CASOS DE USO

Casos de Uso: Introduccin

Es una coleccin de diagramas y texto
que juntos documentan como los usuarios
esperan interactuar con el sistema.
Los casos de uso se centran en los
factores crticos de xito, en trminos de
la funcionalidad que los usuarios
necesitan para interactuar.

Casos de Uso: Objetivo

La diferencia entre los Casos de Uso y el
diseo funcional es el foco. El diseo
funcional documenta un proceso, los
casos de uso la meta del proceso.
Centrarse en procesos, a menudo
reproduce sistemas existentes, ya que
nos centramos en el como y no en el
porque y en el que.

Recursos del modelo de Casos de

Uso
Nombre
Suposiciones
Pre-condiciones
Dilogo
Post-condiciones
Excepciones
Mejoras futuras

Narrativa de los
Casos de Uso
Diagrama de Casos de Uso

Escenario de los
Casos de Uso

Diagrama de Casos de Uso

La meta del diagrama es proporcionar una
explicacin de la relacin del sistema y el
mundo exterior.
Por ejemplo en el caso de un cajero el diagrama
del Caso de Uso puede corresponder a la
pantalla principal y el men disponible: retiro,
consulta de saldo, etc. Cada una de estas
opciones puede representarse como un Caso
de Uso separado. El cliente (fuera del sistema)
est asociado con cada uno de los Casos de
Uso (dentro del sistema) que planea usar.

Elementos del Diagrama

Caso de Uso
Sistema

Dependencia

Actor
Asociacin

Generalizacin

Elementos del Diagrama

Sistema: Establece el lmite del sistema en relacin con
los actores que lo van a usar.
Actor: Es un rol que puede jugar una persona, otro
sistema, un dispositivo.
Caso de Uso: Identifica una caracterstica clave del
sistema, expresa una meta que el sistema debe lograr.
Asociacin: identifica la asociacin entre actores y
Casos de Uso. Cada asociacin es un dilogo que debe
explicarse con la narrativa del Caso de Uso.
Dependencia: Identifica una comunicacin entre dos
Casos de Uso.
Generalizacin: Define una relacin entre dos actores
entre dos Casos de Uso, cuando uno de los casos
hereda las propiedades del otro.

Sistema en el Caso de Uso

Que tanto incluiremos en el sistema?

Como se relaciona este sistema con otros?
Quien va a usar este sistema?
Un sistema es como un objeto con un propsito y con
interfases, la implementacin interna puede cambiarse
sin afectar otras entidades, mientras el propsito y las
interfases no cambien.
El propsito es la meta de la justificacin del proyecto.
Las interfases son los canales de comunicacin entre
los actores fuera del sistema y las caractersticas del
sistema en s: los Casos de Uso.

Actores en el Caso de Uso

Usuarios: personas, sistemas o dispositivos

Actor: rol que juega una entidad externa en
relacin al sistema.
Los actores normalmente son los sujetos en las
oraciones que describen como la gente usa los
sistemas.
Es mejor utilizar roles
SISTEMA RH
ya que permite centrarse
en como el sistema ser
usado y no en puestos de
trabajo.

Casos de Uso
Definen las caractersticas requeridas por
el sistema.
Son nombrados usando una frase (verbo),
expresando la meta que debe cumplir el
sistema.
A pesar de que cada Casos de Uso
soporta un proceso, stos se centran en
la meta, no en el proceso
Actualizacin
de Cuenta

Retiro de
Efectivo

Continuacin Casos de Uso

Definiendo los Casos de Uso de esta forma, el sistema
se especifica como un juego de requerimientos ms que
una solucin. No se dice como trabaja el sistema, sino lo
que debe ser capaz de hacer.
Los Casos de Uso describen solo aquellas
caractersticas que son visibles y significativas para los
actores que usaran el sistema. Esto evita el hacer una
descomposicin funcional.
En conclusin: Modelar solo las caractersticas del
sistema que pueden ser vistas por un actor.
Por ejemplo, si un sistema debe guardar datos en una
base de datos, solo se debe ilustrar el mensaje que
indica que los datos se guardaron, no como se guardan.

Asociaciones en los Casos de Uso

Se representan con una lnea conectando
un actor a un Caso de Uso
Pueden ser bidireccionales o
unidireccionales.
Consulta de
saldo

Retiro de
efectivo
Asociacin

