Le diagramme de séquence SysML : lignes de vie, messages et fragments combinés

SysML & modélisation · Par la rédaction de Vue Système · Publié le 2026-11-07

Photographie ancienne en noir et blanc : trois standardistes assises devant un grand standard téléphonique manuel, l'une d'elles branche un cordon — Des standardistes de Fort Richardson, en Alaska, établissent des communications sur un standard manuel : qui appelle qui, dans quel ordre, c'est exactement ce que trace un diagramme de séquence. Photographie de l'armée américaine (David Bedard), domaine public, via Wikimedia Commons.

Le diagramme d'activité décrit ce que fait un système ; la machine à états, dans quel mode il se trouve. Le diagramme de séquence répond à une troisième question : qui envoie quoi à qui, et dans quel ordre, au cours d'un scénario précis. C'est le diagramme des interfaces vues dans le temps, celui qu'on dessine pour un démarrage, une procédure de panne ou un dialogue entre un équipement et son opérateur. Facile à lire, il est aussi facile à mal employer.

Ce que montre un diagramme de séquence

Le diagramme de séquence (abrégé sd) est l'un des quatre diagrammes de comportement de SysML v1, avec les cas d'utilisation, les activités et les machines à états ; nous les avons présentés ensemble dans le panorama des neuf diagrammes de SysML. Il représente une interaction : un ensemble d'échanges entre plusieurs participants, ordonnés le long d'un axe du temps qui descend du haut vers le bas de la page.

SysML reprend presque tel quel le diagramme de séquence d'UML 2. Il laisse en revanche de côté trois autres diagrammes d'interaction d'UML, jugés redondants pour l'ingénierie système : le diagramme de communication, le diagramme de temps (timing) et le diagramme de vue d'ensemble des interactions.

Un diagramme de séquence ne décrit pas tous les comportements possibles : il raconte un scénario, ou une petite famille de scénarios voisins. C'est sa force et sa limite. Pour couvrir l'ensemble des cas, on combine plusieurs séquences, ou l'on passe à une activité ou à une machine à états.

Lignes de vie et messages

Chaque participant est une ligne de vie : un rectangle en tête de diagramme, prolongé d'un trait pointillé vertical. En SysML, une ligne de vie représente le plus souvent une partie du bloc qui possède l'interaction : pour un scénario de recharge, le véhicule, la borne et le système de supervision, définis comme parties d'un bloc « Système de recharge ». C'est ce lien avec la structure qui rend le diagramme vérifiable : un message ne peut circuler qu'entre des parties effectivement reliées, comme le montrent les ports et connecteurs décrits dans notre article sur blocs, ports et flux.

Les messages sont des flèches horizontales d'une ligne de vie à l'autre. Leur forme dit leur nature :

Message	Notation	Signification
Appel synchrone	Trait plein, pointe pleine	L'émetteur appelle une opération et attend la fin du traitement
Message asynchrone	Trait plein, pointe ouverte	L'émetteur envoie un signal et poursuit sans attendre
Réponse	Trait pointillé	Retour d'un appel synchrone, avec d'éventuelles valeurs
Création	Trait pointillé vers la tête d'une ligne de vie	Le participant naît pendant le scénario
Destruction	Croix en bas de la ligne de vie	Le participant cesse d'exister
Message perdu ou trouvé	Flèche vers ou depuis un disque plein	Le destinataire ou l'émetteur est hors du diagramme ou inconnu

Sur la ligne de vie, un rectangle étroit, la spécification d'exécution, indique la période pendant laquelle le participant est occupé à traiter quelque chose. Elle aide à voir qui travaille quand, mais charge vite un diagramme : au niveau système, beaucoup d'équipes ne la dessinent que lorsqu'elle apporte une information.

Un ordre partiel, pas un chronogramme

Point souvent mal compris : la position verticale n'est pas une échelle de temps. Sur une même ligne de vie, ce qui est plus bas arrive après ce qui est plus haut. Entre deux lignes de vie différentes, en revanche, deux événements sans lien de cause ne sont pas ordonnés, même si l'un est dessiné au-dessus de l'autre. La seule certitude entre participants vient des messages : l'émission précède toujours la réception. Pour exprimer une durée ou une échéance, il faut une contrainte explicite.

Fragments combinés : alternatives, boucles et parallélisme

Un scénario réel comporte des variantes. Plutôt que de dessiner un diagramme par cas, on encadre une partie des échanges dans un fragment combiné : un rectangle dont le coin supérieur gauche porte un opérateur, et qui se découpe en opérandes séparés par des traits pointillés, chacun pouvant porter une garde entre crochets.

