Please enable JavaScript.
Coggle requires JavaScript to display documents.
Interaction-Oriented Software Architectures (Model-View-Controller (MVC)…
Interaction-Oriented Software Architectures
Overview
More and more software applications involve user input/output interactions and specific user interfaces to software systems
Software grows more complex when richer user
interaction is required
decomposes the system into
three major partitions
:
data module
control module
view presentation module
Data module
:
provides the
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
system configuration
actions.
View presentation module
:
visual or audio data output presentation
provide user input interface when necessary
Key point
: separation of user interactions from data abstraction and business data processing
Because
Many view presentation in different data formats
Multiple views is supported for the same data set.
Even for a specific view presentation, the interfaces or views may need to change often, so
loose coupling
between data abstractions and its presentations is helpful
Benefits
Loose coupling
:
Exchangeability
Maintainability
Extensibility
Two main categories
:
Model View Controller (MVC)
Presentation-Abstraction-Control (PAC)
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 (model does not and should not know view and controller.)
View
: deal with graphic representation
Controller
: contains the interface between model and view
Concept of Model
Model manages the
behavior and data
of the application
domain.
responds to requests for information about its state
(usually from the view)
responds to instructions to change state (usually from the
controller).
Concept of 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 of Controller
receives user input and initiates a response by
making calls on model objects.
accepts input from the user and instructs the model
and a view port to perform actions based on that input.
MVC-I
simple version of MVC
the system is decomposed into two subsystems:
Controller-View
Model.
Controller-View
: takes care of input and output processing and their interfaces
Model
: in charge of business logic; copes with all core functionality and the data
MVC-II
completely separate view and controller
Controller
View
Model
Model
: provides all core functionality and data supported by a database
View
: displays the data
Controller
: takes input requests, validates input data, initiates the Model and the View and their connection, and dispatches tasks
Applicable Domain
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 => different professionals can be assigned to work on different aspects of such applications concurrently
Evaluation
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 (team working by different
professionals)
Limitations
Not suitable for agent-oriented
applications such as interactive mobile and robotics application
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
Presentation-Abstraction-Control (PAC)
was
developed from MVC
to support the application requirement of
multiple agents
in addition to interactive requirements
Key Idea
the system is decomposed into a
hierarchy of cooperating agents
Each agent has three components (
Presentation
,
Abstraction
, and
Control
)
Each agent responsible for one function
Within each agent there are
no direct connections
between the
abstraction
component and
presentation
component
Sometimes all agents share the same control => Provides interaction between agents
top-level agent provides core data and business logics
bottom-level agents provide detailed data and presentations
middle-level agent may coordinate low-level agents
Usage
:
suitable for any
distributed system
where all the agents are distantly distributed and each agent has its own functionalities with data and interactive interface.
Sometimes, middle level agents, the interactive presentations are not required.
Applicable Domain
:
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.
when the
coupling
among the agents is expected to be
loose
=> changes on an agent do not affect others
Evaluation
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
Limitations
Extra time lost
due to the control bridge
Difficult to determine the correct number of the agents
Complete separation of presentation and abstraction by control in each agent
generates development complexity