19. Estados, eventos, transiciones, guardas y acciones
19.1 Introducción
En el tema anterior vimos que un diagrama de estados permite representar el ciclo de vida de un objeto importante. Ahora profundizaremos en sus elementos principales: estados, eventos, transiciones, guardas y acciones. Estos elementos permiten describir con precisión cuándo un objeto cambia de situación y qué ocurre durante ese cambio.
Un diagrama de estados bien construido ayuda a evitar comportamientos ambiguos. Permite saber qué acciones son válidas en cada estado, qué eventos pueden ocurrir, qué condiciones deben cumplirse y qué cambios no están permitidos.
19.2 Estado
Un estado representa una situación significativa de un objeto. Durante ese estado, el objeto cumple ciertas condiciones y responde de una manera determinada ante eventos. El estado no debe nombrarse como una acción, sino como una condición o situación reconocible.
Por ejemplo, para un Pedido pueden existir estados como Creado, Pendiente de pago, Pagado, Enviado, Entregado y Cancelado. Para un Turno pueden existir Disponible, Reservado, Confirmado, Atendido y Cancelado.
19.3 Elementos de una transición de estado
Una transición puede incluir evento, guarda y acción. El evento dispara el cambio, la guarda condiciona si el cambio puede ocurrir y la acción indica qué se ejecuta durante la transición. Esta combinación permite representar reglas de comportamiento con precisión.
19.4 Evento
Un evento es algo que ocurre y puede provocar una transición. Puede originarse en un usuario, en otro sistema, en el paso del tiempo o en una condición detectada por el propio sistema. El evento responde a la pregunta: qué ocurrió para intentar cambiar de estado.
Ejemplos de eventos son: confirmar, cancelar, pagar, aprobar, rechazar, vencer plazo, recibir respuesta, iniciar sesión o cerrar sesión. El nombre debe ser claro y expresar el hecho que dispara el cambio.
19.5 Transición
Una transición es una flecha que conecta un estado origen con un estado destino. Indica que el objeto puede pasar de una situación a otra. No toda combinación de estados debe estar conectada; solo deben aparecer transiciones válidas según las reglas del sistema.
Por ejemplo, un Pedido puede pasar de Pendiente de pago a Pagado cuando se aprueba el pago. Pero probablemente no debería pasar directamente de Cancelado a Enviado, salvo que exista una regla explícita de reactivación.
19.6 Guarda
Una guarda es una condición que debe cumplirse para que una transición se ejecute. Se escribe entre corchetes junto a la transición. Si el evento ocurre pero la guarda no se cumple, el cambio de estado no debe realizarse.
Por ejemplo: cancelar [antes de la fecha del turno], enviar [pago aprobado] o aprobar [documentación completa]. Las guardas ayudan a representar reglas que dependen de condiciones específicas.
19.7 Acción
Una acción es una operación que se ejecuta como consecuencia de una transición o dentro de un estado. En una transición, suele escribirse después de una barra. Por ejemplo: cancelar [antes del turno] / liberarHorario().
La acción no debe confundirse con el estado. Cancelar puede ser un evento; Cancelado puede ser un estado; liberarHorario() puede ser una acción ejecutada durante la transición.
19.8 Notación completa de transición
Una transición puede expresarse con la forma general:
No siempre aparecen las tres partes. Puede existir una transición con solo evento, con evento y guarda, o con evento y acción. Lo importante es incluir la información que sea necesaria para comprender la regla.
19.9 Acciones de entrada
Una acción de entrada se ejecuta cada vez que el objeto entra en un estado. Suele indicarse con entry / acción. Es útil cuando algo debe ocurrir siempre al llegar a ese estado, sin importar desde qué transición se llegó.
Por ejemplo, al entrar en el estado Confirmado, un Turno puede ejecutar entry / enviarConfirmación(). Así no es necesario repetir esa acción en varias transiciones distintas.
19.10 Acciones de salida
Una acción de salida se ejecuta cuando el objeto abandona un estado. Suele indicarse con exit / acción. Puede usarse para registrar cambios, liberar recursos o ejecutar limpieza antes de pasar a otro estado.
Por ejemplo, al salir del estado Reservado, un Turno podría registrar el cambio en el historial. Estas acciones deben usarse cuando realmente ayudan a simplificar o aclarar el modelo.
19.11 Actividades internas
Un estado puede tener una actividad interna que se ejecuta mientras el objeto permanece en ese estado. Suele indicarse con do / actividad. Es útil para tareas que duran cierto tiempo.
Por ejemplo, un proceso de carga de archivo puede tener un estado Procesando con do / analizarArchivo(). Cuando termina el procesamiento, puede ocurrir una transición hacia Procesado o Error.
19.12 Eventos temporales
Algunos eventos dependen del tiempo. UML permite representar eventos como after(24 horas) o at(fechaVencimiento). Son útiles para vencimientos, expiraciones, recordatorios y tiempos máximos de espera.
Por ejemplo, una Reserva puede pasar de Pendiente de pago a Vencida después de cierto plazo si no se registra el pago.
19.13 Eventos de cambio
Un evento de cambio ocurre cuando una condición se vuelve verdadera. Puede expresarse con una condición como when(stock = 0). Es útil cuando el cambio de estado depende de la variación de una condición observada.
Este recurso debe usarse con cuidado para que el diagrama no se vuelva demasiado técnico o difícil de leer.
19.14 Transiciones automáticas
Una transición automática, o sin evento explícito, ocurre cuando se completa una actividad o se cumple una condición suficiente para avanzar. Puede aparecer sin etiqueta o con una guarda.
Por ejemplo, después de terminar una validación, una solicitud puede pasar automáticamente a Aprobada o Rechazada según el resultado. Si hay condiciones alternativas, las guardas ayudan a aclarar el camino.
19.15 Estados compuestos
Un estado compuesto contiene subestados. Se usa cuando un estado general tiene comportamiento interno relevante. Por ejemplo, el estado En proceso puede tener subestados Validando, Procesando pago y Generando comprobante.
Los estados compuestos ayudan a organizar diagramas complejos, pero no deben usarse si solo agregan detalle innecesario.
19.16 Estados concurrentes
Algunos objetos pueden tener regiones concurrentes, donde varias partes de su estado evolucionan en paralelo. Por ejemplo, un pedido puede tener un estado de pago y un estado de preparación que avanzan de manera parcialmente independiente.
Este recurso es más avanzado. Conviene usarlo solo cuando el paralelismo de estados es importante para comprender el comportamiento.
19.17 Ejemplo: turno médico
Un Turno puede pasar de Reservado a Confirmado con el evento confirmar. Puede pasar de Reservado a Cancelado con el evento cancelar y la guarda [antes de la fecha del turno]. Durante esa transición puede ejecutarse la acción liberarHorario().
Si el turno llega a la fecha programada y se registra la atención, puede pasar a Atendido. Si el paciente no asiste, puede pasar a Ausente. Cada transición representa una regla que el sistema debe respetar.
19.18 Ejemplo: pago
Un Pago puede comenzar como Iniciado. Luego puede pasar a Pendiente de autorización. Si la pasarela confirma la operación, pasa a Aprobado. Si la rechaza, pasa a Rechazado. Si no responde dentro del plazo, puede pasar a Vencido o Error.
Este modelo permite identificar eventos externos, guardas y acciones asociadas, como registrar comprobante, notificar rechazo o liberar una reserva.
19.19 Criterios de revisión
- ¿Los estados representan situaciones y no acciones?
- ¿Cada transición tiene sentido según las reglas del sistema?
- ¿Los eventos están nombrados con claridad?
- ¿Las guardas son condiciones verificables?
- ¿Las acciones están ubicadas en la transición o estado correcto?
- ¿Se evitan transiciones inválidas?
- ¿El diagrama mantiene un nivel de detalle comprensible?
19.20 Errores frecuentes
- Nombrar estados con verbos, como Cancelar, Pagar o Enviar.
- Confundir evento con estado.
- Agregar transiciones entre todos los estados posibles sin regla real.
- Escribir guardas ambiguas o imposibles de verificar.
- Ubicar acciones importantes en lugares incorrectos.
- Omitir eventos temporales cuando los plazos son parte del comportamiento.
- Usar estados compuestos cuando el diagrama simple sería suficiente.
19.21 Qué debes recordar de este tema
- Un estado describe una situación significativa del objeto.
- Un evento puede disparar una transición.
- Una transición representa un cambio válido entre estados.
- Una guarda condiciona si la transición puede ocurrir.
- Una acción representa algo que se ejecuta durante una transición o dentro de un estado.
- La forma general de una transición es
evento [guarda] / acción.
19.22 Conclusión
Estados, eventos, transiciones, guardas y acciones permiten describir con precisión el comportamiento de objetos cuyo ciclo de vida es importante. Estos elementos ayudan a transformar reglas dispersas en un modelo visual que facilita análisis, diseño, validación y pruebas.
En el próximo tema veremos diagramas de componentes, orientados a módulos, interfaces y dependencias de software.