Please enable JavaScript.

Coggle requires JavaScript to display documents.

SWD391 - Coggle Diagram

- - - - Usually Requirement Spec. Specified in Data Flow Diagram (DFD)
      - Objective: Map from DFD to Main/Subroutine Design
    - - Two types of flow
        
        Transaction Flow: depending on input data, take different control actions (branch)
        
        Transform Flow: input data get processed and results in output data (sequential)
    - - Identify transform and transaction flows
      - Map each flow into a subroutine
      - Generally: a main process controls the overall flow
    - - Benefits:
        
        Easy to decompose the system
        
        Can still be used in sub-system of OO Design.
      - Limitation:
        
        Globally shared data are vulnerable
        
        Tight coupling may cause ripple impacts 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
      - 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
- - - - Scale
      - Distribution
      - Complexity
    - - The Styles and design patterns to achieve the requirements
      - Constraints that effect the way in which architecture can be implemented
      - It design defines the relationship between major structural elements
    - - They translate the software system requirements into architecture design
      - They apply various design strategies to divide and conquer the complexities
      - Software architects and designers
    - - Good Design
        
        Help development team works together in an orderly fashtion
        
        Make the system traceable for implementation and testing
        
        Reduce the risks associated with software production
        
        Lead to software product that have higher quality attributes
      - Poor Design
        
        May result in deficient product
        
        Is not adptive to future requirement change
        
        Exhibits unpredictable behavior or perform badly
        
        Not reusable
    - - SRS
        
        Provide input necessary for design
        
        Result of requirement analysis
        
        Record FUNCTIONAL and NON FUNCTIONAL
      - Outcome of software architecture design is SDD. SDD?
        
        Describes the elements of a system
        
        The modules that compose each element
        
        Overall representation of the software to be build
        
        The detail information of each module
        
        Sample base on IEEE 1016
        
        Design overview, purpose, scope
        
        Decomposition description
        
        Dependency and connection description
        
        Attributes
        
        User interface description
        
        Detailed design
    - - Architectural design
        
        Designer must specify user component and interconnections that are visible to stakeholder
        
        Architecture design is front strategy for the detailed design
      - Detailed Design/Tactical design
        
        Concerned with local design constraints and the internal detail of each component
  - - - Hightlights early design decisions
      - Blueprint guideline for development
      - Convers functional and non-functional requirement
      - It is very important in software development
      - Show how system is sturctured
    - - System analyst
      - Software architect
    - - Establish dynamic control relationships among different subsystems
      - Consider and evaluate alternative architecture styles
      - Perform static partition and decomposition
      - Tradeoff analysis on quality attributes
      - IMPORTANT: Map the SRS to the SDD guarantee that functional and nonfunctional requirements are met
  - - - Attributes that describe the advantages and disadvantages of the chosen structure
      - Elements that perform functions required by a system
      - Constraints that define how elements are integrated to form the system
      - Connectors that enable communication, coordination, and cooperation among element
    - - Is abstracts the common properties of a family of similar design
      - It governs runtime interaction of flow control and data transfer
      - It contains a set of rules, constraints, and patterns of how to structure a system into a set of element and connectors
    - - Save cost and time on design
      - Architecture style represents
      - Once overall structure determined, rest are easy
    - - Each style has a set of quality attributes that it promotes
      - By indentify the right style to supports software architecture design we can choose which tectics we can use to better implement the architecture
  - - - Runtime attributes
        
        Security
        
        The ability to defend against attacks
        
        Performance
        
        Time efficiency and resource efficiency
        
        Availability
        
        If system is available 24/7
        
        Can be enchanced by replication
        
        Usability
        
        Completeness, correctness, compatibility and user friendliness
      - Business attributes
        
        Cost
        
        Expense of the building, maintaining, and operating the system
        
        Lifetime
        
        The period of time that the product is alive before retirement
        
        Time to market
        
        The time it takes from requirement analysis to the product is released
      - Implementation attributes
        
        Testability
        
        Whether the system allows easy debugging
        
        Portability
        
        Can be system be deployed on different platforms
        
        Maintainability & Extensibility
        
        The ability to modify the system and conveniently extend it
        
        Scalability
        
        Can system adapt to increase of requests
        
        Flexibility
        
        Ease of modification of system to cater to a different environment
    - - Space vs Time
      - Reliability vs Performance
      - Scalability vs Performance
  - - - System requirements must be nailed down before design starts
      - Notice, different stakeholder have different opinions
      - Clarify priority of all requirements before design
    - - Nail down the interface but leave room of change for implementation
      - Use abstract architectural design to communicate with stakeholders helps avoid overhauling the system design in later stage
      - Use multiple level of abstraction if necessary
      - Make all implementation decisions depend on the abstract interfaces instead of concrete ones because those are more stable
      - Always starts with abstraction
    - - The earlier, the better
      - It is not possible to find a design that meets all quality attribute
      - Otherwise, very hard to change your design to reflect these requirement
      - Balance the quality attributes, and consider heterogeneous architecture styles when necessary
      - Speed, Reliability, Security have to be considered first
    - - Leave the room for expansion
      - Consider how resuse existing software components to increase the reliability and cost-effectiveness of new systems.
      - Extensibility is very important
      - Always try hard to make software extensible in the future.
      - User requirements can change frequently
    - - Design should be logically clear!
      - The less correlation between modules, the better!
      - One component (module) should be assigned ONE functionality only
      - Easy debugging and maintenance
      - Try to promote high cohesion within each element and loose-coupling between elements.
      - Also allows great extensibility
    - - Never expect to have software design completely perfect within one step
      - We may need to use prototyping and iteration to refine the software design
    - - Ambiguous design lacks constraints
      - Over-detailed design restricts implementation.
