Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2

Avancée

Université Abdelhamid Mehri – Constantine 2

2020-2021. Semestre 1

MODELISATION ORIENTEE OBJET AVANCEE (MOOA)

– Cours 5–
Chapitre 05 : Diagramme d’interaction

Staff pédagogique
Nom Grade Faculté/Institut Adresse e-mail
Gueraich Sonia MCB Nouvelles Technologies [email protected]

Etudiants concernés
Faculté/Institut Département Année Spécialité
Nouvelles Technologies TLSI Master1 Système d’Information et Technologie
Web (SITW)

Objectifs du cours 5
L’étudiant est censé comprendre et maitriser les notions liées aux diagrammes d’interaction UML2.

© Gueraich Sonia Page 1 sur 9

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

I. Introduction

Le diagramme de cas d’utilisation comme mentionné dans le chapitre 3 montre des acteurs qui interagissent
avec les grandes fonctions d’un système. C’est une vision fonctionnelle et externe d’un système. Le
diagramme de classes, quant à lui, décrit le cœur d’un système et montre des classes et la façon dont elles
sont associées. C’est une vision statique et structurelle.
Les diagrammes d’interaction permettent d’établir un pont entre ces deux approches : ils montrent comment
des instances au cœur du système communiquent pour réaliser une certaine fonctionnalité. Les interactions
sont nombreuses et variées. Il faut un langage riche pour les exprimer.
UML propose plusieurs diagrammes : diagramme de séquence, diagramme de communication, diagramme
global interaction. Ils apportent un aspect dynamique à la modélisation du système.

2. Définitions

Une interaction décrit le comportement d’un classeur en se focalisant sur l’échange d’informations
entre les éléments du classeur.
Les participants à une interaction sont appelés «lignes de vie ».
Une ligne de vie représente un participant unique à une interaction. Le terme « ligne de vie » est
utilisé car, souvent, les interactions montrent des objets (instances de classes). Au cours d’une
interaction, des objets peuvent être créés, utilisés, et parfois détruits. Ce cycle de vie des objets est
matérialisé par une ligne (la ligne de vie) qui court dans les diagrammes d’interaction (figure 5.1).
UML propose principalement deux diagrammes pour illustrer une interaction : le diagramme de
séquence et celui de communication. Une même interaction peut être représentée aussi bien par l’un
que par l’autre.
Les diagrammes de communication et de séquence représentent des interactions entre des lignes de
vie. Un diagramme de séquence montre des interactions sous un angle temporel, et plus
particulièrement le séquencement temporel de messages échangés entre des lignes de vie, tandis
qu’un diagramme de communication montre une représentation spatiale des lignes de vie.

Le diagramme de séquence de la figure 5.1 et le diagramme de communication de la figure 5.2 représentent

la même interaction.

Figure 5.1 Exemple d’un Un diagramme de communication

© Gueraich Sonia Page 2 sur 9

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Figure 5.2 Exemple d’un diagramme de séquence

Diagrammes de séquence et de communication peuvent représenter la même interaction, mais le point de vue
est différent. Un diagramme de séquence met l’accent sur le séquencement temporel des messages (le temps
y figure implicitement et s’écoule de haut en bas), En revanche, le lien qui unit les lignes de vie, et qui est le
vecteur du message, n’y figure pas (alors qu’il est présent sur un diagramme de communication).

3. Notation

Un diagramme d’interaction se représente par un rectangle (figure 5.3) contenant, dans le coin supérieur
gauche, un pentagone accompagné du mot-clé sd lorsqu’il s’agit d’un diagramme de séquence, et de com
lorsqu’il s’agit d’un diagramme de communication.

Figure 5.3 Exemple d’un diagramme de séquence d’un distributeur de billets

© Gueraich Sonia Page 3 sur 9

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Le mot-clé est suivi du nom de l’interaction. La liste des lignes de vie qui figurent dans le diagramme peut
suivre le nom de l’interaction. Des attributs peuvent être indiqués près du sommet du rectangle contenant le
diagramme. La syntaxe de ces attributs est la même que celle des attributs d’une classe (voir chapitre 4).
Une ligne de vie se représente par un rectangle auquel est accrochée une ligne verticale pointillée. Le
rectangle contient un identifiant dont la syntaxe est la suivante :

