Casos de uso

	Los requerimientos son importantes y es donde las técnicas del UML son especialmente provechosas. El punto de partida son los casos de uso. Estos, por lo tanto, son los motores de todo el proceso de desarrollo.
Martin Fowler UML gota a gota.

Así pues, los objetivos principales de la realización de casos de uso son:

• Definir el límite entre el sistema a desarrollar y los elementos externos a ese sistema (actores usuarios del sistema).
   
• Capturar el conjunto de funcionalidades y comportamientos del sistema a desarrollar.

Cada caso de uso se documenta mediante una representación gráfica y un texto con la descripción de las situaciones o escenarios ante los que el usuario se pueda encontrar en su interacción con el sistema.

En el modelado de casos de uso debemos tener en cuenta dos conceptos básicos:

Actores.

Los actores pueden ser personas, software o hardware; el término actor representa el rol genérico de usuario del sistema. El nombre que se le dé a un actor deberá reflejar el papel que tendrá para el sistema. Identificar los actores nos permite:
 

• Definir los límites del sistema (qué forma parte del sistema y qué no).
   
• Desarrollar un sistema orientado al usuario que contemple todas las funcionalidades esperadas por los diferentes actores.

 

Casos de uso.

Reflejan el uso que harán los actores del sistema; se muestran a través de ellos tanto las funcionalidades que ofrecerá el sistema, como los diferentes comportamientos posibles inherentes a las situaciones contempladas para cada una de estas.
 

Los casos de uso se escriben con el fin de expresar lo que debe hacer el sistema a desarrollar, sin tener en cuenta cómo debe hacerlo.

Diagramas de casos de uso.

• Comunicación (relación entre un actor y un caso de uso con el que interactúa; se representa símplemente con una línea).
   
• Uso (include, includes, uses; se representa por una flecha apuntando en el sentido de la relación).
   
• Extensión (extend, extends; gráficamente la representación es la misma que para "uso").
   
• Generalización (se trata del concepto de herencia, habitual en los diagramas de clases, pero aplicado entre casos de uso, e incluso entre actores; se representa por una flecha con un triángulo vacío por punta señalando en el sentido de la relación).
   

Por ahora nos centraremos en las relaciones de uso y extensión.

Relación <<include>>.

Es una simple relación de inclusión, es decir, los escenarios o situaciones posibles detalladas en un caso de uso están incluidas en otro caso de uso (aquel del que, gráficamente, parte la flecha).
 

Relación <<extend>>.

Este tipo de relación refleja situaciones particulares en un caso de uso que pueden ser tratadas (extendidas) por otro. En la descripción del caso de uso que es extendido debe haber una forma de indicar en que punto entra en juego el caso de uso que lo extiende (punto de extensión); esto se representa mediante una "etiqueta" (un texto significativo entre paréntesis) como referencia del lugar donde entraría a formar parte del caso de uso extendido.
 

Una vez expuestos los principales tipos de relación que vamos a encontrar en los diagramas de casos de uso es buen momento para hacer referencia a la descripción que acompaña a cada caso de uso. Hasta aquí hemos tenido en cuenta principalmente la representación gráfica, sin embargo, aparte de esta, un diagrama de casos de uso llevará asociada una descripción textual, en forma de flujos de eventos, de cada caso de uso representado. Surgen aquí dos tipos de apartado a tener en consideración:

Flujo de eventos principal

Se trata de una descripción de los eventos que van aconteciendo en el uso habitual, es decir, cuando no se presenta ningún tipo de problema (es el denominado happy path).
 

Flujo de eventos excepcional

Podemos encontrar tantos apartados de este tipo como situaciones excepcionales se puedan plantear, siendo que para cada uno de estos escenarios atípicos se definirá el flujo de eventos correspondiente.