Modélisation des états

Objectif

La modélisation des états sert à décrire de façon précise et non ambiguë le cycle de vie d'une seule entité: l'ensemble des états qu'elle peut occuper, l'ordre dans lequel elle passe de l'un à l'autre, les événements et les conditions qui commandent ces passages et les actions déclenchées en chemin. Une entité est un objet métier doté d'un cycle de vie qui a un début et une fin, un sinistre, une commande, un permis, un contrat. Le BABOK situe l'emploi de la technique là où l'entité présente un comportement complexe et des règles complexes qui gouvernent ce comportement (§10.44): c'est ce double critère qui justifie le coût du modèle. Le livrable est un diagramme d'états accompagné du texte qui le documente, souvent précédé d'une table des états qui en élicite le contenu.

La décision que le modèle soutient est celle des transitions légales: quels changements sont permis depuis quel état et lesquels ne le sont pas. Un sinistre ne peut être réglé avant d'avoir été accepté, et cette règle, qu'un texte d'exigences noie dans des paragraphes, un modèle d'états la rend visible et vérifiable. C'est la vue centrée sur l'entité. Un modèle de données montre la structure statique, quelles entités existent et comment elles se relient; un modèle d'états montre le comportement dynamique de l'une d'elles dans le temps. La modélisation des processus, elle, suit le flux d'activités à travers plusieurs entités; le modèle d'états prend une entité et rassemble tout ce qui peut légalement lui arriver, à travers tous les processus qui la touchent.

Usage

Quand l'utiliser

• Entité au cycle de vie riche et gouverné par des règles: nombreux états, transitions conditionnelles, comportement qui dépend du statut courant.
• Les règles de transition sont l'exigence: ce qui compte est quels changements sont permis depuis quel état et lesquels sont interdits.
• Comportement piloté par le statut: les événements auxquels l'entité répond changent selon l'état où elle se trouve.
• Objet traversé par plusieurs processus: une vue centrée sur l'entité rassemble ce que les modèles de processus dispersent.

Quand ne pas l'utiliser

• Entité simple, deux ou trois statuts: capturer le statut comme un attribut du modèle de données suffit, sans le coût d'un modèle d'états.
• La question est le flux de travail entre plusieurs entités: relève de la modélisation des processus.
• La question est la structure statique et les relations des entités: prendre le modèle de données et son diagramme entités-relations.

Description

Un business analyst n'a pas besoin de maîtriser toute la notation des machines à états pour s'en servir. Il lui faut savoir lire une poignée d'éléments et, souvent, animer l'élicitation qui les fait émerger. Le reste, états composites, régions parallèles, historique, relève de la modélisation détaillée.

États, transitions, événements et gardes

Un état est un statut que l'entité tient dans la durée, pendant lequel elle répond à un ensemble défini d'événements et peut exécuter des activités. On le dessine par un rectangle aux coins arrondis portant un nom. Une transition est une flèche à sens unique qui va d'un état source vers un état cible, et on la lit dans le sens où elle pointe. Son étiquette suit la forme événement [garde] / action: l'événement qui la déclenche, une garde facultative, condition entre crochets qui doit être vraie pour que la transition se produise et une action facultative exécutée au passage. Deux pseudo-états bornent le cycle: un disque noir plein marque l'état initial, le point où l'entité vient à l'existence, et un disque cerclé marque l'état final, où l'entité est close et son cycle achevé.

Les transitions ne sont pas forcément linéaires. Une entité peut sauter un état, revenir à un état précédent ou boucler sur le même état. Une transition peut être conditionnelle, déclenchée par un événement sous garde, ou automatique, déclenchée par l'achèvement des activités de l'état ou par l'écoulement d'un délai. C'est cette combinaison qui donne au modèle sa précision: il dit ce qui peut arriver à l'entité, depuis quel état et sous quelle condition.

La table des états

Avant de dessiner, on élicite. La table des états est la forme basse technologie du même modèle: une ligne par transition, avec l'état de départ, l'événement et sa garde, l'action et l'état d'arrivée. Le BABOK la recommande pour faire nommer aux experts métier les états et les événements avant de tracer le diagramme (§10.44), et elle reste le meilleur support de cet échange, car un expert qui hésite devant un diagramme complète volontiers un tableau ligne à ligne.

Les pièges

Le piège le plus fréquent est de prendre un attribut pour un état. Un état change les événements auxquels l'entité répond et les transitions qui deviennent légales, tandis qu'un attribut n'est qu'une donnée qu'elle porte. « Priorité haute » ou « montant élevé » ne sont pas des états, ils ne commandent aucun passage. Le test est simple: si la valeur ne change pas ce qui peut arriver ensuite, c'est un attribut.

