Le diagramme de séquence

Le but

Ici, nous allons apprendre à faire le diagramme de séquence. Il a pour but de décrire le comportement dynamique de notre système. En général, cela est représenté par les différents cas d'utilisations.

Les notions du diagramme de séquence

Pour aborder les différentes notions, nous diviserons le diagramme de séquence en 3 niveaux :

Débutant
Intermédiaire
Avancé

Cela nous permettra de ne pas vous surcharger avec de nombreuses notions.

Débutant
Les notions

Nous allons voir dans ce niveau les notions suivantes :
- Quelques informations
- Les acteurs
- Les objets
- Les messages
Quelques informations

Nous allons commencer par voir quelques concepts du diagramme de séquence que nous illustrerons plus tard en abordant d'autre notions. Dans un diagramme de séquence, on représente des actions ou des comportements au cours du temps. Le temps se lit de haut en bas.

Les acteurs

Dans notre diagramme de séquence, les acteurs sont les personnes qui interagissent dans le cas d'utilisation ou le comportement que l'on décrit. Cela peut être un "Client" ou un "Satellite" qui vont effectuer une/plusieurs action(s) avec notre système. Un acteur du diagramme de séquence n'est donc pas forcément un être vivant. Tout acteur à sa ligne de vie (représenté par le rectangle bleu) qui correspond à sa participation à une interaction. Hors comme tout acteur participe à des interactions que l'on décrit, il a forcément une ligne de vie.

Les objets

Les objets sont des parties de notre système qui effectue un certains nombre d'actions. Eux aussi ont une ligne de vie qui démarre au moment de la réception d'un message (nous developperons cela ci-dessous). Des objets peuvent interagir entre eux en s'échangeant des messages. On représente un objet comme avec les objets "Système" et "Gestionnaire d'article" ci-contre.

Les messages

Maintenant que nous avons nos acteurs ainsi que nos objets, il faut que l'on représente des interactions entre ces derniers. Pour cela, nous utilisons des messages. Ici, nous allons commencer doucement en observant la notion générale de message. Nous approfondirons cela dans le niveau "Intermédiaire". Un message signifie qu'il y a une communication entre deux lignes de vie. Il est représenté par une flèche pleine avec au dessus la méthode (ce que fait ou passe l'acteur ou l'objet). La flèche en pointillée est quant à elle une flèche de retour. C'est la réponse à la demande de l'acteur.
Intermédiaire
Les notions

Nous allons voir dans ce niveau les notions suivantes :
- L'Interface Homme Machine (IHM)
- Les boucles
- Les conditions
- Les messages avancés
L'Interface Homme Machine (IHM)

Maintenant que nous avons les bases, nous allons ajouter un élément essentiel qui va à partir de maintenant se retrouver dans tous vos diagrammes de séquence (ou presque) : l'IHM.
L'IHM nous permet de faire la liaison entre notre utilisateur et notre système. C'est elle qui se chargera d'envoyer la demande de l'utilisateur ainsi que d'afficher la réponse de notre système. Il n'y aura donc plus aucun retour jusqu'à l'utilisateur comme le montre le diagramme de séquence ci-contre.

Les boucles

Passons maintenant aux boucles. Comme nous devons retranscrire des cas qui n'ont pas une seule possibilité, nous allons avoir besoin de boucle ainsi que de conditions. Nous allons donc voir ici les boucles. On représente une boucle avec un cadre dans lequel on met les messages sur lesquels la boucle doit se répéter. En haut à gauche on écrit la multiplicité de la répétition de la boucle. On y ajoute entre crochets la condition pour sortir de la boucle. Je vous laisse regarder l'exemple ci-contre.

Les conditions

Maintenant, observons les conditions. Pour pouvoir gérer les différents cas et savoir quel message envoyer, il nous est nécessaire d'utiliser des conditions. Dans un diagramme de classe, elles se représentent comme des boucles, c'est-à-dire dans un rectangle avec écrit en haut à gauche "alt". On sépare les différents cas de nos conditions à l'aide d'un trait en pointillé. On y écrit la condition entre crochets. Voici un exemple de diagramme de séquence avec une condition.

Les messages avancés

Ici, nous allons voir comment améliorer nos messages. Tout d'abord, il est possible d'ajouter des paramètres à nos messages. Comme pour une fonction ou une procédure, on écrit les paramètres entre parenthèses.
Nous allons voir les différences entre les messages synchrones et les messages asynchrones.

Un message synchrone est un message bloquant l'expéditeur en attendant une réponse. L'expéditeur reprend le contrôle une fois qu'il reçoit le retour du récepteur.
Un message asynchrone est un message qui ne bloque pas l'expéditeur, il n'attend donc aucune réponse. Du côté du récepteur, il peut prendre en compte ou non le message qu'il vient de recevoir.
Nous allons finir par voir les messages recursifs. Ce sont des messages qui partent et arrivent au même acteur ou objet.

