Please enable JavaScript.

Coggle requires JavaScript to display documents.

Lecture 7,8 Architecture Styles :red_flag:A fundamental structural…

- - - - Pipe and Filter
      - Batch Sequence
        
        Assume each step runs to completion before the next step starts
  - - - Variant
        
        Client Server
        
        Object Brokers
        
        Peer-to-Peer
    - - 3 layer
      - 2 layer
      - 4 layer
      - open architecture
      - close architecture
  - - - Separates control policy from the controlled process
      - Handles real-time, reactive computations
    - - Difficult to specify the timing characteristics and response to disturbances.
  - - - Unnamed participants using the publish/subscribe paradigm (Event Style)
        
        Event based (implicit invocation)
        
        Make use of a message manager
        
        publish/subscribe paradigm
        
        Interesting properties
        
        Announcers of events don't need to know who will handle the event
        
        Supports reuse, and evolution of systems (add new agents easily)
        
        Disadvantages
        
        Components have no control over ordering of computations
      - Named participants (Communicating Processes style)
        
        Communicating processes style
        :red_flag:Classic multiprocess systems
        
        Goal is to achieve the quality of scalability
        
        Client-server is a well-know subtype
        
        A server exists to serve data to one or more clients, which are typically located across a network.
    - - Send data to each other but typically do not directly control each other
  - - - Interpreters
      - Rule-based systems
      - Syntactic shells
      - Command language processors
  - - - i. Locationally heterogeneous
        
        Drawing of its runtime structures will reveal patterns of different styles in different areas.
      - ii. Hierarchically Heterogeneous
        
        A component of one style, when decomposed, is structured according to the rules of a different styles
      - iii. Simultaneously Heterogeneous
        
        Any of several styles may well be apt descriptions of the system.
  - - - Centralized data store shared by all surrounding software components
    - - Clients are relatively independent of each other
      - Data store is independent of the clients
      - Scalable: New clients can be easily added
    - - Repository Architectural Styles
        
        Passive Data Store
        
        Active software components controls logic flow & check changes of data store
      - Blackboard Architectural Styles
        
        Blackboard component as central data repository
        
        Data store is active
        
        Clients(knowledge source,listeners or subscribers) are passive
        
        Logical flow is determined by current data status in the data store
        
        3 major components
        
        Knowledge source
        
        Solves problem and aggregate partial results, providing specific expertise needed by the application
        
        Blackboard
        
        Shared repository of problems, solutions, suggestions and contributed information.
        
        Control shell
        
        Control flow of problem-solving activity in the system.
        
        Manage the task and check the state.
        
        Interesting properties
        
        Reduce the need to duplicate complex data
        
        Disadvantages
        
        Blackboard becomes a bottleneck
    - - Model-View-Controller
        
        Model
        :star: Contains application's data
        
        View
        :star: Displays some portion of the underlying data and interacts with the user
        
        Controller
        :star: Mediates between the model and the view and manages the notifications of state changes
        
        Constraint:
        
        There must be at least one instance each of model, view and controller
        
        The model component should not interact directly with the controller
        
        Weaknesses
        
        The complexity may not be worth it for simple user interfaces
        
        The model, view, and controller abstractions may not be good fits for some user interface toolkits.