Qué es un diagrama de casos de uso?

Es un diagrama de UML (Lenguaje Unificado de Modelado) que se utiliza para modelar los
aspectos dinámicos de un sistema, un subsistema o una clase, de tal forma que los usuarios
puedan comprender cómo utilizar cada uno de sus elementos y de forma que los
programadores puedan implementarlo.

Elementos:

1. Caso de uso.
• Un caso de uso es una descripción de los pasos o las actividades que deberán
realizarse, incluyendo las variaciones de la secuencia de pasos, para que el sistema
lleve a cabo algún proceso que dé resultados observables y de valor para un actor.
• Un caso de uso describe “qué” hace un sistema (o un subsistema, una clase o una
interfaz), pero no especifica “cómo” lo hace, esto se realiza porque permite que
los usuarios finales y los expertos del dominio se comuniquen con los
desarrolladores sin quedarse atascados en los detalles.
• Un caso de uso captura el comportamiento esperado del sistema (o un
subsistema, una clase o una interfaz) que está desarrollando, sin tener que
especificar cómo se implementa ese comportamiento. Esta separación es
importante porque el análisis de un sistema (que especifica un comportamiento)
no debería estar influenciado por cuestiones de implementación
• Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso. Se
llama nombre simple si solo es una cadena de texto, y se llama nombre específico
si el nombre del caso de uso va precedido del nombre del paquete en el que se
encuentra.
2. Actor.
• Un actor representa un rol que es desempeñado por una persona, un dispositivo
hardware o incluso otro sistema al interactuar con nuestro sistema.
• Un objeto puede representar el papel de varios actores. Por ejemplo si una
persona trabaja para un banco este podría ser un actor “ResponsablePrestamos”,
si tiene sus cuentas personales en ese mismo banco está desempeñando también
el rol de “Cliente”.
• Aunque se utilizan actores en el modelo, estos no forman parte del sistema. Están
fuera de la aplicación, en el entorno que lo rodea
• Los actores se representan como monigotes. Se pueden definir categorías
generales de actores (“Cliente”) y especializarlos (“ClienteComercial”) a través de
relaciones de generalización.
3. Relaciones.
• Los casos de uso pueden organizarse especificando las relaciones de
generalización, inclusión y extensión entre ellos. Estas relaciones se utilizan para
factorizar el comportamiento común (extrayendo ese comportamiento de los
casos de uso en los que se incluyen) y para factorizar variantes (poniendo ese
comportamiento en otros casos de uso que lo extienden).

3.1. Generalización.
• El caso de uso hijo hereda el comportamiento y el significado del caso de uso
padre (igual que en la generalización de clases); el hijo puede añadir o redefinir el
 comportamiento del padre; el hijo puede ser colocado en cualquier lugar donde
aparezca el padre (tanto el padre como el hijo podrán tener instancias concretas).

3.2. Inclusión.
• Un caso de uso base incorpora explícitamente el comportamiento de otro caso de
uso en el lugar especificado en el caso de base. El caso de uso incluido nunca se
encuentra aislado, sino que es instanciado solo como parte de algún caso de uso
base más amplio que lo incluye. La inclusión puede verse como que el caso de uso
base toma el comportamiento del caso de uso proveedor.
• La relación de inclusión se usa para evitar describir el mismo flujo de eventos
repetidas veces, poniendo el comportamiento común en un caso de uso aparte
(que será incluido por un caso de uso de una base). La relación de inclusión es
básicamente una relación de delegación: se toma un conjunto de
responsabilidades del sistema y se capturan en un sitio (el caso de uso a incluir en
otros); a continuación se permite que otras partes del sistema (otros casos de uso)
incluyan la nueva agregación de responsabilidades, siempre que se necesite usar
esa funcionalidad.
• Se representa como una dependencia estereotipada con “include”. Para
especificar la posición en un flujo de eventos en la cual el caso de uso base incluye
el comportamiento de otro caso de uso.
3.3. Extensión.
• Significa que un caso de uso base incorpora implícitamente el comportamiento de
otro caso de uso en el lugar especificado indirectamente por el caso de uso que se
extiende al base.
• El caso de uso base puede estar aislado pero, en algunas condiciones, su
comportamiento puede extenderse con el comportamiento de otro caso de uso.
• Este caso de uso base puede extenderse sólo en ciertos puntos llamados puntos de
extensión. La extensión se puede ver como que el caso de uso que extiende
incorpora su comportamiento en el caso de uso base.
• Se utiliza para modelar la parte de un caso de uso que el usuario puede ver como
comportamiento opcional del sistema. De esta forma, se separa el
comportamiento opcional del obligatorio. También se puede utilizar una relación
de extensión para modelar un subflujo separado que se ejecuta bajo ciertas
condiciones. También se puede utilizar una relación de extensión para distinguir
las partes opcionales de un sistema que se va a implementar. El significado es que
el sistema puede existir con o sin las diferentes extensiones.
• Una relación de extensión se representa como una dependencia estereotipada con
“extend”. Los puntos de extensión del caso de uso base se pueden listar en un
compartimiento extra. Estos puntos de extensión solo son etiquetas que pueden
aparecer en el flujo del caso de uso base.

Casos de uso:

Modelado del contexto de un sistema.

• Definir el sujeto. Hay que identificar las fronteras del sistema decidiendo los
comportamientos que conformarán parte de él y cuáles serán ejecutados por
entidades externas.
• Identificar los actores del sistema. Esto se hace considerando qué grupos requieren
ayuda del sistema para llevar a cabo sus tareas; qué grupos son necesarios para
ejecutar las funciones del sistema; qué grupos interactúan con el hardware externo o
con otros sistemas de software; y qué grupos realiza funciones secundarias de
administración y mantenimiento.
• Organizar los actores similares en jerarquías de generalización/especialización.
• Proporcionar un estereotipo para cada uno de esos actores, si así se ayuda a entender
el sistema.