Lesson 8	UML Component view
Objective	The objective of this lesson is to Define the Purpose and Function of the Component View

Component View: Purpose, Function, and Modern Module Architecture

The component view addresses software organization concerns distinct from logical domain modeling—how do we partition implementations into deployable units, manage dependencies between modules, enable parallel team development, support incremental integration, and facilitate component reuse across projects? While logical view models conceptual design through classes and interactions, component view specifies physical software structure: executables, libraries, packages, services, and their dependency relationships. Understanding the component view's purpose and function requires examining both its role in traditional component-based development and how modern architectures evolved component concepts toward microservices, npm packages, Docker containers, and serverless functions while retaining the fundamental principle—organizing software into independently developable, deployable, and replaceable modules with well-defined interfaces. Contemporary practice applies component diagrams selectively where module dependency visualization provides value—detecting circular dependencies preventing clean architecture, documenting legacy system structure for modernization planning, specifying microservice boundaries for distributed systems—while using C4 Model Container diagrams, dependency graphs generated from build tools, and architecture decision records for living documentation synchronized with actual system structure rather than static UML diagrams diverging from implementation reality.

Purpose of the Component View

The component view's purpose centers on modeling physical software organization—how source code, binaries, libraries, and executables arrange into deployable artifacts. This physical perspective contrasts with logical view's conceptual abstraction. A single logical class might compile into multiple physical components (header files, implementation files, object files). Conversely, one component might contain many logical classes. The component view answers questions logical view cannot: What JAR files does our application require? Which DLLs must deploy with the executable? What npm packages does this service depend on? Can we build module A before module B completes? These pragmatic concerns matter for build systems, configuration management, deployment automation, and team coordination.

Components provide reusability mechanism at implementation level. While logical view models domain concepts for potential reuse (Customer class useful across applications), component view packages implementations for actual reuse. A payment processing component encapsulates credit card validation, fraud detection, and transaction recording as deployable unit usable across e-commerce, subscription billing, and point-of-sale systems. Component interfaces specify what functionality the component provides without exposing internal implementation—developers use components knowing purpose and contracts without understanding internals. This black-box reusability enables composition-based development where teams assemble systems from existing components rather than coding everything from scratch.

Function: What Component Diagrams Model

Component diagrams represent various software artifact types reflecting different implementation technologies and organizational granularities. Subsystems group related functionality into major architectural divisions—in banking system: customer management subsystem, account processing subsystem, reporting subsystem. Libraries package reusable code—utility libraries, domain-specific frameworks, third-party dependencies. Executables represent runnable programs—desktop applications, command-line tools, batch processors. Web services encapsulate remotely accessible functionality—REST APIs, SOAP services, GraphQL endpoints. Microservices represent independently deployable bounded contexts in distributed architecture. Packages organize code namespaces—Java packages, Python modules, C++ namespaces, npm packages. Database schemas can model as components when representing packaged database functionality. The flexibility enabling modeling any "chunk of software" as component provides adaptation to diverse architectural styles.

Component diagrams' critical function models dependencies—which components use which other components. Dashed arrows show dependency direction: if Component A depends on Component B, arrow points from A to B (A uses B's interfaces). This dependency visualization serves multiple purposes. Architecture validation detects circular dependencies violating layered architecture—if presentation layer depends on persistence layer, and persistence depends on domain layer, but domain depends on presentation, circular dependency prevents clean modular compilation. Build ordering determines compilation sequence—components with no dependencies build first, dependents build after dependencies complete. Impact analysis identifies change ripple effects—modifying Component B potentially affects all components depending on it. Team coordination shows development dependencies—teams building Component A need Component B's interfaces stabilized before integration.

Components expose provided interfaces (functionality component offers) and required interfaces (functionality component needs). Provided interfaces (ball notation in UML) specify operations component implements—OrderService provides placeOrder(), cancelOrder(), getOrderStatus(). Required interfaces (socket notation) specify operations component consumes—OrderService requires PaymentGateway, InventoryService, NotificationService. This interface-based modeling enables substitutability—any component implementing required interface can replace another, supporting dependency inversion principle where high-level components depend on abstractions (interfaces) rather than concrete implementations.

