Curso de UML

Actividad 2
Diagramas de Casos de Uso del
 Sumario

§ Casos de uso
§ Casos de uso del Negocio
§ Casos de uso del Sistema
Casos de uso
 Casos de uso
§ Los Casos de Uso (Ivar Jacobson) describen, bajo
la forma de acciones y reacciones, el
comportamiento de un sistema desde el punto de
vista del usuario.
§ Permiten definir los límites del sistema y las
relaciones entre el sistema y el entorno.
§ Los Casos de Uso son descripciones de la
funcionalidad del negocio/sistema independientes
de la implementación.
 Casos de uso
§ Los Casos de Uso cubren la carencia
existente en métodos previos (OMT, Booch)
en cuanto a la determinación de requisitos.
§ Los Casos de Uso particionan el conjunto de
necesidades atendiendo a la categoría de
usuarios que participan en el mismo.
§ Están basado en el lenguaje natural, es decir,
es accesible por los usuarios.
 Casos de uso vs. DFD
• Un CU es una función (servicio o transacción)
atómica ofrecida por el sistema al entorno (actores).
• Un proceso de un DFD puede ser detallado en un DFD
hijo. Así, el concepto de “explosión de proceso” sólo
se aplica a los DFDs.
 Casos de uso vs. DFD
• Un CU y un proceso modelan una pieza de funcionalidad
del sistema, pero su especificación es diferente. En un CU
interesa expresar la funcionalidad mediante la interacción
actores – sistema. En un proceso la funcionalidad se
expresa mediante la transformación que se hace de los
flujos de entrada para producir flujos de salida.
• Un CU en general no modela un particionamiento (o
detalle) funcional interno del sistema pues se concibe
desde la perspectiva de los actores, es decir una visión
externa del sistema. Un DFD, según sea el nivel de detalle,
puede mostrar descomposición funcional interna del
¿En qué momento se usa los CU?

Modela
miento

Captura
de
Casos de uso del Negocio
Modelo de Casos de Uso del Negocio

• Describe los procesos de un negocio,

vinculados al campo de acción, y cómo
se benefician e interactúan los socios y
clientes en estos procesos.

Estereotipos
Actor Caso de
del Uso
Negoci del
 ¿Actor del negocio?
Rol que alguien o algo juega cuando
interactúa con el negocio para
beneficiarse de sus resultados.
Candidatos: Rol = Actor
• Clientes o potenciales clientes
• Socios
• Proveedores
• Autoridades
• Propietarios
• Sistemas de información externos al negocio
• Otras parte de la organización, si ésta es
grande.
 Proceso de negocio
Grupo de tareas lógicamente relacionadas
que se llevan a cabo en una determinada
secuencia y manera y que emplean los
recursos de la organización para dar
resultados en apoyo a sus objetivos.

Un CUN representa
a un proceso de negocio
 Casos de Uso del Negocio (CUN)
Secuencia de acciones, realizadas en el
negocio, que producen un resultado de valor
observable para ciertos actores del negocio.

Desde la perspectiva de un actor individual,

define un flujo de trabajo completo que
produce resultados deseados.
Envía y/o recibe mensajes

asociación
Cliente Vender Pasaje
Identificación de los procesos del negocio

Núcle Cliente Servicio de comida

Soport
Comprar suministros Proveedor
Gerencial

Marketing
Cliente potencial Experto en
(Ejemplo: Restaurante)
relaciones públicas
Identificación de los procesos del negocio
(Agrupamiento de actividades)
Un grupo funcional que responde a
un objetivo de la organización y que
Funci puede involucrar a varias áreas.

(Ejemplo: Empresa productora)

Identificación de los procesos del negocio
(Objetivos)

SubObjetivo 1
... Proceso
Objetivos
... s
estratégic SubObjetivo n
• Atender pedido
“Satisfacer
de los clientes.
pedidos de • Cliente Atender pedido
Solicitra insumo
los clientes”
a los
proveedores.
Proveedor Comprar suministros

(Ejemplo: Empresa de servicio)

 Consideraciones acerca de actores
