Desarrollo de software orientado a

objetos
Unidad 3:
Casos de Uso
Agenda

 Actores y casos de uso del Sistema

 Especificación de casos de uso
 Organización del modelo de casos de
Uso
Actores y casos de uso
Casos de Uso y Procesos de Negocios

EMPRESA SISTEMA ARTEFACTOS

¿Cuáles son los Casos de Uso del

procesos de Negocio
negocios?
Análisis de Casos de Uso
requerimientos
Modelo de Casos de Uso
 Un modelo de casos de uso describe las
funciones a desarrollarse en el sistema y a los
actores que las utilizan.
 Es usado en los workflows de requerimientos,
análisis y diseño y prueba.

Objetivo: Comunicar la funcionalidad y

el comportamiento al cliente y al usuario
Workflows y Casos de Uso
Casos de uso y Actores
Actor representa cualquier cosa que
interactúa con el sistema (humano,
SW o HW). Ejemplo: Cajero

Caso de Uso secuencia de acciones

que obtienen resultados de valor para
un actor

Proceso del sistema

 Actores y ámbito del sistema

Sistema Bancario
¿Límites del
Cliente
Sistema?
Sistema ATM

Cajero Bancario
Definiendo los límites del sistema
Usuarios Otros Sistemas

Sistema
Nuevo Sistema
Heredado

Mantención
Comunicaciones
Reportes
Casos de Uso
• El análisis de los casos de uso incluye
entender el dominio de los procesos y el
medio externo ¿Cuáles son los actores que
participan en los procesos?
Casos de Uso

Error común ...

Representar pasos

Los casos de uso describen los

procesos a automatizar.
Actores
 No son parte del sistema, son roles de un
usuario.
 Puede intercambiar información con el
sistema (actor directo).
 Puede ser un recipiente pasivo de
información (actor indirecto).
 Puede representar a un humano, una
máquina o un SW.
¿Cómo encontrar los actores?
Preguntas de ayuda
 ¿Quién está interesado en cierto requerimiento (se
beneficia o se ve afectado)?
 ¿Dónde en la organización es usado el sistema?
 ¿Quiénes usan, eliminan o suministran
información?
 ¿Quién usa una determinada función?
¿Cómo encontrar los actores?
 ¿Quién soporta y mantiene el sistema?
 ¿Usa el sistema un recurso externo?
 ¿Cuáles actores necesita el caso de uso?
 ¿Un actor juega diferentes roles? o ¿Varios
actores juegan el mismo rol
(generalización /especialización)?
Instancias de Actores

Inserte
Tarjeta 1 2 3
Iván se 4 5 6
comporta 7 8 9
* 0 #
como Actor
del Sistema Tomás se
comporta
como Actor
del Sistema

Modelo de Caso de Uso

Actor Caso de Uso

Un usuario puede desempeñar el rol
de varios actores……
Jimmy es
Insert card
1 2 3 Operador
4 5 6
7 8 9
* 0 #

Jimmy Operador
Jimmy también
es Cliente
Cliente
 Dos actores pueden realizar idénticas
tareas
Inserte Jimmy es un
Iván es Tarjeta 1 2 3
operador
un cliente 4 5 6
7 8 9
* 0 #

Usuario

• Tanto el cliente como el operador pueden efectuar Cliente Operador

transacciones en un cajero automático
• El cliente y el operador son usuarios del cajero
automático.
• El usuario puede efectuar transacciones en un Usuario Efectuar
Transacciones
cajero automático
Identificación de los casos de uso
 Método basado en los Actores.
 Método basado en Eventos.
 Análisis del modelo de casos de uso del
negocio (business modeling).
 Análisis de Requerimientos.
Método basado en los Actores
 Se relacionan los actores
vinculados con un sistema o
empresa.
 Para cada actor, se identifican los
procesos que ellos inician o en los
que participan.
Método basado en los Actores
Preguntas clave:
 ¿Cuáles son las tareas de este actor?
 ¿Qué objetivos concretos necesita alcanzar un
