Component Diagram
Use when asked to model a system's software architecture as interacting components — dependency, association, aggregation, composition between components — as distinct from a deployment diagram's runtime hardware/node view (see deployment-diagram), which shows where components run rather than how they relate to each other.
A component diagram is a UML structural diagram showing the organization and relationships among a system's software components — commonly used to model software architecture and a system's interdependencies with external systems or modules, at a coarser grain than a Class Diagram but more implementation-oriented than a Package Diagram.
Elements
- Components — drawn as rectangles labeled with the component's name; a component represents a modular, replaceable part of the system providing specific functionality (a service, a library, a subsystem).
- Dependency — one component needs another to function; drawn as a dashed arrow pointing from the dependent component toward the one it depends on.
- Association — two components are related through data or control flow; drawn as a solid connecting line.
- Aggregation — one component contains or is composed of others, but those parts could exist independently; drawn with an open diamond arrowhead (same underlying semantics as Object Diagram's aggregation, applied at the component level).
- Composition — a stronger containment where the contained components can't exist without the containing one; drawn with a filled diamond arrowhead.
When a component diagram is the right choice
Best for showing how major software parts of a system relate and depend on each other — which service calls which, which module a library dependency flows through — at a level useful for architecture discussions, distinct from Deployment Diagram's concern with where those components physically run.
Drawing one
See PlantUML Diagram for the @startuml component-diagram syntax (component "Name", interface, connecting arrows) to generate one from version-controlled text.
Common pitfalls
- Confusing a component diagram with a deployment diagram — a component diagram shows logical software relationships; a Deployment Diagram shows physical runtime placement on actual hardware nodes. A system can have components that are logically related but deployed on entirely separate machines.
- Dependency arrows drawn in the wrong direction — a dependency points from the dependent component toward what it depends on; reversing this misrepresents which component would actually break if the other changed.
- Too fine-grained a component breakdown — showing every class as its own "component" collapses this diagram type into a Class Diagram in disguise, losing the architectural-overview value a component diagram is meant to provide.
Learn more
- PlantUML Diagram for the text-based syntax to draw this diagram type.
- Deployment Diagram for the physical/runtime counterpart showing where components actually run.
- Package Diagram for an even coarser-grained organizational view.