CSSE 377 Software Architecture and Design 2
Steve Chenoweth, Rose-Hulman Institute
Week 2, Day 4, Thursday, Sep 16, 2011
Architectural Styles 2
Left – Model for the “repository” style of
architecture is a warehouse. Half the battle is
designing it so that the same lift truck can
access anything you might need. The other half,
perhaps, is knowing where that is! Fisheye
image from www.moodleman.net/archives/202 .
Today


HW 2 – Tim will post HW comments in Angel dropbox.
More on arch styles – this


Bonus: a few examples of possible questions on the next
biweekly quiz!
Project 2 –


Time to work on Project 2 in class
11:55 PM – File a spreadsheet showing the “availability” of the
part of the system you stressed, and how much you predict you
can improve it. Also turn in your journal with a discussion of that
spreadsheet – how you decided on the numbers, especially.
2
Acknowledgements

Some of the material in
these slides is taken from
“An Introduction to
Software Architecture” by
Garlan and Shaw.
3
Arch styles, continuing…
Garlan & Shaw’s TOC:


Quick review of
yesterday’s styles
New styles for today:





Repository
Interpreter
Distributed Processes
Domain Specific
State Transition Systems
… and 1 more example
4
Review from Yesterday
Call and Return
Main
One
Two
Foo
Three
Bar
5
Review from Yesterday
Data Abstraction (Object
Oriented)
6
Review from Yesterday
Implicit Invocation (Callback)
Register interest in events
Event 1
Event 2
Event 3
...
Foo
Notification of events
Bar
Announcement of events
Example implicit invocation biweekly quiz question:
1. Why does “filters not knowing their neighbors” imply easy evolution?
7
Review from Yesterday
Pipe and Filter
Example pipe-and-filter biweekly quiz questions:
1. What does “often leads to batch processing” mean?
2. Suppose this whole system ran in one computer, and passed
large images from filter to filter for processing. How would
you modify its operation to save memory?
8
Review from Yesterday
Layered
U
p
C
v
Example layered system biweekly quiz question:
1. Suppose you discover that the “Useful system” level has to communicate
directly with the “core level” to handle errors. What would you need to do
to be sure doing this didn’t mess up your system design?
9
New!
Repositories (Database or Blackboard)
D
C
10
Repositories
Repository Properties

Components:




Database: input stream selects processes
Blackboard: State of central data structure selects
processes



Central data structure
Independent computational elements
Used for finding nondeterministic solutions
Has “knowledge base” vs DB at its center
Invariant: decisions are based on data on the shared
blackboard
Today’s quiz – Q 1
11
Repositories
Repository Advantages/
Disadvantages

Similar to Implicit Invocation style:
 Knowledge
sources don’t know ID’s, but
 Control is driven by the blackboard

Context is important for reasoning
 Usually
complex interpretation is the goal
12
Repositories
Repository – A Blackboard Example





Hearsay II (in Garlan & Shaw’s
article)
Speech recognition
Input stream – speech signal
Blackboard – hypotheses
about what was being said
Independent computing
elements – opportunistically
tried to reach higher level
conclusions – like “If these
words say ‘Welcome to Terre
Haute.” then that could be a
coherent sentence.
Hearsay II’s blackboard architecture – from
www.cs.cmu.edu/.../Soft_Arch/base.105.html .
13
Repositories
Additional uses for blackboards








Breaking complex cryptographic codes
Sensory interpretation and analysis (such as
computer vision)
Command and Control Systems
Surveillance Systems
Workflow Processing
Case-based reasoning
Symbolic learning
Data Fusion
14
Interpreters
Interpreter
15
Interpreters
Interpreter Properties

Components:
 Interpretation engine
 Memory containing pseudo-code
 Control state of interpretation engine
 Current state of program being simulated

Connectors:
 Closely
bound, with direct procedure calls and shared
state.

Interpreter examples – See PLC!
 Lisp

and Scheme, etc.
Invariant? Details of the data manipulation are
hidden by the high-level language.
Today’s quiz – Q 2
16
Interpreters
Interpreters –
what you get




Binary instructions for a virtual machine, often called
bytecode, as is done in Lua, Python, Ruby, Smalltalk,
and many other systems (the approach was popularized
in the 1970s by the UCSD P-system and UCSD Pascal)
A tree-like representation of the original program, such
as an abstract-syntax tree, as is done for many prototype
or educational interpreters
A tokenized representation of the source program,
similar to Tcl
The characters of the source program, as was done in
MINT and TRAC
17
Interpreters
Interpreter Advantages/
Disadvantages
Superb end-user programmability and
maintainability; supports dynamically
changing capabilities.
 Slower than “raw code” doing the same
thing.

