Rsum du sous-ensemble

de la notation UML 2
utilis dans ce livre

Diagramme de cas dutilisation

Diagramme de squence
Diagramme de classes
Diagramme de packages
Diagramme dtats

Groupe Eyrolles, 2005

annexe

Cahier du programmeur UML 2

Diagramme de cas dutilisation

Montre les interactions fonctionnelles entre les acteurs
et le systme ltude

Figure A1 Diagramme de cas dutilisation (bases)

Acteur : rle jou par un utilisateur humain ou un autre systme qui

interagit directement avec le systme tudi. Un acteur participe au
moins un cas dutilisation.
Cas dutilisation (use case) : ensemble de squences dactions ralises
par le systme produisant un rsultat observable intressant pour un
acteur particulier. Collection de scnarios relis par un objectif utilisateur commun.
Association : utilise dans ce type de diagramme pour relier les acteurs et
les cas dutilisation par une relation qui signifie simplement participe .
Inclusion : le cas dutilisation de base en incorpore explicitement un
autre, de faon obligatoire, un endroit spcifi dans ses enchanements.
Extension : le cas dutilisation de base en incorpore implicitement un
autre, de faon optionnelle, un endroit spcifi indirectement dans
celui qui procde lextension (dconseill !)
Gnralisation : les cas dutilisation descendants hritent de la description de leur parent commun. Chacun dentre eux peut nanmoins comprendre des relations spcifiques supplmentaires avec dautres acteurs
ou cas dutilisation (dconseill !). La gnralisation dacteurs est en
revanche parfois utile.
182

Groupe Eyrolles, 2005

A Rsum du sous-ensemble de la notation UML 2 utilis dans ce livre

ud UC diagramme complexe

Sujet
Use Case2
include
ActeurHumain

Fragment
Use Case21

Use Case22

include

Use Case1
Extension points:
PtEx2
PtEx1

(PtEx1)

Use Case3

extend

ActeurSpcialis

Figure A2 Diagramme de cas dutilisation (avanc)

Diagramme de squence
Montre la squence verticale des messages passs entre
objets au sein dune interaction

Figure A3

Diagramme de squence (bases)

Groupe Eyrolles, 2005

183

Cahier du programmeur UML 2

Ligne de vie : reprsentation de lexistence dun lment participant

dans un diagramme de squence. Cela peut tre un acteur ou le systme
en modlisation dexigences, des objets logiciels en conception prliminaire ou conception dtaille.
Message : lment de communication unidirectionnel entre objets qui
dclenche une activit dans lobjet destinataire. La rception dun message provoque un vnement dans lobjet rcepteur. La flche pointille
reprsente un retour au sens UML. Cela signifie que le message en question est le rsultat direct du message prcdent.

Figure A4

Diagramme de squence (avanc)

Spcification dactivation : bande blanche qui reprsente une priode

dactivit sur une ligne de vie.
Message synchrone : envoi de message pour lequel lmetteur se bloque
en attente du retour et qui est reprsent par une flche pleine. Un message asynchrone, au contraire, est reprsent par une flche ouverte.
Occurrence dinteraction : une interaction peut faire rfrence explicitement une autre interaction grce un cadre avec le mot-cl ref et indiquant le nom de lautre interaction.
UML 2 a ajout une nouvelle notation trs utile : les cadres dinteraction. Chaque cadre possde un oprateur et peut tre divis en fragments. Les principaux oprateurs sont :
loop : boucle. Le fragment peut sexcuter plusieurs fois, et la condition de garde explicite litration.
184

Groupe Eyrolles, 2005

A Rsum du sous-ensemble de la notation UML 2 utilis dans ce livre

sd Squence
:ClasseA
:ActeurHumain
loop

appel synchrone

[condition]

create

nouveau
:ClasseB

self-message
retour
autre appel
alt

m1 asynchrone

[C1]
[else]

m2

destroy

Figure A5

Diagramme de squence (avanc-suite)

opt : optionnel. Le fragment ne sexcute que si la condition fournie

est vraie.
alt : fragments alternatifs. Seul le fragment possdant la condition
vraie sexcutera.

Diagramme de classes
Montre les briques de base statiques : classes, associations, interfaces, attributs, oprations, gnralisations,
etc.

Figure A6

Diagramme de classes (bases)

Groupe Eyrolles, 2005

185

Cahier du programmeur UML 2

Classe : description abstraite dun ensemble dobjets qui partagent les

mmes proprits (attributs et associations) et comportements (oprations et tats).
Attribut : donne dclare au niveau dune classe, ventuellement type,
laquelle chacun des objets de cette classe donne une valeur. Un attribut
peut possder une multiplicit et une valeur initiale. Un attribut
driv ( / ) est un attribut dont la valeur peut tre dduite dautres
informations disponibles dans le modle.
Opration : lment de comportement des objets, dfini de manire
globale dans leur classe. Une opration peut dclarer des paramtres
(eux-mmes typs) ainsi quun type de retour.

Figure A7

Diagramme de classes (bases-suite1)

Association : relation smantique durable entre deux classes, qui dcrit

