Please enable JavaScript.

Coggle requires JavaScript to display documents.

Chapter 5 - 12, Limitations:, Benefits:, 5.4 Process Control Architecture,…

- - - - Applicable Design Domains
        
        For applications which have classes that are close related each other.
        
        For systems that can be divided between portions providing generic services to the application of the system.
    - - Idea
        
        Physical Implementation.
        
        Examples
        
        Web service (ip, tcp, http, xml, SOAP, WSDL, BPEL, UDDI)
        
        OSI 7-layer Network Stack
        
        OS (driver, kernel, system call, application)
        
        Functions in one layer usually organized in one package
        Some times deployed as services.
    - - Benefits
        
        Enhanced reusability and interchangeability.
        
        Incremental software development.
        
        Component-based technology is a suitable.
        
        Promotion of portability.
        
        Enhanced independence of upper layer to lower layer.
  - - - Benefits
        
        Simulation for non-native and disaster working model.
        
        Simplicity of the software development.
        
        Portability and machine platform independency.
    - - Limitations
        
        Slow execution of the interpreter.
        
        Additional overhead due to the new layer.
    - - Applicable Design Domain
        
        Sample applications such as interpreters of microprogramming, XML processing, script command language execution, rule-based system execution, Smalltalk and Java interpreter typed programming language.
        
        Suitable for solving a problem by simulation or translation.
  - - - Characteristics
        
        Parallel computing and accuracy of computation.
    - - Define
        
        A variant of main-subroutine architecture.
        
        Slaves may perform the same functional task by different algorithms and methods or a totally different functionality.
        
        It supports fault tolerance and system reliability.
        
        The master selects a particular result among slaves by certain selection strategies.
        
        The slaves provide replicated services to the master.
    - - Applicable domain
        
        Where reliability is crucial.
  - - - Examples
        
        Microsoft .NET
        
        TCP/IP
        
        Unix operating system
  - - - Plus Point
        
        Any changes to a specific layer may affect only its adjacent upper layers.
  - - - Purpose
        
        A “main” program calls sub-routines and accomplishes task
        
        Encourage re-use of modules
        Idea.
        
        System decomposed into sub-routines
    - - How Subroutine Call is Supported
        
        Function Call Supported by High Level Language
        
        Much more tricky
        
        Parameter passing
        
        Pass by value
        
        Pass by reference
        
        Much more convenient
        
        Function Call Supported by Assembly
        
        Protect old register values by pushing to stack
        
        Call the subroutine
        
        Set parameters in register
        
        Software Interrupt
        
        Jump, Long Jump, Call instruction
    - - Define
        
        Probably the oldest and most widely used architecture.
    - - Limitation
        
        Tight coupling may cause ripple impacts as compared to OO design.
        
        Globally shared data are vulnerable.
    - - Benefits
        
        Easy to decompose the system.
        
        Can still be used in sub-system of OO Design.
  - - - Mapping Process
        
        Map each flow into a subroutine
        
        Generally
        
        A main process controls the overall flow.
        
        Identify transform and transaction flows
    - - Two types of flow
        
        Transaction Flow
        
        Transaction Flow: depending on input data, take different control actions (branch)
        
        Transform Flow
        
        Transform Flow: input data get processed and results in output data (sequential)
- - - - Update of user view however business logic is not changed
      - Validating user input
        
        buffer overflow
        
        SQL injection attack
  - - - Data module
      - Flow control module
      - View presentation module
    - - Loose coupling
        
        Exchangeability
        
        Maintainability
        
        Extensibility
  - - - Model View Controller (MVC)
      - Presentation-Abstraction-Control (PAC)
  - - - 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), and
      - responds to instructions to change state (usually from the controller).
    - - 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.
    - - 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.
  - - - 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
  - - - Suitable for where there are many cooperating agents in a hierarchical structure.
      - The coupling among the agents is expected very loose
    - - Supporting agent reusability and extensibility
      - Easy to plug in new agent or replace an existing agent
      - Supporting multi-tasking, multi-viewing
      - Supporting concurrency
    - - Overhead due to the control bridge.
      - Difficult to design agents
