Cours UML PDF

UML 2
dition 2007-2008
Laurent AUDIBERT
Institut Universitaire de Technologie de Villetaneuse Dpartement Informatique

Avenue Jean-Baptiste Clment
93430 Villetaneuse
Adresse lectronique : laurent[dot]audibert[at]iutv[dot]univ-paris13[dot]fr
Adresse du document : http ://www-lipn.univ-paris13.fr/ audibert/pages/enseignement/cours.htm
2 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/
Avant-propos
Les techniques de programmation nont cess de progresser depuis lpoque de la program-

mation 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 lassembleur (1947), avec larrive de lordinateur
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.
Lalgorithmique 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 dap-
plications 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 simposaient dans le domaine de la modlisation objet
au milieu des annes 1990 : OMT, Booch et OOSE. Dimportants acteurs industriels (IBM,
Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) sassocient alors leffort et proposent UML
1.0 lOMG (Object Management Group) qui laccepte en novembre 1997 dans sa version 1.1.
La version dUML en cours en 2008 est UML 2.1.1 qui simpose plus que jamais en tant que
langage de modlisation standardis pour la modlisation des logiciels.
Ce document constitue le support du cours dUML 2 dispens aux tudiants du dpartement
dinformatique de linstitut 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 Charroux, Osmani et Thierry-Mieg (2005) qui constitue une bonne introduction
au langage UML. Aomar Osmani est lorigine du cours dUML dans notre IUT.
Rumbaugh, Jacobson et Booch (2004), Booch, Rumbaugh et Jacobson (2003), Barbier (2005)
Roques et Valle (2003) et Muller et Gaertner (2000) ont galement t largement utiliss.
Rumbaugh et al.. (2004) est un ouvrage de rfrence assez complet et contient un dictionnaire
dtaill de la terminologie UML 2.0. Booch et al.. (2003), galement crit par les crateurs du
langage UML, est un guide dapprentissage compltant bien le premier ouvrage. Muller et
3
Gaertner (2000) est un cours dUML 2.0 bien expliqu et plus complet et dtaill que Charroux
et al.. (2005) mais, en contrepartie, moins accessible. Barbier (2005) constitue une approche
pratique et critique dUML trs intressante. Roques (2006b) constitue une excellente approche
concrte dUML comportant des exercices corrigs de trs bonne facture que nous reprenons
parfois dans les travaux dirigs de ce cours. Pascal Roques est probablement lun des auteurs
les plus prolifique (Roques, 2002 ; Roques & Valle, 2003 ; Roques, 2006a ; Roques, 2006b) et
comptant concernant la mise en uvre dUML.
Agrable lire, Volle (2006) sintresse la place de linformatique dans notre socit et plus
particulirement dans lentreprise.
Enfin, diverses sources trouves sur Internet, inpuisable source dinformation en perptuel
renouvellement, mont galement t dun grand secours. Parmi ces dernires, certaines sont
incontournables, comme le cours de Piechocki (n.d.) ou encore le site Developpez.com (n.d.).

Table des matires
1 Introduction la modlisation objet 11

1.1 Le gnie logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.1 Linformatisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.2 Les logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.3 Le gnie logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.4 Notion de qualit pour un logiciel . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Modlisation, cycles de vie et mthodes . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1 Pourquoi et comment modliser ? . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2 Le cycle de vie dun logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.3 Modles de cycles de vie dun logiciel . . . . . . . . . . . . . . . . . . . . . 16
1.2.4 Mthodes danalyse et de conception . . . . . . . . . . . . . . . . . . . . . 18
1.3 De la programmation structure lapproche oriente objet . . . . . . . . . . . . . 19
1.3.1 Mthodes fonctionnelles ou structures . . . . . . . . . . . . . . . . . . . . 19
1.3.2 Lapproche oriente objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.3 Approche fonctionnelle vs. approche objet . . . . . . . . . . . . . . . . . . 20
1.3.4 Concepts importants de lapproche objet . . . . . . . . . . . . . . . . . . . 21
1.3.5 Historique la programmation par objets . . . . . . . . . . . . . . . . . . . . 22
1.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.2 Histoire des modlisations par objets . . . . . . . . . . . . . . . . . . . . . 23
1.4.3 UML en uvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4.4 Comment prsenter un modle UML ? . . . . . . . . . . . . . . . . . . . . . 25
1.5 Travaux Dirigs Introduction la modlisation objet . . . . . . . . . . . . . . . 27
1.5.1 Objectifs et mise en situation . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5.3 Conception avec une approche structure . . . . . . . . . . . . . . . . . . . 27
1.5.4 Conception avec une approche objet . . . . . . . . . . . . . . . . . . . . . . 28
1.5.5 Maintenance volutive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2 Diagramme de cas dutilisation 29

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 lments des diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . . . . 29
2.2.1 Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.2 Cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.3 Reprsentation dun diagramme de cas dutilisation . . . . . . . . . . . . . 30
2.3 Relations dans les diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . 31
2.3.1 Relations entre acteurs et cas dutilisation . . . . . . . . . . . . . . . . . . . 31
5
TABLE DES MATIRES
2.3.2 Relations entre cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.3 Relations entre acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 Notions gnrales du langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 Paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.2 Espace de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.3 Classeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.4 Strotype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.5 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5 Modlisation des besoins avec UML . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5.1 Comment identifier les acteurs ? . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5.2 Comment recenser les cas dutilisation ? . . . . . . . . . . . . . . . . . . . . 37
2.5.3 Description textuelle des cas dutilisation . . . . . . . . . . . . . . . . . . . 38
2.5.4 Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6 Travaux Dirigs Diagramme de cas dutilisation . . . . . . . . . . . . . . . . . . 41
2.6.1 Identification des acteurs et de cas dutilisation simples . . . . . . . . . . . 41
2.6.2 Caisse enregistreuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.6.3 La bibliothque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 Diagramme de classes 45
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Les classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.1 Notions de classe et dinstance de classe . . . . . . . . . . . . . . . . . . . . 45
3.2.2 Caractristiques dune classe . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.3 Reprsentation graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.4 Encapsulation, visibilit, interface . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.5 Nom dune classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.6 Les attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.7 Les mthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.8 Classe active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Relations entre classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1 Notion dassociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.2 Terminaison dassociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.3 Association binaire et n-aire . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.4 Multiplicit ou cardinalit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.5 Navigabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.6 Qualification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3.7 Classe-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.8 Agrgation et composition . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.9 Gnralisation et Hritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.10 Dpendance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5 Diagramme dobjets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5.2 Reprsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5.3 Relation de dpendance dinstanciation . . . . . . . . . . . . . . . . . . . . 64
3.6 laboration et implmentation dun diagramme de classes . . . . . . . . . . . . . 64
3.6.1 laboration dun diagramme de classes . . . . . . . . . . . . . . . . . . . . 64
3.6.2 Implmentation en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

TABLE DES MATIRES
3.6.3 Implmentation en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.7 Travaux Dirigs Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.1 Proprits et relations simples . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.2 Identification des relations . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.3 Interfaces / hritage multiple . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.7.4 Classes / Objets / Implmentation . . . . . . . . . . . . . . . . . . . . . . . . 74
3.7.5 Systme de rservation de vols : Modle du domaine . . . . . . . . . . . . . 75
3.7.6 La bibliothque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4 Object constraint langage (OCL) 77

