Informática

Tipos de relaciones en diagramas de casos de uso. UML.

18 marzo, 2013
uml368

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:

Ejemplo de inclusión

 

  • 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.


SEAS Estudios Superiores Abiertos. Solicita información.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.

Puedes compartir este artículo en:
  • Reply
    Shalin
    13 octubre, 2014 at 12:16 pm

    This tute is awesome. Isn’t there any other way to draw pretty usecases. Software free and easy to use?

  • Reply
    Yan David Burbano Amariles
    28 octubre, 2014 at 6:10 pm

    Muy 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

  • Reply
    Stiven
    10 marzo, 2016 at 6:13 pm

    Observació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.

  • Reply
    kevin
    16 marzo, 2017 at 2:03 am

    quien me podria ayudar en los propósito primarios de los caso de uso son?

  • Reply
    NADIA
    10 septiembre, 2017 at 11:46 pm

    Generalizació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.

  • Reply
    Raul Segovia reyes
    31 enero, 2018 at 11:36 pm

    hola 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

  • Reply
    Kevin S
    7 septiembre, 2022 at 5:52 pm

    creo 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.

Deja un comentario

Información básica acerca de cómo protegemos tus datos conforme al Reglamento General de Protección de Datos (Reglamento UE 2016/679) y en la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales

De conformidad con lo establecido en el Reglamento General de Protección de Datos, te informamos de:

- Quien es el responsable del tratamiento: SEAS, Estudios Superiores Abiertos S.A.U con NIF A-50973098, dirección en C/ Violeta Parra nº 9 – 50015 Zaragoza y teléfono 976.700.660.

- Cuál es el fin del tratamiento: Gestión y control de los comentarios del blog de SEAS. 

- En que basamos la legitimación: En tu consentimiento.

- La comunicación de los datos: No se comunicarán tus datos a terceros.

- Los criterios de conservación de los datos: Se conservarán mientras exista interés mutuo para mantener el fin del tratamiento o por obligación legal. Cuando dejen de ser necesarios, procederemos a su destrucción.

- Los derechos que te asisten: (i) Derecho de acceso, rectificación, portabilidad y supresión de sus datos y a la limitación u oposición al tratamiento, (ii) derecho a retirar el consentimiento en cualquier momento y (iii) derecho a presentar una reclamación ante la autoridad de control (AEPD).

- Los datos de contacto para ejercer tus derechos: SEAS, Estudios Superiores Abiertos S.A.U. C/ Violeta Parra nº 9 –
50015 Zaragoza (España) o través de correo electrónico a lopd@estudiosabiertos.com

- También puedes ponerte en contacto con nuestro Delegado de Protección de Datos en dpd@estudiosabiertos.com

Información adicional: Puedes consultar la información adicional y detallada sobre nuestra política de privacidad