Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 9 Interaction Oriented Architecture (PAC Presentation…
Chapter 9
Interaction Oriented Architecture
More and more SW involve user input/output interaction, so specific user interfaces to software design.
Interaction oriented SW architecture decomposes the system into
Data module
Control module
View presentation module
Data module
Provides data abstraction
All core business logic on data processing
Control module
Flow of control of view presentation
Communication between modules
Job dispatching
Certain data initialization
System configuration
View presentation module
Visual or audio data output presentation
Provide user interface when necessary
Key points:
Separation of user interactions from data abstraction and business logic
This is because
Many view presentation in different data formats
Multiple views is supported for the same data set.
Even for a specific view presentation, the view or interface may need to change so often, so the loose coupling between data abstraction and its presentation is helpful. This is supported in this style.
Overview
Software has to interact with people
From 1950’s, existing human-computer-interaction:
Punched Cards (1950’s)
Teletype Terminal (1970’s)
Personal Computer + Keyboard (1970’s)
Color Monitor + Mouse + GUI (1980’s)
Multimedia + Speech Recognition (1990’s)
Software grows more complex when richer user interaction is required
Many problems! Examples?
Update of user view however business logic is not changed
Validating user input
buffer overflow
SQL injection attack
Decompose user-interaction software
Data module
Flow control module
View presentation module
Benefits:
Loose coupling
Exchangeability
Maintainability
Extensibility
Model View Controller
Widely used in web applications
E.g., MS ASP.Net, Java Swing
First introduced in 1980’s SmallTalk
Key Idea
Model: model of application’s logic
View: deal with graphic representation
Controller: contains the interface between model and view
Note: model does not (and should not) know view and controller. It should not depend on the other two components.
Concept for model:
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).
Concept for View:
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.
Concept for Controller:
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.
MVC-I & MVC-II
Simplified System
Controller/View
Model
Controller/View
Takes care of input/output, interface to model
Model
In charge of business logic
Difference: completely separate view and controller
Summary MVC
Applicable domain
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.
Benefits:
Easy to plug in new or change interface views,
Very effective for developments (team working by different professionals)
Limitations:
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
PAC
Presentation Abstraction Control
PAC was developed from MVC to support the application requirement of multiple agents in addition to interactive requirements.
PAC: hierarchy structure for interacting or cooperating agents
Each agent has three components
Presentation
Abstraction
Control
Each agent responsible for one function
Sometimes all agents share the same control
Provides interaction between agents
Within each agent there are no direct connections between the abstraction component and presentation component
Usage
PAC is suitable for distributed systems where all agents are distantly distributed and each agent has its own functionalities with data and interactive interfaces.
Sometimes, middle level agents, the interactive presentations are not required.
Desktop Presentation Application that can browse and display presentation pages in a graphical one at a time.
Has 4 buttons
First page
Last page
Next page
Previous page
Applicable domain of PAC architecture:
Suitable for where there are many cooperating agents in a hierarchical structure.
The coupling among the agents is expected very loose
Benefits:
Supporting multi-tasking, multi-viewing
Supporting agent reusability and extensibility
Easy to plug in new agent or replace an existing agent
Supporting concurrency
Limitations:
Overhead due to the control bridge.
Difficult to design agents
Difference of MVC and PAC
They differ in their flow of control and organization.
PAC is an agent based hierarchical architecture, whereas MVC does not have any clear hierarchical architecture. All three modules are connected together.