UML : diagrammes d'activité et d'états

Deux diagrammes décrivent le comportement : le diagramme d’activité (un processus, étape par étape) et le diagramme d’états (le cycle de vie d’un objet).

Diagramme d’activité

Un processus comme un enchaînement d’actions, avec décisions et parallélisme (proche d’un algorithme ou d’un logigramme).

Élément	Symbole
Début	Disque plein
Fin	Disque cerclé
Action	Rectangle aux coins arrondis
Décision / fusion	Losange
Fourche / jointure (parallélisme)	Barre épaisse
Couloir (qui fait l’action)	Colonne ou ligne nommée
Flux	Flèche

Exemple : traiter une commande

@startuml
|Client|
start
:Valider le panier;
|Système|
:Vérifier le stock;
if (Stock suffisant ?) then (oui)
  :Enregistrer la commande;
  |Client|
  :Payer;
  |Système|
  if (Paiement accepté ?) then (oui)
    fork
      :Préparer le colis;
    fork again
      :Envoyer la confirmation;
    end fork
    :Expédier;
  else (non)
    :Annuler la commande;
  endif
else (non)
  :Signaler la rupture;
endif
stop
@enduml

Syntaxe PlantUML	Sens
`start` / `stop`	Début / fin
`:Action;`	Action
`if (…) then (oui) … else (non) … endif`	Décision
`fork` / `fork again` / `end fork`	Parallélisme
`\|Couloir\|`	Couloir
`repeat` … `repeat while (…)` ou `while (…)`	Boucles

Les couloirs répondent à la question « qui fait quoi » : utile pour un processus qui implique plusieurs acteurs ou services.

Quand l’utiliser

Bon usage	Mauvais usage
Décrire un processus métier (traitement d’une commande, inscription)	Détailler chaque ligne de code
Mettre en évidence décisions et traitements parallèles	Décrire des interactions entre objets (utiliser la séquence)
Préparer les scénarios alternatifs d’un cas d’utilisation	Un schéma de plus de 20 actions

Diagramme d’états

Le cycle de vie d’un objet : ses états, et les événements qui le font passer de l’un à l’autre.

Élément	Sens
État	Situation durable de l’objet (rectangle arrondi)
Transition	Flèche d’un état à un autre
Événement	Ce qui déclenche la transition (étiquette)
Garde	Condition entre crochets `[…]`
Effet	Action effectuée pendant la transition, après `/`
État initial / final	Disque plein / disque cerclé

Étiquette d’une transition : événement [garde] / effet.

Exemple : cycle de vie d’une commande

@startuml
[*] --> Nouvelle : créer
Nouvelle --> Payee : payer [paiement accepté] / décrémenter le stock
Nouvelle --> Annulee : annuler
Payee --> Expediee : expédier / envoyer le suivi
Payee --> Annulee : annuler [avant expédition] / rembourser
Expediee --> Livree : livrer
Expediee --> Retournee : retourner
Livree --> [*]
Annulee --> [*]
Retournee --> [*]
@enduml

Ce diagramme répond aux questions que les règles de gestion laissent ouvertes :

Question	Réponse du diagramme
Peut-on annuler une commande expédiée ?	Non : pas de transition `Expediee → Annulee`
Peut-on repasser de `Payee` à `Nouvelle` ?	Non
Quels états sont terminaux ?	`Livree`, `Annulee`, `Retournee`
Que se passe-t-il au paiement ?	Le stock est décrémenté

États et base de données

Le diagramme d’états sert à définir les valeurs d’une colonne de statut et les changements autorisés.

CREATE TABLE commande (
    num_commande bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    statut varchar(20) NOT NULL DEFAULT 'nouvelle'
        CHECK (statut IN ('nouvelle', 'payee', 'expediee', 'livree', 'annulee', 'retournee'))
);

Une contrainte CHECK limite les valeurs, mais pas les transitions. Contrôler les transitions :

dans le code (voir ci-dessous) ;
ou dans la base avec un déclencheur (TRIGGER) qui refuse une transition interdite ;
avec une table de transitions autorisées et une clé étrangère composite (statut_precedent, statut).

États dans le code

type Statut =
  'nouvelle' | 'payee' | 'expediee' | 'livree' | 'annulee' | 'retournee';

const TRANSITIONS: Record<Statut, readonly Statut[]> = {
  nouvelle: ['payee', 'annulee'],
  payee: ['expediee', 'annulee'],
  expediee: ['livree', 'retournee'],
  livree: [],
  annulee: [],
  retournee: [],
};

class Commande {
  constructor(
    public readonly numero: string,
    private _statut: Statut = 'nouvelle',
  ) {}

  get statut(): Statut {
    return this._statut;
  }

  changerStatut(cible: Statut): void {
    if (!TRANSITIONS[this._statut].includes(cible)) {
      throw new Error(`transition interdite : ${this._statut} -> ${cible}`);
    }
    this._statut = cible;
  }
}

La table TRANSITIONS est le diagramme d’états sous forme de données : une transition non prévue est refusée à un seul endroit. Voir POO : encapsulation et héritage (protéger les invariants) et TypeScript : types de base (unions de littéraux).

Le patron « état »

Quand chaque état a un comportement différent, une classe par état :

interface EtatCommande {
  payer(c: CommandeContexte): void;
  expedier(c: CommandeContexte): void;
  annuler(c: CommandeContexte): void;
}

Chaque classe implémente les opérations autorisées dans cet état et lève une erreur pour les autres (voir POO : composition et patrons). Pour la plupart des cas, la table de transitions suffit.

États imbriqués et historique

UML permet des états composites (un état qui contient des sous-états) et des états d’historique :

@startuml
state Expediee {
  [*] --> EnPreparation
  EnPreparation --> EnTransit : colis remis
  EnTransit --> EnLivraison : arrivé au dépôt
}
Payee --> Expediee : expédier
Expediee --> Livree : livrer
@enduml

Utile pour garder un diagramme lisible quand un état a lui-même un déroulement.

Activité ou états ?

Question	Diagramme
Quelle est la suite d’actions d’un processus ?	Activité
Quels statuts un objet traverse-t-il ?	États
Qui fait quoi ?	Activité avec couloirs
Quelles transitions sont interdites ?	États

Bonnes pratiques

Un diagramme d’états par classe qui a un vrai cycle de vie (commande, abonnement, ticket), pas pour toutes.
Nommer les états comme des situations (« Payée »), pas comme des actions (« Payer »).
Nommer les événements comme des actions (« payer »).
Indiquer les états terminaux.
Déduire de ces diagrammes les contraintes de la base et les tests.
Un diagramme d’activité pour la vue d’ensemble du processus, un diagramme de séquence pour les détails techniques.

Dépannage

Symptôme	Piste
Diagramme d’états « en toile d’araignée »	Trop d’états ou de transitions : imbriquer, regrouper
États qui ressemblent à des actions	Les nommer comme des situations durables
Transitions manquantes découvertes en production	Les écrire dans le diagramme et les tester (Vitest : écrire des tests)
Un statut modifié directement en base	Contrôle des transitions : code central, déclencheur
Diagramme d’activité énorme	Découper en sous-activités (`detach`, appel d’une autre activité)
Couloirs illisibles	Limiter à 3 ou 4 acteurs

Ubuntu 24.04 et 26.04 : différences à connaître

Aucune.