4.1 Expression des contraintes en UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.2 criture des contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.3 Reprsentation des contraintes et contraintes prdfinies . . . . . . . . . . 79
4.2 Intrt dOCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.2.1 OCL Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.2.2 Illustration par lexemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3 Typologie des contraintes OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.1 Diagramme support des exemples illustratifs . . . . . . . . . . . . . . . . . 82
4.3.2 Contexte (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3.3 Invariants (inv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3.4 Prconditions et postconditions (pre, post) . . . . . . . . . . . . . . . . . . . 84
4.3.5 Rsultat dune mthode (body) . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.3.6 Dfinition dattributs et de mthodes (def et let. . .in) . . . . . . . . . . . . . 85
4.3.7 Initialisation (init) et volution des attributs (derive) . . . . . . . . . . . . . 86
4.4 Types et oprations utilisables dans les expressions OCL . . . . . . . . . . . . . . 87
4.4.1 Types et oprateurs prdfinis . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.4.2 Types du modle UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.4.3 OCL est un langage typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.4.4 Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.5 Accs aux caractristiques et aux objets . . . . . . . . . . . . . . . . . . . . . . . . 88
4.5.1 Accs aux attributs et aux oprations (self ) . . . . . . . . . . . . . . . . . . 88
4.5.2 Navigation via une association . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.5.3 Navigation via une association qualifie . . . . . . . . . . . . . . . . . . . . 89
4.5.4 Navigation vers une classe association . . . . . . . . . . . . . . . . . . . . . 90
4.5.5 Navigation depuis une classe association . . . . . . . . . . . . . . . . . . . 90
4.5.6 Accder une caractristique redfinie (oclAsType()) . . . . . . . . . . . . . 91
4.5.7 Oprations prdfinies sur tous les objets . . . . . . . . . . . . . . . . . . . 91
4.5.8 Opration sur les classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.6 Oprations sur les collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.6.1 Introduction : ., ->, : : et self . . . . . . . . . . . . . . . . . . . . . . . 92
4.6.2 Oprations de base sur les collections . . . . . . . . . . . . . . . . . . . . . 93
4.6.3 Opration sur les lments dune collection . . . . . . . . . . . . . . . . . . 94
4.6.4 Rgles de prcdence des oprateurs . . . . . . . . . . . . . . . . . . . . . . 96
4.7 Exemples de contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 7

TABLE DES MATIRES
5 Diagramme dtats-transitions 99
5.1 Introduction au formalisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.2 Notion dautomate tats finis . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.3 Diagrammes dtats-transitions . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2 tat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.1 Les deux acceptions du terme tat . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.2 tat initial et final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3 vnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3.1 Notion dvnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3.2 vnement de type signal (signal) . . . . . . . . . . . . . . . . . . . . . . . 102
5.3.3 vnement dappel (call) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3.4 vnement de changement (change) . . . . . . . . . . . . . . . . . . . . . . 103
5.3.5 vnement temporel (after ou when) . . . . . . . . . . . . . . . . . . . . . . 103
5.4 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.1 Dfinition et syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.2 Condition de garde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.4.3 Effet dune transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.4.4 Transition externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.4.5 Transition dachvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.4.6 Transition interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5 Point de choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.5.1 Point de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.5.2 Point de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.6 tats composites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.6.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.6.2 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.6.3 tat historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.6.4 Interface : les points de connexion . . . . . . . . . . . . . . . . . . . . . . . 110
5.6.5 Concurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.7 Travaux Dirigs Diagramme dtats-transitions . . . . . . . . . . . . . . . . . . 113
5.7.1 Porte de garage motorise enroulement . . . . . . . . . . . . . . . . . . . 113
5.7.2 Montre digitale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6 Diagramme dactivits 117

6.1 Introduction au formalisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.1.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.1.2 Utilisation courante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.2 Activit et Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2.1 Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2.2 Activit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.2.3 Groupe dactivits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.2.4 Nud dactivit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.2.5 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.3 Nud excutable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.3.1 Nud daction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.3.2 Nud dactivit structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.4 Nud de contrle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

TABLE DES MATIRES
6.4.1 Nud initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.4.2 Nud final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.4.3 Nud de dcision et de fusion . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.4.4 Nud de bifurcation et dunion . . . . . . . . . . . . . . . . . . . . . . . . 124
6.5 Nud dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.5.2 Pin dentre ou de sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.5.3 Pin de valeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.5.4 Flot dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.5.5 Nud tampon central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.5.6 Nud de stockage des donnes . . . . . . . . . . . . . . . . . . . . . . . . 126
6.6 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.7 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.8 Travaux Dirigs Diagramme dactivits . . . . . . . . . . . . . . . . . . . . . . . 131
6.8.1 Mousse au chocolat (question du contrle du 8 janvier 2007) . . . . . . . . 131
6.8.2 Modlisation dune opration dinsertion dans un tableau tri . . . . . . . 131
6.8.3 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.8.4 Documentation dun cas dutilisation . . . . . . . . . . . . . . . . . . . . . 131
7 Diagrammes dinteraction 135

7.1 Prsentation du formalisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.1.2 Classeur structur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.1.3 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.1.4 Interactions et lignes de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.1.5 Reprsentation gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.2 Diagramme de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.2.1 Reprsentation des lignes de vie . . . . . . . . . . . . . . . . . . . . . . . . 139
7.2.2 Reprsentation des connecteurs . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.2.3 Reprsentation des messages . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.3 Diagramme de squence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.3.1 Reprsentation des lignes de vie . . . . . . . . . . . . . . . . . . . . . . . . 140
7.3.2 Reprsentation des messages . . . . . . . . . . . . . . . . . . . . . . . . . . 140
7.3.3 Fragments dinteraction combins . . . . . . . . . . . . . . . . . . . . . . . 144
7.3.4 Utilisation dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
7.4 Travaux Dirigs Diagramme dinteraction . . . . . . . . . . . . . . . . . . . . . . 147
7.4.1 Diagramme de communication : syntaxe des messages . . . . . . . . . . . 147
7.4.2 Nono le petit robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.4.3 Types de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.4.4 La bibliothque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.4.5 Distributeur de boisson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8 Diagrammes de composants et de dploiement 151

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8.2 Diagrammes de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8.2.1 Pourquoi des composants ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8.2.2 Notion de composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
8.2.3 Notion de port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

TABLE DES MATIRES
8.2.4 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

8.3 Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
8.3.1 Objectif du diagramme de dploiement . . . . . . . . . . . . . . . . . . . . 155
8.3.2 Reprsentation des nuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
8.3.3 Notion dartefact (artifact) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
8.3.4 Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
9 Mise en uvre dUML 159

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
9.1.1 UML nest pas une mthode . . . . . . . . . . . . . . . . . . . . . . . . . . 159
9.1.2 Une mthode simple et gnrique . . . . . . . . . . . . . . . . . . . . . . . 160
9.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
9.2.1 Diagramme de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . 160
9.2.2 Diagrammes de squence systme . . . . . . . . . . . . . . . . . . . . . . . 161
9.2.3 Maquette de lIHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
9.3 Phases danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
9.3.1 Modle du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
9.3.2 Diagramme de classes participantes . . . . . . . . . . . . . . . . . . . . . . 163
9.3.3 Diagrammes dactivits de navigation . . . . . . . . . . . . . . . . . . . . . 165
9.4 Phase de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
9.4.1 Diagrammes dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
9.4.2 Diagramme de classes de conception . . . . . . . . . . . . . . . . . . . . . 168
Bibliographie 171
Index 173

Chapitre 1
Introduction la modlisation objet
1.1 Le gnie logiciel

1.1.1 Linformatisation
Linformatisation est le phnomne le plus important de notre poque. Elle simmisce main-
tenant dans la pluspart des objets de la vie courante et ce, que ce soit dans lobjet proprement
dit 1 , ou bien dans le processus de conception ou de fabrication de cet objet.
Actuellement, linformatique est au cur de toutes les grandes entreprises. Le systme
dinformation dune entreprise est compos de matriels et de logiciels. Plus prcisment, les
investissements dans ce systme dinformation se rparatissent 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 relative-
ment fiable et le march est standardis. Les problmes lis linformatique 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 dassurer 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 dquipes coordonnes. Le dveloppement de grands logiciels par
de grandes quipes pose dimportants problmes de conception et de coordination. Or, le
dveloppement dun logiciel est une phase absolument cruciale qui monopolise lessentiel du
cot dun produit2 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
8380 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 dun facteur 2 3 avec diminution
du nombre des fonctions offertes,
1
Par exemple, aujourdhui, 90% des nouvelles fonctionnalits des automobiles sont apportes par llectronique
et linformatique 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 dun logiciel est extrmement important. Nous
verrons par la suite que la maintenance cote galement trs cher.
11
CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET
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.
Lexamen des causes de succs et dchec est instructif : la plupart des checs proviennent
non de linformatique, mais de la matrise douvrage3 (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 maintenance4
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, Garmisch-Partenkirchen, sous le parrainage de lOTAN. Il a pour objectif de rpondre
un problme qui snonait en deux constatations : dune part le logiciel ntait pas fiable,
dautre part, il tait incroyablement difficile de raliser dans des dlais prvus des logiciels
satisfaisant leur cahier des charges.
Lobjectif du gnie logiciel est doptimiser le cot de dveloppement du logiciel. Limpor-
tance dune approche mthodologique sest impose la suite de la crise de lindustrie du
logiciel la fin des annes 1970. Cette crise de lindustrie du logiciel tait principalement due
:
laugmentation des cots ;
les difficults de maintenance et dvolution ;
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 dun logiciel. En
effet, une enqute effectue aux USA en 1986 auprs de 55 entreprises rvle que 53% du budget
total dun 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 performance 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 sintresse particulirement
la manire dont le code source dun logiciel est spcifi puis produit. Ainsi, le gnie logiciel
touche au cycle de vie des logiciels :
lanalyse du besoin,
llaboration des spcifications,
la conceptualisation,
le dveloppement,
la phase de test,
3
c.f. section 1.2.1 Matrise douvrage et matrise duvre 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 lont dvelopp.

1.2. MODLISATION, CYCLES DE VIE ET MTHODES
la maintenance.
Les projets relatifs lingnierie logicielle sont gnralement de grande envergure et d-
passent souvent les 10000 lignes de code. Cest 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 lapplication et des outils utiliss. Parmi
ces derniers nous pouvons citer :
Validit : aptitude dun produit logiciel remplir exactement ses fonctions, dfinies par le
cahier des charges et les spcifications.
Fiabilit ou robustesse : aptitude dun produit logiciel fonctionner dans des conditions anor-
males.
Extensibilit (maintenance) : facilit avec laquelle un logiciel se prte sa maintenance, cest-
-dire une modification ou une extension des fonctions qui lui sont demandes.
Rutilisabilit : aptitude dun logiciel tre rutilis, en tout ou en partie, dans de nouvelles
applications.
Compatibilit : facilit avec laquelle un logiciel peut tre combin avec dautres logiciels.
Efficacit : Utilisation optimales des ressources matrielles.
Portabilit : facilit avec laquelle un logiciel peut tre transfr sous diffrents environnements
matriels et logiciels.
Vrifiabilit : facilit de prparation des procdures de test.
Intgrit : aptitude dun logiciel protger son code et ses donnes contre des accs non
autoriss.
Facilit demploi : facilit dapprentissage, dutilisation, de prparation des donnes, dinter-
prtation des erreurs et de rattrapage en cas derreur dutilisation.
Ces facteurs sont parfois contradictoires, le choix des compromis doit seffectuer en fonction du
contexte.
1.2 Modlisation, cycles de vie et mthodes

1.2.1 Pourquoi et comment modliser ?
Quest-ce quun modle ?
Un modle est une reprsentation abstraite et simplifie (i.e. qui exclut certains dtails), dune
entit (phnomne, processus, systme, etc.) du monde rel en vue de le dcrire, de lexpliquer
ou de le prvoir. Modle est synonyme de thorie, mais avec une connotation pratique : un
modle, cest une thorie oriente vers laction quelle doit servir.
Concrtement, un modle permet de rduire la complexit dun phnomne en liminant
les dtails qui ninfluencent 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 dobservation (satellite, . . .), il permet de prvoir

les conditions climatiques pour les jours venir.
Modle conomique peut par exemple permettre de simuler lvolution de cours boursiers
en fonction dhypothses macro-conomiques (volution du chmage, taux de croissance,
. . .).
Modle dmographique dfinit la composition dun panel dune population et son com-
portement, dans le but de fiabiliser des tudes statistiques, daugmenter limpact de
dmarches commerciales, etc.
Plans Les plans sont des modles qui donnent une vue densemble du systme concern.
Par exemple, dans le btiment, pour la construction dun immeuble, il faut pralablement
laborer de nombreux plans :
plans dimplantation du btiment dans son environnement ;
plans gnraux du btiment et de sa structure ;
plans dtailles des diffrents locaux, bureaux, appartements, . . .
plans des cblages lectriques ;
plans dcoulements des eaux, etc.
Les trois premiers exemples sont des modles que lon qualifie de prdictifs. Le dernier,
plus conceptuel, possde diffrents niveaux de vues comme la pluspart des modles en gnie
logiciel.
Pourquoi modliser ?
Modliser un systme avant sa ralisation permet de mieux comprendre le fonctionnement
du systme. Cest galement un bon moyen de matriser sa complexit et dassurer sa cohrence.
Un modle est un langage commun, prcis, qui est connu par tous les membres de lquipe 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 douvrage et la matrise duvre informatique) et prcise dun problme
donn.
Dans le domaine de lingnierie du logiciel, le modle permet de mieux rpartir les tches
et dautomatiser certaines dentre elles. Cest 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 aller-
retours entre le code et le modle sans perte dinformation. Le modle est enfin indispensable
pour assurer un bon niveau de qualit et une maintenance efficace. En effet, une fois mise en
production, lapplication va devoir tre maintenue, probablement par une autre quipe et, qui
plus est, pas ncessairement de la mme socit que celle ayant cre lapplication.
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 mo-
dles employs, la dmarche de modlisation nest pas la mme.
Qui doit modliser ?

La modlisation est souvent faite par la matrise duvre informatique (MOE). Cest mal-
encontreux, car les priorits de la MOE rsident dans le fonctionnement de la plate-forme
informatique et non dans les processus de lentreprise.
Il est prfrable que la modlisation soit ralise par la matrise douvrage (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 plate-forme informatique.
Il est vrai que certains mtiers, dont les priorits sont oprationnelles, ne disposent pas tou-
jours de la capacit dabstraction et de la rigueur conceptuelle ncessaires la formalisation. La
professionnalisation de la MOA a pour but de les doter de ces comptences. Cette professionna-
lisation rside essentiellement dans laptitude modliser le systme dinformation du mtier :
le matre mot est modlisation. Lorsque le modle du systme dinformation est de bonne qualit,
sobre, clair, stable, la matrise duvre peut travailler dans de bonnes conditions. Lorsque cette
professionnalisation a lieu, elle modifie les rapports avec linformatique et dplace la frontire
des responsabilits, ce qui contrarie parfois les informaticiens dans un premier temps, avant
quils nen voient apparatre les bnfices.
Matrise douvrage et matrise duvre

Matre douvrage (MOA) : Le MOA est une personne morale (entreprise, direction etc.), une
entit de lorganisation. Ce nest jamais une personne.
Matre duvre (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 dun 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 four-
nisseurs. Le MOE assure leur coordination ; il veille la cohrence des fournitures et leur
compatibilit. Il coordonne laction des fournisseurs en contrlant la qualit technique, en as-
surant 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 dun logiciel

Le cycle de vie dun logiciel (en anglais software lifecycle), dsigne toutes les tapes du dve-
loppement dun logiciel, de sa conception sa disparition. Lobjectif dun tel dcoupage est
de permettre de dfinir des jalons intermdiaires permettant la validation du dveloppement
logiciel, cest--dire la conformit du logiciel avec les besoins exprims, et la vrification du
processus de dveloppement, cest--dire ladquation des mthodes mises en uvre.
Lorigine de ce dcoupage provient du constat que les erreurs ont un cot dautant plus
lev quelles 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 :
Dfinition des objectifs Cet tape consiste dfinir la finalit du projet et son inscription
dans une stratgie globale.
Analyse des besoins et faisabilit cest--dire lexpression, le recueil et la formalisation des
besoins du demandeur (le client) et de lensemble des contraintes, puis lestimation de la
faisabilit de ces besoins.

Spcifications ou conception gnrale Il sagit de llaboration des spcifications de larchi-

tecture gnrale du logiciel.
Conception dtaille Cette tape consiste dfinir prcisment chaque sous-ensemble du
logiciel.
Codage (Implmentation ou programmation) cest la traduction dans un langage de pro-
grammation des fonctionnalits dfinies lors de phases de conception.
Tests unitaires Ils permettent de vrifier individuellement que chaque sous-ensemble du
logiciel est implment conformment aux spcifications.
Intgration Lobjectif est de sassurer de linterfaage des diffrents lments (modules) du
logiciel. Elle fait lobjet de tests dintgration consigns dans un document.
Qualification (ou recette) Cest--dire la vrification de la conformit du logiciel aux spcifi-
cations initiales.
Documentation Elle vise produire les informations ncessaires pour lutilisation du logiciel
et pour des dveloppements ultrieurs.
Mise en production Cest le dploiement sur site du logiciel.
Maintenance Elle comprend toutes les actions correctives (maintenance corrective) et volu-
tives (maintenance volutive) sur le logiciel.
La squence et la prsence de chacune de ces activits dans le cycle de vie dpend du choix
dun modle de cycle de vie entre le client et lquipe de dveloppement. Le cycle de vie permet
de prendre en compte, en plus des aspects techniques, lorganisation et les aspects humains.
1.2.3 Modles de cycles de vie dun logiciel

Modle de cycle de vie en cascade
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 sils sont jugs satisfaisants.
Le modle original ne comportait pas de possibilit de retour en arrire. Celle-ci a t rajoute
ultrieurement sur la base quune tape ne remet en cause que ltape prcdente, ce qui, dans
la pratique, savre insuffisant.
Linconvnient 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 dintgration, ou
pire, lors de la mise en production.
Modle de 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 sagit dun modle en cascade dans lequel le dveloppement des
tests et du logiciels sont effectus de manire synchrone.
Le principe de ce modle est quavec toute dcomposition doit tre dcrite la recomposition
et que toute description dun composant est accompagne de tests qui permettront de sassurer
quil correspond sa description.

F. 1.1 Modle du cycle de vie en cascade
F. 1.2 Modle du cycle de vie en V

Ceci rend explicite la prparation des dernires phases (validation-vrification) par les pre-
mires (construction du logiciel), et permet ainsi dviter un cueil bien connu de la spcification
du logiciel : noncer une proprit quil est impossible de vrifier objectivement aprs la rali-
sation.
Cependant, ce modle souffre toujours du problme de la vrification trop tardive du bon
fonctionnement du systme.
Modle de cycle de vie en spirale

Propos par B. Boehm en 1988, ce modle est beaucoup plus gnral que le prcdent. Il
met laccent sur lactivit danalyse des risques : chaque cycle de la spirale se droule en quatre
phases :
1. dtermination, partir des rsultats des cycles prcdents, ou de lanalyse prliminaire
des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ;
2. analyse des risques, valuation des alternatives et, ventuellement maquettage ;
3. dveloppement et vrification de la solution retenue, un modle classique (cascade ou
en V) peut tre utilis ici ;
4. revue des rsultats et vrification du cycle suivant.
Lanalyse prliminaire est affine au cours des premiers cycles. Le modle utilise des ma-
quettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se
termine par un processus de dveloppement classique.
Modle par incrment

Dans les modles prcdents un logiciel est dcompos en composants dvelopps spar-
ment et intgrs la fin du processus.
Dans les modles par incrment un seul ensemble de composants est dvelopp la fois :
des incrments viennent sintgrer un noyau de logiciel dvelopp au pralable. Chaque
incrment est dvelopp selon lun 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 leffort 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 globa-
lement, au dbut du projet. Les incrments doivent tre aussi indpendants que possibles,
fonctionnellement mais aussi sur le plan du calendrier du dveloppement.
1.2.4 Mthodes danalyse et de conception

Les mthodes danalyse 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 :

1.3. DE LA PROGRAMMATION STRUCTURE LAPPROCHE ORIENTE OBJET
La distinction entre composition et dcomposition : Elle met en opposition dune part les m-
thodes ascendantes qui consistent construire un logiciel par composition partir de
modules existants et, dautre part, les mthodes descendantes qui dcomposent rcursi-
vement le systme jusqu arriver des modules programmables simplement.
La distinction entre fonctionnel (dirige par le traitement) et oriente objet : Dans la strat-
gie fonctionnelle (galement qualifie de structure) un systme est vu comme un en-
semble hirarchique dunits en interaction, ayant chacune une fonction clairement d-
finie. Les fonctions disposent dun tat local, mais le systme a un tat partag, qui est
centralis et accessible par lensemble des fonctions. Les stratgies orientes objet consi-
drent quun systme est un ensemble dobjets interagissants. Chaque objet dispose dun
ensemble dattributs dcrivant son tat et ltat du systme est dcrit (de faon dcentra-
lise) par ltat de lensemble.
1.3 De la programmation structure lapproche oriente objet

1.3.1 Mthodes fonctionnelles ou structures
F. 1.3 Reprsentation graphique dune 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 spci-
fications dont lessentielle est sous forme de notation graphique en diagrammes de flots de
donnes. Le plus haut niveau reprsente lensemble du problme (sous forme dactivit, de
donnes ou de processus, selon la mthode). Chaque niveau est ensuite dcompos en respec-
tant les entres/sorties du niveau suprieur. La dcomposition se poursuit jusqu arriver des
composants matrisables (cf. figure 1.3).
Lapproche 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 transversalles matrialisent la manipulation de ces donnes par des sous-
fonctions. Cet accs peut-tre direct (cest 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 danalyse
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 nest pas une simple collection dlments indpendants, mais une
organisation structure de ceux-ci dans une finalit prcise.
En rsum, larchitecture du systme est dicte par la rponse au problme (i.e. la fonction
du systme).
1.3.2 Lapproche oriente objet

Lapproche oriente objet considre le logiciel comme une collection dobjets dissocis, iden-
tifis et possdant des caractristiques. Une caractristique est soit un attribut (i.e. une donne
caractrisant ltat de lobjet), soit une entit comportementale de lobjet (i.e. une fonction). La
fonctionnalit du logiciel merge alors de linteraction entre les diffrents objets qui le consti-
tuent. Lune des particularits de cette approche est quelle rapproche les donnes et leurs
traitements associs au sein dun unique objet.
Comme nous venons de le dire, un objet est caractris par plusieurs notions :
Lidentit Lobjet possde une identit, qui permet de le distinguer des autres objets, ind-
pendamment 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 sagit des donnes caractrisant lobjet. Ce sont des variables stockant des
informations sur ltat de lobjet.
Les mthodes Les mthodes dun objet caractrisent son comportement, cest--dire len-
semble des actions (appeles oprations) que lobjet est mme de raliser. Ces oprations
permettent de faire ragir lobjet aux sollicitations extrieures (ou dagir sur les autres ob-
jets). 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
dobjets, dentits 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 logi-
cielles fondes sur les objets du systme, plutt que sur la fonction quil est cens raliser.
En rsum, larchitecture 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 quil est possible dcrire dans un langage
pourrait galement tre crit dans nimporte quel autre langage. Ainsi, tout ce que lon fait
avec un langage de programmation par objets pourrait tre fait en programmation imprative.
La diffrence entre une approche fonctionnelle et une approche objet nest donc pas dordre
logique, mais pratique.
Lapproche structure privilgie la fonction comme moyen dorganisation du logiciel. Ce
nest pas pour cette raison que lapproche objet est une approche non fonctionnelle. En effet,
les mthodes dun objet sont des fonctions. Ce qui diffrencie sur le fond lapproche objet de
lapproche fonctionnelle, cest que les fonctions obtenues lissue de la mise en uvre de lune

1.3. DE LA PROGRAMMATION STRUCTURE LAPPROCHE ORIENTE OBJET
ou lautre mthode sont distinctes. Lapproche objet est une approche oriente donne. Dans
cette approche, les fonctions se dduisent dun regroupement de champs de donnes formant
une entit cohrente, logique, tangible et surtout stable quant au problme trait. Lapproche
structure classique privilgie une organisation des donnes postrieure la dcouverte des
grandes, puis petites fonctions qui les dcomposent, lensemble constituant les services qui
rpondent aux besoins.
En approche objet, lvolution des besoins aura le plus souvent tendance se prsenter
comme un changement de linteraction des objets. Sil faut apporter une modification aux
donnes, seul lobjet 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, lvolution 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. Dautre part, une modification des donnes entrane gnralement une modification
dun nombre important de fonctions parpilles et difficiles identifier dans la hirarchie de
cette dcomposition.
En fait, la modularit nest pas antinomique de lapproche structure. Les modules rsultant
de la dcomposition objet sont tout simplement diffrents de ceux manant de lapproche
structure. Les units de traitement, et surtout leur dpendance dans la topologie de la figure
1.3 sont initialement bons. Cest leur rsistance au temps, contrairement aux modules objet, qui
est source de problme. La structure dun logiciel issue dune approche structure est beaucoup
moins mallable, adaptable, que celle issue dune approche objet.
Ainsi la technologie objet est la consquence ultime de la modularisation du logiciel, d-
marche qui vise matriser sa production et son volution. Mais malgr cette continuit logique
les langages objet ont apport en pratique un profond changement dans lart de la programma-
tion : ils impliquent en effet un changement de lattitude mentale du programmeur.
1.3.4 Concepts importants de lapproche objet

Dans la section 1.3.2, nous avons dit que lapproche objet rapproche les donnes et leurs
traitements. Mais cette approche ne fait pas que a, dautres concepts importants sont spcifiques
cette approche et participent la qualit du logiciel.
Notion de classe
Tout dabord, introduisons la notion de classe. Une classe est un type de donnes abstrait
qui prcise des caractristiques (attributs et mthodes) communes toute une famille dobjets
et qui permet de crer (instancier) des objets possdant ces caractristiques. Les autres concepts
importants quil nous faut maintenant introduire sont lencapsulation, lhritage et lagrgation.
Encapsulation
Lencapsulation consiste masquer les dtails dimplmentation dun objet, en dfinissant

une interface. Linterface est la vue externe dun objet, elle dfinit les services accessibles (offerts)
aux utilisateurs de lobjet.
Lencapsulation facilite lvolution dune application car elle stabilise lutilisation des objets :
on peut modifier limplmentation des attributs dun objet sans modifier son interface, et donc
la faon dont lobjet est utilis.

Lencapsulation garantit lintgrit des donnes, car elle permet dinterdire, ou de res-
treindre, laccs direct aux attributs des objets.
Hritage, Spcialisation, Gnralisation et Polymorphisme
Lhritage est un mcanisme de transmission des caractristiques dune classe (ses attributs
et mthodes) vers une sous-classe. Une classe peut tre spcialise en dautres classes, afin dy
ajouter des caractristiques spcifiques ou den adapter certaines. Plusieurs classes peuvent tre
gnralises en une classe qui les factorise, afin de regrouper les caractristiques communes
dun ensemble de classes.
Ainsi, la spcialisation et la gnralisation permettent de construire des hirarchies de
classes. Lhritage peut tre simple ou multiple. Lhritage vite la duplication et encourage la
rutilisation.
Le polymorphisme reprsente la facult dune mthode pouvoir sappliquer des objets
de classes diffrentes. Le polymorphisme augmente la gnricit, et donc la qualit, du code.
Agrgation
Il sagit dune relation entre deux classes, spcifiant que les objets dune classe sont des
composants de lautre classe. Une relation dagrgation permet donc de dfinir des objets
composs dautres objets. Lagrgation permet donc dassembler des objets de base, afin de
construire des objets plus complexes.
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, lhritage, lencapsulation, 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 program-
mation oriente objets, aux Bell Labs dAT&T en 1982. C++ deviendra le langage le plus utilis
par les programmeurs professionnels. Il arrivera maturation 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 ltendue 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 lcriture
du code : il faut dabord organiser ses ides, les documenter, puis organiser la ralisation en

1.4. UML
dfinissant les modules et tapes de la ralisation. Cest cette dmarche antrieure lcriture
que lon appelle modlisation ; son produit est un modle.
Les spcifications fournies par la matrise douvrage en programmation imprative taient
souvent floues : les articulations conceptuelles (structures de donnes, algorithmes de traite-
ment) sexprimant dans le vocabulaire de linformatique, le modle devait souvent tre labor
par celle-ci. Lapproche objet permet en principe la matrise douvrage de sexprimer de faon
prcise selon un vocabulaire qui, tout en transcrivant les besoins du mtier, pourra tre imm-
diatement compris par les informaticiens. En principe seulement, car la modlisation demande
aux matrises douvrage une comptence et un professionnalisme qui ne sont pas aujourdhui
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 limportance au dbut des annes 1990, la
ncessit dune 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 simposer. 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 dun systme ;
OOD de Grady Booch, dfinie pour le Department of Defense, introduit le concept de
paquetage (package) ;
OOSE dIvar Jacobson (Ericsson) fonde lanalyse sur la description des besoins des utili-
sateurs (cas dutilisation, ou use cases).
Chaque mthode avait ses avantages et ses partisans. Le nombre de mthodes en comptition
stait rduit, mais le risque dun clatement subsistait : la profession pouvait se diviser entre ces
trois mthodes, crant autant de continents intellectuels qui auraient du mal communiquer.
vnement considrable et presque miraculeux, les trois gourous qui rgnaient chacun sur
lune des trois mthodes se mirent daccord 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. Ladjectif unified est l pour marquer quUML
unifie, et donc remplace.
En fait, et comme son nom lindique, UML na pas lambition dtre exactement une m-
thode : cest un langage.
Lunification a progress par tapes. En 1995, Booch et Rumbaugh (et quelques autres) se
sont mis daccord 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 sassocient alors
leffort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et UML 1.0 est soumis
lOMG5 . LOMG adopte en novembre 1997 UML 1.1 comme langage de modlisation des
systmes dinformation objets. La version dUML en cours en 2008 est UML 2.1.1 et les
travaux damlioration se poursuivent.
5
LOMG (Object Management Group) est une association amricaine but non-lucratif cre en 1989 dont lobjectif
est de standardiser et promouvoir le modle objet sous toutes ses formes. LOMG est notamment la base des
spcifications UML, MOF, CORBA et IDL. LOMG est aussi lorigine de la recommandation MDA

UML est donc non seulement un outil intressant mais une norme qui simpose en techno-
logie objets et laquelle se sont rangs tous les grands acteurs du domaine, acteurs qui ont
dailleurs contribu son laboration.
1.4.3 UML en uvre

UML nest pas une mthode (i.e. une description normative des tapes de la modlisation) :
ses auteurs ont en effet estim quil ntait 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 dun systme dinformation.
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 dun logiciel, ou de tout
autre systme complexe, de mme quil 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 dune statue, et
dont la conjonction donnera une ide utilisable en pratique sans risque derreur grave.
UML 2.0 comporte ainsi treize types de diagrammes reprsentant autant de vues distinctes
pour reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deux
grands groupes :
Diagrammes structurels ou diagrammes statiques (UML Structure)
diagramme de classes (Class diagram)
diagramme dobjets (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 dutilisation (Use case diagram)
diagramme dactivits (Activity diagram)
diagramme dtats-transitions (State machine diagram)
Diagrammes dinteraction (Interaction diagram)
diagramme de squence (Sequence diagram)
diagramme de communication (Communication diagram)
diagramme global dinteraction (Interaction overview diagram)
diagramme de temps (Timing diagram)
Ces diagrammes, dune utilit variable selon les cas, ne sont pas ncessairement tous pro-
duits loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les dia-
grammes dactivits, de cas dutilisation, de classes, dobjets, de squence et dtats-transitions.
Les diagrammes de composants, de dploiement et de communication sont surtout utiles pour
la matrise duvre qui ils permettent de formaliser les contraintes de la ralisation et la
solution technique.
Diagramme de cas dutilisation

Le diagramme de cas dutilisation (cf. section 2) reprsente la structure des grandes fonc-
tionnalits ncessaires aux utilisateurs du systme. Cest le premier diagramme du modle

1.4. UML
UML, celui o sassure la relation entre lutilisateur et les objets que le systme met en uvre.
Diagramme de classes
Le diagramme de classes (cf. section 3) est gnralement considr comme le plus important
dans un dveloppement orient objet. Il reprsente larchitecture 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).
Diagramme dobjets
Le diagramme dobjets (cf. section 3.5) permet dclairer un diagramme de classes en lillus-
trant par des exemples. Il est, par exemple, utilis pour vrifier ladquation dun diagramme
de classes diffrents cas possibles.
Diagramme dtats-transitions
Le diagramme dtats-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.
Diagramme dactivits
Le diagramme dactivits (cf. section 6) nest autre que la transcription dans UML de la repr-
sentation du processus telle quelle a t labore lors du travail qui a prpar la modlisation :
il montre lenchanement des activits qui concourent au processus.
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 lacteur va manipuler et les oprations
qui font passer dun objet lautre. 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
lune partir de lautre) dune mme chronologie. Ce sont des diagrammes dinteraction (section
7).
1.4.4 Comment prsenter un modle UML ?

La prsentation dun modle UML se compose de plusieurs documents crits en langage
courant et dun 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 :
Prsentation stratgique : elle dcrit pourquoi lentreprise a voulu se doter de loutil considr,
les buts quelle 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 lapplication 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 : il sagit de synthtiser, sous
les yeux du lecteur, les discussions qui ont prsid ces choix.
Modle formel : cest le document le plus pais et le plus difficile lire. Il est prfrable de
le prsenter sur lIntranet de lentreprise. En effet, les diagrammes peuvent tre alors
quips de liens hypertextes permettant louverture de diagrammes plus dtaills ou de
commentaires.
On doit prsenter en premier le diagramme de cas dutilisation qui montre lenchanement
des cas dutilisation au sein du processus, enchanement immdiatement comprhensible ; puis
le diagramme dactivits, qui montre le contenu de chaque cas dutilisation ; puis le diagramme
de squence, qui montre lenchanement chronologique des oprations lintrieur de chaque
cas dutilisation. 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.).

1.5. TRAVAUX DIRIGS INTRODUCTION LA MODLISATION OBJET
1.5 Travaux Dirigs Introduction la modlisation objet

1.5.1 Objectifs et mise en situation
Objectifs
Nous navons pas encore commenc ltude des diagrammes UML, il nest donc pas nces-
saire de respecter la notation UML au cours de ce TD.
Lobjectif est de montrer que tout dveloppement est prcd dune phase danalyse et que
des mthodes diffrentes mnent des solutions diffrentes. Lobjectif doit galement permettre
de distinguer lapproche structure de lapproche objet.
Mise en situation
Une bibliothque souhaite informatiser le rfrencement de ses ouvrages ainsi que sa gestion
des prts.
Les ouvrages de cette bibliothque sont des romans, caractriss par un titre, un auteur
et un diteur et des bandes dessines caractrises par un titre, un dessinateur et un diteur.
Concernant la gestion des ouvrages, le bibliothcaire aimerait un logiciel lui permettant de saisir
de nouveaux ouvrages, mettre jour des ouvrages existants, et ventuellement en supprimer.
Il voudrait pouvoir raliser peu prs les mmes oprations sur les abonns.
Bien entendu, le logiciel doit permettre la gestion des prts (lemprunt et le retour). Une fonc-
tionnalit doit permettre denvoyer une lettre de rappel pour tous les exemplaires emprunts
depuis quatre jours pour les bandes dessines et deux semaines pour les romans.
Le bibliothcaire aimerait, en outre, pouvoir effectuer une recherche duvre sur le titre.
Enfin, le bibliothcaire doit pouvoir effectuer une recherche dabonn sur le nom ou le prnom
(sans distinction).
Attention la distinction entre une uvre et un exemplaire. Une bibliothque possde
gnralement plusieurs exemplaires dune mme uvre, et ce sont toujours des exemplaires
qui sont emprunts.
Remarque : Nous reviendrons rgulirement lors des travaux dirigs sur cette thmatique de
la bibliothque.
1.5.2 Analyse des besoins

1. Quel est, en quelques mots, lobjectif du systme ?
2. Quels sont les utilisateurs du systme ?
3. Quels sont les contextes dutilisation ? En dautres termes, quelles occasions y a-t-il
interaction entre le systme et ses utilisateurs ?
4. Pourquoi doit-on distinguer les uvres et les exemplaires ?
Quelles sont les implications de cette distinction sur la conception du logiciel ?
1.5.3 Conception avec une approche structure (i.e. fonctionnelle)

5. Dcomposez le systme en terme de fonctions et de sous-fonctions jusqu arriver des
fonctionnalits si simples quil ny a plus lieu de les dcomposer. Dessinez une structure
arborescente montrant la dcomposition du systme.

6. Rflchissez et donnez une solution quant la reprsentation des donnes.

7. Donnez des dtails sur la manire de remplir la fonctionnalit correspondant la recherche
dune uvre sur le titre.
1.5.4 Conception avec une approche objet

8. Identifiez les objets du systme. Regroupez les en classe. Pour chaque classe, prcisez les
attributs et mthodes qui la caractrise.
9. tablissez un schma synthtique montrant les classes du systme.
Le cas chant, matrialisez les relations dhritage par une flche pointant vers la classe
la plus gnrale.
Reliez par un trait les classes dont les objets (i.e. instances) doivent collaborer.
10. Donnez des dtails sur la manire de remplir la fonctionnalit correspondant la recherche
dune uvre sur le titre.
1.5.5 Maintenance volutive

La bibliothque souhaite maintenant voluer en mdiathque : elle veut acqurir des albums
musicaux sous forme de compact disques, caractriss par un titre et un interprte, et pouvant
tre emprunts trois jours, ainsi que des DVD de films caractriss par un titre et un ralisateur,
et pouvant tre emprunts seulement deux jours.
11. Identifiez les impacts dune telle volution sur le systme obtenu grce lapproche
structure.
12. Identifiez les impacts dune telle volution sur le systme obtenu grce lapproche objet.

Chapitre 2
Diagramme de cas dutilisation

(Use Case Diagram)
2.1 Introduction
Bien souvent, la matrise douvrage et les utilisateurs ne sont pas des informaticiens. Il leur
faut donc un moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes
de cas dutilisation qui permettent de recueillir, danalyser et dorganiser les besoins, et de
recenser les grandes fonctionnalits dun systme. Il sagit donc de la premire tape UML
danalyse dun systme.
Un diagramme de cas dutilisation capture le comportement dun systme, dun sous-
systme, dune classe ou dun composant tel quun utilisateur extrieur le voit. Il scinde la
fonctionnalit du systme en units cohrentes, les cas dutilisation, ayant un sens pour les
acteurs. Les cas dutilisation permettent dexprimer le besoin des utilisateurs dun systme, ils
sont donc une vision oriente utilisateur de ce besoin au contraire dune vision informatique.
Il ne faut pas ngliger cette premire tape pour produire un logiciel conforme aux attentes
des utilisateurs. Pour laborer les cas dutilisation, il faut se fonder sur des entretiens avec les
utilisateurs.
2.2 lments des diagrammes de cas dutilisation

2.2.1 Acteur
Un acteur est lidalisation dun 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.
Il est galement possible de reprsenter un acteur sous la forme dun classeur (cf. section
2.4.3) strotyp (cf. section 2.4.4) actor (figure 2.2).
2.2.2 Cas dutilisation

Un cas dutilisation est une unit cohrente reprsentant une fonctionnalit visible de lex-
trieur. Il ralise un service de bout en bout, avec un dclenchement, un droulement et une fin,
29
CHAPITRE 2. DIAGRAMME DE CAS DUTILISATION
F. 2.1 Exemple de reprsentation dun acteur
F. 2.2 Exemple de reprsentation dun acteur sous la forme dun classeur
pour lacteur qui linitie. Un cas dutilisation modlise donc un service rendu par le systme,
sans imposer le mode de ralisation de ce service.
Un cas dutilisation se reprsente par une ellipse (figure 2.3) contenant le nom du cas (un
verbe linfinitif), et optionnellement, au-dessus du nom, un strotype (cf. section 2.4.4).
F. 2.3 Exemple de reprsentation dun cas dutilisation
Dans le cas o lon dsire prsenter les attributs ou les oprations du cas dutilisation, il est
prfrable de le reprsenter sous la forme dun classeur strotyp use case (figure 2.4). Nous
reviendrons sur les notions dattributs ou dopration lorsque nous aborderons les diagrammes
de classes et dobjets (section 3).
F. 2.4 Exemple de reprsentation dun cas dutilisation sous la forme dun classeur
2.2.3 Reprsentation dun diagramme de cas dutilisation

Comme le montre la figure 2.5, la frontire du systme est reprsente par un cadre. Le
nom du systme figure lintrieur du cadre, en haut. Les acteurs sont lextrieur et les cas
dutilisation lintrieur.

2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION
F. 2.5 Exemple simplifi de diagramme de cas dutilisation modlisant une borne daccs
une banque.
2.3 Relations dans les diagrammes de cas dutilisation
2.3.1 Relations entre acteurs et cas dutilisation
Relation dassociation
F. 2.6 Diagramme de cas dutilisation reprsentant un logiciel de partage de fichiers
Une relation dassociation est chemin de communication entre un acteur et un cas dutilisa-
tion et est reprsent un trait continu (cf. figure 2.5 ou 2.6).
Multiplicit
Lorsquun acteur peut interagir plusieur fois avec un cas dutilisation, il est possible dajouter
une multiplicit sur lassociation du ct du cas dutilisation. Le symbole * signifie plusieurs
(figure 2.6), exactement n scrit tout simplement n, n..m signifie entre n et m, etc. Prciser une
multiplicit sur une relation nimplique pas ncessairement que les cas sont utiliss en mme
temps.
La notion de multiplicit nest pas propre au diagramme de cas dutilisation. Nous en
reparlerons dans le chapitre consacr au diagramme de classes section 3.3.4.

Acteurs principaux et secondaires

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

Quand un cas nest pas directement reli un acteur, il est qualifi de cas dutilisation interne.
2.3.2 Relations entre cas dutilisation
F. 2.7 Exemple de diagramme de cas dutilisation
Types et reprsentations
Il existe principalement deux types de relations :

2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION
les dpendances strotypes, qui sont explicites par un strotype (les plus utiliss sont
linclusion et lextension),
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 pleins dont la pointe est
un triangle ferm dsignant le cas le plus gnral (figure 2.7).
Relation dinclusion
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 lest obligatoirement, comme une partie de A.
Cette dpendance est symbolise par le strotype include (figure 2.7). Par exemple, laccs
aux informations dun compte bancaire inclut ncessairement une phase dauthentification avec
un identifiant et un mot de passe (figure 2.7).
Les inclusions permettent essentiellement de factoriser une partie de la description dun cas
dutilisation qui serait commune dautres cas dutilisation (cf. le cas Sauthentifier 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 dun cas dutilisation en plusieurs sous-cas
dutilisation pour ne pas retomber dans le travers de la dcomposition fonctionnelle.
Attention galement au fait que, les cas dutilisation ne senchanent pas, puisquil ny a
aucune reprsentation temporelle dans un diagramme de cas dutilisation.
F. 2.8 Relations entre cas pour dcomposer un cas complexe
Relation dextension
La relation dextension 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 dinformaticiens.
On dit quun cas dutilisation A tend un cas dutilisation B lorsque le cas dutilisation A
peut tre appel au cours de lexcution du cas dutilisation B. Excuter B peut ventuelle-
ment entraner lexcution de A : contrairement linclusion, lextension est optionnelle. Cette
dpendance est symbolise par le strotype extend (figure 2.7).

Lextension peut intervenir un point prcis du cas tendu. Ce point sappelle le point
dextension. Il porte un nom, qui figure dans un compartiment du cas tendu sous la rubrique
point dextension, et est ventuellement associ une contrainte indiquant le moment o lexten-
sion intervient. Une extension est souvent soumise condition. Graphiquement, la condition
est exprime sous la forme dune note. La figure 2.7 prsente lexemple dune banque o la
vrification du solde du compte nintervient que si la demande de retrait dpasse 20 euros.
Relation de gnralisation
Un cas A est une gnralisation dun cas B si B est un cas particulier de A. Dans la figure 2.7,
la consultation dun 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 dhritage dans les langages orients objet.
2.3.3 Relations entre acteurs

La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une
gnralisation dun acteur B si lacteur A peut tre substitu par lacteur B. Dans ce cas, tous les
cas dutilisation accessibles A le sont aussi B, mais linverse nest 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 lacteur le plus gnral (comme nous lavons dj vu
pour la relation de gnralisation entre cas dutilisation).
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.
F. 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 dutilisation mais sont gnraux. Nous avons dj utilis certains de ces lments dans

2.4. NOTIONS GNRALES DU LANGAGE UML
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
F. 2.10 Reprsentations dun paquetage
Un paquetage est un regroupement dlments de modle et de diagrammes. Il permet ainsi

dorganiser des lments de modlisation en groupes. Il peut contenir tout type dlment de
modle : des classes, des cas dutilisation, 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 dun paquetage.
Dans ce cas, le nom du paquetage est plac dans longlet (figure 2.10, diagramme de droite).
Les lments contenus dans un paquetage doivent reprsenter un ensemble fortement co-
hrent et sont gnralement de mme nature et de mme niveau smantique. Tout lment
nappartient qu un seul paquetage. Les paquetage constituent un mcanisme de gestion im-
portant des problmes de grande taille. Ils permettent dviter les grands modles plats et
de cloisonner des lments constitutifs dun 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 dun 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 llment 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 dinstance. Dune manire
gnrale, les lments de modlisation pouvant en avoir sont reprsents dans des classeurs1 .
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 dune identit
(i.e. un nom), dune structure ou dun tat (i.e. des attributs), dun comportement (i.e. des
1
Certains lments, comme les associations, peuvent avoir des instances bien quils ne soient pas reprsents
dans des classeurs.

oprations), de relations et dune structure interne facultative. Il peut participer des relations
dassociation, 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 dutilisation sont des classeurs. Tout au long de ce cours, nous retrou-
verons le terme de classeur car cette notion englobe aussi les classes, les interfaces, les signaux,
les nuds, les composants, les sous-systmes, 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 sappliquant sur un lment de modle. Il na pas de
dfinition formelle, mais permet de mieux caractriser des varits dun mme concept. Il permet
donc dadapter le langage des situations particulires. Il est reprsent par une chanes de
caractres entre guillemets ( ) dans, ou proximit du symbole de llment de modle de
base.
Par exemple, la figure 2.4 reprsente un cas dutilisation par un rectangle. UML utilise
aussi les rectangles pour reprsenter les classes (cf. section 3). La notation nest cependant pas
ambigu grce la prsence du strotype use case .
2.4.5 Note
F. 2.11 Exemple dutilisation dune note pour prciser que le solde dun 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 langle suprieur
droit est pli. Le texte contenu dans le rectangle nest pas contraint par UML. Une note nindique
pas explicitement le type dlment quelle contient, toute lintelligibilit dune note doit tre
contenu dans le texte mme. On peut relier une note llment quelle dcrit grce une ligne
en pointills. Si elle dcrit plusieurs lments, on dessine une ligne vers chacun dentre eux.
Lexemple 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 nemploie pas le terme dutilisateur mais dacteur. Les acteurs dun systme sont les
entits externes ce systme qui interagissent (saisie de donnes, rception dinformation, . . .)

2.5. MODLISATION DES BESOINS AVEC UML
avec lui. Les acteurs sont donc lextrieur du systme et dialoguent avec lui. Ces acteurs
permettent de cerner linterface que le systme va devoir offrir son environnement. Oublier
des acteurs ou en identifier de faux conduit donc ncessairement se tromper sur linterface 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) dun systme. Dune part parce que
les acteurs inclus les utilisateurs humains mais aussi les autres systmes informatiques ou
hardware qui vont communiquer avec le systme. Dautre part parce que un acteur englobe
tout une classe dutilisateur. 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 sont rle car un acteur reprsente un
ensemble cohrent de rles jous vis--vis du systme.
Pour trouver les acteurs dun systme, il faut identifier quels sont les diffrents rles que vont
devoir jouer ses utilisateurs (ex : responsable clientle, responsable dagence, administrateur,
approbateur, . . .). Il faut galement sintresser aux autres systmes avec lesquels le systme va
devoir communiquer comme :
les priphriques manipuls par le systme (imprimantes, hardware dun distributeur de
billet, . . .) ;
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 lextrieur et qui interagit avec le systme est un acteur, tout ce qui est lintrieur est une
fonctionnalit raliser.
Vrifiez que les acteurs communiquent bien directement avec le systme par mission ou
rception de messages. Une erreur frquente consiste rpertorier en tant quacteur des entits
externes qui ninteragissent pas directement avec le systme, mais uniquement par le biais dun
des vritables acteurs. Par exemple, lhtesse de caisse dun magasin de grande distribution est
un acteur pour la caisse enregistreuse, par contre, les clients du magasins ne correspondent pas
un acteur car ils ninteragissent pas directement avec la caisse.
2.5.2 Comment recenser les cas dutilisation ?

Lensemble des cas dutilisation doit dcrire exhaustivement les exigences fonctionnelles du
systme. Chaque cas dutilisation correspond donc une fonction mtier du systme, selon le
point de vue dun de ses acteurs. Aussi, pour identifier les cas dutilisation, 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
dabstraction. Trouver le bon niveau de dtail pour les cas dutilisation est un problme difficile
qui ncessite de lexprience.
Nommez les cas dutilisation avec un verbe linfinitif suivi dun complment en vous
plaant du point de vue de lacteur et non pas de celui du systme. Par exemple, un distributeur
de billets aura probablement un cas dutilisation Retirer de largent et non pas Distribuer de largent.
De par la nature fonctionnelle, et non objet, des cas dutilisation, et en raison de la diffi-
cult 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
dutilisation est en gnral le symptme de ce type derreur.

Dans tous les cas, il faut bien garder lesprit quil ny a pas de notion temporelle dans un
diagramme de cas dutilisation.
2.5.3 Description textuelle des cas dutilisation

Le diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de
vue des acteurs, mais nexpose pas de faon dtaille le dialogue entre les acteurs et les cas
dutilisation. Bien que de nombreux diagrammes dUML permettent de dcrire un cas, il est
recommand de rdiger une description textuelle car cest une forme souple qui convient dans
bien des situations.
Une description textuelle couramment utilise se compose de trois parties.
1. La premire partie permet didentifier le cas, elle doit contenir les informations qui suivent.
Nom : Utiliser une tournure linfinitif (ex : Rceptionner un colis).

Objectif : Une description rsume permettant de comprendre lintention principale du
cas dutilisation. Cette partie est souvent renseigne au dbut du projet dans la phase
de dcouverte des cas dutilisation.
Acteurs principaux : Ceux qui vont raliser le cas dutilisation (la relation avec le cas
dutilisation est illustre par le trait liant le cas dutilisation et lacteur dans un
diagramme de cas dutilisation)
Acteurs secondaires : Ceux qui ne font que recevoir des informations lissue de la
ralisation du cas dutilisation
Dates : Les dates de crations et de mise jour de la description courante.
Responsable : Le nom des responsables.
Version : Le numro de version.
2. La deuxime partie contient la description du fonctionnement du cas sous la forme dune

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
sajoutent frquemment des squences alternatives (des embranchement dans la squence
nominale) et des squences dexceptions (qui interviennent quand une erreur se produit).
Les prconditions : elles dcrivent dans quel tat doit tre le systme (lapplication)
avant que ce cas dutilisation puisse tre dclench.
Des scnarii : Ces scnarii sont dcrits sous la forme dchanges dvnements entre
lacteur et le systme. On distingue le scnario nominal, qui se droule quand il ny
a pas derreur, des scnarii alternatifs qui sont les variantes du scnario nominal et
enfin les scnarii dexception qui dcrivent les cas derreurs.
Des postconditions : Elle dcrivent ltat du systme lissue des diffrents scnarii.
3. La troisime partie de la description dun cas dutilisation est une rubrique optionnelle.
Elle contient gnralement des spcifications non fonctionnelles (spcifications tech-
niques, . . .). Elle peut ventuellement contenir une description des besoins en termes
dinterface graphique.

2.5. MODLISATION DES BESOINS AVEC UML
2.5.4 Remarques
Concernant les relations dans les cas dutilisation
Il est important de noter que lutilisation des relations nest pas primordiale dans la rdaction
des cas dutilisation et donc dans lexpression 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, au final, relativement faible.
Concernant les cas dutilisation

Unanimement reconnus comme cantonns lingnierie des besoins, les diagrammes de
cas dutilisation ne peuvent tre qualifis de modlisation proprement parler. Dailleur, 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.
Les Use case Realization

UML ne mentionne que le fait que la ralisation dun cas dutilisation est dcrit par une suite
de collaborations entre lments de modlisation mais ne parle par de llment de modlisation
use case realization. Les use case realization ne sont pas un formalisme dUML mais du RUP
(Rational Unified Process).
Aprs avoir rdig les cas dutilisation, il faut identifier des objets, des classes, des donnes
et des traitements qui vont permettre au systme de supporter ces cas dutilisation. Pour
documenter la manire dont sont mis en uvre les cas dutilisation du systme, on peut utiliser
le mcanisme des use case realization. Ils permettent de regrouper un diagramme de classes et des
diagrammes dinteraction. On retrouvera dans le diagramme de classes les classes qui mettent
en uvre le cas dutilisation associ au use case realization. On retrouvera dans les diffrents
diagrammes dinteraction une documentation des diffrents vnements changs entre les
objets afin de raliser les diffrents scnarii dcrit dans le cas dutilisation.
Au final on aura un use case realization par cas dutilisation et dans chaque use case realization
on aura autant de diagrammes dinteraction que ncessaire pour illustrer les scnarii dcrits
dans le cas dutilisation (scnario nominal, scnarii alternatifs et scnarii dexception).
Les use case realization permettent donc, dans la pratique, dapporter un lment de rponse
la question : Comment structurer mon modle UML ?


2.6. TRAVAUX DIRIGS DIAGRAMME DE CAS DUTILISATION
2.6 Travaux Dirigs Diagramme de cas dutilisation

2.6.1 Identification des acteurs et de cas dutilisation simples
Considrons une station-service de distribution dessence. Le client se sert de lessence de
la faon suivante : il prend un pistolet accroch une pompe et appuie sur la gchette pour
prendre de lessence.
1. Qui est lacteur du systme ? Est-ce le client, le pistolet ou la gchette ?
2. Proposer un petit diagramme de cas dutilisation pour modliser la situation.
3. Jojo, dont le mtier est pompiste, peut se servir de lessence pour sa voiture dans sa
station. Pour modliser cette activit de Jojo, doit-on dfinir un nouvel acteur ? Comment
modlise-t-on a ?
4. Lorsque Jojo vient avec son camion citerne pour remplir les rservoirs des pompes, est-il
considr comme un nouvel acteur ? Comment modlise-t-on cela ?
5. Certains pompistes sont aussi qualifis pour oprer des oprations de maintenance en
plus des oprations habituelles des pompistes telles que le remplissage des rservoirs. Ils
sont donc rparateurs en plus dtre pompistes. Comment modliser cela ?
2.6.2 Caisse enregistreuse

Cet exercice consiste modliser un systme simplifi de caisse enregistreuse de supermar-
ch. Il est largement inspir du livre de Roques (2006b) et initialement propos par Larman
(1997).
Mise en situation
Le droulement normal dutilisation dune caisse enregistreuse est le suivant :
Un client arrive la caisse avec des articles quil veut acheter.
Le caissier enregistre le numro didentification de chaque article, ainsi que la quantit si
celle-ci est suprieure un.
La caisse affiche le prix de chaque article et son libell pour que le client puisse surveiller
le droulement des oprations.
Lorsque tous les articles ont t enregistrs, le caissier signale la fin de la vente la caisse.
La caisse affiche le total des achats.
Le client peut prsenter des coupons de rduction avant le paiement.
Le client choisit son mode de paiement :
Liquide : le caissier encaisse largent et la caisse indique le montant ventuel rendre au
client.
Chque : le caissier note lidentit du client et sa solvabilit en transmettant une requte
un centre dautorisation via la caisse.
Carte de crdit : un terminal bancaire fait partie de la caisse, il transmet la demande un
centre dautorisation multi-banques.
La caisse enregistre la vente et imprime un ticket.
Le caissier transmet le ticket imprim au client.
La caisse transmet les informations relatives aux articles vendus au systme de gestion
des stocks.
Tous les matins, le responsable du magasin initialise les caisses pour la journe.

Questions
6. Proposez un diagramme de cas dutilisation minimaliste contenant deux cas : Traiter le

passage en caisse et Initialiser la caisse et uniquement le ou les acteurs principaux.
7. Ajouter le ou les acteurs secondaires.
8. La prolifration dacteurs secondaires sur le cas Traiter le passage en caisse indique que ce
cas comporte probablement trop de responsabilits. Proposez une dcomposition de ce
cas.
9. En utilisant un point dextension, faites figurer la prise en compte des coupons de rduc-
tion.
2.6.3 La bibliothque
Objectif
Lobjectif de la problmatique de la bibliothque consiste, au fil des diffrents travaux dirigs,

proposer un modle du systme informatique dune bibliothque. Actuellement, la bibliothque
en question nen possde pas et ne travaille quavec des notices et des fiches papier. Une
personne sest rendue pour vous la rencontre du client (la bibliothcaire) qui demande ce
systme. Leur entretien est retranscrit dans la section qui suit.
Retranscription de lentretien avec la bibliothcaire

Bonjour monsieur, je vous attendais. Jai fait appel vous pour informatiser notre biblio-
thque. En effet, nous commenons avoir un certain nombre de livres et dadhrents, et il
devient difficile pour nous de suivre les prts et difficile pour les adhrents de rechercher
des livres.
Bonjour madame. Pourriez-vous me dcrire la faon dont vous fonctionnez actuellement ?
Nous fonctionnons avec des notices papier. Une notice est affecte chaque livre et insre
contre la couverture lintrieur du livre. Quand une personne emprunte un livre, elle
donne la notice du livre un assistant qui la range dans le fichier des emprunts. Nous
avons aussi une fiche par adhrent. Il faut donc noter sur la fiche de ladhrent les livres
quil emprunte et la date de retour lorsquil les rend.
Quy-a-t-il dcrit sur une notice ?
Le titre du livre, lauteur et lditeur par exemple. Mais a dpend un peu des notices.
Quand une personne emprunte un livre, on crit aussi son nom, son prnom et la date du
prt.
Pourquoi dites-vous : a dpend un peu des notices ?
Parce quil y a plusieurs types de notice en fonction des documents. Nous avons des
romans, des bandes dessines, des livres sur la culture, comme lhistoire, lart, etc.
Pouvez-vous me montrer quelques notices ?
Oui. (Cf. figure 2.12 et 2.13)
Quels sont exactement les diffrents types de documents que vous possdez ?
Des romans, des bandes dessines, des ouvrages sur lart et lhistoire, des guides de
voyage et des revues qui ne peuvent pas tre emprunts.
Le systme doit-il aussi grer les revues ?
Oui, pour connatre notre fond, et pour permettre de faire des recherches.
Quattendez-vous du systme ?

2.6. TRAVAUX DIRIGS DIAGRAMME DE CAS DUTILISATION
Quil permette de mmoriser et de grer toutes nos notices papier. Quil permette deffec-
tuer des recherche sur notre fond. Quil permette de grer les emprunts.
Tout le monde peut-il emprunter des ouvrages ?
Oui, condition dtre abonn la bibliothque.
Donc le systme doit aussi grer les abonns ?
Euh ... oui.
Un adhrant a-t-il accs au systme ?
Oui, il doit pouvoir effectuer des recherches pour savoir si un ouvrage existe dans la
bibliothque et sil est disponible. Mme un simple visiteur doit pouvoir le faire.
Toutes les autres interactions avec le systme sont ralises uniquement par le bibliothcaire ?
Oui ... ou un assistant. Un assistant doit pouvoir grer les emprunts et les retours. Il doit
aussi pouvoir effectuer des recherches et savoir, le cas chant, qui emprunt un ouvrage
en cours de prt. Moi, je dois pouvoir, en plus, modifier le fond documentaire. Jaimerais
aussi pouvoir afficher la liste des ouvrages qui auraient d tre rendus et ne le sont pas
encore, et qui les a emprunts.
Quelle est la dure maximale dun prt ?
a dpend, un mois pour les romans et les autres livres, trois semaines pour un guide de
voyage et deux pour une bande dessine.
Combien un adhrent peut-il emprunter douvrages ?
Au maximum trois romans, deux guides de voyage et cinq bandes dessines. Mais pas
plus de cinq ouvrages en tout.
Bon, voyez-vous des choses rajouter
Oui, jaimerais bien quun assistant ou moi-mme puissions spcifier sur une notice ltat
dun ouvrage. Par exemple avec trois niveaux : bon, moyen et abm. Ceci maiderai
beaucoup pour le remplacement des exemplaires.
Remarque Utilisez vos connaissances sur le monde de ldition et sur votre frquentation des
bibliothques pour trouver les informations qui ne figurent pas dans cet entretien. Elles sont
nombreuses !
Questions
10. Identifiez et spcifiez les besoins en ralisant un diagramme de cas dutilisation.
11. Donnez une description textuelle du cas dutilisation Grer emprunt.

F. 2.12 Exemple de notice pour un roman de science-fiction et un ouvrage dart.
F. 2.13 Exemple de notice pour une bande dessine.

Chapitre 3
(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 dune telle modlisation.
Alors que le diagramme de cas dutilisation 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 ensemble pour raliser les cas dutilisation.
Il est important de noter quun mme objet peut trs bien intervenir dans la ralisation de
plusieurs cas dutilisation. Les cas dutilisation ne ralisent donc pas une partition1 des classes
du diagramme de classes. Un diagramme de classes nest donc pas adapt (sauf cas particulier)
pour dtailler, dcomposer, ou illustrer la ralisation dun cas dutilisation particulier.
Il sagit dune vue statique car on ne tient pas compte du facteur temporel dans le compor-
tement du systme. Le diagramme de classes modlise les conceps du domaine dapplication
ainsi que les concepts internes crs de toutes pices dans le cadre de limplmentation dune
application. Chaque langage de Programmation Orient Objets donne un moyen spcifique
dimplmenter 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 indpen-
damment dun 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 lutilisation.
3.2 Les classes

3.2.1 Notions de classe et dinstance de classe
Une instance est une concrtisation dun concept abstrait. Par exemple :
la Ferrari Enzo qui se trouve dans votre garage est une instance du concept abstrait
Automobile ;
lamiti qui lie Jean et Marie est une instance du concept abstrait Amiti ;
Une classe est un concept abstrait reprsentant des lments varis comme :
1
Une partition dun ensemble est un ensemble de parties non vides de cet ensemble, deux deux disjointes et
dont la runion est gale lensemble.
45
CHAPITRE 3. DIAGRAMME DE CLASSES
des lments concrets (ex : des avions),

des lments abstraits ( ex : des commandes de marchandises ou services),
des composants dune 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.
Une classe est la description formelle dun ensemble dobjets ayant une smantique et des
caractristiques communes.
Un objet est une instance dune classe. Cest une entit discrte dote dune identit, dun
tat et dun comportement que lon peut invoquer. Les objets sont des lments individuels
dun systme en cours dexcution.
Par exemple, si lon 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 dune classe

Une classe dfinit un jeu dobjets dots de caractristiques communes. Les caractristiques
dun 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 dun objet taient soit des attributs, soit des oprations. Ce
nest pas exact dans un diagramme de classe car les terminaisons dassociations sont des proprits
qui peuvent faire partie des caractristiques dun objet au mme titre que les attributs et les oprations
(cf. section 3.3.2).
tat dun objet : Ce sont les attributs et gnralement les terminaisons dassociations, tous deux
runis sous le terme de proprits structurelles, ou tout simplement proprits2 , qui dcrivent
ltat dun objet. Les attributs sont utiliss pour des valeurs de donnes pures, dpour-
vues didentit, 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 lassociation (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 instan-
cie. Linstance dune association est appele un lien.
Comportement dun objet : Les oprations dcrivent les lments individuels dun compor-
tement que lon 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) dune mthode. Limplmentation (i.e.
dfinition) dune mthode est galement appele mthode. Il y a donc une ambigut sur
le terme mthode.
2
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 dune classe (i.e. les attributs comme les
mthodes). Dans ce cas, les attributs et les terminaisons dassociation sont rassembls sous le terme de proprits
structurelles, le qualificatif structurelle prenant ici toute son importance. Dun autre ct, le mot proprit est souvent
utilis dans lacception du terme anglais property (dans la norme UML Superstructure version 2.1.1), qui, lui, ne
dsigne que les attributs et les terminaisons dassociation, cest--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 mefforce de me conformer cette deuxime solution
o proprit et proprit structurelle dsignent finalement la mme chose.

3.2. LES CLASSES
Les attributs, les terminaisons dassociation et les mthodes constituent donc les caractris-
tiques dune classe (et de ses instances).
3.2.3 Reprsentation graphique
F. 3.1 Reprsentation UML dune classe
Une classe est un classeur 3 . 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 lensemble de tches devant tre assures par la classe mais pour
lesquelles on ne dispose pas encore assez dinformations. 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
F. 3.2 Bonnes pratiques concernant la manipulation des attributs.
Nous avons dj abord cette problmatique section 1.3.4. Lencapsulation est un mca-
nisme consistant rassembler les donnes et les mthodes au sein dune structure en cachant
limplmentation de lobjet, cest--dire en empchant laccs aux donnes par un autre moyen
que les services proposs. Ces services accessibles (offerts) aux utilisateurs de lobjet dfinissent
ce que lon appel linterface de lobjet (sa vue externe). Lencapsulation permet donc de garantir
lintgrit des donnes contenues dans lobjet.
Lencapsulation permet de dfinir des niveaux de visibilit des lments dun conteneur. La
visibilit dclare la possibilit pour un lment de modlisation de rfrencer un lment qui
3
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.

se trouve dans un espace de noms diffrents de celui de llment qui tablit la rfrence. Elle
fait partie de la relation entre un lment et le conteneur qui lhberge, 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 llment indiqu.
Protected ou # : seul un lment situ dans le conteneur ou un de ses descendants peut voir
llment indiqu.
Private ou - : seul un lment situ dans le conteneur peut voir llment.
Package ou ou rien : seul un lment dclar dans le mme paquetage peut voir llment.
Par ailleur, UML 2.0 donne la possibilit dutiliser nimporte 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 caract-
ristiques (attributs, terminaisons dassociation et opration). Il permet dindiquer 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 daccder au premier paquetage peut voir les lments.
Dans la pratique, lorsque des attributs doivent tre accessibles de lextrieur, il est prfrable
que cet accs ne soit pas direct mais se fasse par lintermdiaire doprations (figure 3.2).
3.2.5 Nom dune 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 lauteur de la
modlisation, la date, etc. Pour indiquer quune classe est abstraite, il faut ajouter le mot-clef
abstract.
La syntaxe de base de la dclaration dun nom dune classe est la suivante :
[ <Nom_du_paquetage_1>::...::<Nom_du_paquetage_N> ]
<Nom_de_la_classe> [ { [abstract], [<auteur>], [<date>], ... } ]
Mta-langage des syntaxes Nous aurons rgulirement recours ce mta-langage pour

dcrire des syntaxes de dclaration. Ce mta-langage contient certains mta-caractre :
[ ] : les crochets indiquent que ce qui est lintrieur est optionnel ;
< > : les signes infrieur et suprieur indiquent que ce qui est lintrieur est plus ou moins
libre ; par exemple, la syntaxe de dclaration dune variable comme compteur : int est
<nom_variable> : <type> ;
: les cotes sont utiles quand on veut utiliser un mta-caractre comme un caractre ; par
exemple, pour dsigner un crochet ([) il faut crire [ car [ est un mta-caractre ayant
une signification spciale ;
... : permet de dsigner une suite de squence de longueur non dfinie, le contexte permettant
de comprendre de quelle suite il sagit.

3.2. LES CLASSES
3.2.6 Les attributs

Attributs de la classe
Les attributs dfinissent des informations quune 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 initialis. Le nom
de lattribut doit tre unique dans la classe. La syntaxe de la dclaration dun attribut est la
suivante :
<visibilit> [/] <nom_attribut> :

<type> [ [<multiplicit>] [{<contrainte>}] ] [ = <valeur_par_dfaut> ]
Le type de lattribut (<type>) peut tre un nom de classe, un nom dinterface ou un type de
donn prdfini. La multiplicit (<multiplicit>) dun attribut prcise le nombre de valeurs
que lattribut peut contenir. Lorsquune multiplicit suprieure 1 est prcise, il est possible
dajouter une contrainte ({<contrainte>}) pour prciser si les valeurs sont ordonnes ({ordered})
ou pas ({list}).
Attributs de classe
Par dfaut, chaque instance dune classe possde sa propre copie des attributs de la classe.
Les valeurs des attributs peuvent donc diffrer dun 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 nen
possdent pas une copie. Un attribut de classe nest donc pas une proprit dune instance mais
une proprit de la classe et laccs cet attribut ne ncessite pas lexistence dune instance.
Graphiquement, un attribut de classe est soulign.
Attributs drivs
Les attributs drivs peuvent tre calculs partir dautres 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 lajout dun / devant leur nom.
3.2.7 Les mthodes

Mthode de la classe
Dans une classe, une opration (mme nom et mme types de paramtres) doit tre unique.
Quand le nom dune opration apparat plusieurs fois avec des paramtres diffrents, on dit que
lopration est surcharge. En revanche, il est impossible que deux oprations ne se distinguent
que par leur valeur retourne.
La dclaration dune 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>}]
La syntaxe de dfinition dun paramtre (<paramtre>) est la suivante :

[<direction>] <nom_paramtre>:<type> [[<multiplicit>]] [=<valeur_par_dfaut>]
La direction peut prendre lune des valeurs suivante :

in : Paramtre dentre pass par valeur. Les modifications du paramtre ne sont pas dispo-
nibles pour lappelant. Cest le comportement par dfaut.
out : Paramtre de sortie uniquement. Il ny a pas de valeur dentre et la valeur finale est
disponible pour lappelant.
inout : Paramtre dentre/sortie. La valeur finale est disponible pour lappelant.
Le type du paramtre (<type>) peut tre un nom de classe, un nom dinterface ou un type de
donn prdfini.
Les proprits (<proprits>) correspondent des contraintes ou des informations com-
plmentaires comme les exceptions, les prconditions, les postconditions ou encore lindication
quune mthode est abstraite (mot-clef abstract), etc.
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 na pas accs aux attributs de la classe (i.e. des instances de la classe). Laccs une
mthode de classe ne ncessite pas lexistence dune instance de cette classe.
Graphiquement, une mthode de classe est souligne.
Mthodes et classes abstraites

Une mthode est dite abstraite lorsquon 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 lorsquelle dfinit au moins une mthode abstraite ou lorsquune
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 quune 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 dactivits.
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 dassociation
Une association est une relation entre deux classes (association binaire) ou plus (association
n-aire), qui dcrit les connexions structurelles entre leurs instances. Une association indique
donc quil peut y avoir des liens entre des instances des classes associes.

3.3. RELATIONS ENTRE CLASSES
Comment une association doit-elle tre modlise ? Plus prcisment, quelle diffrence
existe-t-il entre les deux diagrammes de la figure 3.3 ?
F. 3.3 Deux faons de modliser une association.
Dans la premire version, lassociation apparat clairement et constitue une entit distincte.
Dans la seconde, lassociation se manifeste par la prsence de deux attributs dans chacune
des classes en relation. Cest en fait la manire dont une association est gnralement impl-
mente 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 sil faut modliser les associations en tant que tel a longtemps fait
dbat. UML a tranch pour la premire version car elle se situe plus un niveau conceptuel (par
opposition au niveau dimplmentation) et simplifie grandement la modlisation dassociations
complexes (comme les associations plusieurs plusieurs par exemple).
Un attribut peut alors tre considr comme une association dgnre dans laquelle une
terminaison dassociation4 est dtenue par un classeur (gnralement une classe). Le classeur
dtenant cette terminaison dassociation devrait thoriquement se trouver lautre extrmit,
non modlise, de lassociation. Un attribut nest donc rien dautre quune terminaison dun
cas particulier dassociation (cf. figure 3.9 section 3.3.5).
Ainsi, les terminaisons dassociations et les attributs sont deux lments conceptuellement
trs proches que lon regroupe sous le terme de proprit.
3.3.2 Terminaison dassociation

Propritaire dune terminaison dassociation
La possession dune terminaison dassociation par le classeur situ lautre extrmit de
lassociation peut tre spcifi graphiquement par ladjonction dun petit cercle plein (point)
entre la terminaison dassociation et la classe (cf. figure 3.4). Il nest pas indispensable de pr-
ciser la possession des terminaisons dassociations. Dans ce cas, la possession est ambigu. Par
contre, si lon indique des possessions de terminaisons dassociations, toutes les terminaisons
dassociations sont non ambigu : la prsence dun point implique que la terminaison das-
sociation appartient la classe situe lautre extrmit, labsence du point implique que la
4
Une terminaison dassociations est une extrmit de lassociation. Une association binaire en possde deux, une
association n-aire en possde n.

terminaison dassociation appartient lassociation.
F. 3.4 Utilisation dun petit cercle plein pour prciser le propritaire dune terminaison
dassociation.
Par exemple, le diagramme de la figure 3.4 prcise que la terminaison dassociation sommet
(i.e. la proprit sommet) appartient la classe Polygone tandis que la terminaison dassociation
polygone (i.e. la proprit polygone) appartient lassociation Dfini par.
Une terminaison dassociation est une proprit

Une proprit est une caractristique structurelle. Dans le cas dune classe, les proprits
sont constitues par les attributs et les ventuelles terminaisons dassociation que possde
la classe. Dans le cas dune association, les proprits sont constitues par les terminaisons
dassociation que possde lassociation. Attention, une association ne possde pas forcment
toutes ses terminaisons dassociation !
Une proprit peut tre paramtre par les lments suivant (on sintresse ici essentielle-
ment aux terminaisons dassociations puisque les attributs ont t largement traits section 3.2) :
nom : Comme un attribut, une terminaison dassociation peut tre nomme. Le nom est situ
proximit de la terminaison, mais contrairement un attribut, ce nom est facultatif. Le
nom dune terminaison dassociation est appele 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 dassociation 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 dassociation peut possder une multipli-
cit. Elle est mentionne proximit de la terminaison. Il nest pas impratif de la prciser,
mais, contrairement un attribut dont la multiplicit par dfaut est 1, la multiplicit par
dfaut dune terminaison dassociation est non spcifie. Linterprtation de la multiplicit
pour une terminaison dassociation est moins vidente que pour un attributs (cf. section
3.3.4).
navigabilit : Pour un attribut, la navigabilit est implicite, navigable, et toujours depuis la
classe vers lattribut. Pour une terminaison dassociation, la navigabilit peut tre prcise
(cf. section 3.3.5).
3.3.3 Association binaire et n-aire

Association binaire
Une association binaire est matrialise par un trait plein entre les classes associes (cf.
figure 3.5). Elle peut tre orne dun nom, avec ventuellement une prcision du sens de lecture
(I ou J).
Quand les deux extrmits de lassociation pointent vers la mme classe, lassociation est
dite rflexive.

F. 3.5 Exemple dassociation binaire.
Association n-aire
F. 3.6 Exemple dassociation n-aire.
Une association n-aire lie plus de deux classes. La section 3.3.4 dtaille comment interprter
les multiplicits dune association n-aire. La ligne pointill dune classe-association (cf. section
3.3.7) peut tre relie au losange par une ligne discontinue pour reprsenter une association
n-aire dote dattributs, doprations ou dassociations.
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 lassociation, le cas chant, apparat
proximit du losange.
3.3.4 Multiplicit ou cardinalit

La multiplicit associe une terminaison dassociation, dagrgation ou de composition
dclare le nombre dobjets susceptibles doccuper la position dfinie par la terminaison dasso-
ciation. 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 dobjets de la classe cible pouvant tre associs un seul objet donn de la classe
source (la classe de lautre terminaison de lassociation).
Dans une association n-aire, la multiplicit apparaissant sur le lien de chaque classe sap-
plique sur une instance de chacune des classes, lexclusion 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 dobjets C qui peuvent apparatre dans
lassociation (dfinie section 3.3.7) avec une paire particulire dobjets A et B.
Remarque 1 : 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 quil doit exister un lien (ou plus) pour TOUTES les combinaisons possibles des
instances des classes situes aux autres extrmits de lassociation n-aire !

Remarque 2 : Il faut noter que, pour les habitus du modle entit/relation, les multiplicits
sont en UML lenvers (par rfrence Merise) pour les associations binaires et lendroit
pour les n-aires avec n > 2.
3.3.5 Navigabilit
F. 3.7 Navigabilit.
La navigabilit indique sil est possible de traverser une association. On reprsente graphi-
quement 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 nest pas
navigable : cela signifie que les instances de la classe Produit ne stockent pas de liste dobjets du
type Commande. Inversement, la terminaison du ct de la classe Produit est navigable : chaque
objet commande contient une liste de produits.
F. 3.8 Implicitement, ces trois notations ont la mme smantique.
Lorsque lon reprsente la navigabilit uniquement sur lune des extrmits dune associa-
tion, il faut remarquer que, implicitement, les trois associations reprsentes sur la figure 3.8
ont la mme signification : lassociation ne peut tre traverse que dans un sens.
F. 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 dasso-
ciation est dtenue par un classeur (gnralement une classe). Le classeur dtenant
cette terminaison dassociation devrait thoriquement se trouver lautre termi-
naison, non modlise, de lassociation. Un attribut nest donc rien dautre quune
terminaison dun cas particulier dassociation.
La figure 3.9 illustre parfaitement cette situation. 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
F. 3.10 En haut, un diagramme reprsentant lassociation entre une banque et ses clients
( gauche), et un diagramme reprsentant lassociation 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 pro-
prits. Une telle classe rassemble un ensemble dlments (dobjets). Quand une classe est
lie une autre classe par une association, il est parfois prfrable de restreindre la porte de
lassociation 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 dun objet (appel objet qualifi) reli par une association un
autre objet. Lobjet slectionn par la valeur du qualificatif est appel objet cible. Lassociation est
appele association qualifie. Un qualificatif agit toujours sur une association dont la multiplicit
est plusieurs (avant que lassociation ne soit qualifie) du ct cible.
Un objet qualifi et une valeur de qualificatif gnrent un objet cible li unique. En consid-
rant 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. Cest--
dire quune instance de la classe Personne peut tre associe plusieurs (zro compris)
instances du couple {Banque , compte}.
Bien entendu, et dans tous les cas, un 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 {Echiquier, range, colonne} est en association avec une instance
unique de la classe Case.
Inversement, une instance de la classe Case est en association avec une instance unique
du triplet {Echiquier, range, colonne}.
3.3.7 Classe-association
Dfinition et reprsentation
F. 3.11 Exemple de classe-association.
Parfois, une association doit possder des proprits. Par exemple, lassociation Emploie entre
une socit et une personne possde comme proprits le salaire et la date dembauche. En effet,
ces deux proprits nappartiennent ni la socit, qui peut employer plusieurs personnes,
ni aux personnes, qui peuvent avoir plusieurs emplois. Il sagit donc bien de proprits de
lassociation 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 lassociation
quelle reprsente (figure 3.11).
Classe-association pour plusieurs associations
Il nest pas possible de rattacher une classe-association plus dune association puisque la
classe-association constitue elle-mme lassociation. Dans le cas o plusieurs classe-associations
doivent disposer des mmes caractristiques, elles doivent hriter dune mme classe possdant
ces caractristiques, ou lutiliser en tant quattribut.
De mme, il nest pas possible de rattacher une instance de la classe dune classe-association
plusieurs instances de lassociation de la classe-association. En effet, la reprsentation graphique

(association relie par une ligne pointill une classe dporte) est trompeuse : une classe-
associaiton est une entit smantique atomique et non composite qui sintancie donc en bloc.
Ce problme et nouveau abord et illustr section 3.5.2.
Auto-association sur classe-association
F. 3.12 Exemple dauto-association sur classe-association.
Imaginons que nous voulions ajouter une association Suprieur de dans le diagramme 3.11
pour prciser quune personne est le suprieur dune autre personne. On ne peut simplement
ajouter une association rflexive sur la classe Personne. En effet, une personne nest pas le
suprieur dune autre dans labsolu. Une personne est, en tant quemploy dune entreprise
donn, le suprieur dune autre personne dans le cadre de son emploi pour une entreprise donn
(gnralement, mais pas ncessairement, la mme). Il sagit donc dune association rflexive,
non pas sur la classe Personne mais sur la classe-association Emploie (cf. figure 3.12).
Liens multiples
F. 3.13 Exemple de classe-association avec liens multiples.
Plusieurs instances dune mme association ne peuvent lier les mmes objets. Cependant,
si lon sintresse lexemple de la figure 3.13, on voit bien quil 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 dune mme socit.

Cest justement la raison de la contrainte {bag} qui, place sur les terminaisons dassociation
de la classe-association Actions, indique quil peut y avoir des liens multiples impliquant les
mmes paires dobjets.
quivalences
Parfois, linformation vhicule par une classe-association peut tre vhicule sans perte
dune autre manire (cf. figure 3.14 et 3.15).
F. 3.14 Deux modlisations modlisant la mme information.
F. 3.15 Deux modlisations modlisant la mme information.
Classe-association, association n-aire ou association qualifie ?
Il nest souvent pas simple trancher entre lutilisation dune classe-association, dune asso-
ciation n-aire ou encore dune association qualifie. Lorsque lon utilise lun de ces trois types
dassociation, il peut tre utile ou instructif de se demander si lun des deux autres types ne
serait pas plus pertinent. Dans tous les cas, il faut garder lesprit quune classe-association est
dabord et avant tout une association et que, dans une classe-association, la classe est indisso-
ciable de lassociation.
F. 3.16 Pour couvrir le cas des comptes joints, il faut utiliser le modle de droite.

Ainsi, le cas dun 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 3.16). Ce problme et nouveau abord et illustr section 3.5.2.
F. 3.17 Si un cours doit pouvoir exister indpendamment dun 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 sil existe un
lien entre un objet Enseignant et un objet Groupe. Quand le lien est rompu (effac), le cours lest
galement. Si un cours doit pouvoir exister indpendamment de lexistence dun lien (on a
pas encore trouv denseignant pour ce cours, le cours nest pas enseign cette anne mais le
sera probablement lanne prochaine, . . .) il faut opter pour une association ternaire (modle
de droite dans figure 3.17).
F. 3.18 Si un mme cours doit concerner plusieurs couples Enseignant/Etudiant, 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 lon remplace Groupe par Etudiant (cf. modle gauche
sur la figure 3.18). En effet, le cas gnral dcrit par ce modle ne correspond pas du tout au
diagramme dobjet (cf. section 3.5) situ au centre. Nous reviendrons sur ce problme dans
la section 3.5.2 avec lillustration 3.24. Dans cette situation, il faut opter pour une association
ternaire comme sur le modle de droite.
3.3.8 Agrgation et composition

Agrgation
Une association simple entre deux classes reprsente une relation structurelle entre pairs,
cest dire entre deux classes de mme niveau conceptuel : aucune des deux nest plus im-
portante que lautre. Lorsque lon souhaite modliser une relation tout/partie o une classe

F. 3.19 Exemple de relation dagrgation et de composition.
constitue un lment plus grand (tout) compos dlments plus petit (partie), il faut utiliser une
agrgation.
Une agrgation est une association qui reprsente une relation dinclusion structurelle ou
comportementale dun lment dans un ensemble. Graphiquement, on ajoute un losange vide
() du ct de lagrgat (cf. figure 3.19). Contrairement une association simple, lagrgation
est transitive.
La signification de cette forme simple dagrgation est uniquement conceptuelle. Elle ne
contraint pas la navigabilit ou les multiplicits de lassociation. Elle nentrane pas non plus
de contrainte sur la dure de vie des parties par rapport au tout.
Composition
La composition, galement appele agrgation composite, dcrit une contenance structu-
relle entre instances. Ainsi, la destruction de lobjet composite implique la destruction de ses
composants. Une instance de la partie appartient toujours au plus une instance de llment
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 lagrgat (cf. figure 3.19).
Remarque
Les notions dagrgation et surtout de composition posent de nombreux problmes en
modlisation et sont souvent le sujet de querelles dexperts et sources de confusions. Ce que
dit la norme UML Superstructure version 2.1.1 reflte dailleur 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

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 gn-
ralisation se traduit par le concept dhritage. On parle galement de relation dhritage. Ainsi,
lhritage permet la classification des objets (cf. figure 3.20).
Le symbole utilis pour la relation dhritage 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 lhritage sont :
La classe enfant possde toutes les caractristiques des ses classes parents, mais elle ne
peut accder aux caractristiques prives de cette dernire.

F. 3.20 Partie du rgne animal dcrit avec lhritage multiple.
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 sappliquent aux classes drives.
Une instance dune 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 dune classe Animal doit accepter un objet de la classe Chat.
Une classe peut avoir plusieurs parents, on parle alors dhritage 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 dhritage nest pas propre aux classes. Elle sapplique dautre lments
du langage comme les paquetages, les acteurs (cf. section 2.3.3) ou les cas dutilisation (cf. section
2.3.2).
3.3.10 Dpendance
F. 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 dune 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 paramtre sont du type Stratgie. Si la classe Stratgie, notamment son inter-
face, change, alors des modifications devront galement tre apportes la classe Confrontation.
3.4 Interfaces
F. 3.22 Exemple de diagramme mettant en uvre une interface
Nous avons dj abord la notion dinterface 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 dinterface. Il peut sagir
de linterface complte dun objet, ou simplement dune partie dinterface qui sera commune
plusieurs objets.
Le rle de ce classeur, strotyp interface , est de regrouper un ensemble de proprits
et doprations assurant un service cohrent. Lobjectif est de diminuer le couplage entre deux
classeurs. La notion dinterface en UML est trs proche de la notion dinterface en Java.
Une interface est reprsente comme une classe except labsence du mot-clef abstract (car
linterface et toutes ses mthodes sont, par dfinition, abstraites) et lajout du strotype in-
terface (cf. figure 3.22).
Une interface doit tre ralise par au moins une classe et peut ltre par plusieurs. Graphi-
quement, 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 linterface) peut dpendre dune interface (interface requise). On reprsente cela par
une relation de dpendance et le strotype use . Attention aux problmes de conflits si une
classe dpend dune interface ralise par plusieurs autres classes.
La notion dinterface 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 dinterface), la notion
dinterface est gnralement implmente par une classe abstraite.
3.5 Diagramme dobjets (object diagram)

3.5.1 Prsentation
Un diagramme dobjets reprsente des objets (i.e. instances de classes) et leurs liens (i.e.
instances de relations) pour donner une vue fige de ltat dun systme un instant donn. Un

3.5. DIAGRAMME DOBJETS
diagramme dobjets 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) dun systme un moment donn.
Le diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits.
Par exemple, le diagramme de classes de la figure 3.23 montre quune entreprise emploie
au moins deux personnes et quune personne travaille dans au plus deux entreprises. Le dia-
gramme dobjets modlise lui une entreprise particulire (PERTNE) qui emploie trois personnes.
Un diagramme dobjets ne montre pas lvolution du systme dans le temps. Pour repr-
senter une interaction, il faut utiliser un diagramme de communication (cf. section 7.2) ou de
squence (cf. section 7.3).
3.5.2 Reprsentation
F. 3.23 Exemple de diagramme de classes et de diagramme dobjets associ.
Graphiquement, un objet se reprsente comme une classe. Cependant, le compartiment des

oprations nest pas utile. De plus, le nom de la classe dont lobjet est une instance est prcd
dun : et est soulign. Pour diffrencier les objets dune mme classe, leur identifiant peut
tre ajout devant le nom de la classe. Enfin les attributs reoivent des valeurs. Quand certaines
valeurs dattribut dun objet ne sont pas renseignes, on dit que lobjet est partiellement dfini.
Dans un diagrammes dobjets, les relations du diagramme de classes deviennent des liens.
La relation de gnralisation ne possde pas dinstance, elle nest donc jamais reprsente dans
un diagramme dobjets. Graphiquement, un lien se reprsente comme une relation, mais, sil y
a un nom, il est soulign. Naturellement, on ne reprsente pas les multiplicits.
La norme UML 2.1.1 prcise quune instance de classe-association ne peut tre associe
qu une instance de chacunes des classes associes5 ce qui interdit dinstancier le diagramme
de classe gauche dans la figure 3.24 par le diagramme dobjet droite dans cette mme
figure. Cependant, un diagramme dobjet peut tre utilis pour exprimer une exception. Sur la
figure 3.24, le diagramme dobjets droite peut tre lgitime sil vient prciser une situation
5
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

F. 3.24 Le diagramme dobjets de droite, illustrant le cas de figure dun compte joint, nest
pas une instance normale du diagramme de classe de gauche mais peut prciser une situation
exceptionnelle.
exceptionnelle non prise en compte par le diagramme de classe reprsent gauche. Nanmoins,
le cas des comptes joints ntant pas si exceptionnel, mieux vaut revoir la modlisation comme
prconis par la figure 3.16.
3.5.3 Relation de dpendance dinstanciation
F. 3.25 Dpendance dinstanciation entre les classeurs et leurs instances.
La relation de dpendance dinstanciation (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 dun diagramme de classes
3.6.1 laboration dun 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 collabo-
ration 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.

3.6. LABORATION ET IMPLMENTATION DUN DIAGRAMME DE CLASSES
Trouver les attributs des classes. Les attributs correspondent souvent des substantifs, ou des
groupes nominaux, tels que la masse dune voiture ou le montant dune transaction .
Les adjectifs et les valeurs correspondent souvent des valeurs dattributs. Vous pouvez
ajouter des attributs toutes les tapes du cycle de vie dun projet (implmentation
comprise). Nesprez pas trouver tous les attributs ds la construction du diagramme de
classes.
Organiser et simplifier le modle en liminant les classes redondantes et en utilisant lhri-
tage.
Itrer et raffiner le modle. Un modle est rarement correct ds sa premire construction. La
modlisation objet est un processus non pas linaire mais itratif.
3.6.2 Implmentation en Java

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 lobjet nest 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();
...
}
}
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() {
...
}
}
Classe abstraite
public abstract class A {
...
}

