Statecharts: máquinas de estados jerárquicas

 (statecharts.dev)
1 puntos por GN⁺ 3 일 전 | 1 comentarios | Compartir por WhatsApp
  • Es un formato para estructurar visualmente el comportamiento de sistemas complejos; amplía la state machine básica para abordar el problema de la explosión de estados
  • Permite la separación entre comportamiento y componentes, lo que facilita cambiar el comportamiento y razonar sobre el código, además de adaptarse bien a pruebas independientes del componente y a la exploración de casos excepcionales
  • Al crear un statechart se terminan explorando todos los estados posibles, y también hay resultados de investigación donde el código basado en statecharts mostró menos bugs que el código tradicional
  • Mediante el estándar SCXML y herramientas y bibliotecas en varios lenguajes, es posible leer, escribir y ejecutar modelos, además de ayudar a procesar correctamente el orden de ejecución de comportamientos como entry/exit action
  • Si se usa un formato de máquina ejecutable, una sola definición puede servir como single source of truth para mantener juntos el comportamiento en runtime y el diagrama, por lo que mantener la sincronización entre implementación y diseño se vuelve importante

Resumen de Statecharts

  • Un Statechart es un formato visual para manejar sistemas complejos, una extensión de la state machine básica
  • Está reforzado para manejar el problema de la explosión de estados que aparece cuando una state machine crece
  • Puede expresar el comportamiento en un diagrama, pero en ingeniería de software está más cerca del modelado y la estructuración del comportamiento que de la visualización en sí
  • La explicación base relacionada continúa en What is a state machine? y What is a statechart?

Por qué usar Statecharts

  • Tiene una estructura fácil de entender, por lo que suele ser más fácil de comprender que muchas otras formas de código
  • Permite la separación entre comportamiento y componentes
    • Facilita cambiar el comportamiento
    • Facilita razonar sobre el código
    • Permite probar el comportamiento independientemente de los componentes
  • Durante la creación de un statechart se exploran todos los estados posibles
  • Hay resultados de investigación donde el código basado en statecharts tuvo menos bugs que el código tradicional
  • Se adapta bien al manejo de casos excepcionales que suelen pasarse por alto
  • A medida que crece la complejidad, mejora su escalabilidad
  • También es fácil de entender para personas no desarrolladoras, y QA puede usarlo como herramienta de exploración
  • Ya hay mucho código que contiene state machines de forma implícita, y statecharts funciona como una forma de hacerlo explícito

Costo y objeciones frente a Statecharts

  • Requiere un nuevo costo de aprendizaje
    • El concepto base, la state machine, puede resultar familiar para muchos programadores
  • Como difiere bastante de la forma tradicional de programar, puede sentirse como un paradigma poco familiar
    • Esto puede generar rechazo a nivel de equipo
  • En statecharts pequeños, el proceso de separar comportamientos puede aumentar la cantidad de líneas de código
  • Entre las razones por las que no se usa más están la falta de conocimiento y YAGNI actuando en conjunto
  • Entre las objeciones más comunes están que supuestamente no hace falta, que no encaja con ciertos enfoques tecnológicos y que aumenta la cantidad de bibliotecas
    • En aplicaciones web, puede aumentar el tiempo de carga
  • Incluso considerando estas ventajas y desventajas, el efecto de adoptarlo en general se acerca más a una ganancia neta

Forma de uso y SCXML

  • SCXML es un formato estandarizado por el W3C entre 2005 y 2015 que define varias reglas semánticas de los statecharts y el manejo de edge cases
  • Existen herramientas en varios lenguajes para leer, escribir y ejecutar SCXML
  • También hay formatos derivados con sintaxis distinta que mantienen el mismo modelo
  • Existen bibliotecas de statecharts para varias plataformas, con distintos niveles de soporte para la semántica de SCXML
  • Usar estas bibliotecas ayuda a procesar correctamente el orden de ejecución de comportamientos como entry/exit action
  • La guía de uso adicional continúa en how to use statecharts

