sw architecture 1

8/3/2019 Sw Architecture 1

1/52

Software Architecture - 1

May 1, 2012


2/52

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


3/52

All Architectural Patterns

Implicit Asynchronous CommunicationArchitecture 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


4/52

Architectural Patterns - 1

Data Flow Architecture Batch Sequential Pipe and Filter

Process Control Data Centered Architecture

Repository Blackboard


Main-subroutine Master-slave Layered Virtual Machines


5/52

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


6/52

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


7/52

Batch Sequential

Validate Sort Update Report

data

transformation

Data flow


8/52

Batch Sequential

222 U111 I

333 D-123 U

Validate

222 U

111 I333 D

sort

111 I

222 U333 D

Update100 ----111 ----200 ----

222 ----444 ----

100 ---

200 ---222 ---

333 ---444 ---

Generate Report

Sortedtransaction

Validatedtransaction

UpdatedMaster file

Rejectedtransaction

-123 U

Master file

Reports

Transaction File


9/52

Batch Sequential

Using Unix Shell Script(exec) validate trans validTrans invalids

(exec) sort validTrans sortedTrans

(exec) update master sortedTrans

(exec) generateReports master report1 report2


10/52

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


11/52

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, andwrites it over a pipe for next filter to process

A filter processes data once received, does not wait until thewhole 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


12/52

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 andlets downstream pipes to pull (read) data from it


13/52

Pipe and Filter

data source:

Data Sourcefilter1:

Filter

pipe:

pipefilter2:

Filter

data sink:

Data Sink

R

write

W

read

Filter1

Data Source Filter1 Filter2 Data Sink

pipe

Filter2


14/52

Pipe and Filter

H 1

L 2

HL LO W

Upper case

Conversion

Filter

orld

Match

(H,L)

Filter

HelloWorld

Sort &

Count

Filter


15/52

Pipe and Filter


16/52

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


17/52

Data-Centered Architecture

OverviewA centralized data store is shared by all surrounding

software components

The surrounding components are normallyindependent each other Significant amount can be pipelined for performance

Two categories: Repository

Blackboard


18/52

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


19/52

Repository


20/52

Repository


21/52

Repository


22/52

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 andits agents.


23/52

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


24/52

Blackboard

Collaboration

Knowledge sources register with the blackboardin advance in a publish/subscribe fashion

Data changes in the blackboard trigger one ormore matched knowledge sources to continueprocessing

Data changes may be caused by new deducedinformation or hypothesis results by knowledge

sources Knowledge sources normally do not interact with

each other


25/52

Blackboard


26/52

Blackboard


27/52

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 ANDanimal has tawny color AND animal has black stripesTHEN animal is tiger

A set of factsF1: animal eats meatF2: animal gives milk

F3: animal has black stripes

F4: animal has tawny color


28/52


Forward reasoning

New knowledge is added to blackboardN1: animal is carnivore (from R2 + F1)

N2: animal is mammal (from R1 + F2) IF animal gives milkTHEN animal is mammal

N3: animal is tiger (R3 + N3 + N2 + F3 + F4)


29/52


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


30/52


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 inblackboard, 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


31/52

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.


32/52

Blackboard

Limitations: Tight dependency between the blackboard and knowledge

source,

Difficult to make a decision when to terminate reasoning, sinceonly partial or approximated solutions are expected

Synchronization of multiple agents is an issue.

Debugging and testing of the system is a challenge.


33/52


Overview The software system is decomposed into logical modules (sub-

systems) 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


34/52

Main-subroutine

Overview The main-subroutine architecture has dominated the

software design methodologies for a very long time.

Reuse the subroutines and have individualsubroutines developed independently. Using this style, a software system is decomposed

into subroutines hierarchically refined according tothe desired functionality of the system.

Refinements are conducted vertically until thedecomposed subroutine is simple enough to have itssole independent responsibility, and whosefunctionality may be reused and shared by multiplecallers above.


35/52

Main-subroutine


36/52

Main-subroutine

Data Flow Diagram to Main-subroutine Transform flow: incoming flow feeds data in an

external format, and the data is then transformed toanother format, and then the outgoing flow carriesthe data out

Transaction flow: evaluates its incoming data, anddecided which path to follow among many actionpaths.

A transform flow is mapped by a controlling modulefor incoming, transform and outgoing informationprocessing.

The transaction node becomes a dispatcher controlmodule that controls all subordinate action modules


37/52

Main-subroutine


38/52

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.


39/52

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 certainselection strategy.

The slaves may perform the same functional task by differentalgorithms and methods or totally different functionality.


40/52

Master-slave


41/52

Master-slave

Applicable Domains Software systems where reliability is critical.


42/52

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 thatare encapsulated in package, in a deployedcomponent, or as a group of subroutines in theformat of method library or header file.

Also, each layer has its own sole responsibility in thesystem.

A request to layer i +1 invokes the services providedby the layer i via the interface of layer i.

The response may go back to the layer i +1 if thetask is completed; otherwise layer i continuallyinvokes services from the layer i -1 below.


43/52



44/52



45/52



46/52

FTP

TCP

IP

Ethernet

FTP

TCP

IP

Ethernet

TCP protocol

IP protocol

Physical connection

Ethernet protocol

FTP protocol



47/52


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 thelayered architecture; this makes the system much easier toallow for plug-and-play of new components.

Promotion of portability: each layer can be an abstract machinedeployed independently.

Easy to decompose the system based on the definition of thetasks in a top-down refinement manner


48/52


Limitations Lower runtime performance since a clients 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.


49/52

Virtual Machine

OverviewA virtual machine is built up on an existing system

and provides a virtual abstraction, a set ofattributes, and operations.

In most cases, we find that a virtual machineseparates a programming language or applicationenvironment from a execution platform.

Some people say that a virtual machine looks likeemulation software.


50/52

Virtual Machine


51/52

Virtual Machine


52/52

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, rule-based system execution, Smalltalk and Java interpreter typedprogramming 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.

sw architecture 1

Documents