Interface
public interface A {
...
}
Hritage simple
public class A {
...
}
public class B extends A {

...
}
Ralisation dune interface par une classe
public interface Ia {
...
}
public class A implements Ia {

...
}
Association bidirectionnelle 1 vers 1
public class A {
private B rb;
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); }
}
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 lexistence de la classe A
}
Association bidirectionnelle 1 vers N
public class A {
private ArrayList rb;
public A() { rb = new ArrayList(); }
public ArrayList 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);
}
}

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);
}
}
}
}
Association unidirectionnelle 1 vers plusieurs

public class A {
private ArrayList rb;
public A() { rb = new ArrayList(); }
public void addB(B b){
if( !rb.contains( b ) ) {
rb.add(b);
}
}
}
public class B {
... // B ne connat pas lexistence de A
}
Association 1 vers N
Dans ce cas, il faut utiliser un tableau plutt quun vec-
teur. La dimension du tableau tant donnes par la car-
dinalit de la terminaison dassociation.
Agrgations
Les agrgations simplmentent comme les associations.
Composition
Une composition peut simplmenter comme une asso-

ciation unidirectionnelle.

3.6.3 Implmentation en SQL

Introduction
Il est possible de traduire un diagramme de classe en modle relationnel. Bien entendu,

les mthodes des classes ne sont pas traduites. Aujourdhui, lors de la conception de base
de donnes, il devient de plus en plus courant dutiliser la modlisation UML plutt que le
traditionnel modle entits-associations.
Cependant, moins davoir respect une mthodologie adapte, la correspondance entre le
modle objet et le modle relationnel nest pas une tche facile. En effet, elle ne peut que rarement
tre complte puisque lexpressivit dun diagramme de classes est bien plus grande que celle
dun 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.
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);
Association 1 vers 1
Pour reprsenter une association 1 vers 1 entre deux relation, la cl primaire de lune des
relations doit figurer comme cl trangre dans lautre relation.
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);
Association 1 vers plusieurs
Pour reprsenter une association 1 vers plusieurs, on procde comme pour une association
1 vers 1, except que cest forcment la relation du ct plusieurs qui reoit comme cl trangre
la cl primaire de la relation du ct 1.


