You are on page 1of 19

www.assignmentwritingindia.

co
m

RESEARC
H REPORT
ENTERPRISE APPLICATION DESIGN PATTERNS

Student Name: Student ID:


Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

www.assignmentwritingindia.co
m Page
2
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

Abstract

All the characteristics and features of our lives are integrated with the
software afforded by the developers with the suitable tools which is having
ever growing consequences .An enterprise application is a business
application, obviously. As most people use the term, it is a big business
application. In today’s corporate environment, enterprise applications are
complex, scalable, distributed, component-based, and mission-critical. They
may be deployed on a variety of platforms across corporate networks,
intranets, or the Internet. They are data-centric, user-friendly, and must
meet stringent requirements for security, administration, and maintenance.
In short, they are highly complex systems.

It organizes an application’s requirements into a small set of distinct but


interdependent categories, and shows how each requirement interacts with
the others. By balancing the effects of each design choice against all the
other requirements, you can avoid the nasty shock of discovering too late
that you’ve overlooked or underestimated some important design
consideration.

Architecture and design patterns are playing a vital role in order to


communicate knowledge of known patterns and their solutions. This thesis is
mainly concentrated on the developments and accompaniments to the
above mention patterns. By using these above mentioned patterns, we
present a framework that developed to aid practitioners in following
methodology.

www.assignmentwritingindia.co
m Page
3
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

Table of Contents

Abstract.......................................................................................3
List of Abbreviations.....................................................................5
Chapter 1 Introduction .................................................................7
Enterprise application..............................................................................................7
The Enterprise Application Model............................................................................8
Enterprise application design objectives.................................................................9
Basic Assumptions/Limitations..............................................................................10
Literature Review..................................................................................................10
Section 2 Background.................................................................12
Section 3 Recent Research Activities............................................14
Section 4 Conclusions and Future Work........................................17
Conclusion............................................................................................................. 17
Future Work........................................................................................................... 17
References.................................................................................19

www.assignmentwritingindia.co
m Page
4
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

List of Abbreviations

• UoW - Unit of Work

• EA – Enterprise Application

• UML – Unified Markup Language

• SQL – Structured Query Language

• UI – User Interface

www.assignmentwritingindia.co
m Page
5
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

www.assignmentwritingindia.co
m Page
6
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

Chapter 1 Introduction

If a developer uses design patterns correctly, he or she will reap the benefits
of other developers’ experience and hard work. Design patterns give a
proven solution to software applications. This proven solution will lead to
highly cohesive objects with minimal coupling. Like any good software
application, high cohesion and low coupling allow code to be easily
maintained. Using design patterns will also give a common vocabulary to
communicate thoughts and ideas to other developers or architects.
Obviously, all these benefits lead to decreased development time, which
leads to lower costs. Software design patterns have been proven over time
to be defect free and have a large community of fellow developers who are
ready and willing to lend their expertise. Given these reasons, software
produced will contain much fewer defects and lower design costs when
compared to top down structural software.

Enterprise application

An enterprise application is a business application, obviously. As most people


use the term, it is a big business application. In today’s corporate
environment, enterprise applications are complex, scalable, distributed,
component-based, and mission-critical. They may be deployed on a variety
of platforms across corporate networks, intranets, or the Internet. They are
data-centric, user-friendly, and must meet stringent requirements for
security, administration, and maintenance. In short, they are highly complex
systems.

Designing and developing such enterprise applications means satisfying


hundreds or thousands of separate requirements. What’s more, every
development decision you make to satisfy each requirement affects many
other requirements, often in ways that are difficult to understand or predict
— and the failure to meet any of these requirements can mean the failure of
the entire project! The Enterprise Application Model introduced in this
chapter gives you a way to look at the enterprise application "whole cloth,"
to bring some order out of this complexity. It organizes an application’s
requirements into a small set of distinct but interdependent categories, and
shows how each requirement interacts with the others. By balancing the

www.assignmentwritingindia.co
m Page
7
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

effects of each design choice against all the other requirements, you can
avoid the nasty shock of discovering too late that you’ve overlooked or
underestimated some important design consideration.

An enterprise application is:

• Large

A multi-user, multi-developer, multi-machine, multi-component application


that can manipulate massive data and utilize extensive parallel processing,
network distributed resources, and complex logic. It can be deployed across
multiple platforms and inter-operate with many other applications, and it is
long lived.

