16. Estados y transiciones: objetos cuyo significado cambia durante el proceso
16.1 Introducción
Muchos objetos del dominio cambian de significado durante un proceso. Un Turno puede estar disponible, reservado, confirmado, cancelado, atendido o ausente. Un Pedido puede estar pendiente, pagado, enviado, entregado o anulado. Una Factura puede estar emitida, pagada o anulada. Estos cambios no son simples etiquetas: determinan qué acciones están permitidas y qué reglas se aplican.
Modelar estados y transiciones ayuda a comprender el ciclo de vida de conceptos importantes. También evita permitir operaciones inválidas, como cancelar un turno ya atendido o enviar un pedido que todavía no fue pagado.
16.2 Imagen conceptual de estados y transiciones
16.3 Qué es un estado
Un estado representa una situación significativa en la que puede encontrarse un objeto del dominio durante su ciclo de vida. No todo atributo es un estado. Para que una situación sea estado, normalmente debe afectar reglas, acciones permitidas, decisiones o interpretación del objeto.
Por ejemplo, que un Turno esté reservado significa que ya no puede ofrecerse libremente a otro paciente. Que esté atendido significa que no debería cancelarse como si aún estuviera pendiente. Cada estado cambia el significado del objeto.
16.4 Qué es una transición
Una transición es el cambio de un estado a otro. Suele ocurrir por una acción, un evento, una decisión o el paso del tiempo. Por ejemplo, un Turno pasa de disponible a reservado cuando un paciente lo reserva. Pasa de reservado a cancelado cuando se cancela. Pasa de confirmado a atendido cuando se registra la atención.
Las transiciones deben estar controladas por reglas. No todos los cambios son válidos. Un turno atendido no debería volver a disponible sin una regla explícita que justifique esa operación.
16.5 Estados frente a tipos
Como vimos en el tema anterior, no conviene confundir estados con tipos. Un tipo suele ser una clasificación más estable. Un estado cambia durante el ciclo de vida. Turno presencial y Turno virtual pueden ser tipos o modalidades. Turno reservado y Turno cancelado son estados.
Una buena pregunta es: ¿la misma instancia puede pasar de una categoría a otra durante su vida normal? Si la respuesta es sí, probablemente hablamos de estados.
16.6 Estados frente a eventos
Un estado describe una situación actual. Un evento describe algo que ocurrió. "Reservado" es un estado. "Turno reservado" es un evento que pudo causar el cambio al estado reservado. "Cancelado" es un estado. "Turno cancelado" es un hecho ocurrido en un momento.
Distinguir ambos conceptos ayuda a modelar mejor. El estado permite saber qué puede hacerse ahora. El evento permite conocer cómo se llegó a esa situación y puede ser parte del historial.
16.7 Ciclo de vida de un turno
Un ciclo de vida simple para Turno podría ser:
Con caminos alternativos:
Confirmado -> Cancelado
Confirmado -> Ausente
Este ciclo no es universal. Cada organización puede tener reglas diferentes. Algunas pueden no usar confirmación. Otras pueden permitir reprogramación, lista de espera o sobreturnos.
16.8 Acciones permitidas según estado
Una de las razones principales para modelar estados es definir acciones permitidas. Por ejemplo:
- Un Turno disponible puede reservarse.
- Un Turno reservado puede confirmarse o cancelarse.
- Un Turno confirmado puede atenderse, cancelarse o marcarse como ausente.
- Un Turno atendido no puede cancelarse como turno pendiente.
- Un Turno cancelado puede liberar la franja, según las reglas del negocio.
Estas reglas evitan transiciones incoherentes.
16.9 Transiciones disparadas por acciones
Muchas transiciones ocurren porque una persona o sistema realiza una acción. Reservar, cancelar, confirmar, atender, pagar, aprobar, rechazar o enviar son acciones que pueden cambiar estados.
Al analizar una acción, conviene preguntar desde qué estados puede ejecutarse, a qué estado lleva, quién puede realizarla, qué condiciones deben cumplirse y qué consecuencias produce.
16.10 Transiciones disparadas por tiempo
Otras transiciones ocurren por el paso del tiempo. Un turno no confirmado puede vencer. Una reserva puede expirar. Una promoción puede dejar de estar vigente. Un pedido pendiente puede cancelarse automáticamente después de cierto plazo.
Estas transiciones requieren reglas temporales claras: cuánto tiempo debe pasar, desde qué momento se cuenta, qué calendario se usa y qué ocurre si hay días no laborables o feriados.
16.11 Estados finales
Algunos estados son finales o casi finales. Un Turno atendido normalmente cierra el ciclo del turno. Un Pedido entregado puede considerarse final, salvo devoluciones. Una Factura anulada conserva registro, pero ya no sigue el mismo proceso que una factura activa.
Identificar estados finales ayuda a evitar operaciones inválidas y a comprender cuándo un proceso termina.
16.12 Estados intermedios
Algunos estados representan etapas intermedias. Un Pedido puede estar en preparación antes de enviarse. Una Agenda puede estar en borrador antes de publicarse. Una Reserva puede estar pendiente antes de confirmarse.
Los estados intermedios suelen ser necesarios cuando hay reglas, revisiones o acciones específicas antes de llegar al estado final. Si no aportan reglas ni decisiones, quizá no hace falta modelarlos explícitamente.
16.13 Tabla de transiciones
Una tabla puede ayudar a revisar estados y transiciones:
| Estado actual | Acción o evento | Estado resultante | Condición |
|---|---|---|---|
| Disponible | Reservar turno | Reservado | La franja no debe estar ocupada. |
| Reservado | Confirmar turno | Confirmado | Debe realizarse antes del vencimiento. |
| Reservado | Cancelar turno | Cancelado | Debe cumplir política de cancelación. |
| Confirmado | Registrar atención | Atendido | Debe haber llegado la fecha del turno. |
| Confirmado | Registrar inasistencia | Ausente | El paciente no asistió. |
16.14 Diagramas de estados
Los diagramas de estados de UML son útiles para representar ciclos de vida. Muestran estados como nodos y transiciones como flechas. Permiten visualizar qué caminos son válidos y qué eventos producen cambios.
No siempre hace falta un diagrama formal. Para modelos simples, una tabla o lista puede alcanzar. Pero cuando un objeto tiene muchos estados, reglas y caminos alternativos, el diagrama de estados ayuda a detectar huecos e inconsistencias.
16.15 Estados y reglas de negocio
Cada estado puede habilitar o prohibir reglas. Por ejemplo, un Turno reservado puede cancelarse, pero un Turno atendido no. Una Factura emitida puede anularse, pero una Factura en borrador quizá puede eliminarse sin anulación formal.
Al modelar estados, conviene asociar cada estado con las acciones permitidas, las restricciones y los eventos que pueden ocurrir. Esto permite construir pruebas más completas y evitar comportamientos no previstos.
16.16 Preguntas para descubrir estados
Estas preguntas ayudan a identificar estados y transiciones:
- ¿Qué situaciones importantes puede atravesar este concepto?
- ¿Qué acciones se permiten o prohíben en cada situación?
- ¿Qué evento provoca el cambio de estado?
- ¿Hay estados finales?
- ¿Hay estados temporales o intermedios?
- ¿El paso del tiempo cambia el estado?
- ¿Qué estados son visibles para los usuarios y cuáles son internos al negocio?
16.17 Errores frecuentes
Al modelar estados y transiciones, suelen aparecer estos errores:
- Usar estados como simples etiquetas sin reglas asociadas.
- Confundir estados con tipos, roles o categorías.
- No definir qué transiciones son válidas.
- Permitir que cualquier estado cambie a cualquier otro.
- Olvidar transiciones producidas por el paso del tiempo.
- No identificar estados finales o irreversibles.
- No validar el ciclo de vida con expertos y escenarios reales.
16.18 Qué debes recordar de este tema
- Un estado representa una situación significativa de un objeto del dominio.
- Una transición es un cambio de estado provocado por una acción, evento, decisión o tiempo.
- Los estados determinan qué acciones están permitidas y qué reglas se aplican.
- No conviene confundir estados con tipos, roles o eventos.
- Las transiciones deben validarse con condiciones claras.
- Los diagramas de estados ayudan cuando el ciclo de vida es complejo.
- Modelar estados evita operaciones inválidas y mejora la comprensión del proceso.
16.19 Conclusión
Los estados y transiciones permiten representar objetos cuyo significado cambia durante un proceso. Hacen visible el ciclo de vida del dominio, muestran qué acciones son válidas y ayudan a ubicar reglas según la situación de cada objeto. Cuando un concepto importante cambia de estado, modelarlo explícitamente evita ambigüedad y errores.
En el próximo tema estudiaremos los eventos de dominio, es decir, hechos importantes que ya ocurrieron y que pueden afectar el modelo o iniciar nuevos procesos.