Informática

Agregación Vs Composición en diagramas de clases. UML.

25 enero, 2013

Una duda que frecuentemente me plantean los alumnos a la hora de modelar diagramas de clases con UML (Unified Modeling Language), es el uso de las relaciones estructurales de agregación y composición. Se trata de dos tipos de especialización de la relación de asociación entre clases.
Vamos a intentar mediante algunos ejemplos muy simples y esclarecedores, ver las diferencias que existen entre la composición fuerte y la composición débil, conocida habitualmente como agregación.

 

Agregación

La agregación es un tipo de asociación que indica que una clase es parte de otra clase (composición débil). Los componentes pueden ser compartidos por varios compuestos (de la misma asociación de agregación o de varias asociaciones de agregación distintas). La destrucción del compuesto no conlleva la destrucción de los componentes. Habitualmente se da con mayor frecuencia que la composición.
La agregación se representa en UML mediante un diamante de color blanco colocado en el extremo en el que está la clase que representa el “todo”.

Veamos un ejemplo de agregación:

• Tenemos una clase Empresa.
• Tenemos una clase Cliente.
• Una empresa agrupa a varios clientes.

Composición

Composición es una forma fuerte de composición donde la vida de la clase contenida debe coincidir con la vida de la clase contenedor. Los componentes constituyen una parte del objeto compuesto. De esta forma, los componentes no pueden ser compartidos por varios objetos compuestos. La supresión del objeto compuesto conlleva la supresión de los componentes.
El símbolo de composición es un diamante de color negro colocado en el extremo en el que está la clase que representa el “todo” (Compuesto).

Veamos un ejemplo de composición:

 

• Tenemos una clase Empresa.
• Un objeto Empresa está a su vez compuesto por uno o varios objetos del tipo empleado.
• El tiempo de vida de los objetos Empleado depende del tiempo de vida de Empresa, ya que si no existe una Empresa no pueden existir sus empleados.

Diferencias entre Composición y Agregación

La siguiente tabla intenta resumir algunas diferencias entre agregación y composición.

Y en código…

Para traducir ambas relaciones a código, podemos utilizar un atributo en la clase contenedora o compuesta donde almacenaremos una colección de los objetos que la componen, y por otro lado declararemos un método para agregar elementos a la colección. Dependiendo del lenguaje de programación empleado, podemos utilizar diferentes estructuras de datos que nos permitan almacenar esa colección de objetos, aunque generalmente se utilizan arrays (arreglos) para este fin.

Veamos un ejemplo:

Como podemos apreciar, es tan simple como crear en la clase Empresa un atributo clientes (colección de clientes) que sea un array, luego creamos un método addCliente donde recibiremos objetos de tipo Cliente y los agregaremos dentro del array.

Concluyendo…

En líneas generales, como hemos visto, se podría decir que la diferencia entre agregación y composición es conceptual, no se diferencia por código, o al menos, en el mayor de los casos y en la mayoría de los lenguajes de programación (como Java o PHP). De todas maneras, en el caso de la composición, si quisiéramos ser más estrictos con los diagramas de clases modelados con UML, deberíamos destruir de alguna manera el objeto componente (empleado) una vez que se desasociaran del objeto compuesto (empresa).

En definitiva, UML nos permite la posibilidad de diferenciar este tipo de asociaciones con el fin de que, aquella persona que le interese, pueda estipular de una u otra manera que se trata de una composición o una agregación, aunque en términos de implementación no se diferencie tan apenas su uso ni tenga tanta relevancia. Pero una vez más, y como vimos en un post anterior de este blog: “UML en su justa medida…” , UML propone muchas posibilidades y debe ser el analista y/o desarrollador quien decida y haga un uso correcto del mismo, con el fin de visualizar, especificar, construir y documentar adecuadamente los artefactos (modelos) de un sistema software.

Todo esto y mucho más, se estudia en el curso de Experto en gestión y desarrollo de aplicaciones informáticas orientadas a objetos.


