Statecharts : machines à états hiérarchiques

 (statecharts.dev)
1 points par GN⁺ 3 일 전 | 1 commentaires | Partager sur WhatsApp
  • Format visuel permettant de structurer le comportement de systèmes complexes, qui étend la state machine de base afin de mieux gérer le problème de state explosion
  • Permet de séparer le comportement des composants, ce qui facilite la modification du fonctionnement, le raisonnement sur le code, les tests indépendants des composants et l’exploration des cas d’exception
  • Le processus de création d’un statechart amène à explorer tous les états possibles, et des résultats de recherche ont aussi montré que le code fondé sur des statecharts présentait moins de bugs que le code traditionnel
  • Grâce au standard SCXML et à des outils et bibliothèques dans plusieurs langages, il est possible de lire, écrire et exécuter le modèle, tout en aidant à traiter correctement l’ordre des opérations comme les entry/exit action
  • En utilisant un format de machine exécutable, une seule définition peut servir de single source of truth pour conserver ensemble le comportement à l’exécution et le diagramme, ce qui rend importante la synchronisation entre conception et implémentation

Vue d’ensemble des statecharts

  • Un statechart est un format visuel conçu pour traiter des systèmes complexes, sous la forme d’une extension de la state machine de base
  • Il a été renforcé pour faire face au problème de state explosion qui apparaît quand une state machine grossit
  • Le comportement peut être représenté sous forme de diagramme, mais en ingénierie logicielle il s’agit moins de visualisation au sens strict que de modélisation et de structuration du comportement
  • Les explications de base se poursuivent dans What is a state machine? et What is a statechart?

Pourquoi utiliser des statecharts

  • Ils offrent une structure facile à comprendre, souvent plus lisible que bien d’autres formes de code
  • Ils permettent la séparation du comportement et des composants
    • Il devient plus facile de modifier le fonctionnement
    • Il devient plus facile de raisonner sur le code
    • Le comportement peut être testé indépendamment des composants
  • Le processus de création d’un statechart conduit à explorer tous les états possibles
  • Des résultats de recherche ont montré que le code fondé sur des statecharts comportait moins de bugs que le code traditionnel
  • Ils conviennent bien pour traiter des cas d’exception faciles à manquer
  • Leur scalabilité s’améliore à mesure que la complexité augmente
  • Ils sont faciles à comprendre même pour des non-développeurs, et les équipes QA peuvent les utiliser comme outil d’exploration
  • Beaucoup de code contient déjà implicitement des state machines, et les statecharts servent à les rendre explicites

Contraintes et freins à l’adoption des statecharts

  • Ils demandent un coût d’apprentissage supplémentaire
    • Le concept sous-jacent de state machine peut toutefois déjà être familier à beaucoup de programmeurs
  • Comme ils diffèrent sensiblement des habitudes de développement existantes, ils peuvent être perçus comme un paradigme peu familier
    • Cela peut susciter des réticences à l’échelle de l’équipe
  • Pour de petits statecharts, le fait de séparer le comportement peut augmenter le nombre de lignes de code
  • Le manque d’adoption s’explique notamment par une faible notoriété et par le YAGNI
  • Parmi les objections courantes figurent l’idée que ce n’est pas vraiment nécessaire, que cela ne colle pas à certains courants techniques, ou que cela ajoute des bibliothèques supplémentaires
    • Dans les applications web, cela peut augmenter le temps de chargement
  • Même en tenant compte de ces avantages et inconvénients, l’effet global de l’adoption reste plutôt positif

Modes d’utilisation et SCXML

  • SCXML est un format standardisé par le W3C entre 2005 et 2015, qui définit les différentes règles sémantiques des statecharts ainsi que le traitement des cas limites
  • Il existe des outils dans plusieurs langages pour lire, écrire et exécuter du SCXML
  • Il existe aussi des formats dérivés qui conservent le même modèle tout en changeant uniquement la syntaxe
  • Il existe des bibliothèques de statecharts pour diverses plateformes, avec des niveaux de prise en charge variables des règles sémantiques de SCXML
  • L’usage de ces bibliothèques aide à traiter correctement l’ordre d’exécution d’opérations comme les entry/exit action
  • Des indications d’usage supplémentaires sont disponibles dans how to use statecharts

