Vous êtes sur la page 1sur 22

Chapitre 3 : UML

1. UML: Unified Modeling Language


UML est le résultat du travail initié par G. Booch et J. Rumbaugh en 1994. L’objectif de ce
travail était d’unifier les méthodes de modélisation de:
Booch
OMT de Rumbaugh
OOSE de Jacobson
La Version 1.0 d’UML apparaît en Janvier 1997.
L ’OMG a adopté UML comme langage de modélisation

1.1. Objectifs de UML


Les objectifs d’UML sont :
Modéliser des systèmes divers en utilisant des concepts orientés objets
Établir un couplage entre les concepts et leur implantation
Aborder la description des problèmes d’échelle propres aux systèmes complexes
Offrir une approche de description utilisable par les humains et les machines

1.2. Usages de UML


Systèmes d’information pour la présentation d ’informations diverses à des usagers
Systèmes techniques pour la commande d’équipements
Systèmes temps-réel embarqués
Systèmes répartis sur des réseaux (locaux ou non)
Systèmes logiciels (exploitation, bases de données, interfaces GUI, …etc.)
Systèmes commerciaux (description de la structure et du fonctionnement des entreprises: règles,
stratégies, politiques, …etc.)

1.3. Étapes de développement d’un système


← Analyse des besoins: recherche des points fonctionnels (Use Cases)
← Analyse (recherche des abstractions principales composant le système: classes et objets)
← Conception des abstractions principales et implantation d’abstractions secondaires
← Programmation des abstractions dans un langage orienté objet
← Tests du système

1
2. Types de visualisation dans UML

2.1. Visualisation « Use Cases »


Les cas d’utilisation (Use cases) décrivent la fonctionnalité d’un système. Ces diagrammes
s’adressent aux clients, concepteurs, responsables du développement, responsables des tests
Un Use Case décrit un point fonctionnel du système et le fonctionnement global du système est
décrit par l’ensemble des Use Cases

2.1.1. Use Cases dans UML


Les use cases sont représentés par une ellipse dans laquelle est inscrit le nom du Use Case
Ils sont généralement connectés à un acteur avec une association

2.1.2. Liens entre Use Cases


« extends » signifie qu’un Use Case est une spécialisation d’un autre Use Case plus général.
L’Use Case plus spécifique n’inclut pas nécessairement tout le comportement du Use Case qu’il
spécialise
« uses » signifie qu’un Use Case utilise intégralement la fonctionnalité du Use Case plus général
en plus de lui ajouter des fonctionnalités additionnelles

2
2.1.3. Description d’un Use Case
Un use case est décrit par :
Ses Objectifs
Le Flot des messages entre l’acteur et le Use Case
Le Flot secondaire des messages entre l’acteur et le Use Case
Les Condition de fin pour le Use Case et information retournée à l ’acteur lors qu’il se termine

2.1.4. Qu’est-ce qu’un bon Use Case


Un bon Use Case représente une fonctionnalité du système qui est complète du début jusqu’à la
fin. Il doit normalement apporter quelque chose de valable à un acteur (i.e. un résultat tangible à
une de ses commandes ou à une de ses actions sur le système).
Il n’y a pas de consensus sur la « grosseur » que devrait prendre un Use Case en termes de
fonctionnalité.

2.2. Visualisation « Logique »


Il existe deux types visualisation logique : Visualisation statique et Visualisation dynamique
La visualisation statique est décrite par les diagrammes de classes et d’objets.

La visualisation dynamique est décrite par les diagrammes d’états, séquentiels (de séquence), de
collaboration et d’activité

2.2.1Vision statique

2.2.1.1. Diagrammes de classes


Classes et objets :
Une classe sert à décrire de manière générique une catégorie d’objets participant aux actions du
système
Un objet est relié à une classe de la même manière qu’une variable est associée à un type de
données dans un langage de programmation procédural
Les fondements de la programmation orientée objet sont les classes, les objets, et les relations
entre eux.
Ces classes, objets, et relations sont représentés par des diagrammes en langage UML

