20. Precondiciones y disparadores
20.1 Introducción
En una especificación de caso de uso, las precondiciones y los disparadores ayudan a definir cuándo puede comenzar la interacción. Aunque están relacionados con el inicio del caso de uso, no significan lo mismo.
Una precondición indica qué debe ser verdadero antes de iniciar. Un disparador indica qué evento pone en marcha el caso de uso. Distinguirlos evita ambigüedades y permite escribir flujos más claros.
Por ejemplo, para Solicitar turno, una precondición puede ser que el paciente esté registrado. El disparador puede ser que el paciente seleccione la opción de solicitar un nuevo turno.
20.2 Qué es una precondición
Una precondición es una condición que debe cumplirse antes de que el caso de uso pueda comenzar correctamente. No es un paso del flujo, sino un estado previo que se asume verdadero.
Si la precondición no se cumple, el caso de uso no debería iniciar como está especificado, o debería ejecutarse otro caso de uso previo para preparar el contexto.
20.3 Qué es un disparador
Un disparador es el evento que inicia el caso de uso. Puede ser una acción del actor, una señal de un sistema externo, una fecha programada, una condición del entorno o una decisión automática.
El disparador no describe todo el flujo; solo indica qué hecho hace que el caso de uso comience.
20.4 Diferencia entre precondición y disparador
La precondición describe el estado necesario antes de comenzar. El disparador describe el evento que inicia la interacción. En Solicitar turno, que el paciente esté registrado puede ser una precondición; que el paciente elija solicitar un turno puede ser el disparador.
20.5 Ejemplos de precondiciones
Algunos ejemplos de precondiciones son:
- El paciente está registrado en el sistema.
- El usuario inició sesión correctamente.
- El profesional médico tiene una agenda configurada.
- El pedido existe y está pendiente de pago.
- La cuenta bancaria está activa.
- El producto se encuentra publicado en el catálogo.
Estas condiciones describen un estado previo, no una acción que ocurre dentro del flujo principal.
20.6 Ejemplos de disparadores
Algunos ejemplos de disparadores son:
- El paciente selecciona la opción Solicitar turno.
- El administrador elige Registrar profesional.
- El sistema recibe una confirmación de pago externa.
- Llega la fecha programada para enviar recordatorios.
- Un sensor informa una medición fuera de rango.
- El cliente solicita descargar un comprobante.
El disparador indica el hecho que inicia el caso de uso.
20.7 Precondición no es validación del flujo
Un error frecuente es escribir como precondición algo que el sistema debe verificar durante el flujo. Si el sistema debe pedir un dato y validarlo, eso suele formar parte del flujo principal o de una excepción.
Por ejemplo, en Solicitar turno, "el horario seleccionado está disponible" no debería ser precondición si el sistema lo determina durante la búsqueda. Puede ser una validación dentro del flujo.
20.8 Precondición no es objetivo
La precondición tampoco debe confundirse con el objetivo del caso de uso. "El paciente obtiene un turno reservado" no es una precondición; es un resultado esperado o postcondición.
La precondición se ubica antes del inicio. El objetivo se alcanza al finalizar correctamente.
20.9 Disparadores iniciados por actores
El disparador más común es una acción del actor principal. Por ejemplo, el Paciente selecciona Solicitar turno o la Recepcionista elige Registrar turno presencial.
En estos casos, el disparador suele estar muy relacionado con la intención del actor. Aun así, conviene escribirlo de forma concreta para que el inicio del flujo quede claro.
20.10 Disparadores automáticos
No todos los casos de uso comienzan por una acción humana directa. Algunos se inician automáticamente por tiempo, eventos externos o condiciones del sistema.
Ejemplos:
- Cada día a las 18:00, el sistema inicia Enviar recordatorios de turno.
- Al recibir una respuesta de la pasarela de pago, el sistema inicia Confirmar pago.
- Cuando un sensor informa una temperatura crítica, el sistema inicia Registrar alerta.
20.11 Ejemplo completo: Solicitar turno
Para el caso de uso Solicitar turno, podríamos documentar:
- El paciente está registrado en el sistema.
- Existe al menos una agenda médica configurada.
Disparador:
- El paciente selecciona la opción de solicitar un nuevo turno.
Esta redacción separa claramente el estado previo del evento que inicia la interacción.
20.12 Ejemplo completo: Enviar recordatorio
Para el caso de uso Enviar recordatorio de turno, podríamos documentar:
- Existen turnos confirmados para el día siguiente.
- Los pacientes aceptaron recibir recordatorios.
Disparador:
- Llega la hora programada para ejecutar el envío diario de recordatorios.
En este ejemplo, el disparador no es una acción del paciente, sino un evento temporal.
20.13 Tabla comparativa
La siguiente tabla resume la diferencia:
| Elemento | Pregunta que responde | Ejemplo |
|---|---|---|
| Precondición | ¿Qué debe ser verdadero antes de iniciar? | El paciente está registrado. |
| Disparador | ¿Qué evento inicia el caso de uso? | El paciente selecciona Solicitar turno. |
| Flujo principal | ¿Qué ocurre después de iniciado? | El sistema muestra horarios disponibles. |
| Postcondición | ¿Qué queda verdadero al finalizar? | El turno queda reservado. |
20.14 Cómo redactar precondiciones
Para redactar buenas precondiciones, conviene:
- Escribirlas como estados verificables.
- Evitar acciones que pertenezcan al flujo.
- No incluir resultados finales.
- No escribir condiciones obvias que no aportan valor.
- Revisar si dependen de otro caso de uso previo.
- Usar lenguaje claro y no técnico cuando sea posible.
20.15 Cómo redactar disparadores
Para redactar buenos disparadores, conviene:
- Identificar el evento concreto que inicia el caso de uso.
- Indicar si lo provoca un actor, un sistema externo, el tiempo o una condición.
- No mezclar el disparador con todo el flujo principal.
- Evitar frases vagas como "cuando sea necesario".
- Usar una redacción breve y directa.
20.16 Errores frecuentes
Al documentar precondiciones y disparadores, suelen aparecer estos errores:
- Confundir precondición con primer paso del flujo.
- Confundir precondición con resultado final.
- Escribir disparadores demasiado vagos.
- Omitir disparadores automáticos o externos.
- Incluir validaciones internas como precondiciones.
- Agregar precondiciones innecesarias que no ayudan a comprender el caso.
- No revisar qué ocurre si una precondición no se cumple.
20.17 Qué debes recordar de este tema
- Una precondición es un estado que debe cumplirse antes de iniciar.
- Un disparador es el evento que inicia el caso de uso.
- La precondición no debe confundirse con una validación del flujo.
- El disparador puede venir de un actor, un sistema externo, el tiempo o una condición.
- Las precondiciones deben ser verificables.
- Los disparadores deben ser concretos.
- Distinguir ambos elementos mejora la claridad de la especificación.
20.18 Conclusión
Las precondiciones y los disparadores permiten definir con precisión el inicio de un caso de uso. Las precondiciones explican qué debe estar preparado; el disparador explica qué evento pone en marcha la interacción.
Separar correctamente estos conceptos ayuda a escribir flujos más claros, detectar dependencias previas y preparar mejores pruebas. En el próximo tema estudiaremos postcondiciones y resultados observables.