num_B integer references relation_B,
attA1 text,
attA2 integer);

attB1 text,
attB2 integer);
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.

attA1 text,
attA2 integer);

attB1 text,
attB2 integer);
create table relation_A_B (

primary key (num_A, num_B));
Classe-association plusieurs vers plusieurs
Le cas est proche de celui dune 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.


attA1 text,
attA2 integer);

attB1 text,
attB2 integer);
create table relation_C (

attC1 text,
attC2 integer,
primary key (num_A, num_B));
Hritage
Les relations correspondant aux sous-classes ont comme cl 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 dun tuple
de la relation correspondant la classe parente peuvent tre compltes par un tuple de lune
des relations correspondant une sous-classe, et, le cas chant, de quelle relation il sagit. Ainsi,
dans cette solution, un objet peut avoir ses attributs rpartis dans plusieurs relations. Il faut
donc oprer des jointures pour reconstituer un objet. Lattribut 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);

id_A references relation_C,
attA1 text,
attA2 integer,
primary key (id_A));

id_B references relation_C,
attB1 text,
attB2 integer,
primary key (id_B));
Une alternative cette reprsentation est de ne crer quune seule table par arborescence
dhritage. Cette table doit contenir tous les attributs de toutes les classes de larborescence
plus lattribut type dont nous avons parl ci-dessus. Linconvnient de cette solution est quelle
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);

3.7. TRAVAUX DIRIGS DIAGRAMME DE CLASSE
3.7 Travaux Dirigs Diagramme de classe

3.7.1 Proprits et relations simples
Un rpertoire possde un nom et des droits de lecture, dexcution et dcritures.
1. Proposez une modlisation sous forme de classe de cette notion de rpertoire.
Un fichier possde un nom et des droits de lecture, dexcution et dcritures.
2. Proposez une modlisation sous forme de classe de cette notion de fichier.
3. Faites coexister ces deux notions sur un mme diagramme en en proposant une gnrali-
sation.
Un rpertoire peut contenir des rpertoires et des fichiers.
4. Proposez une modlisation de ces relations.
Les fichiers et les rpertoires possdent une mthode pour leffacement et le renommage.
Un rpertoire possde galement une mthode permettant daccder au rpertoire parent, une
mthode permettant de lister son contenu et une mthode permettant de se rendre dans lun
de ses sous-rpertoires en prcisant son nom.
5. Compltez votre diagramme de classe en consquence.
Toutes les proprits structurelles des rpertoires et des fichiers sont prives.
6. Compltez votre diagramme de classe en prcisant les mthodes daccs ncessaires.
3.7.2 Identification des relations

Dterminez la relation approprie la modlisation des noncs qui suivent. Proposez un
diagramme de classe correspondant.
7. Une voiture possde quatre roues.
8. Une cole possde des salles de cours. Parfois, plusieurs coles peuvent se partager une
mme salle.
9. Une souris et un clavier sont des priphriques dentre.
10. Une transaction boursire est un achat ou une vente.
11. Un compte bancaire peut appartenir une personne physique ou morale (sans utiliser de
relation de gnralisation).
12. Un compte bancaire peut appartenir une personne physique ou morale (en utilisant une
relation de gnralisation).
13. Deux personnes peuvent tre maries (avec une association rflexive). Deux personnes
maries sont de sexes opposs.
14. Deux personnes peuvent tre maries (avec relation de gnralisation). Deux personnes
maries sont de sexes opposs.
15. Deux personnes peuvent tre maries ou pacses.
16. Deux personnes peuvent tre maries ou pacses. Un pacs est caractris par une date et
un lieu. Un mariage est caractris par une date, un lieu et un contrat.

17. Un cours (intitul, date, heure) est dispens par un enseignant un groupe dtudiants
dans une salle. Un enseignant peut donner plusieurs cours un mme groupe dans une
mme salle. Votre modlisation devra comporter les classes Cours, Enseignant, Groupe et
Salle.
18. Un ouvrage comporte un titre et un auteur. Un ouvrage est toujours dit par un diteur.
Un ouvrage peut tre dit plusieurs fois pas forcment par le mme diteur. Chaque
dition possde un numro ddition, un numro ISBN et une date ddition.
3.7.3 Interfaces / hritage multiple

Les tudiants sont des personnes qui peuvent sinscrire et se dsinscrire luniversit.
Luniversit propose un certain nombre de cours. Les enseignants sont des personnes qui
dispensent des cours luniversit. Comme les tudiants, les doctorants peuvent sinscrire et
se dsinscrire luniversit et comme les enseignants, ils peuvent dispenser des cours.
19. Proposez plusieurs modlisations de cette situation faisant intervenir ou non les notions
dhritage multiple et dinterfaces.
3.7.4 Classes / Objets / Implmentation
F. 3.26 Relation crivain-livre trs simplifie.
20. Proposez une implmentation en Java du diagramme de classes de la figure 3.26. Sur ce
diagramme, les mthodes daccs ne figurent pas, mais tous les attributs de ce diagramme
doivent en possder.
21. Proposez deux diagrammes dobjets conformes au diagramme de classes de la figure 3.26.
22. Proposez un exemple de code Java correspondant la situation dcrite par lun des deux
diagrammes dobjets proposs ci-dessus.
23. Proposez deux diagrammes dobjets non conformes au diagramme de classes de la figure
3.26.
F. 3.27 Relation binaire crivain-livre.

3.7. TRAVAUX DIRIGS DIAGRAMME DE CLASSE
24. Proposez une implmentation en Java du diagramme de classes de la figure 3.27. On ne

vous demande pas limplmentation des mthodes.
26. Proposez un exemple de code Java correspondant la situation dcrite par lun des deux
diagrammes dobjets proposs ci-dessus.
3.27.
F. 3.28 Relation ternaire diteur/ouvrage/dition.
3.28.
3.7.5 Systme de rservation de vols : Modle du domaine

Un modle du domaine (cf. section 9.3.1) est un diagramme de classes modlisant les entits
ou concepts prsents dans le domaine de lapplication. Il sagit donc de produire un modle
des objets du monde rel.
Les tapes suivre pour tablir ce diagramme sont :
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
lhritage.
La prsente tude de cas concerne un systme simplifi de rservation de vols. Les interviews
des experts mtier ont permis de rsumer leur connaissance du domaine de la manire suivante :
Des compagnies ariennes proposent diffrents vols.
Un vol peut tre ouvert la rservation ou ferm sur ordre de la compagnie.
Un client peut effectuer une ou plusieurs rservations sur un ou plusieurs vols pour un
ou plusieurs passagers.
Une rservation concerne forcment un seul vol et un seul passager.
Une rservation peut tre annule ou confirme.
Un vol a un aroport de dpart et un aroport darrive.
Un vol a un jour et une heure de dpart et un jour et une heure darrive
30. Proposez un diagramme de classes modlisant cet ensemble de connaissances.

31. Proposez un modle du domaine de la problmatique de la bibliothque (cf. nonc
section 2.6.3).

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. Tou-
tefois, 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
dinstruction dans un langage textuel qui peut tre naturel ou formel. En gnral, une contrainte
peut tre attache nimporte quel lment de modle ou liste dlments de modle. Une
contrainte dsigne une restriction qui doit tre applique par une implmentation correcte du
systme.
On reprsente une contrainte sous la forme dune 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 dun langage de programmation.
Si une contrainte possde un nom, on prsente celui-ci sous forme dune chane suivie dun
double point (:), le tout prcdant le texte de la contrainte.
77
CHAPITRE 4. OBJECT CONSTRAINT LANGAGE (OCL)
F. 4.1 UML permet dassocier 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 dun 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 lhtel
nont pas le droit de prendre une chambre dans ce mme htel.
F. 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 tout une liste de pays, et que cette liste est ordonne (probablement par ordre de
prfrence).

4.2. INTRT DOCL
4.1.3 Reprsentation des contraintes et contraintes prdfinies
UML permet dassocier une contrainte un, ou plusieurs, lment(s) de modle de diff-
rentes faons (cf. figure 4.1) :
en plaant directement la contrainte ct dune proprit ou dune opration dans un
classeur ;
en ajoutant une note associe llment contraindre ;
en plaant la contrainte proximit de llment contraindre, comme une extrmit
dassociation 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 sapplique sur plus de deux
lments de modle.
Nous venons de voir, au travers des exemples de la figure 4.1, quelques contraintes pr-
dfinies ({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 dun langage de contraintes objet comme OCL
4.2.1 OCL Introduction
QuesacOCL ?
Cest avec OCL (Object Constraint Language) quUML formalise lexpression des contraintes
. Il sagit donc dun langage formel dexpression de contraintes bien adapt aux diagrammes
dUML, et en particulier au diagramme de classes.
OCL existe depuis la version 1.1 dUML et est une contribution dIBM. OCL fait partie
intgrante de la norme UML depuis la version 1.3 dUML. Dans le cadre dUML 2.0, les spcifi-
cations du langage OCL figurent dans un document indpendant de la norme dUML, dcrivant
en dtail la syntaxe formelle et la faon dutiliser ce langage.
OCL peut sappliquer sur la plupart des diagrammes dUML et permet de spcifier des
contraintes sur ltat dun objet ou dun ensemble dobjets comme :
des invariants sur des classes ;
des prconditions et des postconditions lexcution doprations :
les prconditions doivent tre vrifies avant lexcution,
les postconditions doivent tre vrifies aprs lexcution ;
des gardes sur des transitions de diagrammes dtats-transitions ou des messages de
diagrammes dinteraction ;
des ensembles dobjets destinataires pour un envoi de message ;
des attributs drivs, etc.

Pourquoi OCL ?
Nous avons dit que les contraintes pouvaient tre crites en langage naturel, alors pourquoi
sembarrasser du langage OCL ? Lintrt du langage naturel est quil est simple mettre en
uvre et comprhensible par tous. Par contre (et comme toujours), il est ambigu et imprcis, il
rend difficile lexpression des contraintes complexes et ne facilite pas les rfrences dautres
lments (autres que celui sur lequel porte la contrainte) du modle.
OCL est un langage formel volontairement simple daccs. Il possde une grammaire l-
mentaire (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 lexemple

Mise en situation
Plaons-nous dans le contexte dune application bancaire. Il nous faut donc grer :
des comptes bancaires,
des clients,
et des banques.
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 dune 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.
F. 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.

4.2. INTRT DOCL
F. 4.4 Ajout dune 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.
F. 4.5 Diagramme dobjets cohrent avec le diagramme de classes de la figure 4.4.
F. 4.6 Diagramme dobjets cohrent avec le diagramme de classes de la figure 4.4, mais
reprsentant une situation inacceptable.
Cependant, dautres problmes subsistent. La figure 4.5 montre un diagramme dobjets

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 dobjets valide vis--
vis du diagramme de classes de la figure 4.4 mais ne respectant pas la spcification du problme.
En effet, ce diagramme dobjets montre une personne (P1) ayant un compte dans une banque
sans en tre client. Ce diagramme montre galement un client (P2) dune banque ny possdant
pas de compte.
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.

context Compte
inv : solde > 0
context Compte :: dbiter(somme : int)

pre : somme > 0
post : solde = solde@pre - somme
context Compte
inv : banque.clients -> includes (propri-
taire)
F. 4.7 Exemple dutilisation du langage de contrainte OCL sur lexemple bancaire.
Remarque : faites bien attention au fait quune expression OCL dcrit une contrainte res-
pecter et ne dcrit absolument pas limplmentation dune mthode.
4.3 Typologie des contraintes OCL

4.3.1 Diagramme support des exemples illustratifs
F. 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 ser-
vira de support aux diffrents exemples de contraintes que nous donnerons, titre dillustration,
dans les sections qui suivent (4.3 4.7).
Ce diagramme introduit un nouveau type de classeur, strotyp enumeration, permettant
de dfinir une numration. Une numration est un type de donn UML, possdant un nom, et

4.3. TYPOLOGIE DES CONTRAINTES OCL
F. 4.9 Dfinition dune numration en utilisant un classeur.
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.
4.3.2 Contexte (context)

Une contrainte est toujours associe un lment de modle. Cest cet lment qui constitue
le contexte de la contrainte. Il existe deux manires pour spcifier le contexte dune contrainte
OCL :
En crivant la contrainte entre accolades ({}) dans une note (comme nous lavons fait sur
la figure 4.4). Llment 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 lavons fait sur la figure 4.7).
Syntaxe
context <lment>
<lment> peut tre une classe, une opration, etc. Pour faire rfrence un lment op (comme
un opration) dun classeur C (comme une classe), ou dun paquetage, . . ., il faut utiliser les ::
comme sparateur (comme C::op).
Exemple
Le contexte est la classe Compte :

context Compte
Le contexte est lopration 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 dobjets, qui
doit tre respecte en permanence.

Syntaxe
inv : <expression_logique>
<expression_logique> est une expression logique qui doit toujours tre vraie.
Exemple
Le solde dun compte doit toujours tre positif.
context Compte
inv : solde > 0
Les femmes (au sens de lassociation) 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.
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) lappel dune opration.
Dans lexpression de la contrainte de la postcondition, deux lments particuliers sont
utilisables :
lattribut result qui dsigne la valeur retourne par lopration,
et <nom_attribut>@pre qui dsigne la valeur de lattribut <nom_attribut> avant lappel
de lopration.
Syntaxe
Prcondition :
pre : <expression_logique>
Postcondition :
post : <expression_logique>
<expression_logique> est une expression logique qui doit toujours tre vraie.
Exemple
Concernant la mthode dbiter de la classe Compte, la somme dbiter doit tre positive pour
que lappel de lopration soit valide et, aprs lexcution de lopration, lattribut solde doit
avoir pour valeur la diffrence de sa valeur avant lappel et de la somme passe en paramtre.
context Compte::dbiter(somme : Real)
pre : somme > 0
post : solde = solde@pre - somme
Le rsultat de lappel de lopration getSolde doit tre gal lattribut solde.
context Compte : :getSolde() : Real
post : result = solde

4.3. TYPOLOGIE DES CONTRAINTES OCL
Attention : mme si cela peut sembler tre le cas dans ces exemples, nous navons pas dcrit
comment lopration est ralise, mais seulement les contraintes sur ltat avant et aprs son
excution.
4.3.5 Rsultat dune mthode (body)

Ce type de contrainte permet de dfinir directement le rsultat dune opration.
Syntaxe
body : <requte>
<requte> est une expression qui retourne un rsultat dont le type doit tre compatible avec le
type du rsultat de lopration dsigne par le contexte.
Exemple
Voici une autre solution au deuxime exemple de la section 4.3.4 : le rsultat de lappel de
lopration getSolde doit tre gal lattribut solde.
context Compte : :getSolde() : Real
body : solde
4.3.6 Dfinition dattributs et de mthodes (def et let. . .in)

Parfois, une sous-expression est utilise plusieurs fois dans une expression. let permet
de dclarer et de dfinir la valeur (i.e. initialiser) dun attribut qui pourra tre utilis dans
lexpression qui suit le in.
def est un type de contrainte qui permet de dclarer et de dfinir la valeur dattributs comme
la squence let. . .in. def permet galement de dclarer et de dfinir la valeur retourne par une
opration interne la contrainte.
Syntaxe de let. . .in
let <dclaration> = <requte> in <expression>
Un nouvel attribut dclar dans <dclaration> aura la valeur retourne par lexpression
<requte> dans toute lexpression <expression>.
Reportez-vous la section 4.7 pour un exemple dutilisation.
Syntaxe de def
def : <dclaration> = <requte>
<dclaration> peut correspondre la dclaration dun attribut ou dune mthode. <requte>

est une expression qui retourne un rsultat dont le type doit tre compatible avec le type de lat-
tribut, ou de la mthode, dclar dans <dclaration>. Dans le cas o il sagit dune mthode,
<requte> peut utiliser les paramtres spcifis dans la dclaration de la mthode.

Exemple
Pour imposer quune personne majeure doit avoir de largent, 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 dun attribut ou dune termi-
naison dassociation.
Les diagrammes dUML dfinissent parfois des attributs ou des associations drives. La
valeur de tels lments est toujours dtermine en fonctions dautres lments du diagramme.
Le type de contrainte derive permet de prciser comment la valeur de ce type dlment volue.
Notez bien la diffrence entre ces deux types de contraintes. La contrainte derive impose une
contrainte perptuelle : llment driv doit toujours avoir la valeur impos par lexpression
de la contrainte derive. Dun autre ct, la contrainte init ne sapplique quau moment de la
cration dune instance prcise par le contexte de la contrainte. Ensuite, la valeur de llment
peut fluctuer indpendamment de la contrainte init.
Syntaxe
init : <requte>
derive : <requte>
Exemple
Quand on cre une personne, la valeur initiale de lattribut mari est faux et la personne ne
possde pas demployeur :
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.
Lge dune 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 lopration moins (-) entre deux dates est bien dfinie et retourne un nombre
dannes.

4.4. TYPES ET OPRATIONS UTILISABLES DANS LES EXPRESSIONS OCL
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 doprations prdfinies
sur ces types. Ces types et ces oprations sont utilisables dans nimporte 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 dinterprtation des oprateurs logiques.
Loprateur 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 sinterprte de la faon suivante : si <expression_logique_0> est vrai, alors la
valeur de vrit de lexpression est celle de <expression_logique_1>, sinon, cest celle de <expres-
sion_logique_2>.
Type Exemples de valeurs Oprateurs

Boolean true ; false and ; or ; xor ; not ; implies ; if-then-else-endif ; . . .
Integer 1 ; 5 ; 2 ; 34 ; 26524 ; . . . ; + ; ; / ; abs() ; . . .
Real 1, 5 ; 3, 14 ; . . . ; + ; ; / ; abs() ; f loor() ; . . .
String "To be or not to be . . ." concat() ; size() ; substring() ; . . .
T. 4.1 Types et oprateurs prdfinis dans les contraintes OCL.
E1 E2 P1 and P2 P1 or P2 P1 xor P2 P1 implies P2

vrai vrai vrai vrai faux vrai
vrai faux faux vrai vrai faux
faux vrai faux vrai vrai vrai
faux faux faux faux faux vrai
T. 4.2 Interprtation des quatre connecteurs, E1 et E2 sont deux expressions logiques.
expression not expression

vrai faux
faux vrai
T. 4.3 Convention dinterprtation de la ngation.
4.4.2 Types du modle UML

Toute expression OCL est crite dans le contexte dun 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 densemble sous le terme gnrique de collection (collection
en anglais). Il existe plusieurs sous-types du type abstrait Collection :
Ensemble (Set) : collection non ordonne dlments uniques (i.e. pas dlment en double).
Ensemble ordonn (OrderedSet) : collection ordonne dlments uniques.
Sac (Bag) : collection non ordonne dlments identifiables (i.e. comme un ensemble, mais
pouvant comporter des doublons).
Squence (Sequence) : collection ordonne dlments identifiables.
Jusqu UML 2.0 exclu, les collections taient toujours plates : une collection ne pouvait pas
possder des collections comme lments. Cette restriction nexiste plus partir dUML 2.0.
4.5 Accs aux caractristiques et aux objets dans les contraintes OCL
Dans une contrainte OCL associe un objet, il est possible daccder aux caractristiques
(attributs, oprations et terminaison dassociation) de cet objet, et donc, daccder de manire
transitive tous les objets (et leurs caractristiques) avec qui il est en relation.
4.5.1 Accs aux attributs et aux oprations (self )

Pour faire rfrence un attribut ou une opration de lobjet dsign par le contexte, il suffit
dutiliser le nom de cet lment. Lobjet dsign par le contexte est galement accessible par
lexpression 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
lopration.
Lorsque la multiplicit dun attribut, de type T, nest pas 1 (donc sil sagit dun 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

4.5. ACCS AUX CARACTRISTIQUES ET AUX OBJETS
self.solde
getSolde()
self.getSolde()
dbiter(1000)
self.dbiter(1000)
Dans lexemple prcdent, le rsultat de lexpression self.dbiter(1000) est un singleton du
type Real. Mais une opration peut comporter des paramtres dfinis en sortie ou en en-
tre/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 opera-
tion(out param_out : Integer) :Real possdant un paramtre dfini en sortie param_out. Dans ce
cas, le rsultat de lexpression 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
4.5.2 Navigation via une association

Pour faire rfrence un objet, ou un groupe dobjets, en association avec lobjet dsign
par le contexte, il suffit dutiliser le nom de la classe associe (en minuscule) ou le nom du rle
dassociation du cot de cette classe. Quand cest possible, il est prfrable dutiliser le nom
de rle de lassociation du ct de lobjet auquel on dsire faire rfrence. Cest indispensable
sil existe plusieurs associations entre lobjet dsign par le contexte et lobjet auquel on dsire
accder, ou si lassociation emprunte est rflexive.
Le type du rsultat dpend de la proprit structurelle emprunte pour accder lobjet
rfrenc, et plus prcisment de la multiplicit du ct de lobjet rfrenc, et du type de
lobjet rfrenc proprement dit. Si on appelle X la classe de lobjet rfrenc, dans le cas dune
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 sil 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 lensemble des employs de la socit (rsultat de type Set(Personne)) ;
employ.compte dsigne lensemble des comptes de tous les employs de la socit (r-
sultat de type Bag(Compte)) ;
employ.date_de_naissance dsigne lensemble des dates de naissance des employs
de la socit (rsultat de type Bag(Date)).
4.5.3 Navigation via une association qualifie

Une association qualifie (cf. section3.3.6) utilise un ou plusieurs qualificatifs pour slec-
tionner des instances de la classe cible de lassociation. Pour emprunter une telle association, il
est possible de spcifier les valeurs, ou les instances, des qualificatifs en utilisant des crochets
([]).

F. 4.10 Diagramme illustrant une association qualifie entre une classe Banque et une classe
Personne.
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 lordre des qualificatifs du diagramme UML. Il nest pas possible de ne
prciser la valeur que de certains qualificatifs en en laissant dautres non dfinis. Par contre, il
est possible de ne prciser aucune valeur de qualificatif :
self.client.nom
Dans ce cas, le rsultat sera lensemble 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 lassociation ntait pas qualifie. Dans ce cas, faites attention la
cardinalit de la cible qui change quand lassociation nest plus qualifie (cf. section3.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 minuscule. 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 lassociation est rflexive (cest le cas de la classe association
Mariage), il faut en plus prciser par quelle extrmit il faut emprunter lassociation. Pour cela,
on prcise le nom de rle de lune des extrmits de lassociation 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 :

4.5. ACCS AUX CARACTRISTIQUES ET AUX OBJETS
context Poste
inv : self.employ.age > 21
Par dfinition mme dune classe association, naviguer depuis une classe association vers
une classe participante produit toujours comme rsultat un objet unique. Par exemple, lexpres-
sion self.employ.age de lexemple 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
lexpression oclAsType().
Supposons une classe B hritant dune 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

Lopration oclAsType, que nous venons de dcrire (section 4.5.6), est une opration prd-
finie 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
Opration oclIsTypeOf
oclIsTypeOf retourne vrai si le type de lobjet au titre duquel cette opration est invoqu est
exactement le mme que le type t pass en paramtre.
Par exemple, dans le contexte de Socit, lexpression directeur.oclIsTypeOf(Personne) est vraie
tandis que lexpression self.oclIsTypeOf(Personne) est fausse.
Opration oclIsKindOf
oclIsKindOf permet de dterminer si le type t pass en paramtre correspond exactement au

type ou un type parent du type de lobjet au titre duquel cette opration est invoqu.
Par exemple, supposons une classe B hritant dune classe A :
dans le contexte de B, lexpression self.oclIsKindOf(B) est vraie ;
toujours dans le contexte de B, lexpression self.oclIsKindOf(A) est vraie ;
mais dans le contexte de A, lexpression self.oclIsKindOf(B) est fausse.

Opration oclIsNew
Lopration oclIsNew doit tre utilise dans une postcondition. Elle est vraie quand lobjet au
titre duquel elle est invoqu est cr pendant lopration (i.e. lobjet nexistait pas au moment
des prconditions).
Opration oclInState
Cette opration est utilise dans un diagramme dtats-transitions (cf. section 5). Elle est
vraie si lobjet dcrit par le diagramme dtats-transitions est dans ltat s pass en paramtre.
Les valeurs possibles du paramtre s sont les noms des tats du diagramme dtats-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).
4.5.8 Opration sur les classes

Toutes les oprations que nous avons dcrites jusquici sappliquaient sur des instances de
classe. Cependant, OCL permet galement daccder des caractristiques de classe (celles qui
sont soulignes dans un diagramme de classes). Pour cela, on utilise le nom qualifi de la classe
suivi dun point puis du nom de la proprit ou de lopration : <nom_qualifi>.<proprit>.
Le langage OCL dispose galement dune opration prdfinie sur les classes, les interfaces
et les numrations (allInstances) qui retourne lensemble (Set) de toutes les instances du type
au titre duquel elle est invoque, au moment o lexpression est value. Par exemple, pour
dsigner lensemble 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 lavons vu dans la section prcdente (4.5), pour accder aux caractristiques
(attributs, terminaisons dassociations, oprations) dun 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 dopration, 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 daccder une caractristique (attributs, terminaisons dassociations, oprations)
dun objet ;
-> permet daccder une caractristiques dune collection.
Nous avons dit dans la section 4.5.1 que lobjet dsign par le contexte est galement
accessible par lexpression self. self nest pas uniquement utilis pour dsigner le contexte
dune contrainte dans une expression mais galement pour dsigner le contexte dune sous-
expression dans le texte (en langage naturel). Ainsi, lorsque lon utilise self pour une opration
<opration>, cest pour dsigner lobjet (comme une collection par exemple) sur lequel porte

4.6. OPRATIONS SUR LES COLLECTIONS
lopration. Cette objet peut tre le rsultat dune opration intermdiaire comme lvaluation
de lexpression <expression> prcdant lopration <opration> dans lexpression 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 (Object Management Group
(OMG), 2006) pour plus dexhaustivit.
Oprations de base sur les collections

Nous dcrivons ici quelques oprations de base sur les collections que propose le langage
OCL.
size() :Integer retourne le nombre dlments (la cardinalit) de self.
includes(objet :T) :Boolean vrai si self contient lobjet objet.
excludes(objet :T) :Boolean vrai si self ne contient pas lobjet objet.
count(objet :T) :Integer retourne le nombre doccurrences 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 vrai si self ne contient aucun lment de la collection
c.
isEmpty() vrai si self est vide.
notEmpty() vrai si self nest pas vide.
sum() :T retourne la somme des lments de self. Les lments de self doivent supporter lop-
rateur somme (+) et le type du rsultat dpend du type des lments.
product(c2 :Collection(T2)) :Set(Tuple(first :T,second :T2)) le rsultat est la collection de Tuple
correspondant au produit cartsien de self (de type Collection(T)) par c2.
Oprations de base sur les ensembles (Set)

Nous dcrivons ici quelques oprations de base sur les ensembles (type Set) que propose le
langage OCL.
union(set :Set(T)) :Set(T) retourne lunion de self et set.
union(bag :Bag(T)) :Bag(T) retourne lunion de self et bag.
=(set :Set(T)) :Boolean 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. 1
including(objet :T) :Set(T) Le rsultat contient tous les lments de self plus lobjet objet.
excluding(objet :T) :Set(T) Le rsultat contient tous les lments de self sans lobjet objet.
-(set :Set(T)) :Set(T) Le rsultat contient tous les lments de self sans ceux de set.
asOrderedSet() :OrderedSet(T) permet de convertir self du type Set(T) en OrderedSet(T).
asSequence() :Sequence(T) permet de convertir self du type Set(T) en Sequence(T).
asBag() :Bag(T) permet de convertir self du type Set(T) en Bag(T).
1
Non, il ny a pas derreur de copier/coller : rflchissez !

Remarque : les sacs (type Bag) disposent doprations analogues.
Exemples
1. Une socit a au moins un employ :
context Socit inv : self.employ->notEmpty()
2. Une socit possde exactement un directeur :
context Socit inv : self.directeur->size()=1
3. Le directeur est galement un employ :
context Socit inv : self.employ->includes(self.directeur)
4.6.3 Opration sur les lments dune collection

Syntaxe gnrale
La syntaxe dune opration portant sur les lments dune collection est la suivante :
<collection> -> <opration>( <expression> )
Dans tous les cas, lexpression <expression> est value pour chacun des lments de la collection
<collection>. Lexpression <expression> porte sur les caractristiques des lments en les citant
directement par leur nom. Le rsultat dpend de lopration <opration>.
Parfois, dans lexpression <expression>, il est prfrable de faire rfrence aux caractris-
tiques de llment 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 ditrateur et sert de rfrence llment courant dans lexpression
<expression>.
Il est galement possible, afin dtre plus explicite, de prciser le type de cet lment :
<collection> -> <opration>( <lment> : <Type> | <expression> )
La syntaxe gnrale dune opration portant sur les lments dune collection est donc la
suivante :
<collection> -> <opration>( [ <lment> [ : <Type> ] | ] <expression> )
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
lexpression logique <expression_logique>.
reject permet de gnrer une sous-collection contenant tous les lments de self except ceux
qui satisfont lexpression logique <expression_logique>.

4.6. OPRATIONS SUR LES COLLECTIONS
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. context Socit
inv : self.employ->select(age > 50)->notEmpty()
2. context Socit
inv : self.employ->select(individu | individu.age > 50)->notEmpty()
3. context Socit
inv : self.employ->select(individu : Personne | individu.age > 50)->notEmpty()
Opration forAll et exists

Ces deux oprations permettent de reprsenter le quantificateur universel () et le quanti-
ficateur 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 dcrire une expression logique vraie si lexpression <expression_logique> est
vraie pour tous les lments de self.
exists permet dcrire une expression logique vraie si lexpression <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)
Lopration forAll possde une variante tendue possdant plus dun itrateur. Dans ce cas,
chacun des itrateurs parcourra lensemble de la collection. Concrtement, une opration forAll
comportant deux itrateurs est quivalente une opration forAll nen comportant quun, mais
ralise sur le produit cartsien de self par lui-mme.
Par exemple, imposer quil nexiste pas deux instances de la classe Personne pour lesquelles
lattribut nom a la mme valeur, cest dire pour imposer que deux personnes diffrentes ont
un nom diffrent, on peut crire indiffremment :
1. context Personne
inv : Personne.allInstances()->forAll(p1, p2 | p1 <> p2 implies p1.nom <> p2.nom)
2. context Personne
inv : (Personne.allInstances().product(Personne.allInstances()))
->forAll(tuple | tuple.first <> tuple.second implies tuple.first.nom <> tuple.second.nom)
Opration collect
Cette opration permet de construire une nouvelle collection en utilisant la collection self.
La nouvelle collection construite possde le mme nombre dlments que la collection self,
mais le type de ces lments est gnralement diffrent. La syntaxe de loprateur collect est la
suivante :
collect( [ <lment> [ : <Type> ] | ] <expression> )

Pour chaque lment de la collection self, loprateur collect value lexpression <expression> sur
cet lment et ajoute le rsultat dans la collection gnre.
Par exemple, pour dfinir la collection des dates de naissance des employs dune 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, lexpression self.employ->collect(date_de_naissance)-
>size() = self.employ->size() est toujours vraie, il faut en conclure que le rsultat dune opration
collect sur une collection du type Set nest 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. @pre
2. . et ->
3. not et - (oprateur unaire)
4. * et /
5. + et -(oprateur binaire)
6. if-then-else-endif
7. <, >, <= et >=
8. = et <>
9. and, or et xor
10. implies
Les parenthses, ( et ), permettent de changer cet ordre.
4.7 Exemples de contraintes

Dans cette section, nous allons illustrer par quelques exemples lutilisation 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.
1. Dans une socit, le directeur est un employ, nest 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)
2. Une personne considre comme au chmage ne doit pas avoir des revenus suprieurs
100 .

