Resolución de conflictos: qué transición gana

Una máquina de estado determinista no es una máquina en la que solo una transición puede dispararse: es una máquina en la que, cuando varias podrían dispararse, existe una regla que decide cuál lo hace, y esa regla da siempre el mismo resultado. La diferencia importa porque los statecharts jerárquicos con regiones ortogonales generan conflictos constantemente y por diseño. Un evento CANCELAR puede estar declarado en un estado hoja, en su padre y en la raíz al mismo tiempo, y las tres declaraciones son legítimas. Lo que hace SCXML no es prohibir esa ambigüedad sino resolverla mediante dos mecanismos encadenados: un orden de selección que recorre el árbol de dentro hacia fuera, y un criterio de preempción basado en qué estados abandona cada candidata. Comprender esos dos mecanismos convierte una fuente crónica de sorpresas en un sistema de prioridades que puedes usar a favor.

Cuándo dos transiciones colisionan de verdad

La definición formal de conflicto es sorprendentemente concreta y no menciona ni el evento ni la guarda: dos transiciones están en conflicto si sus conjuntos de salida se intersecan, es decir, si ambas pretenden abandonar al menos un estado en común. Todo lo demás es coincidencia inofensiva.

Esa definición tiene una consecuencia inmediata y liberadora. Dos transiciones que responden al mismo evento en dos regiones paralelas distintas no están en conflicto, porque cada una abandona estados de su propia región. Pueden y deben ejecutarse las dos en el mismo microstep. En cambio, una transición de un hijo y otra de su padre que responden al mismo evento sí colisionan casi siempre, porque el conjunto de salida del padre incluye a todos sus descendientes activos, y entre ellos está el hijo.

stateDiagram-v2
state Sesion {
  [*] --> Panel
  state Panel {
    [*] --> Lista
    Lista --> Detalle : ABRIR
    Detalle --> Lista : ESC
  }
  Panel --> Ajustes : ESC
}
Sesion --> Bloqueada : ESC

En ese diagrama el evento ESC está declarado en tres niveles. Si la configuración activa incluye Detalle, las tres transiciones están habilitadas y las tres colisionan: la de Detalle sale de Detalle, la de Panel sale de Panel y por tanto de Detalle, y la de Sesion sale de todo. El algoritmo debe elegir una, y elige siempre la misma.

Nótese que la colisión depende de la configuración y no solo del documento. Las mismas tres transiciones no colisionan si la máquina está en Ajustes: allí la de Detalle ni siquiera es candidata porque su origen no está activo, y las otras dos siguen chocando entre sí pero con un ganador distinto. Un conflicto no es una propiedad estática del diagrama sino una situación que se evalúa en cada evento, y por eso la misma máquina puede responder a ESC de tres maneras según dónde esté.

La selección: de las hojas hacia la raíz

Antes de resolver conflictos hay que reunir candidatas, y el modo de reunirlas ya introduce una prioridad. El algoritmo no recorre todas las transiciones del documento: recorre los estados atómicos de la configuración actual en orden documental y, para cada uno, asciende por la cadena de ancestros. En cada estado visitado examina sus transiciones en orden documental y se queda con la primera cuyo evento coincida y cuya guarda se cumpla. En cuanto encuentra una, deja de ascender para ese estado atómico.

// La forma de la seleccion, simplificada al esqueleto normativo.
function selectTransitions(evento: Evento): Transicion[] {
  const habilitadas: Transicion[] = []
  for (const atomico of estadosAtomicosEnOrdenDocumental()) {
    // se asciende hasta la raiz o hasta encontrar una candidata
    for (const estado of [atomico, ...ancestrosDe(atomico)]) {
      const t = estado.transiciones.find(
        (t) => coincideEvento(t, evento) && guardaSeCumple(t),
      )
      if (t) { habilitadas.push(t); break }
    }
  }
  return removeConflictingTransitions(habilitadas)
}

De aquí salen las dos reglas prácticas que gobiernan tu día a día. La primera es que el estado más profundo elige antes: al arrancar desde el atómico y ascender, la transición del hijo se encuentra antes que la del padre y corta la búsqueda. La segunda es que dentro de un mismo estado gana la primera declarada: si un estado tiene dos transiciones para el mismo evento con guardas distintas, el orden en que las escribes es el orden en que se prueban, y la primera que pase su guarda se lleva el paso. Por eso una transición sin guarda colocada antes que otra con guarda vuelve inalcanzable a la segunda.