Voici un diagramme qui resume tout cela.
Avancé
Les notions

Nous allons voir dans ce niveau les notions suivantes :
- Les créations et les destructions
- Les activations
- D'autres détails
Les créations et les destructions

La création et la destruction représentent la création ou destruction d'un objet. Elles n'arrivent donc en aucun cas dès le début du diagramme.
Pour la création, on fait un message de création qui pointe vers un objet de notre système. L'objet a alors une ligne de vie et peut être utilisé comme tout autre objet de notre système.
Pour la destruction, l'objet à détruire reçoit un message de destruction représenté par une flèche avec une croix à l'extrémité de l'objet à détruire.
Voici un exemple de création ainsi que de destruction.

Les activations

Les activations est un concept assez simple mais que je vous ai caché jusqu'à présent. L'activation est en fait le moment où un objet reçoit un message. Sur les diagrammes de séquence, cela est représenté par des rectangles (ici en bleu). C'est donc la durée durant laquelle l'objet est actif. Un même objet peut donc avoir plusieurs phases d'activation ou une seule. Il y a un exemple d'activation sur le schéma ci-dessus.

D'autres détails

Dans un diagramme de séquence, il est possible d'annoter son diagramme à l'aide de notes. Elles permettent de donner des détails ou des indications sur notre diagramme comme des flots d'erreurs, des conditions... Vous pouvez observer cela dans l'exemple ci-contre.

Notre étude de cas

