«SEG 3501» D. Amyot uOttawa SEG 3501- Module 3 Modélisation à l’aide de UML 2 Objectifs: ―Caractéristiques intéressantes de UML 2.x pour la modélisation.

Présentation au sujet: "«SEG 3501» D. Amyot uOttawa SEG 3501- Module 3 Modélisation à l’aide de UML 2 Objectifs: ―Caractéristiques intéressantes de UML 2.x pour la modélisation."— Transcription de la présentation:

1 «SEG 3501» D. Amyot uOttawa SEG 3501- Module 3 Modé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 )http://www.developpez.com

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

3 «SEG 3501» D. Amyot uOttawa Dilbert et les normes… Module 3 : Spécification des exigences3

4 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences4 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

5 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences5 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)

6 «SEG 3501» D. Amyot uOttawa Diagrammes de classes UML 2 Module 3 : Spécification des exigences6

7 «SEG 3501» D. Amyot uOttawa 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 exigences7

8 «SEG 3501» D. Amyot uOttawa Plusieurs notations existent. Voici celle de Chen (1976) Module 3 : Spécification des exigences8 Notation ERM

9 «SEG 3501» D. Amyot uOttawa Diagrammes de classe UML Module 3 : Spécification des exigences9

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

11 «SEG 3501» D. Amyot uOttawa 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 exigences11

12 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences12 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

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

14 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences14 Aspect Triggered behavior (code) Predicate F.R1 Une solution partielle: les Aspects (pour votre info…) ClassA R1 elements ClassC R1 elements ClassG R1 elements ClassF R1 elements R2 elements R3 elements RN elements advicepointcut Terminologie basée sur AspectJ: www.eclipse.org/aspectj intertype declaration ClassB R1 elements (identifies joinpoints where advice is executed) R1 elements

15 «SEG 3501» D. Amyot uOttawa Diagrammes d’activités UML 2 (pour votre information seulement) Module 3 : Spécification des exigences15

16 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences16 Éléments des diagrammes d’activités Décrivent les aspects dynamiques a l’aide de flots d’activités

17 «SEG 3501» D. Amyot uOttawa Exemples de partitions Module 3 : Spécification des exigences17

18 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences18 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.

19 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences19 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

20 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences20 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)

21 «SEG 3501» D. Amyot uOttawa Diagrammes de séquences UML 2 Module 3 : Spécification des exigences21

22 «SEG 3501» D. Amyot uOttawa Éléments de base Module 3 : Spécification des exigences22

23 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences23 Interactions synchrones ou asynchrones

24 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences24 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.

25 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences25 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.

26 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences26 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é.

27 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences27 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.

28 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences28 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)http://www.developpez.com http://www.developpez.net/forums/

29 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences29 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.

30 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences30 Fragments combinés: imbriqués

31 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences31 Aspects temporels (pour votre info)

32 «SEG 3501» D. Amyot uOttawa Diagrammes d’états UML 2 Module 3 : Spécification des exigences32

33 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences33 Décrivent la vue dynamique d’un objet (états et transitions) Diagrammes d’états

34 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences34 Sorties et actions Des sorties peuvent être générées lors de transitions: on off Lamp On print(”on”) print(”on”) Lamp Off off on Automate de Moore on off Lamp On Lamp Off off print(”on”) on/print(”on”) Automate de Mealy

35 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences35 Variables (états « étendus ») off on Lamp On Lamp Off off on/ctr := ctr + 1 ctr : Integer

36 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences36 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. time threshold

37 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences37 top Notation de base UML ReadyReady stop /ctr := 0stop ÉtatÉtat DéclancheurDéclancheur ActionAction PseudoétatinitialPseudoétatinitial TransitionTransition État final DoneDone État “top”

38 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences38 Actions d’entrée/sortie d’état (Entry et Exit)LampOnLampOn entry/lamp.on(); exit/lamp.off();e1 e2

