CHAPTER 4: PATTERNS AND STYLES IN

SOFTWARE ARCHITECTURE
SESSION II: DATA-CENTERED, DATA-FLOW, AND DISTRIBUTED SYSTEMS

Software Engineering Design: Theory and Practice

by Carlos E. Otero

Slides copyright © 2012 by Carlos E. Otero

For non-profit educational use only

May be reproduced only for student use when used in conjunction with Software Engineering Design:
Theory and Practice. Any other reproduction or use is prohibited without the express written
permission of the author.

All copyright information must appear if these slides are posted on a website for student use.

06/08/2020 Software Engineering Design: Theory and Practice 1

 SESSION’S AGENDA
 Data-Centered Systems
 Overview
 Patterns
 Blackboard

 Data Flow Systems

 Overview
 Patterns
 Pipes-and-Filters

 Distributed Systems
 Overview
 Patterns
 Client Server

 What’s next…
 Distributed systems – Broker Pattern
 Interactive Systems
 Hierarchical Systems

06/08/2020 Software Engineering Design: Theory and Practice 2

 DATA-CENTERED SYSTEMS
 Data-centered systems are systems primarily decomposed around a main central
repository of data. These include:
 Data management component
 The data management component controls, provides, and manages access to the system’s data.
 Worker components
 Worker components execute operations and perform work based on the data.

 Communication in data-centered systems is characterized by a one-to-one bidirectional

communication between a worker component and the data management component.
 Worker components do not interact with each other directly; all communication goes through
the data management component.
Worker 1 Two way Worker 2
communication

Data Manager

Data repository
Manages data

06/08/2020 Software Engineering Design: Theory and Practice 3

 DATA-CENTERED SYSTEMS

 Because of the architecture of these systems, they must consider issues with:
 Data integrity
 Communication protocols between worker and data management
 Transactions and recovery (also known as roll-back)
 Security
Worker 1 Worker 2
1. Communication Protocol
2. Security
1. Communication Protocol
2. Security

Data Manager

1. Transactions and Recovery Data Integrity

2. Security

 A common architectural pattern for data-centered systems is the Blackboard

Pattern.

06/08/2020 Software Engineering Design: Theory and Practice 4

 BLACKBOARD ARCHITECTURAL PATTERN
 Blackboard decomposes systems into components that work around a central data component to
provide solutions to complex problems.
 These components work independently from each other to provide partial solutions to problems using an
opportunistic problem-solving approach.
 That is, there are no predetermined, or correct, sequences of operations for reaching the problem’s
solution.

 The Blackboard architectural pattern resembles the approach a group of scientists would employ to
solve a complex problem.
 Consider a group of scientists at one location using a blackboard (chalkboard, whiteboard, or electronic
blackboard) to solve a complex problem.
 Assume that to manage the problem-solving process, a mediator controls access to the blackboard.
 Once the mediator (or controller) assigns control to the blackboard, a scientist evaluates the current state of
the problem and if possible, advances its solution before releasing control of the blackboard.
 With new knowledge obtained from the previous solution attempt, control is assigned to the next scientist
who can further improve the problems’ state.
 This process continues until no more progress can be made, at which point the blackboard system reaches
a solution.

 This behavior is prevalent in expert systems, therefore, the Blackboard architectural pattern is a
good choice for depicting the logical architecture of expert systems.
06/08/2020 Software Engineering Design: Theory and Practice 5
 BLACKBOARD ARCHITECTURAL PATTERN

Agents cannot
access blackboard The actual blackboard. In this
until access is example, this is the data
granted by repository Controller
controller.

Agent 4 waits for his turn

Agent 1
Agent 3 waits for his turn

Access to the blackboard has

been granted to Agent 1

Agent 2 waits for his turn Agent 1 advances the solution!

06/08/2020 Software Engineering Design: Theory and Practice 6

 BLACKBOARD ARCHITECTURAL PATTERN

 Consider the Students’ Scheduling System .

Controller

Agents

Blackboard

06/08/2020 Software Engineering Design: Theory and Practice 7

 BLACKBOARD ARCHITECTURAL PATTERN

Client requests a
schedule

Controller grants schedule access

The StudentHistory agent
to the StudentHistory agent
retrieves the data

The StudentHistory agent

Controller grants schedule access modifies the schedule and
to the CourseOfferings agent stores the results back

This note provides

important information!
The CourseOfferings agent
Controller grants schedule retrieves, modifies, and
access to the WorkSchedule stores the schedule back
agent