- - - - A very Poppular design approach, applies to many of the software architecture styles
      - Popular since 1980's
      - OO Software Engineering
        
        OO Design
        
        OO Programming
        
        OO Analysis
      - OO programming language: C++, Java, C#
      - Three Principles
        
        Inheritance
        
        A class can inherit from its base class
        
        Inheritance allows software reuse, hence improving the effectiveness of software development
        
        Polymorphism
        
        Translate it is call multiple form
        
        Refer to ability of an object to behave differently and assume different forms based on its inheritance hierarchy
        
        It includes:
        
        Override
        
        Overloading
        
        Encapsulation
        
        Often call information hiding
        
        It separate interface from implementation by hinding the implementation details
        
        Flexibility in design, easy teamwork working.
    - - Although treated as an "architecture style" in the book
      - Should be used as a methodology
      - All other architecture style can be described using OO
  - - - Class
        
        Is group to gether related data and their operations
        
        Defines the attributes and behavious share by all of its object
        
        Consists of three elements:
        
        A class Name
        
        A list of operations
        
        A list of attributes
      - Objects
        
        Is an instance of a class
    - - It very complex!
      - A partial list of relationship
        
        Instance Level Relationship
        
        Aggregation
        
        A kind of "whole-part" relationship
        
        Parts do not have to share the same lifespan as owner
        
        Is a special case of association
        
        In UML, aggregation is represented using a hollow diamond arrowhead
        
        Composition
        
        Composition is a stronger variant of the "own a" relationship
        
        Requirement: the lifespan of "Components" and "owner" involved in a composition relationship must be same
        
        Is represented using a solid diamond arrowhead
        
        Association
        
        Is a connection between classes, and a semantic connection between objects of the classes involved in the association
        
        Nomaly bidirectional
        
        Class Level Relationship
        
        Generalization
        
        Realization
        
        General Relationship
        
        Dependency
      - Differences between composition and aggregation
        
        Attempting to represent real-world whole-part relationship, use composition
        
        Representing a software or database relationship, use aggregation
      - Composition vs Inheritance
        
        OO paradigm provide two different approaches for reuse a design: composition and inheritance
        
        Use the inheritance relationship only when the derived class "is-a" base class
        
        Use the composition can be used to model the "has a" relationshi[ among class
  - - - Use Case is a way that a user accesses the system
      - User can be either real human user, or components of a bigger picture
      - UCD Depicts their relationship
      - UCD Must be accompanied by the description of flow of events
      - Flow of Events: a sequence of operations for a use case
    - - Requirement specification
      - Initial logic structure of the system
    - - Use case diagram
      - Analysis class diagram
    - - Analysis Class Diagram
      - Describes: Key class of a system, their relationshi[
      - Abstraction of the system
      - Extracts all nouns in the flow of events description
  - - - High level design process
      - Detailed level design process
    - - class diagram
      - interaction diagram
      - CRC cards
      - state chart etc.
    - - Class-Responsibility-Collaborator
      - Identify classes to build a system
      - Team Work
      - How to use
        
        The Team examine use case one by one
        
        When use case are solved, examine each responsibility of each class, repeat the same process
        
        Facilitator starts the process
        
        When to stop?
        
        When get to “private” details with no need of collaboration with other classes
    - - Mostly used: sequence diagram
      - Process: reconstruct the flow of events using sequence diagram
    - - Describe the life-cycle of an object
      - Many times directly translated into implementation; sometimes not.
      - Conveys the spec between designer and programmer
    - - Purpose: Determine the set of: attributes, operations
        
        Identify: public interface, implementation details of classes
        
        Examine each responsibility
        
        If necessary split class
        
        Start from CRC Cards
      - Nail down the interface of each class
      - Outcome: class diagram
      - Interface:
        
        interaction protocol between classes
      - Implementation details:
        
        private data members, algorithm of operations
      - Operations
        
        Design multiple constructors if necessary
        
        Destructor: very important
        
        Release system resources
        
        Notice virtual destructors
        
        A class can provide 4 categories of ops
        
        Destructor
        
        Accessor
        
        Constructor
        
        Mutator
      - Handle Implementation Details
        
        Start from each public operation
        
        Think about how to implement it
  - - - Tight coupling is usually bad
      - Why?
        
        Hard to maintain
        
        Hard to extend
        
        Longer project compiling time
    - - Close to Modification
        
        The existing implementation should not be modified
      - How to do it?
        
        Inheritance
        
        polymorphism
      - Open to Extension
        
        he system can be extended to meet new requirements
    - - a class only performs closely related operations
      - Logically good! Easy to maintain
- - - - Provides a static view of the system. It captures the vocabulary of the designed system.
      - Is the foundation diagram of the system design and it is the most frequently used UML diagram as well.
      - Is generated by system analysts and system designers and will be iteratively refined in the subsequent phases during the software development life cycle.
      - Describe each individual class with its type, interface, properties, and methods.
      - Popular accessibility modifiers include private, public, protected, and default
      - One important part of a class diagram is the interface of each class
      - There are three main different relationships among classes’ these are inheritance, aggregation, and association.They all can be represented graphically in a class diagram.
      - For each relationship, multiplicities between classes can be denoted. Typical multiplicity types include one to one, one to many, and many to many mappings.
    - - Is used to describe a sample subset of objects in the system at a point of time.
      - Shows a snapshot of class instance connection and interaction.
      - Many other behavioral diagrams (sequence diagram, communication diagram, and interaction diagram) can make references to the object diagram.
    - - Is used to describe the composition of interconnected elements or the collaboration of runtime instances.
      - There are two basic notations in a composite structure diagram
        
        Structured class (represented using a rectangle box)
        
        Collaboration (represented using a dashed eclipse)
      - Each structure class may have an annotation which indicates its “role” in the collaboration.
    - - Is neither a class nor an object.
      - Is a deployable reusable building block for software design and development.
      - Each component has an interface to expose its services and hides its implementations.
      - The interface is the contract between reusable component and its clients.
      - UML 2.0 introduced a new notation for components and connections between components.
        
        A cup shape represents the required interface, and the required interface must be provided by some other components.
    - - Is represented by a tabbed folder that indicates where all included classes and sub packages reside.
      - Packages play a similar role as a directory for grouping files in a file system; they allow the organization of all closely related classes in a well-formed manner to be placed in one “container.”
      - We can also organize related packages in a same parent package to build a class and package hierarchy just like.NET class library and Java API.
      - Shows the dependency relationship between packages (see static structure above), where a change of one package may result in changes of other package due to this dependency.
      - May also specify the contents of a package, i.e., the classes which constitute a package and their relationship.
      - The use of package diagrams to represent system structure can help reduce the dependency complexity and simplify relationships between groups of classes.
    - - Depict the physical configuration of the software system deployed on hardware server nodes and the network between the nodes (defined as protocols).
      - Is generated in the later phase of software development life cycle.
      - All components in the system need to be deployed on servers to provide services via network protocols.
      - Component diagrams are the basis for the deployment diagram.
      - UML uses a cube symbol to represent a computing resource node; such a resource can be a hardware device or a deployed software subsystem.
  - - - The user interface view
      - The physical view
        
        Specifies the deployment infrastructure in terms of software, hardware, and networking configurations, installation, and deployment for delivery purposes.
      - The development view
        
        Organizes the software units in well-defined ways according to the actual file or directory structure.
      - The process view
        
        Addresses non-functional requirements such as module communication styles and performance issues at runtime.
      - The logical view
        
        Is used to identify software modules and their boundaries, interfaces, external environment, usage scenarios, etc.
  - - - is one of the most important and most widely used UML diagrams for software system analysis and design.
      - Is a time-oriented interaction diagram showing the chronological sequence of messages between objects.
      - Usually, one sequence diagram corresponds to one use case.
      - Each participant object in this diagram has a vertical timeline for its life cycle.
        
        Time goes forward along with the timeline downward.
        
        Each vertical timeline has a number of narrow rectangle boxes (called activations) representing the object activated state where either it receives messages or sends out messages.
        
        Each activation box may also have a self-recursive directed link pointed back to itself, indicating the object passes messages to itself.
        
        An activation may also branch or fork many separate lifelines for the if-selection scenario conditions; eventually all forked lines will join together.
      - A message passing action between objects is represented by a horizontal arrow link from the source to the destination. It is represented by a solid line with an arrowhead.
      - An object can send a synchronous message to another object by a synchronous message line with a full arrowhead.
      - A synchronous message means that the sender must wait for the reply from the target object before it can move forward in their timeline.
    - - Known as collaboration diagram in UML 1.x, is a message-oriented diagram that describes ALL message passing sequence, flow control, object coordination, etc, between the objects that participate in certain use case.
      - Summarizes how objects in the system receive and send messages from/to other objects.
      - Is an extension of the static object diagram where the links between objects represent the association relationships.
      - Above the links in a communication diagram are the numbered messages, indicating the order in which they are sent or received.
      - These two type of diagrams provide a message-oriented and time-oriented view, respectively.
    - - Describes the control flow of the interactions rather than message.
      - Is a variant of the Activity Diagram.
      - The nodes in a Interaction Overview Diagram represent either interactions reference to some existing diagrams (ref) or interaction basic element (activity diagram (ad) or sequence diagram (sd)).
      - Each node (called frames) can be any interaction diagram
      - A reference node, indicated by a “ref” in the up-left corner of frame, points to an existing diagram while the basic element directly displays the dynamic interaction diagram in it.
    - - Is a new diagram in UML 2.0.
      - Combines the state diagram and time sequences to show the dynamic view of state change caused by external events over time.
      - Is often used in time-critical systems such as real time operating system, embedded system design, etc.
    - - Called state charts in UML 1.x, are widely used for embedded systems and device software analysis and design.
      - Is an event-oriented diagram where the software elements in the system change their states in response to external or internal stimuli (such as time events or other system events).
      - Are ideal for specifying the internal behavior of objects.
      - In a state machine diagram, a state is a rounded rectangle with three subdivisions
        
        State name
        
        State variables
        
        State activities
      - Is a situation in which an object meets conditions, takes actions, and waits for new event. When a new event takes place in the current state, the machine will perform specified actions and then will enter a new state (the next state).
      - Each state machine diagram has one starting point in a solid black circle and has one or more endpoints, the latter indicated by eye-circles.
    - - Describe user requirements in terms of system functionality (use cases) as a contract between the user (actors) and the software system.
      - It consists of actors, use cases and links between them.
      - An actor in a use case diagram is an external “user;” this may be a human end user, an application, an external device, or another system.
      - Each use case is a meaningful operational work scenario.
      - Are scenario-oriented in the sense that each is a sequence of working steps to be carried out by classes in order to provide the required system functionality.
      - The (simple) connection link from actor to use case shows the direction of actors using the use case.
      - An <<include>> link
        
        Is a dashed line with an arrow pointing to the reused use case
        
        A special kind of link, from one use case to another indicates that the first use case reuses or includes the latter use case and it is needed to complete the work to fulfill the requirement.
      - An <<extend>> link
        
        Shows a newly created optional use case from an existing use case.
        
        It covers alternative cases that may or may not necessarily take place.
        
        Is also a dashed directed line with an arrow towards the extended use case; these special links are labeled accordingly.
    - - Is used to describe complex business processes
      - Is a workflow-oriented diagram describing steps on a single process.
      - One activity diagram corresponds to one business process. There are many activities in a business process.
      - UML activity diagrams use a rounded rectangle to represent an activity.
      - Each activity diagram starts with a starting point and finishes with one or more finishing points.
      - A small diamond represents a decision point in the diagram.
      - Also support parallel processing using a pair of black horizontal bars to indicate the corresponding fork/join actions in such pathways.
      - Also support communication between two concurrent flows by sending signals from one path to another (this is called an event and it is noted as a pair of convex polygons).
  - - - The Logical or Conceptual View
        
        Is based on application domain entities necessary to implement the functional requirements.
        
        It focuses on functional requirements and the main building blocks and key abstractions decomposing of the system.
        
        The view basically is an abstraction of the system's functional requirements.
        
        It is typically used for object-oriented modeling from where the static and dynamic system structures emerge.
        
        The logical view specifies system decomposition into conceptual entities (such as objects), and connection between them (such as associations).
        
        The logical view is typically supported by UML static diagrams such as: class/object diagram and UML dynamic diagrams such as interaction overall diagram, sequence diagram, communication diagram, state diagram, and activity diagram
      - The Development or Module View
        
        Describes the software static organization of the system modules.
        
        It is derived from the logical view.
        
        Modules such as namespaces, class library, sub-system, or packages are building blocks that group classes for further development and implementation.
        
        Addresses the sub-system decomposition and organizational issue.
        
        In this view, the software is packaged and partitioned into small units such as program libraries or sub-systems that are developed by many teams of developers
        
        Each package has its own visibility and accessibility as package or default scope visibility (see static structure discussion above).
        
        The development view maps software component elements to actual physical directories, files in the development environment.
        
        UML diagrams such as package diagrams and component diagrams are often used to support this view.
      - The scenario view
        
        Describes the functionality of the system, i.e., how user will use the system and how the system provides services to the users.
        
        This view provides a foundation for other 4 views and lets them work together seamlessly and coherently.
        
        It helps designers discover architectural elements during design and helps to validate the architectural design afterward.
        
        Helps to make the software architecture consistent and validated against functional and non-functional requirements.
      - The Process View
        
        Focuses on the dynamic aspects of the system, i.e., its execution time behavior.
        
        Is also derived from logical view.
        
        Is an abstraction of processes or threads dealing with process synchronization and concurrency.
        
        It contributes to many non-functional requirements and quality attributes such as scalability and performance requirements.
        
        Is a coordination view of the system's processes and the communications between them.
        
        Is a runtime execution unit.
        
        A software system can be decomposed into many such units.
        
        The quality attributes such as performance, scalability, concurrency, synchronization, distribution, and system throughput are addressed here.
        
        Takes care of the concurrency and synchronization issues between sub-systems in the system.
        
        The non-functional requirements are also important issues the process view must address such as multi-threading, synchronous and asynchronous communications for performance and availability.
        
        The UML activity diagrams and interaction overview diagram support this view.
        
        Many architectural styles such as pipe & filter, multi-tier, and others can be applied in the process view
      - The Physical View
        
        Describes installation, configuration, and deployment of the software application.
        
        It concerns itself with how to deliver the deployable system.
        
        Shows the mapping of software onto hardware.
        
        Is particularly of interest in distributed or parallel systems
        
        A physical view also takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), throughput performance, scalability performance, and security.
        
        The stakeholders of this view are system installers, system administrators, system engineers, and operators.
      - The User Interface View
        
        Giving user-computer clear interface view while hiding implementation details.
        
        May be provided as a series of screen snapshots or a dynamic, interactive prototype demo.
        
        Any modification on this view will have direct impact on the scenarios view.
- - - - Software Runtime Element
        
        same element in a code structure can implement or support multiple runtime elements
        
        several code structure elements may implement or support a single runtime element
      - Run-time Connector Properties
        
        inherit attributes from their source-code structure counterparts, with a few extra attributes
        
        Multiplicity
        
        One element can be connected to multiple elements
        
        Distance and connection media
        
        Two connected element may communicate in the same thread, in the same process , on the same computers, or on different computers across a network
        
        Universal invocable
        
        irrespective of hardware/software platform, and programming languages
        
        Self-descriptive
        
        allows clients to choose service providers dynamically
      - A runtime project consists of elements
        
        Processes
        
        Web services
        
        Threads
        
        Distributed objects
    - - Can be used for resource allocation
    - - A software project is typically implemented in multiple files
      - The connectors at this level are in the form of module dependency
      - Static connectors may exhibit some attributes
        
        Synchronization
        
        Sequence
        
        Direction
  - - - Rule 1: Reentrant
        
        describes a computer program or routine that is written so that the same copy in memory can be shared by multiple users
        
        it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete executing
        
        making sure that no instruction modify the contents of variable values in other instructions within the program
      - Rule 2: Handle Bottle-Neck First
        
        Treat bottle-neck functionality using approaches
        
        Improving its efficiency by replication
        
        allocate cluster or multi-CPU computers for bottle-neck modules in deployment
        
        Wrap it as a separate and highly independent module
      - Rule 3: Make Things Simple
        
        Split it into smaller ones
        
        Vertical Layers
        
        Horizontal Layers
  - - - Availability
      - Security
      - Reliability
      - Efficiency
    - - Blocking
        
        allows one of its incident elements to send a request to another and wait for a response
        
        the element will be blocked from further execution until it receives a response
      - Non-blocking
        
        allows one of its incident elements to send a request to another and continues its execution without waiting for a response
      - initiator
        
        One Initiator
        
        only allows one of the two connected elements initiates the request
        
        Two Initiator
        
        either of the two elements can make the request
    - - Signature based
        
        Usually method invocation
        
        Method parameter indicates operation type
      - Protocol based
        
        A protocol-based connector can implement multiple operation types with a single binding signature
- - - - Whole system as transformation of successive sets of data.
      - No Inreraction between modules
      - Connection can be
        
        IO Steam
        
        Filesm, Buffers, Pipes
      - Modules do not need to know identify of each other
      - System decomposed into modules
    - - Many sub-categories exist
        
        Batch sequential
        
        Process Control
        
        Pipe & Filter
      - To adopt which one depends on the nature of the problem
  - - - Usually done in batch processing language of shell script
      - Direct implementation in coding
      - DOS batch file
    - - Data are batched
    - - No interactive interface
      - No concurrency and low throughtput
      - High latency
    - - Simple division between sub-system
      - Each sub-system can be a stand-alone
  - - - Independent modules
      - Data connections
    - - Connections are stream oriented
      - Concurrent processing
    - - Data Sink
      - Filter: independent data steam tranformer
        
        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: charater of 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 tranformed data in a downstream
    - - Active filter
        
        Pull in data and push out the transfromed data(pull/push)
        
        Its works with a passive pipe that provides read/write mechanisms for pulling and pushing
        
        EX: UNIX pipe
      - 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
    - - System can be broken into a series of processing steps over data stream, in each step filter consumes and moves data incrementally
      - Data format on the data stream is simple and stable, and easy to be adapted if it is necessary
      - There are significant work which can be pipelined to gain the performance
      - Suitable for producer/ consumer model
    - - Modifiability: Low due to coupling between filters
      - Simplicity: clear
      - Reusability is easy - plug and play
      - Flexibility: high, very modular design
      - Concurrency in high
      - Lower latency
    - - Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
      - Difficult to configure a P&F system dynamically
      - Data standards (ASCII, XML?)
      - Error handling issue
      - Not suitable for dynamic interactions
  - - - sub system
      - Connection
    - - Executor processor unit
      - Controller unit
    - - Controlled variable: target controlled variable
      - Input variable: measured input data
      - Manipulated variable: can be ajusted by the controller
    - - 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 manimulated variable
        
        Can be completele embedded
      - Limitations
        
        Requires more sensors to monitor system states
- - - - Interactive GUI component communication
      - Require loose coupling between components
      - Implementation of state machines
      - When event handlings in the application are not predictable
    - - Reusability of components
      - System maintenance and evolution
      - Framework availability
      - Independency and flexible connectivity
      - Parallel execution of event handlings is possible
    - - It is difficult to test and debug
      - tighter coupling between event sources
      - Reliability and overhead of indirect invocations may be an issue
    - - PAC, message-based, MVC, multi-tier, and state machine architectures
  - - - Message consumers
      - Message service providers
      - Message producers
    - - message topic: one-to-many
      - message queue : one-to-one
  - - - The message consumer does not know who produced the message
      - Providing high degree of anonymity between message producer and consumer
      - Supporting for concurrency among consumers
      - Providing scalability and reliability of message delivery
      - Supporting batch processing
      - Supporting loose coupling between message producers and consumers
    - - Difficult to determine the numbers of agents needed to satisfy the loose couplings between agents
      - Capacity limit of message queue
      - Generate development complexity since communications between agents only take place between the control of agents
      - 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
      - The event handler must be ready in order to be able to intercept an event
      - Commonly used in the connection between the Model sub-system and the View sub-system in an MVC or PAC architecture
- - - - 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
    - - Synchronization of duplicated data
      - Cost of data transmission
      - Vertical or horizontal partitions
      - Collaboration (two-phase transaction commitment)
    - - 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
  - - - Knowledge sources
      - Listeners or subscribers
    - - 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
    - - They don’t need to interact with each other
      - Only interact and respond to the blackboard subsystem
      - Each knowledge source is relatively independent
    - - 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
    - - 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