Cours UML PDF

UML 2.
0
(IUT, dpartement informatique, 1re anne)
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
Avant-propos
Les techniques de programmation nont cess de progrsser depuis lpoque de la programmation en
langage binaire (cartes perfores, switch) nos jours. Cette volution a toujours t dicte par le besoin
de concevoir et de maintenir des applications toujours plus complexes.
La programmation par cartes perfores, switch ou cablage (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 developper,
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 developper 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
coeur 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 dapplications 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. Dimportant 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 la fin 2006
est UML 2.0 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.0 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), 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. Muller et Gaertner (2000) est
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.
Enfin, Roques et Valle (2003) nous montre une mise en pratique de la version 1.4 dUML dtaille au
travers dun projet rel. 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

1.1 Le gnie logiciel . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Linformatisation . . . . . . . . . . . . . . . . . . . . .
1.1.2 Les logiciels . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3 Le gnie logiciel . . . . . . . . . . . . . . . . . . . . . .
1.1.4 Notion de qualit pour un logiciel . . . . . . . . . . .
1.2 Pourquoi et comment modliser ? . . . . . . . . . . . . . . . .
1.2.1 Notions de modle et de modlisation . . . . . . . . .
1.2.2 Le cycle de vie dun logiciel . . . . . . . . . . . . . . .
1.2.3 Modles de cycles de vie dun logiciel . . . . . . . . .
1.2.4 Mthodes danalyse et de conception . . . . . . . . .
1.3 De la programmation structure lapproche oriente objet .
1.3.1 Mthodes fonctionnelles ou structures . . . . . . . .
1.3.2 Lapproche oriente objet . . . . . . . . . . . . . . . .
1.3.3 Approche fonctionnelle vs. approche objet . . . . . .
1.3.4 Concepts importants de lapproche objet . . . . . . .
1.3.5 Historique la programmation par objets . . . . . . . .
1.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Histoire des modlisations par objets . . . . . . . . .
1.4.3 UML en uvre . . . . . . . . . . . . . . . . . . . . . .
1.4.4 Comment prsenter un modle UML ? . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
12
12
13
13
14
15
17
18
18
18
19
19
20
20
20
21
21
23
Diagramme de cas dutilisation

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 lments des diagrammes de cas dutilisation . . . . . . . .
2.2.1 Acteur . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Cas dutilisation . . . . . . . . . . . . . . . . . . . . .
2.2.3 Reprsentation dun diagramme de cas dutilisation
2.3 Relations dans les diagrammes de cas dutilisation . . . . .
2.3.1 Relations entre acteurs et cas dutilisation . . . . . .
2.3.2 Relations entre cas dutilisation . . . . . . . . . . . .
2.3.3 Relations entre acteurs . . . . . . . . . . . . . . . . .
2.4 Notions gnrales du langage UML . . . . . . . . . . . . .
2.4.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Strotype . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Classeur . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.4 Paquetage . . . . . . . . . . . . . . . . . . . . . . . .
2.4.5 Espace de noms . . . . . . . . . . . . . . . . . . . . .
2.5 Modlisation des besoins avec UML . . . . . . . . . . . . .
2.5.1 Comment identifier les acteurs ? . . . . . . . . . . .
2.5.2 Comment recenser les cas dutilisation ? . . . . . . .
2.5.3 Description textuelle des cas dutilisation . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
25
25
26
26
26
26
28
29
30
30
30
31
31
31
31
31
32
32
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIRES
2.5.4
2.5.5
2.5.6
3
Description avec des diagrammes dynamiques simples . . . . . . . . . . . . . . . .

Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les Use case Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagramme de classes
3.1 Introduction . . . . . . . . . . . . . . . . . . . .
3.2 Les classes . . . . . . . . . . . . . . . . . . . . .
3.2.1 Notions de classe et dinstance de classe
3.2.2 Notions de proprits . . . . . . . . . .
3.2.3 Reprsentation graphique . . . . . . . .
3.2.4 Encapsulation, visibilit, interface . . .
3.2.5 Nom dune classe . . . . . . . . . . . . .
3.2.6 Les attributs . . . . . . . . . . . . . . . .
3.2.7 Les mthodes . . . . . . . . . . . . . . .
3.2.8 Classe active . . . . . . . . . . . . . . . .
3.3 Relations entre classes . . . . . . . . . . . . . .
3.3.1 Gnralisation et Hritage . . . . . . . .
3.3.2 Association . . . . . . . . . . . . . . . .
3.3.3 Multiplicit ou cardinalit . . . . . . . .
3.3.4 Navigabilit . . . . . . . . . . . . . . . .
3.3.5 Qualification . . . . . . . . . . . . . . .
3.3.6 Classe-association . . . . . . . . . . . .
3.3.7 Agrgation . . . . . . . . . . . . . . . .
3.3.8 Composition . . . . . . . . . . . . . . . .
3.3.9 Dpendance . . . . . . . . . . . . . . . .
3.4 Interfaces . . . . . . . . . . . . . . . . . . . . . .
3.5 laboration dun diagramme de classes . . . .
3.6 Diagramme dobjets . . . . . . . . . . . . . . .
3.6.1 Prsentation . . . . . . . . . . . . . . . .
3.6.2 Reprsentation . . . . . . . . . . . . . .
3.6.3 Relation de dpendance dinstanciation
33
33
33
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
35
35
36
36
37
37
37
38
39
39
39
40
41
41
42
43
44
44
44
44
45
45
45
46
46
Object constraint langage (OCL)

4.1 Expression des contraintes en UML . . . . . . . . . . . . . . . . .
4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 criture des contraintes . . . . . . . . . . . . . . . . . . .
4.1.3 Reprsentation des contraintes et contraintes prdfinies
4.2 Intrt dOCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 OCL Introduction . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Illustration par lexemple . . . . . . . . . . . . . . . . . .
4.3 Typologie des contraintes OCL . . . . . . . . . . . . . . . . . . .
4.3.1 Diagramme support des exemples illustratifs . . . . . . .
4.3.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 Invariants (inv) . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 Prconditions et postconditions (pre, post) . . . . . . . . .
4.3.5 Rsultat dune mthode (body) . . . . . . . . . . . . . . .
4.3.6 Dfinition dattributs et de mthodes (def et let. . .in) . . .
4.3.7 Initialisation (init) et volution des attributs (derive) . . .
4.4 Types et oprations utilisables dans les expressions OCL . . . .
4.4.1 Types et oprateurs prdfinis . . . . . . . . . . . . . . .
4.4.2 Types du modle UML . . . . . . . . . . . . . . . . . . . .
4.4.3 OCL est un langage typ . . . . . . . . . . . . . . . . . . .
4.4.4 Collections . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Accs aux proprits et aux objets . . . . . . . . . . . . . . . . . .
4.5.1 Accs aux attributs et aux oprations (self ) . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
47
47
47
49
49
49
51
51
52
53
53
54
54
55
55
55
56
56
57
57
57
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIRES
4.6
4.7
5
4.5.2 Navigation via une association . . . . . . . . .