del negocio
• Todo lo que interacciona con el ambiente
del negocio se modela con actores.
• Cada actor humano expresa un rol, no
una persona específica.
• Cada actor modela algo fuera del
negocio.
• Cada actor se involucra con al menos un
caso de uso.
• Cada actor tiene una descripción y un
nombre que explica su rol en relación al
negocio.
Consideraciones acerca de los CUN
• Su nombre y descripción breve
son claras y fáciles de
comprender.
• Cada caso de uso del negocio es
completo desde la perspectiva de
un actor externo.
• Cada caso de uso del negocio
normalmente se involucra con, al
menos, un actor.
• Es posible que un caso de uso de
 Diagrama de CUN
Diagrama que representa gráficamente a los
procesos del negocio y su interacción con los
actores del negocio.

Cliente Marketing
potencial Gerente de Relaciones
Públicas

Proveedor
Comprar
Cliente
Servicio de comida suministros
(Ejemplo:Restaurant)
 Convenios en la representación del
Diagrama de CUN
• Un caso de uso puede asociarse con uno o
más actores.
• Un caso de uso se comunica con al menos
un actor, sino hay error en el modelo,
excepto cuando:
• CU abstracto (puede tenerlas).
• CU hijo en una relación de
generalización/especialización si en el padre se
describe toda la comunicación.
 Convenios en la representación del
Diagrama de CUN
Navegabilidad en las relaciones de comunicación
entre actores y CUN

• Indica quién inicia la comunicación en la interacción y

se muestra con una flecha.
• Si la fecha apunta al CUN, inicia el actor.
• Si la flecha apunta al actor, entonces inicia el CUN.
• La relación en los dos sentidos se muestra sin saetas.
• Por cada flecha de comunicación se asume un
mensaje de retorno.
 Convenios en la representación del
Diagrama de CUN
Navegabilidad en las relaciones de comunicación
entre actores y CUN

• NO confundir navegabilidad con flujos de datos, la

navegabilidad solo indica relación de iniciación.
• Los convenios que usaremos serán:
• La flecha de iniciación del actor al CUN siempre se
muestran, aún si más tarde el CU inicia comunicación con
el actor que lo mostró. En este último caso solo se pone
una flecha del actor al CUN.
• El resto de las flechas puede ser omitida e incluirla solo
para esclarecer el diagrama.
 Estructuración de los CUN
• Identificar los comportamiento en
CUN que necesitan considerarse
como casos de uso abstractos
(casos de uso que no se instancian
por si solos y que describen
comportamiento reutilizable y
compartido).
• Encontrar actores del negocio
que definan roles compartidos
 Estructuración de los CUN

• Relación de inclusión
• Relación de extensión
• Relación de Generalización-especialización
 Relación de inclusión <include>
Una relación que especifica un
comportamiento definido para el CU de
inclusión que se inserta explícitamente dentro
del comportamieto definido para el CU base.

El workflow del proceso entero está en el

caso de uso base y el (los) caso(s) de uso
incluido(s).
Relación de inclusión <include>

Se justifica cuando:
• Se puede reusar en otros CUN el
comportamiento incluido en el caso de
uso base, o
• Simplifica la comprensión del caso de
uso base.
 Relación de inclusión <include>.
REUTILIZAR

<<include>>
Check-In
Pasajero Individual
Manipular
<<include>> Equipaje

Guía de Check-In
turismo de Grupo
(Ejemplo: Aduana)
 Relación de inclusión <include>.
PARTICIONAR

<<include>>
Venta de
Cliente producto
Verificar
Es un CU de apoyo que política de
no se relaciona con descuento
actores

(Ejemplo: Empresa de servicios)

 Relación de extensión <extend>
Una vez definido el workflow de un
caso de uso del negocio, se puede
encontrar alguna conducta opcional
u optativa.
Tiene sentido definir un nuevo CU cuando:
• Modelar un workflow complejo o un
subflujo separado, que raramente ocurre u
ocurre bajo ciertas condiciones.
• Flujos distintos que pueden ejecutarse en
base a la selección del actor.
 Relación de extensión <extend>.

Pasajero

<<extend>>
Check-In Individual Manejo Especial de Equipaje

SOLO PARA ALGUNOS PASAJEROS HAY QUE IR

