Les Cas d’utilisation.

Présentation au sujet: "Les Cas d’utilisation."— Transcription de la présentation:

1 Les Cas d’utilisation

2 Cas d’utilisation Solution UML pour représenter le Modèle Conceptuel
Ils permettent de structurer: les besoins des utilisateurs les objectifs correspondants d'un système. Ils centrent l'expression des exigences du système sur ses utilisateurs Ils se limitent aux préoccupations "réelles" des utilisateurs Ils identifient les utilisateurs du système leur interaction avec le système. Ils permettent de classer les acteurs de structurer les objectifs du système. Ils servent de base à la traçabilité des exigences d'un système Jacobson identifie les caractéristiques suivantes pour les modèles : Un modèle est une simplification de la réalité. Il permet de mieux comprendre le système qu'on doit développer. Les meilleurs modèles sont proches de la réalité. Les cas d'utilisation permettent de modéliser les besoins des clients d'un système et doivent aussi posséder ces caractéristiques. Ils ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins. Une fois identifiés et structurés, ces besoins : définissent le contour du système à modéliser (ils précisent le but à atteindre), permettent d'identifier les fonctionnalités principales (critiques) du système. Les cas d'utilisation ne doivent donc en aucun cas décrire des solutions d'implémentation. Leur but est justement d'éviter de tomber dans la dérive d'une approche fonctionnelle, où l'on liste une litanie de fonctions que le système doit réaliser. Les diagrammes de cas d'utilisation utilisent des acteurs, le système et les cas d'utilisation eus- mêmes. L'ensemble des fonctionnalités d'un système est exprimé en considérant les besoins fonctionnels de chaque acteur, exprimés sous forme de familles d'interactions. Les acteurs sont représentés par de petits personnages déclenchant des cas d'utilisation. Un cas d'utilisation est représenté par une ellipse. Le système est une boîte contenant les cas d'utilisation. Un acteur représente un rôle joué par une personne : directeur, administrateur réseau, gardien de l'immeuble sont des fonctions, des rôles de personnes. Un acteur peut être un utilisateur direct du système, une personne responsable de son exploitation, de sa maintenance, ou bien tout simplement un autre système qui interagit avec le système à modéliser. On distingue quatre catégories d'acteurs : 1 - les acteurs principaux : les personnes qui utilisent les fonctions principales du système. 2 - les acteurs secondaires : les personnes qui effecetuent des tâches administratives ou de maintenance sur le système. 3 - le matériel externe : le matériel qu'il est incontournable d'utiliser pour la bonne marche du système. 4 - les autres systèmes : le matériel avec lequel le système devra interagir. Après identification, un acteur doit être décrit d'une manière claire en quelques lignes. On peut les regrouper par famille s'ils sont nombreux, afin de clarifier les diagrammes.

3 Cas d’utilisation Trois concepts fondamentaux interviennent :
Les acteurs : utilisateurs du système. Les cas : utilisation du système  Leurs relations qui permettent un découpage fonctionnel Les use cases (cas d’utilisation) sont un concept de la méthode OOSE de Ivar Jacobson. Ils permettent d’effectuer une délimitation du système et de décrire son comportement. Ils constituent une représentation orientée “ fonctionnalités ” du système. Dans la modélisation par les use cases : 2 concepts fondamentaux interviennent : Les acteurs : utilisateurs du système. Les uses cases : utilisation du système  Les Acteurs: ce sont les utilisateurs du système Ils ont une bonne connaissance des fonctionnalités du système. Ils constituent les éléments extérieurs du système. Ils peuvent être : soit des humains ; soit des logiciels ; soit des automates. On distingue  : les acteurs primaires : ceux sont les utilisateurs du système ; les acteurs secondaires : ceux qui administrent le système. Les uses cases Ce sont les utilisations du système Il s’agit de déterminer les éléments constitutifs d’un point de vue fonctionnel. On pourra trouver des use cases pour décrire : chaque tâche de l’utilisateur ; les fonctionnalités mal décrites lors des spécifications ; les E/S des données ; les cas d’anomalies.

4 Cas d’utilisation Les Acteurs Ce sont les utilisateurs du système
Ils ont une bonne connaissance des fonctionnalités du système. Ils constituent les éléments extérieurs du système. Ils peuvent être : des humains  des logiciels des automates On distingue  : les acteurs primaires  les acteurs secondaires 

5 Cas d’utilisation Acteurs : représentation
Dans UML, le nom de l ’acteur correspond au rôle qu’il joue vis-à-vis du système

