Transcript Review of Course/Syllabus

Software Architecture - 1
July 21, 2015
All Architectural Patterns

Data Flow Architecture
– Batch Sequential
– Pipe and Filter
– Process Control

Data Centered Architecture
– Repository
– Blackboard

Hierarchical Architecture
–
–
–
–
Main-subroutine
Master-slave
Layered
Virtual Machines
All Architectural Patterns

Implicit Asynchronous Communication
Architecture
– Non-buffered event-based Implicit Invocation
– Buffered messaged-based

Interaction-Oriented Architecture
– Model-View-Controller (MVC)
– Presentation-Abstraction-Control (PAC)

Distributed Architecture
– Client-server
– Broker
– Service-oriented architecture (SOA)

Component-based Architecture
Architectural Patterns - 1

Data Flow Architecture
– Batch Sequential
– Pipe and Filter
– Process Control

Data Centered Architecture
– Repository
– Blackboard

Hierarchical Architecture
–
–
–
–
Main-subroutine
Master-slave
Layered
Virtual Machines
Data-Flow Architecture

Overview
– A series of transformation on successive sets of data
– Data sets and operations are independent of each other.

Three subcategories
– Batch Sequential
– Pipe and Filter
– Process Control
Batch Sequential

Overview
– A transformation subsystem or module cannot start its process
until the previous module completes its computation
– Data flow carries a batch of data as a whole from a module to
next
– series of transformation on successive sets of data
– Data sets and operations are independent of each other.

Applications
– Business data processing in banking and utility billing
Batch Sequential
Validate
D a ta flo w
Sort
data
transformation
U pdate
R eport
Batch Sequential
Rejected
transaction
-123 U
222 U
111 I
333 D
-123 U
Sorted
transaction
Validated
transaction
Transaction File
Validate
222 U
111 I
333 D
Generate Report
sort
100 ---111 ---200 ---222 ---444 ----
Reports
Updated
Master file
111 I
222 U
333 D
Update
100 --200 --222 --333 --444 ---
Master file
Batch Sequential

Using Unix Shell Script
(exec)
(exec)
(exec)
(exec)
validate trans validTrans invalids
sort validTrans sortedTrans
update master sortedTrans
generateReports master report1 report2
Batch Sequential

Applicable Domains
– Data are batched
– Intermediate files are sequential files
– Each module reads input files and writes output files

Benefits
– Simple division on subsystems
– Each subsystem can be stand-alone program

Limitations
– Implementation requires external control
– No interactive interface
– Concurrency not supported
Pipe and Filter

Overview
–
–
–
–
–
–
–
–
A system consists of data source, filters, pipes, and data sinks
Connections between components are data streams
Each data stream is a first-in-first-out buffer
Each filter reads data from its input stream, processes it, and
writes it over a pipe for next filter to process
A filter processes data once received, does not wait until the
whole data is received
A filter only knows its connected pipes, does not know what
are at the other end of the pipe
Filters are independent of each other
Pipes and filters may run concurrently
Pipe and Filter

Active filter
– Pulls in (read) data from upstream and pushes out (write) data
to downstream

Passive filter
– It lets connected upstream pipes push (write) data to it and
lets downstream pipes to pull (read) data from it
Pipe and Filter
data source:
Data Source
pipe:
pipe
filter1:
Filter
filter2:
Filter
data sink:
Data Sink
read
Filter1
W
Filter2
R
write
Data Source
Filter1
Filter2
pipe
Data Sink
Pipe and Filter
Hello
World
Sort &
Count
Filter
H 1
L 2
HL
Match
(H,L)
Filter
LO W
Upper case
Conversion
Filter
orld
Pipe and Filter
Pipe and Filter

Applicable Domains
– System can be broken into a series of steps over data streams
– Data format in the streams is simple, stable and adaptable
– Significant amount can be pipelined for performance

Benefits
– Concurrency: all filters may operate at the same time
– Reusability: filters are easy to plug and play

Limitations
– No user interaction
– Difficult to configure
– Concurrency not supported
Data-Centered Architecture


