UML aggregation vs association

Question

Here I am, with another question about aggregation and association. I wanted to learn some basics of UML, so I started reading \"UML distilled\" by Martin Fowler. I read bot

Answer 1

Implementation wise there is not much of a difference but conceptually there is big difference: aggregations are used to express a hierarchy. When you work with a hierarchy of components there are certain type of operations you need to have in the root interface:

• find subcomponents in the hierarchy
• add/remove subcomponents to/from the hierarchy
• change common attributes of all components
• traverse the hierarchy recursively (Visitor pattern)
• reconfigure the hierarchy and the links (associations) between the components

Most of these operations are not needed when dealing with associations.

Answer 2

Rumbaugh's statement is the most telling and Uncle Bob's good advice. As I've said elsewhere, Aggregation is semantically so weak as to offer nothing practically beneficial. It only has one valid corner case (acyclicity of recursive relationships) however few people know and understand that. So you end up having to point out in comments anyway.

I just don't use it. And have never felt any loss. Stick with simple binary associations and focus on what really matters - getting the cardinality and naming right. You'll get far more from that than trying to decide the undecidable association vs. aggregation.

hth.

Answer 3

I tend to use Aggregation to show a relation that is the same as a Composition with one big distinction: the containing class is NOT responsible for the life-cycle of the contained object. Typically, a (non-null) pointer or reference to the object-to-be-contained is passed to the containing class's constructor. The containing object, for the duration of its life-cycle, depends upon the contained object existing. The containing object cannot do its job (fully) without the contained object. This is my interpretation of the "Part/Whole" relationship implied by Aggregation.

Answer 4

They do not mean the same! I can put it in this way:

Association relationship: A class references another class. Actually it shows that a class is related to another class but they don't necessarily have attributes to show this relationship... e.g 'Teacher' and 'Student' classes, although 'Teacher' class has no attribute that refer to students, but we do know that in reality a teacher do have students... And also 'School' class has 'teachers' and 'students' properties that now make those two classes related to each other.

Aggregation relationship: A class contains another class. But if the container(ClassRoom) is destroyed, the contained(Chair) is not. Actually the ClassRoom owns the Chair. Aggregation is a more stronger relationship than the Association relationship.

Here is also a tutorial about it and the whole UML2.0 which explains everything easy and simple, you may find it useful: https://github.com/imalitavakoli/learn-uml2

TIP: Also let me mention that because the Association relationship exists between classes most of the times, we sometimes don't draw it to prevent unnecessary complexity.

Answer 5

In UML aggregation is under-defined and since they haven't got any clearly defined semantic. A valid use-case of an aggregation is the encapsulation of a several classes, as stated in "Domain Driven Design" by Eric Evans.

E.g. a car has four wheels. You might want to calculate the total amount of meters each wheel has driven, for each car. This calculation is done by the car-entity, since it knows which wheels it has and you don't care which wheels belong to which car.

The car is the aggregation-root for all it's parts, like wheels, and you can't access the parts of a car from outside the aggregation, just the root.

So basically an aggregation encapsulates a set of classes which belong to each other.

Answer 6

This term often gets confused.

Aggregation and composition are some of the types of association. There is hardly a difference between aggregations and associations during implementation, and many will skip aggregation relations altogether in their diagrams with association relation.

You can get the idea from this analogy.

Class:A(person) and Class:B(car) has association relation, if Class:A has a Class:B declaration, and also Class:B(car) object is not essential to create a Class:A(person) object.

Class:A(car) and Class:B(tyre) has aggregation relation, if Class:A has a Class:B declaration, and also Class:B(tyre) object is essential to create a Class:A(car) object.

Cheers!