La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Unidad de Aprendizaje: Programación Avanzada Elaborado por: M. En T. I. Rafael Valentín Mendoza Méndez UNIVERSIDAD AUTÓNOMA DEL ESTADO DE MÉXICO CENTRO.

Presentaciones similares


Presentación del tema: "Unidad de Aprendizaje: Programación Avanzada Elaborado por: M. En T. I. Rafael Valentín Mendoza Méndez UNIVERSIDAD AUTÓNOMA DEL ESTADO DE MÉXICO CENTRO."— Transcripción de la presentación:

1 Unidad de Aprendizaje: Programación Avanzada Elaborado por: M. En T. I. Rafael Valentín Mendoza Méndez UNIVERSIDAD AUTÓNOMA DEL ESTADO DE MÉXICO CENTRO UNIVERSITARIO UAEM TEMASCALTEPEC MAESTRÍA EN CIENCIAS DE LA COMPUTACIÓN

2 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.

3 Contenido Básico III. Modelación UML Tema: CASOS DE USO

4 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.

5 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”.

6 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

7 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.

8 Elementos del Diagrama Sistema Dependencia GeneralizaciónAsociación Actor Caso de Uso

9 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.

10 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.

11 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 roles ya que permite centrarse en como el sistema será usado y no en puestos de trabajo. SISTEMA RH

12 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

13 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.

14 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

15 Estereotipos  Los estereotipos se usan en UML en los Casos de Uso, clases y paquetes.  Notación >: 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 > 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 >

16 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

17 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 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.

18 Paso 2: Identificar a los actores receptor almacenista inventarios surte > SistemaCuentas Por Pagar > SistemaProcesa- miento Ordenes

19 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.

20 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…”

21 Paso 4: Definir las asociaciones entre actores y Casos de Uso LlenarOrden EmbarcarOrden RecibirProducto AlmacenarProducto Receptor Encargado de Inventarios Otros Encargado embarques > SistemaCuentas Por Pagar > SistemaProcesa- miento Ordenes LocalizarProducto

22 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

23 Evaluar los casos de Uso para dependencias tipo  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 >

24 Evaluar los casos de Uso para dependencias tipo  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. RecibirProductoActualizarInventario >

25 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

26 Asociaciones  1) Entre el Receptor y RecibirProducto. “The receiving clerks receive incoming shipments…” y entre RecibirProducto y SistemasCuentas por Pagar

27 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.

28  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.

29  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.

30 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.

31  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

32  Iniciación Caso de Uso: Describir como se inicia el diálogo con el caso. IniciaciónEl 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

33  Terminación Caso de Uso: TerminaciónEl 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: PoscondicionesFin 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.

34 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.

35 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.

36 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

37 Pedir Num Orden Dar Num Orden Se encontró la Orden? si no Se traza el escenario hasta el primer punto de decisión

38 Pedir Num Orden Se encontró la Orden? no Escenario 1 Dar 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 III’I’ II’

39 Pedir Num Orden Se encontró la Orden? no Dar Num Orden Mensaje de error si Escenario 2

40 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

41 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?

42 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.

43 Pedir Num Orden Se encontró la Orden? no Escenario 1 Dar 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

44 Pedir Num Orden Dar Num Orden Se encontró la Orden? si no Se traza el escenario hasta el primer punto de decisión

45 Bibliografía


Descargar ppt "Unidad de Aprendizaje: Programación Avanzada Elaborado por: M. En T. I. Rafael Valentín Mendoza Méndez UNIVERSIDAD AUTÓNOMA DEL ESTADO DE MÉXICO CENTRO."

Presentaciones similares


Anuncios Google