Patterns·Deep Dive
DARK
SE322 · Software Design & Architecture · Chapter 04, Lecture 02

Four patterns,
four ways components talk.

Same question every time: who is allowed to talk to whom? Blackboard says "only through me." Pipes-and-Filters says "only to your neighbor." Client-Server says "only to the one server you know." Broker says "to anyone, through me, and you'll never know the difference."

Blackboard
Pipes-and-Filters
Client-Server
Broker
4 PATTERNS
§ 01 — DATA-CENTERED SYSTEMS, ZOOMED IN

Two roles: one manager, many workers

Data-centered systems decompose around one main central repository. Every system in this family has exactly two kinds of roles:

Data Management Component

Controls, provides, and manages access to the system's data — the gatekeeper.

Worker Components

Execute operations and perform work based on that data.

🚫
The one rule that matters most
"Workers never gossip — everything goes through the manager."
Communication is one-to-one, bidirectional, between a worker and the data management component. Workers never talk directly to each other.
Worker 1
⇄
Data Manager
⇄
Worker 2
Issues to watch for because of this shape: data integrity (complete, accurate, consistent data across transfers/storage/retrieval), and communication protocols between worker and data manager.
DBMS has two valid views: as a Repository (Data-Centered) → all apps share one central database. As part of a Client-Server system (Distributed) → clients send SQL queries, server processes them, database stores data.
§ 02 — BLACKBOARD PATTERN

Opportunistic problem-solving around a shared space

Blackboard

central data, independent agents

Components work around a central data component to provide solutions to complex problems — independently, with no predetermined or "correct" sequence of operations. Famous for depicting the logical architecture of expert systems (AI that mimics human decision-making using knowledge + inference rules).

🗣️
Three roles, one hook
"Board, Agents, Boss"
Blackboard = shared data store. Agents = independent specialists who read/write to it. Controller = decides who gets access, when.
Agent 1
Agent 2
Agent n
↓ ↓ ↓
Controller
→ manages access →
Blackboard
Real-world lens: the ER room
Blackboard The patient's chart — visible & updated by everyone
Agents Doctors, nurses, specialists — each updates based on their expertise
Controller Manages who gets access when, based on the patient's changing condition
Why the interfaces point where they point
Blackboard → Provides read/write/update interfaces — it's the central hub everyone needs.
Controller → Does not provide data interfaces to Agents; its job is to orchestrate, not store. It just says "go check the Blackboard."
Agents → Provide a service interface (e.g. run()) so the Controller can invoke them on demand.
Worked example — student scheduling system: StudentHistory, CourseOfferings, and WorkSchedule are Agents; ScheduleManager is the Controller; ScheduleBlackboard holds the draft schedule via getSchedule()/setSchedule().
  1. Client calls generateSchedule() on the ScheduleManager.
  2. ScheduleManager picks the next Agent via nextScheduler() and calls workOnSchedule().
  3. That Agent reads the draft from the Blackboard (getSchedule()), improves it, and writes it back (setSchedule()).
  4. Control returns to the Manager, which repeats for the next Agent — until the schedule is finalized and delivered to the Client.
General guideline: control flow is Controller → Agents (invocation). Data flow is Agents ↔ Blackboard (read/write). Agents never talk to each other directly — only indirectly, via the Blackboard, and only when the Controller schedules them.
Quality properties
Quality Why
Modifiability Agents are compartmentalized/independent — easy to add or remove an agent (e.g. a new SportsSchedule agent) without touching the others.
Reusability Specialized agents can be reused elsewhere — e.g. StudentHistory reused in a graduation checker.
Maintainability Separation of concerns means a bug in one agent (e.g. CourseOfferings) can be fixed without touching WorkSchedule.
Used in: speech recognition, image recognition, security systems, business resource management.
§ 03 — DATA FLOW SYSTEMS, ZOOMED IN

Two roles again — but this time in a chain

Decomposed around transporting and transforming data along the way to meet application-specific needs.

Worker components

Abstract the transformations/processing before forwarding a data stream: encryption/decryption, compression/decompression, changing format (binary → XML), enhancing/modifying/storing data.

Transport components

Abstract the management and control of the data transport mechanisms — how the data physically moves between workers.

The canonical pattern for this family: Pipes-and-Filters — covered next.
§ 04 — PIPES-AND-FILTERS PATTERN

A chain where each link transforms the data

Pipes-and-Filters

sequential transformation
🚰
Four components
"Source Feeds Pipes to a Sink"
Data Source produces input → Filters process/transform it → Pipes carry data between filters → Data Sink is the final destination.
Data Source
→
Filter 1
→
Filter 2
→
Filter 3
→
Data Sink
Careful: the box-and-line diagram is only an abstraction — real pipes and filters are more complex mechanisms than plain boxes and arrows suggest.
Worked example 1 — a language processor (compiler)
Lexical Analyzer Breaks source code into tokens. E.g. int x = 5; → tokens int, x, =, 5, ;
Parser Builds a parse tree from the tokens representing grammatical structure.
Code Generator Translates the parse tree into machine code / an intermediate representation.
Optimizer Makes the code faster / leaner — e.g. merges two memory operations into one instruction.
Interpreter (Alternative to compiling) executes the code directly from its high-level or intermediate form, without producing machine code.
Nice detail: filters are reusable components — the same Lexical Analyzer, Parser, and Optimizer can be reused whether you're building a compiler or an interpreter; just swap the last filter.
Worked example 2 — face recognition from video
YouTube Manager
→
Face Detection
→
Face Recognition
→
Identity Manager