4.5.3 Navigation via une association qualifie . . . .
4.5.4 Navigation vers une classe association . . . . .
4.5.5 Navigation depuis une classe association . . .
4.5.6 Accder une proprit redfinie (oclAsType())
4.5.7 Proprits prdfinies sur tous les objets . . .
4.5.8 Proprits sur les classes . . . . . . . . . . . . .
Oprations sur les collections . . . . . . . . . . . . . .
4.6.1 Introduction : ., ->, : : et self . . . . . . .
4.6.2 Oprations de base sur les collections . . . . .
4.6.3 Opration sur les lments dune collection . .
4.6.4 Rgles de prcdence des oprateurs . . . . . .
Exemples de contraintes . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
58
59
59
59
59
60
60
60
61
62
63
64
Diagramme dtats-transitions
5.1 Introduction au formalisme . . . . . . . . .
5.1.1 Prsentation . . . . . . . . . . . . . .
5.1.2 Notion dautomate tats finis . . .
5.1.3 Diagrammes dtats-transitions . . .
5.2 tat . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Les deux acceptions du terme tat .
5.2.2 tat initial et final . . . . . . . . . . .
5.3 vnement . . . . . . . . . . . . . . . . . . .
5.3.1 Notion dvnement . . . . . . . . .
5.3.2 vnement de type signal (signal) .
5.3.3 vnement dappel (call) . . . . . . .
5.3.4 vnement de changement (change)
5.3.5 vnement temporel (after ou when)
5.4 Transition . . . . . . . . . . . . . . . . . . .
5.4.1 Dfinition et syntaxe . . . . . . . . .
5.4.2 Condition de garde . . . . . . . . . .
5.4.3 Effet dune transition . . . . . . . . .
5.4.4 Transition externe . . . . . . . . . . .
5.4.5 Transition dachvement . . . . . . .
5.4.6 Transition interne . . . . . . . . . . .
5.5 Point de choix . . . . . . . . . . . . . . . . .
5.5.1 Point de jonction . . . . . . . . . . .
5.5.2 Point de dcision . . . . . . . . . . .
5.6 tats composites . . . . . . . . . . . . . . . .
5.6.1 Prsentation . . . . . . . . . . . . . .
5.6.2 Transition . . . . . . . . . . . . . . .
5.6.3 tat historique . . . . . . . . . . . .
5.6.4 Interface : les points de connexion .
5.6.5 Concurrence . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
67
67
67
68
68
68
69
69
69
70
70
70
71
71
71
71
71
71
72
72
73
73
73
73
73
75
76
76
77
Diagramme dactivits
6.1 Introduction au formalisme
6.1.1 Introduction . . . . .
6.1.2 Action . . . . . . . .
6.1.3 Activit . . . . . . .
6.1.4 Groupe dactivits .
6.1.5 Nud dactivit . . .
6.1.6 Transition . . . . . .
6.2 Nud excutable . . . . . .
6.2.1 Nud daction . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
79
79
80
80
80
82
82
82
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIRES
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Diagrammes dinteraction
7.1 Prsentation du formalisme . . . . . . . .
7.1.1 Introduction . . . . . . . . . . . . .
7.1.2 Classeur structur . . . . . . . . .
7.1.3 Collaboration . . . . . . . . . . . .
7.1.4 Interactions et lignes de vie . . . .
7.1.5 Reprsentation gnrale . . . . . .
7.2 Diagramme de communication . . . . . .
7.2.1 Reprsentation des lignes de vie .
7.2.2 Reprsentation des connecteurs . .
7.2.3 Reprsentation des messages . . .
7.3 Diagramme de squence . . . . . . . . . .
7.3.1 Reprsentation des lignes de vie .
7.3.2 Reprsentation des messages . . .
7.3.3 Fragments dinteraction combins
7.3.4 Utilisation dinteraction . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
. 93
. 93
. 93
. 94
. 94
. 95
. 95
. 95
. 96
. 96
. 96
. 96
. 96
. 99
. 101
Diagrammes de composants et de dploiement

8.1 Introduction . . . . . . . . . . . . . . . . . . . .
8.2 Diagrammes de composants . . . . . . . . . . .
8.2.1 Pourquoi des composants ? . . . . . . .
8.2.2 Notion de composant . . . . . . . . . .
8.2.3 Notion de port . . . . . . . . . . . . . .
8.2.4 Diagramme de composants . . . . . . .
8.3 Diagramme de dploiement . . . . . . . . . . .
8.3.1 Objectif du diagramme de dploiement
8.3.2 Reprsentation des nuds . . . . . . . .
8.3.3 Notion dartefact (artifact) . . . . . . . .
8.3.4 Diagramme de dploiement . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
103
103
103
103
105
105
105
107
107
107
107
109
Mise en uvre dUML

9.1 Introduction . . . . . . . . . . . . . . . . .
9.1.1 UML nest pas une mthode . . .
9.1.2 Une mthode simple et gnrique
9.2 Identification des besoins . . . . . . . . .
9.2.1 Diagramme de cas dutilisation . .
9.2.2 Diagrammes de squence systme
9.2.3 Maquette de lIHM . . . . . . . . .
9.3 Phases danalyse . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
111
111
112
112
112
113
113
113
6.3
6.4
6.5
6.6
7
6.2.2 Nud dactivit structure . . .

Nud de contrle . . . . . . . . . . . . .
6.3.1 Nud initial . . . . . . . . . . . .
6.3.2 Nud final . . . . . . . . . . . .
6.3.3 Nud de dcision et de fusion .
6.3.4 Nud de bifurcation et dunion
Nud dobjet . . . . . . . . . . . . . . .
6.4.1 Introduction . . . . . . . . . . . .
6.4.2 Pin dentre ou de sortie . . . . .
6.4.3 Pin de valeur . . . . . . . . . . .
6.4.4 Flot dobjet . . . . . . . . . . . . .
6.4.5 Nud tampon central . . . . . .
6.4.6 Nud de stockage des donnes
Partitions . . . . . . . . . . . . . . . . . .
Exceptions . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
82
83
83
85
85
86
86
86
86
87
87
87
87
89
90
TABLE DES MATIRES
9.4
9.5
9.3.1 Modle du domaine . . . . . . . . . .

