Siempre que sea posible, debemos evitar secuencias de pasos como:
n. El sistema hace…
n+1. El sistema hace…
O
m. El actor hace…
m+1. El actor hace…
Donde n y m son números de pasos de una secuencia cualquiera del caso de uso. Es decir, ni el sistema ni el actor ejecutan dos pasos seguidos en el caso de uso. La escritura de casos de uso debe (ría) obedecer al siguiente patrón de diálogo:
p. El sistema hace…
p+1. El actor hace…
Donde “hace” se debe reemplazar por la acción que uno y otro ente realizan. Normalmente, el sistema “solicita” el ingreso o selección de datos y el actor “proporciona” datos, ya sea ingresándolos (por medio del teclado, en cuyo caso “digita” los datos) o seleccionando uno o más datos disponibles de una lista suministrada por el sistema. Nunca se debe especificar el mecanismo programático (formularios, ventanas, cuadros de texto, listas combinadas, cuadros de chequeo, botones de comando, entre otros) utilizado para crear y mostrar la lista. Ejecutar.
Además, nuestros usuarios siempre esperan que los sorprendamos con algo novedoso y una forma mejor de hacer las cosas. En el futuro cercano, por ejemplo, esperarían no tener que lidiar con la clásica interfaz gráfica de hoy sino con hologramas u otra suerte de mecanismos de comunicación Humano-Máquina. Pero ese es otro asunto.
Volviendo al consejo práctico que nos ocupa, normalmente cuando ocurre que debemos especificar varias actividades seguidas de un actor o del sistema, nos encontramos ante una de estas situaciones: estamos haciendo descomposición funcional que, en principio, es innecesaria. Recordemos que lo esencial en un caso de uso es especificar lo que hace el sistema que es relevante para el negocio o para ese actor en particular. Por ejemplo, para un actor es significativo que el sistema busque y muestre los datos de una factura o le indique que no la encontró, pero no es importante si esa búsqueda ocurre mediante un método secuencial, uno binario, la técnica de Fibonacci o un algoritmo genético, o si usa el mismo método de google para encontrar páginas en Internet.
También puede ocurrir que estamos especificando una funcionalidad del sistema que es posible documentar mejor con otros mecanismos como diagramas de actividad o estado o, si es necesario documentación textual, con requisitos escritos a la usanza tradicional de: “el sistema debe hacer algo…”. También se pueden usar escenarios, tableros de historias (storyboards), prototipos o simuladores, o una combinación de dos o más de estos artilugios.
Ejemplo
El siguiente caso de uso para reservar sillas en un viaje por avión nos ilustra muy bien esta sugerencia:
Caso de Uso: Reservar tiquetes
Actor: Cliente (Aerolínea)
Secuencia Básica:
1. El caso de uso inicia cuando el Cliente decide reservar tiquetes aéreos
2. El sistema solicita seleccionar la ciudad origen
3. El Cliente selecciona la ciudad origen
4. El sistema solicita seleccionar la ciudad destino
5. El Cliente selecciona la ciudad destino
6. El sistema solicita la fecha de ida
7. El cliente ingresa la fecha de ida
8. El Sistema solicita la fecha de regreso
9. El Cliente ingresa la fecha de regreso
10. El sistema solicita el número de pasajeros
11. El cliente ingresa el número de pasajeros
12. El sistema verifica que hay disponibilidad de vuelos entre las ciudades y fechas solicitadas
13. El sistema verifica que hay disponibilidad de asientos para el número de pasajeros establecidos
14. El sistema muestra el mensaje “Sí hay disponibilidad de vuelos entre las ciudades y fechas establecidas”
15. El sistema genera un número de reserva
16. El sistema almacena la información de la reserva
17. El caso de uso termina
Aquí caímos en la típica descomposición funcional que se debe evitar durante la etapa de requisitos. Los pasos 12 a 17 bien pueden reemplazarse por:
12. El sistema verifica que hay asientos disponibles y muestra el número de reserva.
13. El caso de uso termina
¿Y qué se hicieron las otras especificaciones? ¿Será que los programadores son capaces de inferirla? No. Estos otros detalles pueden documentarse como requisitos especiales en el caso de uso o como elementos de diseño (por ejemplo, estableciendo en un diagrama de secuencia cuáles son las entidades de almacenamiento de información o el algoritmo para generar el número de la reserva). Nótese que estos aspectos no son relevantes para el negocio.
