Association Relationship

When beginners learn Object-Oriented Programming, they usually focus on:

Classes
Objects
Methods
Inheritance

But in real software systems, the most important question is often:

How do objects related to each other?

Consider an E-Commerce system.

We have:

Customer
Order
Product
Payment

The classes themselves are simple.

The challenge is understanding:

Who knows whom?
Who can access whom?
Who owns whom?
Who communicates with whom?
How many relationships exist?

Most real-world design mistakes occur not because a class is poor written, but because relationships between classes are poorly modeled.

Association is the first and most fundamental relationship in UML.

Everything else:

Aggregation
Composition
Dependency

can be viewed as specialized forms of association.

What Is an Association?

Definition:

Association represents a structural relationship where one object knows about another object.

Or

It is an connection between two classes that allows one object to use or communicate with another.

The key phrase is:

Knows About

Association does NOT imply:

Ownership
Lifecycle Control
Creation Responsibility
Containment

It simply means:

One object can communicate with another.

It is the most general (or broadest) relationship between object in OOAD.

Why is Association the broader term?

An association simply means:

Two objects are related in some way.

It says nothing about:
Ownership ❌
Lifetime ❌
Responsibility ❌
Containment ❌

It only says:
"These two objects are connected."

Real-World Analogy

Imagine:

Doctor ←→ Patient

A doctor knows about patients.

A patient knows about doctors.

Neither owns the other.

Neither controls the other's lifecycle.

This is a classic association.

Characteristics of Association

Association reflects a “has-a” or “uses-a” relationship.

Association has several important characteristics.

1 Objects Are Independent

Each object has it own lifecycle. Objects are lossely coupled and can exist independently of one another. The association can be unidirectional or bidirectional, and can follow different multiplicity patterns (1-to-1, 1-to-many, etc.).

Example:

Teacher -------- Student

A teacher exists even if no students are assigned.

A student exists even if no teacher is currently assigned.

Neither depends on the other's existence.

2 Objects Can Communicate

Association enables collaboration.

For example:

Customer -------- Order

A customer can place orders.

An order knows which customer placed it.

3 Association Represents Business Relationships

Association models relationships that naturally exist in the business.

Examples:

Doctor -------- Patient

Author -------- Book

Employee -------- Department

Customer -------- Bank Account

These relationships exist even without software.

First UML Association

Association is represented using a simple solid line.

Example:

Customer places Order

Diagram:

+------------+      +------------+
| Customer   |------|   Order    |
+------------+      +------------+

The line indicates that the two concepts are related.

Nothing more.

Interpretation:

Customer and Order are related.

Association in C++

Suppose:

class Order
{
};

class Customer
{
private:
    vector<Order*> orders;
};

Customer knows Orders

Association exists.

Notice:

Order can exist independently.

Customer can exist independently.

Association does not imply ownership.

Mental Model

Whenever you hear:

Uses
Knows
Works With
References
Interacts With

Think:

Association

Direction of Association

Associations may be:

1 Unidirectional

Only one object knows about the other.

Customer -------------> Order

The customer knows its orders.

The order does not know its customer.

C++ Example:

class Order
{
};

class Customer
{
private:
    std::vector<Order*> orders;
};

Only Customer stores references to Order.

2 Bidirectional

Both objects know each other.

Customer <------------> Order

Customer knows its orders.

Order knows its customer.

C++ Example:

class Customer;

class Order
{
private:
    Customer* customer;
};

class Customer
{
private:
    std::vector<Order*> orders;
};

Both classes maintain references.

Association vs Ownership

A common misunderstanding.

Many developers think:

Customer → Order

means Customer owns Order.

Not necessarily.

Association only says:

There is a relationship.

Ownership is introduced later through:

Aggregation
Composition

Multiplicity

Association alone is incomplete.

We must answer:

How many obejcts participate?

This is called multiplicity.

Example:

One Customer Many Orders

Diagram:

Customer 1 -------- * Order

Meaning:

One customer can have many orders.

Multiplicity Notation (Cardinality)

Association also tells us how many objects participate in the relationship.

This is called multiplicity.

One-to-One (1 : 1)

Example:

Person -------- Passport

Each passport belongs to one person.

Each person has one passport.

1 -------- 1

One-to-Many (1 : *)

Example:

Department -------- Employee

One department has many employees.

Each employee belongs to one department.

1 -------- *

Many-to-One (* : 1)

Simply the reverse.

Employee -------- Department

Many empoyees work in one department.