Estereotipos
Los estereotipos se usan en UML en los Casos de Uso,
clases y paquetes.
Notacin <<include>>: Cuando un Caso de Uso
necesita ayuda de otro Caso de Uso, la dependencia se
dibuja con una flecha punteada hacia el caso que ser
usado. Es una subrutina o llamada a funcin.
Notacin <<extend>> indica que un Caso de Uso puede
necesitar ayuda de otro Caso de Uso, contrario al
include donde siempre la necesita.
Retiro
efectivo
Retiro
efectivo con
proteccin

<<include>>

Actualizar
cuenta

<<extend>>

Proteccin por
falta fondos

Generalizacin
La herencia indica que un objeto tiene
desde el momento de su creacin, acceso
a todas las propiedades de otra clase.
Esto mismo se aplica a los actores y a los
Casos de Uso, se conoce como
generalizacin y a veces se especifica
con una relacin es un Autorizacin
Cargo

Autorizacin
Cargo, con
Aviso al celular

Caso de Estudio: Construccin del

Diagrama de Caso de Uso
Fuente de informacin para poder construir el Caso de Uso:
Receiving, Stocking, Order fulfillment, Shipping.
Paso 1: Establecer el contexto del sistema meta. El contexto
define la ubicacin del sistema dentro del negocio,
incluyendo procesos, planes y objetivos de negocio, otros
sistemas, gente y sus obligaciones en el trabajo,
restricciones impuestas por entidades externas.
De acuerdo con el problema, los participantes:
..informan al departamento de Cuentas
notifican al departamento de Procesamiento de Ordenes
contactan a los embarcadores
El contexto ubica al sistema dentro del las operaciones de la
bodega, trabaja con las rdenes, con cuentas por pagar y
con los que embarcan.

Paso 2: Identificar a los actores

<<Actor>>
SistemaCuentas
Por Pagar

<<Actor>>
SistemaProcesamiento Ordenes

receptor almacenista inventarios surte

Paso 3: Identificar los casos de

Uso
Encontrar las caractersticas o la funcionalidad
que el sistema debe proporcionar con preguntas
como:
Qu produce el sistema para el actor? Ayuda
a identificar salidas crticas.
En que ayuda el actor al sistema) Facilita
conocer las entradas crticas.
En que ayuda el sistema al actor? Identifica las
reglas que deben aplicarse cuando el actor usa
el sistema.

Casos de uso identificados

RecibirProducto receive incoming
shipments.and updates inventory
AlmacenarProducto looks up the correct
location
LlenarOrden ..Other staff members fill orders
update inventory
LocalizarProducto locating the products
required .
EmbarcarOrden .order has shipped and
updates inventory

Paso 4: Definir las asociaciones

entre
actores
y
Casos
de
Uso
Receptor
RecibirProducto

Encargado
de
Inventarios
Otros

AlmacenarProducto

LocalizarProducto

LlenarOrden
Encargado
embarques

<<Actor>>
SistemaCuentas
Por Pagar

EmbarcarOrden

<<Actor>>
SistemaProcesamiento Ordenes

Paso 5: Evaluar los actores y

Casos de Uso
Renombrar, mezclar, dividir actores y
Casos de Uso cuando sea necesario.
Preguntarse: Por qu este actor es
responsable de estas tareas?
Por qu estas tareas se dan juntas,
separadas en este orden?
En el ejemplo hay que verificar si el
Receptor y el Encargado de Inventarios
son una misma persona

Evaluar los casos de Uso para

dependencias tipo <<include>
Se aplica cuando un Caso de Uso siempre
llama a otro para que lo ayude con una tarea.
En el ejemplo, Actualizar inventarios es un
requerimiento para AlmacenarProducto,
LlenarOrden y para EmabarcarOrden
EmbarcarOrden

<<include>>
<<include>>

ActualizarInventario

LlenarOrden
AlmacenarProducto

<<include>>

Evaluar los casos de Uso para

dependencias tipo <<extend>
Un Caso de Uso puede o no usar otro Caso de Uso
dependiendo de una cierta condicin. Cuando la
condicin se cumpla se llama al otro Caso de Uso, sino,
no se llama.
Si en el ejemplo se quisiera aumentar un producto en el
inventario sin tenerlo que colocar en una de las
ubicaciones predefinidas, sin tener que pasar por el
Caso AlmacenarProducto. El Caso RecibirProducto
tendra que solicitar permiso para llamar
ActualizarInventario.
RecibirProducto

<<extend>>

ActualizarInventario

Evaluando actores y los Casos de

Uso para Generalizacin
El problema dice The products may come from
cancelled orders, returned orders, or vendor
shipments. Si las reglas de almacenaje son
distintas para los varios tipos de entrada, se
puede usar generalizacin en el Caso de Uso
AlmacenarProducto
AlmacenarProd

AlmacenarProd
Regresado