Overview
– A centralized data store is shared by all surrounding
software components
– The surrounding components are normally
independent each other
– Significant amount can be pipelined for performance
Two categories:
– Repository
– Blackboard
Repository

Overview
– Data store is passive
– Clients of the data store are active
– Supports interactive data processing
– Clients control the computation and flow of logic
Repository
Repository
Repository
Repository

Applications
– Suitable for large complex information systems where many
software component clients need to access it in different ways.
– Data transactions to drive the control flow of computation.

Benefits:
– Easy to backup and restore.
– Easy to add new software components
– Reduce the overhead of transient data

Limitations:
– Centralized repository is vulnerable to failure compared to
distributed repository with data replication.
– High dependency between the structure of the data store and
its agents.
Blackboard


Overview
– Data store is active
– Clients are passive
– Clients are also called knowledge sources, listeners,
and subscribers
Two partitions
– Blackboard: store data (hypotheses and facts)
– Knowledge sources: domain-specific knowledge is
stored
– Controller: initiate the blackboard and knowledge
sources and take overall supervision
Blackboard

Collaboration
– Knowledge sources register with the blackboard
in advance in a publish/subscribe fashion
– Data changes in the blackboard trigger one or
more matched knowledge sources to continue
processing
– Data changes may be caused by new deduced
information or hypothesis results by knowledge
sources
– Knowledge sources normally do not interact with
each other
Blackboard
Blackboard
Blackboard – example 1

Animal identification System(KBS).
– The knowledge is represented as production rules.
R1: IF animal gives milk THEN animal is mammal
R2: IF animal eats meat THEN animal is carnivore
R3: IF animal is mammal AND animal is carnivore AND
animal has tawny color AND animal has black stripes
THEN animal is tiger
– A set of facts
F1:
F2:
F3:
F4:
animal eats meat
animal gives milk
animal has black stripes
animal has tawny color
Blackboard – example 1

Forward reasoning
– New knowledge is added to blackboard
N1: animal is carnivore (from R2 + F1)
N2: animal is mammal (from R1 + F2) IF animal gives milk
THEN animal is mammal
N3: animal is tiger (R3 + N3 + N2 + F3 + F4)
Blackboard – example 2

Travel Consulting System
– Participating agents

Airline, hotel reservation, auto rental, and attraction agents
– Blackboard

Budget, available time, locations, etc
– Clients of the system


Clients fill out a initial travel form
The system will respond with many optional plans for client
to choose
Blackboard – example 2

Travel Consulting System
– Process






A client submits a request
The system stores all the data in the blackboard
The blackboard makes a request to the air agent
Once air reservation data is returned and stored in
blackboard, the change triggers hotel, auto rental,
attraction agents for a travel plans under budge and time
Client chooses one of the plan
The system triggers the billing process
Blackboard

Applications
– Suitable for open-ended and complex problems (AI)
– The problem spans multiple disciplines, each of them has
complete different knowledge expertise
– Partial, or approximate solution is acceptable to the problems.

Benefits:
– Easy to add new or update existing knowledge source.
– Concurrency: all knowledge sources can work in parallel
– Reusability of knowledge source agents.
Blackboard

Limitations:
– Tight dependency between the blackboard and knowledge
source,
– Difficult to make a decision when to terminate reasoning, since
only partial or approximated solutions are expected
– Synchronization of multiple agents is an issue.
– Debugging and testing of the system is a challenge.
Hierarchical Architecture

Overview
– The software system is decomposed into logical modules (subsystems) at different levels in the hierarchy.
– Modules at different levels are connected by explicit or implicit
method invocations.
– A lower level module provides services to its adjacent upper
level modules
– Upper level modules invoke the methods or procedures in
lower level.

Four categories
–
–
–
–
Main-subroutine
Master-slave
Layered
Virtual Machines
Main-subroutine

