grc informatica http www grch com ar isft 189 unlu utn frd
Download
Skip this Video
Download Presentation
Relaciones entre Objetos

Loading in 2 Seconds...

play fullscreen
1 / 18

Relaciones entre Objetos - PowerPoint PPT Presentation


  • 141 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Relaciones entre Objetos' - karik


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
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
ad