Soluciones con objetos y patrones. visibilidad

9,346 views

Published on

U.T.N. - F.R.T. - Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad III. Soluciones con Objetos y Patrones. Visibilidad

Published in: Travel
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,346
On SlideShare
0
From Embeds
0
Number of Embeds
7,333
Actions
Shares
0
Downloads
125
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Soluciones con objetos y patrones. visibilidad

  1. 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  2. 2. Contenidos de la Unidad 3 Diseño Orientado a Objetos I <ul><li>Diseño orientado a Objeto I </li></ul>Craig Larman , Cap 15. <ul><li>Casos de Uso Reales </li></ul>  Cap. 16 <ul><li>Diagrama de Interacción </li></ul>  Cap. 17 <ul><ul><li>Diagrama de Secuencia. </li></ul></ul>  <ul><ul><li>Diagramas de Comunicación (UML 2)/ Colaboración (UML 1.1) </li></ul></ul>  <ul><li>Patrones de Diseño. </li></ul>Cap. 18 <ul><ul><li>Patrones creacionales </li></ul></ul>  <ul><ul><li>Patrones Estructurales </li></ul></ul>  <ul><ul><li>Patrones de Comportamiento </li></ul></ul>  <ul><ul><li>GRAPS (Experto, Creador, Alta Cohesión, Bajo Acoplamiento, Controlador) </li></ul></ul> 
  3. 3. Soluciones con Objetos y Patrones Craig Larman, Cap. 19 Ingeniería en Sistemas de Información
  4. 4. DISEÑO DE SISTEMAS
  5. 5. DISEÑO DE SISTEMAS
  6. 6. DISEÑO DE SISTEMAS
  7. 7. DISEÑO DE SISTEMAS
  8. 8. DISEÑO DE SISTEMAS
  9. 9. DISEÑO DE SISTEMAS Patrones (GRASP)
  10. 10. DISEÑO DE SISTEMAS Patrones (GRASP)    
  11. 11. DISEÑO DE SISTEMAS Para elaborar un Diagrama de Colaboración efectivo necesitamos contar con las Responsabilidades y las Postcondiciones , que hemos estudiado en los Contratos . En caso de omitir la preparación del contrato, de todos modos deberíamos elaborar los diagramas de interacción retornando a los casos de uso y reflexionando sobre los cambios que cada operación genera en el sistema, para poder elaborar los Diagramas de Colaboración . Los contratos organizan y aíslan la información en un formato funcional, y estimulan la investigación en la fase de análisis y no en la de diseño, ahorrándonos trabajo y problemas.
  12. 12. DISEÑO DE SISTEMAS Las postcondiciones son sólo una estimación: Los diagramas se deben preparar para cumplir con las postcondiciones del contrato. Por eso, las postcondiciones definidas de antemano son una excelente conjetura o estimación inicial de lo que se pretende alcanzar; aunque tal vez no sean muy exactas. Lo mismo sucede con el modelo conceptual: es un punto de partida que contendrá errores y omisiones. Los contratos son un mero punto de partida para establecer lo que se hará, pero sin sentirnos obligados por ellos. Lo más probable es que algunas postcondiciones no sean necesarias y que haya algunas tareas por realizar aún no descubiertas.
  13. 13. DISEÑO DE SISTEMAS Los Diagramas de Interacción y el Modelo Conceptual: Algunos objetos que interactúan (a través de mensajes) en los Diagramas de Colaboración provienen del Modelo Conceptual . Utilizamos información del Modelo Conceptual para asignar responsabilidades con los patrones GRASP . Ahora bien: ¿todos los objetos en interacción saldrán necesariamente del Modelo Conceptual? De ninguna manera; durante la fase de diseño podemos descubrir otros objetos nuevos, que no figuran en los análisis anteriores.
  14. 14. DISEÑO DE SISTEMAS DIAGRAMAS DE COLABORACION – VIDEO CLUB: A continuación, desarrollaremos los Diagramas de Colaboración para el caso de uso Alquiler de video del caso de estudio del Video Club. El diagrama de colaboración: introducirSocio: La operación del sistema introducirSocio ocurre cuando el Cajero captura el Código del Socio. Debemos contar con un Diagrama de Colaboración que cumpla con las Postcondiciones de introducirSocio .
  15. 15. DISEÑO DE SISTEMAS
  16. 16. DISEÑO DE SISTEMAS
  17. 17. DISEÑO DE SISTEMAS <ul><li>Realización de un alquiler: </li></ul><ul><li>Ahora, repasamos las Postcondiciones, expresadas en los contratos, (de introducirSocio ); que establecen lo siguiente: </li></ul><ul><li>Se creó un Alquiler ( creación de instancia ). </li></ul><ul><li>Se asoció el Alquiler a Socio ( asociación formada ). </li></ul>
  18. 18. DISEÑO DE SISTEMAS Primero, tenemos una responsabilidad de creación. Con lo cual, utilizamos el patrón Creador ; el cual indica la asignación de la responsabilidad de generar una clase que agregue, contenga o registre la que va a ser creada. Al analizar el Modelo Conceptual , descubrimos que Caja nos permite ver el registro de un Alquiler ; con lo que Caja sería un buen candidato para crear un Alquiler . Sin embargo, perderíamos la posibilidad de asociar Alquiler con Socio ; por lo tanto, es mejor asignar a Socio la responsabilidad de crear el Alquiler .
  19. 19. DISEÑO DE SISTEMAS Además, cuando se crea el Alquiler , hay que generar una colección vacía (un contenedor) para que registre todas las instancias futuras AlquilerLineadeVideo que vayamos agregando. En conclusión, el objeto Socio crea un Alquiler y éste, a su vez, genera una colección vacía, representada por un multiobjeto en el Diagrama de Colaboración .
  20. 20. DISEÑO DE SISTEMAS Creación de Alquileres 2.1: crear () introducirSocio(codigo) 2: hacerAlquiler() : Caja :AlquilerLinea deVideo soc:Socio 2.2: Crear () :Socio 1: soc:=encontrar(codigo) :Alquiler según Controlador según Creador según Creador
  21. 21. DISEÑO DE SISTEMAS Mensajes a multiobjetos: Un mensaje enviado a un multiobjeto se envía a todos los elementos de la colección / contenedor. Por ejemplo, en el Diagrama de Colaboración introducirSocio : El mensaje crear (2.2) enviado al multiobjeto AlquilerLineadeVideo tiene por objeto generar la estructura de datos colección representada por el multiobjeto. Su finalidad no es crear una instancia de la clase AlquilerLineadeVideo .
  22. 22. DISEÑO DE SISTEMAS El Diagrama de Colaboración: introducirVideo La operación del sistema introducirVideo ocurre cuando el Cajero captura el código de Video. Con las Postcondiciones de introducirVideo se construirá un Diagrama de Colaboración. Cada vez que se emita un mensaje debemos asignar una responsabilidad. Selección de la case Controlador: Igual que en el diagrama anterior, utilizaremos Caja como Controlador.
  23. 23. DISEÑO DE SISTEMAS <ul><li>Análisis de las Postcondiciones de introducirVideo : </li></ul><ul><li>Las Postcondiciones Contractuales de introducirVideo establecen lo siguiente: </li></ul><ul><li>Se creó una instancia AlquilerLineadeVideo ( creación de instancia ). </li></ul><ul><li>Se asoció AlquilerLineadeVideo al Alquiler ( asociación formada ). </li></ul><ul><li>Se asoció la instancia AlquilerLineadeVideo con Video a partir de la correspondencia en el código ( asociación formada ). </li></ul><ul><li>Se asignó el valor verdadero a Video.estado ( modificación de atributo ). </li></ul>
  24. 24. DISEÑO DE SISTEMAS Lo anterior indica la responsabilidad de crear una instancia AlquilerLineadeVideo . El análisis del Modelo Conceptual revela que el Alquiler contiene los objetos AlquilerLineadeVideo ; por lo tanto, aplicando el patrón Creador ; Alquiler es un buen candidato para generar la línea de video . Al hacer esto, asociamos automáticamente el Alquiler con la línea a lo largo del tiempo, al guardar esta nueva colección .
  25. 25. DISEÑO DE SISTEMAS Obtención de una instancia Video: Debemos ahora asociar la instancia AlquilerLineadeVideo a Video , por concordancia del código que se recibe. Esto significa que se requiere recuperar un Video basado en la correspondencia del código . En este caso, no estamos ante un problema de creación ni de escoger un controlador. Entonces, aplicamos el patrón Experto GRASP en primer lugar. ¿ Quién está enterado de todo lo concerniente a Video ?: El análisis del Modelo Conceptual revela que VideoClub contiene a todos los Videos y así, siguiendo al patrón Experto , VideoClub es idóneo para asumir esa responsabilidad de consulta .
  26. 26. DISEÑO DE SISTEMAS Establecimiento del atributo Video.estado: ¿Quién debería encargarse de asignar el valor verdadero al atributo estado del Video ? Basándonos en el patrón Experto, debería ser el mismo Video , porque posee el atributo estado. Así VideoClub enviará a la instancia Video el mensaje seAlquila para asignarle el valor verdadero , el Video quede registrado como «alquilado», y por ende, no disponible para una nueva transacción de Alquiler.
  27. 27. DISEÑO DE SISTEMAS Diagrama de colaboración introducirVideo introducirVideo(codigo) 2: hacerAlquilerLineadeVideo(vid) : Caja :AlquilerLinea deVideo 2.2:agregar (da) :Video 1: vid:=extraer(codigo) :Alquiler según Controlador según Creador :VideoClub 1.1: vid:=encontrar(codigo) vid:Video 3: alquilado() 2.1: crear(vid) da:AlquilerLineadeVideo según Experto
  28. 28. DISEÑO DE SISTEMAS <ul><li>Mensajes a multiobjetos: </li></ul><ul><li>En este diagrama de colaboración, los mensajes a multiobjetos son los siguientes: </li></ul><ul><li>El mensaje encontrar (1.1) enviado al multiobjeto Video . </li></ul><ul><li>El mensaje agregar (2.2) enviado al multiobjeto AlquilerLineadeVideo , tiene por objeto incorporar un elemento a la estructura de datos colección. </li></ul>
  29. 29. DISEÑO DE SISTEMAS El diagrama de colaboración: terminarAlquiler La operación terminarAlquiler ocurre cuando un Cajero oprime un botón para indicar la conclusión de un alquiler. Se elaborará un Diagrama de Colaboración para cumplir las Postcondiciones de terminarAlquiler . Cada decisión sobre mensajes implica asignar Responsabilidades, y los patrones GRASP se emplearán para escogerlos y justificarlos. Selección de la clase Controlador: Basándonos en el patrón Controlador de GRASP, seguiremos utilizando Caja .
  30. 30. DISEÑO DE SISTEMAS <ul><li>Establecimiento de los atributos de Alquiler: </li></ul><ul><li>Las Postcondiciones contractuales establecen lo siguiente: </li></ul><ul><li>Se asignó el valor FechaActual a Alquiler.fecha ( modificación de atributo ). </li></ul><ul><li>Se asignó el valor HoraActual a Alquiler.hora ( modificación de atributo ). </li></ul><ul><li>Como siempre, el Patrón Experto debe ser el primero a considerar, salvo para problemas de controlador o de creación. </li></ul><ul><li>En este caso, el Experto debería ser el propio Alquiler , puesto que éste tiene los atributos fecha y hora. De esta manera, Caja enviará a Alquiler el mensaje seTermina , para modificar los atributos anteriores. </li></ul>
  31. 31. DISEÑO DE SISTEMAS Terminación de la captura de videos terminarAlquiler() 2: seTermina() : Caja :Alquiler según Controlador según Experto seTermina() { fecha := FechaActual hora:= HoraActual }
  32. 32. <ul><li>La presentación visual de información: </li></ul><ul><li>En las responsabilidades del contrato terminarAlquiler se estipula que debe mostrarse el total del alquiler. </li></ul><ul><li>Se trata de una cuestión de quién debe encargarse de presentar visualmente la información, en una ventana gráfica. </li></ul><ul><li>Se sugiere que la capa de los objetos del dominio (Alquiler, VideoClub, Caja, etc.) no debieran conocer las ventanas o la capa de presentación o tener comunicación con ellas. </li></ul>DISEÑO DE SISTEMAS
  33. 33. DISEÑO DE SISTEMAS <ul><li>Cálculo del total del Alquiler : </li></ul><ul><li>El Patrón Experto debe ser el primero en considerarse. </li></ul><ul><li>¿Quién debe asumir la responsabilidad de realizar el alquiler? Según el patrón Experto, el propio alquiler, porque conoce todo lo concerniente a AlquilerLineadeVideo . Por consiguiente Alquiler es el responsable de calcularlo, y se implementa como una operación total. </li></ul><ul><li>b) Para que Alquiler calcule el total, necesita conocer el precio de cada video en la línea de video. ¿Quién debería asumir la responsabilidad de ofrecer el precio?. </li></ul><ul><li>Según el patrón Experto , debería ser: AlquilerLineadeVideo , que esta asociado a Video . Por lo tanto AlquilerLineadeVideo tendrá esta responsabilidad, que se implementa con la operación subtotal . </li></ul>
  34. 34. DISEÑO DE SISTEMAS
  35. 35. DISEÑO DE SISTEMAS Calculo del Total de la Venta 2.1 : p := precio () 2 : st := subtotal() t:= total()  :Alquiler alv:=:ALV vid:Video :AlquilerLineade Video 1*:[p/c] alv:= siguiente()  según Experto según Experto
  36. 36. DISEÑO DE SISTEMAS El diagrama de colaboración: efectuarPago La operación sistémica efectuarPago ocurre cuando un cajero captura el efectivo ofrecido como pago. Se construirá un diagrama de colaboración para cumplir con las Postcondiciones de efectuarPago. Elección del Controlador: Nuestra primera decisión se refiere a la responsabilidad del manejo de los mensajes. Con base en el patrón Controlador seguiremos empleando a la Caja como controlador .
  37. 37. DISEÑO DE SISTEMAS <ul><li>Creación del Pago: </li></ul><ul><li>Postcondiciones contractuales: </li></ul><ul><li>“ se creó un Pago” ( creación de instancia ). </li></ul><ul><li>¿Quién registra, agrega o contiene un Pago ?: </li></ul><ul><li>Como resulta atractivo afirmar que la Caja registra lógicamente un Pago , se pensará que Caja es idónea para crearlo. Sin embargo, Alquiler está estrechamente ligado a su Pago ; de ahí la posibilidad de que sea un buen candidato también para crearlo. </li></ul><ul><li>En conclusión, tenemos dos candidatos: </li></ul><ul><li>1º) Caja </li></ul><ul><li>2º) Alquiler </li></ul>
  38. 38. DISEÑO DE SISTEMAS En estos casos, en que tenemos varios buenos candidatos, conviene hacer jugar a los restantes patrones de: Bajo acoplamiento y Alta cohesión . Si escogemos el objeto “ Alquiler ” para crear un Pago , las responsabilidades de Caja serán mas ligeras, y dará origen a una definición mas simple de Caja . Además no necesita saber que existe una instancia Pago , porque podemos registrarla indirectamente mediante el Alquiler . Con lo cual, el diagrama de colaboración sería así:
  39. 39. DISEÑO DE SISTEMAS Diagrama de colaboración efectuarPago 1: efectuarPago (efecOfrecido) :Caja : Alquiler :Pago efectuarPago (efecOfrecido) 1.1: crear (efecOfrecido) según Controlador según Creador y Bajo Acoplamiento
  40. 40. DISEÑO DE SISTEMAS Calcular el vuelto: Como es habitual el patrón Experto será el primero en considerarse, y habrá que formular la responsabilidad en los siguientes términos: ¿Quién asume la responsabilidad de conocer el vuelto? Para calcular el vuelto, necesitamos el total del alquiler y el pago en efectivo ofrecido. Por lo tanto: Alquiler y Pago son expertos parciales para la solución de este problema. Si Pago es el principal responsable de conocer el saldo, necesitará ser visible al Alquiler para pedirle su total. Como por ahora no lo conoce, con este método aumentará el acoplamiento global del diseño: y por lo tanto, no soportará el patrón de Bajo Acoplamiento .
  41. 41. DISEÑO DE SISTEMAS En cambio si el Alquiler es el principal responsable de conocer el saldo, necesitara ser visible al Pago para pedirle el monto ofrecido. Dado que Alquiler ya es visible al Pago (por ser su Creador ), con este enfoque no aumenta el acoplamiento global, de ahí que es preferible elegir a Alquiler , para asignarle la responsabilidad e . El diagrama de colaboración será el siguiente: El diagrama de colaboración alquiler-saldo :Pago 1: mon:= monto() sal:= saldo() 2:t := total() :Alquiler

×