Mastering PlantUML: A Deep Dive into Composition and Aggregation Relationships

In the realm of software engineering and system design, the ability to clearly communicate the structure of a system is paramount. Visual Paradigm’s PlantUML feature allows developers to define complex class diagrams using simple text, bridging the gap between coding and design. Today, we will explore a fundamental yet critical concept in Object-Oriented Design: the distinction between Composition and Aggregation. We will analyze a classic example involving a University, its Departments, and Professors to understand how these relationships define the lifecycle and ownership of objects.

Understanding the Scenario: A University Structure

Before diving into the code, let’s establish the real-world logic that drives our diagram. We are modeling a hierarchy where:

A University is the top-level entity.
A Department exists within the University.
A Professor works within a Department.

The critical question we need to answer through our diagram is: How tightly coupled are these entities? If the parent object is destroyed, does the child object cease to exist as well? This is the core difference between Composition and Aggregation.

Defining the Classes

First, we define the three entities. In PlantUML, classes are defined using the class keyword. Let’s look at the structure provided in the example:

University: This class represents the institution. It has a name attribute and a method establishDepartment(), indicating it has the authority to create new departments.
Department: This class represents a specific division. It holds a deptName and has the method addProfessor().
Professor: This class represents an individual. It has a name and the capability to teach().

These definitions form the building blocks of our model, but they don’t yet tell us how the blocks fit together.

Relationship 1: Composition (University <– Department)

The first relationship defines the bond between the University and its Departments. In the diagram code, this is represented as:

University -- Department

What is Composition?

Composition is the strongest form of association. It implies a “Whole-Part” relationship where the parts cannot exist independently of the whole. This is often referred to as “strong ownership.”

The Lifecycle Logic

In our model, we treat the Department as a component that is intrinsically tied to the University. If the University is dissolved or shut down, the Departments cease to exist. A department without a university is a logical impossibility in this specific context.

Visualizing in PlantUML

The code University -- Department uses the asterisk () to denote a filled diamond. When rendered, this points to the “Whole” (University) and connects to the “Part” (Department). It visually screams that the Department is owned by the University and cannot survive its destruction.

Relationship 2: Aggregation (Department <– Professor)

The second relationship connects the Department to the Professor. The code looks like this:

Department o-- Professor

What is Aggregation?

Aggregation represents a “Has-A” relationship, but it is a weaker form of ownership compared to composition. In an aggregation relationship, the child object can exist independently of the parent object.

The Lifecycle Logic

Consider the nature of academia. If a specific Department is closed down or reorganized, the Professors within it do not disappear. They can move to other departments, or they can exist as independent entities until they are assigned to a new role. The Professor is not “owned” by the Department in the same way a Department is “owned” by the University.

Visualizing in PlantUML

The code Department o-- Professor uses a hollow diamond (o). This visually represents a looser connection. It signifies that while the Department “has” Professors, the Professors have an independent lifecycle.

Key Takeaways for System Architects

When designing your own systems using PlantUML or any other modeling tool, remember these rules:

Use Composition when the lifecycle is tied. If deleting the parent deletes the child, use the filled diamond (--). Think of Engine and Car, or Order and OrderItems.
Use Aggregation when the lifecycle is independent. If the child can survive the parent’s deletion, use the hollow diamond (o--). Think of Library and Books, or Department and Professor.

By correctly applying these concepts in your code, you ensure that your system architecture accurately reflects the real-world constraints and business logic of the application you are building.