Material from: Software Engineering 8, Sommerville

Software Architecture, Shaw and Garlan

ARCHITECTURAL
PATTERNS
Christopher Parnin
(slides from Dr. Eric Wohlstadter, Dr. Gail Murphy, and Dr. Emerson
This work is licensed under a Creative Commons
Attribution-Noncommercial 2.5 Canada License

Murphy-Hill

Learning Goals
You will be able to:
Identify an architecture when you see it
Pick an appropriate architecture for a problem
Compare and contrast architectural choices

Format:
Descriptions
Examples
Consequences

Where Were Going

Architectural Design Goals

Skeleton of system, repositories for designs
Templates for programmers to build systems

Concepts and constraints

Provide framework for how components interact.

Stakeholder communication
Abstract enough to explain to non-experts

System Requirements Affect Architecture

Performance
Minimize communication between components
Reduce resource contention and maximize concurrency

Security
Reduce access paths to critical resources

Safety
Localize safety critical operations in a single module

Availability/Replicability
Provide redundant access paths. Can duplicate components easily.

Maintainability
Reduce dependencies, make components self-contained
Often in conflict with ease of development

Architectural Patterns
An architectural pattern consists of:
a set of component types (e.g. process, procedure) that perform
some function at runtime
a topological layout of the components showing their runtime
relationships
a set of connectors (e.g. data streams, sockets) that mediate
communication among components

Where We At

Data Centered Patterns

When a system can be described as a centralized
data store that communicates with a number of
clients
+ Easy to administer
Hard to track down errors/dependencies
Shared Data

Client
Client

Client

Repository Model Description

Components must exchange information so they
can work together effectively
Data held in central database that is accessible by
all components

Repository Model Example

Repository Model Consequences

+ Short communication links
+ Sub-systems are well modularized
+ Backup, security, access control, and recovery are
mostly contained to the central repository
Sub-systems must agree on common data-format;
makes evolution difficult
Clients may have to poll for changes
Repository may be a bottleneck

Blackboard Description
Analogy: a bunch of experts writing at a whiteboard, observing each
other, writing when their expertise is needed.
Knowledge sources (ks) independently change centralized
blackboard
Control is driven entirely by the state of the blackboard

Blackboard Example
eBay Auctions + eBay mobile for iPhone
(http://pages.ebay.com/mobile/iphone.html)

x
RADARSAT-1 is an earth-observing satellite that was launched
on November 4, 1995. It is used to collect weather and
environment-related data.
RADARSAT-1's mission control system performed operations
that included
(a) translating requests from commercial and
government users into detailed schedules for the spacecraft and
processing facilities
(b) producing and maintaining a schedule of activities for
the spacecraft and its different components; data-reception
stations; and data-processing facilities.
Countdown to Success:Dynamic Objects,GBB, and
RADARSAT-1" by Daniel D. Corkill

 Each of these activities involved planning and co-ordination for

time segments as small as fractions of a second.
Blackboard architecture was chosen to support the required
incremental planning activities and to provide flexible,
opportunistic control.
Generic Blackboard Builder, an application development and
delivery framework for high-performance blackboard-based
applications was used to build components of RADARSAT1's mission control system to handle adaptability issues of the
system.

Countdown to Success:Dynamic Objects,GBB, and

RADARSAT-1" by Daniel D. Corkill

 The modularity of the blackboard-based design, the natural

mapping between the problem domain, blackboard objects, and
KSs, made it easy to integrate the various components of the
system.
The decision to use blackboard architecture resulted in the
completion of the software on schedule and substantial cost
savings. Their costs had dropped to about one third of their
original estimates.

Countdown to Success:Dynamic Objects,GBB, and

RADARSAT-1" by Daniel D. Corkill

Blackboard Consequences
+ Good when solution is non-deterministic
+ When building a new knowledge-source,
notification of events makes implementation
easier
Requires complex infrastructure

Repository vs. Blackboard

Repository uses pull model
Components write data in the repository
Components read data from the repository
+ Easy to implement as a whole
Clients may become complex when polling

Blackboard uses push model

Components register data subscription
Components are notified when data is available
Infrastructure complex
+ Client programming is simplified

Exercise
With the person next to you, give an example of an application where
blackboard would be appropriate, and another where a repository
would be appropriate

Where We At

Call and Return Patterns

Typical control flow imposed by modern
programming languages
Some exceptions, including Prolog, jump
instructions
+ Easy to reason about behavior from static code
Sometimes not flexible enough

Main and Subprogram Description

Modules takes turns executing in a well defined
fashion, controlled by a single main program
Example: Top down sub-routine model
Routine Function Procedure Method
Control starts at the top of a hierarchy and proceeds to
lower levels in the tree
Each routine is blocked waiting for sub-routines to finish
o Synchronous

Main and Subprogram Example

from Sommerville

Main and Subprogram Consequences

+ Easy to program
+ Easy to understand

Performance can suffer without multiple threads

But, multiple threads often creates programming nightmares

Can be hard to extend

Changes to the interface of a routine can affect many callers
Inserting new routines requires change of some existing
routine

Object-Oriented Description
System is decomposed around data
Classes encapsulate data and provide services to
manipulate data
Classes provide well defined interfaces
Control determined by dynamic dispatch.

Object-Oriented Example

from Sommerville

Object-Oriented Consequences
+ Well defined interfaces
Implementation details are easy to change
Data formats can be abstracted by class interfaces

Interface changes break all users of a particular

class

Multiple threads may contend for access to object

data

Layered Model Description

Organize system as a stack of clients and servers
Layers are both clients and servers

Layers are decomposed into increasing levels of

abstraction
Each layer only knows about one other layer

Layered Model Example

Layered Model Consequences

+ Easy to extend system by inserting new layer which
provides same interface

Structuring layers can be difficult as layers may require

services of non-adjacent layers

Performance can suffer since requests must pass

through many layers

Exercise
1. Which architecture would be easier to replicate a central database?
a.repository
b.blackboard
2. Which of the following is a component of the blackboard pattern?
a. routine
b. sink
c. knowledge source
3. What type of architecture does the object-oriented pattern fall under?
a.data centered
b.call and return

Where We At

Data Flow Description

Architectural pattern for stream processing.
A component defines a processing/computational step.
Data flows through components and connections.

Pipe-And-Filter
Components (Filters)
Set of inputs and outputs
Local transformation
Connectors (Pipes)
Facilitate data flow
Constraints
Do not share state

Pipe-And-Filter
Specialization
Pipelines: restricted to linear order
Bounded pipes: restricts data flow size.
Typed pipes: only accept connections for acceptable
types of filters.

Pipe-And-Filter Example
Map Reduce

Batch Sequential Description

Each component completes transformation of input
before passing to output.
A degenerate case of pipe-and-filter where no
streaming occurs.

Batch Sequential Example

A compiler

Data Flow Consequences

+ Supports easy reuse of components
+ Fairly easy to reason about (composition)
+ Easy to maintain by adding components
Some component may have to wait for the output
of the previous pipe to finish
Sometimes difficult to maintain correspondences
between separate streams

Where We At

Event Systems
Execution is controlled by events; a packet coming
in, a button being clicked, etc
Styles
EXPLICIT INVOCATION
IMPLICIT INVOCATION
CLIENT-SERVER
PEER-TO-PEER

Case Study
Tektronix wanted to develop software architecture
for oscilloscopes, which measure and display
traces of electronic signals.

Searching for Architecture

Object-Oriented Model
Represented objects, no overall model to explain
how objects fit together.
Layered Model
Partitioned functionality, but components in layers
needed to interact with each other too much.

Searching for Architecture

Pipe-And-Filter
Allowed interaction with components, but could
allow wrong connections and no UX model.
Modified Pipe-And-Filter
Introduced control interface that parameterized
and controlled connections to and filters.

Searching for Architecture

Specialized Pipe-And-Filter
Almost there, but performance was affected by
copying and duplicating signals for each filter.
Introduced colored pipes which slow/fast pipes,
and allowed data to be read without copying.

And now Robots!

http://www.youtube.com/user/BostonDynamics
http://www.youtube.com/watch?v=5rfsoSLJY04

Robots: a Complex Problem

Robots should:
Balance internal control vs. external control
Respond in real time
Deal gracefully with component failure

Exercise: Architecture Evaluation

Our Criteria (different for different domains):
Coordination of deliberative + reactive behavior
Allow for uncertainty: deal with missing or contradictory
information
Account for danger: maintain integrity of robot, its operators,
and environment
Allow for flexibility: robots frequently require experimentation
and reconfiguration

1.Sketch a layered architecture for a robot

Hybrid Architectures
Most systems are hybrid
Systems can be broken down into sub-systems with
different architectures at different levels of
abstraction

Wrap-Up
You should be able to:
Identify an architecture when you see it
Pick an appropriate architecture for a problem
Compare and contrast architectural choices