What is UML Diagrams | Class & Sequence Diagrams with Real Examples

Unified Modeling Language (UML) diagrams serve as the blueprint for software architecture, bridging the gap between a developer's mental model and actual production code. By visualizing system components, their internal structures, and their dynamic interactions, UML diagrams allow engineers to design robust, scalable, and maintainable object-oriented systems before writing a single line of code.

1. Why Do We Need UML Diagrams?

When you have a vision for a software application, you need a way to communicate that architecture to teammates, stakeholders, or interviewers.

Real-Life Analogy: Explaining an App Idea

Imagine you have a brilliant idea for a new application and want to explain it to a friend. You have two primary approaches:

• The Naive Approach (Text-Heavy): You write long, dense paragraphs detailing every component, database entity, and API call. This approach is monotonous, difficult to parse, and fails to intuitively show how different parts of the system interact.
• The Better Approach (Visual Diagrams): You sketch out the components on a whiteboard, showing boxes for entities and arrows to represent interactions. This is instantly intuitive, highly readable, and structurally clear.

UML (Unified Modeling Language) is simply the standardized, industry-accepted version of that whiteboard sketch. It provides a universal visual vocabulary to represent:

1. What components/objects exist in the system.
2. How those components are structured internally.
3. How they communicate and exchange messages with one another.

2. The Two Pillars of UML: Structural vs. Behavioral

UML diagrams are broadly categorized into two main families, representing the static layout and the dynamic execution of a system.

While there are 14 distinct UML diagrams (7 structural and 7 behavioral), 99% of Low-Level Design (LLD) interviews and real-world engineering tasks require mastering only two:

Note: The other 12 diagrams are highly use-case specific and rarely requested in general LLD interviews. Mastering Class and Sequence diagrams is sufficient to solve almost any system design problem.

3. Anatomy of a Class Diagram: The Class Box

A class diagram represents the static structure of your system's classes. In UML, a single class is represented by a solid rectangle divided vertically into three distinct compartments:

Code Evolution: From C++ Code to UML Representation

Let us look at a standard C++ class definition for a Car and see how it translates directly into a UML class box.

The C++ Class Definition:

#include <string>

class Car {
public:
    std::string brand;
    std::string model;
    int engineCC;

    void startEngine() {
        // Implementation
    }
    
    void stopEngine() {
        // Implementation
    }
    
    void accelerate() {
        // Implementation
    }
    
    void brake() {
        // Implementation
    }
};

The UML Class Box Representation:

• Top Compartment: Car
• Middle Compartment (Attributes):
  • brand: String
  • model: String
  • engineCC: int
• Bottom Compartment (Methods):
  • startEngine(): void
  • stopEngine(): void
  • accelerate(): void
  • brake(): void

Note: In UML notation, the variable/method name is written first, followed by a colon and its data/return type (e.g., variableName: Type). This is the reverse of languages like C++ and Java, but matches modern languages like TypeScript, Kotlin, and Go.

4. Access Modifiers & Abstract Classes in UML

To make class diagrams truly useful for code generation, we must represent object-oriented principles like encapsulation and abstraction.

Access Modifiers

UML uses simple prefix symbols to denote the visibility of attributes and methods:

Applying encapsulation best practices (hiding data and exposing behavior), we can update our Car class diagram to make attributes private and methods public:

Abstract Classes

An abstract class (a class containing at least one pure virtual/unimplemented method) is represented in UML by adding the stereotype <<abstract>> above the class name:

5. Class Associations: The "Is-A" Relationship (Inheritance)

Classes do not exist in isolation; they connect to form systems. The most fundamental relationship in Object-Oriented Programming is Inheritance, which represents an "Is-A" relationship.

Mental Model: The "Is-A" Rule

• A Cow is an Animal.
• A ManualCar is a Car.
• An ElectricCar is a Car.

In UML, inheritance is represented by a solid line with a closed, hollow arrow pointing from the child class to the parent class.

       Parent Class (e.g., Car)
                 ^
                 |  (Solid line, hollow arrow)
                 |
        Child Class (e.g., ElectricCar)

Real-World Example:

6. Object Associations: The "Has-A" Relationships

When one class contains, references, or uses another class, it establishes a "Has-A" relationship. In UML, these are categorized into three distinct levels of coupling: Simple Association, Aggregation, and Composition.

7. Programmatic Implementation of Composition

While Simple Association, Aggregation, and Composition are conceptually different in the real world, they are implemented almost identically in code. In languages like C++, they are all represented by holding a reference, pointer, or member variable of one class inside another.

Code Evolution: Implementing Composition in C++

Let us implement a composition relationship where class B contains a reference to class A.

#include <iostream>

// Class A (The Part)
class A {
public:
    void method1() {
        std::cout << "Executing Method 1 in Class A" << std::endl;
    }
};

// Class B (The Whole - Composed of A)
class B {
private:
    A* ptrA; // Reference to Class A

public:
    B() {
        ptrA = new A(); // Instantiating A inside B's constructor
    }

