21. Postcondiciones y resultados observables
21.1 Introducción
Las postcondiciones describen qué debe ser verdadero cuando un caso de uso termina. Ayudan a precisar el resultado esperado y a verificar si el objetivo fue cumplido correctamente.
Un caso de uso no debería terminar con una frase vaga como "el sistema finaliza el proceso". Debe quedar claro qué cambió, qué se registró, qué se informó o qué estado quedó establecido.
Los resultados observables son efectos que pueden comprobarse desde el sistema, por el actor o por una prueba. Son fundamentales para validar requisitos y diseñar casos de prueba.
21.2 Qué es una postcondición
Una postcondición es una afirmación sobre el estado del sistema después de finalizar el caso de uso. Describe una condición que debe cumplirse si el caso de uso terminó correctamente.
Por ejemplo, en Solicitar turno, una postcondición puede ser:
Esta frase permite verificar si el resultado esperado realmente se produjo.
21.3 Qué es un resultado observable
Un resultado observable es un efecto que puede comprobarse. Puede ser un dato registrado, un estado actualizado, una notificación enviada, un comprobante generado, una pantalla de confirmación o una restricción aplicada.
Si nadie puede observar o verificar el resultado, la postcondición probablemente está redactada de manera demasiado abstracta.
21.4 Estado antes y después del caso de uso
Las postcondiciones muestran la diferencia entre el estado previo y el estado final. En el ejemplo, antes de Solicitar turno existe un horario disponible; después de completar el caso de uso, ese horario queda reservado para el paciente y ya no puede ser seleccionado por otra persona.
21.5 Postcondición de éxito
La postcondición de éxito describe el estado esperado cuando el caso de uso se completa correctamente. Debe estar alineada con el objetivo del actor principal y con la garantía de éxito.
Ejemplos:
- El turno queda reservado y asociado al paciente.
- El pedido queda registrado con estado pendiente de pago.
- El comprobante queda generado y disponible para descarga.
- La agenda del médico queda actualizada.
- La solicitud queda enviada para aprobación.
21.6 Postcondición ante fallo
Algunas especificaciones también documentan qué debe quedar garantizado si el caso de uso no termina con éxito. Esto se relaciona con la garantía mínima.
Ejemplo:
Esto es importante porque un caso de uso fallido no debería dejar datos inconsistentes.
21.7 Diferencia con precondiciones
Las precondiciones se cumplen antes de iniciar. Las postcondiciones se cumplen después de finalizar. Confundirlas puede desordenar la especificación.
| Elemento | Momento | Ejemplo |
|---|---|---|
| Precondición | Antes de iniciar | El paciente está registrado. |
| Postcondición | Después de finalizar | El turno queda reservado. |
21.8 Diferencia con flujo principal
El flujo principal describe los pasos que ocurren durante el caso de uso. La postcondición resume el estado final después de esos pasos.
Por ejemplo, el flujo puede decir que el paciente selecciona un horario y el sistema registra la reserva. La postcondición dirá que el turno quedó reservado y el horario ya no está disponible.
21.9 Cómo redactar postcondiciones
Para redactar buenas postcondiciones, conviene:
- Escribirlas como estados verificables.
- Indicar qué datos, estados o registros cambiaron.
- Evitar frases vagas como "el proceso fue exitoso".
- No repetir todos los pasos del flujo principal.
- Relacionarlas con el objetivo del actor.
- Revisar que puedan convertirse en pruebas.
21.10 Ejemplo completo: Solicitar turno
Para el caso de uso Solicitar turno, se podrían documentar estas postcondiciones:
- El turno queda reservado para el paciente.
- El horario reservado deja de estar disponible para otros pacientes.
- El sistema genera una confirmación de la reserva.
Postcondición si no se completa:
- No se registra una reserva incompleta.
- La disponibilidad de horarios no se modifica indebidamente.
21.11 Ejemplo: Cancelar turno
Para el caso de uso Cancelar turno, las postcondiciones podrían ser:
- El turno queda marcado como cancelado.
- El horario puede volver a quedar disponible según la regla de negocio.
- El paciente recibe una confirmación de cancelación.
- La agenda del profesional se actualiza.
Estas postcondiciones permiten verificar que la cancelación tuvo efectos concretos.
21.12 Resultados visibles para el actor
No todos los resultados observables son internos. Algunos deben ser visibles para el actor. Por ejemplo, el paciente necesita ver una confirmación, un número de reserva o un mensaje claro de cancelación.
Si el sistema registra datos correctamente pero no informa al actor, el caso de uso puede quedar incompleto desde el punto de vista de la experiencia del usuario.
21.13 Resultados internos del sistema
Otros resultados son internos, pero igualmente verificables. Por ejemplo, actualizar el estado de un turno, bloquear un horario, registrar una auditoría o cambiar el estado de un pedido.
Estos resultados pueden no ser visibles directamente para el usuario final, pero son importantes para la consistencia del sistema y para las pruebas.
21.14 Resultados hacia sistemas externos
Un caso de uso también puede producir resultados hacia otros sistemas. Por ejemplo, enviar una confirmación a un servicio de mensajería, informar una operación al sistema contable o notificar a una pasarela de pago.
Si el resultado externo es importante, debe quedar documentado en la postcondición o en las garantías del caso de uso.
21.15 Postcondiciones y pruebas
Las postcondiciones son una excelente base para pruebas. Cada postcondición puede transformarse en una verificación.
Ejemplo:
| Postcondición | Verificación posible |
|---|---|
| El turno queda reservado para el paciente. | Consultar la reserva y verificar paciente, fecha, profesional y horario. |
| El horario deja de estar disponible. | Buscar disponibilidad y confirmar que ese horario no aparece. |
| El paciente recibe confirmación. | Verificar mensaje, correo o comprobante generado. |
21.16 Errores frecuentes
Al redactar postcondiciones, suelen aparecer estos errores:
- Escribir resultados vagos, como "todo queda correcto".
- Confundir postcondiciones con pasos del flujo.
- Confundir postcondiciones con precondiciones.
- No indicar qué datos o estados cambian.
- Olvidar resultados visibles para el actor.
- No considerar qué debe ocurrir si el caso de uso falla.
- Redactar condiciones imposibles de verificar.
21.17 Lista de revisión
Antes de cerrar las postcondiciones, conviene revisar:
- ¿Describen el estado final del sistema?
- ¿Son verificables?
- ¿Están alineadas con el objetivo del actor?
- ¿Indican resultados visibles cuando corresponde?
- ¿Consideran datos, estados o notificaciones relevantes?
- ¿Pueden transformarse en pruebas?
- ¿Evitan repetir todos los pasos del flujo?
21.18 Qué debes recordar de este tema
- Las postcondiciones describen qué debe ser verdadero al finalizar.
- Los resultados observables son efectos que pueden comprobarse.
- La postcondición de éxito debe alinearse con el objetivo del caso de uso.
- También puede documentarse qué se garantiza si el caso falla.
- Una buena postcondición evita frases vagas.
- Las postcondiciones ayudan a diseñar pruebas.
- El resultado final debe ser claro para el sistema, el actor o ambos.
21.19 Conclusión
Las postcondiciones permiten cerrar el caso de uso con precisión. Indican qué debe quedar establecido cuando la interacción termina y ayudan a verificar que el objetivo fue cumplido.
Redactarlas bien mejora la calidad de la especificación, facilita las pruebas y evita interpretaciones ambiguas sobre el resultado esperado. En el próximo tema estudiaremos el flujo principal de eventos paso a paso.