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

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

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.

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

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)

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

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

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

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.

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.

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

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

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

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

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

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

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

Relaciones entre Objetos