1 / 28

Interaction Oriented Architecture

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.

teryl
Download Presentation

Interaction Oriented Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interaction Oriented Architecture

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

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

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

  5. 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)

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

  7. Key Idea • Decompose user-interaction software • Data module • Flow control module • View presentation module • Benefits: • Loose coupling • Exchangeability • Maintainability • Extensibility

  8. Categories • Two Major Categories • Model View Controller (MVC) • Presentation-Abstraction-Control (PAC)

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

  10. 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).

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

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

  13. MVC-I • Simplified System • Controller/View • Model • Controller/View • Takes care of input/output, interface to model • Model • In charge of business logic

  14. MVC-1 Diagram

  15. MVC-II Difference: completely separate view and controller

  16. Object Diagram Notice again: one model can correspond to multiple views • C1 is paired with V1, C2 is paired with V2 • All views and controllers are connected to the model • 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.

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

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

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

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

  21. PAC – communication

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

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

  24. Example Note: there might be multiple layers of controllers.

  25. Example • Assume now at page 3 and you have only four pages. • What if “next button” is clicked? • C4 informs A4 to load/update contents • C4 contacts its parent agent C1, C1 takes powers and tells A1 to move to the next page and P1 display that page • What is missing? • C1 also informs C5 to hide the last button.

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

  27. Hierarchical PAC (HPAC)

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

More Related