9.3.2 Diagramme de classes participantes .
9.3.3 Diagrammes dactivits de navigation
Phase de conception . . . . . . . . . . . . . .
9.4.1 Diagrammes dinteraction . . . . . . .
9.4.2 Diagramme de classes de conception
Phase dimplmentation . . . . . . . . . . . .
9.5.1 Implmentation en Java . . . . . . . .
9.5.2 Implmentation en SQL . . . . . . . .
Bibliographie
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
113
115
117
117
117
119
120
120
123
127
10
TABLE DES MATIRES
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 maintenant
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 relativement 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,
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.
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
12
CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET
Lexamen des causes de succs et dchec est instructif : la plupart des checs proviennent non de
linformatique, mais de la matrise douvrage3 , en comprenant sous ce terme la fois les dirigeants et les
concepteurs des mtiers.
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. Limportance 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,
la maintenance.
Les projets relatifs lingnierie logicielle sont gnralement de grande envergure et dpassent
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 :
3
c.f. section 1.2.1 Matrise douvrage et matrise duvre pour une dfinition de ce terme.
Souvent, les personnes qui doivent oprer des modifications ultrieures dans le code ne sont plus les personnes qui lont
dvelopp.
4
1.2. POURQUOI ET COMMENT MODLISER ?
13
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 anormales.
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, dinterprtation
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
Pourquoi et comment modliser ?
1.2.1
Notions de modle et de modlisation
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 prdictifs :
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 comportement,
dans le but de fiabiliser des tudes statistiques, daugmenter limpact de dmarches commerciales,
etc.
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
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
14
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 nontriviaux sont mieux modliss par un ensemble de modles indpendants. Selon les modles employs,
la dmarche de modlisation nest pas la mme.
Qui doit modliser ?
La modlisation est souvent faite par la matrise duvre informatique (MOE). Cest malencontreux,
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 les mtiers, dont les priorits sont oprationnelles, ne disposent pas toujours de la
capacit dabstraction, de la rigueur conceptuelle ncessaires la formalisation. La professionnalisation
de la MOA a pour but de les doter de ces comptences. Cette professionnalisation rside essentiellement
dans 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 fournisseurs. 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 assurant le respect des dlais fixs par le
MOA et en minimisant les risques.
Le MOE est responsable de la qualit technique de la solution. Il doit, avant toute livraison au MOA,
procder aux vrifications ncessaires ( recette usine ).
1.2.2
Le cycle de vie dun logiciel
Le cycle de vie dun logiciel (en anglais software lifecycle), dsigne toutes les tapes du dveloppement
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.
15
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 a minima 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.
Spcification ou conception gnrale Il sagit de llaboration des spcifications de larchitecture 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 programmation
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 spcifications
initiales.
Documentation Elle vise produire les informations ncessaires pour lutilisation du logiciel et pour
des dveloppements ultrieurs.
Mise en production
Maintenance Elle comprend toutes les actions correctives (maintenance corrective) et volutives
(maintenance volutive) sur le logiciel.
La squence et la prsence de chacune de ces activits dans le cycle de vie 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 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.
Modle de cycle de vie en V
Le modle en V demeure actuellement le cycle de vie le plus connu et certainement le plus utilis.
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.
Ceci rend explicite la prparation des dernires phases (validation-vrification) par les premires
(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 ralisation.
16
F. 1.1 Modle du cycle de vie en cascade
F. 1.2 Modle du cycle de vie en V
17
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 maquettes
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 sparment 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 grace la possibilit de
recouvrement (paralllisation) des diffrentes phases.
Les risques de ce type de modle sont les suivants :
remettre en cause les incrments prcdents ou pire le noyau ;
ne pas pouvoir intgrer de nouveaux incrments.
Les noyaux, les incrments ainsi que leurs interactions doivent donc tre spcifis globalement, au
dbut du projet. Les incrments doivent tre aussi indpendants que 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 :
La distinction entre composition et dcomposition : Elle met en opposition dune part les mthodes
ascendantes qui consistent construire un logiciel par composition partir de modules existants
et, dautre part, les mthodes descendantes qui dcomposent rcursivement le systme jusqu
arriver des modules programmables simplement.
La distinction entre fonctionnel (dirige par le traitement) et oriente objet : Dans la stratgie fonctionnelle (galement qualifie de structure) un systme est vu comme un ensemble hirarchique
dunits en interaction, ayant chacune une fonction clairement dfinie. 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 considrent quun systme est un ensemble dobjets interagissants. Chaque objet dispose dun ensemble dattributs dcrivant son tat et ltat du systme
est dcrit (de faon dcentralise) par ltat de lensemble.
18
1.3
1.3.1
De la programmation structure lapproche oriente objet

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 spcifications
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 respectant 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.
1.3.2
Lapproche oriente objet
Lapproche oriente objet considre le logiciel comme une collection dobjets dissocis, et identifis,
dfinis par des proprits. Une proprit est soit un attribut (i.e. une donne caractrisant ltat de
lobjet), entit lmentaire comportementale de lobjet). La fonctionnalit du logiciel merge alors de
linteraction entre les diffrents objets qui le constituent. 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, indpendamment
de son tat. On construit gnralement cette identit grce un identifiant dcoulant naturellement
du problme (par exemple un produit pourra tre repr par un code, une voiture par un numro
de srie, etc.)
Les attributs Il sagit des donnes caractrisant lobjet. Ce sont des variables stockant des informations
sur ltat de lobjet.
1.3. DE LA PROGRAMMATION STRUCTURE LAPPROCHE ORIENTE OBJET
19
Les mthodes Les mthodes dun objet caractrisent son comportement, cest--dire lensemble 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 objets). De plus, les oprations
sont troitement lies aux attributs, car leurs actions peuvent dpendre des valeurs des attributs,
ou bien les modifier.
La difficult de cette modlisation consiste crer une reprsentation abstraite, sous forme 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 logicielles fondes
sur les objets du systme, plutt que sur la fonction quil est cens raliser.
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 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 sousfonctions) 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, dmarche qui
vise matriser sa production et son volution. Mais malgr cette continuit logique les langages objet
ont apport en pratique un profond changement dans lart de la programmation : 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.
20
Notion de classe
Tout dabord, introduisons la notion de classe. Une classe est un type de donnes abstrait, caractris
par des proprits (attributs et mthodes) communes toute une famille dobjets et permettant de
crer (instancier) des objets possdant ces proprits. 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 restreindre, laccs
direct aux attributs des objets.
Hritage, Spcialisation, Gnralisation et polymorphisme
Lhritage est un mcanisme de transmission des proprits 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 programmation
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
1.4.1
UML
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.
1.4. UML
21
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 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 traitement) 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 immdiatement compris par les informaticiens.
En principe seulement, car la modlisation demande aux matrises douvrage une comptence, 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 utilisateurs (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 mthode : cest
un langage.
Lunification a progresse 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 la
fin 2006 est UML 2.0 et les travaux damlioration se poursuivent.
UML est donc non seulement un outil intressant mais une norme qui simpose en technologie 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, de
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
22
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 juxtaposition 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 produits loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les diagrammes 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.
Le diagramme de cas dutilisation (cf. section 2) reprsente la structure des grandes fonctionnalits
ncessaires aux utilisateurs du systme. Cest le premier diagramme du modle UML, celui o sassure
la relation entre lutilisateur et les objets que le systme met en uvre.
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.6) permet dclairer un diagramme de classes en lillustrant
par des exemples. Il est, par exemple, utilis pour vrifier ladquation dun diagramme de classes
diffrents cas possibles.
1.4. UML
23
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 reprsentation 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.).
24
Chapitre 2

(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
2.2.1
lments des diagrammes de cas dutilisation

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.
F. 2.1 Exemple de reprsentation dun acteur
Il est galement possible de reprsenter un acteur sous la forme dun classeur (cf. section 2.4.3)
strotyp (cf. section 2.4.2) actor (figure 2.2).
25
26
CHAPITRE 2. DIAGRAMME DE CAS DUTILISATION
F. 2.2 Exemple de reprsentation dun acteur sous la forme dun classeur
2.2.2
Cas dutilisation
Un cas dutilisation est une unit cohrente dune fonctionnalit visible de lextrieur. Il ralise un
service de bout en bout, avec un dclenchement, un droulement et une fin, 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.2).
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
2.3.1
Relations dans les diagrammes de cas dutilisation

Relations entre acteurs et cas dutilisation
Relation dassociation
Une relation dassociation est chemin de communication entre un acteur et un cas dutilisation et est
reprsent un trait continu (cf. figure 2.5 ou 2.6).
2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION
27
F. 2.5 Exemple simplifi de diagramme de cas dutilisation modlisant une borne daccs une
banque.
F. 2.6 Diagramme de cas dutilisation reprsentant un logiciel de partage de fichiers
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.3.
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.
28
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 :
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
2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION
29
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, car il 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 ventuellement 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 lextension 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.
30
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 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
Note
F. 2.10 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.10 montre une note exprimant une contrainte (cf. section 4.1) sur un attribut.
2.4.2
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.
2.5. MODLISATION DES BESOINS AVEC UML
31
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.3
Classeur
Un classeur est un lment de modle qui dcrit une unit comportementale ou structurelle.
Un classeur modlise un concept discret qui dcrit un lment (i.e. objet) dot dune identit (i.e. un
nom), dun tat (i.e. des attributs), dun comportement (i.e. des 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 retrouverons le
terme de classeur car cette notion englobe aussi les classes, des parties dun systme, etc.
2.4.4
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.
Les lments contenus dans un paquetage doivent reprsenter un ensemble fortement cohrent et
sont gnralement de mme nature et de mme niveau smantique.
Gnralement, il existe un seul paquetage racine qui dtient la totalit du modle dun systme.
2.4.5
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.5
2.5.1
Modlisation des besoins avec UML

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, . . .) 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 :
32
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 quactera 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 difficult de
trouver le bon niveau de dtail, il faut tre trs vigilant pour ne pas retomber dans une dcomposition
fonctionnelle descendante hirarchique. Un nombre trop important de cas 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.5. MODLISATION DES BESOINS AVEC UML
33
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 techniques, . . .). Elle
peut ventuellement contenir une description des besoins en termes dinterface graphique.
2.5.4
Description avec des diagrammes dynamiques simples
2.5.5
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.
2.5.6
Les Use case Realization (pour aller plus loin que le cours . . .)
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 ?
34
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 comportement 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 indpendamment 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
3.2.1
Les classes
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 :
des lments concrets (ex : des avions),
des lments abstraits ( ex : des commandes),
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.
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.
35
36
CHAPITRE 3. DIAGRAMME DE CLASSES
Tout systme orient objet est organis autour des classes.