// Component Diagram: E-Commerce Microservices

┌─────────────────┐
│   Web Frontend  │
│   (React SPA)   │
└────────┬────────┘
         │ requires
         ├──────────────┐
         │              │
         ▼              ▼
┌─────────────┐  ┌──────────────┐
│ Order API   │  │ Product API  │
│ (Node.js)   │  │ (Java)       │
└─────┬───────┘  └──────────────┘
      │ requires
      ├───────────┬─────────────┐
      │           │             │
      ▼           ▼             ▼
┌──────────┐ ┌─────────┐ ┌────────────┐
│ Payment  │ │Inventory│ │ Email      │
│ Service  │ │ Service │ │ Service    │
│ (Python) │ │ (Go)    │ │ (Node.js)  │
└──────────┘ └─────────┘ └────────────┘

// Dependencies show:
// - Frontend depends on two APIs
// - Order API depends on three services
// - Each service independently deployable
// - Technology heterogeneity supported

Components vs Packages: Critical Distinction

Components differ from packages despite superficial similarity. Packages provide namespace organization grouping related classes—Java's `java.util`, `java.io`, Python's standard library packages, C++ namespaces. Packages offer logical grouping primarily for developer convenience and name collision avoidance. Components represent physical deployment units with explicit interfaces and versioning. A Java JAR file is component—it deploys as unit, has version number, declares dependencies via Maven/Gradle, provides explicit API through exported classes. The `java.io` package isn't component—it's logical grouping within larger component (Java runtime). This distinction matters during deployment: components version, package, and distribute independently; packages exist only within containing component.

The JDK illustrates this distinction. The `java.lang` and `java.io` packages group related classes logically but don't constitute separate components—both exist within single `rt.jar` component (historically) or modules like `java.base` (Java 9+ module system). Conversely, Apache Commons libraries (`commons-lang3`, `commons-io`) are components—separately versioned, independently deployable JARs with explicit dependency declarations. Applications depend on Commons components, not individual packages within them. Modern Java modules (JPMS) blur this distinction by providing language-level component boundaries with explicit dependencies, demonstrating evolution toward treating packages as first-class components.

Component-Based Development Goals

Component view supports black-box reuse—using software through interfaces without understanding implementation. Traditional code reuse often meant white-box reuse—copying source code, understanding internals, modifying to fit needs. This approach scaled poorly—every reuse instance required understanding and potentially modifying implementation. Component-based development inverts this: well-designed components provide stable interfaces hiding implementation complexity. Payment processing component exposes `processPayment(amount, cardNumber, cvv)` without revealing fraud detection algorithms, encryption mechanisms, or gateway integration protocols. Developers use component knowing interface contract, enabling productivity through composition rather than comprehension.

Components enable incremental development and integration. Rather than building monolithic systems where nothing works until everything completes, component architecture allows building and testing components incrementally. Core components develop first, dependent components integrate progressively. Each component proves functionality independently through unit testing before system integration. Mock components substitute for unavailable dependencies during development—OrderService tests using mock PaymentGateway until actual payment component completes. This incremental approach reduces integration risk by validating component interfaces continuously rather than discovering incompatibilities during big-bang integration.

Component boundaries enable parallel team development. Different teams own different components with clearly defined interfaces. Interface contracts establish development contracts—once interfaces stabilize, teams develop component internals independently without continuous coordination. Payment team implements payment processing, inventory team manages stock levels, notification team handles messaging—all working simultaneously against agreed interfaces. This parallel development accelerates delivery compared to sequential development where teams wait for others to complete before starting. Clear component ownership also improves code quality through team accountability for component reliability and performance.

Modern Evolution: From Components to Microservices

Microservices architecture represents component view's natural evolution toward distributed systems. Where traditional components deployed within single process (DLLs, JARs loaded into application), microservices deploy as independent processes communicating via network protocols. Each microservice embodies component principles: encapsulates specific business capability, exposes well-defined API (REST, gRPC, GraphQL), hides internal implementation, versions independently, deploys separately. The shift from in-process to inter-process components introduces new concerns—network latency, partial failures, distributed data consistency—but preserves fundamental component concept: modular software with explicit interfaces and managed dependencies.