AlmacenarProd
Nuevo

AlmacenarProd
Cancelado

Asociaciones
1) Entre el Receptor y RecibirProducto.
The receiving clerks receive incoming
shipments y entre RecibirProducto y
SistemasCuentas por Pagar

Narrativa del Caso de Uso

Es una descripcin del Caso de Uso, que se
refiere a la comunicacin entre el Caso de Uso y
el usuario, que puede ser un actor u otro Caso
de Uso. Una narrativa debe incluir:
Suposiciones: Describen el estado del sistema que
debe ser verdadero antes de que se pueda usar el
Caso de Uso. Estas condiciones no se prueban para
el Caso de Uso. Por ejemplo, autenticacin y
autorizacin en un sistema, un sistema tpico soporta
estas funciones. Cada Caso de Uso subsecuente
supone que el usuario no puede acceder si no ha
pasado por el chequeo de seguridad, por lo que no
tendremos que incluir en cada Caso de Uso la
verificacin de la seguridad.

 Precondiciones: A diferencia de las suposiciones, estas

condiciones si son probadas por el Caso de Uso, si no son
verdaderas, no se puede continuar. Estas reglas deben
conocerse, por ejemplo si se le pide a un cliente proporcionar un
password, debe decirle exactamente como debe estar formado.
Iniciacin del Caso de Uso: Hay que definir que va a iniciar el
caso, sobre todo cuando ste se va a reutilizar y/o ser utilizado
por varios actores.
Dilogo: Es una descripcin paso a paso de la conversacin
entre el Caso de Uso (el sistema) y el usuario (un actor otro
Caso de Uso). A menudo es til modelar esta secuencia de
eventos con un diagrama de Actividades. Por ejemplo si quieres
sacar dinero de un cajero: Una vez que se pas el Caso de Uso
de seguridad y se tiene el men de opciones, seleccionar Retiro
efectivo. El sistema preguntar cuanto quieres sacar. Hay que
escribir la cantidad en pesos, si se rebasa el permitido, el
sistema dar un mensaje de error o bien si se pide una cantidad
que no sea mltiplo de los billetes que maneja el cajero. Si se
cumplen las restricciones del cajero, se obtendr el dinero.

 Terminacin del Caso de uso: Puede haber

varias formas de terminar un caso de uso, por
ejemplo si todo va por buen camino el caso de
uso llegar a su fin normalmente, si no es as
tendr un fin diferente, un mensaje de error,
una cancelacin, etc.
Post-condiciones: Describen un estado del
sistema que debe ser verdadero cuando el
Caso de Uso termina. A veces se usa el
trmino garantizar, por ejemplo al final de
una transaccin, exitosa o fallida, debemos
notificar al usuario el estado de la transaccin.

Narrativa para el caso en estudio

Usaremos el caso LlenarOrden:
bsicamente este es el punto principal del
negocio, personal autorizado toma un
Producto del inventario de acuerdo a la
especificacin de la Orden. Actualiza la
orden y el inventario. Si no hay alguno de
los tems, se crea una backorder.

 Suposiciones: El personal debe estar

autorizado, por lo que supondremos que la
seguridad est soportada por otro Caso de Uso
(ValidarAcceso) y que se hace en forma
confiable y correcta.
Suposicin

Usuario vlido con permiso

Precondiciones: El problema dice Other staff

members fill orders by locating the products
required, si el nmero de orden el de los
productos no son vlidos, no podr continuar
Precondicin

Dar un nmero de orden vlido

 Iniciacin Caso de Uso: Describir como se inicia el

dilogo con el caso.
Iniciacin

El Caso inicia por demanda

Dilogo: Se requiere interaccin entre el usuario y el

sistema.
Dilogo
El sistema pide un nmero de orden
El usuario lo proporciona
El sistema busca la orden, sino encuentra se detiene si lo
encuentra proporciona la orden al usuario.
El usuario selecciona un tem y el sistema lo busca, si est
disponible, el usuario de la cantidad.
Si hay algn tem que no se tuvo se hace una backorder,
utilizando el Caso de Uso CrearBackOrder

 Terminacin Caso de Uso:

Terminacin

El usuario puede cancelar

El Caso de Uso puede exceder tiempo
El usuario puede dejar la orden a la mitad
El usuario puede terminar todos los tems

Poscondiciones:
Poscondiciones

Fin normal: Los cambios en la orden

deben salvarse, si se cre una BackOrder
debe soportarse por el Caso de Uso
correspondiente.
Cancelacin: La Orden debe salvarse sin
cambios. Si se cre una BackOrder debe
cancelarse.