Une classe est la description formelle dun ensemble dobjets ayant une smantique et des proprits
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
Notions de proprits
Une classe dfinit un jeu dobjets dots de proprits. Les proprits 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 proprits dun objet
taient soit des attributs, soit des oprations. Ce nest pas exact dans un diagramme de classe car les
terminaisons dassociations font galement partie des proprits dun objet au mme titre que les attributs et les
opration.
tat dun objet : Ce sont les attributs et les terminaisons dassociations (cf. section 3.3.2) qui dcrivent
ltat dun objet. On utilise les attributs pour des valeurs de donnes pures, dpourvues didentit,
telles que les nombres et les chanes de caractres. On utilise les associations pour connecter les
classes du diagramme de classe. Dans ce cas, la terminaison de lassociation (du ct de la classe
cible) est une proprit de la classe de base.
Les proprits dcrites par les attributs prennent des valeurs lorsque la classe est instancie.
Linstance dune association est appele un lien.
Comportement dun objet : Les oprations dcrivent les lments individuels dun comportement 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.
Les attributs, les terminaisons dassociation et les mthodes constituent donc les proprits dune
classe (et de ses instances).
3.2.3
Reprsentation graphique
Une classe est un classeur 2 . Elle est reprsente par un rectangle divis en trois cinq compartiments
(figure 3.1).
F. 3.1 Reprsentation UML dune classe

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.
2 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.
3.2. LES CLASSES
3.2.4
37
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 mcanisme 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 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 ses proprits (attributs, terminaisons
dassociation et opration). Il permet dindiquer si une autre classe peut accder ses proprits.
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 de mthodes (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>], ... } ]
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
38
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. Lorsquun 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 dun opration contient les types des paramtres et le type de la valeur de retour, sa
syntaxe est la suivante :
<visibilit> <nom_mthode> ( [ <paramtre> [, <paramtre> [, <paramtre>
[<valeur_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 disponibles 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 complmentaires comme les exceptions, les prconditions, les postconditions ou encore lindication quune mthode
est abstraite (mot-clef abstract), etc.
3.3. RELATIONS ENTRE CLASSES
39
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.1) contient une mthode abstraite non encore ralise.
On ne peut instancier une classe abstraite : elle est voue se spcialiser (cf. section 3.3.1). 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.
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
Gnralisation et Hritage
F. 3.3 Partie du rgne animal dcrit avec lhritage multiple.

La gnralisation dcrit une relation entre une classe gnrale (classe de base ou classe parent) et
une classe spcialise (sous-classe). La classe spcialise est intgralement cohrente avec la classe de
base, mais comporte des informations supplmentaires (attributs, oprations, associations). Un objet de
la classe spcialise peut tre utilis partout o un objet de la classe de base est autoris.
Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de gnralisation
se traduit par le concept dhritage. On parle galement de relation dhritage. Ainsi, lhritage permet
la classification des objets (cf. figure 3.3).
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.3).
Les proprits principales de lhritage sont :
La classe enfant possde toutes les proprits des ses classes parents, mais elle ne peut accder aux
proprits prives de celle-ci.
40
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.3, 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.3). 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 ou les cas dutilisation (cf. section 2.3.2).
3.3.2
Association
Une association est une relation entre deux classes (association binaire) ou plus (association n-aire),
qui dcrit les connexions structurelle entre leurs instances.
Terminaison dassociation vs. attribut
Un attribut est une association dgnre dans laquelle une terminaison dassociation3 est dtenue
par un classeur (gnralement une classe). Le classeur dtenant cette terminaison dassociation devrait
thoriquement se trouver lautre terminaison, non modlise, de lassociation. Un attribut nest donc
rien dautre quune terminaison dun cas particulier dassociation.
Les terminaisons dassociations et les attributs sont donc deux lments conceptuellement trs
proches que lon regroupe sous le terme de proprit structurelle.
Une proprit structurelle peut tre paramtre par les lments suivant :
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 multiplicit. 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.3).
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.4).
Association binaire
F. 3.4 Exemple dassociation binaire.

3 Une terminaison dassociations est une extrmit de lassociation. Une association binaire en possde deux, une association
n-aire en possde n
41
Une association binaire est matrialise par un trait plein entre les classes associes (cf. figure 3.4).
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.
Association n-aire
F. 3.5 Exemple dassociation n-aire.
Une association n-aire lie plus de deux classes. La section 3.3.3 dtaille comment interprter les
multiplicits dune association n-aire. La ligne pointill dune classe-association (cf. section 3.3.6) 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.5). Le nom de lassociation, le cas chant, apparat proximit du losange.
3.3.3
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 dassociation. 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.4), 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 sapplique 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.6) avec une
paire particulire dobjets A et B.
Remarque
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.4
Navigabilit
La navigabilit indique sil est possible de traverser une association. On reprsente graphiquement
la navigabilit par une flche du ct de la terminaison navigable et on empche la navigabilit par une
croix du ct de la terminaison non navigable (cf. figure 3.6). Par dfaut, une association est navigable
dans les deux sens.
Par exemple, sur la figure 3.6, 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.
42
F. 3.6 Navigabilit.
Inversement, la terminaison du ct de la classe Produit est navigable : chaque objet commande contient
une liste de produits.
F. 3.7 Implicitement, ces trois notations ont la mme smantique.

Lorsque lon reprsente la navigabilit uniquement sur lune des extrmits dune association, il
faut remarquer que, implicitement, les trois associations reprsentes sur la figure 3.7 ont la mme
signification : lassociation ne peut tre traverse que dans un sens.
F. 3.8 Deux modlisations quivalentes.

Dans la section 3.3.2, nous avons dit que :
Un attribut est une association dgnre dans laquelle une terminaison dassociation est
dtenue par un classeur (gnralement une classe). Le classeur dtenant cette terminaison
dassociation devrait thoriquement se trouver lautre terminaison, non modlise, de
lassociation. Un attribut nest donc rien dautre quune terminaison dun cas particulier
dassociation.
La figure 3.8 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.5
Qualification
Gnralement, une classe peut tre dcompose en sous-classes ou possder plusieurs proprits.
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
43
F. 3.9 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.
objet qualifi) reli par une association un autre objet. Lobjet slectionn par la valeur du qualificatif
est appel objet cible. Lassociation est appel 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 considrant un
objet qualifi, chaque valeur de qualificatif dsigne un objet cible unique.
Par exemple, le diagramme de gauche de la figure 3.9 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}.
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.6
Classe-association
F. 3.10 Exemple de classe-association.
Une classe-association possde les proprits des associations et des classes : elle se connecte deux
ou plusieurs classes et possde galement des attributs et des oprations.
44
Une classe-association est caractrise par un trait discontinu entre la classe et lassociation quelle
reprsente (figure 3.10).
Par exemple, dans la figure 3.10, la dtention dactions est modlise en tant quassociation entre
les classes Personne et Socit. Les attributs de la classe-association Action permettent de prciser les
informations relatives chaque dtention dactions (nombre dactions, prix et date dachat).
3.3.7
Agrgation
F. 3.11 Exemple de relation dagrgation et de composition.

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.11). Contrairement une association simple, lagrgation est transitive.
3.3.8
Composition
La composition, galement appele agrgation composite, dcrit une contenance structurelle 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. Graphiquement,
on ajoute un losange plein () du ct de lagrgat (cf. figure 3.11).
3.3.9
Dpendance
F. 3.12 Exemple de relation de dpendance.

Une dpendance est une relation unidirectionnelle exprimant une dpendance smantique entre les
lments du modle. Elle est reprsente par un trait discontinu orient (cf. figure 3.12). Elle indique
que la modification de la cible implique une modification de la source. La dpendance est souvent
strotype pour mieux expliciter le lien smantique entre les lments du modle (cf. figure 3.15).
3.4
Interfaces
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.
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 interface (cf. figure 3.13).
Une interface doit tre ralise par au moins une classe. Graphiquement, cela est reprsent par un
trait discontinu termin par une flche triangulaire et le strotype realize . Une classe (classe cliente
de linterface) peut dpendre dune interface (interface requise). On reprsente cela par une relation de
dpendance et le strotype use .
3.5. LABORATION DUN DIAGRAMME DE CLASSES
45
F. 3.13 Exemple de diagramme mettant en uvre une interface
3.5
laboration dun diagramme de classes
Il y a au moins trois points de vue qui guident la modlisation (Steve Cook et John Daniels) :
Le point de vue spcification met laccent sur les interfaces des classes plutt que sur leurs contenus.
Le point de vue conceptuel capture les concepts du domaine et les liens qui les lient. Il sintresse
peu ou prou la manire ventuelle dimplmenter ces concepts et relations et aux langages
dimplmentation.
Le point de vue implmentation, le plus courant, dtaille le contenu et limplmentation de chaque
classe.
En fonction du point de vue adopt, vous obtiendrez des modles diffrents.
Une dmarche couramment utilise pour btir un diagramme de classes consiste :
Trouver les classes du domaine tudi. Cette tape empirique se fait gnralement en collaboration
avec un expert du domaine. Les classes correspondent gnralement des concepts ou des substantifs du domaine.
Trouver les associations entre classes. Les associations correspondent souvent des verbes, ou des
constructions verbales, mettant en relation plusieurs classes, comme est compos de , pilote ,
travaille pour . Attention, mfiez vous de certains attributs qui sont en ralit des relations entre classes.
Trouver les attributs des classes. Les attributs correspondent souvent des substantifs, ou des groupes
nominaux, tels que la masse 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 lhritage.
Vrifier les chemins daccs aux classes.
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
3.6.1
Diagramme dobjets (object diagram)