Le diagramme de classes est un modèle statique du système qui décrit le système en termes de
ses classes et des relations entre celles-ci. Il sert de base aux autres diagrammes où d’autres

3
facettes du système sont décrites (tels les diagrammes d ’états des objets ou les diagrammes de
collaboration qui sont des diagrammes dynamiques)

Recherche des classes


La recherche des classes est une étape de création.
Pour trouver les classes pertinentes à un problème, il faut se poser les questions suivantes:
– Est-ce qu’une information doit être analysée ou stockée?
– Est-ce que le système interagit avec d’autres systèmes?
– Existe-t-il des patrons, des librairies, ou des composantes réutilisables dans le système?
– Le système doit-il manipuler des périphériques (devices)?
– Quels rôles les acteurs jouent-ils?
– Le système possède-t-il des pièces structurales (parts)?

Types classiques de classes


Entity: servent à modéliser des catégories d’objets qui ont une durée de vie importante dans le
système (i.e. elles sont des parties intégrantes du système)
Boundary: servent à faciliter la communication des classes Entity avec l’extérieur du système
(soit un autre système, avec l’utilisateur ou encore avec un périphérique)
Control: servent à coordonner les échanges de messages entre les autres classes pour réaliser un
Use case

Représentation des classes en UML


Une classe est représentée par un rectangle divisé en trois compartiments:
– le compartiment du nom
– le compartiment des attributs
– le compartiment des méthodes (opérations)

La syntaxe dans les différents compartiments est indépendante des langages de programmation

a. Compartiment de nom
 Il contient le nom de la classe.
 Il est centré dans le compartiment.
 Il est imprimé en caractères gras.
 Le nom ne doit pas être ambigu et doit être tiré du domaine propre au problème.

b. Compartiment des attributs