4.7. EXEMPLES DE CONTRAINTES
F. 4.11 Reprise du diagramme de la figure 4.8.
context Personne
inv :
let revenus : Real = self.poste.salaire->sum() in
if chmeur then
revenus < 100
else
revenus >= 100
endif
3. Une personne possde au plus 2 parents (rfrencs).
context Personne
inv : parent->size()<=2
4. Si une personne possde deux parents, lun est une femme et lautre un homme.
context Personne
inv :
parent->size()=2 implies
( parent->exists(genre=Genre::homme) and
parent->exists(genre=Genre::femme) )
5. Tous les enfants dune personne ont bien cette personne comme parent et inversement.
context Personne
inv :
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))

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

context Personne::mari
derive : self.femme->notEmpty() or self.mari->notEmpty()
7. 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

Chapitre 5
Diagramme dtats-transitions
(State machine diagram)
5.1 Introduction au formalisme

5.1.1 Prsentation
Les diagrammes dtats-transitions dUML dcrivent le comportement interne dun objet
laide dun automate tats finis. Ils prsentent les squences possibles dtats et dactions
quune 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 dune instance de classeur (classe ou compo-
sant), mais parfois aussi le comportement interne dautres lments tels que les cas dutilisation,
les sous-systmes, les mthodes.
Le diagramme dtats-transitions est le seul diagramme, de la norme UML, offrir une
vision complte et non ambigu de lensemble des comportements de llment auquel il est
attach. En effet, un diagramme dinteraction noffre quune vue partielle correspondant un
scnario sans spcifier comment les diffrents scnarii interagissent entre eux.
La vision globale du systme napparat pas sur ce type de diagramme puisquils ne sint-
ressent qu un seul lment du systme indpendamment de son environnement.
Concrtement, un diagramme dtats-transitions est un graphe qui reprsente un automate
tats finis, cest--dire une machine dont le comportement des sorties ne dpend pas seulement
de ltat de ses entres, mais aussi dun historique des sollicitations passes.
5.1.2 Notion et exemple dautomate tats finis

Comme nous venons de le dire, un automate tats finis est un automate dont le compor-
tement des sorties ne dpend pas seulement de ltat de ses entres, mais aussi dun historique
des sollicitations passes. Cet historique est caractris par un tat global.
Un tat global est un jeu de valeurs dobjet, pour une classe donne, produisant la mme
rponse face aux vnements. Toutes les instances dune mme classe ayant le mme tat global
ragissent de la mme manire un vnement. Il ne faut pas confondre les notions dtat
global et dtat. La section 5.2.1 donne plus dinformation 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.
99
CHAPITRE 5. DIAGRAMME DTATS-TRANSITIONS
F. 5.1 Un diagramme dtats-transitions simple.
La figure 5.1 montre un exemple simple dautomate tats finis. Cet automate possde deux
tats (Allum et Eteint) et deux transitions correspondant au mme vnement : la pression sur
un bouton dclairrage domestique. Cet automate tats finis illustre en fait le fonctionnement
dun tlrupteur dans une maison. Lorsque lon appuie sur un bouton dclairrage, la raction
de lclairage associ dpendra de son tat courant (de son historique) : sil la lumire est
allume, elle steindra, si elle est teinte, elle sallumera.
5.1.3 Diagrammes dtats-transitions

Un diagramme dtats-transitions rassemble et organise les tats et les transitions dun
classeur donn. Bien entendu, le modle dynamique du systme comprend plusieurs dia-
grammes dtats-transitions. Il est souhaitable de construire un diagramme dtats-transitions
pour chaque classeur (qui, le plus souvent, est une classe) possdant un comportement dyna-
mique important. Un diagramme dtats-transitions ne peut tre associ qu un seul classeur.
Tous les automates tats finis des diagrammes dtats-transitions dun systme sexcutent
concurremment et peuvent donc changer dtat de faon indpendante.
5.2 tat
5.2.1 Les deux acceptions du terme tat
tat dans un diagrammes dtats-transitions
F. 5.2 Exemple dtat simple.
Comme nous lavons dj dit, un tat, que lon peut qualifier informellement dlmentaire,
se reprsente graphiquement dans un diagrammes dtats-transitions par un rectangles aux
coins arrondis (figure 5.2).
Certains tats, dits composites (cf. section 5.6), peuvent contenir (i.e. envelopper) des sous-
tats.
Le nom de ltat peut tre spcifi dans le rectangles et doit tre unique dans le diagrammes
dtats-transitions, ou dans ltat enveloppant. On peut lomettre, ce qui produit un tat ano-

5.2. TAT
nyme. Il peut y avoir un nombre quelconque dtats anonymes distincts. Un tat imbriqu peut
tre identifi par son nom qualifi (cf. section 2.4.2) si tous les tats enveloppant ont des noms.
Un tat peut tre partitionn en plusieurs compartiments spars par une ligne horizontale.
Le premier compartiment contient le nom de ltat et les autres peuvent recevoir des transitions
interne (cf. section 5.4.6), ou des sous-tats (cf. section 5.6), quand il sagit dun tat composite.
Dans le cas dun tat simple (i.e. sans transitions interne ou sous-tat), on peut omettre toute
barre de sparation (figure 5.2).
tat dun objet, ou du diagrammes dtats-transitions (i.e. tat global)
Un objet peut passer par une srie dtats pendant sa dure de vie. Un tat reprsente une
priode dans la vie dun objet pendant laquelle ce dernier attend un vnement ou accomplit
une activit. La configuration de ltat global de lobjet est le jeu des tats (lmentaires) qui
sont actifs un instant donn.
Dans le cas dun diagramme dtats-transitions simple (sans transition concurrente), il ne
peut y avoir quun seul tat actif la fois. Dans ce cas, les notions dtat actif et dtat global se
rejoignent.
Cependant, la configuration de ltat global peut contenir plusieurs tats actifs un instant
donn. On parle dtats concurrents (cf. section 5.6.5) quand plusieurs tats sont actifs en
mme temps et on dit quil y a concurrence au sein de lobjet. Le nombre dtats actifs peut
changer pendant la dure de vie dun objet du fait dembranchements ou de jointures appeles
transitions concurrentes (cf. section 5.6.5).
5.2.2 tat initial et final

tat initial
F. 5.3 Reprsentation graphique de ltat initial.
Ltat initial est un pseudo tat qui indique ltat de dpart, par dfaut, lorsque le diagramme
dtats-transitions, ou ltat enveloppant, est invoqu. Lorsquun objet est cr, il entre dans
ltat initial.
tat final
F. 5.4 Reprsentation graphique de ltat final.
Ltat final est un pseudo tat qui indique que le diagramme dtats-transitions, ou ltat
enveloppant, est termin.

5.3 vnement
5.3.1 Notion dvnement
Un vnement est quelque chose qui se produit pendant lexcution dun systme et qui
mrite dtre modlis. Les diagrammes dtats-transitions permettent justement de spcifier
les ractions dune 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 lobjet dans un nouvel tat. On peut diviser les vnements en
plusieurs types explicites et implicites : signal, appel, changement et temporel.
5.3.2 vnement de type signal (signal)
F. 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. Lobjet expditeur cre et initialise explicitement
une instance de signal et lenvoi un objet explicite ou tout un groupe dobjets. Il nattend
pas que le destinataire traite le signal pour poursuivre son droulement. La rception dun
signal est un vnement pour lobjet destinataire. Un mme objet peut tre la fois expditeur
et destinataire.
Les signaux sont dclars par la dfinition dun classeur portant le strotype signal
ne fournissant pas dopration et dont les attributs sont interprts comme des arguments (cf.
figure 5.5). La syntaxe dun signal est la suivante :
<nom_vnement> ( [ <paramettre> : <type> [; <paramettre> : <type> ... ] ] )
Les signaux supporte 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 dappel (call)

Un vnement dappel reprsente la rception de lappel dune opration par un objet.
Les paramtres de lopration sont ceux de lvnement dappel. La syntaxe dun vnement
dappel est la mme que celle dun signal. Par contre, les vnements dappel sont des mthodes
dclares au niveau du diagramme de classes.

5.4. TRANSITION
5.3.4 vnement de changement (change)

Un vnement de changement est gnr par la satisfaction (i.e. passage de faux vrai) dune
expression boolenne sur des valeurs dattributs. Il sagit dune manire dclarative dattendre
quune condition soit satisfaite. La syntaxe dun 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 lvnement 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 nest pas rvalue. Un vnement de changement est valu continuellement jusqu
ce quil devienne vrai, et cest ce moment-l que la transition se dclenche.
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 scouler ds lentre dans ltat courant.
La syntaxe dun 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 dun objet loccurrence dun vnement. Elle lie, gn-
ralement, deux tats E1 et E2 et indique quun objet dans un tat E1 peut entrer dans ltat E2
et excuter certaines activits, si un vnement dclencheur se produit et que la condition de
garde est vrifie.
La syntaxe dune 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 dexcution. Si deux transitions
sont actives en mme temps par un mme vnement, une seule se dclenche et le choix nest
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 sagit dune expression logique sur les attributs de lobjet, associ au diagramme
dtats-transitions, ainsi que sur les paramtres de lvnement dclencheur. La condition de
garde est value uniquement lorsque lvnement dclencheur se produit. Si lexpression 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 dune transition

Lorsquune transition se dclenche (on parle galement de tir dune transition), son effet
(spcifi par / <activit> dans la syntaxe) sexcute. Il sagit gnralement dune activit
qui peut tre
une opration primitive comme une instruction dassignation ;
lenvoi dun signal ;
lappel dune opration ;
une liste dactivits, etc.
La faon de spcifier lactivit raliser est laisse libre (langage naturel ou pseudo-code).
Lorsque lexcution de leffet est termine, ltat cible de la transition devient actif.
5.4.4 Transition externe
F. 5.6 Reprsentation graphique dune transition externe entre deux tats.
Une transition externe est une transition qui modifie ltat actif. Il sagit du type de transition
le plus rpandu. Elle est reprsente par une flche allant de ltat source vers ltat cible.
La figure 5.6 illustre la reprsentation graphique dune transition externe entre deux tats.
5.4.5 Transition dachvement

Une transition dpourvue dvnement dclencheur explicite se dclenche la fin de lacti-
vit contenue dans ltat source (y compris les tat imbriqus). Elle peut contenir une condition
de garde qui est value au moment o lactivit contenue dans ltat sachve, 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 successeurs puisque ces pseudo-tats ne
peuvent rester actifs.
5.4.6 Transition interne

Les rgles de dclenchement dune transition interne sont les mmes que pour une transition
externe except quune transition interne ne possde pas dtat cible et que ltat actif reste le
mme la suite de son dclenchement. La syntaxe dune transition interne reste la mme que
celle dune transition classique (cf. section 5.4.1). Par contre, les transitions internes ne sont pas

5.5. POINT DE CHOIX
F. 5.7 Reprsentation de la saisie dun mot de passe dans un tat unique en utilisant des
transitions internes.
reprsentes par des arcs mais sont spcifies dans un compartiment de leur tat associ (cf.
figure 5.7).
Les transitions internes possdent des noms dvnement prdfinis correspondant des
dclencheurs particuliers : entry, exit, do et include. Ces mots clefs rservs viennent prendre la
place du nom de lvnement dans la syntaxe dune transition interne.
entry entry permet de spcifier une activit qui saccomplit quand on entre dans ltat.
exit exit permet de spcifier une activit qui saccomplit quand on sort de ltat.
do Une activit do commence ds que lactivit entry est termine. Lorsque cette activit est
termine, une transition dachvement peut tre dclenche, aprs lexcution de lactivit
exit bien entendu. Si une transition se dclenche pendant que lactivit do est en cours,
cette dernire est interrompue et lactivit exit de ltat sexcute.
include permet dinvoquer un sous-diagramme dtats-transitions.
Les activits entry servent souvent effectuer la configuration ncessaire dans un tat.
Comme il nest pas possible de lluder, toute action interne ltat peut supposer que la confi-
guration est effectue indpendamment de la manire dont on entre dans ltat. De manire
analogue, une activit exit est une occasion de procder un nettoyage. Cela peut savrer parti-
culirement utile lorsquil existe des transitions de haut niveau qui reprsentent des conditions
derreur qui abandonnent les tats imbriqus.
Le dclenchement dune transition interne ne modifie pas ltat actif et nentrane donc pas
lactivation des activits entry et exit.
5.5 Point de choix

Il est possible de reprsenter des alternatives pour le franchissement dune transition. On
utilise pour cela des pseudo-tats particuliers : les points de jonction (reprsents par un petit
cercle plein) et les points de dcision (reprsent par un losange).
5.5.1 Point de jonction

Les points de jonction sont un artefact graphique (un pseudo-tat en loccurrence) qui permet
de partager des segments de transition, lobjectif tant daboutir 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 dactivit interne ni des transitions
sortantes dotes de dclencheurs dvnements.

F. 5.8 En haut, un diagramme sans point de jonction. En bas, son quivalent utilisant un
point de jonction.
F. 5.9 Exemple dutilisation de deux points de jonction pour reprsenter une alternative.

5.6. TATS COMPOSITES
Il ne sagit pas dun tat qui peut tre actif au cours dun laps de temps fini. Lorsquun
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 svaluer vrai ds le franchissement
du premier segment.
La figure 5.8 illustre bien lutilit des points de jonction.
La figure 5.9 illustre lutilisation de points de jonction pour reprsenter le branchement
dune clause conditionnelle.
5.5.2 Point de dcision
F. 5.10 Exemple dutilisation dun 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 nest franchissable, cest que le modle est mal form.
Il est possible dutiliser une garde particulire, note [else], sur un des segments en aval
dun point de choix. Ce segment nest franchissable que si les gardes des autres segments sont
toutes fausses. Lutilisation dune clause [else] est recommande aprs un point de dcision
car elle garantit un modle bien form.
5.6 tats composites

5.6.1 Prsentation
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 dune rgion, il est qualifi dtat orthogonal. Lors-
quun 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 quune rgion est
qualifi dtat non orthogonal.
Implicitement, tout diagramme dtats-transitions est contenu dans un tat externe qui nest
usuellement pas reprsent. Cela apporte une plus grande homognit dans la description :
tout diagramme dtats-transitions est implicitement un tat composite.
Lutilisation dtats composites permet de dvelopper une spcification par raffinements. Il
nest pas ncessaire de reprsenter les sous-tats chaque utilisation de ltat englobant. Une

F. 5.11 Exemple dtat composite modlisant lassociation dune commande un client.
F. 5.12 Notation abrge dun tat composite.
notation abrge (figure 5.12) permet dindiquer quun tat est composite et que sa dfinition
est donne sur un autre diagramme.
La figure figure 5.11 montre un exemple dtat composite et la figure 5.12 montre sa notation
abrge.
5.6.2 Transition
Les transitions peuvent avoir pour cible la frontire dun tat composite et sont quivalentes
une transition ayant pour cible ltat initial de ltat composite.
Une transition ayant pour source la frontire dun tat composite est quivalente une
transition qui sapplique tout sous-tat de ltat 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 dun tat composite ne porte pas de
dclencheur explicite (i.e. sil sagit dune transition dachvement), elle est franchissable quand
ltat final de ltat composite est atteint.
Les transitions peuvent galement toucher des tats de diffrents niveaux dimbrication en
traversant les frontires des tats composites.
La figure 5.13 illustre une configuration complexe de transition produisant une cascade
dactivits.
5.6.3 tat historique

Un tat historique, galement qualifi dtat historique plat, est un pseudo-tat qui mmorise
le dernier sous-tat actif dun tat composite. Graphiquement, il est reprsent par un cercle
contenant un H.
Une transition ayant pour cible ltat historique est quivalente une transition qui a pour
cible le dernier tat visit de ltat englobant. Un tat historique peut avoir une transition
sortante non tiquete indiquant ltat excuter si la rgion na pas encore t visite.

F. 5.13 Exemple de configuration complexe de transition. Depuis ltat tat 1, la rception

de lvnement event1 produit la squence dactivits QuitterE11, QuitterE1, action1, EntrerE2,
EntrerE21, initialiser(), EntrerE22, et place le systme dans ltat tat22.
F. 5.14 Exemple de diagramme possdant un tat historique profond permettant de re-

prendre le programme de lavage ou de schage dune voiture lendroit o il tait arriv avant
dtre interrompu.
Il est galement possible de dfinir un tat historique profond reprsent graphiquement par
un cercle contenant un H*. Cet tat historique profond permet datteindre le dernier tat visit
dans la rgion, quel que soit sont niveau dimbrication, alors que le ltat historique plat limite
laccs aux tats de son niveau dimbrication.
La figure 5.14 montre un diagramme dtats-transitions modlisant le lavage automatique
dune voiture. Les tats de lavage, schage et lustrage sont des tats composites dfinis sur trois
autres diagrammes dtats-transitions non reprsents ici. En phase de lavage ou de schage,
le client peut appuyer sur le bouton darrt durgence. Sil 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 t interrompue, cest dire au niveau du dernier sous-tat actif des tats de
lavage ou de lustrage (tat historique profond). Si ltat avait t un tat historique plat, cest
toute la squence de lavage ou de lustrage qui aurait recommence. En phase de lustrage, le
client peut aussi interrompre la machine. Mais dans ce cas, la machine sarrtera dfinitivement.

5.6.4 Interface : les points de connexion
F. 5.15 Exemple dutilisation de points de connexion.
Comme nous lavons dj dit, il est possible de masquer les sous-tats dun tat composite
et de les dfinir dans un autre diagramme. Cette pratique ncessite parfois lutilisation de
pseudo-tats appels points de connexion.
Lorsque lon utilise le comportement par dfaut de ltat composite, cest--dire entrer par
ltat initial par dfaut et considrer les traitements finis quand ltat final est atteint, aucun
problme ne se pose car on utilise des transitions ayant pour cible, ou pour source, la frontire
de ltat composite. Dans ce cas, les points de connexion sont inutiles.
Le problme se pose lorsquil est possible dentrer ou de sortir dun tat composite de
plusieurs faons. Cest, par exemple, le cas lorsquil existe des transitions traversant la frontire
de ltat composite et visant directement, ou ayant pour source, un sous-tat de ltat composite.
Dans ce cas, la solution est dutiliser des points de connexion sur la frontire de ltat composite.
Les points de connexion sont des points dentre et de sortie portant un nom, et situs sur
la frontire dun tat composite. Ils sont respectivement reprsents par un cercle vide et un
cercle barr dune croix (cf. figure 5.15). Il ne sagit que de rfrences un tat dfini dans ltat
composite . Une unique transition dachvement, dpourvue de garde, relie le pseudo-tat
source (i.e. le point de connexion) ltat rfrenc. Cette transition dachvement nest que
le prolongement de la transition qui vise le point de connexion (il peut dailleurs y en avoir
plusieurs).
Les points de connexions offrent ainsi une faon de reprsenter linterface (au sens objet)
dun tat composite en masquant limplmentation de son comportement.
On peut considrer que les pseudo-tats initiaux et finaux sont des points de connexion sans
nom.
5.6.5 Concurrence
Les diagrammes dtats-transitions permettent de dcrire efficacement les mcanismes
concurrents grce lutilisation dtats orthogonaux. Un tat orthogonal est un tat composite
comportant plus dune rgion, chaque rgion reprsentant un flot dexcution. Graphiquement,