alt : alternative. Un seul opérande s'exécute, celui dont la garde est vraie ; [else] couvre les autres cas.
opt : option. Le contenu s'exécute seulement si la garde est vraie.
loop : répétition, avec un nombre minimal et maximal d'itérations, par exemple loop(1,3) pour trois tentatives de connexion au plus.
par : les opérandes se déroulent en parallèle, sans ordre imposé entre eux.
break : si la garde est vraie, le contenu s'exécute à la place de la suite du fragment englobant ; utile pour une procédure d'abandon.
critical : région qui ne doit pas être entrelacée avec d'autres événements.
neg et assert : le premier décrit une trace interdite, le second la seule trace valide à cet endroit. Ce sont des outils de spécification plus que de description.

D'autres opérateurs (seq, strict, ignore, consider) précisent l'ordre ou filtrent les messages pris en compte. Ils sont rarement utiles au niveau système ; mieux vaut s'en tenir aux opérateurs que tous les lecteurs comprennent.

Réutiliser et contraindre

Une utilisation d'interaction, encadrée et marquée ref, insère une autre séquence par son nom : « Authentifier l'utilisateur » ou « Initialiser la communication » se dessinent une fois et se réutilisent partout. C'est l'équivalent, pour les séquences, de l'action d'appel qui permet de décomposer un diagramme d'activité. Des portes (gates) relient les messages qui entrent ou sortent du fragment référencé.

Deux sortes de contraintes rendent le temps explicite. Une contrainte de durée borne l'écart entre deux événements, par exemple {0..2 s} entre une commande et son acquittement. Une contrainte de temps fixe l'instant d'un événement par rapport à une observation. Enfin, un invariant d'état, posé sur une ligne de vie, impose qu'un participant se trouve dans un état donné à ce moment du scénario : c'est un pont direct vers la machine à états du composant concerné.

À quoi il sert dans un projet

Dans une démarche d'ingénierie système, le diagramme de séquence intervient à plusieurs moments :

Détailler un cas d'utilisation. Chaque cas d'utilisation se raconte par un scénario nominal et quelques scénarios alternatifs, échangés entre les acteurs et le système vu comme une boîte noire.
Découvrir les interfaces. En passant de la boîte noire à la boîte blanche, les messages entre parties révèlent les opérations et les signaux que chaque interface doit offrir.
Spécifier un protocole. Un dialogue entre deux équipements, avec ses délais et ses cas d'erreur, se décrit naturellement en séquences.
Préparer les essais. Un scénario nominal ou dégradé devient la base d'un cas de test : stimuli, réponses attendues, délais à respecter.

Et en SysML v2 ?

SysML v2 ne reprend pas la liste fermée des diagrammes de la version 1 : il définit des vues, dont une vue de séquence. Le fond reste proche : des occurrences d'événements, des messages entre participants, des successions qui ordonnent ces événements. La différence tient au modèle sous-jacent, qui unifie actions, états et interactions dans un même langage et dispose d'une notation textuelle. Une séquence n'y est plus un dessin à part, mais une manière de montrer des échanges déjà définis ailleurs dans le modèle.

Cinq erreurs à éviter

Vouloir tout couvrir dans un seul diagramme. Au-delà de deux ou trois fragments imbriqués, la séquence devient illisible : découper avec des références.
Lire la verticale comme une échelle de temps. Une durée se déclare par une contrainte, pas par l'espacement des flèches.
Créer des lignes de vie sans lien avec la structure. Si le participant n'est pas une partie du modèle, rien ne permet de vérifier que les messages sont possibles.
Confondre appel synchrone et signal. La différence change le comportement de l'émetteur, et donc les cas de blocage.
Oublier les scénarios dégradés. Le scénario nominal est le moins utile pour la sûreté : ce sont les pannes, les délais dépassés et les messages perdus qui méritent d'être dessinés.

Séquence ou activité ?

Les deux diagrammes peuvent décrire le même enchaînement. La séquence met en avant les participants et leurs échanges ; l'activité met en avant les fonctions et ce qui circule entre elles. Quand la question est « qui parle à qui », on choisit la séquence ; quand elle est « que faut-il faire, et avec quoi », l'activité.

Sources

Object Management Group, OMG Systems Modeling Language (SysML), versions 1.x (chapitre « Interactions » : diagramme de séquence retenu, diagrammes de communication, de temps et de vue d'ensemble exclus) et 2.0 (occurrences, messages, vue de séquence) : omg.org/spec/SysML.
Object Management Group, Unified Modeling Language (UML) 2.5.1, chapitre « Interactions » : lignes de vie, messages, spécifications d'exécution, fragments combinés et opérateurs d'interaction, utilisations d'interaction, contraintes de durée et de temps : omg.org/spec/UML.