Diagrammes de SEQUENces
Présentation CrÉation et destruCtion d’objet
ÉlÉments d’un diagramme de Syntaxe des messages synchrones et
séquence asynchrones
Acteurs et objets Message retour implicite et
explicite
Ligne de vie
Recouvrement de bande et message
Message récursif
Message asynchrone Fragments d’interaCtion CombinÉs
Message synchrone Exemple de diagramme de séquence
Représentation graphique
Présentation
Le diagramme de séquences
Fait partie des diagrammes comportementaux
(dynamique) et plus précisément des diagrammes
d’interactions.
Il permet de représenter les échanges entre les différents
objets et acteurs du système en fonction du temps.
Présentation
A moins que le système à modéliser soit extrêmement
simple, il n’est pas possible de modéliser la dynamique
globale du système dans un seul diagramme.
Il faut donc faire appel à un ensemble de diagrammes de
séquences chacun correspondant à une sous fonction du
système
Eléments d’un diagramme
de séquence
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. Il
est constitué d’éléments suivants:
Les objets
Les acteurs
Les messages
Les lignes de vie
Acteurs et Objets
Acteur : Représenté par un stickman et qui peut être considéré
comme un objet.
Objet : Représenté par un rectangle dans lequel figure le nom
de l’objet. Ce nom est généralement souligné et peut prendre
l’une des formes suivantes :
Ligne de vie
le diagramme de séquence fait entrer en action les instances de
classes intervenant dans la réalisation d’un cas d’utilisation
particulier.
A chaque objet est associé une ligne de vie en trait pointillés à
la verticale de l’objet qui peut être considéré comme un axe
temporel (le temps s’écoule du haut vers le bas).
La ligne de vie indique les périodes d’activité de l’objet
(généralement, les moments où l’objet exécute une de ses
méthodes).
Lorsque l’objet est détruit, la ligne de vie s’achève par une croix
Messages
Un message
Définit une communication particulière entre des lignes
de vie.
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).
Messages
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.
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 la fin de celle-ci avant
de pouvoir lancer un nouveau message. C’est le message le
plus fréquemment utilisé.
Messages synchrones
Message synchrone: Emetteur bloqué en attente de retour
Messages asynchrones
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âches). Ainsi, l’objet expéditeur n’étant pas bloqué, il peut
continuer d’envoyer d’autres messages.
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.
Messages asynchrones
Message asynchrone: Emetteur non boqué, continue son
exécution
Représentation graphique
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.
Un message synchrone est représenté par une flèche avec
un triangle plein à son extrémité
Un message asynchrone est représenté par une simple
flèche
Représentation graphique
Un message de retour (réponse) est représenté par une
simple flèche en pointillés.
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 pas l’activation d’un objet)
Le message retour porte souvent le nom de l’élément
retourné
Création et destruction
des objets
Une séquence peut aussi contenir la création ou la destruction
d’un objet :
La création d’un objet est matérialisée par un message spécifique,
d’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).
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 ».
Création et destruction
des objets
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, 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 du message, séparé du nom du
message par 2 point " : ". La numérotation 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
Syntaxe des messages
synchrones et asynchrones
Exemple
Syntaxe des messages
synchrones et asynchrones
On peut se contenter de donner aux messages 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
Messages retour
implicites et explicites
Le retour d’un message synchrone peut ne pas être
représenté, il s’agit alors d’un retour implicite.
Par contre, dans le cas d’un message asynchrone, il est
impératif de faire apparaître le message de retour. Il s’agit du
retour est explicite.
Cependant, si l’exécution de la méthode lancée par le
message asynchrone ne doit rien retourner, il est évident
qu’on ne va pas représenter le message de retour (c'est
généralement le cas le plus classique, dans la gestion
événementielle).
Recouvrement de bande
et messages récursifs
Recouvrement de bande d’activation
Lorsqu’un objet est déjà activé, il peut quand même
recevoir d’autres messages (appel d’une autre de ses
méthodes), cela se représente par un dédoublement de la
bande d’activation.
Messages récursifs
Un objet peut s’envoyer un message à lui-même (utilisation
d’une autre méthode du même objet). Cela se représente là
aussi par un dédoublement de la bande d’activation
Recouvrement de bande
et messages récursifs
Fragments d’interaction
combinés
Un fragment d’interactions
Est une partie du diagramme de séquence délimitée par un
rectangle, et associée à une étiquette située dans le coin supérieur
gauche.
L’étiquette contient un opérateur d’interaction 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’interaction 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 ([ ]).
Fragments d’interaction
combinés
Les principales modalités sont les boucles, les branchements
conditionnels, les alternatives, les envois simultanés, etc.
Fragment 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.
Fragment 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 n’est exécutée que si aucune
autre condition n’est valide.
Fragment d’interaction
avec opérateur « alt »
Fragment 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 vrai et le nombre
d’exécution de la boucle ne dépasse pas max fois
Fragment d’interaction
avec opérateur « loop »
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.
Fragment 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)
Autres fragments
d’interaction
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 8 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.
Autres fragments
d’interaction
assert : Pour les fragments dont on connaît à l’avance les paramètres du
message (exemple : 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.
Exemple de diagramme de
séquence: DAB
Le diagramme de séquence permet de compléter et de
visualiser simplement et intuitivement la description
textuelle d’un cas d’utilisation.
Dans le cours sur les diagrammes des cas d’utilisations,
nous avons fait une description textuelle du cas d’utilisation
« Retirer de l’argent » du DAB. Le diagramme de séquence
du scénario nominale est le suivant :
Exemple de diagramme de
séquence: DAB