Instructions: Diagramme de séquence
Un diagramme de séquence est une construction UML utilisée pour montrer les séquences d'interactions d'objets qui exécutent le scénario d'un cas d'utilisation. Ces instructions décrivent la notation UML pour cette construction.
Relations
Description principale

Introduction

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.

Contenu des diagrammes de séquence

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 décrit dans le texte d'accompagnement.

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.

Objets

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.

Acteurs

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.

Messages

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.

Scripts

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.

Distribution du flux de contrôle dans les diagrammes de séquence

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.

Diagramme décrit dans le texte d'accompagnement.

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.

Diagramme décrit dans le texte d'accompagnement.

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.

Diagramme décrit dans le texte d'accompagnement.

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.