Este documento presenta una introducción a los diagramas de casos de uso en UML. Explica conceptos clave como casos de uso, actores, relaciones entre casos de uso y actores, y cómo crear y describir casos de uso. También incluye ejemplos y errores comunes al modelar casos de uso. El objetivo es proporcionar una guía básica sobre cómo modelar el comportamiento de un sistema desde la perspectiva de los usuarios a través de diagramas de casos de uso.

1. 1

2. Diagramas de Casos de Uso
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Mayo, 2021
Loja, Ecuador

3. 3
1. Diagramas Estructurales

Casos de Uso

Diagrama de Casos de Uso

Notación de un Caso de Uso

Frontera del Sistema

Actor

Asociaciones

Relaciones entre actores

Relaciones entre casos de uso

Ejemplos

Errores comunes
Agenda

4. 4
Casos de Uso
¿Qué es un caso de uso?
Los Casos de Uso (CU) describen las acciones y reacciones el
comportamiento de un sistema desde el punto de vista del usuario
¿Para qué se utiliza?
Los UC son descripciones de la funcionalidad del sistema independientes de
la implementación
¿Para quién está orientado?
Están basado en el lenguaje natural, es decir, son accesibles por los usuarios

5. 5

El diagrama de UC es el único elemento de UML que describe el sistema
desde el punto de vista del usuario

Entender el punto de vista del usuario es fundamental para crear sistemas:

Que cumplan con los requerimientos de quién lo va a utilizar

Sea sencillo de trabajar con ellos

Los diagramas de UC son fundamentales en la fase de análisis de un
sistema y diseño preliminar

La forma en que los usuarios utilizan un sistema es lo que se debe diseñar e
implementar
Diagrama de Casos de Uso

6. 6

Dada su flexibilidad, ayudan en diferentes fases del proceso de desarrollo:

Ante posibles actualizaciones, el diagrama de UC puede servir como base
para la captación de nuevos requisitos

Corrección de errores

Es una herramienta que permite que los usuarios potenciales hablen de un
sistema desde su propio punto de vista

Descripción gráfica de los diferentes CU del sistema, así como las
relaciones entre los mismos
Diagramas de Casos de Uso

7. 7
El diagrama de UC no cubre la estructura interna y la implementación real de
un caso de uso
El diagrama de UC también se pueden utilizar para documentar la
funcionalidad que ofrece un sistema
Diagramas de Casos de Uso

8. 8
Las diferentes alternativas de notación de UC son:
Notación de un Caso de Uso

9. 9
Caso de Uso. Indica un proceso dentro del propio sistema
En el diagrama de UC solo se indica el nombre del UC, así como sus
relaciones con otros UC o actores
Una descripción más detallada se realiza en un documento aparte
Notación de un Caso de Uso

10. 10
El conjunto de todos los casos de uso
juntos describe la funcionalidad que
proporciona un sistema de software
Los casos de uso generalmente se agrupan
dentro de un rectángulo
Este rectángulo simboliza los límites del
sistema que se describirá
Frontera del sistema
Nombre del sistema / subsistema

11. 11
Subsistema. Se
pueden agrupar varios
Casos de Uso en
subsistemas
Representan diferentes
sistemas semi-
independientes en un
ámbito funcional
dentro del sistema
general
Frontera del sistema

12. 12
Representa el rol de un usuario del sistema. Todo aquel
elemento que interactúa con el sistema
Tipos de actores:

Principales: personas que usan el sistema

Secundarios: personas que mantienen o administran el
sistema

Material externo: dispositivos materiales
imprescindibles que forman parte del ámbito de la
aplicación y deben ser utilizados

Otros sistemas: otros entornos con los que el sistema
interactúa
Actor

13. 13
Estas tres alternativas de notación son todas igualmente válidas.
Los actores pueden ser humanos (por ejemplo, estudiante o profesor) o
no humanos (por ejemplo, servidor de correo electrónico).
Actor

