VI.
DIAGRAMME DE SEQUENCES
● 1. Présentation
● 2. Les objets
● 3. Ligne de vie d'un objet
● 4. Les messages
● 5. Quelques séquences
● 6. Fragments d'interactions combinées
● 7. Exercice d'application
1. Présentation
Le diagramme de séquence
● Fait parties des diagrammes
comportementaux (dynamique) et plus
précisément des diagrammes
d’interactions.
● Permet de représenter des échanges entre
les différents objets et acteurs du système
en fonction du temps.
1. Présentation (suite)
● Décrit la réalisation des cas d'utilisation sur le
système décrit par le diagramme de classes
- Description du point de vue interne sur le
fonctionnement du système
- Description au niveau de l'instance (état du
système à un instant)
- Description de scénarios particuliers
- Représentation des échanges de messages entre
les acteurs et le système et entre les objets du
système de façon chronologique
1. Présentation (suite)
Le diagramme de séquence
● Est placé dans un rectangle qui dispose d’une
étiquette sd en haut à gauche (qui signifie
sequence diagramm) suivi du nom du diagramme.
● Les éléments du diagramme de séquence sont les
suivants :
- Les objets : Instances de classes
- Les messages: Méthodes des classes receptrices
- Les lignes de vie (objet) et le bloc d'activation
(opération)
1. Présentation (suite)
NB :
● A moins que le système à modéliser soit
extrêmement simple, on ne peut pas modéliser
la dynamique globale du système dans un seul
diagramme de séquence.
● Il faut donc faire appel à un ensemble de
diagrammes de séquences, chacun
correspondant à une sous fonction du système
2. Les objets
L'objet
● Entité appartenant au système ou se trouvant à
ses limites
● Il représente:
- Les acteurs
- Les concepts abstraits (cas d’utilisation)
- Les objets d’implantation (interactions
“informatiques”)
2. Les objets (suite)
Les objets
● Sont identifiés par l’intermédiaire
- Des cas d’utilisation
- Ou des diagrammes de classe
● En UML, les objets sont représentés comme suit :
- Le nom de l’objet est composé de son rôle (ou
nom) et/ou du nom de la classe instanciée (classe)
- Le nom est souligné pour indiquer qu’il s’agit d’une
instance
2. Les objets (suite)
● A la même représentation que dans le diagramme d'objets.
C'est-à-dire un rectangle dans lequel figure le nom de
l’objet, il est généralement souligné et peut prendre l’une
des formes suivantes :
● On retrouve aussi la représentation du stickman (qui peut
être considéré comme un objet)
3. Ligne de vie d'un objet
● Le diagramme de séquence fait apparaître les instances
des classes
● A chaque instance est associée une ligne de vie,
Une ligne de vie
● Est une ligne verticale (en pointillé) en dessous des
objets, qui montre la période de temps durant laquelle
l’objet “existe”
● Elle indique les périodes d’activité de l’objet
(généralement, les moments ou l’objet exécute une de
ces méthodes).
● Lorsque l’objet est détruit, la ligne de vie s’achève par un
croix
3. Ligne de vie d'un objet (suite)
4. Les messages
Un message
● Définit une communication particulière
entre des lignes de vie.
● C'est une communication d’un objet vers
un autre objet.
● La réception d’un message est considérée
par l’objet récepteur comme un événement
qu’il faut traiter (ou pas).
4. Les messages (suite)
● Les objets communiquent en échangeant
des messages représentés sous forme de
flèches
● Ces messages sont étiquetés par le nom
de l’opération ou du signal invoqué.
4. Les messages (suite)
Plusieurs types de messages existent, les plus
communs sont :
● L’invocation d’une opération : Message
synchrone (appel d’une méthode de l’objet
cible).
● L’envoi d’un signal : Message asynchrone
(typiquement utilisé pour la gestion
événementielle).
● La création ou la destruction d’une instance
de classe au cours du cycle principal.
4.1. Messages et activation
Une période d’activité
● Correspond au temps pendant lequel un objet
effectue une action directe ou indirecte
● Représentation : bande verticale le long de la
ligne de vie de l’objet
4.2. Messages synchrones
● La réception d’un message synchrone doit
provoquer chez le destinataire le lancement
d’une de ses méthodes (qui souvent porte le
même nom que le message).
● L’expéditeur du message reste bloqué pendant
toute l’exécution de la méthode et attend donc la
fin de celle-ci avant de pouvoir lancer un
nouveau message
4.3. Messages asynchrones
● Dans le cas d’un message asynchrone,
l’expéditeur n’attend pas la fin de l’activation
de la méthode invoquée chez le destinataire.
Un message asynchrone peut être :
● Un appel de méthode : Fréquent dans un
système multi-threads (multi-tâche). Ainsi,
l’objet expéditeur n’étant pas bloqué pendant
l’exécution de la méthode, il peut continuer
ainsi à envoyer d’autres messages.
4.3. Messages asynchrones (suite)
Un message asynchrone peut également
être :
● Un signal (cas le plus fréquent) : L’objet
expéditeur transmet juste une information à
l’objet destinataire.
● Souvent, ce sont les acteurs ou les
périphériques qui envoient des signaux,
typiquement utilisé dans la gestion
événementielle d’une IHM graphique
4.4. Représentation des messages
● Dans le diagramme de séquence, les envois de
messages sont représentés par des flèches
horizontales qui vont de la ligne de vie de l’objet
émetteur vers la ligne de vie de l’objet récepteur
du message.
● Les messages synchrones : flèche avec un
triangle plein à son extrémité.
● Les messages asynchrones : simple flèche
● Les messages retour (réponses) : simple
flèche en pointillés.
4.4. Représentation des messages
(suite)
● Si une méthode qui a été activée (par un message) doit
retourner des valeurs à la fin de son activation, cela se fait
par un message retour.
● Le message de retour n’est donc pas un appel de méthode
(il ne provoque donc pas l’activation d’un objet)
● Le message retour porte souvent le nom de l’élément
retourné
4.5. Message de construction d'un
objet
● La création d’un objet est matérialisée par
un message spécifique, appel d’un
constructeur, généralement accompagné
du stéréotype «create» qui pointe sur le
début (le sommet) de la ligne de vie de
l’objet créé (Le rectangle de l’instance de
la classe est alors surbaissée)
4.6. Message de destruction d'un
objet
● La destruction d’un objet est représentée
par une croix à la fin de sa ligne de vie.
Souvent l’objet est détruit suite à la
réception d’un message mais ce n’est
pas obligatoire. Dans ce cas là, il porte le
stéréotype « destroy ».
Exemple de
construction/destruction d'objets
4.7. Syntaxe des messages
synchrones et asynchrones
● Dans la plupart des cas, la réception d’un message est suivie de
l’exécution de la méthode de la classe cible.
● Cette méthode peut recevoir des arguments et la syntaxe des
messages permet de transmettre ces arguments.
● La plupart du temps, dans un diagramme de séquence, on peut
se contenter de définir un message par : Son nom, qui est le nom
de la méthode appelée ou du signal envoyé.
● On peut lui adjoindre facultativement :
- Une numérotation devant le nom message (séparé du nom du
message par 2 point " : "). Elle s’effectue séquentiellement à
partir de 1.
● - Les paramètres passés à la méthode ou au signal (entre
parenthèses après le nom du message).
4.7. Syntaxe des messages
synchrones et asynchrones (suite)
4.8. Syntaxe des
reponses/messages retour
● Comme pour les messages synchrones ou
asynchrones, on peut se contenter de donner au
message retour un simple nom,
● Mais on peut aussi les caractériser plus
précisément en utilisant la syntaxe suivante :
●
numéro : attribut = nomMessage (paramètres) : valeurDeRetour
4.8. Syntaxe des
reponses/messages retour (suite)
4.8. Syntaxe des reponses/messages
retour (suite)
● Le retour d’un message synchrone peut ne pas
être représenté, le retour est alors implicite.
● Par contre, dans le cas d’un message
asynchrone, il est impératif de faire apparaître le
message de retour. Le retour est explicite.
● Bien entendu, si l’exécution de la méthode
lancée par le message asynchrone ne doit rien
retourner, il est évident qu'on ne doit pas
représenter le message de retour (c'est
généralement le cas le plus classique,
notamment avec la gestion événementielle).
4.8. Syntaxe des
reponses/messages retour (suite)
● Les 3 diagrammes suivants sont équivalents :
5.1. Quelques séquences :
Messages récursifs
Messages recursifs
● Un objet peut s’envoyer un message à lui-même
(utilisation d’une autre méthode du même objet). Cela
se représente par un dédoublement de la bande
d’activation.
5.2. Quelques séquences :
Contraintes temporelles
Contraintes temporelles
● Des repères temporels avec des contraintes peuvent
être placés le long de la ligne de vie.
● Un message avec un temps de propagation non
négligeable peut être représenté par une flèche oblique
ou en l'écrivant explicitement.
6. Fragments d'interaction
combinées
Un fragment d'interaction
● Est une partie du diagramme de séquence délimitée par un
rectangle associée à une étiquette située dans le coin supérieur
gauche.
● L’étiquette contient un opérateur d’interactions qui permet de
décrire des modalités d’exécution des messages à l’intérieur du
cadre
● Les opérandes d’un opérateur d’interactions sont séparés par
une ligne pointillée.
● Les conditions de choix des opérandes (éventuels) sont
données par des expressions booléennes entre crochets ([ ]).
● Les principales modalités sont les boucles, les branchements
conditionnels, les alternatives, les envois simultanés,
6.1. Fragments d'interaction avec
opérateur “opt”
● L’opérateur option (opt) comporte une opérande et une
condition de garde associée.
● Le sous-fragment s’exécute si la condition de garde est
vraie et ne s’exécute pas dans le cas contraire.
6.2. Fragments d'interaction avec
opérateur “alt”
● L’opérateur alternatives (alt) est un opérateur conditionnel
possédant plusieurs opérandes séparés par des pointillés.
● C’est l’équivalent d’une exécution à choix multiples.
● Chaque opérande détient une condition de garde. Seul le sous-
fragment dont la condition est vraie est exécuté. La condition else
est exécutée que si aucune autre condition n’est valide
6.3. Fragments d'interaction avec
opérateur “loop”
● L’opérateur de boucle (loop) exécute une itérative dont la
séquence qu’elle contient est exécutée tant que la garde qui lui
est associée est vraie.
● La garde s’écrit de la façon suivante :
- loop [min, max, condition] : Chaque paramètre (min, max et
condition) est optionnel.
- Le contenu du cadre est exécuté min fois, puis continue à
s’exécuter tant que la condition est vraie et que le nombre
d’exécution de la boucle ne dépasse pas max fois.
Exemple de gardes :
● Loop[3] : La séquence s’exécute 3 fois.
● loop[1, 3, code=faux] : La séquence s’exécute 1 fois puis un
maximum de 2 autres fois si code=faux.
6.3. Fragments d'interaction avec
opérateur “loop” (suite)
6.4. Fragments d'interaction avec
opérateur “par”
● Un fragment d’interaction avec l’opérateur de
traitements parallèles (par) contient au moins deux
sous fragments (opérandes) séparés par des pointillés
qui s’exécutent simultanément (traitements concurrents)
6.5. D'autres fragments d'interactions
Nous venons de voir les 4 fragments d’interactions les
plus utilisés (opt, alt, loop et par). Il en existe en réalité
13 au total, ci-dessous la liste des 9 autres :
● ignore et considere : Pour les fragments facultatifs ou
obligatoires.
● critical : pour les fragments qui doivent se dérouler
sans être interrompus.
● break : pour les fragments représentants des scenarii
exceptionnels ou de ruptures (Ex : appui sur la touche
« Esc »). Le scénario de rupture est exécuté si une
condition de garde est satisfaite.
6.5. D'autres fragments d'interactions
(suite)
● Pour les fragments dont on connaît à l’avance les paramètres
du message (EX : Après la saisie des 4 chiffres d’un code, la
saisie suivante sera obligatoirement la touche« Entrée »).
● seq : Indique que le fragment est composé de plusieurs sous
fragments qui peuvent s’exécuter dans n’importe quel ordre
(mais pas en même temps).
● strict : Pour les fragments dont les messages doivent se
dérouler dans un ordre bien précis.
● neg : Pour indiquer que la séquence à l’intérieur du fragment
n’est pas valide.
● ref : Permet de faire appel à un autre diagramme de séquence.
7. Exercice d'application
Enoncé
Modéliser la gestion d'une bibliothèque à l'aide du diagramme de
séquence, à partir du scénario de cas d'utilisation “Emprunter livre”
suivant :
● 1) L'adhérent se présente au comptoir et la bibliothécaire saisit la
fonctionnalité pour emprunter un livre de l'application.
● 2) D'abord, il faut vérifier si l'adhérent a le droit d'emprunter des livres
(carte valide, nombre de livres déjà empruntés ne dépasse pas un
seuil fixé, …).
● 3) Ensuite, il faut vérifier si le livre est disponible.
● 4) Si tout va bien, on crée un nouveau prêt avec la date de prêt et la
date de retour, associé avec l'adhérent et le livre choisit.
● 5) On rend le livre indisponible.
● 6) On incrémente le nombre de livres empruntés par l'adhérent.