• Business Oriented

Its purpose is to meet specific business requirements. It encodes business


policies, processes, rules, and entities, is developed in a business
organization, and is deployed in a manner responsive to business needs.

• Mission Critical

An enterprise application must be robust enough to sustain continuous


operation. It must be extremely flexible for scalability and deployment, and
allow for efficient maintenance, monitoring, and administration.

The Enterprise Application Model is a design tool.

The Enterprise Application Model

The Enterprise Application Model helps guide you step by step through the
process of designing and building a large-scale commercial application, by
organizing the hundreds or thousands of design requirements into a small
number of sub-models, and showing how they fit together. It shows how to
www.assignmentwritingindia.co
m Page
8
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

balance the competing requirements of every design decision. This lets you
build up the application in small incremental steps, working in any order that
seems appropriate, with the confidence that every design choice integrates
smoothly with the overall application architecture.

Enterprise application design objectives


1. The main objective of this iteration is to build up an acquaintance with the
Flower’s patterns on which the theory is developed
2. The application’s functionality can be broken down into the following initial
feature list:
The following are the initial features list of the application functionality:
Browse People

View Person

Increase Age

4. We demonstrate an evolution in the use of EA patterns in successive


iterations. Each iteration focuses on one or more patterns that increasingly
apply separation of concerns or otherwise improve the overall design.

5. An evolution is demonstrated in the use of EA patterns in successive


iterations. Each iteration focuses on one or more patterns that increasingly
apply separation of concerns or otherwise improve the overall design.

6. The different iterations are

Do-It-All Transactions Scripts

Isolating Technical Services with Row Data Gateway

Isolating Presentation with Template View and View Helper

Data Integrity and an Isolated Domain Logic with OPTIMISTIC OFFLINE LOCK, PAGE
CONTROLLER and IDENTITY FIELDs

Refined Access to the Data Source with DATA MAPPER, TABLE DATA GATEWAY and
DOMAIN MODEL

An Organized Approach to the Application Layer Using the FRONT CONTROLLER


Pattern

www.assignmentwritingindia.co
m Page
9
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

Managing In-Memory Data with LAZY LOAD (via VIRTUAL PROXY) and IDENTITY MAP

Accommodating a Complex Domain with UNIT OF WORK (UOW) and DEPENDENT


MAPPING

Basic Assumptions/Limitations

Literature Review
Over the lifetime of a software application changes and modifications will
occur. No matter how bulletproof the initial design is or how exhaustively
tested the application is, there will be requirement changes or missed
features. How does this fact relate to software patterns? First, a few terms
need to be defined: software decay is the breakdown of internal system
design; design pattern decay is the deterioration of the structural integrity of
a design pattern realization (Izurieta and Bieman 2008). These terms are
used to verify and validate how often the original software pattern became
corrupt or strayed from the initial pattern design. This behavior has also
been defined as the term “grime”; design pattern grime can also be
classified into subcategories of Class, Modular and Organizational (Izurieta
and Bieman 2008).

Class grime applies to the classes that construct the design pattern. The
grime is considered the increases in the number of ancestors, public
attributes and other class related functionality (2008). Modular grime applies
to the increase in coupling of the pattern with other external classes by
tracking the number of relationships (2008). Organizational grime applies to
the structure of the namespaces and file organization (2008). Design pattern
grime is a relative concept; what is considered grime from a software pattern
point of view may be a sound design approach from a different perspective
(2008).

This usually occurs with software over long term development cycles.
Additions of functionality and design changes can lead to a bastardization of
the original pattern. This, however, is necessary for the growth of the
application. If strict adherence to maintaining the integrity of initially coded
patterns is kept, pattern decay will be minimal. How does keeping pattern
decay to a minimum reduce the number of defects? First, examining what
takes place with pattern decay is necessary. An increase in coupling with
internal classes is an indication of deteriorated modularity and a symptom of

www.assignmentwritingindia.co
grime buildup (Izurieta and Bieman 2008).

m Page
10
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

Although, the original intention of the design pattern remains, the pattern
itself will become unnoticeable. By keeping decay to minimum, the essence
of the pattern will remain intact. This will increase reliability, readability and
reduce non-standard or unreliable code. These traits are desirable and will
lead to the reduction of defects. As mentioned earlier, there is no
substitution for experience when architecting software using design patterns.
Inexperienced

With design patterns, an increase in coupling within classes is a symptom of


