Please enable JavaScript.

Coggle requires JavaScript to display documents.

Chap 5 - 8 - Coggle Diagram

- - - - Usually Requirement Spec. Specified in Data Flow Diagram (DFD)
      - Objective: Map from DFD to Main/Subroutine Design
    - - Two types of flow
        
        Transform Flow: input data get processed and results in output data (sequential)
        
        Transaction Flow: depending on input data, take different control actions (branch)
      - Mapping Process
        
        Identify transform and transaction flows
        
        Map each flow into a subroutine
        
        Generally: a main process controls the overall flow
    - - It is easy to decompose the system based on the definition of the tasks in a top-down refinement manner.
      - This architecture can still be used in a subsystem of OO design.
    - - Globally shared data in classical main-subroutines introduces vulnerabilities.
      - Tight coupling may cause more ripple effects of changes as compared to OO design.
  - - - The slaves provide replicated services to the master
      - The master selects a particular result among slaves by certain selection strategies.
      - Slaves may perform the same functional task by different algorithms and methods or a totally different functionality.
  - - - Functionality grouped into layers
      - Upper layer invokes func. in lower layer
    - - Functions in one layer usually organized in one package
    - - For systems that can be divided between portions providing generic services to the application of the system
      - Applications that have clean divisions between core services, critical services, user interface services, etc.
      - For applications which have classes that are close related each other
    - - Incremental software development
      - Enhanced independence of upper layer to lower layer
      - Enhanced reusability and interchangeability
      - Component-based technology is a suitable
      - Promotion of portability
    - - Lower runtime performance
      - Many applications can not fit this architecture
      - Exception and error handling
  - - - Provide a virtual interpretation layer that separates
        
        Application
        
        Physical machine layer
    - - Suitable for solving a problem by simulation or translation
      - Sample applications such as interpreters of microprogramming, XML processing, script command language execution, rule-based system execution, Smalltalk and Java interpreter typed programming language
    - - 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
    - - Interpreter, repository, and layered architecture
- - - - Whole system as transformation of successive sets of data.
      - System decomposed into modules.
      - Connection can be
        
        IO Stream
        
        Files, Buffers, Pipes
      - No interaction between modules
      - Modules do not need to know identity of each other
    - - Many sub-categories exist
        
        Batch Sequential
        
        Pipe & Filter
        
        Process Control
      - To adopt which one depends on the nature of the problem
  - - - Usually done in batch processing language or shell script
      - DOS Batch File
      - Direct implementation in coding
    - - Data are batched.
      - Intermediate file is a sequential access file.
      - Each subsystem reads related input files and writes output files.
    - - Simple divisions on subsystems.
      - Each subsystem can be a stand-alone program working on input data and producing output data
    - - Implementation requires external control.
      - It does not provide interactive interface.
      - Concurrency is not supported and hence throughput remains low
      - High latency
  - - - Independent modules
      - Data connectors
    - - Connectors are stream oriented
      - Concurrent processing
    - - Data Source
      - Data Sink
      - Filter: independent data stream transformer
        
        Reads data from input data stream
        
        Process data and write to output stream
        
        Does not wait for batched data as a whole
        
        Does not even have to know identity of i/o streams
      - Pipe: data conduit
        
        Moves data from one filter to another
        
        Two types: character or byte streams
    - - 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
    - - Active Filter:
        
        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.
      - Passive filter
        
        Lets connected pipe to push data in and pull data out.
        
        The filter must provide read/write mechanisms in this case.
    - - Unix provides pipe operation “|”
        
        moves stdout from predecessor to the stdin of its successor
    - - Java.io provides PipedWriter and PipedReader
      - Can work in parallel manner
    - - 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.
    - - Concurrency
        
        It provides high overall throughput for excessive data processing.
      - Reusability
        
        Encapsulation of filters makes it easy to plug and play, and to substitute.
      - Modifiability
        
        It features low coupling between filters, less impact from adding new filters, and modifying the implementation of any
        existing filters as long as the I/O interfaces are unchanged.
      - Simplicity
        
        It offers clear division between any two filters connected by a pipe.
      - Flexibility
        
        It supports both sequential and parallel execution.
    - - It is not suitable for dynamic interactions.
      - Data standards (ASCII, XML?)
      - 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.
  - - - Sub-systems
      - Connectors
    - - executor processor unit
      - controller unit
    - - Controlled variable
        
        A target controlled variable such as speed in a cruise control system or the temperature in an auto H/A system.
        It has a set point goal to reach. The controlled variable data should be measured by sensors as a feedback reference to recalculate manipulated variables.
      - Input variable
        
        A measured input data such as the temperature of return air in a temperature control system
      - Manipulated variable
        
        Can be adjusted by the controller
    - - 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
    - - Better for situations where no precise formula for deciding the manipulated variable
      - Can be completely embedded
    - - Requires more sensors to monitor system states