- - - - A UML component can be mapped to any target technology component
      - EBJ Component (.jar file)
        
        Java Web Component (.war file)
        
        What about MS .Net Component? - .dll file
  - - - The component-oriented design defines components and connections between them instead of classes and connections between classes
    - - First identify all components and their interfaces
    - - Reduced time in market
      - Lower development costs by reuse of the existing components
      - increased reliability with reuse of the existing components
  - - - Abstract Interface
      - Concrete Implementation Classes
    - - Some IDE tools support visualization of components, e.g., VS Studio .Net Toolset
      - However, it does not mean that each component should have such a visual representation
    - - Java Counter
        package counter;
        interface Counter {
        public void setCount(int c);
        public int getCount(); public void inc();
        }
      - Implementation File
        import counter.*;
        class CouterImpl implements Counter {
        private int count;
        public void setCount(int c){
        count = c;
        }
        public int getCount(){
        return count;
        }
        public void inc() {
        count ++;
        }
        }
- - - - Define
        
        Consumers are interested in some events or messages issued by a producer.
        
        Also called publisher-subscriber or producer-consumer patterns.
        
        Subscribers are interested in some events or messages issued by a publisher.
    - - Two different modes
        
        Non-buffered
        
        Buffered
  - - - Benefits
        
        Independency and flexible connectivity
        
        Dynamic registration and deregistration can be done dynamically at run-time.
        
        Framework availability
        
        Many vendor APIs such as Java AWT and Swing components available.
        
        System maintenance and evolution
        
        Easy to update both of event sources and targets.
        
        Reusability of components
        
        Easy to plug-in new event handlers without affecting the rest of the system.
        
        Possibility of parallel execution of event handling.
    - - Limitations
        
        The event source cannot determine.
        
        When a response finished or the sequence of all responses
        
        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.
        
        Hard to predict and verify responses and the order of responses from the listeners.
        
        Difficult to test and debug the system.
    - - Applicable Domain
        
        Suitable for the implementation of state machines.
        
        Suitable for applications that require loose coupling between components that need to notify or trigger other components to take actions upon asynchronous notifications.
        
        Suitable when event handlings in the application are not predictable.
        
        Suitable for interactive GUI component communication and Integrated Development Environment (IDE) tools.
    - - The non-buffered event-based implicit invocation architecture breaks the software system into two partitions
        
        Event listeners
        
        The event registration process connects these two partitions.
        
        Event sources
        
        There is no buffer available between these two parties.
  - - - Publish-Subscribe Messaging (P&S)
        
        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.
        
        Publishers and subscribers have a timing coupling dependency.
        
        One difference between P&S from P2P is that each topic message can have multiple consumers.
        
        Message topic publishers and subscribers are not aware of each other.
        
        The P&S messaging architecture is a hub-like architecture, where publisher clients send messages to a message topic that acts like a bulletin board.
        
        The system delivers the messages to all its multiple subscribers instead of single receiver as in the message queue system.
    - - Point-to-Point Messaging (P2P)
        
        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.
        
        A sender and a receiver of a message have no timing dependencies, that is, the receiver can still get the message even it was not available when the sender sent the message.
        
        Each message has only one consumer, i.e., the message will be “gone” once it is delivered.
        
        The message queue architecture is a point-to-point structure between producer and consumer.
        
        A P2P messaging architecture is composed of message queues, senders, and receivers.
        
        Each message is sent to a destination (a specific queue) which is maintained by the consumer; consumer clients extract messages from these queues.
        
        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.
    - - The messaging system architecture is just a peer-to-peer client-server architecture.
      - Its high scalability, interoperability in heterogeneous networks, and reliability also make the messaging system more popular.
      - The high degree of independency between components within the messaging system is one of its most important features.
    - - The buffered message-based software architecture breaks the software system into three partitions
        
        Message producers
        
        Message service providers
        
        Message consumers
      - Connected asynchronously
        
        message topic: one-to-many
        
        message queue: one-to-one
      - This architecture is also considered data-centric.
    - - Message
        
        A message is a structured data with a message id, message header, property, and a body.
        
        A typical example of a message is an XML document.
        
        Messaging
        
        Messaging is a mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably.
    - - The message-based software architecture has been used for a long time.
      - Messaging systems are used to build reliable, scalable, and flexible distributed applications supporting asynchronous communication.
    - - 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.
      - A messaging client can produce and send messages to other clients, they can also consume messages from other clients.
  - - - Providing scalability and reliability of message delivery; reliability mechanisms.
        
        Message persistence setting without loss.
        
        Message priority level setting.
        
        Control level setting of message acknowledgement.
        
        Message expiration setting.
        
        Supporting batch processing.
        
        Supporting loose coupling between message producers and consumers and between legacy systems and modern systems for integration development.
    - - Providing high degree of anonymity between message producer and consumer.
        
        The message consumer does not know
        
        Where the producer lives on the network (location independence).
        
        Who produced the message (user independence).
        
        When the message was produced (time independence).
        
        Supporting for concurrency among consumers and between producer and consumers.
