pattern oriented architecture for web based architecture

28
Abstract • The web is being used for applications that contain significant business logic complexity and have considerable user interface requirements. Unfortunately, the limitations of the existing web infrastructure mean that purely event-based user interaction is unsuitable within web applications. Nevertheless, we believe that integrating event-based user interaction in certain parts of a large web application will have positive effects if a suitable architecture is used. In this paper, we explore an architecture that accommodates a partial integration of an event-driven user interface. We also suggest ways in which the interaction of user is better using various Design and Architectural Pattern.

Upload: shuchi-tripathi

Post on 22-Jan-2017

202 views

Category:

Education


0 download

TRANSCRIPT

Abstract• The web is being used for applications that contain significant

business logic complexity and have considerable user interface requirements. Unfortunately, the limitations of the existing web infrastructure mean that purely event-based user interaction is unsuitable within web applications. Nevertheless, we believe that integrating event-based user interaction in certain parts of a large web application will have positive effects if a suitable architecture is used. In this paper, we explore an architecture that accommodates a partial integration of an event-driven user interface. We also suggest ways in which the interaction of user is better using various Design and Architectural Pattern.

Web Based Application Architecture

Three Layer Architecture

• Presentation layer• Application or Business Layer• Data Access Layer

Presentation Layer

For most business applications, a form metaphor is used to structure the presentation layer. The application consists of a series of forms (pages) with which the user interacts. Each form contains a number of fields that display output from lower layers and collect user input.

Two types of components that implement forms-based user interfaces are:

• User interface components• User interface process components

Application/Business Layer• Large enterprise applications are often

structured around the concepts of business processes and business components. These concepts are addressed through a number of components, entities, agents, and interfaces in the business layer.– Business Components– Business Workflows– Business Entities– Business Interface

Data Access Layer

• Data access components in this data layer are responsible for exposing the data stored in these databases to the business layer.– Data Access Components– Service Gateways

Why do we need these patterns If we can certainly build software applications without

using any of these patterns, but by using these patterns we can achieve separation of concerns design principle.

These help in improving maintainability of the application.

Another important reason why these patterns became popular is implementing these patterns improve the testability of the application using automated unit tests

Design Pattern Classification

• Creational Patterns• Structural Patterns• Behavioral Pattern

Separation on Concern(SoC)

• Separation of concerns (SoC) is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. A concern is a set of information that affects the code of a computer program. A concern can be as general as the details of the hardware the code is being optimized for, or as specific as the name of a class to instantiate. A program that embodies SoC well is called a modular program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Encapsulation is a means of information hiding. Layered designs in information systems are another embodiment of separation of concerns (e.g., presentation layer, business logic layer, data access layer, persistence layer).

Model View Controller (MVC) architecture

Design patterns: A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution. There are many good reasons to use design patterns: 1. They are proven: You tap the experience, knowledge and insights of developers who have used these patterns successfully in their own work. 2. They are reusable: When a problem recurs, you don’t have to invent a new solution; you

follow the pattern and adapt it as necessary. 3. They are expressive: Design patterns provide a common vocabulary of solutions, which you can use to express larger solutions succinctly. It is important to remember, however, that design patterns do not guarantee success

Cont..

• It is common to think of an application as having three main layers: presentation (UI), application logic, and resource management. In MVC, the presentation layer is split into controller and view.

• MVC (Model, View, Controller) is a pattern for organising code in an application to improve maintainability.

Imagine a photographer with his camera in a studio. A customer asks him to take a photo of a box.

The box is the model, the photographer is the controller and the camera is the view.

• Model View Controller or MVC as it is popularly called, is a software design pattern for developing web applications. A Model View Controller pattern is made up of the following three parts.

Model View Controller

Model - Model represents an object or JAVA POJO carrying data. It can also have logic to update controller if its data changes.The model is responsible for managing the data of the application. It responds to the request from the view and it also responds to instructions from the controller to update itself.View - View represents the visualization of the data that model contains.MVC is often seen in web applications, where the view is the HTML page and thecode which gathers dynamic data for the pageController - Controller acts on both model and view. It controls the data flow into model object and updates the view whenever data changes. It keeps view and model separate. The controller receives the input, it validates the input and then performs the business operation that modifies the state of the data model.

MVC Implementation

We are going to create a Student object acting as a model.StudentView will be a view class which can print student details on console and StudentController is the controller class responsible to store data in Student object and update view StudentView accordingly.

MVCPatternDemo, our demo class, will use StudentController to demonstrate use of MVC pattern

What is PAC?

• The Presentation-Abstraction-Control pattern (PAC) defines a structure for interactive software systems in the form of a hierarchy of cooperating agents.

Moreover…• Every agent is responsible for a specific

aspect of the application's functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents.

Class Diagram For PAC:

As the comparison

• The PAC abstraction component corresponds roughly to the model component of MVC.

• The presentation component in PAC is a combination of the view and control components in MVC.

• The control component of PAC mediates between agents and has no equivalent in MVC.

Example

Context• Interactive systems can often be viewed as a set of cooperating

agents.–  Agents specialized in human-computer interaction accept user input

and display data.–  Other agents maintain the data model of the system and offer

functionality that operates on this data.– Additional agents are responsible for diverse tasks such as error

handling or communication with other software systems.• Besides this horizontal decomposition of system functionality, we

often encounter a vertical decomposition.• In such an architecture of cooperating agents, each agent is

specialized for a specific task, and all agents together provide the system functionality. This architecture captures both a horizontal and vertical decomposition.

How it works?

• The agent's presentation component provides the visible behavior of the PAC agent.

• Its abstraction component maintains the data model that underlies the agent, and provides functionality that operates on this data.

• Its control component connects the presentation and abstraction components, and provides functionality that allows the agent to communicate with other PAC agents.

Top-Level

• The top-level PAC agent provides the functional core of the system.

– The top-level PAC agent includes those parts of the user interface that cannot be assigned to particular subtasks, such as menu bars or a dialog box displaying information about the application.

– Most other PAC agents depend or operate on this core.

Bottom-level

• Bottom-level PAC agents represent self-contained concepts on which users of the system can act, such as spreadsheets and charts.

– The bottom-level agents present these concepts to the user and support all operations that users can perform on these agents, such as zooming or moving a chart.

Intermediate-level

• Intermediate-level PAC agents represent either combinations of, or relationships between, lower-level agents, e.g. a floor plan and an external view of a house in a CAD system for architecture.

PAC Benefits• Support for change and extension.–  Changes within the presentation or abstraction

components of a PAC agent do not affect other agents in the system.

–  New agents are easily integrated into an existing PAC architecture without major changes to existing PAC agents.

• Support for multitasking.– PAC agents can be distributed easily to different

threads, processes, or machines. Extending a PAC agent with appropriate inter-process communication functionality only affects its control component.

Liability of PAC

• Increased system complexity.• Complex control component.• Efficiency.• Applicability.