El documento habla sobre diagramas de clases en el diseño orientado a objetos. Explica que los diagramas de clases identifican las clases de software y sus métodos a partir de los diagramas de interacción y el modelo conceptual. También describe cómo representar las clases, agregar atributos, métodos, asociaciones y navegabilidad en los diagramas de clases.

1. Metodologías de Análisis y Diseño Unidad VIII Diseño O.O “ Diagrama de Clases” Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática Docente Jornada Parcial Universidad Viña del Mar

4. Diagramas de Clases Modelo de Dominio v/s Modelo de Diseño En el modelo de dominio, una Venta no representa una definición de software, sino que se trata de una abstracción de un concepto del mundo real acerca del cual estamos interesados en realizar una declaración. En cambio, los DCD expresan – para la aplicación de software – la definción de las clases como componentes de software.

5. Diagramas de Clases Modelo de Dominio v/s Modelo de Diseño Ejemplo: Registro Venta Captura 1 1 ..... Fecha esCompleta: Boolean hora Registro Venta Captura 1 1 Fecha esCompleta: Boolean hora finalizarVenta() introducirArticulo(..) realizarPago(..) crearLineaDeVenta(..) Modelo de Dominio Modelo de Diseño

6. Diagramas de Clases Modelo de Dominio v/s Modelo de Diseño Ejemplo: Un rectángulo con tres secciones para la definición de clase Métodos: hay parámetros pero no se especifican. Navegabilidad Información del tipo Registro Venta Captura 1 1 ..... Fecha esCompleta: Boolean hora finalizarVenta() introducirArticulo(..) realizarPago(..) crearLineaDeVenta(..)

7. Diagramas de Clases Identificación y representación de las clases de software El primer paso de los DCD como parte del modelo de la solución es identificar aquellas clases que participan en la solución software. Se pueden encontrar examinando todos los diagramas de interacción y listando las clases que se mencionan. En la aplicación de Punto de Venta (primer ciclo) ellas son: Registro, CatalogoDeProductos, Tienda, Pago, Venta, EspecificaciónDelProducto, LineaDeVenta. El siguiente paso es dibujar un diagrama de clases para estas clases e incluir los atributos que se identificaron previamente en el modelo del dominio que también se utilizan en el Diseño

8. Diagramas de Clases Identificación y representación de las clases de software Ejemplo: Registro ..... ....... Venta Fecha esCompleta hora ..... CatalogoDeProductos ..... ....... EspecificacionDeProductos Fecha esCompleta hora ..... Pago cantidad ....... Tienda Dirección nombre ....... LineaDeVenta cantidad .......

9. Diagramas de Clases Añadir los nombres de los métodos Se pueden identificar los nombres de los métodos analizando los diagramas de interacción. En general, el conjunto de todos los mensajes enviados a una clase X a lo largo de todos los diagramas de interacción indican la mayoría de los métodos que debe definir la clase X. : Registro : Venta 2: crearLineaVenta(espec,cant) Venta Fecha esCompleta: Boolean hora crearLineaDeVenta(..)

10. Diagramas de Clases Añadir los nombres de los métodos Ejemplo: Registro ..... FinalizarVenta() introduccirArticulo(..) crearNuevaVenta() realizarPago(..) Venta Fecha esCompleta hora seHaCompletado() crearLineaDeVenta(...) realizarPago(..) getTotal() CatalogoDeProductos ..... getEspecificacion(...) EspecificacionDeProductos Fecha esCompleta hora ..... Pago cantidad ....... Tienda Dirección nombre añadirVenta(..) LineaDeVenta cantidad getSubTotal()

15. Diagramas de Clases Incorporación de asociaciones y navegabilidad Cada extremo de la asociación se denomina Rol, y en los DCD el Rol podría decorarse con una flecha de navegabilidad. La navegabilidad es una propiedad del rol que indica que es posible navegar unidireccionalmente a través de la asociación desde los objetos de la clase origen a la clase destino. La navegabilidad implica visibilidad – normalmente visibilidad de atributo.

