UML Capítulo12: Vista de Casos de Uso

¡Hola de nuevo internauta!,

      En esta entrada hablaremos sobre la denominada vista de casos de uso cuya finalidad es capturar el comportamiento de un sistema, subsistema, clase o componente tal y como se mostrará al usuario externo. Para ello divide la funcionalidad del sistema en transacciones cuyo significado  entiende el usuario(llamado actor).

1. Actor

Con actor no nos referimos a una estrella del cine, teatro o televisión puesto que el entorno en el que nos manejamos es el de Ingeniería del Software. ¡Pero se me está yendo la cabeza!, seguimos con lo que nos interesa.

Un actor plasma la idea de un rol que puede desempeñar una persona, un proceso u otra cosa externa al sistema(o subsistema, o clase) que interactúa con el mismo mediante el intercambio de mensajes(llamado comunicación). Los actores pueden ser definidos en jerarquías de generalización.

Existen diferentes tipos de actores:

• Primarios: Son aquellos que explotan el sistema mediante la interacción con el mismo.
• Secundarios: Son aquellos que interactúan con el caso de uso para dar soporte a los primarios.
• Iniciadores: Son aquellos que desencadenan el trabajo de otro actor sin usar directamente el sistema.

En algunos libros y seminarios sobre UML, como el que nos ofrece la Universidad de Granada (aquí), se propone una plantilla para la descripción de actores en documentación. Pongo una captura de pantalla obtenida del documento ofrecido por la Universidad de Granada sobre casos de uso cuyo enlace tenemos unas líneas más arriba.

2. Caso de uso

Su finalidad es definir una pieza de comportamiento coherente sin revelar la estructura interna del sistema. Tenemos dos puntos de vista de un caso de uso:

• En el modelo, la ejecución de cada caso de uso es independiente de los otros.
• En el sistema, representan el comportamiento externo del mismo y como es percibido por los actores.

Cada caso de uso se debe corresponder con las clases que implementan un sistema. Su comportamiento se corresponde con las transacciones y operaciones de las clases. Su implementación se puede modelar como un conjunto de una o más colaboraciones(una colaboración es la realización de un caso de uso).

Su dinámica se materializa en diagramas de estados, diagramas de secuencia, diagramas de comunicación o descripciones informales de texto.

Ejemplo de diagrama de caso de uso que representa a un Catálogo Telefónico

Especificación de un caso de uso

La especificación de un caso de uso responde a la necesidad de documentar el escenario o escenarios en los que se ejecutará y conocer así sus limitaciones y características particulares. Dicho de otra manera, representa las interacciones del actor con el sistema. Por ejemplo, siguiendo el diagrama expuesto anteriormente el cliente posee tres casos de uso: comprobar estado, hacer pedido y establecer pedidos; y cada uno tendrá su especificación o especificaciones ya que pueden tener uno o más escenarios. A continuación desarrollaremos a grandes rasgos un ejemplo de escenarios con el caso de uso hacer pedido:

Escenario 1: Si el usuario no tiene una cuenta abierta se le pedirá que abra una mostrándose la pantalla para el alta.
Escenario 2: Si el usuario tiene cuenta se ejecuta el caso de uso comprobar estado(para saber si lo que pide está disponible) y se le permite hacer el pedido puede llenar su carro de la compra añadiendo o quitando productos. El usuario confirma la compra tras lo cual se le lleva a la plataforma de pago y se vacía su carrito de la compra. Lo que haya comprado el usuario se almacena en su historial de compra.
Escenario 3: El usuario cancela la compra. Se le lleva a la pantalla de inicio y se vacía su carrito de la compra.

Creo que con esto nos hacemos una idea de lo que queremos explicar ;).

Para documentar toda esta información se usan unas plantillas que pueden variar de una empresa a otra o de un cliente a otro, pero que siguen un formato muy parecido. Dicha documentación siempre incluirá:

