Metodologías de Análisis y Diseño Unidad VIII Diseño O.O  “ Diagrama de Clases” Sergio Sánchez Rios. Ingeniero en Informát...
Diagramas de Clases Introducción <ul><li>Completando los diagramas de interacción, es posible identificar la especificació...
Diagramas de Clases Introducción <ul><li>Características </li></ul><ul><li>Un diagrama de clases (DCD) representa las espe...
Diagramas de Clases Modelo de Dominio v/s Modelo de Diseño En el modelo de dominio, una Venta no representa una definición...
Diagramas de Clases Modelo de Dominio v/s Modelo de Diseño Ejemplo: Registro Venta Captura 1 1 ..... Fecha esCompleta: Boo...
Diagramas de Clases Modelo de Dominio v/s Modelo de Diseño Ejemplo: Un rectángulo con tres secciones para la definición de...
Diagramas de Clases Identificación y representación de las clases de software El primer paso de los DCD como parte del mod...
Diagramas de Clases Identificación y representación de las clases de software Ejemplo: Registro ..... ....... Venta Fecha ...
Diagramas de Clases Añadir los nombres de los métodos Se pueden identificar los nombres de los métodos analizando los diag...
Diagramas de Clases Añadir los nombres de los métodos Ejemplo: Registro ..... FinalizarVenta() introduccirArticulo(..) cre...
Diagramas de Clases Añadir los nombres de los métodos <ul><li>Se deben tener en cuenta los siguientes aspectos especiales ...
Diagramas de Clases Añadir los nombres de los métodos <ul><li>Se deben tener en cuenta los siguientes aspectos especiales ...
Diagramas de Clases Añadir los nombres de los métodos <ul><ul><li>Interpretación de los mensajes dirigidos a multiobjetos ...
Diagramas de Clases Añadir los nombres de los métodos <ul><li>Es opcional mostrar el tipo de los atributos, los parámetros...
Diagramas de Clases Incorporación de asociaciones y navegabilidad Cada extremo de la asociación se denomina Rol, y en los ...
Diagramas de Clases Incorporación de asociaciones y navegabilidad Ejemplo: La flecha de navegabilidad indica que los objet...
Diagramas de Clases Incorporación de asociaciones y navegabilidad <ul><li>Como base es necesario definir una asociación co...
Diagramas de Clases Incorporación de asociaciones y navegabilidad La mayoría, por no decir todas, las asociaciones en los ...
Diagramas de Clases Añadir relaciones de dependencia UML incluye una  relación de dependencia  general, que indica que un ...
Diagramas de Clases Añadir relaciones de dependencia Ejemplo Registra Registro ..... FinalizarVenta() introduccirArticulo(...
Patrones Adicionales  Polimorfismo Implica “asignar el mismo nombre a servicios en varios objetos”, cuando los servicios s...
Patrones Adicionales  Polimorfismo ¿Cómo manejar las alternativas basadas en el tipo? La variación condicional es un tema ...
Patrones Adicionales  Polimorfismo Es fácil agregar las futuras extensiones que requieren las variaciones imprevistas. Ben...
Patrones Adicionales  Polimorfismo Ejemplo: En la aplicación del punto de venta, ¿quién debería encargarse de autorizar la...
Patrones Adicionales  Polimorfismo Ejemplo: Según el polimorfismo cada tipo de pago debe autorizarse a si mismo. PagoconCh...
Patrones Adicionales  Fabricación Pura Situación Supongamos, que se necesita soporte para guardar las instancias venta en ...
Patrones Adicionales  Fabricación Pura Observaciones Guarda los objetos en una base de datos relacional es una tarea muy g...
Patrones Adicionales  Fabricación Pura ¿A quién asignar la responsabilidad cuando está desesperado y no quiere violar los ...
Patrones Adicionales  Fabricación Pura Alta cohesión y alto nivel de reutilización Beneficios Puede perderse el espíritu d...
Patrones Adicionales  Fabricación Pura Ejemplo: Supongamos, por ejemplo, que se necesita soporte para guardar las instanci...
Patrones Adicionales  Indirección Situación Dos componentes o servicios de un sistema se encuentran acoplados directamente...
Patrones Adicionales  Indirección Ejemplo 1: En el ejemplo anterior (Fabricación pura) para desacoplar la Venta y los serv...
Patrones Adicionales  No hables con extraños ¿Cómo asignar responsabilidades para evitar conocer la estructura de objetos ...
Patrones Adicionales  No hables con extraños -No hables con extraños se refiere a no obtener una visibilidad temporal fren...
Patrones Adicionales  No hables con extraños Ejemplo : En una aplicación del punto de venta, suponga que una instancia  TP...
Patrones Adicionales  No hables con extraños Ejemplo : TPDV::MontoPago() {pag: e_venta -> pago() //viola “No hables con ex...
Patrones Adicionales  No hables con extraños Ejemplo : La solución, como lo indica el patrón, consiste en agregar la respo...
<ul><li>Guía del Tópico: </li></ul><ul><li>Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000. (Cap....
Upcoming SlideShare
Loading in...5
×

Unidad 10 Mad Diagrama De Clases

4,853

Published on

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

No Downloads
Views
Total Views
4,853
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
189
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Unidad 10 Mad Diagrama De Clases

  1. 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
  2. 2. Diagramas de Clases Introducción <ul><li>Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando detalles de su implementación, como por ejemplo los métodos . </li></ul><ul><li>Entradas de los Diagramas de Clases </li></ul><ul><ul><li>Diagramas de interacción, a partir de ellos el diseñador identifica las clases de software y sus métodos. </li></ul></ul><ul><ul><li>Modelo conceptual, a partir de éste el diseñador agregar detalle a la definición de las clases. </li></ul></ul>
  3. 3. Diagramas de Clases Introducción <ul><li>Características </li></ul><ul><li>Un diagrama de clases (DCD) representa las especificaciones de las clases e interfaces de software (por ejemplo, las interfaces de java) en una aplicación. Entre la información general que entregan se encuentran: </li></ul><ul><ul><ul><li>Clases, asociaciones y atributos. </li></ul></ul></ul><ul><ul><ul><li>Interfaces con sus operaciones y constantes. </li></ul></ul></ul><ul><ul><ul><li>Métodos. </li></ul></ul></ul><ul><ul><ul><li>Información acerca del tipo de los atributos. </li></ul></ul></ul><ul><ul><ul><li>Navegabilidad. </li></ul></ul></ul><ul><ul><ul><li>Dependencias. </li></ul></ul></ul>
  4. 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. 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. 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. 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. 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. 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. 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()
  11. 11. Diagramas de Clases Añadir los nombres de los métodos <ul><li>Se deben tener en cuenta los siguientes aspectos especiales respecto a los nombres de los métodos. </li></ul><ul><ul><li>Interpretación del mensaje create(): Por ser la inicialización una actividad muy común, se acostumbra a omitir los métodos de creación. Se supone por default. </li></ul></ul><ul><ul><li>Descripción de los métodos de acceso: </li></ul></ul><ul><ul><ul><li>Son aquellos que establecen o recuperan el valor de los atributos. </li></ul></ul></ul><ul><ul><ul><li>Implican un accesor (métodos de obtención) y un mutador (métodos de cambio) para cada atributo. </li></ul></ul></ul><ul><ul><ul><li>Por su amplia utilización se omiten. Se suponen por defecto. </li></ul></ul></ul>
  12. 12. Diagramas de Clases Añadir los nombres de los métodos <ul><li>Se deben tener en cuenta los siguientes aspectos especiales respecto a los nombres de los métodos. </li></ul><ul><ul><li>Interpretación de los mensajes dirigidos a multiobjetos: Un mensaje a un multiobjeto se interpreta como si estuviera destinado al objeto contenedor /colección. </li></ul></ul>El mensaje getSubTotal() está destinado al objeto contenedor , no a una LineaDeVenta : lineadeVenta : Venta 1*:st:=getSubTotal() *
  13. 13. Diagramas de Clases Añadir los nombres de los métodos <ul><ul><li>Interpretación de los mensajes dirigidos a multiobjetos </li></ul></ul><ul><ul><li>Estas clases contenedor/colección son clases predefinidas de las bibliotecas, y rara vez sirve mostrarlas explícitamente en el diagrama respectivo porque incorpora ruido y aportan escasa información nueva. </li></ul></ul>
  14. 14. Diagramas de Clases Añadir los nombres de los métodos <ul><li>Es opcional mostrar el tipo de los atributos, los parámetros del método y los valores de devolver método. </li></ul><ul><li>El diagrama de clases orientado al diseño debería elaborarse teniendo en cuenta la audiencia: </li></ul><ul><ul><li>Si vamos a crearlo a una herramienta CASE con generación automática de código se requerirán detalles completos y exhaustivos. </li></ul></ul><ul><ul><li>Si vamos a crearlo para los diseñadores de software, el exceso de información puede influir negativamente en su efectiva comprensión. </li></ul></ul>
  15. 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. 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(..)
  17. 17. Diagramas de Clases Incorporación de asociaciones y navegabilidad <ul><li>Como base es necesario definir una asociación con una flecha de navegabilidad de A a B cuando: </li></ul><ul><ul><li>A envía un mensaje a B. </li></ul></ul><ul><ul><li>A crea una instancia de B. </li></ul></ul><ul><ul><li>A necesita mantener una conexión con B. </li></ul></ul>
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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()
  38. 38. <ul><li>Guía del Tópico: </li></ul><ul><li>Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000. (Cap. 6) </li></ul><ul><li>Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002. </li></ul><ul><li>Utilización de UML en ingeniería del software con objetos y componentes – Perdita Stevens & Rob Pooley – Addison Wesley – 2002. </li></ul><ul><li>UML y Patrones una introducción al análisis y diseño orientados a objeto y al proceso unificado – Craig Larman – Prentice Hall - 2002. </li></ul>Bibliografía
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×