As a requirements engineer, I often explore the depth of UML and how it visualizes system connections. Understanding what are UML aggregation and composition is essential for modeling effective “part/whole” relationships. These concepts show how one class can include or depend on another, helping us design systems with clear structure and hierarchy. In this article, I’ll explain what are UML aggregation and composition and how they make complex systems easier to understand.
What Is UML Aggregation?
Aggregation represents a weak whole-part relationship.
I draw it as an association with a hollow diamond at the whole end.
For example, a Company can aggregate several Departments. The Company represents the whole, while Department represents the part.
I use aggregation when I want to express a whole-part structure without strong lifecycle dependency.
However, I do not interpret aggregation as general ownership. The relationship should represent a meaningful whole-part concept in the domain.
What Is UML Composition?
Composition represents a stronger whole-part relationship.
I draw it with a filled diamond at the whole end.
A composed part belongs to one composite whole at a time. In addition, its existence normally depends on that whole.
For example, I can model a Route as being composed of a Starting Point and a Destination when these elements form integral parts of that Route.
Composition expresses a strong relationship in which the parts belong to the structure of the whole.
Aggregation and Composition in the Example
The diagram shows both relationships.
Company and Department use aggregation. The hollow diamond appears at Company. Therefore, Company represents the whole and Department the part.
Route uses composition for Starting Point and Destination. The filled diamonds at Route indicate the stronger relationship.
In contrast, Route connects to Place of Interest through aggregation. A Place of Interest can therefore remain conceptually separate from a particular Route.
Multiplicity Adds Further Meaning
The diagram also combines whole-part relationships with multiplicities.
A Company can relate to several Departments. Likewise, a Route has one Starting Point and one Destination, while it can relate to several Places of Interest.
Therefore, the diamond and the multiplicity answer different questions.
The diamond tells me what kind of whole-part relationship exists. The multiplicity tells me how many instances may participate.
I use the relationship type and multiplicity together to describe the structure precisely.
How I Recognize Whole-Part Relationships
Natural-language requirements often contain useful clues.
For example, I look for expressions such as:
- consists of
- is composed of
- contains
- is part of
However, these expressions only give me candidates. I still check the domain meaning before choosing aggregation or composition.
If the part belongs strongly to one whole, I consider composition. If the part remains more independent, aggregation may fit better.
Conclusion
UML aggregation and composition both describe whole-part relationships.
I use a hollow diamond for aggregation and a filled diamond for composition. Aggregation expresses a weaker relationship. Composition expresses stronger ownership and lifecycle dependency.
I choose between aggregation and composition by asking how strongly the part belongs to the whole, not simply whether one class “has” another.
What’s Next?!
Now that you understand what UML is and how it supports requirements engineering, IT business analysis, and project management, it’s time to go a step deeper. In my next article, “Understanding the Syntax and Semantics of UML Classes,” I’ll explain how precise structure and meaning bring clarity to your models. Join me to discover how mastering UML syntax and semantics helps you create accurate, consistent, and professional system designs.
Bring Structure to Complexity with Requirements Modeling
If I want to understand requirements in a clearer and more complete way, I need more than text alone. I need models that show how ideas, workflows, and system structures connect. In the main article on Requirements Modeling, I explore essential Modeling Concepts, Process Modeling with BPMN, and the structural perspective of UML. Together, these topics help me analyze requirements more effectively, communicate them more clearly, and build a stronger foundation for successful system design.
This article covers concepts that are also included in the CPRE certification syllabus.