Software Architecture - 1

1
Software Architecture - 1

• May 10, 2014

2
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
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

4
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

5
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
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
Batch Sequential
8
Batch Sequential
9
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
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
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

12
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

13
Pipe and Filter
14
Pipe and Filter
Hello World
Upper case Conversion Filter
Match (H,L) Filter
Sort Count Filter
HL
LO W
orld
H 1 L 2
15
Pipe and Filter
16
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
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

18
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
Repository
20
Repository
21
Repository
22
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.

23
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
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

25
Blackboard
26
Blackboard
27
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 animal eats meat
• F2 animal gives milk
• F3 animal has black stripes
• F4 animal has tawny color

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

29
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

30
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

31
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
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.

33
Hierarchical Architecture

• 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
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.

35
Main-subroutine
36
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

37
Main-subroutine
38
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
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.

40
Master-slave
41
Master-slave

• Applicable Domains
• Software systems where reliability is critical.

42
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.

43
Layered Architecture
44
Layered Architecture
45
Layered Architecture
46
Layered Architecture
FTP protocol
TCP protocol
IP protocol
Ethernet protocol
Physical connection
47
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

48
Layered Architecture

• 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
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.

50
Virtual Machine
51
Virtual Machine
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 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.