Por qué visualizar: el diagrama como formalismo, no como adorno

Casi todo el mundo ha visto un diagrama de cajas y flechas pegado en un documento de arquitectura y ha aprendido, con el tiempo, a no fiarse de él. La desconfianza está justificada: ese diagrama se dibujó una vez, describía el sistema de entonces y nadie lo ha vuelto a tocar desde que el sistema cambió. La lección que sigue no defiende que dibujar sea bueno —eso sería trivial y falso—, sino algo mucho más estrecho y mucho más fuerte: que un statechart pertenece a una categoría distinta de la del dibujo, la categoría que David Harel llamó formalismo visual, y que esa pertenencia cambia la economía entera de la documentación. Un formalismo visual no ilustra el comportamiento: lo define. Y lo que define el comportamiento no puede desincronizarse de él, porque no hay dos cosas que sincronizar.

Dibujo, modelo, formalismo

Tres artefactos que se parecen en la pizarra son radicalmente distintos en su régimen de verdad. El primero es el dibujo: cajas y flechas sin gramática, donde una flecha puede significar llamada, dependencia, flujo de datos o simple cercanía conceptual, según quién la mirase el día que se pintó. El segundo es el modelo informal: hay convenciones, quizá heredadas de UML, pero la semántica vive en la cabeza del equipo y nada impide dibujar una configuración que el sistema real jamás alcanzaría. El tercero es el formalismo visual: una notación gráfica con semántica operacional definida, en la que el diagrama es una sintaxis alternativa de un objeto matemático preciso, y por tanto se puede ejecutar, simular, verificar y traducir sin pérdida.

La prueba de pertenencia a la tercera categoría es sencilla de aplicar y despiadada: si no puedes ejecutar el diagrama, no es un formalismo visual, por muy formal que parezca. Un diagrama de secuencia de UML dibujado con esmero sigue siendo un modelo informal si ninguna herramienta puede recorrerlo; y un statechart garabateado a mano en una servilleta ya pertenece a la tercera categoría en cuanto se transcribe, porque su semántica no depende de la calidad del trazo sino de la notación. La categoría no la determina el aspecto del artefacto, sino si existe una función definida que lleve cada símbolo a un significado computable.

Harel introdujo los statecharts en 1987 con exactamente esa ambición, y el subtítulo de su artículo —una formalidad visual para sistemas complejos— no era retórica. Lo que propuso no fue un estilo de dibujo sino una extensión de los autómatas finitos con jerarquía, ortogonalidad y difusión de eventos, junto con una semántica que dice sin ambigüedad qué ocurre cuando llega un evento en una configuración dada. Que se dibuje bien es una consecuencia agradable de esa formalidad, no su propósito. La confusión de las décadas siguientes —tratar los statecharts como una técnica de diagramación— invirtió causa y efecto, y explica gran parte del escepticismo actual hacia los diagramas.

La distinción no es académica: determina qué preguntas puedes hacerle al artefacto. A un dibujo solo puedes preguntarle qué recuerda su autor. A un modelo informal puedes preguntarle qué estados existen, pero no si una secuencia concreta de eventos es alcanzable. A un formalismo visual puedes preguntarle si el estado expirado es alcanzable desde anonimo sin pasar por autenticado, y obtener una respuesta calculada, no opinada. Esa capacidad de interrogar mecánicamente el modelo es lo que convierte el diagrama en una herramienta de ingeniería y no en un elemento de presentación.

Conviene añadir una precisión que suele omitirse al contar esta historia. Lo que hizo dibujable un autómata de tamaño realista no fue la notación gráfica sino la jerarquía y la ortogonalidad que Harel le añadió: un autómata plano con veinte modos independientes tiene un número de estados que ninguna hoja puede contener, mientras que el mismo comportamiento expresado con estados compuestos y regiones paralelas cabe holgadamente en una pantalla. La visualización es un beneficio de la estructura, no al revés. Quien intenta dibujar una máquina plana grande concluye que los diagramas no escalan, y tiene razón; lo que no escala es su modelo, y el diagrama se limita a decírselo antes que el código.

