Aggregation is used to model a compositional relationship between model elements. There are many examples of
compositional relationships: a Library contains Books, within a company Departments are made-up of
Employees, a Computer is composed of a number of Devices. To model this, the aggregate
(Department) has an aggregation association to the its constituent parts (Employee).
A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate
In this example an Customer has an Address. We use aggregation because the two classes represent part of
a larger whole. We have also chosen to model Address as a separate class, since many other kinds of things have
addresses as well.
An aggregate object can hold other objects together.
An aggregation relationship that has a multiplicity greater than one established for the aggregate is called
shared, and destroying the aggregate does not necessarily destroy the parts. By implication, a shared
aggregation forms a graph, or a tree with many roots. Shared aggregations are used in cases where there is a strong
relationship between two classes, so that the same instance can participate in two different aggregations.
Consider the case where a person has a home-based business. Both the Person and the Business have an address; in fact
it is the same address. The Address is an integral part of both the Person and the Business. Yet the Business
may cease to exist, leaving the Person hopefully at the same address.
Note also that it is possible in this case to start off with shared aggregation, then convert to non-shared aggregation
at a later date. The home-based business may grow and prosper, eventually moving into separate quarters. At this point,
the Person and the Business no longer share the same address. As a result, the aggregation is no longer shared.
An example of shared aggregation.
Composition is a form of aggregation with strong ownership and coincident lifetime of the part with the
aggregate. The multiplicity of the aggregate end (in the example, the Order) may not exceed one (i.e. it cannot
be shared). The aggregation is also unchangeable, that is once established, its links cannot be changed. By
implication, a composite aggregation forms a "tree" of parts, with the root being the aggregate, and the "branches" the
A compositional aggregation should be used over "plain" aggregation when there is strong inter-dependency relationship
between the aggregate and the parts; where the definition of the aggregate is incomplete without the parts. In the
example presented below, it does make sense to even have an Order if there is nothing being ordered (i.e.
Line Items). In some cases, this inter-dependency can be identified as early as analysis (as in the case with
this example), but more often it is not until design that such decisions can be made confidently.
A solid filled diamond is attached to the end of an association path to indicate composition, as shown below:
An example of compositional aggregation
In this example, the Customer Interface is composed of several other classes. In this example the multiplicities
of the aggregations are not yet specified.
A Customer Interface object knows which Display, Receipt Printer, KeyPad, and Speaker
objects belong to it.
A property of a class is something that the class knows about. As in the case of the Customer class shown above,
one could choose to model the Address of the Customer as either a class, as we have shown it, or as a set of
attributes of the class. The decision whether to use a class and the aggregation relation, or a set of attributes,
depends on the following:
Do the 'properties' need to have independent identity, such that they can be referenced from a number of objects?
If so, use a class and aggregation.
Do a number of classes need to have the same 'properties'? If so, use a class and aggregation.
Do the 'properties' have a complex structure and properties of their own? If so, use a class (or classes) and
Otherwise, use attributes.
In an Automated Teller Machine, the system must keep track of the current customer and their PIN, let us assume
that the Customer Interface is responsible for this. This information may be thought of as "properties" of the
class. This may done using a separate class, shown as follows:
Object properties modeled using Aggregation
The alternative, having the Customer Interface keep track of the current Customer and their PIN using
attributes, is modeled as follows:
Object properties modeled using Attributes
The decision of whether to use attributes or an aggregation association to a separate class is determined based the
degree of coupling between the concepts being represented: when the concepts being modeled are tightly connected, use
attributes. When the concepts are likely to change independently, use aggregation.
Aggregation should be used only in cases where there is a compositional relationship between classes, where one class
is composed of other classes, where the "parts" are incomplete outside the context of the whole. Consider the case of
an Order: it makes no sense to have an order which is "empty" and consists of "nothing". The same is true for
all aggregates: Departments must have Employees, Families must have Family Members, and so on.
If the classes can have independent identity outside the context provided by other classes, if they are not parts of
some greater whole, then the association relationship should be used. In addition, when in doubt, an association more
appropriate; aggregations are generally obvious, and choosing aggregation is only done to help clarify. It is not
something that is crucial to the success of the modeling effort.
Sometimes, a class may be aggregated with itself. This does not mean that an instance of that class is composed of
itself (this would be silly), it means that one instance of the class is an aggregate composed of other instances of
the same class. In the case of self-aggregations, role names are essential to distinguish the purpose for the
Consider the following self-aggregation involving the class Product:
In this case, a product may be composed of other products; if they are, the aggregated products are called
sub-products. The association is navigable only from the aggregate to the sub-product; i.e. sub-products would not know
what products they are part of (since they may be part of many products).