Client receives an
optimized schedule

06/08/2020 Software Engineering Design: Theory and Practice 8

 BLACKBOARD ARCHITECTURAL PATTERN

 Quality properties of the Blackboard architectural pattern include the ones

specified below.

 An important aspect of the Blackboard and any other architectural pattern

is their deployment aspect (i.e., the deployment view). For example, It is
not easily determined from the logical view where each agent or
blackboard component reside.
 Depending on their location, Blackboard can have increased complexity when
managing communication between agents, controller, and blackboard.

06/08/2020 Software Engineering Design: Theory and Practice 9

 DATA FLOW SYSTEMS
 Data flow systems are decomposed around the central theme of transporting data (or data streams) and
transforming the data along the way to meet application-specific requirements.
 Typical responsibilities found in components of data-flow systems include:
 Worker components, those that perform work on data
 Transport components, those that transporting data

 Worker components abstract data transformations and processing that need to take place before
forwarding data streams in the system, e.g.,
 Encryption and decryption
 Compression and decompression
 Changing data format, e.g. ,from binary to XML, from raw data to information, etc.
 Enhancing, modifying, storing, etc. of the data

 Transport components abstract the management and control of the data transport mechanisms, which
could include:
 Inter-process communication
 Sockets, serial, pipes, etc.
 Intra-process communication
 Direct function call, etc.

 An example of an architectural pattern for data flow systems is the Pipes-and-Filters.

06/08/2020 Software Engineering Design: Theory and Practice 10

 PIPES-AND-FILTERS ARCHITECTURAL PATTERN
 Pipes-and-Filters is composed of the following components:
 Data source
 Produces the data
 Filter
 Processes, enhances, modifies, etc. the data
 Pipes
 Provide connections between data source and filter, filter to filter, and filter to data sink.
 Data Sink Not an UML diagram!
 Data consumer

Data is moved and processed

Pipes used to move the data! along the way until it reaches
its destination, the Data Sink.

Data source produces the data Important:

The abstractions used in the box-and-
line diagram above for Pipes can be
deceiving, since they really do not
Filters work on the data! convey the real identity of these
mechanisms!

06/08/2020 Software Engineering Design: Theory and Practice 11

 PIPES-AND-FILTERS ARCHITECTURAL PATTERN

 A common example for the Pipes-and-Filters pattern:

 Architecture of a Language Processor (e.g., compiler, interpreter)

Important:
Not a UML Diagram!
Lexical Analyzer Parser Code Generator Optimizer

Parser
Lexical analyzer
produces parse Generates code, e.g.,
produces tokens Optimizes code
trees machine language
Reused
component
It would be cool to build
an interpreter… I know,
let’s reuse the
components that we
already have!

Lexical Analyzer Parser Optimizer Interpreter

Lexical analyzer Parser

produces tokens produces parse Optimizes
trees Run the
interpreted program
form of the
program

06/08/2020 Software Engineering Design: Theory and Practice 12

 PIPES-AND-FILTERS ARCHITECTURAL PATTERN
Filters
Important:
A UML Diagram!

Lexical Code Optimizer

Parser
Analyzer Generator

In this example,
the Pipes are
simply function
calls!

06/08/2020 Software Engineering Design: Theory and Practice 13

 PIPES-AND-FILTERS ARCHITECTURAL PATTERN
 Consider software that houses algorithms for automatically determining the identity of an individual:
 The software access videos (with audio) from You Tube
 The software detects faces of individuals in the video
 Face detection is used to determine if a face is in the video
 The software recognizes faces speech from the video
 Face recognition is used to determine the identity of the person from the detected face.
 Based on detection and recognition, the software predicts the identity of individuals in the video

 Using the pipes and filters architecture, the logical structure of the system can be modeled as follows:

Important:
Consider what would
happen if a better algorithm
Transformed data containing only the for recognition is
Big video file!
information from detected faces! discovered?
Transformed data containing only the
results from the recognition process,
e.g., a report of identity!

Wanted!

Youtube Manager Face Detection Face Recognition Identity Manager

Joe Developer

Wanted!

06/08/2020 Software Engineering Design: Theory and Practice 14

 PIPES-AND-FILTERS ARCHITECTURAL PATTERN
 In the previous example, the box-and-line diagram was useful for visualizing the
components in the system, however, it conveyed nothing about how data is transported
from one Filter to the next, i.e., the Pipes.
 Consider the following UML component for the same system
