Please enable JavaScript.
Coggle requires JavaScript to display documents.
CHAPTER 9 Interaction-Oriented Software Architectures - Coggle Diagram
CHAPTER 9 Interaction-Oriented Software Architectures
Overview
categories of interaction-oriented architectures
Presentation-Abstraction-Control (PAC)
Model-ViewController (MVC)
interaction-oriented architectures
view presentation module
responsible for visual or audio data output presentation and may also provide user input interface when necessary
control module
determines the flow of control involving view selections
communications between modules, job dispatching, and certain data initialization
system configuration actions
data module
provides the data abstraction and all core business logic on data processing
Model-View-Controller (MVC)
MVC-I
Model module
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
Controller-View module
registers with (attaches to) the data module
takes care of input and output processing and their interfaces
MVC-II
Model module
provides all core functionality and data supported by a database.
View module
displays the data
Controller module
takes input requests
validates input data
initiates the Model and the View and their connection
dispatches tasks
Applicable domains of MVC architecture:
■ Interactive applications where multiple views are needed for a single data model and the interfaces are prone to frequent data changes.
■ Applications with clear divisions between controller, view, and data modules so that different professionals can be assigned to work on different aspects of such applications concurrently.
Benefits:
■ Many MVC vendor framework toolkits are available.
■ Multiple views synchronized with same data model.
■ Easy to change or plug in new interface views, allowing updating of interface views with new technologies without overhauling the rest of the system.
■ Very effective for developments if graphics, programming, and database development professionals are working in a team in a designed project.
Limitations:
■ Not suitable for agent-oriented applications such as interactive mobile and robotics applications.
■ Multiple pairs of controllers and views based on the same data model make any data model change expensive.
■ The division between the View and the Controller is not clear in some cases.
Related architecture:
■ PAC, and implicit invocation such as event-based, multi-tier
architecture
Presentation-Abstraction-Control (PAC)
Definition
system is decomposed into a hierarchy of cooperating agents
The bottom level agents
provide detailed data and presentations
A middle-level agent
may coordinate low-level agents
The top-level agent
provides core data and business logics
Each agent has three components
Abstraction
Control
Presentation
Applicable domains of the PAC architecture:
■ Suitable for an interactive system where the system can be divided into many cooperating agents in a hierarchical manner and each agent has its own specific assigned job.
■ Suitable when the coupling among the agents is expected to be loose so that changes on an agent do not affect others.
Benefits:
■ Support of multitasking and multiviewing
■ Support agent reusability and extensibility
■ Easy to plug in new agent or replace an existing one
■ Support for concurrency where multiple agents run in parallel in different threads or on different devices or computers
Limitations:
■ Extra time lost due to the control bridge between presentation and abstraction and the communication of controls among agents.
■ Difficult to determine the correct number of the agents due to the loose coupling and high independence between agents.
■ Complete separation of presentation and abstraction by control in each agent generates development complexity since communications between agents only take place between the controls of agents.
Related architecture:
■ Layered, multi-tier, and MVC