16. Diagramas de Clases Incorporación de asociaciones y navegabilidad Ejemplo: La flecha de navegabilidad indica que los objetos Registro están conectados unidireccionalmente con los objetos Venta La ausencia de la flecha de navegabilidad indica que no hay conexiones desde la venta al Registro. La clase Registro tendrá un atributo que referencia a un objeto A menudo se excluye el atributo VentaActual puesto que se sobreentiende de acuerdo con la asociación navegable desde el Registro a la Venta Registro Venta Captura 1 1 VentaActual : Venta Fecha esCompleta: Boolean hora finalizarVenta() introducirArticulo(..) realizarPago(..) crearNuvaVenta() crearLineaDeVenta(..) seHaCompletado() realizarPago(..) getTotal(..)

18. Diagramas de Clases Incorporación de asociaciones y navegabilidad La mayoría, por no decir todas, las asociaciones en los DCD deberían adornarse con las flechas de navegabilidad necesarias. Registra Registro ..... FinalizarVenta() introduccirArticulo(..) crearNuevaVenta() realizarPago(..) Venta Fecha esCompleta hora seHaCompletado() crearLineaDeVenta(...) realizarPago(..) getTotal() CatalogoDeProductos ..... getEspecificacion(...) EspecificacionDeProductos Fecha esCompleta hora ..... Pago cantidad ....... Tienda Dirección nombre añadirVenta(..) LineaDeVenta cantidad getSubTotal() Utiliza 1 1 Busca-en 1 1 1 1..+ 1 * 1..* 1 1. 1 1 1 Contiene Contiene Pagada-Mediante Alberga 1 1 Captura 1 * Describe

19. Diagramas de Clases Añadir relaciones de dependencia UML incluye una relación de dependencia general, que indica que un elemento (de cualquier tipo, como clases, casos de uso, etc.) tiene conocimiento de otro elemento. Se representa mediante una flecha de línea punteada. En los diagramas de clase la relación de dependencia es útil para describir la visibilidad entre clases que no es de atributo; en otras palabras, la declaración de visibilidad de parámetros, local y global. Por ejemplo, el objeto de software Registro recibe un objeto de retorno de tipo EspecificaciónDelProducto a partir del mensaje de especificación que envía al CatalogoDeProductos. El registro tiene una visibilidad local de la EspecificacionDeProducto.

20. Diagramas de Clases Añadir relaciones de dependencia Ejemplo Registra Registro ..... FinalizarVenta() introduccirArticulo(..) crearNuevaVenta() realizarPago(..) Venta Fecha esCompleta hora seHaCompletado() crearLineaDeVenta(...) realizarPago(..) getTotal() CatalogoDeProductos ..... getEspecificacion(...) EspecificacionDeProductos Fecha esCompleta hora ..... Pago cantidad ....... Tienda Dirección nombre añadirVenta(..) LineaDeVenta cantidad getSubTotal() Utiliza 1 1 Busca-en 1 1 1 1..+ 1 * 1..* 1 1. 1 1 1 Contiene Contiene Pagada-Mediante Alberga 1 1 Captura 1 * Describe

21. Patrones Adicionales Polimorfismo Implica “asignar el mismo nombre a servicios en varios objetos”, cuando los servicios se parecen o están relacionados entre ellos. Situación ¿Quién es responsable de autorizar cada tipo de pago? PagoconCheque PagoconTarjeta PagoenEfectivo Monto Ofrecido PagoconCheque monto

22. Patrones Adicionales Polimorfismo ¿Cómo manejar las alternativas basadas en el tipo? La variación condicional es un tema esencial en la programación. Si se diseña un programa mediante la lógica condicional if– then-else o case, habra que modificar la lógica del case cuando surja una variante. Este procedimiento dificulta extender un programa con otras variantes, porque los cambios tienden a requerirse en varios lugares donde exista la lógica condicional. Problema Polimorfismo Nombre Cuando por el tipo varían las alternativas o comportamientos afines, las responsabilidades del comportamiento se asignarán – mediante operaciones poliformicas – a los tipos en que el comportamiento presenta variantes. Solución

