Unied Modeling Language

langage de modelisation... langage et non pas methode

approche orientee objet
attentif aux utilisateurs
Je remercie Laurent Audibert qui ma permis de reproduire certains de ses schemas. Vous
trouverez son polycopie, tr`es tr`es complet, sur le site
http://laurent-audibert.developpez.com/Cours-UML/
UML
UML nest pas une methode.
Neanmoins, pour les concepteurs dUML, tout processus de developpement devrait etre
pilote par les cas dutilisation
centre sur larchitecture
iteratif et incremental
Cycle de vie AUP
Les phases Commencement, Elaboration, Construction, Transition se succ`edent et,
divisees en iterations, constituent le cycle de vie du projet.
Une iteration contient les disciplines Modelisation, Implementation,... dans des
proportions relatives `a literation.
voir le schema sur
http://www.ambysoft.com/unifiedprocess/agileUP.html#Overview
Les Phases A.U.P.
Commencement : le but est didentier la portee initiale du projet, une architecture
potentielle pour lapplication, de saccorder sur le nancement initial du projet et
lacceptation des depositaires (utilisateurs, managers,...).
Elaboration : le but est de valider larchitecture de lapplication.
Construction : le but est de construire, de fa con reguli`ere et progressive, le logiciel qui
repond aux besoins les plus prioritaires des depositaires.
Transition : le but est de valider et dinstaller lapplication dans lenvironnement de
production.
Les Disciplines A.U.P.
Modelisation : comprendre le domaine de lapplication, lenvironnement du projet et
identier une solution viable pour le probl`eme.
Implementation : transformer le mod`ele en code executable et mettre en uvre des
tests de bas niveau (unit tests)
Test : executer une evaluation objective pour assurer la qualite (recherche de defauts,
verication de ladequation aux exigences initiales).
Installation : Livraison de lapplication et mise `a disposition des utilisateurs naux.
Gestion de conguration : gestion des prototypes.
Gestion de projet : assignation des taches, suivi de progression dans le but de ne pas
depasser les delais et le budget.
Environnement. verication de la disponibilite materielle et logicielle, suivi des
directives et des normes.
Remarques
Les concepteurs de methodes essaient de formaliser une realite evidente : il est dicile de
trop ger les phases dun developpement logiciel, les activites se chevauchent, les points de
vue sont multiples... Un cycle iteratif semble reeter mieux la realite du developpement
logiciel.
Il ny a pas une demarche absolue. Il faut adapter selon le projet. Pour un petit projet, il
est possible que lanalyse soit satisfaisante d`es la premi`ere iteration. Plus le projet est
consequent, plus il faut revenir sur lanalyse et la conception.
Meme `a linterieur de la conception, une demarche iterative est souvent bien adaptee :
decrire les besoins, decrire les classes, puis decrire les scenarios qui anent les classes, qui
eux-memes anent les scenarios...
Une demarche possible... `a gros traits...
1. etude dopportunite : description generale de lapplication `a realiser, faisabilite,...
2. analyse (quoi faire) : mise en evidence des principaux cas dutilisation, scenarios (au
minimum nominal), diagrammes de sequences,...
3. conception (comment) : description detaillee de lapplication (architecture),
eventuellement maquette de lapplication, validation par lutilisateur
4. plan de developpement, formation dune equipe, environnement de travail (bacs `a
sable, gestionnaire de versions...),
5. mise en uvre des iterations jusqu`a obtenir satisfaction de lutilisateur
(a) description des scenarios traites par literation (nouveaux ou/et `a corriger)
(b) aectation des taches
(c) denition des crit`eres devaluation
(d) implementation (dans les bacs `a sable)
(e) test des unites, des classes
(f) integration dans le prototype, documentation
(g) presentation `a lutilisateur futur, validation/evolution
6. integration de lapplication dans lenvironnement nal, tests, formations
Phase delaboration `a gros traits (avec les diagrammes UML)
1. description generale de lapplication `a realiser (pas de materiel, logiciel...)
2. mise en evidence des principaux cas dutilisation
3. iterations, pour chaque cas dutilisation, jusqu`a description assez ne
(a) description des scenarios, scenario nominal et exceptions
description textuelle, denition de tests `a passer
diagramme de collaboration (de communication), diagramme de sequence
(b) identication des classes diagramme des classes
(c) utilisation possible de diagrammes detats/transitions
(d) integration des classes dans le mod`ele du domaine
4. realisation dune maquette/prototype, documentation de cette architecture
5. plan de developpement pour le projet (les iterations, cahier des charges, evaluations...)
6. validation par lutilisateur
plan de presentation
objets, messages, application.....description avec UML.
diagrammes de classes
diagrammes de cas dutilisation
diagrammes dactivites
diagrammes de sequence
diagrammes detats/transitions
objet
Un objet, au sens informatique, est une representation abstraite dentites du monde reel
ou virtuel.
le chier du poly
nom = poly.pdf
taille = 375 Ko
mon velo
type = randonneur
couleur = blanc
poids = 7kg
plateau = 22
pignon = 28
moi :enseignant
nom = Terlutte
prenom = Alain
statut = MdC
moi :individu
nom = Terlutte
prenom = Alain
dateN = 13/07/1951
objet
Un objet est caracterise par
un etat : les informations qui le caracterisent
un comportement : les operations (actions) quil peut faire
une identite, caracteristique de son existence
mon velo
type = randonneur
couleur = blanc
poids = 7kg
plateau = 22
pignon = 28
changerBraquet(Plateau,Pignon)
freiner()
moi :individu
nom = Terlutte
prenom = Alain
dateN = 13/07/1951
vue statique : objet, lien
Des informations caracterisent les objets. Il existe une structure, une repartition de toutes
les informations dans des objets dierents. Il existe des liens entre les objets.
mon velo
type = randonneur
couleur = blanc
poids = 7kg
plateau = 22
pignon = 28
chBraquet(Plt,Pgn)
freiner()
moi :individu
nom = Terlutte
prenom = Alain
dateN = 13/07/1951
proprietaire de
vue statique : objet, lien
Il peut exister des liens ayant des signications dierentes.
mon velo
type = randonneur
couleur = blanc
poids = 7kg
plateau = 22
pignon = 28
chBraquet(Plt,Pgn)
freiner()
moi :individu
nom = Terlutte
prenom = Alain
dateN = 13/07/1951
alter ego :individu
nom = Troubl e
prenom = Amedee
dateN = 21/10/1996
proprietaire de
utilisateur de
utilisateur de
Tout depend du syst`eme `a decrire : les utilisations ou/et les possessions de velos...
La vue statique conduira au diagramme de classes.
vue dynamique : objet, message
Les objets peuvent communiquer, interagir. Il existe des liens entre les objets.
Lun peut demander `a lautre de realiser une operation. Les objets echangent des
messages.
mon velo
type = randonneur
couleur = blanc
poids = 7kg
plateau = 22
pignon = 28
chBraquet(Plt,Pgn)
freiner()
moi :individu
nom = Terlutte
prenom = Alain
dateN = 13/07/1951
chBraquet(32,28)

objet, message
Si lobjet est correctement realise, apr`es reception et traitement du message, lobjet aura
change detat.
mon velo
type = randonneur
couleur = blanc
poids = 7kg
plateau = 32
pignon = 28
chBraquet(Plt,Pgn)
freiner()
moi :individu
nom = Terlutte
prenom = Alain
dateN = 13/07/1951
cas dutilisation
La description dynamique commencera par la description des besoins
Syst`eme ` a developper
client
service
maintenance
Commander
boisson
Demander
remboursement
Reparer
Approvisionner
diagramme de collaboration ou diagramme de communication
Diagramme montrant des objets dans une situation de communication particuli`ere
(insistence sur lorganisation des objets).
:utilisateur
panneau
commande
distributeur
1: choixBoisson(petit cafe sucre)

2: PreparerCafe(0.5,0.2)

3: chauerEau()
Ce diagramme se lit :
lutilisateur envoie dabord le message choixBoisson(petit cafe sucre) `a lobjet panneau de
commande, puis lobjet panneau de commande envoie le message preparerCafe(0.5,0.2) `a
lobjet distributeur, enn lobjet distributeur senvoie (realise) le message chauferEau().
Ce diagramme decrit un scenario.
diagramme de sequence
Diagramme proche permettant de decrire une sequence beaucoup plus detaillee. Il nest
pas necessaire dindiquer la chronologie (elle est implicite).
:utilisateur
panneau
commande
distributeur
t
choixBoisson(petit caf e sucre)
preparerCafe(0.5,0.2)
chaufferEau()
UML : les diagrammes
UML propose neuf types de diagrammes pour decrire les vues statiques (structure) et
dynamiques (comportement) dun syst`eme.
diagrammes structurels
diagramme de classes
diagramme dobjets
diagramme de composants
diagramme de deploiement
diagrammes comportementaux
diagramme des cas dutilisation
diagramme etats/transitions
diagramme dactivites
diagramme de sequences
diagramme de collaboration (de communication)
classes
Les objets appartiennent souvent `a des ensembles qui ont les memes caracteristiques.
Une classe est une abstraction decrivant lensemble. Tous les objets dune meme classe
auront les memes attributs (avec des valeurs particuli`eres) et les memes operations (les
memes possibilites de comportement).
Un objet est une instance dune classe.
velo
type
couleur
poids
plateau
pignon
chBraquet(Plt,Pgn)
freiner()
mon velo : velo
type = randonneur
couleur = blanc
poids = 7kg
plateau = 22
pignon = 28
chBraquet(Plt,Pgn)
freiner()
instance de
Selon le contexte, on peut ne pas faire apparatre la description compl`ete dune classe.
classes
On doit parfois faire reference `a une instance quelconque dun objet.
velo
type
couleur
poids
plateau
pignon
chBraquet(Plt,Pgn)
freiner()
: velo
type
couleur
poids
plateau
pignon
chBraquet(Plt,Pgn)
freiner()
instance de
Le rectangle de droite (:classe) represente un objet quelconque de la classe velo.
classes, visibilite des attributs et des operations
Certains attributs peuvent etre inaccessibles `a lutilisateur. Il est frequent de ne pas
donner un acc`es direct aux attributs mais de controler cet acc`es par les operations.
De la meme fa con, certaines operations peuvent etre inaccessibles `a lutilisateur.
+ attribut ou operation public, visisble par tous les objets
# attribut ou operation protege, visible par les objets de la meme classe et ceux des
sous-classes
- attribut ou operation prive, visible par les objets de la meme classe
individu
- nom
- prenom
- dateN
+ poids
+ getNom()
+ setNom(nvnom)
classes, syntaxe simpliee des attributs
Visibilite Nom Attribut : Type = Valeur Initiale
Le type peut etre un type predeni (entier, booleen, chane de caract`eres,...) ou une
classe... un tableau, une enumeration...
Il est possible de denir des attributs derives, cest `a dire calcule `a partir dautres
attributs.
Il est possible de preciser quun attribut nest pas modiable (constante, gel e).
individu
- nom : Cha^ ne
- prenom : Cha^ ne
- dateN : Date
+ poids : R eel
+ sexe : Sexes
+ c elibataire : Booleen = Vrai
+ prenomEnfants [0..*] : Cha^ ne
+ /^ age : R eel
enumeration
Sexes
f eminin
masculin
^age = DateCourante - dateN
classes, syntaxe simpliee des operations
Visibilite Nom Operation ( Arguments ) : Type Retourne
Les arguments forment une liste precisant le nom de largument et son type. On peut
aussi preciser sa direction (in (par defaut), out, inout).
individu
- nom : Cha^ ne
- prenom : Cha^ ne
+ GetNom() : Cha^ ne
+ SetNom ( nvnom : Cha^ ne ) : void
Il est aussi possible davoir des attributs ou des operations de classe, cest `a dire partages
par toutes les instances de la classe. Cela permet, par exemple, des mecanismes pour
denombrer les instances dune classe.
associations
Une association represente une relation entre des classes. La plupart des associations sont
binaires.
Les associations peuvent etre nommees et un triangle peut en preciser le sens de lecture.
cours
intitule
jour
heure
enseignant
nom
prenom
fait
associations
Une association peut etre reexive.
individu
nom
prenom
enfant de
Des classes peuvent etre reliees par plusieurs associations, si elles ont des signications
dierentes.
trajetSNCF
noligne
jour
heure
gare
nom
ville
depart de
arrivee de
associations
Lorsquune association concerne les instances de la classe avec une signication
particuli`ere, il est possible de preciser le role de lassociation `a cette extremite.
cours
intitule
jour
heure
individu
nom
prenom
fait
enseignant
suit
etudiant
individu
nom
prenom
enfant de
parent
enfant
classe-associations
On peut avoir envie daecter des attributs `a une association.
etudiant
nom
prenom
discipline
libell e
date
note
est evalue sur
classe-associations
On peut remplacer cette classe-association par une association.
etudiant
nom
prenom
discipline
libell e
epreuve
date
note
passe
concerne
Le diagramme est souvent plus simple `a lire en faisant cette transformation.
associations
Une association peut relier plus de deux classes.
acheteur
nom
prenom
vendeur
nom
prenom
lieu
rue
ville
<>
associations
De la meme fa con, on peut remplacer lassociation par une classe, surtout quand
lassociation utilise une classe-association qui fait apparatre des attributs.
acheteur
nom
prenom
vendeur
nom
prenom
lieu
rue
ville
contrat
date
navigabilite dans les associations
Par defaut, une association est navigable dans les deux sens.
Une notion de navigabilite peut etre indiquee par une `eche. Elle signie que les instances
dune classe voient les objets instances de lautre classe, mais pas linverse.
Par exemple, pour un forum de discussion,
abonne
nom
prenom
message
texte
voit
signie lanonymat : un abonne peut avoir acc`es aux messages mais on ne peut pas
retrouver labonne `a partir du message.
multiplicite des associations
Chaque extremite dune association peut porter une indication de multiplicite indiquant
combien dobjets dune classe peuvent etre lies `a un objet de lautre classe
cours
intitule
jour
heure
enseignant
nom
prenom
fait 1 0..*
Un cours est fait par un seul enseignant. Un enseignant fait un nombre de cours quon ne
peut pas limiter ; il peut ne pas faire de cours.
multiplicite des associations
La multiplicite peut etre une valeur, un intervalle ou un nombre indetermine (symbole ).
A
2

B signie ` a une instance de la classe A correspondent un nombre

indetermine dinstances de la classe B et ` a une instance de la classe B correspondent 2
instances de la classe A
A
0,1

1..10
B signie ` a une instance de la classe A correspondent de 1 ` a 10 instances
de la classe B et ` a une instance de la classe B correspond 0 ou 1 instance de la classe A
A
1..

1
B signie ` a une instance de la classe A correspond exactement 1 instance
de la classe B et ` a une instance de la classe B correspond au moins 1 instance de la
classe A
multiplicite des associations
Les multiplicites courantes sont les suivantes
1 un et un seul
0..1 zero ou un
* de zero `a plusieurs
0..* de zero `a plusieurs
1..* de un `a plusieurs
x un nombre entier x (par exemple 2 ou 7 ou ...)
x..y de x `a y (par exemple 2..7)
x..* x et plus (par exemple 2..*)
multiplicite des associations
etudiant
nom
prenom
cours
discipline
jour
heure
enseignant
nom
prenom
suit
1..* 0..*
fait
1
0..*
Ticket Quinte PMU
num ero ticket
heure du pari
cheval partant
no dossard
couleur casaque
nom
concerne
5
0..*
multiplicite des associations
Les multiplicites des relations n-aires, avec n > 2, ne sont pas simples `a lire.
Prenons le cas dune relation ternaire. Pour determiner les multiplicites, il faut se poser la
question si je choisis un couple dans deux classes, combien dobjets lui sont associes, dans
la troisi`eme ?
acheteur
nom
prenom
vendeur
nom
prenom
lieu/annonce
rue
ville
<>
multiplicite des associations
acheteur
nom
prenom
vendeur
nom
prenom
lieu/annonce
rue
ville
<>
0..1 1
*
Si je prends un lieu et un acheteur, combien puis-je leur associer de vendeurs ? 1 seul.
Si je prends un vendeur et un acheteur, combien puis-je leur associer de lieux ? 0 `a
plusieurs. Le client peut navoir rien achete ou, fortune, avoir achete plusieurs lieux.
Si je prends un lieu et un vendeur, combien puis-je leur associer dacheteurs ? 0 ou 1. Si
on consid`ere le lieu comme une annonce, le fait quun lieu puisse etre vendu plusieurs fois
serait impossible... ce nest plus le meme lieu ; le temps a passe, le prix est dierent.
contraintes sur les associations
Il est possible de preciser des contraintes sur des associations.
Par exemple, pour indiquer quun directeur dUFR est forcement un enseignant nomme
dans lUFR.
enseignant
noligne
jour
heure
UFR
nom
ville
nomme dans
directeur de
{sous-ensemble}
Le langage OCL permet decrire de multiples types de contraintes que lon peut faire
porter sur les associations ou sur les classes.
agregation
Lagregation est une association particuli`ere. Elle indique une relation de dependance plus
forte (type matre/esclave ou contenance) ; une classe domine lautre.
equipe
nom dequipe
individu
nom
prenom
0..* 1..*
Lagregation nimplique pas une realisation particuli`ere (pas de traduction en SQL).
composition
Une composition est une agregation particuli`ere. Dans le cas dune composition, lobjet
contenu ne peut etre partage ; il nappartient qu`a un objet contenant.
De plus, une composition implique une duree de vie. La suppression dun objet
contenant implique la suppression des objets contenus.
hotel
nom
ville
chambre
num ero
etage
nombre de lits
1
1..*
La composition ne produit pas non plus une traduction particuli`ere en SQL mais on
devrait se poser la question des suppressions...
generalisation/specialisation
Une generalisation est une association de classication. Elle permet dindiquer quune
classe est une forme particuli`ere dune autre classe. Le nom donnant la semantique de
cette association pourrait etre est une sorte de.
oeuvre
titre
lm
dur ee
livre
nombre de pages
roman
personnage principal
Cela signie quun livre est une oeuvre, que toute attribut/operation dune uvre est
valide pour un livre. Par exemple, un livre a un titre et un roman a un nombre de pages.
On parle dheritage : la sous-classe herite des attributs de la classe superieure.
Il peut y avoir heritage multiple quand une classe est sous-classe de plusieurs classes
principales. Elle herite des attributs et des operations des classes principales.
diagramme des cas dutilisation
Representation des besoins exprimes par les utilisateurs.
Identier les acteurs.
Identier les besoins.
Mettre en evidence des parties de cas dutilisation.
inclusion : notion de sous-programme qui sera execute par le scenario principal
extension : notion de sous-programme optionnel du scenario principal
generalisation, specialisation : cas particuliers du cas dutilisation (retirer des
euros est une specialisation de retirer de largent)
Lanalyse des besoins par les cas dutilisation saccommode tr`es bien dune approche
iterative et incrementale.
diagramme des cas dutilisation
Premi`ere description des fonctionnalites du syst`eme, on represente les acteurs et leurs
besoins
Syst`eme ` a developper
Acteur
Cas dutilisation
= fonctionnalite du syst`eme
quon detaille progressivement...
Figure 1: exemple de diagramme des cas dutilisation (L. Audibert)
diagramme des cas dutilisation
Un cas dutilisation synthetise un ensemble de scenarios avec des traitements optionnels et
des traitements derreurs. Un scenario est une instance de cas dutilisation (une
description de ce qui doit se passer). Le scenario nominal est le scenario le plus court,
celui o` u tout se passe correctement.
Les traitements optionnels sont des extensions du scenario nominal. Ils peuvent apparatre
dans le diagramme sous forme de traitements dextension.
Mettre en evidence des parties de scenario quon peut isoler conduit aux inclusions.
Mettre en evidence des cas particuliers conduit `a des specialisations.
Ne pas hesiter `a decrire les scenarios de fa con textuelle.
Chaque scenario sera decrit plus tard par un diagramme dactivites et/ou par un
diagramme de communication et/ou par un diagramme de sequence.
cas dutilisation, description textuelle
cas dutilisation : retrait dargent (premi`ere ebauche)
scenario nominal :
1. lutilisateur introduit sa carte
2. lutilisateur sidentie
3. le syst`eme propose dierentes sommes
4. lutilisateur choisit une somme
5. le syst`eme donne la somme
inclusion (commune `a plusieurs operations) : lutilisateur introduit sa carte et sidentie
point dextension 4 : lutilisateur desire une autre somme
exception 4 : lutilisateur peut annuler loperation
Il faudra aner : le syst`eme a-t-il du stock de billets ?, lutilisateur a-t-il fait dautres
retraits durant la semaine ?....
Figure 2: exemple de diagramme des cas dutilisation (L. Audibert)
Figure 3: exemple de diagramme des cas dutilisation.
Relations dinclusion pour decomposer un cas complexe (L. Audibert)
diagramme de sequence simplie
Un cas dutilisation represente un ensemble de scenarios. Ces scenarios devraient etre
decrits de fa con textuelle.
Pour formaliser la description dun scenario, il est possible dutiliser une forme simpliee
de diagramme de sequence.
Le diagramme de sequence montre les interactions entre objets en insistant sur la sequence
des interactions. Il va donc permettre de decrire les interactions entre les acteurs et le
syst`eme, sans rentrer dans la description du syst`eme.
diagramme de sequence simplie
:utilisateur
:syst`eme
t
demandeListeEtudiants()
liste()
choixEtudiant(noSS)
informationsEtudiants()
modifierPrenom(nvPrenom)
diagramme dactivites
Si le cas dutilisation nest pas un simple echange entre le syst`eme et lutilisateur, sil fait
intervenir plusieurs acteurs, il peut etre interessant de le decrire avec un diagramme
dactivites.
Les etats represente des actions. Les transitions assurent la chronologie des actions ;
quand lune est terminee, la suivante commence.
action 1 action 2
transition [condition]
Figure 4: exemple de diagramme dactivite (L. Audibert)
Figure 5: exemple de diagramme dactivite (L. Audibert)
diagramme dactivites
Les diagrammes dactivites permettent aussi de representer des ux de donnees. On
decore les actions par des pins indiquant les donnees necessaires aux actions ou produites
par les actions.
Enn, ces diagrammes peuvent representer le fait quune activite peut generer des
exceptions.
diagramme de sequence
Il decrit la decomposition dun scenario en operations.
Principe general : un objet re coit un message qui declenche une operation. Loperation a
un resultat qui constitue un message envoye `a un autre objet.
La numerotation des messages indique la chronologie. Le temps apparat aussi dans la
dimension verticale.
:individu
:Tresor public :Compta
t
d eclaration(salaires)
montant:=calcul(salaires)
imp^ ot(montant)
Les messages
Dans les diagrammes de communication et dans les diagrammes de sequence, la
communication se fait par envoi de messages. Voici la syntaxe des messages :
synchro/ garde s equence: iteration r esultat:= message (param` etres)
La synchronisation indique la liste des messages qui doivent etre envoyes avant que celui-ci
ne le soit.
La garde est une expression booleenne, une condition `a lenvoi du message.
La sequence est un numero qui indique le rang du message, cest-`a-dire son numero
dordre par rapport aux autres messages. Les messages sont numerotes `a la fa con de
chapitres dans un document, `a laide de chires separes par des points.
Literation permet de repeter un message. Il permet denvoyer ces messages en sequence
ou en parall`ele.
Et enn, on a les param`etres (optionnels) du message.
Les messages
La synchronisation permet dindiquer quun message doit attendre dautres messages. Il
existe une autre forme de synchronisation.
message simple : aucune caracteristique denvoi ou de reception particuli`ere.
message minute (timeout) : bloque lexpediteur pendant un temps donne (qui peut
etre specie dans une contrainte), en attendant la prise en compte du message par le
recepteur. Lexpediteur est libere si la prise en compte na pas eu lieu pendant le delai
specie.
message synchrone : bloque lexpediteur jusqu`a prise en compte du message par le
destinataire. Le ot de controle passe de lemetteur au recepteur (lemetteur devient
passif et le recepteur actif) `a la prise en compte du message. Lemetteur redevient
actif lorsquil re coit la reponse ou lorsque le destinataire a ni de traiter le message.
Cest le type de messages le plus utilise ; il correspond aux appels de procedure.
message asynchrone : ninterrompt pas lexecution de lexpediteur. Le message envoye
peut etre pris en compte par le recepteur `a tout moment ou ignore (jamais traite).
Les messages
:acteur
:class1 :class2
objet3
:class3
t
message1()
res:=message2()
message3(res)
message4(res)
Les messages
Dans le schema precedent, le message2 est un message synchrone. On peut supposer quil
sagit, par exemple, dun appel de fonction qui renvoie un resultat. Ce resultat est
memorise dans la variable res.
Un objet1 de la class1 qui enverra le message2 devra attendre la n du traitement du
message avant de poursuivre son execution. Le message3 ne pourra etre envoye quapr`es
retour du resultat.
Par contre, ce message3 est asynchrone. Il sera envoye `a lobjet3 de la class3 sans
soccuper de savoir sil est re cu, traite...
Et l objet1 enchanera en envoyant le message4.
Les messages
Les messages synchrones sont les plus frequents. On envoie un message et on attend sa
reponse.
Dans ce cas, les deux representations suivantes sont equivalentes.
:class1 :class2
res:=message2()
:class1 :class2
message2()
res
Les messages
:acteur
:class1
objet2:class2

message1()
create
message2()
destroy
Des messages speciques peuvent creer des instances dobjets ou les detruire.
Les fragments combines
UML 2.0 a introduit les fragments combines dans les diagrammes de sequence. Ils
permettent de decrire les scenarios de fa con plus compacte.
On peut ainsi decrire un scenario contenant des parties optionnelles, des parties
conditionnelles, des parties iterees.
On peut decrire des parties qui doivent absolument se succeder, sexecuter en parall`ele ou
encore des parties qui doivent se derouler sans interruption.
Il existe ainsi 12 operateurs de fragments.
Les fragments combines
:acteur
:class2 :class3
message1()
message2()
message3()
message4()
opt
La partie encadree est optionnelle.
Il est possible que lacteur envoie le message2. Dans ce cas, il faudra le traiter.
Mais il est aussi possible quil envoie directement le message4.
Les fragments combines
:class1 :class2 :class3
message1()
message2()
message3()
message4()
alt
[condition1]
[condition2]
La partie encadree est une alternative `a deux options ; il pourrait y en avoir plus.
Si la condition1 est veriee, on executera cette sous-partie.
Si la condition1 nest pas veriee, on examinera la condition2. On peut utiliser le terme
else pour executer la deuxi`eme sous-partie lorsque la condition1 nest pas veriee.
Les fragments combines
:class1 :class2 :class3
message1()
message2()
message3()
message4()
loop[5]
La partie encadree est repetee 5 fois.
Les fragments combines
:class1 :class2 :class3
message1()
message2()
message3()
message4()
critical
La partie encadree ne peut pas etre interrompue.
diagramme de communication ou diagramme de collaboration
Il decrit les communications entre objets, comme le diagramme de sequence.
Il insiste plus sur les objets, moins sur la chronologie.
Figure 6: exemple de diagramme de communication ou diagramme de collaboration (L.
Audibert)
diagramme des etats et transitions
Il decrit les changements detats dun objet. Une transition est un changement detat,
provoque par un evenement. La transition peut etre gardee par une condition.
On peut lui associer une action. Une action est une operation instantanee, sans
interruption.
On peut associer une activite `a letat. Une activite est une operation que fait lobjet
quand il est dans cet etat. Une activite peut etre interrompue.
etat
activite
etat
activite
transition [condition] / action
Figure 7: exemple de diagramme detats/transitions (L. Audibert)