Composition in UML: Definition and Context
In the Unified Modeling Language (UML), **composition** is a type of association that represents a "whole-part" relationship, where the part is a critical and tightly-bound constituent of the whole. If the whole is destroyed, its parts are also destroyed. This distinguishes it from aggregation, which represents a weaker "whole-part" relationship where the part can exist independently of the whole.
Key Characteristics of Composition:
Strong Ownership: The "whole" object has strong ownership of the "part" object.
Lifecycle Dependency: The "part" cannot exist without the "whole."
Single Whole: A "part" is associated with exactly one "whole" object.
Implicit Deletion: Deleting the "whole" results in the deletion of all its "parts."
UML Notation for Composition
Composition is visually represented in UML diagrams (typically in class diagrams) as a solid diamond shape placed near the "whole" end of the association line. The line connects the "whole" class to the "part" class.
Composition Notation Elements:
Solid Diamond: Represents composition at the "whole" end.
Association Line: Connects the diamond (whole) to the part.
Multiplicity: Specifies the number of instances of the "part" associated with the "whole" and vice versa.
Example:
If we model a `Car` as the "whole" and `Engine` as a "part":
Diagram:
A solid diamond is attached to the Car class.
An association line connects the Car class to the Engine class.
Multiplicity:
Near Car: 1 (A car must have exactly one engine.)
Near Engine: 1..* (One engine may belong to one or more cars, depending on the model.)
Use in Context: Composition is widely used to model relationships where the components are intrinsic to the entity, such as:
A `House` and its `Rooms`
A `Library` and its `Bookshelves`
Understanding and utilizing composition effectively in UML helps convey strong ownership and dependency relationships within a system.
UML Aggregation Challenges
Aggregation poses a problem when interpreting some of the related associations. The composition context helps to assist with the problem of interpreting some of the related associations.Take a look at the Book class diagram below. When we first showed this example to you, we used aggregation. Realistically, it would be better modeled as composition, because the chapters and other parts cannot exist apart from the book. Now let us add some additional associations to show where this notation breaks down.
Book example
Looking at the Book class diagram, can you determine whether or not a footnote can refer to chapters in the same book or only chapters in other books, or if footnotes may refer to the book in which they reside or only to other books?
The context notation provides a very precise specification that handles these limitations of the current diagram. Start with a large rectangle. The name of the composite class becomes the name of the context. Inside the context, place the component class or classes.The nesting continues for all levels of the composition. Place the multiplicity of the parts in the top-right corner of the context box. The name of the part may be just the class name or it may include the role that the part plays in the composition, using the notation role:classname. Step through the creation of the book composition context to see how the parts fit together.
Book Composition Image Gallery1) Start with the Book context. Draw the box and place the name at the top. 2) Place the Chapter context inside of the Book context to show containment. Name the new component context and place the multiplicity in the top right corner. 3) Place the Footnote context inside the Chapter context to show containment. Place the multiplicity in the top right corner of the Footnote context. 4) A Footnote may refer to another Chapter in the same book. Draw the association line from the edge of the Footnote out of the Chapter context and back to the outside edge of the Chapter context and back to the outside edge of the Chapter context. The association line goes outside of the Chapter context in which the Footnote resides. 5) Footnotes can also refer to Chapters in other Books. Draw the association line from the outside edge of the Footnote, out of the Chapter and the Book context, then back inside the Book context to the outside edge of the Chapter context. The association goes outside of the context of the current Book and back in to another Chapter inside another Book. 6) A Footnote can refer to the Book in which it resides. Draw the association line from the Footnote to the inside edge of the Book context. The association does not go outside of the current Book context, but rather remains inside the context of the current Book.
Composite Aggregation is a Filled Diamond
Composite aggregation, or composition, means that the part is a member of only one composite object, and that there is an existence and disposition dependency of the part on the composite.For example, a hand is in a composition relationship to a finger.
In the Design Model, composition and its existence dependency implication indicates that composite software objects create (or caused the creation of) the part software objects (for example, Sale creates SalesLineItem).
But in the Domain Model, since it does not represent software objects, the notion of the whole creating the part is seldom relevant (a real sale does not createa real sales line item). However, there is still an analogy. For example, in a "human body" domain model, one thinks of the hand as including the fingers, so
if one says, "A hand has come into existence," we understand this to also mean that fingers have come into existence as well.
Composition is signified with a filled diamond. It implies that the composite solely owns the part, and that they are in a tree structure parts hierarchy; it is
the most common form of aggregation shown in models.
For example, a finger is a part of at most one hand, thus the aggregation diamond is filled to indicate composite aggregation (see Figure 4-9).
The context diagram is a general-purpose tool for presenting your models. Composition is only one possible use. Use the context diagram for any presentation where you want to limit the scope of the elements under review.
In the next lesson, you will learn the notation for specifying inheritance.
