1 / 18

Relaciones entre Objetos

GRC Informatica http://www.grch.com.ar – ISFT 189 - UNLu - UTN FRD -. Relaciones entre Objetos. Composicion (I) Definición. Relación del tipo “todo/parte”.

karik
Download Presentation

Relaciones entre Objetos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GRC Informatica http://www.grch.com.ar – ISFT 189 - UNLu - UTN FRD - Relaciones entre Objetos

  2. Composicion (I) Definición • Relación del tipo “todo/parte”. • Indica una contención física, de manera que el objeto compuesto (todo) contiene físicamente a cada uno de sus objetos componentes (partes). • Ciclo de vida de los objetos fuertemente ligados: cuando se crea el objeto compuesto también se crean cada una de sus partes (opcional). Cuando se destruye el objeto compuesto, se destruyen sus partes.

  3. Composicion (II) Definición • “Es una forma de agregación que requiere que una instancia parte sea incluída en al menos algo compuesto por vez, y que el objeto compuesto es responsable de la creación y destrucción de las partes.” [OMG, pag 540] • No reflexiva • UML: diamante sólido

  4. Composicion (III) Implementación • El objeto compuesto contiene un arreglo o colección de referencias a objetos parte. • Los objetos parte son creados en el constructor del objeto compuesto o bien el objeto compuesto posee un método para crear instancias de las partes que lo componen. • En el destructor del objeto compuesto, se destruyen las instancias de las partes.

  5. Asociación (I) Definición • Relación de tipo “HAS A” • Muy común y semánticamente débil • “es una relación denotando una conexión semántica entre dos clases.” [Booch,pag 512] • “relación semántica entre dos o más clasificadores que especifican conexiones entre sus instancias” [OMG,pag 537] • Dimensiones de una asociación: [OO-226] • Roles que desempeña cada clase • Multiplicidad (cardinalidad) de cada rol • Dirección (navegabilidad) de la asociación • UML: linea sólida indicando rol y multiplicidad

  6. Asociación (II) Implementación • “Las asociaciones bidireccionales violan la encapsulación y comprometen la reutilización de las clases” [Graham et al., 1997] • Proponen utilizar asociaciones unidireccionales, mappings, que preserven la encapsulación, integrando en el objeto las reglas de negocio, accesibles a través de la interfaz de dicho objeto • Los mappings unidireccionales se implementan como punteros embebidos en los objetos, acoplados con reglas que preserven la integridad semántica y referencial • Multiplicidad “a uno” -> requiere una única referencia • Multiplicidad “a muchos” -> requiere un arreglo o colección de referencias (orden)

  7. Asociación (III) Implementación • Bidireccionales: “se pueden seguir tres aproximaciones para su implementación” [Rumbaugh et al., 1991]: • Como un solo atributo, en un único sentido y se realiza una búsqueda cuando se requiere acceso en otro sentido • Esta aproximación sólo es útil si hay una gran disparidad entre las frecuencias de recorrido en los dos sentidos, y si además es importante minimizar el coste de almacenamiento y el de actualización • Como atributos en ambas direcciones usando referencias • Esto permite un acceso rápido, pero si se actualiza alguno de los atributos también el otro atributo deberá actualizarse para mantener la congruencia del enlace, lo que conduce a una ruptura de la encapsulación. Esta aproximación es útil cuando el número de accesos supera al de las actualizaciones

  8. Asociación (IV) • Bidireccionales: “se pueden seguir tres aproximaciones para su implementación” [Rumbaugh et al., 1991] (continuación): • Como un objeto de asociación por separado, independiente de ambas clases • Un objeto de asociación es un conjunto de parejas de objetos asociados

  9. Agregación (I) Definición • Relación de tipo todo/parte, una forma fuertemente acoplada de asociación • Es transitiva, esto es, si A es parte de B y B es parte de C, entonces A es parte de C • Es antisimétrica, si A es parte de B, entonces B no es parte de A • Ciclo de vida de los objetos no ligados: Se pueden crear y destruir instancias de cada clase involucrada en la relación de forma independiente • Puede ser reflexiva • UML: diamante vacío

  10. Agregación (II) Implementación • El objeto todo contiene un arreglo o colección de referencias a objetos parte. • Las referencias a objetos parte son asociadas en el constructor del objeto todo o bien el objeto todo posee un método para agregar referencias de las partes.

  11. Herencia (I) Definición • Relación de tipo “IS A”, generalización - especialización • “un mecanismo en donde una clase es definida en referencia a otras, agregando como propias todas sus carácterísticas” [Meyer, pag 1197] • En sentido familiar: es la adquisición de propiedades de generaciones anteriores • permite hacer nuevas descripciones de objetos basándose en descripciones existentes: sólo se necesita declarar de forma explícita las propiedades en las que difiere de las clases existentes, tomando el resto de éstas automáticamente.

  12. Herencia (II) Definición • “es una relación entre clases en la que una clase comparte la estructura y/o el comportamiento definidos en una (herencia simple) o más clases (herencia múltiple)” [Booch,1994] • Los términos hijo y padre, derivada y base, subclase y superclase se utilizan para nombrar a una clase que hereda de otra y a esta última, respectivamente • La herencia es transitiva [Marqués, 1995] • Ancestros y descendientes

  13. Herencia (III) Definición • Características de la herencia: [OO-226] • Atributos y métodos de la superclase son incluídos en la subclase • Los métodos de la subclase puede sobre-escribir los métodos de la superclase • Una subclase puede heredar de múltiples superclases (herencia múltiple) o una subclase puede solamente heredar de una única superclase (herencia simple) • “La herencia múltiple es como un paracaídas: no siempre se necesita, pero cuando así ocurre, uno está verdaderamente feliz de tenerlo a mano” [Booch, 1994] • La herencia múltiple puede incurrir en colisiones • Diseño: regla “es un” • UML: flecha sólida (apuntando a superclase) con linea sólida

  14. Herencia (IV) Implementación • Java: uso de palabra reservada “extends” • Importancia de los modificadores de acceso: public, private, friend (o default), protect y el package al que pertenezca la superclase y la subclase • Importancia de la implementación o regla de constructor nulo. No herencia de constructor. • Uso de super y this • Upcasting (seguro) / Downcasting (inseguro) • Polimorfismo • Sobre-escritura (overriding) <-> method signature • Sobrecarga (overloading) <-> method signature

  15. Realización (I) Definición Interfase • Interfase: conjunto de métodos que expresan una determinada funcionalidad (prototipo) • “Un conjunto de operaciones referenciado por un nombre y que caracteriza el comportamiento de un elemento” [OMG, 2003] • forma de declarar un tipo que se compone sólo de métodos abstractos y constantes, posibilitando que se escriba cualquier implementación para estos métodos • una expresión de diseño puro, mientras que una clase es una mezcla de diseño e implementación • Todos sus métodos son abstractos, public, no static • Todos sus atributos son static, final • Pueden participar en relaciones de tipo generalización / especialización (supertipos / subtipos) -> palabra “extends” • Las definiciones de interfaz crean nombres de tipo igual que las definiciones de clase -> polimorfismo

  16. Realización (II) Implementación • Java: uso de palabra reservada “implements” • Realización = clase que implementa una interfase • Una clase que implemente una interfaz debe implementar todos los métodos o ser declarada abstracta • Una clase puede implementar n interfases -> conflictos por métodos con igual signature • El tipo completo de la clase que implementa la interfaz X incluye todos sus supertipos de X -> polimorfismo (Se puede usar el nombre de una interfaz como nombre de tipo de una variable y cualquier objeto que implemente esa interfaz se puede asignar a esa variable) • Una clase puede implementar los métodos de una interfaz de cualquier forma que elija el diseñador de la clase • UML: flecha sólida (apuntando a interfase) con linea punteada

  17. Otras Relaciones • Relación de Uso / Dependencia • relación del tipo “cliente-servidor” • Cuando un método toma una instancia de otra clase y dentro del mismo llama a los servicios de la otra clase • “posible refinamiento de una asociación, por el que se establece qué abstracción es el cliente y qué abstracción es el servidor que proporciona ciertos servicios” [Booch, 1994] • UML: flecha (punta abierta) con linea no continua

  18. Referencias • [Booch, 1994] Booch, G. “Object Oriented Analysis and Design with Applications”. 2nd Edition. The Benjamin/Cummings Publishing Company, 1994 • [Graham et al., 1997] Graham, I, Bischof, J., Henderson-Sellers, B. “Associations Considered a Bad Thing”. Journal of Object-Oriented Programming (JOOP), 9(9):41-48. February 1997 • [Marqués, 1995] Marqués Corral, J. M. “Jerarquías de Herencia en el Diseño de Software Orientado al Objeto”. Tesis Doctoral. Facultad de Ciencias, Universidad de Valladolid, 1995 • [Meyer, 1997] “Object-Oriented Software Construction”, Prentice Hall, 1988, 1997, Meyer Bertrand • [OMG], Object Management Group, http://www.omg.org • [OMG, 2003] OMG. “OMG Unified Modeling Language Specification Version 1.5”. Object Management Group Inc. Document formal/03-03-01. March 2003. http://www.omg.org/uml • [OO-226] “Object-Oriented Analysis and Design Using UML” course OO-226, Sun Microsystems • [Rumbaugh et al., 1991] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F.,Lorensen, W. “Object-Oriented Modeling and Design”. Prentice-Hall, 1991

More Related