grime buildup (Izurieta and Bieman 2008). As dependencies increase, the
system becomes harder to extend and the testability of the pattern is
restricted; a higher number of dependencies decreases the
comprehensibility of the pattern (2008).

Straying from the original intention and design of the pattern could lead to
increased coupling and a decrease in modularity. These traits are
undesirable and will lead to increased defects. As systems evolve, new
relationships develop between classes. These relationships may or may not
have been intended in the original design, again, not a desirable trait. Such
relationships may be the consequence of Modular grime buildup (Izurieta and
Bieman 2008). The more blurry class lines become, the more difficult making
code changes become, once again leading to an increased number of defects
within the codebase.

www.assignmentwritingindia.co
m Page
11
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

Section 2 Background
Different sections as appropriate to building the theoretical background for
the topic emphasizing the most recent activities relevant to the subject.

The layered and client-server styles in particular—are reviewed to provide a


basis for the rest of this thesis. In the layered style, layers are the
components. Protocols that dictate how layers, and modules within layers
may depend on each other define the connectors this style. In what we
describe as a “pure” layered style–in that this variation follows the style
guidelines suggested in [SG96] exactly–these protocols state that only
adjacent layers may communicate; layers below provide services to the layer
immediately above and layers below are oblivious to the layers above
[SG96].

In the client-server style, components are clients and servers which are
separated across a network. The connectors for this style are requests made
over network links, which come only from the clients to the servers, and the
subsequent responses.

In keeping with a pure layered style, we merge the Application and


Presentation layers, both described in, which differs from Larman’s approach
of keeping the Application layer separate if it is used at all.

The Domain layer contains the logic and entities which describes the area of
concern of an application. Domain entities of the application; the
application’s behavior might include adding, removing and updating entries
on people, which constitutes the Domain logic of the application.

The trend is that the Application / Presentation layer is usually more


represented on the client side, and the Service layer is much less so. The
Domain layer tends to be represented more evenly, usually leaning towards
the server side.

While this thesis will focus on the server-side aspects of WEAs, it is important
to understand the client-side aspect as well. While client-side validation can
be easily circumvented by someone who knows their browser, it does protect
users of the applications front-end from tying up the system with multiple
erroneous network requests due to small mistakes.

www.assignmentwritingindia.co
m Page
12
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

www.assignmentwritingindia.co
m Page
13
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

Section 3 Recent Research Activities


Top-Down Decomposition
Design patterns are not applied all at once, but rather in a sequential, one-by-one fashion. In
order to master the design patterns it is very important to adopt an appropriate process,
which facilitates such development. Top-down decomposition is a method of developing
software through a number of iterative steps, in order to increase developer productivity
and improve software quality. This approach was introduced by E.W. Dijkstra as a response
to the so-called "software crisis" of the late 1960s.

When combined with popular Agile Software development practices such as user stories,
unit tests, and

mock objects, the top-down decomposition could be briefly outlined as follows:

For each user story:

1) Specify an acceptance test; make it to fail

2) If required, address the project organization and version control issues

3) At each step:

a) Identify a smallest possible piece of the program, which would allow making a
progress by either adding detail to the current level of abstraction or introducing a
new one.

b) Specify a unit test using mocks for all other units regardless of whether they are
already implemented or not; make unit test to fail

c) Provide a simplest possible solution that allows passing the unit test

d) Re-factor the code in order to eliminate duplications, fix bugs, improve code
readability or/and improve performance

e) Repeat until the whole story is implemented

4) Integrate and test

5) If required, perform additional re-factoring to eliminate “code smells”

6) Integrate and test

Complexity with respect to software development we must distinguish three


different types of complexity

1) Computational complexity

2) Programming complexity
www.assignmentwritingindia.co
m Page
14
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

3) Intellectual complexity

Computational complexity : the amount of work (computation) the computer will


need to perform when it is running a particular program is known as Computational
complexity.

Programming complexity : the complexity of the structure of the text of the


program, which performs this computation.

Intellectual complexity : The intellectual that effort we, as programmers, have to


exert in order to create a program that performs the required computation.

Fist, we have very little direct control over the computation we should states that
separately from providing some input data we have very little direct control over
the computation which is performed solely by computer. To provide a corresponding
program significant impact over computation is only the way.

