Les nouveaux venus au formalisme de la machine à états confondent souvent les diagrammes d’états avec les organigrammes. La figure ci-dessous montre une comparaison entre un diagramme d’états et un organigramme. Une machine à états (panneau (a)) effectue des actions en réponse à des événements explicites. En revanche, l’organigramme (panneau (b)) n’a pas besoin d’événements explicites mais transite de nœud en nœud dans son graphe automatiquement à l’achèvement des activités.
Les nœuds des organigrammes sont des arêtes dans le graphe induit des états.La raison est que chaque nœud d’un organigramme représente une commande de programme.Une commande de programme est une action à exécuter.Ce n’est donc pas un état, mais lorsqu’elle est appliquée à l’état du programme, elle entraîne une transition vers un autre état.
Plus en détail, le listing du code source représente un graphe de programme.L’exécution du graphe de programme (analyse syntaxique et interprétation) aboutit à un graphe d’états.Ainsi, chaque graphe de programme induit un graphe d’états.La conversion du graphe de programme en son graphe d’états associé est appelée « dépliage » du graphe de programme.
Le graphe de programme est une séquence de commandes.Si aucune variable n’existe, alors l’état est constitué uniquement du compteur de programme, qui garde la trace de l’endroit où nous nous trouvons dans le programme pendant l’exécution (quelle est la prochaine commande à appliquer).
Dans ce cas, avant d’exécuter une commande, le compteur de programme est à une certaine position (état avant l’exécution de la commande).L’exécution de la commande déplace le compteur de programme vers la commande suivante.Puisque le compteur de programme est l’état entier, il s’ensuit que l’exécution de la commande a changé l’état.Donc, la commande elle-même correspond à une transition entre les deux états.
Envisageons maintenant le cas complet, lorsque les variables existent et sont affectées par les commandes du programme en cours d’exécution.Alors, entre différents emplacements du compteur de programme, non seulement le compteur de programme change, mais les variables pourraient également changer de valeur, en raison des commandes exécutées.Par conséquent, même si nous revisitons une certaine commande de programme (par exemple, dans une boucle), cela n’implique pas que le programme est dans le même état.
Dans le cas précédent, le programme serait dans le même état, parce que l’état entier est juste le compteur de programme, donc si le compteur de programme pointe vers la même position (commande suivante), il suffit de préciser que nous sommes dans le même état.Cependant, si l’état comprend des variables, alors si celles-ci changent de valeur, nous pouvons être au même emplacement du programme avec des valeurs de variables différentes, ce qui signifie dans un état différent dans l’espace d’état du programme.Le terme « dépliage » provient de cette multiplication des emplacements lors de la production du graphe d’état à partir du graphe de programme.
Un exemple représentatif est une boucle do incrémentant un certain compteur jusqu’à ce qu’il déborde et redevienne 0.Bien que la boucle do exécute la même commande d’incrémentation de manière itérative, de sorte que le graphe de programme exécute un cycle, dans son espace d’état n’est pas un cycle, mais une ligne.Cela résulte de l’état étant l’emplacement du programme (ici le cycle) combiné avec la valeur du compteur, qui est strictement croissante (jusqu’au débordement), de sorte que différents états sont visités en séquence, jusqu’au débordement.Après le débordement, le compteur redevient 0, donc l’état initial est revisité dans l’espace d’état, fermant un cycle dans l’espace d’état (en supposant que le compteur a été initialisé à 0).
La figure ci-dessus tente de montrer cette inversion des rôles en alignant les arcs des diagrammes d’état avec les étapes de traitement de l’organigramme.
Vous pouvez comparer un organigramme à une chaîne de montage dans la fabrication parce que l’organigramme décrit la progression d’une certaine tâche du début à la fin (par ex, la transformation d’une entrée de code source en sortie de code objet par un compilateur). Un automate à états n’a généralement aucune notion d’une telle progression. L’automate à états de la porte illustré en haut de cet article, par exemple, n’est pas à un stade plus avancé lorsqu’il est à l’état « fermé », par rapport à l’état « ouvert » ; il réagit simplement différemment aux événements d’ouverture/fermeture. Un état dans une machine à états est un moyen efficace de spécifier un comportement particulier, plutôt qu’une étape de traitement.