Livre UML 2

Informatique
Synthse
de cours
exercices
corrigs
&
UML 2
Pratique de la modlisation
2e dition
Les principaux diagrammes dUML

Une quarantaine dapplications corriges
et une tude de cas complte
Un comparatif des logiciels de modlisation
collection
Synthex
Benot CHARROUX
Aomar OSMANI
Yann THIERRY-MIEG
UML2-Pr lims Page I Vendredi, 14. d cembre 2007 11:37 11
Informatique
Synthse
de cours
&
exercices
corrigs
UML 2
2e dition
Benot Charroux
EFREI (cole dingnieur)
Aomar Osmani
universit Paris XIII
Yann Thierry-Mieg
universit Paris VI
collection
Synthex
UML2 Livre Page II Vendredi, 14. d cembre 2007 7:24 07
ISBN : 978-2-7440-4050-4
ISSN : 1768-7616
Copyright 2009 Pearson Education France
Tous droits rservs
Composition sous FrameMaker : TyPAO
Aucune reprsentation ou reproduction, mme partielle, autre que celles prvues larticle L. 122-5 2 et 3 a)
du code de la proprit intellectuelle ne peut tre faite sans lautorisation expresse de Pearson Education France
ou, le cas chant, sans le respect des modalits prvues larticle L. 122-10 dudit code.
UML2 Livre Page III Vendredi, 14. d cembre 2007 7:24 07
Sommaire
Les auteurs
Introduction
VII
Chapitre 1 Diagramme de cas dutilisation
Chapitre 2 Diagramme de classes
35
Chapitre 3 Diagramme dinteraction
85
Chapitre 4 Diagramme dtats-transitions
127
Chapitre 5 Diagramme dactivits
155
Chapitre 6 UML en pratique
187
Annexe A Comparatif des outils de modlisation
233
Annexe B
237
Classeurs structurs
Annexe C Composants
238
Annexe D Diagramme de dploiement
240
Annexe E
Implmentation dun modle objet en Java
241
Annexe F
Organisation dUML 2
247
Annexe G Bibliographie
252
Index
253
Sommaire III
UML2 Livre Page IV Vendredi, 14. d cembre 2007 7:24 07
UML2 Livre Page V Vendredi, 14. d cembre 2007 7:24 07
Les auteurs
Benot Charroux est docteur en informatique. Aprs avoir men des travaux de recherche
en traitement dimages, il se consacre maintenant exclusivement la formation. Ayant
dirig le dpartement informatique de lESIGETEL, il gre prsent les enseignements
de linformatique lEFREI (cole dIngnieurs des Technologies de lInformation et du
Management). Il enseigne les technologies orientes objet (UML, Java, C++, EJB) dans de
nombreux tablissements : coles dingnieurs, universits, et entreprises.
Aomar Osmani est docteur en informatique et matre de confrences luniversit Paris
XIII. Il mne des travaux de recherche en diagnostic de systmes dynamiques, en raisonnement temporel et en apprentissage artificiel. Ces activits denseignement portent sur la
plupart des domaines de linformatique (architecture des ordinateurs, rseaux, systmes,
bases de donnes). Il a principalement enseign ces dernires annes les technologies orientes objet et le gnie logiciel, et a particip, linstitut universitaire de technologie de Paris
XIII, la cration et la direction de groupes de licence professionnelle.
Yann Thierry-Mieg est docteur en informatique et matre de confrences. Ses problmatiques de recherche sont centres sur la modlisation et la vrification formelle de systmes
informatiques, plus particulirement rpartis, en vue de fournir des outils pour vrifier de
manire automatique le comportement dun systme partir de son modle. Il enseigne
Paris VI ainsi qu lEFREI les systmes dinformation, les technologies orientes objet et
les mthodologies de dveloppement.
Les auteurs V
UML2 Livre Page VI Vendredi, 14. d cembre 2007 7:24 07
UML2 Livre Page VII Vendredi, 14. d cembre 2007 7:24 07
Introduction
Lapproche objet est incontournable dans le cadre du dveloppement de systmes logiciels
complexes, capables de suivre les volutions incessantes des technologies et des besoins
applicatifs. Cependant, la programmation objet est moins intuitive que la programmation
fonctionnelle. En effet, il est plus naturel de dcomposer les problmes informatiques en
termes de fonctions quen termes densembles dobjets en interaction. De ce fait, lapproche
objet requiert de modliser avant de concevoir. La modlisation apporte une grande rigueur, offre une meilleure comprhension des logiciels, et facilite la comparaison des solutions
de conception avant leur dveloppement. Cette dmarche se fonde sur des langages de modlisation, qui permettent de saffranchir des contraintes des langages dimplmentation.
Le besoin dune mthode de description et de dveloppement de systmes, prenant en compte
la fois les donnes et les traitements, a grandi en mme temps que la taille des applications
objet. Au milieu des annes 90, plusieurs dizaines de mthodes objet sont disponibles, mais
aucune ne prdomine. Lunification et la normalisation des trois mthodes dominantes,
savoir Booch, du nom de son auteur, OOSE (Object Oriented Software Engineering), dIvan
Jacobson et OMT (Object Modeling Technique), de James Rumbaugh, sont lorigine de la
cration du langage UML (Unified Modeling Language).
UML est une notation graphique conue pour reprsenter, spcifier, construire et documenter
les systmes logiciels. Ses deux principaux objectifs sont la modlisation de systmes utilisant les techniques orientes objet, depuis la conception jusqu la maintenance, et la cration dun langage abstrait comprhensible par lhomme et interprtable par les machines.
UML sadresse toutes les personnes charges de la production, du dploiement et du suivi
de logiciels (analystes, dveloppeurs, chefs de projets, architectes), mais peut galement
servir la communication avec les clients et les utilisateurs du logiciel. Il sadapte tous les
domaines dapplication et tous les supports. Il permet de construire plusieurs modles
dun systme, chacun mettant en valeur des aspects diffrents : fonctionnels, statiques, dynamiques et organisationnels. UML est devenu un langage incontournable dans les projets de
dveloppement.
Une mthode de dveloppement dfinit la fois un langage de modlisation et la marche
suivre lors de la conception. Le langage UML propose uniquement une notation dont
linterprtation est dfinie par un standard, mais pas une mthodologie complte. Plusieurs
processus de dveloppement complets fonds sur UML existent, comme le Rational Unified
Process (RUP), de Booch, Jacobson et Rumbaugh, ou lapproche MDA (Model Driven
Architecture) propose par lOMG, mais ils ne font pas partie du standard UML.
Introduction VII
UML2 Livre Page VIII Vendredi, 14. d cembre 2007 7:24 07
Le processus RUP propose de bien matriser les tapes successives de la modlisation et du

dveloppement par une approche itrative. Lapproche MDA propose une architecture
du dveloppement en deux couches : le PIM (Platform Indepent Model) reprsente une
vision abstraite du systme, indpendante de limplmentation ; le PSM (Platform Specific
Model) reprsente les programmes excutables, qui doivent tre obtenus en partie automatiquement partir du PIM ; cela sajoute le PDM (Platform Definition Model), en loccurrence
une description de larchitecture physique voulue (langages de programmation, architecture
matrielle).
UML intgre de nombreux concepts permettant la gnration de programmes. Cest un
langage de modlisation fond sur des vnements ou des messages. Il ne convient pas pour
la modlisation de processus continus, comme la plupart des procds en physique. Ce nest
pas un langage formel, ni un langage de programmation. Il ne peut pas tre utilis pour valider
un systme, ni pour gnrer un programme excutable complet. Mais, il permet de produire
des parties de code, comme le squelette des classes (attributs et signatures de mthode).
Mme si la version 2 apporte des avances significatives au niveau du formalisme, UML na
pas encore atteint la rigueur syntaxique et smantique des langages de programmation.
UML est le rsultat dun large consensus, continuellement enrichi par les avances en
matire de modlisation de systmes et de dveloppement de logiciels. Cest le rsultat dun
travail dexperts reconnus, issus du terrain. Il couvre toutes les phases du cycle de vie de
dveloppement dun systme et se veut indpendant des langages dimplmentation et des
domaines dapplication.
Historique du langage UML

la fin des annes 80, lindustrie commence utiliser massivement les langages de programmation orients objet, tels que C++, Objective C, Eiffel et Smalltalk. De lindustrialisation
de ce type de programmation est n le besoin de penser objet , indpendamment du
langage dimplmentation. Plusieurs quipes proposent alors des mthodes (OMT, OOSE,
Booch, Coad, Odell, CASE) qui, pour la plupart, modlisent les mmes concepts fondamentaux dans diffrents langages, avec une terminologie, des notations et des dfinitions
diffrentes. Les diffrents protagonistes conviennent rapidement du besoin dunifier ces
langages en un standard unique.
Lors de la confrence OOPSLA doctobre 1995, Booch et Rumbaugh prsentent la version
0.8 de leur mthode unifie (Unified Method 0.8). Ils sont rejoints la mme anne par
Jacobson. Les trois auteurs amliorent la mthode unifie et proposent en 1996 la version
0.9 du langage UML. Rational Software, qui emploie dsormais le trio, publie en 1997 la
documentation de la version 1.0 dUML et la propose lOMG en vue dune standardisation. Des modifications sont apportes la version propose par Rational, puis lOMG
propose, la mme anne, la version UML 1.1, qui devient un standard.
LOMG constitue ensuite un groupe de rvision nomm RTF (Revision Task Force). Entretemps, de trs nombreux utilisateurs industriels adoptent UML et apportent quelques
modifications, ce qui conduit la proposition de la version 1.2 en 1999. La premire rvision
significative du langage est la version 1.3, propose en 1999, dont la spcification complte
est publie en mars 2000. En mars 2003, la version 1.5 voit le jour.
Concrtement, UML 1 est utilis lors de la phase danalyse et de conception prliminaire des
systmes. Il sert spcifier les fonctionnalits attendues du systme (diagrammes de cas
dutilisation et de squence) et dcrire larchitecture (diagramme de classes). La description de la partie comportementale (diagrammes dactivits et dtats) est moins utilise.
Cela est d essentiellement linsuffisance de la formalisation de la conception dtaille
dans UML 1. La plupart du temps, en matire de spcification des algorithmes et des
mthodes de traitement, le seul moyen est de donner une description textuelle informelle.
VIII
UML 2
UML2 Livre Page IX Vendredi, 14. d cembre 2007 7:24 07
Certes, des outils comme les automates et les diagrammes dactivits sont disponibles, mais
leur emploi est limit. Les utilisateurs restent sur le vieux paradigme centr sur le code : ils
se contentent de recourir UML lors des phases prliminaires et passent un langage de
programmation classique lors des phases de codage et de tests. Lun des objectifs de lOMG
est de proposer un paradigme guid par des modles dcrivant la fois le codage, la gestion
de la qualit, les tests et vrifications, et la production de la documentation. Il sagit de
recentrer lactivit des informaticiens sur les fonctions que le systme doit fournir, en
conformit avec les exigences du client et les standards en vigueur.
Objectif du livre
Lobjectif de cet ouvrage est de fournir une rfrence concise des concepts de base dUML,
illustre par de nombreux exemples. Nous adoptons le point de vue pragmatique des utilisateurs du langage. Il permet de comprendre limportance de la modlisation et lintrt
demployer une notation graphique.
Selon le principe de cette collection, chaque chapitre commence par une synthse de cours
prsentant les concepts de base du langage, avec leur syntaxe prcise, et illustre de nombreux exemples, remarques pratiques et commentaires. Vient ensuite une srie dexercices.
Ce livre donne la vue utilisateur des concepts de la notation UML : ils sont dcrits avec prcision dans la norme par un mtamodle, mais cet aspect un peu complexe nest pas dtaill
dans cet ouvrage.
Le langage UML ne sappuie pas sur un processus dcrivant les tapes du dveloppement.
Cependant, il est bien adapt aux processus itratifs guids par les besoins des utilisateurs et
axs sur larchitecture. Les exemples et les exercices corrigs, prsents au fil des chapitres,
donnent des indications sur les approches suivre pour laborer un modle dune situation
donne. Le problme difficile et rcurrent de lenchanement des modles est trait dans
une tude de cas prsente au chapitre 6.
Structure du livre
Le livre est compos de chapitres qui peuvent tre lus sparment. Cependant, le plan respecte toujours la mme dmarche dont la premire tape correspond une prsentation du
point de vue fonctionnel. Lanalyse fonctionnelle permet de mettre au point une reprsentation graphique, compacte et complte des besoins, appele diagramme de cas dutilisation . Les cas sont ventuellement dcrits textuellement afin de spcifier les diffrents
scnarios attendus du systme. Vient ensuite la partie analyse statique , dans laquelle on
spcifie les classes et les relations entre classes (diagramme de classes). Des cas particuliers
ou explicatifs sont aussi prsents par des diagrammes dobjets. Une fois que les diffrents
objets sont dfinis (diagramme de classes), on revient sur lanalyse fonctionnelle dans
laquelle on spcifie les interactions entre les diffrents objets du systme. On peut tre intress par les changes dans le temps (diagramme de squence) ou encore par les collaborations existantes entre les objets (diagramme de communication). La description de la
partie dynamique du systme est prsente par les diagrammes dtats et les diagrammes
dactivits.
Chaque chapitre est divis en deux parties : le rappel de cours puis les exercices corrigs, qui
occupent une part importante de louvrage. Ils illustrent via des exemples simples les
concepts prsents dans le rappel de cours et expliquent comment utiliser UML dans des
situations pratiques. Ils donnent quelques indications sur la manire de modliser (ce qui
ne fait pas partie de la description du langage). travers une application concrte, le chapitre 6 introduit le diagramme de composants, qui permet une organisation statique du systme, et prsente une mthodologie complte intgrant la plupart des concepts prsents
dans les chapitres prcdents.
Introduction IX
UML2 Livre Page X Vendredi, 14. d cembre 2007 7:24 07
Prrequis
Si cet ouvrage peut tre abord par toute personne ayant une certaine culture informatique,
certains passages ncessitent la connaissance des notions minimales de programmation
objet. De nombreux concepts dUML (classes, hritage, encapsulation) sont directement
proposs par les langages de programmation orients objet, comme le C++ ou Java. Certains
exemples sont donc compars ces langages, et supposent donc une exprience minimale
de la programmation oriente objet. Les ouvrages sur le C++ et Java 5, publis dans la
mme collection, sont de bonnes rfrences en la matire.
Pourquoi modliser ?
Un modle est une reprsentation simplifie dune ralit. Il permet de capturer des aspects
pertinents pour rpondre un objectif dfini a priori. Par exemple, un astronaute modlisera la Lune comme un corps cleste ayant une certaine masse et se trouvant une certaine
distance de la Terre, alors quun pote la modlisera comme une dame avec laquelle il peut
avoir une conversation.
Le modle sexprime sous une forme simple et pratique pour le travail [Rumbaugh2004].
Quand le modle devient compliqu, il est souhaitable de le dcomposer en plusieurs
modles simples et manipulables.
Lexpression dun modle se fait dans un langage compatible avec le systme modlis et les
objectifs attendus. Ainsi, le physicien qui modlise la lune utilisera les mathmatiques
comme langage de modlisation. Dans le cas du logiciel, lun des langages utiliss pour la
modlisation est le langage UML. Il possde une smantique propre et une syntaxe compose de graphique et de texte et peut prendre plusieurs formes (diagrammes).
Les modles ont diffrents usages :
Ils servent circonscrire des systmes complexes pour les dominer. Par exemple, il est inimaginable de construire une fuse sans passer par une modlisation permettant de tester
les racteurs, les procdures de scurit, ltanchit de lensemble, etc.
Ils optimisent lorganisation des systmes. La modlisation da la structure dune entreprise en divisions, dpartements, services, etc. permet davoir une vision simplifie du
systme et par l mme den assurer une meilleure gestion
Ils permettent de se focaliser sur des aspects spcifiques dun systme sans sembarrasser
des donnes non pertinentes. Si lon sintresse la structure dun systme afin de factoriser ses composants, il est inutile de sencombrer de ses aspects dynamiques. En utilisant,
par exemple, le langage UML, on sintressera la description statique (via le diagramme
de classes) sans se soucier des autres vues.
Ils permettent de dcrire avec prcision et compltude les besoins sans forcment connatre
les dtails du systme.
Ils facilitent la conception dun systme, avec notamment la ralisation de maquette
approximative, chelle rduite, etc.
Ils permettent de tester une multitude de solutions moindre cot et dans des dlais
rduits et de slectionner celle qui rsout les problmes poss.
La modlisation objet produit des modles discrets permettant de regrouper un ensemble
de configurations possibles du systme et pouvant tre implments dans un langage de
programmation objet. La modlisation objet prsente de nombreux avantages travers
un ensemble de proprits (classe, encapsulation, hritage et abstraction, paquetage,
modularit, extensibilit, adaptabilit, rutilisation) qui lui confre toute sa puissance et
son intrt.
UML 2
UML2 Livre Page XI Vendredi, 14. d cembre 2007 7:24 07
UML 2
UML 2 apporte des volutions majeures par rapport UML 1.5, sans toutefois tre rvolutionnaire : les principales fonctionnalits de base se ressemblent. Au niveau du mtamodle,
qui concerne surtout les dveloppements doutils, UML 2 se rapproche davantage des standards de modlisation objet proposs par lOMG. En particulier, lunification du noyau
UML et des parties conceptuelles de modlisation MOF (Meta-Object Facility) permet aux
outils MOF de grer les modles UML ; lajout du principe de profils permet de mieux dfinir les extensions du domaine ; enfin, la rorganisation du mtamodle UML limine les
redondances prsentes dans les versions prcdentes (voir la fin de louvrage pour plus de
dtails concernant la structuration du langage UML).
Du point de vue de lutilisateur, les changements concernent certaines notations. La notation des diagrammes de squence se rapproche de la norme dchanges de messages MSC
(Message Sequence Chart) de lIUT (Union Internationale des Tlcommunications). Le concept
de classeurs sinspire des avances de lingnierie temps rel du langage de description et de
spcification SDL. De plus, UML 2 unifie la modlisation des activits et la modlisation des
actions introduites dans UML 1.5 et utilise des notations de modlisation de processus
mtier. Des lments de modlisation contextuels amliorent la souplesse et formalisent
mieux le concept dencapsulation des classes et des collaborations.
Afin de formaliser le modle utilisateur du langage et de le rapprocher davantage des normes
OMG, le langage UML est structur en quatre couches (figure 0.1) ; seules les deux couches
user model et run time instance sont destines lutilisateur.
Figure 0.1
Organisation
en quatre couches
du langage UML.
Lutilisateur na pas besoin de mettre en vidence cette organisation quand il utilise UML. Il
doit se contenter de respecter la syntaxe et la smantique du langage dtailles dans ce livre.
Il doit galement connatre les diffrents diagrammes mettant en valeur tantt des aspects
statiques, tantt des aspects comportementaux du systme. Une organisation conceptuelle
des diffrents diagrammes UML permet davoir une vision plus claire des vues offertes par
ce langage. Les trois auteurs lorigine du langage UML proposent un dcoupage conceptuel en quatre domaines : structurel, dynamique, physique et gestion de modles (voir la fin
de louvrage pour plus de dtails).
Introduction XI
UML2 Livre Page XII Vendredi, 14. d cembre 2007 7:24 07
UML2 Livre Page 1 Vendredi, 14. d cembre 2007 7:24 07
Chapitre
Diagramme de cas
dutilisation
1. Limportance de bien recueillir
les besoins ................................ 2
2. Le diagramme de cas dutilisation 2
3. Modlisation des besoins
avec UML ................................ 9
Problmes et exercices
1. Identification des acteurs et
recensement de cas dutilisation
simples ....................................
2. Relations entre cas dutilisation....
3. Relations entre cas dutilisation
cas internes ...........................
4. Identification des acteurs,
recensement des cas dutilisation
et relations simples entre cas......
5. Description dun cas dutilisation
6. Relations dextension entre cas
dutilisation, regroupement de
cas dutilisation en paquetages ..
7. Relations entre acteurs,
extensions conditionnelles
entre cas dutilisation ................
8. Identification des acteurs, recensement des cas dutilisation
internes et relation de gnralisation entre cas.......................
UML permet de construire plusieurs modles dun systme :

certains montrent le systme du point de vue des utilisateurs,
dautres montrent sa structure interne, dautres encore en
donnent une vision globale ou dtaille. Les modles se
compltent et peuvent tre assembls. Ils sont labors tout
au long du cycle de vie du dveloppement dun systme
16
18
(depuis le recueil des besoins jusqu la phase de
18
des modles, en loccurrence le premier construire :
conception). Dans ce chapitre, nous allons tudier un

le diagramme de cas dutilisation. Il permet de recueillir,
20
22
danalyser et dorganiser les besoins. Avec lui dbute

ltape danalyse dun systme.
25
27
29
(1)
Limportance de bien recueillir les besoins

Le dveloppement dun nouveau systme, ou lamlioration dun systme existant, doit
rpondre un ou plusieurs besoins. Par exemple, une banque a besoin dun guichet automatique pour que ses clients puissent retirer de largent mme en dehors des heures
douverture de la banque. Celui qui commande le logiciel est le matre douvrage. Celui qui
ralise le logiciel est le matre duvre.
Le matre douvrage intervient constamment au cours du projet, notamment pour :
dfinir et exprimer les besoins ;
valider les solutions proposes par le matre duvre ;
valider le produit livr.
Le matre duvre est, par exemple, une socit de services en informatique (SSII). Il a t
choisi, avant tout, pour ses comptences techniques. Mais son savoir-faire va bien au-del.
Au dbut du projet, il est capable de recueillir les besoins auprs du matre douvrage. Le
recueil des besoins implique une bonne comprhension des mtiers concerns. Raliser un
logiciel pour une banque, par exemple, implique la connaissance du domaine bancaire et
lintgration de toutes les contraintes et exigences de ce mtier. Cette condition est ncessaire pour bien cerner les cas dutilisation exprims par le client afin dapporter les solutions
adquates.
Chaque cas a ses particularits lies au mtier du client. Le recueil des besoins peut soprer
de diffrentes faons. Cela dit, il est recommand de complter le cahier des charges par des
discussions approfondies avec le matre douvrage et les futurs utilisateurs du systme. Il
convient galement dutiliser tous les documents produits propos du sujet (rapports techniques, tude de march) et dtudier les procdures administratives des fonctions de
lentreprise qui seront prises en charge par le systme. La question que doit se poser le
matre duvre durant le recueil des besoins est la suivante : ai-je toutes les connaissances
et les informations pour dfinir ce que doit faire le systme ?
(2)
Le diagramme de cas dutilisation
2.1 LES
CAS DUTILISATION
Parlons prsent dUML et voyons quelle aide il peut apporter lors du recueil des besoins.
UML nest quun langage et il ne sert ici qu formaliser les besoins, cest--dire les
reprsenter sous une forme graphique suffisamment simple pour tre comprhensible par
toutes les personnes impliques dans le projet. Noublions pas que bien souvent, le matre
douvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas dutilisation.
Ils permettent de recenser les grandes fonctionnalits dun systme.
EXEMPLE
UML 2
La figure 1.1 modlise une borne interactive qui permet daccder une banque. Le systme
modliser apparat dans un cadre (cela permet de sparer le systme modliser du
monde extrieur). Les utilisateurs sont reprsents par des petits bonshommes, et les grandes
fonctionnalits (les cas dutilisation) par des ellipses.
Chapitre
Figure 1.1
Borne interactive dune banque
frontire du sujet
Diagramme
de cas dutilisation
modlisant une
borne daccs
une banque.
nom du sujet
cas dutilisation
Retirer argent
acteur
Effectuer un virement
Consulter comptes
Client
association
Lensemble des cas dutilisation contenus dans le cadre constitue un sujet . Les petits
bonshommes sont appels acteurs . Ils sont connects par de simples traits (appels
associations ) aux cas dutilisation et mettent en vidence les interactions possibles entre
le systme et le monde extrieur. Chaque cas modlise une faon particulire et cohrente
dutiliser un systme pour un acteur donn.
Dfinition
Un cas dutilisation est une manire spcifique dutiliser un systme. Les acteurs sont
lextrieur du systme ; ils modlisent tout ce qui interagit avec lui. Un cas dutilisation
ralise un service de bout en bout, avec un dclenchement, un droulement et une fin, pour
lacteur qui linitie.
Notation et spcification
Un cas dutilisation se reprsente par une ellipse (figure 1.2). Le nom du cas est inclus dans
lellipse ou bien il figure dessous. Un strotype (voir la dfinition ci-aprs), peut tre ajout
optionnellement au-dessus du nom, et une liste de proprits place au-dessous.
Un cas dutilisation se reprsente aussi sous la forme dun rectangle deux compartiments :
celui du haut contient le nom du cas ainsi quune ellipse (symbole dun cas dutilisation) ;
celui du bas est optionnel et peut contenir une liste de proprits (figure 1.3).
Un acteur se reprsente par un petit bonhomme ayant son nom inscrit dessous (figure 1.1) ou
par un rectangle contenant le strotype acteur avec son nom juste en dessous (figure 1.4).
Il est recommand dajouter un commentaire sur lacteur pour prciser son rle.
Figures 1.2 et 1.3

Reprsentations
dun cas
dutilisation.
Figure 1.4
Autre reprsentation
dun acteur.
strotype
Nom du cas
Liste de proprits
Nom du cas
Liste de proprits
Rle de lacteur
acteur
Nom de lacteur
Diagramme de cas dutilisation 3
La figure 1.4 reprsente un acteur par un rectangle. UML utilise aussi les rectangles pour
reprsenter des classes, et plus gnralement des classeurs. Pour autant, la notation nest pas
ambigu puisque le strotype acteur indique que le rectangle dsigne un acteur. Les strotypes permettent dadapter le langage des situations particulires.
Dfinition
Un strotype reprsente une variation dun lment de modle existant.
un niveau dabstraction plus lev, UML permet de reprsenter tous les cas dutilisation
dun systme par un simple rectangle. La figure 1.5 montre comment un tel rectangle peut
remplacer tous les cas dutilisation de la figure 1.1.
Figure 1.5
Reprsentation des cas
dutilisation un niveau
dabstraction lev.
Le rectangle de la figure 1.5 est appel classeur .
Dfinition
Un classeur est un lment de modlisation qui dcrit une unit comportementale ou structurelle. Les acteurs et les cas dutilisation sont des classeurs. Tout au long de ce livre, on
retrouvera le terme classeur car cette notion englobe aussi les classes, des par ties dun
systme, etc.
Notation
Un classeur se reprsente par un rectangle contenant ventuellement des compar timents (la
figure 1.6 montre comment il est possible de faire figurer explicitement des cas dutilisation
dans un classeur).
Figure 1.6
Les compartiments
dun classeur.
Retirer argent
Consulter comptes
UML 2
Chapitre
2.2 RELATIONS
ENTRE ACTEURS ET CAS DUTILISATION
Un acteur peut utiliser plusieurs fois le mme cas dutilisation.

EXEMPLE
La figure 1.7 montre un internaute qui tlcharge plusieurs morceaux de musique sur Internet.
Figure 1.7
Logiciel de tlchargement
Association avec
multiplicit.
*
Tlcharger une musique
Internaute
Le symbole * qui signifie plusieurs est ajout lextrmit du cas et sappelle une multiplicit. Plusieurs valeurs sont possibles pour la multiplicit : exactement n scrit tout simplement n, m..n signifie entre m et n, etc. Prciser une multiplicit sur une relation
nimplique pas ncessairement que les cas sont utiliss en mme temps.
2.3 RELATIONS
ENTRE CAS DUTILISATION
Pour clarifier un diagramme, UML permet dtablir des relations entre les cas dutilisation.
Il existe principalement deux types de relations : les dpendances strotypes et la gnralisation/spcialisation. Les dpendances strotypes sont des dpendances dont la porte
est explicite par le nom du strotype. Les strotypes les plus utiliss sont linclusion et
lextension.
La relation dinclusion. Un cas A est inclus dans un cas B si le comportement dcrit par le
cas A est inclus dans le comportement du cas B : on dit alors que le cas B dpend de A.
Cette dpendance est symbolise par le strotype inclut. Par exemple, laccs aux informations dun compte bancaire inclut ncessairement une phase dauthentification avec
un mot de passe (figure 1.8).
La relation dextension. Si le comportement de B peut tre tendu par le comportement
de A, on dit alors que A tend B. Une extension est souvent soumise condition. Graphiquement, la condition est exprime sous la forme dune note. La figure 1.8 prsente
lexemple dune banque o la vrification du solde du compte nintervient que si la
demande de retrait dargent dpasse 20 euros.
La relation de gnralisation. Un cas A est une gnralisation dun cas B si B est un cas
particulier de A. la figure 1.8, la consultation dun compte bancaire via Internet est un
cas particulier de la consultation. Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par le concept dhritage dans les
langages orients objet.
Les inclusions permettent aussi de dcomposer un cas complexe en sous-cas plus simples.
EXEMPLE
la figure 1.9, le modlisateur a jug que la vente dun article par correspondance est un
problme complexe et quil est important de faire apparatre dans le modle une dcomposition en sous-cas.
Une dpendance se reprsente par une flche pointille. Un strotype est souvent ajout
au-dessus du trait.
Le strotype inclut indique que la relation de dpendance est une inclusion (figures 1.8
et 1.9).
Le strotype tend indique une extension (figure 1.8). Lextension peut intervenir un point
prcis du cas tendu ; ce point sappelle le point dextension ; il porte un nom, qui figure
dans un compartiment du cas tendu sous la rubrique point dextension , et est ventuellement associ une contrainte indiquant le moment o lextension inter vient. Une extension
est souvent soumise une condition (indique dans une note attache la flche pointille).
Le symbole utilis pour la gnralisation est une flche en traits pleins dont la pointe est un
triangle ferm. La flche pointe vers le cas le plus gnral (figure 1.8).
Figure 1.8
Relations entre cas

dans un diagramme
de cas dutilisation.
Retirer argent
Point dextension :
vrificationSolde {aprs
avoir demand le
montant}
inclut
inclut
tend
Sauthentifier
Client
Vrifier le solde
Condition : {si montant > 20 euros}
Point dextension : vrificationSolde
inclut
Consulter comptes
Consulter sur Internet
Figure 1.9
Systme de vente par correspondance
Relations entre cas

pour dcomposer
un cas complexe.
Vrifier la disponibilit
de larticle
inclut
Passer une commande
inclut
Prpos aux
commandes
Vrifier la solvabilit du client
Un cas reli un autre cas peut ne pas tre directement accessible un acteur (figure 1.9).
Un tel cas est appel cas interne .
UML 2
Chapitre
Dfinition
Un cas dutilisation est dit interne sil nest pas reli directement un acteur.
Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et denrichir les
cas dutilisation. Par exemple, la figure 1.8, rien nempche de regrouper les cas Consulter
comptes et Consulter sur Internet en un seul cas. Cependant, indiquer ds la phase de
recueil des besoins quil y a des cas particuliers apporte une information supplmentaire
pertinente. La question se poser est : faut-il la faire figurer dans le diagramme de cas dutilisation ou la prendre en compte plus tard ? La rponse cette question ne sera pas toujours
la mme selon le contexte du projet.
Remarque
Attention lorientation des flches : si le cas A inclut B on trace la flche de A vers B, mais
si B tend A, la flche est dirige de B vers A.
2.4 RELATIONS
ENTRE ACTEURS
La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une
gnralisation dun acteur B si lacteur A peut tre substitu par lacteur B (tous les cas dutilisation accessibles A le sont aussi B, mais linverse nest pas vrai).
EXEMPLE
La figure 1.10 montre que le directeur des ventes est un prpos aux commandes avec un
pouvoir supplmentaire (en plus de pouvoir passer et suivre une commande, il peut grer le
stock). Le prpos aux commandes ne peut pas grer le stock.
Figure 1.10
Systme de vente par correspondance
Relations
entre acteurs.
Passer une commande
Suivre une commande

Prpos aux
commandes
inclut
Rechercher article
inclut
inclut
Grer le stock
Directeur
des ventes
Notation
Le symbole utilis pour la gnralisation entre acteurs est une flche en traits pleins dont la
pointe est un triangle ferm. La flche pointe vers lacteur le plus gnral.
2.5 REGROUPEMENT
DES CAS DUTILISATION EN PAQUETAGES
UML permet de regrouper des cas dutilisation dans une entit appele paquetage . Le
regroupement peut se faire par acteur ou par domaine fonctionnel. Un diagramme de cas
dutilisation peut contenir plusieurs paquetages et des paquetages peuvent tre inclus dans
dautres paquetages.
Dfinition
Un paquetage permet dorganiser des lments de modlisation en groupe. Un paquetage
peut contenir des classes, des cas dutilisations, des interfaces, etc.
EXEMPLE
la figure 1.11, trois paquetages ont t crs : Client, Stock et Suppor t. Ces paquetages
contiennent les cas dutilisation du diagramme de la figure 1.10 (Client contient les cas
Passer une commande et Suivre une commande , Stock contient le cas Grer le
stock , tandis que le cas Rechercher article est inclus dans le paquetage Support.
Figure 1.11
Regroupement
des cas dutilisation
en paquetage.
Client
Dpendance
entre paquetages
qui reflte
linclusion des
cas dutilisation.
Support
Stock
En tant que langage, UML est soumis des rgles de nommage quil faut strictement respecter : pour accder au contenu de paquetages imbriqus les uns dans les autres, il faut utiliser
des deux-points comme sparateur des noms de paquetage. Par exemple, si un paquetage B
inclus dans un paquetage A contient une classe X, il faut crire A::B::X pour pouvoir utiliser
la classe X en dehors du contexte des paquetages.
UML 2
Chapitre
(3)
Modlisation des besoins avec UML
3.1 QUI
SONT LES ACTEURS
? COMMENT
LES IDENTIFIER
Les principaux acteurs sont les utilisateurs du systme. Ils sont en gnral faciles reprer.
Cest le matre douvrage qui les dsigne. Chaque acteur doit tre nomm, mais attention,
pour trouver son nom, il faut penser son rle : un acteur reprsente un ensemble cohrent
de rles jous vis--vis dun systme. Ainsi, pour un logiciel de gestion de paie, le nom
correct dun acteur est Comptable plutt que Mme Dupont. Plusieurs personnes peuvent
avoir le mme rle. Cest le cas des clients dune banque par exemple. Il ny aura alors quun
seul acteur. Rciproquement, une mme personne physique peut jouer des rles diffrents
vis--vis du systme et donc correspondre plusieurs acteurs.
En gnral, les utilisateurs ne sont pas difficiles trouver, mais il faut veiller ne pas oublier
les personnes responsables de lexploitation et de la maintenance du systme. Par exemple,
un logiciel de surveillance qui limite les accs un btiment doit avoir un administrateur
charg de crer des groupes de personnes et leur donner des droits daccs. Il ne sagit pas ici
des personnes qui installent et paramtrent le logiciel avant sa mise en production, mais des
utilisateurs du logiciel dans son fonctionnement nominal.
En plus des utilisateurs, les acteurs peuvent tre :
des priphriques manipuls par le systme (imprimantes, robots) ;
des logiciels dj disponibles intgrer dans le projet ;
des systmes informatiques externes au systme mais qui interagissent avec lui, etc.
Pour faciliter la recherche des acteurs, on peut imaginer les frontires du systme. Tout ce
qui est lextrieur et qui interagit avec le systme est un acteur ; tout ce qui est lintrieur
est une fonctionnalit du systme que le matre duvre doit raliser.
Un cas dutilisation a toujours au moins un acteur principal pour qui le systme produit un
rsultat observable, et ventuellement dautres acteurs ayant un rle secondaire. Par exemple, lacteur principal dun cas de retrait dargent dans un distributeur automatique de
billets est la personne qui fait le retrait, tandis que la banque qui vrifie le solde du compte
est un acteur secondaire. En gnral, lacteur principal initie le cas dutilisation par ses sollicitations.
Dfinition
Lacteur est dit principal pour un cas dutilisation lorsque le cas dutilisation rend ser vice
cet acteur. Les autres acteurs sont dits secondaires . Un cas dutilisation a au plus un
acteur principal, et un ensemble ventuellement vide dacteurs secondaires.
Un acteur principal obtient un rsultat observable du systme tandis quun acteur secondaire est sollicit pour des informations complmentaires.
3.2 COMMENT
RECENSER LES CAS DUTILISATION
Il ny a pas une faon unique de reprer les cas dutilisation. Il faut se placer du point de vue
de chaque acteur et dterminez comment il se sert du systme, dans quels cas il lutilise, et
quelles fonctionnalits il doit avoir accs. Il faut viter les redondances et limiter le nombre de
cas en se situant au bon niveau dabstraction (par exemple, ne pas rduire un cas une action).
EXEMPLE
Considrons un systme de rservation et dimpression de billets de train via des bornes interactives situes dans des gares. En prenant pour acteur une personne qui souhaite obtenir un
billet, on peut obtenir la liste suivante des cas dutilisation :
rechercher un voyage ;
rserver une place dans un train ;
acheter son billet.
Lensemble des cas dutilisation doit couvrir exhaustivement tous les besoins fonctionnels
du systme. Ltape de recueil des besoins est souvent longue et fastidieuse car les utilisateurs
connaissent lexistant et nont quune vague ide de ce que leur apportera un futur systme ;
en outre, le cahier des charges contient des imprcisions, des oublis, voire des informations
contradictoires difficiles extraire. Llaboration du diagramme de cas dutilisation permet
de pallier ces problmes en recentrant le systme sur les besoins fonctionnels et ce, ds le
dbut du projet.
On peut se demander pourquoi adopter un point de vue fonctionnel, et non technique ?
Trop souvent, par le pass, les logiciels taient techniquement trs labors sans pour autant
satisfaire les utilisateurs. Avec les diagrammes de cas dutilisation, on se place clairement du
ct des utilisateurs. Le ct technique nest pas oubli mais abord diffremment : les
besoins sont affins lors de lcriture des spcifications on parle de spcifications techniques des besoins (voir la section Description textuelle des cas dutilisation ).
Remarque
Il ne faut pas faire apparatre les dtails des cas dutilisation, mais il faut rester au niveau
des grandes fonctions du systme. La question qui se pose alors est de savoir jusqu quel
niveau de dtails descendre ? Si le nombre de cas est trop impor tant, il faut se demander
si on a fait preuve de suffisamment dabstraction. Le nombre de cas dutilisation est un bon
indicateur de la faisabilit dun logiciel.
Il ne doit pas y avoir de notion temporelle dans un diagramme de cas dutilisation. Il ne faut
pas se dire que lacteur fait ceci, puis le systme lui rpond cela, ce qui implique une raction de lacteur, et ainsi de suite. Le squencement temporel sera pris en compte plus tard,
notamment dans la description dtaille des cas (voir section 3.3).
Lintrt des cas dutilisation ne se limite pas au recueil des besoins. La description des cas
dutilisation peut servir de base de travail pour tablir les tests de vrification du bon fonctionnement du systme, et orienter les travaux de rdaction de la documentation lusage
des utilisateurs.
3.3 DESCRIPTION
DES CAS DUTILISATION
Le diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de vue
des acteurs, mais nexpose pas de faon dtaille le dialogue entre les acteurs et les cas dutilisation.
EXEMPLE
10
UML 2
Lexemple de la figure 1.12 ne permet pas de savoir ce qui entre et ce qui sort du logiciel
bancaire : le retrait dargent se fait-il en euros ou en dollars ? Dans quel ordre les oprations
sont-elles effectues ? Faut-il choisir le montant du retrait avant de choisir le compte dbiter,
ou bien linverse ? Tous ces dtails sont des lments de spcification. Spcifier un produit,
cest le dcrire de la faon la plus prcise possible.
Chapitre
Figure 1.12
Gestion dune banque
Diagramme de cas
dutilisation pour
une banque.
Retirer argent
Guichetier
Consulter compte
Systme
central
Les spcifications peuvent tre divises en deux catgories selon quelles sont fonctionnelles
ou techniques. Les spcifications fonctionnelles concernent les fonctions du systme, la
fonction de retrait dargent par exemple, tandis que les spcifications techniques permettent
de prciser le contexte dexcution du systme. Par exemple, le logiciel qui gre la distribution des billets doit tre compatible avec tel ou tel systme dexploitation, ou encore, un
retrait dargent doit se faire en moins de 5 secondes.
Les spcifications fonctionnelles dcoulent directement du diagramme de cas dutilisation.
Il sagit de reprendre chaque cas et de le dcrire trs prcisment. En dautres termes, vous
devez dcrire comment les acteurs interagissent avec le systme.
EXEMPLE
Figure 1.13
Description dun cas
dutilisation par
une squence
de messages.
partir du diagramme de cas dutilisation de lexemple prcdent, la figure 1.13 montre une
faon de dcrire les interactions entre le guichetier et le systme. On y voit clairement apparatre une squence de messages.
Le graphisme utilis fait partie du formalisme des diagrammes de squence (voir chapitre 3).
sd Retirer argent
: Systme
Guichetier
Systme
central
Saisie du numro de compte client

Demande de validit du compte
Compte valide
Demande type dopration
Retrait despces de 200 euros
Demande de dbit du compte
Compte dbit
Autorisation de dlivrer les 200 euros
Les diffrentes faons de dcrire les cas dutilisation

UML nimpose rien quant la faon de dcrire un cas dutilisation. Au lieu dutiliser une
squence de messages, il est possible dutiliser les diagrammes dactivits dUML (voir chapitre 5). Cette libert de choix peut tre droutante, mais comme UML est cens pouvoir
modliser tout type de systme, une manire unique de dcrire un cas ne suffirait pas.
Remarque
Une des forces de la notation UML est de proposer de nombreux types de diagrammes qui
mettent en avant des aspects diffrents dune description. Ainsi, le modlisateur peut utiliser
le type de diagramme qui lui parat le plus adapt pour reprsenter son problme (et sa
solution), tout en restant dans la norme.
Description textuelle des cas dutilisation

Bien que de nombreux diagrammes dUML permettent de dcrire un cas, il est recommand
de rdiger une description textuelle car cest une forme souple qui convient dans bien des
situations. Une description textuelle couramment utilise se compose de trois parties, comme
le montre lexemple suivant. La premire partie permet didentifier le cas. Elle doit contenir :
le nom du cas ;
un rsum de son objectif ;
les acteurs impliqus (principaux et secondaires) ;
les dates de cration et de mise jour de la description courante ;
le nom des responsables ;
un numro de version.
La deuxime partie contient la description du fonctionnement du cas sous la forme dune
squence de messages changs entre les acteurs et le systme. Elle contient toujours une
squence nominale qui correspond au fonctionnement nominal du cas (par exemple, un
retrait dargent qui se termine par lobtention des billets demands par lutilisateur). Cette
squence nominale commence par prciser lvnement qui dclenche le cas (lutilisateur
introduit sa carte bancaire par exemple) et se dveloppe en trois points :
Les pr-conditions. Elles indiquent dans quel tat est le systme avant que se droule la
squence (le distributeur est aliment en billets par exemple).
Lenchanement des messages.
Les post-conditions. Elles indiquent dans quel tat se trouve le systme aprs le drouement
de la squence nominale (une transaction a t enregistre par la banque par exemple).
Parfois la squence correspondant un cas a besoin dtre appele dans une autre squence (par
exemple quand une relation dinclusion existe entre deux cas dutilisation). Signifier lappel
dune autre squence se fait de la faon suivante : appel du cas X , o X est le nom du cas.
Les acteurs ntant pas sous le contrle du systme, ils peuvent avoir des comportements
imprvisibles. La squence nominale ne suffit donc pas pour dcrire tous les comportements possibles. la squence nominale sajoutent frquemment des squences alternatives
et des squences dexceptions. Ces deux types de squences se dcrivent de la mme faon
que la squence nominale mais il ne faut pas les confondre. Une squence alternative
diverge de la squence nominale (cest un embranchement dans une squence nominale)
mais y revient toujours, alors quune squence dexception intervient quand une erreur se
produit (le squencement nominal sinterrompt, sans retour la squence nominale).
12
UML 2
Chapitre
EXEMPLE
Dans le cas dun retrait dargent, des squences alternatives se produisent par exemple dans
les situations suivantes :
Le client choisit deffectuer un retrait en euros ou en dollars.
Le client a la possibilit dobtenir un reu.
Une exception se produit si la connexion avec le systme central de la banque qui doit
vrifier la validit du compte est interrompue.
La survenue des erreurs dans les squences doit tre signale de la faon suivante : appel de
lexception Y o Y est le nom de lexception.
La dernire partie de la description dun cas dutilisation est une rubrique optionnelle. Elle
contient gnralement des spcifications non fonctionnelles (ce sont le plus souvent des
spcifications techniques, par exemple pour prciser que laccs aux informations bancaires
doit tre scuris). Cette rubrique contient aussi dventuelles contraintes lies aux interfaces
homme-machine (par exemple, pour donner la possibilit daccder tous les comptes dun
utilisateur partir de lcran principal).
Description dun retrait dargent

Identification
Nom du cas : retrait despces en euros.
But : dtaille les tapes permettant un guichetier deffectuer lopration de retrait deuros
demand par un client.
Acteur principal : Guichetier.
Acteur secondaire : Systme central.
Date : le 18/02/2005.
Responsable : M. Dupont.
Version : 1.0.
Squencement
Le cas dutilisation commence lorsquun client demande le retrait despces en euros.
Pr-conditions
Le client possde un compte (donne son numro de compte).
Enchanement nominal
1. Le guichetier saisit le numro de compte client.
2. Lapplication valide le compte auprs du systme central.
3. Lapplication demande le type dopration au guichetier.
4. Le guichetier slectionne un retrait despces de 200 euros.
5. Lapplication demande au systme central de dbiter le compte.
6. Le systme notifie au guichetier quil peut dlivrer le montant demand.
Post-conditions
Le guichetier ferme le compte.
Le client rcupre largent.
Rubriques optionnelles
Contraintes non fonctionnelles
Fiabilit : les accs doivent tre extrmement srs et scuriss.
Confidentialit : les informations concernant le client ne doivent pas tre divulgues.
Contraintes lies linterface homme-machine
Donner la possibilit daccder aux autres comptes du client.
Toujours demander la validation des oprations de retrait.
La squence nominale, les squences alternatives, les exceptions, etc., font quil existe une
multitude de chemins depuis le dbut du cas jusqu la fin. Chaque chemin est appel
scnario . Un systme donn gnre peu de cas dutilisation, mais, en gnral, beaucoup
de scnarios.
Remarque
Parfois, les utilisateurs ont du mal dcrire un cas sous une forme textuelle. Il est alors
judicieux de se servir dune autre forme de description, en utilisant un organigramme ou
encore en construisant des maquettes des interfaces homme-machine. Le dessin, mme sommaire, de laspect des crans des interfaces permet de fixer les ides ; il offre une excellente base pour la discussion avec le matre douvrage, qui le considre comme plus
parlant .
Conclusion
Les phases de recueil des besoins et dcriture des spcifications sont longues et fastidieuses.
Mais quand elles sont bien menes, elles permettent de lever toutes les ambiguts du cahier
des charges et de recueillir les besoins dans leurs moindres dtails. Les spcifications permettant dapprofondir les besoins (on parle dailleurs juste titre de spcifications techniques
des besoins), la frontire entre ces deux notions est floue.
Il nest pas question ce moment de la modlisation de limiter les besoins. Du ct du
matre duvre, la tendance est les limiter des fonctionnalits essentielles, tandis que
le matre douvrage, et surtout les utilisateurs, ont tendance en exprimer bien plus quil
nest possible den raliser. Le matre duvre doit faire preuve ici de patience et mener la
phase de spcifications de tous les besoins jusqu son terme. Cest ce moment seulement,
que des priorits sont mises sur les spcifications. Le matre duvre tente alors dagencer
les besoins de faon cohrente et fait plusieurs propositions de solutions au matre
douvrage, qui couvrent plus ou moins de besoins. UML ne propose rien pour mettre des
priorits sur les spcifications.
Le diagramme de cas dutilisation est un premier modle dun systme. Que savons-nous
sur le systme aprs avoir cr ce diagramme ? Sur le systme lui-mme, en interne, pas
grand-chose vrai dire. Cest encore une bote noire larchitecture et au mode de fonctionnement interne inconnus. Donc, a fortiori, ce stade, nous ne savons toujours pas comment le raliser. En revanche, son interface avec le monde qui lentoure est partiellement
connue : nous nous sommes placs du point de vue des acteurs pour dfinir les spcifications fonctionnelles. Il faut sattarder un instant sur lexpression partiellement connue
pour mesurer les limites du modle des cas dutilisation. Les spcifications fonctionnelles
disent ce que le systme doit faire pour les acteurs. En dautres termes, nous connaissons prcisment ce qui entre et ce qui sort du systme, mais, en revanche, nous ne savons toujours
pas comment raliser cette interface avec lextrieur.
14
UML 2
Chapitre
Lobjectif de cette phase de la modlisation est donc de clairement identifier les frontires du
systme et les interfaces quil doit offrir lutilisateur. Si cette tape commence avant la
conception de larchitecture interne du systme, il est en gnral utile, quand la rflexion est
suffisamment pousse, de poser les bases de la structure interne du systme, et donc dalterner analyse des besoins et bauche des solutions envisages.
Aux spcifications fonctionnelles sajoutent des spcifications techniques qui peuvent tre
vues comme des exigences pour la future ralisation.
Le prsent chapitre se poursuit par une srie de problmes corrigs. Le chapitre 2, quant
lui, prsente le diagramme des classes, qui permet de modliser la structure interne dun
systme.
Problmes
et exercices
La construction dun diagramme de cas dutilisation dbute par la recherche des
frontires du systme et des acteurs, pour se poursuivre par la dcouverte des cas
dutilisation. Lordre des exercices suit cette progression. Llaboration proprement
dite dun diagramme de cas dutilisation est illustre par plusieurs exercices.
Ce chapitre se termine par des tudes de cas de complexits croissantes.
EXERCICE 1
IDENTIFICATION
DES ACTEURS ET RECENSEMENT DE CAS DUTILISATION
SIMPLES
Considrons le systme informatique qui gre une station-service de distribution dessence.

On sintresse la modlisation de la prise dessence par un client.
1. Le client se sert de lessence de la faon suivante. Il prend un pistolet accroch une
pompe et appuie sur la gchette pour prendre de lessence. Qui est lacteur du systme ?
Est-ce le client, le pistolet ou la gchette ?
2. Le pompiste peut se servir de lessence pour sa voiture. Est-ce un nouvel acteur ?
3. La station a un grant qui utilise le systme informatique pour des oprations de gestion.
Est-ce un nouvel acteur ?
4. La station-service a un petit atelier dentretien de vhicules dont soccupe un mcanicien. Le grant est remplac par un chef datelier qui, en plus dassurer la gestion, est
aussi mcanicien. Comment modliser cela ?
1. Pour le systme informatique qui pilote la station-service, le pistolet et la gchette sont
des priphriques matriels. De ce point de vue, ce sont des acteurs. Il est nanmoins
ncessaire de consigner dans le systme informatique ltat de ces priphriques : ds
quun client prend le pistolet par exemple, le systme doit informer le pompiste en indiquant le type dessence choisi. Pistolet et gchette doivent donc faire partie du systme
modliser. Ici, nous sommes face deux options contradictoires : soit le pistolet et la
gchette sont des acteurs, soit ils ne le sont pas. Pour lever cette ambigut, il faut adopter
le point de vue du client. Le client agit sur le systme informatique quand il se sert de
lessence. Laction de se servir constitue une transaction bien isole des autres fonctionnalits de la station-service. Nous disons donc que Se servir est un cas dutilisation.
Le client, qui est en dehors du systme, devient alors lacteur principal, comme le montre
la figure 1.14. Ce cas englobe la prise du pistolet et lappui sur la gchette. Ces priphriques ne sont plus considrs comme des acteurs ; sils ltaient, la modlisation se ferait
un niveau de dtails trop important.
16
UML 2
Chapitre
Le client est donc lacteur principal du systme. Or, bien souvent, le pompiste note le
numro dimmatriculation du vhicule du client dans le systme informatique. Le client
doit alors tre modlis deux fois : la premire fois en tant quacteur, et la seconde,
lintrieur du systme, pour y conserver un numro dimmatriculation.
Figure 1.14
Station-service
Le client comme
acteur du cas
Se servir .
Se servir
Client
2. Un acteur est caractris par le rle quil joue vis--vis du systme. Le pompiste, bien
qutant une personne diffrente du client, joue un rle identique quand il se sert de
lessence. Pour le cas Se servir , il nest pas ncessaire de crer un acteur supplmentaire reprsentant le pompiste.
3. La gestion de la station-service dfinit une nouvelle fonctionnalit modliser. Le grant
prend le rle principal ; cest donc un nouvel acteur (figure 1.15).
Figure 1.15
Station-service
Deux acteurs
pour deux rles.
Se servir
Client
Grer la station
Grant
4. La station offre un troisime service : lentretien des vhicules. Le systme informatique

doit prendre en charge cette fonctionnalit supplmentaire. Un nouvel acteur apparat
alors : le mcanicien. Le grant est prsent un chef datelier qui est un mcanicien ayant
la capacit de grer la station. Il y a ainsi une relation de gnralisation entre les acteurs
Mcanicien et Chef datelier (figure 1.16) signifiant que le chef datelier peut, en plus
dassurer la gestion, entretenir des vhicules.
Figure 1.16
Station-service
Relation
de gnralisation
entre acteurs.
Se servir
Client
Entretenir des vhicules
Grer la station
Chef
datelier
Exercices
Mcanicien
EXERCICE 2
RELATIONS
Quel est le dfaut du diagramme prsent la figure 1.17 ?
Figure 1.17
Station-service
Exemple dun
diagramme
erron.
Dcrocher le pistolet
Appuyer sur la gchette
Reposer le pistolet
Payer
Client
Il ne faut pas introduire de squencement temporel entre des cas dutilisation (cette notion
apparat lors de la description des cas). De plus, il est incorrect dutiliser un trait plein pour
relier deux cas. Cette notation est rserve aux associations entre les acteurs et les cas.
EXERCICE 3
RELATIONS
CAS INTERNES
Choisissez et dessinez les relations entre les cas suivants :

1. Une agence de voyages organise des voyages o lhbergement se fait en htel. Le client
doit disposer dun taxi quand il arrive la gare pour se rendre lhtel.
Figure 1.18
Diagramme
incomplet des
cas dutilisation
dune agence
de voyages.
Agence de voyages
Rserver une
chambre dhtel
Rserver un taxi
Rserver un billet de train
Organiser un voyage
Agent de
voyages
2. Certains clients demandent lagent de voyages dtablir une facture dtaille. Cela donne
lieu un nouveau cas dutilisation appel tablir une facture dtaille . Comment
mettre ce cas en relation avec les cas existants ?
3. Le voyage se fait soit par avion, soit par train. Comment modliser cela ?
1.Le modlisateur a considr que lorganisation dun voyage est trop complexe pour tre
reprsente par un seul cas dutilisation. Il la donc dcompose en trois tches modlises par les trois cas dutilisation Rserver une chambre dhtel , Rserver un taxi et
Rserver un billet de train . Ces trois tches forment des transactions suffisamment
isoles les unes des autres pour tre des cas dutilisation. De plus, ces cas sont mutuellement
18
UML 2
Chapitre
indpendants. Ils constituent des cas internes du systme car ils ne sont pas relis directement un acteur.
Figure 1.19
Agence de voyages
Relations dinclusion
entre cas dutilisation.
Rserver une
chambre dhtel
inclut
Rserver un taxi
inclut
inclut
Organiser un voyage
Agent de
voyages
2 .Ltablissement dune facture dtaille se fait uniquement sur demande du client. Ce

caractre optionnel est modlis par une relation dextension entre les cas Organiser un
voyage et tablir une facture dtaille . Lextension porte la condition la demande
du client .
Figure 1.20
Agence de voyages
Relation dextension
entre cas dutilisation.
Rserver une
chambre dhtel
Rserver un taxi
inclut
inclut
inclut
Organiser un voyage
Agent de
voyages
Points dextension :
tablirUneFacture
Condition : { la demande du
client}
Point dextension : tablirUneFacture
tend
tablir une facture dtaille
Exercices
3. Il y a maintenant deux cas particuliers : le voyage se fait en train ou en avion. Ces cas particuliers sont modliss par les cas Rserver un billet de train et Rserver un billet
davion . Ceux-ci sont lis un cas plus gnral appel Rserver un titre de transport .
Figure 1.21
Agence de voyages
Relation de
gnralisation entre
cas dutilisation.
Rserver une
chambre dhtel
inclut
Rserver un taxi
inclut
Rserver un titre
de transport
inclut
Organiser un voyage
Points dextension :
tablirUneFacture
Agent de
voyages
Condition : { la demande du client}

Point dextension : tablirUneFacture
Rserver un billet
de train
tend
Rserver un billet
davion
tablir une facture dtaille
EXERCICE 4
IDENTIFICATION
DES ACTEURS, RECENSEMENT DES CAS DUTILISATION
ET RELATIONS SIMPLES ENTRE CAS
Modlisez avec un diagramme de cas dutilisation le fonctionnement dun distributeur

automatique de cassettes vido dont la description est donne ci-aprs.
Une personne souhaitant utiliser le distributeur doit avoir une carte magntique spciale.
Les cartes sont disponibles au magasin qui gre le distributeur. Elles sont crdites dun
certain montant en euros et rechargeables au magasin. Le prix de la location est fix par
tranches de 6 heures (1 euro par tranche). Le fonctionnement du distributeur est le suivant : le client introduit sa carte ; si le crdit est suprieur ou gal 1 euro, le client est
autoris louer une cassette (il est invit aller recharger sa carte au magasin sinon) ; le
client choisit une cassette et part avec ; quand il la ramne, il lintroduit dans le distributeur puis insre sa carte ; celle-ci est alors dbite ; si le montant du dbit excde le crdit
de la carte, le client est invit rgulariser sa situation au magasin et le systme mmorise
le fait quil est dbiteur ; la gestion des comptes dbiteurs est prise en charge par le personnel du magasin. On ne sintresse ici qu la location des cassettes, et non la gestion du
distributeur par le personnel du magasin (ce qui exclut la gestion du stock des cassettes).
Le seul acteur est le client.

Lacquisition dune carte et sa recharge ne se font pas via le distributeur : il faut aller au
magasin. Ces fonctions ne donnent pas lieu des cas dutilisation.
Il ne faut pas faire apparatre un squencement temporel dans un diagramme de cas dutilisation. On ne fait donc pas figurer les tapes successives telles que lintroduction de la carte
puis le choix dune cassette, etc. Ce niveau de dtails apparatra quand on dcrira les cas
dutilisation (sous forme textuelle par exemple). Dans un diagramme de cas dutilisation, il
20
UML 2
Chapitre
faut rester au niveau des grandes fonctions et penser en termes de transactions (une transaction est une squence doprations qui fait passer un systme dun tat cohrent initial
un tat cohrent final).
Il ny a donc que deux cas : Emprunter une vido et Restituer une vido (figure 1.22).
Figure 1.22
Magasin de location de cassettes vido
Diagramme de cas
dutilisation dun
distributeur de
cassettes vido.
Emprunter une vido
Client
Restituer une vido
Nom de lacteur
Client
Rle
Reprsente un client du magasin de location de cassettes vido.
Pour dcrire le cas Emprunter une vido , imaginons un scnario possible. Le client
introduit sa carte. Il doit ensuite pouvoir choisir une vido. Quels sont les critres de choix ?
Lnonc ne prcise pas ces critres. Ce problme arrive frquemment en situation relle.
Le matre douvrage dans un projet informatique de cette ampleur est bien souvent le propritaire du magasin de location. Il sait rarement rdiger un cahier des charges. Cest le rle
du matre duvre dobliger le matre douvrage bien formuler ses besoins. Choisir une
vido peut tre complexe : la recherche se fait-elle par genres, par titres ou par dates de sortie des films en salles ? Si la recherche se fait par genres, quels sont-ils ? Rechercher un film
semble plus complexe quon ne limaginait au premier abord. De plus, cette fonctionnalit
peut tre isole de la location proprement dite, qui concerne plutt la gestion de la carte.
Ces remarques incitent crer le cas supplmentaire Rechercher une vido . Lemprunt
dune vido inclut sa recherche. Une relation dinclusion intervient donc entre les cas
Emprunter une vido et Rechercher une vido , comme le montre la figure 1.23.
Figure 1.23
Magasin de location de cassettes vido
Diagramme de cas
dutilisation
complt par la
recherche dune
vido.
Emprunter une vido
inclut
Rechercher une vido
Client
Restituer une vido
Le succs dUML en tant que langage de modlisation sexplique, entre autres, par le fait
quil oblige le modlisateur poser les bonnes questions au bon moment ; la modlisation vient peine de commencer que dj des questions se posent. Il faut cependant
veiller rester au niveau du recueil des besoins et des spcifications et ne faire aucun
choix de conception du systme. Il faut se contenter de dcrire les fonctions du systme
sans chercher savoir comment les raliser.
Exercices
ce point de la modlisation, deux remarques simposent :
Le problme des critres de recherche a conduit une rvision du diagramme de cas

dutilisation. Cet aller-retour sur les modles est ncessaire. Chacun deux apporte des
informations complmentaires qui peuvent remettre en cause les modles existants. Une
fois tous les modles tablis, la modlisation sera alors aboutie.
EXERCICE 5
DESCRIPTION DUN
CAS DUTILISATION
Dcrivez sous forme textuelle les cas dutilisation Emprunter une vido et Rechercher
une vido du diagramme prsent la figure 1.23. La recherche dune vido peut se faire
par genres ou par titres de film. Les diffrents genres sont action, aventure, comdie et
drame. Quand une liste de films saffiche, le client peut trier les films par titres ou par dates
de sortie en salles.
Avant de prsenter la solution, donnons quelques indications :

Tous les cas dutilisation dun systme doivent tre dcrits sous forme textuelle (dans la
suite de ce chapitre, nous omettrons ventuellement de le faire pour des raisons de place
ou dintrt).
Quand une erreur (exception) est dtecte dans un cas, une squence derreurs est active
(par exemple, voir la squence E1 dans la description suivante). La squence nominale
nest pas reprise et le cas sinterrompt aussitt.
Description du cas Emprunter une vido

Identification
Nom du cas : Emprunter une vido .
But : dcrire les tapes permettant au client du magasin demprunter une cassette vido via
le distributeur automatique.
Acteur principal : Client.
Acteur secondaire : nant.
Date de cration : le 31/12/2004.
Date de mise jour : le 1/1/2005.
Version : 1.1.
Squencement
Le cas dutilisation commence lorsquun client introduit sa carte.
Pr-conditions
Le client possde une carte quil a achete au magasin.
Le distributeur est aliment en cassettes.
Enchanement nominal
1. Le systme vrifie la validit de la carte.
2. Le systme vrifie que le crdit de la carte est suprieur ou gal 1 euro.
3. Appel du cas Rechercher une vido .
4. Le client a choisi une vido.
5. Le systme indique, daprs la valeur de la carte, pendant combien de temps (tranches
de 6 heures) le client peut garder la cassette.
6. Le systme dlivre la cassette.
22
UML 2
Chapitre
Description du cas Emprunter une vido (suite)

7. Le client prend la cassette.
8. Le systme rend la carte au client.
9. Le client prend sa carte.
Enchanements alternatifs
A1 : Le crdit de la carte est infrieur 1 euro.
Lenchanement dmarre aprs le point 2 de la squence nominale :
3. Le systme indique que le crdit de la carte ne permet pas au client demprunter une
vido.
4. Le systme invite le client aller recharger sa carte au magasin.
La squence nominale reprend au point 8.
Enchanements dexception
E1 : La carte introduite nest pas valide.
2. Le systme indique que la carte nest pas reconnue.
3. Le distributeur jecte la carte.
E2 : La cassette nest pas prise par le client.
7. Au bout de 15 secondes le distributeur avale la cassette.
8. Le systme annule la transaction (toutes les oprations mmorises par le systme sont
dfaites).
E3 : La carte nest pas reprise par le client.
9. Au bout de 15 secondes le distributeur avale la carte.
10. Le systme consigne cette erreur (date et heure de la transaction, identifiant du client,
identifiant du film).
E4 : Le client a annul la recherche (il na pas choisi de vido).
Lenchanement dmarre au point 4 de la squence nominale :
Post-conditions
Le systme a enregistr les informations suivantes :
La date et lheure de la transaction, la minute prs : les tranches de 6 heures sont calcules la minute prs.
Lidentifiant du client.
Lidentifiant du film emprunt.
Le distributeur doit fonctionner 24 heures sur 24 et 7 jours sur 7.
La vrification de la validit de la carte doit permettre la dtection des contrefaons.
Exercices
Contrainte lie linterface homme-machine

Avant de dlivrer la cassette, demander confirmation au client.
Description du cas Rechercher une vido

Identification
Nom du cas : Rechercher une vido .
But : dcrire les tapes permettant au client de rechercher une vido via le distributeur automatique.
Acteur principal : nant (cas interne inclus dans le cas Emprunter une vido ).
Acteur secondaire : nant.
Date de cration : le 31/12/2004.
Version : 1.0.
Squencement
Le cas dmarre au point 3 de la description du cas Emprunter une vido .
Enchanement nominal (le choix du film se fait par genres)
1. Le systme demande au client quels sont ses critres de recherche pour un film (les
choix possibles sont : par titres ou par genres de film).
2. Le client choisit une recherche par genres.
3. Le systme recherche les diffrents genres de film prsents dans le distributeur.
4. Le systme affiche une liste des genres (les choix possibles sont action, aventure, comdie et drame).
5. Le client choisit un genre de film.
6. Le systme affiche la liste de tous les films du genre choisi prsents dans le distributeur.
7. Le client slectionne un film.
Enchanements alternatifs
A1 : Le client choisit une recherche par titres.
2. Le client choisit une recherche par titres.
3. Le systme affiche la liste de tous les films classs par ordre alphabtique des titres.
La squence nominale reprend au point 7.
Enchanements dexception
E1 : Le client annule la recherche.
Lenchanement peut dmarrer aux points 2, 5 et 7 de la squence nominale :
Appel de lexception E4 du cas Emprunter une vido .
Post-conditions
Le systme a mmoris le film choisi par le client.
Contraintes lies linterface homme-machine
Quand une liste de films saffiche, le client peut trier la liste par titres ou par dates de sortie
en salles.
Le client peut se dplacer dans la liste et la parcourir de haut en bas et de bas en haut.
Ne pas afficher plus de 10 films la fois dans la liste.
24
UML 2
Chapitre
EXERCICE 6
RELATIONS DEXTENSION ENTRE CAS DUTILISATION,

DE CAS DUTILISATION EN PAQUETAGES
REGROUPEMENT
Modlisez laide dun diagramme de cas dutilisation un systme informatique de pilotage dun robot distance.
Le fonctionnement du robot est dcrit ci-aprs.
Un robot dispose dune camra pour filmer son environnement. Il peut avancer et reculer
grce un moteur lectrique capable de tourner dans les deux sens et commandant la
rotation des roues. Il peut changer de direction car les roues sont directrices. Il est pilot
distance : les images prises par la camra sont envoyes vers un poste de tlpilotage. Ce
dernier affiche lenvironnement du robot sur un cran. Le pilote visualise limage et utilise
des commandes pour contrler distance les roues et le moteur du robot. La communication entre le poste de pilotage et le robot se fait via des ondes radio.
Le systme informatique est compos de deux sous-systmes :
le sous-systme du robot ;
le sous-systme du poste de tlpilotage.
Do lide de faire deux diagrammes de cas dutilisation un par sous-systme et de
placer chaque diagramme dans un paquetage. La figure 1.24 montre deux paquetages : un
pour le sous-systme du robot et un pour le sous-systme du poste de pilotage. La relation
de dpendance entre les paquetages signifie que le systme de pilotage utilise le robot.
Reprsentation
du systme de
tlpilotage dun
robot par des
paquetages.
Robot
Systme de pilotage
Commenons par modliser le robot. Ses capteurs (camra, moteur et roues) sont lextrieur du systme informatique et ils interagissent avec lui. Ils correspondent a priori la
dfinition dacteurs. Reprenons chaque capteur pour ltudier en dtail :
Le systme doit demander la capture dune image la camra et raliser la capture. La
camra est donc un acteur associ un cas dutilisation appel Capturer images
(figure 1.25).
Le sens de rotation du moteur peut tre command. Le moteur est lacteur ; il est associ
un cas appel Commander le moteur .
La direction des roues peut tre modifie, do la cration du cas dutilisation Commander la direction reli lacteur Direction.
Pour pouvoir envoyer les images au poste de pilotage et recevoir les commandes en retour, il
faut un capteur supplmentaire, metteur/rcepteur dondes radio. Le systme informatique ne va pas se charger denvoyer et de recevoir des ondes radio cest le rle des priphriques dmission et de rception mais il doit soccuper du transcodage des images pour
les envoyer via des ondes. Le systme informatique doit-il raliser lui-mme ce transcodage
ou bien les fonctions de transcodage sont-elles fournies avec les priphriques ? Pour
rpondre cette question, il faudrait raliser une tude de march des metteurs/rcepteurs
Exercices
Figure 1.24
radio. Cela dpasse le cadre de cet ouvrage. Considrons que le systme informatique intervient, ne serait-ce que pour appeler des fonctions de transcodage. Cela constitue un cas
dutilisation. Deux flots dinformations distincts doivent tre envoys au poste de pilotage :
des images et des commandes. Cette dernire remarque incite crer deux cas dutilisation :
un pour mettre des images ( Envoyer les images ) et un pour recevoir les commandes
( Recevoir les commandes ). En outre, selon lutilisation du robot, la transmission des
images seffectue plus ou moins vite : si les dplacements du robot sont rapides par exemple,
la transmission doit ltre aussi. Ces contraintes de ralisation font partie des spcifications
techniques du systme. Elles doivent figurer dans la description textuelle du cas dutilisation. Sur le diagramme de cas dutilisation, il est possible de placer une relation dextension
entre les cas Envoyer les images et Capturer images , en indiquant comme point
dextension quel moment de la capture et quelle frquence sont envoyes les images.
Nom de lacteur
Camra
Direction
Moteur
metteur
Rcepteur
Rle
Permet de capturer des images de lenvironnement du robot.

Permet de diriger les roues du robot.
Permet de faire avancer ou reculer le robot.
Permet denvoyer des ondes radio.
Permet de recevoir des ondes radio.
Figure 1.25
Systme de contrle dun robot
Diagramme de cas
dutilisation du
robot.
Capturer images
Points dextension :
envoiImage
Camra
Condition : {ds quune image
complte a t capture}
Point dextension : envoiImage
tend
Envoyer les images
metteur
Recevoir les commandes
Points dextension :
- commandeMoteur
- commandeDirection
Condition : {ds quune

commande concerne le moteur}
Point dextension : commandeMoteur
Condition : {ds quune commande

concerne la direction}
Point dextension : commandeDirection
tend
Commander le moteur
Moteur
26
UML 2
Rcepteur
tend
Commander la direction
Direction
Chapitre
Intressons-nous prsent au sous-systme de pilotage. La figure 1.26 prsente le diagramme de cas dutilisation, qui se dduit sans problme du diagramme prcdent.
Nom de lacteur
Pilote
metteur
Rcepteur
Rle
Reprsente un pilote qui agit sur les commandes distance.

Permet denvoyer des ondes radio.
Permet de recevoir des ondes radio.
Figure 1.26
Systme de pilotage dun robot
Diagramme de cas
dutilisation du
systme de pilotage.
Recevoir des images

Points dextension :
afficheImage
Rcepteur
Condition : {ds quune image
complte a t reue}
Point dextension : afficheImage
tend
Afficher les images
Tlpiloter
Pilote
Points dextension :
envoiCommande
Condition : {ds quune commande

a t manipule par le pilote}
Point dextension : envoiCommande
tend
Envoyer des commandes
metteur
RELATIONS ENTRE
DUTILISATION
ACTEURS, EXTENSIONS CONDITIONNELLES ENTRE CAS
Modlisez laide dun diagramme de cas dutilisation une mdiathque dont le fonctionnement est dcrit ci-aprs.
Une petite mdiathque na quune seule employe qui assume toutes les tches :
la gestion des uvres de la mdiathque ;
la gestion des adhrents.

Le prt dun exemplaire dune uvre donne est limit trois semaines. Si lexemplaire
nest pas rapport dans ce dlai, cela gnre un contentieux. Si lexemplaire nest toujours
pas rendu au bout dun an, une procdure judiciaire est dclenche.
Laccs au systme informatique est protg par un mot de passe.
Exercices
EXERCICE 7
La mdiathque nemploie quune employe. Nanmoins, un acteur est dtermin par le

rle quil joue vis--vis du systme modliser. Ici, lemploye a deux rles essentiels :
le rle de bibliothcaire qui gre les uvres ainsi que les adhrents ;
le rle de gestionnaire des contentieux ayant les connaissances juridiques suffisantes pour
dclencher des procdures judiciaires.
Ces rles sont modliss par deux acteurs : Bibliothcaire et Gestionnaire des contentieux.
Un gestionnaire de contentieux est un bibliothcaire avec pouvoir. Les acteurs correspondants sont relis par une relation de gnralisation (figure 1.27). Ainsi, lacteur Gestionnaire
des contentieux peut utiliser les cas associs lacteur Bibliothcaire. A contrario, lacteur
Bibliothcaire ne peut pas utiliser les cas relatifs la gestion des contentieux.
Jusqu prsent la mdiathque fonctionne avec une seule employe. Si, lavenir, plusieurs
employs devenaient ncessaires, le systme informatique pourrait fonctionner avec deux
groupes dutilisateurs : un premier groupe dont le rle serait limit celui des bibliothcaires et un deuxime groupe susceptible de grer les contentieux en plus davoir un rle de
bibliothcaire. Lauthentification du groupe auquel appartient un utilisateur du systme
doit tre contrle par un mot de passe. La gestion des mots de passe requiert la prsence
dun administrateur du systme. Pour UML, peu importe si cette personne fait partie ou
non du groupe des bibliothcaires ou des gestionnaires de contentieux. Comme un nouveau
rle apparat dans le systme, cela justifie la dfinition dun acteur supplmentaire : Administrateur. Tous les cas dutilisation lis aux acteurs incluent la procdure dauthentification
matrialise par le cas Sauthentifier .
Dans le diagramme, la gestion des adhrents et la gestion des emprunts sont spares :
Grer les adhrents consiste ajouter, supprimer ou modifier lenregistrement dun
adhrent dans la mdiathque, tandis que Grer les emprunts consiste prter des exemplaires aux adhrents dj inscrits.
La gestion des contentieux a deux degrs dalerte :
Un exemplaire na pas t rendu au bout de trois semaines.
Un exemplaire na toujours pas t rapport au bout dun an.
Cela correspond deux fonctionnalits distinctes puisque, dans le deuxime cas seulement,
il faut dclencher une procdure judiciaire. Nous reprsentons cela par deux cas dutilisation : Grer les contentieux et Dclencher une procdure judiciaire . Ces deux cas sont
lis par une relation dextension soumise la condition si le retard dpasse un an .
Nom de lacteur
Bibliothcaire
Gestionnaire des
contentieux
Administrateur
28
UML 2
Rle
Reprsente un bibliothcaire. Il gre les uvres, les adhrents et les

emprunts.
Reprsente un bibliothcaire qui peut grer les contentieux.
Reprsente un gestionnaire des droits daccs au systme.
Chapitre
Figure 1.27
Une mdiathque
Diagramme de cas
dutilisation dune
mdiathque.
Grer les
uvres
inclut
Rechercher
les uvres
inclut
Grer les
adhrents
Bibliothcaire
inclut
Sauthentifier
inclut
Rechercher
les adhrents
inclut
inclut
inclut
Grer les comptes

utilisateurs
Grer les
emprunts
Administrateur
Grer les contentieux
Gestionnaire des
contentieux
Points dextension :
procdureJudiciaire : {pas
chaque fois que le gestionnaire
utilise le cas mais
une fois par mois}
Condition : {si plus dun an de retard}

Point dextension : procdureJudiciaire
tend
Dclencher une
procdure judiciaire
IDENTIFICATION
DES ACTEURS, RECENSEMENT DES CAS DUTILISATION
INTERNES ET RELATION DE GNRALISATION ENTRE CAS
Modlisez laide dun diagramme de cas dutilisation le systme informatique qui gre la
distribution dessence dans une station-service. Le fonctionnement de la distribution de
lessence est dcrit ci-aprs.
Avant de pouvoir tre utilise par un client, la pompe doit tre arme par le pompiste. La
pompe est ainsi apprte, mais ce nest que lorsque le client appuie sur la gchette du pistolet de distribution que lessence est pompe. Si le pistolet est dans son tui de rangement
et si la gchette est presse, lessence nest pas pompe. La distribution de lessence un
client est termine quand celui-ci remet le pistolet dans son tui. La mesure de lessence
distribue se fait par un dbitmtre.
Quatre types de carburants sont proposs : diesel, sans plomb avec un indice doctane de
98, sans plomb avec un indice doctane de 95, et plomb.
Le paiement peut seffectuer en espces, par chque ou par carte bancaire. En fin de journe, les transactions sont archives.
Le niveau des cuves ne doit pas descendre en dessous de 5 % de la capacit maximale.
Sinon les pompes ne peuvent plus tre armes.
Exercices
EXERCICE 8
Pour un systme complexe, il vaut mieux se concentrer sur les fonctions essentielles puis
passer aux cas moins importants.
Identification des principaux acteurs et recensement des cas dutilisation

essentiels
Lacteur principal est videmment le client. Il utilise le systme pour obtenir de lessence. Il
est associ au cas dutilisation Se servir . Rappel : dans un diagramme de cas dutilisation,
on ne dtaille pas la squence des oprations. Par exemple, le type dessence choisi sera pris
en compte quand on dcrira le cas.
Imaginons le fonctionnement de la pompe : lessence ne peut tre distribue que si la
pompe est arme ; le client prend un pistolet ; sur le pupitre du pompiste est indiqu le type
dessence choisi ; le pompiste arme la pompe en appuyant sur un bouton de son pupitre, ce
qui initialise la pompe.
Ainsi, le cas Se servir doit inclure larmement de la pompe. Deux solutions sont possibles :
La premire utilise un cas unique (Se servir), et deux acteurs (Client et Pompiste),
comme le montre la figure 1.28.
Figure 1.28
Se servir de
lessence : solution
avec un cas unique.
Se Servir
Client
Pompiste
La deuxime solution met en uvre deux cas : Se servir et Armer pompe

(figure 1.29).
Figure 1.29
Se servir de
lessence : solution
avec deux cas.
inclut
Se Servir
Client
Armer pompe
Pompiste
Larmement de la pompe est indispensable, sinon lessence ne peut tre distribue, do la

relation dinclusion entre les cas Se servir et Armer pompe . Larmement de la pompe
se fait en une seule action pour le pompiste : celle darmer la pompe en appuyant sur un
bouton. La description de larmement se rsume donc une squence trs sommaire
dactions. Faut-il alors reprsenter cela par un cas dutilisation ? Largument qui fait pencher
pour le maintien du cas Armer pompe est que larmement est une opration bien isole
des autres fonctions : il sagit dinitialiser la pompe et donc de piloter des priphriques
(mcaniques, lectroniques). Vu sous cet angle, larmement est suffisamment complexe
et bien isol des autres fonctions pour en faire un cas (figure 1.31).
Le pompiste est un acteur secondaire du cas Armer pompe (cest un cas interne pour
lequel le pompiste est consult). Larmement de la pompe nest possible que si le niveau de
la cuve est suffisant. Un dtecteur de niveau (priphrique externe au systme informatique) est ncessaire. Ce priphrique est reprsent par lacteur Capteur niveau cuve pour
armement . Il est secondaire car linformation sur le niveau de la cuve ne lui est pas destine. Si le niveau est trop bas, cest le pompiste qui doit en tre inform. Il saura ainsi ce qui
empche larmement de la pompe. La vrification du niveau de la cuve est importante pour
le systme. De plus, cette opration constitue une transaction bien isole des autres fonctions (il sagit de contrler un priphrique matriel). Cest la raison pour laquelle on
dcide de crer un cas Vrifier niveau cuve pour armement . Pour transmettre le niveau
30
UML 2
Chapitre
de la cuve au pompiste, il faut relier lacteur Pompiste au cas Vrifier niveau cuve pour
armement . Le pompiste est inform que le niveau est trop bas, mais la vrification doit
tre automatique pour que les pompes soient ventuellement bloques. Une relation
dinclusion intervient donc entre les cas Armer pompe et Vrifier niveau cuve pour
armement (figure 1.31).
Recensement des cas de moindres importances

Aprs avoir trouv les principaux cas, il est temps de se consacrer ceux de moindre importance. Il ne faut pas oublier de couvrir tous les besoins et ne pas hsiter introduire des cas
auxquels le matre douvrage na pas pens. Il validera ou pas le modle a posteriori.
Lnonc naborde pas le problme du remplissage des cuves dessence. Cette opration est
ralise par une entreprise tierce de livraison dessence. Elle doit cependant tre consigne
dans le systme informatique de la station-service. Une solution consiste alerter le pompiste ds que le niveau des cuves descend au-dessous dun certain seuil. Ce deuxime seuil,
appel seuil de remplissage des cuves , doit tre suprieur au seuil des 5 % de lnonc
(celui qui empche les pompes dtre armes). Quand il est atteint, le pompiste prvient
lentreprise de livraison dessence de sorte viter de tomber au seuil des 5 %. Si la stationservice est sur une autoroute, la livraison dessence doit tre garantie 24 heures sur 24. Il faut
peut-tre contacter la socit de livraison automatiquement sans passer par lintermdiaire du pompiste ds que le niveau devient trop bas. Le capteur du niveau de remplissage
est reprsent par un acteur appel Capteur niveau cuve pour remplissage (figure 1.31).
Il est associ au cas Vrifier niveau cuve pour remplissage , lui-mme associ lacteur
Pompiste.
Abordons prsent le problme du paiement. De concert avec le matre douvrage, le matre
duvre imagine un fonctionnement possible du systme : ds que le client raccroche le pistolet, le montant payer est calcul ; il saffiche sur le pupitre du pompiste ; le client qui
vient payer indique son mode de paiement (espces, chque ou carte bancaire) ; le pompiste
slectionne le mode de paiement choisi. partir de l, les cas divergent :
Pour un paiement en espces, le pompiste encaisse le montant demand, puis valide la
transaction, qui est mmorise dans le systme informatique (le montant, la date de la
transaction et le mode de paiement sont conservs).
Si le paiement se fait par chque, ce dernier est rempli automatiquement, puis le pompiste lencaisse. La transaction est mmorise dans le systme informatique (en plus de la
date, du montant et du mode paiement, sont conservs les rfrences dune pice didentit ou le numro dimmatriculation du vhicule).
Comment reprsenter cela dans un diagramme de cas dutilisation ? Une premire solution
(prsente la figure 1.31) consiste crer un cas gnral appel Payer , et trois cas particuliers relis par une relation de spcialisation au cas Payer . Chacun des trois cas reprsente
un mode de paiement.
Une autre solution (prsente la figure 1.30) repose sur un cas, Payer , qui se droule
jusquau choix du mode de paiement, puis, selon le type de paiement, un des trois modes
est activ ( Payer en espces , Payer par chque ou Payer par carte bancaire ). Ces
trois cas sont typiquement des extensions du cas Payer , o lextension est soumise
condition.
Exercices
Pour un paiement par carte bancaire, la banque de la station-service ralise une transaction avec la banque du client. Les seules informations conserver dans le systme informatique de la station-service sont le montant, la date de la transaction et le mode de
paiement.
Figure 1.30
Utilisation
de relations
dextension
pour modliser
le paiement.
Payer
Points dextension :
- paiementEspce,
- paiementParChque
- paiementParCarteBancaire
{les trois extensions sexcluent mutuellement et
une extension intervient au tout dbut du
paiement}
Condition : {si le client choisit de payer
par carte bancaire}
Point dextension : paiementParCarteBancaire
tend
tend
tend
Payer par carte bancaire
Condition : {si le client choisit de

payer par chque}
Point dextension : paiementParChque
Condition : {si le client

choisit de payer en espce}
Point dextension :
paiementEnEspce
Payer en espces
Payer par
chque
Ces deux solutions sont possibles. Il est difficile de dire laquelle est la meilleure. La suite de
lexercice se fonde arbitrairement sur la reprsentation avec des relations de gnralisation
(figure 1.31). Le modlisateur se retrouve rgulirement face ce dilemme. La rponse est
souvent la mme : peu importe la faon de modliser un systme du moment que le modle
est correct un modle est correct sil montre une solution qui satisfait le matre douvrage
ainsi que les futurs utilisateurs du systme.
Aboutir une modlisation correcte

Il faut prendre le temps dlaborer le diagramme de cas dutilisation, bien quil soit gnralement simple btir, afin dviter les a priori qui peuvent conduire une modlisation errone.
la relecture du fonctionnement du paiement tel quil est dcrit prcdemment, le pompiste devient lacteur principal du cas de paiement. Cest un peu surprenant car on pourrait
croire au premier abord quil sagit du client. Or, la seule fois o le client intervient directement sur le systme informatique de la station-service est quand il saisit son numro de
carte bancaire. Toutes les autres situations ncessite lintervention du pompiste. Attardonsnous un instant encore sur le paiement par carte bancaire. Il faut de toute vidence faire
figurer un acteur supplmentaire qui reprsente la banque, car elle interagit avec le systme
sans en faire partie. Cest un acteur secondaire qui est sollicit uniquement pour confirmer
le bon droulement de la transaction. Quel est le rle de cet acteur ? Le plus souvent, les
solutions de paiement par carte bancaire sont disponibles cls en main sur le march. Elles
incluent un lecteur de cartes ainsi quun logiciel pour le piloter. Le matre duvre doit proposer plusieurs solutions prsentes sur le march au matre douvrage, et ventuellement
une solution propritaire si aucune solution du march ne lui convient. Le matre douvrage
dcidera. Dans le cadre de cet exercice, dfaut de pouvoir dialoguer avec un matre
douvrage, nous choisissons lachat dune solution cls en main pour le paiement par carte
bancaire. Dans ce cas, le client, lorsquil saisit le code de sa carte, ninteragit plus directement avec le systme informatique de la station-service. Ainsi, quel que soit le mode de
paiement, tout passe par lintermdiaire du pompiste. Le client nest donc pas un acteur du
systme.
Le calcul automatique du montant payer peut se faire ds que le client raccroche le pistolet
(ce qui intervient la fin du cas Se servir ). Pour indiquer le moment o le montant est
32
UML 2
Chapitre
calcul, on peut ajouter une relation dextension entre les cas Se servir et Payer , avec
un point dextension qui prcise le moment o le calcul du montant intervient, comme le
montre la figure 1.31. Le paiement peut aussi intervenir avant de se servir. Dans ce cas, il est
possible dajouter un deuxime point dextension (voir la figure 6.17 du chapitre 6).
Modlisation des concepts abstraits

Parfois, le langage UML peut paratre limit. Il faut alors trouver, parmi les lments du langage, celui qui convient le mieux une situation donne.
Un dernier besoin nest pas dcrit par le diagramme de cas dutilisation : cest larchivage
en fin de journe des transactions. Faut-il prendre en compte ce cas et, si oui, quel acteur
lutilise ? Un cas dutilisation est dclench par un vnement. Les vnements peuvent tre
classs en trois catgories :
Les vnements externes. Ils sont dclenchs par des acteurs.
Les vnements temporels. Ils rsultent de latteinte dun moment dans le temps.
Les vnements dtats. Ils se produisent quand quelque chose dans le systme ncessite
un traitement.
Ici, il sagit dun vnement temporel. Il est difficile de dfinir un acteur qui dclencherait
cet vnement. Comment le temps peut-il interagir avec un systme ? Cela dit, larchivage
quotidien est une fonctionnalit essentielle. Il faut la faire figurer dans la modlisation du
systme. quelle tape de la modlisation doit-on prendre en compte cette fonctionnalit ?
Comme nous en sommes produire le premier modle du systme et que cette fonctionnalit est importante, nous choisissons, pour ne pas loublier, den faire un cas dutilisation.
Pour dclencher ce cas, nous introduisons un acteur appel Timer qui, une fois par jour,
dclenche un vnement temporel. Timer est un acteur, il est donc en dehors du systme.
Cela signifie que lheure est donne par une horloge externe notre systme informatique
(par exemple, lhorloge du systme dexploitation du systme informatique).
La prise en compte des vnements dtats est plus dlicate puisque, par dfinition, ils se
produisent lintrieur dun systme. Ils ne peuvent donc pas tre dclenchs par un acteur,
qui est forcment en dehors du systme. Il est toutefois possible quun vnement dtat
active un cas dutilisation condition que ce cas soit interne au systme. Une faon de
reprsenter un cas de ce type consiste le relier dautres cas via des relations dextension et
faire figurer comme condition dextension lvnement dtat. Cest cette solution qui a
t adopte entre les cas Se servir et Payer , en considrant ce dernier comme un cas
interne vis--vis du cas Se servir .
Client
Pompiste
Capteur niveau cuve
pour armement
Capteur niveau cuve
pour remplissage
Timer
Banque
Rle
Acteur principal du cas dutilisation Se servir . Reprsente le client

qui se sert de lessence.
Acteur principal des cas Payer et Vrifier niveau cuve pour
remplissage . Acteur secondaire pour le cas Armer pompe .
Acteur secondaire du cas Vrifier niveau cuve pour armement .
Acteur secondaire du cas Vrifier niveau cuve pour remplissage .
Acteur secondaire du cas Archiver les transactions .
Acteur secondaire du cas Payer par carte bancaire .
Exercices
Nom de lacteur
Figure 1.31
Diagramme de cas
dutilisation dune
station-service.
Capteur niveau cuve

pour armement
Capteur niveau cuve

pour remplissage
Vrifier niveau cuve

pour armement
Vrifier niveau cuve

pour remplissage
Station-Service
inclut
Se servir
Client
inclut
Armer pompe
Points dextension :
paiement : { la fin du
cas se servir }
Condition : {si le client

a pris de lessence avant
de raccrocher le pistolet}
Pompiste
tend
Payer
Payer en espce
Payer par carte

bancaire
Banque
Payer par chque
Archiver les
transactions
Tous les soirs minuit

Timer
34
UML 2
Chapitre
Diagramme
de classes
1.
2.
3.
4.
5.
6.
7.
8.
Exemple de diagramme de classes

De lobjet la classe .....................
Interface .......................................
Relations entre classes ...................
Connecteurs, signaux et ports ........
Diagramme dobjets ....................
Contraintes ...................................
Construction dun diagramme
de classes .....................................
36
36
44
45
54
54
56
57
1. Proprits dune classe ................... 61
2. Classe strotype ......................... 63
3. Nom dune classe .......................... 64
4. Dfinition dun message asynchrone 64
5. classe active .................................. 65
6. Contrainte sur une classe................ 65
7. Classe paramtrable ...................... 66
8. Relations simples............................ 66
9. Ralisation dune interface ............. 68
10. Utilisation dune interface ............... 69
11. Relations ....................................... 70
12. Hritage ........................................ 71
13. Hritage ....................................... 73
14. Diagramme dobjets ...................... 75
15. Patron de conception objets
composites .................................. 75
16. Application htelire ...................... 76
17. Application bancaire ..................... 77
18. Rservation de billets davion ......... 79
19. Patron Bridge .......................... 81
20. Patron Adapteur ..................... 82
21. Organisation du langage UML ....... 84
Le diagramme de classes est considr comme le plus

important de la modlisation oriente objet. Alors que le
diagramme de cas dutilisation montre un systme du point
de vue des acteurs, le diagramme de classes en montre la
structure interne. Il contient principalement des classes. Une
classe contient des attributs et des oprations. Le diagramme
de classes nindique pas comment utiliser les oprations :
cest une description purement statique dun systme.
Laspect dynamique de la modlisation est apport par les
diagrammes dinteractions (voir chapitre 3).
35
(1)
Exemple de diagramme de classes

Les classeurs dcrivent les caractristiques structurelles et comportementales de certains
lments du modle UML. Les classes, les interfaces, les associations, les cas dutilisation, les
collaborations, les acteurs, les types primitifs, les composants, les signaux sont des spcialisations possibles de classeurs.
Le diagramme de classes prsente un ensemble de classeurs. Il dcrit les classes et leurs
relations, comme le montre lexemple suivant. Il peut galement dcrire les regroupements
de classes en paquetages, les interfaces et les objets, les classes qui participent une collaboration ou qui ralisent un cas dutilisation, etc.
EXEMPLE
La figure 2.1 modlise une entreprise laide de cinq classes : Entreprise, Ser vice, Bureau,
Employ et Sige. Les classes possdent ventuellement des attributs (la classe Ser vice est
caractrise par un nom, un employ se caractrise par un nom et un identifiant). Elles
contiennent aussi des oprations (demandeCongs pour la classe Employ). Les classes sont
relies entre elles par des associations symbolises par des traits. Plusieurs types dassociations existent, qui se reprsentent diffremment (par des losanges, des flches).
Figure 2.1
Exemple de
diagramme
de classes.
Entreprise
Une agrgation
1..*
utilise
Bureau
nom : String
Une contrainte
entre relations
{subset}
1..* membre
Opration
1..*
1..*
Service
1 chef
Sige
Employ
nom : String
identifiant : Number
demandeCongs() :bool
Pour crer un diagramme de classes, vous avez besoin dabord de dfinir les classes et leurs
responsabilits, les paquetages ainsi que les relations (association, composition, agrgation,
hritage, dpendance) possibles entre ces lments. Dautres lments peuvent galement
apparatre dans le diagramme de classes, comme les objets et les interfaces.
Nous prsenterons, dans ce chapitre, les lments indispensables pour bien russir la modlisation du diagramme de classes. Commenons par dcrire la gense des classes.
(2)
De lobjet la classe
Beaucoup dobjets naturels ou informatiques se ressemblent tant au niveau de leur description que de leur comportement. Afin de limiter la complexit de la modlisation, vous pouvez regrouper les objets ayant les mmes caractristiques en classes. Ainsi, une classe dcrit
les tats (ou attributs) et le comportement haut niveau dabstraction dobjets similaires.
De cette faon, vous pouvez dfinir la classe comme le regroupement des donnes et des
traitements applicables aux objets quelle reprsente, comme le montre la figure 2.2. Dans
36
UML 2
Chapitre
lapproche objet, il faut, avant tout, pouvoir identifier les objets, les diffrencier des autres
avant de les dfinir. Lidentit associe une classe est essentielle car elle conditionne la perception des structures et des comportements des objets quelle reprsente.
EXEMPLE
La figure 2.2 modlise la situation suivante : Jean est un homme clibataire g de 40 ans et
Anne est une femme marie.
Figure 2.2
Reprsentation UML
de la classe
Personne.
Personne
prnom : String
dateNaissance : Date
sexe : {M,F}
calculAge() : Integer
renvoyerNom() : String
Le nom de la classe doit tre significatif et

complet. Il commence par une majuscule. Sil est
compos de plusieurs mots, la premire lettre de
chaque mot doit tre une majuscule. Personne
Liste des attributs de la classe avec les
modificateurs daccs ventuels. Certains attributs
napparaissent pas directement, ils seront dduits
partir des relations entre classes.
Liste des mthodes de la classe. Quand la
mthode accepte des paramtres alors ces
paramtres et leurs types sont ajouts entre les
parenthses.
Dans cet exemple, on regroupe les similarits entre les deux objets Jean et Anne dans une
classe Personne. Les informations qui apparaissent dans lexemple sont le prnom, le sexe et
la situation matrimoniale. De ce fait, la classe Personne est munie des attributs suivants :
prnom, sexe et situation matrimoniale. Lge est une donne qui change. On le calcule en
faisant la diffrence entre la date courante et la date de naissance. On parle dans ce cas
dattributs drivs. Cette dernire analyse permet de complter la description de la classe en
ajoutant lattribut date de naissance et une opration permettant le calcul de lge.
En UML, la classe Personne est reprsente graphiquement par un rectangle divis en plusieurs
compartiments. Le premier compartiment indique le nom de la classe, le deuxime ses attributs, le troisime ses mthodes. En fonction de ltat de la modlisation et des lments
mettre en valeur, dautres compartiments, comme les compartiments de responsabilits et
dexceptions, peuvent tre ajouts la description de la classe.
Dfinition
Une classe est une description dun ensemble dobjets ayant une smantique, des attributs,
des mthodes et des relations en commun. Un objet est une instance dune classe.
Remarque
Dans les langages de programmation objet, on confond souvent la notion dinstance et la
notion dobjet alors que la premire est plus gnrale que la seconde. Un objet est une instance dune classe. Mais une instance peut tre une instance de plusieurs autres lments
du langage UML. Par exemple, un lien est une instance dune association.
Un objet dune classe doit avoir des valeurs uniques pour tous les attributs dfinis dans la
classe et doit pouvoir excuter (sans exception) toutes les mthodes de la classe.
Diagramme de classes 37
2.1 CLASSE
ET MTHODE ABSTRAITES
Dans votre environnement quotidien, vous faites abstraction dune quantit de dtails qui
permettent davoir une vision globale et gnralisante du monde. Cette notion dabstraction se retrouve, au sein de lapproche objet, dans les classes et les mthodes abstraites.
Imaginez une classe modlisant une figure gomtrique. Toutes les figures gomtriques
doivent pouvoir tre dessines. Ajoutez cette classe une opration qui permet de dessiner
une figure. ce stade de la modlisation, vous tes dans lincapacit de dfinir limplmentation de cette opration. On lappelle mthode abstraite .
Dfinition
Une mthode est dite abstraite lorsquon connat son entte mais pas la manire dont elle
peut tre ralise. Une classe est dite abstraite lorsquelle dfinit au moins une mthode
abstraite ou lorsquune classe parent contient une mthode abstraite non encore ralise.
EXEMPLE
Chaque lment graphique du langage UML est reprsent par une figure gomtrique.
Les caractristiques communes de ces figures gomtriques sont le type de trait utilis pour les
dessiner et la possibilit de les dessiner.
Il est vident que si nous ne connaissons pas la forme exacte de la figure dessiner nous ne
pouvons pas le faire. On dira de ce fait que la mthode dessiner est abstraite dans la classe
FigureGomtrique et la classe FigureGomtrique est donc elle-mme abstraite. Cependant,
si on dfinit un rectangle comme particularisation de la figure gomtrique alors le rectangle pourra tre dessin et la mthode dessiner fournit ainsi un corps lopration dessiner
qui sera dite concrte. Une classe abstraite contient au moins une mthode abstraite. La
figure 2.3 donne un exemple dune classe abstraite contenant une mthode abstraite et les
consquences de cette proprit sur les classes drives. En particulier, une classe qui drive
dune classe abstraite doit implmenter toutes les mthodes abstraites sinon elle reste aussi
abstraite.
Figure 2.3
Exemple de classe
abstraite.
2.2 NOM
FigureGomtrique{abstract}
Rectangle
typeTrait : Trait
dessiner()
dessiner() {abstract}
FigurePleine{abstract}
Implmentation de
lopration dessiner
Cette classe reste abstraite

car elle nimplmente pas
la mthode dessiner
DE LA CLASSE
La modlisation dune classe passe par plusieurs tapes auxquelles participent ventuellement plusieurs intervenants. Par exemple, une classe peut tre extraite des cas dutilisation
par un analyste programmeur, et aprs analyse et factorisation opres par un ingnieur de
dveloppement, tre mise dans un paquetage prdfini et considre comme valide. Pour
distinguer ces tapes de modlisation, vous devez ajouter au nom de la classe toutes les
informations pertinentes.
38
UML 2
Chapitre
Les informations les plus souvent utilises sont le nom de la classe, les paquetages qui la
contiennent, le strotype ventuel de la classe, lauteur de la modlisation, la date, le statut
de la classe (elle est valide ou pas). Par dfaut, une classe est considre comme concrte.
Sinon, ajoutez le mot-cl abstract pour indiquer quelle est abstraite.
Spcification
La syntaxe de base de la dclaration dun nom dune classe est la suivante :
[strotype]
[<NomDuPackage1>:::<NomDuPaquetage N>::]
<NomDeLaClasse>[{[abstract],[auteur],[tat],}]
Figure 2.4
NomSimple
Quelques exemples
de noms de classe.
Personne
nomPackage::NomSimple
java::util::Vector
FigureGomtrique
{abstract,
auteur : osmani
tat : valide}
Controleur
LeGardien
Remarque
Le nom de la classe doit voquer le concept dcrit par la classe. Il commence par une
majuscule. Quand le nom est compos, chaque mot commence par une majuscule et les
espaces blancs sont limins.
En UML 2, les guillemets (comme dans lexemple de contrleur ser vent, la fois, indiquer les strotypes et les mots-cls du langage. Dans les versions prcdentes dUML, ils
ne servent qu dsigner les strotypes.
2.3 ENCAPSULATION
Un principe de conception largement utilis (mme au-del de lapproche objet) consiste
protger le cur dun systme des accs intempestifs venant de lextrieur. Cest le principe
du coffre-fort : seuls les dtenteurs dune clef peuvent louvrir. Transpos la modlisation
objet, ce principe sappelle lencapsulation. Il permet de dfinir les droits daccs aux
proprits dun classeur. UML dfinit quatre niveaux dencapsulation dune proprit dune
classe.
Une proprit peut tre visible partout. Dans ce cas, elle est dite publique . Si elle nest
visible qu lintrieur dune classe, elle est dite prive . En utilisant le principe de
lhritage, les descendants dune classe peuvent avoir un accs privilgi aux proprits des
classes parentes. Une classe parent qui souhaite autoriser laccs une de ses proprits
ses seuls descendants doit dfinir cette proprit comme protge . Lors de la modlisation dapplications complexes, les classes sont regroupes dans des paquetages ddis des
domaines ou activits particulires. Le langage Java, par exemple, propose un paquetage
ddi aux entres/sorties (java.io), un paquetage contenant les utilitaires (java.util), etc. La
visibilit par dfaut dune classe et de ses proprits se limite au paquetage dans lequel elle
est dfinie.
Notation
Les modificateurs daccs ou de visibilit associs aux classes ou leurs proprits sont nots
comme suit :
Le mot-cl public ou le caractre +. Proprit ou classe visible partout.
Aucun caractre, ni mot-cl. Proprit ou classe visible uniquement dans le paquetage
o la classe est dfinie.
Le mot-cl protected ou le caractre #. Proprit ou classe visible dans la classe et par
tous ses descendants.
Le mot-cl private ou le caractre -. Proprit ou classe visible uniquement dans la classe.
Par ailleurs, le langage UML 2 donne la possibilit dutiliser nimpor te quel langage de
programmation pour la spcification de la visibilit des classeurs et de leurs proprits. Il
suffit pour cela de prciser le langage utilis.
Le paquetage Paquetage1 utilise le paquetage Paquetage2. La classe Classe1 dfinit quatre

attributs avec des visibilits diffrentes (figure 2.5). Lattribut priv attribut1 nest accessible
que dans la classe Classe1. Lattribut attribut2 est public dans le paquetage, accessible
partir des classes Classe1, Classe2 et Classe3. Lattribut attribut3 est accessible partir des
quatre classes alors que lattribut attribut4 nest visible que dans les classes Classe1 et
Classe2.
Figure 2.5
Paquetage1
Visibilit
des proprits
dune classe.
+ Classe1
-attribut1
attribut2
+attribut3
#attribut4
+ Classe3
accessibles
attribut2
Paquetage2
+ Classe2
accessibles
attribut2
attribut3
import
+ Classe4
accessibles
attribut3
attribut4
attribut3
2.4 ATTRIBUTS
DE LA CLASSE
Les attributs dfinissent les informations quune classe ou un objet doivent connatre. Ils
reprsentent les donnes encapsules dans les objets de cette classe. Chacune de ces informations est dfinie par un nom, un type de donnes et une visibilit. Le nom de lattribut
doit tre unique dans la classe.
En UML, les attributs correspondent des instances de classes dj prdfinies. Pour des
raisons de programmation, ce principe nest pas toujours respect par les langages de programmation objet, comme en tmoigne lexistence de types de base (int, float,) dans les
langages Java et C++.
EXEMPLE
40
UML 2
La classe Htel possde un nom et un propritaire. Un htel contient entre une et deux cents
chambres. Le propritaire de lhtel nest pas visible partir des autres classes. Par ailleurs,
lhtel respecte les textes de lois communs tous les htels.
Chapitre
Pour pouvoir modliser la classe Htel, vous avez besoin de connatre les classes String,
Chambre, Personne et TexteDeLoi. Vous avez galement besoin de savoir modliser la multiplicit (entre une et deux cents chambres) et la possibilit dassocier une proprit la
classe, et non linstance de la classe (texte de loi).
Figure 2.6
Classe Htel
mettant en vidence
les modificateurs
daccs, la multiplicit et les attributs
de classes.
Htel
+ chambres : Chambre[1..200]
+ nom : String
-propritaire : Personne
+ texte : TexteDeLoi
Description des attributs en mettant en vidence la

visibilit et la multiplicit. Dans le cas ou la multiplicit est
reprsente par plusieurs intervalles, ils sont ordonns par
ordre croissant. Quand les intervalles sont continus,ils
doivent tre regroups.
Exemple : [5..6] doit tre prfr "5,6 ".
Le texte de loi qui rgit la profession nest pas propre
un htel. Elle existe en un seul exemplaire, partage par
toutes les instances dhtel. Il sagit dun attribut de classe
(soulign).
Notation
Un attribut peut tre initialis et sa visibilit est dfinie lors de sa dclaration. La syntaxe de
la dclaration dun attribut est la suivante :
<modificateur daccs> [/]<NomAttribut>:
<NomClasse>[[multiplicit]] [ = valeur(s) initiale(s)]
Les attributs de classes

Par dfaut, les valeurs des attributs dfinis dans une classe diffrent dun objet un autre.
Parfois, il est ncessaire de dfinir un attribut qui garde une valeur unique et partage par
toutes les instances de la classe. Cest par exemple le cas de la valeur de la variable PI=3,14
dfinie dans la classe Math du langage Java. Quel que soit lobjet de cette classe, la valeur de
PI reste la mme. De plus, cette valeur est accessible mme sil nexiste aucun objet de la
classe Math. On dit alors que PI est un attribut de la classe Math, et non un attribut de ses
instances. Les instances ont accs cet attribut, mais nen possdent pas une copie.
Graphiquement, un attribut de classe est soulign, comme le montre lexemple de TexteDeLoi de la figure 2.6. En Java, comme en C++, par exemple, un attribut de classe saccompagne du mot-cl static.
Les attributs drivs

Les attributs drivs, symboliss par lajout dun slash (/) devant leur nom, peuvent tre
calculs partir dautres attributs et des formules de calcul. Lors de la conception, un attribut driv peut tre utilis comme marqueur jusqu ce que vous puissiez dterminer les
rgles lui appliquer.
EXEMPLE
La plupart des calculs concernant la pension de retraite sont bass sur lge. Lge est vu
comme un attribut. Pourtant, lors de la modlisation de la classe Personne, cest la date de
naissance qui est dterminante, et non lge, car celui-ci change en fonction de la date du
jour. De ce fait, on dit que lattribut ge est un attribut driv : il est utilis comme un vrai
attribut mais calcul par une mthode. Il est not /age : integer.
2.5 MTHODES
ET OPRATIONS
Le comportement dun objet est modlis par un ensemble de mthodes. Chaque mthode
correspond une implmentation bien prcise dun comportement.
En gnral, lors de la conception des classes, on commence par donner les en-ttes des
mthodes sans prciser la manire de les implmenter. Cependant, avant toute instanciation
dune classe, il est ncessaire de donner une implmentation possible de ses mthodes. videmment, pour chaque en-tte, plusieurs implmentations sont possibles.
UML distingue la spcification dune mthode, qui correspond la dfinition de son entte, de son implmentation. La spcification est appele opration et limplmentation
est appele mthode . Vous pouvez donc associer plusieurs mthodes une opration,
comme le montre lexemple suivant :
EXEMPLE
Soit la factorielle de n (n!), une fonction dfinie de faon inductive pour tout entier positif n
par : 0! = 1 et n! = n * (n 1)!. On dit que : + fact (n : integer) : integer est une opration et
que
+fact(n:integer):integer
{
if (n==0 || n==1) renvoyer (1);
renvoyer (n * fact(n-1); *= i;
}
et
+fact(n:integer):integer
{
int resultat = 1;
pour (int i = n; i>0; i--) resultat*=i;
renvoyer resultat;
}
sont deux mthodes possibles implmentant lopration fact().
Dans une classe, une opration (mme nom et mmes types de paramtres) doit tre unique. Quand le nom dune opration apparat plusieurs fois avec des paramtres diffrents,
on dit que lopration (et/ou la mthode) est surcharge. En revanche, il est impossible que
deux oprations ne se distinguent que par la valeur retourne.
Spcification
La spcification dune opration contient les types des paramtres et le type de la valeur
de retour. UML 2 ne prvoit pas de type de la valeur de retour dune opration. Mais lutilit de ce paramtre nous conduit garder la syntaxe dUML 1.5.
La syntaxe de la dclaration est la suivante :
<modificateur daccs><nomDeLaMthode ([paramtres])>:
[<valeurRenvoye>][{proprit}]
La syntaxe de la liste des paramtres est la suivante :

<NomClasse> nomVariable, <NomClasse> nomVariable, <NomClasse>
nomVariable,
Les proprits correspondent des contraintes ou des informations complmentaires,

comme les exceptions, les pr-conditions, les post-conditions, ou encore lindication quune
classe est abstraite, etc.
UML 2 autorise galement la dfinition des oprations dans nimporte quel langage
condition que celui-ci soit prcis a priori. Vous pouvez, par exemple, utiliser la syntaxe du
langage C++ ou du langage Java pour exprimer toutes les mthodes des classes.
42
UML 2
Chapitre
2.6 OPRATIONS
DE CLASSE
Comme pour les attributs de classe, vous aurez peut-tre besoin de dfinir une opration
qui ne dpend pas des valeurs propres de chaque objet, mais qui porte sur les attributs de la
classe ou uniquement sur les paramtres de lopration. Dans ce cas, lopration devient
proprit de la classe, et non de ses instances. Elle na pas accs aux attributs des objets de la
classe. Graphiquement, une mthode de classe est souligne.
EXEMPLE
Lexcution dune application cre plusieurs objets de la classe Processus. Pour affi cher le
nombre dobjets de cette classe disponible simultanment dans le systme, vous pouvez ajouter un attribut de classe qui compte le nombre de processus (lors de la cration et de la destruction des objets) et une mthode qui affiche ce nombre.
Figure 2.7
Opration de classe
et strotype
dopration.
Processus
+ nom : String
- nombreProc : integer
constructeurs
+ afficheNombreProc() : void
Le nombreProc est un attribut de classe priv.

Contrairement au nom qui est associ chaque
processus, le nombreProc nest disponible quen
un seul exemplaire. Il est associ la classe.
Les indiquent que tous les attributs ne sont
pas reprsents.
Le strotype type de mthodes est utilis pour
simplifier la notation ou lorsque les oprations ou
leurs signatures ne sont pas encore connues,
La mthode affiche() est une mthode de classe.
Elle est publique et ne renvoie aucune valeur.
2.7 COMPARTIMENTS
COMPLMENTAIRES DUNE CLASSE
Le processus de modlisation se fait pas pas. De ce fait, lors de la construction des classes,
les caractristiques ne sont pas toutes connues de faon prcise. Pour prendre en compte
cette construction incrmentale, vous ajoutez des informations complmentaires aux classes telles que les responsabilits, les contraintes gnrales, les exceptions, etc.
Pour ce faire, vous disposez de deux nouveaux compartiments dans la description graphique dune classe, savoir le compartiment des responsabilits et celui des exceptions. Si la
modlisation concerne une application informatique implmenter, ces deux compartiments disparatront quand vous arriverez la phase de gnration de code ; ils seront
transforms en un ensemble dattributs et de mthodes.
EXEMPLE
La classe ConnexionInformatique doit respecter une charte dfinissant les modalits de

connexion. Dans un premier temps, cette charte nest ni une mthode, ni un attribut : il sagit
dune responsabilit de la classe. Dans la description de cette classe, comme le montre la
figure 2.8, il faut aussi grer le cas o la connexion est impossible.
Figure 2.8
Compartiment
de responsabilit
et dexception.
Connexion
+ip : Byte [4]
Respecter la charte
Possder une adresse IP
+ seConnecter( )
exceptions
Connexion impossible
(3)
Compartiment des responsabilits

numrant lensemble des tches devant
tre assures par la classe.
numre les situations exceptionnelles et

les anomalies devant tre gres par la classe.
Interface
Le rle dune interface est de regrouper un ensemble doprations assurant un service cohrent offert par un classeur et une classe en particulier.
Le concept dinterface est essentiellement utilis pour classer les oprations en catgories
sans prciser la manire dont elles sont implmentes. La dfinition dune interface ne spcifie pas contrairement celle dune classe une structure interne et ne prcise pas les
algorithmes permettant la ralisation de ses mthodes. Elle peut prciser les conditions et
les effets de son invocation. Une interface na pas dinstances directes. Pour tre utilise,
elle doit tre ralise par un classeur, qui est souvent une classe. Une interface peut tre spcialise et/ou gnralise par dautres interfaces.
La ralisation dune interface par une classe est reprsente graphiquement par un trait discontinu qui se termine par une pointe triangulaire. Une manire simplifie de reprsenter
une interface consiste placer un petit cercle, souvent appel lollipop (sucette), rattach
la classe qui ralise linterface, comme le montre la figure 2.9.
Spcification
Une interface est dfinie comme une classe, avec les mmes compartiments. Les principales
diffrences sont la non-utilisation du mot-cl abstract, car linterface et toutes ses mthodes
sont, par dfinition, abstraites, et lajout du strotype interface avant le nom de linterface.
Figure 2.9
Deux manires de
reprsenter linterface
et le lien avec la classe
qui la ralise. Linterface
NomInterface est
ralise par la classe
NomClasse.
EXEMPLE
44
UML 2
interface
NomInterface
NomClasse
NomInterface
NomClasse
Selon des critres dfinir a posteriori, les objets de la classe Htel et les objets de la classe
Personne doivent tre comparables. Lopration qui compose linterface et permet la comparaison entre les instances des classes Personne et Htel doit tre la mme. Cependant, les
critres de comparaison sont, videmment, diffrents. La figure 2.10 modlise cette interface
commune, ralise par chacune des classes drives.
Chapitre
Figure 2.10
Les classes Htel
et Personne ralisent
linterface Comparable.
realize
Htel
Personne
interface
Comparable
CompareTo() : Integer
Htel
Comparable
realize
Personne
Comparable
Quand une classe dpend dune interface (interface requise) pour raliser ses oprations,
elle est dite classe cliente de linterface . Graphiquement, cela est reprsent par une relation de dpendance entre la classe et linterface. Une notation lollipop quivalente est aussi
possible, comme le montre la figure 2.11.
Figure 2.11
La classe NomClasse
dpend de linterface
NomInterface.
interface
NomInterface
NomClasse
NomInterface
use
NomClasse
(4)
Relations entre classes

Les classes sont les lments de base du diagramme de classes. Une application ncessite
videmment la modlisation de plusieurs classes. Aprs avoir trouv les classes, il convient
de les relier entre elles. Les relations entre classes expriment les liens smantiques ou structurels. Les relations les plus utilises sont lassociation, lagrgation, la composition, la
dpendance et lhritage. Dans la plupart des cas, ces relations sont binaires (elles relient
deux classes uniquement).
Mme si les relations sont dcrites dans le diagramme de classes, elles expriment souvent les
liens entre les objets. De ce fait, mme les relations binaires entre classes peuvent faire intervenir plusieurs objets de chaque classe. La notion de multiplicit permet le contrle du
nombre dobjets intervenant dans chaque instance de la relation.
4.1 MULTIPLICIT
Dans le mtamodle UML, la multiplicit est dfinie par un ensemble non vide dentiers
positifs lexclusion dun ensemble ne contenant que zro {0}. Elle apparat chaque extrmit dune relation et indique le nombre dobjets de la classe apparaissant cette extrmit
pouvant sassocier un seul et unique objet de la classe apparaissant lautre extrmit.
EXEMPLE
Figure 2.12
Exemple de
multiplicit.
Un objet de la classe Voiture est compos dau moins trois roues et dau plus dix roues. Pour
ajouter cette information dans le diagramme de classes, on ajoutera le lien de composition
entre les classes Voiture et Roue et on ajoutera la multiplicit [3..10] du ct de la classe
Roue.
Voiture
3..10
Roue
Cette relation entre deux classes indique quun objet de la classe Voiture doit tre compos
de trois dix objets de la classe Roue.
Les principales multiplicits normalises sont plusieurs (*), exactement n (n), au
minimum n (n..*) et entre n et m (n..m). Il est aussi possible davoir un ensemble
dintervalles convexes: n1..n2, n3..n4 ou n1..n2, n5, n6..*, etc.
4.2 ASSOCIATION
Une association reprsente une relation smantique entre les objets dune classe. Elle est
reprsente graphiquement par un trait plein entre les classes associes. Elle est complte
par un nom qui correspond souvent un verbe linfinitif, avec une prcision du sens de
lecture en cas dambigut. Parfois, un strotype qui caractrise au mieux lassociation
remplace le nom. Chaque extrmit de lassociation indique le rle de la classe dans la
relation et prcise le nombre dobjets de la classe qui interviennent dans lassociation.
Quand linformation circule dans un sens uniquement, le sens de la navigation est indiqu
lune des extrmits. UML 2 donne, aussi, la possibilit dexprimer la non-navigabilit
dune extrmit par lajout dune croix sur lassociation, comme le montre la figure 2.15.
Figure 2.13
Lassociation
et ses diffrents
ornements.
EXEMPLE
multiplicit
nom
multiplicit
rle
rle
Indique le sens de lecture du

nom ou du strotype. Dans le cas
dun strotype, ce dernier est mis
entre guillemets.
Association
Une personne travaille pour une et une seule entreprise. Lentreprise emploie au moins une
personne. Lentreprise est lemployeur des personnes qui travaillent pour elle et une personne
a un statut demploy dans lentreprise.
Figure 2.14
Personne
Rle, multiplicit et
nom de lassociation
sans restriction de
navigabilit.
EXEMPLE
1..*
travailler pour
employ
Entreprise
employeur
Association avec navigabilit et contraintes

Un polygone est dfini par un ensemble de points jouant le rle de sommets. Les sommets du
polygone ne sont accessibles que par la classe et par ses descendants. Par ailleurs, il est inutile et encombrant que les points aient un lien vers le polygone et, de manire gnrale, vers
les figures auxquelles ils appartiennent.
Figure 2.15
Association oriente.
Polygone
dfini par
3..*
#sommet
Point
La navigation est possible uniquement du polygone vers les points.

Vous pouvez modliser lassociation entre les classes Polygone et Point et mettre en vidence
la navigabilit de lassociation en ajoutant un attribut sommet dans Polygone (figure 2.16).
46
UML 2
Chapitre
Cependant, la classe Point ne doit pas avoir dattribut de type Polygone, ni de mthode qui
renvoie les polygones dfinis par ce point.
Figure 2.16
Polygone
Exemple de
modlisation
de la navigation
par des attributs.
#sommets : Point[3..*]
Lassociation la plus utilise est lassociation binaire (reliant deux classeurs). Parfois, les
deux extrmits de lassociation pointent vers le mme classeur. Dans ce cas, lassociation
est dite rflexive .
Figure 2.17
a le mme age
Exemples
dassociations
rflexives.
+parent
2
Personne
+enfant
*
*
amie de
La premire est asymtrique (parent de), la deuxime est symtrique et non transitive (amie
de) et la dernire est la fois symtrique et transitive. Il est conseill dajouter les rles des
extrmits dans le cas des relations asymtriques.
Lassociation rflexive entre classes a pour principale fonction de structurer les objets dune
mme classe. Quand lassociation est asymtrique, elle permet de crer une hirarchie entre
les objets sinon elle partitionne les instances de la mme classe. Quand lassociation est la
fois symtrique et transitive, les objets sont regroups en classes dquivalence. Dans lexemple de la figure 2.17, lassociation rflexive parent de permet de crer un arbre (hirarchie) gnalogique entre les instances de la classe Personne. La relation symtrique et
transitive a le mme ge permet de regrouper les objets de la classe Personne en classes
dquivalence (toutes les personnes ayant le mme ge appartiendront au mme groupe).
Remarque
De nombreux concepts sont dfinis autour de la notion dassociation. Nous avons slectionn
cinq concepts qui nous paraissent importants : lassociation avec contraintes, lassociation
drive, la classe-association, la classe reprsentante (ou qualifiante) et lassociation n-aire
(n > 2).
4.3 ASSOCIATION
AVEC CONTRAINTES
Une association entre classes indique que des proprits sont changes ou partages par les
classes relies. Lajout de contraintes une association ou bien entre associations apporte
plus dinformations car cela permet de mieux prciser la porte et le sens de lassociation.
Les contraintes sont mises entre accolades et peuvent tre exprimes dans nimporte quel
langage. Cependant, il est prfrable dutiliser le langage OCL (Object Constraint Language).
Le premier exemple de la figure 2.18 montre une association entre un polygone et ses sommets en prcisant que les sommets dun polygone sont ordonns, ce qui permet de rduire
1 le nombre de figures pouvant tre dessines partir de n sommets. Le deuxime exemple
montre une contrainte entre deux associations : elle indique que le responsable du dpartement fait ncessairement partie du personnel.
Figure 2.18
Polygone
Exemples
dassociations
dont la porte
est restreinte par
les contraintes
du langage OCL.
dfini par
3..*
Point
#sommet
{ordered}
1
Dpartement
emploie
Personne
{subset}
1
4.4 ASSOCIATION
lment du langage OCL qui

indique que les sommets, dans un
polygone, sont ordonns.
est responsable
DRIVE
Une association drive est conditionne ou peut tre dduite partir dune autre association. Souvent un ensemble de contraintes, exprimes en OCL, est ajout une association
drive pour dfinir les conditions de drivation. Graphiquement, une association drive
est symbolise par lajout dun slash avant le nom de lassociation. Dans lexemple de la
figure 2.19, lassociation drive /emploi indique que la personne qui travaille pour une
entreprise est la mme que celle qui est associe lun de ses dpartements.
Figure 2.19
Association drive
dfinie par une
contrainte du
langage OCL.
1
Entreprise
/emploie
n..*
{Context : Personne
self.departement.entreprise
= self.entreprise}
Dpartement
Personne
Cette contrainte suppose que la classe

Personne contienne un attribut de la classe
Dpartement et que la classe Dpartement
contienne un attribut de la classe Entreprise
4.5 CLASSE-ASSOCIATION
Une association peut tre raffine et avoir ses propres proprits, qui ne sont disponibles
dans aucune des classes quelle lie. Comme, dans le modle objet, seules les classes peuvent
avoir des proprits, cette association devient alors une classe appele classe-association .
partir du moment o elle est dfinie, elle est considre comme toutes les autres classes du
modle.
EXEMPLE
Figure 2.20
Une classeassociation est
caractrise par
lajout dun trait
discontinu entre
la classe et
lassociation
quelle reprsente.
48
UML 2
Les personnes qui travaillent dans une entreprise occupent un poste. Parmi les proprits associes au poste figure le salaire. Par ailleurs, quand une personne occupe un poste dans une
entreprise, elle peut tre responsable de plusieurs personnes.
Personne
Entreprise
employ
Association
rflexive oriente
employeur
Poste
salaire : Salaire
*
responsable
Classe association
Chapitre
4.6 ASSOCIATION
QUALIFIE
Parfois, lassociation entre deux classes donne peu dindications sur limplication effective
des classes dans la relation, ce qui rend la modlisation imprcise. Cette imprcision concerne,
en particulier, la multiplicit dune extrmit de lassociation et/ou la porte de lassociation
par rapport aux classes associes.
La qualification dune association permet, dans certains cas, de transformer une multiplicit indtermine ou infinie en une multiplicit finie, comme le montre la figure 2.21.
EXEMPLE
Changement de multiplicit avec un qualificateur

La classe Vector du langage Java permet de rfrencer un ensemble quelconque dobjets de
la classe Object. On suppose quun objet est rfrenc une seule fois. La figure 2.21 donne
une modlisation de cette situation avec et sans qualificateur. Un objet de la classe Object est
rfrenc par un indice de type integer.
Figure 2.21
Vector
Intrt de la
qualification dune
classe pour prciser
la multiplicit.
EXEMPLE
Vector
Object
indice:integer
Object
Qualification dune association pour limiter son impact sur les classes associes
Lobjectif est de modliser lassociation entre une personne et une banque. Lunique lien entre
les deux est le fait de possder au plus deux comptes. La banque assure bien dautres activits qui ne concernent pas le client. Pour mettre en vidence le fait que le lien entre la banque
et une personne se limite la possession de plusieurs comptes, on ajoute une classe Compte
qui reprsente la classe Banque dans lassociation avec la classe Personne.
Figure 2.22
Banque
Une classe qualifiante

est colle la classe
principale.
#Compte
0..2
possder
*
client
Personne
4.7 ASSOCIATION N-AIRE

Une association n-aire lie plus de deux classes. La gestion de ce type dassociation est trs
dlicate, notamment quand on ajoute la multiplicit (voir exercice 5). Pour cette raison,
elles sont trs peu utilises. On leur prfre des associations binaires combines avec des
contraintes du langage OCL.
Notation
Les traits pleins qui viennent de toutes les classes associes convergent vers un losange central pouvant ventuellement accueillir une classe-association. La multiplicit apparaissant
sur le lien de chaque classe sapplique sur une instance du losange. Une instance du
losange par rapport une classe est un ensemble contenant une seule et unique instance
de chacune des classes, lexclusion de la classe-association et de la classe considre.
EXEMPLE
Chaque anne, les tudiants sinscrivent dans un seul groupe et suivent des modules. Pour un
groupe dtudiants donn (ne dpassant pas vingt-cinq individus), un module est assur
par un seul enseignant. Un module nouvre que si au moins quatre tudiants sont inscrits. Par
ailleurs, la politique de lcole fait quun enseignant ne peut pas assurer plus de trois modules
pour un tudiant donn et un tudiant suit entre cinq et dix modules.
Figure 2.23
tudiant
Relation entre trois

classes (relation
ternaire).
4..25
1..3
Enseignant
4..*
*
5..10
Module
4.8 RELATION DAGRGATION

Une agrgation est une forme particulire dassociation. Elle reprsente la relation dinclusion structurelle ou comportementale dun lment dans un ensemble. Contrairement
lassociation, lagrgation est une relation transitive.
Notation
Une agrgation se distingue dune association par lajout dun losange vide du ct de
lagrgat.
EXEMPLE
Une cole dispose dau moins une salle de cours. Dans chaque salle, on trouve des chaises et
un vido-projecteur fix au plafond.
Figure 2.24
cole
Relation
dagrgation.
2..*
Salle
Chaise
1
1
Projecteur
Lagrgation permet galement la dlgation dopration : une opration dfinie comme

pouvant tre ralise par une classe est en ralit ralise par ses parties. Par exemple, on
ralisera lopration de nettoyage dune cole en dlguant cette tche toutes ses salles. La
dure de vie de lagrgat est indpendante des lments qui le constituent. La destruction
dune instance de la classe Salle nimplique pas la destruction des instances de la classe
String. Par ailleurs, un composant peut apparatre dans plusieurs agrgats (pas de restriction sur la multiplicit du ct de lagrgat). Une instance de la classe Projecteur peut tre
partage par plusieurs salles.
4.9 RELATION
DE COMPOSITION
La composition, appele galement agrgation composite , est une agrgation particulire.

Cela signifie que toute composition peut tre remplace par une agrgation, qui elle-mme
peut tre remplace par une association. La seule consquence est la perte dinformations.
La relation de composition dcrit une contenance structurelle entre instances. Ceci implique, en particulier, que llment composite est responsable de la cration, de la copie et de
50
UML 2
Chapitre
la destruction de ses composants. Par ailleurs, la destruction ou la copie de lobjet composite implique respectivement la destruction ou la copie de ses composants. Une instance de
la partie appartient toujours au plus une instance de llment composite.
Notation
Une composition se distingue dune association par lajout dun losange plein du ct de
lagrgat. La multiplicit du ct de lagrgat ne peut prendre que deux valeurs : 0 ou 1.
Par dfaut, la multiplicit vaut 1.
Comme tous les autres lments du langage UML, la composition ne reflte pas forcment la
ralit. Cependant, elle doit tre fidle la situation modlise, comme le montre ce qui suit.
EXEMPLE
On peut complter lexemple prcdent en indiquant quune salle est compose dune seule
porte et de plusieurs fentres. De plus, si le tableau est fix, on considre que la relation de
composition reflte mieux le lien qui le lie la salle.
Figure 2.25
cole
2..*
Salle
Exemple de relation
de composition.
0..1
*
Projecteur
Chaise
Porte
*
Fentre
Remarque
La relation de composition tant structurelle, le langage UML autorise la reprsentation suivante :
Figure 2.26
Salle
Reprsentation imbrique
de la composition. Une salle
est compose dune porte
et de plusieurs fentres.
4.10 RELATION
Porte 1
Fentre *
mp
DE DPENDANCE
Une dpendance est une relation unidirectionnelle exprimant une dpendance smantique
entre les lments du modle. Elle est reprsente par un trait discontinu orient. Elle indique que la modification de la cible implique le changement de la source. La dpendance est
souvent strotype pour mieux expliciter le lien smantique entre les lments du modle.
Les strotypes normaliss sont, entre autres, friend (on accorde une visibilit spciale
la classe source dans la cible), drive (la source est calcule partir de la cible), appel
(appel dune opration par une autre), instantiate (une opration de la source cre une
instance de la cible), send (une opration envoie un signal vers un lment cible),
trace (la cible est une version prcdente de la source), refine , copie et create .
EXEMPLE
Le droulement des cours dpend des cours.
Figure 2.27
Relation de dpendance.
EmploiDuTemps
Cours
4.11 RELATION DHRITAGE

Un des intrts de la modlisation objet est la possibilit de manipuler des concepts abstraits. Cette notion est trs importante car elle permet de simplifier la reprsentation. Elle
est, par ailleurs, proche de la faon dont on modlise le monde : continuellement, sans
mme sen rendre compte, on fait abstraction de certaines choses : par exemple, quand on
parle dun vhicule, cest une vue de lesprit ; dans la ralit, il sagit de voitures, de camions,
etc. Les camions se distinguent par des marques, des tailles diffrentes, etc. Ces diffrents
niveaux dabstraction permettent, entre autres, de simplifier le langage et de factoriser les
proprits.
Ce principe dabstraction est assur par le concept de lhritage. Ce concept permet tout
simplement de partitionner rcursivement les objets en ensembles densembles. Quand les
partitions sont grossires, on les raffine (spcialisation) et quand elles sont trs fines, on
les gnralise. Chaque partition est modlise par une classe.
Ce processus de gnralisation et de spcialisation est souvent guid par le sens smantique
donn chaque partition dobjets et la granularit de la modlisation.
En UML, la relation dhritage nest pas propre aux classes. Elle sapplique dautres lments
du langage UML, comme les paquetages ou les cas dutilisation.
EXEMPLE
Les animaux sont des tres vivants qui ont tous une dure de vie limite. Ltre humain est un
animal dont la dure de vie ne dpasse pas cent cinquante ans.
Dans cet exemple, lensemble des objets considrs est celui de la classe Animal. Celle-ci est
une spcialisation de la classe EtreVivant dont elle reprend la proprit dureDeVie. Le partitionnement des objets de la classe Animal fait apparatre la partition reprsente par la
classe EtreHumain. Linformation spcifique de cette classe est la dure de vie qui ne dpasse
pas cent cinquante ans.
Figure 2.28
Animal
Exemple dune
relation dhritage.
EtreVivant
EtreHumain
La classe EtreVivant est dite

classe parent ou superclasse
de la classe Animal. La classe
EtreHumain est dite classe
enfant, classe drive ou sousclasse de la classe Animal.
Comme le montre lexemple, lhritage simplifie la modlisation en utilisant les principes

dabstraction et de dcomposition. Labstraction consiste dfinir une hirarchie de sousproblmes devant tre traits en fonction de leur importance. La dcomposition, quant
elle, consiste dfinir un ensemble de sous-problmes pouvant tre traits sparment.
La spcialisation de classes consiste rduire le domaine de dfinition des objets. Cela se fait
principalement de deux manires : en ajoutant de nouveaux attributs, indpendants de ceux
existants, ou en rduisant le domaine de dfinition des attributs existants.
EXEMPLE
52
UML 2
Un rectangle et un cercle sont des figures gomtriques. Un carr est un rectangle dont la longueur et la largeur sont identiques.
Les classes dcrivant cette situation sont FigureGomtrique, Rectangle, Carr. La classe
Rectangle spcialise FigureGomtrique en ajoutant des attributs et la classe Carr spcialise la classe Rectangle en rduisant le domaine de dfinition des attributs existants (largeur
= longueur).
Chapitre
Figure 2.29
FigureGomtrique
Exemple dune
relation dhritage.
Rectangle
Cercle
largeur: integer
longueur: integer
carr
La liste suivante donne quelques proprits de lhritage :

La classe enfant possde toutes les proprits de ses classes parents. Mais elle na pas accs
aux proprits prives de celles-ci.
Une classe enfant peut redfinir (mme signature) une ou plusieurs mthodes de la classe
parent. Sauf indications contraires, un objet utilise les oprations les plus spcialises
dans la hirarchie des classes. La surcharge doprations (mme nom, mais signatures des
oprations diffrentes) est possible dans toutes les classes.
Toutes les associations de la classe parent sappliquent, par dfaut, aux classes drives.
Une instance dune classe peut tre utilise partout o une instance de sa classe parent est
attendue (principe de la substitution). Par exemple, toute opration acceptant un objet
dune classe Animal doit accepter tout objet de la classe Chat (linverse nest pas toujours
vrai).
Une classe peut avoir plusieurs classes parents. On parle alors dhritage multiple. Le
langage C++ est un des langages objet permettant son implmentation effective. Ce
mcanisme est largement considr comme une source derreurs, en raison de la complexit des relations entre attributs quil introduit.
Remarque
Lors de la redfinition dun attribut dune classe dans une sous-classe, il est fortement
conseill de le faire uniquement en restreignant son domaine de dfinition. Deux cas sont
possibles : soit garder le mme type et rduire le champ des valeurs, soit redfinir lattribut
comme objet dune sous-classe de sa classe prcdente. Dans le cas de la redfinition de
mthode, celle-ci est utilise afin de restreindre les arguments (en fixant certains), en tendant
la dfinition initiale de la mthode, en proposant dautres alternatives dimplmentation
(par exemple pour optimiser le temps de calcul).
EXEMPLE
Hritage multiple
Un bateau est la fois un vhicule moteur et un vhicule marin. Si les classes VhiculeAMoteur et VhiculeMarin existent, il est souhaitable dindiquer que le bateau hrite de lune et
de lautre et de profiter ainsi de toutes les proprits dj dfinies. Cependant, la question se
pose de savoir quelle est la proprit associe lobjet lorsque celle-ci apparat dans les
deux parents directs. La solution la plus simple consiste dfinir une priorit dhritage.
Figure 2.30
Exemple dhritage
multiple.
Si on donne la priorit au
VhiculeMarin alors le type du
nom dans Bateau sera String.
Bateau
VhiculeMarin
VhiculeMoteur
nom: String
nom: Char [1..10]
Remarque
Quand une classe (ou une opration) ne peut tre redfinie, il faut ajouter la proprit
{leaf} la dfinition de la classe ou de lopration. Lexercice 5 prsente certaines proprits de la relation dhritage.
(5)
Connecteurs, signaux et ports

Les connecteurs spcifient les liens de communication possibles entre les instances de
classeur. Ces liens peuvent correspondre des instances dassociation ou des communications via des passages de paramtres, des appels dopration, etc. Une connexion peut tre
ralise par un simple pointeur ou par un rseau de communication complexe.
Le port est une proprit dun classeur lui permettant de prciser ses points dinteraction
avec son environnement ou bien, parfois, avec ses propres parties. Les ports sont connects
via des connecteurs. Ils peuvent spcifier les services dun classeur ou les services quil
attend de son environnement. Deux principaux types de ports existent : le port protocole,
qui dcrit les connectiques interne et externe dun classeur (souvent classe active), et le port
comportemental, qui est directement associ la machine dtats (automate) du classeur
qui porte ce port.
Un signal modlise un message asynchrone chang entre les instances. Il est caractris
par un nom et un ensemble dattributs qui correspondent aux donnes transportes par le
signal.
Figure 2.31
Reprsentations
graphiques dun
connecteur, dun
port et dun signal.
(6)
connecteur
port
Port comportemental Port protocole
signal
estAllum
fait:boolean
Signal
Diagramme dobjets
Bien souvent, la description statique dun systme est faite travers le diagramme de classes.
Cela permet de simplifier la modlisation en synthtisant les caractristiques communes et
en couvrant un grand nombre dobjets. Parfois, il est utile, voire ncessaire, dajouter un
diagramme dobjets. Le diagramme dobjets permet, selon les situations, dillustrer le
modle de classes (en montrant un exemple qui explique le modle), de prciser certains
54
UML 2
Chapitre
aspects du systme (en mettant en vidence des dtails imperceptibles dans le diagramme de
classes), dexprimer une exception (en modlisant des cas particuliers, des connaissances
non gnralisables) ou de prendre une image (snapshot) dun systme un instant donn.
Le diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits.
Souvent, le diagramme de classes sert de modle pour instancier les classeurs afin dobtenir
le diagramme dobjets. Le diagramme de classes de la modlisation dune entreprise montre
quune entreprise emploie au moins une personne et quune personne travaille dans au plus
deux entreprises (figure 2.31(a)). En revanche, le diagramme dobjets modlise lentreprise
qui emploie trois personnes (figure 2.31(b)).
Figure 2.32
Entreprise
Diagramme de
classes et exemple
de diagramme
dobjets associ.
nom: String
0..2
travailler pour
1..*
Personne
e:Entreprise
nom: String="OSKAD"
travailler pour
p1:Personne
travailler pour
:Personne
travailler pour
p2:Personne
(a)
(b)
Les deux principaux classeurs instancis dans le diagramme dobjets sont les classes et les
relations.
6.1 REPRSENTATION
DES OBJETS
Graphiquement, un objet se reprsente comme une classe, avec deux compartiments, celui
du nom et celui des attributs. Le compartiment des oprations des classes nest pas utile
dans les objets puisque linterprtation des oprations est la mme pour tous les objets et
que tous les objets dune classe possdent les mmes oprations.
Contrairement au nom dune classe, le nom dun objet est soulign et son identifiant peut
tre ajout devant le nom de la classe. Les attributs reoivent des valeurs. Quand certaines
valeurs dattribut dun objet ne sont pas renseignes, on dit que lobjet est partiellement
dfini (figure 2.33(a)).
Parmi les diffrentes formes dobjet, on trouve les instances nommes (figure 2.33(b)), les
instances anonymes avec indication de paquetage (figure 2.33(c)), les instances multiples
(figure 2.33(d)), les instances orphelines (figure 2.33(e)) et les instances strotypes
(figure 2.33(g)). La figure 2.33(f) montre un objet sans valeur dattribut, mais avec un tat
explicite. Cela est particulirement utile lorsque plusieurs valeurs des attributs dun objet
correspondent une seule interprtation smantique. la figure 2.33(f), ltat grand correspond toutes les valeurs de lattribut taille suprieure un mtre quatre-vingts, par
exemple.
Figure 2.33
Exemples dinstances
dobjet.
:Personne
nom:String="toto"
age :integer="inconnu"
(a)
albert:Adhrent
(b)
:Adhrent ::Asso
(c)
:Adhrent
(d)
albert:
albert:Adhrent
[grand]
exception
e.IOException
(e)
(f)
(g)
6.2 INSTANCES
DE RELATION
Un diagramme de classes contient essentiellement des classes et des relations entre classes.
Quand un diagramme dobjets est cr partir dun diagramme de classes, les classes sont
instancies et deviennent des objets, tandis que les relations deviennent des liens au
moment de leurs instanciations. Graphiquement, un lien se reprsente comme une relation,
mais le nom de la relation est soulign. Lexemple de la figure 2.34 indique que le portable
achet par Jean est compos dun cran et est livr avec une alimentation.
Figure 2.34
SonyVaio1:Portable
Instances de relation
montrant des instances
dassociation,
de composition
et dagrgation.
6.3 RELATION
:Alimentation
:cran
DE DPENDANCE DINSTANCIATION
La relation de dpendance dinstanciation dcrit la relation entre un classeur et ses instances.

Elle relie, en particulier, les associations aux liens et les classes aux objets, comme le montre
la figure 2.35.
Figure 2.35
Enseignant
Dpendances
dinstanciation
entre les classeurs
et leurs instances.
(7)
1..*
instanceof
donner cours
1..*
instanceof
Etudiant
instanceof
donner cours
:Enseignant
:Etudiant
Contraintes
Les contraintes permettent de rendre compte des dtails que nexpriment pas les lments
du langage UML afin de restreindre la porte du modle. En UML, les contraintes sont vues
comme un mcanisme dextension. Elles sont exprimes par une expression mathmatique,
un langage de programmation, le langage naturel, etc. Cependant, un langage dexpression
des contraintes est maintenant associ UML et permet dexprimer la plupart des
contraintes : il sagit du langage OCL. OCL permet dexprimer principalement quatre types
de contraintes : les invariants, les pr-conditions et les post-conditions lexcution doprations ainsi que les conditions de garde.
Dans le diagramme de classes, les contraintes les plus couramment utilises permettent de
spcifier les valeurs initiales dun objet ou dune extrmit dune association, de spcifier
les rgles dhritage ({complete}, {incomplete}, {overlaps}, {distinct}, ), de spcifier une
mthode, de restreindre la porte dune association ({subset}, {xor},), dexprimer le
mode dvolution des objets ({frozen}, {addOnly}, ), leur organisation ({ordered},
{frozen}, ).
Dans le cadre dUML 2, les spcifications du langage OCL figurent dans un document indpendant, dcrivant en dtail la syntaxe formelle et la faon dutiliser ce langage.
56
UML 2
Chapitre
EXEMPLE
1. Un comit est compos dau moins deux personnes. Le comit est prsid par un de ses
membres.
2. Un polygone est compos dune srie dau moins trois sommets ordonns. Chaque sommet
est un point.
3. Une voiture peut avoir entre trois et dix roues. Durant la vie dune instance de la classe
Voiture, le nombre de roues ne change jamais.
Figure 2.36
Exemple dutilisation
des contraintes
pour affiner la
modlisation.
Polygone
Comit
membre de
{subset}
2..*
prside
1
Personne
Voiture
{ordered}
3..* sommet
Personne
{frozen}
2..*
Roue
Une contrainte, dans le modle de donnes, est associe au modle sauf si elle est associe
un strotype. Dans ce dernier cas, la contrainte concerne le mtamodle, et non le modle
de donnes. Pour plus de dtails, reportez-vous au document normatif ddi au langage
OCL.
(8)
Construction dun diagramme de classes

La construction du diagramme de classes, comme celle des autres diagrammes, dpend la
fois de lobjectif et de la finalit de la modlisation. Si on sintresse la finalit de la modlisation, souligne Steve Cook et John Daniels, il y a au moins trois points de vue qui guident
la modlisation.
Le point de vue spcification. Dans le domaine du logiciel, il met laccent sur les interfaces des classes plutt que sur leurs contenus.
Le point de vue conceptuel. Il capture les concepts du domaine et les liens qui les lient. Il
sintresse peu ou prou la manire ventuelle dimplmenter ces concepts et relations et
aux langages dimplmentation.
Le point de vue implmentation. Cest le plus courant. Lobjectif est de dtailler le contenu
et limplmentation de chaque classe.
En fonction des objectifs fixs, vous obtiendrez des modles ventuellement diffrents. Pour
cette raison, il faut absolument situer le contexte de la modlisation avant de commencer la
construction de tout diagramme.
Une dmarche couramment utilise pour btir un diagramme de classes consiste trouver
les classes, puis les associations entre elles, trouver ensuite les attributs de chaque classe, et
enfin organiser et simplifier le diagramme en utilisant notamment le principe de gnralisation. Il faut ritrer ce processus afin damliorer la qualit du modle.
Trouver les classes du domaine. La premire tape consiste, avec laide dun expert du
domaine, trouver une liste de classes candidates. La dmarche est souvent empirique.
Dans un premier temps, ne soyez pas trop restrictif. Les classes correspondent souvent des
concepts ou des substantifs du domaine. Parfois, elles correspondent des oprations :
une transaction pour une banque est une classe, tout comme un appel tlphonique pour
un oprateur de tlphonie. Nanmoins, une opration qui sapplique un objet est rarement
une classe : payer ou appeler ne sont pas des bons choix, mme pour une banque ou un oprateur de tlphonie.
Aprs avoir tabli une premire liste, liminez les classes redondantes (celles qui modlisent
des concepts similaires), ainsi que les classes superflues (celles qui ne sont pas en rapport
direct avec le domaine). Le nom des classes est important ; il ne doit pas tre vague. Par
exemple, EmployDanscurieDeCourseAutomobile est trop vague. Prfrez Pilote et Mcanicien. Il faut cependant faire attention aux classes qui portent un nom de rle : PremierPilote
et DeuximePilote ne sont pas des bons choix.
Le niveau de granularit dune classe est important. Gnralement, une classe contient plusieurs attributs. Si un substantif ne peut pas tre dcompos en plusieurs entits, il sagit
bien souvent dun attribut : un nom, par exemple, est considr comme un attribut dune
classe Personne, qui a par ailleurs dautres attributs (lge, le sexe), tandis que lauteur
dun livre ne peut pas se rduire lattribut dune classe Livre, car lauteur a un nom, une
date de naissance, etc.
Les classes ne doivent pas modliser des implmentations possibles dlments du domaine :
une liste de clients nest pas une bonne ide de classe car vous pouvez crer un ensemble
de clients de plusieurs faons, et pas seulement sous forme de liste. Dailleurs, un modle
contient rarement la fois des classes et leurs conteneurs. Le modle dune banque, par
exemple, ne doit pas runir simultanment les classes Clients au pluriel et Client au singulier, moins quil soit important de constituer un portefeuille de clients. Dans ce cas, il faut
avoir recours deux classes, Client et PorteFeuilleDeClients et les associer par une relation
de un vers plusieurs .
Trouver les associations entre les classes. Les associations correspondent souvent des verbes
mettant en relation plusieurs classes, comme est compos de , ou pilote , ou bien
encore travail pour . Les relations entre classes doivent tre modlises par des associations, et non par des attributs (conducteur pour une classe Pilote est un mauvais
choix dattribut mais conduire en tant quassociation entre les classes Pilote et Voiture est
appropri).
vitez les associations qui mettent en jeu plus de deux classes. Souvent, une association ternaire peut tre transforme en une association binaire qualifie. Par exemple, un conducteur
a besoin dune assurance pour conduire une voiture peut tre ramen un conducteur a
une voiture et lassurance est un attribut de lassociation binaire entre conducteur et voiture .
Quand plusieurs classes sont associes, plusieurs chemins sont ventuellement possibles
entre les classes. Le problme qui se pose souvent est le suivant : faut-il limiter les chemins,
ou au contraire, multiplier les associations en gnralisant les raccourcis ? Multiplier les
associations facilite lutilisation des classes lors de limplmentation car il nest pas ncessaire de parcourir de nombreuses associations pour accder une information. Cependant,
multiplier nimporte comment les associations conduit des chemins redondants, qui
napportent aucune valeur ajoute au diagramme de classes. De plus, multiplier les associations rduit la rutilisabilit de lapplication, car deux classes associes peuvent difficilement
tre utilises sparment. Dans la plupart des cas, vitez les chemins redondants durant
la phase danalyse. Il sera toujours temps, au moment de limplmentation, dajouter des
chemins si vraiment cela facilite la programmation.
Ne confondez pas une association avec un attribut car un attribut est propre une classe
tandis quune association met en jeu plusieurs classes. Dans certaines situations, cette rgle
intangible est viole de faon presque indiscernable. Considrez les deux classes Avion et
Camion : devez-vous considrer "est plus lourd que" comme une association ? Non, car le
plus simple est de placer un attribut masse dans chaque classe et dutiliser une simple
fonction de comparaison pour obtenir la rponse.
58
UML 2
Chapitre
Trouver les attributs des classes. Les attributs correspondent gnralement des substantifs
tels que la masse dune voiture ou le montant dune transaction . Les adjectifs tels
que rouge ou des expressions telles que 50 euros reprsentent souvent des valeurs
dattribut. Un attribut ne doit pas tre driv dun autre attribut : lge dune personne, par
exemple, peut tre dduit de sa date de naissance et de la date courante.
Vous pouvez ajouter des attributs toutes les tapes du cycle de vie dun projet (implmentation comprise). Nesprez pas trouver tous les attributs ds la construction du diagramme
de classes.
Organiser et simplifier le diagramme en utilisant lhritage. Un hritage dnote une relation
de gnralisation/spcialisation entre plusieurs classes. Vous pouvez construire un graphe
dhritage vers le bas , en partant dune classe du domaine et en la spcialisant en une ou
plusieurs sous-classes, ou vers le haut , en factorisant les proprits de plusieurs classes
pour former une classe plus gnrale.
Cependant, ne confondez pas numration et hritage. Une numration est un type de
donnes qui a un ensemble fini de valeurs possibles (les couleurs dune voiture par exemple). Un hritage reprsente une relation de gnralisation entre classes ; cela implique
quune des sous-classes au moins a un attribut, une mthode ou une association spcifique.
Tester les chemins daccs aux classes. Suivez les associations pour vrifier les chemins
daccs aux informations contenues dans les classes. Manque-t-il des chemins ou des informations ? Si le monde modliser parat simple, le modle ne devrait pas tre complexe.
Veillez nomettre aucune association. Cependant, ne cherchez pas relier systmatiquement toutes les classes. Certaines peuvent trs bien tre isoles.
Itrer et affiner le modle. Un modle est rarement correct ds sa premire construction.
La modlisation objet est un processus, non pas linaire, mais itratif. Plusieurs signes
dnotent des classes manquantes : des asymtries dans les associations et les hritages, des
attributs ou des oprations disparates dans une classe, des difficults gnraliser, etc.
La dmarche prsente dans cette section est une dmarche indicative. Diffrents processus
permettent la construction dun diagramme de classes. Dans tous les cas, respectez les rgles
simples et efficaces suivantes :
liminez les classes redondantes.
EXEMPLE
Un avion est associ un aroport de dpart et un aroport darrive. Une premire modlisation permet dobtenir trois classes : AroportDpart, AroportArrive et Avion (voir exercice 11). En ralit, tous les aroports jouent le rle daroport de dpart pour certains
avions et daroport darrive pour dautres. Il est donc insens de garder deux classes
Aroport. On limine la redondance en ne crant quune classe Aroport et en modlisant
les aroports de dpart et darrive comme des rles des associations qui lient lavion
laroport.
Retardez lajout des classes faisant intervenir les choix de conception et de ralisation.
EXEMPLE
Lapplication dcrite dans lexercice 1 indique que le systme gre les salaris de lentreprise.
Il nest pas souhaitable dintroduire une classe FichierEmploys car cela impose un choix de
ralisation. Ce choix doit tre retard dans la mesure du possible.
Najoutez pas les tableaux ou listes dobjets dans les classes. Souvent, cette information
est explicitement visible dans les multiplicits associes aux relations entre les classes.
Une bonne faon de reprsenter la prsence dun tableau dinstances dune classe dans
une autre est dutiliser les relations dagrgation ou de composition.
Quand une classe dispose de beaucoup de responsabilits, trouvez un moyen de la simplifier (voir le principe dabstraction et de dcomposition).
Lors de la modlisation et du choix des relations entre classes, distinguez bien les objets
physiques de leur description (du modle dobjets).
Une proprit structurelle (attribut) peut tre reprsente par une association, une
description textuelle dans un classeur ou une combinaison des deux.
vitez les oprations daccs aux attributs (get et set) car celles-ci ajoutent beaucoup de
bruits et sont souvent inutiles.
Pour des applications complexes, souvent plusieurs diagrammes de classes sont dfinis.
Chaque diagramme met en vidence des parties particulires du modle. Par exemple, un
diagramme montre les classes appartenant un paquetage, un autre montre les classes
participant la ralisation dun cas dutilisation, etc.
Conclusion
Dans ce chapitre, nous avons dabord dfini la notion de classe et dobjet. Un objet reprsente une entit concrte (par exemple un emplacement mmoire dans un ordinateur). La
classe, quant elle, adopte un niveau plus lev dabstraction car elle modlise, dune faon
concise, un ensemble dobjets. Cependant, souvent le diagramme dobjets est nglig lors de
la modlisation. Cest pourtant lui qui permet de dfinir les liens concrets entre les entits
avant que ceux-ci ne soient gnraliss dans le diagramme des classes. Par exemple, lassociation rflexive de la figure 2.17 ne permet pas de donner le nombre exact dobjets mis en
jeu. Plusieurs consquences peuvent en dcouler. Par exemple, il nest pas possible de dfinir
la quantit de mmoire prvoir pour les instances de cette classe.
Malgr leur importance, le diagramme de classes et le diagramme dobjets ont plusieurs
limites la bonne comprhension dun systme. Notamment, ils ne montrent pas le cycle de
vie des objets : nous ne savons pas, la lecture de tels diagrammes, dans quel ordre les objets
sont crs, utiliss puis dtruits, pas plus quils nindiquent lordre dans lequel senchanent
les oprations. Nanmoins, le diagramme des classes est le plus utilis pour la modlisation
dun systme car il en montre la structure interne.
Avec le diagramme des cas dutilisation, vu au chapitre 1, nous disposons, prsent, de deux
faons de voir un systme. En effet, le diagramme des classes donne une approche objet tandis que celui des cas dutilisation montre un ct fonctionnel. Mais, rien nindique que ces
deux modles sont cohrents entre eux : la structure interne donne par le diagramme des
classes supportera-t-elle les fonctionnalits prvues par les cas dutilisation ? Ce passage du
fonctionnel lobjet est dlicat. Une des solutions possibles pour garantir la cohrence des
deux modles est de faire un dcoupage en couches horizontales : la couche du bas dcrit
limplantation du diagramme des classes et la couche du haut permet, via une interface
(homme-machine et graphique par exemple), daccder aux fonctions de lapplication. Le
lien entre les deux couches est assur par ladjonction dune couche supplmentaire (dite
couche applicative). Une tude de cas, dcrite la fin de cet ouvrage dtaille comment
dcomposer un systme en couches.
60
UML 2
Chapitre
Problmes
et exercices
Les exercices suivants utilisent les principaux concepts des diagrammes de classes.
PROPRITS DUNE
CLASSE
Proposez une modlisation, en vue dune implmentation informatique, de la situation

suivante en mettant en vidence les diffrents compartiments et ornements des classes.
Ralisez la modlisation tape par tape, en faisant apparatre, en fonction des connaissances disponibles, les changements du modle.
1. Une personne est caractrise par son nom, son prnom, son sexe et son ge. Les responsabilits de la classe sont entre autres le calcul de lge, le calcul du revenu et le paiement
des charges. Les attributs de la classe sont privs ; le nom, le prnom ainsi que lge de la
personne font partie de linterface de la classe Personne.
2. Deux types de revenus sont envisags, le salaire et toutes les sources de revenus autres
que le salaire, qui sont tous deux reprsents par des entiers. On calcule les charges en
appliquant un coefficient fixe de 15 % sur les salaires et un coefficient de 20 % sur les
autres revenus.
3 Un objet de la classe Personne peut tre cr, en particulier, partir du nom et de la date
de naissance. Il est possible de changer le prnom dune personne. Par ailleurs, le calcul
des charges ne se fait pas de la mme manire lorsque la personne dcde.
1. La modlisation implique la cration dune classe Personne. Les attributs de la classe sont
le nom, le prnom, le sexe et lge. Dans lapproche objet, tout est objet ou classe. Sauf
exceptions, les types des attributs sont aussi des classes. Mme si les types des attributs ne
sont pas prciss, dfinissez le nom et le prnom comme une chane de caractres (classe
String). Partez du principe que le sexe peut avoir deux valeurs ('M' ou 'F') et que la date
de naissance peut tre de type Date (classe Date). Cela impose videmment lexistence
des classes String et Date, sinon il faut les crer. Tous ces attributs sont privs. Il faut donc
les faire prcder du modificateur daccs private ou -. Les services offerts par cette classe
sont le calcul de lge, la possibilit de voir le nom et le prnom dune personne ainsi que
le calcul des charges et du revenu. cette tape, vous navez pas suffisamment dinformations pour dduire les oprations permettant le calcul des charges et du revenu ; elles
resteront donc dans le compartiment de responsabilits de la classe. Elles seront, par la
suite, ralises par lajout dun ensemble doprations et/ou dattributs.
Exercices
EXERCICE 1
Figure 2.37
Classe Personne.
Personne {tat :non

valide}
- nom : String
- prnom : String
- sexe : {F, M}
- dateNaissance : Date
+getNom : String
+getPrnom : String
+calculAge() : Date
Dautres informations
peuvent tre ajoutes comme
lauteur, la date, etc.
Age = dateDuJour DateNaissance
Responsabilits
- calcul revenu
- calcul charges
Remarque
Dans la solution propose, la modlisation de lge est reprsente par un attribut dateNaissance et une mthode calculAge(). Une autre solution possible est de reprsenter lge
par un attribut et de laisser au programmeur le choix dun modle dimplmentation. Dans
ce cas, ajoutez lattribut driv /age ; sa valeur sera alors calcule partir dune mthode.
2. Au vu de ces nouvelles informations, les responsabilits de la classe se transforment en

proprits de la manire suivante :
Le calcul du revenu est reprsent par les attributs salaire et autreRevenu, avec ventuellement deux mthodes permettant la mise jour de leurs valeurs.
Le calcul des charges est reprsent par deux attributs de classe, chargeSalaire et autreCharge, et par une mthode de calcul des charges (puisque celle-ci est bien dtaille dans
lnonc).
Le calcul des charges est invalid en cas de dcs de la personne. De ce fait, ajoutez un
compartiment dexceptions pour prvoir le traitement ultrieur de cette exception.
Figure 2.38
Ajout des oprations
la classe Personne.
Personne
-chargeSalaire :Float =0.15
-autreCharge :Float =0.2
- nom : String
- prnom : String
- sexe : {F, M}
- salaire : Integer
- autreRevenu : Integer
La mthode correspondante
est :
Renvoie (salaire * chargeSalaire
+ autreRevenu * autreCharge)
+getNom : String
+getPrnom : String
+calculAge() : Date
+calculCharges () : Float
3. Pour crer un objet de la classe Personne, il faut par exemple disposer dun nom et dune
date de naissance. Mais il est ventuellement possible de crer un objet personne en
disposant dautres informations. Au lieu dajouter le constructeur indiqu seul, ajoutez
le strotype constructor, qui permet la fois dorganiser des oprations en groupes et
dindiquer quil est possible dajouter dautres constructeurs.
62
UML 2
Chapitre
Les oprations assurant le changement des valeurs des attributs peuvent galement tre
regroupes sous le strotype update.
Lnonc indique que le calcul des charges ne sapplique plus si la personne est dcde. Il
sagit, dans ce cas, dune exception qui doit tre ajoute dans le compartiment ddi afin
quelle soit traite lorsque les informations suffisantes seront disponibles.
Figure 2.39
Ajout du
compartiment
numrant les
exceptions.
Personne
-chargeSalaire :Float =0.15
-autreCharge : Float =0.2
- nom : String
- prnom : String
- sexe : {F,M}
- salaire : Integer
- autreRevenu : Integer
constructor
Personne (String nom, Date dNaissance)
update
+setPrenom (String prenom)
+setAge(Date dNaissance)
La mthode correspondante est :

Renvoie (salaire * chargeSalaire +
autreRevenu * autreCharge)
+getNom : String
+getPrnom : String
+calculAge() : Date
+calculCharges () : Float
Exceptions
Calcul charge si dcs
EXERCICE 2
CLASSE
STROTYPE
En trigonomtrie, on a besoin de calculer le sinus, le cosinus, la tangente des angles et la

valeur du nombre PI. La classe Angle existe dj. Proposez une structure qui regroupe ces
fonctions.
Les proprits de lnonc ne correspondent pas rellement une classe. Mais pour des
besoins dimplmentation, par exemple, on peut vouloir les regrouper ensemble. UML offre
un moyen de regrouper les variables et les oprations globales sous forme dune classe en
utilisant le strotype Utility. Ces classes sont dites utilitaires car elles ne rpondent pas
directement un besoin fonctionnel mais contribuent sa ralisation.
Utilisation du
strotype Utility.
Utility
Math
PI :Real = 3,14
sinus(Angle) : Real
cosinus(Angle) : Real
tangente(Angle) : Real
Exercices
Figure 2.40
EXERCICE 3
NOM DUNE
CLASSE
La classe Livre est dfinie dans le paquetage Ressource se trouvant lui-mme dans le paquetage Bibliothque. Parmi les attributs de la classe Livre figurent le nom de type String se
trouvant dans le paquetage Base et lemprunteur de type Adhrent se trouvant dans le
paquetage Bibliothque. Donnez la reprsentation graphique de la classe Livre.
Quand une classe est dfinie dans un paquetage, celui-ci peut tre prcis dans la dclaration
du nom de la classe. Du point de vue implmentation, le paquetage correspond souvent au
chemin daccs la classe.
Figure 2.41
bibliothque::ressource :: Livre
Espace de nommage
des classes.
EXERCICE 4
emprunteur:Bibbliothque ::Adhrent
nom :base ::String
DFINITION DUN
MESSAGE ASYNCHRONE
Lors de lenvoi dun e-mail, on souhaite lui associer un signal permettant de savoir que le
message envoy est approuv par le destinataire. Utilisez le mcanisme de classe strotype pour modliser ce message.
Les messages changs entre les instances de classe sont modliss par des oprations. Les
oprations sont, par dfinition, synchrones. UML 2 a prvu un mcanisme pour lchange
des donnes asynchrones. Il sagit des signaux.
Un signal est un message asynchrone. Comme une opration, le signal possde un nom et
des paramtres. Cependant, un signal peut se modliser comme une opration, une classe
ou une interface, en fonction de sa complexit et de sa nature. Quand il est modlis comme
une opration, il est prcd du mot-cl signal. Quand il est modlis par une classe, le nom
de la classe est prcd du strotype signal.
On suppose que le signal associ le-mail a une valeur boolenne qui indique si le message
est approuv ou pas.
Figure 2.42
Modlisation
dun signal.
64
UML 2
signal
estAllum
fait : Boolean
Ce signal aurait pu tre modlis dans

la classe message sous forme dun message
asynchrone comme suit :
signal estOk():Boolean
Chapitre
EXERCICE 5
CLASSE ACTIVE
Votre tlphone mobile dispose dun gestionnaire dvnements qui permet de suspendre
lactivit du tlphone lorsque celui-ci nest pas sollicit, dafficher un message quand un
rendez-vous est programm. Proposez une modlisation UML de ce gestionnaire dvnements.
Le gestionnaire dvnements peut tre modlis par une classe. Linstance de cette classe
cre elle-mme des instances de la classe vnements et contrle certaines activits de votre
tlphone. Il sagit dune classe particulire qualifie d active par UML.
Une classe active initie et contrle le flux dactivits alors quune classe passive (par dfaut)
sauvegarde les donnes et offre les services aux autres. Graphiquement, une classe active est
reprsente comme une classe standard, avec une paisseur de trait plus prononce.
Le gestionnaire dvnements contient des vnements. Il est capable de crer un vnement, de le suspendre, de lafficher ou de le dtruire. Cela donne le modle prsent la
figure 2.43.
Figure 2.43
Gestionnairevnements
Exemple de classe
active.
Lpaisseur du trait indique

quil sagit dune classe active.
evts : venement[1..n]
+cration(vnement)
+destruction(vnement)
+afficher(vnement)
+suspendre(vnement)
EXERCICE 6
CONTRAINTE
SUR UNE CLASSE
Les cartes de visite contiennent diverses informations. Leur caractristique commune est
que leurs proprits sont immuables durant toute la vie de la carte. Proposez une modlisation UML de cet lment.
Dans le cas de la carte de visite, deux types de contraintes saccumulent. En effet, la carte de
visite est en lecture seule et, en principe, une fois imprime, ses proprits restent immuables
durant toute la vie de la carte. Dans le cas gnral, les deux contraintes sont indpendantes.
Figure 2.44
Ajout des contraintes
dans la description
dune classe.
CarteDeVisite {frozen, ReadOnly}
Exercices
Vous pouvez geler une association en utilisant la contrainte standard {frozen}. Cette
contrainte prcise que la valeur de lassociation est gele durant toute la vie de lassociation. Ce principe sapplique de la mme manire pour les classes et les attributs. Dans
le cas de la classe, cela signifie que les valeurs sont affectes lors de la cration de lobjet et
ne changent pas.
EXERCICE 7
CLASSE
PARAMTRABLE
La gestion dune liste, indpendamment des objets quelle contient, utilise les oprations
dajout, de suppression et de recherche. Proposez une modlisation UML de concept.
Certains langages de programmation typage fort, comme le C++, utilisent des classes
paramtrables (patrons). Lintrt principal est de regrouper les comportements associs
la structure de la classe indpendamment des objets quelle contient. Il appartient, par la
suite, au programmeur de prciser le type dobjet concern pour que toutes les oprations
soient applicables.
Modlisez la classe Liste comme une classe standard, en ajoutant cette dfinition un ou
plusieurs paramtres substituables ClasseCible1ClasseCiblen qui reprsentent les classes
des objets cibles. La figure 2.45 donne la reprsentation graphique de la classe paramtrable
Liste et un exemple de classe cible utilisant cette classe paramtrable. Une fois que la classe
Livre est dfinie, les oprations permettant dinsrer, denlever, de chercher un livre sappliquent automatiquement.
Figure 2.45
En utilisant la classe
paramtrable Liste
et la classe standard
Livre, on dfinit une
liste de livres utilisant
les proprits de
la classe Liste.
EXERCICE 8
Liste
ClasseCible
+inserer(ClasseCible)
+ supprimer(ClasseCible)
+chercher(ClasseCible)
Livre
Liste<Livre>
(1)
RELATIONS
SIMPLES
Donnez les diagrammes de classes correspondant aux situations suivantes :

1. Les personnes qui sont associes luniversit sont des tudiants ou des professeurs.
2. Un rectangle est caractris par quatre sommets. Un sommet est un point. On construit
un rectangle partir des coordonnes de quatre sommets. Il est possible de calculer sa
surface et son primtre et de le translater.
3. Un crivain possde au moins une uvre. Ses uvres sont ordonnes selon lanne de
publication. Si la premire publication est faite avant lge de dix ans, lcrivain est dit
prcoce .
4. Tous les jours, le facteur distribue le courrier aux habitants de sa zone daffectation.
Quand il sagit de lettres, il les dpose dans les botes aux lettres. Quand il sagit dun
colis, le destinataire du courrier doit signer un reu. Proposez les classes candidates et
dduisez-en le diagramme de classes.
1. Cet exercice met en vidence lassociation multiple entre deux classes et la ncessit
dajouter une contrainte (mcanisme dextension dUML) pour exprimer le fait que le
rle dune personne luniversit est tudiant ou bien professeur. Seuls les noms des
66
UML 2
Chapitre
deux classes, des deux associations et la contrainte entre associations apparaissent dans la
solution. En effet, vu les informations disponibles dans lnonc et lobjectif de la modlisation (mettre en vidence les relations entre classes), il est inutile dajouter dautres
informations.
Figure 2.46
Contraintes entre
associations.
tudier
Universit
Personne
{ ou }
enseigner
2. Il sagit de reprsenter la fois les dtails dune classe et ses liens avec une autre classe. La
classe principale modliser est la classe Rectangle. Elle est associe la classe Point qui
joue le rle de ct dans lassociation avec la classe Rectangle. En labsence dinformations complmentaires permettant, en particulier, de savoir lutilit de modliser la classe
Point, vous pouvez proposer deux solutions, lune faisant apparatre uniquement la
classe Rectangle, et lautre, plus dtaille, faisant apparatre les classes Rectangle et Point.
Cela dit, si seule la classe Rectangle est reprsente, vous perdez linformation sur lassociation du point vers le rectangle. Cela correspond une modlisation dune association
unidirectionnelle de Rectangle vers Point alors que cette information nest pas disponible
directement dans lnonc. Ce choix peut tre justifi par lobjectif de la modlisation et
par le choix de limplmentation (pour limplmentation de lassociation, un attribut
point sera ajout dans Rectangle).
Figure 2.47
La figure de gauche
transforme
lassociation entre
les classes Rectangle
et Point en une
relation de
composition.
Rectangle
-sommet : Point[2]
constructor
Rectangle(Point, Point)
query
+ surface () : Float
update
+translater (Point)
Rectangle
constructor
Rectangle(Point, Point)
query
+ surface () : Float
update
+translater (Point)
-sommet
2
Point
Figure 2.48
Si datePublication dateNaissance
<10 lcrivain est dit prcoce
Ajout de contraintes
pour limiter la
porte dune
association.
crivain
#dateNaissance : Date
{ordered} 1..*
uvre
#datePublication : Date
Exercices
3. Les deux classes principales sont crivain et uvre. Une association bidirectionnelle
nomme possder relie les deux classes. Les uvres sont ordonnes selon la date de publication. Ajoutez donc lattribut datePublication de type Date dans uvre et la contrainte
{ordered} du langage OCL. Celle-ci signifie que les uvres sont ordonnes. Pour indiquer que lcrivain est prcoce, ajoutez un commentaire en langage naturel sous forme de
note. Cette note peut prciser galement le critre utilis pour lordonnancement. Il est
aussi ncessaire dajouter deux attributs dans la classe crivain : dateDeNaissance de type
Date et /prcoce de type Boolean. Lattribut /prcoce est un attribut drive de lassociation
entre crivain et uvre. Par ailleurs, la multiplicit du ct de lcrivain nest pas prcise
car celle-ci nest pas indique dans lnonc.
4. La lecture du texte permet de slectionner les classes candidates suivantes : Facteur, Courrier, Habitant, ZoneDAffectation, Lettre, BoteAuxLettres, Colis, Destinataire.
La rdaction dune liste de classes candidates intervient en phase danalyse prliminaire.
Lobjectif est de dgager les principaux concepts partir de lanalyse fonctionnelle. Les
phases danalyse et de conception permettent de slectionner les classes qui apparatront dans le diagramme de classes. Pour trouver les candidates, il faut recourir un
expert du domaine, consulter le cahier des charges du client et parfois tenir compte du
langage dimplmentation qui sera utilis pour la ralisation (notamment pour les classes
utilitaires).
Si la modlisation concerne la mise en vidence du lien entre le facteur et les habitants
ainsi que la zone daffectation du facteur, vous pouvez proposer la solution qui suit :
La classe BoteAuxLettres nest pas pertinente. Elle ne fera pas partie du diagramme de
classes.
Un colis et une lettre sont des courriers particuliers.
Le destinataire est le rle dun habitant quand il reoit un courrier. Il ne sera pas reprsent par une classe.
Un facteur dessert une zone daffectation qui abrite plusieurs habitants.
Le seul lien entre le facteur et lhabitant est la distribution du courrier (classe-association).
Figure 2.49
Modlisation dune
classe-association.
Habitant *
destinataire
Lettre
ZoneDAffectation
Courrier
affecter
Colis
EXERCICE 9
RALISATION DUNE
Facteur
INTERFACE
Les tudiants peuvent tre compars par rapport lattribut moyenne gnrale et les livres
sont comparables par rapport leurs prix de vente. Pour des raisons dhomognit des
interfaces prsentes par les classes, tous les objets comparables utilisent la mme opration
compareTo(Instance). Proposez le diagramme de classes mettant en vidence lopration de
comparaison.
Les classes qui interviennent dans cette application sont tudiant et Livre. Lopration compareTo(Instance) compare tout type dobjet. Elle est donc abstraite. Si elle est commune
toutes les classes, vous devez la dfinir dans une interface que vous appellerez par exemple
68
UML 2
Chapitre
Comparable. Cette interface sera ralise par les classes qui lutilisent. Pour lapplication
considre, vous obtenez le diagramme prsent la figure 2.50.
Figure 2.50
tudiant
Ralisation
dune interface.
moyenneGn :float
realize
EXERCICE 10 UTILISATION DUNE
Livre
interface
Comparable
CompareTo()
realize
INTERFACE
Luniversit propose des cours de langue accessibles aux agents administratifs et aux
enseignants. La procdure dinscription est la mme pour les deux catgories de personnes.
Une personne inscrite peut galement rsilier son inscription. Modlisez les classes pour
reprsenter cette situation. Simplifiez la modlisation en faisant apparatre uniquement les
classes Enseignant et AgentAdministratif.
Les agents administratifs et les enseignants sont des personnes particulires. Ils partagent les
oprations inscrire() et rsilier(), qui font partie de la mme interface : Inscription. Dans un
premier temps, crez les classes Personne, Enseignant, AgentAdministratif, et linterface Inscription qui contient deux oprations : inscrire() et rsilier(). Faites volontairement abstraction de la classe Cours car lobjectif ici est de mettre en vidence les relations de dpendance
et de ralisation.
La ralisation de linterface Inscription est faite de la mme manire par les deux classes drives de Personne. De ce fait, et pour viter la redondance de la ralisation, il suffit quune seule
des deux classes sen charge (relation de ralisation) et que la deuxime utilise les mthodes
obtenues (relation de dpendance strotype par use ), comme le montre la figure 2.51.
Figure 2.51
Personne
AgentAdministratif
Enseignant
realize
interface
Inscription
+inscrire()
+rsilier()
use
Pour mettre en vidence uniquement les deux classes Enseignant et AgentAdministratif,

utilisez le lien simplifi de la figure 2.52, qui indique que la classe Enseignant implmente
linterface Inscription utilise par la classe AgentAdministratif.
Figure 2.52
Utilisation
dune interface.
AgentAdministratif
Enseignant
use
Exercices
La classe Enseignant
ralise linterface
Inscription et la classe
AgentAdministratif
utilise le rsultat.
EXERCICE 11 RELATIONS
Une commande est lie plusieurs produits. chaque produit de la commande sont associes des dates.
1. Donnez une modlisation UML de lassociation entre ces trois classes.
Plus prcisment, deux dates sont affectes chaque produit dune commande, une
date et un produit sont associs une seule commande et, une commande et une date
donne sont lis deux dix produits.
2. Compltez la modlisation UML de lapplication.
Soit la base de donnes suivante : (commande, produit, date) = {(c1,p1,d1), (c1,p2,d2),
(c2,p1,d2), (c2,p4,d4)}.
3. Vrifiez quelle respecte bien le diagramme UML de la question 1. Sinon, ajoutez-lui les
tuples ncessaires pour la rendre conforme.
1. Trois classes peuvent tre extraites de la description de lapplication : Commande, Produit
et Date. Les deux relations entre les classes dfinies dans lnonc sont les suivantes :
Une relation binaire intervient entre Produit et Commande. La commande est compose
de plusieurs produits. Mais, les dures de vie des objets ne sont pas lies. De ce fait, cette
relation peut tre modlise par une agrgation. La commande est compose de plusieurs
produits. En principe, il faut dfinir une multiplicit *.
Une relation ternaire met en jeu les trois classes Commande, Date et Produit.
Figure 2.53
Commande
Produit
Relation ternaire.
1
2
Date
2. Pour dfinir la multiplicit mettre ct dune classe dans une relation n-aire, calculez
le nombre dobjets de ladite classe consistant avec chaque ensemble de (n-1) objets des
autres classes. Lunion de ces nombres calculs constitue la cardinalit de la relation. Pour
cette application, calculez le nombre dobjets de la classe Date consistant avec chaque
couple dobjets des classes Commande et Produit, le nombre dobjets de la classe Commande consistant avec chaque couple des classes Produit et Date et le nombre dobjets de
la classe Produit consistant avec chaque couple dobjets des classes Commande et Date.
Par exemple, lnonc indique qu chaque couple dobjets des classes Commande et
Produit sont associes exactement deux dates (figure 2.54).
70
UML 2
Chapitre
Par ailleurs, mme si lnonc ne le dit pas explicitement, vous savez quune commande
na de sens que si elle porte sur au moins un produit et quun produit peut apparatre
dans plusieurs commandes. La multiplicit de lagrgation est, de ce fait, restreinte.
Figure 2.54
Commande
Multiplicits
associes aux
relations n-aires.
1..*
Produit
2..10
1
2
Date
3. La contrainte de cardinalit est viole plusieurs fois par la base de donnes. Par exemple,
il est indiqu qu chaque couple dinstances des classes Commande et Produit correspondent exactement deux instances de la classe Date. Les couples (c2,p1) et (c2,p4) ne
vrifient pas cette contrainte.
Commande
c1
c1
c1
c1
c2
c2
c2
c2
Produit
p1
p1
p2
p2
p1
p1
p4
p4
Date
d1
d3
d2
d5
d2
d6
d4
d7
EXERCICE 12 HRITAGE
Exercices
1. Le chat et le chien sont des animaux. Les animaux possdent tous un nom. Proposez
une modlisation de cette situation en faisant apparatre que dautres animaux que les
chats et les chiens existent et quun animal ne peut pas tre la fois un chat et un chien.
2. Les animaux, en fonction de leur catgorie (chat, chien), ont un cri spcifique. Si la
catgorie de lanimal nest pas connue, le cri ne peut tre ralis. Compltez la modlisation prcdente pour inclure cette proprit.
3. Tous les animaux sont comparables par rapport la puissance, en dcibels, du cri
dgag. La valeur maximale est connue pour chaque catgorie danimaux. De plus,
pour des soucis dhomognit, toutes les comparaisons doivent respecter une interface
commune. Compltez le modle prcdent avec ces nouvelles informations.
1. Vous avez besoin de trois classes : Chat, Chien et Animal. La classe Animal est plus gnrale (hritage) que les deux classes Chien et Chat. Une instance de la classe Chat (respectivement Chien) ne peut pas tre instance de la classe Chien (respectivement Chat) : il
sagit dun hritage exclusif (utilisation de la contrainte {disjoint} du langage OCL). Par
ailleurs, dautres animaux que les chats et les chiens existent. La contrainte {incomplete}
du langage OCL permet dexprimer cette contrainte.
Figure 2.55
Animal
nom : String
Hritage avec
contraintes. Lhritage
est incomplet et les
hritiers sont tous
disjoints.
{incomplete, disjoint}
Chien
Chat
2. Lopration crier() est partage par tous les animaux. Elle doit donc apparatre au niveau
de la classe Animal. Cependant, la mthode associe nest connue quau niveau des
descendants de cette classe. Cette mthode est donc abstraite. Les classes Chat et Chien
doivent absolument redfinir la mthode crier().
Figure 2.56
Animal {abstract}
nom : String
Ajout de la mthode
abstraite partage
par tous les hritiers
de la classe Animal.
abstract crier()
Chien
Chat
3. La valeur en dcibels de la puissance des cris est pareille pour chaque catgorie danimaux . Utilisez donc une variable statique. Pour oprer les comparaisons, dfinissez une
interface commune, par exemple Comparable, contenant les oprations ncessaires, en
loccurrence float compareTo(type) qui est ralise par chaque catgorie danimaux comme
le montre la figure 2.57.
Figure 2.57
Implmentation
de linterface
Comparable par
les classes drives
de la classe Animal.
use
interface
Comparable
float compareTo(type)
Animal {abstract}
nom : String
abstract crier()
realize
{incomplete,disjoint}
realize
Chat
static float bitCri
72
UML 2
Chien
static float dbitCri
Chapitre
EXERCICE 13 HRITAGE
Un tudiant et un enseignant sont des personnes particulires.
1. Proposez un modle de classes correspondant.
Un doctorant est un tudiant qui assure des enseignements. La modlisation sera suivie
par une implmentation en Java ou en C++.
2. Compltez le modle de classes prcdent en exploitant au mieux les possibilits du langage cible.
Un doctorant et un tudiant doivent sinscrire au dbut de lanne et ventuellement
modifier leur inscription. En fonction des deux modles proposs.
3. Ajoutez cette fonctionnalit aux deux prcdents modles.
1. Les tudiants et les enseignants hritent de la classe Personne. Dautres personnes, qui
ne sont ni des tudiants, ni des enseignants, drivent de la classe Personne. Ajoutez la
contrainte{incomplete} du langage OCL pour expliciter cette situation.
Figure 2.58
Personne
Relation dhritage.
{incomplete}
tudiant
Enseignant
2. Un doctorant est la fois un tudiant et un enseignant. Le doctorant hrite la fois des

proprits des enseignants et de celles des tudiants. Il sagit bien dun hritage multiple.
Cela ncessite, galement, lajout de la contrainte {overlapping}, qui indique quun tudiant et un enseignant peuvent instancier le mme objet (lintersection entre les ensembles dobjets des classes Enseignant et tudiant nest pas vide). Ce modle est correct pour
une implmentation en C++, car ce langage autorise lhritage multiple.
Figure 2.59
Personne
Solution en utilisant
lhritage multiple.
{incomplete, overlapping}
tudiant
Enseignant
Java naccepte que lhritage simple. Cette contrainte implique une modlisation hirarchique de lhritage. En dautres termes, une classe peut avoir au plus un seul parent.
Lajout de cette contrainte implique implicitement lajout de la contrainte {disjoint} entre
les classes qui drivent directement de toute classe du modle. Vous pouvez modliser
Exercices
Doctorant
cela en sparant les instances des doctorants de celles des tudiants et des enseignants.
Vous obtenez le modle prsent la figure 2.60.
Figure 2.60
Personne
Solution en utilisant
lhritage simple
tudiant
Enseignant
Doctorant
3. Linscription ncessite au moins deux oprations.

Dans le cas de lhritage simple, la solution consiste dfinir une interface Inscription
contenant les deux oprations. Celles-ci peuvent tre ralises par la classe tudiant et
utilises par la classe Doctorant (figure 2.61).
Figure 2.61
Personne
Solution dans le cas

de lhritage simple.
tudiant
Enseignant
Doctorant
use
realize
interface
Inscription
La solution propose par la figure 2.61 est aussi valable dans le cas o le langage supporte
lhritage multiple. Cependant, dans ce dernier cas, deux autres solutions sont possibles
comme le montre la figure 2.62.
Figure 2.62
Les deux solutions
possibles dans le
cas de lhritage
multiple.
Personne
Personne
{incomplete,
Enseignant
tudiant
overlapping}
tudiant
inscrire() ;
modifier()
{incomplete,
Enseignant overlapping}
Doctorant
realize
74
UML 2
interface
Inscription
inscrire() ;
modifier() ;
Doctorant
Chapitre
EXERCICE 14 DIAGRAMME DOBJETS

Un robot se dplace dans un environnement compos de zones, de murs et de portes.
Proposez le diagramme dobjets dcrivant la situation suivante : le robot Mars est en mouvement. Il est li une instance mondeCourant de la classe Monde dcrivant les mondes
possibles o peut voluer le robot. Le robot peut manipuler des objets se trouvant dans le
monde dans lequel il volue.
linstant qui nous intresse, le robot Mars est en mouvement et mondeCourant est li
aux zones z1 et z2. La zone z2 est compose de deux murs (m1 et m2) et dune porte. La
largeur de la porte est de un mtre.
Donnez le diagramme dobjets associ cette situation.
Vous avez besoin des classes Robot, Monde, Objet, Zone, Mur et Porte. La classe Robot est
active. Le diagramme dobjets prsent la figure 2.63 correspond un snapshot dune
situation particulire et varie selon la position du robot.
Figure 2.63
Diagramme dobjets.
mars:Robot
[enMouvement]
m1:Mur
z2:Zone
:Porte
mondeCourant:Monde
largeur:integer=1m
z1:Zone
m2:Mur
:Objet
EXERCICE 15 PATRON
DE CONCEPTION
OBJETS COMPOSITES
1. Toutes les figures comportent les oprations dessiner() et translater(). Les mthodes
associes ne sont pas connues, donc la classe Figure est abstraite. Une figure peut tre
spcialise en figure simple ou en figure compose. Cette dernire peut tre compose
(relation dagrgation) de plusieurs figures.
Exercices
Une figure gomtrique est compose de figures simples ou composes. Une figure compose est constitue de plusieurs figures et une figure simple peut tre un point, une ligne
ou un cercle. Une figure peut tre dessine ou translate.
1. Donnez la modlisation des classes de cette situation.
2. De manire plus gnrale, la notion dobjets composites se retrouve dans beaucoup
dapplications. De ce fait, il est intressant de proposer un patron de conception qui
modlise les objets composites et de les instancier en fonction des objets considrs.
tendez la solution prcdente afin de modliser nimporte quel ensemble dobjets
dcrits par une hirarchie dagrgation dobjets ayant le mme comportement.
Figure 2.64
Figure{abstract}
Diagramme de
classes modlisant
les figures simples
et composes.
Elment de
+dessiner()
+translater()
FigureSimple
FigureCompose
+dessiner()
+translater()
Cercle
+dessiner()
+translater()
+dessiner()
+translater()
Point
+dessiner()
+translater()
Ligne
+dessiner()
+translater()
2. Le patron de conception dobjets composites permet de reprsenter des objets qui se

dcrivent par une hirarchie dagrgation dobjets dans laquelle tous les objets, jusquau
plus haut niveau, prsentent un mme comportement (on peut leur appliquer un mme
ensemble de mthodes). Cette solution est propose par Erich Gamma.
Figure 2.65
Le diagramme de
classes modlisant
le patron de
conception objets
composites .
Les oprations communes

dont certaines sont abstraites.
Composant{abstract}
Composant{abstract}
fils de
+operation
Feuille
+operation()
Composite
+operation()
Appliquer lopration
tous les descendants.
EXERCICE 16 APPLICATION
+ajout(c :Composant)
HTELIRE
Un htel est compos dau moins deux chambres. Chaque chambre dispose dune salle
deau qui peut tre une douche ou une salle de bain. Lhtel hberge des personnes. Il peut
employer du personnel et est dirig par un des employs. Lhtel a les caractristiques suivantes : une adresse, le nombre de pices, la catgorie. Une chambre est caractrise par le
nombre et le type de lits, le prix et le numro. On peut calculer le chiffre daffaires, le loyer
en fonction des occupants.
1. Donnez le diagramme de classes.
2. Utilisez les contraintes pour affiner les relations.
76
UML 2
Chapitre
La figure 2.66 propose une solution qui rpond aux deux questions.
Diagramme de
classes reprsentant
lapplication
htelire.
Htel
Chambre
adresse : String
catgorie : String
2..*
calculChiffreAffaires() : double
Loyer() : double
hberge emploie
{ou}
{ou}
0..1
1
dirige
1
1
loue
{element de}
*
1..*
1
SalleDEau
Personne
client
douche
EXERCICE 17 APPLICATION
Le loyer est calcul

en fonction du nombre
de personnes, de la
saison, etc.
nombreLit : int
typeLit : String
lePrix : double
numro : int
Baignoire
BANCAIRE
Une banque compte plusieurs agences rparties sur le territoire franais. Une banque est
caractrise parle nom de son directeur gnral, son capital global, son propre nom et de
ladresse de son sige social. Le directeur gnral est identifi par son nom, son prnom et
son revenu.
Une agence a un numro dagence et une adresse. Chaque agence emploie plusieurs
employs, qui se caractrisent par leurs nom, prnom et date dembauche. Les employs
peuvent demander leur mutation dune agence une autre, mais un employ ne peut travailler que dans une seule agence. Les employs dune agence ne font que grer des clients.
Un client ne peut avoir des comptes que dans une seule agence de la banque. Chaque nouveau client se voit systmatiquement attribuer un employ de lagence (conseiller). Les
clients ont un nom, un prnom et une adresse.
Les comptes sont de nature diffrente selon quils soient rmunrs ou non (comptes
courants). Les comptes rmunrs ont un taux dintrt et rapportent des intrts verss
annuellement.
1. Donnez la description complte de toutes les classes (remplissez tous les compartiments).
Prcisez les types des attributs et les types de retour des fonctions. Les attributs sont
tous privs. Chaque attribut possde deux mthodes publiques (getAttribut renvoie la
valeur dun attribut et setAttribut affecte une nouvelle valeur un attribut). Toutes les
autres mthodes sont accessibles uniquement dans le package de la classe.
2. Analysez les classes trouves en (1) et modlisez-les en factorisant (par gnralisation
ou autre) au mieux la description des proprits.
3. Une relation particulire lie lagence, le client, lemploy et le compte. De quelle relation
sagit-il ? Dessinez le modle de cette relation.
4. Donnez le diagramme de classes en nutilisant que leur nom et ajoutez tous les ornements possibles aux relations.
Exercices
Figure 2.66
1. Les classes qui apparaissent dans cette application sont Banque, Directeur, Agence,
Employ, Client, CompteRmunr, CompteNonRmunr.
Figure 2.67
Description dtaille
des classes de
lapplication.
Banque
Directeur
-nom : String
-prenom : String
-revenu : float
-nomDirecteur : String
-capital : int
-adresseSiege : String
Client
Employ
-nom : String
-prenom : String
-adresse : String
-conseiller : Employer
-agence : Agence
-comptes : [1..N] Compte
-nom : String
-prenom : String
-dateEmbauche : Date
+getNomDirecteur() : String
+getNom() : String
+getNom: String
+setNomDirecteur(String n)
+setNom (String n)
+setNom(String n)
+getCapital():int
+getPrenom ():String
+getPrenom():String
+setPrenom(String p)
+getNom: String
+setCapital(int capital)
+setPrenom(String s)
+getRevenu():float
+setNom(String n)
+getAdresseSiege():String
+getDate(): Date
+setRevenu(float s)
+getPrenom():String
+setAdresseSiege(String s)
+setDate(Date s)
+setPrenom(String s)
mutation(Agence g): boolean
+getDate(): Date
Banque(String Adresse)
+setDate(Dates)
mutation(Agence g):boolean
CompteNonRmunr
-solde : float
-numero : int
Agence
-nomAgence :String
-adresseAgence : String
CompteRmunr
-solde : float
-numero : int
-taux : float
+getNomAgence() : String
...
+setNomAgence(String n)
...
verserInteret() : void
2.
Figure 2.68
Personne
Les liens de
gnralisation
entre les classes
de lapplication.
Compte
Directeur
Employ
CompteRemunr
CompteNonRemunr
Client
3.
Figure 2.69
Agence
Employ
Associations
ternaires avec
classe-association.
1..*
Compte
78
UML 2
Client
Chapitre
4.
Figure 2.70
Personne
Diagramme
de classes de
lapplication
bancaire.
1
1
Banque
1..*
Agence
1..*
Directeur
1..*
Employ
1
1
Client
1..*
Compte
CompteRmunr
EXERCICE 18 RSERVATION
CompteNonRmunr
DE BILLETS DAVION
1. Tous les avions assurent plusieurs vols. Il est donc utile de remonter lassociation "assurer
vol" au niveau des classes Avion et Vol. Cependant, si vous nutilisez pas les contraintes et
si la contrainte spcifiant quun avion-cargo (respectivement de passagers) assure exclusivement des vols cargos (respectivement de passagers) alors la seule solution consiste,
non pas remonter lassociation entre Avion et Vol, mais la prciser entre tous les types
de vols et davions (figure 2.71).
Exercices
Un avion assure plusieurs vols et un vol est assur par un seul avion. Un vol peut tre un
vol cargo ou un vol de passagers. Les avions utiliss pour ces deux types de vols ne sont pas
les mmes.
1. Donnez le diagramme de classes exprimant cette situation.
2. Ajoutez les contraintes du langage OCL pour exprimer le fait quun vol cargo soit assur
par un avion-cargo et quun vol de passagers soit assur par un avion de passagers.
Les vols sont proposs par des compagnies ariennes. Pour un meilleur remplissage des
avions, un vol est partag par plusieurs affrteurs. Un des affrteurs assure louverture et
la fermeture de chaque vol. Un vol est caractris par une date et un lieu de dpart, une
date et un lieu darrive.
3. Donnez la modlisation des classes de cette situation.
Quand un client fait une rservation auprs dune compagnie arienne pour un ou plusieurs passagers, il est inform du fait que le vol compte plusieurs escales. Une escale est
caractrise par des dates darrive et de dpart ainsi quun aroport qui dessert plusieurs villes.
4. Proposez le diagramme de classes pour cette situation.
5. partir de ces diagrammes partiels, proposez un diagramme de classes modlisant cette
application.
Figure 2.71
Vol
Avion
Diagramme
de classes.
AvionCargo *
AvionPassagers
assurer
VolCargo
assurer
VolPassagers
2. Lajout des contraintes du langage OCL permet une meilleure gnralisation travers
lexpression de cas particuliers et dexceptions. Vous pouvez remonter lassociation entre
un avion et un vol au niveau des classes Vol et Avion et ajouter une contrainte qui restreint limpact de lassociation sur les instances des classes (figure 2.71).
Figure 2.72
Avion
Gnralisation de
lassociation assure
par lajout de
contraintes OCL.
assurer
Vol
context Vol
inv: type=cargo implies Avion.type=cargo
inv: type=passager implies Avion.type=passager
VolCargo
AvionCargo
AvionPassagers
VolPassagers
3. Le rle de la compagnie arienne par rapport un vol est celui daffrteur. Laffrteur qui
ouvre un vol est aussi celui qui le ferme. De plus, un vol ne peut tre ouvert puis ferm
quune seule fois. UML ne fournit pas un moyen dexprimer cette double synchronisation. De ce fait, une note est ajoute au diagramme pour exprimer cette contrainte. Les
caractristiques dun vol (dates et lieux) ne sont pas dtailles et seront reprsentes par
de simples attributs.
Figure 2.73
Modlisation
dtaille de
la classe Vol.
Vol
1..*
propose
1..*
CompagnieArienne
#dateDpart:Date
#dateArrive:Date
#lieuDpart:Lieu
#lieuArrive:Lieu
+ouvrirVol()
+fermerVol()
Prconditions
ouvrir(): instance de vol jamais ouverte
former(): instance de vol ouverte par le
mme objet et jamais ferme.
4. Lassociation qui lie le client et la compagnie arienne concerne la rservation. La rservation nat de cette association et se compose de toutes les donnes la concernant. Il sagit
donc dune classe-association. La rservation concerne un passager et un vol.
Dans la modlisation prcdente, les lieux de dpart et darrive ne sont pas dtaills
(reprsentation sous forme dattributs). Cette fois, le lieu est connu : il sagit de laroport. Les deux attributs modlisant le lieu se transforment en rle dans les associations
reliant le vol et laroport.
80
UML 2
Chapitre
Une escale se caractrise par des dates et un aroport. Elle est dcrite par les attributs de
la classe Vol mais pas par ses mthodes (ouvrir(), fermer()). Ce nest donc pas un vol
particulier. Un vol peut compter plusieurs escales ordonnes. Chaque escale est lie un
aroport. Lescale nat dune relation entre un vol et un aroport, qui nest ni un aroport
de dpart, ni un aroport darrive. Les escales sont reprsentes par une classe-association
entre un vol et un aroport.
Figure 2.74
Client
Vol
Modlisation des
vols des compagnies
ariennes.
dpart
1
arrive
*
*
Reservation
Aroport
1
{ordered}
Passager
*
Escale
CompagnieArienne
dateDpart:Date
dateArrive:Date
Ville
EXERCICE 19 PATRON BRIDGE

Une figure gomtrique peut tre un cercle ou rectangle. On souhaite proposer aux clients
un outil de dessin des figures gomtriques qui sadapte lenvironnement informatique.
Les interfaces, la qualit des dessins dpendent de lenvironnement.
1 .Proposez une modlisation qui isole le dessin dune figure gomtrique et qui la spcialise en fonction de lenvironnement.
2. Selon le mme principe et dune manire plus gnrale, on souhaite concevoir une
structure qui permet un client de voir une classe et ses oprations de haut niveau.
Cette structure doit sparer compltement la dfinition abstraite des classes et leur
implmentation.
Proposez un schma de modlisation.
1. Le client est associ aux figures gomtriques. Son objectif est de les dessiner. La figure
gomtrique est compose dun ensemble de proprits, dont celles lies au dessin (trait,
couleur, etc.). Ces proprits dpendent de lenvironnement (elles sont spcialises). La
figure gomtrique peut tre spcialise, en particulier, en cercle ou en rectangle.
Client
Modlisation
gnrique dune
figure gomtrique.
FigureGomtrique
Cercle
Rectangle
Dessin
DessinInterface1
DessinInterface2
Exercices
Figure 2.75
Labstraction est visible par les clients, renvoie les demandes vers limplmentation (operation=Implementation.operation) et fournit des fonctions de haut niveau. Les classes
RefinedAbstraction implmentent les diffrentes abstractions, la faon des classes FigureGeometrique qui implmentent diffrentes figures. Implementation est une interface
entre plusieurs implmentations possibles. Elle offre des oprations de bas niveau. Les
classes Implementation1 et Implementation2 permettent dimplmenter linterface Implementation en proposant des mthodes concrtes.
Figure 2.76
Diagramme de
classes du patron
de conception
Bridge .
+Implementation.operations()
Client
Abstraction
Implementation
+operation()
+operation()
RefinedAbstraction
EXERCICE 20
RefinedAbstraction
Implementation1
Implementation2
PATRON ADAPTEUR
Un diteur de jeux possde un jeu permettant aux enfants de connatre les animaux. Les
enfants peuvent, en particulier, apprendre la forme et le cri des animaux parmi lesquels le
chat et la vache. Le chat est modlis par la classe LeChat possdant au moins les deux
mthodes formeChat() et criChat() et la vache est modlise par la classe LaVache possdant les deux mthodes criVache() et formeVache().
Comme le montrent les noms des mthodes, la premire spcification de ce jeu est propre
aux animaux modliss. Lditeur souhaite amliorer ce jeu en crant une interface commune tous les animaux qui lui permette den ajouter de nouveaux, sans modifier linterface avec le client, et dutiliser le polymorphisme dans la gestion des animaux (manipuler
des troupeaux).
1. Proposez une modlisation des classes pour cette nouvelle version du jeu en faisant
apparatre le client.
2 .On souhaite rutiliser tout le code dvelopp dans la version prcdente. Proposez une
modlisation permettant dincorporer les anciennes mthodes pour viter de les
rcrire.
3. Est-il possible de gnraliser ce raisonnement pour les applications de mme type ? Si
cest le cas, proposez le patron gnrique correspondant.
1. Chaque animal est modlis par une classe : Chat, Vache, etc. Ces classes possdent au
moins les comportements suivants : crier() et forme(). Les mthodes implmentes dans
les diffrentes classes danimaux ont toutes les mmes oprations (mmes signatures de
mthodes). Cela signifie que le client qui utilise un animal na pas besoin de savoir a
priori de quel animal il sagit exactement ; il doit pouvoir accder un ensemble doprations. En ce sens, il suffit de crer une classe gnrale appele Animal, qui regroupe les
oprations communes. Cela permet de traiter tous les animaux de la mme manire, sans
82
UML 2
Chapitre
se soucier des diffrences dimplmentation, et dajouter ultrieurement de nouveaux
animaux sans devoir modifier le client.
Figure 277
Animal{abstract}
+crier():{abstract}
+forme():{abstract}
Client
Gnralisation
des proprits des
animaux dans la
classe Animal, seule
interface avec le
client.
Vache
Chat
+crier()
+forme()
+crier()
+forme()
Lajout dune classe danimaux quelconques doit se faire par drivation de la classe Animal. Cette nouvelle classe doit absolument implmenter les mthodes abstraites de la
classe Animal.
2. Pour pouvoir rutiliser les mthodes dj dveloppes et garder la proprit du polymorphisme, vous devez trouver un moyen dadapter les noms des anciennes mthodes aux
noms gnriques choisis dans la nouvelle version du jeu. Par exemple, pour le cas de la
classe Chat, il suffit de trouver un moyen dappeler les mthodes criChat() et formeChat()
de la classe LeChat. La solution simple qui permet de rsoudre ce problme consiste
mettre la classe LeChat dans la classe Chat. La composition permet la dlgation doprations. Ainsi, la classe Chat se contente tout simplement de dlguer les oprations quon
lui demande la classe LeChat et dutiliser par l mme le code dj dvelopp.
Figure 2.78
La classe LeChat
existante et la
nouvelle classe Chat.
Chat
La mthode crier() se
contentera dappeler la mthode
criChat() de la classe LeChat
+crier()
+forme()
LeChat
+criChat()
1 +formeChat()
Ce processus dencapsulation des classes de lancienne version est dcrit la figure 2.78.
Les classes Chat et

Vache encapsulent
respectivement les
classes LeChat et
LaVache.
Client
Animal{abstract}
+crier()
+ forme()
Chat
+crier()
+forme()
LeChat
+criChat()
+formeChat()
Vache
+crier()
+forme()
Lion
+crier()
+forme()
LaVache
+criVache()
+formeVache()
3. Ce mcanisme dadaptation par encapsulation peut tre utile dans le contexte dutilisation du polymorphisme. Il permet aussi de ne plus se poser de questions sur lintgration
de classes existantes lors de la phase de conception : la solution prsente ici ne prsente
aucune contrainte et peut tre utilise facilement. Il sagit dune instance du patron
Adaptateur .
Exercices
Figure 2.79
La solution gnrique du patron Adaptateur consiste donc faire correspondre une

interface donne un objet existant contenant des mthodes quelconques. En simplifiant
la figure 2.79, vous obtenez la solution gnrique prsente la figure 2.80.
Figure 2.80
Vue simplifie
du patron
Adaptateur .
ClasseCible
+mthode()
Client
Adaptateur
+mthode()
ClasseAdapte
+mthodeAdapte()
+mthode(){
instanceClasseAdapte.mthodeAdapte() ;
}
EXERCICE 21 ORGANISATION
DU LANGAGE
UML
La spcification du langage UML 2 dfinit un type de donnes comme un classeur particulier dans le paquetage Noyau. Un type de donnes est compos de plusieurs proprits et
de plusieurs oprations ordonnes. Un type primitif, comme les entiers, et un type numr
sont deux spcialisations dun type de donnes. Un type numr est compos de littraux
ordonns. Utilisez cette description et vos connaissances de la modlisation des types en
UML pour proposer le modle de classes des types de donnes.
Cette solution est extraite de la norme UML 2.0 superstructure spcification publie par
lOMG.
Figure 2.81
Classifier
Diagramme de
classes dun type
de donnes dans
le mtamodle UML.
DataType
+datatype
0..1
+ownedAttribute
{subsets namespace,
subsets featuringClassifier,
subsets classifier}
+datatype
+ownedOperation
0..1 {subsets namespace,

subsets redefinitionContext,
subsets featuringClassifier}
Property
*
{ordered,
subsets attribute,
subsets ownedMember}
Operation
*
{ordered,
subsets feature,
InstanceSpecification
PrimitiveType
Enumeration
+enumeration
0..1
84
UML 2
{subset namespace}
+ownedLiteral
*
{ordered,
EnumerationLiteral
Chapitre
Diagramme
dinteraction
1. Intrt des interactions ................... 86
2. Diagramme de squence
en dtail ....................................... 91
3. Diagramme de communication
en dtail ..................................... 101
4. Rutilisation dune interaction ...... 104
1. Syntaxe des messages.................. 107
2. Ajouter un aspect dynamique
un diagramme de classes
et traduction dun diagramme
de squence en diagramme
de communication ....................... 109
3. Messages synchrones vs messages
asynchrones ................................ 111
4. Messages perdus, trouvs ou
envoys dans des flots dexcution
parallles .................................... 114
5. Fragments dinteraction combins
pour dcrire une mthode
complexe .................................... 115
6. Oprateurs dinteraction .............. 116
7. Diagrammes de squence
pour illustrer des cas dutilisation .. 117
8. Fragments dinteraction combins . 120
pour illustrer des collaborations .... 121
10. Rutilisation dune interaction ....... 124
pour illustrer les interactions
dans un classeur structur ............. 125
Le diagramme de cas dutilisation montre des acteurs qui

interagissent avec les grandes fonctions dun systme.
Cest une vision fonctionnelle et externe dun systme.
Le diagramme de classes, quant lui, dcrit le cur dun
systme et montre des classes et la faon dont elles sont
associes. Cest une vision statique et structurelle.
Les diagrammes dinteraction permettent dtablir un pont
entre ces deux approches : ils montrent comment des
instances au cur du systme communiquent pour raliser
une certaine fonctionnalit. Les interactions sont nombreuses
et varies. Il faut un langage riche pour les exprimer.
UML propose plusieurs diagrammes : diagramme de
squence, diagramme de communication, diagramme de
timing. Ils apportent un aspect dynamique la modlisation
du systme.
85
(1)
Intrt des interactions

Les diagrammes de cas dutilisation montrent des interactions entre des acteurs et les grandes fonctions dun systme. Cependant, les interactions ne se limitent pas aux acteurs : par
exemple, des objets au cur dun systme, instances de classes, interagissent lorsquils
schangent des messages.
EXEMPLE
Le diagramme de classes prsent la figure 3.1 montre la structure interne dun systme de
pilotage automatique compos des trois classes : PiloteAutomatique, Voiture et Moteur. Ce
diagramme nindique pas comment le pilotage est ralis. Pour ajouter un aspect dynamique
la modlisation, il faut descendre au niveau des instances et montrer comment elles
interagissent.
Des instances de ces classes peuvent figurer sur un diagramme dinteraction particulier,
appel diagramme de communication (figure 3.2). Dans cet exemple, les instances
senvoient les messages dmarrer et allumer. Pratiquement, lenvoi des messages dclenche
lappel des mthodes dmarrer et allumer, ce qui a pour effet de consulter ou de changer
ltat de la voiture et du moteur respectivement.
Plus gnralement, une interaction montre le comportement dun classeur tel quun sous-systme,
un cas dutilisation, une classe, un composant, etc.
Figure 3.1
PiloteAutomatique
Diagramme de
classes dun systme
de pilotage
automatique.
Figure 3.2
Voiture
Moteur
dmarrer()
allumer()
com Piloter
Diagramme de
communication dun
systme de pilotage
automatique.
dmarrer
unPilote : PiloteAutomatique
uneVoiture : Voiture
allumer
leMoteur : Moteur
Dfinition
Une interaction dcrit le comportement dun classeur en se focalisant sur lchange dinformations entre les lments du classeur. Les participants une interaction sont appels
lignes de vie .
Une ligne de vie reprsente un participant unique une interaction.
Le terme ligne de vie est utilis car, souvent, les interactions montrent des objets (instances de classes). Au cours dune interaction, des objets peuvent tre crs, utiliss, et
parfois dtruits. Ce cycle de vie des objets est matrialis par une ligne (la ligne de vie) qui
court dans les diagrammes dinteraction (figure 3.3).
UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme
de squence et celui de communication. Une mme interaction peut tre reprsente aussi
bien par lun que par lautre.
86
UML 2
Chapitre
EXEMPLE
Figure 3.3
Le diagramme de squence de la figure 3.3 et le diagramme de communication de la figure

3.2 reprsentent la mme interaction.
sd Piloter
Un diagramme de
squence la place
dun diagramme
de communication.
unPilote : PiloteAutomatique
sens du
temps
uneVoiture : Voiture
leMoteur : Moteur
dmarrer
allumer
ligne de vie
Diagrammes de squence et de communication peuvent reprsenter la mme interaction,

mais le point de vue est diffrent. Un diagramme de squence met laccent sur le squencement temporel des messages (le temps y figure implicitement et scoule de haut en bas) ; en
revanche, le lien qui unit les lignes de vie, et qui est le vecteur du message, ny figure pas
(alors quil est prsent sur un diagramme de communication).
Dfinition
Les diagrammes de communication et de squence reprsentent des interactions entre des
lignes de vie. Un diagramme de squence montre des interactions sous un angle temporel,
et plus particulirement le squencement temporel de messages changs entre des lignes
de vie, tandis quun diagramme de communication montre une reprsentation spatiale des
lignes de vie.
Remarque
Aux diagrammes de squence et de communication sajoute un troisime type de diagramme dinteraction : le diagramme de timing. Son usage est limit la modlisation des
systmes qui sexcutent sous de fortes contraintes de temps, comme les systmes temps
rel. Cependant, mme dans ces situations extrmes, les diagrammes de squence conviennent bien souvent. Cest la raison pour laquelle les diagrammes de timing ne sont pas
abords dans cet ouvrage. Le lecteur intress trouvera dans le manuel de rfrence dUML
2.0 [Rumbaugh 2004] des explications sur le sujet.
Notation
Un diagramme dinteraction se reprsente par un rectangle (figure 3.4) contenant, dans
le coin suprieur gauche, un pentagone accompagn du mot-cl sd lorsquil sagit dun
diagramme de squence, et de com lorsquil sagit dun diagramme de communication.
Le mot-cl est suivi du nom de linteraction. La liste des lignes de vie qui figurent dans le
diagramme peut suivre le nom de linteraction. Des attributs peuvent tre indiqus prs du
sommet du rectangle contenant le diagramme. La syntaxe de ces attributs est la mme que
celle des attributs dune classe (voir chapitre 2).
Une ligne de vie se reprsente par un rectangle auquel est accroche une ligne ver ticale
pointille. Le rectangle contient un identifiant dont la syntaxe est la suivante :
[<nomDeLaLigneDeVie> [[slecteur]]]: <NomDeClasseur> [dcomposition]
o le slecteur permet de choisir un objet parmi n (par exemple objet[2]).
Diagramme dinteraction 87
Figure 3.4
Un diagramme
de squence dun
distributeur de billets.
Contrainte sur la
valeur de lattribut
Attribut de linteraction
Ligne de vie
sd Retrait argent lifelines :Client, :Distributeur, :Banque

+code : integer { readonly 1000 <= code <= 9999 }
: Distributeur
comBanque : Reseau
Client
introduireCarte
affichercranSaisieCode
saisieCode( code )
vrifierCode( code )
banqueOK = vrifierCode( _ )
1.1 UTILISATION
DES INTERACTIONS
Les diagrammes dinteraction sont utiliss tout au long du cycle de vie dun projet (depuis
le recueil des besoins jusqu la phase de conception). Ils servent dcrire les cas dutilisation dans les phases en amont, modliser la mise en uvre dune classe ou dune opration
dune classe et, plus gnralement, ajouter un aspect dynamique la modlisation dun
systme.
Le diagramme de classes modlise avant tout le domaine dans lequel le systme sera utilis ;
ce domaine, celui dune banque par exemple, est relativement indpendant des applications
bancaires qui viennent se greffer dessus ; limplmentation dun diagramme de classes nest
quune base de dveloppement pour des applications ; ce qui caractrise une application,
cest la faon dont elle utilise le diagramme de classes, ou plus prcisment, comment des
instances des classes interagissent pour raliser les fonctionnalits de lapplication ; sans cet
aspect dynamique, un systme serait purement statique et noffrirait aucune fonctionnalit.
Lapproche objet du dveloppement dun systme recommande une conception modulaire
(de sorte que les parties du systme soient rutilisables). Le langage de modlisation doit
permettre la reprsentation de cette modularit. Il nest pas souhaitable de faire figurer toutes les interactions sur un seul diagramme. Le modlisateur doit pouvoir focaliser son attention sur un sous-ensemble dlments du systme et tudier leur faon dinteragir pour
donner un comportement particulier au systme. UML permet de dcrire un comportement limit un contexte prcis de deux faons : dans le cadre dun classeur structur ou
dans celui dune collaboration.
Interactions dans les classeurs structurs

La structure imbrique dun classeur structur limite les interactions possibles entre ses parties, chacune delles ne pouvant appartenir un autre classeur structur (voir lannexe B
pour de plus amples informations).
88
UML 2
Chapitre
EXEMPLE
Considrons une classe qui est dcompose pour montrer sa structure inter ne (figure 3.5) :
une classe Moteur est compose des classes Allumage et Bougie. Un diagramme de squence
montre comment les bougies et lallumage interagissent pour dmarrer le moteur.
Figure 3.5
Moteur
Un diagramme
de squence
pour illustrer le
comportement
interne dune classe.
sd allumer moteur
interaction
boucle pour
allumer les
bougies
structure interne
de la classe
: Allumage
loop( 1,4)
: Allumage
bougie [ i ] : Bougies
allumer
1..4
: Bougies
Les classeurs structurs sont surtout utiliss dans la phase de conception dun systme,
quand on dtermine la faon dont il va tre ralis. Le concepteur prend pour point de
dpart les classeurs mis en vidence au moment de lanalyse ; il dcide de leur structure
interne et illustre ventuellement leur comportement par des interactions. Les classeurs
ainsi structurs sont repris par les dveloppeurs qui implmentent une solution.
Interactions dans le cadre dune collaboration

Les parties de la structure interne dun classeur structur sont cres ds que le classeur est
instanci. Leur dure de vie est celle de linstance du classeur. Parfois, des instances existent
avant dtre utilises. Elles peuvent tre runies temporairement, le temps de collaborer la
ralisation dune certaine fonctionnalit dun systme. Une fois leur rle jou, leur tche
sachve et la runion est dissoute. Certaines instances devenues obsoltes sont dtruites,
dautres libres jusqu leur prochaine utilisation. Ce type de runion dinstances est une
collaboration.
Dfinition
Une collaboration montre des instances qui collaborent dans un contexte donn pour mettre en uvre une fonctionnalit dun systme.
EXEMPLE
La figure 3.6 montre une collaboration entre instances pour raliser une transaction immobilire.
Notation
Une collaboration se reprsente par une ellipse en trait pointill comprenant deux compartiments. Le compartiment suprieur contient le nom de la collaboration ayant pour syntaxe :
<nomDuRle>[: <NomDuType>][multiplicit]
Le compartiment infrieur montre les participants la collaboration.
Figure 3.6
venteImmobilire
Diagramme
de collaboration
dune transaction
immobilire.
acqureur : Personne
contratVente : Transaction
propritaire : Personne
notaire : Notaire
connecteur
Comme dans les classeurs structurs, des connecteurs relient les instances dune collaboration. Un connecteur reprsente souvent une association transitoire (tablie le temps que
dure la collaboration concrtement, ce peut tre largument dune mthode, une variable
locale, une association).
Notation
Une collaboration peut aussi se reprsenter par une ellipse sans compar timent, portant le
nom de la collaboration en son sein (figure 3.7). Les instances sont relies lellipse par
des lignes qui portent le nom du rle de chaque instance.
Figure 3.7
Reprsentation
possible dune
collaboration.
propritaire
Personne
venteImmobilire
contratVente
Transaction
acqureur
notaire
Notaire
Les interactions au sein dune collaboration peuvent tre reprsentes par un diagramme
dinteraction comme le montre la figure 3.8.
Figure 3.8
Un diagramme
de squence
pour illustrer
une collaboration.
sd venteImmobilire
notaire : Notaire
contratVente : Transaction
propritaire : Personne
tablir
signer
signer
90
UML 2
acqureur : Personne
Chapitre
(2)
Diagramme de squence en dtail

Les principales informations contenues dans un diagramme de squence sont les messages
changs entre les lignes de vie. Un message dfinit une communication particulire entre
des lignes de vie. Plusieurs types de messages existent.
Les plus communs sont :
lenvoi dun signal ;
linvocation dune opration ;
la cration ou la destruction dune instance.
Lenvoi dun signal dclenche une raction chez le rcepteur, de faon asynchrone et sans
rponse : lmetteur du signal ne reste pas bloqu le temps que le signal parvienne au rcepteur et il ne sait pas quand, ni mme si le message sera trait par le destinataire. Un exemple
typique de signal est une interruption (lorsque des donnes sont saisies au clavier dun ordinateur par exemple, le processeur reoit un signal lectrique dinterruption lui donnant
lordre de lire les donnes du clavier, mais la lecture ne bloque pas le clavier).
Plus encore que lenvoi dun signal, linvocation dune opration est le type de message le
plus utilis en programmation objet. Si, par exemple, une classe C possde une opration
op, linvocation se fait par c.op(), o c est une instance de la classe C. Linvocation peut tre
synchrone (lmetteur reste bloqu le temps que dure linvocation de lopration) ou asynchrone. Dans la pratique, la plupart des invocations sont synchrones. Une des techniques
utilises pour raliser une invocation asynchrone consiste crer un thread (un thread est
un flot dexcution parallle) et excuter la mthode associe lopration dans ce thread.
Pour UML, lenvoi dun signal ou linvocation dune opration sont deux sortes de messages
qui se reprsentent de la mme faon. Par contre, UML fait la diffrence entre un message
synchrone et un message asynchrone.
Notation
Un message synchrone se reprsente par une flche lextrmit pleine qui pointe sur le
destinataire du message (figure 3.9). Ce message peut tre suivi dune rponse qui se
reprsente par une flche en pointill.
Un message asynchrone se reprsente par une flche lextrmit ouverte (figure 3.10).
La cration dun objet est matrialise par une flche qui pointe sur le sommet dune ligne
de vie (figure 3.11).
La destruction dun objet est matrialise par une croix qui marque la fin de la ligne de vie
de lobjet (figure 3.12).
Figures 3.9
et 3.10
Reprsentation dun message synchrone (3.9) et dun message asynchrone (3.10).
Figures 3.11
et 3.12
nouvelObjet : Classe
Reprsentation de la cration (3.11) et destruction (3.12).
Lmetteur dun message asynchrone ntant pas bloqu le temps que le message parvienne
au rcepteur, une srie de messages peut tre envoye avant quun seul ne soit reu. De plus,
les messages peuvent tre reus dans un ordre diffrent de lordre denvoi.
EXEMPLE
La figure 3.13 montre une communication sur un rseau dordinateurs (cer tains protocoles de
communication tel UDP ne garantissent pas lordre darrive des messages).
Figure 3.13
sd communication sur un rseau dordinateurs
Messages asynchrones
reus dans un ordre
diffrent de lordre
denvoi.
: Client
: Serveur
question
question
2.1 MESSAGE
ET VNEMENTS
Linvocation dune opration ou lenvoi dun signal peut dclencher une raction chez le
rcepteur. La raction la plus courante est lexcution dune mthode (rappel : une mthode
est limplmentation dune opration). Ce nest cependant pas la seule raction possible. Par
exemple, un signal derreur (souvent appel exception ) peut tre interprt comme une
simple alerte qui ne dclenchera pas ncessairement lexcution dune mthode. Mme
dans le cas de linvocation dune opration, il nest pas vident que linvocation soit suivie
de lexcution dune mthode : dans les middlewares objets qui forment aujourdhui
lossature des systmes dinformations des entreprises, des objets sont rpartis sur un rseau
dordinateurs ; linvocation se fait donc distance et des erreurs de transmission peuvent
empcher le message dinvocation darriver au rcepteur.
UML permet de sparer clairement lenvoi du message de sa rception, ainsi que le dbut de
lexcution de la raction de sa fin. Des vnements sont utiliss pour marquer chaque tape.
Ainsi, la transmission dun message est contrle par loccurrence de deux vnements : un
pour lenvoi et un pour la rception.
EXEMPLE
La figure 3.14 montre un diagramme dinteraction o un message envoy provoque lexcution dune mthode chez le rcepteur.
Figure 3.14
Diagramme
de squence
o figurent,
pour explication,
les occurrences
dvnement.
sd Retrait argent
: Distributeur
vnement denvoi
Client
introduireCarte
vnement de
rception
92
UML 2
vnement de
dbut dexcution
vnement de fin
dexcution
Chapitre
Notation
La spcification de lexcution dune raction se fait par un rectangle blanc ou gris plac
sur la ligne de vie (figure 3.14). Autre notation : un rectangle portant un label.
EXEMPLE
La figure 3.15 spcifie diffremment lexcution de la raction dcrite la figure 3.14.
Figure 3.15
sd Retrait argent
Autre spcification
dune excution.
: Distributeur
vnement
de rception
vnement
denvoi
vnement de
dbut dexcution
introduireCarte
vrifierCarte
vnement de fin
dexcution
Grce aux vnements denvoi et de rception, UML dfinit trois types de messages :
Un message complet est tel que les vnements denvoi et de rception sont connus.
Un message perdu est tel que lvnement denvoi est connu, mais pas lvnement de
rception.
Un message trouv est tel que lvnement de rception est connu, mais pas lvnement
dmission.
Ces diffrents messages se reprsentent de la faon suivante.
Notation
Un message complet se reprsente par une simple flche dirige de lmetteur vers le rcepteur. Un message perdu se reprsente par une flche qui pointe sur une boule noire (figure
3.16). Une flche qui part dune boule noire symbolise un message trouv (figure 3.17).
Figure 3.16
Reprsentation dun
message perdu.
Figure 3.17
Reprsentation dun
message trouv.
2.2 SYNTAXE
DES MESSAGES
UML permet de modliser tout type de systme. Mais bien souvent, les implmentations se
font via des langages de programmation. Dans la plupart des cas, la rception dun message
est suivie de lexcution dune mthode dune classe. Cette mthode peut recevoir des arguments et la syntaxe des messages permet de transmettre ces arguments.
Notation
La syntaxe des messages est :
<nomDuSignalOuDeOpration> [( [<argument>, )]
o la syntaxe des arguments est la suivante :

[ <nomDeParamtre> = ] <valeur de largument>
Par dfaut, les paramtres transmis ne peuvent pas tre modifis par le rcepteur (les arguments sont en entre ). Pour indiquer que des paramtres peuvent tre modifis (argument
en sortie ou en entre/sortie ), il faut crire :
<nomDuParamtreEnSortie> [: <valeur de largument> ]
Quand un message doit transmettre uniquement la valeur des arguments, le caractre - peut
tre utilis en lieu et place de nimporte quel argument pour signifier : valeur indfinie. Le
caractre * peut tre utilis en lieu et place du message complet. Il signifie que tout type de
message est accept.
EXEMPLE
Appeler( "Capitaine Hadock", 54214110 )

afficher( x, y )
initialiser( x = 100 ) est un message dont largument en entre reoit la
valeur 100.
f( x:12 ) est un message avec un argument en entre/sortie x qui prend
initialement la valeur 12.
appeler( "Castafiore", - )
Le rcepteur du message peut aussi vouloir rpondre et transmettre un rsultat via un

message de retour.
Notation
La syntaxe de rponse un message est la suivante :
[<attribut> =] message [: <valeur de retour> ]
o message reprsente le message denvoi.
EXEMPLE
94
UML 2
La figure 3.18 montre un message de rponse signalant que quarante-deux occurrences de la

rfrence Tintin figurent dans une mdiathque.
Chapitre
Figure 3.18
Contrainte sur les valeurs dun attribut
Exemple dun
message de
rponse.
sd Rechercher livre
+nombreLivres : integer { nombreLivres >= 0 }
: Mdiathque
Client
chercher( "Tintin" )
nombreLivres = chercher( "Tintin" ) : 42
2.3 CONTRAINTES
SUR LES LIGNES DE VIE
La figure 3.18 contient un attribut, nombreLivres, auquel est accole une contrainte qui
limite les valeurs possibles du nombre de livres. Les lignes de vie dune interaction peuvent
aussi porter toutes sortes de contraintes. Si la ligne de vie est un objet par exemple, une
contrainte sur la valeur dun attribut peut tre pose.
EXEMPLE
La figure 3.19 montre que, pour dmarrer le moteur dun avion, il est impratif de vrifier le
niveau dessence ; aprs vrification lattribut essence doit avoir une valeur suprieure 0.
Figure 3.19
sd Piloter Avion
Exemple dune
contrainte sur
une ligne de vie.
: Pilote
: Avion
dmarrerMoteur()
Oprateur dassertion qui rend

indispensable lenvoi du message
vrifierEssence (voir le paragraphe
ci-dessous sur les fragments combins)
contrainte
assert
vrifierEssence()
{ Avion.essence > 0 }
dcoller()
Notation
Une contrainte est indique sur une ligne de vie par un texte entre accolades.
Une contrainte peut aussi tre contenue dans une note attache loccurrence de lvnement sur lequel elle agit.
Une contrainte est value au cours de lexcution de linteraction. Si la condition de la

contrainte nest pas vrifie, les occurrences dvnement qui suivent cette contrainte sont
considres comme invalides, alors quune contrainte qui se vrifie rend valides les vnements suivre. Ainsi, la figure 3.19, si la quantit dessence est nulle, dcoller devient un
message invalide.
Remarque
Un diagramme dinteraction peut dcrire des messages non valides, cest--dire qui ne doivent absolument pas tre envoys : dans le cas de la modlisation dune centrale nuclaire
par exemple, il est trs important de prvoir les squences des messages invalides.
2.4 FRAGMENTS DINTERACTION
COMBINS
Les langages de programmation sont limits par leur syntaxe. Certes, ils permettent
dcrire des tests et des boucles trs simplement. Par contre, crire un programme avec des
flots dinstructions devant sexcuter en parallle nest pas simple (il faut crire des instructions pour crer, soit des tches, soit des threads, puis utiliser dautres instructions pour
synchroniser les flots dinstructions). UML, sans tre un langage de programmation,
propose une syntaxe qui se veut complte. Quand le modlisateur doit reprsenter une
situation complexe, UML permet de dcomposer une interaction en fragments suffisamment simples pour les faire tenir sur un schma. La combinaison des fragments permet
de reconstituer la complexit du systme. Le terme gnrique en vigueur pour UML est
fragments combins .
EXEMPLE
La figure 3.20 montre comment reprsenter, laide dUML, lquivalent du test des langages
de programmation.
Figure 3.20
sd Retrait argent
Reprsentation
dun choix dans
un diagramme
de squence.
: Client
: Distributeur
condition
du choix
choixTypeRetrait
( EurosOuDollards )
Oprateur dinteraction
alt
[ EurosOuDollards == Euros ]
affichercranEnFranais
Sparateur doprandes
[ else ]
affichercranEnAnglais
Notation
Un fragment combin se reprsente de la mme faon quune interaction : par un rectangle
dont le coin suprieur gauche contient un pentagone. Dans le pentagone figure le type de
la combinaison (appel oprateur dinteraction ).
la figure 3.20, loprateur dinteraction alt indique que le fragment est un choix. Les deux
options de choix sont appeles oprandes de loprateur alt .
96
UML 2
Chapitre
Notation
Les oprandes dun oprateur dinteraction sont spars par une ligne pointille. Les conditions de choix des oprandes sont donnes par des expressions boolennes entre crochets.
La liste suivante regroupe les oprateurs dinteraction par fonctions :
les oprateurs de choix et de boucle : alternative, option, break et loop ;
les oprateurs contrlant lenvoi en parallle de messages : parallel et critical region ;
les oprateurs contrlant lenvoi de messages : ignore, consider, assertion et negative ;
les oprateurs fixant lordre denvoi des messages : weak sequencing, strict sequencing.
EXEMPLE
La figure 3.21 montre comment une boucle peut tre reprsente. Lexemple illustre la fermeture en boucle de toutes les portes dun train.
Notation
La syntaxe dune boucle est la suivante :
loop [( <minint> [, <maxint> ] ) ]
o la boucle est rpte au moins minint fois avant quune ventuelle condition boolenne
ne soit teste (la condition est place entre crochets sur la ligne de vie) ; tant que la condition est vraie, la boucle continue, au plus maxint fois (minint est un entier suprieur ou gal
0, maxint est un entier suprieur ou gal minit).
loop( valeur ) est quivalent loop( valeur, valeur ).
loop est quivalent loop ( 0, * ), o * signifie illimit .
Figure 3.21
Diagramme de
squence montrant
une boucle.
sd Dmarrer train
: Conducteur
: Train
porte[ i ] : Porte
fermerPortes()
loop(1, n)
fermer()
Loprateur par permet denvoyer des messages en parallle. Ses oprandes se droulent en
parallle. Plus prcisment, les vnements qui jalonnent un oprande (lenvoi du message,
la rception du message) forment une trace. Soumise loprateur par, la trace dun oprande est conserve (lordre des vnements est le mme), mais les diffrentes traces des
diffrents oprandes sentrelacent nimporte comment. En consquence, la trace finale,
obtenue par la fusion des traces des oprandes, peut varier dun droulement lautre. La
figure 3.22 montre un exemple.
Les oprateurs ignore et consider permettent de focaliser lattention du modlisateur sur une
partie des messages qui peuvent tre envoys durant une interaction. Quand de nombreux
messages sont possibles, certains sont importants, dautres moins. Le modlisateur peut
choisir de ne pas tenir compte de tous les messages. Pour un systme en phase de test par
exemple, de nombreux messages servent tester exhaustivement le bon fonctionnement du
systme mais ne seront pas mis lors dune utilisation particulire (quand le systme sera en
production). Loprateur ignore dfinit lensemble des messages ignorer, tandis que loprateur consider dfinit lensemble de ceux quil faut prendre en compte. la figure 3.23, un
oprateur assert sapplique au message fermer. Ce message doit imprativement tre envoy
avant que le train puisse dmarrer.
Figure 3.22
sd
Utilisation de
loprateur par.
:A
:B
par
a
oprandes qui
se droulent
en parallle
EXEMPLE
La figure 3.23 est un exemple dutilisation des oprateurs assert, ignore et consider.
Figure 3.23
sd Dmarrer train, ignore { testerMoteur }, consider{ fermer, dmarrer }
Utilisation des
oprateurs ignore,
consider et assert.
: Conducteur
: Portes
assert
fermer()
dmarrer()
Notation
La syntaxe de loprateur ignore est :
ignore { listeDesNomsDesMessagesIgnorer }
La syntaxe de loprateur consider est :

consider { listeDesNomsDesMessagesConsidrer }
Dans les listes, les messages sont spars par des virgules.
98
UML 2
: Moteur
Chapitre
Loprateur strict sequencing impose que ses oprandes se droulent dans lordre strict de
leur prsentation, cest--dire de haut en bas. Lordre impos ne sapplique qu ses oprandes,
et dventuels fragments imbriqus peuvent avoir, en interne, un squencement quelconque.
EXEMPLE
La figure 3.24 illustre un scnario de dcollage dun avion qui utilise loprateur strict sequencing. Avant de faire dcoller un avion, il faut contrler sa ckeck-list. Le dtail des interactions
pour contrler la check-list et pour faire dcoller lavion nest pas donn. Dautres diagrammes rfrencs sous le label ref sen chargent.
Figure 3.24
sd Dcollage dun avion
Droulement des
oprandes dun
oprateur dans
un ordre strict.
: TourDeContrle
strict
: Pilote
: Avion
ref
Contrler check list
ref
Procdure de dcollage
2.5 DCOMPOSITION DUNE
LIGNE DE VIE
Parfois, une interaction est trop complexe pour tre dcrite sur un seul diagramme. UML
permet de dcomposer volont une ligne de vie sur plusieurs diagrammes.
EXEMPLE
Lexemple suivant modlise un contrle daccs pour entrer dans un btiment. La ligne de vie
SystmeContrleAccs a un comportement complexe dcrit sur un diagramme spar : SystmeContrleAccsUtilisateur (figure 3.26).
Notation
Une dcomposition est rfrence dans le rectangle en tte de ligne de vie, sous le label ref
(figure 3.25).
la figure 3.26, la ligne de vie PointDAccs est dcompose en deux lignes p1 et p2.
Cette notation est une autre manire de dcomposer une ligne de vie dans un diagramme
dinteraction.
On remarque la figure 3.26, la prsence dun message entrant vrifier( code ) et dun
message sortant message( "Entrez!" ) ; ces messages entrent et sortent du diagramme
par un point appel porte . Ces mmes messages sont prsents sur le diagramme de la
figure 3.25.
Dfinition
Une porte est un point de connexion qui permet de relier un mme message reprsent par
des flches diffrentes dans plusieurs fragments dinteraction.
Figure 3.25
Ligne de vie dcompose

sur la figure 3.26
Dcomposition
dune ligne de vie.
sd vrifier accs
+code : integer { 1000 <= code <= 9999 }
: SystmeContrleAccs
ref SystmeContrleAccsUtilisateur
: Utilisateur
vrifier( code )
ref
VrifierAccs( code )
Rfrences des
diagrammes existants
ref
[ code ok ]
message( "Entrez !" )
ref
OuvrirPorte
Figure 3.26
sd SystmeContrleAccsUtilisateur
Ligne de vie
dcompose.
+PointDAccs.code : integer { 1000 <= code <= 9999 }

: PointDAccs
Autre notation
pour la dcomposition
p1
: Contrleur
P2
vrifier( code )
ref
SystmeVrifierAccs( code )
portes
opt
[ code ok ]
message( "Entrez !" )
opt
SystmeOuvrirPorte
100
UML 2
Chapitre
2.6 LES
TATS INVARIANTS
Une ligne de vie peut aussi reprsenter un classeur ayant un comportement complexe. Cest
le cas des instances de classes qui peuvent tre dans plusieurs tats (voir chapitre 4). Il est
possible de placer un certain tat dune machine tats sur une ligne de vie.
Dfinition
Un tat est dit invariant lorsquil reste constant sur une ligne de vie, cest--dire lorsquil
ne change pas quel que soit le contexte dexcution de linteraction.
EXEMPLE
La figure 3.27 montre un tat plac sur une ligne de vie. Au moment de lexcution de linteraction, ltat est test conformment la machine tats spcifie.
Figure 3.27
Ajouter le contrle
de ltat dune
ligne de vie dans
une interaction.
sd Piloter Avion
: Avion
: Pilote
contrler()
AvionPrtAuDcollage
dcoller()
(3)
Diagramme de communication en dtail

Un diagramme de squence montre un squencement temporel des messages (le temps
scoule de haut en bas). Par contre, lorganisation spatiale des participants linteraction
napparat pas. Un diagramme de communication est un autre moyen de dcrire une interaction. Il rend compte des relations entre des lignes de vie qui communiquent. Il reprsente
des interactions du point de vue spatial. Les diagrammes de communication servent le plus
souvent illustrer un cas dutilisation ou dcrire une opration.
EXEMPLE
Le diagramme de la figure 3.28 montre la mise en uvre dune opration (fermerPortes) qui
permet de fermer toutes les portes dun train.
Figure 3.28
com Dmarrer train
Un diagramme de
communication pour
illustrer la fermeture
des portes dun
train.
fermerPortes()
: Train
1 : fermerLesPortes()
1.1 *[i :=1..n] : fermerPorte( i )
connecteur
portes : Portes
ligne de vie
numro de squence
itration
nom de rle
nom de classe
Un diagramme de communication contient des lignes de vie, linstar des diagrammes de

squence : elles reprsentent toujours des participants uniques une interaction, mais les
pointills qui matrialisaient leur dure de vie ont disparu.
Notation
Les lignes de vie sont reprsentes par des rectangles contenant une tiquette dont la syntaxe
est :
<nomDuRle>: <NomDuType>
Au moins un des deux noms doit tre mentionn dans ltiquette (si le nom du rle est omis,
le caractre : est obligatoire).
Le rle permet de dfinir le contexte dutilisation de linteraction. Si la ligne de vie est un

objet, celui-ci peut avoir au cours de sa vie plusieurs rles : une instance dune classe Personne peut jouer le rle dun tudiant dans un contexte donn, et devenir le conducteur
dune voiture un autre moment.
Les diagrammes de communication sont proches des diagrammes de classes auxquels ils
ajoutent un aspect dynamique en montrant des envois de messages. Cependant, les relations entre les lignes de vie sont appeles connecteurs alors quelles se nomment associations dans les diagrammes de classes. Un connecteur se reprsente de la mme faon
quune association mais la smantique est plus large : les associations qui figurent dans un
diagramme de classes reprsentent des relations indpendamment de tout contexte, tandis
que, pour un systme en tat de marche, il est possible de connecter ses lments de nombreuses faons : un objet par exemple, peut tre transmis comme un paramtre une
procdure ou tre une variable locale.
102
UML 2
Chapitre
Les connecteurs peuvent montrer la multiplicit des lignes de vie qui participent une
interaction, comme le montre la figure 3.29.
Figure 3.29
com Dmarrer train
Reprsentation de
la multiplicit dans
un diagramme de
communication.
fermerPortes()
: Train
multiplicit
fermerPorte()
*
porte : Porte
3.1 NUMROS
DE SQUENCE DES MESSAGES
Dans un diagramme de communication, les messages peuvent tre ordonns selon un

numro de squence croissant. Quand plusieurs messages sont envoys en cascade (par
exemple quand une procdure appelle une sous-procdure), ils portent un numro
dembotement qui prcise leur niveau dimbrication. la figure 3.28, le message fermerLesPortes porte le numro 1 et dclenche le message fermerPorte qui porte le numro 1.1.
3.2 MESSAGES
ET FLOTS DEXCUTION PARALLLES
Il est possible denvoyer des messages simultanment dans des flots dexcution qui se
droulent en parallle (dans les applications multitches ou multithreads, plusieurs flots
dinstructions sexcutent en parallle et une mme mthode peut tre excute simultanment dans plusieurs flots). Les flots parallles sont dsigns par des lettres (a, b).
EXEMPLE
Figure 3.30
Envoi dun message
dans des flots
dexcution
parallles.
La figure 3.30 illustre le parcours dun arbre binaire : le message visiter est envoy aux deux
fils (gauche et droit) dun nud pre ; ce message est transmis deux flots parallles portant
les lettres a et b.
com Parcourir nud arbre
visiter()
pre : Nud
1.a, 1.b : visiter()

2
fils : Nud
3.3 OPRATEURS
DE CHOIX ET DE BOUCLE
Les diagrammes de squence permettent de reprsenter divers oprateurs (choix, boucle)

dans des fragments combins. Il nest pas permis dutiliser les fragments combins dans un
diagramme de communication. Malgr tout, des choix et des boucles peuvent y figurer
selon une syntaxe particulire.
Notation
* [ <clause ditration> ] reprsente une itration (figure 3.28). La clause ditration
peut tre exprime dans le format i := 1n.
[ <clause de condition> ] reprsente un choix. La clause de condition est une condition
boolenne.
3.4 SYNTAXE
DES MESSAGES
Notation
La syntaxe complte des messages est (voir les exemples ci-aprs) :
[ <numro_squence> ] [ <expression> ]: <message>
o message a la mme forme que dans les diagrammes de squence, numro_squence

reprsente le numro de squencement des messages tel quil a t dfini prcdemment et
expression prcise une itration ou un embranchement.
EXEMPLE
(4)
2: affiche( x, y ) est un message simple.

1.3.1: trouve("Hadock" ) est un appel embot.
4 [x < 0]: inverse( x, couleur ) est un message conditionnel.
3.1 *[i:=1..10]: recommencer() reprsente une itration.
Rutilisation dune interaction

Une bonne pratique de lapproche objet consiste concevoir un systme en modules qui
pourront tre extraits de leur contexte initial et rutiliss ailleurs. Un langage de modlisation doit permettre de prvoir la rutilisabilit. UML propose les diagrammes de composants pour dcomposer un systme en modules (voir lannexe C). un niveau de dtails
plus fin, il est possible de dcrire compltement une interaction une fois, puis de la rutiliser
volont, en y faisant simplement rfrence. Les diagrammes de squence et les diagrammes de communication peuvent tre rfrencs.
EXEMPLE
104
UML 2
La figure 3.31 montre le travail dun contrleur arien. Un pilote vrifie la check-list de son
avion (le diagramme correspondant appel contrlerCheckList nest pas dcrit en dtail mais
simplement rfrenc). La check-list est transmise en argument car elle est utilise par linteraction contrlerCheckList. Cette interaction retourne un boolen qui est affect lattribut ok de
lavion. Lorsque le contrleur demande contrler lavion, le boolen ok est test. Si lavion
Chapitre
est prt partir, son plan de vol est valid ; dans le cas contraire, le plan de vol est invalid.
Linteraction contrleAvion (dont le nom figure dans le pentagone en haut gauche du diagramme) reoit en argument une instance de CheckList. Cet argument est en entre/sor tie
(inout) car il est utilis dans le diagramme et pourra ser vir encore dans un autre diagramme
qui rfrencera contrleAvion. contrleAvion retourne un rsultat du type PlanDeVol. Linstance correspondante est la ligne de vie appele planDeVol dans le diagramme.
Figure 3.31
Utilisation dune
interaction avec des
arguments et une
valeur de retour.
Argument en entre Rfrence une

/ sortie
interaction existante
Instance du PlanDeVol
retourne
sd contrleAvion( inout checkList : CheckList ) : PlanDevol

+Avion.ok : boolen
: Contrleur
: Pilote
: Avion
checkList : CheckList
planDeVol
ref
:Avion.ok = contrlerCheckList( checkList )
contrler()
alt
[ ok == true ]
valider()
[ ok == false ]
invalider()
Notation
Rutiliser une interaction consiste placer un fragment portant la rfrence ref l o linteraction est utile. La syntaxe complte pour spcifier linteraction rutiliser est la suivante :
[ <nomAttributPourValeurRetour> =] <nom de linteraction>
[( [<argument>], ) ] [: <valeur de retour> ]
La valeur de retour est affecte un attribut. Les arguments peuvent tre en entre (ils portent alors la marque in), en sortie (out), ou en entre et en sortie (inout).
Conclusion
Les diagrammes de squence et de communication montrent laspect dynamique dun systme. Ce ne sont pas les seuls : les diagrammes dactivit et les diagrammes dtats-transitions,
prsents aux chapitres suivants, dcrivent eux aussi un systme sous cet angle. Cependant,
les diagrammes de squence et de communication sont mieux appropris la description
des interactions entre les lments dun systme.
Une interaction montre un comportement typique dun systme dans un contexte donn.
Le contexte est dlimit par un classeur structur ou une collaboration. La vision du systme donne par les diagrammes dinteraction est donc partielle (car limite un contexte
donn) mais cohrente (car elle montre comment un comportement dun systme est ralis par des lments qui le compose). Une interaction peut illustrer un cas dutilisation, le
fonctionnement dun sous-systme, la mise en uvre dune classe ou dune opration. Les
diagrammes dinteraction peuvent tre affins : les interactions dcouvertes lors des phases
en amont du cycle de vie dun projet peuvent tre compltes par les modlisateurs. Chaque
intervenant na pas les mmes exigences et nenvisage pas les mmes interactions de la
mme faon. Malgr ces exigences diffrentes, il est important dassurer une continuit dans
la modlisation. Les diagrammes dinteraction peuvent tre complts mesure que la
modlisation progresse et ports un niveau de dtails requis pour limplmentation du
systme.
Diagrammes de squence et de communication peuvent dcrire une mme interaction mais
de faons diffrentes. Le modlisateur a le choix : les diagrammes de squence montrent le
squencement temporel de messages, tandis que les diagrammes de communication dcrivent
la structure spatiale des participants une interaction.
Arriv ce stade de la lecture du livre, et si vous avez parcouru les chapitres prcdents dans
lordre, vous savez prsent comment construire les trois modles essentiels dun systme :
le modle fonctionnel et externe laide du diagramme des cas dutilisation ;
le modle structurel et interne grce au diagramme des classes ;
le modle des interactions au sein du systme avec les diagrammes de squence et de
communication.
partir de l, vous pouvez passer directement au chapitre 6 pour voir sur une tude de cas
comment tous ces modles sassemblent, ou continuer la lecture des chapitres suivants.
Deux diagrammes supplmentaires y sont prsents :
le diagramme dtats-transitions ;
le diagramme dactivits.
Les diagrammes dtats-transitions sont utiliss avant tout pour dcrire le cycle de vie
des objets dun systme : tout objet est forcment cr un moment donn, utilis via les
mthodes de la classe dont il est issu et, ventuellement, dtruit sil devient inutile. Les diagrammes dactivits sont des organigrammes. Ils montrent les flots de contrle qui grent
les activits dun systme. Ils permettent de modliser tout processus squentiel (un processus de fabrication industriel, le fonctionnement dun systme dinformation, le corps dune
opration).
106
UML 2
Chapitre
Problmes
et exercices
Les diagrammes dinteraction reposent sur la transmission de messages. Avant
dutiliser les interactions, il est ncessaire de matriser la syntaxe des messages, qui
est riche et complexe. Parmi les premiers exercices, certains sont consacrs la
syntaxe, dautres aux diffrents types de messages (synchrone, asynchrone, perdu,
trouv). Plusieurs exercices montrent lquivalence entre les diagrammes de
squence et de communication. Une fois ces notions de base matrises, vous
pourrez raliser les exercices suivants, qui mettent en pratique les diagrammes
dinteraction. Bien souvent, ces diagrammes sont utiliss pour ajouter un aspect
dynamique au modle du diagramme de classes. Le lien entre diagramme de
classes et diagramme dinteraction est illustr par des exercices, tout comme les
autres utilisations des interactions (dcrire un cas dutilisation, une opration, le
comportement dun classeur structur ou dune collaboration). Tout au long des
exemples, il est fait appel aux fragments dinteraction combins, qui permettent
denrichir les modles.
SYNTAXE
DES MESSAGES
1. Expliquez la syntaxe des messages suivants extraits dun diagramme de squence :

f
f( 0 )
f( x )
f( x = 0 )
f( y = x )
f( - )
f( x, y )
*
y = f
y = f( 0 )
y = f( x = 0 )
y = f( x ): 0
Exercices
EXERCICE 1
2. Expliquez la syntaxe des messages suivants extraits dun diagramme de communication :

f
y:= f( x )
1: f
1.1: f
[x>0]: f
*[x>0]: f
*[i:=0..10]: f
1 *[i:=0..10]: f
1.a *[i:=0..10]: f
1. La plupart des messages portent f comme nom.

f est un message sans argument.
f( 0 ) est un message qui reoit en argument la valeur 0.
f( x ) est un message qui reoit la valeur de x en argument.
f( x = 0 ) est un message qui reoit un argument x ayant pour valeur 0.
f( y = x ) est un message ayant un argument y qui prend la valeur de x.
f( - ) est un message avec un argument non dfini.
f( x, y ) est un message qui reoit en arguments les valeurs de x et de y.
* est un message de type quelconque.
y = f est un message de rponse un message f ; la valeur de retour est affecte y.
y = f( 0 ) est un message de rponse un message f( 0 ) ; la valeur de retour est affecte y.
y = f( x = 0 ) est un message de rponse un message f( x = 0) ; la valeur de retour est
affecte y.
y = f( x ): 0 est un message de rponse un message f( x ) ; la valeur de retour 0 est
affecte y.
2. La syntaxe des messages dans les diagrammes de communication est de la forme :
[<numroSquence>] [<expression>]: <message>
o message a la mme syntaxe et la mme signification que dans les diagrammes de

squence.
f est un message sans argument.
y:= f( x ) est un message qui est suivi de lexcution chez le rcepteur dune raction
(par exemple, linvocation dune opration) ; le rsultat de la raction est affect y.
1: f est un message sans argument qui porte le numro de squence 1.
1.1: f est un message embot sans argument qui porte le numro de squence 1.1.
[x>0]: f est un message sans argument qui nest mis que si la condition x > 0 est vraie.
*[x>0]: f est un message sans argument qui est mis tant que la condition x > 0 est vraie.
*[i:=0..10]: f est un message sans argument qui est mis onze fois (pour i allant de
0 10).
1 *[i:=0..10]: f est un message sans argument, portant le numro de squence 1,
qui est mis onze fois (pour i allant de 0 10).
1.a *[i:=0..10]: f est un message sans argument, portant le numro de squence 1,
qui est mis onze fois (pour i allant de 0 10) dans un flot dexcution parallle identifi
par le caractre a.
108
UML 2
Chapitre
EXERCICE 2
AJOUTER
UN ASPECT DYNAMIQUE UN DIAGRAMME DE CLASSES
ET TRADUCTION DUN DIAGRAMME DE SQUENCE EN DIAGRAMME

DE COMMUNICATION
Le diagramme de classes prsent la figure 3.32 modlise un robot qui dispose dun bras
articul se terminant par une pince. Le fonctionnement du robot est le suivant : le robot
dplie son bras, attrape la pice avec sa pince, replie son bras puis relche la pice.
Figure 3.32
Diagramme
de classes
dun robot.
Robot
chercherPice
BrasArticul
Pince
dplier
replier
ouvrir
fermer
1. Reprsentez laide dun diagramme de squence lchange des messages entre les
objets robot, brasArticul et pince.
2. Transformez le diagramme de squence en un diagramme de communication.
3. crivez en pseudo-code les classes Robot, BrasArticul et Pince.
1. Le diagramme de squence est prsent la figure 3.33. Le message chercherPice

parvient au robot via une porte. Lmetteur du message est suppos apparatre dans un
diagramme non reprsent ici. chercherPice entrane lenvoi des messages dplier et
replier au bras articul. Conformment ce qui est stipul dans le rectangle spcifiant
lexcution de la mthode dplier (respectivement replier), le message fermer (respectivement ouvrir) est envoy la pince.
Figure 3.33
sd Attraper pice
Diagramme de
squence du robot.
: Robot
chercherPice
: BrasArticul
: Pince
dplier
fermer
porte
replier
spcifications de lexcution des mthodes
2. Le diagramme de communication (figure 3.34) se dduit aisment du diagramme de

squence prcdent (figure 3.33). Il faut cependant veiller numroter correctement les
messages pour indiquer leur ordre denvoi : le premier message, chercherPice, porte le
numro 1 ; le message suivant, dplier, est embot dans le message chercherPice et porte
Exercices
ouvrir
en consquence le numro 1.1 ; le message fermer (numro 1.1.1) est embot dans le
message dplier. Le mme raisonnement a permis de numroter les messages replier et
ouvrir.
Figure 3.34
com Attraper pice
Diagramme de
communication
quivalent au
diagramme de
squence de la
figure 3.33.
1 : chercherPice()
1.1 : dplier
: Robot
: BrasArticul
1.2 : replier
1.1.1 : fermer
1.2.1 : ouvrir
: Pince
3. Le pseudo-code montre que lobjet brasArticul est inclus dans la partie des attributs de la
classe Robot. Cest la faon la plus courante dimplmenter une relation de composition :
le robot est compos dun bras articul. Il en est de mme des classes BrasArticul et
Pince.
class Robot{
prive:
BrasArticul brasArticul;
publique:
void chercherPice(){
brasArticul.dplier();
brasArticul.replier();
/* objet brasArticul (instance

de la classe BrasArticul) */
/* appel de la mthode dplier

de lobjet brasArticul */
/* appel de la mthode replier
de lobjet brasArticul */
}
}
class BrasArticul {
prive:
Pince pince;
publique:
void dplier (){
pince.fermer();
}
void replier (){
pince.ouvrir();
/* objet pince (instance de

la classe Pince) */
/* instructions pour dplier

le bras */
/* fermeture de la pince pour
attraper la pice */
/* instructions pour replier

le bras */
/* ouverture de la pince pour
relcher la pice */
}
}
class Pince {
prive:
publique:
void fermer (){
110
UML 2
/* instructions pour fermer

la pince */
Chapitre
void ouvrir (){
/* instructions pour ouvrir la pince */
}
Dbut programme principal
Robot robot;
robot.chercherPice();
/* cration dun objet robot

(instance de la classe Robot) */
/* appel de la mthode
chercherPice de la classe Robot */
Fin programme principal
Remarque
Les associations sont souvent implmentes comme des attributs. Il ne faut cependant pas
confondre les deux (voir chapitre 2). Malheureusement, de nombreux langages de programmation ne permettent pas de faire la distinction.
Lannexe E donne des indications pour implmenter un modle objet avec le langage de
programmation Java.
EXERCICE 3
MESSAGES
SYNCHRONES VS MESSAGES ASYNCHRONES
Compltez les messages des figures 3.35 3.39 en choisissant le type de message appropri
(synchrone ou asynchrone).
1. Envoi dun message pour calculer la valeur de la constante pi avec 3 dcimales.
Figure 3.35
Calcul de Pi avec
3 dcimales.
: ProgrammePrincipal
Envoi du message
Message de rponse
: FonctionDeCalculDePi
calculerPI( nombreDcimales = 3 )
PI = calculerPI( nombreDcimales = 3 )
2. Envoi dun message pour calculer la valeur de pi avec 3 000 dcimales.
Figure 3.36
Envoi du message
Message de rponse

Exercices
Calcul de pi avec
3 000 dcimales.
3. Transmission dun courrier lectronique.
Figure 3.37
: metteur
Transmission
dun courrier
lectronique.
: Destinataire
transmettre( message )
4. Transmission dun courrier lectronique via un serveur de messagerie qui rceptionne

les messages et les conserve le temps que le destinataire les rcupre.
Figure 3.38
Transmission
dun courrier
lectronique
via un serveur
de messagerie.
: metteur
: ServeurDeMessagerie
: Destinataire
poster( message )
message = rcuprer
5. Transmission dun courrier lectronique deux destinataires.
Figure 3.39
Transmission dun
courrier deux
destinataires.
: metteur
destinataire1 : Destinataire
1. On considre que le programme principal est actif tout le temps. Le calcul de pi avec
3 dcimales ne doit pas prendre beaucoup de temps. Le programme principal peut donc
tre bloqu par un appel synchrone de la mthode calculerPI le temps deffectuer le calcul
(figure 3.40).
Figure 3.40
objet actif
Calcul de Pi avec
3 dcimales utilisant
un message
synchrone.
objet actif
112
UML 2
objet passif
Chapitre
Remarque
La tte de la ligne de vie ProgrammePrincipal contient deux traits ver ticaux qui indiquent
que lobjet est actif. Le double trait qui court tout au long de la ligne de vie indique aussi un
objet actif. Ces deux notations prsentes simultanment sont redondantes. Dans un diagramme de squence, les deux traits verticaux dans la tte de la ligne de vie sont superflus,
tandis que dans un diagramme de communication, comme aucun pointill nindique la
dure de vie dun objet, ces deux traits sont indispensables (figure 3.48).
Un objet actif possde son propre thread de contrle, cest--dire quon peut lui appliquer
des mthodes dans un flot dexcution indpendant des autres flots dexcution existants.
Un objet passif, au contraire, a besoin quon lui donne un flot de contrle pour lui appliquer une mthode.
2. Calculer Pi avec 3 000 dcimales peut prendre du temps. Dans ce cas, il vaut mieux utiliser un message asynchrone pour ne pas bloquer le programme principal le temps deffectuer le calcul (figure 3.41).
Figure 3.41
Calcul de Pi avec
3 000 dcimales
utilisant un message
asynchrone.

3. La rception dun courrier lectronique peut se faire nimporte quand aprs lmission. Il
ne faut donc pas bloquer lmetteur et utiliser un message asynchrone (figure 3.42).
Figure 3.42
: metteur
Transmission
asynchrone
dun courrier
lectronique.
: Destinataire
4. Lmetteur et le destinataire sont des objets actifs qui sont bloqus le temps denvoyer ou
de rcuprer un courrier (figure 3.43).
Figure 3.43
Transmission
synchrone dun
courrier lectronique
via un serveur de
messagerie.
: metteur
: ServeurDeMessagerie
: Destinataire
poster( message )
5. Les transmissions sont asynchrones et les messages peuvent tre reus dans un ordre
diffrent de lordre denvoi (figure 3.44).
Exercices
message = rcuprer
Figure 3.44
: Destinataire
Transmission dun
courrier deux
destinataires
via des messages
asynchrones.
transme
ttre( me
ssage )
Remarque
La dure de transmission dun message peut tre indique en ajoutant des contraintes sur
un diagramme, comme le montre la figure 3.45.
Figure 3.45
Contraintes de
dure exprimes
sur un diagramme.
: Destinataire
: metteur
transmett
re( mess
{ < 1 jour }
age )
d
{ d - d < 1 jour }
EXERCICE 4
MESSAGES PERDUS, TROUVS

DEXCUTION PARALLLES
OU ENVOYS DANS DES FLOTS
Compltez les messages des figures 3.46 et 3.47 en choisissant le type de message appropri
(perdu, trouv ou sexcutant dans des flots dexcution parallles).
1. Demande dexcution de deux programmes par un systme dexploitation.
Figure 3.46
Demande
dexcution de
programmes.
: SystmeDExploitation
excuter( programme = "lecteur CD" )
excuter( programme = "diteur de texte" )
: Processeur
2. Transmission dun virus un ordinateur.
Figure 3.47
Transmission
dun virus un
ordinateur.
114
UML 2
virus : Virus
: Ordinateur
Chapitre
1. Si le systme dexploitation est considr comme multitche, lexcution des deux programmes se fait simultanment, dans deux flots dexcution parallles nots a et b.
Figure 3.48
objet actif
Envoi simultan
de deux messages.
: SystmeDExploitation
a : excuter( programme = "lecteur CD" )
b : excuter( programme = "diteur de texte" )
: Processeur
2 .La plupart du temps, un ordinateur contamin ne connat pas la source du virus

et lauteur du virus ne souhaite pas tre connu, do lutilisation de messages perdu et
trouv.
Figure 3.49
: Virus
Utilisation de
messages perdu
et trouv.
diffuser( virus )
attraper( virus )
message perdu
message trouv
FRAGMENTS DINTERACTION
COMBINS POUR DCRIRE UNE MTHODE
COMPLEXE
Le programme suivant, crit en pseudo-code, permet de calculer le factoriel dun nombre

n:
int factoriel( int n ){
if( n == 0 ) return 1;
return n * factoriel( n-1);
}
o n 0 et factoriel( 0 ) = 1.
Reprsentez le programme prcdent sur un diagramme de squence.
La solution (figure 3.50) utilise loprateur alternative pour raliser le test sur la valeur de n.
Notez aussi la superposition dune deuxime ligne de vie sur la premire pour matrialiser
lappel rcursif de lopration factorielle. Le nom de la ligne de vie, X, est fictif.
Exercices
EXERCICE 5
: Ordinateur
Figure 3.50
Reprsentation du
calcul de la fonction
factorielle sur un
diagramme de
squence.
sd calcul dun factoriel

+n : integer { n >= 0}
+f : integer
:X
factoriel( n)
[ n == 0 ]
alt
factoriel( n)
[ else ]
factoriel( n-1 )
appel rcursif
f = factoriel( n-1 )
factoriel( n ) : n * f
EXERCICE 6
OPRATEURS DINTERACTION
Dessinez un diagramme de squence qui prsente trois objets : un robot + deux capteurs
(une camra et un dtecteur de chocs). Le diagramme doit contenir un fragment dinteraction qui montre que les capteurs fonctionnent en mme temps (ils peuvent envoyer
tout moment des messages au robot).
Figure 3.51
sd Dplacement dun robot
Utilisation de
loprateur par
pour un problme
de robotique.
: Camra
par
: Robot
: DtecteurChocs
analyserImage( image )
viterObstacle()
116
UML 2
Chapitre
Remarque
Avec loprateur par, la squence des vnements dun oprande peut tre interrompue
par dautres occurrences dvnement venant dautres oprandes. cer tains moments, les
interruptions sont malvenues. Si lon ajoute au robot un pilote et un moteur (figure 3.52), le
pilote a un rle prpondrant et doit pouvoir tout moment demander larrt durgence du
robot. La demande darrt doit tre imprativement suivie de larrt du moteur du robot.
Loprateur critical est utilis pour dfinir une section critique, cest--dire une rgion dune
interaction o les traitements sont atomiques (raliss en un bloc inscable).
Parfois, lentrelacement des vnements provenant de plusieurs oprandes nest pas souhaitable pour tous les participants (les lignes de vie) une interaction. Loprateur seq empche
lentrelacement des occurrences dvnement sur une mme ligne de vie par tage par plusieurs oprandes (cest lordre des oprandes qui fixe le squencement). Lentrelacement
nest possible que sur des lignes de vie diffrentes non soumises loprateur seq.
Figure 3.52
sd Dplacement dun robot
Une rgion o les

oprations sont
atomiques.
: Pilote
: Camra
: Robot
: Moteur
: DtecteurChocs
par
analyserImage( image )
viterObstacle()
critical
arrterDUrgence()
EXERCICE 7
DIAGRAMMES
arrter ()
DE SQUENCE POUR ILLUSTRER DES CAS DUTILISATION
Le diagramme de cas dutilisation prsent la figure 3.53 modlise la gestion simplifie

dune bibliothque.
Figure 3.53
Gestion des emprunts
Bibliothcaire
Le fonctionnement de la bibliothque est le suivant : une bibliothque propose ses adhrents des uvres littraires ; les uvres peuvent tre prsentes en plusieurs exemplaires ;
un adhrent peut emprunter jusqu trois livres.
Exercices
Diagramme de cas
dutilisation dune
bibliothque.
1. crivez laide dun diagramme de squence un scnario nominal demprunt.

2. crivez laide de diagrammes de squence des scnarios demprunt alternatifs et
dexceptions.
1. Pour dcrire un scnario dutilisation dun cas, il faut considrer le systme comme une
bote noire et ne pas chercher montrer des objets au cur du systme. Rappel : un cas
dutilisation est une grande fonction du systme vue par un acteur ; il ne faut donc pas
faire figurer la structure interne dun systme (cest le rle du diagramme de classes). la
figure 3.54, le systme est reprsent par une seule ligne de vie appele Bibliothque.
Figure 3.54
Description dun
scnario nominal
laide dun
diagramme de
squence.
sd gestion des emprunts
: Bibliothque
Bibliothcaire
rechercher un adhrent
adhrent trouv
vrifier si ladhrent peut emprunter
ladhrent peut emprunter
rechercher une uvre
uvre trouve
vrifier sil y a un exemplaire disponible pour cette uvre
Il y a un exemplaire disponible
dcrmenter le nombre dexemplaires dans la bibliothque
attribuer lexemplaire ladhrent
Remarque
Quand un diagramme de squence dcrit un cas dutilisation, le formalisme strict dUML (la
syntaxe des messages par exemple) est plus libre.
La description dun scnario par un diagramme de squence nempche pas de dcrire le
cas sous forme textuelle (voir chapitre 1), ce qui permet de faire figurer des renseignements
supplmentaires (pr- et post-conditions, contraintes).
118
UML 2
Chapitre
2. Le diagramme de la figure 3.55 complte le diagramme prcdent (figure 3.54) en
incluant la vrification de contraintes. Si une contrainte nest pas vrifie, les vnements
qui suivent cette contrainte sont invalides. De plus, la squence doit imprativement se
terminer par les deux messages dcrmenter le nombre dexemplaires dans la bibliothque et attribuer lexemplaire ladhrent cause de lutilisation de loprateur
assert.
Utilisation de
contraintes et de
loprateur assert
dans un diagramme
de squence.
: Bibliothque
Bibliothcaire
rechercher ladhrent
{ adhrent trouv }

{ adhrent peut emprunter }
rechercher une uvre

{ uvre trouve }
vrifier sil y a un exemplaire

disponible pour cette uvre
{ exemplaire disponible }
assert
dcrmenter le nombre
dexemplaires dans la bibliothque
Le formalisme des diagrammes de squence est trs riche. Souvent, il est possible de reprsenter des scnarios de plusieurs faons. Au lieu dutiliser des oprateurs dassertion, il est
possible de recourir des oprateurs dalternative.
Exercices
Figure 3.55
La figure 3.56 prsente une troisime solution qui utilise un oprateur doption (loprateur
doption opt est identique un oprateur dalternative, mais avec un choix unique).
Figure 3.56
Utilisation des
oprateurs opt
et neg.
: Bibliothque
Bibliothcaire
rechercher ladhrent
opt
[ adhrent non trouv ]
neg
rechercher une uvre

La figure 3.56 utilise loprateur negative pour indiquer que les messages sur lesquels il
sapplique sont invalides.
EXERCICE 8
FRAGMENTS DINTERACTION
COMBINS
Construisez un diagramme de squence ayant trois lignes de vie : Conducteur, Train et

Passager.
Comment interdire aux passagers douvrir les portes quand le train a dmarr ?
La solution utilise loprateur negative pour interdire louverture des portes (figure 3.57).
120
UML 2
Chapitre
Figure 3.57
sd Conduire Train
Utilisation de
loprateur negative
pour interdire
louverture des
portes dun train.
: Conducteur
: Train
: Passager
dmarrer()
neg
ouvrirPorte()
EXERCICE 9
DIAGRAMMES
DE SQUENCE POUR ILLUSTRER DES COLLABORATIONS
Lexercice 7 montre comment utiliser des diagrammes de squence pour dcrire des cas
dutilisation. Lexercice 9 prolonge lexemple de la bibliothque en partant de lhypothse
quun diagramme de classes a t construit (figure 3.58). Le but prsent est de montrer
comment des objets au cur du systme interagissent pour raliser les fonctions des cas
dutilisation.
Le diagramme de classes prsent la figure 3.58 modlise la structure interne de la bibliothque. Un adhrent peut emprunter un exemplaire dune uvre donne. Lemprunt se
fait de la faon suivante : lopration emprunter de la classe uvre est invoque pour un
adhrent donn en argument ; sil reste des exemplaires dans la bibliothque, lun des
exemplaires associs luvre est extrait via la mthode extraireExemplaire, une instance
de la classe Prt est cre, puis lexemplaire extrait de la bibliothque est attribu ladhrent grce linvocation de lopration attribuer.
Figure 3.58
Diagramme de
classes dune
mdiathque.
Prt
date
Adhrent
attribuer( Exemplaire )
Exemplaire
0..3
emprunte
uvre
1..n
extraireExemplaire() : Exemplaire
emprunter( Adhrent )
Exercices
1. Parmi les classes du diagramme prcdent (figure 3.58), donnez la liste de celles qui
permettent de raliser le comportement entour par un cercle dans le diagramme de
squence prsent la figure 3.59.
Figure 3.59
Diagramme de
squence de
lemprunt dun
livre.
: Bibliothque
Bibliothcaire
adhrent trouv
rechercher une oeuvre
uvre trouve
Il y a un exemplaire disponible
2. Dessinez une collaboration montrant des instances des classes trouves la question 1.
3. Reprsentez les interactions au sein de la collaboration laide dun diagramme de
squence.
1. Les classes impliques sont Exemplaire, uvre, Adhrent et Prt.

La classe Prt nest pas mentionne dans le diagramme de squence, et pourtant elle est
incluse dans la liste. Cest une classe dassociation prsente dans le diagramme de classes.
Une instance de la classe Prt doit tre cre au moment de lemprunt.
2. Des instances des classes Exemplaire, uvre, Adhrent et Prt sont runies dans une
collaboration (figure 3.60). Rappel : les liens entre les instances sont des connecteurs qui
reprsentent des associations transitoires tablies le temps que dure la collaboration.
Parmi les connecteurs, on retrouve les associations du diagramme de classes. En plus,
un nouveau lien apparat entre les instances dAdhrent et duvre afin de matrialiser
la transmission dun adhrent comme argument de lopration emprunter de la classe
uvre.
122
UML 2
Chapitre
Figure 3.60
Diagramme de
collaboration pour
lemprunt dun
exemplaire.
Argument
dune opration
Attribution dun exemplaire un adhrent
uvreTrouve : uvre
adhrentTrouv : Adhrent
exemplaireDisponible : Exemplaire
: Prt
associations
3 .Le diagramme de squence est prsent la figure 3.61. Linteraction est dcompose en
fragments combins qui utilisent loprateur alternative : le choix porte sur la prsence
ou non dun exemplaire disponible dans la mdiathque. Notez la cration dune instance de la classe Prt matrialise par un message qui pointe sur la tte de la ligne de vie.
Figure 3.61
sd AttributionExemplaireAAdhrent( inout adhrentTrouv : Adhrent, inout uvreTrouve : uvre )
Diagramme de
squence pour
lemprunt dun
exemplaire.
+uvre.nombreExemplaires : integer { nombreExemplaires >= 0}
uvreTrouve: uvre
exemplaireTrouv : Exemplaire
adhrentTrouv : Adhrent
emprunter( adhrentTrouv )
[ nombreExemplaires > 0 ]
alt
extraireExemplaire() : Exemplaire
: Prt
attribuer( exemplaireTrouv )
emprunter : ok
[ else ]
emprunter : non ok
Le formalisme des diagrammes de squence est trs proche de celui des langages de programmation (on peut reprsenter aisment des tests, des boucles). Les diagrammes de
squence sont principalement utiliss durant la phase danalyse. Cette tape ne doit pas
tre confondue avec les phases de conception et dimplmentation. Durant lanalyse, les
interactions servent souvent valider un diagramme de classes (en montrant comment des
instances de classes interagissent). Veillez ne pas faire ce moment-l des choix de
conception ou dimplmentation (voir chapitre 6).
Exercices
Remarque
La cration dune instance dans un diagramme de communication peut tre matrialise

par une contrainte, comme le montre la figure 3.62.
Les contraintes {dtruit} et {transitoire} peuvent tre places sur des liens ou sur des objets
pour indiquer leur destruction ou bien quils sont temporaires.
Figure 3.62
com emprunter
Reprsentation de la
cration dun objet
et dun lien dans
un diagramme de
communication.
emprunter()
: uvre
EXERCICE 10 RUTILISATION DUNE
{ nouveau }
: Prt
INTERACTION
Le diagramme de squence de lexercice 9 (figure 3.61) reprsente la fin du scnario nominal de lemprunt (partie entoure par un cercle dans le diagramme de la figure 3.59). Supprimez la partie encercle du scnario nominal et indiquez comment vous pouvez
rutiliser le diagramme de squence de la figure 3.61 la place.
Figure 3.63
Diagramme de
squence qui
rfrence une
interaction.
: Bibliothque
Bibliothcaire
adhrent trouv
rechercher une uvre
uvre trouve
ref
AttributionExemplaireAAdhrent( adhrentTrouv, uvreTrouve )
124
UML 2
Chapitre
EXERCICE 11 DIAGRAMMES
DE SQUENCE POUR ILLUSTRER LES INTERACTIONS DANS
UN CLASSEUR STRUCTUR
Au moment de la conception dun systme, le concepteur part du rsultat de lanalyse (qui

a dfini ce que doit faire le systme), et cherche comment raliser ce systme. Il procde
par dcompositions successives des classes pour dfinir les structures de donnes sousjacentes. Le but de cet exercice est dutiliser les classeurs structurs dUML pour dcomposer une classe, puis dillustrer les interactions entre les lments dun classeur structur
par un diagramme de squence.
Une file est une structure de donnes dans laquelle les donnes sont ajoutes la fin et
extraites partir du dbut. La file est modlise par une classe possdant les oprations
ajouter et extraire (figure 3.64).
Figure 3.64
Une classe
reprsentant
une file.
File
ajouter( Donne )
extraire() : Donne
Un classeur structur peut tre utilis pour montrer la structure interne de la file (figure
3.65). Le concepteur choisit dimplmenter la file en recourant un tableau (une file est un
tableau dans lequel on a restreint les accs aux deux extrmits). Afin de dcrire le comportement du tableau lors de lextraction dun lment, le concepteur dcide dutiliser une
interaction appele Extraire de la file.
Figure 3.65
La file vue comme
un classeur
structur.
File
ref
Extraire de la file
: Tableau
Reprsentez linteraction Extraire de la file laide dun diagramme de squence. Indication : la faon la plus simple dextraire le premier lment dun tableau est de mmoriser la
valeur de celui-ci avant de dcaler les lments suivants, comme le montre la figure 3.66.
Extraire le premier
lment dun
tableau.
mmoriser
Exercices
Figure 3.66
La solution est prsente la figure 3.67, o une boucle est utilise pour raliser le dcalage.
Les oprations add et get permettent dajouter et dextraire un lment du tableau.
Figure 3.67
Un diagramme
de squence pour
illustrer lextraction
du premier lment
dune file.
sd extraire de la file
premier : Exemplaire
suivant : Exemplaire
: File
: Tableau
extraire()
get( 0 )
premier = get( 0
loop(1, n)
prcdent = get( 0 )
add(prcdent, i )
extraire() : premier
126
UML 2
Chapitre
Diagramme
dtats-transitions
1. Modlisation laide
dautomates .........................
2. Hirarchie dans les machines
tats .................................
3. Contrat de comportement .......
4. Gestion de la concurrence ......
1. Diagramme dtats-transitions
dun individu du point de vue
de lINSEE ............................
dune porte...........................
dune montre chronomtre .....
4. Modlisation de la socket TCP...
Les diagrammes dtats-transitions (ou statecharts) dUML

128
dcrivent le comportement interne dun objet laide dun
133
138
139
automate tats finis. Ils prsentent les squences possibles

dtats et dactions quune instance de classe peut traiter au
cours de son cycle de vie en raction des vnements
discrets (de type signaux, invocations de mthode).
142
143
145
148
Ils spcifient habituellement le comportement dune instance

de classeur (classe ou composant), mais parfois aussi le
comportement interne dautres lments tels que les cas
dutilisation, les sous-systmes, les mthodes. Ils sont bien
adapts la description dobjets ayant un comportement
dautomate. Cependant, la vision globale du systme est
moins apparente sur ces diagrammes, car ils ne sintressent
qu un seul lment du systme indpendamment
de son environnement. Les diagrammes dinteractions
(voir chapitre 3) permettent de lier les parties du systme
entre elles.
127
(1)
Modlisation laide dautomates
1.1 TAT
Un diagramme dtats-transitions est un graphe qui reprsente un automate tats finis,
cest--dire une machine dont le comportement des sorties ne dpend pas seulement de
ltat de ses entres, mais aussi dun historique des sollicitations passes : cet historique est
caractris par un tat.
Ainsi, leffet dune action sur un objet dpend de son tat interne, qui peut varier au cours
du temps. Par exemple, considrez une lampe munie de deux boutons-poussoirs : une pression sur On allume la lampe et une pression sur Off lteint. Une pression sur On ne produit
pas deffet si la lampe est dj allume ; la raction dune instance de Lampe cet vnement
dpend de son tat interne.
EXEMPLE
La lampe
Cet exemple simple prsente la notion dtat et leffet des invocations en fonction de ltat
courant.
Figure 4.1
Un diagramme
dtats-transitions
simple.
allume
Off
On
On
teinte
Off
Les tats sont reprsents par des rectangles aux coins arrondis, tandis que les transitions
sont reprsentes par des arcs orients liant les tats entre eux. Certains tats, dits composites , peuvent contenir des sous-diagrammes. UML offre galement un certain nombre de
constructions la smantique particulire, telles que lhistorique, qui permet de retrouver
un tat prcdent, les points de choix, qui permettent dexprimer des alternatives, ou
encore un moyen dexprimer des mcanismes concurrents.
EXEMPLE
Fentre dapplication
Le diagramme de la figure 4.2 prsente le comportement simplifi dune fentre dapplication, qui rpond aux stimuli de trois boutons placs dans langle. Une fentre peut tre dans
trois tats : rduite, normale, agrandie. Lorsquelle est rduite, elle est reprsente par une
icne dans la barre des tches. ltat normal, elle peut tre dplace et redimensionne.
Lorsquelle est agrandie, elle occupe toute la surface disponible de lcran et ne peut tre
dplace ou redimensionne. Les arcs portent une tiquette indiquant le nom de lvnement
qui dclenche la transition associe. Ltat initial (Init 1 et Init 2 ici), not par un cercle plein,
dsigne le point dentre du diagramme ou du sous-diagramme. Une nouvelle instance de
fentre sera initialise ltat cre, dans le sous-tat ouverte et dans le sous-tat normale. Le
pseudo-tat historique, dsign par un H dans un cercle, permet de retrouver la fentre son
tat prcdent (normale ou agrandie) quand on quitte ltat rduite. Ltat final, dsign par
un point dans un cercle correspond la fin de vie de linstance et sa destruction.
128
UML 2
Chapitre
Figure 4.2
cre
Le comportement
dune fentre
dapplication.
ouverte
maximiser()
Init 1
normale
agrandie
Init 2
maximiser()
positionner()
dimensionner()
minimiser()
Final
H
minimiser()
rduite
1.2 VNEMENT
La vue propose par les diagrammes dtats-transitions met en vidence les ractions dune
partie du systme des vnements discrets. Un tat reprsente une priode dans la vie
dun objet dans laquelle ce dernier attend un vnement ou accomplit une activit. Quand
un vnement est reu, une transition peut tre dclenche qui va faire basculer lobjet
dans un nouvel tat.
Les transitions dun diagramme dtats-transitions sont donc dclenches par des vnements, appels dclencheurs ou triggers. La notion dvnement est assez large en UML :
Un appel de mthode sur lobjet courant gnre un vnement de type call.
Le passage de faux vrai de la valeur de vrit dune condition boolenne gnre implicitement un vnement de type change.
La rception dun signal asynchrone, explicitement mis par un autre objet, gnre un
vnement de type signal.
Lcoulement dune dure dtermine aprs un vnement donn gnre un vnement
de type after. Par dfaut, le temps commence scouler ds lentre dans ltat courant.
La fin dune activit de type do/, interne un tat gnre implicitement un vnement
appel completion event. Cela peut dclencher le tir des transitions dites automatiques , qui ne portent pas de dclencheur explicite.
Un vnement de type call ou signal est dclar ainsi :
nom-vnement ( liste-paramtres )
o chaque paramtre a la forme :

nom-paramtre : type-paramtre
Les vnements de type call sont donc des mthodes dclares au niveau du diagramme de
classes. Les signaux sont dclars par la dfinition dune classe portant le strotype signal,
ne fournissant pas doprations, et dont les attributs sont interprts comme des arguments.
Un vnement de type change est introduit de la faon suivante :
when ( condition-boolenne )
Diagramme dtats-transitions 129
Notation et spcification (suite)

Il prend la forme dun test continu et se dclenche potentiellement chaque changement de
valeurs des variables intervenant dans la condition.
Un vnement temporel de type after est spcifi par :
after ( paramtre )
o le paramtre svalue comme une dure, a priori coule depuis lentre dans ltat courant. Par exemple : after(10 secondes) ou after(10 secondes aprs lentre dans ltat A).
Vous pouvez aussi spcifier un dclencheur li une date prcise par une clause when( ),
par exemple when(date=1 janvier 2000).
Les dclarations dvnement ont une porte de niveau paquetage et peuvent tre utilises
dans tout diagramme dtats-transitions des classes du paquetage. Leur porte nest en
aucun cas limite une classe.
Particularits des vnements de type signal

Un signal est un message mis de faon asynchrone, cest--dire que lappelant peut poursuivre son excution sans attendre la bonne rception du signal. Ce type de communication
a un sens uniquement lorsque plusieurs processus ou objets actifs sont en concurrence, en
particulier lorsque linstance cible est munie dun flot de contrle indpendant de celui de
lappelant. Lutilisation de signaux la place de mthodes peut accrotre les possibilits
de concurrence et permet de modliser certains types de communications matrielles
(interruptions matrielles, entres/sorties) ou en mode dconnect (le protocole UDP sur
IP par exemple). Lmission et la rception dun signal constituent donc deux vnements
distincts.
EXEMPLE
Dclaration de signaux
la figure 4.3, trois signaux sont dclars comme des classes du paquetage et peuvent tre
lis entre eux par des relations dhritage. Si le signal A drive du signal B, il dclenche par
transitivit toutes les activits lies B en plus des siennes propres. Les attributs de classe sont
interprts comme les arguments de lvnement de type signal.
Figure 4.3
signal
Interruption E/S
Dclarations de
signaux et hritage.
+pripherique :int
signal
Souris
+posx:int
+posy:int
130
UML 2
signal
Clavier
+caractre: int
Chapitre
1.3 TRANSITION
SIMPLE
Une transition entre deux tats simples E1 et E2 est reprsente par un arc qui les lie lun
lautre. Elle indique quune instance dans ltat E1 peut entrer dans ltat E2 et excuter certaines activits, si un vnement dclencheur se produit et que les conditions de garde sont
vrifies. On parle de tir dune transition quand elle est dclenche.
Notation
Une transition dun diagramme dtats-transitions est reprsente par un arc plein, liant un
tat dit source un tat cible . Elle est dote dune tiquette contenant une expression de la forme :
nom-vnement ( liste-param-vnement ) [ garde ] / activit
o les paramtres ventuels de lvnement sont spars par des virgules, la garde (par
dfaut vraie) dsigne une condition qui doit tre remplie pour pouvoir dclencher la transition, et lactivit exprime dans une syntaxe laisse libre dsigne des instructions effectuer
au moment du tir.
Le dclencheur de la transition est un vnement de type call, signal, change ou after, ou
nest pas spcifi pour les transitions automatiques (voir la section vnement ). Lvnement peut porter des paramtres, visibles dans les activits associes la transition ainsi
que dans lactivit exit de ltat source et lactivit entry de ltat cible. Les vnements
entrants sont traits squentiellement. Si aucune transition nest dclenche par lvnement, il est dtruit. Si une transition est dclenche, sa garde est value ; celle-ci est exprime en fonction des variables dinstance et ventuellement de tests dtat des instances
dobjet accessibles (par exemple, obj1 in tat1 ou obj1 not in tat1) ; si elle est
fausse, lvnement est dtruit. Si plusieurs transitions sont simultanment franchissables,
lune dentre elles est choisie de faon arbitraire.
1.4 POINT
DE DCISION
Il est possible de reprsenter des alternatives pour le franchissement dune transition. On
utilise pour cela des pseudo-tats particuliers : les points de jonction (reprsents par un
petit cercle plein) et les points de choix (reprsents par un losange).
Les points de jonction sont un artefact graphique qui permet de partager des segments de
transition. Plusieurs transitions peuvent viser et/ou quitter un point de jonction. Tous les
chemins travers le point de jonction sont potentiellement valides. On peut donc reprsenter un comportement quivalent en crant une transition pour chaque paire de segments
avant et aprs le point de jonction. Lintrt est de permettre une notation plus compacte et
de rendre plus visibles les chemins alternatifs.
EXEMPLE
quivalences de reprsentation
Les deux reprsentations des figures 4.4 et 4.5 sont quivalentes.
Lutilisation des points de jonction rend les diagrammes plus lisibles.
Figure 4.4
Utilisation de points
de jonction.
[b>0]
tat1
tat3
e1[a>0]
[b=0]
e2[a>0]
tat2
tat4
tat5
[b<0]
Figure 4.5
Equivalence avec
des transitions
gardes.
e1[a>0 and b<0]

tat1
e1[a>
0 and
e1[
a>0
and
tat3
b=0]
b>0
]
tat4
nd
0a
b<0
a>
e2[
0 and
e2[a>
b=0]
tat2
tat5
0]
e2[a>0 and b>
Cette quivalence avec une reprsentation par plusieurs transitions implique que, pour que
lon puisse emprunter un chemin, toutes les gardes le long de ce chemin doivent svaluer
vrai ds le franchissement du premier segment. Les points de jonction ne constituent donc
quun sucre syntaxique, sans smantique particulire.
On dispose galement du point de choix dit dynamique , reprsent par un losange. Au
contraire dun point de jonction, les gardes aprs ce point de choix sont values au moment
o il est atteint. Cela permet en particulier de baser le choix sur des rsultats obtenus en
franchissant le segment avant le point de choix. Si, quand le point de choix est atteint, aucun
segment en aval nest franchissable, le modle est mal form. Au contraire, si plusieurs
segments sont franchissables, on suit la rgle habituelle : quand plusieurs transitions sont
simultanment franchissables, lune dentre elles est choisie alatoirement.
EXEMPLE
Point de choix dynamique

Un formulaire en ligne est rempli par un utilisateur. Quand il valide son formulaire en
appuyant sur le bouton go, une vrification de la cohrence des donnes fournies est ralise
par validerEntre(). Si les informations paraissent correctes, on lui demande de confirmer,
sinon on affiche les erreurs dtectes et il doit remplir de nouveau le formulaire. Notez que la
validation se fait sur le segment avant le point de choix. Ce fonctionnement ne peut tre dcrit
par un simple point de jonction.
Figure 4.6
Utilisation dun
point de jonction.
saisie
formulaire
go/validerEntre()
[entre valide]
[else]
afficher
problmes
132
UML 2
demander
confirmation
Chapitre
Il est possible dutiliser une garde particulire sur un des segments aprs un point de choix
ou de jonction en introduisant une clause [else]. Ce segment nest franchissable que si les
gardes des autres segments sont toutes fausses. Lutilisation dune clause [else] est recommande aprs un point de choix car elle garantit un modle bien form.
Si lon utilise un point de jonction pour reprsenter le branchement dune clause conditionnelle, il est conseill dutiliser galement un point de jonction pour faire apparatre la fin du
branchement et tre homogne.
EXEMPLE
Point de jonction reprsentant des alternatives

Le point de jonction est bien adapt la reprsentation de clauses conditionnelles de type
if/endif.
Figure 4.7
associer client et commande
Deux points de
jonction pour
reprsenter des
alternatives.
[client trouv]
chercher client
[client non trouv]
(2)
/afficher
numero client
associer client
crer client
Hirarchie dans les machines tats
2.1 TAT
ET TRANSITION INTERNE
Un tat est une priode dans la vie dun objet o il vrifie une condition donne, excute
une certaine activit, ou plus gnralement attend un vnement. Conceptuellement, un
objet reste donc dans un tat durant une certaine dure, au contraire des transitions qui
sont vues comme des vnements ponctuels (sauf dans le cas particulier o la transition
dclenche elle-mme un traitement).
Un tat peut tre dcompos en deux compartiments spars par une barre horizontale. Le
premier compartiment contient le nom de ltat, le second contient les transitions internes
de ltat, ou activits associes cet tat. Vous pouvez omettre la barre de sparation en
labsence de transitions internes. Une transition interne ne modifie pas ltat courant, mais
suit globalement les rgles dune transition simple entre deux tats. Trois dclencheurs
particuliers sont introduits permettant le tir de transitions internes : entry/, do/, et exit/.
EXEMPLE
Figure 4.8
La saisie dun mot
de passe.
Reprsentation dun tat simple

saisie mot de passe
entry/ set echo invisible
character/ traiter cararctre
help/ afficher aide
exit/ set echo normal
Notation
La syntaxe de la dfinition dune transition interne est la suivante :
Nom-vnement (liste-paramtres) [garde] / activit--raliser
Le nom de lvnement peut tre celui dune mthode de lobjet auquel appar tient ltat,
dun vnement dclar comme tel au niveau paquetage, ou un des mots-cls rser vs
suivants :
entry dfinit une activit effectuer chaque fois que lon rentre dans cet tat.
exit dfinit une activit effectuer quand on quitte cet tat.
do dfinit une activit continue qui est ralise tant que lon se trouve dans cet tat, ou
jusqu ce que le calcul associ soit termin. On pourra dans ce dernier cas grer lvnement correspondant la fin de cette activit (completion event).
include permet dinvoquer un sous-diagramme dtats-transitions.
La liste des paramtres (optionnelle) correspond aux arguments de lvnement dclencheur de lactivit. La condition dactivation, ou garde, est une condition boolenne qui
permet dautoriser ou non le dclenchement de lactivit. La faon de spcifier lactivit
raliser est laisse libre. En gnral, on utilise le langage naturel pour dcrire lactivit
entreprendre, ou du pseudo-code mentionnant les arguments de lvnement dclencheur.
On peut galement utiliser une rfrence vers un autre diagramme (activit ou collaboration) pour dcrire ce traitement.
Une transition interne se distingue dune transition reprsente par un arc qui boucle sur
ltat, car lors de lactivation dune transition interne, les activits entry et exit ne sont pas
appeles (on ne quitte pas ltat courant). Implicitement, tout diagramme dtats-transitions est contenu dans un tat externe qui nest usuellement pas reprsent. Cela apporte
une plus grande homognit dans la description : tout diagramme est implicitement un
sous-diagramme.
2.2 TAT
COMPOSITE
Un tat composite, par opposition un tat dit simple , est graphiquement dcompos
en deux ou plusieurs sous-tats. Tout tat ou sous-tat peut ainsi tre dcompos en soustats enchans sans limite a priori de profondeur. Un tat composite est reprsent par les
deux compartiments de nom et dactions internes habituelles, et par un compartiment
contenant le sous-diagramme.
EXEMPLE
Combin tlphonique
Cet exemple prsente les tapes de laction composer numro. lentre dans ltat composite (par exemple suite une action dcrocher), une tonalit sonore annonce que le tlphone
est prt pour la composition du numro. Les chiffres sont saisis un par un suite lappel de
lopration chiffrer. La transition automatique de numroter vers ltat final est franchie ds
que sa garde devient vraie.
134
UML 2
Chapitre
Figure 4.9
Composer numro
Composition
dun numro
et transitions
automatiques.
Dbut
entry/tonalit prt
exit/ cesser tonalit
Numroter
[numro.valide()]
entry/numero.append(n)
chiffrer(n)
chiffrer(n)
Un nouvel objet est cr dans ltat initial le plus externe du diagramme et franchit la transition par dfaut qui en part. Un objet qui atteint ltat final le plus externe est dtruit. Ces
transitions peuvent tre accompagnes dune tiquette qui indique un vnement correspondant au constructeur ou destructeur dinstance, et ventuellement associes une activit.
Une transition qui atteint ltat final dun sous-diagramme correspond la fin de laction
associe ltat lencapsulant. La fin dune activit interne dun tat peut tre associe au
dclenchement dun changement dtat, reprsent par une transition sans tiquette qui
quitte ltat externe courant. On parle alors de transition automatique, dclenche par un
vnement implicite de terminaison (completion event). Un completion event est galement
dclench par la fin dune activit interne de type do/.
Lutilisation dtats composites permet de dvelopper une spcification par raffinements. Il
est parfois souhaitable de ne pas reprsenter les sous-tats chaque utilisation de ltat
englobant. Vous pouvez noter graphiquement le fait quun tat est composite et que sa
dfinition est donne sur un autre diagramme.
EXEMPLE
Notation abrge des tats composites
Figure 4.10
Composer
numro
Reprsentation compacte
dun tat composite.
2.3 TRANSITION
ET TAT COMPOSITE
Les transitions peuvent avoir pour cible la frontire dun tat composite et sont alors quivalentes une transition ayant pour cible ltat initial de ltat composite. De mme, une
transition ayant pour source la frontire dun tat composite est quivalente une transition qui sapplique tout sous-tat de ltat composite source. Cette relation est transitive :
la transition est franchissable depuis tout tat imbriqu, quelle que soit sa profondeur. Si la
transition ayant pour source la frontire dun tat composite ne porte pas de dclencheur
explicite (en dautres termes, si elle est dclenche par un completion event), elle est franchissable quand ltat final de ltat composite est atteint.
Par exemple, la transition minimiser de la fentre dapplication est franchissable depuis les
tats normale et agrandie (voir figure 4.2).
Les transitions peuvent galement toucher des tats de diffrents niveaux dimbrication, en
traversant les frontires des tats.
Dans tous les cas, avant lentre dans un tat (respectivement la sortie), les activits entry/
(respectivement exit/) sont ralises. En cas de transition menant vers un tat imbriqu, les
activits entry/ de ltat englobant sont ralises avant celles de ltat imbriqu. En cas de
transition depuis la frontire de ltat englobant, les activits exit/ du sous-tat actif sont
ralises, puis celles de ltat englobant le sont leur tour.
EXEMPLE
Ordre dappel
Depuis ltat tat11, la rception de lvnement event1 provoque la squence dactivits
QuitterE11, QuitterE1, action1, EntrerE2, EntrerE21, initialiser, EntrerE22, et place le systme
dans ltat tat22.
Figure 4.11
tat2
Ordre des actions

dans un cas
complexe.
tat 1
tat21
tat22
tat11
exit/QuitterE11
exit/QuitterE1
event1/action1
initialiser() entry/EntrerE22
entry/EntrerE21
entry/EntrerE2
2.4 HISTORIQUE
ET TAT COMPOSITE
Chaque rgion ou sous-diagramme dtats-transitions peut avoir un pseudo-tat historique, not par un cercle contenant un H. Une transition ayant pour cible le pseudo-tat historique est quivalente une transition qui a pour cible le dernier tat visit dans la rgion
contenant le H.
Dans lexemple de la fentre prsent prcdemment la figure 4.2, le pseudo-tat historique permet de retrouver ltat prcdent (normale ou agrandie) quand on sort de ltat
rduite.
Il est possible de dfinir un dernier tat visit par dfaut laide dune transition ayant pour
source le pseudo-tat H. Cet tat par dfaut sera utilis si la rgion na pas encore t visite.
Il est galement possible de dfinir un pseudo-tat historique profond, not par un cercle
contenant H*. Cet historique profond permet datteindre le dernier tat visit dans la
rgion, quel que soit son niveau dimbrication, alors que le pseudo-tat H limite laccs aux
tats de son niveau dimbrication dans la rgion. Toute rgion peut avoir la fois un historique profond et un historique de surface.
EXEMPLE
Historique
Lutilisation dun historique profond permet de retrouver, aprs une interruption, le sous-tat
prcdent. la figure 4.12, lutilisation dun historique de surface H, au lieu de H*, permettrait de retrouver ltat Traitement1 ou Traitement2 dans leur sous-tat initial, mais pas les
sous-tats imbriqus E11, E12, E21, E22, qui taient occups avant linterruption.
136
UML 2
Chapitre
Figure 4.12
Traitement
Historique et
historique profond.
reprendre
H*
Traitement 1
2.5 INTERFACE
Traite
Interruption
Traitement 2
E11
E21
E12
E22
interrompre
DES TATS COMPOSITES
Pour cacher la complexit, il est possible de masquer, sur un diagramme, les sous-tats dun
tat composite et de les dfinir dans un autre diagramme. Pour exprimer la connexion des
diagrammes entre eux, vous pouvez utiliser des points de connexion. Les points dentre et
de sortie sont respectivement reprsents par un cercle vide et un cercle barr la frontire
de ltat.
Pour utiliser le comportement par dfaut dune machine tat, cest--dire entrer par
ltat initial par dfaut et considrer les traitements finis quand ltat final est atteint, il est
inutile de se servir de ces points de connexion. Recourez plus simplement des transitions
ayant pour cible la frontire de ltat englobant.
Employez plutt des points de connexion lorsquil est possible dentrer ou de sortir de la
machine tats de plusieurs faons, par exemple pour reprsenter des transitions traversant
la frontire de ltat englobant et visant directement un autre sous-tat que ltat initial
(comme ltat historique par exemple), ou ayant pour source un sous-tat et visant un tat
externe.
Un point de connexion nest quune rfrence un tat dfini ailleurs. Ltat quil dsigne est
signal par lunique transition quittant le pseudo-tat. Cette transition peut ventuellement
porter une tiquette indiquant une action (qui sera excute avant lactivit entry de ltat
cible), mais pas de garde ni de dclencheur explicite : cest le prolongement de la transition
qui vise le point de connexion.
Plusieurs transitions peuvent cibler un mme point de connexion. Cela peut rendre les diagrammes plus lisibles.
EXEMPLE
Points de connexion
Cet exemple montre lutilisation des points de connexion. Ltat distribuer boisson a deux
entres et trois sorties. Lentre par dfaut vrifie dabord que le crdit de lutilisateur est suffisant pour la boisson slectionne, et peut provoquer une sortie sur erreur par le point de
connexion crdit insuffisant. Un deuxime point dentre est fourni pour loprateur de maintenance qui peut dclencher la prparation dune boisson sans insrer dargent. La prparation de la boisson peut elle-mme tre soumise des erreurs. Dans le cas nominal, la boisson
est prpare et la sortie de ltat distribuer boisson se fait par ltat final.
Figure 4.13
distribuer boisson
Points de connexion
pour la composition
de diagrammes.
[crdit < prix]
Crdit insuffisant
vrifier crdit
[crdit >= prix]

Test oprateur
prparer
boisson
Produit puis
Erreur matrielle
Erreur boisson non distribue
Les points de connexion sont plus quune facilit de notation : ils permettent de dcoupler
la modlisation du comportement interne dun tat et la modlisation dun comportement
plus global. Ils offrent une faon de reprsenter linterface (au sens objet) dune machine
tats, en masquant limplmentation du comportement. Cela permet un dveloppement
par raffinements (ou en bottom-up), en deux tapes indpendantes du processus de conception, ce qui est essentiel pour traiter des modles de grande taille.
(3)
Contrat de comportement
UML 2 introduit la notion de contrat de comportement (ou protocole dutilisation dun
classeur), reprsent laide dun diagramme de protocole (une version simplifie des
diagrammes dtats-transitions reconnaissable au mot-cl {protocol}).
Un contrat de comportement dfinit les squences dactions lgales sur un classeur, ainsi
quun certain nombre de pr- et post-conditions qui doivent tre valides. Il est relativement abstrait et nexprime pas la nature des traitements raliss, mais indique simplement
leur enchanement logique. Ainsi, les tats dun diagramme de protocole nont pas de
clauses dclenchant des activits (entry/, exit/, do/), et les transitions nont pas dactivits
dclencher.
Notation
La syntaxe de ltiquette dune transition liant un tat source E1 un tat destination E2 sur
un diagramme de protocole est la suivante :
[pr-condition] Dclencheur / [post-condition]
Une telle transition a le sens suivant : si le classeur est dans ltat protocolaire E1 et si la
pr-condition est vraie, la rception de lvnement dclencheur doit provoquer le passage
dans ltat E2, et lissue du franchissement, la post-condition doit tre vraie.
138
UML 2
Chapitre
Les protocoles servent expliquer la faon correcte de se servir dune classe ou dun composant, sans spcifier les traitements qui ralisent laction. Plusieurs implmentations diffrentes dune classe peuvent respecter un protocole donn.
EXEMPLE
Protocole dune classe Fichier

Ce diagramme dcrit la faon de se servir dune instance de classe descripteur de fichier.
Avant de pouvoir lutiliser vraiment (lecture, criture, positionnement du curseur dans le
fichier), il faut lassocier un fichier laide de la mthode open. Avant de dtruire linstance, lutilisateur doit appeler la mthode close, pour viter dventuels problmes dentre/
sortie. Sur cet exemple, il ny a pas de gardes.
Figure 4.14
Diagramme de
protocole dune
classe fichier.
stm {protocol}
fichier
write/
close/
dconnect
connect
seek/
open/
delete/
read/
(4)
Gestion de la concurrence
Les diagrammes dtats-transitions permettent de dcrire efficacement les mcanismes
concurrents. Un tat composite dot de sous-tats peut avoir un comportement concurrent,
travers lutilisation de rgions concurrentes. Celles-ci permettent de reprsenter des zones
o laction est ralise par des flots dexcution parallles.
Chaque rgion dun tat peut avoir un tat initial et final. Une transition qui atteint la
bordure dun tat composite est quivalente une transition qui atteint ltat initial du
sous-diagramme ou les tats initiaux de toutes ses rgions concurrentes si elles existent. Les
transitions ayant pour origine un tat initial interne ne sont pas tiquetes et correspondent
toute transition atteignant la frontire de ltat externe.
Quand un tat prsente des rgions concurrentes, elles doivent toutes atteindre leur tat
final pour que laction soit considre comme termine (gnration dun completion event).
EXEMPLE
tat concurrent
Cet exemple montre un tat concurrent, au sein dun distributeur de type machine caf.
Quand la boisson a t slectionne et le montant valid par rappor t au crdit, deux squences dactions sont dclenches en parallle : la prparation de la boisson et le rendu de la
monnaie.
Figure 4.15
boisson slectionne
Rgions concurrentes
au sein dun tat.
prparer boisson
terminer prparation
entry/placer gobelet
do/servir liquide
do/ajouter sucre
exit/signal sonore
rendre monnaie
entry/monnaie= credit - boisson.prix()
do/monnayeur.rendre(monnaie)
Il est galement possible de reprsenter ce type de comportement au moyen de transitions

concurrentes dites complexes . Ces transitions sont reprsentes par une barre verticale
paisse et courte, ventuellement associe un nom. Un ou plusieurs arcs peuvent avoir
pour origine ou destination la transition. La smantique associe est celle dun fork/join.
EXEMPLE
Transition concurrente
Ltat concurrent du distributeur de boisson peut tre spcifi de faon quivalente laide de
deux transitions concurrentes. La transition nomme ici fork correspond la cration de deux
tches concurrentes cres dans les tats prparer boisson et rendre monnaie. La transition
nomme join correspond une barrire de synchronisation par rendez-vous. Pour pouvoir
continuer leur excution, toutes les tches concurrentes doivent pralablement tre prtes
franchir la transition de rendez-vous.
Figure 4.16
Transition complexe
pour lexpression
de la concurrence.
prparer boisson
terminer prparation
fork
join
entry/placer gobelet
do/servir liquide
do/ajouter sucre
exit/signal sonore
gobelet bloqu
nominal
do/a fficher retirer boisson
rendre monnaie
entry/monnaie= credit - boisson.prix()
do/monnayeur.rendre(monnaie)
gobelet retir/
Une transition ayant pour destination un tat cible muni de rgions concurrentes est quivalente une transition complexe de type fork ayant pour cibles les tats initiaux de chaque
rgion concurrente. Une transition ayant pour origine un tat source muni de rgions
concurrentes est quivalente une transition complexe de type join ayant pour sources les
tats finaux de chaque rgion concurrente.
140
UML 2
Chapitre
Conclusion
Les diagrammes dtats-transitions permettent de reprsenter le comportement interne
dun objet, a fortiori actif, sous une forme qui met en avant le modle vnementiel ou ractif des traitements. Ils sont bien adapts au gnie logiciel orient objet, en raison des mcanismes quils proposent (vnement de type call, signal, after), qui permettent de faire le lien
avec les autres diagrammes de la norme. La grande flexibilit apporte par la possibilit de
dfinir des transitions internes (entry, do, exit) et par les mcanismes de hirarchisation des
diagrammes permet de reprsenter de faon concise et formelle lensemble des comportements dune instance modlise.
De ce point de vue, les diagrammes dtats-transitions sont les seuls de la norme offrir une
vision complte et non ambigu de lensemble des comportements (les diagrammes dinteractions noffrant que la vue dun scnario, sans vraiment prciser comment les diffrents
scnarios bauchs peuvent interagir entre eux). Dun autre ct, en raison de leur grand
niveau de dtails et de leur lourdeur relative, ils sont surtout adapts la phase de ralisation. En outre, ils conviennent peu la modlisation de systmes composs de plusieurs
sous-systmes car ils noffrent pas de vision globale.
Les diagrammes de protocole donnent une vision de haut niveau du comportement dun
composant en spcifiant ses responsabilits, sans entrer dans les dtails de son implmentation. Ils sont relativement proches de la notion dinterface dun composant, tout en ajoutant
une information supplmentaire par rapport la seule description des signatures des oprations quil porte, savoir des contraintes sur lordre dappel des oprations dclares.
Outre leur intrt lors de la modlisation, certains outils sont capables de gnrer automatiquement un programme partir dune description sous forme de diagrammes tatstransitions. Ainsi, chaque objet dun systme passe sous le contrle dun automate. Ce
dernier connat ltat de lobjet tout instant, et en agissant comme un filtre, nautorise les
changements dtats que sil reoit une demande de transition valide. Le code produit est
alors trs robuste car lobjet ne peut pas tre corrompu. De plus, le mode de contrle du
logiciel devient alors vnementiel.
Avec les diagrammes prsents dans la partie prcdente du livre (diagramme des cas dutilisation, diagramme de classes et dobjets, diagramme de squence et de communication,
diagramme dtats-transitions), un systme peut tre presque entirement modlis. La
modlisation nest cependant pas assez avance pour implanter le systme. Les dveloppeurs
par exemple ont besoin de dcrire les algorithmes utiliss pour dfinir les mthodes des
classes, sans pour autant avoir recours un langage de programmation. Par ailleurs, certains
modles sont trop approximatifs. Considrez par exemple un systme dont le comportement est complexe. Dans ce cas, les diagrammes de squence peuvent ne pas suffire
dtailler les cas dutilisation. Une partie de ces lacunes peuvent tre combles grce aux
diagrammes dactivits qui sont tudis au chapitre suivant.
Problmes
et exercices
Les exercices suivants utilisent les principaux concepts des diagrammes
dtats-transitions.
EXERCICE 1
DIAGRAMME DTATS-TRANSITIONS DUN

DE LINSEE
INDIVIDU DU POINT DE VUE
Reprsentez par un diagramme dtats-transitions les tats que peut prendre un individu
du point de vue de lINSEE : vivant, dcd, mineur, majeur, clibataire, mari, veuf et
divorc.
Supposez que seul un individu majeur peut se marier. Utilisez des tats composites pour
cumuler les tats : un individu peut tre simultanment vivant, majeur, et divorc par
exemple.
Figure 4.17
Un individu du point
de vue de lINSEE.
vivant
majeur
mineur
marier
marier
clibataire
mari
after (18 ans)
veuf
dcs conjoint
divorcer
marier
majoritAnticipe
divorc
dcder
dcd
La machine tats englobante est implicite ici. Lutilisation dun vnement de type after
permet de dclencher le passage ltat majeur. Seules les transitions lgales sont reprsentes : une personne ne peut se marier si elle est dj marie.
La transition dcder est franchissable quel que soit le sous-tat de vivant dans lequel se
trouve un individu.
142
UML 2
Chapitre
EXERCICE 2
DIAGRAMME DTATS-TRANSITIONS DUNE
PORTE
Une porte munie dune serrure offre les oprations ouvrir, fermer, verrouiller, dverrouiller
et franchir. La serrure peut tre ferme simple ou double tour.
1. Commencez par modliser les tats et transitions de la serrure. Mettez en avant les tats
o la serrure est verrouille par rapport aux tats o elle ne lest pas.
2. Exprimez travers un diagramme de protocole la faon normale de se servir dune
porte verrou.
3. Modlisez les tats et transitions dune porte sans serrure. Ajoutez ensuite des annotations exprimant des contraintes pour lier ce diagramme lutilisation de la serrure.
1.La serrure rpond aux vnements verrouiller et dverrouiller. Vous pouvez dans un premier temps vous contenter de modliser les trois tats dverrouille, simple tour et double
tour. Utilisez un tat composite pour distinguer les tats o la serrure est verrouille. Sur
le schma de la figure 4.18, nous avons employ la notation frame (cadre), avec lindication stm (State Machine), pour spcifier le type et le nom du diagramme.
Figure 4.18
Les tats dune
serrure de porte.
stm
Serrure
verrouille
verrouiller
verrouiller
dverrouille
simple tour
double tour
dverrouiller
dverrouiller
2. Un diagramme de protocole exprime la faon correcte de se servir dun composant. Ici

vous devez spcifier quon ne verrouille la porte que quand elle est ferme. Une premire
version prsente la figure 4.19 fait apparatre quatre tats.
Le protocole
dutilisation
dune porte.
{protocol}
porte avec verrou
fermer()
ouverte
franchir()
verrouiller()
ferme
ouvrir()
verrouiller()
ferme
simple tour
dverrouiller()
ferme
double tour
dverrouiller()
Cependant pour amliorer la cohrence avec le diagramme prsent la figure 4.18, vous
pouvez utiliser un tat composite, dans lequel les tats prcdemment identifis de la
serrure sont prsents.
Exercices
Figure 4.19
Figure 4.20
{protocol}
porte avec verrou
Une autre modlisation du protocole

dutilisation dune
porte.
ferme
fermer()
ouverte
franchir()
verrouiller()
dverrouille
ouvrir()
verrouiller()
simple tour
dverrouiller()
double tour
dverrouiller()
Ces deux modlisations sont trs similaires, mais la deuxime dcouple mieux les tats de
la serrure et ceux de la porte elle-mme.
3. La porte na que de deux tats (ouverte ou ferme) et ragit aux vnements ouvrir, fermer
et franchir. Vous pouvez dabord modliser les tats ouverte et ferme et les transitions
associes. Ajoutez ensuite les gardes qui contraignent les transitions par rapport aux tats
de la serrure. La rfrence ltat de lobjet serrure suppose une variable de contexte
accessible depuis lobjet englobant ce diagramme, cest--dire la porte.
Figure 4.21
Les tats dune porte.
stm
porte
[serrure dverrouille] fermer()/
ouverte
ferme
[serrure dverrouille] ouvrir()/
franchir()
Cette modlisation exploite la dfinition composite des tats de la serrure : il ne sagit pas
de savoir si la serrure est ferme simple ou double tour, mais simplement si elle est
verrouille ou non.
Remarque
Cette modlisation dcouple mieux les objets porte et serrure quune modlisation qui
mlangerait leurs machines tats. Vous seriez alors oblig de faire figurer des tats
comme ouverte et verrouille simple tour, ouverte et verrouille double tour, ferme et
verrouille, ce qui augmenterait la complexit du diagramme inutilement et forcerait
copier-coller des parties de diagramme.
Lutilisation de gardes est mieux adapte ici que lutilisation dune barre de synchronisation
qui forcerait mlanger les diagrammes de la serrure et de la por te. Avec le modle
obtenu, vous pourrez aisment rutiliser des parties pour modliser une porte avec un digicode par exemple.
Enfin, notez que la porte telle quelle est dfinie par le diagramme de la figure 4.21 admet
des scnarios absents du diagramme de protocole : il est galement possible de la verrouiller quand elle est ouverte (ce qui empche de la fermer correctement). Le diagramme
de protocole donne donc des informations non redondantes par rapport aux diagrammes
dtats-transitions : il dcrit la bonne faon de se servir dune porte.
144
UML 2
Chapitre
EXERCICE 3
DIAGRAMME DTATS-TRANSITIONS DUNE
MONTRE CHRONOMTRE
Cet exercice runit trois exercices relativement indpendants, correspondant aux diffrentes
fonctionnalits proposes. Larchitecture logicielle propose sappuie sur le design pattern
Observer.
Remarque
Le design pattern (ou patron de solution) Observer [Gamma 95] offre une solution propre
aux problmes de mise jour des donnes de classes lies entre elles. Un des problmes
du partitionnement dune application en classes est le maintien de la cohrence des par ties
de lapplication. Pour favoriser la rutilisabilit, il nest pas souhaitable de coupler for tement les classes stockant les donnes (classes de type sujet) et celles qui les affichent ou plus
gnralement les utilisent (classes de type observateur). Pourtant, il faut assurer quune mise
jour des donnes des classes de type sujet sera correctement rpercute sur les classes de
type observateur.
Le design pattern Observer dcrit une solution ce problme. Un sujet peut avoir un nombre
indtermin dobservateurs et tous les observateurs sont notifis du changement quand le
sujet subit une mise jour. En rponse, les observateurs interrogent le sujet pour connatre
son nouvel tat et mettre ainsi jour leur propre tat.
Une architecture de ce type est parfois qualifie de publish/subscribe (publication/abonnement) : le sujet publie des notifications, les observateurs sy abonnent sils le souhaitent. Le
point important est que le sujet ignore quels sont ses observateurs, ce qui donne un modle
bien dcoupl.
Figure 4.22
Sujet
Observateur
observateurs
+attacher(Observateur)
+dtacher(Observateur)
+notify()
SujetConcret
update()
pour chaque o de observateurs {
o.update();
}
sujet
tatSujet
setEtat()
getEtat()
ObservateurConcret
tatObservateur
mettre jour ltat ;

self.notify();
update()
tatObservateur = foo (sujet.getEtat());

return tatSujet;
Une montre digitale propose une fonction horloge et une fonction chronomtre. Elle est
munie de quatre boutons :
Le bouton light, quand il est press, allume une lumire pendant une dure de deux
secondes.
Le bouton mode active successivement trois modes principaux de la montre : laffichage de lheure courante, le mode chronomtre et le mode rglage (pour mettre
jour lheure courante).
Exercices
Design pattern
Observer.
Le bouton start-stop lance et arrte le chronomtre en mode chronomtre. Il active

successivement les fonctions de rglage de lheure, des minutes ou des secondes en
mode rglage.
Le bouton set incrmente les heures, minutes et secondes en mode rglage et remet
zro le chronomtre.
Vous allez dcomposer ltude du fonctionnement de cette montre en plusieurs tapes.
On vous donne la classe Timer qui sait grer les dates/heures et est munie de toutes les oprations de mise jour utiles. Sa mthode start() lance lcoulement du temps et stop() larrte.
1. laborez un diagramme de classes qui permet de raliser le lien entre lafficheur cristaux liquides de la montre et les instances de Timer grant respectivement le chronomtre et lheure courante.
2 .Modlisez dans un premier temps le comportement li lutilisation du bouton mode
de la montre. Ajoutez le comportement li lutilisation de la lumire (bouton light).
3. En mode chronomtre, le bouton start-stop lance ou arrte le chronomtre. Le bouton
set remet le chronomtre zro sil est arrt. Modlisez ces comportements.
Ajoutez la possibilit de retrouver ltat prcdent en changeant de mode : il est possible
de lancer le chronomtre, puis de basculer en mode affichage de lheure et de revenir au
mode chronomtre : le chronomtre continue de tourner pendant cette opration.
(Vous pourrez utiliser un pseudo-tat historique.)
4. En mode rglage, le bouton start-stop active successivement les fonctions de rglage de
lheure, des minutes ou des secondes. Le bouton set incrmente lheure courante dune
heure en mode rglage de lheure, dune minute en mode rglage des minutes, ou remet
les secondes zro en mode rglage des secondes. Lafficheur fait clignoter le champ
slectionn. Modlisez ces comportements.
1. La montre dispose de deux instances de Timer, et dun afficheur, accessibles depuis son
contexte. On utilise une instance du design pattern Observer pour assurer la cohrence
continue entre laffichage et ltat interne de la montre.
Figure 4.23
Sujet
Diagramme de
classes simplifi
dune montre.
Timer
Observateur
sujet
start()
stop()
chrono
afficher(t: Timer)
time
afficheur
Montre
146
UML 2
Afficheur
sujet.dtacher(self);
t.attacher(self);
sujet = t;
Chapitre
2. Lalternance entre les trois modes principaux se reprsente facilement laide de trois
tats. Le comportement li lclairage est indpendant du mode principal slectionn.
Utilisez donc des rgions concurrentes pour exprimer cette indpendance.
Figure 4.24
mode/
mode/
mode chrono
affichage heure
mode rglage
entry/
afficheur.afficher(time)
mode/
light/
lumire teinte
lumire allume
light/
after(2 sec)
Le mode affichage de lheure est relativement simple : quand on entre dans cet tat, on lie
lafficheur lheure courante ; les boutons set et start-stop sont alors sans effet.
Les modes chronomtre et rglage sont plus complexes et par l mme dtaills sparment. Notez graphiquement que ce sont des tats composites, sans plus de prcision. On
introduit le point dentre de ltat mode chrono par souci de cohrence avec la solution
propose la question 3. ce stade de la modlisation, vous pourriez vous contenter de
toucher la frontire de ltat.
La gestion de la lumire donne lieu deux tats, isols dans une rgion concurrente.
after(2sec) se mesure par dfaut ds lentre dans ltat lumire allume. Une nouvelle
pression sur le bouton light quand la lumire est dj active a donc pour effet de remettre
ce compteur zro, puisque la transition associe fait quitter et entrer de nouveau dans
ltat lumire allume.
3. Le mode chronomtre sappuie sur linstance de Timer chrono. Chaque fois que lon entre
en mode chronomtre, lafficheur est li linstance de Timer chrono.
Le chronomtre est initialis zro la premire fois que lon entre dans cet tat. Ce fonctionnement est modlis par la transition partant de ltat historique, qui est la transition
par dfaut (portant laction chrono.set(0)) utilise uniquement la premire fois que lon
pntre dans cette rgion. Celle-ci a ensuite deux sous-tats, selon que le chronomtre est
lanc ou arrt. Si on la quitte et quon la retrouve ensuite, le dernier tat visit est atteint,
ce qui reprsente bien le mcanisme de reprise dcrit dans lnonc.
Lvnement not s-s correspond la pression sur le bouton start-stop. Le point dentre
de cet tat composite mne directement ltat historique. Labsence de pseudo-tat
initial est compense par la prsence dun tat historique qui permet dentrer dans
la rgion. Un pseudo-tat final est galement inutile puisque les transitions quittant cette
rgion touchent la frontire de ltat et sont donc franchissables depuis les deux tats
stopp et lanc.
Exercices
Les principaux
modes daffichage
et la lumire.
Figure 4.25
mode chrono
Le mode
chronomtre.
s-s/chrono.stop()
H
stopp
lanc
/chrono.set(0)
s-s/chrono.start()
set/chrono.set(0)
entry/afficheur.afficher(chrono)
4. Le mode rglage a trois sous-tats reprsentant le rglage de lheure, des minutes et des
secondes. lentre dans cette rgion, lafficheur est li au Timer time reprsentant
lheure courante.
Les actions do/ sont continues et durent tant que lon reste dans ltat, mais sont interrompues par une transition qui le quitte. Les mthodes increment et reset incrmentent
ou remettent zro le champ mentionn.
Figure 4.26
mode rglage
Le mode rglage.
set/time.increment(minute)
s-s/
set/time.increment(heure)
rglage minute
do/afficheur.clignoter(minute)
rglage heure
s-s/
set/time.reset(seconde)
rglage seconde
do/afficheur.clignoter(heure)
do/afficheur.clignoter(seconde)
s-s/
entry/afficheur.affiche(time)
EXERCICE 4
MODLISATION
DE LA SOCKET
TCP
Cet exercice rcapitulatif aborde la modlisation dune socket de communication en mode

connect utilisant le protocole TCP (Transfer Control Protocol). Les tats utiliss dans cette
modlisation sont ceux affichs par la commande standard netstat et spcifis dans la norme
IEEE. Cet exercice correspond donc la modlisation dun protocole rel. Ne soyez pas
drout par la complexit apparente du sujet : le passage des diagrammes de squence proposs aux diagrammes dtats-transitions est relativement direct.
148
UML 2
Chapitre
Les sockets sont des points extrmes de communication bidirectionnels : cest une interface
standardise, implmente sur quasiment toutes les plates-formes de faon homogne,
pour permettre la portabilit dapplications interagissant travers un rseau.
Le modle offert pour lutilisation de sockets TCP est de type client-serveur :
Le serveur offre un service aux clients, sur un numro de port bien connu (80 pour
HTTP par exemple). Il ouvre pour cela une socket quil place dans ltat LISTEN
(coute) et attend les requtes de client.
Le client est lutilisateur du service. Il ouvre une socket et demande la connexion au

serveur, en fournissant ladresse du service souhait (par exemple : nom.de.serveur.fr:80).
Si, ladresse spcifie, un serveur est bien en attente, une connexion entre le client et le
serveur est tablie.
Le diagramme de squence de la figure 4.27 reprsente les tapes de cette ouverture de
connexion. Les rectangles arrondis sur la ligne de vie donnent ltat de linstance de socket
concerne. Les messages provenant de la bordure du cadre reprsentent les messages provenant de lapplication. Les messages (ou trames) SYN sont un des types de messages de
contrle du protocole TCP. Les trames ACK correspondent des acquittements. Chaque
trame TCP porte un numro de squence, qui permet de grer les pertes de trames et les
acquittements. Toute trame peut porter, en plus de sa valeur propre, un acquittement
encapsul dans le mme objet (piggy-back), pour des questions defficacit.
Figure 4.27
sd tablissement de connexion TCP
client:Socket
server:Socket
CLOSED
CLOSED
accept()
SYN J
connect()
SYN_SENT
LISTEN
SYN K,ACK J+1

SYN_RCVD
ACK K+1
ESTABLISHED
ESTABLISHED
Une fois la connexion tablie, le protocole devient symtrique : les deux participants peuvent lire et envoyer des messages. Vous ne modliserez pas cette partie du protocole relativement complexe, qui assure la transmission sans pertes, duplications ou dsquencement
des messages, et la gestion transparente des congestions du rseau.
La fin de connexion est initie par lun des participants, quand son application appelle la
mthode close(). Pour que la connexion se termine proprement, un certain nombre de
trames sont encore changes, comme le montre le schma prsent la figure 4.28.
Exercices
Ouverture de
connexion TCP.
Figure 4.28
Fermeture de
connexion TCP.
sd Fermeture de connexion TCP
client:Socket
close()
On note client et
serveur, mais cette
partie du protocole
est totalement
symtrique
ESTABLISHED
FIN_WAIT_1
server:Socket
ESTABLISHED
FIN M
ACK M+1
CLOSE_WAIT
FIN_WAIT_2
close()
FIN N
TIME_WAIT
La fin du timeout de 2 MSL

(Maximum Segment Lifetime)
ramne ltat CLOSED
LAST_ACK
ACK N+1
CLOSED
On dit de lextrmit note client sur ce schma quelle fait une fermeture active, car elle
initie la fin de connexion. Au contraire, lextrmit serveur subit une fermeture passive,
linitiative de lautre participant. ltat CLOSE_WAIT, les lectures de lapplication sur la
socket vont rendre le caractre de fin de fichier EOF, et lon attend de lapplication quelle
appelle la mthode close() pour une fermeture propre de la connexion.
Lensemble du protocole prvoit des problmes matriels tels quune interruption du
rseau ou un crash dun des participants : chaque envoi dune trame, on initialise une
horloge, qui dclenche la rmission de la trame si elle nest pas acquitte temps (on suppose que la trame sest perdue sur le rseau) ou la fin de la connexion si la trame a dj t
mise trois fois (on suppose un crash rseau ou de lautre participant).
1. En vous basant sur les diagrammes de squence fournis, laborez un diagramme
dtats-transitions reprsentant les tats dune socket TCP. Vous distinguerez les tats
correspondant ltat initial (CLOSED), lattente dune connexion ct serveur,
lattente dtablissement de la connexion ct client, la connexion tablie (ESTABLISHED), et la fermeture active et passive de la connexion. Certains de ces tats
peuvent tre affins en sous-tats.
150
UML 2
Chapitre
2. Une fermeture simultane de la connexion se produit lorsque les deux participants

demandent en mme temps cette fermeture (par appel de close()). Leurs trames de FIN
se croisent et sont rceptionnes alors que la socket est ltat FIN_WAIT_1 o lon
attend habituellement un simple acquittement. Ce cas est dcrit par le diagramme de
squence prsent la figure 4.29.
Figure 4.29
sd Fermeture de connexion simultane TCP
client:Socket
server:Socket
ESTABLISHED
ESTABLISHED
close()
FIN J
close()
FIN K
FIN_WAIT_1
FIN_WAIT_1
ACK K+1
ACK J+1
CLOSING
CLOSING
TIME_WAIT
TIME_WAIT
La fin du timeout de 2 MSL
(Maximum Segment Lifetime)
ramne ltat CLOSED
Modifiez le diagramme de la rponse la question 1 pour permettre ce nouveau cas de

figure.
1. Cet exercice modlisant un systme rel est plus complet que les prcdents. La solution
propose ici est une version simplifie du protocole, inspire du chapitre 18 de louvrage
TCP/IP illustr, volume 1 de Stevens (1993, Addison Wesley).
Il faut dcomposer le problme en tapes. Dans ce but, laborez dans un premier temps
un diagramme o napparaissent que les messages provenant de lapplication et les tats
proposs par lnonc (voir figure 4.30).
Exercices
Fermeture
simultane de
connexion TCP.
Figure 4.30
[timeout et trame rmise 2 fois]
tats dune socket

TCP du point de vue
dune application.
CLOSED
accept()
connect()
Attente dun
client
Connexion au
serveur
ESTABLISHED
Fin par correspondant
close()
Fermeture passive
Fermeture active
Ce premier diagramme donne une bonne vue densemble du comportement de la socket.

Sont mentionns les informations et comportements principaux du protocole : une
socket est initialement ltat CLOSED et peut tre sollicite par un accept() (du ct
serveur) ou un connect() (du ct client). La connexion est alors tablie (tat ESTABLISHED). La connexion peut se terminer soit de faon active, avec un appel de close(),
soit de faon passive, si cest lautre participant qui met fin la connexion.
La solution propose utilise un point de sortie alternatif pour reprsenter ce dernier cas,
au lieu de porter la trame FIN/ACK directement sur une transition de la bordure de ltat
ESTABLISHED ltat Fermeture passive. Ce parti pris assure une certaine cohrence et
permet de cacher sur ce diagramme toutes les trames de contrle. Cela donne une vision
de plus haut niveau du comportement.
La fin nominale de la connexion correspond ltat final, atteint par une transition automatique depuis un des tats de fermeture. La transition sans tiquette qui ramne ltat
CLOSED est alors franchie.
Le mcanisme de timeout ramne ltat CLOSED et est franchissable depuis tout tat o
la connexion est engage.
Vient ensuite la description dtaille des tats recenss (figures 4.31 4.35), ce qui est
relativement direct tant donn les diagrammes de squence proposs. Sont omis sur ces
diagrammes les numros de squence des messages.
152
UML 2
Chapitre
Figure 4.31
attente dun client
Ct serveur,
attente dun client.
LISTEN
SYN_RCVD
SYN / SYN,ACK
Figure 4.32
ACK/
connexion au serveur
Ct client, tapes
de la connexion.
/ SYN
SYN,ACK / ACK
SYN_SENT
Figure 4.33
ESTABLISHED
Symtrique,
phase connecte
dchanges
de donnes.
Transfert de donnes
FIN/ACK
Fin par correspondant
Figure 4.34
fermeture active
/FIN
FIN_WAIT_1
ACK/
Figure 4.35
Fermeture passive,
suite une
demande de lautre
participant.
FIN_WAIT_2
after (2MSL)
FIN/ACK
TIME_WAIT
fermeture passive
close()/FIN
CLOSE_WAIT
ACK/
LAST_ACK
Exercices
Fermeture active,
linitiative de
lapplication.
2. Lajout de ce nouveau scnario se traduit par lintroduction dune nouvelle transition

depuis ltat FIN_WAIT_1. Le schma densemble dcrivant les tats nest pas transform : seul le comportement interne de ltat composite fermeture active est modifi
(figure 4.36).
Figure 4.36
Introduction
de la fermeture
simultane ou
double fermeture
active.
fermeture active
/FIN
FIN/ACK
FIN_WAIT_1
CLOSING
ACK/
ACK/
after (2MSL)
FIN_WAIT_2
FIN/ACK
TIME_WAIT
La bonne modularit de la description prcdemment labore permet de limiter le

nombre et la porte des modifications ncessaires pour prendre en compte ce nouveau
scnario.
154
UML 2
Chapitre
Diagramme
dactivits
1.
2.
3.
4.
Action ...................................
Activit .................................
Flot de contrle ......................
Mcanismes avancs .............
156
160
161
171
1. Programmation en activits...... 177
2. Vente en ligne ........................ 178
3. Algorithmique ........................ 179
4. Vidoclub .............................. 182
5. Cache doprations................. 183
Les diagrammes dactivits permettent de spcifier des

traitements a priori squentiels. Ils offrent un pouvoir
dexpression trs proche des langages de programmation
objet : spcification des actions de base (dclaration
de variables, affectation), structures de contrle
(conditionnelles, boucles), ainsi que les instructions
particulires la programmation oriente objet (appels
doprations, exceptions). Ils sont donc bien adapts
la spcification dtaille des traitements en phase de
ralisation. On peut aussi les utiliser de faon plus informelle
pour dcrire des enchanements dactions de haut niveau,
en particulier pour la description dtaille des cas
dutilisation.
155
(1)
Action
Les modles servent dabord expliquer le fonctionnement dun systme, en fournissant
une vision abstraite de ses comportements. Cependant, UML 2 a vocation aller au-del
dune simple description informelle, en fournissant la possibilit de dcrire un systme un
niveau de dtails qui permette son excution. Cela sinscrit dans le cadre du MDA (Model
Driven Architecture), mis au point par lOMG, qui propose de centrer le dveloppement des
systmes au niveau de leur modle.
terme, lobjectif est de fournir un langage de spcification qui permette de se dtacher des
langages de programmation classiques : les dveloppeurs de demain pourront utiliser UML
pour dvelopper leur systme sans jamais descendre jusquau niveau de langages de programmation tels que Java, C++.
Pour cela, UML doit tre dot de mcanismes offrant la prcision dun langage de programmation au niveau de la description de leffet des actions. Comme UML se veut universel,
aucune syntaxe concrte nest propose dans la norme pour dcrire les actions : cest la
charge des outils den dfinir une ou dutiliser la syntaxe dun langage de programmation
existant. Cependant, UML propose une dfinition des instructions de base qui constituent
le langage orient objet : cest la description des actions UML.
Sans aller dans les dtails de la dfinition, nous prsentons ici les grandes catgories
dactions que propose la norme, et donnons des exemples concrets dinstructions offrant en
C++ ou Java la mme smantique.
1.1 GESTION
DES APPELS DE PROCDURE
Ces actions de communication grent le passage et le retour de paramtres et les mcanismes dappels doprations synchrones et asynchrones.
Appel synchrone
Les actions de type call correspondent des appels de procdure ou de mthode.
Dans les deux cas, il est possible de spcifier des arguments et dobtenir des valeurs en retour.
Ce type dappel est bloquant : lappelant attend la rponse de lappel avant de continuer
son excution.
Call operation correspond lappel dune opration sur un classeur. Call behavior correspond
linvocation dun comportement spcifi laide dun diagramme UML, par exemple un
diagramme dactivits ou dinteractions. Cela offre la possibilit, dans les diagrammes
dactivits, de directement rfrer dautres types de diagrammes. Vous pouvez donc utiliser un diagramme de squence par exemple (imbriqu dans un diagramme dactivits) pour
illustrer le comportement dune activit, et rciproquement.
Les actions accept call et reply peuvent tre utilises du ct rcepteur pour dcomposer
la rception de lappel. Reply correspond prcisment au return des langages de programmation.
EXEMPLE
156
UML 2
Linvocation dune mthode, ou dune procdure plus complexe (un autre programme par
exemple), correspond une instance de call.
Pour dcrire un traitement rcursif, il faut utiliser une action call behavior pour r-invoquer le
comportement en cours de description.
Chapitre
Appel asynchrone
Les appels asynchrones de type send correspondent des envois de messages asynchrones :
lappelant poursuit son excution sans attendre que lentit cible ait bien reu le message.
Ce type dappel est bien adapt la modlisation de systmes matriels (communications
sur un bus, interruptions dentre/sortie avec send signal) ou de protocoles de communication particuliers (UDP dans le domaine Internet, ou MPI dans le contexte multiprocesseur
avec send object).
Le broadcast signal permet dmettre vers plusieurs destinataires la fois, une possibilit
rarement offerte par les langages de programmation.
Laction symtrique ct rcepteur est accept event, qui permet la rception dun signal.
EXEMPLE
La smantique dun appel dans les langages objet (C++, Java) est toujours synchrone (cest-dire de type appel de procdure). Cependant, certains mcanismes de communication
peuvent tre vus comme des appels asynchrones.
En Java par exemple, la mthode notify() de la classe Object permet de signaler un autre
thread Java loccurrence dun vnement. Cet appel nest pas bloquant : lexcution se poursuit sans attendre la bonne rception de lappel. Lautre thread nen est inform quaprs un
dlai, quand la machine virtuelle llit pour sexcuter.
vnements particuliers
Laction raise exception permet de lever une exception au cours dun traitement.
Une exception est un lment important de lapproche oriente objet ; elle permet de traiter
des cas particuliers. Le comportement complet associ la gestion des exceptions est dcrit
la section 4.2 de ce chapitre.
EXEMPLE
Le mot-cl standard throw (en Java et en C++) correspond prcisment la smantique dune
action raise exception.
Un time event est un vnement temporel dclench aprs lcoulement dune certaine
dure (spcifie librement). On distingue graphiquement les actions associes une communication : send signal, accept event et accept time event. Cela permet de mieux mettre en
valeur les changes entre les diagrammes de la spcification.
Figure 5.1
Les actions de
communication.
Appui bouton lumire
action accept event
clairer Affichage
action send signal
attendre 2 secondes
action accept time event
teindre Affichage
action send signal
Diagramme dactivits 157
1.2 MANIPULATION
DES VARIABLES
Les variables en UML sont toujours considres comme des instances dune classe : les
actions proposes sur les variables correspondent donc des accs sur un objet. On retrouve
ici toutes les oprations usuelles des langages de programmation.
Accs et mise jour

Les variables UML sont en principe des objets. Cependant, nous incluons aussi les types de
base (int, float, boolean, string), qui ne sont pas proprement parler des objets parmi
les types de variables. Cela suppose que loutillage permettra de les grer par des profils ou
des bibliothques. Par exemple, lopration i++ doit se rsoudre comme un appel de la
mthode ++ sur lobjet i de la classe Int.
UML propose en outre des variables dites multivalues , qui correspondent des collections, tries ou non. Leur introduction permet de faire mieux abstraction de limplmentation : elles peuvent reprsenter une liste, un tableau, une table associative, etc. de faon
homogne. En Java, linterface Collection correspond bien la notion de variable multivalue.
La lecture dune variable par read variable permet daccder son contenu. Laction clear
variable permet de rinitialiser une variable. Si elle est multivalue, clear la vide de ses
valeurs. Pour les variables monovalues, clear na pas dquivalent direct en programmation
objet, si ce nest laffectation dun objet construit par dfaut la variable.
Les actions dcriture permettent non seulement daffecter une valeur une variable, mais
galement dajouter ou de supprimer des valeurs une variable multivalue (type collection
dobjets). En consquence, les actions dcriture se dclinent en add variable value et remove
variable value.
Enfin, une action value specification correspond la dfinition dune constante ou dun
littral (la valeur 3, le caractre a, la chane "hello").
Manipulations des objets

Pour la manipulation des objets, UML offre les actions de base associes la programmation objet.
Create object et destroy object permettent la cration et la destruction dinstances dobjets.
Il est ainsi possible de crer et de dtruire des variables locales, ainsi que des variables de
porte plus grande (attribut statique de classe, par exemple).
Une fois lobjet construit, laccs ses champs se fait laide dactions read structural feature,
qui permettent daccder ses attributs comme ses oprations. Elles correspondent la
notation pointe (monObjet.attribut1.laMthode()) des langages de programmation.
Toute action qui se droule dans un contexte dinstance (non statique) peut accder linstance courante par read self (self correspond lidentit de lobjet courant, not this en Java
et en C++, par exemple).
Enfin, des actions permettent de modifier le type dun objet (reclassify object) ou de tester
lappartenance dun objet un type donn (is classified).
En gnral, il nest possible de reclassifier un objet quen respectant larbre dhritage : typer
une instance de classe drive en instance de classe de base est une opration toujours lgale.
La rciproque est fausse.
158
UML 2
Chapitre
EXEMPLE
Ces mcanismes de typage sont frquemment utiliss dans limplmentation doprateurs de

comparaison dfinis au niveau dune classe de base.
public boolean equals (Object o) {
if (! (o instanceof MaClasse) ) {
return false;
} else {
MaClasse a = (MaClasse) o;
return this.attrib1.equals(a.attrib1);
}
}
#include <typeinfo>
bool operator== (const ClasseBase & o) const {
if ( typeid(o)!= typeid(MaClasse) ) {
return false;
} else {
MaClasse * pa = (MaClasse *) &o;
return this->attrib1 == pa->attrib1;
}
}
Gestion des pointeurs et rfrences

UML intgre la notion de pointeur, sous le nom link . Les actions associes permettent de
manipuler directement une rfrence un objet (ou pointeur). On dclare, en gnral, un
objet de type rfrence avec create link object et on lui affecte ensuite des valeurs avec create
link. destroy link correspond un clear et ne dtruit pas lobjet link mais bien le lien vers
lobjet quil rfrence. Laccs la valeur rfrence par le lien est assur par une action read
link.
Larithmtique des pointeurs nest pas totalement prise en charge, mais laction test identity
permet de comparer des rfrences. Cette action teste lidentit (galit physique en
mmoire) de deux objets. Cela revient comparer les adresses des objets.
EXEMPLE
En Java, tout objet est manipul par rfrence ; il nexiste pas de faon par ticulire de lire la
valeur associe la rfrence : les deux notions sont confondues.
En C++, un pointeur est explicitement manipulable. Une instance dobjet ou une rfrence sur
objet se manipulent de la mme faon. Loprateur toile (*) de drfrencement correspond
la notion de read link dUML.
Modification du modle de classes

La modification du modle de classes (ajout dattributs ou doprations) est assure par des
actions de type add ou remove structural feature. Ces actions ont peu dintrt dans le cadre
dune utilisation usuelle de langage objet. Lobjectif est de modifier en cours dexcution la
structure dune classe.
EXEMPLE
Smalltalk et Python sont deux exemples de langages objet qui permettent ce niveau de rflectivit en cours dexcution.
En Java, ce type dopration nest pris en charge quau niveau bytecode, pas directement au
niveau des fonctionnalits standard du langage. Certaines bibliothques spcialises offrent
cependant une interface de haut niveau pour raliser ces oprations. Elles sont utilises dans
des approches rflexives, comme le tissage daspect (Aspect Oriented Programming).
Le modle de compilation statique de C++ ne permet pas ce type dopration, aprs la dclaration dune classe.
1.3 ACTION
OPAQUE
Une action opaque na pas de smantique ou de contrainte particulire, et na donc pas un
sens dfini par UML. Cest donc aux outils de savoir interprter ce type daction, qui
dpasse le cadre dUML, limit aux actions prcites dans cette section.
Les actions opaques permettent lintgration de librairies ou routines de traitements existants. Elles peuvent galement correspondre des traitements qui nont simplement pas t
modliss.
Parmi les actions opaques figurent galement les oprations sur les types machine de base :
arithmtique entire et flottante, masques et vecteur de bits, etc. Bien que communes la
majorit des langages de programmation, elles ne sont pas standardises en UML.
1.4 UML 2
ET LES ACTIONS
UML dfinit des actions qui couvrent les instructions lmentaires dun langage de programmation, mais ne propose pas de mcanismes pour exprimer des boucles, des conditionnelles, des blocs dactions conscutives. Il sagit l dune volution importante dUML 2
par rapport aux versions prcdentes dUML 1.x, qui intgraient ces mcanismes dans les
actions.
En UML 2, la description de la structuration des actions est laisse aux activits. Ainsi, le
modle est plus clair et mieux dcoupl. Les activits englobent les actions et offrent des
mcanismes pour exprimer clairement le cheminement du flot de contrle.
On peut cependant regretter labsence doprations explicitement dfinies sur les types de
base habituels (oprations arithmtiques, par exemple). On peut esprer quun profil UML
standardis verra bientt le jour pour prendre en charge ces types.
(2)
Activit
2.1 MODLISATION
DES TRAITEMENTS
Les actions lmentaires sont dcrites sparment en UML. Les traitements complets sont
dcrits par des activits, qui offrent une manire concise et sans ambigut de prsenter
graphiquement un traitement squentiel, avec tout larsenal propos par un langage de programmation orient objet (actions de base, boucles et conditionnelles, appels de mthode,
gestion des exceptions).
Les activits donnent donc une description complte des traitements associs des comportements au sens interaction dUML. On les utilise couramment pour tiqueter les autres
diagrammes (traitements associs aux messages des diagrammes de squence, transitions
des diagrammes dtats-transitions) ou pour dcrire limplmentation dune opration
dun classeur.
Les diagrammes dactivits sont relativement proches des diagrammes dtats-transitions
dans leur prsentation, mais leur interprtation est sensiblement diffrente. En particulier,
ils offrent un support pour lexpression de mcanismes concurrents, mais ce nest pas l leur
fonction premire.
160
UML 2
Chapitre
2.2 UNE
VISION TRANSVERSALE, DCOUPLE DE LA VISION STRUCTURELLE

CLASSES/COMPOSANTS
La vision des diagrammes dtats-transitions est en effet oriente vers des systmes ractifs,
les transitions tant dclenches par la rception de sollicitations, sans que la source de
lvnement soit spcifie. Cela est bien adapt aux systmes concurrents, o chaque composant a son propre flot de contrle, par exemple les systmes bass sur des objets actifs ou
les systmes matriels. Leur avantage est de spcifier sans ambigut leffet de toute action
sur le composant, sans a priori sur le comportement de lenvironnement.
Mais ils ne donnent pas une vision satisfaisante dun traitement faisant intervenir plusieurs
composants ou classes, et doivent tre complts par des scnarios dinteraction, usuellement dcrits laide de diagrammes de squence. Au contraire, les diagrammes dactivits
permettent une description centre sur le traitement, en saffranchissant (partiellement) de
la structuration de lapplication en classeurs.
2.3 PROGRAMMATION
STRUCTURE
Un flot de contrle est associ chaque processus ou thread dune application : il reprsente
le curseur dexcution (program counter) qui excute les instructions dun programme.
un instant donn, il excute une certaine instruction ; le choix de linstruction suivante
excuter est dtermin par les structures de contrle du langage (if/else, for, while, switch/
case). Les activits capturent de faon graphique ce comportement a priori squentiel de
lexcution.
En mettant laccent sur le traitement, la vision des diagrammes dactivits se rapproche des
langages de programmation procduraux type C ou Pascal. Une activit se comporte par
bien des points de vue comme une procdure, possdant des arguments en entre et des
valeurs de sortie et pouvant causer des effets de bord sur les variables accessibles depuis leur
contexte. Il est possible, dans un premier temps, de raisonner purement sur les traitements
et, lors dune phase de conception dtaille, daffecter les diffrentes activits recenses des
classeurs du systme.
(3)
Flot de contrle
3.1 ACTIVIT
ET TRANSITION
La vision des diagrammes dactivits est centre sur les flots de contrle. On y trouve deux
lments fondamentaux :
Les activits, reprsentes par un rectangle aux coins arrondis, dcrivent un traitement.
Le flot de contrle reste dans lactivit jusqu ce que les traitements soient termins. On
peut dfinir des variables locales une activit et manipuler les variables accessibles
depuis le contexte de lactivit (classe contenante en particulier). Les activits peuvent
tre imbriques hirarchiquement : on parle alors dactivits composites.
Les transitions, reprsentes par des flches pleines qui connectent les activits entre
elles, sont dclenches ds que lactivit source est termine et dterminent la prochaine
activit dclencher. Contrairement aux activits, les transitions sont franchies de
manire atomique, en principe sans dure perceptible.
EXEMPLE
La commande
Cet exemple fait apparatre un certain nombre de possibilits des diagrammes dactivits. On
y trouve la description dun traitement Passer Commande. Les trois cadres, appels lignes
deau , permettent de situer les actions par rapport aux entits du systme : on identifie trois
intervenants dans ce traitement, savoir le client, le ser vice comptable et le service livraison.
Les cercles noirs pleins dsignent un tat initial, utilis pour dbuter le traitement. Les cercles
contenant un point noir dsignent des tats finaux, o le traitement est considr comme
termin.
Laction se droule comme suit : le client commence par passer une commande, ce qui donne
lieu llaboration dun devis par le service comptable. Llaboration du devis est elle-mme
dcompose en deux sous-activits : vrifier la disponibilit des produits commands et calculer le prix de la commande.
Pour mieux faire apparatre la transmission du devis au client, on fait figurer un nud
dobjets. Cela reprsente un flux de donnes changes entre le service comptable et le
client. Devis est le nom dune classe du systme : les flots de donnes sont typs. Le client
peut ensuite dcider de modifier sa commande (retour dans lactivit initiale Passer commande), de lannuler (passage dans ltat final, signifiant la fin de ce traitement), ou de valider le devis.
Sil valide, deux actions peuvent tre engages en parallle : la prparation de la commande par le service livraison et le traitement de la facturation et du paiement. Le ser vice
comptable cre une facture quil envoie au client (lobjet facture transmis est alors dans ltat
mise). Celui-ci effectue le paiement et renvoie la facture (qui se trouve prsent dans
ltat rgle).
Quand la commande est prte et le paiement du client confirm (synchronisation par rendezvous de ces deux activits), la commande est livre au client et le traitement sachve.
Notation
Une activit UML est reprsente par un rectangle aux coins arrondis (figure 5.3) et
contient la description textuelle des actions de base quelle ralise, ou simplement son nom
si le niveau de spcification nest pas encore assez prcis pour dtailler les actions. Aucune
syntaxe spcifique nest propose dans la norme pour lexpression de ces actions : on
utilise le plus souvent une syntaxe proche dun langage de programmation ou, dfaut,
du pseudo-code. Les activits sont lies par des transitions reprsentes par des arcs orients pouvant porter des gardes, qui reprsentent le cheminement du flot de contrle de
lapplication.
Certaines actions sont distingues par un graphisme particulier (figure 5.1).
162
UML 2
Chapitre
Figure 5.2
Client
Service comptable
Service livraison
La commande.
tat Initial
Passer Commande
Lignes deau
tablir Devis
Vrifier disponibilit
Sous-activit
Calculer Prix
[modifier]
Activit composite
Transition
Devis
Garde
Fork
Valider
Activit
[valider]
[annuler]
Facture
[mise]
tablir facture
Facture
[rgle]
Valider Paiement
Prparer Commande
Rgler facture
Nud Objet
Join
Invariant dtat
Livrer Commande
Clturer Dossier
tat final
Figure 5.3
Flot de contrle entrant
Notation
des activits.
Flot de contrle sortant
Prparer Commande
Activit
3.2 STRUCTURES
DE CONTRLE
Structure de contrle conditionnelle

La faon la plus naturelle dexprimer les conditions est dutiliser des transitions munies
dune garde : de telles transitions ne peuvent tre empruntes que si la garde svalue vrai.
Une garde est un test pouvant faire intervenir les variables accessibles depuis le contexte de
lactivit. En principe, une garde na pas deffets de bord, car elle peut tre value plusieurs
fois.
On peut ajouter une garde toute transition dun diagramme dactivits. Elle est note
entre crochets. Si plusieurs transitions sont simultanment franchissables, le choix de la
transition emprunte est indterministe ; en gnral, il est donc prfrable de sassurer
quune seule transition la fois est franchissable. On peut utiliser une clause [else] dans une
garde, qui est valide si et seulement si toutes les autres gardes des transitions ayant la mme
source sont fausses.
Les gardes peuvent porter sur des transitions ayant pour source une activit. Cependant, si
lon veut mieux mettre en valeur le branchement conditionnel, on peut utiliser un point de
jonction, reprsent par un losange. Les points de jonction expriment un aiguillage du flot
de contrle : ils peuvent avoir plusieurs transitions en entre comme en sortie. Ils ont la
smantique dun if/endif ou dun switch/case des langages de programmation. Ce sont des
tats dits de contrle (comme les tats initiaux ou finaux), dans lesquels le flot de
contrle ne sattarde pas : le franchissement dune transition entre une activit et la suivante
est globalement atomique, mme si lon traverse des points de jonction.
EXEMPLE
Le distributeur de billets
Cet exemple illustre diffrentes reprsentations des alternatives. Aprs la vrification prliminaire, deux activits sont potentiellement dclenches : la restitution de la car te si la vrification choue ou lactivit taper PIN (Personal Identification Number) sinon. Aprs le contrle
du code PIN, on trouve trois alternatives, connectes un point de dcision ; une seule
dentre elles sera utilise. Enfin, la note portant le mot-cl decisionInput indique que les
gardes sur les transitions aprs le point de choix comparent la variable autorisation accorde
oui ou non.
Cet exemple est modlis un niveau relativement lev dabstraction, les actions tant exprimes en langage naturel. Il dcrit de faon concise un comportement relativement complexe.
Ce niveau de description conceptuelle est bien adapt la spcification dtaille des cas
dutilisation, car il rsume de faon synthtique plusieurs scnarios.
164
UML 2
Chapitre
Figure 5.4
Le distributeur
automatique
de banque.
external
Client
Insrer Carte
Vrification prliminaire
[chec]
[else]
[Code faux et essai < 3]
Taper PIN
Contrler code
Avaler Carte
[else]
Saisir montant
[Code bon]
Obtenir Autorisation
[non]
Restituer Carte
decisionInput
Autorisation accorde
[oui]
Dlivrer Billets
Les points de dcision peuvent aussi modliser la fin dune alternative. On les appelle alors
points de dbranchement .
EXEMPLE
Compter les mots, les lignes, les caractres

Lexemple de la figure 5.5 illustre la possibilit de reprsenter le flot de contrle dun programme laide dun diagramme dactivits. Lactivit appele wc ralise le comportement de
loutil Unix wc (word count). On utilise ici la notation frame (qui sert aussi dans les diagrammes de squence) pour la reprsenter, et le strotype activity.
On dclare les variables locales de lactivit, nc, nw, nl, qui servent compter respectivement
le nombre de caractres, de mots et de lignes de lentre. On utilise une variable c de type
char pour stocker le dernier caractre lu de lentre (par la fonction getchar()). Ltat courant de la lecture (dans mot ou hors mot) est reprsent par une variable boolenne inWord.
On suppose ici que print, getchar, isWhitespace, lopration dincrment ++ sont fournies
(sous la forme dactions opaques).
Comme on le voit sur cet exemple, les diagrammes dactivits dun niveau de spcifi cation
dtaille permettent datteindre le pouvoir dexpression de langages de programmation
classiques.
Figure 5.5
Compter les lignes,
les mots et les
caractres.
nc : int ;
nw : int ;
nl : int ;
activity wc
nc = nw = nl = 0;
inWord = false;
c : char ;
inWord : bool
c = getchar();
nc++;
decisionInput
c
print nc nw nl;
[EOF]
[else]
decisionInput
isWhitespace(c)
[\n]
[else]
[true]
nl++;
inWord = false;
[inWord==true]
[else]
[else]
[inWord==false]
inWord=true;
nw++;
Activit structure
La norme prvoit galement des activits dites structures , qui utilisent les structures de
contrle usuelles (conditionnelles et boucle) travers une syntaxe qui dpend de loutil. La
syntaxe prcise de ces annotations, comme celle des actions de base, nest donc pas dfinie
dans la norme : on utilise du pseudo-code ou la syntaxe dun langage de programmation.
EXEMPLE
Avec une syntaxe C++, on dcrit une activit contenant une boucle (le calcul du prix total
dune facture) et une activit contenant une conditionnelle (une implmentation possible de
isWhitespace() de lexemple prcdent). Les arguments et valeurs de retour sont dcrits
laide de pins, prsents en dtail la section 3.4.
Figure 5.6
Activit structure.
total=0;
for (int i=lignes.size()-1 ; i >= 0 ; i--)
total += lignes[i].prixUnitaire * lignes[i].quantit
lignes : vector<ligneCommande>
if(c== || c== \t || c== \n )

return true;
else
return false;
total:float c : char
bool
Ce type dactivit est fourni par commodit, mais son utilisation rend peu visible le cheminement du flot de contrle.
3.3 ACTIVIT
ET CLASSEUR
Les activits peuvent tre utilises pour des descriptions de diffrents niveaux de dtails, de
la plus lmentaire (description conceptuelle dun comportement par exemple) la plus
fouille, faisant alors intervenir des actions UML pour tre la hauteur de ce que permet un
langage de programmation.
Une de leurs utilisations principales est de dcrire leffet doprations de classeur. Les activits peuvent, dans un premier temps, ne pas avoir un contexte bien dfini. Cest le cas dans
lexemple du distributeur de banque : le systme complet du DAB ntant pas encore
dcompos en sous-lments, seules les activits affrentes au client ont t places sur une
166
UML 2
Chapitre
ligne deau. Une description plus dtaille ncessiterait sans doute de dcomposer plus finement les actions, en vue de reprsenter plus explicitement les appels dopration sur les
composants du systme (lecteur de cartes, serveur dauthentification, imprimante pour le
ticket). Sur le diagramme de la figure 5.4, le mot-cl extern, sis au-dessus de la partition
du client, indique que ce dernier nest pas un lment du systme en cours de conception.
Les lignes deau (ou partitions) permettent dattribuer les activits des lments particuliers du modle. Une partition peut elle-mme tre dcompose en sous-partitions. La
liste suivante runit les types standard dune tiquette de partition :
Classeur. Les activits de la partition sont sous la responsabilit du classeur indiqu : le
contexte de lactivit est donc celui du classeur concern. Lappel effectif de lactivit dans
un scnario de comportement doit se faire sur une instance du classeur.
Instance. En plus des contraintes imposes par la notion de classeur, lappel effectif doit
se faire sur linstance cite.
Attribut et valeur. Ce cas est assez diffrent des prcdents. On a toujours au moins deux
niveaux de partition : la partition englobante donne le nom de lattribut concern, et ses
sous-partitions spcifient une valeur de lattribut.
EXEMPLE
Utilisation de partitions
Il est possible daffiner le modle de la commande prsent prcdemment en spcifiant plus
finement le type des lignes deau. Il sagit dindiquer, dune part, que les activits du service
comptable sont rattaches une instance qui a, pour lattribut libellService de type Service,
la valeur Service Comptable et, dautre part, que le client ne fait pas partie intgrante du
systme tudi.
Figure 5.7
Lignes deau.
external
Client
attribute libellService : Service

Service comptable
Service livraison
Les activits peuvent appartenir plusieurs partitions, si ces dernires fournissent une
information qui nest pas conflictuelle (par exemple, une activit donne ne peut appartenir
qu un unique classeur). On peut mme cumuler graphiquement des partitions en les
plaant horizontalement et verticalement.
EXEMPLE
Partitions multidimensionnelles
La version simplifie de la commande prsente la figure 5.8 exprime que la rception des
commandes se fait au sige social Paris, que la validation du paiement est ralise par le
service comptable de Roubaix, et que les commandes sont prpares et livres par un ser vice
livraison situ galement Roubaix. Lutilisation de partitions multidimensionnelles ne facilite
pas la lisibilit des diagrammes.
Figure 5.8
Client
Service comptable
Service livraison
Partitions
multidimensionnelles.
Valider Commande
Enregistrer Commande
Paris
tablir Facture
Facture
[rgle]
Valider Paiement
Prparer Commande
Clturer Dossier
Livrer Commande
Rgler Facture
Roubaix
"attribute" siteExploitation : Localisation
Facture
[mise]
Il est possible de spcifier la partition laquelle appartient une activit directement dans
ltiquette de lactivit, entre parenthses. Si une activit est ainsi tiquete, cette information prvaut sur lappartenance ventuelle une partition graphiquement reprsente.
EXEMPLE
Partition explicite
Cette notation est moins encombrante graphiquement, mais met moins bien en valeur lappartenance de groupes dactivits un mme conteneur.
Figure 5.9
external
(Client)
Rgler facture
Partition explicite.
3.4 ARGUMENT
(Service Comptable)
Etablir facture
(Service Livraison)
Livrer Commande
ET VALEUR RETOURNE
Si les diagrammes dactivits prsents jusquici montrent bien le comportement du flot de

contrle, le flot de donnes napparat pas clairement. Or, cest un lment essentiel des
traitements : si une activit est bien adapte la description dune opration dun classeur,
il faut un moyen de spcifier les arguments et valeurs de retour de lopration. Cest le rle
des pins, des nuds et des flots dobjets associs.
168
UML 2
Chapitre
Pin
Pour spcifier les valeurs passes en argument une activit et les valeurs de retour, on utilise des pins. Un pin reprsente un point de connexion pour une action : laction ne peut
dbuter que si lon affecte une valeur chacun de ses pins dentre ; quand elle se termine,
une valeur doit tre affecte chacun de ses pins de sortie.
La smantique associe est celle des langages de programmation usuels : les valeurs sont
passes par copie, une modification des valeurs dentre au cours du traitement de laction
nest visible qu lintrieur de lactivit.
Un pin est reprsent par un petit carr attach la bordure dune activit. Il est typ et
ventuellement nomm. Il peut contenir des flches indiquant sa direction (entre ou
sortie) si cela nest pas dtermin par le contexte dutilisation de lactivit.
EXEMPLE
Utilisation de pins
Soit lactivit reprsentant lopration produit entre deux entiers a et b. On utilise un pin pour
reprsenter chaque argument, et un pin de sortie pour reprsenter la valeur retourne.
Figure 5.10
a:int
Reprsentation
de pins.
res = a * b ;
res:int
b:int
Les valeurs associes aux pins peuvent tre utilises comme les variables du contexte dans les
traitements associs lactivit. Introduisez un pin par argument du traitement. Vous pouvez ainsi de dfinir des traitements paramtrs, ce qui manquait cruellement aux versions
prcdentes dUML.
Les pins servent galement reprsenter des mcanismes dexceptions. Un triangle signale
un pin dexception.
EXEMPLE
Reprsentation des pins dexceptions

La mthode elementAt de la classe Vector de la librairie standard Java renvoie llment du
vecteur situ lindice donn en argument, mais peut chouer si cet indice est ngatif ou
au-del de la taille courante du vecteur. On met alors une exception.
Figure 5.11
Pin dexception.
index:int
(java.util.Vector)
elementAt
IndexOutOfBoundsException
o : Object
Vous avez donc les moyens de reprsenter graphiquement une opration dun classeur, avec
sa signature complte : arguments, type de retour et exceptions potentiellement leves. Vous
avez en outre la possibilit de dfinir une activit comme appartenant une classe. En
conclusion, les mcanismes essentiels de la programmation oriente objet sont prsents
dans les diagrammes dactivits.
Nud et flot dobjets

Un flot dobjets permet de passer des donnes dune activit une autre. De fait, un arc qui a
pour origine et destination un pin correspond un flot dobjets. Le type du pin rcepteur doit
tre parent (au sens hritage) du type du pin metteur ; le flot dobjets est lui-mme typ.
Il est possible de mieux mettre en valeur les donnes par lutilisation dun nud dobjets
dtach dune activit particulire. Un nud dobjets, reprsent par un rectangle, est un
conteneur typ qui permet le transit des donnes. Il sert galement de stockage : il peut contenir plusieurs instances dobjet, la manire dun tampon (buffer).
Un nud dobjets (ou un pin) peut imposer des contraintes, que doivent vrifier les objets
quil contient. Elles sont exprimes sous la forme dinvariants dtat, nots entre crochets.
Implicitement, tout arc ayant pour source ou destination un nud dobjets est un flot
dobjets plutt quun flot de contrle. Un flot dobjets peut porter une tiquette mentionnant deux annotations particulires :
transformation indique une interprtation particulire de la donne transmise par le flot.
selection indique lordre dans lequel les objets sont choisis dans le nud pour le quitter.
Une annotation de slection peut galement figurer sur un nud dobjets : lordre spcifi est alors commun tout arc ayant pour source ce nud.
Figure 5.12
:Type1
:Type1
Deux notations pour

un flot de donnes.
Type1
Figure 5.13
Annotations des
flots de donnes
et invariants dtat.
selection
priorit maximale,
FIFO priorit gale
remplir
commande
:Commande
[remplie]
transformation
Commande.client
expdier
commande
clturer
commande
expdier
reu au client
:Commande
[clture]
:Commande
[remplie]
:Client
Enfin, certains flots dobjets correspondent mieux la notion de flot continu de donnes :
ils portent ltiquette {stream} ou ont pour cible un pin de type {stream} (reprsent par un
carr noir plein). Le comportement usuel dune activit consiste consommer un objet
sur chaque pin dentre, sexcuter et fournir une valeur sur chaque pin de sortie. Une
activit peut cependant consommer (respectivement mettre) plusieurs donnes sur ses
pins dentre (respectivement de sortie) qui sont du type stream.
EXEMPLE
Filtres Unix
La plupart des commandes standard Unix sont conues comme des filtres, qui lisent sur leur
entre standard stdin et crivent sur leur sortie standard stdout. Le signalement des erreurs
passe par un troisime flux : stderr. Il est possible de chaner les commandes, ce qui permet
de construire facilement des commandes plus puissantes.
Figure 5.14
Le chanage des
commandes tar
et gzip permet de
crer des archives
compresses.
"tar | gzip"
Liste<fichiers>
stdout
stdout
tar
gzip
stdin
stderr
stderr
stderr
{stream}
170
UML 2
stdout
deux notations
quivalentes de stream
Chapitre
(4)
Mcanismes avancs
Les constructions prsentes la section 3 sont suffisantes pour la majorit des usages.
Ce jeu dlments de base constitue le cur du formalisme des diagrammes dactivits. Il
est recommand de bien comprendre ces mcanismes avant daborder cette section, qui
prsente des concepts plus complexes proposs par les diagrammes dactivits.
4.1 CONCURRENCE
La vocation premire des diagrammes dactivits est de dcrire des traitements a priori
squentiels : on ne dbute lactivit aprs une transition que lorsque celle qui la prcde est
termine.
Cependant, il est possible de dcrire des mcanismes concurrents laide de diagrammes
dactivits. Cela ne signifie pas ncessairement que limplmentation est concurrente, mais
plutt que les actions dcrites ne sont pas lies par une dpendance causale : lordre dexcution na pas dincidence sur le comportement global.
Dans lexemple de la commande prsent la section 3.1, lactivit prparer commande peut
tre ralise avant ou aprs lactivit tablir facture, ou mme simultanment.
La gestion de la concurrence ajoute deux nouveaux lments graphiques aux diagrammes
dactivits :
Les barres de synchronisation. Elles sont reprsentes par une barre noire paisse et
courte. Plusieurs transitions peuvent avoir pour source ou pour cible une barre de synchronisation. Lorsque la barre de synchronisation a plusieurs transitions en sortie, on
parle de transition de type fork, qui correspond une duplication du flot de contrle en
plusieurs flots indpendants ; quand la barre de synchronisation est atteinte, un jeton de
contrle est produit sur chaque arc de sortie. Quand la barre de synchronisation a plusieurs transitions en entre, on parle de transition de type join, qui correspond un
rendez-vous entre des flots de contrle ; la transition ne peut tre franchie que si un jeton
de contrle est prsent sur chacune de ses entres. Pour plus de commodit, il est possible
de fusionner des barres de synchronisation de type join et fork, et donc davoir sur une
mme barre plusieurs transitions entrantes et sortantes. Dans tous les cas, le franchissement des transitions se fait de manire atomique, la barre de synchronisation ne stocke
pas les jetons : ils restent dans les activits en amont jusqu ce que la transition puisse
tre franchie.
Les nuds de contrle de type flow final. Ils sont reprsents par un cercle contenant une
croix et correspondent la fin de vie dun jeton de contrle. Un jeton de contrle qui
atteint un tel nud est dtruit. Les autres flots de contrle ne sont pas affects. Au
contraire, si un flot de contrle atteint un nud de contrle final, tous les autres flots
de contrle de lactivit sont interrompus et dtruits.
EXEMPLE
Fabrication dun produit manufactur

Cet exemple montre une barre de synchronisation de type fork et des nuds de contrle flow
final. Il reprsente une procdure de fabrication dun produit manufactur. Les pices ncessaires lassemblage sont produites squentiellement par lactivit Fournir pice. Ds quune
pice est prte, elle peut tre monte.
Le franchissement de la barre de synchronisation produit deux jetons de contrle : lun ralise
lactivit Monter pice, lautre soccupe de fournir la pice suivante si toutes les pices nont
pas encore t fournies. Quand il ne reste plus de pice fournir, le flot se termine. Lactivit
Monter pice peut avoir des dures variables ; chaque fois quelle se termine, on teste si le
montage est termin ou non. Une fois la dernire pice monte, le produit est emball et
lactivit englobante se termine.
Si ce diagramme suggre lexistence de concurrence, ce nest l quune possibilit dimplmentation : un seul oprateur physique peut raliser lensemble des activits (de faon squentielle)
sans dvier de la smantique du modle.
Figure 5.15
Fournir Pice
Mcanismes
exprimant la
concurrence.
Monter Pice
Emballer
[montage fini]
[else]
[manque pice]
[else]
Les barres de synchronisation permettent donc dexprimer que des actions peuvent dbuter
en parallle, alors que les transitions ordinaires des diagrammes dactivits imposent une
excution squentielle. Les transitions de type join imposent, au contraire, dattendre la fin
dun ensemble dactivits avant de poursuivre lexcution.
4.2 EXCEPTIONS
Les exceptions sont un concept important en programmation oriente objet : elles permettent dinterrompre un traitement quand une situation qui dvie du traitement normal se
produit et assurent une gestion plus propre des erreurs qui peuvent se produire au cours
dun traitement.
Un exemple typique est la gestion de la division par zro dans une opration arithmtique :
si lon dclare une opration float diviser (float dividende, float diviseur), comment signaler lappelant quune erreur de dbordement se produit quand le diviseur vaut zro ? On
ne peut utiliser une valeur de retour particulire que lappelant pourrait tester car toutes les
valeurs de retour sont potentiellement valides. La solution prconise est donc de recourir
une exception, qui ne correspond pas une valeur de retour de la signature normale de
lopration. Lappelant a alors le choix, quand il appelle lopration diviser, de traiter
lexception ou de la laisser remonter son propre appelant. Une exception qui nest traite
aucun niveau correspond une faute du programme. Dans la plupart des langages orients
objet, elle induit la fin du processus ; en UML, le comportement nest pas spcifi, mais le
modle est alors considr comme incomplet ou mal form.
Dfinition : gestion des exceptions

Toute activit peut avoir un ou plusieurs pins dexception (not par un triangle). La leve de
lexception se reprsente par une transition qui vise le pin dexception, ou par une annotation textuelle, dans le cas dactivits structures, dont la forme dpend de loutil utilis
(mot-cl throw par exemple).
Lorsquune exception est leve, lexcution de lactivit en cours est interrompue sans gnrer de valeurs de sortie. la place, un jeton de donnes reprsentant lexception est
gnr. Le mcanisme dexcution recherche alors un gestionnaire dexception susceptible
de traiter ce type dexception ou une de ses classes parentes. On dit dun gestionnaire
dexception (ou clause catch des langages de programmation) quil protge une activit.
172
UML 2
Chapitre
Dfinition : gestion des exceptions (suite)

On examine dabord lactivit qui a donn lieu la leve de lexception. Si un gestionnaire
dexception existe, il est invoqu avec pour argument ladite exception. Il doit avoir les
mmes pins de sortie, en nombre et en type, que le bloc quil protge. Un gestionnaire
dexception se reprsente par une activit ordinaire, munie dun pin dentre du type de
lexception quil gre, et lie au bloc (activit) quil protge par un arc en zigzag.
Quand lexcution du gestionnaire se termine, lexcution se poursuit comme si lactivit
protge stait termine normalement, avec les valeurs de sortie du gestionnaire en lieu et
place de celles du bloc protg. Il est inutile de faire figurer des transitions depuis lactivit
reprsentant le gestionnaire dexception.
Si lactivit qui a lev lexception nest pas protge, lexception interrompt lactivit englobante et un gestionnaire dexception est recherch ce niveau. Ce mcanisme de propagation se poursuit jusqu ce quun gestionnaire adapt soit trouv (ou que lon quitte
lapplication).
EXEMPLE
Traitement des exceptions dans le calcul du produit dune matrice par un vecteur
Cet exemple montre un mcanisme de gestion dexceptions. Lactivit protge calcule un produit dune matrice par un vecteur en deux tapes : on inverse dabord la matrice argument m,
puis on ralise le produit par le vecteur argument v.
Linversion de matrice est susceptible de lever une exception si lopration est impossible
(discriminant nul par exemple). Linversion et le produit sont susceptibles de provoquer un
dbordement de capacit de flottants. On protge lensemble du bloc par deux gestionnaires dexception distincts : selon lexception leve, on fournit une constante (de type vecteur)
diffrente.
Dans tous les cas, laction afficher vecteur est ralise la fin du traitement.
Figure 5.16
m : matrice
v : vecteur
Gestionnaire
dexception.
ExceptionMatriceSingulire
rendre la constante
vecteur1
inverser matrice
res : vecteur
: matrice
m : matrice
Deux notations quivalentes
v : vecteur
calculer produit
res : vecteur
rendre la constante
vecteur2
ExceptionDbordement
res : vecteur
afficher vecteur
Les exceptions sont des classeurs part entire et peuvent, ce titre, porter des informations
sous la forme dattributs, et des oprations. Vous pouvez galement dcrire des arbres
dhritage dexceptions. Cela permet de spcifier des messages dtaills associs aux erreurs
et des donnes supplmentaires dcrivant lesdites erreurs. Un gestionnaire dexception
spcifie le type dexception quil est capable de traiter : toute exception drivant de ce type
est galement traite par un tel gestionnaire.
EXEMPLE
Spcification des exceptions Java

Cet extrait de la spcification des exceptions Java illustre le fonctionnement des arbres dhritage dexceptions. Toutes les exceptions en Java drivent de la classe Exception du paquetage java.lang ou de linterface Throwable du mme paquetage. Linterface Throwable dfinit
des oprations permettant de dterminer lorigine de lexception, telles que printStackTrace,
qui affiche les numros de ligne du source qui ont abouti la leve de lexception. La classe
Exception est munie dun message s, qui dcrit prcisment lexception leve.
Les exceptions correspondant des problmes dentre/sortie drivent de la classe IOException. Parmi ces erreurs, la classe InterruptedIOException porte un attribut qui indique ltat du
transfert de donnes au moment de la leve de lexception. Un gestionnaire dexception qui
accepte en entre la classe gnrale Exception est aussi capable de grer des IOException,
des EOFException, etc.
Figure 5.17
Hritage et
exceptions.
interface
Throwable
+printStackTrace()
...
Exception
IOException
message : String
+getMessage ()
InterruptedIOException
EOFException
bytesTransferred : int
Rgion interruptible et interruption

Le mcanisme de gestion dexceptions permet de les reprsenter telles quon les trouve dans
les langages de programmation objet. UML propose un deuxime mcanisme analogue,
mais moins prcis, de gestion des interruptions : les rgions interruptibles. Il est mieux
adapt aux phases de modlisation conceptuelle ou de modlisation mtier, qui demandent
une moins grande prcision. Le but est de reprsenter graphiquement un enchanement
nominal et une alternative qui interrompt le cours du traitement.
Une rgion interruptible est reprsente par un cadre arrondi en pointills. Si lvnement
dinterruption se produit, toutes les activits en cours dans la rgion interruptible sont stoppes et le flot de contrle suit la flche en zigzag qui quitte la rgion. Aucune contrainte sur
la suite du traitement nest impose : a priori, lactivit ainsi interrompue nest pas reprise.
Cette smantique est diffrente de celle des gestionnaires dexception et correspond mieux
aux interruptions dans les activits mtier.
EXEMPLE
174
UML 2
Dans cet exemple, lactivit dbute la rception dune commande dun client. Toute la suite
de lactivit grer commande est interruptible : le client est libre dannuler sa commande
tout moment. Sil passe lordre dannuler, le dossier est effac. Une fois que le paiement
est effectif et que la commande est prte, il devient impossible de lannuler : la transaction est
dment enregistre et le dossier cltur.
Aprs rception dun ordre dannulation, et durant lactivit annuler dossier, lactivit traiter
paiement peut continuer sexcuter. Cependant, elle est, elle aussi, interrompue quand le
flot de traitement a fini dannuler le dossier et que ltat final est atteint (cela termine tous les
flots de lactivit).
Chapitre
Figure 5.18
activity grer commande
Rgion interruptible.
Ordre dannuler
Commande
crer dossier
prparer commande
annuler dossier
clturer dossier
traiter paiement client
4.3 SQUENCE
ET ITRATION
Une zone dexpansion, graphiquement reprsente par un cadre en pointills, exprime une
action rpte sur chaque lment dune collection. Une collection peut tre implmente
par un tableau ou une liste par exemple. Le type des objets contenus dans la collection doit
tre connu. La collection est passe la zone dexpansion travers un pin dexpansion, graphiquement reprsent par un rectangle divis en compartiments, cens voquer la notion
de liste dlments.
Lactivit lintrieur de la rgion dexpansion est excute une fois pour chaque item de la
collection, la manire dun foreach des langages Python, Perl ou Fortran. Cette activit
interne doit prendre en entre un objet respectant le type de la collection : vu de lextrieur
de la rgion, le pin dexpansion est de type Collection<Objet>, mais vu de lintrieur, il est de
type Objet. chaque excution de lactivit interne, sa valeur de retour est insre dans la
collection de sortie la mme position (indice) que son entre. Lactivit interne peut galement se terminer sans rendre de valeur, ce qui correspond un mode filtre : la collection
rsultante compte alors moins de valeurs que lentre.
Une zone dexpansion peut tre de lun des trois types suivants, signal par un mot-cl plac
dans langle de la rgion dexpansion :
parallel. Les excutions de lactivit interne sur les lments de la collection sont indpendantes et peuvent tre ralises dans nimporte quel ordre ou mme simultanment.
Une implmentation sur une architecture parallle peut donc efficacement raliser ce
traitement.
iterative. Les occurrences dexcution de lactivit interne doivent senchaner squentiellement, en suivant lordre de la collection dentre. Si cette dernire na pas dordre de
parcours bien dfini (table de hachage par exemple), un ordre quelconque est choisi
de faon indterministe.
stream. Les lments de la collection sont passs sous la forme dun flux de donnes
lactivit interne, qui doit tre adapte aux traitements de flux. Cela permet de contrler
plus finement le paralllisme des excutions.
EXEMPLE
Passer un texte en majuscules

Cette activit permet de passer un texte en majuscules. Quel que soit lordre des traitements,
le rsultat est correct. Elle porte donc le mot-cl parallel.
Figure 5.19
string : char[]
Zone dexpansion.
parallel
c : char
if (c >= a && c <= z)
return c-a+A;
else
return c;
:char
: char[]
UML 2 a introduit le mcanisme des zones dexpansion pour permettre une meilleure
expression du paralllisme des actions.
Conclusion
La vue offerte par les diagrammes dactivits est centre sur les traitements. Elle permet de
modliser efficacement le cheminement de flots de contrle et de flots de donnes. Les
apports importants dUML 2 au niveau de ces diagrammes assurent lexpression prcise du
comportement : la gnration de code est un objectif central dans ces diagrammes.
En fournissant une vision abstraite des traitements, la modlisation des activits ne fixe
cependant pas compltement les choix dimplmentation. Lexpression de mcanismes
concurrents, par exemple, nimpose pas leur ralisation sur une architecture parallle. De
mme, la manipulation de variables multivalues et de collections permet un bon niveau
dabstraction.
Les diagrammes dactivits sont particulirement utiles dans la phase de conception pour la
description dtaille des cas dutilisation. On utilise alors une syntaxe libre, qui dcrit des
actions conceptuelles de haut niveau. Ils sont galement utiles dans la phase de ralisation
pour la description prcise des traitements, avec un niveau de dtails qui se rapproche dune
spcification pleinement excutable. On utilise alors une syntaxe inspire dun langage de
programmation pour dcrire les actions et lon peut prciser finement la gestion des exceptions ou le passage des paramtres.
La description graphique des traitements permet de mieux cerner le cheminement des alternatives. Les mcanismes dimbrication et dappels (call) permettent de prserver une certaine
concision. Cependant, vitez les diagrammes dactivits quand le traitement est trs linaire :
une description textuelle de lenchanement est alors suffisante dans la plupart des cas.
Arriv ce stade du livre, sept diagrammes ont t prsents : le diagramme des cas dutilisation, celui des classes et des objets, le diagramme de squence et de communication, le
diagramme dtats-transitions et, enfin, le diagramme dactivits. Ils permettent de modliser quasiment tout systme. Deux autres diagrammes ont volontairement t relgus dans
les annexes : le diagramme de composants et celui de dploiement. Ils sont, en effet, suffisamment simples pour ne pas faire lobjet dun chapitre entier. Le chapitre suivant, quant
lui, prsente comment tous ces diagrammes sassemblent et se compltent pour donner une
vision globale et cohrente dun systme. La partie pratique de ce chapitre est constitue
dune tude de cas.
176
UML 2
Chapitre
Problmes
et exercices
Les exercices suivants couvrent les principaux concepts des diagrammes dactivits.
EXERCICE 1
PROGRAMMATION
EN ACTIVITS
1. Les chanes de caractres du langage C sont codes comme un tableau de caractres non
nuls, termin par un caractre \0. Par exemple, la chane s="hello!" est code
comme suit :
s[0]
s[1]
s[2]
s[3]
s[4]
s[5]
s[6]
\0
Dcrivez une activit implmentant la fonction strlen, qui prend en entre un tableau
de caractres et rend un entier correspondant la taille de la chane. Exemple :
strlen("hello!")=6.
2. Proposez le diagramme dactivits qui compte les mots, les lignes et les caractres de
son entre.
La fonction getchar() lit le prochain caractre disponible sur lentre. Sil sagit du
caractre spcial EOF, le programme affiche ses rsultats et se termine.
Lopration bool isWhitespace(c:char) rpond vrai si le caractre pass en argument
est considr comme un espace.
1. Le traitement est relativement simple : on itre sur le tableau de caractres de lentre ;
quand la valeur du caractre est \0, on rend lindex courant. Une implmentation efficace en C manipulerait plutt deux pointeurs sur caractre que lindice len, mais cela
suppose lexistence doprations arithmtiques sur les pointeurs, absentes en UML.
Figure 5.20
char[] s
decisionInput
s[len]
len++
len=0
[else]
[\0]
int len
2. Une solution est propose la figure 5.5.
Exercices
Calcul de la longueur
dune chane de
caractres.
EXERCICE 2
VENTE
EN LIGNE
Un site de vente en ligne propose des produits, placs dans un panier virtuel tandis que
lutilisateur navigue. Pour valider ses achats, il clique sur le bouton Sortir du magasin. On lui
propose alors de se connecter un compte existant, ou den crer un sil nen a pas encore.
Pour crer un nouveau compte, lutilisateur doit fournir une adresse de messagerie, qui
sert galement de login, son nom et son adresse, ventuellement une adresse de livraison,
et ses coordonnes bancaires. On prvoit le cas o ladresse de messagerie est dj associe
un compte. Si la validation de ces informations russit, on cre un nouveau compte et
lon propose lutilisateur de sy connecter.
On passe ensuite la confirmation des achats.
Modlisez cette procdure laide dun diagramme dactivits.
Lnonc est suffisamment vague pour donner lieu de nombreuses interprtations. Cela
est typique dune spcification textuelle des besoins, telle quon en trouve dans un cahier des
charges. La solution propose ici fixe donc un certain nombre de choix dorganisation de la
procdure.
On se concentre sur la partie concernant lauthentification de lutilisateur, et la cration
dun compte le cas chant.
Figure 5.21
Une interface web
pour lauthentification.
confirmer des achats
remplir panier
loger utilisateur
[else]
[compte invalide]
[oui]
compte existant?
saisie login,
mot de passe
[non]
[adresse connue]
crer le compte
saisie email
[else]
mot de passe perdu?
saisie nom, adresse

[adresse diffrente]
modifier
adresse de livraison
178
UML 2
saisie rfrences bancaires
Chapitre
Lorganisation propose correspond une interface de type wizard : il faut valider tous
les champs dune page, cliquer sur Suivant, pour passer la validation des prochains champs.
Si les informations sont incorrectes, un message avertit lutilisateur et lcran suivant saffiche.
Cette vrification des champs nest donc pas reprsente ici : il revient lactivit de saisie de
se terminer quand la saisie est valide.
Chaque activit correspond donc assez bien un cran dinterface, les transitions exprimant
une navigation possible entre ces crans. Vous pourrez rutiliser ces activits ailleurs. Par
exemple, la modification de ladresse de livraison est accessible depuis un menu quand lutilisateur est connect son compte.
Ce niveau de description est bien adapt la description dinterfaces homme-machine et
permet de se concentrer sur la vision logique dun traitement, sans se perdre dans le modle
structurel en classes.
ALGORITHMIQUE
Les diagrammes dactivits permettent de raisonner sur des algorithmes, au cours de lactivit de spcification dtaille.
Vous allez utiliser les diagrammes dactivits pour dcrire des algorithmes de tri.
1. laborez une activit swap qui prend trois arguments, un tableau tab et deux indices a
et b, et change le contenu de la case tab[a] et tab[b].
2. En utilisant swap, dcrivez un tri par bulles dun tableau tab de taille n. Lalgorithme
consiste en n 1 parcours du tableau, chacun amenant (par des appels successifs swap
sur des cases contigus) le plus grand lment du tableau en dernire position (donc en
position n 1 i litration numro i).
3 .Lalgorithme glouton du tri par bulles est peu efficace, en raison du grand nombre de
copies inutiles ralises. crivez un tri par insertion, qui opre en n itrations : chaque
itration de numro i, considrez la plage de valeurs de 0 i 1 comme trie. Lalgorithme consiste chercher le bon endroit o insrer la valeur en position i, afin de trier
la plage de valeurs de 0 i. Copiez la valeur en position i dans une variable temporaire
et dcalez les valeurs avant cette position vers la droite (une par une) jusqu trouver
lendroit ou recopier la valeur de la variable temporaire.
4. Lalgorithme prcdent a encore une complexit leve. Les tris les plus efficaces sont
fonds sur des appels rcursifs qui font chuter la complexit. La fusion de deux tableaux
tris en un tableau tri est une opration de complexit linaire sur la taille du tableau
rsultant. Pouvez-vous concevoir un algorithme (tri par fusion) qui sappuie sur cette
proprit et des appels rcursifs pour trier plus efficacement un tableau ? Indication :
vous pouvez dfinir une activit tri fusion qui prend un tableau t et deux indices, g et d,
et trie la portion du tableau comprise entre les indices g et d.
Notons que les algorithmes prsents ici sont fonds sur le trs classique livre Le Langage C,
de Kernighan et Ritchie. La lecture compare des versions en C et en diagrammes dactivits
est instructive.
1. Utilisez une variable temporaire pour stocker lune des deux valeurs des variables
changer avant de lcraser en la remplaant par la valeur de lautre variable. Ce diagramme met bien en avant le flot des valeurs. La variable temporaire est reprsente par
un pin.
Exercices
EXERCICE 3
Comme vous navez pas plus de prcisions sur le type des objets contenus dans le tableau,
utilisez un template pour reprsenter ce type : lopration est en effet gnrique et valable
quel que soit le type T contenu dans le tableau.
Figure 5.22
change de valeurs
de deux variables.
swap
a : int
tmp:T
tmp = T[a]
tab : T[]
T[a] = T[b]
T[b] = tmp
b : int
2. Le diagramme de la figure 5.23 prsente une structure intressante pour la reprsentation

de boucles, qui fait apparatre clairement les deux boucles imbriques. Les cycles dans
le graphe traduisent le phnomne de bouclage , et limbrication est visible grce la
hirarchie.
Le placement des objets constituant les boucles (corps de boucle, condition darrt)
est reconnaissable visuellement ; il est rutilis plusieurs fois dans les diagrammes qui
suivent.
Deux points de dcision font apparatre plus clairement la fois le dbut et la fin de
lalternative dans la boucle interne.
Une nouvelle contrainte sur le type contenu dans le tableau impose que ce type soit muni
dune relation dordre total pour que puisse soprer la comparaison de ses lments.
Indiquez-la en mentionnant que le type T doit raliser linterface Comparable. (Voir aussi
la section 3.3 et lexercice 4 du chapitre 3.)
Figure 5.23
incrment entre chaque boucle
condition darrt
Tri par bulles .
Comparable T
Tri bulles
i : int
i++
j : int
tab : T[]
j++
[i <= n]
i=1
[else]
[else]
j=1
swap(j-1,j,tab)
[j<= i]
[else]
[ tab[j-1]>tab[j] ]
n : int
initialisation
180
UML 2
corps de boucle
si la valeur est plus petite

que la voisine de droite...
on les change
Chapitre
3. Cette version du tri limite le nombre de copies intermdiaires de valeur. Elle ralise un
roulement des variables (au lieu de les changer deux deux) qui dplace tout un bloc
avant de recopier la variable temporaire.
La structure de lalgorithme reste assez proche du tri par bulles. De ce fait, il a la mme
complexit thorique en O(n2) en nombre doprations que le tri par bulles, mais ralise
un peu moins de copies que lui. Vous vous en apercevrez en comparant les deux
schmas : limbrication des deux boucles apporte le facteur n2 et les diffrences entre
les actions dans chaque boucle napportent quun facteur constant, donc thoriquement
ngligeable en complexit.
Figure 5.24
copie dans le temporaire

= crer un trou
Tri par slection.
teste si la bonne position du

trou est atteinte
Comparable T
Tri par insertion
i : int
i++
tab : T[]
tmp : T
j : int
j-[i <= n]
i=1
tmp = tab[i]
[j>0 et t[j-1]>tmp]
[else]
j=i
tab[j] = tab[j-1]
[else]
tab[j] = tmp
n : int
recopier le temporaire dans le tableau

= remplir le trou
dcaler droite la valeur (en crasant)

= dcaler le trou gauche
4. Le tri par fusion permet de montrer la modlisation de concepts algorithmiques avancs,

en particulier la rcursivit et le paralllisme. Ce type de tri est relativement puissant : il a
une complexit comparable au quicksort, devenu standard, et se prte galement une
implmentation sur des listes chanes. Cest rcemment devenu lalgorithme de tri
standard (au lieu de quicksort) du langage Perl par exemple.
Comme le montre le diagramme prsent la figure 5.25, il est possible de limplmenter
avec des traitements en parallle, ce qui se prte aux architectures parallles. Pour autant,
il nest pas obligatoire de limplmenter avec du paralllisme : toute excution qui respecte
lenchanement des actions et les barres de synchronisation est correcte.
Lalgorithme correspond lapproche diviser pour rgner . chaque profondeur dans

lappel rcursif, vous triez un tableau deux fois plus petit : la moiti du tableau prcdent.
La complexit thorique totale des traitements nest quen O(n log n), au lieu de O(n2),
comme les deux algorithmes prcdents.
Exercices
Les numros indiqus ct des pins donnent lordre des arguments. Lappel rcursif est
reprsent comme un appel de fonction normal.
Figure 5.25
Tri par fusion.
cas terminal pour la rcursion : un tableau

un seul lment est dj tri.
trouver le milieu m de lintervalle

trier
tri rcursif des deux moitis

Comparable T
Tri fusion
m : int
s : int [d-g+1]
m = (g+d)/2
tri fusion (t,g,m)
[d <= g]
i : int
j : int
1
t : T[]
2
g : int
3
d : int
tri fusion (t,m+1,d)
i : int
j : int
i++
j++
[i<=m]
i=g
j=0
i-j++
[i>m]
i=d
j=m-g+1
s[j]=t[i]
[else]
Attention, i dcroit :
deuxime moiti copie
en ordre inverse !
s[j]=t[i]
[else]
copies dans s des deux moitis

i : int
j : int
k : int
i++
t[i]=s[k]
k--
i=g
j=0
k=d-g
[else]
[else]
[i<=d]
fusion des moitis tries

et recopie dans t
EXERCICE 4
t[i]=s[j]
j++
[ s[j] <= s[k] ]
On part des deux extrmits de s dindices j et k

et on copie dans t[i] le plus petit des deux
VIDOCLUB
En vous basant sur la description textuelle du vidoclub de lexercice 5 du chapitre 1,
reprsentez par un diagramme dactivits le cas dutilisation Emprunter une vido .
La description des cas dutilisation est lune des applications immdiates des diagrammes
dactivits. Elle permet daccompagner la description textuelle par un schma synthtique,
mais ne la remplace pas.
182
UML 2
Chapitre
Figure 5.26
Exception E3
(client)
introduire carte
Le cas dutilisation
Emprunter vido .
Exception E1
valider carte
15 secondes
[carte invalide]
[else]
valider crdit
suprieur ou gal
un euro
avaler carte
(client)
prendre carte
Alternatif A1
[else]
proposer rechargement
[crdit suffisant]
Exception E4
rechercher video
jecter carte
[annulation]
dlivrer cassette
15 secondes
avaler cassette
annuler opration
(client)
prendre cassette
Exception E2
afficher temps
et prix de location
On retrouve sur ce diagramme la fois la squence nominale et les diffrents enchanements

alternatifs et dexceptions. On distingue les actions se rapportant au client, qui ne fait pas
directement partie du systme.
valeur dexemple, deux mcanismes diffrents sont utiliss pour reprsenter le dlai de 15
secondes pendant lequel le client rcupre sa cassette ou sa carte.
Dans le premier cas, une exception gre cet vnement : cela permet, en cas de leve de
lexception, de reprendre le traitement au mme point que si le client avait rcupr sa cassette et denchaner sur jecter carte.
Dans le deuxime cas, deux actions sont mises en concurrence : prendre carte et le time event
de 15 secondes. Lastuce ici est que le premier flot de contrle qui atteint le nud final force
la terminaison de tous les autres flots. Si ce comportement nest pas celui souhait, il faut
utiliser un nud flow final (cercle avec une croix) pour terminer un flot sans affecter les
autres flots de la rgion.
CACHE DOPRATIONS
Cet exercice aborde la modlisation dun mcanisme de cache, permettant de limiter le cot
des calculs rpts. Cette stratgie est trs utile pour les calculs coteux en temps, mais
consomme en contrepartie plus de mmoire.
Exercices
EXERCICE 5
Cet exercice propose de modliser un mcanisme de cache. Une classe Map reprsente une
table associative. Elle contient conceptuellement des couples <cl,valeur>. La recherche de
la valeur associe une cl donne (opration get) est trs rapide (complexit thoriquement constante, quel que soit le nombre de couples dans la table). Une seule valeur peut
tre associe chaque cl distincte : si une valeur est dj associe la cl, lopration put
dajout la table crase lancienne valeur. Les tables de hash ou les arbres de recherche sont
des implmentations frquemment rencontres de tables associatives.
Figure 5.27
Les classes
proposes pour
implmenter
un cache.
Map
Object get (Object key)
Object put (Object key, Object value)
postcondition
si la cl key nest pas dans la table rends la rfrence nulle.
sinon rends la valeur associe la cl key
postcondition
la valeur value t associe la cl key dans la table.
{abstract}
Cache
-map : Map
Fonction2
#Object doComputation (Object)
Ralisent un
calcul coteux
+Object compute (arg: Object)

Fonction1
#Object doComputation (Object) {abstract}
#Object doComputation (Object)
Vous allez raliser une classe abstraite Cache qui offre ses classes drives une fonctionnalit de cache. Elle est munie, pour cela, dune instance de la classe Map, qui sert stocker
les rsultats dj calculs par cette instance de fonction.
Les classes drives de Cache ralisent un calcul coteux en temps. De telles classes, qui
servent raliser un calcul, sont parfois appeles foncteurs . Elles doivent implmenter
lopration de visibilit protge doComputation (coteuse). Elles offrent publiquement
lopration compute aux utilisateurs de la fonction.
1. Dcrivez laide dun diagramme dactivits le comportement de lopration compute.
2. Prvoyez que largument pass compute nest pas du bon sous-type de Object pour la
fonction concrte. Si cest le cas, lopration doComputation risque de lever une exception
de typage quand elle essaie dinterprter lobjet pass en argument (ClassCastException
par exemple en Java standard). Pour offrir une gestion propre, si une erreur de ce type se
produit, vous voulez que compute lve une exception (non standard) de type TypeException. Enrichissez le diagramme prcdent pour reprsenter ce mcanisme.
1. Lopration compute cherche si le rsultat de lopration a dj t calcul pour son argument. Si cest le cas, elle rend la valeur stocke dans le cache. Sinon, elle ralise le calcul
par un appel la fonction abstraite doComputation. Ensuite, elle ajoute ce nouveau rsultat dans la table avant de le rendre lappelant.
184
UML 2
Chapitre
Figure 5.28
Comportement
associ lopration
compute du cache.
arg : Object
(Cache)
compute
[else]
res = map.get (arg)
res = doComputation (arg)
[res != null]
map.put(arg,res)
res: Object
2. Supposez que doComputation peut lever une exception : il faut protger lactivit qui
appelle cette fonction par un gestionnaire dexception. Enrichissez donc le diagramme en
ajoutant ce gestionnaire et un pin pour reprsenter la nouvelle signature complte (avec
lexception TypeException) de compute. Le corps du gestionnaire dexception se contente
de lever lexception approprie : lopration dajout dans la table qui suit lactivit
doComputation nest pas ralise.
Figure 5.29
(Cache)
compute
raise TypeException
arg : Object
:ClassCastException
:TypeException
[else]
res = map.get (arg)
res = doComputation (arg)
[res != null]
res: Object
map.put(arg,res)
Exercices
Opration compute
avec la gestion des
exceptions.
Chapitre
UML en pratique
1. Un processus pour la
modlisation dun systme ...... 188
2. Guide mthodologique ........... 189
tude de cas ............................... 196
Les principaux diagrammes raliss avec UML ont t

prsents dans les chapitres prcdents. Or, les modles
labors avec ces diffrents diagrammes sassemblent et se
compltent pour donner une vision globale et cohrente dun
systme. Dautre part, la modlisation dun systme nest
pas un processus linaire (o les modles sont labors
selon un enchanement immuable), mais au contraire un
processus itratif, voire incrmental. Ainsi, lordre de
prsentation des diagrammes dans les chapitres prcdents,
sans tre dnu dintrt, est quelque peu arbitraire,
et ne dfinit pas un processus immuable applicable
la modlisation de nimporte quel systme. Ce chapitre
prsente un processus qui est suffisamment gnral pour
convenir, moyennant quelques adaptations, la plupart
des problmes. Dans la partie exercices, ce processus est
illustr par une tude de cas.
187
(1)
Un processus pour la modlisation dun

systme
limage des langages de programmation qui permettent de dvelopper des applications
pour tous les domaines, UML est un langage capable de dcrire nimporte quel systme. Ses
lments de base (les rectangles qui reprsentent des classes, les traits qui matrialisent des
associations entre classes, etc.) sassemblent pour former des diagrammes. Un diagramme
est un modle. laborer tous les modles donne lassurance davoir une vision complte dun
systme, mais parfois, une vision partielle suffit. Le modlisateur est donc libre de choisir les
modles qui conviennent une application particulire. Cest cette libert de choix qui fait
la force dUML. A contrario, cet aspect bote outils en fait un langage difficile appliquer :
le modlisateur dbutant se trouve souvent perdu face tant de possibilits.
La richesse dUML se retrouve dans la profusion de diagrammes quil permet de construire :
diagramme de cas dutilisation ;
diagramme de classes et dobjets ;
diagramme dinteraction (diagrammes de squence, de communication, de timing) ;
diagramme dtats-transitions ;
diagramme dactivit ;
diagramme de composants ;
diagramme de dploiement.
Les deux derniers diagrammes de la liste, que nous navons pas encore abords, sont dcrits
la fin de louvrage.
Ce nombre important de diagrammes pose la question de lordre dans lequel il faut les
laborer. Y a-t-il une marche suivre ? Un processus immuable ? videmment, et malheureusement non ! La diversit des systmes modliser rend illusoire la dfinition dun tel
processus. Toutefois, dfaut dtre immuable, la marche suivre doit respecter les tapes
du cycle de dveloppement dun systme :
planification du projet ;
phase danalyse ;
conception ;
implmentation ;
tests ;
dploiement ;
maintenance.
La planification du projet comprend notamment la dfinition du problme, ltablissement
dun calendrier ainsi que la vrification de la faisabilit du projet. Lanalyse permet de prciser ltendue des besoins auxquels doit rpondre le systme, puis de spcifier et de comprendre ce que doit faire ce systme (sans se proccuper de la ralisation). La conception dfinit
comment le systme va tre ralis (cest ltape o des choix techniques sont faits). Limplmentation, quant elle, correspond la ralisation du systme (dans le cas dun logiciel, il
sagit de la phase dimplmentation dans un langage de programmation). Les tests permettent, avant la mise en production, de vrifier ladquation entre la solution et les besoins
initiaux. Enfin, la maintenance permet de conserver en tat de marche un systme en
production.
188
UML 2
Chapitre
UML couvre la plupart des tapes du cycle de vie dun projet (figure 6.1).
Figure 6.1
planification
La place dUML
dans le cycle de
dveloppement
dun systme.
analyse
UML
conception
implmentation
tests
dploiement
UML
maintenance
Historiquement, cest dabord durant la phase danalyse quUML a t utile. La version 2

dUML a considrablement tendu le langage, notamment avec lapparition des classeurs
structurs qui sont utiles en phase de conception. Cependant, il est encore trop tt pour
affirmer quUML va simposer comme un standard dans ce domaine. Dautre part, lOMG,
lorganisme qui supporte UML, a lambition dviter la rupture trop brutale qui a toujours
exist entre les phases de modlisation et la phase dimplmentation (l o UML est abandonn au profit dun langage de programmation). Son objectif est quUML puisse, terme,
tre utilis tout au long du cycle de vie dun projet, y compris pour donner une implmentation un systme, ce qui nest pas le cas aujourdhui. En revanche, le langage permet
depuis longtemps de reprsenter un systme tel quil sera dploy grce aux diagrammes de
dploiement (voir lannexe D). De plus, les scnarios qui prsentent des ralisations des cas
dutilisation (sous forme textuelle, avec des diagrammes de squence ou dactivit) peuvent
servir de base pour dfinir les tests du systme implment.
La recherche dun processus unifi qui sadapte tous les projets a donn lieu de nombreux travaux. Parmi ceux-ci, deux se distinguent : le RUP (Rational Unified Process) et le
MDA (Model Driven Architecture). Lampleur de ces travaux dpasse le cadre de ce livre,
aussi, nous nous contenterons dans ce chapitre de dcrire une mthode relativement simple,
mais largement utilise dans le domaine du dveloppement de logiciels [Blaha 2005]. Elle
est illustre par une tude de cas dans la partie exercices de ce chapitre.
(2)
Guide mthodologique
Considrons un projet de dveloppement dun systme logiciel. La premire tape du cycle
de vie, la planification, a permis de dfinir le problme, dtablir un calendrier, et de vrifier
la faisabilit du projet. Notre description commence ltape danalyse. Rappelons quelle
sert prciser le besoin auquel doit rpondre un systme, et spcifier et comprendre ce
que ce systme doit faire.
Remarque
La description qui suit est succincte mais assez complte car nous dcrivons toutes les tapes
dun processus (mme celles o UML nest daucune utilit), afin que vous puissiez vous rendre compte de la porte, mais galement des limites dUML. Nous insistons particulirement
sur les phases danalyse et de conception car cest l o UML est le plus utile. La phase de
dploiement est aborde dans lannexe D et dans ltude de cas. Des indications sur la
faon dimplmenter un diagramme de classes dans un langage de programmation objet
sont galement donnes dans lannexe E.
UML en pratique 189
Remarque (suite)
Nous avons spar la description du processus de ltude de cas, afin de ne pas encombrer
la partie thorique (et donc gnrale) avec des dtails lis une application. Cependant,
nous conseillons, lors de la premire lecture, de ne pas parcourir dune seule traite la par tie
cours avant de passer ltude de cas. Il vaut mieux alterner partie thorique et mise en
pratique. Plus tard, le lecteur pourra revenir sur la partie thorique seule, quil verra alors
comme le rsum dune mthode.
2.1 PHASE DANALYSE

Le concept de rutilisabilit, qui consiste reprendre une partie dun logiciel pour lutiliser
dans une autre application, et le concept dvolutivit, qui permet dajouter des nouvelles
fonctionnalits un logiciel existant, ont t des raisons fondamentales au dveloppement
de lapproche objet du gnie logiciel. Pour tre effectifs dans une application, ces mcanismes doivent tre mis en place ds la phase danalyse. Il faut sparer ltude du domaine de
lapplication de lapplication elle-mme. Le domaine, cest par exemple celui dune banque,
et lapplication, un logiciel de gestion de comptes bancaires : dune application bancaire
une autre, le domaine ne va pas changer car cest toujours dune banque quil sagit.
La phase danalyse dun logiciel se compose de deux parties :
lanalyse du domaine de lapplication ;
lanalyse de lapplication.
Analyse du domaine de lapplication

Cest durant la phase danalyse du domaine quune premire version du diagramme de classes
est labore. Ce modle doit capturer les classes qui modlisent des entits prsentes dans le
domaine de lapplication. Cette premire version du diagramme de classes est btie avec des
experts du domaine (des banquiers pour un systme bancaire par exemple). Ce modle est
labor plutt au dbut de la phase danalyse, et, en tout cas, indpendamment de la phase
danalyse de lapplication : le modle du domaine sera ainsi plus stable, et il pourra facilement voluer car il sera indpendant des dtails de lapplication (le modle du domaine ne
sintresse pas aux fonctionnalits de lapplication). Aprs avoir labor le modle des classes
du domaine, lanalyse se poursuivra par la construction de diagrammes dtats-transitions
pour les classes ayant des tats complexes.
Modle des classes du domaine. Le chapitre 2 donne des indications pour construire un
diagramme de classes. La dmarche pour btir le diagramme de classes du domaine est la
mme. Aussi nous contenterons-nous de donner un rsum des tapes suivre :
trouver les classes du domaine ;
prparer un dictionnaire des donnes ;
trouver les associations entre les classes ;
trouver les attributs des classes ;
organiser et simplifier le diagramme en utilisant lhritage ;
tester les chemins daccs aux classes ;
itrer et affiner le modle ;
regrouper des classes dans des paquetages.
190
UML 2
Chapitre
Remarque
Un modle est rarement correct ds sa premire construction. Il est souvent ncessaire de
revenir plusieurs fois dessus afin de laffiner. Par exemple, il ne faut pas sattendre trouver
toutes les associations ds la premire construction du diagramme de classes. La modlisation
ne se fait pas par une succession linaire dtapes, mais progresse souvent par itrations.
Modle des tats du domaine. Un diagramme de classes nest quun modle et, dans un logiciel en cours de fonctionnement, il ny a pas de classe mais des objets, instances de classes. Un
diagramme de classes nest quune abstraction de la ralit. Le modlisateur a besoin de descendre un niveau plus bas (cest--dire au niveau des objets). Durant lanalyse, il ne faut
cependant pas descendre jusquau niveau physique : il est tout fait prmatur de sintresser
lallocation des ressources mmoire pour les objets, et du temps processeur pour les mthodes. En revanche, il est ncessaire de connatre le cycle de vie des objets ( quelle tape de la
vie du logiciel en production les classes vont donner naissance des objets, comment ceux-ci
vont tre utiliss et quelle tape ils seront dtruits). La description de ce cycle revient aux
diagrammes dtats-transitions. Cependant, seules les classes dont les instances ont un cycle
de vie complexe doivent donner lieu des diagrammes dtats-transitions.
La dmarche pour construire le modle des tats du domaine est la suivante :
identifier des classes du domaine ayant des tats complexes ;
dfinir les tats ;
trouver les vnements qui vont engendrer des transitions entre tats ;
construire les diagrammes dtats.
Remarque
Il est important de suivre les diffrentes tapes de la dmarche dans lordre indiqu ci-dessus.
Notamment, il faut trouver les tats avant les vnements. De nombreux vnements sont
produits par les utilisateurs dun systme. Ils sont pris en compte au moment o sont dcrits
les cas dutilisation, et donc lis une application particulire. Or, le modle du domaine
doit tre indpendant des applications.
Analyse de lapplication
Limplmentation du modle des classes du domaine donne lieu un systme statique. Ce
modle nindique pas comment des instances de classes interagissent pour raliser les fonctionnalits dune application. Un diagramme de classes, mme implment, noffre aucune
fonctionnalit aux utilisateurs. Pas plus quune implmentation du modle des tats du
domaine qui se contente de dfinir le cycle de vie des objets sparment les uns des autres.
Aprs avoir construit le modle du domaine, il faut sintresser aux applications qui utilisent ses classes.
Modle des interactions de lapplication. Cest durant la phase danalyse de lapplication
quun modle des interactions du systme est produit. Lanalyse dbute par la construction
du diagramme de cas dutilisation et se poursuit par la description des scnarios dutilisation des cas. La dmarche est dcrite en dtail dans le chapitre 1. Nous nous contentons ici
den donner un rsum :
dterminer les limites du systme ;
trouver les acteurs ;
UML en pratique 191
trouver les cas dutilisation ;

construire le diagramme de cas dutilisation ;
prparer les scnarios pour dcrire les cas ;
ajouter des squences alternatives et des squences dexceptions aux scnarios ;
prparer des diagrammes dactivit pour des cas dutilisation complexes ;
raliser une vrification croise des modles du domaine et de lapplication.
La vrification se fait partir des scnarios. Elle permet de contrler si les classes ont tous les
attributs et tous les chemins (les associations) ncessaires pour y accder.
Modle des classes de lapplication. Les classes du diagramme de classes ne suffisent pas
raliser une application. Des instances de ces classes doivent interagir avec les acteurs du
logiciel (les utilisateurs, les priphriques, etc.). Il nest pas souhaitable que les acteurs interagissent directement avec les instances des classes du domaine. La logique interne de lapplication doit tre indpendante des acteurs. Linterface utilisateur du logiciel, par exemple, doit
pouvoir voluer tandis que le cur de lapplication doit rester identique. Cest le principe
fondamental du dcoupage en couches dune application (figure 6.2) : lune des extrmits de lapplication se trouve linterface utilisateur et, de lautre ct, le logiciel interagit avec
des supports de stockage (bases de donnes, annuaires, fichiers, etc.) via une couche de services. Limplmentation du diagramme des classes trouvera sa place dans la couche mtier.
Figure 6.2
Utilisateurs
Le dcoupage
en tiers dune
application.
Interface utilisateurs
Logique applicative
Logique mtier
Services : accs aux donnes,
transactions...
Supports de stockage
Remarque
La tendance actuelle du dveloppement de logiciels, prne notamment par lapproche
dite composant de la programmation, va vers la multiplication du nombre de couches. On
parle alors dun dcoupage en N-tiers !
Le modle des classes de lapplication concerne toutes les classes supplmentaires quil
convient dajouter pour interfacer la logique applicative avec les acteurs du logiciel. La
dmarche est la suivante :
spcifier linterface homme-machine ;
dfinir les classes la priphrie du systme.
192
UML 2
Chapitre
En modlisation objet, linterface est un objet, ou un groupe dobjets, qui permet dinteragir
avec lapplication. Durant la phase danalyse, vous devez vous intresser non pas la prsentation de linterface utilisateur mais uniquement aux flots de donnes et de contrle transmis via linterface. Il ne faut pas non plus trop dtailler les entres-sorties, mais considrer
globalement les requtes qui permettent daccder un service, la rservation dune place
de cinma, par exemple. Cela ne doit cependant pas vous empcher de construire les
maquettes des interfaces pour vous aider tablir leurs spcifications.
Les classes la priphrie du systme ont pour rle de convertir les informations utiles au
logiciel, du format comprhensible par le monde extrieur au format interne du logiciel, et
vice versa.
En plus des objets dfinissant les interfaces de lapplication, un logiciel contient un ou plusieurs objets actifs qui le contrlent. Ces objets sont appels contrleurs . Ils reoivent des
signaux du monde extrieur, ou des objets lintrieur du systme, et ragissent en invoquant des oprations sur dautres objets. Chaque contrleur a pour tche de traiter un comportement particulier du logiciel.
Remarque
UML nest pas dun grand secours lors de cette phase de lanalyse, mme si les classes qui
y sont dcouvertes peuvent tre reprsentes avec le formalisme du diagramme de classes.
La couche daccs aux donnes est construite lors de la phase de conception et non pas
pendant la phase danalyse. Il faut dabord avoir dcompos successivement les classes et
les mthodes pour arriver aux supports de stockage.
La dernire tape pour llaboration du modle des classes de lapplication consiste

contrler la cohrence de ce modle avec celui des interactions. Il sagit de reprendre les cas
dutilisation afin de vrifier comment les modles interagissent : par exemple, une donne
saisie via linterface homme-machine est confie un objet contrleur qui la transmet un
objet du domaine via linvocation dune opration, etc. Lors de cette tape, le langage OCL
peut tre utilis pour naviguer parmi les classes.
Modle des tats de lapplication. Tout comme les classes du domaine, les classes de lapplication peuvent avoir des tats complexes. Chacune delles ncessite donc un diagramme
dtats-transitions. Pour construire un tel diagramme, la dmarche est la suivante :
identifier des classes de lapplication ayant des tats complexes ;
trouver les vnements ;
construire les diagrammes dtats ;
vrifier la cohrence avec les modles prcdents.
Remarque
Les diagrammes des tats-transitions de lapplication se construisent peu prs de la mme
manire que ceux du domaine de lapplication. Seul lordre des tapes diffre : pour lapplication, il faut dabord trouver les vnements avant les tats, alors que cest le contraire
pour le domaine. En effet, les tats de lapplication sont labors aprs que les cas dutilisation, qui sont dclenchs par des vnements provenant des acteurs, ont t dfi nis. On
dispose donc des vnements avant de construire les tats. Il nen est pas de mme pour
ltude du domaine qui, parce quelle doit tre indpendante des applications, ne peut pas
reposer sur des vnements.
UML en pratique 193
Ajout des oprations. ce stade de lanalyse, les classes du domaine de lapplication peuvent
contenir quelques oprations (celles qui ont t suggres par ltude du domaine). Ces
oprations sont intressantes car elles sont propres au domaine, et donc indpendantes des
applications. Cependant, les oprations lies lapplication ne sont pas forcment toutes
dcouvertes. Elles peuvent tre dduites de ltude des cas dutilisation et de leurs descriptions par les diagrammes de squence et/ou dactivit produits.
2.2 PHASE
DE CONCEPTION
Avertissement
La phase de conception requiert beaucoup dexprience. Cela dpasse largement le cadre
de cet ouvrage. La description qui en est faite ici est trs sommaire, mais nanmoins utile
pour se rendre compte de lintrt dutiliser UML lors de cette phase.
Les concepteurs ont pour tche principale de prparer limplmentation. Pour un logiciel,
limplmentation consiste traduire le plus mcaniquement possible des modles danalyse
et de conception dans un ou plusieurs langages de programmation. Les modles produits
lors de lanalyse dcrivent ce que doit faire le systme indpendamment de la faon dont on
va le raliser. La conception va permettre de dcider comment raliser le systme. La phase
de conception est compose de deux tapes :
la conception du systme ;
la conception des classes.
Conception du systme
Au final, le logiciel va sexcuter sur des ressources matrielles (processeurs, mmoire). Le
concepteur du logiciel doit choisir les ressources adquates. Gnralement, il est guid par
les besoins du logiciel. Le choix ne peut pas se faire directement partir des modles danalyse, notamment pour les raisons suivantes :
Les ressources matrielles sont limites.
Les ressources matrielles sont diverses, varies et souvent htrognes.
La principale limitation des ressources concerne les microprocesseurs des ordinateurs et les
systmes dexploitation qui les grent. Ce sont des ressources partages auxquelles peuvent
accder toutes les applications qui sexcutent en mme temps sur une machine. Lors de
ltape danalyse dun logiciel, on fait la supposition que tous les objets disposent de ressources illimites. Or, au vu des ressources processeur limites, il convient de dcider, parmi
toutes les mthodes des classes du logiciel, lesquelles doivent sexcuter squentiellement,
et lesquelles doivent le faire en parallle. Pour reprer les mthodes concurrentes, on peut
analyser les modles des tats produits au moment de lanalyse.
Le choix des ressources matrielles doit tre guid par les besoins du logiciel. Une fois le
choix fait, il faut sadapter aux capacits des ressources. La principale difficult rside dans
leur grande diversit. Certains systmes dexploitation ou certains langages de programmation par exemple, fonctionnent selon un mode vnementiel, dautres sur un mode procdural, voire concurrent, etc. Le concepteur doit donc choisir une stratgie de contrle pour
son logiciel. De plus, si le logiciel est rparti sur plusieurs machines, la stratgie de contrle
ne sera pas forcment la mme pour les parties du logiciel qui sexcutent sur des machines
diffrentes. UML nest daucune aide pour choisir la stratgie de contrle. En revanche, il est
194
UML 2
Chapitre
possible de dcrire les parties dun logiciel qui sexcutent sur des matriels laide des
diagrammes de dploiement (voir lannexe D).
Au dpart, le concepteur ne dispose que des modles issus de lanalyse, cest--dire des
diagrammes de classes, des tats-transitions, des squences, etc. Or, le passage des modles
de lanalyse au diagramme de dploiement est loin dtre immdiat. Le concepteur procde par tapes. Tout dabord, le systme (dans notre cas, un systme logiciel) est dcompos en sous-systmes. La partition du systme doit permettre de regrouper dans un soussystme des classes, des associations, des oprations, des vnements, etc., qui collaborent
aux mmes fonctionnalits, ou dont les contraintes techniques les destinent sexcuter
sur les mmes ressources. UML ne donne pas dindication sur les critres prendre en
compte pour partitionner un systme, mais permet simplement de reprsenter des soussystmes. Aprs que le systme a t dcompos en sous-systmes, les tapes suivantes
consistent :
reprer les objets qui sexcutent concurremment ;
allouer les sous-systmes des matriels ;
choisir sur quel(s) support(s) stocker les donnes (bases de donnes, fichiers, etc.) ;
identifier les ressources ncessaires (processeurs, disques, crans, claviers, etc.) ;
choisir une (ou plusieurs) stratgie(s) de contrle du logiciel (vnementielle, procdurale, etc.) ;
sassurer du bon fonctionnement du logiciel dans des conditions limites (comment
linitialiser, larrter, grer les erreurs, etc.).
Remarque
UML nest daucune utilit dans les quatre dernires tapes.
Conception des classes

ce stade de la conception, le systme a t dcoup en sous-systmes et les ressources utiles
au logiciel ont t choisies. La dernire tape de la conception avant limplmentation
consiste dfinir et appliquer une stratgie pour combler la distance qui spare les
oprations des classes des ressources choisies. La technique utilise ici rejoint lapproche
fonctionnelle du dveloppement logiciel. Le concepteur procde par dcomposition des
fonctions en sous-fonctions, puis choisit des algorithmes pour raliser ces fonctions. Les
choix de conception faits ce moment-l sont plutt techniques, mais ils doivent toujours
tre guids par les cas dutilisation. Les diagrammes dactivit dUML permettent de dcrire
les algorithmes complexes, et les classeurs structurs sont utiles lors de la dcomposition des
classes et des oprations des classes. Les algorithmes sont choisis principalement pour les
performances quils offrent. Le concepteur peut aussi tre amen optimiser laccs aux
attributs des classes en ajoutant de nouvelles associations au diagramme de classes.
Conclusion
Dans ce chapitre, nous avons rassembl tous les lments de modlisation qui ont t
abords dans cet ouvrage et prsent un processus visant modliser un systme logiciel.
Ce processus gnral pourra tre adapt des projets spcifiques.
UML en pratique 195
tude de cas
nonc du problme
Le problme concerne un projet de dveloppement dun logiciel. La premire tape du cycle
de vie du projet, la planification, a permis de dfinir le problme, dtablir un calendrier, et
de vrifier la faisabilit du projet. Notre description commence ltape danalyse.
Cette section contient lessentiel de ltude de cas. Des informations complmentaires sont
disponibles sur le site http://www.pearsoneducation.fr.
DESCRIPTION
DU PROBLME
Le but de ce projet est de dvelopper un logiciel qui gre la distribution de carburant dans
une station-service.
Le fonctionnement de la distribution de lessence est le suivant : avant de pouvoir tre
utilise par un client, la pompe doit tre arme par le pompiste. Mais ce nest que lorsque le
client appuie sur la gchette du pistolet de distribution que lessence est pompe. Si le pistolet est dans son tui de rangement, et si lon appuie sur la gchette, lessence nest pas
pompe. La prise dessence est termine quand le client remet le pistolet dans son tui.
Il existe quatre types de carburants : diesel, sans plomb avec 98 comme indice doctane, sans
plomb avec 95 pour indice doctane, plomb.
Le paiement peut seffectuer en espces, par chque ou par carte bancaire. En fin de journe,
les transactions sont archives.
Les pompes ne peuvent tre armes que si le niveau des cuves dpasse 5 % de leurs capacits
maximales.
CONTEXTE
TECHNIQUE DU SYSTME
Le contexte technique du logiciel est impos (figure 6.3). Le logiciel doit sexcuter sur une
unit centrale laquelle sont relis :
des capteurs pour mesurer le niveau de carburant dans les cuves ;
des pompes qui puisent le carburant dans les cuves ;
le pupitre du pompiste (cran et clavier) ;
un systme cls en main de paiement par carte bancaire.
196
UML 2
Chapitre
Figure 6.3
Contexte technique
du logiciel (ce
diagramme nest
pas un diagramme
UML).
DIAGRAMME
Pupitre pompiste
Banque
Systme de paiement
par carte bancaire
Unit centrale
Cuves carburant
Pompe 1
Pompe n
SP98 Super SP95 Diesel
SP98 Super SP95 Diesel
DE DPLOIEMENT DES PRIPHRIQUES DU SYSTME

Pour prciser le contexte technique du systme, il est parfois utile de montrer un exemple de
solution. Lexemple doit tre donn titre purement indicatif et la solution finale pourra
tre diffrente. Pour que lanalyse, qui na pas encore dbut, ne soit pas biaise, il faut cependant veiller ne donner aucune consigne de conception (architecture interne, structure de
donnes, algorithmes, etc.).
La figure 6.4 prsente le diagramme de dploiement des priphriques du systme informatique de la station-service. Le systme informatique, quand il sera dploy, sexcutera sur le
nud unit centrale . ce stade du projet, il sagit dune bote noire. Outre lunit centrale,
on retrouve sur ce diagramme les priphriques de la figure 6.3.
Figure 6.4
Diagramme
de dploiement
des priphriques
du systme.
clavier
clavier du
pompiste
Priphrique
de gestion des
cuves
cran
cran du pompiste
unit centrale
Systme informatique de la station-service
disque
Base de donnes
Priphrique de
paiement par carte
bancaire
Priphrique
de gestion des
pompes
On suppose que les priphriques matriels (de gestion des cuves, des pompes et du terminal
de paiement) sont pilots par des composants existants. La figure 6.5 montre uniquement
les composants qui pilotent une pompe : les deux premiers permettent de connatre respectivement les tats des gchettes (appuyes ou relches) et des pistolets ; le troisime fournit
une interface (InterfacePompe) permettant darmer et dactiver la pompe.
UML en pratique 197
Figure 6.5
Les composants qui
grent une pompe.
Gchette super
Gchette diesel
Gchette SP95
Gchette SP98
Pompe super
Pistolet super
Pompe diesel
Pistolet diesel
Pompe SP95
Pistolet SP95
Pistolet SP98
Pompe SP98
Priphriques de gestion dune pompe
unit centrale
Systme informatique de la station-service
InterfaceCapteurGchette InterfaceCapteurPistolet
: Capteur
Gchette
: Capteur
Pistolet
: Pompe
InterfacePompe
Informations transmises : Informations transmises :

- numro de pompe,
- gchette appuye,
- gchette relche.
- type carburant choisi,
- pistolet dcroch,
- pistolet raccroch.
interface
InterfacePompe
armer : boolen
dsarmer : boolen
activer : boolen
dsactiver : boolen
Analyse du domaine de lapplication

Nous choisissons arbitrairement de commencer par lanalyse du domaine de lapplication.
Il est possible davoir une lecture diffrente et de commencer par lanalyse de lapplication
(voir plus loin dans ce chapitre). La seule contrainte, cest quil faut mener ces deux analyses
de faon indpendante. Le premier modle du domaine produire est celui des classes.
198
UML 2
Chapitre
MODLE
DES CLASSES DU DOMAINE
1.
2.
3.
4.
Trouvez les classes qui font partie du domaine de lapplication.

Trouvez les associations entre les classes.
Trouvez les attributs des classes.
Organisez et simplifiez le diagramme en utilisant lhritage. Testez les chemins daccs
aux classes. Itrez et affinez le modle.
5. Regroupez des classes dans des paquetages.
1. Avant de dresser une liste de classes, commenons par dlimiter le domaine de lapplication. Le contexte technique du logiciel concevoir impose dutiliser des priphriques
matriels qui interagissent avec notre logiciel via des capteurs (les dtecteurs de niveau
des cuves, par exemple). Notre but nest pas de concevoir ces priphriques mais de les
modliser afin de pouvoir les piloter. Bien entendu, un modle du domaine doit dpendre le moins possible des applications qui vont sappuyer sur lui. Plus le nombre dapplications qui peuvent tre construites partir dun seul modle du domaine est lev, et
meilleur est ce modle. Cependant, dans notre cas, le domaine est clairement limit une
station-service : notre modle nest pas destin lalimentation en carburant de voitures
de course pendant une comptition, ni au remplissage des rservoirs dun avion.
Lanalyse de domaine est ralise avec un expert. Il connat les priphriques qui grent la
distribution dessence, et notamment les capteurs et les actionneurs qui les contrlent.
Commenons par en dresser une liste exhaustive :
capteurs de niveau des cuves ;
dispositifs de pompage qui pompent le carburant dans les cuves ;
gchettes des pistolets de distribution de carburant qui contrlent les dispositifs de pompage ;
capteurs de prsence des pistolets dans les tuis de rangement.
Le domaine ainsi dlimit, nous pouvons en commencer lanalyse. Ltude de la description du problme donne une premire liste de classes candidates : Pistolet, Gchette,
Pompe, Etui, Carburant, Cuve, Client, Transaction, Archive.
La notion de pompe est centrale dans la prise de carburant, mais que recouvre-t-elle
exactement ? Est-ce lappareil auquel fait face un client et qui contient un ensemble de
pistolets, de gchettes, dtuis, etc., ou est-ce la pompe qui puise le carburant dans les
cuves ? Ltude des capteurs et des actionneurs reproduite prcdemment mentionne un
dispositif de pompage qui pompe le carburant dans les cuves . Cest avant tout le dispositif de pompage que nous devons piloter (et donc modliser). Pour lever lambigut
pesant sur le mot pompe, nous choisissons dutiliser DispositifDePompage la place.
Lensemble des pistolets, des gchettes et des tuis auquel fait face un client est appel
EnsemblePompe.
Le dispositif de pompage est contrl par un pistolet, une gchette et un tui, do les
noms de classes Pistolet, Gchette et Etui.
La notion de cuve est importante dans notre domaine. Elle permet, notamment, de raliser la contrainte sur larmement dune pompe. Elle est modlise par une classe appele
Cuve. La cuve contient du carburant. Carburant constitue galement un bon nom pour
une classe.
UML en pratique 199
Client, transaction et archive nont pas encore t traits. Pour lapplication que nous
allons concevoir, un client est celui qui se sert de lessence : cest un concept clair et non
ambigu pour lapplication. Quen est-il du domaine de lapplication ? Quel concept du
mtier de la distribution de carburant voulons-nous cerner ? Le client prend de
lessence. Cest donc plus la prise dessence, lessence dlivre (la quantit, le type de carburant, etc.) qui nous intresse que le client en tant que tel. En ce qui concerne ce dernier,
nous voulons plutt savoir quel type de paiement il a effectu (en espces, par chque ou
par carte bancaire), et ventuellement, conserver le numro dimmatriculation de sa
voiture. Nous sommes donc en prsence de deux concepts distincts. Le premier, qui
correspond lessence dlivre, est modlis par une classe appele PriseDeCarburant.
La prise de carburant nenglobe pas le type de paiement. Elle est lie au dispositif de
pompage qui est au cur de notre domaine. Le type de paiement est li un client. Pour
la distribution dessence des particuliers, le paiement fait partie du domaine de lapplication. Rsumons cette notion par le mot-cl TransactionClient. Le dernier substantif que
nous navons pas encore abord est archive. Les transactions doivent tre archives quotidiennement. Pour quil ny ait pas dambigut, renommons lensemble des transactions
quotidiennes TransactionsDuJour.
La liste des classes candidates est prsent la suivante : Pistolet, Gchette, DispositifDePompage, EnsemblePompe, Etui, Carburant, Cuve, PriseDeCarburant, TransactionClient,
TransactionsDuJour.
Afin de dfinir clairement chaque terme, un dictionnaire a t rdig. Voici un extrait :
Essence distribue par la station-service. Le carburant peut tre de
plusieurs types (sans plomb 98, sans plomb 95, super et diesel).
Conteneur du carburant de la station-service. Il y a une cuve par
Cuve
type de carburant.
DispositifDePompage Appareil qui pompe le carburant dans les cuves.

Contient toutes les informations concernant le paiement dun
TransactionClient
client, incluant le montant, la date et lheure de la transaction.
TransactionsDuJour Lensemble des transactions ralises en une journe.
Carburant
Remarque
Tous les termes lis au domaine ou lapplication doivent tre consigns dans des dictionnaires, mais pour des raisons de place, nous ne les avons pas tous reproduits.
2. Un premier diagramme de classes contenant des associations est prsent la figure 6.6.
Notre objectif premier est de modliser lorganisation des priphriques afin de les
contrler.
Le modle sarticule autour du dispositif de pompage. Cest la gchette qui contrle lactivation du dispositif de pompage. Do lassociation entre les classes Gchette et DispositifDePompage. Ce dispositif pompe le carburant dans une cuve ( noter que lassociation
de 1 vers plusieurs entre les classes Cuve et DispositifDePompage indique que plusieurs
pompes puisent le carburant dans une mme cuve).
200
UML 2
Chapitre
La gchette ne peut dclencher le pompage que si le pistolet qui la contient est dans son
tui. Cest ltat dun capteur qui indique si le pistolet est dans son tui ou pas. Pour
modliser cette information, nous tablissons une association ayant la multiplicit 0 ou 1
entre les classes Pistolet et Etui.
La prise de carburant relie les classes DispositifDePompage, Carburant et TransactionClient.
Figure 6.6
EnsemblePompe
Premire version
du diagramme de
classes du domaine.
1..*
Pistolet
Gchette
contrle
activation
Pompe
carburant
dans
DispositifDePompage
Cuve
1..*
contient
0..1
Etui
dbite
PriseDeCarburant
TransactionsDuJour
0..*
Carburant
1..*
TransactionClient
La navigabilit des associations nest pas prise en compte ce stade de lanalyse.

3. La plupart des attributs sont des boolens qui refltent ltat des capteurs physiques
(figure 6.7) : le pistolet est dans son tui, la gchette est appuye, le dispositif de pompage
est arm ou actif (il est actif quand le pompage a lieu).
Si le pistolet possde un boolen qui indique sil est ou non dans son tui, la classe tui
devient superflue : elle est supprime du modle.
La classe Cuve est caractrise par son niveau de carburant. La classe Carburant contient
le prix au litre ainsi que le type de carburant (sans plomb 98, etc.).
La classe TransactionClient recense lensemble des donnes caractrisant le paiement par
un client : le type de paiement (espces, carte bancaire ou chque), le montant ainsi que
la date de la transaction. La quantit dessence prise qui permet de calculer le montant est
dtenue par la classe PriseDeCarburant.
UML en pratique 201
Figure 6.7
EnsemblePompe
Version du
diagramme de
classes du domaine
incluant les attributs.
numroPompe : entier
Pompe carburant dans

contrle
activation DispositifDePompage
Cuve
1..*
1..*
Gchette
Pistolet
dansEtui : boolen
niveau : entier
appuye : boolen
arm : boolen
actif : boolen
contient
dbite
PriseDeCarburant
1..*
quantitCarburant : rel
{ ordonnes par date}
TransactionsDuJour
archiver()
0..*
Carburant
prix : rel
typeCarburant : TypeCarburant
numration
TypeCarburant
TransactionClient
sansPlomb98
sansPlomb95
super
diesel
typePaiement : TypePaiement
date : Date
montant : rel
4. Les diffrents types de carburants peuvent tre modliss en crant des classes qui hritent
de la classe Carburant (figure 6.8).
Figure 6.8
Carburant
Modlisation des
types de carburants
par un hritage.
SansPlomb98
SansPlomb95
Diesel
Super
Cependant, nous avons utilis une numration la place de lhritage, car un hritage ne
se justifie que si au moins une classe drive possde un attribut, une association ou une
mthode spcifique, ce qui nest pas le cas ici. Le diagramme de classes de la figure 6.10
contient une numration appele TypeCarburant qui est utilise pour typer lattribut
typeCarburant de la classe Carburant.
Le client peut choisir parmi trois modes de paiement : par carte bancaire, en espces ou
par chque. Or, jusqu prsent, nous ne disposons, dans notre modle, que dune seule
classe pour grer le paiement : TransactionClient (figure 6.7). Le paiement par carte bancaire est particulier car la transaction doit tre valide auprs de la banque. Si le client
souhaite payer par chque, il doit donner au pompiste un identifiant, son numro de
carte didentit, par exemple. Ces particularits incitent transformer la classe TransactionClient en une classe de base dont hritent trois classes (figure 6.9) : TransactionEnEspces, TransactionBancaire et TransactionParChque. La classe TransactionClient est
abstraite car elle possde lopration abstraite payer. Celle-ci sera implmente dans les
202
UML 2
Chapitre
classes drives et permettra ainsi de particulariser le paiement. Lattribut identifiantClient a t ajout la classe TransactionParChque pour que celle-ci puisse conserver
lidentifiant dun client payant par chque.
Figure 6.9
TransactionClient {abstract}
Un hritage
pour modliser
les transactions.
date : Date
montant : rel
payer {abstract}
TransactionEnEspces
TransactionBancaire
TransactionParChque
identifiantClient : entier
payer
payer
payer
La technique de lhritage permet dtendre le domaine au plus grand nombre dapplications possibles. Or, il est rare aujourdhui quune station-service vende uniquement du
carburant. En observant le graphe dhritage de la figure 6.9, on saperoit que les transactions des clients peuvent sappliquer la vente de nimporte quel produit ou service. Ce
qui caractrise la vente de carburant, cest lassociation tablie entre les classes TransactionClient et PriseDeCarburant. Pour gnraliser la vente dautres services, une nouvelle
classe appele Service est cre (pour ne pas trop sortir du cadre de cette tude, la vente de
produits nest pas prise en compte). La prise de carburant devient alors un service, et la
classe PriseDeCarburant hrite de la classe Service (figure 6.10). Pour linstant, aucun
service supplmentaire na t ajout au modle, mais si, lavenir, un service dentretien
de vhicules venait tre cr, le graphe dhritage des services serait prt recevoir une
classe appele EntretienVhicule.
Pour tester en profondeur les chemins daccs aux classes, vous pouvez dfinir des requtes utilisant le langage OCL. Une autre technique consiste employer des diagrammes
dinteraction (de squence ou de communication) pour montrer comment des objets,
instances des classes, collaborent la ralisation des cas dutilisation. Mais avant dutiliser
les interactions, il faut avoir dvelopp le modle de lanalyse de lapplication. Ce que
nous ferons juste aprs avoir regroup les classes en paquetages et bti le modle des tats
du domaine.
5. la figure 6.10, deux ensembles de classes correspondant deux fonctionnalits de la
station-service apparaissent : un premier ensemble concerne la prise de carburant (il
regroupe les classes EnsemblePompe, Pistolet, Gchette, DispositifDePompage, Cuve,
Carburant, PriseDeCarburant et Service), et un deuxime a trait aux transactions (TransactionsDuJour, TransactionClient, TransactionEnEspces, TransactionBancaire, Transaction-ParChque, PriseDeCarburant et Service). Les classes lies la prise de carburant sont
regroupes dans un paquetage appel ServiceCarburant, tandis que les classes relatives
aux transactions sont incluses dans un paquetage appel Transactions (figure 6.11).
UML en pratique 203
Figure 6.10
Diagramme de
classes du domaine.
Pompe carburant dans
contrle
activation
Pistolet
dansEtui : boolen
Gchette
DispositifDePompage
appuye : boolen
arm : boolen
actif : boolen
1..*
Cuve
niveau : entier
contient
1..*
Service
EnsemblePompe
numroPompe : entier
dbite
PriseDeCarburant
Carburant
prix : rel
typeCarburant : TypeCarburant
{ordonnes par date}

TransactionsDuJour
0..*
TransactionClient {abstract}
Pistolet
numration
TypeCarburant
date : date
montant : rel
archiver()
sansPlomb98
sansPlomb95
super
diesel
payer {abstract}
TransactionEnEspces
TransactionBancaire
TransactionParChque
identifiantClient : entier
payer( )
Figure 6.11
payer( )
Transactions
payer( )
ServiceCarburant
Paquetages du
modle du domaine.
Remarque
Il faut essayer de limiter les dpendances entre paquetages car cela facilite la rutilisabilit
spare des paquetages dans dautres projets. Il y a dpendance entre deux paquetages
quand une association existe entre deux classes appartenant deux paquetages diffrents.
Si lassociation est bidirectionnelle, la dpendance lest aussi (figure 6.12).
Dans ce cas, il est peut-tre possible de limiter lassociation un seul sens (ce qui supprime
une des deux dpendances entre les paquetages).
Il ne faut pas oublier non plus que la dpendance entre deux paquetages dpend aussi du
nombre de messages qui circulent sur lassociation. Plus le nombre de messages est lev,
plus la dpendance est forte. Si ce nombre est trop important, il faut peut-tre revoir la rpartition des classes entre les paquetages afin que lassociation qui est en cause ne les relie plus.
204
UML 2
Chapitre
Figure 6.12
Double dpendance
entre paquetages.
Figure 6.13
Simple dpendance
entre paquetages.
MODLE
DES TATS DU DOMAINE

Le modle des classes du domaine est prsent complet. Il na cependant pas t valid par
dautres modles qui vont lclairer sous un nouveau jour. Aprs avoir construit le diagramme de classes du domaine, il faut prsent tudier chaque classe sparment et reprer
celles qui engendrent des objets au cycle de vie complexe. Pour ces classes particulires, il
faut construire un diagramme dtats-transitions.
1. Identifiez des classes du domaine ayant des tats complexes.
2. Pour chaque classe ayant des tats complexes :
dfinissez les tats ;
trouvez les vnements ;
construisez les diagrammes dtats.
1. Seules les classes DispositifDePompage et TransactionClient (avec ses classes drives) ont
des tats complexes.
2. Un diagramme dtat dbute au moment o une instance est cre. tant donn que la
classe TransactionClient contient une opration abstraite (payer), elle ne peut pas tre
instancie. Ses classes drives (TransactionEnEspces, TransactionBancaire et TransactionParChque) implmentent lopration payer, ce qui leur permet dtre instanciables.
Linstanciation intervient ds que le pompiste slectionne le mode de paiement choisi par
le client.
Il faut prsent imaginer des tats. Ltat dun objet est souvent caractris par la valeur
instantane de ses attributs et de ses liens vers dautres objets. On en dduit plusieurs
tats possibles :
type de paiement choisi ;
paye ;
archive.
Les vnements qui dclenchent des transitions vers ces tats sont :
choix du mode de paiement ;
valider la transaction.
UML en pratique 205
partir des tats et des vnements prcdents, le diagramme dtats-transitions est

construit.
Figure 6.14
Diagramme des
tats-transitions
pour la classe
TransactionClient.
type paiement
choisi
paiement valid
valider paiement
archiv
archiver
annuler
Remarque
Le modle du domaine doit dpendre le moins possible des applications qui vont reposer
sur lui. Il faut donc essayer, quand on construit ce modle, de ne pas y faire inter venir des
considrations lies une application particulire. Il est donc important de commencer par
trouver les tats avant les vnements. Commencer par chercher les vnements conduit
rflchir la manire dutiliser un systme, ce qui revient imaginer une application par ticulire.
Intressons-nous prsent la deuxime classe qui engendre des objets ayant des tats complexes : la classe DispositifDePompage. quel moment des instances doivent-elles tre
cres ? Cest difficile dire en ltat actuel de lanalyse : en effet, le dispositif de pompage en
tant que priphrique matriel existe indpendamment du logiciel qui va le piloter, mais
quen est-il des instances de la classe DispositifDePompage ? Quand le client arrive pour
prendre de lessence, il a plusieurs pistolets (un par type de carburant) sa disposition.
Ds quil a pris un pistolet, le type de carburant quil dsire est connu. On sait donc dans
quelle cuve il faut puiser du carburant. Chaque cuve a des pompes particulires que notre
logiciel va devoir piloter. Le pilotage commence donc ds que le client dcroche un pistolet
(il faut alors armer le dispositif de pompage). Linstance ne doit pas forcment tre cre
ce moment-l car cela a peut-tre dj t fait auparavant. Comme nous ne pouvons pas le
savoir pour linstant, nous ne prcisons pas dans le diagramme suivant lvnement qui
instancie un dispositif de pompage.
Pour un dispositif de pompage, les tats possibles sont les suivants :
arm ou dsarm en fonction des actions du pompiste ;
bloqu ou dbloqu selon que le pistolet est rang ou non ;
actif ou inactif selon que lessence est en train dtre pompe ou non.
laide des tats et des vnements ci-dessus, on en dduit le diagramme dtats-transitions
de la figure 6.15. Notons que quand le client raccroche le pistolet, la pompe est automatiquement dsarme.
206
UML 2
Chapitre
Figure 6.15
arm
Diagramme des tatstransitions de la classe

DispositifDePompage.
armer
dsarm
dcrocher pistolet
bloqu
dbloqu
pression
gchette
raccrocher pistolet
inactif
dpression
gchette
actif
Analyse de lapplication
Lanalyse de lapplication commence par ltude des cas dutilisation. Ce modle reprsente le
systme informatique de la station-service vu par les acteurs. Il est construit indpendamment du modle du domaine de lapplication. Par la suite, ces deux modles seront confronts
pour vrifier que les classes du domaine permettent de raliser les cas dutilisation. Lanalyse
complte de lapplication se fait en btissant trois modles :
le modle des interactions de lapplication ;
le modle des classes de lapplication ;
le modle des tats de lapplication.
La phase danalyse se conclut par lajout doprations aux classes.
MODLE
DES INTERACTIONS DE LAPPLICATION
1. Dterminez les limites du systme. Trouvez les acteurs. Trouvez les cas dutilisation.
Construisez le diagramme de cas dutilisation.
2. Prparez les scnarios pour dcrire les cas. Ajoutez des squences alternatives et des
squences dexceptions aux scnarios. Prparez des diagrammes dactivit pour des cas
dutilisation complexes.
3. Vrifiez la cohrence entre le modle des classes du domaine et celui de lapplication.
1. Les quatre premires questions ont t traites dans la partie exercices du chapitre 1. Vous
y trouverez des explications sur la dmarche qui a permis daboutir au diagramme prsent la figure 6.16.
UML en pratique 207
Figure 6.16
Diagramme de cas
dutilisation de la
station-service.
Capteur niveau cuve

pour armement
Capteur niveau cuve

pour remplissage
Vrifier niveau cuve

pour armement
Vrifier niveau cuve

pour remplissage
Station Service
inclut
Client
inclut
Se servir
Armer pompe
Points dextension :
paiement : { la fin du
cas se servir }
Condition : {si le client a

pris de lessence avant de
raccrocher le pistolet}
Point dextension : paiement
Pompiste
tend
Payer
Payer
en espces
Payer par carte

bancaire
Banque
Archiver les
transactions
Payer
par chque

Timer
2. Les cas dutilisation doivent tre dcrits sous forme textuelle comme indiqu au chapitre 1.
Certains peuvent tre dcrits laide de diagrammes de squence ou par des diagrammes
dactivit. Pour chaque cas, il faut dfinir une squence nominale ainsi que des squences
alternatives et dexceptions. Pour des raisons de place, la description textuelle des cas et
les squences alternatives et dexceptions ne sont pas prsentes.
Un cas dutilisation est dclench quand un vnement survient. Le dictionnaire suivant
liste les vnements qui initient les cas dutilisation. Comme nous lavons vu au chapitre
1, les vnements peuvent tre classs en trois catgories :
les vnements externes ;
les vnements temporels ;
les vnements dtats.
208
UML 2
Chapitre
Il est minuit lhorloge

systme
Choix du mode de paiement
Dcrochage dun pistolet
Demande armement
pompe
Demande niveau dans
cuve pour armement
Niveau dans cuve pour
remplissage atteint
Encaissement (pompe,
typeCarburant)
vnement temporel qui dclenche le cas Archiver les transactions . Cest aussi un vnement externe car le temps est
considr comme un acteur : acteur Timer.
vnement externe produit par lacteur Pompiste qui dclenche
un des trois cas particuliers de paiement : Payer par carte
bancaire , Payer en espces et Payer par chque .
vnement externe produit lacteur Client qui dclenche le cas
Se servir .
le cas Armer Pompe .
vnement dtat, car produit lors du droulement du cas
Se servir , qui dclenche le cas Vrifier niveau cuve pour
armement .
vnement externe produit par lacteur Capteur niveau cuve
pour remplissage qui dclenche le cas Vrifier niveau cuve
pour remplissage .
le cas payer .
On remarque sur le diagramme de la figure 6.16 que le paiement intervient aprs que le
client a pris de lessence. En situation relle, il faudrait sinquiter de lvolutivit de notre
application et considrer le cas o le paiement interviendrait avant. Il faudrait aussi offrir
la possibilit au client de payer lui-mme, directement avec une carte de crdit dans le terminal de la pompe, sans lintervention du pompiste. La figure 6.17 montre comment le
diagramme de cas dutilisation peut tre transform pour que le paiement puisse intervenir
avant que le client prenne de lessence. Dans la suite de cette tude de cas, nous revenons
la situation initiale (cas o le client paye aprs avoir pris du carburant).
Figure 6.17
Points dextension
qui prcisent
quand le paiement
intervient.
Se servir
Points dextension :
- paiementAvant
- paiementAprs
Client
Point dextension : paiementAvant
(le paiement se fait avant de se
servir)
tend
Point dextension : paiementAprs

(le paiement se fait aprs stre
servi)
Payer
Payer en espces
Payer par carte

bancaire
Banque
Payer par chque
UML en pratique 209
Scnario nominal pour Se servir du carburant. La figure 6.18 tablit le scnario nominal
du cas dutilisation Se servir du carburant. noter la boucle qui indique que le client
peut appuyer et relcher plusieurs fois la gchette avant de reposer le pistolet. Il est galement fait rfrence un diagramme appel ArmerPompe. On indique ainsi que larmement
est inclus dans la prise dessence.
Figure 6.18
sd Se servir
Scnario nominal
du cas Se servir .
: Station-service
Client
ref
ArmerPompe
loop
[ pistolet hors tui ]
Appui sur la gchette
Affiche quantit essence + montant
Relchement de la gchette
Raccrochage du pistolet
Dsarmer
pompe
La figure 6.19 donne le scnario nominal pour le cas Armer Pompe . La vrification du
niveau des cuves pour larmement y est incluse. De plus, on vrifie que plusieurs pistolets
nont pas t dcrochs.
210
UML 2
Chapitre
Figure 6.19
Scnario nominal
du cas Armer
pompe .
sd ArmerPompe
: Station service
Pompiste
Affiche numro de pompe +

type essence prise
Demande armement pompe
Tester si un autre pistolet

nest pas dcroch
ref
VrifierNiveauCuvePourArmement
RAZ compteur volume

et montant + prix du litre
Affiche confirmation armement
Le scnario nominal pour le cas Vrifier niveau cuve pour armement est donn la
figure 6.20.
Figure 6.20
Scnario nominal
du cas Vrifier
niveau cuve pour
armement .
sd VrifierNiveauCuvePourArmement
: Station service
Capteur niveau
pour armement
Demande niveau dans cuve pour armement
Niveau dans cuve pour armement OK
UML en pratique 211
Remarque
Le diagramme de cas dutilisation dtaille de manire trs prcise les fonctions de la station-service (on y voit larmement ainsi que la vrification du niveau des cuves). Il eut t
possible de dcrire le systme plus sommairement comme le montre la figure 6.21. Malgr
ce changement dchelle, le scnario pour se servir de lessence ne change pas. La figure
6.22 le reproduit. On y retrouve superposes les figures 6.18, 6.19 et 6.20, qui reprsentent la station-service, avec plus de dtails. Ceci dnote limportance tout relative des
relations dinclusion, dextension et de gnralisation qui peuvent agrmenter un diagramme
de cas dutilisation. Dailleurs, certains modlisateurs ignorent dans un premier temps les
relations entre les cas, et tablissent dabord les scnarios.
Figure 6.21
Diagramme de
cas dutilisation
montrant moins
de dtails.
Capteur niveau cuve

pour armement
Capteur niveau cuve

pour remplissage
Station Service
Vrifier niveau cuve
pour remplissage
Se servir
Points dextension :
paiement : { la fin du cas
se servir }
Client
Condition : {si le client a pris
de lessence avant de raccrocher
le pistolet}
Point dextension : paiement
Pompiste
tend
Payer
Payer en espces
Payer par carte

bancaire
Banque
Archiver les
transactions
Payer
par chque

Timer
212
UML 2
Chapitre
Figure 6.22
sd Se servir + Armer pompe + Vrifier niveau cuve pour armement
Scnario nominal
des cas Se servir ,
Armer pompe
et Vrifier
niveau cuve pour
armement .
: Station service
Client
Pompiste
Capteur niveau
pour armement

Affiche numro de pompe +
type essence pris
sd ArmerPompe

Tester si un autre pistolet nest pas dcoch
sd VrifierNiveauCuvePourArmement
Demande niveau dans cuve pour armement
Niveau dans cuve pour armement OK
RAZ compteur volume

loop
[ pistolet hors tui ]
Affiche quantit essence + montant
Dsarmer pompe
Scnario nominal du cas Payer . Intressons-nous prsent au cas du paiement. Le

diagramme de cas dutilisation de la figure 6.16 indique une relation de gnralisation entre
les cas Payer par carte bancaire , Payer par chque , Payer en espces et Payer .
On signifie ainsi que le paiement commence se drouler uniformment puis se spcialise
en trois cas particuliers. La divergence de traitement intervient quand le pompiste choisit
le mode de paiement conformment la demande du client. Le diagramme montre alors
une rfrence un comportement polymorphe, TransactionClient.payer, qui correspond
linvocation de lopration payer de la classe TransactionClient figurant dans le diagramme
de classes du domaine (figure 6.10).
noter aussi que le paiement dbute quand le pompiste slectionne la pompe et le type de
carburant dont sest servi le client.
La figure 6.23 illustre le scnario nominal du cas payer . On remarque aussi la rfrence
faite TransactionClient.payer. On indique ainsi que cette partie du scnario peut varier en
fonction du mode choisi.
UML en pratique 213
Figure 6.23
Scnario nominal
pour le cas
payer .
sd payer
: Station-service
Pompiste
encaissement (pompe, typeCarburant)
Affiche montant payer
ref
TransactionClient.payer
3. La vrification doit tre minutieuse : il sagit dtudier attentivement tous les scnarios en
vrifiant si les classes possdent tous les attributs et les chemins (les associations) ncessaires pour y accder. La vrification tant fastidieuse, elle na pas t reproduite ici.
MODLE
DES CLASSES DE LAPPLICATION

Les classes que nous avons dcouvertes jusqu prsent sont issues du domaine de lapplication. Elles sont a priori valables pour toutes les applications possibles dans le cadre dune
station-service. Cependant, elles ne sont pas suffisantes pour faire fonctionner une application particulire. Par exemple, quand le pompiste interagit avec les classes du domaine via
un terminal, un ensemble de classes supplmentaires doit raliser des conversions de donnes, afin de traduire les attributs des classes du domaine dans un format plus parlant pour
le pompiste.
1. Spcifiez linterface homme-machine.
2. Dfinissez les classes la priphrie du systme.
3. Dfinissez des classes pour contrler le systme. Contrlez la cohrence avec le modle
des interactions.
1. Pour spcifier linterface homme-machine, on en construit souvent une maquette
(figure 6.24). Elle reprsente lcran principal auquel fait face le pompiste. Il est compos
de n zones, chacune appele Pompe i (pour i allant de 1 n). Chaque zone est constitue de quatre boutons qui permettent au pompiste de demander larmement dune
pompe. Si le niveau dessence dans les cuves est suffisant, la pompe est arme et le bouton
correspondant reste enfonc. Si, au contraire, le niveau dessence est insuffisant, le bouton de la pompe apparat en rouge. Ds que le client a fini de se servir (il a raccroch le
pistolet), le bouton de la pompe correspondant au type dessence quil a pris clignote.
Les boutons correspondant aux types dessence choisis peuvent tre dans lun des tats
suivants :
214
UML 2
Chapitre
non enfonc (pompe dsarme) ;
enfonc (pompe arme) ;
rouge (armement impossible) ;
clignotant (fin de prise de carburant).
Figure 6.24
cran principal
du terminal du
pompiste.
Pompe 1
Pompe n
SansPlomb98
SansPlomb98
SansPlomb95
SansPlomb95
Diesel
Diesel
Super
Super
Ds que le pompiste appuie sur un bouton clignotant, la zone de lcran correspondant

la pompe est remplace par une zone servant au paiement (figure 6.25).
Figure 6.25
cran du terminal
du pompiste tel quil
apparat au moment
du paiement.
Pompe 1
Pompe n
Montant payer : 30 euros
SansPlomb98
Carte bancaire
SansPlomb95
Chque
Diesel
Espces
Super
Valider transaction
Zone de lcran pour

le paiement
Zone de lcran montrant

des pompes dsarmes
Le pompiste peut choisir, via linterface prsente la figure 6.25, le type de paiement
dsir par le client (carte bancaire, chque ou espces). Le bouton correspondant au
mode de paiement choisi reste enfonc une fois slectionn. Le pompiste peut appuyer
sur le bouton qui valide la transaction ds que le client a pay.
partir de cette maquette la dmarche consiste btir un diagramme de classes qui doit
reflter les changes de donnes vhicules entre cette interface et le cur du logiciel.
UML en pratique 215
La construction de ce diagramme suit les tapes habituelles suivantes :

dresser une liste de classes ;
trouver les associations entre les classes ;
etc.
Ayant dj ralis une tude similaire pour construire le diagramme de classes du domaine,
ltude des classes de linterface utilisateur na pas t reproduite.
2. Notre logiciel doit tre interfac avec des priphriques matriels : des capteurs de niveau
dessence dans les cuves, un terminal de paiement, etc. Nous nous contenterons dtudier
les priphriques qui grent le niveau de carburant dans les cuves. Vous pourrez facilement en dduire les autres cas par analogie.
La figure 6.26 est extraite du diagramme de dploiement de la figure 6.4. Seuls les nuds
permettant la gestion des capteurs de niveau sont reprsents. Le priphrique de gestion
des cuves est externe au systme informatique de la station-service. Il sagit par exemple
dun botier dont les extrmits sont raccord un capteur de niveau et lunit centrale.
Un composant qui pilote le priphrique de gestion des cuves est charg de fournir une
classe du domaine le niveau du carburant via une interface (appel PiloteGestionCuve).
Figure 6.26
Composant
permettant
daccder aux
priphriques de
gestion des cuves.
unit centrale
Systme informatique de la station
service
niveau
Priphrique de
gestion des cuves
: PiloteGestionCuve
InterfaceCuve
La figure 6.27 dtaille linterface InterfaceCuve et montre que la classe Cuve extraite du
diagramme de classes de la figure 6.10 est cliente de cette interface.
Figure 6.27
La classe Cuve
comme classe
cliente de linterface
InterfaceCuve.
interface
InterfaceCuve
getNiveau : entier
Cuve
niveau : entier
3. En plus des classes qui se trouvent la priphrie dun systme et celles qui grent linterface homme-machine, un logiciel est constitu dobjets qui le contrlent. Chaque objet
contrleur est ddi une fonction particulire. Dans notre cas, il sagit de trois fonctions bien distinctes : la prise dessence, le paiement et larchivage des transactions.
Pour commencer, tentons dimaginer un objet qui puisse contrler la prise dessence.
Session de prise dessence. Ds quun client dcroche un pistolet, des instances des
classes Pistolet, Gchette et DispositifDePompage sont prtes activer le priphrique
matriel qui pompe lessence. Les tats des instances vont changer en fonction des actions
des clients qui sont perues par le systme au travers de capteurs. Si N clients prennent du
carburant simultanment, il y aura N ensembles dinstances de Pistolet, de Gchette et de
216
UML 2
Chapitre
DispositifDePompage. Pour contrler ces trois instances, nous crons une classe appele
SessionDePriseDeCarburant.
Le diagramme des objets prsent la figure 6.28 montre deux clients qui se servent du
super 98 simultanment, chacun ayant sa propre session.
Figure 6.28
Diagramme dobjets
qui montre deux
sessions de prise
dessence.
client1
session1
EnsemblePompe1
pistolet1
gchette1
pompe1 : DispositifDePompage
numro : entier = 1
priseDeCarburant1
carburant
Cuve
typeCarburant : TypeCarburant = sansPlomb98
priseDeCarburant2
EnsemblePompe2
pistolet2
gchette2
pompe2 : DispositifDePompage
numro : entier = 2
session2
client2
Pour illustrer comment la session dun client interagit avec les instances des classes Pistolet,
Gchette et DispositifDePompage, on dfinit une collaboration (figure 6.29).
Figure 6.29
Une collaboration
qui permet de
montrer le
droulement
dune session de
prise dessence.
La SessionDePriseDeCarburant
: Pistolet
: Gchette
: DispositifDePompage
: Cuve
: SessionDePriseDeCarburant
UML en pratique 217
Cette collaboration est dcrite plus en dtail la figure 6.30. Elle dbute par la cration
dune session pour un client (instance de la classe SessionDePriseDeCarburant). Ensuite, des
instances des classes Pistolet, Gchette et Pompe sont cres leur tour. Cest l un parti pris.
Nous avons en effet dcid que ces instances nexistaient pas avant que le client dcroche un
pistolet. Une autre solution aurait consist disposer dun pool dobjets prts lemploi
dans lequel on aurait pris volont des instances. Ce choix relve plutt de la conception
que de lanalyse. Considrons-le comme un scnario de conception possible. La figure 6.30
montre que les instances du pistolet et de la gchette sont dtruites ds que le client raccroche le pistolet. Deux autres diagrammes servant illustrer larmement de la pompe et la
prise du carburant sont rfrencs.
Figure 6.30
Interaction
qui illustre la
collaboration
de la figure 6.29.
sd SessionDePriseDeCarburant
client : Client
pompiste : Pompiste
session : SessionDePriseDeCarburant
pompe : DispositifDePompage
: Pistolet
gchette : Gchette
Affiche numro de pompe + type essence pris
ref
ArmementPompe( client, pompiste, session, pompe )
ref
ActivationPompe( client, session, gchette, pompe )
Affiche la fin de la prise dessence
Dsarmer pompe
Larmement de la pompe est illustr par le diagramme de la figure 6.31. On y voit que, avant
darmer la pompe, il faut tester si plusieurs pistolets ne sont pas dcrochs, puis vrifier le
niveau de la cuve. Lacteur CapteurNiveauPourArmement nest pas reprsent ici : il est sollicit implicitement par linstance de la cuve.
218
UML 2
Chapitre
Figure 6.31
Interaction qui
illustre larmement
de la pompe.
sd ArmementPompe( inout client : Client, inout pompiste : Pompiste, inout session :

SessionDePriseDeCarbutant, inout pompe : DispositifDePompage)
+autrePistolet : boolen
client : Client
pompiste : Pompiste
cuve : Cuve
ref
autrePistolet = TestAutrePistoletPris
opt
[ autrePistolet == false ]
Demande
Armement
Demande niveau dans
cuve pour armement
Niveau dans cuve
pour armement OK
armer
armement
OK
RAZ compteur volume

La figure 6.31 fait rfrence au diagramme TestAutrePistoletPris qui nest pas reprsent (il
sagit simplement de demander linstance de lEnsemblePompe de vrifier laide dune
boucle quil ny a pas plusieurs pistolets dcrochs).
Le diagramme reproduit la figure 6.32 dtaille linteraction ActivationPompe qui est rfrence la figure 6.30.
Figure 6.32
Interaction qui
illustre lactivation
de la pompe.
sd ActivationPompe( inout client : Client, inout session : SessionDePriseDeCarburant, inout gchette : Gchette, inout pompe :
DispositifDePompage )
gchette : Gchette
client : Client
loop
Appuyer sur la gchette
activer
Relcher la gchette
dsactiver
UML en pratique 219
Session de paiement. Intressons-nous prsent au paiement, et imaginons un objet pour

le contrler. Si la session de prise de carburant (instance de la classe SessionDePriseCarburant) tait prolonge de manire englober le paiement, un objet pourrait alors contrler le
service de prise dessence de bout en bout , depuis le dcrochage du pistolet jusqu la fin
du paiement. Ce serait la session complte dun client. Or, les classes du domaine ont t
partitionnes en deux paquetages pour accrotre la modularit du logiciel : un paquetage
concerne la prise dessence, lautre le paiement. Une session client unique serait donc partage entre les deux paquetages (elle dbuterait avec la prise de carburant pour se terminer par
le paiement). Cest pourquoi nous avons dcid de crer une nouvelle classe contrleur
(SessionDePaiement) qui se charge du paiement.
La figure 6.33 tablit une collaboration entre des instances de PriseDeCarburant, de TransactionBancaire, de TransactionsDuJour et de SessionDePaiement. Les connecteurs entre les
instances de PriseDeCarburant, de TransactionBancaire et de TransactionsDuJour reprsentent les associations du diagramme de classes du domaine (figure 6.10).
Figure 6.33
La SessionDePaiement
Collaboration pour
le paiement.
: PriseDeCarburant
: TransactionBancaire
: TransactionsDuJour
session : SessionDePaiement
La figure 6.34 illustre les interactions au sein de la collaboration prcdente. La session de

paiement dbute au moment o le pompiste demande, via son terminal, encaisser la prise
dessence relative une pompe et un type de carburant. Le montant de la transaction est
calcul laide du type de carburant (qui permet davoir le prix du litre) et de la quantit
dessence prise. Le diagramme se poursuit par le droulement du scnario nominal de paiement par carte bancaire. Une instance de TransactionBancaire est cre le temps de raliser
une transaction avec la banque. Ds que le pompiste valide la transaction, celle-ci est
ajoute aux transactions du jour pour tre finalement dtruite. La session de paiement se
termine juste aprs, par la destruction de linstance correspondante.
220
UML 2
Chapitre
Figure 6.34
Interaction qui
illustre comment le
paiement est ralis
durant la session
de paiement.
sd payer par carte bancaire
pompiste : Pompiste
Banque
encaissement( pompe, typeCarburant )
: SessionDePriseDeCarburant
demande la quantit pompe
quantit
Calcul du Montant
Afficher montant payer
opt
[ paiement par carte bancaire]

validerTransaction( montant )
Transaction valide
Paiement effectu
Informe pompiste
Valide la transaction
Valider transaction
Ajouter la transaction client
Un gestionnaire pour larchivage. Aprs avoir trouv des objets contrleurs pour assurer
les fonctions de prise dessence et de paiement, intressons-nous aux autres fonctions du
logiciel. Pour cela, revenons au diagramme de cas dutilisation de la figure 6.16. Deux cas
nont pas t traits : Vrifier niveau cuve pour remplissage et Archiver les transactions . Le premier cas nest pas tudi dans cet ouvrage car il ne prsente pas un grand
intrt. Larchivage des transactions est plus intressant.
UML en pratique 221
Le diagramme de la figure 6.35 montre comment, en fin de journe, les transactions du jour
sont archives. Pour raliser cette fonction, nous ajoutons une nouvelle classe, GestionnaireDesArchivages. Une seule instance de cette classe est ncessaire pour faire fonctionner
larchivage. Lobjet correspondant est actif une fois par jour ( minuit). Il demande larchivage des transactions du jour ; aprs quoi linstance de la classe TransactionsDuJour est
dtruite pour tre recre aussitt (et initialiser ainsi une nouvelle journe de transactions).
Figure 6.35
Diagramme qui
illustre comment le
gestionnaire des
archivages ralise
la sauvegarde
quotidienne des
transactions.
sd Archiver les transactions
: GestionnaireDesArchivages
Timer
loop
Il est minuit lhorloge

archiver
systme
MODLE
DES TATS DE LAPPLICATION

Ltude de lapplication a conduit lajout de classes supplmentaires. Il faut prsent
reprer parmi ces classes celles qui engendrent des instances ayant des tats complexes, et
pour chacune delles, suivre la dmarche suivante :
identifier des classes de lapplication avec des tats complexes ;
trouver les vnements ;
construire les diagrammes dtats ;
vrifier la cohrence avec les autres modles.
Cette tude, bien quindispensable, na pas t reproduite ici car elle nest pas dun grand
intrt pdagogique.
AJOUT
DES OPRATIONS
La phase danalyse de notre logiciel est prsent presque acheve. Il reste ajouter des
oprations aux classes. Les oprations peuvent tre dduites des cas dutilisation et
des scnarios.
Considrons nouveau le diagramme de la figure 6.31 (o le test sur le nombre de pistolets
dcrochs a t omis). Rcrivons les messages destins aux objets en respectant la syntaxe
des messages utiliss dans les diagrammes de squence (voir chapitre 3).
222
UML 2
Chapitre
Figure 6.36
sd ArmementPompe (inout client : Client, inout pompiste : Pompiste, inout session : SessionDePriseDeCarbutant,
inout pompe : DispositifDePompage)
Les messages
destins aux objets
mis la norme
des diagrammes
de squence.
client : Client
pompiste : Pompiste
cuve : Cuve
armementPompe
armement
niveauSuffisantPourArmement
niveauSuffisantPourArmement : vrai
armer
armement : vrai
RAZ compteur volume
Chaque message destin un objet devient une opration pour la classe correspondante. La
classe Cuve par exemple contient prsent lopration niveauSuffisantPourArmement() :
boolen comme le montre la figure 6.37.
Figure 6.37
Ajout dune opration
la classe Cuve.
Cuve
niveau : entier
niveauSuffisantPourArmement() : boolen
Procder ainsi systmatiquement pour tous les diagrammes dinteraction produits permet
dajouter des oprations aux classes. La figure 6.38 montre des classes qui concernent la
prise de carburant auxquelles ont t ajoutes des oprations.
UML en pratique 223
Figure 6.38
SessionDePriseDeCarburant
Quelques classes
du domaine avec
leurs oprations.
demandeArmementPompe : boolen
dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant )
raccrochagePistolet
appuiGchette
relachementGchette
Gchette
appuye : boolen
appuyer
relcher
PriseDeCarburant
DispositifDePompage
arm : boolen
actif : boolen
armement : boolen
armer : boolen
dsarmer : boolen
activer : boolen
dsactiver : boolen
getQuantitCarburant : rel
Phase de conception
La phase danalyse est prsent termine. Ltude a permis de prciser ltendue des besoins
auquel doit rpondre le logiciel de gestion dune station-service, mais aussi spcifier et
comprendre ce quil doit faire. Dans la phase suivante, la conception, il sagit de dcider
comment raliser ce logiciel. Cette phase passe par de nombreuses tapes o UML nest pas
utile (le choix des ressources ncessaires pour excuter le logiciel par exemple). Dans la suite
de ce chapitre, nous nous intressons aux seules tapes o UML est utile.
CONCEPTION
DU SYSTME
1. Dcomposez le systme en sous-systmes.

2. Reprez les objets qui sexcutent concurremment.
1. Isoler la couche mtier pour prvoir la rutilisabilit des classes du domaine . Un
dcoupage possible en sous-systmes est prsent la figure 6.39. Il y a quatre couches :
Tout en haut, la couche de prsentation contient linterface homme machine du pompiste.
Les classes contrleurs (SessionDePriseDeCarburant, SessionDePaiement et GestionnaireDesArchivages) constituent la couche applicative.
224
UML 2
Chapitre
La logique mtier est compose des classes du domaine (reprsentes ici par les paquetages qui les contiennent).
La gestion des priphriques (capteurs de niveau des cuves, gestion des pompes et du
terminal de paiement) est incluse dans la couche de services.
noter la relation de dpendance qui existe entre la couche applicative et la couche de services : elle indique que larchivage dans la base de donnes (non reprsente) est directement gr par le gestionnaire de la persistance (GestionnairePersistance) sans passer par la
couche mtier.
Figure 6.39
Architecture du
logiciel de gestion
de la station-service.
layer
Prsentation
layer
Logique applicative
________________________
+SessionDePriseDeCarburant
+SessionDePaiement
+ GestionnaireDesArchivages
layer
Logique mtier
ServiceCarburant
Transactions
layer
Services
______________________
+PiloteGestionCuve
+Pompe
+PiloteGestionPaiement
+GestionPersistance
Le systme a donc t dcoup en couches horizontales. Lapplication, essentiellement contenue dans la couche applicative, permet, grce aux classes contrleurs, de raliser les cas
dutilisation. Sans ses classes contrleurs, couche applicative et couche mtier seraient
UML en pratique 225
mlanges tel point que la rutilisabilit des classes de la couche mtier serait compromise.
La sparation entre logique applicative et logique mtier permettra une autre application
de rutiliser les classes du domaine.
Augmenter la rutilisabilit par partie du logiciel. Le dcoupage en couches prcdent a
permis disoler la partie mtier (les classes du domaine) afin de ne pas lencombrer avec les
dtails de lapplication. Une autre partition du logiciel est possible par fonctionnalits.
Dailleurs, bien souvent, ces deux types de dcoupage sont raliss simultanment.
Une partition fonctionnelle a dj t ralise quand nous avons spar les classes du
domaine en deux paquetages (figure 6.11). Il est possible disoler les paquetages en les plaant dans un classeur structur (voir lannexe B). La figure 6.40 prsente un classeur structur qui contient le paquetage ServiceCarburant.
Figure 6.40
PriseCarburant
Structure interne
du classeur structur
PriseCarburant.
ServiceCarburant
Le classeur PriseCarburant interagit avec son environnement via des ports (figure 6.41).
Certains reoivent ltat des capteurs pistolet et gchette, dautres servent dinterface avec le
pompiste ou avec le moteur de la pompe, dautres encore servent rcuprer la quantit
dessence pompe.
Figure 6.41
InterfacePompiste
Ports du classeur
PriseCarburant.
Entre tat
capteur pistolet
Sortie
commandes
pompe
InterfacePistolet
PriseCarburant
InterfaceGchette
Entre tat
capteur
gchette
Sortie quantit essence pompe
InterfaceDbitmtre
226
UML 2
Chapitre
Ces interfaces ont t labores partir des classes contenues dans le paquetage du classeur
structur. Par exemple, la classe SessionDePriseDeCarburant contient une opration destine au pompiste, deux oprations qui servent dinterface avec le pistolet, et deux oprations
qui sont relies la gchette.
Figure 6.42
Sparation
des oprations
de la classe
SessionDePriseDe
Carburant pour
prparer les
interfaces.
demandeArmementPompe : boolen
raccrochagePistolet
appuiGchette
relachementGchette
opration invoque par le pompiste

oprations lies au pistolet
oprations lies la gchette
On retrouve ces trois ensembles doprations dans les trois interfaces : InterfacePompiste,
InterfacePistolet et InterfaceGchette (figure 6.43). Ainsi, une seule classe interne un classeur structur peut tre accessible via plusieurs interfaces.
Figure 6.43
interface
InterfacePistolet
Interface qui indique

si le pistolet est
rang.

raccrochagePistolet
interface
InterfaceGchette
interface
InterfaceDbitmtre
appuiGchette
relachementGchette
getQuantitPompe : rel
interface
InterfacePompiste
demandeArmementPompe() : boolen
getNumeroPompe() : entier
getTypeCarburant() : TypeCarburant
priseCarburantTermine
La figure 6.44 montre comment le classeur structur PriseCarburant interagit avec son environnement quand un client appuie sur une gchette. Cette information est transmise au
composant CapteurGchette, puis circule via linterface InterfaceGchette jusquau classeur
structur PriseCarburant. Ce classeur est alors considr comme une bote noire (le composant CapteurGchette na pas accs sa structure interne). Il adopte un certain comportement qui engendre ventuellement une commande sur son port de sortie. Cette commande
est rpercute jusquau moteur de la pompe en passant par le composant Pompe qui implmente linterface InterfacePompe (figure 6.45).
UML en pratique 227
Figure 6.44
Gchette
Cheminement dune
information depuis
lappui sur une
gchette jusqu
la commande du
moteur de la pompe.
Moteur pompe Gchette
Priphriques de gestion des pompes
InterfaceCapteurGchette
: CapteurGchette
unit centrale
Systme informatique de la station
service
Entre tat
capteur
gchette
PriseCarburant
: Pompe
Sortie
commandes
pompe
InterfacePompe
InterfaceGchette
Figure 6.45
Vue dtaille de
linterface qui
contrle le moteur
de la pompe.
interface
InterfacePompe
armer : boolen
dsarmer : boolen
activer : boolen
dsactiver : boolen
Le classeur PriseCarburant doit parfaitement sinsrer dans lapplication. Pour le vrifier, les
scnarios issus de lanalyse de lapplication peuvent tre repris afin de montrer comment le
classeur interagit avec son environnement.
Utiliser un classeur structur muni de ports permet disoler la structure interne du classeur
de son environnement. Le but tant de pouvoir facilement rutiliser ce classeur dans un
environnement qui se conforme aux interactions imposes par ses ports. Le dcoupage
opr avec le classeur PriseCarburant pourrait tre reproduit pour la gestion des transactions. Le systme informatique de la station-service ainsi dcoup gagne en modularit.
Chaque sous-systme, qui est isol dans un classeur structur, peut tre facilement extrait
du contexte de lapplication courante et utilis dans une autre application.
228
UML 2
Chapitre
Figure 6.46
Classeur structur
dont le comportement
est dcrit par une
interaction.
PriseCarburant
ref
ServiceCarburant
2. Le modle des tats dun systme est gnralement utilis pour reprer les objets qui
sexcutent en parallle : deux objets sexcutent potentiellement en parallle sils peuvent recevoir des vnements en mme temps sans interagir. Si les vnements ne sont
pas synchroniss, ces objets ne peuvent pas tre traits dans le mme thread de contrle.
Dans notre cas, les vnements qui concernent la prise de carburant par un client ainsi
que le paiement sont squentiels. En revanche, chaque client doit avoir sa propre session
de prise de carburant et de paiement. Les instances des classes SessionDePriseDeCarburant
et SessionDePaiement sexcutent toutes en parallle sans interagir, sauf au moment
de larchivage des transactions. Larchivage est sous le contrle dun objet du type
GestionnaireDesArchivages (figure 6.35). Que se passe-t-il alors si un client paye aprs
stre servi de lessence minuit, au moment o larchivage se dclenche ? Larchivage
utilise une instance des TransactionsDuJour (figure 6.35) et cette mme instance peut tre
utilise concurremment par une session de paiement pour y ajouter la transaction dun
client (figure 6.34). Le diagramme de la figure 6.47 utilise loprateur dinteraction par
pour montrer que le gestionnaire des archivages et la session client peuvent accder
concurremment linstance de TransactionsDuJour (le deuxime oprande est extrait de
linteraction de la figure 6.34, o seul le message Ajouter la transaction client est pris
en considration). Pour que la session de paiement ne vienne pas perturber larchivage,
cette fonction est ralise dans une section critique grce loprateur dinteraction
ritical (voir chapitre 3).
UML en pratique 229
Figure 6.47
Concurrence daccs
sur linstance des
transactions du jour.
sd archiver les transactions + se servir
: SessionDePaiement
: GestionnaireDesArchivages
Timer
par consider{ archiver, il est minuit lhorloge systme, ajouter la transaction client }
critical
archiver
Il est minuit
lhorloge systme
critical
Conception des classes

Les diagrammes dactivit sont utiles toutes les tapes du dveloppement dun systme.
En phase de conception, ils permettent de dcrire le fonctionnement interne des mthodes
des classes afin de prciser les algorithmes utiliss.
Considrons le diagramme de squence suivant extrait du scnario de paiement par carte
bancaire au moment o le pompiste valide la transaction du client. Celle-ci est alors ajoute lensemble des transactions du jour (instance de la classe TransactionsDuJour).
Dcrivez laide dun diagramme dactivit comment la transaction du client est ajoute
lensemble des transactions du jour.
230
UML 2
Chapitre
Figure 6.48
Diagramme de
squence pour
larchivage
de transactions.
sd gestion des transactions
Pompiste
Valide la transaction
Valider transaction
Indications : on suppose que les transactions du jour sont structures en tableau, et que les
transactions y sont tries par ordre croissant de leur montant en euros.
Figure 6.49
Diagramme de
squence pour
larchivage de
transactions.
t1 : TransactionClient
t2 : TransactionClient
tn : TransactionClient
10 euros
12,3 euros
47 euros
Lalgorithme utilis pour ajouter une nouvelle transaction consiste parcourir le tableau
la recherche de lemplacement o ajouter la transaction, puis faire de la place pour la
nouvelle transaction en dcalant les transactions existantes.
Lalgorithme propos correspond un tri par insertion, dont une modlisation est propose
la question 3 de lexercice 3 du chapitre 5. La seule contrainte impose par lactivit tri
insertion est que le type contenu dans le tableau pass en argument ralise linterface Comparable. Il suffit donc dcrire un comparateur entre deux transactions qui corresponde
lordre propos : t1 < t2 quivalent t1.montant < t2.montant. Cela peut simplmenter
directement comme un oprateur en C++, ou comme une mthode en Java.
UML en pratique 231
Annexe A
Comparatif des outils

de modlisation
Introduction
Pour se servir efficacement dUML, il faut utiliser un outil adapt vos besoins. Labondance de loffre en la matire rend son choix trs difficile. Lobjectif de cette annexe est den
prsenter brivement quelques-uns afin de permettre le choix rapide et efficace de loutil le
mieux adapt. Un accent sera mis sur le cot des licences. Nous prciserons, en particulier,
si les outils disposent dune licence dite acadmique, permettant aux professionnels dbutants, aux tudiants et aux formateurs dillustrer lintrt dUML, sans devoir, dans un
premier temps, investir dans une licence onreuse.
Pour un simple diteur de diagramme UML, adapt aux phases danalyse et de conception,
loffre est large, et le choix de loutil importe finalement peu, pourvu que son ergonomie
soit raisonnable (placement des objets et des arcs, navigation entre les diagrammes).
On pourra alors regarder du ct de lopen-source o les plugins ou petits outils UML
abondent (BoUML, ArgoUML, TopCased), ou utiliser une version modeler dun
outil professionnel.
Un des intrt de la modlisation qui accompagne le dveloppement informatique est, dun
cot, la production de code et, de lautre, la gnration de modles partir du code.
De ce fait, il est important que votre outil propose des fonctions de rtro-ingnierie (extraction de modle depuis le code) et rciproquement de gnration de code depuis le modle
(en gnral surtout les diagrammes de classe, parfois aussi machines tat). Lidal dans
les phases de conception dtaille et dimplmentation est que loutil sintgre dans votre
environnement de dveloppement de code (IDE) pour permettre de garder une bonne synchronisation entre le code et les modles. Il faut galement exiger de loutil quil soit capable
de gnrer un document lisible et imprimable, contenant les diffrents diagrammes qui
composent un modle.
La majorit des outils sont disponibles en version dvaluation limite dans la dure, donc
nhsitez pas en tlcharger deux ou trois avant de fixer votre choix ; lchange de modles
entre outils est quasiment impossible.
La liste ci-aprs est trie par nom dditeur.
Comparatif des outils de modlisation 233
Compagnie : vendeur de loutil

Produit : nom du produit dcrit
Licence acadmique : existe-t-il une licence gratuite pour les enseignements ?
Licence commerciale : prix de la licence commerciale, varie beaucoup selon le nombre de
postes, dutilisateurs
IDE : loutil sintgre-t-il dans un environnement de dveloppement intgr ?
Langages : pour quels langages les traductions code <-> UML sont-elles possibles ?
Description : une brve description de loutil.
+ Points forts de loutil
Points faibles
Compagnie : Borland
Produit : Together
Licence acadmique : essai 15 jours
Licence commerciale : prix disponible en contactant leur service commercial (!)
IDE : Eclipse
Langages : Java, BPMN (Business Process Modeling Notation)
Description : dune ergonomie sans faille, robuste et rapide, cet outil offre de nombreux
services support (vrification de contraintes OCL, audit de projet, extraction de diagrammes de squence depuis le code, transformation de modles). Outil rellement
de qualit industrielle, qui accompagne le dveloppement de lanalyse des besoins au
dveloppement du code.
+ Ergonomie, prise en main.
+ Synchronisation code Java.
Difficult dobtention de licence.
Compagnie : Gentleware
Produit : Poseidon
Licence acadmique : Community Edition, svrement bride
Licence commerciale : Professional Edition, 700 1 200
IDE : Professional Edition intgre dans Eclipse, Community Edition outil java standalone
Langages : Java
Description : bas sur loutil open-source gratuit ArgoUML, lergonomie de Poseidon
reste revoir. Il est parfois choisi cependant pour sa facilit de dploiement (32 Mo, tlchargement sans questions). La politique commerciale de Gentleware a voulu pousser,
depuis 2005, sa communaut dutilisateurs gratuits passer la version payante, avec
pour rsultat un outil CE aux fonctions appauvries (pas dextraction de modle), ce qui
est un peu dommage.
+ diteur graphique UML entre de gamme.
Ergonomie et fonctionnalits limites.
234
UML 2
Compagnie : IBM/Rational
Produit : Rational Rose Enterprise
Licence acadmique : complte sous programme IBM Academic Initiative ngociable
par les enseignants.
Licence commerciale : 5 000 10 000
IDE : Standalone, intgration partielle dans Visual Studio 2005
Langages : Visual C ++, Visual Basic 6, Ansi C ++, SQL, Java (1.4)
Description : Rose a t le premier outil de modlisation UML, au dbut des annes 2000.
Il na pas t mis jour pour supporter UML 2, il reste cependant un outil trs agrable
manipuler, et il supporte bien linteraction avec les technologies Microsoft, ainsi quavec
les bases de donnes. noter quil existe galement un produit IBM offrant du support
pour C#, mais qui nest pas inclus dans Rose.
+ Ergonomie bien travaille.
+ Importation de projets Visual.
Ne supporte pas UML 2.
Compagnie : IBM/Rational
Produit : Rational Software Architect
Licence acadmique : complte sous programme IBM Academic Initiative ngociable
par les enseignants.
Licence commerciale : 4 000 12 000
IDE : bas sur Eclipse
Langages : Java, C ++, Corba
Description : un outil norme, par sa taille (6 Go disque, 1 Go RAM), mais aussi par ses
capacits plus avances que la concurrence. Construit sur Eclipse, supporte bien tout
UML 2. Notons que loffre de IBM/Rational se dcline en plusieurs variantes, ce produit
constitue leur haut de gamme.
+ Modlisation trs avance, bon support des diagrammes de squence, machines tat.
+ Services de gnration de code/extraction de modle.
Lourdeur de loutil, ncessite une grosse configuration pour tourner correctement.
Compagnie : Microsoft
Produit : Visio
Licence acadmique : inclus dans le lot Microsoft MSDN Academic Alliance
Licence commerciale : 360 780
IDE : Visual Studio (menu Visio)
Langages : (partiel) C#, VB. Net
Description : Visio est dabord un outil de dessin puissant, permettant de produire assez
facilement des diagrammes techniques de bonne qualit graphique. Une palette contenant les lments des diagrammes UML est incluse avec loutil. Visual Studio offre galement une option permettant de produire des diagrammes de classe sous Visio partir
dun projet, mais cela reste relativement limit. Certaines des illustrations de ce livre sont
ralises laide de Visio.
+ Logiciel de dessin au rendu graphique agrable.
Pas rellement un outil UML.
Comparatif des outils de modlisation 235
Compagnie : No magic
Produit : MagicDraw UML
Licence acadmique : version bride ldition de diagrammes disponible par ngociation
des enseignants
Licence commerciale : 400 2 150
IDE : Eclipse, NetBeans, JBuilder
Langages : Java, C ++, C# (partiel)
Description : un outil assez plaisant visuellement, et dune ergonomie globalement bonne.
MagicDraw offre un certain nombre de services de transformation de modles et de dfinition de profils. Linteraction avec le Java est assez bonne (cration de diagrammes de
squence depuis le code), les fonctionnalits pour le C ++ et C# sont beaucoup plus limites.
+ Un outil honnte, au rendu graphique et lergonomie au dessus de la moyenne.
La version offerte aux enseignants ne permet que le dessin.
Compagnie : Omondo
Produit : EclipseUML
Licence acadmique : version Free edition , quelques fonctionnalits brides
Licence commerciale : version Studio 2 500 7 100
IDE : Intgration Eclipse
Langages : Java, J2EE
Description : un des premiers plugins UML pour Eclipse, bas sur les standards open-source.
Spcialement ddi au Java, offre une bonne synchronisation code/diagrammes de classe.
Les autres diagrammes sont cependant dans lensemble plutt dlaisss, mme si un diteur
graphique sommaire est fourni pour chaque type de diagramme. Permet davoir une visualisation UML du code du projet dans les phases de conception dtaille et dimplmentation.
+ Synchronisation avec le code Java (jdk < = 1.6), intgration dans Eclipse.
+ Facile tlcharger et installer.
Supporte surtout les diagrammes de classe.
Compagnie : Visual-Paradigm
Produit : Visual-Paradigm for UML
Licence acadmique : Programme Academic Partners, version standard gratuite ngociable
par les enseignants
Licence commerciale : 400 1 200
IDE : intgration dans la majorit des IDE, effort particulier pour Eclipse
Langages : Java, C ++, PHP, SQL-JDBC, Ada, Python Support partiel dautres langages
Description : un outil assez agrable visuellement et ergonomique pour ldition de diagrammes. La version standard offerte aux enseignants inclut suffisamment de fonctionnalits pour tre vraiment utilisable, une version logiciel de dessin UML gratuite est
disponible. Les diffrents diagrammes sont faciles construire. Beaucoup de fonctionnalits sont proposes pour interagir avec les bases de donnes.
+ Interface ergonomique.
+ Bon support pour une large palette de langages.
Documentation proche de la publicit, difficile parfois de trouver linformation
pertinente.
236
UML 2
Annexe B
Classeurs structurs
Les classes dcouvertes au moment de lanalyse (celles qui figurent dans le diagramme de
classes) ne sont pas assez dtailles pour pouvoir tre implmentes par des dveloppeurs.
Lanalyse montre ce que doit faire un systme mais pas comment il doit tre ralis. Cest le
rle des concepteurs de faire des choix de ralisation. Une technique de conception consiste
dcomposer un systme jusqu ce quapparaissent des niveaux de dtails suffisamment
fins pour permettre limplmentation. UML propose de partir des classeurs dcouverts au
moment de lanalyse tels que les classes, les sous-systmes, les cas dutilisation, , et de
les dcomposer. Les classeurs ainsi dcomposs sappellent des classeurs structurs. Ils se
prsentent comme des classes qui montrent leurs structures internes. Un classeur structur
est constitu de plusieurs parties relies par des connecteurs. La figure B.1 illustre une commande de billets de spectacle par un client via un classeur structur.
Figure B.1
rle
type
Une classe structure.
commandeBillet
client : Personne
partie
1..*
billetCommand : Billet
connecteur multiplicit
Chaque classeur est constitu de parties spcifiques : une partie ne peut pas figurer dans
deux classeurs. Cette condition permet de dcomposer un classeur sur plusieurs niveaux.
Dfinition
Une partie est un fragment dun classeur structur.
Notation
Comme un classeur, une partie est reprsente par un rectangle contenant une tiquette
dont la syntaxe est :
<nomDuRle> [: <nomDuType> multiplicit ]
Tandis que les parties dun classeur structur reprsentent une structure de donnes, les
rles correspondent ses diffrents comportements et permettent de dfinir le contexte
dans lequel il est utilis.
Classeurs structurs 237
Un classeur interagit avec son environnement via des ports (voir chapitre 2) par o passent
des messages. La figure B.2 illustre lutilisation des ports dans une classe structure.
Figure B.2
Une classe structure
avec des ports.
signal
audio
entre niveau ligne
Carte son
sortie audio [2]
niveau sonore
entre niveau micro

niveau
micro
interface fournie
ports
interface requise
Annexe C
Composants
Un composant est une unit autonome au sein dun systme ou sous-systme. Cest un
classeur structur particulier, muni dune ou plusieurs interfaces requises ou offertes, possiblement travers des ports explicitement reprsents. Son comportement interne est
totalement masqu de lextrieur, seule ses interfaces mergent du composant. Le modle
de composants favorise la rutilisation en fournissant un grain plus grossier que celui des
classes, qui permet davoir des entits rellement autonomes.
Le programmation par composants constitue une volution technologiques en matire
de programmation, soutenue par de nombreuses plateformes (composants EJB, CORBA,
COM+ ou .Net, WSDL). Laccent est sur la rutilisation du composant, et son volution
de faon indpendante des applications qui lutilisent. Un composant peut tre dploy
dans diverses configurations, selon ses connexions avec les autres lments du systme. Au
contraire, une classe est lie de faon fige au systme dont elle fait partie, les associations
avec les autres classes reprsentant des liens structurels. En ce sens, sans perdre la gnralit
dun classeur, un composant est plus proche dune instance de classe que dune classe, et
les diagrammes de composants sapparentent plus des diagrammes des objets qu des
diagrammes de classe.
Un composant est reprsent laide dun rectangle comme un classeur ordinaire, muni du
mot-cl component , et optionnellement dun graphisme particulier (figure C.1) plac
dans un angle.
238
UML 2
Figure C.1
Un composant
avec une interface
requise et une
interface offerte.
component
Persistence
Persistance
BaseDeDonnes
component
Persistance
provided interface
Persistance
crer
stocker
charger
required inteface
BasesDeDonnes
JDBC
Les composants sont raliss par des ensembles de classeurs, qui implmentent le comportement dclar par les interfaces du composant. Un composant peut tre ralis de diffrentes
manires, sans affecter ses interfaces. La seule contrainte pour pouvoir substituer un composant un autre est de prserver les interfaces requises et offertes. La faon dont un
composant est ralis peut tre dfinie plusieurs niveau de dtail.
Un composant peut tre vu comme une bote noire. On ne fait alors merger que ses interfaces et lon utilise une des prsentations de la figure C.1.
On peut galement dcrire la structure interne du composant en bote blanche. On expose
ainsi la faon dont le composant est ralis, avec une reprsentation proche de celle dun
claseur structur. On connecte alors les ports externes du composant aux ports des classeurs
constituant ses parties, par un arc qui reprsente une relation de dlgation (figure C.2) : les
messages qui arrivent sur ce port sont directement transmis au composant interne. Cette
vision hirarchique permet de dcomposer un systme en sous systmes relativement indpendants, et donc plus rutilisables. Les interfaces requises et offertes sont connectes entre
elles pour exprimer lassemblage des parties ralisant le composant.
Figure C.2
La ralisation dun
composant expose
en bote blanche.
component
Persistance
Persistance delegate
delegate
BaseDeDonnes
CollectionPersistante
delegate
AnalyseurDeClasse
PersistanceTypeDeBase
Composants 239
Annexe D
Diagramme
de dploiement
UML nest pas limit la production de modles utiles aux phases danalyse et de conception.
Le dploiement qui prcde la mise en production constitue une tape importante du dveloppement dun systme. Au final, ce dernier va sexcuter sur des ressources matrielles
(processeurs, mmoire, etc.) dans un environnement particulier. UML permet de reprsenter un environnement dexcution ainsi que des ressources physiques (avec les parties du
systme qui sy excutent) grce aux diagrammes de dploiement. Lenvironnement dexcution ou les ressources matrielles sont appels nuds . Les parties dun systme qui
sexcutent sur un nud sont appeles artefacts . Un artefact peut prendre la forme
dun fichier binaire excutable, dun fichier source, dune table dune base de donnes, dun
document, dun courrier lectronique, etc.
La figure D.1 reprsente le dploiement dun serveur Web avec lequel une machine cliente,
dote dun navigateur Web, communique. Le serveur, qui est connect une base de donnes
installe sur une machine tierce, excute lartefact siteWEB.
Figure D.1
Diagramme de
dploiement pour
un serveur Web
qui prsente des
instances de nuds
et une instance
dartefact dploye.
client : PC
serveurWEB : Serveur
serveurBaseDeDonnes : ServeurSGBD
dploy
artfact
siteWEB
Le diagramme de la figure D.1 contient des instances de nuds. un niveau dabstraction

plus lev (au niveau des nuds), ce diagramme peut se reprsenter de la faon suivante.
Figure D.2
Diagramme de
dploiement pour
un serveur Web
qui prsente des
nuds.
240
UML 2
PC
Serveur
1..*
ServeurSGBD
Les associations entre les nuds sont des chemins de communication tels que des cbles
rseaux, des bus, etc., qui peuvent porter une multiplicit : la figure D2 prsente plusieurs
PC qui sont connects au site Web du serveur.
Dfinition
Un nud est une ressource sur laquelle des artefacts peuvent tre dploys pour tre excuts. Un artefact est la spcification dune entit physique du monde rel.
Notation
Un nud se reprsente par un cube dont le nom respecte la syntaxe des noms de classes (voir
chapitre 2). Le nom dun nud instanci doit tre soulign (figure D.1).
Un artefact se reprsente comme une classe par un rectangle contenant le mot-cl artefact
suivi du nom de lartefact. Celui-ci est soulign quand il sagit dune instance. Un artefact
dploy sur un nud est symbolis par une flche en trait pointill qui porte le strotype
dploy et qui pointe vers le nud (figure D.1). Lartefact peut aussi tre inclus directement
dans le cube reprsentant le nud.
Plusieurs strotypes standard existent pour les artefacts : document, excutable, fichier,
librairie, source.
Annexe E
Implmentation dun
modle objet en Java
Dans le cycle de dveloppement dun systme, limplmentation correspond la phase
de ralisation. Quand il sagit dun logiciel, cela consiste traduire les modles danalyse et de
conception dans un langage de programmation. Cette phase peut tre automatise en partie
avec des outils informatiques de modlisation. Ces outils sont nombreux (GDPro, ObjectTeam, Objecteering, OpenTool, Rhapsody, STP, Visio, Visual Modeler, WithClass, ).
Certains supportent UML depuis ses dbuts (Rose de Rational Software), dautres viennent
du monde du logiciel libre (ArgoUML). Nombreux sont les outils qui permettent la gnration automatique de code partir dun diagramme de classes vers des langages de programmation varis (Java, C++, C#, etc.). Dans la suite de ce paragraphe, nous montrons
comment implmenter les lments essentiels dun diagramme de classes, et comment traduire les messages des diagrammes dinteraction (de squence ou de communication) en Java.
Implmentation dun modle objet en Java 241
Notation
Les implmentations vers diffrents langages sont assez proches les unes des autres. par tir
dune implmentation en Java, il est donc facile de passer dautres langages.
Une implmentation dans un langage donn peut tre ralise de diffrentes manires.
IMPLMENTATION
DE LHRITAGE
Figure E.1
Voiture
seDeplacer
VoitureAEssence
Implmentation dun hritage

public class Voiture{
public void seDeplacer(){
//
}
}
public class VoitureAEssence extends Voiture{
}
Figure E.2
interface
Vehicule
Voiture
Implmentation dune interface

public interface Vehicule{
public void seDeplacer();
}
public class Voiture implements Vehicule{
public void seDeplacer(){
//
}
}
242
UML 2
IMPLMENTATION
DES RELATIONS ENTRE CLASSES
Les langages de programmation comme Java noffrent pas de technique particulire pour
implmenter des associations, des agrgations ou des compositions. Ce type de relation
simplmente en ajoutant des attributs dans des classes.
Figure E.3
Exemplaire
0..1
range
Emplacement
Association unidirectionnelle de 1 vers 1

public class Emplacement{
}
public class Exemplaire{
private Emplacement range;
public void setEmplacement( Emplacement emplacement ){
this.range = emplacement;
}
public Emplacement getEmplacement(){
return range;
}
public static void main( String [] args ){
Emplacement emplacement = new Emplacement();
Exemplaire exemplaire = new Exemplaire();
exemplaire.setEmplacement( emplacement );
Emplacement place = exemplaire.getEmplacement();
}
}
Remarque
Pour accder lassociation plus facilement (sans passer par les mthodes setEmplacement
et getEmplacement), il est possible de supprimer le mot-cl private (ce nest possible que si
les classes font partie dun mme paquetage).
Figure E.4
Voiture
0..1
0..1
Conducteur
Association bidirectionnelle de 1 vers 1

package bagnole;
public class Conducteur{
Voiture voiture;
public void setVoiture( Voiture voiture ){
if( voiture!= null ){
this.voiture = voiture;
voiture.conducteur = this;
}
}
public static void main( String [] argv ){
Voiture voiture = new Voiture();
Conducteur conducteur = new Conducteur();
conducteur. addVoiture ( voiture );
}
}
package bagnole;
Conducteur conducteur;
public void setConducteur( Conducteur conducteur ){
this.conducteur = conducteur;
conducteur.voiture = this;
}
}
Figure E.5
Entreprise
1
+
clients
Client
Association unidirectionnelle de 1 vers plusieurs

public class Client{
}
import java.util.Vector;
public class Entreprise{
private Vector clients = new Vector();
public void addClient( Client client ){
clients.addElement( client );
}
public void removeClient( Client client ){
clients.removeElement( client );
}
Entreprise monEntreprise = new Entreprise();
Client client = new Client();
monEntreprise.addClient( client );
monEntreprise.removeClient( client );
}
}
244
UML 2
Figure E.6
uvre
uvre
1..n exemplaires
Exemplaire
Association bidirectionnelle de 1 vers plusieurs

import java.util.Vector;
class Oeuvre{
Vector exemplaires = new Vector();
public void addExemplaire( Exemplaire exemplaire ){
if( exemplaires.contains( exemplaire ) == false ){
exemplaires.addElement( exemplaire );
}
}
public void removeExemplaire( Exemplaire exemplaire ){
if( exemplaires.removeElement( exemplaire ) == true )
exemplaire.oeuvre = null;
}
Oeuvre donGiovani = new Oeuvre();
Exemplaire exemplaire = new Exemplaire( 1 );
donGiovani.addExemplaire( exemplaire );
}
}
class Exemplaire{
int numro;
Oeuvre uvre;
public Exemplaire( int numro ){
this.numro = numro;
}
public void setOeuvre( Oeuvre oeuvre ){
if( oeuvre!= null ){
oeuvre.exemplaires.addElement( this );
this.oeuvre = oeuvre;
}
}
public void removeOeuvre( Oeuvre oeuvre ){
if( oeuvre.exemplaires.removeElement( this ) == true )
this.oeuvre = null;
}
public boolean equals( Object obj ){
if( (obj!=null) && (obj instanceof Exemplaire) )
return numero == ((Exemplaire)obj).numero;
else return false;
}
}
Figure E.7
Voiture
Moteur
Composition
private class Moteur{
}
private Moteur moteur;
}
Agrgation : une agrgation simplmente comme une association
IMPLMENTATION
Figure E.8
DE LENVOI DE MESSAGES
com Piloter
conduire
conducteur : Conducteur
dmarrer
voiture : Voiture
Implmenter les messages des diagrammes de communication

public class Conducteur{
private Voiture voiture;
public void setVoiture( Voiture voiture ){
if( voiture!= null ){
this.voiture = voiture;
}
}
public void conduire(){
voiture.demarrer();
}
Voiture voiture = new Voiture();
Conducteur conducteur = new Conducteur();
conducteur.setVoiture( voiture );
conducteur.conduire();
}
}
public void demarrer(){
//
}
}
Implmenter les messages des diagrammes de squence

Ce diagramme est quivalent au prcdent au niveau interprtation et donne donc lieu au
mme code (voir figure E.9).
246
UML 2
Figure E.9
sd Piloter
conducteur : Conducteur
voiture : Voiture
conduire
demarrer
Annexe F
Organisation dUML 2
DIFFRENTES
VUES DUML
Le langage UML sintgre dans toutes les phases du cycle de vie du dveloppement, allant de
la collecte des besoins au dploiement. UML ne dfinit pas de processus de dveloppement.
Il est utilisable avec la plupart des processus existants. UML donne la possibilit dutiliser
les mmes concepts et notations, sans ncessiter de conversion, dans les diffrentes phases
de dveloppement. Il est, de ce fait, bien adapt au cycle de dveloppement itratif et
incrmental.
ORGANISATION
EN PAQUETAGES
Un paquetage dfinit des regroupements qui rpondent aux contraintes applicatives et aux
besoins du dveloppement. Dans la version 2 dUML, un modle est dfini par un paquetage
qui comprend une description complte dun systme partir dun point de vue spcifique.
Le mtamodle UML, qui est aussi compos dun ensemble de modles, est modlis par
des paquetages. Les principales caractristiques des normes OMG sont regroupes dans le
paquetage dit Core. UML, CWM, MOF, les profils et les autres mtamodles utilisent les
standards spcifis dans le modle Core, comme le montre la figure F.1.
Organisation dUML 2 247
Figure F.1
Structure du
mtamodle en
paquetages.
Chaque modle (paquetage) est, son tour, compos de plusieurs sous-paquetages, ce qui
confre UML une organisation arborescente. Plus on remonte vers la racine, plus on slve
dans le niveau dabstraction. Par exemple, le modle Core contient les sous-paquetages
PrimitivesTypes, Abstractions, Basic et Profils, comme le montre la figure F.2.
Figure F.2
Structure
hirarchique
du modle
(paquetage)
Core.
Selon le mme principe, chaque paquetage est, lui-mme, compos de plusieurs sousmodles. Par exemple, le modle de la superstructure dUML 2, qui permet de spcifier la
syntaxe des modles utilisateurs, est compos, entre autres, dun modle de classes, dun
modle dinteractions, dun modle de profils et dun modle de cas dutilisation, comme le
montre la figure F.3.
248
UML 2
Figure F.3
Paquetages
composant la
superstructure du
langage UML 2.
COUCHES
DU MTAMODLE
Les paquetages dfinissent la hirarchie dabstraction entre les diffrents modles, mais ne
mettent pas en vidence les diffrentes couches de modlisation, en particulier les diffrences entre les mtamodles et le modle de donnes. LOMG propose une organisation en
couches de ses langages parmi lesquels figure UML 2. Les caractristiques quils partagent
sont regroupes dans le mtamodle MOF. Linstanciation de ce mtamodle donne naissance des langages comme UML et CWM. Lutilisateur dUML dfinit des classeurs (classes, associations) dcrivant son application en respectant les spcifications du
mtamodle UML. Un modle utilisateur bien employ garantit un modle dobjets physiques actifs, avec des proprits bien dfinies.
Une architecture de modlisation se compose de quatre couches : les couches M0, M1, M2
dfinissent respectivement les instances actives du modle utilisateur, le modle de donnes
utilisateur, et le mtamodle UML, la faon dont est construit ce dernier tant spcifie par
la couche M3. Lexemple prsent la figure F.4, extrait de la spcification de la superstructure du langage UML, illustre les quatre couches.
La vido (aVido) qui est en train dtre visionne est une instance active : elle se situe au
niveau M0. Cette vido est une instance de la classe Vido (diagramme de classes), en
loccurrence linstance 2001 : A spaceOdyssey (diagramme dobjets). Les diagrammes de
classes et dobjets correspondent au modle utilisateur : ils sont donc au niveau M1. La
classe Vido et les attributs quelle contient sont modliss dans le respect du mtamodle
UML, qui spcifie comment dfinir une classe et un attribut : ils font donc partie de la couche M2. Un attribut, une classe et une instance respectent les spcifications MOF. Au niveau
de la couche MOF, ils sont spcifis par une classe (cela correspond la couche M3).
Figure F.4
Exemple mettant
en vidence
lorganisation en
quatre couches
du langage UML.
MODLES
CONCEPTUELS DUML
Les paquetages et les couches donnent une organisation architecturale du langage UML. Un
utilisateur na pas besoin de connatre cette organisation pour bien utiliser ce langage. Il doit
se contenter de respecter la syntaxe et la smantique dUML. Il doit galement connatre les
diffrents diagrammes mettant en valeur tantt des aspects statiques, tantt des aspects
comportementaux du systme. Une organisation conceptuelle des diffrents diagrammes
UML permet davoir une vision plus claire des vues offertes par ce langage. Les trois auteurs
lorigine dUML proposent un dcoupage conceptuel en quatre domaines : structurel,
dynamique, physique et gestion de modles. Chaque domaine est compos de plusieurs
vues et chaque vue est ralise par un ensemble de diagrammes UML.
Domaine structurel
Le domaine structurel est compos des trois vues suivantes :
La vue fonctionnelle. Elle conceptualise et structure les besoins de lutilisateur (diagramme de cas dutilisation). Elle dfinit le contour du systme modliser en dfinissant les fonctionnalits principales sans pour autant chercher lexhaustivit. Elle sert
dinterface entre les diffrents intervenants dans le projet.
La vue statique. Elle dfinit les principaux classeurs de lapplication. Elle est modlise
par un ensemble de classes dotes dattributs et doprations. Celles-ci sont organises
via des relations de composition, de gnralisation, etc. Des objets en excution peuvent
tre modliss pour illustrer leur comportement et leurs relations. La vue statique se prsente essentiellement sous forme de diagrammes de classes et dobjets.
La vue conceptuelle. Elle met en vidence les collaborations entre classeurs et dcrit
larchitecture physique du systme. Elle est ralise par le diagramme de collaborations et
le diagramme de composants.
250
UML 2
Domaine dynamique
Le domaine dynamique regroupe lensemble des vues montrant le comportement du systme lexcution : la vue des interactions (diagramme dactivits), des machines tats
(diagramme dtats-transitions), des interactions (diagramme de squences et diagramme
de communication)
Domaine physique
Le domaine physique est compos de la seule vue de dploiement. Elle dcrit lemplacement
physique du matriel utilis et la rpartition des composants sur ce matriel. Ces ressources
sont modlises par des nuds interconnects. Cette vue est particulirement importante
dans le cas de la modlisation des environnements distribus o une place importante est
donne lexpression des exigences en termes de performances.
Domaine gestion de modles

Le domaine gestion de modles montre une organisation en paquetages du modle luimme. Il est ralis via le diagramme de paquetages et est compos de deux vues :
La vue des profils. Les profils permettent dapporter des changements restreints aux
modles UML pour les adapter des outils ou plates-formes tout en conservant linteroprabilit. Ces changements sont assurs par des mcanismes dextension du langage. Les
deux principaux lments dextension en UML sont les contraintes et les strotypes. On
appelle profil un ensemble cohrent de strotypes avec les contraintes associes.
La vue de gestion de modles. Elle modlise lorganisation du modle par un ensemble
de paquetages et leurs relations. Un modle est dfini par un point de vue et un niveau de
prcision. Le choix de la granularit des paquetages et de la manire de les organiser dfinissent la vue de gestion du modle.
Annexe G
Bibliographie
[Blaha 2005]
Michael Blaha, James Rumbaugh. Modlisation et conception orientes objet avec UML 2,
Pearson Education, 2005
[Gamma 95]
rich Gamma, Richard Helm, Ralph Johnson et John Vlissides. Design Patterns: Elements
of Reusable Object-Oriented Software, Addison-Wesley, 1995
[Jacobson 1999]
Ivan Jacobson, Grady Booch et James Rumbaugh. Le processus unifi de dveloppement
logiciel, Eyrolles, 1999
[Kernighan, Ritchie 1990]
Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, Prentice Hall, Inc.
1988. En franais : Le Langage C : norme ANSI, taduit par Jean-Franois Groff et ric Mottier,
Dunod, coll. Sciences sup , 2e dition, 2004
[Larman]
Craig Larman. UML et les design patterns, deuxime dition, CampusPress, 2005
[Norme UML 2.0]
OMG (Object Management Group). UML 2.0 Superstructure (rfrence ptc/04-10-02),
UML 2.0 Infrastructure (rfrence ptc/03-09-15), http://www.uml.org, 2004
[Penders 2002]
Tom Penders. Introduction UML, EOM, 2002
[Rumbaugh 2004]
James Rumbaugh, Ivar Jacobson et Grady Booch. UML 2.0 - Guide de rfrence, CampusPress, 2004
252
UML 2
Index
A
Abstraite
classe 38
mthode 38
Acteur 3, 9, 16, 27, 29
Action
call 131, 156
manipulations de variables 158
opaque 160
raise exception 157
send 157
sur un link 159
time event 131
Activit
argument d'une 168
concurrence 171, 181
description 161
et cas d'utilisation 178, 182
exception 172
interne 133
interruptible 174
ligne d'eau 166
partition 166
pin 168
programmation 166, 177, 179, 183
structure 166
structures de contrle 164
zone d'expansion 175
Agrgation 50
Alt, oprateur dinteraction 96
Alternative 96
Analyse
du systme 1
phase d 190
Argument 94
Artefact 241
Assert 95
Assert, oprateur 98
Assertion 95
Association 46
avec contraintes 47
classe 48
drive 48
n-aire 49
qualifie 49
Asynchrone, message 91, 111
Attribut driv 61
B
Boucle
oprateur 104
reprsentation 97
Break 97
C
Cas d'utilisation 2, 9
acteur 3
dfinition 3
diagramme 1, 2, 15
extension 5, 25, 27
gnralisation 5, 29
inclusion 5, 29
relations 5, 18
Index 253
Classe 37
active 64
attribut de la 40, 41
contrainte sur 65
exceptions 43
mthode de la 42
nom de la 38, 63
opration de la 42, 43
paramtrable 65
responsabilits d'une 43
strotype 63
Classeur 36
dfinition 4
rle 237
structur 88, 125, 226, 237
utilisation 88
Collaboration
dfinition 89
rle 89
utilisation 122
Com, mot-cl 87
Composition 50
Conception 89, 194
Concurrence
activits 171
barre de synchronisation 135
tats-transitions 139
zone d'expansion 175
Connecteurs 54
Consider, oprateur 98
Construction du diagramme de classes 57
Contraintes 56
de dure 114
sur les lignes de vie 95
Critical 117
D
Dpendance, relation de 51
Dploiement, diagramme 197, 240
Diagramme
d'interactions 87, 106
d'objets 74, 217
dtats-transitions 128
de cas d'utilisation 1, 2, 15
de classes 35
de communication 87, 106
de dploiement 197, 240
de squence 87, 106
objets 54
254
UML 2
Dure, contrainte de 114

E
Else 96
Encapsulation 39
private 40
protected 40
public 40
tats-transitions
activit interne 133
concurrence 135, 139
tat
composite 134
simple 128, 133
historique 136
interface 137
point
de choix 132
de connexion 137
de jonction 131
protocol 138, 143
transition automatique 135
vnement 134
dclencheur 129
dfinition 129
signal 130
time event 129, 157
Exception 12, 23
gestionnaire d 172
pin d 169
raise 157
Extension entre les cas dutilisation 5, 6, 25, 27
F
Flot
d'objet 169
contraintes 169
de contrle 161, 164
flow final 171
Fragment
combin 96, 115, 120
d'interaction 96, 116
G
Garde
dans un diagramme d'activits 164
tats-transitions 131
Gnralisation de cas dutilisation 29, 31
Index
H
Hritage 71, 72
exceptions 174
multiple 53, 72
relation 52
signal 130
Historique, pseudo-tat 136
Objet 37
actif 113
ligne de vie 86
passif 113
reprsentation 55
Occurrence d'vnement 92
Oprande d'interaction 96
Opt 120
I
Ignore, oprateur 98
Implmentation en langage Java 241
Inclut 5
Inout, paramtre 94, 105
Instance 37
de relation 56
Interaction
dfinition 86
diagramme 87
fragment 96
message 87, 91, 92, 103
oprande 96
utilisation 106
Interface 44
ralisation d'une 68
utilisation d'une 68
Interne, structure 237
L
Ligne de vie 86
M
Message
asynchrone 64, 91
dans un diagramme
de communication 104, 108
de squence 94, 107
dfinition 91
dlai de transmission 91
signal 130
synchrone 91, 156
Modle des cas dutilisation 1, 15
Modlisation d'une classe 61
Multiplicit 45
P
Paquetage 25
dfinition 8
dpendance 25
Par, oprateur 97, 117
Parallle, envoi de messages 97
Paramtre
de retour 94
inout 94, 105
Partie structure 237
Patron de conception
adapteur 81
Bridge 80
objets composites 74
Phase
d'implmentation 188
de dploiement 188
de maintenance 188
de tests 188
Pin
d'exception 169
dfinition 168
stream 170
Point
d'extension 6, 28, 33
de choix 132
de jonction 131, 164
Port 54
proprits 54
protocole 54
Postcondition 12, 23
Prcondition 12, 22
protocol 138
R
N
Neg 120
Nud dans un diagramme de dploiement 240
Numro de squence 103
Rgion interruptible 174

Relation 45, 69
agrgation 50
composition 50
Index 255
d'extension 5
d'inclusion 5
dpendance 51
d'instanciation 56
gnralisation 5, 7, 28
hritage 52
n-aire 70
simple 66
256
T
Thread 91
U
Utilisation
d'une collaboration 89
d'une interaction 88
Scnario 14
Sd, mot-cl 87
Signal 54
vnement 130
Strotype, dfinition 4
Strict sequencing, oprateur 99
Structure interne 237
Synchrone, message 91
Synchronisation des activits 171
Variables, manipulation 158

Visibilit de paquetages 8
UML 2
Z
Zone d'expansion 175
Informatique
Synthse
de cours
exercices
corrigs
&
Les auteurs :
Benot Charroux dirige le
dpartement informatique de
lEFREI (Villejuif), o il enseigne la
modlisation et la programmation
objet. Il est galement formateur en
entreprise.
Aomar Osmani est matre de
confrences luniversit Paris XIII.
Il assure des enseignements sur
UML, les bases de donnes,
lalgorithmique, la programmation
objet, le gnie logiciel et les
rseaux. Il y est aussi responsable
de la Licence en formation continue.
Yann Thierry-Mieg est matre de
confrences luniversit Paris VI.
Il effectue des recherches sur UML 2
dans le cadre de mthodologies
de dveloppement adaptes au
domaine des logiciels critiques.
Dans la mme collection :
Algorithmique, Applications en C,
J.-M. Lry
Algorithmique en C++, J.-M. Lry
Algorithmique en Java 5, J.-M. Lry
Architecture de lordinateur, E. Lazard
Architecture des rseaux, D. Seret,
D. Dromard
Cration de bases de donnes,
N. Larrousse
Excel 2007 et VBA, B. Minot
Java 5 et 6, R. Chevallier
LaTeX, J.-C. Charpentier, D. Bitouz
Le langage C, J.-M. Lry
Le langage C++, M. Vasiliu
Linux, J.-M. Lry
Mathmatiques discrtes appliques
linformatique, R. Haggarty
SQL, F. Brouard, C. Soutou
Systmes dexploitation, B. Lamiroy et al
XML, G. Chagnon, F. Nolot
UML 2
2e dition
Pratique de la modlisation
UML est le langage de modlisation le plus utilis dans lindustrie,

principalement pour le dveloppement logiciel. Synthex UML 2 prsente tous les concepts fondamentaux de ce langage et les met en
perspective au moyen de nombreux exemples comments. Il explique
galement comment les diffrents modles ncessaires la conception
dun logiciel se compltent pour en donner une vision exhaustive et
cohrente.
Les exercices corrigs, qui reprsentent la moiti de chaque chapitre,
permettent dappliquer les notions prsentes. Une tude de cas finale
rassemble les lments essentiels du langage et montre comment mettre en uvre les volutions dUML 2.
Cette nouvelle dition propose notamment un comparatif des principaux outils de modlisation, avec les avantages et les inconvnients
de chaque logiciel, afin que le lecteur puisse choisir le produit le plus
adapt ses besoins.
Louvrage sadresse aux tudiants de premier et de second cycles (IUT,
BTS, universits et coles dingnieurs) ainsi quaux professionnels.
Il constitue la fois une mthode pratique dapprentissage du langage
UML, un support concis de rvision et dauto-valuation, et un outil de
travail prcieux pour les professionnels en formation continue.
La collection Synthex informatique propose de dcouvrir les

fondements thoriques et les applications pratiques des principales
disciplines de science informatique. partir dune synthse de cours
rigoureuse et dexercices aux corrigs dtaills, le lecteur, tudiant
ou professionnel, acquiert une comprhension rapide et un
raisonnement solide.
ISBN : 978-2-7440-4050-4
Pearson Education France

47 bis, rue des Vinaigriers 75010 Paris
Tl. : 01 72 74 90 00
Fax : 01 42 05 22 17
www.pearson.fr

Livre UML 2

Transféré par

Informations du document

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

Livre UML 2

Transféré par

Droits d'auteur :

Formats disponibles

Informatique

Les principaux diagrammes dUML

UML2-Pr lims Page I Vendredi, 14. d cembre 2007 11:37 11

UML2 Livre Page II Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page III Vendredi, 14. d cembre 2007 7:24 07

Chapitre 1 Diagramme de cas dutilisation

Chapitre 2 Diagramme de classes

Chapitre 3 Diagramme dinteraction

Chapitre 4 Diagramme dtats-transitions

Chapitre 5 Diagramme dactivits

Chapitre 6 UML en pratique

Annexe A Comparatif des outils de modlisation

Annexe D Diagramme de dploiement

Implmentation dun modle objet en Java

UML2 Livre Page IV Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page V Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page VI Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page VII Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page VIII Vendredi, 14. d cembre 2007 7:24 07

Le processus RUP propose de bien matriser les tapes successives de la modlisation et du

Historique du langage UML

UML2 Livre Page IX Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page X Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page XI Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page XII Vendredi, 14. d cembre 2007 7:24 07

UML2 Livre Page 1 Vendredi, 14. d cembre 2007 7:24 07

UML permet de construire plusieurs modles dun systme :

(depuis le recueil des besoins jusqu la phase de

des modles, en loccurrence le premier construire :

conception). Dans ce chapitre, nous allons tudier un

danalyser et dorganiser les besoins. Avec lui dbute

UML2 Livre Page 2 Vendredi, 14. d cembre 2007 7:24 07

Limportance de bien recueillir les besoins

Le diagramme de cas dutilisation

UML2 Livre Page 3 Vendredi, 14. d cembre 2007 7:24 07

Borne interactive dune banque

Figures 1.2 et 1.3

Diagramme de cas dutilisation 3

UML2 Livre Page 4 Vendredi, 14. d cembre 2007 7:24 07

Borne interactive dune banque

Le rectangle de la figure 1.5 est appel classeur .

Borne interactive dune banque

UML2 Livre Page 5 Vendredi, 14. d cembre 2007 7:24 07

ENTRE ACTEURS ET CAS DUTILISATION

Un acteur peut utiliser plusieurs fois le mme cas dutilisation.

Tlcharger une musique

ENTRE CAS DUTILISATION

Diagramme de cas dutilisation 5

UML2 Livre Page 6 Vendredi, 14. d cembre 2007 7:24 07

Borne interactive dune banque

Relations entre cas

Consulter sur Internet

Systme de vente par correspondance

Relations entre cas

UML2 Livre Page 7 Vendredi, 14. d cembre 2007 7:24 07

Systme de vente par correspondance

Suivre une commande

Diagramme de cas dutilisation 7

UML2 Livre Page 8 Vendredi, 14. d cembre 2007 7:24 07

DES CAS DUTILISATION EN PAQUETAGES

UML2 Livre Page 9 Vendredi, 14. d cembre 2007 7:24 07

Modlisation des besoins avec UML

SONT LES ACTEURS

RECENSER LES CAS DUTILISATION