The 14 UML diagram types: definitions, symbols and when to use each

What are the 14 UML diagram types?

Structure: class, object, package, component, composite structure, deployment, profile. Behaviour: use case, activity, state machine, sequence, communication, interaction overview, timing. The last four are grouped as interaction diagrams in the UML 2.5.1 taxonomy (Annex A).

Which UML diagram should I use?

Start from the question you need answered, not from the diagram list. Most projects need a class diagram, one or two sequence diagrams for the tricky interactions, a state machine for anything with a lifecycle, and a use case or activity diagram for stakeholders.

What are the 7 UML structure diagrams and their symbols?

Structure diagrams show the things that exist in a system and how they are related, independent of time: classes and objects, packages, components and their interfaces, composite parts, deployment nodes and artifacts, and profiles that extend UML itself.

Class diagram

The class diagram is the UML diagram almost every project draws. Each class is a rectangle with up to three compartments (name, attributes, operations); relationships between classes are drawn as lines whose ends carry the meaning. UML 2.5.1 defines the arrowheads precisely: a hollow triangle is generalization (inheritance), a hollow diamond is aggregation, a filled diamond is composition, a dashed open arrow is dependency. Use it for domain models, ORM schemas and API object models.

Object diagram

An object diagram is a class diagram with the values filled in: concrete instances ("o1 : Order", underlined), their slot values and the links between them. It is the diagram to draw when a class diagram is correct but nobody can picture what a real configuration looks like — a tree of five nested Folder objects explains recursion better than a self-association ever will. Keep it small and dated.

Package diagram

Package diagrams show the large-scale structure of a model or codebase: which packages exist, what they contain and which ones depend on which. The only subtle part is the stereotypes on the dependency arrows — «import» makes the target's public contents visible in the source namespace, «merge» combines the definitions. Teams use package diagrams to enforce layering rules (UI may depend on domain, never the reverse).

Component diagram

Component diagrams are UML's architecture view: replaceable, encapsulated units and the contracts between them. The lollipop–socket notation is what makes them useful — you can see at a glance which interfaces are provided, which are required and which requirements are unsatisfied. Modern service architecture diagrams are informal component diagrams; ChartCraft's architecture generator draws the same structure without the UML icons.

Composite structure diagram

A composite structure diagram zooms into one class or component and shows the runtime parts it is made of and how they are connected. It answers "when a Car exists, what instances exist inside it and how do they talk?" — something a class diagram with composition arrows only implies. It is used heavily in systems engineering (SysML's internal block diagram is a direct descendant) and rarely in web development.

Deployment diagram

The deployment diagram maps software onto hardware: nodes are the machines or runtimes, artifacts are the files deployed onto them, and communication paths carry protocol labels. It is the UML answer to "where does this run?" and the formal version of the Kubernetes and cloud architecture diagrams most teams draw informally today.

Profile diagram

Added in UML 2, the profile diagram is a meta-level diagram: it defines new stereotypes (for example «entity», «service», «REST endpoint») that other diagrams can then apply. You will meet it if you use SysML, MARTE or a company-specific modelling profile, and almost never otherwise. The filled-triangle extension arrow is unique to this diagram.

What are the 7 UML behaviour diagrams and their symbols?

Behaviour diagrams show what happens over time: what the system does (use case), the flow of work (activity), the lifecycle of an object (state machine), and four views of interactions between parts (sequence, communication, interaction overview, timing).

Use case diagram

The use case diagram is the requirements diagram: who uses the system and for what. Its vocabulary is tiny (actor, ellipse, boundary, four line types) and the only thing people get wrong is the direction of «include» and «extend» — include points from base to the included use case; extend points from the extension to the base. The full notation and a worked ATM example are on the use case diagram page.

Activity diagram

Activity diagrams are UML's flowcharts, with two things a plain flowchart lacks: fork/join bars for parallel flow and swimlanes (activity partitions) for responsibility. UML 2 reworked their semantics on token flow, which is why forks and joins behave like Petri nets. Use them for business processes, algorithms with concurrency and anything cross-functional.

State machine diagram

A state machine diagram describes every state one object can be in and exactly which event moves it to which other state. The transition label grammar — event [guard] / action — is what makes it precise enough to implement. Composite states, history pseudostates and orthogonal regions handle the hard cases. The how to draw a state diagram guide walks through an order lifecycle.

Sequence diagram

The sequence diagram is the most used behaviour diagram: who sends what to whom, in what order. UML 2.5.1 distinguishes the arrowheads strictly — filled is synchronous, open is asynchronous, dashed is a reply — and adds combined fragments (alt, opt, loop, par, break, ref) so conditional and repeated interactions fit on one diagram. The how to make a sequence diagram guide covers them in order.

Communication diagram

A communication diagram (called a collaboration diagram in UML 1) shows the same messages as a sequence diagram but emphasises the links between objects instead of time. Order is given by numbers (1, 1.1, 1.2, 2…) rather than vertical position. It is compact for small interactions and unreadable beyond a dozen messages, which is why sequence diagrams won.

Interaction overview diagram

The interaction overview diagram stitches sequence diagrams together: it uses activity-diagram control flow (initial, decision, fork, final) but its nodes are "ref" frames pointing at other interactions or inline sequence diagrams. It is the right diagram when a flow such as checkout is really five sequence diagrams with branches between them.

Timing diagram

The timing diagram flips the sequence diagram on its side: time runs horizontally and each lifeline's state is drawn as a stepped line. It exists for real-time and embedded work where the question is "how long is the device in this state?" rather than "who calls whom?". Duration and time constraints such as {≤ 2 s} are first-class notation.

Which UML symbols are shared across diagram types?

A few symbols mean the same thing everywhere: the note, the «stereotype» guillemets, the dashed dependency arrow, the hollow generalization triangle, and the frame with a name tag in the top-left corner (sd, ref, act, stm, pkg) that UML 2 puts around any diagram.

Which UML diagrams can be written as code?

Mermaid supports class, sequence, state and (via journey/flowchart) rough activity and use case diagrams; PlantUML supports all 14. ChartCraft draws class, sequence, state and activity diagrams from plain English instead of a DSL. Minimal Mermaid for the three most common types:

Class diagram

classDiagram
  class Order {
    -Decimal total
    +pay() bool
  }
  Customer "1" --> "*" Order : places
  Order ..|> Payable

Sequence diagram

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: GET /orders
  S-->>C: 200 OK

State machine diagram

stateDiagram-v2
  [*] --> Draft
  Draft --> Paid : pay
  Paid --> [*]

The full syntax for every Mermaid diagram type is on the Mermaid cheat sheet; if you would rather not learn a syntax at all, the how to make a UML diagram guide shows the describe-and-generate route.

Related guides and generators