Diagrammes de séquence

Objectif

Le diagramme de séquence spécifie le comportement d'un scénario: qui envoie quel message à qui, dans quel ordre et ce qui revient. Il prend un chemin unique à travers un cas d'utilisation et le déroule participant par participant, du haut vers le bas dans l'ordre chronologique. Sa valeur tient à deux usages. Il rend une interaction assez lisible pour être validée avec les parties prenantes, qui suivent la chronologie sans maîtriser la notation en profondeur. Et il la spécifie assez précisément pour qu'une équipe construise contre elle, chaque appel nommé, chaque attente explicite, chaque branche gardée par sa condition. Le livrable est une spécification comportementale d'un scénario, tracée vers le cas d'utilisation qu'elle raffine. Il montre comment des participants interagissent dans le temps; la façon dont ils sont structurellement reliés relève du diagramme de classes UML.

Usage

Quand l'utiliser

• Raffiner un cas d'utilisation: transformer les étapes d'un scénario en messages concrets entre participants.
• Valider une logique d'échange avec des non-techniciens: la forme chronologique se suit sans bagage particulier.
• Fixer l'ordre et le sens des appels d'un enchaînement complexe: poignée de main d'authentification, transaction multi-systèmes, notification en retour.
• Spécifier la collaboration entre composants ou éléments d'interface: montrer qui appelle qui et ce qui revient.

Quand ne pas l'utiliser

• Besoin de structure, pas de comportement: pour les relations entre entités, prendre le diagramme de classes UML.
• Flux unique et linéaire, sans branche ni système tiers: le formalisme ne se justifie pas, un cas d'utilisation en prose suffit.
• Flux métier pour une audience non technique, par-delà les rôles: trop technique ici, prendre la modélisation des processus.

Description

Un diagramme de séquence est un diagramme d'interaction: il modélise la logique d'un scénario par les messages échangés entre un ensemble de participants, rangés dans le temps. Il répond à une question de comportement, qui parle à qui et dans quel ordre, là où le diagramme d'activités UML décrit le flux de contrôle à l'intérieur d'un seul système et le diagramme de classes la structure. BABOK le range parmi les techniques qui raffinent un cas d'utilisation en détail d'interaction et le nomme parfois diagramme d'événements.

Participants, lignes de vie et barres d'exécution

Un participant est une boîte en haut du diagramme, étiquetée nom:Classe, l'une ou l'autre partie pouvant être omise; un participant anonyme s'écrit :Classe. Un participant qui figure un rôle humain ou un système externe, l'acteur, peut porter la silhouette en bâton. Chaque boîte possède une colonne. De sa base descend la ligne de vie, un trait vertical en pointillé qui court sur toute la durée d'existence du participant dans le scénario; le temps s'écoule vers le bas. Sur cette ligne, la barre d'exécution, un mince rectangle, marque la période où le participant traite une opération; des barres imbriquées montrent un appel à l'intérieur d'un appel. Une ligne de vie peut se terminer par une grande croix, à l'instant où le participant est détruit et cesse d'exister.

Les messages portent le sens

Le sens se lit dans la forme de la flèche. Un message synchrone, un appel, se dessine par un trait plein terminé d'une tête pleine: l'émetteur bloque, il ne peut rien faire tant que la réponse n'est pas revenue. Un message asynchrone se dessine par un trait plein terminé d'une tête ouverte, une pointe fine: l'émetteur poursuit son propre traitement sans attendre. Le message de retour, la réponse, se dessine par un trait pointillé terminé d'une tête ouverte, revenant vers l'appelant; il se lit en paire avec l'appel synchrone qui l'a déclenché. La confusion la plus coûteuse tient à un détail: un retour dessiné en trait plein devient un message asynchrone et l'inverse. L'asynchrone et le retour partagent la tête ouverte; seul le trait, plein ou pointillé, les sépare.

Fragments combinés: brancher, répéter, paralléliser

Le contrôle du flux à l'intérieur d'une interaction se dessine par un fragment combiné, un cadre autour d'une région du diagramme, avec un opérateur inscrit dans le coin supérieur gauche. Quatre suffisent au niveau conceptuel. alt pose des alternatives: deux opérandes gardés, séparés par un trait horizontal pointillé, le choix entre deux branches du diagramme, par exemple une authentification réussie contre une authentification échouée. opt pose un fragment optionnel, qui ne s'exécute que si sa garde est vraie. loop pose une répétition, éventuellement bornée par loop(min,max) ou par une garde. par pose des opérandes concurrents, exécutés en parallèle. La garde, un booléen entre crochets, énonce la condition sous laquelle un message ou un opérande se déclenche. Un alt sans gardes est le piège classique: il montre qu'il existe deux issues sans dire laquelle survient quand.

Construire le diagramme

On construit le diagramme scénario par scénario. D'abord choisir un scénario, un chemin unique à travers le cas d'utilisation, le chemin nominal ou un cas alternatif précis; un diagramme modélise un scénario. Identifier ensuite les participants qui échangent des messages sur ce chemin, acteurs, composants d'interface, services et systèmes, objets clés, rangés de gauche à droite dans l'ordre de leur première intervention, l'initiateur à gauche. Tracer les têtes et les lignes de vie. Parcourir alors le scénario dans l'ordre, chaque interaction devenant une flèche de l'émetteur vers le récepteur, en descendant; choisir le type de flèche à dessein, synchrone pour un appel bloquant, asynchrone pour un envoi sans attente, pointillé pour un retour. Ajouter les barres d'exécution sur les récepteurs, imbriquées pour les appels imbriqués. Envelopper les branches dans un alt ou un opt, la répétition dans un loop, la concurrence dans un par et écrire les gardes. Marquer les événements de cycle de vie utiles, création et destruction. Valider enfin le résultat avec les parties prenantes, puis le réconcilier avec le cas d'utilisation d'origine.

