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