Many-to-Many (* : *)

Example:

Student -------- Course

One student studies many courses.

One course contains many students.

* -------- *

Exactly One

1

Example:

Order 1 ---- 1 Payment

One payment per order.

Zero or One

0..1

Example:

Order ---- 0..1 Coupon

Coupon optional.

Many

*

Meaning:

Unlimited

Example:

Customer 1 ---- * Order

One or More

1..*

Example:

Team 1 ---- 1..* Player

Range

2..5

Example:

Car 1 ---- 4..5 Tire

Four or five tires.

Reading Multiplicity Correctly

Students often read multiplicity backward.

Example:

Customer 1 -------- * Order

Correct reading:

One Customer can have many Orders.

NOT:

One Order has many Customers.

Rule:

Look at the multiplicity near the opposite class.

Example:

Teacher 1 ------- * Student

Interpretation:

One teacher teaches many students.

One-to-One Association

Example:

Person 1 -------- 1 Passport

Meaning:

Each person has one passport.
Each passport belongs to one person.

C++ Example:

class Passport
{
};

class Person
{
private:
    Passport* passport;
};

One-to-Many Association

Example:

Department 1 ------ * Employee

Meaning:

One department contains many employees.

C++ Example:

class Employee
{
};

class Department
{
private:
    vector<Employee*> employees;
};

Many-to-Many Association

Example:

Student * ------- * Course

Meaning:

Student can enroll in manay courses.
Course can contain many students.

C++ Example:

class Course;

class Student
{
private:
    vector<Course*> courses;
};

class Course
{
private:
    vector<Student*> students;
};

Navigability

Association may be directional.

Question:

Who knows whom?

Unidirectional Association

Example:

Customer ------> Order

Meaning:

Customer knows Order.

Order does NOT know Customer.

C++ Example:

class Order
{
};

class Customer
{
private:
    vector<Order*> orders;
};

Only one side has a reference.

Bidirectional Association

Example:

Customer <------> Order

Meaning:

Customer knows Order.

Order knows Customer.

C++ Example:

class Customer;

class Order
{
private:
    Customer* customer;
};

class Customer
{
private:
    vector<Order*> orders;
};

Both objects know each other.

When to Use Bidirectional Associations

Many beginners create bidirectional relationships everywhere.

Bad idea.

Example:

Customer ↔ Order
might be useful

But:
Product ↔ Every Other Class
create chaos.

Rule:

Use bidirectional association only when both directions are genuinely needed.

Self Association

A class can associate with itself.

Example:

Employee manages Employee

Diagram:

Employee
    ^
    |
    |
Employee

Meaning:

Manager is also an Employee.

C++ Example:

class Employee
{
private:
    Employee* manager;
};

Common Uses:

Organization Hierarchies

Folder Structures

Comment Threads

Category Trees

How to Decide Which Relationship is this?

A senior architect doesn't look at two classes and say:

“Hmm… I think this should be composition.”

Instead, they ask questions about the business semantics.

Step 1: Are these concepts related at all?

Ask:

Do these two concepts interact in the business?

If the answer is No, then there is no relationship.

Example:

Engine		Student

No business relationship.

If Yes, then start with:

Association

Because every meaningful relationship starts as an association.

Step 2: Is it just a connection?

Ask:

Do these objects simply know about each other?

Example:

Doctor --------- Patient

Doctor treats Patient.

Patient visits Doctor.

Neither ows the other.

Both exist independently.

✅ Association

Step 3: Is it a Whole-Part relationship?

Now ask:

Is one concept a whole and the other a part?

Example:

Car
Wheel

A wheel is part of a car.

Now we move beyond a simple association.

We ask another question.

Step 4: Can the part exist independently?

If YES

Department
Employee

Employee can move to another department.

The department closes, Employees still exist.

✅ Aggregation

If No

House
Room

Conceptually, a room doesn't exist without a house.

Destroy the house, the rooms disappear.

✅ Composition

The Complete Decision Tree

Are the two concepts related?
            │
      ┌─────┴─────┐
      │           │
     No          Yes
      │           │
 No Relationship  ▼
             Association
                   │
                   ▼
      Is it a Whole-Part relationship?
                   │
          ┌────────┴────────┐
          │                 │
         No                Yes
          │                 │
    Association             ▼
             	Can the part exist independently?
        	           │
        	  ┌────────┴────────┐
       	      │                 │
         	 Yes               No
       	      │                 │
         Aggregation      Composition