Symboles du diagramme de composants
Toutes les marques qu'un diagramme de composants UML peut porter, et ce à quoi chacune vous engage : l'icône de prise, la sucette et la cavité, les connecteurs d'assemblage et de délégation, les ports et les quatre stéréotypes qui valent la peine.
7 min de lectureUML 2.5.110 sur 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.
06Questions fréquentes
Que signifie le symbole sucette en UML ?
Une sucette - un petit cercle au bout d'une tige - est une interface fournie : le composant auquel elle est accrochée implémente ce contrat. C'est la forme compacte d'une flèche de réalisation vers une boîte d'interface ; les deux disent la même chose, donc un diagramme choisit l'une ou l'autre.
Peut-on mêler sucettes et boîtes d'interface sur un diagramme ?
On peut, et cela coûte au lecteur sans rien apporter. Les deux formes disent exactement la même chose : deux notations sur une même image obligent à vérifier si l'écart signifie quelque chose. Prenez la forme compacte rotule et cavité quand la place manque, et des boîtes explicites quand ce sont les flèches que l'on discute.
Que signifie une flèche pointillée à triangle creux ?
C'est une réalisation, et sur un diagramme de composants elle va toujours de l'implémentation vers le contrat. Le composant à la base promet de satisfaire l'interface à la pointe. Une flèche pointillée à tête ouverte est l'autre versant de la même relation : une dépendance, le composant a besoin de ce contrat.
Le symbole du composant diffère-t-il entre UML 1 et UML 2 ?
Oui, et les deux se rencontrent encore. UML 1 remplaçait la boîte par un rectangle portant deux rectangles plus petits sur son bord gauche. UML 2 utilise une boîte de classificateur ordinaire avec cette icône réduite dans le coin supérieur droit, éventuellement avec le mot-clé «component» au-dessus du nom.
À lire aussi