un ensemble de liens entre instances. Une association est bidirectionnelle par dfaut, sauf si lon restreint sa navigabilit en ajoutant une
flche.
Rle : nom donn une extrmit dune association ; par extension,
manire dont les instances dune classe voient les instances dune autre
classe au travers dune association.
Multiplicit : le nombre dobjets (min..max) qui peuvent participer une
relation avec un autre objet dans le cadre dune association. Multiplicits
frquentes :
0..1 = optionnel (mais pas multiple)
1 = exactement 1
0..* = * = quelconque
1..* = au moins 1

Figure A8

Diagramme de classes (bases-suite2)

186

Groupe Eyrolles, 2005

A Rsum du sous-ensemble de la notation UML 2 utilis dans ce livre

Agrgation : cas particulier dassociation non symtrique exprimant une

relation de contenance.
Composition : forme forte dagrgation, dans laquelle les parties ne peuvent appartenir plusieurs agrgats et o le cycle de vie des parties est
subordonn celui de lagrgat.
Figure A9

Diagramme de classes (bases-suite3)

Super-classe : classe gnrale relie dautres classes plus spcialises

(sous-classes) par une relation de gnralisation.
Gnralisation : relation entre classifieurs o les descendants hritent des proprits de leur parent commun. Ils peuvent nanmoins comprendre chacun des proprits spcifiques supplmentaires, mais aussi
modifier les comportements hrits.

Figure A10

Diagramme de classes (bases-suite4)

Note : commentaire visible dans le diagramme. Peut tre attach un

lment du modle (ou plusieurs) par un trait pointill. Utilisable dans
tout type de diagramme UML !

Figure A11

Diagramme de classes (avanc)

Classe dassociation : association promue au rang de classe. Elle possde

tout la fois les caractristiques dune association et celles dune classe et
peut donc porter des attributs qui prennent des valeurs pour chaque lien
entre objets.
Qualifieur (ou qualificatif ) : attribut qui permet de partitionner
lensemble des objets en relation avec un objet donn dans le cadre dune
association multiple.
Groupe Eyrolles, 2005

187

Cahier du programmeur UML 2

Figure A12

Diagramme de classes (avanc-suite1)

Contrainte : condition portant sur un ou plusieurs lment(s) du modle

qui doit tre vrifie par les lments concerns. Elle est note entre
accolades { }, et souvent insre dans une note graphique (le post-it).

Figure A13

Diagramme de classes (avanc-suite2)

Dpendance : relation smantique entre deux lments, dans laquelle la

modification dun des lments (llment indpendant) peut affecter la
smantique de lautre lment (llment dpendant).

Figure A14

Diagramme de classes (avanc-suite3)

Catgorisation des classes danalyse en trois catgories qui a t propose par I. Jacobson et popularise ensuite par le RUP (Rational Unified Process) :
Celles qui permettent les interactions entre le site web et ses utilisateurs sont qualifies de dialogues . Il sagit typiquement des crans
proposs lutilisateur.
Les classes qui contiennent la cinmatique de lapplication sont
appeles contrles . Elles font la transition entre les dialogues et
les concepts du domaine, et contiennent les rgles applicatives.
Celles qui reprsentent les concepts mtier sont qualifies
d entits . Elles sont trs souvent persistantes.

188

Groupe Eyrolles, 2005

A Rsum du sous-ensemble de la notation UML 2 utilis dans ce livre

Diagramme de packages
Montre lorganisation logique du modle et les relations
entre packages

Figure A15

Diagramme de packages

Package (ou paquetage) : mcanisme gnral de regroupement dlments tels que classes, interfaces, mais aussi acteurs, cas dutilisation, etc.
Les packages peuvent tre imbriqus dans dautres packages.
Importation : relation de dpendance entre packages qui rend visibles
les lments publics de lun des packages au sein dun autre.

Figure A16

Diagramme de packages (suite)

Les packages sont des espaces de noms (namespace) : deux lments ne

peuvent pas porter le mme nom au sein du mme package. En
revanche, deux lments appartenant des packages diffrents peuvent
porter le mme nom. Du coup, UML propose une notation complte
pour un lment : nomPackage::nomlment.
Groupe Eyrolles, 2005

189

Cahier du programmeur UML 2

Diagramme dtats
Montre les diffrents tats et transitions possibles des
objets dune classe lexcution

Figure A17

Diagramme dtats (bases)

tat : condition ou situation qui se produit dans la vie dun objet pendant laquelle il satisfait une certaine condition, excute une activit particulire ou attend certains vnements.
vnement : spcification dune occurrence remarquable qui a une localisation dans le temps et lespace. Un vnement peut porter des paramtres qui matrialisent le flot dinformation ou de donnes entre objets.

Figure A18

Diagramme dtats (bases-suite)

Transition : connexion entre deux tats dun automate, qui est dclenche par loccurrence dun vnement, et conditionne par une condition
de garde, induisant certains effets.
Effet : action ou activit qui sexcute lorsquune transition se dclenche.
Lexcution de leffet est unitaire et ne permet de traiter aucun vnement supplmentaire pendant son droulement.
Un tat peut contenir une activit durable (do-activity), qui est interruptible par un vnement, mais peut galement se terminer delle-mme.

190

Groupe Eyrolles, 2005