Les autres pièges se lisent tous sur le graphe. Une transition manquante laisse un événement qui peut survenir dans un état sans réponse définie, et balayer chaque état contre chaque événement les fait apparaître. Un état inatteignable, vers lequel aucune transition ne mène, signale une modélisation morte ou une transition oubliée ailleurs, car tout état non initial a besoin d'au moins une flèche entrante. Un état puits, non final et sans transition sortante, piège l'entité qui n'en ressort jamais, alors que tout état sauf le final a besoin d'une sortie. Omettre l'état final masque les règles de clôture, d'archivage ou de suppression de l'entité. Reste la sur-modélisation: bâtir une machine à états pour une entité simple dépense du temps d'expert pour peu de retour.

Considérations IA

Un modèle de langage rend deux services sur cette technique. Le premier est la dérivation d'une machine à états candidate: il lit des règles métier, un texte d'exigences ou les journaux d'un système existant et propose des états, des transitions et leurs événements. Sur un système hérité dont le comportement n'est documenté nulle part, le brouillon obtenu se corrige plus vite qu'une page blanche ne se remplit. Le second est la vérification de complétude, un travail réglé qui se prête bien à la machine: signaler un état inatteignable, un état puits sans sortie, une transition manquante pour un événement connu ou l'absence d'état final.

La limite est de nature métier. Distinguer un état d'un attribut suppose de savoir si la valeur gouverne réellement le comportement, ce que seul le métier tranche. Qu'une transition soit légale, qu'un sinistre puisse passer directement de Reçu à Refusé, est une règle métier que le texte ne livre pas de façon fiable, et une transition fausse fait mentir le modèle. Le modèle de langage tend par ailleurs à sur-modéliser, à produire des états qui sont des attributs déguisés. Toute proposition de la machine est un brouillon soumis aux experts du domaine et au business analyst qui tient la distinction entre état et attribut.

Exemples

Le concept que l'exemple rend visible est la lecture d'une machine à états sur une seule entité: les états, une transition qui porte à la fois un événement, une garde et une action, un retour en arrière et les pseudo-états initial et final. Le cas est le cycle de vie d'un sinistre chez un assureur, assemblé en diagramme.

Une seule transition porte l'essentiel de la notation. La transition de En instruction vers En expertise est étiquetée couverture confirmée [montant > CHF 10'000] / mandater un expert: l'événement est la confirmation de couverture, la garde entre crochets restreint le passage aux montants supérieurs à CHF 10'000, et l'action mandate un expert au moment du passage. Le même événement, sous la garde inverse [montant ≤ CHF 10'000], mène directement à Accepté: une seule garde partage un événement en deux issues. En expertise se résout ensuite vers Accepté ou Refusé selon le rapport rendu. Le retour de En attente de pièces vers En instruction montre qu'une transition n'est pas forcément une progression, le sinistre revenant à l'instruction dès les pièces reçues. Le disque plein marque l'entrée du sinistre dans le système, et les deux branches terminales, Réglé et Refusé, rejoignent l'état final. Quelques états et leurs transitions suffisent à porter toute la notation qu'un business analyst a besoin de lire.

Visualisations

La forme porte le sens et se lit sans légende. Le rectangle arrondi dit un statut tenu dans la durée. La flèche dit une transition légale, et elle se lit dans le sens où elle pointe, car la règle est orientée. L'étiquette dit l'événement qui déclenche le passage, la garde entre crochets qui le conditionne et l'action exécutée au passage. Le disque plein dit la naissance de l'entité, le disque cerclé sa fin. Un lecteur qui connaît ces cinq signes lit un diagramme d'états sans autre appui, y compris celui du sinistre.

Coût

Outils

Un tableau blanc suffit à une première ébauche, quelques états et leurs transitions tenant sur une surface et se corrigeant debout avec les experts. La table des états se tient dans un tableur, forme naturelle de l'élicitation avant le dessin. Les outils de schéma généralistes, diagrams.net, Lucidchart ou Visio, portent des gabarits de machine à états UML et donnent un diagramme propre et partageable, adaptés tant qu'il reste un support de discussion. Les ateliers de modélisation UML dédiés, Enterprise Architect, Visual Paradigm, StarUML ou Modelio, tiennent le diagramme d'états comme une vue d'un modèle cohérent, le vérifient et le relient aux autres diagrammes. Les outils à génération textuelle, PlantUML ou Mermaid, décrivent un diagramme d'états en quelques lignes de texte versionnables, ce qui convient à un modèle tenu à côté du code. Au-delà de la documentation, un modèle d'états sert parfois directement de configuration, les moteurs de workflow et les machines à états logicielles exécutant le cycle de vie que le modèle décrit.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.44 State Modelling: la définition de la technique, l'entité au comportement et aux règles complexes, les éléments état, transition, événement et condition, la table des états et la limite de la sur-modélisation.
• OMG (Object Management Group), Unified Modeling Language (UML) Specification, version 2.5.1, State Machines: la spécification qui définit la notation des machines à états, états, transitions étiquetées événement-garde-action, pseudo-états initial et final. L'ancre normative de la notation.
• David Harel, « Statecharts: A Visual Formalism for Complex Systems », Science of Computer Programming, vol. 8, n° 3 (1987), pp. 231-274: l'article fondateur du formalisme des statecharts sur lequel reposent les machines à états d'UML.