Component Diagram

A component diagram shows the organization and dependencies among software components—the modular, replaceable parts of a system that encapsulate their contents and expose behavior through well-defined interfaces. While class diagrams model fine-grained code structure (individual classes and their relationships), component diagrams operate at a higher abstraction level, showing how a system is decomposed into major building blocks and how those blocks interact. They answer the architectural question: "What are the major pieces of this system, and how do they connect?"

Core Concepts

Component: A modular unit of software that encapsulates its implementation behind interfaces. A component can be a library, a service, a module, a package, or any self-contained unit with clearly defined boundaries. Components are represented as rectangles with the component stereotype icon (a small rectangle with two protruding tabs) or the «component» keyword.

Interface: The contract through which a component communicates with the outside world. Components have two types of interfaces:

• Provided Interface (lollipop ─○): Services the component offers to others
• Required Interface (socket ─◗): Services the component needs from others

Dependency: A relationship indicating that one component requires another to function. Shown as a dashed arrow from the dependent component to the component it depends on.

Port: A specific interaction point on a component where interfaces are exposed. A component might have multiple ports for different types of communication (an HTTP port for client requests, a database port for data access, a messaging port for async events).

Notation

Real-World Example: E-Commerce System Components

This diagram reveals:

• The system is decomposed into distinct services (microservices architecture)
• The Web Frontend communicates only through the API Gateway (no direct service access)
• Each business service (Product, Order, Payment) owns its own data store
• The Auth Service is accessed by the API Gateway for request authentication
• Services are independently deployable components

Interface-Based Design Example

This clearly shows what the Product Catalog component offers to other components and what it needs from them. Any component that provides ICacheService (Redis, Memcached, in-memory cache) can be plugged in without modifying the Product Catalog.

When to Use Component Diagrams

Architecture documentation: Communicating system structure to stakeholders who do not need to see individual classes but need to understand major building blocks.

Service boundaries: Defining microservice boundaries and their interfaces during system decomposition.

Dependency management: Identifying and managing dependencies between components to prevent circular dependencies and excessive coupling.

Team organization: Mapping components to development teams (each team owns specific components and their interfaces).

Build and deployment planning: Understanding which components need to be built, tested, and deployed together or independently.

Technology evaluation: Showing which components could be replaced by third-party solutions (any component satisfying the required interface can substitute).

Component Diagram vs. Other Diagrams

Best Practices

Define clear interfaces for every component—avoid exposing internal details. Show the most architecturally significant components; omit utility libraries and infrastructure components unless they are architecturally important. Use nesting to show composition (a composite component containing sub-components). Label dependencies with the nature of the dependency (uses, calls, imports). Keep the diagram at a consistent level of abstraction—do not mix high-level services with low-level libraries in the same diagram.

Component Design Principles

Good components exhibit: High cohesion (everything within a component is related to its core responsibility), Low coupling (minimal dependencies between components), Clear interfaces (well-defined contracts that hide implementation details), Replaceability (any implementation satisfying the interface can substitute), and Independent deployability (especially important in microservices architectures where each component should be deployable without coordinating with others).