AL COUNTER DE EQUIPAJE ESPECIAL
(Ejemplo: Aduana)
 Generalización - especialización

Se usa para mostrar worksflows

que comparten estructuras,
propósito y comportamiento.

Un caso de uso padre se puede

especificar en uno o más casos
de uso hijos que representan
formularios más especificos del
padre.
 Generalización - especialización
Se utiliza para:
Para no tener que describir el mismo
flujo varias veces, se puede colocar el
comportamiento común en un CUN.

Se recomienda usar cuando:

Se puede afirmar que constituyen tipos de
procesos. Generalmente tienen un
comportamiento similar pero con diferencias
sustanciales que provocan que sean
considerados CUN diferentes.
 Generalización – especialización.

Realizar
visitas
Jefe zonal

Realizar Visitas a Realizar visitas a

clientes clientes
potenciales registrados
(Ejemplo: Vendedores ambulantes)
 Generalización entre Actores
Varios actores del negocio pueden jugar
el mismo rol en un caso de uso
particular del negocio.

El rol compartido se modela como el

actor del cual heredan los actores con
roles compartidos (solo se representan
si interactúan como actor con otro CUN).
 Generalización entre Actores. Ejemplo

Despachar medicamentos
en farmacia
Cliente

Asignar citas Administrador Administrador Asignar camas

Consulta Externa Hospitalización
(Ejemplo:Hospital)
 Realizaciones de CUN
Muestran la manera en que colaboran
los trabajadores y entidades de
negocio para ejecutar el proceso. Se
documentan con:

•Diagramas de actividad
•Descripción textual
•Diagramas de clases
•Diagramas de secuencia
 Descripción textual de los

• nombre del caso del uso del negocio

• actores
• propósito
• resumen
• flujo de trabajo
- Básico (normal)
- Curso Alterno
• otras secciones
• Prioridad
• Mejoras
Cliente Atender pedido
Cliente Atender pedido
Casos de uso del Sistema
 Casos de uso del sistema
Establece un acuerdo entre clientes y
desarrolladores sobre las condiciones y
posibilidades (requisitos) que debe cumplir
el sistema.
Artefacto narrativo que describe, bajo la forma de
acciones y reacciones, el comportamiento del sistema
desde el punto de vista del usuario (Jacobson).

Descripciones de la funcionalidad del sistema

independientes de la implementación.
 Casos de uso del sistema

Descripciones de la funcionalidad del sistema

independientes de la implementación.

Definición de
 Definición de Requisitos
Es el proceso de averiguar, por lo general en
circunstancias difíciles, lo que se debe construir.

Los usuarios deben saber lo que quieren

•Cada uno sabe lo que hace, pero

ninguno tiene una visión global
•No saben cómo puede hacerse más eficiente la
operación en su conjunto.
•No saben qué parte de su trabajo puede
transformarse en software..
 Requisito funcional
“Una capacidad o condición que el sistema
cumplirá”

Co l es
mp sib
ren e n
sib pr
les om
C
Desarrolladores

Requisitos Clientes y
Usuarios
 Clasificación de los requisitos
funcionales
• Objetivos y metas para un sistema.
Normal
(Funcional) • Si están presentes 

• Implícitos al sistema.
Espera
(No Funcional) • Puede que el cliente no los declare,
pero si no están se siente insatisfecho.

Innovad
(Funcional y no
• Características que van más allá de la
expectativas del cliente.
funcionales)
 Identificación de requisitos
funcionales a partir del modelo del

• Descripciones textuales.
Realización • Diagrama de clases del
modelo de objetos del
de CUN negocio.
• Diagrama de actividades.

Actividades que serán

automatizadas
Diagrama de casos de uso del
negocio
(Ejemplo: Empresa constructora)

Proyectista Atender proyecto nuevo

Diagrama de Actividad.
 Requisito funcional
• Registrar características de un
proyecto
• Analizar viabilidad económica
1.1 Evaluar factibilidad económica
1.2 Registrar resultados de la
evaluación.
3. Analizar viabilidad técnica
1.1 Evaluar factibilidad técnica
1.2 Registrar resultados de la
evaluación.
4. Registrar aprobación/rechazo de un
proyecto
 Actores