14. 14
Un actor principal obtiene un beneficio real de la ejecución del caso de
uso
El actor secundario no recibe ningún beneficio directo de la ejecución del
caso de uso
Gráficamente, no hay diferenciación entre actores primarios y
secundarios, entre actores activos y pasivos, y entre actores humanos y
no humanos
Actor

15. 15
Todo actor puede:

Iniciar una secuencia de Casos de Uso. Parte izquierda del diagrama

Ser objeto de una secuencia de Casos de Uso. Parte derecha del
diagrama
Puede iniciar o ser objeto de varios casos de uso
Un actor es un elemento externo al sistema, mientras que los Casos de Uso
son parte del mismo
Actor

16. 16
Roles
Los actores no representan a un usuario específico
Representan roles que adoptan los usuarios
Si un usuario ha adoptado el rol respectivo, este usuario está autorizado
para ejecutar los casos de uso asociados con este rol
Actor

17. 17
• Relación: cualquier tipo de unión entre elementos del diagrama. Actor-Caso o
Caso-Caso
• Conectamos a los actores con casos de uso mediante líneas continuas sin explicar
esto con más detalle
• Asociación: es siempre binaria, lo que significa que siempre se especifica entre
un caso de uso y un acto
• Comunicación: relación que indica que un Actor o Caso de Uso origen utiliza un
Caso de Uso destino
Asociaciones

18. 18
• Se pueden especificar multiplicidades para los fines de asociación
• Si se especifica una multiplicidad mayor que 1 para el final de la asociación del
actor, esto significa que más de una instancia de un actor está involucrada en la
ejecución del caso de uso
Asociaciones

19. 19
• Los actores a menudo tienen propiedades comunes
y varios actores pueden utilizar algunos casos de
uso
• Los actores pueden representarse en una relación
de herencia (generalización) entre sí
• La generalización expresa una relación "es un"
• Está representado con una línea del sub-actor al
super-actor con una gran punta de flecha triangular
en el extremo del super-actor
Relaciones entre actores

20. 20
Relaciones entre actores

21. 21
Relaciones entre actores
• Si no hay una instancia de un
actor, este actor se puede
etiquetar con la palabra clave
{abstract}
• El uso de actores abstractos
solo tiene sentido en el
contexto de una relación de
herencia

22. 22
Existen relaciones de «inclusión», relaciones de «extensión» y
generalizaciones de casos de uso.
Relaciones entre casos de uso

23. 23
Inclusión. Utilizado cuando una instancia del UC origen incluye también
el comportamiento descrito por el UC destino
Utilizado para UC más complejos, que requieren la utilización de otros
UC.
No puede utilizarse en la relación Actor-Caso de Uso
Relaciones entre casos de uso

24. 24
Inclusión. el comportamiento de Destino se integra en el comportamiento
de Origen
El UC base siempre requiere el comportamiento del UC incluido para
poder ofrecer su funcionalidad
Por el contrario, el UC incluido se puede ejecutar por sí solo
Relaciones entre casos de uso

25. 25
Relaciones entre casos de uso

26. 26
Extensión. El Caso de Uso origen extiende el comportamiento del Caso
de Uso destino
Es posible volver a utilizar un caso de uso agregándole algunos pasos
a un caso de uso existente
Tanto la inclusión como la extensión se hace en puntos indicados y de
manera específica dentro de una secuencia de casos de uso. No se permite
en la relación Actor-Caso de Uso
Relaciones entre casos de uso

27. 27
Se puede especificar una condición
que debe cumplirse para que el caso
de uso base inserte el
comportamiento del caso de uso
extendido para cada relación
«extender»
La condición se especifica, entre
corchetes, en una nota que está
conectada con la correspondiente
relación «extender»
Relaciones entre casos de uso

28. 28
Puntos de extensión, puede definir
el punto en el que se debe insertar el
comportamiento de los casos de uso
extendidos en el caso de uso base
Los puntos de extensión se escriben
directamente dentro del caso de uso
Relaciones entre casos de uso

29. 29
Herencia. El Caso de Uso origen hereda la especificación del Caso de Uso
destino y posiblemente la modifica y/o amplía
Similar al concepto de herencia utilizado en programación
Relaciones entre casos de uso

