Le diagramme d'activité SysML : actions, flux de contrôle et flux d'objets

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

Vue plongeante sur un nœud ferroviaire où plusieurs voies se croisent, se séparent et se rejoignent entre deux quais — Un nœud ferroviaire à Chicago, vu d'en haut : des voies qui se séparent et se rejoignent, comme les flux d'un diagramme d'activité. Photo : Todd Diemer, via Wikimedia Commons, CC0.

La machine à états dit dans quel mode se trouve un système ; le diagramme d'activité dit ce qu'il fait, dans quel ordre, et avec quoi. C'est le diagramme de l'analyse fonctionnelle : il enchaîne des actions, fait circuler des matières, de l'énergie ou des données de l'une à l'autre, et montre ce qui peut se dérouler en parallèle. Bien construit, il devient la colonne vertébrale de l'architecture fonctionnelle et le point de départ des allocations vers les composants.

Ce que décrit un diagramme d'activité

Le diagramme d'activité (abrégé act) est l'un des quatre diagrammes de comportement de SysML v1, aux côtés des cas d'utilisation, des séquences et des machines à états ; nous les avons situés dans notre panorama des neuf diagrammes de SysML. Il reprend les activités d'UML 2 et leur ajoute quelques extensions utiles à l'ingénierie système, notamment pour les flux continus et les probabilités.

Une activité est un comportement composé d'actions reliées par des flux. Elle peut posséder des paramètres d'entrée et de sortie : une activité « Distribuer un café » reçoit de l'eau, du café en grains et un paiement, et produit une boisson. Chaque action peut elle-même appeler une autre activité : c'est l'action d'appel de comportement (call behavior action), qui permet de décomposer une fonction en sous-fonctions sur autant de niveaux que nécessaire.

La différence avec la machine à états tient à la question posée. La machine à états réagit à des événements et mémorise une situation ; l'activité décrit une transformation, de ses entrées à ses sorties. Les deux se combinent souvent : un état peut déclencher une activité (le comportement do), et une activité peut attendre un signal.

Jetons, flux de contrôle et flux d'objets

La sémantique des activités s'explique par des jetons, à la manière des réseaux de Petri. Une action démarre lorsqu'un jeton est disponible sur chacun de ses flux entrants requis ; à la fin, elle dépose des jetons sur ses flux sortants. Deux sortes de flux transportent ces jetons :

Le flux de contrôle ne transporte rien d'autre que l'autorisation de démarrer : il exprime un ordre, « après ceci, cela ».
Le flux d'objets transporte une chose typée : un fluide, une pièce, une commande, une mesure. Il relie les broches (pins), petits carrés posés sur le bord des actions, qui déclarent ce que chaque action consomme et produit.

Un piège classique découle de cette règle : si une action a deux flux entrants, elle attend des jetons sur les deux. Deux flèches qui convergent vers une action forment donc une jonction implicite, pas un « ou ». Pour exprimer une alternative, il faut un nœud de fusion.

Les nœuds de contrôle

Nœud	Notation	Rôle
Initial	Disque plein	Dépose un jeton au démarrage de l'activité
Fin d'activité	Disque cerclé	Termine toute l'activité, y compris les branches encore actives
Fin de flux	Cercle barré d'une croix	Détruit le jeton qui l'atteint, sans arrêter le reste
Bifurcation (fork)	Barre épaisse, une entrée, plusieurs sorties	Duplique le jeton : les branches s'exécutent en parallèle
Jonction (join)	Barre épaisse, plusieurs entrées, une sortie	Attend toutes les branches avant de continuer
Décision	Losange, une entrée	Oriente le jeton vers une seule sortie selon des gardes exclusives
Fusion (merge)	Losange, plusieurs entrées	Laisse passer le premier jeton arrivé, sans synchroniser

Confondre fin d'activité et fin de flux est une erreur fréquente : une branche secondaire qui se termine par un disque cerclé interrompt toute l'activité, y compris le traitement principal.

Ce que SysML ajoute aux activités d'UML

Pour décrire des systèmes physiques, SysML complète la sémantique d'UML sur quelques points précis :

Flux continus et discrets. Un flux marqué «continuous» représente un écoulement dont le temps entre deux jetons tend vers zéro : un débit d'eau, un courant électrique. Les propriétés de rate précisent un débit attendu.
Probabilités. Les sorties d'un nœud de décision peuvent porter une probabilité, utile pour les analyses de fiabilité ou de performance.
Entrées et sorties facultatives. Le stéréotype «optional» indique qu'une action peut démarrer sans jeton sur une broche donnée.
Opérateurs de contrôle. Une action «controlOperator» produit des valeurs de contrôle qui activent ou désactivent d'autres actions, par exemple pour couper une pompe.
Tampons. Les stéréotypes «nobuffer» et «overwrite» disent ce qu'il advient des jetons qui arrivent sur un nœud d'objet déjà plein : ils sont perdus, ou remplacent les plus anciens.

