Component diagram symbols
Every mark a UML component diagram can carry, and what each one commits you to: the plug icon, the lollipop and the socket, assembly and delegation connectors, ports, and the four stereotypes worth writing.
7 min readUML 2.5.110 of 23
01The component itself
Two forms are in circulation and both are correct, which is why the same system drawn in two tools can look like two notations.
| Element | Notation | What it means |
|---|---|---|
| Component (UML 2) | box, small plug icon top-right | An ordinary classifier box with the icon shrunk into the corner. Often carries the keyword «component» above the name. This is what current tools draw by default. |
| Component (UML 1) | box with two tabs on its left edge | The older form, where the icon is the shape. Still common in textbooks and in diagrams inherited from the 2000s; recognise it, do not draw it in new work. |
| Subsystem | «subsystem» on a component | A component large enough to have parts of its own. Only worth writing when the diagram shows what is inside it. |
| Artifact | «artifact», page with a folded corner | The physical file a component ships as - a jar, an image, a bundle. It belongs on a deployment diagram, not here, unless the point being made is about packaging. |
02Provided and required interfaces
Every component has two lists - what it provides and what it requires - and the whole notation is ways of writing those two lists down. There are two, and they are interchangeable.
| Element | Notation | What it means |
|---|---|---|
| Provided (explicit) | Dashed line, hollow triangle, pointing at the interface. The component implements this contract. | |
| Provided (lollipop) | a circle on a short stick | The same statement, drawn on the component's edge with the interface name beside the circle. Compact, and the reason most tools default to it. |
| Required (explicit) | Dashed line, open arrowhead, pointing at the interface. Usually labelled «use». The component needs somebody to satisfy this. | |
| Required (socket) | a half-cup on a short stick | The same statement in the compact form. A socket with nothing in it is an unmet dependency, which is a useful thing for a diagram to be able to show. |
Explicit or shorthand, never both on one diagram - a reader should not have to check whether two notations on the same picture mean two different things.
03Connectors, ports and delegation
Once components contain other components, two more marks appear. An assembly connectorwires one component's provided interface directly into another's required one - a ball sitting in a socket, which is the shorthand for the two arrows in the figure at the top of this article. A delegation connector runs from a port on the outer boundary to the part inside that honours it.
| Element | Notation | What it means |
|---|---|---|
| Assembly connector | a ball resting in a socket | One component satisfies another's requirement. Same statement as a realization plus a dependency through a shared interface, in a third of the space. |
| Port | small square on the boundary | One distinct point of interaction. Worth drawing when a component has genuinely separate surfaces - a public API and an admin API - and noise otherwise. |
| Delegation connector | From a port to an internal part: this external contract is handled by that piece. What makes a subsystem's inside checkable against its outside. | |
| Dependency between components | Legal, and almost always a defect: it says "depends somehow", which is the vagueness the diagram exists to remove. Name the interface instead. |
Nesting is the third way to say "inside", and the one this series draws: parts placed within the boundary of their owner, as above. It needs no extra symbol and it survives a reader who has never seen a delegation connector, which is most readers.
04The stereotypes worth writing
A stereotype in guillemets extends the meaning of a box, and the temptation is to invent a vocabulary. Four earn their place, because each one changes what a reader should do about the box:
«subsystem»- this has parts of its own, and they may be on another diagram.«service»- this is deployed and reached over a network, so its interface is a wire contract and versioning it is somebody's job.«library»- this is linked in, not called across a boundary, so a change to it is a rebuild rather than a deployment.«external»- somebody else owns this, so its interface is a constraint rather than a decision.
Anything past those four is usually a profile in disguise. If a team really does need a formal vocabulary of its own - marked elements, constrained elements, tool-enforced rules - that is what a UML profile is for, and writing it down properly is cheaper than a convention half the team follows.
05Where tools disagree
Three differences account for most of the confusion when a diagram moves between tools, and none of them changes the meaning:
- Icon or keyword. Some tools draw the plug icon, some write
«component», some do both. All three are the same UML 2 component. - Lollipops by default. Most drawing tools attach ball-and-socket to the component edge; modelling tools that hold a repository tend to draw the interface as its own element, because it is one.
- Ports drawn where there are none. Some tools put a small square at every interface attachment point. If the diagram never distinguishes two surfaces on one component, those squares carry no information.
In one line each
- 01Box with a plug icon in the corner: the UML 2 component. Two tabs on the left edge: the UML 1 form.
- 02Realization - dashed, hollow triangle - points from the implementer at the contract.
- 03Dependency - dashed, open head - points from the needer at the contract.
- 04Lollipop is provided, socket is required, ball-in-socket is an assembly of the two.
- 05A port is a distinct interaction point; a delegation connector routes it to a part inside.
- 06An arrow between two components with no interface names nothing - that is the defect to look for.
The symbols in use on real systems are in the five worked examples, and the order to put them down in is in how to draw a component diagram.
06Common questions
What does the lollipop symbol mean in UML?
A lollipop - a small circle on a short stick - is a provided interface: the component it is attached to implements that contract. It is the compact form of a realization arrow pointing at an interface box, and the two mean exactly the same thing, so a diagram should use one form or the other rather than both.
Can I mix lollipops and interface boxes on one diagram?
You can, and it costs the reader for no gain. Both forms state exactly the same thing, so two notations on one picture leave somebody checking whether the difference is meaningful. Pick the compact ball-and-socket form when space is short, and explicit interface boxes when the arrows themselves are what the diagram is discussing.
What does a dashed arrow with a hollow triangle mean?
That is a realization, and on a component diagram it always points from the implementer to the contract. The component at the tail promises to satisfy the interface at the head. A dashed arrow with a plain open head is the opposite side of the same relationship: a dependency, meaning the component needs that contract from somebody else.
Is the component symbol different in UML 1 and UML 2?
Yes, and both are still drawn. UML 1 replaced the box outright with a rectangle carrying two smaller rectangles on its left edge. UML 2 uses an ordinary classifier box with that icon shrunk into the top-right corner, optionally with the keyword «component» above the name, which is the form current tools default to.
Related reading