UML Cours

Analyse > Langage UML > Cours v0.8.1.
1 21/08/2009
1 / 49
LE LANGAGE UML
v0.8.1.1 21/08/2009
peignotc(at)arqendra(dot)net / peignotc(at)gmail(dot)com

Toute reproduction partielle ou intgrale autorise selon les termes de la licence Creative Commons (CC) BY-NC-SA : Contrat
Paternit-Pas d'Utilisation Commerciale-Partage des Conditions Initiales l'Identique 2.0 France, disponible en ligne
http://creativecommons.org/licenses/by-nc-sa/2.0/fr/ ou par courrier postal Creative Commons, 171 Second Street, Suite 300,
San Francisco, California 94105, USA. Merci de citer et prvenir lauteur.
TODO :
- 3.5 : Cadres dinteraction et fragments
- 3.6 : Diagrammes complmentaires (collaboration, tat, activit)
- 4.3 : Diagrammes complmentaires (objet, composants, dploiement)
Analyse > Langage UML > Cours v0.8.1.1 21/08/2009
2 / 49
TABLE DES MATIRES
1 INTRODUCTION AU LANGAGE UML.............................................................. 8
1.1 INTRODUCTION AU GNIE LOGICIEL........................................................................................... 8
1.2 CYCLE DE VIE DUN PROJET....................................................................................................... 8
1.2.1 Gnralits .......................................................................................................................................8
1.2.2 Diffrents cycles de vie.....................................................................................................................8
1.2.2.1 Prototypage rapide..................................................................................................................................... 8
1.2.2.2 Code and fix ........................................................................................................................................ 9
1.2.2.3 Cycle en V ........................................................................................................................................... 9
1.2.2.4 Cycle incrmental.................................................................................................................................... 10
1.3 UML ET GNIE LOGICIEL......................................................................................................... 11
1.3.1 Dfinition........................................................................................................................................11
1.3.2 Objectifs..........................................................................................................................................12
2 LE DIAGRAMME DE CAS DUTILISATION.................................................. 13
2.1 DFINITION ............................................................................................................................. 13
2.2 CONSTRUCTION DU DIAGRAMME............................................................................................. 13
2.2.1 Les acteurs......................................................................................................................................13
2.2.1.1 Dfinition ................................................................................................................................................ 13
2.2.1.2 Reprsentation graphique ........................................................................................................................ 14
2.2.2 Les cas dutilisation........................................................................................................................14
2.2.2.1 Dfinition ................................................................................................................................................ 14
2.2.3 Les relations ...................................................................................................................................15
2.2.3.1 Dfinition ................................................................................................................................................ 15
2.2.4 Le diagramme.................................................................................................................................15
2.2.4.1 Dfinition ................................................................................................................................................ 15
2.2.4.3 Description textuelle des flots dvnements .......................................................................................... 16
2.3 DIAGRAMMES COMPLMENTAIRES.......................................................................................... 17
2.3.1 Le diagramme de contexte statique ................................................................................................17
2.3.2 Le diagramme de contexte dynamique ...........................................................................................17
2.4 COMPLMENTS SUR LES RELATIONS........................................................................................ 18
2.4.1 La gnralisation............................................................................................................................18
2.4.2 Linclusion......................................................................................................................................19
2.4.3 Lextension .....................................................................................................................................19
2.4.4 Exemple de diagramme de cas dutilisation complet .....................................................................20
3 LES DIAGRAMMES DE SQUENCE............................................................... 21
3.1 DFINITION ............................................................................................................................. 21
3.2.1 Les objets........................................................................................................................................21
3.2.1.1 Dfinition ................................................................................................................................................ 21
3.2.2 Les interactions ..............................................................................................................................22
3.2.2.1 Dfinition ................................................................................................................................................ 22
3 / 49
3.2.3 Les diagrammes : approche gnrale.............................................................................................22
3.3 UTILISATIONS.......................................................................................................................... 23
3.3.1 Forme simplifie : documentation dun cas dutilisation...............................................................23
3.3.1.1 Description du flot dvnements principal............................................................................................. 23
3.3.1.2 Description des flots dvnements alternatifs et exceptionnels ............................................................. 23
3.3.2 Forme dtaille : clatement du systme en classes.......................................................................24
3.3.2.1 Recherche des classes.............................................................................................................................. 25
3.3.2.2 Modification des diagrammes de squence ............................................................................................. 26
3.4 COMPLMENTS........................................................................................................................ 26
3.4.1 Strotypes de Jacobson.................................................................................................................26
3.4.2 Flot de contrle ..............................................................................................................................27
3.4.3 Priode dactivit ...........................................................................................................................27
3.4.4 Messages de cration et de destruction dinstance ........................................................................28
3.4.5 Messages synchrones et asynchrones.............................................................................................29
3.4.6 Reprsentation des comportements non squentiels : tests et boucles ...........................................29
3.4.7 Syntaxe complte des messages......................................................................................................30
3.5 COMPLMENTS........................................................................................................................ 30
3.6.1 Les diagrammes de collaboration ..................................................................................................30
3.6.2 Les diagrammes dactivits ............................................................................................................30
3.6.3 Les diagrammes dtats-transitions................................................................................................30
4 LE DIAGRAMME DE CLASSES ....................................................................... 31
4.1 DFINITION ............................................................................................................................. 31
4.2.1 Les classes ......................................................................................................................................31
4.2.1.1 Dfinition ................................................................................................................................................ 31
4.2.2 Les interfaces..................................................................................................................................33
4.2.2.1 Dfinition ................................................................................................................................................ 33
4.2.3 Les paquetages ...............................................................................................................................33
4.2.3.1 Dfinition ................................................................................................................................................ 33
4.2.4 Les gnralisations et les spcialisations.......................................................................................34
4.2.4.1 Dfinition ................................................................................................................................................ 34
4.2.5 Les ralisations...............................................................................................................................34
4.2.5.1 Dfinition ................................................................................................................................................ 34
4.2.6 Les associations simples.................................................................................................................34
4.2.6.1 Dfinition ................................................................................................................................................ 34
4.2.7 Les agrgations ..............................................................................................................................36
4.2.7.1 Dfinition ................................................................................................................................................ 36
4.2.8 Les compositions ............................................................................................................................36
4.2.8.1 Dfinition ................................................................................................................................................ 36
4.2.9 Les classes dassociation................................................................................................................38
4.2.9.1 Dfinition ................................................................................................................................................ 38
4 / 49
4.2.10 Les dpendances.............................................................................................................................38
4.2.10.1 Dfinition ................................................................................................................................................ 38
4.2.11 Le diagramme.................................................................................................................................39
4.2.11.1 Dfinition ................................................................................................................................................ 39
4.3.1 Les diagrammes dobjet..................................................................................................................40
4.3.2 Les diagrammes de composants .....................................................................................................40
4.3.3 Les diagrammes de dploiement.....................................................................................................40
5 / 49
TABLE DES ANNEXES
A ORIGINES DU LANGAGE................................................................................. 41
A.1 HISTORIQUE ............................................................................................................................ 41
A.2 CONTRIBUTIONS...................................................................................................................... 41
B LEXIQUE GRAPHIQUE ..................................................................................... 42
B.1 STRUCTURE STATIQUE............................................................................................................. 42
B.1.1 Classes............................................................................................................................................42
B.1.1.1 Classe ...................................................................................................................................................... 42
B.1.1.2 Classe abstraite........................................................................................................................................ 42
B.1.1.3 Classe strotype ................................................................................................................................... 42
B.1.1.4 Classe paramtrable................................................................................................................................. 43
B.1.1.5 Classe paramtre.................................................................................................................................... 43
B.1.1.6 Interface................................................................................................................................................... 43
B.1.2 Objets..............................................................................................................................................43
B.1.2.1 Objet........................................................................................................................................................ 43
B.1.2.2 Objet comme instance de classe .............................................................................................................. 43
B.1.2.3 Objet anonyme ........................................................................................................................................ 43
B.1.3 Paquetage.......................................................................................................................................44
B.1.4 Membres .........................................................................................................................................44
B.1.4.1 Membres.................................................................................................................................................. 44
B.1.4.2 Visibilit.................................................................................................................................................. 44
B.1.4.3 Membre statique...................................................................................................................................... 44
B.1.4.4 Mthode abstraite .................................................................................................................................... 44
B.2 ASSOCIATIONS ........................................................................................................................ 45
B.2.1 Association simple ....................................................................................................................45
B.2.1.1 Association unidirectionnelle 1-1............................................................................................................ 45
B.2.1.2 Association unidirectionnelle 1-plusieurs ............................................................................................... 45
B.2.1.3 Association bidirectionnelle .................................................................................................................... 45
B.2.1.4 Association rflexive............................................................................................................................... 45
B.2.2 Agrgation......................................................................................................................................45
B.2.2.1 Agrgation 1-1......................................................................................................................................... 46
B.2.2.2 Agrgation 1-plusieurs ............................................................................................................................ 46
B.2.2.3 Agrgation navigable .............................................................................................................................. 46
B.2.2.4 Agrgation rflexive................................................................................................................................ 46
B.2.3 Composition....................................................................................................................................46
B.2.3.1 Composition 1-1...................................................................................................................................... 46
B.2.3.2 Composition 1-plusieurs.......................................................................................................................... 46
B.2.3.3 Composition navigable............................................................................................................................ 47
B.2.3.4 Composition rflexive ............................................................................................................................. 47
B.3 SPCIALISATION / GNRALISATION........................................................................................ 47
B.3.1 Spcialisation .................................................................................................................................47
B.3.2 Ralisation......................................................................................................................................47
B.4 CLASSE DASSOCIATION.......................................................................................................... 47
B.5 DPENDANCES ........................................................................................................................ 48
C BIBLIOGRAPHIE ................................................................................................ 49
6 / 49
TABLE DES ILLUSTRATIONS
Figure 1.1 : cycle de vie code and fix _____________________________________________________________________________________9
Figure 1.2 : cycle de vie en V ___________________________________________________________________________________________9
Figure 1.3 : rpartition temporelle des tapes du cycle en V __________________________________________________________________10
Figure 1.4 : cycle de vie incrmental _______________________________________________________________________________________11
Figure 2.1 : processus de construction du diagramme de cas dutilisation __________________________________________________________13
Figure 2.2 : reprsentation graphique dun acteur ____________________________________________________________________________14
Figure 2.3 : exemple dun acteur__________________________________________________________________________________________14
Figure 2.4 : reprsentation graphique dun cas dutilisation ____________________________________________________________________15
Figure 2.5 : exemple dun cas dutilisation __________________________________________________________________________________15
Figure 2.6 : reprsentation graphique dune relation __________________________________________________________________________15
Figure 2.7 : exemple dune relation________________________________________________________________________________________15
Figure 2.8 : exemple dun diagramme de cas dutilisation ______________________________________________________________________16
Figure 2.9 : description des flots dvnements _______________________________________________________________________________17
Figure 2.10 : exemple dun diagramme de contexte statique_____________________________________________________________________17
Figure 2.11 : exemple dun diagramme de contexte dynamique __________________________________________________________________17
Figure 2.12 : reprsentation graphique dune gnralisation ____________________________________________________________________18
Figure 2.13 : exemple dune gnralisation entre acteurs_______________________________________________________________________18
Figure 2.14 : exemple dune gnralisation entre cas dutilisation ________________________________________________________________18
Figure 2.15 : reprsentation graphique dune inclusion ________________________________________________________________________19
Figure 2.16 : exemple dune relation dinclusion _____________________________________________________________________________19
Figure 2.17 : reprsentation graphique dune extension ________________________________________________________________________19
Figure 2.18 : exemple dune relation dextension _____________________________________________________________________________20
Figure 2.19 : exemple dun diagramme de cas dutilisation complet_______________________________________________________________20
Figure 3.1 : reprsentation dun objet ______________________________________________________________________________________22
Figure 3.2 : reprsentation dune interaction ________________________________________________________________________________22
Figure 3.3 : reprsentation dun diagramme de squence_______________________________________________________________________23
Figure 3.4 : exemple dun diagramme de squence simplifi_____________________________________________________________________23
Figure 3.5 : exemple dun diagramme de squence simplifi annot_______________________________________________________________24
Figure 3.6 : reprsentation dun diagramme de squence dtaill ________________________________________________________________25
Figure 3.7 : exemple dun diagramme de squence dtaill _____________________________________________________________________26
Figure 3.8 : reprsentation graphique des classes selon les strotypes de Jacobson__________________________________________________26
Figure 3.9 : exemple dun diagramme de squence en utilisant les strotypes de Jacobson ____________________________________________27
Figure 3.10 : flot de contrle_____________________________________________________________________________________________27
Figure 3.11 : reprsentation dune priode dactivit __________________________________________________________________________28
Figure 3.12 : reprsentation des messages de construction et de destruction dinstance _______________________________________________28
Figure 3.13 : reprsentation des messages synchrones et asynchrones _____________________________________________________________29
Figure 3.14 : reprsentation des comportements non squentiels _________________________________________________________________29
Figure 4.1 : reprsentation graphique dune classe ___________________________________________________________________________32
Figure 4.2 : exemple de reprsentation graphique dune classe __________________________________________________________________33
Figure 4.3 : reprsentation graphique dune classe strotype __________________________________________________________________33
Figure 4.4 : reprsentation graphique dune interface _________________________________________________________________________33
Figure 4.5 : reprsentation graphique dun paquetage _________________________________________________________________________34
Figure 4.6 : reprsentation graphique dune gnralisation _____________________________________________________________________34
Figure 4.7 : reprsentation graphique dune ralisation________________________________________________________________________34
Figure 4.8 : reprsentation graphique dune association _______________________________________________________________________35
Figure 4.9 : exemple dassociation ________________________________________________________________________________________35
Figure 4.10 : reprsentation graphique dune agrgation_______________________________________________________________________36
Figure 4.11 : exemple dagrgation________________________________________________________________________________________36
Figure 4.12 : reprsentation graphique dune composition______________________________________________________________________37
Figure 4.13 : reprsentation graphique dune composition sous forme de classe imbrique_____________________________________________37
Figure 4.14 : exemple de composition ______________________________________________________________________________________37
Figure 4.15 : reprsentation graphique dune classe dassociation _______________________________________________________________38
Figure 4.16 : reprsentation graphique dune dpendance ______________________________________________________________________39
Figure 4.17 : exemple dun diagramme de classes ____________________________________________________________________________40
Figure B.1 : reprsentation UML dune classe _______________________________________________________________________________42
Figure B.2 : reprsentation UML simplifie dune classe (1) ____________________________________________________________________42
Figure B.3 : reprsentation UML simplifie dune classe (2) ____________________________________________________________________42
Figure B.4 : reprsentation UML dune classe abstraite________________________________________________________________________42
Figure B.5 : reprsentation UML dune classe strotype______________________________________________________________________42
Figure B.6 : reprsentation UML dune classe paramtrable ____________________________________________________________________43
Figure B.7 : reprsentation UML dune classe paramtre______________________________________________________________________43
7 / 49
Figure B.8 : reprsentation UML dune interface _____________________________________________________________________________43
Figure B.9 : reprsentation UML dun objet _________________________________________________________________________________43
Figure B.10 : reprsentation UML simplifie dun objet ________________________________________________________________________43
Figure B.11 : reprsentation UML dun objet comme instance de classe ___________________________________________________________43
Figure B.12 : reprsentation UML dun objet anonyme ________________________________________________________________________43
Figure B.13 : reprsentation UML dun paquetage____________________________________________________________________________44
Figure B.14 : reprsentation UML dune classe et de ses membres________________________________________________________________44
Figure B.15 : reprsentation UML dune classe, de ses membres et de leur visibilit__________________________________________________44
Figure B.16 : reprsentation UML dune classe et des membres statiques __________________________________________________________44
Figure B.17 : reprsentation UML dune classe abstraite et dune mthode abstraite _________________________________________________45
Figure B.18 : reprsentation UML dune association __________________________________________________________________________45
Figure B.19 : reprsentation UML dune association unidirectionnelle 1-1 _________________________________________________________45
Figure B.20 : reprsentation UML dune association unidirectionnelle 1-plusieurs ___________________________________________________45
Figure B.21 : reprsentation UML dune association bidirectionnelle _____________________________________________________________45
Figure B.22 : reprsentation UML dune association rflexive ___________________________________________________________________45
Figure B.23 : reprsentation UML dune agrgation __________________________________________________________________________45
Figure B.24 : reprsentation UML dune agrgation 1-1 _______________________________________________________________________46
Figure B.25 : reprsentation UML dune agrgation 1-plusieurs _________________________________________________________________46
Figure B.26 : reprsentation UML dune agrgation navigable __________________________________________________________________46
Figure B.27 : reprsentation UML dune agrgation rflexive ___________________________________________________________________46
Figure B.28 : reprsentation UML dune composition _________________________________________________________________________46
Figure B.29 : reprsentation UML dune composition sous forme de classe imbrique ________________________________________________46
Figure B.30 : reprsentation UML dune composition 1-1 ______________________________________________________________________46
Figure B.31 : reprsentation UML dune composition 1-plusieurs ________________________________________________________________46
Figure B.32 : reprsentation UML dune composition navigable _________________________________________________________________47
Figure B.33 : reprsentation UML dune composition rflexive __________________________________________________________________47
Figure B.34 : reprsentation UML dune gnralisation / spcialisation ___________________________________________________________47
Figure B.35 : reprsentation UML dune ralisation___________________________________________________________________________47
Figure B.36 : reprsentation UML dune classe dassociation ___________________________________________________________________47
Figure B.37 : reprsentation UML dune dpendance__________________________________________________________________________48
Un grand nombre de diagrammes UML et de reprsentations dlments utiliss pour les figures du prsent
document sont extraites de captures dcran de modlisations ralises laide du logiciel StarUML v5.0.2.1570
(http://staruml.sourceforge.net), plate-forme UML/MDA OpenSource.
Le logiciel StarUML comme tout logiciel de modlisation ayant ses limites et son interprtation de la norme,
certaines de ces captures dcran ont d tre retravailles laide dun logiciel ddition dimages afin de rester au
plus proche des standards de reprsentation UML.
8 / 49
1 INTRODUCTION AU LANGAGE UML
1.1 INTRODUCTION AU GNIE LOGICIEL
Le dveloppement de logiciels est une activit rcente ayant dbut dans les annes 70 pour devenir lheure
actuelle lun des piliers de lconomie mondiale. Durant cette priode de passage de lartisanat lindustrie, les
ncessits dindustrialisation (volution perptuelle du matriel, accroissement exponentiel des besoins en quantit et
qualit, etc.) ont conduit la mise en place du gnie logiciel.

Le gnie logiciel est un terme dsignant lensemble des activits de conception et de mise en uvre des produits et
procdures ayant pour objectif de rationaliser la production de logiciels ainsi que leur suivi.
Lide est de mettre en place des procds, des mthodes, des normes, des techniques et des outils pour le
dveloppement de logiciels. Les objectifs vidents sont de produire des logiciels de qualit, rpondant aux besoins
exprims, de prvoir et rduire les cots et les dlais, ainsi que de mettre en place des structures facilitant la
maintenance.
1.2 CYCLE DE VIE DUN PROJET
1.2.1 Gnralits
La notion de projet apparat lorsquun besoin en systme informatis est exprim par une entreprise, afin de mettre
en place le suivi de sa ralisation. Un projet possde un dbut (un besoin), et une fin (une ralisation).

Le cycle de vie dun projet dcrit les tapes successives de dveloppement de ce projet, partant du besoin pour
arriver la ralisation : analyse des besoins, spcification, conception, codage, intgration, maintenance, retrait.
Chaque tape du cycle de vie est suivie dune opration de vrification qui conditionne le passage ltape suivante.

Le cycle de vie sert de base de travail pour le planning de dveloppement du systme informatis. Il permet ainsi
davoir une vision sur ltat davancement du projet, ainsi que deffectuer un contrle continu des rsultats produits. Il
joue par ailleurs le rle de contrat entre le client et les fournisseurs.

Le cycle de vie favorise la dtection des erreurs le plus tt possible lors du dveloppement, car de la bonne mise en
place des tapes amont dpend la bonne ralisation des tapes finales ; en effet, une modification en fin de cycle
entrane une remise jour de tous les produits des phases prcdentes. De surcrot, il est plus facile de modifier les
spcifications dun systme que den modifier la ralisation (le code).
1.2.2 Diffrents cycles de vie
1.2.2.1 Prototypage rapide
Le cycle de vie type prototypage rapide est particulier :
R slectionner les fonctions valider ;
R construire le prototype ;
R valuer et modifier ce prototype.

Son intrt est de sassurer trs rapidement des besoins du client en offrant une vision concrte bien que partielle du
produit ; il permet ainsi de prouver la faisabilit du produit, dvaluer grossirement les performances et de valider des
choix de conception.
9 / 49
Son inconvnient est dtre une solution coteuse, principalement en phase de maintenance. De plus, le temps de
dveloppement du prototype nest pas du tout reprsentatif du temps de dveloppement du systme rel.
1.2.2.2 Code and fix
Le cycle de vie code and fix est dfini en 2 tapes : coder et corriger (do le nom).

dveloppement
dune premire
version
modifications tant
que le client nest
pas satisfait
utilisation
dveloppement
maintenance

Figure 1.1 : cycle de vie code and fix
Son intrt est de raliser une mise en route trs rapide en fonctionnement chez le client.
Son inconvnient est que le rsultat obtenu est trs loign du besoin, que le code perd sa structuration initiale, et
que celui-ci est coteux modifier.
1.2.2.3 Cycle en V
Le cycle en V possde la particularit de positionner en parallle les activits de production et les activits de
contrle.

expression
du besoin
contrle
spcification
conception
prliminaire
utilisation
tests de
validation
tests
dintgration
conception
dtaille
tests
unitaires
codage
production
client
industriel
cahier des
charges
test s bot e blanche
et bot e noire
Figure 1.2 : cycle de vie en V
Les diffrentes tapes de ce cycle de vie sont les suivantes :
R cahier des charges ;
Lorsque des besoins en systme informatis se font ressentir dans une entreprise, le client synthtise ceux-ci
et rdige un cahier des charges, qui dcrit ainsi le pourquoi du systme.
Ce document est ensuite soumis divers prestataires concepteurs de systmes informatiss, qui font alors une
proposition de dveloppement, incluant lvaluation des cots et des dlais de ralisation. Une fois
lentreprise dcide sur le prestataire, le cahier des charges est ensuite remani lors dun travail de
collaboration entre lentreprise et le prestataire, notamment pour clarifier les lments propres au domaine
dapplication du systme concevoir, lequel peut parfois tre trs spcifique (domaine mdical par exemple).
10 / 49
R spcification des besoins ;
La spcification des besoins permet de dlimiter le systme en dcrivant les fonctions majeures de celui-ci ;
elle dcrit ainsi le quoi du systme (i.e. que faire ?). Les besoins exprims dans le cahier des charges sont re-
formuls, hors de tout vocabulaire informatique, en utilisant un formalisme clair et vulgaris, et sont proposs
pour vrification au client afin de sassurer que les besoins ont bien t compris.
R conception prliminaire ;
La conception prliminaire permet de dterminer larchitecture informatique globale du systme
(configuration matrielle, choix des langages et outils de dveloppement, dcoupage en modules et dfinition
des modules, etc.) et dcrit ainsi le comment du systme.
R conception dtaille ;
Le contenu (algorithme) de chaque module dfini lors de la conception prliminaire est dcrit prcisment.
R codage ;
Le codage correspond limplmentation des diffrents modules dcrits lors de la conception dtaille,
limplmentation des diffrentes IHMs
1
, et la programmation du reste de lapplication logicielle du
systme informatis, le tout en utilisant les langages informatiques choisis.
R tests unitaires ;
Les tests unitaires permettent de contrler le fonctionnement de chaque module (squences, boucles,
alternatives) en ralisant des tests bote blanche (le code interne du module est visible) et bote noire (le code
interne est invisible, seule linterface (prototype) du module est utilise).
R tests dintgration ;
Les modules prcdemment tests sont assembls progressivement les uns avec les autres, afin de tester leur
interoprabilit.
R tests de validation ;
Les tests de validation sassurent que le produit dvelopp est conforme aux spcifications du cahier des
charges.
R utilisation.
Linstallation, la configuration et la mise en situation au sein de lentreprise du systme dvelopp permettent
de vrifier que celui-ci rpond ainsi aux besoins du client.

Ces diffrentes tapes se rpartissent temporellement sur des priodes qui se chevauchent, afin de pouvoir minimiser
les dlais en travaillant sur diffrents travaux en parallle et pour permettre une rvaluation des tapes antrieures lors
de la mise en vidence derreurs.

spcification
temps
charge de travail
ralisation tests conception
Figure 1.3 : rpartition temporelle des tapes du cycle en V
Lintrt de ce cycle de vie est dimposer les activits de contrle pour chaque tape de production.
Son inconvnient est de proposer une mise en uvre tardive de limplmentation, des tests et de la validation, ce qui
peut rendre coteux certaines erreurs de spcification.
1.2.2.4 Cycle incrmental
Le cycle de vie incrmental permet un dveloppement sous forme de prototypes conscutifs, et est adapt au
dveloppement mettant en uvre la programmation oriente objet
2
.
1
IHM : Interface Homme/Machine.
2
POO : Programmation Oriente Objet.
11 / 49
spcification
analyse
conception
implmentation
tests
validation
v1.0 v2.0 v3.0
Figure 1.4 : cycle de vie incrmental
Ce cycle de vie est notamment constitu des phases suivantes :
R spcification : correspond la dfinition de ce que cest ;
Elle permet de dlimiter prcisment le systme, de dcrire les diffrentes manires de lutiliser du point de
vue des utilisateurs.
Cette dmarche est oriente utilisateur et permet ainsi de concevoir le systme en tant que rponse un ou
des besoin(s).
R analyse : correspond la dfinition de ce que doit faire le systme.
Elle permet de mettre en vidence les caractristiques des objets
1
suivant 3 axes :
U fonctionnel : ce que fait lobjet ;
U statique : la structure de lobjet ;
U dynamique : les diffrents tats de lobjet dans le temps (comportement).

Son intrt est de permettre un dveloppement chelonn des diffrentes fonctionnalits et daffiner les
spcifications en fonction des rsultats obtenus.
Son inconvnient est dtre applicable principalement avec des produits suffisamment souples pour prendre en
compte des spcifications non prvues au dpart.
1.3 UML ET GNIE LOGICIEL
La plupart des diffrents cycles de vie dun projet font ressortir les notions de spcification, conception et analyse
qui, depuis les annes 80, ont t mises en uvre suivant diffrents procds ; parmi ceux-ci, se trouve le langage
UML.
1.3.1 Dfinition
Le langage UML (Unified Modeling Language
2
) est un langage de modlisation qui a pour but de faciliter les
transitions, lors du dveloppement dun projet, du besoin originel la phase dimplmentation.
Ce langage, fusion de 3 mthodes orientes objet trs utilises (OMT
3
, Booch et OOSE
4
) dont le dveloppement a
dbut en 1994, et qui a t standardis en 1997 par lOMG
5
dans sa version 1.1
6
, sappuie essentiellement sur la
technologie objet et les concepts quelle vhicule.
Nanmoins, lutilisation de UML nest pas restreinte au dveloppement de systmes informatiss, mais peut servir
au dveloppement de systmes de gestion, tout comme la rsolution de problmes dorganisation de tout style. De
plus, UML, de par sa reprsentation essentiellement graphique, se veut extrmement vulgaris et intuitif, et est
utilisable par les tres humains ainsi que les machines.

Nb : On parle volontairement de langage UML et non pas de mthode, car UML propose des outils et des concepts
de modlisation, et non pas une mthodologie respecter imprativement.

1
Au sens POO du terme.
2
Langage de Modlisation Unifi.
3
Object Modeling Technique.
4
Object Oriented Software Engineering.
5
Object Management Group.
6
En fvrier 2009, UML a dj subi une rvision importante et on travaille dsormais avec UML 2.2.
12 / 49
1.3.2 Objectifs
Au final, le langage UML est une synthse de tous les concepts et formalismes mthodologiques les plus utiliss,
pouvant tre utilis, grce sa simplicit et son universalit, comme langage de modlisation pour la plupart des
systmes devant tre dvelopps
1
.
Le langage UML permet ainsi dapporter des solutions lors du dveloppement de systmes informatiss :
R dcomposer le processus de dveloppement en distinguant la phase danalyse (aspects fonctionnels) de la
phase de ralisation (aspects technologiques et architecturaux) ;
R dcomposer le systme en sous-systmes plus facilement abordables : rduction de la complexit, rpartition
du travail, rutilisation des sous-systmes ;
R utiliser une technologie de haut niveau proche de la ralit pour aborder le dveloppement.

La modlisation propose par le langage UML se ralise principalement sous forme graphique, en usant de divers
types de diagrammes spcifiques
2
, rpartis en deux groupes :
R structure du systme (statique) ;
U diagramme de cas dutilisation : structure des fonctionnalits ;
U diagramme de classes : structure des entits ;
U diagrammes dobjets : cas particulier des structures de classe ;
U diagrammes de composants : structure de larchitecture logicielle ;
U diagrammes de dploiement : structure de larchitecture matrielle ;
U diagramme des paquetages (UML v2) ;
U diagrammes de structure composite (UML v2).
R comportement du systme (dynamique).
U diagrammes dtats-transitions : cycle de vie des objets ;
U diagrammes dactivits : ;
U interactions du systme :
X diagrammes de squence : scnarios des fonctionnalits ;
X diagrammes de collaboration/communication : interactions entre objets ;
X diagrammes de vue globale des interactions (UML v2) ;
X diagrammes de temps (UML v2).

Certains de ces diagrammes sont indpendants, alors que dautres servent de base de travail ou bien sont la
continuit dautres diagrammes.

1
Informatiques ou autres.
2
9 diagrammes diffrents pour UML v1.4, et 13 pour UML v2.2.
13 / 49
2 LE DIAGRAMME DE CAS DUTILISATION
2.1 DFINITION
Le diagramme de cas dutilisation dcrit les fonctionnalits dun systme dun point de vue utilisateur, sous la
forme dactions et de ractions ; lensemble des fonctionnalits est dtermin en examinant les besoins fonctionnels de
tous les utilisateurs potentiels.

Le but est didentifier :
R les catgories dutilisateurs : chacune dentre elles, appele acteur, est susceptible de mettre en uvre une ou
plusieurs fonctionnalits du systme ;
R les besoins du systme : chaque fonctionnalit, appele cas dutilisation, doit rpondre lun des besoins
ncessits par une ou plusieurs catgories dutilisateurs.

Le diagramme des cas dutilisation se base sur le cahier des charges pour tre construit ; il fait donc partie, en termes
de gestion de projet, de la spcification du systme.

acquisition
guide
transcription
graphique
cahier des
charges initial
ce que lon
veut obtenir
modle du
besoin
dfinition
du besoin
ide du
besoin
Figure 2.1 : processus de construction du diagramme de cas dutilisation
Lobjectif du diagramme de cas dutilisation est de recentrer la problmatique du cahier des charges sur les besoins
des utilisateurs, lide sous-jacente tant quun systme et ses fonctionnalits nont de raison dtre que sils rpondent
un ou des besoins.

Le diagramme des cas dutilisation, qui est unique, synthtise alors les rsultats de cette tude en faisant apparatre
tous les acteurs, tous les cas dutilisation, et les relations entre ces divers lments.
2.2 CONSTRUCTION DU DIAGRAMME
2.2.1 Les acteurs
2.2.1.1 Dfinition
Un acteur symbolise les actions quune entit autonome et extrieure peut avoir avec le systme dont on dsire
dcrire le fonctionnement. Plus globalement, un acteur correspond une personne ou une machine extrieure, une
tche ou bien une interaction avec le systme.

On peut distinguer trois types dacteurs :
R humain : utilisateur du systme, au travers des diffrentes interfaces (IHM
1
logicielle ou matrielle) ;
exemple : client, administrateur, technicien, etc. ;

1
IHM : Interface Homme/Machine.
14 / 49
R logiciel : entit logicielle existante et fonctionnelle qui communique avec le systme grce une interface
logicielle ; exemple : application de gestion, base de donnes, etc. ;
R matriel : entit matrielle qui exploite les donnes du systme, ou est pilote par le systme ; exemple :
imprimante, robot, serveur, etc.

Plusieurs utilisateurs potentiels peuvent tre reprsents par un seul acteur si leur rle par rapport au systme est
identique ; exemple : deux techniciens (Pierre et Paul) seront reprsents par un seul acteur technicien .
De la mme manire, un utilisateur peut tre reprsent par plusieurs acteurs diffrents, sil est susceptible dutiliser
le systme en jouant des rles diffrents ; exemple : une personne physique (Pierre) tour--tour simple utilisateur et
technicien sera reprsente par deux acteurs utilisateur et technicien .

Ainsi, un acteur peut aussi bien dsigner une personne ou un systme unique, quun groupe de personnes ou de
systmes ayant des traits communs mis en uvre dans le systme.

Chaque acteur doit interagir avec au moins un des cas dutilisation. Les relations mises en vidence dcrivent ainsi
les possibilits des acteurs sur le systme.

Du point de vue du systme, on peut diffrencier deux types dacteurs :
R primaire : utilise le systme ; met en uvre 1 ou plusieurs fonctionnalits du systme ; rpond aux diffrentes
questions : qui va servir le systme ? qui va lutiliser ? qui le systme doit-il aider ? etc.
R secondaire : administre le systme ; possde un rle dadministration et de maintenance, paramtre le
systme et lui fournit toutes les informations ncessaires son bon fonctionnement pour les acteurs
primaires ; rpond aux diffrentes questions : qui gre le systme ? qui ladministre ? qui le paramtre ? etc.
2.2.1.2 Reprsentation graphique
Un acteur se reprsente graphiquement diffremment selon quil sagisse dun acteur humain ou non-humain,
respectivement par un personnage ou un rectangle. cette reprsentation graphique est associ un nom correspondant
au type dacteurs reprsent.

Figure 2.2 : reprsentation graphique dun acteur
Ex. : Un acteur reprsentant nimporte quel administrateur pouvant tre amen intervenir sur le systme.

Figure 2.3 : exemple dun acteur
2.2.2 Les cas dutilisation
2.2.2.1 Dfinition
Un cas dutilisation dsigne une fonctionnalit visible de lextrieur du systme dont on dsire dcrire le
fonctionnement. Un cas dutilisation doit rpondre un besoin en dfinissant une partie du comportement attendu du
systme sans rvler sa structure interne.

Un cas dutilisation regroupe une famille de scnarios dutilisation du systme ; exemple : configurer les paramtres
est un cas dutilisation, alors que configurer les paramtres dinitialisation est un scnario du cas dutilisation
prcdent.

Lexcution de chaque cas dutilisation est indpendante des autres, ce qui implique quun cas dutilisation doit tre
vu, la plupart du temps, comme une utilisation ayant un dbut et une fin propres.
Cependant, dans certains cas, un cas dutilisation reprsente une partie dune fonctionnalit dont lexcution peut
tre associe lexcution dautres cas dutilisation.
15 / 49
Un cas dutilisation est reprsent par une ellipse. cette reprsentation graphique est associ un nom
correspondant lutilisation reprsente ; de manire gnrale ce nom correspond la description dune action et
comprend donc un verbe linfinitif.

Figure 2.4 : reprsentation graphique dun cas dutilisation
Ex. : Un cas dutilisation correspondant laction de configurer les paramtres.

Figure 2.5 : exemple dun cas dutilisation
2.2.3 Les relations
2.2.3.1 Dfinition
Une relation prcise une interaction unidirectionnelle ou bidirectionnelle mettant en jeu 2 lments de type acteur
ou cas dutilisation ; celle-ci peut tre de deux types :
R entre acteur et cas dutilisation : reprsente linteraction du systme avec lextrieur, appele association ;
R entre deux entits de mme type (deux cas dutilisation ou deux acteurs) : reprsente le comportement entre
les entits (gnralisation, dpendance, inclusion ou extension)
1
.
Une relation est reprsente graphiquement par un lien entre les deux entits quelle relie. Ce lien peut tre flch
(flche tte classique
2
), le sens de la flche symbolisant alors le sens de linteraction (qui est actif ? passif ?), et pas
un quelconque flux de donnes. Lorsque linteraction est bidirectionnelle, le lien ne porte aucune flche.

Figure 2.6 : reprsentation graphique dune relation
Ex. : Un cas dutilisation dcrivant la possibilit pour nimporte quel administrateur de configurer les paramtres du
systme.

Figure 2.7 : exemple dune relation
2.2.4 Le diagramme
2.2.4.1 Dfinition
Au final, le diagramme de cas dutilisation doit faire apparatre :
R tous les acteurs susceptibles dintervenir sur le systme ;
R tous les cas dutilisation devant reprsenter toutes les diffrentes fonctionnalits du systme ;
R toutes les relations existantes dcrivant les interactions entre les acteurs et les cas dutilisation.

Ce diagramme doit tre pens comme tant dfinitif et exhaustif, et doit donc faire tat de tout ce qui est attendu du
systme. Par ailleurs, il reprsente le systme en tant que rponse des besoins et pas comme une entit unique. Le

1
cf. 2.4.
2
Une flche tte triangulaire symbolise autre chose quune relation dans le cadre de la programmation objet (la gnralisation, cf. 2.4.1).
16 / 49
systme lui-mme nest donc pas mentionn sur le diagramme, il nest reprsent que par les besoins auxquels il
rpond (les fonctionnalits) ; cest lensemble des fonctionnalits reprsentes qui dcrivent alors le systme.
Ce diagramme est la synthse graphique de tous les lments quil doit reprsenter.

Pour sassurer de sa cohrence, plusieurs rgles doivent tre observes :
R chaque entit (acteur, cas dutilisation) ne doit tre reprsente quune seule fois ;
R un acteur a obligatoirement une relation avec au moins un cas dutilisation ;
R un cas dutilisation a obligatoirement une relation avec au moins un acteur (sauf dans le cas des relations
entre cas dutilisation
1
).

Ex. : Cahier des charges et diagramme de cas dutilisation dun systme informatis implant dans une borne
automatique permettant dacheter un billet (mtro, train, etc.) qui est situe lintrieur mme dune gare.

Lorsque la borne est active, lutilisateur slectionne, grce au clavier, sa destination, puis la classe du billet
(premire ou seconde). Ensuite, il paie le montant demand en utilisant soit sa carte bleue quil insre dans la
borne et en composant son code, soit en utilisant de la monnaie. Puis le billet est imprim par la borne et
lutilisateur peut alors le retirer. Par dfaut, on considre que la gare de dpart est la gare o lon se trouve,
mais lutilisateur peut ventuellement dcider de modifier la gare de dpart.

Figure 2.8 : exemple dun diagramme de cas dutilisation
Ce diagramme doit ainsi synthtiser lintgralit des fonctionnalits attendues du systme. Trs occasionnellement,
il est possible que le diagramme de cas dutilisation ne dcrive quune partie du systme (gnralement par souci de
lisibilit).
2.2.4.3 Description textuelle des flots dvnements
Pour parfaire cette description, chaque cas dutilisation peut tre dcrit en langage naturel ou en pseudo-code, afin
de mettre en vidence les flots dvnements mis en jeu. On peut en distinguer trois types :
R flot dvnements principal : description du fonctionnement du cas dutilisation dans le cas du scnario le
plus probable ;
R flots dvnements alternatifs : description du fonctionnement du cas dutilisation pour une partie du scnario
diffrente du scnario le plus probable, venant ainsi se substituer une partie de la description du flot
dvnement principal ;
R flots dvnements exceptionnels : description du fonctionnement du cas dutilisation pour une partie du
scnario supplmentaire et optionnelle, venant ainsi se rajouter la description du flot dvnement principal
et signalant gnralement la fin du scnario.

Cette description textuelle permet ainsi de prciser lensemble du droulement du cas dutilisation :
R les prconditions (tat avant) et les postconditions (tat aprs) ;
R quand et comment le cas dutilisation dbute et se termine ;
R les relations entre le cas dutilisation et les acteurs (ou entre plusieurs cas dutilisation
1
) ;
R les donnes ncessaires pour ce cas dutilisation ;
R les rptitions de comportement ;
R dventuelles situations alternatives ou exceptionnelles.

1
cf. 2.4.
17 / 49
flot dvnements principal
flot dvnements alternatif flot dvnements exceptionnel
dbut cas
dutilisation
fin cas
dutilisation
Figure 2.9 : description des flots dvnements
Ex. : Le cas dutilisation dcrivant laction dacheter un billet de train en utilisant une borne automatique.

R flot dvnements principal : Lutilisateur slectionne, grce au clavier, sa destination, la classe du billet
(premire ou seconde), insre sa carte bleue, paie le montant demand, puis enfin retire le billet qui est
imprim par la borne.
R flots dvnements alternatifs : Lutilisateur choisit de payer en utilisant de la monnaie plutt que sa carte
bleue / Lutilisateur dcide dannuler la procdure en cours / etc..
R flots dvnements exceptionnels : Lutilisateur modifie la gare de dpart, puis suit le fonctionnement
principal (slection de la destination, etc.) / etc.
2.3 DIAGRAMMES COMPLMENTAIRES
Certains diagrammes optionnels permettent de prciser la description gnrale du fonctionnement du systme. Les
diagrammes de contexte permettent notamment de prciser la position du systme dans son environnement.
2.3.1 Le diagramme de contexte statique
Le diagramme de contexte statique permet de positionner le systme dans son environnement selon un point de
vue matriel. Le systme est donc dcrit physiquement, et non pas en termes de fonctionnalits.
De plus, pour chaque type dlment matriel extrieur au systme, il est prcis les nombres minimal et maximal
dlments, appels cardinalits, qui sont mis en jeu.

Ex. : Le diagramme de contexte statique dune borne automatique permettant dacheter un billet.

Figure 2.10 : exemple dun diagramme de contexte statique
Aucun ou au plus 1 utilisateur utilise la borne
automatique ( un instant donn).
Aucun ou au plus 1 serveur bancaire est utilis par
la borne automatique.
2.3.2 Le diagramme de contexte dynamique
Le diagramme de contexte dynamique permet de positionner le systme dans son environnement selon le point de
vue des communications. Il reprend les lments du contexte statique et prcise les changes dinformations qui sont
raliss entre le systme et les lments matriels extrieurs au systme. Le systme est donc dcrit physiquement et
logiquement.

Ex. : Le diagramme de contexte dynamique dune borne automatique permettant dacheter un billet.

Figure 2.11 : exemple dun diagramme de contexte dynamique
18 / 49
2.4 COMPLMENTS SUR LES RELATIONS
2.4.1 La gnralisation
Une relation de gnralisation entre deux entits est une relation unidirectionnelle symbolisant que lune des
entits, lentit-fille, possde lintgralit des proprits et/ou du comportement de lautre entit, lentit-parente,
auxquels sajoutent les spcificits de lentit-fille (nda : on parle alors de spcialisation). La gnralisation ne peut
tre applique quentre entits de mme nature : 2 acteurs ou 2 cas dutilisation.
La gnralisation est reprsente par une flche tte triangulaire reliant les 2 entits dans le sens entit-fille Z
entit-parente.
Figure 2.12 : reprsentation graphique dune gnralisation
On peut ainsi dfinir une gnralisation entre deux acteurs, signifiant que lacteur-fils possde toutes les proprits
de lacteur-parent, ce qui inclut les relations avec les cas dutilisation. Par ailleurs, lacteur-fils possde en plus ses
propres proprits et relations avec dautres cas dutilisation.

Ex. : Tout administrateur, en plus de ses possibilits, peut aussi acheter un billet et donc se comporter tel un
utilisateur.

Figure 2.13 : exemple dune gnralisation entre acteurs
On peut dfinir une gnralisation entre deux cas dutilisation, prcisant ainsi que le cas dutilisation-fils propose le
mme comportement que le cas dutilisation-parent mais dans une version spcialise.

Ex. : Le cas dutilisation configurer les paramtres par dfaut est une spcialisation du cas dutilisation configurer
les paramtres.
Figure 2.14 : exemple dune gnralisation entre cas dutilisation
19 / 49
2.4.2 Linclusion
Une relation dinclusion entre deux cas dutilisation est une relation unidirectionnelle symbolisant que lun des cas
dutilisation, le cas dutilisation-inclusif, comprend lintgralit de lautre cas dutilisation, le cas dutilisation-inclus,
auquel sajoutent dautres lments de comportement. Le cas dutilisation-inclusif est donc un sur-ensemble du cas
dutilisation-inclus.
Linclusion est reprsente par une flche classique trait pointill reliant les 2 cas dutilisation dans le sens
cas dutilisation-inclusif Zcas dutilisation-inclus, prcise avec le prototype <<include>>.
Figure 2.15 : reprsentation graphique dune inclusion
Linclusion a un caractre obligatoire, et le cas dutilisation-inclusif peut prciser la position au sein de son propre
comportement du cas dutilisation inclus.

Cette relation est gnralement utilise pour dcomposer le comportement dun cas dutilisation en plusieurs
sous-cas dutilisation et permettre ainsi de dfinir une portion de comportement, le cas dutilisation-inclus, qui est
commune plusieurs cas dutilisation.

Ex. : Le cas dutilisation configurer les paramtres inclut la portion de comportement authentifier ladministrateur.
Figure 2.16 : exemple dune relation dinclusion
2.4.3 Lextension
Une relation dextension entre deux cas dutilisation est une relation unidirectionnelle symbolisant que lun des cas
dutilisation, le cas dutilisation-tendu, ajoute son propre comportement lintgralit du comportement de lautre cas
dutilisation, le cas dutilisation-de base. Le cas dutilisation-tendu est donc un sur-ensemble du cas dutilisation-de
base.
Lextension est reprsente par une flche classique trait pointill reliant les 2 cas dutilisation dans le sens
cas dutilisation-tendu Zcas dutilisation-de base, prcise avec le prototype <<extend>>.
Figure 2.17 : reprsentation graphique dune extension
Lextension peut tre soumise une condition, et celle-ci est alors prcise.

Cette relation est gnralement utilise pour modliser un cas dutilisation principal, le cas dutilisation de base, et
une extension de son comportement, le cas dutilisation tendu, celle-ci proposant donc une variante facultative ou
alternative.

Ex. : Le cas dutilisation acheter un billet prcommand sur internet est une extension du cas dutilisation acheter
un billet.
20 / 49
Figure 2.18 : exemple dune relation dextension
2.4.4 Exemple de diagramme de cas dutilisation complet
Figure 2.19 : exemple dun diagramme de cas dutilisation complet

Le diagramme de cas dutilisation permet donc daffiner le contenu du cahier des charges, afin de dterminer les
limites du systme en prsentant le systme dans son environnement, et en se recentrant sur le besoin utilisateur, donc
sur le quoi et aucunement sur le comment ; il permet de sassurer, par voie de consquence, que le systme rpond bien
aux exigences du client.
21 / 49
3 LES DIAGRAMMES DE SQUENCE
3.1 DFINITION
Les diagrammes de squence dcrivent le droulement de chaque cas dutilisation, en montrant la faon dont les
diverses entits mises en uvre dans les cas dutilisation interagissent et collaborent dans le temps afin de raliser les
fonctionnalits attendues.

Le but est de dterminer :
R les divers entits, appeles objets, mises en jeu dans la ralisation dune fonctionnalit ;
R les interactions entre ces divers objets ;
R le droulement dans le temps de ces interactions.

Le diagramme de squence est en ralit un cas particulier de diagramme dinteraction
1
ayant pour but de mettre en
avant laspect chronologique des interactions dcrites.

Typiquement, chaque cas dutilisation dtermin dans le diagramme des cas dutilisation fait lobjet dune tude
temporelle des interactions en utilisant un diagramme de squence. Par consquent, on doit avoir autant de
diagrammes de squence que de cas dutilisation ; occasionnellement, un cas dutilisation peut tre dcrit par plusieurs
diagrammes de squence afin de clarifier lensemble.

Les diagrammes de squence sont donc la suite logique du diagramme des cas dutilisation. En fonction du niveau
de dtail dsir, on peut les utiliser de deux manires diffrentes :
R forme simplifie : description sommaire du cas dutilisation en se basant sur la description textuelle fin de
la phase de spcification du systme ;
R forme dtaille : prsentation dune bauche de la structure du code objet phase de conception prliminaire.
3.2.1 Les objets
3.2.1.1 Dfinition
Un objet mis en uvre dans un diagramme de squence peut symboliser :
R un acteur, humain ou non-humain ;
R le systme, ou une partie ou composante de celui-ci.
Un objet est reprsent par un rectangle, ainsi quune ligne pointille verticale partant de ce rectangle et dirige vers
le bas qui reprsente ainsi la ligne de vie de lobjet. Dans le cas dun objet symbolisant un acteur, le rectangle peut tre
remplac par un personnage.

1
Tout comme le diagramme de collaboration/communication.
22 / 49
Figure 3.1 : reprsentation dun objet
3.2.2 Les interactions
3.2.2.1 Dfinition
Une interaction permet dexprimer une collaboration ou une communication ncessaire la mise en uvre de la
fonctionnalit tudie. De manire gnrale, une interaction est vue comme lenvoi dun message entre un objet
metteur et un objet destinataire.

Il est important de bien garder lesprit quune interaction nest pas reprsentative dun flux de donnes, mais dun
message ; lequel peut en revanche mettre en jeu un flux de donnes, de sens identique ou diffrent celui du message.

Une interaction peut tre interne, cest--dire tre mise par un composant dun objet destination dun autre
composant du mme objet ; en ce cas, le message est envoy par lobjet lui-mme ; on parle alors de message interne
ou message rflexif.
Une interaction est reprsente par une flche horizontale tte classique
1
, oriente de lobjet metteur vers lobjet
destinataire du message, prcise de lintitul du message.

Figure 3.2 : reprsentation dune interaction
Il faut noter quun message est de caractre synchrone ou asynchrone, selon que lobjet objet metteur soit ou pas
bloqu durant la prise en compte du message par lobjet destinataire
2
.
3.2.3 Les diagrammes : approche gnrale
Un diagramme de squence doit faire apparatre :
R tous les objets mis en uvre dans la ralisation de la fonctionnalit tudie ;
R toutes les interactions montrant les communications et collaborations entre les objets.

Par ailleurs, le diagramme de squence mettant laccent sur la chronologie des interactions entre objet, laspect
temporel est pris en compte par la dimension verticale du diagramme, avec un coulement du temps qui va du haut
vers le bas, ce qui permet de prciser lordre des messages changs ; les messages peuvent cependant tre
ventuellement numrots.
En revanche, la position horizontale des objets les uns par rapport aux autres est sans importance
3
.
1
En ralit, les flches dcrivant les interactions peuvent possder diverses ttes diffrentes ayant une signification particulire.
2
cf. 3.4.5.
3
Cest donc gnralement le souci de lisibilit qui guide ce choix.
23 / 49
temps
Figure 3.3 : reprsentation dun diagramme de squence
3.3 UTILISATIONS
3.3.1 Forme simplifie : documentation dun cas dutilisation
La forme simplifie des diagrammes de squence permet de dcrire graphiquement le cas dutilisation, et ainsi de
complter la documentation de celui-ci. Gnralement, le diagramme de squence associ un cas dutilisation est
construit sur la base de la description textuelle ou en pseudo-code de celui-ci, ou bien peut sy substituer.
Le diagramme de squence se concentre alors principalement sur la description temporelle des interactions du
systme avec les lments extrieurs. Il sagit de montrer la progression de la squence dans le temps ; les messages
changs sont donc de type asynchrone, car les objets communiquent mais restent indpendants les uns des autres
1
.
3.3.1.1 Description du flot dvnements principal
Si la description textuelle ou en pseudo-code du cas dutilisation a t faite, il suffit de retranscrire celle-ci
graphiquement. On visualise ainsi la suite dans le temps des interactions entre le systme et les acteurs.

Ex. : Pour le diagramme de squence du cas dutilisation dcrivant laction dacheter un billet de train en utilisant
une borne automatique, le flot dvnements principal est le suivant : lutilisateur slectionne, grce au clavier, sa
destination, la classe du billet (premire ou seconde), insre sa carte bleue, paie le montant demand, puis enfin retire
le billet qui est imprim par la borne.

Figure 3.4 : exemple dun diagramme de squence simplifi
3.3.1.2 Description des flots dvnements alternatifs et exceptionnels
Les diagrammes de squence reprsentent la chronologie des interactions changes dans le sens vertical ; il nest
donc pas toujours trs simple de reprsenter les comportements non squentiels (structures conditionnelles, rptitives,
rcursives ou concurrentes). Aussi, prcise-t-on gnralement ceux-ci ainsi que tout comportement particulier en
gnral sous la forme de notes insres en marge du diagramme de squence, la hauteur temporelle adquate.

1
On parle alors de flot de contrle plat.
24 / 49
Ex. : Pour le diagramme de squence du cas dutilisation dcrivant laction dacheter un billet de train en utilisant
une borne automatique, il y a un seul flot dvnements exceptionnel qui est le suivant : lutilisateur modifie la gare de
dpart, puis suit le fonctionnement principal (slection de la destination, etc.).

Figure 3.5 : exemple dun diagramme de squence simplifi annot
3.3.2 Forme dtaille : clatement du systme en classes
Le systme tait vu jusqu prsent comme une bote noire. La forme dtaille des diagrammes de squence permet
de mettre en vidence les diffrentes composantes du systme, tout comme elle permet de dcrire plus prcisment les
interactions entre les objets.
Cette forme dtaille se dduit de la forme simplifie en cherchant se rapprocher du code objet, sachant que :
R Les diffrents acteurs seront reprsents par des instances de classe ;
R Les diffrentes composantes du systme seront reprsentes par des instances de classe ;
R Les interactions seront reprsentes par des messages changs entre des instances de classes, cest--dire des
appels de mthode ;
R Les interactions internes sont reprsentes par des interactions entre diverses composantes du systme, cest-
-dire des appels de mthode partir dautres mthodes la mthode appelante et la mthode appele
appartenant ou pas la mme classe.

Les acteurs et les composantes correspondent des instances de classe, mais celles-ci nont pas t nommes. Si on
ne dcide pas dun nom pour une instance, celle-ci est donc littralement anonyme et on ne connat que la classe
laquelle elle appartient ; la notation de lobjet sur le diagramme de squence est donc modifie de la sorte :
<objet anonyme> : NomClasse, not : NomClasse.
Si on dcide de donner un nom une instance, la notation de lobjet sur le diagramme de squence est alors
modifie ainsi : nomObjet : NomClasse.
Les interactions correspondent gnralement des appels de mthodes (/appels de procdures)
1
, soit donc des
message synchrones
2
. Elles sont reprsentes par des flches ttes triangulaire
3
et leur notation sur le diagramme est
modifie de la sorte : message(), ce qui permet aussi de signifier les ventuels paramtres dappel :
message(paramtres). Lobjet metteur du message est celui qui ralise lappel de mthode de lobjet
destinataire ; la mthode appartient donc lobjet destinataire.

1
Plus rarement, une interaction peut traduire un vnement, un signal, une interruption matrielle,
2
On parle alors de flot de contrle embot.
3
cf. 3.4.5.
25 / 49
Figure 3.6 : reprsentation dun diagramme de squence dtaill
Dans la reprsentation ci-dessus, lobjet objet2 de la classe Classe2 effectue lappel de la mthode
autre_message( ) de lobjet anonyme de la classe Classe3 et lui passe un paramtre.
3.3.2.1 Recherche des classes
Dcomposer le systme revient donc dterminer les diffrentes classes qui le composent. Pour cela, sur la base des
diagrammes de squence dans leur version simplifie, on recherche nominativement les classes potentielles de manire
intuitive, auxquelles on applique ensuite la technique CRC (Classe / Responsabilit / Collaboration). Cest--dire que
pour chaque classe potentielle, il faut rechercher ses responsabilits et ses collaborations.
R responsabilit (parfois appele aussi service) : description de haut niveau de la raison dtre dune classe, qui
dcrit lun des objectifs attendus de la classe au sein du systme ;
R collaboration : interaction de la classe potentielle avec dautres classes du systme ncessaire la ralisation
dune responsabilit.

Nom de la classe potentielle
Responsabilit 1 Nom de la / des classe(s) de la collaboration / <rien>

Responsabilit N
Au final, pour chaque classe analyse on doit avoir :
R une ou plusieurs responsabilit(s) bien dfinie(s), sans doublon avec les responsabilits dune autre classe ;
R au moins une collaboration avec une autre classe pour lune ou lautre de ses responsabilits.

On doit donc retrouver lensemble des actions mener par le systme dans les responsabilits ralises par lune ou
lautre des classes.

Ex. : Dans le cas dutilisation acheter un billet de train, on note un ensemble de classes potentielles priori
ncessaires au bon fonctionnement du systme : Systme, Clavier, cran, Imprimante, Trajet.

Systme
Grer le fonctionnement du systme et le
droulement du processus

Clavier
Attendre les saisies de lutilisateur Utilisateur
Transmettre les donnes saisies Systme
cran
Afficher des messages publicitaires
Recevoir les informations Systme
Afficher les informations
Imprimante
Recevoir les informations Systme
Imprimer le billet
Trajet
Stocker les donnes dun trajet Systme
Autres classes potentielles : LecteurCarteBleue (lit les infos de la CB), etc.
26 / 49
3.3.2.2 Modification des diagrammes de squence
Une fois les classes potentielles analyses et valides, il suffit de les insrer dans les diagrammes de squence dans
leur forme simplifie, la place de lobjet systme , et de complter les messages ncessaires la description du
fonctionnement du cas dutilisation. On obtient ainsi les diagrammes de squence dans leur forme dtaille.

Ex. : Le diagramme de squence du cas dutilisation dcrivant laction dacheter un billet de train en utilisant une
borne automatique.

Figure 3.7 : exemple dun diagramme de squence dtaill
3.4 COMPLMENTS
3.4.1 Strotypes de Jacobson
Les strotypes de Jacobson
12
sont des catgories de classes qui permettent de prciser un rle gnrique pour 1
ou plusieurs classes du systme par rapport son fonctionnement global.
On dispose ainsi de 3 strotypes diffrents :
R <<boundary>> (frontire) : classe faisant office dIHM ;
R <<control>> (contrle) : classe contrlant le systme (gnralement une seule) ;
R <<entity>> (entit) : classe de stockage de donnes (gnralement sans mthodes autre que mthodes
accesseurs
3
).

Figure 3.8 : reprsentation graphique des classes selon les strotypes de Jacobson
Ex. : Les classes du diagramme de squence du cas dutilisation dcrivant laction dacheter un billet de train en
utilisant une borne automatique.

1
Des strotypes de classe autres que de Jacobson existent.
2
Lun des fondateurs du langage UML.
3
get( ) / set( ).
27 / 49
Figure 3.9 : exemple dun diagramme de squence en utilisant les strotypes de Jacobson
Les strotypes de Jacobson sont ainsi une bonne base de dpart pour la recherche des classes potentielles ; en effet,
dans tout systme, il est rare de ne pas disposer dune classe <<control>>, dau moins 1 classe <<boundary>>, et
dune ou plusieurs classes <<entity>>.
3.4.2 Flot de contrle
Le terme de contrle dtermine lobjet actif linstant t dans le droulement du cas dutilisation. Au dpart, le
contrle est initi par un objet (gnralement un acteur), lorsque celui-ci envoie un message lun des objets du
systme. Se faisant, il passe le contrle cet objet, qui lui-mme passe le contrle un autre objet lorsquil envoie un
message, etc.
Le terme de flot de contrle, ou flot dexcution, dsigne le droulement du cas dutilisation du point de vue de la
suite dobjets actifs au fur et mesure des appels de mthode.

Figure 3.10 : flot de contrle
3.4.3 Priode dactivit
Une priode dactivit, ou dure dactivation, dun objet correspond un temps durant lequel lobjet est en activit,
cest--dire une priode pendant laquelle :
R Lobjet effectue directement une action (il possde le contrle) ;
R Une action est ralise par un autre objet quil a lui-mme mandat (il a pass le contrle), objet qui est donc
galement en activit.

Lactivit dun objet ne correspond pas sa dure de vie
1
, et est gnralement dclenche par la rception dun
message, lequel peut donc tre qualifi de stimulus dactivation. Un mme objet peut ainsi tre en activit plusieurs
fois pendant le droulement du cas dutilisation sil reoit plusieurs stimuli dactivation.

Une priode dactivit est reprsente par une bande rectangulaire sur la ligne de vie de lobjet en activit,
positionne prcisment sur laxe vertical et dterminant ainsi le dbut et la fin de la priode dactivit.

1
Mme si un objet doit bien entendu exister pour pouvoir tre en activit.
28 / 49
Figure 3.11 : reprsentation dune priode dactivit
3.4.4 Messages de cration et de destruction dinstance
Les objets prsents sur un diagramme de squence ont gnralement une ligne de vie qui stend sur toute la
hauteur diagramme. Nanmoins, les interactions peuvent dsigner explicitement la cration ou la destruction
dinstance lors du droulement du diagramme de squence.
La cration dinstance se reprsente par un message pointant sur le rectangle du nom de lobjet, et non sur sa ligne
de vie, signifiant ainsi que le message cre lobjet. ventuellement, un message de cration dinstance peut tre
reprsent comme un message prcis du strotype <<create>>, pointant sur la ligne de vie de lobjet.
La destruction dinstance se reprsente par un message la suite duquel la ligne de vie est interrompue et marque
dune croix ; le message peut tre prcis par le prototype <<destroy>>.
Figure 3.12 : reprsentation des messages de construction et de destruction dinstance

29 / 49
3.4.5 Messages synchrones et asynchrones
Les interactions peuvent tre synchrones ou asynchrones en fonction du message quelles vhiculent :
R interaction synchrone (appel de mthode/procdure) : lobjet metteur doit attendre la ralisation complte
par lobjet destinataire de lopration spcifie par le message ; lobjet metteur peut ainsi superviser la
ralisation de lopration ;
R interaction asynchrone (envoi de message) : lobjet metteur nest pas bloqu durant la ralisation par lobjet
destinataire de lopration spcifie par le message ; de fait, lobjet metteur na pas de moyen de superviser
la ralisation de cette opration.

De plus, une interaction peut dsigner spcifiquement la fin de la ralisation dune opration en indiquant
explicitement le retour dun appel de mthode. Le retour de mthode/procdure est gnralement implicite la fin
dune priode dactivit, mais il peut tre utile de le mentionner explicitement pour apporter des informations sur le
retour de lappel de mthode (paramtre ou valeur de retour, par exemple), ou bien lors de lutilisation de messages
asynchrones afin de permettre la synchronisation entre objets.

Un message synchrone est reprsent par une flche tte triangulaire et trait plein. Un message asynchrone est
reprsent par une flche horizontale tte classique et trait plein ; il peut tre aussi ventuellement reprsent par une
demi-flche
1
).
Un retour dappel de procdure explicite est reprsent par une flche classique trait pointill.

