Les diagrammes d'états

Tous les diagrammes vus jusqu'ici décrivent un instant : les concepts du métier, les classes du logiciel, l'ordre des messages d'une opération. Celui-ci décrit une durée — la vie entière d'un objet, depuis sa naissance jusqu'à ce qu'il n'ait plus rien à faire. Et il répond à la question que les autres ne posent pas : pourquoi le même appel réussit aujourd'hui et échoue demain.

L'objet qui se souvient

Prends deux objets du même modèle du domaine. Un Livre à qui l'on demande son titre répond toujours la même chose : la réponse ne dépend que de ses données, jamais de ce qui lui est arrivé avant. Un Emprunt à qui l'on demande prolonger(7), lui, répond parfois oui et parfois non — et l'appel est rigoureusement identique dans les deux cas. Ce qui a changé n'est pas l'argument, c'est l'histoire de l'objet.

C'est exactement le tri. Un objet dont la réponse au même message dépend de ce qu'il a vécu est un objet à états : il mérite un diagramme d'états. Un objet dont la réponse ne dépend que de ses arguments et de ses données n'en a aucun besoin, et lui en dessiner un produit un diagramme à un seul état, c'est-à-dire rien.

Le symptôme dans le code est très reconnaissable, et c'est souvent par lui qu'on découvre qu'on avait affaire à un objet à états sans l'avoir vu :

public void prolonger(int jours) {
    if (statut.equals("rendu")) {
        throw new IllegalStateException("déjà rendu");
    }
    if (statut.equals("perdu")) {
        throw new IllegalStateException("déclaré perdu");
    }
    if (statut.equals("enRetard")) {
        return;                    // on ignore, sans rien dire
    }
    if (statut.equals("prolonge")) {
        return;                    // une seule prolongation
    }
    dateRetourPrevue = dateRetourPrevue.plusDays(jours);
    statut = "prolonge";
}

Chaque méthode de la classe rouvre la même cascade, avec les mêmes chaînes de caractères et pas tout à fait les mêmes cas. La règle du cycle de vie existe bel et bien — elle est simplement éparpillée, réécrite à chaque méthode, et rien ne dit si les copies sont d'accord entre elles. Le diagramme d'états est la spécification que ce code applique sans la porter : une fois dessinée, elle se lit d'un coup d'œil, et les oublis se voient.

class Livre {
    String titre;
    String isbn;
    String auteurPrincipal() { ... }
    boolean correspondA(String recherche) { ... }
}

class Reservation {
    Date poseeLe;
    String statut;
    void confirmer() { ... }
    void annuler() { ... }
    boolean peutEtreConfirmee() { ... }
}

L'état, et ce qui n'en est pas un

Un état est une situation dans laquelle un objet se trouve pendant un certain temps, et qui détermine sa réaction aux événements qu'il peut recevoir. Il se dessine par un rectangle aux coins arrondis portant son nom, et ce nom s'écrit presque toujours au participe passé ou avec un adjectif — Rendu, En retard, Perdu — parce qu'il décrit une manière d'être, jamais une action.

Cette dernière phrase n'est pas une préférence de style. C'est la ligne de partage qui coûte le plus de points à l'examen, parce que deux diagrammes du cours acceptent des boîtes qui se ressemblent : le diagramme d'états et le diagramme d'activités. Voici ce qui les sépare, et il faut savoir le dire en une phrase.

Le test le plus rapide, quand on hésite devant un énoncé : demande-toi qui est le sujet de chaque boîte. Si c'est toujours le même objet, à des moments différents de sa vie, c'est un diagramme d'états. Si les boîtes changent de sujet — le magasinier vérifie, puis le préparateur emballe, puis le transporteur livre — c'est un processus, donc un diagramme d'activités.

(A) « Une commande est validée, puis payée, puis expédiée,
     puis livrée. Elle peut être annulée tant qu'elle
     n'est pas payée. »

(B) « Le magasinier vérifie le stock, puis le préparateur
     emballe la commande, puis le transporteur la livre.
     Si le stock manque, le service achats commande. »

La transition, et son étiquette en trois parties

Une transition est une flèche d'un état vers un autre. Elle porte une étiquette, et cette étiquette est le cœur de toute la notation : c'est elle qu'on lit de travers, c'est elle qu'on écrit incomplète, et c'est sur elle que les questions d'examen portent. Elle a trois parties, et deux ponctuations seulement les séparent — les crochets et la barre oblique.