actor?
 ¿Puede el actor crear, almacenar, remover o leer
información en el sistema?
 El actor, ¿necesita estar informado acerca de las
ocurrencias del sistema?
Método basado en Eventos
 Se identifican los eventos externos a los
que un sistema debe responder.
 Se relacionan los eventos con los
actores y con los casos de uso.
 Es útil para este método establecer una
tabla de eventos.
 Tabla de Eventos
Evento Entrada Fuente Salida Destino

Se requiere Datos del Vendedor

registrar a un Cliente
cliente
Se requiere Datos de la Cajero Comprobante de Cliente
registrar una Venta Venta
Venta
Se requiere Estado de Cliente
emitir un Cuenta
EECC
Análisis del modelo de casos de uso
del negocio
 Exploración de los diagramas
Análisis del modelo de casos de uso
del negocio
 Transición natural (AS IS)
Análisis del modelo de negocio
 Transición natural (AS IS)
Análisis del modelo de negocio
 Análisis del diagrama de actividades
GV : BA-Gerente Ventas AV : BW -Asistente Ventas

Sol i cita revi si ón de Consul ta i nform aci ón

l i sta de preci os del m ercado

Si
Hay nue vos Defi ne productos
productos? para l a venta

No No

Es cam paña
SI

Busca productos a
P1 : BE-Producto
No ofertar
Aprueba?

Si
Reali za aj uste de preci o s de
productos y ofertas
Rem i te Nueva
Lista a T i endas

Envi a l i sta a
PO : BE-Preci o
Ge rente de Ventas
Análisis del modelo de negocio
 Transición con mejora de procesos
Análisis del modelo de negocio
 Transición de los objetos de negocio
Análisis del modelo de negocio
 Redefinición de los procesos (TO BE)
Matriz de actividades y requerimientos

 Al identificar los requerimientos se pueden

enlazar con los casos de uso (fase 2)

Caso de Activi- Respon- Requeri- Caso de Actor

uso de dades sable mientos uso
negocio
“Trazabilidad”: Enlace de
requerimientos y casos de uso
Documento de Visión
Característica PR10:La máquina de reciclado deberá permitir
del Sistema que se agreguen nuevos tipos de botella.

[UC4: “Agregue nuevo Tipo de Botella”]

Caso de Uso Para agregar nuevos tipos de botella se debe
activar el modo “aprendizaje” e insertar 5
ejemplos...

Verifique que los requerimientos de menor nivel,

sean consistentes con los requerimientos estratégicos.
Especificación de casos de uso
Especificación de Casos de Uso
 La especificación de un caso de uso es el
documento narrativo que describe la
secuencia de eventos que realiza un actor
(agente externo) para completar un proceso,
a través del uso de un sistema.
Tipos de Casos de Uso
 Primario: Representan los casos mas
importantes y comunes. Ej.: Alquiler de
libros
 Secundario: Representan procesos menores
o raros. Ej.: Alquiler entre bibliotecas.
 Opcional: Representan que pueden no
abordarse. Ej.: Remate de libros
Niveles de especificación de casos de
uso
 Existen tres niveles de especificación de
casos de uso dependiendo del nivel de
identificación y desarrollo de los mismos.
 De Alto Nivel
 Esencial
 Real
Casos de uso de Alto Nivel

 Describe el caso de uso muy brevemente,

resumiendo la esencia del mismo en breves
enunciados.
 Son útiles durante el examen inicial de los
requerimientos y del proyecto.
 No influyen de manera determinante en
las decisiones de diseño.
Casos de uso de Alto Nivel

Caso de Uso Realizar Préstamo

Actores Socio (indirecto, iniciador)

Bibliotecario (directo)

Tipo Primario

Descripción Un socio elige los recursos de biblioteca que

desea solicitar en préstamo, luego el bibliotecario
los registra como “prestados” y el socio se los
lleva por un plazo determinado.

Referencias Requerimientos R1, R2

Especificación Esencial
 La especificación esencial de un caso de uso
