Vous êtes sur la page 1sur 142

UML 2

De l'apprentissage la pratique Par Laurent AUDIBERT

Date de publication : 31 octobre 2006 Dernire mise jour : 12 janvier 2009

Les techniques de programmation n'ont cess de progresser depuis l'poque de la programmation par cartes perfores nos jours. Cette volution a toujours t dicte par le besoin de concevoir et de maintenir des applications toujours plus complexes. Ainsi, la programmation par cartes perfores a-t-elle fait place l'assembleur, puis la programmation structure et, enfin, la programmation oriente objet. La technologie objet est donc la consquence ultime de la modularisation dicte par la matrise de la conception et de la maintenance d'applications toujours plus complexes. Cette nouvelle technique de programmation a ncessit la conception de nouvelles mthodes de modlisation. UML (Unified Modeling Language en anglais) s'impose aujourd'hui comme le langage de modlisation objet standardis pour la conception des logiciels. La version finalise, largement enrichie et corrige de cette premire bauche de cours est parue, dans la collection Info+ chez les ditions Ellipses, sous le titre UML 2 - de l'apprentissage la pratique (cours et exercices). Voici ce que la version publie apporte par rapport la prsente version en ligne : de nombreuses amliorations (corrections, illustrations, exemples). En fait, seulement 20 % de la version dite se retrouve l'identique dans la version en ligne ; de nouvelles notions (Design Patterns, introduction aux principales mthodes de dveloppement, diagramme de structures composites). La version dite est pratiquement deux fois plus volumineuse que la version en ligne ; des sances de travaux dirigs et de travaux pratiques accompagnes de corrigs complets et dtaills ; une prsentation bien plus agrable sous la forme d'un vrai livre.

Le livre "UML 2 - de l'apprentissage la pratique" Le livre chez Amazon Le livre la FNAC

UML 2 par Laurent AUDIBERT

Avant-propos................................................................................................................................................................ 8 1 - Chapitre 1 Introduction la modlisation objet..................................................................................................... 9 1-1 - Le gnie logiciel............................................................................................................................................ 9 1-1-1 - L'informatisation.................................................................................................................................... 9 1-1-2 - Les logiciels.......................................................................................................................................... 9 1-1-3 - Le gnie logiciel....................................................................................................................................9 1-1-4 - Notion de qualit pour un logiciel.......................................................................................................10 1-2 - Modlisation, cycles de vie et mthodes.................................................................................................... 11 1-2-1 - Pourquoi et comment modliser ?......................................................................................................11 1-2-1-a - Qu'est-ce qu'un modle ?.......................................................................................................... 11 1-2-1-b - Pourquoi modliser ?..................................................................................................................12 1-2-1-c - Qui doit modliser ?................................................................................................................... 12 1-2-1-d - Matrise d'ouvrage et matrise d'uvre......................................................................................13 1-2-2 - Le cycle de vie d'un logiciel............................................................................................................... 13 1-2-3 - Modles de cycles de vie d'un logiciel............................................................................................... 14 1-2-3-a - Modle de cycle de vie en cascade.......................................................................................... 14 1-2-3-b - Modle de cycle de vie en V..................................................................................................... 15 1-2-3-c - Modle de cycle de vie en spirale............................................................................................. 15 1-2-3-d - Modle par incrment................................................................................................................ 16 1-2-4 - Mthodes d'analyse et de conception................................................................................................ 16 1-3 - De la programmation structure l'approche oriente objet...................................................................... 17 1-3-1 - Mthodes fonctionnelles ou structures............................................................................................. 17 1-3-2 - L'approche oriente objet................................................................................................................... 17 1-3-3 - Approche fonctionnelle vs approche objet..........................................................................................18 1-3-4 - Concepts importants de l'approche objet........................................................................................... 19 1-3-4-a - Notion de classe.........................................................................................................................19 1-3-4-b - Encapsulation............................................................................................................................. 19 1-3-4-c - Hritage, spcialisation, gnralisation et polymorphisme.........................................................19 1-3-4-d - Agrgation.................................................................................................................................. 19 1-3-5 - Historique la programmation par objets............................................................................................. 20 1-4 - UML............................................................................................................................................................. 20 1-4-1 - Introduction..........................................................................................................................................20 1-4-2 - Histoire des modlisations par objets.................................................................................................20 1-4-3 - UML en uvre....................................................................................................................................21 1-4-3-a - Diagramme de cas d'utilisation.................................................................................................. 22 1-4-3-b - Diagramme de classes...............................................................................................................22 1-4-3-c - Diagramme d'objets....................................................................................................................22 1-4-3-d - Diagramme d'tats-transitions.................................................................................................... 22 1-4-3-e - Diagramme d'activits................................................................................................................ 22 1-4-3-f - Diagramme de squence et de communication..........................................................................22 1-4-4 - Comment prsenter un modle UML ?.............................................................................................. 22 2 - Chapitre 2 Diagramme de cas d'utilisation (Use Case Diagram)........................................................................ 23 2-1 - Introduction.................................................................................................................................................. 23 2-2 - lments des diagrammes de cas d'utilisation........................................................................................... 23 2-2-1 - Acteur.................................................................................................................................................. 23 2-2-2 - Cas d'utilisation................................................................................................................................... 24 2-2-3 - Reprsentation d'un diagramme de cas d'utilisation.......................................................................... 25 2-3 - Relations dans les diagrammes de cas d'utilisation................................................................................... 25 2-3-1 - Relations entre acteurs et cas d'utilisation......................................................................................... 25 2-3-1-a - Relation d'association.................................................................................................................25 2-3-1-b - Multiplicit................................................................................................................................... 25 2-3-1-c - Acteurs principaux et secondaires............................................................................................. 26 2-3-1-d - Cas d'utilisation interne.............................................................................................................. 26 2-3-2 - Relations entre cas d'utilisation.......................................................................................................... 26 2-3-2-a - Types et reprsentations............................................................................................................26 2-3-2-b - Relation d'inclusion.....................................................................................................................27 2-3-2-c - Relation d'extension................................................................................................................... 27 2-3-2-d - Relation de gnralisation..........................................................................................................27
-2-

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

2-3-3 - Relations entre acteurs.......................................................................................................................28 2-4 - Notions gnrales du langage UML............................................................................................................28 2-4-1 - Paquetage........................................................................................................................................... 28 2-4-2 - Espace de noms................................................................................................................................. 29 2-4-3 - Classeur.............................................................................................................................................. 29 2-4-4 - Strotype........................................................................................................................................... 29 2-4-5 - Note.....................................................................................................................................................29 2-5 - Modlisation des besoins avec UML.......................................................................................................... 30 2-5-1 - Comment identifier les acteurs ?........................................................................................................ 30 2-5-2 - Comment recenser les cas d'utilisation ?........................................................................................... 31 2-5-3 - Description textuelle des cas d'utilisation........................................................................................... 31 2-5-4 - Remarques..........................................................................................................................................32 2-5-4-a - Concernant les relations dans les cas d'utilisation.................................................................... 32 2-5-4-b - Concernant les cas d'utilisation..................................................................................................32 2-5-4-c - Les Use case Realization...........................................................................................................32 3 - Chapitre 3 Diagramme de classes (Class Diagram)........................................................................................... 33 3-1 - Introduction.................................................................................................................................................. 33 3-2 - Les classes..................................................................................................................................................33 3-2-1 - Notions de classe et d'instance de classe......................................................................................... 33 3-2-2 - Caractristiques d'une classe............................................................................................................. 34 3-2-3 - Reprsentation graphique...................................................................................................................34 3-2-4 - Encapsulation, visibilit, interface....................................................................................................... 35 3-2-5 - Nom d'une classe............................................................................................................................... 36 3-2-5-a - Mtalangage des syntaxes........................................................................................................ 36 3-2-6 - Les attributs........................................................................................................................................ 37 3-2-6-a - Attributs de la classe..................................................................................................................37 3-2-6-b - Attributs de classe......................................................................................................................37 3-2-6-c - Attributs drivs..........................................................................................................................37 3-2-7 - Les mthodes..................................................................................................................................... 37 3-2-7-a - Mthode de la classe.................................................................................................................37 3-2-7-b - Mthode de classe..................................................................................................................... 38 3-2-7-c - Mthodes et classes abstraites..................................................................................................38 3-2-8 - Classe active.......................................................................................................................................38 3-3 - Relations entre classes............................................................................................................................... 39 3-3-1 - Notion d'association............................................................................................................................ 39 3-3-2 - Terminaison d'association................................................................................................................... 39 3-3-2-a - Propritaire d'une terminaison d'association..............................................................................39 3-3-2-b - Une terminaison d'association est une proprit....................................................................... 40 3-3-3 - Association binaire et n-aire............................................................................................................... 40 3-3-3-a - Association binaire..................................................................................................................... 40 3-3-3-b - Association n-aire....................................................................................................................... 41 3-3-4 - Multiplicit ou cardinalit.....................................................................................................................41 3-3-5 - Navigabilit..........................................................................................................................................42 3-3-6 - Qualification.........................................................................................................................................43 3-3-7 - Classe-association.............................................................................................................................. 44 3-3-7-a - Dfinition et reprsentation........................................................................................................ 44 3-3-7-b - Classe-association pour plusieurs associations.........................................................................44 3-3-7-c - Autoassociation sur classe-association......................................................................................44 3-3-7-d - Liens multiples............................................................................................................................45 3-3-7-e - quivalences.............................................................................................................................. 45 3-3-7-f - Classe-association, association n-aire ou association qualifie ?...............................................46 3-3-8 - Agrgation et composition.................................................................................................................. 47 3-3-8-a - Agrgation.................................................................................................................................. 47 3-3-8-b - Composition................................................................................................................................48 3-3-9 - Gnralisation et Hritage.................................................................................................................. 48 3-3-10 - Dpendance...................................................................................................................................... 49 3-4 - 3.4 Interfaces...............................................................................................................................................49 3-5 - 3.5 Diagramme d'objets (object diagram)................................................................................................... 50
-3-

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

3-5-1 - Prsentation........................................................................................................................................ 50 3-5-2 - Reprsentation.................................................................................................................................... 51 3-5-3 - Relation de dpendance d'instanciation............................................................................................. 52 3-6 - laboration et implmentation d'un diagramme de classes........................................................................52 3-6-1 - laboration d'un diagramme de classes.............................................................................................52 3-6-2 - Implmentation en Java......................................................................................................................53 3-6-2-a - Classe.........................................................................................................................................53 3-6-2-b - Classe avec attributs et oprations............................................................................................53 3-6-2-c - Classe abstraite..........................................................................................................................53 3-6-2-d - Interface......................................................................................................................................54 3-6-2-e - Hritage simple.......................................................................................................................... 54 3-6-2-f - Ralisation d'une interface par une classe................................................................................. 54 3-6-2-g - Association bidirectionnelle 1 vers 1..........................................................................................54 3-6-2-h - Association unidirectionnelle 1 vers 1........................................................................................55 3-6-2-i - Association bidirectionnelle 1 vers N.......................................................................................... 55 3-6-2-j - Association unidirectionnelle 1 vers plusieurs.............................................................................56 3-6-2-k - Association 1 vers N.................................................................................................................. 56 3-6-2-l - Agrgations..................................................................................................................................56 3-6-2-m - Composition...............................................................................................................................56 3-6-3 - Implmentation en SQL...................................................................................................................... 57 3-6-3-a - Introduction................................................................................................................................. 57 3-6-3-b - Classe avec attributs..................................................................................................................57 3-6-3-c - Association 1 vers 1...................................................................................................................57 3-6-3-d - Association 1 vers plusieurs...................................................................................................... 58 3-6-3-e - Association plusieurs vers plusieurs.......................................................................................... 58 3-6-3-f - Classe-association plusieurs vers plusieurs............................................................................... 58 3-6-3-g - Hritage...................................................................................................................................... 59 4 - Chapitre 4 Langage de contraintes objet (Object Constraint Langage : OCL).................................................... 60 4-1 - Expression des contraintes en UML........................................................................................................... 60 4-1-1 - Introduction..........................................................................................................................................60 4-1-2 - criture des contraintes...................................................................................................................... 60 4-1-3 - Reprsentation des contraintes et contraintes prdfinies.................................................................61 4-2 - Intrt d'OCL............................................................................................................................................... 62 4-2-1 - OCL - Introduction.............................................................................................................................. 62 4-2-1-a - QuesacOCL ?............................................................................................................................. 62 4-2-1-b - Pourquoi OCL ?..........................................................................................................................62 4-2-2 - Illustration par l'exemple..................................................................................................................... 62 4-2-2-a - Mise en situation........................................................................................................................ 62 4-2-2-b - Diagramme de classes...............................................................................................................63 4-3 - Typologie des contraintes OCL................................................................................................................... 65 4-3-1 - Diagramme support des exemples illustratifs.....................................................................................65 4-3-2 - Contexte (context)...............................................................................................................................66 4-3-2-a - Syntaxe.......................................................................................................................................66 4-3-2-b - Exemple......................................................................................................................................66 4-3-3 - Invariants (inv).................................................................................................................................... 66 4-3-3-a - Syntaxe.......................................................................................................................................66 4-3-3-b - Exemple......................................................................................................................................66 4-3-4 - Prconditions et postconditions (pre, post)........................................................................................ 67 4-3-4-a - Syntaxe.......................................................................................................................................67 4-3-4-b - Exemple......................................................................................................................................67 4-3-5 - Rsultat d'une mthode (body).......................................................................................................... 67 4-3-5-a - Syntaxe.......................................................................................................................................67 4-3-5-b - Exemple......................................................................................................................................68 4-3-6 - Dfinition d'attributs et de mthodes (def et letin).......................................................................... 68 4-3-6-a - Syntaxe de letin...................................................................................................................... 68 4-3-6-b - Syntaxe de def........................................................................................................................... 68 4-3-6-c - Exemple...................................................................................................................................... 68 4-3-7 - Initialisation (init) et volution des attributs (derive)........................................................................... 68
-4-

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

4-3-7-a - Syntaxe.......................................................................................................................................69 4-3-7-b - Exemple......................................................................................................................................69 4-4 - Types et oprations utilisables dans les expressions OCL.........................................................................69 4-4-1 - Types et oprateurs prdfinis........................................................................................................... 69 4-4-2 - Types du modle UML....................................................................................................................... 70 4-4-3 - OCL est un langage typ................................................................................................................... 70 4-4-4 - Collections...........................................................................................................................................70 4-5 - Accs aux caractristiques et aux objets....................................................................................................71 4-5-1 - Accs aux attributs et aux oprations (self)....................................................................................... 71 4-5-2 - Navigation via une association........................................................................................................... 72 4-5-3 - Navigation via une association qualifie............................................................................................ 72 4-5-4 - Navigation vers une classe association............................................................................................. 73 4-5-5 - Navigation depuis une classe association..........................................................................................73 4-5-6 - Accder une caractristique redfinie (oclAsType()).......................................................................73 4-5-7 - Oprations prdfinies sur tous les objets......................................................................................... 74 4-5-7-a - Opration oclIsTypeOf................................................................................................................74 4-5-7-b - Opration oclIsKindOf................................................................................................................ 74 4-5-7-c - Opration oclIsNew.................................................................................................................... 74 4-5-7-d - Opration oclInState...................................................................................................................74 4-5-8 - Opration sur les classes................................................................................................................... 75 4-6 - Oprations sur les collections..................................................................................................................... 75 4-6-1 - Introduction : . , -> , :: et self...............................................................................................75 4-6-2 - Oprations de base sur les collections.............................................................................................. 75 4-6-2-a - Oprations de base sur les collections...................................................................................... 75 4-6-2-b - Oprations de base sur les ensembles (Set)............................................................................ 76 4-6-2-c - Exemples.................................................................................................................................... 77 4-6-3 - Opration sur les lments d'une collection.......................................................................................77 4-6-3-a - Syntaxe gnrale....................................................................................................................... 77 4-6-3-b - Opration select et reject........................................................................................................... 78 4-6-3-c - Opration forAll et exists............................................................................................................ 78 4-6-3-d - Opration collect........................................................................................................................ 79 4-6-4 - Rgles de prcdence des oprateurs.............................................................................................. 79 4-7 - Exemples de contraintes............................................................................................................................. 79 5 - Chapitre 5 Diagramme d'tats-transitions (State machine diagram)................................................................... 81 5-1 - Introduction au formalisme.......................................................................................................................... 81 5-1-1 - Prsentation........................................................................................................................................ 81 5-1-2 - Notion d'automate tats finis........................................................................................................... 81 5-1-3 - Diagrammes d'tats-transitions...........................................................................................................82 5-2 - tat...............................................................................................................................................................82 5-2-1 - Les deux acceptions du terme tat.................................................................................................... 82 5-2-1-a - tat dans un diagrammes d'tats-transitions............................................................................. 82 5-2-1-b - tat d'un objet, ou du diagramme d'tats-transitions (i.e. tat global)....................................... 83 5-2-2 - tat initial et final................................................................................................................................ 83 5-2-2-a - tat initial....................................................................................................................................83 5-2-2-b - tat final..................................................................................................................................... 83 5-3 - vnement...................................................................................................................................................83 5-3-1 - Notion d'vnement............................................................................................................................ 83 5-3-2 - vnement de type signal (signal)..................................................................................................... 84 5-3-3 - vnement d'appel (call).................................................................................................................... 84 5-3-4 - vnement de changement (change)................................................................................................ 84 5-3-5 - vnement temporel (after ou when)................................................................................................. 85 5-4 - Transition..................................................................................................................................................... 85 5-4-1 - Dfinition et syntaxe........................................................................................................................... 85 5-4-2 - Condition de garde............................................................................................................................. 85 5-4-3 - Effet d'une transition........................................................................................................................... 85 5-4-4 - Transition externe............................................................................................................................... 86 5-4-5 - Transition d'achvement..................................................................................................................... 86 5-4-6 - Transition interne................................................................................................................................ 86
-5-

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

5-5 - Point de choix..............................................................................................................................................87 5-5-1 - Point de jonction................................................................................................................................. 87 5-5-2 - Point de dcision................................................................................................................................ 88 5-6 - tats composites......................................................................................................................................... 89 5-6-1 - Prsentation........................................................................................................................................ 89 5-6-2 - Transition.............................................................................................................................................90 5-6-3 - tat historique..................................................................................................................................... 90 5-6-4 - Interface : les points de connexion.....................................................................................................91 5-6-5 - Concurrence........................................................................................................................................92 6 - Chapitre 6 Diagramme d'activits (Activity diagram)........................................................................................... 94 6-1 - Introduction au formalisme.......................................................................................................................... 94 6-1-1 - Prsentation........................................................................................................................................ 94 6-1-2 - Utilisation courante............................................................................................................................. 94 6-2 - Activit et Transition.................................................................................................................................... 94 6-2-1 - Action (action)..................................................................................................................................... 94 6-2-2 - Activit (activity).................................................................................................................................. 96 6-2-3 - Groupe d'activits (activity group)...................................................................................................... 96 6-2-4 - Nud d'activit (activity node)........................................................................................................... 96 6-2-5 - Transition.............................................................................................................................................98 6-3 - Nud excutable (executable node).......................................................................................................... 98 6-3-1 - Nud d'action.....................................................................................................................................98 6-3-2 - Nud d'activit structure (structured activity node)......................................................................... 99 6-4 - Nud de contrle (control node)................................................................................................................99 6-4-1 - Nud initial.......................................................................................................................................100 6-4-2 - Nud final........................................................................................................................................ 100 6-4-2-a - Nud de fin d'activit.............................................................................................................. 101 6-4-2-b - Nud de fin de flot.................................................................................................................. 101 6-4-3 - Nud de dcision et de fusion........................................................................................................ 101 6-4-3-a - Nud de dcision (decision node).......................................................................................... 101 6-4-3-b - Nud de fusion (merge node).................................................................................................101 6-4-4 - Nud de bifurcation et d'union........................................................................................................ 102 6-4-4-a - Nud de bifurcation ou de dbranchement (fork node).......................................................... 102 6-4-4-b - Nud d'union ou de jointure (join node)................................................................................. 102 6-5 - Nud d'objet............................................................................................................................................. 102 6-5-1 - Introduction........................................................................................................................................102 6-5-2 - Pin d'entre ou de sortie.................................................................................................................. 102 6-5-3 - Pin de valeur.....................................................................................................................................103 6-5-4 - Flot d'objets.......................................................................................................................................103 6-5-5 - Nud tampon central....................................................................................................................... 103 6-5-6 - Nud de stockage des donnes..................................................................................................... 104 6-6 - Partitions.................................................................................................................................................... 104 6-7 - Exceptions................................................................................................................................................. 106 7 - Chapitre 7 Diagrammes d'interaction (Interaction diagram).............................................................................. 107 7-1 - Prsentation du formalisme.......................................................................................................................107 7-1-1 - Introduction........................................................................................................................................107 7-1-2 - Classeur structur............................................................................................................................. 108 7-1-3 - Collaboration..................................................................................................................................... 108 7-1-4 - Interactions et lignes de vie..............................................................................................................109 7-1-5 - Reprsentation gnrale...................................................................................................................110 7-2 - Diagramme de communication (Communication diagram)....................................................................... 110 7-2-1 - Reprsentation des lignes de vie..................................................................................................... 110 7-2-2 - Reprsentation des connecteurs...................................................................................................... 110 7-2-3 - Reprsentation des messages......................................................................................................... 111 7-3 - Diagramme de squence (Sequence diagram)........................................................................................ 111 7-3-1 - Reprsentation des lignes de vie..................................................................................................... 111 7-3-2 - Reprsentation des messages......................................................................................................... 112 7-3-2-a - Messages asynchrones............................................................................................................112 7-3-2-b - Messages synchrones..............................................................................................................112
-6-

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

7-3-2-c - Messages de cration et destruction d'instance...................................................................... 113 7-3-2-d - vnements et messages........................................................................................................113 7-3-2-e - Syntaxe des messages et des rponses................................................................................. 113 7-3-2-f - Message perdu et trouv.......................................................................................................... 114 7-3-2-g - Porte......................................................................................................................................... 115 7-3-2-h - Excution de mthode et objet actif........................................................................................ 115 7-3-3 - Fragments d'interaction combins.................................................................................................... 115 7-3-3-a - Introduction............................................................................................................................... 115 7-3-3-b - Oprateur alt............................................................................................................................ 116 7-3-3-c - Oprateurs opt..........................................................................................................................116 7-3-3-d - Oprateur loop......................................................................................................................... 117 7-3-3-e - Oprateur par........................................................................................................................... 117 7-3-3-f - Oprateur strict..........................................................................................................................117 7-3-4 - Utilisation d'interaction...................................................................................................................... 118 8 - Chapitre 8 Diagrammes de composants (Component diagram) et Diagrammes de dploiement (Deployment diagram)................................................................................................................................................................... 118 8-1 - Introduction................................................................................................................................................ 118 8-2 - Diagrammes de composants.....................................................................................................................119 8-2-1 - Pourquoi des composants ?............................................................................................................. 119 8-2-2 - Notion de composant........................................................................................................................120 8-2-3 - Notion de port................................................................................................................................... 121 8-2-4 - Diagramme de composants..............................................................................................................121 8-3 - Diagramme de dploiement...................................................................................................................... 121 8-3-1 - Objectif du diagramme de dploiement............................................................................................121 8-3-2 - Reprsentation des nuds.............................................................................................................. 121 8-3-3 - Notion d'artefact (artifact)..................................................................................................................122 8-3-4 - Diagramme de dploiement..............................................................................................................123 9 - Chapitre 9 Mise en uvre d'UML..................................................................................................................... 123 Introduction......................................................................................................................................................... 123 9-1-1 - UML n'est pas une mthode............................................................................................................ 123 9-1-2 - Une mthode simple et gnrique................................................................................................... 124 9-2 - Identification des besoins.......................................................................................................................... 125 9-2-1 - Diagramme de cas d'utilisation.........................................................................................................125 9-2-2 - Diagrammes de squence systme................................................................................................. 125 9-2-3 - Maquette de l'IHM.............................................................................................................................126 9-3 - Phases d'analyse.......................................................................................................................................127 9-3-1 - Analyse du domaine : modle du domaine...................................................................................... 127 9-3-2 - Diagramme de classes participantes................................................................................................129 9-3-3 - Diagrammes d'activits de navigation.............................................................................................. 131 9-4 - Phase de conception.................................................................................................................................132 9-4-1 - Diagrammes d'interaction................................................................................................................. 132 9-4-2 - Diagramme de classes de conception............................................................................................. 133 Bibliographie.............................................................................................................................................................134 Index.........................................................................................................................................................................135

-7-

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Avant-propos
Les techniques de programmation n'ont cess de progresser depuis l'poque de la programmation en langage binaire (cartes perfores, switch) nos jours. Cette volution a toujours t dicte par le besoin de concevoir et de maintenir des applications toujours plus complexes. La programmation par cartes perfores, switch ou cblage (de 1800 1940) a ainsi fait place des techniques plus volues, comme l'assembleur (1947), avec l'arrive de l'ordinateur lectronique n des besoins de la guerre. Des langages plus volus ont ensuite vu le jour comme Fortran en 1956 ou Cobol en 1959. Jusque-l, les techniques de programmation taient bases sur le branchement conditionnel et inconditionnel (goto) rendant les programmes importants extrmement difficiles dvelopper, matriser et maintenir. La programmation structure (Pascal en 1970, C en 1972, Modula et Ada en 1979) a alors vu le jour et permis de dvelopper et de maintenir des applications toujours plus ambitieuses. L'algorithmique ne se suffisant plus elle seule la fin des annes 1970, le gnie logiciel est venu placer la mthodologie au cur du dveloppement logiciel. Des mthodes comme Merise (1978) se sont alors imposes. La taille des applications ne cessant de crotre, la programmation structure a galement rencontr ses limites, faisant alors place la programmation oriente objet (Simula 67 en 1967, Smalltalk en 1976, C++ en 1982, Java en 1995). La technologie objet est donc la consquence ultime de la modularisation dicte par la matrise de la conception et de la maintenance d'applications toujours plus complexes. Cette nouvelle technique de programmation a ncessit la conception de nouvelles mthodes de modlisation. UML (Unified Modeling Language en anglais, soit langage de modlisation objet unifi) est n de la fusion des trois mthodes qui s'imposaient dans le domaine de la modlisation objet au milieu des annes 1990 : OMT, Booch et OOSE. D'importants acteurs industriels (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys, etc.) s'associent alors l'effort et proposent UML 1.0 l'OMG (Object Management Group) qui l'accepte en novembre 1997 dans sa version 1.1. La version d'UML en cours en 2008 est UML 2.1.1 qui s'impose plus que jamais en tant que langage de modlisation standardis pour la modlisation des logiciels. Ce document constitue le support du cours d'UML 2 dispens aux tudiants du dpartement d'informatique de l'institut universitaire de technologie (IUT) de Villetaneuse en semestre dcal. Ce support a t ralis en utilisant les ouvrages cits en bibliographie. Il est en partie bas sur le livre de [7] qui constitue une bonne introduction au langage UML. Aomar Osmani est l'origine du cours d'UML dans notre IUT. [27], [5], [3] [26] et [16] ont galement t largement utiliss. [27] est un ouvrage de rfrence assez complet et contient un dictionnaire dtaill de la terminologie UML 2.0. [5], galement crit par les crateurs du langage UML, est un guide d'apprentissage compltant bien le premier ouvrage. [16] est un cours d'UML 2.0 bien expliqu et plus complet et dtaill que [7], mais, en contrepartie, moins accessible. [3] constitue une approche pratique et critique d'UML trs intressante. [25] constitue une excellente approche concrte d'UML comportant des exercices corrigs de trs bonne facture que nous reprenons parfois dans les travaux dirigs de ce cours. Pascal Roques est probablement l'un des auteurs les plus prolifiques [23, 26, 24, 25] et comptents concernant la mise en uvre d'UML. Agrable lire, [28] s'intresse la place de l'informatique dans notre socit et plus particulirement dans l'entreprise. Enfin, diverses sources trouves sur Internet, inpuisable source d'information en perptuel renouvellement, m'ont galement t d'un grand secours. Parmi ces dernires, certaines sont incontournables, comme le cours de [21] ou encore le site [9].

-8-

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

1 - Chapitre 1 Introduction la modlisation objet 1-1 - Le gnie logiciel 1-1-1 - L'informatisation


L'informatisation est le phnomne le plus important de notre poque. Elle s'immisce maintenant dans la plupart des objets de la vie courante et ce, que ce soit dans l'objet proprement dit (1) , ou bien dans le processus de conception ou de fabrication de cet objet. Actuellement, l'informatique est au cur de toutes les grandes entreprises. Le systme d'information d'une entreprise est compos de matriels et de logiciels. Plus prcisment, les investissements dans ce systme d'information se rpartissent gnralement de la manire suivante : 20 % pour le matriel et 80 % pour le logiciel. En effet, depuis quelques annes, la fabrication du matriel est assure par quelques fabricants seulement. Ce matriel est relativement fiable et le march est standardis. Les problmes lis l'informatique sont essentiellement des problmes de logiciel.

1-1-2 - Les logiciels


Un logiciel ou une application est un ensemble de programmes, qui permet un ordinateur ou un systme informatique d'assurer une tche ou une fonction en particulier (exemple : logiciel de comptabilit, logiciel de gestion des prts). Les logiciels, suivant leur taille, peuvent tre dvelopps par une personne seule, une petite quipe, ou un ensemble d'quipes coordonnes. Le dveloppement de grands logiciels par de grandes quipes pose d'importants problmes de conception et de coordination. Or, le dveloppement d'un logiciel est une phase absolument cruciale qui monopolise l'essentiel du cot d'un produit (2) et conditionne sa russite et sa prennit. En 1995, une tude du Standish Group dressait un tableau accablant de la conduite des projets informatiques. Reposant sur un chantillon reprsentatif de 365 entreprises, totalisant 8 380 applications, cette tude tablissait que : 16,2% seulement des projets taient conformes aux prvisions initiales, 52,7% avaient subi des dpassements en cot et dlai d'un facteur 2 3 avec diminution du nombre des fonctions offertes, 31,1% ont t purement abandonns durant leur dveloppement.

Pour les grandes entreprises (qui lancent proportionnellement davantage de gros projets), le taux de succs est de 9% seulement, 37% des projets sont arrts en cours de ralisation, 50% aboutissent hors dlai et hors budget. L'examen des causes de succs et d'chec est instructif : la plupart des checs proviennent non de l'informatique, mais de la matrise d'ouvrage (3) (i.e. le client). Pour ces raisons, le dveloppement de logiciels dans un contexte professionnel suit souvent des rgles strictes encadrant la conception et permettant le travail en groupe et la maintenance (4) du code. Ainsi, une nouvelle discipline est ne : le gnie logiciel.

1-1-3 - Le gnie logiciel


Le gnie logiciel est un domaine de recherche qui a t dfini (fait rare) du 7 au 11 octobre 1968, GarmischPartenkirchen, sous le parrainage de l'OTAN. Il a pour objectif de rpondre un problme qui s'nonait en deux constatations : d'une part le logiciel n'tait pas fiable, d'autre part, il tait incroyablement difficile de raliser dans des dlais prvus des logiciels satisfaisant leur cahier des charges.

-9-

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

L'objectif du gnie logiciel est d'optimiser le cot de dveloppement du logiciel. L'importance d'une approche mthodologique s'est impose la suite de la crise de l'industrie du logiciel la fin des annes 1970. Cette crise de l'industrie du logiciel tait principalement due : l'augmentation des cots ; les difficults de maintenance et d'volution ; la non-fiabilit ; le non-respect des spcifications ; le non-respect des dlais.

La maintenance est devenue une facette trs importante du cycle de vie d'un logiciel. En effet, une enqute effectue aux .-U. en 1986 auprs de 55 entreprises rvle que 53% du budget total d'un logiciel est affect la maintenance. Ce cot est rparti comme suit : 34% maintenance volutive (modification des spcifications initiales) ; 10% maintenance adaptative (nouvel environnement, nouveaux utilisateurs) ; 17% maintenance corrective (correction des bogues) ; 16% maintenance perfective (amliorer les performances sans changer les spcifications) ; 6% assistance aux utilisateurs ; 6% contrle qualit ; 7% organisation/suivi ; 4% divers.

Pour apporter une rponse tous ces problmes, le gnie logiciel s'intresse particulirement la manire dont le code source d'un logiciel est spcifi puis produit. Ainsi, le gnie logiciel touche au cycle de vie des logiciels : l'analyse du besoin, l'laboration des spcifications, la conceptualisation, le dveloppement, la phase de test, la maintenance.

Les projets relatifs l'ingnierie logicielle sont gnralement de grande envergure et dpassent souvent les 10 000 lignes de code. C'est pourquoi ces projets ncessitent une quipe de dveloppement bien structure. La gestion de projet se retrouve naturellement intimement lie au gnie logiciel.

1-1-4 - Notion de qualit pour un logiciel


En gnie logiciel, divers travaux ont men la dfinition de la qualit du logiciel en termes de facteurs, qui dpendent, entre autres, du domaine de l'application et des outils utiliss. Parmi ces derniers nous pouvons citer :

Validit :

aptitude d'un produit logiciel remplir exactement ses fonctions, dfinies par le cahier des charges et les spcifications.

Fiabilit ou robustesse :

aptitude d'un produit logiciel fonctionner dans des conditions anormales.

Extensibilit (maintenance) :

facilit avec laquelle un logiciel se prte sa maintenance, c'est--dire une modification ou une extension des fonctions qui lui sont demandes.

- 10 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Rutilisabilit : Compatibilit : Efficacit :

aptitude d'un logiciel tre rutilis, en tout ou en partie, dans de nouvelles applications.

facilit avec laquelle un logiciel peut tre combin avec d'autres logiciels.

Utilisation optimale des ressources matrielles.

Portabilit :

facilit avec laquelle un logiciel peut tre transfr sous diffrents environnements matriels et logiciels.

Vrifiabilit : Intgrit :

facilit de prparation des procdures de test.

aptitude d'un logiciel protger son code et ses donnes contre des accs non autoriss.

Facilit d'emploi :

facilit d'apprentissage, d'utilisation, de prparation des donnes, d'interprtation des erreurs et de rattrapage en cas d'erreur d'utilisation.

Ces facteurs sont parfois contradictoires, le choix des compromis doit s'effectuer en fonction du contexte.

1-2 - Modlisation, cycles de vie et mthodes 1-2-1 - Pourquoi et comment modliser ? 1-2-1-a - Qu'est-ce qu'un modle ?
Un modle est une reprsentation abstraite et simplifie (i.e. qui exclut certains dtails), d'une entit (phnomne, processus, systme, etc.) du monde rel en vue de le dcrire, de l'expliquer ou de le prvoir. Modle est synonyme de thorie, mais avec une connotation pratique : un modle, c'est une thorie oriente vers l'action qu'elle doit servir. Concrtement, un modle permet de rduire la complexit d'un phnomne en liminant les dtails qui n'influencent pas son comportement de manire significative. Il reflte ce que le concepteur croit important pour la comprhension et la prdiction du phnomne modlis. Les limites du phnomne modlis dpendant des objectifs du modle. Voici quelques exemples de modles :

Modle mtorologique

partir de donnes d'observation (satellite), il permet de prvoir les conditions climatiques pour les jours venir.

Modle conomique

peut par exemple permettre de simuler l'volution de cours boursiers en fonction d'hypothses macroconomiques (volution du chmage, taux de croissance).

Modle dmographique

dfinit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des tudes statistiques, d'augmenter l'impact de dmarches commerciales, etc.

- 11 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Plans
Les plans sont des modles qui donnent une vue d'ensemble du systme concern. Par exemple, dans le btiment, pour la construction d'un immeuble, il faut pralablement laborer de nombreux plans : plans d'implantation du btiment dans son environnement ; plans gnraux du btiment et de sa structure ; plans dtaills des diffrents locaux, bureaux, appartements plans des cblages lectriques ; plans d'coulements des eaux, etc.

Les trois premiers exemples sont des modles que l'on qualifie de prdictifs. Le dernier, plus conceptuel, possde diffrents niveaux de vues comme la plupart des modles en gnie logiciel.

1-2-1-b - Pourquoi modliser ?


Modliser un systme avant sa ralisation permet de mieux comprendre le fonctionnement du systme. C'est galement un bon moyen de matriser sa complexit et d'assurer sa cohrence. Un modle est un langage commun, prcis, qui est connu par tous les membres de l'quipe et il est donc, ce titre, un vecteur privilgi pour communiquer. Cette communication est essentielle pour aboutir une comprhension commune aux diffrentes parties prenantes (notamment entre la matrise d'ouvrage et la matrise d'uvre informatique) et prcise d'un problme donn. Dans le domaine de l'ingnierie du logiciel, le modle permet de mieux rpartir les tches et d'automatiser certaines d'entre elles. C'est galement un facteur de rduction des cots et des dlais. Par exemple, les plateformes de modlisation savent maintenant exploiter les modles pour faire de la gnration de code (au moins au niveau du squelette) voire des allers-retours entre le code et le modle sans perte d'information. Le modle est enfin indispensable pour assurer un bon niveau de qualit et une maintenance efficace. En effet, une fois mise en production, l'application va devoir tre maintenue, probablement par une autre quipe et, qui plus est, pas ncessairement de la mme socit que celle ayant cr l'application. Le choix du modle a donc une influence capitale sur les solutions obtenues. Les systmes non triviaux sont mieux modliss par un ensemble de modles indpendants. Selon les modles employs, la dmarche de modlisation n'est pas la mme.

