Hace unas semanas hablamos en este blog de una duda que frecuentemente me plantean los alumnos a la hora de modelar diagramas de clases con UML: “Agregación Vs Composición en diagramas de clases. UML” , en esta ocasión vamos a intentar resolver otra consulta que me suelen plantear a la hora de modelar diagramas de casos de uso, se trata de los diferentes tipos de relaciones que podemos encontrar entre casos de uso.
Antes de nada diremos que los casos de uso fueron ideados por Jacobson a principios de los noventa y están inspirados en el concepto de escenario, el cual ya había sido utilizado para describir procesos. Los casos de uso especifican un comportamiento deseado del sistema, representan requisitos funcionales del mismo. Es importante resaltar que describen qué hace el sistema, no cómo lo hace. UML nos dice que: “Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor”. Los casos de uso nos sirven de base para elaborar los aspectos funcionales del pliego de condiciones y nos dan soporte en las etapas de modelado, desarrollo y validación de software.
Elementos de un caso de uso:
- Conjunto de secuencias de acciones, cada secuencia representa un posible comportamiento del sistema.
- Actores, se tratan de los roles que pueden jugar los agentes que interactúan con el sistema. Los roles son jugados por personas, dispositivos, u otros sistemas. Podríamos distinguir entre actores primarios, para los cuales el objetivo del caso de uso es esencial y actores secundarios, que interactúan con el caso de uso, pero cuyo objetivo no es esencial.
- Variantes, son versiones especializadas, un caso de uso que extiende a otro o un caso de uso que incluye a otro
Como veremos a continuación, en los diagramas de casos de uso se muestran: casos de uso (representados en forma de elipses), actores (en forma de personajes) y relaciones (en forma de líneas y/o flechas). UML define cuatro tipos de relaciones en los diagramas de casos de uso:
- Comunicación: Relación (asociación) entre un actor y un caso de uso. El estereotipo de la relación de comunicación es: <<communicate>> aunque generalmente no se estipula ningún nombre, como podemos apreciar en el siguiente ejemplo de comunicación:
- Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de otro en algún lugar de su secuencia. La relación de inclusión sirve para enriquecer un caso de uso con otro y compartir una funcionalidad común entre varios casos de uso, también puede utilizarse para estructurar un caso de uso describiendo sus subfunciones. El caso de uso incluido existe únicamente con ese propósito, ya que no responde a un objetivo de un actor.
Estas relaciones se representan mediante una flecha discontinua con el estereotipo <<include>>. Algunos casos de uso típicos de inclusión son: comprobar, verificar, buscar, validar, autentificar o login… En principio, no deberíamos abusar de este tipo de relación, para no hacer una descomposición funcional del sistema. A partir de UML 1.3 la relación <<include>> reemplazó al denominado <<uses>>.
Veamos un ejemplo de inclusión entre casos de uso:
- Extensión: Un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por este otro caso de uso. En el caso de uso base, la extensión se hace en una serie de puntos concretos y previstos en el momento del diseño, llamados puntos de extensión, los cuáles no son parte del flujo principal. La relación de extensión sirve para modelar: la parte opcional del sistema, un subflujo que sólo se ejecuta bajo ciertas condiciones o varios flujos que se pueden insertar en un punto determinado. Este tipo de relación produce confusión y no debería utilizarse en exceso. Conviene su uso sólo para insertar un nuevo comportamiento no previsto en un caso de uso existente. Estas relaciones se representan mediante una flecha discontinua con el estereotipo <<extend>>.
Veamos un ejemplo de extensión:
En este ejemplo usamos la relación de extensión entre los casos de uso Abrir acción de mejora y Resolver consulta. En este caso tendremos el punto de extensión “resolución retrasada” (en el caso de uso Resolver consulta) debido a que cuando haya pasado un tiempo estipulado por la organización (por ejemplo 3 días laborales) se abrirá una acción de mejora para dejar constancia del retraso y realizar posteriormente las acciones pertinentes, de ahí que digamos que el caso de uso Abrir acción de mejora es una subfunción de uso que puede extender al caso de uso Resolver consulta.
- Especialización y generalización de los casos de uso: Un caso de uso (subcaso) hereda el comportamiento y significado de otro, es decir las relaciones de comunicación, inclusión y extensión del super-caso de uso. En muchas ocasiones este super-caso de uso es abstracto y corresponde a un comportamiento parcial completado en el subcaso de uso. O dicho de otra manera, Los casos de uso “hijo” son una especialización del caso de uso “padre”. En la medida de lo posible debería evitarse puesto que produce cierta confusión en algunas ocasiones.
Veamos un ejemplo de generalización:
Como podemos ver en este último ejemplo también pueden existir vínculos de generalización o herencia entre actores. Los actores especializados (Abogado y Psicólogo) heredan los casos de uso del actor general (Profesional). La punta de flecha apunta al actor más general. Hay que reseñar que los actores especializados pueden tener otros casos de uso propios que no estarán disponibles para los demás actores. Este tipo de herencia entre actores si que se usa frecuentemente puesto que nos simplifica considerablemente el diagrama, nos ahorra un número importante de relaciones de comunicación entre actores y casos de uso y nos sirve para esclarecer visualmente la jerarquía entre actores del sistema.
Si te interesan todos estos temas relacionados con la gestión y el desarrollo de software para escritorio, web y móvil. SEAS imparte formación para que puedas ampliar tus conocimientos sobre desarrollo de software. Puedes ver formación como el Máster en Gestión y Desarrollo de Aplicaciones Multiplataforma, o el Curso de UML.
SEAS es el centro de formación online del Grupo San Valero, especializado en el ámbito técnico, industrial y de empresa. Visita www.seas.es para consultar nuestra oferta formativa de cursos y másteres. Formación profesional para el empleo de calidad y accesible para todos.
Shalin
13 octubre, 2014 at 12:16 pmThis tute is awesome. Isn’t there any other way to draw pretty usecases. Software free and easy to use?
Yan David Burbano Amariles
28 octubre, 2014 at 6:10 pmMuy bien explicado, solo me quedo una duda en como aplicar en un caso de uso la relación de extensión y de inclusión. Los suelo confundir. Si tienes otro ejemplo te agradecería mucho, pero debo decir que me resolvió muchas inquietudes.
Gracias!
—
David Amariles
Ingeniero de Sistemas/Diseñador Web
http://www.davidamariles.com
Stiven
10 marzo, 2016 at 6:13 pmObservación: la relación de comunicación que se da entre un actor(es) y un caso(s) de uso no se representa mediante una flecha sino mediante un linea simple.
kevin
16 marzo, 2017 at 2:03 amquien me podria ayudar en los propósito primarios de los caso de uso son?
NADIA
10 septiembre, 2017 at 11:46 pmGeneralización o especialización se da SOLO entre ACTORES o SOLO entre CASOS DE USO, lo cual es viable. El INCLUDE no me quedó muy claro.
Raul Segovia reyes
31 enero, 2018 at 11:36 pmhola alguien tiene estos ejemplos resueltos?
Complete el siguiente diagrama de estados UML de acuerdo con la especificación textual que
aparece a continuación, proporcionando el texto correspondiente a la etiqueta de las
transiciones de máquina de estados t1 a t7 y para las acciones a1 y a2. Se proporciona el
texto de la transición inicial (indicando, a la vez, la sintaxis de la asignación que debe usar para
el lenguaje de acciones).
Su solución debe usar los siguientes eventos de disparo (o señales de activación):
tirar_anilla, tocar_suelo
las siguientes variables boleanas:
fallado1, fallado2, abrir1, abrir2
y las siguientes invocaciones de métodos:
alucinar(), gritar(String grito), expirar().
Un paracaidista se tira desde un avión, momento a partir del cual está en caída libre. Entonces
puede tirar de la anilla para abrir el paracaídas principal (nota: pero no la que abre el
paracaídas de emergencia). Al hacerlo, pueden pasar dos cosas: el paracaídas se abre, en cuyo
caso grita “sí” y empieza a caer despacio, o no se abre, en cuyo caso sigue en caída libre. Si no
se abre el paracaídas principal (nota: y no en otro caso), puede intentar abrir el paracaídas de
emergencia con los dos mismos posibles resultados. Si se mantiene en caída libre un tiempo
mayor que max_fall_time (nota: independientemente de que haya tratado de abrir cero,
uno o dos paracaídas), la caída se convierte en una caída mortal y ve pasar delante de él toda
su vida. En todos los casos, al final llega al suelo, gritando “¡aaah!” en caso de caída con
paracaídas y expirando en caso de caída mortal.
caída_libre
caída despacio
entry / a1
caída mortal
do / a2
/ fallado1 := false, fallado2:= false
abrir1
t1
abrir2
[true] [true]
[false] [false]
t2 t3
t4 t5
t6 t7Software de Comunicaciones. Ejemplos de UML Departamento de Ingeniería Telemática Universidad Carlos III de Madrid
Problema del examen de septiembre de 2007
Se quiere desarrollar un sistema de información para las universidades españolas según la
descripción siguiente.
Una Universidad se caracteriza mediante su nombre y la ciudad donde se sitúa. A una
Universidad están vinculados dos tipos de Persona: Trabajadores, que la Universidad
emplea, y Estudiantes, que estudian en la Universidad. Cada Persona tiene un DNI y un
nombre.
Los Trabajadores pertenecen a dos grupos: PDI y PAS. Cada Trabajador tiene asociada una
fecha de inicio de su contrato. Cada miembro del PDI también tiene una categoría, mientras
que cada miembro del PAS tiene un puesto. Los miembros del PDI pueden o no ser Doctores.
Las actividades que desarrolla el PDI son investigar y enseñar, mientras que la actividad que
desarrolla el PAS es administrar.
Cada Universidad se compone de un conjunto de Departamentos, cada uno de los cuales
tiene un nombre y un conjunto de Trabajadores adscrito. Un Trabajador no puede estar
adscrito a más de un Departamento. Un PDI está adscrito obligatoriamente a un
Departamento, mientras que un PAS, no. Cada Departamento está dirigido por un Doctor.
Un Estudiante puede ser bien Estudiante de grado, de una determinada titulación, bien
Estudiante de doctorado, de un determinado programa de doctorado. Un Estudiante de
grado puede también colaborar con un Departamento como becario y puede realizar un PFC
dirigido por un miembro del PDI. Un Estudiante de doctorado realiza una tesis dirigida por
un Doctor.
Puede suponer que un Estudiante no puede estudiar en más de una Universidad y que un
Trabajador no puede ser empleado por más de una Universidad.
Proporcione un modelo de esta descripción en forma de un diagrama de clases UML utilizando
para nombres de clases únicamente las palabras que aparecen en negrita en la descripción
anterior. Las palabras que aparecen en cursiva proporcionan pistas para la definición de los
otros elementos del modelo. No hace falta proporcionar información de tipado para las
propiedades que pueda definir.
Para más puntuación, añada a su modelo los elementos necesarios para tomar en cuenta lo
siguiente:
• una Persona puede ser a la vez Trabajador y Estudiante,
• un Estudiante no puede ser a la vez Estudiante de grado y Estudiante de doctorado,
• los únicos tipos de Trabajador que existen son PDI y PAS,
• un Trabajador no puede ser a la vez PDI y PAS.Software de Comunicaciones. Ejemplos de UML Departamento de Ingeniería Telemática Universidad Carlos III de Madrid
Problema del examen de septiembre de 2008
(a) Los diagramas UML de la Figura 1 constituyen un modelo simplificado de un cajero
conectado a un banco. Constan de un diagrama de clases con dos clases, y dos diagramas
de estado cada uno de los cuales describe el comportamiento de una de estas clases.
Estudie los diagramas y responda a continuación a las siguientes preguntas:
(i) (0,3 puntos) ¿Cuál es el significado de los rectángulos verticales negros del diagrama
de estados de la clase Bank? ¿Qué comportamiento del banco describe la transición
que va desde el estado CardValid hacia el rectángulo negro situado más abajo a la
derecha del diagrama?.
(ii) (0,2 puntos) ¿Cuál es el significado de los diamantes situados dentro del estado
Verifying de la clase Bank? ¿Cómo es que no aparece guarda alguna en ninguna de
las transiciones de salida del diamante situado más abajo?
(iii) (0,2 puntos) ¿Cuál es el significado de la línea discontinua situada dentro del estado
Verifying del diagrama de estados de la clase Bank, y cuál es la diferencia entre
este tipo de estado y un estado como Giving Money del diagrama de estados de la
clase ATM?
(iv) (0,6 puntos) Describa brevemente cada una de las partes que pueden aparecer en la
etiqueta de una transición de un diagrama de estados UML. ¿Cuál es el significado del
texto que empieza por el carácter “^” situado en las etiquetas de algunas de las
transiciones de los dos diagramas de estado de la Figura 1? Explique qué representan
cada una de las dos transiciones del diagrama de estados de la clase ATM cuya etiqueta
contiene el texto ^bank, y cada una de las tres transiciones del diagrama de estados
de la clase Bank cuya etiqueta contiene el texto ^atm [Pista: mire el diagrama de
clases].
(b) (0,7 puntos) Ahora proporcione un diagrama de secuencias UML que muestre la
comunicación entre un objeto que desempeñe el rol atm y un objeto que desempeñe el rol
bank correspondiente. [Pistas: el diagrama debería reflejar si la comunicación es síncrona
o asíncrona; se sugiere usar operadores de interacción].
Problema del examen de enero de 2009
Estudie el diagrama de clases UML que aparece en la Figura 1.
(i) Describa en lenguaje natural el dominio modelado por esta especificación UML; si no
tiene tiempo para proporcionar una descripción exhaustiva, al menos ilustre cada uno
de los distintos elementos sintácticos que en ella aparece.
(ii) ¿Qué otra información podría haberse proporcionado dentro de las cajas?
(iii) ¿Qué tiene de particular la caja que contiene el texto “IntervaloTiempo”?«signal» done
verifyPIN()
«signal» PINVerified
«signal» abort
«signal» reenterPIN
1
atm
1
bank Bank
int maxNumIncorrect = 2
int numIncorrect = 0
boolean cardValid = true
ATM
(a) Class diagram
ReturningCard
Verification AmountEntry
CardEntry
Counting
Dispensing
PINEntry
Giving Money
PINVerified
abort
/ ^bank.done
/ ^bank.verifyPIN()
reenterPIN
(d) State machine diagram for class ATM
VerifyingCard CardValid
Idle
PINCorrect
entry / numIncorrect = 0
PINIncorrect
VerifyingPIN
[else] / ^atm.abort
[cardValid]
[else] / cardValid = false; ^atm.abort
/ ^atm.PINVerified
[numIncorrect < maxNumIncorrect]
/ numIncorrect++; ^atm.reenterPIN
done
Verifying
verifyPIN()
(e) State machine diagram for class Bank
Fig. 1. UML model of an ATM
Kevin S
7 septiembre, 2022 at 5:52 pmcreo que ya tienes claro la diferencia entre extensión e inclusión, pero la simple diferencia entre cada uno es que la extensión es un extra que no es obligatorio por el usuario o cliente y la inclusión es algo que incluye desde el inicio, pero ambos son para explicar algo nuevo a incluir en el caso de uso.