es el documento narrativo que describe la
secuencia de eventos que realiza un actor
(agente externo) para completar un proceso,
a través del uso de un sistema.
Escenario de un Caso de Uso
 Un escenario es una instancia de un caso de uso,
en donde se dan un conjunto de factores.
 Cada cada de uso tiene un conjunto de escenarios
clasificados en:
 Primarios o de flujo de eventos normal (describen
cómo trabaja usualmente el sistema).
 Alternativos, se producen de acuerdo a excepciones
con el escenario primario.
Casos de uso esenciales
 Entonces…muestran más detalle que uno de alto
nivel.
 Tiene una sección destinada al flujo normal de los
eventos que los describe paso a paso.
 Tiene muchas secciones destinadas a describir los
flujos alternativos.
 Se identifican las pre y post condiciones.
 Se asocian los requerimientos especiales (No
funcionales).
Casos de Uso y flujo de eventos
 Un caso de uso describe “que hace” un
sistema, pero no identifica “cómo”.
 Un flujo de eventos describe el cómo
(parcialmente) al interior de un caso de uso.
 Cuando se modela, es importante que se
conserve la separación de la vista interna y
externa.
Caso de uso esencial: Encabezado
Nombre Realizar Préstamo de Libros
Actores Socio (Indirecto e iniciador)
Bibliotecario (Directo)
Tipo Primario y Esencial

Propósito Capturar un préstamo y sus condiciones de devolución.

Descripción Un socio elige los libros que desea llevarse en préstamo.

El bibliotecario registra los libros y consigna su fecha
de devolución. El socio se lleva los libros aceptando las
condiciones que se le han indicado

Referencias Requerimientos: R1, R2

Anexos: A1, A2
 Caso de uso esencial: Flujo normal
de eventos
Acción del actor Respuesta del sistema
1. Comienza cuando el socio
selecciona libros en calidad de
préstamo y se identifica como
socio
2. El bibliotecario registra al 3. Valida al socio y determina la
socio y los libros solicitados fecha de devolución de los
por el socio libros.
4. El bibliotecario termina el 5. Muestra aviso de registro del
registro del préstamo. préstamo OK
6. El socio se lleva los libros
solicitados.
 Caso de uso esencial: Flujo
alternativo de eventos
Acción del actor Respuesta del sistema

En el punto 2 del flujo normal

2. El bibliotecario registra al 3. Valida que el socio no existe o

socio y los libros solicitados está con deudas
por el socio
4. El bibliotecario avisa al socio
que debe regularizar su
situación y finaliza el
préstamo.
Pre y Post Condiciones
 Describen los cambios de estado del sistema
cuando se ejecuta un caso de uso.

Pueden ayudar a identificar las

clases....después
Pre Condiciones
 Son suposiciones sobre el estado del
sistema al iniciarse una operación.
 Cosas que son importantes probar en el
SW en algún momento de la ejecución.
 Cosas que no serán sometidas a pruebas
pero de las cuáles depende el éxito de la
operación.
Post Condiciones
 Describen el estado de un sistema luego de ejecutarse un caso
de uso.
 No se refieren a las acciones a realizar en un futuro inmediato.
 Se redactan con verbos en pasado.

Cambios (en pretérito) de estado

Post Condiciones

 Categorías de Post-Condiciones:
 Creación y eliminación de objetos
 Modificación de atributos
 Asociaciones formadas y canceladas
 Ejemplo de Pre y Post-Condiciones

 Pre-Condiciones:
 Se deben reconocer los ejemplares de libros por
código
 El sistema debe conocer el tiempo de devolución
estándar por tipo de socio.
 Post-Condiciones:
 Se creó un objeto préstamo.
 Se asociaron ejemplares de libros al préstamo.
 Se asoció un socio al préstamo
Requerimientos Especiales

 En esta sección del caso de uso se

asocian los requerimientos no
funcionales de mayor impacto sobre
el caso de uso.
Organización del modelo de
casos de uso
Diagramas de casos de uso

 Representa un conjunto de casos de

