About s/w engineering pattern oriented web based architecture

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

2. Web Based Application Architecture

3. Three Layer Architecture
• Presentation layer
• Application or Business Layer
• Data Access Layer

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

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

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

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

8. Design Pattern Classification
• Creational Patterns
• Structural Patterns
• Behavioral Pattern

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

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

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

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

13. 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 the
code which gathers dynamic data for the page
Controller - 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.

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

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

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

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

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

19. Example

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

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

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

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

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

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

28. Liability of PAC
• Increased system complexity.
• Complex control component.
• Efficiency.
• Applicability.