Prsentation
Un diagramme dobjets reprsente des objets (i.e. instances de classes) et leurs liens (i.e. instances de
relations) pour donner une vue de ltat du systme un instant donn. Un diagramme dobjets permet,
selon les situations, dillustrer le modle de classes (en montrant un exemple qui explique le modle),
de prciser certains aspects du systme (en mettant en vidence des dtails imperceptibles dans le
diagramme de classes), dexprimer une exception (en modlisant des cas particuliers, des connaissances
non gnralisables . . .), ou de prendre une image (snapshot) dun systme un moment donn. Le
diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits.
46
F. 3.14 Exemple de diagramme de classes et de diagramme dobjets associ.
Par exemple, le diagramme de classes de la figure 3.14 montre quune entreprise emploie au moins
deux personnes et quune personne travaille dans au plus deux entreprises. Le diagramme dobjets
modlise lui une entreprise particulire (OSKAD) qui emploie trois personnes.
Un diagramme dobjets ne montre pas lvolution du systme dans le temps. Pour reprsenter une
interaction, il faut utiliser un diagramme de communication (cf. section 7.2) ou de squence (cf. section
7.3).
3.6.2
Reprsentation
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. Graphiquement, un lien se reprsente comme une relation, mais, sil y a un nom, il est soulign. Naturellement,
on ne reprsente pas les multiplicits.
3.6.3
Relation de dpendance dinstanciation
F. 3.15 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.
Chapitre 4
Langage de contraintes objet

(Object Constraint Langage : OCL)
4.1
4.1.1
Expression des contraintes en UML

Introduction
Nous avons dj vu comment exprimer certaines formes de contraintes avec UML :

Contraintes structurelles : les attributs dans les classes, les diffrents types de relations entre classes
(gnralisation, association, agrgation, composition, dpendance), la cardinalit et la navigabilit
des proprits structurelles, etc.
Contraintes de type : typage des proprits, etc.
Contraintes diverses : les contraintes de visibilit, les mthodes et classes abstraites (contrainte abstract),
etc.
Dans la pratique, toutes ces contraintes sont trs utiles mais se rvlent insuffisantes. Toutefois, UML
permet de spcifier explicitement des contraintes particulires sur des lments de modle.
4.1.2
criture des contraintes
Une contrainte constitue une condition ou une restriction smantique exprime sous forme 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.
4.1.3
Reprsentation des contraintes et contraintes prdfinies
UML permet dassocier une contrainte un, ou plusieurs, lment(s) de modle de diffrentes 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 ;
47
48
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
49
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 prdfinies
({frozen}, {subset} et {xor}). Le diagramme de la figure 4.2 en introduit deux nouvelles : {ordered} et
{addOnly}. La liste est encore longue, mais le pouvoir expressif de ces contraintes reste insuffisant comme
nous le verrons dans la section 4.2.2. Le langage de contraintes objet OCL apporte une solution lgante
cette insuffisance.
4.2
4.2.1
Intrt dun langage de contraintes objet comme OCL

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 spcifications 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 lmentaire
(OCL peut tre interprt par des outils) que nous dcrirons dans les sections 4.3 4.6. OCL reprsente,
en fait, un juste milieu entre le langage naturel et un langage trs technique (langage mathmatique,
informatique, . . .). Il permet ainsi de limiter les ambiguts, tout en restant accessible.
4.2.2
Illustration par lexemple
Mise en situation
Plaons-nous dans le contexte dune application bancaire. Il nous faut donc grer :
des comptes bancaires,
50
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.
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.
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.
4.3. TYPOLOGIE DES CONTRAINTES OCL
51
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.
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.
context Compte
inv : solde > 0
context Compte :: dbiter(somme : int)

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

Diagramme support des exemples illustratifs
Le diagramme de la figure 4.8 modlise des personnes, leurs liens de parent (enfant/parent et
mari/femme) et le poste ventuel de ces personnes dans une socit. Ce diagramme nous servira de
52
F. 4.8 Diagramme de classes modlisant une entreprise et des personnes.
support aux diffrents exemples de contraintes que nous donnerons, titre dillustration, dans les
sections qui suivent (4.3 4.7).
F. 4.9 Dfinition dune numration en utilisant un classeur.
Ce diagramme introduit un nouveau type de classeur, strotyp enumeration, permettant de dfinir

une numration. Une numration est un type de donn UML, possdant un nom, et utilis pour
numrer un ensemble de littraux correspondant toutes les valeurs possibles que peut prendre une
expression de ce type. Un type numr est dfini par un classeur possdant le strotype enumeration
comme reprsent sur la figure 4.9.
4.3.2
Contexte
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).
4.3. TYPOLOGIE DES CONTRAINTES OCL
53
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.
54
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
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 lattribut, 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.
4.4. TYPES ET OPRATIONS UTILISABLES DANS LES EXPRESSIONS OCL
55
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 terminaison
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
4.4.1
Types et oprations utilisables dans les expressions OCL

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 :
56
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 <expression_logique_2>.
Type
Boolean
Integer
Real
String
Exemples de valeurs
true ; false
1 ; 5 ; 2 ; 34 ; 26524 ; . . .
1, 5 ; 3, 14 ; . . .
"To be or not to be . . ."
Oprateurs
and ; or ; xor ; not ; implies ; if-then-else-endif ; . . .
; + ; ; / ; abs() ; . . .
; + ; ; / ; abs() ; f loor() ; . . .
concat() ; size() ; substring() ; . . .
T. 4.1 Types et oprateurs prdfinis dans les contraintes OCL.
E1
vrai
vrai
faux
faux
E2
vrai
faux
vrai
faux
P1 and P2
vrai
faux
faux
faux
P1 or P2
vrai
vrai
vrai
faux
P1 xor P2
faux
vrai
vrai
faux
P1 implies P2
vrai
faux
vrai
vrai
T. 4.2 Interprtation des quatre connecteurs, E1 et E2 sont deux expressions logiques.