6 Cas d’utilisation Les Cas Ce sont les utilisations du système
Il s’agit de déterminer les éléments constitutifs d’un point de vue fonctionnel. Un Use Case s'adresse à un acteur qui va solliciter le système et en attendre un service mesurable. Cette sollicitation fait naître la notion d'évènement externe qui sollicite le système. Un Use Case regroupe une séquence d'actions qui seront réalisées par le système. Ici, on ne s'intéresse pas à chaque action mais bien à des étapes clefs du systèmes qui sont menées à l'aide de séquences d'actions. La séquence signifie ici ininterrompue, non pas dans le sens BATCH, mais dans le cadre d'une même sollicitation - d'un même évènement externe -. Un état du système atteint à la fin d'une séquence d'action est caractérisé par la production d'un résultat tangible - le service rendu - et mesurable par un acteur. Un Use Case élémentaire peut être considéré, du point de vue métier, comme un situation de vie de l'acteur ayant un début et une fin. Il est appréciable de donner un titre très parlant au Use Case, on aide ainsi à "modéliser" le métier. NB : Dans la définition, un Use Case est mono acteur et mono résultat mais, dans la pratique, on ne décrit pas chaque Use Case théorique de manière spécifique. Un regroupement peut s'effectuer pour mettre en avant les situations caractéristiques du métier. On peut considérer que ces situations représentent plus des WORKFLOW que des Use Case. Cela peut, dans certains cas représenter un gain de lisibilité du système et dans d'autres une confusion entre Use Case et Processus métier voire traitements.

7 Cas d’utilisation Cas d’utilisation : représentation
Un cas d ’utilisation correspond à une famille de scénarios qui pourront être représentés par des diagrammes de séquences

8 Cas d’utilisation Un cas d’utilisation correspond à des familles de scénarios qui vont mettre en évidence les objets nécessaires à leur réalisation

9 Cas d’utilisation Un Cas d ’Utilisation peut être employé de deux manières : Comme une spécification de ce qu'il sera possible de demander de l'extérieur à l'entité ainsi représentée Comme une spécification de la fonctionnalité offerte par cette même entité (déja réalisée) D'un point de vue méthodologique, on peut le comparer au concept de vue externe en BD, à cette différence essentielle près qu'il ne décrit pas un sous schéma logique d'une structure

10 Cas d’utilisation Le scénario est initié par un acteur (ici la secrétaire). En réponse, l'instance exécute la séquence d'actions spécifiée par le cas d'utilisation Commande. Cette exécution peut consister en l'envoi d'un message à une instance d'acteur qui n'est pas nécessairement le déclencheur (par exemple ici à l'acheteur pour qu'il demande l'exécution du cas Choix_fournisseur). On peut donc définir l'interaction Use Case - Acteur par des interfaces. Plusieurs Use Case peuvent être assemblés pour former un système de plus haut niveau. Par exemple le rectangle de la figure est un système que l'on pourrait appeler Approvisionnement. On obtient ainsi quelque chose de similaire au processus de Merise à 2 différences (importantes) près : - on ne s'interesse pas au fil d'exécution interne - on s'intéresse aux interactions entre le système (processus) et son environnement. Les diagrammes Use Case modélisent donc à la fois : des activités (fonctionnalités) et des communications (interactions) pour les entités concernées

11 Cas d’utilisation Raffinage des Cas

12 Cas d’utilisation UML prédéfinit 4 stéréotypes de liens: Association
<<Extend>> <<Include>> <<Generalize>>

13 Stéréotypes de liens dans un diagramme de Cas
Association: C'est la seule relation autorisée entre une instance d'acteur et une instance de cas

14 Stéréotypes de liens dans un diagramme de Cas
<<Extend>> : C'est une relation entre 2 instances de cas telle que A étend B signifie que le comportement d'un B peut être complété par le comportement d'un A.

15 Stéréotypes de liens dans un diagramme de Cas
<<Extend>> : Ici le comportement du cas « Commander un Produit » peut être complété par le comportement du cas «Obtenir une réduction »

16 Stéréotypes de liens dans un diagramme de Cas
<<Extend>> : Cette relation doit spécifier à la fois : la condition de l'extension et le point d'extension. Il y a une notion de POSSIBILITE, d’OPTION

17 Stéréotypes de liens dans un diagramme de Cas
<<Include>> : C'est une relation entre 2 instances de Cas telle que la réalisation de la fonction de l'un nécessite la réalisation de la fonction de l'autre. Il y a une notion d’OBLIGATION

18 Stéréotypes de liens dans un diagramme de Cas
<<Include>> : Ici la réalisation de « Régler la facture » nécessite la réalisation de « Payer ». Il y a une notion d’OBLIGATION

19 Stéréotypes de liens dans un diagramme de Cas
<<Include>>

20 Stéréotypes de liens dans un diagramme de Cas
<<Generalize>> : Exprime une relation d'héritage qui sera présentée plus en détail à l'occasion du diagramme de CLASSE. Elle exprime « est une sorte de »

21 Cas d’utilisation