La deriva y el valor negativo

Cuando el código y el diagrama son dos artefactos distintos, la sincronización entre ellos es un trabajo humano, recurrente y sin recompensa inmediata. La teoría de la evolución del software de Lehman lo formuló hace medio siglo: un sistema en uso cambia sin descanso y su complejidad crece salvo que se invierta explícitamente en reducirla. La documentación separada es la primera víctima de esa dinámica, porque la penalización por no actualizarla llega tarde, es difusa y recae sobre otra persona. La deriva no es un fallo de disciplina del equipo: es el resultado esperable de un sistema de incentivos donde el coste de actualizar es inmediato y el beneficio, diferido y ajeno.

flowchart LR
subgraph DOS_ARTEFACTOS
  A[Codigo de ayer] -->|cambia cada dia| B[Codigo de hoy]
  C[Diagrama dibujado a mano]
  B -.deriva silenciosa.-> C
end
subgraph UNA_FUENTE
  D[Definicion serializable] --> E[Diagrama]
  D --> F[Simulacion]
  D --> G[Traza en vivo]
  D --> H[Recorridos de prueba]
end

Hay un matiz que la formulación habitual del problema pasa por alto y que agrava el diagnóstico: un diagrama mantenido a mano no es solo una copia que puede desviarse, es un segundo sistema con su propio trabajo pendiente. Tiene convenciones que alguien decidió, un formato que alguien eligió, una herramienta que hay que instalar y una persona que sabe usarla. Cuando esa persona cambia de equipo, el diagrama deja de actualizarse aunque nadie lo anuncie, y su fecha de defunción no queda registrada en ninguna parte. Los artefactos con un solo cuidador no se abandonan mediante una decisión: simplemente dejan de recibir cuidados.

De ahí se sigue una conclusión incómoda: un diagrama desactualizado no vale menos que ningún diagrama, vale menos que cero. Quien no tiene diagrama sabe que no lo tiene y va al código; quien tiene uno obsoleto razona sobre un sistema que no existe, toma decisiones basadas en transiciones que se eliminaron hace tres meses y descubre el engaño en producción. El coste de la mentira es proporcional a la confianza que inspira, y un diagrama bonito inspira mucha. Por eso la regla práctica es dura: si un diagrama no se genera automáticamente y nadie va a mantenerlo, la decisión correcta no es actualizarlo una vez más, es borrarlo.

La regla admite una formulación operativa que conviene adoptar como política de equipo, porque zanja discusiones estériles. Todo diagrama del repositorio debe declarar en su encabezado a cuál de tres categorías pertenece: derivado, y entonces indica el comando que lo regenera; congelado con fecha, y entonces se lee como una fotografía histórica y nadie debe confiar en él para decidir; o candidato a borrado. No existe la cuarta categoría, la de mantenido por buena voluntad, porque es la que produce todos los diagramas mentirosos que cualquiera puede encontrar hoy en su propio proyecto sin buscar mucho.

Merece la pena contrastar esta situación con la propuesta de la programación literaria de Knuth, que intentó resolver el mismo problema por el camino contrario: en lugar de derivar la descripción del programa, entrelazar ambos en un único documento del que se extraen el código y la prosa. La idea era correcta en su diagnóstico —el problema es la separación— y frágil en su remedio, porque la prosa entrelazada sigue siendo prosa y nada impide que describa algo que el código adyacente ya no hace. Derivar es estrictamente más fuerte que entrelazar: entrelazar acerca los dos artefactos, derivar elimina uno de los dos.

Esto explica el fracaso histórico del round-trip engineering en las herramientas CASE de UML durante los años dos mil. La promesa era exactamente la nuestra —edita el diagrama y obtén el código, edita el código y obtén el diagrama— y no se cumplió por una razón estructural, no por falta de ingeniería. El código fuente contiene mucho más de lo que el diagrama puede expresar, así que la traducción de vuelta era lossy; las herramientas insertaban marcas de generación en los archivos, los desarrolladores las tocaban, y cada ciclo introducía conflictos que solo un humano podía resolver. Round-trip entre dos representaciones de expresividad desigual es, en el mejor de los casos, una fusión perpetua.

