Second patterns lecture: the patterns for the first three system types of Lecture 1. For each one learn its components (the roles you will be asked to name), how they communicate, and its quality properties.

Data-centered → the blackboard pattern.

Data flow → pipes and filters.

Distributed → client–server and broker. Interactive and hierarchical systems come in Lecture 3.

A data-centered system is decomposed around one central repository of data.

The data management component (the “Data Manager” in the diagram) controls, provides and manages access to the system’s data.

Worker components do the actual work, operating on that data.

Communication is one-to-one and two-way between each worker and the data manager (the “two way communication” arrows).

Workers do not interact with each other directly; everything goes through the data management component. That keeps workers independent, but makes the data manager critical: if it is slow or down, everyone is.

Because everything depends on shared data, these systems must handle data integrity: data stays complete, accurate and consistent across operations, even when several workers update it (the diagram adds transactions and recovery, and security, at the data manager).

They must also define the communication protocols (and security) between the workers and the data manager. The Extra box repeats Lecture 1: a DBMS can be seen as a repository or as the server in client–server.

The blackboard pattern decomposes a system into components that work around a central data component to solve complex problems.

The components work independently, each providing a partial solution, in an opportunistic way: whoever can contribute something useful given the current state does so.

There is no predetermined sequence of operations that leads to the answer. That is the key difference from pipes and filters, whose order is fixed.

The pattern copies how a group of scientists would attack a hard problem together at one blackboard.

A mediator (controller) controls access to the board. When it hands control to a scientist, that scientist looks at the current state and, if possible, advances the solution before releasing the board.

With the new knowledge on the board, control goes to the next scientist who can improve it, and so on until no more progress can be made. There is no fixed order: each contributes when the current state makes their expertise useful.

This is how expert systems work (AI that applies knowledge and inference rules like a human expert, in medicine or finance), so the blackboard pattern is a good fit for their logical architecture.

Blackboard: the shared whiteboard in a group project, where all information is displayed and updated and everyone can see it.

Agents: independent contributors with different skills who read the board and add their expertise.

Controller: the organiser who manages when and how agents access the board, so the project progresses in an orderly way.

An emergency room maps onto the pattern exactly.

Blackboard: the patient’s chart, visible to all staff and continuously updated.

Agents: doctors, nurses and specialists. A nurse updates vital signs, a doctor orders tests or medication, a specialist adds an opinion. Each reads the chart and contributes from their own expertise.

Controller: decides who gets access to the chart and when, prioritising contributions as the patient’s condition changes.

Blackboard: the central data repository where all current information is displayed and accessible.

Agents (knowledge sources): Agent 1–4, each with unique expertise for part of the problem. In the cartoon, agents cannot touch the board until the controller grants access.

Controller: decides which agent accesses the board at any time, keeping problem solving orderly.

Process: Agent 1 currently has access and advances the solution; Agents 2–4 wait their turn.

Typical uses: speech recognition, image recognition, security systems, business resource management. All are problems where several kinds of knowledge must be combined with no fixed order.

The structure diagram: the controller at the top connects to every agent (to invoke them) and to the blackboard; Agents 1…n each connect to the blackboard to read and write. Agents never connect to each other.

Example: a students’ scheduling system that builds a schedule from completed courses, the student’s work schedule, and the courses offered.

Blackboard (ScheduleBlackboard): the shared knowledge base that controller and agents read and write.

Agents (StudentHistory, WorkSchedule, CourseOfferings): specialised problem solvers that contribute when they can.

Controller (ScheduleManager): decides when and which agent acts, and the order of problem solving.

Interfaces in the component diagram: the blackboard provides an interface (IStudentHistory, IWorkSchedule… read/write/update) because both the controller and the agents need its data. The controller provides nothing to the agents: it orchestrates, it doesn’t store data.

The agents provide an interface (e.g. run(), workOnSchedule()) that the controller requires, so the controller can invoke them when it decides they should act.

Who does what: the blackboard is the shared store with a read/write/update API; agents are specialised solvers that use that API when invoked; the controller (scheduler) orchestrates when and which agent runs, and does not pass data around.