La spécification propose aussi un profil pour les diagrammes de blocs fonctionnels étendus (EFFBD), une notation antérieure à SysML encore employée dans certaines équipes ; un diagramme d'activité qui respecte ses contraintes peut être relu par les habitués de cette notation.

Partitions et allocation : de la fonction au composant

Les partitions, appelées familièrement « couloirs de nage », découpent le diagramme en bandes : chaque bande représente un élément de structure, et les actions placées dans une bande lui sont attribuées. Dans l'exemple de la machine à café, une bande « Monnayeur » recevrait l'action de vérification du paiement, une bande « Chaudière » celle du chauffage de l'eau, une bande « Moulin » celle de la mouture.

En SysML v1, une partition marquée «allocate» exprime une relation d'allocation : la fonction est confiée au bloc, sans préjuger de la manière dont il la réalise. C'est exactement le passage de l'architecture fonctionnelle à l'architecture logique ou physique, que nous avons détaillé dans notre article sur les trois vues d'un système. Les flux d'objets qui traversent la frontière entre deux bandes signalent alors une interface à prévoir entre les deux composants : l'eau chaude qui passe de la chaudière au groupe d'infusion devra circuler par un port, décrit dans le diagramme de blocs internes.

Interruptions et régions

Une région interruptible, dessinée comme un cadre en pointillés, englobe un groupe d'actions qu'un événement peut arrêter d'un coup : l'appui sur « Annuler » interrompt la préparation et mène à une action de remboursement. Ce mécanisme évite de multiplier les décisions à chaque étape pour tester une annulation.

Le même exemple en SysML v2

SysML v2 conserve les notions d'action, de succession et de flux, mais les écrit avec des définitions et des usages. Une action def définit un type d'action, first … then … exprime une succession, fork, join, decide et merge sont des nœuds de contrôle, et flow relie les paramètres. Voici une esquisse du cycle de la machine à café :

action def DistribuerCafe {
    action verifierPaiement;
    action chaufferEau { out eauChaude : Eau; }
    action moudreCafe { out mouture : Mouture; }
    action infuser { in eauChaude : Eau; in mouture : Mouture; }

    first start then verifierPaiement;
    first verifierPaiement then preparation;
    fork preparation;
        then chaufferEau;
        then moudreCafe;
    first chaufferEau then pret;
    first moudreCafe then pret;
    join pret;
    then infuser;

    flow from chaufferEau.eauChaude to infuser.eauChaude;
    flow from moudreCafe.mouture to infuser.mouture;
}

Les types Eau et Mouture seraient déclarés ailleurs par des item def. Une définition de partie indique qu'elle réalise une action avec perform action, ce qui remplace l'allocation par partition de SysML v1. Les différences de fond entre les deux versions du langage sont détaillées dans notre article sur ce que change SysML v2.

Cinq erreurs à éviter

Dessiner un organigramme de programme. Au niveau système, les actions sont des fonctions (« chauffer l'eau »), pas des instructions ni des tests de variables.
Oublier les flux d'objets. Un diagramme fait seulement de flux de contrôle dit l'ordre, mais pas ce qui circule ; ce sont pourtant les flux d'objets qui révèlent les interfaces.
Créer des jonctions implicites. Deux flux entrants sur une action, c'est un « et » ; pour un « ou », placer une fusion.
Laisser des gardes incomplètes. Les sorties d'une décision doivent couvrir tous les cas, avec une branche [else] si nécessaire, sinon le jeton reste bloqué.
Tout mettre sur un seul diagramme. Au-delà d'une dizaine d'actions, décomposer avec des actions d'appel : chaque niveau reste lisible, et le modèle garde la trace de la hiérarchie fonctionnelle.

Un diagramme qui s'exécute

Parce que sa sémantique est définie par les jetons, une activité peut être simulée : plusieurs outils de modélisation jouent l'enchaînement des actions et révèlent les blocages, comme une jonction qui attend une branche jamais déclenchée. La norme fUML (Foundational UML) de l'OMG précise d'ailleurs une sémantique d'exécution pour un sous-ensemble des activités d'UML.

Sources

Object Management Group, OMG Systems Modeling Language (SysML), versions 1.x (chapitre « Activities » : flux continus, probabilités, «optional», «controlOperator», «nobuffer», «overwrite», EFFBD, allocation par partition) et 2.0 (actions, successions, nœuds de contrôle et flux) : omg.org/spec/SysML.
Object Management Group, Unified Modeling Language (UML) 2.5.1, chapitres « Activities » et « Actions » : sémantique des jetons, nœuds de contrôle, broches, régions interruptibles : omg.org/spec/UML.
Object Management Group, Semantics of a Foundational Subset for Executable UML Models (fUML).