23. Patrones Adicionales Polimorfismo Es fácil agregar las futuras extensiones que requieren las variaciones imprevistas. Beneficios El patrón polimorfismo es concordante con el espíritu del patrón Experto. Es un principio fundamental en que se fundan las estrategias globales al diseñar cómo organizar un sistema para que se encargue del trabajo. Observaciones

24. Patrones Adicionales Polimorfismo Ejemplo: En la aplicación del punto de venta, ¿quién debería encargarse de autorizar las diversas clases de pagos?. El comportamiento de autorización varía con el tipo de pago –en efectivo, con tarjeta o con cheque; por eso, conforme al polimorfismo deberiamos asignar esa responsabilidad a cada tipo de pago, implementado con una aplicación polimorfica autorizada.

25. Patrones Adicionales Polimorfismo Ejemplo: Según el polimorfismo cada tipo de pago debe autorizarse a si mismo. PagoconCheque Autorizar() PagoconTarjeta Autorizar() PagoenEfectivo Monto Ofrecido Autorizar() PagoconCheque monto

26. Patrones Adicionales Fabricación Pura Situación Supongamos, que se necesita soporte para guardar las instancias venta en una base de datos relacional. En virtud del patrón Experto, en cierto modo se justifica asignar responsabilidades a la clase Venta. Observaciones La tarea requiere un número relativamente amplio de operaciones de soporte orientadas a la base de dato, ninguna de las cuales se relaciona con el concepto de Vender. La clase venta a de acoplarse a la interfaz de la base de datos relacional.

27. Patrones Adicionales Fabricación Pura Observaciones Guarda los objetos en una base de datos relacional es una tarea muy general en que debemos brindar mucho soporte. Por lo tanto, está asignación aumenta el acoplamiento y la cohesión de clase Venta.

28. Patrones Adicionales Fabricación Pura ¿A quién asignar la responsabilidad cuando está desesperado y no quiere violar los patrones de alta cohesión y Bajo Acoplamiento? Los diseños O.O se caracterizan por implementar como clases de software las representaciones de conceptos en el dominio de un problema del mundo real; por ejemplo, una Venta y Cliente. Pese a ello se dan muchas situaciones donde asignar responsabilidades exclusivamente a las clases del dominio origina problemas por una mala cohesión o acoplamiento o bien por un escaso potencial de reutilización. Problema Fabricación Pura Nombre Asignar un conjunto altamente cohesivo de responsabilidades a una clase artificial que no representa nada en el dominio del problema: una cosa inventada para dar soporte a una alta cohesión, un bajo acoplamiento y reutilización. La razón exclusiva para la incorporación de la clase artificial es por tanto una decisión de “fabricación pura”. Solución

29. Patrones Adicionales Fabricación Pura Alta cohesión y alto nivel de reutilización Beneficios Puede perderse el espíritu de los buenos diseños O.O que se centran en los objetos y no en las funciones. Si se abusa de ello, la creación de clases de Fabricación Pura, originará un diseño centrado en procesos o funciones que se implementa en un O.O. Desventajas -Para diseñar una Fabricación Pura debe buscarse ante todo un gran potencial de reutilización, asegurándose para ello de que sus responsabilidades sean pequeñas y cohesivas. -Estas clases tienen a tener un conjunto de responsabilidades de granularidad fina. - Una fabricación pura suele partirse atendiendo a su funcionalidad y, por lo mismo, es una especie de objeto de función central. Observaciones

30. Patrones Adicionales Fabricación Pura Ejemplo: Supongamos, por ejemplo, que se necesita soporte para guardar las instancias Venta en una base de datos relacional. Si se utiliza el patrón Experto (Venta sería el candidato lógico) se daría origen a un diseño de baja cohesión, alto acoplamiento y bajo potencial de reutilización. Una solución razonable consiste en crear una clase nueva que se encargue tan solo de guardar los objetos de algún tipo de almacenamiento persistente: una base de datos relacional. Según la Fabricación Pura AgentedeAlmacenamientoPersistente Guardar()