1-2-1-c - Qui doit modliser ?


La modlisation est souvent faite par la matrise d'uvre informatique (MOE). C'est malencontreux, car les priorits de la MOE rsident dans le fonctionnement de la plateforme informatique et non dans les processus de l'entreprise. Il est prfrable que la modlisation soit ralise par la matrise d'ouvrage (MOA) de sorte que le mtier soit matre de ses propres concepts. La MOE doit intervenir dans le modle lorsque, aprs avoir dfini les concepts du mtier, on doit introduire les contraintes propres la plateforme informatique. Il est vrai que certains mtiers, dont les priorits sont oprationnelles, ne disposent pas toujours de la capacit d'abstraction et de la rigueur conceptuelle ncessaires la formalisation. La professionnalisation de la MOA a pour but de les doter de ces comptences. Cette professionnalisation rside essentiellement dans l'aptitude modliser le systme d'information du mtier : le matre mot est modlisation. Lorsque le modle du systme d'information est de bonne qualit, sobre, clair, stable, la matrise d'uvre peut travailler dans de bonnes conditions. Lorsque cette professionnalisation a lieu, elle modifie les rapports avec l'informatique et dplace la frontire des responsabilits, ce qui contrarie parfois les informaticiens dans un premier temps, avant qu'ils n'en voient apparatre les bnfices.

- 12 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

1-2-1-d - Matrise d'ouvrage et matrise d'uvre Matre d'ouvrage (MOA) :


Le MOA est une personne morale (entreprise, direction, etc.), une entit de l'organisation. Ce n'est jamais une personne.

Matre d'uvre (MOE) :

Le MOE est une personne morale (entreprise, direction, etc.) garante de la bonne ralisation technique des solutions. Il a, lors de la conception du SI, un devoir de conseil vis--vis du MOA, car le SI doit tirer le meilleur parti des possibilits techniques.

Le MOA est client du MOE qui il passe commande d'un produit ncessaire son activit. Le MOE fournit ce produit ; soit il le ralise lui-mme, soit il passe commande un ou plusieurs fournisseurs ( entreprises ) qui laborent le produit sous sa direction. La relation MOA et MOE est dfinie par un contrat qui prcise leurs engagements mutuels. Lorsque le produit est compliqu, il peut tre ncessaire de faire appel plusieurs fournisseurs. Le MOE assure leur coordination ; il veille la cohrence des fournitures et leur compatibilit. Il coordonne l'action des fournisseurs en contrlant la qualit technique, en assurant le respect des dlais fixs par le MOA et en minimisant les risques. Le MOE est responsable de la qualit technique de la solution. Il doit, avant toute livraison au MOA, procder aux vrifications ncessaires ( recette usine ).

1-2-2 - Le cycle de vie d'un logiciel


Le cycle de vie d'un logiciel (en anglais software lifecycle), dsigne toutes les tapes du dveloppement d'un logiciel, de sa conception sa disparition. L'objectif d'un tel dcoupage est de permettre de dfinir des jalons intermdiaires permettant la validation du dveloppement logiciel, c'est--dire la conformit du logiciel avec les besoins exprims, et la vrification du processus de dveloppement, c'est--dire l'adquation des mthodes mises en uvre. L'origine de ce dcoupage provient du constat que les erreurs ont un cot d'autant plus lev qu'elles sont dtectes tardivement dans le processus de ralisation. Le cycle de vie permet de dtecter les erreurs au plus tt et ainsi de matriser la qualit du logiciel, les dlais de sa ralisation et les cots associs. Le cycle de vie du logiciel comprend gnralement au minimum les tapes suivantes :

Analyse des besoins et faisabilit

c'est--dire l'expression, le recueil et la formalisation des besoins du demandeur (le client) et de l'ensemble des contraintes, puis l'estimation de la faisabilit de ces besoins ;

Spcifications ou conception gnrale Conception dtaille

il s'agit de l'laboration des spcifications de l'architecture gnrale du logiciel ;

cette tape consiste dfinir prcisment chaque sous-ensemble du logiciel ;

Codage (Implmentation ou programmation)

c'est la traduction dans un langage de programmation des fonctionnalits dfinies lors de phases de conception ;

- 13 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Tests unitaires

ils permettent de vrifier individuellement que chaque sous-ensemble du logiciel est implment conformment aux spcifications ;

Intgration

l'objectif est de s'assurer de l'interfaage des diffrents lments (modules) du logiciel. Elle fait l'objet de tests d'intgration consigns dans un document ;

Qualification (ou recette) Documentation

c'est--dire la vrification de la conformit du logiciel aux spcifications initiales ;

elle vise produire les informations ncessaires pour l'utilisation du logiciel et pour des dveloppements ultrieurs ;

Mise en production Maintenance

c'est le dploiement sur site du logiciel ;

elle comprend toutes les actions correctives (maintenance corrective) et volutives (maintenance volutive) sur le logiciel.

La squence et la prsence de chacune de ces activits dans le cycle de vie dpendent du choix d'un modle de cycle de vie entre le client et l'quipe de dveloppement. Le cycle de vie permet de prendre en compte, en plus des aspects techniques, l'organisation et les aspects humains.

1-2-3 - Modles de cycles de vie d'un logiciel 1-2-3-a - Modle de cycle de vie en cascade

Figure 1.1 : Modle du cycle de vie en cascade.

- 14 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Le modle de cycle de vie en cascade (cf. figure 1.1) a t mis au point ds 1966, puis formalis aux alentours de 1970. Dans ce modle le principe est trs simple : chaque phase se termine une date prcise par la production de certains documents ou logiciels. Les rsultats sont dfinis sur la base des interactions entre tapes, ils sont soumis une revue approfondie et on ne passe la phase suivante que s'ils sont jugs satisfaisants. Le modle original ne comportait pas de possibilit de retour en arrire. Celle-ci a t rajoute ultrieurement sur la base qu'une tape ne remet en cause que l'tape prcdente, ce qui, dans la pratique, s'avre insuffisant. L'inconvnient majeur du modle de cycle de vie en cascade est que la vrification du bon fonctionnement du systme est ralise trop tardivement : lors de la phase d'intgration, ou pire, lors de la mise en production.

1-2-3-b - Modle de cycle de vie en V

Figure 1.2 : Modle du cycle de vie en V. Le modle en V (cf. figure 1.2 ) demeure actuellement le cycle de vie le plus connu et certainement le plus utilis. Il s'agit d'un modle en cascade dans lequel le dveloppement des tests et du logiciel sont effectus de manire synchrone. Le principe de ce modle est qu'avec toute dcomposition doit tre dcrite la recomposition et que toute description d'un composant est accompagne de tests qui permettront de s'assurer qu'il correspond sa description. Ceci rend explicite la prparation des dernires phases (validation-vrification) par les premires (construction du logiciel), et permet ainsi d'viter un cueil bien connu de la spcification du logiciel : noncer une proprit qu'il est impossible de vrifier objectivement aprs la ralisation. Cependant, ce modle souffre toujours du problme de la vrification trop tardive du bon fonctionnement du systme.

1-2-3-c - Modle de cycle de vie en spirale


Propos par B. Boehm en 1988, ce modle est beaucoup plus gnral que le prcdent. Il met l'accent sur l'activit d'analyse des risques : chaque cycle de la spirale se droule en quatre phases : 1 2 3 4 Dtermination, partir des rsultats des cycles prcdents, ou de l'analyse prliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ; Analyse des risques, valuation des alternatives et, ventuellement maquettage ; Dveloppement et vrification de la solution retenue, un modle classique (cascade ou en V) peut tre utilis ici ; Revue des rsultats et vrification du cycle suivant.

- 15 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

L'analyse prliminaire est affine au cours des premiers cycles. Le modle utilise des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de dveloppement classique.

1-2-3-d - Modle par incrment


Dans les modles prcdents, un logiciel est dcompos en composants dvelopps sparment et intgrs la fin du processus. Dans les modles par incrment un seul ensemble de composants est dvelopp la fois : des incrments viennent s'intgrer un noyau de logiciel dvelopp au pralable. Chaque incrment est dvelopp selon l'un des modles prcdents. Les avantages de ce type de modle sont les suivants : chaque dveloppement est moins complexe ; les intgrations sont progressives ; il est ainsi possible de livrer et de mettre en service chaque incrment ; il permet un meilleur lissage du temps et de l'effort de dveloppement grce la possibilit de recouvrement (paralllisation) des diffrentes phases.

Les risques de ce type de modle sont les suivants : remettre en cause les incrments prcdents ou pire le noyau ; ne pas pouvoir intgrer de nouveaux incrments.

Les noyaux, les incrments ainsi que leurs interactions doivent donc tre spcifis globalement, au dbut du projet. Les incrments doivent tre aussi indpendants que possible, fonctionnellement, mais aussi sur le plan du calendrier du dveloppement.

1-2-4 - Mthodes d'analyse et de conception


Les mthodes d'analyse et de conception fournissent une mthodologie et des notations standards qui aident concevoir des logiciels de qualit. Il existe diffrentes manires pour classer ces mthodes, dont :

La distinction entre composition et dcomposition :

Elle met en opposition d'une part les mthodes ascendantes qui consistent construire un logiciel par composition partir de modules existants et, d'autre part, les mthodes descendantes qui dcomposent rcursivement le systme jusqu' arriver des modules programmables simplement ;

La distinction entre fonctionnelle (dirige par le traitement) et oriente objet :

Dans la stratgie fonctionnelle (galement qualifie de structure) un systme est vu comme un ensemble hirarchique d'units en interaction, ayant chacune une fonction clairement dfinie. Les fonctions disposent d'un tat local, mais le systme a un tat partag, qui est centralis et accessible par l'ensemble des fonctions. Les stratgies orientes objet considrent qu'un systme est un ensemble d'objets interagissants. Chaque objet dispose d'un ensemble d'attributs dcrivant son tat et l'tat du systme est dcrit (de faon dcentralise) par l'tat de l'ensemble.

- 16 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

1-3 - De la programmation structure l'approche oriente objet 1-3-1 - Mthodes fonctionnelles ou structures

Figure 1.3 : Reprsentation graphique d'une approche fonctionnelle. Les mthodes fonctionnelles (galement qualifies de mthodes structures) trouvent leur origine dans les langages procduraux. Elles mettent en vidence les fonctions assurer et proposent une approche hirarchique descendante et modulaire. Ces mthodes utilisent intensivement les raffinements successifs pour produire des spcifications dont l'essentiel est sous forme de notation graphique en diagrammes de flots de donnes. Le plus haut niveau reprsente l'ensemble du problme (sous forme d'activit, de donnes ou de processus, selon la mthode). Chaque niveau est ensuite dcompos en respectant les entres/sorties du niveau suprieur. La dcomposition se poursuit jusqu' arriver des composants matrisables (cf. figure 1.3). L'approche fonctionnelle dissocie le problme de la reprsentation des donnes, du problme du traitement de ces donnes. Sur la figure 1.3, les donnes du problme sont reprsentes sur la gauche. Des flches transversales matrialisent la manipulation de ces donnes par des sous-fonctions. Cet accs peut-tre direct (c'est parfois le cas quand les donnes sont regroupes dans une base de donnes), ou peut tre ralis par le passage de paramtre depuis le programme principal. La SADT (Structured Analysis Design Technique) est probablement la mthode d'analyse fonctionnelle et de gestion de projets la plus connue. Elle permet non seulement de dcrire les tches du projet et leurs interactions, mais aussi de dcrire le systme que le projet vise tudier, crer ou modifier, en mettant notamment en vidence les parties qui constituent le systme, la finalit et le fonctionnement de chacune, ainsi que les interfaces entre ces diverses parties. Le systme ainsi modlis n'est pas une simple collection d'lments indpendants, mais une organisation structure de ceux-ci dans une finalit prcise. En rsum, l'architecture du systme est dicte par la rponse au problme (i.e. la fonction du systme).

1-3-2 - L'approche oriente objet


L'approche considre le logiciel comme une collection d'objets dissocis, identifis et possdant des caractristiques. Une caractristique est soit un attribut (i.e. une donne caractrisant l'tat de l'objet), soit une entit comportementale de l'objet (i.e. une fonction). La fonctionnalit du logiciel merge alors de l'interaction entre les diffrents objets qui le constituent. L'une des particularits de cette approche est qu'elle rapproche les donnes et leurs traitements associs au sein d'un unique objet. Comme nous venons de le dire, un objet est caractris par plusieurs notions :

- 17 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

L'identit

l'objet possde une identit, qui permet de le distinguer des autres objets, indpendamment de son tat. On construit gnralement cette identit grce un identifiant dcoulant naturellement du problme (par exemple un produit pourra tre repr par un code, une voiture par un numro de srie, etc.) ;

Les attributs

il s'agit des donnes caractrisant l'objet. Ce sont des variables stockant des informations sur l'tat de l'objet ;

Les mthodes

les mthodes d'un objet caractrisent son comportement, c'est--dire l'ensemble des actions (appeles oprations) que l'objet est mme de raliser. Ces oprations permettent de faire ragir l'objet aux sollicitations extrieures (ou d'agir sur les autres objets). De plus, les oprations sont troitement lies aux attributs, car leurs actions peuvent dpendre des valeurs des attributs, ou bien les modifier.

La difficult de cette modlisation consiste crer une reprsentation abstraite, sous forme d'objets, d'entits ayant une existence matrielle (chien, voiture, ampoule, personne) ou bien virtuelle (client, temps). La Conception Oriente Objet (COO) est la mthode qui conduit des architectures logicielles fondes sur les objets du systme, plutt que sur la fonction qu'il est cens raliser. En rsum, l'architecture du systme est dicte par la structure du problme.

1-3-3 - Approche fonctionnelle vs approche objet


Selon la thse de Church-Turing, tout langage de programmation non trivial quivaut une machine de Turing. Il en rsulte que tout programme qu'il est possible d'crire dans un langage pourrait galement tre crit dans n'importe quel autre langage. Ainsi, tout ce que l'on fait avec un langage de programmation par objets pourrait tre fait en programmation imprative. La diffrence entre une approche fonctionnelle et une approche objet n'est donc pas d'ordre logique, mais pratique. L'approche structure privilgie la fonction comme moyen d'organisation du logiciel. Ce n'est pas pour cette raison que l'approche objet est une approche non fonctionnelle. En effet, les mthodes d'un objet sont des fonctions. Ce qui diffrencie sur le fond l'approche objet de l'approche fonctionnelle, c'est que les fonctions obtenues l'issue de la mise en uvre de l'une ou l'autre mthode sont distinctes. L'approche objet est une approche oriente donne. Dans cette approche, les fonctions se dduisent d'un regroupement de champs de donnes formant une entit cohrente, logique, tangible et surtout stable quant au problme trait. L'approche structure classique privilgie une organisation des donnes postrieure la dcouverte des grandes, puis petites fonctions qui les dcomposent, l'ensemble constituant les services qui rpondent aux besoins. En approche objet, l'volution des besoins aura le plus souvent tendance se prsenter comme un changement de l'interaction des objets. S'il faut apporter une modification aux donnes, seul l'objet incrimin (encapsulant cette donne) sera modifi. Toutes les fonctions modifier sont bien identifies : elles se trouvent dans ce mme objet : ce sont ses mthodes. Dans une approche structure, l'volution des besoins entrane souvent une dgnrescence, ou une profonde remise en question, de la topologie typique de la figure 1.3, car la dcomposition des units de traitement (du programme principal aux sous-fonctions) est directement dicte par ces besoins. D'autre part, une modification des donnes entrane gnralement une modification d'un nombre important de fonctions parpilles et difficiles identifier dans la hirarchie de cette dcomposition. En fait, la modularit n'est pas antinomique de l'approche structure. Les modules rsultant de la dcomposition objet sont tout simplement diffrents de ceux manant de l'approche structure. Les units de traitement, et surtout leur dpendance dans la topologie de la figure 1.3 sont initialement bonnes. C'est leur rsistance au temps, contrairement aux modules objet, qui est source de problme. La structure d'un logiciel issue d'une approche structure est beaucoup moins mallable, adaptable, que celle issue d'une approche objet.

- 18 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Ainsi la technologie objet est la consquence ultime de la modularisation du logiciel, dmarche qui vise matriser sa production et son volution. Mais malgr cette continuit logique les langages objet ont apport en pratique un profond changement dans l'art de la programmation : ils impliquent en effet un changement de l'attitude mentale du programmeur.

1-3-4 - Concepts importants de l'approche objet


Dans la section 1.3.2, nous avons dit que l'approche objet rapproche les donnes et leurs traitements. Mais cette approche ne fait pas que a, d'autres concepts importants sont spcifiques cette approche et participent la qualit du logiciel.

1-3-4-a - Notion de classe


Tout d'abord, introduisons la notion de classe. Une classe est un type de donnes abstrait qui prcise des caractristiques (attributs et mthodes) communes toute une famille d'objets et qui permet de crer (instancier) des objets possdant ces caractristiques. Les autres concepts importants qu'il nous faut maintenant introduire sont l'encapsulation, l'hritage et l'agrgation.

1-3-4-b - Encapsulation
L'encapsulation consiste masquer les dtails d'implmentation d'un objet, en dfinissant une interface. L'interface est la vue externe d'un objet, elle dfinit les services accessibles (offerts) aux utilisateurs de l'objet. L'encapsulation facilite l'volution d'une application, car elle stabilise l'utilisation des objets : on peut modifier l'implmentation des attributs d'un objet sans modifier son interface, et donc la faon dont l'objet est utilis. L'encapsulation garantit l'intgrit des donnes, car elle permet d'interdire, ou de restreindre, l'accs direct aux attributs des objets.

1-3-4-c - Hritage, spcialisation, gnralisation et polymorphisme


L'hritage est un mcanisme de transmission des caractristiques d'une classe (ses attributs et mthodes) vers une sous-classe. Une classe peut tre spcialise en d'autres classes, afin d'y ajouter des caractristiques spcifiques ou d'en adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise, afin de regrouper les caractristiques communes d'un ensemble de classes. Ainsi, la spcialisation et la gnralisation permettent de construire des hirarchies de classes. L'hritage peut tre simple ou multiple. L'hritage vite la duplication et encourage la rutilisation. Le polymorphisme reprsente la facult d'une mthode pouvoir s'appliquer des objets de classes diffrentes. Le polymorphisme augmente la gnricit, et donc la qualit, du code.

1-3-4-d - Agrgation
Il s'agit d'une relation entre deux classes, spcifiant que les objets d'une classe sont des composants de l'autre classe. Une relation d'agrgation permet donc de dfinir des objets composs d'autres objets. L'agrgation permet donc d'assembler des objets de base, afin de construire des objets plus complexes.

- 19 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

1-3-5 - Historique la programmation par objets


Les premiers langages de programmation qui ont utilis des objets sont Simula I (1961-64) et Simula 67 (1967), conus par les informaticiens norvgiens Ole-Johan Dahl et Kristan Nygaard. Simula 67 contenait dj les objets, les classes, l'hritage, l'encapsulation, etc. Alan Kay, du PARC de Xerox, avait utilis Simula dans les annes 1960. Il ralisa en 1976 Smalltalk qui reste, aux yeux de certains programmeurs, le meilleur langage de programmation par objets. Bjarne Stroustrup a mis au point C++, une extension du langage C permettant la programmation oriente objet, aux Bell Labs d'AT&T en 1982. C++ deviendra le langage le plus utilis par les programmeurs professionnels. Il arrivera maturit en 1986, sa standardisation ANSI / ISO date de 1997. Java est lanc par Sun en 1995. Comme il prsente plus de scurit que C++, il deviendra le langage favori de certains programmeurs professionnels.

1-4 - UML 1-4-1 - Introduction


La description de la programmation par objets a fait ressortir l'tendue du travail conceptuel ncessaire : dfinition des classes, de leurs relations, des attributs et mthodes, des interfaces, etc. Pour programmer une application, il ne convient pas de se lancer tte baisse dans l'criture du code : il faut d'abord organiser ses ides, les documenter, puis organiser la ralisation en dfinissant les modules et tapes de la ralisation. C'est cette dmarche antrieure l'criture que l'on appelle modlisation ; son produit est un modle. Les spcifications fournies par la matrise d'ouvrage en programmation imprative taient souvent floues : les articulations conceptuelles (structures de donnes, algorithmes de traitement) s'exprimant dans le vocabulaire de l'informatique, le modle devait souvent tre labor par celle-ci. L'approche objet permet en principe la matrise d'ouvrage de s'exprimer de faon prcise selon un vocabulaire qui, tout en transcrivant les besoins du mtier, pourra tre immdiatement compris par les informaticiens. En principe seulement, car la modlisation demande aux matrises d'ouvrage une comptence et un professionnalisme qui ne sont pas aujourd'hui rpandus.

1-4-2 - Histoire des modlisations par objets


Les mthodes utilises dans les annes 1980 pour organiser la programmation imprative (notamment Merise) taient fondes sur la modlisation spare des donnes et des traitements. Lorsque la programmation par objets prend de l'importance au dbut des annes 1990, la ncessit d'une mthode qui lui soit adapte devient vidente. Plus de cinquante mthodes apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, etc.), mais aucune ne parvient s'imposer. En 1994, le consensus se fait autour de trois mthodes : OMT de James Rumbaugh (General Electric) fournit une reprsentation graphique des aspects statique, dynamique et fonctionnel d'un systme ; OOD de Grady Booch, dfinie pour le Department of Defense, introduit le concept de paquetage (package) ; OOSE d'Ivar Jacobson (Ericsson) fonde l'analyse sur la description des besoins des utilisateurs (cas d'utilisation, ou use cases).

Chaque mthode avait ses avantages et ses partisans. Le nombre de mthodes en comptition s'tait rduit, mais le risque d'un clatement subsistait : la profession pouvait se diviser entre ces trois mthodes, crant autant de continents intellectuels qui auraient du mal communiquer.

- 20 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

vnement considrable et presque miraculeux, les trois gourous qui rgnaient chacun sur l'une des trois mthodes se mirent d'accord pour dfinir une mthode commune qui fdrerait leurs apports respectifs (on les surnomme depuis the Amigos ). UML (Unified Modeling Language) est n de cet effort de convergence. L'adjectif unified est l pour marquer qu'UML unifie, et donc remplace. En fait, et comme son nom l'indique, UML n'a pas l'ambition d'tre exactement une mthode : c'est un langage. L'unification a progress par tapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis d'accord pour construire une mthode unifie, Unified Method 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement du mot mthode par le mot langage, plus modeste). Les acteurs les plus importants dans le monde du logiciel s'associent alors l'effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys, etc.) et UML 1.0 est soumis l'OMG (5) . L'OMG adopte en novembre 1997 UML 1.1 comme langage de modlisation des systmes d'information objets. La version d'UML en cours en 2008 est UML 2.1.1 et les travaux d'amlioration se poursuivent. UML est donc non seulement un outil intressant, mais une norme qui s'impose en technologie objets et laquelle se sont rangs tous les grands acteurs du domaine, acteurs qui ont d'ailleurs contribu son laboration.

1-4-3 - UML en uvre


UML n'est pas une mthode (i.e. une description normative des tapes de la modlisation) : ses auteurs ont en effet estim qu'il n'tait pas opportun de dfinir une mthode en raison de la diversit des cas particuliers. Ils ont prfr se borner dfinir un langage graphique qui permet de reprsenter et de communiquer les divers aspects d'un systme d'information. Aux graphiques sont bien sr associs des textes qui expliquent leur contenu. UML est donc un mtalangage, car il fournit les lments permettant de construire le modle qui, lui, sera le langage du projet. Il est impossible de donner une reprsentation graphique complte d'un logiciel, ou de tout autre systme complexe, de mme qu'il est impossible de reprsenter entirement une statue ( trois dimensions) par des photographies ( deux dimensions). Mais il est possible de donner sur un tel systme des vues partielles, analogues chacune une photographie d'une statue, et dont la conjonction donnera une ide utilisable en pratique sans risque d'erreur grave. UML 2.0 comporte ainsi treize types de diagrammes reprsentant autant de vues distinctes pour reprsenter des concepts particuliers du systme d'information. Ils se rpartissent en deux grands groupes : Diagrammes structurels ou diagrammes statiques (UML Structure) diagramme de classes (Class diagram) diagramme d'objets (Object diagram) diagramme de composants (Component diagram) diagramme de dploiement (Deployment diagram) diagramme de paquetages (Package diagram) diagramme de structures composites (Composite structure diagram)

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) diagramme de cas d'utilisation (Use case diagram) diagramme d'activits (Activity diagram) diagramme d'tats-transitions (State machine diagram) Diagrammes d'interaction (Interaction diagram) diagramme de squence (Sequence diagram) diagramme de communication (Communication diagram) diagramme global d'interaction (Interaction overview diagram) diagramme de temps (Timing diagram)

Ces diagrammes, d'une utilit variable selon les cas, ne sont pas ncessairement tous produits l'occasion d'une modlisation. Les plus utiles pour la matrise d'ouvrage sont les diagrammes d'activits, de cas d'utilisation,
- 21 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

de classes, d'objets, de squence et d'tats-transitions. Les diagrammes de composants, de dploiement et de communication sont surtout utiles pour la matrise d'uvre qui ils permettent de formaliser les contraintes de la ralisation et la solution technique.

1-4-3-a - Diagramme de cas d'utilisation


Le diagramme de cas d'utilisation (cf. section 2) reprsente la structure des grandes fonctionnalits ncessaires aux utilisateurs du systme. C'est le premier diagramme du modle UML, celui o s'assure la relation entre l'utilisateur et les objets que le systme met en uvre.

1-4-3-b - Diagramme de classes


Le diagramme de classes (cf. section 3) est gnralement considr comme le plus important dans un dveloppement orient objet. Il reprsente l'architecture conceptuelle du systme : il dcrit les classes que le systme utilise, ainsi que leurs liens, que ceux-ci reprsentent un embotage conceptuel (hritage) ou une relation organique (agrgation).

1-4-3-c - Diagramme d'objets


Le diagramme d'objets (cf. section 3.5) permet d'clairer un diagramme de classes en l'illustrant par des exemples. Il est, par exemple, utilis pour vrifier l'adquation d'un diagramme de classes diffrents cas possibles.

1-4-3-d - Diagramme d'tats-transitions


Le diagramme d'tats-transitions (cf. section 5) reprsente la faon dont voluent (i.e. cycle de vie) les objets appartenant une mme classe. La modlisation du cycle de vie est essentielle pour reprsenter et mettre en forme la dynamique du systme.

1-4-3-e - Diagramme d'activits


Le diagramme d'activits (cf. section 6) n'est autre que la transcription dans UML de la reprsentation du processus telle qu'elle a t labore lors du travail qui a prpar la modlisation : il montre l'enchanement des activits qui concourent au processus.

1-4-3-f - Diagramme de squence et de communication


Le diagramme de squence (cf. section 7.3) reprsente la succession chronologique des oprations ralises par un acteur. Il indique les objets que l'acteur va manipuler et les oprations qui font passer d'un objet l'autre. On peut reprsenter les mmes oprations par un diagramme de communication (cf. section 7.2), graphe dont les nuds sont des objets et les arcs (numrots selon la chronologie) les changes entre objets. En fait, diagramme de squence et diagramme de communication sont deux vues diffrentes, mais logiquement quivalentes (on peut construire l'une partir de l'autre) d'une mme chronologie. Ce sont des diagrammes d'interaction (section 7).

1-4-4 - Comment prsenter un modle UML ?


La prsentation d'un modle UML se compose de plusieurs documents crits en langage courant et d'un document formalis : elle ne doit pas se limiter au seul document formalis, car celui-ci est pratiquement incomprhensible si on le prsente seul. Un expert en UML sera capable dans certains cas de reconstituer les intentions initiales en lisant le modle, mais pas toujours ; et les experts en UML sont rares. Voici la liste des documents qui paraissent ncessaires :

- 22 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Prsentation stratgique :

elle dcrit pourquoi l'entreprise a voulu se doter de l'outil considr, les buts qu'elle cherche atteindre, le calendrier de ralisation prvu, etc. ;

Prsentation des processus de travail par lesquels la stratgie entend se raliser :

pour permettre au lecteur de voir comment l'application va fonctionner en pratique, elle doit tre illustre par une esquisse des crans qui seront affichs devant les utilisateurs de terrain ;

Explication des choix qui ont guid la modlisation formelle : Modle formel :

il s'agit de synthtiser, sous les yeux du lecteur, les discussions qui ont prsid ces choix ;

c'est le document le plus pais et le plus difficile lire. Il est prfrable de le prsenter sur l'Intranet de l'entreprise. En effet, les diagrammes peuvent tre alors quips de liens hypertextes permettant l'ouverture de diagrammes plus dtaills ou de commentaires.

On doit prsenter en premier le diagramme de cas d'utilisation qui montre l'enchanement des cas d'utilisation au sein du processus, enchanement immdiatement comprhensible ; puis le diagramme d'activits, qui montre le contenu de chaque cas d'utilisation ; puis le diagramme de squence, qui montre l'enchanement chronologique des oprations l'intrieur de chaque cas d'utilisation. Enfin, le diagramme de classes, qui est le plus prcis conceptuellement, mais aussi le plus difficile lire, car il prsente chacune des classes et leurs relations (agrgation, hritage, association, etc.).

2 - Chapitre 2 Diagramme de cas d'utilisation (Use Case Diagram) 2-1 - Introduction


Bien souvent, la matrise d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs besoins. C'est prcisment le rle des diagrammes de cas d'utilisation qui permettent de recueillir, d'analyser et d'organiser les besoins, et de recenser les grandes fonctionnalits d'un systme. Il s'agit donc de la premire tape UML d'analyse d'un systme. Un diagramme de cas d'utilisation capture le comportement d'un systme, d'un sous-systme, d'une classe ou d'un composant tel qu'un utilisateur extrieur le voit. Il scinde la fonctionnalit du systme en units cohrentes, les cas d'utilisation, ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le besoin des utilisateurs d'un systme, ils sont donc une vision oriente utilisateur de ce besoin au contraire d'une vision informatique. Il ne faut pas ngliger cette premire tape pour produire un logiciel conforme aux attentes des utilisateurs. Pour laborer les cas d'utilisation, il faut se fonder sur des entretiens avec les utilisateurs.

2-2 - lments des diagrammes de cas d'utilisation 2-2-1 - Acteur


Un acteur est l'idalisation d'un rle jou par une personne externe, un processus ou une chose qui interagit avec un systme. Il se reprsente par un petit bonhomme (figure 2.1) avec son nom (i.e. son rle) inscrit dessous.

- 23 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 2.1 : Exemple de reprsentation d'un acteur. Il est galement possible de reprsenter un acteur sous la forme d'un classeur (cf. section 2.4.3) strotyp (cf. section 2.4.4) << actor >> (figure 2.2).

Figure 2.2 : Exemple de reprsentation d'un acteur sous la forme d'un classeur.

2-2-2 - Cas d'utilisation