Statecharts exécutables

  • Au lieu d’utiliser les statecharts uniquement comme documentation, on peut employer un format de machine exécutable à la fois pour la conception et pour l’exécution
  • Une seule définition peut servir de single source of truth afin d’alimenter à la fois le comportement réel à l’exécution et le diagramme visuel
  • Cela supprime le besoin de transcrire le diagramme en code
  • Cela peut réduire les bugs introduits par une traduction manuelle
  • Le diagramme et l’implémentation restent en permanence synchronisés
  • Le diagramme devient plus précis
  • En contrepartie, le diagramme peut devenir assez complexe
  • Les formats et outils disponibles pour les statecharts exécutables restent limités
  • Il est difficile de garantir fortement la sûreté de typage entre statechart et composants
  • Si la définition du statechart se trouve dans le code, cette représentation peut servir à générer automatiquement un statechart visuel
    • Cela devient plus simple lorsque la définition se trouve dans un fichier séparé, comme du JSON ou du XML

Communauté et ressources complémentaires

À lire aussi

1 commentaires

 
GN⁺ 3 일 전
Avis Hacker News

  • Ça fait plaisir de voir les statecharts continuer à attirer l’attention
    J’ai créé XState, une bibliothèque JS/TS pour écrire, exécuter et visualiser des machines à états et des statecharts, visible ici : https://github.com/statelyai/xstate
    Après plus de 10 ans de travail dessus, la leçon essentielle que j’en retiens est que les statecharts ont le plus de valeur quand on les traite non comme une simple documentation, mais comme un comportement exécutable
    Il ne faut pas en mettre partout, mais c’est particulièrement puissant lorsque la réponse à « que se passe-t-il ensuite ? » dépend à la fois de l’état courant et de l’événement
    Ce type de diagramme peut servir d’oracle répondant à la question : « dans cet état précis, si cet événement arrive, quel est l’état suivant et quels effets sont exécutés ? »
    L’alpha de la prochaine version majeure de XState est presque prête aussi, avec un focus sur l’ergonomie, la sûreté de typage, la composabilité, et un nouveau visualiseur/éditeur
    L’outil de visualisation open source de base est ici : https://sketch.stately.ai
    Côté spécification formelle, SCXML vaut le détour : https://www.w3.org/TR/scxml
    Et l’article original de David Harel reste très précieux : https://www.weizmann.ac.il/math/harel/sites/math.harel/files/users/user50/Statecharts.pdf

    • C’est grâce à toi que j’ai découvert les state machines pour la première fois
      Il y a aussi une vidéo d’une présentation à Laracon où les idées sur les state machines et les statecharts sont bien mises en ordre
      https://www.youtube.com/watch?v=1A1xFtlDyzU
    • Côté Clojure, on peut recommander https://github.com/fulcrologic/statecharts
      C’est une implémentation assez mature, assez proche de SCXML, tout en supprimant l’exigence XML, surtout pour le contenu exécutable
      XState figure aussi parmi les références dans la section prior art
    • En utilisant XState, je n’avais même pas besoin de connaître le terme statecharts pour y trouver beaucoup de valeur
      Je l’ai utilisé avec lit.js pour un composant de navigation de type drawer qui réagit à la largeur de la page et possède beaucoup de props et d’état interne ; je n’ose pas imaginer à quel point ça aurait été horrible sans XState
    • J’ai déjà démêlé beaucoup de situations complexes avec XState
      J’attends la prochaine version avec impatience, et merci infiniment
    • Si vous n’avez pas besoin de machines à états imbriquées complexes, robot3.js mérite aussi un coup d’œil
      Son inférence automatique de types TS est plutôt bonne, donc c’est pratique quand on veut une logique de machine à états légère

  • J’ai l’impression qu’autrefois les statecharts commençaient à gagner du terrain dans l’écosystème frontend/UI, et je trouve dommage que cet élan se soit un peu perdu
    Pour les interactions UI, utiliser des machines à états, en particulier des compositions comme les statecharts, rend les flux complexes beaucoup plus faciles à raisonner
    Si vous découvrez le sujet, je recommande fortement « Constructing the user interface with statecharts » de Ian Horrucks
    C’est un livre de 1999, mais il reste excellent comme introduction concrète sur la manière de les appliquer et de les utiliser réellement
    https://archive.org/details/isbn_9780201342789/mode/2up

    • XState continue pourtant à se diffuser largement
      Il dépasse les 4 millions de téléchargements hebdomadaires sur npm, et des outils d’animation comme Rive et LottieFiles mettent eux aussi fortement en avant des fonctionnalités de machine à états
      Des outils IA comme LangGraph reposent également sur une base de machines à états
      Il faudra sans doute encore du temps pour que ces applications et outils exploitent tout le potentiel des statecharts, mais le départ est bon
    • Moi aussi, j’ai découvert les statecharts en tombant sur ce plugin Godot
      https://github.com/derkork/godot-statecharts

  • Un point souvent absent des introductions, ce sont les history pseudo-states
    Avec H et H, un statechart devient formellement non déterministe vu de l’extérieur
    On explique souvent que « l’état courant est une fonction pure de l’entrée », mais l’historique casse cette hypothèse
    Si on rentre à nouveau dans un état parent via H, on revient au dernier enfant activé, donc avec le même événement et le même état extérieur, on peut réentrer dans des états internes différents
    Ce « dernier enfant actif » caché est lui-même un état, mais il n’est généralement pas représenté dans le diagramme
    L’article original de Harel le reconnaît, et SCXML comme XState l’implémentent, mais on en parle très peu
    Donc si l’on conserve l’état d’un sous-arbre lors de la réentrée via deep history, on déplace en réalité la tenue de cet historique vers le moteur du diagramme
    C’est un choix tout à fait valable, mais cela signifie que le dessin seul ne suffit pas à décrire tout le comportement, et que les transitions d’historique doivent être testées séparément comme toute autre logique d’état

    • Ici, on peut considérer que les inputs désignent soit uniquement les entrées présentes et futures, soit l’ensemble des entrées, y compris les entrées passées ayant conduit à l’état actuel
      Avec cette seconde interprétation, la machine est entièrement déterministe, et le pointeur de deep history fait simplement partie de l’état de la machine
    • Si l’on ne regarde que le scénario décrit, le nœud d’historique semble aussi pouvoir être remodélisé de façon déterministe
      Par exemple, on peut développer les nœuds H et H en plusieurs nœuds, et traiter H' comme une sorte de write-ahead log placé en amont de chacun

  • Je me demande s’il serait possible de combiner les statecharts avec des moteurs de durable execution comme Temporal, DBOS, Restate
    Dans l’entreprise, nous utilisons Cloudflare Workflows pour gérer les workflows d’onboarding et de paiement, et les diagrammes de flowchart générés automatiquement permettent de comprendre très vite le comportement du workflow
    Au fond, cela ressemble beaucoup à la valeur que visent les statecharts

    • Je construis justement Zindex pour être cette couche de « représentation visuelle exécutable des workflows »
      https://zindex.ai/
      Les diagrammes générés par l’IA sont généralement de simples Mermaid/SVG/PNG produits une fois pour toutes, sans état de diagramme persistant permettant mise à jour, validation, diff ou réutilisation
      Zindex traite le diagramme lui-même comme un état structuré
      Les agents modifient nœuds, arêtes, groupes, relations, contraintes et révisions via le Diagram Scene Protocol (DSP), et Zindex se charge de la validation, du layout, du rendu, du versioning et du stockage
      L’idée est donc de pouvoir le brancher à côté de Temporal/DBOS/Restate/Cloudflare Workflows : le moteur reste la source de vérité de l’exécution, tandis que Zindex gère un modèle visuel persistant et vérifiable, dérivé du code ou de l’historique d’exécution
    • J’ai toujours trouvé dommage que seuls les workflows soient mis en avant alors que les state machines restent sous-estimées
      En pratique, avec de la durable execution, les statecharts peuvent tout à fait faire le travail
      Cloudflare semblait pendant un temps aller vers un modèle d’acteurs basé sur durable objects, mais je ne sais pas si ce projet a été abandonné
    • Quand tu dis « générer un diagramme de flowchart », je me demande précisément ce qui le produit
      Est-ce une fonctionnalité intégrée à Cloudflare Workers, ou bien quelque chose développé en interne par ton équipe ?

  • J’adore vraiment XState
    Il a résolu quantité de problèmes dans plusieurs codebases, et récemment il est devenu l’ossature centrale d’une application vocale que nous développons pour le secteur bancaire
    Merci d’y avoir consacré autant de temps et d’efforts pour en faire quelque chose d’aussi solide
    J’ai aussi résumé sur mon blog une partie de mon expérience avec les finite state machines, ainsi que l’architecture que j’avais mise en place avec XState + Mastra
    Après la publication, je suis passé de Mastra à Pipecat
    https://blog.davemo.com/posts/2026-02-14-deterministic-core-agentic-shell.html

  • Je balance aussi ça ici
    ETL State Chart et Hierarchial FSM :
    https://www.etlcpp.com/state_chart.html / https://www.etlcpp.com/hfsm.html
    Quantum Leaps :
    https://www.state-machine.com
    Je les ai surtout utilisés dans des systèmes safety-critical, où la complexité, le timing et la vérifiabilité du comportement sont particulièrement importants
    La possibilité de séparer la prise de décision de l’action aide énormément
    Réduire la décision à « dans cet état, si cet événement arrive, que faut-il faire ensuite ? » diffère un peu de la structure habituelle d’un programme, mais cela crée une bonne séparation et rend le comportement plus facile à raisonner dans des conditions variées

  • J’ai toujours espéré une adoption plus large des machines à états
    À une époque où le code généré par l’IA n’est pas compris aussi en profondeur que le code écrit par des humains, la compréhension visuelle de l’état devient de plus en plus importante
    Malgré cela, les frameworks frontend semblent toujours préférer l’état réactif basé sur des stores
    C’est aussi mon choix par défaut, donc je n’ai pas particulièrement cherché à changer, et des bibliothèques comme xstate gardent la réputation d’être plus difficiles à apprendre et plus verbeuses au niveau de la syntaxe
    Mais avec l’IA, cette barrière baisse presque entièrement, donc je me demande s’il y a d’autres raisons que je ne vois pas, ou si les statecharts n’ont simplement pas encore atteint leur sommet

    • La prochaine version de XState sera bien plus ergonomique
      L’API sera plus réduite, la courbe d’apprentissage plus douce, et l’écriture plus facile pour les développeurs comme pour les agents
      En même temps, les modèles frontier actuels écrivent déjà plutôt bien du code XState

  • En travaillant sur le projet https://github.com/xlnfinance/xln, j’ai réalisé qu’il me fallait un moyen d’émuler le réseau de façon déterministe
    Puis je me suis dit qu’au fond, toute blockchain est une replicated state machine, donc pourquoi ne pas encapsuler chaque nœud utilisateur dans une hiérarchie de machines à états en 3 niveaux : Runtime -> Entity -> Account
    La machine extérieure contrôlerait entièrement la machine intérieure, un peu comme une « blockchain dans la blockchain » avec différents modes de consensus
    Ensuite, en cherchant « hierarchical state machines », je suis tombé sur les statecharts, et j’ai trouvé les deux idées assez proches
    À mon avis, davantage de logiciels devraient utiliser des hiérarchies de machines à états pour réduire les pires bugs causés par la non-déterminisme

  • Dans l’automobile, ce genre d’approche est utilisé depuis très longtemps
    Avec matlab/simulink, on peut dessiner les algorithmes sous forme de machines à états puis générer le code
    Récemment, j’ai aussi implémenté une machine à états pour gérer un composant React assez complexe, qui passait par des transitions CSS et naviguait entre plusieurs états visuels
    La machine à états en elle-même n’était pas particulièrement difficile, mais les gens ne semblent pas encore assez familiers avec cette manière de faire

    • Les moteurs de jeu ont probablement déjà implémenté ça, ou des versions encore plus évoluées

  • Dans l’entreprise, depuis que j’ai créé un interpréteur interne à Postgres, nous faisons tourner tous les processus métier avec des statecharts
    L’expérience a été excellente, les processus sont devenus très robustes face au changement, et restent faciles à comprendre même des années plus tard
    J’ai aussi publié la bibliothèque en open source
    https://github.com/kronor-io/statecharts