expression
vrai
faux
not expression
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.5. ACCS AUX PROPRITS ET AUX OBJETS
4.4.4
57
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 proprits et aux objets dans les contraintes OCL
Dans une contrainte OCL associe un objet, il est possible daccder aux proprits (attributs,
oprations et terminaison dassociation) de cet objet, et donc, daccder de manire transitive tous les
objets (et leurs proprits) 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
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 entre/sortie. Dans ce cas, le
rsultat sera un tuple contenant tous les paramtres dfinis en sortie ou en entre/sortie. Par exemple,
imaginons une opration dont la dclaration serait operation(out param_out : Integer) :Real possdant un
paramtre dfini en sortie param_out. Dans ce cas, le rsultat de 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.
58
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 (rsultat 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
F. 4.10 Diagramme illustrant une association qualifie entre une classe Banque et une classe Personne.
Une association qualifie (cf. section3.3.5) utilise un ou plusieurs qualificatifs pour slectionner 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 ([]).
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.5).
4.5. ACCS AUX PROPRITS ET AUX OBJETS
4.5.4
59
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 :
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, lexpression self.employ.age
de lexemple prcdant produit bien un singleton.
4.5.6
Accder une proprit redfinie (oclAsType())
Quand une proprit dfinie dans une classe parente est redfinie dans une sous-classe associe, la
proprit 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
Proprits prdfinies sur tous les objets
La proprit oclAsType, que nous venons de dcrire (section 4.5.6), est une proprit prdfinie dans
le langage OCL qui peut tre applique tout objet. Le langage OCL en propose plusieurs :
oclIsTypeOf (t : OclType) : Boolean
oclIsKindOf (t : OclType) : Boolean
oclInState (s : OclState) : Boolean
oclIsNew () : Boolean
oclAsType (t : OclType) : instance of OclType
Proprit oclIsTypeOf
oclIsTypeOf retourne vrai si le type de lobjet auquel cette proprit est applique 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.
60
Proprit oclIsKindOf
oclIsKindOf permet de dterminer si le type t pass en paramtre correspond exactement au type ou
un type parent du type de lobjet auquel cette proprit est applique.
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.
Proprit oclIsNew
La proprit oclIsNew doit tre utilise dans une postcondition. Elle est vraie quand lobjet auquel
elle est applique est cr pendant lopration (i.e. lobjet nexistait pas au moment des prconditions).
Proprit oclInState
Cette proprit 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
Proprits sur les classes
Toutes les proprits que nous avons dcrites jusquici sappliquaient sur des instances de classe.
Cependant, OCL permet galement daccder des proprits 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 : <nom_qualifi>.<proprit>.
Le langage OCL dispose galement dune proprit prdfinie sur les classes, les interfaces et les
numrations (allInstances) qui retourne lensemble (Set) de toutes les instances du type prcis, 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 proprits (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 proprit (attributs, terminaisons dassociations, oprations) dun objet ;
-> permet daccder une proprit 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
4.6. OPRATIONS SUR LES COLLECTIONS
61
une collection par exemple) sur lequel porte 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 loprateur
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).
Remarque :
1
les sacs (type Bag) disposent doprations analogues.
Non, il ny a pas derreur de copier/coller : rflchissez !
62
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 proprits 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 proprits 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>.
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()
4.6. OPRATIONS SUR LES COLLECTIONS
63
Opration forAll et exists

Ces deux oprations permettent de reprsenter le quantificateur universel () et le quantificateur
existentiel (). Le rsultat de ces oprations est donc du type Boolean. Leur syntaxe est la suivante :
forAll( [ <lment> [ : <Type> ] | ] <expression_logique> )
exists( [ <lment> [ : <Type> ] | ] <expression_logique> )
forAll permet 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)
64
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
F. 4.11 Reprise du diagramme de la figure 4.8.

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 .
context Personne
inv :
let revenus : Real = self.poste.salaire->sum() in
if chmeur then
revenus < 100
4.7. EXEMPLES DE CONTRAINTES
65
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
66
Chapitre 5
(State machine diagram)
5.1
5.1.1
Introduction au formalisme
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 composant), 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 sintressent
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 comportement 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 globale.
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.
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.
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
67
68
CHAPITRE 5. DIAGRAMME DTATS-TRANSITIONS
F. 5.1 Un diagramme dtats-transitions simple.
dpendra de son tat courant (de son historique) : sil la lumire est allume, elle steindra, si elle est
teinte, elle sallumera.
Remarque
Nous avons employ dans cette section le terme dtat global, qui dsigne une situation particulire
dans laquelle se trouve lensemble de lautomate tats finis, par opposition au simple terme dtat, qui
dsigne lun des tats lmentaire dun automate tats finis, pour lever toute ambigut sur la notion
dtat. Dans le cas dun diagramme dtats-transitions simple, ces deux notions se rejoignent puisquun
tel diagramme ne comporte toujours quun tat actif la fois, mais si le diagramme dtats-transitions
comporte des tats concurrents (cf. section 5.6.5), plusieurs tats peuvent tre actifs en mme temps, ltat
global tant alors caractris par lensemble des tats actifs. La section 5.2.1 donne plus dinformation
sur cette ambigut du terme tat.
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 diagrammes dtats-transitions.
Il est souhaitable de construire un diagramme dtats-transitions pour chaque classeur (qui, le plus
souvent, est une classe) possdant un comportement dynamique important. Un diagramme dtatstransitions 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
5.2.1
tat
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.
5.3. VNEMENT
69
Le nom de ltat peut tre spcifi dans le rectangles et doit tre unique dans le diagrammes dtatstransitions, ou dans ltat enveloppant. On peut lomettre, ce qui produit un tat anonyme. Il peut y
avoir un nombre quelconque dtats anonymes distincts. Un tat imbriqu peut tre identifi par son
nom qualifi (cf. section 2.4.5) 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 actif de lobjet est le jeu des tats (lmentaires) qui sont actifs un instant donn.
Si cette configuration contient plusieurs tats, il y a concurrence au sein de lobjet. Le nombre dtats
(lmentaires) 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 dtatstransitions, 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
5.3.1
vnement
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.
70
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.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.4. TRANSITION
5.3.5
71
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
5.4.1
Transition
Dfinition et syntaxe
Une transition dfinit la rponse dun objet loccurrence dun vnement. Elle lie, gnralement,
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
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.
72
F. 5.6 Reprsentation graphique dune transition externe entre deux tats.
5.4.5
Transition dachvement
Une transition dpourvue dvnement dclencheur explicite se dclenche la fin de lactivit 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
F. 5.7 Reprsentation de la saisie dun mot de passe dans un tat unique en utilisant des transitions
internes.
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 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 configuration 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 particulirement 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
5.5
73
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.
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
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
5.6.1
tats composites
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 soustats.
Quand un tat composite comporte plus dune rgion, il est qualifi dtat orthogonal. Lorsquun 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 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.
74
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.
F. 5.10 Exemple dutilisation dun point de dcision.
5.6. TATS COMPOSITES
75
F. 5.11 Exemple dtat composite modlisant la composition dun numro de tlphone.
F. 5.12 Notation abrge dun tat composite.
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.
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.
La figure 5.13 illustre une configuration complexe de transition produisant une cascade dactivits.
76
F. 5.14 Exemple de diagramme possdant un tat historique profond permettant de reprendre le

programme de lavage ou de schage dune voiture lendroit o il tait arriv avant dtre interrompu.
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.
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
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,
5.6. TATS COMPOSITES
77
F. 5.15 Exemple dutilisation de points de connexion.
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
F. 5.16 Exemple dutilisation dun tat composite orthogonal.
78
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, 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.
Chapitre 6
Diagramme dactivits
(Activity diagram)
6.1
6.1.1
Introduction au formalisme
Introduction
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. Ils 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.
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.
Les diagrammes dactivits sont galement utiles dans la phase de ralisation car ils permettent une
description si prcise des traitements quelle autorise la gnration automatique du code.
6.1.2
Action (action)
Une action est le plus petit traitement qui puisse tre exprim en UML. Une action a une incidence
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.
79
80
CHAPITRE 6. DIAGRAMME DACTIVITS
Action appeler (call operation) Laction call operation correspond linvocation dune opration 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 rception
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 exception.
Graphiquement, les actions apparaissent dans des nuds daction, dcrits section 6.2.1.
6.1.3
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.1.4
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.1.5
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) ;
6.1. INTRODUCTION AU FORMALISME
F. 6.2 Exemple de diagramme dactivits modlisant le fonctionnement dune borne bancaire.
81
82
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 comment
certains de ces nuds sont utiliss pour former un diagramme dactivits.
6.1.6
Transition
F. 6.3 Reprsentation graphique dune 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 principe sans dure perceptible.
Les transitions spcifient lenchanement des traitements et dfinissent le flot de contrle.
6.2
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.2.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 transformation 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.
Certaines actions de communication ont une notation spciale (cf. figure 6.5).
6.2.2
Nud dactivit structure (structured activity node)
Un nud dactivit structure est un nud dactivit excutable qui reprsente une portion 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.
6.3. NUD DE CONTRLE
83
F. 6.5 Reprsentation particulire des nuds daction de communication.
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 horizontale
en trait continu spare le compartiment contenant le strotype structured et le nom de lactivit
structure du corps de lactivit structure.
6.3
Nud de contrle (control node)
Un nud de contrle est un nud dactivit abstrait utilis pour coordonner les flots entre les nuds
dune activit.
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.3.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).
84
F. 6.6 Exemple de diagramme dactivit illustrant lutilisation de nuds de contrle. Ce diagramme

