Tema 3: Diagramas de Casos de Uso

1.-Introducción
Los casos de uso han sido adoptados casi universalmente para la captura de requisitos de
sistemas de software en general, y de sistemas basados en componentes en particular, pero
los casos de uso son mucho más que una herramienta para capturar requisitos. Dirigen el
proceso de desarrollo en su totalidad. Los casos de uso son la entrada fundamental cuando
se identifican y especifican clases, subsistemas e interfaces, cuando se identifican y
especifican casos de prueba, y cuando se planifican las iteraciones del desarrollo y la
integración del sistema
La captura de requisitos tiene dos objetivos: encontrar los verdaderos requisitos y,
representarlos de un modo adecuado para los usuarios , clientes y desarrolladores.
Entendemos por verdaderos requisitos aquellos que cuando se implementan añadirán el
valor esperado para los clientes
En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones
que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un
actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para
especificar la comunicación y el comportamiento de un sistema mediante su interacción con
los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre
los actores y los casos de uso en un sistema. Una relación es una conexión entre los
elementos del modelo, por ejemplo la especialización y la generalización son relaciones.
Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al
mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un Caso
de Uso representa una unidad discreta de interacción entre un usuario (humano o máquina)
y el sistema. Un Caso de Uso es una unidad de trabajo significativo; por ejemplo crear una
solicitud y modificar una solicitud son todos Casos de Uso.
Cada Caso de Uso tiene una descripción que especifica la funcionalidad que se incorporará
al sistema propuesto. Un Caso de Uso puede 'incluir' la funcionalidad de otro Caso de Uso
o puede 'extender' otro Caso de Uso con su propio comportamiento.
2.- El modelo de casos de uso representa los requisitos funcionales
El modelo de casos de uso ayuda al cliente, a los usuarios y a los desarrolladores a llegar a
un acuerdo sobre como utilizar el sistema. La mayoría de los sistemas tiene muchos tipos
de usuarios . cada tipo de usuario se representa mediante un actor . los actores utilizan el
sistema al interactuar con los casos de uso. Todos los actores y casos de uso del sistema
forman un modelo de casos de uso
3.-Restricciones, requisitos y escenarios
La especificación formal de un Caso de Uso incluye 3 elementos básicos:
 Requisitos. Son los requisitos funcionales formales que el Caso de Uso debe proveer al
usuario final. Ellos corresponden a las especificaciones funcionales de las metodologías
estructuradas. Un requisito es un contrato de que el Caso de Uso realizará alguna acción o
proveerá algún valor al sistema.
  Restricciones. Estas son las reglas formales y las limitaciones bajo las que opera un Caso de
Uso e incluyen las pre-condiciones, las post-condiciones y las invariantes. Una
precondición especifica qué debe haber ocurrido o estar cumplido antes de que el Caso de
Uso pueda iniciarse. Una post-condición documenta qué será verdadero una vez que el
Caso de Uso se complete. Una invariante especifica qué será verdadero durante el tiempo
en que opere el Caso de Uso.
 Escenarios. Son descripciones formales del flujo de eventos que ocurre durante una
instancia de un Caso de Uso. Usualmente se describen con texto y corresponden a una
representación textual del diagrama de secuencia.
3.- Elementos del Modelo de Casos de Uso

3.1.- Nombres
Cada caso de uso debe tener un nombre que los distinga de otros casos de uso. Un nombre
es una cadena de texto. Ese nombre sólo se llama nombre simple; un nombre de camino
consta del nombre del caso de uso precedido del nombre del paquete en el que se encuentra.
Normalmente un caso de uso se dibuja mostrando sólo su nombre.
Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que
indique su funcionalidad. Los casos de uso pueden tener relaciones con otros caso de uso.
Sus relaciones son:
 Include: Representado por una flecha, en el diagrama de ejemplo podemos ver
como un caso de uso, el de totalizar el coste incluye a dos casos de uso.
 Extends: Una relación de una caso de Uso A hacia un caso de uso B indica que el
caso de uso B implementa la funcionalidad del caso de uso A.
 Generalización: Es la típica relación de herencia.
3.2.- Asociaciones: Hay una asociación entre un actor y un caso de uso si el actor
interactúa con el sistema para llevar a cabo el caso de uso
3.3.-Actores

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le
demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a
todos los sistemas externos, además de entidades abstractas, como el tiempo.

En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo
que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin
embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que
nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y
siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de
capturar dicho requisito en el modelo de caso de uso final.

Se representa mediante una figura humana dibujada con palotes. Esta representación sirve
tanto para actor que son personas como para otro tipo de actores. Los actores sólo se
pueden conectar a los casos de uso a través de asociaciones . una asociación entre un actor
y un caso de uso indica que el actor y el caso de uso se comunican entre sí , y cada uno
puede enviar y recibir mensajes.

3.3.1.-Tipos de actores

 Primarios, interaccionan con el sistema para explotar su funcionalidad; trabajan

directa y frecuentemente con el software
 Secundarios, soporte del sistema para que los primarios puedan trabajar