Figure 3.13 : reprsentation des messages synchrones et asynchrones
3.4.6 Reprsentation des comportements non squentiels : tests et boucles
Les comportements non squentiels, non linaires dans le temps, peuvent tre reprsents par des annotations en
marge du diagramme de squence. On peut ainsi dcrire facilement des structures conditionnelles (tests) et des
structures itratives (boucles).

Figure 3.14 : reprsentation des comportements non squentiels
Nb : UML v2 a introduit la notion de cadres dinteraction et de fragments qui permettent notamment de reprsenter
de manire standard les structures conditionnelles et itratives.

1
Avant UML v1.4.
30 / 49
3.4.7 Syntaxe complte des messages
Les interactions peuvent tre prcises par des indicateurs associs aux messages.

La syntaxe complte est la suivante :
prcdents / [conditions] numro *[rptition] : variable = nomMessage(paramtres).
R prcdents : liste des messages devant tre envoys avant celui-ci ;
R [conditions] : conditions ncessaires lenvoi du message, ex : [X = 1], [t < 5s] ;
R numro : numro du message parmi lensemble des messages ;
R *[rptition] : conditions de rptition du message, ex. : *[i := 1..2] ;
R variable = : rcupration de la valeur de retour renvoye par le message, ex. : val = message() (valeur
de retour de la mthode) ;
R paramtres : valeur des paramtres avec lesquels le message doit tre envoy (valeur des paramtres
dentre de la mthode).
3.5 COMPLMENTS
3.6.1 Les diagrammes de collaboration
3.6.2 Les diagrammes dactivits
3.6.3 Les diagrammes dtats-transitions

