Modelado de

Casos de Uso

Diseño de Sistemas

Nehil Muñoz Casildo

 Modelado de Casos de Uso

 Un caso de uso especifica un comportamiento deseado del

sistema.
 Representan los requisitos funcionales del sistema.
“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.”
(Definición en UML)

 Describen qué hace el sistema, no cómo lo hace.

2
 Que es un Caso de Uso

Un caso de uso es un conjunto de escenarios que

tienen una meta de usuario en común
Martin Fowler
Caso de Uso: Es una descripción de un proceso
fin-a-fin, relativamente largo, que incluye varias
etapas o transacciones
Es una manera específica de utilizar el sistema,
es una historia que describe un uso particular del
sistema
Es la imagen de una funcionalidad del sistema,
desencadenada en respuesta al estímulo de un
actor o rol externo
Casos de Uso

¿Escenario?
 Casos de Uso
(¿Qué es un escenario?)

¿Escenario?

Escenario: Es una secuencia de acciones e

interacciones (pasos) entre los usuarios (actores)
y el sistema
...por ejemplo:
“El usuario introduce su nombre de usuario y su
contraseña. El sistema verifica la validez del nombre de
usuario y de la contraseña y permite al usuario el acceso
al sistema. El sistema muestra la pantalla principal del
sistema. El usuario selecciona la opción de añadir nuevo
empleado. El sistema muestra...”
 Casos de Uso
(¿Qué es un actor?)

¿Actor, Rol?

Un actor representa el rol jugado por una persona

o cosa que actúa con el sistema.

“Cliente, Administrador, Usuario no Registrado

(Autenticado), Usuario Registrado (Autenticado), Jefe de
Compras, Jefe de Personal, Moderador, Jefe de
Departamento, Obrero de Planta, Supervisor...”

¿Actor o Rol?: Sería mejor usar la palabra rol,

pero algunos piensan que “Actor” fue usado
debido a una mala traducción del Sueco
 Casos de Uso
(¿Qué es un caso de uso?)

NOTA: NO TODOS los

interesados en el
sistema (stakeholders)
son actores, sólo son
actores aquellos que
utilizarán el sistema
 Casos de Uso -Observaciones

Actualmente, mucha gente considera que los casos

de uso son de vital importancia en los proyectos de
software (Procesos Guiados por Casos de Uso)

Describen bajo la forma de acciones y reacciones el

comportamiento de un sistema desde el punto de
vista de un usuario

Se puede considerar que hasta cierto punto, cada

caso de uso es independiente de los demás

Permiten definir los límites del sistema y las

relaciones entre el sistema y su entorno
(MUY IMPORTANTE)
 Casos de Uso
(Algunas Características)

Un caso de uso NO es un diagrama, NO es un

símbolo dentro de un diagrama...
...es una forma de describir un escenario de
interacción usuario sistema...
...los diagramas vienen después (o antes) y son
una forma de tener una visión general de los
casos de uso, sus relaciones con los actores y
con otros casos de uso
 Modelado de Casos de Uso

 Partes de un caso de uso (cdu)

 Conjunto de secuencias de acciones; cada
secuencia representa un posible comportamiento del
sistema
 Actores, roles que pueden jugar los usuarios
 Variantes: versiones especializadas, un cdu que
extiende a otro o un cdu que incluye a otro
 Un caso de uso realiza un trabajo tangible.

10
 Emisor Centralita Receptor

listo( )

tono

marcar_numero

Escenario tono_sonando
timbre_sonando

telefono_cogido
para_tono

para_timbre

Los Casos de uso son ideados por Jacobson a principios de los noventa y
están inspirados en los Escenarios utilizados para describir procesos.
Modelo de Casos de Uso

¿Cómo se
desarrolla un
modelo de
Casos de Uso?

12
 Diagrama de Casos de Usos
(Requerimientos: ¿Qué debe hacer el
sistema?)
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:

¿Cuales son las tareas ¿Que datos debe el actor

del/los actores crear, guardar, modificar,
involucrados? destruir, leer?

¿Debe el actor informar al ¿Debe el el sistema

sistema de cambios informar al actor de
externos ocurridos? cambios internos?
13
 Diagrama de Casos de Usos

Límites del
Sistema

Generalización /
Caso de Uso Especialización
de Actores

Asociación
Caso de Uso
/ Actor

Colaboración Actor
entre casos
de uso
 Diagrama de Casos de Usos

Usado para
compartir
comportamiento
común entre
varios casos de
uso

Usado para
modelar por
separado el
Usado para comportamiento
modelar excepcional (o
relaciones de adicional) del
Generalización / caso de uso
Especialización base
entre casos de
uso
 Tipos de Actores