F. 5.16 Exemple dutilisation dun tat composite orthogonal.
dans un tat orthogonal, les diffrentes rgions sont spares par un trait horizontal en pointill
allant du bord gauche au bord droit de ltat composite.
Chaque rgion peut possder un tat initial et final. Une transition qui atteint la bordure
dun tat composite orthogonal est quivalente une transition qui atteint les tats initiaux de
toutes ses rgions concurrentes.
Toutes les rgions concurrentes dun tat composite orthogonal doivent atteindre leur tat
final pour que ltat composite soit considr comme termin.
La figure 5.16 illustre lutilisation dun tat composite orthogonal pour modliser le fait que
la prparation de la boisson dun distributeur de boisson se fait en parallle au rendu de la
monaie.
F. 5.17 Exemple dutilisation 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, ltat 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 lutilisation des transitions complexes.

5.7. TRAVAUX DIRIGS DIAGRAMME DTATS-TRANSITIONS
5.7 Travaux Dirigs Diagramme dtats-transitions

5.7.1 Porte de garage motorise enroulement
Considrons une porte de garage motorise enroulement. Lutilisateur dispose dune

tlcommande comportant un bouton unique permettant dactionner cette porte. Une pression
sur le bouton a pour effet :
douvrir la porte si celle-ci est ferme ;
de la fermer si elle est ouverte ;
de demander son ouverture si elle est en cours de fermeture ;
de demander sa fermeture si elle en cours douverture.
La porte dispose en outre dun capteur de bute qui indique que la porte a atteint sa bute
haute (porte ouverte) ou basse (porte ferme). On suppose que cette porte de garage motorise
est modlise par une classe PorteDeGarage.
1. Quels sont les tats de la classe PorteDeGarage ?
2. Quels sont les vnements possibles et leur type ?
3. Donner le diagramme dtats-transitions associ la classe PorteDeGarage.
4. Afin dviter un accident lors de la mise sous tension de la porte, on veut prciser que
lorsquune instance de la classe porte est cre, elle se trouve dans ltat Ferm. Compltez
le diagramme en consquence.
5. Que se passe-t-il si la porte est en ralit installe dans sa position ouverte ou dans une
position intermdiaire ?
5.7.2 Montre digitale

Cet exercice est largement inspir dexercices proposs dans Roques (2006b) et Charroux
et al.. (2005).
F. 5.18 Cadran dune montre digitale.
Considrons une montre digitale simplifie reprsente figure 5.18. Le mode courant est
Affichage heure. Une pression sur le bouton Mode permet de passer au mode Rglage heure.

Une nouvelle pression sur le bouton Mode permet de passer au mode Chronomtre. Enfin, une
nouvelle pression sur le bouton Mode permet de revenir au mode Affichage heure.
F. 5.19 Modlisation de la montre par un diagramme de classes.
On suppose que le fonctionnement de cette montre est modlis par le diagramme de

classes de la figure 5.19. Nous allons dcomposer ltude du fonctionnement de cette montre en
plusieurs tapes, en tablissant des diagrammes dtats-transitions concernant la classe montre.
6. Proposez un diagramme dtats-transitions dcrivant les diffrents tats de la classe
Montre.
7. On suppose que le mode Affichage heure actualise laffichage de lheure toutes les secondes.
Compltez le diagramme dtats-transitions.
8. Lutilisateur dispose de deux minutes pour rgler lheure dans le mode Rglage heure.
Pass ce dlai, la montre passe automatiquement en mode Affichage heure. Compltez le
diagramme dtats-transitions.
9. Le bouton Light permet dallumer la lumire pendant deux secondes. Une pression sur ce
bouton pendant que la lumire est allume rinitialise la dure de lallumage. Le bouton
Light fonctionne quelque soit le mode dans lequel se trouve la montre. Compltez le
diagramme dtats-transitions.
10. En mode Chronomtre, le bouton Start/stop lance ou arrte le chronomtre. Le bouton Set
remet le chronomtre zro sil est arrt. Laffichage est actualis tous les centimes de
seconde. Ltat Chronomtre est un tat composite que vous devez maintenant modliser
par un diagramme dtats-transitions.
11. Il est possible de lancer le chronomtre, puis de basculer dans un autre mode, puis de
revenir au mode chronomtre. Dans ce cas, le chronomtre continue de tourner pendant
cette opration. Adaptez le diagramme dtats-transitions pour modliser cette possibilit.
12. En mode Rglage heure, le bouton Start/stop active successivement les fonctions de rglage
de lheure, des minutes ou des secondes. Lafficheur fait clignoter lheure, les minutes ou
les secondes suivant la fonction de rglage courante. Le bouton Set incrmente lheure
courante dune heure dans la fonction de rglage de lheure, dune minute dans la fonction
de rglage des minutes, ou remet les secondes zro dans la fonction de rglage des se-
condes. Lheure affiche continue de courir en mode Rglage heure. Il faut donc ractualiser
laffichage toutes les secondes. Ltat Rglage heure est un tat composite dont vous devez
maintenant modliser le comportement laide dun diagramme dtats-transitions.

5.7. TRAVAUX DIRIGS DIAGRAMME DTATS-TRANSITIONS
13. Compltez le diagramme dtats-transitions Rglage heure pour modliser le comporte-

ment suivant : dans les fonctions de rglage de lheure ou des minutes, quand on appuie
sur le bouton Set plus de deux secondes, les heures (ou les minutes) sincrmentent rapi-
dement jusquau relchement du bouton Set.


Chapitre 6
Diagramme dactivits
(Activity diagram)
6.1 Introduction au formalisme

6.1.1 Prsentation
Les diagrammes dactivits permettent de mettre laccent 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 dune mthode
ou le droulement dun cas dutilisation.
Les diagrammes dactivits sont relativement proches des diagrammes dtats-transitions
dans leur prsentation, mais leur interprtation est sensiblement diffrente. Les diagrammes
dtats-transitions sont orients vers des systmes ractifs, mais ils ne donnent pas une vision
satisfaisante dun traitement faisant intervenir plusieurs classeurs et doivent tre complts,
par exemple, par des diagrammes de squence. Au contraire, les diagrammes dactivits ne
sont pas spcifiquement rattachs un classeur particulier. On peut attacher un diagramme
dactivits nimporte quel lment de modlisation afin de visualiser, spcifier, construire ou
documenter le comportement de cet lment.
La diffrence principale entre les diagrammes dinteraction et les diagrammes dactivits
est que les premiers mettent laccent sur le flot de contrle dun objet lautre, tandis que les
seconds insistent sur le flot de contrle dune activit lautre.
6.1.2 Utilisation courante

Dans la phase de conception, les diagrammes dactivits sont particulirement adapts
la description des cas dutilisation. Plus prcisment, ils viennent illustrer et consolider la
description textuelle des cas dutilisation (cf. section 2.5.3). De plus, leur reprsentation sous
forme dorganigrammes les rend facilement intelligibles et beaucoup plus accessibles que les
diagrammes dtats-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 dun processus mtier. La modlisation du flot dobjets est souvent importante
dans ce type dutilisation des diagrammes dactivits.
Les diagrammes dactivits 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
117
CHAPITRE 6. DIAGRAMME DACTIVITS
une description si prcise des oprations quelle autorise la gnration automatique du code.
La modlisation dune opration peut toutefois tre assimil une utilisation dUML comme
langage de programmation visuelle, ce qui nest 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 in-
cidence sur ltat du systme ou en extrait une information. Les actions sont des tapes discrtes
partir desquelles se construisent les comportements. La notion daction est rapprocher de la
notion dinstruction lmentaire dun langage de programmation (comme C++ ou Java). Une
action peut tre, par exemple :
une affectation de valeur des attributs ;
un accs la valeur dune proprit structurelle (attribut ou terminaison dassociation) ;
la cration dun nouvel objet ou lien ;
un calcul arithmtique simple ;
lmission dun signal ;
la rception dun signal ;
...
Nous dcrivons ci-dessous les types dactions les plus courants prdfinis dans la notation
UML.
Action appeler (call operation) Laction call operation correspond linvocation dune opra-
tion sur un objet de manire synchrone ou asynchrone. Lorsque laction est excute, les
paramtres sont transmis lobjet cible. Si lappel est asynchrone, laction est termine et
les ventuelles valeurs de retour seront ignores. Si lappel est synchrone, lappelant est
bloqu pendant lexcution de lopration et, le cas chant, les valeurs de retour pourront
tre rceptionnes.
Action comportement (call behavior) Laction call behavior est une variante de laction call
operation car elle invoque directement une activit plutt quune opration.
Action envoyer (send) Cette action cre un message et le transmet un objet cible, o elle
peut dclencher un comportement. Il sagit dun appel asynchrone (i.e. qui ne bloque pas
lobjet appelant) bien adapt lenvoi de signaux (send signal).
Action accepter vnement (accept event) Lexcution de cette action bloque lexcution en
cours jusqu la rception du type dvnement spcifi, qui gnralement est un signal.
Cette action est utilise pour la rception de signaux asynchrones.
Action accepter appel (accept call) Il sagit dune variante de laction accept event pour les
appels synchrones.
Action rpondre (reply) Cette action permet de transmettre un message en rponse la r-
ception dune action de type accept call.
Action crer (create) Cette action permet dinstancier un objet.
Action dtruire (destroy) Cette action permet de dtruire un objet.
Action lever exception (raise exception) Cette action permet de lever explicitement une ex-
ception.

6.2. ACTIVIT ET TRANSITION
Graphiquement, les actions apparaissent dans des nuds daction, dcrits section 6.3.1.
6.2.2 Activit (activity)

Une activit dfinit un comportement dcrit par un squencement organis dunits dont
les lments simples sont les actions. Le flot dexcution est modlis par des nuds relis par
des arcs (transitions). Le flot de contrle reste dans lactivit 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 dactivits (activity group)

Un groupe dactivits est une activit regroupant des nuds et des arcs. Les nuds et les
arcs peuvent appartenir plus dun groupe. Un diagramme dactivits est lui-mme un groupe
dactivits (cf. figure 6.2).
6.2.4 Nud dactivit (activity node)
F. 6.1 Reprsentation graphique des nuds dactivit. 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 dunion, un nud initial, un nud
final et un nud final de flot.
Un nud dactivit est un type dlment abstrait permettant de reprsenter les tapes le
long du flot dune activit. Il existe trois familles de nuds dactivits :
les nuds dexcutions (executable node en anglais) ;
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 dactivit. La figure 6.2 montre com-
ment certains de ces nuds sont utiliss pour former un diagramme dactivits.
6.2.5 Transition
Le passage dune 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 lactivit source est termine et provoquent
automatiquement et immdiatement le dbut de la prochaine activit dclencher (lactivit
cible). Contrairement aux activits, les transitions sont franchies de manire atomique, en prin-
cipe sans dure perceptible.
Les transitions spcifient lenchanement des traitements et dfinissent le flot de contrle.

F. 6.2 Exemple de diagramme dactivits modlisant le fonctionnement dune borne ban-

caire.
F. 6.3 Reprsentation graphique dune transition.

6.3. NUD EXCUTABLE
6.3 Nud excutable (executable node)

Un nud excutable est un nud dactivit quon peut excuter (i.e. une activit). Il possde
un gestionnaire dexception qui peut capturer les exceptions leves par le nud, ou un de ses
nuds imbriqus.
6.3.1 Nud daction
F. 6.4 Reprsentation graphique dun nud daction.
Un nud daction est un nud dactivit excutable qui constitue lunit fondamentale de
fonctionnalit excutable dans une activit. Lexcution dune action reprsente une transfor-
mation ou un calcul quelconque dans le systme modlis. Les actions sont gnralement lies
des oprations qui sont directement invoques. Un nud daction doit avoir au moins un arc
entrant.
Graphiquement, un nud daction est reprsent par un rectangle aux coins arrondis (figure
6.4) qui contient sa description textuelle. Cette description textuelle peut aller dun simple nom
une suite dactions ralises par lactivit. UML nimpose aucune syntaxe pour cette description
textuelle, on peut donc utiliser une syntaxe proche de celle dun langage de programmation
particulier ou du pseudo-code.
F. 6.5 Reprsentation particulire des nuds daction de communication.
Certaines actions de communication ont une notation spciale (cf. figure 6.5).

6.3.2 Nud dactivit structure (structured activity node)

Un nud dactivit structure est un nud dactivit excutable qui reprsente une por-
tion structure dune activit donne qui nest partage avec aucun autre nud structur,
lexception dune imbrication ventuelle.
Les transitions dune activit structure doivent avoir leurs nuds source et cible dans le
mme nud dactivit structure. Les nuds et les arcs contenus par nud dactivit structur
ne peuvent pas tre contenus dans un autre nud dactivit structur.
Un nud structur est dnot par le strotype structured et identifi par un nom unique
dcrivant le comportement modlis dans lactivit structure.
Graphiquement, le contour dun nud dactivit structure est en pointill. Une ligne hori-
zontale en trait continu spare le compartiment contenant le strotype structured et le nom
de lactivit structure du corps de lactivit structure.
6.4 Nud de contrle (control node)
F. 6.6 Exemple de diagramme dactivit illustrant lutilisation de nuds de contrle. Ce

diagramme dcrit la prise en compte dune commande.
Un nud de contrle est un nud dactivit abstrait utilis pour coordonner les flots entre
les nuds dune activit.

6.4. NUD DE CONTRLE
Il existe plusieurs types de nuds de contrle :

nud initial (initial node en anglais) ;
nud de fin dactivit (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 dunion (join node en anglais).
La figure 6.6 illustre lutilisation de ces nuds de contrle.
6.4.1 Nud initial

Un nud initial est un nud de contrle partir duquel le flot dbute lorsque lactivit
enveloppante est invoque. Une activit peut avoir plusieurs nuds initiaux. Un nud initial
possde un arc sortant et pas darc 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.
Nud de fin dactivit

Lorsque lun des arcs dun nud de fin dactivit est activ (i.e. lorsquun flot dexcution
atteint un nud de fin dactivit), lexcution de lactivit enveloppante sachve et tout nud
ou flot actif au sein de lactivit enveloppante est abandonn. Si lactivit a t invoque par
un appel synchrone, un message (reply) contenant les valeurs sortantes est transmis en retour
lappelant.
Graphiquement, un nud de fin dactivit est reprsent par un cercle vide contenant un
petit cercle plein (cf. figure 6.6).
Nud de fin de flot

Lorsquun flot dexcution atteint un nud de fin de flot, le flot en question est termin,
mais cette fin de flot na aucune incidence sur les autres flots actifs de lactivit enveloppante.
Graphiquement, un nud de fin de flot est reprsent par un cercle vide barr dun X.
Les nuds de fin de flot sont particuliers et utiliser avec parcimonie. Dans lexemple de
la figure 6.6, le nud de fin de flot nest pas indispensable : on peut le remplacer par un nud
dunion possdant une transition vers un nud de fin dactivit.
6.4.3 Nud de dcision et de fusion

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 nest franchissable (i.e. aucune condition de garde nest vraie),

cest que le modle est mal form. Lutilisation dune 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 lun dentre eux est retenu et ce choix est non dterministe.
Graphiquement, on reprsente un nud de dcision par un losange (cf. figure 6.6).
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 nest pas utilis pour synchroniser des flots concurrents (cest le rle
du nud dunion) 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).
Remarque
Graphiquement, il est possible de fusionner un nud de fusion et un nud de dcision, et

donc davoir 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 dutiliser un nud de dcision (losange).
6.4.4 Nud de bifurcation et dunion
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 dunion
pour quilibrer la concurrence (cf. figure 6.2).
Graphiquement, on reprsente un nud de bifurcation par un trait plein (cf. figure 6.6).
Nud dunion ou de jointure (join node)
Un nud dunion, galement appel nud de jointure est un nud de contrle qui syn-
chronise des flots multiples. Un tel nud possde donc plusieurs arcs entrants et un seul arc
sortant. Lorsque tous les arcs entrants sont activs, larc sortant lest galement.
Graphiquement, on reprsente un nud de union, comme un nud de bifurcation, par un
trait plein (cf. figure 6.2).
Remarque
Graphiquement, il est possible de fusionner un nud de bifurcation et un nud dunion,

et donc davoir un trait plein possdant plusieurs arcs entrants et sortants (cf. figure 6.6).

6.5. NUD DOBJET
6.5 Nud dobjet (object node)

6.5.1 Introduction
Jusquici, nous avons montr comment modliser le comportement du flot de contrle dans
un diagramme dactivits. Or, les flots de donnes napparaissent pas et sont pourtant un
lment essentiel des traitements (arguments des oprations, valeurs de retour, . . .).
Justement, un nud dobjet permet de dfinir un flot dobjet (i.e. un flot de donnes) dans
un diagramme dactivits. Ce nud reprsente lexistence dun objet gnr par une action
dans une activit et utilis par dautres actions.
6.5.2 Pin dentre ou de sortie
F. 6.7 Reprsentation des pins dentre et de sortie sur une activit.
Pour spcifier les valeurs passes en argument une activit et les valeurs de retour, on
utilise des nuds dobjets appels pins (pin en anglais) dentre ou de sortie. Lactivit ne peut
dbuter que si lon affecte une valeur chacun de ses pins dentre. Quand lactivit se termine,
une valeur doit tre affecte chacun de ses pins de sortie.
Les valeurs sont passes par copie : une modification des valeurs dentre au cours du
traitement de laction nest visible qu lintrieur de lactivit.
Graphiquement, un pin est reprsent par un petit carr attach la bordure dune activit
(cf. figure 6.7). Il est typ et ventuellement nomm. Il peut contenir des flches indiquant sa
direction (entre ou sortie) si lactivit ne permet pas de le dterminer de manire univoque.
6.5.3 Pin de valeur (value pin)

Un pin valeur est un pin dentre qui fournit une valeur une action sans que cette valeur ne
provienne dun arc de flot dobjets. Un pin valeur est toujours associ une valeur spcifique.
Graphiquement, un pin de valeur se reprsente comme un pin dentre avec la valeur
associe crite proximit.
6.5.4 Flot dobjet

Un flot dobjets permet de passer des donnes dune activit une autre. Un arc reliant un
pin de sortie un pin dentre est, par dfinition mme des pins, un flot dobjets (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 dun flot dobjets, plus axe sur les donnes
proprement dites car elle fait intervenir un nud dobjet dtach dune activit particulire
(en bas de la figure 6.8). Graphiquement, un tel nud dobjet est reprsent par un rectangle
dans lequel est mentionn le type de lobjet (soulign). Des arcs viennent ensuite relier ce nud
dobjet des activits sources et cibles. Le nom dun tat, ou dune liste dtats, de lobjet peut

F. 6.8 Deux notations possibles pour modliser un flot de donnes.
tre prcis entre crochets aprs ou sous le type de lobjet. On peut galement prciser des
contraintes entre accolades, soit lintrieur, soit en dessous du rectangle du nud dobjet.
La figure 6.11 montre lutilisation de nuds dobjets dans un diagramme dactivits.
Un flot dobjets peut porter une tiquette strotype mentionnant deux comportements
particuliers :
transformation indique une interprtation particulire de la donne vhicule par le flot ;
selection indique lordre dans lequel les objets sont choisis dans le nud pour le quitter
(cf. figure 6.10).
6.5.5 Nud tampon central (central buffer node)
F. 6.9 Exemple dutilisation dun nud tampon central pour centraliser toutes les com-
mandes prises par diffrents procds, avant quelles soient traites.
Un nud tampon central est un nud dobjet qui accepte les entres de plusieurs nuds
dobjets ou produit des sorties vers plusieurs nuds dobjets. Les flots en provenance dun
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 dobjet dtach
(en bas de la figure 6.8) strotyp centralBuffer (cf. figure 6.9).
6.5.6 Nud de stockage des donnes (data store node)

Un nud de stockage des donnes est un nud tampon central particulier qui assure la
persistance des donnes. Lorsquune information est slectionne par un flux sortant, linfor-

6.6. PARTITIONS
F. 6.10 Dans cette modlisation, le personnel, aprs avoir t recrut par lactivit Recruter
personnel, est stock de manire persistante dans le nud de stockage Base de donne du Personnel.
Bien quils restent dans ce nud, chaque employ qui na pas encore reu daffectation (tiquette
strotype selection : personnel.affectation=null) est disponible pour tre utilis par
lactivit Affecter personnel.
mation est duplique et ne disparat pas du nud de stockage des donnes comme ce serait
le cas dans un nud tampon central. Lorsquun 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 dobjet dtach
(en bas de la figure 6.8) strotyp datastore (cf. figure 6.10).
6.6 Partitions
Les partitions, souvent appeles couloirs ou lignes deau (swimlane) du fait de leur notation,
permettent dorganiser les nuds dactivits dans un diagramme dactivits en oprant des
regroupements (cf. figure 6.11).
Les partitions nont pas de signification bien arrte, mais correspondent souvent des
units dorganisation du modle. On peut, par exemple, les utiliser pour spcifier la classe
responsable de la mise en uvre dun ensemble tche. Dans ce cas, la classe en question est
responsable de limplmentation du comportement des nuds inclus dans ladite partition.
Graphiquement, les partitions sont dlimites par des lignes continues. Il sagit gnrale-
ment de lignes verticales, comme sur la figure 6.11, mais elle peuvent tre horizontales ou
mme courbes. Dans la version 2.0 dUML, les partitions peuvent tre bidimensionnelles, elles
prennent alors la forme dun tableau. Dans le cas dun diagramme dactivits partitionn, les
nuds dactivits appartiennent forcment une et une seule partition. Les transitions peuvent,
bien entendu, traverser les frontires des partitions.
Les partitions dactivits tant des catgories arbitraires, on peut les reprsenter par dautre
moyens quand une rpartition gomtrique savre difficile raliser. On peut ainsi utiliser
des couleurs ou tout simplement tiqueter les nuds dactivit par le nom de leur partition
dappartenance.
6.7 Exceptions
Une exception est gnre quand une situation anormale entrave le droulement nominal
dune tche. Elle peut tre gnre automatiquement pour signaler une erreur dexcution
(dbordement dindice de tableau, division par zro, . . .), ou tre souleve explicitement par
une action (RaiseException) pour signaler une situation problmatique qui nest pas prise en

F. 6.11 Illustration de lutilisation de nuds dobjets et de partitions dans un diagramme

dactivits.
F. 6.12 Notation graphique du fait quune activit peut soulever une exception.

6.7. EXCEPTIONS
charge par la squence de traitement normale. Graphiquement, on peut reprsenter le fait

quune activit peut soulever une exception comme un pin de sortie orn dun petit triangle et
en prcisant le type de lexception proximit du pin de sortie (cf. figure 6.12).
F. 6.13 Les deux notations graphiques de la connexion entre une activit protge et son
gestionnaire dexception associ.
Un gestionnaire dexception est une activit possdant un pin dentre du type de lexception
quil gre et li lactivit quil protge par un arc en zigzag ou un arc classique orn dune
petite flche en zigzag. Le gestionnaire dexception doit avoir les mmes pins de sortie que le
bloc quil 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 dutiliser la relation dhritage sur
les exceptions. Un gestionnaire dexception spcifie toujours le type des exceptions quil peut
traiter, toute exception drivant de ce type est donc galement prise en charge.
F. 6.14 Exemple dutilisation dun gestionnaire dexception pour protger une activit de
lexception Division_par_zero dclenche en cas de division par zro.
Lorsquune exception survient, lexcution de lactivit en cours est abandonne sans gnrer
de valeur de sortie. Le mcanisme dexcution recherche alors un gestionnaire dexception
susceptible de traiter lexception leve ou une de ses classes parentes. Si lactivit qui a lev
lexception nest pas protge de cette exception, lexception est propage lactivit englobante.
Lexcution de cette dernire est abandonne, ses valeurs de sortie ne sont pas gnres et un
gestionnaire dexception est recherch son niveau. Ce mcanisme de propagation se poursuit
jusqu ce quun gestionnaire adapt soit trouv. Si lexception se propage jusquau sommet

dune activit (i.e. il ny a plus dactivit englobante), trois cas de figure se prsentent. Si lactivit
a t invoque de manire asynchrone, aucun effet ne se produit et la gestion de lexception
est termine. Si lactivit a t invoque de manire synchrone, lexception est propage au
mcanisme dexcution de lappelant. Si lexception sest 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 dexception adapt a t trouv et que son excution se termine, lexcution
se poursuit comme si lactivit protge stait termine normalement, les valeurs de sortie
fournies par le gestionnaire remplaant celle que lactivit protge aurait d produire.

6.8. TRAVAUX DIRIGS DIAGRAMME DACTIVITS
6.8 Travaux Dirigs Diagramme dactivits

6.8.1 Mousse au chocolat (question du contrle du 8 janvier 2007)
Voici une recette de mousse au chocolat simplifie :
Commencez par casser le chocolat en morceaux, puis le faire fondre.
Pendant ce temps, cassez les ufs en sparant les blancs des jaunes.
Mettez les blancs monter en neige dans un robot.
Pendant ce temps, mlangez les jaunes au chocolat fondu.
Une fois le mlange termin et les blancs en neige bien ferme, incorporez dlicatement les
blancs au mlange.
Versez la prparation dans des ramequins individuels.
Mettre au frais au moins 3 heures.
Cest prt !
1. Reprsentez par un diagramme dactivit le workflow de la recette de la mousse au chocolat.
6.8.2 Modlisation dune opration dinsertion dans un tableau tri

Supposons un tableau (tab : int[]) dentiers tris par ordre croissant et un entier (val : int)
insrer dans ce tableau. On suppose que la taille TABMAX du tableau, qui nest pas dynamique,
ainsi que le nombre dentiers tabcont quil contient sont passs en paramtres.
2. Proposez un diagramme dactivit modlisant une opration dinsertion de cet entier dans
ce tableau. Si le tableau est trop petit pour supporter une insertion, lactivit se termine.
3. Modifiez le diagramme tabli ci-dessus pour quune exception soit leve lorsque le tableau
est trop petit pour supporter une insertion.
6.8.3 Partitions
On sintresse ici aux formalits daccueil dun employ qui vient dtre recrut. Ce scnario
commence par lacceptation du poste par le candidat auprs des ressources humaines. Cette
action dclenche simultanment diffrentes actions auprs de diffrents services :
les ressources humaines prparent les documents dembauche, puis, soumettent au future
employ le contrat pour signature ;
le dpartement informatique ouvre un compte pour le nouvel arrivant ;
le secrtariat gnral se charge dallouer un bureau au nouvel arrivant.
4. Proposez un diagramme dactivit partitionn par service illustrant ce scnario.
6.8.4 Documentation dun cas dutilisation

Ci-dessous figure la description textuelle du cas dutilisation Grer emprunt de lexercice de
La bibliothque (section 2.6.3) du TD 2.6.
Identification du cas
Nom : Grer emprunt
Objectif : permettre lassistant de renseigner et, le cas chant, de valider lemprunt dun
ouvrage par un abonn.

Acteurs principaux : Assistant.

Acteurs secondaires : nant.
Dates : 03/12/2007.
Responsable : M. Tantsissa.
Version : 1.1.
Description sous la forme dune squence de messages

Le cas dutilisation commence quand un abonn prsente un assistant un, ou plusieurs,
exemplaires quil veut emprunter.
Prconditions : labonn possde sa carte dabonnement.
Enchanement nominal
1. Lassistant identifie labonn en prsentant la carte de labonn au lecteur de carte
du systme.
2. Le systme vrifie que labonn a pay sa cotisation annuelle.
3. Le systme vrifie que labonn ne possde pas dexemplaire dpassant la dure
autorise du prt.
4. Lassistant identifie un exemplaire emprunt en le passant devant le lecteur de code
dexemplaire du systme.
5. Le systme vrifie que labonn ne dpasse pas les quotas demprunts autoriss.
6. Si labonn prsente dautres exemplaires lassistant on boucle au point 4.
Enchanements alternatifs
A1) Labonn na pas pay sa cotisation lenchanement dmarre au point 1 de la
squence nominale :
1. Le systme invite lassistant demander labonn de payer sa cotisation.
2. Si labonn paie sa cotisation, lenchanement reprend au point 3 de la squence
nominale, sinon lenchanement sachve.
A2) Labonn est en retard pour la restitution dun exemplaire lenchanement dmarre
au point 3 de la squence nominale :
1. Le systme invite lassistant demander labonn de rendre lexemplaire en
retard.
2. Si labonn rend lexemplaire, lenchanement reprend au point 3 de la squence
nominale, sinon lenchanement sachve.
A3) Labonn dpasse un quota demprunt lenchanement dmarre au point 5 de la
squence nominale :
1. Le systme prvient lassistant que labonn ne peut emprunter cet exemplaire car
il dpasse un quota demprunt. Lenchanement reprend au point 6 de la squence
nominale.
Enchanements dexception
E1) La carte nest pas lisible lenchanement dmarre au point 1 de la squence
nominale :
1. Le systme indique lassistant que la carte nest pas lisible. Lenchanement
sachve.

6.8. TRAVAUX DIRIGS DIAGRAMME DACTIVITS
E2) Ouvrage non rfrenc lenchanement dmarre au point 4 de la squence nomi-

nale :
1. Le systme indique lassistant que lexemplaire ne peut tre emprunt car son
tiquette doit tre refaite. Lenchanement reprend au point 6 de la squence nomi-
nale.
Postconditions
Le systme a enregistr toutes les informations relatives lemprunt : date, heure,
numros dexemplaires, numro dabonn.
5. En vous basant sur la description textuelle ci-dessus, reprsentez par un diagramme
dactivits le cas dutilisation Grer emprunt.


