Au-delà des notions de base,
prenons un exemple simple tiré d'un manuel : un problème orienté état. Cherchons une implémentation adaptée sur une machine à états. Dans ce cas, il existe deux solutions différentes, chacune présentant ses avantages et ses inconvénients ; le choix dépend donc de l'évaluation de ces avantages et inconvénients.

Problème : « Une route principale très fréquentée croise une route locale peu fréquentée. Des détecteurs sont placés le long de la route locale pour déclencher un feu vert lorsqu’un véhicule attend pour traverser la route principale. Le contrôleur de feux de circulation doit fonctionner comme suit : tant qu’aucun véhicule n’est détecté sur la route locale, les feux de circulation restent verts en direction de la route principale. Si un véhicule est détecté sur la route locale, les feux de circulation de la route principale passent du jaune au rouge, permettant ainsi aux feux de la route locale de passer au vert. Les feux de la route locale restent verts tant qu’un véhicule y est détecté, et ce, pendant un intervalle déterminé afin de permettre la circulation sur la route principale. Si ces conditions sont réunies, les feux de la route locale passent du vert au jaune, puis au rouge, permettant ainsi aux feux de la route principale de revenir au vert. Même si des véhicules attendent pour traverser la route principale, celle-ci reste verte pendant un intervalle déterminé. »¹
Cet exercice se concentre sur une approche matérielle, mais avec un peu d’imagination, il peut être adapté à un environnement logiciel. Notez que cet exemple utilise la convention selon laquelle la lumière jaune apparaît toujours seule (d'autres conventions sont utilisées dans certaines régions du monde). Cela n'affecte cependant pas la difficulté du problème ; cela facilite simplement le repérage des combinaisons de couleurs possibles.

L'approche simplifiée de la conception de machines à états peut être décrite comme suit :

1. Identifier les événements et les actions ;
2. Identifier les états ;
3. Regrouper par hiérarchie ;
4. Regrouper par concurrence ;
5. Ajouter les transitions ;
6. Ajouter les synchronisations.

Il ne s'agit pas d'une méthode rigide, mais plutôt d'une approche généralement utile pour structurer une solution, quels que soient les outils et les méthodes d'implémentation choisis.

Approfondissons le sujet.
Commençons par examiner la description du problème, en recherchant les événements et actions possibles. Qu'est-ce qu'un événement dans le contexte d'une machine à états finis ? En termes simples, un événement est un déclencheur susceptible d'amener la machine à états finis à changer d'état et à exécuter une action. Dans le cas des sémaphores, on peut identifier une série d'événements potentiels :

Les intervalles de délai ne constituent pas des événements en soi ; c’est la fin d’un intervalle qui peut être considérée comme un événement. En pratique, cela nous donne deux événements : un événement correspondant au long intervalle pendant la période de feu vert sur les deux voies, et un autre événement correspondant au court délai uniforme lors de la transition entre le rouge et le vert.
Nous avons donc trois événements, que nous pouvons appeler LocalRoadTrafficEvent, LongEvent et ShortEvent.

Alors, qu'est-ce qui constitue une action dans ce problème ? Changer la couleur des feux de circulation est une action typique. La seule question est de savoir si le changement de couleur sur les deux routes constitue une ou deux actions. En réalité, c'est une question de convention. On peut le considérer comme deux actions distinctes, chacune gérant une route, ou comme une seule action. Je choisis de le considérer comme deux actions distinctes, pour des raisons qui deviendront claires plus loin.
Je choisis d'appeler ces actions `ConfigureLocalRoadLight()` et `ConfigureMainRoadLight()` ; chaque action prend un paramètre de couleur indiquant la couleur souhaitée.

L'idée est que les événements sélectionnés déclencheront des changements de couleur des feux tricolores dans certaines situations.
Il nous faut également un moyen de suivre les intervalles de temps ; nous introduisons donc une action spéciale appelée « minuterie ». Son but est de démarrer un compteur pour un intervalle spécifié et de suivre un événement qui sera déclenché à la fin de ce délai. Par souci de simplicité, nous appellerons cette minuteur `ActionTemp()`.
Pour mieux comprendre la logique de contrôle du système de feux tricolores, il est nécessaire de connaître les états possibles et leurs transitions. La première solution s'appuie sur les observations suivantes :

à tout instant, les feux tricolores afficheront l'une des combinaisons de couleurs suivantes : {VERT, ROUGE}, {JAUNE, ROUGE}, {ROUGE, ROUGE}, {ROUGE, JAUNE}, {ROUGE, VERT}, {ROUGE, JAUNE}. Conformément aux règles de fonctionnement des feux tricolores, il est clair que d'autres combinaisons ne doivent pas être autorisées afin d'éviter tout risque pour la circulation traversant simultanément l'intersection. La première couleur de chaque paire correspond au feu tricolore de la route principale.
Les combinaisons de couleurs indiquées ci-dessus s'affichent selon une séquence fixe : {VERT, ROUGE}, {JAUNE, ROUGE}, {ROUGE, ROUGE}, {ROUGE, JAUNE}, {ROUGE, VERT}, {ROUGE, JAUNE}, {ROUGE, ROUGE}, {JAUNE, ROUGE}, puis on revient à la première combinaison pour recommencer.

Chaque étape de la séquence représente un état possible, puisqu'elle inclut clairement l'état du système à un instant donné. Les transitions entre les états sont alors déclenchées par les différents intervalles de temps associés à chaque changement de couleur. Si la séquence commence par un feu vert sur la route principale, elle est déclenchée par un événement LocalRoadTrafficEvent.
Le lecteur attentif aura remarqué des doublons dans la séquence de combinaisons de couleurs ci-dessus. Par exemple, la combinaison « les deux feux rouges » apparaît deux fois. Faut-il les considérer comme un seul ou deux états ? J'ai choisi de considérer chaque position de la séquence comme un état distinct. Ce choix implique que les transitions entre états doivent être aussi simples que possible.
Nous disposons déjà des éléments de base : un ensemble d'événements, des actions et un ensemble d'états candidats.

La figure 2 illustre la conception en notation UML. Les états proposés sont représentés sous forme circulaire, les transitions étant nommées d'après les événements correspondants. Chaque état possède également des actions d'entrée permettant de modifier la couleur du feu tricolore. Comme on peut le constater, seul l'état initial nécessite la configuration des deux feux pour assurer un démarrage correct de la séquence ; pour les autres états, un seul feu doit être modifié par rapport à l'état précédent. Ceci explique l'utilisation de deux fonctions d'action différentes. L'état initial est indiqué par la transition entre l'état initial et l'état actuel, représentée par un petit cercle dans le coin supérieur gauche.

La sémantique UML utilise l'état initial et la transition depuis cet état pour pointer vers l'état de départ souhaité, ce qui nous permet d'exprimer directement l'initialisation du système dans le diagramme. La transition ne comporte aucun événement et est implicite lors du démarrage.
Du point de vue de la machine à états, cette conception est presque complète, mais ne gère pas l'intervalle minimal de feu vert pour la route principale. Plusieurs solutions sont possibles, mais la suivante semble assez simple :

introduire une légère hiérarchie dans le modèle en créant une machine à états au sein de l'état MainGreen_LocalRed. Cette machine à états est composée de deux états et du pseudo-état initial. Lorsque l'état environnant est atteint, l'état NewGreen est également activé.
À l'expiration d'un long intervalle de temps, qui a débuté lors de l'entrée dans MainGreen_LocalRed, la machine à états passe à l'état LocalRoadEventOK. Nous savons alors que l'intervalle minimal de feu vert sur la route principale est écoulé et que le passage au vert sur la route locale est désormais autorisé en cas de circulation.

Le dernier élément nécessaire au maintien de l'intervalle vert minimal sur la route principale est une « protection » lors de la transition hors de l'état GreenMain_RedLocal. Cette transition ne doit être annulée que si l'état LocalRoadEventOK est déclenché. Cela peut se traduire par une condition d'état positive ou une synchronisation positive dans la transition. Les modifications résultantes sont visibles sur la figure 3.

Cette solution n'est pas parfaite car elle ne tient pas compte du fait que le trafic arrivant sur la route locale pendant l'intervalle vert minimal sur la route principale reste arrêté jusqu'à l'arrivée d'un autre véhicule une fois l'intervalle expiré. Pour y remédier, il est nécessaire d'enregistrer tout événement LocalRoadTrafficEvent survenant pendant l'intervalle vert afin de pouvoir prendre les mesures appropriées à son expiration. Nous n'étudierons pas ici une solution complète à ce problème, mais si vous souhaitez en concevoir une, les points suivants indiquent une piste possible :

introduire une variable d'alerte interne dans la machine à états, réinitialisée à zéro à chaque passage au vert sur la route principale.
Introduisez une « réaction interne » à l'état vert de la route principale, qui détecte l'alerte lors de la réception d'un événement LocalRoadTrafficEvent, par exemple avec NewGreen comme état de protection.
Une « réaction d'entrée » à l'état LocalRoadEventOK envoie un signal si l'alerte est déclenchée lors du passage à cet état (un signal est un événement spécial que la machine à états peut elle-même envoyer).
Une transition vers le jaune déclenche le signal et lance un court intervalle de temporisation.
D'autres solutions existent, mais elles nécessitent une syntaxe UML plus complexe, trop longue pour être abordée ici.

Les machines à états logicielles diffèrent de leurs homologues matérielles : elles doivent détecter les événements de l'environnement matériel et y réagir. Leur modèle de calcul repose donc sur un cycle détection-événement-réaction composé d'étapes discrètes, tandis qu'une machine à états matérielle peut réagir « simultanément » à un changement de signal sur une broche donnée. (Bien que la variation effective des portes logiques corresponde, bien sûr, à une activité discrète au niveau du bit.) Par exemple, un ensemble de signaux matériels peut être combiné au niveau d'une porte logique pour produire un événement lorsqu'une certaine combinaison de signaux est présente en entrée. Dans un environnement logiciel, vous devez soit laisser les pilotes d'interruption et de périphérique effectuer cette combinaison, soit laisser la machine à états s'en charger (sauf si vous contrôlez la conception matérielle).

Une approche différente.
Comme souligné en introduction, il existe au moins une autre manière de résoudre ce problème, consistant à modéliser les machines à états comme deux régions parallèles au sein d'une même machine à états de haut niveau. Cette approche présente l'avantage de permettre de considérer la solution complète comme un système composé de composants distincts et semi-indépendants. Faute de place, nous ne pouvons pas développer davantage ce point, mais vous pouvez consulter la documentation en ligne à l'adresse www.iar.com/p236597/p236597_eng.php
.
Le choix précis de la solution importe peu, mais il est généralement préférable de privilégier la simplicité. L'utilisation d'un outil de conception graphique tel qu'IAR visualSTATE pour la conception de machines à états est une méthode pratique pour élever le niveau d'abstraction, car un bon outil prend en charge des aspects tels que la génération de code, les tests et la simulation, ainsi que la vérification des capacités du modèle.

Auteur : Anders Holmberg, IAR Systems

Pour plus d'informations ou un devis