Diagrammes de séquence UML

Un diagramme de séquence répond précisément à une question : que se passe-t-il, dans quel ordre, entre qui. C'est le diagramme qu'on trace quand deux personnes ne s'accordent pas sur quel service appelle lequel, ou quand un flux traverse quatre systèmes et que personne n'a le chemin complet en tête.

La mise en page fait tout le travail. Les participants sont alignés en haut. Le temps descend - pas de gauche à droite, et pas à l'échelle. Un message plus bas sur la page se produit après un message plus haut, et c'est toute la règle de lecture.

Trois meubles, et tout le reste en est une variation.

Une ligne de vie, c'est la tête en haut plus la verticale pointillée qui en descend. La tête nomme le participant. Ce peut être un nom de classe, un objet (: Checkout), un acteur dessiné en bonhomme bâton, ou un rôle avec un stéréotype comme «boundary» ou «control». Quel que soit votre choix, restez cohérent sur tout le diagramme.

Une barre d'activation - parfois appelée occurrence d'exécution - est le rectangle étroit posé sur la ligne de vie. Elle marque la période pendant laquelle ce participant fait quelque chose. Des barres imbriquées signifient qu'un participant s'est rappelé lui-même. Les activations sont optionnelles en UML, et elles valent la peine : elles rendent évident que Checkout attend encore pendant que la passerelle travaille.

Un message est la flèche horizontale. Son style dit de quel type d'appel il s'agit, et c'est la partie à retenir.

La distinction pointe pleine contre pointe ouverte est celle qui pèse vraiment. C'est la différence entre « l'appelant est maintenant bloqué » et « l'appelant est passé à autre chose », et c'est la chose la plus utile qu'un diagramme de séquence dise à un lecteur sur un système distribué.

Les vrais flux ont des conditions et des répétitions. UML traite les deux avec un fragment combiné : une boîte tracée autour d'une suite de messages, avec un opérateur dans une étiquette en haut à gauche.

• alt - alternatives. Séparé par un trait pointillé en compartiments, chacun avec une garde entre crochets. Exactement un s'exécute. C'est un si/sinon.
• opt - optionnel. Un compartiment avec une garde ; il s'exécute ou non. C'est un si sans sinon.
• loop - répétition. La garde donne la condition ou les bornes, comme loop [1..*] ou loop [tant qu'il reste des pages].
• par - parallèle. Les compartiments s'exécutent concurremment, sans ordre garanti.
• ref - une référence à une interaction définie sur un autre diagramme. C'est ainsi qu'on empêche un diagramme de séquence de s'étaler sur trois pages.
• critical - une région qui ne doit être entrelacée avec rien d'autre.

Tout ce qui précède se trouve dans une boîte que la plupart des diagrammes tracent et que peu de lecteurs remarquent : le cadre d'interaction, un rectangle autour du diagramme entier avec une étiquette en haut à gauche portant sd et le nom de l'interaction. Cela ressemble à de la décoration et n'en est pas : c'est ce qui donne un nom à l'interaction, et c'est le nom qui rend ref possible. Sans lui, impossible de découper un flux long, ce qui veut dire que chaque flux doit tenir sur une page.

La liste de fragments de la section précédente est l'ensemble de travail, pas l'ensemble complet. Quatre autres opérateurs existent et trois méritent parfois leur place : break abandonne le reste du fragment englobant quand sa garde tient, ce qui est la forme naturelle d'un retour anticipé sur erreur ; strict impose l'ordre de ses compartiments là où seq les laisse libres ; neg marque une interaction qui ne doit pas se produire, une façon d'inscrire un test négatif dans une image. assert, ignore et consider relèvent de la spécification formelle et peuvent être ignorés jusqu'à ce que quelque chose vous les impose.

Ce qu'un diagramme de séquence a de plus précieux n'est pas de documenter le chemin heureux. C'est qu'une fois le chemin heureux sur la page, les échecs deviennent dénombrables - et un flux traversant quatre systèmes en a bien plus que quiconque n'estime de mémoire.

Descendez le diagramme et posez trois questions à chaque message, dans cet ordre. Les réponses sont vos chemins d'extension, et chacune est soit un fragment à tracer, soit une décision que quelqu'un doit prendre.

1. Et s'il n'y a pas de réponse ? Chaque message synchrone est un endroit où l'appelant peut se bloquer indéfiniment. Il existe quelque part une valeur de délai ; si personne dans la salle ne la connaît, c'est là le constat. Tracez-le en alt avec une garde [timeout], et le chiffre se retrouve sur le diagramme où l'on peut en discuter.
2. Et si la réponse est un échec ? Distinct de l'absence de réponse, et traité de façon identique par une quantité inquiétante de code de production. Une autorisation refusée et un acquéreur mort demandent des traitements différents, et c'est sur le diagramme que cette différence devient visible.
3. Et si ceci est livré deux fois ? Posez la question à chaque message asynchrone, car les files redélivrent et les clients réessaient. Si la réponse est « le client est débité deux fois », vous venez de trouver l'exigence d'idempotence qui n'était pas dans le ticket.

Relisez ensuite le diagramme à l'envers, pour la question que la passe avant ne capture jamais : qu'est-ce qui s'est déjà produit et doit maintenant être défait ? Un échec au quatrième message laisse en place les effets des trois premiers. C'est la logique de compensation, et un diagramme de séquence est l'endroit le moins cher au monde pour découvrir qu'il vous en faut.

Le diagramme de séquence est aussi l'artefact UML le plus efficace pour relire une conception avant de la construire, parce qu'il force les questions gênantes au grand jour. Que se passe-t-il si la passerelle expire ? Qui réessaie ? Cet appel est-il bloquant ? On ne peut pas tracer le diagramme sans y répondre.

1. Toutes les flèches en trait plein et pointe pleine. Si tout paraît synchrone, le diagramme a jeté sa distinction la plus utile. Pointes ouvertes pour le tire-et-oublie.
2. Des flèches de réponse partout. La réponse à un appel synchrone est souvent implicite et peut être omise. Tracez-la quand la valeur renvoyée compte.
3. Mélanger les niveaux d'abstraction. Une ligne de vie pour toute une plateforme de paiement à côté d'une ligne de vie pour une classe utilitaire. Choisissez une altitude.
4. Aucun chemin d'erreur. Le chemin heureux seul est la moitié la moins intéressante. C'est l'alt avec la branche de délai qui rend le diagramme digne d'être relu.
5. Vingt lignes de vie. Au-delà de sept environ, le diagramme ne tient plus à l'écran et se fait faire défiler plutôt que lire. Découpez-le et utilisez ref.