Intuition The ONE core ideaA software system is invisible, so we draw it — and UML is a shelf of standardized shapes where every box, arrow, and diamond means exactly one agreed thing. Master the alphabet of shapes here, and every diagram in the parent topic becomes readable like ordinary sentences.
Before you can read a UML diagram you must know its vocabulary of marks . This page lists every symbol the parent note uses or quietly assumes, from absolute zero, in an order where each one leans on the previous. No shape is used before it is drawn and named.
Everything in UML is built from three primitive marks. Meet them first.
Definition The three primitives
A box (or oval, or rounded rectangle) = a thing — something that exists (an object, a class, a step, a state).
A line = a relationship — two things know about each other. A line has no direction.
An arrow = a directed relationship — something flows or points from tail to head . Direction carries meaning.
WHY UML needs all three: a system is made of things (boxes) that relate (lines) and act on each other (arrows). Those are the only ingredients. Every fancy UML symbol is one of these three with a decoration added to its end or its middle.
Intuition Read the ends, not the middleNearly all UML meaning lives at the ends of a line: a hollow diamond, a filled diamond, a hollow triangle, an open arrowhead. The line's job is just to connect; the shape stuck on its end tells you the flavour of the relationship. Train your eye to look at the tips.
Definition Stick figure = ActorA stick figure drawn outside a box means an Actor : a role that uses the system from the outside. WHAT it looks like: a little person. WHY a role and not a person — one human can play many roles (a Customer and an Admin ), and a role can be another computer, so we draw the job , not the individual.
Definition Oval = Use caseAn oval is a use case : one goal the system delivers, written as a verb phrase like Withdraw Cash . WHY an oval and not a box — the rounded, soft shape signals "a behaviour / a goal", visually distinct from the sharp-cornered thing -boxes you meet later in class diagrams.
Definition Big box = System boundaryA large rectangle drawn around the ovals is the system boundary . Inside = your software's responsibility; the actors stand outside it. WHY: it draws the literal line between "what we build" and "the world that uses it".
Definition The two dotted stereotype arrows
<<include>> — a dashed arrow with the word <<include>> on it. Points from a base use case to a sub-behaviour it always performs.<<extend>> — a dashed arrow with <<extend>> on it. Points from an optional extra into the base use case it enriches.
The << >> marks are called a stereotype — a label that refines what a plain arrow means. Plain-words: they let one arrow shape carry two precise meanings by writing the meaning on it.
Definition Generalization of actors and use cases (hollow triangle ▷)A solid line ending in a hollow triangle ▷ pointing at the general one means generalization : the thing at the tail is a specialized version of the thing at the triangle. WHAT it looks like: exactly the inheritance triangle you meet in class diagrams — but here it joins two actors or two use cases .
Actor example: a Premium Customer ▷— Customer (a Premium Customer can do everything a Customer can, plus more).Use case example: Pay by Card ▷— Make Payment (a specific way of achieving the general goal).
WHY use it: it factors out shared behaviour without repeating it — the specialized role/goal automatically inherits every association of the general one. Same "is-a" idea as class inheritance, reused in a behavioural diagram.
Mnemonic include vs extendincluD e → D epends always (base cannot skip it). eX tend → eX tra, optional.
The class diagram reuses the box primitive but splits it into three stacked compartments.
Definition Three-compartment class box
Top = the class name .
Middle = attributes (the data each object holds), written name: Type.
Bottom = operations (the methods it can do), written name().
WHY three shelves: a class is identity + data + behaviour , and separating them lets you read any one layer at a glance. This maps almost one-to-one onto real Object-Oriented Programming classes.
Definition Visibility marksA single symbol in front of a member says who may touch it:
+ public (anyone), - private (only this class), # protected (this class + subclasses), ~ package.
WHY tiny symbols: visibility is the heart of encapsulation, so UML gives it the shortest possible notation — one character.
Now the relationship ends — this is where reading "the tips" pays off.
Definition The five line-ends of a class diagram
Plain line = association ("knows about").Hollow diamond ◇ at the whole = aggregation ("has-a", parts survive alone).Filled diamond ◆ at the whole = composition ("owns-a", parts die with the whole).Hollow triangle ▷ pointing at the parent = inheritance ("is-a").Dashed line with an open (unfilled) arrowhead ⇢ = dependency ("uses temporarily"). NOTE the arrowhead is open/thin , not filled — that open V is what distinguishes a dependency from a solid message arrow, and the dashes distinguish it from a solid association.
WHY a scale of shapes: relationships range from loose to tight, so UML orders the decorations by "togetherness". Empty shapes = looser; filled shapes = tighter. The diamond points at the whole ; the triangle points at the parent .
Definition Navigability arrowheads (one-way awareness)A plain association line can carry a small open arrowhead → at one end . This is navigability : it says awareness flows one way only — the class at the tail knows about / can reach the class at the head, but not the reverse.
Order ——→ Customer : an Order can reach its Customer, but a Customer object holds no reference back to its Orders.A line with no arrowhead = navigability unspecified (often read as two-way); a line with arrowheads on both ends = explicitly two-way.
WHY it matters: navigability mirrors real code — which object stores a pointer/reference to which. It answers "from here, can I get to that object?" without adding a whole new symbol; it just decorates the association's tip.
Definition Multiplicity numbersSmall labels at a line's ends — 1, 0..1, *, 1..* — are multiplicity . They answer "how many objects on this side?". * = many, 0..1 = optional-one, 1..* = one-or-more. WHY: a relationship is incomplete without a count; "an Order has OrderLines" only makes sense once you say how many .
Common mistake Steel-man: "hollow vs filled diamond — surely just a style choice"Why it feels right: both are diamonds meaning whole/part. Fix: the lifecycle test. Ask "if I delete the whole, must the part die too?" Yes → filled ◆ (composition) . No → hollow ◇ (aggregation) . The fill is not decoration; it encodes life-and-death.
The sequence diagram introduces vertical time . Down = later.
Definition Lifeline vs activation bar
A dashed vertical line hanging under an object is its lifeline — it means "this object exists for this whole span of time".
A thin rectangle sitting on the lifeline is the activation bar — it means "right now this object is busy running a method ".
WHY two separate marks: existing and working are different. An object can sit idle (lifeline only) then wake up (bar appears). Confusing the two is the classic beginner error.
Definition Message arrows
Solid line, filled arrowhead → = synchronous message : the caller waits for a reply.Dashed line, open arrowhead ⇠ = return : the reply travelling back.Solid line, open (thin) arrowhead ⇀ = asynchronous message : the caller does not wait.
WHY filled vs open arrowheads: the fill tells you whether the sender blocks. Filled = "I stop and wait"; open = "I fire and move on". Same primitive arrow, decorated tip changes the timing meaning.
Definition Combined fragmentsA box drawn around several messages with a keyword in its corner — alt (if/else), opt (optional), loop, par (parallel) — groups messages under a condition. WHY: raw arrows only show a straight line of events; the fragment box adds branching and repetition without leaving the time-ordered picture.
Activity and state-machine diagrams share a family of flow symbols. These build on Flowcharts and Finite State Machines .
Definition Start and end markers
Filled dot ● = initial node : where flow begins.Bullseye ◉ (dot inside a ring) = activity-final node : the whole activity stops here — all running flows end.Circle with an X inside ⊗ = flow-final node : only this one flow stops; other parallel flows keep running.
WHY two different endings: in a parallel diagram you often want ONE branch to finish quietly while its siblings continue. The bullseye ◉ kills everything; the crossed circle ⊗ kills only its own thread. Using the wrong one accidentally halts the whole workflow.
Definition Action, decision, merge
Rounded rectangle = an action (activity) or a state (state machine) — a resting place or unit of work.Diamond ◇ with one input = a decision : chooses exactly one guarded output [condition].Diamond ◇ with one output = a merge : alternative paths rejoin.
WHY the same diamond for both: geometry of "many meet here" is identical; you tell decision from merge by counting inputs vs outputs.
Definition Fork and join barsA thick solid bar ━ :
splitting one flow into many = a fork (all branches run in parallel );
collecting many flows into one = a join (waits for all to finish).
WHY a bar and not a diamond: parallelism ("all at once") must look different from choice ("pick one"). Bar = and ; diamond = or .
Common mistake Steel-man: "diamond and bar both split — use either"Why it feels right: both are one-in-many-out. Fix: a decision ◇ fires exactly one branch (mutually exclusive). A fork ━ fires all branches at once. Different shape = different logic word (or vs and ).
Definition Transition labelevent [guard] / action
On a state-machine arrow you read three parts:
event = the trigger that fires the arrow (e.g. coin),[guard] = a condition in brackets that must be true, else the arrow is ignored,/action = what the system does while transitioning.
WHY three slots: a transition needs to say when (event), only-if (guard), and do-what (action) — bundling them keeps the whole rule on one arrow.
Definition Extra state-machine pseudostatesBeyond the plain initial ● and final ◉, richer state machines use small labelled markers called pseudostates (they are not real "resting" states — they only route the flow):
Circle with H = shallow history : on re-entering a composite state, return to whichever direct sub-state you last left.Circle with H* = deep history : return to the exact deeply nested sub-state you last left.Small filled diamond (junction) = a shared branch point that chains several guarded transitions together.Entry point / exit point (small circle on a composite state's border) = named doors into or out of a nested machine.Internal entry/, do/, exit/ lines inside a state = actions run when you enter, while you stay, and when you leave.
WHY they exist: real objects have nested modes (a Player is "On" and, inside that, "Paused"). History markers let the object remember where it was; junctions and entry/exit points keep complex wiring readable instead of a spaghetti of arrows.
The structural diagrams also describe how code is packaged and deployed . These use their own icons, built again from the box primitive.
Definition Component and its interfaces
Component = a rectangle with two small tabs (port stubs) on its left edge (the classic "component" icon), or a rectangle tagged <<component>>. It is a replaceable, deployable chunk of the system.Provided interface (lollipop ○—) = a small circle on a stick reaching out of a component: "here is a service I offer ".Required interface (socket ⊂—) = a half-circle cup on a stick: "here is a service I need ".Port = a small square on a component's border where an interface attaches.
WHY the lollipop-and-socket pair: it shows plug-and-socket wiring at a glance — a lollipop that fits into a socket means one component supplies exactly what another demands . This is the visual grammar of loose coupling and swappable parts, central to Software Architecture .
Definition Package = folder iconA rectangle with a small tab on its top-left corner (like a manila file folder) is a package : a named grouping/namespace that bundles related classes or components. WHY: large systems need containers, and the folder shape instantly reads as "a group of things live in here".
Definition Deployment node = 3-D box; artifact
Node = a 3-D box (cuboid) = a piece of physical or virtual hardware the software runs on (a server, a phone). WHY 3-D: the extra dimension visually separates "a physical machine" from the flat 2-D boxes that mean "software".Artifact = a rectangle tagged <<artifact>> (sometimes with a dog-eared page icon) = a concrete deployable file : a .jar, an .exe, a config file. Artifacts are deployed onto nodes.
WHY nodes and artifacts: a component diagram says what parts exist ; a deployment diagram says where they physically live and run — the last mile from design to running hardware.
Box, Line, Arrow primitives
Actor, Oval, Boundary, Generalization
Class box, line-ends, navigability
Lifeline, Bar, Message arrows
Nodes, Decision, Fork, Transition, Pseudostates
Component, Package, Deployment icons
Object-Oriented Programming
Everything descends from the three primitives at the top; only the decoration on the ends differs from diagram to diagram. Deeper study threads into Design Patterns , Software Architecture , Requirements Engineering , and SOLID Principles .
Cover the right side and test yourself. If any line stumps you, re-read its section above.
What are the three primitive marks of all UML? Box (a thing), line (a relationship), arrow (a directed relationship).
Where does most UML meaning live? At the ends/tips of a line, in the decoration stuck there.
A stick figure means…? An actor — a role outside the system, not a specific person.
<<include>> vs <<extend>>?include = always/depended-on sub-behaviour; extend = optional extra reaching into the base.
What does the hollow triangle mean between two actors or two use cases? Generalization — the tail is a specialized version of (inherits from) the general one.
The three compartments of a class box? Name, attributes (data), operations (methods).
+ - # ~ stand for…?public, private, protected, package visibility.
Hollow ◇ vs filled ◆ diamond? Aggregation (parts survive alone) vs composition (parts die with the whole).
What does the hollow triangle ▷ mean in a class diagram? Inheritance / generalization — "is-a", pointing at the parent.
What arrowhead does a dependency use, and on what line? An open (unfilled) arrowhead on a dashed line.
What does an open arrowhead at one end of an association show? Navigability — one-way awareness; tail class can reach the head class, not vice versa.
Lifeline vs activation bar? Lifeline (dashed) = object exists; bar = object is actively running a method.
Filled vs open arrowhead on a message? Filled = synchronous (caller waits); open = asynchronous (caller does not wait).
Decision ◇ vs fork ━? Decision fires exactly one guarded branch (or); fork fires all branches in parallel (and).
Activity-final ◉ vs flow-final ⊗? Bullseye stops the whole activity; crossed circle stops only that one flow, siblings continue.
Read coin [hasCredit] / unlock? event = coin, guard = hasCredit must be true, action = unlock.
What do H and H* pseudostates do? Shallow history returns to the last direct sub-state; deep history returns to the exact deeply nested sub-state.
Lollipop ○— vs socket ⊂— on a component? Lollipop = provided interface (service offered); socket = required interface (service needed).
What shape is a deployment node, and what is an artifact? Node = 3-D box (hardware); artifact = a concrete deployable file (.jar/.exe) deployed onto a node.
