Comportements et états¶

Modéliser ce qui se passe dans le temps — interactions entre objets, enchainements de messages, et transitions d'états.

Pourquoi modéliser le comportement¶

Les diagrammes de classes et de données capturent la structure statique du système. Mais un système ne se réduit pas a ses données — il vit, réagit, change d'état. Une commande passe de "en attente" a "payee" a "expediee". Un utilisateur s'authentifie, consulte, modifie, se déconnecté. Un service reçoit un message, le traite, en emet un autre.

Pour comprendre et concevoir ces dynamiques, on a besoin de deux outils complementaires :

• Les diagrammes de sequence : qui envoie quoi a qui, dans quel ordre.
• Les diagrammes d'états : dans quels états une entité peut se trouver, et ce qui provoque les transitions.

Les deux se completent. Le diagramme de sequence montre les interactions entre objets pour un scenario donne. Le diagramme d'états montre le cycle de vie complet d'une entité unique. On a besoin des deux pour comprendre le système.

Diagrammes de sequence UML¶

Le diagramme de sequence représenté les interactions entre objets (ou systèmes, ou acteurs) le long d'un axe temporel vertical. Chaque participant est une "lifeline" (ligne de vie), et les messages circulent horizontalement entre elles.

Éléments fondamentaux¶

Exemple : passer une commande¶

sequenceDiagram
    actor Client
    participant UI as Interface web
    participant API as API Gateway
    participant CMD as Service commande
    participant STK as Service stock
    participant PAY as Service paiement
    participant MSG as Service notification

    Client->>UI: Valider le panier
    UI->>API: POST /commandes
    API->>CMD: creerCommande(panier)
    CMD->>STK: verifierDisponibilite(articles)
    STK-->>CMD: disponibilite confirmee

    CMD->>PAY: initierPaiement(montant)
    PAY-->>CMD: reference paiement

    CMD->>CMD: enregistrer commande
    CMD-->>API: commande creee (id, statut)
    API-->>UI: 201 Created

    PAY--)MSG: paiement confirme (async)
    MSG--)Client: email de confirmation

Ce diagramme révélé plusieurs décisions d'architecture : la communication synchrone entre API et services internes, la communication asynchrone pour les notifications, le point de coordination dans le service commande.

Fragments d'interaction¶

Les fragments permettent de représenter des structures de contrôle dans un diagramme de sequence.

Exemple avec fragments¶

sequenceDiagram
    actor Client
    participant CMD as Service commande
    participant STK as Service stock
    participant PAY as Service paiement

    Client->>CMD: passer commande

    alt stock disponible
        CMD->>STK: reserver(articles)
        STK-->>CMD: reservation OK
        CMD->>PAY: debiter(montant)
        PAY-->>CMD: paiement OK
        CMD-->>Client: commande confirmee
    else stock insuffisant
        CMD-->>Client: commande refusee - stock
    end

Quand utiliser un diagramme de sequence vs un diagramme d'activité¶

La règle pragmatique : si on veut montrer qui parle a qui, on utilisé un diagramme de sequence. Si on veut montrer les étapes d'un processus, on utilise un diagramme d'activité (ou BPMN).

Diagrammes d'états¶

Un diagramme d'états (statechart) modélisé le cycle de vie d'une entité unique. Il répond à la question : dans quels états l'entité peut-elle se trouver, et quels événements provoquent les transitions entre états ?

Éléments fondamentaux¶

Exemple : cycle de vie d'une commande¶

stateDiagram-v2
    [*] --> Brouillon : creation

    Brouillon --> EnAttente : validation client
    Brouillon --> Annulee : abandon

    EnAttente --> Payee : paiement confirme
    EnAttente --> Annulee : timeout 30 min

    Payee --> EnPreparation : prise en charge logistique
    Payee --> Remboursee : annulation apres paiement

    EnPreparation --> Expediee : colis remis au transporteur

    Expediee --> Livree : confirmation livraison
    Expediee --> EnLitige : probleme livraison

    EnLitige --> Livree : resolution positive
    EnLitige --> Remboursee : resolution negative

    Livree --> [*]
    Annulee --> [*]
    Remboursee --> [*]