Pour tous nos diagrammes, nous utiliserons le même cas que nous approfondirons (plus ou moins en fonction du niveau que vous étudiez). Elle sera basée sur un sujet disponible ici (de Mme Blay, ensaignante à l'IUT de Nice). Pour nos diagrammes de séquence, nous effectuerons seulement le diagramme de séquence du cas d'utilisation "Envoyer un message".
Il y aura une correction des différents niveaux mais retenez bien qu'il n'y a pas une unique solution lors de la modélisation. Cependant, lorsque l'on a un sujet écrit comme ici, il ne faut pas imaginer des informations qui ne nous sont pas fournies par le sujet.

Débutant

Étude de cas niveau débutant

Scénario : Le conducteur sélectionne le modèle de message. Le système construit le message, puis le lit. Le conducteur doit alors valider l’envoi. Le message est alors envoyé par le système. Dès que le message est envoyé, le conducteur est averti.

Analyser le sujet

Dans ce sujet, le diagramme de séquence à effectuer est bien distinct du reste du sujet. Il est donc facile à repérer et ne comporte aucune information inutile.
Nous pouvons donc commencer l'analyse du sujet.

Nous pouvons observer l'existence de notre acteur "Conducteur" que nous nommerons "Utilisateur" (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici.
Ensuite nous allons chercher des objets à inclure à notre diagramme. Nous trouvons un objet "Système" avec qui notre "Utilisateur" pourra communiquer.

Dans le scénario, nous avons "Le conducteur sélectionne le modèle de message" puis "Le système construit le message, puis le lit". Nous avons donc là nos trois premiers messages. Nous pouvons donc les ajouter à notre diagramme. Je vous aide un peu car nous n'avons pas encore vu cette notion mais pour "le système construit et lit le message", cela doit être un message récursif (qui part du système et y revient). Nous apprendrons cela plus tard. Continuons avec "Le conducteur doit alors valider l’envoi" et ensuite "Le message est alors envoyé par le système. Dès que le message est envoyé, le conducteur est averti."
On obtient donc le diagramme suivant :
Intermédiaire

Étude de cas niveau intermédiaire

Scénario : Le conducteur sélectionne le modèle de messages parmi les modèles connus de son boîtier. Le système construit le message, puis le lit. Le conducteur doit alors valider l’envoi. Le message est alors envoyé par le système. Dès que le message est envoyé, le conducteur est averti. Si le système ne parvient pas à l’envoyer, il réessaie jusqu’à réussir.

Analyser le sujet

Dans ce sujet, le diagramme de séquence à effectuer est bien distinct du reste du sujet. Il est donc facile à repérer et ne comporte aucune information inutile.
Nous pouvons donc commencer l'analyse du sujet.

Nous pouvons observer l'existence de notre acteur "Conducteur" que nous nommerons "Utilisateur" (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici.
Ensuite nous allons chercher des objets à inclure à notre diagramme. Nous trouvons un objet "Système". Mais notre "Utilisateur" ne peut pas directement communiquer avec le système. Pour communiquer, il passe par l'intermédiaire de "l'IHM" qui, lui pourra communiquer avec notre "Utilisateur".

Dans le scénario, nous avons "Le conducteur sélectionne le modèle de message" puis "Le système construit le message, puis le lit". Nous avons donc là nos trois premiers messages avec comme paramètres le modèle choisi plus les différents messages de transfert de l'IHM. Nous pouvons donc les ajouter à notre diagramme. En ce qui concerne le système lit le message, nous avons un message récursif car le système se demande à lui-même de lire le message. Continuons avec "Le conducteur doit alors valider l’envoi" et ensuite "Le message est alors envoyé par le système. Dès que le message est envoyé, le conducteur est averti."

Il ne nous reste plus qu'une phrase à interpréter qui est aussi la plus dure, "Si le système ne parvient pas à l’envoyer, il réessaie jusqu’à réussir". Dans cette phrase, on observe une condition avec le "Si le système [...]" ainsi qu'une boucle "jusqu’à réussir". Nous allons donc devoir rajouter un cadre de condition avec pour condition "S'il y a un problème" puis une boucle avec comme condition "tant que ce n'est pas réussi".
Attention, il va aussi falloir imbriquer les boucles car on réessaie seulement si la tentative précédente n'a pas réussi. On obtient donc le diagramme suivant :
Avancé

Étude de cas niveau avancé

Scénario : Le conducteur sélectionne le modèle de messages parmi les modèles connus de son boîtier. Le système construit le message, puis le lit. Le conducteur doit alors valider l’envoi. Le message est alors envoyé par le système. Si le système ne parvient pas à l’envoyer, il annonce le problème, puis réessaie jusqu’à réussir ou que le délai associé à ce modèle de message soit dépassé. Dans ce cas, il avertit le conducteur que le message n’est pas parti par un signal sonore et que ce dernier est détruit. Inversement dès que le message est envoyé, le conducteur est averti.

Analyser le sujet

Dans ce sujet, le diagramme de séquence à effectuer est bien distinct du reste du sujet. Il est donc facile à repérer et ne comporte aucune information inutile.
Nous pouvons donc commencer l'analyse du sujet. L'énoncé n'est pas très différent des autres niveaux mais ici, nous irons plus loin dans la représentation de notre système en le divisant en plusieurs parties. Cela ne nous est pas dit par l'énoncé mais cela se comprend avec l'expérience.

Nous pouvons observer l'existence de notre acteur "Conducteur" que nous nommerons "Utilisateur" (c'est un choix de ma part qui n'est pas obligatoire). Mais si vous faites cela, il faudra le spécifier dans le glossaire. Si vous ne savez pas encore ce qu'est un glossaire je vous invite à voir à quoi sert et comment faire un glossaire ici.
Ensuite nous allons chercher des objets à inclure à notre diagramme. Nous trouvons un objet "Système". Mais notre "Utilisateur" ne peut pas directement communiquer avec le système. Pour communiquer, il passe par l'intermédiaire de "l'IHM" qui lui, pourra communiquer avec notre "Utilisateur".

Dans le scénario, nous avons "Le conducteur sélectionne le modèle de message" puis "Le système construit le message, puis le lit". Nous avons donc là nos trois premiers messages avec comme paramètres le modèle choisi plus les différents messages de transfert de l'IHM. Nous pouvons donc les ajouter à notre diagramme. En ce qui concerne le système lit le message, nous avons un message récursif car le système se demande à lui-même de lire le message. Continuons avec "Le conducteur doit alors valider l’envoi" et ensuite "Le message est alors envoyé par le système. Dès que le message est envoyé, le conducteur est averti."

Il ne nous reste plus que la fin du texte à interpréter qui est aussi la plus dure, "Si le système ne parvient pas à l’envoyer, il réessaie jusqu’à réussir ou que le délai associé à ce modèle de message soit dépassé". Dans cette phrase, on observe une condition avec le "Si le système [...]" ainsi qu'une boucle "jusqu’à réussir ou que le délai associé à ce modèle de message soit dépassé". Nous allons donc devoir rajouter un cadre de condition avec pour condition "S'il y a un problème" puis une boucle avec comme condition "tant que ce n'est pas réussi ou que le délai le permet". Attention, il va aussi falloir imbriquer les boucles car on réessaie seulement si la tentative précédente n'a pas réussi.

Ensuite, il faut aussi penser qu'avant d'envoyer notre message, il est nécessaire de le créer. Il faut donc demander à un objet qui pourrait construire notre message de le faire. Nous allons donc ajouter un objet "Fabrique de message" qui va créer un objet "Message" après en avoir reçu l'ordre. C'est donc le message qui recevra l'ordre de s'envoyer. Continuons en analysant l'ultime partie.

"Dans ce cas [échec], il avertit le conducteur que le message n’est pas parti par un signal sonore et que ce dernier est détruit. Inversement dès que le message est envoyé, le conducteur est averti."
On observe donc deux cas différents :
-Un premier où le message est bien envoyé
-Un second où le message n'est pas envoyé et il est détruit.
Nous devons donc ajouter une autre condition que nous ajouterons dans notre boucle for.
On obtient donc le diagramme suivant :