3.3.1.1 Relaciones entre actores:

Los actores en UML son clases con el estereotipo <<actor>> y tienen un estereotipo icono
estándar. El nombre de la clase es el nombre del actor.

Cuando varios actores, como parte de sus papeles, también representan un papel más
generalizado, se describe mediante una relación de generalización.
– El comportamiento del papel general se describe en una superclase actor. Los actores
especializados heredan el comportamiento de la superclase y extienden ese comportamiento
de algún modo como en la siguiente figura:
 Figura: Generalización de actores

Ejemplo que muestra la interacción de actores con casos de uso

Ejemplo de Casos de Uso

Elementos de un diagrama de casos de uso:

4.- Modelo de casos de uso

 Presenta una notación gráfica con actores y casos de uso

 Presenta relaciones
o Entre actores: herencia
o Entre actores y casos: comunicación
o Entre casos de uso: inclusión, extensión y herencia

El modelo de casos de uso muestra gráficamente toda la funcionalidad del sistema como se
evidencia en las figuras anteriores

El modelo está organizado en tres capas:

 Diagrama de contexto o negocio y modelo inicial

 Plantillas de descripción
 Modelo estructurado

5.- Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML,
el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas a
continuación:

5.1.-Inclusión (include o use)

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro. El primer
caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para
extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una
descripción individual, desde el caso de uso. El estándar de Lenguaje de Modelado
Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso,
pero no el formato para describir casos de uso. Mucha gente sufre la equivocación
pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la
notación gráfica y las descripciones son importantes, ellos forman parte de la
documentación de un caso de uso --un propósito para el que el actor puede usar el sistema.
La notación es de una flecha de punta abierta con línea discontinua desde el caso de uso
que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»". Este uso se
asemeja a una expansión de una macro, donde el comportamiento del caso incluido es
colocado dentro del comportamiento del caso de uso base. No hay parámetros o valores de
retorno. Aquí también podemos decir que éste va de padre a hijo.

Un Caso de Uso puede incluir la funcionalidad de otro como parte de su procesamiento

normal. Generalmente se asume que los casos de uso incluidos se llamarán cada vez que se
ejecute el camino base. Un ejemplo puede ser listar un conjunto de órdenes de clientes de
las cuáles poder elegir antes de modificar una orden seleccionada; en este caso, el Caso de
Uso <listar órdenes> se puede incluir en el Caso de Uso <modificar orden> cada vez que
éste se ejecute.
Un Caso de Uso puede ser incluido por uno o más casos de uso, ayudando así a reducir la
duplicación de funcionalidad al factorizar el comportamiento común en los casos de uso
que se reutilizan muchas veces.
Ejemplo:

En la imagen anterior tanto “Reservar Libro” como “Renovar préstamo” hacen algo en
común “Comprobar reserva”.
Las ventajas de esta asociación son:
 Las descripciones de los casos de uso son más cortas y se entienden mejor.
 La identificación de funcionalidad común puede ayudar a descubrir el posible uso
de
componentes ya existentes en la implementación.
Las desventajas son:
 La inclusión de estas relaciones hace que los diagramas sean más difícil de leer,
sobre todo para los clientes.

5.2.- Extensión (Extend)

Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a otro. El
caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas
condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el
caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser
útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el
mantenimiento del sistema y su extensión.Un Caso de Uso puede extender el
comportamiento de otro Caso de Uso; típicamente cuando ocurren situaciones
excepcionales. Por ejemplo, si antes de modificar un tipo particular de orden de cliente, un
usuario debe obtener la aprobación de alguna autoridad superior, entonces el Caso de Uso
<obtener aprobación> puede extender opcionalmente el Caso de Uso normal <modificar
orden>.

"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la
extensión son los ejemplos o instancias de los conceptos."

Se puede incluir una relación entre dos casos de uso de tipo “exclude” si se desea
especificar diferentes variantes del mismo caso de uso. Es decir, esta relación implica que
el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias. En
principio esas variaciones pueden también mostrar

La flecha en el caso de las relaciones “extend” va hacia el caso de uso “original”.

5.3.- Generalización

"Entonces la Generalización es la actividad de identificar elementos en común entre

conceptos y definir las relaciones de una superclase (concepto general) y subclase
(concepto especializado). Es una manera de construir clasificaciones taxonómicas entre
conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales
son conformes con las superclases conceptuales en cuanto a la intención y extensión."

En la tercera forma de relaciones entre casos de uso, existe una relación

generalización/especialización. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notación es una línea sólida terminada en un
triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se
asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil
factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una
vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados. esto es
gran mentira

Una relación de generalización entre Casos de Uso implica que el Caso de Uso hijo hereda
todos los atributos, secuencias de comportamiento, puntos de extensión y relaciones
definidos en el Caso de Uso padre. El Caso de Uso hijo puede definir nuevas operaciones,
como también redefinir o enriquecer con nuevas secuencias de acciones operaciones ya
existentes en el Caso de Uso padre.