Objetivo

• Al término del curso el alumno aplicará la programación Orientada al Objeto, a través del uso del Lenguaje Unificado de Modelado (UML) y el Lenguaje de programación Java, con la finalidad de resolver problema de Sistemas reales. Considerando los paradigmas de Programación: lógica funcional, paralela, distribuida y orientada a agentes.

Contenido Básico III. Modelación UML

Tema: CASOS DE USO

Casos de Uso: Introducción

• Es una colección de diagramas y texto que juntos documentan como los usuarios esperan interactuar con el sistema.

• Los casos de uso se centran en los factores críticos de éxito, en términos de la funcionalidad que los usuarios necesitan para interactuar.

Casos de Uso: Objetivo

• La diferencia entre los Casos de Uso y el diseño funcional es el foco. El diseño 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

Diálogo

Post-condiciones

Excepciones

Mejoras futuras

Diagrama de Casos de Uso

Narrativa de los

Casos de Uso

Escenario de los

Casos de Uso

Diagrama de Casos de Uso

• La meta del diagrama es proporcionar una explicación de la relación 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

Sistema

Dependencia

GeneralizaciónAsociación

Actor

Caso de Uso

Elementos del Diagrama• Sistema: Establece el límite del sistema en relación 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 característica clave del sistema, expresa una meta que el sistema debe lograr.

• Asociación: identifica la asociación entre actores y Casos de Uso. Cada asociación es un diálogo que debe explicarse con la narrativa del Caso de Uso.

• Dependencia: Identifica una comunicación entre dos Casos de Uso.

• Generalización: Define una relación 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 propósito y con interfases, la implementación interna puede cambiarse sin afectar otras entidades, mientras el propósito y las interfases no cambien.

• El propósito es la meta de la justificación del proyecto.

• Las interfases son los canales de comunicación entre los actores fuera del sistema y las características 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 relación al sistema.

• Los actores normalmente son los sujetos en las oraciones que describen como la gente usa los sistemas.

• Es mejor utilizar rolesya que permite centrarseen como el sistema seráusado y no en puestos detrabajo.

SISTEMA RH

Casos de Uso• Definen las características 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

Retiro de

Efectivo

Actualización

de Cuenta

Continuación Casos de Uso

• Definiendo los Casos de Uso de esta forma, el sistema se especifica como un juego de requerimientos más que una solución. No se dice como trabaja el sistema, sino lo que debe ser capaz de hacer.

• Los Casos de Uso describen solo aquellas características que son visibles y significativas para los actores que usaran el sistema. Esto evita el hacer una descomposición funcional.

• En conclusión: Modelar solo las características 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 línea conectando un actor a un Caso de Uso

• Pueden ser bidireccionales o unidireccionales.

Consulta de

saldo

Retiro de

efectivo

Asociación

Estereotipos• Los estereotipos se usan en UML en los Casos de Uso, clases y

paquetes.

• Notación <<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 función.

• Notación <<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

protección

Actualizar

cuenta

Protección por

falta fondos

<<include>>

<<extend>>

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

Caso de Estudio: Construcción del Diagrama de Caso de Uso

Fuente de información para poder construir el Caso de Uso: Receiving, Stocking, Order fulfillment, Shipping.

Paso 1: Establecer el contexto del sistema meta. El contexto define la ubicación 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 embarcadoresEl 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

receptor almacenista inventarios surte

<<Actor>>

SistemaCuentas

Por Pagar

<<Actor>>

SistemaProcesa-

miento Ordenes

Paso 3: Identificar los casos de Uso

Encontrar las características o la funcionalidad que el sistema debe proporcionar con preguntas como:

• ¿Qué produce el sistema para el actor? Ayuda a identificar salidas críticas.

• ¿En que ayuda el actor al sistema) Facilita conocer las entradas críticas.

• ¿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

LlenarOrden

EmbarcarOrden

RecibirProducto

AlmacenarProducto

Receptor

Encargado

de

Inventarios

Otros

Encargado

embarques

<<Actor>>

SistemaCuentas

Por Pagar

<<Actor>>

SistemaProcesa-

miento Ordenes

LocalizarProducto

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

LlenarOrden

AlmacenarProducto

ActualizarInventario

<<include>>

<<include>>

<<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 condición. Cuando la condición 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 tendría que solicitar permiso para llamar

ActualizarInventario.

RecibirProducto ActualizarInventario<<extend>>

Evaluando actores y los Casos de Uso para Generalización

•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 generalización en el Caso de Uso AlmacenarProducto

AlmacenarProd

Regresado

AlmacenarProd

Nuevo

AlmacenarProd

Cancelado