    ~B() {
        delete ptrA; // Ensuring A is destroyed when B is destroyed (Strict Composition)
    }

    void method2() {
        std::cout << "Executing Method 2 in Class B" << std::endl;
    }

    // Exposing A's functionality through B
    A* getA() {
        return ptrA;
    }
};

int main() {
    B* objB = new B();
    
    // Calling B's native method
    objB->method2();
    
    // Calling A's method through B's reference
    objB->getA()->method1();

    delete objB;
    return 0;
}

Design Subjectivity: The Swiggy/Zomato Menu Example

In software design, the boundary between Aggregation and Composition can be subjective and depends entirely on your business requirements.

• Scenario: A Restaurant has a Menu.
• Design Choice A (Composition): If your application deletes a restaurant from the database and you want its menu to be deleted instantly as well, this is Composition (filled diamond).
• Design Choice B (Aggregation): If your database allows a generic Menu to exist independently (perhaps to be assigned to another restaurant branch later), this is Aggregation (hollow diamond).

There is no single "correct" answer; it depends on how you choose to model your system's lifecycle.

8. Introduction to Sequence Diagrams (Behavioral Modeling)

While Class Diagrams show how classes are structured, Sequence Diagrams show how objects interact over time. They are crucial for mapping out complex execution flows, such as API requests, payment processing, or database transactions.

Core Components of a Sequence Diagram

To read or draw a sequence diagram, you must understand its four foundational elements:

• 1. Object Box: Placed at the top of the diagram. Unlike class diagrams, these represent specific runtime instances of a class (e.g., User, ATM, Database).
• 2. Lifeline: A vertical dashed line extending downwards from each Object Box. It represents the existence of the object over time.
• 3. Activation Bar: A thin vertical rectangle drawn over the lifeline. It indicates that the object is currently active, executing a process, or waiting for a response.

9. Message Types in Sequence Diagrams

Communication between objects is represented by horizontal arrows. The style of the arrow indicates the type of message being sent:

1. Synchronous Message

The sender sends a message and pauses execution to wait for a response.

• Notation: Solid line with a filled, closed arrowhead.
• Response Notation: Dashed line with an open arrowhead returning to the sender.

2. Asynchronous Message

The sender sends a message and continues its execution immediately without waiting for a response.

• Notation: Solid line with an open arrowhead.

3. Create & Destroy Messages

• Create Message: Used when one object instantiates another object dynamically during runtime. The arrow points directly to the newly created Object Box.
• Destroy Message: Used when an object's lifecycle ends. The lifeline terminates with a large "X" symbol.

4. Lost & Found Messages

• Lost Message: A message sent to an unknown recipient or lost during transmission. Represented by an arrow ending in a filled circle.
• Found Message: A message received from an unknown source. Represented by an arrow originating from an open circle.

10. Advanced Control Flows: Alt, Opt, and Loop

Modern sequence diagrams use frame boxes to represent programming logic like conditionals and loops:

• alt (Alternative - If/Else): Represents conditional logic. The frame is split into sections; if the condition is met, the top section executes, otherwise the bottom section executes.
• opt (Option - If): Represents a single conditional path. The messages inside the frame only execute if the condition is true.
• loop (Iteration): Represents a loop (e.g., for, while). The messages inside the frame repeat as long as the loop condition is met.

11. Complete Walkthrough: ATM Cash Withdrawal Flow

Let us design a real-world sequence diagram for an ATM Cash Withdrawal flow.

Step-by-Step System Flow

1. The User initiates a withdrawal by sending the amount and account number to the ATM.
2. The ATM dynamically instantiates a new Transaction object to handle the request.
3. The Transaction object queries the Account object to verify if sufficient funds exist.
4. The Account verifies the balance and returns true (or false) to the Transaction.
5. The Transaction passes this verification result back to the ATM and is then destroyed.
6. The ATM instructs the CashDispenser to dispense the physical cash.
7. The CashDispenser dispenses the cash and confirms completion to the ATM.
8. The ATM delivers the cash to the User.

Vertical Workflow Representation

Summary and Key Takeaways

• UML is a Visual Blueprint: It replaces long, confusing text descriptions with clear, standardized diagrams that map out system architecture before coding begins.
• Class Diagrams are Static: They show the classes, their attributes, methods, and access modifiers (+ for public, # for protected, - for private).
• Sequence Diagrams are Dynamic: They show how objects interact over time, making them perfect for mapping out step-by-step API or transaction flows.
• "Is-A" vs. "Has-A": Inheritance represents an "Is-A" relationship (solid line, hollow arrow), while Composition/Aggregation represents a "Has-A" relationship (diamond notations).
• Aggregation vs. Composition: Aggregation (hollow diamond) means the child can exist without the parent; Composition (solid diamond) means the child's lifecycle is strictly bound to the parent.
• Code Implementation is Identical: Despite their conceptual differences, Simple Association, Aggregation, and Composition are all implemented in code by holding a reference or pointer to another class.
• Frame Boxes Handle Logic: Use alt for if/else conditions, opt for simple if statements, and loop for iterations inside sequence diagrams.