• No son parte del sistema
• Puede intercambiar información con el sistema.
• Puede ser un recipiente pasivo de información.

TRABAJADORES Y ACTORES
DEL NEGOCIO
Actores
Identificación de los CU del sistema a
partir del modelo del negocio

CASO DE USO = PROCESO QUE OBTIENE

UN RESULTADO DE
VALOR
¿Cómo identificar los casos de uso del
sistema?
Comenzar con los trabajadores del
negocio. Para cada uno:
• Decidir si el trabajador del negocio va a
utilizar el sistema de información.
• De ser así, identificar un actor en el
modelo de casos de uso del sistema.
• Para cada caso de uso del negocio en el
que participe el trabajador del negocio,
crear un caso de uso del sistema.
• Repetir estos pasos para todos los
 Casos de uso
Ejemplo

Jefe de obra Económico

Aprobar/rechazar proyecto
Evaluar un proyecto
económicamente
Evaluar un proyecto
técnicamente
 Casos de uso
Casos especiales: Manejo del tiempo
En algunos sistemas se tienen actividades
que se ejecutan periódicamente, como por
ejemplo, el cálculo de intereses de los
clientes de un banco se realizan todas la
noches. Para modelar esto se puede realizar
lo siguiente:

Calcular intereses
Reloj
 Perfeccionar la definición de
casos de uso

CASOS GENERALIZACIÓN/E
MÚLTIPLES SPECIALIZACIÓN DE
DE USO ACTORES
GENERALIZACIÓN/ES
PECIALIZACIÓN DE
CASOS DE USO
 ¿Cuándo escribir un caso de uso
independiente?
• Se duplica comportamiento en otros CU.
• Un CU es complejo y largo, y su separación
facilita que sean manejables y comprensibles.

• Crear casos de uso independientes (Representar

relaciones <<include>> o <<extend>> entre los
casos de uso).
• Reescribir los casos de uso de las actividades
 Relación de inclusión
Ejemplo
• Casos de uso que tienen una parte común en sus
funcionalidades.
<<include>>

Pagar un servicio
por Internet
Usuario
<<include>> Verificar
permiso
Chequear pagos
realizados
 Relación de inclusión
Ejemplo
• Se observa una relativa independencia en una parte del
flujo de trabajo que se describe, aún cuando no se reutilice.
De ese subproceso solo interesa el resultado.

<<include>>

Pagar un servicio
por Internet
Usuario
Redefinir deuda
pendiente
 Relación de extensión
Ejemplo
• Comportamiento opcional.
<<extend>>
Enviar e-mail a
superior
<<extend>>
Analizar
Especialista discrepancias
del banco
Resolver
discrepancia
 Relación de extensión
Ejemplo
• Comportamiento que es ejecutado solamente bajo ciertas
condiciones.

<<extend>>

Pagar un servicio
por Internet
Especialista
del banco Buscar cuentas
alternativas
 Relación de extensión
Ejemplo
• Flujos distintos y diferentes que pueden ejecutarse sobre la
base de la selección del actor.

<<extend>>

Chequear pagos
realizados
Usuario
Reportar
discrepancias
 Casos de uso múltiples
Ejemplo

Usuario Pagar un servicio por

internet
<<include>> <<extend>>
<<include>>

Reportar
Verificar permiso Redefinir deuda
incongruencias
Generalización/Especialización
entre casos de uso
Ejemplo

Usuario
Pagar

Pagar con Pagar en

tarjeta de efectivo
 Generalización/Especialización
entre casos de uso

Colocar
Llamada

Colocar Llamada Colocar Llamada

Local Larga Distancia
 Colocar Llamada Local
1.La persona (caller) levanta el auricular
2.El sistema presenta el tono de discar
3.La persona disca un dígito
4.El sistema quita el tono de discar
5.La persona introduce el resto del número
6.El sistema analiza el número
7.El sistema encuentra la parte
correspondiente
8.El sistema conecta las partes
9.Las partes se desconectan
 Colocar Llamada de Larga Distancia