[<nomDeLaLigneDeVie> [’[’sélecteur’]’]] : <NomDeClasseur> [décomposition]

où le sélecteur permet de choisir un objet parmi n

4. Caractéristiques d’un diagramme de séquence

Les principales informations contenues dans un diagramme de séquence sont les messages échangés entre les
lignes de vie. Un message définit une communication particulière entre des lignes de vie. Plusieurs types de
messages existent.
Les plus communs 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. Exemple
typique de signal est une interruption E/S

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.
L’invocation peut être synchrone (l’émetteur reste bloqué le temps que dure l’invocation de l’opération) ou
asynchrone. Dans la pratique, la plupart des invocations sont synchrones.

Notation

Un message synchrone se représente par une flèche à l’extrémité pleine qui pointe sur le destinataire du
message (figure 5.4 à gauche). 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 (figure 5.4 au milieu).
La création d’un objet est matérialisée par une flèche qui pointe sur le sommet d’une ligne de vie (figure 5.4
à gauche). La destruction d’un objet est matérialisée par une croix qui marque la fin de la ligne de vie de
l’objet (figure 5.4 en dessous).

Figure 5.4 Notations de messages

4.1 Messages et évènements

L’invocation d’une opération ou l’envoi d’un signal peut déclencher une réaction chez le récepteur. La
réaction la plus courante est l’exécution d’une méthode (rappel : une méthode est l’implémentation d’une
opération). Ce n’est cependant pas la seule réaction possible. Par exemple, un signal d’erreur (souvent appelé

© Gueraich Sonia Page 4 sur 9

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

« exception ») peut être interprété comme une simple alerte qui ne déclenchera pas nécessairement
l’exécution d’une méthode.

UML permet de séparer clairement l’envoi du message de sa réception, ainsi que le début de l’exécution de
la réaction de sa fin. Des événements sont utilisés pour marquer chaque étape. La transmission d’un message
est contrôlée par l’occurrence de deux événements : un pour l’envoi et un pour la réception.
La figure 3.14 montre un diagramme d’interaction où un message envoyé provoque l’exécution d’une
méthode chez le récepteur.

Figure 5.5 Occurrences d’ »évènements

Grâce aux événements d’envoi et de réception, UML définit trois types de messages :
Un message complet est tel que les événements d’envoi et de réception sont connus.
Un message perdu est tel que l’événement d’envoi est connu, mais pas l’événement de réception.
Un message trouvé est tel que l’événement de réception est connu, mais pas l’événement d’émission.
Ces différents messages se représentent de la façon suivante.
Un message complet se représente par une simple flèche dirigée de l’émetteur vers le récepteur. Un message
perdu se représente par une flèche qui pointe sur une boule noire Une flèche qui part d’une boule noire
symbolise un message trouvé (figure).

Figure 5.6 Messages perdu et trouvé

Syntaxe des messages

© Gueraich Sonia Page 5 sur 9

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

UML permet de modéliser tout type de système. Mais bien souvent, les implémentations se font via des
langages de programmation. Dans la plupart des cas, la réception d’un message est suivie de l’exécution
d’une méthode d’une classe. Cette méthode peut recevoir des arguments et la syntaxe des messages permet
de transmettre ces arguments.

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> ]
Quand un message doit transmettre uniquement la valeur des arguments, le caractère – peut être utilisé en
lieu et place de n’importe quel argument pour signifier : valeur indéfinie. Le caractère * peut être utilisé en
lieu et place du message complet. Il signifie que tout type de message est accepté.

Le récepteur du message peut aussi vouloir répondre et transmettre un résultat via un message de retour. La
syntaxe de réponse à un message est la suivante :
[<attribut> ’=’] message [’:’ <valeur de retour> ]
où message représente le message d’envoi.

4.2 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 considérées comme invalides, alors
qu’une contrainte qui se vérifie rend valides les événements à suivre (figure 5.7).

Figure 5.7 Exemple d’une contrainte sur une ligne de vie

© Gueraich Sonia Page 6 sur 9

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Dans la figure pour démarrer le moteur d’un avion, il est impératif de vérifier le
niveau d’essence ; après vérification l’attribut essence doit avoir une valeur supérieure à 0.

