El documento presenta los contenidos de la unidad 3 de diseño orientado a objetos, incluyendo casos de uso, diagramas de interacción y secuencia, patrones de diseño como creacionales, estructurales y de comportamiento, y patrones GRASP. También describe ejemplos de diagramas de colaboración para los casos de uso de un video club utilizando los patrones discutidos.

1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)

3. Soluciones con Objetos y Patrones Craig Larman, Cap. 19 Ingeniería en Sistemas de Información

4. DISEÑO DE SISTEMAS

5. DISEÑO DE SISTEMAS

6. DISEÑO DE SISTEMAS

7. DISEÑO DE SISTEMAS

8. DISEÑO DE SISTEMAS

9. DISEÑO DE SISTEMAS Patrones (GRASP)

10. DISEÑO DE SISTEMAS Patrones (GRASP)

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. 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. 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. 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. DISEÑO DE SISTEMAS

16. DISEÑO DE SISTEMAS

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

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

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 .

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 }

34. DISEÑO DE SISTEMAS

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

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