🏠 Home

Week 6

Hierarchy Architecture

Chapter 7

Instructor: Baber Sheikh (Visiting Faculty)

Agenda

7. Hierarchy architecture
7.1. Introduction of hierarchical style
7.2. Main and sub routine architectural style
7.2.1. Benefits & limitations
7.3. Master-Slave architectural style
7.3.1. Applicable domains
7.4. Layered architectural style
7.4.1. SOAP example
7.4.2. OSI layer
7.5. Virtual machine architectural style
7.5.1. JVM architecture
7.5.2. Benefits & limitations
7.5.3. Applicable domains

🔄 Week 4 Recap: What is Data Flow Architecture?

Core Idea

Data Flow Architecture views the entire software system as a series of transformations on successive sets of data.

Data moves from one component to the next → each component transforms the data → passes it forward.

🍕 Easy Example: Pizza Assembly Line

Think of a pizza shop where each station does one job:

Dough Station → makes the base → Sauce Station → adds sauce → Topping Station → adds toppings → Oven → bakes it → Boxing → ready!

Each station doesn't care WHO is before or after it. It just takes input, transforms it, and passes output. That's Data Flow Architecture!

🔑 Independence

Components don't know each other — only input/output matters.

⚙️ 3 Subcategories

1. Batch Sequential
2. Pipe & Filter
3. Process Control

📂 Best For

Compilers, data processing, multimedia streaming, embedded systems.

📋 Week 4 Crux: Data Flow Comparison Table

Feature	Batch Sequential	Pipe & Filter	Process Control
How Data Moves	Whole batch at once	Continuous stream (incremental)	Variable updates via feedback loop
Concurrency	❌ None — Step A finishes, then B starts	✅ High — All filters work simultaneously	⚡ Real-time continuous loop
Control	Explicit (Script drives order)	Implicit (Data drives flow)	Loop (Sensors drive actions)
Latency	🐢 High (wait for full batch)	🐇 Low (start immediately)	⚡ Near-zero (real-time)
Interactive?	❌ No user interaction	❌ No user interaction	✅ Yes (user sets target)
Easy Example	🏦 Bank: Process ALL salaries → then report	🚗 Car Wash: Soap → Rinse → Dry (all at once)	❄️ AC: Measure temp → adjust cooling → repeat
Best For	Tape/File processing, Billing	Compilers, Multimedia, Unix CLI	Embedded systems, IoT, Robotics
🎓 One-Liner	"Finish everything, then move."	"Everyone works at the same time."	"Measure, adjust, repeat forever."

🎓 Crux: Choose Batch for simplicity, Pipes for speed, and Control for physical feedback systems.

6. Week 5 Recap: Data-Centered Architecture

The Big Idea

One central data store sits in the middle. All software components (called agents) connect to it. Agents never talk to each other directly — everything goes through the data store.

📱 Easy Example: WhatsApp Group

Imagine your class WhatsApp group:

Group Chat = Data Store (center)
Members = Agents (around it)
Nobody DMs each other for class notes — everyone posts & reads from the group

✅ That's Data-Centered Architecture! One shared place, everyone accesses it.

WhatsApp Group = Data-Centered Architecture

6.1 Two Building Blocks

The system has only 2 major parts:

🗄️

1. Data Store

The central hub — stores all shared data. Provides: Insert, Delete, Update, and Retrieve operations.

Think: Database / Shared Folder / Cloud Drive

⚙️

2. Independent Agents

Software components that work independently. Each reads/writes data to the store without knowing about other agents.

Think: Apps / Modules / Services

🔑 Key Properties

📌 Data Integrity — Single source of truth 🔄 Loose Coupling — Agents are independent 📈 Scalability — Add agents without breaking others ⚠️ Single Point of Failure — If store dies, everything stops

6.2 Repository Architecture

Data-centered sub-type 1: "Agents form the Logic"

🗂️ Repository

Data Store = Passive (Lazy) 😴

Agents = Active (Hardworking) 💪

The agents decide when to read/write data. The data store just sits there waiting.