18
Distributed Processes
Distributed Processes


SAP, as an example:
Each server has a
“dispatcher” and a number
of work processes


These vary, depending on
resource needs
E.g., one may have only
“dialog processes” and
another may have just
“background processing”.
19
Distributed Processes
Distributed Processes

Often described in terms of their topology:
 ring
 star

Sometimes described in terms of communication
protocols:
 client/server
 peer-to-peer
 Heartbeat

Invariant? Physical isolation of functions goes
with separation of responsibilities
20
Distributed Processes
Distributed Processes
Advantages/
Disadvantages


Inherently flexible and reliable
Can be slow instead of fast!
 Use
data close to its source, or batch it
 Keep “conversations” short

Maintenance of individual parts
 What

happens when you change 1 interface?
Reliability
 Minimize
the number of transactions
21
Distributed Processes
Distributed Process
Example – Client/Server
Like Web browser connected to a server…
 What are good & bad features of that?

PC
Client
Database
Servers
Gets requested
data
Application
Servers
Web
Servers
Each doing individual tasks
Runs major
applications
Hands out
Web pages
PC
Client
A typical 4-tiered client-server system
Clients “request services,” Servers “respond”.
22
Distributed Processes
Distributed Process
Example – Cloud
(peer-to-peer)
Issues –
 Achieving
scalability via
distribution
 Achieving
availability via
duplication
 What’s “stateless
vs stateful”
From “Building cloud-ready, multicore-friendly
applications, Part 1: Design principles,” at
http://www.javaworld.com/javaworld/jw-032009/jw-03-multicore-and-cloud-ready1.html?page=4.
Today’s quiz – Q 3
23
Domain-Specific Arch
Domain-Specific Styles

The
prototypical
example of a
refined style –
transaction
processing
using a credit /
debit card:
24
Domain-Specific Arch
Domain-Specific Styles
Specific to a family of systems -- a product
line
 Some components are common, but may
be implemented in different ways
 Connections between common
components are preserved across family

25
Domain-Specific Arch
Domain-Specific Example Transaction processing systems


Used in banking, retail, loading docks, etc.
Domain idea is that some activity of real value
occurs and needs to be recorded. Usually,
assets change hands:
 You get money at a bank machine
 You buy an iTune for your iPod
 You checkout your groceries at Kroger’s
 60 refrigerators get loaded onto your
store’s truck at the manufacturer’s
warehouse
Image from www.handiramp.com/dock_equipment.htm .
26
Domain-Specific Arch
Domain-Specific Example Transaction processing systems
What quality attributes are important?




Performance – usually impacts productivity or customer
patience.
Reliability – different meaning. Want all transactions to
be “atomic.”*
Usually are distributed systems, with parts owned by
different organizations.
Invariant: Guaranteed completion or roll-back of
transactions
* Famously, we want all the ACID properties in transactions: Atomicity, Consistency,
Isolation and Durability. See, e.g., http://en.wikipedia.org/wiki/ACID.
Today’s quiz – Q 4
27
Domain-Specific Arch
Domain-Specific Example Transaction processing systems

Example – Buying groceries at Kroger’s:
PIN Pad
Gets VISA
data
Scanner
POS
Register
Store
Tracks item-level
sales
Records
transaction
Scans
groceries
In-store
processor
Supplies item info to POS,
Updates inventory system
POS = Point of Sale
Kroger’s
Inventory
system
VISA
Authorizes
payment
Kroger image from compulsivec.wordpress.com/2007/03/ .
28
State-Transition Sys
State Transition Systems


Remember formal
methods?
Here’s where a
state diagram IS
the design!
29
State-Transition Sys
State Transition Systems
Set of states as components
 Set of transitions between states, as
connectors

 Often
built on hardware “events”
Good style for reactive systems
 Invariant: The various “states” defined
determine what can be done there.

30
State-Transition Sys
State Transition System
Example – Process Control

Use feedback or feedforward to control a
process:
Diagram from http://en.wikipedia.org/wiki/Feedback. Feedback image from
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6302Feedback-SystemsFall2002/CourseHome/, an MIT open course on
feedback systems
31
Today’s quiz – Q 5
Examples
Again, taken from Garlan &
Shaw’s Case Studies section.
Compiler – Pipe and Filter

A first try at compiler architecture – hand off the
data from one step to the next, in “passes.”
33
Compiler – Modified Pipe and Filter

But the steps all use the common Symbol Table
built during compilation, so need to have that
large, shared area to update.
34
Compiler – Repository

And more
improvements occur
when the steps can
interact, using rules to
guide decisions …


Like whether you are
trying to make a single
block of object code
out of one segment of
source code.
Which leads to more of
a repository style
architecture.
35