Le rle fondamental des diagrammes de squence est donc de faire merger les classes, ainsi que leurs mthodes.
31 / 49
4 LE DIAGRAMME DE CLASSES
4.1 DFINITION
Le diagramme de classes reprsente, de manire statique, les classes qui composent le systme, ainsi que les
relations existant entre elles.

Le but est de dcrire :
R la structure statique interne prcise de chacune des classes (attributs et mthodes) ;
R les relations entre les classes mises en uvre.

Le diagramme de classes, qui est unique, se construit en partie laide des informations issues des diffrents
diagrammes de squence. Il permet dobtenir, laide dun outil logiciel appropri
1
, le squelette du code par
gnration automatique de code
2
; il sagit donc de la dernire tape danalyse juste avant le codage proprement dit.
Par consquent, il fait partie de la conception dtaille du systme.

Une bauche de diagramme de classes peut aussi tre produite en phase de spcification, aprs lanalyse du cahier
des charges et la production du diagramme de cas dutilisation afin dorienter les phases de conception ; on parle alors
de diagramme de classes danalyse. Cette bauche est par la suite complte lors de la phase de conception dtaille.
Larchitecture statique dun systme fait tat de :
R classes ;
R interfaces : classes non-instanciables
3
servant de modle pour dautres classes ;
R paquetages : regroupement de classes et de leurs relations.