One cycle: (1) the controller decides “Agent A runs now” and calls AgentA.run(); (2) A reads what it needs from the blackboard; (3) A computes and writes its results back; (4) the controller checks the board (or is notified) and picks the next agent.

Interfaces: the blackboard provides the data API (agents and controller require it); agents provide a service interface such as run() (the controller requires it); the controller generally provides nothing to agents.

Guideline: control flows controller → agents (invocation); data flows agents ↔ blackboard (read/write). Agents never talk to each other; they communicate only through the blackboard, and only when scheduled.

The sequence diagram for the scheduling system. Client: the student portal; the student clicks “Generate Schedule”, which calls generateSchedule().

ScheduleManager (controller) runs the process and decides which scheduler goes next (nextScheduler()).

StudentHistory, CourseOfferings, WorkSchedule: the agents. Each improves the draft: check eligibility from passed courses, keep only sections actually offered, remove conflicts with work hours.

ScheduleBlackboard holds the current draft, accessed through getSchedule() and setSchedule(). Slides 15–17 walk through the 19 messages.

Messages 1–2: the client calls generateSchedule() on the ScheduleManager, which calls nextScheduler() to choose the first agent.

Phase 1 (messages 3–6): the manager calls workOnScheduler() on StudentHistory; StudentHistory reads the draft with getSchedule(), adjusts it for past courses and degree requirements, saves it with setSchedule(sch), and returns control to the manager.

Phase 2 (messages 7–11): the manager picks the next agent (nextScheduler()) and calls workOnScheduler() on CourseOfferings. It reads the draft, keeps only courses actually offered this semester, saves the realistic version back, and returns control. Note the pattern repeating: manager invokes → agent reads → agent writes → control returns.

Phase 3 (messages 12–16): WorkSchedule reads the draft, removes conflicts with the student’s work commitments, and saves the final conflict-free version.

Phase 4 (messages 17–19): the manager retrieves the finished schedule from the blackboard with one last getSchedule() and returns it to the client.

Modifiability: agents are independent, so adding or removing one is easy, e.g. a new SportsSchedule agent without touching the others.

Reusability: specialised agents can be reused elsewhere, e.g. StudentHistory in a graduation checker.

Maintainability: knowledge is separated, so fixing a bug in CourseOfferings doesn’t touch WorkSchedule. (The cost: the controller’s scheduling makes behaviour harder to predict and test.)

A deployment diagram shows the physical deployment of artifacts (programs, libraries) onto hardware: servers, devices, run-time nodes and the communication links between them. Web-app example: how the web server, application server and database server are configured and connected.

A component diagram shows how software components are organised and depend on each other through interfaces. Web-app example: the authentication library, data-access objects and business logic, and how they interact. Component = logical structure; deployment = where it runs.

The exercise: a speech-recognition system. Input is speech as a waveform (single words or whole sentences); output is English text on the screen.

Using the structure on the left (Segmentation, Word creation and Phrase creation agents around a controller and a blackboard holding segments S1…S9, words and phrases), draw the component and sequence diagrams with the blackboard pattern.

(The table on the right is unreadable in the PDF because of a font problem; slides 21–23 give its content and the solution.) The controller coordinates the agents; the blackboard is the shared memory where segments, words and phrases are stored and refined.

A walk-through on sample text. Segmentation agent: splits the input into sentences (“Artificial intelligence is transforming education.” …).

The word creation agent (between them) builds words from segments; the phrase creation agent groups words into grammatically correct phrases: NP “Artificial intelligence”, VP “is transforming”, NP “education”.

The final structured output on the blackboard holds the sentence, its words and its phrases, each written by a different agent.

The component solution: Segmentation, Word Creation and Phrase Creation agents each require the blackboard (reads/writes) and provide their own operation; the controller requires the agents and the blackboard and orchestrates them; the blackboard provides read/write and event services. (The table is garbled in the PDF; the diagram on the right shows the same structure.)

The note answers a common doubt: give the controller a provided interface only if it is active (offers services such as scheduling or policies to others); if it just manages agents and the blackboard internally, it has none.

The sequence solution, top to bottom: the controller initialises the blackboard, then repeats the same cycle for each agent: request (segmentation, word creation, phrase creation) → the agent returns its data → the controller updates the blackboard → the blackboard confirms (dashed feedback arrows).