Un cas d'utilisation est une unit cohrente reprsentant une fonctionnalit visible de l'extrieur. Il ralise un service de bout en bout, avec un dclenchement, un droulement et une fin, pour l'acteur qui l'initie. Un cas d'utilisation modlise donc un service rendu par le systme, sans imposer le mode de ralisation de ce service. Un cas d'utilisation se reprsente par une ellipse (figure 2.3) contenant le nom du cas (un verbe l'infinitif), et optionnellement, au-dessus du nom, un strotype (cf. section 2.4.4).

Figure 2.3 : Exemple de reprsentation d'un cas d'utilisation. Dans le cas o l'on dsire prsenter les attributs ou les oprations du cas d'utilisation, il est prfrable de le reprsenter sous la forme d'un classeur strotyp << use case >> (figure 2.4). Nous reviendrons sur les notions d'attributs ou d'opration lorsque nous aborderons les diagrammes de classes et d'objets (section 3).

- 24 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 2.4 : Exemple de reprsentation d'un cas d'utilisation sous la forme d'un classeur.

2-2-3 - Reprsentation d'un diagramme de cas d'utilisation

Figure 2.5 : Exemple simplifi de diagramme de cas d'utilisation modlisant une borne d'accs une banque. Comme le montre la figure 2.5, la frontire du systme est reprsente par un cadre. Le nom du systme figure l'intrieur du cadre, en haut. Les acteurs sont l'extrieur et les cas d'utilisation l'intrieur.

2-3 - Relations dans les diagrammes de cas d'utilisation 2-3-1 - Relations entre acteurs et cas d'utilisation 2-3-1-a - Relation d'association

Figure 2.6 : Diagramme de cas d'utilisation reprsentant un logiciel de partage de fichiers. Une relation d'association est chemin de communication entre un acteur et un cas d'utilisation et est reprsent un trait continu (cf. figure 2.5 ou 2.6).

2-3-1-b - Multiplicit
Lorsqu'un acteur peut interagir plusieurs fois avec un cas d'utilisation, il est possible d'ajouter une multiplicit sur l'association du ct du cas d'utilisation. Le symbole * signifie plusieurs (figure 2.6), exactement n s'crit tout simplement n, n..m signifie entre n et m, etc. Prciser une multiplicit sur une relation n'implique pas ncessairement que les cas sont utiliss en mme temps.

- 25 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

La notion de multiplicit n'est pas propre au diagramme de cas d'utilisation. Nous en reparlerons dans le chapitre consacr au diagramme de classes section 3.3.4.

2-3-1-c - Acteurs principaux et secondaires


Un acteur est qualifi de principal pour un cas d'utilisation lorsque ce cas rend service cet acteur. Les autres acteurs sont alors qualifis de secondaires. Un cas d'utilisation a au plus un acteur principal. Un acteur principal obtient un rsultat observable du systme tandis qu'un acteur secondaire est sollicit pour des informations complmentaires. En gnral, l'acteur principal initie le cas d'utilisation par ses sollicitations. Le strotype << primary >> vient orner l'association reliant un cas d'utilisation son acteur principal, le strotype << secondary >> est utilis pour les acteurs secondaires (figure 2.6).

2-3-1-d - Cas d'utilisation interne


Quand un cas n'est pas directement reli un acteur, il est qualifi de cas d'utilisation interne.

2-3-2 - Relations entre cas d'utilisation

Figure 2.7 : Exemple de diagramme de cas d'utilisation.

2-3-2-a - Types et reprsentations


Il existe principalement deux types de relations : les dpendances strotypes, qui sont explicites par un strotype (les plus utiliss sont l'inclusion et l'extension) ; et la gnralisation/spcialisation.

Une dpendance se reprsente par une flche avec un trait pointill (figure 2.7). Si le cas A inclut ou tend le cas B, la flche est dirige de A vers B. Le symbole utilis pour la gnralisation est un flche avec un trait plein dont la pointe est un triangle ferm dsignant le cas le plus gnral (figure 2.7).

- 26 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

2-3-2-b - Relation d'inclusion


Un cas A inclut un cas B si le comportement dcrit par le cas A inclut le comportement du cas B : le cas A dpend de B. Lorsque A est sollicit, B l'est obligatoirement, comme une partie de A. Cette dpendance est symbolise par le strotype << include >> (figure 2.7). Par exemple, l'accs aux informations d'un compte bancaire inclut ncessairement une phase d'authentification avec un identifiant et un mot de passe (figure ). Les inclusions permettent essentiellement de factoriser une partie de la description d'un cas d'utilisation qui serait commune d'autres cas d'utilisation (cf. le cas S'authentifier de la figure 2.7). Les inclusions permettent galement de dcomposer un cas complexe en sous-cas plus simples (figure 2.8). Cependant, il ne faut surtout pas abuser de ce type de dcomposition : il faut viter de raliser du dcoupage fonctionnel d'un cas d'utilisation en plusieurs sous-cas d'utilisation pour ne pas retomber dans le travers de la dcomposition fonctionnelle. Attention galement au fait que, les cas d'utilisation ne s'enchanent pas, puisqu'il n'y a aucune reprsentation temporelle dans un diagramme de cas d'utilisation.

Figure 2.8 : Relations entre cas pour dcomposer un cas complexe.

2-3-2-c - Relation d'extension


La relation d'extension est probablement la plus utile, car elle a une smantique qui a un sens du point de vue mtier au contraire des deux autres qui sont plus des artifices d'informaticiens. On dit qu'un cas d'utilisation A tend un cas d'utilisation B lorsque le cas d'utilisation A peut tre appel au cours de l'excution du cas d'utilisation B. Excuter B peut ventuellement entraner l'excution de A : contrairement l'inclusion, l'extension est optionnelle. Cette dpendance est symbolise par le strotype << extend >> (figure 2.7). L'extension peut intervenir un point prcis du cas tendu. Ce point s'appelle le point d'extension. Il porte un nom, qui figure dans un compartiment du cas tendu sous la rubrique point d'extension, et est ventuellement associ une contrainte indiquant le moment o l'extension intervient. Une extension est souvent soumise condition. Graphiquement, la condition est exprime sous la forme d'une note. La figure 2.7 prsente l'exemple d'une banque o la vrification du solde du compte n'intervient que si la demande de retrait dpasse 20 euros.

2-3-2-d - Relation de gnralisation


Un cas A est une gnralisation d'un cas B si B est un cas particulier de A. Dans la figure 2.7, la consultation d'un compte via Internet est un cas particulier de la consultation. Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par le concept d'hritage dans les langages orients objet.

- 27 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

2-3-3 - Relations entre acteurs


La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une gnralisation d'un acteur B si l'acteur A peut tre substitu par l'acteur B. Dans ce cas, tous les cas d'utilisation accessibles A le sont aussi B, mais l'inverse n'est pas vrai. Le symbole utilis pour la gnralisation entre acteurs est une flche avec un trait plein dont la pointe est un triangle ferm dsignant l'acteur le plus gnral (comme nous l'avons dj vu pour la relation de gnralisation entre cas d'utilisation). Par exemple, la figure 2.9 montre que le directeur des ventes est un prpos aux commandes avec un pouvoir supplmentaire : en plus de pouvoir passer et suivre une commande, il peut grer le stock. Par contre, le prpos aux commandes ne peut pas grer le stock.

Figure 2.9 : Relations entre acteurs.

2-4 - Notions gnrales du langage UML


Les lments du langage UML que nous abordons ici ne sont pas spcifiques au diagramme de cas d'utilisation, mais sont gnraux. Nous avons dj utilis certains de ces lments dans ce chapitre et nous utiliserons les autres dans les chapitres qui suivent, notamment dans le chapitre sur les diagrammes de classes (section 3).

2-4-1 - Paquetage

Figure 2.10 : Reprsentations d'un paquetage. Un paquetage est un regroupement d'lments de modle et de diagrammes. Il permet ainsi d'organiser des lments de modlisation en groupes. Il peut contenir tout type d'lment de modle : des classes, des cas d'utilisation, des interfaces, des diagrammes et mme des paquetages imbriqus (dcomposition hirarchique). Un paquetage se reprsente comme un dossier avec son nom inscrit dedans (figure 2.10, diagramme de gauche). Il est possible de reprsenter explicitement le contenu d'un paquetage. Dans ce cas, le nom du paquetage est plac dans l'onglet (figure , diagramme de droite).

- 28 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Les lments contenus dans un paquetage doivent reprsenter un ensemble fortement cohrent et sont gnralement de mme nature et de mme niveau smantique. Tout lment n'appartient qu' un seul paquetage. Les paquetages constituent un mcanisme de gestion important des problmes de grande taille. Ils permettent d'viter les grands modles plats et de cloisonner des lments constitutifs d'un systme voluant des rythmes diffrents ou dvelopps par des quipes diffrentes. Il existe un paquetage racine unique, ventuellement anonyme, qui contient la totalit des modles d'un systme.

2-4-2 - Espace de noms


Les espaces de noms sont des paquetages, des classeurs, etc. On peut dterminer un lment nomm de faon unique par son nom qualifi, qui est constitu de la srie des noms des paquetages ou des autres espaces de noms depuis la racine jusqu' l'lment en question. Dans un nom qualifi, chaque espace de nom est spar par deux doubles points (::). Par exemple, si un paquetage B est inclus dans un paquetage A et contient une classe X, il faut crire A::B::X pour pouvoir utiliser la classe X en dehors du contexte du paquetage B.

2-4-3 - Classeur
Les paquetages et les relations de gnralisation ne peuvent avoir d'instance. D'une manire gnrale, les lments de modlisation pouvant en avoir sont reprsents dans des classeurs (6) . Plus important encore, un classeur est un lment de modle qui dcrit une unit structurelle ou comportementale. Un classeur modlise un concept discret qui dcrit un lment (i.e. objet) dot d'une identit (i.e. un nom), d'une structure ou d'un tat (i.e. des attributs), d'un comportement (i.e. des oprations), de relations et d'une structure interne facultative. Il peut participer des relations d'association, de gnralisation, de dpendance et de contrainte. On le dclare dans un espace de noms, comme un paquetage ou une autre classe. Un classeur se reprsente par un rectangle, en traits pleins, contenant ventuellement des compartiments. Les acteurs et les cas d'utilisation sont des classeurs. Tout au long de ce cours, nous retrouverons le terme de classeur, car cette notion englobe aussi les classes, les interfaces, les signaux, les nuds, les composants, les soussystmes, etc. Le type de classeur le plus important tant, bien videmment, la classe (cf. section 3).

2-4-4 - Strotype
Un strotype est une annotation s'appliquant sur un lment de modle. Il n'a pas de dfinition formelle, mais permet de mieux caractriser des varits d'un mme concept. Il permet donc d'adapter le langage des situations particulires. Il est reprsent par une chane de caractres entre guillemets (<< >>) dans, ou proximit du symbole de l'lment de modle de base. Par exemple, la figure 2.4 reprsente un cas d'utilisation par un rectangle. UML utilise aussi les rectangles pour reprsenter les classes (cf. section 3). La notation n'est cependant pas ambigu grce la prsence du strotype << use case >>.

2-4-5 - Note

- 29 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 2.11 : Exemple d'utilisation d'une note pour prciser que le solde d'un compte doit toujours tre positif. Une note contient une information textuelle comme un commentaire, un corps de mthode ou une contrainte. Graphiquement, elle est reprsente par un rectangle dont l'angle suprieur droit est pli. Le texte contenu dans le rectangle n'est pas contraint par UML. Une note n'indique pas explicitement le type d'lment qu'elle contient, toute l'intelligibilit d'une note doit tre contenue dans le texte mme. On peut relier une note l'lment qu'elle dcrit grce une ligne en pointills. Si elle dcrit plusieurs lments, on dessine une ligne vers chacun d'entre eux. L'exemple de la figure 2.11 montre une note exprimant une contrainte (cf. section 4.1) sur un attribut.

2-5 - Modlisation des besoins avec UML 2-5-1 - Comment identifier les acteurs ?
UML n'emploie pas le terme d'utilisateur, mais d'acteur. Les acteurs d'un systme sont les entits externes ce systme qui interagissent (saisie de donnes, rception d'information) avec lui. Les acteurs sont donc l'extrieur du systme et dialoguent avec lui. Ces acteurs permettent de cerner l'interface que le systme va devoir offrir son environnement. Oublier des acteurs ou en identifier de faux conduit donc ncessairement se tromper sur l'interface et donc la dfinition du systme produire. Il faut faire attention ne pas confondre acteurs et utilisateurs (utilisateur avec le sens de la personne physique qui va appuyer sur un bouton) d'un systme. D'une part parce que les acteurs incluent les utilisateurs humains, mais aussi les autres systmes informatiques ou hardware qui vont communiquer avec le systme. D'autre part parce qu'un acteur englobe tout une classe d'utilisateurs. Ainsi, plusieurs utilisateurs peuvent avoir le mme rle, et donc correspondre un mme acteur, et une mme personne physique peut jouer des rles diffrents vis--vis du systme, et donc correspondre plusieurs acteurs. Chaque acteur doit tre nomm. Ce nom doit reflter son rle, car un acteur reprsente un ensemble cohrent de rles jous vis--vis du systme. Pour trouver les acteurs d'un systme, il faut identifier quels sont les diffrents rles que vont devoir jouer ses utilisateurs (ex. : responsable clientle, responsable d'agence, administrateur, approbateur). Il faut galement s'intresser aux autres systmes avec lesquels le systme va devoir communiquer comme : les priphriques manipuls par le systme (imprimantes, hardware d'un distributeur de billets) ; des logiciels dj disponibles intgrer dans le projet ; des systmes informatiques externes au systme, mais qui interagissent avec lui, etc.

Pour faciliter la recherche des acteurs, on peut imaginer les frontires du systme. Tout ce qui est l'extrieur et qui interagit avec le systme est un acteur, tout ce qui est l'intrieur est une fonctionnalit raliser.

- 30 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Vrifiez que les acteurs communiquent bien directement avec le systme par mission ou rception de messages. Une erreur frquente consiste rpertorier en tant qu'acteur des entits externes qui n'interagissent pas directement avec le systme, mais uniquement par le biais d'un des vritables acteurs. Par exemple, l'htesse de caisse d'un magasin de grande distribution est un acteur pour la caisse enregistreuse, par contre, les clients du magasin ne correspondent pas un acteur, car ils n'interagissent pas directement avec la caisse.

2-5-2 - Comment recenser les cas d'utilisation ?


L'ensemble des cas d'utilisation doit dcrire exhaustivement les exigences fonctionnelles du systme. Chaque cas d'utilisation correspond donc une fonction mtier du systme, selon le point de vue d'un de ses acteurs. Aussi, pour identifier les cas d'utilisation, il faut se placer du point de vue de chaque acteur et dterminer comment et surtout pourquoi il se sert du systme. Il faut viter les redondances et limiter le nombre de cas en se situant un bon niveau d'abstraction. Trouver le bon niveau de dtail pour les cas d'utilisation est un problme difficile qui ncessite de l'exprience. Nommez les cas d'utilisation avec un verbe l'infinitif suivi d'un complment en vous plaant du point de vue de l'acteur et non pas de celui du systme. Par exemple, un distributeur de billets aura probablement un cas d'utilisation Retirer de l'argent et non pas Distribuer de l'argent. De par la nature fonctionnelle, et non objet, des cas d'utilisation, et en raison de la difficult de trouver le bon niveau de dtail, il faut tre trs vigilant pour ne pas retomber dans une dcomposition fonctionnelle descendante hirarchique. Un nombre trop important de cas d'utilisation est en gnral le symptme de ce type d'erreur. Dans tous les cas, il faut bien garder l'esprit qu'il n'y a pas de notion temporelle dans un diagramme de cas d'utilisation.

2-5-3 - Description textuelle des cas d'utilisation


Le diagramme de cas d'utilisation dcrit les grandes fonctions d'un systme du point de vue des acteurs, mais n'expose pas de faon dtaille le dialogue entre les acteurs et les cas d'utilisation. Bien que de nombreux diagrammes d'UML permettent de dcrire un cas, il est recommand de rdiger une description textuelle, car c'est une forme souple qui convient dans bien des situations. Une description textuelle couramment utilise se compose de trois parties. 1 La premire partie permet d'identifier le cas, elle doit contenir les informations qui suivent. Nom : utiliser une tournure l'infinitif (ex. : Rceptionner un colis). Objectif : une description rsume permettant de comprendre l'intention principale du cas d'utilisation. Cette partie est souvent renseigne au dbut du projet dans la phase de dcouverte des cas d'utilisation. Acteurs principaux : ceux qui vont raliser le cas d'utilisation (la relation avec le cas d'utilisation est illustre par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas d'utilisation). Acteurs secondaires : ceux qui ne font que recevoir des informations l'issue de la ralisation du cas d'utilisation. Dates : les dates de cration et de mise jour de la description courante.

- 31 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Responsable : le nom des responsables. Version : le numro de version. La deuxime partie contient la description du fonctionnement du cas sous la forme d'une squence de messages changs entre les acteurs et le systme. Elle contient toujours une squence nominale qui dcrit de droulement normal du cas. la squence nominale s'ajoutent frquemment des squences alternatives (des embranchements dans la squence nominale) et des squences d'exceptions (qui interviennent quand une erreur se produit). Les prconditions : elles dcrivent dans quel tat doit tre le systme (l'application) avant que ce cas d'utilisation puisse tre dclench. Des scnarii : ces scnarii sont dcrits sous la forme d'changes d'vnements entre l'acteur et le systme. On distingue le scnario nominal, qui se droule quand il n'y a pas d'erreur, des scnarii alternatifs qui sont les variantes du scnario nominal et enfin les scnarii d'exception qui dcrivent les cas d'erreurs. Des postconditions : elles dcrivent l'tat du systme l'issue des diffrents scnarii. La troisime partie de la description d'un cas d'utilisation est une rubrique optionnelle. Elle contient gnralement des spcifications non fonctionnelles (spcifications techniques). Elle peut ventuellement contenir une description des besoins en termes d'interface graphique.

2-5-4 - Remarques 2-5-4-a - Concernant les relations dans les cas d'utilisation
Il est important de noter que l'utilisation des relations n'est pas primordiale dans la rdaction des cas d'utilisation et donc dans l'expression du besoin. Ces relations peuvent tre utiles dans certains cas, mais une trop forte focalisation sur leur usage conduit souvent une perte de temps ou un usage fauss, pour une valeur ajoute, finalement, relativement faible.

2-5-4-b - Concernant les cas d'utilisation


Unanimement reconnus comme cantonns l'ingnierie des besoins, les diagrammes de cas d'utilisation ne peuvent tre qualifis de modlisations proprement parler. D'ailleurs, de nombreux lments descriptifs sont en langage naturel. De plus, ils ne correspondent pas stricto sensu une approche objet. En effet, capturer les besoins, les dcouvrir, les rfuter, les consolider, etc., correspond plus une analyse fonctionnelle classique.

2-5-4-c - Les Use case Realization


UML ne mentionne que le fait que la ralisation d'un cas d'utilisation est dcrite par une suite de collaborations entre lments de modlisation, mais ne parle par de l'lment de modlisation use case realization. Les use case realization ne sont pas un formalisme d'UML, mais du RUP (Rational Unified Process). Aprs avoir rdig les cas d'utilisation, il faut identifier des objets, des classes, des donnes et des traitements qui vont permettre au systme de supporter ces cas d'utilisation. Pour documenter la manire dont sont mis en uvre les cas d'utilisation du systme, on peut utiliser le mcanisme des use case realization. Ils permettent de regrouper un diagramme de classes et des diagrammes d'interaction. On retrouvera dans le diagramme de classes les classes qui

- 32 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

mettent en uvre le cas d'utilisation associ au use case realization. On retrouvera dans les diffrents diagrammes d'interaction une documentation des diffrents vnements changs entre les objets afin de raliser les diffrents scnarii dcrits dans le cas d'utilisation. Finalement, on aura un use case realization par cas d'utilisation et dans chaque use case realization on aura autant de diagrammes d'interaction que ncessaire pour illustrer les scnarii dcrits dans le cas d'utilisation (scnario nominal, scnarii alternatifs et scnarii d'exception). Les use case realization permettent donc, dans la pratique, d'apporter un lment de rponse la question : Comment structurer mon modle UML ?

3 - Chapitre 3 Diagramme de classes (Class Diagram) 3-1 - Introduction


Le diagramme de classes est considr comme le plus important de la modlisation oriente objet, il est le seul obligatoire lors d'une telle modlisation. Alors que le diagramme de cas d'utilisation montre un systme du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une reprsentation abstraite des objets du systme qui vont interagir pour raliser les cas d'utilisation. Il est important de noter qu'un mme objet peut trs bien intervenir dans la ralisation de plusieurs cas d'utilisation. Les cas d'utilisation ne ralisent donc pas une partition (7) des classes du diagramme de classes. Un diagramme de classes n'est donc pas adapt (sauf cas particulier) pour dtailler, dcomposer, ou illustrer la ralisation d'un cas d'utilisation particulier. Il s'agit d'une vue statique, car on ne tient pas compte du facteur temporel dans le comportement du systme. Le diagramme de classes modlise les concepts du domaine d'application ainsi que les concepts internes crs de toutes pices dans le cadre de l'implmentation d'une application. Chaque langage de Programmation orient objet donne un moyen spcifique d'implmenter le paradigme objet (pointeurs ou pas, hritage multiple ou pas, etc.), mais le diagramme de classes permet de modliser les classes du systme et leurs relations indpendamment d'un langage de programmation particulier. Les principaux lments de cette vue statique sont les classes et leurs relations : association, gnralisation et plusieurs types de dpendances, telles que la ralisation et l'utilisation.

3-2 - Les classes 3-2-1 - Notions de classe et d'instance de classe


Une instance est une concrtisation d'un concept abstrait. Par exemple : la Ferrari Enzo qui se trouve dans votre garage est une instance du concept abstrait Automobile ; l'amiti qui lie Jean et Marie est une instance du concept abstrait Amiti ;

Une classe est un concept abstrait reprsentant des lments varis comme : des lments concrets (ex. : des avions), des lments abstraits (ex. : des commandes de marchandises ou services), des composants d'une application (ex. : les boutons des botes de dialogue), des structures informatiques (ex. : des tables de hachage), des lments comportementaux (ex. : des tches), etc.

Tout systme orient objet est organis autour des classes.


- 33 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Une classe est la description formelle d'un ensemble d'objets ayant une smantique et des caractristiques communes. Un objet est une instance d'une classe. C'est une entit discrte dote d'une identit, d'un tat et d'un comportement que l'on peut invoquer. Les objets sont des lments individuels d'un systme en cours d'excution. Par exemple, si l'on considre que Homme (au sens tre humain) est un concept abstrait, on peut dire que la personne Marie-Ccile est une instance de Homme. Si Homme tait une classe, Marie-Ccile en serait une instance : un objet.

3-2-2 - Caractristiques d'une classe


Une classe dfinit un jeu d'objets dots de caractristiques communes. Les caractristiques d'un objet permettent de spcifier son tat et son comportement. Dans les sections 1.3.2 et 1.3.4, nous avons dit que les caractristiques d'un objet taient soit des attributs, soit des oprations. Ce n'est pas exact dans un diagramme de classe, car les terminaisons d'associations sont des proprits qui peuvent faire partie des caractristiques d'un objet au mme titre que les attributs et les oprations (cf. section 3.3.2).

tat d'un objet :


ce sont les attributs et gnralement les terminaisons d'associations, tous deux runis sous le terme de proprits structurelles, ou tout simplement proprits (8) , qui dcrivent l'tat d'un objet. Les attributs sont utiliss pour des valeurs de donnes pures, dpourvues d'identit, telles que les nombres et les chanes de caractres. Les associations sont utilises pour connecter les classes du diagramme de classe ; dans ce cas, la terminaison de l'association (du ct de la classe cible) est gnralement une proprit de la classe de base (cf. section 3.3.1 et 3.3.2). Les proprits dcrites par les attributs prennent des valeurs lorsque la classe est instancie. L'instance d'une association est appele un lien.

Comportement d'un objet :


les oprations dcrivent les lments individuels d'un comportement que l'on peut invoquer. Ce sont des fonctions qui peuvent prendre des valeurs en entre et modifier les attributs ou produire des rsultats. Une opration est la spcification (i.e. dclaration) d'une mthode. L'implmentation (i.e. dfinition) d'une mthode est galement appele mthode. Il y a donc une ambigut sur le terme mthode. Les attributs, les terminaisons d'association et les mthodes constituent donc les caractristiques d'une classe (et de ses instances).

3-2-3 - Reprsentation graphique

- 34 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 3.1 : Reprsentation UML d'une classe. Une classe est un classeur (9) . Elle est reprsente par un rectangle divis en trois cinq compartiments (figure 3.1). Le premier indique le nom de la classe (cf. section 3.2.5), le deuxime ses attributs (cf. section 3.2.6) et le troisime ses oprations (cf. section 3.2.7). Un compartiment des responsabilits peut tre ajout pour numrer l'ensemble de tches devant tre assures par la classe, mais pour lesquelles on ne dispose pas encore assez d'informations. Un compartiment des exceptions peut galement tre ajout pour numrer les situations exceptionnelles devant tre gres par la classe.

3-2-4 - Encapsulation, visibilit, interface

Figure 3.2 : Bonnes pratiques concernant la manipulation des attributs. Nous avons dj abord cette problmatique section 1.3.4. L'encapsulation est un mcanisme consistant rassembler les donnes et les mthodes au sein d'une structure en cachant l'implmentation de l'objet, c'est--dire en empchant l'accs aux donnes par un autre moyen que les services proposs. Ces services accessibles (offerts) aux utilisateurs de l'objet dfinissent ce que l'on appelle l'interface de l'objet (sa vue externe). L'encapsulation permet donc de garantir l'intgrit des donnes contenues dans l'objet. L'encapsulation permet de dfinir des niveaux de visibilit des lments d'un conteneur. La visibilit dclare la possibilit pour un lment de modlisation de rfrencer un lment qui se trouve dans un espace de noms diffrent de celui de l'lment qui tablit la rfrence. Elle fait partie de la relation entre un lment et le conteneur qui l'hberge, ce dernier pouvant tre un paquetage, une classe ou un autre espace de noms. Il existe quatre visibilits prdfinies. Public ou + : tout lment qui peut voir le conteneur peut galement voir l'lment indiqu. Protected ou # :

- 35 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

seul un lment situ dans le conteneur ou un de ses descendants peut voir l'lment indiqu. Private ou - : seul un lment situ dans le conteneur peut voir l'lment. Package ou # ou rien : seul un lment dclar dans le mme paquetage peut voir l'lment. Par ailleurs, UML 2.0 donne la possibilit d'utiliser n'importe quel langage de programmation pour la spcification de la visibilit. Dans une classe, le marqueur de visibilit se situe au niveau de chacune de ses caractristiques (attributs, terminaisons d'association et opration). Il permet d'indiquer si une autre classe peut y accder. Dans un paquetage, le marqueur de visibilit se situe sur des lments contenus directement dans le paquetage, comme les classes, les paquetages imbriqus, etc. Il indique si un autre paquetage susceptible d'accder au premier paquetage peut voir les lments. Dans la pratique, lorsque des attributs doivent tre accessibles de l'extrieur, il est prfrable que cet accs ne soit pas direct, mais se fasse par l'intermdiaire d'oprations (figure 3.2).

3-2-5 - Nom d'une classe


Le nom de la classe doit voquer le concept dcrit par la classe. Il commence par une majuscule. On peut ajouter des informations subsidiaires comme le nom de l'auteur de la modlisation, la date, etc. Pour indiquer qu'une classe est abstraite, il faut ajouter le mot-clef abstract. La syntaxe de base de la dclaration d'un nom d'une classe est la suivante :
[ <Nom_du_paquetage_1>::...::<Nom_du_paquetage_N> ] <Nom_de_la_classe> [ { [abstract], [<auteur>], [<date>], ... } ]

3-2-5-a - Mtalangage des syntaxes


Nous aurons rgulirement recours ce mtalangage pour dcrire des syntaxes de dclaration. Ce mtalangage contient certains mtacaractres : []: les crochets indiquent que ce qui est l'intrieur est optionnel ; <>: les signes infrieur et suprieur indiquent que ce qui est l'intrieur est plus ou moins libre ; par exemple, la syntaxe de dclaration d'une variable comme compteur : int est <nom_variable> : <type> ; '': les cotes sont utiles quand on veut utiliser un mtacaractre comme un caractre ; par exemple, pour dsigner un crochet ([) il faut crire '[, car [ est un mtacaractre ayant une signification spciale ;

- 36 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

: permet de dsigner une suite de squence de longueur non dfinie, le contexte permettant de comprendre de quelle suite il s'agit.

3-2-6 - Les attributs 3-2-6-a - Attributs de la classe


Les attributs dfinissent des informations qu'une classe ou un objet doivent connatre. Ils reprsentent les donnes encapsules dans les objets de cette classe. Chacune de ces informations est dfinie par un nom, un type de donnes, une visibilit et peut tre initialise. Le nom de l'attribut doit tre unique dans la classe. La syntaxe de la dclaration d'un attribut est la suivante :
<visibilit> [/] <nom_attribut> : <type> [ '['<multiplicit>']' [{<contrainte>}] ] [ = <valeur_par_dfaut> ]

Le type de l'attribut (<type>) peut tre un nom de classe, un nom d'interface ou un type de donne prdfini. La multiplicit (<multiplicit>) d'un attribut prcise le nombre de valeurs que l'attribut peut contenir. Lorsqu'une multiplicit suprieure 1 est prcise, il est possible d'ajouter une contrainte ({<contrainte>}) pour prciser si les valeurs sont ordonnes ({ordered}) ou pas ({list}).

3-2-6-b - Attributs de classe


Par dfaut, chaque instance d'une classe possde sa propre copie des attributs de la classe. Les valeurs des attributs peuvent donc diffrer d'un objet un autre. Cependant, il est parfois ncessaire de dfinir un attribut de classe (static en Java ou en C++) qui garde une valeur unique et partage par toutes les instances de la classe. Les instances ont accs cet attribut, mais n'en possdent pas une copie. Un attribut de classe n'est donc pas une proprit d'une instance, mais une proprit de la classe et l'accs cet attribut ne ncessite pas l'existence d'une instance. Graphiquement, un attribut de classe est soulign.

3-2-6-c - Attributs drivs


Les attributs drivs peuvent tre calculs partir d'autres attributs et de formules de calcul. Lors de la conception, un attribut driv peut tre utilis comme marqueur jusqu' ce que vous puissiez dterminer les rgles lui appliquer. Les attributs drivs sont symboliss par l'ajout d'un / devant leur nom.

3-2-7 - Les mthodes 3-2-7-a - Mthode de la classe


Dans une classe, une opration (mme nom et mmes types de paramtres) doit tre unique. Quand le nom d'une opration apparat plusieurs fois avec des paramtres diffrents, on dit que l'opration est surcharge. En revanche, il est impossible que deux oprations ne se distinguent que par leur valeur retourne. La dclaration d'une opration contient les types des paramtres et le type de la valeur de retour, sa syntaxe est la suivante :
<visibilit> <nom_mthode> ([<paramtre_1>, ... , <paramtre_N>]) : [<type_renvoy>] [{<proprits>}]

- 37 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

La syntaxe de dfinition d'un paramtre (<paramtre>) est la suivante :


[<direction>] <nom_paramtre>:<type> ['['<multiplicit>']'] [=<valeur_par_dfaut>]

La direction peut prendre l'une des valeurs suivantes :

in :

paramtre d'entre pass par valeur. Les modifications du paramtre ne sont pas disponibles pour l'appelant. C'est le comportement par dfaut.

out :

paramtre de sortie uniquement. Il n'y a pas de valeur d'entre et la valeur finale est disponible pour l'appelant.

inout :

paramtre d'entre/sortie. La valeur finale est disponible pour l'appelant.

Le type du paramtre (<type>) peut tre un nom de classe, un nom d'interface ou un type de donne prdfini. Les proprits (<proprits>) correspondent des contraintes ou des informations complmentaires comme les exceptions, les prconditions, les postconditions ou encore l'indication qu'une mthode est abstraite (mot-clef abstract), etc.

3-2-7-b - Mthode de classe


Comme pour les attributs de classe, il est possible de dclarer des mthodes de classe. Une mthode de classe ne peut manipuler que des attributs de classe et ses propres paramtres. Cette mthode n'a pas accs aux attributs de la classe (i.e. des instances de la classe). L'accs une mthode de classe ne ncessite pas l'existence d'une instance de cette classe. Graphiquement, une mthode de classe est souligne.

3-2-7-c - Mthodes et classes abstraites


Une mthode est dite abstraite lorsqu'on connat son entte, mais pas la manire dont elle peut tre ralise (i.e. on connat sa dclaration, mais pas sa dfinition). Une classe est dite abstraite lorsqu'elle dfinit au moins une mthode abstraite ou lorsqu'une classe parent (cf. section 3.3.9) contient une mthode abstraite non encore ralise. On ne peut instancier une classe abstraite : elle est voue se spcialiser (cf. section 3.3.9). Une classe abstraite peut trs bien contenir des mthodes concrtes. Une classe abstraite pure ne comporte que des mthodes abstraites. En programmation oriente objet, une telle classe est appele une interface. Pour indiquer qu'une classe est abstraite, il faut ajouter le mot-clef abstract derrire son nom.

3-2-8 - Classe active


Une classe est passive par dfaut, elle sauvegarde les donnes et offre des services aux autres. Une classe active initie et contrle le flux d'activits.

- 38 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Graphiquement, une classe active est reprsente comme une classe standard dont les lignes verticales du cadre, sur les cts droit et gauche, sont doubles.

3-3 - Relations entre classes 3-3-1 - Notion d'association


Une association est une relation entre deux classes (association binaire) ou plus (association naire), qui dcrit les connexions structurelles entre leurs instances. Une association indique donc qu'il peut y avoir des liens entre des instances des classes associes. Comment une association doit-elle tre modlise ? Plus prcisment, quelle diffrence existe-t-il entre les deux diagrammes de la figure 3.3 ?

Figure 3.3 : Deux faons de modliser une association. Dans la premire version, l'association apparat clairement et constitue une entit distincte. Dans la seconde, l'association se manifeste par la prsence de deux attributs dans chacune des classes en relation. C'est en fait la manire dont une association est gnralement implmente dans un langage objet quelconque (cf. section 3.6.2), mais pas dans tout langage de reprsentation (cf. section 3.6.3). La question de savoir s'il faut modliser les associations en tant que telles a longtemps fait dbat. UML a tranch pour la premire version, car elle se situe plus un niveau conceptuel (par opposition au niveau d'implmentation) et simplifie grandement la modlisation d'associations complexes (comme les associations plusieurs plusieurs par exemple). Un attribut peut alors tre considr comme une association dgnre dans laquelle une terminaison d'association (10) est dtenue par un classeur (gnralement une classe). Le classeur dtenant cette terminaison d'association devrait thoriquement se trouver l'autre extrmit, non modlise, de l'association. Un attribut n'est donc rien d'autre qu'une terminaison d'un cas particulier d'association (cf. figure 3.9 section 3.3.5). Ainsi, les terminaisons d'associations et les attributs sont deux lments conceptuellement trs proches que l'on regroupe sous le terme de proprit.

3-3-2 - Terminaison d'association 3-3-2-a - Propritaire d'une terminaison d'association


La possession d'une terminaison d'association par le classeur situ l'autre extrmit de l'association peut tre spcifie graphiquement par l'adjonction d'un petit cercle plein (point) entre la terminaison d'association et la classe (cf. figure 3.4). Il n'est pas indispensable de prciser la possession des terminaisons d'associations. Dans ce cas, la possession est ambigu. Par contre, si l'on indique des possessions de terminaisons d'associations, toutes les terminaisons d'associations sont non ambigus : la prsence d'un point implique que la terminaison d'association appartient la classe situe l'autre extrmit, l'absence du point implique que la terminaison d'association appartient l'association.
- 39 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 3.4 : Utilisation d'un petit cercle plein pour prciser le propritaire d'une terminaison d'association. Par exemple, le diagramme de la figure 3.4 prcise que la terminaison d'association sommet (i.e. la proprit sommet) appartient la classe Polygone tandis que la terminaison d'association polygone (i.e. la proprit polygone) appartient l'association Dfini par.

3-3-2-b - Une terminaison d'association est une proprit


Une proprit est une caractristique structurelle. Dans le cas d'une classe, les proprits sont constitues par les attributs et les ventuelles terminaisons d'association que possde la classe. Dans le cas d'une association, les proprits sont constitues par les terminaisons d'association que possde l'association. Attention, une association ne possde pas forcment toutes ses terminaisons d'association ! Une proprit peut tre paramtre par les lments suivants (on s'intresse ici essentiellement aux terminaisons d'associations puisque les attributs ont t largement traits section 3.2.1) :

nom :

comme un attribut, une terminaison d'association peut tre nomme. Le nom est situ proximit de la terminaison, mais contrairement un attribut, ce nom est facultatif. Le nom d'une terminaison d'association est appel nom du rle. Une association peut donc possder autant de noms de rle que de terminaisons (deux pour une association binaire et n pour une association n-aire) ;

visibilit :

comme un attribut, une terminaison d'association possde une visibilit (cf. section 3.2.4). La visibilit est mentionne proximit de la terminaison, et plus prcisment, le cas chant, devant le nom de la terminaison ;

multiplicit :

comme un attribut, une terminaison d'association peut possder une multiplicit. Elle est mentionne proximit de la terminaison. Il n'est pas impratif de la prciser, mais, contrairement un attribut dont la multiplicit par dfaut est 1, la multiplicit par dfaut d'une terminaison d'association est non spcifie. L'interprtation de la multiplicit pour une terminaison d'association est moins vidente que pour un attribut (cf. section 3.3.4) ;

navigabilit :

pour un attribut, la navigabilit est implicite, navigable, et toujours depuis la classe vers l'attribut. Pour une terminaison d'association, la navigabilit peut tre prcise (cf. section 3.3.5).

3-3-3 - Association binaire et n-aire 3-3-3-a - Association binaire

Figure 3.5 : Exemple d'association binaire. Une association binaire est matrialise par un trait plein entre les classes associes (cf. figure 3.5). Elle peut tre orne d'un nom, avec ventuellement une prcision du sens de lecture ( ou ).
- 40 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Quand les deux extrmits de l'association pointent vers la mme classe, l'association est dite rflexive.

3-3-3-b - Association n-aire

Figure 3.6 : Exemple d'association n-aire. Une association n-aire lie plus de deux classes. La section 3.3.4 dtaille comment interprter les multiplicits d'une association n-aire. La ligne pointille d'une classe-association (cf. section 3.3.7) peut tre relie au losange par une ligne discontinue pour reprsenter une association n-aire dote d'attributs, d'oprations ou d'associations. On reprsente une association n-aire par un grand losange avec un chemin partant vers chaque classe participante (cf. figure 3.6). Le nom de l'association, le cas chant, apparat proximit du losange.

3-3-4 - Multiplicit ou cardinalit


La multiplicit associe une terminaison d'association, d'agrgation ou de composition dclare le nombre d'objets susceptibles d'occuper la position dfinie par la terminaison d'association. Voici quelques exemples de multiplicit : exactement un : 1 ou 1..1 ; plusieurs : * ou 0..* ; au moins un : 1..* ; de un six : 1..6.

Dans une association binaire (cf. figure 3.5), la multiplicit sur la terminaison cible contraint le nombre d'objets de la classe cible pouvant tre associs un seul objet donn de la classe source (la classe de l'autre terminaison de l'association). Dans une association n-aire, la multiplicit apparaissant sur le lien de chaque classe s'applique sur une instance de chacune des classes, l'exclusion de la classe-association et de la classe considre. Par exemple, si on prend une association ternaire entre les classes (A, B, C), la multiplicit de la terminaison C indique le nombre d'objets C qui peuvent apparatre dans l'association (dfinie section 3.3.7) avec une paire particulire d'objets A et B. Pour une association n-aire, la multiplicit minimale doit en principe, mais pas ncessairement, tre 0. En effet, une multiplicit minimale de 1 (ou plus) sur une extrmit implique qu'il doit exister un lien (ou plus) pour TOUTES les combinaisons possibles des instances des classes situes aux autres extrmits de l'association n-aire !

- 41 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Il faut noter que, pour les habitus du modle entit/relation, les multiplicits sont en UML l'envers (par rfrence Merise) pour les associations binaires et l'endroit pour les naires avec n>2.

3-3-5 - Navigabilit

Figure 3.7 : Navigabilit. La navigabilit indique s'il est possible de traverser une association. On reprsente graphiquement la navigabilit par une flche du ct de la terminaison navigable et on empche la navigabilit par une croix du ct de la terminaison non navigable (cf. figure 3.7). Par dfaut, une association est navigable dans les deux sens. Par exemple, sur la figure 3.7, la terminaison du ct de la classe Commande n'est pas navigable : cela signifie que les instances de la classe Produit ne stockent pas de liste d'objets du type Commande. Inversement, la terminaison du ct de la classe Produit est navigable : chaque objet commande contient une liste de produits.

Figure 3.8 : Implicitement, ces trois notations ont la mme smantique. Lorsque l'on reprsente la navigabilit uniquement sur l'une des extrmits d'une association, il faut remarquer que, implicitement, les trois associations reprsentes sur la figure 3.8 ont la mme signification : l'association ne peut tre traverse que dans un sens.

Figure 3.9 : Deux modlisations quivalentes. Dans la section 3.3.1, nous avons dit que : Un attribut est une association dgnre dans laquelle une terminaison d'association est dtenue par un classeur (gnralement une classe). Le classeur dtenant cette terminaison d'association devrait thoriquement se trouver l'autre terminaison, non modlise, de l'association. Un attribut n'est donc rien d'autre qu'une terminaison d'un cas particulier d'association. La figure 3.9 illustre parfaitement cette situation.

- 42 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Attention toutefois, si vous avez une classe Point dans votre diagramme de classe, il est extrmement maladroit de reprsenter des classes (comme la classe Polygone) avec un ou plusieurs attributs de type Point. Il faut, dans ce cas, matrialiser cette proprit de la classe en question par une ou plusieurs associations avec la classe Point.

3-3-6 - Qualification

Figure 3.10 : En haut, un diagramme reprsentant l'association entre une banque et ses clients ( gauche), et un diagramme reprsentant l'association entre un chiquier et les cases qui le composent ( droite). En bas, les diagrammes quivalents utilisant des associations qualifies. Gnralement, une classe peut tre dcompose en sous-classes ou possder plusieurs proprits. Une telle classe rassemble un ensemble d'lments (d'objets). Quand une classe est lie une autre classe par une association, il est parfois prfrable de restreindre la porte de l'association quelques lments cibls (comme un ou plusieurs attributs) de la classe. Ces lments cibls sont appels un qualificatif. Un qualificatif permet donc de slectionner un ou des objets dans le jeu des objets d'un objet (appel objet qualifi) reli par une association un autre objet. L'objet slectionn par la valeur du qualificatif est appel objet cible. L'association est appele association qualifie. Un qualificatif agit toujours sur une association dont la multiplicit est plusieurs (avant que l'association ne soit qualifie) du ct cible. Un objet qualifi et une valeur de qualificatif gnrent un objet cible li unique. En considrant un objet qualifi, chaque valeur de qualificatif dsigne un objet cible unique. Par exemple, le diagramme de gauche de la figure 3.10 nous dit que : un compte dans une banque appartient au plus deux personnes. Autrement dit, une instance du couple {Banque , compte} est en association avec zro deux instances de la classe Personne ; mais une personne peut possder plusieurs comptes dans plusieurs banques. C'est--dire qu'une instance de la classe Personne peut tre associe plusieurs (zro compris) instances du couple {Banque , compte} ; bien entendu, et dans tous les cas, une instance du couple {Personne , compte} est en association avec une instance unique de la classe Banque.

Le diagramme de droite de cette mme figure nous dit que : une instance du triplet {chiquier, range, colonne} est en association avec une instance unique de la classe Case ;

- 43 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

inversement, une instance de la classe Case est en association avec une instance unique du triplet {chiquier, range, colonne}.

3-3-7 - Classe-association 3-3-7-a - Dfinition et reprsentation

Figure 3.11 : Exemple de classe-association. Parfois, une association doit possder des proprits. Par exemple, l'association Emploie entre une socit et une personne possde comme proprits le salaire et la date d'embauche. En effet, ces deux proprits n'appartiennent ni la socit, qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il s'agit donc bien de proprits de l'association Emploie. Les associations ne pouvant possder de proprit, il faut introduire un nouveau concept pour modliser cette situation : celui de classe-association. Une classe-association possde les caractristiques des associations et des classes : elle se connecte deux ou plusieurs classes et possde galement des attributs et des oprations. Une classe-association est caractrise par un trait discontinu entre la classe et l'association qu'elle reprsente (figure 3.11).

3-3-7-b - Classe-association pour plusieurs associations


Il n'est pas possible de rattacher une classe-association plus d'une association puisque la classe-association constitue elle-mme l'association. Dans le cas o plusieurs classe-associations doivent disposer des mmes caractristiques, elles doivent hriter d'une mme classe possdant ces caractristiques, ou l'utiliser en tant qu'attribut. De mme, il n'est pas possible de rattacher une instance de la classe d'une classe-association plusieurs instances de l'association de la classe-association. En effet, la reprsentation graphique (association relie par une ligne pointille une classe dporte) est trompeuse : une classe-association est une entit smantique atomique et non composite qui s'instancie donc en bloc. Ce problme et nouveau abord et illustr section 3.5.2.

3-3-7-c - Autoassociation sur classe-association

- 44 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 3.12 : Exemple d'autoassociation sur classe-association. Imaginons que nous voulions ajouter une association Suprieur de dans le diagramme 3.11 pour prciser qu'une personne est le suprieur d'une autre personne. On ne peut simplement ajouter une association rflexive sur la classe Personne. En effet, une personne n'est pas le suprieur d'une autre dans l'absolu. Une personne est, en tant qu'employ d'une entreprise donne, le suprieur d'une autre personne dans le cadre de son emploi pour une entreprise donne (gnralement, mais pas ncessairement, la mme). Il s'agit donc d'une association rflexive, non pas sur la classe Personne, mais sur la classe-association Emploie (cf. figure 3.12).

3-3-7-d - Liens multiples

Figure 3.13 : Exemple de classe-association avec liens multiples. Plusieurs instances d'une mme association ne peuvent lier les mmes objets. Cependant, si l'on s'intresse l'exemple de la figure 3.13, on voit bien qu'il doit pouvoir y avoir plusieurs instances de la classe-association Actions liant une mme personne une mme socit : une mme personne peut acheter des moments diffrents des actions d'une mme socit. C'est justement la raison de la contrainte {bag} qui, place sur les terminaisons d'association de la classe-association Actions, indique qu'il peut y avoir des liens multiples impliquant les mmes paires d'objets.

3-3-7-e - quivalences
Parfois, l'information vhicule par une classe-association peut tre vhicule sans perte d'une autre manire (cf. figure 3.14 et 3.15).

- 45 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 3.14 : Deux modlisations modlisant la mme information.

Figure 3.15 : Deux modlisations modlisant la mme information.

3-3-7-f - Classe-association, association n-aire ou association qualifie ?


Il n'est souvent pas simple trancher entre l'utilisation d'une classe-association, d'une association n-aire ou encore d'une association qualifie. Lorsque l'on utilise l'un de ces trois types d'association, il peut tre utile ou instructif de se demander si l'un des deux autres types ne serait pas plus pertinent. Dans tous les cas, il faut garder l'esprit qu'une classe-association est d'abord et avant tout une association et que, dans une classe-association, la classe est indissociable de l'association.

Figure 3.16 : Pour couvrir le cas des comptes joints, il faut utiliser le modle de droite. Ainsi, le cas d'un compte joint ne peut tre reprsent correctement par le diagramme de gauche dans figure 3.16 : mieux vaut utiliser une association qualifie (diagramme de droite dans la figure ). Ce problme et nouveau abord et illustr section 3.5.2.

- 46 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 3.17 : Si un cours doit pouvoir exister indpendamment d'un lien entre un enseignant et un groupe, il faut utiliser le modle de droite. Dans le diagramme de gauche de la figure 3.17, un cours ne peut exister que s'il existe un lien entre un objet Enseignant et un objet Groupe. Quand le lien est rompu (effac), le cours l'est galement. Si un cours doit pouvoir exister indpendamment de l'existence d'un lien (on n'a pas encore trouv d'enseignant pour ce cours, le cours n'est pas enseign cette anne, mais le sera probablement l'anne prochaine) il faut opter pour une association ternaire (modle de droite dans figure 3.17).

Figure 3.18 : Si un mme cours doit concerner plusieurs couples Enseignant/tudiant, il ne faut pas utiliser une classe-association, mais une association ternaire comme sur le modle de droite. Le cas de figure est encore pire si l'on remplace Groupe par tudiant (cf. modle gauche sur la figure 3.18). En effet, le cas gnral dcrit par ce modle ne correspond pas du tout au diagramme d'objet (cf. section 3.5) situ au centre. Nous reviendrons sur ce problme dans la section 3.5.2 avec l'illustration 3.24. Dans cette situation, il faut opter pour une association ternaire comme sur le modle de droite.

3-3-8 - Agrgation et composition 3-3-8-a - Agrgation

Figure 3.19 : Exemple de relation d'agrgation et de composition. Une association simple entre deux classes reprsente une relation structurelle entre pairs, c'est--dire entre deux classes de mme niveau conceptuel : aucune des deux n'est plus importante que l'autre. Lorsque l'on souhaite modliser une relation tout/partie o une classe constitue un lment plus grand (tout) compos d'lments plus petits (partie), il faut utiliser une agrgation.

- 47 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Une agrgation est une association qui reprsente une relation d'inclusion structurelle ou comportementale d'un lment dans un ensemble. Graphiquement, on ajoute un losange vide () du ct de l'agrgat (cf. figure 3.19). Contrairement une association simple, l'agrgation est transitive. La signification de cette forme simple d'agrgation est uniquement conceptuelle. Elle ne contraint pas la navigabilit ou les multiplicits de l'association. Elle n'entrane pas non plus de contrainte sur la dure de vie des parties par rapport au tout.

3-3-8-b - Composition
La composition, galement appele agrgation composite, dcrit une contenance structurelle entre instances. Ainsi, la destruction de l'objet composite implique la destruction de ses composants. Une instance de la partie appartient toujours au plus une instance de l'lment composite : la multiplicit du ct composite ne doit pas tre suprieure 1 (i.e. 1 ou 0..1). Graphiquement, on ajoute un losange plein () du ct de l'agrgat (cf. figure 3.19). Les notions d'agrgation et surtout de composition posent de nombreux problmes en modlisation et sont souvent le sujet de querelles d'experts et sources de confusions. Ce que dit la norme UML Superstructure version 2.1.1 reflte d'ailleurs trs bien le flou qui entoure ces notions : Precise semantics of shared aggregation varies by application area and modeler. The order and way in which part instances are created is not defined.

3-3-9 - Gnralisation et Hritage

Figure 3.20 : Partie du rgne animal dcrit avec l'hritage multiple. La gnralisation dcrit une relation entre une classe gnrale (classe de base ou classe parent) et une classe spcialise (sous-classe). La classe spcialise est intgralement cohrente avec la classe de base, mais comporte des informations supplmentaires (attributs, oprations, associations). Un objet de la classe spcialise peut tre utilis partout o un objet de la classe de base est autoris. Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de gnralisation se traduit par le concept d'hritage. On parle galement de relation d'hritage. Ainsi, l'hritage permet la classification des objets (cf. figure 3.20). Le symbole utilis pour la relation d'hritage ou de gnralisation est une flche avec un trait plein dont la pointe est un triangle ferm dsignant le cas le plus gnral (cf. figure 3.20). Les proprits principales de l'hritage sont :

- 48 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

la classe enfant possde toutes les caractristiques de ses classes parents, mais elle ne peut accder aux caractristiques prives de cette dernire ; une classe enfant peut redfinir (mme signature) une ou plusieurs mthodes de la classe parent. Sauf indication contraire, un objet utilise les oprations les plus spcialises dans la hirarchie des classes ; toutes les associations de la classe parent s'appliquent aux classes drives ; une instance d'une classe peut tre utilise partout o une instance de sa classe parent est attendue. Par exemple, en se basant sur le diagramme de la figure 3.20, toute opration acceptant un objet d'une classe Animal doit accepter un objet de la classe Chat ; une classe peut avoir plusieurs parents, on parle alors d'hritage multiple (cf. la classe Ornithorynque de la figure 3.20). Le langage C++ est un des langages objet permettant son implmentation effective, le langage Java ne le permet pas.

En UML, la relation d'hritage n'est pas propre aux classes. Elle s'applique d'autres lments du langage comme les paquetages, les acteurs (cf. section 2.3.3) ou les cas d'utilisation (cf. section 2.3.2).

3-3-10 - Dpendance

Figure 3.21 : Exemple de relation de dpendance. Une dpendance est une relation unidirectionnelle exprimant une dpendance smantique entre des lments du modle. Elle est reprsente par un trait discontinu orient (cf. figure 3.21). Elle indique que la modification de la cible peut impliquer une modification de la source. La dpendance est souvent strotype pour mieux expliciter le lien smantique entre les lments du modle (cf. figure 3.21 ou 3.25). On utilise souvent une dpendance quand une classe en utilise une autre comme argument dans la signature d'une opration. Par exemple, le diagramme de la figure 3.21 montre que la classe Confrontation utilise la classe Stratgie, car la classe Confrontation possde une mthode confronter dont deux paramtres sont du type Stratgie. Si la classe Stratgie, notamment son interface, change, alors des modifications devront galement tre apportes la classe Confrontation.

3-4 - 3.4 Interfaces

- 49 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 3.22 : Exemple de diagramme mettant en uvre une interface. Nous avons dj abord la notion d'interface dans les sections 1.3.4 et 3.2.4. En effet, les classes permettent de dfinir en mme temps un objet et son interface. Le classeur, que nous dcrivons dans cette section, ne permet de dfinir que des lments d'interface. Il peut s'agir de l'interface complte d'un objet, ou simplement d'une partie d'interface qui sera commune plusieurs objets. Le rle de ce classeur, strotyp << interface >>, est de regrouper un ensemble de proprits et d'oprations assurant un service cohrent. L'objectif est de diminuer le couplage entre deux classeurs. La notion d'interface en UML est trs proche de la notion d'interface en Java. Une interface est reprsente comme une classe except l'absence du mot-clef abstract (car l'interface et toutes ses mthodes sont, par dfinition, abstraites) et l'ajout du strotype << interface >> (cf. figure 3.22). Une interface doit tre ralise par au moins une classe et peut l'tre par plusieurs. Graphiquement, cela est reprsent par un trait discontinu termin par une flche triangulaire et le strotype realize . Une classe peut trs bien raliser plusieurs interfaces. Une classe (classe cliente de l'interface) peut dpendre d'une interface (interface requise). On reprsente cela par une relation de dpendance et le strotype use . Attention aux problmes de conflits si une classe dpend d'une interface ralise par plusieurs autres classes. La notion d'interface est assez proche de la notion de classe abstraite avec une capacit de dcouplage plus grand. En C++ (le C++ ne connat pas la notion d'interface), la notion d'interface est gnralement implmente par une classe abstraite.

3-5 - 3.5 Diagramme d'objets (object diagram) 3-5-1 - Prsentation


Un diagramme d'objets reprsente des objets (i.e. instances de classes) et leurs liens (i.e. instances de relations) pour donner une vue fige de l'tat d'un systme un instant donn. Un diagramme d'objets peut tre utilis pour : illustrer le modle de classes en montrant un exemple qui explique le modle ; prciser certains aspects du systme en mettant en vidence des dtails imperceptibles dans le diagramme de classes ; exprimer une exception en modlisant des cas particuliers ou des connaissances non gnralisables qui ne sont pas modliss dans un diagramme de classe ; prendre une image (snapshot) d'un systme un moment donn.

- 50 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Le diagramme de classes modlise les rgles et le diagramme d'objets modlise des faits. Par exemple, le diagramme de classes de la figure 3.23 montre qu'une entreprise emploie au moins deux personnes et qu'une personne travaille dans au plus deux entreprises. Le diagramme d'objets modlise lui une entreprise particulire (PERTNE) qui emploie trois personnes. Un diagramme d'objets ne montre pas l'volution du systme dans le temps. Pour reprsenter une interaction, il faut utiliser un diagramme de communication (cf. section 7.2) ou de squence (cf. section 7.3).

3-5-2 - Reprsentation

Figure 3.23 : Exemple de diagramme de classes et de diagramme d'objets associ. Graphiquement, un objet se reprsente comme une classe. Cependant, le compartiment des oprations n'est pas utile. De plus, le nom de la classe dont l'objet est une instance est prcd d'un << : >> et est soulign. Pour diffrencier les objets d'une mme classe, leur identifiant peut tre ajout devant le nom de la classe. Enfin les attributs reoivent des valeurs. Quand certaines valeurs d'attribut d'un objet ne sont pas renseignes, on dit que l'objet est partiellement dfini. Dans un diagramme d'objets, les relations du diagramme de classes deviennent des liens. La relation de gnralisation ne possde pas d'instance, elle n'est donc jamais reprsente dans un diagramme d'objets. Graphiquement, un lien se reprsente comme une relation, mais, s'il y a un nom, il est soulign. Naturellement, on ne reprsente pas les multiplicits.

Figure 3.24 : Le diagramme d'objets de droite, illustrant le cas de figure d'un compte joint, n'est pas une instance normale du diagramme de classe de gauche, mais peut prciser une situation exceptionnelle. La norme UML 2.1.1 prcise qu'une instance de classe-association ne peut tre associe qu' une instance de chacune des classes associes (11) ce qui interdit d'instancier le diagramme de classe gauche dans la figure 3.24 par le diagramme d'objet droite dans cette mme figure. Cependant, un diagramme d'objet peut tre utilis pour exprimer une exception. Sur la figure , le diagramme d'objets droite peut tre lgitime s'il vient prciser une

- 51 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

situation exceptionnelle non prise en compte par le diagramme de classe reprsent gauche. Nanmoins, le cas des comptes joints n'tant pas si exceptionnel, mieux vaut revoir la modlisation comme prconis par la figure 3.16.

3-5-3 - Relation de dpendance d'instanciation

Figure 3.25 : Dpendance d'instanciation entre les classeurs et leurs instances. La relation de dpendance d'instanciation (strotype << instanceof >>) dcrit la relation entre un classeur et ses instances. Elle relie, en particulier, les liens aux associations et les objets aux classes.

3-6 - laboration et implmentation d'un diagramme de classes 3-6-1 - laboration d'un diagramme de classes
Une dmarche couramment utilise pour btir un diagramme de classes consiste :

Trouver les classes du domaine tudi.

Cette tape empirique se fait gnralement en collaboration avec un expert du domaine. Les classes correspondent gnralement des concepts ou des substantifs du domaine ;

Trouver les associations entre classes.

Les associations correspondent souvent des verbes, ou des constructions verbales, mettant en relation plusieurs classes, comme << est compos de >>, << pilote >>, << travaille pour >>.

Attention, mfiez-vous de certains attributs qui sont en ralit des relations entre classes.

Trouver les attributs des classes.

Les attributs correspondent souvent des substantifs, ou des groupes nominaux, tels que << la masse d'une voiture >> ou << le montant d'une transaction >>. Les adjectifs et les valeurs correspondent souvent des valeurs d'attributs. Vous pouvez ajouter des attributs toutes les tapes du cycle de vie d'un projet (implmentation comprise). N'esprez pas trouver tous les attributs ds la construction du diagramme de classes ;

Organiser et simplifier le modle. Itrer et raffiner le modle.

En liminant les classes redondantes et en utilisant l'hritage ;

Un modle est rarement correct ds sa premire construction. La modlisation objet est un processus non pas linaire, mais itratif.

- 52 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

3-6-2 - Implmentation en Java 3-6-2-a - Classe


Parfois, la gnration automatique de code produit, pour chaque classe, un constructeur et une mthode finalize comme ci-dessous. Rappelons que cette mthode est invoque par le ramasse-miettes lorsque celui-ci constate que l'objet n'est plus rfrenc. Pour des raisons de simplification, nous ne ferons plus figurer ces oprations dans les sections suivantes.

public class A { public A() { ... } protected void finalize() throws Throwable { super.finalize(); ... } }

3-6-2-b - Classe avec attributs et oprations

public class A { public String a1; package String a2; protected String a3; private String a4; public void op1() { ... } public void op2() { ... } }

3-6-2-c - Classe abstraite

public abstract class A { ... }

- 53 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

3-6-2-d - Interface

public interface A { ... }

3-6-2-e - Hritage simple

public class A { ... } public class B extends A { ... }

3-6-2-f - Ralisation d'une interface par une classe

public interface Ia { ... } public class A implements Ia { ... }

3-6-2-g - Association bidirectionnelle 1 vers 1

public class A { private B rb;


- 54 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

public void addB( B b ) { if( b != null ){ if ( b.getA() != null ) { // si b est dj connect un autre A b.getA().setB(null); // cet autre A doit se dconnecter } this.setB( b ); b.setA( this ); } } public B getB() { return( rb ); } public void setB( B b ) { this.rb=b; }

public class B { private A ra; public void addA( A a ) { if( a != null ) { if (a.getB() != null) { // si a est dj connect un autre B a.getB().setA( null ); // cet autre B doit se dconnecter } this.setA( a ); a.setB( this ); } } public void setA(A a){ this.ra=a; } public A getA(){ return(ra); } }

3-6-2-h - Association unidirectionnelle 1 vers 1

public class A { private B rb; public void addB( B b ) { if( b != null ) { this.rb=b; } } } public class B { ... // La classe B ne connat pas l'existence de la classe A }

3-6-2-i - Association bidirectionnelle 1 vers N

public class A { private ArrayList <B> rb; public A() { rb = new ArrayList<B>(); } public ArrayList <B> getArray() {return(rb);} public void remove(B b){rb.remove(b);} public void addB(B b){ if( !rb.contains(b) ){ if (b.getA()!=null) b.getA().remove(b); b.setA(this); rb.add(b); } } }

- 55 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

public class B { private A ra; public B() {} public A getA() { return (ra); } public void setA(A a){ this.ra=a; } public void addA(A a){ if( a != null ) { if( !a.getArray().contains(this)) { if (ra != null) ra.remove(this); this.setA(a); ra.getArray().add(this); } } } }

3-6-2-j - Association unidirectionnelle 1 vers plusieurs

public class A { private ArrayList <B> rb; public A() { rb = new ArrayList<B>(); } public void addB(B b){ if( !rb.contains( b ) ) { rb.add(b); } } } public class B { ... // B ne connat pas l'existence de A }

3-6-2-k - Association 1 vers N

Dans ce cas, il faut utiliser un tableau plutt qu'un vecteur. La dimension du tableau tant donne par la cardinalit de la terminaison d'association.

3-6-2-l - Agrgations

Les agrgations s'implmentent comme les associations.

3-6-2-m - Composition

Une composition peut s'implmenter comme une association unidirectionnelle.

- 56 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

3-6-3 - Implmentation en SQL 3-6-3-a - Introduction


Il est possible de traduire un diagramme de classe en modle relationnel. Bien entendu, les mthodes des classes ne sont pas traduites. Aujourd'hui, lors de la conception de base de donnes, il devient de plus en plus courant d'utiliser la modlisation UML plutt que le traditionnel modle entits-associations. Cependant, moins d'avoir respect une mthodologie adapte, la correspondance entre le modle objet et le modle relationnel n'est pas une tche facile. En effet, elle ne peut que rarement tre complte puisque l'expressivit d'un diagramme de classes est bien plus grande que celle d'un schma relationnel. Par exemple, comment reprsenter dans un schma relationnel des notions comme la navigabilit ou la composition ? Toutefois, de nombreux AGL (Atelier de Gnie Logiciel) comportent maintenant des fonctionnalits de traduction en SQL qui peuvent aider le dveloppeur dans cette tche. Dans la section 9.3.1, nous prsentons un type de diagramme de classes, appel modle du domaine, tout fait adapt une implmentation sous forme de base de donnes.

3-6-3-b - Classe avec attributs


Chaque classe devient une relation. Les attributs de la classe deviennent des attributs de la relation. Si la classe possde un identifiant, il devient la cl primaire de la relation, sinon, il faut ajouter une cl primaire arbitraire.

create table relation_A ( num_relation_A integer primary key, att1 text, att2 integer);

3-6-3-c - Association 1 vers 1


Pour reprsenter une association 1 vers 1 entre deux relations, la cl primaire de l'une des relations doit figurer comme cl trangre dans l'autre relation.

create table relation_A ( id_A integer primary key, attA1 text, attA2 integer); create table relation_B ( id_B integer primary key, num_A integer references relation_A, attB1 text, attB2 integer);

- 57 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

3-6-3-d - Association 1 vers plusieurs


Pour reprsenter une association 1 vers plusieurs, on procde comme pour une association 1 vers 1, except que c'est forcment la relation du ct plusieurs qui reoit comme cl trangre la cl primaire de la relation du ct 1.

create table relation_A ( id_A integer primary key, num_B integer references relation_B, attA1 text, attA2 integer); create table relation_B ( id_B integer primary key, attB1 text, attB2 integer);

3-6-3-e - Association plusieurs vers plusieurs


Pour reprsenter une association du type plusieurs vers plusieurs, il faut introduire une nouvelle relation dont les attributs sont les cls primaires des relations en association et dont la cl primaire est la concatnation de ces deux attributs.

create table relation_A ( id_A integer primary key, attA1 text, attA2 integer); create table relation_B ( id_B integer primary key, attB1 text, attB2 integer); create table relation_A_B ( num_A integer references relation_A, num_B integer references relation_B, primary key (num_A, num_B));

3-6-3-f - Classe-association plusieurs vers plusieurs


Le cas est proche de celui d'une association plusieurs vers plusieurs, les attributs de la classe-association tant ajouts la troisime relation qui reprsente, cette fois-ci, la classe-association elle-mme.

- 58 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

create table relation_A ( id_A integer primary key, attA1 text, attA2 integer); create table relation_B ( id_B integer primary key, attB1 text, attB2 integer); create table relation_C ( num_A integer references relation_A, num_B integer references relation_B, attC1 text, attC2 integer, primary key (num_A, num_B));

3-6-3-g - Hritage
Les relations correspondant aux sous-classes ont comme cls trangre et primaire la cl de la relation correspondant la classe parente. Un attribut type est ajout dans la relation correspondant la classe parente. Cet attribut permet de savoir si les informations d'un tuple de la relation correspondant la classe parente peuvent tre compltes par un tuple de l'une des relations correspondant une sous-classe, et, le cas chant, de quelle relation il s'agit. Ainsi, dans cette solution, un objet peut avoir ses attributs rpartis dans plusieurs relations. Il faut donc oprer des jointures pour reconstituer un objet. L'attribut type de la relation correspondant la classe parente doit indiquer quelles jointures faire.

create table relation_C ( id_C integer primary key, attC1 text, attC2 integer, type text); create table relation_A ( id_A references relation_C, attA1 text,
- 59 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

attA2 integer, primary key (id_A)); create table relation_B ( id_B references relation_C, attB1 text, attB2 integer, primary key (id_B));

Une option cette reprsentation est de ne crer qu'une seule table par arborescence d'hritage. Cette table doit contenir tous les attributs de toutes les classes de l'arborescence plus l'attribut type dont nous avons parl ci-dessus. L'inconvnient de cette solution est qu'elle implique que les tuples contiennent de nombreuses valeurs nulles.
create table relation_ABC ( id_C integer primary key, attC1 text, attC2 integer, attA1 text, attA2 integer, attB1 text, attB2 integer, type text);

4 - Chapitre 4 Langage de contraintes objet (Object Constraint Langage : OCL) 4-1 - Expression des contraintes en UML 4-1-1 - Introduction
Nous avons dj vu comment exprimer certaines formes de contraintes avec UML :

Contraintes structurelles :

les attributs dans les classes, les diffrents types de relations entre classes (gnralisation, association, agrgation, composition, dpendance), la cardinalit et la navigabilit des proprits structurelles, etc. ;

Contraintes de type :

typage des proprits, etc. ;

Contraintes diverses :

les contraintes de visibilit, les mthodes et classes abstraites (contrainte abstract), etc.

Dans la pratique, toutes ces contraintes sont trs utiles, mais se rvlent insuffisantes. Toutefois, UML permet de spcifier explicitement des contraintes particulires sur des lments de modle.

4-1-2 - criture des contraintes


Une contrainte constitue une condition ou une restriction smantique exprime sous forme d'instruction dans un langage textuel qui peut tre naturel ou formel. En gnral, une contrainte peut tre attache n'importe quel lment de modle ou liste d'lments de modle. Une contrainte dsigne une restriction qui doit tre applique par une implmentation correcte du systme. On reprsente une contrainte sous la forme d'une chane de texte place entre accolades ({}). La chane constitue le corps crit dans un langage de contrainte qui peut tre : naturel ; ddi, comme OCL ; ou encore directement issu d'un langage de programmation.

- 60 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Si une contrainte possde un nom, on prsente celui-ci sous forme d'une chane suivie d'un double point (:), le tout prcdant le texte de la contrainte.

4-1-3 - Reprsentation des contraintes et contraintes prdfinies

Figure 4.1 : UML permet d'associer une contrainte un lment de modle de plusieurs faons. Sur les deux diagrammes du haut, la contrainte porte sur un attribut qui doit tre positif. En bas gauche, la contrainte {frozen} prcise que le nombre de roues d'un vhicule ne peut pas varier. Au milieu, la contrainte {subset} prcise que le prsident est galement un membre du comit. Enfin, en bas droite, la contrainte {xor} (ou exclusif) prcise que les employs de l'htel n'ont pas le droit de prendre une chambre dans ce mme htel.

Figure 4.2 : Ce diagramme exprime que : une personne est ne dans un pays, et que cette association ne peut tre modifie ; une personne a visit un certain nombre de pays, dans un ordre donn, et que le nombre de pays visits ne peut que crotre ; une personne aimerait encore visiter toute une liste de pays, et que cette liste est ordonne (probablement par ordre de prfrence). UML permet d'associer une contrainte un, ou plusieurs, lment(s) de modle de diffrentes faons (cf. figure 4.1) : en plaant directement la contrainte ct d'une proprit ou d'une opration dans un classeur ; en ajoutant une note associe l'lment contraindre ; en plaant la contrainte proximit de l'lment contraindre, comme une extrmit d'association par exemple ; en plaant la contrainte sur une flche en pointills joignant les deux lments de modle contraindre ensemble, la direction de la flche constituant une information pertinente au sein de la contrainte ; en plaant la contrainte sur un trait en pointills joignant les deux lments de modle contraindre ensemble dans le cas o la contrainte est bijective ; en utilisant une note relie, par des traits en pointills, chacun des lments de modle, subissant la contrainte commune, quand cette contrainte s'applique sur plus de deux lments de modle.
- 61 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Nous venons de voir, au travers des exemples de la figure 4.1, quelques contraintes prdfinies ({frozen}, {subset} et {xor}). Le diagramme de la figure 4.2 en introduit deux nouvelles : {ordered} et {addOnly}. La liste est encore longue, mais le pouvoir expressif de ces contraintes reste insuffisant comme nous le verrons dans la section 4.2.2. Le langage de contraintes objet OCL apporte une solution lgante cette insuffisance.

4-2 - Intrt d'OCL 4-2-1 - OCL - Introduction 4-2-1-a - QuesacOCL ?


C'est avec OCL (Object Constraint Language) qu'UML formalise l'expression des contraintes. Il s'agit donc d'un langage formel d'expression de contraintes bien adapt aux diagrammes d'UML, et en particulier au diagramme de classes. OCL existe depuis la version 1.1 d'UML et est une contribution d'IBM. OCL fait partie intgrante de la norme UML depuis la version 1.3 d'UML. Dans le cadre d'UML 2.0, les spcifications du langage OCL figurent dans un document indpendant de la norme d'UML, dcrivant en dtail la syntaxe formelle et la faon d'utiliser ce langage. OCL peut s'appliquer sur la plupart des diagrammes d'UML et permet de spcifier des contraintes sur l'tat d'un objet ou d'un ensemble d'objets comme : des invariants sur des classes ; des prconditions et des postconditions l'excution d'oprations : les prconditions doivent tre vrifies avant l'excution, les postconditions doivent tre vrifies aprs l'excution ; des gardes sur des transitions de diagrammes d'tats-transitions ou des messages de diagrammes d'interaction ; des ensembles d'objets destinataires pour un envoi de message ; des attributs drivs, etc.

4-2-1-b - Pourquoi OCL ?


Nous avons dit que les contraintes pouvaient tre crites en langage naturel, alors pourquoi s'embarrasser du langage OCL ? L'intrt du langage naturel est qu'il est simple mettre en uvre et comprhensible par tous. Par contre (et comme toujours), il est ambigu et imprcis, il rend difficile l'expression des contraintes complexes et ne facilite pas les rfrences d'autres lments (autres que celui sur lequel porte la contrainte) du modle. OCL est un langage formel volontairement simple d'accs. Il possde une grammaire lmentaire (OCL peut tre interprt par des outils) que nous dcrirons dans les sections 4.3 4.6. OCL reprsente, en fait, un juste milieu entre le langage naturel et un langage trs technique (langage mathmatique, informatique). Il permet ainsi de limiter les ambiguts, tout en restant accessible.

4-2-2 - Illustration par l'exemple 4-2-2-a - Mise en situation


Plaons-nous dans le contexte d'une application bancaire. Il nous faut donc grer : des comptes bancaires ; des clients ; et des banques.
- 62 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

De plus, on aimerait intgrer les contraintes suivantes dans notre modle : un compte doit avoir un solde toujours positif ; un client peut possder plusieurs comptes ; une personne peut tre cliente de plusieurs banques ; un client d'une banque possde au moins un compte dans cette banque ; un compte appartient forcment un client ; une banque gre plusieurs comptes ; une banque possde plusieurs clients.

4-2-2-b - Diagramme de classes

Figure 4.3 : Diagramme de classes modlisant une banque, ses clients et leurs comptes. La figure 4.3 montre un diagramme de classes correspondant la problmatique que nous venons de dcrire.

Figure 4.4 : Ajout d'une contrainte sur le diagramme de la figure 4.3. Un premier problme apparat immdiatement : rien ne spcifie, dans ce diagramme, que le solde du client doit toujours tre positif. Pour rsoudre le problme, on peut simplement ajouter une note prcisant cette contrainte ({solde > 0}), comme le montre la figure 4.4.
- 63 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 4.5 : Diagramme d'objets cohrent avec le diagramme de classes de la figure 4.4.

Figure 4.6 : Diagramme d'objets cohrent avec le diagramme de classes de la figure 4.4, mais reprsentant une situation inacceptable. Cependant, d'autres problmes subsistent. La figure 4.5 montre un diagramme d'objets valide vis--vis du diagramme de classes de la figure 4.4 et galement valide vis--vis de la spcification du problme. Par contre, la figure 4.6 montre un diagramme d'objets valide vis--vis du diagramme de classes de la figure 4.4 mais ne respectant pas la spcification du problme. En effet, ce diagramme d'objets montre une personne (P1) ayant un compte dans une banque sans en tre client. Ce diagramme montre galement un client (P2) d'une banque n'y possdant pas de compte. context Compte inv : solde > 0 context Compte :: dbiter(somme : int) pre : somme > 0 post : solde = solde@pre - somme context Compte inv : banque.clients -> includes (propritaire)

Figure 4.7 : Exemple d'utilisation du langage de contrainte OCL sur l'exemple bancaire.
- 64 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Le langage OCL est particulirement adapt la spcification de ce type de contrainte. La figure 4.7 montre le diagramme de classes de notre application bancaire accompagn des contraintes OCL adaptes la spcification du problme. Faites bien attention au fait qu'une expression OCL dcrit une contrainte respecter et ne dcrit absolument pas l'implmentation d'une mthode.

4-3 - Typologie des contraintes OCL 4-3-1 - Diagramme support des exemples illustratifs

Figure 4.8 : Diagramme de classes modlisant une entreprise et des personnes. Le diagramme de la figure 4.8 modlise des personnes, leurs liens de parent (enfant/parent et mari/femme) et le poste ventuel de ces personnes dans une socit. Ce diagramme nous servira de support aux diffrents exemples de contraintes que nous donnerons, titre d'illustration, dans les sections qui suivent (4.3 4.7).

Figure 4.9 : Dfinition d'une numration en utilisant un classeur. Ce diagramme introduit un nouveau type de classeur, strotyp enumeration , permettant de dfinir une numration. Une numration est un type de donne UML, possdant un nom, et utilis pour numrer un ensemble de littraux correspondant toutes les valeurs possibles que peut prendre une expression de ce type. Un type numr est dfini par un classeur possdant le strotype enumeration comme reprsent sur la figure 4.9.

- 65 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

4-3-2 - Contexte (context)


Une contrainte est toujours associe un lment de modle. C'est cet lment qui constitue le contexte de la contrainte. Il existe deux manires pour spcifier le contexte d'une contrainte OCL : en crivant la contrainte entre accolades ({}) dans une note (comme nous l'avons fait sur la figure 4.4). L'lment point par la note est alors le contexte de la contrainte ; en utilisant le mot-clef context dans un document accompagnant le diagramme (comme nous l'avons fait sur la figure 4.7).

4-3-2-a - Syntaxe
context <lment>

<lment> peut tre une classe, une opration, etc. Pour faire rfrence un lment op (comme un opration) d'un classeur C (comme une classe), ou d'un paquetage il faut utiliser les :: comme sparateur (comme C::op).

4-3-2-b - Exemple
Le contexte est la classe Compte : context Compte Le contexte est l'opration getSolde() de la classe Compte : context Compte::getSolde()

4-3-3 - Invariants (inv)


Un invariant exprime une contrainte prdicative sur un objet, ou un groupe d'objets, qui doit tre respecte en permanence.

4-3-3-a - Syntaxe
inv : <expression_logique>

<expression_logique> est une expression logique qui doit toujours tre vraie.

4-3-3-b - Exemple
Le solde d'un compte doit toujours tre positif. context Compte inv : solde > 0 Les femmes (au sens de l'association) des personnes doivent tre des femmes (au sens du genre). context Personne inv : femme->forAll(genre=Genre::femme) self est dcrit section 4.5.1 et forAll() section 4.6.3.
- 66 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

4-3-4 - Prconditions et postconditions (pre, post)


Une prcondition (respectivement une postcondition) permet de spcifier une contrainte prdicative qui doit tre vrifie avant (respectivement aprs) l'appel d'une opration. Dans l'expression de la contrainte de la postcondition, deux lments particuliers sont utilisables : l'attribut result qui dsigne la valeur retourne par l'opration ; et <nom_attribut>@pre qui dsigne la valeur de l'attribut <nom_attribut> avant l'appel de l'opration.

4-3-4-a - Syntaxe
Prcondition :
pre : <expression_logique> post : <expression_logique>

Postcondition :

<expression_logique> est une expression logique qui doit toujours tre vraie.

4-3-4-b - Exemple
Concernant la mthode dbiter de la classe Compte, la somme dbiter doit tre positive pour que l'appel de l'opration soit valide et, aprs l'excution de l'opration, l'attribut solde doit avoir pour valeur la diffrence de sa valeur avant l'appel et de la somme passe en paramtre. context Compte::dbiter(somme : Real) pre : somme > 0 post : solde = solde@pre - somme Le rsultat de l'appel de l'opration getSolde doit tre gal l'attribut solde. context Compte::getSolde() : Real post : result = solde Mme si cela peut sembler tre le cas dans ces exemples, nous n'avons pas dcrit comment l'opration est ralise, mais seulement les contraintes sur l'tat avant et aprs son excution.

4-3-5 - Rsultat d'une mthode (body)


Ce type de contrainte permet de dfinir directement le rsultat d'une opration.

4-3-5-a - Syntaxe
body : <requte>

<requte> est une expression qui retourne un rsultat dont le type doit tre compatible avec le type du rsultat de l'opration dsigne par le contexte.

- 67 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

4-3-5-b - Exemple
Voici une autre solution au deuxime exemple de la section 4.3.4 : le rsultat de l'appel de l'opration getSolde doit tre gal l'attribut solde. context Compte::getSolde() : Real body : solde

4-3-6 - Dfinition d'attributs et de mthodes (def et letin)


Parfois, une sous-expression est utilise plusieurs fois dans une expression. let permet de dclarer et de dfinir la valeur (i.e. initialiser) d'un attribut qui pourra tre utilis dans l'expression qui suit le in. def est un type de contrainte qui permet de dclarer et de dfinir la valeur d'attributs comme la squence letin. def permet galement de dclarer et de dfinir la valeur retourne par une opration interne la contrainte.

4-3-6-a - Syntaxe de letin


let <dclaration> = <requte> in <expression>

Un nouvel attribut dclar dans <dclaration> aura la valeur retourne par l'expression <requte> dans toute l'expression <expression>. Reportez-vous la section 4.7 pour un exemple d'utilisation.

4-3-6-b - Syntaxe de def


def : <dclaration> = <requte>

<dclaration> peut correspondre la dclaration d'un attribut ou d'une mthode. <requte> est une expression qui retourne un rsultat dont le type doit tre compatible avec le type de l'attribut, ou de la mthode, dclar dans <dclaration>. Dans le cas o il s'agit d'une mthode, <requte> peut utiliser les paramtres spcifis dans la dclaration de la mthode.

4-3-6-c - Exemple
Pour imposer qu'une personne majeure doit avoir de l'argent, on peut crire indiffremment : context Personne inv : let argent=compte.solde->sum() in age>=18 implies argent>0 context Personne def : argent : int = compte.solde->sum() context Personne inv : age>=18 implies argent>0 sum() est dcrit section 4.6.2.

4-3-7 - Initialisation (init) et volution des attributs (derive)


Le type de contrainte init permet de prciser la valeur initiale d'un attribut ou d'une terminaison d'association.

- 68 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Les diagrammes d'UML dfinissent parfois des attributs ou des associations drives. La valeur de tels lments est toujours dtermine en fonctions d'autres lments du diagramme. Le type de contrainte derive permet de prciser comment la valeur de ce type d'lment volue. Notez bien la diffrence entre ces deux types de contraintes. La contrainte derive impose une contrainte perptuelle : l'lment driv doit toujours avoir la valeur impose par l'expression de la contrainte derive. D'un autre ct, la contrainte init ne s'applique qu'au moment de la cration d'une instance prcise par le contexte de la contrainte. Ensuite, la valeur de l'lment peut fluctuer indpendamment de la contrainte init.

4-3-7-a - Syntaxe
init : <requte> derive : <requte>

4-3-7-b - Exemple
Quand on cre une personne, la valeur initiale de l'attribut mari est faux et la personne ne possde pas d'employeur : context Personne::mari : Boolean init : false context Personne::employeur : Set(Socit) init : Set{} Les collections (dont Set est une instance) sont dcrites section 4.4.4. Set{} correspond un ensemble vide. L'ge d'une personne est la diffrence entre la date courante et la date de naissance de la personne : context Personne::age : Integer derive : date_de_naissance - Date::current() On suppose ici que le type Date possde une mthode de classe permettant de connatre la date courante et que l'opration moins (-) entre deux dates est bien dfinie et retourne un nombre d'annes.

4-4 - Types et oprations utilisables dans les expressions OCL 4-4-1 - Types et oprateurs prdfinis
Le langage OCL possde un certain nombre de types prdfinis et d'oprations prdfinies sur ces types. Ces types et ces oprations sont utilisables dans n'importe quelle contrainte et sont indpendants du modle auquel sont rattaches ces contraintes. Le tableau 4.1 donne un aperu des types et oprations prdfinis dans les contraintes OCL. Les tableaux 4.2 et 4.3 rappellent les conventions d'interprtation des oprateurs logiques. L'oprateur logique if-then-else-endif est un peu particulier. Sa syntaxe est la suivante :
if <expression_logique_0> then <expression_logique_1> else <expression_logique_2> endif

Cet oprateur s'interprte de la faon suivante : si <expression_logique_0> est vrai, alors la valeur de vrit de l'expression est celle de <expression_logique_1>, sinon, c'est celle de <expression_logique_2>.

- 69 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Boolean Integer Real String

Type

Exemples de valeurs true ; false 1 ; 5 ; 2 ; 34 ; 26524 ; 1,5 ; 3,14 ; "To be or not to be "

Oprateurs and ; or ; xor ; not ; implies ; if-then-else-endif ; * ; + ; ; / ; abs() ; * ; + ; ; / ; abs() ; floor() ; concat() ; size() ; substring() ;

E1 VRAI VRAI FAUX FAUX

E2 VRAI FAUX VRAI FAUX

P1 and P2 VRAI FAUX FAUX FAUX

P1 or P2 VRAI VRAI VRAI FAUX

P1 xor P2 FAUX VRAI VRAI FAUX

P1 implies P2 VRAI FAUX VRAI VRAI

expression VRAI FAUX

not expression FAUX VRAI

4-4-2 - Types du modle UML


Toute expression OCL est crite dans le contexte d'un modle UML donn. Bien entendu, tous les classeurs de ce modle sont des types dans les expressions OCL attaches ce modle. Dans la section 4.3.1, nous avons introduit le type numr. Une contrainte OCL peut rfrencer une valeur de ce type de la manire suivante :
<nom_type_enumr>::valeur

Par exemple, la classe Personne possde un attribut genre de type Genre. On peut donc crire la contrainte :
context Personne inv : genre = Genre::femme

Dans ce cas, toutes les personnes doivent tre des femmes.

4-4-3 - OCL est un langage typ


OCL est un langage typ dont les types sont organiss sous forme de hirarchie. Cette hirarchie dtermine comment diffrents types peuvent tre combins. Par exemple, il est impossible de comparer un boolen (Boolean) avec un entier (Integer) ou une chane de caractres (String). Par contre, il est possible de comparer un entier (Integer) et un rel (Real), car le type entier est un sous-type du type rel dans la hirarchie des types OCL. Bien entendu, la hirarchie des types du modle UML est donne par la relation de gnralisation entre les classeurs du modle UML.

4-4-4 - Collections
OCL dfinit galement la notion d'ensemble sous le terme gnrique de collection (collection en anglais). Il existe plusieurs sous-types du type abstrait Collection : Ensemble ( Set ) :

- 70 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

collection non ordonne d'lments uniques (i.e. pas d'lment en double) ; Ensemble ordonn ( OrderedSet ) : collection ordonne d'lments uniques ; Sac ( Bag ) : collection non ordonne d'lments identifiables (i.e. comme un ensemble, mais pouvant comporter des doublons) ; Squence ( Sequence ) : collection ordonne d'lments identifiables. Jusqu' UML 2.0 exclu, les collections taient toujours plates : une collection ne pouvait pas possder des collections comme lments. Cette restriction n'existe plus partir d'UML 2.0.

4-5 - Accs aux caractristiques et aux objets


Dans une contrainte OCL associe un objet, il est possible d'accder aux caractristiques (attributs, oprations et terminaison d'association) de cet objet, et donc, d'accder de manire transitive tous les objets (et leurs caractristiques) avec lesquels il est en relation.

4-5-1 - Accs aux attributs et aux oprations (self)


Pour faire rfrence un attribut ou une opration de l'objet dsign par le contexte, il suffit d'utiliser le nom de cet lment. L'objet dsign par le contexte est galement accessible par l'expression self. On peut donc galement utiliser la notation pointe : self.<proprit>. Une opration peut avoir des paramtres, il faut alors les prciser entre les parenthses de l'opration. Lorsque la multiplicit d'un attribut, de type T, n'est pas 1 (donc s'il s'agit d'un tableau), la rfrence cet attribut est du type ensemble (i.e. Set(T)). Par exemple, dans le contexte de la classe Compte, on peut utiliser les expressions suivantes : solde ; self.solde ; getSolde() ; self.getSolde() ; dbiter(1000) ; self.dbiter(1000).

Dans l'exemple prcdent, le rsultat de l'expression self.dbiter(1000) est un singleton du type Real. Mais une opration peut comporter des paramtres dfinis en sortie ou en entre/sortie. Dans ce cas, le rsultat sera un tuple contenant tous les paramtres dfinis en sortie ou en entre/sortie. Par exemple, imaginons une opration dont la dclaration serait operation(out param_out : Integer):Real possdant un paramtre dfini en sortie param_out. Dans ce cas, le rsultat de l'expression operation(paramtre) est un tuple de la forme (param_out : Integer, result : Real). On peut accder aux valeurs de ce tuple de la faon suivante :
operation(paramtre).param_out operation(paramtre).result

- 71 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

4-5-2 - Navigation via une association


Pour faire rfrence un objet, ou un groupe d'objets, en association avec l'objet dsign par le contexte, il suffit d'utiliser le nom de la classe associe (en minuscules) ou le nom du rle d'association du ct de cette classe. Quand c'est possible, il est prfrable d'utiliser le nom de rle de l'association du ct de l'objet auquel on dsire faire rfrence. C'est indispensable s'il existe plusieurs associations entre l'objet dsign par le contexte et l'objet auquel on dsire accder, ou si l'association emprunte est rflexive. Le type du rsultat dpend de la proprit structurelle emprunte pour accder l'objet rfrenc, et plus prcisment de la multiplicit du ct de l'objet rfrenc, et du type de l'objet rfrenc proprement dit. Si on appelle X la classe de l'objet rfrenc, dans le cas d'une multiplicit de : 1, le type du rsultat est X (ex. : * ou 0..n, le type du rsultat est Set(X) (ex. : ); * ou 0..n, et s'il y a en plus une contrainte {ordered}, le type du rsultat est OrderedSet(X) (ex. : ). Emprunter une seule proprit structurelle peut produire un rsultat du type Set (ou OrderedSet). Emprunter plusieurs proprits structurelles peut produire un rsultat du type Bag (ou Sequence). Par exemple, dans le contexte de la classe Socit (context Socit) : directeur dsigne le directeur de la socit (rsultat de type Personne) ; employ dsigne l'ensemble des employs de la socit (rsultat de type Set(Personne)) ; employ.compte dsigne l'ensemble des comptes de tous les employs de la socit (rsultat de type Bag(Compte)) ; employ.date_de_naissance dsigne l'ensemble des dates de naissance des employs de la socit (rsultat de type Bag(Date)). );

4-5-3 - Navigation via une association qualifie

Figure 4.10 : Diagramme illustrant une association qualifie entre une classe Banque et une classe Personne.

- 72 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Une association qualifie (cf. section3.3.6) utilise un ou plusieurs qualificatifs pour slectionner des instances de la classe cible de l'association. Pour emprunter une telle association, il est possible de spcifier les valeurs, ou les instances, des qualificatifs en utilisant des crochets ([]). Plaons-nous dans le cadre du diagramme de la figure 4.10. Dans le contexte de banque (context Banque), pour faire rfrence au nom des clients dont le compte porte le numro 19503800 il faut crire :
self.client[19503800].nom

Dans le cas o il y a plusieurs qualificatifs, il faut sparer chacune des valeurs par une virgule en respectant l'ordre des qualificatifs du diagramme UML. Il n'est pas possible de ne prciser la valeur que de certains qualificatifs en en laissant d'autres non dfinis. Par contre, il est possible de ne prciser aucune valeur de qualificatif :
self.client.nom

Dans ce cas, le rsultat sera l'ensemble des noms de tous les clients de la banque. Ainsi, si on ne prcise pas la valeur des qualificatifs en empruntant une association qualifie, tout se passe comme si l'association n'tait pas qualifie. Dans ce cas, faites attention la cardinalit de la cible qui change quand l'association n'est plus qualifie (cf. section 3.3.6).

4-5-4 - Navigation vers une classe association


Pour naviguer vers une classe association, il faut utiliser la notation pointe classique en prcisant le nom de la classe association en minuscules. Par exemple, dans le contexte de la classe Socit (context Socit), pour accder au salaire de tous les employs, il faut crire :
self.poste.salaire

Cependant, dans le cas o l'association est rflexive (c'est le cas de la classe association Mariage), il faut en plus prciser par quelle extrmit il faut emprunter l'association. Pour cela, on prcise le nom de rle de l'une des extrmits de l'association entre crochets ([]) derrire le nom de la classe association. Par exemple, dans le contexte de la classe Personne (context Personne), pour accder la date de mariage de toutes les femmes, il faut crire :
self.mariage[femme].date

4-5-5 - Navigation depuis une classe association


Il est tout fait possible de naviguer directement depuis une classe association vers une classe participante. Exemple :
context Poste inv : self.employ.age > 21

Par dfinition mme d'une classe association, naviguer depuis une classe association vers une classe participante produit toujours comme rsultat un objet unique. Par exemple, l'expression self.employ.age de l'exemple prcdant produit bien un singleton.

4-5-6 - Accder une caractristique redfinie (oclAsType())


Quand une caractristique dfinie dans une classe parente est redfinie dans une sous-classe associe, la caractristique de la classe parente reste accessible dans la sous-classe en utilisant l'expression oclAsType().

- 73 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Supposons une classe B hritant d'une classe A et une proprit p1 dfinie dans les deux classes. Dans le contexte de la classe B (context B), pour accder la proprit p1 de B, on crit simplement :
self.p1

et pour accder la proprit p1 de A (toujours dans le contexte de B), il faut crire :


self.oclAsType(A).p1

4-5-7 - Oprations prdfinies sur tous les objets


L'opration oclAsType, que nous venons de dcrire (section 4.5.6), est une opration prdfinie dans le langage OCL qui peut tre applique tout objet. Le langage OCL en propose plusieurs : oclIsTypeOf (t : OclType) : Boolean oclIsKindOf (t : OclType) : Boolean oclInState (s : OclState) : Boolean oclIsNew () : Boolean oclAsType (t : OclType) : instance of OclType

4-5-7-a - Opration oclIsTypeOf


oclIsTypeOf retourne vrai si le type de l'objet au titre duquel cette opration est invoque est exactement le mme que le type t pass en paramtre. Par exemple, dans le contexte de Socit, l'expression directeur.oclIsTypeOf(Personne) est vraie tandis que l'expression self.oclIsTypeOf(Personne) est fausse.

4-5-7-b - Opration oclIsKindOf


oclIsKindOf permet de dterminer si le type t pass en paramtre correspond exactement au type ou un type parent du type de l'objet au titre duquel cette opration est invoque. Par exemple, supposons une classe B hritant d'une classe A : dans le contexte de B, l'expression self.oclIsKindOf(B) est vraie ; toujours dans le contexte de B, l'expression self.oclIsKindOf(A) est vraie ; mais dans le contexte de A, l'expression self.oclIsKindOf(B) est fausse.

4-5-7-c - Opration oclIsNew


L'opration oclIsNew doit tre utilise dans une postcondition. Elle est vraie quand l'objet au titre duquel elle est invoque est cr pendant l'opration (i.e. l'objet n'existait pas au moment des prconditions).

4-5-7-d - Opration oclInState


Cette opration est utilise dans un diagramme d'tats-transitions (cf. section 5). Elle est vraie si l'objet dcrit par le diagramme d'tats-transitions est dans l'tat s pass en paramtre. Les valeurs possibles du paramtre s sont les noms des tats du diagramme d'tats-transitions. On peut faire rfrence un tat imbriqu en utilisant des :: (par exemple, pour faire rfrence un tat B imbriqu dans un tat A, on crit : A::B).

- 74 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

4-5-8 - Opration sur les classes


Toutes les oprations que nous avons dcrites jusqu'ici s'appliquaient sur des instances de classe. Cependant, OCL permet galement d'accder des caractristiques de classe (celles qui sont soulignes dans un diagramme de classes). Pour cela, on utilise le nom qualifi de la classe suivi d'un point puis du nom de la proprit ou de l'opration : <nom_qualifi>.<proprit>. Le langage OCL dispose galement d'une opration prdfinie sur les classes, les interfaces et les numrations (allInstances) qui retourne l'ensemble (Set) de toutes les instances du type au titre duquel elle est invoque, au moment o l'expression est value. Par exemple, pour dsigner l'ensemble des instances de la classe personne (type set(Personne)) on crit :
Personne.allInstances()

4-6 - Oprations sur les collections 4-6-1 - Introduction : . , -> , :: et self


Comme nous l'avons vu dans la section prcdente (4.5), pour accder aux caractristiques (attributs, terminaisons d'associations, oprations) d'un objet, OCL utilise la notation pointe : <objet>.<proprit>. Cependant, de nombreuses expressions ne produisent pas comme rsultat un objet, mais une collection. Le langage OCL propose plusieurs oprations de base sur les collections. Pour accder ce type d'opration, il faut, utiliser non pas un point, mais une flche : <collection>-><opration>. Enfin, rappelons que pour dsigner un lment dans un lment englobant on utilise les :: (cf. Section 4.3.2 et 4.5.7 par exemple). En rsum :

::

permet de dsigner un lment (comme une opration) dans un lment englobant (comme un classeur ou un paquetage) ;

permet d'accder une caractristique (attributs, terminaisons d'associations, oprations) d'un objet ;

->

permet d'accder une caractristique d'une collection.

Nous avons dit dans la section 4.5.1 que l'objet dsign par le contexte est galement accessible par l'expression self. self n'est pas uniquement utilis pour dsigner le contexte d'une contrainte dans une expression, mais galement pour dsigner le contexte d'une sous-expression dans le texte (en langage naturel). Ainsi, lorsque l'on utilise self pour une opration <opration>, c'est pour dsigner l'objet (comme une collection par exemple) sur lequel porte l'opration. Cet objet peut tre le rsultat d'une opration intermdiaire comme l'valuation de l'expression <expression> prcdant l'opration <opration> dans l'expression complte : <expression>.<opration>.

4-6-2 - Oprations de base sur les collections


Nous ne dcrirons pas toutes les oprations sur les collections et ses sous-types (ensemble) dans cette section. Rfrez-vous la documentation officielle [19] pour plus d'exhaustivit.

4-6-2-a - Oprations de base sur les collections


Nous dcrivons ici quelques oprations de base sur les collections que propose le langage OCL.

- 75 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

size():Integer

retourne le nombre d'lments (la cardinalit) de self.

includes(objet:T):Boolean

vrai si self contient l'objet objet.

excludes(objet:T):Boolean count(objet:T):Integer

vrai si self ne contient pas l'objet objet.

retourne le nombre d'occurrences de objet dans self.

includesAll(c:Collection(T)):Boolean

vrai si self contient tous les lments de la collection c.

excludesAll(c:Collection(T)):Boolean isEmpty()

vrai si self ne contient aucun lment de la collection c.

vrai si self est vide.

notEmpty() sum():T

vrai si self n'est pas vide.

retourne la somme des lments de self. Les lments de self doivent supporter l'oprateur somme (+) et le type du rsultat dpend du type des lments.

product(c2:Collection(T2)):Set(Tuple(first:T,second:T2)) 4-6-2-b - Oprations de base sur les ensembles (Set)

le rsultat est la collection de Tuples correspondant au produit cartsien de self (de type Collection(T)) par c2.

Nous dcrivons ici quelques oprations de base sur les ensembles (type Set) que propose le langage OCL.

union(set:Set(T)):Set(T)

retourne l'union de self et set.

union(bag:Bag(T)):Bag(T) =(set:Set(T)):Boolean

retourne l'union de self et bag.

vrai si self et set contiennent les mmes lments.

intersection(set:Set(T)):Set(T)
intersection entre self et set.

intersection(bag:Bag(T)):Set(T)
intersection entre self et bag. (12)

- 76 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

including(objet:T):Set(T)

Le rsultat contient tous les lments de self plus l'objet objet.

excluding(objet:T):Set(T) -(set:Set(T)):Set(T)

Le rsultat contient tous les lments de self sans l'objet objet.

Le rsultat contient tous les lments de self sans ceux de set.

asOrderedSet():OrderedSet(T) asSequence():Sequence(T) asBag():Bag(T)

permet de convertir self du type Set(T) en OrderedSet(T).

permet de convertir self du type Set(T) en Sequence(T).

permet de convertir self du type Set(T) en Bag(T).

Les sacs (type Bag) disposent d'oprations analogues.

4-6-2-c - Exemples
1 2 3 Une socit a au moins un employ : context Socit inv : self.employ->notEmpty() Une socit possde exactement un directeur : context Socit inv : self.directeur->size()=1 Le directeur est galement un employ : context Socit inv : self.employ->includes(self.directeur)

4-6-3 - Opration sur les lments d'une collection 4-6-3-a - Syntaxe gnrale
La syntaxe d'une opration portant sur les lments d'une collection est la suivante :
<collection> -> <opration>( <expression> )

Dans tous les cas, l'expression <expression> est value pour chacun des lments de la collection <collection>. L'expression <expression> porte sur les caractristiques des lments en les citant directement par leur nom. Le rsultat dpend de l'opration <opration>. Parfois, dans l'expression <expression>, il est prfrable de faire rfrence aux caractristiques de l'lment courant en utilisant la notation pointe : <lment>.<proprit>. Pour cela, on doit utiliser la syntaxe suivante :
<collection> -> <opration>( <lment> | <expression> )

<lment> joue alors un rle d'itrateur et sert de rfrence l'lment courant dans l'expression <expression>. Il est galement possible, afin d'tre plus explicite, de prciser le type de cet lment :
<collection> -> <opration>( <lment> : <Type> | <expression> )

- 77 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

La syntaxe gnrale d'une opration portant sur les lments d'une collection est donc la suivante :
<collection> -> <opration>( [ <lment> [ : <Type> ] | ] <expression> )

4-6-3-b - Opration select et reject


Ces deux oprations permettent de gnrer une sous-collection en filtrant les lments de la collection self. Leur syntaxe est la suivante :
select( [ <lment> [ : <Type> ] | ] <expression_logique> ) reject( [ <lment> [ : <Type> ] | ] <expression_logique> )

select

permet de gnrer une sous-collection de self ne contenant que des lments qui satisfont l'expression logique <expression_logique>.

reject

permet de gnrer une sous-collection contenant tous les lments de self except ceux qui satisfont l'expression logique <expression_logique>.

Par exemple, pour crire une contrainte imposant que toute socit doit possder, parmi ses employs, au moins une personne de plus de 50 ans, on peut crire indiffremment : 1 2 3 context Socit inv: self.employ->select(age > 50)->notEmpty() context Socit inv: self.employ->select(individu | individu.age > 50)->notEmpty() context Socit inv: self.employ->select(individu : Personne | individu.age > 50)->notEmpty()

4-6-3-c - Opration forAll et exists


Ces deux oprations permettent de reprsenter le quantificateur universel () et le quantificateur existentiel (). Le rsultat de ces oprations est donc du type Boolean. Leur syntaxe est la suivante :
forAll( [ <lment> [ : <Type> ] | ] <expression_logique> ) exists( [ <lment> [ : <Type> ] | ] <expression_logique> )

forAll

permet d'crire une expression logique vraie si l'expression <expression_logique> est vraie pour tous les lments de self.

exists

permet d'crire une expression logique vraie si l'expression <expression_logique> est vraie pour au moins un lment de self.

Par exemple, pour crire une contrainte imposant que toute socit doit possder, parmi ses employs, au moins une personne de plus de 50 ans, on peut crire : context Socit inv: self.employ->exists(age > 50)

- 78 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

L'opration forAll possde une variante tendue possdant plus d'un itrateur. Dans ce cas, chacun des itrateurs parcourra l'ensemble de la collection. Concrtement, une opration forAll comportant deux itrateurs est quivalente une opration forAll n'en comportant qu'un, mais ralise sur le produit cartsien de self par lui-mme. Par exemple, imposer qu'il n'existe pas deux instances de la classe Personne pour lesquelles l'attribut nom a la mme valeur, c'est--dire pour imposer que deux personnes diffrentes ont un nom diffrent, on peut crire indiffremment : 1 2 context Personne inv: Personne.allInstances()->forAll(p1, p2 | p1 <> p2 implies p1.nom <> p2.nom) context Personne inv: (Personne.allInstances().product(Personne.allInstances())) ->forAll(tuple | tuple.first <> tuple.second implies tuple.first.nom <> tuple.second.nom)

4-6-3-d - Opration collect


Cette opration permet de construire une nouvelle collection en utilisant la collection self. La nouvelle collection construite possde le mme nombre d'lments que la collection self, mais le type de ces lments est gnralement diffrent. La syntaxe de l'oprateur collect est la suivante :
collect( [ <lment> [ : <Type> ] | ] <expression> )

Pour chaque lment de la collection self, l'oprateur collect value l'expression <expression> sur cet lment et ajoute le rsultat dans la collection gnre. Par exemple, pour dfinir la collection des dates de naissance des employs d'une socit, il faut crire, dans le contexte de la classe Socit :
self.employ->collect(date_de_naissance)

Puisque, toujours dans le contexte de la classe Socit, l'expression self.employ->collect(date_de_naissance)>size() = self.employ->size() est toujours vraie, il faut en conclure que le rsultat d'une opration collect sur une collection du type Set n'est pas du type Set, mais du type Bag. En effet, dans le cadre de notre exemple, il y aura certainement des doublons dans les dates de naissance.

4-6-4 - Rgles de prcdence des oprateurs


Ordre de prcdence pour les oprateurs par ordre de priorit dcroissante : 1 2 3 4 5 6 7 8 9 10 @pre . et -> not et - (oprateur unaire) * et / + et -(oprateur binaire) if-then-else-endif <, >, <= et >= = et <> and, or et xor implies

Les parenthses, ( et ) , permettent de changer cet ordre.

4-7 - Exemples de contraintes

- 79 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 4.11 : Reprise du diagramme de la figure 4.8. Dans cette section, nous allons illustrer par quelques exemples l'utilisation du langage OCL. Nous restons toujours sur le diagramme de classes de la figure 4.8 reprsent nouveau sur la figure 4.11 pour des raisons de proximit. Dans une socit, le directeur est un employ, n'est pas un chmeur et doit avoir plus de 40 ans. De plus, une socit possde exactement un directeur et au moins un employ.
context Socit inv : self.directeur->size()=1 and not(self.directeur.chmeur) and self.directeur.age > 40 and self.employ->includes(self.directeur)

Une personne considre comme au chmage ne doit pas avoir des revenus suprieurs 100 .
context Personne inv : let revenus : Real = self.poste.salaire->sum() in if chmeur then revenus < 100 else revenus >= 100 endif

Une personne possde au plus deux parents (rfrencs).


context Personne 13. inv : parent->size()<=2

Si une personne possde deux parents, l'un est une femme et l'autre un homme.
context Personne inv : parent->size()=2 implies ( parent->exists(genre=Genre::homme) and parent->exists(genre=Genre::femme) )

Tous les enfants d'une personne ont bien cette personne comme parent et inversement.
context Personne inv :
- 80 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

enfant->notEmpty() implies enfant->forAll( p : Personne | p.parents->includes(self)) context Personne inv : parent->notEmpty() implies parent->forAll ( p : Personne | p.enfant->includes (self))

Pour tre mari, il faut avoir une femme ou un mari.


context Personne::mari derive : self.femme->notEmpty() or self.mari->notEmpty()

Pour tre mari, il faut avoir plus de 18 ans. Un homme est mari avec exactement une femme et une femme avec exactement un homme.
context Personne inv : self.mari implies self.genre=Genre::homme implies ( self.femme->size()=1 and self.femme.genre=Genre::femme) and self.genre=Genre::femme implies ( self.mari->size()=1 and self.mari.genre=Genre::homme) and self.age >=18

5 - Chapitre 5 Diagramme d'tats-transitions (State machine diagram) 5-1 - Introduction au formalisme 5-1-1 - Prsentation
Les diagrammes d'tats-transitions d'UML dcrivent le comportement interne d'un objet l'aide d'un automate tats finis. Ils prsentent les squences possibles d'tats et d'actions qu'une instance de classe peut traiter au cours de son cycle de vie en raction des vnements discrets (de type signaux, invocations de mthode). Ils spcifient habituellement le comportement d'une instance de classeur (classe ou composant), mais parfois aussi le comportement interne d'autres lments tels que les cas d'utilisation, les sous-systmes, les mthodes. Le diagramme d'tats-transitions est le seul diagramme, de la norme UML, offrir une vision complte et non ambigu de l'ensemble des comportements de l'lment auquel il est attach. En effet, un diagramme d'interaction n'offre qu'une vue partielle correspondant un scnario sans spcifier comment les diffrents scnarii interagissent entre eux. La vision globale du systme n'apparat pas sur ce type de diagrammes puisqu'ils ne s'intressent qu' un seul lment du systme indpendamment de son environnement. Concrtement, un diagramme d'tats-transitions est un graphe qui reprsente un automate tats finis, c'est--dire une machine dont le comportement des sorties ne dpend pas seulement de l'tat de ses entres, mais aussi d'un historique des sollicitations passes.

5-1-2 - Notion d'automate tats finis


Comme nous venons de le dire, un automate tats finis est un automate dont le comportement des sorties ne dpend pas seulement de l'tat de ses entres, mais aussi d'un historique des sollicitations passes. Cet historique est caractris par un tat global.
- 81 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Un tat global est un jeu de valeurs d'objet, pour une classe donne, produisant la mme rponse face aux vnements. Toutes les instances d'une mme classe ayant le mme tat global ragissent de la mme manire un vnement. Il ne faut pas confondre les notions d'tat global et d'tat. La section 5.2.1 donne plus d'information sur ces deux acceptions du terme tat. Un automate tats finis est graphiquement reprsent par un graphe comportant des tats, matrialiss par des rectangles aux coins arrondis, et des transitions, matrialises par des arcs orients liant les tats entre eux.

Figure 5.1 : Un diagramme d'tats-transitions simple. La figure 5.1 montre un exemple simple d'automate tats finis. Cet automate possde deux tats (Allum et teint) et deux transitions correspondant au mme vnement : la pression sur un bouton d'clairage domestique. Cet automate tats finis illustre en fait le fonctionnement d'un tlrupteur dans une maison. Lorsque l'on appuie sur un bouton d'clairage, la raction de l'clairage associ dpendra de son tat courant (de son historique) : si la lumire est allume, elle s'teindra, si elle est teinte, elle s'allumera.

5-1-3 - Diagrammes d'tats-transitions


Un diagramme d'tats-transitions rassemble et organise les tats et les transitions d'un classeur donn. Bien entendu, le modle dynamique du systme comprend plusieurs diagrammes d'tats-transitions. Il est souhaitable de construire un diagramme d'tats-transitions pour chaque classeur (qui, le plus souvent, est une classe) possdant un comportement dynamique important. Un diagramme d'tats-transitions ne peut tre associ qu' un seul classeur. Tous les automates tats finis des diagrammes d'tats-transitions d'un systme s'excutent concurremment et peuvent donc changer d'tat de faon indpendante.

5-2 - tat 5-2-1 - Les deux acceptions du terme tat 5-2-1-a - tat dans un diagrammes d'tats-transitions

Figure 5.2 : Exemple d'tat simple. Comme nous l'avons dj dit, un tat, que l'on peut qualifier informellement d'lmentaire, se reprsente graphiquement dans un diagramme d'tats-transitions par un rectangle aux coins arrondis (figure 5.2). Certains tats, dits composites (cf. section 5.6), peuvent contenir (i.e. envelopper) des sous-tats.

- 82 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Le nom de l'tat peut tre spcifi dans le rectangle et doit tre unique dans le diagramme d'tats-transitions, ou dans l'tat enveloppant. On peut l'omettre, ce qui produit un tat anonyme. Il peut y avoir un nombre quelconque d'tats anonymes distincts. Un tat imbriqu peut tre identifi par son nom qualifi (cf. section 2.4.2) si tous les tats enveloppants ont des noms. Un tat peut tre partitionn en plusieurs compartiments spars par une ligne horizontale. Le premier compartiment contient le nom de l'tat et les autres peuvent recevoir des transitions internes (cf. section 5.4.6), ou des sous-tats (cf. section 5.6), quand il s'agit d'un tat composite. Dans le cas d'un tat simple (i.e. sans transition interne ou soustat), on peut omettre toute barre de sparation (figure 5.2).

5-2-1-b - tat d'un objet, ou du diagramme d'tats-transitions (i.e. tat global)


Un objet peut passer par une srie d'tats pendant sa dure de vie. Un tat reprsente une priode dans la vie d'un objet pendant laquelle ce dernier attend un vnement ou accomplit une activit. La configuration de l'tat global de l'objet est le jeu des tats (lmentaires) qui sont actifs un instant donn. Dans le cas d'un diagramme d'tats-transitions simple (sans transition concurrente), il ne peut y avoir qu'un seul tat actif la fois. Dans ce cas, les notions d'tat actif et d'tat global se rejoignent. Cependant, la configuration de l'tat global peut contenir plusieurs tats actifs un instant donn. On parle d'tats concurrents (cf. section 5.6.5) quand plusieurs tats sont actifs en mme temps et on dit qu'il y a concurrence au sein de l'objet. Le nombre d'tats actifs peut changer pendant la dure de vie d'un objet du fait d'embranchements ou de jointures appeles transitions concurrentes (cf. section ).

5-2-2 - tat initial et final 5-2-2-a - tat initial

Figure 5.3 : Reprsentation graphique de l'tat initial. L'tat initial est un pseudotat qui indique l'tat de dpart, par dfaut, lorsque le diagramme d'tats-transitions, ou l'tat enveloppant, est invoqu. Lorsqu'un objet est cr, il entre dans l'tat initial.

5-2-2-b - tat final

Figure 5.4 : Reprsentation graphique de l'tat final. L'tat final est un pseudotat qui indique que le diagramme d'tats-transitions, ou l'tat enveloppant, est termin.

5-3 - vnement 5-3-1 - Notion d'vnement


Un vnement est quelque chose qui se produit pendant l'excution d'un systme et qui mrite d'tre modlis. Les diagrammes d'tats-transitions permettent justement de spcifier les ractions d'une partie du systme des vnements discrets. Un vnement se produit un instant prcis et est dpourvu de dure. Quand un vnement est reu, une transition peut tre dclenche et faire basculer l'objet dans un nouvel tat. On peut diviser les vnements en plusieurs types explicites et implicites : signal, appel, changement et temporel.

- 83 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

5-3-2 - vnement de type signal (signal)

Figure 5.5 : Dclaration de signaux et hritage. Un signal est un type de classeur destin explicitement vhiculer une communication asynchrone sens unique entre deux objets. L'objet expditeur cre et initialise explicitement une instance de signal et l'envoi un objet explicite ou tout un groupe d'objets. Il n'attend pas que le destinataire traite le signal pour poursuivre son droulement. La rception d'un signal est un vnement pour l'objet destinataire. Un mme objet peut tre la fois expditeur et destinataire. Les signaux sont dclars par la dfinition d'un classeur portant le strotype signal ne fournissant pas d'opration et dont les attributs sont interprts comme des arguments (cf. figure 5.5). La syntaxe d'un signal est la suivante :
<nom_vnement> ( [ <paramtre> : <type> [; <paramtre> : <type> ... ] ] )

Les signaux supportent la relation de gnralisation (cf. figure 5.5). Les signaux hritent des attributs de leurs parents (hritage) et ils dclenchent des transitions contenant le type du signal parent (polymorphisme).

5-3-3 - vnement d'appel (call)


Un vnement d'appel reprsente la rception de l'appel d'une opration par un objet. Les paramtres de l'opration sont ceux de l'vnement d'appel. La syntaxe d'un vnement d'appel est la mme que celle d'un signal. Par contre, les vnements d'appel sont des mthodes dclares au niveau du diagramme de classes.

5-3-4 - vnement de changement (change)


Un vnement de changement est gnr par la satisfaction (i.e. passage de faux vrai) d'une expression boolenne sur des valeurs d'attributs. Il s'agit d'une manire dclarative d'attendre qu'une condition soit satisfaite. La syntaxe d'un vnement de changement est la suivante :
when ( <condition_boolenne> )

Notez la diffrence entre une condition de garde (cf. section 5.4.2) et un vnement de changement. La premire est value une fois que l'vnement dclencheur de la transition a lieu et que le destinataire le traite. Si elle est fausse, la transition ne se dclenche pas et la condition n'est pas rvalue. Un vnement de changement est valu continuellement jusqu' ce qu'il devienne vrai, et c'est ce moment-l que la transition se dclenche.

- 84 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

5-3-5 - vnement temporel (after ou when)


Les vnements temporels sont gnrs par le passage du temps. Ils sont spcifis soit de manire absolue (date prcise), soit de manire relative (temps coul). Par dfaut, le temps commence s'couler ds l'entre dans l'tat courant. La syntaxe d'un vnement temporel spcifi de manire relative est la suivante :
after ( <dure> )

Un vnement temporel spcifi de manire absolue est dfini en utilisant un vnement de changement :
when ( date = <date> )

5-4 - Transition 5-4-1 - Dfinition et syntaxe


Une transition dfinit la rponse d'un objet l'occurrence d'un vnement. Elle lie, gnralement, deux tats E1 et E2 et indique qu'un objet dans un tat E1 peut entrer dans l'tat E2 et excuter certaines activits, si un vnement dclencheur se produit et que la condition de garde est vrifie. La syntaxe d'une transition est la suivante :
[ <vnement> ][ '[' <garde> ']' ] [ '/' <activit> ]

La syntaxe de <vnement> a t dfinie dans la section 5.3. Le mme vnement peut tre le dclencheur de plusieurs transitions quittant un mme tat. Chaque transition avec le mme vnement doit avoir une condition de garde diffrente. En effet, une seule transition peut se dclencher dans un mme flot d'excution. Si deux transitions sont actives en mme temps par un mme vnement, une seule se dclenche et le choix n'est pas prvisible (i.e. pas dterministe).

5-4-2 - Condition de garde


Une transition peut avoir une condition de garde (spcifie par '[' <garde> ']' dans la syntaxe). Il s'agit d'une expression logique sur les attributs de l'objet, associ au diagramme d'tats-transitions, ainsi que sur les paramtres de l'vnement dclencheur. La condition de garde est value uniquement lorsque l'vnement dclencheur se produit. Si l'expression est fausse ce moment-l, la transition ne se dclenche pas, si elle est vraie, la transition se dclenche et ses effets se produisent.

5-4-3 - Effet d'une transition


Lorsqu'une transition se dclenche (on parle galement de tir d'une transition), son effet (spcifi par '/' <activit> dans la syntaxe) s'excute. Il s'agit gnralement d'une activit qui peut tre une opration primitive comme une instruction d'assignation ; l'envoi d'un signal ; l'appel d'une opration ; une liste d'activits, etc.

La faon de spcifier l'activit raliser est laisse libre (langage naturel ou pseudocode).

- 85 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Lorsque l'excution de l'effet est termine, l'tat cible de la transition devient actif.

5-4-4 - Transition externe

Figure 5.6 : Reprsentation graphique d'une transition externe entre deux tats. Une transition externe est une transition qui modifie l'tat actif. Il s'agit du type de transition le plus rpandu. Elle est reprsente par une flche allant de l'tat source vers l'tat cible. La figure 5.6 illustre la reprsentation graphique d'une transition externe entre deux tats.

5-4-5 - Transition d'achvement


Une transition dpourvue d'vnement dclencheur explicite se dclenche la fin de l'activit contenue dans l'tat source (y compris les tats imbriqus). Elle peut contenir une condition de garde qui est value au moment o l'activit contenue dans l'tat s'achve, et non pas ensuite. Les transitions de garde sont, par exemple, utilises pour connecter les tats initiaux et les tats historiques (cf. section 5.6.3) avec leur tat successeur puisque ces pseudotats ne peuvent rester actifs.

5-4-6 - Transition interne

Figure 5.7 : Reprsentation de la saisie d'un mot de passe dans un tat unique en utilisant des transitions internes. Les rgles de dclenchement d'une transition interne sont les mmes que pour une transition externe except qu'une transition interne ne possde pas d'tat cible et que l'tat actif reste le mme la suite de son dclenchement. La syntaxe d'une transition interne reste la mme que celle d'une transition classique (cf. section 5.4.1). Par contre, les transitions internes ne sont pas reprsentes par des arcs, mais sont spcifies dans un compartiment de leur tat associ (cf. figure 5.7). Les transitions internes possdent des noms d'vnement prdfinis correspondant des dclencheurs particuliers : entry, exit, do et include. Ces mots-clefs rservs viennent prendre la place du nom de l'vnement dans la syntaxe d'une transition interne. entry entry permet de spcifier une activit qui s'accomplit quand on entre dans l'tat. exit

- 86 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

exit permet de spcifier une activit qui s'accomplit quand on sort de l'tat. do une activit do commence ds que l'activit entry est termine. Lorsque cette activit est termine, une transition d'achvement peut tre dclenche, aprs l'excution de l'activit exit bien entendu. Si une transition se dclenche pendant que l'activit do est en cours, cette dernire est interrompue et l'activit exit de l'tat s'excute. include permet d'invoquer un sous-diagramme d'tats-transitions. Les activits entry servent souvent effectuer la configuration ncessaire dans un tat. Comme il n'est pas possible de l'luder, toute action interne l'tat peut supposer que la configuration est effectue indpendamment de la manire dont on entre dans l'tat. De manire analogue, une activit exit est une occasion de procder un nettoyage. Cela peut s'avrer particulirement utile lorsqu'il existe des transitions de haut niveau qui reprsentent des conditions d'erreur qui abandonnent les tats imbriqus. Le dclenchement d'une transition interne ne modifie pas l'tat actif et n'entrane donc pas l'activation des activits entry et exit.

5-5 - Point de choix


Il est possible de reprsenter des alternatives pour le franchissement d'une transition. On utilise pour cela des pseudotats particuliers : les points de jonction (reprsents par un petit cercle plein) et les points de dcision (reprsents par un losange).

5-5-1 - Point de jonction

- 87 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 5.8 : En haut, un diagramme sans point de jonction. En bas, son quivalent utilisant un point de jonction.

Figure 5.9 : Exemple d'utilisation de deux points de jonction pour reprsenter une alternative. Les points de jonction sont un artefact graphique (un pseudotat en l'occurrence) qui permet de partager des segments de transition, l'objectif tant d'aboutir une notation plus compacte ou plus lisible des chemins alternatifs. Un point de jonction peut avoir plusieurs segments de transition entrante et plusieurs segments de transition sortante. Par contre, il ne peut avoir d'activit interne ni des transitions sortantes dotes de dclencheurs d'vnements. Il ne s'agit pas d'un tat qui peut tre actif au cours d'un laps de temps fini. Lorsqu'un chemin passant par un point de jonction est emprunt (donc lorsque la transition associe est dclenche) toutes les gardes le long de ce chemin doivent s'valuer vrai ds le franchissement du premier segment. La figure 5.8 illustre bien l'utilit des points de jonction. La figure 5.9 illustre l'utilisation de points de jonction pour reprsenter le branchement d'une clause conditionnelle.

5-5-2 - Point de dcision

- 88 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 5.10 : Exemple d'utilisation d'un point de dcision. Un point de dcision possde une entre et au moins deux sorties. Contrairement un point de jonction, les gardes situes aprs le point de dcision sont values au moment o il est atteint. Cela permet de baser le choix sur des rsultats obtenus en franchissant le segment avant le point de choix (cf. figure 5.10). Si, quand le point de dcision est atteint, aucun segment en aval n'est franchissable, c'est que le modle est mal form. Il est possible d'utiliser une garde particulire, note [else], sur un des segments en aval d'un point de choix. Ce segment n'est franchissable que si les gardes des autres segments sont toutes fausses. L'utilisation d'une clause [else] est recommande aprs un point de dcision, car elle garantit un modle bien form.

5-6 - tats composites 5-6-1 - Prsentation

Figure 5.11 : Exemple d'tat composite modlisant l'association d'une commande un client. Un tat simple ne possde pas de sous-structure, mais uniquement, le cas chant, un jeu de transitions internes. Un tat composite est un tat dcompos en rgions contenant chacune un ou plusieurs sous-tats. Quand un tat composite comporte plus d'une rgion, il est qualifi d'tat orthogonal. Lorsqu'un tat orthogonal est actif, un sous-tat direct de chaque rgion est simultanment actif, il y a donc concurrence (cf. section 5.6.5). Un tat composite ne comportant qu'une rgion est qualifi d'tat non orthogonal. Implicitement, tout diagramme d'tats-transitions est contenu dans un tat externe qui n'est usuellement pas reprsent. Cela apporte une plus grande homognit dans la description : tout diagramme d'tats-transitions est implicitement un tat composite.

Figure 5.12 : Notation abrge d'un tat composite.


- 89 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

L'utilisation d'tats composites permet de dvelopper une spcification par raffinements. Il n'est pas ncessaire de reprsenter les sous-tats chaque utilisation de l'tat englobant. Une notation abrge (figure 5.12) permet d'indiquer qu'un tat est composite et que sa dfinition est donne sur un autre diagramme. La figure 5.11 montre un exemple d'tat composite et la figure 5.12 montre sa notation abrge.

5-6-2 - Transition
Les transitions peuvent avoir pour cible la frontire d'un tat composite et sont quivalentes une transition ayant pour cible l'tat initial de l'tat composite. Une transition ayant pour source la frontire d'un tat composite est quivalente une transition qui s'applique tout sous-tat de l'tat composite source. Cette relation est transitive : la transition est franchissable depuis tout tat imbriqu, quelle que soit sa profondeur. Par contre, si la transition ayant pour source la frontire d'un tat composite ne porte pas de dclencheur explicite (i.e. s'il s'agit d'une transition d'achvement), elle est franchissable quand l'tat final de l'tat composite est atteint. Les transitions peuvent galement toucher des tats de diffrents niveaux d'imbrication en traversant les frontires des tats composites.

Figure 5.13 : Exemple de configuration complexe de transition. Depuis l'tat tat 1, la rception de l'vnement event1 produit la squence d'activits QuitterE11, QuitterE1, action1, EntrerE2, EntrerE21, initialiser(), EntrerE22, et place le systme dans l'tat tat22. La figure 5.13 illustre une configuration complexe de transition produisant une cascade d'activits.

5-6-3 - tat historique

- 90 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 5.14 : Exemple de diagramme possdant un tat historique profond permettant de reprendre le programme de lavage ou de schage d'une voiture l'endroit o il tait arriv avant d'tre interrompu. Un tat historique, galement qualifi d'tat historique plat, est un pseudotat qui mmorise le dernier sous-tat actif d'un tat composite. Graphiquement, il est reprsent par un cercle contenant un H. Une transition ayant pour cible l'tat historique est quivalente une transition qui a pour cible le dernier tat visit de l'tat englobant. Un tat historique peut avoir une transition sortante non tiquete indiquant l'tat excuter si la rgion n'a pas encore t visite. Il est galement possible de dfinir un tat historique profond reprsent graphiquement par un cercle contenant un H*. Cet tat historique profond permet d'atteindre le dernier tat visit dans la rgion, quel que soit son niveau d'imbrication, alors que le l'tat historique plat limite l'accs aux tats de son niveau d'imbrication. La figure 5.14 montre un diagramme d'tats-transitions modlisant le lavage automatique d'une voiture. Les tats de lavage, schage et lustrage sont des tats composites dfinis sur trois autres diagrammes d'tats-transitions non reprsents ici. En phase de lavage ou de schage, le client peut appuyer sur le bouton d'arrt d'urgence. S'il appuie sur ce bouton, la machine se met en attente. Il a alors deux minutes pour reprendre le lavage ou le lustrage, exactement o le programme a t interrompu, c'est--dire au niveau du dernier sous-tat actif des tats de lavage ou de lustrage (tat historique profond). Si l'tat avait t un tat historique plat, c'est toute la squence de lavage ou de lustrage qui aurait recommenc. En phase de lustrage, le client peut aussi interrompre la machine. Mais dans ce cas, la machine s'arrtera dfinitivement.

5-6-4 - Interface : les points de connexion

- 91 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 5.15 : Exemple d'utilisation de points de connexion. Comme nous l'avons dj dit, il est possible de masquer les sous-tats d'un tat composite et de les dfinir dans un autre diagramme. Cette pratique ncessite parfois l'utilisation de pseudotats appels points de connexion. Lorsque l'on utilise le comportement par dfaut de l'tat composite, c'est--dire entrer par l'tat initial par dfaut et considrer les traitements finis quand l'tat final est atteint, aucun problme ne se pose, car on utilise des transitions ayant pour cible, ou pour source, la frontire de l'tat composite. Dans ce cas, les points de connexion sont inutiles. Le problme se pose lorsqu'il est possible d'entrer ou de sortir d'un tat composite de plusieurs faons. C'est, par exemple, le cas lorsqu'il existe des transitions traversant la frontire de l'tat composite et visant directement, ou ayant pour source, un sous-tat de l'tat composite. Dans ce cas, la solution est d'utiliser des points de connexion sur la frontire de l'tat composite. Les points de connexion sont des points d'entre et de sortie portant un nom, et situs sur la frontire d'un tat composite. Ils sont respectivement reprsents par un cercle vide et un cercle barr d'une croix (cf. figure 5.15). Il ne s'agit que de rfrences un tat dfini dans l'tat composite. Une unique transition d'achvement, dpourvue de garde, relie le pseudotat source (i.e. le point de connexion) l'tat rfrenc. Cette transition d'achvement n'est que le prolongement de la transition qui vise le point de connexion (il peut d'ailleurs y en avoir plusieurs). Les points de connexions offrent ainsi une faon de reprsenter l'interface (au sens objet) d'un tat composite en masquant l'implmentation de son comportement. On peut considrer que les pseudotats initiaux et finals sont des points de connexion sans nom.

5-6-5 - Concurrence

- 92 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 5.16 : Exemple d'utilisation d'un tat composite orthogonal. Les diagrammes d'tats-transitions permettent de dcrire efficacement les mcanismes concurrents grce l'utilisation d'tats orthogonaux. Un tat orthogonal est un tat composite comportant plus d'une rgion, chaque rgion reprsentant un flot d'excution. Graphiquement, dans un tat orthogonal, les diffrentes rgions sont spares par un trait horizontal en pointill allant du bord gauche au bord droit de l'tat composite. Chaque rgion peut possder un tat initial et final. Une transition qui atteint la bordure d'un tat composite orthogonal est quivalente une transition qui atteint les tats initiaux de toutes ses rgions concurrentes. Toutes les rgions concurrentes d'un tat composite orthogonal doivent atteindre leur tat final pour que l'tat composite soit considr comme termin. La figure 5.16 illustre l'utilisation d'un tat composite orthogonal pour modliser le fait que la prparation de la boisson d'un distributeur de boissons se fait en parallle au rendu de la monnaie.

Figure 5.17 : Exemple d'utilisation de transitions complexes. Il est galement possible de reprsenter ce type de comportement au moyen de transitions concurrentes. De telles transitions sont qualifies de complexes. Les transitions complexes sont reprsentes par une barre paisse et peuvent, ventuellement, tre nommes. La figure 5.17 montre la mise en uvre de ce type de transition. Sur ce diagramme, l'tat orthogonal prparer boisson et rendre monnaie peut ventuellement ne pas apparatre (tout en gardant la reprsentation de ses sous-tats) pour allger la reprsentation, car la notion de concurrence est clairement apparente de par l'utilisation des transitions complexes.

- 93 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

6 - Chapitre 6 Diagramme d'activits (Activity diagram) 6-1 - Introduction au formalisme 6-1-1 - Prsentation
Les diagrammes d'activits permettent de mettre l'accent sur les traitements. Ils sont donc particulirement adapts la modlisation du cheminement de flots de contrle et de flots de donnes. Ils permettent ainsi de reprsenter graphiquement le comportement d'une mthode ou le droulement d'un cas d'utilisation. Les diagrammes d'activits sont relativement proches des diagrammes d'tats-transitions dans leur prsentation, mais leur interprtation est sensiblement diffrente. Les diagrammes d'tats-transitions sont orients vers des systmes ractifs, mais ils ne donnent pas une vision satisfaisante d'un traitement faisant intervenir plusieurs classeurs et doivent tre complts, par exemple, par des diagrammes de squence. Au contraire, les diagrammes d'activits ne sont pas spcifiquement rattachs un classeur particulier. On peut attacher un diagramme d'activits n'importe quel lment de modlisation afin de visualiser, spcifier, construire ou documenter le comportement de cet lment. La diffrence principale entre les diagrammes d'interaction et les diagrammes d'activits est que les premiers mettent l'accent sur le flot de contrle d'un objet l'autre, tandis que les seconds insistent sur le flot de contrle d'une activit l'autre.

6-1-2 - Utilisation courante


Dans la phase de conception, les diagrammes d'activits sont particulirement adapts la description des cas d'utilisation. Plus prcisment, ils viennent illustrer et consolider la description textuelle des cas d'utilisation (cf. section 2.5.3). De plus, leur reprsentation sous forme d'organigrammes les rend facilement intelligibles et beaucoup plus accessibles que les diagrammes d'tats-transitions. On parle gnralement dans ce cas de modlisation de workflow. On se concentre ici sur les activits telles que les voient les acteurs qui collaborent avec le systme dans le cadre d'un processus mtier. La modlisation du flot d'objets est souvent importante dans ce type d'utilisation des diagrammes d'activits. Les diagrammes d'activits permettent de spcifier des traitements a priori squentiels et offrent une vision trs proche de celle des langages de programmation impratifs comme C++ ou Java. Ainsi, ils peuvent tre utiles dans la phase de ralisation, car ils permettent une description si prcise des oprations qu'elle autorise la gnration automatique du code. La modlisation d'une opration peut toutefois tre assimile une utilisation d'UML comme langage de programmation visuelle, ce qui n'est pas sa finalit. Il ne faut donc pas y avoir recours de manire systmatique, mais la rserver des oprations dont le comportement est complexe ou sensible.

6-2 - Activit et Transition 6-2-1 - Action (action)


Une action est le plus petit traitement qui puisse tre exprim en UML. Une action a une incidence sur l'tat du systme ou en extrait une information. Les actions sont des tapes discrtes partir desquelles se construisent les comportements. La notion d'action est rapprocher de la notion d'instruction lmentaire d'un langage de programmation (comme C++ ou Java). Une action peut tre, par exemple : une affectation de valeur des attributs ; un accs la valeur d'une proprit structurelle (attribut ou terminaison d'association) ; la cration d'un nouvel objet ou lien ; un calcul arithmtique simple ;

- 94 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

l'mission d'un signal ; la rception d'un signal ; Nous dcrivons ci-dessous les types d'actions les plus courants prdfinis dans la notation UML.

Action appeler ( call operation ) L'action call operation correspond l'invocation d'une opration sur un objet de manire synchrone ou asynchrone. Lorsque l'action est excute, les paramtres sont transmis l'objet cible. Si l'appel est asynchrone, l'action est termine et les ventuelles valeurs de retour seront ignores. Si l'appel est synchrone, l'appelant est bloqu pendant l'excution de l'opration et, le cas chant, les valeurs de retour pourront tre rceptionnes. Action comportement ( call behavior ) L'action call behavior est une variante de l'action call operation car elle invoque directement une activit plutt qu'une opration. Action envoyer ( send ) Cette action cre un message et le transmet un objet cible, o elle peut dclencher un comportement. Il s'agit d'un appel asynchrone (i.e. qui ne bloque pas l'objet appelant) bien adapt l'envoi de signaux (send signal). Action accepter vnement ( accept event ) L'excution de cette action bloque l'excution en cours jusqu' la rception du type d'vnement spcifi, qui gnralement est un signal. Cette action est utilise pour la rception de signaux asynchrones. Action accepter appel ( accept call ) Il s'agit d'une variante de l'action accept event pour les appels synchrones. Action rpondre ( reply ) Cette action permet de transmettre un message en rponse la rception d'une action de type accept call. Action crer ( create ) Cette action permet d'instancier un objet. Action dtruire ( destroy ) Cette action permet de dtruire un objet. Action lever exception ( raise exception ) Cette action permet de lever explicitement une exception. Graphiquement, les actions apparaissent dans des nuds d'action, dcrits section 6.3.1.

- 95 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

6-2-2 - Activit (activity)


Une activit dfinit un comportement dcrit par un squencement organis d'units dont les lments simples sont les actions. Le flot d'excution est modlis par des nuds relis par des arcs (transitions). Le flot de contrle reste dans l'activit jusqu' ce que les traitements soient termins. Une activit est un comportement (behavior en anglais) et ce titre peut tre associe des paramtres.

6-2-3 - Groupe d'activits (activity group)


Un est une activit regroupant des nuds et des arcs. Les nuds et les arcs peuvent appartenir plus d'un groupe. Un diagramme d'activits est lui-mme un groupe d'activits (cf. figure 6.2).

6-2-4 - Nud d'activit (activity node)

Figure 6.1 : Reprsentation graphique des nuds d'activit. De la gauche vers la droite, on trouve : le nud reprsentant une action, qui est une varit de nud excutable, un nud objet, un nud de dcision ou de fusion, un nud de bifurcation ou d'union, un nud initial, un nud final et un nud final de flot.

- 96 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 6.2 : Exemple de diagramme d'activits modlisant le fonctionnement d'une borne bancaire. Un nud d'activit est un type d'lment abstrait permettant de reprsenter les tapes le long du flot d'une activit. Il existe trois familles de nuds d'activits : les nuds d'excutions (executable node en anglais) ;
- 97 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

les nuds objets (object node en anglais) ; et les nuds de contrle (control nodes en anglais).

La figure 6.1 reprsente les diffrents types de nuds d'activit. La figure 6.2 montre comment certains de ces nuds sont utiliss pour former un diagramme d'activits.

6-2-5 - Transition

Figure 6.3 : Reprsentation graphique d'une transition. Le passage d'une activit vers une autre est matrialis par une transition. Graphiquement les transitions sont reprsentes par des flches en traits pleins qui connectent les activits entre elles (figure 6.3). Elles sont dclenches ds que l'activit source est termine et provoquent automatiquement et immdiatement le dbut de la prochaine activit dclencher (l'activit cible). Contrairement aux activits, les transitions sont franchies de manire atomique, en principe sans dure perceptible. Les transitions spcifient l'enchanement des traitements et dfinissent le flot de contrle.

6-3 - Nud excutable (executable node)


Un nud excutable est un nud d'activit qu'on peut excuter (i.e. une activit). Il possde un gestionnaire d'exceptions qui peut capturer les exceptions leves par le nud, ou un de ses nuds imbriqus.

6-3-1 - Nud d'action

Figure 6.4 : Reprsentation graphique d'un nud d'action. Un nud d'action est un nud d'activit excutable qui constitue l'unit fondamentale de fonctionnalit excutable dans une activit. L'excution d'une action reprsente une transformation ou un calcul quelconque dans le systme modlis. Les actions sont gnralement lies des oprations qui sont directement invoques. Un nud d'action doit avoir au moins un arc entrant. Graphiquement, un nud d'action est reprsent par un rectangle aux coins arrondis (figure 6.4) qui contient sa description textuelle. Cette description textuelle peut aller d'un simple nom une suite d'actions ralises par l'activit. UML n'impose aucune syntaxe pour cette description textuelle, on peut donc utiliser une syntaxe proche de celle d'un langage de programmation particulier ou du pseudocode.

- 98 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 6.5 : Reprsentation particulire des nouds d'action de communication. Certaines actions de communication ont une notation spciale (cf. figure 6.5).

6-3-2 - Nud d'activit structure (structured activity node)


Un nud d'activit structure est un nud d'activit excutable qui reprsente une portion structure d'une activit donne qui n'est partage avec aucun autre nud structur, l'exception d'une imbrication ventuelle. Les transitions d'une activit structure doivent avoir leurs nuds source et cible dans le mme nud d'activit structure. Les nuds et les arcs contenus par nud d'activit structur ne peuvent pas tre contenus dans un autre nud d'activit structur. Un nud structur est dnot par le strotype structured et identifi par un nom unique dcrivant le comportement modlis dans l'activit structure. Graphiquement, le contour d'un nud d'activit structure est en pointill. Une ligne horizontale en trait continu spare le compartiment contenant le strotype structured et le nom de l'activit structure du corps de l'activit structure.

6-4 - Nud de contrle (control node)

- 99 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 6.6 : Exemple de diagramme d'activit illustrant l'utilisation de nuds de contrle. Ce diagramme dcrit la prise en compte d'une commande. Un nud de contrle est un nud d'activit abstrait utilis pour coordonner les flots entre les nuds d'une activit. Il existe plusieurs types de nuds de contrle : nud initial (initial node en anglais) ; nud de fin d'activit (final node en anglais) ; nud de fin de flot (flow final en anglais) ; nud de dcision (decision node en anglais) ; nud de fusion (merge node en anglais) ; nud de bifurcation (fork node en anglais) ; nud d'union (join node en anglais).

La figure 6.6 illustre l'utilisation de ces nuds de contrle.

6-4-1 - Nud initial


Un nud initial est un nud de contrle partir duquel le flot dbute lorsque l'activit enveloppante est invoque. Une activit peut avoir plusieurs nuds initiaux. Un nud initial possde un arc sortant et pas d'arc entrant. Graphiquement, un nud initial est reprsent par un petit cercle plein (cf. figure 6.6).

6-4-2 - Nud final


Un nud final est un nud de contrle possdant un ou plusieurs arcs entrants et aucun arc sortant.

- 100 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

6-4-2-a - Nud de fin d'activit


Lorsque l'un des arcs d'un nud de fin d'activit est activ (i.e. lorsqu'un flot d'excution atteint un nud de fin d'activit), l'excution de l'activit enveloppante s'achve et tout nud ou flot actif au sein de l'activit enveloppante est abandonn. Si l'activit a t invoque par un appel synchrone, un message (reply) contenant les valeurs sortantes est transmis en retour l'appelant. Graphiquement, un nud de fin d'activit est reprsent par un cercle vide contenant un petit cercle plein (cf. figure 6.6).

6-4-2-b - Nud de fin de flot


Lorsqu'un flot d'excution atteint un nud de fin de flot, le flot en question est termin, mais cette fin de flot n'a aucune incidence sur les autres flots actifs de l'activit enveloppante. Graphiquement, un nud de fin de flot est reprsent par un cercle vide barr d'un X. Les nuds de fin de flot sont particuliers et utiliser avec parcimonie. Dans l'exemple de la figure 6.6, le nud de fin de flot n'est pas indispensable : on peut le remplacer par un nud d'union possdant une transition vers un nud de fin d'activit.

6-4-3 - Nud de dcision et de fusion 6-4-3-a - Nud de dcision (decision node)


Un nud de dcision est un nud de contrle qui permet de faire un choix entre plusieurs flots sortants. Il possde un arc entrant et plusieurs arcs sortants. Ces derniers sont gnralement accompagns de conditions de garde pour conditionner le choix. Si, quand le nud de dcision est atteint, aucun arc en aval n'est franchissable (i.e. aucune condition de garde n'est vraie), c'est que le modle est mal form. L'utilisation d'une garde [else] est recommande aprs un nud de dcision, car elle garantit un modle bien form. En effet, la condition de garde [else] est valide si et seulement si toutes les autres gardes des transitions ayant la mme source sont fausses. Dans le cas o plusieurs arcs sont franchissables (i.e. plusieurs conditions de garde sont vraies), seul l'un d'entre eux est retenu et ce choix est non dterministe. Graphiquement, on reprsente un nud de dcision par un losange (cf. figure 6.6).

6-4-3-b - Nud de fusion (merge node)


Un nud de fusion est un nud de contrle qui rassemble plusieurs flots alternatifs entrants en un seul flot sortant. Il n'est pas utilis pour synchroniser des flots concurrents (c'est le rle du nud d'union), mais pour accepter un flot parmi plusieurs. Graphiquement, on reprsente un nud de fusion, comme un nud de dcision, par un losange (cf. figure 6.6). Graphiquement, il est possible de fusionner un nud de fusion et un nud de dcision, et donc d'avoir un losange possdant plusieurs arcs entrants et sortants. Il est galement possible de fusionner un nud de dcision ou de fusion avec un autre nud, comme un nud de fin de flot sur la figure 6.6, ou avec une activit. Cependant, pour mieux mettre en vidence un branchement conditionnel, il est prfrable d'utiliser un nud de dcision (losange).

- 101 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

6-4-4 - Nud de bifurcation et d'union 6-4-4-a - Nud de bifurcation ou de dbranchement (fork node)
Un nud de bifurcation, galement appel nud de dbranchement est un nud de contrle qui spare un flot en plusieurs flots concurrents. Un tel nud possde donc un arc entrant et plusieurs arcs sortants. On apparie gnralement un nud de bifurcation avec un nud d'union pour quilibrer la concurrence (cf. figure 6.2). Graphiquement, on reprsente un nud de bifurcation par un trait plein (cf. figure 6.6).

6-4-4-b - Nud d'union ou de jointure (join node)


Un nud d'union, galement appel nud de jointure est un nud de contrle qui synchronise des flots multiples. Un tel nud possde donc plusieurs arcs entrants et un seul arc sortant. Lorsque tous les arcs entrants sont activs, l'arc sortant l'est galement. Graphiquement, on reprsente un nud d'union, comme un nud de bifurcation, par un trait plein (cf. figure 6.2). Graphiquement, il est possible de fusionner un nud de bifurcation et un nud d'union, et donc d'avoir un trait plein possdant plusieurs arcs entrants et sortants (cf. figure 6.6).

6-5 - Nud d'objet 6-5-1 - Introduction


Jusqu'ici, nous avons montr comment modliser le comportement du flot de contrle dans un diagramme d'activits. Or, les flots de donnes n'apparaissent pas et sont pourtant un lment essentiel des traitements (arguments des oprations, valeurs de retour). Justement, un nud d'objet permet de dfinir un flot d'objets (i.e. un flot de donnes) dans un diagramme d'activits. Ce nud reprsente l'existence d'un objet gnr par une action dans une activit et utilis par d'autres actions.

6-5-2 - Pin d'entre ou de sortie

Figure 6.7 : Reprsentation des pins d'entre et de sortie sur une activit. Pour spcifier les valeurs passes en argument une activit et les valeurs de retour, on utilise des nuds d'objets appels pins (pin en anglais) d'entre ou de sortie. L'activit ne peut dbuter que si l'on affecte une valeur chacun de ses pins d'entre. Quand l'activit se termine, une valeur doit tre affecte chacun de ses pins de sortie. Les valeurs sont passes par copie : une modification des valeurs d'entre au cours du traitement de l'action n'est visible qu' l'intrieur de l'activit. Graphiquement, un pin est reprsent par un petit carr attach la bordure d'une activit (cf. figure 6.7). Il est typ et ventuellement nomm. Il peut contenir des flches indiquant sa direction (entre ou sortie) si l'activit ne permet pas de le dterminer de manire univoque.
- 102 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

6-5-3 - Pin de valeur


Un pin valeur est un pin d'entre qui fournit une valeur une action sans que cette valeur ne provienne d'un arc de flot d'objets. Un pin valeur est toujours associ une valeur spcifique. Graphiquement, un pin de valeur se reprsente comme un pin d'entre avec la valeur associe crite proximit.

6-5-4 - Flot d'objets

Figure 6.8 : Deux notations possibles pour modliser un flot de donnes. Un flot d'objets permet de passer des donnes d'une activit une autre. Un arc reliant un pin de sortie un pin d'entre est, par dfinition mme des pins, un flot d'objets (en haut de la figure 6.8). Dans cette configuration, le type du pin rcepteur doit tre identique ou parent (au sens de la relation de gnralisation) du type du pin metteur. Il existe une autre reprsentation possible d'un flot d'objets, plus axe sur les donnes proprement dites, car elle fait intervenir un nud d'objet dtach d'une activit particulire (en bas de la figure 6.8). Graphiquement, un tel nud d'objet est reprsent par un rectangle dans lequel est mentionn le type de l'objet (soulign). Des arcs viennent ensuite relier ce nud d'objet des activits sources et cibles. Le nom d'un tat, ou d'une liste d'tats, de l'objet peut tre prcis entre crochets aprs ou sous le type de l'objet. On peut galement prciser des contraintes entre accolades, soit l'intrieur, soit en dessous du rectangle du nud d'objet. La figure 6.11 montre l'utilisation de nuds d'objets dans un diagramme d'activits. Un flot d'objets peut porter une tiquette strotype mentionnant deux comportements particuliers : transformation indique une interprtation particulire de la donne vhicule par le flot ; selection indique l'ordre dans lequel les objets sont choisis dans le nud pour le quitter (cf. figure 6.10).

6-5-5 - Nud tampon central

- 103 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 6.9 : Exemple d'utilisation d'un nud tampon central pour centraliser toutes les commandes prises par diffrents procds, avant qu'elles soient traites. Un nud tampon central est un nud d'objet qui accepte les entres de plusieurs nuds d'objets ou produit des sorties vers plusieurs nuds d'objets. Les flots en provenance d'un nud tampon central ne sont donc pas directement connects des actions. Ce nud modlise donc un tampon traditionnel qui peut contenir des valeurs en provenance de diverses sources et livrer des valeurs vers diffrentes destinations. Graphiquement, un nud tampon central est reprsent comme un nud d'objet dtach (en bas de la figure 6.8) strotyp centralBuffer (cf. figure 6.9).

6-5-6 - Nud de stockage des donnes

Figure 6.10 : Dans cette modlisation, le personnel, aprs avoir t recrut par l'activit Recruter personnel, est stock de manire persistante dans le nud de stockage Base de donnes du Personnel. Bien qu'ils restent dans ce nud, chaque employ qui n'a pas encore reu d'affectation (tiquette strotype selection : personnel.affectation=null) est disponible pour tre utilis par l'activit Affecter personnel. Un nud de stockage des donnes est un nud tampon central particulier qui assure la persistance des donnes. Lorsqu'une information est slectionne par un flux sortant, l'information est duplique et ne disparat pas du nud de stockage des donnes comme ce serait le cas dans un nud tampon central. Lorsqu'un flux entrant vhicule une donne dj stocke par le nud de stockage des donnes, cette dernire est crase par la nouvelle. Graphiquement, un nud tampon central est reprsent comme un nud d'objet dtach (en bas de la figure 6.8) strotyp data store (cf. figure 6.10).

6-6 - Partitions

- 104 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 6.11 : Illustration de l'utilisation de nuds d'objets et de partitions dans un diagramme d'activits. Les partitions, souvent appeles couloirs ou lignes d'eau (swimlane) du fait de leur notation, permettent d'organiser les nuds d'activits dans un diagramme d'activits en oprant des regroupements (cf. figure 6.11). Les partitions n'ont pas de signification bien arrte, mais correspondent souvent des units d'organisation du modle. On peut, par exemple, les utiliser pour spcifier la classe responsable de la mise en uvre d'un ensemble de tches. Dans ce cas, la classe en question est responsable de l'implmentation du comportement des nuds inclus dans ladite partition. Graphiquement, les partitions sont dlimites par des lignes continues. Il s'agit gnralement de lignes verticales, comme sur la figure 6.11, mais elles peuvent tre horizontales ou mme courbes. Dans la version 2.0 d'UML, les partitions peuvent tre bidimensionnelles, elles prennent alors la forme d'un tableau. Dans le cas d'un diagramme d'activits partitionn, les nuds d'activits appartiennent forcment une et une seule partition. Les transitions peuvent, bien entendu, traverser les frontires des partitions. Les partitions d'activits tant des catgories arbitraires, on peut les reprsenter par d'autres moyens quand une rpartition gomtrique s'avre difficile raliser. On peut ainsi utiliser des couleurs ou tout simplement tiqueter les nuds d'activit par le nom de leur partition d'appartenance.

- 105 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

6-7 - Exceptions

Figure 6.12 : Notation graphique du fait qu'une activit peut soulever une exception. Une exception est gnre quand une situation anormale entrave le droulement nominal d'une tche. Elle peut tre gnre automatiquement pour signaler une erreur d'excution (dbordement d'indice de tableau, division par zro), ou tre souleve explicitement par une action (RaiseException) pour signaler une situation problmatique qui n'est pas prise en charge par la squence de traitement normale. Graphiquement, on peut reprsenter le fait qu'une activit peut soulever une exception comme un pin de sortie orn d'un petit triangle et en prcisant le type de l'exception proximit du pin de sortie (cf. figure 6.12).

Figure 6.13 : Les deux notations graphiques de la connexion entre une activit protge et son gestionnaire d'exceptions associ. Un gestionnaire d'exceptions est une activit possdant un pin d'entre du type de l'exception qu'il gre et li l'activit qu'il protge par un arc en zigzag ou un arc classique orn d'une petite flche en zigzag. Le gestionnaire d'exceptions doit avoir les mmes pins de sortie que le bloc qu'il protge (cf. figure 6.13). Les exceptions sont des classeurs et, ce titre, peuvent possder des caractristiques comme des attributs ou des oprations. Il est galement possible d'utiliser la relation d'hritage sur les exceptions. Un gestionnaire d'exceptions spcifie toujours le type des exceptions qu'il peut traiter, toute exception drivant de ce type est donc galement prise en charge.

- 106 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 6.14 : Exemple d'utilisation d'un gestionnaire d'exceptions pour protger une activit de l'exception Division_par_zero dclenche en cas de division par zro. Lorsqu'une exception survient, l'excution de l'activit en cours est abandonne sans gnrer de valeur de sortie. Le mcanisme d'excution recherche alors un gestionnaire d'exceptions susceptible de traiter l'exception leve ou une de ses classes parentes. Si l'activit qui a lev l'exception n'est pas protge de cette exception, l'exception est propage l'activit englobante. L'excution de cette dernire est abandonne, ses valeurs de sortie ne sont pas gnres et un gestionnaire d'exception est recherch son niveau. Ce mcanisme de propagation se poursuit jusqu' ce qu'un gestionnaire adapt soit trouv. Si l'exception se propage jusqu'au sommet d'une activit (i.e. il n'y a plus d'activit englobante), trois cas de figure se prsentent. Si l'activit a t invoque de manire asynchrone, aucun effet ne se produit et la gestion de l'exception est termine. Si l'activit a t invoque de manire synchrone, l'exception est propage au mcanisme d'excution de l'appelant. Si l'exception s'est propage la racine du systme, le modle est considr comme incomplet ou mal form. Dans la plupart des langages orients objet, une exception qui se propage jusqu' la racine du programme implique son arrt. Quand un gestionnaire d'exceptions adapt a t trouv et que son excution se termine, l'excution se poursuit comme si l'activit protge s'tait termine normalement, les valeurs de sortie fournies par le gestionnaire remplaant celle que l'activit protge aurait d produire.

7 - Chapitre 7 Diagrammes d'interaction (Interaction diagram) 7-1 - Prsentation du formalisme


Porte de garage motorise enroulement.

7-1-1 - Introduction
Un objet interagit pour implmenter un comportement. On peut dcrire cette interaction de deux manires complmentaires : l'une est centre sur des objets individuels (diagramme d'tats-transitions) et l'autre sur une collection d'objets qui cooprent (diagrammes d'interaction). La spcification d'un diagramme d'tats-transitions est prcise et conduit immdiatement au code. Elle ne permet pas pour autant d'expliquer le fonctionnement global d'un systme, car elle se concentre sur un seul objet la fois. Un diagramme d'interaction permet d'offrir une vue plus holistique (13) du comportement d'un jeu d'objets. Le diagramme de communication (section 7.2) est un diagramme d'interaction mettant l'accent sur l'organisation structurelle des objets qui envoient et reoivent des messages. Le diagramme de squence (section 7.3) est un diagramme d'interaction mettant l'accent sur la chronologie de l'envoi des messages. Les diagrammes d'interaction permettent d'tablir un lien entre les diagrammes de cas d'utilisation et les diagrammes de classes : ils montrent comment des objets (i.e. des instances de classes) communiquent pour raliser une certaine fonctionnalit. Ils apportent ainsi un aspect dynamique la modlisation du systme. Pour produire un diagramme d'interaction, il faut focaliser son attention sur un sous-ensemble d'lments du systme et tudier leur faon d'interagir pour dcrire un comportement particulier. UML permet de dcrire un comportement
- 107 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

limit un contexte prcis de deux faons : dans le cadre d'un classeur structur (cf. section 7.1.2) ou dans celui d'une collaboration (cf. section 7.1.3).

7-1-2 - Classeur structur

Figure 7.1 : Exemple de classeur structur montrant qu'un classeur Moteur est en fait constitu d'un Allumage et de quatre Bougies. Les classes dcouvertes au moment de l'analyse (celles qui figurent dans le diagramme de classes) ne sont parfois pas assez dtailles pour pouvoir tre implmentes par des dveloppeurs. UML propose de partir des classeurs dcouverts au moment de l'analyse (tels que les classes, mais aussi les sous-systmes, les cas d'utilisation) et de les dcomposer en lments suffisamment fins pour permettre leur implmentation. Les classeurs ainsi dcomposs s'appellent des classeurs structurs. Un classeur structur est donc la description de la structure d'implmentation interne d'une classe. Graphiquement, un classeur structur se reprsente par un rectangle en trait plein comprenant deux compartiments. Le compartiment suprieur contient le nom du classeur et le compartiment infrieur montre les parties internes relies par des connecteurs (cf. figure 7.1). Un classeur structur possde des ports (cf. section 8.2.3), des parties et des connecteurs. Lorsque l'on cre l'instance d'un classeur structur, on cre galement une instance de ses ports, de ses parties et de ses connecteurs.

7-1-3 - Collaboration

Figure 7.2 : Diagramme de collaboration d'une transaction immobilire. Une collaboration permet de dcrire la mise en uvre d'une fonctionnalit par un jeu de participants. Un rle est la description d'un participant. Contrairement aux paquetages et aux classeurs structurs, une collaboration ne dtient pas les instances lies ses rles. Les instances existent avant l'tablissement d'une instance de la collaboration, mais la collaboration les rassemble et prcise des connecteurs entre elles. Une collaboration peut donc traverser plusieurs niveaux d'un systme et un mme lment peut apparatre dans plusieurs collaborations.

- 108 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Par exemple, pour implmenter un cas d'utilisation, il faut utiliser un ensemble de classes, et d'autres lments, fonctionnant ensemble pour raliser le comportement de ce cas d'utilisation. Cet ensemble d'lments, comportant la fois une structure statique et dynamique, est modlis en UML par une collaboration. Graphiquement, une collaboration se reprsente par une ellipse en trait pointill comprenant deux compartiments. Le compartiment suprieur contient le nom de la collaboration et le compartiment infrieur montre les participants la collaboration (cf. figure 7.2).

7-1-4 - Interactions et lignes de vie

Figure 7.3 : Diagramme de classe d'un systme de pilotage.

Figure 7.4 : Diagramme de communication d'un systme de pilotage.

Figure 7.5 : Diagramme de squence d'un systme de pilotage. Une interaction montre le comportement d'un classeur structur ou d'une collaboration en se focalisant sur l'change d'informations entre les lments du classeur ou de la collaboration. Une interaction contient un jeu de lignes de vie. Chaque ligne de vie correspond une partie interne d'un classeur ou d'une collaboration (i.e. un rle dans le cas d'une collaboration). L'interaction dcrit donc l'activit interne des lments du classeur ou de la collaboration, appels lignes de vie, par les messages qu'ils changent. UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme de communication et celui de squence. Une mme interaction peut tre prsente aussi bien par l'un que par l'autre (cf. figure 7.4 et 7.5).

- 109 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

ces deux diagrammes, UML 2.0 en ajoute un troisime : le diagramme de timing. Son usage est limit la modlisation des systmes qui s'excutent sous de fortes contraintes de temps, comme les systmes temps rel.

7-1-5 - Reprsentation gnrale


Un diagramme d'interaction se reprsente par un rectangle contenant, dans le coin suprieur gauche, un pentagone accompagn du mot-clef sd lorsqu'il s'agit d'un diagramme de squence (cf. figure 7.5) et com lorsqu'il s'agit d'un diagramme de communication (cf. figure 7.4). Le mot-clef est suivi du nom de l'interaction. Dans le pentagone, on peut aussi faire suivre le nom par la liste des lignes de vie impliques, prcde par le mot-clef lifelines :. Enfin, des attributs peuvent tre indiqus dans la partie suprieure du rectangle contenant le diagramme (cf. figure 7.11). La syntaxe de ces attributs est la mme que celle des attributs d'une classe.

7-2 - Diagramme de communication (Communication diagram)

Figure 7.6 : Diagramme de communication illustrant la recherche puis l'ajout, dans son panier virtuel, d'un livre lors d'une commande sur Internet. Contrairement un diagramme de squence, un diagramme de communication (14) rend compte de l'organisation spatiale des participants l'interaction, il est souvent utilis pour illustrer un cas d'utilisation ou pour dcrire une opration. Le diagramme de communication aide valider les associations du diagramme de classe en les utilisant comme support de transmission des messages.

7-2-1 - Reprsentation des lignes de vie


Les lignes de vie sont reprsentes par des rectangles contenant une tiquette dont la syntaxe est :
[<nom_du_rle>] : [<Nom_du_type>]

Au moins un des deux noms doit tre spcifi dans l'tiquette, les deux points (:) sont, quant eux, obligatoires.

7-2-2 - Reprsentation des connecteurs


Les relations entre les lignes de vie sont appeles connecteurs et se reprsentent par un trait plein reliant deux lignes de vie et dont les extrmits peuvent tre ornes de multiplicits.

- 110 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

7-2-3 - Reprsentation des messages


Dans un diagramme de communication, les messages sont gnralement ordonns selon un numro de squence croissant. Un message est, habituellement, spcifi sous la forme suivante :
[ '['<cond>']' [<sq>] [ *[||] ['['<iter>']'] ] :] [<var> :=] <msg>([<par>])

<cond> est une condition sous forme d'expression boolenne entre crochets. <sq> est le numro de squence du message. On numrote les messages par envoi et sous-envoi dsigns par des chiffres spars par des points : ainsi l'envoi du message 1.4.4 est postrieur celui du message 1.4.3, tous deux tant des consquences (i.e. des sous-envois) de la rception d'un message 1.4. La simultanit d'un envoi est dsigne par une lettre : les messages 1.6a et 1.6b sont envoys en mme temps. <iter> spcifie (en langage naturel, entre crochets) l'envoi squentiel (ou en parallle, avec ||) de plusieurs messages. On peut omettre cette spcification et ne garder que le caractre * (ou *||) pour dsigner un message rcurrent, envoy un certain nombre de fois. <var> est la valeur de retour du message, qui sera par exemple transmise en paramtre un autre message. <msg> est le nom du message. <par> dsigne les paramtres (optionnels) du message. Cette syntaxe un peu complexe permet de prciser parfaitement l'ordonnancement et la synchronisation des messages entre les objets du diagramme de communication (cf. figure 7.6). La direction d'un message est spcifie par une flche pointant vers l'un ou l'autre des objets de l'interaction, relis par ailleurs avec un trait continu (connecteur).

7-3 - Diagramme de squence (Sequence diagram)


Les principales informations contenues dans un sont les messages changs entre les lignes de vie, prsents dans un ordre chronologique. Ainsi, contrairement au diagramme de communication, le temps y est reprsent explicitement par une dimension (la dimension verticale) et s'coule de haut en bas (cf. figure 7.5).

7-3-1 - Reprsentation des lignes de vie


Une ligne de vie se reprsente par un rectangle, auquel est accroch une ligne verticale pointille, contenant une tiquette dont la syntaxe est :
- 111 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

[<nom_du_rle>] : [<Nom_du_type>]

Au moins un des deux noms doit tre spcifi dans l'tiquette, les deux points (:) sont, quant eux, obligatoires.

7-3-2 - Reprsentation des messages


Un message dfinit une communication particulire entre des lignes de vie. Plusieurs types de messages existent, les plus communs sont : l'envoi d'un signal ; l'invocation d'une opration ; la cration ou la destruction d'une instance.

7-3-2-a - Messages asynchrones

Figure 7.7 : Reprsentation d'un message asynchrone. Une interruption ou un vnement sont de bons exemples de signaux. Ils n'attendent pas de rponse et ne bloquent pas l'metteur qui ne sait pas si le message arrivera destination, le cas chant quand il arrivera et s'il sera trait par le destinataire. Un signal est, par dfinition, un message asynchrone. Graphiquement, un message asynchrone se reprsente par une flche en traits pleins et l'extrmit ouverte partant de la ligne de vie d'un objet expditeur et allant vers celle de l'objet cible (figure 7.7).

7-3-2-b - Messages synchrones

Figure 7.8 : Reprsentation d'un message synchrone. L'invocation d'une opration est le type de message le plus utilis en programmation objet. L'invocation peut tre asynchrone ou synchrone. Dans la pratique, la plupart des invocations sont synchrones, l'metteur reste alors bloqu le temps que dure l'invocation de l'opration. Graphiquement, un message synchrone se reprsente par une flche en traits pleins et l'extrmit pleine partant de la ligne de vie d'un objet expditeur et allant vers celle de l'objet cible (figure 7.8). Ce message peut tre suivi d'une rponse qui se reprsente par une flche en pointill (figure ).

- 112 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

7-3-2-c - Messages de cration et destruction d'instance

Figure 7.9 : Reprsentation d'un message de cration et destruction d'instance. La cration d'un objet est matrialise par une flche qui pointe sur le sommet d'une ligne de vie (figure 7.9). La destruction d'un objet est matrialise par une croix qui marque la fin de la ligne de vie de l'objet (figure 7.9). La destruction d'un objet n'est pas ncessairement conscutive la rception d'un message.

7-3-2-d - vnements et messages

Figure 7.10 : Les diffrents vnements correspondant un message asynchrone. UML permet de sparer clairement l'envoi du message, sa rception, ainsi que le dbut de l'excution de la raction et sa fin (figure 7.10).

7-3-2-e - Syntaxe des messages et des rponses

- 113 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 7.11 : Syntaxe des messages et des rponses. Dans la plupart des cas, la rception d'un message est suivie de l'excution d'une mthode d'une classe. Cette mthode peut recevoir des arguments et la syntaxe des messages permet de transmettre ces arguments. La syntaxe de ces messages est la mme que pour un diagramme de communication (cf. section 7.2.3) except deux points : la direction du message est directement spcifie par la direction de la flche qui matrialise le message, et non par une flche supplmentaire au-dessus du connecteur reliant les objets comme c'est le cas dans un diagramme de communication ; les numros de squence sont gnralement omis puisque l'ordre relatif des messages est dj matrialis par l'axe vertical qui reprsente l'coulement du temps.

La syntaxe de rponse un message est la suivante :


[<attribut> = ] message [ : <valeur_de_retour>]

o message reprsente le message d'envoi. La figure 7.11 montre un exemple d'excution d'une mthode avec une rponse.

7-3-2-f - Message perdu et trouv

Figure 7.12 : Reprsentation d'un message perdu et d'un message trouv. Un message complet est tel que les vnements d'envoi et de rception sont connus. Comme nous l'avons dj vu, un message complet se reprsente par une simple flche dirige de l'metteur vers le rcepteur. Un message perdu est tel que l'vnement d'envoi est connu, mais pas l'vnement de rception. Il se reprsente par une flche qui pointe sur une petite boule noire (figure 7.12). Un message trouv est tel que l'vnement de rception est connu, mais pas l'vnement d'mission. Une flche partant d'une petite boule noire reprsente un message trouv (figure 7.12).
- 114 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

7-3-2-g - Porte
Une porte est un point de connexion qui permet de reprsenter un mme message dans plusieurs fragments d'interaction. Ces messages entrants et sortants vont d'un bord d'un diagramme une ligne de vie (ou l'inverse).

7-3-2-h - Excution de mthode et objet actif

Figure 7.13 : Reprsentation d'un objet actif ( gauche) et d'une excution sur un objet passif ( droite). Un objet actif initie et contrle le flux d'activits. Graphiquement, la ligne pointille verticale d'un objet actif est remplace par un double trait vertical (cf. figures 7.13). Un objet passif, au contraire, a besoin qu'on lui donne le flux d'activit pour pouvoir excuter une mthode. La spcification de l'excution d'une raction sur un objet passif se reprsente par un rectangle blanc ou gris plac sur la ligne de vie en pointill (cf. figures 7.13). Le rectangle peut ventuellement porter un label.

Figure 7.14 : Reprsentation d'une excution simultane ( gauche). Les sur une mme ligne de vie sont reprsentes par un rectangle chevauchant comme le montre la figure 7.14.

7-3-3 - Fragments d'interaction combins 7-3-3-a - Introduction


Un fragment combin reprsente des articulations d'interactions. Il est dfini par un oprateur et des oprandes. L'oprateur conditionne la signification du fragment combin. Il existe 12 d'oprateurs dfinis dans la notation UML 2.0. Les fragments combins permettent de dcrire des diagrammes de squence de manire compacte. Les fragments combins peuvent faire intervenir l'ensemble des entits participant au scnario ou juste un sousensemble. Un fragment combin se reprsente de la mme faon qu'une interaction. Il est reprsent dans un rectangle dont le coin suprieur gauche contient un pentagone. Dans le pentagone figure le type de la combinaison, appel oprateur d'interaction. Les oprandes d'un oprateur d'interaction sont spars par une ligne pointille. Les conditions de choix des oprandes sont donnes par des expressions boolennes entre crochets ([ ]).
- 115 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

La liste suivante regroupe les oprateurs d'interaction par fonctions : les oprateurs de choix et de boucle : alternative, option, break et loop ; les oprateurs contrlant l'envoi en parallle de messages : parallel et critical region ; les oprateurs contrlant l'envoi de messages : ignore, consider, assertion et negative ; les oprateurs fixant l'ordre d'envoi des messages : weak sequencing , strict sequencing.

Nous n'aborderons que quelques-unes de ces interactions dans la suite de cette section.

7-3-3-b - Oprateur alt

Figure 7.15 : Reprsentation d'un choix dans un diagramme de squence illustrant le dcouvrement d'une case au jeu du dmineur. L'oprateur alternative, ou alt, est un oprateur conditionnel possdant plusieurs oprandes (cf. figure 7.15). C'est un peu l'quivalent d'une excution choix multiple (condition switch en C++). Chaque oprande dtient une condition de garde. L'absence de condition de garde implique une condition vraie (true). La condition else est vraie si aucune autre condition n'est vraie. Exactement un oprande dont la condition est vraie est excut. Si plusieurs oprandes prennent la valeur vraie, le choix est non dterministe.

7-3-3-c - Oprateurs opt


L'oprateur option, ou opt, comporte un oprande et une condition de garde associe. Le sous-fragment s'excute si la condition de garde est vraie et ne s'excute pas dans le cas contraire.

- 116 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

7-3-3-d - Oprateur loop


Un fragment combin de type loop possde un sous-fragment et spcifie un compte minimum et maximum (boucle) ainsi qu'une condition de garde. La syntaxe de la boucle est la suivante :
loop[ '('<minInt> [ ',' <maxInt> ] ')' ]

La condition de garde est place entre crochets sur la ligne de vie. La boucle est rpte au moins minInt fois avant qu'une ventuelle condition de garde boolenne ne soit teste. Tant que la condition est vraie, la boucle continue, au plus maxInt fois. Cette syntaxe peut tre remplace par une indication intelligible comme sur la figure 7.15.

7-3-3-e - Oprateur par

Figure 7.16 : Microwave est un exemple d'objet effectuant deux tches en parallle. Un fragment combin de type parallel, ou par, possde au moins deux sous-fragments excuts simultanment (cf. figure 7.16). La concurrence est logique et n'est pas ncessairement physique : les excutions concurrentes peuvent s'entrelacer sur un mme chemin d'excution dans la pratique.

7-3-3-f - Oprateur strict

- 117 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 7.17 : Procdures de dcollage d'un avion dans l'ordre. Un fragment combin de type strict sequencing, ou strict, possde au moins deux sous-fragments. Ceux-ci s'excutent selon leur ordre d'apparition au sein du fragment combin. Ce fragment combin est utile surtout lorsque deux parties d'un diagramme n'ont pas de ligne de vie en commun (cf. figure 7.17).

7-3-4 - Utilisation d'interaction


Il est possible de faire rfrence une interaction (on appelle cela une utilisation d'interaction) dans la dfinition d'une autre interaction. Comme pour toute rfrence modulaire, cela permet la rutilisation d'une dfinition dans de nombreux contextes diffrents. Lorsqu'une utilisation d'interaction s'excute, elle produit le mme effet que l'excution d'une interaction rfrence avec la substitution des arguments fournie dans le cadre de l'utilisation de l'interaction. L'utilisation de l'interaction doit couvrir toutes les lignes de vie qui apparaissent dans l'interaction rfrence. L'interaction rfrence ne peut ajouter des lignes de vie que si elles ont lieu en son sein. Graphiquement, une utilisation apparat dans un diagramme de squence sous forme de rectangle avec le tag ref (pour rfrence). On place dans le rectangle le nom de l'interaction rfrence (cf. figure 7.17). La syntaxe complte pour spcifier l'interaction rutiliser est la suivante :
[ <nomAttributValeurRetour> '=' ] <nomInteraction> [ '(' [<arguments>] ')' ][ ':' <valeurRetour> ]

8 - Chapitre 8 Diagrammes de composants (Component diagram) et Diagrammes de dploiement (Deployment diagram) 8-1 - Introduction
Les diagrammes de composants et les diagrammes de dploiement sont les deux derniers types de vues statiques en UML. Les premiers dcrivent le systme modlis sous forme de composants rutilisables et mettent en vidence leurs relations de dpendance. Les seconds se rapprochent encore plus de la ralit physique, puisqu'ils identifient les lments matriels (PC, Modem, Station de travail, Serveur, etc.), leur disposition physique (connexions) et la disposition des excutables (reprsents par des composants) sur ces lments matriels.

- 118 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

8-2 - Diagrammes de composants 8-2-1 - Pourquoi des composants ?


Dans la section 1.1.4, parmi tous les facteurs qui concourent la qualit d'un logiciel, nous avons introduit la notion de rutilisabilit comme tant l'aptitude d'un logiciel tre rutilis, en tout ou en partie, dans de nouvelles applications. Or, la notion de classe, de par sa faible granularit et ses connexions figes (les associations avec les autres classes matrialisent des liens structurels), ne constitue pas une rponse adapte la problmatique de la rutilisation. Pour faire face ce problme, les notions de patrons et de canevas d'applications ont perc dans les annes 1990 pour ensuite laisser la place un concept plus gnrique et fdrateur : celui de composant. La programmation par composants constitue une volution technologique soutenue par de nombreuses plateformes (composants EJB, CORBA, .Net, WSDL). Ce type de programmation met l'accent sur la rutilisation du composant et l'indpendance de son volution vis--vis des applications qui l'utilisent. La programmation oriente composant s'intgre trs bien dans le contexte de la programmation oriente objet puisqu'il ne s'agit, finalement, que d'un facteur d'chelle. En effet, l'utilisation de composants est assimilable une approche objet, non pas au niveau du code, mais au niveau de l'architecture gnrale du logiciel.

Figure 8.1 : Reprsentation d'un composant et de ses interfaces requises ou offertes sous la forme d'un classeur structur strotyp component . Au lieu ou en plus du mot-clef, on peut faire figurer une icne de composant (petit rectangle quip de deux rectangles plus petits dpassant sur son ct gauche) dans l'angle suprieur droit (comme sur la figure de droite).

Figure 8.2 : Reprsentation d'un composant accompagne de la reprsentation explicite de ses interfaces requise et offerte.

Figure 8.3 : Reprsentation classique d'un composant et de ses interfaces requise (reprsent par un demi-cercle) et offerte (reprsente par un cercle). Cette reprsentation est souvent

- 119 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

utilise dans les diagrammes de composants (cf. figure 8.5). Sur la figure du bas, le strotype component est rendu inutile par la reprsentation mme du composant.

Figure 8.4 : Reprsentation d'un composant et de ses interfaces requise et offerte avec la reprsentation explicite de leur port correspondant.

Figure 8.5 : Reprsentation de l'implmentation d'un composant complexe contenant des sous-composants.

8-2-2 - Notion de composant


Un composant doit fournir un service bien prcis. Les fonctionnalits qu'il encapsule doivent tre cohrentes entre elles et gnriques (par opposition spcialises) puisque sa vocation est d'tre rutilisable. Un composant est une unit autonome reprsente par un classeur structur, strotyp component , comportant une ou plusieurs interfaces requises ou offertes. Son comportement interne, gnralement ralis par un ensemble de classes, est totalement masqu : seules ses interfaces sont visibles. La seule contrainte pour pouvoir substituer un composant par un autre est de respecter les interfaces requises et offertes. Les figures 8.1, 8.2, 8.3 et 8.4 illustrent diffrentes faons de reprsenter un composant. Un composant tant un classeur structur, on peut en dcrire la structure interne. L'implmentation d'un composant peut tre ralise par d'autres composants, des classes ou des artefacts (cf. section 8.3.3). Les lments d'un composant peuvent tre reprsents dans le symbole du composant (cf. figure 8.5), ou ct en les reliant au composant par une relation de dpendance. Pour montrer les instances des composants, un diagramme de dploiement doit tre utilis (cf. section 8.3).
- 120 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

8-2-3 - Notion de port


Un port est un point de connexion entre un classeur et son environnement. Graphiquement, un port est reprsent par un petit carr cheval sur la bordure du contour du classeur. On peut faire figurer le nom du port proximit de sa reprsentation. Gnralement, un port est associ une interface requise ou offerte (cf. figure 8.4). Parfois, il est reli directement un autre port situ sur la limite du composant englobant (cf. figure 8.5) par une flche en trait plein, pouvant tre strotyp delegate , et appel connecteur de dlgation. L'utilisation des ports permet de modifier la structure interne d'un classeur sans affecter les clients externes.

8-2-4 - Diagramme de composants

Figure 8.6 : Exemple de diagramme montrant les dpendances entre composants. La relation de dpendance est utilise dans les diagrammes de composants pour indiquer qu'un lment de l'implmentation d'un composant fait appel aux services offerts par les lments d'implmentation d'un autre composant (cf. figure 8.6). Lorsqu'un composant utilise l'interface d'un autre composant, on peut utiliser la reprsentation de la figure 8.3 en imbriquant le demi-cercle d'une interface requise dans le cercle de l'interface offerte correspondante (cf. figure 8.5).

8-3 - Diagramme de dploiement 8-3-1 - Objectif du diagramme de dploiement


Un diagramme de dploiement dcrit la disposition physique des ressources matrielles qui composent le systme et montre la rpartition des composants sur ces matriels. Chaque ressource tant matrialise par un nud, le diagramme de dploiement prcise comment les composants sont rpartis sur les nuds et quelles sont les connexions entre les composants ou les nuds. Les diagrammes de dploiement existent sous deux formes : spcification et instance.

8-3-2 - Reprsentation des nuds

Figure 8.7 : Reprsentation d'un nud ( gauche) et d'une instance de nud ( droite). Chaque ressource est matrialise par un nud reprsent par un cube comportant un nom (cf. figure 8.7). Un nud est un classeur et peut possder des attributs (quantit de mmoire, vitesse du processeur).

- 121 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 8.8 : Deux possibilits pour reprsenter l'affectation d'un composant un nud. Pour montrer qu'un composant est affect un nud, il faut soit placer le composant dans le nud, soit les relier par une relation de dpendance strotype support oriente du composant vers le nud (cf. figure 8.8).

8-3-3 - Notion d'artefact (artifact)

Figure 8.9 : Reprsentation du dploiement de deux artefacts dans un nud. La dpendance entre les deux artefacts est galement reprsente.

Figure 8.10 : Reprsentation du dploiement de deux artefacts dans un nud utilisant la relation de dpendance strotype deploy .

- 122 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 8.11 : Reprsentation du dploiement dans un nud d'un artefact manifestant un composant. Un artefact correspond un lment concret existant dans le monde rel (document, excutable, fichier, tables de bases de donnes, script). Il se reprsente comme un classeur par un rectangle contenant le mot-clef artifact suivi du nom de l'artefact (cf. figures 8.9 et 8.9). L'implmentation des modles (classes) se fait sous la forme de jeu d'artefacts. On dit qu'un artefact peut manifester, c'est--dire rsulter et implmenter, un ensemble d'lments de modle. On appelle manifestation la relation entre un lment de modle et l'artefact qui l'implmente. Graphiquement, une manifestation se reprsente par une relation de dpendance strotype manifest (cf. figure 8.11). Une instance d'un artefact se dploie sur une instance de nud. Graphiquement, on utilise une relation de dpendance (flche en trait pointill) strotype deploy pointant vers le nud en question (cf. figure 8.10). L'artefact peut aussi tre inclus directement dans le cube reprsentant le nud (cf. figure 8.9). En toute rigueur, seuls des artefacts doivent tre dploys sur des nuds. Un composant doit donc tre manifest par un artefact qui, luimme, peut tre dploy sur un nud.

8-3-4 - Diagramme de dploiement

Figure 8.12 : Exemple de diagramme de dploiement illustrant la communication entre plusieurs nuds. Dans un diagramme de dploiement, les associations entre nuds sont des chemins de communication qui permettent l'change d'informations (cf. figure 8.12).

9 - Chapitre 9 Mise en uvre d'UML Introduction 9-1-1 - UML n'est pas une mthode

- 123 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 9.1 : Quelle mthode pour passer de l'expression des besoins au code de l'application ? La problmatique que pose la mise en uvre d'UML est simple : comment passer de l'expression des besoins au code de l'application ? Cette problmatique est parfaitement illustre par la figure 9.1. Comme nous l'avons dj dit, maintes reprises, UML n'est qu'un langage de modlisation, ce n'est pas une mthode. En effet, UML ne propose pas une dmarche de modlisation explicitant et encadrant toutes les tapes d'un projet, de la comprhension des besoins la production du code de l'application. Une mthode se doit de dfinir une squence d'tapes, partiellement ordonnes, dont l'objectif est de produire un logiciel de qualit qui rpond aux besoins des utilisateurs dans des temps et des cots prvisibles. Bien qu'UML ne soit pas une mthode, ses auteurs prcisent nanmoins qu'une mthode base sur l'utilisation UML doit tre :

Pilote par les cas d'utilisation :

la principale qualit d'un logiciel tant son utilit, c'est--dire son adquation avec les besoins des utilisateurs, toutes les tapes, de la spcification des besoins la maintenance, doivent tre guides par les cas d'utilisation qui modlisent justement les besoins des utilisateurs ;

Centre sur l'architecture :

l'architecture est conue pour satisfaire les besoins exprims dans les cas d'utilisation, mais aussi pour prendre en compte les volutions futures et les contraintes de ralisation. La mise en place d'une architecture adapte conditionne le succs d'un dveloppement. Il est important de la stabiliser le plus tt possible ;

Itrative et incrmentale :

l'ensemble du problme est dcompos en petites itrations, dfinies partir des cas d'utilisation et de l'tude des risques. Les risques majeurs et les cas d'utilisation les plus importants sont traits en priorit. Le dveloppement procde par des itrations qui conduisent des livraisons incrmentales du systme. Nous avons dj prsent le modle de cycle de vie par incrment dans la section 1.2.3.

9-1-2 - Une mthode simple et gnrique


Dans les sections qui suivent (sections 9.2, 9.3 et 9.4) nous allons prsenter une mthode simple et gnrique qui se situe mi-chemin entre UP (Unified Process), qui constitue un cadre gnral trs complet de processus de dveloppement, et XP (eXtreme Programming) qui est une approche minimaliste la mode centre sur le code. Cette mthode est issue de celle prsente par [23] dans son livre UML - Modliser un site e-commerce qui rsulte de plusieurs annes d'exprience sur de nombreux projets dans des domaines varis. Elle a donc montr son efficacit dans la pratique et est : conduite par les cas d'utilisation, comme UP, mais bien plus simple ; relativement lgre et restreinte, comme XP, mais sans ngliger les activits de modlisation en analyse et conception ; fonde sur l'utilisation d'un sous-ensemble ncessaire et suffisant du langage UML (modliser 80 % des problmes en utilisant 20 % d'UML).

- 124 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Dans tous les cas, il faut garder l'esprit qu'une mthode n'est pas une formule magique. Le fait de produire des diagrammes UML selon un ordre tabli n'est en aucun cas une garantie de russite. Une mthode ne sert qu' canaliser et ordonner les tapes de la modlisation. La valeur n'est pas dans la mthode, mais dans les personnes qui la mettent en uvre.

9-2 - Identification des besoins 9-2-1 - Diagramme de cas d'utilisation

Figure 9.2 : Les besoins sont modliss par un diagramme de cas d'utilisation. Les cas d'utilisation sont utiliss tout au long du projet. Dans un premier temps, on les cre pour identifier et modliser les besoins des utilisateurs (figure 9.2). Ces besoins sont dtermins partir des informations recueillies lors des rencontres entre informaticiens et utilisateurs. Il faut imprativement proscrire toute considration de ralisation lors de cette tape. Durant cette tape, vous devrez dterminer les limites du systme, identifier les acteurs et recenser les cas d'utilisation (cf. section 2.5). Si l'application est complexe, vous pourrez organiser les cas d'utilisation en paquetages. Dans le cadre d'une approche itrative et incrmentale, il faut affecter un degr d'importance et un coefficient de risque chacun des cas d'utilisation pour dfinir l'ordre des incrments raliser. Les interactions entre les acteurs et le systme (au sein des cas d'utilisation) seront explicites sous forme textuelle et sous forme graphique au moyen de diagrammes de squence (cf. section 9.2.2). Les utilisateurs ont souvent beaucoup de difficults exprimer clairement et prcisment ce qu'ils attendent du systme. L'objectif de cette tape et des deux suivantes (section et 9.2.3) est justement de les aider formuler et formaliser ces besoins.

9-2-2 - Diagrammes de squence systme

- 125 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 9.3 : Les diagrammes de squence systme illustrent la description textuelle des cas d'utilisation. Dans cette tape, on cherche dtailler la description des besoins par la description textuelle des cas d'utilisation (cf. section 2.5.3) et la production de diagrammes de squence systme illustrant cette description textuelle (figure 9.3). Cette tape amne souvent mettre jour le diagramme de cas d'utilisation puisque nous sommes toujours dans la spcification des besoins. Les scnarii de la description textuelle des cas d'utilisation peuvent tre vus comme des instances de cas d'utilisation et sont illustrs par des diagrammes de squence systme. Il faut, au minimum, reprsenter le scnario nominal de chacun des cas d'utilisation par un diagramme de squence qui rend compte de l'interaction entre l'acteur, ou les acteurs, et le systme. Le systme est ici considr comme un tout et est reprsent par une ligne de vie. Chaque acteur est galement associ une ligne de vie. Lorsque les scnarii alternatifs d'un cas d'utilisation sont nombreux et importants, l'utilisation d'un diagramme d'tatstransitions ou d'activits peut s'avrer prfrable une multitude de diagrammes de squence.

9-2-3 - Maquette de l'IHM

- 126 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 9.4 : Une maquette d'IHM facilite les discussions avec les futurs utilisateurs. Une maquette d'IHM (Interface Homme-Machine) est un produit jetable permettant aux utilisateurs d'avoir une vue concrte, mais non dfinitive de la future interface de l'application (figure 9.4). La maquette peut trs bien consister en un ensemble de dessins produits par un logiciel de prsentation ou de dessin. Par la suite, la maquette pourra intgrer des fonctionnalits de navigation permettant l'utilisateur de tester l'enchanement des crans ou des menus, mme si les fonctionnalits restent fictives. La maquette doit tre dveloppe rapidement afin de provoquer des retours de la part des utilisateurs.

9-3 - Phases d'analyse 9-3-1 - Analyse du domaine : modle du domaine

- 127 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 9.5 : La phase d'analyse du domaine permet d'laborer la premire version du diagramme de classes. La modlisation des besoins par des cas d'utilisation s'apparente une analyse fonctionnelle classique. L'laboration du modle des classes du domaine permet d'oprer une transition vers une vritable modlisation objet. L'analyse du domaine est une tape totalement dissocie de l'analyse des besoins (sections 9.2.1, 9.2.2 et 9.2.3). Elle peut tre mene avant, en parallle ou aprs cette dernire. La phase d'analyse du domaine permet d'laborer la premire version du diagramme de classes (figure 9.5) appele modle du domaine. Ce modle doit dfinir les classes qui modlisent les entits ou concepts prsents dans le domaine (on utilise aussi le terme de mtier) de l'application. Il s'agit donc de produire un modle des objets du monde rel dans un domaine donn. Ces entits ou concepts peuvent tre identifis directement partir de la connaissance du domaine ou par des entretiens avec des experts du domaine. Il faut absolument utiliser le vocabulaire du mtier pour nommer les classes et leurs attributs. Les classes du modle du domaine ne doivent pas contenir d'opration, mais seulement des attributs. Les tapes suivre pour tablir ce diagramme sont (cf. section 3.6.1) : identifier les entits ou concepts du domaine ; identifier et ajouter les associations et les attributs ; organiser et simplifier le modle en liminant les classes redondantes et en utilisant l'hritage ; le cas chant, structurer les classes en paquetage selon les principes de cohrence et d'indpendance.

- 128 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

L'erreur la plus courante lors de la cration d'un modle du domaine consiste modliser un concept par un attribut alors que ce dernier devait tre modlis par une classe. Si la seule chose que recouvre un concept est sa valeur, il s'agit simplement d'un attribut. Par contre, si un concept recouvre un ensemble d'informations, alors il s'agit plutt d'une classe qui possde elle-mme plusieurs attributs.

9-3-2 - Diagramme de classes participantes

Figure 9.6 : Le diagramme de classes participantes effectue la jonction entre les cas d'utilisation, le modle du domaine et les diagrammes de conception logicielle. Le diagramme de classes participantes est particulirement important puisqu'il effectue la jonction entre, d'une part, les cas d'utilisation (section 9.2.1), le modle du domaine (section 9.3.1) et la maquette (section 9.2.3), et d'autre part, les diagrammes de conception logicielle que sont les diagrammes d'interaction (section 9.4.1) et le diagramme de classes de conception (section 9.4.2). Les diagrammes de conception logicielle n'apparaissent pas encore sur la figure 9.6. Il n'est pas souhaitable que les utilisateurs interagissent directement avec les instances des classes du domaine par le biais de l'interface graphique. En effet, le modle du domaine doit tre indpendant des utilisateurs et de l'interface graphique. De mme, l'interface graphique du logiciel doit pouvoir voluer sans rpercussion sur le cur de l'application. C'est le principe fondamental du dcoupage en couches d'une application. Ainsi, le diagramme de classes participantes modlise trois types de classes d'analyse, les dialogues, les contrles et les entits ainsi que leurs relations.
- 129 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Les classes de dialogues

Les classes qui permettent les interactions entre l'IHM et les utilisateurs sont qualifies de dialogues. Ces classes sont directement issues de l'analyse de la maquette prsente section 9.2.3. Il y a au moins un dialogue pour chaque association entre un acteur et un cas d'utilisation du diagramme de cas d'utilisation de la section 9.2.1. En gnral, les dialogues vivent seulement le temps du droulement du cas d'utilisation concern.

Les classes de contrles

Les classes qui modlisent la cinmatique de l'application sont appeles contrles. Elles font la jonction entre les dialogues et les classes mtier en permettant aux diffrentes vues de l'application de manipuler des informations dtenues par un ou plusieurs objets mtier. Elles contiennent les rgles applicatives et les isolent la fois des dialogues et des entits.

Les classes entits

Les classes mtier, qui proviennent directement du modle du domaine (cf. section 9.3.1), sont qualifies d'entits. Ces classes sont gnralement persistantes, c'est--dire qu'elles survivent l'excution d'un cas d'utilisation particulier et qu'elles permettent des donnes et des relations d'tre stockes dans des fichiers ou des bases de donnes. Lors de l'implmentation, ces classes peuvent ne pas se concrtiser par des classes, mais par des relations, au sens des bases de donnes relationnelles (cf. section 3.6.3).

Lors de l'laboration du diagramme de classes participantes, il faut veiller au respect des rgles suivantes : les entits, qui sont issues du modle du domaine, ne comportent que des attributs (cf. section 9.3.1) ; les entits ne peuvent tre en association qu'avec d'autres entits ou avec des contrles, mais, dans ce dernier cas, avec une contrainte de navigabilit interdisant de traverser une association d'une entit vers un contrle ; les contrles ne comportent que des oprations. Ils implmentent la logique applicative (i.e. les fonctionnalits de l'application), et peuvent correspondre des rgles transverses plusieurs entits. Chaque contrle est gnralement associ un cas d'utilisation, et vice versa. Mais rien n'empche de dcomposer un cas d'utilisation complexe en plusieurs contrles ; les contrles peuvent tre associs tous les types de classes, y compris d'autres contrles. Dans le cas d'une association entre un dialogue et un contrle, une contrainte de navigabilit doit interdire de traverser l'association du contrle vers le dialogue ; les dialogues comportent des attributs et des oprations. Les attributs reprsentent des informations ou des paramtres saisis par l'utilisateur ou des rsultats d'actions. Les oprations ralisent (gnralement par dlgation aux contrles) les actions que l'utilisateur demande par le biais de l'IHM ; les dialogues peuvent tre en association avec des contrles ou d'autres dialogues, mais pas directement avec des entits ; il est galement possible d'ajouter les acteurs sur le diagramme de classes participantes en respectant la rgle suivante : un acteur ne peut tre li qu' un dialogue.

Certaines classes possdent un comportement dynamique complexe. Ces classes auront intrt tre dtailles par des diagrammes d'tats-transitions. L'attribution des bonnes responsabilits, dgage dans la section 9.2.2, aux bonnes classes est l'un des problmes les plus dlicats de la conception oriente objet. Ce problme sera affront en phase de conception lors de l'laboration des diagrammes d'interaction (section 9.4.1) et du diagramme de classes de conception (section 9.4.2). Lors de la phase d'laboration du diagramme de classes participantes, le chef de projet a la possibilit de dcouper le travail de son quipe d'analystes par cas d'utilisation. L'analyse et l'implmentation des fonctionnalits dgages par les cas d'utilisation dfinissent alors les itrations raliser. L'ordonnancement des itrations tant dfini par le degr d'importance et le coefficient de risque affect chacun des cas d'utilisation dans la section 9.2.1.

- 130 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

9-3-3 - Diagrammes d'activits de navigation

Figure 9.7 : Les diagrammes d'activits de navigation reprsentent graphiquement l'activit de navigation dans l'IHM. Les IHM modernes facilitent la communication entre l'application et l'utilisateur en offrant toute une gamme de moyens d'action et de visualisation comme des menus droulants ou contextuels, des palettes d'outils, des botes de dialogues, des fentres de visualisation, etc. Cette combinaison possible d'options d'affichage, d'interaction et de navigation aboutit aujourd'hui des interfaces de plus en plus riches et puissantes. UML offre la possibilit de reprsenter graphiquement cette activit de navigation dans l'interface en produisant des diagrammes dynamiques. On appelle ces diagrammes des diagrammes de navigation. Le concepteur a le choix d'opter pour cette modlisation entre des diagrammes d'tats-transitions et des diagrammes d'activits. Les diagrammes d'activits constituent peut-tre un choix plus souple et plus judicieux. Les diagrammes d'activits de navigation sont relier aux classes de dialogue du diagramme de classes participantes. Les diffrentes activits du diagramme de navigation peuvent tre strotypes en fonction de leur nature : fentre , menu , menu contextuel , dialogue , etc. La modlisation de la navigation a intrt tre structure par acteur.

- 131 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

9-4 - Phase de conception 9-4-1 - Diagrammes d'interaction

Figure 9.8 : Les diagrammes d'interaction permettent d'attribuer prcisment les responsabilits de comportement aux classes d'analyse. Maintenant, il faut attribuer prcisment les responsabilits de comportement, dgages par le diagramme de squence systme dans la section 9.2.2, aux classes d'analyse du diagramme de classes participantes labor dans la section 9.3.2. Les rsultats de cette rflexion sont prsents sous la forme de diagrammes d'interaction UML (figure 9.8). Inversement, l'laboration de ces diagrammes facilite grandement la rflexion. Paralllement, une premire bauche de la vue statique de conception, c'est--dire du diagramme de classes de conception, est construite et complte. Durant cette phase, l'bauche du diagramme de classes de conception reste indpendante des choix technologiques qui seront faits ultrieurement (dans la section 9.4.2). Pour chaque service ou fonction, il faut dcider quelle est la classe qui va le contenir. Les diagrammes d'interactions (i.e de squence ou de communication) sont particulirement utiles au concepteur pour reprsenter graphiquement ces dcisions d'allocations des responsabilits. Chaque diagramme va reprsenter un ensemble d'objets de classes diffrentes collaborant dans le cadre d'un scnario d'excution du systme. Dans les diagrammes d'interaction, les objets communiquent en s'envoyant des messages qui invoquent des oprations sur les objets rcepteurs. Il est ainsi possible de suivre visuellement les interactions dynamiques entre objets, et les traitements raliss par chacun d'eux. Avec un outil de modlisation UML (comme Rational Rose ou PowerAMC), la spcification de l'envoi d'un message entre deux objets cre effectivement une opration publique sur la classe de l'objet cible. Ce type d'outil permet rellement de mettre en uvre l'allocation des responsabilits partir des diagrammes d'interaction.

- 132 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Figure 9.9 : Le systme des diagrammes de squences systme, vu comme une bote noire, est remplac par un ensemble d'objets en collaboration. Par rapport aux diagrammes de squences systme de la section 9.2.2, nous remplaons ici le systme, vu comme une bote noire, par un ensemble d'objets en collaboration (cf. figure 9.9). Ces objets sont des instances des trois types de classes d'analyse du diagramme de classes participantes, savoir des dialogues, des contrles et des entits. Les diagrammes de squences labors dans cette section doivent donc toujours respecter les rgles dictes dans la section 9.3.2. Ces rgles doivent cependant tre transposes, car, pour que deux objets puissent interagir directement, il faut que : les classes dont ils sont issus soient en association dans le diagramme de classes participantes (15) ; l'interaction respecte la navigabilit de l'association en question.

9-4-2 - Diagramme de classes de conception

Figure 9.10 : Chane complte de la dmarche de modlisation du besoin jusqu'au code. L'objectif de cette tape est de produire le diagramme de classes qui servira pour l'implmentation (figure 9.10). Une premire bauche du diagramme de classes de conception a dj t labore en parallle du diagramme d'interaction (section 9.4.1). Il faut maintenant le complter en prcisant les oprations prives des diffrentes
- 133 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

classes. Il faut prendre en comptes les choix techniques, comme le choix du langage de programmation, le choix des diffrentes bibliothques utilises (notamment pour l'implmentation de l'interface graphique), etc. Pour une classe, le couplage est la mesure de la quantit d'autres classes auxquelles elle est connecte par des associations, des relations de dpendances, etc. Durant toute l'laboration du diagramme de classes de conception, il faut veiller conserver un couplage faible pour obtenir une application plus volutive et plus facile maintenir. L'utilisation des design patterns est fortement conseille lors de l'laboration du diagramme de classes de conception. Pour le passage l'implmentation, referez-vous la section 3.6. Parfois, les classes du type entits ont intrt tre implmentes dans une base de donnes relationnelle (cf. section 3.6.3).

Bibliographie
[1] Wikipdia, encyclopdie librement distribuable. Internet. http://fr.wikipedia.org/wiki/Accueil. [2] Mamoun Alissali. Support de cours introduction au gnie logiciel. Internet, 1998. http://www-ic2.univ-lemans.fr/ ~alissali/Enseignement/Polys/GL/gl.html. [3] Franck Barbier. UML 2 et MDE. Dunod, 2005. [4] Donald Bell. Uml's sequence diagram. Internet, 2004. http://www-128.ibm.com/developerworks/rational/ library/3101.html#notes. [5] Grady Booch, James Rumbaugh, and Ivar Jacobson. Le guide de l'utilisateur UML. Eyrolles, 2003. [6] Eric Cariou. Support de cours le langage de contraintes ocl . Internet, novembre 2003. http://www.univ-pau.fr/ ~ecariou/cours/mde/cours-ocl.pdf. [7] Benot Charroux, Aomar Osmani, and Yann Thierry-Mieg. UML2. Pearson Education France, 2005. [8] Laurent Debrauwer and Fien Van der Heyd. UML 2 Initiation, exemples et exercices corrigs. eni, 2005. [9] Developpez.com. Club d'entraide des dveloppeurs francophones. Internet. http://www.developpez.com/. [10] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: elements of reusable object-oriented sofware. Addison-Wesley, 1995. [11] Erik Gollot. Les cas d'utilisation. Internet, 2004. http://ego.developpez.com/uml/tutoriel/casUtilisation/. [12] Pierre Grard. Uml. Internet, 2007. http://www-lipn.univ-paris13.fr/~gerard/fr_ens_uml.html. [13] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Printice Hall, 1997. [14] Hugues Malgouyres, Jean-Pierre Seuma-Vidal, and Gilles Motet. Rgles de cohrence UML 2.0 (version 1.1). Internet, 2005. http://www.lesia.insa-toulouse.fr/UML/CoherenceUML_v1_1_100605.pdf. [15] Bernard Morand. Analyse et conception des systmes d'information : Les diagrammes de unified modeling language (uml). Internet. http://www.iutc3.unicaen.fr/~moranb/cours/acsi/menucoo.htm. [16] Pierre-Alain Muller and Nathalie Gaertner. Modlisation objet avec UML. Eyrolles, 2000. [17] Object Management Group (OMG). Uml resource page. Internet. http://www.uml.org/.

- 134 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

[18] Object Management Group (OMG). Unified modeling language: Superstructure. Internet, aot 2004. http:// www.uml.org/. [19] Object Management Group (OMG). Object constraint language. Internet, mai 2006. http://www.uml.org/. [20] Tom Penders. Introduction UML. OEM, 2002. [21] Laurent Piechocki. Uml en franais. Internet. http://uml.free.fr/. [22] Dan Pilone and Neil Pitman. UML 2 en concentr. O'Reilly, 2006. [23] Pascal Roques. UML - Modliser un site e-commerce. Les cahiers du programmeur. Eyrolles, 2002. [24] Pascal Roques. UML2 - Modliser une application web. Les cahiers du programmeur. Eyrolles, 2006. e [25] Pascal Roques. UML2 par la pratique (tude de cas et exercices corrigs). Eyrolles, 5 dition, 2006. e [26] Pascal Roques and Franck Valle. UML en action. Eyrolles, 2 dition, 2003. [27] James Rumbaugh, Ivar Jacobson, and Grady Booch. UML 2.0 Guide de rfrence. CampusPress, 2004. [28] Michel Volle. De l'Informatique (Savoir vivre avec l'automate). Economica, 2006.

Index
Acteur, 2.2.1 identification, 2.5.1 principal, 2.3.1 reprsentation graphique, 2.2.1, 2.2.1 secondaire, 2.3.1 Action diagramme d'activits, 6.2.1 Activit diagramme d'activits, 6, 6.2.2, 6.7 groupe, 6.2.3 nud, 6.2.4 Agrgation, 1.3.4 composite , voir relation de composition implmentation en Java, 3.6.2, 3.6.2 Approche fonctionnelle, 1.3.1 fonctionnelle vs objet, 1.3.3 objet (concepts), 1.3.4 oriente objet, 1.3.2 structure, 1.3.1 Artefact (diagramme de dploiement), 8.3.3 Association Hritage, 1.3.4 classe, 3.3.9 implmentation en Java, 3.6.2 implmentation en SQL, 3.6.3 Historique modlisation objet, 1.4.2 programmation par objets, 1.3.5 Implmentation en Java, 3.6.2, 3.6.2 agrgation, 3.6.2 association 1 vers N, 3.6.2 association bidirectionnelle 1 vers 1, 3.6.2 association bidirectionnelle 1 vers N, 3.6.2 association unidirectionnelle 1 vers 1, 3.6.2 association unidirectionnelle 1 vers N, 3.6.2 attribut, 3.6.2 classe, 3.6.2 classe abstraite, 3.6.2 composition, 3.6.2 hritage simple, 3.6.2 interface, 3.6.2 opration, 3.6.2 ralisation d'une interface, 3.6.2 en SQL, 3.6.3, 3.6.3

- 135 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

1 vers 1 (implmentation en SQL), 3.6.3 1 vers N (implmentation en Java), 3.6.2 1 vers N (implmentation en SQL), 3.6.3 bidirectionnelle 1 vers 1 (implm. en Java), 3.6.2 bidirectionnelle 1 vers N (implm. en Java), 3.6.2 quivalences, 3.3.7 instance, 3.5.2 modles quivalents, 3.3.7 N vers N (implmentation en SQL), 3.6.3 n-aire, 3.3.3, 3.3.7 n-aire (modle quivalent), 3.3.7 n-aire vs classe-association vs qualifie, 3.3.7 notion et discussion, 3.3.1 qualifie, 3.3.6, 3.3.7 qualifie vs n-aire vs classeassociation, 3.3.7 unidirectionnelle 1 vers 1 (implm. en Java), 3.6.2 unidirectionnelle 1 vers N (implm. en Java), 3.6.2 Attribut, 3.2.6, 3.3.1 drivs, 3.2.6 de classe, 3.2.6 de la classe, 3.2.6 implmentation en Java, 3.6.2 implmentation en SQL, 3.6.3 syntaxe, 3.2.6 Autoassociation sur classe-association, 3.3.7 Automate tats finis, 5.1.2 Caractristique d'une classe, 3.2.2 terminaison d'association, 3.2.2 Cas d'utilisation, 2.2.2 description textuelle, 2.5.3 diagramme de cas d'utilisation, 2, 2.5.4 interne, 2.3.1 recensement, 2.5.2 reprsentation graphique, 2.2.2, 2.2.2 Use case Realization, 2.5.4 Classe, 1.3.4, 3.2, 3.2.8 abstraite, 3.2.7 abstraite (implmentation en Java), 3.6.2 active, 3.2.8 attribut, 3.2.6 attribut drivs, 3.2.6 attribut de classe, 3.2.6

association 1 vers 1, 3.6.3 association 1 vers N, 3.6.3 association N vers N, 3.6.3 attribut, 3.6.3 classe, 3.6.3 classe-association N vers N, 3.6.3 gnralisation, 3.6.3 hritage, 3.6.3 opration, 3.6.3 relation d'hritage, 3.6.3 relation de gnralisation, 3.6.3

Instance association, 3.5.2 classe, 3.2.1, 3.5.2 classe-association, 3.5.2 notion, 3.2.1 relation, 3.5.2 Interaction, 7.1.4 diagramme d'interaction, 7, 7.3.4 Interface, 1.3.4, 3.2.4, 3.2.7, 3.4 implmentation en Java, 3.6.2 Ligne de vie, 7.1.4 diagramme de communication, 7.2.1 diagramme de squence, 7.3.1 Logiciel, 1.1.2 cycle de vie, 1.2.2 qualit, 1.1.4 Mthode, 3.2.2, 3.2.7 abstraite, 3.2.7 de classe, 3.2.7 de la classe, 3.2.7 syntaxe, 3.2.7 Matre d'uvre, 1.2.1 Matre d'ouvrage, 1.2.1 Message asynchrone, 7.3.2 de cration, 7.3.2 de destruction, 7.3.2 diagramme de communication, 7.2.3 diagramme de squence, 7.3.2, 7.3.2 vnement, 7.3.2 perdu, 7.3.2 porte, 7.3.2 synchrone, 7.3.2 trouv, 7.3.2 Mise en uvre d'UML, 9, 9.4.2 Modle, 1.2.1 cycle de vie en cascade, 1.2.3 cycle de vie en spirale, 1.2.3

- 136 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

attribut de la classe, 3.2.6 caractristique, 3.2.2 diagramme de classes, 3, 3.4 encapsulation, 3.2.4 implmentation en Java, 3.6.2 implmentation en SQL, 3.6.3 instance, 3.2.1, 3.5.2 interface, 3.2.4 mthode, 3.2.2, 3.2.7 mthode de classe, 3.2.7 mthode de la classe, 3.2.7 notion, 3.2.1 opration, 3.2.2 proprits, 3.2.2 proprits structurelles, 3.2.2 reprsentation graphique, 3.2.3 syntaxe du nom, 3.2.5 visibilit, 3.2.4 Classe-association, 3.3.7, 3.3.7 autoassociation, 3.3.7 instance, 3.5.2 liens multiples, 3.3.7 modle quivalent, 3.3.7 N vers N (implmentation en SQL), 3.6.3 pour plusieurs associations, 3.3.7 reprsentation graphique, 3.3.7 vs association n-aire vs association qualifie, 3.3.7 Classeur, 2.4.3 interface, 3.4 structur, 7.1.2 Collaboration, 7.1.3 Communication diagramme de communication, 7.2, 7.2.3 Composant diagramme de composant, 8.2.2 diagramme de composants, 8.2, 8.2.4 Concurrence dans un diagramme d'tatstransitions, 5.6.5 Contrainte, 4.1.2 prdfinie, 4.1.3 reprsentation, 4.1.3 typologie des contraintes OCL, 4.3, 4.3.7 Cycle de vie en cascade, 1.2.3 en spirale, 1.2.3 en V, 1.2.3 logiciel, 1.2.2 modle par incrment, 1.2.3 Dploiement

cycle de vie en V, 1.2.3 cycles de vie, 1.2.3 incrment, 1.2.3 Pourquoi modliser ?, 1.2.1 Qui doit modliser ?, 1.2.1 Multiplicit relation d'association, 2.3.1 Nud d'action, 6.3.1 d'activit, 6.2.4 d'activit structure, 6.3.2 d'objet, 6.5 d'union, 6.4.4 de bifurcation, 6.4.4 de contrle, 6.4 de dbranchement, 6.4.4 de dcision, 6.4.3 de fin d'activit, 6.4.2 de fin de flot, 6.4.2 de fusion, 6.4.3 de jointure, 6.4.4 de stockage des donnes, 6.5.6 diagramme de dploiement, 8.3.2 excutable, 6.3 final, 6.4.2 initial, 6.4.1 tampon central, 6.5.5 Navigabilit, 3.3.5 reprsentation graphique, 3.3.5 Note, 2.4.5 reprsentation graphique, 2.4.5 Object constraint langage, 4, 4.7 Objet diagramme d'objets, 3.5, 3.5.3 qualifi, 3.3.6 reprsentation graphique, 3.5.2 OCL, 4, 4.7 -(), 4.6.2 =(), 4.6.2 ->, 4.6.1 ., 4.6.1 ::, 4.6.1 accs aux attributs (self), 4.5.1 accs aux caractristiques, 4.5, 4.5.8 accs aux objets, 4.5, 4.5.8 accs aux oprations (self), 4.5.1 accder une caractristique redfinie (oclAsType()), 4.5.6 allInstances, 4.5.8 asBag(), 4.6.2 asOrderedSet(), 4.6.2 asSequence(), 4.6.2 body, 4.3.5 collect, 4.6.3 collections, 4.4.4 context, 4.3.2

- 137 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

diagramme de dploiement, 8.3, 8.3.4 Dpendance classe, 3.3.10 Diagramme d'tats-transitions, 5, 5.6.5 d'activits, 6, 6.7 d'interaction, 7, 7.3.4 d'objets, 3.5, 3.5.3 de cas d'utilisation, 2, 2.5.4 de classes, 3, 3.4 de communication, 7.2, 7.2.3 de composants, 8.2, 8.2.4 de dploiement, 8.3, 8.3.4 de squence, 7.3, 7.3.4 Diagramme d'tats-transitions, 5, 5.6.5 concurrence, 5.6.5 tat, 5.2 tat composite, 5.6, 5.6.5 tat final, 5.2.2 tat historique, 5.6.3 tat historique profond, 5.6.3 tat initial, 5.2.2 vnement, 5.3, 5.3.5 vnement d'appel, 5.3.3 vnement de changement, 5.3.4 vnement de type signal, 5.3.2 vnement temporel, 5.3.5 point de choix, 5.5, 5.5.2 point de dcision, 5.5.2 point de jonction, 5.5.1 points de connexion, 5.6.4 transition, 5.4, 5.4.6 transition d'achvement, 5.4.5 transition externe, 5.4.4 transition interne, 5.4.6 Diagramme d'activits, 6, 6.7 action, 6.2.1 activit, 6.2.2 exceptions, 6.2.1, 6.7 flot d'objet, 6.5.4 groupe d'activits, 6.2.3 nud d'action, 6.3.1 nud d'activit, 6.2.4 nud d'activit structure, 6.3.2 nud d'objet, 6.5 nud d'union, 6.4.4 nud de bifurcation, 6.4.4 nud de contrle, 6.4 nud de dbranchement, 6.4.4 nud de dcision, 6.4.3 nud de fin d'activit, 6.4.2 nud de fin de flot, 6.4.2 nud de fusion, 6.4.3 nud de jointure, 6.4.4 nud de stockage des donnes, 6.5.6
- 138 -

contexte (context), 4.3.2 count(), 4.6.2 dfinition d'attributs et de mthode (def et letin), 4.3.6 def, 4.3.6 est un langage typ, 4.4.3 excludes(), 4.6.2 excludesAll(), 4.6.2 excluding(), 4.6.2 exists, 4.6.3 forAll, 4.6.3 includes(), 4.6.2 includesAll(), 4.6.2 including(), 4.6.2 init, 4.3.7 initialisation (init), 4.3.7 intersection(), 4.6.2 inv, 4.3.3 invariants (inv), 4.3.3 isEmpty(), 4.6.2 let in, 4.3.6 navigation depuis une classe association, 4.5.5 navigation vers une classe association, 4.5.4 navigation via une association, 4.5.2 navigation via une association qualifie, 4.5.3 notEmpty(), 4.6.2 oclAsType(), 4.5.6, 4.5.7 oclInState(), 4.5.7 oclIsKindOf(), 4.5.7 oclIsNew(), 4.5.7 oclIsTypeOf(), 4.5.7 oprateurs prdfinis, 4.4.1 opration sur les classes, 4.5.8 oprations, 4.4, 4.4.4 oprations collect, 4.6.3 oprations exists, 4.6.3 oprations forAll, 4.6.3 oprations reject, 4.6.3 oprations select, 4.6.3 oprations prdfinies sur tous les objets, 4.5.7 oprations sur les lments d'une collection, 4.6.3 oprations sur les collections, 4.6, 4.6.2, 4.6.4 oprations sur les ensembles, 4.6.2 post, 4.3.4 postconditions (post), 4.3.4 prcdence des oprateurs, 4.6.4 prconditions (pre), 4.3.4 pre, 4.3.4 product(), 4.6.2

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

nud excutable, 6.3 nud final, 6.4.2 nud initial, 6.4.1 nud tampon central, 6.5.5 partitions, 6.6 pin d'entre, 6.5.2 pin de sortie, 6.5.2 pin de valeur, 6.5.3 transition, 6.2.5 Diagramme d'interaction, 7, 7.3.4 interaction, 7.1.4 ligne de vie, 7.1.4 Diagramme d'objets, 3.5, 3.5.3 relation de dpendance d'instanciation, 3.5.3 reprsentation graphique, 3.5.2 Diagramme de cas d'utilisation, 2, 2.5.4 acteur, 2.2.1 acteur principal, 2.3.1 acteur secondaire, 2.3.1 cas d'utilisation, 2.2.2 cas d'utilisation interne, 2.3.1 identifier les acteurs, 2.5.1 recenser les cas d'utilisation, 2.5.2 relation d'association, 2.3.1 relation d'extension, 2.3.2 relation d'inclusion, 2.3.2 relation de gnralisation, 2.3.2, 2.3.2, 2.3.3 relation de spcialisation, 2.3.2, 2.3.2 relations, 2.3, 2.3.3 reprsentation graphique, 2.2.3 Use case Realization, 2.5.4 Diagramme de classes, 3, 3.4 autoassociation sur classeassociations, 3.3.7 classe, 3.2, 3.2.8 classe association, 3.3.7, 3.3.7 classe association (instance), 3.5.2 classe association pour plusieurs associations, 3.3.7 classe-association vs association n-aire vs association qualifie, 3.3.7 laboration, 3.6.1 interface, 3.4 notion d'association, 3.3.1 possession d'une terminaison d'association, 3.3.2 propritaire d'une terminaison d'association, 3.3.2 relation d'agrgation, 3.3.8 relation d'association, 3.3.3, 3.3.7

rgles de prcdence des oprateurs, 4.6.4 rsultat d'une mthode (body), 4.3.5 reject, 4.6.3 select, 4.6.3 self, 4.5.1, 4.6.1 size(), 4.6.2 sum(), 4.6.2 types, 4.4, 4.4.4 types du modle UML, 4.4.2 types prdfinis, 4.4.1 typologie des contraintes, 4.3, 4.3.7 union(), 4.6.2 Oprateur alt, 7.3.3 loop, 7.3.3 opt, 7.3.3 par, 7.3.3 strict, 7.3.3 Opration, 3.2.2 implmentation en Java, 3.6.2 implmentation en SQL, 3.6.3 Paquetage, 2.4.1 reprsentation graphique, 2.4.1 Partitions (diagramme d'activits), 6.6 Pin d'entre (diagramme d'activits), 6.5.2 de sortie (diagramme d'activits), 6.5.2 de valeur (diagramme d'activits), 6.5.3 Point de choix, 5.5, 5.5.2 point de dcision, 5.5.2 point de jonction, 5.5.1 Point de dcision, 5.5.2 Point de jonction, 5.5.1 Points de connexion, 5.6.4 Polymorphisme, 1.3.4 Port (diagramme de composants), 8.2.3 Porte, 7.3.2 Proprit (terminaison d'association), 3.3.2 Proprits d'une classe, 3.2.2 structurelles d'une classe, 3.2.2 Qualificatif, 3.3.6 Ralisation d'une interface implmentation en Java, 3.6.2 Relation instance, 3.5.2 Relation d'agrgation classe, 3.3.8 implmentation en Java, 3.6.2

- 139 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

relation d'association binaire, 3.3.3 relation d'association n-aire, 3.3.3 relation d'association qualifie, 3.3.6 relation d'hritage, 3.3.9 relation de composition, 3.3.8 relation de dpendance, 3.3.10 relation de gnralisation, 3.3.9 terminaison d'association, 3.3.2 Diagramme de communication, 7.2, 7.2.3 connecteur, 7.2.2 ligne de vie, 7.2.1 messages, 7.2.3 Diagramme de composants, 8.2, 8.2.4 composant, 8.2.2 port, 8.2.3 Diagramme de dploiement, 8.3, 8.3.4 artefact, 8.3.3 nud, 8.3.2 Diagramme de squence, 7.3, 7.3.4 vnement, 7.3.2 excution de mthode, 7.3.2 excution simultane, 7.3.2 fragment d'interaction combin, 7.3.3, 7.3.3 ligne de vie, 7.3.1 message, 7.3.2 message asynchrone, 7.3.2 message de cration, 7.3.2 message de destruction, 7.3.2 message perdu, 7.3.2 message synchrone, 7.3.2 message trouv, 7.3.2 objet actif, 7.3.2 oprateur alt, 7.3.3 oprateur loop, 7.3.3 oprateur opt, 7.3.3 oprateur par, 7.3.3 oprateur strict, 7.3.3 porte, 7.3.2 syntaxe des messages, 7.3.2 utilisation d'interaction, 7.3.4 Encapsulation, 1.3.4, 3.2.4 Espace de noms, 2.4.2 tat, 5.2 composite, 5.6, 5.6.5 final, 5.2.2 historique, 5.6.3 historique profond, 5.6.3 initial, 5.2.2 tats-transition diagramme d'tats-transitions, 5, 5.6.5 tude du Standish Group, 1.1.2

reprsentation graphique, 3.3.8 Relation d'association acteur cas d'utilisation, 2.3.1 binaire, 3.3.3 cardinalit, 3.3.4 classe, 3.3.3, 3.3.7 implmentation en Java, 3.6.2, 3.6.2 implmentation en SQL, 3.6.3, 3.6.3 multiplicit, 2.3.1, 3.3.4 n-aire, 3.3.3 navigabilit, 3.3.5 qualificatif, 3.3.6 reprsentation graphique, 2.3.1, 3.3.3, 3.3.3 Relation d'association qualifie classe, 3.3.6 Relation d'extension cas d'utilisation, 2.3.2 Relation d'hritage classe, 3.3.9 implmentation en SQL, 3.6.3 reprsentation graphique, 3.3.9 Relation d'inclusion cas d'utilisation, 2.3.2 Relation de composition classe, 3.3.8 implmentation en Java, 3.6.2 reprsentation graphique, 3.3.8 Relation de dpendance classe, 3.3.10 reprsentation graphique, 2.3.2, 3.3.10 Relation de dpendance d'instanciation, 3.5.3 Relation de gnralisation acteur, 2.3.3 classe, 3.3.9 diagramme de cas d'utilisation, 2.3.2, 2.3.2 implmentation en SQL, 3.6.3 reprsentation graphique, 2.3.3, 3.3.9 Relation de spcialisation acteur, 2.3.3 cas d'utilisation, 2.3.2, 2.3.2 Squence diagramme de squence, 7.3, 7.3.4 Spcialisation, 1.3.4 acteur, 2.3.3 cas d'utilisation, 2.3.2, 2.3.2 Strotype, 2.4.4

- 140 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

Exceptions (diagramme d'activits), 6.2.1, 6.7 vnement, 5.3, 5.3.5 d'appel, 5.3.3 de changement, 5.3.4 de type signal, 5.3.2 diagramme de squence, 7.3.2 temporel, 5.3.5 Flot d'objet (diagramme d'activits), 6.5.4 Fragment d'interaction combin, 7.3.3, 7.3.3 Oprateur alt, 7.3.3 Oprateur loop, 7.3.3 Oprateur opt, 7.3.3 Oprateur par, 7.3.3 Oprateur strict, 7.3.3 Gnralisation, 1.3.4 cas d'utilisation, 2.3.2, 2.3.2 classe, 3.3.9 implmentation en SQL, 3.6.3 Gnie logiciel, 1.1, 1.1.3 Gnie logiciel (crise), 1.1.3 Groupe d'activits (diagramme d'activits), 6.2.3

Standish Group (tude du), 1.1.2 Terminaison d'association, 3.2.2, 3.3.1, 3.3.2 possession, 3.3.2 proprit, 3.3.2 propritaire, 3.3.2 Transition, 5.4, 5.4.6 condition de garde, 5.4.2 d'achvement, 5.4.5 diagramme d'activits, 6.2.5 effet, 5.4.3 externe, 5.4.4 interne, 5.4.6 Typologie des contraintes OCL, 4.3, 4.3.7 Utilisation d'interaction, 7.3.4 Visibilit, 3.2.4

- 141 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.

UML 2 par Laurent AUDIBERT

1 : Par exemple, aujourd'hui, 90% des nouvelles fonctionnalits des automobiles sont apportes par l'lectronique et l'informatique embarques. Il y a, ou aura terme, du logiciel partout : ampoules lectriques, four micro-ondes, tissus des vtements, stylos, livres, etc. 2 : Comparativement sa production, le cot du dveloppement d'un logiciel est extrmement important. Nous verrons par la suite que la maintenance cote galement trs cher. 3 : cf. section 1.2.1.d << Matrise d'ouvrage et matrise d'uvre >> pour une dfinition de ce terme. 4 : Souvent, les personnes qui doivent oprer des modifications ultrieures dans le code ne sont plus les personnes qui l'ont dvelopp. 5 : L'OMG (Object Management Group) est une association amricaine but non lucratif cre en 1989 dont l'objectif est de standardiser et promouvoir le modle objet sous toutes ses formes. L'OMG est notamment la base des spcifications UML, MOF, CORBA et IDL. L'OMG est aussi l'origine de la recommandation MDA. 6 : Certains lments, comme les associations, peuvent avoir des instances bien qu'ils ne soient pas reprsents dans des classeurs. 7 : Une partition d'un ensemble est un ensemble de parties non vides de cet ensemble, deux deux disjointes et dont la runion est gale l'ensemble. 8 : Il faut ici aborder un petit problme de terminologie autour du mot proprit. En effet, dans la littrature, le mot proprit est parfois utilis pour dsigner toutes les caractristiques d'une classe (i.e. les attributs comme les mthodes). Dans ce cas, les attributs et les terminaisons d'association sont rassembls sous le terme de proprits structurelles, le qualificatif structurelle prenant ici toute son importance. D'un autre ct, le mot proprit est souvent utilis dans l'acception du terme anglais property (dans la norme UML Superstructure version 2.1.1), qui, lui, ne dsigne que les attributs et les terminaisons d'association, c'est--dire les proprits structurelles. Pour englober les mthodes, il faut alors utiliser le terme plus gnrique de caractristiques, qui prend ainsi le rle de traduction du terme anglais feature dans la norme. Dans le prsent cours, je m'efforce de me conformer cette deuxime solution o proprit et proprit structurelle dsignent finalement la mme chose. 9 : De manire gnrale, toute bote non strotype dans un diagramme de classes est implicitement une classe. Ainsi, le strotype class est le strotype par dfaut. 10 : Une terminaison d'associations est une extrmit de l'association. Une association binaire en possde deux, une association n-aire en possde n. 11 : UML Superstructure Specification, v2.1.1 ; p.49 : << It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end, i.e., from the instance point of view, the multiplicity of the associations ends are 1' >> 12 : Non, il n'y a pas d'erreur de copier/coller : rflchissez ! 13 : Doctrine ou point de vue qui consiste considrer les phnomnes comme des totalits. 14 : Dans la norme UML 1, le diagramme de communication s'appelait diagramme de collaboration. 15 : Si elles ne sont pas en association, il doit au moins exister une relation de dpendance comme illustr par la figure 3.21 de la section 3.3.10.

- 142 -

Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge par les droits d'auteur. Copyright 2013 Laurent AUDIBERT. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.