Summarize Knowledge (5-11) (CHAPTER 5: Data Flow Architecture (Advantages,…
Summarize Knowledge (5-11)
CHAPTER 5: Data Flow Architecture
Similar to Batch
Connectors are stream oriented
Pros and Cons
Better for situations where no precise formula for deciding the manipulated variable
Can be completely embedded
Limitation: Requires more sensors to monitor system states
Moves data from one filter to another
Two types: character or byte streams
Process data and write to output stream
Does not wait for batched data as a whole
Reads data from input data stream
Does not even have to know identity of i/o streams
Usually done in batch processing language or shell script
Simple division between sub-systems
Each sub-system can be a stand-alone
Example: mainframe computers using COBOL
No interactive interface
No concurrency and low throughput
Traditional data processing model
Data Flow Methods
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
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.
What is data flow
Connection can be(IO Stream, Files, Buffers, Pipes)
No interaction between modules
System decomposed into modules
Whole system as transformation of successive sets of data
Modules do not need to know identity of each other
pulls in data and push out the transformed data (pull/push)
It works with a passive pipe that provides read/write mechanisms for pulling and pushing
Lets connected pipe to push data in and pull data out.
The filter must provide read/write mechanisms in this case
Pipe & Filter
To adopt which one depends on the nature of the problem
Concurrency is high.
Reusability is easy – plug and play
Modifiability: Low due to coupling between filters
Flexibility: High, very modular design
Not suitable for dynamic interactions
Data standards (ASCII, XML?)
Difficult to configure a P&F system dynamically
Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
Error handling issue
CHAPTER 6: Data-Centered
Optimal, partial, or approximate solution is acceptable
Suitable for solving immature and complex AI problems
The problem spans multiple disciplines, each of which has
complete different knowledge expertise
Exhausted searching is impossible.
Tight dependency between the blackboard and knowledge
Synchronization of multiple agents is an issue
Debugging and testing of the system is a challenge.
Reusability of knowledge source agents
Scalability: easy to add new knowledge source
Concurrency: all knowledge sources can work in parallel
Suitable for large complex information syste
Data transactions drive the control flo
Data integrity: easy to backup and restore,
System scalability and Reusability of agents
Reduce the overhead of transient data between software
Data store reliability and availabilit
High dependency between data structure of data store
Overhead cost of moving data on networ
CHAPTER 7: Hierarchical
Applicable Design Domain
Suitable for solving a problem by simulation or translation
Sample applications such as interpreters of microprogramming, XML processing, script command language execution...
Portability and machine platform independency
Simplicity of the software development
Simulation for non-native and disaster working model
Slow execution of the interpreter
Additional overhead due to the new layer
Applicable Design Domains
For applications which have classes that are close related each other
For systems that can be divided between portions providing generic services to the application of the system
Incremental software development
Enhanced independence of upper layer to lower layer
Enhanced reusability and interchangeability
Component-based technology is a suitable
Promotion of portability
Many applications can not fit this architecture
Exception and error handling
Lower runtime performance
Slaves may perform the same functional task by different algorithms and methods or a totally different functionality.
A variant of main-subroutine architecture
It supports Fault tolerance and system reliability
Main Subrountine Architecture
Probably the oldest and most widely used architecture
Can still be used in sub-system of OO Design
Easy to decompose the system
Tight coupling may cause ripple impacts as compared to OO design
Globally shared data are vulnerable
CHAPTER 8: Asynchronous implicit invocation
Reliability and overhead of indirect
invocations may be an issue.
The event source cannot determine
when a response finished or
the sequence of all responses
Difficult to test and debug the system: Hard to predict and verify responses and the order of responses from the listeners.
There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation.
System maintenance and evolution:
Easy to update both of event sources and targets.
Reusability of components: Easy to plug-in
new event handlers without affecting the rest of the system.
Independency and flexible connectivity: Dynamic registration and deregistration can be done dynamically at run-time.
Framework availability: Many vendor APIs
such as Java AWT and Swing components available.
Possibility of parallel execution of event handlings.
The message consumer does not know who produced the message (user independence), where the producer lives on the network (location independence), or when the message was produced (time independence).
Supporting for concurrency among consumers and between
producer and consumers.
Supporting batch processing.
Providing high degree of anonymity between message producer and consumer.
Providing scalability and reliability of message delivery; reliability mechanisms include
Supporting loose coupling between message producers and consumers and between legacy systems and modern systems for integration development.
Complete separation of presentation and abstraction by control in each agent generate development complexity since communications between agents only take place between the control of agents.
Increased complexity of the system design and implementation
However, there is an absolute limit based onavailable memory. It is also difficult to determine the numbers of agents needed to satisfy the loose couplings between agents.
A message receiver can still receive messages even if it is not
running at the time the message was sent.
Capacity limit of message queue. This is not an inherent limitation but an implementation issue that can be eased if the queue is implemented as a dynamic data structure (e.g., linked lists).
In an event-based invocation system the event handler must be ready in order to be able to intercept an event and take an action upon that event.
This architectural style is commonly used in the connection between the Model sub-system and the View sub-system in an MVC or PAC architecture.
CHAPTER 9: Interaction Oriented Architecture
Model View Controller
Easy to plug in new or change interface views
Very effective for developments
Does not fit agent-oriented application such as robotics applications
Multiple pairs of controllers and views make data model change expensive
The division between the View and the Controller is not very clear in some cases
Suitable for where multiple views needed for a single data model
There are clear divisions between controller, view, and data modules
Widely used in web applications
Presentation Abstraction Control
Suitable for where there are many cooperating agents in
a hierarchical structure
The coupling among the agents is expected very loose
Supporting multi-tasking, multi-viewing
Supporting agent reusability and extensibility
Easy to plug in new agent or replace an existing agent
Overhead due to the control bridge.
Difficult to design agents
Difference of MVC and PAC
They differ in their flow of control and organization.
PAC is an agent based hierarchical architecture
MVC does not have any clear hierarchical architecture. All three
modules are connected together.
Interaction oriented SW architecture
Separation of user interactions from data abstraction and business logic
This is because
Even for a specific view presentation, the view or interface may need to change so often, so the loose coupling between data abstraction and its presentation is helpful. This is supported in this style.
Multiple views is supported for the same data set.
Many view presentation in different data formats
CHAPTER 10: Distributed Architecture
Low fault tolerance
Inefficiency due to the overhead of proxies
Server component implementation and location transparency,
Changeability and extensibility,
Feasibility of run time changes of server components (add or remove server components)
Service Oriented Advantages
Interoperability: Technically any client or any service can access
other services regardless of their platform, technology, vendors,
or language implementations
Reusability: Any service can be reused by any other service,. Because clients of a service only need to know its public interfaces, service composition and integration become much easier.
It makes SOA software much easier to evolve and update.
SOA based business application development comes much
more efficient in term of time and cost.
The implementation of a service will not affect the application of
the service as long as the exposed interface is not changed.
Each service component is independent from other services due
to the stateless service feature.
Loosely-coupled connection: Loose-coupling is the key attribute
Adding multiple servers in the system makes the server reliability
and availability even more critical
Difficulty in testing due to lack of testing tools
Advantages of multi-tier over two-tier architecture.
Reduces traffic on the network
Middle layer can provide multi-threading support
Have portable and nonproprietary design and implementation
Middle layer is easy to change
Reusability of server components
Responsibility separation such as user interface presentation
and business logic processing
Testability and scalability
Server availability and reliability
Lack of heterogeneous infrastructure to deal with the requirement changes
CHAPTER 11: Component Based Architecture
Suitable for loose coupling between the components and many reusable components are available
Suitable for the class library system organization. .NET class library and Java API themselves are built in component architecture
Suitable for where the interface contracts between sub-systems are clear.
Many OO design tools available
Independency and flexible connectivity of components
System maintenance and evolution
Reusability of components
Sometime it is difficult to find suitable components to reuse.
Adaptation of components is always an issue.