Un actor representa un conjunto coherente de roles que

juegan los usuarios de los casos de uso al interaccionar
con el sistema.

 Roles jugados por personas, dispositivos, u otros

sistemas.
 El tiempo puede ser un actor (“procesos iniciados
automáticamente por el sistema”).
 No forman parte del sistema.

16
 Actores

 Un usuario puede jugar diferentes roles.

 En la realización de un caso de uso pueden intervenir
diferentes actores.
 Un actor puede intervenir en varios casos de uso.
 Identificar casos de uso mediante actores y eventos
externos.
 Un actor necesita el caso de uso y/o participa en él.

17
 Actores

 Dos tipos de actores:

 Principal:
Requiere al sistema el cumplimiento de un
objetivo.

 Secundarios:
El sistema necesita de ellos para satisfacer un
objetivo.

18
 Propiedades de los casos de uso

 Son iniciados por un actor con un objetivo en mente y es

completado con éxito cuando el sistema lo satisface.
 Puede incluir secuencias alternativas que llevan al éxito
y fracaso en la consecución del objetivo.
 El sistema es considerado como una “caja negra” y las
interacciones se perciben desde fuera.
 El conjunto completo de casos de uso especifica todas las
posibles formas de usar el sistema, esto es el
comportamiento requerido.

19
 Descripción de un caso de uso

 Son documentos de texto, no son diagramas.

 El modelado de casos de uso consiste en escribir texto,
no en dibujar diagramas.
 Describir el flujo de eventos
 Texto estructurado informal
 Texto estructurado formal (plantillas)
 Pseudocódigo
 Notaciones gráficas: diagramas de secuencia
 Debe ser legible y comprensible para un usuario no
experto.
 Debe indicar: actores, flujos principal y excepcionales.

20
 Descripción Textual de los Actores del Sistema
(Requerimientos: ¿Quiénes interactúan con el sistema?)

Nombre: <nombre del actor>

Descripción:
<descripción del actor>

Nombre: Usuario no Autenticado

Descripción:

Representa a un usuario que no se a identificado frente

al sistema. Generalmente estos usuarios deberían
poder registrarse (crear un nuevo usuario) o ingresar al
sistema para transformarse en usuarios autenticados,
en moderadores o en administradores del sistema

...
 Descripción Textual de un Caso de Uso
(Requerimientos: ¿Qué debe hacer el sistema?)

Nombre: <nombre del caso de uso>

Autor: <nombre del autor (o autores) del caso de uso>
Fecha: <fecha de creación del caso de uso>
Descripción:
<breve descripción del caso de uso>

Actores:
<actores participantes en el caso de uso>
Precondiciones:
<condiciones que deben cumplirse para poder ejecutar el caso de uso>
Flujo Normal:
<flujo normal (feliz) de ejecución del caso de uso>
Flujo Alternativo:
<flujos alternativos de ejecución del caso de uso>
Poscondiciones:
<condiciones que deben cumplirse al finalizar la ejecución del caso de uso>

Planillas de Casos de Uso (Generales)

 Descripción Textual de un Caso de Uso
(Requerimientos: ¿Qué debe hacer el sistema?)

Nombre: Crear mensaje foro

Autor: Pedro Pérez
Fecha: 21/04/09
Descripción:
Permite crear un nuevo mensaje (hilo) en el foro de discusión.
Actores:
Usuario / Moderador
Precondiciones:
El usuario debe de estar autenticado en el sistema.
 Descripción Textual de un Caso de Uso
(Requerimientos: ¿Qué debe hacer el sistema?)

...continuación
Flujo Normal:
1.- El actor pulsa sobre el botón para crear un nuevo mensaje.
2.- El sistema muestra una caja de texto para introducir el título del
mensaje y una zona de mayor tamaño para introducir el cuerpo del
mensaje.
3.- El actor introduce el título del mensaje y el cuerpo del mismo.
4.- El sistema comprueba la validez de los datos y los almacena.
5.- El moderador recibe una notificación de que hay un nuevo mensaje.
6.- El moderador acepta y el sistema publica el mensaje si éste fue
aceptado por el moderador.
Flujo Alternativo:
4.A.- El sistema comprueba la validez de los datos, si los datos no son
correctos, se avisa al actor de ello permitiéndole que los corrija.

7.B.- El moderador rechaza el mensaje, de modo que no es publicado sino

devuelto al usuario.
Poscondiciones:
El mensaje ha sido almacenado en el sistema y fue publicado.
 Descripción de un caso de uso: textual

