Please enable JavaScript.

Coggle requires JavaScript to display documents.

Chap 5,6,7,8 - Coggle Diagram

- - - - IO Stream
      - Files, Buffers, Pipes
  - - - Similar to Batch Sequence
      - Data connectors
    - - Connectors are stream oriented
      - Concurrent processing
    - - Data Sink
      - Filter: independent data stream transformer
        
        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
      - Data Source
      - Pipe: data conduit
        
        Moves data from one filter to another
        
        Two types: character or byte streams
    - - 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.
      - Push only (Write only)
        
        A data source may push data in a downstream
        
        A filter may push data in a downstream
    - - Active Filter:
        
        It works with a passive pipe that provides read/write mechanisms for pulling and pushing.
        
        pulls in data and push out the transformed data (pull/push)
      - Passive filter
        
        Lets connected pipe to push data in and pull data out.
        
        The filter must provide read/write mechanisms in this case.
    - - Advantages
        
        Modifiability: Low due to coupling between filters
        
        Simplicity: Clear
        
        Reusability is easy – plug and play.
        
        Flexibility: High, very modular design
        
        Concurrency is high.
        
        Lower latency
      - Disadvantages
        
        Data standards (ASCII, XML?)
        
        Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
        
        Not suitable for dynamic interactions
        
        Difficult to configure a P&F system dynamically.
        
        Error handling issue
  - - - Composed of
        
        Connectors
        
        Sub-systems
      - Two types of sub-systems
        
        executor processor unit
        
        controller unit
      - Suitable for embedded System
      - System depends on: Control Variables
    - - Input variable: measured input data
      - Manipulated variable: can be adjusted by the controller
      - Controlled variable: target controlled variable
    - - Needs to maintain an output data at a stable level.
      - The system has a set point which is the goal the system will reach and stay at that level.
      - Embedded software system involving continuing actions.
    - - Benefits
        
        Better for situations where no precise formula for deciding the manipulated variable
        
        Can be completely embedded
      - Limitations
        
        Requires more sensors to monitor system states
- - - - Retrival
      - Update and
      - Deletion
      - Insertion
    - - Data Store
      - Software component agents
    - - Blackboard
      - Repository
  - - - Data store reliability and availability are important issues
      - High dependency between data structure of data store and its agents. Changes in data structure have significant impacts on its agents. Data evolution is more difficult and expensive
      - Cost of moving data on network if data is distributed.
    - - Reduces the overhead of transient data between software
        components
      - Data integrity
      - System scalability and reusability of agents
    - - Suitable for large, complex information systems
      - Requires data transactions to drive the control flow of
        computation
    - - Virtual repository
        
        Built up on the top of multiple physical repositories
        
        Most DB allows users to create views that are virtual repositories
        since they do not exist physically
      - Distributed repository system (distributed database system)
        
        All data are distributed over all sites linked by net
        
        Data are replicated in order to Improve reliability and local
        accessibility
  - - - The problem spans multiple disciplines, and each problem involves completely different types of knowledge expertise and problemsolving paradigms that require cooperation.
      - Exhaustive searching is impossible and impractical since it may take forever because available knowledge and even data and hypotheses may not be complete or precisely accurate
      - Suitable for solving open-ended and complex problems such as artificial intelligence (AI) problems where no preset solutions exist
    - - Supports experimentation for hypotheses.
      - Scalability: easy to add or update knowledge source
      - Concurrency: all knowledge sources can work in parallel since
        they are independent of each other
    - - Synchronization of multiple agents is an issue
      - Due to the close dependency between the blackboard and knowledge source, the structure change of the blackboard may have a significant impact on all of its agents
      - it can be difficult to decide when to terminate reasoning
      - Debugging and testing of the system is a challenge
    - - Blackboard: Used to store data (Hypothesis and fact)
      - Knowledge Source: stores domain specific knowledge
      - controller: initiating the blackboard and knowledge sources
    - - Each knowledge source is relatively independent
      - They don’t need to interact with each other
      - Only interact and respond to the blackboard subsystem
  - - - Data store is passive
      - Clients of the data store are active
    - - Data store is active
      - Clients are inactive/passive
- - - - Pass by reference where the subroutine may change the value of data referenced by the parameter
      - Pass by value where the subroutine only uses the passed data but cannot change it