This component may reuse existing
mechanisms to facilitate data movement,
for example, the .NET FileSystemWatcher.
In this system, data is moved through <<component>>
the File System using a mechanism FileSystemManager This interface encapsulates
that relies on monitoring of new files! the FileSystemWatcher and
provides other services for
creating, deleting, reading
IFileSystemPipe IFileSystemPipe IFileSystemPipe IFileSystemPipe and writing files.

<<component>> <<component>> <<component>> <<component>>

VideoManager FaceDetection FaceRecognition IdentityManager

Warning: These components require monitoring of directories from the

This is not the typical example that you File System Manager. When a new file is detected, the File
would find for Pipes-and-Filters.
System Manger fires an event, indicating that a new file has been
However, it displays the inherent flexibility
received, which triggers some processing by the Filter
present when employing architectural
components.
patterns.

06/08/2020 Software Engineering Design: Theory and Practice 15

 A more detailed example of the
message exchanges in the example

: VideoManager : FaceDetection : FaceRecognition : IdentityManager : FileSystemManager

Register with the file system manager

This triggers
Youtube video file found!
and event!
Transport the file to the next
component via the file system.

Notify anyone
registered for
monitoring of
Do work using the data from
this directory
the file, save the results on the
file system so that the process
can repeat again with the
next component / filter.

Identity
determined!

06/08/2020 Software Engineering Design: Theory and Practice 16

 Assume now that unlike the
previous example, the Video Consider the Pipes-and-Filters
component now interfaces with modeled this way
a camera for real-time video
feed!
<<component>>
<<component>> <<component>> Other Pipes
YoutubeManager
VideoManager FaceRecognition and Filters in
the System

IVideoPipe
Filter Component
Pipe Filter Component
Interface
When modeled this way, there are
implications about the internal
structure of these components!
For example, see below

Similarly, since Pipes-and-Filters specify the separation

between pipes and filters, there is an implication about the Provided interface to transport
existence of both pipe and Filter component inside the Video the data stream to the next
Manager component
<<component>>
FaceDetection

<<component>>
VideoManager <<delegate>>
<<delegate>> <<component>>
TransportComponent
IVideoPipe IStreamPipe IStreamPipe

Pipe
<<component>>
WorkerComponent
Filter

06/08/2020 Software Engineering Design: Theory and Practice 17

 PIPES-AND-FILTERS ARCHITECTURAL PATTERN

 Quality properties of the Pipes-and-Filters architectural pattern include the

ones specified below.

06/08/2020 Software Engineering Design: Theory and Practice 18

 DISTRIBUTED SYSTEMS
 Distributed systems are decomposed into multiple processes that (typically) collaborate
through the network.
 These systems are ubiquitous in today’s modern systems thanks to wireless, mobile, and internet
technology.
 In some distributed systems, one or more distributed processes perform work on behalf of client users
and provide a bridge to some server computer, typically located remotely and performing work
delegated to it by the client part of the system.
 Other distributed systems may be composed of peer nodes, each with similar capabilities and
collaborating together to provide enhanced services, such as music-sharing distributed applications.
 These types of distributed systems are easy to spot, since their deployment architecture entails
multiple physical nodes.
 However, with the advent of multi-core processors, distributed architectures are also relevant to
software that executes on a single node with multiprocessor capability.

 Some examples of distributed systems include:

 Internet systems, web services, file- or music-sharing systems, high-performance systems, etc.

 Common architectural patterns for distributed systems include:

 Client-Server Pattern
 Broker Pattern
06/08/2020 Software Engineering Design: Theory and Practice 19
 CLIENT-SERVER PATTERN

06/08/2020 Software Engineering Design: Theory and Practice 20

 CLIENT-SERVER PATTERN

 Quality properties of the Client-Server architectural pattern include the

ones specified below.

06/08/2020 Software Engineering Design: Theory and Practice 21

 WHAT’S NEXT…

 In this session, we presented fundamentals concepts of data-centered , data

flow, and distributed systems, together with essential architectural patterns
for these systems, including:
 Blackboard
 Pipes-and-Filters
 Client-server

 In the next session, we will continue the discussion of distributed systems

and present in depth two other types of systems (i.e., Interactive and
Hierarchical) together with architectural patterns, including:
 Model-View-Controller
 Layered
 Main program and subroutine

06/08/2020 Software Engineering Design: Theory and Practice 22