Académique Documents
Professionnel Documents
Culture Documents
Joo Info UML - 2 - Pratique - de - La - Modélisation - 2ème - Edition PDF
Joo Info UML - 2 - Pratique - de - La - Modélisation - 2ème - Edition PDF
Synthse
de cours &
exercices
corrigs
UML 2
Pratique de la modlisation
2e dition
collection
Synthex
Benot CHARROUX
Aomar OSMANI
Yann THIERRY-MIEG
UML2-Pr lims Page I Vendredi, 14. d cembre 2007 11:37 11
Informatique
Synthse
&
exercices
de cours 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
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 V
Introduction VII
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 raisonne-
ment 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 orien-
tes 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 problmati-
ques 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
Introduction VII
UML2 Livre Page VIII Vendredi, 14. d cembre 2007 7:24 07
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 utili-
sateurs 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 nom-
breux 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 pr-
cision 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 res-
pecte toujours la mme dmarche dont la premire tape correspond une prsentation du
point de vue fonctionnel. Lanalyse fonctionnelle permet de mettre au point une reprsen-
tation graphique, compacte et complte des besoins, appele diagramme de cas dutilisa-
tion . 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 int-
ress par les changes dans le temps (diagramme de squence) ou encore par les collabo-
rations 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 chapi-
tre 6 introduit le diagramme de composants, qui permet une organisation statique du sys-
tme, 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 modli-
sera 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 compo-
se 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 ini-
maginable 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 entre-
prise 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 facto-
riser 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.
X 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 rvolu-
tionnaire : les principales fonctionnalits de base se ressemblent. Au niveau du mtamodle,
qui concerne surtout les dveloppements doutils, UML 2 se rapproche davantage des stan-
dards 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 dfi-
nir 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 nota-
tion 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 concep-
tuel 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
Diagramme de cas
1
Chapitre
dutilisation
1. Limportance de bien recueillir UML permet de construire plusieurs modles dun systme :
les besoins ................................ 2 certains montrent le systme du point de vue des utilisateurs,
2. Le diagramme de cas dutilisation 2
3. Modlisation des besoins dautres montrent sa structure interne, dautres encore en
avec UML ................................ 9 donnent une vision globale ou dtaille. Les modles se
Problmes et exercices compltent et peuvent tre assembls. Ils sont labors tout
1. Identification des acteurs et
recensement de cas dutilisation au long du cycle de vie du dveloppement dun systme
simples .................................... 16
(depuis le recueil des besoins jusqu la phase de
2. Relations entre cas dutilisation.... 18
3. Relations entre cas dutilisation conception). Dans ce chapitre, nous allons tudier un
cas internes ........................... 18
des modles, en loccurrence le premier construire :
4. Identification des acteurs,
recensement des cas dutilisation le diagramme de cas dutilisation. Il permet de recueillir,
et relations simples entre cas...... 20
5. Description dun cas dutilisation 22
danalyser et dorganiser les besoins. Avec lui dbute
6. Relations dextension entre cas ltape danalyse dun systme.
dutilisation, regroupement de
cas dutilisation en paquetages .. 25
7. Relations entre acteurs,
extensions conditionnelles
entre cas dutilisation ................ 27
8. Identification des acteurs, recen-
sement des cas dutilisation
internes et relation de gnra-
lisation entre cas....................... 29
1
UML2 Livre Page 2 Vendredi, 14. d cembre 2007 7:24 07
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 sim-
ple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas dutilisation.
Ils permettent de recenser les grandes fonctionnalits dun systme.
EXEMPLE 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.
2 UML 2
UML2 Livre Page 3 Vendredi, 14. d cembre 2007 7:24 07
Figure 1.1
Diagramme
frontire du sujet Borne interactive dune banque nom du sujet
1
Chapitre
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.
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 stro-
types 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
Borne interactive dune banque
Reprsentation des cas
dutilisation un niveau
dabstraction lev.
Dfinition
Un classeur est un lment de modlisation qui dcrit une unit comportementale ou struc-
turelle. 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
Borne interactive dune banque
Les compartiments
dun classeur.
Retirer argent
Effectuer un virement
Consulter comptes
4 UML 2
UML2 Livre Page 5 Vendredi, 14. d cembre 2007 7:24 07
EXEMPLE La figure 1.7 montre un internaute qui tlcharge plusieurs morceaux de musique sur Internet.
Internaute
Le symbole * qui signifie plusieurs est ajout lextrmit du cas et sappelle une multi-
plicit. Plusieurs valeurs sont possibles pour la multiplicit : exactement n scrit tout sim-
plement 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.
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 gnra-
lisation/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 infor-
mations 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. Graphi-
quement, 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 pr-
sente 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 dcomposi-
tion en sous-cas.
Notation et spcification
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 ventuelle-
ment 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
Borne interactive dune banque
Relations entre cas Retirer argent
dans un diagramme
de cas dutilisation.
Effectuer un virement
Point dextension : inclut
vrificationSolde {aprs
avoir demand le
montant} inclut
tend Sauthentifier
Client
Vrifier le solde
Condition : {si montant > 20 euros}
Point dextension : vrificationSolde
inclut
Consulter comptes
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 .
6 UML 2
UML2 Livre Page 7 Vendredi, 14. d cembre 2007 7:24 07
Dfinition
1
Chapitre
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 duti-
lisation 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.
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 duti-
lisation 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.
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.
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.
Support
Stock
En tant que langage, UML est soumis des rgles de nommage quil faut strictement respec-
ter : 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.
8 UML 2
UML2 Livre Page 9 Vendredi, 14. d cembre 2007 7:24 07
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 exem-
ple, 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 solli-
citations.
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 secon-
daire est sollicit pour des informations complmentaires.
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 inter-
actives 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 techni-
ques 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 rac-
tion 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 fonc-
tionnement du systme, et orienter les travaux de rdaction de la documentation lusage
des utilisateurs.
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 duti-
lisation.
EXEMPLE 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.
10 UML 2
UML2 Livre Page 11 Vendredi, 14. d cembre 2007 7:24 07
Figure 1.12
Diagramme de cas
Gestion dune banque
1
Chapitre
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 distribu-
tion 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 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 appa-
ratre une squence de messages.
Le graphisme utilis fait partie du formalisme des diagrammes de squence (voir chapitre 3).
Figure 1.13
sd Retirer argent
Description dun cas
dutilisation par
une squence : Systme
de messages.
Guichetier Systme
central
Saisie du numro de compte client
Compte valide
Compte dbit
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.
12 UML 2
UML2 Livre Page 13 Vendredi, 14. d cembre 2007 7:24 07
EXEMPLE Dans le cas dun retrait dargent, des squences alternatives se produisent par exemple dans
les situations suivantes :
1
Chapitre
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).
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 som-
maire, de laspect des crans des interfaces permet de fixer les ides ; il offre une excel-
lente 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 per-
mettant 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 fonc-
tionnement interne inconnus. Donc, a fortiori, ce stade, nous ne savons toujours pas com-
ment 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 spcifica-
tions 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 pr-
cisment 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
UML2 Livre Page 15 Vendredi, 14. d cembre 2007 7:24 07
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
1
Chapitre
suffisamment pousse, de poser les bases de la structure interne du systme, et donc dalter-
ner 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.
16 UML 2
UML2 Livre Page 17 Vendredi, 14. d cembre 2007 7:24 07
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,
1
Chapitre
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 supplmen-
taire 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
Mcanicien
Exercices
Grer la station
Chef
datelier
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.
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 modli-
ses 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
UML2 Livre Page 19 Vendredi, 14. d cembre 2007 7:24 07
indpendants. Ils constituent des cas internes du systme car ils ne sont pas relis directe-
ment un acteur.
1
Chapitre
Organiser un voyage
Agent de
voyages
Organiser un voyage
Agent de
Points dextension :
voyages
tablirUneFacture
Condition : { la demande du
client} tend
Point dextension : tablirUneFacture
3. Il y a maintenant deux cas particuliers : le voyage se fait en train ou en avion. Ces cas par-
ticuliers 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 .
Exercices
Figure 1.21
Agence de voyages
Relation de
gnralisation entre Rserver une Rserver un titre
cas dutilisation. Rserver un taxi de transport
chambre dhtel
Organiser un voyage
20 UML 2
UML2 Livre Page 21 Vendredi, 14. d cembre 2007 7:24 07
faut rester au niveau des grandes fonctions et penser en termes de transactions (une tran-
saction est une squence doprations qui fait passer un systme dun tat cohrent initial
un tat cohrent final).
1
Chapitre
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 Emprunter une vido
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 pro-
pritaire 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 sor-
tie 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 Emprunter une vido
inclut
recherche dune
vido.
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 modlisa-
tion 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.
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.
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
UML2 Livre Page 23 Vendredi, 14. d cembre 2007 7:24 07
Rubriques optionnelles
Contraintes non fonctionnelles
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.
Contrainte lie linterface homme-machine
Avant de dlivrer la cassette, demander confirmation au client.
Exercices
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, com-
die 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.
Lenchanement dmarre aprs le point 1 de la squence nominale :
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.
Rubriques optionnelles
Contraintes non fonctionnelles
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
UML2 Livre Page 25 Vendredi, 14. d cembre 2007 7:24 07
Commenons par modliser le robot. Ses capteurs (camra, moteur et roues) sont lext-
rieur 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 Com-
mander la direction reli lacteur Direction.
Pour pouvoir envoyer les images au poste de pilotage et recevoir les commandes en retour, il
Exercices
radio. Cela dpasse le cadre de cet ouvrage. Considrons que le systme informatique inter-
vient, 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 dutilisa-
tion. 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.
Camra
Condition : {ds quune image tend
complte a t capture}
Point dextension : envoiImage
Envoyer les images
metteur
Points dextension :
- commandeMoteur Rcepteur
- commandeDirection
Moteur Direction
26 UML 2
UML2 Livre Page 27 Vendredi, 14. d cembre 2007 7:24 07
Figure 1.26
Systme de pilotage dun robot
Diagramme de cas
dutilisation du Recevoir des images
systme de pilotage.
Points dextension :
afficheImage
Rcepteur
Condition : {ds quune image
complte a t reue} tend
Point dextension : afficheImage
Afficher les images
Tlpiloter
Pilote
Points dextension :
envoiCommande
metteur
Modlisez laide dun diagramme de cas dutilisation une mdiathque dont le fonction-
nement est dcrit ci-aprs.
Une petite mdiathque na quune seule employe qui assume toutes les tches :
la gestion des uvres de la mdiathque ;
Exercices
28 UML 2
UML2 Livre Page 29 Vendredi, 14. d cembre 2007 7:24 07
Figure 1.27
Diagramme de cas
Une mdiathque
inclut
1
Chapitre
inclut
Grer les
adhrents inclut
inclut Sauthentifier
Bibliothcaire
Rechercher
les adhrents inclut
inclut
inclut
Grer les Grer les comptes
emprunts utilisateurs
Administrateur
Grer les contentieux
Points dextension :
Gestionnaire des procdureJudiciaire : {pas
contentieux 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
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 pis-
tolet 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.
Exercices
Le paiement peut seffectuer en espces, par chque ou par carte bancaire. En fin de jour-
ne, 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.
Pour un systme complexe, il vaut mieux se concentrer sur les fonctions essentielles puis
passer aux cas moins importants.
Figure 1.28
Se servir de Se Servir
lessence : solution
avec un cas unique. Client Pompiste
Figure 1.29
inclut
Se servir de Se Servir Armer pompe
lessence : solution
avec deux cas. Client Pompiste
30 UML 2
UML2 Livre Page 31 Vendredi, 14. d cembre 2007 7:24 07
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
1
Chapitre
dinclusion intervient donc entre les cas Armer pompe et Vrifier niveau cuve pour
armement (figure 1.31).
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.
Figure 1.30
Payer
Utilisation
de relations Points dextension :
- paiementEspce,
dextension - paiementParChque
pour modliser - paiementParCarteBancaire
le paiement. {les trois extensions sexcluent mutuellement et
une extension intervient au tout dbut du
paiement}
Condition : {si le client choisit de payer Condition : {si le client
par carte bancaire} choisit de payer en espce}
Point dextension : paiementParCarteBancaire Point dextension :
paiementEnEspce
tend tend tend
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.
32 UML 2
UML2 Livre Page 33 Vendredi, 14. d cembre 2007 7:24 07
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
1
Chapitre
possible dajouter un deuxime point dextension (voir la figure 6.17 du chapitre 6).
pour armement
Capteur niveau cuve
Acteur secondaire du cas Vrifier niveau cuve pour remplissage .
pour remplissage
Timer Acteur secondaire du cas Archiver les transactions .
Banque Acteur secondaire du cas Payer par carte bancaire .
Figure 1.31
Diagramme de cas
dutilisation dune
station-service. Capteur niveau cuve Capteur niveau cuve
pour armement pour remplissage
Station-Service
Vrifier niveau cuve Vrifier niveau cuve
pour armement pour remplissage
inclut
inclut
Se servir Armer pompe
Points dextension :
Client paiement : { la fin du Pompiste
cas se servir }
Condition : {si le client
a pris de lessence avant tend
de raccrocher le pistolet}
Payer
Payer en espce
Payer par carte
bancaire
Archiver les
Banque transactions
Payer par chque
Timer
34 UML 2
UML2 Livre Page 35 Vendredi, 14. d cembre 2007 7:24 07
Diagramme
2
Chapitre
de classes
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 dassocia-
tions existent, qui se reprsentent diffremment (par des losanges, des flches).
Figure 2.1
Une agrgation Entreprise
Exemple de
diagramme
de classes. 1..* 1..* 1..*
Service utilise
Bureau
Une contrainte nom : String
entre relations
{subset}
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 mod-
lisation du diagramme de classes. Commenons par dcrire la gense des classes.
36 UML 2
UML2 Livre Page 37 Vendredi, 14. d cembre 2007 7:24 07
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 per-
ception des structures et des comportements des objets quelle reprsente.
2
Chapitre
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
Le nom de la classe doit tre significatif et
Reprsentation UML complet. Il commence par une majuscule. Sil est
de la classe compos de plusieurs mots, la premire lettre de
Personne. Personne chaque mot doit tre une majuscule. Personne
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 attri-
buts, 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 ins-
tance 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
UML2 Livre Page 38 Vendredi, 14. d cembre 2007 7:24 07
Dans votre environnement quotidien, vous faites abstraction dune quantit de dtails qui
permettent davoir une vision globale et gnralisante du monde. Cette notion dabstrac-
tion 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 limplmen-
tation 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 rectan-
gle 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
Rectangle Implmentation de
FigureGomtrique{abstract}
Exemple de classe lopration dessiner
abstraite. typeTrait : Trait dessiner()
La modlisation dune classe passe par plusieurs tapes auxquelles participent ventuelle-
ment 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
UML2 Livre Page 39 Vendredi, 14. d cembre 2007 7:24 07
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.
2
Chapitre
Spcification
La syntaxe de base de la dclaration dun nom dune classe est la suivante :
[strotype]
[<NomDuPackage1>:::<NomDuPaquetage N>::]
<NomDeLaClasse>[{[abstract],[auteur],[tat],}]
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, indi-
quer les strotypes et les mots-cls du langage. Dans les versions prcdentes dUML, ils
ne servent qu dsigner les strotypes.
2.3 ENCAPSULATION
Diagramme de classes 39
UML2 Livre Page 40 Vendredi, 14. d cembre 2007 7:24 07
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.
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 infor-
mations 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 pro-
grammation objet, comme en tmoigne lexistence de types de base (int, float,) dans les
langages Java et C++.
EXEMPLE 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.
40 UML 2
UML2 Livre Page 41 Vendredi, 14. d cembre 2007 7:24 07
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 multi-
plicit (entre une et deux cents chambres) et la possibilit dassocier une proprit la
2
Chapitre
Figure 2.6
Description des attributs en mettant en vidence la
Classe Htel visibilit et la multiplicit. Dans le cas ou la multiplicit est
mettant en vidence Htel reprsente par plusieurs intervalles, ils sont ordonns par
les modificateurs + chambres : Chambre[1..200] ordre croissant. Quand les intervalles sont continus,ils
daccs, la multipli- + nom : String doivent tre regroups.
cit et les attributs -propritaire : Personne Exemple : [5..6] doit tre prfr "5,6 ".
de classes. + texte : TexteDeLoi
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)]
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.
Diagramme de classes 41
UML2 Livre Page 42 Vendredi, 14. d cembre 2007 7:24 07
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. vi-
demment, pour chaque en-tte, plusieurs implmentations sont possibles.
UML distingue la spcification dune mthode, qui correspond la dfinition de son en-
tte, 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 uni-
que. 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 luti-
lit 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
UML2 Livre Page 43 Vendredi, 14. d cembre 2007 7:24 07
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 ajou-
ter un attribut de classe qui compte le nombre de processus (lors de la cration et de la des-
truction des objets) et une mthode qui affiche ce nombre.
Figure 2.7
Le nombreProc est un attribut de classe priv.
Opration de classe Contrairement au nom qui est associ chaque
et strotype processus, le nombreProc nest disponible quen
dopration. Processus un seul exemplaire. Il est associ la classe.
+ nom : String Les indiquent que tous les attributs ne sont
pas reprsents.
- nombreProc : integer
constructeurs Le strotype type de mthodes est utilis pour
simplifier la notation ou lorsque les oprations ou
+ afficheNombreProc() : void leurs signatures ne sont pas encore connues,
La mthode affiche() est une mthode de classe.
Elle est publique et ne renvoie aucune valeur.
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 clas-
ses telles que les responsabilits, les contraintes gnrales, les exceptions, etc.
Pour ce faire, vous disposez de deux nouveaux compartiments dans la description graphi-
que dune classe, savoir le compartiment des responsabilits et celui des exceptions. Si la
modlisation concerne une application informatique implmenter, ces deux compar-
timents 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.
Diagramme de classes 43
UML2 Livre Page 44 Vendredi, 14. d cembre 2007 7:24 07
Figure 2.8
Compartiment des responsabilits
Compartiment numrant lensemble des tches devant
Connexion
de responsabilit tre assures par la classe.
et dexception. +ip : Byte [4]
Respecter la charte
Possder une adresse IP
+ seConnecter( )
numre les situations exceptionnelles et
exceptions
les anomalies devant tre gres par la classe.
Connexion impossible
(3) Interface
Le rle dune interface est de regrouper un ensemble doprations assurant un service coh-
rent 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 sp-
cifie 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 sp-
cialise et/ou gnralise par dautres interfaces.
La ralisation dune interface par une classe est reprsente graphiquement par un trait dis-
continu 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.
EXEMPLE 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 compa-
raison 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.
44 UML 2
UML2 Livre Page 45 Vendredi, 14. d cembre 2007 7:24 07
Figure 2.10
Les classes Htel
Htel
realize
interface
Comparable Htel
2
Chapitre
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 rela-
tion de dpendance entre la classe et linterface. Une notation lollipop quivalente est aussi
possible, comme le montre la figure 2.11.
NomClasse
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 extr-
mit 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 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.
Diagramme de classes 45
UML2 Livre Page 46 Vendredi, 14. d cembre 2007 7:24 07
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.
EXEMPLE 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.
46 UML 2
UML2 Livre Page 47 Vendredi, 14. d cembre 2007 7:24 07
Cependant, la classe Point ne doit pas avoir dattribut de type Polygone, ni de mthode qui
renvoie les polygones dfinis par ce point.
2
Chapitre
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 +parent Personne *
dassociations 2
rflexives. amie de
*
+enfant
*
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 lexem-
ple de la figure 2.17, lassociation rflexive parent de permet de crer un arbre (hirar-
chie) 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).
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 som-
mets 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 dparte-
ment fait ncessairement partie du personnel.
Diagramme de classes 47
UML2 Livre Page 48 Vendredi, 14. d cembre 2007 7:24 07
1 est responsable
Une association drive est conditionne ou peut tre dduite partir dune autre associa-
tion. 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.
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 Les personnes qui travaillent dans une entreprise occupent un poste. Parmi les proprits asso-
cies au poste figure le salaire. Par ailleurs, quand une personne occupe un poste dans une
entreprise, elle peut tre responsable de plusieurs personnes.
Figure 2.20
Personne Entreprise
Une classe- employ employeur
association est
caractrise par Poste
Association
lajout dun trait rflexive oriente *
salaire : Salaire Classe association
discontinu entre responsable
la classe et
lassociation
quelle reprsente.
48 UML 2
UML2 Livre Page 49 Vendredi, 14. d cembre 2007 7:24 07
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 multipli-
cit indtermine ou infinie en une multiplicit finie, comme le montre la figure 2.21.
EXEMPLE 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 activi-
ts 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
#Compte 0..2 possder * Personne
Une classe qualifiante Banque
client
est colle la classe
principale.
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 cen-
tral 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.
Diagramme de classes 49
UML2 Livre Page 50 Vendredi, 14. d cembre 2007 7:24 07
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.
Une agrgation est une forme particulire dassociation. Elle reprsente la relation dinclu-
sion 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.
50 UML 2
UML2 Livre Page 51 Vendredi, 14. d cembre 2007 7:24 07
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.
Remarque
La relation de composition tant structurelle, le langage UML autorise la reprsentation suivante :
Une dpendance est une relation unidirectionnelle exprimant une dpendance smantique
entre les lments du modle. Elle est reprsente par un trait discontinu orient. Elle indi-
que 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 .
Figure 2.27
EmploiDuTemps Cours
Relation de dpendance.
Diagramme de classes 51
UML2 Livre Page 52 Vendredi, 14. d cembre 2007 7:24 07
Un des intrts de la modlisation objet est la possibilit de manipuler des concepts abs-
traits. 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 par-
titionnement 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.
EXEMPLE Un rectangle et un cercle sont des figures gomtriques. Un carr est un rectangle dont la lon-
gueur 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 spcia-
lise la classe Rectangle en rduisant le domaine de dfinition des attributs existants (largeur
= longueur).
52 UML 2
UML2 Livre Page 53 Vendredi, 14. d cembre 2007 7:24 07
Figure 2.29
Exemple dune
FigureGomtrique
2
Chapitre
relation dhritage.
Rectangle Cercle
largeur: integer
longueur: integer
carr
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).
Diagramme de classes 53
UML2 Livre Page 54 Vendredi, 14. d cembre 2007 7:24 07
Figure 2.30
Si on donne la priorit au
Exemple dhritage Bateau VhiculeMarin alors le type du
multiple. nom dans Bateau sera String.
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 propri-
ts de la relation dhritage.
54 UML 2
UML2 Livre Page 55 Vendredi, 14. d cembre 2007 7:24 07
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.
2
Chapitre
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)).
Les deux principaux classeurs instancis dans le diagramme dobjets sont les classes et les
relations.
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 cor-
respond toutes les valeurs de lattribut taille suprieure un mtre quatre-vingts, par
exemple.
Figure 2.33
:Personne albert:Adhrent :Adhrent ::Asso :Adhrent
Exemples dinstances nom:String="toto" (b) (c) (d)
dobjet. age :integer="inconnu"
Diagramme de classes 55
UML2 Livre Page 56 Vendredi, 14. d cembre 2007 7:24 07
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.
(7) 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 dop-
rations 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 ind-
pendant, dcrivant en dtail la syntaxe formelle et la faon dutiliser ce langage.
56 UML 2
UML2 Livre Page 57 Vendredi, 14. d cembre 2007 7:24 07
EXEMPLE 1. Un comit est compos dau moins deux personnes. Le comit est prsid par un de ses
membres.
2
Chapitre
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.
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.
Diagramme de classes 57
UML2 Livre Page 58 Vendredi, 14. d cembre 2007 7:24 07
une classe : payer ou appeler ne sont pas des bons choix, mme pour une banque ou un op-
rateur 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 Mcani-
cien. 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 plu-
sieurs 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 singu-
lier, 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 asso-
ciations, 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 ter-
naire 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 nces-
saire 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 associa-
tions 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
UML2 Livre Page 59 Vendredi, 14. d cembre 2007 7:24 07
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
2
Chapitre
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 (implmen-
tation 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 exem-
ple). 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 infor-
mations ? Si le monde modliser parat simple, le modle ne devrait pas tre complexe.
Veillez nomettre aucune association. Cependant, ne cherchez pas relier systmatique-
ment 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 mod-
lisation permet dobtenir trois classes : AroportDpart, AroportArrive et Avion (voir exer-
cice 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.
Diagramme de classes 59
UML2 Livre Page 60 Vendredi, 14. d cembre 2007 7:24 07
Conclusion
Dans ce chapitre, nous avons dabord dfini la notion de classe et dobjet. Un objet repr-
sente 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, lasso-
ciation 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 tan-
dis 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
UML2 Livre Page 61 Vendredi, 14. d cembre 2007 7:24 07
Problmes
2
Chapitre
et exercices
Les exercices suivants utilisent les principaux concepts des diagrammes de classes.
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 dinfor-
mations 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
Diagramme de classes 61
UML2 Livre Page 62 Vendredi, 14. d cembre 2007 7:24 07
Remarque
Dans la solution propose, la modlisation de lge est reprsente par un attribut date-
Naissance 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.
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
UML2 Livre Page 63 Vendredi, 14. d cembre 2007 7:24 07
Les oprations assurant le changement des valeurs des attributs peuvent galement tre
regroupes sous le strotype update.
2
Chapitre
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 Personne
Ajout du -chargeSalaire :Float =0.15
-autreCharge : Float =0.2
compartiment
- nom : String
numrant les - prnom : String
exceptions. - sexe : {F,M}
- dateNaissance : Date
- salaire : Integer
- autreRevenu : Integer
constructor
Personne (String nom, Date dNaissance) La mthode correspondante est :
update Renvoie (salaire * chargeSalaire +
+setPrenom (String prenom) autreRevenu * autreCharge)
+setAge(Date dNaissance)
+getNom : String
+getPrnom : String
+calculAge() : Date
+calculCharges () : Float
Exceptions
Calcul charge si dcs
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.
Figure 2.40 Utility
Math
Utilisation du
strotype Utility. PI :Real = 3,14
Exercices
sinus(Angle) : Real
cosinus(Angle) : Real
tangente(Angle) : Real
Diagramme de classes 63
UML2 Livre Page 64 Vendredi, 14. d cembre 2007 7:24 07
La classe Livre est dfinie dans le paquetage Ressource se trouvant lui-mme dans le paque-
tage 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 emprunteur:Bibbliothque ::Adhrent
des classes. nom :base ::String
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 stro-
type 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 Ce signal aurait pu tre modlis dans
signal
Modlisation la classe message sous forme dun message
estAllum
dun signal. asynchrone comme suit :
fait : Boolean signal estOk():Boolean
64 UML 2
UML2 Livre Page 65 Vendredi, 14. d cembre 2007 7:24 07
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 dvne-
ments.
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 vne-
ment, de le suspendre, de lafficher ou de le dtruire. Cela donne le modle prsent la
figure 2.43.
Figure 2.43 Gestionnairevnements Lpaisseur du trait indique
Exemple de classe quil sagit dune classe active.
evts : venement[1..n]
active.
+cration(vnement)
+destruction(vnement)
+afficher(vnement)
+suspendre(vnement)
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 modli-
sation UML de cet lment.
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 lasso-
ciation. 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.
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
Exercices
durant toute la vie de la carte. Dans le cas gnral, les deux contraintes sont indpendantes.
Figure 2.44
CarteDeVisite {frozen, ReadOnly}
Ajout des contraintes
dans la description
dune classe.
Diagramme de classes 65
UML2 Livre Page 66 Vendredi, 14. d cembre 2007 7:24 07
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 sappli-
quent automatiquement.
Figure 2.45 ClasseCible
Liste
En utilisant la classe
paramtrable Liste +inserer(ClasseCible) Livre Liste<Livre>
et la classe standard + supprimer(ClasseCible)
Livre, on dfinit une +chercher(ClasseCible)
liste de livres utilisant
(1)
les proprits de
la classe Liste.
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
UML2 Livre Page 67 Vendredi, 14. d cembre 2007 7:24 07
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 mod-
lisation (mettre en vidence les relations entre classes), il est inutile dajouter dautres
2
Chapitre
informations.
Figure 2.46 tudier
Contraintes entre Universit Personne
{ ou }
associations.
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 dinforma-
tions 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 lasso-
ciation 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 Rectangle Rectangle
-sommet : Point[2]
La figure de gauche constructor
transforme constructor Rectangle(Point, Point)
* -sommet Point
Rectangle(Point, Point)
lassociation entre query 2
les classes Rectangle query + surface () : Float
et Point en une + surface () : Float
relation de update
composition. update +translater (Point)
+translater (Point)
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 publi-
cation. 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 indi-
quer 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.
Figure 2.48
Si datePublication dateNaissance
Ajout de contraintes <10 lcrivain est dit prcoce
Exercices
pour limiter la
porte dune
association.
{ordered} 1..* uvre
crivain
#datePublication : Date
#dateNaissance : Date
Diagramme de classes 67
UML2 Livre Page 68 Vendredi, 14. d cembre 2007 7:24 07
4. La lecture du texte permet de slectionner les classes candidates suivantes : Facteur, Cour-
rier, 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 appa-
ratront 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 repr-
sent 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).
Courrier ZoneDAffectation
affecter
Colis Facteur
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 com-
pareTo(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
UML2 Livre Page 69 Vendredi, 14. d cembre 2007 7:24 07
Comparable. Cette interface sera ralise par les classes qui lutilisent. Pour lapplication
considre, vous obtenez le diagramme prsent la figure 2.50.
2
Chapitre
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 Ins-
cription qui contient deux oprations : inscrire() et rsilier(). Faites volontairement abstrac-
tion 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 dri-
ves 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.
Diagramme de classes 69
UML2 Livre Page 70 Vendredi, 14. d cembre 2007 7:24 07
EXERCICE 11 RELATIONS
Une commande est lie plusieurs produits. chaque produit de la commande sont asso-
cies 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.
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 Com-
mande 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
UML2 Livre Page 71 Vendredi, 14. d cembre 2007 7:24 07
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.
2
Chapitre
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 corres-
pondent exactement deux instances de la classe Date. Les couples (c2,p1) et (c2,p4) ne
vrifient pas cette contrainte.
EXERCICE 12 HRITAGE
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 modli-
sation 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.
Exercices
Diagramme de classes 71
UML2 Livre Page 72 Vendredi, 14. d cembre 2007 7:24 07
1. Vous avez besoin de trois classes : Chat, Chien et Animal. La classe Animal est plus gn-
rale (hritage) que les deux classes Chien et Chat. Une instance de la classe Chat (respec-
tivement 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.
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().
3. La valeur en dcibels de la puissance des cris est pareille pour chaque catgorie dani-
maux . 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 Animal {abstract}
use
Implmentation interface nom : String
de linterface Comparable abstract crier()
Comparable par float compareTo(type) realize
les classes drives
de la classe Animal. {incomplete,disjoint}
realize
Chat Chien
static float bitCri static float dbitCri
72 UML 2
UML2 Livre Page 73 Vendredi, 14. d cembre 2007 7:24 07
EXERCICE 13 HRITAGE
2
Chapitre
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.
Doctorant
Java naccepte que lhritage simple. Cette contrainte implique une modlisation hirar-
chique de lhritage. En dautres termes, une classe peut avoir au plus un seul parent.
Exercices
Diagramme de classes 73
UML2 Livre Page 74 Vendredi, 14. d cembre 2007 7:24 07
cela en sparant les instances des doctorants de celles des tudiants et des enseignants.
Vous obtenez le modle prsent la figure 2.60.
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.
74 UML 2
UML2 Livre Page 75 Vendredi, 14. d cembre 2007 7:24 07
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.
z1:Zone
m2:Mur
:Objet
Une figure gomtrique est compose de figures simples ou composes. Une figure com-
pose 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.
Exercices
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.
Diagramme de classes 75
UML2 Livre Page 76 Vendredi, 14. d cembre 2007 7:24 07
Figure 2.64
Figure{abstract}
Diagramme de Elment de
classes modlisant +dessiner()
les figures simples +translater()
et composes.
FigureSimple
+dessiner() FigureCompose
+translater() +dessiner()
+translater()
+operation()
Composite
+operation()
Appliquer lopration +ajout(c :Composant)
tous les descendants.
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 sui-
vantes : 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
UML2 Livre Page 77 Vendredi, 14. d cembre 2007 7:24 07
La figure 2.66 propose une solution qui rpond aux deux questions.
2
Chapitre
Figure 2.66
Htel Chambre
Diagramme de adresse : String 2..* Le loyer est calcul
nombreLit : int
classes reprsentant catgorie : String typeLit : String en fonction du nombre
lapplication lePrix : double de personnes, de la
htelire. calculChiffreAffaires() : double numro : int saison, etc.
douche Baignoire
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 tra-
vailler 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 nou-
veau 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
Exercices
Diagramme de classes 77
UML2 Livre Page 78 Vendredi, 14. d cembre 2007 7:24 07
1. Les classes qui apparaissent dans cette application sont Banque, Directeur, Agence,
Employ, Client, CompteRmunr, CompteNonRmunr.
Figure 2.67 Banque Directeur Employ Client
Description dtaille -nomDirecteur : String -nom : String -nom : String -nom : String
des classes de -capital : int -prenom : String -prenom : String -prenom : String
lapplication. -adresseSiege : String -revenu : float -dateEmbauche : Date -adresse : String
-conseiller : Employer
+getNomDirecteur() : String +getNom() : String +getNom: String -agence : Agence
+setNomDirecteur(String n) +setNom (String n) +setNom(String n) -comptes : [1..N] Compte
+getCapital():int +getPrenom ():String +getPrenom():String +getNom: String
+setCapital(int capital) +setPrenom(String p) +setPrenom(String s) +setNom(String n)
+getAdresseSiege():String +getRevenu():float +getDate(): Date +getPrenom():String
+setAdresseSiege(String s) +setRevenu(float s) +setDate(Date s) +setPrenom(String s)
Banque(String Adresse) mutation(Agence g): boolean +getDate(): Date
+setDate(Dates)
mutation(Agence g):boolean
CompteNonRmunr Agence CompteRmunr
-solde : float -nomAgence :String -solde : float
-numero : int -adresseAgence : String -numero : int
-taux : float
... +getNomAgence() : String
+setNomAgence(String n) ...
verserInteret() : void
2.
Figure 2.68
Personne
Les liens de Compte
gnralisation
entre les classes Directeur
de lapplication.
Employ
CompteRemunr CompteNonRemunr
Client
3.
Figure 2.69 1 1
Agence Employ
Associations
ternaires avec
classe-association.
1..*
Compte Client
78 UML 2
UML2 Livre Page 79 Vendredi, 14. d cembre 2007 7:24 07
Figure 2.70
4.
2
Chapitre
Personne
Diagramme
de classes de
lapplication 1 Directeur
bancaire.
1 1..*
1..* Employ
Banque Agence
1..* 1
1
Client
1..*
Compte
CompteRmunr CompteNonRmunr
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 plu-
sieurs 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 plu-
sieurs villes.
4. Proposez le diagramme de classes pour cette situation.
5. partir de ces diagrammes partiels, proposez un diagramme de classes modlisant cette
application.
Exercices
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 exclu-
sivement 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).
Diagramme de classes 79
UML2 Livre Page 80 Vendredi, 14. d cembre 2007 7:24 07
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 res-
treint limpact de lassociation sur les instances des classes (figure 2.71).
Figure 2.72 * assurer 1
Avion Vol
Gnralisation de
lassociation assure
par lajout de context Vol
contraintes OCL. inv: type=cargo implies Avion.type=cargo
inv: type=passager implies Avion.type=passager
AvionCargo VolCargo
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 synchronisa-
tion. 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 1..* propose 1..*
Vol CompagnieArienne
Modlisation
dtaille de #dateDpart:Date
la classe Vol. #dateArrive:Date
#lieuDpart:Lieu
Prconditions
#lieuArrive:Lieu
ouvrir(): instance de vol jamais ouverte
+ouvrirVol() former(): instance de vol ouverte par le
mme objet et jamais ferme.
+fermerVol()
80 UML 2
UML2 Livre Page 81 Vendredi, 14. d cembre 2007 7:24 07
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
2
Chapitre
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 dpart
Client Aroport
Modlisation des Vol * 1
vols des compagnies arrive
ariennes. Reservation * 1
{ordered}
* *
Passager
Escale
CompagnieArienne
dateDpart:Date
dateArrive:Date
Ville
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 spcia-
lise 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.
Diagramme de classes 81
UML2 Livre Page 82 Vendredi, 14. d cembre 2007 7:24 07
Labstraction est visible par les clients, renvoie les demandes vers limplmentation (ope-
ration=Implementation.operation) et fournit des fonctions de haut niveau. Les classes
RefinedAbstraction implmentent les diffrentes abstractions, la faon des classes Figu-
reGeometrique 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 Imple-
mentation en proposant des mthodes concrtes.
Figure 2.76
+Implementation.operations()
Diagramme de
classes du patron Client
de conception Abstraction Implementation
Bridge .
+operation() +operation()
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 poss-
dant 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 com-
mune tous les animaux qui lui permette den ajouter de nouveaux, sans modifier linter-
face 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 dopra-
tions. 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
UML2 Livre Page 83 Vendredi, 14. d cembre 2007 7:24 07
Figure 277
Animal{abstract}
Client
Gnralisation +crier():{abstract}
des proprits des +forme():{abstract}
animaux dans la
classe Animal, seule
interface avec le
client.
Chat Vache
+crier() +crier()
+forme() +forme()
Lajout dune classe danimaux quelconques doit se faire par drivation de la classe Ani-
mal. 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 polymor-
phisme, 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 dopra-
tions. 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
Chat LeChat
La classe LeChat La mthode crier() se
existante et la contentera dappeler la mthode +crier() +criChat()
criChat() de la classe LeChat +forme() 1 1 +formeChat()
nouvelle classe Chat.
Ce processus dencapsulation des classes de lancienne version est dcrit la figure 2.78.
Figure 2.79 Animal{abstract}
Client
Les classes Chat et +crier()
Vache encapsulent + forme()
respectivement les
classes LeChat et
LaVache. Chat Vache Lion
+crier() +crier() +crier()
+forme() +forme() +forme()
LeChat LaVache
+criChat() +criVache()
+formeChat() +formeVache()
Exercices
3. Ce mcanisme dadaptation par encapsulation peut tre utile dans le contexte dutilisa-
tion 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 .
Diagramme de classes 83
UML2 Livre Page 84 Vendredi, 14. d cembre 2007 7:24 07
Figure 2.80
Client ClasseCible Adaptateur ClasseAdapte
Vue simplifie +mthode() +mthode() +mthodeAdapte()
du patron
Adaptateur . +mthode(){
instanceClasseAdapte.mthodeAdapte() ;
}
Cette solution est extraite de la norme UML 2.0 superstructure spcification publie par
lOMG.
+datatype +ownedOperation
Operation
0..1 {subsets namespace, {ordered, *
subsets redefinitionContext, subsets feature,
subsets featuringClassifier} subsets ownedMember}
InstanceSpecification
+enumeration +ownedLiteral
PrimitiveType Enumeration EnumerationLiteral
0..1 {subset namespace} {ordered, *
subsets ownedMember}
84 UML 2
UML2 Livre Page 85 Vendredi, 14. d cembre 2007 7:24 07
Diagramme
3
Chapitre
dinteraction
1. Intrt des interactions ................... 86 Le diagramme de cas dutilisation montre des acteurs qui
2. Diagramme de squence interagissent avec les grandes fonctions dun systme.
en dtail ....................................... 91
3. Diagramme de communication Cest une vision fonctionnelle et externe dun systme.
en dtail ..................................... 101
4. Rutilisation dune interaction ...... 104 Le diagramme de classes, quant lui, dcrit le cur dun
Problmes et exercices systme et montre des classes et la faon dont elles sont
1. Syntaxe des messages.................. 107
associes. Cest une vision statique et structurelle.
2. Ajouter un aspect dynamique
un diagramme de classes Les diagrammes dinteraction permettent dtablir un pont
et traduction dun diagramme
de squence en diagramme entre ces deux approches : ils montrent comment des
de communication ....................... 109
3. Messages synchrones vs messages instances au cur du systme communiquent pour raliser
asynchrones ................................ 111 une certaine fonctionnalit. Les interactions sont nombreuses
4. Messages perdus, trouvs ou
envoys dans des flots dexcution et varies. Il faut un langage riche pour les exprimer.
parallles .................................... 114
5. Fragments dinteraction combins UML propose plusieurs diagrammes : diagramme de
pour dcrire une mthode
complexe .................................... 115
squence, diagramme de communication, diagramme de
6. Oprateurs dinteraction .............. 116 timing. Ils apportent un aspect dynamique la modlisation
7. Diagrammes de squence
pour illustrer des cas dutilisation .. 117 du systme.
8. Fragments dinteraction combins . 120
9. Diagrammes de squence
pour illustrer des collaborations .... 121
10. Rutilisation dune interaction ....... 124
11. Diagrammes de squence
pour illustrer les interactions
dans un classeur structur ............. 125
85
UML2 Livre Page 86 Vendredi, 14. d cembre 2007 7:24 07
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.
leMoteur : Moteur
Dfinition
Une interaction dcrit le comportement dun classeur en se focalisant sur lchange dinfor-
mations 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 (ins-
tances 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
UML2 Livre Page 87 Vendredi, 14. d cembre 2007 7:24 07
ligne de vie
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 dia-
gramme 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 con-
viennent 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
UML2 Livre Page 88 Vendredi, 14. d cembre 2007 7:24 07
introduireCarte
affichercranSaisieCode
saisieCode( code )
vrifierCode( code )
banqueOK = vrifierCode( _ )
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 dutilisa-
tion 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 tou-
tes les interactions sur un seul diagramme. Le modlisateur doit pouvoir focaliser son atten-
tion sur un sous-ensemble dlments du systme et tudier leur faon dinteragir pour
donner un comportement particulier au systme. UML permet de dcrire un comporte-
ment limit un contexte prcis de deux faons : dans le cadre dun classeur structur ou
dans celui dune collaboration.
88 UML 2
UML2 Livre Page 89 Vendredi, 14. d cembre 2007 7:24 07
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
3
Chapitre
structure interne
: Allumage : Bougies
de la classe 1..4
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.
Dfinition
Une collaboration montre des instances qui collaborent dans un contexte donn pour met-
tre en uvre une fonctionnalit dun systme.
EXEMPLE La figure 3.6 montre une collaboration entre instances pour raliser une transaction immo-
bilire.
Notation
Une collaboration se reprsente par une ellipse en trait pointill comprenant deux compar-
timents. Le compartiment suprieur contient le nom de la collaboration ayant pour syntaxe :
<nomDuRle>[: <NomDuType>][multiplicit]
Le compartiment infrieur montre les participants la collaboration.
Diagramme dinteraction 89
UML2 Livre Page 90 Vendredi, 14. d cembre 2007 7:24 07
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 collabora-
tion. 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
propritaire contratVente Transaction
Reprsentation Personne venteImmobilire
possible dune acqureur
collaboration.
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
sd venteImmobilire
Un diagramme
de squence notaire : Notaire contratVente : Transaction propritaire : Personne acqureur : Personne
pour illustrer
une collaboration. tablir
signer
signer
90 UML 2
UML2 Livre Page 91 Vendredi, 14. d cembre 2007 7:24 07
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 rcep-
teur 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 ordi-
nateur 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 asyn-
chrone. 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).
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.
Diagramme dinteraction 91
UML2 Livre Page 92 Vendredi, 14. d cembre 2007 7:24 07
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
: Client : Serveur
diffrent de lordre
denvoi.
question
question
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 lexcu-
tion dune mthode chez le rcepteur.
Figure 3.14
sd Retrait argent
Diagramme
de squence
o figurent,
pour explication, : Distributeur
les occurrences
dvnement.
vnement denvoi Client
vnement de
introduireCarte dbut dexcution
vnement de
vnement de fin
rception
dexcution
92 UML 2
UML2 Livre Page 93 Vendredi, 14. d cembre 2007 7:24 07
Notation
3
Chapitre
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
introduireCarte vnement de
dbut dexcution
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 rcep-
teur. 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.
Diagramme dinteraction 93
UML2 Livre Page 94 Vendredi, 14. d cembre 2007 7:24 07
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 argu-
ments 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 argu-
ments 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.
Notation
La syntaxe de rponse un message est la suivante :
[<attribut> =] message [: <valeur de retour> ]
o message reprsente le message denvoi.
EXEMPLE La figure 3.18 montre un message de rponse signalant que quarante-deux occurrences de la
rfrence Tintin figurent dans une mdiathque.
94 UML 2
UML2 Livre Page 95 Vendredi, 14. d cembre 2007 7:24 07
Figure 3.18
Exemple dun sd Rechercher livre
Contrainte sur les valeurs dun attribut
3
Chapitre
message de
rponse.
+nombreLivres : integer { nombreLivres >= 0 }
: Mdiathque
Client
chercher( "Tintin" )
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.
contrainte 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 lv-
nement sur lequel elle agit.
Diagramme dinteraction 95
UML2 Livre Page 96 Vendredi, 14. d cembre 2007 7:24 07
Remarque
Un diagramme dinteraction peut dcrire des messages non valides, cest--dire qui ne doi-
vent 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.
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 instruc-
tions 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 suffisam-
ment 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.
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
UML2 Livre Page 97 Vendredi, 14. d cembre 2007 7:24 07
Notation
3
Chapitre
Les oprandes dun oprateur dinteraction sont spars par une ligne pointille. Les condi-
tions 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 ferme-
ture 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 condi-
tion 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
sd Dmarrer train
Diagramme de
squence montrant
une boucle.
: 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 op-
rande 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.
Diagramme dinteraction 97
UML2 Livre Page 98 Vendredi, 14. d cembre 2007 7:24 07
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 lop-
rateur 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 b
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 : Moteur
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
UML2 Livre Page 99 Vendredi, 14. d cembre 2007 7:24 07
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.
3
Chapitre
EXEMPLE La figure 3.24 illustre un scnario de dcollage dun avion qui utilise loprateur strict sequen-
cing. 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 diagram-
mes rfrencs sous le label ref sen chargent.
ref
Procdure de dcollage
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 : Syst-
meContrleAccsUtilisateur (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.
Diagramme dinteraction 99
UML2 Livre Page 100 Vendredi, 14. d cembre 2007 7:24 07
Dfinition
Une porte est un point de connexion qui permet de relier un mme message reprsent par
des flches diffrentes dans plusieurs fragments dinteraction.
: SystmeContrleAccs
: Utilisateur ref SystmeContrleAccsUtilisateur
vrifier( code )
ref
VrifierAccs( code )
ref
OuvrirPorte
Figure 3.26
sd SystmeContrleAccsUtilisateur
Ligne de vie
dcompose. +PointDAccs.code : integer { 1000 <= code <= 9999 }
: PointDAccs : Contrleur
Autre notation p1 P2
pour la dcomposition
vrifier( code )
ref
SystmeVrifierAccs( code )
portes
opt
[ code ok ]
opt
SystmeOuvrirPorte
100 UML 2
UML2 Livre Page 101 Vendredi, 14. d cembre 2007 7:24 07
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 linter-
action, ltat est test conformment la machine tats spcifie.
AvionPrtAuDcollage
dcoller()
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 fermerPortes()
des portes dun : Train
train.
1 : fermerLesPortes() connecteur
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).
102 UML 2
UML2 Livre Page 103 Vendredi, 14. d cembre 2007 7:24 07
Les connecteurs peuvent montrer la multiplicit des lignes de vie qui participent une
interaction, comme le montre la figure 3.29.
3
Chapitre
Figure 3.29
com Dmarrer train
Reprsentation de
la multiplicit dans
un diagramme de fermerPortes()
communication. : Train
multiplicit
fermerPorte()
*
porte : Porte
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 simultan-
ment dans plusieurs flots). Les flots parallles sont dsigns par des lettres (a, b).
EXEMPLE 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.
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.
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 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 linterac-
tion 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
104 UML 2
UML2 Livre Page 105 Vendredi, 14. d cembre 2007 7:24 07
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 dia-
gramme) reoit en argument une instance de CheckList. Cet argument est en entre/sor tie
3
Chapitre
(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. Lins-
tance correspondante est la ligne de vie appele planDeVol dans le diagramme.
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 linter-
action 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 por-
tent 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 sys-
tme. 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 sys-
tme donne par les diagrammes dinteraction est donc partielle (car limite un contexte
donn) mais cohrente (car elle montre comment un comportement dun systme est ra-
lis 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 dia-
grammes dactivits sont des organigrammes. Ils montrent les flots de contrle qui grent
les activits dun systme. Ils permettent de modliser tout processus squentiel (un proces-
sus de fabrication industriel, le fonctionnement dun systme dinformation, le corps dune
opration).
106 UML 2
UML2 Livre Page 107 Vendredi, 14. d cembre 2007 7:24 07
Problmes
3
Chapitre
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.
*
y = f
y = f( 0 )
y = f( x = 0 )
y = f( x ): 0
108 UML 2
UML2 Livre Page 109 Vendredi, 14. d cembre 2007 7:24 07
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 BrasArticul Pince
de classes Robot
dun robot.
chercherPice dplier ouvrir
replier 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.
chercherPice
dplier
fermer
porte
replier
ouvrir
Exercices
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 1 : chercherPice() 1.1 : dplier
quivalent au : Robot : BrasArticul
diagramme de 1.2 : replier
squence de la 1.1.1 : fermer
figure 3.33.
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; /* objet brasArticul (instance
de la classe BrasArticul) */
publique:
void chercherPice(){
brasArticul.dplier(); /* appel de la mthode dplier
de lobjet brasArticul */
brasArticul.replier(); /* appel de la mthode replier
de lobjet brasArticul */
}
}
class BrasArticul {
prive:
Pince pince; /* objet pince (instance de
la classe Pince) */
publique:
void dplier (){
/* instructions pour dplier
le bras */
pince.fermer(); /* fermeture de la pince pour
attraper la pice */
}
void replier (){
/* instructions pour replier
le bras */
pince.ouvrir(); /* ouverture de la pince pour
relcher la pice */
}
}
class Pince {
prive:
publique:
void fermer (){
/* instructions pour fermer
la pince */
}
110 UML 2
UML2 Livre Page 111 Vendredi, 14. d cembre 2007 7:24 07
}
/* instructions pour ouvrir la pince */
3
Chapitre
}
Dbut programme principal
Robot robot; /* cration dun objet robot
(instance de la classe Robot) */
robot.chercherPice(); /* 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 pro-
grammation ne permettent pas de faire la distinction.
Lannexe E donne des indications pour implmenter un modle objet avec le langage de
programmation Java.
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 : ProgrammePrincipal : FonctionDeCalculDePi
3 dcimales.
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 : ProgrammePrincipal : FonctionDeCalculDePi
un message
synchrone. calculerPI( nombreDcimales = 3 )
112 UML 2
UML2 Livre Page 113 Vendredi, 14. d cembre 2007 7:24 07
Remarque
3
Chapitre
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 dia-
gramme 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 appli-
quer une mthode.
2. Calculer Pi avec 3 000 dcimales peut prendre du temps. Dans ce cas, il vaut mieux utili-
ser un message asynchrone pour ne pas bloquer le programme principal le temps deffec-
tuer le calcul (figure 3.41).
Figure 3.41
: ProgrammePrincipal : FonctionDeCalculDePi
Calcul de Pi avec
3 000 dcimales
calculerPI( nombreDcimales = 3000 )
utilisant un message
asynchrone.
PI = calculerPI( nombreDcimales = 3000 )
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 : Destinataire
Transmission
asynchrone
transmettre( message )
dun courrier
lectronique.
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
: metteur : ServeurDeMessagerie : Destinataire
Transmission
synchrone dun
courrier lectronique poster( message )
via un serveur de
messagerie.
message = rcuprer
Exercices
5. Les transmissions sont asynchrones et les messages peuvent tre reus dans un ordre
diffrent de lordre denvoi (figure 3.44).
Remarque
La dure de transmission dun message peut tre indique en ajoutant des contraintes sur
un diagramme, comme le montre la figure 3.45.
transmettre( message )
d
d transmettre( message )
{ d - d < 1 jour }
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 : SystmeDExploitation
dexcution de excuter( programme = "lecteur CD" )
programmes.
excuter( programme = "diteur de texte" )
: Processeur
114 UML 2
UML2 Livre Page 115 Vendredi, 14. d cembre 2007 7:24 07
1. Si le systme dexploitation est considr comme multitche, lexcution des deux pro-
grammes se fait simultanment, dans deux flots dexcution parallles nots a et b.
3
Chapitre
: Processeur
o n 0 et factoriel( 0 ) = 1.
Reprsentez le programme prcdent sur un diagramme de squence.
Exercices
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.
Figure 3.50
sd calcul dun factoriel
Reprsentation du
calcul de la fonction +n : integer { n >= 0} +f : integer
factorielle sur un
diagramme de
:X
squence.
factoriel( n)
alt [ n == 0 ]
factoriel( n)
[ else ]
factoriel( n-1 )
appel rcursif
f = factoriel( n-1 )
factoriel( n ) : n * f
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 dinter-
action qui montre que les capteurs fonctionnent en mme temps (ils peuvent envoyer
tout moment des messages au robot).
viterObstacle()
116 UML 2
UML2 Livre Page 117 Vendredi, 14. d cembre 2007 7:24 07
Remarque
3
Chapitre
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 souhai-
table 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 plu-
sieurs oprandes (cest lordre des oprandes qui fixe le squencement). Lentrelacement
nest possible que sur des lignes de vie diffrentes non soumises loprateur seq.
par
analyserImage( image )
viterObstacle()
critical
arrterDUrgence() arrter ()
Bibliothcaire
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
sd gestion des emprunts
Description dun
scnario nominal
laide dun
diagramme de : Bibliothque
squence.
Bibliothcaire
rechercher un adhrent
adhrent trouv
uvre trouve
Il y a un exemplaire disponible
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
UML2 Livre Page 119 Vendredi, 14. d cembre 2007 7:24 07
terminer par les deux messages dcrmenter le nombre dexemplaires dans la biblio-
thque et attribuer lexemplaire ladhrent cause de lutilisation de loprateur
assert.
{ adhrent trouv }
{ uvre trouve }
{ exemplaire disponible }
assert
dcrmenter le nombre
dexemplaires dans la bibliothque
Le formalisme des diagrammes de squence est trs riche. Souvent, il est possible de repr-
senter des scnarios de plusieurs faons. Au lieu dutiliser des oprateurs dassertion, il est
possible de recourir des oprateurs dalternative.
Exercices
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
sd gestion des emprunts
Utilisation des
oprateurs opt
et neg.
: Bibliothque
Bibliothcaire
rechercher ladhrent
opt
[ adhrent non trouv ]
neg
vrifier si ladhrent peut emprunter
La figure 3.56 utilise loprateur negative pour indiquer que les messages sur lesquels il
sapplique sont invalides.
La solution utilise loprateur negative pour interdire louverture des portes (figure 3.57).
120 UML 2
UML2 Livre Page 121 Vendredi, 14. d cembre 2007 7:24 07
Figure 3.57
Utilisation de
sd Conduire Train
3
Chapitre
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 biblio-
thque. 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 ladh-
rent grce linvocation de lopration attribuer.
Figure 3.58
Diagramme de Prt
classes dune
mdiathque. date
Exemplaire uvre
Adhrent
0..3 1..n
emprunte extraireExemplaire() : Exemplaire
attribuer( Exemplaire )
emprunter( Adhrent )
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.
Exercices
Figure 3.59
Diagramme de
sd gestion des emprunts
squence de
lemprunt dun
livre.
: Bibliothque
Bibliothcaire
rechercher un adhrent
adhrent trouv
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.
122 UML 2
UML2 Livre Page 123 Vendredi, 14. d cembre 2007 7:24 07
Figure 3.60
Diagramme de
Argument
dune opration Attribution dun exemplaire un adhrent
3
Chapitre
collaboration pour
lemprunt dun
exemplaire. uvreTrouve : uvre
: 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 ins-
tance 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 +uvre.nombreExemplaires : integer { nombreExemplaires >= 0}
lemprunt dun
exemplaire.
uvreTrouve: uvre exemplaireTrouv : Exemplaire adhrentTrouv : Adhrent
emprunter( adhrentTrouv )
extraireExemplaire() : Exemplaire
: Prt
attribuer( exemplaireTrouv )
emprunter : ok
[ else ]
emprunter : non ok
Remarque
Le formalisme des diagrammes de squence est trs proche de celui des langages de pro-
grammation (on peut reprsenter aisment des tests, des boucles). Les diagrammes de
Exercices
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).
Figure 3.62
com emprunter
Reprsentation de la
cration dun objet emprunter()
et dun lien dans { nouveau }
: uvre : Prt
un diagramme de
communication.
adhrent trouv
uvre trouve
ref
AttributionExemplaireAAdhrent( adhrentTrouv, uvreTrouve )
124 UML 2
UML2 Livre Page 125 Vendredi, 14. d cembre 2007 7:24 07
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 com-
portement 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 File
un classeur
structur.
ref
Extraire de la file
: Tableau
lment dun
tableau.
mmoriser
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 sd extraire de la file premier : Exemplaire
Un diagramme
de squence pour suivant : Exemplaire
illustrer lextraction
: File : Tableau
du premier lment
dune file.
extraire()
get( 0 )
premier = get( 0 )
loop(1, n)
prcdent = get( 0 )
add(prcdent, i )
extraire() : premier
126 UML 2
UML2 Livre Page 127 Vendredi, 14. d cembre 2007 7:24 07
Diagramme
4
Chapitre
dtats-transitions
127
UML2 Livre Page 128 Vendredi, 14. d cembre 2007 7:24 07
EXEMPLE La lampe
Cet exemple simple prsente la notion dtat et leffet des invocations en fonction de ltat
courant.
Figure 4.1
Un diagramme allume On
dtats-transitions
simple.
Off 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 compo-
sites , 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.
128 UML 2
UML2 Livre Page 129 Vendredi, 14. d cembre 2007 7:24 07
Figure 4.2
Le comportement
cre
ouverte
4
Chapitre
dune fentre
dapplication. Init 1 maximiser()
normale agrandie
Init 2 maximiser()
positionner() dimensionner()
H
minimiser() minimiser()
Final 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 vne-
ments, 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 implici-
tement 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 automati-
ques , qui ne portent pas de dclencheur explicite.
Notation et spcification
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 )
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.
Figure 4.3
signal
Dclarations de Interruption E/S
signaux et hritage.
+pripherique :int
signal signal
Souris Clavier
+posx:int
+caractre: int
+posy:int
130 UML 2
UML2 Livre Page 131 Vendredi, 14. d cembre 2007 7:24 07
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 cer-
taines 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 expres-
sion 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 transi-
tion, 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 ). Lvne-
ment 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 lvne-
ment, il est dtruit. Si une transition est dclenche, sa garde est value ; celle-ci est expri-
me 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.
[b=0]
tat4
e2[a>0]
tat2 tat5
[b<0]
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.
afficher
problmes
132 UML 2
UML2 Livre Page 133 Vendredi, 14. d cembre 2007 7:24 07
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 recom-
4
Chapitre
mande 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 condition-
nelle, il est conseill dutiliser galement un point de jonction pour faire apparatre la fin du
branchement et tre homogne.
Figure 4.7
associer client et commande
Deux points de
/afficher
jonction pour [client trouv] numero client
reprsenter des chercher client associer client
alternatives.
crer client
[client non trouv]
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/.
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 lv-
nement 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 dclen-
cheur 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 collabora-
tion) 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-transi-
tions 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.
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 sous-
tats 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.
134 UML 2
UML2 Livre Page 135 Vendredi, 14. d cembre 2007 7:24 07
Figure 4.9
Composition
Dbut
Composer numro
4
Chapitre
chiffrer(n)
Un nouvel objet est cr dans ltat initial le plus externe du diagramme et franchit la tran-
sition 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 correspon-
dant 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.
Figure 4.10
Composer
Reprsentation compacte numro
dun tat composite.
Les transitions peuvent avoir pour cible la frontire dun tat composite et sont alors qui-
valentes 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 transi-
tion 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 fran-
chissable 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.
entry/EntrerE21
exit/QuitterE1
entry/EntrerE2
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*, permet-
trait 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
UML2 Livre Page 137 Vendredi, 14. d cembre 2007 7:24 07
Figure 4.12
Historique et
Traitement
H*
reprendre Traite
4
Chapitre
Traitement 1 Traitement 2
E11 E21
interrompre
E12 E22
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 dia-
grammes plus lisibles.
Figure 4.13
distribuer boisson
Points de connexion
pour la composition
de diagrammes.
Crdit insuffisant
[crdit < prix]
vrifier crdit
Test oprateur
prparer
boisson
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 concep-
tion, ce qui est essentiel pour traiter des modles de grande taille.
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
UML2 Livre Page 139 Vendredi, 14. d cembre 2007 7:24 07
Les protocoles servent expliquer la faon correcte de se servir dune classe ou dun compo-
sant, sans spcifier les traitements qui ralisent laction. Plusieurs implmentations diff-
rentes dune classe peuvent respecter un protocole donn.
4
Chapitre
Figure 4.14
stm {protocol}
Diagramme de fichier
protocole dune write/
classe fichier.
close/
open/
delete/
read/
Figure 4.15
boisson slectionne
Rgions concurrentes
au sein dun tat.
prparer boisson terminer prparation
rendre monnaie
gobelet retir/
Une transition ayant pour destination un tat cible muni de rgions concurrentes est qui-
valente 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
UML2 Livre Page 141 Vendredi, 14. d cembre 2007 7:24 07
Conclusion
4
Chapitre
Problmes
et exercices
Les exercices suivants utilisent les principaux concepts des diagrammes
dtats-transitions.
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.
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 reprsen-
tes : 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
UML2 Livre Page 143 Vendredi, 14. d cembre 2007 7:24 07
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 annota-
tions exprimant des contraintes pour lier ce diagramme lutilisation de la serrure.
1.La serrure rpond aux vnements verrouiller et dverrouiller. Vous pouvez dans un pre-
mier 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 lindica-
tion stm (State Machine), pour spcifier le type et le nom du diagramme.
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.
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.
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 digi-
code 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 ver-
rouiller 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
UML2 Livre Page 145 Vendredi, 14. d cembre 2007 7:24 07
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 te-
ment 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/abonne-
ment) : 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
Design pattern observateurs
Observer. +attacher(Observateur) update()
+dtacher(Observateur)
+notify()
pour chaque o de observateurs {
o.update();
}
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
Exercices
secondes.
Le bouton mode active successivement trois modes principaux de la montre : laffi-
chage de lheure courante, le mode chronomtre et le mode rglage (pour mettre
jour lheure courante).
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 Observateur
Diagramme de
classes simplifi
dune montre.
sujet.dtacher(self);
Timer sujet Afficheur t.attacher(self);
sujet = t;
start() afficher(t: Timer)
stop()
chrono time afficheur
Montre
146 UML 2
UML2 Livre Page 147 Vendredi, 14. d cembre 2007 7:24 07
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.
4
Chapitre
Figure 4.24
Les principaux mode/ mode/
modes daffichage mode chrono
et la lumire. affichage heure
entry/ mode rglage
afficheur.afficher(time)
mode/
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 spar-
ment. 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 fonc-
tionnement 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
Exercices
rgion touchent la frontire de ltat et sont donc franchissables depuis les deux tats
stopp et lanc.
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 inter-
rompues par une transition qui le quitte. Les mthodes increment et reset incrmentent
ou remettent zro le champ mentionn.
do/afficheur.clignoter(heure) do/afficheur.clignoter(seconde)
s-s/
entry/afficheur.affiche(time)
148 UML 2
UML2 Livre Page 149 Vendredi, 14. d cembre 2007 7:24 07
Les sockets sont des points extrmes de communication bidirectionnels : cest une interface
standardise, implmente sur quasiment toutes les plates-formes de faon homogne,
4
Chapitre
CLOSED CLOSED
accept()
connect() SYN J LISTEN
SYN_RCVD
ACK K+1
ESTABLISHED
ESTABLISHED
Une fois la connexion tablie, le protocole devient symtrique : les deux participants peu-
vent lire et envoyer des messages. Vous ne modliserez pas cette partie du protocole relati-
vement complexe, qui assure la transmission sans pertes, duplications ou dsquencement
Exercices
Figure 4.28
Fermeture de sd Fermeture de connexion TCP
On note client et
connexion TCP. serveur, mais cette
client:Socket partie du protocole server:Socket
est totalement
symtrique
close() ESTABLISHED ESTABLISHED
FIN_WAIT_1 FIN M
FIN_WAIT_2 close()
FIN N LAST_ACK
TIME_WAIT
ACK N+1
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 sup-
pose 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 (ESTA-
BLISHED), et la fermeture active et passive de la connexion. Certains de ces tats
peuvent tre affins en sous-tats.
150 UML 2
UML2 Livre Page 151 Vendredi, 14. d cembre 2007 7:24 07
4
Chapitre
ESTABLISHED ESTABLISHED
close() close()
FIN J 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
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
ESTABLISHED
152 UML 2
UML2 Livre Page 153 Vendredi, 14. d cembre 2007 7:24 07
Figure 4.31
Ct serveur,
attente dun client
4
Chapitre
Figure 4.32
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
Figure 4.36
fermeture active
Introduction
de la fermeture
simultane ou /FIN FIN/ACK
double fermeture FIN_WAIT_1 CLOSING
active.
ACK/ ACK/
after (2MSL)
FIN/ACK
FIN_WAIT_2 TIME_WAIT
154 UML 2
UML2 Livre Page 155 Vendredi, 14. d cembre 2007 7:24 07
Diagramme
5
Chapitre
dactivits
Problmes et exercices
objet : spcification des actions de base (dclaration
1. Programmation en activits...... 177 de variables, affectation), structures de contrle
2. Vente en ligne ........................ 178
(conditionnelles, boucles), ainsi que les instructions
3. Algorithmique ........................ 179
4. Vidoclub .............................. 182 particulires la programmation oriente objet (appels
5. Cache doprations................. 183
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
UML2 Livre Page 156 Vendredi, 14. d cembre 2007 7:24 07
(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 pro-
grammation tels que Java, C++.
Pour cela, UML doit tre dot de mcanismes offrant la prcision dun langage de program-
mation 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.
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 utili-
ser 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 program-
mation.
EXEMPLE 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.
156 UML 2
UML2 Livre Page 157 Vendredi, 14. d cembre 2007 7:24 07
Appel asynchrone
Les appels asynchrones de type send correspondent des envois de messages asynchrones :
5
Chapitre
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 communica-
tion 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 pour-
suit 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 com-
munication : 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 Appui bouton lumire action accept event
communication.
clairer Affichage
action send signal
attendre 2 secondes
action accept time event
teindre Affichage
action send signal
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.
158 UML 2
UML2 Livre Page 159 Vendredi, 14. d cembre 2007 7:24 07
EXEMPLE Ces mcanismes de typage sont frquemment utiliss dans limplmentation doprateurs de
comparaison dfinis au niveau dune classe de base.
5
Chapitre
#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;
}
}
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.
EXEMPLE Smalltalk et Python sont deux exemples de langages objet qui permettent ce niveau de rflec-
tivit 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 dcla-
ration dune classe.
UML dfinit des actions qui couvrent les instructions lmentaires dun langage de pro-
grammation, mais ne propose pas de mcanismes pour exprimer des boucles, des condi-
tionnelles, 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 pro-
grammation 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 compor-
tements 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
UML2 Livre Page 161 Vendredi, 14. d cembre 2007 7:24 07
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 com-
posant 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, usuelle-
ment 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.
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.
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 calcu-
ler 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 com-
mande), de lannuler (passage dans ltat final, signifiant la fin de ce traitement), ou de vali-
der le devis.
Sil valide, deux actions peuvent tre engages en parallle : la prparation de la com-
mande 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 rendez-
vous 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 orien-
ts 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
UML2 Livre Page 163 Vendredi, 14. d cembre 2007 7:24 07
Figure 5.2
La commande.
Client Service comptable Service livraison
5
Chapitre
tat Initial
Lignes deau
Passer Commande tablir Devis
Vrifier disponibilit
Sous-activit
Calculer Prix
[modifier]
Activit composite
Transition
Devis
Garde
Activit
Valider Fork
[valider]
[annuler]
Rgler facture
Join
Invariant dtat
Livrer Commande
Clturer Dossier
tat final
Activit
164 UML 2
UML2 Livre Page 165 Vendredi, 14. d cembre 2007 7:24 07
Figure 5.4
Le distributeur
external
Client
5
Chapitre
automatique
de banque.
[chec]
Insrer Carte Vrification prliminaire
[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 .
inWord=true;
[inWord==false] 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
total=0; | | | |
if(c== || c== \t || c== \n )
| |
Ce type dactivit est fourni par commodit, mais son utilisation rend peu visible le chemi-
nement du flot de contrle.
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 activi-
ts 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
UML2 Livre Page 167 Vendredi, 14. d cembre 2007 7:24 07
ligne deau. Une description plus dtaille ncessiterait sans doute de dcomposer plus fine-
ment les actions, en vue de reprsenter plus explicitement les appels dopration sur les
composants du systme (lecteur de cartes, serveur dauthentification, imprimante pour le
5
Chapitre
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 parti-
culiers 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.
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.
Paris
"attribute" siteExploitation : Localisation
Facture
tablir Facture
[mise]
Rgler Facture
Facture
Valider Paiement Prparer Commande
[rgle]
Roubaix
Clturer Dossier Livrer Commande
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 informa-
tion prvaut sur lappartenance ventuelle une partition graphiquement reprsente.
168 UML 2
UML2 Livre Page 169 Vendredi, 14. d cembre 2007 7:24 07
Pin
Pour spcifier les valeurs passes en argument une activit et les valeurs de retour, on uti-
5
Chapitre
lise 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.
Figure 5.10
a:int
Reprsentation res = a * b ; res:int
de pins. 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 pou-
vez 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.
Figure 5.11
Pin dexception. (java.util.Vector) IndexOutOfBoundsException
index:int
elementAt
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.
conteneur typ qui permet le transit des donnes. Il sert galement de stockage : il peut con-
tenir 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 mention-
nant 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 spci-
fi est alors commun tout arc ayant pour source ce nud.
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.
stderr
{stream} deux notations
quivalentes de stream
170 UML 2
UML2 Livre Page 171 Vendredi, 14. d cembre 2007 7:24 07
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 dex-
cution 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 syn-
chronisation. 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 plu-
sieurs 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 franchis-
sement 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.
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 dimplmen-
tation : un seul oprateur physique peut raliser lensemble des activits (de faon squentielle)
sans dvier de la smantique du modle.
Figure 5.15
Fournir Pice Monter Pice Emballer
Mcanismes [montage fini]
exprimant la
concurrence. [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 permet-
tent 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 signa-
ler 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.
172 UML 2
UML2 Livre Page 173 Vendredi, 14. d cembre 2007 7:24 07
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 pro-
duit 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 gestionnai-
res 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.
calculer produit
rendre la constante
vecteur2
ExceptionDbordement res : vecteur
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.
Exception
IOException
message : String
+getMessage ()
InterruptedIOException EOFException
bytesTransferred : int
EXEMPLE 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).
174 UML 2
UML2 Livre Page 175 Vendredi, 14. d cembre 2007 7:24 07
Figure 5.18
Rgion interruptible.
activity grer commande
5
Chapitre
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, gra-
phiquement 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 gale-
ment 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 ind-
pendantes 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 squentiel-
lement, 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.
: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 excep-
tions ou le passage des paramtres.
La description graphique des traitements permet de mieux cerner le cheminement des alter-
natives. 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 dutili-
sation, 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 modli-
ser 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, suffi-
samment 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
UML2 Livre Page 177 Vendredi, 14. d cembre 2007 7:24 07
Problmes
5
Chapitre
et exercices
Les exercices suivants couvrent les principaux concepts des diagrammes dactivits.
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]
h e l l o ! \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.
[\0]
int len
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
remplir panier confirmer des achats
Une interface web
pour lauthentification.
loger utilisateur
[else]
[compte invalide]
[oui]
saisie login,
compte existant?
mot de passe
[non]
[adresse connue]
crer le compte
saisie email
[adresse diffrente]
modifier
adresse de livraison
178 UML 2
UML2 Livre Page 179 Vendredi, 14. d cembre 2007 7:24 07
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.
5
Chapitre
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 luti-
lisateur 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.
EXERCICE 3 ALGORITHMIQUE
Les diagrammes dactivits permettent de raisonner sur des algorithmes, au cours de lacti-
vit 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. Lalgo-
rithme 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,
Exercices
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
T
change de valeurs swap
de deux variables. a : int
tmp:T
tmp = T[a]
tab : T[]
n : int
180 UML 2
UML2 Livre Page 181 Vendredi, 14. d cembre 2007 7:24 07
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.
5
Chapitre
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.
[j>0 et t[j-1]>tmp]
[else] j=i tab[j] = tab[j-1]
[else]
tab[j] = tmp
n : int
Figure 5.25 cas terminal pour la rcursion : un tableau trouver le milieu m de lintervalle tri rcursif des deux moitis
un seul lment est dj tri. trier
Tri par fusion. Comparable T
Tri fusion
m : int
m = (g+d)/2 s : int [d-g+1]
Attention, i dcroit :
[d <= g] tri fusion (t,g,m) tri fusion (t,m+1,d) deuxime moiti copie
en ordre inverse !
i : int i : int
j : int i++ j : int i--
j++ j++
i : int
j : int i++
k : int
t[i]=s[k] t[i]=s[j]
i=g
k-- j++
j=0
k=d-g
[else] [else]
[i<=d] [ s[j] <= s[k] ]
EXERCICE 4 VIDOCLUB
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
UML2 Livre Page 183 Vendredi, 14. d cembre 2007 7:24 07
Figure 5.26
Le cas dutilisation
(client)
introduire carte
Exception E3
avaler carte
5
Chapitre
Emprunter vido .
Exception E1
15 secondes (client)
valider carte [carte invalide] prendre carte
[else] Alternatif A1
valider crdit [else]
suprieur ou gal proposer rechargement
un euro
[crdit suffisant]
jecter carte
Exception E4
rechercher video [annulation]
dlivrer cassette
15 secondes
avaler cassette
annuler opration (client)
prendre cassette
Exception E2
afficher temps
et prix de location
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.
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 thorique-
ment 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 postcondition
si la cl key nest pas dans la table rends la rfrence nulle.
proposes pour Map
sinon rends la valeur associe la cl key
implmenter Object get (Object key)
un cache. Object put (Object key, Object value)
postcondition
la valeur value t associe la cl key dans la table.
{abstract} Fonction2
Cache
-map : Map #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 fonction-
nalit 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 TypeExcep-
tion. Enrichissez le diagramme prcdent pour reprsenter ce mcanisme.
184 UML 2
UML2 Livre Page 185 Vendredi, 14. d cembre 2007 7:24 07
Figure 5.28
Comportement arg : Object
(Cache)
compute
5
Chapitre
associ lopration
compute du cache. [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.
[else]
res = map.get (arg) res = doComputation (arg)
[res != null]
map.put(arg,res)
res: Object
Exercices
UML en pratique
6
Chapitre
187
UML2 Livre Page 188 Vendredi, 14. d cembre 2007 7:24 07
188 UML 2
UML2 Livre Page 189 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.1
UML couvre la plupart des tapes du cycle de vie dun projet (figure 6.1).
6
Chapitre
planification
La place dUML
analyse
dans le cycle de UML
dveloppement conception
dun systme.
implmentation
tests
UML
dploiement
maintenance
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 ren-
dre 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.
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.
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 mcanis-
mes 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.
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
UML2 Livre Page 191 Vendredi, 14. d cembre 2007 7:24 07
Remarque
6
Chapitre
Modle des tats du domaine. Un diagramme de classes nest quun modle et, dans un logi-
ciel 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 des-
cendre 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 mtho-
des. 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 fonc-
tionnalits 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 utili-
sent ses classes.
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 inter-
agissent directement avec les instances des classes du domaine. La logique interne de lappli-
cation 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 extrmi-
ts 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 ser-
vices. 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
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
UML2 Livre Page 193 Vendredi, 14. d cembre 2007 7:24 07
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 prsen-
tation de linterface utilisateur mais uniquement aux flots de donnes et de contrle trans-
6
Chapitre
mis 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 plu-
sieurs 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 invo-
quant des oprations sur dautres objets. Chaque contrleur a pour tche de traiter un com-
portement 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.
Modle des tats de lapplication. Tout comme les classes du domaine, les classes de lappli-
cation 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 lappli-
cation, 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 dutili-
sation, 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.
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 descrip-
tions par les diagrammes de squence et/ou dactivit produits.
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 dana-
lyse, 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 res-
sources 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 programma-
tion par exemple, fonctionnent selon un mode vnementiel, dautres sur un mode proc-
dural, 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
UML2 Livre Page 195 Vendredi, 14. d cembre 2007 7:24 07
possible de dcrire les parties dun logiciel qui sexcutent sur des matriels laide des
diagrammes de dploiement (voir lannexe D).
6
Chapitre
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 pro-
cde par tapes. Tout dabord, le systme (dans notre cas, un systme logiciel) est dcom-
pos en sous-systmes. La partition du systme doit permettre de regrouper dans un sous-
systme 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 sous-
systmes. 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, procdu-
rale, 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.
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.
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 pis-
tolet 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.
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
UML2 Livre Page 197 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.3
Contexte technique
Pupitre pompiste
Banque
6
Chapitre
du logiciel (ce
diagramme nest
pas un diagramme
UML). Systme de paiement
Cuves carburant Unit centrale
par carte bancaire
Pompe 1 Pompe n
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 cepen-
dant 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 informa-
tique 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
clavier cran
des priphriques
clavier du cran du pompiste
du systme.
pompiste
unit centrale
Priphrique Priphrique de
de gestion des paiement par carte
Systme informatique de la station-service
cuves bancaire
Priphrique
disque
de gestion des
Base de donnes
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 respec-
tivement les tats des gchettes (appuyes ou relches) et des pistolets ; le troisime fournit
une interface (InterfacePompe) permettant darmer et dactiver la pompe.
unit centrale
Systme informatique de la station-service
InterfaceCapteurGchette InterfaceCapteurPistolet
InterfacePompe
198 UML 2
UML2 Livre Page 199 Vendredi, 14. d cembre 2007 7:24 07
1. Avant de dresser une liste de classes, commenons par dlimiter le domaine de lapplica-
tion. 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 dpen-
dre le moins possible des applications qui vont sappuyer sur lui. Plus le nombre dappli-
cations 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 pom-
page ;
capteurs de prsence des pistolets dans les tuis de rangement.
Le domaine ainsi dlimit, nous pouvons en commencer lanalyse. Ltude de la descrip-
tion 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 dis-
positif 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 rali-
ser 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.
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 car-
burant, 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 lappli-
cation. Rsumons cette notion par le mot-cl TransactionClient. Le dernier substantif que
nous navons pas encore abord est archive. Les transactions doivent tre archives quo-
tidiennement. Pour quil ny ait pas dambigut, renommons lensemble des transactions
quotidiennes TransactionsDuJour.
La liste des classes candidates est prsent la suivante : Pistolet, Gchette, DispositifDe-
Pompage, EnsemblePompe, Etui, Carburant, Cuve, PriseDeCarburant, TransactionClient,
TransactionsDuJour.
Afin de dfinir clairement chaque terme, un dictionnaire a t rdig. Voici un extrait :
Remarque
Tous les termes lis au domaine ou lapplication doivent tre consigns dans des diction-
naires, 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 lacti-
vation du dispositif de pompage. Do lassociation entre les classes Gchette et Dispositif-
DePompage. 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
UML2 Livre Page 201 Vendredi, 14. d cembre 2007 7:24 07
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
6
Chapitre
Figure 6.6
EnsemblePompe
Premire version
du diagramme de Pompe
classes du domaine. 1..* carburant
contrle dans
activation Cuve
Pistolet Gchette DispositifDePompage
1..*
contient
0..1
Etui dbite
PriseDeCarburant Carburant
1..*
TransactionsDuJour TransactionClient
0..*
Figure 6.7
EnsemblePompe
Version du
numroPompe : entier
diagramme de
classes du domaine
incluant les attributs.
1..* Pompe carburant dans
contrle
Pistolet Gchette activation DispositifDePompage Cuve
1..*
dbite
Carburant
PriseDeCarburant
1..* prix : rel
quantitCarburant : rel typeCarburant : TypeCarburant
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.
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 ban-
caire 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 Transac-
tionClient en une classe de base dont hritent trois classes (figure 6.9) : TransactionEn-
Espces, TransactionBancaire et TransactionParChque. La classe TransactionClient est
abstraite car elle possde lopration abstraite payer. Celle-ci sera implmente dans les
202 UML 2
UML2 Livre Page 203 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.9
TransactionClient {abstract}
Un hritage
pour modliser date : Date
les transactions. montant : rel
payer {abstract}
Diagramme de activation
Cuve
Pistolet Gchette DispositifDePompage 1..*
classes du domaine.
dansEtui : boolen appuye : boolen arm : boolen niveau : entier
actif : boolen
contient
1..*
EnsemblePompe Service
numroPompe : entier
dbite
PriseDeCarburant
Carburant
quantitCarburant : rel prix : rel
typeCarburant : TypeCarburant
{ordonnes par date}
identifiantClient : entier
Figure 6.11
Transactions 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 rpar-
tition des classes entre les paquetages afin que lassociation qui est en cause ne les relie plus.
204 UML 2
UML2 Livre Page 205 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.12
Double dpendance
A B
6
Chapitre
entre paquetages.
Figure 6.13
Simple dpendance
entre paquetages.
A B
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 dia-
gramme 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. 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 Transaction-
ParChque) 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.
Figure 6.14
Diagramme des
tats-transitions
pour la classe type paiement paiement valid archiv
TransactionClient. choisi valider paiement 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 ti-
culire.
Intressons-nous prsent la deuxime classe qui engendre des objets ayant des tats com-
plexes : 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 automati-
quement dsarme.
206 UML 2
UML2 Livre Page 207 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.15
Diagramme des tats-
arm
6
Chapitre
dbloqu
pression
gchette
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 indpendam-
ment 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.
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 pr-
sent la figure 6.16.
Figure 6.16
Diagramme de cas
dutilisation de la
station-service. Capteur niveau cuve Capteur niveau cuve
pour armement pour remplissage
Station Service
inclut
inclut
Se servir Armer pompe
Points dextension :
Client paiement : { la fin du Pompiste
cas se servir }
Condition : {si le client a
pris de lessence avant de tend
raccrocher le pistolet}
Point dextension : paiement
Payer
Payer
Payer par carte
en espces
bancaire
Archiver les
Banque Payer transactions
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
UML2 Livre Page 209 Vendredi, 14. d cembre 2007 7:24 07
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 ter-
minal 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 Se servir
qui prcisent
quand le paiement
Points dextension :
intervient. - paiementAvant
Client - paiementAprs
Point dextension : paiementAvant Point dextension : paiementAprs
(le paiement se fait avant de se (le paiement se fait aprs stre
servir) servi)
tend
Payer
Banque
Payer par chque
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 gale-
ment 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
Dcrochage dun pistolet
ref
ArmerPompe
loop
[ pistolet hors tui ]
Appui sur la gchette
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
UML2 Livre Page 211 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.19
Scnario nominal
sd ArmerPompe
6
Chapitre
du cas Armer
pompe . : Station service
Pompiste
ref
VrifierNiveauCuvePourArmement
Le scnario nominal pour le cas Vrifier niveau cuve pour armement est donn la
figure 6.20.
Figure 6.20
sd VrifierNiveauCuvePourArmement
Scnario nominal
du cas Vrifier
niveau cuve pour
armement . : Station service
Capteur niveau
pour armement
Remarque
Le diagramme de cas dutilisation dtaille de manire trs prcise les fonctions de la sta-
tion-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 repr-
sentent 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 Capteur niveau cuve Capteur niveau cuve
de dtails. pour armement pour remplissage
Station Service
Se servir
Points dextension :
Client paiement : { la fin du cas
Pompiste
se servir }
Condition : {si le client a pris
de lessence avant de raccrocher
le pistolet} tend
Point dextension : paiement
Payer
Timer
212 UML 2
UML2 Livre Page 213 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.22
Scnario nominal
sd Se servir + Armer pompe + Vrifier niveau cuve pour armement
6
Chapitre
sd VrifierNiveauCuvePourArmement
Demande niveau dans cuve pour armement
loop
Relchement de la gchette
Raccrochage du pistolet
Dsarmer pompe
Figure 6.23
sd payer
Scnario nominal
pour le cas
payer . : Station-service
Pompiste
encaissement (pompe, typeCarburant)
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) nces-
saires pour y accder. La vrification tant fastidieuse, elle na pas t reproduite ici.
Les classes que nous avons dcouvertes jusqu prsent sont issues du domaine de lapplica-
tion. 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 applica-
tion 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 don-
nes, afin de traduire les attributs des classes du domaine dans un format plus parlant pour
le pompiste.
214 UML 2
UML2 Livre Page 215 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.24
cran principal
du terminal du Pompe 1 Pompe n
pompiste.
SansPlomb98 SansPlomb98
SansPlomb95 SansPlomb95
Diesel Diesel
Super Super
Figure 6.25
cran du terminal
du pompiste tel quil Pompe 1 Pompe n
apparat au moment
du paiement.
Montant payer : 30 euros SansPlomb98
Chque Diesel
Espces Super
Valider transaction
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.
Figure 6.26
Composant
permettant
daccder aux
unit centrale
priphriques de Systme informatique de la station
gestion des cuves. service
Priphrique de
gestion des cuves
niveau : 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
interface Cuve
La classe Cuve InterfaceCuve
comme classe niveau : entier
cliente de linterface getNiveau : entier
InterfaceCuve.
3. En plus des classes qui se trouvent la priphrie dun systme et celles qui grent linter-
face 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 fonc-
tions 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
UML2 Livre Page 217 Vendredi, 14. d cembre 2007 7:24 07
DispositifDePompage. Pour contrler ces trois instances, nous crons une classe appele
SessionDePriseDeCarburant.
6
Chapitre
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
client1
sessions de prise
dessence.
session1
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
La SessionDePriseDeCarburant
Une collaboration
qui permet de
montrer le
droulement : Pistolet : Gchette : DispositifDePompage
dune session de
prise dessence.
: Cuve
: SessionDePriseDeCarburant
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 raccro-
che le pistolet. Deux autres diagrammes servant illustrer larmement de la pompe et la
prise du carburant sont rfrencs.
pompe : DispositifDePompage
: Pistolet
gchette : Gchette
ref
ArmementPompe( client, pompiste, session, pompe )
ref
ActivationPompe( client, session, gchette, pompe )
Raccrochage du pistolet
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 solli-
cit implicitement par linstance de la cuve.
218 UML 2
UML2 Livre Page 219 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.31
Interaction qui
sd ArmementPompe( inout client : Client, inout pompiste : Pompiste, inout session :
SessionDePriseDeCarbutant, inout pompe : DispositifDePompage)
6
Chapitre
illustre larmement
de la pompe.
+autrePistolet : boolen
client : Client
pompiste : Pompiste
cuve : Cuve
Demande armement pompe
ref
autrePistolet = TestAutrePistoletPris
armement
OK
RAZ compteur volume
et montant + prix du litre
Affiche confirmation armement
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 rf-
rence la figure 6.30.
Figure 6.32 sd ActivationPompe( inout client : Client, inout session : SessionDePriseDeCarburant, inout gchette : Gchette, inout pompe :
Interaction qui DispositifDePompage )
illustre lactivation
de la pompe.
session : SessionDePriseDeCarburant gchette : Gchette pompe : DispositifDePompage
client : Client
loop
Appui sur la gchette
Appuyer sur la gchette
activer
Relchement de la gchette
Relcher la gchette
dsactiver
Figure 6.33
La SessionDePaiement
Collaboration pour
le paiement.
session : SessionDePaiement
220 UML 2
UML2 Livre Page 221 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.34
Interaction qui
sd payer par carte bancaire
6
Chapitre
illustre comment le
paiement est ralis : TransactionsDuJour
durant la session
pompiste : Pompiste
de paiement. Banque
session : SessionDePaiement
quantit
Calcul du Montant
: TransactionBancaire
validerTransaction( montant )
Transaction valide
Paiement effectu
Informe pompiste
Valide la transaction
Valider transaction
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 trans-
actions . Le premier cas nest pas tudi dans cet ouvrage car il ne prsente pas un grand
intrt. Larchivage des transactions est plus intressant.
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, Gestionnaire-
DesArchivages. Une seule instance de cette classe est ncessaire pour faire fonctionner
larchivage. Lobjet correspondant est actif une fois par jour ( minuit). Il demande larchi-
vage 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
sd Archiver les transactions
Diagramme qui
illustre comment le
gestionnaire des : TransactionsDuJour : GestionnaireDesArchivages
archivages ralise Timer
la sauvegarde
loop
quotidienne des Il est minuit lhorloge
archiver
transactions. systme
: TransactionsDuJour
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
UML2 Livre Page 223 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.36
Les messages
sd ArmementPompe (inout client : Client, inout pompiste : Pompiste, inout session : SessionDePriseDeCarbutant,
inout pompe : DispositifDePompage)
6
Chapitre
niveauSuffisantPourArmement : vrai
armer
armement : vrai
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
Cuve
Ajout dune opration
la classe 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.
Figure 6.38
SessionDePriseDeCarburant
Quelques classes
du domaine avec
leurs oprations.
demandeArmementPompe : boolen
dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant )
raccrochagePistolet
appuiGchette
relachementGchette
Gchette
DispositifDePompage
appuye : boolen
armement : boolen
PriseDeCarburant armer : boolen
dsarmer : boolen
activer : boolen
quantitCarburant : rel
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
224 UML 2
UML2 Livre Page 225 Vendredi, 14. d cembre 2007 7:24 07
La logique mtier est compose des classes du domaine (reprsentes ici par les paque-
tages qui les contiennent).
6
Chapitre
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 ser-
vices : elle indique que larchivage dans la base de donnes (non reprsente) est directe-
ment 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
Transactions ServiceCarburant
layer
Services
______________________
+PiloteGestionCuve
+Pompe
+PiloteGestionPaiement
+GestionPersistance
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.
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.
Entre tat
Sortie
capteur pistolet
commandes
InterfacePistolet pompe
PriseCarburant
InterfaceGchette
Entre tat
capteur
gchette
Sortie quantit essence pompe
InterfaceDbitmtre
226 UML 2
UML2 Livre Page 227 Vendredi, 14. d cembre 2007 7:24 07
Ces interfaces ont t labores partir des classes contenues dans le paquetage du classeur
structur. Par exemple, la classe SessionDePriseDeCarburant contient une opration desti-
ne au pompiste, deux oprations qui servent dinterface avec le pistolet, et deux oprations
6
Chapitre
Figure 6.42
SessionDePriseDeCarburant
Sparation
des oprations
de la classe opration invoque par le pompiste
SessionDePriseDe demandeArmementPompe : boolen
dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant )
Carburant pour raccrochagePistolet oprations lies au pistolet
prparer les appuiGchette
interfaces. relachementGchette 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 clas-
seur structur peut tre accessible via plusieurs interfaces.
Figure 6.43
interface
Interface qui indique InterfacePistolet
si le pistolet est
rang.
dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant )
raccrochagePistolet
interface interface
InterfaceGchette InterfaceDbitmtre
interface
InterfacePompiste
demandeArmementPompe() : boolen
getNumeroPompe() : entier
getTypeCarburant() : TypeCarburant
priseCarburantTermine
La figure 6.44 montre comment le classeur structur PriseCarburant interagit avec son envi-
ronnement 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 compo-
sant CapteurGchette na pas accs sa structure interne). Il adopte un certain comporte-
ment 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 impl-
mente linterface InterfacePompe (figure 6.45).
InterfaceCapteurGchette
unit centrale
: CapteurGchette Systme informatique de la station : Pompe
service
Entre tat
capteur Sortie
gchette commandes
pompe InterfacePompe
PriseCarburant
InterfaceGchette
Figure 6.45
interface
Vue dtaille de InterfacePompe
linterface qui
contrle le moteur
de la pompe.
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 transac-
tions. 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
UML2 Livre Page 229 Vendredi, 14. d cembre 2007 7:24 07
Figure 6.46
Classeur structur
PriseCarburant
6
Chapitre
dont le comportement
est dcrit par une
interaction. ref
SessionDePriseDeCarburant
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 peu-
vent 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).
Figure 6.47
sd archiver les transactions + se servir
Concurrence daccs
sur linstance des
transactions du jour. : TransactionsDuJour : GestionnaireDesArchivages : SessionDePaiement
Timer
par consider{ archiver, il est minuit lhorloge systme, ajouter la transaction client }
critical
Il est minuit
archiver
lhorloge systme
: TransactionsDuJour
critical
Ajouter la transaction client
230 UML 2
UML2 Livre Page 231 Vendredi, 14. d cembre 2007 7:24 07
6
Chapitre
Figure 6.48
Diagramme de sd gestion des transactions
squence pour
larchivage
de transactions. : TransactionsDuJour : TransactionBancaire session : SessionDePaiement
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
t1 : TransactionClient t2 : TransactionClient tn : TransactionClient
Diagramme de
squence pour 10 euros 12,3 euros 47 euros
larchivage de
transactions.
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 Com-
parable. 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.
Annexe A
Comparatif des outils
de modlisation
Introduction
Pour se servir efficacement dUML, il faut utiliser un outil adapt vos besoins. Labon-
dance 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 dbu-
tants, 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 (extrac-
tion 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 syn-
chronisation 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.
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 dia-
grammes 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, tl-
chargement 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
UML2 Livre Page 235 Vendredi, 14. d cembre 2007 7:24 07
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 conte-
nant les lments des diagrammes UML est incluse avec loutil. Visual Studio offre gale-
ment 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.
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 dfini-
tion 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 visua-
lisation 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 dia-
grammes. La version standard offerte aux enseignants inclut suffisamment de fonction-
nalits pour tre vraiment utilisable, une version logiciel de dessin UML gratuite est
disponible. Les diffrents diagrammes sont faciles construire. Beaucoup de fonctionna-
lits 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
UML2 Livre Page 237 Vendredi, 14. d cembre 2007 7:24 07
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 com-
mande de billets de spectacle par un client via un classeur structur.
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.
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.
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, pos-
siblement 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
UML2 Livre Page 239 Vendredi, 14. d cembre 2007 7:24 07
Les composants sont raliss par des ensembles de classeurs, qui implmentent le comporte-
ment 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 com-
posant 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 interfa-
ces 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 ind-
pendants, et donc plus rutilisables. Les interfaces requises et offertes sont connectes entre
elles pour exprimer lassemblage des parties ralisant le composant.
Figure C.2
component
La ralisation dun Persistance
composant expose Persistance delegate BaseDeDonnes
delegate
en bote blanche.
CollectionPersistante
delegate
AnalyseurDeClasse
PersistanceTypeDeBase
Composants 239
UML2 Livre Page 240 Vendredi, 14. d cembre 2007 7:24 07
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 dve-
loppement dun systme. Au final, ce dernier va sexcuter sur des ressources matrielles
(processeurs, mmoire, etc.) dans un environnement particulier. UML permet de reprsen-
ter un environnement dexcution ainsi que des ressources physiques (avec les parties du
systme qui sy excutent) grce aux diagrammes de dploiement. Lenvironnement dex-
cution 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 client : PC serveurWEB : Serveur serveurBaseDeDonnes : ServeurSGBD
dploiement pour
un serveur Web
qui prsente des
instances de nuds
et une instance
dartefact dploye. dploy
artfact
siteWEB
Figure D.2
Diagramme de PC Serveur ServeurSGBD
dploiement pour
1..*
un serveur Web
qui prsente des
nuds.
240 UML 2
UML2 Livre Page 241 Vendredi, 14. d cembre 2007 7:24 07
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 ex-
cuts. 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, Object-
Team, 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 gn-
ration automatique de code partir dun diagramme de classes vers des langages de pro-
grammation varis (Java, C++, C#, etc.). Dans la suite de ce paragraphe, nous montrons
comment implmenter les lments essentiels dun diagramme de classes, et comment tra-
duire les messages des diagrammes dinteraction (de squence ou de communication) en Java.
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
Figure E.2
interface
Vehicule
Voiture
242 UML 2
UML2 Livre Page 243 Vendredi, 14. d cembre 2007 7:24 07
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
1 range
Emplacement
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
package bagnole;
public class Voiture{
Conducteur conducteur;
public void setConducteur( Conducteur conducteur ){
this.conducteur = conducteur;
conducteur.voiture = this;
}
}
Figure E.5
Entreprise
+
* clients
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 );
}
public static void main( String [] argv ){
Entreprise monEntreprise = new Entreprise();
Client client = new Client();
monEntreprise.addClient( client );
monEntreprise.removeClient( client );
}
}
244 UML 2
UML2 Livre Page 245 Vendredi, 14. d cembre 2007 7:24 07
1..n exemplaires
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;
}
}
Moteur
Composition
public class Voiture{
private class Moteur{
}
private Moteur moteur;
}
conducteur : Conducteur
dmarrer
voiture : Voiture
246 UML 2
UML2 Livre Page 247 Vendredi, 14. d cembre 2007 7:24 07
Figure E.9
sd Piloter
conduire
demarrer
Annexe F
Organisation dUML 2
DIFFRENTES VUES DUML 2
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.
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 sous-
modles. 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
UML2 Livre Page 249 Vendredi, 14. d cembre 2007 7:24 07
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 diffren-
ces 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 nais-
sance des langages comme UML et CWM. Lutilisateur dUML dfinit des classeurs (clas-
ses, associations) dcrivant son application en respectant les spcifications du
mtamodle UML. Un modle utilisateur bien employ garantit un modle dobjets physi-
ques 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 superstruc-
ture 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 cou-
che 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.
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 (dia-
gramme de cas dutilisation). Elle dfinit le contour du systme modliser en dfinis-
sant 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 pr-
sente 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
UML2 Livre Page 251 Vendredi, 14. d cembre 2007 7:24 07
Domaine dynamique
Le domaine dynamique regroupe lensemble des vues montrant le comportement du sys-
tme 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.
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
[Larman]
Craig Larman. UML et les design patterns, deuxime dition, CampusPress, 2005
[Penders 2002]
Tom Penders. Introduction UML, EOM, 2002
[Rumbaugh 2004]
James Rumbaugh, Ivar Jacobson et Grady Booch. UML 2.0 - Guide de rfrence, Campus-
Press, 2004
252 UML 2
UML2 Livre Page 253 Vendredi, 14. d cembre 2007 7:24 07
Index
A Analyse
du systme 1
Abstraite phase d 190
classe 38 Argument 94
mthode 38 Artefact 241
Acteur 3, 9, 16, 27, 29 Assert 95
Action Assert, oprateur 98
call 131, 156 Assertion 95
manipulations de variables 158 Association 46
opaque 160 avec contraintes 47
raise exception 157 classe 48
send 157 drive 48
sur un link 159 n-aire 49
time event 131 qualifie 49
Asynchrone, message 91, 111
Activit
Attribut driv 61
argument d'une 168
concurrence 171, 181
description 161 B
et cas d'utilisation 178, 182 Boucle
exception 172 oprateur 104
interne 133 reprsentation 97
interruptible 174 Break 97
ligne d'eau 166
partition 166 C
pin 168
programmation 166, 177, 179, 183 Cas d'utilisation 2, 9
acteur 3
structure 166
dfinition 3
structures de contrle 164 diagramme 1, 2, 15
zone d'expansion 175 extension 5, 25, 27
Agrgation 50 gnralisation 5, 29
Alt, oprateur dinteraction 96 inclusion 5, 29
Alternative 96 relations 5, 18
Index 253
UML2 Livre Page 254 Vendredi, 14. d cembre 2007 7:24 07
254 UML 2
UML2 Livre Page 255 Vendredi, 14. d cembre 2007 7:24 07
Index
H O
Hritage 71, 72 Objet 37
exceptions 174 actif 113
multiple 53, 72 ligne de vie 86
relation 52 passif 113
signal 130 reprsentation 55
Historique, pseudo-tat 136 Occurrence d'vnement 92
Oprande d'interaction 96
I Opt 120
Ignore, oprateur 98
Implmentation en langage Java 241 P
Inclut 5 Paquetage 25
Inout, paramtre 94, 105 dfinition 8
Instance 37 dpendance 25
de relation 56 Par, oprateur 97, 117
Interaction Parallle, envoi de messages 97
dfinition 86 Paramtre
diagramme 87 de retour 94
fragment 96 inout 94, 105
message 87, 91, 92, 103 Partie structure 237
oprande 96 Patron de conception
utilisation 106 adapteur 81
Interface 44 Bridge 80
ralisation d'une 68 objets composites 74
utilisation d'une 68
Phase
Interne, structure 237 d'implmentation 188
de dploiement 188
L de maintenance 188
Ligne de vie 86 de tests 188
Pin
d'exception 169
M dfinition 168
Message stream 170
asynchrone 64, 91 Point
dans un diagramme d'extension 6, 28, 33
de communication 104, 108 de choix 132
de squence 94, 107 de jonction 131, 164
dfinition 91 Port 54
dlai de transmission 91 proprits 54
signal 130 protocole 54
synchrone 91, 156 Postcondition 12, 23
Modle des cas dutilisation 1, 15 Prcondition 12, 22
Modlisation d'une classe 61 protocol 138
Multiplicit 45
R
N
Rgion interruptible 174
Neg 120 Relation 45, 69
Nud dans un diagramme de dploiement 240 agrgation 50
Numro de squence 103 composition 50
Index 255
UML2 Livre Page 256 Vendredi, 14. d cembre 2007 7:24 07
d'extension 5 T
d'inclusion 5
Thread 91
dpendance 51
d'instanciation 56
gnralisation 5, 7, 28 U
hritage 52 Utilisation
n-aire 70 d'une collaboration 89
simple 66 d'une interaction 88
S V
Scnario 14 Variables, manipulation 158
Sd, mot-cl 87 Visibilit de paquetages 8
Signal 54
vnement 130 Z
Strotype, dfinition 4
Zone d'expansion 175
Strict sequencing, oprateur 99
Structure interne 237
Synchrone, message 91
Synchronisation des activits 171
256 UML 2
UML 2
Informatique
Synthse
de cours
exercices
& 2e dition
ISBN : 978-2-7440-4050-4