Exemples de diagrammes d'états-transitions

Si une table de votre base a une colonne status, ce diagramme est déjà implicite dans le code : il est simplement écrit à travers une douzaine de clauses de garde au lieu d'être dessiné une fois. Le rendre explicite est l'exercice de recherche de défauts le moins cher qu'offre une machine à états.

Lisez les transitions plutôt que les boîtes. Chacune porte le déclencheur qui la provoque - checkout, pay, dispatch, deliver - et l'une porte un effet après une barre oblique : dispatch / print label. Ces étiquettes sont le contenu. Un diagramme de six boîtes arrondies aux flèches non étiquetées dit seulement que les choses changent, ce que tout le monde savait déjà.

Les deux états finaux sont délibérés. Annulée et Livrée sont toutes deux terminales et ne sont pas le même résultat, et dessiner un seul disque cerclé pour les deux dirait que la commande est terminée sans dire comment. Rien dans UML ne vous limite à un seul.

Les vrais flux de travail vont rarement dans un seul sens. Quelque chose est refusé, revient, et repasse - et c'est dans la transition de retour que vivent en général les règles intéressantes.

La transition revise de Refusé vers Brouillonest ce qui fait de ceci une machine à états plutôt qu'une liste de contrôle. Elle dit qu'un article refusé n'est pas fini : il rentre dans le même cycle, et tout compteur du genre « refusé deux fois signifie escalader » pend à cette flèche et non à un état.

Notez que Refusé a une sortie et Publié non. Un état sans transition sortante et sans état final derrière lui affirme que l'objet y reste pour toujours, ce qui est parfois vrai et plus souvent un oubli. Vérifier chaque état feuille sur ce point est une relecture de deux minutes qui trouve de vrais trous.

Les noms de déclencheurs sont des événements du vocabulaire du domaine - submit, approve, reject, revise - et non des noms de méthodes. Cela garde le diagramme lisible pour les rédacteurs qui possèdent le processus, c'est-à-dire le public capable de vous dire qu'il est faux.

La confusion la plus fréquente quand on passe des diagrammes d'activité aux machines à états porte sur ce que signifient deux flèches sortant d'une boîte.

Ce sont deux déclencheurs, pas deux branches d'une décision. La commande reste indéfiniment dans En attente de paiement ; l'événement qui arrive le premier - pay ou l'événement temporel timeout(72h) - décide où elle va. Rien n'a besoin d'être exhaustif et il n'y a pas de [else], parce qu'attendre est une issue légitime.

C'est l'inverse d'un diagramme d'activité, où un jeton arrivant à une décision sans garde activée est un processus bloqué. Une géométrie identique, une sémantique opposée : d'où l'intérêt de choisir entre les deux notations volontairement plutôt que par habitude.

Une machine à états est peu coûteuse à dessiner et coûteuse à entretenir, donc la question de savoir si l'objet a un cycle de vie mérite d'être posée avant la première boîte.

Si le processus s'étend sur plusieurs participants plutôt que sur la vie d'un objet, vous voulez un diagramme d'activité ou, pour un public métier, BPMN. Le test est simple : si vous ne pouvez pas nommer la chose unique dont ce sont les états, ce n'est pas une machine à états.