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

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