difference between association and aggregation

Question

I understand the difference between aggregation and composition but I am struggling a bit with association. My current understanding is that an association exists between classes when ‘they use each other’, for example, one object is passed to the other during a method call. See also:

http://www.codeproject.com/Articles/330447/Understanding-Association-Aggregation-and-Composit

Both objects exist independently and, in contrast to aggregation, no object is a container class of the other. Does this mean that both objects MUST have a copy of the other(s) (e.g. 1:m relationship) or how else is the association ‘stored’. Any feedback would be very much appreciated.

Solution 1

From the UML Superstructure 2.4.1:

An association declares that there can be links between instances of the associated types. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end. (UML Superstructure, Page 37)

Nothing more, nothing less. and very vague. Because of this, it is also very hard to understand. What I defined (In a course I teach) is a hierarchy of links from dependency to composition where:

1. Dependency from A to B means that A uses B but indirectly (say by receiving instances of it and forwarding them to other objects).
2. Association from A to B means that A uses B directly, (for example by calling methods)
3. Aggregation from A to B means that B is part of A (semantically) but B can be shared and if A is deleted, B is not deleted. Note that this says nothing about how the "is part" is implemented.
4. Composition from A to B is like Aggregation, where B cannot be shared and if A is deleted, all of its aggregates (Bs) are deleted also.

Solution 2

Aggregation is an Association relationship where the Association can be considered the containing class 'Owning' the contained class, and the lifetime of that relationship is not defined.

Association is an 'Has-A' relationship.

Example:-

  public class Person  
  {  
   private final Name name;  
   private Address currentAddress;  

   //...  
 } 

In this case, the Person Has-A name and Has-A Address, so there is an Association between Person and Name, and Person and Address.

Solution 3

An association describes a relationship between instances of one or more classes. In the words of the UML Reference Manual, "Associations are the glue that holds together a system."

Aggregation is a form of association in which there is a "whole-part" relationship. You may say that if a class Airplane has a class Engine then this forms a "whole-part" relationship.

Solution 4

Aggregation

Let's set the terms. The Aggregation is a metaterm in the UML standard, and means BOTH composition and shared aggregation, simply named shared. Too often it is named incorrectly "aggregation". It is BAD, for composition is an aggregation, too. As I understand, you meant you understand "shared aggregation and composition".

From UML standard:

Precise semantics of shared aggregation varies by application area and modeler.

I haven't found a word about that aggregation supposed multiplicity, for example.

Association.

A definition from UML 3.4.1 standard:

An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end.

Aggregated relationship is a subclass of Association.

Association is based on relationship. IT is the glue for models.

But your feelings didn't lie - as the shared aggregation is not strictly defined, there is also NO any strictly defined boundary between Association and Aggregated association. Authors of tools and modellers have to set it themselves.

Solution 5

It depends on the context.

Association: A man drives a car, focus on the caller and callee relationship.

Aggregation: A man has a car, focus on the owner and member relationship.

Composition: A man has a mouth, focus on the owner & member but the owner consists of members, it means that they shared the same life cycle.

Feels like I'm speaking Chinglish.

View more solutions

Comments

[Christian]

"has-a" usually refers to an aggregation :)

[Rahul Tripathi]

Thats correct. Usually Association refers to Aggregation as Aggregation is a special case of association. A directional association between objects. When an object ‘has-a’ another object, then you have got an aggregation between them. Direction between them specified which object contains the other object. Aggregation is also called a “Has-a” relationship.

[Carsten]

That would be a usage relationship. An association is more. As others have pointed out, it means 'A refers to B', but - in its plain form - without the whole-part semantics of Aggregation or Composition

[Christian]

actually this answer is wrong, imo: an aggregation can be implemented nearly the same way as a 'normal' association (they both could or could not manifest in an actual reference)

[vainolo]

Actually, I didn't say the you can't implement association the same way as aggregation - just that it is not a must. From the UML Superstructure: "An association describes a set of tuples whose values refer to typed instances". Does this mean that every association should be implemented as a class that stores a link to the two objects? Don't think so. In my interpretation of UML, defining aggregation (or composition) means that one class has an instance of the other. Simple association means usage. But that is only my interpreation (and the problem with UML).

[Ian]

Um, sorry about the late comment, but I thought aggregation was the weaker form of association. IE - shouldn't your definitions for aggregation and composition be swapped? Composition should be the type with the solid diamond (full ownership), and aggregation should be the hollow diamond (ownership of reference); Right?

[vainolo]

The diamonds don't matter. The definition is not exact, and you have to interpret it yourself. I invite you to read the UML documents :-)

[Revolutionair]

I hope you made a mistake here and didn't teach your students this because your descriptions of aggregation and composition should indeed be the other way around, as Ian already pointed out.

[vainolo]

@Revolutionair you are right for the correction. The definition here was incorrect and not what I taught :-). No idea how this slipped two years...

[Revolutionair]

As far as I can tell it is because you missed his point about aggregation being weak but instead dived into diamonds and invited him to read UML documents :-)

[Gerd Wagner]

The UML concept of association is not based on "uses". There is no need for the objects that participate in an association to "use each other". See codeproject.com/Articles/880451/…

[zish]

here is better explanation on SO stackoverflow.com/questions/885937/…