Agregación UML vs asociación

Question

Aquí estoy, con otra pregunta sobre agregación y asociación. Quería aprender algunos conceptos básicos de UML, así que comencé a leer "UML destilado" por Martin Fowler. Leí ambos capítulos sobre clases, y creo que hay una cosa que no puedo entender completamente, y es la agregación frente a la asociación. En el libro hay esta cita:

en los días pre-UML, las personas eran por lo general bastante vaga en lo que era la agregación y lo que era asociación. Ya sea vago o no, siempre fueron inconsistentes con los demás. Como resultado, muchos modeladores piensan que la agregación es importante, aunque por diferentes motivos. Por lo tanto, UML incluía la agregación (Figura 5.3) pero con casi ninguna semántica. Como dice Jim Rumbaugh, "Piénselo como un placebo modelo" [Rumbaugh, UML Reference].

Según entiendo de esta cita y los temas que he leído sobre el desbordamiento de pila que no importa cuál de esas dos relaciones que uso, que significa bassicly el mismo, o hay alguna situación en la que el uso de la agregación en lugar de la asociación estaría justificada y/o no podría cambiar una a la otra sin cambiar el "significado" de un diagrama de clases?

Estoy preguntando esto, porque este libro es de 2003, y algunas cosas podrían cambiar durante esos pocos años.

Answer 1

La declaración de Rumbaugh es la más reveladora y el mejor consejo del tío Bob.Como he dicho elsewhere, la agregación es semánticamente tan débil que no ofrece nada prácticamente beneficioso. Solo tiene un caso de esquina válido (aciclicidad de relaciones recursivas), pero pocas personas saben y entienden eso. Así que terminas teniendo que señalar en los comentarios de todos modos.

Simplemente no lo uso. Y nunca he sentido ninguna pérdida. Quédese con asociaciones binarias simples y concéntrese en lo que realmente importa: conseguir la cardinalidad y nombrar correctamente. Obtendrá mucho más de eso que tratando de decidir la asociación indecidible contra la agregación.

hth.

Answer 2

Tal vez esto le puede ayudar, pero no creo que se encuentra la explicación perfecta:

La diferencia es uno de implicación. La agregación denota relaciones totales/parte mientras que las asociaciones no. Sin embargo, no es probable que sea una gran diferencia en la forma en que se implementan las dos relaciones . Es decir, sería muy difícil ver el código y determinar si una relación en particular debería ser agregación o asociación. Por esta razón, es bastante seguro ignorar la relación de agregación por completo.
[Robert C. Martin | UML]

y un ejemplo para cada situación:

a) asociación es una relación en la que todos los objetos tienen su propio ciclo de vida y no hay ningún propietario. Tomemos un ejemplo de Teacher y Student. Varios estudiantes pueden asociarse con un solo maestro y un solo alumno puede asociarse con varios profesores, pero no existe la propiedad entre los objetos y ambos tienen su propio ciclo de vida. Ambos pueden crear y eliminar de forma independiente.

b) La agregación es una forma especializada de asociación donde todos los objetos tienen su propio ciclo de vida pero hay propiedad y el objeto secundario no puede pertenecer a otro objeto primario. Tomemos un ejemplo de Departamento y profesor. Un solo profesor no puede pertenecer a los departamentos múltiples , pero si eliminamos el departamento, no se destruirá el objeto maestro . Podemos pensar en la relación "tiene una".
[Maesh | GeeksWithBlogs]

Answer 3

En la agregación de UML no está bien definido y no tiene una semántica definida. Un caso de uso válido de una agregación es la encapsulación de varias clases, como se indica en "Diseño controlado por el dominio" por Eric Evans.

E.g. un auto tiene cuatro ruedas Es posible que desee calcular la cantidad total de metros que cada rueda ha conducido, para cada automóvil. Este cálculo lo realiza la entidad del automóvil, ya que sabe qué ruedas tiene y no le importa qué ruedas pertenecen a cada automóvil.

