24. Excepciones, errores y recuperación
24.1 Introducción
Los casos de uso no deben describir solamente el camino ideal. En los sistemas reales aparecen errores, datos inválidos, servicios externos que no responden, permisos insuficientes, reglas incumplidas y operaciones interrumpidas.
Las excepciones documentan estas situaciones problemáticas y explican cómo debe responder el sistema. Su objetivo es evitar que el comportamiento ante fallos quede librado a la improvisación.
Una buena especificación indica qué ocurre, qué informa el sistema, si se puede recuperar la operación y qué estado final debe quedar protegido.
24.2 Qué es una excepción
Una excepción es una situación que impide continuar normalmente el flujo principal o un flujo alternativo. Puede originarse por un error del usuario, una condición del negocio, una falla técnica, un dato inválido o una dependencia externa.
Por ejemplo, en Solicitar turno, una excepción ocurre si el horario seleccionado fue reservado por otra persona antes de confirmar. El sistema no puede continuar como si el horario siguiera disponible.
24.3 Diferencia entre alternativa y excepción
Un flujo alternativo es una variante válida. Una excepción representa un problema, una interrupción o una condición que impide completar el camino normal.
Ejemplo de alternativa: el paciente busca turnos por profesional. Ejemplo de excepción: el sistema no puede confirmar el turno porque el horario ya no está disponible.
24.4 Interrupción y recuperación
Cuando aparece una excepción, el sistema debe responder de forma controlada. Puede informar el problema, ofrecer una recuperación, volver a un paso anterior, cancelar la operación o dejar constancia de lo ocurrido. Lo importante es que el sistema no quede en un estado incoherente.
24.5 Tipos de excepciones
Las excepciones pueden clasificarse de distintas maneras:
- Errores de validación: datos incompletos, formato incorrecto o valores no permitidos.
- Reglas de negocio incumplidas: operación fuera de plazo, cupo agotado o permiso insuficiente.
- Conflictos de concurrencia: otro usuario modifica o reserva el mismo recurso.
- Fallas de integración: un sistema externo no responde o devuelve rechazo.
- Errores técnicos: fallas de comunicación, almacenamiento o disponibilidad del servicio.
- Cancelación del usuario: el actor decide interrumpir antes de confirmar.
24.6 Estructura recomendada
Una excepción puede documentarse con esta estructura:
Punto de origen: paso del flujo donde puede ocurrir.
Condición: qué problema se detecta.
Respuesta del sistema: qué informa o realiza el sistema.
Recuperación o resultado: cómo continúa o cómo finaliza el caso de uso.
24.7 Ejemplo: horario no disponible
En Solicitar turno, puede ocurrir que otro paciente reserve el mismo horario segundos antes. La excepción podría documentarse así:
Punto de origen: paso donde el paciente confirma la reserva.
Condición: el horario seleccionado ya fue reservado por otro usuario.
Respuesta del sistema: informa que el horario ya no está disponible.
Recuperación: el sistema muestra nuevamente horarios disponibles para que el paciente seleccione otra opción.
24.8 Ejemplo: paciente no registrado
Si la precondición indica que el paciente debe estar registrado, pero el sistema detecta que no existe una cuenta válida, puede ejecutarse una excepción o redirigirse a otro caso de uso.
Condición: el sistema no encuentra un paciente registrado con los datos ingresados.
Respuesta del sistema: informa que se requiere registro previo.
Recuperación: ofrece iniciar el caso de uso Registrar paciente.
24.9 Ejemplo: servicio externo no responde
Cuando un caso de uso depende de un sistema externo, hay que documentar qué ocurre si ese sistema no responde.
Condición: el sistema de la obra social no responde durante la validación.
Respuesta del sistema: informa que no se pudo validar la cobertura en ese momento.
Recuperación: permite continuar como pendiente de validación o cancelar la solicitud, según regla de negocio.
24.10 Recuperación
La recuperación define cómo puede continuar el caso de uso después del problema. No todas las excepciones permiten recuperación, pero cuando sea posible debe quedar explicado.
Opciones comunes:
- Volver a un paso anterior.
- Solicitar corrección de datos.
- Ofrecer una opción alternativa.
- Registrar estado pendiente.
- Cancelar la operación sin cambios.
- Derivar a otro caso de uso.
24.11 Garantía mínima ante errores
Una excepción debe respetar la garantía mínima del caso de uso. Si la operación no se completa, el sistema debe evitar registros incompletos, duplicaciones, datos inconsistentes o cambios no autorizados.
Por ejemplo, si falla la confirmación de un turno, no debería quedar un turno reservado a medias ni bloquearse un horario sin motivo.
24.12 Mensajes de error
Los mensajes de error deben ser claros para el actor. No conviene mostrar mensajes técnicos como "Error 500" o "Null reference" si el usuario necesita saber qué hacer.
Un mensaje útil informa el problema y, si corresponde, ofrece una acción posible:
24.13 Excepciones y pruebas
Cada excepción importante debe tener pruebas. No basta con probar el flujo principal. Si el sistema debe manejar falta de disponibilidad, datos inválidos o fallas externas, esas situaciones deben verificarse.
Las pruebas de excepciones ayudan a evitar errores graves en producción, especialmente cuando afectan datos, pagos, reservas, permisos o integraciones.
24.14 Tabla de excepciones comunes
Algunas excepciones habituales son:
| Tipo | Ejemplo | Respuesta esperada |
|---|---|---|
| Validación | Documento con formato inválido. | Solicitar corrección del dato. |
| Negocio | Cancelación fuera de plazo. | Informar restricción y no cancelar automáticamente. |
| Concurrencia | Horario reservado por otro usuario. | Mostrar nuevas opciones disponibles. |
| Integración | Servicio externo no responde. | Informar situación y registrar pendiente si corresponde. |
| Permisos | Usuario no autorizado. | Bloquear operación y mostrar mensaje adecuado. |
24.15 Errores frecuentes
Al documentar excepciones, suelen aparecer estos errores:
- Describir solo el flujo ideal.
- Confundir excepciones con flujos alternativos normales.
- No indicar en qué paso puede ocurrir la excepción.
- No explicar la respuesta del sistema.
- No definir recuperación o estado final.
- Olvidar fallas de sistemas externos.
- No derivar pruebas para las excepciones importantes.
24.16 Lista de revisión
Antes de cerrar las excepciones, conviene revisar:
- ¿Se consideraron errores de validación?
- ¿Se consideraron reglas de negocio incumplidas?
- ¿Se consideraron fallas de sistemas externos?
- ¿Cada excepción indica punto de origen?
- ¿La respuesta del sistema es clara?
- ¿La recuperación o finalización está definida?
- ¿Se protege la consistencia del sistema?
- ¿Existen pruebas para las excepciones relevantes?
24.17 Qué debes recordar de este tema
- Las excepciones describen situaciones problemáticas o de interrupción.
- Deben indicar condición, punto de origen, respuesta y recuperación.
- No son lo mismo que flujos alternativos válidos.
- La recuperación puede volver a un paso anterior, cancelar o derivar a otro caso de uso.
- El sistema debe proteger su consistencia ante errores.
- Los mensajes deben ser comprensibles para el actor.
- Las excepciones importantes deben probarse.
24.18 Conclusión
Las excepciones permiten diseñar el comportamiento del sistema ante problemas reales. Sin ellas, la especificación queda incompleta y el sistema puede fallar de forma impredecible ante situaciones comunes.
Documentar errores y recuperación mejora la calidad del producto, protege los datos y facilita las pruebas. En el próximo tema estudiaremos las reglas de negocio dentro de los casos de uso.