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.

 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.

Actores en el Caso de Uso

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 Proteccin por falta fondos

<<extend>>

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 <<Actor>> SistemaCuentas Por Pagar

LocalizarProducto <<Actor>> SistemaProcesamiento Ordenes

LlenarOrden

Encargado embarques

EmbarcarOrden

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 <<include>> AlmacenarProducto

LlenarOrden

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.