SEAS Estudios Superiores Abiertos. Solicita información.Si te ha gustado este artículo de nuestro profesor Jose María Megino, te animamos a que amplíes tus conocimientos sobre UML con nuestro Curso online de UML, con el que aprenderás a usar este lenguaje en cualquier sistema.

Puedes compartir este artículo en:
  • Reply
    Fran
    10 enero, 2014 at 6:57 pm

    Muy claro, gracias!!

  • Reply
    David
    12 marzo, 2014 at 9:32 am

    Muchas gracias por el artículo. Hacía tiempo que no utilizaba UML y, ahora que estoy realizando un diagrama UML, me han surgido dudas con este tema que ya están zanjadas. Me encanta leer artículos como este, del cual sales con las ideas claras.

    • Reply
      SEAS
      19 marzo, 2014 at 12:18 pm

      ¡Gracias David! Nos alegra de que te sea útil ¡No dejes de visitarnos!

  • Reply
    Luis
    18 marzo, 2014 at 11:36 pm

    Hola, comentas que la cardinalidad en el extremo compuesto en una composición puede ser 0..1 o 1.

    Si es una parte de un todo, ¿cómo va a existir una parte sin un todo?

    Gracias.

    • Reply
      Pedro
      21 diciembre, 2017 at 10:14 am

      Hola, tengo una duda la misma duda existencial ya diría.
      En el caso de composición si la clase compuesta no tiene sentido sin la clase principal entiendo que al modelar la clase compuesta SIEMPRE debería tener como cardinalidad 1..* (en alguna referencia he visto escrito 0..* lo que me despisa mucho).
      Gracias y un saludo

  • Reply
    Alexis González
    16 abril, 2014 at 2:42 pm

    Más claro no podía estar. Muchas Gracias!!

  • Reply
    Pedro Arnoldo Machado Duran
    14 mayo, 2014 at 8:11 am

    Muy buen articulo, gracias por el aporte

  • Reply
    giuli
    31 agosto, 2014 at 10:44 pm

    La cardinalidad de la composicion: una silla 4 patas, un auto se compone de 4 ruedas osea mas de 1… a que te referirs con cardinalidad a nivel de compuesto??

  • Reply
    Jose Barros
    18 octubre, 2014 at 1:03 pm

    La explicación parece buena, pero es incompleta e informal. Queda claro lo que el autor «opina» pero no está ni mucho menos demostrado. El autor dice que: «• El tiempo de vida de los objetos Empleado depende del tiempo de vida de Empresa, ya que si no existe una Empresa no pueden existir sus empleados.», y así justifica que se trata de una composición, pero yo me pregunto: ¿los clientes de una empresa pueden seguir existiendo cuando la empresa desaparece?; ¿A quién le compran?, esta claro que una «persona» no se muere cuando cierra la empresa de la cual es cliente o empleado, pero estaríamos hablando de la clase persona y no de las clases «cliente» o «empleado». Cualquiera de los dos ejemplos propuestos podría interpretarse como agregación (y dejar vivir a los clientes y a los empleados) o como composición (y matarlos a todos). La cuestión sigue abierta, sería bueno seguir indagando, y tratar de conseguir ejemplos que no presenten estas ambigüedades de interpretación.

    • Reply
      Víctor
      11 junio, 2017 at 7:26 am

      Hola José, a pesar que mi comentario va con mucho tiempo de retraso, no me gusta dejar dudas sin responder, ya que a otras personas que lean esto posteriormente les puede servir.
      Obviamente cuando modelamos un sistema debemos enmarcarlo en un determinado contexto. Para ello una de las herramientas con las que contamos es la abstracción. Podríamos modelar un sistema basandonos en diferentes puntos de vista y así obtener diferentes soluciones a un mismo ejemplo, pero debemos elegir la más apropiada para el negocio que intentamos modelar Ej:
      Podríamos estar realizando un software para un taller mecánico, para lo cual vamos a crear una clase llamada auto, a su vez esta clase va a estar formada por objetos de la clase rueda. En este caso podríamos decir que se trata de una composición, ya que sin el auto no tiene sentido que las ruedas existan, esto estaría bien para algunos casos, pero no para todos. Por otro lado si nos llevamos nuestro programa a otro taller, nos podríamos encontrar con un escenario totalmente distinto, en el cual el taller a parte de arreglar autos, vende ruedas. En este caso la vida de los objetos rueda es independiente del objeto auto, ya que en este caso sí tiene sentido que una rueda exista sin un auto, es decir, aquí habria que aplicar agregación. En tu ejemplo, no se trata de ambiguedades, sino más bien de definir cual es el contexto del negocio, si estás modelando un sistema para el control de clientes de una empresa, obviamente no tiene sentido mantenerlos vivos una vez destruida tu empresa 🙂
      Espero que se haya entendido la idea.

      • Reply
        Salvador
        12 febrero, 2019 at 7:58 am

        Gracias por aclarar la duda, en un principio al leer el comentario de José empece a dudar y dar crédito que lo que decía era muy cierto, sin embargo ahora con tu comentario me doy cuenta de lo que bien comentas, que todo depende del contexto, en pocas palabras de la lógica de negocio que se este desarrollando.

  • Reply
    Erwin
    13 noviembre, 2014 at 9:26 am

    Gracias

  • Reply
    Diego
    10 febrero, 2015 at 9:46 pm

    Todo está muy claro, pero en realidad, cuando tratas de ilustrarlo en el código, creo que se está confundiendo con la «DEPENDENCIA». Según éste libro http://bit.ly/1vCMwxh, argumento lo que les digo.
    Si estoy equivocado, por favor ílustrame el camino correcto. Gracias.

  • Reply
    daniel
    1 marzo, 2015 at 9:50 am

    cuando creas un metodo y le pasas parametros que son por Valor o por Referencia.
    ¿por Valor es agregacion o composicion? y ¿por referencia es agregacion o composicion?
    ejemplo:
    funcion integer sumar(ByVal num1 integer, ByVal mun2 integer){

    }
    este codigo es irreal pero en visual es maso menos asi¡¡¡¡¡

  • Reply
    jhon castro
    21 mayo, 2015 at 6:08 pm

    creo que le falta explicar que es eso de relación fuerte y débil… por ejemplo en composición la relación entre las clases es fuerte porque a falta de un compuesto la clase principal de esa asociación no podría existir, lo que no pasa en la agregación

  • Reply
    Danilo
    2 junio, 2015 at 5:06 am

    Excelente explicación, mas claro imposible
    muchas gracias

  • Reply
    Nicolas
    15 junio, 2015 at 1:19 am

    Excelente articulo! Muchas gracias por dedicar tanto esfuerzo para la ayuda de los que estamos aprendiendo. Los felicito.

  • Reply
    Alberto
    2 junio, 2017 at 4:38 pm

    Está claro que los clientes no «mueren» cuando la empresa desaparece, pero los clientes ya no tienen categoría de clientes para dicha empresa cuando ésta desaparece. La entidad «cliente» de la empresa desaparece con la empresa. No puede existir clientes si no hay empresa. Es algo conceptual, no literal.

  • Reply
    Víctor
    11 junio, 2017 at 7:04 am

    «En líneas generales, como hemos visto, se podría decir que la diferencia entre agregación y composición es conceptual, no se diferencia por código»

    Completamente en desacuerdo con el autor. Tal como lo mencionó Daniel, Existe una gran diferencia a la hora de codificar la agregación y la Composición. El hecho de que en la agregación la vida del objeto incluido sea independiente del objeto contenedor, se manifiesta en el código creando el objeto contenido fuera de la clase contenedora y pasándoselo a ésta por «referencia», de este modo también se permite que otros objetos contengan al objeto contenido. A diferencia de lo anterior en la composición, el objeto incluido se crea dentro de la clase contenedora con la instrucción new (en el caso de Java) y se le pasan los valores del objeto original por «valor». De esta manera al destruir la clase contenedora, se destruye también el objeto que fue creado dentro de ella. Y aclarando de paso lo que dice Diego, en el caso de la dependencia, el objeto externo sólo se utiliza dentro de un método de la clase contenedora para aprovechar su funcionalidad, a diferencia de la asociación, agregación y composición, en donde el objeto forma parte de los atributos del contenedor o es agregado a una colección que representa un atributo (en el caso de la agregación y composición). Espero que mi comentario sirva para aclarar las dudas o para establecer un debate que de igual modo nos enriquece

  • Reply
    Jorge
    19 octubre, 2017 at 8:03 pm

    La composición y la agregación se diferencian claramente en el código. Lo que ocurre es que la mayoría sólo codifican agregaciones.
    Yo en general resuelvo la composición con una clase interna y la agregación con una clase externa. El ciclo de vida de la clase interna está definido por la clase contenedora y no permito que se instancie por fuera de esta clase.
    Hay que tener en cuenta que los objetos del modelo suelen tener sus cuestiones con el uso de los ORMs, con lo cual la composición en la capa de persistencia no es muy aplicable. Sin embargo en otros casos la composición funciona muy bien, por ejemplo las clases Map y Map.Entry.
    Si quieren buscar casos correctos de composición, busquen casos correctos de usos de clases internas.

  • Reply
    Nelson
    28 marzo, 2018 at 10:54 pm

    Muy buena explicación. Muchas gracias por compartir.

  • Reply
    gaston
    6 mayo, 2018 at 6:48 pm

    Jose Barros, estuve leyendo tus cometarios al igual que otros. La verdad que tus comentarios dejan mucho que decir. Me parece que no entendiste nada. Te recomiendo que leas el libro de «UML Y PATRONES DE CRAIG LARMAN». El autor de esta página web explica con claridad la Agregación Vs Composición en diagramas de clases. UML. Tenes varios ejemplos del libro, además VOS PODES PENSAR Y ANALIZAR EJEMPLOS DE LA VIDAL REAL. !!!!! El autor de esta página, te dá ejemplos concretos que estan sacados de libros, no es ningún invento.

  • Reply
    OLMAN JOSUE SANTAMARIA ACOSTA
    1 julio, 2018 at 12:00 am

    Excelente artículo! Me fue de mucha utilidad

  • Reply
    DIEGO
    7 junio, 2019 at 1:55 am

    Muy buena explicación