dcrit la prise en compte dune commande.
6.3. NUD DE CONTRLE
6.3.2
85
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.3.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).
86
6.3.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 synchronise 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.4
6.4.1
Nud dobjet (object node)

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.4.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.4. NUD DOBJET
6.4.3
87
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.4.4
Flot dobjet
F. 6.8 Deux notations possibles pour modliser un flot de donnes.

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 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.4.5
Nud tampon central (central buffer node)
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.4.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, linformation est duplique
et ne disparat pas du nud de stockage des donnes comme ce serait le cas dans un nud tampon
88
F. 6.9 Exemple dutilisation dun nud tampon central pour centraliser toutes les commandes prises
par diffrents procds, avant quelles soient traites.
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.
6.5. PARTITIONS
89
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.5
Partitions
F. 6.11 Illustration de lutilisation de nuds dobjets et de partitions dans un diagramme dactivits.
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 gnralement 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 for-
90
cment 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.6
Exceptions
F. 6.12 Notation graphique du fait quune activit peut soulever une exception.
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 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 proprits 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.
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
6.6. EXCEPTIONS
91
F. 6.14 Exemple dutilisation dun gestionnaire dexception pour protger une activit de lexception
Division_par_zero dclenche en cas de division par zro.
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.
92
Chapitre 7
(Interaction diagram)
7.1
7.1.1
Prsentation du formalisme
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 dinteraction).
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. La vue de lensemble des interactions offre une vue plus holistique1 du
comportement dun jeu dobjets.
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 un aspect dynamique la modlisation
du systme.
Le modlisateur doit pouvoir focaliser son attention sur un sous-ensemble dlments du systme
et tudier leur faon dinteragir pour dcrire un comportement particulier du systme. 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
F. 7.1 Exemple de classeur structur montrant quun classeur Moteur est en fait constitu dun objet
Allumage et de quatre objets Bougie.
Les classes dcouvertes au moment de lanalyse (celles qui figurent dans le diagramme de classes) ne
sont pas assez dtailles pour pouvoir tre implmentes par des dveloppeurs. UML propose de partir
1
Doctrine ou point de vue qui consiste considrer les phnomnes comme des totalits.
93
94
CHAPITRE 7. DIAGRAMMES DINTERACTION
des classeurs dcouverts au moment de lanalyse (tels que les classes, les sous-systmes, les cas dutilisation, . . .) et de les dcomposer en lments suffisamment fins pour permettre leur implmentation.
Les classeur ainsi dcomposs sappellent des classeurs structurs.
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 objets internes relies par des connecteurs (cf. figure 7.1).
7.1.3
Collaboration
F. 7.2 Diagramme de collaboration dune transaction immobilire.
Une collaboration montre des instances qui collaborent dans un contexte donn pour mettre en
oeuvre une fonctionnalit dun systme.
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.

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
7.2. DIAGRAMME DE COMMUNICATION
95
F. 7.5 Diagramme de squence dun systme de pilotage.
contient un jeu de ligne de vie. Chaque ligne de vie correspond une partie interne dun classeur ou de
la collaboration et reprsente une instance ou un jeu dinstances sur une priode donne. Linteraction
dcrit donc lactivit interne des lments du classeur ou de la collaboration, appels lignes de vie, et
des messages quils changent.
UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme de
communication et celui de squence. Une mme interaction peut tre prsente aussi bien par 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.9). La syntaxe de ces attributs est la mme que celle des
attributs dun classe.
7.2
Diagramme de communication (Communication diagram)
Contrairement un diagramme de squence, un diagramme de communication rend compte de lorganisation spatiale des participants linteraction, il est souvent utilis pour illustrer un cas dutilisation
ou pour dcrire une opration.
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.
96
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] ] :] [r :=] 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.3 est antrieur celui du
message 1.4.4 mais postrieur celui du message 1.3.5. La simultanit dun envoi est dsigne
par une lettre : les messages 1.6.a et 1.6.b sont envoys en mme temps.
iter spcifie (en langage naturel, entre crochets) lenvoi squentiel (ou en parallle, avec ||). On peut
omettre cette spcification et ne garder que le caractre "*" (ou "*||") pour dsigner un message
rcurrent envoy un certain nombre de fois.
r 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. 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.
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
Messages synchrones et asynchrones, cration et destruction dinstance

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 ;
7.3. DIAGRAMME DE SQUENCE
97
la cration ou la destruction dune instance.

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.
F. 7.6 Reprsentation dun 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.6).
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.
F. 7.7 Reprsentation dun message synchrone.

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.7). Ce
message peut tre suivi dune rponse qui se reprsente par une flche en pointill (figure 7.7).
La cration dun objet est matrialise par une flche qui pointe sur le sommet dune ligne de vie.
La destruction dun objet est matrialise par une croix qui marque la fin de la ligne de vie de lobjet.
vnements et messages
F. 7.8 Les diffrents vnement correspondant un message asynchrone.
98
UML permet de sparer clairement lenvoi du message, sa rception, ainsi que le dbut de lexcution
de la raction et sa fin (figure 7.8).
Syntaxe des messages et des rponses
F. 7.9 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 matrialise 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.9 montre un exemple dexcution dune mthode avec une rponse.
Message perdu et trouv
F. 7.10 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.
99
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.10).
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.10).
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

Un objet actif initie et contrle le flux dactivits. Graphiquement, la ligne pointille verticale dun
objet actif est remplace par un double trait vertical.
Un objet passif, au contraire, a besoin quon lui donne le flux dactivit pour lui appliquer 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.7 ou 7.9 par exemple). Le rectangle peut
ventuellement porter un label.
7.3.3
Fragments dinteraction combins
Introduction
Un fragment combin reprsente des articulations dinteractions. Il est dfini par un oprateur 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 dcrire 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 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.
Oprateurs alt et opt
Loprateur alternative, ou alt, est un oprateur conditionnel possdant plusieurs oprandes (cf. figure
7.11). 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.
Loprateur option, ou opt, comporte une oprande et une condition de garde associe. Le sousfragment sexcute si la condition de garde est vraie et ne sexcute pas dans le cas contraire.
100
F. 7.11 Reprsentation dun choix dans un diagramme de squence.
F. 7.12 Reprsentation dune boucle dans un diagramme de squence.
Oprateur loop
Un fragments combin de type loop (cf. figure 7.12) 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.
Oprateur par
Un fragments combin de type parallel, ou par, possde au moins deux sous-fragments excuts
simultanment (cf. figure 7.13). La concurrence est logique et nest pas ncessairement physique : les
excutions concurrentes peuvent sentrelacer sur un mme chemin dexcution dans la pratique.
101
F. 7.13 MicrowaveOven est un exemple dobjet effectuant deux tches en parallle.
Oprateur strict
F. 7.14 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.14).
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 lutilisation de linteraction.
102
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.14). La syntaxe complte pour spcifier linteraction rutiliser est la suivante :
[ <nomAttributValeurRetour> = ] <nomInteraction>
[ ( [<arguments>] ) ][ : <valeurRetour> ]
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
8.2.1
Diagrammes de composants
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 programmation
oriente objet puisquil ne sagit, finalement, que dun facteur dchelle. En effet, lutilisation de composants est assimilable une approche objet, non pas au niveau du code, mais au niveau de larchitecture
gnrale du logiciel.
103
104
CHAPITRE 8. DIAGRAMMES DE COMPOSANTS ET DE DPLOIEMENT
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 demicercle) 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 reprsentation
explicite de leur port correspondant.
8.2. DIAGRAMMES DE COMPOSANTS
8.2.2
105
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. Limplmentation
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 symbole du composant (cf. figure 8.5),
ou ct en les reliant au composant par une relation de dpendance.
Pour montrer les instances des composants, un diagramme de dploiement doit tre utilis (cf. section
8.3).
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 reprsenation de
la figure 8.3 en imbriquant le demi-cercle dune interface requise dans le cercle de linterface offerte
correspondante (cf. figure 8.5).
106
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
8.3.1
107
Diagramme de dploiement
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, excutable,
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 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.
108
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 composant.
8.3. DIAGRAMME DE DPLOIEMENT
8.3.4
109
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).
110
Chapitre 9
Mise en uvre dUML

