UML Component Diagrams

A UML component diagram shows the units a software system is assembled from, the interfaces each unit provides, the interfaces it requires, and how those interfaces are wired together. UML 2.5.1 defines a component as a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

A component diagram describes a system in larger pieces than a class diagram: each component groups several classes into one unit that can be replaced on its own, and hardware does not appear. Architects use it to define boundaries before implementation starts. Teams that own separate services use it to list the operations one service calls on another.

What is a UML Component Diagram?

A component diagram is a structural diagram. It shows:

• Components: modular units whose internals are hidden and reachable only through their interfaces.
• Provided interfaces: implemented by the component. Other components call them.
• Required interfaces: called by the component but implemented elsewhere. The component cannot run until something supplies them.
• Ports: named connection points on a component boundary that group provided and required interfaces.
• Connectors: an assembly connector joins one component's required interface to another's provided interface. A delegation connector passes requests from the outer boundary to the part that handles them.
• Realizing classifiers and artifacts: the classes that implement the component's behavior, and the files it is packaged into. Both can be listed inside the box.

A component can be as abstract as a billing unit in a design, or as concrete as a service you deploy and version on its own.

Why Use Component Diagrams?

• Agree which operations two services provide to each other before either is written.
• Make dependency direction explicit, so a cycle between two components is easy to see.
• Decide which units can be versioned and released independently.

Core Components and Notation

Component

A component is drawn as a classifier rectangle with the keyword «component». A component icon may be placed in the right hand corner. When the icon is shown, the keyword may be hidden.

Provided Interface

A provided interface is a small circle on the end of a line from the component, labeled with the interface name. The symbol is called a lollipop or a ball. The component implements every operation that interface declares.

Required Interface

A required interface is a half circle on the end of a line from the component, labeled with the interface name. The symbol is called a socket. The component calls those operations but does not implement them, so something else has to supply them.

Assembly Connector

When one component requires an interface that another provides, draw the socket touching the ball. UML calls this an assembly connector.

Ball-and-socket only wires ports that carry exactly one interface. If a port carries several, or the parts have no ports, draw a plain connector line instead.

Port

A port is drawn as a small square on the component boundary, or inside it. The name is placed near the square, the type after a colon. Lollipops and sockets attach to the port rather than to the component body. A port can carry more than one interface. Instead of drawing a separate lollipop for each, draw one and list the names on it: IPlayback, IDownload. A port with several interfaces still cannot be wired with ball-and-socket, so its connections use plain lines.

Delegation Connector

A component can show the parts it is built from. A delegation connector is a line from a port on the component's own boundary to a port on one of those parts. Requests arriving from outside are handled by that part.

There is no special arrowhead or label. What makes the line a delegation is where it attaches: one end is on the component's own boundary. If both ends attach to inner parts, the same line is an assembly connector.

Ball and socket symbols carry only the interface name. When operation signatures matter, draw the interface as a classifier rectangle with the keyword «interface» and connect it with dependency arrows. A provided interface uses an InterfaceRealization: a dashed line with a hollow triangle arrowhead. A required interface uses a Usage dependency: a dashed line with an open arrowhead and the keyword «use».

Standard Stereotypes for Components

From the UML 2.5.1 standard profile:

Stereotype	Applies to	Meaning
«Subsystem»	Component	A unit of hierarchical decomposition for large systems
«Service»	Component	A stateless, functional component
«Specification»	Classifier	A component with interfaces only, and no realizing classifiers
«Realization»	Classifier	A component whose realizing classifiers implement a separate «Specification»

Practical Example: Video Streaming Platform

The diagram below models the main components of a video streaming platform.

The relationships it shows:

1. WebClient requires IStreamCatalog and IPlayback. It provides nothing, so it carries only sockets.
2. CatalogService provides IStreamCatalog, which returns title listings and search results.
3. CatalogService requires IMediaMetadata from MediaStore to read durations, resolutions, and cover art.
4. PlaybackService provides IPlayback, and requires ILicense from LicenseService to check playback rights before a stream starts.
5. PlaybackService also requires IMediaStorage from MediaStore to read video segments.
6. MediaStore provides two separate interfaces, so CatalogService gets metadata access without the ability to read video segments.

LicenseService and MediaStore require nothing, so each can be tested alone. PlaybackService needs two test doubles.

Best Practices

• Name the interface, not the connection: ILicense states what crosses the boundary. A line labeled "calls license service" does not.
• Split interfaces by responsibility: one interface per concern lets a consumer depend on only the part it uses, as MediaStore does above.
• Add ports when a component has many interfaces: named groups keep the boundary readable.
• Keep internal structure on its own diagram: the external view answers what a component needs. Draw parts and delegation connectors separately.
• Match component boundaries to units you can release: if two components always ship together, the boundary between them is not doing any work.

Conclusion

A component diagram shows the pieces of a system and what each one needs from the others. Two teams can use it to settle an interface list before either writes code. It also shows which pieces are independent enough to release on their own.

It records no timing. The diagram states that PlaybackService requires ILicense, but not whether the license check runs before the first byte of video or halfway through. Order belongs on a sequence diagram. For where each component actually runs, use a deployment diagram.