- - - - Deletion
      - Update
      - Insertion
      - Retrieval
  - - - Synchronization of duplicated data
      - Cost of data transmission
      - Vertical or horizontal partitions
      - Collaboration (two-phase transaction commitment)
    - - Distributed repository system
        
        Data are replicated in order to
        
        All data are distributed over all sites linked by network
      - Virtual repository
        
        Benefits
        
        Simplify the overall complexity of overall database structure
        
        Security management in terms of scope of data of manipulation for different users
    - - Data transactions drive the control flow
      - Suitable for large complex information system
    - - Data integrity : easy to backup and restore
      - System scalability and Reusability of agents :Reduce the overhead of transient data between software components
    - - High dependency between data structure of data store
      - Overhead cost of moving data on network
      - Data store reliability and availability
  - - - The problem spans multiple disciplines, each of which has complete different knowledge expertise
      - Optimal, partial, or approximate solution is acceptable
      - Suitable for solving immature and complex AI problems
      - Exhausted searching is impossible
    - - They don’t need to interact with each other
      - Only interact and respond to the blackboard subsystem
      - Each knowledge source is relatively independent
    - - Listeners or subscribers
      - Knowledge sources
    - - Knowledge Source : stores domain specific knowledge
      - Controller :initiating the blackboard and knowledge sources
      - Blackboard :Used to store data
    - - Data driven – a change in the data stored in Blackboard triggers one or more knowledge source
    - - Concurrency: all knowledge sources can work in parallel
      - Reusability of knowledge source agents
      - Scalability: easy to add new knowledge source
    - - Synchronization of multiple agents is an issue
      - Debugging and testing of the system is a challenge
      - Tight dependency between the blackboard and knowledge source
- - - - Interactive GUI component communication and integrated development environment (IDE) tools
      - Require loose coupling between components
      - The implementation of state machines
      - When event handlings in the application are not predictable
    - - Parallel execution of event handlings is possible.
      - Framework availability
      - Reusability of components
      - System maintenance and evolution
      - Independency and flexible connectivity
    - - It is difficult to test and debug
      - Reliability and overhead of indirect invocations may be an issue
      - Tighter coupling between event sources
    - - PAC, message-based, MVC, multi-tier, and state machine architectures
  - - - Message producers
      - Message consumers
      - Message service providers.
    - - message queue : one-to-one
      - message topic: one-to-many
    - - is a point-to-point structure between producer and consumer
      - is composed of message queues, senders, and receivers
      - Each message is sent to a destination => consumer clients extract messages from these queues
      - The queue retains all messages they receive either until the messages expire
      - Each message has only one consumer
      - Allows multiple message receivers but one and only one of them will get the message as determined by the message service provider
      - A sender and a receiver of a message have no timing dependencies
      - 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
    - - Is a hub-like architecture
      - Message topic publishers and subscribers are not aware of each other
      - Each topic message can have multiple consumers
      - Publishers and subscribers have a timing coupling dependency
      - A message topic consumer must subscribe the topic before it is published unless subscription is a durable subscription
    - - Suitable for communication between a producer and a receiver needs buffered message-based asynchronous implicit invocation
      - The provider wants the components not to depend on information about other components' interfaces, so that components can be easily replaced
      - Allows a component to send information to another and to continue to operate on its own without waiting for an immediate response
    - - Anonymity: providing high degree of anonymity between message producer and consumer
      - Concurrency: supports concurrency both among consumers and between producer and consumers
      - 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.
    - - Capacity limit of message queue
      - Complete separation of presentation and abstraction by control in each agent generates development complexity since
        communication between agents only takes place between the control of agents
      - Increased complexity of the system design and implementation.
    - - Event-based system, layered, multi-tier, and MVC