🏠 Home

Week 5

Data Centered Architecture

Chapter 6

Instructor: Baber Sheikh (Visiting Faculty)

Agenda

6. Introduction to Data Centered Architecture
6.1 Building blocks of data centered architecture
6.2 Repository architectural style
6.2.1 Overview
6.2.2 Benefits & limitations
6.2.3 Applicable domains
6.3 Blackboard architectural style
6.3.1 Overview
6.3.2 Benefits & limitations
6.3.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 Recap: Batch Sequential & Pipe and Filter

📦 Batch Sequential

Traditional step-by-step processing (1950s–1970s). Each subsystem must complete fully before the next one starts.

Flow: Validate → Sort → Update → Report

🏦 Easy Example

Bank processes month-end salaries:

Step 1: Collect ALL salary requests → Step 2: Validate ALL → Step 3: Process ALL → Step 4: Generate report.

⚠️ Step 2 can't start until Step 1 finishes everything.

🔧 Pipe & Filter

Components (Filters) process data simultaneously. Connected by Pipes (FIFO buffers). Incremental — no waiting for full batch.

Unix: who | sort | wc -l

🚗 Easy Example: Car Wash

Station 1: Soap → Station 2: Rinse → Station 3: Dry

Car A is being rinsed while Car B enters soap station — they work at the same time!

✅ Unlike Batch: doesn't wait for ALL cars to finish soap first.

Key Difference: Batch Sequential = "Finish everything, then move." | Pipe & Filter = "Start passing immediately, everyone works together."

🔄 Week 4 Recap: Process Control Architecture

Closed-Loop Feedback System

Maintains a variable (Temperature, Speed, Altitude) at a specific level by continuously measuring and adjusting.

❄️ Easy Example: AC in Your Room

You set: 22°C (Set Point)

Sensor reads: 28°C (Input Variable)

Controller calculates: Error = 28 - 22 = 6°C too hot!

Executor: Turns compressor ON full blast

Once temp reaches 22°C → compressor slows down. Goes below 22°C → it stops. This loop runs forever.

📊 The 4 Variables

Controlled Variable: What we maintain (Temperature)
Set Point: The goal value (22°C)
Input Variable: Sensor reading (28°C)
Manipulated Variable: What we adjust (Fan speed)

🧠 Two Main Units

Controller (The Brain):

Calculates: Error = Set Point − Current Value

Decides how much to adjust.

Executor (The Muscle):

Physically changes the system (Engine, Heater, Motor, Compressor).

📋 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. What is 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

6.1 How Communication Works

🚫 Agents DON'T Talk Directly

In pure data-centered architecture, Component A never calls Component B. All communication passes through the shared data store.

📁 Easy Example: Google Drive

You upload a presentation to Google Drive.

Your friend opens Drive, sees the file, edits it.

Another friend opens Drive, sees updates, adds comments.

Nobody emailed the file → everyone went to the shared drive (data store). That's data-centered!

🔗 Two Types of Connections

1. Data Link (Solid Lines ─)

Bidirectional — agents get data from the store and put data into the store.

2. Control Link (Dashed Lines - -)

Bidirectional — either the data store controls agents OR agents control the data store.

💡 Key Insight

Who controls whom? That's what separates Repository from Blackboard!

6.1 The Two Categories

Data-centered has 2 sub-types, separated by one question: "Who is the boss?"

🗂️ 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!

📋 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!

6.1 Repository Architecture

🗂️ How It Works

Agents (clients) actively request data from a passive data store. They can access it interactively (real-time queries) or via batch transactions (bulk operations). The data store never initiates contact.

💻 Easy Example: VS Code (Your IDE)

Your project folder = Data Store (passive, just sits there with files)

Code Editor → reads files to show code
IntelliSense → reads files to suggest autocomplete
Debugger → reads files to set breakpoints
Git Extension → reads files to show changes

The folder (data store) never says "Hey! Read me!" — the tools (agents) pull from it when they need to.

🗃️ DBMS

MySQL, PostgreSQL — Clients query, DB returns data.

🛠️ CASE Tools

Rational Rose, Visual Paradigm — Tools share project models.

🔧 Compilers

Lexer, Parser, Code Gen — all share the symbol table.

6.1 Blackboard Architecture

📋 How It Works

The data store is active — it triggers events when data changes. Agents (called Knowledge Sources / Subscribers) are passive — they wait for notifications, then react. This chain continues until a goal is reached.

📷 Easy Example: Instagram Notifications

You post a photo on Instagram:

Instagram Server (Data Store) detects: "New photo uploaded!"
→ Notification Agent wakes up: sends push notification to followers
→ Feed Agent wakes up: adds photo to followers' feeds
→ AI Agent wakes up: scans photo for content moderation
→ Analytics Agent wakes up: starts counting views & likes

The server (data store) pushed the event, and agents reacted. Nobody asked — the data triggered everything!

🤖 AI Systems

Knowledge-based expert systems — data triggers reasoning.

🎤 Voice Recognition

Siri/Google — audio data triggers processing agents.

🔒 Security Systems

Intrusion detected → agents respond in chain.

6.2 Repository Architecture Style

What Makes Repository Special?

Repository is a data-centered architecture that supports user interaction for data processing. The agents (clients) control computation and flow of logic — NOT the data store. The data store is passive.

🎬 Easy Example: Netflix

Netflix Database = Repository (passive, stores all movies/shows)

Mobile App → queries DB to show you movies
Smart TV App → queries DB to play content
Recommendation Engine → queries DB to suggest shows
Admin Dashboard → queries DB to manage content

The database never says "Hey, watch this!" — apps pull data when they need it. That's Repository!

Figure 6.1: Repository Architecture

📌 Key Properties

Data Store: Passive — just stores data
Agents: Active — they control logic flow
Access: Interactive query or Batch connection
Interfaces: Different clients can have different interfaces & privileges

📱 Google Docs Example

Multiple people typing in the same document.

User A types "Hello" → Docs Engine saves to DB → User B sees "Hello".

Figure 6.2: Control Flow (Agents control the Data Store)

6.2 Repository Example: Student Management

A simple class diagram showing how Repository Architecture works in code

📦 Three Parts Working Together

1. Student Class (Data Bean)

Holds one student's data: SSN + Name. Has getters & setters.

2. Students Collection

An ArrayList/Vector holding many Student objects. add(), remove(), next(), first().

3. Students Table (Database)

Physical DB table with rows: (SSN, Name). Connected via JDBC.

📱 Easy Analogy: Contacts App

Think of your phone contacts:

One Contact = Student object (has name, number)
Contact List = Students collection (ArrayList)
Cloud Backup = Database table (Google/iCloud sync)

When you add a new contact → it goes into your list → AND saves to the cloud database. That's exactly what this class diagram shows!

Figure 6.3: Student Management Class Diagram

Figure 6.4: Dynamic View of Client Interaction

6.2 Java Code: Student Data Bean

The Student class — one object = one row in the database table

public class Student implements Serializable {
    String SSN;
    String Name;

    // Default Constructor
    public Student() {
        SSN = "";
        Name = "";
    }

    public Student(String ssn, String name) {
        SSN = ssn;
        Name = name;
    }

    // Getters & Setters
    public void setSSN(String ssn) { SSN = ssn; }
    public String getSSN() { return SSN; }
    public void setName(String name) { Name = name; }
    public String getName() { return Name; }
}

🧐 What's Happening?

Serializable → Object can be saved/sent over network
Two attributes: SSN + Name (matches DB columns)
Default Constructor: Empty student
Custom Constructor: Student with values
Getters/Setters: Read & write each field

🍔 Easy Analogy

Student class = Order Form at a restaurant

It has fields (dish name, quantity) and methods (fill in, read back). One form = one order = one DB row.

6.2 Java Code: JDBC Database Access

How agents (clients) connect to the Repository (database)

Step 1: Connect to Database

try {
    Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
    Connection connection =
        DriverManager.getConnection(
            "jdbc:odbc:students");
} catch(Exception e) { ... }

Step 2: Read All Students

ArrayList studentList = new ArrayList();
Statement stmt = connection.createStatement();
ResultSet results =
    stmt.executeQuery("SELECT * FROM students");
Student student = new Student();
while (results.next()) {
    student.setSsn(results.getString(1));
    student.setName(results.getString(2));
    studentList.add(student);
}

🔍 Step-by-Step Breakdown

1. Load Driver

JDBC driver = the "bridge" between Java and the DB

2. Get Connection

Open a "road" to the students database

3. Execute SQL

SELECT * = "Give me everything from students table"

4. Loop & Fill

Read each row → create Student object → add to list

Repository Pattern: Client (this code) actively pulls data from the passive DB. The DB never pushes data to the client!

6.2 Dynamic View: Multiple Clients Sharing Data

One Data Store, Many Clients

Multiple clients can Read (R) and Write (W) the same data object. Each client may use a different interface: CLI, GUI, API, RPC, or RMI.

📱 Easy Example: Google Docs

One Google Doc = shared data object

