UML component diagram template
Four components and three interfaces, each one provided by exactly one component and required by another - which is the only arrangement a component diagram exists to show.
Notation: UML 2.5.1Diagram: Component diagram
Open this template in Archyno
It opens as an editable model, not an image. Change it in the browser, then export to PNG, SVG, Mermaid, XMI, or a Sparx .qea file.
Open this templateWhat is on this diagram
- Storefront
- A consumer. It requires an interface and provides none - the edge of the system.
- OrderIntake
- The contract between the storefront and the service. Rename this before you rename either component.
- Order service
- The component that provides one interface and requires two. Most of your components look like this.
- OrderRepository
- Persistence as a contract, so the store behind it can be replaced without touching the service.
- Order store
- The realizing component. The «database» stereotype says what kind of thing it is.
- Payment adapter
- The third party, wrapped. The interface is yours even when the vendor behind it is not.
How to make it yours
- Rename the interfaces first. A component diagram is a diagram about contracts, and the component names are the part everyone already agrees on.
- Check that every interface is provided by exactly one component. Two providers is a diagram of an argument that has not been resolved.
- Draw the required end as a dependency and the provided end as a realization. Getting these the wrong way round reverses the direction of the whole design.
- Never connect two components directly. If there is no interface between them, the diagram is a box-and-line sketch and the notation is doing nothing.
- Add a stereotype only where the kind of the component changes how it is deployed - «database», «service», «device». Stereotyping everything says nothing.
- Leave the third-party adapter in place. The interface you own in front of a vendor you do not is the whole reason to draw this diagram.
Common questions
What is the difference between a provided and a required interface?
A provided interface is one the component implements - anyone may call it. A required interface is one the component needs somebody else to implement before it can work. In this template the Order service provides OrderIntake and requires OrderRepository and PaymentGateway, so it is both a supplier and a consumer, which is what most real components are.
Should I use ball-and-socket notation instead?
Both are correct UML and they mean the same thing. Ball-and-socket is more compact and reads well when one interface joins exactly two components; the classifier form used here scales better, because a second consumer is one more dashed arrow rather than a redrawn connector. Use whichever your team already reads without asking.
Is a component diagram the same as a deployment diagram?
No. A component diagram says what the pieces of software are and how they depend on each other; a deployment diagram says which machine each piece runs on. They are commonly drawn together, and merging them into one picture is the usual reason neither is legible.
Read the notation
How to read and draw a UML component diagram: components, provided and required interfaces, ball-and-socket notation, ports, and how it differs from a class diagram.
A reference for every symbol on a UML component diagram: the component box, provided and required interfaces, ball and socket, assembly and delegation connectors, ports and stereotypes.
A step-by-step walkthrough: choose the parts, draw the boxes, name what each provides, add what each requires, then run the four checks that tell you the diagram is finished.
Five worked UML component diagram examples - a shared catalogue, ports and adapters, a legacy swap, a plugin architecture and a dependency cycle - with what each one is for.