A Composition is an Association and designates a special form of an Aggregation. It is used in cases where the abstraction of a model requires a strong emphasis on the whole/part-relationship, approximately corresponding to denoting a parent/child-relationship of the elements within the Composition.
A Composition between entities can be illustrated in UML with a filled diamond-shaped adornment starting at the root of the Composition (the composite), then connecting to its part(s) with a solid line.
In a Composition, the owning element (the Composite) is responsible for the lifetime of its parts. In a system, Compositions do not share instances of their parts: Each part always belongs to only one composite at a time. As such, the parts of a composite share the lifetime of the owning composite: If the composite is destroyed, its parts are destroyed, too. However, there is an important detail in this statement (see Lifecycle).
The following applies to the relationship between a composite
A and its parts :
- the owning object
Ais solely responsible for its parts
- the parts may not belong to another composite, for as long as they belong to
This implies that the parts exclusively belong to
A, for as long as
A exists, and
A is responsible for the deposition
of its parts. That must not necessarily mean that the parts are destroyed when
A is destroyed. Rather,
A sets up the constraints for what happens to its parts once it gets destroyed. It is entirely possible that existing parts might become the parts of another composite. However, the deposition must be controlled through
Rumbaugh et al. state that once the owning element is destroyed, the owning element may either destroy its parts, too, or permit other elements to take ownership:
"If the composite is destroyed, it must either destroy all its parts or else give responsibility for them to other objects." [📖UREF, p. 227]
A Composition serves as an abstraction to parent/child-relationships. It is defined through the sum of its parts, i.e. the owning object and its parts with the prerequisite that a Composition - as a stronger form of an Aggregation - maintains and controls references to its parts, and no other object must do this for as long as the owning composite exists. Other elements may reference the parts, but they may not control their lifecycle.
In the Toolbox-entry Association, the
Employee's relationship with
Address is modelled as plain Association.
We understand that
Employee must not share the same
Address-objects, since changing an address
Company would also change the data for
Employee . The formal definition for a Composition in UML rules the simultaneously existence of more than one owning object out.
How should a model depict the relationship between those elements? An Address is unique, so wouldn't it make sense to share addresses to prevent redundancy? The Association example shows that it would be good practice to use Value Objects: For as long as shared addresses do not change their values, owning objects may reference the same instances which will help with keeping memory footprint low. However, designing the model as a Composition forbids such an implementation:
If Address is navigable through
and there is an instance that is shared by both
Company, which of those elements is then considered to be the owning object of
Address? Not using arrows as indicators for the navigability doesn't help in this case: If a Composition is used in a design, then a part of it "may be part of only one composite object at a time." [📖UREF, p. 228] and further "during the life of the composite, no other object may have responsibility for it." [📖UREF, p. 227]
Modeling the relationship as an Aggregation provides a looser contract on the relationship between the element, and permits the developers to choose implementation details like applying the Value Object-design to
The following model hold Compositions and Aggregations:
Companyis the composite for
Companyis the composite for
Departmentis an aggregate for
Employeeis the composite for
Company has at least one
Employee has one
Account knows the
Employee it belongs to.
Department is associated with multiple
Employee leaves the
Company, the link to the
Account is also destroyed: Without an
Account has no meaning in this context and model.
Department closes, it has no impact to the Departments
Employees: They remain in the
Company closes, the
Departments shut down.
Company also removes all its
Employees in the given model.