ishavasya

1. UML

9 min read

What UML is

UML stands for Unified Modeling Language.

It is a standard visual language for describing a system:

  • what parts it has
  • how those parts relate
  • how behavior flows
  • how users or other systems interact with it

Think of UML as a shared sketching language for software and systems design, not as a programming language.

Where it came from

Why it was created

Before UML, many object-oriented design methods existed, and they did not match each other well. This created “method wars” and made communication harder across teams and tools.

UML was created to unify that landscape into one standard notation.

Who created it

The main creators were:

  • Grady Booch
  • James Rumbaugh
  • Ivar Jacobson

Their earlier methods heavily influenced UML:

  • Booch method
  • OMT (Object Modeling Technique)
  • OOSE (Object-Oriented Software Engineering)

When it was created

Key dates:

  • late 1994: Booch and Rumbaugh began unification work at Rational
  • fall 1995: Jacobson joined the effort
  • 1996: UML 0.9 and 0.91 appeared
  • December 1997: UML 1.1 was adopted by OMG as a standard

OMG = Object Management Group, the standards body that maintains UML.

Status today

As of April 28, 2026:

  • UML is still an official OMG standard
  • the current official version is UML 2.5.1
  • UML 2.5.1 was adopted in December 2017

So UML is still alive, but it is mature rather than trendy.

In practice today:

  • UML is used in architecture, design discussions, documentation, systems engineering, and enterprise modeling
  • most software teams use only a small subset
  • many teams prefer lightweight text-first tools such as Mermaid or PlantUML
  • people often say “UML” even when they mean “UML-like diagramming”

Versions you should know about

You do not need to memorize every version. Just know the rough evolution.

UML 1.x

Important versions:

  • 1.1 in 1997
  • 1.2 in 1999
  • 1.3 in 2000
  • 1.4 in 2001
  • 1.5 in 2003

This was the early standardization phase.

UML 2.x

Important versions:

  • 2.0 in 2005
  • 2.1.2 in 2007
  • 2.2 in 2009
  • 2.3 in 2010
  • 2.4.1 in 2011
  • 2.5 in 2015
  • 2.5.1 in 2017

UML 2.x is the modern family and the one that matters now.

Which version you should learn today

Learn practical UML 2.x, not version trivia.

More specifically:

  • conceptually, learn UML 2.5.x style
  • practically, learn the subset supported well by your tooling
  • for your notes, use Mermaid by default
  • if you later need stricter UML notation, use PlantUML

Do not aim to learn all of UML. That is unnecessary for most real work.

Learn this subset well:

  • use case diagrams
  • class diagrams
  • sequence diagrams
  • activity diagrams
  • state machine diagrams
  • component diagrams
  • deployment diagrams

If you learn those properly, you will cover most practical needs.

What UML is for

Use UML when you need to:

  • explain a design quickly
  • think before coding
  • document architecture
  • show system behavior over time
  • discuss requirements with others
  • communicate across developers, analysts, testers, and architects

Do not use UML just to make pretty diagrams. Use it to reduce ambiguity.

The most important idea

Different UML diagrams answer different questions.

Use this mapping:

  • Use case diagram: who uses the system, and for what
  • Class diagram: what things exist and how they relate
  • Sequence diagram: who talks to whom, and in what order
  • Activity diagram: what flow of work happens
  • State machine diagram: what states something can be in
  • Component diagram: what major software parts exist
  • Deployment diagram: where the software runs

If you choose the wrong diagram type, the diagram gets confusing fast.

Practical learning: start with examples

The fastest way to learn UML is to model a simple system repeatedly from different angles.

We will use a very small example:

Online library system

It lets a member:

  • search books
  • borrow a book
  • return a book

1. Use Case Diagram

What it teaches

This is the easiest starting point. It teaches:

  • system boundary
  • actors
  • user goals

Example

flowchart LR
    Member([Member])
    Librarian([Librarian])

    subgraph LibrarySystem[Library System]
        Search([Search Books])
        Borrow([Borrow Book])
        Return([Return Book])
        Register([Register Member])
    end

    Member --> Search
    Member --> Borrow
    Member --> Return
    Librarian --> Register

What to notice

  • actors are external roles, not internal classes
  • use cases are goals, usually written as verb phrases
  • the system boundary separates the system from the outside world

Practical rule

Use use case diagrams early, when requirements are still being discussed.

2. Class Diagram

What it teaches

This teaches:

  • domain structure
  • attributes
  • operations
  • relationships

Example

classDiagram
    class Member {
        +memberId: String
        +name: String
        +borrow(book: Book)
        +return(book: Book)
    }

    class Book {
        +isbn: String
        +title: String
        +isAvailable(): Boolean
    }

    class Loan {
        +loanDate: Date
        +dueDate: Date
        +close()
    }

    Member "1" --> "0..*" Loan : has
    Book "1" --> "0..*" Loan : appears in

What to notice

  • a class describes a type of thing
  • attributes hold data
  • operations show behavior
  • multiplicity matters:
    • 1 means exactly one
    • 0..* means zero or many

Practical rule

A good class diagram is not a database dump. It should show the important concepts and relationships.

3. Sequence Diagram

What it teaches

This teaches:

  • time order
  • interactions
  • responsibility flow

Example

sequenceDiagram
    actor Member
    participant App
    participant Catalog
    participant LoanService

    Member->>App: borrowBook(isbn)
    App->>Catalog: findBook(isbn)
    Catalog-->>App: Book
    App->>LoanService: createLoan(member, book)
    LoanService-->>App: loanCreated
    App-->>Member: success

