1 / 59

Les cas d’utilisation

Les cas d’utilisation. Les cas d’utilisation (use cases) ont été formalisés par Ivar Jacobson. Les cas d’utilisation décrivent , sous la forme d’actions et de réactions, le comportement d’un système du point de vue d’un utilisateur .

axel
Download Presentation

Les cas d’utilisation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Les cas d’utilisation Les cas d’utilisation (use cases) ont été formalisés par Ivar Jacobson. Les cas d’utilisation décrivent, sous la forme d’actions et de réactions, le comportement d’un système du point de vue d’un utilisateur. Un cas d’utilisation est une manière spécifique d’utiliser un système. C’est l’image d’une fonctionnalité du système, déclenchée en réponse à la stimulation d’un acteur externe. UML 04 V1-1a [PAM-00 p151]

  2. Utilisateur C Ensemble des besoins Utilisateur A Utilisateur B Intérêt des cas d’utilisation Les cas d’utilisation partitionnent l’ensemble des besoins d’un système Cahier des charges UML 04 V1-1a [PAM-00 p152]

  3. Système Le modèle des cas d’utilisation Un acteur représente un rôle joué par une personne ou une chose qui interagit avec un système. UML 04 V1-1a [PAM-00 p152]

  4. Figure 3-125 / Exercice 1 - 1 UML 04 V1-1a [PAM-00 p153]

  5. 4 grandes catégories d’acteurs • 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 l’application et qui doivent être utilisés. • Les autres systèmes… les systèmes avec lesquels le système doit interagir. UML 04 V1-1a [PAM-00 p153]

  6. Les scénarios (1) Les cas d’utilisation se déterminent en observant et en précisant, acteur par acteur, les séquences d’interaction -les scénarios- du point de vue de l’utilisateur. Un cas d’utilisation regroupe une famille de scénarios d’utilisation selon un critère fonctionnel. Les cas d’utilisation 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. UML 04 V1-1a [PAM-00 p155]

  7. Les cas d’utilisation doivent être vus comme des classes dont les instances sont les scénarios. Chaque fois qu’un acteur interagit avec le système, le cas d’utilisation instantie un scénario; ce scénario correspond au flot de messages échangés par les objets durant l’interaction particulière qui correspond au scénario. Les scénarios (2) UML 04 V1-1a [PAM-00 p155]

  8. Les relations dans un diagramme cas d’utilisation • La relation de communication • La relation de généralisation • La relation d’inclusion • La relation d’extension UML 04 V1-1a [PAM-00 p156]

  9. La relation d’inclusion La relation d’inclusion a un caractère obligatoire, la source spécifiant à quel endroit le cas d’utilisation cible doit être inclus. UML 04 V1-1a [PAM-00 p156]

  10. La relation d’extension Dans une relation d’extension entre cas d’utilisation, le cas d’utilisation source ajoute son comportement au cas d’utilisation destination (cible). L’extension peut être soumise à une condition. UML 04 V1-1a [PAM-00 p156]

  11. Figure 3-133 / Exercice 2 - 1 UML 04 V1-1a

  12. Règles de mise en œuvre des cas d’utilisation La description des cas d’utilisation comprend: • Le début du cas d’utilisation. • La fin du cas d’utilisation. • L’interaction entre le cas d’utilisation et les acteurs. • Les échanges d’informations (paramètres des interactions). • La chronologie et l’origine des informations. • Les répétitions de comportement. • Les situations optionnelles. UML 04 V1-1a [PAM-00 p158]

  13. Figure 3-134 / Cas d’utilisation et scénarios Un cas d’utilisation décrit, de manière abstraite, une famille de scénarios. Scénario 1 Scénario 2 Scénario 3 Cas d’utilisation UML 04 V1-1a [PAM-00 p160]

  14. Maquette [PAM-97] Le maquettage à base de constructeurs d’interfaces utilisateur est très souvent le meilleur moyen d’aider l’utilisateur final à articuler ses désirs. L’examen des interactions(*) entre l’utilisateur et la maquette procure alors une source non négligeable de scénarios, et donc de moyens de valider le modèle de cas d’utilisation. [LMP-98 p61] Une maquette est un ensemble d’enchaînements d’écrans permettant de simuler un nombre limité de fonctionnalités du système. Elle s’appuie sur des objets métier simulés et des accès en bases de données fictifs. UML 04 V1-1a [PAM-97 p131]

  15. La transition vers l’objet (collaboration) UML 04 V1-1a [PAM-97 p133]

  16. Collaboration [BRJ-00 p240] Un cas d’utilisation saisit le comportement attendu du système que l’on développe, sans que l’on ait besoin de préciser comment ce comportement est réalisé…Ensuite, il faut quand même implémenter les cas d’utilisation en créant une société de classes et d’autres éléments qui fonctionnent ensemble pour réaliser le comportement de ce cas d’utilisation. 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 d’un cas d’utilisation par une collaboration. Pourtant, la plupart du temps, un cas d’utilisation donné est réalisé par une seule collaboration, sans que l’on ait à modéliser explicitement cette relation. UML 04 V1-1a

  17. Collaboration implicite / Exercice 3 -1 UML 04 V1-1a

  18. Une approche objet réalise un cas d’utilisation au moyen d’une collaboration entre objets. Les scénarios, instances du cas d’utilisation, sont représentés par des diagrammes d’interaction (diagrammes de collaboration et diagrammes de séquence). La transition vers l’objet UML 04 V1-1a [PAM-00 p163]

  19. Les diagrammes d’objets Les diagrammes d’objets, ou diagrammes d’instances, montrent des objets et des liens. Comme les diagrammes de classes, les diagrammes d’objets représentent la structure statique. Les diagrammes d’objets s’utilisent 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. UML 04 V1-1a [PAM-97 p134]

  20. Représentation des objets L’objet « ObjetA » n’est pas classifié L’objet « ObjetB » est instance de la classe «  ClasseB » L’objet « ClasseC » est une instance anonyme de la classe «ClasseC» Rational Rose n’affiche pas les stéréotypes de classe • Rational Rose ne permet pas la saisie de valeurs d’attributs • Les attributs peuvent être affichés avec la fonction • Edit Compartment du menu contextuel des objets UML 04 V1-1a [PAM-00 p164]

  21. Classe Objets Représentation des liens / Exercice 4 - 1 UML 04 V1-1a [PAM-00 p167]

  22. Classes Objets Les objets composites UML 04 V1-1a [PAM-00 p168]

  23. Classes Objets Similitudes avec les diagrammes de classes (1) UML 04 V1-1a [PAM-00 p169]

  24. Compréhension de structures complexes UML 04 V1-1a [PAM-00 p169]

  25. Les objets actifs UML 04 V1-1a [PAM-00 p170]

  26. 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 d’un groupe d’objets. Les diagrammes de collaboration expriment à la fois le contexte d’un groupe d’objets (au travers des objets et des liens) et l’interaction entre ces objets (par la représentation de l’envoi de messages). Les diagrammes de collaboration sont une extension des diagrammes d’objet. UML 04 V1-1a [PAM-00 p171]

  27. Les envois de messages UML utilise le terme de stimulis pour parler d’une communication entre deux objets qui déclenche l’invocation d’une opération, l’émission d’un signal ou la création et destruction d’un objet UML 04 V1-1a [PAM-00 p178]

  28. 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 n’est 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 l’ordre des envois. UML 04 V1-1a [PAM-00 p179]

  29. Exercice 5 - 1 Classes Collaboration UML 04 V1-1a [PAM-00 p180]

  30. Figure 3-178 / Contraintes UML 04 V1-1a [PAM-00 p181]

  31. Figure 3-179 / Itération d’un message Rational Rose prend le symbolisme de l’itération comme élément constitutif du nom du message. UML 04 V1-1a [PAM-00 p181]

  32. La place de l’utilisateur Stéréotype Acteur UML 04 V1-1a [PAM-00 p182]

  33. Syntaxe des messages Le message, ses arguments et valeurs de retour, son rang au sein de l’interaction, et diverses autres informations comme le degré d’emboîtement ou la synchronisation sont précisés lors de l’envoi. Séquence Niveau d’emboîtement du message au sein de l’interaction Résultat Liste de valeurs retournées par le message Nom du message … Opération définie dans la classe de l’objet destinataire Argument Liste des paramètres du message UML 04 V1-1a [PAM-00 p182]

  34. Les messages / Figure 3-183 Rational Rose ne supporte pas l’ensemble 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! UML 04 V1-1a [PAM-97 p143]

  35. Enrichissement des messages (1) UML 04 V1-1a

  36. Opération conditionnelle UML 04 V1-1a

  37. 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. UML 04 V1-1a

  38. 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 n’est pas représenté de manière explicite comme dans les diagrammes de collaboration. La représentation se concentre sur l’expression 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 ». UML 04 V1-1a [PAM-00 p186]

  39. 1ère utilisation des diagrammes de séquence La première utilisation des diagrammes de séquence correspond à la documentation des cas d’utilisation. UML 04 V1-1a [PAM-00 p188]

  40. Figure 3-192 / Exercice 6 -1 UML 04 V1-1a

  41. Catégories d’envoi de messages [PAM-97 p149]Les diagrammes de séquence distinguent deux grandes catégories d’envoi de message: • Les envois synchrones pour lesquels l’émetteur est bloqué et attend que l’appelé ait fini de traiter le message. • Les envois asynchrones pour lesquels l’émetteur n’est pas bloqué et peut continuer son exécution. UML 04 V1-1a

  42. Les activations et envois de messages Les diagrammes de séquence permettent de représenter les périodes d’activité des objets. Une période d’activité correspond au temps pendant lequel un objet effectue une action, soit directement, soit par l’intermédiaire d’un autre objet qui lui sert de sous-traitant. Les périodes d’activité se représentent par des bandes rectangulaires placées sur les lignes de vie. Le début et la fin d’une bande correspondent respectivement au début et à la fin d’une période d’activité. UML 04 V1-1a [PAM-00 p189]

  43. Retour en fin d’exécution Message synchrone  Retour implicite Message asynchrone  Retour explicite UML 04 V1-1a [PAM-00 p190]

  44. Représentation des interactions 1 2 3 4 UML 04 V1-1a [PAM-00 p190-194]

  45. Les contraintes temporelles UML 04 V1-1a [PAM-00 p192]

  46. Figure 3-204 / Exercice 7 -1 UML 04 V1-1a [PAM-00 p193]

  47. Contrôle centralisé Diagramme de séquence avec un objet contrôleur chef d’orchestre UML 04 V1-1a [KETT-98 Fig1-40]

  48. Contrôle décentralisé Diagramme de séquence avec délégation UML 04 V1-1a [KETT-98 Fig1-41]

  49. Diagramme de séquence à éviter! UML 04 V1-1a [KETT-98 Fig1-42]

  50. Pseudo-code (1) L’ajout 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 d’une interaction, au-delà de la seule prise en compte d’un scénario particulier. UML 04 V1-1a [PAM-00 p194]

More Related