Diagramas de casos de uso
Los casos de uso son una herramienta esencial en la toma de requisitos del sistema. Nos permiten expresar gráficamente las relaciones entre los diferentes usos del mismo y sus participantes o actores. El resultado es un conjunto de diagramas muy fácilmente entendibles tanto por el cliente, como por los analistas del proyecto.
No definen todos los requisitos (por ejemplo, tipos de datos, interfaces externas, rendimiento, etc.) pero sí que representan el hilo conductor que los vincula a todos con los actores del sistema.
Se componen de los siguientes elementos:
- Actores: representan los roles que juegan los usuarios u otros sistemas en el sistema del problema. Identificar a los actores de un caso de uso pasa por averiguar quién está involucrado en cada requisito concreto, quién se beneficiará de cada funcionalidad o
quién proveerá o usará la información.
- Caso de uso: son las acciones que pueden tener lugar en el sistema que queremos modelar. Para identificarlas, puede ser útil preguntarse cuáles son las tareas y responsabilidades de cada actor, si habrá actores que recibirán información del sistema, etc.
- Relaciones: indican actividad o flujo de información.
- Límite del sistema: define el ámbito donde se produce el caso de uso que estamos representando y que va a ser tratado por el sistema. Los actores no son parte del sistema y por lo tanto están fuera de sus límites.
A continuación veamos una propuesta de caso de uso en el ámbito de la gestión de los contactos y proyectos.
Caso de uso para la gestión de contactos y proyectos.
En primer lugar, vemos que estamos modelando a muy alto nivel, trasladando lo expresado en los requerimientos a una representación gráfica. Las relaciones entre los actores y los casos de uso indican si proporcionan o reciben información (según el sentido de la flecha).
En cambio, las relaciones entre casos de uso pueden tener significados diferentes. Cada caso de uso es susceptible de representarse más detalladamente en otro diagrama. Ampliemos uno de ellos para mostrarlo.
Caso de uso para la aceptación de la propuesta
La etiqueta incluye entre dos casos de uso indica que uno tiene la funcionalidad de otro como parte integrante suya. En el ejemplo, la aceptación de la propuesta incluirá la funcionalidad para actualizar los datos del cliente (ahora tenemos un cliente en lugar de un simple contacto), emitir la factura inicial, quizá (no forzosamente)
crear el proyecto, etc.
La etiqueta extiende indicará que un caso de uso amplía la funcionalidad de otro. En el ejemplo, la emisión de la factura inicial no es la emisión de una factura cualquiera, implicará comprobaciones, como por ejemplo si tenemos todos los datos del cliente, etc., que no se producen en la emisión de una factura normal. Ahora bien, está claro que habrá una parte de funcionalidad que compartirán.
En otras palabras, la creación de la factura inicial es un caso particular de la emisión de una factura.
La etiqueta generaliza indica también una relación padre hijo similar a la extensión, con la diferencia de que actúan exactamente igual en cuanto a reglas de negocio se refiere. En otras palabras, en un momento dado podríamos sustituir el caso de uso padre por el hijo y el sistema no se vería afectado. En cambio, en una relación de extensión esto no sucede, no podemos sustituir la emisión de cualquier factura por la de la factura inicial.
Las relaciones de generalización también pueden darse entre los actores. Volviendo al diagrama inicial:
Caso de uso para la gestión de contactos y proyectos, con generalización en los actores
Vemos que generalizamos a un cliente en un contacto; es completamente lógico si consideramos que todos los clientes fueron contactos en un cierto instante y que deben poder mantener sus mismas funcionalidades.
Dado el alto nivel al que estamos modelando el sistema en esta fase, es importante tener presentes algunas buenas prácticas con respecto a la interpretación y creación de diagramas de casos de uso:
- Empezar los nombres de los casos de uso con un verbo.
- Aunque no hay forma de indicar el orden en que un actor aplicará los casos de uso, suele ser más intuitivo representarlos en orden descendiente, situando los más importantes en la parte superior del diagrama.
- Situar a los actores principales en la parte superior del diagrama también ayuda a su comprensión y a generalizar de forma más entendible.
- Nombrar a los actores con sustantivos relacionados con las reglas de negocio, de acuerdo con los roles que representan. No con su cargo o posición en el sistema.
- Anteponer “Sistema” o sistema a los actores que sean procesos externos.
- Para representar eventos que ocurren de forma programada, podemos introducir un actor de sistema “Tiempo” para modelar sus casos de uso.
- La etiqueta incluye no es obligatoria. Es aconsejable incluirla sólo si en un punto específico la lógica del caso de uso incluido es necesaria.
- No debe abusarse de la etiqueta extiende, ya que dificulta la comprensión del caso.
- La generalización de clases suele identificarse porque una sola condición del caso de uso (en el ejemplo, el método de envío), cambia por completo su lógica interna, pero no así las reglas de negocio del sistema.
- Debe evitarse representar más de dos niveles de asociaciones de casos de uso en un mismo diagrama. Si nos encontramos en esta situación, hay muchas probabilidades de que estemos haciendo una representación funcional de lo que ocurre en el caso de uso. Debemos concentrarnos sólo en los requisitos de uso, ya que la descomposición funcional es parte de la fase de diseño.
- Situar los casos incluidos a la derecha del caso que los incluye ayuda a comprender mejor el diagrama. De la misma forma, es más intuitivo situar los casos que extienden debajo del caso padre, al igual que los casos que heredan o generalizan.
- Es útil intentar expresar con “es como” la generalización de actores para comprobar si los estamos modelando correctamente.