• Nombre del caso de uso.
• Identificador.
• Actores involucrados.
• Tipo del caso de uso: Primario, secundario u opcional. Personalmente no suelo usar este campo en la documentación pues la descripción del caso de uso es suficiente para saber el tipo al cual corresponde pero lo vamos a indicar igualmente.
• Referencias: Se indican los requisitos que se pueden incluir dentro del caso de uso y los casos de uso que tienen relación con este.
• Pre-condición: Condiciones sobre el estado del sistema que tienen que cumplirse para que se pueda realizar el caso de uso.
• Post-condición: Efectos sobre el sistema que tiene la realización del caso de uso.
• Propósito o descripción: Descripción del caso de uso.

Otros campos a incluir son:

• Resumen: Resumen del caso de uso a alto nivel.
• Autor: Creador del caso de uso.
• Fecha: Fecha de la creación del caso de uso o de su versión.
• Versión: Versión del caso de uso(ya que puede variar en el tiempo conforme se implemente o se profundice en el análisis o diseño) .

Estos últimos campos son necesarios sobre todo en grandes empresas donde están involucrados varios equipos o personas, pues ayuda a tener un control de la información tratada. Tenéis un buen modelo de este tipo de documentación en el enlace de la Universidad de Granada(aquí).

Os dejo un ejemplo de los escenarios indicados más arriba en este enlace. Espero que os ayude a entender lo expuesto más arriba.

Tipos de relaciones

Existen los siguientes tipos de relaciones entre los casos de uso:

Relación	Función	Notación
Asociación	Indica la relación entre el actor o caso de uso base con otro caso de uso. Puede indicarse restricción de cardinalidad.
Extensión	El caso de uso principal extiende su funcionalidad mediante otro caso de uso final bajo unas condiciones específicas. Se usan entre casos de uso similares
Generalización	Indica una relación entre un caso de uso general y un caso de uso específico. Dicha relación puede ser de herencia(<<extends>>) o de uso(<<uses>>. Son relaciones taxonómicas. Entra actores indica que uno es más general y el otro más especializado. Pudiendo comunicarse el más especializado con los mismos casos de uso que el más general.
Inclusión	El caso de uso inicial incluye al caso de uso final. Siempre que se realice el caso de uso inicial se realizará también el caso de uso final.

A continuación un ejemplo de diagrama de casos de uso(nos basaremos en el caso de uso, Hacer Pedido, del primer diagrama de este mismo artículo un poco más arriba):

Ejemplo de relaciones

¿Qué información podemos extrapolar de este ejemplo?. Vamos a dividirlo por partes:

1. Un actor(persona, sistema,...) llama al caso de uso, Hacer Pedido, que siempre ejecutará los siguientes casos de uso: Proporcionar Datos del Cliente, Pedir Producto y Acordar Pago. Fijémonos en que no se implementa el funcionamiento de los mismos si no solamente las relaciones entre los diferentes casos de uso.
2. Solicitar Catálogo es una extensión del caso de uso Hacer Pedido y vemos como la notación empieza en el caso de uso final y apunta hacia el caso de uso inicial. Lo que aquí se indica es que el actor al hacer un pedido puede solicitar un catálogo si quiere(o se le ofrecerá esa opción y él lo seleccionará o no).
3. El caso de uso Acordar Pago es una generalización de Pagar en Metálico y Acordar Crédito. Esto nos indica que en el momento de acordar el pago el actor puede decantarse por cualquiera de estas dos opciones(se hacen generalizaciones para ahorrar relaciones duplicadas aunque se invoquen desde diferentes casos de uso).

Espero que con este ejemplo os haya quedado un poco más claro el diagrama de casos de uso. Si tenéis alguna duda o queréis aportar algo más podéis dejar un comentario ;).

¡Gracias por leerme!.

PD: Los ejemplos de diagramas los he sacado del “El lenguaje Unificado de Modelado Universal”.