- - - - Running on different processors
      - So, it is decomposed into two major subsystems:
        
        Client
        
        Server
      - Server process receives the request, carries it out, and sends a reply to the client
    - - Responsibility separation such as user interface presentation and business logic processing
      - Reusability of server components
    - - Lack of heterogeneous infrastructure to deal with the requirement changes
      - Security complications
      - Server availability and reliability
      - Testability and scalability
  - - - Front-end tier - User interface presentation tier
      - Middle-end tier - Business logic tier
        
        Manages business logic and execution
      - Back-end tier - DB management tier
        
        Handles database
    - - Enhanced reusability and scalability by adding the middle tier
        
        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
    - - Difficulty in testing due to lack of testing tools
        
        Adding multiple servers in the system makes the server reliability and availability even more critical
  - - - An object can call methods of another object without knowing that this object is remotely located.
      - CORBA is a well-known open standard that allows you to build this kind of architecture.
  - - - Service provider register services through broker
      - Clients discover services through broker
      - Clients submit requests to broker
      - Broker massages requests from clients and relay results from service provider
    - - CORBA, RPC, and RMI
    - - Server component implementation and location transparency,
      - Changeability and extensibility,
      - Feasibility of run time changes of server components (add or remove server components)
    - - Low fault tolerance
      - Inefficiency due to the overhead of proxies
      - Difficulty testing
  - - - It makes SOA software much easier to evolve and update.
      - Interoperability: Technically any client or any service can access other services regardless of their platform, technology, vendors, or language implementations.
      - The implementation of a service will not affect the application of the service as long as the exposed interface is not changed.
      - Reusability: Any service can be reused by any other service,. Because clients of a service only need to know its public interfaces, service composition and integration become much easier.
      - Each service component is independent from other services due to the stateless service feature.
      - SOA based business application development comes much more efficient in term of time and cost.
      - Loosely-coupled connection: Loose-coupling is the key attribute of SOA.
      - Scalability: Loosely coupled services make themselves easy to scale.
      - The coarse-grained, document-oriented, and asynchronous service features enhance the scalability attribute.
- - - - decompose functionalities
        
        propose
        feasible architecture styles
        
        documented and collected in a set of candidate solutions
        
        whole process starts
        all over again, until the most appropriate architecture is identified
  - - - ATAM (Architecture Trade-off Analysis Method)
      - ARID (Active Reviews for Intermediate Designs)
      - SAAM (Software Architecture Analysis Method)
        
        Perform an evaluation on all candidate architecture designs, using
        the collection of scenarios
        
        ■ Expandability: Over time, more occupation types could be added into
        the system, such as AmericanFarmer, AmericanBusinessOwner, etc
        
        Modifiability: The format of tax forms and the method of calculating tax rates
        change every year. The system should be adaptable to such changes
        
        ■ Performance: Since millions of cases could be processed each day
        during peak times, time efficiency is very important. However,
        space efficiency is of less concern because the stakeholders have enough funding to purchase computer storage (which is cheaper
        each day)
        
        Define a collection of design scenarios that cover the functional and
        nonfunctional requirements. Quality attributes should be reflected.
        
        Perform an analysis on the interaction relationship among scenarios