Realizar Venta (en un Terminal de Punto de Venta o TPV)

Actor Principal: Cajero

Flujo Principal: Un cliente llega al TPV con un conjunto de artículos. El
Cajero registra los artículos y se genera un ticket. El cliente paga en
efectivo y recoge los artículos.

1. El cliente llega al TPV con los artículos.

2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la información a la
transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción de artículos.

25
 Algunas Reglas de Estilo
(Para los Diagramas de Casos de Uso)

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
Forma General: Imprimir
Verbo (Infinitivo) + Reporte de
Ventas
Predicado
 Algunas Reglas de Estilo
(Para los Diagramas de Casos de Uso)

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 tener demasiados casos de uso en el

mismo diagrama (Regla 5 ± 2) (¡Esto es relativo!)
Evite el uso complejo de relaciones de extensión,
especialización e inclusión (No más de tres
niveles)
¡En general, use el sentido común y recuerde
utilizar la regla KISS!
 Algunas Reglas de Estilo
(Para la Descripción Textual de Casos de Uso)

Narrar el flujo de eventos usando voz

activa, en tiempo presente y desde la
perspectiva del actor:

Evitar el uso de “La clave es introducida

la voz pasiva: por el usuario”

“El usuario introduce la

Preferir la voz clave”
activa: “El sistema valida la clave”
 Algunas Reglas de Estilo
(Para la Descripción Textual de Casos de Uso)

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)

Sin embargo, un caso de uso puede expresar

más de un requisito NO funcional (Esto está bien)
 Ejemplo diagrama de casos de uso

Reservar Libro Prestamo Revista

Profesor

Prestamo Libro Devolver Revista

Socio

Devolver Libro Actualizar Catalogo

Bibliotecario

Extender Prestamo
30 Consultar Socio
 Casos de uso y Colaboraciones

 Con un caso de uso se describe un comportamiento

esperado del sistema, pero no se especifica cómo se
implementa.
 Una caso de uso se implementa a través de una
colaboración:
“Sociedad de clases y otros elementos que colaborarán
para realizar el comportamiento expresado en un caso de
uso”
 Una colaboración tiene una parte estática (diagramas de
clases) y una parte dinámica (diagramas de secuencia).

31
 Descripción de un caso de uso: gráfica

Realizar Venta
Diagrama de secuencia

:Sistema

: Cajero
crearNuevaVenta()

* introducirItem(cod,cantidad)

finalizarVenta()

hacerPago(cantidad)

32
 Casos de uso y Colaboraciones

caso de uso

colaboración

Hacer Pedido

Gestión Pedidos
realización

33
 Haciendo un paréntesis...
(Estereotipos)

planillas de
casos de uso
(CLEDA)

Ojo: Esto es sólo

un ejemplo de un
CRUD es un acrónimo
posible estereotipo, que viene de “Create,
no se lo tomen Read, Update, Delete”

literal...
 Haciendo un paréntesis...
(Estereotipos)

Los estereotipos se pueden

utilizar en casi todos los
elementos disponibles de UML,
de manera que se puede
extender y enriquecer el lenguaje
con su uso

En este caso los estereotipos se utilizan para diferenciar los distintos

tipos de actores (<<client>>, <<internal>>, <<system>>). Algunas
personas reemplazan el “monigote” por iconos personalizados (Ej.
Una computadora, monigotes de distintos colores, etcétera)
Haciendo un paréntesis...
(Estereotipos)

Se pueden utilizar imágenes para

representar cierto tipo especial
de actores
 Diagrama de Casos de Usos
(Ejemplo / Include / Extends /
Especialización)
Algunas personas utilizan la
inclusión para expresar que el
caso de uso asociado debe de
invocarse de manera
“obligatoria”

Múltiples casos de uso “reutilizan” otros

casos de uso. De esta forma no es necesario
describir varias veces el mismo caso de uso
incluido
 Diagrama de Casos de Usos
(Ejemplo / Include / Extends /
Especialización)

Puntos de extensión
explícitos
Puntos de extensión
explícitos
 Diagrama de Casos de Usos
(Ejemplo / Include / Extends /
Especialización)

Las notas son un

elemento común
de UML, se pueden
asociar a casi
todos elementos
disponibles de
Una extensión puede estar
UML
asociada a varios puntos de
extensión
 Generalización

 La herencia indica que un objeto tiene desde el

momento de su creación, acceso a todas las
propiedades de otra clase.
 Esto mismo se aplica a los actores y a los Casos de
Uso, se conoce como generalización y a veces se
especifica con una relación “es un”

Autorización
Cargo