Docker containers provide modern component packaging. A container image encapsulates application code, runtime dependencies, configuration, and execution environment as immutable artifact. Container registries (Docker Hub, ECR, GCR) function as component repositories. Container orchestration (Kubernetes, Docker Swarm) manages component deployment, scaling, and lifecycle. Containers realize component-based development vision more fully than traditional DLLs or JARs—truly portable across environments, versioned through tags, composable via orchestration, replaceable through blue-green deployment. Component diagrams modeling containerized microservices show service boundaries, inter-service dependencies, and deployment topology.

// Modern Component: Containerized Microservice

// Dockerfile (Component Package Definition)
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

// package.json (Interface Declaration)
{
  "name": "order-service",
  "version": "2.3.1",
  "dependencies": {
    "payment-client": "^1.5.0",
    "inventory-client": "^2.1.0",
    "express": "^4.18.0"
  }
}

// Kubernetes Deployment (Component Deployment)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: order-service
        image: company/order-service:2.3.1
        ports:
        - containerPort: 3000

// Modern components are:
// - Fully self-contained (runtime included)
// - Version tagged (2.3.1)
// - Dependencies explicit (payment-client, inventory-client)
// - Independently deployable (Kubernetes manages)

What Modern Practice Replaced

The C4 Model's Container diagram provides modern alternative to UML component diagrams. Containers (C4's term, distinct from Docker containers though conceptually similar) represent separately deployable/executable units: web applications, mobile apps, databases, file systems, microservices. C4 Container diagrams use simple boxes and arrows rather than UML notation, showing technology stack explicitly (React, Spring Boot, PostgreSQL) unlike UML's technology-neutral abstraction. C4 prescribes what Container level should document and who consumes it—software architects and senior developers—providing methodology guidance UML component view lacks. Teams find C4 Container diagrams more accessible to non-UML experts while conveying equivalent architectural information.

Automated dependency visualization tools generate component-level architecture diagrams from build configurations rather than manual modeling. Maven dependency plugin visualizes Java dependencies from `pom.xml`. npm's dependency tree shows JavaScript package dependencies. Go's module graph displays Go module relationships. These generated diagrams guarantee accuracy—they reflect actual dependencies declared in build files rather than potentially outdated manual UML diagrams. Continuous integration pipelines regenerate dependency graphs on each build, creating living documentation synchronized with codebase. This automation addresses documentation drift that plagued static component diagrams maintained separately from code.

Modern module bundlers and package managers (webpack, Rollup, npm, pip, Maven, Gradle) provide explicit component dependency management superseding informal component organization. Package manifests (`package.json`, `requirements.txt`, `pom.xml`) declare component dependencies with version constraints. Lock files (`package-lock.json`, `Pipfile.lock`, Maven dependency tree) pin exact dependency versions ensuring reproducible builds. These tools automatically resolve transitive dependencies, detect version conflicts, and fetch required components from registries. The formalism component view advocated through diagrams now exists in executable form through package management tooling.

Where Component View Remains Valuable

Component diagrams excel at detecting circular dependencies preventing clean layered architecture. Drawing components and dependencies visually reveals cycles invisible in code. If Presentation layer depends on Business layer, Business depends on Data Access layer, but Data Access depends on Presentation (for DTOs or interfaces), circular dependency emerges clearly in diagram. Automated tools (JDepend, NDepend, dependency-cruiser) detect cycles programmatically, but component diagrams communicate architectural violations to teams more effectively than console output. Architecture reviews use component diagrams discussing dependency direction, identifying violations, and planning refactoring to eliminate cycles.

Legacy system documentation benefits from reverse-engineered component diagrams showing existing system structure before modernization. Tools analyze deployed artifacts (JARs, DLLs, executables), extract dependencies, and generate component diagrams mapping current architecture. These diagrams inform modernization strategies—which components migrate to microservices? which consolidate as redundant? which retire as obsolete? The visual architecture map enables stakeholder discussions about migration priorities, incremental modernization paths, and risk assessment that raw dependency data cannot facilitate. Component diagrams become before/after artifacts documenting transformation from monolith to microservices.