Les relations pouvant exister entre les classes se dpartagent en plusieurs catgories :
R gnralisation : hritage entre deux classes ;
R ralisation : hritage dans le cas dune classe de base type interface ;
R association : utilisation dune instance dune classe partir dune instance dune autre classe en tant
quattribut-objet ;
R agrgation : association avec une notion dappartenance et cration de linstance de lattribut-objet ;
R composition : agrgation avec cration + destruction de linstance de lattribut-objet ;
R classe dassociation : colution dune association vers le concept de classe ;
R dpendance : instanciation ou utilisation dune instance dune classe par une autre ntant pas dterminante
pour leur structure interne.
4.2.1 Les classes
4.2.1.1 Dfinition
Une classe dfinit la description abstraite, servant de modle, dun ensemble dobjets ayant un tat similaire, un
comportement identique, mais une identit diffrente.

1
AGL (StarUML, BoUML, Entreprise Architect, Objeteering, Rational Rose, ).
2
Code engineering (eng).
3
volution POO de la notion de classe abstraite.
32 / 49
Les tapes prcdentes de lanalyse, et principalement celles ralises lors de la conception prliminaire
1
, guident
pour la dtermination des classes.
En effet, tous les objets mis en vidence prcdemment (diagrammes de squence) sont susceptibles dtre
considrs comme des instances de classe ; on en dduit donc les classes. Dautres classes, notamment des classes de
gnralisation, peuvent tre rajoutes si leur ncessit apparat.
Les messages reus par un objet sont eux susceptibles dtre considrs comme des mthodes, lmetteur du
message ralisant alors un appel de lune des mthodes du destinataire ; la mthode exacte est celle correspondant au
contenu du message.

