Software Design and

Architecture

Interaction Oriented Software

Architecture

Chapter 9 of Kia Qian Book

INTERACTION ORIENTED SOFTWARE
ARCHITECTURES
 The key point - the separation of user interactions from data abstraction
and business data processing.
 The interaction oriented software architecture decomposes the system into
three major partitions:
 Data module
 Control module
 View presentation module
 The data module provides the data abstraction & all business logic.
 The view presentation module is responsible for data output presentation
and it may provide an input interface for user input.
 The control module determines the flow of control involving view
selections, communications between modules, job dispatching, and certain
data initialization and system configuration actions.
 Multiple view presentations in different formats are allowed
INTERACTION ORIENTED SOFTWARE
ARCHITECTURES
 Two major style
 Model-View-Controller (MVC)
 Presentation-Abstraction-Control (PAC)
 Both of MVC and PAC are used for interactive applications
multiple talks and user interactions.
 They are different in their flow of control and organization.
 The PAC is an agent based hierarchical architecture
 The MVC does not have a clear hierarchical structure and
all three modules are connected together.
Model-View-Controller (MVC)
 Objects of different classes take over the operations related to the application
domain (the model), the display of the application's state (the view), and the user
interaction with the model and the view (The controller).
 Models:
 The model of an application is the domain-specific software simulation or
implementation of the application's central structure.
 Views:
 In this metaphor, views deal with everything graphical: they request data from their
model and display the data.
 Controllers:
 Controllers contain the interface between their associated models and views and the
input devices (e.g., keyboard, pointing device, time)
MVC-I
 The MVC-I is a simple version of MVC architecture
where the system is simply decomposed into two
sub-systems: The Controller-View and the Model.
 Basically, the Controller-View takes care of input
and output processing and their interfaces; the
Model module copes with all core functionality and
the data.
 The Controller-View module registers with (attaches
to) the data module.
MVC-I
 The Model module notifies the Controller-View
module of any data changes so that any graphics data
display will be changed accordingly; the controller
also takes appropriate action upon the changes.
 The connection between the Controller-View and the
Model can be designed in a pattern of subscribe-
notify whereby the Controller-View subscribes to the
Model and the Model notifies the Controller-View of
any changes.
 In other words, the Controller-View is an observer of
the data in the Model module.
MVC-I
MVC-I
 Simple GUI example designed in MVC-I.
 The View has a GUI interface with two text
fields, for the user to enter a new number in one
of the text fields and 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
 Whenever the data in the Model is updated it will
notify the registered GUI components of changes,
and then the GUI components will update their
displays.
 This is why we say that the data in the Model of
MVC architecture is active rather than passive.
 Actually, for this specific example there is no need
to have separated Model to notify the change
because actionPerformed() can take care all
necessary changes.
 We just want to use this example to see how MVC-
I architecture works.
MVC-II
MVC-II

 The MVC in figure 9.2 is the same as MVC-I in figure 9.1 except that the
controller and the view are separated.
MVC-II
MVC-II

 Fig 9.4 depicts a sequence diagram for a generic MVC architecture.

MVC-II

 After clients start up the MVC application, the controller

initializes the Model and View, and attaches the View
and itself to the Model (this is called registration with the
Model.
 Later, the Controller intercepts a user request either
directly from command line or through the View
interface, and forwards the request to the Model to
update the data in the Model.
 The changes in the Model will trigger the Model to
notify all attached or registered listeners of all changes,
and the interface in the View will also be updated right
way.
MVC
 Applications:
 Suitable for interactive applications where multiple
views are needed for a single data model and the
interfaces are prone to data changes frequently.
 Suitable for applications where 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
 Benefits:
 There are many MVC vendor framework toolkits
available.
 Multiple views synchronized with same data model
 Easy to plug-in new or change interface views,
 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
 Does not fit well 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.
Presentation-Abstraction-Control (PAC)

 The PAC architecture is 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.
Presentation-Abstraction-Control (PAC)

 Each agent has three components (Presentation, Abstraction,

and Control).
 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 may play a role of coordinator of low-
level agents.
 There are no direct connections between Abstraction
component and Presentation component in each agent.
Presentation-Abstraction-Control (PAC)

 The PAC three components concepts are applied to all

concrete sub-system architectures.
 It is very suitable for any distributed system where all the
agents are distantly distributed and each of them has its own
functionalities with data and interactive interface.
 In such a system, all agents need to communicate with other
agents in a well-structured manner.
 The PAC is also used in applications with rich GUI
components where each of them keeps its own current data
and interactive interface and needs to communicate with
other components.
Presentation-Abstraction-Control (PAC)

 Of course, some concrete agent needs all three

components and some other agents do not.
 For some middle level agents the interactive
presentations are not required, so they do not have
a Presentation component.
 The control component is required for all agents
because this is the only way for an agent to talk to
another agent.
Presentation-Abstraction-Control (PAC)

 The Control component is a mediator between the Presentation

component and the Abstraction component within the agent,
and also 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 and encapsulating all
detailed data manipulation.
Presentation-Abstraction-Control (PAC)
Presentation-Abstraction-Control (PAC)
Presentation-Abstraction-Control (PAC)

 Assume that the current page is the second to last

page in the document at this time.
 If the user clicks on the next button, the control
agent C4 informs agent P4 to update its
presentation, in this case, it also hides the next
button since there is no next page after last page.
 Agent C4 also informs agent A4 to update the
data on next button.
Presentation-Abstraction-Control (PAC)

 After C4 handles all local processing, it contacts

its parent agent, C1, to let it take over.
 After C1 gets the message from C4, it tells A1 to
move the next page, which is the last page in the
document, and then asks P1 to display that page.
 C1 also informs C5 to hide the last button since
the current page is the last page (or let the last
button stay based on the requirement
specification).
Presentation-Abstraction-Control (PAC)

 We can see that all the agents communicate via the

controls.
 The data structure shown on the upper-right corner of
Figure 9.7 indicates the pointer and data.
 Since PAC2, PAC3, PAC4, and PAC5 are all buttons,
they have very similar data and presentation
functionality such as hide, move-over, gray-out
features; their controls, however, are different.
Presentation-Abstraction-Control (PAC)

 The sequence diagram in Figure 9.9 shows the interaction

sequence in the example we discussed above.
 When the next button is pressed to display the last page in the
document PAC4 and PAC1 react as follows:
P4 informs C4 that the “next” button was pressed;
C4 sends update to A4;
C4 informs P4 to update its presentation or shape;
C4 contacts C1 (a top level agent).
C1 sends update to A1 to move the pointer to next (last page)
C1 instructs P1 to display the last page.
Presentation-Abstraction-Control (PAC)
Presentation-Abstraction-Control (PAC)
Presentation-Abstraction-Control (PAC)

 Applications:
 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.
Presentation-Abstraction-Control (PAC)

 Benefit:
 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.
Presentation-Abstraction-Control (PAC)

 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.