Overview
– The main-subroutine architecture has dominated the
software design methodologies for a very long time.
– Reuse the subroutines and have individual
subroutines developed independently.
– Using this style, a software system is decomposed
into subroutines hierarchically refined according to
the desired functionality of the system.
– Refinements are conducted vertically until the
decomposed subroutine is simple enough to have its
sole independent responsibility, and whose
functionality may be reused and shared by multiple
callers above.
Main-subroutine
Main-subroutine

Data Flow Diagram to Main-subroutine
– Transform flow: incoming flow feeds data in an
external format, and the data is then transformed to
another format, and then the outgoing flow carries
the data out
– Transaction flow: evaluates its incoming data, and
decided which path to follow among many action
paths.
– A transform flow is mapped by a controlling module
for incoming, transform and outgoing information
processing.
– The transaction node becomes a dispatcher control
module that controls all subordinate action modules
Main-subroutine
Main-subroutine

Applicable Domains
– Data are batched
– Intermediate files are sequential files
– Each module reads input files and writes output files

Benefits
– Easy to decompose the system based on the definition of the
tasks in a top-down refinement manner

Limitations
– Globally shared data in classical main-subroutines introduces
vulnerabilities.
– Tight coupling may cause more ripple effects of changes as
compared to OO Design.
Master-slave

Overview
– A variant of the main-subroutine architecture style that
supports fault tolerance and system reliability.
– Slaves provide replicated services to the master, and the
master selects a particular result among slaves by certain
selection strategy.
– The slaves may perform the same functional task by different
algorithms and methods or totally different functionality.
Master-slave
Master-slave

Applicable Domains
– Software systems where reliability is critical.
Layered Architecture

Overview
– The system is decomposed into a number of higher
and lower layers in a hierarchy
– Each layer consists of a group of related classes that
are encapsulated in package, in a deployed
component, or as a group of subroutines in the
format of method library or header file.
– Also, each layer has its own sole responsibility in the
system.
– A request to layer i +1 invokes the services provided
by the layer i via the interface of layer i.
– The response may go back to the layer i +1 if the
task is completed; otherwise layer i continually
invokes services from the layer i -1 below.
Layered Architecture
Layered Architecture
Layered Architecture
Layered Architecture
FTP
TCP
FTP protocol
TCP protocol
FTP
TCP
IP protocol
IP
IP
Ethernet protocol
Ethernet
Ethernet
Physical connection
Layered Architecture

Applicable Domains
– Any system that can be divided between the application
specific portions and platform specific portions .
– Applications that have clean divisions between core services,
critical services, user interface services, etc.

Benefits
– Incremental development based on levels of abstraction.
– Enhanced independence of upper layer to lower layer as long
as their interfaces remain unchanged.
– separation of the standard interface and its implementation.
– Component-based technology may be used to implement the
layered architecture; this makes the system much easier to
allow for plug-and-play of new components.
– Promotion of portability: each layer can be an abstract machine
deployed independently.
– Easy to decompose the system based on the definition of the
tasks in a top-down refinement manner
Layered Architecture

Limitations
– Lower runtime performance since a client’s request or a
response to client must go through potentially several layers.
There are also performance concerns on overhead on the data
marshaling and buffering by each layer.
– Many applications cannot fit this architectural design.
– Breach of interlayer communication may cause deadlocks and
“bridging” may cause tight coupling.
– Exceptions and error handling is an issue in the layered
architecture, since faults in one layer must propagate upwards
to all calling layers.
Virtual Machine

Overview
– A virtual machine is built up on an existing system
and provides a virtual abstraction, a set of
attributes, and operations.
– In most cases, we find that a virtual machine
separates a programming language or application
environment from a execution platform.
– Some people say that a virtual machine looks like
emulation software.
Virtual Machine
Virtual Machine
Virtual Machine

Applicable Domains
– Suitable for solving a problem by simulation or translation if
there is no direct solution.
– Sample applications include interpreters of microprogramming,
XML processing, script command language execution, rulebased system execution, Smalltalk and Java interpreter typed
programming language

Benefits
– Portability and machine platform independency.
– Simplicity of software development.
– Simulation for disaster working model.

Limitations
– Slow execution of the interpreter due to the interpreter nature.
– Additional overhead due to the new layer.