La dfinition dune classe comprend imprativement les 3 lments suivants :
R nom de la classe : description du modle dobjets ;
R attributs : informations qualifiant lobjet, variables associes la classe ;
R mthodes : comptences, oprations, actions et ractions de lobjet, fonctions associes la classe.
Une classe se reprsente par un cadre plusieurs niveaux : nom, attributs et mthodes.

Figure 4.1 : reprsentation graphique dune classe
Outre le nom de la classe, on peut prciser :
R lindication NomClasse : class pour ter tout doute ;
R classe abstraite : nom de la classe en italique.

Pour chaque membre sont prcises toutes les informations ncessaires la dfinition exacte de larchitecture
interne de la classe.

Pour un attribut, la syntaxe est :
visibilit nomAttribut : modificateurs type multiplicit = valeur_initiale.
R visibilit : + (public) / # (protg) / (priv) ;
R type : boolean / short / int / char / float / double (types primitifs) / autre classe (type complexe) ;
R multiplicit : [] (tableau) / * (pointeur) / & (rfrence) ;
R modificateurs : const (constant) / static ou nom de lattribut soulign (statique).

Pour une mthode, la syntaxe est :
visibilit nomMthode(paramtres) : modificateurs type multiplicit.
R visibilit : + (public) / # (protg) / (priv) ;
R type : void / boolean / short / int / char / float / double (types primitifs) / autre classe (type
complexe) ;
R paramtres : type primitif ou complexe de chaque paramtre, spars par une virgule, ventuellement avec
leur nom ;
R multiplicit : [] (tableau) / * (pointeur) / & (rfrence) ;
R modificateurs : const (constant) / static ou nom de la mthode souligne (statique) / virtual (virtuelle) /
abstract ou nom de la mthode en italique (abstraite / virtuelle pure).

