SESIÓN VI

Análisis y Diseño de Sistemas PDSD – IV

ELEMENTOS DEL DIAGRAMA DE CASO DE USO

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de

diagrama de comportamiento.
El Lenguaje de Modelado Unificado define una notación gráfica para representar casos
de uso llamada “modelo de casos de uso”. UML no define estándares para que el formato
escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica
define la naturaleza de un caso de uso; sin embargo, una notación gráfica puede solo dar
una vista general simple de un caso de uso o un conjunto de casos de uso.
Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras
los dos conceptos están relacionados, los casos de uso son mucho más detallados que los
diagramas de casos de uso.
Los elementos del diagrama de caso de uso son los siguientes:
➢ Actor.
➢ Caso de uso.
➢ Relaciones (entre actores, entre caso de usos, entre actor y caso de uso).

Diagramas de Casos de Uso UML

El estándar de Lenguaje de Modelado Unificado 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

Ing. Billy Roger Socla Mezarino Página 1

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV
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.
El valor verdadero de un caso de uso reposa en dos áreas:
➢ La descripción escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito de negocio. Esta descripción se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios humanos u
otros sistemas.
➢ La posición o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organización, un conjunto de casos de uso coherentes, consistentes
promueve una imagen fácil del comportamiento del sistema, un entendimiento
común entre el cliente/propietario/usuario y el equipo de desarrollo.
Es práctica común crear especificaciones suplementarias para capturar detalles de
requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos
de esos temas incluyen rendimiento, temas de escalabilidad/gestión, o cumplimiento de
estándares.

El diagrama describe la funcionalidad de un Sistema Restaurante muy simple. Los casos

de uso están representados por elipses y los actores están representados por las figuras
humanas.
El actor Crítico de comidas puede:

Ing. Billy Roger Socla Mezarino Página 2

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV
- Probar la comida.
- Pagar la comida.
- Beber vino.
Sólo el actor Chef puede Preparar la comida. Podría ser que ambos Patrón y Cajero estén
involucrados en el caso de uso Pagar la comida. El marco define los límites del sistema
Restaurante, por ejemplo, los casos de uso se muestran como parte del sistema que está
siendo modelado, los actores no.
La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción
es esencial para una descripción coherente del comportamiento deseado, quizás los
límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la
interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin
embargo, los actores son una especie de rol, un usuario humano u otra entidad externa
puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma
persona.

ACTOR ¿Qué es?

Ente que interactúa con el sistema a desarrollar. Puede ser una persona, un dispositivo
(hardware), software.
Gráficamente, se representa con:

Es importante indicar que un actor y un usuario no son la misma cosa. Un usuario

normal puede jugar un número de papeles diferentes cuando utiliza un sistema, por lo
tanto, un actor representa una clase de entidades externas (a veces, pero no siempre
personas) que lleva cabo un papel.
Como ejemplo, considerar un operador de una máquina (un usuario) que interactúa con
el ordenador central para un elemento de fabricación que contiene un número de robots y
máquinas bajo control numérico.
Después de una revisión cuidadosa de los requisitos, el software del computador central
requiere cuatro modelos diferentes (papeles) de interacción: modo programación, modo
prueba, modo monitorización y modo investigación.

Ing. Billy Roger Socla Mezarino Página 3

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV
Además, se pueden definir cuatro actores:
➢ Programador.
➢ Probador.
➢ Supervisor.
➢ investigador.
En algunos casos, el operador de la máquina puede realizar todos los papeles.

CASO DE USO
Es una descripción de los pasos o las actividades que deberán realizarse para llevar a
cabo algún proceso.

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

¿Hay relaciones entre actores?

Se puede definir categorías generales de actores (por ejemplo, cliente) y especializarlos
(como ClienteComercial) a través de relaciones de generalización.

