Chapter 9
INTERACTION ORIENTED
SOFTWARE ARCHITECTURES
Objectives
Introduce concepts of interaction-oriented
software architectures.
Describe the MVC and PAC architectural styles.
Discuss the applicable domains of interaction-
oriented software architectures.
Discuss the benefits and limitations of the
interaction-oriented software architecture style.
Discuss other related architectures.
INTERACTION ORIENTED
SOFTWARE ARCHITECTURES
• Decomposes the system into 3 major partitions
– Data module
– Control module
– View presentation module
• Each module has its own responsibilities.
– The data module provides
• The data abstraction
• All core business logic on data processing.
– The view presentation module is responsible for
• Visual or audio data output presentation
• May also provide user input interface as well when
necessary.
INTERACTION ORIENTED
SOFTWARE ARCHITECTURES
– The control module determines the flow of control involving
• View selections
• Communications between modules
• Job dispatching
• Certain data initialization and system configuration actions.
• The key point is “the separation of user interactions from
data abstraction and business data processing”.
– Since there may be many view presentations in different formats
• Multiple views may be supported for the same data set.
– Even for a specific view presentation, the interfaces or views
may need to change often
• Loose coupling between data abstractions and its presentations is
helpful.
INTERACTION ORIENTED
SOFTWARE ARCHITECTURES
• The loose coupling connections can be
implemented in different ways
– explicit method invocation
– implicit registration/notification method invocation.
• All 3 modules may be fully connected.
• We will discuss about 2 major styles categories
of interaction-oriented architectures
– Presentation-Abstraction-Control (PAC) architecture
– Model-View-Controller (MVC) architecture.
• Both of MVC and PAC are used for interactive
applications such as
– Web online applications
– Distributed applications with multiple tasks and user
interactions.
• They are different in their flow of control and
organization.
– PAC
• is an agent based hierarchical architecture
– MVC
• does not have a clear hierarchical structure
• all three modules are connected together.
Model-View-Controller (MVC)
• MVC programming is the application of
this 3-way factoring
– Objects of different classes take over the
operations related to the application domain
(the model)
– The display of the application's state (the
view)
– The user interaction with the model and the
view (The controller)
Model-View-Controller (MVC)
• Models is
– the domain-specific software simulation
– or implementation of the application's central
structure.
• Views deal with everything graphical
– Request data from their model
– And display the data
• Controllers contain the interface between
– Associated models
– Associated views
– and the input devices (e.g., keyboard, pointing device,
time).
MVC-I
• The 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.
MVC-I
• The connection between the Controller-
View and the Model
– Can be designed in a pattern of subscribe-
notify
• the Controller-View subscribes to the Model
• the Model notifies the Controller-View of any
changes.
– Note: the Controller-View is an observer of
the data in the Model module.
MVC-I
View - Controller Model DB
MVC-I Example
• A simple GUI example designed in MVC-I.
– The View has a GUI interface with two text
fields
• the user to enter a new number in one of the text
field
• the accumulated summation is displayed in the
other text field.
– The summation is held in the Model module.
– Model provides all business logics including
all getter and setter methods.
MVC-I Example
– Whenever the data in the Model is
updated
• The Model will notify the registered GUI
components of changes
• Then the GUI components will update their
displays.
-> This is why we say that the data in
the Model of MVC architecture is active.
public class ViewController extends JFrame
implements
ActionListener {
Model myModel; <- Model
JTextField myInput; <- View’s element
JTextField mySum; <- View’s element
JPanel content;
public ViewController(Model model) {
myModel = model;
myInput = new JTextField(5);
mySum = new JTextField(15);
content = new JPanel();
content.add(myInput);
content.add(mySum);
setContentPane(content);
myInput.addActionListener(this);
}
public void update() {
mySum.setText(" " + myModel.getSum());
}
public void actionPerformed(ActionEvent e) {
try {
myModel.add(myInput.getText());
} catch (Exception ex) { ... }
}
}
public class Model {
int sum;
Vector listeners;
public Model() {
sum = 0;
listeners = new Vector();
}
public void attach(ViewController vc) {
listeners.addElement(vc);
}
public void notifyVC() {
for (int i = 0; i < listeners.size(); i++) {
ViewController vc =(ViewController) vc.update();
}
}
public void add(String st) {
sum += Integer.parseInteger(st);
notifyVC();
}
public int getSum() {
return sum;
}
}
public class MVC1{
public static void main(String[] args) {
Model myModel = new Model();
ViewController vc =
new ViewController(myModel);
myModel.attach(vc);
vc.setTitle("my MVC-I");
vc.setVisible(true);
}
}
MVC-II
MVC architecture:
• Applicable domain
– Suitable for interactive applications
• Multiple views are needed for a single data model
• The interfaces are prone to data changes
frequently.
• 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 concurrently.
MVC Architecture
• Benefits
– Many MVC vendor framework toolkits available.
– Multiple views synchronized with same data model
– Easy to plug-in new or change interface views
• thus allowing updating the interface views with new
technologies without overhang the rest of the system.
– Very effective for developments
• if Graphics expertise professionals, programming
professionals, and data base development professionals are
working in a team in a designed project.
MVC Architecture
• Limitations
– Does not fit well agent-oriented applications
such as
• Interactive mobile
• Robotics applications.
– Any data model change expensive.
• Multiple pairs of controllers and views based on
the same data model
– In some cases the division between the View
and the Controller is not clear
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
– Abstraction
– Control
Presentation Abstraction
Controller
• The Control component in each agent
– is in charge of communications with other agents.
• 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
• Very suitable for any distributed system where
– all the agents are
• distantly distributed
– each of them has its own functionalities with
• data and
• interactive interface.
– all agents need to communicate with other agents in a well-
structured manner.
• also used in applications with rich GUI components
where
– each of them keeps
• its own current data and
• Its interactive interface and
• needs to communicate with other components.
• Components are required if necessary
– For some middle level agents
• the interactive presentations are not required
– The control component is required for all
agents
• because this is the only way for an agent to talk to
another agent.
• The Control component is
– a mediator
• between the Presentation component and the Abstraction component within
the agent,
– a bridge
• between the agent itself and other agents as well.
• The Presentation component and the Abstraction component are
loosely coupled.
• The Presentation component is responsible for both
– data input and
– data output in GUI interfaces where the data come from the Abstraction
component.
• The Abstraction component is responsible for
– providing logical data concepts and services
– encapsulating all detailed data manipulation.
PAC architecture:
• Applicable domain
– Suitable for an interactive system
• Where the system can be divided into many
cooperating agents in a hierarchical manner.
• 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 does not affect
others.
PAC architecture
• 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.
PAC Architecture
• Limitations:
– Overhead due to the control bridge
• between presentation and abstraction and the
communication of controls among agents.
– Difficult to determine the right 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 generate development complexity
since communications between agents only take place
between the controls of agents.
