While Class Diagrams model individual code structures and ER Diagrams model data schemas, real-world systems are often too large to look at on a class-by-class level. To manage complexity, systems are broken down into autonomous, reusable software modules called components. In Low-Level Design (LLD), developers use the Component Diagram to visualize how these high-level modules are organized and wired together.

Key ideas:

  • A Component Diagram provides a structural view of the physical artifacts, modules, and subsystems making up an application.

  • It emphasizes Component-Based Development (CBD), where software is constructed out of interchangeable parts.

  • It centers on service contracts (interfaces), explicitly defining how a module exposes capabilities or consumes external resources.

Core Components of a Component Diagram

Component Diagrams use a distinct set of visual notations to illustrate modular wiring boundaries:

  • Component (Stereotyped Box): Represented by a rectangle with a text stereotype <<component>> (and optionally a small icon featuring a block with two smaller rectangles protruding from its left side). It represents an encapsulated, replaceable structural unit of a system (e.g., BillingModule, AuthEngine).

  • Provided Interface (Lollipop Notation): A solid line ending in a full circle. This indicates an interface that the component implements and exposes publicly for other modules to call. It defines the services the component provides.

  • Required Interface (Socket Notation): A solid line ending in an open half-circle/cup shape. This indicates an external dependency that the component needs to do its job. It defines the services the component requires.

  • Port (Small Square): A small square box sitting directly on the boundary edge of a component. It acts as an explicit gateway, isolating the component's internal logic from the external interfaces.

Assembly Connectors: Wiring the Grid

When a component that requires a service is hooked up to a component that provides that exact service, their respective socket and lollipop symbols interlock perfectly. This structural layout link is called an Assembly Connector (often referred to as a "ball-and-socket" connection).

This visual interlocking is a representation of the Dependency Inversion Principle (the 'D' in SOLID). Instead of Component A coupling directly to the concrete internals of Component B, they meet at a clean, abstract interface boundary line.

Step-by-Step Modeling Example: Order Processor Architecture

Let us map out a component structure for an enterprise execution engine:

"An autonomous OrderProcessingComponent manages client transactions. To be used by external UI services, it exposes a public billing interface. Internally, to complete its task, it relies on two external dependencies: it must consume an inventory validation contract from an InventoryComponent, and it must hit an alert dispatch contract managed by a NotificationComponent."

Mapping Component Diagrams to Modular C++ Code

In a production-ready C++ architecture, components translate directly into isolated directories, namespaces, or compiled binary libraries (.so or .dll files). The wiring maps directly to abstract class pointers injected into constructors.

Here is how the Order Processor component diagram maps into a clean, modular structure:


System Assembly Demonstration


Common Pitfalls in Component Modeling

  • Mixing Classes with Components: Do not draw individual utility classes, helper methods, or micro-level entities like User, String, or MathUtils as full component shapes. A component is a macro-level subsystem container. If an item belongs inside a class file, it does not belong on a Component Diagram.

  • Drawing Direct Box-to-Box Arrows: Avoid drawing simple solid lines directly from Component A to Component B without any interface nodes between them. Doing so implies hard-coded, tight coupling. Always route connections through explicit lollipops and sockets to show proper interface boundaries.

  • Creating Overly Granular Boundaries: If you split your application into 50 different micro-components for a small, basic software tool, your architecture becomes over-engineered and difficult to manage. Group tightly coupled classes together inside a single component boundary.

Summary

  • Component Diagrams model the macro-level structural architecture and module boundaries of an application system.

  • Provided and required interface notations clearly define how an encapsulated block exposes services or consumes outside behaviors.

  • Designing around component blueprints ensures your software modules remain decoupled, easy to test, and ready to be swapped out without breaking downstream dependencies.