Class Diagram

What is a Class Diagram?

A Class Diagram is a staticstructural diagram in UML (Unified Modeling Language) that visually represents the classes, attributes, operations (methods), and relationships among objects in an object-oriented system.

• Classes (blueprint for objects)
• Attributes (data/properties)
• Methods (functions/behavior)
• Relationships between classes (e.g., inheritance, associations)

It is primarily used in the design phase of software development.

Purpose of Class Diagram

• To describe the blueprint of a system’s design
• To communicate design between teams
• To define object types, data, and behavior
• To specify relationships such as inheritance, associations, and dependencies
• To reverse engineer code into visual form
• To act as a guide for developers, testers, and architects

Components of a Class Diagram

1️⃣ Class Structure

1 Class:

Represented by a rectangle divided into three compartments:

• Top Compartment: Class name bold and centered (e.g., Person)
• Middle Compartment: Attributes (data members) (e.g., -name: string)
• Bottom Compartment: Methods (functions/operations) +getName(): string)

+----------------------+
|      Person          | <- Top Compartment
+----------------------+
| -name: string        | <- Middle Compartment
| -age: int            |
+----------------------+
| +getName(): string   | <- Bottom Compartment
| +setAge(a: int): void|
+----------------------+

Attributes

• Represent internal state/data members of the class
• Syntax: visibility name: type = default

Methods

• Represent behavior or functionality
• Syntax: visibility name (parameters): returnType

2 Visibility (Access Modifiers)

Visibility markers define access levels for attributes and operations.

These markers help enforce encapsulation, a core principle in object-oriented design.

3 Abstract Classes and Methods

An Abstract class is a class that cannot be instantiated and may contain both implemented and unimplemented (abstract) methods. It is represented in UML class diagram as follows:

• Class name in italics or {abstract} stereotype.
• Abstract methods are listed without implementation.

Consider the below code:

class AbstractAccound {
    void calculateInterest() = 0;
}

The above code looks like the below UML diagram.

+------------------------------+
|    <<abstract>>              |
|    *AbstractAccount*         |
|------------------------------|
| +calculateInterest() : void  |
|                              |
+------------------------------+

4 Static Members

• Underlined e.g., +count: int (underlined)

5 Interfaces

An interface defines a contract that other classes must follow. It contains only abstract methods (no implementation). UML class diagram for interfaces contains the following compartments:

• Name Compartment: Contains the stereotype <<interface>> and the name of interface.
• Operation Compartment: Contains method signatures (i.e., abstract operations to be implemented).Only method declaration (no attributes).

For example, consider the following interface that can be represented as the diagram given below:

class Notifier {
	void sendAlert(string) = 0;
};

+------------------------------------+
|   <<interface>>                    | <-- Name compartment
|       Notifier                     |
|------------------------------------|
| +sendAlert(message: String): void  | <-- Operation compartment
|                                    |
+------------------------------------+

Note:

By default, interfaces don't have a compartment for attributes like regular classes. However, there is an exception, i.e., If the interface declares constants, you may include an attribute compartment to show them.

6 Enumeration (Enum)

An enumeration is a data type consisting of a fixed set of named values, often called literals. It is represented in UML class diagrams with the <<enumeration>> stereotype above the name in one compartment and list of literals in another compartment.

+-----------------------+
|   <<enumeration>>     |
|     Name              |
+-----------------------+
|   literal 1           |
|   literal 2           |
|   literal 3           |
+-----------------------+

2️⃣ Relationships

In object-oriented design, classes often need to interact with one another. Just like in the real world (e.g., Driver drives a Car), We model relationship between classes to represent these interactions.

2.1 Association (Use-a)

Definition: A general relationship between two classes (e.g., “uses" or “has”).

Imagine:

• A Teacherteaches a Course
• A Studentenrolls in a Course

This connection is called Association.

UML Notation: A solid line between the two classes.

Direction of Association:

• Bidirectional (default)

  • Both classes know about each other

    A -------- B
    

• Unidirectional

  • Arrow shows that one class knows about the other

    A --------> B
    

    Example: Student knows about Course, but not vice versa.

Multiplicity: It defines cardinality:

• 1 (exactly one)
• 0..1 (zero or one)
• * or 0..* (many)
• 1..* (at least one)

Types of Association

1 Simple Association (General Association)

A general binary relationship between two classes, indicating they are connected in some way.

Characteristics:

• No ownership implied
• Can be unidirectional or bidirectional
• Uses a solid line

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

A Customer places an Order.

2 Inheritance (Generalization)

Also called Generalization, this represents an “is-a” relationship between a subclass and a superclass. Example: A Dog is an Animal.

UML Notation: A solid line with a hollow triangle pointing to the parent class.

Characteristics:

• Denotes class hierarchy
• Represented by a solid line with a hollow triangle pointing to the superclass
• Subclass inherits attributes and behaviors from the superclass.

Example:

SavingsAccount ───▷ BankAccount

SavingsAccountis-aBankAccount.

3 Aggregation (Weak “has-a”)

• Part-whole relationship where parts can exist independently
• Represented with a hollow diamond (◇) at the aggregate (whole) end
• Loosely coupled
• Lifetime of the part is independent

Example: University contains Departments.

University ◇—— Department

(A university has departments, but departments can exist alone.)

Team ◇-------- Player

A Team has multiple Players, but a Player can exist without a Team.

Code:

class Player { };

class Team {
    vector<Player*> players;  // Aggregation
};

4 Composition (Strong “has-a”)

A stronger form of aggregation indicating exclusive ownership. The part cannot exist without the whole.

Characteristics:

• Represented by a filled diamond (◆) at the composite (whole) end
• Strong coupling
• When the whole is destroyed, parts are destroyed too

Example: A House is composed of Rooms.

House ◆—— Room

A House consists of Rooms, and rooms don't exist without a house.

Code:

class Room { };

class House {
    Room livingRoom;  // Composition
};

5 Realization (implementation)

Realization is the relationship between a class and an interface. The class agrees to implement the behavior declared by the interface or abstract class.

Real-World Analogy:

A TV remote (interface) defines how to press buttons.

A SamsungRemote (class) provides the actual behavior for those buttons.

• It's a contract: the class agrees to provide actual implementations.
• Common with interfaces or abstract base classes.

UML Symbol:

A dashed line with a hollow triangle pointing to the interface.

Example:

class Remote {  // Interface
public:
    virtual void turnOn() = 0;
};

class SamsungRemote : public Remote {
public:
    void turnOn() override {
        // Actual implementation
    }
};

5 Dependency

A class uses another class temporarily to perform a task.

Real-World Analogy:

A Doctor uses a Stethoscope during a check-up, but doesn't own it forever.

• It is temporary or one-time use relatipship.
• No strong ownership.
• Often seen in method parameters or local variables.

Example:

class Stethoscope {};

class Doctor {
public:
    void checkPatient(Stethoscope s) { // Dependency
        // Uses Stethoscope temporarily
    }
};

UML Symbol:

• A dashed arrow pointing from the dependent class to the class it uses.