El automóvil es la raíz de agregación para todas sus partes, como las ruedas, y no se puede acceder a las partes de un automóvil desde fuera de la agregación, solo la raíz.

Así que, básicamente, una agregación encapsula un conjunto de clases que pertenecen entre sí.

Answer 4

Tiendo a usar Agregación para mostrar una relación que es lo mismo que una Composición con una gran distinción: la clase contenedora NO es responsable del ciclo de vida del objeto contenido. Normalmente, un puntero (no nulo) o referencia al objeto que se va a contener se pasa al constructor de la clase contenedora. El objeto que lo contiene, mientras dure su ciclo de vida, depende del objeto contenido que exista. El objeto contenedor no puede hacer su trabajo (completamente) sin el objeto contenido. Esta es mi interpretación de la relación "Parte/Total" implicada por Agregación.

Answer 5

¡No significan lo mismo! Puedo ponerlo de esta manera:

relación Asociación: Una clase hace referencia a otra clase. En realidad, muestra que una clase está relacionada con otra clase pero no necesariamente tienen atributos para mostrar esta relación ... por ejemplo, clases 'Profesor' y 'Estudiante', aunque la clase 'Profesor' no tiene ningún atributo que haga referencia estudiantes, pero sí sabemos que en realidad un maestro tiene estudiantes ... Y también la clase 'Escuela' tiene 'maestros' y 'propiedades de estudiantes' que ahora hacen esas dos clases relacionadas con cada otra.

Relación de agregación: Una clase contiene otra clase. Pero si el contenedor (ClassRoom) se destruye, el contenido (Chair) no lo es. En realidad, el ClassRoom es dueño de la silla. La agregación es una relación más fuerte que la relación de asociación.

Aquí hay también un tutorial sobre él y todo el UML2.0, lo que explica que todo sea fácil y simple, puede que le resulte útil: https://github.com/imalitavakoli/learn-uml2

TIP: También quisiera mencionar que debido a que existe la relación Asociación entre las clases mayoría de las veces, a veces no nos acercamos a evitar la complejidad innecesaria.

Answer 6

Implementación sabia no hay mucha diferencia, pero conceptualmente hay una gran diferencia: las agregaciones se utilizan para expresar una jerarquía. Cuando se trabaja con una jerarquía de componentes que hay cierto tipo de operaciones es necesario tener en la interfaz raíz:

• subcomponentes descubrimiento en la jerarquía
• añadir/eliminar los subcomponentes a/de la jerarquía
• cambio atributos comunes de todos los componentes
• atravesar la jerarquía de forma recursiva (patrón Visitante)
• reconfigure la jerarquía y los enlaces (asociaciones) entre los componentes

La mayoría de estas operaciones no son necesarias cuando se trata de asociaciones.

Answer 7

Este término a menudo se confunde.

Agregación y composición son algunos de los tipos de asociación. Hay apenas una diferencia entre agregaciones y asociaciones durante la implementación , y muchas omitirán las relaciones de agregación por completo en sus diagramas con relación de asociación.

Puede obtener la idea de esta analogía.

Clase: A (persona) y Clase: B (auto) tiene asociación relación, si Clase: A tiene una Clase: declaración B, y también Clase: B (automóvil) objeto es no esencial para crear un Clase: A (persona) objeto.

Clase: A (auto) y Clase: B (neumático) tiene agregación relación, si Clase: A tiene una Clase: B declaración, y también Clase: B (neumático) objeto es esencial para crear un objeto Clase: A (coche).

¡Salud!

Answer 8

Para añadir, sólo quiero sugerir a descargar desde el sitio especificación UML OMG: la mejor referencia y ver pág 110.

ninguno indica que la propiedad no tiene la semántica de agregación.

compartido Indica que la propiedad tiene una semántica de agregación compartida. La semántica precisa de la agregación compartida varía según el área de aplicación y el modelador.

compuesto Indica que la propiedad se agrega de forma compuesta, es decir, el objeto compuesto tiene la responsabilidad de la existencia y el almacenamiento de los objetos compuestos (consulte la definición de partes en 11.2.3).