1.La persona (caller) levanta el auricular
2.El sistema presenta el tono de discar
3.La persona disca un dígito
4.El sistema quita el tono de discar
5.La persona introduce el resto del número
6.El sistema analiza el número
7.El sistema envía el número a otro sistema
8.El sistema conecta las líneas
9.Las partes se desconectan
 Generalización/Especialización
entre actores
Ejemplo

Especialista Consultor Usuario

del banco de cuentas

Analizar Chequear pagos

discrepancias Chequear realizados
estado de una
cuenta bancaria
 Descripción de los casos de uso en
formato de alto nivel
Caso de uso: <Nombre>
Actores: <Nombre de los actores>
Descripción: <Frases que describan las acciones
indicando los actores involucrados,
debe quedar claro cómo se inicia y
termina el proceso y de que forma
intervienen los actores>

Referencias: <Listado de requerimientos y casos de

uso asociados, indicando tipo de
asociación (include o extend)>
 Descripción de los casos de uso en
formato de alto nivel
Precondiciones: <Cosas que tienen que cumplirse
en el sistema para que se ejecute
el CU>
Poscondiciones: <Condiciones en las que queda el
sistema cuando termina la
ejecución del CU>
Requerimientos especiales: <Precisar de qué
manera restricciones de tiempo
de respuesta, seguridad,
velocidad, disponibilidad,
exactitud o uso de memoria
afectan al caso de uso>
 Descripción de casos de uso
Ejemplo
Caso de uso: Aprobar/rechazar un proyecto

Actores: Jefe de obra

Descripción:
El caso de uso se inicia cuando se han realizado las evaluaciones técnica y
económica de una propuesta de un proyecto y el Jefe de obra debe valorar si
se aprueba o no su ejecución. El sistema debe permitir ver los resultados de
estas evaluaciones y permitir que se registre las conclusiones del Jefe de
obra (aprobar/rechazar y alguna otra consideración que justifique su decisión,
culminando la ejecución del caso de uso.
 Descripción de casos de uso
Ejemplo

Referencias R4

Precondiciones Existan proyectos ya evaluados técnica y económicamente

y estén pendientes de aprobación o rechazo

Poscondiciones Se cambia el estado del proyecto a rechazado o aprobado y

se asocian las causas que motivaron la decisión

Requerimientos -
especiales
 Resumiendo...
• Cada forma en que los actores usan el
negocio/sistema se representa con un caso
de uso.
• Los CU son fragmentos de funcionalidad
que el negocio/sistema ofrece para aportar
un resultado de valor para los actores.
• Un CU especifica una secuencia de acciones
que el negocio/sistema puede llevar a cabo
interactuando con sus actores, incluyendo
alternativas dentro de la secuencia.
 Resumiendo...

•Un caso de uso entrega un resultado que

añade valor a un actor en concreto.

A usuarios
Al actor individuales
iniciador reales
Evita CU muy
Evita CU muy grandes
pequeños
Resumiendo...
 Resumiendo...
Tipos de relaciones en los DCU
– Comunicación
C aso de U so
Actor
<<include>>

– Inclusión
Caso de Uso Origen C aso de U so Desti no

<<extend>>

Caso de Uso Origen C aso de U so Desti no

Caso de Uso Hij o Caso de Uso Padre

 Resumiendo...
Error común en los CU
Representar pasos Imprimir Recibo
como CU
Es un paso del
proceso más amplio
“Comprar Productos”
Los casos de uso describen los
procesos de principio a fin.

Se nombran: Utilizando verbos fuertes en

infinitivo.
 Resumiendo...

Error común en los CU

Describir los cursos
alternos dentro de
los cursos
normales
Se debe definir una
subsección dentro de
la sección de cursos
alternos para cada
curso alterno.
 Resumiendo...
Caso de uso: Actualizar Factura
Acción del actor Respuesta del sistema
1 El usuario suministra su
identificación

2 Localiza la identificación
3 Actualiza los datos de la del usuario. Si no existe el
nueva factura usuario, ejecutar caso de
5 El usuario concluye la uso “Registrar Usuario”.
operación.
Presencia de curso alterno
4 Registra los datos de la
dentro del curso normal factura.
 Resumiendo...
Error común en los CU

Describir de manera insuficiente el caso

de uso en aras de “ganar tiempo”