événement [garde] / action

  ÉVÉNEMENT   ce qui ARRIVE à l'objet
      rendre()              un appel
      après(30 jours)       le temps
      quand(solde < 0)      une condition
                            devenue vraie

  [GARDE]     une condition BOOLÉENNE, testée
              quand l'événement arrive.
              Fausse : rien ne se passe.
      [prolongations < 1]

  / ACTION    ce qui S'EXÉCUTE pendant le
              passage. Instantané.
      / facturerAmende()

ÉTIQUETTES COMPLÈTES
      rendre()
      rendre() / facturerAmende()
      prolonger(j) [prolongations < 1]
      payer(m) [solde >= m] / debiter(m)

Les trois parties se confondent d'autant plus facilement qu'elles se ressemblent à l'écrit : rendre(), facturerAmende() et prolongations < 1 ont toutes l'air d'être du code. Le seul moyen sûr de les distinguer est la position par rapport aux deux signes. Avant les crochets : ce qui arrive. Entre les crochets : ce qu'on vérifie. Après la barre oblique : ce qu'on fait.

Il reste une question à laquelle on répond mal une fois sur deux : que devient l'événement quand la garde est fausse ? Il est consommé et perdu. L'objet ne bouge pas, l'action ne s'exécute pas, et rien n'est mis en attente pour plus tard : l'événement a été présenté, aucune transition ne l'a pris, il disparaît. C'est exactement ce qui arrive à un événement pour lequel l'état courant n'a aucune flèche — et c'est le point le plus rentable de tout le module, parce qu'une question d'examen sur trois s'y joue.

(A) declarerPerdu() / facturerRemplacement()
(B) après(dateRetourPrevue)
(C) prolonger(jours) [prolongations < 1]
(D) rendre() [enRetard] / facturerAmende()
(E) / envoyerAccuseReception()

entry, do, exit — le ponctuel et le continu

Jusqu'ici, tout ce qui s'exécute est accroché à une flèche. On peut aussi accrocher du comportement à un état lui-même, et c'est utile dès qu'une même chose doit se produire quelle que soit la porte par laquelle on entre. Trois mots-clés, écrits sous le nom de l'état et séparés de lui par un trait :

• entry / action — à l'entrée dans l'état, par n'importe quelle transition.
• exit / action — à la sortie, par n'importe quelle transition.
• do / action — pendant le séjour, tant que l'objet est là.

La différence entre les deux premiers et le troisième n'est pas une nuance : entry et exit sont ponctuels et ininterruptibles — ils occupent un instant, et aucun événement ne peut les couper. do est continu et interruptible — il dure autant que le séjour, et un événement qui fait sortir de l'état l'arrête là où il en est. C'est exactement ce que la figure suivante rend visible.

état EnService
   entry / allumerVoyant()
   do    / surveillerDebit()
   exit  / eteindreVoyant()

EnService  raccrocher() / imprimerRecu()  ▶ Libre
EnService  panne()                        ▶ HorsService

Les pseudo-états, et l'auto-transition

Deux marques ne sont pas des états, bien qu'elles occupent une place sur le diagramme. Le pseudo-état initial est un disque plein : il ne désigne aucune situation, il dit seulement dans quel état l'objet naît. Le pseudo-état final est un disque plein cerclé : il dit que l'objet n'a plus aucun comportement — il ne réagira plus à rien. Un diagramme sans initial est incomplet ; un diagramme sans final est parfaitement normal, car beaucoup d'objets n'ont pas de fin.

L'auto-transition, elle, est une vraie transition qui revient sur l'état d'où elle part. Elle a l'air de ne rien faire, et c'est faux : elle sort réellement de l'état puis y rentre, donc elle exécute exit, puis l'action de la flèche, puis entry. C'est la seule façon de relancer un minuteur, de réinitialiser un compteur, ou de journaliser une tentative qui n'a rien changé.

Reste le point le plus rentable du module, et il n'a pas de symbole : ce qui n'est pas dessiné est une décision. Si l'état courant n'a aucune flèche portant l'événement reçu, l'événement est ignoré — pas mis en file, pas reporté, pas transformé en erreur : il disparaît, et l'objet reste exactement où il était. Un énoncé qui dit « on ne peut pas annuler une commande payée » ne demande donc pas d'ajouter quoi que ce soit : il demande de ne pas tracer la flèche.

L'état composite, ou écrire une sortie au lieu de trois

Un état composite est un état qui contient lui-même d'autres états. Ce n'est pas une commodité de mise en page : c'est ce qui empêche une famille de transitions de se répéter. Le besoin apparaît toujours de la même façon — plusieurs états voisins réagissent identiquement au même événement, et l'on se retrouve à tracer la même flèche autant de fois qu'il y a d'états.

Un Emprunt en est l'exemple exact. Tant qu'il n'est ni rendu ni perdu, il est dans l'une de trois situations : EnCours, Prolongé ou EnRetard. Et de chacune, le même événement peut survenir : le lecteur annonce qu'il a perdu le livre.

