Defining Class Relationships

In our previous lesson, we established the foundation for object-oriented modeling by learning how to represent a single class—with its attributes, operations, and visibility—using Mermaid syntax. You now have the tools to describe the internal blueprint of any object in a system. However, the real power of object-oriented design emerges not from isolated classes, but from how they collaborate.

This lesson focuses on bringing your diagrams to life by connecting those classes. We will explore the most fundamental type of relationship: the association. Your goal is to learn how to precisely define these connections by specifying their direction, the numerical constraints (multiplicity), and their purpose (role labels). Mastering these elements will allow you to create clear, unambiguous diagrams that accurately model the structural rules of a software system.

The Association Relationship: Connecting the Pieces

In programming, objects rarely exist in isolation. A Request object might hold a reference to a User object, or a Product object might be part of an Order. In UML, this general "uses-a" or "knows-about" relationship is called an association. It's a structural link between classes, indicating that instances of those classes are connected in some way.

An association is typically represented by a solid line. If the relationship is navigable in only one direction (e.g., an Order knows its Customer, but the Customer object doesn't necessarily have a pre-loaded list of all its Orders), we use an arrow to show the direction of that awareness.

Let's look at a complete class diagram that uses several associations.

In the diagram above, notice the line between Customer and Order. This is an association. The arrow pointing from Customer to Order indicates that from a Customer instance, you can navigate to its associated Order instances.

Defining Relationships in Mermaid

The Mermaid syntax for relationships is a natural extension of the class definitions you've already learned. It connects two classes with an arrow symbol.

As the documentation shows, the simplest association is written as:
Customer --> Order

This creates a navigable association from Customer to Order. For a bidirectional association, where each class is aware of the other, the syntax would be Customer <--> Order. However, in many designs, it's more common and often better practice to specify navigability in one direction.

Specifying Quantity with Multiplicity

An association line tells us that two classes are connected, but it doesn't say how many. Does an order belong to one customer or many? Can a customer have multiple orders? These are critical business rules that must be captured in the model. This is the role of multiplicity (also known as cardinality).

Multiplicity is expressed as a range of numbers placed at the end of an association line. The video you reviewed in the previous module has an excellent conceptual explanation.

The common multiplicity values are:

• 1: Exactly one
• 0..1: Zero or one (optional)
• 1..*: One or more
• 0..* or *: Zero or more (can be none)

In Mermaid, you add multiplicity by placing the values in quotes on either side of the relationship arrow.

Let's apply this to our Order System example. A Customer can have zero or more Orders, and each Order is associated with exactly one Customer. The Mermaid code for this would be:

Customer "1" --> "0..*" Order

Notice how the multiplicity "1" is placed next to Customer, and "0..*" is placed next to Order. The multiplicity at one end of the association describes how many instances of the class at that end can be linked to a single instance of the class at the other end. So, for one Customer instance, there can be 0..* Order instances. For one Order instance, there must be exactly 1 Customer instance.

Adding Clarity with Role Labels

Sometimes, the nature of a relationship isn't immediately obvious. A User and a Document could be related because the user "owns" the document, "edits" it, or "approves" it. A role label clarifies this by adding descriptive text to the association line.

Looking at the Order System diagram, you can see a label "line item" on the relationship between Order and OrderDetail. This tells us the role that OrderDetail plays in relation to an Order.

The syntax in Mermaid is simple: you add a colon : followed by the label text.

Combining all our elements, if we want to state that a Customer "places" Orders, the syntax would be:

Customer "1" --> "0..*" Order : places

This single line of Mermaid code now communicates a precise set of rules:

1. There is a relationship between Customer and Order.
2. A Customer is aware of its Orders.
3. An Order must be associated with exactly one Customer.
4. A Customer can be associated with zero, one, or many Orders.
5. The nature of this relationship is that the customer "places" the order.

Practice Exercise

Now, let's put these concepts into practice by modeling a simple blogging system. Your task is to create a Mermaid class diagram that models the following rules:

• A User can write zero or more Posts. A Post is written by exactly one User.
• A Post can have zero or more Comments. A Comment belongs to exactly one Post.
• A User can write zero or more Comments. A Comment is written by exactly one User.

Create a diagram with three classes: User, Post, and Comment. Define the associations between them using the correct arrows, multiplicity, and descriptive role labels (e.g., "writes", "contains"). For this exercise, you only need to show the classes and their relationships; you don't need to add attributes or operations.

Conclusion

In this lesson, you have taken a significant step from modeling isolated classes to describing the interconnected structure of a system. You learned to use associations to link classes and, crucially, how to enrich those links with details that reflect real-world rules.

Here are the key takeaways:

• Association: The --> arrow creates a basic navigable relationship.
• Multiplicity: Placed in quotes ("1", "0..*"), it defines the number of allowed instances in a relationship.
• Role Labels: Added with a colon (: label), they describe the purpose of the association.

You are now equipped to diagram the static relationships between the core entities of an application. So far, we've focused on the general "uses-a" association. In the next lesson, we will explore more specialized and powerful types of relationships: inheritance ("is-a") and composition/aggregation ("has-a"). These will allow us to model object hierarchies and part-whole relationships with even greater precision.