Please enable JavaScript.

Coggle requires JavaScript to display documents.

Object - Oriented, Component Based Architecture, SOLID Principle,…

- - - - Public interface
      - Detailed implementation
  - - - Association
      - Aggregation
      - Composition
    - - Generalization
      - Realization
    - - Dependency
- - - - Describes user interactions with the system which indicate all necessary operations of the component
      - We can map use case diagram to the provided service interfaces of the first-cut component specification
    - - Depicts the relationships of the business process entities in the domain
      - Extract business process entities that can exist independently without any associated dependency on other entities
      - Recognize and discover these independent entities as new components
- - - - Middle layer is easy to change
      - Have portable and nonproprietary design and implementation
      - Middle layer can provide multi-threading support
      - Reduces traffic on the network
- - - - It coordinates communications, passing on request and returning replies
      - It stores all servers’
      - registration information, their functionalities and location information
      - It provides APIs for clients to request, servers to respond, registering or unregistering server components, transferring messages, and locating servers.
    - - Mediates between the client and the broker and providing additional transparency between them.
      - To the client, a remote object appears like a local one.
      - The proxy hides inter-process communication at protocol level, marshals the parameter values, and unmarshals results from the server.
      - The stud is generated at compilation time and deployed at client side to be used as a proxy for client
    - - It is also generated by service interface compilation and deployed at server side
      - Encapsulates low-level system specific networking functions like client proxy and provides high level APIs to mediate between the server and the broker
      - It receives and unpacks the requests, unmarshals the arguments, and calls the appropriate service.
      - When receives the result back from the server, it also marshals results before sending it back to the client.
    - - Hide implementation details when two brokers interoperates
      - Can translate requests and parameters from one format to another
    - - Connects components using designated protocol standards such as
        
        TCP/IP
        
        OIIP
        
        SOAP
      - The request carries data in a message document or method invocation format.
- - - - Where reliability is crucial
- - - - interface defined and published - concurrent development by multiple teams
      - each layer is thoroughly tested -> no deeply nested debugging
- - - - Model: model of application’s logic
        
        The Model manages the behavior and data of the application domain.
        
        The model responds to requests for information about its state (usually from the view)
        
        responds to instructions to change state (usually from the controller).
      - View: deal with graphic representation
        
        The View renders the model into a form suitable for interaction, typically a user interface element.
        
        Multiple views can exist for a single model for different purposes.
        
        A view port typically has a one to one correspondence with a display surface and knows how to render to it.
      - Controller: contains the interface between model and view
        
        The Controller receives user input and initiates a response by making calls on model objects.
        
        A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.
      - model does not (and should not) know view and controller. It should not depend on the other two components.
    - - Simplified System
        
        Controller/View
        
        Model
      - Controller/View
        
        Takes care of input/output, interface to model
      - Model
        
        In charge of business logic
    - - Difference: completely separate view and controller
      - one model can correspond to multiple views
    - - Suitable for where multiple views needed for a single data model and the graphics interfaces prone to data changes.
      - There are clear divisions between controller, view, and data modules so that different professionals can be assigned to work on different aspects of such applications.
    - - Easy to plug in new or change interface views,
      - Very effective for developments (team working by different professionals)
    - - 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
  - - - Each agent has three components
        
        Presentation
        
        Abstraction
        
        Control
      - Each agent responsible for one function
      - Sometimes all agents share the same control
      - Within each agent there are no direct connections between the abstraction component and presentation component
    - - PAC is suitable for distributed systems where all agents are distantly distributed and each agent has its own functionalities with data and interactive interfaces
      - Sometimes, middle level agents, the interactive presentations are not required.
    - - 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
      - Supporting concurrency
    - - Overhead due to the control bridge.
      - Difficult to design agents
- - - - A sender does not care much of the response from the receivers except for guaranteed message delivery
      - Implemented as a Message-Oriented Middleware (MOM) providing a reliable message service on a distributed system
    - - Used to build reliable, scalable, and flexible distributed applications supporting asynchronous communication
      - Peer-to-peer client-server architecture
      - The high degree of independency between components
      - Its high scalability, interoperability in heterogeneous networks, and reliability
      - A messaging client can produce and send messages to other clients, they can also consume messages from other clients
      - Each 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
  - - - Control level setting of message acknowledgement
      - Message persistence setting without loss
      - Message priority level setting
      - Message expiration setting
- - - - Its clients taking control of flow logic
      - Client may access the repository
    - - Virtual repository
        
        Most DB allows users to create views that are virtual repositories since they do not exist physically.
        
        Built up on the top of multiple physical repositories
        
        Benefit
        
        Simplify the overall complexity of overall database structure
        
        Security management in terms of scope of data of manipulation for different users
      - Distributed repository system (distributed database system)
        
        All data are distributed over all sites linked by network
        
        Data are replicated in order to Improve reliability and local accessibility
        
        Other issues - concerns
        
        Vertical or horizontal partitions
        
        Synchronization of duplicated data
        
        Cost of data transmission
        
        Collaboration (two-phase transaction commitment)
  - - - Blackboard: Used to store data (Hypothesis and fact)
      - Knowledge Source: stores domain specific knowledge
      - Controller: initiating the blackboard and knowledge sources
    - - Data driven – a change in the data stored in Blackboard triggers one or more knowledge source  might lead to more changes
    - - Suitable for solving immature and complex AI problems
      - The problem spans multiple disciplines, each of which has complete different knowledge expertise
      - Optimal, partial, or approximate solution is acceptable
      - Exhausted searching is impossible.
    - - Scalability: easy to add new knowledge source
      - Concurrency: all knowledge sources can work in parallel
      - Reusability of knowledge source agents
    - - Tight dependency between the blackboard and knowledge source
      - Synchronization of multiple agents is an issue
      - Debugging and testing of the system is a challenge.
- - - - Traditional data processing model
      - Widely used in 1950’s – 1970’s
    - - Applicable Design Domains: Data are batched
      - Benefits:
        Simple division between sub-systems, Each sub-system can be a stand-alone
      - Limitation: No interactive interface, No concurrency and low throughput, High latency
  - - - Similar to Batch Sequence: Independent modules, Data connectors
      - Difference: Connectors are stream oriented, Concurrent processing
      - Basic Concept
        
        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
        
        Classification of Filters
        
        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.
        
        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
      - Push only (Write only)
        
        A data source may push data in a downstream
        
        A filter may push data in a downstream
      - Pull/Push (Read/Write)
        
        A filter may pull data from an upstream and push transformed data in a downstream
    - - 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
      - System can be broken into a series of processing steps over data stream, in each step filter consumes and moves data incrementally.
      - Advantages
        
        Concurrency is high.
        
        Reusability is easy – plug and play.
        
        Modifiability: Low due to coupling between filters
        
        Simplicity: Clear
        
        Flexibility: High, very modular design
        
        Lower latency
      - Disadvantages
        
        Data standards (ASCII, XML?)
        
        Overhead of data transformation among filters such as parsing is repeated in two consecutive filters
        
        Difficult to configure a P&F system dynamically
        
        Not suitable for dynamic interactions
        
        Error handling issue
  - - - Suitable for embedded System
      - Composed of
        
        Sub-systems
        
        Connectors
      - Two types of sub-systems
        
        executor processor unit
        
        controller unit
      - System depends on: Control Variables
    - - Controlled variable: target controlled variable
        
        E.g., Speed in a cruise control system
        
        E.g., Temperature in an auto H/A system
      - Input variable: measured input data
      - Manipulated variable: can be adjusted by the controller
        
        E.g., motor rotation speed, etc
    - - 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