Heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a1 Les cas dutilisation Les cas dutilisation (use cases) ont été formalisés par Ivar Jacobson.

Présentation au sujet: "Heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a1 Les cas dutilisation Les cas dutilisation (use cases) ont été formalisés par Ivar Jacobson."— Transcription de la présentation:

1 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a1 Les cas dutilisation Les cas dutilisation (use cases) ont été formalisés par Ivar Jacobson. Les cas dutilisation décrivent, sous la forme dactions et de réactions, le comportement dun système du point de vue dun utilisateur. Un cas dutilisation est une manière spécifique dutiliser un système. Cest limage dune fonctionnalité du système, déclenchée en réponse à la stimulation dun acteur externe. [PAM-00 p151]

2 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a2 Intérêt des cas dutilisation [PAM-00 p152] Ensemble des besoins Utilisateur A Utilisateur B Utilisateur C Les cas dutilisation partitionnent lensemble des besoins dun système Cahier des charges

3 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a3 Le modèle des cas dutilisation Un acteur représente un rôle joué par une personne ou une chose qui interagit avec un système. [PAM-00 p152] Système

4 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a4 Figure 3-125 / Exercice 1 - 1 [PAM-00 p153]

5 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a5 4 grandes catégories dacteurs Les acteurs principaux…les personnes qui utilisent les fonctions principales du système. Les acteurs secondaires…les personnes qui effectuent des tâches administratives ou de maintenance. Le matériel externe…les dispositifs matériels incontournables qui font partie du domaine de lapplication et qui doivent être utilisés. Les autres systèmes… les systèmes avec lesquels le système doit interagir. [PAM-00 p153]

6 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a6 Les scénarios (1) Les cas dutilisation se déterminent en observant et en précisant, acteur par acteur, les séquences dinteraction -les scénarios- du point de vue de lutilisateur. Un cas dutilisation regroupe une famille de scénarios dutilisation selon un critère fonctionnel. Les cas dutilisation sont des abstractions du dialogue entre les acteurs et le système: ils décrivent des interactions potentielles, sans entrer dans le détail de chaque scénario. [PAM-00 p155]

7 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a7 Les scénarios (2) [PAM-00 p155] Les cas dutilisation doivent être vus comme des classes dont les instances sont les scénarios. Chaque fois quun acteur interagit avec le système, le cas dutilisation instantie un scénario; ce scénario correspond au flot de messages échangés par les objets durant linteraction particulière qui correspond au scénario.

8 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a8 Les relations dans un diagramme cas dutilisation La relation de communication La relation de généralisation La relation dinclusion La relation dextension [PAM-00 p156]

9 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a9 La relation dinclusion La relation dinclusion a un caractère obligatoire, la source spécifiant à quel endroit le cas dutilisation cible doit être inclus. [PAM-00 p156]

10 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a10 La relation dextension Dans une relation dextension entre cas dutilisation, le cas dutilisation source ajoute son comportement au cas dutilisation destination (cible). Lextension peut être soumise à une condition. [PAM-00 p156]

11 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a11 Figure 3-133 / Exercice 2 - 1

12 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a12 Règles de mise en œuvre des cas dutilisation La description des cas dutilisation comprend: –Le début du cas dutilisation. –La fin du cas dutilisation. –Linteraction entre le cas dutilisation et les acteurs. –Les échanges dinformations (paramètres des interactions). –La chronologie et lorigine des informations. –Les répétitions de comportement. –Les situations optionnelles. [PAM-00 p158]

13 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a13 Figure 3-134 / Cas dutilisation et scénarios Un cas dutilisation décrit, de manière abstraite, une famille de scénarios. Cas dutilisation Scénario 1Scénario 3Scénario 2 [PAM-00 p160]

14 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a14 Maquette [PAM-97] Le maquettage à base de constructeurs dinterfaces utilisateur est très souvent le meilleur moyen daider lutilisateur final à articuler ses désirs. Lexamen des interactions(*) entre lutilisateur et la maquette procure alors une source non négligeable de scénarios, et donc de moyens de valider le modèle de cas dutilisation. [LMP-98 p61] Une maquette est un ensemble denchaînements décrans permettant de simuler un nombre limité de fonctionnalités du système. Elle sappuie sur des objets métier simulés et des accès en bases de données fictifs. [PAM-97 p131]

15 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a15 La transition vers lobjet (collaboration) [PAM-97 p133]

16 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a16 Collaboration [BRJ-00 p240] Un cas dutilisation saisit le comportement attendu du système que lon développe, sans que lon ait besoin de préciser comment ce comportement est réalisé…Ensuite, il faut quand même implémenter les cas dutilisation en créant une société de classes et dautres éléments qui fonctionnent ensemble pour réaliser le comportement de ce cas dutilisation. Cette société déléments, qui comporte à la fois une structure statique et dynamique, est modélisée en UML sous le nom de collaboration. On peut préciser explicitement la réalisation dun cas dutilisation par une collaboration. Pourtant, la plupart du temps, un cas dutilisation donné est réalisé par une seule collaboration, sans que lon ait à modéliser explicitement cette relation.