What to notice

  • time flows top to bottom
  • sequence diagrams are ideal for service calls, API flows, and business scenarios
  • they help answer: which object should do what?

Practical rule

When a design feels messy, draw a sequence diagram. It exposes unclear responsibility quickly.

4. Activity Diagram

What it teaches

This teaches:

  • workflow
  • branching
  • parallel thinking
  • process logic

Example

flowchart TD
    A[Start Borrow Request] --> B{Book available?}
    B -- Yes --> C[Create Loan]
    C --> D[Notify Member]
    D --> E[End]
    B -- No --> F[Add to Waitlist]
    F --> E

What to notice

  • activity diagrams are good for business process flow
  • decisions are often clearer here than in sequence diagrams

Practical rule

If you are explaining a process, not object interaction, use an activity diagram.

5. State Machine Diagram

What it teaches

This teaches:

  • lifecycle of one thing
  • allowed transitions
  • event-driven behavior

Example

stateDiagram-v2
    [*] --> Available
    Available --> Reserved: reserve
    Reserved --> Borrowed: checkout
    Borrowed --> Available: return
    Borrowed --> Overdue: due date passed
    Overdue --> Available: return + fine settled

What to notice

  • a state machine focuses on one entity
  • it is ideal when rules depend on current state
  • common use cases: orders, tickets, payments, sessions, devices

Practical rule

If you ever say “it depends on the current status”, a state diagram may help.

6. Component Diagram

What it teaches

This teaches:

  • major modules
  • dependencies between subsystems
  • architecture at a higher level

Example

flowchart LR
    WebApp[Web App]
    Auth[Auth Service]
    Catalog[Catalog Service]
    Loan[Loan Service]
    DB[(Library DB)]

    WebApp --> Auth
    WebApp --> Catalog
    WebApp --> Loan
    Catalog --> DB
    Loan --> DB

What to notice

  • this is not about small classes
  • this is about deployable or conceptual building blocks

Practical rule

Use component diagrams in architecture conversations, not detailed coding discussions.

7. Deployment Diagram

What it teaches

This teaches:

  • runtime environment
  • nodes
  • where components execute

Example

flowchart TD
    UserDevice[User Browser]
    WebServer[Web Server]
    AppServer[Application Server]
    Database[(Database Server)]

    UserDevice --> WebServer
    WebServer --> AppServer
    AppServer --> Database

What to notice

  • deployment diagrams answer: where does it run?
  • useful for production architecture, networks, and infrastructure reviews

The practical UML toolkit

If you want to be effective in real work, learn these questions:

Requirements

  • Who uses the system?
  • What do they want to do?

Use:

  • use case diagram

Domain modeling

  • What important concepts exist?
  • How are they related?

Use:

  • class diagram

Behavior

  • What happens step by step?
  • Who calls whom?

Use:

  • sequence diagram
  • activity diagram

Lifecycle

  • What statuses can this thing have?
  • Which transitions are valid?

Use:

  • state machine diagram

Architecture

  • What major parts exist?
  • How do they connect?
  • Where do they run?

Use:

  • component diagram
  • deployment diagram

A small progression you can follow

For an actual feature, model in this order:

  1. Use case: what goal is being supported?
  2. Class diagram: what concepts are involved?
  3. Sequence diagram: how does the scenario execute?
  4. Activity diagram: what process or decision flow exists?
  5. State diagram: does any key entity change state over time?
  6. Component/deployment: where does this fit architecturally?

This order is practical because it moves from business goal to design detail.

What beginners usually get wrong

1. Using UML for everything

Not every idea needs a formal diagram. Sometimes a short paragraph is better.

2. Mixing levels of abstraction

Do not put:

  • database tables
  • UI screens
  • service endpoints
  • business goals

all into one diagram.

Pick one viewpoint at a time.

3. Making diagrams too big

If one diagram explains everything, it usually explains nothing.

4. Treating UML like code

UML is a communication tool, not the product itself.

5. Chasing notation perfection too early

Correctness matters, but clarity matters first.

What you actually need to know to “know UML”

You do not need all 14 UML diagram types to claim practical UML knowledge.

You should be able to:

  • choose the right diagram for the question
  • read common UML notations
  • draw small clear diagrams
  • model structure, behavior, and architecture separately
  • use diagrams to clarify design decisions

If you can do that, you already know UML well enough for real engineering use.

For your work, learn this subset deeply:

  • use case
  • class
  • sequence
  • activity
  • state
  • component
  • deployment

Skip deep study of less commonly needed diagrams for now, such as:

  • timing
  • interaction overview
  • communication
  • composite structure
  • profile details

Those can be learned later if needed.

Mermaid vs formal UML

For these notes, Mermaid is the best default because:

  • it stays inside Markdown
  • it is fast to edit
  • it is enough for most study and design work

But remember:

  • Mermaid is often UML-like, not perfect formal UML
  • if you need stricter notation, switch to PlantUML

That is a tooling decision, not a conceptual one.

Bottom line

UML is a standard visual language for modeling systems.

It was created in the mid-1990s by Booch, Rumbaugh, and Jacobson, standardized by OMG, and the current official version is UML 2.5.1.

Today, the correct goal is not to learn every corner of UML.

The correct goal is to learn a practical subset well enough to:

  • analyze requirements
  • model domain concepts
  • describe interactions
  • reason about lifecycle
  • communicate architecture clearly

That is enough for real work.

Sources

Graph View