It ends with CheckCompletion() / CompletionStatus() and Finalize(). In this solution the controller writes to the blackboard on the agents’ behalf; in the scheduling example the agents wrote themselves. Both are accepted variants: what matters is that agents never call each other.

Data flow systems are decomposed around transporting data streams and transforming them on the way to meet application needs.

Worker components perform work on the data.

Transport components move the data.

Worker components abstract the transformations applied before data is forwarded: encryption/decryption, compression/decompression, changing format (binary to XML, raw data to information), enhancing, modifying or storing data.

Transport components abstract how data is moved and controlled. The data-flow pattern studied here is pipes and filters: filters are the workers, pipes the transport.

Data source: produces the input data.

Pipes: carry data from one step to the next.

Filters: process the data (transform, clean, analyse) and pass it on. In the diagram data branches: Filter 1 feeds Filters 2, 3 and 4, which rejoin at Filter 5.

Data sink: the final destination where the processed data is stored or used.

Important: the box-and-line diagram is not UML and hides how pipes really work; in real systems pipes can be function calls, files, queues or sockets.

The four components, formally. Data source: produces the data.

Filter: processes, enhances or modifies the data.

Pipe: connects source → filter, filter → filter, and filter → sink.

Data sink: consumes the data.

Example 1: a language processor (compiler or interpreter) is the classic pipes-and-filters system: source code flows through lexical analysis, parsing, code generation and optimisation.

Lexical analyser (filter 1): breaks source code into tokens. int x = 5; becomes int, x, =, 5, ;.

Parser: builds a parse tree from the tokens (a declaration node for int x, an initialisation node for = 5). Code generator: turns the tree into machine code or an intermediate form (allocate memory for x, move 5 into it).

Optimizer: makes the code faster or smaller (e.g. one instruction that both reserves and initialises x). In an interpreter pipeline the last filter executes the intermediate form directly instead. The diagram shows that filters are reusable: the same lexer and parser serve both pipelines.

The same pipeline as a UML sequence diagram (“Important: a UML diagram!”). 1: call() feeds input to the lexical analyser.

The parser 2: process()es the tokens into a parse tree and 3: call()s the code generator.

The code generator 4: process()es the tree into code and 5: call()s the optimizer.

The optimizer 6: process()es the code. Here the pipes are simply function calls between filters.

Example 2: software that identifies people automatically. In order: it accesses videos (with audio) from YouTube, detects faces (is there a face?), recognises faces (whose face is it?), and predicts the identity of the individuals.

Each step consumes the previous step’s output, which makes it a pipes-and-filters system; the next slides model it.

The box-and-line view: a big video file enters the YouTube Manager, which prepares it.

Face detection turns the video into data containing only the detected faces.

Face recognition matches the detected faces against known ones.

Identity manager produces the final output, such as an identity report (“Wanted: Joe Developer”). The callout asks the design question: if a better recognition algorithm appears, only that one filter changes.

The box-and-line diagram shows the components but says nothing about how data is transported between filters, i.e. the pipes.

A UML component diagram (next slide) makes the transport explicit.

Here the pipe is the file system: a FileSystemManager component (built on .NET’s FileSystemWatcher) monitors directories and fires an event when a new file appears.

The pipeline components (VideoManager, FaceDetection, FaceRecognition, IdentityManager) each require the IFileSystemPipe interface the manager provides. A filter writes its output as a file; the manager detects it and triggers the next filter. The warning notes this is not the typical pipes-and-filters example but shows how flexible the pattern is.

VideoManager: put(file) places a new video file into the system (message 4).

FaceDetection: register()s with the FileSystemManager at start-up, then, when notified, process()es the video for faces and put(file)s its result.

FaceRecognition: registers, processes the detected faces when notified, and puts the recognised-face data forward.

IdentityManager: registers and, when notified, processes the recognition data to determine identity (the last step: “identity determined!”).

FileSystemManager: the coordinator. Its onFileDetected(file) notifies the registered filter whenever a new or processed file appears, which is what moves data along the pipeline.