Nb : Lorsquun attribut correspond une instance dune classe spcifique au systme, gnralement on ne lintgre
pas dans la liste des attributs, mais on utilise une association, afin de mettre en avant une relation avec une autre
classe.

Ex. : La classe BorneAutomatique dun systme de borne automatique permettant dacheter un billet de train.

1
Les diagrammes de squence dtaills.
33 / 49
Figure 4.2 : exemple de reprsentation graphique dune classe
Le nom de la classe peut tre ventuellement prcd par la prcision dun strotype (<<class>>,
<<interface>>, <<entity>>, <<control>>, etc.).

Figure 4.3 : reprsentation graphique dune classe strotype
4.2.2 Les interfaces
4.2.2.1 Dfinition
Une interface est un type de classe spcifique, qui peut tre dfinie comme tant une classe abstraite dont toutes les
mthodes sont abstraites
1
et qui ne possde aucun attribut
2
. Une interface reprsente ainsi une classe- concept .

On peut assimiler une interface une classe de services, cest--dire une classe qui est utilise par dautres classes
pour leur donner un cadre dimplmentation des fonctionnalits (/services) quelles doivent proposer.
En dautres termes, une interface ne fait que reprsenter, sans limplmenter, un comportement (quoi) que doivent
suivre certaines classes, laissant ainsi la libert chaque classe de limplmenter selon ses besoins (comment).

Nb : Le principe dinterface nest pas implment dans tous les langages orients objet : il est par exemple prsent
en Java et en C#, mais absent en C++
3
.
Une interface peut se reprsenter de deux manires :
R comme une classe, except quon prcise le strotype <<interface>>, ce qui permet ainsi de donner le
dtail des attributs et mthodes ;
R cercle nomm.

Figure 4.4 : reprsentation graphique dune interface
4.2.3 Les paquetages
4.2.3.1 Dfinition
Un paquetage dsigne un regroupement de classes ou interfaces, ainsi que leurs relations. Lide est de rassembler
des classes ayant le mme type dutilit, appartenant une mme thmatique ou qui collaborent dans un mme but ; on
rassemblera par exemple une classe de base avec ses classes drives surtout si la classe de base est abstraite.
Un paquetage est reprsent par un cadre avec onglet entourant les classes qui en font partie. Le nom peut tre
prcis dans le haut du cadre ou bien dans longlet.

1
Abstraite b virtuelle pure.
2
Dans certains langages, le concept dinterface a quelque peu driv et peut possder des attributs. Ex : en Java, une interface a des attributs
obligatoirement constants.
3
Rien nempche cependant de dfinir une classe abstraite dont toutes les mthodes sont virtuelles pures.
34 / 49
Figure 4.5 : reprsentation graphique dun paquetage
4.2.4 Les gnralisations et les spcialisations
4.2.4.1 Dfinition
La gnralisation dans un ensemble de classes dsigne la mise en commun dattributs et de mthodes au sein dune
classe-mre ; chaque classe possde les attributs et mthodes de sa classe-mre auxquels viennent sajouter les
membres propres la classe.
Inversement, la spcialisation dsigne la propagation des attributs et des mthodes dune classe dans une classe-
fille, laquelle peut intgrer des membres supplmentaires.
La gnralisation/spcialisation est mise en uvre par le mcanisme dhritage (/drivation) de la POO.
La gnralisation dune classe vers une autre se reprsente par une flche tte triangulaire et trait plein reliant les 2
classes dans le sens classe spcialise Zclasse gnrale.
Figure 4.6 : reprsentation graphique dune gnralisation
4.2.5 Les ralisations
4.2.5.1 Dfinition
La ralisation dans un ensemble de classes correspond au principe de gnralisation pour laquelle la classe
gnralise (la super-classe) est une interface. On dit alors que la classe spcialise implmente linterface.
La ralisation dune interface par une classe peut se reprsenter de deux manires :
R cas dune interface reprsente comme une classe strotype : par une flche tte triangulaire et trait
pointill reliant les 2 entits dans le sens classe ralisatrice Zinterface ;
R cas dune interface reprsente selon un cercle nomm : par un simple trait plein.

Figure 4.7 : reprsentation graphique dune ralisation
4.2.6 Les associations simples
4.2.6.1 Dfinition
Une association dsigne le cas o une instance dune classe utilise un objet dune autre classe en tant quattribut-
objet. Cependant, il nest pas de la responsabilit de la classe utilisatrice de crer ou de dtruire linstance utilise ; elle
doit se servir dun objet instanci par une autre classe afin dinitialiser son attribut-objet.

Le couplage entre les classes est faible, et les deux classes restent relativement peu dpendantes lune de lautre.
35 / 49
Une association se reprsente par une flche tte classique (non-triangulaire) et trait plein, oriente dans le sens de
la navigabilit classe utilisatrice Zclasse utilise.
Lassociation peut tre prcise par diverses informations textuelles :
R le nom : dsigne lutilit de lassociation, prcise ventuellement du sens de lecture (< / >) ;
R le rle de chacune des classes : dcrit comment chaque classe est vue par lautre travers lassociation ;
R la cardinalit de chacune des classes : prcise le nombre dinstances impliques dans lassociation :
U 1 ou rien : exactement 1 ;
U X : exactement X ;
U 0..1 : 0 ou 1 ;
U 0..* ou * : plusieurs ;
U X..Y : X Y ;
U X..* : X plusieurs ;
U X..Y, U..V : X Y plus U V.

Figure 4.8 : reprsentation graphique dune association
Ex. : La borne automatique utilise le serveur bancaire. La classe BorneAutomatique du systme utilise un objet de
la classe ServeurBancaire (BorneAutomatique appelle la mthode enregistrer_transaction() de
ServeurBancaire ; BorneAutomatique utilise donc une instance de ServeurBancaire).

Figure 4.9 : exemple dassociation
Dans le cadre de lassociation BorneAutomatique transfre la transaction bancaire
ServeurBancaire :
Un serveur bancaire est susceptible dtre contact
par plusieurs bornes automatiques diffrentes ; en
revanche, on peut imaginer que certains serveurs
bancaires ne seront jamais contacts par une borne
automatique (0..*).
Une borne automatique fait toujours appel 1
serveur bancaire pour finaliser la transaction ; la
complexit des partenariats inter-bancaires induit
que la borne peut ncessiter de faire appel
plusieurs serveurs bancaires (1..*).

Nb : Le rle est gnralement utilis comme nom dinstance lorsque lassociation est implmente dans un
programme en langage orient objet. De fait, le rle peut ventuellement tre prcis par un indicateur de visibilit (ici
- devant demandeur et mandataire prcisant une visibilit prive).

