Dans la plupart des cas, un diagramme de séquence est utilisé pour illustrer les réalisations de cas d'utilisation
(voir Produit: réalisations de cas d'utilisation), autrement dit pour
montrer la façon dont les objets interagissent afin d'exécuter le comportement de la totalité ou d'une partie d'un cas
d'utilisation. Un ou plusieurs diagrammes de séquence peuvent illustrer les interactions d'objets qui définissent un
cas d'utilisation. L'organisation classique est d'avoir un diagramme de séquence pour le flux d'événements principal et
un autre diagramme pour chaque sous-flot du cas d'utilisation.
Les diagrammes de séquence sont très importants pour les concepteurs car ils clarifient les rôles des objets dans un
flux et sont donc un moyen de déterminer les responsabilités des classes et les interfaces.
Contrairement au diagramme de communication, le diagramme de séquence inclut les séquences chronologiques, mais pas les
relations d'objets. Les diagrammes de séquence et de communication expriment des informations similaires, mais les
montrent de manière différente. Les diagrammes de séquence montrent la séquence explicite des messages et sont plus
appropriés lorsqu'il est important de visualiser l'organisation dans le temps des messages. Lorsque vous voulez voir
les relations structurelles entre les instances d'une interaction, utilisez un diagramme de communication. Voir Technique : diagramme de communication pour plus d'informations.
Il peut y avoir des instances d'objets et d'acteurs dans les diagrammes de séquence, ainsi que des messages décrivant
leurs interactions. Le diagramme décrit ce qui se passe dans les objets participants, en termes d'activation, ainsi que
la façon dont les objets communiquent en s'envoyant des messages. Vous pouvez faire un diagramme de séquence pour
chaque variante du flux d'événements d'un cas d'utilisation.
Diagramme de séquence décrivant une partie du flux d'événements du cas d'utilisation Emettre un appel local
depuis un standard téléphonique classique.
Un objet est représenté par une ligne tiretée verticale appelée la "ligne de vie". La ligne de vie représente
l'existence d'un objet à un moment donné. Un symbole d'objet est tracé au début de la ligne de vie, il indique le nom
de l'objet et sa classe en caractères soulignés et séparés par deux-points :
nom d'objet : nom de classe
Les objets peuvent être utilisés dans les diagrammes de séquence des manières suivantes :
-
Une ligne de vie peut représenter un objet ou sa classe. Vous pouvez donc utiliser une ligne de vie pour modéliser
le comportement de la classe et de l'objet. Cependant, en général, une ligne de vie représente tous les objets
d'une certaine classe.
-
La classe d'un objet peut ne pas être précisée. En général, on crée d'abord un diagramme de séquence avec des
objets, puis on définit leur classe plus tard.
-
Les objets peuvent ne pas être nommés, mais il est préférable de le faire si vous voulez pouvoir distinguer les
différents objets d'une même classe.
-
Dans le même diagramme, plusieurs lignes de vie peuvent représenter différents objets de la même classe ; mais,
comme nous l'avons déjà dit, il est préférable de nommer les objets pour pouvoir les différencier les uns des
autres.
-
Une ligne de vie représentant une classe peut exister en parallèle des lignes de vie représentant les objets de
cette classe. Le nom d'objet de la ligne de vie représentant la classe peut être assorti au nom de la classe.
Normalement, l'instance d'un acteur est représentée par la première ligne de vie (la plus à gauche), comme étant
l'auteur de l'interaction. Si vous avez plusieurs instances d'acteurs dans le même diagramme, essayer de les placer
dans les lignes de vie les plus à gauche ou les plus à droite.
Un message est une communication entre des objets qui transmet des informations dans le but de déclencher une activité.
Dans les diagrammes de séquence, un message est représenté par une flèche pleine horizontale entre la ligne de vie d'un
objet et celle d'un autre objet. Dans le cas d'un message qu'un objet s'envoie à lui-même, la flèche peut commencer et
finir sur la même ligne de vie. La flèche est étiquetée avec le nom du message et ses paramètres. La flèche peut aussi
comporter un numéro de séquence pour montrer la séquence du message dans l'interaction générale. Les numéros de
séquence sont souvent omis dans les diagrammes de séquence dans lesquels la position de la flèche indique la séquence
relative.
Un message peut être sans affectation, cela signifie que son nom est une chaîne temporaire qui décrit le sens général
du message mais pas le nom d'une opération de l'objet recevant. Vous pourrez par la suite donner une affectation au
message en définissant l'opération de l'objet auquel le message est destiné. L'opération définie alors remplacera le
nom du message.
Les scripts décrivent le flux d'événements sous forme de texte dans un diagramme de séquence.
Il vaut mieux positionner les scripts à la gauche des lignes de vie de façon à pouvoir lire le flux complet de haut en
bas (voir la figure ci-dessous). Vous pouvez joindre un message aux scripts vous assurant alors que le script se
déplacera avec le message.
Le contrôle centralisé d'un flux d'événements ou d'une partie d'un flux d'événements signifie que quelques
objets contrôlent le flux en échangeant des messages avec d'autres objets. Ces objets qui contrôlent décident l'ordre
dans lequel les autres objets seront activés dans le cas d'utilisation. Les interactions avec les autres objets sont
très rares ou inexistantes.
Exemple
Dans le Système d'une machine de recyclage, le cas d'utilisation Imprimer le rapport quotidien garde la
trace, entre autres, du nombre et du type d'objets consignés et imprime ce décompte sur un reçu. L'objet de contrôle
Générateur de rapport décide l'ordre dans lequel les sommes seront extraites et écrites.
La structure du comportement du cas d'utilisation Imprimer le rapport quotidien est centralisée dans l'objet de
contrôle Générateur de rapport.
C'est un exemple de comportement centralisé. La structure du contrôle est centralisée principalement parce que les
différentes phases de sous-événement du flux d'événements ne dépendent pas les unes des autres. Le principal avantage
de cette approche est qu'elle permet aux objets de ne pas avoir à garder trace du compte du prochain objet. Pour
changer l'ordre des phases de sous-événement, vous n'avez qu'à effectuer les changements dans l'objet de contrôle. Vous
pouvez aussi facilement ajouter d'autres phases de sous-événement si, par exemple, un nouveau type d'article à
consigner est ajouté. Un autre avantage de cette structure est qu'elle permet de réutiliser les différentes phases de
sous-événement dans d'autres cas d'utilisation car l'ordre de comportement n'est pas contenu par les objets.
Le contrôle décentralisé provient des objets participants qui communiquent entre eux directement et non
pas à l'aide d'un ou plusieurs objets de contrôle.
Exemple
Dans le cas d'utilisation Envoyer une lettre, quelqu'un envoie une lettre dans un autre pays par la poste. La
lettre est d'abord envoyée dans le pays du destinataire. Une fois dans le pays, la lettre est envoyée dans une ville
spécifique. Arrivée dans la ville, la lettre est cette fois expédiée à l'adresse du destinataire.
La structure du comportement du cas d'utilisation Envoyer une lettre est décentralisée.
Le comportement de ce cas d'utilisation est un flux d'événements décentralisé. Les phases de sous-événement vont
ensemble. L'expéditeur de la lettre parle "d'envoyer la lettre à quelqu'un". Il n'éprouve ni le besoin, ni l'envie de
connaître la façon dont les lettres sont acheminées dans les pays ou les villes. Si une personne envoyait une lettre
dans le même pays, toutes ces actions n'auraient probablement pas lieu.
Le type de contrôle dépend de l'application. En général, il faut essayer de créer des objets indépendants, c'est à dire
de donner des tâches variées aux objets les mieux adaptés pour les accomplir.
Un flux d'événements avec un contrôle centralisé aura un diagramme de séquence à plusieurs branches. Un diagramme de
séquence en escalier indique, au contraire, que la structure du contrôle est décentralisée pour les objets
participants.
Une structure de contrôle centralisée dans un flux d'événements produit un diagramme de séquence à plusieurs branches.
Une structure de contrôle décentralisée produit un diagramme de séquence en escalier.
La structure du comportement de la réalisation d'un cas d'utilisation est généralement faite d'un mélange de
comportement centralisé et décentralisé.
Une structure décentralisée convient si :
-
les phases de sous-événements sont étroitement couplées. Ce sera le cas si les objets participants :
-
font partie d'une hiérarchie, comme Pays - Etat - Ville ;
-
sont une hiérarchie informative, comme Directeur général - Chef de la division - Chef de la section ;
-
représentent une progression chronologique fixe (la séquence des phases de sous-événements sera toujours
exécutée dans le même ordre), comme Message publicitaire - Commande - Facture -Livraison - Paiement ;
-
forment une hiérarchie d'héritage conceptuelle comme Animal - Mammifère - Chat.
-
vous voulez encapsuler et donc faire abstraction de la fonctionnalité. Cela est utile pour quelqu'un voulant
toujours utiliser la fonctionnalité entière. En effet, la fonctionnalité peut devenir difficile à manipuler si la
structure du comportement est centralisée.
Une structure centralisée convient si :
-
l'ordre dans lequel les phases de sous-événements sont réalisées est susceptible d'être changé.
-
vous prévoyez d'insérer de nouvelles phases de sous-événements.
-
vous voulez réutiliser certaines parties de la fonctionnalité comme des pièces séparées.
|