SEG 3501- Module 3 Modélisation à l’aide de UML 2

1. SEG 3501- Module 3Modélisation à l’aide de UML 2 Objectifs: Caractéristiques intéressantes de UML 2.x pour la modélisation dans un contexte d’ingénierie des exigences. Diagrammes de classe, de séquence, d’états (beaucoup de matériel tiré de http://www.developpez.com de même que de K. Kostas, S. Somé, G. Mussbacher et D. Amyot)

2. Évolution d’UML (http://www.omg.org/uml/) Rumbaugh Booch Jacobson Version officielle: 2.4.1 (août 2011) 2.5 Beta (“simplified”): 831 pages!

3. Dilbert et les normes… Module 3 : Spécification des exigences

4. Treize types de diagrammes UML 2.x • Structure • Classe, objet, structure composite, composantes, et cas d’utilisations • Dynamique (comportement) • Machines à états, activités, séquence, communication, chronogramme, et aperçu d’interactions • Physique • Déploiement • Gestion de modèles • Paquetage Module 3 : Spécification des exigences

5. Quand utiliser UML 2 pour l’I.E.? • Diagrammes de cas d’usage: • Acteurs et structure des cas d’usage • Diagrammes de classes: • Modélisation du domaine • Diagrammes d’activités: • Modélisation de processus (d’affaires ou autres) • Semblables à UCM • Diagrammes de séquences: • Modélisation de scénarios par échanges de messages • Diagrammes de machines à états: • Modélisation de comportement détaillé (objets, protocoles, ports) • Modélisation du comportement du système entier (boîte noire) Module 3 : Spécification des exigences

6. Diagrammes de classes UML 2 Module 3 : Spécification des exigences

7. Modélisation entité-relation (ERM) • Proposé à l’origine par Peter Chen (1976) • Concepts • Entité: représente un type d’instances et définit les propriétés de ces instances • Relation: représente les instances de lien qui existent entre certaines paires d’entités • Les entités impliquées s’appellent rôles • L’information de multiplicité précise combien d’instances de l’autre côté de la relation sont en lien avec cette instance. • Attribut: une entité ou une relation peut avoir plusieurs attributs, identifiés par un nom et un type primitif (entier, chaîne de caractères…) Module 3 : Spécification des exigences

8. Notation ERM • Plusieurs notations existent. • Voici celle de Chen (1976) Module 3 : Spécification des exigences

9. Diagrammes de classe UML Module 3 : Spécification des exigences

10. Analyse orientée-objet (OOA) • Cinq étapes principales • Identifier les classes clés dans le domaine du problème • Modéliser les relations entre les classes (diagramme de class) • Définir les attributs associés à chaque classe • Déterminer leurs opérations pertinentes • Définir les échanges de messages entre les objets • diagrammes d’interactions et d’états Module 3 : Spécification des exigences

11. Exercice… • Concevez un modèle de domaine simple pour une application logicielle permettant de faire de la généalogie • Classes, attributs et associations pertinentes? • Observez-vous certaines contraintes difficiles à exprimer avec les diagrammes de classe? Module 3 : Spécification des exigences

12. Problèmes avec les diagramme de classe? • Risque de sombrer dans la conception… • Et oui, encore des problèmes d’extension et de décomposition… • Les exigences ne peuvent pas toutes être assignées à un seul composant ou une seule classe • Les objectifs et scénarios peuvent en affecter plusieurs classes à la fois • La modularisation OO n’est pas parfaite non plus… • Motivation pour la conception orientée-aspect Module 3 : Spécification des exigences

13. ComponentA R1 elements ComponentD R1 elements ComponentC R1 elements ComponentE ComponentB R1 elements Requirement1 (R1) Requirement2 (R2) Requirement3 (R3) ComponentF R1 elements R2 elements R3 elements RN elements … RequirementN (RN) Analyse orientée-objet: Problèmes Scattering (éparpillement): designelements to support R1 in many components Tangling (emmêlement):single component has elements for many requirements Module 3 : Spécification des exigences

14. intertypedeclaration Aspect advice ClassA R1 elements ClassC R1 elements ClassG R1 elements ClassB R1 elements pointcut ClassF R1 elements R2 elements R3 elements RN elements (identifies joinpointswhere advice is executed) Une solution partielle: les Aspects (pour votre info…) R1 elements F.R1 Triggered behavior (code) R1 elements Predicate R1 elements R1 elements R1 elements Terminologie basée sur AspectJ: www.eclipse.org/aspectj Module 3 : Spécification des exigences

15. Diagrammes d’activités UML 2(pour votre information seulement) Module 3 : Spécification des exigences

16. Éléments des diagrammes d’activités Décrivent les aspects dynamiques a l’aide de flots d’activités Module 3 : Spécification des exigences

17. Exemples de partitions Module 3 : Spécification des exigences

18. UCM ou diagrammes d’activités UML? • Les UCM et les diagrammes d’activités (DA) ont beaucoup de concepts en commun • Responsabilité  Action • Points de départ / d’arrivée • Alternatives (fork/join) • Concurrence (fork/join) • Stub/plug-in  Action / sous-DA • Association entre éléments et composantes / partition • Peuvent tout deux représenter des scénarios opérationnels et des processus d’affaires. Module 3 : Spécification des exigences

19. Uniques à UCM • Stubs dynamiques avec plusieurs plug-ins • Les DA n’ont qu’un seul sous-DA par action • Synchronizing/Blocking stubs • Les plug-ins peuvent continuer en parallèle avec leur modèle parent • Les sous-DA doivent terminer avant de revenir au DA parent • Disposition graphique 2D des composantes • Définitions de scénarios (tests intégrés!) • Intégration avec GRL dans URN Module 3 : Spécification des exigences

20. Uniques aux diagrammes d’activités • Flots de données • Conditions sur parallélisme (branches d’un AND-fork) • UCM les supporte avec les stubs synchronisants • Contraintes sur pines • Intégration avec UML (incluant les diagrammes de classe et OCL) Module 3 : Spécification des exigences

21. Diagrammes de séquences UML 2 Module 3 : Spécification des exigences

22. Éléments de base Module 3 : Spécification des exigences

23. Interactions synchrones ou asynchrones Module 3 : Spécification des exigences

24. Fragments combinés • Les fragments combinés permettent de décrire des diagrammes de séquence de manière compacte. • Pour combiner des fragments de séquences, il existe une dizaine d’opérateurs définis dans la notation UML 2.0. • Alternative (alt) • Option (opt) • Boucle (loop) • Parallèle (par) • « Break », pour indiquer que le reste du scénario ne sera pas couvert • « Neg », pour les scénarios d’abus ou invalides • « Critical », pour désigner une section critique • « Ignore » et « Consider », pour filtrer les message • « Assert », pour indiquer une assertion dans un scénario • Séquençage faible ou stricte • Les fragments combinés peuvent faire intervenir l'ensemble des entités participant au scénario ou juste un sous-ensemble. Module 3 : Spécification des exigences

25. Fragments combinés: alternative Exemple: soit l'utilisateur entre un code correct et dans ce cas le diagramme de séquence relatif à la vérification du code est appelé, soit (alt) l'utilisateur entre un code erroné trois fois et sa carte est gardée. On remarque ici une référence (ref) vers un diagramme défini ailleurs. Module 3 : Spécification des exigences

26. Fragments combinés: optionnel Cas particulier du alt. L'utilisateur, si il est mécontent, peut se défouler sur le distributeur de billets. L'opérateur opt montre cette possibilité. Module 3 : Spécification des exigences

27. Fragments combinés: boucle Ce diagramme de séquence avec segment loop indique que lorsque l'utilisateur se trompe trois fois de code, la carte est gardée et le distributeur se remet en mode d'attente d'une carte. Module 3 : Spécification des exigences

28. Fragments combinés: parallèle (par) Un développeur averti ayant accès à Internet peut consulter en parallèle, soit le site http://www.developpez.com soit le site http://www.developpez.net/forums/ sans préférence d'ordre (il peut commencer par consulter les forums puis les cours, soit l'inverse) Module 3 : Spécification des exigences

29. Quiz parallélisme! • L’interaction du bas est-elle une version séquentielle valide du diagramme du haut (par)? • Non! Les sous-séquences combinées peuvent être entrelacées mais l’ordre des sous-séquences doit être maintenu. Module 3 : Spécification des exigences

30. Fragments combinés: imbriqués Module 3 : Spécification des exigences

31. Aspects temporels (pour votre info) Module 3 : Spécification des exigences

32. Diagrammes d’états UML 2 Module 3 : Spécification des exigences

33. Diagrammes d’états Décrivent la vue dynamique d’un objet (états et transitions) Module 3 : Spécification des exigences

34. on on Lamp On Lamp On print(”on”) on on/print(”on”) off off off off Lamp Off Lamp Off Automate de Moore Automate de Mealy Sorties et actions • Des sorties peuvent être générées lors de transitions: Module 3 : Spécification des exigences

35. on Lamp On on/ctr := ctr + 1 off off Lamp Off Variables (états « étendus ») ctr : Integer Module 3 : Spécification des exigences

36. threshold time Modélisation de comportement • En général, les machines à états sont appropriées pour décrire des systèmes réactifs ou à base d’événements • Inappropriés pour décrire un comportement continu. Module 3 : Spécification des exigences

37. top stop Notation de base UML État “top” État Pseudoétat initial Déclancheur Ready Transition stop /ctr := 0 Done Étatfinal Action Module 3 : Spécification des exigences

38. LampOn e2 e1 Actions d’entrée/sortie d’état (Entry et Exit) entry/lamp.on(); exit/lamp.off(); Module 3 : Spécification des exigences

39. LampOn LampOff entry/lamp.on(); off/printf(“to off”); entry/lamp.off(); exit/printf(“exiting”); exit/printf(“exiting”); off/printf(“needless”); Ordre des actions • Actions de sortie: préfix d’une transition • Actions de sortie: postfix d’une transition Séquence d’actions résultante: printf(“exiting”); printf(“to off”); lamp.off(); printf(“exiting”); printf(“needless”); lamp.off(); Module 3 : Spécification des exigences

40. Error entry/printf(“error!”) Activités d’états (Do) • Crée un processus concurrent qui va s’exécuter jusqu’à ce que: • L’action se termine, ou • On quitte l’état via une transition de sortie Activité “do” do/alarm.ring(); Module 3 : Spécification des exigences

41. bid [value < 100] /reject Selling bid [value >= 200] /sell Happy bid [(value >= 100) & (value < 200)] /sell Unhappy Gardes (conditions) • Les gardes (expressions booléennes) ne doivent pas avoir d’effets de bord. Exécution conditionnelle de transitions. Module 3 : Spécification des exigences

42. flash/ LampOn LampOff off/ entry/lamp.on() entry/lamp.off() 1sec/ 1sec/ on/ on/ FlashOn FlashOff on/ entry/lamp.off() entry/lamp.on() Machines à états hiérarchiques • États composés, pour gérer la complexité LampFlashing Module 3 : Spécification des exigences

43. flash/ LampOn LampOff off/ entry/lamp.off() entry/lamp.on() 1sec/ 1sec/ on/ FlashOn FlashOff on/ entry/lamp.off() entry/lamp.on() Transitions de groupe Transition par défaut vers Le pseudoétat initial LampFlashing Transition de groupe Module 3 : Spécification des exigences

44. Committing Phase1 CommitDone Phase2 Transitions de complétion • Déclenchées par un événement de complétion • Généré automatiquement quand une machine à état imbriquée se termine transition de complétion (sans déclencheur) Module 3 : Spécification des exigences

45. on/ on/ Règle de déclenchement • Plusieurs transitions peuvent avoir le même événement déclencheur • Celui imbriqué le plus profondément a précédence • L’événement disparait peu importe s’il déclenche une transition ou non LampFlashing FlashOn off/ FlashOff Module 3 : Spécification des exigences

46. S1 exit/exS1 S2 entry/enS2 S11 exit/exS11 S21 entry/enS21 Ordre des actions: exemple plus complexe /initS2 E/actE Séquence d’exécution d’actions: exS11exS1  actE enS2  initS2  enS21 Module 3 : Spécification des exigences

47. Exercice: Que fait cette machine? • Comment pourrait-elle être améliorée? Module 3 : Spécification des exigences

48. age financialStatus Child Poor Adult age financialStatus Rich Child Retiree Poor Adult Rich Retiree Régions orthogonales • Combine plusieurs perspectives simultanément Module 3 : Spécification des exigences

49. legalStatus financialStatus LawAbiding Poor robBank/ robBank/ Outlaw Rich Régions orthogonales - Sémantique • Toutes les régions mutuellement orthogonales détectent les mêmes événements et leur répondent « simultanément » (parfois par entrelacement) Module 3 : Spécification des exigences

50. Exercice: Décrivez ce comportement CourseAttempt Studying lab done lab done Lab2 Lab1 project done Term Project pass Final Test fail Passed Failed Module 3 : Spécification des exigences