Una fuente, varias proyecciones

La máquina de XState es un valor: una estructura de datos anidada, sin funciones en su núcleo si se respeta la disciplina de nombrar las implementaciones en lugar de incrustarlas. Leerla no la ejecuta. Esa propiedad, que el nivel 3 estableció y que aquí se cobra por completo, es la que permite tratar el diagrama como una proyección y no como una copia. La analogía exacta viene de las bases de datos: una vista no es una segunda tabla que haya que mantener en sincronía con la primera, es una consulta sobre la tabla que se evalúa cuando se mira. El diagrama de un statechart es una vista sobre la definición.

import { createMachine } from 'xstate'

export const pedido = createMachine({
  id: 'pedido',
  initial: 'borrador',
  states: {
    borrador: { on: { ENVIAR: 'revision' } },
    revision: {
      on: { APROBAR: 'listo', DEVOLVER: 'borrador' },
    },
    listo: { type: 'final' },
  },
})

// Nada de esto arranca la maquina: solo la interroga como dato.
const nombres = Object.keys(pedido.config.states ?? {})
const finales = nombres.filter((n) => pedido.config.states?.[n]?.type === 'final')

Las proyecciones útiles son al menos cuatro y las cuatro salen de la misma fuente sin intervención manual. Cada una responde a una pregunta distinta y tiene un lector distinto, lo cual explica por qué ninguna sustituye a las demás y por qué el nivel dedica una lección a cada familia.

Ninguna de las cuatro es un documento: las cuatro son funciones de la definición, y esa es la razón de que no aparezcan en la lista de tareas pendientes de nadie. Una consecuencia menos obvia es que las proyecciones que no usas también las estás pagando, solo que a mano y peor: si dibujas el flujo en una pizarra para explicárselo a alguien, estás calculando la primera proyección con tu cerebro; si razonas en voz alta sobre qué pasaría con cierta secuencia, estás simulando; si buscas en los registros qué hizo el usuario, estás reconstruyendo una traza. El trabajo se hace igual; la única variable es si lo hace la máquina o tú.

La proyección más infravalorada de las cuatro es la primera, y no por lo que muestra sino por dónde se muestra. Un diagrama derivado que aparece en la petición de cambio convierte la revisión de una modificación de comportamiento en un ejercicio visual de treinta segundos —esta flecha ya no está, esta caja es nueva— para el que no hace falta conocer el archivo ni el lenguaje. La última lección del nivel construye esa tubería. Merece la pena adelantar aquí por qué importa tanto: es el único punto del proceso donde una decisión de comportamiento todavía se puede discutir con quien tiene autoridad para cambiarla y sin haber pagado el despliegue.

Nada de esto es gratis, y el nivel entero se entiende mal si se lee como una promesa sin contrapartida. La condición que sostiene las cuatro proyecciones es que el comportamiento esté modelado como dato, y modelar cuesta: obliga a nombrar estados que en un if anidado no tenían nombre, a declarar eventos que antes eran llamadas directas y a decidir por adelantado cosas que el código imperativo permite dejar implícitas hasta que fallan. La tesis honesta no es que visualizar sea gratis, sino que su coste ya está pagado por quien decidió modelar, y que no cobrarlo —tener la máquina y seguir manteniendo diagramas a mano— es la peor combinación posible de las dos.

Merece la pena nombrar la consecuencia epistemológica, porque es la que ordena el nivel entero. La crítica clásica al modelado, que el mapa no es el territorio, presupone que el mapa se dibuja mirando un territorio independiente y que por eso puede equivocarse. Aquí el territorio se compila desde el mapa: la definición que se dibuja es la que se ejecuta. El mapa no puede desviarse del territorio porque el territorio se deriva del mapa. Es la única configuración conocida en la que la crítica de Korzybski deja de aplicar, y no por virtuosismo del equipo sino por la forma del artefacto.