9.1
9.1.1
Introduction
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 explicitant 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.
Itrative et incrmentale : Lensemble du problme est dcompos en petites itrations, dfinies 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.
111
112
9.1.2
CHAPITRE 9. MISE EN UVRE DUML
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 modlisation en
analyse et conception ;
fonde sur lutilisation dun sous-ensemble ncessaire et suffisant du langage UML (modliser 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
9.2.1
Identification des besoins et spcification des fonctionnalits

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.
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.3. PHASES DANALYSE
9.2.2
113
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, lutilisation dun
diagramme dtats-transitions ou dactivits peut savrer prfrable une multitude de diagrammes
de squence.
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
9.3.1
Phases danalyse
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 modlisent 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
114
F. 9.4 Une maquette dIHM facilite les discussions avec les futurs utilisateurs.
F. 9.5 La phase danalyse du domaine permet dlaborer la premire version du diagramme de

classes.
9.3. PHASES DANALYSE
115
peuvent tre identifis directement partir de la connaissance du domaine ou par des entretiens avec
des experts du domaine. Il faut absolument utiliser le vocabulaire du mtier pour nommer les classes et
leurs attributs. Les classes du modle du domaine ne doivent pas contenir doprations, mais seulement
des attributs. Les tapes suivre pour tablir ce diagramme sont (cf. section 3.5) :
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
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.
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 conception (section 9.4.2). Les diagrammes de
conception logicielle napparaissent pas encore sur la 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 principe fondamental du dcoupage en couches
dune application. Ainsi, le diagramme de classes participantes modlise trois types de classes danalyse,
116
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 utilisateurs 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 appeles
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 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 9.5.2).
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 navigabilit 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 oprations 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.4. PHASE DE CONCEPTION
117
F. 9.7 Les diagrammes dactivits de navigation reprsentent graphiquement lactivit de navigation

dans lIHM.
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 diagrammes de navigation.
Le concepteur le choix dopter pour cette modlisation entre des diagrammes dtats-transitions et des
diagrammes dactivits. Les diagrammes dactivits constituent 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
9.4.1
Phase de conception
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 prsents sous la forme
de diagrammes dinteraction UML (figure 9.8). Inversement, llaboration de ces diagrammes facilite
grandement la rflexion.
118
F. 9.8 Les diagrammes dinteraction permettent dattribuer prcisment les responsabilits de comportement aux classes danalyse.
Paralllement, une premire bauche de la vue statique de conception, cest--dire du diagramme

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).
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 participantes ;
linteraction respecte la navigabilit de lassociation en question.
9.4. PHASE DE CONCEPTION
119
F. 9.9 Le systme des diagrammes de squences systme, vu comme une bote noire, est remplac
par un ensemble dobjets en collaboration.
F. 9.10 Chane complte de la dmarche de modlisation du besoin jusquau code.
9.4.2
Diagramme de classes de conception
Lobjectif de cette tape est de produire le diagramme de classes qui servira pour limplmentation
(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
120
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 est fortement conseille lors de llaboration du
diagramme de classes de conception.
Pour le passage limplmentation, rfrez vous la section 9.5. Parfois, les classes du type entits
ont intrt tre implmentes dans une base de donnes relationnelle (cf. section 9.5.2).
9.5
9.5.1
Phase dimplmentation
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 {
...
}
9.5. PHASE DIMPLMENTATION
121
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; }
122
public A getA(){ return(ra); }

}
Association unidirectionnelle 1 vers 1
public class A {
private B rb;
if( b != null ) {
this.setB( b );
}
public void setB( B b ) { this.rb=b; }
}
public class B {
... // La classe B ne connat pas lexistence de la classe A
}
Association bidirectionnelle 1 vers plusieurs

public class A {
private ArrayList rb;
public A() { rb = new ArrayList(); }
if( !rb.contains( b ) ) {
b.setA( this );
rb.add( b );
}
}
public ArrayList getRB() { return(rb); }
}
public class B {
private A ra;
public void addA( A a ) {
if( a != null ) {
if( !a.getArray().contains( this ) ) {
this.setA( a );
ra.getRB().add( this );
}
}
}
public void setA(A a) { this.ra=a; }
}
123
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 vecteur.
La dimension du tableau tant donnes par la cardinalit de
la terminaison dassociation.
Agrgations
Les agrgations simplmentent comme les associations.
Composition
Une composition peut simplmenter comme une association
unidirectionnelle.
9.5.2
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.
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);
124
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 classeassociation tant ajouts la troisime relation qui reprsente, cette fois ci, la classe-association ellemme.
125

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 sousclasse, 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,
126
attB2 integer,
type text);
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)
Cariou, E. (2003, novembre). Support de cours "le langage de contraintes ocl". Internet. (http :// www.univpau.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
(http ://www.developpez.com/)
dentraide
des
dveloppeurs
francophones.
Internet.
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. (2006). Uml 2.0. Prsentation projette.
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)
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/)
Object Management Group (OMG).
(http ://www.uml.org/)
(2006, Mai).
Object constraint language.
Piechocki, L. (n.d.). Uml en franais. Internet. (http ://uml.free.fr/)

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.
127
Internet.
128
Bibliographie
Volle, M. (2006). De linformatique (savoir vivre avec lautomate). Economica.

Wikipdia, encyclopdie librement distribuable. (n.d.). Internet. (http ://fr.wikipedia.org/ wiki/ Accueil)

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

Table des matires

Introduction la modlisation objet

Diagramme de cas dutilisation

TABLE DES MATIRES

Description avec des diagrammes dynamiques simples . . . . . . . . . . . . . . . .

Object constraint langage (OCL)

TABLE DES MATIRES

4.5.2 Navigation via une association . . . . . . . . .

TABLE DES MATIRES

Diagrammes de composants et de dploiement

Mise en uvre dUML

6.2.2 Nud dactivit structure . . .

TABLE DES MATIRES

9.3.1 Modle du domaine . . . . . . . . . .

TABLE DES MATIRES

Introduction la modlisation objet

Un logiciel ou une application est un ensemble de programmes, qui permet un ordinateur ou

CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET

Notion de qualit pour un logiciel

1.2. POURQUOI ET COMMENT MODLISER ?

Pourquoi et comment modliser ?

Notions de modle et de modlisation

Quest-ce quun modle ?

CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET

Le cycle de vie dun logiciel

1.2. POURQUOI ET COMMENT MODLISER ?

Modles de cycles de vie dun logiciel

Modle de cycle de vie en cascade

CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET

F. 1.1 Modle du cycle de vie en cascade

F. 1.2 Modle du cycle de vie en V

1.2. POURQUOI ET COMMENT MODLISER ?

Modle de cycle de vie en spirale

Mthodes danalyse et de conception

CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET

De la programmation structure lapproche oriente objet

F. 1.3 Reprsentation graphique dune approche fonctionnelle

Lapproche oriente objet

1.3. DE LA PROGRAMMATION STRUCTURE LAPPROCHE ORIENTE OBJET

Approche fonctionnelle vs. approche objet

Concepts importants de lapproche objet

CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET

Historique la programmation par objets

Histoire des modlisations par objets

CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET

Comment prsenter un modle UML ?

CHAPITRE 1. INTRODUCTION LA MODLISATION OBJET

Diagramme de cas dutilisation

lments des diagrammes de cas dutilisation

F. 2.1 Exemple de reprsentation dun acteur

CHAPITRE 2. DIAGRAMME DE CAS DUTILISATION

F. 2.2 Exemple de reprsentation dun acteur sous la forme dun classeur

F. 2.3 Exemple de reprsentation dun cas dutilisation

Reprsentation dun diagramme de cas dutilisation

Relations dans les diagrammes de cas dutilisation

2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION

F. 2.6 Diagramme de cas dutilisation reprsentant un logiciel de partage de fichiers

CHAPITRE 2. DIAGRAMME DE CAS DUTILISATION

Relations entre cas dutilisation

F. 2.7 Exemple de diagramme de cas dutilisation

2.3. RELATIONS DANS LES DIAGRAMMES DE CAS DUTILISATION