Gonzalorojas 07 U M L, Casos De Uso ( Final)

  • 38,442 views
Uploaded on

Realizadas por Gonzalo Rojas

Realizadas por Gonzalo Rojas

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • como me descargo Dios
    Are you sure you want to
    Your message goes here
  • gracias por este documento ha sido de gran ayuda , muy claro y facil de comprender
    Are you sure you want to
    Your message goes here
  • Este documento esta muy claro y facil de entender, sobre todo gracias a los ejemplos.

    Totalmente recomendado
    Are you sure you want to
    Your message goes here
  • Gracias!
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
38,442
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
1,579
Comments
4
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Fundamentos de Modelado OO en UML Adaptado de Curso de UML, Patricio Letelier T., Universitat Politècnica de València, España 1
  • 2. Objetos Objeto = unidad atómica que encapsula estado y comportamiento La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento Un objeto puede caracterizar una entidad física (coche) o abstracta (ecuación matemática) 2
  • 3. … Objetos En UML, un objeto se representa por un rectángulo con un nombre subrayado Otro ob jeto Un objeto Otro ob jeto más 3
  • 4. … Objetos Ejemplo de varios objetos relacionados: Cuenta Corriente 101 Juan Banco de Valencia Felipe Cuenta Corriente 114 4
  • 5. … Objetos Objeto = Identidad + Estado + Comportamiento El estado está representado por los valores de los atributos Un atributo toma un valor en un dominio concreto Un coche Azul 979 Kg 70 CV ... 5
  • 6. Clases y Objetos 6
  • 7. Comportamiento Ejemplo de interacción: Operación 1 Un Objeto Operación 2 1: Un mensaje Otro Objeto 7
  • 8. … Comportamiento Los mensajes navegan por los enlaces, a priori en ambas direcciones Estado y comportamiento están relacionados Ejemplo: no es posible aterrizar un avión si no está volando. Está volando como consecuencia de haber despegado del suelo 8
  • 9. Persistencia La persistencia de los objetos designa la capacidad de un objeto de trascender en el espacio/tiempo Podremos después reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecución (materialización del objeto) Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debería ser transparente, un objeto existe desde su creación hasta que se destruya 9
  • 10. Comunicación Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que trabajan de manera coordinada en la consecución de un fin específico El comportamiento global se basa pues en la comunicación entre los objetos que la componen 10
  • 11. … Comunicación Categorías de objetos: • Activos - Pasivos • Cliente – Servidores, Agentes Objeto Activo: posee un hilo de ejecución (thread) propio y puede iniciar una actividad Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos una vez que se le solicita un servicio Cliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitado 11
  • 12. … Comunicación Los agentes reúnen las características de clientes y servidores Son la base del mecanismo de delegación Introducen indirección: un cliente puede comunicarse con un servidor que no conoce directamente 12
  • 13. … Comunicación Ejemplo con objeto agente: Servidor 1 2: Un agente 3: 1: Servidor 2 Un cliente 13
  • 14. El Concepto de Mensaje La unidad de comunicación entre objetos se llama mensaje 1: Mensaje A Objeto 2 Objeto 1 2: Mensaje C 4: Mensaje E Objeto 4 Objeto 3 3: Mensaje D 14
  • 15. Mensaje y Estímulo Un estímulo causará la invocación de una operación, la creación o destrucción de un objeto o la aparición de una señal Un mensaje es la especificación de un estímulo 15
  • 16. UML Diagrama de Casos de Uso 16
  • 17. Casos de Uso Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación Diferente al Diagrama de Flujo de Datos del Enfoque Estructurado 17
  • 18. … Casos de Uso Actores: • Principales: personas que usan el sistema • Secundarios: personas que mantienen o administran el sistema • Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados • Otros sistemas: sistemas con los que el sistema interactúa La misma persona física puede interpretar varios papeles como actores distintos El nombre del actor describe el papel desempeñado 18
  • 19. … Casos de Uso Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario Un escenario es una instancia de un caso de uso Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso 19
  • 20. Casos de Uso: Relaciones UML define cuatro tipos de relación en los Diagramas de Casos de Uso: • Comunicación C aso de U so Actor 20
  • 21. … Casos de Uso: Relaciones • Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino <<include>> Caso de Uso Origen C aso de U so Desti no <<include>> reemplazó al denominado <<uses>> 21
  • 22. … Casos de Uso: Relaciones Ejemplo <<include>>: <<include>> Reintegro Cuenta Corriente Verificar Operación Cliente <<include>> Reintegro Cuenta de Crédito 22
  • 23. … Casos de Uso: Relaciones • Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino <<extend>> Caso de Uso Origen C aso de U so Desti no 23
  • 24. … Casos de Uso: Relaciones Ejemplo <<extend>>: Solicitar Préstamo Cliente [Tarjeta Caducada] <<extend> > Solic itar N ueva Tarjeta 24
  • 25. … Casos de Uso: Relaciones Ejemplo <<include>> y <<extend>>: Ide n f i caci ó ti n <<include>> Transferencia Cliente << exten d>> Transferencia en Internet 25
  • 26. … Casos de Uso: Relaciones Otro ejemplo <<include>> y <<extend>>: Order Product Supply Customer Data Arrange Payment <<include>> <<include>> <<include>> the salesperson asks for the catal og 1 <<extend>> * Request Catalog Salesperson Place Order 26
  • 27. … Casos de Uso: Relaciones • Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía Caso de Uso Hij o Caso de Uso Padre 27
  • 28. … Casos de Uso: Relaciones • Ejemplo de herencia Reserva por Agencia * * Reserva de Billete Aéreo Cliente Reserva en Aerolínea 28
  • 29. Casos de Uso: Construcción Un caso de uso debe ser simple, inteligible, claro y conciso Generalmente hay pocos actores asociados a cada Caso de Uso Preguntas clave: • ¿cuáles son las tareas del actor? • ¿qué información crea, guarda, modifica, destruye o lee el actor? • ¿debe el actor notificar al sistema los cambios externos? • ¿debe el sistema informar al actor de los cambios internos? 29
  • 30. … Casos de Uso: Construcción La descripción del Caso de Uso comprende: • el inicio: cuándo y qué actor lo produce? • el fin: cuándo se produce y qué valor devuelve? • la interacción actor-caso de uso: qué mensajes intercambian ambos? • objetivo del caso de uso: ¿qué lleva a cabo o intenta? • cronología y origen de las interacciones • repeticiones de comportamiento: ¿qué operaciones son iteradas? • situaciones opcionales: ¿qué escenarios alternativos se presentan en el caso de uso? 30
  • 31. Ejemplo Cajero Automático Sacar Dinero Realizar Transferencias Cliente Sistema Bancario Depositar Dinero Administrar Cajero Operador 31
  • 32. Caso de Uso UC1: Sacar Dinero Actor Principal: Cliente Personal involucrado e intereses: - Cliente: quiere retirar dinero en efectivo desde su cuenta de forma rápida y sencilla - Sistema Bancario: quiere recibir peticiones de transacción en formato correcto; quiere mantener actualizada la información de las cuentas de sus clientes a partir de la información de los giros en el Cajero. Precondiciones: El Cliente suministra tarjeta bancaria Garantías de éxito (Postcondiciones): El Cliente obtiene el monto requerido en dinero en efectivo. Escenario Principal de Éxito (o Flujo Básico): 1. El Cliente inserta la tarjeta en el Cajero 2. El Cajero lee el código de la banda magnética de la tarjeta, verifica si es aceptable y pide el código del Cliente 3. El Cliente introduce el código 4. Si el código es correcto, el Cajero pide al Cliente que seleccione el tipo de transacción deseada 5. El Cliente selecciona la función Sacar Dinero 6. El Cajero le pide al cliente que teclee la cantidad deseada 7. El Cliente teclea la cantidad que quiere sacar 8. El Cajero envía la petición al sistema bancario 9. Si la conexión al Sistema Bancario es exitosa, el Sistema Bancario deberá comprobar si el monto es permitido. 10. El Cajero expulsa la tarjeta, imprime el recibo y entrega el dinero 32
  • 33. Extensiones (o Flujos Alternativos): 2’ La tarjeta no es aceptada - El Cajero expulsa la tarjeta, emitiendo un sonido 4’ Código incorrecto (1,2) - Se emite un mensaje, dando al Cliente la oportunidad de volver a introducir el código 4’’ Código incorrecto (3) - Se emite un mensaje y se retiene la tarjeta 9’a Fallo en la conexión con Sistema Bancario - Se emite un mensaje y se expulsa la tarjeta 9’b El Sistema Bancario no permite girar ese monto - Se emite un mensaje y se expulsa la tarjeta 10’ El Cajero no dispone de la cantidad pedida - Se emite un mensaje y se vuelve al paso 7 1-9’ Cancelar - En cualquier momento, el usuario puede cancelar la transacción, con lo que se expulsa la tarjeta 33
  • 34. Ejemplo 2… Venta por Catálogo Comprobar Estado del Pedido Realizar Pedido Vendedor Completar Pedido Empleado Cliente Establecer Crédito Supervisor 34
  • 35. …Ejemplo 2 <<extend>> Realizar Pedido Solicitar Catálogo <<i nclu >> de> ude > l nc <<i <<in cl ude> Suministrar Datos Realizar Pedido de Cliente Productos > Realizar Pago Cliente Vendedor 35
  • 36. Plantilla de documentación propuesta… RF- <id del requisito> <nombre del requisito funcional> Versión <numero de versión y fecha> Autores <autor> Fuentes <fuente de la versión actual> Objetivos asociados <nombre del objetivo> Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>} 36
  • 37. Plantilla de documentación propuesta… Precondición <precondición del caso de uso> Postcondición <postcondición del caso de uso> Secuencia Paso Acción Normal 1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x> 2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x> 3 4 5 6 n 37
  • 38. Plantilla de documentación propuesta… Excepciones Paso Acción 1 Si <condición de excepción>,{el <actor> , el sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta} 2 3 Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundos 38
  • 39. …Plantilla de documentación propuesta Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales> 39
  • 40. Comentarios En métodos OO que carecen de una técnica de captura de requisitos se comienza inmediatamente con la construcción del modelo de análisis/diseño Los Casos de Uso son una idea maravillosa que ha sido generalmente complicada. El verdadero truco para los Casos de Uso es mantenerlos simples. Recordad, mañana van a cambiar. Rober C. Martin Los requisitos NO funcionales también son importantes. Desempeño, cumplimiento de estándares o leyes, atributos de calidad (confiabilidad, disponibilidad, seguridad, mantenibilidad, portabilidad), etc. 40
  • 41. Recomendación Bibliográfica UML y Patrones, Craig Larman, Sección 6.6 41