39 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences39 Séquence d’actions résultante: printf(“exiting”); printf(“exiting”); printf(“to off”); printf(“to off”); lamp.off(); lamp.off(); Séquence d’actions résultante: printf(“exiting”); printf(“exiting”); printf(“to off”); printf(“to off”); lamp.off(); lamp.off(); Ordre des actions Actions de sortie: préfix d’une transition Actions de sortie: postfix d’une transition printf(“exiting”);printf(“needless”);lamp.off();printf(“exiting”);printf(“needless”);lamp.off(); off/printf(“needless”); off/printf(“to off”); LampOffLampOff entry/lamp.off(); exit/printf(“exiting”);LampOnLampOnentry/lamp.on(); exit/printf(“exiting”);

40 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences40 ErrorError 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 do/alarm.ring(); Activité “do”

41 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences41 Gardes (conditions) Les gardes (expressions booléennes) ne doivent pas avoir d’effets de bord. Exécution conditionnelle de transitions.SellingSellingUnhappyUnhappy HappyHappy bid /sell bid [(value >= 100) & (value < 200)] /sell bid /sell bid [value >= 200] /sell bid /reject bid [value < 100] /reject

42 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences42 Machines à états hiérarchiques États composés, pour gérer la complexité LampFlashingLampFlashingflash/ 1sec/ 1sec/ FlashOffFlashOff entry/lamp.off()FlashOnFlashOnentry/lamp.on() off/LampOffLampOffentry/lamp.off() LampOnLampOn entry/lamp.on() on/ on/ on/

43 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences43 LampFlashingLampFlashing 1sec/ 1sec/ FlashOffFlashOff entry/lamp.off()FlashOnFlashOnentry/lamp.on() off/LampOffLampOffentry/lamp.off() LampOnLampOn entry/lamp.on() on/ Transitions de groupeflash/ on/ Transition par défaut vers Le pseudoétat initial Transition par défaut vers Le pseudoétat initial Transition de groupe

44 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences44 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 termineCommittingCommittingPhase1Phase1 Phase2Phase2 CommitDoneCommitDone transition de complétion (sans déclencheur) transition de complétion (sans déclencheur)

45 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences45 LampFlashingLampFlashing off/ FlashOffFlashOff FlashOnFlashOn 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 on/

46 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences46 Ordre des actions: exemple plus complexeS1exit/exS1S1exit/exS1 S11exit/exS11S11exit/exS11 S2entry/enS2S2entry/enS2 S21entry/enS21S21entry/enS21/initS2 E/actE Séquence d’exécution d’actions: exS11  exS1  actE  enS2  initS2  enS21

47 «SEG 3501» D. Amyot uOttawa Exercice: Que fait cette machine? Comment pourrait-elle être améliorée? Module 3 : Spécification des exigences47

48 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences48 Régions orthogonales Combine plusieurs perspectives simultanément Child Adult Retiree age Poor Rich financialStatus Poor RichfinancialStatusChild Adult Retireeage

49 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences49 OutlawOutlaw LawAbidingLawAbidingPoorPoor RichRich financialStatuslegalStatus 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) robBank/robBank/

50 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences50 Exercice: Décrivez ce comportement CourseAttempt Studying Lab1 Lab2 lab done Term Project Final Tes t project done pass fail Failed Passed

51 «SEG 3501» D. Amyot uOttawa Exercices Module 3 : Spécification des exigences51 En ingénierie des exigences, les machines à états sont très utiles pour déterminer le cycle de vie de certains documents ou artifacts À l’aide de machines à états UML, décrivez le cycle de vie: ―D’une demande d’exemption de prérequis à un cours de l’Université d’Ottawa ―D’un « bogue » logiciel dans un système de gestion d’erreurs tel que Bugzilla.

52 «SEG 3501» D. Amyot uOttawa Module 3 : Spécification des exigences52 Conclusion…