Grc informatica http www grch com ar isft 189 unlu utn frd
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

Relaciones entre Objetos PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on
  • Presentation posted in: General

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Grc informatica http www grch com ar isft 189 unlu utn frd

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

Relaciones entre Objetos


Composicion i definici n

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


  • Login