17 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a17 Collaboration implicite / Exercice 3 -1

18 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a18 La transition vers lobjet Une approche objet réalise un cas dutilisation au moyen dune collaboration entre objets. Les scénarios, instances du cas dutilisation, sont représentés par des diagrammes dinteraction (diagrammes de collaboration et diagrammes de séquence). [PAM-00 p163]

19 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a19 Les diagrammes dobjets Les diagrammes dobjets, ou diagrammes dinstances, montrent des objets et des liens. Comme les diagrammes de classes, les diagrammes dobjets représentent la structure statique. Les diagrammes dobjets sutilisent principalement pour montrer un contexte, par exemple avant ou après une interaction, mais également pour faciliter la compréhension des structures complexes, comme les structures récursives. [PAM-97 p134]

20 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a20 Représentation des objets Lobjet « ObjetA » nest pas classifié Lobjet « ObjetB » est instance de la classe « ClasseB » Lobjet « ClasseC » est une instance anonyme de la classe «ClasseC» Rational Rose naffiche pas les stéréotypes de classe Rational Rose ne permet pas la saisie de valeurs dattributs Les attributs peuvent être affichés avec la fonction Edit Compartment du menu contextuel des objets [PAM-00 p164]

21 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a21 Représentation des liens / Exercice 4 - 1 [PAM-00 p167] Classe Objets

22 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a22 Les objets composites [PAM-00 p168] Classes Objets

23 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a23 Similitudes avec les diagrammes de classes (1) [PAM-00 p169] Classes Objets

24 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a24 Compréhension de structures complexes [PAM-00 p169]

25 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a25 Les objets actifs [PAM-00 p170]

26 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a26 Les diagrammes de collaboration [PAM-97 p139]Les diagrammes de collaboration montrent des interactions entre objets, en insistant plus particulièrement sur la structure spatiale statique qui permet la mise en collaboration dun groupe dobjets. Les diagrammes de collaboration expriment à la fois le contexte dun groupe dobjets (au travers des objets et des liens) et linteraction entre ces objets (par la représentation de lenvoi de messages). Les diagrammes de collaboration sont une extension des diagrammes dobjet. [PAM-00 p171]

27 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a27 Les envois de messages UML utilise le terme de stimulis pour parler dune communication entre deux objets qui déclenche linvocation dune opération, lémission dun signal ou la création et destruction dun objet [PAM-00 p178]

28 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a28 Représentation des interactions Les interactions comprennent principalement les éléments suivants: –Les instances –Les liens –Les messages –Les rôles Dans un diagramme de collaboration, le temps nest pas représenté de manière implicite, comme dans un diagramme de séquence, de sorte que les différents messages sont numérotés pour indiquer lordre des envois. [PAM-00 p179]

29 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a29 Exercice 5 - 1 Classes Collaboration [PAM-00 p180]

30 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a30 Figure 3-178 / Contraintes [PAM-00 p181]

31 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a31 Figure 3-179 / Itération dun message [PAM-00 p181] Rational Rose prend le symbolisme de litération comme élément constitutif du nom du message.

32 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a32 La place de lutilisateur [PAM-00 p182] Stéréotype Acteur

33 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a33 Syntaxe des messages Le message, ses arguments et valeurs de retour, son rang au sein de linteraction, et diverses autres informations comme le degré demboîtement ou la synchronisation sont précisés lors de lenvoi. Séquence Niveau demboîtement du message au sein de linteraction Résultat Liste de valeurs retournées par le message Nom du message … Opération définie dans la classe de lobjet destinataire Argument Liste des paramètres du message [PAM-00 p182]

34 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a34 Les messages / Figure 3-183 Rational Rose ne supporte pas lensemble des enrichissements de messages que cite P.-A. Muller [PAM-00 p182-185]. Dans ses exemples avec Rational Rose, P.-A. Muller enrichit la sémantique des messages en utilisant la zone de nommage! [PAM-97 p143]

35 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a35 Enrichissement des messages (1)

36 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a36 Opération conditionnelle

37 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a37 Les « pattern » [PAM-97 p146] Les collaborations existent également sous une forme générique (modèle), paramétrée par des classes, des relations, des attributs et des opérations. Une collaboration générique est appelée « pattern » ou schème et micro-architecture en français. Les patterns possèdent toujours un nom, contrairement aux collaborations qui peuvent être anonymes.

