Bonsoir,
La modélisation d'un système par machine d'états-transitions est, à ma connaissance, un des moyens les plus efficaces pour analyser un problème et écrire du bon code (dans le sens conforme, efficace, facile à mettre au point et à maintenir). Cela s'applique à la gestion de systèmes physiques en toute sécurité ou à des protocoles de communication, avec la même facilité. C'est une approche malheureusement insuffisamment connue.
Pour chaque état, un (ou des) évènements permettent une transition vers un autre état (ou d'autres états), en réalisant éventuellement une action déterminée. Il peut parfois y avoir retour vers le même état (à une variable d'état près, éventuellement). A chaque état peuvent être associées un jeu de valeurs des variables d'état (ce qui peu matérialiser en quoi consiste une 'transition', mais pas toujours).
Cette approche permet effectivement de réfléchir à bien poser le problème, à trouver les bons états, les bonnes variables d'état, à tester sur papier la conformité du fonctionnement aux attentes, tout cela avec rapidité (ce n'est finalement que du dessin servant de support à une 'expérience de pensée') mais avec une grande sûreté (l'automate dessiné fait ce que l'on veut, ou non, le constat est immédiat, et en cas de non, c'est que la modélisation est à revoir). Cette approche événementielle est en général vécue comme assez naturelle. Tout cela sans avoir écrit une seule ligne de code !
Le passage du schéma au code est grandement simplifié, et une grande partie en devient assez 'mécanique', donc sûre :
- un bel enum() pour les états possibles de la variable 'état' (on peut mettre des noms parlants; si on en ajoute un, intermédiaire, rien n'est cassé avec l'enum) ;
- un grand switch sur la variable 'état' pour le choix de l'état courant à traiter, avec autant d' instructions 'case' que d'états recensés;
- et sous chaque 'case' du switch, la succession des événements possibles dans cet état (et seulement ceux-là) [souvent des if() ], suivi du code des actions à appliquer pour réaliser la transition correspondant à cette événement (changement de certaines valeurs d'état ou autre action) avec, in fine, le passage dans le nouvel état pour cet événement (nouvelle valeur assignée à 'état').
Ce code peut bien souvent être enrichi progressivement: on fait tourner la machine à vide au début (pour vérifier tous les enchaînements avec des traces simples), puis on ajoute les actions (dont certaines peuvent être 'dangereuses' surtout en cas de bug et pour lesquelles il vaut mieux être certain du fonctionnement correct de l'automate avant de les activer). Si l'étude est bien faite, cela doit marcher du premier coup, ou presque (pour la part automate, au moins).
Chacun pourra selon ses goûts y ajouter une dose appropriée de programmation-objet. Une transition, finalement, cela peut-être une action, donc une méthode appliquée à un objet.
De la sorte, on peut résoudre des problèmes très complexes en les divisant en des transitions simples et précisément définies. Cette approche structurée facilite la lisibilité, la maintenance et les évolutions.
Dans un projet de type Locoduino, il peut facilement y avoir besoin de plusieurs diagrammes états-transitions : un pour une phase de réglage de paramètres, par exemple, un pour le fonctionnement d'exploitation proprement dit, pour gérer un affichage, etc...
Un lien en français qui décrit une façon d'aborder cette modélisation :
http://frederique.lafoux.free.fr/cours/pdf/ISI_UML_DiagrammeEtatsTransitions.pdf.
et il y en a sûrement bien d'autres.
Quoiqu'il en soit, en ce qui concerne la mise en oeuvre de la partie 'étude de l'automate', je suis d'accord avec Dominique, un outil n'est pas essentiel.
Au-delà du simple papier crayon gomme, un outil graphique pour faire des rectangles, des flèches et mettre des commentaires convient parfaitement. A défaut un Excel ou un LibreOffice répond aussi au besoin. Cela facilite l'établissement et les itérations de mise au point en restant plus 'propre' qu'un dessin manuel. Après, on peut aussi acheter l'outil de génie logiciel qui passe directement du schéma au squelette du code, mais c'est peut-être un peu luxueux.
J'ai même connu des concepteurs qui se contentaient de plusieurs colonnes : état de départ, événement, état d'arrivée, commentaires ou description de l'action. Il 'suffit' de détailler toutes les instances nécessaires, ligne par ligne. A chacun sa façon et ses préférences ...
Un autre lien qui donne des informations sur divers logiciels de génie logiciel, dont StarUml qui pourrait, sous Windows, répondre à la question :
https://www.projet-plume.org/fr/fiche/staruml (non testé; et il y a beaucoup d'autres logiciels sur ce site, certains bien connus).
En espérant que cela pourra vous être utile.