Chapitre 7
Diagrammes dinteraction
(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 : lune est centre sur des objets individuels (diagramme
dtats-transitions) et lautre sur une collection dobjets qui cooprent (diagrammes dinterac-
tion).
La spcification dun diagramme dtats-transitions est prcise et conduit immdiatement
au code. Elle ne permet pas pour autant dexpliquer le fonctionnement global dun systme,
car elle se concentre sur un seul objet la fois. Un diagramme dinteraction permet doffrir une
vue plus holistique1 du comportement dun jeu dobjets.
Le diagramme de communication (section 7.2) est un diagramme dinteraction mettant
laccent sur lorganisation structurelle des objets qui envoient et reoivent des messages. Le
diagramme de squence (section 7.3) est un diagramme dinteraction mettant laccent sur la
chronologie de lenvoi des messages. Les diagrammes dinteraction permettent dtablir un lien
entre les diagrammes de cas dutilisation 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 dinteraction, il faut focaliser son attention sur un sous-
ensemble dlments du systme et tudier leur faon dinteragir pour dcrire un comportement
particulier. UML permet de dcrire un comportement limit un contexte prcis de deux faons :
dans le cadre dun classeur structur (cf. section 7.1.2) ou dans celui dune collaboration (cf.
section 7.1.3).
7.1.2 Classeur structur

Les classes dcouvertes au moment de lanalyse (celles qui figurent dans le diagramme de
classes) ne sont parfois pas assez dtailles pour pouvoir tre implmentes par des dvelop-
1
Doctrine ou point de vue qui consiste considrer les phnomnes comme des totalits.
135
CHAPITRE 7. DIAGRAMMES DINTERACTION
F. 7.1 Exemple de classeur structur montrant quun classeur Moteur est en fait constitu
dun Allumage et de quatre Bougie.
peurs. UML propose de partir des classeurs dcouverts au moment de lanalyse (tels que les
classes, mais aussi les sous-systmes, les cas dutilisation, . . .) et de les dcomposer en l-
ments suffisamment fins pour permettre leur implmentation. Les classeurs ainsi dcomposs
sappellent des classeurs structurs.
Un classeur structur est donc la description de la structure dimplmentation interne dune
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 lon cre linstance dun classeur structur, on cre galement une instance de ses ports,
de ses parties et de ses connecteurs.
7.1.3 Collaboration
F. 7.2 Diagramme de collaboration dune transaction immobilire.
Une collaboration permet de dcrire la mise en uvre dune fonctionnalit par un jeu de
participants. Un rle est la description dun participant. Contrairement aux paquetages et aux
classeurs structurs, une collaboration ne dtient pas les instances lies ses rles. Les instances
existent avant ltablissement dune instance de la collaboration, mais la collaboration les ras-
semble et prcise des connecteurs entre elles. Une collaboration peut donc traverser plusieurs
niveaux dun systme et un mme lment peut apparatre dans plusieurs collaborations.
Par exemple, pour implmenter un cas dutilisation, il faut utiliser un ensemble de classes,
et dautres lments, fonctionnant ensemble pour raliser le comportement de ce cas dutilisa-
tion. Cette ensemble dlments, comportant la fois une structure statique et dynamique, est

7.1. PRSENTATION DU FORMALISME
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
F. 7.3 Diagramme de classe dun systme de pilotage.
F. 7.4 Diagramme de communication dun systme de pilotage.
F. 7.5 Diagramme de squence dun systme de pilotage.
Une interaction montre le comportement dun classeur structur ou dune collaboration en

se focalisant sur lchange dinformations entre les lments du classeur ou de la collaboration.
Une interaction contient un jeu de ligne de vie. Chaque ligne de vie correspond une partie
interne dun classeur ou dune collaboration (i.e. un rle dans le cas dune collaboration).

Linteraction dcrit donc lactivit interne des lments du classeur ou de la collaboration,

appels lignes de vie, par les messages quils changent.
UML propose principalement deux diagrammes pour illustrer une interaction : le dia-
gramme de communication et celui de squence. Une mme interaction peut tre prsente
aussi bien par lun que par lautre (cf. figure 7.4 et 7.5).
Remarque
A ces deux diagrammes, UML 2.0 en ajoute un troisime : le diagramme de timing. Son
usage est limit la modlisation des systmes qui sexcutent sous de fortes contraintes de
temps, comme les systmes temps rel.
7.1.5 Reprsentation gnrale

Un diagramme dinteraction se reprsente par un rectangle contenant, dans le coin suprieur
gauche, un pentagone accompagn du mot-clef sd lorsquil sagit dun diagramme de squence
(cf. figure 7.5) et com lorsquil sagit dun diagramme de communication (cf. figure 7.4). Le mot
cl est suivi du nom de linteraction. Dans le pentagone, on peut aussi faire suivre le nom par la
liste des lignes de vie impliques, prcde par le mot cl 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 dun classe.
7.2 Diagramme de communication (Communication diagram)
F. 7.6 Diagramme de communication illustrant la recherche puis lajout, dans son panier
virtuel, dun livre lors dune commande sur Internet.
Contrairement un diagramme de squence, un diagramme de communication2 rend

compte de lorganisation spatiale des participants linteraction, il est souvent utilis pour
illustrer un cas dutilisation 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.
2
Dans la norme UML 1, le diagramme de communication sappelait diagramme de collaboration.

7.3. DIAGRAMME DE SQUENCE
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 ltiquette, les deux points ( :) sont, quand
eux, obligatoire.
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 vies et dont les extrmits peuvent tre ornes de multiplicits.
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 dexpression 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 lenvoi 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 dun message 1.4. La simultanit dun 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) lenvoi squentiel (ou en parallle, avec ||)
de plusieurs message. 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 lordonnancement et la
synchronisation des messages entre les objets du diagramme de communication (cf. figure 7.6).
La direction dun message est spcifie par une flche pointant vers lun ou lautre des objets
de linteraction, relis par ailleurs avec un trait continu (connecteur).
7.3 Diagramme de squence (Sequence diagram)

Les principales informations contenues dans un diagramme de squence 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 scoule 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 :
[<nom_du_rle>] : [<Nom_du_type>]
Au moins un des deux noms doit tre spcifi dans ltiquette, les deux points ( :) sont, quand
eux, obligatoire.
7.3.2 Reprsentation des messages

Un message dfinit une communication particulire entre des lignes de vie. Plusieurs types
de messages existent, les plus commun sont :
lenvoi dun signal ;
linvocation dune opration ;
la cration ou la destruction dune instance.
Messages asynchrones
F. 7.7 Reprsentation dun message asynchrone.
Une interruption ou un vnement sont de bons exemples de signaux. Ils nattendent pas
de rponse et ne bloquent pas lmetteur qui ne sait pas si le message arrivera destination, le
cas chant quand il arrivera et sil serra 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
lextrmit ouverte partant de la ligne de vie dun objet expditeur et allant vers celle de lobjet
cible (figure 7.7).
Messages synchrones
F. 7.8 Reprsentation dun message synchrone.

Linvocation dune opration est le type de message le plus utilis en programmation objet.
Linvocation peut tre asynchrone ou synchrone. Dans la pratique, la pluspart des invocations
sont synchrones, lmetteur reste alors bloqu le temps que dure linvocation de lopration.
Graphiquement, un message synchrone se reprsente par une flche en traits pleins et
lextrmit pleine partant de la ligne de vie dun objet expditeur et allant vers celle de lobjet
cible (figure 7.8). Ce message peut tre suivi dune rponse qui se reprsente par une flche en
pointill (figure 7.8).
Messages de cration et destruction dinstance
F. 7.9 Reprsentation dun message de cration et destruction dinstance.
La cration dun objet est matrialise par une flche qui pointe sur le sommet dune ligne
de vie (figure 7.9).
La destruction dun objet est matrialise par une croix qui marque la fin de la ligne de
vie de lobjet (figure 7.9). La destruction dun objet nest pas ncessairement conscutive la
rception dun message.
vnements et messages
F. 7.10 Les diffrents vnements correspondant un message asynchrone.

UML permet de sparer clairement lenvoi du message, sa rception, ainsi que le dbut de
lexcution de la raction et sa fin (figure 7.10).
Syntaxe des messages et des rponses
F. 7.11 Syntaxe des messages et des rponses.
Dans la plupart des cas, la rception dun message est suivie de lexcution dune mthode
dune 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 matria-
lise le message, et non par une flche supplmentaire au dessus du connecteur reliant les
objets comme cest le cas dans un diagramme de communication ;
les numros de squence sont gnralement omis puisque lordre relatif des messages est
dj matrialis par laxe vertical qui reprsente lcoulement du temps.
La syntaxe de rponse un message est la suivante :
[<attribut> = ] message [ : <valeur_de_retour>]
o message reprsente le message denvoi.

La figure 7.11 montre un exemple dexcution dune mthode avec une rponse.
Message perdu et trouv
F. 7.12 Reprsentation dun message perdu et dun message trouv.

Un message complet est tel que les vnements denvoi et de rception sont connus. Comme
nous lavons dj vu, un message complet se reprsente par une simple flche dirige de
lmetteur vers le rcepteur.
Un message perdu est tel que lvnement denvoi est connu, mais pas lvnement de
rception. Il se reprsente par une flche qui pointe sur une petite boule noire (figure 7.12).
Un message trouv est tel que lvnement de rception est connu, mais pas lvnement
dmission. Une flche partant dune petite boule noire reprsente un message trouv (figure
7.12).
Porte
Une porte est un point de connexion qui permet de reprsenter un mme message dans
plusieurs fragments dinteraction. Ces messages entrants et sortants vont dun bord dune
diagramme une ligne de vie (ou linverse).
Excution de mthode et objet actif
F. 7.13 Reprsentation dun objet actif ( gauche) et dune excution sur un objet passif (
droite).
Un objet actif initie et contrle le flux dactivits. Graphiquement, la ligne pointille verticale
dun objet actif est remplace par un double trait vertical (cf. figures 7.13).
Un objet passif, au contraire, a besoin quon lui donne le flux dactivit pour pouvoir excuter
une mthode. La spcification de lexcution dune raction sur un objet passif se reprsente par
un rectangle blanc ou gris plac sur la ligne de vie en pointille (cf. figures 7.13). Le rectangle
peut ventuellement porter un label.
F. 7.14 Reprsentation dune excution simultane ( gauche).
Les excutions simultanes sur une mme ligne de vie sont reprsentes par un rectangle
chevauchant comme le montre la figure 7.14.

7.3.3 Fragments dinteraction combins

Introduction
Un fragment combin reprsente des articulations dinteractions. Il est dfini par un opra-
teur et des oprandes. Loprateur conditionne la signification du fragment combin. Il existe
12 doprateurs dfinis dans la notation UML 2.0. Les fragments combins permettent de d-
crire des diagrammes de squence de manire compacte. Les fragments combins peuvent faire
intervenir lensemble des entits participant au scnario ou juste un sous-ensemble.
Un fragment combin se reprsente de la mme faon quune 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 dinteraction. Les oprandes dun oprateur
dinteraction sont spars par une ligne pointille. Les conditions de choix des oprandes sont
donnes par des expressions boolennes entre crochets ([ ]).
La liste suivante regroupe les oprateurs dinteraction par fonctions :
les oprateurs de choix et de boucle : alternative, option, break et loop ;
les oprateurs contrlant lenvoi en parallle de messages : parallel et critical region ;
les oprateurs contrlant lenvoi de messages : ignore, consider, assertion et negative ;
les oprateurs fixant lordre denvoi des messages : weak sequencing , strict sequencing.
Nous naborderons que quelques-unes de ces interactions dans la suite de cette section.
Oprateur alt
Loprateur alternative, ou alt, est un oprateur conditionnel possdant plusieurs oprandes

(cf. figure 7.15). Cest un peu lquivalent dune excution choix multiple (condition switch
en C++). Chaque oprande dtient une condition de garde. Labsence de condition de garde
implique une condition vraie (true). La condition else est vraie si aucune autre condition nest
vraie. Exactement un oprande dont la condition est vraie est excut. Si plusieur oprandes
prennent la valeur vraie, le choix est non dterministe.
Oprateurs opt
Loprateur option, ou opt, comporte une oprande et une condition de garde associe.
Le sous-fragment sexcute si la condition de garde est vraie et ne sexcute pas dans le cas
contraire.
Oprateur loop
Un fragment combin de type loop possde un sous-fragment et spcifie un compte minimum

et maximum (boucle) ainsi quune 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 quune 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.

F. 7.15 Reprsentation dun choix dans un diagramme de squence illustrant le dcouvre-

ment dune case au jeu du dmineur.
F. 7.16 Microwave est un exemple dobjet effectuant deux tches en parallle.

Oprateur par
Un fragments combin de type parallel, ou par, possde au moins deux sous-fragments
excuts simultanment (cf. figure 7.16). La concurrence est logique et nest pas ncessairement
physique : les excutions concurrentes peuvent sentrelacer sur un mme chemin dexcution
dans la pratique.
Oprateur strict
F. 7.17 Procdures de dcollage dun avion dans lordre.
Un fragments combin de type strict sequencing, ou strict, possde au moins deux sous-
fragments. Ceux-ci sexcutent selon leur ordre dapparition au sein du fragment combin. Ce
fragment combin est utile surtout lorsque deux parties dun diagramme nont pas de ligne de
vie en commun (cf. figure 7.17).
7.3.4 Utilisation dinteraction (interaction use)

Il est possible de faire rfrence une interaction (on appelle cela une utilisation dinteraction)
dans la dfinition dune autre interaction. Comme pour toute rfrence modulaire, cela permet
la rutilisation dune dfinition dans de nombreux contextes diffrents.
Lorsquune utilisation dinteraction sexcute, elle produit le mme effet que lexcution
dune interaction rfrence avec la substitution des arguments fournie dans le cadre de luti-
lisation de linteraction. Lutilisation de linteraction doit couvrir toutes les lignes de vie qui
apparaissent dans linteraction rfrence. Linteraction 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 linteraction
rfrence (cf. figure 7.17). La syntaxe complte pour spcifier linteraction rutiliser est la
suivante :
[ <nomAttributValeurRetour> = ] <nomInteraction>
[ ( [<arguments>] ) ][ : <valeurRetour> ]

7.4. TRAVAUX DIRIGS DIAGRAMME DINTERACTION
7.4 Travaux Dirigs Diagramme dinteraction

7.4.1 Diagramme de communication : syntaxe des messages
1. Expliquez la syntaxe des messages suivants extraits dun diagramme de communication.
truc()
truc(chose)
machin=truc(chose)
1:truc()
2.1:truc()
3.2b:truc()
[a>b]:truc()
*[i:=0..10]:truc()
*||[pour toutes les portes]:fermer()
[heure=heure_de_dpart] 1.1a *||[i:=0..10]:ok[i]=fermer()
7.4.2 Nono le petit robot

La situation est celle dun petit bras articul (un petit robot) capable de dplier ou de replier
son bras et douvrir ou de fermer sa pince pour aller chercher des objets quand on le lui
demande. Les trois participants la collaboration tudie sont le robot, le bras articul et la
pince.
2. Dans le cadre de cette collaboration, illustrez par un diagramme de communication lin-
teraction suivante :
on demande au robot daller chercher un objet ;
le robot dplie son bras ;
le robot ferme sa pince ;
le robot replie son bras ;
le robot ouvre sa pince.
3. Proposez maintenant un diagramme de squence quivalent.
7.4.3 Types de messages

Quand un courrier lectronique est envoy, lmetteur ne veut pas attendre que le destina-
taire lait reu.
4. Peut-on utiliser un message synchrone ? Compltez la figure ci-dessous pour reprsenter
correctement la situation.
5. On suppose maintenant quun serveur de messagerie sert dintermdiaire entre lmetteur

et le rcepteur dun message. Le serveur est toujours en fonction. Peut-on utiliser des
messages synchrones pour lenvoi et la rception des messages ? Compltez la figure

ci-dessous par une squence de messages illustrant lenvoi et la rception dun message
lectronique.
6. Proposez un diagramme de classe cohrent avec le diagramme de squence ci-dessus.
Les scnarii de la description textuelle des cas dutilisation sont illustrs par des diagrammes
de squence systme (cf. section 9.2.2) qui rendent compte des interactions entre 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.
7. Proposez un diagramme de squence systme correspondant aux scnarii trouvs dans

lexercice de la section 2.6.3.
7.4.5 Distributeur de boisson

Un distributeur de boisson permet dobtenir la boisson de son choix aprs avoir tap le code
de la boisson dsire puis pay par carte bancaire ou avec de la monnaie.

7.4. TRAVAUX DIRIGS DIAGRAMME DINTERACTION
8. En vous appuyant sur le diagramme de classes ci-dessus, proposez un diagramme de

squence illustrant une interaction allant de la commande dune boisson sa distribution
et traitant les deux types de paiement. On ne vous demande pas de prendre en compte
les cas exceptionnels (code de carte bancaire erron, monnaie manquante, etc.)
9. Traduisez votre diagramme de squence en diagramme de communication


Chapitre 8
Diagrammes de composants
(Component diagram)
&
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, puisquils 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.
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 dun logiciel, nous
avons introduit la notion de rutilisabilit comme tant laptitude dun logiciel tre rutilis,
en tout ou en partie, dans de nouvelles applications. Or, la notion de classe, de part 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 dapplications 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 programmaiton met laccent sur la rutilisation du composant et lindpendance de son
volution vis--vis des applications qui lutilisent.
La programmation oriente composant sintgre trs bien dans le contexte de la programma-
tion oriente objet puisquil ne sagit, finalement, que dun facteur dchelle. En effet, lutilisation
151
CHAPITRE 8. DIAGRAMMES DE COMPOSANTS ET DE DPLOIEMENT
de composants est assimilable une approche objet, non pas au niveau du code, mais au niveau
de larchitecture gnrale du logiciel.
8.2.2 Notion de composant

Un composant doit fournir un service bien prcis. Les fonctionnalits quil encapsule doivent
tre cohrentes entre elles et gnriques (par opposition spcialises) puisque sa vocation est
dtre 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. Lim-
plmentation dun composant peut tre ralise par dautres composants, des classes ou des
artefacts (cf. section 8.3.3). Les lments dun composant peuvent tre reprsents dans le sym-
bole 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).
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 strotype delegate, et appele connecteur de
dlgation.
Lutilisation des ports permet de modifier la structure interne dun classeur sans affecter les
clients externes.
8.2.4 Diagramme de composants

La relation de dpendance est utilise dans les diagrammes de composants pour indiquer
quun lment de limplmentation dun composant fait appel aux services offerts par les
lments dimplmentation dun autre composant (cf. figure 8.6).
Lorsquun composant utilise linterface dun autre composant, on peut utiliser la reprsen-
tation de la figure 8.3 en imbriquant le demi-cercle dune interface requise dans le cercle de
linterface offerte correspondante (cf. figure 8.5).

8.2. DIAGRAMMES DE COMPOSANTS
F. 8.1 Reprsentation dun composant et de ses interfaces requises ou offertes sous la forme
dun classeur structur strotyp component. Au lieu ou en plus du mot cl, on peut faire
figurer une icne de composant (petit rectangle quip de deux rectangles plus petits dpassant
sur son ct gauche) dans langle suprieur droit (comme sur la figure de droite).
F. 8.2 Reprsentation dun composant accompagne de la reprsentation explicite de ses

interfaces requise et offerte.
F. 8.3 Reprsentation classique dun composant et de ses interfaces requise (reprsent

par un demi-cercle) et offerte (reprsente par un cercle). Cette reprsentation est souvent
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.
F. 8.4 Reprsentation dun composant et de ses interfaces requise et offerte avec la repr-
sentation explicite de leur port correspondant.

F. 8.5 Reprsentation de limplmentation dun composant complexe contenant des sous-

composants.
F. 8.6 Exemple de diagramme montrant les dpendances entre composants.

8.3. DIAGRAMME DE DPLOIEMENT
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
F. 8.7 Reprsentation dun nud ( gauche) et dune 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, . . .).
F. 8.8 Deux possibilits pour reprsenter laffectation dun composant un nud.
Pour montrer quun 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 dartefact (artifact)

Un artefact correspond un lment concret existant dans le monde rel (document, excu-
table, fichier, tables de bases de donnes, script, . . .). Il se reprsente comme un classeur par un
rectangle contenant le mot-cl artifact suivi du nom de lartefact (cf. figures 8.9 et 8.9).
Limplmentation des modles (classes, . . .) se fait sous la forme de jeu dartefacts. On dit
quun artefact peut manifester, cest--dire rsulter et implmenter, un ensemble dlments
de modle. On appelle manifestation la relation entre un lment de modle et lartefact qui

F. 8.9 Reprsentation du dploiement de deux artefacts dans un nud. La dpendance

entre les deux artefacts est galement reprsente.
F. 8.10 Reprsentation du dploiement de deux artefacts dans un nud utilisant la relation

de dpendance strotype deploy.
F. 8.11 Reprsentation du dploiement dans un nud dun artefact manifestant un compo-

sant.

8.3. DIAGRAMME DE DPLOIEMENT
limplmente. Graphiquement, une manifestation se reprsente par une relation de dpendance

strotype manifest (cf. figure 8.11).
Une instance dun 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). Lartefact peut aussi tre inclus directement dans le cube
reprsentant le noeud (cf. figure 8.9). En toute rigueur, seul des artefacts doivent tre dploys
sur des nuds. Un composant doit donc tre manifest par un artefact qui, lui-mme, peut tre
dploy sur un nud.
8.3.4 Diagramme de dploiement
F. 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 lchange dinformations (cf. figure 8.12).


Chapitre 9
Mise en uvre dUML
9.1 Introduction
9.1.1 UML nest pas une mthode
F. 9.1 Quelle mthode pour passer de lexpression des besoins au code de lapplication ?
La problmatique que pose la mise en uvre dUML est simple : comment passer de
lexpression des besoins au code de lapplication ? Cette problmatique est parfaitement illustre
par la figure 9.1.
Comme nous lavons dj dit, maintes reprises, UML nest quun langage de modlisation,
ce nest pas une mthode. En effet, UML ne propose pas une dmarche de modlisation explici-
tant et encadrant toutes les tapes dun projet, de la comprhension des besoins la production
du code de lapplication. Une mthode se doit de dfinir une squence dtapes, partiellement
ordonnes, dont lobjectif est de produire un logiciel de qualit qui rpond aux besoins des
utilisateurs dans des temps et des cots prvisibles.
Bien quUML ne soit pas une mthode, ses auteurs prcisent nanmoins quune mthode
base sur lutilisation UML doit tre :
Pilote par les cas dutilisation : La principale qualit dun logiciel tant son utilit, cest--
dire son adquation avec les besoins des utilisateurs, toutes les tapes, de la spcification
des besoins la maintenance, doivent tre guides par les cas dutilisation qui modlisent
justement les besoins des utilisateurs.
Centre sur larchitecture : Larchitecture est conue pour satisfaire les besoins exprims dans
les cas dutilisation, mais aussi pour prendre en compte les volutions futures et les
contraintes de ralisation. La mise en place dune architecture adapte conditionne le
succs dun dveloppement. Il est important de la stabiliser le plus tt possible.
159
CHAPITRE 9. MISE EN UVRE DUML
Itrative et incrmentale : Lensemble du problme est dcompos en petites itrations, dfi-

nies partir des cas dutilisation et de ltude des risques. Les risques majeurs et les cas
dutilisation 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 Roques (2002) dans son livre UML - Modliser un site e-commerce qui rsulte de plusieurs
annes dexprience sur de nombreux projets dans des domaines varis. Elle a donc montr son
efficacit dans la pratique et est :
conduite par les cas dutilisation, comme UP, mais bien plus simple ;
relativement lgre et restreinte, comme XP, mais sans ngliger les activits de modlisa-
tion en analyse et conception ;
fonde sur lutilisation dun sous-ensemble ncessaire et suffisant du langage UML (mo-
dliser 80% des problmes en utilisant 20% dUML).
Dans tous les cas, il faut garder lesprit quune mthode nest pas une formule magique.
Le fait de produire des diagrammes UML selon un ordre tabli nest en aucun cas une garantie
de russite. Une mthode ne sert qu canaliser et ordonner les tapes de la modlisation. La
valeur nest pas dans la mthode mais dans les personnes qui la mettent en uvre.
9.2 Identification des besoins et spcification des fonctionnalits

9.2.1 Identification et reprsentation des besoins : diagramme de cas dutilisation
F. 9.2 Les besoins sont modliss par un diagramme de cas dutilisation.
Les cas dutilisation 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.