Les attributs servent à décrire les caractéristiques des objets appartenant à la classe (i.e.
décrivent l’état de l ’objet)
Chaque attribut possède:
 Un type (primitif ou défini par l’usager)
 Un niveau de visibilité (public (+), protected (#) ou private (-))
 Une valeur par défaut

4
Optionnellement, on peut aussi indiquer qu’un attribut possède une portée s’appliquant à la
classe (class scope) ou une chaîne de propriétés indiquant les valeurs que peut prendre
l’attribut.
Exemples de classe avec attributs

c. Compartiment des opérations


Les opérations permettent de manipuler les attributs et d’effectuer d’autres actions. Elles sont
appelées pour des instances (objets) de la classe.
 La signature des opérations comprend:
 un type de retour
 un nom
 0 ou plus paramètres (ayant chacun un type, un nom et possiblement une valeur par
défaut)
 une visibilité (private(-), protected(#), public(+))
Les opérations constituent l’interface de la classe avec le monde extérieur

Exemple de classe avec opérations

Spécification de l’opération
Une méthode (opération) est spécifiée par :
 les Pré-conditions: doivent être vérifiées avant que l’algorithme ne s’exécute
 les Post-conditions: doivent être vraies une fois l’opération complétée
 l’Algorithme: effet que l’opération a sur l’objet

Relations entre les classes


Un diagramme de classes montre les classes d’un système mais également les relations entre
celles-ci.
On compte quatre principales catégories de relations entre classes :
–les associations
–les généralisations (héritage)
–les dépendances

5
–les raffinements

Les associations de classes


Il existe plusieurs types d’associations:
 normale
 récursive
 agrégation par référence
 agrégation par composition

a. Association normale
Une association normale est une connexion entre classes.
- Elle possède un nom.
- Elle est généralement navigable de manière bidirectionnelle (dans ce cas elle a un nom
dans les deux sens si nécessaire)
- Elle a une multiplicité
- Elle peut être dotée de rôles

b. Association récursive
Une classe peut être connectée à elle-même via une association récursive. Elle représente une
connexion sémantique entre des objets mais avec la différence que ceux-ci appartiennent à la
même classe

c. Agrégation par référence


Elle indique une relation tout-partie. Elle se représente par une ligne avec un losange du côté
« tout » de l’agrégation. Ce losange ne peut apparaîtra qu’à une seule extrémité.
Une agrégation par référence possède des rôles, multiplicité, …etc., comme une association
normale.

d. Agrégation par composition

6
Elle indique une relation tout-partie avec inclusion « physique ». Elle se représente par une ligne
avec un losange plein du côté « tout » de l’agrégation. Ce losange ne peut apparaîtra qu’à une
seule extrémité.
Une agrégation par composition possède des rôles, multiplicité, …etc., comme une association
normale

Les généralisations de classes


Une généralisation est une relation entre une classe générale et une classe plus spécifique.
La classe spécifique est appelée sous-classe et la classe générale est appelée super-classe.
La sous-classe hérite des attributs et opérations de la super-classe (en fonction de la visibilité de
la généralisation)
une sous-classe peut être la super-classe d’une autre classe dans ce que l’on appelle une
hiérarchie

Représentation des généralisations


On représente les généralisations par une flèche allant de la classe spécifique à la classe
générale.
Lorsqu’une classe spécifique hérite de plusieurs super-classes, on parlera d’héritage multiple

Les Interfaces
Les interfaces sont des classes contenant seulement des opérations sans implantation.
Une classe peut implanter une interface.
Le symbole d’implantation est une flèche pointillée allant de la classe vers l ’interface
Ici, la classe A implante les interfaces Storable et Runnable et B utilise ces implantations

7
2.2.1.2. Les Packages
Pour les systèmes comprenant plusieurs classes, il convient de regrouper celles-ci en entités
logiques, les packages
Un package est un ensemble de packages et de classes reliés sémantiquement entre eux.
Chaque package est muni d’une interface (ses classes public) qui lui permet de communiquer sa
fonctionnalité aux autres packages qui peuvent l’importer
Un package est représenté par un dossier (folder).
Les Packages ont eux aussi un niveau de visibilité est des relations qui sont ici: la dépendance, le
raffinement, et la généralisation

2.2.1.3. Les Templates


UML supporte les templates (aussi appelés « parameterized classes ») qui sont symbolisés par
un symbole de classe avec un ajout identifiant le fait que le template doit être « instancié » avant
de pouvoir créer des objets de la classe correspondant au template

2.2.1.4. Qualités d’un modèle statique


Un bon modèle statique doit répondre aux questions suivantes :
Le modèle peut-il être communiqué aux autres membres de l’équipe de même qu’au client ?

8
Le modèle a-t-il une utilité pour décrire le système?
Le modèle embrasse-t-il les caractères essentiels du système (permet-il entre autres de bien
répéter les use-cases?
Les noms des classes du modèle reflètent-ils les noms des éléments du système (i.e. les noms
sont-ils pertinents)?
Des modèles différents de la même chose sont-ils intégrés et coordonnés entre eux?
Les modèles sont-ils simples (même pour les systèmes complexes)?

9
2.2.2. Visualisation « Dynamique »
La modélisation dynamique sert à montrer comment les objets d’un système collaborent pour
réaliser une fonctionnalité du système. Elle montre comment les objets s’échangent des
messages (i.e. comment un objet, le client, invoque une opération sur un autre objet, le serveur).
Ces échanges sont appelés interactions.
Les interactions sont montrées via trois principaux diagrammes: séquence, collaboration,
activité.
Un autre diagramme, le diagramme d’état décrit le comportement d’un objet mais cette fois-ci
pris isolément.

Diagramme d’états: décrit les états que peut prendre un objet durant son cycle d’existence et le
comportement de ces états de même que les événements qui provoquent un changement d’état
de l’objet
Diagramme séquentiel : montre comment les objets interagissent et communiquent entre eux
pour accomplir une tâche du système. La variable indépendante est ici le temps.
Diagramme de collaboration: montre comment les objets interagissent et communiquent entre
eux pour accomplir une tâche du système. La variable indépendante est ici le l’espace. Par espace
on entend ici les relations (liens) entre les objets dans le système.
Diagramme d’activité: montre comment les objets interagissent et communiquent entre eux
pour accomplir une tâche du système. La variable indépendante est ici le travail accompli par les
objets.

Interactions entre les objets (messages)


En programmation orientée objet, les interactions entre les objets sont modélisées comme des
messages envoyés d’un objet à un autre. Ces messages sont simplement des appels d’opérations
d’un objet par un autre avec le contrôle qui revient à l’objet appelant avec une valeur de retour

1. synchrone: l’objet appelant transmet le message et attend la réponse (i.e. la valeur de retour de
l’opération appelée) avant de poursuivre son activité;
2. asynchrone: l’objet appelant transmet le message et n’attend pas la réponse (i.e. la valeur de
retour de l’opération appelée) avant de poursuivre son activité. Cela implique par exemple que les
objets peuvent s’exécuter sur des threads différents.
3. simple: message dont on ne spécifie pas la nature exacte (synchrone ou asynchrone);
4. synchrone avec retour immédiat: cas spécial de message synchrone pour lequel l’attente de la
réponse du serveur est négligeable.

10
2.2.2.1. Les diagrammes de séquence
Ils illustrent comment les objets interagissent entre eux. Ils se concentrent sur la séquence des
messages envoyés entre les objets (c’est-à-dire comment et quand les messages sont envoyés et
reçus entre les objets)
Ils possèdent deux axes: l’axe vertical montre le temps tandis que l’axe horizontal montre
l’ensemble des objets en interaction dans un scénario ou une scène spécifique d’un scénario.
Les diagrammes de séquence peuvent être utilisés sous deux formes:
– forme générique: elle décrit tous les déroulements possibles d’un scénario et peut contenir des
branchements, des conditions, et des boucles.
– forme d’instanciation: elle décrit le comportement du système pour un aspect spécifique d’un
scénario et ne peut donc contenir aucun branchement et aucune condition ou boucle.

Les messages dans les diagrammes séquentiels


Ils représentent une communication entre objets véhiculant une information avec l’anticipation
qu’une action sera entreprise.
La réception d’un message est généralement appelée événement.
Les messages ...
Quand un objet reçoit un message, on dit qu’il entre dans sa phase d’activation. Un objet dans
cette phase peut:
– exécuter son propre code
– attendre les résultats retournés par un autre objet à qui il a envoyé un message
L’activation d’un objet est représentée par un rectangle étroit sur la ligne de vie de l’objet

Les messages les plus communs qu’un objet peut recevoir sont :
• l’envoi d’un signal ;
• l’invocation d’une opération ;
• la création ou la destruction d’une instance.
L’envoi d’un signal déclenche une réaction chez le récepteur, de façon asynchrone et sans
réponse : l’émetteur du signal ne reste pas bloqué le temps que le signal parvienne au récepteur et
il ne sait pas quand, ni même si le message sera traité par le destinataire.

11
Plus encore que l’envoi d’un signal, l’invocation d’une opération est le type de message le plus
utilisé en programmation objet. Si, par exemple, une classe C possède une opération op,
l’invocation se fait par c.op(), où c est une instance de la classe C.

Notation
Un message synchrone se représente par une flèche à l’extrémité pleine qui pointe sur le
destinataire du message. Ce message peut être suivi d’une réponse qui se représente par une
flèche en pointillé.
Un message asynchrone se représente par une flèche à l’extrémité ouverte.
La création d’un objet est matérialisée par une flèche qui pointe sur le sommet d’une ligne de
vie.
La destruction d’un objet est matérialisée par une croix qui marque la fin de la ligne de vie de
l’objet.

Règles de cohérence (well-formedness rules)


– Chaque objet dans le diagramme de séquence doit être instance d'une classe dans le diagramme
de classe
– Chaque message dans le diagramme de séquence doit correspondre à une opération dans le
diagramme de classe
– ...

SYNTAXE DES MESSAGES


La syntaxe des messages est :
<nomDuSignalOuDeOpération> [’(’ [<argument>’,’ … ’)’]
où la syntaxe des arguments est la suivante :
[ <nomDeParamètre> ’=’ ] <valeur de l’argument>
Par défaut, les paramètres transmis ne peuvent pas être modifiés par le récepteur (les arguments
sont « en entrée »). Pour indiquer que des paramètres peuvent être modifiés (argument « en sortie
» ou « en entrée/sortie »), il faut écrire :
<nomDuParamètreEnSortie> [’:’ <valeur de l’argument> ]
Exemple
Appeler( "Capitaine Hadock", 54214110 )
afficher( x, y )
initialiser( x = 100 ) est un message dont l’argument en entrée reçoit la valeur 100.
f( x :12 ) est un message avec un argument en entrée/sortie x qui prend initialement la valeur 12.

La syntaxe de réponse à un message est la suivante :


[<attribut> ’=’] message [’:’ <valeur de retour> ] où message représente le message d’envoi.
Exemple
nombreLivres = chercher( "Tintin" ) : 42

CONTRAINTES SUR LES LIGNES DE VIE


Une contrainte est indiquée sur une ligne de vie par un texte entre accolades.
Une contrainte peut aussi être contenue dans une note attachée à l’occurrence de l’événement sur
lequel elle agit.
Une contrainte est évaluée au cours de l’exécution de l’interaction. Si la condition de la
contrainte n’est pas vérifiée, les occurrences d’événement qui suivent cette contrainte sont

12
considérées comme invalides, alors qu’une contrainte qui se vérifie rend valides les événements à
suivre.

FRAGMENTS D’INTERACTION COMBINÉS


Un fragment combiné se représente de la même façon qu’une interaction : par un rectangle dont
le coin supérieur gauche contient un pentagone. Dans le pentagone figure le type de la
combinaison (appelé « opérateur d’interaction »).
Les opérandes d’un opérateur d’interaction sont séparés par une ligne pointillée. Les conditions
de choix des opérandes sont données par des expressions booléennes entre crochets.
La liste suivante regroupe les opérateurs d’interaction par fonctions :
• les opérateurs de choix et de boucle : alternative, option, break et loop ;
• les opérateurs contrôlant l’envoi en parallèle de messages : parallel et critical region ;
• les opérateurs contrôlant l’envoi de messages : ignore, consider, assertion et negative ;
• les opérateurs fixant l’ordre d’envoi des messages : weak sequencing, strict sequencing.

Opérateur alt
l’opérateur d’interaction alt indique que le fragment est un choix. Les deux options de choix sont
appelées « opérandes de l’opérateur alt ».

13
Opérateur Loop
La syntaxe d’une boucle est la suivante :
loop [’(’ <minint> [’,’ <maxint> ] ’)’ ]
où la boucle est répétée au moins minint fois avant qu’une éventuelle condition booléenne ne soit
testée (la condition est placée entre crochets sur la ligne de vie) ; tant que la condition est vraie, la
boucle continue, au plus maxint fois (minint est un entier supérieur ou égal à 0, maxint est un
entier supérieur ou égal à minit).
loop( valeur ) est équivalent à loop( valeur, valeur ).
loop est équivalent à loop( 0, * ), où * signifie « illimité »

Opérateur par

14
L’opérateur par permet d’envoyer des messages en parallèle. Ses opérandes se déroulent en
parallèle.

Opérateur ignore et consider


Les opérateurs ignore et consider permettent de focaliser l’attention du modélisateur sur une
partie des messages qui peuvent être envoyés durant une interaction. Quand de nombreux
messages sont possibles, certains sont importants, d’autres moins.
L’opérateur ignore définit l’ensemble des messages à ignorer, tandis que l’opérateur consider
définit l’ensemble de ceux qu’il faut prendre en compte.

La syntaxe de l’opérateur ignore est :


ignore { listeDesNomsDesMessagesÀIgnorer }
La syntaxe de l’opérateur consider est :
consider { listeDesNomsDesMessagesÀConsidérer }
Dans les listes, les messages sont séparés par des virgules.

Opérateur strict sequencing


L’opérateur strict sequencing impose que ses opérandes se déroulent dans l’ordre strict de leur
présentation, c’est-à-dire de haut en bas.

15
DÉCOMPOSITION D’UNE LIGNE DE VIE
Une décomposition est référencée dans le rectangle en tête de ligne de vie, sous le label ref.
À la figure 3.26, la ligne de vie PointDAccès est décomposée en deux lignes p1 et p2.
Cette notation est une autre manière de décomposer une ligne de vie dans un diagramme
d’interaction.

16
Une porte est un point de connexion qui permet de relier un même message représenté par des
flèches différentes dans plusieurs fragments d’interaction.

Exercice
Le programme suivant, écrit en pseudo-code, permet de calculer le factoriel d’un nombre n :
int factoriel( int n ){
if( n == 0 ) return 1;
return n * factoriel( n-1) ;
}
où n 0 et factoriel( 0 ) = 1.
Représentez le programme précédent sur un diagramme de séquence.

Corrigé

17
2.2.2.2. Les diagrammes de collaboration
Tout comme un diagramme de séquence, un diagramme de collaboration décrit le déroulement
d’une interaction entre plusieurs objets.
Sur un diagramme de collaboration, les objets constituent les nœuds d’un graphe dont les arcs
correspondent aux actions (i.e., l’envoi de messages, l’instanciation et la destruction d’objets). Le
temps n’est pas associé à une dimension particulière du diagramme, mais la chronologie de
l’interaction est exprimée par des numéros de séquence qui accompagnent les actions.

Les diagrammes de collaboration montrent les interactions et les liens entre un ensemble d’objets
participant à un scénario.
Ils focalisent leur attention sur l’aspect spatial des interactions.
Ils sont particulièrement utiles pour montrer la réalisation des use-cases (sans que les aspects
temporels des interactions ne soient nécessairement rendus explicites).
Les objets sont dessinés comme des classes mais leurs noms sont soulignés.
Les liens sont illustrés par des lignes (qui ressemblent à des lignes d’associations dans les
diagrammes de classes mais sans les informations de multiplicité).
Un lien entre deux objets dénote l’envoi d’un message ou une action d’instanciation ou de
destruction.
Un message, accompagné d’une étiquette, peut être associé à un lien pour montrer le sens et
l’ordonnancement de la transmission du message.

18
Les étiquettes des liens sont similaires à celles des transitions d’un diagramme de séquence. Elles
sont cependant préfixées d’un numéro de séquence qui précise l’ordre dans lequel les actions sont
effectuées. Ces numéros peuvent être imbriqués afin de mettre en évidence la structure de
l’interaction.

NUMÉROS DE SÉQUENCE DES MESSAGES


Dans un diagramme de communication, les messages peuvent être ordonnés selon un numéro de
séquence croissant. Quand plusieurs messages sont envoyés en cascade (par exemple quand une
procédure appelle une sous-procédure), ils portent un numéro d’emboîtement qui précise leur
niveau d’imbrication.

Exemple 1

Exemple pour l’ascenseur : Classes

Exemple pour l’ascenseur : Collaboration

19
Exemple 2
Exemple de gestion des commandes.

SYNTAXE DES MESSAGES


Les diagrammes de séquence permettent de représenter divers opérateurs (choix, boucle…) dans
des fragments combinés. Il n’est pas permis d’utiliser les fragments combinés dans un diagramme
de communication. Malgré tout, des choix et des boucles peuvent y figurer selon une syntaxe
particulière.
* [ <clause d’itération> ] représente une itération. La clause d’itération peut être exprimée dans le
format i := 1…n.
[ <clause de condition> ] représente un choix. La clause de condition est une condition
booléenne.

La syntaxe complète des messages est (voir les exemples ci-après) :


[ <numéro_séquence> ] [ <expression> ] : <message>

20
où message a la même forme que dans les diagrammes de séquence, numéro_séquence représente
le numéro de séquencement des messages tel qu’il a été défini précédemment et expression
précise une itération ou un embranchement.

Exemple
2 : affiche( x, y ) est un message simple.
1.3.1 : trouve("Hadock" ) est un appel emboîté.
4 [x < 0] : inverse( x, couleur ) est un message conditionnel.
3.1 *[i :=1..10] : recommencer() représente une itération.

Le branchement
Les différentes branches d’un choix conditionnel sont repérées par le même numéro de séquence
auquel on ajoute un suffixe propre à la branche (e.g., 2a, 2b, 2c, . . . ).
Exemple :

Les liens dans les diagrammes de collaboration


Le rôle de chaque objet peut être inclus aux extrémités de la connexion avec les qualificatifs du
lien (rappel: les rôles et qualificatifs sont aussi inclus dans le diagramme de classe)
Le stéréotype du lien peut aussi être inclus dans la connexion.
On compte les stéréotypes suivants: global, local, parameter, self, vote, broadcast

Les stéréotypes de liens


Global: associé à un rôle du lien pour montrer que l’instanciation en présence est globale (visible
dans tout le système). Le récepteur est un objet global. Ceci se produit lorsque la référence à
l’objet peut être obtenue à l’aide d’une méthode statique. Le stéréotype à utiliser est «global», ou
[G].
Local: associé à un rôle du lien pour montrer que l’instanciation est une variable locale dans une
opération. Le récepteur est contenu dans une variable locale de la méthode émettrice. Ceci se
produit fréquemment lorsque l’objet a été créé par la méthode émettrice ou lorsqu’un résultat
précédent a retourné un objet. Le stéréotype à utiliser est «local» ou [L].

21
Parameter: montre que l’instance est visible parce que c’est un paramètre d’une opération. Une
référence à l’objet récepteur a été reçue comme paramètre par la méthode émettrice. Le
stéréotype à utiliser est «parameter» or [P].
Self: montre qu’un objet peut s’envoyer des messages
Vote: contrainte imposée à un message limitant l’éventail des valeurs de retour (spécifie que la
valeur de retour est choisie au vote majoritaire entre différentes valeurs de retour)
Broadcast: contrainte appliquée à un ensemble de messages pour signifier qu’ils ne sont pas
exécutés dans un ordre donné.

Exemple

On remarque que, contrairement au diagramme séquentiel, le diagramme de collaboration inclut


un objet de la classe File. En effet, dans l’interaction des objets de ce point fonctionnel, l’objet
de la classe File ne reçoit aucun message et il n’est donc pas pertinent de le montrer dans le
diagramme séquentiel. Par contre, l’objet de la classe File intervient dans la collaboration soit
en tant qu’objet global que comme paramètre dans des messages. Le diagramme de collaboration
rend explicite la présence de l’objet de la classe File et montre comment il intervient dans la
collaboration. On remarque également les étiquettes avec leur numéro accompagnant les liens
entre les objets d’une collaboration1. Il convient de remarquer que la classe File possède des
liens avec les autres classes dans le diagramme de classes, ce qui permet d’inclure les mêmes
liens entre les objets du diagramme de collaboration pour le point fonctionnel illustrant
l’impression d’un fichier.

22