Académique Documents
Professionnel Documents
Culture Documents
Livre UML 2
Livre UML 2
Synthse
de cours
exercices
corrigs
&
UML 2
Pratique de la modlisation
2e dition
collection
Synthex
Benot CHARROUX
Aomar OSMANI
Yann THIERRY-MIEG
Informatique
Synthse
de cours
&
exercices
corrigs
UML 2
2e dition
Benot Charroux
EFREI (cole dingnieur)
Aomar Osmani
universit Paris XIII
Yann Thierry-Mieg
universit Paris VI
collection
Synthex
ISBN : 978-2-7440-4050-4
ISSN : 1768-7616
Copyright 2009 Pearson Education France
Tous droits rservs
Composition sous FrameMaker : TyPAO
Aucune reprsentation ou reproduction, mme partielle, autre que celles prvues larticle L. 122-5 2 et 3 a)
du code de la proprit intellectuelle ne peut tre faite sans lautorisation expresse de Pearson Education France
ou, le cas chant, sans le respect des modalits prvues larticle L. 122-10 dudit code.
Sommaire
Les auteurs
Introduction
VII
35
85
127
155
187
233
Annexe B
237
Classeurs structurs
Annexe C Composants
238
240
Annexe E
241
Annexe F
Organisation dUML 2
247
Annexe G Bibliographie
252
Index
253
Sommaire III
Les auteurs
Benot Charroux est docteur en informatique. Aprs avoir men des travaux de recherche
en traitement dimages, il se consacre maintenant exclusivement la formation. Ayant
dirig le dpartement informatique de lESIGETEL, il gre prsent les enseignements
de linformatique lEFREI (cole dIngnieurs des Technologies de lInformation et du
Management). Il enseigne les technologies orientes objet (UML, Java, C++, EJB) dans de
nombreux tablissements : coles dingnieurs, universits, et entreprises.
Aomar Osmani est docteur en informatique et matre de confrences luniversit Paris
XIII. Il mne des travaux de recherche en diagnostic de systmes dynamiques, en raisonnement temporel et en apprentissage artificiel. Ces activits denseignement portent sur la
plupart des domaines de linformatique (architecture des ordinateurs, rseaux, systmes,
bases de donnes). Il a principalement enseign ces dernires annes les technologies orientes objet et le gnie logiciel, et a particip, linstitut universitaire de technologie de Paris
XIII, la cration et la direction de groupes de licence professionnelle.
Yann Thierry-Mieg est docteur en informatique et matre de confrences. Ses problmatiques de recherche sont centres sur la modlisation et la vrification formelle de systmes
informatiques, plus particulirement rpartis, en vue de fournir des outils pour vrifier de
manire automatique le comportement dun systme partir de son modle. Il enseigne
Paris VI ainsi qu lEFREI les systmes dinformation, les technologies orientes objet et
les mthodologies de dveloppement.
Les auteurs V
Introduction
Lapproche objet est incontournable dans le cadre du dveloppement de systmes logiciels
complexes, capables de suivre les volutions incessantes des technologies et des besoins
applicatifs. Cependant, la programmation objet est moins intuitive que la programmation
fonctionnelle. En effet, il est plus naturel de dcomposer les problmes informatiques en
termes de fonctions quen termes densembles dobjets en interaction. De ce fait, lapproche
objet requiert de modliser avant de concevoir. La modlisation apporte une grande rigueur, offre une meilleure comprhension des logiciels, et facilite la comparaison des solutions
de conception avant leur dveloppement. Cette dmarche se fonde sur des langages de modlisation, qui permettent de saffranchir des contraintes des langages dimplmentation.
Le besoin dune mthode de description et de dveloppement de systmes, prenant en compte
la fois les donnes et les traitements, a grandi en mme temps que la taille des applications
objet. Au milieu des annes 90, plusieurs dizaines de mthodes objet sont disponibles, mais
aucune ne prdomine. Lunification et la normalisation des trois mthodes dominantes,
savoir Booch, du nom de son auteur, OOSE (Object Oriented Software Engineering), dIvan
Jacobson et OMT (Object Modeling Technique), de James Rumbaugh, sont lorigine de la
cration du langage UML (Unified Modeling Language).
UML est une notation graphique conue pour reprsenter, spcifier, construire et documenter
les systmes logiciels. Ses deux principaux objectifs sont la modlisation de systmes utilisant les techniques orientes objet, depuis la conception jusqu la maintenance, et la cration dun langage abstrait comprhensible par lhomme et interprtable par les machines.
UML sadresse toutes les personnes charges de la production, du dploiement et du suivi
de logiciels (analystes, dveloppeurs, chefs de projets, architectes), mais peut galement
servir la communication avec les clients et les utilisateurs du logiciel. Il sadapte tous les
domaines dapplication et tous les supports. Il permet de construire plusieurs modles
dun systme, chacun mettant en valeur des aspects diffrents : fonctionnels, statiques, dynamiques et organisationnels. UML est devenu un langage incontournable dans les projets de
dveloppement.
Une mthode de dveloppement dfinit la fois un langage de modlisation et la marche
suivre lors de la conception. Le langage UML propose uniquement une notation dont
linterprtation est dfinie par un standard, mais pas une mthodologie complte. Plusieurs
processus de dveloppement complets fonds sur UML existent, comme le Rational Unified
Process (RUP), de Booch, Jacobson et Rumbaugh, ou lapproche MDA (Model Driven
Architecture) propose par lOMG, mais ils ne font pas partie du standard UML.
Introduction VII
VIII
UML 2
Certes, des outils comme les automates et les diagrammes dactivits sont disponibles, mais
leur emploi est limit. Les utilisateurs restent sur le vieux paradigme centr sur le code : ils
se contentent de recourir UML lors des phases prliminaires et passent un langage de
programmation classique lors des phases de codage et de tests. Lun des objectifs de lOMG
est de proposer un paradigme guid par des modles dcrivant la fois le codage, la gestion
de la qualit, les tests et vrifications, et la production de la documentation. Il sagit de
recentrer lactivit des informaticiens sur les fonctions que le systme doit fournir, en
conformit avec les exigences du client et les standards en vigueur.
Objectif du livre
Lobjectif de cet ouvrage est de fournir une rfrence concise des concepts de base dUML,
illustre par de nombreux exemples. Nous adoptons le point de vue pragmatique des utilisateurs du langage. Il permet de comprendre limportance de la modlisation et lintrt
demployer une notation graphique.
Selon le principe de cette collection, chaque chapitre commence par une synthse de cours
prsentant les concepts de base du langage, avec leur syntaxe prcise, et illustre de nombreux exemples, remarques pratiques et commentaires. Vient ensuite une srie dexercices.
Ce livre donne la vue utilisateur des concepts de la notation UML : ils sont dcrits avec prcision dans la norme par un mtamodle, mais cet aspect un peu complexe nest pas dtaill
dans cet ouvrage.
Le langage UML ne sappuie pas sur un processus dcrivant les tapes du dveloppement.
Cependant, il est bien adapt aux processus itratifs guids par les besoins des utilisateurs et
axs sur larchitecture. Les exemples et les exercices corrigs, prsents au fil des chapitres,
donnent des indications sur les approches suivre pour laborer un modle dune situation
donne. Le problme difficile et rcurrent de lenchanement des modles est trait dans
une tude de cas prsente au chapitre 6.
Structure du livre
Le livre est compos de chapitres qui peuvent tre lus sparment. Cependant, le plan respecte toujours la mme dmarche dont la premire tape correspond une prsentation du
point de vue fonctionnel. Lanalyse fonctionnelle permet de mettre au point une reprsentation graphique, compacte et complte des besoins, appele diagramme de cas dutilisation . Les cas sont ventuellement dcrits textuellement afin de spcifier les diffrents
scnarios attendus du systme. Vient ensuite la partie analyse statique , dans laquelle on
spcifie les classes et les relations entre classes (diagramme de classes). Des cas particuliers
ou explicatifs sont aussi prsents par des diagrammes dobjets. Une fois que les diffrents
objets sont dfinis (diagramme de classes), on revient sur lanalyse fonctionnelle dans
laquelle on spcifie les interactions entre les diffrents objets du systme. On peut tre intress par les changes dans le temps (diagramme de squence) ou encore par les collaborations existantes entre les objets (diagramme de communication). La description de la
partie dynamique du systme est prsente par les diagrammes dtats et les diagrammes
dactivits.
Chaque chapitre est divis en deux parties : le rappel de cours puis les exercices corrigs, qui
occupent une part importante de louvrage. Ils illustrent via des exemples simples les
concepts prsents dans le rappel de cours et expliquent comment utiliser UML dans des
situations pratiques. Ils donnent quelques indications sur la manire de modliser (ce qui
ne fait pas partie de la description du langage). travers une application concrte, le chapitre 6 introduit le diagramme de composants, qui permet une organisation statique du systme, et prsente une mthodologie complte intgrant la plupart des concepts prsents
dans les chapitres prcdents.
Introduction IX
Prrequis
Si cet ouvrage peut tre abord par toute personne ayant une certaine culture informatique,
certains passages ncessitent la connaissance des notions minimales de programmation
objet. De nombreux concepts dUML (classes, hritage, encapsulation) sont directement
proposs par les langages de programmation orients objet, comme le C++ ou Java. Certains
exemples sont donc compars ces langages, et supposent donc une exprience minimale
de la programmation oriente objet. Les ouvrages sur le C++ et Java 5, publis dans la
mme collection, sont de bonnes rfrences en la matire.
Pourquoi modliser ?
Un modle est une reprsentation simplifie dune ralit. Il permet de capturer des aspects
pertinents pour rpondre un objectif dfini a priori. Par exemple, un astronaute modlisera la Lune comme un corps cleste ayant une certaine masse et se trouvant une certaine
distance de la Terre, alors quun pote la modlisera comme une dame avec laquelle il peut
avoir une conversation.
Le modle sexprime sous une forme simple et pratique pour le travail [Rumbaugh2004].
Quand le modle devient compliqu, il est souhaitable de le dcomposer en plusieurs
modles simples et manipulables.
Lexpression dun modle se fait dans un langage compatible avec le systme modlis et les
objectifs attendus. Ainsi, le physicien qui modlise la lune utilisera les mathmatiques
comme langage de modlisation. Dans le cas du logiciel, lun des langages utiliss pour la
modlisation est le langage UML. Il possde une smantique propre et une syntaxe compose de graphique et de texte et peut prendre plusieurs formes (diagrammes).
Les modles ont diffrents usages :
Ils servent circonscrire des systmes complexes pour les dominer. Par exemple, il est inimaginable de construire une fuse sans passer par une modlisation permettant de tester
les racteurs, les procdures de scurit, ltanchit de lensemble, etc.
Ils optimisent lorganisation des systmes. La modlisation da la structure dune entreprise en divisions, dpartements, services, etc. permet davoir une vision simplifie du
systme et par l mme den assurer une meilleure gestion
Ils permettent de se focaliser sur des aspects spcifiques dun systme sans sembarrasser
des donnes non pertinentes. Si lon sintresse la structure dun systme afin de factoriser ses composants, il est inutile de sencombrer de ses aspects dynamiques. En utilisant,
par exemple, le langage UML, on sintressera la description statique (via le diagramme
de classes) sans se soucier des autres vues.
Ils permettent de dcrire avec prcision et compltude les besoins sans forcment connatre
les dtails du systme.
Ils facilitent la conception dun systme, avec notamment la ralisation de maquette
approximative, chelle rduite, etc.
Ils permettent de tester une multitude de solutions moindre cot et dans des dlais
rduits et de slectionner celle qui rsout les problmes poss.
La modlisation objet produit des modles discrets permettant de regrouper un ensemble
de configurations possibles du systme et pouvant tre implments dans un langage de
programmation objet. La modlisation objet prsente de nombreux avantages travers
un ensemble de proprits (classe, encapsulation, hritage et abstraction, paquetage,
modularit, extensibilit, adaptabilit, rutilisation) qui lui confre toute sa puissance et
son intrt.
UML 2
UML 2
UML 2 apporte des volutions majeures par rapport UML 1.5, sans toutefois tre rvolutionnaire : les principales fonctionnalits de base se ressemblent. Au niveau du mtamodle,
qui concerne surtout les dveloppements doutils, UML 2 se rapproche davantage des standards de modlisation objet proposs par lOMG. En particulier, lunification du noyau
UML et des parties conceptuelles de modlisation MOF (Meta-Object Facility) permet aux
outils MOF de grer les modles UML ; lajout du principe de profils permet de mieux dfinir les extensions du domaine ; enfin, la rorganisation du mtamodle UML limine les
redondances prsentes dans les versions prcdentes (voir la fin de louvrage pour plus de
dtails concernant la structuration du langage UML).
Du point de vue de lutilisateur, les changements concernent certaines notations. La notation des diagrammes de squence se rapproche de la norme dchanges de messages MSC
(Message Sequence Chart) de lIUT (Union Internationale des Tlcommunications). Le concept
de classeurs sinspire des avances de lingnierie temps rel du langage de description et de
spcification SDL. De plus, UML 2 unifie la modlisation des activits et la modlisation des
actions introduites dans UML 1.5 et utilise des notations de modlisation de processus
mtier. Des lments de modlisation contextuels amliorent la souplesse et formalisent
mieux le concept dencapsulation des classes et des collaborations.
Afin de formaliser le modle utilisateur du langage et de le rapprocher davantage des normes
OMG, le langage UML est structur en quatre couches (figure 0.1) ; seules les deux couches
user model et run time instance sont destines lutilisateur.
Figure 0.1
Organisation
en quatre couches
du langage UML.
Lutilisateur na pas besoin de mettre en vidence cette organisation quand il utilise UML. Il
doit se contenter de respecter la syntaxe et la smantique du langage dtailles dans ce livre.
Il doit galement connatre les diffrents diagrammes mettant en valeur tantt des aspects
statiques, tantt des aspects comportementaux du systme. Une organisation conceptuelle
des diffrents diagrammes UML permet davoir une vision plus claire des vues offertes par
ce langage. Les trois auteurs lorigine du langage UML proposent un dcoupage conceptuel en quatre domaines : structurel, dynamique, physique et gestion de modles (voir la fin
de louvrage pour plus de dtails).
Introduction XI
Chapitre
Diagramme de cas
dutilisation
1. Limportance de bien recueillir
les besoins ................................ 2
2. Le diagramme de cas dutilisation 2
3. Modlisation des besoins
avec UML ................................ 9
Problmes et exercices
1. Identification des acteurs et
recensement de cas dutilisation
simples ....................................
2. Relations entre cas dutilisation....
3. Relations entre cas dutilisation
cas internes ...........................
4. Identification des acteurs,
recensement des cas dutilisation
et relations simples entre cas......
5. Description dun cas dutilisation
6. Relations dextension entre cas
dutilisation, regroupement de
cas dutilisation en paquetages ..
7. Relations entre acteurs,
extensions conditionnelles
entre cas dutilisation ................
8. Identification des acteurs, recensement des cas dutilisation
internes et relation de gnralisation entre cas.......................
16
18
18
20
22
25
27
29
(1)
(2)
2.1 LES
CAS DUTILISATION
Parlons prsent dUML et voyons quelle aide il peut apporter lors du recueil des besoins.
UML nest quun langage et il ne sert ici qu formaliser les besoins, cest--dire les
reprsenter sous une forme graphique suffisamment simple pour tre comprhensible par
toutes les personnes impliques dans le projet. Noublions pas que bien souvent, le matre
douvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas dutilisation.
Ils permettent de recenser les grandes fonctionnalits dun systme.
EXEMPLE
UML 2
La figure 1.1 modlise une borne interactive qui permet daccder une banque. Le systme
modliser apparat dans un cadre (cela permet de sparer le systme modliser du
monde extrieur). Les utilisateurs sont reprsents par des petits bonshommes, et les grandes
fonctionnalits (les cas dutilisation) par des ellipses.
Chapitre
Figure 1.1
frontire du sujet
Diagramme
de cas dutilisation
modlisant une
borne daccs
une banque.
nom du sujet
cas dutilisation
Retirer argent
acteur
Effectuer un virement
Consulter comptes
Client
association
Lensemble des cas dutilisation contenus dans le cadre constitue un sujet . Les petits
bonshommes sont appels acteurs . Ils sont connects par de simples traits (appels
associations ) aux cas dutilisation et mettent en vidence les interactions possibles entre
le systme et le monde extrieur. Chaque cas modlise une faon particulire et cohrente
dutiliser un systme pour un acteur donn.
Dfinition
Un cas dutilisation est une manire spcifique dutiliser un systme. Les acteurs sont
lextrieur du systme ; ils modlisent tout ce qui interagit avec lui. Un cas dutilisation
ralise un service de bout en bout, avec un dclenchement, un droulement et une fin, pour
lacteur qui linitie.
Notation et spcification
Un cas dutilisation se reprsente par une ellipse (figure 1.2). Le nom du cas est inclus dans
lellipse ou bien il figure dessous. Un strotype (voir la dfinition ci-aprs), peut tre ajout
optionnellement au-dessus du nom, et une liste de proprits place au-dessous.
Un cas dutilisation se reprsente aussi sous la forme dun rectangle deux compartiments :
celui du haut contient le nom du cas ainsi quune ellipse (symbole dun cas dutilisation) ;
celui du bas est optionnel et peut contenir une liste de proprits (figure 1.3).
Un acteur se reprsente par un petit bonhomme ayant son nom inscrit dessous (figure 1.1) ou
par un rectangle contenant le strotype acteur avec son nom juste en dessous (figure 1.4).
Il est recommand dajouter un commentaire sur lacteur pour prciser son rle.
Figure 1.4
Autre reprsentation
dun acteur.
strotype
Nom du cas
Liste de proprits
Nom du cas
Liste de proprits
Rle de lacteur
acteur
Nom de lacteur
La figure 1.4 reprsente un acteur par un rectangle. UML utilise aussi les rectangles pour
reprsenter des classes, et plus gnralement des classeurs. Pour autant, la notation nest pas
ambigu puisque le strotype acteur indique que le rectangle dsigne un acteur. Les strotypes permettent dadapter le langage des situations particulires.
Dfinition
Un strotype reprsente une variation dun lment de modle existant.
un niveau dabstraction plus lev, UML permet de reprsenter tous les cas dutilisation
dun systme par un simple rectangle. La figure 1.5 montre comment un tel rectangle peut
remplacer tous les cas dutilisation de la figure 1.1.
Figure 1.5
Reprsentation des cas
dutilisation un niveau
dabstraction lev.
Dfinition
Un classeur est un lment de modlisation qui dcrit une unit comportementale ou structurelle. Les acteurs et les cas dutilisation sont des classeurs. Tout au long de ce livre, on
retrouvera le terme classeur car cette notion englobe aussi les classes, des par ties dun
systme, etc.
Notation
Un classeur se reprsente par un rectangle contenant ventuellement des compar timents (la
figure 1.6 montre comment il est possible de faire figurer explicitement des cas dutilisation
dans un classeur).
Figure 1.6
Les compartiments
dun classeur.
Retirer argent
Effectuer un virement
Consulter comptes
UML 2
Chapitre
2.2 RELATIONS
La figure 1.7 montre un internaute qui tlcharge plusieurs morceaux de musique sur Internet.
Figure 1.7
Logiciel de tlchargement
Association avec
multiplicit.
*
Internaute
Le symbole * qui signifie plusieurs est ajout lextrmit du cas et sappelle une multiplicit. Plusieurs valeurs sont possibles pour la multiplicit : exactement n scrit tout simplement n, m..n signifie entre m et n, etc. Prciser une multiplicit sur une relation
nimplique pas ncessairement que les cas sont utiliss en mme temps.
2.3 RELATIONS
Pour clarifier un diagramme, UML permet dtablir des relations entre les cas dutilisation.
Il existe principalement deux types de relations : les dpendances strotypes et la gnralisation/spcialisation. Les dpendances strotypes sont des dpendances dont la porte
est explicite par le nom du strotype. Les strotypes les plus utiliss sont linclusion et
lextension.
La relation dinclusion. Un cas A est inclus dans un cas B si le comportement dcrit par le
cas A est inclus dans le comportement du cas B : on dit alors que le cas B dpend de A.
Cette dpendance est symbolise par le strotype inclut. Par exemple, laccs aux informations dun compte bancaire inclut ncessairement une phase dauthentification avec
un mot de passe (figure 1.8).
La relation dextension. Si le comportement de B peut tre tendu par le comportement
de A, on dit alors que A tend B. Une extension est souvent soumise condition. Graphiquement, la condition est exprime sous la forme dune note. La figure 1.8 prsente
lexemple dune banque o la vrification du solde du compte nintervient que si la
demande de retrait dargent dpasse 20 euros.
La relation de gnralisation. Un cas A est une gnralisation dun cas B si B est un cas
particulier de A. la figure 1.8, la consultation dun compte bancaire via Internet est un
cas particulier de la consultation. Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par le concept dhritage dans les
langages orients objet.
Les inclusions permettent aussi de dcomposer un cas complexe en sous-cas plus simples.
EXEMPLE
la figure 1.9, le modlisateur a jug que la vente dun article par correspondance est un
problme complexe et quil est important de faire apparatre dans le modle une dcomposition en sous-cas.
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 ventuellement associ une contrainte indiquant le moment o lextension inter vient. Une extension
est souvent soumise une condition (indique dans une note attache la flche pointille).
Le symbole utilis pour la gnralisation est une flche en traits pleins dont la pointe est un
triangle ferm. La flche pointe vers le cas le plus gnral (figure 1.8).
Figure 1.8
Retirer argent
Effectuer un virement
Point dextension :
vrificationSolde {aprs
avoir demand le
montant}
inclut
inclut
tend
Sauthentifier
Client
Vrifier le solde
Condition : {si montant > 20 euros}
Point dextension : vrificationSolde
inclut
Consulter comptes
Figure 1.9
Vrifier la disponibilit
de larticle
inclut
Passer une commande
inclut
Prpos aux
commandes
Vrifier la solvabilit du client
Un cas reli un autre cas peut ne pas tre directement accessible un acteur (figure 1.9).
Un tel cas est appel cas interne .
UML 2
Chapitre
Dfinition
Un cas dutilisation est dit interne sil nest pas reli directement un acteur.
Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et denrichir les
cas dutilisation. Par exemple, la figure 1.8, rien nempche de regrouper les cas Consulter
comptes et Consulter sur Internet en un seul cas. Cependant, indiquer ds la phase de
recueil des besoins quil y a des cas particuliers apporte une information supplmentaire
pertinente. La question se poser est : faut-il la faire figurer dans le diagramme de cas dutilisation ou la prendre en compte plus tard ? La rponse cette question ne sera pas toujours
la mme selon le contexte du projet.
Remarque
Attention lorientation des flches : si le cas A inclut B on trace la flche de A vers B, mais
si B tend A, la flche est dirige de B vers A.
2.4 RELATIONS
ENTRE ACTEURS
La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une
gnralisation dun acteur B si lacteur A peut tre substitu par lacteur B (tous les cas dutilisation accessibles A le sont aussi B, mais linverse nest pas vrai).
EXEMPLE
La figure 1.10 montre que le directeur des ventes est un prpos aux commandes avec un
pouvoir supplmentaire (en plus de pouvoir passer et suivre une commande, il peut grer le
stock). Le prpos aux commandes ne peut pas grer le stock.
Figure 1.10
Relations
entre acteurs.
Passer une commande
inclut
Rechercher article
inclut
inclut
Grer le stock
Directeur
des ventes
Notation
Le symbole utilis pour la gnralisation entre acteurs est une flche en traits pleins dont la
pointe est un triangle ferm. La flche pointe vers lacteur le plus gnral.
2.5 REGROUPEMENT
UML permet de regrouper des cas dutilisation dans une entit appele paquetage . Le
regroupement peut se faire par acteur ou par domaine fonctionnel. Un diagramme de cas
dutilisation peut contenir plusieurs paquetages et des paquetages peuvent tre inclus dans
dautres paquetages.
Dfinition
Un paquetage permet dorganiser des lments de modlisation en groupe. Un paquetage
peut contenir des classes, des cas dutilisations, des interfaces, etc.
EXEMPLE
la figure 1.11, trois paquetages ont t crs : Client, Stock et Suppor t. Ces paquetages
contiennent les cas dutilisation du diagramme de la figure 1.10 (Client contient les cas
Passer une commande et Suivre une commande , Stock contient le cas Grer le
stock , tandis que le cas Rechercher article est inclus dans le paquetage Support.
Figure 1.11
Regroupement
des cas dutilisation
en paquetage.
Client
Dpendance
entre paquetages
qui reflte
linclusion des
cas dutilisation.
Support
Stock
En tant que langage, UML est soumis des rgles de nommage quil faut strictement respecter : pour accder au contenu de paquetages imbriqus les uns dans les autres, il faut utiliser
des deux-points comme sparateur des noms de paquetage. Par exemple, si un paquetage B
inclus dans un paquetage A contient une classe X, il faut crire A::B::X pour pouvoir utiliser
la classe X en dehors du contexte des paquetages.
UML 2
Chapitre
(3)
3.1 QUI
? COMMENT
LES IDENTIFIER
Les principaux acteurs sont les utilisateurs du systme. Ils sont en gnral faciles reprer.
Cest le matre douvrage qui les dsigne. Chaque acteur doit tre nomm, mais attention,
pour trouver son nom, il faut penser son rle : un acteur reprsente un ensemble cohrent
de rles jous vis--vis dun systme. Ainsi, pour un logiciel de gestion de paie, le nom
correct dun acteur est Comptable plutt que Mme Dupont. Plusieurs personnes peuvent
avoir le mme rle. Cest le cas des clients dune banque par exemple. Il ny aura alors quun
seul acteur. Rciproquement, une mme personne physique peut jouer des rles diffrents
vis--vis du systme et donc correspondre plusieurs acteurs.
En gnral, les utilisateurs ne sont pas difficiles trouver, mais il faut veiller ne pas oublier
les personnes responsables de lexploitation et de la maintenance du systme. Par exemple,
un logiciel de surveillance qui limite les accs un btiment doit avoir un administrateur
charg de crer des groupes de personnes et leur donner des droits daccs. Il ne sagit pas ici
des personnes qui installent et paramtrent le logiciel avant sa mise en production, mais des
utilisateurs du logiciel dans son fonctionnement nominal.
En plus des utilisateurs, les acteurs peuvent tre :
des priphriques manipuls par le systme (imprimantes, robots) ;
des logiciels dj disponibles intgrer dans le projet ;
des systmes informatiques externes au systme mais qui interagissent avec lui, etc.
Pour faciliter la recherche des acteurs, on peut imaginer les frontires du systme. Tout ce
qui est lextrieur et qui interagit avec le systme est un acteur ; tout ce qui est lintrieur
est une fonctionnalit du systme que le matre duvre doit raliser.
Un cas dutilisation a toujours au moins un acteur principal pour qui le systme produit un
rsultat observable, et ventuellement dautres acteurs ayant un rle secondaire. Par exemple, lacteur principal dun cas de retrait dargent dans un distributeur automatique de
billets est la personne qui fait le retrait, tandis que la banque qui vrifie le solde du compte
est un acteur secondaire. En gnral, lacteur principal initie le cas dutilisation par ses sollicitations.
Dfinition
Lacteur est dit principal pour un cas dutilisation lorsque le cas dutilisation rend ser vice
cet acteur. Les autres acteurs sont dits secondaires . Un cas dutilisation a au plus un
acteur principal, et un ensemble ventuellement vide dacteurs secondaires.
Un acteur principal obtient un rsultat observable du systme tandis quun acteur secondaire est sollicit pour des informations complmentaires.
3.2 COMMENT
Il ny a pas une faon unique de reprer les cas dutilisation. Il faut se placer du point de vue
de chaque acteur et dterminez comment il se sert du systme, dans quels cas il lutilise, et
quelles fonctionnalits il doit avoir accs. Il faut viter les redondances et limiter le nombre de
cas en se situant au bon niveau dabstraction (par exemple, ne pas rduire un cas une action).
EXEMPLE
Considrons un systme de rservation et dimpression de billets de train via des bornes interactives situes dans des gares. En prenant pour acteur une personne qui souhaite obtenir un
billet, on peut obtenir la liste suivante des cas dutilisation :
rechercher un voyage ;
rserver une place dans un train ;
acheter son billet.
Lensemble des cas dutilisation doit couvrir exhaustivement tous les besoins fonctionnels
du systme. Ltape de recueil des besoins est souvent longue et fastidieuse car les utilisateurs
connaissent lexistant et nont quune vague ide de ce que leur apportera un futur systme ;
en outre, le cahier des charges contient des imprcisions, des oublis, voire des informations
contradictoires difficiles extraire. Llaboration du diagramme de cas dutilisation permet
de pallier ces problmes en recentrant le systme sur les besoins fonctionnels et ce, ds le
dbut du projet.
On peut se demander pourquoi adopter un point de vue fonctionnel, et non technique ?
Trop souvent, par le pass, les logiciels taient techniquement trs labors sans pour autant
satisfaire les utilisateurs. Avec les diagrammes de cas dutilisation, on se place clairement du
ct des utilisateurs. Le ct technique nest pas oubli mais abord diffremment : les
besoins sont affins lors de lcriture des spcifications on parle de spcifications techniques des besoins (voir la section Description textuelle des cas dutilisation ).
Remarque
Il ne faut pas faire apparatre les dtails des cas dutilisation, mais il faut rester au niveau
des grandes fonctions du systme. La question qui se pose alors est de savoir jusqu quel
niveau de dtails descendre ? Si le nombre de cas est trop impor tant, il faut se demander
si on a fait preuve de suffisamment dabstraction. Le nombre de cas dutilisation est un bon
indicateur de la faisabilit dun logiciel.
Il ne doit pas y avoir de notion temporelle dans un diagramme de cas dutilisation. Il ne faut
pas se dire que lacteur fait ceci, puis le systme lui rpond cela, ce qui implique une raction de lacteur, et ainsi de suite. Le squencement temporel sera pris en compte plus tard,
notamment dans la description dtaille des cas (voir section 3.3).
Lintrt des cas dutilisation ne se limite pas au recueil des besoins. La description des cas
dutilisation peut servir de base de travail pour tablir les tests de vrification du bon fonctionnement du systme, et orienter les travaux de rdaction de la documentation lusage
des utilisateurs.
3.3 DESCRIPTION
Le diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de vue
des acteurs, mais nexpose pas de faon dtaille le dialogue entre les acteurs et les cas dutilisation.
EXEMPLE
10
UML 2
Lexemple de la figure 1.12 ne permet pas de savoir ce qui entre et ce qui sort du logiciel
bancaire : le retrait dargent se fait-il en euros ou en dollars ? Dans quel ordre les oprations
sont-elles effectues ? Faut-il choisir le montant du retrait avant de choisir le compte dbiter,
ou bien linverse ? Tous ces dtails sont des lments de spcification. Spcifier un produit,
cest le dcrire de la faon la plus prcise possible.
Chapitre
Figure 1.12
Diagramme de cas
dutilisation pour
une banque.
Retirer argent
Guichetier
Consulter compte
Systme
central
Les spcifications peuvent tre divises en deux catgories selon quelles sont fonctionnelles
ou techniques. Les spcifications fonctionnelles concernent les fonctions du systme, la
fonction de retrait dargent par exemple, tandis que les spcifications techniques permettent
de prciser le contexte dexcution du systme. Par exemple, le logiciel qui gre la distribution des billets doit tre compatible avec tel ou tel systme dexploitation, ou encore, un
retrait dargent doit se faire en moins de 5 secondes.
Les spcifications fonctionnelles dcoulent directement du diagramme de cas dutilisation.
Il sagit de reprendre chaque cas et de le dcrire trs prcisment. En dautres termes, vous
devez dcrire comment les acteurs interagissent avec le systme.
EXEMPLE
Figure 1.13
Description dun cas
dutilisation par
une squence
de messages.
partir du diagramme de cas dutilisation de lexemple prcdent, la figure 1.13 montre une
faon de dcrire les interactions entre le guichetier et le systme. On y voit clairement apparatre une squence de messages.
Le graphisme utilis fait partie du formalisme des diagrammes de squence (voir chapitre 3).
sd Retirer argent
: Systme
Guichetier
Systme
central
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
Chapitre
EXEMPLE
Dans le cas dun retrait dargent, des squences alternatives se produisent par exemple dans
les situations suivantes :
Le client choisit deffectuer un retrait en euros ou en dollars.
Le client a la possibilit dobtenir un reu.
Une exception se produit si la connexion avec le systme central de la banque qui doit
vrifier la validit du compte est interrompue.
La survenue des erreurs dans les squences doit tre signale de la faon suivante : appel de
lexception Y o Y est le nom de lexception.
La dernire partie de la description dun cas dutilisation est une rubrique optionnelle. Elle
contient gnralement des spcifications non fonctionnelles (ce sont le plus souvent des
spcifications techniques, par exemple pour prciser que laccs aux informations bancaires
doit tre scuris). Cette rubrique contient aussi dventuelles contraintes lies aux interfaces
homme-machine (par exemple, pour donner la possibilit daccder tous les comptes dun
utilisateur partir de lcran principal).
La squence nominale, les squences alternatives, les exceptions, etc., font quil existe une
multitude de chemins depuis le dbut du cas jusqu la fin. Chaque chemin est appel
scnario . Un systme donn gnre peu de cas dutilisation, mais, en gnral, beaucoup
de scnarios.
Remarque
Parfois, les utilisateurs ont du mal dcrire un cas sous une forme textuelle. Il est alors
judicieux de se servir dune autre forme de description, en utilisant un organigramme ou
encore en construisant des maquettes des interfaces homme-machine. Le dessin, mme sommaire, de laspect des crans des interfaces permet de fixer les ides ; il offre une excellente base pour la discussion avec le matre douvrage, qui le considre comme plus
parlant .
Conclusion
Les phases de recueil des besoins et dcriture des spcifications sont longues et fastidieuses.
Mais quand elles sont bien menes, elles permettent de lever toutes les ambiguts du cahier
des charges et de recueillir les besoins dans leurs moindres dtails. Les spcifications permettant dapprofondir les besoins (on parle dailleurs juste titre de spcifications techniques
des besoins), la frontire entre ces deux notions est floue.
Il nest pas question ce moment de la modlisation de limiter les besoins. Du ct du
matre duvre, la tendance est les limiter des fonctionnalits essentielles, tandis que
le matre douvrage, et surtout les utilisateurs, ont tendance en exprimer bien plus quil
nest possible den raliser. Le matre duvre doit faire preuve ici de patience et mener la
phase de spcifications de tous les besoins jusqu son terme. Cest ce moment seulement,
que des priorits sont mises sur les spcifications. Le matre duvre tente alors dagencer
les besoins de faon cohrente et fait plusieurs propositions de solutions au matre
douvrage, qui couvrent plus ou moins de besoins. UML ne propose rien pour mettre des
priorits sur les spcifications.
Le diagramme de cas dutilisation est un premier modle dun systme. Que savons-nous
sur le systme aprs avoir cr ce diagramme ? Sur le systme lui-mme, en interne, pas
grand-chose vrai dire. Cest encore une bote noire larchitecture et au mode de fonctionnement interne inconnus. Donc, a fortiori, ce stade, nous ne savons toujours pas comment le raliser. En revanche, son interface avec le monde qui lentoure est partiellement
connue : nous nous sommes placs du point de vue des acteurs pour dfinir les spcifications fonctionnelles. Il faut sattarder un instant sur lexpression partiellement connue
pour mesurer les limites du modle des cas dutilisation. Les spcifications fonctionnelles
disent ce que le systme doit faire pour les acteurs. En dautres termes, nous connaissons prcisment ce qui entre et ce qui sort du systme, mais, en revanche, nous ne savons toujours
pas comment raliser cette interface avec lextrieur.
14
UML 2
Chapitre
Lobjectif de cette phase de la modlisation est donc de clairement identifier les frontires du
systme et les interfaces quil doit offrir lutilisateur. Si cette tape commence avant la
conception de larchitecture interne du systme, il est en gnral utile, quand la rflexion est
suffisamment pousse, de poser les bases de la structure interne du systme, et donc dalterner analyse des besoins et bauche des solutions envisages.
Aux spcifications fonctionnelles sajoutent des spcifications techniques qui peuvent tre
vues comme des exigences pour la future ralisation.
Le prsent chapitre se poursuit par une srie de problmes corrigs. Le chapitre 2, quant
lui, prsente le diagramme des classes, qui permet de modliser la structure interne dun
systme.
Problmes
et exercices
La construction dun diagramme de cas dutilisation dbute par la recherche des
frontires du systme et des acteurs, pour se poursuivre par la dcouverte des cas
dutilisation. Lordre des exercices suit cette progression. Llaboration proprement
dite dun diagramme de cas dutilisation est illustre par plusieurs exercices.
Ce chapitre se termine par des tudes de cas de complexits croissantes.
EXERCICE 1
IDENTIFICATION
SIMPLES
16
UML 2
Chapitre
Le client est donc lacteur principal du systme. Or, bien souvent, le pompiste note le
numro dimmatriculation du vhicule du client dans le systme informatique. Le client
doit alors tre modlis deux fois : la premire fois en tant quacteur, et la seconde,
lintrieur du systme, pour y conserver un numro dimmatriculation.
Figure 1.14
Station-service
Le client comme
acteur du cas
Se servir .
Se servir
Client
2. Un acteur est caractris par le rle quil joue vis--vis du systme. Le pompiste, bien
qutant une personne diffrente du client, joue un rle identique quand il se sert de
lessence. Pour le cas Se servir , il nest pas ncessaire de crer un acteur supplmentaire reprsentant le pompiste.
3. La gestion de la station-service dfinit une nouvelle fonctionnalit modliser. Le grant
prend le rle principal ; cest donc un nouvel acteur (figure 1.15).
Figure 1.15
Station-service
Deux acteurs
pour deux rles.
Se servir
Client
Grer la station
Grant
Figure 1.16
Station-service
Relation
de gnralisation
entre acteurs.
Se servir
Client
Entretenir des vhicules
Grer la station
Chef
datelier
Exercices
Mcanicien
EXERCICE 2
RELATIONS
Figure 1.17
Station-service
Exemple dun
diagramme
erron.
Dcrocher le pistolet
Reposer le pistolet
Payer
Client
Il ne faut pas introduire de squencement temporel entre des cas dutilisation (cette notion
apparat lors de la description des cas). De plus, il est incorrect dutiliser un trait plein pour
relier deux cas. Cette notation est rserve aux associations entre les acteurs et les cas.
EXERCICE 3
RELATIONS
CAS INTERNES
Figure 1.18
Diagramme
incomplet des
cas dutilisation
dune agence
de voyages.
Agence de voyages
Rserver une
chambre dhtel
Rserver un taxi
Organiser un voyage
Agent de
voyages
2. Certains clients demandent lagent de voyages dtablir une facture dtaille. Cela donne
lieu un nouveau cas dutilisation appel tablir une facture dtaille . Comment
mettre ce cas en relation avec les cas existants ?
3. Le voyage se fait soit par avion, soit par train. Comment modliser cela ?
1.Le modlisateur a considr que lorganisation dun voyage est trop complexe pour tre
reprsente par un seul cas dutilisation. Il la donc dcompose en trois tches modlises par les trois cas dutilisation Rserver une chambre dhtel , Rserver un taxi et
Rserver un billet de train . Ces trois tches forment des transactions suffisamment
isoles les unes des autres pour tre des cas dutilisation. De plus, ces cas sont mutuellement
18
UML 2
Chapitre
indpendants. Ils constituent des cas internes du systme car ils ne sont pas relis directement un acteur.
Figure 1.19
Agence de voyages
Relations dinclusion
entre cas dutilisation.
Rserver une
chambre dhtel
inclut
Rserver un taxi
inclut
inclut
Organiser un voyage
Agent de
voyages
Figure 1.20
Agence de voyages
Relation dextension
entre cas dutilisation.
Rserver une
chambre dhtel
Rserver un taxi
inclut
inclut
inclut
Organiser un voyage
Agent de
voyages
Points dextension :
tablirUneFacture
Condition : { la demande du
client}
Point dextension : tablirUneFacture
tend
Exercices
3. Il y a maintenant deux cas particuliers : le voyage se fait en train ou en avion. Ces cas particuliers sont modliss par les cas Rserver un billet de train et Rserver un billet
davion . Ceux-ci sont lis un cas plus gnral appel Rserver un titre de transport .
Figure 1.21
Agence de voyages
Relation de
gnralisation entre
cas dutilisation.
Rserver une
chambre dhtel
inclut
Rserver un taxi
inclut
Rserver un titre
de transport
inclut
Organiser un voyage
Points dextension :
tablirUneFacture
Agent de
voyages
Rserver un billet
de train
tend
Rserver un billet
davion
EXERCICE 4
IDENTIFICATION
20
UML 2
Chapitre
faut rester au niveau des grandes fonctions et penser en termes de transactions (une transaction est une squence doprations qui fait passer un systme dun tat cohrent initial
un tat cohrent final).
Il ny a donc que deux cas : Emprunter une vido et Restituer une vido (figure 1.22).
Figure 1.22
Diagramme de cas
dutilisation dun
distributeur de
cassettes vido.
Client
Nom de lacteur
Client
Rle
Pour dcrire le cas Emprunter une vido , imaginons un scnario possible. Le client
introduit sa carte. Il doit ensuite pouvoir choisir une vido. Quels sont les critres de choix ?
Lnonc ne prcise pas ces critres. Ce problme arrive frquemment en situation relle.
Le matre douvrage dans un projet informatique de cette ampleur est bien souvent le propritaire du magasin de location. Il sait rarement rdiger un cahier des charges. Cest le rle
du matre duvre dobliger le matre douvrage bien formuler ses besoins. Choisir une
vido peut tre complexe : la recherche se fait-elle par genres, par titres ou par dates de sortie des films en salles ? Si la recherche se fait par genres, quels sont-ils ? Rechercher un film
semble plus complexe quon ne limaginait au premier abord. De plus, cette fonctionnalit
peut tre isole de la location proprement dite, qui concerne plutt la gestion de la carte.
Ces remarques incitent crer le cas supplmentaire Rechercher une vido . Lemprunt
dune vido inclut sa recherche. Une relation dinclusion intervient donc entre les cas
Emprunter une vido et Rechercher une vido , comme le montre la figure 1.23.
Figure 1.23
Diagramme de cas
dutilisation
complt par la
recherche dune
vido.
inclut
Rechercher une vido
Client
Le succs dUML en tant que langage de modlisation sexplique, entre autres, par le fait
quil oblige le modlisateur poser les bonnes questions au bon moment ; la modlisation vient peine de commencer que dj des questions se posent. Il faut cependant
veiller rester au niveau du recueil des besoins et des spcifications et ne faire aucun
choix de conception du systme. Il faut se contenter de dcrire les fonctions du systme
sans chercher savoir comment les raliser.
Exercices
EXERCICE 5
DESCRIPTION DUN
CAS DUTILISATION
Dcrivez sous forme textuelle les cas dutilisation Emprunter une vido et Rechercher
une vido du diagramme prsent la figure 1.23. La recherche dune vido peut se faire
par genres ou par titres de film. Les diffrents genres sont action, aventure, comdie et
drame. Quand une liste de films saffiche, le client peut trier les films par titres ou par dates
de sortie en salles.
22
UML 2
Chapitre
Exercices
24
UML 2
Chapitre
EXERCICE 6
REGROUPEMENT
Modlisez laide dun diagramme de cas dutilisation un systme informatique de pilotage dun robot distance.
Le fonctionnement du robot est dcrit ci-aprs.
Un robot dispose dune camra pour filmer son environnement. Il peut avancer et reculer
grce un moteur lectrique capable de tourner dans les deux sens et commandant la
rotation des roues. Il peut changer de direction car les roues sont directrices. Il est pilot
distance : les images prises par la camra sont envoyes vers un poste de tlpilotage. Ce
dernier affiche lenvironnement du robot sur un cran. Le pilote visualise limage et utilise
des commandes pour contrler distance les roues et le moteur du robot. La communication entre le poste de pilotage et le robot se fait via des ondes radio.
Le systme informatique est compos de deux sous-systmes :
le sous-systme du robot ;
le sous-systme du poste de tlpilotage.
Do lide de faire deux diagrammes de cas dutilisation un par sous-systme et de
placer chaque diagramme dans un paquetage. La figure 1.24 montre deux paquetages : un
pour le sous-systme du robot et un pour le sous-systme du poste de pilotage. La relation
de dpendance entre les paquetages signifie que le systme de pilotage utilise le robot.
Reprsentation
du systme de
tlpilotage dun
robot par des
paquetages.
Robot
Systme de pilotage
Commenons par modliser le robot. Ses capteurs (camra, moteur et roues) sont lextrieur du systme informatique et ils interagissent avec lui. Ils correspondent a priori la
dfinition dacteurs. Reprenons chaque capteur pour ltudier en dtail :
Le systme doit demander la capture dune image la camra et raliser la capture. La
camra est donc un acteur associ un cas dutilisation appel Capturer images
(figure 1.25).
Le sens de rotation du moteur peut tre command. Le moteur est lacteur ; il est associ
un cas appel Commander le moteur .
La direction des roues peut tre modifie, do la cration du cas dutilisation Commander la direction reli lacteur Direction.
Pour pouvoir envoyer les images au poste de pilotage et recevoir les commandes en retour, il
faut un capteur supplmentaire, metteur/rcepteur dondes radio. Le systme informatique ne va pas se charger denvoyer et de recevoir des ondes radio cest le rle des priphriques dmission et de rception mais il doit soccuper du transcodage des images pour
les envoyer via des ondes. Le systme informatique doit-il raliser lui-mme ce transcodage
ou bien les fonctions de transcodage sont-elles fournies avec les priphriques ? Pour
rpondre cette question, il faudrait raliser une tude de march des metteurs/rcepteurs
Exercices
Figure 1.24
radio. Cela dpasse le cadre de cet ouvrage. Considrons que le systme informatique intervient, ne serait-ce que pour appeler des fonctions de transcodage. Cela constitue un cas
dutilisation. Deux flots dinformations distincts doivent tre envoys au poste de pilotage :
des images et des commandes. Cette dernire remarque incite crer deux cas dutilisation :
un pour mettre des images ( Envoyer les images ) et un pour recevoir les commandes
( Recevoir les commandes ). En outre, selon lutilisation du robot, la transmission des
images seffectue plus ou moins vite : si les dplacements du robot sont rapides par exemple,
la transmission doit ltre aussi. Ces contraintes de ralisation font partie des spcifications
techniques du systme. Elles doivent figurer dans la description textuelle du cas dutilisation. Sur le diagramme de cas dutilisation, il est possible de placer une relation dextension
entre les cas Envoyer les images et Capturer images , en indiquant comme point
dextension quel moment de la capture et quelle frquence sont envoyes les images.
Nom de lacteur
Camra
Direction
Moteur
metteur
Rcepteur
Rle
Figure 1.25
Diagramme de cas
dutilisation du
robot.
Capturer images
Points dextension :
envoiImage
Camra
Condition : {ds quune image
complte a t capture}
Point dextension : envoiImage
tend
Envoyer les images
metteur
Recevoir les commandes
Points dextension :
- commandeMoteur
- commandeDirection
Commander le moteur
Moteur
26
UML 2
Rcepteur
tend
Commander la direction
Direction
Chapitre
Intressons-nous prsent au sous-systme de pilotage. La figure 1.26 prsente le diagramme de cas dutilisation, qui se dduit sans problme du diagramme prcdent.
Nom de lacteur
Pilote
metteur
Rcepteur
Rle
Figure 1.26
Diagramme de cas
dutilisation du
systme de pilotage.
tend
Afficher les images
Tlpiloter
Pilote
Points dextension :
envoiCommande
tend
Envoyer des commandes
metteur
RELATIONS ENTRE
DUTILISATION
Modlisez laide dun diagramme de cas dutilisation une mdiathque dont le fonctionnement est dcrit ci-aprs.
Une petite mdiathque na quune seule employe qui assume toutes les tches :
la gestion des uvres de la mdiathque ;
Exercices
EXERCICE 7
Bibliothcaire
Gestionnaire des
contentieux
Administrateur
28
UML 2
Rle
Chapitre
Figure 1.27
Une mdiathque
Diagramme de cas
dutilisation dune
mdiathque.
Grer les
uvres
inclut
Rechercher
les uvres
inclut
Grer les
adhrents
Bibliothcaire
inclut
Sauthentifier
inclut
Rechercher
les adhrents
inclut
inclut
inclut
Grer les
emprunts
Administrateur
Grer les contentieux
Gestionnaire des
contentieux
Points dextension :
procdureJudiciaire : {pas
chaque fois que le gestionnaire
utilise le cas mais
une fois par mois}
tend
Dclencher une
procdure judiciaire
IDENTIFICATION
Modlisez laide dun diagramme de cas dutilisation le systme informatique qui gre la
distribution dessence dans une station-service. Le fonctionnement de la distribution de
lessence est dcrit ci-aprs.
Avant de pouvoir tre utilise par un client, la pompe doit tre arme par le pompiste. La
pompe est ainsi apprte, mais ce nest que lorsque le client appuie sur la gchette du pistolet de distribution que lessence est pompe. Si le pistolet est dans son tui de rangement
et si la gchette est presse, lessence nest pas pompe. La distribution de lessence un
client est termine quand celui-ci remet le pistolet dans son tui. La mesure de lessence
distribue se fait par un dbitmtre.
Quatre types de carburants sont proposs : diesel, sans plomb avec un indice doctane de
98, sans plomb avec un indice doctane de 95, et plomb.
Le paiement peut seffectuer en espces, par chque ou par carte bancaire. En fin de journe, les transactions sont archives.
Le niveau des cuves ne doit pas descendre en dessous de 5 % de la capacit maximale.
Sinon les pompes ne peuvent plus tre armes.
Exercices
EXERCICE 8
Pour un systme complexe, il vaut mieux se concentrer sur les fonctions essentielles puis
passer aux cas moins importants.
Figure 1.28
Se servir de
lessence : solution
avec un cas unique.
Se Servir
Client
Pompiste
Figure 1.29
Se servir de
lessence : solution
avec deux cas.
inclut
Se Servir
Client
Armer pompe
Pompiste
30
UML 2
Chapitre
de la cuve au pompiste, il faut relier lacteur Pompiste au cas Vrifier niveau cuve pour
armement . Le pompiste est inform que le niveau est trop bas, mais la vrification doit
tre automatique pour que les pompes soient ventuellement bloques. Une relation
dinclusion intervient donc entre les cas Armer pompe et Vrifier niveau cuve pour
armement (figure 1.31).
Comment reprsenter cela dans un diagramme de cas dutilisation ? Une premire solution
(prsente la figure 1.31) consiste crer un cas gnral appel Payer , et trois cas particuliers relis par une relation de spcialisation au cas Payer . Chacun des trois cas reprsente
un mode de paiement.
Une autre solution (prsente la figure 1.30) repose sur un cas, Payer , qui se droule
jusquau choix du mode de paiement, puis, selon le type de paiement, un des trois modes
est activ ( Payer en espces , Payer par chque ou Payer par carte bancaire ). Ces
trois cas sont typiquement des extensions du cas Payer , o lextension est soumise
condition.
Exercices
Pour un paiement par carte bancaire, la banque de la station-service ralise une transaction avec la banque du client. Les seules informations conserver dans le systme informatique de la station-service sont le montant, la date de la transaction et le mode de
paiement.
Figure 1.30
Utilisation
de relations
dextension
pour modliser
le paiement.
Payer
Points dextension :
- paiementEspce,
- paiementParChque
- paiementParCarteBancaire
{les trois extensions sexcluent mutuellement et
une extension intervient au tout dbut du
paiement}
Condition : {si le client choisit de payer
par carte bancaire}
Point dextension : paiementParCarteBancaire
tend
tend
tend
Payer en espces
Payer par
chque
Ces deux solutions sont possibles. Il est difficile de dire laquelle est la meilleure. La suite de
lexercice se fonde arbitrairement sur la reprsentation avec des relations de gnralisation
(figure 1.31). Le modlisateur se retrouve rgulirement face ce dilemme. La rponse est
souvent la mme : peu importe la faon de modliser un systme du moment que le modle
est correct un modle est correct sil montre une solution qui satisfait le matre douvrage
ainsi que les futurs utilisateurs du systme.
32
UML 2
Chapitre
calcul, on peut ajouter une relation dextension entre les cas Se servir et Payer , avec
un point dextension qui prcise le moment o le calcul du montant intervient, comme le
montre la figure 1.31. Le paiement peut aussi intervenir avant de se servir. Dans ce cas, il est
possible dajouter un deuxime point dextension (voir la figure 6.17 du chapitre 6).
Client
Pompiste
Capteur niveau cuve
pour armement
Capteur niveau cuve
pour remplissage
Timer
Banque
Rle
Exercices
Nom de lacteur
Figure 1.31
Diagramme de cas
dutilisation dune
station-service.
Station-Service
inclut
Se servir
Client
inclut
Armer pompe
Points dextension :
paiement : { la fin du
cas se servir }
Pompiste
tend
Payer
Payer en espce
Archiver les
transactions
34
UML 2
Chapitre
Diagramme
de classes
1.
2.
3.
4.
5.
6.
7.
8.
36
36
44
45
54
54
56
57
Problmes et exercices
1. Proprits dune classe ................... 61
2. Classe strotype ......................... 63
3. Nom dune classe .......................... 64
4. Dfinition dun message asynchrone 64
5. classe active .................................. 65
6. Contrainte sur une classe................ 65
7. Classe paramtrable ...................... 66
8. Relations simples............................ 66
9. Ralisation dune interface ............. 68
10. Utilisation dune interface ............... 69
11. Relations ....................................... 70
12. Hritage ........................................ 71
13. Hritage ....................................... 73
14. Diagramme dobjets ...................... 75
15. Patron de conception objets
composites .................................. 75
16. Application htelire ...................... 76
17. Application bancaire ..................... 77
18. Rservation de billets davion ......... 79
19. Patron Bridge .......................... 81
20. Patron Adapteur ..................... 82
21. Organisation du langage UML ....... 84
35
(1)
EXEMPLE
La figure 2.1 modlise une entreprise laide de cinq classes : Entreprise, Ser vice, Bureau,
Employ et Sige. Les classes possdent ventuellement des attributs (la classe Ser vice est
caractrise par un nom, un employ se caractrise par un nom et un identifiant). Elles
contiennent aussi des oprations (demandeCongs pour la classe Employ). Les classes sont
relies entre elles par des associations symbolises par des traits. Plusieurs types dassociations existent, qui se reprsentent diffremment (par des losanges, des flches).
Figure 2.1
Exemple de
diagramme
de classes.
Entreprise
Une agrgation
1..*
utilise
Bureau
nom : String
Une contrainte
entre relations
{subset}
1..* membre
Opration
1..*
1..*
Service
1 chef
Sige
Employ
nom : String
identifiant : Number
demandeCongs() :bool
Pour crer un diagramme de classes, vous avez besoin dabord de dfinir les classes et leurs
responsabilits, les paquetages ainsi que les relations (association, composition, agrgation,
hritage, dpendance) possibles entre ces lments. Dautres lments peuvent galement
apparatre dans le diagramme de classes, comme les objets et les interfaces.
Nous prsenterons, dans ce chapitre, les lments indispensables pour bien russir la modlisation du diagramme de classes. Commenons par dcrire la gense des classes.
(2)
De lobjet la classe
Beaucoup dobjets naturels ou informatiques se ressemblent tant au niveau de leur description que de leur comportement. Afin de limiter la complexit de la modlisation, vous pouvez regrouper les objets ayant les mmes caractristiques en classes. Ainsi, une classe dcrit
les tats (ou attributs) et le comportement haut niveau dabstraction dobjets similaires.
De cette faon, vous pouvez dfinir la classe comme le regroupement des donnes et des
traitements applicables aux objets quelle reprsente, comme le montre la figure 2.2. Dans
36
UML 2
Chapitre
lapproche objet, il faut, avant tout, pouvoir identifier les objets, les diffrencier des autres
avant de les dfinir. Lidentit associe une classe est essentielle car elle conditionne la perception des structures et des comportements des objets quelle reprsente.
EXEMPLE
La figure 2.2 modlise la situation suivante : Jean est un homme clibataire g de 40 ans et
Anne est une femme marie.
Figure 2.2
Reprsentation UML
de la classe
Personne.
Personne
prnom : String
dateNaissance : Date
sexe : {M,F}
calculAge() : Integer
renvoyerNom() : String
Dans cet exemple, on regroupe les similarits entre les deux objets Jean et Anne dans une
classe Personne. Les informations qui apparaissent dans lexemple sont le prnom, le sexe et
la situation matrimoniale. De ce fait, la classe Personne est munie des attributs suivants :
prnom, sexe et situation matrimoniale. Lge est une donne qui change. On le calcule en
faisant la diffrence entre la date courante et la date de naissance. On parle dans ce cas
dattributs drivs. Cette dernire analyse permet de complter la description de la classe en
ajoutant lattribut date de naissance et une opration permettant le calcul de lge.
En UML, la classe Personne est reprsente graphiquement par un rectangle divis en plusieurs
compartiments. Le premier compartiment indique le nom de la classe, le deuxime ses attributs, le troisime ses mthodes. En fonction de ltat de la modlisation et des lments
mettre en valeur, dautres compartiments, comme les compartiments de responsabilits et
dexceptions, peuvent tre ajouts la description de la classe.
Dfinition
Une classe est une description dun ensemble dobjets ayant une smantique, des attributs,
des mthodes et des relations en commun. Un objet est une instance dune classe.
Remarque
Dans les langages de programmation objet, on confond souvent la notion dinstance et la
notion dobjet alors que la premire est plus gnrale que la seconde. Un objet est une instance dune classe. Mais une instance peut tre une instance de plusieurs autres lments
du langage UML. Par exemple, un lien est une instance dune association.
Un objet dune classe doit avoir des valeurs uniques pour tous les attributs dfinis dans la
classe et doit pouvoir excuter (sans exception) toutes les mthodes de la classe.
Diagramme de classes 37
2.1 CLASSE
ET MTHODE ABSTRAITES
Dans votre environnement quotidien, vous faites abstraction dune quantit de dtails qui
permettent davoir une vision globale et gnralisante du monde. Cette notion dabstraction se retrouve, au sein de lapproche objet, dans les classes et les mthodes abstraites.
Imaginez une classe modlisant une figure gomtrique. Toutes les figures gomtriques
doivent pouvoir tre dessines. Ajoutez cette classe une opration qui permet de dessiner
une figure. ce stade de la modlisation, vous tes dans lincapacit de dfinir limplmentation de cette opration. On lappelle mthode abstraite .
Dfinition
Une mthode est dite abstraite lorsquon connat son entte mais pas la manire dont elle
peut tre ralise. Une classe est dite abstraite lorsquelle dfinit au moins une mthode
abstraite ou lorsquune classe parent contient une mthode abstraite non encore ralise.
EXEMPLE
Chaque lment graphique du langage UML est reprsent par une figure gomtrique.
Les caractristiques communes de ces figures gomtriques sont le type de trait utilis pour les
dessiner et la possibilit de les dessiner.
Il est vident que si nous ne connaissons pas la forme exacte de la figure dessiner nous ne
pouvons pas le faire. On dira de ce fait que la mthode dessiner est abstraite dans la classe
FigureGomtrique et la classe FigureGomtrique est donc elle-mme abstraite. Cependant,
si on dfinit un rectangle comme particularisation de la figure gomtrique alors le rectangle pourra tre dessin et la mthode dessiner fournit ainsi un corps lopration dessiner
qui sera dite concrte. Une classe abstraite contient au moins une mthode abstraite. La
figure 2.3 donne un exemple dune classe abstraite contenant une mthode abstraite et les
consquences de cette proprit sur les classes drives. En particulier, une classe qui drive
dune classe abstraite doit implmenter toutes les mthodes abstraites sinon elle reste aussi
abstraite.
Figure 2.3
Exemple de classe
abstraite.
2.2 NOM
FigureGomtrique{abstract}
Rectangle
typeTrait : Trait
dessiner()
dessiner() {abstract}
FigurePleine{abstract}
Implmentation de
lopration dessiner
DE LA CLASSE
La modlisation dune classe passe par plusieurs tapes auxquelles participent ventuellement plusieurs intervenants. Par exemple, une classe peut tre extraite des cas dutilisation
par un analyste programmeur, et aprs analyse et factorisation opres par un ingnieur de
dveloppement, tre mise dans un paquetage prdfini et considre comme valide. Pour
distinguer ces tapes de modlisation, vous devez ajouter au nom de la classe toutes les
informations pertinentes.
38
UML 2
Chapitre
Les informations les plus souvent utilises sont le nom de la classe, les paquetages qui la
contiennent, le strotype ventuel de la classe, lauteur de la modlisation, la date, le statut
de la classe (elle est valide ou pas). Par dfaut, une classe est considre comme concrte.
Sinon, ajoutez le mot-cl abstract pour indiquer quelle est abstraite.
Spcification
La syntaxe de base de la dclaration dun nom dune classe est la suivante :
[strotype]
[<NomDuPackage1>:::<NomDuPaquetage N>::]
<NomDeLaClasse>[{[abstract],[auteur],[tat],}]
Figure 2.4
NomSimple
Quelques exemples
de noms de classe.
Personne
nomPackage::NomSimple
java::util::Vector
FigureGomtrique
{abstract,
auteur : osmani
tat : valide}
Controleur
LeGardien
Remarque
Le nom de la classe doit voquer le concept dcrit par la classe. Il commence par une
majuscule. Quand le nom est compos, chaque mot commence par une majuscule et les
espaces blancs sont limins.
En UML 2, les guillemets (comme dans lexemple de contrleur ser vent, la fois, indiquer les strotypes et les mots-cls du langage. Dans les versions prcdentes dUML, ils
ne servent qu dsigner les strotypes.
2.3 ENCAPSULATION
Un principe de conception largement utilis (mme au-del de lapproche objet) consiste
protger le cur dun systme des accs intempestifs venant de lextrieur. Cest le principe
du coffre-fort : seuls les dtenteurs dune clef peuvent louvrir. Transpos la modlisation
objet, ce principe sappelle lencapsulation. Il permet de dfinir les droits daccs aux
proprits dun classeur. UML dfinit quatre niveaux dencapsulation dune proprit dune
classe.
Une proprit peut tre visible partout. Dans ce cas, elle est dite publique . Si elle nest
visible qu lintrieur dune classe, elle est dite prive . En utilisant le principe de
lhritage, les descendants dune classe peuvent avoir un accs privilgi aux proprits des
classes parentes. Une classe parent qui souhaite autoriser laccs une de ses proprits
ses seuls descendants doit dfinir cette proprit comme protge . Lors de la modlisation dapplications complexes, les classes sont regroupes dans des paquetages ddis des
domaines ou activits particulires. Le langage Java, par exemple, propose un paquetage
ddi aux entres/sorties (java.io), un paquetage contenant les utilitaires (java.util), etc. La
visibilit par dfaut dune classe et de ses proprits se limite au paquetage dans lequel elle
est dfinie.
Diagramme de classes 39
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.
Figure 2.5
Paquetage1
Visibilit
des proprits
dune classe.
+ Classe1
-attribut1
attribut2
+attribut3
#attribut4
+ Classe3
accessibles
attribut2
Paquetage2
+ Classe2
accessibles
attribut2
attribut3
import
+ Classe4
accessibles
attribut3
attribut4
attribut3
2.4 ATTRIBUTS
DE LA CLASSE
Les attributs dfinissent les informations quune classe ou un objet doivent connatre. Ils
reprsentent les donnes encapsules dans les objets de cette classe. Chacune de ces informations est dfinie par un nom, un type de donnes et une visibilit. Le nom de lattribut
doit tre unique dans la classe.
En UML, les attributs correspondent des instances de classes dj prdfinies. Pour des
raisons de programmation, ce principe nest pas toujours respect par les langages de programmation objet, comme en tmoigne lexistence de types de base (int, float,) dans les
langages Java et C++.
EXEMPLE
40
UML 2
La classe Htel possde un nom et un propritaire. Un htel contient entre une et deux cents
chambres. Le propritaire de lhtel nest pas visible partir des autres classes. Par ailleurs,
lhtel respecte les textes de lois communs tous les htels.
Chapitre
Pour pouvoir modliser la classe Htel, vous avez besoin de connatre les classes String,
Chambre, Personne et TexteDeLoi. Vous avez galement besoin de savoir modliser la multiplicit (entre une et deux cents chambres) et la possibilit dassocier une proprit la
classe, et non linstance de la classe (texte de loi).
Figure 2.6
Classe Htel
mettant en vidence
les modificateurs
daccs, la multiplicit et les attributs
de classes.
Htel
+ chambres : Chambre[1..200]
+ nom : String
-propritaire : Personne
+ texte : TexteDeLoi
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)]
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
2.5 MTHODES
ET OPRATIONS
Le comportement dun objet est modlis par un ensemble de mthodes. Chaque mthode
correspond une implmentation bien prcise dun comportement.
En gnral, lors de la conception des classes, on commence par donner les en-ttes des
mthodes sans prciser la manire de les implmenter. Cependant, avant toute instanciation
dune classe, il est ncessaire de donner une implmentation possible de ses mthodes. videmment, pour chaque en-tte, plusieurs implmentations sont possibles.
UML distingue la spcification dune mthode, qui correspond la dfinition de son entte, de son implmentation. La spcification est appele opration et limplmentation
est appele mthode . Vous pouvez donc associer plusieurs mthodes une opration,
comme le montre lexemple suivant :
EXEMPLE
Soit la factorielle de n (n!), une fonction dfinie de faon inductive pour tout entier positif n
par : 0! = 1 et n! = n * (n 1)!. On dit que : + fact (n : integer) : integer est une opration et
que
+fact(n:integer):integer
{
if (n==0 || n==1) renvoyer (1);
renvoyer (n * fact(n-1); *= i;
}
et
+fact(n:integer):integer
{
int resultat = 1;
pour (int i = n; i>0; i--) resultat*=i;
renvoyer resultat;
}
Dans une classe, une opration (mme nom et mmes types de paramtres) doit tre unique. Quand le nom dune opration apparat plusieurs fois avec des paramtres diffrents,
on dit que lopration (et/ou la mthode) est surcharge. En revanche, il est impossible que
deux oprations ne se distinguent que par la valeur retourne.
Spcification
La spcification dune opration contient les types des paramtres et le type de la valeur
de retour. UML 2 ne prvoit pas de type de la valeur de retour dune opration. Mais lutilit de ce paramtre nous conduit garder la syntaxe dUML 1.5.
La syntaxe de la dclaration est la suivante :
<modificateur daccs><nomDeLaMthode ([paramtres])>:
[<valeurRenvoye>][{proprit}]
42
UML 2
Chapitre
2.6 OPRATIONS
DE CLASSE
Comme pour les attributs de classe, vous aurez peut-tre besoin de dfinir une opration
qui ne dpend pas des valeurs propres de chaque objet, mais qui porte sur les attributs de la
classe ou uniquement sur les paramtres de lopration. Dans ce cas, lopration devient
proprit de la classe, et non de ses instances. Elle na pas accs aux attributs des objets de la
classe. Graphiquement, une mthode de classe est souligne.
EXEMPLE
Lexcution dune application cre plusieurs objets de la classe Processus. Pour affi cher le
nombre dobjets de cette classe disponible simultanment dans le systme, vous pouvez ajouter un attribut de classe qui compte le nombre de processus (lors de la cration et de la destruction des objets) et une mthode qui affiche ce nombre.
Figure 2.7
Opration de classe
et strotype
dopration.
Processus
+ nom : String
- nombreProc : integer
constructeurs
+ afficheNombreProc() : void
2.7 COMPARTIMENTS
Le processus de modlisation se fait pas pas. De ce fait, lors de la construction des classes,
les caractristiques ne sont pas toutes connues de faon prcise. Pour prendre en compte
cette construction incrmentale, vous ajoutez des informations complmentaires aux classes telles que les responsabilits, les contraintes gnrales, les exceptions, etc.
Pour ce faire, vous disposez de deux nouveaux compartiments dans la description graphique dune classe, savoir le compartiment des responsabilits et celui des exceptions. Si la
modlisation concerne une application informatique implmenter, ces deux compartiments disparatront quand vous arriverez la phase de gnration de code ; ils seront
transforms en un ensemble dattributs et de mthodes.
EXEMPLE
Diagramme de classes 43
Figure 2.8
Compartiment
de responsabilit
et dexception.
Connexion
+ip : Byte [4]
Respecter la charte
Possder une adresse IP
+ seConnecter( )
exceptions
Connexion impossible
(3)
Interface
Le rle dune interface est de regrouper un ensemble doprations assurant un service cohrent offert par un classeur et une classe en particulier.
Le concept dinterface est essentiellement utilis pour classer les oprations en catgories
sans prciser la manire dont elles sont implmentes. La dfinition dune interface ne spcifie pas contrairement celle dune classe une structure interne et ne prcise pas les
algorithmes permettant la ralisation de ses mthodes. Elle peut prciser les conditions et
les effets de son invocation. Une interface na pas dinstances directes. Pour tre utilise,
elle doit tre ralise par un classeur, qui est souvent une classe. Une interface peut tre spcialise et/ou gnralise par dautres interfaces.
La ralisation dune interface par une classe est reprsente graphiquement par un trait discontinu qui se termine par une pointe triangulaire. Une manire simplifie de reprsenter
une interface consiste placer un petit cercle, souvent appel lollipop (sucette), rattach
la classe qui ralise linterface, comme le montre la figure 2.9.
Spcification
Une interface est dfinie comme une classe, avec les mmes compartiments. Les principales
diffrences sont la non-utilisation du mot-cl abstract, car linterface et toutes ses mthodes
sont, par dfinition, abstraites, et lajout du strotype interface avant le nom de linterface.
Figure 2.9
Deux manires de
reprsenter linterface
et le lien avec la classe
qui la ralise. Linterface
NomInterface est
ralise par la classe
NomClasse.
EXEMPLE
44
UML 2
interface
NomInterface
NomClasse
NomInterface
NomClasse
Selon des critres dfinir a posteriori, les objets de la classe Htel et les objets de la classe
Personne doivent tre comparables. Lopration qui compose linterface et permet la comparaison entre les instances des classes Personne et Htel doit tre la mme. Cependant, les
critres de comparaison sont, videmment, diffrents. La figure 2.10 modlise cette interface
commune, ralise par chacune des classes drives.
Chapitre
Figure 2.10
Les classes Htel
et Personne ralisent
linterface Comparable.
realize
Htel
Personne
interface
Comparable
CompareTo() : Integer
Htel
Comparable
realize
Personne
Comparable
Quand une classe dpend dune interface (interface requise) pour raliser ses oprations,
elle est dite classe cliente de linterface . Graphiquement, cela est reprsent par une relation de dpendance entre la classe et linterface. Une notation lollipop quivalente est aussi
possible, comme le montre la figure 2.11.
Figure 2.11
La classe NomClasse
dpend de linterface
NomInterface.
interface
NomInterface
NomClasse
NomInterface
use
NomClasse
(4)
4.1 MULTIPLICIT
Dans le mtamodle UML, la multiplicit est dfinie par un ensemble non vide dentiers
positifs lexclusion dun ensemble ne contenant que zro {0}. Elle apparat chaque extrmit dune relation et indique le nombre dobjets de la classe apparaissant cette extrmit
pouvant sassocier un seul et unique objet de la classe apparaissant lautre extrmit.
EXEMPLE
Figure 2.12
Exemple de
multiplicit.
Un objet de la classe Voiture est compos dau moins trois roues et dau plus dix roues. Pour
ajouter cette information dans le diagramme de classes, on ajoutera le lien de composition
entre les classes Voiture et Roue et on ajoutera la multiplicit [3..10] du ct de la classe
Roue.
Voiture
3..10
Roue
Diagramme de classes 45
Cette relation entre deux classes indique quun objet de la classe Voiture doit tre compos
de trois dix objets de la classe Roue.
Les principales multiplicits normalises sont plusieurs (*), exactement n (n), au
minimum n (n..*) et entre n et m (n..m). Il est aussi possible davoir un ensemble
dintervalles convexes: n1..n2, n3..n4 ou n1..n2, n5, n6..*, etc.
4.2 ASSOCIATION
Une association reprsente une relation smantique entre les objets dune classe. Elle est
reprsente graphiquement par un trait plein entre les classes associes. Elle est complte
par un nom qui correspond souvent un verbe linfinitif, avec une prcision du sens de
lecture en cas dambigut. Parfois, un strotype qui caractrise au mieux lassociation
remplace le nom. Chaque extrmit de lassociation indique le rle de la classe dans la
relation et prcise le nombre dobjets de la classe qui interviennent dans lassociation.
Quand linformation circule dans un sens uniquement, le sens de la navigation est indiqu
lune des extrmits. UML 2 donne, aussi, la possibilit dexprimer la non-navigabilit
dune extrmit par lajout dune croix sur lassociation, comme le montre la figure 2.15.
Figure 2.13
Lassociation
et ses diffrents
ornements.
EXEMPLE
multiplicit
nom
multiplicit
rle
rle
Association
Une personne travaille pour une et une seule entreprise. Lentreprise emploie au moins une
personne. Lentreprise est lemployeur des personnes qui travaillent pour elle et une personne
a un statut demploy dans lentreprise.
Figure 2.14
Personne
Rle, multiplicit et
nom de lassociation
sans restriction de
navigabilit.
EXEMPLE
1..*
travailler pour
employ
Entreprise
employeur
Figure 2.15
Association oriente.
Polygone
dfini par
3..*
#sommet
Point
46
UML 2
Chapitre
Cependant, la classe Point ne doit pas avoir dattribut de type Polygone, ni de mthode qui
renvoie les polygones dfinis par ce point.
Figure 2.16
Polygone
Exemple de
modlisation
de la navigation
par des attributs.
#sommets : Point[3..*]
Lassociation la plus utilise est lassociation binaire (reliant deux classeurs). Parfois, les
deux extrmits de lassociation pointent vers le mme classeur. Dans ce cas, lassociation
est dite rflexive .
Figure 2.17
a le mme age
Exemples
dassociations
rflexives.
+parent
2
Personne
+enfant
*
*
amie de
La premire est asymtrique (parent de), la deuxime est symtrique et non transitive (amie
de) et la dernire est la fois symtrique et transitive. Il est conseill dajouter les rles des
extrmits dans le cas des relations asymtriques.
Lassociation rflexive entre classes a pour principale fonction de structurer les objets dune
mme classe. Quand lassociation est asymtrique, elle permet de crer une hirarchie entre
les objets sinon elle partitionne les instances de la mme classe. Quand lassociation est la
fois symtrique et transitive, les objets sont regroups en classes dquivalence. Dans lexemple de la figure 2.17, lassociation rflexive parent de permet de crer un arbre (hirarchie) gnalogique entre les instances de la classe Personne. La relation symtrique et
transitive a le mme ge permet de regrouper les objets de la classe Personne en classes
dquivalence (toutes les personnes ayant le mme ge appartiendront au mme groupe).
Remarque
De nombreux concepts sont dfinis autour de la notion dassociation. Nous avons slectionn
cinq concepts qui nous paraissent importants : lassociation avec contraintes, lassociation
drive, la classe-association, la classe reprsentante (ou qualifiante) et lassociation n-aire
(n > 2).
4.3 ASSOCIATION
AVEC CONTRAINTES
Une association entre classes indique que des proprits sont changes ou partages par les
classes relies. Lajout de contraintes une association ou bien entre associations apporte
plus dinformations car cela permet de mieux prciser la porte et le sens de lassociation.
Les contraintes sont mises entre accolades et peuvent tre exprimes dans nimporte quel
langage. Cependant, il est prfrable dutiliser le langage OCL (Object Constraint Language).
Le premier exemple de la figure 2.18 montre une association entre un polygone et ses sommets en prcisant que les sommets dun polygone sont ordonns, ce qui permet de rduire
1 le nombre de figures pouvant tre dessines partir de n sommets. Le deuxime exemple
montre une contrainte entre deux associations : elle indique que le responsable du dpartement fait ncessairement partie du personnel.
Diagramme de classes 47
Figure 2.18
Polygone
Exemples
dassociations
dont la porte
est restreinte par
les contraintes
du langage OCL.
dfini par
3..*
Point
#sommet
{ordered}
1
Dpartement
emploie
Personne
{subset}
1
4.4 ASSOCIATION
est responsable
DRIVE
Une association drive est conditionne ou peut tre dduite partir dune autre association. Souvent un ensemble de contraintes, exprimes en OCL, est ajout une association
drive pour dfinir les conditions de drivation. Graphiquement, une association drive
est symbolise par lajout dun slash avant le nom de lassociation. Dans lexemple de la
figure 2.19, lassociation drive /emploi indique que la personne qui travaille pour une
entreprise est la mme que celle qui est associe lun de ses dpartements.
Figure 2.19
Association drive
dfinie par une
contrainte du
langage OCL.
1
Entreprise
/emploie
n..*
{Context : Personne
self.departement.entreprise
= self.entreprise}
Dpartement
Personne
4.5 CLASSE-ASSOCIATION
Une association peut tre raffine et avoir ses propres proprits, qui ne sont disponibles
dans aucune des classes quelle lie. Comme, dans le modle objet, seules les classes peuvent
avoir des proprits, cette association devient alors une classe appele classe-association .
partir du moment o elle est dfinie, elle est considre comme toutes les autres classes du
modle.
EXEMPLE
Figure 2.20
Une classeassociation est
caractrise par
lajout dun trait
discontinu entre
la classe et
lassociation
quelle reprsente.
48
UML 2
Les personnes qui travaillent dans une entreprise occupent un poste. Parmi les proprits associes au poste figure le salaire. Par ailleurs, quand une personne occupe un poste dans une
entreprise, elle peut tre responsable de plusieurs personnes.
Personne
Entreprise
employ
Association
rflexive oriente
employeur
Poste
salaire : Salaire
*
responsable
Classe association
Chapitre
4.6 ASSOCIATION
QUALIFIE
Parfois, lassociation entre deux classes donne peu dindications sur limplication effective
des classes dans la relation, ce qui rend la modlisation imprcise. Cette imprcision concerne,
en particulier, la multiplicit dune extrmit de lassociation et/ou la porte de lassociation
par rapport aux classes associes.
La qualification dune association permet, dans certains cas, de transformer une multiplicit indtermine ou infinie en une multiplicit finie, comme le montre la figure 2.21.
EXEMPLE
Figure 2.21
Vector
Intrt de la
qualification dune
classe pour prciser
la multiplicit.
EXEMPLE
Vector
Object
indice:integer
Object
Qualification dune association pour limiter son impact sur les classes associes
Lobjectif est de modliser lassociation entre une personne et une banque. Lunique lien entre
les deux est le fait de possder au plus deux comptes. La banque assure bien dautres activits qui ne concernent pas le client. Pour mettre en vidence le fait que le lien entre la banque
et une personne se limite la possession de plusieurs comptes, on ajoute une classe Compte
qui reprsente la classe Banque dans lassociation avec la classe Personne.
Figure 2.22
Banque
#Compte
0..2
possder
*
client
Personne
Notation
Les traits pleins qui viennent de toutes les classes associes convergent vers un losange central pouvant ventuellement accueillir une classe-association. La multiplicit apparaissant
sur le lien de chaque classe sapplique sur une instance du losange. Une instance du
losange par rapport une classe est un ensemble contenant une seule et unique instance
de chacune des classes, lexclusion de la classe-association et de la classe considre.
Diagramme de classes 49
EXEMPLE
Chaque anne, les tudiants sinscrivent dans un seul groupe et suivent des modules. Pour un
groupe dtudiants donn (ne dpassant pas vingt-cinq individus), un module est assur
par un seul enseignant. Un module nouvre que si au moins quatre tudiants sont inscrits. Par
ailleurs, la politique de lcole fait quun enseignant ne peut pas assurer plus de trois modules
pour un tudiant donn et un tudiant suit entre cinq et dix modules.
Figure 2.23
tudiant
4..25
1..3
Enseignant
4..*
*
5..10
Module
Notation
Une agrgation se distingue dune association par lajout dun losange vide du ct de
lagrgat.
EXEMPLE
Une cole dispose dau moins une salle de cours. Dans chaque salle, on trouve des chaises et
un vido-projecteur fix au plafond.
Figure 2.24
cole
Relation
dagrgation.
2..*
Salle
Chaise
1
1
Projecteur
4.9 RELATION
DE COMPOSITION
50
UML 2
Chapitre
la destruction de ses composants. Par ailleurs, la destruction ou la copie de lobjet composite implique respectivement la destruction ou la copie de ses composants. Une instance de
la partie appartient toujours au plus une instance de llment composite.
Notation
Une composition se distingue dune association par lajout dun losange plein du ct de
lagrgat. La multiplicit du ct de lagrgat ne peut prendre que deux valeurs : 0 ou 1.
Par dfaut, la multiplicit vaut 1.
Comme tous les autres lments du langage UML, la composition ne reflte pas forcment la
ralit. Cependant, elle doit tre fidle la situation modlise, comme le montre ce qui suit.
EXEMPLE
On peut complter lexemple prcdent en indiquant quune salle est compose dune seule
porte et de plusieurs fentres. De plus, si le tableau est fix, on considre que la relation de
composition reflte mieux le lien qui le lie la salle.
Figure 2.25
cole
2..*
Salle
Exemple de relation
de composition.
0..1
*
Projecteur
Chaise
Porte
*
Fentre
Remarque
La relation de composition tant structurelle, le langage UML autorise la reprsentation suivante :
Figure 2.26
Salle
Reprsentation imbrique
de la composition. Une salle
est compose dune porte
et de plusieurs fentres.
4.10 RELATION
Porte 1
Fentre *
mp
DE DPENDANCE
Une dpendance est une relation unidirectionnelle exprimant une dpendance smantique
entre les lments du modle. Elle est reprsente par un trait discontinu orient. Elle indique que la modification de la cible implique le changement de la source. La dpendance est
souvent strotype pour mieux expliciter le lien smantique entre les lments du modle.
Les strotypes normaliss sont, entre autres, friend (on accorde une visibilit spciale
la classe source dans la cible), drive (la source est calcule partir de la cible), appel
(appel dune opration par une autre), instantiate (une opration de la source cre une
instance de la cible), send (une opration envoie un signal vers un lment cible),
trace (la cible est une version prcdente de la source), refine , copie et create .
EXEMPLE
Figure 2.27
Relation de dpendance.
EmploiDuTemps
Cours
Diagramme de classes 51
Les animaux sont des tres vivants qui ont tous une dure de vie limite. Ltre humain est un
animal dont la dure de vie ne dpasse pas cent cinquante ans.
Dans cet exemple, lensemble des objets considrs est celui de la classe Animal. Celle-ci est
une spcialisation de la classe EtreVivant dont elle reprend la proprit dureDeVie. Le partitionnement des objets de la classe Animal fait apparatre la partition reprsente par la
classe EtreHumain. Linformation spcifique de cette classe est la dure de vie qui ne dpasse
pas cent cinquante ans.
Figure 2.28
Animal
Exemple dune
relation dhritage.
EtreVivant
EtreHumain
52
UML 2
Un rectangle et un cercle sont des figures gomtriques. Un carr est un rectangle dont la longueur et la largeur sont identiques.
Les classes dcrivant cette situation sont FigureGomtrique, Rectangle, Carr. La classe
Rectangle spcialise FigureGomtrique en ajoutant des attributs et la classe Carr spcialise la classe Rectangle en rduisant le domaine de dfinition des attributs existants (largeur
= longueur).
Chapitre
Figure 2.29
FigureGomtrique
Exemple dune
relation dhritage.
Rectangle
Cercle
largeur: integer
longueur: integer
carr
Remarque
Lors de la redfinition dun attribut dune classe dans une sous-classe, il est fortement
conseill de le faire uniquement en restreignant son domaine de dfinition. Deux cas sont
possibles : soit garder le mme type et rduire le champ des valeurs, soit redfinir lattribut
comme objet dune sous-classe de sa classe prcdente. Dans le cas de la redfinition de
mthode, celle-ci est utilise afin de restreindre les arguments (en fixant certains), en tendant
la dfinition initiale de la mthode, en proposant dautres alternatives dimplmentation
(par exemple pour optimiser le temps de calcul).
EXEMPLE
Hritage multiple
Un bateau est la fois un vhicule moteur et un vhicule marin. Si les classes VhiculeAMoteur et VhiculeMarin existent, il est souhaitable dindiquer que le bateau hrite de lune et
de lautre et de profiter ainsi de toutes les proprits dj dfinies. Cependant, la question se
pose de savoir quelle est la proprit associe lobjet lorsque celle-ci apparat dans les
deux parents directs. La solution la plus simple consiste dfinir une priorit dhritage.
Diagramme de classes 53
Figure 2.30
Exemple dhritage
multiple.
Si on donne la priorit au
VhiculeMarin alors le type du
nom dans Bateau sera String.
Bateau
VhiculeMarin
VhiculeMoteur
nom: String
Remarque
Quand une classe (ou une opration) ne peut tre redfinie, il faut ajouter la proprit
{leaf} la dfinition de la classe ou de lopration. Lexercice 5 prsente certaines proprits de la relation dhritage.
(5)
Figure 2.31
Reprsentations
graphiques dun
connecteur, dun
port et dun signal.
(6)
connecteur
port
signal
estAllum
fait:boolean
Signal
Diagramme dobjets
Bien souvent, la description statique dun systme est faite travers le diagramme de classes.
Cela permet de simplifier la modlisation en synthtisant les caractristiques communes et
en couvrant un grand nombre dobjets. Parfois, il est utile, voire ncessaire, dajouter un
diagramme dobjets. Le diagramme dobjets permet, selon les situations, dillustrer le
modle de classes (en montrant un exemple qui explique le modle), de prciser certains
54
UML 2
Chapitre
aspects du systme (en mettant en vidence des dtails imperceptibles dans le diagramme de
classes), dexprimer une exception (en modlisant des cas particuliers, des connaissances
non gnralisables) ou de prendre une image (snapshot) dun systme un instant donn.
Le diagramme de classes modlise les rgles et le diagramme dobjets modlise des faits.
Souvent, le diagramme de classes sert de modle pour instancier les classeurs afin dobtenir
le diagramme dobjets. Le diagramme de classes de la modlisation dune entreprise montre
quune entreprise emploie au moins une personne et quune personne travaille dans au plus
deux entreprises (figure 2.31(a)). En revanche, le diagramme dobjets modlise lentreprise
qui emploie trois personnes (figure 2.31(b)).
Figure 2.32
Entreprise
Diagramme de
classes et exemple
de diagramme
dobjets associ.
nom: String
0..2
travailler pour
1..*
Personne
e:Entreprise
nom: String="OSKAD"
travailler pour
p1:Personne
travailler pour
:Personne
travailler pour
p2:Personne
(a)
(b)
Les deux principaux classeurs instancis dans le diagramme dobjets sont les classes et les
relations.
6.1 REPRSENTATION
DES OBJETS
Graphiquement, un objet se reprsente comme une classe, avec deux compartiments, celui
du nom et celui des attributs. Le compartiment des oprations des classes nest pas utile
dans les objets puisque linterprtation des oprations est la mme pour tous les objets et
que tous les objets dune classe possdent les mmes oprations.
Contrairement au nom dune classe, le nom dun objet est soulign et son identifiant peut
tre ajout devant le nom de la classe. Les attributs reoivent des valeurs. Quand certaines
valeurs dattribut dun objet ne sont pas renseignes, on dit que lobjet est partiellement
dfini (figure 2.33(a)).
Parmi les diffrentes formes dobjet, on trouve les instances nommes (figure 2.33(b)), les
instances anonymes avec indication de paquetage (figure 2.33(c)), les instances multiples
(figure 2.33(d)), les instances orphelines (figure 2.33(e)) et les instances strotypes
(figure 2.33(g)). La figure 2.33(f) montre un objet sans valeur dattribut, mais avec un tat
explicite. Cela est particulirement utile lorsque plusieurs valeurs des attributs dun objet
correspondent une seule interprtation smantique. la figure 2.33(f), ltat grand correspond toutes les valeurs de lattribut taille suprieure un mtre quatre-vingts, par
exemple.
Figure 2.33
Exemples dinstances
dobjet.
:Personne
nom:String="toto"
age :integer="inconnu"
(a)
albert:Adhrent
(b)
:Adhrent ::Asso
(c)
:Adhrent
(d)
albert:
albert:Adhrent
[grand]
exception
e.IOException
(e)
(f)
(g)
Diagramme de classes 55
6.2 INSTANCES
DE RELATION
Un diagramme de classes contient essentiellement des classes et des relations entre classes.
Quand un diagramme dobjets est cr partir dun diagramme de classes, les classes sont
instancies et deviennent des objets, tandis que les relations deviennent des liens au
moment de leurs instanciations. Graphiquement, un lien se reprsente comme une relation,
mais le nom de la relation est soulign. Lexemple de la figure 2.34 indique que le portable
achet par Jean est compos dun cran et est livr avec une alimentation.
Figure 2.34
SonyVaio1:Portable
Instances de relation
montrant des instances
dassociation,
de composition
et dagrgation.
6.3 RELATION
:Alimentation
:cran
DE DPENDANCE DINSTANCIATION
Figure 2.35
Enseignant
Dpendances
dinstanciation
entre les classeurs
et leurs instances.
(7)
1..*
instanceof
donner cours
1..*
instanceof
Etudiant
instanceof
donner cours
:Enseignant
:Etudiant
Contraintes
Les contraintes permettent de rendre compte des dtails que nexpriment pas les lments
du langage UML afin de restreindre la porte du modle. En UML, les contraintes sont vues
comme un mcanisme dextension. Elles sont exprimes par une expression mathmatique,
un langage de programmation, le langage naturel, etc. Cependant, un langage dexpression
des contraintes est maintenant associ UML et permet dexprimer la plupart des
contraintes : il sagit du langage OCL. OCL permet dexprimer principalement quatre types
de contraintes : les invariants, les pr-conditions et les post-conditions lexcution doprations ainsi que les conditions de garde.
Dans le diagramme de classes, les contraintes les plus couramment utilises permettent de
spcifier les valeurs initiales dun objet ou dune extrmit dune association, de spcifier
les rgles dhritage ({complete}, {incomplete}, {overlaps}, {distinct}, ), de spcifier une
mthode, de restreindre la porte dune association ({subset}, {xor},), dexprimer le
mode dvolution des objets ({frozen}, {addOnly}, ), leur organisation ({ordered},
{frozen}, ).
Dans le cadre dUML 2, les spcifications du langage OCL figurent dans un document indpendant, dcrivant en dtail la syntaxe formelle et la faon dutiliser ce langage.
56
UML 2
Chapitre
EXEMPLE
1. Un comit est compos dau moins deux personnes. Le comit est prsid par un de ses
membres.
2. Un polygone est compos dune srie dau moins trois sommets ordonns. Chaque sommet
est un point.
3. Une voiture peut avoir entre trois et dix roues. Durant la vie dune instance de la classe
Voiture, le nombre de roues ne change jamais.
Figure 2.36
Exemple dutilisation
des contraintes
pour affiner la
modlisation.
Polygone
Comit
membre de
{subset}
2..*
prside
1
Personne
Voiture
{ordered}
3..* sommet
Personne
{frozen}
2..*
Roue
Une contrainte, dans le modle de donnes, est associe au modle sauf si elle est associe
un strotype. Dans ce dernier cas, la contrainte concerne le mtamodle, et non le modle
de donnes. Pour plus de dtails, reportez-vous au document normatif ddi au langage
OCL.
(8)
Diagramme de classes 57
une classe : payer ou appeler ne sont pas des bons choix, mme pour une banque ou un oprateur de tlphonie.
Aprs avoir tabli une premire liste, liminez les classes redondantes (celles qui modlisent
des concepts similaires), ainsi que les classes superflues (celles qui ne sont pas en rapport
direct avec le domaine). Le nom des classes est important ; il ne doit pas tre vague. Par
exemple, EmployDanscurieDeCourseAutomobile est trop vague. Prfrez Pilote et Mcanicien. Il faut cependant faire attention aux classes qui portent un nom de rle : PremierPilote
et DeuximePilote ne sont pas des bons choix.
Le niveau de granularit dune classe est important. Gnralement, une classe contient plusieurs attributs. Si un substantif ne peut pas tre dcompos en plusieurs entits, il sagit
bien souvent dun attribut : un nom, par exemple, est considr comme un attribut dune
classe Personne, qui a par ailleurs dautres attributs (lge, le sexe), tandis que lauteur
dun livre ne peut pas se rduire lattribut dune classe Livre, car lauteur a un nom, une
date de naissance, etc.
Les classes ne doivent pas modliser des implmentations possibles dlments du domaine :
une liste de clients nest pas une bonne ide de classe car vous pouvez crer un ensemble
de clients de plusieurs faons, et pas seulement sous forme de liste. Dailleurs, un modle
contient rarement la fois des classes et leurs conteneurs. Le modle dune banque, par
exemple, ne doit pas runir simultanment les classes Clients au pluriel et Client au singulier, moins quil soit important de constituer un portefeuille de clients. Dans ce cas, il faut
avoir recours deux classes, Client et PorteFeuilleDeClients et les associer par une relation
de un vers plusieurs .
Trouver les associations entre les classes. Les associations correspondent souvent des verbes
mettant en relation plusieurs classes, comme est compos de , ou pilote , ou bien
encore travail pour . Les relations entre classes doivent tre modlises par des associations, et non par des attributs (conducteur pour une classe Pilote est un mauvais
choix dattribut mais conduire en tant quassociation entre les classes Pilote et Voiture est
appropri).
vitez les associations qui mettent en jeu plus de deux classes. Souvent, une association ternaire peut tre transforme en une association binaire qualifie. Par exemple, un conducteur
a besoin dune assurance pour conduire une voiture peut tre ramen un conducteur a
une voiture et lassurance est un attribut de lassociation binaire entre conducteur et voiture .
Quand plusieurs classes sont associes, plusieurs chemins sont ventuellement possibles
entre les classes. Le problme qui se pose souvent est le suivant : faut-il limiter les chemins,
ou au contraire, multiplier les associations en gnralisant les raccourcis ? Multiplier les
associations facilite lutilisation des classes lors de limplmentation car il nest pas ncessaire de parcourir de nombreuses associations pour accder une information. Cependant,
multiplier nimporte comment les associations conduit des chemins redondants, qui
napportent aucune valeur ajoute au diagramme de classes. De plus, multiplier les associations rduit la rutilisabilit de lapplication, car deux classes associes peuvent difficilement
tre utilises sparment. Dans la plupart des cas, vitez les chemins redondants durant
la phase danalyse. Il sera toujours temps, au moment de limplmentation, dajouter des
chemins si vraiment cela facilite la programmation.
Ne confondez pas une association avec un attribut car un attribut est propre une classe
tandis quune association met en jeu plusieurs classes. Dans certaines situations, cette rgle
intangible est viole de faon presque indiscernable. Considrez les deux classes Avion et
Camion : devez-vous considrer "est plus lourd que" comme une association ? Non, car le
plus simple est de placer un attribut masse dans chaque classe et dutiliser une simple
fonction de comparaison pour obtenir la rponse.
58
UML 2
Chapitre
Trouver les attributs des classes. Les attributs correspondent gnralement des substantifs
tels que la masse dune voiture ou le montant dune transaction . Les adjectifs tels
que rouge ou des expressions telles que 50 euros reprsentent souvent des valeurs
dattribut. Un attribut ne doit pas tre driv dun autre attribut : lge dune personne, par
exemple, peut tre dduit de sa date de naissance et de la date courante.
Vous pouvez ajouter des attributs toutes les tapes du cycle de vie dun projet (implmentation comprise). Nesprez pas trouver tous les attributs ds la construction du diagramme
de classes.
Organiser et simplifier le diagramme en utilisant lhritage. Un hritage dnote une relation
de gnralisation/spcialisation entre plusieurs classes. Vous pouvez construire un graphe
dhritage vers le bas , en partant dune classe du domaine et en la spcialisant en une ou
plusieurs sous-classes, ou vers le haut , en factorisant les proprits de plusieurs classes
pour former une classe plus gnrale.
Cependant, ne confondez pas numration et hritage. Une numration est un type de
donnes qui a un ensemble fini de valeurs possibles (les couleurs dune voiture par exemple). Un hritage reprsente une relation de gnralisation entre classes ; cela implique
quune des sous-classes au moins a un attribut, une mthode ou une association spcifique.
Tester les chemins daccs aux classes. Suivez les associations pour vrifier les chemins
daccs aux informations contenues dans les classes. Manque-t-il des chemins ou des informations ? Si le monde modliser parat simple, le modle ne devrait pas tre complexe.
Veillez nomettre aucune association. Cependant, ne cherchez pas relier systmatiquement toutes les classes. Certaines peuvent trs bien tre isoles.
Itrer et affiner le modle. Un modle est rarement correct ds sa premire construction.
La modlisation objet est un processus, non pas linaire, mais itratif. Plusieurs signes
dnotent des classes manquantes : des asymtries dans les associations et les hritages, des
attributs ou des oprations disparates dans une classe, des difficults gnraliser, etc.
La dmarche prsente dans cette section est une dmarche indicative. Diffrents processus
permettent la construction dun diagramme de classes. Dans tous les cas, respectez les rgles
simples et efficaces suivantes :
liminez les classes redondantes.
EXEMPLE
Un avion est associ un aroport de dpart et un aroport darrive. Une premire modlisation permet dobtenir trois classes : AroportDpart, AroportArrive et Avion (voir exercice 11). En ralit, tous les aroports jouent le rle daroport de dpart pour certains
avions et daroport darrive pour dautres. Il est donc insens de garder deux classes
Aroport. On limine la redondance en ne crant quune classe Aroport et en modlisant
les aroports de dpart et darrive comme des rles des associations qui lient lavion
laroport.
Retardez lajout des classes faisant intervenir les choix de conception et de ralisation.
EXEMPLE
Lapplication dcrite dans lexercice 1 indique que le systme gre les salaris de lentreprise.
Il nest pas souhaitable dintroduire une classe FichierEmploys car cela impose un choix de
ralisation. Ce choix doit tre retard dans la mesure du possible.
Najoutez pas les tableaux ou listes dobjets dans les classes. Souvent, cette information
est explicitement visible dans les multiplicits associes aux relations entre les classes.
Une bonne faon de reprsenter la prsence dun tableau dinstances dune classe dans
une autre est dutiliser les relations dagrgation ou de composition.
Diagramme de classes 59
Quand une classe dispose de beaucoup de responsabilits, trouvez un moyen de la simplifier (voir le principe dabstraction et de dcomposition).
Lors de la modlisation et du choix des relations entre classes, distinguez bien les objets
physiques de leur description (du modle dobjets).
Une proprit structurelle (attribut) peut tre reprsente par une association, une
description textuelle dans un classeur ou une combinaison des deux.
vitez les oprations daccs aux attributs (get et set) car celles-ci ajoutent beaucoup de
bruits et sont souvent inutiles.
Pour des applications complexes, souvent plusieurs diagrammes de classes sont dfinis.
Chaque diagramme met en vidence des parties particulires du modle. Par exemple, un
diagramme montre les classes appartenant un paquetage, un autre montre les classes
participant la ralisation dun cas dutilisation, etc.
Conclusion
Dans ce chapitre, nous avons dabord dfini la notion de classe et dobjet. Un objet reprsente une entit concrte (par exemple un emplacement mmoire dans un ordinateur). La
classe, quant elle, adopte un niveau plus lev dabstraction car elle modlise, dune faon
concise, un ensemble dobjets. Cependant, souvent le diagramme dobjets est nglig lors de
la modlisation. Cest pourtant lui qui permet de dfinir les liens concrets entre les entits
avant que ceux-ci ne soient gnraliss dans le diagramme des classes. Par exemple, lassociation rflexive de la figure 2.17 ne permet pas de donner le nombre exact dobjets mis en
jeu. Plusieurs consquences peuvent en dcouler. Par exemple, il nest pas possible de dfinir
la quantit de mmoire prvoir pour les instances de cette classe.
Malgr leur importance, le diagramme de classes et le diagramme dobjets ont plusieurs
limites la bonne comprhension dun systme. Notamment, ils ne montrent pas le cycle de
vie des objets : nous ne savons pas, la lecture de tels diagrammes, dans quel ordre les objets
sont crs, utiliss puis dtruits, pas plus quils nindiquent lordre dans lequel senchanent
les oprations. Nanmoins, le diagramme des classes est le plus utilis pour la modlisation
dun systme car il en montre la structure interne.
Avec le diagramme des cas dutilisation, vu au chapitre 1, nous disposons, prsent, de deux
faons de voir un systme. En effet, le diagramme des classes donne une approche objet tandis que celui des cas dutilisation montre un ct fonctionnel. Mais, rien nindique que ces
deux modles sont cohrents entre eux : la structure interne donne par le diagramme des
classes supportera-t-elle les fonctionnalits prvues par les cas dutilisation ? Ce passage du
fonctionnel lobjet est dlicat. Une des solutions possibles pour garantir la cohrence des
deux modles est de faire un dcoupage en couches horizontales : la couche du bas dcrit
limplantation du diagramme des classes et la couche du haut permet, via une interface
(homme-machine et graphique par exemple), daccder aux fonctions de lapplication. Le
lien entre les deux couches est assur par ladjonction dune couche supplmentaire (dite
couche applicative). Une tude de cas, dcrite la fin de cet ouvrage dtaille comment
dcomposer un systme en couches.
60
UML 2
Chapitre
Problmes
et exercices
Les exercices suivants utilisent les principaux concepts des diagrammes de classes.
PROPRITS DUNE
CLASSE
Exercices
EXERCICE 1
Diagramme de classes 61
Figure 2.37
Classe Personne.
Dautres informations
peuvent tre ajoutes comme
lauteur, la date, etc.
Responsabilits
- calcul revenu
- calcul charges
Remarque
Dans la solution propose, la modlisation de lge est reprsente par un attribut dateNaissance et une mthode calculAge(). Une autre solution possible est de reprsenter lge
par un attribut et de laisser au programmeur le choix dun modle dimplmentation. Dans
ce cas, ajoutez lattribut driv /age ; sa valeur sera alors calcule partir dune mthode.
Figure 2.38
Ajout des oprations
la classe Personne.
Personne
-chargeSalaire :Float =0.15
-autreCharge :Float =0.2
- nom : String
- prnom : String
- sexe : {F, M}
- dateNaissance : Date
- salaire : Integer
- autreRevenu : Integer
La mthode correspondante
est :
Renvoie (salaire * chargeSalaire
+ autreRevenu * autreCharge)
+getNom : String
+getPrnom : String
+calculAge() : Date
+calculCharges () : Float
3. Pour crer un objet de la classe Personne, il faut par exemple disposer dun nom et dune
date de naissance. Mais il est ventuellement possible de crer un objet personne en
disposant dautres informations. Au lieu dajouter le constructeur indiqu seul, ajoutez
le strotype constructor, qui permet la fois dorganiser des oprations en groupes et
dindiquer quil est possible dajouter dautres constructeurs.
62
UML 2
Chapitre
Les oprations assurant le changement des valeurs des attributs peuvent galement tre
regroupes sous le strotype update.
Lnonc indique que le calcul des charges ne sapplique plus si la personne est dcde. Il
sagit, dans ce cas, dune exception qui doit tre ajoute dans le compartiment ddi afin
quelle soit traite lorsque les informations suffisantes seront disponibles.
Figure 2.39
Ajout du
compartiment
numrant les
exceptions.
Personne
-chargeSalaire :Float =0.15
-autreCharge : Float =0.2
- nom : String
- prnom : String
- sexe : {F,M}
- dateNaissance : Date
- salaire : Integer
- autreRevenu : Integer
constructor
Personne (String nom, Date dNaissance)
update
+setPrenom (String prenom)
+setAge(Date dNaissance)
+getNom : String
+getPrnom : String
+calculAge() : Date
+calculCharges () : Float
Exceptions
Calcul charge si dcs
EXERCICE 2
CLASSE
STROTYPE
Utilisation du
strotype Utility.
Utility
Math
PI :Real = 3,14
sinus(Angle) : Real
cosinus(Angle) : Real
tangente(Angle) : Real
Exercices
Figure 2.40
Diagramme de classes 63
EXERCICE 3
NOM DUNE
CLASSE
La classe Livre est dfinie dans le paquetage Ressource se trouvant lui-mme dans le paquetage Bibliothque. Parmi les attributs de la classe Livre figurent le nom de type String se
trouvant dans le paquetage Base et lemprunteur de type Adhrent se trouvant dans le
paquetage Bibliothque. Donnez la reprsentation graphique de la classe Livre.
Quand une classe est dfinie dans un paquetage, celui-ci peut tre prcis dans la dclaration
du nom de la classe. Du point de vue implmentation, le paquetage correspond souvent au
chemin daccs la classe.
Figure 2.41
bibliothque::ressource :: Livre
Espace de nommage
des classes.
EXERCICE 4
emprunteur:Bibbliothque ::Adhrent
nom :base ::String
DFINITION DUN
MESSAGE ASYNCHRONE
Lors de lenvoi dun e-mail, on souhaite lui associer un signal permettant de savoir que le
message envoy est approuv par le destinataire. Utilisez le mcanisme de classe strotype pour modliser ce message.
Les messages changs entre les instances de classe sont modliss par des oprations. Les
oprations sont, par dfinition, synchrones. UML 2 a prvu un mcanisme pour lchange
des donnes asynchrones. Il sagit des signaux.
Un signal est un message asynchrone. Comme une opration, le signal possde un nom et
des paramtres. Cependant, un signal peut se modliser comme une opration, une classe
ou une interface, en fonction de sa complexit et de sa nature. Quand il est modlis comme
une opration, il est prcd du mot-cl signal. Quand il est modlis par une classe, le nom
de la classe est prcd du strotype signal.
On suppose que le signal associ le-mail a une valeur boolenne qui indique si le message
est approuv ou pas.
Figure 2.42
Modlisation
dun signal.
64
UML 2
signal
estAllum
fait : Boolean
Chapitre
EXERCICE 5
CLASSE ACTIVE
Votre tlphone mobile dispose dun gestionnaire dvnements qui permet de suspendre
lactivit du tlphone lorsque celui-ci nest pas sollicit, dafficher un message quand un
rendez-vous est programm. Proposez une modlisation UML de ce gestionnaire dvnements.
Le gestionnaire dvnements peut tre modlis par une classe. Linstance de cette classe
cre elle-mme des instances de la classe vnements et contrle certaines activits de votre
tlphone. Il sagit dune classe particulire qualifie d active par UML.
Une classe active initie et contrle le flux dactivits alors quune classe passive (par dfaut)
sauvegarde les donnes et offre les services aux autres. Graphiquement, une classe active est
reprsente comme une classe standard, avec une paisseur de trait plus prononce.
Le gestionnaire dvnements contient des vnements. Il est capable de crer un vnement, de le suspendre, de lafficher ou de le dtruire. Cela donne le modle prsent la
figure 2.43.
Figure 2.43
Gestionnairevnements
Exemple de classe
active.
evts : venement[1..n]
+cration(vnement)
+destruction(vnement)
+afficher(vnement)
+suspendre(vnement)
EXERCICE 6
CONTRAINTE
Les cartes de visite contiennent diverses informations. Leur caractristique commune est
que leurs proprits sont immuables durant toute la vie de la carte. Proposez une modlisation UML de cet lment.
Dans le cas de la carte de visite, deux types de contraintes saccumulent. En effet, la carte de
visite est en lecture seule et, en principe, une fois imprime, ses proprits restent immuables
durant toute la vie de la carte. Dans le cas gnral, les deux contraintes sont indpendantes.
Figure 2.44
Ajout des contraintes
dans la description
dune classe.
Exercices
Vous pouvez geler une association en utilisant la contrainte standard {frozen}. Cette
contrainte prcise que la valeur de lassociation est gele durant toute la vie de lassociation. Ce principe sapplique de la mme manire pour les classes et les attributs. Dans
le cas de la classe, cela signifie que les valeurs sont affectes lors de la cration de lobjet et
ne changent pas.
Diagramme de classes 65
EXERCICE 7
CLASSE
PARAMTRABLE
La gestion dune liste, indpendamment des objets quelle contient, utilise les oprations
dajout, de suppression et de recherche. Proposez une modlisation UML de concept.
Certains langages de programmation typage fort, comme le C++, utilisent des classes
paramtrables (patrons). Lintrt principal est de regrouper les comportements associs
la structure de la classe indpendamment des objets quelle contient. Il appartient, par la
suite, au programmeur de prciser le type dobjet concern pour que toutes les oprations
soient applicables.
Modlisez la classe Liste comme une classe standard, en ajoutant cette dfinition un ou
plusieurs paramtres substituables ClasseCible1ClasseCiblen qui reprsentent les classes
des objets cibles. La figure 2.45 donne la reprsentation graphique de la classe paramtrable
Liste et un exemple de classe cible utilisant cette classe paramtrable. Une fois que la classe
Livre est dfinie, les oprations permettant dinsrer, denlever, de chercher un livre sappliquent automatiquement.
Figure 2.45
En utilisant la classe
paramtrable Liste
et la classe standard
Livre, on dfinit une
liste de livres utilisant
les proprits de
la classe Liste.
EXERCICE 8
Liste
ClasseCible
+inserer(ClasseCible)
+ supprimer(ClasseCible)
+chercher(ClasseCible)
Livre
Liste<Livre>
(1)
RELATIONS
SIMPLES
1. Cet exercice met en vidence lassociation multiple entre deux classes et la ncessit
dajouter une contrainte (mcanisme dextension dUML) pour exprimer le fait que le
rle dune personne luniversit est tudiant ou bien professeur. Seuls les noms des
66
UML 2
Chapitre
deux classes, des deux associations et la contrainte entre associations apparaissent dans la
solution. En effet, vu les informations disponibles dans lnonc et lobjectif de la modlisation (mettre en vidence les relations entre classes), il est inutile dajouter dautres
informations.
Figure 2.46
Contraintes entre
associations.
tudier
Universit
Personne
{ ou }
enseigner
2. Il sagit de reprsenter la fois les dtails dune classe et ses liens avec une autre classe. La
classe principale modliser est la classe Rectangle. Elle est associe la classe Point qui
joue le rle de ct dans lassociation avec la classe Rectangle. En labsence dinformations complmentaires permettant, en particulier, de savoir lutilit de modliser la classe
Point, vous pouvez proposer deux solutions, lune faisant apparatre uniquement la
classe Rectangle, et lautre, plus dtaille, faisant apparatre les classes Rectangle et Point.
Cela dit, si seule la classe Rectangle est reprsente, vous perdez linformation sur lassociation du point vers le rectangle. Cela correspond une modlisation dune association
unidirectionnelle de Rectangle vers Point alors que cette information nest pas disponible
directement dans lnonc. Ce choix peut tre justifi par lobjectif de la modlisation et
par le choix de limplmentation (pour limplmentation de lassociation, un attribut
point sera ajout dans Rectangle).
Figure 2.47
La figure de gauche
transforme
lassociation entre
les classes Rectangle
et Point en une
relation de
composition.
Rectangle
-sommet : Point[2]
constructor
Rectangle(Point, Point)
query
+ surface () : Float
update
+translater (Point)
Rectangle
constructor
Rectangle(Point, Point)
query
+ surface () : Float
update
+translater (Point)
-sommet
2
Point
Figure 2.48
Si datePublication dateNaissance
<10 lcrivain est dit prcoce
Ajout de contraintes
pour limiter la
porte dune
association.
crivain
#dateNaissance : Date
{ordered} 1..*
uvre
#datePublication : Date
Exercices
3. Les deux classes principales sont crivain et uvre. Une association bidirectionnelle
nomme possder relie les deux classes. Les uvres sont ordonnes selon la date de publication. Ajoutez donc lattribut datePublication de type Date dans uvre et la contrainte
{ordered} du langage OCL. Celle-ci signifie que les uvres sont ordonnes. Pour indiquer que lcrivain est prcoce, ajoutez un commentaire en langage naturel sous forme de
note. Cette note peut prciser galement le critre utilis pour lordonnancement. Il est
aussi ncessaire dajouter deux attributs dans la classe crivain : dateDeNaissance de type
Date et /prcoce de type Boolean. Lattribut /prcoce est un attribut drive de lassociation
entre crivain et uvre. Par ailleurs, la multiplicit du ct de lcrivain nest pas prcise
car celle-ci nest pas indique dans lnonc.
Diagramme de classes 67
4. La lecture du texte permet de slectionner les classes candidates suivantes : Facteur, Courrier, Habitant, ZoneDAffectation, Lettre, BoteAuxLettres, Colis, Destinataire.
La rdaction dune liste de classes candidates intervient en phase danalyse prliminaire.
Lobjectif est de dgager les principaux concepts partir de lanalyse fonctionnelle. Les
phases danalyse et de conception permettent de slectionner les classes qui apparatront dans le diagramme de classes. Pour trouver les candidates, il faut recourir un
expert du domaine, consulter le cahier des charges du client et parfois tenir compte du
langage dimplmentation qui sera utilis pour la ralisation (notamment pour les classes
utilitaires).
Si la modlisation concerne la mise en vidence du lien entre le facteur et les habitants
ainsi que la zone daffectation du facteur, vous pouvez proposer la solution qui suit :
La classe BoteAuxLettres nest pas pertinente. Elle ne fera pas partie du diagramme de
classes.
Un colis et une lettre sont des courriers particuliers.
Le destinataire est le rle dun habitant quand il reoit un courrier. Il ne sera pas reprsent par une classe.
Un facteur dessert une zone daffectation qui abrite plusieurs habitants.
Le seul lien entre le facteur et lhabitant est la distribution du courrier (classe-association).
Figure 2.49
Modlisation dune
classe-association.
Habitant *
destinataire
Lettre
ZoneDAffectation
Courrier
affecter
Colis
EXERCICE 9
RALISATION DUNE
Facteur
INTERFACE
Les tudiants peuvent tre compars par rapport lattribut moyenne gnrale et les livres
sont comparables par rapport leurs prix de vente. Pour des raisons dhomognit des
interfaces prsentes par les classes, tous les objets comparables utilisent la mme opration
compareTo(Instance). Proposez le diagramme de classes mettant en vidence lopration de
comparaison.
Les classes qui interviennent dans cette application sont tudiant et Livre. Lopration compareTo(Instance) compare tout type dobjet. Elle est donc abstraite. Si elle est commune
toutes les classes, vous devez la dfinir dans une interface que vous appellerez par exemple
68
UML 2
Chapitre
Comparable. Cette interface sera ralise par les classes qui lutilisent. Pour lapplication
considre, vous obtenez le diagramme prsent la figure 2.50.
Figure 2.50
tudiant
Ralisation
dune interface.
moyenneGn :float
realize
Livre
interface
Comparable
CompareTo()
realize
INTERFACE
Luniversit propose des cours de langue accessibles aux agents administratifs et aux
enseignants. La procdure dinscription est la mme pour les deux catgories de personnes.
Une personne inscrite peut galement rsilier son inscription. Modlisez les classes pour
reprsenter cette situation. Simplifiez la modlisation en faisant apparatre uniquement les
classes Enseignant et AgentAdministratif.
Les agents administratifs et les enseignants sont des personnes particulires. Ils partagent les
oprations inscrire() et rsilier(), qui font partie de la mme interface : Inscription. Dans un
premier temps, crez les classes Personne, Enseignant, AgentAdministratif, et linterface Inscription qui contient deux oprations : inscrire() et rsilier(). Faites volontairement abstraction de la classe Cours car lobjectif ici est de mettre en vidence les relations de dpendance
et de ralisation.
La ralisation de linterface Inscription est faite de la mme manire par les deux classes drives de Personne. De ce fait, et pour viter la redondance de la ralisation, il suffit quune seule
des deux classes sen charge (relation de ralisation) et que la deuxime utilise les mthodes
obtenues (relation de dpendance strotype par use ), comme le montre la figure 2.51.
Figure 2.51
Personne
AgentAdministratif
Enseignant
realize
interface
Inscription
+inscrire()
+rsilier()
use
Figure 2.52
Utilisation
dune interface.
AgentAdministratif
Enseignant
use
Exercices
La classe Enseignant
ralise linterface
Inscription et la classe
AgentAdministratif
utilise le rsultat.
Diagramme de classes 69
EXERCICE 11 RELATIONS
Une commande est lie plusieurs produits. chaque produit de la commande sont associes des dates.
1. Donnez une modlisation UML de lassociation entre ces trois classes.
Plus prcisment, deux dates sont affectes chaque produit dune commande, une
date et un produit sont associs une seule commande et, une commande et une date
donne sont lis deux dix produits.
2. Compltez la modlisation UML de lapplication.
Soit la base de donnes suivante : (commande, produit, date) = {(c1,p1,d1), (c1,p2,d2),
(c2,p1,d2), (c2,p4,d4)}.
3. Vrifiez quelle respecte bien le diagramme UML de la question 1. Sinon, ajoutez-lui les
tuples ncessaires pour la rendre conforme.
1. Trois classes peuvent tre extraites de la description de lapplication : Commande, Produit
et Date. Les deux relations entre les classes dfinies dans lnonc sont les suivantes :
Une relation binaire intervient entre Produit et Commande. La commande est compose
de plusieurs produits. Mais, les dures de vie des objets ne sont pas lies. De ce fait, cette
relation peut tre modlise par une agrgation. La commande est compose de plusieurs
produits. En principe, il faut dfinir une multiplicit *.
Une relation ternaire met en jeu les trois classes Commande, Date et Produit.
Figure 2.53
Commande
Produit
Relation ternaire.
1
2
Date
2. Pour dfinir la multiplicit mettre ct dune classe dans une relation n-aire, calculez
le nombre dobjets de ladite classe consistant avec chaque ensemble de (n-1) objets des
autres classes. Lunion de ces nombres calculs constitue la cardinalit de la relation. Pour
cette application, calculez le nombre dobjets de la classe Date consistant avec chaque
couple dobjets des classes Commande et Produit, le nombre dobjets de la classe Commande consistant avec chaque couple des classes Produit et Date et le nombre dobjets de
la classe Produit consistant avec chaque couple dobjets des classes Commande et Date.
Par exemple, lnonc indique qu chaque couple dobjets des classes Commande et
Produit sont associes exactement deux dates (figure 2.54).
70
UML 2
Chapitre
Par ailleurs, mme si lnonc ne le dit pas explicitement, vous savez quune commande
na de sens que si elle porte sur au moins un produit et quun produit peut apparatre
dans plusieurs commandes. La multiplicit de lagrgation est, de ce fait, restreinte.
Figure 2.54
Commande
Multiplicits
associes aux
relations n-aires.
1..*
Produit
2..10
1
2
Date
3. La contrainte de cardinalit est viole plusieurs fois par la base de donnes. Par exemple,
il est indiqu qu chaque couple dinstances des classes Commande et Produit correspondent exactement deux instances de la classe Date. Les couples (c2,p1) et (c2,p4) ne
vrifient pas cette contrainte.
Commande
c1
c1
c1
c1
c2
c2
c2
c2
Produit
p1
p1
p2
p2
p1
p1
p4
p4
Date
d1
d3
d2
d5
d2
d6
d4
d7
EXERCICE 12 HRITAGE
Exercices
1. Le chat et le chien sont des animaux. Les animaux possdent tous un nom. Proposez
une modlisation de cette situation en faisant apparatre que dautres animaux que les
chats et les chiens existent et quun animal ne peut pas tre la fois un chat et un chien.
2. Les animaux, en fonction de leur catgorie (chat, chien), ont un cri spcifique. Si la
catgorie de lanimal nest pas connue, le cri ne peut tre ralis. Compltez la modlisation prcdente pour inclure cette proprit.
3. Tous les animaux sont comparables par rapport la puissance, en dcibels, du cri
dgag. La valeur maximale est connue pour chaque catgorie danimaux. De plus,
pour des soucis dhomognit, toutes les comparaisons doivent respecter une interface
commune. Compltez le modle prcdent avec ces nouvelles informations.
Diagramme de classes 71
1. Vous avez besoin de trois classes : Chat, Chien et Animal. La classe Animal est plus gnrale (hritage) que les deux classes Chien et Chat. Une instance de la classe Chat (respectivement Chien) ne peut pas tre instance de la classe Chien (respectivement Chat) : il
sagit dun hritage exclusif (utilisation de la contrainte {disjoint} du langage OCL). Par
ailleurs, dautres animaux que les chats et les chiens existent. La contrainte {incomplete}
du langage OCL permet dexprimer cette contrainte.
Figure 2.55
Animal
nom : String
Hritage avec
contraintes. Lhritage
est incomplet et les
hritiers sont tous
disjoints.
{incomplete, disjoint}
Chien
Chat
2. Lopration crier() est partage par tous les animaux. Elle doit donc apparatre au niveau
de la classe Animal. Cependant, la mthode associe nest connue quau niveau des
descendants de cette classe. Cette mthode est donc abstraite. Les classes Chat et Chien
doivent absolument redfinir la mthode crier().
Figure 2.56
Animal {abstract}
nom : String
Ajout de la mthode
abstraite partage
par tous les hritiers
de la classe Animal.
abstract crier()
{incomplete, disjoint}
Chien
Chat
3. La valeur en dcibels de la puissance des cris est pareille pour chaque catgorie danimaux . Utilisez donc une variable statique. Pour oprer les comparaisons, dfinissez une
interface commune, par exemple Comparable, contenant les oprations ncessaires, en
loccurrence float compareTo(type) qui est ralise par chaque catgorie danimaux comme
le montre la figure 2.57.
Figure 2.57
Implmentation
de linterface
Comparable par
les classes drives
de la classe Animal.
use
interface
Comparable
float compareTo(type)
Animal {abstract}
nom : String
abstract crier()
realize
{incomplete,disjoint}
realize
Chat
static float bitCri
72
UML 2
Chien
static float dbitCri
Chapitre
EXERCICE 13 HRITAGE
Un tudiant et un enseignant sont des personnes particulires.
1. Proposez un modle de classes correspondant.
Un doctorant est un tudiant qui assure des enseignements. La modlisation sera suivie
par une implmentation en Java ou en C++.
2. Compltez le modle de classes prcdent en exploitant au mieux les possibilits du langage cible.
Un doctorant et un tudiant doivent sinscrire au dbut de lanne et ventuellement
modifier leur inscription. En fonction des deux modles proposs.
3. Ajoutez cette fonctionnalit aux deux prcdents modles.
1. Les tudiants et les enseignants hritent de la classe Personne. Dautres personnes, qui
ne sont ni des tudiants, ni des enseignants, drivent de la classe Personne. Ajoutez la
contrainte{incomplete} du langage OCL pour expliciter cette situation.
Figure 2.58
Personne
Relation dhritage.
{incomplete}
tudiant
Enseignant
Figure 2.59
Personne
Solution en utilisant
lhritage multiple.
{incomplete, overlapping}
tudiant
Enseignant
Java naccepte que lhritage simple. Cette contrainte implique une modlisation hirarchique de lhritage. En dautres termes, une classe peut avoir au plus un seul parent.
Lajout de cette contrainte implique implicitement lajout de la contrainte {disjoint} entre
les classes qui drivent directement de toute classe du modle. Vous pouvez modliser
Exercices
Doctorant
Diagramme de classes 73
cela en sparant les instances des doctorants de celles des tudiants et des enseignants.
Vous obtenez le modle prsent la figure 2.60.
Figure 2.60
Personne
Solution en utilisant
lhritage simple
{incomplete, disjoint}
tudiant
Enseignant
Doctorant
Figure 2.61
Personne
{incomplete, disjoint}
tudiant
Enseignant
Doctorant
use
realize
interface
Inscription
La solution propose par la figure 2.61 est aussi valable dans le cas o le langage supporte
lhritage multiple. Cependant, dans ce dernier cas, deux autres solutions sont possibles
comme le montre la figure 2.62.
Figure 2.62
Les deux solutions
possibles dans le
cas de lhritage
multiple.
Personne
Personne
{incomplete,
Enseignant
tudiant
overlapping}
tudiant
inscrire() ;
modifier()
{incomplete,
Enseignant overlapping}
Doctorant
realize
74
UML 2
interface
Inscription
inscrire() ;
modifier() ;
Doctorant
Chapitre
Figure 2.63
Diagramme dobjets.
mars:Robot
[enMouvement]
m1:Mur
z2:Zone
:Porte
mondeCourant:Monde
largeur:integer=1m
z1:Zone
m2:Mur
:Objet
EXERCICE 15 PATRON
DE CONCEPTION
OBJETS COMPOSITES
1. Toutes les figures comportent les oprations dessiner() et translater(). Les mthodes
associes ne sont pas connues, donc la classe Figure est abstraite. Une figure peut tre
spcialise en figure simple ou en figure compose. Cette dernire peut tre compose
(relation dagrgation) de plusieurs figures.
Exercices
Une figure gomtrique est compose de figures simples ou composes. Une figure compose est constitue de plusieurs figures et une figure simple peut tre un point, une ligne
ou un cercle. Une figure peut tre dessine ou translate.
1. Donnez la modlisation des classes de cette situation.
2. De manire plus gnrale, la notion dobjets composites se retrouve dans beaucoup
dapplications. De ce fait, il est intressant de proposer un patron de conception qui
modlise les objets composites et de les instancier en fonction des objets considrs.
tendez la solution prcdente afin de modliser nimporte quel ensemble dobjets
dcrits par une hirarchie dagrgation dobjets ayant le mme comportement.
Diagramme de classes 75
Figure 2.64
Figure{abstract}
Diagramme de
classes modlisant
les figures simples
et composes.
Elment de
+dessiner()
+translater()
FigureSimple
FigureCompose
+dessiner()
+translater()
Cercle
+dessiner()
+translater()
+dessiner()
+translater()
Point
+dessiner()
+translater()
Ligne
+dessiner()
+translater()
Figure 2.65
Le diagramme de
classes modlisant
le patron de
conception objets
composites .
Composant{abstract}
fils de
+operation
Feuille
+operation()
Composite
+operation()
Appliquer lopration
tous les descendants.
EXERCICE 16 APPLICATION
+ajout(c :Composant)
HTELIRE
Un htel est compos dau moins deux chambres. Chaque chambre dispose dune salle
deau qui peut tre une douche ou une salle de bain. Lhtel hberge des personnes. Il peut
employer du personnel et est dirig par un des employs. Lhtel a les caractristiques suivantes : une adresse, le nombre de pices, la catgorie. Une chambre est caractrise par le
nombre et le type de lits, le prix et le numro. On peut calculer le chiffre daffaires, le loyer
en fonction des occupants.
1. Donnez le diagramme de classes.
2. Utilisez les contraintes pour affiner les relations.
76
UML 2
Chapitre
La figure 2.66 propose une solution qui rpond aux deux questions.
Diagramme de
classes reprsentant
lapplication
htelire.
Htel
Chambre
adresse : String
catgorie : String
2..*
calculChiffreAffaires() : double
Loyer() : double
hberge emploie
{ou}
{ou}
0..1
1
dirige
1
1
loue
{element de}
*
1..*
1
SalleDEau
Personne
client
douche
EXERCICE 17 APPLICATION
nombreLit : int
typeLit : String
lePrix : double
numro : int
Baignoire
BANCAIRE
Une banque compte plusieurs agences rparties sur le territoire franais. Une banque est
caractrise parle nom de son directeur gnral, son capital global, son propre nom et de
ladresse de son sige social. Le directeur gnral est identifi par son nom, son prnom et
son revenu.
Une agence a un numro dagence et une adresse. Chaque agence emploie plusieurs
employs, qui se caractrisent par leurs nom, prnom et date dembauche. Les employs
peuvent demander leur mutation dune agence une autre, mais un employ ne peut travailler que dans une seule agence. Les employs dune agence ne font que grer des clients.
Un client ne peut avoir des comptes que dans une seule agence de la banque. Chaque nouveau client se voit systmatiquement attribuer un employ de lagence (conseiller). Les
clients ont un nom, un prnom et une adresse.
Les comptes sont de nature diffrente selon quils soient rmunrs ou non (comptes
courants). Les comptes rmunrs ont un taux dintrt et rapportent des intrts verss
annuellement.
1. Donnez la description complte de toutes les classes (remplissez tous les compartiments).
Prcisez les types des attributs et les types de retour des fonctions. Les attributs sont
tous privs. Chaque attribut possde deux mthodes publiques (getAttribut renvoie la
valeur dun attribut et setAttribut affecte une nouvelle valeur un attribut). Toutes les
autres mthodes sont accessibles uniquement dans le package de la classe.
2. Analysez les classes trouves en (1) et modlisez-les en factorisant (par gnralisation
ou autre) au mieux la description des proprits.
3. Une relation particulire lie lagence, le client, lemploy et le compte. De quelle relation
sagit-il ? Dessinez le modle de cette relation.
4. Donnez le diagramme de classes en nutilisant que leur nom et ajoutez tous les ornements possibles aux relations.
Exercices
Figure 2.66
Diagramme de classes 77
1. Les classes qui apparaissent dans cette application sont Banque, Directeur, Agence,
Employ, Client, CompteRmunr, CompteNonRmunr.
Figure 2.67
Description dtaille
des classes de
lapplication.
Banque
Directeur
-nom : String
-prenom : String
-revenu : float
-nomDirecteur : String
-capital : int
-adresseSiege : String
Client
Employ
-nom : String
-prenom : String
-adresse : String
-conseiller : Employer
-agence : Agence
-comptes : [1..N] Compte
-nom : String
-prenom : String
-dateEmbauche : Date
+getNomDirecteur() : String
+getNom() : String
+getNom: String
+setNomDirecteur(String n)
+setNom (String n)
+setNom(String n)
+getCapital():int
+getPrenom ():String
+getPrenom():String
+setPrenom(String p)
+getNom: String
+setCapital(int capital)
+setPrenom(String s)
+getRevenu():float
+setNom(String n)
+getAdresseSiege():String
+getDate(): Date
+setRevenu(float s)
+getPrenom():String
+setAdresseSiege(String s)
+setDate(Date s)
+setPrenom(String s)
+getDate(): Date
Banque(String Adresse)
+setDate(Dates)
mutation(Agence g):boolean
CompteNonRmunr
-solde : float
-numero : int
Agence
-nomAgence :String
-adresseAgence : String
CompteRmunr
-solde : float
-numero : int
-taux : float
+getNomAgence() : String
...
+setNomAgence(String n)
...
verserInteret() : void
2.
Figure 2.68
Personne
Les liens de
gnralisation
entre les classes
de lapplication.
Compte
Directeur
Employ
CompteRemunr
CompteNonRemunr
Client
3.
Figure 2.69
Agence
Employ
Associations
ternaires avec
classe-association.
1..*
Compte
78
UML 2
Client
Chapitre
4.
Figure 2.70
Personne
Diagramme
de classes de
lapplication
bancaire.
1
1
Banque
1..*
Agence
1..*
Directeur
1..*
Employ
1
1
Client
1..*
Compte
CompteRmunr
EXERCICE 18 RSERVATION
CompteNonRmunr
DE BILLETS DAVION
1. Tous les avions assurent plusieurs vols. Il est donc utile de remonter lassociation "assurer
vol" au niveau des classes Avion et Vol. Cependant, si vous nutilisez pas les contraintes et
si la contrainte spcifiant quun avion-cargo (respectivement de passagers) assure exclusivement des vols cargos (respectivement de passagers) alors la seule solution consiste,
non pas remonter lassociation entre Avion et Vol, mais la prciser entre tous les types
de vols et davions (figure 2.71).
Exercices
Un avion assure plusieurs vols et un vol est assur par un seul avion. Un vol peut tre un
vol cargo ou un vol de passagers. Les avions utiliss pour ces deux types de vols ne sont pas
les mmes.
1. Donnez le diagramme de classes exprimant cette situation.
2. Ajoutez les contraintes du langage OCL pour exprimer le fait quun vol cargo soit assur
par un avion-cargo et quun vol de passagers soit assur par un avion de passagers.
Les vols sont proposs par des compagnies ariennes. Pour un meilleur remplissage des
avions, un vol est partag par plusieurs affrteurs. Un des affrteurs assure louverture et
la fermeture de chaque vol. Un vol est caractris par une date et un lieu de dpart, une
date et un lieu darrive.
3. Donnez la modlisation des classes de cette situation.
Quand un client fait une rservation auprs dune compagnie arienne pour un ou plusieurs passagers, il est inform du fait que le vol compte plusieurs escales. Une escale est
caractrise par des dates darrive et de dpart ainsi quun aroport qui dessert plusieurs villes.
4. Proposez le diagramme de classes pour cette situation.
5. partir de ces diagrammes partiels, proposez un diagramme de classes modlisant cette
application.
Diagramme de classes 79
Figure 2.71
Vol
Avion
Diagramme
de classes.
AvionCargo *
AvionPassagers
assurer
VolCargo
assurer
VolPassagers
2. Lajout des contraintes du langage OCL permet une meilleure gnralisation travers
lexpression de cas particuliers et dexceptions. Vous pouvez remonter lassociation entre
un avion et un vol au niveau des classes Vol et Avion et ajouter une contrainte qui restreint limpact de lassociation sur les instances des classes (figure 2.71).
Figure 2.72
Avion
Gnralisation de
lassociation assure
par lajout de
contraintes OCL.
assurer
Vol
context Vol
inv: type=cargo implies Avion.type=cargo
inv: type=passager implies Avion.type=passager
VolCargo
AvionCargo
AvionPassagers
VolPassagers
3. Le rle de la compagnie arienne par rapport un vol est celui daffrteur. Laffrteur qui
ouvre un vol est aussi celui qui le ferme. De plus, un vol ne peut tre ouvert puis ferm
quune seule fois. UML ne fournit pas un moyen dexprimer cette double synchronisation. De ce fait, une note est ajoute au diagramme pour exprimer cette contrainte. Les
caractristiques dun vol (dates et lieux) ne sont pas dtailles et seront reprsentes par
de simples attributs.
Figure 2.73
Modlisation
dtaille de
la classe Vol.
Vol
1..*
propose
1..*
CompagnieArienne
#dateDpart:Date
#dateArrive:Date
#lieuDpart:Lieu
#lieuArrive:Lieu
+ouvrirVol()
+fermerVol()
Prconditions
ouvrir(): instance de vol jamais ouverte
former(): instance de vol ouverte par le
mme objet et jamais ferme.
4. Lassociation qui lie le client et la compagnie arienne concerne la rservation. La rservation nat de cette association et se compose de toutes les donnes la concernant. Il sagit
donc dune classe-association. La rservation concerne un passager et un vol.
Dans la modlisation prcdente, les lieux de dpart et darrive ne sont pas dtaills
(reprsentation sous forme dattributs). Cette fois, le lieu est connu : il sagit de laroport. Les deux attributs modlisant le lieu se transforment en rle dans les associations
reliant le vol et laroport.
80
UML 2
Chapitre
Une escale se caractrise par des dates et un aroport. Elle est dcrite par les attributs de
la classe Vol mais pas par ses mthodes (ouvrir(), fermer()). Ce nest donc pas un vol
particulier. Un vol peut compter plusieurs escales ordonnes. Chaque escale est lie un
aroport. Lescale nat dune relation entre un vol et un aroport, qui nest ni un aroport
de dpart, ni un aroport darrive. Les escales sont reprsentes par une classe-association
entre un vol et un aroport.
Figure 2.74
Client
Vol
Modlisation des
vols des compagnies
ariennes.
dpart
1
arrive
*
*
Reservation
Aroport
1
{ordered}
Passager
*
Escale
CompagnieArienne
dateDpart:Date
dateArrive:Date
Ville
Modlisation
gnrique dune
figure gomtrique.
FigureGomtrique
Cercle
Rectangle
Dessin
DessinInterface1
DessinInterface2
Exercices
Figure 2.75
Diagramme de classes 81
Labstraction est visible par les clients, renvoie les demandes vers limplmentation (operation=Implementation.operation) et fournit des fonctions de haut niveau. Les classes
RefinedAbstraction implmentent les diffrentes abstractions, la faon des classes FigureGeometrique qui implmentent diffrentes figures. Implementation est une interface
entre plusieurs implmentations possibles. Elle offre des oprations de bas niveau. Les
classes Implementation1 et Implementation2 permettent dimplmenter linterface Implementation en proposant des mthodes concrtes.
Figure 2.76
Diagramme de
classes du patron
de conception
Bridge .
+Implementation.operations()
Client
Abstraction
Implementation
+operation()
+operation()
RefinedAbstraction
EXERCICE 20
RefinedAbstraction
Implementation1
Implementation2
PATRON ADAPTEUR
Un diteur de jeux possde un jeu permettant aux enfants de connatre les animaux. Les
enfants peuvent, en particulier, apprendre la forme et le cri des animaux parmi lesquels le
chat et la vache. Le chat est modlis par la classe LeChat possdant au moins les deux
mthodes formeChat() et criChat() et la vache est modlise par la classe LaVache possdant les deux mthodes criVache() et formeVache().
Comme le montrent les noms des mthodes, la premire spcification de ce jeu est propre
aux animaux modliss. Lditeur souhaite amliorer ce jeu en crant une interface commune tous les animaux qui lui permette den ajouter de nouveaux, sans modifier linterface avec le client, et dutiliser le polymorphisme dans la gestion des animaux (manipuler
des troupeaux).
1. Proposez une modlisation des classes pour cette nouvelle version du jeu en faisant
apparatre le client.
2 .On souhaite rutiliser tout le code dvelopp dans la version prcdente. Proposez une
modlisation permettant dincorporer les anciennes mthodes pour viter de les
rcrire.
3. Est-il possible de gnraliser ce raisonnement pour les applications de mme type ? Si
cest le cas, proposez le patron gnrique correspondant.
1. Chaque animal est modlis par une classe : Chat, Vache, etc. Ces classes possdent au
moins les comportements suivants : crier() et forme(). Les mthodes implmentes dans
les diffrentes classes danimaux ont toutes les mmes oprations (mmes signatures de
mthodes). Cela signifie que le client qui utilise un animal na pas besoin de savoir a
priori de quel animal il sagit exactement ; il doit pouvoir accder un ensemble doprations. En ce sens, il suffit de crer une classe gnrale appele Animal, qui regroupe les
oprations communes. Cela permet de traiter tous les animaux de la mme manire, sans
82
UML 2
Chapitre
se soucier des diffrences dimplmentation, et dajouter ultrieurement de nouveaux
animaux sans devoir modifier le client.
Figure 277
Animal{abstract}
+crier():{abstract}
+forme():{abstract}
Client
Gnralisation
des proprits des
animaux dans la
classe Animal, seule
interface avec le
client.
Vache
Chat
+crier()
+forme()
+crier()
+forme()
Lajout dune classe danimaux quelconques doit se faire par drivation de la classe Animal. Cette nouvelle classe doit absolument implmenter les mthodes abstraites de la
classe Animal.
2. Pour pouvoir rutiliser les mthodes dj dveloppes et garder la proprit du polymorphisme, vous devez trouver un moyen dadapter les noms des anciennes mthodes aux
noms gnriques choisis dans la nouvelle version du jeu. Par exemple, pour le cas de la
classe Chat, il suffit de trouver un moyen dappeler les mthodes criChat() et formeChat()
de la classe LeChat. La solution simple qui permet de rsoudre ce problme consiste
mettre la classe LeChat dans la classe Chat. La composition permet la dlgation doprations. Ainsi, la classe Chat se contente tout simplement de dlguer les oprations quon
lui demande la classe LeChat et dutiliser par l mme le code dj dvelopp.
Figure 2.78
La classe LeChat
existante et la
nouvelle classe Chat.
Chat
La mthode crier() se
contentera dappeler la mthode
criChat() de la classe LeChat
+crier()
+forme()
LeChat
+criChat()
1 +formeChat()
Ce processus dencapsulation des classes de lancienne version est dcrit la figure 2.78.
Client
Animal{abstract}
+crier()
+ forme()
Chat
+crier()
+forme()
LeChat
+criChat()
+formeChat()
Vache
+crier()
+forme()
Lion
+crier()
+forme()
LaVache
+criVache()
+formeVache()
3. Ce mcanisme dadaptation par encapsulation peut tre utile dans le contexte dutilisation du polymorphisme. Il permet aussi de ne plus se poser de questions sur lintgration
de classes existantes lors de la phase de conception : la solution prsente ici ne prsente
aucune contrainte et peut tre utilise facilement. Il sagit dune instance du patron
Adaptateur .
Exercices
Figure 2.79
Diagramme de classes 83
Figure 2.80
Vue simplifie
du patron
Adaptateur .
ClasseCible
+mthode()
Client
Adaptateur
+mthode()
ClasseAdapte
+mthodeAdapte()
+mthode(){
instanceClasseAdapte.mthodeAdapte() ;
}
EXERCICE 21 ORGANISATION
DU LANGAGE
UML
La spcification du langage UML 2 dfinit un type de donnes comme un classeur particulier dans le paquetage Noyau. Un type de donnes est compos de plusieurs proprits et
de plusieurs oprations ordonnes. Un type primitif, comme les entiers, et un type numr
sont deux spcialisations dun type de donnes. Un type numr est compos de littraux
ordonns. Utilisez cette description et vos connaissances de la modlisation des types en
UML pour proposer le modle de classes des types de donnes.
Cette solution est extraite de la norme UML 2.0 superstructure spcification publie par
lOMG.
Figure 2.81
Classifier
Diagramme de
classes dun type
de donnes dans
le mtamodle UML.
DataType
+datatype
0..1
+ownedAttribute
{subsets namespace,
subsets featuringClassifier,
subsets classifier}
+datatype
+ownedOperation
Property
*
{ordered,
subsets attribute,
subsets ownedMember}
Operation
*
{ordered,
subsets feature,
subsets ownedMember}
InstanceSpecification
PrimitiveType
Enumeration
+enumeration
0..1
84
UML 2
{subset namespace}
+ownedLiteral
*
{ordered,
subsets ownedMember}
EnumerationLiteral
Chapitre
Diagramme
dinteraction
1. Intrt des interactions ................... 86
2. Diagramme de squence
en dtail ....................................... 91
3. Diagramme de communication
en dtail ..................................... 101
4. Rutilisation dune interaction ...... 104
Problmes et exercices
1. Syntaxe des messages.................. 107
2. Ajouter un aspect dynamique
un diagramme de classes
et traduction dun diagramme
de squence en diagramme
de communication ....................... 109
3. Messages synchrones vs messages
asynchrones ................................ 111
4. Messages perdus, trouvs ou
envoys dans des flots dexcution
parallles .................................... 114
5. Fragments dinteraction combins
pour dcrire une mthode
complexe .................................... 115
6. Oprateurs dinteraction .............. 116
7. Diagrammes de squence
pour illustrer des cas dutilisation .. 117
8. Fragments dinteraction combins . 120
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
(1)
EXEMPLE
Le diagramme de classes prsent la figure 3.1 montre la structure interne dun systme de
pilotage automatique compos des trois classes : PiloteAutomatique, Voiture et Moteur. Ce
diagramme nindique pas comment le pilotage est ralis. Pour ajouter un aspect dynamique
la modlisation, il faut descendre au niveau des instances et montrer comment elles
interagissent.
Des instances de ces classes peuvent figurer sur un diagramme dinteraction particulier,
appel diagramme de communication (figure 3.2). Dans cet exemple, les instances
senvoient les messages dmarrer et allumer. Pratiquement, lenvoi des messages dclenche
lappel des mthodes dmarrer et allumer, ce qui a pour effet de consulter ou de changer
ltat de la voiture et du moteur respectivement.
Plus gnralement, une interaction montre le comportement dun classeur tel quun sous-systme,
un cas dutilisation, une classe, un composant, etc.
Figure 3.1
PiloteAutomatique
Diagramme de
classes dun systme
de pilotage
automatique.
Figure 3.2
Voiture
Moteur
dmarrer()
allumer()
com Piloter
Diagramme de
communication dun
systme de pilotage
automatique.
dmarrer
unPilote : PiloteAutomatique
uneVoiture : Voiture
allumer
leMoteur : Moteur
Dfinition
Une interaction dcrit le comportement dun classeur en se focalisant sur lchange dinformations entre les lments du classeur. Les participants une interaction sont appels
lignes de vie .
Une ligne de vie reprsente un participant unique une interaction.
Le terme ligne de vie est utilis car, souvent, les interactions montrent des objets (instances de classes). Au cours dune interaction, des objets peuvent tre crs, utiliss, et
parfois dtruits. Ce cycle de vie des objets est matrialis par une ligne (la ligne de vie) qui
court dans les diagrammes dinteraction (figure 3.3).
UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme
de squence et celui de communication. Une mme interaction peut tre reprsente aussi
bien par lun que par lautre.
86
UML 2
Chapitre
EXEMPLE
Figure 3.3
Un diagramme de
squence la place
dun diagramme
de communication.
unPilote : PiloteAutomatique
sens du
temps
uneVoiture : Voiture
leMoteur : Moteur
dmarrer
allumer
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 diagramme dinteraction : le diagramme de timing. Son usage est limit la modlisation des
systmes qui sexcutent sous de fortes contraintes de temps, comme les systmes temps
rel. Cependant, mme dans ces situations extrmes, les diagrammes de squence conviennent bien souvent. Cest la raison pour laquelle les diagrammes de timing ne sont pas
abords dans cet ouvrage. Le lecteur intress trouvera dans le manuel de rfrence dUML
2.0 [Rumbaugh 2004] des explications sur le sujet.
Notation
Un diagramme dinteraction se reprsente par un rectangle (figure 3.4) contenant, dans
le coin suprieur gauche, un pentagone accompagn du mot-cl sd lorsquil sagit dun
diagramme de squence, et de com lorsquil sagit dun diagramme de communication.
Le mot-cl est suivi du nom de linteraction. La liste des lignes de vie qui figurent dans le
diagramme peut suivre le nom de linteraction. Des attributs peuvent tre indiqus prs du
sommet du rectangle contenant le diagramme. La syntaxe de ces attributs est la mme que
celle des attributs dune classe (voir chapitre 2).
Une ligne de vie se reprsente par un rectangle auquel est accroche une ligne ver ticale
pointille. Le rectangle contient un identifiant dont la syntaxe est la suivante :
[<nomDeLaLigneDeVie> [[slecteur]]]: <NomDeClasseur> [dcomposition]
Diagramme dinteraction 87
Figure 3.4
Un diagramme
de squence dun
distributeur de billets.
Contrainte sur la
valeur de lattribut
Attribut de linteraction
Ligne de vie
: Distributeur
comBanque : Reseau
Client
introduireCarte
affichercranSaisieCode
saisieCode( code )
vrifierCode( code )
banqueOK = vrifierCode( _ )
1.1 UTILISATION
DES INTERACTIONS
Les diagrammes dinteraction sont utiliss tout au long du cycle de vie dun projet (depuis
le recueil des besoins jusqu la phase de conception). Ils servent dcrire les cas dutilisation dans les phases en amont, modliser la mise en uvre dune classe ou dune opration
dune classe et, plus gnralement, ajouter un aspect dynamique la modlisation dun
systme.
Le diagramme de classes modlise avant tout le domaine dans lequel le systme sera utilis ;
ce domaine, celui dune banque par exemple, est relativement indpendant des applications
bancaires qui viennent se greffer dessus ; limplmentation dun diagramme de classes nest
quune base de dveloppement pour des applications ; ce qui caractrise une application,
cest la faon dont elle utilise le diagramme de classes, ou plus prcisment, comment des
instances des classes interagissent pour raliser les fonctionnalits de lapplication ; sans cet
aspect dynamique, un systme serait purement statique et noffrirait aucune fonctionnalit.
Lapproche objet du dveloppement dun systme recommande une conception modulaire
(de sorte que les parties du systme soient rutilisables). Le langage de modlisation doit
permettre la reprsentation de cette modularit. Il nest pas souhaitable de faire figurer toutes les interactions sur un seul diagramme. Le modlisateur doit pouvoir focaliser son attention sur un sous-ensemble dlments du systme et tudier leur faon dinteragir pour
donner un comportement particulier au systme. UML permet de dcrire un comportement limit un contexte prcis de deux faons : dans le cadre dun classeur structur ou
dans celui dune collaboration.
88
UML 2
Chapitre
EXEMPLE
Considrons une classe qui est dcompose pour montrer sa structure inter ne (figure 3.5) :
une classe Moteur est compose des classes Allumage et Bougie. Un diagramme de squence
montre comment les bougies et lallumage interagissent pour dmarrer le moteur.
Figure 3.5
Moteur
Un diagramme
de squence
pour illustrer le
comportement
interne dune classe.
sd allumer moteur
interaction
boucle pour
allumer les
bougies
structure interne
de la classe
: Allumage
loop( 1,4)
: Allumage
bougie [ i ] : Bougies
allumer
1..4
: Bougies
Les classeurs structurs sont surtout utiliss dans la phase de conception dun systme,
quand on dtermine la faon dont il va tre ralis. Le concepteur prend pour point de
dpart les classeurs mis en vidence au moment de lanalyse ; il dcide de leur structure
interne et illustre ventuellement leur comportement par des interactions. Les classeurs
ainsi structurs sont repris par les dveloppeurs qui implmentent une solution.
Dfinition
Une collaboration montre des instances qui collaborent dans un contexte donn pour mettre en uvre une fonctionnalit dun systme.
EXEMPLE
La figure 3.6 montre une collaboration entre instances pour raliser une transaction immobilire.
Notation
Une collaboration se reprsente par une ellipse en trait pointill comprenant deux compartiments. Le compartiment suprieur contient le nom de la collaboration ayant pour syntaxe :
<nomDuRle>[: <NomDuType>][multiplicit]
Diagramme dinteraction 89
Figure 3.6
venteImmobilire
Diagramme
de collaboration
dune transaction
immobilire.
acqureur : Personne
contratVente : Transaction
propritaire : Personne
notaire : Notaire
connecteur
Comme dans les classeurs structurs, des connecteurs relient les instances dune collaboration. Un connecteur reprsente souvent une association transitoire (tablie le temps que
dure la collaboration concrtement, ce peut tre largument dune mthode, une variable
locale, une association).
Notation
Une collaboration peut aussi se reprsenter par une ellipse sans compar timent, portant le
nom de la collaboration en son sein (figure 3.7). Les instances sont relies lellipse par
des lignes qui portent le nom du rle de chaque instance.
Figure 3.7
Reprsentation
possible dune
collaboration.
propritaire
Personne
venteImmobilire
contratVente
Transaction
acqureur
notaire
Notaire
Les interactions au sein dune collaboration peuvent tre reprsentes par un diagramme
dinteraction comme le montre la figure 3.8.
Figure 3.8
Un diagramme
de squence
pour illustrer
une collaboration.
sd venteImmobilire
notaire : Notaire
contratVente : Transaction
propritaire : Personne
tablir
signer
signer
90
UML 2
acqureur : Personne
Chapitre
(2)
Notation
Un message synchrone se reprsente par une flche lextrmit pleine qui pointe sur le
destinataire du message (figure 3.9). Ce message peut tre suivi dune rponse qui se
reprsente par une flche en pointill.
Un message asynchrone se reprsente par une flche lextrmit ouverte (figure 3.10).
La cration dun objet est matrialise par une flche qui pointe sur le sommet dune ligne
de vie (figure 3.11).
La destruction dun objet est matrialise par une croix qui marque la fin de la ligne de vie
de lobjet (figure 3.12).
Figures 3.9
et 3.10
Reprsentation dun message synchrone (3.9) et dun message asynchrone (3.10).
Figures 3.11
et 3.12
nouvelObjet : Classe
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
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
Messages asynchrones
reus dans un ordre
diffrent de lordre
denvoi.
: Client
: Serveur
question
question
2.1 MESSAGE
ET VNEMENTS
Linvocation dune opration ou lenvoi dun signal peut dclencher une raction chez le
rcepteur. La raction la plus courante est lexcution dune mthode (rappel : une mthode
est limplmentation dune opration). Ce nest cependant pas la seule raction possible. Par
exemple, un signal derreur (souvent appel exception ) peut tre interprt comme une
simple alerte qui ne dclenchera pas ncessairement lexcution dune mthode. Mme
dans le cas de linvocation dune opration, il nest pas vident que linvocation soit suivie
de lexcution dune mthode : dans les middlewares objets qui forment aujourdhui
lossature des systmes dinformations des entreprises, des objets sont rpartis sur un rseau
dordinateurs ; linvocation se fait donc distance et des erreurs de transmission peuvent
empcher le message dinvocation darriver au rcepteur.
UML permet de sparer clairement lenvoi du message de sa rception, ainsi que le dbut de
lexcution de la raction de sa fin. Des vnements sont utiliss pour marquer chaque tape.
Ainsi, la transmission dun message est contrle par loccurrence de deux vnements : un
pour lenvoi et un pour la rception.
EXEMPLE
La figure 3.14 montre un diagramme dinteraction o un message envoy provoque lexcution dune mthode chez le rcepteur.
Figure 3.14
Diagramme
de squence
o figurent,
pour explication,
les occurrences
dvnement.
sd Retrait argent
: Distributeur
vnement denvoi
Client
introduireCarte
vnement de
rception
92
UML 2
vnement de
dbut dexcution
vnement de fin
dexcution
Chapitre
Notation
La spcification de lexcution dune raction se fait par un rectangle blanc ou gris plac
sur la ligne de vie (figure 3.14). Autre notation : un rectangle portant un label.
EXEMPLE
Figure 3.15
sd Retrait argent
Autre spcification
dune excution.
: Distributeur
vnement
de rception
vnement
denvoi
vnement de
dbut dexcution
introduireCarte
vrifierCarte
vnement de fin
dexcution
Grce aux vnements denvoi et de rception, UML dfinit trois types de messages :
Un message complet est tel que les vnements denvoi et de rception sont connus.
Un message perdu est tel que lvnement denvoi est connu, mais pas lvnement de
rception.
Un message trouv est tel que lvnement de rception est connu, mais pas lvnement
dmission.
Ces diffrents messages se reprsentent de la faon suivante.
Notation
Un message complet se reprsente par une simple flche dirige de lmetteur vers le rcepteur. Un message perdu se reprsente par une flche qui pointe sur une boule noire (figure
3.16). Une flche qui part dune boule noire symbolise un message trouv (figure 3.17).
Figure 3.16
Reprsentation dun
message perdu.
Figure 3.17
Reprsentation dun
message trouv.
Diagramme dinteraction 93
2.2 SYNTAXE
DES MESSAGES
UML permet de modliser tout type de systme. Mais bien souvent, les implmentations se
font via des langages de programmation. Dans la plupart des cas, la rception dun message
est suivie de lexcution dune mthode dune classe. Cette mthode peut recevoir des arguments et la syntaxe des messages permet de transmettre ces arguments.
Notation
La syntaxe des messages est :
<nomDuSignalOuDeOpration> [( [<argument>, )]
Par dfaut, les paramtres transmis ne peuvent pas tre modifis par le rcepteur (les arguments sont en entre ). Pour indiquer que des paramtres peuvent tre modifis (argument
en sortie ou en entre/sortie ), il faut crire :
<nomDuParamtreEnSortie> [: <valeur de largument> ]
Quand un message doit transmettre uniquement la valeur des arguments, le caractre - peut
tre utilis en lieu et place de nimporte quel argument pour signifier : valeur indfinie. Le
caractre * peut tre utilis en lieu et place du message complet. Il signifie que tout type de
message est accept.
EXEMPLE
Notation
La syntaxe de rponse un message est la suivante :
[<attribut> =] message [: <valeur de retour> ]
EXEMPLE
94
UML 2
Chapitre
Figure 3.18
Exemple dun
message de
rponse.
sd Rechercher livre
+nombreLivres : integer { nombreLivres >= 0 }
: Mdiathque
Client
chercher( "Tintin" )
nombreLivres = chercher( "Tintin" ) : 42
2.3 CONTRAINTES
La figure 3.18 contient un attribut, nombreLivres, auquel est accole une contrainte qui
limite les valeurs possibles du nombre de livres. Les lignes de vie dune interaction peuvent
aussi porter toutes sortes de contraintes. Si la ligne de vie est un objet par exemple, une
contrainte sur la valeur dun attribut peut tre pose.
EXEMPLE
La figure 3.19 montre que, pour dmarrer le moteur dun avion, il est impratif de vrifier le
niveau dessence ; aprs vrification lattribut essence doit avoir une valeur suprieure 0.
Figure 3.19
sd Piloter Avion
Exemple dune
contrainte sur
une ligne de vie.
: Pilote
: Avion
dmarrerMoteur()
contrainte
assert
vrifierEssence()
{ Avion.essence > 0 }
dcoller()
Notation
Une contrainte est indique sur une ligne de vie par un texte entre accolades.
Une contrainte peut aussi tre contenue dans une note attache loccurrence de lvnement sur lequel elle agit.
Diagramme dinteraction 95
Remarque
Un diagramme dinteraction peut dcrire des messages non valides, cest--dire qui ne doivent absolument pas tre envoys : dans le cas de la modlisation dune centrale nuclaire
par exemple, il est trs important de prvoir les squences des messages invalides.
COMBINS
Les langages de programmation sont limits par leur syntaxe. Certes, ils permettent
dcrire des tests et des boucles trs simplement. Par contre, crire un programme avec des
flots dinstructions devant sexcuter en parallle nest pas simple (il faut crire des instructions pour crer, soit des tches, soit des threads, puis utiliser dautres instructions pour
synchroniser les flots dinstructions). UML, sans tre un langage de programmation,
propose une syntaxe qui se veut complte. Quand le modlisateur doit reprsenter une
situation complexe, UML permet de dcomposer une interaction en fragments suffisamment simples pour les faire tenir sur un schma. La combinaison des fragments permet
de reconstituer la complexit du systme. Le terme gnrique en vigueur pour UML est
fragments combins .
EXEMPLE
La figure 3.20 montre comment reprsenter, laide dUML, lquivalent du test des langages
de programmation.
Figure 3.20
sd Retrait argent
Reprsentation
dun choix dans
un diagramme
de squence.
: Client
: Distributeur
condition
du choix
choixTypeRetrait
( EurosOuDollards )
Oprateur dinteraction
alt
[ EurosOuDollards == Euros ]
affichercranEnFranais
Sparateur doprandes
[ else ]
affichercranEnAnglais
Notation
Un fragment combin se reprsente de la mme faon quune interaction : par un rectangle
dont le coin suprieur gauche contient un pentagone. Dans le pentagone figure le type de
la combinaison (appel oprateur dinteraction ).
la figure 3.20, loprateur dinteraction alt indique que le fragment est un choix. Les deux
options de choix sont appeles oprandes de loprateur alt .
96
UML 2
Chapitre
Notation
Les oprandes dun oprateur dinteraction sont spars par une ligne pointille. Les conditions de choix des oprandes sont donnes par des expressions boolennes entre crochets.
La liste suivante regroupe les oprateurs dinteraction par fonctions :
les oprateurs de choix et de boucle : alternative, option, break et loop ;
les oprateurs contrlant lenvoi en parallle de messages : parallel et critical region ;
les oprateurs contrlant lenvoi de messages : ignore, consider, assertion et negative ;
les oprateurs fixant lordre denvoi des messages : weak sequencing, strict sequencing.
EXEMPLE
La figure 3.21 montre comment une boucle peut tre reprsente. Lexemple illustre la fermeture en boucle de toutes les portes dun train.
Notation
La syntaxe dune boucle est la suivante :
loop [( <minint> [, <maxint> ] ) ]
o la boucle est rpte au moins minint fois avant quune ventuelle condition boolenne
ne soit teste (la condition est place entre crochets sur la ligne de vie) ; tant que la condition est vraie, la boucle continue, au plus maxint fois (minint est un entier suprieur ou gal
0, maxint est un entier suprieur ou gal minit).
loop( valeur ) est quivalent loop( valeur, valeur ).
loop est quivalent loop ( 0, * ), o * signifie illimit .
Figure 3.21
Diagramme de
squence montrant
une boucle.
sd Dmarrer train
: Conducteur
: Train
porte[ i ] : Porte
fermerPortes()
loop(1, n)
fermer()
Loprateur par permet denvoyer des messages en parallle. Ses oprandes se droulent en
parallle. Plus prcisment, les vnements qui jalonnent un oprande (lenvoi du message,
la rception du message) forment une trace. Soumise loprateur par, la trace dun oprande est conserve (lordre des vnements est le mme), mais les diffrentes traces des
diffrents oprandes sentrelacent nimporte comment. En consquence, la trace finale,
obtenue par la fusion des traces des oprandes, peut varier dun droulement lautre. La
figure 3.22 montre un exemple.
Diagramme dinteraction 97
Les oprateurs ignore et consider permettent de focaliser lattention du modlisateur sur une
partie des messages qui peuvent tre envoys durant une interaction. Quand de nombreux
messages sont possibles, certains sont importants, dautres moins. Le modlisateur peut
choisir de ne pas tenir compte de tous les messages. Pour un systme en phase de test par
exemple, de nombreux messages servent tester exhaustivement le bon fonctionnement du
systme mais ne seront pas mis lors dune utilisation particulire (quand le systme sera en
production). Loprateur ignore dfinit lensemble des messages ignorer, tandis que loprateur consider dfinit lensemble de ceux quil faut prendre en compte. la figure 3.23, un
oprateur assert sapplique au message fermer. Ce message doit imprativement tre envoy
avant que le train puisse dmarrer.
Figure 3.22
sd
Utilisation de
loprateur par.
:A
:B
par
a
oprandes qui
se droulent
en parallle
EXEMPLE
La figure 3.23 est un exemple dutilisation des oprateurs assert, ignore et consider.
Figure 3.23
Utilisation des
oprateurs ignore,
consider et assert.
: Conducteur
: Portes
assert
fermer()
dmarrer()
Notation
La syntaxe de loprateur ignore est :
ignore { listeDesNomsDesMessagesIgnorer }
Dans les listes, les messages sont spars par des virgules.
98
UML 2
: Moteur
Chapitre
Loprateur strict sequencing impose que ses oprandes se droulent dans lordre strict de
leur prsentation, cest--dire de haut en bas. Lordre impos ne sapplique qu ses oprandes,
et dventuels fragments imbriqus peuvent avoir, en interne, un squencement quelconque.
EXEMPLE
La figure 3.24 illustre un scnario de dcollage dun avion qui utilise loprateur strict sequencing. Avant de faire dcoller un avion, il faut contrler sa ckeck-list. Le dtail des interactions
pour contrler la check-list et pour faire dcoller lavion nest pas donn. Dautres diagrammes rfrencs sous le label ref sen chargent.
Figure 3.24
Droulement des
oprandes dun
oprateur dans
un ordre strict.
: TourDeContrle
strict
: Pilote
: Avion
ref
Contrler check list
ref
Procdure de dcollage
LIGNE DE VIE
Parfois, une interaction est trop complexe pour tre dcrite sur un seul diagramme. UML
permet de dcomposer volont une ligne de vie sur plusieurs diagrammes.
EXEMPLE
Lexemple suivant modlise un contrle daccs pour entrer dans un btiment. La ligne de vie
SystmeContrleAccs a un comportement complexe dcrit sur un diagramme spar : SystmeContrleAccsUtilisateur (figure 3.26).
Notation
Une dcomposition est rfrence dans le rectangle en tte de ligne de vie, sous le label ref
(figure 3.25).
la figure 3.26, la ligne de vie PointDAccs est dcompose en deux lignes p1 et p2.
Cette notation est une autre manire de dcomposer une ligne de vie dans un diagramme
dinteraction.
On remarque la figure 3.26, la prsence dun message entrant vrifier( code ) et dun
message sortant message( "Entrez!" ) ; ces messages entrent et sortent du diagramme
par un point appel porte . Ces mmes messages sont prsents sur le diagramme de la
figure 3.25.
Diagramme dinteraction 99
Dfinition
Une porte est un point de connexion qui permet de relier un mme message reprsent par
des flches diffrentes dans plusieurs fragments dinteraction.
Figure 3.25
Dcomposition
dune ligne de vie.
sd vrifier accs
+code : integer { 1000 <= code <= 9999 }
: SystmeContrleAccs
ref SystmeContrleAccsUtilisateur
: Utilisateur
vrifier( code )
ref
VrifierAccs( code )
Rfrences des
diagrammes existants
ref
[ code ok ]
message( "Entrez !" )
ref
OuvrirPorte
Figure 3.26
sd SystmeContrleAccsUtilisateur
Ligne de vie
dcompose.
p1
: Contrleur
P2
vrifier( code )
ref
SystmeVrifierAccs( code )
portes
opt
[ code ok ]
message( "Entrez !" )
opt
SystmeOuvrirPorte
100
UML 2
Chapitre
2.6 LES
TATS INVARIANTS
Une ligne de vie peut aussi reprsenter un classeur ayant un comportement complexe. Cest
le cas des instances de classes qui peuvent tre dans plusieurs tats (voir chapitre 4). Il est
possible de placer un certain tat dune machine tats sur une ligne de vie.
Dfinition
Un tat est dit invariant lorsquil reste constant sur une ligne de vie, cest--dire lorsquil
ne change pas quel que soit le contexte dexcution de linteraction.
EXEMPLE
La figure 3.27 montre un tat plac sur une ligne de vie. Au moment de lexcution de linteraction, ltat est test conformment la machine tats spcifie.
Figure 3.27
Ajouter le contrle
de ltat dune
ligne de vie dans
une interaction.
sd Piloter Avion
: Avion
: Pilote
contrler()
AvionPrtAuDcollage
dcoller()
(3)
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
Un diagramme de
communication pour
illustrer la fermeture
des portes dun
train.
fermerPortes()
: Train
1 : fermerLesPortes()
connecteur
portes : Portes
ligne de vie
numro de squence
itration
nom de rle
nom de classe
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
Chapitre
Les connecteurs peuvent montrer la multiplicit des lignes de vie qui participent une
interaction, comme le montre la figure 3.29.
Figure 3.29
Reprsentation de
la multiplicit dans
un diagramme de
communication.
fermerPortes()
: Train
multiplicit
fermerPorte()
*
porte : Porte
3.1 NUMROS
3.2 MESSAGES
Il est possible denvoyer des messages simultanment dans des flots dexcution qui se
droulent en parallle (dans les applications multitches ou multithreads, plusieurs flots
dinstructions sexcutent en parallle et une mme mthode peut tre excute simultanment dans plusieurs flots). Les flots parallles sont dsigns par des lettres (a, b).
EXEMPLE
Figure 3.30
Envoi dun message
dans des flots
dexcution
parallles.
La figure 3.30 illustre le parcours dun arbre binaire : le message visiter est envoy aux deux
fils (gauche et droit) dun nud pre ; ce message est transmis deux flots parallles portant
les lettres a et b.
com Parcourir nud arbre
visiter()
pre : Nud
3.3 OPRATEURS
DE CHOIX ET DE BOUCLE
Notation
* [ <clause ditration> ] reprsente une itration (figure 3.28). La clause ditration
peut tre exprime dans le format i := 1n.
[ <clause de condition> ] reprsente un choix. La clause de condition est une condition
boolenne.
3.4 SYNTAXE
DES MESSAGES
Notation
La syntaxe complte des messages est (voir les exemples ci-aprs) :
[ <numro_squence> ] [ <expression> ]: <message>
EXEMPLE
(4)
EXEMPLE
104
UML 2
La figure 3.31 montre le travail dun contrleur arien. Un pilote vrifie la check-list de son
avion (le diagramme correspondant appel contrlerCheckList nest pas dcrit en dtail mais
simplement rfrenc). La check-list est transmise en argument car elle est utilise par linteraction contrlerCheckList. Cette interaction retourne un boolen qui est affect lattribut ok de
lavion. Lorsque le contrleur demande contrler lavion, le boolen ok est test. Si lavion
Chapitre
est prt partir, son plan de vol est valid ; dans le cas contraire, le plan de vol est invalid.
Linteraction contrleAvion (dont le nom figure dans le pentagone en haut gauche du diagramme) reoit en argument une instance de CheckList. Cet argument est en entre/sor tie
(inout) car il est utilis dans le diagramme et pourra ser vir encore dans un autre diagramme
qui rfrencera contrleAvion. contrleAvion retourne un rsultat du type PlanDeVol. Linstance correspondante est la ligne de vie appele planDeVol dans le diagramme.
Figure 3.31
Utilisation dune
interaction avec des
arguments et une
valeur de retour.
Instance du PlanDeVol
retourne
: Pilote
: Avion
checkList : CheckList
planDeVol
ref
:Avion.ok = contrlerCheckList( checkList )
contrler()
alt
[ ok == true ]
valider()
[ ok == false ]
invalider()
Notation
Rutiliser une interaction consiste placer un fragment portant la rfrence ref l o linteraction est utile. La syntaxe complte pour spcifier linteraction rutiliser est la suivante :
[ <nomAttributPourValeurRetour> =] <nom de linteraction>
[( [<argument>], ) ] [: <valeur de retour> ]
La valeur de retour est affecte un attribut. Les arguments peuvent tre en entre (ils portent alors la marque in), en sortie (out), ou en entre et en sortie (inout).
Conclusion
Les diagrammes de squence et de communication montrent laspect dynamique dun systme. Ce ne sont pas les seuls : les diagrammes dactivit et les diagrammes dtats-transitions,
prsents aux chapitres suivants, dcrivent eux aussi un systme sous cet angle. Cependant,
les diagrammes de squence et de communication sont mieux appropris la description
des interactions entre les lments dun systme.
Une interaction montre un comportement typique dun systme dans un contexte donn.
Le contexte est dlimit par un classeur structur ou une collaboration. La vision du systme donne par les diagrammes dinteraction est donc partielle (car limite un contexte
donn) mais cohrente (car elle montre comment un comportement dun systme est ralis par des lments qui le compose). Une interaction peut illustrer un cas dutilisation, le
fonctionnement dun sous-systme, la mise en uvre dune classe ou dune opration. Les
diagrammes dinteraction peuvent tre affins : les interactions dcouvertes lors des phases
en amont du cycle de vie dun projet peuvent tre compltes par les modlisateurs. Chaque
intervenant na pas les mmes exigences et nenvisage pas les mmes interactions de la
mme faon. Malgr ces exigences diffrentes, il est important dassurer une continuit dans
la modlisation. Les diagrammes dinteraction peuvent tre complts mesure que la
modlisation progresse et ports un niveau de dtails requis pour limplmentation du
systme.
Diagrammes de squence et de communication peuvent dcrire une mme interaction mais
de faons diffrentes. Le modlisateur a le choix : les diagrammes de squence montrent le
squencement temporel de messages, tandis que les diagrammes de communication dcrivent
la structure spatiale des participants une interaction.
Arriv ce stade de la lecture du livre, et si vous avez parcouru les chapitres prcdents dans
lordre, vous savez prsent comment construire les trois modles essentiels dun systme :
le modle fonctionnel et externe laide du diagramme des cas dutilisation ;
le modle structurel et interne grce au diagramme des classes ;
le modle des interactions au sein du systme avec les diagrammes de squence et de
communication.
partir de l, vous pouvez passer directement au chapitre 6 pour voir sur une tude de cas
comment tous ces modles sassemblent, ou continuer la lecture des chapitres suivants.
Deux diagrammes supplmentaires y sont prsents :
le diagramme dtats-transitions ;
le diagramme dactivits.
Les diagrammes dtats-transitions sont utiliss avant tout pour dcrire le cycle de vie
des objets dun systme : tout objet est forcment cr un moment donn, utilis via les
mthodes de la classe dont il est issu et, ventuellement, dtruit sil devient inutile. Les diagrammes dactivits sont des organigrammes. Ils montrent les flots de contrle qui grent
les activits dun systme. Ils permettent de modliser tout processus squentiel (un processus de fabrication industriel, le fonctionnement dun systme dinformation, le corps dune
opration).
106
UML 2
Chapitre
Problmes
et exercices
Les diagrammes dinteraction reposent sur la transmission de messages. Avant
dutiliser les interactions, il est ncessaire de matriser la syntaxe des messages, qui
est riche et complexe. Parmi les premiers exercices, certains sont consacrs la
syntaxe, dautres aux diffrents types de messages (synchrone, asynchrone, perdu,
trouv). Plusieurs exercices montrent lquivalence entre les diagrammes de
squence et de communication. Une fois ces notions de base matrises, vous
pourrez raliser les exercices suivants, qui mettent en pratique les diagrammes
dinteraction. Bien souvent, ces diagrammes sont utiliss pour ajouter un aspect
dynamique au modle du diagramme de classes. Le lien entre diagramme de
classes et diagramme dinteraction est illustr par des exercices, tout comme les
autres utilisations des interactions (dcrire un cas dutilisation, une opration, le
comportement dun classeur structur ou dune collaboration). Tout au long des
exemples, il est fait appel aux fragments dinteraction combins, qui permettent
denrichir les modles.
SYNTAXE
DES MESSAGES
Exercices
EXERCICE 1
108
UML 2
Chapitre
EXERCICE 2
AJOUTER
Le diagramme de classes prsent la figure 3.32 modlise un robot qui dispose dun bras
articul se terminant par une pince. Le fonctionnement du robot est le suivant : le robot
dplie son bras, attrape la pice avec sa pince, replie son bras puis relche la pice.
Figure 3.32
Diagramme
de classes
dun robot.
Robot
chercherPice
BrasArticul
Pince
dplier
replier
ouvrir
fermer
1. Reprsentez laide dun diagramme de squence lchange des messages entre les
objets robot, brasArticul et pince.
2. Transformez le diagramme de squence en un diagramme de communication.
3. crivez en pseudo-code les classes Robot, BrasArticul et Pince.
Figure 3.33
sd Attraper pice
Diagramme de
squence du robot.
: Robot
chercherPice
: BrasArticul
: Pince
dplier
fermer
porte
replier
Exercices
ouvrir
en consquence le numro 1.1 ; le message fermer (numro 1.1.1) est embot dans le
message dplier. Le mme raisonnement a permis de numroter les messages replier et
ouvrir.
Figure 3.34
Diagramme de
communication
quivalent au
diagramme de
squence de la
figure 3.33.
1 : chercherPice()
1.1 : dplier
: Robot
: BrasArticul
1.2 : replier
1.1.1 : fermer
1.2.1 : ouvrir
: Pince
3. Le pseudo-code montre que lobjet brasArticul est inclus dans la partie des attributs de la
classe Robot. Cest la faon la plus courante dimplmenter une relation de composition :
le robot est compos dun bras articul. Il en est de mme des classes BrasArticul et
Pince.
class Robot{
prive:
BrasArticul brasArticul;
publique:
void chercherPice(){
brasArticul.dplier();
brasArticul.replier();
}
}
class BrasArticul {
prive:
Pince pince;
publique:
void dplier (){
pince.fermer();
}
void replier (){
pince.ouvrir();
}
}
class Pince {
prive:
publique:
void fermer (){
110
UML 2
Chapitre
void ouvrir (){
}
Dbut programme principal
Robot robot;
robot.chercherPice();
Remarque
Les associations sont souvent implmentes comme des attributs. Il ne faut cependant pas
confondre les deux (voir chapitre 2). Malheureusement, de nombreux langages de programmation ne permettent pas de faire la distinction.
Lannexe E donne des indications pour implmenter un modle objet avec le langage de
programmation Java.
EXERCICE 3
MESSAGES
Compltez les messages des figures 3.35 3.39 en choisissant le type de message appropri
(synchrone ou asynchrone).
1. Envoi dun message pour calculer la valeur de la constante pi avec 3 dcimales.
Figure 3.35
Calcul de Pi avec
3 dcimales.
: ProgrammePrincipal
Envoi du message
Message de rponse
: FonctionDeCalculDePi
calculerPI( nombreDcimales = 3 )
PI = calculerPI( nombreDcimales = 3 )
Figure 3.36
: ProgrammePrincipal
Envoi du message
Message de rponse
: FonctionDeCalculDePi
Exercices
Calcul de pi avec
3 000 dcimales.
Figure 3.37
: metteur
Transmission
dun courrier
lectronique.
: Destinataire
transmettre( message )
Figure 3.38
Transmission
dun courrier
lectronique
via un serveur
de messagerie.
: metteur
: ServeurDeMessagerie
: Destinataire
poster( message )
message = rcuprer
Figure 3.39
Transmission dun
courrier deux
destinataires.
: metteur
destinataire1 : Destinataire
destinataire2 : Destinataire
transmettre( message )
transmettre( message )
1. On considre que le programme principal est actif tout le temps. Le calcul de pi avec
3 dcimales ne doit pas prendre beaucoup de temps. Le programme principal peut donc
tre bloqu par un appel synchrone de la mthode calculerPI le temps deffectuer le calcul
(figure 3.40).
Figure 3.40
objet actif
Calcul de Pi avec
3 dcimales utilisant
un message
synchrone.
: ProgrammePrincipal
calculerPI( nombreDcimales = 3 )
objet actif
112
UML 2
: FonctionDeCalculDePi
PI = calculerPI( nombreDcimales = 3 )
objet passif
Chapitre
Remarque
La tte de la ligne de vie ProgrammePrincipal contient deux traits ver ticaux qui indiquent
que lobjet est actif. Le double trait qui court tout au long de la ligne de vie indique aussi un
objet actif. Ces deux notations prsentes simultanment sont redondantes. Dans un diagramme de squence, les deux traits verticaux dans la tte de la ligne de vie sont superflus,
tandis que dans un diagramme de communication, comme aucun pointill nindique la
dure de vie dun objet, ces deux traits sont indispensables (figure 3.48).
Un objet actif possde son propre thread de contrle, cest--dire quon peut lui appliquer
des mthodes dans un flot dexcution indpendant des autres flots dexcution existants.
Un objet passif, au contraire, a besoin quon lui donne un flot de contrle pour lui appliquer une mthode.
2. Calculer Pi avec 3 000 dcimales peut prendre du temps. Dans ce cas, il vaut mieux utiliser un message asynchrone pour ne pas bloquer le programme principal le temps deffectuer le calcul (figure 3.41).
Figure 3.41
: ProgrammePrincipal
Calcul de Pi avec
3 000 dcimales
utilisant un message
asynchrone.
: FonctionDeCalculDePi
3. La rception dun courrier lectronique peut se faire nimporte quand aprs lmission. Il
ne faut donc pas bloquer lmetteur et utiliser un message asynchrone (figure 3.42).
Figure 3.42
: metteur
Transmission
asynchrone
dun courrier
lectronique.
: Destinataire
transmettre( message )
4. Lmetteur et le destinataire sont des objets actifs qui sont bloqus le temps denvoyer ou
de rcuprer un courrier (figure 3.43).
Figure 3.43
Transmission
synchrone dun
courrier lectronique
via un serveur de
messagerie.
: metteur
: ServeurDeMessagerie
: Destinataire
poster( message )
5. Les transmissions sont asynchrones et les messages peuvent tre reus dans un ordre
diffrent de lordre denvoi (figure 3.44).
Exercices
message = rcuprer
Figure 3.44
: Destinataire
Transmission dun
courrier deux
destinataires
via des messages
asynchrones.
destinataire1 : Destinataire
transme
destinataire2 : Destinataire
ttre( me
transmettre( message )
ssage )
Remarque
La dure de transmission dun message peut tre indique en ajoutant des contraintes sur
un diagramme, comme le montre la figure 3.45.
Figure 3.45
Contraintes de
dure exprimes
sur un diagramme.
: Destinataire
: metteur
transmett
re( mess
{ < 1 jour }
age )
transmettre( message )
transmettre( message )
d
{ d - d < 1 jour }
EXERCICE 4
Compltez les messages des figures 3.46 et 3.47 en choisissant le type de message appropri
(perdu, trouv ou sexcutant dans des flots dexcution parallles).
1. Demande dexcution de deux programmes par un systme dexploitation.
Figure 3.46
Demande
dexcution de
programmes.
: SystmeDExploitation
excuter( programme = "lecteur CD" )
excuter( programme = "diteur de texte" )
: Processeur
Figure 3.47
Transmission
dun virus un
ordinateur.
114
UML 2
virus : Virus
: Ordinateur
Chapitre
1. Si le systme dexploitation est considr comme multitche, lexcution des deux programmes se fait simultanment, dans deux flots dexcution parallles nots a et b.
Figure 3.48
objet actif
Envoi simultan
de deux messages.
: SystmeDExploitation
a : excuter( programme = "lecteur CD" )
b : excuter( programme = "diteur de texte" )
: Processeur
Figure 3.49
: Virus
Utilisation de
messages perdu
et trouv.
diffuser( virus )
attraper( virus )
message perdu
message trouv
FRAGMENTS DINTERACTION
COMPLEXE
o n 0 et factoriel( 0 ) = 1.
Reprsentez le programme prcdent sur un diagramme de squence.
La solution (figure 3.50) utilise loprateur alternative pour raliser le test sur la valeur de n.
Notez aussi la superposition dune deuxime ligne de vie sur la premire pour matrialiser
lappel rcursif de lopration factorielle. Le nom de la ligne de vie, X, est fictif.
Exercices
EXERCICE 5
: Ordinateur
Figure 3.50
Reprsentation du
calcul de la fonction
factorielle sur un
diagramme de
squence.
+f : integer
:X
factoriel( n)
[ n == 0 ]
alt
factoriel( n)
[ else ]
factoriel( n-1 )
appel rcursif
f = factoriel( n-1 )
factoriel( n ) : n * f
EXERCICE 6
OPRATEURS DINTERACTION
Dessinez un diagramme de squence qui prsente trois objets : un robot + deux capteurs
(une camra et un dtecteur de chocs). Le diagramme doit contenir un fragment dinteraction qui montre que les capteurs fonctionnent en mme temps (ils peuvent envoyer
tout moment des messages au robot).
Figure 3.51
Utilisation de
loprateur par
pour un problme
de robotique.
: Camra
par
: Robot
: DtecteurChocs
analyserImage( image )
viterObstacle()
116
UML 2
Chapitre
Remarque
Avec loprateur par, la squence des vnements dun oprande peut tre interrompue
par dautres occurrences dvnement venant dautres oprandes. cer tains moments, les
interruptions sont malvenues. Si lon ajoute au robot un pilote et un moteur (figure 3.52), le
pilote a un rle prpondrant et doit pouvoir tout moment demander larrt durgence du
robot. La demande darrt doit tre imprativement suivie de larrt du moteur du robot.
Loprateur critical est utilis pour dfinir une section critique, cest--dire une rgion dune
interaction o les traitements sont atomiques (raliss en un bloc inscable).
Parfois, lentrelacement des vnements provenant de plusieurs oprandes nest pas souhaitable pour tous les participants (les lignes de vie) une interaction. Loprateur seq empche
lentrelacement des occurrences dvnement sur une mme ligne de vie par tage par plusieurs oprandes (cest lordre des oprandes qui fixe le squencement). Lentrelacement
nest possible que sur des lignes de vie diffrentes non soumises loprateur seq.
Figure 3.52
: Pilote
: Camra
: Robot
: Moteur
: DtecteurChocs
par
analyserImage( image )
viterObstacle()
critical
arrterDUrgence()
EXERCICE 7
DIAGRAMMES
arrter ()
Figure 3.53
Gestion des emprunts
Bibliothcaire
Le fonctionnement de la bibliothque est le suivant : une bibliothque propose ses adhrents des uvres littraires ; les uvres peuvent tre prsentes en plusieurs exemplaires ;
un adhrent peut emprunter jusqu trois livres.
Exercices
Diagramme de cas
dutilisation dune
bibliothque.
Figure 3.54
Description dun
scnario nominal
laide dun
diagramme de
squence.
: Bibliothque
Bibliothcaire
rechercher un adhrent
adhrent trouv
vrifier si ladhrent peut emprunter
ladhrent peut emprunter
rechercher une uvre
uvre trouve
vrifier sil y a un exemplaire disponible pour cette uvre
Il y a un exemplaire disponible
dcrmenter le nombre dexemplaires dans la bibliothque
attribuer lexemplaire ladhrent
Remarque
Quand un diagramme de squence dcrit un cas dutilisation, le formalisme strict dUML (la
syntaxe des messages par exemple) est plus libre.
La description dun scnario par un diagramme de squence nempche pas de dcrire le
cas sous forme textuelle (voir chapitre 1), ce qui permet de faire figurer des renseignements
supplmentaires (pr- et post-conditions, contraintes).
118
UML 2
Chapitre
2. Le diagramme de la figure 3.55 complte le diagramme prcdent (figure 3.54) en
incluant la vrification de contraintes. Si une contrainte nest pas vrifie, les vnements
qui suivent cette contrainte sont invalides. De plus, la squence doit imprativement se
terminer par les deux messages dcrmenter le nombre dexemplaires dans la bibliothque et attribuer lexemplaire ladhrent cause de lutilisation de loprateur
assert.
Utilisation de
contraintes et de
loprateur assert
dans un diagramme
de squence.
: Bibliothque
Bibliothcaire
rechercher ladhrent
{ adhrent trouv }
assert
dcrmenter le nombre
dexemplaires dans la bibliothque
attribuer lexemplaire ladhrent
Le formalisme des diagrammes de squence est trs riche. Souvent, il est possible de reprsenter des scnarios de plusieurs faons. Au lieu dutiliser des oprateurs dassertion, il est
possible de recourir des oprateurs dalternative.
Exercices
Figure 3.55
La figure 3.56 prsente une troisime solution qui utilise un oprateur doption (loprateur
doption opt est identique un oprateur dalternative, mais avec un choix unique).
Figure 3.56
Utilisation des
oprateurs opt
et neg.
: Bibliothque
Bibliothcaire
rechercher ladhrent
opt
[ adhrent non trouv ]
neg
La figure 3.56 utilise loprateur negative pour indiquer que les messages sur lesquels il
sapplique sont invalides.
EXERCICE 8
FRAGMENTS DINTERACTION
COMBINS
120
UML 2
Chapitre
Figure 3.57
sd Conduire Train
Utilisation de
loprateur negative
pour interdire
louverture des
portes dun train.
: Conducteur
: Train
: Passager
dmarrer()
neg
ouvrirPorte()
EXERCICE 9
DIAGRAMMES
Lexercice 7 montre comment utiliser des diagrammes de squence pour dcrire des cas
dutilisation. Lexercice 9 prolonge lexemple de la bibliothque en partant de lhypothse
quun diagramme de classes a t construit (figure 3.58). Le but prsent est de montrer
comment des objets au cur du systme interagissent pour raliser les fonctions des cas
dutilisation.
Le diagramme de classes prsent la figure 3.58 modlise la structure interne de la bibliothque. Un adhrent peut emprunter un exemplaire dune uvre donne. Lemprunt se
fait de la faon suivante : lopration emprunter de la classe uvre est invoque pour un
adhrent donn en argument ; sil reste des exemplaires dans la bibliothque, lun des
exemplaires associs luvre est extrait via la mthode extraireExemplaire, une instance
de la classe Prt est cre, puis lexemplaire extrait de la bibliothque est attribu ladhrent grce linvocation de lopration attribuer.
Figure 3.58
Diagramme de
classes dune
mdiathque.
Prt
date
Adhrent
attribuer( Exemplaire )
Exemplaire
0..3
emprunte
uvre
1..n
extraireExemplaire() : Exemplaire
emprunter( Adhrent )
Exercices
1. Parmi les classes du diagramme prcdent (figure 3.58), donnez la liste de celles qui
permettent de raliser le comportement entour par un cercle dans le diagramme de
squence prsent la figure 3.59.
Figure 3.59
Diagramme de
squence de
lemprunt dun
livre.
: Bibliothque
Bibliothcaire
rechercher un adhrent
adhrent trouv
vrifier si ladhrent peut emprunter
ladhrent peut emprunter
rechercher une oeuvre
uvre trouve
vrifier sil y a un exemplaire disponible pour cette uvre
Il y a un exemplaire disponible
dcrmenter le nombre dexemplaires dans la bibliothque
attribuer lexemplaire ladhrent
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
Chapitre
Figure 3.60
Diagramme de
collaboration pour
lemprunt dun
exemplaire.
Argument
dune opration
uvreTrouve : uvre
adhrentTrouv : Adhrent
exemplaireDisponible : Exemplaire
: Prt
associations
3 .Le diagramme de squence est prsent la figure 3.61. Linteraction est dcompose en
fragments combins qui utilisent loprateur alternative : le choix porte sur la prsence
ou non dun exemplaire disponible dans la mdiathque. Notez la cration dune instance de la classe Prt matrialise par un message qui pointe sur la tte de la ligne de vie.
Figure 3.61
Diagramme de
squence pour
lemprunt dun
exemplaire.
uvreTrouve: uvre
exemplaireTrouv : Exemplaire
adhrentTrouv : Adhrent
emprunter( adhrentTrouv )
[ nombreExemplaires > 0 ]
alt
extraireExemplaire() : Exemplaire
: Prt
attribuer( exemplaireTrouv )
emprunter : ok
[ else ]
emprunter : non ok
Le formalisme des diagrammes de squence est trs proche de celui des langages de programmation (on peut reprsenter aisment des tests, des boucles). Les diagrammes de
squence sont principalement utiliss durant la phase danalyse. Cette tape ne doit pas
tre confondue avec les phases de conception et dimplmentation. Durant lanalyse, les
interactions servent souvent valider un diagramme de classes (en montrant comment des
instances de classes interagissent). Veillez ne pas faire ce moment-l des choix de
conception ou dimplmentation (voir chapitre 6).
Exercices
Remarque
Figure 3.62
com emprunter
Reprsentation de la
cration dun objet
et dun lien dans
un diagramme de
communication.
emprunter()
: uvre
{ nouveau }
: Prt
INTERACTION
Le diagramme de squence de lexercice 9 (figure 3.61) reprsente la fin du scnario nominal de lemprunt (partie entoure par un cercle dans le diagramme de la figure 3.59). Supprimez la partie encercle du scnario nominal et indiquez comment vous pouvez
rutiliser le diagramme de squence de la figure 3.61 la place.
Figure 3.63
Diagramme de
squence qui
rfrence une
interaction.
: Bibliothque
Bibliothcaire
rechercher un adhrent
adhrent trouv
vrifier si ladhrent peut emprunter
ladhrent peut emprunter
rechercher une uvre
uvre trouve
ref
AttributionExemplaireAAdhrent( adhrentTrouv, uvreTrouve )
124
UML 2
Chapitre
EXERCICE 11 DIAGRAMMES
UN CLASSEUR STRUCTUR
Figure 3.64
Une classe
reprsentant
une file.
File
ajouter( Donne )
extraire() : Donne
Un classeur structur peut tre utilis pour montrer la structure interne de la file (figure
3.65). Le concepteur choisit dimplmenter la file en recourant un tableau (une file est un
tableau dans lequel on a restreint les accs aux deux extrmits). Afin de dcrire le comportement du tableau lors de lextraction dun lment, le concepteur dcide dutiliser une
interaction appele Extraire de la file.
Figure 3.65
La file vue comme
un classeur
structur.
File
ref
Extraire de la file
: Tableau
Reprsentez linteraction Extraire de la file laide dun diagramme de squence. Indication : la faon la plus simple dextraire le premier lment dun tableau est de mmoriser la
valeur de celui-ci avant de dcaler les lments suivants, comme le montre la figure 3.66.
Extraire le premier
lment dun
tableau.
mmoriser
Exercices
Figure 3.66
La solution est prsente la figure 3.67, o une boucle est utilise pour raliser le dcalage.
Les oprations add et get permettent dajouter et dextraire un lment du tableau.
Figure 3.67
Un diagramme
de squence pour
illustrer lextraction
du premier lment
dune file.
sd extraire de la file
premier : Exemplaire
suivant : Exemplaire
: File
: Tableau
extraire()
get( 0 )
premier = get( 0
loop(1, n)
prcdent = get( 0 )
add(prcdent, i )
extraire() : premier
126
UML 2
Chapitre
Diagramme
dtats-transitions
1. Modlisation laide
dautomates .........................
2. Hirarchie dans les machines
tats .................................
3. Contrat de comportement .......
4. Gestion de la concurrence ......
Problmes et exercices
1. Diagramme dtats-transitions
dun individu du point de vue
de lINSEE ............................
2. Diagramme dtats-transitions
dune porte...........................
3. Diagramme dtats-transitions
dune montre chronomtre .....
4. Modlisation de la socket TCP...
133
138
139
142
143
145
148
127
(1)
1.1 TAT
Un diagramme dtats-transitions est un graphe qui reprsente un automate tats finis,
cest--dire une machine dont le comportement des sorties ne dpend pas seulement de
ltat de ses entres, mais aussi dun historique des sollicitations passes : cet historique est
caractris par un tat.
Ainsi, leffet dune action sur un objet dpend de son tat interne, qui peut varier au cours
du temps. Par exemple, considrez une lampe munie de deux boutons-poussoirs : une pression sur On allume la lampe et une pression sur Off lteint. Une pression sur On ne produit
pas deffet si la lampe est dj allume ; la raction dune instance de Lampe cet vnement
dpend de son tat interne.
EXEMPLE
La lampe
Cet exemple simple prsente la notion dtat et leffet des invocations en fonction de ltat
courant.
Figure 4.1
Un diagramme
dtats-transitions
simple.
allume
Off
On
On
teinte
Off
Les tats sont reprsents par des rectangles aux coins arrondis, tandis que les transitions
sont reprsentes par des arcs orients liant les tats entre eux. Certains tats, dits composites , peuvent contenir des sous-diagrammes. UML offre galement un certain nombre de
constructions la smantique particulire, telles que lhistorique, qui permet de retrouver
un tat prcdent, les points de choix, qui permettent dexprimer des alternatives, ou
encore un moyen dexprimer des mcanismes concurrents.
EXEMPLE
Fentre dapplication
Le diagramme de la figure 4.2 prsente le comportement simplifi dune fentre dapplication, qui rpond aux stimuli de trois boutons placs dans langle. Une fentre peut tre dans
trois tats : rduite, normale, agrandie. Lorsquelle est rduite, elle est reprsente par une
icne dans la barre des tches. ltat normal, elle peut tre dplace et redimensionne.
Lorsquelle est agrandie, elle occupe toute la surface disponible de lcran et ne peut tre
dplace ou redimensionne. Les arcs portent une tiquette indiquant le nom de lvnement
qui dclenche la transition associe. Ltat initial (Init 1 et Init 2 ici), not par un cercle plein,
dsigne le point dentre du diagramme ou du sous-diagramme. Une nouvelle instance de
fentre sera initialise ltat cre, dans le sous-tat ouverte et dans le sous-tat normale. Le
pseudo-tat historique, dsign par un H dans un cercle, permet de retrouver la fentre son
tat prcdent (normale ou agrandie) quand on quitte ltat rduite. Ltat final, dsign par
un point dans un cercle correspond la fin de vie de linstance et sa destruction.
128
UML 2
Chapitre
Figure 4.2
cre
Le comportement
dune fentre
dapplication.
ouverte
maximiser()
Init 1
normale
agrandie
Init 2
maximiser()
positionner()
dimensionner()
minimiser()
Final
H
minimiser()
rduite
1.2 VNEMENT
La vue propose par les diagrammes dtats-transitions met en vidence les ractions dune
partie du systme des vnements discrets. Un tat reprsente une priode dans la vie
dun objet dans laquelle ce dernier attend un vnement ou accomplit une activit. Quand
un vnement est reu, une transition peut tre dclenche qui va faire basculer lobjet
dans un nouvel tat.
Les transitions dun diagramme dtats-transitions sont donc dclenches par des vnements, appels dclencheurs ou triggers. La notion dvnement est assez large en UML :
Un appel de mthode sur lobjet courant gnre un vnement de type call.
Le passage de faux vrai de la valeur de vrit dune condition boolenne gnre implicitement un vnement de type change.
La rception dun signal asynchrone, explicitement mis par un autre objet, gnre un
vnement de type signal.
Lcoulement dune dure dtermine aprs un vnement donn gnre un vnement
de type after. Par dfaut, le temps commence scouler ds lentre dans ltat courant.
La fin dune activit de type do/, interne un tat gnre implicitement un vnement
appel completion event. Cela peut dclencher le tir des transitions dites automatiques , qui ne portent pas de dclencheur explicite.
Notation et spcification
Un vnement de type call ou signal est dclar ainsi :
nom-vnement ( liste-paramtres )
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 )
o le paramtre svalue comme une dure, a priori coule depuis lentre dans ltat courant. Par exemple : after(10 secondes) ou after(10 secondes aprs lentre dans ltat A).
Vous pouvez aussi spcifier un dclencheur li une date prcise par une clause when( ),
par exemple when(date=1 janvier 2000).
Les dclarations dvnement ont une porte de niveau paquetage et peuvent tre utilises
dans tout diagramme dtats-transitions des classes du paquetage. Leur porte nest en
aucun cas limite une classe.
Dclaration de signaux
la figure 4.3, trois signaux sont dclars comme des classes du paquetage et peuvent tre
lis entre eux par des relations dhritage. Si le signal A drive du signal B, il dclenche par
transitivit toutes les activits lies B en plus des siennes propres. Les attributs de classe sont
interprts comme les arguments de lvnement de type signal.
Figure 4.3
signal
Interruption E/S
Dclarations de
signaux et hritage.
+pripherique :int
signal
Souris
+posx:int
+posy:int
130
UML 2
signal
Clavier
+caractre: int
Chapitre
1.3 TRANSITION
SIMPLE
Une transition entre deux tats simples E1 et E2 est reprsente par un arc qui les lie lun
lautre. Elle indique quune instance dans ltat E1 peut entrer dans ltat E2 et excuter certaines activits, si un vnement dclencheur se produit et que les conditions de garde sont
vrifies. On parle de tir dune transition quand elle est dclenche.
Notation
Une transition dun diagramme dtats-transitions est reprsente par un arc plein, liant un
tat dit source un tat cible . Elle est dote dune tiquette contenant une expression de la forme :
nom-vnement ( liste-param-vnement ) [ garde ] / activit
o les paramtres ventuels de lvnement sont spars par des virgules, la garde (par
dfaut vraie) dsigne une condition qui doit tre remplie pour pouvoir dclencher la transition, et lactivit exprime dans une syntaxe laisse libre dsigne des instructions effectuer
au moment du tir.
Le dclencheur de la transition est un vnement de type call, signal, change ou after, ou
nest pas spcifi pour les transitions automatiques (voir la section vnement ). Lvnement peut porter des paramtres, visibles dans les activits associes la transition ainsi
que dans lactivit exit de ltat source et lactivit entry de ltat cible. Les vnements
entrants sont traits squentiellement. Si aucune transition nest dclenche par lvnement, il est dtruit. Si une transition est dclenche, sa garde est value ; celle-ci est exprime en fonction des variables dinstance et ventuellement de tests dtat des instances
dobjet accessibles (par exemple, obj1 in tat1 ou obj1 not in tat1) ; si elle est
fausse, lvnement est dtruit. Si plusieurs transitions sont simultanment franchissables,
lune dentre elles est choisie de faon arbitraire.
1.4 POINT
DE DCISION
Il est possible de reprsenter des alternatives pour le franchissement dune transition. On
utilise pour cela des pseudo-tats particuliers : les points de jonction (reprsents par un
petit cercle plein) et les points de choix (reprsents par un losange).
Les points de jonction sont un artefact graphique qui permet de partager des segments de
transition. Plusieurs transitions peuvent viser et/ou quitter un point de jonction. Tous les
chemins travers le point de jonction sont potentiellement valides. On peut donc reprsenter un comportement quivalent en crant une transition pour chaque paire de segments
avant et aprs le point de jonction. Lintrt est de permettre une notation plus compacte et
de rendre plus visibles les chemins alternatifs.
EXEMPLE
quivalences de reprsentation
Les deux reprsentations des figures 4.4 et 4.5 sont quivalentes.
Lutilisation des points de jonction rend les diagrammes plus lisibles.
Figure 4.4
Utilisation de points
de jonction.
[b>0]
tat1
tat3
e1[a>0]
[b=0]
e2[a>0]
tat2
tat4
tat5
[b<0]
Figure 4.5
Equivalence avec
des transitions
gardes.
e1[a>
0 and
e1[
a>0
and
tat3
b=0]
b>0
]
tat4
nd
0a
b<0
a>
e2[
0 and
e2[a>
b=0]
tat2
tat5
0]
Cette quivalence avec une reprsentation par plusieurs transitions implique que, pour que
lon puisse emprunter un chemin, toutes les gardes le long de ce chemin doivent svaluer
vrai ds le franchissement du premier segment. Les points de jonction ne constituent donc
quun sucre syntaxique, sans smantique particulire.
On dispose galement du point de choix dit dynamique , reprsent par un losange. Au
contraire dun point de jonction, les gardes aprs ce point de choix sont values au moment
o il est atteint. Cela permet en particulier de baser le choix sur des rsultats obtenus en
franchissant le segment avant le point de choix. Si, quand le point de choix est atteint, aucun
segment en aval nest franchissable, le modle est mal form. Au contraire, si plusieurs
segments sont franchissables, on suit la rgle habituelle : quand plusieurs transitions sont
simultanment franchissables, lune dentre elles est choisie alatoirement.
EXEMPLE
Figure 4.6
Utilisation dun
point de jonction.
saisie
formulaire
go/validerEntre()
[entre valide]
[else]
afficher
problmes
132
UML 2
demander
confirmation
Chapitre
Il est possible dutiliser une garde particulire sur un des segments aprs un point de choix
ou de jonction en introduisant une clause [else]. Ce segment nest franchissable que si les
gardes des autres segments sont toutes fausses. Lutilisation dune clause [else] est recommande aprs un point de choix car elle garantit un modle bien form.
Si lon utilise un point de jonction pour reprsenter le branchement dune clause conditionnelle, il est conseill dutiliser galement un point de jonction pour faire apparatre la fin du
branchement et tre homogne.
EXEMPLE
Figure 4.7
Deux points de
jonction pour
reprsenter des
alternatives.
[client trouv]
chercher client
(2)
/afficher
numero client
associer client
crer client
2.1 TAT
ET TRANSITION INTERNE
Un tat est une priode dans la vie dun objet o il vrifie une condition donne, excute
une certaine activit, ou plus gnralement attend un vnement. Conceptuellement, un
objet reste donc dans un tat durant une certaine dure, au contraire des transitions qui
sont vues comme des vnements ponctuels (sauf dans le cas particulier o la transition
dclenche elle-mme un traitement).
Un tat peut tre dcompos en deux compartiments spars par une barre horizontale. Le
premier compartiment contient le nom de ltat, le second contient les transitions internes
de ltat, ou activits associes cet tat. Vous pouvez omettre la barre de sparation en
labsence de transitions internes. Une transition interne ne modifie pas ltat courant, mais
suit globalement les rgles dune transition simple entre deux tats. Trois dclencheurs
particuliers sont introduits permettant le tir de transitions internes : entry/, do/, et exit/.
EXEMPLE
Figure 4.8
La saisie dun mot
de passe.
Notation
La syntaxe de la dfinition dune transition interne est la suivante :
Nom-vnement (liste-paramtres) [garde] / activit--raliser
Le nom de lvnement peut tre celui dune mthode de lobjet auquel appar tient ltat,
dun vnement dclar comme tel au niveau paquetage, ou un des mots-cls rser vs
suivants :
entry dfinit une activit effectuer chaque fois que lon rentre dans cet tat.
exit dfinit une activit effectuer quand on quitte cet tat.
do dfinit une activit continue qui est ralise tant que lon se trouve dans cet tat, ou
jusqu ce que le calcul associ soit termin. On pourra dans ce dernier cas grer lvnement correspondant la fin de cette activit (completion event).
include permet dinvoquer un sous-diagramme dtats-transitions.
La liste des paramtres (optionnelle) correspond aux arguments de lvnement dclencheur de lactivit. La condition dactivation, ou garde, est une condition boolenne qui
permet dautoriser ou non le dclenchement de lactivit. La faon de spcifier lactivit
raliser est laisse libre. En gnral, on utilise le langage naturel pour dcrire lactivit
entreprendre, ou du pseudo-code mentionnant les arguments de lvnement dclencheur.
On peut galement utiliser une rfrence vers un autre diagramme (activit ou collaboration) pour dcrire ce traitement.
Une transition interne se distingue dune transition reprsente par un arc qui boucle sur
ltat, car lors de lactivation dune transition interne, les activits entry et exit ne sont pas
appeles (on ne quitte pas ltat courant). Implicitement, tout diagramme dtats-transitions est contenu dans un tat externe qui nest usuellement pas reprsent. Cela apporte
une plus grande homognit dans la description : tout diagramme est implicitement un
sous-diagramme.
2.2 TAT
COMPOSITE
Un tat composite, par opposition un tat dit simple , est graphiquement dcompos
en deux ou plusieurs sous-tats. Tout tat ou sous-tat peut ainsi tre dcompos en soustats enchans sans limite a priori de profondeur. Un tat composite est reprsent par les
deux compartiments de nom et dactions internes habituelles, et par un compartiment
contenant le sous-diagramme.
EXEMPLE
Combin tlphonique
Cet exemple prsente les tapes de laction composer numro. lentre dans ltat composite (par exemple suite une action dcrocher), une tonalit sonore annonce que le tlphone
est prt pour la composition du numro. Les chiffres sont saisis un par un suite lappel de
lopration chiffrer. La transition automatique de numroter vers ltat final est franchie ds
que sa garde devient vraie.
134
UML 2
Chapitre
Figure 4.9
Composer numro
Composition
dun numro
et transitions
automatiques.
Dbut
entry/tonalit prt
exit/ cesser tonalit
Numroter
[numro.valide()]
entry/numero.append(n)
chiffrer(n)
chiffrer(n)
Un nouvel objet est cr dans ltat initial le plus externe du diagramme et franchit la transition par dfaut qui en part. Un objet qui atteint ltat final le plus externe est dtruit. Ces
transitions peuvent tre accompagnes dune tiquette qui indique un vnement correspondant au constructeur ou destructeur dinstance, et ventuellement associes une activit.
Une transition qui atteint ltat final dun sous-diagramme correspond la fin de laction
associe ltat lencapsulant. La fin dune activit interne dun tat peut tre associe au
dclenchement dun changement dtat, reprsent par une transition sans tiquette qui
quitte ltat externe courant. On parle alors de transition automatique, dclenche par un
vnement implicite de terminaison (completion event). Un completion event est galement
dclench par la fin dune activit interne de type do/.
Lutilisation dtats composites permet de dvelopper une spcification par raffinements. Il
est parfois souhaitable de ne pas reprsenter les sous-tats chaque utilisation de ltat
englobant. Vous pouvez noter graphiquement le fait quun tat est composite et que sa
dfinition est donne sur un autre diagramme.
EXEMPLE
Figure 4.10
Composer
numro
Reprsentation compacte
dun tat composite.
2.3 TRANSITION
ET TAT COMPOSITE
Les transitions peuvent avoir pour cible la frontire dun tat composite et sont alors quivalentes une transition ayant pour cible ltat initial de ltat composite. De mme, une
transition ayant pour source la frontire dun tat composite est quivalente une transition qui sapplique tout sous-tat de ltat composite source. Cette relation est transitive :
la transition est franchissable depuis tout tat imbriqu, quelle que soit sa profondeur. Si la
transition ayant pour source la frontire dun tat composite ne porte pas de dclencheur
explicite (en dautres termes, si elle est dclenche par un completion event), elle est franchissable quand ltat final de ltat composite est atteint.
Par exemple, la transition minimiser de la fentre dapplication est franchissable depuis les
tats normale et agrandie (voir figure 4.2).
Les transitions peuvent galement toucher des tats de diffrents niveaux dimbrication, en
traversant les frontires des tats.
Dans tous les cas, avant lentre dans un tat (respectivement la sortie), les activits entry/
(respectivement exit/) sont ralises. En cas de transition menant vers un tat imbriqu, les
activits entry/ de ltat englobant sont ralises avant celles de ltat imbriqu. En cas de
transition depuis la frontire de ltat englobant, les activits exit/ du sous-tat actif sont
ralises, puis celles de ltat englobant le sont leur tour.
EXEMPLE
Ordre dappel
Depuis ltat tat11, la rception de lvnement event1 provoque la squence dactivits
QuitterE11, QuitterE1, action1, EntrerE2, EntrerE21, initialiser, EntrerE22, et place le systme
dans ltat tat22.
Figure 4.11
tat2
tat 1
tat21
tat22
tat11
exit/QuitterE11
exit/QuitterE1
event1/action1
initialiser() entry/EntrerE22
entry/EntrerE21
entry/EntrerE2
2.4 HISTORIQUE
ET TAT COMPOSITE
Chaque rgion ou sous-diagramme dtats-transitions peut avoir un pseudo-tat historique, not par un cercle contenant un H. Une transition ayant pour cible le pseudo-tat historique est quivalente une transition qui a pour cible le dernier tat visit dans la rgion
contenant le H.
Dans lexemple de la fentre prsent prcdemment la figure 4.2, le pseudo-tat historique permet de retrouver ltat prcdent (normale ou agrandie) quand on sort de ltat
rduite.
Il est possible de dfinir un dernier tat visit par dfaut laide dune transition ayant pour
source le pseudo-tat H. Cet tat par dfaut sera utilis si la rgion na pas encore t visite.
Il est galement possible de dfinir un pseudo-tat historique profond, not par un cercle
contenant H*. Cet historique profond permet datteindre le dernier tat visit dans la
rgion, quel que soit son niveau dimbrication, alors que le pseudo-tat H limite laccs aux
tats de son niveau dimbrication dans la rgion. Toute rgion peut avoir la fois un historique profond et un historique de surface.
EXEMPLE
Historique
Lutilisation dun historique profond permet de retrouver, aprs une interruption, le sous-tat
prcdent. la figure 4.12, lutilisation dun historique de surface H, au lieu de H*, permettrait de retrouver ltat Traitement1 ou Traitement2 dans leur sous-tat initial, mais pas les
sous-tats imbriqus E11, E12, E21, E22, qui taient occups avant linterruption.
136
UML 2
Chapitre
Figure 4.12
Traitement
Historique et
historique profond.
reprendre
H*
Traitement 1
2.5 INTERFACE
Traite
Interruption
Traitement 2
E11
E21
E12
E22
interrompre
Pour cacher la complexit, il est possible de masquer, sur un diagramme, les sous-tats dun
tat composite et de les dfinir dans un autre diagramme. Pour exprimer la connexion des
diagrammes entre eux, vous pouvez utiliser des points de connexion. Les points dentre et
de sortie sont respectivement reprsents par un cercle vide et un cercle barr la frontire
de ltat.
Pour utiliser le comportement par dfaut dune machine tat, cest--dire entrer par
ltat initial par dfaut et considrer les traitements finis quand ltat final est atteint, il est
inutile de se servir de ces points de connexion. Recourez plus simplement des transitions
ayant pour cible la frontire de ltat englobant.
Employez plutt des points de connexion lorsquil est possible dentrer ou de sortir de la
machine tats de plusieurs faons, par exemple pour reprsenter des transitions traversant
la frontire de ltat englobant et visant directement un autre sous-tat que ltat initial
(comme ltat historique par exemple), ou ayant pour source un sous-tat et visant un tat
externe.
Un point de connexion nest quune rfrence un tat dfini ailleurs. Ltat quil dsigne est
signal par lunique transition quittant le pseudo-tat. Cette transition peut ventuellement
porter une tiquette indiquant une action (qui sera excute avant lactivit entry de ltat
cible), mais pas de garde ni de dclencheur explicite : cest le prolongement de la transition
qui vise le point de connexion.
Plusieurs transitions peuvent cibler un mme point de connexion. Cela peut rendre les diagrammes plus lisibles.
EXEMPLE
Points de connexion
Cet exemple montre lutilisation des points de connexion. Ltat distribuer boisson a deux
entres et trois sorties. Lentre par dfaut vrifie dabord que le crdit de lutilisateur est suffisant pour la boisson slectionne, et peut provoquer une sortie sur erreur par le point de
connexion crdit insuffisant. Un deuxime point dentre est fourni pour loprateur de maintenance qui peut dclencher la prparation dune boisson sans insrer dargent. La prparation de la boisson peut elle-mme tre soumise des erreurs. Dans le cas nominal, la boisson
est prpare et la sortie de ltat distribuer boisson se fait par ltat final.
Figure 4.13
distribuer boisson
Points de connexion
pour la composition
de diagrammes.
Crdit insuffisant
vrifier crdit
Erreur matrielle
Les points de connexion sont plus quune facilit de notation : ils permettent de dcoupler
la modlisation du comportement interne dun tat et la modlisation dun comportement
plus global. Ils offrent une faon de reprsenter linterface (au sens objet) dune machine
tats, en masquant limplmentation du comportement. Cela permet un dveloppement
par raffinements (ou en bottom-up), en deux tapes indpendantes du processus de conception, ce qui est essentiel pour traiter des modles de grande taille.
(3)
Contrat de comportement
UML 2 introduit la notion de contrat de comportement (ou protocole dutilisation dun
classeur), reprsent laide dun diagramme de protocole (une version simplifie des
diagrammes dtats-transitions reconnaissable au mot-cl {protocol}).
Un contrat de comportement dfinit les squences dactions lgales sur un classeur, ainsi
quun certain nombre de pr- et post-conditions qui doivent tre valides. Il est relativement abstrait et nexprime pas la nature des traitements raliss, mais indique simplement
leur enchanement logique. Ainsi, les tats dun diagramme de protocole nont pas de
clauses dclenchant des activits (entry/, exit/, do/), et les transitions nont pas dactivits
dclencher.
Notation
La syntaxe de ltiquette dune transition liant un tat source E1 un tat destination E2 sur
un diagramme de protocole est la suivante :
[pr-condition] Dclencheur / [post-condition]
Une telle transition a le sens suivant : si le classeur est dans ltat protocolaire E1 et si la
pr-condition est vraie, la rception de lvnement dclencheur doit provoquer le passage
dans ltat E2, et lissue du franchissement, la post-condition doit tre vraie.
138
UML 2
Chapitre
Les protocoles servent expliquer la faon correcte de se servir dune classe ou dun composant, sans spcifier les traitements qui ralisent laction. Plusieurs implmentations diffrentes dune classe peuvent respecter un protocole donn.
EXEMPLE
Figure 4.14
Diagramme de
protocole dune
classe fichier.
stm {protocol}
fichier
write/
close/
dconnect
connect
seek/
open/
delete/
read/
(4)
Gestion de la concurrence
Les diagrammes dtats-transitions permettent de dcrire efficacement les mcanismes
concurrents. Un tat composite dot de sous-tats peut avoir un comportement concurrent,
travers lutilisation de rgions concurrentes. Celles-ci permettent de reprsenter des zones
o laction est ralise par des flots dexcution parallles.
Chaque rgion dun tat peut avoir un tat initial et final. Une transition qui atteint la
bordure dun tat composite est quivalente une transition qui atteint ltat initial du
sous-diagramme ou les tats initiaux de toutes ses rgions concurrentes si elles existent. Les
transitions ayant pour origine un tat initial interne ne sont pas tiquetes et correspondent
toute transition atteignant la frontire de ltat externe.
Quand un tat prsente des rgions concurrentes, elles doivent toutes atteindre leur tat
final pour que laction soit considre comme termine (gnration dun completion event).
EXEMPLE
tat concurrent
Cet exemple montre un tat concurrent, au sein dun distributeur de type machine caf.
Quand la boisson a t slectionne et le montant valid par rappor t au crdit, deux squences dactions sont dclenches en parallle : la prparation de la boisson et le rendu de la
monnaie.
Figure 4.15
boisson slectionne
Rgions concurrentes
au sein dun tat.
prparer boisson
terminer prparation
entry/placer gobelet
do/servir liquide
do/ajouter sucre
exit/signal sonore
rendre monnaie
entry/monnaie= credit - boisson.prix()
do/monnayeur.rendre(monnaie)
Transition concurrente
Ltat concurrent du distributeur de boisson peut tre spcifi de faon quivalente laide de
deux transitions concurrentes. La transition nomme ici fork correspond la cration de deux
tches concurrentes cres dans les tats prparer boisson et rendre monnaie. La transition
nomme join correspond une barrire de synchronisation par rendez-vous. Pour pouvoir
continuer leur excution, toutes les tches concurrentes doivent pralablement tre prtes
franchir la transition de rendez-vous.
Figure 4.16
Transition complexe
pour lexpression
de la concurrence.
prparer boisson
terminer prparation
fork
join
entry/placer gobelet
do/servir liquide
do/ajouter sucre
exit/signal sonore
gobelet bloqu
nominal
do/a fficher retirer boisson
rendre monnaie
entry/monnaie= credit - boisson.prix()
do/monnayeur.rendre(monnaie)
gobelet retir/
Une transition ayant pour destination un tat cible muni de rgions concurrentes est quivalente une transition complexe de type fork ayant pour cibles les tats initiaux de chaque
rgion concurrente. Une transition ayant pour origine un tat source muni de rgions
concurrentes est quivalente une transition complexe de type join ayant pour sources les
tats finaux de chaque rgion concurrente.
140
UML 2
Chapitre
Conclusion
Les diagrammes dtats-transitions permettent de reprsenter le comportement interne
dun objet, a fortiori actif, sous une forme qui met en avant le modle vnementiel ou ractif des traitements. Ils sont bien adapts au gnie logiciel orient objet, en raison des mcanismes quils proposent (vnement de type call, signal, after), qui permettent de faire le lien
avec les autres diagrammes de la norme. La grande flexibilit apporte par la possibilit de
dfinir des transitions internes (entry, do, exit) et par les mcanismes de hirarchisation des
diagrammes permet de reprsenter de faon concise et formelle lensemble des comportements dune instance modlise.
De ce point de vue, les diagrammes dtats-transitions sont les seuls de la norme offrir une
vision complte et non ambigu de lensemble des comportements (les diagrammes dinteractions noffrant que la vue dun scnario, sans vraiment prciser comment les diffrents
scnarios bauchs peuvent interagir entre eux). Dun autre ct, en raison de leur grand
niveau de dtails et de leur lourdeur relative, ils sont surtout adapts la phase de ralisation. En outre, ils conviennent peu la modlisation de systmes composs de plusieurs
sous-systmes car ils noffrent pas de vision globale.
Les diagrammes de protocole donnent une vision de haut niveau du comportement dun
composant en spcifiant ses responsabilits, sans entrer dans les dtails de son implmentation. Ils sont relativement proches de la notion dinterface dun composant, tout en ajoutant
une information supplmentaire par rapport la seule description des signatures des oprations quil porte, savoir des contraintes sur lordre dappel des oprations dclares.
Outre leur intrt lors de la modlisation, certains outils sont capables de gnrer automatiquement un programme partir dune description sous forme de diagrammes tatstransitions. Ainsi, chaque objet dun systme passe sous le contrle dun automate. Ce
dernier connat ltat de lobjet tout instant, et en agissant comme un filtre, nautorise les
changements dtats que sil reoit une demande de transition valide. Le code produit est
alors trs robuste car lobjet ne peut pas tre corrompu. De plus, le mode de contrle du
logiciel devient alors vnementiel.
Avec les diagrammes prsents dans la partie prcdente du livre (diagramme des cas dutilisation, diagramme de classes et dobjets, diagramme de squence et de communication,
diagramme dtats-transitions), un systme peut tre presque entirement modlis. La
modlisation nest cependant pas assez avance pour implanter le systme. Les dveloppeurs
par exemple ont besoin de dcrire les algorithmes utiliss pour dfinir les mthodes des
classes, sans pour autant avoir recours un langage de programmation. Par ailleurs, certains
modles sont trop approximatifs. Considrez par exemple un systme dont le comportement est complexe. Dans ce cas, les diagrammes de squence peuvent ne pas suffire
dtailler les cas dutilisation. Une partie de ces lacunes peuvent tre combles grce aux
diagrammes dactivits qui sont tudis au chapitre suivant.
Problmes
et exercices
Les exercices suivants utilisent les principaux concepts des diagrammes
dtats-transitions.
EXERCICE 1
Reprsentez par un diagramme dtats-transitions les tats que peut prendre un individu
du point de vue de lINSEE : vivant, dcd, mineur, majeur, clibataire, mari, veuf et
divorc.
Supposez que seul un individu majeur peut se marier. Utilisez des tats composites pour
cumuler les tats : un individu peut tre simultanment vivant, majeur, et divorc par
exemple.
Figure 4.17
Un individu du point
de vue de lINSEE.
vivant
majeur
mineur
marier
marier
clibataire
mari
veuf
dcs conjoint
divorcer
marier
majoritAnticipe
divorc
dcder
dcd
La machine tats englobante est implicite ici. Lutilisation dun vnement de type after
permet de dclencher le passage ltat majeur. Seules les transitions lgales sont reprsentes : une personne ne peut se marier si elle est dj marie.
La transition dcder est franchissable quel que soit le sous-tat de vivant dans lequel se
trouve un individu.
142
UML 2
Chapitre
EXERCICE 2
PORTE
Une porte munie dune serrure offre les oprations ouvrir, fermer, verrouiller, dverrouiller
et franchir. La serrure peut tre ferme simple ou double tour.
1. Commencez par modliser les tats et transitions de la serrure. Mettez en avant les tats
o la serrure est verrouille par rapport aux tats o elle ne lest pas.
2. Exprimez travers un diagramme de protocole la faon normale de se servir dune
porte verrou.
3. Modlisez les tats et transitions dune porte sans serrure. Ajoutez ensuite des annotations exprimant des contraintes pour lier ce diagramme lutilisation de la serrure.
1.La serrure rpond aux vnements verrouiller et dverrouiller. Vous pouvez dans un premier temps vous contenter de modliser les trois tats dverrouille, simple tour et double
tour. Utilisez un tat composite pour distinguer les tats o la serrure est verrouille. Sur
le schma de la figure 4.18, nous avons employ la notation frame (cadre), avec lindication stm (State Machine), pour spcifier le type et le nom du diagramme.
Figure 4.18
Les tats dune
serrure de porte.
stm
Serrure
verrouille
verrouiller
verrouiller
dverrouille
simple tour
double tour
dverrouiller
dverrouiller
Le protocole
dutilisation
dune porte.
{protocol}
porte avec verrou
fermer()
ouverte
franchir()
verrouiller()
ferme
ouvrir()
verrouiller()
ferme
simple tour
dverrouiller()
ferme
double tour
dverrouiller()
Cependant pour amliorer la cohrence avec le diagramme prsent la figure 4.18, vous
pouvez utiliser un tat composite, dans lequel les tats prcdemment identifis de la
serrure sont prsents.
Exercices
Figure 4.19
Figure 4.20
{protocol}
porte avec verrou
ferme
fermer()
ouverte
franchir()
verrouiller()
dverrouille
ouvrir()
verrouiller()
simple tour
dverrouiller()
double tour
dverrouiller()
Ces deux modlisations sont trs similaires, mais la deuxime dcouple mieux les tats de
la serrure et ceux de la porte elle-mme.
3. La porte na que de deux tats (ouverte ou ferme) et ragit aux vnements ouvrir, fermer
et franchir. Vous pouvez dabord modliser les tats ouverte et ferme et les transitions
associes. Ajoutez ensuite les gardes qui contraignent les transitions par rapport aux tats
de la serrure. La rfrence ltat de lobjet serrure suppose une variable de contexte
accessible depuis lobjet englobant ce diagramme, cest--dire la porte.
Figure 4.21
Les tats dune porte.
stm
porte
[serrure dverrouille] fermer()/
ouverte
ferme
[serrure dverrouille] ouvrir()/
franchir()
Cette modlisation exploite la dfinition composite des tats de la serrure : il ne sagit pas
de savoir si la serrure est ferme simple ou double tour, mais simplement si elle est
verrouille ou non.
Remarque
Cette modlisation dcouple mieux les objets porte et serrure quune modlisation qui
mlangerait leurs machines tats. Vous seriez alors oblig de faire figurer des tats
comme ouverte et verrouille simple tour, ouverte et verrouille double tour, ferme et
verrouille, ce qui augmenterait la complexit du diagramme inutilement et forcerait
copier-coller des parties de diagramme.
Lutilisation de gardes est mieux adapte ici que lutilisation dune barre de synchronisation
qui forcerait mlanger les diagrammes de la serrure et de la por te. Avec le modle
obtenu, vous pourrez aisment rutiliser des parties pour modliser une porte avec un digicode par exemple.
Enfin, notez que la porte telle quelle est dfinie par le diagramme de la figure 4.21 admet
des scnarios absents du diagramme de protocole : il est galement possible de la verrouiller quand elle est ouverte (ce qui empche de la fermer correctement). Le diagramme
de protocole donne donc des informations non redondantes par rapport aux diagrammes
dtats-transitions : il dcrit la bonne faon de se servir dune porte.
144
UML 2
Chapitre
EXERCICE 3
MONTRE CHRONOMTRE
Cet exercice runit trois exercices relativement indpendants, correspondant aux diffrentes
fonctionnalits proposes. Larchitecture logicielle propose sappuie sur le design pattern
Observer.
Remarque
Le design pattern (ou patron de solution) Observer [Gamma 95] offre une solution propre
aux problmes de mise jour des donnes de classes lies entre elles. Un des problmes
du partitionnement dune application en classes est le maintien de la cohrence des par ties
de lapplication. Pour favoriser la rutilisabilit, il nest pas souhaitable de coupler for tement les classes stockant les donnes (classes de type sujet) et celles qui les affichent ou plus
gnralement les utilisent (classes de type observateur). Pourtant, il faut assurer quune mise
jour des donnes des classes de type sujet sera correctement rpercute sur les classes de
type observateur.
Le design pattern Observer dcrit une solution ce problme. Un sujet peut avoir un nombre
indtermin dobservateurs et tous les observateurs sont notifis du changement quand le
sujet subit une mise jour. En rponse, les observateurs interrogent le sujet pour connatre
son nouvel tat et mettre ainsi jour leur propre tat.
Une architecture de ce type est parfois qualifie de publish/subscribe (publication/abonnement) : le sujet publie des notifications, les observateurs sy abonnent sils le souhaitent. Le
point important est que le sujet ignore quels sont ses observateurs, ce qui donne un modle
bien dcoupl.
Figure 4.22
Sujet
Observateur
observateurs
+attacher(Observateur)
+dtacher(Observateur)
+notify()
SujetConcret
update()
pour chaque o de observateurs {
o.update();
}
sujet
tatSujet
setEtat()
getEtat()
ObservateurConcret
tatObservateur
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
secondes.
Le bouton mode active successivement trois modes principaux de la montre : laffichage de lheure courante, le mode chronomtre et le mode rglage (pour mettre
jour lheure courante).
Exercices
Design pattern
Observer.
Figure 4.23
Sujet
Diagramme de
classes simplifi
dune montre.
Timer
Observateur
sujet
start()
stop()
chrono
afficher(t: Timer)
time
afficheur
Montre
146
UML 2
Afficheur
sujet.dtacher(self);
t.attacher(self);
sujet = t;
Chapitre
2. Lalternance entre les trois modes principaux se reprsente facilement laide de trois
tats. Le comportement li lclairage est indpendant du mode principal slectionn.
Utilisez donc des rgions concurrentes pour exprimer cette indpendance.
Figure 4.24
mode/
mode/
mode chrono
affichage heure
mode rglage
entry/
afficheur.afficher(time)
mode/
light/
lumire teinte
lumire allume
light/
after(2 sec)
Le mode affichage de lheure est relativement simple : quand on entre dans cet tat, on lie
lafficheur lheure courante ; les boutons set et start-stop sont alors sans effet.
Les modes chronomtre et rglage sont plus complexes et par l mme dtaills sparment. Notez graphiquement que ce sont des tats composites, sans plus de prcision. On
introduit le point dentre de ltat mode chrono par souci de cohrence avec la solution
propose la question 3. ce stade de la modlisation, vous pourriez vous contenter de
toucher la frontire de ltat.
La gestion de la lumire donne lieu deux tats, isols dans une rgion concurrente.
after(2sec) se mesure par dfaut ds lentre dans ltat lumire allume. Une nouvelle
pression sur le bouton light quand la lumire est dj active a donc pour effet de remettre
ce compteur zro, puisque la transition associe fait quitter et entrer de nouveau dans
ltat lumire allume.
3. Le mode chronomtre sappuie sur linstance de Timer chrono. Chaque fois que lon entre
en mode chronomtre, lafficheur est li linstance de Timer chrono.
Le chronomtre est initialis zro la premire fois que lon entre dans cet tat. Ce fonctionnement est modlis par la transition partant de ltat historique, qui est la transition
par dfaut (portant laction chrono.set(0)) utilise uniquement la premire fois que lon
pntre dans cette rgion. Celle-ci a ensuite deux sous-tats, selon que le chronomtre est
lanc ou arrt. Si on la quitte et quon la retrouve ensuite, le dernier tat visit est atteint,
ce qui reprsente bien le mcanisme de reprise dcrit dans lnonc.
Lvnement not s-s correspond la pression sur le bouton start-stop. Le point dentre
de cet tat composite mne directement ltat historique. Labsence de pseudo-tat
initial est compense par la prsence dun tat historique qui permet dentrer dans
la rgion. Un pseudo-tat final est galement inutile puisque les transitions quittant cette
rgion touchent la frontire de ltat et sont donc franchissables depuis les deux tats
stopp et lanc.
Exercices
Les principaux
modes daffichage
et la lumire.
Figure 4.25
mode chrono
Le mode
chronomtre.
s-s/chrono.stop()
H
stopp
lanc
/chrono.set(0)
s-s/chrono.start()
set/chrono.set(0)
entry/afficheur.afficher(chrono)
4. Le mode rglage a trois sous-tats reprsentant le rglage de lheure, des minutes et des
secondes. lentre dans cette rgion, lafficheur est li au Timer time reprsentant
lheure courante.
Les actions do/ sont continues et durent tant que lon reste dans ltat, mais sont interrompues par une transition qui le quitte. Les mthodes increment et reset incrmentent
ou remettent zro le champ mentionn.
Figure 4.26
mode rglage
Le mode rglage.
set/time.increment(minute)
s-s/
set/time.increment(heure)
rglage minute
do/afficheur.clignoter(minute)
rglage heure
s-s/
set/time.reset(seconde)
rglage seconde
do/afficheur.clignoter(heure)
do/afficheur.clignoter(seconde)
s-s/
entry/afficheur.affiche(time)
EXERCICE 4
MODLISATION
DE LA SOCKET
TCP
148
UML 2
Chapitre
Les sockets sont des points extrmes de communication bidirectionnels : cest une interface
standardise, implmente sur quasiment toutes les plates-formes de faon homogne,
pour permettre la portabilit dapplications interagissant travers un rseau.
Le modle offert pour lutilisation de sockets TCP est de type client-serveur :
Le serveur offre un service aux clients, sur un numro de port bien connu (80 pour
HTTP par exemple). Il ouvre pour cela une socket quil place dans ltat LISTEN
(coute) et attend les requtes de client.
Figure 4.27
sd tablissement de connexion TCP
client:Socket
server:Socket
CLOSED
CLOSED
accept()
SYN J
connect()
SYN_SENT
LISTEN
ESTABLISHED
ESTABLISHED
Une fois la connexion tablie, le protocole devient symtrique : les deux participants peuvent lire et envoyer des messages. Vous ne modliserez pas cette partie du protocole relativement complexe, qui assure la transmission sans pertes, duplications ou dsquencement
des messages, et la gestion transparente des congestions du rseau.
La fin de connexion est initie par lun des participants, quand son application appelle la
mthode close(). Pour que la connexion se termine proprement, un certain nombre de
trames sont encore changes, comme le montre le schma prsent la figure 4.28.
Exercices
Ouverture de
connexion TCP.
Figure 4.28
Fermeture de
connexion TCP.
client:Socket
close()
On note client et
serveur, mais cette
partie du protocole
est totalement
symtrique
ESTABLISHED
FIN_WAIT_1
server:Socket
ESTABLISHED
FIN M
ACK M+1
CLOSE_WAIT
FIN_WAIT_2
close()
FIN N
TIME_WAIT
LAST_ACK
ACK N+1
CLOSED
On dit de lextrmit note client sur ce schma quelle fait une fermeture active, car elle
initie la fin de connexion. Au contraire, lextrmit serveur subit une fermeture passive,
linitiative de lautre participant. ltat CLOSE_WAIT, les lectures de lapplication sur la
socket vont rendre le caractre de fin de fichier EOF, et lon attend de lapplication quelle
appelle la mthode close() pour une fermeture propre de la connexion.
Lensemble du protocole prvoit des problmes matriels tels quune interruption du
rseau ou un crash dun des participants : chaque envoi dune trame, on initialise une
horloge, qui dclenche la rmission de la trame si elle nest pas acquitte temps (on suppose que la trame sest perdue sur le rseau) ou la fin de la connexion si la trame a dj t
mise trois fois (on suppose un crash rseau ou de lautre participant).
1. En vous basant sur les diagrammes de squence fournis, laborez un diagramme
dtats-transitions reprsentant les tats dune socket TCP. Vous distinguerez les tats
correspondant ltat initial (CLOSED), lattente dune connexion ct serveur,
lattente dtablissement de la connexion ct client, la connexion tablie (ESTABLISHED), et la fermeture active et passive de la connexion. Certains de ces tats
peuvent tre affins en sous-tats.
150
UML 2
Chapitre
Figure 4.29
sd Fermeture de connexion simultane TCP
client:Socket
server:Socket
ESTABLISHED
ESTABLISHED
close()
FIN J
close()
FIN K
FIN_WAIT_1
FIN_WAIT_1
ACK K+1
ACK J+1
CLOSING
CLOSING
TIME_WAIT
TIME_WAIT
La fin du timeout de 2 MSL
(Maximum Segment Lifetime)
ramne ltat CLOSED
1. Cet exercice modlisant un systme rel est plus complet que les prcdents. La solution
propose ici est une version simplifie du protocole, inspire du chapitre 18 de louvrage
TCP/IP illustr, volume 1 de Stevens (1993, Addison Wesley).
Il faut dcomposer le problme en tapes. Dans ce but, laborez dans un premier temps
un diagramme o napparaissent que les messages provenant de lapplication et les tats
proposs par lnonc (voir figure 4.30).
Exercices
Fermeture
simultane de
connexion TCP.
Figure 4.30
CLOSED
accept()
connect()
Attente dun
client
Connexion au
serveur
ESTABLISHED
Fin par correspondant
close()
Fermeture passive
Fermeture active
152
UML 2
Chapitre
Figure 4.31
Ct serveur,
attente dun client.
LISTEN
SYN_RCVD
SYN / SYN,ACK
Figure 4.32
ACK/
connexion au serveur
Ct client, tapes
de la connexion.
/ SYN
SYN,ACK / ACK
SYN_SENT
Figure 4.33
ESTABLISHED
Symtrique,
phase connecte
dchanges
de donnes.
Transfert de donnes
FIN/ACK
Figure 4.34
fermeture active
/FIN
FIN_WAIT_1
ACK/
Figure 4.35
Fermeture passive,
suite une
demande de lautre
participant.
FIN_WAIT_2
after (2MSL)
FIN/ACK
TIME_WAIT
fermeture passive
close()/FIN
CLOSE_WAIT
ACK/
LAST_ACK
Exercices
Fermeture active,
linitiative de
lapplication.
Figure 4.36
Introduction
de la fermeture
simultane ou
double fermeture
active.
fermeture active
/FIN
FIN/ACK
FIN_WAIT_1
CLOSING
ACK/
ACK/
after (2MSL)
FIN_WAIT_2
FIN/ACK
TIME_WAIT
154
UML 2
Chapitre
Diagramme
dactivits
1.
2.
3.
4.
Action ...................................
Activit .................................
Flot de contrle ......................
Mcanismes avancs .............
156
160
161
171
Problmes et exercices
1. Programmation en activits...... 177
2. Vente en ligne ........................ 178
3. Algorithmique ........................ 179
4. Vidoclub .............................. 182
5. Cache doprations................. 183
155
(1)
Action
Les modles servent dabord expliquer le fonctionnement dun systme, en fournissant
une vision abstraite de ses comportements. Cependant, UML 2 a vocation aller au-del
dune simple description informelle, en fournissant la possibilit de dcrire un systme un
niveau de dtails qui permette son excution. Cela sinscrit dans le cadre du MDA (Model
Driven Architecture), mis au point par lOMG, qui propose de centrer le dveloppement des
systmes au niveau de leur modle.
terme, lobjectif est de fournir un langage de spcification qui permette de se dtacher des
langages de programmation classiques : les dveloppeurs de demain pourront utiliser UML
pour dvelopper leur systme sans jamais descendre jusquau niveau de langages de programmation tels que Java, C++.
Pour cela, UML doit tre dot de mcanismes offrant la prcision dun langage de programmation au niveau de la description de leffet des actions. Comme UML se veut universel,
aucune syntaxe concrte nest propose dans la norme pour dcrire les actions : cest la
charge des outils den dfinir une ou dutiliser la syntaxe dun langage de programmation
existant. Cependant, UML propose une dfinition des instructions de base qui constituent
le langage orient objet : cest la description des actions UML.
Sans aller dans les dtails de la dfinition, nous prsentons ici les grandes catgories
dactions que propose la norme, et donnons des exemples concrets dinstructions offrant en
C++ ou Java la mme smantique.
1.1 GESTION
Ces actions de communication grent le passage et le retour de paramtres et les mcanismes dappels doprations synchrones et asynchrones.
Appel synchrone
Les actions de type call correspondent des appels de procdure ou de mthode.
Dans les deux cas, il est possible de spcifier des arguments et dobtenir des valeurs en retour.
Ce type dappel est bloquant : lappelant attend la rponse de lappel avant de continuer
son excution.
Call operation correspond lappel dune opration sur un classeur. Call behavior correspond
linvocation dun comportement spcifi laide dun diagramme UML, par exemple un
diagramme dactivits ou dinteractions. Cela offre la possibilit, dans les diagrammes
dactivits, de directement rfrer dautres types de diagrammes. Vous pouvez donc utiliser un diagramme de squence par exemple (imbriqu dans un diagramme dactivits) pour
illustrer le comportement dune activit, et rciproquement.
Les actions accept call et reply peuvent tre utilises du ct rcepteur pour dcomposer
la rception de lappel. Reply correspond prcisment au return des langages de programmation.
EXEMPLE
156
UML 2
Linvocation dune mthode, ou dune procdure plus complexe (un autre programme par
exemple), correspond une instance de call.
Pour dcrire un traitement rcursif, il faut utiliser une action call behavior pour r-invoquer le
comportement en cours de description.
Chapitre
Appel asynchrone
Les appels asynchrones de type send correspondent des envois de messages asynchrones :
lappelant poursuit son excution sans attendre que lentit cible ait bien reu le message.
Ce type dappel est bien adapt la modlisation de systmes matriels (communications
sur un bus, interruptions dentre/sortie avec send signal) ou de protocoles de communication particuliers (UDP dans le domaine Internet, ou MPI dans le contexte multiprocesseur
avec send object).
Le broadcast signal permet dmettre vers plusieurs destinataires la fois, une possibilit
rarement offerte par les langages de programmation.
Laction symtrique ct rcepteur est accept event, qui permet la rception dun signal.
EXEMPLE
La smantique dun appel dans les langages objet (C++, Java) est toujours synchrone (cest-dire de type appel de procdure). Cependant, certains mcanismes de communication
peuvent tre vus comme des appels asynchrones.
En Java par exemple, la mthode notify() de la classe Object permet de signaler un autre
thread Java loccurrence dun vnement. Cet appel nest pas bloquant : lexcution se poursuit sans attendre la bonne rception de lappel. Lautre thread nen est inform quaprs un
dlai, quand la machine virtuelle llit pour sexcuter.
vnements particuliers
Laction raise exception permet de lever une exception au cours dun traitement.
Une exception est un lment important de lapproche oriente objet ; elle permet de traiter
des cas particuliers. Le comportement complet associ la gestion des exceptions est dcrit
la section 4.2 de ce chapitre.
EXEMPLE
Le mot-cl standard throw (en Java et en C++) correspond prcisment la smantique dune
action raise exception.
Un time event est un vnement temporel dclench aprs lcoulement dune certaine
dure (spcifie librement). On distingue graphiquement les actions associes une communication : send signal, accept event et accept time event. Cela permet de mieux mettre en
valeur les changes entre les diagrammes de la spcification.
Figure 5.1
Les actions de
communication.
clairer Affichage
action send signal
attendre 2 secondes
teindre Affichage
action send signal
1.2 MANIPULATION
DES VARIABLES
Les variables en UML sont toujours considres comme des instances dune classe : les
actions proposes sur les variables correspondent donc des accs sur un objet. On retrouve
ici toutes les oprations usuelles des langages de programmation.
158
UML 2
Chapitre
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.
Smalltalk et Python sont deux exemples de langages objet qui permettent ce niveau de rflectivit en cours dexcution.
En Java, ce type dopration nest pris en charge quau niveau bytecode, pas directement au
niveau des fonctionnalits standard du langage. Certaines bibliothques spcialises offrent
cependant une interface de haut niveau pour raliser ces oprations. Elles sont utilises dans
des approches rflexives, comme le tissage daspect (Aspect Oriented Programming).
Le modle de compilation statique de C++ ne permet pas ce type dopration, aprs la dclaration dune classe.
1.3 ACTION
OPAQUE
Une action opaque na pas de smantique ou de contrainte particulire, et na donc pas un
sens dfini par UML. Cest donc aux outils de savoir interprter ce type daction, qui
dpasse le cadre dUML, limit aux actions prcites dans cette section.
Les actions opaques permettent lintgration de librairies ou routines de traitements existants. Elles peuvent galement correspondre des traitements qui nont simplement pas t
modliss.
Parmi les actions opaques figurent galement les oprations sur les types machine de base :
arithmtique entire et flottante, masques et vecteur de bits, etc. Bien que communes la
majorit des langages de programmation, elles ne sont pas standardises en UML.
1.4 UML 2
ET LES ACTIONS
UML dfinit des actions qui couvrent les instructions lmentaires dun langage de programmation, mais ne propose pas de mcanismes pour exprimer des boucles, des conditionnelles, des blocs dactions conscutives. Il sagit l dune volution importante dUML 2
par rapport aux versions prcdentes dUML 1.x, qui intgraient ces mcanismes dans les
actions.
En UML 2, la description de la structuration des actions est laisse aux activits. Ainsi, le
modle est plus clair et mieux dcoupl. Les activits englobent les actions et offrent des
mcanismes pour exprimer clairement le cheminement du flot de contrle.
On peut cependant regretter labsence doprations explicitement dfinies sur les types de
base habituels (oprations arithmtiques, par exemple). On peut esprer quun profil UML
standardis verra bientt le jour pour prendre en charge ces types.
(2)
Activit
2.1 MODLISATION
DES TRAITEMENTS
Les actions lmentaires sont dcrites sparment en UML. Les traitements complets sont
dcrits par des activits, qui offrent une manire concise et sans ambigut de prsenter
graphiquement un traitement squentiel, avec tout larsenal propos par un langage de programmation orient objet (actions de base, boucles et conditionnelles, appels de mthode,
gestion des exceptions).
Les activits donnent donc une description complte des traitements associs des comportements au sens interaction dUML. On les utilise couramment pour tiqueter les autres
diagrammes (traitements associs aux messages des diagrammes de squence, transitions
des diagrammes dtats-transitions) ou pour dcrire limplmentation dune opration
dun classeur.
Les diagrammes dactivits sont relativement proches des diagrammes dtats-transitions
dans leur prsentation, mais leur interprtation est sensiblement diffrente. En particulier,
ils offrent un support pour lexpression de mcanismes concurrents, mais ce nest pas l leur
fonction premire.
160
UML 2
Chapitre
2.2 UNE
2.3 PROGRAMMATION
STRUCTURE
Un flot de contrle est associ chaque processus ou thread dune application : il reprsente
le curseur dexcution (program counter) qui excute les instructions dun programme.
un instant donn, il excute une certaine instruction ; le choix de linstruction suivante
excuter est dtermin par les structures de contrle du langage (if/else, for, while, switch/
case). Les activits capturent de faon graphique ce comportement a priori squentiel de
lexcution.
En mettant laccent sur le traitement, la vision des diagrammes dactivits se rapproche des
langages de programmation procduraux type C ou Pascal. Une activit se comporte par
bien des points de vue comme une procdure, possdant des arguments en entre et des
valeurs de sortie et pouvant causer des effets de bord sur les variables accessibles depuis leur
contexte. Il est possible, dans un premier temps, de raisonner purement sur les traitements
et, lors dune phase de conception dtaille, daffecter les diffrentes activits recenses des
classeurs du systme.
(3)
Flot de contrle
3.1 ACTIVIT
ET TRANSITION
La vision des diagrammes dactivits est centre sur les flots de contrle. On y trouve deux
lments fondamentaux :
Les activits, reprsentes par un rectangle aux coins arrondis, dcrivent un traitement.
Le flot de contrle reste dans lactivit jusqu ce que les traitements soient termins. On
peut dfinir des variables locales une activit et manipuler les variables accessibles
depuis le contexte de lactivit (classe contenante en particulier). Les activits peuvent
tre imbriques hirarchiquement : on parle alors dactivits composites.
Les transitions, reprsentes par des flches pleines qui connectent les activits entre
elles, sont dclenches ds que lactivit source est termine et dterminent la prochaine
activit dclencher. Contrairement aux activits, les transitions sont franchies de
manire atomique, en principe sans dure perceptible.
EXEMPLE
La commande
Cet exemple fait apparatre un certain nombre de possibilits des diagrammes dactivits. On
y trouve la description dun traitement Passer Commande. Les trois cadres, appels lignes
deau , permettent de situer les actions par rapport aux entits du systme : on identifie trois
intervenants dans ce traitement, savoir le client, le ser vice comptable et le service livraison.
Les cercles noirs pleins dsignent un tat initial, utilis pour dbuter le traitement. Les cercles
contenant un point noir dsignent des tats finaux, o le traitement est considr comme
termin.
Laction se droule comme suit : le client commence par passer une commande, ce qui donne
lieu llaboration dun devis par le service comptable. Llaboration du devis est elle-mme
dcompose en deux sous-activits : vrifier la disponibilit des produits commands et calculer le prix de la commande.
Pour mieux faire apparatre la transmission du devis au client, on fait figurer un nud
dobjets. Cela reprsente un flux de donnes changes entre le service comptable et le
client. Devis est le nom dune classe du systme : les flots de donnes sont typs. Le client
peut ensuite dcider de modifier sa commande (retour dans lactivit initiale Passer commande), de lannuler (passage dans ltat final, signifiant la fin de ce traitement), ou de valider le devis.
Sil valide, deux actions peuvent tre engages en parallle : la prparation de la commande par le service livraison et le traitement de la facturation et du paiement. Le ser vice
comptable cre une facture quil envoie au client (lobjet facture transmis est alors dans ltat
mise). Celui-ci effectue le paiement et renvoie la facture (qui se trouve prsent dans
ltat rgle).
Quand la commande est prte et le paiement du client confirm (synchronisation par rendezvous de ces deux activits), la commande est livre au client et le traitement sachve.
Notation
Une activit UML est reprsente par un rectangle aux coins arrondis (figure 5.3) et
contient la description textuelle des actions de base quelle ralise, ou simplement son nom
si le niveau de spcification nest pas encore assez prcis pour dtailler les actions. Aucune
syntaxe spcifique nest propose dans la norme pour lexpression de ces actions : on
utilise le plus souvent une syntaxe proche dun langage de programmation ou, dfaut,
du pseudo-code. Les activits sont lies par des transitions reprsentes par des arcs orients pouvant porter des gardes, qui reprsentent le cheminement du flot de contrle de
lapplication.
Certaines actions sont distingues par un graphisme particulier (figure 5.1).
162
UML 2
Chapitre
Figure 5.2
Client
Service comptable
Service livraison
La commande.
tat Initial
Passer Commande
Lignes deau
tablir Devis
Vrifier disponibilit
Sous-activit
Calculer Prix
[modifier]
Activit composite
Transition
Devis
Garde
Fork
Valider
Activit
[valider]
[annuler]
Facture
[mise]
tablir facture
Facture
[rgle]
Valider Paiement
Prparer Commande
Rgler facture
Nud Objet
Join
Invariant dtat
Livrer Commande
Clturer Dossier
tat final
Figure 5.3
Notation
des activits.
Prparer Commande
Activit
3.2 STRUCTURES
DE CONTRLE
Le distributeur de billets
Cet exemple illustre diffrentes reprsentations des alternatives. Aprs la vrification prliminaire, deux activits sont potentiellement dclenches : la restitution de la car te si la vrification choue ou lactivit taper PIN (Personal Identification Number) sinon. Aprs le contrle
du code PIN, on trouve trois alternatives, connectes un point de dcision ; une seule
dentre elles sera utilise. Enfin, la note portant le mot-cl decisionInput indique que les
gardes sur les transitions aprs le point de choix comparent la variable autorisation accorde
oui ou non.
Cet exemple est modlis un niveau relativement lev dabstraction, les actions tant exprimes en langage naturel. Il dcrit de faon concise un comportement relativement complexe.
Ce niveau de description conceptuelle est bien adapt la spcification dtaille des cas
dutilisation, car il rsume de faon synthtique plusieurs scnarios.
164
UML 2
Chapitre
Figure 5.4
Le distributeur
automatique
de banque.
external
Client
Insrer Carte
Vrification prliminaire
[chec]
[else]
[Code faux et essai < 3]
Taper PIN
Contrler code
Avaler Carte
[else]
Saisir montant
[Code bon]
Obtenir Autorisation
[non]
Restituer Carte
decisionInput
Autorisation accorde
[oui]
Dlivrer Billets
Les points de dcision peuvent aussi modliser la fin dune alternative. On les appelle alors
points de dbranchement .
EXEMPLE
Figure 5.5
Compter les lignes,
les mots et les
caractres.
nc : int ;
nw : int ;
nl : int ;
activity wc
nc = nw = nl = 0;
inWord = false;
c : char ;
inWord : bool
c = getchar();
nc++;
decisionInput
c
print nc nw nl;
[EOF]
[else]
decisionInput
isWhitespace(c)
[\n]
[else]
[true]
nl++;
inWord = false;
[inWord==true]
[else]
[else]
[inWord==false]
inWord=true;
nw++;
Activit structure
La norme prvoit galement des activits dites structures , qui utilisent les structures de
contrle usuelles (conditionnelles et boucle) travers une syntaxe qui dpend de loutil. La
syntaxe prcise de ces annotations, comme celle des actions de base, nest donc pas dfinie
dans la norme : on utilise du pseudo-code ou la syntaxe dun langage de programmation.
EXEMPLE
Avec une syntaxe C++, on dcrit une activit contenant une boucle (le calcul du prix total
dune facture) et une activit contenant une conditionnelle (une implmentation possible de
isWhitespace() de lexemple prcdent). Les arguments et valeurs de retour sont dcrits
laide de pins, prsents en dtail la section 3.4.
Figure 5.6
Activit structure.
total=0;
for (int i=lignes.size()-1 ; i >= 0 ; i--)
total += lignes[i].prixUnitaire * lignes[i].quantit
lignes : vector<ligneCommande>
bool
Ce type dactivit est fourni par commodit, mais son utilisation rend peu visible le cheminement du flot de contrle.
3.3 ACTIVIT
ET CLASSEUR
Les activits peuvent tre utilises pour des descriptions de diffrents niveaux de dtails, de
la plus lmentaire (description conceptuelle dun comportement par exemple) la plus
fouille, faisant alors intervenir des actions UML pour tre la hauteur de ce que permet un
langage de programmation.
Une de leurs utilisations principales est de dcrire leffet doprations de classeur. Les activits peuvent, dans un premier temps, ne pas avoir un contexte bien dfini. Cest le cas dans
lexemple du distributeur de banque : le systme complet du DAB ntant pas encore
dcompos en sous-lments, seules les activits affrentes au client ont t places sur une
166
UML 2
Chapitre
ligne deau. Une description plus dtaille ncessiterait sans doute de dcomposer plus finement les actions, en vue de reprsenter plus explicitement les appels dopration sur les
composants du systme (lecteur de cartes, serveur dauthentification, imprimante pour le
ticket). Sur le diagramme de la figure 5.4, le mot-cl extern, sis au-dessus de la partition
du client, indique que ce dernier nest pas un lment du systme en cours de conception.
Les lignes deau (ou partitions) permettent dattribuer les activits des lments particuliers du modle. Une partition peut elle-mme tre dcompose en sous-partitions. La
liste suivante runit les types standard dune tiquette de partition :
Classeur. Les activits de la partition sont sous la responsabilit du classeur indiqu : le
contexte de lactivit est donc celui du classeur concern. Lappel effectif de lactivit dans
un scnario de comportement doit se faire sur une instance du classeur.
Instance. En plus des contraintes imposes par la notion de classeur, lappel effectif doit
se faire sur linstance cite.
Attribut et valeur. Ce cas est assez diffrent des prcdents. On a toujours au moins deux
niveaux de partition : la partition englobante donne le nom de lattribut concern, et ses
sous-partitions spcifient une valeur de lattribut.
EXEMPLE
Utilisation de partitions
Il est possible daffiner le modle de la commande prsent prcdemment en spcifiant plus
finement le type des lignes deau. Il sagit dindiquer, dune part, que les activits du service
comptable sont rattaches une instance qui a, pour lattribut libellService de type Service,
la valeur Service Comptable et, dautre part, que le client ne fait pas partie intgrante du
systme tudi.
Figure 5.7
Lignes deau.
external
Client
Service livraison
Les activits peuvent appartenir plusieurs partitions, si ces dernires fournissent une
information qui nest pas conflictuelle (par exemple, une activit donne ne peut appartenir
qu un unique classeur). On peut mme cumuler graphiquement des partitions en les
plaant horizontalement et verticalement.
EXEMPLE
Partitions multidimensionnelles
La version simplifie de la commande prsente la figure 5.8 exprime que la rception des
commandes se fait au sige social Paris, que la validation du paiement est ralise par le
service comptable de Roubaix, et que les commandes sont prpares et livres par un ser vice
livraison situ galement Roubaix. Lutilisation de partitions multidimensionnelles ne facilite
pas la lisibilit des diagrammes.
Figure 5.8
Client
Service comptable
Service livraison
Partitions
multidimensionnelles.
Valider Commande
Enregistrer Commande
Paris
tablir Facture
Facture
[rgle]
Valider Paiement
Prparer Commande
Clturer Dossier
Livrer Commande
Rgler Facture
Roubaix
Facture
[mise]
Il est possible de spcifier la partition laquelle appartient une activit directement dans
ltiquette de lactivit, entre parenthses. Si une activit est ainsi tiquete, cette information prvaut sur lappartenance ventuelle une partition graphiquement reprsente.
EXEMPLE
Partition explicite
Cette notation est moins encombrante graphiquement, mais met moins bien en valeur lappartenance de groupes dactivits un mme conteneur.
Figure 5.9
external
(Client)
Rgler facture
Partition explicite.
3.4 ARGUMENT
(Service Comptable)
Etablir facture
(Service Livraison)
Livrer Commande
ET VALEUR RETOURNE
168
UML 2
Chapitre
Pin
Pour spcifier les valeurs passes en argument une activit et les valeurs de retour, on utilise des pins. Un pin reprsente un point de connexion pour une action : laction ne peut
dbuter que si lon affecte une valeur chacun de ses pins dentre ; quand elle se termine,
une valeur doit tre affecte chacun de ses pins de sortie.
La smantique associe est celle des langages de programmation usuels : les valeurs sont
passes par copie, une modification des valeurs dentre au cours du traitement de laction
nest visible qu lintrieur de lactivit.
Un pin est reprsent par un petit carr attach la bordure dune activit. Il est typ et
ventuellement nomm. Il peut contenir des flches indiquant sa direction (entre ou
sortie) si cela nest pas dtermin par le contexte dutilisation de lactivit.
EXEMPLE
Utilisation de pins
Soit lactivit reprsentant lopration produit entre deux entiers a et b. On utilise un pin pour
reprsenter chaque argument, et un pin de sortie pour reprsenter la valeur retourne.
Figure 5.10
a:int
Reprsentation
de pins.
res = a * b ;
res:int
b:int
Les valeurs associes aux pins peuvent tre utilises comme les variables du contexte dans les
traitements associs lactivit. Introduisez un pin par argument du traitement. Vous pouvez ainsi de dfinir des traitements paramtrs, ce qui manquait cruellement aux versions
prcdentes dUML.
Les pins servent galement reprsenter des mcanismes dexceptions. Un triangle signale
un pin dexception.
EXEMPLE
Figure 5.11
Pin dexception.
index:int
(java.util.Vector)
elementAt
IndexOutOfBoundsException
o : Object
Vous avez donc les moyens de reprsenter graphiquement une opration dun classeur, avec
sa signature complte : arguments, type de retour et exceptions potentiellement leves. Vous
avez en outre la possibilit de dfinir une activit comme appartenant une classe. En
conclusion, les mcanismes essentiels de la programmation oriente objet sont prsents
dans les diagrammes dactivits.
conteneur typ qui permet le transit des donnes. Il sert galement de stockage : il peut contenir plusieurs instances dobjet, la manire dun tampon (buffer).
Un nud dobjets (ou un pin) peut imposer des contraintes, que doivent vrifier les objets
quil contient. Elles sont exprimes sous la forme dinvariants dtat, nots entre crochets.
Implicitement, tout arc ayant pour source ou destination un nud dobjets est un flot
dobjets plutt quun flot de contrle. Un flot dobjets peut porter une tiquette mentionnant deux annotations particulires :
transformation indique une interprtation particulire de la donne transmise par le flot.
selection indique lordre dans lequel les objets sont choisis dans le nud pour le quitter.
Une annotation de slection peut galement figurer sur un nud dobjets : lordre spcifi est alors commun tout arc ayant pour source ce nud.
Figure 5.12
:Type1
:Type1
Figure 5.13
Annotations des
flots de donnes
et invariants dtat.
selection
priorit maximale,
FIFO priorit gale
remplir
commande
:Commande
[remplie]
transformation
Commande.client
expdier
commande
clturer
commande
expdier
reu au client
:Commande
[clture]
:Commande
[remplie]
:Client
Enfin, certains flots dobjets correspondent mieux la notion de flot continu de donnes :
ils portent ltiquette {stream} ou ont pour cible un pin de type {stream} (reprsent par un
carr noir plein). Le comportement usuel dune activit consiste consommer un objet
sur chaque pin dentre, sexcuter et fournir une valeur sur chaque pin de sortie. Une
activit peut cependant consommer (respectivement mettre) plusieurs donnes sur ses
pins dentre (respectivement de sortie) qui sont du type stream.
EXEMPLE
Filtres Unix
La plupart des commandes standard Unix sont conues comme des filtres, qui lisent sur leur
entre standard stdin et crivent sur leur sortie standard stdout. Le signalement des erreurs
passe par un troisime flux : stderr. Il est possible de chaner les commandes, ce qui permet
de construire facilement des commandes plus puissantes.
Figure 5.14
Le chanage des
commandes tar
et gzip permet de
crer des archives
compresses.
"tar | gzip"
Liste<fichiers>
stdout
stdout
tar
gzip
stdin
stderr
stderr
stderr
{stream}
170
UML 2
stdout
deux notations
quivalentes de stream
Chapitre
(4)
Mcanismes avancs
Les constructions prsentes la section 3 sont suffisantes pour la majorit des usages.
Ce jeu dlments de base constitue le cur du formalisme des diagrammes dactivits. Il
est recommand de bien comprendre ces mcanismes avant daborder cette section, qui
prsente des concepts plus complexes proposs par les diagrammes dactivits.
4.1 CONCURRENCE
La vocation premire des diagrammes dactivits est de dcrire des traitements a priori
squentiels : on ne dbute lactivit aprs une transition que lorsque celle qui la prcde est
termine.
Cependant, il est possible de dcrire des mcanismes concurrents laide de diagrammes
dactivits. Cela ne signifie pas ncessairement que limplmentation est concurrente, mais
plutt que les actions dcrites ne sont pas lies par une dpendance causale : lordre dexcution na pas dincidence sur le comportement global.
Dans lexemple de la commande prsent la section 3.1, lactivit prparer commande peut
tre ralise avant ou aprs lactivit tablir facture, ou mme simultanment.
La gestion de la concurrence ajoute deux nouveaux lments graphiques aux diagrammes
dactivits :
Les barres de synchronisation. Elles sont reprsentes par une barre noire paisse et
courte. Plusieurs transitions peuvent avoir pour source ou pour cible une barre de synchronisation. Lorsque la barre de synchronisation a plusieurs transitions en sortie, on
parle de transition de type fork, qui correspond une duplication du flot de contrle en
plusieurs flots indpendants ; quand la barre de synchronisation est atteinte, un jeton de
contrle est produit sur chaque arc de sortie. Quand la barre de synchronisation a plusieurs transitions en entre, on parle de transition de type join, qui correspond un
rendez-vous entre des flots de contrle ; la transition ne peut tre franchie que si un jeton
de contrle est prsent sur chacune de ses entres. Pour plus de commodit, il est possible
de fusionner des barres de synchronisation de type join et fork, et donc davoir sur une
mme barre plusieurs transitions entrantes et sortantes. Dans tous les cas, le franchissement des transitions se fait de manire atomique, la barre de synchronisation ne stocke
pas les jetons : ils restent dans les activits en amont jusqu ce que la transition puisse
tre franchie.
Les nuds de contrle de type flow final. Ils sont reprsents par un cercle contenant une
croix et correspondent la fin de vie dun jeton de contrle. Un jeton de contrle qui
atteint un tel nud est dtruit. Les autres flots de contrle ne sont pas affects. Au
contraire, si un flot de contrle atteint un nud de contrle final, tous les autres flots
de contrle de lactivit sont interrompus et dtruits.
EXEMPLE
Monter pice peut avoir des dures variables ; chaque fois quelle se termine, on teste si le
montage est termin ou non. Une fois la dernire pice monte, le produit est emball et
lactivit englobante se termine.
Si ce diagramme suggre lexistence de concurrence, ce nest l quune possibilit dimplmentation : un seul oprateur physique peut raliser lensemble des activits (de faon squentielle)
sans dvier de la smantique du modle.
Figure 5.15
Fournir Pice
Mcanismes
exprimant la
concurrence.
Monter Pice
Emballer
[montage fini]
[else]
[manque pice]
[else]
Les barres de synchronisation permettent donc dexprimer que des actions peuvent dbuter
en parallle, alors que les transitions ordinaires des diagrammes dactivits imposent une
excution squentielle. Les transitions de type join imposent, au contraire, dattendre la fin
dun ensemble dactivits avant de poursuivre lexcution.
4.2 EXCEPTIONS
Les exceptions sont un concept important en programmation oriente objet : elles permettent dinterrompre un traitement quand une situation qui dvie du traitement normal se
produit et assurent une gestion plus propre des erreurs qui peuvent se produire au cours
dun traitement.
Un exemple typique est la gestion de la division par zro dans une opration arithmtique :
si lon dclare une opration float diviser (float dividende, float diviseur), comment signaler lappelant quune erreur de dbordement se produit quand le diviseur vaut zro ? On
ne peut utiliser une valeur de retour particulire que lappelant pourrait tester car toutes les
valeurs de retour sont potentiellement valides. La solution prconise est donc de recourir
une exception, qui ne correspond pas une valeur de retour de la signature normale de
lopration. Lappelant a alors le choix, quand il appelle lopration diviser, de traiter
lexception ou de la laisser remonter son propre appelant. Une exception qui nest traite
aucun niveau correspond une faute du programme. Dans la plupart des langages orients
objet, elle induit la fin du processus ; en UML, le comportement nest pas spcifi, mais le
modle est alors considr comme incomplet ou mal form.
172
UML 2
Chapitre
EXEMPLE
Traitement des exceptions dans le calcul du produit dune matrice par un vecteur
Cet exemple montre un mcanisme de gestion dexceptions. Lactivit protge calcule un produit dune matrice par un vecteur en deux tapes : on inverse dabord la matrice argument m,
puis on ralise le produit par le vecteur argument v.
Linversion de matrice est susceptible de lever une exception si lopration est impossible
(discriminant nul par exemple). Linversion et le produit sont susceptibles de provoquer un
dbordement de capacit de flottants. On protge lensemble du bloc par deux gestionnaires dexception distincts : selon lexception leve, on fournit une constante (de type vecteur)
diffrente.
Dans tous les cas, laction afficher vecteur est ralise la fin du traitement.
Figure 5.16
m : matrice
v : vecteur
Gestionnaire
dexception.
ExceptionMatriceSingulire
rendre la constante
vecteur1
inverser matrice
res : vecteur
: matrice
m : matrice
v : vecteur
calculer produit
res : vecteur
rendre la constante
vecteur2
ExceptionDbordement
res : vecteur
afficher vecteur
Les exceptions sont des classeurs part entire et peuvent, ce titre, porter des informations
sous la forme dattributs, et des oprations. Vous pouvez galement dcrire des arbres
dhritage dexceptions. Cela permet de spcifier des messages dtaills associs aux erreurs
et des donnes supplmentaires dcrivant lesdites erreurs. Un gestionnaire dexception
spcifie le type dexception quil est capable de traiter : toute exception drivant de ce type
est galement traite par un tel gestionnaire.
EXEMPLE
Figure 5.17
Hritage et
exceptions.
interface
Throwable
+printStackTrace()
...
Exception
IOException
message : String
+getMessage ()
InterruptedIOException
EOFException
bytesTransferred : int
174
UML 2
Dans cet exemple, lactivit dbute la rception dune commande dun client. Toute la suite
de lactivit grer commande est interruptible : le client est libre dannuler sa commande
tout moment. Sil passe lordre dannuler, le dossier est effac. Une fois que le paiement
est effectif et que la commande est prte, il devient impossible de lannuler : la transaction est
dment enregistre et le dossier cltur.
Aprs rception dun ordre dannulation, et durant lactivit annuler dossier, lactivit traiter
paiement peut continuer sexcuter. Cependant, elle est, elle aussi, interrompue quand le
flot de traitement a fini dannuler le dossier et que ltat final est atteint (cela termine tous les
flots de lactivit).
Chapitre
Figure 5.18
Rgion interruptible.
Ordre dannuler
Commande
crer dossier
prparer commande
annuler dossier
clturer dossier
4.3 SQUENCE
ET ITRATION
Une zone dexpansion, graphiquement reprsente par un cadre en pointills, exprime une
action rpte sur chaque lment dune collection. Une collection peut tre implmente
par un tableau ou une liste par exemple. Le type des objets contenus dans la collection doit
tre connu. La collection est passe la zone dexpansion travers un pin dexpansion, graphiquement reprsent par un rectangle divis en compartiments, cens voquer la notion
de liste dlments.
Lactivit lintrieur de la rgion dexpansion est excute une fois pour chaque item de la
collection, la manire dun foreach des langages Python, Perl ou Fortran. Cette activit
interne doit prendre en entre un objet respectant le type de la collection : vu de lextrieur
de la rgion, le pin dexpansion est de type Collection<Objet>, mais vu de lintrieur, il est de
type Objet. chaque excution de lactivit interne, sa valeur de retour est insre dans la
collection de sortie la mme position (indice) que son entre. Lactivit interne peut galement se terminer sans rendre de valeur, ce qui correspond un mode filtre : la collection
rsultante compte alors moins de valeurs que lentre.
Une zone dexpansion peut tre de lun des trois types suivants, signal par un mot-cl plac
dans langle de la rgion dexpansion :
parallel. Les excutions de lactivit interne sur les lments de la collection sont indpendantes et peuvent tre ralises dans nimporte quel ordre ou mme simultanment.
Une implmentation sur une architecture parallle peut donc efficacement raliser ce
traitement.
iterative. Les occurrences dexcution de lactivit interne doivent senchaner squentiellement, en suivant lordre de la collection dentre. Si cette dernire na pas dordre de
parcours bien dfini (table de hachage par exemple), un ordre quelconque est choisi
de faon indterministe.
stream. Les lments de la collection sont passs sous la forme dun flux de donnes
lactivit interne, qui doit tre adapte aux traitements de flux. Cela permet de contrler
plus finement le paralllisme des excutions.
EXEMPLE
Figure 5.19
string : char[]
Zone dexpansion.
parallel
c : char
if (c >= a && c <= z)
return c-a+A;
else
return c;
:char
: char[]
UML 2 a introduit le mcanisme des zones dexpansion pour permettre une meilleure
expression du paralllisme des actions.
Conclusion
La vue offerte par les diagrammes dactivits est centre sur les traitements. Elle permet de
modliser efficacement le cheminement de flots de contrle et de flots de donnes. Les
apports importants dUML 2 au niveau de ces diagrammes assurent lexpression prcise du
comportement : la gnration de code est un objectif central dans ces diagrammes.
En fournissant une vision abstraite des traitements, la modlisation des activits ne fixe
cependant pas compltement les choix dimplmentation. Lexpression de mcanismes
concurrents, par exemple, nimpose pas leur ralisation sur une architecture parallle. De
mme, la manipulation de variables multivalues et de collections permet un bon niveau
dabstraction.
Les diagrammes dactivits sont particulirement utiles dans la phase de conception pour la
description dtaille des cas dutilisation. On utilise alors une syntaxe libre, qui dcrit des
actions conceptuelles de haut niveau. Ils sont galement utiles dans la phase de ralisation
pour la description prcise des traitements, avec un niveau de dtails qui se rapproche dune
spcification pleinement excutable. On utilise alors une syntaxe inspire dun langage de
programmation pour dcrire les actions et lon peut prciser finement la gestion des exceptions ou le passage des paramtres.
La description graphique des traitements permet de mieux cerner le cheminement des alternatives. Les mcanismes dimbrication et dappels (call) permettent de prserver une certaine
concision. Cependant, vitez les diagrammes dactivits quand le traitement est trs linaire :
une description textuelle de lenchanement est alors suffisante dans la plupart des cas.
Arriv ce stade du livre, sept diagrammes ont t prsents : le diagramme des cas dutilisation, celui des classes et des objets, le diagramme de squence et de communication, le
diagramme dtats-transitions et, enfin, le diagramme dactivits. Ils permettent de modliser quasiment tout systme. Deux autres diagrammes ont volontairement t relgus dans
les annexes : le diagramme de composants et celui de dploiement. Ils sont, en effet, suffisamment simples pour ne pas faire lobjet dun chapitre entier. Le chapitre suivant, quant
lui, prsente comment tous ces diagrammes sassemblent et se compltent pour donner une
vision globale et cohrente dun systme. La partie pratique de ce chapitre est constitue
dune tude de cas.
176
UML 2
Chapitre
Problmes
et exercices
Les exercices suivants couvrent les principaux concepts des diagrammes dactivits.
EXERCICE 1
PROGRAMMATION
EN ACTIVITS
1. Les chanes de caractres du langage C sont codes comme un tableau de caractres non
nuls, termin par un caractre \0. Par exemple, la chane s="hello!" est code
comme suit :
s[0]
s[1]
s[2]
s[3]
s[4]
s[5]
s[6]
\0
Dcrivez une activit implmentant la fonction strlen, qui prend en entre un tableau
de caractres et rend un entier correspondant la taille de la chane. Exemple :
strlen("hello!")=6.
2. Proposez le diagramme dactivits qui compte les mots, les lignes et les caractres de
son entre.
La fonction getchar() lit le prochain caractre disponible sur lentre. Sil sagit du
caractre spcial EOF, le programme affiche ses rsultats et se termine.
Lopration bool isWhitespace(c:char) rpond vrai si le caractre pass en argument
est considr comme un espace.
1. Le traitement est relativement simple : on itre sur le tableau de caractres de lentre ;
quand la valeur du caractre est \0, on rend lindex courant. Une implmentation efficace en C manipulerait plutt deux pointeurs sur caractre que lindice len, mais cela
suppose lexistence doprations arithmtiques sur les pointeurs, absentes en UML.
Figure 5.20
char[] s
decisionInput
s[len]
len++
len=0
[else]
[\0]
int len
Exercices
Calcul de la longueur
dune chane de
caractres.
EXERCICE 2
VENTE
EN LIGNE
Un site de vente en ligne propose des produits, placs dans un panier virtuel tandis que
lutilisateur navigue. Pour valider ses achats, il clique sur le bouton Sortir du magasin. On lui
propose alors de se connecter un compte existant, ou den crer un sil nen a pas encore.
Pour crer un nouveau compte, lutilisateur doit fournir une adresse de messagerie, qui
sert galement de login, son nom et son adresse, ventuellement une adresse de livraison,
et ses coordonnes bancaires. On prvoit le cas o ladresse de messagerie est dj associe
un compte. Si la validation de ces informations russit, on cre un nouveau compte et
lon propose lutilisateur de sy connecter.
On passe ensuite la confirmation des achats.
Modlisez cette procdure laide dun diagramme dactivits.
Lnonc est suffisamment vague pour donner lieu de nombreuses interprtations. Cela
est typique dune spcification textuelle des besoins, telle quon en trouve dans un cahier des
charges. La solution propose ici fixe donc un certain nombre de choix dorganisation de la
procdure.
On se concentre sur la partie concernant lauthentification de lutilisateur, et la cration
dun compte le cas chant.
Figure 5.21
Une interface web
pour lauthentification.
remplir panier
loger utilisateur
[else]
[compte invalide]
[oui]
compte existant?
saisie login,
mot de passe
[non]
[adresse connue]
crer le compte
saisie email
[else]
modifier
adresse de livraison
178
UML 2
Chapitre
Lorganisation propose correspond une interface de type wizard : il faut valider tous
les champs dune page, cliquer sur Suivant, pour passer la validation des prochains champs.
Si les informations sont incorrectes, un message avertit lutilisateur et lcran suivant saffiche.
Cette vrification des champs nest donc pas reprsente ici : il revient lactivit de saisie de
se terminer quand la saisie est valide.
Chaque activit correspond donc assez bien un cran dinterface, les transitions exprimant
une navigation possible entre ces crans. Vous pourrez rutiliser ces activits ailleurs. Par
exemple, la modification de ladresse de livraison est accessible depuis un menu quand lutilisateur est connect son compte.
Ce niveau de description est bien adapt la description dinterfaces homme-machine et
permet de se concentrer sur la vision logique dun traitement, sans se perdre dans le modle
structurel en classes.
ALGORITHMIQUE
Les diagrammes dactivits permettent de raisonner sur des algorithmes, au cours de lactivit de spcification dtaille.
Vous allez utiliser les diagrammes dactivits pour dcrire des algorithmes de tri.
1. laborez une activit swap qui prend trois arguments, un tableau tab et deux indices a
et b, et change le contenu de la case tab[a] et tab[b].
2. En utilisant swap, dcrivez un tri par bulles dun tableau tab de taille n. Lalgorithme
consiste en n 1 parcours du tableau, chacun amenant (par des appels successifs swap
sur des cases contigus) le plus grand lment du tableau en dernire position (donc en
position n 1 i litration numro i).
3 .Lalgorithme glouton du tri par bulles est peu efficace, en raison du grand nombre de
copies inutiles ralises. crivez un tri par insertion, qui opre en n itrations : chaque
itration de numro i, considrez la plage de valeurs de 0 i 1 comme trie. Lalgorithme consiste chercher le bon endroit o insrer la valeur en position i, afin de trier
la plage de valeurs de 0 i. Copiez la valeur en position i dans une variable temporaire
et dcalez les valeurs avant cette position vers la droite (une par une) jusqu trouver
lendroit ou recopier la valeur de la variable temporaire.
4. Lalgorithme prcdent a encore une complexit leve. Les tris les plus efficaces sont
fonds sur des appels rcursifs qui font chuter la complexit. La fusion de deux tableaux
tris en un tableau tri est une opration de complexit linaire sur la taille du tableau
rsultant. Pouvez-vous concevoir un algorithme (tri par fusion) qui sappuie sur cette
proprit et des appels rcursifs pour trier plus efficacement un tableau ? Indication :
vous pouvez dfinir une activit tri fusion qui prend un tableau t et deux indices, g et d,
et trie la portion du tableau comprise entre les indices g et d.
Notons que les algorithmes prsents ici sont fonds sur le trs classique livre Le Langage C,
de Kernighan et Ritchie. La lecture compare des versions en C et en diagrammes dactivits
est instructive.
1. Utilisez une variable temporaire pour stocker lune des deux valeurs des variables
changer avant de lcraser en la remplaant par la valeur de lautre variable. Ce diagramme met bien en avant le flot des valeurs. La variable temporaire est reprsente par
un pin.
Exercices
EXERCICE 3
Comme vous navez pas plus de prcisions sur le type des objets contenus dans le tableau,
utilisez un template pour reprsenter ce type : lopration est en effet gnrique et valable
quel que soit le type T contenu dans le tableau.
Figure 5.22
change de valeurs
de deux variables.
swap
a : int
tmp:T
tmp = T[a]
tab : T[]
T[a] = T[b]
T[b] = tmp
b : int
Figure 5.23
condition darrt
Comparable T
Tri bulles
i : int
i++
j : int
tab : T[]
j++
[i <= n]
i=1
[else]
[else]
j=1
swap(j-1,j,tab)
[j<= i]
[else]
[ tab[j-1]>tab[j] ]
n : int
initialisation
180
UML 2
corps de boucle
on les change
Chapitre
3. Cette version du tri limite le nombre de copies intermdiaires de valeur. Elle ralise un
roulement des variables (au lieu de les changer deux deux) qui dplace tout un bloc
avant de recopier la variable temporaire.
La structure de lalgorithme reste assez proche du tri par bulles. De ce fait, il a la mme
complexit thorique en O(n2) en nombre doprations que le tri par bulles, mais ralise
un peu moins de copies que lui. Vous vous en apercevrez en comparant les deux
schmas : limbrication des deux boucles apporte le facteur n2 et les diffrences entre
les actions dans chaque boucle napportent quun facteur constant, donc thoriquement
ngligeable en complexit.
Figure 5.24
i : int
i++
tab : T[]
tmp : T
j : int
j-[i <= n]
i=1
tmp = tab[i]
[j>0 et t[j-1]>tmp]
[else]
j=i
tab[j] = tab[j-1]
[else]
tab[j] = tmp
n : int
Exercices
Les numros indiqus ct des pins donnent lordre des arguments. Lappel rcursif est
reprsent comme un appel de fonction normal.
Figure 5.25
Tri par fusion.
Tri fusion
m : int
s : int [d-g+1]
m = (g+d)/2
[d <= g]
i : int
j : int
1
t : T[]
2
g : int
3
d : int
i : int
j : int
i++
j++
[i<=m]
i=g
j=0
i-j++
[i>m]
i=d
j=m-g+1
s[j]=t[i]
[else]
Attention, i dcroit :
deuxime moiti copie
en ordre inverse !
s[j]=t[i]
[else]
i++
t[i]=s[k]
k--
i=g
j=0
k=d-g
[else]
[else]
[i<=d]
EXERCICE 4
t[i]=s[j]
j++
[ s[j] <= s[k] ]
VIDOCLUB
En vous basant sur la description textuelle du vidoclub de lexercice 5 du chapitre 1,
reprsentez par un diagramme dactivits le cas dutilisation Emprunter une vido .
La description des cas dutilisation est lune des applications immdiates des diagrammes
dactivits. Elle permet daccompagner la description textuelle par un schma synthtique,
mais ne la remplace pas.
182
UML 2
Chapitre
Figure 5.26
Exception E3
(client)
introduire carte
Le cas dutilisation
Emprunter vido .
Exception E1
valider carte
15 secondes
[carte invalide]
[else]
valider crdit
suprieur ou gal
un euro
avaler carte
(client)
prendre carte
Alternatif A1
[else]
proposer rechargement
[crdit suffisant]
Exception E4
rechercher video
jecter carte
[annulation]
dlivrer cassette
15 secondes
avaler cassette
annuler opration
(client)
prendre cassette
Exception E2
afficher temps
et prix de location
CACHE DOPRATIONS
Cet exercice aborde la modlisation dun mcanisme de cache, permettant de limiter le cot
des calculs rpts. Cette stratgie est trs utile pour les calculs coteux en temps, mais
consomme en contrepartie plus de mmoire.
Exercices
EXERCICE 5
Cet exercice propose de modliser un mcanisme de cache. Une classe Map reprsente une
table associative. Elle contient conceptuellement des couples <cl,valeur>. La recherche de
la valeur associe une cl donne (opration get) est trs rapide (complexit thoriquement constante, quel que soit le nombre de couples dans la table). Une seule valeur peut
tre associe chaque cl distincte : si une valeur est dj associe la cl, lopration put
dajout la table crase lancienne valeur. Les tables de hash ou les arbres de recherche sont
des implmentations frquemment rencontres de tables associatives.
Figure 5.27
Les classes
proposes pour
implmenter
un cache.
Map
Object get (Object key)
Object put (Object key, Object value)
postcondition
si la cl key nest pas dans la table rends la rfrence nulle.
sinon rends la valeur associe la cl key
postcondition
la valeur value t associe la cl key dans la table.
{abstract}
Cache
-map : Map
Fonction2
#Object doComputation (Object)
Ralisent un
calcul coteux
Vous allez raliser une classe abstraite Cache qui offre ses classes drives une fonctionnalit de cache. Elle est munie, pour cela, dune instance de la classe Map, qui sert stocker
les rsultats dj calculs par cette instance de fonction.
Les classes drives de Cache ralisent un calcul coteux en temps. De telles classes, qui
servent raliser un calcul, sont parfois appeles foncteurs . Elles doivent implmenter
lopration de visibilit protge doComputation (coteuse). Elles offrent publiquement
lopration compute aux utilisateurs de la fonction.
1. Dcrivez laide dun diagramme dactivits le comportement de lopration compute.
2. Prvoyez que largument pass compute nest pas du bon sous-type de Object pour la
fonction concrte. Si cest le cas, lopration doComputation risque de lever une exception
de typage quand elle essaie dinterprter lobjet pass en argument (ClassCastException
par exemple en Java standard). Pour offrir une gestion propre, si une erreur de ce type se
produit, vous voulez que compute lve une exception (non standard) de type TypeException. Enrichissez le diagramme prcdent pour reprsenter ce mcanisme.
1. Lopration compute cherche si le rsultat de lopration a dj t calcul pour son argument. Si cest le cas, elle rend la valeur stocke dans le cache. Sinon, elle ralise le calcul
par un appel la fonction abstraite doComputation. Ensuite, elle ajoute ce nouveau rsultat dans la table avant de le rendre lappelant.
184
UML 2
Chapitre
Figure 5.28
Comportement
associ lopration
compute du cache.
arg : Object
(Cache)
compute
[else]
res = map.get (arg)
[res != null]
map.put(arg,res)
res: Object
2. Supposez que doComputation peut lever une exception : il faut protger lactivit qui
appelle cette fonction par un gestionnaire dexception. Enrichissez donc le diagramme en
ajoutant ce gestionnaire et un pin pour reprsenter la nouvelle signature complte (avec
lexception TypeException) de compute. Le corps du gestionnaire dexception se contente
de lever lexception approprie : lopration dajout dans la table qui suit lactivit
doComputation nest pas ralise.
Figure 5.29
(Cache)
compute
raise TypeException
arg : Object
:ClassCastException
:TypeException
[else]
res = map.get (arg)
[res != null]
res: Object
map.put(arg,res)
Exercices
Opration compute
avec la gestion des
exceptions.
Chapitre
UML en pratique
1. Un processus pour la
modlisation dun systme ...... 188
2. Guide mthodologique ........... 189
tude de cas ............................... 196
187
(1)
188
UML 2
Chapitre
UML couvre la plupart des tapes du cycle de vie dun projet (figure 6.1).
Figure 6.1
planification
La place dUML
dans le cycle de
dveloppement
dun systme.
analyse
UML
conception
implmentation
tests
dploiement
UML
maintenance
(2)
Guide mthodologique
Considrons un projet de dveloppement dun systme logiciel. La premire tape du cycle
de vie, la planification, a permis de dfinir le problme, dtablir un calendrier, et de vrifier
la faisabilit du projet. Notre description commence ltape danalyse. Rappelons quelle
sert prciser le besoin auquel doit rpondre un systme, et spcifier et comprendre ce
que ce systme doit faire.
Remarque
La description qui suit est succincte mais assez complte car nous dcrivons toutes les tapes
dun processus (mme celles o UML nest daucune utilit), afin que vous puissiez vous rendre compte de la porte, mais galement des limites dUML. Nous insistons particulirement
sur les phases danalyse et de conception car cest l o UML est le plus utile. La phase de
dploiement est aborde dans lannexe D et dans ltude de cas. Des indications sur la
faon dimplmenter un diagramme de classes dans un langage de programmation objet
sont galement donnes dans lannexe E.
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.
190
UML 2
Chapitre
Remarque
Un modle est rarement correct ds sa premire construction. Il est souvent ncessaire de
revenir plusieurs fois dessus afin de laffiner. Par exemple, il ne faut pas sattendre trouver
toutes les associations ds la premire construction du diagramme de classes. La modlisation
ne se fait pas par une succession linaire dtapes, mais progresse souvent par itrations.
Modle des tats du domaine. Un diagramme de classes nest quun modle et, dans un logiciel en cours de fonctionnement, il ny a pas de classe mais des objets, instances de classes. Un
diagramme de classes nest quune abstraction de la ralit. Le modlisateur a besoin de descendre un niveau plus bas (cest--dire au niveau des objets). Durant lanalyse, il ne faut
cependant pas descendre jusquau niveau physique : il est tout fait prmatur de sintresser
lallocation des ressources mmoire pour les objets, et du temps processeur pour les mthodes. En revanche, il est ncessaire de connatre le cycle de vie des objets ( quelle tape de la
vie du logiciel en production les classes vont donner naissance des objets, comment ceux-ci
vont tre utiliss et quelle tape ils seront dtruits). La description de ce cycle revient aux
diagrammes dtats-transitions. Cependant, seules les classes dont les instances ont un cycle
de vie complexe doivent donner lieu des diagrammes dtats-transitions.
La dmarche pour construire le modle des tats du domaine est la suivante :
identifier des classes du domaine ayant des tats complexes ;
dfinir les tats ;
trouver les vnements qui vont engendrer des transitions entre tats ;
construire les diagrammes dtats.
Remarque
Il est important de suivre les diffrentes tapes de la dmarche dans lordre indiqu ci-dessus.
Notamment, il faut trouver les tats avant les vnements. De nombreux vnements sont
produits par les utilisateurs dun systme. Ils sont pris en compte au moment o sont dcrits
les cas dutilisation, et donc lis une application particulire. Or, le modle du domaine
doit tre indpendant des applications.
Analyse de lapplication
Limplmentation du modle des classes du domaine donne lieu un systme statique. Ce
modle nindique pas comment des instances de classes interagissent pour raliser les fonctionnalits dune application. Un diagramme de classes, mme implment, noffre aucune
fonctionnalit aux utilisateurs. Pas plus quune implmentation du modle des tats du
domaine qui se contente de dfinir le cycle de vie des objets sparment les uns des autres.
Aprs avoir construit le modle du domaine, il faut sintresser aux applications qui utilisent ses classes.
Modle des interactions de lapplication. Cest durant la phase danalyse de lapplication
quun modle des interactions du systme est produit. Lanalyse dbute par la construction
du diagramme de cas dutilisation et se poursuit par la description des scnarios dutilisation des cas. La dmarche est dcrite en dtail dans le chapitre 1. Nous nous contentons ici
den donner un rsum :
dterminer les limites du systme ;
trouver les acteurs ;
Figure 6.2
Utilisateurs
Le dcoupage
en tiers dune
application.
Interface utilisateurs
Logique applicative
Logique mtier
Services : accs aux donnes,
transactions...
Supports de stockage
Remarque
La tendance actuelle du dveloppement de logiciels, prne notamment par lapproche
dite composant de la programmation, va vers la multiplication du nombre de couches. On
parle alors dun dcoupage en N-tiers !
Le modle des classes de lapplication concerne toutes les classes supplmentaires quil
convient dajouter pour interfacer la logique applicative avec les acteurs du logiciel. La
dmarche est la suivante :
spcifier linterface homme-machine ;
dfinir les classes la priphrie du systme.
192
UML 2
Chapitre
En modlisation objet, linterface est un objet, ou un groupe dobjets, qui permet dinteragir
avec lapplication. Durant la phase danalyse, vous devez vous intresser non pas la prsentation de linterface utilisateur mais uniquement aux flots de donnes et de contrle transmis via linterface. Il ne faut pas non plus trop dtailler les entres-sorties, mais considrer
globalement les requtes qui permettent daccder un service, la rservation dune place
de cinma, par exemple. Cela ne doit cependant pas vous empcher de construire les
maquettes des interfaces pour vous aider tablir leurs spcifications.
Les classes la priphrie du systme ont pour rle de convertir les informations utiles au
logiciel, du format comprhensible par le monde extrieur au format interne du logiciel, et
vice versa.
En plus des objets dfinissant les interfaces de lapplication, un logiciel contient un ou plusieurs objets actifs qui le contrlent. Ces objets sont appels contrleurs . Ils reoivent des
signaux du monde extrieur, ou des objets lintrieur du systme, et ragissent en invoquant des oprations sur dautres objets. Chaque contrleur a pour tche de traiter un comportement particulier du logiciel.
Remarque
UML nest pas dun grand secours lors de cette phase de lanalyse, mme si les classes qui
y sont dcouvertes peuvent tre reprsentes avec le formalisme du diagramme de classes.
La couche daccs aux donnes est construite lors de la phase de conception et non pas
pendant la phase danalyse. Il faut dabord avoir dcompos successivement les classes et
les mthodes pour arriver aux supports de stockage.
Remarque
Les diagrammes des tats-transitions de lapplication se construisent peu prs de la mme
manire que ceux du domaine de lapplication. Seul lordre des tapes diffre : pour lapplication, il faut dabord trouver les vnements avant les tats, alors que cest le contraire
pour le domaine. En effet, les tats de lapplication sont labors aprs que les cas dutilisation, qui sont dclenchs par des vnements provenant des acteurs, ont t dfi nis. On
dispose donc des vnements avant de construire les tats. Il nen est pas de mme pour
ltude du domaine qui, parce quelle doit tre indpendante des applications, ne peut pas
reposer sur des vnements.
Ajout des oprations. ce stade de lanalyse, les classes du domaine de lapplication peuvent
contenir quelques oprations (celles qui ont t suggres par ltude du domaine). Ces
oprations sont intressantes car elles sont propres au domaine, et donc indpendantes des
applications. Cependant, les oprations lies lapplication ne sont pas forcment toutes
dcouvertes. Elles peuvent tre dduites de ltude des cas dutilisation et de leurs descriptions par les diagrammes de squence et/ou dactivit produits.
2.2 PHASE
DE CONCEPTION
Avertissement
La phase de conception requiert beaucoup dexprience. Cela dpasse largement le cadre
de cet ouvrage. La description qui en est faite ici est trs sommaire, mais nanmoins utile
pour se rendre compte de lintrt dutiliser UML lors de cette phase.
Les concepteurs ont pour tche principale de prparer limplmentation. Pour un logiciel,
limplmentation consiste traduire le plus mcaniquement possible des modles danalyse
et de conception dans un ou plusieurs langages de programmation. Les modles produits
lors de lanalyse dcrivent ce que doit faire le systme indpendamment de la faon dont on
va le raliser. La conception va permettre de dcider comment raliser le systme. La phase
de conception est compose de deux tapes :
la conception du systme ;
la conception des classes.
Conception du systme
Au final, le logiciel va sexcuter sur des ressources matrielles (processeurs, mmoire). Le
concepteur du logiciel doit choisir les ressources adquates. Gnralement, il est guid par
les besoins du logiciel. Le choix ne peut pas se faire directement partir des modles danalyse, notamment pour les raisons suivantes :
Les ressources matrielles sont limites.
Les ressources matrielles sont diverses, varies et souvent htrognes.
La principale limitation des ressources concerne les microprocesseurs des ordinateurs et les
systmes dexploitation qui les grent. Ce sont des ressources partages auxquelles peuvent
accder toutes les applications qui sexcutent en mme temps sur une machine. Lors de
ltape danalyse dun logiciel, on fait la supposition que tous les objets disposent de ressources illimites. Or, au vu des ressources processeur limites, il convient de dcider, parmi
toutes les mthodes des classes du logiciel, lesquelles doivent sexcuter squentiellement,
et lesquelles doivent le faire en parallle. Pour reprer les mthodes concurrentes, on peut
analyser les modles des tats produits au moment de lanalyse.
Le choix des ressources matrielles doit tre guid par les besoins du logiciel. Une fois le
choix fait, il faut sadapter aux capacits des ressources. La principale difficult rside dans
leur grande diversit. Certains systmes dexploitation ou certains langages de programmation par exemple, fonctionnent selon un mode vnementiel, dautres sur un mode procdural, voire concurrent, etc. Le concepteur doit donc choisir une stratgie de contrle pour
son logiciel. De plus, si le logiciel est rparti sur plusieurs machines, la stratgie de contrle
ne sera pas forcment la mme pour les parties du logiciel qui sexcutent sur des machines
diffrentes. UML nest daucune aide pour choisir la stratgie de contrle. En revanche, il est
194
UML 2
Chapitre
possible de dcrire les parties dun logiciel qui sexcutent sur des matriels laide des
diagrammes de dploiement (voir lannexe D).
Au dpart, le concepteur ne dispose que des modles issus de lanalyse, cest--dire des
diagrammes de classes, des tats-transitions, des squences, etc. Or, le passage des modles
de lanalyse au diagramme de dploiement est loin dtre immdiat. Le concepteur procde par tapes. Tout dabord, le systme (dans notre cas, un systme logiciel) est dcompos en sous-systmes. La partition du systme doit permettre de regrouper dans un soussystme des classes, des associations, des oprations, des vnements, etc., qui collaborent
aux mmes fonctionnalits, ou dont les contraintes techniques les destinent sexcuter
sur les mmes ressources. UML ne donne pas dindication sur les critres prendre en
compte pour partitionner un systme, mais permet simplement de reprsenter des soussystmes. Aprs que le systme a t dcompos en sous-systmes, les tapes suivantes
consistent :
reprer les objets qui sexcutent concurremment ;
allouer les sous-systmes des matriels ;
choisir sur quel(s) support(s) stocker les donnes (bases de donnes, fichiers, etc.) ;
identifier les ressources ncessaires (processeurs, disques, crans, claviers, etc.) ;
choisir une (ou plusieurs) stratgie(s) de contrle du logiciel (vnementielle, procdurale, etc.) ;
sassurer du bon fonctionnement du logiciel dans des conditions limites (comment
linitialiser, larrter, grer les erreurs, etc.).
Remarque
UML nest daucune utilit dans les quatre dernires tapes.
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 pistolet est dans son tui de rangement, et si lon appuie sur la gchette, lessence nest pas
pompe. La prise dessence est termine quand le client remet le pistolet dans son tui.
Il existe quatre types de carburants : diesel, sans plomb avec 98 comme indice doctane, sans
plomb avec 95 pour indice doctane, plomb.
Le paiement peut seffectuer en espces, par chque ou par carte bancaire. En fin de journe,
les transactions sont archives.
Les pompes ne peuvent tre armes que si le niveau des cuves dpasse 5 % de leurs capacits
maximales.
CONTEXTE
TECHNIQUE DU SYSTME
Le contexte technique du logiciel est impos (figure 6.3). Le logiciel doit sexcuter sur une
unit centrale laquelle sont relis :
des capteurs pour mesurer le niveau de carburant dans les cuves ;
des pompes qui puisent le carburant dans les cuves ;
le pupitre du pompiste (cran et clavier) ;
un systme cls en main de paiement par carte bancaire.
196
UML 2
Chapitre
Figure 6.3
Contexte technique
du logiciel (ce
diagramme nest
pas un diagramme
UML).
DIAGRAMME
Pupitre pompiste
Banque
Systme de paiement
par carte bancaire
Unit centrale
Cuves carburant
Pompe 1
Pompe n
Figure 6.4
Diagramme
de dploiement
des priphriques
du systme.
clavier
clavier du
pompiste
Priphrique
de gestion des
cuves
cran
cran du pompiste
unit centrale
Systme informatique de la station-service
disque
Base de donnes
Priphrique de
paiement par carte
bancaire
Priphrique
de gestion des
pompes
On suppose que les priphriques matriels (de gestion des cuves, des pompes et du terminal
de paiement) sont pilots par des composants existants. La figure 6.5 montre uniquement
les composants qui pilotent une pompe : les deux premiers permettent de connatre respectivement les tats des gchettes (appuyes ou relches) et des pistolets ; le troisime fournit
une interface (InterfacePompe) permettant darmer et dactiver la pompe.
Figure 6.5
Les composants qui
grent une pompe.
Gchette super
Gchette diesel
Gchette SP95
Gchette SP98
Pompe super
Pistolet super
Pompe diesel
Pistolet diesel
Pompe SP95
Pistolet SP95
Pistolet SP98
Pompe SP98
unit centrale
Systme informatique de la station-service
InterfaceCapteurGchette InterfaceCapteurPistolet
: Capteur
Gchette
: Capteur
Pistolet
: Pompe
InterfacePompe
interface
InterfacePompe
armer : boolen
dsarmer : boolen
activer : boolen
dsactiver : boolen
198
UML 2
Chapitre
MODLE
1.
2.
3.
4.
Client, transaction et archive nont pas encore t traits. Pour lapplication que nous
allons concevoir, un client est celui qui se sert de lessence : cest un concept clair et non
ambigu pour lapplication. Quen est-il du domaine de lapplication ? Quel concept du
mtier de la distribution de carburant voulons-nous cerner ? Le client prend de
lessence. Cest donc plus la prise dessence, lessence dlivre (la quantit, le type de carburant, etc.) qui nous intresse que le client en tant que tel. En ce qui concerne ce dernier,
nous voulons plutt savoir quel type de paiement il a effectu (en espces, par chque ou
par carte bancaire), et ventuellement, conserver le numro dimmatriculation de sa
voiture. Nous sommes donc en prsence de deux concepts distincts. Le premier, qui
correspond lessence dlivre, est modlis par une classe appele PriseDeCarburant.
La prise de carburant nenglobe pas le type de paiement. Elle est lie au dispositif de
pompage qui est au cur de notre domaine. Le type de paiement est li un client. Pour
la distribution dessence des particuliers, le paiement fait partie du domaine de lapplication. Rsumons cette notion par le mot-cl TransactionClient. Le dernier substantif que
nous navons pas encore abord est archive. Les transactions doivent tre archives quotidiennement. Pour quil ny ait pas dambigut, renommons lensemble des transactions
quotidiennes TransactionsDuJour.
La liste des classes candidates est prsent la suivante : Pistolet, Gchette, DispositifDePompage, EnsemblePompe, Etui, Carburant, Cuve, PriseDeCarburant, TransactionClient,
TransactionsDuJour.
Afin de dfinir clairement chaque terme, un dictionnaire a t rdig. Voici un extrait :
Essence distribue par la station-service. Le carburant peut tre de
plusieurs types (sans plomb 98, sans plomb 95, super et diesel).
Conteneur du carburant de la station-service. Il y a une cuve par
Cuve
type de carburant.
Remarque
Tous les termes lis au domaine ou lapplication doivent tre consigns dans des dictionnaires, mais pour des raisons de place, nous ne les avons pas tous reproduits.
2. Un premier diagramme de classes contenant des associations est prsent la figure 6.6.
Notre objectif premier est de modliser lorganisation des priphriques afin de les
contrler.
Le modle sarticule autour du dispositif de pompage. Cest la gchette qui contrle lactivation du dispositif de pompage. Do lassociation entre les classes Gchette et DispositifDePompage. Ce dispositif pompe le carburant dans une cuve ( noter que lassociation
de 1 vers plusieurs entre les classes Cuve et DispositifDePompage indique que plusieurs
pompes puisent le carburant dans une mme cuve).
200
UML 2
Chapitre
La gchette ne peut dclencher le pompage que si le pistolet qui la contient est dans son
tui. Cest ltat dun capteur qui indique si le pistolet est dans son tui ou pas. Pour
modliser cette information, nous tablissons une association ayant la multiplicit 0 ou 1
entre les classes Pistolet et Etui.
La prise de carburant relie les classes DispositifDePompage, Carburant et TransactionClient.
Figure 6.6
EnsemblePompe
Premire version
du diagramme de
classes du domaine.
1..*
Pistolet
Gchette
contrle
activation
Pompe
carburant
dans
DispositifDePompage
Cuve
1..*
contient
0..1
Etui
dbite
PriseDeCarburant
TransactionsDuJour
0..*
Carburant
1..*
TransactionClient
Figure 6.7
EnsemblePompe
Version du
diagramme de
classes du domaine
incluant les attributs.
numroPompe : entier
1..*
Gchette
Pistolet
dansEtui : boolen
niveau : entier
appuye : boolen
arm : boolen
actif : boolen
contient
dbite
PriseDeCarburant
1..*
quantitCarburant : rel
{ ordonnes par date}
TransactionsDuJour
archiver()
0..*
Carburant
prix : rel
typeCarburant : TypeCarburant
numration
TypeCarburant
TransactionClient
sansPlomb98
sansPlomb95
super
diesel
typePaiement : TypePaiement
date : Date
montant : rel
4. Les diffrents types de carburants peuvent tre modliss en crant des classes qui hritent
de la classe Carburant (figure 6.8).
Figure 6.8
Carburant
Modlisation des
types de carburants
par un hritage.
SansPlomb98
SansPlomb95
Diesel
Super
Cependant, nous avons utilis une numration la place de lhritage, car un hritage ne
se justifie que si au moins une classe drive possde un attribut, une association ou une
mthode spcifique, ce qui nest pas le cas ici. Le diagramme de classes de la figure 6.10
contient une numration appele TypeCarburant qui est utilise pour typer lattribut
typeCarburant de la classe Carburant.
Le client peut choisir parmi trois modes de paiement : par carte bancaire, en espces ou
par chque. Or, jusqu prsent, nous ne disposons, dans notre modle, que dune seule
classe pour grer le paiement : TransactionClient (figure 6.7). Le paiement par carte bancaire est particulier car la transaction doit tre valide auprs de la banque. Si le client
souhaite payer par chque, il doit donner au pompiste un identifiant, son numro de
carte didentit, par exemple. Ces particularits incitent transformer la classe TransactionClient en une classe de base dont hritent trois classes (figure 6.9) : TransactionEnEspces, TransactionBancaire et TransactionParChque. La classe TransactionClient est
abstraite car elle possde lopration abstraite payer. Celle-ci sera implmente dans les
202
UML 2
Chapitre
classes drives et permettra ainsi de particulariser le paiement. Lattribut identifiantClient a t ajout la classe TransactionParChque pour que celle-ci puisse conserver
lidentifiant dun client payant par chque.
Figure 6.9
TransactionClient {abstract}
Un hritage
pour modliser
les transactions.
date : Date
montant : rel
payer {abstract}
TransactionEnEspces
TransactionBancaire
TransactionParChque
identifiantClient : entier
payer
payer
payer
La technique de lhritage permet dtendre le domaine au plus grand nombre dapplications possibles. Or, il est rare aujourdhui quune station-service vende uniquement du
carburant. En observant le graphe dhritage de la figure 6.9, on saperoit que les transactions des clients peuvent sappliquer la vente de nimporte quel produit ou service. Ce
qui caractrise la vente de carburant, cest lassociation tablie entre les classes TransactionClient et PriseDeCarburant. Pour gnraliser la vente dautres services, une nouvelle
classe appele Service est cre (pour ne pas trop sortir du cadre de cette tude, la vente de
produits nest pas prise en compte). La prise de carburant devient alors un service, et la
classe PriseDeCarburant hrite de la classe Service (figure 6.10). Pour linstant, aucun
service supplmentaire na t ajout au modle, mais si, lavenir, un service dentretien
de vhicules venait tre cr, le graphe dhritage des services serait prt recevoir une
classe appele EntretienVhicule.
Pour tester en profondeur les chemins daccs aux classes, vous pouvez dfinir des requtes utilisant le langage OCL. Une autre technique consiste employer des diagrammes
dinteraction (de squence ou de communication) pour montrer comment des objets,
instances des classes, collaborent la ralisation des cas dutilisation. Mais avant dutiliser
les interactions, il faut avoir dvelopp le modle de lanalyse de lapplication. Ce que
nous ferons juste aprs avoir regroup les classes en paquetages et bti le modle des tats
du domaine.
5. la figure 6.10, deux ensembles de classes correspondant deux fonctionnalits de la
station-service apparaissent : un premier ensemble concerne la prise de carburant (il
regroupe les classes EnsemblePompe, Pistolet, Gchette, DispositifDePompage, Cuve,
Carburant, PriseDeCarburant et Service), et un deuxime a trait aux transactions (TransactionsDuJour, TransactionClient, TransactionEnEspces, TransactionBancaire, Transaction-ParChque, PriseDeCarburant et Service). Les classes lies la prise de carburant sont
regroupes dans un paquetage appel ServiceCarburant, tandis que les classes relatives
aux transactions sont incluses dans un paquetage appel Transactions (figure 6.11).
Figure 6.10
Diagramme de
classes du domaine.
contrle
activation
Pistolet
dansEtui : boolen
Gchette
DispositifDePompage
appuye : boolen
arm : boolen
actif : boolen
1..*
Cuve
niveau : entier
contient
1..*
Service
EnsemblePompe
numroPompe : entier
dbite
PriseDeCarburant
quantitCarburant : rel
Carburant
prix : rel
typeCarburant : TypeCarburant
0..*
TransactionClient {abstract}
Pistolet
numration
TypeCarburant
date : date
montant : rel
archiver()
sansPlomb98
sansPlomb95
super
diesel
payer {abstract}
TransactionEnEspces
TransactionBancaire
TransactionParChque
identifiantClient : entier
payer( )
Figure 6.11
payer( )
Transactions
payer( )
ServiceCarburant
Paquetages du
modle du domaine.
Remarque
Il faut essayer de limiter les dpendances entre paquetages car cela facilite la rutilisabilit
spare des paquetages dans dautres projets. Il y a dpendance entre deux paquetages
quand une association existe entre deux classes appartenant deux paquetages diffrents.
Si lassociation est bidirectionnelle, la dpendance lest aussi (figure 6.12).
Dans ce cas, il est peut-tre possible de limiter lassociation un seul sens (ce qui supprime
une des deux dpendances entre les paquetages).
Il ne faut pas oublier non plus que la dpendance entre deux paquetages dpend aussi du
nombre de messages qui circulent sur lassociation. Plus le nombre de messages est lev,
plus la dpendance est forte. Si ce nombre est trop important, il faut peut-tre revoir la rpartition des classes entre les paquetages afin que lassociation qui est en cause ne les relie plus.
204
UML 2
Chapitre
Figure 6.12
Double dpendance
entre paquetages.
Figure 6.13
Simple dpendance
entre paquetages.
MODLE
Figure 6.14
Diagramme des
tats-transitions
pour la classe
TransactionClient.
type paiement
choisi
paiement valid
valider paiement
archiv
archiver
annuler
Remarque
Le modle du domaine doit dpendre le moins possible des applications qui vont reposer
sur lui. Il faut donc essayer, quand on construit ce modle, de ne pas y faire inter venir des
considrations lies une application particulire. Il est donc important de commencer par
trouver les tats avant les vnements. Commencer par chercher les vnements conduit
rflchir la manire dutiliser un systme, ce qui revient imaginer une application par ticulire.
Intressons-nous prsent la deuxime classe qui engendre des objets ayant des tats complexes : la classe DispositifDePompage. quel moment des instances doivent-elles tre
cres ? Cest difficile dire en ltat actuel de lanalyse : en effet, le dispositif de pompage en
tant que priphrique matriel existe indpendamment du logiciel qui va le piloter, mais
quen est-il des instances de la classe DispositifDePompage ? Quand le client arrive pour
prendre de lessence, il a plusieurs pistolets (un par type de carburant) sa disposition.
Ds quil a pris un pistolet, le type de carburant quil dsire est connu. On sait donc dans
quelle cuve il faut puiser du carburant. Chaque cuve a des pompes particulires que notre
logiciel va devoir piloter. Le pilotage commence donc ds que le client dcroche un pistolet
(il faut alors armer le dispositif de pompage). Linstance ne doit pas forcment tre cre
ce moment-l car cela a peut-tre dj t fait auparavant. Comme nous ne pouvons pas le
savoir pour linstant, nous ne prcisons pas dans le diagramme suivant lvnement qui
instancie un dispositif de pompage.
Pour un dispositif de pompage, les tats possibles sont les suivants :
arm ou dsarm en fonction des actions du pompiste ;
bloqu ou dbloqu selon que le pistolet est rang ou non ;
actif ou inactif selon que lessence est en train dtre pompe ou non.
laide des tats et des vnements ci-dessus, on en dduit le diagramme dtats-transitions
de la figure 6.15. Notons que quand le client raccroche le pistolet, la pompe est automatiquement dsarme.
206
UML 2
Chapitre
Figure 6.15
arm
armer
dsarm
dcrocher pistolet
bloqu
dbloqu
pression
gchette
raccrocher pistolet
inactif
dpression
gchette
actif
Analyse de lapplication
Lanalyse de lapplication commence par ltude des cas dutilisation. Ce modle reprsente le
systme informatique de la station-service vu par les acteurs. Il est construit indpendamment du modle du domaine de lapplication. Par la suite, ces deux modles seront confronts
pour vrifier que les classes du domaine permettent de raliser les cas dutilisation. Lanalyse
complte de lapplication se fait en btissant trois modles :
le modle des interactions de lapplication ;
le modle des classes de lapplication ;
le modle des tats de lapplication.
La phase danalyse se conclut par lajout doprations aux classes.
MODLE
1. Dterminez les limites du systme. Trouvez les acteurs. Trouvez les cas dutilisation.
Construisez le diagramme de cas dutilisation.
2. Prparez les scnarios pour dcrire les cas. Ajoutez des squences alternatives et des
squences dexceptions aux scnarios. Prparez des diagrammes dactivit pour des cas
dutilisation complexes.
3. Vrifiez la cohrence entre le modle des classes du domaine et celui de lapplication.
1. Les quatre premires questions ont t traites dans la partie exercices du chapitre 1. Vous
y trouverez des explications sur la dmarche qui a permis daboutir au diagramme prsent la figure 6.16.
Figure 6.16
Diagramme de cas
dutilisation de la
station-service.
Station Service
inclut
Client
inclut
Se servir
Armer pompe
Points dextension :
paiement : { la fin du
cas se servir }
Pompiste
tend
Payer
Payer
en espces
Archiver les
transactions
Payer
par chque
2. Les cas dutilisation doivent tre dcrits sous forme textuelle comme indiqu au chapitre 1.
Certains peuvent tre dcrits laide de diagrammes de squence ou par des diagrammes
dactivit. Pour chaque cas, il faut dfinir une squence nominale ainsi que des squences
alternatives et dexceptions. Pour des raisons de place, la description textuelle des cas et
les squences alternatives et dexceptions ne sont pas prsentes.
Un cas dutilisation est dclench quand un vnement survient. Le dictionnaire suivant
liste les vnements qui initient les cas dutilisation. Comme nous lavons vu au chapitre
1, les vnements peuvent tre classs en trois catgories :
les vnements externes ;
les vnements temporels ;
les vnements dtats.
208
UML 2
Chapitre
vnement temporel qui dclenche le cas Archiver les transactions . Cest aussi un vnement externe car le temps est
considr comme un acteur : acteur Timer.
vnement externe produit par lacteur Pompiste qui dclenche
un des trois cas particuliers de paiement : Payer par carte
bancaire , Payer en espces et Payer par chque .
vnement externe produit lacteur Client qui dclenche le cas
Se servir .
vnement externe produit par lacteur Pompiste qui dclenche
le cas Armer Pompe .
vnement dtat, car produit lors du droulement du cas
Se servir , qui dclenche le cas Vrifier niveau cuve pour
armement .
vnement externe produit par lacteur Capteur niveau cuve
pour remplissage qui dclenche le cas Vrifier niveau cuve
pour remplissage .
vnement externe produit par lacteur Pompiste qui dclenche
le cas payer .
On remarque sur le diagramme de la figure 6.16 que le paiement intervient aprs que le
client a pris de lessence. En situation relle, il faudrait sinquiter de lvolutivit de notre
application et considrer le cas o le paiement interviendrait avant. Il faudrait aussi offrir
la possibilit au client de payer lui-mme, directement avec une carte de crdit dans le terminal de la pompe, sans lintervention du pompiste. La figure 6.17 montre comment le
diagramme de cas dutilisation peut tre transform pour que le paiement puisse intervenir
avant que le client prenne de lessence. Dans la suite de cette tude de cas, nous revenons
la situation initiale (cas o le client paye aprs avoir pris du carburant).
Figure 6.17
Points dextension
qui prcisent
quand le paiement
intervient.
Se servir
Points dextension :
- paiementAvant
- paiementAprs
Client
Point dextension : paiementAvant
(le paiement se fait avant de se
servir)
tend
Payer
Payer en espces
Scnario nominal pour Se servir du carburant. La figure 6.18 tablit le scnario nominal
du cas dutilisation Se servir du carburant. noter la boucle qui indique que le client
peut appuyer et relcher plusieurs fois la gchette avant de reposer le pistolet. Il est galement fait rfrence un diagramme appel ArmerPompe. On indique ainsi que larmement
est inclus dans la prise dessence.
Figure 6.18
sd Se servir
Scnario nominal
du cas Se servir .
: Station-service
Client
Dcrochage dun pistolet
ref
ArmerPompe
loop
[ pistolet hors tui ]
Appui sur la gchette
Affiche quantit essence + montant
Relchement de la gchette
Raccrochage du pistolet
Dsarmer
pompe
La figure 6.19 donne le scnario nominal pour le cas Armer Pompe . La vrification du
niveau des cuves pour larmement y est incluse. De plus, on vrifie que plusieurs pistolets
nont pas t dcrochs.
210
UML 2
Chapitre
Figure 6.19
Scnario nominal
du cas Armer
pompe .
sd ArmerPompe
: Station service
Pompiste
ref
VrifierNiveauCuvePourArmement
Le scnario nominal pour le cas Vrifier niveau cuve pour armement est donn la
figure 6.20.
Figure 6.20
Scnario nominal
du cas Vrifier
niveau cuve pour
armement .
sd VrifierNiveauCuvePourArmement
: Station service
Capteur niveau
pour armement
Demande niveau dans cuve pour armement
Remarque
Le diagramme de cas dutilisation dtaille de manire trs prcise les fonctions de la station-service (on y voit larmement ainsi que la vrification du niveau des cuves). Il eut t
possible de dcrire le systme plus sommairement comme le montre la figure 6.21. Malgr
ce changement dchelle, le scnario pour se servir de lessence ne change pas. La figure
6.22 le reproduit. On y retrouve superposes les figures 6.18, 6.19 et 6.20, qui reprsentent la station-service, avec plus de dtails. Ceci dnote limportance tout relative des
relations dinclusion, dextension et de gnralisation qui peuvent agrmenter un diagramme
de cas dutilisation. Dailleurs, certains modlisateurs ignorent dans un premier temps les
relations entre les cas, et tablissent dabord les scnarios.
Figure 6.21
Diagramme de
cas dutilisation
montrant moins
de dtails.
Station Service
Vrifier niveau cuve
pour remplissage
Se servir
Points dextension :
paiement : { la fin du cas
se servir }
Client
Condition : {si le client a pris
de lessence avant de raccrocher
le pistolet}
Point dextension : paiement
Pompiste
tend
Payer
Payer en espces
Archiver les
transactions
Payer
par chque
212
UML 2
Chapitre
Figure 6.22
Scnario nominal
des cas Se servir ,
Armer pompe
et Vrifier
niveau cuve pour
armement .
: Station service
Client
Pompiste
Capteur niveau
pour armement
sd ArmerPompe
sd VrifierNiveauCuvePourArmement
Demande niveau dans cuve pour armement
Relchement de la gchette
Raccrochage du pistolet
Dsarmer pompe
Figure 6.23
Scnario nominal
pour le cas
payer .
sd payer
: Station-service
Pompiste
encaissement (pompe, typeCarburant)
Affiche montant payer
Choix du mode de paiement
ref
TransactionClient.payer
3. La vrification doit tre minutieuse : il sagit dtudier attentivement tous les scnarios en
vrifiant si les classes possdent tous les attributs et les chemins (les associations) ncessaires pour y accder. La vrification tant fastidieuse, elle na pas t reproduite ici.
MODLE
214
UML 2
Chapitre
non enfonc (pompe dsarme) ;
enfonc (pompe arme) ;
rouge (armement impossible) ;
clignotant (fin de prise de carburant).
Figure 6.24
cran principal
du terminal du
pompiste.
Pompe 1
Pompe n
SansPlomb98
SansPlomb98
SansPlomb95
SansPlomb95
Diesel
Diesel
Super
Super
Figure 6.25
cran du terminal
du pompiste tel quil
apparat au moment
du paiement.
Pompe 1
Pompe n
SansPlomb98
Carte bancaire
SansPlomb95
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
priphriques de
gestion des cuves.
unit centrale
Systme informatique de la station
service
niveau
Priphrique de
gestion des cuves
: PiloteGestionCuve
InterfaceCuve
La figure 6.27 dtaille linterface InterfaceCuve et montre que la classe Cuve extraite du
diagramme de classes de la figure 6.10 est cliente de cette interface.
Figure 6.27
La classe Cuve
comme classe
cliente de linterface
InterfaceCuve.
interface
InterfaceCuve
getNiveau : entier
Cuve
niveau : entier
3. En plus des classes qui se trouvent la priphrie dun systme et celles qui grent linterface homme-machine, un logiciel est constitu dobjets qui le contrlent. Chaque objet
contrleur est ddi une fonction particulire. Dans notre cas, il sagit de trois fonctions bien distinctes : la prise dessence, le paiement et larchivage des transactions.
Pour commencer, tentons dimaginer un objet qui puisse contrler la prise dessence.
Session de prise dessence. Ds quun client dcroche un pistolet, des instances des
classes Pistolet, Gchette et DispositifDePompage sont prtes activer le priphrique
matriel qui pompe lessence. Les tats des instances vont changer en fonction des actions
des clients qui sont perues par le systme au travers de capteurs. Si N clients prennent du
carburant simultanment, il y aura N ensembles dinstances de Pistolet, de Gchette et de
216
UML 2
Chapitre
DispositifDePompage. Pour contrler ces trois instances, nous crons une classe appele
SessionDePriseDeCarburant.
Le diagramme des objets prsent la figure 6.28 montre deux clients qui se servent du
super 98 simultanment, chacun ayant sa propre session.
Figure 6.28
Diagramme dobjets
qui montre deux
sessions de prise
dessence.
client1
session1
EnsemblePompe1
pistolet1
gchette1
pompe1 : DispositifDePompage
numro : entier = 1
priseDeCarburant1
carburant
Cuve
typeCarburant : TypeCarburant = sansPlomb98
priseDeCarburant2
EnsemblePompe2
pistolet2
gchette2
pompe2 : DispositifDePompage
numro : entier = 2
session2
client2
Pour illustrer comment la session dun client interagit avec les instances des classes Pistolet,
Gchette et DispositifDePompage, on dfinit une collaboration (figure 6.29).
Figure 6.29
Une collaboration
qui permet de
montrer le
droulement
dune session de
prise dessence.
La SessionDePriseDeCarburant
: Pistolet
: Gchette
: DispositifDePompage
: Cuve
: SessionDePriseDeCarburant
Cette collaboration est dcrite plus en dtail la figure 6.30. Elle dbute par la cration
dune session pour un client (instance de la classe SessionDePriseDeCarburant). Ensuite, des
instances des classes Pistolet, Gchette et Pompe sont cres leur tour. Cest l un parti pris.
Nous avons en effet dcid que ces instances nexistaient pas avant que le client dcroche un
pistolet. Une autre solution aurait consist disposer dun pool dobjets prts lemploi
dans lequel on aurait pris volont des instances. Ce choix relve plutt de la conception
que de lanalyse. Considrons-le comme un scnario de conception possible. La figure 6.30
montre que les instances du pistolet et de la gchette sont dtruites ds que le client raccroche le pistolet. Deux autres diagrammes servant illustrer larmement de la pompe et la
prise du carburant sont rfrencs.
Figure 6.30
Interaction
qui illustre la
collaboration
de la figure 6.29.
sd SessionDePriseDeCarburant
client : Client
Dcrochage dun pistolet
pompiste : Pompiste
session : SessionDePriseDeCarburant
pompe : DispositifDePompage
: Pistolet
gchette : Gchette
Affiche numro de pompe + type essence pris
ref
ArmementPompe( client, pompiste, session, pompe )
ref
ActivationPompe( client, session, gchette, pompe )
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 sollicit implicitement par linstance de la cuve.
218
UML 2
Chapitre
Figure 6.31
Interaction qui
illustre larmement
de la pompe.
+autrePistolet : boolen
pompe : DispositifDePompage
session : SessionDePriseDeCarburant
client : Client
pompiste : Pompiste
cuve : Cuve
ref
autrePistolet = TestAutrePistoletPris
opt
[ autrePistolet == false ]
Demande
Armement
Demande niveau dans
cuve pour armement
Niveau dans cuve
pour armement OK
armer
armement
OK
La figure 6.31 fait rfrence au diagramme TestAutrePistoletPris qui nest pas reprsent (il
sagit simplement de demander linstance de lEnsemblePompe de vrifier laide dune
boucle quil ny a pas plusieurs pistolets dcrochs).
Le diagramme reproduit la figure 6.32 dtaille linteraction ActivationPompe qui est rfrence la figure 6.30.
Figure 6.32
Interaction qui
illustre lactivation
de la pompe.
sd ActivationPompe( inout client : Client, inout session : SessionDePriseDeCarburant, inout gchette : Gchette, inout pompe :
DispositifDePompage )
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.
: PriseDeCarburant
: TransactionBancaire
: TransactionsDuJour
session : SessionDePaiement
220
UML 2
Chapitre
Figure 6.34
Interaction qui
illustre comment le
paiement est ralis
durant la session
de paiement.
: TransactionsDuJour
pompiste : Pompiste
Banque
encaissement( pompe, typeCarburant )
: SessionDePriseDeCarburant
session : SessionDePaiement
demande la quantit pompe
quantit
Calcul du Montant
Afficher montant payer
Choix du mode de paiement
opt
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 transactions . 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, GestionnaireDesArchivages. Une seule instance de cette classe est ncessaire pour faire fonctionner
larchivage. Lobjet correspondant est actif une fois par jour ( minuit). Il demande larchivage des transactions du jour ; aprs quoi linstance de la classe TransactionsDuJour est
dtruite pour tre recre aussitt (et initialiser ainsi une nouvelle journe de transactions).
Figure 6.35
Diagramme qui
illustre comment le
gestionnaire des
archivages ralise
la sauvegarde
quotidienne des
transactions.
: TransactionsDuJour
: GestionnaireDesArchivages
Timer
loop
systme
: TransactionsDuJour
MODLE
AJOUT
DES OPRATIONS
La phase danalyse de notre logiciel est prsent presque acheve. Il reste ajouter des
oprations aux classes. Les oprations peuvent tre dduites des cas dutilisation et
des scnarios.
Considrons nouveau le diagramme de la figure 6.31 (o le test sur le nombre de pistolets
dcrochs a t omis). Rcrivons les messages destins aux objets en respectant la syntaxe
des messages utiliss dans les diagrammes de squence (voir chapitre 3).
222
UML 2
Chapitre
Figure 6.36
sd ArmementPompe (inout client : Client, inout pompiste : Pompiste, inout session : SessionDePriseDeCarbutant,
inout pompe : DispositifDePompage)
Les messages
destins aux objets
mis la norme
des diagrammes
de squence.
pompe : DispositifDePompage
session : SessionDePriseDeCarburant
client : Client
pompiste : Pompiste
cuve : Cuve
armementPompe
armement
niveauSuffisantPourArmement
niveauSuffisantPourArmement : vrai
armer
armement : vrai
RAZ compteur volume
et montant + prix du litre
Affiche confirmation armement
Chaque message destin un objet devient une opration pour la classe correspondante. La
classe Cuve par exemple contient prsent lopration niveauSuffisantPourArmement() :
boolen comme le montre la figure 6.37.
Figure 6.37
Ajout dune opration
la classe Cuve.
Cuve
niveau : entier
niveauSuffisantPourArmement() : boolen
Procder ainsi systmatiquement pour tous les diagrammes dinteraction produits permet
dajouter des oprations aux classes. La figure 6.38 montre des classes qui concernent la
prise de carburant auxquelles ont t ajoutes des oprations.
Figure 6.38
SessionDePriseDeCarburant
Quelques classes
du domaine avec
leurs oprations.
demandeArmementPompe : boolen
dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant )
raccrochagePistolet
appuiGchette
relachementGchette
Gchette
appuye : boolen
appuyer
relcher
PriseDeCarburant
quantitCarburant : rel
DispositifDePompage
arm : boolen
actif : boolen
armement : boolen
armer : boolen
dsarmer : boolen
activer : boolen
dsactiver : boolen
getQuantitCarburant : rel
Phase de conception
La phase danalyse est prsent termine. Ltude a permis de prciser ltendue des besoins
auquel doit rpondre le logiciel de gestion dune station-service, mais aussi spcifier et
comprendre ce quil doit faire. Dans la phase suivante, la conception, il sagit de dcider
comment raliser ce logiciel. Cette phase passe par de nombreuses tapes o UML nest pas
utile (le choix des ressources ncessaires pour excuter le logiciel par exemple). Dans la suite
de ce chapitre, nous nous intressons aux seules tapes o UML est utile.
CONCEPTION
DU SYSTME
224
UML 2
Chapitre
La logique mtier est compose des classes du domaine (reprsentes ici par les paquetages qui les contiennent).
La gestion des priphriques (capteurs de niveau des cuves, gestion des pompes et du
terminal de paiement) est incluse dans la couche de services.
noter la relation de dpendance qui existe entre la couche applicative et la couche de services : elle indique que larchivage dans la base de donnes (non reprsente) est directement gr par le gestionnaire de la persistance (GestionnairePersistance) sans passer par la
couche mtier.
Figure 6.39
Architecture du
logiciel de gestion
de la station-service.
layer
Prsentation
layer
Logique applicative
________________________
+SessionDePriseDeCarburant
+SessionDePaiement
+ GestionnaireDesArchivages
layer
Logique mtier
ServiceCarburant
Transactions
layer
Services
______________________
+PiloteGestionCuve
+Pompe
+PiloteGestionPaiement
+GestionPersistance
Le systme a donc t dcoup en couches horizontales. Lapplication, essentiellement contenue dans la couche applicative, permet, grce aux classes contrleurs, de raliser les cas
dutilisation. Sans ses classes contrleurs, couche applicative et couche mtier seraient
mlanges tel point que la rutilisabilit des classes de la couche mtier serait compromise.
La sparation entre logique applicative et logique mtier permettra une autre application
de rutiliser les classes du domaine.
Augmenter la rutilisabilit par partie du logiciel. Le dcoupage en couches prcdent a
permis disoler la partie mtier (les classes du domaine) afin de ne pas lencombrer avec les
dtails de lapplication. Une autre partition du logiciel est possible par fonctionnalits.
Dailleurs, bien souvent, ces deux types de dcoupage sont raliss simultanment.
Une partition fonctionnelle a dj t ralise quand nous avons spar les classes du
domaine en deux paquetages (figure 6.11). Il est possible disoler les paquetages en les plaant dans un classeur structur (voir lannexe B). La figure 6.40 prsente un classeur structur qui contient le paquetage ServiceCarburant.
Figure 6.40
PriseCarburant
Structure interne
du classeur structur
PriseCarburant.
ServiceCarburant
Le classeur PriseCarburant interagit avec son environnement via des ports (figure 6.41).
Certains reoivent ltat des capteurs pistolet et gchette, dautres servent dinterface avec le
pompiste ou avec le moteur de la pompe, dautres encore servent rcuprer la quantit
dessence pompe.
Figure 6.41
InterfacePompiste
Ports du classeur
PriseCarburant.
Entre tat
capteur pistolet
Sortie
commandes
pompe
InterfacePistolet
PriseCarburant
InterfaceGchette
Entre tat
capteur
gchette
InterfaceDbitmtre
226
UML 2
Chapitre
Ces interfaces ont t labores partir des classes contenues dans le paquetage du classeur
structur. Par exemple, la classe SessionDePriseDeCarburant contient une opration destine au pompiste, deux oprations qui servent dinterface avec le pistolet, et deux oprations
qui sont relies la gchette.
Figure 6.42
Sparation
des oprations
de la classe
SessionDePriseDe
Carburant pour
prparer les
interfaces.
SessionDePriseDeCarburant
demandeArmementPompe : boolen
dcrochagePistolet( numroPompe : entier, typeCarburant : TypeCarburant )
raccrochagePistolet
appuiGchette
relachementGchette
On retrouve ces trois ensembles doprations dans les trois interfaces : InterfacePompiste,
InterfacePistolet et InterfaceGchette (figure 6.43). Ainsi, une seule classe interne un classeur structur peut tre accessible via plusieurs interfaces.
Figure 6.43
interface
InterfacePistolet
interface
InterfaceGchette
interface
InterfaceDbitmtre
appuiGchette
relachementGchette
getQuantitPompe : rel
interface
InterfacePompiste
demandeArmementPompe() : boolen
getNumeroPompe() : entier
getTypeCarburant() : TypeCarburant
priseCarburantTermine
La figure 6.44 montre comment le classeur structur PriseCarburant interagit avec son environnement quand un client appuie sur une gchette. Cette information est transmise au
composant CapteurGchette, puis circule via linterface InterfaceGchette jusquau classeur
structur PriseCarburant. Ce classeur est alors considr comme une bote noire (le composant CapteurGchette na pas accs sa structure interne). Il adopte un certain comportement qui engendre ventuellement une commande sur son port de sortie. Cette commande
est rpercute jusquau moteur de la pompe en passant par le composant Pompe qui implmente linterface InterfacePompe (figure 6.45).
Figure 6.44
Gchette
Cheminement dune
information depuis
lappui sur une
gchette jusqu
la commande du
moteur de la pompe.
InterfaceCapteurGchette
: CapteurGchette
unit centrale
Systme informatique de la station
service
Entre tat
capteur
gchette
PriseCarburant
: Pompe
Sortie
commandes
pompe
InterfacePompe
InterfaceGchette
Figure 6.45
Vue dtaille de
linterface qui
contrle le moteur
de la pompe.
interface
InterfacePompe
armer : boolen
dsarmer : boolen
activer : boolen
dsactiver : boolen
Le classeur PriseCarburant doit parfaitement sinsrer dans lapplication. Pour le vrifier, les
scnarios issus de lanalyse de lapplication peuvent tre repris afin de montrer comment le
classeur interagit avec son environnement.
Utiliser un classeur structur muni de ports permet disoler la structure interne du classeur
de son environnement. Le but tant de pouvoir facilement rutiliser ce classeur dans un
environnement qui se conforme aux interactions imposes par ses ports. Le dcoupage
opr avec le classeur PriseCarburant pourrait tre reproduit pour la gestion des transactions. Le systme informatique de la station-service ainsi dcoup gagne en modularit.
Chaque sous-systme, qui est isol dans un classeur structur, peut tre facilement extrait
du contexte de lapplication courante et utilis dans une autre application.
228
UML 2
Chapitre
Figure 6.46
Classeur structur
dont le comportement
est dcrit par une
interaction.
PriseCarburant
ref
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 peuvent recevoir des vnements en mme temps sans interagir. Si les vnements ne sont
pas synchroniss, ces objets ne peuvent pas tre traits dans le mme thread de contrle.
Dans notre cas, les vnements qui concernent la prise de carburant par un client ainsi
que le paiement sont squentiels. En revanche, chaque client doit avoir sa propre session
de prise de carburant et de paiement. Les instances des classes SessionDePriseDeCarburant
et SessionDePaiement sexcutent toutes en parallle sans interagir, sauf au moment
de larchivage des transactions. Larchivage est sous le contrle dun objet du type
GestionnaireDesArchivages (figure 6.35). Que se passe-t-il alors si un client paye aprs
stre servi de lessence minuit, au moment o larchivage se dclenche ? Larchivage
utilise une instance des TransactionsDuJour (figure 6.35) et cette mme instance peut tre
utilise concurremment par une session de paiement pour y ajouter la transaction dun
client (figure 6.34). Le diagramme de la figure 6.47 utilise loprateur dinteraction par
pour montrer que le gestionnaire des archivages et la session client peuvent accder
concurremment linstance de TransactionsDuJour (le deuxime oprande est extrait de
linteraction de la figure 6.34, o seul le message Ajouter la transaction client est pris
en considration). Pour que la session de paiement ne vienne pas perturber larchivage,
cette fonction est ralise dans une section critique grce loprateur dinteraction
ritical (voir chapitre 3).
Figure 6.47
Concurrence daccs
sur linstance des
transactions du jour.
: TransactionsDuJour
: SessionDePaiement
: GestionnaireDesArchivages
Timer
par consider{ archiver, il est minuit lhorloge systme, ajouter la transaction client }
critical
archiver
Il est minuit
lhorloge systme
: TransactionsDuJour
critical
Ajouter la transaction client
230
UML 2
Chapitre
Figure 6.48
Diagramme de
squence pour
larchivage
de transactions.
: TransactionsDuJour
: TransactionBancaire
session : SessionDePaiement
Pompiste
Valide la transaction
Valider transaction
Ajouter la transaction client
Indications : on suppose que les transactions du jour sont structures en tableau, et que les
transactions y sont tries par ordre croissant de leur montant en euros.
Figure 6.49
Diagramme de
squence pour
larchivage de
transactions.
t1 : TransactionClient
t2 : TransactionClient
tn : TransactionClient
10 euros
12,3 euros
47 euros
Lalgorithme utilis pour ajouter une nouvelle transaction consiste parcourir le tableau
la recherche de lemplacement o ajouter la transaction, puis faire de la place pour la
nouvelle transaction en dcalant les transactions existantes.
Lalgorithme propos correspond un tri par insertion, dont une modlisation est propose
la question 3 de lexercice 3 du chapitre 5. La seule contrainte impose par lactivit tri
insertion est que le type contenu dans le tableau pass en argument ralise linterface Comparable. Il suffit donc dcrire un comparateur entre deux transactions qui corresponde
lordre propos : t1 < t2 quivalent t1.montant < t2.montant. Cela peut simplmenter
directement comme un oprateur en C++, ou comme une mthode en Java.
Annexe A
234
UML 2
Compagnie : IBM/Rational
Produit : Rational Rose Enterprise
Licence acadmique : complte sous programme IBM Academic Initiative ngociable
par les enseignants.
Licence commerciale : 5 000 10 000
IDE : Standalone, intgration partielle dans Visual Studio 2005
Langages : Visual C ++, Visual Basic 6, Ansi C ++, SQL, Java (1.4)
Description : Rose a t le premier outil de modlisation UML, au dbut des annes 2000.
Il na pas t mis jour pour supporter UML 2, il reste cependant un outil trs agrable
manipuler, et il supporte bien linteraction avec les technologies Microsoft, ainsi quavec
les bases de donnes. noter quil existe galement un produit IBM offrant du support
pour C#, mais qui nest pas inclus dans Rose.
+ Ergonomie bien travaille.
+ Importation de projets Visual.
Ne supporte pas UML 2.
Compagnie : IBM/Rational
Produit : Rational Software Architect
Licence acadmique : complte sous programme IBM Academic Initiative ngociable
par les enseignants.
Licence commerciale : 4 000 12 000
IDE : bas sur Eclipse
Langages : Java, C ++, Corba
Description : un outil norme, par sa taille (6 Go disque, 1 Go RAM), mais aussi par ses
capacits plus avances que la concurrence. Construit sur Eclipse, supporte bien tout
UML 2. Notons que loffre de IBM/Rational se dcline en plusieurs variantes, ce produit
constitue leur haut de gamme.
+ Modlisation trs avance, bon support des diagrammes de squence, machines tat.
+ Services de gnration de code/extraction de modle.
Lourdeur de loutil, ncessite une grosse configuration pour tourner correctement.
Compagnie : Microsoft
Produit : Visio
Licence acadmique : inclus dans le lot Microsoft MSDN Academic Alliance
Licence commerciale : 360 780
IDE : Visual Studio (menu Visio)
Langages : (partiel) C#, VB. Net
Description : Visio est dabord un outil de dessin puissant, permettant de produire assez
facilement des diagrammes techniques de bonne qualit graphique. Une palette contenant les lments des diagrammes UML est incluse avec loutil. Visual Studio offre galement une option permettant de produire des diagrammes de classe sous Visio partir
dun projet, mais cela reste relativement limit. Certaines des illustrations de ce livre sont
ralises laide de Visio.
+ Logiciel de dessin au rendu graphique agrable.
Pas rellement un outil UML.
Compagnie : No magic
Produit : MagicDraw UML
Licence acadmique : version bride ldition de diagrammes disponible par ngociation
des enseignants
Licence commerciale : 400 2 150
IDE : Eclipse, NetBeans, JBuilder
Langages : Java, C ++, C# (partiel)
Description : un outil assez plaisant visuellement, et dune ergonomie globalement bonne.
MagicDraw offre un certain nombre de services de transformation de modles et de dfinition de profils. Linteraction avec le Java est assez bonne (cration de diagrammes de
squence depuis le code), les fonctionnalits pour le C ++ et C# sont beaucoup plus limites.
+ Un outil honnte, au rendu graphique et lergonomie au dessus de la moyenne.
La version offerte aux enseignants ne permet que le dessin.
Compagnie : Omondo
Produit : EclipseUML
Licence acadmique : version Free edition , quelques fonctionnalits brides
Licence commerciale : version Studio 2 500 7 100
IDE : Intgration Eclipse
Langages : Java, J2EE
Description : un des premiers plugins UML pour Eclipse, bas sur les standards open-source.
Spcialement ddi au Java, offre une bonne synchronisation code/diagrammes de classe.
Les autres diagrammes sont cependant dans lensemble plutt dlaisss, mme si un diteur
graphique sommaire est fourni pour chaque type de diagramme. Permet davoir une visualisation UML du code du projet dans les phases de conception dtaille et dimplmentation.
+ Synchronisation avec le code Java (jdk < = 1.6), intgration dans Eclipse.
+ Facile tlcharger et installer.
Supporte surtout les diagrammes de classe.
Compagnie : Visual-Paradigm
Produit : Visual-Paradigm for UML
Licence acadmique : Programme Academic Partners, version standard gratuite ngociable
par les enseignants
Licence commerciale : 400 1 200
IDE : intgration dans la majorit des IDE, effort particulier pour Eclipse
Langages : Java, C ++, PHP, SQL-JDBC, Ada, Python Support partiel dautres langages
Description : un outil assez agrable visuellement et ergonomique pour ldition de diagrammes. La version standard offerte aux enseignants inclut suffisamment de fonctionnalits pour tre vraiment utilisable, une version logiciel de dessin UML gratuite est
disponible. Les diffrents diagrammes sont faciles construire. Beaucoup de fonctionnalits sont proposes pour interagir avec les bases de donnes.
+ Interface ergonomique.
+ Bon support pour une large palette de langages.
Documentation proche de la publicit, difficile parfois de trouver linformation
pertinente.
236
UML 2
Annexe B
Classeurs structurs
Les classes dcouvertes au moment de lanalyse (celles qui figurent dans le diagramme de
classes) ne sont pas assez dtailles pour pouvoir tre implmentes par des dveloppeurs.
Lanalyse montre ce que doit faire un systme mais pas comment il doit tre ralis. Cest le
rle des concepteurs de faire des choix de ralisation. Une technique de conception consiste
dcomposer un systme jusqu ce quapparaissent des niveaux de dtails suffisamment
fins pour permettre limplmentation. UML propose de partir des classeurs dcouverts au
moment de lanalyse tels que les classes, les sous-systmes, les cas dutilisation, , et de
les dcomposer. Les classeurs ainsi dcomposs sappellent des classeurs structurs. Ils se
prsentent comme des classes qui montrent leurs structures internes. Un classeur structur
est constitu de plusieurs parties relies par des connecteurs. La figure B.1 illustre une commande de billets de spectacle par un client via un classeur structur.
Figure B.1
rle
type
commandeBillet
client : Personne
partie
1..*
billetCommand : Billet
connecteur multiplicit
Chaque classeur est constitu de parties spcifiques : une partie ne peut pas figurer dans
deux classeurs. Cette condition permet de dcomposer un classeur sur plusieurs niveaux.
Dfinition
Une partie est un fragment dun classeur structur.
Notation
Comme un classeur, une partie est reprsente par un rectangle contenant une tiquette
dont la syntaxe est :
<nomDuRle> [: <nomDuType> multiplicit ]
Tandis que les parties dun classeur structur reprsentent une structure de donnes, les
rles correspondent ses diffrents comportements et permettent de dfinir le contexte
dans lequel il est utilis.
Un classeur interagit avec son environnement via des ports (voir chapitre 2) par o passent
des messages. La figure B.2 illustre lutilisation des ports dans une classe structure.
Figure B.2
Une classe structure
avec des ports.
signal
audio
entre niveau ligne
Carte son
niveau sonore
ports
interface requise
Annexe C
Composants
Un composant est une unit autonome au sein dun systme ou sous-systme. Cest un
classeur structur particulier, muni dune ou plusieurs interfaces requises ou offertes, possiblement travers des ports explicitement reprsents. Son comportement interne est
totalement masqu de lextrieur, seule ses interfaces mergent du composant. Le modle
de composants favorise la rutilisation en fournissant un grain plus grossier que celui des
classes, qui permet davoir des entits rellement autonomes.
Le programmation par composants constitue une volution technologiques en matire
de programmation, soutenue par de nombreuses plateformes (composants EJB, CORBA,
COM+ ou .Net, WSDL). Laccent est sur la rutilisation du composant, et son volution
de faon indpendante des applications qui lutilisent. Un composant peut tre dploy
dans diverses configurations, selon ses connexions avec les autres lments du systme. Au
contraire, une classe est lie de faon fige au systme dont elle fait partie, les associations
avec les autres classes reprsentant des liens structurels. En ce sens, sans perdre la gnralit
dun classeur, un composant est plus proche dune instance de classe que dune classe, et
les diagrammes de composants sapparentent plus des diagrammes des objets qu des
diagrammes de classe.
Un composant est reprsent laide dun rectangle comme un classeur ordinaire, muni du
mot-cl component , et optionnellement dun graphisme particulier (figure C.1) plac
dans un angle.
238
UML 2
Figure C.1
Un composant
avec une interface
requise et une
interface offerte.
component
Persistence
Persistance
BaseDeDonnes
component
Persistance
provided interface
Persistance
crer
stocker
charger
required inteface
BasesDeDonnes
JDBC
Les composants sont raliss par des ensembles de classeurs, qui implmentent le comportement dclar par les interfaces du composant. Un composant peut tre ralis de diffrentes
manires, sans affecter ses interfaces. La seule contrainte pour pouvoir substituer un composant un autre est de prserver les interfaces requises et offertes. La faon dont un
composant est ralis peut tre dfinie plusieurs niveau de dtail.
Un composant peut tre vu comme une bote noire. On ne fait alors merger que ses interfaces et lon utilise une des prsentations de la figure C.1.
On peut galement dcrire la structure interne du composant en bote blanche. On expose
ainsi la faon dont le composant est ralis, avec une reprsentation proche de celle dun
claseur structur. On connecte alors les ports externes du composant aux ports des classeurs
constituant ses parties, par un arc qui reprsente une relation de dlgation (figure C.2) : les
messages qui arrivent sur ce port sont directement transmis au composant interne. Cette
vision hirarchique permet de dcomposer un systme en sous systmes relativement indpendants, et donc plus rutilisables. Les interfaces requises et offertes sont connectes entre
elles pour exprimer lassemblage des parties ralisant le composant.
Figure C.2
La ralisation dun
composant expose
en bote blanche.
component
Persistance
Persistance delegate
delegate
BaseDeDonnes
CollectionPersistante
delegate
AnalyseurDeClasse
PersistanceTypeDeBase
Composants 239
Annexe D
Diagramme
de dploiement
UML nest pas limit la production de modles utiles aux phases danalyse et de conception.
Le dploiement qui prcde la mise en production constitue une tape importante du dveloppement dun systme. Au final, ce dernier va sexcuter sur des ressources matrielles
(processeurs, mmoire, etc.) dans un environnement particulier. UML permet de reprsenter un environnement dexcution ainsi que des ressources physiques (avec les parties du
systme qui sy excutent) grce aux diagrammes de dploiement. Lenvironnement dexcution ou les ressources matrielles sont appels nuds . Les parties dun systme qui
sexcutent sur un nud sont appeles artefacts . Un artefact peut prendre la forme
dun fichier binaire excutable, dun fichier source, dune table dune base de donnes, dun
document, dun courrier lectronique, etc.
La figure D.1 reprsente le dploiement dun serveur Web avec lequel une machine cliente,
dote dun navigateur Web, communique. Le serveur, qui est connect une base de donnes
installe sur une machine tierce, excute lartefact siteWEB.
Figure D.1
Diagramme de
dploiement pour
un serveur Web
qui prsente des
instances de nuds
et une instance
dartefact dploye.
client : PC
serveurWEB : Serveur
serveurBaseDeDonnes : ServeurSGBD
dploy
artfact
siteWEB
Figure D.2
Diagramme de
dploiement pour
un serveur Web
qui prsente des
nuds.
240
UML 2
PC
Serveur
1..*
ServeurSGBD
Les associations entre les nuds sont des chemins de communication tels que des cbles
rseaux, des bus, etc., qui peuvent porter une multiplicit : la figure D2 prsente plusieurs
PC qui sont connects au site Web du serveur.
Dfinition
Un nud est une ressource sur laquelle des artefacts peuvent tre dploys pour tre excuts. Un artefact est la spcification dune entit physique du monde rel.
Notation
Un nud se reprsente par un cube dont le nom respecte la syntaxe des noms de classes (voir
chapitre 2). Le nom dun nud instanci doit tre soulign (figure D.1).
Un artefact se reprsente comme une classe par un rectangle contenant le mot-cl artefact
suivi du nom de lartefact. Celui-ci est soulign quand il sagit dune instance. Un artefact
dploy sur un nud est symbolis par une flche en trait pointill qui porte le strotype
dploy et qui pointe vers le nud (figure D.1). Lartefact peut aussi tre inclus directement
dans le cube reprsentant le nud.
Plusieurs strotypes standard existent pour les artefacts : document, excutable, fichier,
librairie, source.
Annexe E
Implmentation dun
modle objet en Java
Dans le cycle de dveloppement dun systme, limplmentation correspond la phase
de ralisation. Quand il sagit dun logiciel, cela consiste traduire les modles danalyse et de
conception dans un langage de programmation. Cette phase peut tre automatise en partie
avec des outils informatiques de modlisation. Ces outils sont nombreux (GDPro, ObjectTeam, Objecteering, OpenTool, Rhapsody, STP, Visio, Visual Modeler, WithClass, ).
Certains supportent UML depuis ses dbuts (Rose de Rational Software), dautres viennent
du monde du logiciel libre (ArgoUML). Nombreux sont les outils qui permettent la gnration automatique de code partir dun diagramme de classes vers des langages de programmation varis (Java, C++, C#, etc.). Dans la suite de ce paragraphe, nous montrons
comment implmenter les lments essentiels dun diagramme de classes, et comment traduire les messages des diagrammes dinteraction (de squence ou de communication) en Java.
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
IMPLMENTATION
Les langages de programmation comme Java noffrent pas de technique particulire pour
implmenter des associations, des agrgations ou des compositions. Ce type de relation
simplmente en ajoutant des attributs dans des classes.
Figure E.3
Exemplaire
0..1
range
Emplacement
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
Figure E.5
Entreprise
1
+
clients
Client
244
UML 2
Figure E.6
uvre
uvre
1..n exemplaires
Exemplaire
Figure E.7
Voiture
Moteur
Composition
public class Voiture{
private class Moteur{
}
private Moteur moteur;
}
IMPLMENTATION
Figure E.8
DE LENVOI DE MESSAGES
com Piloter
conduire
conducteur : Conducteur
dmarrer
voiture : Voiture
246
UML 2
Figure E.9
sd Piloter
conducteur : Conducteur
voiture : Voiture
conduire
demarrer
Annexe F
Organisation dUML 2
DIFFRENTES
VUES DUML
Le langage UML sintgre dans toutes les phases du cycle de vie du dveloppement, allant de
la collecte des besoins au dploiement. UML ne dfinit pas de processus de dveloppement.
Il est utilisable avec la plupart des processus existants. UML donne la possibilit dutiliser
les mmes concepts et notations, sans ncessiter de conversion, dans les diffrentes phases
de dveloppement. Il est, de ce fait, bien adapt au cycle de dveloppement itratif et
incrmental.
ORGANISATION
EN PAQUETAGES
Un paquetage dfinit des regroupements qui rpondent aux contraintes applicatives et aux
besoins du dveloppement. Dans la version 2 dUML, un modle est dfini par un paquetage
qui comprend une description complte dun systme partir dun point de vue spcifique.
Le mtamodle UML, qui est aussi compos dun ensemble de modles, est modlis par
des paquetages. Les principales caractristiques des normes OMG sont regroupes dans le
paquetage dit Core. UML, CWM, MOF, les profils et les autres mtamodles utilisent les
standards spcifis dans le modle Core, comme le montre la figure F.1.
Figure F.1
Structure du
mtamodle en
paquetages.
Chaque modle (paquetage) est, son tour, compos de plusieurs sous-paquetages, ce qui
confre UML une organisation arborescente. Plus on remonte vers la racine, plus on slve
dans le niveau dabstraction. Par exemple, le modle Core contient les sous-paquetages
PrimitivesTypes, Abstractions, Basic et Profils, comme le montre la figure F.2.
Figure F.2
Structure
hirarchique
du modle
(paquetage)
Core.
Selon le mme principe, chaque paquetage est, lui-mme, compos de plusieurs sousmodles. Par exemple, le modle de la superstructure dUML 2, qui permet de spcifier la
syntaxe des modles utilisateurs, est compos, entre autres, dun modle de classes, dun
modle dinteractions, dun modle de profils et dun modle de cas dutilisation, comme le
montre la figure F.3.
248
UML 2
Figure F.3
Paquetages
composant la
superstructure du
langage UML 2.
COUCHES
DU MTAMODLE
Les paquetages dfinissent la hirarchie dabstraction entre les diffrents modles, mais ne
mettent pas en vidence les diffrentes couches de modlisation, en particulier les diffrences entre les mtamodles et le modle de donnes. LOMG propose une organisation en
couches de ses langages parmi lesquels figure UML 2. Les caractristiques quils partagent
sont regroupes dans le mtamodle MOF. Linstanciation de ce mtamodle donne naissance des langages comme UML et CWM. Lutilisateur dUML dfinit des classeurs (classes, associations) dcrivant son application en respectant les spcifications du
mtamodle UML. Un modle utilisateur bien employ garantit un modle dobjets physiques actifs, avec des proprits bien dfinies.
Une architecture de modlisation se compose de quatre couches : les couches M0, M1, M2
dfinissent respectivement les instances actives du modle utilisateur, le modle de donnes
utilisateur, et le mtamodle UML, la faon dont est construit ce dernier tant spcifie par
la couche M3. Lexemple prsent la figure F.4, extrait de la spcification de la superstructure du langage UML, illustre les quatre couches.
La vido (aVido) qui est en train dtre visionne est une instance active : elle se situe au
niveau M0. Cette vido est une instance de la classe Vido (diagramme de classes), en
loccurrence linstance 2001 : A spaceOdyssey (diagramme dobjets). Les diagrammes de
classes et dobjets correspondent au modle utilisateur : ils sont donc au niveau M1. La
classe Vido et les attributs quelle contient sont modliss dans le respect du mtamodle
UML, qui spcifie comment dfinir une classe et un attribut : ils font donc partie de la couche M2. Un attribut, une classe et une instance respectent les spcifications MOF. Au niveau
de la couche MOF, ils sont spcifis par une classe (cela correspond la couche M3).
Figure F.4
Exemple mettant
en vidence
lorganisation en
quatre couches
du langage UML.
MODLES
CONCEPTUELS DUML
Les paquetages et les couches donnent une organisation architecturale du langage UML. Un
utilisateur na pas besoin de connatre cette organisation pour bien utiliser ce langage. Il doit
se contenter de respecter la syntaxe et la smantique dUML. Il doit galement connatre les
diffrents diagrammes mettant en valeur tantt des aspects statiques, tantt des aspects
comportementaux du systme. Une organisation conceptuelle des diffrents diagrammes
UML permet davoir une vision plus claire des vues offertes par ce langage. Les trois auteurs
lorigine dUML proposent un dcoupage conceptuel en quatre domaines : structurel,
dynamique, physique et gestion de modles. Chaque domaine est compos de plusieurs
vues et chaque vue est ralise par un ensemble de diagrammes UML.
Domaine structurel
Le domaine structurel est compos des trois vues suivantes :
La vue fonctionnelle. Elle conceptualise et structure les besoins de lutilisateur (diagramme de cas dutilisation). Elle dfinit le contour du systme modliser en dfinissant les fonctionnalits principales sans pour autant chercher lexhaustivit. Elle sert
dinterface entre les diffrents intervenants dans le projet.
La vue statique. Elle dfinit les principaux classeurs de lapplication. Elle est modlise
par un ensemble de classes dotes dattributs et doprations. Celles-ci sont organises
via des relations de composition, de gnralisation, etc. Des objets en excution peuvent
tre modliss pour illustrer leur comportement et leurs relations. La vue statique se prsente essentiellement sous forme de diagrammes de classes et dobjets.
La vue conceptuelle. Elle met en vidence les collaborations entre classeurs et dcrit
larchitecture physique du systme. Elle est ralise par le diagramme de collaborations et
le diagramme de composants.
250
UML 2
Domaine dynamique
Le domaine dynamique regroupe lensemble des vues montrant le comportement du systme lexcution : la vue des interactions (diagramme dactivits), des machines tats
(diagramme dtats-transitions), des interactions (diagramme de squences et diagramme
de communication)
Domaine physique
Le domaine physique est compos de la seule vue de dploiement. Elle dcrit lemplacement
physique du matriel utilis et la rpartition des composants sur ce matriel. Ces ressources
sont modlises par des nuds interconnects. Cette vue est particulirement importante
dans le cas de la modlisation des environnements distribus o une place importante est
donne lexpression des exigences en termes de performances.
Annexe G
Bibliographie
[Blaha 2005]
Michael Blaha, James Rumbaugh. Modlisation et conception orientes objet avec UML 2,
Pearson Education, 2005
[Gamma 95]
rich Gamma, Richard Helm, Ralph Johnson et John Vlissides. Design Patterns: Elements
of Reusable Object-Oriented Software, Addison-Wesley, 1995
[Jacobson 1999]
Ivan Jacobson, Grady Booch et James Rumbaugh. Le processus unifi de dveloppement
logiciel, Eyrolles, 1999
[Kernighan, Ritchie 1990]
Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, Prentice Hall, Inc.
1988. En franais : Le Langage C : norme ANSI, taduit par Jean-Franois Groff et ric Mottier,
Dunod, coll. Sciences sup , 2e dition, 2004
[Larman]
Craig Larman. UML et les design patterns, deuxime dition, CampusPress, 2005
[Norme UML 2.0]
OMG (Object Management Group). UML 2.0 Superstructure (rfrence ptc/04-10-02),
UML 2.0 Infrastructure (rfrence ptc/03-09-15), http://www.uml.org, 2004
[Penders 2002]
Tom Penders. Introduction UML, EOM, 2002
[Rumbaugh 2004]
James Rumbaugh, Ivar Jacobson et Grady Booch. UML 2.0 - Guide de rfrence, CampusPress, 2004
252
UML 2
Index
A
Abstraite
classe 38
mthode 38
Acteur 3, 9, 16, 27, 29
Action
call 131, 156
manipulations de variables 158
opaque 160
raise exception 157
send 157
sur un link 159
time event 131
Activit
argument d'une 168
concurrence 171, 181
description 161
et cas d'utilisation 178, 182
exception 172
interne 133
interruptible 174
ligne d'eau 166
partition 166
pin 168
programmation 166, 177, 179, 183
structure 166
structures de contrle 164
zone d'expansion 175
Agrgation 50
Alt, oprateur dinteraction 96
Alternative 96
Analyse
du systme 1
phase d 190
Argument 94
Artefact 241
Assert 95
Assert, oprateur 98
Assertion 95
Association 46
avec contraintes 47
classe 48
drive 48
n-aire 49
qualifie 49
Asynchrone, message 91, 111
Attribut driv 61
B
Boucle
oprateur 104
reprsentation 97
Break 97
C
Cas d'utilisation 2, 9
acteur 3
dfinition 3
diagramme 1, 2, 15
extension 5, 25, 27
gnralisation 5, 29
inclusion 5, 29
relations 5, 18
Index 253
Classe 37
active 64
attribut de la 40, 41
contrainte sur 65
exceptions 43
mthode de la 42
nom de la 38, 63
opration de la 42, 43
paramtrable 65
responsabilits d'une 43
strotype 63
Classeur 36
dfinition 4
rle 237
structur 88, 125, 226, 237
utilisation 88
Collaboration
dfinition 89
rle 89
utilisation 122
Com, mot-cl 87
Composition 50
Conception 89, 194
Concurrence
activits 171
barre de synchronisation 135
tats-transitions 139
zone d'expansion 175
Connecteurs 54
Consider, oprateur 98
Construction du diagramme de classes 57
Contraintes 56
de dure 114
sur les lignes de vie 95
Critical 117
D
Dpendance, relation de 51
Dploiement, diagramme 197, 240
Diagramme
d'interactions 87, 106
d'objets 74, 217
dtats-transitions 128
de cas d'utilisation 1, 2, 15
de classes 35
de communication 87, 106
de dploiement 197, 240
de squence 87, 106
objets 54
254
UML 2
Index
H
Hritage 71, 72
exceptions 174
multiple 53, 72
relation 52
signal 130
Historique, pseudo-tat 136
Objet 37
actif 113
ligne de vie 86
passif 113
reprsentation 55
Occurrence d'vnement 92
Oprande d'interaction 96
Opt 120
I
Ignore, oprateur 98
Implmentation en langage Java 241
Inclut 5
Inout, paramtre 94, 105
Instance 37
de relation 56
Interaction
dfinition 86
diagramme 87
fragment 96
message 87, 91, 92, 103
oprande 96
utilisation 106
Interface 44
ralisation d'une 68
utilisation d'une 68
Interne, structure 237
L
Ligne de vie 86
M
Message
asynchrone 64, 91
dans un diagramme
de communication 104, 108
de squence 94, 107
dfinition 91
dlai de transmission 91
signal 130
synchrone 91, 156
Modle des cas dutilisation 1, 15
Modlisation d'une classe 61
Multiplicit 45
P
Paquetage 25
dfinition 8
dpendance 25
Par, oprateur 97, 117
Parallle, envoi de messages 97
Paramtre
de retour 94
inout 94, 105
Partie structure 237
Patron de conception
adapteur 81
Bridge 80
objets composites 74
Phase
d'implmentation 188
de dploiement 188
de maintenance 188
de tests 188
Pin
d'exception 169
dfinition 168
stream 170
Point
d'extension 6, 28, 33
de choix 132
de jonction 131, 164
Port 54
proprits 54
protocole 54
Postcondition 12, 23
Prcondition 12, 22
protocol 138
R
N
Neg 120
Nud dans un diagramme de dploiement 240
Numro de squence 103
Index 255
d'extension 5
d'inclusion 5
dpendance 51
d'instanciation 56
gnralisation 5, 7, 28
hritage 52
n-aire 70
simple 66
256
T
Thread 91
U
Utilisation
d'une collaboration 89
d'une interaction 88
Scnario 14
Sd, mot-cl 87
Signal 54
vnement 130
Strotype, dfinition 4
Strict sequencing, oprateur 99
Structure interne 237
Synchrone, message 91
Synchronisation des activits 171
UML 2
Z
Zone d'expansion 175
Informatique
Synthse
de cours
exercices
corrigs
&
Les auteurs :
Benot Charroux dirige le
dpartement informatique de
lEFREI (Villejuif), o il enseigne la
modlisation et la programmation
objet. Il est galement formateur en
entreprise.
Aomar Osmani est matre de
confrences luniversit Paris XIII.
Il assure des enseignements sur
UML, les bases de donnes,
lalgorithmique, la programmation
objet, le gnie logiciel et les
rseaux. Il y est aussi responsable
de la Licence en formation continue.
Yann Thierry-Mieg est matre de
confrences luniversit Paris VI.
Il effectue des recherches sur UML 2
dans le cadre de mthodologies
de dveloppement adaptes au
domaine des logiciels critiques.
Dans la mme collection :
Algorithmique, Applications en C,
J.-M. Lry
Algorithmique en C++, J.-M. Lry
Algorithmique en Java 5, J.-M. Lry
Architecture de lordinateur, E. Lazard
Architecture des rseaux, D. Seret,
D. Dromard
Cration de bases de donnes,
N. Larrousse
Excel 2007 et VBA, B. Minot
Java 5 et 6, R. Chevallier
LaTeX, J.-C. Charpentier, D. Bitouz
Le langage C, J.-M. Lry
Le langage C++, M. Vasiliu
Linux, J.-M. Lry
Mathmatiques discrtes appliques
linformatique, R. Haggarty
SQL, F. Brouard, C. Soutou
Systmes dexploitation, B. Lamiroy et al
XML, G. Chagnon, F. Nolot
UML 2
2e dition
Pratique de la modlisation
ISBN : 978-2-7440-4050-4