Casos de Uso Introducción Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Representan las funciones que un sistema puede ejecutar. Por tanto los casos de uso determinan los requisitos funcionales del sistema. Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente. Desde el punto de vista del cliente proporcionan una visión de caja negra del sistema, esto es, como aparece el sistema desde el exterior sin necesidad de entrar en los detalles de su construcción. Para los desarrolladores, suponen el punto de partida y el eje sobre el que se apoya todo el desarrollo del sistema en sus procesos de análisis y diseño. Los casos de uso deben especificar un comportamiento deseado pero no imponer cómo se llevará a cabo. El diagrama de casos de uso debe tener: Los actores. Una lista con la descripción de los actores. Los casos de uso. Las relaciones entre casos de uso. Una lista con la descripción de los casos de uso. Actores Los actores representan los diferentes roles que juegan los usuarios que interactuaran con el sistema, proporcionándole información o recibiéndola. Los actores pueden ser humanos, pero también otros sistemas informáticos, empresas, unidades organizativas de una empresa, etc. Cabe remarcar que los actores no son individuos particulares, sino papeles. Una misma persona puede tener varios roles.
Suele ser útil mantener una lista de los usuarios reales para cada actor. Casos de uso Un caso de uso es una funcionalidad o tarea que debe poder llevarse a cabo con el apoyo del sistema que se está desarrollando. Son procesos autónomos iniciados por un actor o por otro caso de uso. Las podemos identificar preguntando cuáles son las tareas y responsabilidades de cada actor, qué actores reciben información del sistema. Aquellos casos de uso que resulten demasiado complejos se pueden descomponer en un segundo nivel, en el que los nuevos casos de uso que intervengan resulten más sencillos y manejables. Se puede completar la descripción definiendo cuáles son las precondiciones y postcondiciones de cada caso de uso. Un escenario es la narración de un ejemplo concreto de caso de uso. Por ejemplo, Pepito decide llevarse El Quijote de la biblioteca.... Una vez identificados los casos de uso, se pueden ordenar por orden de importancia y, teniendo en cuenta el tiempo estimado para desarrollarlos, planificar las iteraciones (en una metodología incremental). Asociaciones Las asociaciones entre actores y casos de uso no son obligatorias, en el sentido de que si aparece una asociación entre un actor y un caso, indica que puede que ese actor interactúe con el sistema en ese caso de uso. Existen tres tipos de asociaciones o relaciones en los diagramas de casos de uso: Incluye: Un caso de uso incluye otro caso de uso cuando la funcionalidad proporcionada por el primero siempre necesita de la funcionalidad proporcionada por el segundo caso de uso. Se puede incluir una relación entre dos casos de uso de tipo include si se desea especificar comportamiento común en dos o más casos de uso. De esta manera las descripciones de los casos de uso son más cortas y se entienden mejor, y la identificación de funcionalidad común
puede ayudar a descubrir el posible uso de componentes ya existentes en la implementación. Extiende: Un caso de uso es extendido por otro caso de uso cuando la funcionalidad proporcionada por el primero en determinadas condiciones necesita de la funcionalidad proporcionada por el segundo caso de uso. Por ejemplo, un caso de uso puede llamar a la funcionalidad proporcionada por otro caso de uso cuando se de un error o una condición excepcional. Dicho de otra forma, la relación extend implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias. Generaliza: En un diagrama de casos de uso también pueden mostrarse generalizaciones o especializaciones (relaciones de herencia) para mostrar que diferentes elementos están relacionados como tipos de otros. Son aplicables tanto a actores como a casos de uso. Un caso de uso especializa a otro cuando el primero tiene la misma funcionalidad que el segundo, y alguna más, o cuando se aplica a una subclase de la clase a la que se aplica el segundo. Debemos ir con cuidado: la inclusión de estos tres tipos de relaciones hace que los diagramas sean más difíciles de leer, sobre todo para los clientes.
Límites del sistema Es útil dibujar un recuadro con los límites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema. Ejemplo
Consejos 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.