The Unified Modeling Language (UML) is a standard visual vocabulary for software, maintained by the Object Management Group (OMG); the current version is UML 2.5.1. It defines 14 diagram types. You do not need all of them: most teams use four or five regularly. This section explains every type with notation legends, worked SVG examples, pros and cons, and diagrams-as-code source.
UML diagrams split into two families. Structure diagrams show what the system is made of, independent of time: classes, objects, packages, components, internal parts and deployment nodes. Behavior diagrams show what the system does: use cases, activities and state machines. Inside behavior sits a third group, the interaction diagrams, which focus on messages exchanged between participants: sequence, communication, timing and interaction overview.
The seventh structure type, the profile diagram, is different from the others: it extends UML itself by defining stereotypes (such as «entity» or «microservice») and tagged values for a domain. It is used by tool builders and by standards such as SysML, so it has no separate page here.
A typical design moves from outside in. Use case diagrams capture who needs what. Activity diagrams describe the business process behind each use case. Sequence diagrams then show how software participants collaborate to carry it out, and class diagrams define the types they need. State machines describe objects with lifecycles, such as an order or a payment. Finally, component and deployment diagrams show how the pieces are packaged and where they run.
The interaction diagrams are four views of the same kind of information. Sequence diagrams emphasise order, communication diagrams emphasise links, timing diagrams emphasise duration, and interaction overview diagrams tie many interactions into one flow. Pick the one that answers your current question; you can redraw a scenario in another form later.
In practice, sketches beat completeness. A diagram is worth drawing when it answers a question someone is actually asking, and worth keeping when it is cheap to update, which is why diagrams-as-code tools such as PlantUML and Mermaid are popular.
| Question you need answered | Diagram | Typical reader |
|---|---|---|
| What types exist and how are they related? | Class | Developers |
| Does the model work on a real example? | Object | Developers, testers |
| How is the code organised; any cycles? | Package | Architects |
| What are the replaceable parts and their APIs? | Component | Architects |
| What is inside this one component? | Composite Structure | Designers |
| Where does it run and over which networks? | Deployment | Ops, SRE, security |
| Who uses the system and for what? | Use Case | Product, business |
| What are the steps of this process? | Activity | Analysts, developers |
| Which statuses can this object have? | State Machine | Developers, product |
| In what order do participants call each other? | Sequence | Developers |
| Which participants are coupled in this scenario? | Communication | Designers |
| How long does each step take; are deadlines met? | Timing | Performance, embedded |
| How do many scenarios fit together? | Interaction Overview | Architects |