- - - - breaks the software system into two partitions
        
        Event source ♦
        Event listener ♦
        
        these two connected by event registration process connects
        
        no buffer
    - - Subscribers is an event listener and register themselves with the event source
      - Once an event is fired off by an event source, all corresponding subscribers are notified, which then take corresponding actions
      - The Observer pattern is another name used for this type of architecture
    - - Interactive GUI component communication and (IDE) tools
      - require loose coupling between components that need to notify or trigger to take actions upon asynchronous notifications.
      - Suitable for the implementation of state machines
      - Suitable when event handlings in the application are not predictable.
    - - Benefits
        
        Possibility of parallel execution of event handlings.
        
        Framework availability: Many vendor APIs such as Java AWT and Swing components available.
        
        Reusability of components: Easy to plug-in new event handlers without affecting the rest of the system.
        
        System maintenance and evolution: Easy to update both of event sources and targets.
        
        Independency and flexible connectivity: Dynamic registration and deregistration can be done dynamically at run-time.
      - Limation
        
        Difficult to test and debug the system
        
        The event source cannot determine
        
        the sequence of all responses
        
        when a response finished
        
        There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation.
        
        Reliability and overhead of indirect invocations may be an issue
  - - - three partitions
        
        Message service providers.
        
        Message consumers
        
        Message producers
      - connected asynchronously by
        
        message queue : one-to-one
        
        message topic: one-to-many
      - It is also considered data-centric
    - - Has been use for a long time
      - build reliable, scalable, and flexible distributed applications supporting asynchronous communication
      - Typically implemented as a Message-Oriented Middleware (MOM) providing a reliable message service on a distributed system
      - just a peer-to-peer client-server architecture
      - Sender sends out a message and it does not care much of the response from the receivers except for guaranteed message delivery
      - high degree of independency between components within the messaging system is one of its most important features
      - Its high scalability, interoperability in heterogeneous networks, and reliability also make the messaging system more popular
    - - structured data with a message id, message header, property, and a body
      - A typical example: is an XML document
      - messaging?
        
        a mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably.
      - Message client
        
        can produce and send messages to other clients
        
        also consume messages from other clients
        
        client must register with a messaging destination in a connection session provided by a message service provider for creating, sending, receiving, reading, validating, and processing messages.
    - - The message queue architecture is a point-to-point structure between producer and consumer
      - Each message is sent to a destination (a specific queue) which is maintained by the consumer; consumer clients extract messages from these queues.
      - composed of message queues, senders, and receivers.
      - The queue retains all messages they receive either until the messages are consumed or until the messages expire
      - This approach allows multiple message receivers but one and only one of them will get the message as determined by the message service provider
      - Each message has only one consumer, i.e., the message will be “gone” once it is delivered.
      - A sender and a receiver of a message have no timing dependencies
        
        the receiver can still get the message even it was not available when the sender sent the message
      - P2P messaging requires every message sent to the message queue must be processed successfully by a consumer.
      - It is much more reliable than simple event-listener based system we discussed earlier.
    - - One difference between P&S from P2P is that each topic message can have multiple consumers
      - The system delivers the messages to all its multiple subscribers instead of single receiver as in the message queue system
      - Message topic publishers and subscribers are not aware of each other
      - Publishers and subscribers have a timing coupling dependency
      - Is a hub-like architecture, where publisher clients send messages to a message topic that acts like a bulletin board
      - A message topic consumer must subscribe the topic before it is published unless subscription is a durable subscription, which is able to receive any topic messages sent while the subscribers are not active or not ready yet
    - - communication between a producer and a receiver
      - The provider wants the components not to depend on information about other components' interfaces, so that components can be easily replaced
      - The provider wants the application to run whether or not all other components are up and running simultaneously
      - The application business model allows a component to send information to another and to continue to operate on its own without waiting for an immediate response
    - - Benefit
        
        Supporting for concurrency among consumers and between producer and consumers
        
        Providing scalability and reliability of message delivery; reliability mechanisms include
        
        Message persistence setting without loss
        
        Message priority level setting
        
        Control level setting of message acknowledgement
        
        Message expiration setting
        
        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 batch processing
        
        Providing high degree of anonymity between message producer and consumer
        
        Supporting loose coupling between message producers and consumers and between legacy systems and modern systems for integration development.
      - Limitations
        
        Increased complexity of the system design and implementation
        
        A message receiver can still receive messages even if it is not running at the time the message was sent
        
        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
        
        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
        
        also difficult to determine the numbers of agents needed to satisfy the loose couplings between agents
        
        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
        
        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).