egulatory documentation requires formal component architecture diagrams demonstrating modular design, separation of concerns, and controlled dependencies. Medical device software (FDA 62304), automotive systems (ISO 26262), and aerospace applications (DO-178C) mandate architecture documentation with traceability from requirements through design to implementation. Component diagrams showing safety-critical components isolated from non-critical components, security boundaries enforced through component interfaces, and audit logging components receiving data from all business components satisfy regulatory requirements for systematic architecture. The formalism automated tools lack becomes valuable for compliance demonstration.

Modern Tooling for Component Documentation

PlantUML supports component diagrams through text syntax enabling version control and automated generation. Components, interfaces, and dependencies expressible concisely compile to images during build. This diagrams-as-code approach integrates component documentation into development workflow—diagrams version controlled with code, updated through pull requests, generated in CI/CD pipelines.

// PlantUML: Component Diagram as Code

@startuml
package "E-Commerce System" {
  component [Web Frontend] as web
  component [Order Service] as order

  component [Payment Service] as payment
  component [Inventory Service] as inventory
  
  interface "Order API" as orderAPI
  interface "Payment API" as payAPI
  interface "Inventory API" as invAPI
  
  web --> orderAPI
  orderAPI - order
  order --> payAPI
  order --> invAPI
  payAPI - payment
  invAPI - inventory
}

database "PostgreSQL" as db
order --> db
payment --> db
inventory --> db
@enduml

// Benefits:
// - Text format (Git tracks changes)
// - Generate PNG/SVG in build pipeline
// - No proprietary tools required

Structurizr applies architecture-as-code principles generating C4 diagrams (including Container level equivalent to component view) from code or DSL. Define architecture once, generate multiple views automatically. Changes to architecture definition immediately reflect in all diagrams. This approach eliminates manual diagram maintenance while providing formal architecture documentation synchronized with system design.

Draw.io and Lucidchart provide collaborative component diagram creation without UML formalism. Teams sketch component boundaries and dependencies using simple boxes and arrows, prioritizing communication over notation correctness. These informal diagrams serve architecture discussions, design reviews, and onboarding documentation where accessibility matters more than UML compliance. The tools' ubiquity means more developers create component-like diagrams in draw.io than formal UML component diagrams in enterprise modeling tools.

Integration with Agile and DevOps

Agile teams practice just-enough component modeling—creating diagrams where architectural communication value exceeds overhead. Architecture Decision Records (ADRs) document component structure decisions with rationale and consequences. Sprint planning might sketch component boundaries for features spanning multiple components. Technical debt reviews update component diagrams when accumulated dependencies violated intended architecture. This incremental, value-driven approach contrasts with upfront comprehensive component modeling waterfall methodologies prescribed.

Modern component view evolves continuously through continuous architecture practices. Initial component boundaries based on assumptions adjust when assumptions prove incorrect. Refactoring splits monolithic components into smaller focused components. Consolidation merges fine-grained components when boundaries proved unnecessarily complex. Architecture fitness functions (automated tests validating architectural characteristics) verify component dependencies match intended architecture, failing builds when violations introduced. This evolutionary approach matches DevOps culture embracing change rather than rigid upfront design.

Conclusion

The component view's purpose—organizing software into deployable modules with managed dependencies—remains fundamentally relevant in modern development. Its function—modeling physical artifacts, dependency relationships, and component interfaces—addresses genuine architectural needs. Contemporary practice evolved component concepts from in-process DLLs toward microservices, containers, and serverless functions while retaining core principle: modular software with explicit interfaces enabling independent development, deployment, and reuse. Modern alternatives—C4 Container diagrams, automated dependency graphs, package manager manifests, architecture-as-code—provide component documentation synchronized with implementation. Component diagrams serve selectively where visual architecture communication provides value: detecting circular dependencies, planning legacy modernization, satisfying regulatory requirements, facilitating architecture reviews. Understanding component view concepts enables informed architectural documentation decisions matching contemporary workflows. The fundamental insight—organize software into manageable modules with well-defined dependencies—persists across all approaches, from traditional UML component diagrams through modern microservices architecture, demonstrating enduring value even as specific techniques evolve from static documentation toward living architecture synchronized with code through automation and executable specifications.

In the next lesson, the deployment view for modeling physical architecture will be discussed.