On peut mentionner les cas particuliers suivants :
R association bidirectionnelle : chacune des classes utilise une instance de lautre classe ; lassociation est alors
reprsente non-flche, indiquant quelle est navigable dans les 2 sens ;
R association rflexive : la classe utilise une instance delle-mme ; lassociation est alors reprsente par un
lien qui revient sur la mme classe ;
R association multiple : les classes ont plusieurs relations distinctes entre elles ; auquel cas, on prend alors soin
de prciser le nom de chaque association et pour chacune dentre elles le rle de chaque classe, afin de
distinguer lutilit des diffrentes relations ;
R association n-aire : lassociation relie plus de 2 classes distinctes ; lassociation est reprsente par une toile
n branches dont chacune dentre elles est relie lune des classes de lassociation, et dont le centre est un
losange ; les associations n-aires peuvent tre trs facilement transformes en classes dassociation
1
.
1
cf. 4.2.9.
36 / 49
4.2.7 Les agrgations
4.2.7.1 Dfinition
Une agrgation dsigne un type particulier dassociation laquelle sajoute un concept dappartenance ; lobjet
utilis fait partie de la classe utilisatrice, et est indispensable sa cration complte. La classe utilisatrice est donc
responsable de la cration de linstance utilise ; en revanche, elle nest pas responsable de sa destruction, mme si
cela est fortement conseille. Malgr tout, linstance reste partageable entre plusieurs instances de la classe utilisatrice,
tout comme des instances dautres classes, et celles-ci peuvent donc lutiliser.
Dans le cadre de cette agrgation, la classe utilisatrice est alors appele agrgat et lobjet utilis agrg.
Le couplage entre les deux classes est donc suprieur celui dune simple association ; il a nanmoins ses limites
car les instances de lagrgat et de lagrg ont chacune une dure de vie propre : lagrg est cr en mme temps que
lagrgat, mais il peut continuer dexister mme si lagrgat est dtruit, surtout sil est utilis par dautres instances.

Nb : Lagrgation peut aussi tre appele agrgation par rfrence, d la manire dont on limplmente
gnralement en langage orient objet.
Une agrgation se reprsente par une association oriente dans le sens classe agrgat Z classe agrge possdant
un losange vide du ct de lagrgat.

L aussi, lagrgation peut tre prcise par le nom, les rles et les cardinalits.

Figure 4.10 : reprsentation graphique dune agrgation
Ex. : La borne automatique est faite dun cran, elle est incomplte si elle nen dispose pas dun ; si la borne
automatique est dmonte, lcran peut tre r-utilis. La classe BorneAutomatique du systme instancie un objet de
la classe Ecran (BorneAutomatique possde une instance de Ecran parmi ses attributs).

Figure 4.11 : exemple dagrgation
Dans le cadre de lassociation BorneAutomatique envoie des informations afficher Ecran :
Un cran affiche des informations qui lui sont
ncessairement envoyes par une borne
automatique ; les informations affiches ne
peuvent cependant jamais provenir que dune seule
et mme borne automatique (1).
Une borne automatique fait toujours usage dun
cran afin dafficher les diffrents messages
dinformations ; en revanche un seul cran suffit
(1).

R agrgation navigable : en plus des proprits de lagrgation, lagrg possde parmi ses attributs un objet de
la classe de lagrgat et peut lutiliser (comme sil existait une association oriente dans le sens
agrg Zagrgat) ;
R agrgation rflexive : la classe possde une instance delle-mme ; lagrgation est alors reprsente par un
lien dagrgation pointant sur la mme classe.
4.2.8 Les compositions
4.2.8.1 Dfinition
Une composition dsigne un type particulier dagrgation laquelle sajoute un concept de partie dun tout .
Lobjet agrg fait partie intgrante de la classe agrgat, est indispensable sa cration complte, et nexiste que parce
quil est imprativement ncessaire lagrgat. Lagrgat est donc responsable de la cration de lagrg, mais aussi
de sa destruction. De fait, linstance ne peut pas tre partage entre plusieurs instances, quil sagisse dinstances de
lagrgat ou bien dinstances dautres classes, et une seule peut donc lutiliser.
37 / 49
Dans le cadre de cette composition, lagrgat est alors appel composite ou conteneur et lagrg composant ou
compos.
Le couplage entre les deux classes est trs important, et encore suprieur celui dune agrgation ; les instances du
composite et du composant ont une dure de vie commune : le composant est cr et dtruit en mme temps que le
composite, renforant le principe que le composant nest pas partageable.

Nb : La composition peut aussi tre appele agrgation par valeur, d la manire dont on limplmente
gnralement en langage orient objet.
Une composition se reprsente par une agrgation oriente dans le sens classe composite Z classe composant
possdant un losange plein du ct du composite.
La composition peut tre bien videmment prcise par le nom, les rles et les cardinalits.

Figure 4.12 : reprsentation graphique dune composition
Nb : Comme le composant nest pas partageable entre plusieurs instances du composite, la cardinalit du ct de
celui-ci ne peut donc prendre que la valeur 0 ou 1 (cardinalits : 1 / 0..1).

Une autre reprsentation possible de la composition insre le composant dans le composite sous forme de classe
imbrique. En ce cas, non seulement linstance nest pas partageable entre plusieurs instances (classe composite ou
autre classe), mais de plus la classe composant ne peut tre utilise par aucune autre classe.

Figure 4.13 : reprsentation graphique dune composition sous forme de classe imbrique
Ex. : La borne automatique ncessite la notion de trajet pour fonctionner ; si la borne automatique est mise hors-
service ou dmonte, les trajets sont dtruits. La classe BorneAutomatique du systme instancie un objet de la classe
Trajet (BorneAutomatique possde une instance de Trajet parmi ses attributs).

Figure 4.14 : exemple de composition
Dans le cadre de lassociation BorneAutomatique stocke les informations dans Trajet :

Un trajet ne peut tre associ qu une et une seule
borne automatique (1).
Une borne automatique ncessite toujours un trajet
afin de stocker les informations ; en revanche, elle
peut avoir grer plusieurs trajets en mme temps
(1..*).

R composition navigable : en plus des proprits de la composition, le composant possde parmi ses attributs
un objet de la classe du composite et peut lutiliser (comme sil existait une association oriente dans le sens
composite Zcomposant) ;
R composition rflexive : la classe possde une instance delle-mme ; la composition est alors reprsente par
un lien de composition pointant sur la mme classe.
38 / 49
4.2.9 Les classes dassociation
4.2.9.1 Dfinition
Une classe dassociation dsigne lvolution dune association vers le concept de classe. Il sagit donc de la
description dune relation dans laquelle une instance dune classe utilise un objet dune autre classe en tant quattribut-
objet, relation qui a t transforme en une modlisation abstraite de famille dobjets, rassemblant ainsi des variables
et des fonctions ddies la classe
1
. Parmi ses attributs, la classe dassociation possde un attribut-objet pour chacune
des 2 classes de lassociation ; gnralement, elle propose aussi des mthodes permettant daccder ses attributs-
objets de lextrieur de la classe.

Le couplage entre les classes est variable puisquune classe dassociation peut tre constuite sur la base dune
association simple, dune agrgation ou dune composition.

Lassociation dcrite par la classe dassociation est gnralement bidirectionnelle, mais peut ventuellement ntre
navigable que dans un seul sens.

Nb : La classe dassociation peut aussi tre appele classe-association ou classe associative. Lorsque la classe
dassociation nest connecte qu lassociation entre les 2 classes et na de relation avec aucune autre classe, on parle
alors dassociation attribue.
Une classe dassociation se reprsente en mlangeant les reprsentations dune association simple classique et dune
classe classique. Les deux classes de lassociation sont relies entre elles, gnralement par une association
bidirectionnelle ; la classe dassociation est raccorde lassociation par un trait pointill connect au trait plein.
Lassociation peut tre prcise par le nom, les rles et les cardinalits ; la classe dassociation peut tre prcise par
des attributs autres que les rfrences sur chacune des classes associes, et des mthodes autres que les accesseurs sur
les rfrences des classes associes.

Figure 4.15 : reprsentation graphique dune classe dassociation
4.2.10 Les dpendances
4.2.10.1 Dfinition
Une dpendance dsigne le cas o une entit utilise de manire quelconque une autre entit, sachant que ces entits
peuvent tre indiffremment classe, interface, paquetage, instance, mthode, attribut, Il sagit dun concept trs
gnral pouvant signifier diffrents types de relations entre deux entits qui ne dterminent aucunement ni ne donnent
dinformation sur larchitecture interne des entits.

Pour prciser le type de dpendance, on dispose de diffrents types de strotypes normaliss regroups en 4 types
de relations, pouvant reprsenter la description de (avec une dpendance de A ZB) :
R utilisation (strotype <<use>>) :
U linstanciation dun objet de la classe B dans une mthode de la classe A autre que le constructeur de A
(strotype <<instanciate>>) ;
U lutilisation dune rfrence sur une instance de la classe B comme paramtre dentre dune mthode de
la classe A (strotype <<create>>) ;
U lutilisation par une mthode de la classe A dune mthode statique de la classe B (strotype
<<call>>) ;
U lenvoi dun signal B par une mthode de la classe A (strotype <<send>>).

1
Exemple dapplication en modlisation de la maxime le tout vaut plus que la somme des parties .
39 / 49
R abstraction :
U la dfinition dune entit A partir dune entit B (strotype <<derive>>) ;
U limplmentation de lentit B par une entit A (strotype <<realize>>) ;
U la spcialisation dune entit B en une entit A lors du passage de lanalyse la conception (strotype
<<refine>>) ;
U le suivi des modifications dune entit B ayant t remanie en une entit A entre deux versions dune
mme modlisation (strotype <<trace>>).
R liaison (strotype <<bind>>) :
U l instanciation dune classe gnrique B avec dfinition complte des types des paramtres pour crer
une classe A.
R permission (strotype <<access>>) :
U la dclaration de lentit A comme amie de lentit B, permettant ainsi A daccder B quelque soit sa
visibilit (strotype <<friend>>).
Une dpendance se reprsente par une flche tte classique (non-triangulaire) et trait pointill oriente dans le sens
classe dpendante Z classe utilise, qui est prcise par un strotype, parmi les strotypes normaliss ou bien des
strotypes ddis.
Lindication du strotype nest pas obligatoire mais est fortement conseille pour renseigner sur le type de
dpendance.

Figure 4.16 : reprsentation graphique dune dpendance
4.2.11 Le diagramme
4.2.11.1 Dfinition
Au final, le diagramme de classes doit faire apparatre :
R toutes les classes et interfaces composant le systme ;
R larchitecture interne complte de chacune des classes ;
R toutes les relations dtermines entre toutes les diffrentes classes ;
R les associations transformes aprs tude en agrgation ou composition ;
R les regroupements ventuels de classes, interfaces et relations en paquetages.

Ce diagramme est unique ; cependant, pour des commodits de lecture il peut tre scind en plusieurs parties, en
paquetages par exemple, puis faire tat des relations entre paquetages ; on peut aussi mentionner toutes les classes
mais sans leur architecture interne qui est dtaille part, etc.
Ce diagramme est la synthse graphique de tous les lments quil doit reprsenter.

Pour sassurer de sa cohrence, plusieurs rgles doivent tre observes :
R Chaque classe ne doit tre reprsente quune seule fois ;
R Une classe a obligatoirement une relation avec au moins une autre classe ;
R On ne doit pas avoir plusieurs groupes de classes indpendants, moins que lon considre que lapplication
soit constitue de plusieurs processus diffrents sexcutant de manire concurrente (environnement multi-
tches).

Ex. : Diagramme de classes de la borne automatique.

40 / 49
Figure 4.17 : exemple dun diagramme de classes
4.3.1 Les diagrammes dobjet
4.3.2 Les diagrammes de composants
4.3.3 Les diagrammes de dploiement

41 / 49
A ORIGINES DU LANGAGE
A.1 HISTORIQUE
1991 : Dveloppement de OMT-1 (Objet Modeling Technique) par James Rumbaugh, aid de M. Blaha, W.
Premerlani, F. Eddy et W. Lorensen.
Dveloppement de Booch91 par Grady Booch.
1992 : Dveloppement de OOSE (Objet Oriented Software Engineering) par Ivar Jacobson Objectory AB.
1994 : volution de OMT-1 vers OMT-2.
volution de Booch91 vers Booch93.
1994 : Dbut de la collaboration entre Rumbaugh, Jacobson, et Booch au sein de la socit Rational Software.
1995 : Travail collaboratif entre Booch, Jacobson et Rumbaugh amenant la description publique dune mthode
unifie dans sa version 0.8.
1996 : Baptme de la mthode unifie sous le nom dUML (Unified Modeling Language) dans sa version 0.9.
1997 : Publication par Rational de UML v1.0, version propose lOMG pour standardisation.
Standardisation par lOMG de UML v1.1.
1999 : Engouement exponentiel et consensuel autour dUML dans sa version 1.3.
2001 : Publication de UML v1.4.
Publication de UML v2.1.
A.2 CONTRIBUTIONS
Nonobstant les 3 mthodes principales Booch, OMT et OOSE, un certain nombre de mthodes objet ont particip
llaboration dUML.

