UML (Unified Modeling Language) defines 14 diagram types across two main categories: structural diagrams that show how a system is organized, and behavioral diagrams that show how it operates over time.
In practice, most software teams use three or four of these regularly and rarely touch the others. This guide covers all 14, explains what each one is for, and is honest about which ones are actually worth learning.
Structural Diagrams
Structural diagrams show the static architecture of a system — what the components are and how they relate to each other.
Class Diagram
What it shows: Classes in a system, their attributes and methods, and the relationships between them (inheritance, association, composition, aggregation).
When to use it: Designing object-oriented systems. A class diagram is the blueprint for your code — it shows what objects exist, what they know, and what they can do. Useful for discussing domain models with the team before writing code, and for documenting existing architecture.
How common it is: Very common. If you're working in an OOP language, class diagrams are the standard way to communicate structure.
Object Diagram
What it shows: Specific instances of classes at a particular point in time — a snapshot of the system's object state.
When to use it: Debugging or clarifying complex class relationships by showing a concrete example. A class diagram can be abstract; an object diagram makes it concrete.
How common it is: Uncommon in practice. Usually replaced by unit test fixtures or just walkthrough examples in code reviews.
Component Diagram
What it shows: High-level software components and the interfaces between them. Components can represent services, libraries, modules, or executables.
When to use it: Documenting system architecture at a level above individual classes — showing how services or modules communicate, what APIs they expose, and what they depend on.
How common it is: Moderately common in distributed or microservices architectures. Often the right tool when a sequence diagram would be too detailed and a block diagram too vague.
Deployment Diagram
What it shows: Physical deployment — servers, containers, cloud resources, and which software runs where.
When to use it: Infrastructure planning, documenting production environments, or handing off to DevOps. Shows which services run on which nodes and how they communicate.
How common it is: Common in infrastructure-heavy projects. Less used in frontend or mobile work.
Package Diagram
What it shows: How code is organized into packages, modules, or namespaces, and the dependencies between them.
When to use it: Identifying dependency cycles, planning a modular architecture, or documenting the high-level organization of a large codebase.
How common it is: Uncommon. Most teams use folder structure and import graphs for this instead.
Composite Structure Diagram
What it shows: The internal structure of a class or component — how its parts are connected and how it collaborates internally.
When to use it: When you need to show the runtime structure of a complex class with multiple internal collaborations.
How common it is: Rare. Most engineers never draw one.
Profile Diagram
What it shows: Extensions to UML itself — custom stereotypes, tagged values, and constraints for specific domains.
When to use it: When creating a UML extension for a specialized domain (embedded systems, database modeling, etc.).
How common it is: Very rare. Primarily used by tool vendors and standards bodies.
Behavioral Diagrams
Behavioral diagrams show how a system behaves — how it responds to events, how processes flow, and how components interact over time.
Use Case Diagram
What it shows: The goals users (actors) want to achieve with a system, and how the system supports them. Not a flowchart — no implementation detail.
When to use it: Early requirements gathering. Use case diagrams are good for aligning with non-technical stakeholders on what a system does at a high level, without getting into how.
How common it is: Common in enterprise and academic contexts, less used in startup or agile product teams who prefer user stories.
Sequence Diagram
What it shows: How objects or services interact over time — what messages they send each other and in what order.
When to use it: Designing or documenting a specific flow: an API request-response cycle, an authentication flow, a checkout process. Sequence diagrams are excellent for finding edge cases — the process of drawing the diagram reveals missing error paths.
How common it is: Very common. One of the most useful diagrams for engineers. If you only learn one UML diagram type, make it this one.
Communication Diagram
What it shows: The same information as a sequence diagram — objects and their message exchanges — but organized spatially rather than as a timeline.
When to use it: When the structure of the collaborating objects matters more than the timing of messages.
How common it is: Uncommon. Sequence diagrams are almost always preferred because time ordering is usually important.
State Machine Diagram
What it shows: The states a system or object can be in, the events that trigger transitions between states, and the actions that occur during transitions.
When to use it: Any system with meaningful state: user account lifecycle (unverified, active, suspended, deleted), order status (pending, confirmed, shipped, delivered), media player (playing, paused, stopped). State machines make implicit state logic explicit.
How common it is: Common for complex state management, especially in backend systems and embedded software.
Activity Diagram
What it shows: The flow of control through a process — similar to a flowchart but with support for parallel flows and swim lanes.
When to use it: Documenting a business process, a complex algorithm, or a workflow with concurrent activities. The swim lane variant is useful for showing which actor or system is responsible for each activity.
How common it is: Common, especially in business process modeling. Often used as a more formal version of a flowchart.
Interaction Overview Diagram
What it shows: A high-level view of how multiple interaction fragments (sequence or communication diagrams) fit together.
When to use it: Complex systems where multiple sequence diagrams need to be composed into a larger flow.
How common it is: Rare. Most teams just reference multiple sequence diagrams separately.
Timing Diagram
What it shows: How state or condition changes over time for one or more objects — a timeline view of state transitions.
When to use it: Real-time systems, embedded software, or any scenario where timing constraints matter (this event must complete within 50ms of that event).
How common it is: Rare in web development. Common in embedded systems and hardware-software integration work.
The Three You Should Actually Learn
If you're a software engineer who doesn't work in a heavily process-driven environment, three UML diagrams cover most real-world situations:
Sequence diagram — Use it any time you need to show how components interact for a specific flow. Design it before you build the feature; update it when the design changes.
Class diagram — Use it to document domain models and object relationships. Especially useful when onboarding engineers to a new codebase or designing a new subsystem.
State machine diagram — Use it any time a system has non-trivial state: user accounts, orders, workflows. Making the states and transitions explicit prevents bugs from implicit assumptions.
The other eleven diagrams exist for good reasons, but unless your team is practicing formal UML modeling or working in a domain that requires them (embedded, enterprise architecture), you'll rarely need them.