Please enable JavaScript.
Coggle requires JavaScript to display documents.
Interaction Oriented Architecture (Chapter 9) (Interaction oriented SW…
Interaction Oriented Architecture
(Chapter 9)
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)
Interaction oriented SW architecture
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:
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.
Separation of user interactions from data abstraction and business logic
Motivation
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
Key Idea
Decompose user-interaction software
Data module
Flow control module
View presentation module
Benefits:
Loose coupling
Exchangeability
Maintainability
Extensibility
Categories
Model View Controller (MVC)
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.
Example java bean
Presentation-Abstraction-Control (PAC)
