herencia - Agregación UML vs asociación
diagramas uml (8)
¡No significan lo mismo! Puedo ponerlo de esta manera:
Relación de asociación : Una clase hace referencia a otra clase. En realidad, muestra que una clase está relacionada con otra, pero no necesariamente tienen atributos para mostrar esta relación ... por ejemplo, las clases de "Profesor" y "Estudiante", aunque la clase de "Profesor" no tiene ningún atributo que se refiera a los estudiantes, pero sí sabemos que, en realidad, un profesor tiene estudiantes ... Y también la clase ''Escuela'' tiene propiedades de ''profesores'' y ''estudiantes'' que ahora hacen que esas dos clases estén relacionadas entre sí.
Relación de agregación : Una clase contiene otra clase. Pero si el contenedor (ClassRoom) se destruye, el contenido (Chair) no se destruye. En realidad, el ClassRoom es el propietario de la silla. La agregación es una relación más fuerte que la relación de asociación.
Aquí también hay un tutorial sobre esto y sobre todo UML2.0 que explica todo de manera fácil y simple, puede resultarle útil: https://github.com/imalitavakoli/learn-uml2
CONSEJO : Permítame mencionar que debido a que la relación de asociación existe entre las clases la mayoría de las veces, a veces no lo hacemos para evitar una complejidad innecesaria.
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í los dos capítulos sobre las clases, y creo que hay una cosa que no puedo comprender por completo: la agregación frente a la asociación. En el libro hay esta cita:
En los días anteriores a UML, las personas solían ser bastante vagas sobre qué era la agregación y qué era la asociación. Vagos o no, siempre fueron inconsistentes con todos los demás. Como resultado, muchos modeladores piensan que la agregación es importante, aunque por diferentes razones. Por lo tanto, el UML incluía la agregación (Figura 5.3) pero casi sin semántica. Como dice Jim Rumbaugh, "Piense en ello como un modelo de placebo" [Rumbaugh, referencia de UML].
Como entiendo de esta cita y los temas que leí en Stack Overflow, no importa cuál de las dos relaciones que uso, significan básicamente lo mismo, o hay alguna situación en la que se justifique el uso de la agregación en lugar de la asociación. y / o ¿no podría cambiar una de otra sin cambiar el "significado" de un diagrama de clase?
Estoy preguntando esto, porque este libro es de 2003, y algunas cosas podrían cambiar durante esos pocos años.
En UML, la agregación está poco definida y, como no tienen ninguna semántica claramente definida. Un caso de uso válido de una agregación es la encapsulación de varias clases, como se indica en "Domain Driven Design" por Eric Evans.
Por ejemplo, un coche tiene cuatro ruedas. Es posible que desee calcular la cantidad total de metros que ha impulsado cada rueda 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 qué automóvil.
El automóvil es la raíz de agregación para todas sus partes, como las ruedas, y no puede acceder a las partes de un automóvil desde fuera de la agregación, solo la raíz.
Entonces, básicamente, una agregación encapsula un conjunto de clases que se pertenecen entre sí.
En cuanto a la implementación, no hay mucha diferencia, pero conceptualmente hay una gran diferencia: las agregaciones se utilizan para expresar una jerarquía . Cuando trabaja con una jerarquía de componentes, hay ciertos tipos de operaciones que debe tener en la interfaz raíz:
- encontrar subcomponentes en la jerarquía
- agregar / eliminar subcomponentes a / desde la jerarquía
- Cambiar atributos comunes de todos los componentes.
- Recorrer la jerarquía recursivamente (patrón de 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.
Este término a menudo se confunde.
La agregación y la composición son algunos de los tipos de asociación. Difícilmente existe una diferencia entre las agregaciones y las asociaciones durante la implementación, y muchos omitirán las relaciones de agregación por completo en sus diagramas con relación de asociación.
Puedes obtener la idea de esta analogía.
Clase: A (persona) y Clase: B (automóvil) tiene relación de asociación , si Clase: A tiene una declaración Clase: B , y también el objeto Clase: B (automóvil) no es esencial para crear un objeto Clase: A (persona) .
Clase: A (automóvil) y Clase: B (neumático) tiene relación de agregación , si Clase: A tiene una declaración Clase: B , y también el objeto Clase: B (neumático) es esencial para crear un objeto Clase: A (automóvil) .
¡Aclamaciones!
La declaración de Rumbaugh es la más reveladora y el buen consejo del tío Bob. Como he dicho en 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), sin embargo pocas personas lo saben y lo comprenden. Así que terminas teniendo que señalar en los comentarios de todos modos.
Simplemente no lo uso. Y nunca he sentido ninguna pérdida. Manténgase en las asociaciones binarias simples y concéntrese en lo que realmente importa: obtener la cardinalidad y nombrar correctamente. Obtendrá mucho más de eso que tratar de decidir la asociación indecidible frente a la agregación.
hth
Para agregar, solo sugeriría descargar la especificación UML desde el sitio de OMG: mejor referencia y vea la p 110.
ninguno Indica que la Propiedad no tiene semántica de agregación.
compartida Indica que la Propiedad tiene 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 está agregada de manera 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).
Quizás esto pueda ayudarte, pero no creo que encuentres la explicación perfecta:
La diferencia es una de las implicaciones. La agregación denota relaciones totales / parciales, mientras que las asociaciones no lo hacen. Sin embargo, no es probable que haya mucha diferencia en la forma en que se implementan las dos relaciones. Es decir, sería muy difícil mirar el código y determinar si una relación particular debería ser agregación o asociación. Por esta razón, es bastante seguro ignorar por completo la relación de agregación.
[Robert C. Martin | UML]
Y un ejemplo para cada situación:
a) La asociación es una relación en la que todos los objetos tienen su propio ciclo de vida y no hay propietario. Tomemos un ejemplo de profesor y alumno. Varios estudiantes pueden asociarse con un solo maestro y un solo estudiante puede asociarse con varios maestros, pero no hay 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 en la que todos los objetos tienen su propio ciclo de vida, pero existe la propiedad y el objeto secundario no puede pertenecer a otro objeto principal. Tomemos un ejemplo de departamento y maestro. Un solo profesor no puede pertenecer a varios departamentos, pero si eliminamos el departamento, el objeto del profesor no se destruirá. Podemos pensar en la relación "has-a".
[Maesh | GeeksWithBlogs]
Tiendo a usar la Agregación para mostrar una relación que es igual a 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 una referencia al objeto a ser contenido se pasa al constructor de la clase contenedora. El objeto que contiene, durante la duración de su ciclo de vida, depende del objeto contenido existente. El objeto que contiene no puede hacer su trabajo (completamente) sin el objeto contenido. Esta es mi interpretación de la relación "Parte / Todo" implícita en la Agregación.