30. 30
Relaciones entre casos de uso

31. 31
Ejemplo 1

32. 32
• El ejemplo muestra el sistema
de Administración de
estudiantes
• Ofrece tres casos de uso: (1)
Consultar datos de estudiantes,
(2) Emitir certificado y (3)
Anunciar examen
• Estos casos de uso pueden ser
activados por el actor Professor
Ejemplo 2

33. 33
Ejemplo 3
•
Un actor siempre está claramente fuera del sistema
•
Un usuario nunca es parte del sistema y, por lo tanto, nunca se
implementa

34. 34
Dado un sistema online de pedidos a restaurantes, se pide realizar el
diagrama de casos de uso del mismo que refleje el siguiente
comportamiento:

El cliente puede buscar una determinada comida

El cliente puede solicitar un encargo al restaurante de su elección

Para poder utilizar el servicio se necesita una cuenta de usuario, por lo
que la operación de encargar comida debe ser validada previamente

Los restaurantes pueden visualizar los pedidos que tienen pendientes
para poder atenderlos
Ejemplo 4

35. 35
Casos de Uso
Ejemplo 4

36. 36
Se debe diseñar un sistema de compra de videojuegos, en el cual a los
usuarios se les permite realizar las siguientes acciones:
Buscar videojuegos. La búsqueda cambia dependiendo de la categoría
del videojuego, que son:

Acción

Deportes

Terror
Comprar un videojuego concreto
Todas las operaciones anteriores contrastan con base de datos
La compra de un videojuego realiza un proceso de validación
Ejemplo 5

37. 37
Ejemplo 5

38. 38
Errores Comunes
Incorrect excerpt of a use case diagram:
modeling processes

39. 39
Errores Comunes
Incorrect excerpt of a use case diagram:
incorrect system boundaries

40. 40
Errores Comunes
Incorrect excerpt of a use case diagram:
mixing abstraction levels

41. 41
Errores Comunes
Incorrect excerpt of a use case diagram:
functional decomposition

42. 42
Errores Comunes
Incorrect excerpt of a use case diagram: incorrect associations

43. 43
Errores Comunes
Modeling redundant use cases

44. 44
1.Para identificar los actores que aparecen en un diagrama de casos de
uso, debe responder las siguientes preguntas:
•
¿Quién usa los principales casos de uso?
•
¿Quién necesita apoyo para su trabajo diario?
•
¿Quién es responsable de la administración del sistema?
•
¿Cuáles son los dispositivos / sistemas (software) externos con los que
debe comunicarse el sistema?
•
¿Quién tiene interés en los resultados del sistema?
Crear un diagrama de casos de uso

45. 45
1.Una vez que conozca a los actores, puede derivar los casos de uso
haciendo las siguientes preguntas sobre los actores:
•
¿Cuáles son las principales tareas que debe realizar un actor?
•
¿Un actor desea consultar o incluso modificar la información
contenida en el sistema?
•
¿Un actor desea informar al sistema sobre cambios en otros sistemas?
•
¿Se debe informar a un actor sobre eventos inesperados dentro del
sistema?
Crear un diagrama de casos de uso

46. 46
La descripción del Caso de Uso comprende:

Objetivo del caso de uso

Actores y acciones

El inicio: cuándo y qué actor lo produce

El fin: cuándo se produce y qué valor devuelve

Definir la interacción actor-caso de uso (paso de mensajes)

Cronología y origen de las interacciones

Repeticiones de comportamiento (bucles o iteraciones)

Situaciones opcionales o alternativas
Describir Casos de Uso

47. 47

48. 48
Cŕeditos
• Transparencias basadas por:
• Christopher Exposito Izquierdo & AiRam Exposito Marquez & otros
• Maria-Isabel, Sanchez Segura & Arturo, Mora-Soto

49. Networking académico:
Correo electrónico: rguaman@unl.edu.ec
Twitter: @rene5254
SlideShare: https://es.slideshare.net/rene5254
49
Gracias