Hay una tercera regla, menos conocida y responsable de bastante desconcierto: una guarda falsa no bloquea el ascenso. Si el hijo declara una transición para el evento pero su guarda no se cumple, el algoritmo no se detiene ahí ni concluye que el evento queda absorbido: sigue probando las demás transiciones del hijo y, si ninguna pasa, continúa subiendo hacia el padre, que puede quedarse con el evento. El comportamiento resultante es una cadena de responsabilidad de abajo arriba, y aprovecharla deliberadamente es idiomático: el hijo maneja el caso especial cuando se dan sus condiciones y deja que el padre aplique la política general en cualquier otro caso.

La preempción: el origen más descendiente desaloja

La selección ya sesga las cosas hacia lo profundo, pero no basta: en una máquina con regiones paralelas pueden llegar a la segunda fase varias candidatas cuyos conjuntos de salida sí se solapan. El procedimiento que limpia esa lista compara las candidatas por pares y aplica un criterio único: si sus conjuntos de salida se intersecan, sobrevive aquella cuyo estado de origen es descendiente del origen de la otra; y si ninguna es descendiente de la otra, sobrevive la que fue seleccionada antes, es decir, la de menor orden documental.

El resultado de aplicar selección y preempción se conoce como el conjunto óptimo de transiciones: el mayor conjunto de transiciones habilitadas y mutuamente compatibles que respeta las prioridades. Ese conjunto es el que se pasa al microstep de la lección anterior, y con él el algoritmo garantiza dos propiedades que dependen la una de la otra: determinismo, porque el conjunto es función únicamente de la configuración, el evento y el documento; y maximalidad, porque no descarta ninguna transición que pudiera haberse ejecutado sin interferir.

La palabra óptimo no es retórica: nombra un compromiso concreto entre dos exigencias que tiran en direcciones opuestas. La concurrencia pide ejecutar todo lo que pueda ejecutarse, porque si dos regiones ortogonales reaccionan al mismo evento y nada les impide hacerlo, suprimir una sería traicionar el significado de ortogonal. El determinismo pide suprimir todo lo ambiguo, porque dos transiciones que se disputan el mismo estado no pueden ganar las dos y elegir al azar destruiría la reproducibilidad. El conjunto óptimo satisface ambas exigencias con la única política que las hace compatibles: conservar el máximo posible sujeto a que no haya solapamiento, resolviendo cada solapamiento con un criterio total y sintáctico.

El punto de variación que casi nadie conoce

Que gane el hijo parece obvio hasta que descubres que no siempre fue así. La semántica original de STATEMATE, la herramienta con la que Harel y su equipo implementaron los statecharts en los años ochenta, da prioridad a la transición de origen más alto: cuando el padre y el hijo compiten, gana el padre. La justificación era razonable en su contexto de sistemas reactivos e ingeniería de control: una regla declarada arriba expresa una política global —una parada de emergencia, un modo degradado— que debe poder imponerse sobre cualquier refinamiento local.

UML eligió lo contrario, y SCXML siguió a UML. El argumento es el del refinamiento: un estado anidado es una especialización de su padre, y una especialización debe poder anular el comportamiento general del mismo modo que una subclase anula un método. Ninguna de las dos posturas es incorrecta; son elecciones distintas sobre qué significa la jerarquía, y son el ejemplo canónico de lo que la literatura llama un punto de variación semántica.

<!-- Bajo SCXML gana la transicion de Detalle. Bajo STATEMATE ganaria la de Panel. -->
<state id="Panel" initial="Lista">
  <transition event="ESC" target="Ajustes"/>
  <state id="Lista">
    <transition event="ABRIR" target="Detalle"/>
  </state>
  <state id="Detalle">
    <transition event="ESC" target="Lista"/>
  </state>
</state>

La lección práctica es que si necesitas el comportamiento de STATEMATE —una regla global que nadie pueda anular— no lo obtendrás peleándote con la prioridad, porque la prioridad no es configurable. Lo obtienes modelándolo: sacando esa transición a una región paralela que nadie más toca, de modo que deje de estar en conflicto con las locales y pueda dispararse junto a ellas en el mismo microstep.

Ese patrón merece un nombre porque aparece una y otra vez: la región supervisora. Consiste en envolver la máquina de trabajo en un parallel cuya segunda región contiene únicamente las transiciones que deben poder ocurrir siempre —la parada de emergencia, el cierre de sesión, la pérdida de conexión— y que al dispararse llevan a un estado desde el que se reconstruye todo. Como esa región es ortogonal a la de trabajo, ningún estado de trabajo puede interceptar sus eventos ni anular sus reglas, y el conflicto desaparece por construcción en lugar de resolverse por prioridad. Es la traducción idiomática de la intuición de STATEMATE a un sistema que eligió lo contrario.