Sesion 5 1 diagrama de secuencia

5,196 views
4,893 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,196
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
153
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Sesion 5 1 diagrama de secuencia

  1. 1. Diagramas de Secuencia Lic. César Alcántara Loayza
  2. 2. Diagramas De Secuencia  El objetivo del análisis del problema es definir el propósito e interfaces de cada recurso del dominio del problema.  Se determinó el propósito al definir cada clase y sus relaciones en un diagrama de clases.  Ahora veremos las interfaces. Las principales herramienta para descubrir y comprender las interfaces son los diagramas de interacción .CAL/Fundamentos 2
  3. 3. Diagramas De Secuencia  Los diagramas de secuencia y colaboración son usados para modelar interacciones entre los objetos . Los diagramas de secuencia ilustran la interacción entre objetos en el tiempo. Los diagramas de colaboración ilustran las interacciones de los objetos a través de enlaces entre objetos.CAL/Fundamentos 3
  4. 4. Diagramas de Secuencia  Las interacciones ayudan a definir el propósito de un objeto, esto decir, las formas en las que un objeto participa en tareas, como se comunica y trabaja con otros objetos, el por que se necesita del objeto.  Las interfases son preguntas y solicitudes que un objeto es capaz de responder. Si la declaración del problema dice que un objeto debe ser capaz de responder una pregunta o responder a una solicitud, entonces el objeto debe tener una interface correspondiente.CAL/Fundamentos 4
  5. 5. Diagramas De Secuencia  Operaciones y atributos:  Una interface aparece como una operación en una definición de clase. Las operaciones describen lo que el objeto puede hacer y lo que puede hacerle al objeto. Las operaciones pueden recibir, manipular y regresar información. Esta información aparece en las definiciones de clase como atributos.CAL/Fundamentos 5
  6. 6. Diagramas De Secuencia  Los diagramas de secuencia muestran objetos que se comunican unos con otros a lo largo del tiempo. Utilizando, objetos, linea de vida de los objetos y flechas de mensaje.CAL/Fundamentos 6
  7. 7. Diagramas De Secuencia  En siguiente diagrama de secuencia:  Los objetos usan la notación estandar, un rectangulo que contiene el nombre del objeto, dos puntos y el nombre de la clase del objeto. Estos tres elementos subrayados. El nombre del objeto es opcional. Nombreobjeto:nombreclase.  La linea de vida del objeto es una línea discontínua vertical.  Los mensajes aparecen como flechas.CAL/Fundamentos 7
  8. 8. Diagramas De Secuencia Factura : Cliente Orden de Factura : Orden : Inventario orden( ) retornar orden AddArticulo( ) ProductoDisponible(Producto) retorno verdadero AddProducto(producto) retorno okCAL/Fundamentos 8
  9. 9. Diagramas De Secuencia  Mensaje.  Un mensaje se presenta como una flecha horizontal desde la línea de vida del objeto que envía hasta la línea de vida del objeto que recibe.  La terminología puede varias entre las versiones de UML ..  Una posición en la línea de vida indica un punto relativo en el tiempo. El tope de la línea representa el comienzo de la línea de vida. La parte baja corresponde al final de la linea de vida.CAL/Fundamentos 9
  10. 10. Diagramas De Secuencia  El contexto del diagrama de secuencia es la comunicación entre objetos. El alcance del diagrama de secuencia está determinado por la fase actual del ciclo de vida del proyecto. Durante el análisis del problema, el alcance es la comunicación entre los actores, el sistema y los recursos del sistema .CAL/Fundamentos 10
  11. 11. Diagramas De Secuencia  Al construir un diagrama de secuencia es útil partir el proceso en dos partes:  Paso 1: describir las interacciones entre el actor y el sistema. Esto permite mantener el diagrama tan simple como sea posible. Mientras se trabaja en comprender como debe trabajar el caso de uso.  Paso 2: expandir el sistema para incluir los recursos usados por el sistema. Una vez que se sabe como debe trabajar el caso de uso, se remapea el comportamiento del sistema para mostrar los objetos recursos usados por el sistema para completar el comportamiento.CAL/Fundamentos 11
  12. 12. Diagramas De Secuencia : Sistema Bancario : Cliente Primer paso: retira $100 fondos insuficientes ¿otro monto? retira $45 denominación inválida ¿otro monto? retira $40 $40 + reciboCAL/Fundamentos 12
  13. 13. Diagramas De Secuencia : Sistema Bancario : Cuenta : Cliente retira $100 retira $100 fondos insuficientes fondos insuficientes ¿otro monto? Segundo paso retira $45 denominación válida? denominación inválida ¿otro monto? retira $40 retira $40 OK $40 + reciboCAL/Fundamentos 13
  14. 14. Diagramas de Secuencia  Muchos casos de uso incluyen decisiones. Cursos de acción que resultan de multiples decisiones pueden ser muy complejas. Los diagramas de secuencia UML permiten bifurcaciones pero son dificiles de leer, por ello se recomienda que el diagrama de secuencia se limite a un solo escenario. Un escenario es una ruta lógica (ejecución particular) del caso de uso.CAL/Fundamentos 14
  15. 15. Modelando Escenarios  Transformar una especificación textual en un diagrama de secuencia:  Un escenario describe una serie ordenada de eventos dentro de un caso de uso. El objetivo del diagrama de secuencia es asignar responsabilidades de los eventos a los objetos, de forma que definan las interfaces del objeto. Para construir un diagrama de secuencia se debe emparejar cada evento del escenario con los objetos que participan en el evento como remitente y receptor.CAL/Fundamentos 15
  16. 16. Modelando Escenarios  Para dibujar un diagrama de secuencia, evalue cada evento del escenario e identifique el objeto que inicia el evento . Luego identifique el objeto que está mejor preparado para responder. Dibuje una flecha de evento desde el objeto iniciador al objeto que responde. Rotule la flecha de evento con la descripción del eventoCAL/Fundamentos 16
  17. 17. Modelando Escenarios  A medida que coloca eventos en el diagrama de secuencia cuide la posición sobre la linea de vida del objeto desde arriba hacia abajo en el orden en el que ocurren. Ajuste el orden de ser necesario.CAL/Fundamentos 17
  18. 18. Realización  La realización de los CUS se pueden hacer con diagramas de colaboración (modelo de análisis y luego aplicación del análisis de robustez) ó se pueden emplear diagramas de secuencia ó se puede hacer textualmente.CAL/Fundamentos 18
  19. 19. Obtener las 20 siguientes presentaciones por fecha Evento 1 A C Muestre las Obtener los eventos para las 20 Evento 3 Evento 2 presentaciones presentaciones seleccionadas Mostrar los Evento 4 eventos Evento 5 B Evento 5 [ selecciona evento ] selecciona presentación [ Ingresa rango fechas ] Validar fechas [ timeout ]Tomarlo ingresadas Obtener detalle de obtener presentaciones para [ cancela ] presentaciones Mostrar mensaje evento seleccionadosolo como timeoutejemplo visual fechas válidas mostrar detalle dede escenarios Muestra presentaciones para el [ fechas inválidas ] presentaciones A rango de fechas Evento 6 mostrar mensaje de error B C BCAL/Fundamentos 19
  20. 20. Modelando Escenarios  Utilice un escenario como fuente de los eventos. De la especificación (representada por el diagrama de actividad) se ha seleccionado un escenario (marcado con color celeste)  una ruta lógica.  En el diagrama de actividad se ha utilizado las notas como conectores (color gris).CAL/Fundamentos 20
  21. 21. Modelando Escenarios  Para el primer evento (Obtener las 20 siguientes presentaciones por fecha), escoja la clase del diagrama de clases que describa el objeto que inicia el evento. El objeto que da inicio puede ser una clase que representa un actor, el sistema mismo, o uno de los recursos del dominio del problema . En este caso el objeto iniciador es el cliente.CAL/Fundamentos 21
  22. 22. Modelando Escenarios  Las clases que participan Evento SistemaDeBoletaje Cliente 0..* PresentaciónCAL/Fundamentos 22
  23. 23. Modelando Escenarios : SistemaDeBoletaje : Cliente Obtener 20 siguientes presentaciones por fechaCAL/Fundamentos 23
  24. 24. Modelando Escenarios  Para cada evento se encoge una clase que describa el objeto que recibe y responde al evento. : SistemaDeBoletaje : Cliente Obtener 20 siguientes presentaciones por fecha Mostrar presentacionesCAL/Fundamentos 24
  25. 25. Modelando Escenarios  Se repite el procedimiento para cada evento hasta que todos los eventos se apliquen al diagrama de secuencia : SistemaDeBoletaje : Presentación : Cliente Obtener 20 siguientes presentaciones por fecha Mostrar presentaciones Mostrar presentacionesCAL/Fundamentos 25
  26. 26. Modelando Escenarios : SistemaDeBoletaje : Presentación : Cliente Obtener 20 siguientes presentaciones por fecha Mostrar presentaciones Mostrar presentaciones obtener eventos para 20 presentaciones seleccionadas listar eventos Mostrar eventosCAL/Fundamentos 26
  27. 27. Modelando Escenarios : SistemaDeBoletaje : Presentación : Evento : Cliente Obtener 20 siguientes presentaciones por fecha Mostrar presentaciones Mostrar presentaciones obtener eventos para 20 presentaciones seleccionadas listar eventos Mostrar eventos Actividad 5 selecionar evento Obtener presentaciones para evento seleccionado evento activador Listar presentaciones Listar presentaciones Valor retornadoCAL/Fundamentos 27
  28. 28. Modelando Escenarios : SistemaDeBoletaje : Presentación : Evento : Cliente Obtener 20 siguientes presentaciones por fecha Mostrar presentaciones Mostrar presentaciones obtener eventos para 20 presentaciones seleccionadas listar eventos Mostrar eventos Actividad 5 selecionar evento Obtener presentaciones para evento seleccionado evento activador Listar presentaciones Listar presentaciones Valor retornado Mostrar eventosCAL/Fundamentos 28
  29. 29. Modelando Escenarios  Transformar eventos en objetos:  Asignar eventos a objetos:  Una vez que se han distribuido los eventos de un escenario en un diagrama de secuencia, vuelva al diagrama y verifique que el propósito de los objetos corresponde con los eventos en los que ellos participan.CAL/Fundamentos 29
  30. 30. Modelando Escenarios  Aplique una medida de cohesión preguntando:  ¿Todos los eventos iniciados por el objeto soportan el propósito (único) del objeto?  ¿Los eventos a los que el objeto responde encajan con el propósito (único) del objeto?, o ¿al objeto se le piden algo que no lo relaciona directamente con su propósito principal?  Aplique una medida de acoplamiento de los objetos. Las interacciones implícitamente identifican dependencias. Las preguntas son:  ¿Las dependencia refuerzan la adecuada división de trabajo a través del objeto, o simplemente complica la comunicación?  ¿Las dependencias reflejan el funcionamiento del mundo real?CAL/Fundamentos 30
  31. 31. Modelando Escenarios  Evalúe el propósito del objeto:  Cuando se asigna una nueva tarea a un objeto, se está en efecto agregando nueva responsabilidad a la “descripción del trabajo” de objeto. Las nuevas responsabilidades afectan al objeto de la misma manera que lo haría adicionar mayores responsabilidades a su trabajo.CAL/Fundamentos 31
  32. 32. Interfaces  Convertir eventos en operaciones:  Completar la descripción del evento adicionando información que es pasado con el evento y la respuesta esperada. Ambos elementos son opcionales, es decir, no todos los eventos necesitan parámetros y no todos los eventos tienen respuestas.  Ejem., Notificar en algunos casos solo como alarma, en otros puede esperar respuesta.CAL/Fundamentos 32
  33. 33. Interfaces  Convertir descripciones de eventos en operaciones:  El objetivo de crear un diagrama de secuencia es descubrir y documentar las interfaces de cada clase. Para definir completamente cada interface, debe convertir la descripción del evento en una signatura de operación formal. La definición formal de una signatura de operación consiste de un nombre, parámetros de entrada (o argumentos), el tipo de dato de retorno esperado y restricciones.CAL/Fundamentos 33
  34. 34. Interfaces  +NombreOperación (NombreArg: Tipo Dato {Restricciones}, ... ) : Tipo Dato Retornado {Restricciones}  NombreOperación: requerido  Se permite cualquier número de argumentos  Tipo de datos retornado: requerido para un valor regresado, pero los valores de retorno son opcionales.  Visibilidad (+): Requerida antes de la generación del código.CAL/Fundamentos 34
  35. 35. Interfaces  Los argumentos o parámetros son elementos de datos que el objeto necesita para ejecutar la operación.  El tipo de datos retornado describe la clase de información que debe darse como resultado de completar la operación.  Las restricciones son simplemente texto en formato libre que describen las reglas y limitaciones en la ejecución de la operación.CAL/Fundamentos 35
  36. 36. Interfaces Descripción de Evento Elementos de la descripción de la Operación Obtener las presentaciones Nombre Operación Argumentos Retorno Para un rango de fechas ObtPresentación FechaInicio, FechaFinal Lista presentaciones Signatura completa: ObtPresentación (FechaInicio, FechaFinal): ListaPresentaciones Mostrar Mostrar ListaPresentaciones Presentaciones Signatura completa: Mostrar (ListaPresentaciones) ó MostrarPresentación (ListaPresentaciones) Obtener Evento ObtenerEvento Evento Para una Presentación Signatura completa: ObtenerEvento():Evento Mostrar Mostrar Lista Eventos Evento Signatura completa: Mostar (Lista Eventos) ó MostarEvento (Lista Eventos)CAL/Fundamentos 36
  37. 37. Descubriendo Atributos  Cada pieza de información usada por el sistema debe se definida como atributo. Cada atributo debe pertenecer a un objeto. Aún si un atributo es derivado y nunca se almacena, algún objeto debe poseer las reglas para derivarlo.CAL/Fundamentos 37
  38. 38. Descubriendo Atributos  - / NombreAtributo: Tipo Dato = Valor por omisión {Restricciones}  - Visibilidad: requerida antes de generar código.  / Indicador de atributo derivado: opcionalCAL/Fundamentos 38
  39. 39. Descubriendo Atributos  Cada argumento de una operación debe tener una fuente, ¿el objeto que inicia el evento posee la data?, Si no es así, ¿de donde lo obtiene?. Mire el diagrama de clases y encuentre la clase que debería tener la data. Actualize el diagrama de secuencia para mostrar como el objeto iniciador ha obtenido la data desde el objeto que la posee.CAL/Fundamentos 39
  40. 40. Descubriendo Atributos  Ejemplo expandir un diagrama de secuencia con parámetros Asiento Cliente Boleto 1 1 Ubica 0..1 utiliza realiza 0..* 0..* 1 reserva Pone Precio Compra AsientoPresentación NivelPrecio 0..* 1 0..* 0..1CAL/Fundamentos 40
  41. 41. Descubriendo Atributos  Diagrama de secuencia inicial para el caso de uso comprar asientos: : Cliente : Compra : AsientoPresentación : Boleto Paga(lista asientos presentacion) ObtenerPrecio Precio Descuento UsarBoleto Boleto Regresar boleto Regresar boleto Regresar conjunto boletosCAL/Fundamentos 41
  42. 42. Descubriendo Atributos  Retornos de la operación:  La misma lógica se aplica a los retornos de operaciones. ¿El objeto que responde posee la data?, Si no es así, ¿de donde la obtiene?, ¿El objeto deriva la data usando sus propias operaciones?, ¿El objeto ha hallado el valor usando otros objetos?. Actualice el diagrama de secuencia para adicionar los objetos que poseen la data y muestre como obtiene la data el objeto original.CAL/Fundamentos 42
  43. 43. Descubriendo Atributos  En el ejemplo .. cuando un cliente quiere comprar asientos para la presentación, debe proporcionar el tipo de precio para cada sitio para que el sistema conozca que tipo de precio cargar, es decir, adulto, estudiante, adulto mayor o niño:CAL/Fundamentos 43
  44. 44. Descubriendo Atributos Agregue un precio Para cada sitio : Cliente : Compra : AsientoPresentación : Boleto Paga(lista asientos presentacion) ObtenerPrecio El cliente es el único objeto que conoce que tipo de precio aplicar para cada sitio. Precio Adicionar el tipo de precio a los parámetros de la operación de Descuento pago invocada por el cliente. UsarBoleto Boleto Regresar boleto Regresar boleto Regresar conjunto boletosCAL/Fundamentos 44
  45. 45. Descubriendo Atributos  Para hallar el precio por asientopresentación, asientopresentación debe pedir el precio a nivelprecio. Cuando se pide el precio asientopresentación debe proporcionar el tipo de modo que nivelprecio decida que precio retornar.CAL/Fundamentos 45
  46. 46. Descubriendo Atributos : Cliente : Compra : AsientoPresentación : Boleto : NivelPrecio Paga(lista asientos presentacion) ObtenerPrecio ObtenerPrecio(TipoPrecio) Precio Precio Descuento Boleto UsarBoleto Regresar boleto Regresar boleto Regresar conjunto boletosCAL/Fundamentos 46
  47. 47. Descubriendo Atributos  Cada vez que haga un refinamiento, itere a traves del proceso de modelamiento:  Evalúe el diagrama de clases para encontrar objetos que participan en la interacción.  Adicione nuevos objetos.  Identifique nuevos eventos.  Reevalúe el propósito de los objetos participantes.  Convierta los eventos en operaciones.  Convierta la información en atributos.  Asigne propietario a los atributos.  Repita hasta que todos los parámetros y retornos esten considerados.CAL/Fundamentos 47
  48. 48. Revisión  Uno de los principales problemas en el diseño de software es decidir que incluir en el: cada elemento tomado en cuenta requiere dinero y tiempo para desarrollar y soportar. ¿Cómo puede asegurarse que está gastando el tiempo y dinero de la mejor manera?  Utilizar diagramas de clase, de secuencia y modelo de casos de uso como referencias cruzadas.CAL/Fundamentos 48
  49. 49. Revisión  Comparar estas tres vistas una con otra ayuda a descubrir y justificar las operaciones y atributos necesarios para soportar las expectativas del usuario.CAL/Fundamentos 49
  50. 50. Revisión  Hemos revisado:  El propósito y la función de los diagramas de secuencia: descubrir y definir las interfaces de las clases.  Transformar los escenarios de casos de uso en diagramas de secuencia: usar un escenario para crear un diagrama de secuencia. Transformar cada evento del escenario en un evento en el diagrama de secuencia. Asignar responsabilidad del evento a los objetos emisor y receptor.CAL/Fundamentos 50
  51. 51. Revisión  El valor de las interacciones para el modelado de objetos: justificar la necesidad de cada interface de clase como parte de los requerimientos de los casos de uso.  Como descubrir y documentar las operaciones desde las interacciones: convertir cada evento en una operación.  Como descubir y documentar atributos de las operaciones: convertir todos los argumentos y retornos de la operación en atributos. Rastree las fuentes de cada atributo identificado en la secuencia.CAL/Fundamentos 51
  52. 52. Reconciliar Modelos  Un diagrama por si mismo es muy dificil de verificar. Pero cuando se usan juntos diferentes diagramas del mismo problema el proceso de comparación y contraste revela problemas potenciales.  Para identificar discrepancias:  Como probar escenarios.  Como probar clases.  Como probar interfaces.  Como reconocer los patrones de reconciliación.CAL/Fundamentos 52
  53. 53. Reconciliar Modelos  Aunque el diagrama de clases es el único usado para generar código los otros diagramas son herramientas que ayudan a comprender las clases. El diagrama de clases tiene una perspectiva limitada del dominio del problema; No muestra como se comportan los objetos cuando se usa el sistema.CAL/Fundamentos 53
  54. 54. Reconciliar Modelos  Para ver el comportamiento de los recursos, se necesitan modelos que describan como se usan los recursos, viendo las interacciones entre clases, la creación y disposición de recursos y los patrones de colaboración de cada comportamiento.CAL/Fundamentos 54
  55. 55. Analisis Del Problema III Lic. César Alcántara Loayza
  56. 56. Reconciliar Modelos  Un diagrama por si mismo es muy dificil de verificar. Pero cuando se usan juntos diferentes diagramas del mismo problema el proceso de comparación y contraste revela problemas potenciales.  Para identificar discrepancias:  Como probar escenarios.  Como probar clases.  Como probas interfaces.  Como reconocer los patrones de reconciliación.CAL/Fundamentos 56
  57. 57. Reconciliar Modelos  Aunque el diagrama de clases es el único usado para generar código los otros diagramas son herramientas que ayudan a comprender las clases. El diagrama de clases tiene una perspectiva limitada del dominio del problema; No muestra como se comportan los objetos cuando se usa el sistema.CAL/Fundamentos 57
  58. 58. Reconciliar Modelos  Para ver el comportamiento de los recursos, se necesitan modelos que describan como se usan los recursos, viendo las interacciones entre clases , la creación y disposición de recursos y los patrones de colaboración de cada comportamiento.CAL/Fundamentos 58
  59. 59. Prueba De Escenarios  Los escenarios de los casos de uso son fuentes para los diagramas de interacción.  Los escenarios son incialmente de muy alto nivel. De hecho, deberian describir solo lo que es visible a un actor desde fuera del sistema. Cuando se crea el diagrama de secuencia, existen solo dos objetos, el actor y el sistema. En una segunda iteración, adiciona los recursos que el sistema usa para completar los eventos asignados al mismo.CAL/Fundamentos 59
  60. 60. Prueba De Escenarios  Durante el diseño este mismo proceso continuará a medida que adicione clases de software. Reemplazará a los actores con objetos interfaces de usuario y reemplazará el objeto “sistems” con las clases interfaz y control que componen el software .CAL/Fundamentos 60
  61. 61. Prueba De Escenarios  Invariablemente el diagrama de secuencia tendrá mas detalle que los escenarios. Los objetivos y las audiencias son diferentes. Los escenarios son dirigidos a los usuarios fuera del sistema. Los diagramas de secuencia son dirigidos para describir el sistema y sus recursos internos .CAL/Fundamentos 61
  62. 62. Prueba De Escenarios  Agregando detalle el diagrama de secuencia:  Si agrega detalle al diagrama de secuencia adicione dichos detalles a los escenarios y viceversa. De forma que ambos diagramas se encuentren coherentes durante el proceso de mejoras.CAL/Fundamentos 62
  63. 63. Prueba De Escenarios  Cuando se buscan objetos que poseen los niveles de conocimiento requeridos para resolver el problema. Ud. No está limitado a enlaces directos. En el ejemplo de ATM, el banco es una fuente que ATM accede para obtener información que necesita. No hay enlace directo entre ATM y el banco.CAL/Fundamentos 63
  64. 64. Escenarios Y Secuencias  Paso 1: en este primer diagrama de secuencia se refleja la secuencia de eventos descrita por el escenario.  Escenario: retiro con éxito $100. 1. El cliente pide retirar $100. 2. El sistema ATM responde proporcionando el dinero y un recibo.CAL/Fundamentos 64
  65. 65. Escenarios Y Secuencias : SistemaATM : Cliente Retira $100 Dinero + reciboCAL/Fundamentos 65
  66. 66. Escenarios Y Secuencias  Paso 2: incorpora los flujos referenciados por otros escenarios pero no mostrados explicitamente en el diagrama de secuencia original.  Desde dos escenarios de excepción se conoce que el sistema actualmente pasa por dos ediciones antes de avalar el retiro.CAL/Fundamentos 66
  67. 67. Escenarios Y Secuencias : SistemaATM : Cliente Retira $100 Denominación válida? Fondos suficientes? Dinero + reciboCAL/Fundamentos 67
  68. 68. Escenarios Y Secuencias  Escenario: Retiro con éxito $100. 1. El cliente pide retirar $100. 2. ¿La cantidad ingresada es divisible por la denominación disponible en la máquina? 3. ¿Existe suficientes fondos en la cuenta para cubrir la cantidad de retiro?. 4. El sistema ATM entrega el dinero y recibo.CAL/Fundamentos 68
  69. 69. Escenarios Y Secuencias  Paso 3: revisar mejoramientos:  Una vez que se ha dibujado el diagrama se revisa con los miembros del equipo. Ellos le preguntan si intenta incluir la verificación de limite diario que tiene el banco. ¿Qué hará? Preguntar a los usuarios.  Los usuarios manifiestan que olvidaron mencionar antes y que desean la verificación de limite diario en el sistema.CAL/Fundamentos 69
  70. 70. Escenarios Y Secuencias : SistemaATM : Cliente Retira $100 Denominación válida? Dentro de los límites diarios? Fondos suficientes? Dinero + reciboCAL/Fundamentos 70
  71. 71. Escenarios Y Secuencias  Escenario: retiro con éxito $100. 1. El cliente pide retirar $100. 2. ¿La cantidad ingresada es divisible por la denominación disponible en la máquina? 3. ¿El retiro está dentro de los límites de retiro diario? 4. ¿Existe suficientes fondos en la cuenta para cubrir la cantidad de retiro?. 5. El sistemaatm entrega dinero y recibo.CAL/Fundamentos 71
  72. 72. Escenarios Y Secuencias  Paso 4: adicionar recursos del sistema.  Identificar los recursos que el sistema atm (cajero) utiliza para satisfacer las solicitudes de retiro. Estos recursos estan definidos en el diagrama de clase donde se han identificado a los recursos del dominio del problema.CAL/Fundamentos 72
  73. 73. Escenarios Y Secuencias SistemaATM 0..* 1..* Cliente RedATM 1..* 0..* Posee 1..* 0..* Banco CuentaBancaria 1 0..*CAL/Fundamentos 73
  74. 74. Escenarios Y Secuencias  Para cada evento, determine el objeto que mejor pueda manejar el evento. Recuerde que para pasar el evento a un objeto debe seguir las asociaciones definidas en el diagrama de clases.  1. El sistema ATM es el único objeto que conoce su propias denominaciones.  2. El banco es el único objeto que controla la política de limites.  3. El banco conoce el saldo de la cuenta.CAL/Fundamentos 74
  75. 75. Escenarios Y Secuencias : SistemaATM : Banco : Cliente Retira $100 Denominación válida? Note que todos los Dentro de limites de retiro diario? eventos y su orden se mantienen Pero OK se han reasignado Suficientes Fondos en cuenta? OK responsabilidades Dinero + recibo desde el sistema ATM hacia el bancoCAL/Fundamentos 75
  76. 76. Escenarios Y Secuencias  Escenario: retiro con éxito $100. 1. El cliente pide retirar $100. 2. ¿La cantidad ingresada es divisible por la denominación disponible en la máquina? 3. ¿El retiro está dentro de los límites de retiro diario? 4. ¿Existe suficientes fondos en la cuenta para cubrir la cantidad de retiro?. 5. El sistemaatm entrega dinero y recibo.CAL/Fundamentos 76
  77. 77. Escenarios Y Secuencias  Paso 5: evalúe el diagrama de secuencia para mejorar el flujo de eventos.  Note que el diagrama de secuencia hace dos llamadas desde el sistema atm hacia el banco. Una gran red separa físicamente estos dos sistemas. Podría mejorar la comunicación y rendimiento para simplificar la comunicación en un único evento.  1. Reemplce los dos eventos con un único evento “retiro.”  2. El banco ejecuta los dos eventos originales cuando recibe un nuevo evento de retiro.  3. Asegurar de adicionar el retorno del evento de retiro para reflejar la respuesta final del banco.CAL/Fundamentos 77
  78. 78. Escenarios Y Secuencias : SistemaATM : Banco : Cliente Retira $100 Denominación válida? Retira $100 Dentro de limite de retiro diario? Fondos suficientes? OK Dinero + reciboCAL/Fundamentos 78
  79. 79. Escenarios Y Secuencias  Escenario: retiro con éxito $100. 1. El cliente pide retirar $100. 2. ¿La cantidad ingresada es divisible por la denominación disponible en la máquina? 3. ¿El retiro está dentro de los límites de retiro diario? 4. ¿Existe suficientes fondos en la cuenta para cubrir la cantidad de retiro?. 5. El sistemaatm entrega dinero y recibo.CAL/Fundamentos 79
  80. 80. Prueba De Interfaces  Reconcilie el diagrama de secuencia con el modelo de objetos.  El formato de la signatura de una operación:  Nombre ( argumento : datatype, ...) : returndatatype {restricciones}.  Cada evento debería ser traducido en una operación. Una vez que la signatura de la operación se ha definido, existen 4 pruebas para aplicar a su diagrama de clases.CAL/Fundamentos 80
  81. 81. Prueba De Interfaces  1. Verificar que cada operación en su diagrama de secuencia aparece en el diagrama de clases. Muchos CASE agregan automáticamente interfaces a los diagramas de clase.CAL/Fundamentos 81
  82. 82. Prueba De Interfaces  2. Pruebe la cohesión de la clase. Verifique que cada interface soporte el propósito del objeto. Luego busque todas las interfaces de la clase y determine si todas las interfaces soportan el mismo propósito. Si observa que las operaciones trabajan en dos o mas objetivos, entonces podría necesitar partir la clase para mejorar la cohesión.CAL/Fundamentos 82
  83. 83. Prueba De Interfaces  3 prueba de consistencia. Si se referencia la misma interfaces en mas de un escenario, verifique que se use del mismo modo en cada escenario. Es muy facil llegar a tener operaciones con identico nombre que ejecutan funciones distintas.CAL/Fundamentos 83
  84. 84. Prueba De Interfaces  4. Responda las siguientes preguntas:  ¿La clase tiene todo lo necesario para cumplir su propósito definido?  ¿Las interfaces proporcionan toda la funcionalidad que normalmente podría asociarse con el alcance de responsabilidad que se ha asignado a la clase?, De no ser así entonces necesitará revisar los casos de uso y los escenarios para averiguar lo que se pudo pasar por alto. Es posible, también , que la responsabilidad esté fuera del alcance del proyecto.CAL/Fundamentos 84
  85. 85. Prueba De Clases  Reconcilie el diagrama de clases con el modelo de casos de uso.  Reconcilie la terminología del modelo de casos de uso y los nombres de clase.CAL/Fundamentos 85
  86. 86. Prueba De Clases  1. ¿Existe una clase que maneje cada recurso mencionado en el modelo de casos de uso?. Cuando se crea inicialmente el diagrama de clases se usa el vocabulario del dominio del problema como se documenta en la declaración del problema y en los casos de uso. A medida que se continua el análisis, es frecuente los cambios en estos documentos.CAL/Fundamentos 86
  87. 87. Prueba De Clases  Verifique que los nuevos recursos sean añadidos (o removidos) de su diagrama de clases y que su propósito esté completamente definido. Defina sus interfaces y actualize su diagrama de secuencias.CAL/Fundamentos 87
  88. 88. Prueba De Clases  2. Usando el modelo, haga preguntas que requieran navegar a través del modelo para verificar que los objetos pueden, de hecho soportar la navegación. P.E., En el caso de uso “comprar asientos”, ¿puede obtener el nombre del evento que se debería imprimir en el boleto?.CAL/Fundamentos 88
  89. 89. Prueba De Clases Ejemplo 1. Para cada evento buscar todos las presentaciones. 2. Para cada presentación buscar mapaasientospresentación. 3. Para cada mapaasiento buscar asientopresentación. 4. Por cada asientopresentación buscar boleto. 5. Obtener el precio pagado por cada boleto.CAL/Fundamentos 89
  90. 90. Prueba De Clases Evento 1 1 0..* 1 1 Presentación MapaAsientosPresentación 1 3 2 0..* Asiento Presentación 1 Navegación utiliza 4 0..1 Boleto 5CAL/Fundamentos 90
  91. 91. Prueba De Clases  Durante la prueba de navegación del caso de uso, notará algunas veces que la ruta para responder en muy larga. No se preocupe, durante el diseño, se optimizará el modelo usando atajos llamados asociaciones derivadas.CAL/Fundamentos 91
  92. 92. Reconociendo Patrones  Resumen: tres formas de comparación entre diagramas:  Concordar los diferentes diagramas puede ser la forma mas efectiva de mejorar sus modelos. La revisión iterativa, el refinamiento y el mejoramiento mantienen el proceso y remueven cualquier elemento de pérdida de información.CAL/Fundamentos 92
  93. 93. Reconociendo Patrones  Patrones de reconciliación:  Casos de uso y escenarios.  Casos de uso y diagramas de clases.  Diagrama de clases y diagramas de interacción (secuencia).  Escenarios y diagramas de interacción.  Diccionario de datos y casos de uso.  Diccionario de datos y diagrama de clases.  Diagrama de objetos y diagrama de clases.CAL/Fundamentos 93
  94. 94. Reconociendo Patrones  Recordar que nada es inmutable, todo debiera ser cuestionado y probado . Utilice los diagramas como herramientas (mas que como fines) y aliente la participación retando al equipo a ver el problema.CAL/Fundamentos 94
  95. 95. Reconociendo Patrones  El modelado de objetos involucra el uso de diferentes diagramas para representar aspectos diferentes del dominio del problema. La comparación y contraste de estas diferentes vistas ayudan a revelar discrepancias y son oportunidades para mejorar y refinar.CAL/Fundamentos 95
  96. 96. Reconociendo Patrones  Se hace mejor el análisis creando rápidamente dibujos iniciales (borradores) de todos los diagramas. No se preocupe de que su análisis sea 100% correcto ni completo . Utilice los diagramas como una referencia para conversar; Actualice a medida que se identifican cambios. Capture el conocimiento inmediatamente para hacerlos disponible a todos en el proyecto.CAL/Fundamentos 96

×