Autorización
Cargo, con
Aviso al celular
 Organización de Casos de uso

 Tres tipos de relaciones:

 Generalización
• Un cdu hereda el comportamiento y significado de otro.
 Inclusión
• Un cdu base incorpora explícitamente el comportamiento
de otro en algún lugar de su secuencia.
 Extensión
• Un cdu base incorpora implícitamente el comportamiento
de otro cdu en el lugar especificado indirectamente por
este otro cdu.

41
 Ejemplo

Extensión
«extend»
Hacer Pedido
Hacer Pedido Urgente
(establecer
prioridad)
«include»
Comprobar clave
Inclusión
Validar Usuario
Generalización
«include»
Seguir Pedido Examinar retina

42
 Relación de inclusión

 Permite factorizar un comportamiento en un caso de uso

aparte y evitar repetir un mismo flujo en diferentes casos
de uso.
 Ejemplo:
Hacer Pedido:
Obtener y verificar el número de pedido;
Incluir “Validar usuario”;
Recoger los ítem del pedido del usuario;
…

43
 Relación de extensión

 El caso de uso base incluye una serie de puntos de

extensión.
 Sirve para modelar:
 la parte opcional del sistema, o
 un subflujo que sólo se ejecuta bajo ciertas
condiciones.

44
 Relación de extensión

 Ejemplo:
Hacer Pedido:
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
Establecer prioridad: punto de
extensión
Enviar pedido para ser procesado
según la prioridad.

45
 Obtención de casos de uso

1) Identificar los usuarios del sistema.

2) Encontrar todos los roles que juegan los usuarios y que
son relevantes al sistema.
3) Para cada rol identificar todas las formas (objetivos) de
interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso.
6) Revisar y validar con el usuario.

46
Diagramas de casos de uso. Ejemplo
 Plantilla usecases.org (Larman)

 Resumen
 Actores Principales y Secundarios
 Personas involucradas e Intereses
 Precondiciones
 Poscondiciones
 Escenario Principal (Flujo Básico)
 Extensiones (Flujos Alternativos)
 Requisitos de Interfaz de Usuario
 Requisitos No-Funcionales
 Cuestiones Pendientes

48
 Utilidad de los casos de uso

 Hay consenso en considerar casos de uso como

esenciales para capturar requisitos y guiar el
modelado.
 Pero todavía existe mucha confusión sobre cómo
usarlos.
 ¿Cuál es el número de casos de uso apropiado
en un proyecto?
 ¿Qué casos de uso hay en el sistema?

49
 Granularidad

 Diferente granularidad
 Casos de uso del negocio
• Procesos de Negocio: Objetivo estratégico de la empresa
• Ej. Vender productos
 Casos de uso del sistema
• Objetivo de un usuario
• Ej. Realizar una compra
 Casos de uso de inclusión
• Forman parte de otro, son como subfunciones
• Ej. Buscar, Validar, Login

50
 Recomendaciones

 Especificar casos de uso no es una actividad de dibujar

diagramas sino de escribir con el detalle necesario el flujo
principal y los flujos alternativos: “centrado en la escritura en
vez del dibujo”.
 No hay que preocuparse demasiado por las relaciones entre
casos de uso ni entre actores.
 El objetivo inicial es identificar los actores y a partir de sus
objetivos encontrar los casos de uso, ya que el diagrama de
casos de uso es una ayuda visual.
 Los actores deben interactuar con el sistema.

51
 Recomendaciones

 No incluir como caso de uso las operaciones CRUD sobre un objeto de

negocio (alta, consulta, borrado, actualización). CRUD es el acrónimo de
Crear, Obtener, Actualizar y Borrar (Create, Retrieve, Update y Delete
en inglés).
 La excepción es si se trata de operaciones relevantes para el sistema, como
“Registrar Cliente” en un sistema de venta por Internet.
 Cuidado con el empleo de la relación “include”.
¡NO HACER UNA DESCOMPOSICION FUNCIONAL!
 Los casos de uso sólo consideran los requisitos funcionales del
proyecto, hay que añadir los no-funcionales.

52
 En Resumen ¿Qué Modelan los
Diagramas de Casos de Usos?

Actores del Sistema

Los Casos de Uso (Escenarios / Interacción

Usuario - Sistema)
Relaciones entre: Actores con Actores, Actores
con Casos de Uso, Casos de Uso con Casos de
Uso

Los límites del sistema, el alcance del sistema

El refinamiento o descomposición de los casos

de uso
53
 Resumen de la Clase

Casos de Uso (Descripción Textual)

Casos de Uso (Diagramas)

Elementos Comunes de UML: Estereotipos,

Notas, Generalización (Especialización)

54