🏪 Like a Library: Books (data) sit quietly on shelves. You walk in, pick a book, return it. The library doesn't chase you!

✅ Advantages

Data Independence — agents don't need to know data format
Backup & Recovery — centralized data is easy to manage
Concurrent Access — multiple agents can query simultaneously

❌ Disadvantages

Bottleneck — single store can slow down under heavy load
Single Point of Failure — store crash = total system failure
Schema Changes — modifying structure affects all agents

6.3 Blackboard Architecture

Data-centered sub-type 2: "Data triggers the Logic"

📋 Blackboard

Data Store = Active (Boss) 🫡

Agents = Passive (Waiting) ⏳

The data store triggers events. When data changes, it notifies agents to wake up & act.

📢 Like a Classroom: Teacher writes on the blackboard → students react to what they see. The board drives the action!

✅ Advantages

Scalability — easily add new Knowledge Sources (agents)
Reusability — agents can be reused across different blackboards
Fault Tolerance — one agent failing doesn't crash others

❌ Disadvantages

Difficult Testing — non-deterministic behavior, hard to reproduce
No guaranteed solution — may not converge to an answer
Complexity — synchronization & controller logic is tricky

📋 Week 5 Crux: Repository vs Blackboard

Feature	Repository	Blackboard
Control Flow	Agents (User Logic)	Data State (Triggers)
Data Store	Passive (Wait for query)	Active (Notify agents)
Connection	Explicit Invocation (Call)	Implicit Invocation (Pub/Sub)
Agents Role	Active — decide when to access data	Passive — wait for notification
Communication	Pull-based (Request/Response)	Push-based (Event-driven)
Best For	DBMS, Business Apps, CASE	AI, Speech/Pattern Recognition
Data Stability	Stable (defined schema)	Evolving (hypotheses)
Analogy	📚 Library — you go pick a book	🔔 Alarm — it wakes you up

6.5 Applied Domains

🗂️ Repository Applications

Used when data structure is known and stable.

DBMS: SQL Databases (Oracle, MySQL, PostgreSQL).
CASE Tools: Software design sharing (UML editors, Rational Rose).
Compilers: Shared symbol table across phases (Lexer → Parser → Code Gen).
Version Control: Git, SVN — central code repository.
ERP Systems: SAP, Oracle — shared business data across modules.

📋 Blackboard Applications

Used when problem is complex and ill-defined.

AI Systems: Expert diagnosis tools (medical, mechanical).
Speech Recognition: Converting sound → text (Hearsay-II).
Pattern Recognition: Fingerprint matching, Image analysis.
Autonomous Vehicles: Sensor data fusion (LIDAR + Camera + Radar).
Natural Language Processing: Text understanding pipelines.

💡 Rule of Thumb: If data is structured & predictable → Repository. If data is evolving & uncertain → Blackboard.

7. Hierarchical Architecture

Chapter Objectives

By the end of this chapter, you should be able to:

1. Concepts

Introduce hierarchical software architecture concepts.

2. Styles

Describe Main-Subroutine, Master-Slave, and Layered architectures.

3. Domains

Discuss application domains (OS, Networks, etc.).

4. Evaluation

Discuss benefits and limitations.

7.1 Overview: Hierarchical Structure

The Big Idea

The system is viewed as a hierarchy of logical modules (subsystems) at different levels.
Dependencies are strict: Lower-level modules provide services to adjacent Upper-level modules.

🧩 Module Connection

Modules connect via Explicit Invocation (Call-and-Return).

Procedural (C/Pascal):
Functions in libraries/header files.
Usage: #include <stdio.h> then call printf().

