Loading learning content...
UML isn't a single diagram type—it's a comprehensive family of 14 distinct diagram types, each designed to visualize different aspects of software systems. Trying to use a single diagram type for all purposes is like trying to navigate with only a road map: useful for driving, useless for hiking or flying.
Understanding the complete landscape of UML diagrams enables you to select the right tool for each communication need. You'll know when a class diagram is essential and when a sequence diagram communicates better. You'll recognize when specialized diagrams like state machines or component diagrams are the right choice.
This page maps the entire UML diagram territory, organized by the fundamental distinction between structural diagrams (what exists) and behavioral diagrams (what happens).
By the end of this page, you will understand all 14 UML diagram types—their purposes, when to use each, and how they relate to one another. You'll develop the vocabulary to discuss UML fluently and the judgment to select appropriate diagrams for specific design questions.
UML divides its 14 diagram types into two fundamental categories based on what aspect of a system they represent:
The Complete UML Diagram Hierarchy:
UML Diagrams
├── Structural Diagrams (7)
│ ├── Class Diagram
│ ├── Object Diagram
│ ├── Component Diagram
│ ├── Composite Structure Diagram
│ ├── Package Diagram
│ ├── Deployment Diagram
│ └── Profile Diagram
│
└── Behavioral Diagrams (7)
├── Use Case Diagram
├── Activity Diagram
├── State Machine Diagram
└── Interaction Diagrams (4)
├── Sequence Diagram
├── Communication Diagram
├── Interaction Overview Diagram
└── Timing Diagram
Note that behavioral diagrams include a subcategory of Interaction Diagrams that specifically focus on object-to-object communication. This reflects UML's recognition that message passing between objects deserves specialized notation.
In practice, most software engineering work uses only 4-5 diagram types: Class diagrams, Sequence diagrams, Use Case diagrams, Component diagrams, and State Machine diagrams. The specialized diagrams serve niche purposes. Focus on mastering the core diagrams first.
Structural diagrams capture the static aspects of systems—the entities that exist and how they connect. Each structural diagram type focuses on a different level of abstraction:
| Diagram Type | Primary Purpose | Key Elements | Usage Frequency |
|---|---|---|---|
| Class Diagram | Show classes, attributes, methods, and relationships | Classes, interfaces, associations, generalizations | Very High ⭐⭐⭐⭐⭐ |
| Object Diagram | Show instances of classes at a specific point in time | Objects (instances), links, attribute values | Low ⭐⭐ |
| Component Diagram | Show components, interfaces, and dependencies | Components, ports, interfaces, dependencies | High ⭐⭐⭐⭐ |
| Composite Structure | Show internal structure of classes/components | Parts, ports, connectors, collaborations | Medium ⭐⭐⭐ |
| Package Diagram | Show namespaces and dependencies between packages | Packages, imports, access relationships | Medium ⭐⭐⭐ |
| Deployment Diagram | Show physical deployment to hardware nodes | Nodes, artifacts, deployment specifications | High ⭐⭐⭐⭐ |
| Profile Diagram | Show UML extensions (stereotypes, tagged values) | Stereotypes, metaclasses, extensions | Low ⭐ |
Class Diagram — The Foundation:
The class diagram is the most fundamental and widely used UML diagram. It shows:
When to use: Designing domain models, planning class structure, documenting APIs, communicating object-oriented designs.
Object Diagram — Instances in Time:
Object diagrams show specific instances at a particular moment—concrete values rather than types. They're essentially class diagrams with:
john:Customer)When to use: Illustrating examples of class relationships, debugging complex scenarios, explaining how objects actually connect at runtime.
As systems grow beyond individual classes, higher-level structural diagrams become essential:
Component diagrams answer: "What are the major pieces of the system and how do they connect?"
They're essential for:
Deployment Diagram — Physical Infrastructure:
Deployment diagrams bridge the gap between software and hardware, showing where software components run physically:
Deployment diagrams are particularly valuable for cloud architectures—showing containers, load balancers, databases, and services across availability zones. They complement infrastructure-as-code by providing visual documentation that Terraform or CloudFormation templates lack.
Package Diagram — Organizing Namespaces:
Package diagrams show how model elements are grouped into namespaces and how those namespaces depend on each other. Key elements:
| Relationship | Notation | Meaning | Example |
|---|---|---|---|
| Import | <<import>> | Public elements of target package become available | Controller imports Model |
| Access | <<access>> | Private access to target package elements | Internal utilities access |
| Merge | <<merge>> | Combine package contents (rare, advanced) | Profile merging |
| Dependency | Dashed arrow | General dependency relationship | UI depends on Services |
When to use package diagrams:
Composite Structure Diagram — Internal Architecture:
Composite structure diagrams show the internal structure of classifiers—what's inside a class or component. They're the UML mechanism for showing "parts within wholes":
Composite structure diagrams are less common than class or component diagrams but essential for hardware/software co-design, embedded systems with specific internal topologies, and documenting framework extension points where parts can be substituted.
Behavioral diagrams capture what happens in a system over time—actions, state changes, and interactions. Let's survey all seven types:
| Diagram Type | Primary Purpose | Key Elements | Usage Frequency |
|---|---|---|---|
| Use Case Diagram | Show system functions from user perspective | Actors, use cases, relationships | High ⭐⭐⭐⭐ |
| Activity Diagram | Show workflows and process flows | Actions, decisions, forks, joins | High ⭐⭐⭐⭐ |
| State Machine | Show object lifecycle and state transitions | States, transitions, events, guards | High ⭐⭐⭐⭐ |
| Sequence Diagram | Show message exchanges over time | Lifelines, messages, activations | Very High ⭐⭐⭐⭐⭐ |
| Communication Diagram | Show object interactions spatially | Objects, messages, sequence numbers | Medium ⭐⭐⭐ |
| Interaction Overview | Combine activity and sequence diagrams | Frames, references, inline interactions | Low ⭐⭐ |
| Timing Diagram | Show state changes with precise timing | Lifelines, state/value changes, time axis | Low ⭐⭐ |
Use Case Diagram — Requirements from User Perspective:
Use case diagrams capture what a system does for its users (actors) without detailing how. Key elements:
When to use: Requirements gathering, scope definition, identifying system boundaries, communicating with non-technical stakeholders.
Activity Diagram — Workflow and Process:
Activity diagrams model workflows, business processes, and algorithm logic. They excel at showing:
Activity diagrams focus on the FLOW of activities (what happens in what order). Sequence diagrams focus on MESSAGE PASSING between specific objects. If you're explaining a process or algorithm, use activity. If you're showing how objects collaborate to accomplish something, use sequence.
State machine diagrams (also called statecharts or state diagrams) model how an object changes state in response to events. They're derived from David Harel's statecharts and are particularly powerful for modeling complex object lifecycles.
Classic State Machine Example: Order Processing
[●] → [Created] →(payment received)→ [Paid] →(shipped)→ [Shipped] →(delivered)→ [Delivered] → [◉]
↓ (cancelled)
[Cancelled] → [◉]
This simple notation communicates the complete lifecycle of an Order object:
When to use state machines:
State machine diagrams aren't just documentation—they often drive implementation. Many frameworks support state machine code generation, and the state pattern in GoF design patterns is essentially a state machine in code. A well-designed state machine diagram directly translates to robust, maintainable code.
Interaction diagrams form a subcategory of behavioral diagrams focused specifically on how objects exchange messages. The four interaction diagram types offer different perspectives on the same phenomenon:
Sequence diagrams are the most widely used interaction diagram. They excel at showing:
Communication Diagram (formerly Collaboration Diagram):
Communication diagrams show the same information as sequence diagrams but emphasize the structural relationships between objects rather than time ordering. Messages are numbered to show sequence.
Advantages over sequence diagrams:
Disadvantages:
Use SEQUENCE diagrams for most scenarios—they're universally understood. Use COMMUNICATION diagrams when object topology matters more than time sequence. Use TIMING diagrams for real-time constraints. Use INTERACTION OVERVIEW for complex multi-scenario narratives.
With 14 diagram types available, how do you choose? Start by identifying the question you're trying to answer:
| Question | Recommended Diagram | Why |
|---|---|---|
| What classes exist and how do they relate? | Class Diagram | Foundation for object-oriented structure |
| How do objects collaborate to perform X? | Sequence Diagram | Shows message flow over time |
| What can users do with the system? | Use Case Diagram | User-centric requirements view |
| What states can this object be in? | State Machine | Models lifecycle and transitions |
| What are the steps in this process? | Activity Diagram | Shows workflow and decisions |
| What components make up the system? | Component Diagram | High-level modular structure |
| Where is software deployed? | Deployment Diagram | Physical/virtual infrastructure |
| How are modules/packages organized? | Package Diagram | Namespace structure and dependencies |
The Essential Subset:
For most software engineering work, master these five diagrams first:
These five handle 90%+ of design communication needs. Add other diagram types as specific needs arise.
You now have a comprehensive map of UML's 14 diagram types, organized by structural and behavioral categories. You understand what each diagram shows and when to use it. Next, we'll explore when to use formal UML notation versus informal sketches—the pragmatic judgment that makes UML truly useful.