Chapter 9 - Interaction Oriented Software Architectures

Get Started. It's Free
or sign up with your email address
Chapter 9 - Interaction Oriented Software Architectures by Mind Map: Chapter 9 - Interaction Oriented Software Architectures

1. 1. Overview

1.1. Interaction-oriented software architecture

1.1.1. Control module

1.1.1.1. Determines the flow of control involving view selections

1.1.1.2. Communications between modules, job dispatching, and certain data

1.1.1.3. Initialization and system configuration action

1.1.2. Data module

1.1.2.1. Provides the data abstraction and all core business logic on data processing

1.1.3. View presentation module

1.1.3.1. Visual or audio data output presentation and may also provide user input interface when necessary

1.2. Categories of interaction-oriented architecures

1.2.1. Presentation-abstraction-control (PAC)

1.2.2. Model View Controller (MVC)

2. 2. MVC

2.1. Applicable domain of MVC architecture

2.1.1. Multiple views are needed for a single data model and the interface are prone to frequent data changes

2.1.2. Clear division between controller, view and data modules

2.2. MVC - I

2.2.1. Controller - view

2.2.1.1. Takes care of input and output processing and their interfaces

2.2.1.2. Register with (attaches to) the data module

2.2.2. Model

2.2.2.1. Copes with all core functionality and the data

2.2.2.2. Notifies the controller - view module of any data changes

2.3. MVC - II

2.3.1. View

2.3.1.1. Displays the data

2.3.2. Model

2.3.2.1. Provides all core functionality and data supported by a database

2.3.3. Controller

2.3.3.1. Takes input request

2.3.3.2. Validates input data

2.3.3.3. Initiates the model and the view and their connection

2.3.3.4. Dispatches tasks

2.4. Benefits

2.4.1. Easy to change or plug in new interface view

2.4.2. Many MVC vender framework toolkits are available

2.4.3. Multiple views synchronized with same data model

2.4.4. Effective for developments if graphics, programming and database development professionals are working in a team in a designed project

2.5. Limitations

2.5.1. This division between the View and the Controller is not clear in some cases

2.5.2. Not suitable for argent-oriented applications such a interactive mobile and robotics applications

2.5.3. Multiple pairs of controllers and view based on the same data model make any data model change expensive

3. 3. Presentation Abstraction Control (PAC)

3.1. Limitation

3.1.1. Extra time lost due to the control bridge between presentation and abstraction and the communication of controls among agents

3.1.2. Difficult to determine the correct number of the agents due to the loose coupling and high independence between agents

3.2. Benefits

3.2.1. Easy to plug in new agent or replace an existing one

3.2.2. Support of multitasking and multiviewing

3.2.3. Support agent reusability and extensibility

3.2.4. Support for concurrency where multiple agent run in parallel in different threads or on different devices or computers

3.3. Definition

3.3.1. System is decomposed into a hierarchy

3.3.1.1. Top-level agent

3.3.1.1.1. Provides core data and business logics

3.3.1.2. Middle-level agent

3.3.1.2.1. Coordinate low-level agents

3.3.1.3. Bottom-level agents

3.3.1.3.1. Provide detailed data and presentations

3.3.2. Each agent has three components

3.3.2.1. Control

3.3.2.1.1. Communicate with other agents

3.3.2.2. Presentation

3.3.2.3. Abstraction

3.4. Applicable domain of the PAC architecture

3.4.1. Suitable for an interactive system where the system can be divided into many cooperating agents in a hierarchical manner

3.4.2. Coupling among the agents is expected to be loose so that change on an agent do not affect others