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.