Second,( Between these three types of complexity there will always be a certain
trade-off.( But this program would probably work very slowly or would not handle
properly particular corner cases and thus would lead to a complex or even incorrect
computation we could create a simple program, thus expending very little
programming and intellectual effort.

To deal with intellectual complexity we, as human beings, may apply three mental
aids

1) Enumeration

2) Mathematical induction

3) Abstraction

Enumeration

By enumeration we mean an individual, case-by-case analysis performed in a series


typically using conditional statements such as if-then-else| and/or switch-case. A
fundamental fact about enumeration is that it stops working when a large number
of cases must be analyzed.

Mathematical Induction

By mathematical induction (a.k.a. repetition) we mean performing a cyclic task,


usually implemented using while, for, do-while loops and recursive procedures.
When performing cyclic tasks we human beings tire very rapidly and thus prefer to
delegate this task to a computer and to prove, in some way, that the programmed
iterative activity will work correctly under certain conditions.

www.assignmentwritingindia.co
Abstraction

m Page
15
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

By abstraction we mean ignoring certain levels of details and extracting common


characteristics of a group of entities. Thus, a class is an abstraction of a group of
objects with a common set of attributes, relationships, and behavior. At a more
fundamental level, the variable is an abstraction of a particular set of values of a
certain type, while the function is an abstraction of a certain set of computations

www.assignmentwritingindia.co
m Page
16
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

Section 4 Conclusions and Future Work

Conclusion

The goal of refining the existing toolkit of patterns has been hugely
successful. While our experience is biased towards new developments, the
changes we have introduced are founded in simple and reliable development
principles and the result is accordingly simple and reliable.
The biggest achievement, and a major reason for our success in training
developers, is the more concrete guidance in approach. A developer who has
a UML Domain Model worked out along with some Use Cases can almost
deterministically generate all the code they require without having to make
any complex decisions until a working system is running under enough load
to provide performance data. Accompanying this practical guidance is
SoenEA, which further reinforces the recommended approach while limiting
tedious implementation tasks. This combination has greatly exceeded our
expectations.

Future Work
There are several important areas where the theory presented in this thesis
could be expanded. We have already begun work on how testing fits in with
this approach, in particular we have begun work on a system-level testing
approach that is tied closely to both DISPATCHERs and Use Cases.
Once a systematic testing approach exists, the next areas to explore are the
advanced topics needed to progress a project to commercial readiness. This
would cover the theory of analyzing the performance of a system, given the
domain-oriented approach we promote, and the subsequent optimization of
the access to data. To complement that theory, some guidance on the
specifics of working with SQL and the general types of SQL
statements/optimization/problems frequently come across when working
with Domain Objects world be instructive.
Marek Krajewsky, working with the Concordia Bioinformatics lab, has been
working on a project titled DOCrib to help codify the relationship between
DOMAIN OBJECTs, INPUT MAPPERs and TDGs. DOCrib has the potential to further
improve on the implementation approach suggested by SoenEA by reducing
much of the duplication in TDGs and FINDERs and making the querying of
ResultSets in INPUT MAPPERs more intuitive.
The advent of AJAX has given WEAs the responsiveness of desktop
applications, and the flexibility for incredibly rich interfaces, but there is little
guidance available on the integration of such GUIs with a back-end system.
www.assignmentwritingindia.co
m Page
17
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

An examination of the existing Javascript frameworks/toolkits available today


would further help WEA developers, as would a comprehensive examination
of UI design patterns.
As much of the theory described in this thesis leads to a nearly deterministic
approach to implementation, there has already been some work in terms of
code generation.

www.assignmentwritingindia.co
m Page
18
Enterprise Application Design Patterns
Section 4 Conclusions and Future Work

References

• Izurieta, Clemente, and James M. Bieman. 2008. Testing consequences


of grime buildup in object oriented design patterns. 2008 International
Conference on Software Testing, Verification, and Validation.
Lillehammer 171-179.

• Fowler M.: "Patterns of Enterprise Application Architecture," Addison-


Wesley, 2003

• Hohpe G., Woolf B.: "Enterprise Integration Patterns," Addison-Wesley,


2003

• Schmidt D., "Pattern-Oriented Software Architecture vol.2: Patterns for


Concurrent and Networked Objects," John Wiley \& Sons, 1999

• Gamma, E., "Design Patterns. Elements of Reusable Object-Oriented


Software," Addison-Wesley, 1995

www.assignmentwritingindia.co
m Page
19