4.2.1 Why Relationships Matter
Defining classes alone is not enough. Real systems are built from interconnected objects.
Relationships define:
How classes depend on each other
Ownership and lifecycle control
Cardinality (how many objects relate to others)
If class definitions describe structure, relationships describe architecture.
In Mermaid, relationships are expressed using arrow-based syntax.
4.2.2 Basic Association
The simplest relationship is an association.
Syntax:
Example:
This means:
A User is associated with an Order.
At this stage, direction simply indicates conceptual navigation.
4.2.3 Bidirectional Association
If both classes reference each other:
This indicates mutual awareness.
Use bidirectional associations sparingly. Most designs benefit from directional clarity.
4.2.4 Adding Labels to Relationships
You can label associations.
Syntax:
Example:
This reads naturally:
Customer places Order.
Clear labeling improves domain readability.
4.2.5 Types of Relationships in UML
Mermaid supports common UML relationship types:
Relationship
Symbol
Meaning
Understanding semantic meaning is critical.
4.2.6 Aggregation (Weak Ownership)
Aggregation indicates:
One class contains another
Contained object can exist independently
Syntax:
Example:
Meaning:
A Department has Employees, but Employees can exist independently.
4.2.7 Composition (Strong Ownership)
Composition indicates:
Strong lifecycle dependency
If parent is destroyed, child is destroyed
Syntax:
Example:
Meaning:
Rooms cannot exist without a House.
Composition is stronger than aggregation.
4.2.8 Inheritance (Generalization)
Inheritance models “is-a” relationships.
Syntax:
Example:
Meaning:
Car is a Vehicle
Bike is a Vehicle
Use inheritance carefully. Prefer composition when possible.
4.2.9 Dependency
Dependency indicates usage without ownership.
Syntax:
Example:
Meaning:
OrderService depends on PaymentGateway.
Dependency relationships are common in service architecture.
4.2.10 Multiplicity (Cardinality)
Multiplicity defines how many instances relate.
Syntax:
Example:
Meaning:
One Customer can have zero or many Orders.
Common multiplicity values:
4.2.11 Multiplicity with Composition
Meaning:
A Library contains one or more Books.
Books cannot exist without Library.
This models ownership with quantity constraints.
4.2.12 Real-World Example — E-Commerce Model
This diagram expresses:
A customer places many orders
An order contains multiple products
Each order has exactly one payment
This is structural modeling at domain level.
4.2.13 Combining Relationship Types
Example:
Interpretation:
Company strongly owns Departments
Departments aggregate Employees
Employees depend on PayrollSystem
Understanding semantics prevents modeling mistakes.
4.2.14 Common Modeling Mistakes
Using composition when aggregation is appropriate
Overusing bidirectional arrows
Using inheritance for shared behavior instead of composition
Failing to label relationships
Poor:
Better:
Clarity is critical.
4.2.15 Hands-On Exercise
Design a University System:
Classes:
Requirements:
University strongly owns Departments
Department aggregates Professors
Students enroll in Courses
Use multiplicity everywhere
Ensure:
At least two labeled relationships
4.2.16 Design Guidelines
Use composition only for strong lifecycle dependency
Always specify multiplicity in domain models
Label relationships for readability
Avoid unnecessary bidirectional arrows
Keep diagrams focused on business domain
Remember:
Class diagrams model static relationships, not runtime message flow.
4.2.17 Key Takeaways
Relationships define how classes interact structurally.
Understanding:
is essential for building accurate system models.
In the next topic, we will explore Annotations and Styling, where you will learn how to enhance readability and presentation of class diagrams.