Client 1 (Laptop): Opens doc, edits text (Write)
Client 2 (Phone): Opens same doc, reads it (Read)
Client 3 (Tablet): Adds comments (Write)

All 3 clients access the same document stored in Google's repository. They Read & Write independently!

🖥️ Different Access Interfaces

Interface	Example
CLI	MySQL Terminal
GUI	phpMyAdmin, DBeaver
Program API	JDBC, REST API
RPC / RMI	Remote method calls

6.2 Domain 1: Database Systems (DBMS)

The relational DBMS is the most common repository architecture. The data store maintains schema (metadata), data tables, and index files. Many tools can access it.

🏫 Easy Example: University Portal

Oracle Database = Repository (stores everything)

🎓 Student Portal → queries grades, courses
👨‍🏫 Faculty Portal → uploads marks, attendance
🏢 Admin Panel → manages admissions, fees
📊 Analytics Tool → generates reports
💰 Finance Module → handles billing

All these tools (agents) pull/push data to the same central database!

🗄️ What's Inside the Repository?

Schema (Metadata)

Table definitions, column types, constraints

Data Tables

Actual rows of data (students, courses, grades)

Index Files

Speed up searches (like a book's index)

Figure 6.5: Database Management System

6.2 Domain 2: CASE Tools

Computer Aided Software Engineering (CASE) systems are a perfect repository example. Multiple tools share one centralized data store containing design blueprints, code, and documentation.

🛠️ How CASE Tools Work

📐 UML Editor → draws class/sequence diagrams
💻 Code Generator → converts UML → Java/C++ code
🔄 Reverse Engineering → converts code → UML diagrams
📝 Documentation Tool → generates docs from models
🔀 Format Converter → Booch ↔ Rumbaugh ↔ Jacobson

💡 Biggest Advantage: One centralized data set → many tools → different products for different purposes!

Figure 6.6: CASE Tools & Repository (Code, Designs, Docs)

6.2 Domain 3: Compiler System

Every compiler has a shared data repository (symbol table, syntax tree, constant table) accessed by all compilation phases. Data flows through phases but is stored centrally.

⚙️ Compilation Phases as Agents

1. Scanner (Lexical Analyzer)

Reads source code → breaks into tokens → fills symbol table

2. Parser (Syntax Analyzer)

Reads symbol table → builds syntax/parse tree

3. Semantics Analyzer

Checks type correctness on the syntax tree

4. Code Generator

Reads syntax tree → produces target binary code

🍳 Easy Analogy: Restaurant Kitchen

Your Java code = customer order

Scanner = Waiter writes order on the shared board
Parser = Chef reads board, organizes recipe steps
Semantics = Quality check: "Does this recipe make sense?"
Code Gen = Cook prepares the final dish (binary code)

Everyone reads/writes on the same shared board (repository). Nobody passes notes directly!

📝 Example from Book

Input: int x, y; x = y + 1;
Scanner tokenizes → Parser builds tree → Code Gen outputs: mov ax, [y]; add ax, 1; mov [x], ax

6.2 Repository Variants

Two important variations of the standard repository

🪟 Virtual Repository

Built on top of multiple physical repositories. Uses database views to create virtual tables.

Benefits:

Simplifies complex DB structure
Security management (limit who sees what)
Different views for different users

📱 Example: University DB → Students see "My Grades" view, Faculty sees "All Students" view, Admin sees everything. Same data, different views!

🌐 Distributed Repository

Data spread across multiple sites linked by network. Data is replicated for reliability.

Challenges:

Data partitioning (vertical/horizontal)
Synchronization of duplicated data
Network transmission cost
Two-phase commit for transactions

🏦 Example: Bank with branches in Karachi, Lahore, Islamabad — each branch has local DB, all synced together!

6.2 Repository: Benefits & Limitations

✅ Benefits

🔒 Data Integrity

Easy to backup & restore — all data in one place

📈 Scalability

Easy to add new agents — they don't communicate with each other

⚡ Less Overhead

No transient data passing between components directly

❌ Limitations

💥 Single Point of Failure

If the centralized DB goes down → everything stops

🔗 High Dependency

Data structure changes → all agents must be updated!

💸 Network Cost

If distributed → moving data across network is expensive

🎯 Best For

Large, complex info systems where many agents need data access. Requires data transactions to drive control flow.

🔗 Related Architectures

Layered, Multi-tier, and MVC architectures often incorporate repository patterns inside them.

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)
Best For	DBMS, Business Apps, CASE	AI, Speech/Pattern Recognition
Data Stability	Stable (defined schema)	Evolving (hypotheses)