OOSE (Jacobson, Ivar) Cas dutilisation, strotype de classes.
OMT (Rumbaugh, James) Classes, instances et objets, attributs et mthodes, associations.
Booch (Booch, Grady) Classes, objets, attributs et mthodes, sous-systmes.
Meyer, Bertrand Thorie du contrat, pr- et post-conditions.
Harel, David Diagrammes tats-transitions.
Wirfs-Brock, Rebecca Responsabilits dune classe.
Beck, Kent / Cunningham, Ward CRC (Classe, Responsabilit, Collaboration).
Fusion (EROOS : Steegmans, Eric /
Boydens Jeroen / Delanote Geert)
Description des mthodes, numrotation des messages dans les
diagrammes dinteractions.
Gamma, Erich / Helm, Richard /
Johnson Ralph / Vlissides, John M.
Patrons de design, frameworks, notes.
Shlaer, Sally / Mellor, Stephen J. Cycle de vie des objets dans les diagrammes de squence.
Odell, James J. Classification dynamique, vnements.
Embley, David W. Objets composites et classes singletons
1
.
1
Une classe singleton ne peut offrir quune seule instance en mme temps ; autrement dit, toute nouvelle instanciation renvoie vers
linstance existante.
42 / 49
B LEXIQUE GRAPHIQUE
B.1 STRUCTURE STATIQUE
B.1.1 Classes
B.1.1.1 Classe
Cadre 3 encarts :
R 1er encart : nom de la classe ;
R 2nd encart : liste des attributs ;
R 3me encart : liste des mthodes.

NomClasse
attributs
methodes(...)

Figure B.1 : reprsentation UML dune classe
Reprsentation simplifie (dtails des attributs et des mthodes omis) :

NomClasse
Figure B.2 : reprsentation UML simplifie dune classe (1)
Reprsentation simplifie (encarts attributs et mthodes omis) :

NomClasse

Figure B.3 : reprsentation UML simplifie dune classe (2)
B.1.1.2 Classe abstraite
NomClasseItalique : classe abstraite (abstract).

NomClasseAbstraite
Figure B.4 : reprsentation UML dune classe abstraite
B.1.1.3 Classe strotype
<<stereotype>>
NomClasse

Figure B.5 : reprsentation UML dune classe strotype
43 / 49
B.1.1.4 Classe paramtrable

NomClasseParametrable
NomParametreGenerique1,
NomParametreGenerique2,
...
Figure B.6 : reprsentation UML dune classe paramtrable
B.1.1.5 Classe paramtre

NomClasseParametree
<type_paramtre_gnrique1, type_paramtre_gnrique2>

Figure B.7 : reprsentation UML dune classe paramtre
B.1.1.6 Interface
<<interface>>
NomInterface
NomInterface
Figure B.8 : reprsentation UML dune interface
B.1.2 Objets
B.1.2.1 Objet

nomObjet
attributs
methodes(...)

Figure B.9 : reprsentation UML dun objet
Reprsentation simplifie (encarts attributs et mthodes omis) :

nomObjet
Figure B.10 : reprsentation UML simplifie dun objet
B.1.2.2 Objet comme instance de classe

nomObjet : NomClasse
attributs
methodes(...)

Figure B.11 : reprsentation UML dun objet comme instance de classe
B.1.2.3 Objet anonyme

: NomClasse
attributs
methodes(...)

Figure B.12 : reprsentation UML dun objet anonyme
44 / 49
B.1.3 Paquetage

NomPaquetage
UneClasse AutreClasse
Figure B.13 : reprsentation UML dun paquetage
B.1.4 Membres
B.1.4.1 Membres
nomAttribut : dclaration dune variable associe la classe ;
nomMethode(...) : dclaration dune fonction associe la classe.

NomClasse
nomAttribut : type_attribut
nomMethode(...) : type_mthode
Figure B.14 : reprsentation UML dune classe et de ses membres
Attribut de type instance de classe / objet : cf. associations (B.2).
B.1.4.2 Visibilit
: priv (private) ;
# : protg (protected) ;
+ : public (public).

NomClasse
- nomAttribut1Prive : type_attribut1
# nomAttribut2Protege : type_attribut2
+ nomAttribut3Public : type_attribut3
- nomMethode1Privee(...) : type_mthode1
# nomMethode2Protegee(...) : type_mthode2
+ nomMethode3Publique(...) : type_mthode3
Figure B.15 : reprsentation UML dune classe, de ses membres et de leur visibilit
B.1.4.3 Membre statique
nomMembreSoulign : membre statique / de classe (static).

NomClasse
- nomAttributStatique : type_attribut
+ nomMethodeStatique(...) : type_mthode

Figure B.16 : reprsentation UML dune classe et des membres statiques
B.1.4.4 Mthode abstraite
nomMethodeItalique : abstraite / virtuelle pure (virtual).

45 / 49
NomClasseAbstraite
+ nomMethodeAbstraite(...) : type_mthode
Figure B.17 : reprsentation UML dune classe abstraite et dune mthode abstraite
B.2 ASSOCIATIONS
Utilisation dune instance dune classe par une autre classe en tant quattribut-objet.
Plusieurs cas possibles : association simple, agrgation et composition.
B.2.1 Association simple
Utilisation dune instance dune classe par une autre classe (a besoin de / ncessite) en tant quattribut-objet.
Aucune responsabilit vis--vis de la cration de linstance ou de la destruction de linstance.

ClasseNecessitee ClasseUtilisatrice
rle CU rle CI
Figure B.18 : reprsentation UML dune association
B.2.1.1 Association unidirectionnelle 1-1

ClasseB ClasseA
monB
Figure B.19 : reprsentation UML dune association unidirectionnelle 1-1
B.2.1.2 Association unidirectionnelle 1-plusieurs

ClasseB ClasseA
*
mesB
Figure B.20 : reprsentation UML dune association unidirectionnelle 1-plusieurs
B.2.1.3 Association bidirectionnelle
ClasseB ClasseA
monB monA

Figure B.21 : reprsentation UML dune association bidirectionnelle
B.2.1.4 Association rflexive
ClasseA
monPropreA
Figure B.22 : reprsentation UML dune association rflexive
B.2.2 Agrgation
Utilisation dune instance dune classe par une autre classe en tant quattribut-objet avec un couplage fort et des
dures de vies distinctes (est constitu de / est fait de / fait partie de) ; appele aussi agrgation par rfrence.
Responsabilit vis--vis de la cration de linstance, mme si celle-ci reste partageable avec dautres instances
(mme classe ou autre classe) ; responsabilit vis--vis de la destruction de linstance pas obligatoire mais fortement
conseille.

ClasseAgregee ClasseAgregat
rle rle
Figure B.23 : reprsentation UML dune agrgation
46 / 49
B.2.2.1 Agrgation 1-1
ClasseB ClasseA
monB
Figure B.24 : reprsentation UML dune agrgation 1-1
B.2.2.2 Agrgation 1-plusieurs

ClasseB ClasseA
*
mesB
Figure B.25 : reprsentation UML dune agrgation 1-plusieurs
B.2.2.3 Agrgation navigable

ClasseB ClasseA
monB monA

Figure B.26 : reprsentation UML dune agrgation navigable
B.2.2.4 Agrgation rflexive

ClasseA
monPropreA
Figure B.27 : reprsentation UML dune agrgation rflexive
B.2.3 Composition
Utilisation dune instance dune classe par une autre classe en tant quattribut-objet avec un couplage fort et des
dures de vies identiques (est compos de) ; appele aussi agrgation par valeur.
Responsabilit complte vis--vis de la cration de linstance ainsi que de la destruction de linstance ; instance
partageable avec aucune autre instance (mme classe ou autre classe).

ClasseComposant ClasseComposite
rle rle
Figure B.28 : reprsentation UML dune composition
Reprsentation alternative : classe imbrique Z instance partageable avec aucune autre instance (mme classe ou
autre classe) + classe utilisable par aucune autre classe.

ClasseComposite
ClasseComposant
Figure B.29 : reprsentation UML dune composition sous forme de classe imbrique
B.2.3.1 Composition 1-1
ClasseB ClasseA
monB
Figure B.30 : reprsentation UML dune composition 1-1
B.2.3.2 Composition 1-plusieurs

ClasseB ClasseA
*
mesB
Figure B.31 : reprsentation UML dune composition 1-plusieurs
47 / 49
B.2.3.3 Composition navigable

ClasseB ClasseA
monB monA

Figure B.32 : reprsentation UML dune composition navigable
B.2.3.4 Composition rflexive

ClasseA
monPropreA
Figure B.33 : reprsentation UML dune composition rflexive
B.3 SPCIALISATION / GNRALISATION
B.3.1 Spcialisation
Spcialisation : dune super-classe vers une sous-classe ;
Gnralisation : dune sous-classe vers une super-classe.

ClasseSpecialisee ClasseGeneralisee
spcialisation
gnralisation
Figure B.34 : reprsentation UML dune gnralisation / spcialisation
B.3.2 Ralisation

ClasseRealisatrice
<<interface>>
NomInterface
NomInterface
ClasseRealisatrice
Figure B.35 : reprsentation UML dune ralisation
B.4 CLASSE DASSOCIATION
volution dune association vers le concept de classe, possdant la fois les caractristiques dune association et
celles dune classe.

ClasseB ClasseA
monB monA
ClasseAB
Figure B.36 : reprsentation UML dune classe dassociation
48 / 49
B.5 DPENDANCES
Instanciation, utilisation ou tout autre besoin smantique entre deux entits (classe, interface, paquetage, instance,
mthode, attribut, ) ne conditionnant ni napportant de signification quant la structure interne de ces entit (utilise /
est abstraction de / est li / a permission sur).
Concept trs gnral pouvant signifier diffrents types de relations entre une entit A et une entit B, gnralement
caractris par lusage dun strotype ; 4 types de relations de dpendance :
R utilisation (strotype <<use>>) : strotypes <<instanciate>>, <<create>>, <<call>>, <<send>> ;
R abstraction : strotypes <<derive>>, <<realize>>, <<refine>>, <<trace>> ;
R liaison (strotype <<bind>>) ;
R permission (strotype <<access>>) : strotype <<friend>>.
ClasseUtilisee ClasseDependante
<<strotype>>
Figure B.37 : reprsentation UML dune dpendance

49 / 49
C BIBLIOGRAPHIE
Alonso Stphane, Cours UML, TS IRIS LEGT Louis Modeste-Leroy vreux, 2004 ;

Dumas Alex Jean-Pierre, Cours UML, UFTI IUFM Toulouse, 1998 ;

Muller Pierre-Alain, Gaertner Nathalie, Modlisation objet avec UML, Eyrolles, 2000 ;

Roques Pascal, UML par la pratique, Eyrolles, 2003 ;

Dumas Alex Jean-Pierre, UML Gestion dune ferme, UFTI IUFM Toulouse, 1997 ;

Hrauville Stphane, Cours UML, CFAI Marcel Sembat Sotteville-ls-Rouen, 2002 ;

Courseille Annie, Introduction au langage UML, UFTI IUFM Toulouse, 1998 ;

Roy Yves, La notation UML, 2002 ;

Charroux Benot, Cours UML, http://perso.efrei.fr/~charroux/, EFREI Villejuif, 1999 ;

Bouzy Bruno, Notes de cours UML, http://www.math-info.univ-paris5.fr/~bouzy/enseign.html, Centre de
Recherche en Informatique de Paris 5 UFR mathmatiques et informatique Universit Paris Descartes, 2001 ;

Bichon Jean, Cours de Systme dInformation Approche objet,
Licence informatique UFR Mathmatiques et Informatique Universit Bordeaux 1, 2004 ;

Essanaa S., Support de cours CSI, http://www.esct.rnu.tn/site/etud.html,
cole Suprieure de Commerce de Tunis Universit de La Manouba, 2007 ;

CommentaMarche.net, http://www.commentcamarche.net/, 2006 ;

Dveloppez.com, Langage UML, http://uml.developpez.com/, 2006 ;

Wikipdia lencyclopdie libre, http://fr.wikipedia.org/, 2008 ;

Schoen D., Module Gnie Logiciel Introduction, FIUPSO Universit Paris-Sud Orsay, 1997.

UML Cours

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

UML Cours

Transféré par

Droits d'auteur :

Formats disponibles

Analyse > Langage UML > Cours v0.8.1.

Vous aimerez peut-être aussi