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.
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.
SEAS es el centro de formación online del Grupo San Valero, especializado en el ámbito técnico, industrial y de empresa. Visita www.seas.es para consultar nuestra oferta formativa de cursos y másteres. Formación profesional para el empleo de calidad y accesible para todos.
Fran
10 enero, 2014 at 6:57 pmMuy claro, gracias!!
David
12 marzo, 2014 at 9:32 amMuchas 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.
SEAS
19 marzo, 2014 at 12:18 pm¡Gracias David! Nos alegra de que te sea útil ¡No dejes de visitarnos!
Luis
18 marzo, 2014 at 11:36 pmHola, 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.
Pedro
21 diciembre, 2017 at 10:14 amHola, 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
Alexis González
16 abril, 2014 at 2:42 pmMás claro no podía estar. Muchas Gracias!!
Pedro Arnoldo Machado Duran
14 mayo, 2014 at 8:11 amMuy buen articulo, gracias por el aporte
giuli
31 agosto, 2014 at 10:44 pmLa 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??
Jose Barros
18 octubre, 2014 at 1:03 pmLa 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.
Víctor
11 junio, 2017 at 7:26 amHola 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.
Salvador
12 febrero, 2019 at 7:58 amGracias 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.
Erwin
13 noviembre, 2014 at 9:26 amGracias
Diego
10 febrero, 2015 at 9:46 pmTodo 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.
daniel
1 marzo, 2015 at 9:50 amcuando 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¡¡¡¡¡
jhon castro
21 mayo, 2015 at 6:08 pmcreo 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
Danilo
2 junio, 2015 at 5:06 amExcelente explicación, mas claro imposible
muchas gracias
Nicolas
15 junio, 2015 at 1:19 amExcelente articulo! Muchas gracias por dedicar tanto esfuerzo para la ayuda de los que estamos aprendiendo. Los felicito.
Alberto
2 junio, 2017 at 4:38 pmEstá 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.
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
Jorge
19 octubre, 2017 at 8:03 pmLa 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.
Nelson
28 marzo, 2018 at 10:54 pmMuy buena explicación. Muchas gracias por compartir.
gaston
6 mayo, 2018 at 6:48 pmJose 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.
OLMAN JOSUE SANTAMARIA ACOSTA
1 julio, 2018 at 12:00 amExcelente artículo! Me fue de mucha utilidad
DIEGO
7 junio, 2019 at 1:55 amMuy buena explicación
Segundo Morante
6 mayo, 2021 at 5:50 pmWow… muchas gracias por el artículo, muy simple y fácil de entender, hace mucho que no veía nada de UML y esto me sirvió muchísimo.
Carlos
16 mayo, 2021 at 7:24 pmFácil de entender y muy esquemático, documentación como esta despeja muchas dudas a la hora de modelar esquemas UML.