Diseñando un Diagrama de Casos de Uso con UML

Diseñando un Diagrama de Casos de Uso con UML (Unified Modeling Language)

UML especifica una notación para el diseño de diagramas de casos de uso. Hay que  decir que un diagramas de casos de uso no son una especificación detallada de cada caso de uso sino de aquellos que poseen una mayor relevancia en el desarrollo del sistema. Para ello existen otras vistas como la vista de interacción, específicamente los diagramas de secuencia o de colaboración que expresan detalladamente el flujo de interacción entre el actor y el sistema de manera detallada conocidos como casos de uso extendidos. Los diagramas de casos de uso son un nivel de abstracción más alto que el detalle de los mismos y presenta todos los casos de uso del sistema a construir (en algunos casos se crean diagramas de casos de uso de varios niveles o separados por módulos esto depende del tamaño del sistema o del propio gusto del modelador)

Para poder crear diagramas de casos de uso hay que entender la semántica para su construcción. UML 2.0  definió una notación para cada elemento del diagrama:

1.       Actor

2.       Caso de Uso

3.       Relaciones

1.       Asociación

2.       Inclusión (INCLUDE)

3.       Extensión (EXTEND)

4.       Generalización

1. Actor: El caso de uso es una descripción funcional de la interacción entre uno o varios actores y el sistema que se está modelando específicamente sobre la funcionalidad desarrollada en el caso de uso. El actor está asociado a un rol específico que cumple en la interacción con el sistema (Ej. Usuario administrador, empleado, etc.). Un actor del sistema generalmente corresponde con un ser humano que tiene un rol de interacción con el caso de uso pero no siempre es así; un actor puede ser un hardware, otro sistema, un servicio que consume las funcionalidades modeladas en el caso de uso, etc. En UML 2.0 un actor se expresa simplemente con una figura en forma de ser humano. Esta figura va acompañada del nombre del actor que representa.

Notación UML 2.0 para un Actor

2. Caso de Uso: Un casos de uso define un comportamiento del sistema para cumplir un objetivo particular para un actor particular. Previa a la especificación de casos de uso existe todo un proceso que se expondrá en otros artículos de casosdeuso.com relacionada con la Ingeniería de Requerimientos, pero básicamente se podría decir que un requerimiento funcional del sistema puede dar origen a uno o muchos casos de uso. Es por eso que definir correctamente todos los requerimientos funcionales (y no funcionales) previos al diseño de diagramas de casos de uso es tan importante.  Por ejemplo, podríamos decir que existe un requerimiento funcional que es el CRUD (Create-Read-Update-Delete) para Administrar Clientes en un sistema de pedidos, es decir, que este requerimiento está asociado con el comportamiento de que el sistema adicione, consulte, actualice un elimine un cliente del sistema, estas operaciones solo podrán ser realizadas por un usuario Administrador de Pedidos. Desde la orientación a objetos también se observa claramente que existe una entidad de negocio (clase) que es el Cliente compuesto de un conjunto de atributos y operaciones (las del requerimiento). El diagrama de casos de uso no muestra el detalle de estas operaciones (se puede presentar en un diagrama de secuencias o en artefacto de software que es un documento de caso de uso del que hablaremos en otros artículos) pero sí presenta la relacion entre el actor (en este caso el cliente) y los casos de uso. La forma de diseñar los diagramas de casos de uso depende mucho de la complejidad de los procesos de negocios a modelar. Para efectos de nuestro ejemplo podriamos decir que este requerimiento Administrar Clientes da origen a cuatro casos de uso: Crear  Cliente, Buscar Cliente, Actualizar Cliente y Eliminar Cliente. La notación UML para un caso de uso se denota por una elipse y el nombre del caso de uso.

Notacion UML 2.0 para un Caso de Uso

3. Tipos de Relaciones: Para la construcción de los diagramas de casos de uso se han identificado un conjunto de relaciones que se pueden dar entre ellos. Estas relaciones expresan relaciones significativas, de interacción o de dependencia entre comportamientos del sistema a través de casos de uso.  A continuación se detallan estas relaciones:

3.1. Asociación: Una asociación es la relación de comunicación más simple entre un actor y el sistema. Las asociaciones implican que un actor interactúa con el comportamiento modelado en el caso de uso. La notación para las asociaciones es un línea simple entre el actor y el caso de uso en el que participa.

Notación UML 2.0 – Asociación