uso para un sistema, los actores y la
relación entre casos de uso y Actores
 Similar a un Diagrama de Contexto
 Diagrama de casos de uso
BIBLIOTECA
Reservar
Libros

Realizar
Bibliotecario Préstamo Socio

Devolver
Libros
Priorizar Casos de Uso
Se puede hacer sobre la base de la experiencia...
 Seleccionar los que influyan profundamente en la
arquitectura básica, dando soporte al dominio y a
las capas de servicio de alto nivel o
 Escoger los que presenten el máximo riesgo,
funciones urgentes o complejas en las primeras
iteraciones.
Priorizar Casos de Uso
Seleccionar....
 Los que requieran investigación a fondo o
nueva tecnología.
 Aquellos que representen procesos
primarios o la línea de negocio.
 Los que apoyen directamente el aumento de
ingresos o la reducción de costos.
Priorizar casos de uso
Sobre la base de ponderaciones...
 Se definen valores a los atributos de los
requerimientos.
 Se aplican pesos a los diferentes valores de los
atributos.
 Se calcula el peso total de cada requerimiento.
 Se priorizan los requerimientos de mayor peso
total.
Priorizar casos de uso
 Debe haber un caso de uso de inicio o
arranque
 Un caso de uso puede abordarse en varias
iteraciones incrementando su funcionalidad.
Organización del modelo de casos de
uso
 Tareas:
 Establecer relaciones de "inclusión" entre los
casos de uso.
 Establecer relaciones de "extensión" entre los
casos de uso.
 Establecer las "generalizaciones" entre los casos
de uso.
 Establecer las "generalizaciones" entre los actores.
 Evaluar los resultados.
Relación de Generalización
 La generalización entre casos de uso es
como la generalización entre clases.
 En concreto, significa que el caso de uso
“hijo” adiciona o antepone el
comportamiento del caso de uso “padre”
Relación de Inclusión
 Significa que un caso de uso base incorpora
explícitamente el comportamiento de otro caso de
uso.
 Se usan para evitar describir el mismo flujo de
eventos varias veces.
 También se usan para ocultar funcionalidad.
 Es esencialmente un ejemplo de delegación.
Relación de Extensión
 Significa que existe un caso de uso base que
implícitamente incorpora el comportamiento de
otro caso de uso.
 El caso de uso base puede desarrollarse
normalmente, pero ante ciertas condiciones sus
operaciones pueden extenderse al comportamiento
de otro caso de uso.
 Las casos de uso de extensión se pueden encontrar
en los flujos alternativos de eventos significativos.
 Ejemplos de relaciones
«extensión» Colocar
Programar
Ordenes
Ordenes
urgentes

«inclusión»

Efectuar Validar
seguimiento password
de Ordenes Validar
Usuario generalización
«inclusión»
Escaneo
de Fotochecks
Uso de Paquetes
 Los paquetes se usan para agrupar casos de
uso de acuerdo a grandes procesos o
gestiones.
 Los paquetes deben guardar relación con la
estructura del menú de la aplicación y los
casos de uso con las funciones/opciones del
mismo.
Uso de Paquetes
 Un primer diagrama debe organizar los grandes procesos
en paquetes.
 Cada paquete se puede descomponer en otro paquete o en
casos de uso.
 En un diagrama de paquetes no debe haber casos de uso.
 La única relación entre paquetes es la dependencia.
 La organización de paquetes en los casos de uso debe ser
similar a la forma como se organiza el menú de la
aplicación.
Uso de paquetes

Gestión
Gestión
de
de
Pedidos
Ventas

Gestión
de
Cobranza
 Conclusiones
 El modelo de casos de uso sirve como herramienta
de comunicación con los usuarios y otros expertos.
 Permite organizar los requerimientos del sistema.
 Permite identificar interacciones de los actores
con el sistema.
 Permite identificar interfaces.
 Permite planificar iteraciones.
 Permite establecer el plan de pruebas del sistema.