520 likes | 736 Views
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
E N D
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)
É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!
Dilbert et les normes… Module 3 : Spécification des exigences
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
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
Diagrammes de classes UML 2 Module 3 : Spécification des exigences
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
Notation ERM • Plusieurs notations existent. • Voici celle de Chen (1976) Module 3 : Spécification des exigences
Diagrammes de classe UML Module 3 : Spécification des exigences
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
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
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
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
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
Diagrammes d’activités UML 2(pour votre information seulement) Module 3 : Spécification des exigences
É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
Exemples de partitions Module 3 : Spécification des exigences
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
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
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
Diagrammes de séquences UML 2 Module 3 : Spécification des exigences
Éléments de base Module 3 : Spécification des exigences
Interactions synchrones ou asynchrones Module 3 : Spécification des exigences
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
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
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
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
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
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
Fragments combinés: imbriqués Module 3 : Spécification des exigences
Aspects temporels (pour votre info) Module 3 : Spécification des exigences
Diagrammes d’états UML 2 Module 3 : Spécification des exigences
Diagrammes d’états Décrivent la vue dynamique d’un objet (états et transitions) Module 3 : Spécification des exigences
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
on Lamp On on/ctr := ctr + 1 off off Lamp Off Variables (états « étendus ») ctr : Integer Module 3 : Spécification des exigences
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
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
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
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
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
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
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
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
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
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
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: exS11exS1 actE enS2 initS2 enS21 Module 3 : Spécification des exigences
Exercice: Que fait cette machine? • Comment pourrait-elle être améliorée? Module 3 : Spécification des exigences
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
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
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