UML Diagrams: All 14 Types Explained (with Examples)
UML 2.5 defines exactly 14 diagram types, split into 7 structural diagrams that show what a system is made of and 7 behavioral diagrams that show how it acts at runtime. In practice, most engineering teams lean on just four of them: class, sequence, activity, and state machine. This guide walks through all 14 with the notation you actually need, explains why the other ten are rare outside of specific niches, and shows when UML earns its keep in 2026 versus when a whiteboard box-and-arrow sketch is the smarter call.
What are the 14 types of UML diagrams?
The Unified Modeling Language 2.5 specification (maintained by the Object Management Group) divides its 14 diagram types into two families. Structural diagrams describe the static parts of a system: class, component, deployment, object, package, profile, and composite structure. Behavioral diagrams describe how those parts interact over time: use case, activity, state machine, sequence, communication, interaction overview, and timing.
The last four behavioral diagrams — sequence, communication, interaction overview, and timing — form a subgroup called interaction diagrams, because each is a different view of message exchanges between objects. A sequence diagram emphasizes time ordering, a communication diagram emphasizes object relationships, a timing diagram emphasizes state changes against a clock, and an interaction overview stitches multiple interactions together with activity-diagram flow control.
You do not need all 14. UML was designed in the 1990s for heavyweight model-driven development, where teams generated code from models. Modern teams use UML selectively as a communication tool, which is why a handful of diagram types dominate real-world usage while the rest survive mostly in textbooks, certification exams, and a few regulated industries like automotive and aerospace.
The 7 structural UML diagrams, explained
The class diagram is the flagship. Each class is a rectangle with three compartments: name, attributes, and operations, with visibility markers (+ public, - private, # protected, ~ package). Relationships carry precise semantics: a solid line with a hollow triangle is generalization (inheritance), a dashed line with a hollow triangle is interface realization, a hollow diamond is aggregation, a filled diamond is composition, and multiplicities like 1..* or 0..1 annotate the ends. If you learn the notation for only one UML diagram, make it this one — it maps directly onto code and database schemas.
Component and deployment diagrams cover architecture. A component diagram shows replaceable software units and their provided/required interfaces using ball-and-socket (lollipop) notation — think OrderService exposing a REST interface that PaymentService consumes. A deployment diagram maps artifacts onto physical or virtual nodes drawn as 3D boxes: your Spring Boot JAR on an EC2 instance, your Postgres database on RDS. In 2026 most teams draw cloud architecture with AWS or Azure icon sets instead, but deployment diagrams still appear in enterprise architecture documents.
The remaining four structural types are situational. An object diagram is a class diagram snapshot with real instance values (order42: Order with total = 99.50), useful for explaining tricky object graphs. A package diagram groups classes into namespaces with dashed dependency arrows, handy for visualizing module boundaries in a monolith. A composite structure diagram shows the internal parts and ports inside a single class, and a profile diagram defines custom stereotypes like «microservice» to extend UML itself — both are rare outside systems-engineering tools like Enterprise Architect or Cameo.
The 7 behavioral UML diagrams, explained
The sequence diagram is the most-drawn behavioral diagram in software teams. Participants sit along the top with dashed lifelines dropping down, activation bars show when an object is executing, solid arrowheads mean synchronous calls, open arrowheads mean asynchronous messages, and dashed arrows carry return values. UML 2 added combined fragments — alt for branching, opt for conditionals, loop for iteration, par for parallelism — which let a single diagram capture an entire API flow such as client, gateway, auth service, and database.
Activity diagrams model workflows: rounded rectangles for actions, diamonds for decisions with guard conditions in square brackets like [payment approved], thick bars for fork and join to show parallel paths, and swimlanes (partitions) to assign steps to actors or services. State machine diagrams model the lifecycle of a single entity: rounded-rectangle states, a filled circle for the initial state, a bullseye for the final state, and transitions labeled trigger [guard] / effect. An Order entity moving through pending, paid, shipped, delivered, and cancelled is the canonical example, and libraries like XState make the mapping to code direct.
Use case diagrams — stick-figure actors connected to ellipses inside a system boundary, with «include» and «extend» dependencies — remain popular with business analysts for scoping, though engineers usually find a user-story list carries the same information. The last three are the rarest: communication diagrams number their messages (1, 1.1, 1.2) on links between objects and are almost always worse than an equivalent sequence diagram; timing diagrams plot state against a time axis and matter mainly in embedded and real-time work; interaction overview diagrams compose interaction fragments into a flowchart and are seldom seen outside the UML spec itself.
Which UML diagrams do engineers actually use?
Four diagram types account for nearly all UML drawn in working software teams: class, sequence, activity, and state machine. They survive because each answers a question that comes up constantly. What are the entities and how do they relate (class)? What calls what, in what order (sequence)? What is the process flow, including branches and parallel work (activity)? What states can this thing be in, and what moves it between them (state machine)?
The other ten fade for a common reason: a simpler notation does the same job. Deployment diagrams lost to cloud-provider icon diagrams, use case diagrams lost to backlog tools, communication diagrams were always a redundant projection of sequence diagrams, and profile or composite structure diagrams only pay off in model-driven toolchains that most teams abandoned. Timing diagrams keep a real niche in firmware and protocol work, but a web or backend engineer can go an entire career without drawing one.
A practical learning order: start with class diagrams because the notation transfers to entity-relationship modeling and code review discussions, then sequence diagrams because they are the lingua franca of API design docs and incident postmortems. Add activity and state machine diagrams when you hit a gnarly workflow or lifecycle bug. Skim the rest so you can read them when they appear in vendor docs, and stop there.
Is UML overkill in 2026, or still worth it?
UML is valuable precisely where ambiguity is expensive. A sequence diagram in an RFC removes arguments about retry ordering before anyone writes code. A state machine diagram catches the unreachable state or missing transition that a prose spec hides. A class diagram accelerates onboarding onto a domain model with fifty entities. In regulated domains — medical devices, automotive (AUTOSAR), defense — UML or its cousin SysML is often contractually required.
UML is overkill when the diagram costs more than the conversation it replaces. Nobody needs a use case diagram for a CRUD feature, full method-level class diagrams rot the day someone renames a function, and exhaustive modeling of a codebase that changes weekly is a treadmill. The 2026 consensus is sketch-level UML: informal enough to draw in minutes, formal enough that the arrows mean something.
Tooling shapes this tradeoff. Mermaid embeds class, sequence, and state diagrams as text in Markdown and versions cleanly in git, which is ideal for docs-as-code, though its auto-layout struggles past roughly 15 nodes and it cannot express full UML notation. draw.io (diagrams.net) is free, has complete UML shape libraries, and gives you full manual control at the cost of drawing everything by hand. Lucidchart adds polished real-time collaboration but locks meaningful use behind per-seat pricing. AI generators like AIDrawIO occupy a middle ground: you describe the diagram in plain English and get an editable draw.io-format diagram, trading some initial control for speed while keeping full manual editability afterward.
How do you make a UML diagram with an AI generator?
The slowest part of making a UML diagram by hand is not deciding what goes in it — it is placing boxes, routing arrows, and remembering whether composition is the filled or hollow diamond. An AI UML diagrammer collapses that step: you write what the system does, and the generator produces the diagram with correct notation. With AIDrawIO's free UML diagram generator (aidrawio.com/en/tools/uml-diagram-generator) you get 5 generations per hour with no account, and the output is standard draw.io XML you can keep editing in AIDrawIO or diagrams.net, then export as SVG or PNG for docs and pull requests.
Prompt with the same specificity you would use in a design review. For a sequence diagram: "Sequence diagram for checkout: Client calls API Gateway, which calls AuthService to validate the JWT. On success, Gateway calls OrderService.createOrder, which writes to Postgres and publishes OrderCreated to Kafka. Include an alt fragment for auth failure returning 401." For a class diagram: "Class diagram for a blog: User has many Posts, Post has many Comments (composition), Post implements a Publishable interface with publish() and archive(). Show attributes and multiplicities." Named participants, explicit relationship types, and requested fragments produce a diagram that needs minor cleanup instead of a rebuild.
Because the result is a normal editable diagram rather than a rendered image, you refine it the way you would any draw.io file: drag lifelines, fix a multiplicity, add the edge case the AI missed. You can also upload a photo of a whiteboard sketch and convert it into an editable vector diagram, and version history lets you keep the diagram current as the design evolves — which is where most hand-drawn UML dies.
Experimente gratis UML generator
AI UML class, state, and activity diagrams. Describe in plain English, get draw.io XML in seconds. No account required.
Perguntas frequentes
What are the 14 types of UML diagrams?
UML 2.5 defines 7 structural diagrams (class, component, deployment, object, package, profile, composite structure) and 7 behavioral diagrams (use case, activity, state machine, sequence, communication, interaction overview, timing). Sequence, communication, interaction overview, and timing diagrams form a subgroup called interaction diagrams. Most teams only use four of the fourteen regularly.
What is the difference between structural and behavioral UML diagrams?
Structural diagrams show the static architecture of a system — its classes, components, packages, and how they are deployed onto hardware. Behavioral diagrams show dynamics: how objects exchange messages over time, how workflows branch, and how an entity moves between states.
Which UML diagram should I learn first?
Start with the class diagram, since its notation (inheritance triangles, composition diamonds, multiplicities) maps directly to code and data models. Learn the sequence diagram second — it is the standard way to document API flows and service interactions in design docs and postmortems.
What is the best free tool to make UML diagrams?
draw.io (diagrams.net) is the strongest free manual editor with full UML shape libraries, and Mermaid is best if you want text-based diagrams versioned in git. If you want to skip manual layout, AIDrawIO generates editable draw.io-format UML diagrams from a plain-English description, free for 5 generations per hour with no account.
Is UML still used in 2026?
Yes, but selectively. Class, sequence, activity, and state machine diagrams remain standard in design docs, RFCs, and onboarding material, while full model-driven UML survives mainly in regulated industries like automotive and aerospace. Most teams now draw sketch-level UML rather than exhaustive models.