Phase 4 of 5  ·  Modern Engineering
Week 15 / 20   ·   Ch 16

Component-Based
Engineering

"Lego-style software — what component-based engineering really means"

📚 Ch 16 — Component-Based SE🔌 Provides/Requires Interfaces🏗️ CBD Process⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

🔌

What is a Component?

A deployable, independent unit of software with defined 'provides' (services) and 'requires' (dependencies) interfaces.

When to Use

Any reusable unit of software that can be used without knowing its internals.

Real-World Example

React components: Button, Modal, DataTable — each has a defined interface (props) and can be reused anywhere.

✓ Advantages

  • Encapsulation
  • Independently deployable
  • Reusable across projects

⚠ Watch Out

  • Interface design is hard
  • Versioning complexity
  • Discovery problem
Component Interface: [Provides: UserList, UserCreate, UserDelete] [Requires: Database, AuthService] → Black box: internals hidden → Only interface matters
🤝

Provides and Requires Interfaces

A component publishes what it offers (provides) and declares what it needs (requires).

When to Use

When designing reusable components — interfaces must be specified before implementation.

Real-World Example

npm package: exports = provides interface. peerDependencies = requires interface.

✓ Advantages

  • Explicit contracts
  • Enables independent development
  • Testable in isolation

⚠ Watch Out

  • Interface changes break consumers
  • Requires interface governance
PaymentComponent: Provides: processPayment(amount, card) refundPayment(transactionId) Requires: PaymentGateway Logger Database
🏗️

Component-Based Development Process

Requirements → Identify candidate components → Search repository → Adapt → Integrate → Validate.

When to Use

Building systems primarily from reusable components.

Real-World Example

Building a SaaS dashboard: find auth component, find data grid component, find charting component, integrate, customize.

✓ Advantages

  • Faster development
  • Higher quality through reuse
  • Modular maintenance

⚠ Watch Out

  • Requirements may need adjustment
  • Integration complexity
  • Repository/discovery challenge
Requirements ↓ Identify candidate components ↓ Search component repository ↓ Adapt found components ↓ Integrate components ↓ System testing

📋Quick Reference

θ Ch 16 Cheat Sheet — Component-Based Engineering
Component
Independent, deployable unit with defined interface. Black box — internals hidden.
Provides Interface
Services the component offers. Its API.
Requires Interface
External services the component depends on. Its dependencies.
CBSE
Component-Based Software Engineering. Assemble systems from components.
CBD Process
Requirements → Find components → Adapt → Integrate → Validate.
Interface Design
Design interfaces before implementation. Changes to interfaces break consumers.
θ
Sommerville's Key Points — Ch 16
Author's own summary from the end of the chapter.
  • 1Components: independent, deployable software units with defined interfaces.
  • 2Provides interface: services offered. Requires interface: external dependencies needed.
  • 3Component model: specification of component interfaces, usage, and composition.
  • 4CBD process: identify, find, adapt, integrate, validate — assemble from components.
  • 5Interface design is critical — it's a contract between component and consumer.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
What is the difference between a component and a class?
A class is an internal implementation construct. A component is a deployable unit that may contain many classes. Components have explicit interfaces (provides/requires) and are independently deployable. You can replace a component without touching others, as long as the interface is honored.
Q2
Apply
Why is interface design harder than implementation?
Because interfaces are contracts — changing them breaks every consumer. Implementation can change freely (as long as behavior is the same). Interface design requires thinking about ALL possible consumers, future use cases, and evolution. Bad interface = permanent technical debt.
Q3
Analyze
How do microservices relate to component-based engineering?
Microservices are components — independently deployable units with defined interfaces (REST/gRPC APIs). They implement the provides/requires interface model at the service level. The key difference: microservices run as separate processes and communicate over networks, while traditional components may be in the same process.
Up Next → Week 16
Distributed Systems
CAP theorem in 30 seconds — and the 8 fallacies every dev must know
Continue → Week 16