Capítulo VII

Conceptos Técnicas y Herramientas

VII.7 - Diagramas de Use Case

1. ¿Qué es un Use Case?

1
Un Use Case es una descripción del funcionamiento un proceso, actividad
o tarea. Los autores Hans-Erik Eriksson y Magnus Pender, en su libro
UML Toolkit, definen un Use Case como “un conjunto de secuencias de
acciones que ejecuta un sistema, para producir un resultado observable,
de valor para algún actor en particular”. Estas acciones pueden ser de
cualquier naturaleza: tareas y comunicación con otros actores, tanto
usuarios como sistemas.
Un Use Case describe un proceso, actividad o tarea, en términos de:
• El nombre que lo distingue
• La secuencia de pasos o flujo de las tareas que lo conforman.
• Las condiciones previas y posteriores que “inician” o “finalizan”el
caso.

2. Diagramas de Use Case

La técnica de modelaje denominada Diagramas de Use Case es una técnica
que permite describir el funcionamiento de una tarea, una actividad, un
proceso, un módulo o un sistema; esto es, muestra cómo los usuarios operan
(u operarán) y ejecutan (o ejecutarán) sus tareas, independientemente de
los componentes o estructura del sistema en uso (o a ser desarrollado). En
pocas palabras, puede decirse que los Use Case describen un segmento de
un sistema, desde el punto de vista sus usuarios.
Un Diagrama de Use Case representa un
conjunto de Use Cases, junto con los Actores
que participan en su ejecución; entendiendo
como actores a los usuarios del sistema,
equipos u otros sistemas que interactúan con
los casos representados en el diagrama.
Cada caso, dentro de un Diagrama de Use
Case, se muestra como una elipse, en la cual
se inscribe su nombre, y cada actor se
183
representa con un “muñeco de líneas”, debajo del cual se coloca el nombre
del actor.
La secuencia de pasos que se
ejecutan en un Use Case puede ser
descrita de diversas formas; es
muy común utilizar texto libre,
aunque puede utilizarse
pseudocódigo o un diagrama de
actividad.

184
En general, los Actores pueden ser:
• Actores Principales, que son las personas que usan el sistema.
• Actores Secundarios, que son las personas que mantienen o
administran el sistema.
• Otros sistemas con los que el sistema interactúa.
Es importante observar que la idea de Actor no se refiere a personas
específicas, sino a roles; una misma persona puede interpretar varios roles,
cumpliendo las tareas de actores distintos.
Como puede verse en el ejemplo precedente, la descripción del Use Case
comprende:
• Objetivo del Use Case.
• El inicio: cuándo y qué actor lo produce.
• El fin: cuándo se produce y qué resultado genera.
• La interacción del Actor con el Use Case: qué mensajes
intercambian.
• Secuencia y origen de las interacciones.
• Repetición de operaciones (iteraciones).
• Situaciones especiales o ejecuciones alternativas.
Un Use Case da respuesta a preguntas como las siguientes:
• ¿Cuáles son las tareas del Actor?
• ¿Qué información crea, guarda, modifica, elimina o lee el Actor?
• ¿Qué datos registra el Actor?
• ¿Qué resultados o información produce el sistema para el Actor?
Un Use Case cumple o debe cumplir las siguientes propiedades:
• Inicio:
Un Use Case es iniciado por un actor, bien sea directa o
indirectamente. Puede darse el caso en que el actor no esté
consciente del inicio de un Use Case, sin embargo, este se inicia
“en su representación”.
• Resultado:
Un Use Case produce un resultado, genera “algo de valor”. Este
resultado no es necesariamente un resultado que sale del Use Case,
pero si debe ser un resultado observable.
• Completo:
Un Use Case debe ser completo. Un Use Case no se “explota”,
como se hace con los Diagramas de Flujo de Datos, tampoco se

185
 debe fraccionar en casos más simples, que se “invocan” unos a
otros, como ocurre con las funciones o módulos de un programa.
Sin embargo, las relaciones entre Use Cases que más adelante se
discuten, permiten en cierta forma segmentarlos o modularizarlos.
• Fin:
Un Use Case no está completo, hasta que se produce su resultado
final.
3. Relaciones
En un Diagrama de Use Case, los casos (proceso, actividad o tarea) se
conectan a los Actores a través de asociaciones, con el fin de mostrar
quiénes son los actores que los inician y con cuáles actores se establece
comunicación.
A su vez, los Use Cases se asocian entre si y estas asociaciones pueden ser
de varios tipos: Inclusión /utilización y Extensión.
3.1. Inclusión/Utilización
Decimos que existe una relación de inclusión entre dos Use Case, cuando
el Use Case Origen, también incluye las acciones correspondientes al Use
Case Destino.

Para denotar estas relaciones se utiliza una flecha de cabeza triangular y

el símbolo o estereotipo <<include>> (este estereotipo reemplazó al
denominado <<uses>>). Es importante señalar que los términos origen y
destino, no tiene ninguna implicación, más que indicar la posición que
guardan los Use Case en relación a la flecha que representa la relación. El

