Association, Aggregation and Composition in OOAD

In object-oriented analysis and design,  an association represents a certain relationship between objects, but all objects have their own lifecycle and there is no ownership among the objects. For example, multiple students can associate with a single teacher and a single student can associate with multiple teachers but there is no ownership among the objects and all have their own lifecycle.

Aggregation and composition both are specialized forms of association. Composition is again a special form of aggregation.

An aggregation represents a whole that comprises various parts; so, a Committee is an aggregate of its Members. A Meeting is an aggregate of an Agenda, a Room, and the Attendees. At implementation time, this relationship is not containment. (A meeting does not contain a room.) Similarly, the parts of the aggregate might be doing other things elsewhere in the program, so they might be referenced by several objects. In other words, There's no implementation-level difference between aggregation and assoication which represents a simple "uses" relationship (an "association" line with no diamonds on it at all). In both cases, an object has references to other objects. Though there's no implementation difference, it's definitely worth capturing the relationship in the UML, both because it helps you understand the domain model better and because there are subtle implementation issues.

Composition involves even tighter coupling than aggregation and definitely involves containment. The basic requirement is that, if a class of objects (call it a "container") is composed of other objects (call them the "elements"), then the elements will come into existence and also be destroyed as a side effect of creating or destroying the container. It would be rare for an element not to be declared as private. An example might be a Customer's name and address. A Customer without a name or address is a worthless thing. By the same token, when the Customer is destroyed, there's no point in keeping the name and address around. (Compare this situation with aggregation, where destroying the Committee should not cause the members to be destroyed---they may be members of other Committees).

Aggregation - "has-a" relationship

In UML, aggregation is defined as a special form of association (an association is a structural relationship that specifies that objects are connected to other objects) that specifies a whole-part relationship between the aggregate (whole) and a component part.

In an aggregation relationship, the part may be independent of the whole but the whole requires the part.

An aggregation relationship is indicated in the UML with an unfilled diamond and a line as follows:

There are many examples of aggregation relationship:

• A Library contains books
• Departments are made up of employees
• A computer is composed of a number of devices.

In terms of implementation, the elements in a composition relationship are typically created by the constructor or an initializer in a field declaration, but Java doesn't have a destructor, so there's no way to guarantee that the elements are destroyed along with the container. In C++, the element would be an object (not a reference or pointer) that's declared as a field in another object, so the creation and destruction of the element would be automatic. Java has no such mechanism. It's nonetheless important to specify a containment relationship in the UML, because this relationship tells the implementation/testing folks that your intent is for the element to become garbage collectible (i.e. there should be no references to it) when the container is destroyed.