Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 5 - 6 - 7 - 8 - Coggle Diagram
Chapter 5 - 6 - 7 - 8
Chapter 7 - Hierarchical Architecture
7.1 Main-Subroutine
Benefits:
Easy to decompose the system
Can still be used in a subsystem of OO design
Limitations:
Globally shared data in classical main-subroutines introduces vulnerabilities
Tight coupling may cause more ripple effects of changes as compared to OO design
Overview
Probably the oldest and most widely used architecture
Purpose:
Encourage re-use of modules
Idea
System decomposed into sub-routines
A “main” program calls sub-routines and accomplishes task
7.2 Master-Slave
Overview
A
variant of the main-subroutine
architecture style that supports fault tolerance and system reliability
In this architecture:
Slaves provide replicated services to the master
The master selects a particular result among slaves by certain
selection strategies
The slaves may perform the same functional task by different algorithms and methods or by a totally different functionality
Characteristic:
parallel computing and accuracy of computation
Applicable domains:
Master-slave architecture is used for the software system where reliability is critical
7.3 Layered
Benefits:
Incremental software development
Enhanced independence of upper layer to lower layer
Enhanced flexibility
Component-based technology is a suitable technology to implement layered architecture
Promotion of portability
Limitations:
Lower runtime performance
Many applications can not fit this architecture
Exception and error handling
Applicable domains:
For systems that can be divided between portions providing generic services to the application of the system
For applications which have classes that are close related each other
Overview
In a layered architecture the system is decomposed into a number of higher and lower layers in a hierarchy
Functions in one layer usually organized in one package
Each layer has its own sole responsibility in the system
Upper layer invokes function in lower layer
7.4 Virtual Machine
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
Applicable domain:
Suitable for solving a problem by simulation or translation
Sample applications include interpreters of microprogramming, XML processing, script command language execution, rule-based system execution, Smalltalk and Java interpreter type programming languages
Overview
Variation of Layered approach
Provide a virtual interpretation layer that separates
application
and
physical machine layer
Chapter 5 - Data Flow Architecture
5.1 Batch Sequential
The batch sequential architecture style represents a traditional data processing model that was widely used from 1950 to 1970
Applicable domains
Data are batched
Intermediate file is a sequential access file
Each subsystem reads related input files and writes output files
Benefits
Simple divisions on subsystems
Each subsystem can be a stand-alone program working on input data and producing output data
Limitations
Implementation requires external control
It does not provide interactive interface
Concurrency is not supported and hence throughput remains low
High latency
5.2 Pipe and Filter Architecture
Applicable domains
The system can be broken into a series of processing steps over data streams, and at each step filters consume and move data incrementally
The data format on the data streams is simple, stable, and adaptable if necessary
Significant work can be pipelined to gain increased performance
Producer or consumer-related problems are being addressed
Benefits
Concurrency
Reusability
Modifiability
Simplicity
Flexibility
Limitations
It is not suitable for dynamic interaction
A low common denominator is required for data transmission in the ASCII formats since filters may need to handle data streams in different formats, such as record type or XML type rather than character type
Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
It can be difficult to configure a pipe and filter system dynamically
03 ways to make the data flow
Push only (Write only)
A data source may push data in a downstream
A filter may push data in a downstream
Pull only (Read only)
A data sink may pull data from an upstream
A filter may pull data from an upstream
Pull/Push (Read/Write)
A filter may pull data from an upstream and push transformed data in a downstream
02 types of filters
Active filter
pulls in data and pushes out the transformed data (pull/push)
works with a passive pipe that provides read/write
mechanisms for pulling and pushing
the pipe and filter mechanism in Unix adopts this mode
Passive filter
lets connected pipes push data in and pull data out
works with active pipes that pull data out from a filter and push
data into the next filter
the filter must provide the read/write mechanisms in this case
Overview
This architecture decomposes the whole system into components of data source, filters, pipes, and data sinks
The connections between components are data streams.
The particular property attribute: concurrent and
incremented execution
Filter - an independent data stream transformer
reads data from its input data stream
processes data and writes to output stream
does not need to wait for batched data as a whole
does not even know the identity of
data upstream or data downstream
5.3 Process Control Architecture
Overview
suitable for the embedded system software design
decomposes the whole system into
subsystems
(modules) and
connections
between subsystems
The connections between the subsystems are the data flow
02 types of subsystems
an executor processing unit for changing process control variables
controller unit for calculating the amounts of the changes
Process control data:
Controlled variable: a target controlled variable
Input variable: a measured input data
Manipulated variable: can be adjusted by the controller
Applicable domains:
Embedded software systems involving continuing actions
Systems that need to maintain an output data at a stable level
The system can have a set point - the goal the system will reach at its operational level
Benefits:
It offers a better solution to the control system where no precise formula can be used to decide the manipulated variable
The software can be completely embedded in the devices
Chapter 6 - Data-Centered Software Architecture
6.1 Repository Architecture Style
Applicable domains:
Suitable for large, complex information systems where many software component clients need to access them in different ways
Requires data transactions to drive the control flow of computation
Benefits:
Data integrity: easy to back up and restore
System scalability and reusability of agents: easy to add new software components because they do not have direct communication with each other
Reduces the overhead of transient data between software components
Limitations:
Data store reliability and availability
High dependency between data structure of data store
Cost of moving data on network if data is distributed
Overview
a data-centered architecture that supports user interaction for data processing
Variants of repository architecture:
Virtual repository
built up on the top of multiple physical repositories
allow users or developers to create views that are virtual repositories
Beneffits:
simplify the complexity of overall database structure
provides security management in terms of scope of data and types of manipulations for different users or groups
Decentralized (distributed) repository
all data are distributed over all sites linked by network
Benefit:
Data are replicated in order to improve reliability and local accessibility
Limitations:
vertical or horizontal data partitions
synchronizations of duplicated data
collaboration in a distributed transaction is a complicated two-phase transaction commitment
cost of data transmission on the network
6.2 Blackboard Architecture Style
Applicable domain:
Suitable for solving open-ended and complex AI problems
The problem spans multiple disciplines, each problem involves completely different types of knowledge expertise and problem-solving paradigms that require cooperation
Partial or approximate solution is acceptable to the problems
Exhaustive searching is impossible
Benefits:
Scalability: easy to add or update knowledge source
Concurrency: all knowledge sources can work in parallel
Supports experimentation for hypotheses
Reusability of knowledge source agents
Limitations:
Close dependency between the blackboard and knowledge source
Difficult to decide when to terminate reasoning
Synchronization of multiple agents is an issue
Debugging and testing of the system is a challenge
Overview
a data- directed and a partially data-driven architecture
consists
03 partitions
:
blackboard: is used to store data
knowledge sources: stores domain-specific knowledge
controller: used to initiate the blackboard and knowledge sources
Properties:
Each knowledge source is relatively independent from the other knowledge sources
The don't need to interact with each other
Only interact and respond to the blackboard subsystem
Chapter 8 - Implicit Asynchronous Communication Software Architecture
8.1 Nonbuffered Event-Based Implicit Invocations
Overview
breaks the software system into two partitions:
event sources
and
event listeners
The
event registration process
connects these two partitions
There is
no buffer available
between these two parties
Applicable domains:
Interactive GUI component communication and integrated development environment (IDE) tools
Applications that require loose coupling between components that need to notify or trigger other components to take actions upon asynchronous notifications
The implementation of state machines
When event handlings in the application are not predictable
Benefits:
Framework availability
Reusability of components
System maintenance and evolution
Independency and flexible connectivity
Parallel execution of event handlings is possible
Limitations:
Difficult to test and debug the system
Reliability and overhead of indirect invocations
The event trigger cannot determine when
a response has finished
or
the sequence of all responses
There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation
8.2 Buffered Message-Based Software Architecture
Overview
breaks the software system into
03 partitions
:
message producers
message consumers
message service providers
This architecture is also considered data-centric
They are connected asynchronously by either:
a message queue: one-to-one
a message topic: one-to-many
Point-to-Point Messaging (P2P)
The message queue architecture is a point-to-point structure between producer and consumer
A P2P messaging architecture is composed of
message queues
,
senders
, and
receivers
Each message is sent to a destination (a specific queue) which is maintained by the consumer; consumer clients extract messages from these queues
P2P messaging requires every message sent to the message queue must be processed successfully by a consumer
Publish-Subscribe Messaging (P&S)
is a hub-like architecture where publisher
clients send messages to a message topic that acts like a bulletin board
Message topic publishers and subscribers are not aware of each other
One difference between P&S and P2P:
each topic message can have multiple consumers
The system delivers the messages to all of its multiple subscribers
A message-based software application
consists of the following parts
A messaging service provider or message server
Clients of message service
Messages
Applicable domains:
Suitable for a software system where the communication between a producer and a receiver requires buffered message-based asynchronous implicit invocation for performance and distribution purposes
The provider wants components that function independently of information about other component interfaces so that components can be easily replaced
The provider wants the application to run whether or not all other components are running simultaneously
The application business model allows a component to send information and to continue to operate on its own without waiting for an immediate response
Benefits:
Concurrency
Anonymity
Scalability and reliability of message delivery
Supports batch processing
Supports loose coupling between message producers and consumers, and between legacy systems and modern systems for integration development
Limitations:
Capacity limit of message queue
Complete separation of presentation and abstraction by control in each agent generates development complexity
Increased complexity of the system design and implementation