Interaction Oriented Architecture Interaction oriented SW architecture More

Interaction Oriented Architecture

Interaction oriented SW 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

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

Interaction oriented SW architecture 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)

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 Two Major Categories Model View Controller (MVC) Presentation-Abstraction-Control (PAC)

Model View Controller Widely used in web applications E. g. , MS ASP. Net, Java Swing First introduced in 1980’s Small. Talk Key Idea Model: Model model of application’s logic View: View deal with graphic representation Controller: 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.

Model View Controller 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).

Model View 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.

Model View Controller 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 Simplified System Controller/View Model Controller/View Takes care of input/output, interface to model Model In charge of business logic

MVC-1 Diagram

MVC-II Difference: completely separate view and controller

Object Diagram Notice again: one model can correspond to multiple views q C 1 is paired with V 1, C 2 is paired with V 2 q All views and controllers are connected to the model q Two classes in the model: one is a collection type that aggregates many other classes as part of it, the other represents a row in a database table.

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.

Summary MVC 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. Abstraction presentation Control

Key Idea 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

PAC – communication

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

Example 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

Example Note: there might be multiple layers of controllers.

Example Assume now at page 3 and you have only four pages. What if “next button” is clicked? C 4 informs A 4 to load/update contents C 4 contacts its parent agent C 1, C 1 takes powers and tells A 1 to move to the next page and P 1 display that page What is missing? ü C 1 also informs C 5 to hide the last button.

Summary - PAC 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

Hierarchical PAC (HPAC)

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.