Extensibility: add new filters easily (a spam filter). Efficiency: filters can run in parallel. Reusability: filters are reused across systems. Modifiability: add, remove or change filters independently. Security: security filters can be inserted anywhere in the chain. Maintainability: independent filters make updates simple. Trade-off: every boundary needs agreed data formats, and the pattern suits batch-like flows, not interactive ones where the user steers the work midway.

Distributed systems are decomposed into multiple processes that usually collaborate over a network.

Client–server: client-side processes work for users and act as a bridge to a remote server that does the work delegated to it.

Peer-to-peer: peer nodes with similar capabilities collaborate as equals, e.g. music-sharing applications. The pictures contrast a mesh of peers with a star around one server.

Those systems are easy to spot because they are deployed on multiple physical nodes.

With multi-core processors, distributed architecture also applies inside a single machine: work is spread across cores instead of computers.

Examples: Internet systems, web services, file- and music-sharing systems, high-performance computing.

Common patterns: client–server (clients request, a central server provides, e.g. browser and web server) and broker.

Peer-to-peer: every node is both client and server, sharing resources with no central server (BitTorrent).

Server: a program or device that provides functionality to other programs or devices, its clients.

Client: hardware or software that accesses a service the server makes available. Many independent clients talk to the server, and clients do not talk to each other.

Deployment diagram (bottom): the PC node runs pc_browser.exe, the mobile node runs mp_browser.exe, and the server node runs web_server.exe (artifacts on nodes).

Clients communicate with the server over HTTP; the server responds with processed data. The box-and-line diagram above shows the same thing as request/response arrows.

Interoperability: clients on different platforms work with servers on different platforms (any browser, any OS).

Modifiability: changes are made once at the server and reach all clients.

Availability: backup server nodes keep the service and data available.

Reusability: server services and data can be reused by different applications.

The main problem: clients are tightly coupled to servers, which becomes complex when services come from many servers in different places.

The client must know the server’s exact IP/URL/protocol, and any server change forces client code updates.

The broker pattern was introduced to remove that coupling.

The broker pattern gives more flexibility between clients and servers in a distributed environment by acting as a mediator between them.

It decreases coupling: one client can transparently use the services of many servers, knowing only the broker.

Comparison: client–server is direct, the client must know the server’s address and protocol, server changes need client updates, simpler but less flexible. Broker goes through middleware, the client knows only the broker, server changes don’t affect clients, more scalable. In short: direct and tight vs. indirect and loose.

The broker coordinates communication between clients and servers: it forwards requests and transmits results and exceptions back.

This makes systems more flexible and interoperable. In the diagram the client relies on Broker 1 for services from Server 1, and Broker 1 can talk to Broker 2 to reach Server 2’s services too.

Client: uses services of one or more servers. Provides nothing; requires the client proxy.

Client proxy: makes remote components look local to the client (transparency). Provides a local service to the client; requires the broker.

Broker: mediates between client and server components. Provides mediation to the client proxy; requires the server proxy.

Server proxy: makes remote components look local on the server side. Provides a local service to the broker; requires the server.

Server: provides the real application services (it may also act as a client of the broker).

Bridge (optional): connects different brokers so they can interoperate.

The client-side proxy decides whether a request can be resolved locally or must be forwarded to the broker.

The pattern separates communication functionality from application functionality: everything about networks and messages sits in the broker and proxies, so clients and servers contain only application logic.

Reading the detailed class diagram:

Client-side proxy

packData(), unpackData(), sendRequest(), return(): marshals requests into messages and results back out.

Broker

registerService(), findServer(), findClient(), forwardRequest(), forwardResponse(): knows where services are and routes messages.

Server-side proxy

packData(), unpackData(), callService(), sendResponse(): calls the real service.

Client / Server / Bridge

The client calls callServer() via the broker API; the server registerService()s and runService()s; the bridge transmits messages between brokers.

Interoperability: clients work with servers on different platforms, and with multiple servers.

Modifiability: server changes are centralised and reach many clients quickly.

Portability: the broker can be ported to new platforms, opening the services to new clients.

Reusability: because brokers handle the system calls, complex services can be reused in other applications.

Data-centered → blackboard.

Data flow → pipes and filters.

Distributed → client–server and broker.

Next: interactive systems (MVC) and hierarchical systems (layered).