38 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a38 Les diagrammes de séquence [PAM-97 p148] Les diagrammes de séquence montrent des interactions entre objets selon un point de vue temporel. Le contexte des objets nest pas représenté de manière explicite comme dans les diagrammes de collaboration. La représentation se concentre sur lexpression des interactions. Un diagramme de séquence représente une interaction entre objets en insistant sur la chronologie des envois de messages. La notation est dérivée des « Object Message Sequence du Siemens Pattern Group ». [PAM-00 p186]

39 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a39 1ère utilisation des diagrammes de séquence La première utilisation des diagrammes de séquence correspond à la documentation des cas dutilisation. [PAM-00 p188]

40 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a40 Figure 3-192 / Exercice 6 -1

41 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a41 Catégories denvoi de messages [PAM-97 p149] Les diagrammes de séquence distinguent deux grandes catégories denvoi de message: –Les envois synchrones pour lesquels lémetteur est bloqué et attend que lappelé ait fini de traiter le message. –Les envois asynchrones pour lesquels lémetteur nest pas bloqué et peut continuer son exécution.

42 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a42 Les activations et envois de messages Les diagrammes de séquence permettent de représenter les périodes dactivité des objets. Une période dactivité correspond au temps pendant lequel un objet effectue une action, soit directement, soit par lintermédiaire dun autre objet qui lui sert de sous-traitant. Les périodes dactivité se représentent par des bandes rectangulaires placées sur les lignes de vie. Le début et la fin dune bande correspondent respectivement au début et à la fin dune période dactivité. [PAM-00 p189]

43 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a43 Retour en fin dexécution Message synchrone Retour implicite Message asynchrone Retour explicite [PAM-00 p190]

44 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a44 Représentation des interactions [PAM-00 p190-194] 3 4 1 2

45 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a45 Les contraintes temporelles [PAM-00 p192]

46 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a46 Figure 3-204 / Exercice 7 -1 [PAM-00 p193]

47 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a47 Contrôle centralisé [KETT-98 Fig1-40] Diagramme de séquence avec un objet contrôleur chef dorchestre

48 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a48 Contrôle décentralisé [KETT-98 Fig1-41] Diagramme de séquence avec délégation

49 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a49 Diagramme de séquence à éviter! [KETT-98 Fig1-42]

50 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a50 Pseudo-code (1) Lajout de pseudo-code sur la partie gauche du diagramme permet la représentation des boucles et des branchements, de sorte que les diagrammes de séquence peuvent représenter la forme générale dune interaction, au-delà de la seule prise en compte dun scénario particulier. [PAM-00 p194]

51 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a51 Figure 3-209 / Pseudo-code (2) [PAM-00 p195]

52 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a52 Messages et opérations des classes Utilisation des diagrammes de séquence: Documentation des cas dutilisation Messages propres au diagramme Spécification technique Messages correspondants aux opérations des classes

53 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a53 Exercice 7 - 1 Cet exercice est repris de [LMP-98 p71-73] Il sagit dun exemple de retrait dargent à un guichet. Le but est de décrire un cas dutilisation sous forme textuelle, sous forme de diagramme de séquence et de diagramme de collaboration. Nous reproduirons ci-après: –Lintroduction théorique de [LMP-98] relative à la description dun cas dutilisation. –Le diagramme du cas dutilisation. –La description textuelle dune instance du cas dutilisation. –Le (un) diagramme de scénario du cas dutilisation. –Le (un) diagramme de collaboration du cas dutilisation.

54 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a54 Exercice 7 – 2 / Introduction théorique [LMP-98 p71] La description des use case doit être synthétique, facilement compréhensible (comme tout modèle) et doit également rendre compte facilement dun cas dutilisation. Un use case peut être décrit de différentes façons: –de façon informelle, il sagit alors de texte libre, comme peuvent lêtre les spécifications. Il faut que les explications soient un minimum structurées et concises; –de façon formelle, il peut alors sagir de langages structurés, de pseudo-code, de diagrammes. Ces notations ne doivent pas être trop techniques, il ne faut pas commencer une ébauche dimplémentation à ce stade de lanalyse.

55 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a55 Exercice 7 – 3 / Le cas dutilisation

56 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a56 Exercice 7 – 4 / Une représentation textuelle Le guichetier saisit le numéro de compte du client. Lapplication valide le compte auprès du système central. Lapplication demande le type dopération au guichetier. Le guichetier sélectionne un retrait de 200 F. Le système « guichet » interroge le système central pour sassurer que le compte est suffisamment approvisionné. Le système central effectue le débit du compte. Le système notifie au guichetier quil peut délivrer le montant demandé. Use case « retrait en espèce »

57 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a57 Exercice 7 – 5 / Un scénario

58 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a58 Exercice 7 – 6 / Un diagramme de collaboration

59 heg Haute école de gestion de Neuchâtel 14/11/01UML 04 V1-1a59 Exercice 7 – 7 / État du référentiel