This posting is a continuation (Part 2) to the modeling class relationships in UML article dealing with the modeling of assoication, aggregation and composition relationships in UML.

Association

An association describes a set of tuples whose values refer to typed instances. An instance of an association is called a link - from UML Superstructure Specification 2.0 page 36

Association denotes a permanent relationship between two classifiers (such as a class or an interface). For example the association relationship between Customer and Address objects is shown in the code example below where the Address is part of the structure of the Customer object.

class Customer {

private Address customerAddress;

}

In UML association relationship between classifiers is represented as a solid line with the arrow head indicating the direction of navigability. The navigation in an association relationship denotes an efficiency of traversal, that’s all. Considering the Customer and Address example it could still be possible that one might be able to retrieve Address of a Customer through some other association from the domain model. The diagram below shows the UML representation of association below.

Aggregation

When an association relationship represents a whole-part relationship it can be an aggregation or a composition. They both are special forms of an association relationship.

In aggregation relationship the part object can exist without the whole object. Aggregation relationship is a shared relationship. The UML representation of aggregation relationship is shown below.

For example a developer can work in multiple projects and if one project is terminated the developer is still a part of other project(s). The UML diagram below shows the aggregation relationship between Project and Developer.

class Project {

private Developer [] developers;

}

Composition In composition relationship the part has the same lifetime as the whole. When the whole ceases to exist then the existence of the part makes little sense. In UML composition is represented as shown in below.

Composition relationship is non-shared; meaning the multiplicity of the aggregate end cannot exceed one. For example the relationship between a Car and its Engine is shown below as a composition.

class Car {

private final Engine theEngine = new Engine();

}

In Java the objects are never destroyed explicitly through the program that you write, they are released by the garbage collector. Thus showing the distinction between aggregation and composition is not that important except in the case when implementing the clone method i.e. a deep copy would indicate composition relationship and a shallow copy would imply an aggregation relationship.