AlmacenarProd

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 descripción del Caso de Uso, que se refiere a la comunicación 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, autenticación y autorización en un sistema, un sistema típico 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 verificación 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.

• Iniciación 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.

• Diálogo: Es una descripción paso a paso de la conversación 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 múltiplo de los billetes que maneja el cajero. Si se cumplen las restricciones del cajero, se obtendrá el dinero.

• Terminación 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 cancelación, etc.

• Post-condiciones: Describen un estado del sistema que debe ser verdadero cuando el Caso de Uso termina. A veces se usa el término “garantizar”, por ejemplo al final de una transacción, exitosa o fallida, debemos notificar al usuario el estado de la transacción.

Narrativa para el caso en estudio

• Usaremos el caso LlenarOrden: básicamente este es el punto principal del negocio: personal autorizado toma un Producto del inventario de acuerdo a la especificación 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.

Suposición Usuario válido con permiso

• Precondiciones: El problema dice “Other staff members fill orders by locating the products required…”, si el número de orden ó el de los productos no son válidos, no podrá continuar

Precondición Dar un número de orden válido

• Iniciación Caso de Uso: Describir como se inicia el diálogo con el caso.

Iniciación El Caso inicia por demanda

• Diálogo: Se requiere interacción entre el usuario y el sistema.Diálogo

El sistema pide un número 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 da la cantidad.

Si hay algún ítem que no se tuvo se hace una backorder, utilizando el Caso de Uso CrearBackOrder

• Terminación Caso de Uso:

Terminación 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.

Cancelación: La Orden debe salvarse sin

cambios. Si se creó una BackOrder debe

cancelarse.

Escenarios en los Casos de Uso

• Un Caso de Uso identifica una meta primaria de un sistema. Cuando un actor trata de completar la meta usando el sistema, usualmente habrá decisiones y reglas que pueden influir la salida.

• Un escenario es un camino lógico de un Caso de Uso.

• Se construyen a partir de la narrativa.

• Empiezan a revelar los trabajos internos del sistema y las expectativas de los usuarios.

Como dibujarlo

• Iniciar con el camino que se considera correcto, ya que es el más fácil de entender.

• Trazar los pasos hasta que se llega a una decisión (diamante).

• Tomar una decisión y continuar con los pasos, hasta el fin. Es escenario 1.

• Regresar hasta el punto de decisión y trazar la segunda rama.

• Repetir el proceso hasta tener trazados cada segmento del diagrama.

Escenarios para el Caso de Uso: SurtirOrden (FillOrder)

Diálogo

El sistema pide un número 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 da la cantidad.

Si hay algún ítem que no se tuvo se hace una backorder, utilizando el Caso de Uso CrearBackOrder

Pedir

Num Orden

Dar

Num Orden

Se encontró la

Orden?

si

no

Se traza el escenario

hasta el primer

punto de decisión

Pedir

Num Orden

Se encontró

la

Orden?

no

Escenario 1Dar

Num Orden

Dar la

Cantidad

Selecciona

Item

Buscar

Item

Desplegar

Orden

Se encontró

el Item?

si

no

si

Actualiza

Inventario

no

si

Quedan

Items en la Orden?

I

II I’

II’

Pedir

Num Orden

Se encontró

la

Orden?

no

Dar

Num Orden

Mensaje de

error

si

Escenario 2

Pedir

Num Orden

Se encontró

la

Orden?

no

Dar

Num Orden

Selecciona

Item

Buscar

Item

Desplegar

Orden

Mensaje de

error

Se encontró

el Item?

si

no

si

Crear

BackOrder

Escenario 3

Pedir

Num Orden

Se encontró

la

Orden?

Dar

Num Orden

Dar la

Cantidad

Selecciona

Item

Buscar

Item

Desplegar

Orden

si

Actualiza

Inventario

no

si

Quedan

Items en la Orden?

Escenario 4

Se encontró

el Item?

Resumiendo…

• Las narrativas explican en detalle como esperan los usuarios interactuar con el sistema.

• Los escenarios proporcionan un análisis detallado de cada posible salida del Caso de Uso.

• Los escenarios pueden usarse para desarrollar un plan de pruebas.

Pedir

Num Orden

Se encontró

la

Orden?

no

Escenario 1Dar

Num Orden

Dar la

Cantidad

Selecciona

Item

Buscar

Item

Desplegar

Orden

Mensaje de

error

Se encontró

el Item?

si

no

si

Actualiza

Inventario

no

si

Quedan

Items en la Orden?

Crear

BackOrder

Escen 2

Escenario 3

Escenario 4

Pedir

Num Orden

Dar

Num Orden

Se encontró la

Orden?

si

no

Se traza el escenario

hasta el primer

punto de decisión

Bibliografía