Diagramme d'états-transitions : la machine à états d'un objet

Le diagramme d'états-transitions (ou machine à états, state machine diagram) décrit le cycle de vie d'un objet : les états par lesquels il passe, et les transitions qui le font changer d'état, déclenchées par des événements, sous certaines conditions, avec certains effets. On le dessine pour les objets dont le comportement dépend de leur état : une commande, un ticket, une réservation, une fiche de frais. Ce chapitre présente la notation, la syntaxe d'une transition, la traduction en code et les vérifications qui en découlent.

États et transitions

Un état est une situation durable dans la vie de l'objet, pendant laquelle il réagit d'une certaine façon aux événements. Il se dessine par un rectangle aux coins arrondis, nommé par un adjectif ou un participe : « Créée », « Clôturée », « Validée ». Une fiche clôturée accepte d'être validée ; une fiche créée, non.

Une transition est le passage d'un état à un autre. Elle se dessine par une flèche et porte un libellé de la forme :

événement [garde] / effet

• l'événement (trigger) déclenche la transition : l'appel d'une opération (Valider(comptable)), un signal reçu (virement confirmé), un événement temporel (when(1er du mois), after(30 jours)) ;
• la garde est une condition, entre crochets : la transition n'a lieu que si elle est vraie au moment de l'événement ;
• l'effet est l'action exécutée pendant la transition, après la barre oblique.

Les trois parties sont facultatives. Une transition sans événement est franchie dès que l'action de l'état est terminée.

Le cycle de vie d'une fiche de frais

La fiche de frais d'AppliFrais passe par cinq états, que la base de données code sur deux lettres (CR, CL, VA, MP, RB) et que le code C# représente par l'énumération EtatFiche.

Ce que le diagramme dit, et que le code doit respecter :

• une fiche naît à l'état Créée quand le visiteur l'ouvre ; tant qu'elle y est, il peut saisir et modifier ses frais (transitions internes : la fiche ne change pas d'état) ;
• quand il a terminé, le visiteur appelle Cloturer() ; le 1er du mois suivant, le planificateur le fait pour les fiches restées ouvertes. La fiche passe à l'état Clôturée, et on ne peut plus ajouter de frais ;
• dans cet état, le comptable peut refuser une ligne hors forfait (transition interne), puis il la valide : elle passe à Validée, et son montant validé est calculé pendant la transition ; en entrant dans cet état, le visiteur est notifié (le code du chapitre 6 laisse cette notification à un service de messagerie, qu'il ne montre pas) ;
• elle est mise en paiement, puis remboursée quand le service de paie confirme le virement ;
• aucune flèche ne revient en arrière : une fiche validée ne peut pas être rouverte. C'est une règle de gestion, que le diagramme rend évidente ;
• au bout de dix ans, durée de conservation des pièces comptables, la fiche est archivée et sort de l'application : c'est l'état final.

Les états composites

Un état composite regroupe plusieurs sous-états qui partagent un comportement. Clôturée, Validée et Mise en paiement ont un point commun : la fiche est verrouillée, le visiteur ne peut plus rien modifier. On pourrait les regrouper dans un état composite « Verrouillée ». Une transition qui part du contour de l'état composite s'applique à tous ses sous-états : par exemple, une transition Annuler() [fraude constatée] vers un état « Annulée » partant du contour de « Verrouillée » s'appliquerait que la fiche soit clôturée, validée ou mise en paiement.

Les états composites évitent de multiplier les flèches identiques. Au BTS, il suffit de savoir les lire.

De la machine à états au code

Une machine à états se traduit de deux façons.

Avec une énumération et des gardes dans chaque opération. C'est la méthode d'AppliFrais (chapitre 6) : l'état est un attribut de type EtatFiche, et chaque opération qui déclenche une transition vérifie d'abord l'état de départ, puis fait l'effet, puis change l'état.

public void Valider(Comptable comptable)
{
    VerifierEtat(EtatFiche.Cloturee);     // la transition ne part que de Clôturée
    MontantValide = Total();              // l'effet : / montantValide := Total()
    ValideePar = comptable;
    Etat = EtatFiche.Validee;             // l'état d'arrivée
}

Une opération appelée dans un état d'où ne part aucune transition correspondante lève une exception : c'est la traduction de « tout ce qui n'est pas dessiné est interdit ».

Avec une table de transitions. Quand les transitions sont nombreuses, on les range dans une table (état de départ, événement) → état d'arrivée, que le code consulte. C'est le principe des bibliothèques de machines à états. Pour une machine de cinq ou six états, la première méthode est plus simple et plus lisible.

Le patron de conception État (State) va plus loin : une classe par état, chacune implémentant les opérations à sa façon. Il est utile quand le comportement de chaque état est riche, rarement au BTS.

Écrire les tests à partir du diagramme

Le diagramme d'états-transitions donne directement la liste des tests unitaires à écrire :

• un test par transition dessinée : à partir de l'état de départ, l'opération mène à l'état d'arrivée et produit son effet (une fiche clôturée validée par Inès passe à Validée, avec le bon montant) ;
• un test par transition interdite importante : une fiche créée qu'on tente de valider lève une exception et reste Créée ; une fiche validée qu'on tente de clôturer aussi ;
• un test par garde : la garde vraie, puis la garde fausse.

Avec cinq états, quatre transitions entre eux et trois transitions internes, une douzaine de tests couvrent tout le cycle de vie. Le cours Tests montre comment les écrire (écrire un bon test unitaire).

Exercices

public enum EtatTicket { Ouvert, EnCours, EnAttente, Resolu, Clos }

public class Ticket
{
    public EtatTicket Etat { get; private set; } = EtatTicket.Ouvert;
    public Technicien? Technicien { get; private set; }
    public string? Solution { get; private set; }
    public int NbReouvertures { get; private set; }

    public void PrendreEnCharge(Technicien technicien)
    {
        VerifierEtat(EtatTicket.Ouvert);
        Technicien = technicien;
        Etat = EtatTicket.EnCours;
    }

    public void Resoudre(string solution)
    {
        VerifierEtat(EtatTicket.EnCours);
        Solution = solution;
        Etat = EtatTicket.Resolu;
        // effet : avertir l'utilisateur (par un service de messagerie)
    }

    public void Rouvrir(string motif)
    {
        VerifierEtat(EtatTicket.Resolu);
        NbReouvertures++;
        Solution = null;
        Etat = EtatTicket.EnCours;
    }

    private void VerifierEtat(EtatTicket attendu)
    {
        if (Etat != attendu)
            throw new InvalidOperationException($"Ticket à l'état {Etat}, {attendu} attendu.");
    }
}