Please enable JavaScript.
Coggle requires JavaScript to display documents.
CHAPTER 9. Interaction Oriented Software Architectures - Coggle Diagram
CHAPTER 9. Interaction Oriented Software Architectures
9.1 General natures:
Decomposed into:
Data module
provide data abstraction
all core business logic on data processing
Control Module
determines the flow of control involving
View selections
Communications between modules
Job dispatching
Certain data initialization and system configuration actions.
View presentation module
Responsible for visual or audio data output presentation
May also provide user input interface as well when necessary
Multiple views may be supported for the same data set.
Loose coupling between data abstractions and its presentations is helpful.
explicit method invocation
implicit registration/notification method invocation
9.2 Model-View-Controller (MVC)
3-way factoring
Objects of different classes take over the operations related to the application domain (the model)
the domain-specific software simulation
implementation of the application's central structure
The display of the application's state (the view)
Request data from their model
display the data
The user interaction with the model and the view (The controller)
contains the interface between
Associated models
Associated views
the input devices (e.g., keyboard, pointing device, time).
9.2.1. MVC-I
is a simple version of MVC architecture
The system is simply decomposed into 2 sub-systems
The Controller-View
takes care of input and output processing and their interfaces
takes appropriate action upon the changes on the model
The Model.
copes with all core functionality and the data.
notifies the Controller-View module of any data changes so that any graphics data display will be changed accordingly
The Controller-View module registers with the Model module
9.2.2. MVC-II
Separate Controller from View
Usually has a central controller for dispatching requests to each responsible controller
Limitations
Does not fit well agent-oriented applications such as
Interactive mobile
Robotics applications.
Any data model change expensive
In some cases the division between the View and the Controller is not clear
9.3 Presentation-Abstraction-Control (PAC)
Similar to MVC but with some important differences.
The PAC was developed from MVC to support the application requirement of multiple agents in addition to interactive requirements.
In PAC, the system is decomposed into a hierarchy of many cooperating agents.
Each agent has 3 components
Presentation
responsible for both data input and
data output in GUI interfaces where the data come from the Abstraction component.
Abstraction
providing logical data concepts and services
encapsulating all detailed data manipulation.
Control
is in charge of communications with other agents
is a mediator between the Presentation component and the abstraction component within the agent
The top-level agent provides
core data and business logics
The bottom level agents
provide detailed specific data and presentations.
A middle level agent play
a role of coordinator of low-level agents.
There are no direct connections between
Abstraction component
Presentation component
Applicable domain
Suitable for an interactive system
Suitable when the coupling among the agents is expected to be loose
Benefits
Support of multi-tasking and multi-viewing
Support agent reusability and extensibility.
Easy to plug-in new agent or replace an existing one
Support for concurrency where
multiple agents are running in parallel in
different threads or
different devices or
computers.
Limitations
Overhead due to the control bridge
Difficult to determine the right number of the agents
Complete separation of presentation and abstraction