Statecharts ejecutables

  • En lugar de usar statecharts solo como documentación, se puede usar un formato de máquina ejecutable tanto en el diseño como en el runtime
  • Una sola definición puede servir como single source of truth para impulsar tanto el comportamiento real en runtime como el diagrama visual
  • Ya no hace falta trasladar el diagrama al código
  • Se pueden reducir los bugs que aparecen al traducirlo manualmente
  • El diagrama y la implementación se mantienen siempre en un estado sincronizado
  • El diagrama se vuelve más preciso
  • En contraste, el diagrama puede volverse bastante complejo
  • Las opciones de formatos y herramientas para statecharts ejecutables son limitadas
  • Es difícil garantizar con fuerza la seguridad de tipos entre el statechart y los componentes
  • Si la definición del statechart está dentro del código, se puede generar automáticamente un statechart visual a partir de esa representación
    • Esto se vuelve más simple cuando la definición está en un archivo separado como JSON o XML

Comunidad y materiales adicionales

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 일 전
Comentarios en Hacker News

  • Me da gusto ver que statecharts siga recibiendo atención
    Yo hice XState, una biblioteca para escribir/ejecutar/visualizar máquinas de estado y statecharts para JS/TS, y se puede ver en https://github.com/statelyai/xstate
    Lo principal que aprendí después de más de 10 años trabajando en esto es que los statecharts aportan mucho más valor cuando se tratan no como simple documentación, sino como comportamiento ejecutable
    No hace falta usarlos en todas partes, pero son especialmente potentes cuando "¿qué pasa después?" depende tanto del estado actual como del evento
    Estos diagramas pueden usarse como una especie de oráculo que responde "si llega este evento en este estado, ¿cuál es el siguiente estado y qué efecto se ejecuta?"
    La siguiente versión mayor de XState también está casi lista en alfa, con foco en ergonomics, seguridad de tipos, composability y un nuevo visualizer/editor
    La herramienta básica de visualización open source está en https://sketch.stately.ai
    Del lado de las especificaciones formales, vale la pena leer SCXML: https://www.w3.org/TR/scxml
    Y el artículo original de David Harel también vale mucho la pena: https://www.weizmann.ac.il/math/harel/sites/math.harel/files/users/user50/Statecharts.pdf

    • Gracias a ti conocí por primera vez las state machines
      También hay un video de una charla en Laracon donde organizaste tus ideas sobre state machines y statecharts
      https://www.youtube.com/watch?v=1A1xFtlDyzU
    • En el lado de Clojure, vale la pena recomendar https://github.com/fulcrologic/statecharts
      Es una implementación bastante madura que se mantiene bastante cerca de SCXML, pero elimina el requisito de XML, especialmente en el contenido ejecutable
      En la sección de prior art también aparece XState como caso de referencia
    • Al usar XState, fue muy útil incluso sin conocer el término statecharts
      Lo apliqué junto con lit.js a un componente de navegación tipo drawer que respondía al ancho de la página y tenía muchas props y estado interno, y no quiero ni imaginar lo terrible que habría sido sin XState
    • Antes ordené muchas situaciones complejas y enredadas con XState
      También espero con ganas la siguiente versión, de verdad gracias
    • Si no necesitas máquinas de estado anidadas complejas, robot3.js también vale la pena
      La inferencia automática de tipos de TS es bastante buena, así que es cómodo de usar cuando necesitas lógica ligera de máquinas de estado

  • Antes parecía que los statecharts estaban ganando impulso poco a poco en el ecosistema frontend/UI, y da pena que por alguna razón ese impulso se haya desvanecido
    Usar máquinas de estado para interacciones de UI, especialmente composiciones de máquinas de estado como statecharts, hace mucho más fácil razonar sobre flujos complejos
    Si es la primera vez que te acercas al tema, recomiendo muchísimo "Constructing the user interface with statecharts" de Ian Horrucks
    Aunque es un libro de 1999, sigue siendo de lo mejor como introducción que explica cómo aplicarlo y usarlo en la práctica
    https://archive.org/details/isbn_9780201342789/mode/2up

    • XState todavía sigue expandiéndose bastante
      Supera los 4 millones de descargas semanales en npm, y herramientas de animación como Rive y LottieFiles también destacan mucho sus capacidades de máquinas de estado
      Herramientas de IA como LangGraph también están montadas sobre una base de máquinas de estado
      Tal vez aún haga falta tiempo para que estas apps y herramientas aprovechen por completo el potencial de los statecharts, pero el arranque es bueno
    • Yo también conocí los statecharts viendo este plugin de Godot
      https://github.com/derkork/godot-statecharts

  • Algo que suele faltar en los materiales introductorios son los history pseudo-states
    Cuando usas H, H, desde fuera el statechart se vuelve formalmente no determinista
    A menudo se explica que "el estado actual es una función pura de la entrada", pero history rompe esa premisa
    Si vuelves a entrar al estado padre por medio de H, regresas al hijo que estuvo activo por última vez, así que incluso con el mismo evento y el mismo estado externo puedes entrar en distintos estados internos
    Ese "último hijo activo" oculto es en sí mismo estado, pero normalmente no se dibuja en el diagrama
    El artículo original de Harel también lo reconoce, y SCXML y XState también lo implementan, pero curiosamente casi no se habla de esta parte
    Así que si con deep history conservas el estado del subárbol al reingresar, en el fondo estás moviendo ese bookkeeping al motor del diagrama
    Está bien como elección, pero el dibujo por sí solo ya no describe todo el comportamiento, y las transiciones con history también necesitan pruebas aparte igual que cualquier otra lógica de estado

    • Aquí inputs podría interpretarse como solo las entradas presentes y futuras, o como la entrada completa incluyendo las pasadas que llevaron hasta la posición actual
      Bajo esta segunda interpretación, la máquina es completamente determinista y el puntero de deep history es simplemente parte del estado de la máquina
    • Viendo solo el escenario que describiste, parece que el nodo history podría volver a modelarse de forma determinista
      Por ejemplo, desplegando los nodos H, H en varios nodos y usando H' como una especie de write-ahead log colocado delante de cada nodo

  • Me pregunto si se podrían combinar motores de durable execution como Temporal, DBOS, Restate con statecharts
    En la empresa usamos Cloudflare Workflows para gestionar workflows de onboarding y pagos, y gracias al diagrama de flowchart que sale automáticamente podemos entender muy rápido cómo se comporta el workflow
    Eso se parece bastante al valor que los statecharts intentan ofrecer

    • Estoy construyendo Zindex justamente con la meta de ser esa capa de "representación visual de workflows ejecutables"
      https://zindex.ai/
      Los diagramas que genera la IA normalmente son Mermaid/SVG/PNG de una sola vez, así que no existe un estado persistente del diagrama que permita actualizar, validar, diff o reutilizar
      Zindex trata el diagrama mismo como estado estructurado
      Los agentes hacen patch de nodos, edges, grupos, relaciones, restricciones y revisiones mediante el Diagram Scene Protocol (DSP), y Zindex se encarga de validation, layout, rendering, versioning y storage
      Por eso creo que puede colocarse al lado de Temporal/DBOS/Restate/Cloudflare Workflows: el motor mantiene la fuente de verdad de la ejecución, y Zindex administra un modelo visual persistente e inspeccionable derivado del código o del historial de ejecución
    • Siempre me ha dado pena que solo los workflows reciban los reflectores y que las state machines queden infravaloradas
      En realidad, si les agregas durable execution, los statecharts pueden hacer perfectamente ese trabajo
      Parecía que Cloudflare iba por un tiempo en la dirección del modelo de actor de durable object, aunque no sé si abandonaron ese proyecto
    • Me da curiosidad qué significa exactamente eso de "generar un diagrama de flowchart"
      Quisiera saber si es una función integrada de Cloudflare Workers o si es algo que su equipo hizo por su cuenta

  • Me encanta XState
    Ha resuelto muchísimos problemas en varias codebases, y recientemente se convirtió en la columna vertebral de una app de voz que estamos haciendo para el sector bancario
    Gracias por invertir tanto tiempo y esfuerzo en construir algo tan bueno
    También escribí un poco en mi blog sobre mi experiencia con finite state machines y la arquitectura que armé con XState + Mastra
    Después de publicarlo, cambié de Mastra a Pipecat
    https://blog.davemo.com/posts/2026-02-14-deterministic-core-agentic-shell.html

  • Dejo esto también por aquí
    ETL State Chart y Hierarchial FSM:
    https://www.etlcpp.com/state_chart.html / https://www.etlcpp.com/hfsm.html
    Quantum Leaps:
    https://www.state-machine.com
    Los he usado principalmente en sistemas safety-critical, donde la complejidad, el timing y la capacidad de verificar el comportamiento son especialmente importantes
    Poder separar la toma de decisiones de las acciones ayuda mucho
    Esa forma de reducir la toma de decisiones a "si llega este evento en este estado, ¿qué hago después?" es un poco distinta de la estructura habitual de los programas, pero genera una buena separación y hace más fácil razonar sobre el comportamiento bajo distintas condiciones

  • Siempre he querido que la adopción de las máquinas de estado crezca más
    En una era donde el código generado por IA no se entiende tan a fondo como el código escrito por humanos, la comprensión visual del estado se vuelve cada vez más importante
    Aun así, en los frameworks de frontend todavía parece preferirse más el estado reactivo basado en stores
    Yo también suelo usar eso por defecto, así que no he hecho un esfuerzo por cambiar, y además existe la percepción de que bibliotecas como xstate son más difíciles de aprender y más verbosas
    Pero con IA esa barrera casi desaparece, así que me pregunto si hay otra razón que no estoy viendo o si los statecharts simplemente todavía no alcanzan su punto máximo

    • La siguiente versión de XState será mucho más ergonomic
      La superficie del API también se reducirá, la curva de aprendizaje bajará y será más fácil de escribir tanto para desarrolladores como para agentes
      Al mismo tiempo, los modelos frontier modernos ya escriben código de XState bastante bien

  • Mientras trabajaba en el proyecto https://github.com/xlnfinance/xln, me di cuenta de que necesitaba una forma de emular determinísticamente una red real
    Entonces pensé que, si al final toda blockchain es una replicated state machine, quizá podría envolver cada nodo de usuario en una jerarquía de máquinas de estado de 3 niveles: Runtime -> Entity -> Account
    Como la máquina externa controla por completo a la interna, la imagen sería algo así como "blockchain dentro de blockchain" con distintos modos de consenso
    Después busqué "hierarchical state machines" y encontré los statecharts, y sentí que ambas ideas eran bastante parecidas
    En mi opinión, más software debería usar jerarquías de máquinas de estado para reducir los peores bugs que provoca el no determinismo

  • En el sector automotriz llevan muchísimo tiempo usando este enfoque
    Si ves matlab/simulink, puedes dibujar algoritmos como máquinas de estado y hasta generar código a partir de eso
    Hace poco implementé una máquina de estado para gestionar un componente de React bastante complejo, que iba pasando por varios estados visuales mientras atravesaba CSS transition
    La máquina de estado en sí no fue especialmente difícil, pero parece que la gente todavía no está lo bastante familiarizada con esto

    • Supongo que los game engines probablemente ya tienen implementado algo así, o versiones más avanzadas

  • En la empresa, desde que construí un intérprete dentro de Postgres, estamos ejecutando todos los procesos de negocio con statecharts
    La experiencia ha sido muy buena, los procesos se volvieron muy resistentes al cambio y siguen siendo fáciles de entender incluso al volver a ellos años después
    También publiqué la biblioteca como open source
    https://github.com/kronor-io/statecharts