- - - - Deletion
      - Retrieval
      - Update
      - Insertion
    - - Software component agents
      - Data Store
    - - Classified into two categories (based on Flow Control Strategy)
        
        Repository
        
        Data store is passive
        
        Clients of the data store are active
        
        Client may access the repository
        
        Batch transaction
        
        Interactively
        
        Its clients taking control of flow logic
        
        Blackboard
        
        Data store is active
        
        Flow of logic is determined by the current data status
        
        The clients of a blackboard system are called
        
        Knowledge sources
        
        Listeners or subscribers
        
        A new data change may trigger events so that the knowledge sources take actions to respond to these events. These actions may result in new data and change in logic flow …
        
        Clients are inactive/passive
  - - - Variants of Data Repository
        
        Other issues - concerns
        
        Vertical or horizontal partitions
        
        Collaboration (two-phase transaction commitment)
        
        Synchronization of duplicated data
        
        Cost of data transmission
        
        Summary
        
        Limitations
        
        Overhead cost of moving data on network
        
        High dependency between data structure of data store
        
        Data store reliability and availability
        
        Benefits
        
        System scalability and Reusability of agents:
        
        Reduce the overhead of transient data between software components
        
        Data integrity:
        
        easy to backup and restore,
        
        Application Domain
        
        Suitable for large complex information system
        
        Data transactions drive the control flow
        
        Related architecture
        
        Layered, multi-tier, and MVC
        
        Virtual repository
        
        Most DB allows users to create views that are virtual repositories since they do not exist physically.
        
        Benefits
        
        Security management in terms of scope of data of manipulation for different users
        
        Simplify the overall complexity of overall database structure
        
        Built up on the top of multiple physical repositories
        
        Distributed repository system
        
        Data are replicated in order to Improve reliability and local accessibility
        
        All data are distributed over all sites linked by network
      - Data in memory are shared by all agents and the agents don’t pass on data to each other directly
      - Every compiler system has its own reserved keyword table, identifier symbol table, constant table generated after lexical analysis, and syntax and semantics trees generated by syntax and semantics analysis
    - - Data store of the repository maintains all
        types of data including schema (metadata), data tables, and index files for data tables
      - a typical design domain for
        the repository architecture
    - - The biggest advantage of CASE tools is its centralized data with many supporting software tools which can generate different products for different purposes based on the same set of data.
  - - - Application Domain
        
        Optimal, partial, or approximate solution is acceptable
        
        The problem spans multiple disciplines, each of which has complete different knowledge expertise
        
        Exhausted searching is impossible.
        
        Suitable for solving immature and complex AI problems
      - Benefits
        
        Scalability: easy to add new knowledge source
        
        Reusability of knowledge source agents
        
        Concurrency: all knowledge sources can work in parallel
      - Related architecture
        
        Implicit invocation architecture such as event-based, MVC architecture
      - Limitations
        
        Tight dependency between the blackboard and knowledge source
        
        Debugging and testing of the system is a challenge.
        
        Synchronization of multiple agents is an issue
    - - Consists of three partitions
        
        Blackboard: Used to store data (Hypothesis and fact)
        
        controller: initiating the blackboard and knowledge sources
        
        Knowledge Source: stores domain specific knowledge
      - Data driven – a change in the data stored in Blackboard triggers one or more knowledge source 🡪 might lead to more changes
      - Blackboard: variation of data-centric
    - - Motivated by classroom teaching
        
        Blackboard
        
        Agents can work collaboratively or independently
        
        Teacher and students (agents) solve problems together
      - 1st Blackboard arch. developed in 1970’s
        
        mainly used for
        
        Weather forecast
        
        Speech recognition
      - A common knowledge base, the "blackboard", is iteratively updated by a diverse knowledge sources,
      - starting with a problem specification and ending with a solution.
    - - Dynamic interaction in a Blackboard system
    - - A UML diagram for rule-based blackboard software
    - - Properties
        
        They don’t need to interact with each other
        
        Each knowledge source is relatively independent
        
        Only interact and respond to the blackboard subsystem
- - - - There are two types of filters: active and passive.
        
        ■ An active filter pulls in data and pushes out the transformed data (pull/push); it works with a passive pipe that provides read/write mechanisms for pulling and pushing. The pipe and filter mechanism in Unix adopts this mode. The PipedWriter and PipedReader pipe classes in Java are also passive pipes that active filters must work with to drive the data stream forward
        
        A passive filter lets connected pipes push data in and pull data out. It works with active pipes that pull data out from a filter and push data into the next filter. The filter must provide the read/write mechanisms in this case. This is very similar to data flow architecture