DPR Git Pages Home — Artifacts Index

Artifact/Template: Component Diagram

a.k.a. Logical View

A component diagram zooms into an element from an architecture overview/container diagram and shows its logical building blocks and their relations.

Motivation (Addressed Information Need)

The C4 model page on Wikipedia describes this artifact as: “decompose containers into interrelated components, and relate the components to other containers or other systems”.

Usage (Produced and Consumed When)

This diagram type is an intermediate artifact, supporting usage scenarios and problem-solving strategies such as:

• Divide and conquer, facilitate working in parallel.
• Estimate effort, organize and support buy-vs.-build-vs.-rent decision making.
• Support development with meaningful abstractions, explain difficult parts (design hot spots).
• Assist with change impact analysis.
• Identify bottlenecks, single points of failure and other quality risks.

Template Structure and Notation(s)

Component diagrams that illustrate the static structure often come in boxes-and-arrows form, with the semantics of these diagram elements explained in a legend or standardized. When using UML, for instance, stereotyped classes can be used as boxes.

The C4 Model for visualizing software architecture by Simon Brown introduces component models as its third C. It also features a “Dynamic diagram”.

Unified Modeling Language (UML) has a component diagram, but due to language and tool limitations stereotyped class diagrams might also be an adequate choice. The UML communication diagram (formerly known as a “UML collaboration diagram”) captures component dynamics; sequence diagrams are a valid choice for that purpose as well.

Example(s)

The following component diagram identifies a number of generic candidate components across logical layers (based on Figure 7 in “An architectural decision modeling framework for service oriented architecture design”):

Note that this diagram operates on a meta level; it might be part of a reference architecture, but does not part of a concrete solution architecture (the generic candidate component would have to be translated into domain-specific components for that).

Tools

Common choices include:

• Any drawing tool or whiteboards (both classic and software-supported)
• C4 tools such as Structurizr
• UML tools

Hints and Pitfalls to Avoid (Common Pitfalls)

• Do not confuse logical and physical model elements; this diagram shows the logical structure. The interactions between the components in selected usage scenarios should be specified as well (for instance, representative cases or particularly challenging design hot spots such as peak load processing and error handling).
• Decide for a leading decomposition type, for instance, functional/domain-driven versus technical. Apply decomposition criteria and strategies such as those in Service Cutter to identify candidate components.
• Do not create a single component for each and every class (in object-oriented programs), but group classes to achieve cohesion, which makes the design change-friendly. The “integrators” and “disintegrators” from “Software Architecture: The Hard Parts” can guide component distribution; options and tradeoffs regarding communication, coordination, and consistency come into play (@Ford:2021).
• Measure coupling and cohesion as the design and its implementation evolve. Consider architectural and interface refactoring to improve the design as desired qualities and their priorities come and go.
• Do not assume all components have to be implemented; buying products and renting cloud services are valid options as well.

Origins and Signs of Use

Component models and diagrams arguably are as old as the software architecture field (or even older), appearing under various names.

The Component Diagram is one of the four Cs in C4.

Layering and partitioning is featured in Scott Ambler’s publications, see for instance his online essay “Class Type Architecture: A Strategy for Layering Software Applications”.

Related Artifacts and Practices (incl. Alternatives)

Activities in DPR:

• SMART NFR Elicitation
• Architecture Modeling

Artifacts:

• Component Interaction Diagram (CID)
• Architecture Overview Diagram
• Deployment Diagram
• Implementation code

More Information

• Philippe Kruchten introduces the 4+1 model in “The 4+1 View Model of Architecture”.
• Sparx Systems provides a UML Tutorial.
• C4 has a Wikipedia page.
• arc42 includes a building block view and a runtime view.
• Gernot Starke explains how to create strong diagrams in “1×1 guter Architekturdiagramme” (in German).

Data Provenance

title: "Design Practice Repository (DPR): Component Diagram"
author: Olaf Zimmermann (ZIO)
date: "09, 04, 2024"
copyright: Olaf Zimmermann, 2024 (unless noted otherwise). All rights reserved.
license: Creative Commons Attribution 4.0 International License