Guidelines: Aggregation
Topics
- Aggregation
- Shared Aggregation
- Composition
- Using Composition to Model Class Properties
- Aggregation or Association?
- Self-Aggregations
Aggregation 
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 aggregation.
Example
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.
Shared Aggregation
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.
Example
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
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 parts.
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
Example
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.
Using Composition to Model
Class Properties
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 aggregation.
- Otherwise, use attributes.
Example
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
or Association?
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.
Self-Aggregations
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 if 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 association.
Example
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).