Ing. Billy Roger Socla Mezarino Página 4

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV
Relación include (use)
Es una forma de interacció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 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.
Son asociaciones entre casos de uso. Normalmente las asociaciones son entre el actor y
el caso de uso.
Para saber cuándo hay que utilizar uses y cuando extends aplicar las siguientes reglas:
Usar extends cuando se describa una variación en un comportamiento normal.
Usar uses cuando se produzca una repetición en dos o más casos de uso separados y se
quiera evitar.
UML establece la relación uses con el nombre de includes.

Relación extensión (Extend)

Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro.
Esta relación indica que el comportamiento del 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. La
extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener
extensión o inclusión.
"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."

Relación Generalizació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 solida 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

Ing. Billy Roger Socla Mezarino Página 5

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV
factorizar comportamientos comunes, restricciones al caso de uso general, describirlos
una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.
"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 intensión y
extensión."

Ejemplos de diagramas de caso de uso

Antes de hacer un caso de uso es necesario tratar de entender los requerimientos del
sistema. Trate de expresar lo que el sistema debe hacer:
El sistema debe permitir a los usuarios registrarse.
El administrador debe poder validar las peticiones de registro antes de que los usuarios
puedan publicar nuevos mensajes.
En base a esto, trate de responder las preguntas:
¿Cuáles son las tareas del/los actores involucrados?
¿Qué datos debe el actor crear, guardar, modificar, destruir, leer?
¿Debe el actor informar al sistema de cambios externos ocurridos?
¿Debe el sistema informar al actor de cambios internos?

Ing. Billy Roger Socla Mezarino Página 6

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV

Ing. Billy Roger Socla Mezarino Página 7

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV

Ing. Billy Roger Socla Mezarino Página 8

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV

Ing. Billy Roger Socla Mezarino Página 9

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV

Algunas Reglas de Estilo

- Cada actor y caso de uso debe tener un nombre único.
- Los actores deben tener nombres y/o iconos representativos. Los nombres de los
actores deben representar roles.
- El nombre de un caso de uso debe indicar acción y debe ser claro y conciso.

- Mantener todos los casos de uso de un diagrama al mismo nivel de abstracción.

- Evitar el cruce de líneas (En general, mantenga el diagrama ordenado).
- Evite el uso complejo de relaciones de extensión, especialización e inclusión (No
más de tres niveles).
- Narrar el flujo de eventos usando voz activa, en tiempo presente y desde la
perspectiva del actor:

Ing. Billy Roger Socla Mezarino Página 10

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV
- Exprese cada paso del flujo usando la forma llamada y respuesta (reflejar el hecho
de que el actor ejecuta algo y el sistema responde a la solicitud del actor):
“El actor introduce su nombre de usuario y su contraseña, y el sistema verifica si
los datos concuerdan con lo que está almacenado en la base de datos”
- El caso de uso que se describe debe expresar un solo requisito funcional (No trate de
expresar más de un requisito funcional en el mismo caso de uso)

Una Mejor Representación

Ing. Billy Roger Socla Mezarino Página 11

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV
Flujo de Eventos:
Flujo Normal:
1. El actor selecciona la opción para listar las Solicitudes Pendientes.
2. El sistema presenta una lista de todas las Solicitudes Pendientes (tanto de Registro
de Usuario como de Publicación de Mensaje) junto con una opción para ver más
detalles sobre una solicitud en particular.
Flujo Alternativo:
En caso de un Registro de Usuario:
3A.- El usuario selecciona una solicitud.
4A.- Si se trata de una solicitud de Registro de Usuario el sistema le envía al caso de uso
Procesar Solicitud de Registro (CU-06).

En caso de una Publicación de Mensaje:

3B.- El usuario selecciona una solicitud.
4B.- Si se trata de una solicitud de Publicación de Mensaje el sistema le envía al caso de
uso Procesar Publicación de Mensaje (CU-07).

Ing. Billy Roger Socla Mezarino Página 12

 SESIÓN VI
Análisis y Diseño de Sistemas PDSD – IV
¿Qué Modelan los Diagramas de Casos de Usos?

Ing. Billy Roger Socla Mezarino Página 13