Para el ejemplo anterior,  se tiene la hipótesis del negocio de que el administrador del sistema de pedidos es quien puede crear, consultar, modificar o actualizar un cliente:

Notación UML 2.0 – Ejemplo de Asociaciones en un diagrama de casos de uso.

NOTA: Es común darle un nombre a la asociación por encima de la línea, esto con el objetivo de dar claridad semántica a dicha relación.

3.2 Inclusión (INCLUDE):  La inclusión en los diagramas de casos de uso es un tipo de relación que describe explícitamente el uso OBLIGATORIO de otro caso de uso. Es decir que un caso de uso incluido en otro indica que su ejecución es obligatoria en el comportamiento modelado en el caso de uso que lo incluye. La notación UML para una inclusión se ve como una flecha de líneas discontinuas con la palabra reservada <<INCLUDE>>:

Notación UML 2.0 Inclusión

Para el ejemplo, se puede dar el caso de que para Actualizar un Clientesiempre se hará necesario Consultar un Cliente:

Notación UML 2.0 – Ejemplo de Inclusiones en un diagrama de casos de uso.

3.3 Extensión (EXTEND): La extensión en los diagramas de casos de uso es un tipo de relación que indica que un caso de uso puede extender su comportamiento a otro caso de uso. La extensión no es obligatoria (como si ocurre en la inclusión), es decir que el caso de uso que al que extiende puede o no ejecutar el comportamiento del caso de uso.  La notación UML para una extensión se ve como una flecha de líneas discontinuas con la palabra reservada <<EXTEND>>:

Notación UML 2.0 para la Extensión

Para el ejemplo, puede darse el caso de que al Consultar un Cliente éste no exista, y al no existir se requiera que se permita Crear el Cliente. Esta relación es una  donde el caso de uso Crear Cliente puede extenderse a la funcionalidad de Consultar Cliente. Puede que el caso de uso consultar cliente lo ejecute o no lo ejecute dependiendo de si existe o no existe el cliente en el sistema. Los casos de uso que extienden generalmente se reflejan en el documento de caso de uso como un flujo alterno. Para el ejemplo, en el caso de uso consultar un cliente existirá un flujo alterno crear cliente que ejecuta el caso de uso extendido al mismo:

Notación UML 2.0 – Ejemplo de extensión en un diagrama de casos de uso.

NOTA: La clave para diferenciar una inclusión de una extensión se puede dar por la siguiente regla:

1. Una inclusión implica que el caso de uso que lo incluye SIEMPRE ejecutará el otro caso de uso.  En el detalle de caso de uso (que no se ve en el diagrama de casos de uso) que puede ser el documento de casos de uso, las inclusiones se ven comúnmente como un paso del flujo principal de eventos del caso de uso.

2. Una extensión implica que el caso de uso al que extiende NO SIEMPRE ejecutará el otro caso de uso extendido. En el detalle de casos de uso las extensiones se ven comúnmente como flujos alternos del caso de uso.

3.4 Generalización: En algunos momentos surge la necesidad, al igual que en la orientación a objetos, de que un caso de uso se pueda especializar en otros más concretos, a esto se le llama Generalización. En un caso de uso especializado, siempre se esperará que el caso de uso padre se ejecute. La notación UML para la generalización se representa con una punta de flecha triangular que va desde el caso de uso hijo hasta el caso de uso padre:

Nota UML 2.0 para Generalización

Para el ejemplo, podríamos suponer que el negocio modelado exige tener dos casos de uso especializados, que usan el caso de uso padre Crear Cliente pero que adicionan propiedades particulares; estos casos de uso son Crear Cliente Gold y Crear Cliente Platinum ya que cada uno adiciona propiedades y eventos adicionales al que posee el caso de uso Crear Cliente. Como lo comentaba, son especializaciones de Crear Cliente porque usan éste y agregan comportamientos/propiedades adicionales. Esto implica que el caso de uso Crear Cliente Gold y Crear Cliente Platinum ejecuta primero el comportamiento del caso de uso padre Crear Cliente:

Ejemplo completo quedaría así:

Notacion UML 2.0 – Ejemplo completo diagrama de casos de uso

Conclusiones

Los casos de uso son una excelente herramienta para guiar el proceso de desarrollo de código fuente y como le mencionaba acotan el alcance del sistema. Son usados comúnmente en metodologías de desarrollo como RUP pero en la actualidad ya existen metodologías ágiles como Essential Unified Process (ESSUP) que toman el caso de uso como vista de escenarios principal para el desarrollo y construcción de software.