4.3 Primitives

Les langages de programmation sont limités par leur syntaxe. Ils permettent d’écrire des tests et des boucles
très simplement. 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.
La figure 5.8 montre comment une boucle peut être représentée.

Figure 5.8 Exemple d’une boucle

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é
».
L’opérateur par permet d’envoyer des messages en parallèle. Ses opérandes se déroulent en parallèle.
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.
La syntaxe de l’opérateur ignore est :
ignore { listeDesNomsDesMessagesAIgnorer }
La syntaxe de l’opérateur consider est :
consider { listeDesNomsDesMessagesAConsidérer }

© Gueraich Sonia Page 7 sur 9

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Dans les listes, les messages sont séparés par des virgules.
Réutiliser une interaction consiste à placer un fragment portant la référence ref là où l’interaction est
utile. La syntaxe complète pour spécifier l’interaction à réutiliser est la suivante :
[ <nomAttributPourValeurRetour> ’=’] <nom de l’interaction>
[’(’ [<argument>]’,’ … ’)’ ] [’:’ <valeur de retour> ]
La valeur de retour est affectée à un attribut. Les arguments peuvent être en entrée (ils portent alors la
marque in), en sortie (out), ou en entrée et en sortie
(inout).

4.4 Les états invariants

Une ligne de vie peut aussi représenter un classeur ayant un comportement complexe. C’est le cas des
instances de classes qui peuvent être dans plusieurs états (voir chapitre 6). Il est possible de placer un certain
état d’une machine à états sur une ligne de vie. Un état est dit « invariant » lorsqu’il reste constant sur une
ligne de vie, c’est-à-dire lorsqu’il ne change pas quel que soit le contexte d’exécution de l’interaction. La
figure 5.9 montre un état placé sur une ligne de vie. Au moment de l’exécution de l’interaction,l’état est testé
conformément à la machine à états spécifiée.

Figure 5.9 Etats invariants

5. Caractéristiques d’un diagramme de séquence communication

Les diagrammes de communication servent le plus souvent à illustrer un cas d’utilisation ou à décrire une
opération. Un diagramme de séquence montre un séquencement temporel des messages (le temps s’écoule de
haut en bas). Par contre, l’organisation spatiale des participants à l’interaction n’apparaît pas. Un diagramme
de communication est un autre moyen de décrire une interaction. Il rend compte des relations entre des lignes
de vie qui communiquent. Il représente des interactions du point de vue spatial.
Les diagrammes de communication sont proches des diagrammes de classes auxquels ils ajoutent un aspect
dynamique en montrant des envois de messages. Cependant, les relations entre les lignes de vie sont appelées
« connecteurs» alors qu’elles se nomment « associations» dans les diagrammes de classes. Un connecteur se
représente de la même façon qu’une association mais la sémantique est plus large
Un diagramme de communication contient des lignes de vie, à l’instar des diagrammes de séquence : elles
représentent toujours des participants uniques à une interaction.
Les lignes de vie sont représentées par des rectangles contenant une étiquette dont la syntaxe est :
<nomDuRôle> : <NomDuType>

© Gueraich Sonia Page 8 sur 9

Modélisation Orientée Objet 2020-2021 – Semestre 1 Université Constantine 2
Avancée

Au moins un des deux noms doit être mentionné dans l’étiquette (si le nom du rôle est omis, le caractère : est
obligatoire).
Le rôle permet de définir le contexte d’utilisation de l’interaction.

Figure 5.10 Eléments d’un diagramme de communication

6. Caractéristiques d’un diagramme global interaction

Il donne une vue d’ensemble des interactions en combinant des diagrammes d’activités et des diagrammes de
séquences en mettant l’accent sur les liaisons des données entre les différents participants à l’interaction.
Ce type de diagramme permet d’avoir une vue globale des interactions entre objets

7. Conclusion

Les diagrammes de séquence et de communication montrent l’aspect dynamique d’un système. Ils sont
mieux appropriés à la description des interactions entre les éléments d’un système. Les diagrammes
d’activité et les diagrammes d’états-transitions, présentés aux chapitres suivants, décrivent eux aussi un
système dynamique mais avec moins d’interaction.

© Gueraich Sonia Page 9 sur 9