Solución:
De hecho, la mayoría de los casos de asociaciones en modelos de clases UML no son agregaciones ni composiciones. Por ejemplo, la asociación entre las clases Publisher y Book asignar los libros publicados por un editor a este editor no es una agregación ni una composición porque los libros publicados por un editor no son partes o componentes de este editor.
Una agregación es una forma especial de asociación con el significado pretendido de una relación parte-todo, pero sin una semántica precisa (la especificación UML dice: “La semántica precisa de la agregación compartida varía según el área de aplicación y el modelador”). Por ejemplo, podemos modelar una agregación entre las clases. Car y Engine y entre las clases Course y Lecture ya que un motor es parte de un automóvil y una conferencia es parte de un curso.
Una composición (también denominada “agregación compuesta” en la especificación UML) es una forma especial de agregación, donde una instancia de componente es parte de como máximo una instancia agregada a la vez (es decir, no se puede compartir entre varios agregados). Esto significa que la agregación entre Car y Engine es una composición (porque un motor no se puede compartir entre dos automóviles al mismo tiempo), mientras que una agregación entre Course y Lecture no es necesariamente una composición, ya que una conferencia se puede compartir entre dos cursos (por ejemplo, un curso de administración de bases de datos y un curso de ingeniería de software pueden compartir una conferencia sobre UML). Esto implica que la multiplicidad del extremo de asociación de una composición en el lado agregado es 1 o 0..1, mientras que también puede ser * en el caso de una agregación no compuesta.
Además de estas características principales de una composición (tener partes exclusivas), una composición también puede tener una dependencia del ciclo de vida entre un agregado y sus componentes, lo que implica que cuando se elimina un agregado, todas sus partes se eliminan con él. Sin embargo, esto solo se aplica a algunos casos de composición y no a otros, por lo que no es una característica definitoria. La especificación UML establece: “Una parte se puede eliminar de una instancia compuesta antes de que se elimine la instancia compuesta y, por lo tanto, no se puede eliminar como parte de la instancia compuesta”. En nuestro ejemplo de la composición Car-Engine, es evidente que el motor se puede quitar del automóvil antes de que se destruya, en cuyo caso el motor no se destruye y se puede reutilizar.
Las asociaciones, la agregación y las composiciones de vainilla a veces se explican con la siguiente semántica:
- Asociación de vainilla: un objeto ‘conoce’ uno o más otros objetos
- agregación: un objeto ‘tiene’ uno o más otros objetos
- composición: un objeto ‘consiste en’ uno o más objetos – el subobjeto no puede estar sin el contenedor de composición
en su mayoría, la diferenciación de agregación y composición gira en torno a la pregunta “si el objeto maestro se ha ido, ¿qué sucede con los objetos parciales?”.
Entonces, la idea es tener alguna restricción de integridad como “en cascada de eliminación” que se describa usando una diferenciación al usar una de las tres opciones. UML tiene tres símbolos diferentes para esto
- sin símbolo – asociación vainilla
- diamante – agregación
- diamante relleno – composición
El problema con estas tres opciones es que la semántica no es lo suficientemente precisa para situaciones de la vida real, especialmente si observa situaciones que cambian con el tiempo.
Por ejemplo, tratando de responder una pregunta simple. “¿Cuántas ruedas tiene mi coche?”
Conducirá a diferentes respuestas:
- 4 ruedas que están fijadas de forma permanente a mi coche
- 1 rueda de repuesto que podría usar en caso de emergencia
- 4 ruedas que son mis ruedas de verano o de invierno y no están unidas al automóvil en las otras estaciones
ver
- Diagrama UML en diagrams.bitplan.com
- Marcado PlanUml para diagrama
¿Cuántas de estas ruedas desaparecerán cuando el automóvil se haya ido? Si intenta modelar esta situación con los tres símbolos que ofrece UML, terminará con mucha discusión y negociación sobre lo que realmente significa su modelo. Creo que es mucho mejor no utilizar nunca símbolos de agregación y composición, sino describir siempre la semántica de asociación con la mayor precisión posible con unas pocas líneas de texto. De esta manera, puede dejar en claro a las personas que leen su modelo lo que realmente desea. Creo que incluso está bien escribir “Un automóvil es una composición de partes que incluye las ruedas …”
Pero ahora no está utilizando un símbolo de composición, sino que realmente hace referencia al acto de componer algo.
ver también http://de.wikipedia.org/wiki/Assoziation_%28UML%29#Aggregation_und_Komposition (alemán)