22. Flujo principal de eventos paso a paso
22.1 Introducción
El flujo principal de eventos describe el camino normal que sigue un caso de uso cuando todo ocurre según lo esperado. Es la secuencia básica de interacción entre el actor principal y el sistema para lograr el objetivo.
Este flujo es una de las partes más importantes de la especificación textual. Permite entender qué solicita el actor, qué responde el sistema, qué datos se intercambian y cómo se alcanza el resultado final.
Un buen flujo principal debe ser claro, ordenado, verificable y estar enfocado en comportamiento observable, no en detalles internos de programación.
22.2 Qué representa el flujo principal
El flujo principal representa el escenario exitoso más común. No significa que sea el único camino posible, sino el recorrido base a partir del cual luego se documentan variantes, alternativas y excepciones.
En Solicitar turno, el flujo principal podría comenzar con el paciente solicitando un turno, continuar con la búsqueda de disponibilidad y terminar con la reserva confirmada.
22.3 Alternancia entre actor y sistema
Una forma clara de redactar el flujo principal es alternar acciones del actor y respuestas del sistema. El actor inicia o aporta información; el sistema valida, muestra, registra o responde. Esta alternancia ayuda a distinguir responsabilidades.
22.4 Pasos numerados
El flujo principal suele redactarse como una lista numerada. Cada paso debe describir una acción relevante y mantener un orden lógico.
Ejemplo básico:
2. El sistema muestra las especialidades disponibles.
3. El paciente selecciona una especialidad y una fecha aproximada.
4. El sistema muestra los horarios disponibles.
5. El paciente selecciona un horario.
6. El sistema registra la reserva y muestra la confirmación.
22.5 Redactar desde comportamiento observable
Los pasos deben describir comportamiento visible o verificable. No conviene escribir detalles internos como "el sistema ejecuta una consulta SQL", "se instancia el controlador" o "se actualiza una variable".
En lugar de eso, se escribe lo que importa para la interacción: el sistema muestra horarios disponibles, valida disponibilidad, registra la reserva o informa que no hay turnos.
22.6 Mantener un nivel de detalle adecuado
El flujo no debe ser tan general que no explique nada, ni tan detallado que describa cada clic y cada campo de interfaz. Debe incluir los pasos necesarios para comprender el comportamiento funcional.
Por ejemplo, "el paciente completa todos los datos y el sistema procesa la solicitud" es demasiado general. En cambio, listar cada movimiento del mouse es demasiado detallado. El equilibrio está en describir decisiones, datos relevantes y respuestas del sistema.
22.7 Actor primero, sistema después
En muchos casos, conviene iniciar el flujo con una acción del actor principal. Esto deja claro quién impulsa el objetivo. Luego el sistema responde o solicita información adicional.
Ejemplo:
- El paciente solicita reservar un turno.
- El sistema muestra criterios de búsqueda disponibles.
- El paciente indica especialidad y fecha.
- El sistema muestra opciones compatibles.
22.8 Evitar condiciones dentro del flujo principal
El flujo principal debe describir el camino normal. Si aparece una condición como "si no hay horarios disponibles", probablemente corresponde a un flujo alternativo o excepción.
No se trata de ocultar los problemas, sino de separar el camino base de las variantes. Esa separación mejora la lectura.
22.9 Ejemplo completo: Solicitar turno
Un flujo principal más completo para Solicitar turno podría ser:
2. El sistema muestra las especialidades disponibles.
3. El paciente selecciona una especialidad.
4. El sistema muestra los profesionales que atienden esa especialidad.
5. El paciente selecciona un profesional y una fecha aproximada.
6. El sistema muestra los horarios disponibles.
7. El paciente selecciona un horario.
8. El sistema muestra el resumen de la reserva.
9. El paciente confirma la solicitud.
10. El sistema registra el turno y muestra la confirmación.
22.10 Relación con precondiciones y postcondiciones
El flujo principal debe respetar las precondiciones y conducir a las postcondiciones de éxito. Si la precondición dice que el paciente está registrado, el flujo no necesita explicar cómo se registra. Si la postcondición dice que el turno queda reservado, el flujo debe incluir el paso donde el sistema registra esa reserva.
22.11 Relación con flujos alternativos
Los flujos alternativos se apoyan en el flujo principal. Por ejemplo, si en el paso 6 no hay horarios disponibles, se puede documentar un flujo alternativo que indique cómo responde el sistema y qué opciones tiene el paciente.
Por eso es útil numerar bien los pasos: las alternativas pueden referirse a un punto específico del flujo principal.
22.12 Tabla de responsabilidades
Separar responsabilidades ayuda a detectar pasos confusos:
| Responsabilidad del actor | Responsabilidad del sistema |
|---|---|
| Solicitar iniciar el caso de uso. | Presentar opciones disponibles. |
| Ingresar o seleccionar datos relevantes. | Validar datos y reglas de negocio. |
| Confirmar una decisión. | Registrar el resultado. |
| Recibir información para continuar. | Mostrar mensajes, comprobantes o confirmaciones. |
22.13 Redacción en voz activa
Conviene escribir los pasos en voz activa, indicando claramente quién realiza cada acción. En lugar de "se confirma el turno", es mejor escribir "El paciente confirma el turno" o "El sistema confirma la reserva", según corresponda.
La voz activa reduce ambigüedad y facilita la revisión con usuarios y equipo técnico.
22.14 Evitar mezclar varias acciones en un paso
Un paso no debería contener demasiadas acciones importantes. Si un paso dice "el sistema valida, registra, envía correo y actualiza la agenda", quizá convenga dividirlo.
Separar acciones relevantes permite detectar errores, alternativas y pruebas con mayor claridad.
22.15 Flujo principal y pruebas
El flujo principal se convierte naturalmente en una prueba de camino exitoso. La prueba debe recorrer los pasos normales y verificar que se llegue a la postcondición esperada.
Si el flujo principal no puede probarse, probablemente está incompleto, ambiguo o mezclado con detalles que no corresponden.
22.16 Errores frecuentes
Al redactar el flujo principal, suelen aparecer estos errores:
- Describir pantallas en lugar de interacción.
- Escribir pasos demasiado generales.
- Incluir detalles técnicos internos.
- Mezclar flujo principal con alternativas y excepciones.
- No indicar claramente si actúa el actor o el sistema.
- Incluir muchas acciones importantes en un solo paso.
- No conducir a una postcondición verificable.
22.17 Lista de revisión
Antes de cerrar el flujo principal, conviene revisar:
- ¿El flujo permite lograr el objetivo del actor?
- ¿Los pasos están numerados en orden lógico?
- ¿Cada paso indica quién actúa?
- ¿El nivel de detalle es suficiente?
- ¿Se evitaron detalles técnicos innecesarios?
- ¿Las condiciones especiales quedaron fuera del flujo principal?
- ¿El final conduce a la postcondición de éxito?
22.18 Qué debes recordar de este tema
- El flujo principal describe el camino normal y exitoso del caso de uso.
- Debe redactarse paso a paso, con acciones claras del actor y del sistema.
- No debe incluir detalles internos de implementación.
- Las alternativas y excepciones se documentan por separado.
- El flujo debe respetar precondiciones y llegar a postcondiciones verificables.
- La numeración facilita referenciar variantes.
- Un buen flujo principal sirve como base para pruebas de aceptación.
22.19 Conclusión
El flujo principal es el corazón de la especificación textual. Describe cómo el actor y el sistema colaboran para alcanzar el objetivo en el escenario normal.
Cuando está bien redactado, permite entender la funcionalidad, validar el comportamiento esperado y preparar pruebas. En el próximo tema estudiaremos los flujos alternativos y las decisiones del usuario.