Object-Oriented (Java/C#):
Classes in packages.
Usage: import java.util.* then call List.add().

🏗️ Design Philosophy

Decomposition: Break comprehensive systems into manageable layers.
Abstraction: Upper layers don't worry about how lower layers work.
Reuse: Lower layers (like I/O or Math libraries) are reused by many upper layers.

7.1 System Software Architecture

System software (OS, Networks) is the classic example.

1. User Interface (Upper)
Shell, GUI, CLI Interpreters

⬇️

2. Domain Logic (Middle)
Business Rules, Core Processing

⬇️

3. System Services (Lower)
I/O, Security, Scheduling, Transaction

Real-World Examples

Microsoft .NET: Languages (C#) → CLR → OS Services.
Unix OS: User Apps → Shell → Kernel → Hardware.
TCP/IP Stack: App → Transport → Internet → Link.

🛡️ Rule of Change:

Changes to a layer only affect its adjacent upper layer (and only if the interface allows it). No ripple effects to the whole system!

7.1 The Four Hierarchical Styles

Hierarchy is often combined with other styles!

1. Main-Subroutine

Classic procedural programming. A main controller calls sub-procedures to do specific tasks.

2. Master-Slave

Parallel computing. A master distributes identical work to slaves and collects results.

3. Layered

The "Onion" model. Distinct layers (Presentation, Logic, Data) with strict visibility rules.

4. Virtual Machine

Simulation. Software that emulates hardware (e.g., JVM) to provide a portable platform.

"It is hard to find software designs that only use one architecture style."

Figure 7.1: Hierarchical Architecture

Figure 7.1: Block diagram of typical hierarchical software architecture

🔍 Understanding the Structure

Root (Main System): The single control point. It orchestrates the entire system flow.
Subsystems (Intermediate): Perform high-level logic. They break down complex tasks into smaller pieces.
Leaves (Bottom): specialized utilities (e.g., I/O, Math) that perform specific, atomic operations.
Key Principle: Control flows Down ⬇️, Results flow Up ⬆️.

7.2 Main-Subroutine Architecture

The Classical Paradigm

Dominant for decades. The goal is to reuse subroutines developed independently.

Procedural Style

Data is often shared by subroutines at the same level.

"Global variables" are common and accessible by related routines.

OO Style

Data is encapsulated within individual objects.

Information is protected and hidden from the outside.

⬇️ Vertical Decomposition

System is refined vertically until subroutines are simple enough to have a single independent responsibility.

7.2 Structure & Data Passing

Control Flow

A "Main" program drives the sequencing of subroutine calls (looping over invocations).

Data Passing Mechanisms

Pass by Value: Subroutine gets a copy. Original data cannot be changed.
Pass by Reference: Subroutine gets a pointer. Original data can be changed.
Pass by Name: (Less common) Depends on implementation.

Figure 7.2: Hierarchical Decomposition

7.2 Mapping Requirements (DFD)

How do we design this? We map a Data Flow Diagram (DFD) to the structure.

1. Transform Flow

Sequential data processing.

                            Input ➔ [Transform] ➔ Output
                        

Incoming flow is converted into internal format, processed, and shipped out.

2. Transaction Flow

Branching logic based on input.

                            Input ➔ [Evaluate] ➔ Path A / Path B
                        

A "Transaction Center" evaluates input and dispatches to the correct action path.

Design Strategy: Identify Transform vs. Transaction centers in the DFD and map them to Main or Sub-controllers.

7.2 Example: Purchase Order Processing

Figure 7.3: From DFD (Top) to Hierarchy (Bottom)

A. Incoming Flow

1. Record Info ➔ 2. Validate Request. Creates the foundation data.

B. Transaction Center

3. Dispatcher evaluates request type: Purchase OR Return.

C. Action Paths

Purchase Path: Check Stock (#5) ➔ Check Cred (#6) ➔ Invoice.
Return Path: Check Policy (#7) ➔ Refund (#8).

7.2 Benefits & Limitations

✅ Benefits

Easy Decomposition: Matches top-down refinement naturally.
Reusability: Subroutines can be reused by multiple callers.
Modularity: Each module has a specific responsibility (if designed well).
Simplicity: Easy to trace execution flow.

❌ Limitations

Global Data Vulnerability: Shared data can be corrupted by any subroutine.
Tight Coupling: Changes in a subroutine often ripple up to main or other callers.
Scalability: Can become a "spaghetti" of calls if not strictly managed.

7.3 Master-Slave Architecture

🏭 Real-World Analogy: A factory manager (Master) assigns identical tasks to assembly line workers (Slaves), then collects finished products.

Concept

A variant of functionality where Reliability and Fault Tolerance are critical.

The Master

Distributes work to slaves.
Collects results.
Selects the final result (e.g., majority vote).

The Slaves

Provide replicated services.
May use different algorithms/methods for the same task.
Execute in parallel.

⚠️ Note: Do not confuse with Database Master-Slave replication (where if Master dies, Slave takes over). Here, the Master is the coordinator and Slaves are workers.

7.3 Structure & Class Diagram

The structure supports parallel execution and redundancy.

Figure 7.4: Block Diagram

Master configures invocations and processes returned results.

Figure 7.5: Class Diagram

Slaves implement the same interface (+service()) often in different ways.

🔍 Fig 7.4: Block Diagram Logic

Master: The central coordinator. It breaks tasks into sub-tasks.
Slaves: Independent worker nodes. They process sub-tasks in parallel.
Flow: Master sends Request ➔ Slaves Process ➔ Slaves Return Result ➔ Master Aggregates.

📐 Fig 7.5: Class Structure

Interface: Slaves must implement a common interface (e.g., service()).
Polymorphism: The Master relies on the interface, not specific slave implementations.
Scalability: New slave types can be added without changing the Master code.

7.3 Characteristics & Domains

🚀 Key Benefits

Fault Tolerance: If one slave fails, others can provide the result.
Parallel Computing: Slaves run simultaneously.
Accuracy: "Majority Vote" strategy rules out outliers/errors.

🌍 Applicable Domains

Systems where Reliability is critical:

Aircraft Control Systems
Nuclear Power Plant Monitoring
High-Availability Web Services

Strategies for Master

Failure detection, Time-out mechanisms, and Result Selection (Voting, First-Valid, Average).

7.4 Layered Architecture

The Concept

Decomposition into higher (abstract) and lower (specific) layers. Each layer has a sole responsibility.

⬇️ Request Flow

Layer i+1 invokes services of Layer i via interface.

Request goes Down via method invocation.

⬆️ Response Flow

Layer i responds to Layer i+1.

Response goes Up via method return.

🌉

Bridging & Breaching

Pure Layered: Only talks to adjacent layer.
Bridging: Upper layer skips a level down (Performance optimization).
Breaching: Lower layer calls upper layer (Avoid! Causes dependency cycles).

7.4 Business Application Example

Figure 7.6: Business Application Layers

Abstraction Levels

User Interface (Top): Most abstract. Users see GUI, not code.
Business Process: Logic & Rules.
Basic Utility: Common services used by many components.
Core Services (Bottom): Least abstract. Close to OS/Hardware.

🔍 Diagram Logic

⬇️ Request: User action triggers Business Logic ➔ Calls Utility ➔ Accesses Core Data.
⬆️ Response: Core returns Data ➔ Utility formats it ➔ Business validates ➔ UI displays it.

7.4 Component-Based Implementation

Layers can be deployed as components (e.g., Java .jar files).

Figure 7.7: Package Organization

Separation of Concerns

Interaction Layer: Handles UI, Validation, Forwarding.

⬇️ ⬆️

Processing Layer: Logic, Database Access, Calculation.

🔍 Package Logic

The diagram shows that the Interaction package depends on the Processing package, but NOT vice-versa. This is critical for maintainability.

This decoupling allows business logic to be independent of the presentation (GUI/Web/Mobile).

7.4 Protocols & Class Structure

Figure 7.8: Protocol Stack

🔍 Stack Logic

Data travels Down stack A via TCP/IP, crosses the network, and travels Up stack B to the Server Application.

Figure 7.9: Class Interface

🔍 Interface Logic

All layers implement a common interface (e.g., service()). This allows upper layers to treat lower layers polymorphically.

7.4 Evaluation & Benefits

✅ Key Benefits

Incremental Development: Build and test one layer at a time.
Independence: Changes in the "Core" layer don't break the "UI" layer as long as the interface is stable.
Interchangeability: Easy to "plug-and-play" new components (e.g., swapping a Database driver).
Portability: Each layer can be an abstract machine deployed independently.

❌ Limitations

Performance Overhead: A simple request must pass through multiple layers, adding latency.
Data Marshaling: Converting data formats between layers takes processing power.
Cascading Exceptions: An error in the bottom layer must propagate up through every layer to be handled.

🌍 Design Note

"Any problem in computer science can be solved by another layer of indirection."

7.5 Virtual Machine Architecture

The Concept

A Virtual Machine (VM) provides an abstraction that separates the application/language from the execution platform.

Figure 7.10: Unix Virtual Machine

Simple Calculator Example

Example: Unix Shells

Unix uses the Kernel as a VM.

Shells (C, Korn, Born): Run on top of the kernel.
Kernel: Hides underlying hardware/drivers.
Result: Shell commands are independent of physical devices.

7.5 Microsoft .NET & CLR

Using a VM to unify multiple languages.

Unified Platform

The Common Language Runtime (CLR) acts as the VM.

Languages (VB.NET, C#, C++): compile to a single Intermediate Language (IL).
Interoperability: A VB.NET client can use a C# component easily.

Figure 7.11: .NET CLR Structure

7.5 Java Virtual Machine (JVM)

Figure 7.12: JVM Architecture

Write Once, Run Anywhere

Java Source ➔ Bytecode (Platform Independent) ➔ JVM (Platform Specific) ➔ OS.

🔍 Comparison

C++: Compiles to native machine code. Fast, but not portable (must recompile for specific OS).
Java: Compiles to Bytecode. Portable, but interpreted by JVM (slower).

7.5 VM Interpretation Engine

Figure 7.13: Execution Engine

Engine Logic

Fetch Bytecode ➔ Fetch Opcode ➔ Execute (Switch case) ➔ Update PC.

// Java Bytecode Example (javap -c)
iconst_0     // Push 0
istore_0     // Pop to V0
iload_0      // Push V0
iconst_2     // Push 2
if_icmpge 20 // Compare 0 >= 2
...
iinc 0, 1   // Increment V0
goto 2      // Loop

The VM acts as a CPU for this bytecode, managing the Program Counter (PC), Stack, and Registers.

7.5 Evaluation & Applicability

✅ Benefits

Portability: Run on any hardware that has the VM installed.
Simplicity: Development is abstracted from hardware details.
Safety: VM can sandbox the execution (e.g., Browser JS).

❌ Limitations

Performance: Interpretation adds overhead compared to native compilation.
Complexity: Building the VM itself is complex and platform-dependent.

🌍 Applicable Domains

Scripting languages (Python, Ruby), Rule-based systems, XML processing, and Cross-platform applications.

7.6 Summary & Design Guidelines

📝 Chapter Summary

The Hierarchical Architecture style decomposes systems into layers where upper layers consume services from lower layers via explicit invocation.

Main-Subroutine: Functional decomposition.
Master-Slave: Parallel work/Fault tolerance.
Layered: Abstraction & Independence.
Virtual Machine: Portability & Simulation.

🛠️ Design Guidelines

Decomposition Criteria: A layer should only depend on its lower layer. Tasks must be clear and specific.
Number of Layers: Keep it ≤ 7 to avoid excessive overhead and complexity.
Interfaces: Define clear API/Interface for each layer.
Error Handling: Design how errors propagate (or are handled) across layers.

Chapter 7 Crux: The Hierarchy of Software

"Structure is the bridge between chaos and order."

Style	Key Characteristic
Main-Subroutine	Functional decomposition, shared data or passing.
Master-Slave	Coordination, parallel processing, reliability.
Layered	Abstraction layers, request/response, strictly adjacent.
Virtual Machine	Platform independence, simulation, translation.

🚀 Key Takeaway

Hierarchical styles are dominant in system software (OS, Networks) and large-scale applications because they manage complexity through separation of concerns and controlled dependencies.

Thank You!

Questions & Discussion

📚 Chapter 7: Hierarchical Architecture

Main-Subroutine • Master-Slave • Layered • Virtual Machine

💡 "Good architecture is about managing complexity through separation of concerns."