Stop Memorizing All 14 UML Diagrams: Only 7 Are High-Frequency in Daily Development

UML 2.5 Overview

UML (Unified Modeling Language) standardizes the practice of drawing diagrams: what diagram to draw at each stage and what each symbol means are explicitly defined. UML 2.5 defines 14 diagram types , divided into two main categories:

Structural Diagrams (Structural) – describe the static skeleton of a system, answering "What is the system composed of?"

Behavioral Diagrams (Behavioral) – describe the dynamic runtime behavior of a system, answering "How does the system operate?"

Of the 14 diagrams, only 7 are truly high-frequency in daily development (marked with ★ in the classification tree below).

UML 2.5 Classification Tree

UML 2.5's 14 diagrams
├── Structural Diagrams — system's "skeleton"
│   ├── Class Diagram ★
│   ├── Object Diagram
│   ├── Component Diagram ★
│   ├── Deployment Diagram ★
│   ├── Package Diagram
│   ├── Composite Structure Diagram
│   └── Profile Diagram
└── Behavioral Diagrams — system's "actions"
    ├── Use Case Diagram ★
    ├── Activity Diagram ★
    ├── State Machine Diagram ★
    ├── Sequence Diagram ★
    ├── Communication Diagram
    ├── Interaction Overview Diagram
    └── Timing Diagram

Structural Diagrams

Class Diagram (★)

Describes classes, interfaces, and their static relationships (inheritance, realization, association, aggregation, composition, dependency). It is the core diagram of object-oriented design . The six relationship symbols are:

Inheritance : --|> (solid line + hollow triangle pointing to parent class)

Realization : ..|> (dashed line + hollow triangle pointing to interface)

Association : --> (solid arrow, "has/knows")

Dependency : ..> (dashed arrow, temporary use such as parameters or local variables)

Aggregation : o-- (hollow diamond, whole-part but separable)

Composition : *-- (filled diamond, whole-part with shared lifecycle)

Class diagrams are used for database table relationships and domain models.

Object Diagram

A snapshot of a class diagram at a specific moment — classes instantiated as concrete objects showing actual attribute values and links. "Class diagram is the blueprint; object diagram is the photo." Rarely drawn separately in daily work; mainly used to analyze complex runtime scenarios.

Component Diagram (★)

Describes the physical composition of a system (components, interfaces, dependencies). Commonly used for microservice decomposition and module boundary clarification.

Deployment Diagram (★)

Describes hardware topology and the physical deployment locations of software artifacts — which node runs which process, connected to which database. In modern terms, this is essentially a "server architecture diagram."

Package Diagram

Describes hierarchical and dependency relationships between packages (namespaces/modules). Extremely useful for layered architecture: dependencies must only go top-down . If the DAO layer references the controller, this diagram immediately reveals the violation.

Composite Structure Diagram

Describes the internal composition of a class/component (internal parts, ports, connectors). Used for precise description of complex component collaboration, mainly in embedded systems and complex framework design ; rarely needed in business application development.

Profile Diagram

A meta-diagram for extending UML itself (defining custom stereotypes, tagged values). Belongs to "modifying the tool" rather than "using the tool"; only encountered when creating domain-specific modeling standards.

Behavioral Diagrams

Use Case Diagram (★)

Describes the functionality a system provides from the perspective of actors (users or other systems). Standard artifact in the requirements analysis phase. Key symbols: oval = use case (a complete function); stick figure = actor; include = mandatory inclusion; extend = optional extension.

Activity Diagram (★)

Describes the execution path of a business process, similar to a "flowchart + parallel capabilities" . Suitable for clarifying cross-role processes such as approval flows and order fulfillment.

State Machine Diagram (★)

Describes the state transitions and triggering events of a single object throughout its lifecycle. Most commonly used for entities with state fields such as orders, tickets, approval records .

Common confusion: Activity diagram vs. State Machine diagram is the pair beginners mix up most. Activity diagram focuses on "process" (steps of one thing); State Machine focuses on "state" (the transformations of one entity).

Sequence Diagram (★)

Describes message interactions between objects in chronological order. It is the best tool for clarifying a single request call chain , essential for API design and troubleshooting call relationships.

Communication Diagram

A cousin of the sequence diagram: also expresses object interactions but emphasizes the link structure between objects, with messages labeled by sequence numbers. Sequence diagrams show "who comes first" more intuitively; communication diagrams show "who connects to whom" more intuitively. Sequence diagrams are generally sufficient.

Interaction Overview Diagram

A variant of the activity diagram where nodes are nested sequence/communication diagrams. Used to organize multiple interaction diagrams into a flow, effectively an "interaction diagram table of contents" ; only needed in very large systems.

Timing Diagram

Focuses on state/condition changes over time — horizontal axis is time, showing object state intervals. Typical scenarios: embedded timing (signal high/low levels), protocol state changes over time. Rarely used in business system development.

Scenario Cheat Sheet

Instead of memorizing 14 diagram definitions, remember this mapping:

Table-to-table, class-to-class relationships → Class Diagram

Complete call chain of a single request/operation → Sequence Diagram

State transitions of an entity (order state machine) → State Machine Diagram

Cross-person, cross-role business process (approval flow) → Activity Diagram

Functions the system provides to users (requirements phase) → Use Case Diagram

Microservice/module decomposition → Component Diagram

Physical layout of servers and containers → Deployment Diagram

Code layering and dependency direction → Package Diagram

Tool Recommendations

Documentation: Mermaid — all examples in this article use Mermaid syntax; diagrams as code, version-controlled alongside documentation , directly renderable in any Mermaid-supported editor.

Detailed diagrams: draw.io / PlantUML — draw.io is free; PlantUML is text-driven and its UML syntax is more standard than Mermaid's .

Database modeling: ER diagram tools — besides class diagrams, dedicated ER tools (e.g., DBeaver's built-in reverse engineering ) can be used.

Conclusion

There is no need to use all 14 diagrams — having many tools doesn't mean you must master them all. Being sufficient and drawing the right diagram is the goal. In practice, 80% of scenarios are covered by just four diagrams: Class Diagram, Sequence Diagram, State Machine Diagram, and Activity Diagram.