Chapter 6: Architectural Design
🎯 Learning Objectives
By the end of this study session, you’ll be able to:
- Explain why explicit architectural design is crucial for software projects
- Identify and apply the three main system organization models (Repository, Client-Server, Layered)
- Choose between object-oriented and function-oriented modular decomposition strategies
- Implement appropriate control models for different system types (centralized vs. event-based)
- Analyze system requirements to select the most suitable architectural approach
🌟 The Big Picture
Architectural design is your blueprint for building complex software systems - it’s like creating the floor plan before constructing a house. You’ll learn three core activities that transform requirements into a structured, manageable system: organizing the overall structure, breaking it into manageable modules, and establishing how everything communicates and controls each other.
📚 Core Concepts
Why Architectural Design Matters
Think of architecture as your project’s foundation. Here’s why you absolutely need it:
Key Benefits:
- Stakeholder Communication - Provides a high-level view everyone can understand
- System Analysis - Lets you verify if your design meets requirements before coding
- Large-scale Reuse - Creates reusable architectural patterns for future projects
- Negotiation Tool - Serves as a concrete discussion point with clients and team members
- Complexity Management - Breaks overwhelming systems into manageable pieces
1. System Organization/Structuring
System organization is about dividing your software into independent sub-systems that work together. Each sub-system handles specific responsibilities and communicates through well-defined interfaces.
The Three Essential Organization Models:
i) Repository Model - The Central Database Approach
When to Use: Perfect for systems that need to share large amounts of data between multiple components.
How It Works:
- Central database stores all shared data
- Sub-systems access and modify data through the repository
- No direct communication between sub-systems
Visual Reference (Slide 27):
Project Repository (Central Hub)
↙ ↓ ↘
Design Code Program
Editor Gen. Editor
↖ ↓ ↗
Design Report Design
Analyzer Gen. Translator
Repository Model Analysis:
Advantages:
- Efficient sharing of large data volumes
- Centralized data management and security
- Sub-systems don’t worry about data production details
- Consistent data schema across the entire system
Disadvantages:
- All sub-systems must agree on one data model (can be limiting)
- Difficult to implement specific data management policies
- Hard to distribute across multiple locations
- Data structure changes are expensive and affect everything
ii) Client-Server Model - The Distributed Services Approach
The Distributed System Breakdown:
- Servers: Stand-alone components providing specific services (printing, data management, file storage)
- Clients: Components that request and use these services
- Network: Infrastructure allowing clients to access servers
Visual Reference (Slide 38):
Client1 Client2 Client3 Client4
\ | | /
\ | | /
Wide-bandwidth Network
/ | | \
/ | | \
Catalogue Video Picture Hypertext
Server Server Server Server
| | | |
Catalogue Film Digital Hypertext
Database Clips Photos Web
Client-Server Model Analysis:
Advantages:
- Straightforward data distribution across networks
- Cost-effective (can use cheaper hardware for clients)
- Easy to add new servers or upgrade existing ones
- Effective use of network resources
Disadvantages:
- Different servers may use incompatible data models
- Can lead to redundant management overhead
- No central registry for tracking available services
- Data sharing between servers can be inefficient
iii) Layered Model - The Abstract Machine Approach
The Layering Concept: Each layer provides services to the layer above it and uses services from the layer below. Think of it like a building - each floor supports the one above it.
Key Characteristics:
- Also called the “Abstract Machine Model”
- Supports incremental development (build layer by layer)
- Changes in one layer only affect adjacent layers
Visual Reference (Slide 45):
Configuration Management System Layer
↓
Object Management System Layer
↓
Database System Layer
↓
Operating System Layer
When to Use: Ideal for systems that can be naturally organized into hierarchical levels of abstraction.
2. Modular Decomposition
Once you’ve organized your system structure, you need to break sub-systems into individual modules - the actual components that contain your code.
Object-Oriented Decomposition Strategy
Approach: Identify real-world entities in your problem domain and model them as objects with data and behaviors.
Example - Invoice Processing System (Slide 51):
Customer Object Invoice Object Payment Object
- CustomerNo - InvoiceNo - InvoiceNo
- Name - Date - Date
- Address - Amount - Amount
- CreditPeriod - CustomerNo - CustomerNo
Methods: Receipt Object
- Issue() - InvoiceNo
- sendReminder() - Date
- acceptPayment() - Amount
- sendReceipt() - CustomerNo
When to Use: Best for systems where you can clearly identify entities that have both data and associated behaviors.
Function-Oriented Decomposition Strategy
Approach: Break the system down based on the functions or processes it needs to perform.
Example - Invoice Processing System (Slide 52):
Read Issued → Identify → Issue → Find Payments → Issue Payment
Invoices Payments Receipts Due Reminders
↓ ↓ ↓ ↓ ↓
Invoices → Payments → Receipts → Reminders
When to Use: Ideal for systems focused on data transformation and processing workflows.
3. Control Modeling
Control modeling determines how your sub-systems coordinate and communicate. You’re essentially designing the “nervous system” of your software.
Two Main Control Approaches:
i) Centralized Control - The Boss System
Core Concept: One sub-system takes charge and directs all others.
a) Call-Return Model (Slide 64)
Main Program
├── Routine 1
│ ├── Routine 1.1
│ └── Routine 1.2
├── Routine 2
└── Routine 3
├── Routine 3.1
└── Routine 3.2
Best For: Sequential systems where operations happen in a predictable order.
b) Manager Model (Slide 67)
System Controller
↓
┌────┬────┼────┬────┐
Sensor Actuator Fault User Computation
Processes Processes Handler Interface Processes
Best For: Concurrent systems where multiple processes need coordination but can run simultaneously.
ii) Event-Based Control - The Reactive System
Core Concept: Sub-systems respond to events from the environment or other systems.
a) Broadcast Model (Slide 71)
Event & Message Handler
↓
Broadcasts Event
┌────┼────┼────┐
Subsystem1 Subsystem2 Subsystem3 Subsystem4
(Responds (Ignores (Responds (Ignores
if relevant) event) if relevant) event)
Best For: Distributed systems where multiple components might need to respond to the same event.
b) Interrupt-Driven Model
Best For: Real-time systems that must respond immediately to external interrupts or time-critical events.
🔄 Complete Architecture Framework Summary
The Three-Step Process:
- System Organization - Choose Repository, Client-Server, or Layered model based on your data sharing and distribution needs
- Modular Decomposition - Select Object-Oriented for entity-rich domains or Function-Oriented for process-heavy systems
- Control Modeling - Implement Centralized control for predictable systems or Event-Based control for reactive systems
Decision Matrix:
- Large shared datasets → Repository Model
- Distributed services → Client-Server Model
- Hierarchical abstractions → Layered Model
- Clear entities with behaviors → Object-Oriented Decomposition
- Process workflows → Function-Oriented Decomposition
- Sequential/managed execution → Centralized Control
- Reactive/distributed responses → Event-Based Control