Ce diagramme rend explicite :

• Les états terminaux (Livree, Annulee, Remboursee)
• Les transitions conditionnelles (timeout, problème livraison)
• Les chemins de retour (litige vers livree ou rembourse)
• L'impossibilite de certaines transitions (on ne peut pas passer de Livree a EnPreparation)

Automates finis¶

Les diagrammes d'états UML sont une notation pour un concept mathématique : l'automate fini. Comprendre les automates aide à modéliser des systèmes corrects.

Définition formelle¶

Un automate fini deterministe est un quintuplet (Q, Sigma, delta, q0, F) :

• Q : ensemble fini d'états
• Sigma : alphabet (ensemble d'événements d'entree)
• delta : fonction de transition (Q x Sigma -> Q)
• q0 : état initial
• F : ensemble d'états finaux (acceptants)

Lien avec les machines a états logicielles¶

En développement, les machines a états apparaissent partout : parseurs, protocoles réseau, UI, workflows. La théorie des automates garantit des propriétés utiles :

États composites et avances¶

États composites¶

Un état composite contient des sous-états. Il permet de structurer une machine a états complexe en niveaux de détail. L'état "EnPreparation" peut contenir les sous-états "PriseEnCharge", "Emballage", "ControleQualite".

stateDiagram-v2
    [*] --> EnPreparation

    state EnPreparation {
        [*] --> PriseEnCharge
        PriseEnCharge --> Emballage : articles collectes
        Emballage --> ControleQualite : colis scelle
        ControleQualite --> [*] : controle OK
    }

    EnPreparation --> Expediee : preparation terminee
    Expediee --> [*]

Historique¶

L'état historique (H) memorise le dernier sous-état actif quand on quitte un état composite. Quand on y revient, on reprend ou on s'etait arrêté au lieu de recommencer depuis l'état initial interne.

Cas d'usage : un processus de commande interrompu par une vérification manuelle reprend à l'étape où il s'etait arrêté, pas au début.

Parallélisme (regions orthogonales)¶

Un état composite peut contenir des regions parallèles qui evoluent independamment. Par exemple, une commande en cours de traitement a simultanément un sous-état "logistique" (préparation, expedition) et un sous-état "financier" (facturation, encaissement).

Combiner sequences et états¶

Les diagrammes de sequence et les diagrammes d'états ne sont pas redondants — ils offrent deux vues complementaires du même système.

Le diagramme de sequence montre un scenario : "quand le client passe une commande, voici ce qui se passe entre les services". Le diagramme d'états montre le cycle de vie : "voici tous les états possibles d'une commande et toutes les transitions permises".

On les combine ainsi :

1. Identifier les entités avec un cycle de vie complexe (commande, demande, contrat) et créer un diagramme d'états pour chacune.
2. Pour chaque transition importante, créer un diagramme de sequence qui montre les interactions entre systèmes pour réaliser cette transition.
3. Vérifier la cohérence : chaque message dans un diagramme de sequence qui change l'état d'une entité doit correspondre a une transition valide dans le statechart.

graph LR
    SEQ[Diagramme de sequence] --"montre les interactions pour"--> TRANS[Transition d'etat]
    STATE[Diagramme d'etats] --"definit les transitions valides"--> TRANS
    TRANS --"valide les messages de"--> SEQ

Cette vérification croisee est un outil puissant de détection d'incoherences. Si un diagramme de sequence montre qu'on passe de "Expediee" a "EnPreparation", mais que le statechart ne permet pas cette transition, il y a un bug de conception.

Erreurs classiques¶

Chapitre suivant : Structure technique — composants, déploiement, C4 niveaux 3-4 et ArchiMate pour documenter l'architecture physique.