Each stage transforms the data into something more specific: raw video → detected faces → recognized identities → an identity report. In one real implementation, the "pipe" between filters is literally .NET's FileSystemWatcher — when a filter writes a file, the next filter is notified and picks it up.

Quality properties
Quality Why
Extensibility New filters (e.g. a spam filter) drop in easily.
Efficiency Filters connected in parallel can run concurrently, reducing latency.
Reusability Compartmentalized pipes and filters can be reused as-is in other systems.
Modifiability Filters are independent — easy to add, remove, or swap.
Security Security filters can be injected at any point in the data flow.
Maintainability Independent filters mean maintaining one doesn't disturb the others.
§ 05 — DISTRIBUTED SYSTEMS, ZOOMED IN

Two shapes: hub-and-spoke, or all-equal peers

Decomposed into multiple processes that (typically) collaborate through a network.

Client-Server
  • One or more processes work on behalf of client users
  • They bridge to a remote server that performs delegated work
  • Example: a web browser talking to a web server
Peer-to-Peer
  • Peer nodes with similar capabilities
  • Collaborate together, no central server
  • Example: music/file-sharing apps like BitTorrent
Don't just look for multiple machines: with multi-core processors, a distributed architecture can also apply within a single physical node that has multiprocessor capability — distribution can be across many computers, or across many cores in one computer.
Common architectural patterns for distributed systems: Client-Server and Broker (both covered below). Real-world examples: internet systems, web services, file/music-sharing systems, high-performance systems.
§ 06 — CLIENT-SERVER PATTERN

Many independent clients, one server

Client-Server

direct, tightly coupled

Server: a program or device providing functionality to clients. Client: hardware/software that accesses a service made available by a server. Multiple clients talk to the server, but clients are independent — they never talk to each other.

Client
— Request →
Server
← Response —
Client
Deployment view: a PC Node runs pc_browser.exe, a Mobile Node runs mp_browser.exe, both send HTTP requests to a Server Node running web_server.exe, which responds with processed data. A deployment diagram maps these artifacts (programs) onto nodes (hardware) — different from a component diagram, which maps software components and their dependencies, not hardware.
Quality properties
Quality Why
Interoperability Clients on different platforms can interoperate with servers on different platforms.
Modifiability Server changes are centralized and quickly distributed to many clients.
Availability Multiple backup server nodes can be connected to increase availability.
Reusability Separating server from clients lets services/data be reused across applications.
The catch: clients are tightly coupled with servers — they must know the server's exact address/protocol, and server changes force client updates. This gets messy fast when services live on multiple servers at different locations. That's exactly the problem the Broker pattern was invented to solve.
§ 07 — BROKER PATTERN

A mediator so clients never need to know the server

Broker

indirect, loosely coupled

The broker (a mediator/middleware) coordinates communication between clients and servers — forwarding requests, transmitting results and exceptions — so one client can transparently access the services of multiple servers.

🧩
Six roles, one hook
"Careful Clients Book Special Server Bridges"
Client → ClientProxy → Broker → ServerProxy → Server, plus an optional Bridge for cross-broker interoperation.
Client
→
ClientProxy
→
Broker
→
ServerProxy
→
Server
Component Job
Client Application that uses services from one or more servers.
ClientProxy Makes remote components look local to the Client; decides whether a request can be resolved locally or must go to the Broker.
Broker Mediates between client and server components — the mediator everyone routes through.
ServerProxy Makes remote components look local to the Server.
Server Provides services to clients; may itself act as a client to another Broker.
Bridge Optional — encapsulates interoperation between different Brokers.
Client-Server vs. Broker, head to head
Client-Server
  • Direct communication, client ↔ server
  • Client must know the server's exact address/protocol
  • Tightly coupled — server changes force client updates
  • Simpler, but doesn't scale well to multiple servers
Broker
  • Indirect communication, through a middleware broker
  • Clients only need to know the broker, not the server
  • Loosely coupled — server changes don't touch clients
  • Scales to multiple servers/services transparently
In short: Client-Server = direct & tightly coupled. Broker = indirect & loosely coupled via a broker.
Quality properties
Quality Why
Interoperability Clients on different platforms interoperate with servers on different platforms — and transparently with multiple servers.
Modifiability Centralized server changes distribute quickly to many clients.
Portability Porting the broker to new platforms makes services easily reachable by new clients.
Reusability Brokers abstract away communication calls, so complex services can be reused across applications.
§ 08 — CHEAT SHEET

All four patterns, side by side

Pattern Family Core roles Coupling Signature quality win
Blackboard Data-Centered Blackboard, Agents, Controller Loose — agents never talk directly Modifiability (swap agents freely)
Pipes-and-Filters Data Flow Source, Filter, Pipe, Sink Loose — each filter only knows its pipe Extensibility & parallel efficiency
Client-Server Distributed Client, Server Tight — client must know the server Availability (backup server nodes)
Broker Distributed Client, ClientProxy, Broker, ServerProxy, Server, Bridge Loose — client only knows the broker Interoperability across multiple servers
Fastest way to pick the right answer on an exam: ask "does this system revolve around one shared data store (Blackboard), a sequence of transformations (Pipes-and-Filters), one client talking to one known server (Client-Server), or one client transparently reaching many servers (Broker)?"