Deja un comentario

Información básica acerca de cómo protegemos tus datos conforme al Reglamento General de Protección de Datos (Reglamento UE 2016/679) y en la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales

De conformidad con lo establecido en el Reglamento General de Protección de Datos, te informamos de:

- Quien es el responsable del tratamiento: SEAS, Estudios Superiores Abiertos S.A.U con NIF A-50973098, dirección en C/ Violeta Parra nº 9 – 50015 Zaragoza y teléfono 976.700.660.

- Cuál es el fin del tratamiento: Gestión y control de los comentarios del blog de SEAS. 

- En que basamos la legitimación: En tu consentimiento.

- La comunicación de los datos: No se comunicarán tus datos a terceros.

- Los criterios de conservación de los datos: Se conservarán mientras exista interés mutuo para mantener el fin del tratamiento o por obligación legal. Cuando dejen de ser necesarios, procederemos a su destrucción.

- Los derechos que te asisten: (i) Derecho de acceso, rectificación, portabilidad y supresión de sus datos y a la limitación u oposición al tratamiento, (ii) derecho a retirar el consentimiento en cualquier momento y (iii) derecho a presentar una reclamación ante la autoridad de control (AEPD).

- Los datos de contacto para ejercer tus derechos: SEAS, Estudios Superiores Abiertos S.A.U. C/ Violeta Parra nº 9 –
50015 Zaragoza (España) o través de correo electrónico a lopd@estudiosabiertos.com

- También puedes ponerte en contacto con nuestro Delegado de Protección de Datos en dpd@estudiosabiertos.com

Información adicional: Puedes consultar la información adicional y detallada sobre nuestra política de privacidad