Un premier excès est d'en modéliser trop: construire un jeu complet de diagrammes pour chaque cas d'utilisation d'un système coûte cher et n'apporte rien là où l'ordre des échanges ne fait courir aucun risque. On modélise les scénarios où la séquence elle-même est la difficulté, une poignée de main d'authentification, une transaction qui traverse plusieurs systèmes, un flux de rappel. Le second est de tout entasser dans un seul diagramme, chaque chemin alternatif compris, jusqu'à un fouillis de fragments illisible; un scénario par diagramme, les alternatives significatives dans leur propre alt ou leur propre diagramme. Reste un piège de fond: attendre du diagramme qu'il montre comment les participants sont reliés. Il montre l'interaction dans le temps; les relations vivent dans un modèle de classes ou de données, l'évolution d'un objet à travers tous ses scénarios dans la modélisation des états et le mouvement des données dans un diagramme de flux de données.

Considérations IA

Deux usages tiennent solidement. Le premier est l'ébauche à partir d'un récit: un modèle de langage transforme la description écrite d'un cas d'utilisation, le client soumet un paiement, le système authentifie, puis débite, en une première liste de participants et une première séquence de messages. L'interface naturelle est le texte-vers-diagramme, le modèle écrit du PlantUML ou du Mermaid, un moteur le rend, et le diff se relit. Le second est la rétro-ingénierie: produire un diagramme candidat depuis des journaux d'exécution, une trace distribuée ou un chemin de code, pour documenter ce que le système fait réellement plutôt que ce qui était spécifié. S'y ajoutent les corvées de cohérence: renommer un participant dans tout un jeu de diagrammes, vérifier que chaque appel synchrone a bien son retour, signaler les fragments sans garde.

Ce qui ne se délègue pas tient au sens et au risque. Qu'un appel doive être synchrone ou asynchrone est une décision de conception aux conséquences réelles, blocage, délais d'attente, couplage; le modèle devine d'après la formulation et se trompe avec aplomb. Le choix de la flèche appartient à l'analyste. La sensibilité des données ensuite: un diagramme d'authentification ou de paiement encode où circulent des secrets, des jetons et des données personnelles; livrer de vrais journaux à un modèle externe peut exposer précisément cela, et le modèle ne signalera pas qu'une étape révèle un identifiant. L'analyste juge ce qui peut être modélisé et où. La granularité enfin: un diagramme reconstruit depuis des traces est exhaustif et illisible, un diagramme de validation avec les parties prenantes est grossier à dessein; savoir pour quel lecteur on dessine n'est pas une question que l'outil sait poser.

Exemples

Un client règle une facture de CHF 1'250.00 dans son e-banking; le paiement exige une authentification forte du client avant que le système bancaire central ne l'exécute. Quatre participants suffisent à porter le scénario: le client, le front-end e-banking, le système bancaire central et le service d'authentification.

Ce que le diagramme rend visible, c'est l'ordre et le caractère synchrone ou asynchrone de l'échange, réunis sur une page. La chose qu'un lecteur manquerait sans le dessin tient à un seul message: le défi lancé au client, la notification push ou le code SMS, est asynchrone. Le système ne bloque pas tout le flux en l'attendant sur ce canal hors bande, alors que les appels entre les systèmes de la banque, eux, sont synchrones et bloquants. Le fragment alt porte la bifurcation d'issue: sur authentification réussie, le jeton validé remonte et le paiement se confirme jusqu'au client; sur échec, le refus remonte par le même chemin, en dénouant chaque appel bloquant.

Visualisations

La géométrie est le contenu. Le type d'un message se lit dans la forme de sa flèche: tête pleine sur trait plein pour l'appel synchrone qui bloque, tête ouverte sur trait plein pour l'envoi asynchrone, tête ouverte sur trait pointillé pour le retour. La ligne de vie en pointillé marque l'existence dans le temps, la barre d'exécution la période d'activité, et le cadre alt avec ses gardes partitionne les issues. Ces distinctions vivent dans le trait et la position; la figure doit donc être un dessin, où chaque forme reste fidèle à la notation.

Coût

Outils

Un tableau blanc suffit à une première ébauche: quatre participants et une dizaine de messages tiennent sur une feuille. Les outils de dessin généralistes, diagrams.net, Lucidchart ou Visio, portent des gabarits de séquence corrects, avec lignes de vie et têtes de flèche prêtes, mais leur apport s'arrête au dessin. Le texte-vers-diagramme, PlantUML ou Mermaid, décrit la séquence en quelques lignes de texte qu'un moteur met en image: le diagramme se relit dans un diff et se versionne comme du code, ce qui convient quand il évolue au fil des livraisons. Les ateliers de modélisation UML, Enterprise Architect ou Visual Paradigm, tiennent le diagramme comme un objet du modèle, tracé vers le cas d'utilisation qu'il raffine, et l'outil signale un appel synchrone sans retour ou un fragment sans garde.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.42 Sequence Diagrams: ce qu'un diagramme de séquence modélise, le raffinement d'un cas d'utilisation en un ou plusieurs diagrammes, les forces et les limites et la liste des éléments au niveau conceptuel.
• OMG, Unified Modeling Language (UML), Version 2.5.1, la clause Interactions: la notation normative, ligne de vie pointillée, spécification d'exécution, message synchrone à tête pleine, asynchrone à tête ouverte, retour pointillé et les fragments combinés alt, opt, loop et par avec leurs gardes.