Une transition qui part du cadre s'appelle une transition de groupe, et elle a une propriété qu'il faut savoir énoncer : quitter le cadre exécute le exit de l'état interne puis celui du cadre. On sort par étages, du plus profond vers le plus haut — et l'on entre dans l'autre sens.

Reste la moitié dont la figure ne parle pas, et c'est délibéré : elle ne montre que les sorties. L'entrée pose sa propre question, et elle tombe souvent à l'examen — quand une flèche arrive sur le cadre, dans lequel de ses sous-états atterrit-on ? La réponse n'est pas « le premier », ni « celui du haut » : un cadre qui reçoit une transition doit contenir son propre pseudo-état initial, un disque plein posé à l'intérieur, qui désigne le sous-état d'arrivée. Sans lui, le diagramme est ambigu, et l'ambiguïté est une faute — pas un détail de mise au propre.

L'autre possibilité est de viser directement : une flèche venue de l'extérieur peut traverser la bordure et pointer un sous-état précis. Les deux formes sont légales et ne disent pas la même chose. Pointer le cadre signifie « entre par la porte normale, quelle qu'elle soit » et survivra à un changement du sous-état de départ ; pointer un sous-état signifie « entre ici, et nulle part ailleurs ». Le premier se maintient tout seul, le second dit une intention plus forte — et c'est très exactement le même arbitrage que la transition de groupe, pris dans l'autre sens.

Lire : où est l'objet après cette séquence ?

C'est la question d'examen la plus courante sur ce diagramme, et elle se traite mécaniquement : on part du pseudo-état initial, on traite les événements un par un et dans l'ordre, et pour chacun on se pose deux questions dans cet ordre — l'état où je suis a-t-il une flèche portant cet événement ? puis sa garde est-elle vraie ? Si l'une des deux réponses est non, on ne bouge pas, et on passe à l'événement suivant.

Voici le cycle de vie complet d'un Emprunt, écrit comme on l'écrirait sur une copie : une transition par ligne. C'est aussi la forme la plus sûre pour vérifier son propre dessin, parce qu'un oubli s'y voit.

●  ──────▶  EnCours

EnCours   prolonger(j) [prolongations < 1]  ▶ Prolongé
EnCours   après(dateRetourPrevue)           ▶ EnRetard
EnCours   rendre()                          ▶ Rendu

Prolongé  après(dateRetourPrevue)           ▶ EnRetard
Prolongé  rendre()                          ▶ Rendu

EnRetard  rendre() / facturerAmende()       ▶ Rendu

Actif     declarerPerdu() / facturer()      ▶ Perdu
          Actif = { EnCours, Prolongé, EnRetard }

Rendu  ──────▶  ◉        Perdu  ──────▶  ◉

(A) prolonger(7) · rendre()
(B) prolonger(7) · prolonger(7) · après(dateRetourPrevue)
(C) après(dateRetourPrevue) · prolonger(7) · rendre()
(D) rendre() · declarerPerdu()

Construire un diagramme depuis un énoncé

Le sens inverse est l'autre question d'examen, et elle se traite dans un ordre précis. Cet ordre n'est pas un conseil de confort : chaque étape n'utilise que ce que la précédente a produit, et le faire dans le désordre est la façon la plus sûre d'obtenir un diagramme où des flèches partent d'états qu'on n'a pas encore décidés.

La septième ligne est celle qu'on saute, et c'est elle qui distingue une copie complète d'une copie approximative. Un énoncé qui interdit quelque chose ne demande pas d'ajouter une flèche vers un état Erreur : il demande de ne rien tracer, et de l'écrire en une ligne à côté du diagramme pour que le correcteur sache que c'est un choix et non un oubli.

●  ──────▶  Demandée

Demandée   confirmer()  ▶ Confirmée
Demandée   annuler()    ▶ Annulée
Confirmée  annuler()    ▶ Erreur
Erreur     revenir()    ▶ Confirmée

« Une session ouverte par un lecteur est active dès qu'il
  s'est authentifié. Après trente minutes sans action, elle
  devient expirée. Depuis une session expirée, se
  réauthentifier la réactive, à condition que le compte ne
  soit pas suspendu. Le lecteur peut fermer sa session
  quand elle est active ; il ne peut pas fermer une session
  déjà expirée. Chaque réactivation doit être journalisée. »

●  ──────▶  Active

Active   après(30 min)                      ▶ Expirée
Active   fermer()                           ▶ Fermée
Expirée  reauthentifier()
           [compte non suspendu]
           / journaliser()                  ▶ Active

Fermée  ──────▶  ◉