186
Use Case Origen es el que está al inicio de la flecha y el Use Case Destino
el que está al final de ésta.
El ejemplo anterior nos muestra una relación de inclusión. En éste, si
imaginamos un sistema de manejo de órdenes, en el cual se ingresan,
modifican, consultan y cancelan pedidos de clientes, podemos observar
que al realizar las operaciones de consulta, modificación o cancelación de
órdenes, siempre será necesario “tener a la mano” los datos del pedido.
Así pues, al modelar los Use Case correspondientes a estas operaciones,
con el fin de evitar la repetición de la secuencia de pasos que corresponden
a “buscar los datos del pedido”, será preferible colocar éstas tareas en un
Use Case aparte, estableciendo un vínculo de Inclusión.
3.2. Extensión
La relación de extensión permite modelar secuencias alternativas de pasos.
Normalmente, al modelar un proceso, se trabaja con lo que podemos llamar
la situación normal o más común. Esta “situación normal” se representa
en un Use Case que podemos decir que corresponde al “escenario nor-
mal”. Al considerar el manejo de secuencias alternativas de pasos, como
ocurre en el manejo de excepciones, se prefiere modelar cada una de ellas
en un Use Case aparte, adicional. Ello permitirá que los modelos sean
mucho más simples y claros.

Para indicar la interrelación que existe entre el escenario normal y los

escenarios alternativos, se utiliza una relación de extensión, como se
muestra en el siguiente ejemplo, en el que se muestra un sistema de entrada

187
de órdenes, en el cual, normalmente, se calcula el monto total de la orden
sobre la base de las cantidades y los precios unitarios de los renglones
pedidos, pero para clientes corporativos se aplican ciertos descuentos:
En general, diremos que existe una relación de extensión, cuando el Use
Case origen extiende las acciones del Use Case destino. Para denotar estas
relaciones se utiliza una flecha de cabeza triangular y el símbolo o
estereotipo <<extend>>.
Las relaciones de inclusión y extensión constituyen una forma de factorizar
las acciones de un Use Case. Esto es, tanto el Use Case incluido, como el
Use Case que extiende representan un fragmento de las acciones que se
cumplen en otro Use Case.
En el caso de la relación de inclusión, se busca evitar una repetición de las
mismas acciones en distintos Use Cases, mientras que en el caso de la
relación extensión, se busca describir una secuencia de acciones alternativa
a las del comportamiento normal, permitiendo simplificar las
especificaciones, cuando una variación pudiera oscurecer la comprensión
del caso.

3.3. Generalización y Herencia

Al igual que otros elementos de UML, los Use Case pueden tener relaciones
de herencia, en las que el Use Case secundario hereda las acciones del Use
Case primario y, además, agrega sus propias acciones.

188
 4. Errores Comunes
Al desarrollar Use Cases, es necesario recordar que éstos definen,
principalmente, la interacción de los usuarios con el sistema, por lo tanto
deben ser vistos como si se tratara de un manual del usuario, ya que
básicamente deben contener lo que, cuando el sistema esté listo, contendrá
dicho manual.
Una vez hecha la definición inicial de un Use Case, debe refinarse hasta
obtener una especificación completa, clara y concisa, en la que quede muy
claro quiénes son los actores, las acciones normales y las acciones
alternativas o escenarios.
La experiencia ha señalado que cuando comenzamos a utilizar esta técnica
de modelaje, es frecuente que se cometan errores como los que, a
continuación, señalamos:
• Describir sólo la interacción del usuario y no la respuesta del
sistema.
Los Use Case deben describir ambos lados de la comunicación,
lo que hace el usuario y lo que hace el sistema en respuesta a las
solicitudes del usuario, por lo que debe definirse qué es lo que
pasa en el sistema cuando el usuario realiza una determinada
acción.
• Describir más atributos que funcionamiento.
No se deben presentar mayores detalles acerca de la forma en que
se presentará la interfaz, ya que se trata de centrar la atención en
lo qué el sistema hace (o hará) y no en cómo lo hace (o hará).
• Hacer descripciones demasiado breves.
Al describir los Use Case, es preferible abundar que quedarse
corto, es importante que se detallen todas las acciones de los actores
y todas las respuestas del sistema.
• Escribir en voz pasiva.
Los Use Case deben mostrar las acciones realizadas por el usuario
y la respuesta del sistema, por lo que será mucho más sencillo y
legible utilizar la voz activa para la descripción de los Use Case.
• Utilizar nombres ambiguos o poco explícitos para los objetos de
interfaz.
Al denominar los objetos de interfaz deben utilizarse nombres
claros que realmente los identifiquen y distingan claramente.
• Omitir cursos de acción alternativos.

189
 Los Use Case deben mostrar tanto el escenario normal, como los
escenarios alternativos.

(Notas)
1
Muchos autores traducen el término Use Case como Caso de Uso, nosotros hemos preferido
mantener la denominación en inglés, con el fin de evitar posibles confusiones.

190