9.2. IDENTIFICATION DES BESOINS
Durant cette tape, vous devrez dterminer les limites du systme, identifier les acteurs
et recenser les cas dutilisation (cf. section 2.5). Si lapplication est complexe, vous pourrez
organiser les cas dutilisation en paquetages.
Dans le cadre dune approche itrative et incrmentale, il faut affecter un degr dimportance
et un coefficient de risque chacun des cas dutilisation pour dfinir lordre des incrments
raliser.
Les interactions entre les acteurs et le systme (au sein des cas dutilisation) 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 quils attendent du systme. Lobjectif de cette tape et des deux suivantes (section 9.2.2 et
9.2.3) est justement de les aider formuler et formaliser ces besoins.
9.2.2 Spcification dtaille des besoins : diagrammes de squence systme
F. 9.3 Les diagrammes de squence systme illustrent la description textuelle des cas
dutilisation.
Dans cette tape, on cherche dtailler la description des besoins par la description textuelle
des cas dutilisation (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 dutilisation puisque nous somme toujours dans la spcification des besoins.
Les scnarii de la description textuelle des cas dutilisation peuvent tre vus comme des
instances de cas dutilisation et sont illustrs par des diagrammes de squence systme. Il faut,
au minimum, reprsenter le scnario nominal de chacun des cas dutilisation par un diagramme
de squence qui rend compte de linteraction entre lacteur, 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 dun cas dutilisation sont nombreux et importants, lutilisa-
tion dun diagramme dtats-transitions ou dactivits peut savrer prfrable une multitude
de diagrammes de squence.

F. 9.4 Une maquette dIHM facilite les discussions avec les futurs utilisateurs.
9.2.3 Maquette de lIHM de lapplication (non couvert par UML)

Une maquette dIHM (Interface Homme-Machine) est un produit jetable permettant aux
utilisateurs davoir une vue concrte mais non dfinitive de la future interface de lapplication
(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 lutilisateur de tester lenchanement 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 danalyse

9.3.1 Analyse du domaine : modle du domaine
La modlisation des besoins par des cas dutilisation sapparente une analyse fonctionnelle
classique. Llaboration du modle des classes du domaine permet doprer une transition vers
une vritable modlisation objet. Lanalyse du domaine est une tape totalement dissocie de
lanalyse 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 danalyse du domaine permet dlaborer la premire version du diagramme de
classes (figure 9.5) appele modle du domaine. Ce modle doit dfinir les classes qui mod-
lisent les entits ou concepts prsents dans le domaine (on utilise aussi le terme de mtier) de
lapplication. Il sagit 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

9.3. PHASES DANALYSE
F. 9.5 La phase danalyse du domaine permet dlaborer la premire version du diagramme

de classes.
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 dopration, 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
lhritage ;
le cas chant, structurer les classes en paquetage selon les principes de cohrence et
dindpendance.
Lerreur la plus courante lors de la cration dun 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 sagit simplement dun attribut. Par contre, si
un concept recouvre un ensemble dinformations, alors il sagit plutt dune classe qui possde
elle-mme plusieurs attributs.
9.3.2 Diagramme de classes participantes

Le diagramme de classes participantes est particulirement important puisquil effectue la
jonction entre, dune part, les cas dutilisation (section 9.2.1), le modle du domaine (section
9.3.1) et la maquette (section 9.2.3), et dautre part, les diagrammes de conception logicielle
que sont les diagrammes dinteraction (section 9.4.1) et le diagramme de classes de concep-
tion (section 9.4.2). Les diagrammes de conception logicielle napparaissent pas encore sur la

F. 9.6 Le diagramme de classes participantes effectue la jonction entre les cas dutilisation,
le modle du domaine et les diagrammes de conception logicielle.
figure 9.6.
Il nest pas souhaitable que les utilisateurs interagissent directement avec les instances des
classes du domaine par le biais de linterface graphique. En effet, le modle du domaine doit
tre indpendant des utilisateurs et de linterface graphique. De mme, linterface graphique
du logiciel doit pouvoir voluer sans rpercussion sur le cur de lapplication. Cest le prin-
cipe fondamental du dcoupage en couches dune application. Ainsi, le diagramme de classes
participantes modlise trois types de classes danalyse, les dialogues, les contrles et les entits
ainsi que leurs relations.
Les classes de dialogues Les classes qui permettent les interactions entre lIHM et les utili-
sateurs sont qualifies de dialogues. Ces classes sont directement issues de lanalyse de
la maquette prsente section 9.2.3. Il y a au moins un dialogue pour chaque association
entre un acteur et un cas dutilisation du diagramme de cas dutilisation de la section 9.2.1.
En gnral, les dialogues vivent seulement le temps du droulemet du cas dutilisation
concern.
Les classes de contrles Les classes qui modlisent la cinmatique de lapplication sont ap-
peles contrles. Elles font la jonction entre les dialogues et les classes mtier en permettant
au diffrentes vues de lapplication 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 dentits. Ces classes sont gnralement persistantes,
cest--dire quelles survivent lexcution dun cas dutilisation particulier et quelles

9.3. PHASES DANALYSE
permettent des donnes et des relations dtre stockes dans des fichiers ou des bases
de donnes. Lors de limplmentation, 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 llaboration 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 quavec dautres entits ou avec des contrles,
mais, dans ce dernier cas, avec une contrainte de navigabilit interdisant de traverser une
association dune entit vers un contrle.
Les contrles ne comportent que des oprations. Ils implmentent la logique applicative
(i.e. les fonctionnalits de lapplication), et peuvent correspondre des rgles transverses
plusieurs entits. Chaque contrle est gnralement associ un cas dutilisation, et
vice versa. Mais rien nempche de dcomposer un cas dutilisation complexe en plusieurs
contrles.
Les contrles peuvent tre associs tous les types de classes, y compris dautres contrles.
Dans le cas dune association entre un dialogue et un contrle, une contrainte de naviga-
bilit doit interdire de traverser lassociation du contrle vers le dialogue.
Les dialogues comportent des attributs et des oprations. Les attributs reprsentent des
informations ou des paramtres saisis par lutilisateur ou des rsultats dactions. Les op-
rations ralisent (gnralement par dlgation aux contrles) les actions que lutilisateur
demande par le biais de lIHM.
Les dialogues peuvent tre en association avec des contrles ou dautres dialoques, mais
pas directement avec des entits.
Il est galement possible dajouter 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 dtats-transitions.
Lattribution des bonnes responsabilits, dgage dans la section 9.2.2, aux bonnes classes
est lun des problmes les plus dlicats de la conception oriente objet. Ce problme sera affront
en phase de conception lors de llaboration des diagrammes dinteraction (section 9.4.1) et du
diagramme de classes de conception (section 9.4.2).
Lors de la phase dlaboration du diagramme de classes participantes, le chef de projet a
la possibilit de dcouper le travail de son quipe danalystes par cas dutilisation. Lanalyse
et limplmentation des fonctionnalits dgages par les cas dutilisation dfinissent alors les
itrations raliser. Lordonnancement des itrations tant dfini par le degr dimportance et
le coefficient de risque affect chacun des cas dutilisation dans la section 9.2.1.
9.3.3 Diagrammes dactivits de navigation

Les IHM modernes facilitent la communication entre lapplication et lutilisateur en offrant
toute une gamme de moyens daction et de visualisation comme des menus droulants ou
contextuels, des palettes doutils, des botes de dialogues, des fentres de visualisation, etc. Cette
combinaison possible doptions daffichage, dinteraction et de navigation aboutis aujourdhui
des interfaces de plus en plus riches et puissantes.
UML offre la possibilit de reprsenter graphiquement cette activit de navigation dans
linterface en produisant des diagrammes dynamiques. On appelle ces diagrammes des dia-

F. 9.7 Les diagrammes dactivits de navigation reprsentent graphiquement lactivit de

navigation dans lIHM.
grammes de navigation. Le concepteur le choix dopter pour cette modlisation entre des dia-
grammes dtats-transitions et des diagrammes dactivits. Les diagrammes dactivits consti-
tuent peut-tre un choix plus souple et plus judicieux.
Les diagrammes dactivits 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 intrt tre structure par acteur.
9.4 Phase de conception

9.4.1 Diagrammes dinteraction
Maintenant, il faut attribuer prcisment les responsabilits de comportement, dgage par
le diagrammes de squence systme dans la section 9.2.2, aux classes danalyse du diagramme
de classes participantes labor dans la section 9.3.2. Les rsultats de cette rflexion sont pr-
sents sous la forme de diagrammes dinteraction UML (figure 9.8). Inversement, llaboration
de ces diagrammes facilite grandement la rflexion.
Paralllement, une premire bauche de la vue statique de conception, cest--dire du dia-
gramme de classes de conception, est construite et complte. Durant cette phase, lbauche du
diagramme de classes de conception reste indpendante des choix technologiques qui seront
faits ultrieurement (dans la section 9.4.2).

9.4. PHASE DE CONCEPTION
F. 9.8 Les diagrammes dinteraction permettent dattribuer prcisment les responsabilits

de comportement aux classes danalyse.
Pour chaque service ou fonction, il faut dcider quelle est la classe qui va le contenir. Les
diagrammes dinteractions (i.e de squence ou de communication) sont particulirement utiles
au concepteur pour reprsenter graphiquement ces dcisions dallocations des responsabilits.
Chaque diagramme va reprsenter un ensemble dobjets de classes diffrentes collaborant dans
le cadre dun scnario dexcution du systme.
Dans les diagrammes dinteraction, les objets communiquent en senvoyant 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 deux. Avec un
outil de modlisation UML (comme Rational Rose ou PowerAMC), la spcification de lenvoi
dun message entre deux objets cre effectivement une opration publique sur la classe de lobjet
cible. Ce type doutil permet rellement de mettre en uvre lallocation des responsabilits
partir des diagrammes dinteraction.
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 dobjets en collaboration (cf. figure
9.9). Ces objets sont des instances des trois types de classes danalyse 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 puis interagir
directement, il faut que :
les classes dont ils sont issus soient en association dans le diagramme de classes partici-
pantes1 ;
1
Si elles ne sont pas en association, il doit au moins exister une relation de dpendance comme illustre par la

F. 9.9 Le systme des diagrammes de squences systme, vu comme une bote noire, est
remplac par un ensemble dobjets en collaboration.
linteraction respecte la navigabilit de lassociation en question.
9.4.2 Diagramme de classes de conception

Lobjectif de cette tape est de produire le diagramme de classes qui servira pour lim-
plmentation (figure 9.10). Une premire bauche du diagramme de classes de conception a
dj t labore en parallle du diagrammes dinteraction (section 9.4.1). Il faut maintenant le
complter en prcisant les oprations prives des diffrentes classes. Il faut prendre en comptes
les choix techniques, comme le choix du langage de programmation, le choix des diffrentes
librairies utilises (notamment pour limplmentation de linterface graphique), etc.
Pour une classe, le couplage est la mesure de la quantit dautre classes auxquelles elle est
connecte par des associations, des relations de dpendances, etc. Durant toute llaboration du
diagramme de classes de conception, il faut veiller conserver un couplage faible pour obtenir
une application plus volutive et plus facile maintenir. Lutilisation des design patterns (cf.
section ??) est fortement conseille lors de llaboration du diagramme de classes de conception.
Pour le passage limplmentation, 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).
figure 3.21 de la section 3.3.10.

9.4. PHASE DE CONCEPTION
F. 9.10 Chane complte de la dmarche de modlisation du besoin jusquau code.


Bibliographie
Alissali, M. (1998). Support de cours introduction au gnie logiciel. Internet. (http :// www-ic2.univ-
lemans.fr/ ~alissali/ Enseignement/ Polys/ GL/ gl.html)
Barbier, F. (2005). Uml 2 et mde. Dunod.
Bell, D. (2004). Umls sequence diagram. Internet. (http ://www-128.ibm.com/ developerworks/

rational/ library/ 3101.html#notes)
Booch, G., Rumbaugh, J. & Jacobson, I. (2003). Le guide de lutilisateur uml. Eyrolles.
Cariou, E. (2003, novembre). Support de cours "le langage de contraintes ocl". Internet. (http ://
www.univ-pau.fr/ ~ecariou/ cours/ mde/ cours-ocl.pdf)
Charroux, B., Osmani, A. & Thierry-Mieg, Y. (2005). Uml2. Pearson Education France.
Debrauwer, L. & Van der Heyd, F. (2005). Uml 2 initiation, exemples et exercices corrigs. eni.
Developpez.com. (n.d.). Club dentraide des dveloppeurs francophones. Internet.

(http ://www.developpez.com/)
Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design patterns : elements of reusable
object-oriented sofware. Addison-Wesley.
Gollot, E. (2004). Les cas dutilisation. Internet. (http :// ego.developpez.com/ uml/ tutoriel/
casUtilisation/)
Grard, P. (2007). Uml. Internet. (http :// www-lipn.univ-paris13.fr/ ~gerard/ fr_ens_uml.html)
Larman, C. (1997). Applying uml and patterns : An introduction to object-oriented analysis and design
and the unified process. Printice Hall.
Malgouyres, H., Seuma-Vidal, J.-P. & Motet, G. (2005). Rgles de cohrence uml 2.0 (version 1.1).
Internet. (http :// www.lesia.insa-toulouse.fr/ UML/ CoherenceUML_v1_1_100605.pdf)
Morand, B. (n.d.). Analyse et conception des systmes dinformation : Les diagrammes de unified
modeling language (uml). Internet. (http :// www.iutc3.unicaen.fr/ ~moranb/ cours/ acsi/
menucoo.htm)
Muller, P.-A. & Gaertner, N. (2000). Modlisation objet avec uml. Eyrolles.
Object Management Group (OMG). (n.d.). Uml resource page. Internet. (http ://www.uml.org/)
Object Management Group (OMG). (2004, aot). Unified modeling language : Superstructure.
Internet. (http ://www.uml.org/)
171
Bibliographie
Object Management Group (OMG). (2006, Mai). Object constraint language. Internet.
(http ://www.uml.org/)
Penders, T. (2002). Introduction uml. OEM.
Piechocki, L. (n.d.). Uml en franais. Internet. (http ://uml.free.fr/)
Pilone, D. & Pitman, N. (2006). Uml 2 en concentr. OReilly.
Roques, P. (2002). Uml - modliser un site e-commerce. Eyrolles.
Roques, P. (2006a). Uml2 - modliser une application web. Eyrolles.
Roques, P. (2006b). Uml2 par la pratique (tude de cas et exercices corrigs) (5 ed.). Eyrolles.
Roques, P. & Valle, F. (2003). Uml en action (2 ed.). Eyrolles.
Rumbaugh, J., Jacobson, I. & Booch, G. (2004). Uml 2.0 guide de rfrence. CampusPress.
Volle, M. (2006). De linformatique (savoir vivre avec lautomate). Economica.
Wikipdia, encyclopdie librement distribuable. (n.d.). Internet. (http ://fr.wikipedia.org/ wiki/

Accueil)

Index
A Automate tats finis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 C
principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Caractristique
reprsentation graphique . . . . . . . . . . . . . . . . . . . . 29 dune classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
secondaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 terminaison dassociation . . . . . . . . . . . . . . . . . . . . 46
Action Cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
diagramme dactivits . . . . . . . . . . . . . . . . . . . . . . 118 description textuelle . . . . . . . . . . . . . . . . . . . . . . . . . 38
Activit diagramme de cas dutilisation . . . . . . . . . . . 2939
diagramme dactivits . . . . . . . . . . . . . . . . . 117130 interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 recensement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
nud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 30
Agrgation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Use case Realization. . . . . . . . . . . . . . . . . . . . . . . . . . .39
composite . . . . . . . . voir relation de composition Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 4550
implmentation en Java . . . . . . . . . . . . . . . . . . . . . 68 abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Approche abstraite (implmentation en Java) . . . . . . . . . . . 65
fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
fonctionnelle vs. objet . . . . . . . . . . . . . . . . . . . . . . . 20 attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
objet (concepts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 attribut de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
oriente objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 attribut de la classe . . . . . . . . . . . . . . . . . . . . . . . . . . 49
structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 attribut drivs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Artefact (diagramme de dploiement) . . . . . . . . . . . 155 caractristique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Association diagramme de classes . . . . . . . . . . . . . . . . . . . . 4562
1 vers 1 (implmentation en SQL) . . . . . . . . . . . . 69 encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1 vers N (implmentation en Java) . . . . . . . . . . . 68 implmentation en Java . . . . . . . . . . . . . . . . . . . . . 65
1 vers N (implmentation en SQL) . . . . . . . . . . . 69 implmentation en SQL . . . . . . . . . . . . . . . . . . . . . 69
bidirectionnelle 1 vers 1 (implm. en Java) . . . 66 instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45, 63
bidirectionnelle 1 vers N (implm. en Java) . . 67 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
quivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46, 49
instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 mthode de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
modles quivalents . . . . . . . . . . . . . . . . . . . . . . . . . 58 mthode de la classe . . . . . . . . . . . . . . . . . . . . . . . . . 49
N vers N (implmentation en SQL) . . . . . . . . . . 70 notion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
n-aire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53, 59 opration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
n-aire (modle quivalent) . . . . . . . . . . . . . . . . . . . 58 proprits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
n-aire vs classe-association vs qualifie . . . . . . 58 proprits structurelles . . . . . . . . . . . . . . . . . . . . . . 46
notion et discussion . . . . . . . . . . . . . . . . . . . . . . . . . 50 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 47
qualifie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 58 syntaxe du nom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
qualifie vs n-aire vs classe-association . . . . . . 58 visibilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
unidirectionnelle 1 vers 1 (implm. en Java) . . 67 Classe-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5659
unidirectionnelle 1 vers N (implm. en Java) . 68 auto-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49, 51 instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 liens multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
de la classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 modle quivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
drivs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 N vers N (implmentation en SQL) . . . . . . . . . . 70
implmentation en Java . . . . . . . . . . . . . . . . . . . . . 65 pour plusieurs associations . . . . . . . . . . . . . . . . . . 56
implmentation en SQL . . . . . . . . . . . . . . . . . . . . . 69 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 56
syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 vs association n-aire vs association qualifie . 58
Auto-association sur classe-association . . . . . . . . . . . 57 Classeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
173
INDEX
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

structur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 pin dentre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 pin de sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Communication pin de valeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
diagramme de communication . . . . . . . . . 138139 transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Composant Diagramme dinteraction . . . . . . . . . . . . . . . . . . . 135146
diagramme de composant . . . . . . . . . . . . . . . . . . 152 interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
diagramme de composants . . . . . . . . . . . . 151152 ligne de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Concurrence Diagramme dobjets. . . . . . . . . . . . . . . . . . . . . . . . . . .6264
dans un diagramme dtats-transitions . . . . . 110 relation de dpendance dinstanciation . . . . . . 64
Contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 63
prdfinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Diagramme dtats-transitions . . . . . . . . . . . . . . . 99112
reprsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 concurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
typologie des contraintes OCL . . . . . . . . . . . 8286 tat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Cycle de vie tat composite . . . . . . . . . . . . . . . . . . . . . . . . . 107112
en cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 tat final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
en spirale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 tat historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 tat historique profond . . . . . . . . . . . . . . . . . . . . . 108
logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 tat initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
modle par incrment . . . . . . . . . . . . . . . . . . . . . . . 18 vnement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102103
vnement dappel . . . . . . . . . . . . . . . . . . . . . . . . . 102
D vnement de changement . . . . . . . . . . . . . . . . . 103
Dpendance vnement de type signal . . . . . . . . . . . . . . . . . . 102
classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 vnement temporel . . . . . . . . . . . . . . . . . . . . . . . 103
Diagramme point de choix . . . . . . . . . . . . . . . . . . . . . . . . . 105107
dactivits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117130 point de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . . . 135146 point de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
dobjets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6264 points de connexion . . . . . . . . . . . . . . . . . . . . . . . . 110
dtats-transitions . . . . . . . . . . . . . . . . . . . . . . . 99112 transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103105
de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . 2939 transition dachvement . . . . . . . . . . . . . . . . . . . . 104
de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4562 transition externe . . . . . . . . . . . . . . . . . . . . . . . . . . 104
de communication . . . . . . . . . . . . . . . . . . . . . 138139 transition interne . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
de composants. . . . . . . . . . . . . . . . . . . . . . . . .151152 Diagramme de cas dutilisation . . . . . . . . . . . . . . . 2939
de dploiement . . . . . . . . . . . . . . . . . . . . . . . . 155157 acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
de squence . . . . . . . . . . . . . . . . . . . . . . . . . . . 139146 acteur principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Diagramme dactivits . . . . . . . . . . . . . . . . . . . . . . 117130 acteur secondaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
activit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 cas dutilisation interne . . . . . . . . . . . . . . . . . . . . . . 32
exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118, 127 identifier les acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 36
flot dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 recenser les cas dutilisation . . . . . . . . . . . . . . . . . 37
groupe dactivits . . . . . . . . . . . . . . . . . . . . . . . . . . 119 relation dassociation . . . . . . . . . . . . . . . . . . . . . . . . 31
nud daction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 relation dextension . . . . . . . . . . . . . . . . . . . . . . . . . 33
nud dactivit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 relation dinclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 33
nud dactivit structure. . . . . . . . . . . . . . . . . .122 relation de gnralisation . . . . . . . . . . . . . . . . 33, 34
nud dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 relation de spcialisation . . . . . . . . . . . . . . . . . 33, 34
nud dunion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3134
nud de bifurcation. . . . . . . . . . . . . . . . . . . . . . . .124 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 30
nud de contrle . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Use case Realization. . . . . . . . . . . . . . . . . . . . . . . . . . .39
nud de dbranchement . . . . . . . . . . . . . . . . . . . 124 Diagramme de classes. . . . . . . . . . . . . . . . . . . . . . . . .4562
nud de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . 123 auto-association sur classe-associations . . . . . . 57
nud de fin dactivit . . . . . . . . . . . . . . . . . . . . . . 123 classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4550
nud de fin de flot . . . . . . . . . . . . . . . . . . . . . . . . . 123 classe association . . . . . . . . . . . . . . . . . . . . . . . . 5659
nud de fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 classe association (instance) . . . . . . . . . . . . . . . . . 63
nud de jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 classe association pour plusieurs associations 56
nud de stockage des donnes . . . . . . . . . . . . . 126 classe-association vs association n-aire vs asso-
nud excutable . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 ciation qualifie . . . . . . . . . . . . . . . . . . . . . . . . 58
nud final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 laboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
nud initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
nud tampon central . . . . . . . . . . . . . . . . . . . . . . 126 notion dassociation . . . . . . . . . . . . . . . . . . . . . . . . . 50

INDEX
possession dune terminaison dassociation . . 51 vnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102103

propritaire dune terminaison dassociation . 51 dappel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
relation dagrgation . . . . . . . . . . . . . . . . . . . . . . . . 59 de changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
relation dassociation . . . . . . . . . . . . . . . . . . . . 5259 de type signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
relation dassociation binaire . . . . . . . . . . . . . . . . 52 diagramme de squence . . . . . . . . . . . . . . . . . . . . 141
relation dassociation n-aire . . . . . . . . . . . . . . . . . 53 temporel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
relation dassociation qualifie . . . . . . . . . . . . . . . 55 Exceptions (diagramme dactivits) . . . . . . . . . 118, 127
relation dhritage . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
relation de composition . . . . . . . . . . . . . . . . . . . . . 60 F
relation de dpendance . . . . . . . . . . . . . . . . . . . . . . 61 Flot dobjet (diagramme dactivits) . . . . . . . . . . . . . 125
relation de gnralisation . . . . . . . . . . . . . . . . . . . . 60 Fragment dinteraction combin . . . . . . . . . . . . 144146
terminaison dassociation . . . . . . . . . . . . . . . . . . . . 51 Oprateur alt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Diagramme de communication . . . . . . . . . . . . . 138139 Oprateur loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
connecteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Oprateur opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
ligne de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Oprateur par . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Oprateur strict . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Diagramme de composants . . . . . . . . . . . . . . . . . 151152
composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 G
port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Gnralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Diagramme de dploiement . . . . . . . . . . . . . . . . 155157 cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 34
classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
artefact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
implmentation en SQL . . . . . . . . . . . . . . . . . . . . . 71
nud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Gnie logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 12
Diagramme de squence . . . . . . . . . . . . . . . . . . . . 139146
Gnie logiciel (crise) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
vnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Groupe dactivits (diagramme dactivits) . . . . . . 119
excution de mthode . . . . . . . . . . . . . . . . . . . . . . 143
excution simultane . . . . . . . . . . . . . . . . . . . . . . . 143
H
fragment dinteraction combin . . . . . . . . 144146
Hritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
ligne de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 implmentation en Java . . . . . . . . . . . . . . . . . . . . . 66
message asynchrone . . . . . . . . . . . . . . . . . . . . . . . 140 implmentation en SQL . . . . . . . . . . . . . . . . . . . . . 71
message de cration . . . . . . . . . . . . . . . . . . . . . . . . 141 Historique
message de destruction . . . . . . . . . . . . . . . . . . . . . 141 modlisation objet . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
message perdu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 programmation par objets . . . . . . . . . . . . . . . . . . . 22
message synchrone . . . . . . . . . . . . . . . . . . . . . . . . . 140
message trouv . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 I
objet actif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Implmentation
oprateur alt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6568
oprateur loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 agrgation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
oprateur opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 association 1 vers N . . . . . . . . . . . . . . . . . . . . . . . 68
oprateur par . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 association bidirectionnelle 1 vers 1 . . . . . . . 66
oprateur strict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 association bidirectionnelle 1 vers N . . . . . . 67
porte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 association unidirectionnelle 1 vers 1 . . . . . . 67
syntaxe des messages . . . . . . . . . . . . . . . . . . . . . . 142 association unidirectionnelle 1 vers N . . . . . 68
utilisation dinteraction . . . . . . . . . . . . . . . . . . . . . 146 attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Dploiement classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
diagramme de dploiement . . . . . . . . . . . . 155157 classe abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
E hritage simple . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 47 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Espace de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 opration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
tat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 ralisation dune interface . . . . . . . . . . . . . . . . . 66
composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107112 en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6972
final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 association 1 vers 1 . . . . . . . . . . . . . . . . . . . . . . . 69
historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 association 1 vers N . . . . . . . . . . . . . . . . . . . . . . . 69
historique profond . . . . . . . . . . . . . . . . . . . . . . . . . 108 association N vers N . . . . . . . . . . . . . . . . . . . . . . 70
initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
tats-transition classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
diagramme dtats-transitions . . . . . . . . . . 99112 classe-association N vers N . . . . . . . . . . . . . . . 70
tude du Standish Group . . . . . . . . . . . . . . . . . . . . . . . . . 11 gnralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

INDEX
hritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 dunion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

opration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 de bifurcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
relation dhritage . . . . . . . . . . . . . . . . . . . . . . . . 71 de contrle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
relation de gnralisation . . . . . . . . . . . . . . . . . 71 de dbranchement . . . . . . . . . . . . . . . . . . . . . . . . . 124
Instance de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 de fin dactivit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45, 63 de fin de flot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
classe-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 de fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
notion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 de jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 de stockage des donnes . . . . . . . . . . . . . . . . . . . 126
Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 diagramme de dploiement . . . . . . . . . . . . . . . . 155
diagramme dinteraction . . . . . . . . . . . . . . . 135146 excutable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 47, 50, 62 final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
implmentation en Java . . . . . . . . . . . . . . . . . . . . . 66 initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
tampon central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
L Navigabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Ligne de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 54
diagramme de communication . . . . . . . . . . . . . 139 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
diagramme de squence . . . . . . . . . . . . . . . . . . . . 140 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 36
Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 O
qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Object constraint langage . . . . . . . . . . . . . . . . . . . . . . . 7798
Objet
M
diagramme dobjets . . . . . . . . . . . . . . . . . . . . . . 6264
Matre duvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
qualifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Matre douvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
reprsentation graphique . . . . . . . . . . . . . . . . . . . . 63
Message
OCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7798
asynchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
de cration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 -() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
de destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 =() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
diagramme de communication . . . . . . . . . . . . . 139 accs aux attributs (self ) . . . . . . . . . . . . . . . . . . . . . 88
diagramme de squence . . . . . . . . . . . . . . . 140, 142 accs aux caractristiques . . . . . . . . . . . . . . . . 8892
vnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 accs aux objets . . . . . . . . . . . . . . . . . . . . . . . . . . 8892
perdu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 accs aux oprations (self ) . . . . . . . . . . . . . . . . . . . 88
porte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 accder une caractristique redfinie (oclAs-
synchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Type()) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
trouv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142 allInstances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Mise en uvre dUML . . . . . . . . . . . . . . . . . . . . . . 159168 asBag() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Modle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 asOrderedSet() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
cycle de vie en cascade . . . . . . . . . . . . . . . . . . . . . . 16 asSequence() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
cycle de vie en spirale . . . . . . . . . . . . . . . . . . . . . . . 18 body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
cycle de vie en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 collect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
cycles de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
incrment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Pourquoi modliser ? . . . . . . . . . . . . . . . . . . . . . . . . 14 contexte (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Qui doit modliser ? . . . . . . . . . . . . . . . . . . . . . . . . . 14 count(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Multiplicit def . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
relation dassociation . . . . . . . . . . . . . . . . . . . . . . . . 31 dfinition dattributs et de mthode (def et let. . .in)
Mthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46, 49 85
abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 est un langage typ . . . . . . . . . . . . . . . . . . . . . . . . . . 88
de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 excludes() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
de la classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 excludesAll() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 excluding() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
exists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
N forAll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Nud includes() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
daction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 includesAll() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
dactivit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 including() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
dactivit structure . . . . . . . . . . . . . . . . . . . . . . . . 122 init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
dobjet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 initialisation (init) . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

INDEX
intersection() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 P
inv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
invariants (inv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 35
isEmpty() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Partitions (diagramme dactivits) . . . . . . . . . . . . . . . 127
let . . .in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Pin
navigation depuis une classe association . . . . . 90 dentre (diagramme dactivits) . . . . . . . . . . . 125
navigation vers une classe association . . . . . . . 90 de sortie (diagramme dactivits) . . . . . . . . . . . 125
navigation via une association . . . . . . . . . . . . . . . 89 de valeur (diagramme dactivits) . . . . . . . . . . 125
navigation via une association qualifie . . . . . . 89 Point de choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105107
notEmpty(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 point de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
oclAsType() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 point de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
oclInState() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Point de dcision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Point de jonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
oclIsKindOf() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Points de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
oclIsNew() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Polymorphisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
oclIsTypeOf() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Port (diagramme de composants) . . . . . . . . . . . . . . . . 152
oprateurs prdfinis . . . . . . . . . . . . . . . . . . . . . . . . 87
Porte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
opration sur les classes . . . . . . . . . . . . . . . . . . . . . 92
Proprit (terminaison dassociation) . . . . . . . . . . . . . 52
oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8788 Proprits
oprations collect . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 dune classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
oprations exists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 structurelles dune classe . . . . . . . . . . . . . . . . . . . . 46
oprations forAll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
oprations reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Q
oprations select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Qualificatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
oprations prdfinies sur tous les objets . . . . 91
oprations sur les collections . . . . . . . . . . . . . 9296 R
oprations sur les ensembles . . . . . . . . . . . . . . . . 93 Relation
oprations sur les lments dune collection . 94 instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
post . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Relation dagrgation
postconditions (post). . . . . . . . . . . . . . . . . . . . . . . . .84 classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
pre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 implmentation en Java . . . . . . . . . . . . . . . . . . . . . 68
product() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 59
prconditions (pre) . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Relation dassociation
prcdence des oprateurs. . . . . . . . . . . . . . . . . . .96 acteur cas dutilisation . . . . . . . . . . . . . . . . . . . . 31
reject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 binaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
rgles de prcdence des oprateurs . . . . . . . . . 96 cardinalit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
rsultat dune mthode (body) . . . . . . . . . . . . . . . 85 classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5259
select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 implmentation en Java . . . . . . . . . . . . . . . . . . 6668
self . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88, 92 implmentation en SQL . . . . . . . . . . . . . . . . . . 6971
size() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 multiplicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31, 53
sum() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 n-aire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
navigabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8788
qualificatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
types du modle UML . . . . . . . . . . . . . . . . . . . . . . . 87
reprsentation graphique . . . . . . . . . . . . . 31, 52, 53
types prdfinis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Relation dassociation qualifie
typologie des contraintes . . . . . . . . . . . . . . . . . 8286
classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
union() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Relation dextension
-> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Relation dhritage
: : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Oprateur implmentation en SQL . . . . . . . . . . . . . . . . . . . . . 71
alt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 60
loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Relation dinclusion
opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
par . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Relation de composition
strict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Opration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 implmentation en Java . . . . . . . . . . . . . . . . . . . . . 68
implmentation en Java . . . . . . . . . . . . . . . . . . . . . 65 reprsentation graphique . . . . . . . . . . . . . . . . . . . . 60
implmentation en SQL . . . . . . . . . . . . . . . . . . . . . 69 Relation de dpendance

INDEX
classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
reprsentation graphique . . . . . . . . . . . . . . . . 33, 61
Relation de dpendance dinstanciation . . . . . . . . . . . 64
Relation de gnralisation
acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
diagramme de cas dutilisation . . . . . . . . . . . 33, 34
implmentation en SQL . . . . . . . . . . . . . . . . . . . . . 71
reprsentation graphique . . . . . . . . . . . . . . . . 34, 60
Relation de spcialisation
acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 34
Ralisation dune interface
implmentation en Java . . . . . . . . . . . . . . . . . . . . . 66
S
Spcialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
acteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 34
Standish Group (tude du) . . . . . . . . . . . . . . . . . . . . . . . 11
Strotype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Squence
diagramme de squence . . . . . . . . . . . . . . . 139146
T
Terminaison dassociation . . . . . . . . . . . . . . . . . . . . . 46, 51
possession . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
propritaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
proprit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103105
condition de garde . . . . . . . . . . . . . . . . . . . . . . . . . 104
dachvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
diagramme dactivits . . . . . . . . . . . . . . . . . . . . . . 119
effet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Typologie des contraintes OCL . . . . . . . . . . . . . . . . 8286
U
Utilisation dinteraction . . . . . . . . . . . . . . . . . . . . . . . . . 146
V
Visibilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Cours UML PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours UML PDF

Transféré par

Droits d'auteur :

Formats disponibles

UML 2

Institut Universitaire de Technologie de Villetaneuse Dpartement Informatique

Les techniques de programmation nont cess de progresser depuis lpoque de la program-

4 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

1 Introduction la modlisation objet 11

2 Diagramme de cas dutilisation 29

2.3.2 Relations entre cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

3.6.3 Implmentation en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4 Object constraint langage (OCL) 77

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 7

6 Diagramme dactivits 117

8 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

6.4.1 Nud initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7 Diagrammes dinteraction 135

8 Diagrammes de composants et de dploiement 151

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 9

8.2.4 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

9 Mise en uvre dUML 159

10 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

Introduction la modlisation objet

1.1 Le gnie logiciel

1.1.2 Les logiciels

31, 1% ont t purement abandonns durant leur dveloppement.

1.1.3 Le gnie logiciel

12 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

1.1.4 Notion de qualit pour un logiciel

1.2 Modlisation, cycles de vie et mthodes

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 13

Modle mtorologique partir de donnes dobservation (satellite, . . .), il permet de prvoir

Qui doit modliser ?

14 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

Matrise douvrage et matrise duvre

1.2.2 Le cycle de vie dun logiciel

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 15

Spcifications ou conception gnrale Il sagit de llaboration des spcifications de larchi-

1.2.3 Modles de cycles de vie dun logiciel

Modle de cycle de vie en V

16 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

F. 1.1 Modle du cycle de vie en cascade

F. 1.2 Modle du cycle de vie en V

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 17

Modle de cycle de vie en spirale

Modle par incrment

1.2.4 Mthodes danalyse et de conception

18 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

1.3 De la programmation structure lapproche oriente objet

F. 1.3 Reprsentation graphique dune approche fonctionnelle

Les mthodes fonctionnelles (galement qualifies de mthodes structures) trouvent leur

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 19

1.3.2 Lapproche oriente objet

1.3.3 Approche fonctionnelle vs. approche objet

20 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

1.3.4 Concepts importants de lapproche objet

Lencapsulation consiste masquer les dtails dimplmentation dun objet, en dfinissant

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 21

Hritage, Spcialisation, Gnralisation et Polymorphisme

1.3.5 Historique la programmation par objets

22 UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/

1.4.2 Histoire des modlisations par objets

UML 2 Laurent Audibert http://laurent-audibert.developpez.com/Cours-UML/ 23

1.4.3 UML en uvre

Diagramme de cas dutilisation