software architecture 1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Architecture - 1 PowerPoint Presentation
Download Presentation
Software Architecture - 1

Loading in 2 Seconds...

play fullscreen
1 / 52

Software Architecture - 1 - PowerPoint PPT Presentation


  • 474 Views
  • Uploaded on

Software Architecture - 1. April 1, 2014. 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Architecture - 1' - shayna


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
all architectural patterns
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 patterns3
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
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
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
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 sequential9
Batch Sequential
  • Using Unix Shell Script

(exec) validate trans validTrans invalids

(exec) sort validTranssortedTrans

(exec) update master sortedTrans

(exec) generateReports master report1 report2

batch sequential10
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
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 filter12
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 filter14
Pipe and Filter

Hello World

Match

(H,L)

Filter

Upper case

Conversion

Filter

Sort & Count Filter

HL

LO W

orld

H 1

L 2

pipe and filter16
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
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
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
repository22
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
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
blackboard24
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 example 1
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

blackboard example 128
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
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 230
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
blackboard31
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.
blackboard32
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
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
main subroutine
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 subroutine36
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 subroutine38
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
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 slave41
Master-slave
  • Applicable Domains
    • Software systems where reliability is critical.
layered architecture
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.
slide46

FTP

FTP

TCP

TCP

IP

IP

Ethernet

Ethernet

Layered Architecture

FTP protocol

TCP protocol

IP protocol

Ethernet protocol

Physical connection

layered architecture47
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 architecture48
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
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 machine52
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.