31. Patrones Adicionales Indirección Situación Dos componentes o servicios de un sistema se encuentran acoplados directamente. ¿A quién se asignaran las responsabilidades a fin de evitar el acoplamiento directo? ¿De qué, manera se desacoplan los objetos de modo que se obtenga un bajo acoplamiento y se conserve un alto potencial de reutilización? Problema Inderección Nombre Se asigna la responsabilidad a un objeto intermedio para que medie entre otros componentes o servicios, y éstos no terminen directamente acoplados. El intermediario crea una indirección entre el resto de los componentes o servicios. Solución

32. Patrones Adicionales Indirección Ejemplo 1: En el ejemplo anterior (Fabricación pura) para desacoplar la Venta y los servicios de la base de datos relacional en el cual se introduce la clase AgentedeAlmacenamientoPersistente tambien es un ejemplo de Indirección. La case AgentedeAlmacenamientoPersistente sirve de intermediario entre la Venta y la Base de datos. Ejemplo 2 : Patrón Publicar-Suscribir u Observar. Los objetos se suscriben a eventos ante un AdministradordeEventos; otros publican eventos para el AdministradordeEventos, que los notifica a los suscriptores. A través de la indirección del AdministradordeEventos se desacoplan los editores y los suscriptores.

33. Patrones Adicionales No hables con extraños ¿Cómo asignar responsabilidades para evitar conocer la estructura de objetos indirectos? Si un objeto cliente tiene que usar un servicio u obtener información a partir de un objeto indirecto, ¿cómo podrá hacerlo sin acoplarse al conocimiento de la estructura interna de su servidor directo o de los objetos indirectos?. Problema No hables con extraños Nombre Se asigna la responsabilidad a un objeto directo del cliente para que colabore con un objeto indirecto, de modo que el cliente no necesite saber nada del objeto indirecto. Esto impone restricciones sobre los objetos a los cuales deberíamos enviar mensajes. Dentro de un método los mensajes sólo pueden ser enviados: El mismo objeto, Un parámetro del método, un atributo, un elemento de una colección que sea atributo de él, un objeto creado en el interior del método. Solución

34. Patrones Adicionales No hables con extraños -No hables con extraños se refiere a no obtener una visibilidad temporal frente a objetos indirectos, que son de conocimiento de otros objetos pero no del cliente. -La desventaja de conseguir visibilidad ante extraños es la siguiente: La solución se acopla entonces a la estructura interna de otros objetos. Ello origina un alto acoplamiento. Observaciones Esto permite que los objetos (cliente) que requieren información de objetos indirectos eviten hablar con extraños “objetos indirectos”, al apoyarse en objetos directos que le permiten obtener dicha información. Solución

35. Patrones Adicionales No hables con extraños Ejemplo : En una aplicación del punto de venta, suponga que una instancia TPDV posee un atributo referente a una Venta, la cual cuenta con un atributo referente a un Pago . La instancias TPDV soportan la operación montodePago , que devuelve el actual monto ofrecido como pago. Las instancia Venta soporta la operación pago , la cual devuelve la instancia Pago asociada a la Venta

36. Patrones Adicionales No hables con extraños Ejemplo : TPDV::MontoPago() {pag: e_venta -> pago() //viola “No hables con extraños” Return pag->montoOfrecido(); } Está forma viola el patrón TPDV terminarVenta() introduccirProducto() efectuarPago() montodePago() Venta Fecha: Fecha Hora :Hora estaTerminada:Boolean Total() hacerLineadeProducto() efectuarPago() seTErmino() Pago() Pago Monto : Entero montoOfrecido() Captura Pagado-Por : TPDV : Venta pag: Pago montodePago() 2: imp:=montoOfrecido() : Float 1: pag: = pago(): Pago

37. Patrones Adicionales No hables con extraños Ejemplo : La solución, como lo indica el patrón, consiste en agregar la responsabilidad al objeto directo – la Venta , en este caso – para que devuelva a TPDV el monto del pago. Por lo tanto se agrega una operación montodePago para que TPDV no tenga que hablar con extraños. TPDV::MontoPago() { pag: e_venta -> montodepago() } A Venta se le agrega la operación montodePago() : TPDV : Venta pag: Pago montodePago() 2: imp:=montoOfrecido() : Float 1: imp: = montodePago()