quantitative analysis of design patterns on an object oriented web application

A REPORT ON

Quantitative Analysis of Design Patterns on an

Object-‐Oriented Web Application

BY

Rinckle Gohil 818

Abha Molri 835

Abishay Rao 847

Rohith Rao 848

Under the guidance of Prof. A. E. Patil

DEPARTMENT OF INFORMATION TECHNOLOGY MCT’S Rajiv Gandhi Institute of Technology

Juhu-‐Versova Link Road, Andheri (W), Mumbai-‐400 053.

UNIVERSITY OF MUMBAI

MAY – 2013

ii

CERTIFICATE DEPARTMENT OF INFORMATION TECHNOLOGY

THIS IS TO CERTIFY THAT

Rinckle Gohil 818

Abha Molri 835

Abishay Rao 847

Rohith Rao 848

have satisfactorily completed this report entitled

Quantitative Analysis of Design Patterns on an Object-‐Oriented

Web Application towards the partial fulfillment of the

BACHELOR OF ENGINEERING [B.E]

IN

INFORMATION TECHNOLOGY

as laid by the University of Mumbai.

Guide H.O.D

Prof. A. E. Patil Prof. D. M. Dalgade

Principal

Dr. U.V. Bhosle

Internal Examiner External Examiner

iii

ACKNOWLEDGEMENT

We wish to express our sincere gratitude to Dr. U. V. Bhosle, Principal

and Prof. D. M. Dalgade, H.O.D, Information Technology of RGIT for

providing us an opportunity to do our project work on “Quantitative

Analysis of Design Patterns on an Object-‐Oriented Web Application".

This project bears on imprint of many people. We sincerely thank our

project guide Prof. A. E. Patil for his guidance and encouragement in the

successful completion of our project synopsis. We would also like to thank

our staff members for their help in carrying out this project work.

We are grateful to Prof. Reena Lokare, an Information Systems field

veteran, for helping us during the initial phase of the project, without

which we could not have initiated this project. We would like to extend

our thanks to Prof. Pallavi Kulkarni, a Source Code Metric Calculation

and Design Patterns expert, for guiding us with Software Metrics.

Finally, we would like to thank our colleagues and friends who helped us

in completing the project successfully.

Rinckle Gohil 818

Abha Molri 835

Abishay Rao 847

Rohith Rao 848

iv

ABSTRACT E-‐commerce had made its mark at the turn of the century and has grown

rapidly since. But why have only some ventures been successful while

others drowned in this dotcom era?

In software engineering, a design pattern is a general reusable solution to

a commonly occurring problem within a given context in software design.

A design pattern is not a finished design that can be transformed directly

into source or machine code. It is a description or template for how to

solve a problem that can be used in many different situations. Patterns

are formalized best practices that all programmers must implement

themselves into the application.

The project work involves the studying of the effect of well-‐established

design patterns, such as Model View Controller, Front Controller, Easy

Undo and Cross-‐selling & Up-‐selling and also applies them to a B2C

(Business-‐to-‐Consumer) e-‐commerce application developed using the

Java EE Platform.

We measure popular Software Metrics on our code such as LCOM (Lack of

Cohesion in Methods), CBO (Coupling Between Objects), WMC (Weighted

Method Count) and RFC (Response For Classes). Finally, we measure the

differences in performance among our base application (without design

patterns) and our final application (with design patterns) using the

aforementioned Software Metrics.

v

TABLE OF CONTENTS

1. INTRODUCTION AND MOTIVATION .................................................................... 1 1.1. AREA OF PROBLEM ............................................................................................................... 1 1.1.1. Includes ....................................................................................................................... 1 1.1.2. Excludes ....................................................................................................................... 1

1.2. MOTIVATION ......................................................................................................................... 2 1.3. LITERATURE REVIEW .......................................................................................................... 3

2. PROBLEM STATEMENT ........................................................................................ 10

3. REQUIREMENT ANALYSIS .................................................................................... 11 3.1. INTRODUCTION ................................................................................................................... 11 3.1.1. Purpose ...................................................................................................................... 11 3.1.2. Overview .................................................................................................................... 11

3.2. USE CASES ............................................................................................................................ 11 3.2.1. Item Addition .............................................................................................................. 11 3.2.2. Item Deletion .............................................................................................................. 12 3.2.3. Checkout ....................................................................................................................... 13

3.3. MAJOR NON-‐FUNCTIONAL REQUIREMENTS .................................................................. 14 3.3.1. Criteria | Definition .................................................................................................. 14 3.3.2. Criteria | Solution ...................................................................................................... 14

4. PROJECT DESIGN .................................................................................................... 16 4.1. USE CASE DIAGRAM ........................................................................................................... 16

4.2. CLASS DIAGRAM .................................................................................................................. 17

4.3. ACTIVITY DIAGRAM ............................................................................................................ 18

4.4. DATA FLOW DIAGRAM ....................................................................................................... 19

4.4.1. DFD Context Level .................................................................................................... 19 4.4.2. DFD Level 1 .................................................................................................................. 20 4.4.3. DFD Level 2 -‐ Cart ..................................................................................................... 21

5. IMPLEMENTATION DETAILS .............................................................................. 22 5.1. DEVELOPING THE APPLICATION ...................................................................................... 22

vi

5.1.1. Gathering Customer Requirements .................................................................. 22 5.1.2. Determining the architecture .............................................................................. 22 5.1.3. Setting up the development environment ..................................................... 24 5.1.4. Designing the data model ...................................................................................... 24 5.1.5. Create an Entity-‐Relationship Diagram ........................................................... 25 5.1.6. Preparing the Page Views ...................................................................................... 25 5.1.7. Creating the Controller Servlet ........................................................................... 32 5.1.8. Adding entity classes and session beans ........................................................ 32 5.1.9. Managing Session ...................................................................................................... 34

5.2. CALCULATION OF SOFTWARE METRICS ........................................................................ 34 5.2.1. Description ................................................................................................................... 34 5.2.2. Measurement Process ............................................................................................. 35 5.2.3. Software Metrics we measured .......................................................................... 35

6. TECHNOLOGY DETAILS ........................................................................................ 39 6.1. INTEGRATED DEVELOPMENT ENVIRONMENT [IDE] .................................................. 39 6.2. GLASSFISH SERVER ............................................................................................................ 40 6.3. DATABASE : MYSQL .......................................................................................................... 40 6.4. DATABASE MANAGEMENT : MYSQL WORKBENCH .................................................... 41

7. TEST CASES ............................................................................................................... 42 7.1. CLASS UNDER TEST : SHOPPINGCART ........................................................................... 42 7.2. CLASS UNDER TEST : SHOPPINGCARTITEM .................................................................. 45

8. PROJECT TIMELINE ................................................................................................ 48 8.1. GANTT CHART I .................................................................................................................. 48 8.2. GANTT CHART II ................................................................................................................ 49

9. TASK DISTRIBUTION ............................................................................................ 50 9.1. WORK BREAKDOWN STRUCTURE ................................................................................... 50 9.2. RESPONSIBILITY MATRIX ................................................................................................. 34

10. CONCLUSION ............................................................................................................ 51 10.1. PERCENTAGE CHANGE ANALYSIS ................................................................................... 52 10.1.1. LCOM % Change ...................................................................................................... 52 10.1.2. CBO % Change ......................................................................................................... 53

vii

10.1.3. RFC % Change .......................................................................................................... 54 10.1.4. WMC % Change ....................................................................................................... 55

10.2. FUTURE SCOPE ................................................................................................................... 56

11. REFERENCES ............................................................................................................ 57 Appendix .............................................................................................................................................. 62

viii

LIST OF FIGURES

Figure 4.1: Use Case Diagram for Ethnique Store

Figure 4.2: Class Diagram for Ethnique Store

Figure 4.3: Activity Diagram for Ethnique Store

Figure 4.4: Data Flow Diagram -‐ Context Level

Figure 4.5: Data Flow Diagram -‐ Level 1

Figure 4.6: Data Flow Diagram -‐ Level 2 -‐ Cart

Figure 5.1: Model View Controller schema for Ethnique Store

Figure 5.2: Front Contoller Schema for Ethnique Store

Figure 5.3: Entity-‐Relationship Diagram for Ethnique Store

Figure 5.4: Screenshot of Ethnique Store -‐ Welcome Page

Figure 5.5: Screenshot of Ethnique Store -‐ Category Page

Figure 5.6: Screenshot of Ethnique Store -‐ Product Page

Figure 5.7: Screenshot of Ethnique Store -‐ Product Details Page

Figure 5.8: Screenshot of Ethnique Store -‐ Easy Undo Page I

Figure 5.9: Screenshot of Ethnique Store -‐ Easy Undo Page II

Figure 5.10: Screenshot of Ethnique Store -‐ Cart Page: Update Quantity

Figure 5.11: Screenshot of Ethnique Store -‐ Cart Page

Figure 5.12: Screenshot of Ethnique Store -‐ Checkout Page

Figure 5.13: Screenshot of Ethnique Store -‐ Validation Page

Figure 5.14: Screenshot of Ethnique Store -‐ Payment Confirmation Page

Figure 5.15: Screenshot of Ethnique Store -‐ Entity Package

Figure 5.16: Screenshot of Ethnique Store -‐ Session Package

Figure 8.1: Prjoect Time Line for Development of Ethnique Store

Figure 8.2: Gantt Chart for Development of Ethnique Store I

Figure 8.3: Gantt Chart for Development of Ethnique Store II

Figure 9.1: Work Breakdown Structure for Development of Ethnique

Store

ix

Figure 9.2: Responsisbilty Matrix for Development of Ethnique Store

Figure 10.1: Metrics Calculation Report for Ethinique Store

Figure 10.2: Metrics Graph: LCOM % Change -‐ Ethnique Store

Figure 10.3: Metrics Graph -‐LCOM % Change -‐ Reference Paper

Figure 10.4: Metrics Graph -‐CBO % Change -‐ Ethnique Store

Figure 10.5: Metrics Graph -‐CBO % Change -‐ Reference Paper

Figure 10.6: Metrics Graph -‐RFC % Change -‐ Ethnique Store

Figure 10.7: Metrics Graph -‐RFC % Change -‐ Reference Paper

Figure 10.8: Metrics Graph -‐WMC % Change -‐ Ethnique Store

Figure 10.9: Metrics Graph -‐WMC % Change -‐ Reference Paper

x

LIST OF TABLES

Table 3.1: Functional Requirement -‐ Use Case Item Addition

Table 3.2: Functional Requirement -‐ Use Case Item Deletion

Table 3.3: Functional Requirement -‐ Use Case Checkout

Table 3.4: Non-‐Functional Requirement: Criteria-‐Definition

Table 3.5: Non-‐Functional Requirement: Criteria-‐Solution

Table 7.1 -‐ 7.8: Test Cases for ShoppingCart Class

Table 7.9 -‐ 7.13: Test Cases for ShoppingCartItem Class

xi

ACRONYMS USED

i. GoF – Gang of Four [Book on Design Patterns]

ii. Java EE – Java Enterprise Edition

iii. CORBA – Common Object Request Broker Architecture

iv. B2C Model – Business to Consumer Model

v. COD – Cash-‐on-‐Delivery

vi. MVC – Model-‐View-‐Controller

vii. HTML – HyperText Markup Language

viii. EJB – Enterprise Java Beans

ix. CBO – Coupling Between Objects

x. CM – Changing Methods

xi. ChC – Changing Classes

xii. LCOM – Lack of Cohesion in Methods

xiii. UI – User Interface

xiv. IDE – Integrated Development Environment

xv. CMS – Content Management System

xvi. JPA – Java Persistence API

xvii. EAS – Enterprise Application Server

xviii. GB – Giga Byte

xix. RAM – Random Access Memory

xx. GHz – Giga Hertz

xxi. HTTP – HyperText Transfer Protocol

xxii. SSL – Secure Socket Layer

CHAPTER 1

Quantitative Analysis Of Design Patterns On An Object-Oriented Web Application

Department of Information Technology 1

1. Introduction and Motivation

1.1. Area of Problem

To understand the scope of this project, let’s divide it under two

categories:

1.1.1. Includes

The proposed e-‐commerce application is entirely based on Java, and

hence includes the use of core-‐Java architecture. It also includes several

add-‐on Java frameworks, which are not mandatory, but shall be used to

enhance the real-‐world performance of the application. The finally

deployed application will make use of well-‐established Design Patterns in

the Software Industry, often used as “best practices”, especially within the

field of our application, “E-‐Commerce”. Since the main idea behind this

project is to analyze the differences that Design Patterns can make, we

will use clearly defined parameters from sophisticated Software Metrics,

also often used as “best practices”. The basic form of comparison between

the derived values for the parameters shall be the most popular ‘tabular’

format. However, because numbers may fail beyond a point, we will also

graphically plot the results in a way that the educated non-‐expert easily

comprehends the benefits and/or drawbacks of Design Patterns. Also, we

may include the use of several open source tools and/or applications, as

the need arises.

1.1.2. Excludes

Since the motivation of the proposed e-‐commerce application is to

understand the impact of Design Patterns, and given the time frame of

about 15 weeks, it is not realistic to expect a full-‐fledged marketplace that

will host hundreds of catalog items. We shall instead measure the

parameters on fewer items that will give us a better understanding of



Design Patterns. Also, we do not mean to make any attempt at classifying

design patterns according to usage, which demands a separate study for

itself. We will only use limited features of the add-‐on Java frameworks

that is mentioned in the previous sub-‐section, and that will only include

features that are critical to achieve certain functionalities within the

scope of this project.

1.2. Motivation

We, as developers are constantly faced with a situation wherein we have

to program a common module, a login page, for instance, over and over

again. To achieve so, we have to follow a specific set of procedures, which

are tagged as “industry standard” or “best practices”. So, we set out to find

out if there was any one really “standard” mechanism to solve such

commonly occurring business problems. Design Patterns emerged as the

clear answer that could be integrated at every level of the application

development paradigm.

Today, every business willing to set out and develop a web application for

its business does so to interact with its customers and market their

product better. This means that the business relies on a database of

customers that it either already has, or is willing to acquire through the

web application being built. This meant that “data” clearly is the central

focus of both functionality and usability. From a developer’s point of view,

things can get messy with data, therefore, there had to be a clear

segregation between the data and the User Interface that the customer is

faced with. Hence, we chose to study the Model-‐View-‐Controller, or MVC

Design Pattern.

A business’ customers both don’t want to wait as well as want their data

residing on the web application to be secure. These are the two key

factors that either attract your consumers or cause it to doom. The Front



Controller design pattern was the best value addition to MVC from a pure

performance and security point of view. And hence, we have integrated

the Front Controller design pattern into the application along with MVC.

Given that we set out to study these interesting design patterns on a very

interesting and booming online business space like e-‐commerce, we had

to justify our study by picking up design patterns that leveraged the e-‐

commerce space and made the study interesting.

First and foremost, the most popular functionality on an e-‐commerce

website from a sale-‐boost point of view is being able to offer similar or

relevant products to the product that the user is currently viewing. We

achieved this by using the Cross-‐Selling and Up-‐Selling Design Pattern.

Another functionality of paramount importance from a pure usability

point of view is the user being able to easily undo the actions they

perform accidentally. Hence, the Easy Undo Design Pattern was quickly

integrated throughout the application.

We wanted to study the effect of employing these Design Patterns on a

Java-‐based E-‐commerce application, and the benefits they offered if used

in the right way. What could be better to prove one better over the other

than numbers? We studied industry-‐standard Software Metrics and used

them very carefully to measure the differences in numbers between the

Design Pattern based application and the base application that did not use

the aforementioned design patterns.

1.3. Literature Review

E-‐commerce has been one of the fastest growing industries in the retail

sector over the past decade. Today, most consumers shop for products

online, causing the speed of this boom to become truly astounding.

Research shows that new e-‐commerce applications arise every week, thus



resulting in hundreds of thousands of online stores on the web. Electronic

stores and retailers are gaining popularity by the minute.[1] This is by far

the best time one could start selling on the web. Moreover, the number of

methods to make such applications has also increased multifold. Now, one

can easily work with an e-‐commerce platform provider and create their

own online store in simple steps without any professional help. Whereas,

web development professionals also have advanced tools that help them

create highly scalable and robust e-‐commerce applications.

Let’s talk about a new or fresh programmer attempting to develop an e-‐

commerce application; this is the point where Design Patterns come into

the picture. [2] Design Patterns can be defined as a general reusable

solution to a commonly occurring problem within a given context of

software design. These patterns are templates that describe how to solve

a particular problem in many situations. These design patterns work most

efficiently with Object Oriented programming languages.

A software developer did not establish the concept of design patterns;

rather, it was a professor of architecture named Christopher Alexander.

During the late ‘70’s, Alexander published many works that introduced

the concepts of patterns and provided a catalog of patterns for

architectural design.

Christopher Alexander said, "Each pattern describes a problem which

occurs over and over again in our environment, and then describes the

core of the solution to that problem, in such a way that you can use this

solution a million times over, without ever doing it the same way

twice".[21] Even though Alexander was talking about patterns in buildings

and towns, what he meant was also true for object-‐oriented design

patterns.



The best-‐known contribution to the popularity of design patterns was the

1995 book Design Patterns: Elements of Reusable Object-‐Oriented

Software. The authors—Erich Gamma, Richard Helm, Ralph Johnson, and

John Vlissides—are also commonly known as the “Gang of Four” or GoF.

The book introduced a comprehensive pattern language, and gave C++

examples for the patterns discussed. The book is divided into two parts,

with the first two chapters exploring the capabilities and pitfalls of object-‐

oriented programming, and the remaining chapters describing 23 classic

software design patterns. [16] The book was first made available to the

public at OOPSLA meeting held in Portland, Oregon, in October 1994. It

has been highly influential to the field of software engineering and is

regarded as an important source for object-‐oriented design theory and

practice.

The work of Martin Fowler also had a great influence on the early

understanding of software design patterns. His book, Patterns of

Enterprise Application Architecture is written in direct response to the

stiff challenges that face enterprise application developers. The author,

noted object-‐oriented designer Martin Fowler, noticed that despite

changes in technology-‐-‐from Smalltalk to CORBA to Java to .NET-‐-‐the

same basic design ideas can be adapted and applied to solve common

problems. [15] With the help of an expert group of contributors, Martin

covers over forty recurring solutions into patterns. The result is an

incredible handbook of solutions that are applicable to any enterprise

application platform. This book is actually two books in one. The first

section is a short tutorial on developing enterprise applications, which

one can read from start to finish to understand the scope of the book's

lessons. The next section, the bulk of the book, is a detailed reference to

the patterns themselves. Each pattern provides usage and

implementation information, as well as detailed code examples in Java or



C#. The entire book is also richly illustrated with UML diagrams to further

explain the concepts.

One of the recent books on Design Pattern concepts called Head First

Design Patterns, written by Eric Freeman, Elisabeth Freeman, Kathy

Sierra and Bert Bates explains the topic in a completely different

approach. The book is full of cartoons, illustrations and sketches with

designer captions. Such features are new to a software development

reference book. Moreover, the language and examples used are quite

informal in tone and help to explain software fundamentals to non-‐

technical readers. The authors believe that learning is effective when

concepts are explained repetitively and associating graphical images with

the text. This will allow a reader to think more deeply, rather than just

reading the plain text. Thus the attention span of the reader is highly

improved and is very effective too. As a result, the book not only teaches

certain principles of design patterns but also touches its readers

emotionally. [14]

After understanding design patterns, the next step was to learn object-‐

oriented development of web applications. A book, which aided very

effectively in this step, was Object Oriented Design Knowledge, written by

Javier Garzas and Mario Piattini. This book goes deep into object-‐oriented

principles, heuristics and best practices. The book is a good tool for new

Java programmers and leaves no room for making mistakes. As the reader

learns about best practices, programming the application will be done in a

structured and scalable manner. Thus, this book gives a reader a holistic

approach towards understanding object oriented programming with

design patters.

Stephen Stelting publishes a detailed documentation about a large

number of Design Patterns and Olav Maassen called Applied Java

Patterns. The book boasts of Pattern-‐based solutions for every stage of



the development lifecycle and also documents 30 patterns, including the

23 core patterns. Sun Microsystems experts Steve Stelting and Olav

Maassen bring together today’s best pattern-‐based techniques and

demonstrate pattern use for a variety of business systems. This practical

guide features proven techniques for all types of patterns, from system

architecture to single classes. After briefly reviewing the fundamentals of

design patterns, the authors describe how these patterns can be applied

effectively to the Java platform. Next, they provide a pattern catalog,

organized into four major categories—the creational, behavioral,

structural, and system patterns. In addition, they identify patterns and

present techniques for pattern use in the core Java APIs as well as the

APIs for distributed development. Applied Java Patterns also features a

section on pattern use in systems built with J2EE and JINI technologies,

and coverage of the servlet, JSP, EJB, and JavaSpaces APIs. Without a

doubt, this accessible and up-‐to-‐date guide can help you enhance your

Java platform programming skills.

The first task during the implementation phase would be developing an

eCommerce application. For this phase, an apt research paper was

studies, called “Building E-‐Commerce Applications from Object-‐Oriented

Conceptual Models”. This research paper is written by Oscar Pastor, Silvia

Abrahão and Joan Fons. This paper introduces an extension to UML that

takes care of web page navigation using the OO-‐ Method, dynamic

prototyping, and a new way of specifying the navigation design.

Furthermore, a software production process for e-‐commerce applications

design is described. This process is driven by an Object-‐Oriented Web-‐

Solutions Modeling approach (OOWS), which provides mechanisms to

deal with the development of web-‐based applications. With such an

extended conceptual model, system functionality and navigational

features are described within a unified framework. Once the system



specification is completed (problem space level), a strategy to obtain the

software components that will constitute the final software product

(solution space level) is defined. Thus, briefly describing how to map

these abstraction primitives to e-‐commerce applications in order to be

able to go from the problem space to the solution space in a structured,

automated way. [4]

A general practice while developing object-‐oriented applications is the

use of UML diagrams during software designing. For this prupose an

important work was published by a group of writers, the research paper

is named “Use Case Based Innovative Design of E-‐commerce Website”.

Rongrong Gong, Shijian Luo, Ji He Department of Industrial Design,

College of Computer Science and Technology, Zhejiang University,

Hangzhou, submitted the research. The book states that a user’s demand

can be met by understanding the use case for the system to be developed.

The UML diagrams can help a developer to visualize the business flow and

activities to be performed by the applications. [24] The paper appropriately

syas that, “Innovative design is an ongoing process of iteration in E-‐

commerce”. The paper also goe on to discuss designing of UI (User

Interface) for the application and layout of the application home page.

Once the application development begins, it is also important to follow

certain principal and common practices during this phase. One paper that

talks very effectively about this is called “Applying Pattern Oriented

Software Engineering to Web Service Development”. This paper is

submitted by Wang Chengjun from Department of Computer Science and

Technology WeiFang University, WeiFang, ShanDong,261041, China. In

this paper, a pattern oriented service development approach (POSE) is

presented. Patterns are used as the means to express the results of

different development phases, so that the services can be organized and

retrieved easily. The business model is constructed explicitly, thus the gap



between business goal and services is bridged by the component

relationships and the compositions of them. The service maintainer

profits from the trace ability because the impact of requirement or design

modifications can be better assessed. The patterns support to integrate

services of varying levels of granularity. The POSE introduces the notion

of pattern that fits for service composition. Pattern is a way of reuse

abstract knowledge about a recurrent problem in a particular context and

its solution. When the problem is complex, it can be divided into a few

more simple problems, and each one is resolved in an independent

pattern. The simplicity of a pattern and its “small size” make it easy to

understand, integrate and reuse. Pattern is “know-‐how” oriented that

provides both solution and engineering guidance to reuse them. [28]

During the study about various applications and design patterns, there

were some cases found where design pattern did not improve the quality

of applications. It was found that, where some design patterns may

improve the effectiveness of an application, there might be others that

may degrade the application. An important work published by a group of

Italian scientists. This paper is called “Relationship between design

patterns defects and crosscutting concern scattering degree: an empirical

study”, it is published by L. Aversano, L. Cerulo and M. Di Penta from the

Department of Engineering, University of Sannio, Via Traiano –

Benevento, Italy. It describes why despite the advantages, the usage of

design patterns implies the presence of crosscutting code implementing

the pattern usage and access from other system components. [3] When the

system evolves, the presence of crosscutting code can cause repeated

changes, possibly introducing defects.

CHAPTER 2



2. Problem Statement

Today, every business aspires to have an impact not only in the local

markets but also on a global scale. This is the reason why more

businesses are willing to develop online stores for marketing their

products on the World Wide Web. Developing e-‐commerce applications

requires both skills and experience. [9] It is difficult to develop powerful,

scalable and robust applications in a few, simple steps. Such applications

should provide users with stability under high loads, handling concurrent

users, uniform performance under high load, fault tolerance and gradual

degradation of services under stress.

The project involves development of an ecommerce application for B2C

model. The application features architectural, implementation and user

interface level design patterns. This project statistically measures the

advantages of using software design patterns for a Java-‐based e-‐

commerce application. The final product will comprise of a generic

application for an online store that has the functions that a user needs

today. It will aim to capture the experience of experts so that new

developers can get assistance. [19]

This project statistically measures the advantages of using software

design patterns for a Java-‐based e-‐commerce application. The

performance of the application would be measured by industry-‐standard

software metrics. Characteristics to be observed are coupling, cohesion,

complexity, reusability, maintainability and flexibility. [17] These

properties are transformed into metrics like Coupling Between Objects

(CBO), Lack of Cohesion in Methods (LCOM), Number of Children (NOC),

Weighted Method per Class (WMC) and Response for Class (RFC).

CHAPTER 3



3. Requirement Analysis

3.1. Introduction

3.1.1. Purpose

The aim of this document is to record the requirements of the Ethnique

Store Application.

3.1.2. Overview

The Ethnique Store is an online boutique store selling various items

belonging to several categories of products such as Apparel, Footwear,

and Accessories etc.

The Ethnique Store shall be developed based on a MySQL database, where

data are saved and flexible for different reporting scenarios. The main

idea behind the development of this application is to ascertain the impact

of Design Patterns on such a flexible and scale-‐hungry application in the

wide domain of e-‐commerce.

3.2. Use Cases

3.2.1. Item Addition

Name Item Addition

Description A user wants to add an item to the cart

Actors User

Prerequisite Products selected and “Add to Cart” button

clicked.

Result Item is added to cart and numberOfItems is

incremented by 1.

Process (good case) 1. Home Page is shown



2. User clicks on any category of product

3. System displays the products for that

category

4. User clicks the “Add to Cart” button on a

product he/she wants to purchase

Non Functional

Requirement

The response time to add the item to the cart

should be within 2 seconds, irrespective of

system condition. [Consider Varnish HTTP

Reverse Proxy Suite]

3.2.2. Item Deletion

Name Item Deletion

Description A user wants to delete an item from the

cart

Actors User

Prerequisite Products selected and “Remove from

Cart” button clicked.

Result Item is deleted from cart and

numberOfItems is decremented by 1.

Process (good case) 1. User clicks on “View Cart”

2. User updates the quantity field of

product to be deleted to “zero”

3. System displays the updated cart

without the item in context of

point number 2.

Non Functional

Requirement

Response time to remove the item from

the cart should be within 2~3 seconds.

Table 3.1. Functional Requirement -‐ Use Case Item Addition



3.2.3. Checkout

Name Checkout

Description A user wants to move on to payment and

delivery options with the items in the

current cart instance.

Actors User

Prerequisite Items added to cart and the “Proceed to

Checkout” button clicked.

Result Checkout Page displayed

Process (good case) 1. User clicks on “Proceed to

Checkout”

2. System displays page to enter

personal and payment information

Non Functional

Requirement

The response time to process the

Checkout must be lesser than 5 seconds

(not accounting for third-‐party payment

gateway navigation and/or processing

time). The input data required to be

entered by the user should be clear and

unambiguous.

Table 3.3. Functional Requirement -‐ Use Case Checkout



3.3. Major Non-Functional Requirements

Software architecture has to reflect the non-‐functional requirements of a

system. It has to fulfill the following criteria:

3.3.1. Criteria | Definition

Criteria Definition

Security The ability to ensure that information is neither modified

nor disclosed except in accordance with the security

policy.

Manageability The ability to manage the system to ensure the continued

health of the system with respect to the other criteria.

Reliability The ability to ensure the integrity and consistency of an

application and its transactions.

Scalability The ability to support the required quality of service as

load increases.

Performance The ability to execute functions quickly enough to meet

performance goals.

Testability The ability to determine what the expected results should

be.

3.3.2. Criteria | Solution

Criteria Solution

Security Access to the system’s CMS (Content Management

System) must be restricted to administrators and other

stakeholders holding a valid username/password

combination.

Manageability The architecture is purely client server. New versions are

Table 3.4. Non-‐Functional Requirement: Criteria-‐Definition



distributed over the web when accessing the application.

Reliability The system makes use of a relational database and uses

for all DB operations transactions.

Scalability The system’s main processing for GUI and calculations

are on server side. Adding many users to the system will

have sufficient impact on processing times of various

clients concurrently.

Performance The system is meant to provide a highly responsive

interface. It is designed to assist customers in finding the

right products and provide an easy checkout interface

too.

Testability As all the computations and business logic lies on the

server side, it is easy to test the application at various

levels viz. Unit, Integration, System etc.

Table 3.5. Non-‐Functional Requirement: Criteria-‐Solution

CHAPTER 4



4. PROJECT DESIGN

4.1. Use Case Diagram

Figure 4.1. Use Case Diagram for Ethnique Store



4.2. Class Diagram

Figure 4.2. Class Diagram for Ethnique Store



4.3. Activity Diagram

Figure 4.3. Activity Diagram for Ethnique Store



4.4. Data Flow Diagram

4.4.1. DFD Context Level

Figure 4.4. Data Flow Diagram -‐ Context Level

Customer

Boutique eCommerce

Portal

Admin

ShippingAgent

Customer / Order Billing Detail

Add / UpdateProduct Catalogue

Order Acceptance /Rejection

Order / Data

Order Confirmation

Delivery



4.4.2. DFD Level 1

Figure 4.5. Data Flow Diagram -‐ Level 1

1Shopping

Cart

Customer

2

Recieve Order

ShoppingCartD1

Add Item

Add Order

New Cart

ShoppingCartItemD2

Product Details

Cart ID

3

Proceed to Checkout

Confirm Order

Product / Cart Data

Customer Data

4

PaymentConfirmation

CustomerD3

OrderedProductD4

CustomerDetails

Ordered Product Details



4.4.3. DFD Level 2 – Cart

Figure 4.6. Data Flow Diagram -‐ Level 2 -‐ Cart

1.1

AddToCart

Customer

ShoppingCartD1Quantity

Cart Item

ShoppingCartItemD2

Cart ID

Catalogue

Browse Products

Select Product

AdministratorUpdate Catalogue

Customer

1.2

Show CartEdit Cart

Cart Item Details

1.3

Check Out

Proceed to Checkout Cart Total

Payment

Order / Billing Details

CustomerOrderD3

Customer Detials

CHAPTER 5



5. IMPLEMENTATION DETAILS

5.1. Developing The Application

5.1.1. Gathering Customer Requirements

Based on the current scenario in the market, The Ethnique store should fulfills the

following requirements:

I) An online representation of the products that are sold in the physical store.

There are four categories (Apparel, Accessories, Footwear and Bags), and four

products for each category, which online shoppers can browse. Details are

provided for each product (i.e., name, image, description, price).

II) Shopping cart functionality, which includes the ability to:

a. Add items to a virtual shopping cart.

b. Remove items from the shopping cart.

c. Update item quantities in the shopping cart.

d. View a summary of all items and quantities in the shopping cart.

e. Place an order and make payment through a secure checkout process.

III) An administration console, enabling staff to view customer orders.

IV) Security, in the form of protecting sensitive customer data while it is

transferred over the Internet, and preventing unauthorized access to the

administration console. [28]

5.1.2. Determining the architecture

This application is based on MVC (Model-‐View-‐Controller) paradigm, which

divides it into three interoperable components:

Model: Represents the business data and any business logic that govern access to

and modification of the data. The model notifies views when it changes and lets



the view query the model about its state. It also lets the controller access

application functionality encapsulated by the model.

View: The view renders the contents of a model. It gets data from the model and

specifies how that data should be presented. It updates data presentation when

the model changes. A view also forwards user input to a controller.

Controller: The controller defines application behavior. It dispatches user

requests and selects views for presentation. It interprets user inputs and maps

them into actions to be performed by the model. In a web application, user inputs

are HTTP GET and POST requests. A controller selects the next view to display

based on the user interactions and the outcome of the model operations. [10]

Figure 5.1. Model View Controller schema for Ethnique Store



The servlet acts as a controller to handle incoming requests. The pages from the

business process flow diagram can be mapped to views. Finally, the business data,

which is maintained in a database, is accessed and modified in the application

using EJB session beans with JPA entity classes. These components represent the

model.

Figure 5.2. Front Contoller Schema for Ethnique Store

5.1.3. Setting up the development environment

The following steps describe how to set up your development environment:

a. Creating a web project b. Running the web project c. Communicating with the database server

5.1.4. Designing the data model

Identifying entities for the data model-‐ Creating a data model involves identifying

the objects, or entities, required by the system and defining the relationships

between them. [22] To begin identifying the entities needed for the data model, we

have to examine the use-‐case designed for the application. In our application,

there are four main entities as follows:

a. customer c. product b. category d. order



5.1.5. Create an entity-relationship diagram

Figure 5.3. Entity-‐Relationship Diagram for Ethnique Store

5.1.6. Preparing the page views

Welcome Page: The welcome page is the website's home page, and entry point

for the application. It introduces the business and service to the user, and enables

the user to navigate to any of the four product categories.

Figure 5.4. Screenshot of Ethnique Store -‐ Welcome Page



Category Page-‐ The category page provides a listing of all products within the

selected category. From this page, a user is able to view all product information,

and add any of the listed products to his or her shopping cart.

Product Page-‐ This shows the list of products within a category. The user can also

navigate through other categories and browse through the products.

Figure 5.5. Screenshot of Ethnique Store -‐ Category Page

Figure 5.6. Screenshot of Ethnique Store -‐ Product Page



Product Details-‐ The product details page pops up and displays the selected

product information along with related products from the same category This

helps the user to navigate through similar products. It offers opportunities for the

marketers to increase revenue at a relatively small cost. It uses three different

strategies:

1. Advantage of available data is taken: It is a predictive model, which

identifies new trends, and customer needs.

2. Appropriate resources are deployed: Appropriate technology is used to

both analyze the data and link the insight with cross-‐sell opportunities

that fit.

3. Consider when and where to reach out: To strategically find about when and where cross-‐sell offers will be made. Identify best position on

the screen.

Figure 5.7. Screenshot of Ethnique Store -‐ Product Details Page



Easy Undo-‐ The user is provided with Undo facilities avoiding him to use

navigation facilities for this purpose. The undo facilities will have to take into

account the customer state and browsing semantics in order to be effective.

t

Figure 5.8. Screenshot of Ethnique Store -‐ Easy Undo Page I

Figure 5.9. Screenshot of Ethnique Store -‐ Easy Undo Page II



Update Quantity-‐ The user can update the quantities of the selected product cart

directly from the cart display. This reduces a significant workload for the user and

allows him to buy multiple quantities at a same time.

Cart Page-‐ The cart page lists all items held in the user's shopping cart. It displays

product details for each item, and tallies the subtotal for the items in the cart. From

this page, a user can:

a. Clear all items in his or her cart

(Clicking 'clear cart' causes the 'proceed to checkout' buttons and shopping

cart table to disappear.)

b. Update the quantity for any listed item

(The price and quantity are updated; the subtotal is recalculated. If user

sets quantity to '0', the product table row is removed.)

c. Return to the previous category by clicking 'continue shopping'

d. Proceed to checkout

Figure 5.10. Screenshot of Ethnique Store -‐ Cart Page -‐ Update Quantity



Checkout Page-‐ The checkout page collects information from the customer using

a form. This page also displays purchase conditions, and summarizes the order by

providing calculations for the total cost.

The user is able to send personal details over a secure channel.

Figure 5.11. Screenshot of Ethnique Store -‐ Cart Page

Figure 5.12. Screenshot of Ethnique Store -‐ Checkout Page



Validation Page-‐ Form validation is the process of checking that a form has been filled

in correctly before it is processed. This not only aids users by providing meaningful

feedback for fields with invalid entries.

Confirmation Page-‐ The confirmation page returns a message to the customer

confirming that the order was successfully recorded. An order reference number

is provided to the customer, as well as a summary listing order details. Order

summary and customer personal details are returned over a secure channel.

The user is able to proceed to checkout from any page, provided that:

a) The shopping cart is not empty

b) The user is not already on the checkout page

c) The user has not already checked out (i.e., is on the confirmation page)

d) View the status of his or her shopping cart (if it is not empty)

Figure 5.13. Screenshot of Ethnique Store -‐ Validation Page



5.1.7. Creating the Controller Servlet

The controller servlet handles incoming requests by initiating any actions needed

to generate the model for the request, then forwarding the request to the

appropriate view.

The IDE provides a Servlet wizard that enables us to define the servlet component

in a web application either by including the @WebServlet annotation in the

generated class, or by adding the necessary directives to the deployment

descriptor. We create the ControllerServlet and define it in the application context

using the @WebServlet annotation. [27]

In ControllerServlet, the IDE's servlet employs a processRequest method, which is

called by both doGet and doPost methods.

5.1.8. Adding entity classes and session beans

Entity Classes from Database wizard: Creates a Java Persistence API entity class

Figure 5.14. Screenshot of Ethnique Store -‐ Payment Confirmation Page



for each selected database table, complete with named query annotations, fields

representing columns, and relationships representing foreign keys. The official

EJB product page describes Enterprise JavaBeans technology as a "server-‐side

component architecture"[5] that "enables rapid and simplified development of

distributed, transactional, secure and portable applications."

Session Beans for Entity Classes wizard: Creates an EJB session facade for each

entity class with basic access methods. A client invokes Enterprise session beans

in order to perform a specific business operation. The name session implies that a

bean instance is available for the duration of a "unit of work". [13]

Figure 5.15. Screenshot of Ethnique Store -‐ Entity Package

Figure 5.16. Screenshot of Ethnique Store -‐ Session Package



The EJB describes a typical session object as having the following characteristics:

1. Executes on behalf of a single client

2. Can be transaction-‐aware

3. Updates shared data in an underlying database

4. Does not represent directly shared data in the database, although it may

access and update such data

5. Is relatively short-‐lived

6. Is removed when the EJB container crashes. The client has to re-‐

establish a new session object to continue computation.

5.1.9. Managing Session

Applications can manage user sessions with the HttpSession object. User-‐specific

data is bind to the HttpSession object, then this data is accessed at a later stage.

Both bind and access actions can be done from Java classes, as well as from

session-‐scoped variables in EL expressions:

1. Working with an HttpSession Object

2. Working with Scoped Variables in Web Applications

5.2. Calculation Of Software Metrics

5.2.1. Description The goal of software metric is to measure the essential parameters that affect

software development. Recent results indicate that the conscientious

implementation and application of a software metrics [25] program can help

achieve better management results, both in the short run (for a given project) and

in the long run (improving productivity on future projects).



5.2.2. Measurement Process We will use the basic process model of input -‐ process -‐ output to discuss software

entities. Software entities of the input type include all of the resources used for

software research, development, and production.

5.2.3. Software Metrics we measured

The quality of the source code has been evaluated using a set of metrics. Simple

classes with few methods are easy to change and extend. The metrics that are used

to evaluate how easily the source code can be maintained and extended before

and after the implementation of each design pattern are:

5.2.3.1. WEIGHTED METHODS PER CLASS (WMC)

Definition: Given a class C,

WMC(C) =c1+c2+...+cn,

where ci is the complexity of Mi which is a method of C and i is from 0 to n, n being

number of methods of C. In, the method to calculate complexity of the methods is

left to the concept in use. It is very common to choose it as the McCabe’s

Cyclomatic Complexity (CC). CC is defined as the maximum number of linearly

independent execution paths in a program . It is calculated as cyclomatic number

of a program control graph; where cyclomatic number of a graph G is defined as

V(G)= e-‐n+2p; where e is the number of edges, n is the number of nodes and p is

the connected components in G. To obtain the control graph of a program e is

calculated as the number of branches, n is taken as the number of code blocks and

p as connected program segments. It is a very widely used complexity measure. In

this thesis CC is also chosen to calculate WMC values of the classes.

Interpretation:

Complexity is an indicator of the effort used for developing and to understand a

code segment. Complexity is a good indicator of fault prone software. Fault prone

software is not stable. WMC is the OO version of the complexity. High values of this



metric mean a class with many complex methods. Therefore, this metric can be

chosen to be an indicator of maintainability since it affects fault proneness,

stability and understandability. [6] WMC is usually correlated with the effort

needed to test that class. Since testability being a sub-‐character of maintainability,

we can conclude that as WMC of a class increases maintainability of that class

decreases.

5.2.3.2. COUPLING BETWEEN OBJECTS (CBO)

Definition:

CBO for class C stands for the number of other classes that C is coupled. A class is

coupled to another if one uses other’s methods; attributes or one is inherited from

the other.

Interpretation:

There are two types of coupling, internal and external. Internal coupling of a class

C (fan-‐out of C) stands for how much C uses other classes’ services. On the other

hand external coupling of C (fan-‐in of C) [12] show how much other classes use C’s

services. It is showed that internal coupling increases fault proneness of class. It is

expected since a class highly coupled to other classes will be unaware of the

changes done to other classes and this may cause the class to function wrongly or

errors to be carried to the class. However, external coupling does not increase

fault proneness of the class itself since how much a class is used by others does

not affect the class but external coupling means internal coupling for other classes

and high external coupling increases overall coupling in software. So both

coupling types affect fault-‐proneness of software. CBO, containing both of these

couplings, is a predictor of fault proneness therefore, maintainability. High CBO

signals poor and complex design, decreases modularity and reuse, complicate

testing of the class and as a result decreases understandability and testability. So,

CBO constitutes a measure for maintainability.



5.2.3.3. LACK OF COHESION IN METHODS (LCOM)

Definition:

The number of common instance variables they use gives degree of similarity of

two methods M1 and M2 of Ci. Let P be the set of pairs of methods with degree of

similarity zero and Q be the set of pairs of methods in C with degree of similarity

being positive. Then LCOM of C is defined as:

LCOM = |P| -‐|Q| ; if |P|> |Q|

= 0 ; Otherwise

Interpretation:

LCOM for a class being positive means methods of that class form disjoint sets of

methods that are working on disjoint sets of attributes. Then this means as the

LCOM increases number of uncorrelated services in the class increases. As an OO

principle this type of classes should be divided according to the independent jobs

they contain. Kemerer et. al. proposed that high values of LCOM [11] signal

complexity and therefore, error proneness. However, Briend et. al. experimented

that LCOM has no significant effect on error-‐proneness. Case studies showed

different results; in one LCOM values increased with testability metrics whereas in

the other decreased. It can be concluded that LCOM is uncorrelated with the

maintainability of the software under these discussions. It is included in the

metric suite to experimentally evaluate its level of meaningfulness.

5.2.3.4. RESPONSE FOR A CLASS (RFC)

Definition:

RFC of a class C is the cardinality of the set of methods that belong to C or is

invoked by methods of C.



Interpretation:

RFC is another measure of internal coupling since it contains the number of

methods that the class is coupled to. Internal coupling is found to be the strong

indicator of the class fault proneness. According to Chidamber and Kemerer , RFC

indicates the complexity of a class and gives a measure of testing time. The

statement is supported by experimental data since when a class is needed to be

(unit) tested; tester has to cope with the initialization of the instances of classes

whose methods are invoked by the class. To conclude, RFC affects the

understandability, fault proneness and testability against maintainability.

Therefore, as RFC increases, maintainability decreases.

CHAPTER 6



6. Technology Details 6.1. Integrated Development Environment:

Netbeans IDE

Why IDE? The term IDE stands for integrated development environment. The

purpose of an IDE has traditionally been to maximize a developer's productivity

by providing tools and support such as:

a. a source code editor

b. a compiler and build automation tools

c. integration with other commonly-‐used services

d. debugging support

e. profiling support

Why Netbeans IDE? The NetBeans IDE is a free, open-‐source integrated

development environment written entirely in Java. It offers a range of tools for

create professional desktop, enterprise, web, and mobile applications with the

Java language, C/C++, and even scripting languages such as PHP, JavaScript,

Groovy, and Ruby. The IDE provides many features for web development, and

several advantages over other IDEs. Here are several noteworthy points:

a. Free and Open Source: When you use the NetBeans IDE, you join a

vibrant, open source community with thousands of users ready to help and

contribute.

b. Profiling and Debugging Tools: With NetBeans IDE profiler, you get real

time insight into memory usage and potential performance bottlenecks.

The HeapWalker tool helps you evaluate Java heap contents and find

memory leaks.

c. Customizable Projects: Through the NetBeans IDE build process, which

relies on industry standards such as Apache Ant, make, Maven, and rake -‐

rather than a proprietary build process -‐ you can easily customize projects



and add functionality. You can build, run, and deploy projects to servers

outside of the IDE.

d. Collaboration Tools: The IDE provides built-‐in support for version control

systems such as CVS, Subversion, and Mercurial.

6.2. Glassfish Server

GlassFish is an open-‐source application server project started by Sun

Microsystems for the Java EE platform. GlassFish is based on source code released

by Sun and Oracle Corporation's TopLink persistence system. It uses a derivative

of Apache Tomcat as the servlet container for serving Web content, with an added

component called Grizzly, which uses Java New I/O (NIO) for scalability and

speed.

6.3. Database: MySQL

The MySQL database server is the world’s most widely used open source database.

Its ingenious software architecture makes it extremely fast and easy to customize.

Extensive reuse of code within the software and a minimalistic approach to

produce functionally rich features has resulted in a database management system

unmatched in speed, compactness, stability and ease of deployment. The unique

separation of the core server from the table handler makes it possible to run

MySQL under strict transaction control or with ultrafast transaction less disk

access, whichever is most appropriate for the situation.

Why MySQL? The MySQL database has become the world’s most popular open

source database because of its consistent fast performance, high reliability and

ease of use. It’s used by individual Web developers as well as many of the world’s

largest and fastest-‐growing organizations to save time and money powering their

high-‐volume Web sites, business-‐critical systems and packaged software –

including industry leaders such as Yahoo!, Google, Nokia, YouTube, and.

Platforms and interfaces: MySQL works on many different system platforms,



including AIX, , FreeBSD, HP-‐UX, i5/OS, Linux, Mac OS X, Novell NetWare,

OpenBSD, Open Solaris, OS/2 Warp, QNX, IRIX, Solaris, Symbian, SunOS, SCO

OpenServer, SCO UnixWare, Sanos, Tru64 and Microsoft Windows.

6.5. Database Management: MySQL Workbench

MySQL Workbench is a visual database design tool that integrates SQL

development, administration, database design, creation and maintenance into a

single integrated development environment for the MySQL database system. First

to deliver Java EE 6 Web Profile and full Java EE 6 platform support. It is based on

GlassFish Server Open Source Edition, backed by a vibrant community. It has

certified interoperability with Oracle Fusion Middleware products. [23]

Benefits: It improves developer productivity, and provides better performance,

extensive runtime. It also enables feature-‐rich applications based on industry

standards. It also supports application clusters for high availability and scalability;

supports non-‐multicast clustering. Provides centralized administration, provisions

GlassFish Server to remote hosts. Also enables rapid, iterative development;

modular architecture reduces overhead

CHAPTER 7



7. Test Cases

7.1. Class Under Test: ShoppingCart

7.1.1. Test Case 1: “testAddItem”

Purpose: Verify if the user is able to add an item to a new cart instance.

Action Input Expected Output

Add item with product

parameter to the new

cart instance

Click on the “Add to Cart”

button on any product

irrespective of cart being

empty/non-‐empty.

Since this test case is

instantiating a new cart

instance, it should return

a non-‐empty (null) value

for getting

numberOfItems from the

cart instance.

7.1.2. Test Case 2: “testUpdate”

Purpose: Verify if the user is able to update the quantity of a product in a new cart

instance.


Add sample item for test

purposes




empty/non-‐empty.

Item is added to

cart

Update the quantity field In the “View Cart” Page, erase

the default value of quantity and

replace with the desired

quantity [1 for this test case]

numberOfItems()

should be equal

to 1.

Table 7.1. Test Case 1: “testAddItem”

Table 7.2. Test Case 2: “testUpdateItem”



7.1.3. Test Case 3: “testGetItems”

Purpose: Verify if the system is able to retrieve the items already added in a new

cart instance.



purposes




empty/non-‐empty.

-‐

Check that number of

items is not null

In the “View Cart” Page,

there should atleast be

one item in the cart.

numberOfItems() >= 1

Compare the getItems()

output before and after

adding the items

-‐ They shouldn’t be the

same

7.1.4. Test Case 4: “testGetNumberOfItems”

Purpose: Verify if the system is able to retrieve the number of items in a new cart

instance.


Attempt to retrieve the

number of items in an

empty cart

-‐ Null

Table 7.3. Test Case 3: “testGetItems”

Table 7.4. Test Case 4: “testGetNumberOfItems”



7.1.5. Test Case 5: “testGetSubtotal”

Purpose: Retrieve the sub total of a new cart instance.


Attempt to retrieve the

sub total of an empty cart

-‐ 0.0

7.1.6. Test Case 6: “testCalculateTotal”

Purpose: Calculation of the grand total of a new cart instance.


Attempt to calculate the

grand total of an empty

cart

-‐ 5 [Zero (for products) +

Five (Delivery

Surcharge)]

7.1.7. Test Case 7: “testGetTotal”

Purpose: Retreive the grand total of a new cart instance.


Attempt to retreive the

grand total of an empty

cart

-‐ 0.0

Table 7.5. Test Case 5: “testGetSubTotal”

Table 7.6. Test Case 6: “testCalculateTotal”

Table 7.7. Test Case 7: “testGetTotal”



7.1.8. Test Case 8: “testClear”

Purpose: Verify if the user is able to clear the cart of the items he/she has added.


Attempt to clear the cart of

its contents

Click on the

“Clear Cart”

button in the

“View Cart”

page.

Items are cleared from the cart

and getNumberOfItems returns 0

7.2. Class Under Test: ShoppingCartItem

7.2.1. Test Case 1: “testGetProduct”

Purpose: Verify if the system is able retrieve the product ID of a particular item in

a new cart instance.


Pass a null product

parameter and attempt

to get its product ID

-‐ Null

7.2.2. Test Case 2: “testGetQuantity”

Purpose: Verify if the system is able to retrieve the quantity of a particular item in

a new cart instance.



purposes




Item is added to cart and

numberOfItems = 1

Table 7.9. Test Case 9: “testGetProduct”

Table 7.8. Test Case 8: “testClear”



empty/non-‐empty.

Attempt to get quantity

of the item added

-‐ getQuantity returns 1

7.2.3. Test Case 3: “testSetQuantity”

Purpose: Verify if the system is able to set the quantity of a particular item in a

new cart instance.



purposes




empty/non-‐empty.


numberOfItems = 1

Attempt to set quantity

of the item added to five

(5)


7.2.4. Test Case 4: “testIncrementQuantity”

Purpose: Verify if the system is able to increment the quantity of a particular item

in a new cart instance.



purposes




empty/non-‐empty.


numberOfItems = 1

Retrieve the quantity of

the item


Table 7.10. Test Case 10: “testGetQuantity”

Table 7.11. Test Case 11: “testSetQuantity”



Increment the quantity of

the item by one (1)


7.2.5. Test Case 5: “testDecrementQuantity”

Purpose: Verify if the system is able to decrement the quantity of a particular item

in a new cart instance.



purposes




empty/non-‐empty.


numberOfItems = 1

Set the quantity of the

added item to 10

-‐ -‐

Retrieve the quantity of

the item


Decrement the quantity

of the item by one (1)


Table 7.12. Test Case 12: “testIncrementQuantity”

Table 7.13. Test Case 13: “testDecrementQuantity”

CHAPTER 8



8. Project TimeLine

8.1. Gantt Chart I

Figure 8.1. Prjoect Time Line for Development of Ethnique Store

Figure 8.2. Gantt Chart for Development of Ethnique Store I



8.2. Gantt Chart II

Figure 8.3. Gantt Chart for Development of Ethnique Store II

CHAPTER 9



9. Task Distribution

9.1. Work Breakdown Structure

9.2. Responsibility Matrix

Figure 9.1. Work Breakdown Structure for Development of Ethnique Store

Figure 9.2. Responsisbilty Matrix for Development of Ethnique Store

CHAPTER 10



10. Conclusion Design patterns at the application-‐functionality level like MVC (Model View

Controller) and Front Controller have proven to boost the measure for Software

Metrics proving it to be a worthwhile exercise to code applications using such

design patterns.

In this project, the non-‐pattern and the pattern version of the system have been

compared using appropriate metrics. The patterns that have been employed are:

Front Controller and Model View Controller. In case more than one-‐design patterns

are implemented in the same part of the e-‐commerce demonstration application

the results are cumulative. The gradual implementation of the patterns: Front

Controller and results in a continuous quality improvement for the servlets' code

and consequently for the maintainability and extensibility of the application.

Implementing these two patterns results in reduced complexity, response and

coupling between objects. It increases the cohesion, which results in reduction of

Lack of Cohesion in Methods.

The following results table shows us the differences in numbers measured in

Software Metrics between the base application and the design patterns-‐enabled

application:

Figure 10.1. Metrics Calculation Report for Ethinique Store



However, the decision whether a specific design pattern should be applied or not,

should be taken considering the goal of each pattern and the problems that it can

solve, rather than solely considering its effect on design metrics. In other words,

the effect of the application of design pattern on low level design properties is

worth exploring, but should not be the primary reason for applying or avoiding

them.

10.1. Percentage Change Analysis

10.1.1. LCOM % Change

-‐60.00%

-‐50.00%

-‐40.00%

-‐30.00%

-‐20.00%

-‐10.00%

0.00%

LCOM % Change -‐ Ethnique Store

LCOM % Change

-‐100.00%

-‐80.00%

-‐60.00%

-‐40.00%

-‐20.00%

0.00%

LCOM % Change -‐ Reference Paper

LCOM % Change

Figure 10.3. Metrics Graph -‐LCOM % Change -‐ Reference Paper

Figure 10.2. Metrics Graph -‐ LCOM % Change -‐ Ethnique Store



10.1.2. CBO % Change

-‐35.00%

-‐30.00%

-‐25.00%

-‐20.00%

-‐15.00%

-‐10.00%

-‐5.00%

0.00%

CBO % Change -‐ Ethnique Store

CBO % Change

-‐70.00% -‐60.00% -‐50.00% -‐40.00% -‐30.00% -‐20.00% -‐10.00% 0.00%

CBO % Change -‐ Reference Paper

CBO % Change

Figure 10.4. Metrics Graph -‐CBO % Change -‐ Ethnique Store

Figure 10.5. Metrics Graph -‐CBO % Change -‐ Reference Paper



10.1.3. RFC % Change

-‐60.00%

-‐50.00%

-‐40.00%

-‐30.00%

-‐20.00%

-‐10.00%

0.00%

RFC % Change -‐ Ethnique Store

RFC % Change

-‐80.00%

-‐70.00%

-‐60.00%

-‐50.00%

-‐40.00%

-‐30.00%

-‐20.00%

-‐10.00%

0.00%

RFC % Change -‐ Reference Paper

RFC % change

Figure 10.6. Metrics Graph -‐RFC % Change -‐ Ethnique Store

Figure 10.7. Metrics Graph -‐RFC % Change -‐ Reference Paper



10.1.4. WMC % Change

-‐80.00%

-‐70.00%

-‐60.00%

-‐50.00%

-‐40.00%

-‐30.00%

-‐20.00%

-‐10.00%

0.00%

WMC % Change -‐ Ethnique Store

WMC % Change

-‐90.00%

-‐80.00%

-‐70.00%

-‐60.00%

-‐50.00%

-‐40.00%

-‐30.00%

-‐20.00%

-‐10.00%

0.00%

WMC % Change -‐ Reference Paper

WMC % change

Figure 10.8. Metrics Graph -‐WMC % Change -‐ Ethnique Store

Figure 10.9. Metrics Graph -‐WMC % Change -‐ Reference Paper



10.2. Future Scope

a. Integration with Payment Gateways like CCAvenue and BillDesk, along with seamless, site-‐wide PayPal Support.

b. Development of a sophisticated, easy-‐to-‐use Content Management System (CMS) for controlling Products, Categories, Customers and efficiently

processing customer Purchase Orders. c. Deploying the application on a Remote Enterprise Server with 99.99%

Uptime SLA for maximum availability of the web application. d. Addition of User Accounts, Wish Lists and Product Review features to the

application. e. Improving security standards to the application by applying for a SSL

Certificate from a reputed security agency like Thawte over the Internet.

CHAPTER 11



11. References

Authored book:

[1] S. R. Chidamber, and C. F. Kemerer, A metrics suite for object oriented

design, IEEE Transactions on Software Engineering, vol. 20. No. 6. pp. 476-‐

493, 1994.

[2] The Effects of Design Patterns application on metric scores, Brian Huston,

Systems Enginnering faculty, Southampton Institute , East Park Terrace,

Southampton, UK, 2000.

[3] The effect of software design patterns on,object-‐oriented software quality

and maintainability a thesis submitted to The Graduate School of Natural

and Applied Sciences of Middle East Technical University by Tuna Türk.

[4] Applied Java™ Patterns , Stephen Stelting ,Olav Maassen. Publisher:

Prentice Hall PTR

[5] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements

of Reusable Object-‐Oriented Software. Upper Saddle River, NJ: Addison-‐

Wesley, 1995

[6] R. Johnson, Expert One-‐on-‐One J2EE Design and Development.

Indianapolis, IN: Wiley Publishing, 2002.

[7] Joel Murach and Andrea Steelman , Murach’s Java Servlets and JSP, 2nd

Edition.

[8] J. Bansiya, and C. G. Davis, A hierarchical model for object-‐oriented design

quality assessment, IEEE Transactions on Software Engineering, vol. 28, no.

1, pp. 4-‐17, 2002.

Article in an edited book:

[9] E. Jendrock, J. Ball, D. Carson, I. Evans, S. Fordin, and K. Haase, The Java EE 5

Tutorial. Santa Clara, CA: Sun Microsystems Press, 2008



[10] M. Lorenz, and J. Kidd, Object-‐Oriented Software Metrics. Upper Saddle

River, NJ: Prentice Hall, 1994.

Paper in a journal:

[11] Use Case Based Innovative Design of E-‐commerce Website by Rongrong

Gong, Shijian Luo, Ji He

[12] Relationship between design patterns defects and crosscutting concern

scattering degree: an empirical study by L. Aversano, L. Cerulo & M. Di

Penta

[13] Improving a Web Application Using Design Patterns: A Case Study by

Phek Lan Thung, Chu Jian Ng, Swee Jing Thung & Shahida Sulaiman

[14] An Assessment of Design Patterns' Influence on a Java-‐based E-‐Commerce

Application by Maria Mouratidou, Vassilios Lourdas, Alexander

Chatzigeorgiou & Christos K. Georgiadis

[15] Building E-‐Commerce Applications from Object-‐Oriented Conceptual

Models by Oscar Pastor, Silvia Abrahão & Joan Fons

Paper in a conference record:

[16] Chang, C. Lu, W. C. Chu, N. Hsueh, and C. Koong, A case study of pattern-‐

based software framework to improve the quality of software

development, in Proceedings of the ACM Symposium on Applied

Computing, Honolulu, Hawaii, 2009, pp. 443-‐447

[17] S. He, Function point metrics improvement and application in e-‐

commerce, in IFIP Volume 254, Research and Practical Issues of

Enterprise Information Systems II, vol. 1 (Xu, Tjoa, Chaudhry, and Sohail,

Eds.), TC 8 WG 8.9 International Conference on Research and Practical



Issues of Enterprise Information Systems, China, Springer, pp. 395-‐398,

2007.

[18] M. Jiang, L. Li, M. Hu, and Y. Ding, Design and model analysis of the e-‐

commerce development platform for 3-‐ tiered web application, in

Proceedings of the International Conference on Advanced Language

Processing and Web Information Technology (ALPIT), 2008, pp. 581-‐584.

[19] M. Kim, V. Sazawal, D. Notkin, and G. C. Murphy, An empirical study of

code clone genealogies, in Proceedings 10th European Software

Engineering Conference & the 13th Foundations of Software Engineering,

2005, pp. 187-‐196.

[20] M. Salehie, S. Li, and L. Tahvildari, A metric-‐based heuristic framework to

detect object-‐oriented design flaws, in Proceedings 14th IEEE

International Conference on Program Comprehension, 2006. pp. 159-‐168.

[21] J. M. Bieman, G. Straw, H. Wang, P. W. Munger, and R. T. Alexander, Design

patterns and change proneness: An examination of five evolving systems,

in Proceedings 9th International Software Metrics Symposium, IEEE

Computer Society Press, Sydney, Australia, Sep. 2003, pp. 40−49.

Technical report:

[22] H. Freitag, "Design methodologies for LSI circuitry," IBM Tech. Rep.

TR41736, pp. 80-‐82, 1983.

[23] D. C. Rajapakse, and S. Jarzabek, Using server pages to unify clones in web

Applications: A trade-‐off analysis, in Proceedings 29th International

Conference on Software Engineering, IEEE Computer Society Press, 2007,

pp. 116-‐126.



Website:

[24] http://www.ieee.org/publications_standards/publications/proceedings

/proc_classic_papers.html

[25] http://www.designofsites.com/advanced-‐e-‐commerce/cross-‐selling-‐

and-‐up-‐ selling

[26] http://ist.berkeley.edu/as-‐ag/pub/pdf/mvc-‐seminar.pdf

[27] http://msdn.microsoft.com/en-‐us/library/ff649643.aspx

[28] http://guides.library.ucsc.edu/write-‐a-‐literature-‐review

Quantitative Analysis of Design Patterns on an Object-‐Oriented Web Application

Abha Molri, Abishay Rao, Rinckle Gohil, Rohith Rao Information Technology Department,

MCT’s Rajiv Gandhi Institute of Technology, Mumbai. E-‐mail: {abha.molri, rao.abishay, rinckle.gohil, rohithrrao}@gmail.com

Under the guidance of Asst. Prof. A. E. Patil, Information Technology Department,

MCT’s Rajiv Gandhi Institute of Technology, Mumbai. E-‐mail: [email protected]

1

ABSTRACT This paper involves the study of the effect of well established object-oriented and GUI design patterns on a web application developed using the Java EE Platform. In the proposed process, a web application is completely specified using object-oriented conceptual modeling techniques to capture properly the specific functionality of an e-commerce application. Once the application is developed, design patterns, such as Model View Controller, Front Controller, Easy Undo and Cross-selling & Up-selling are applied to the base e-commerce application. Then, the first goal is to measure the improvement of design properties after the implementation of each design pattern using software metrics. The second goal is to evaluate the improvements in User Experience. Keywords Software Engineering, e-Commerce Application, Java Enterprise Edition, Design Patterns, Object-Oriented, MVC, Easy Undo, Software Metrics, Cross-selling, Up-selling. 1. INTRODUCTION The Java Enterprise Edition (Java EE) platform provides the base for the development, deployment and execution of applications in a distributed environment. It is ideal for the easy development of complex projects of large scale, such as an e-commerce application. As the modern e-commerce applications become very complex, the need for lower maintenance costs and reusability increases. One solution is to develop the application in such a way, that it will be easy for someone to extend and further develop it. The design patterns provide a solution to this problem and are applicable in object-oriented programming languages, such as Java.

2

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmers must implement themselves in the application. This paper describes the implementation of specific design patterns (Front Controller, Model View Controller, Easy Undo and Cross-selling & Up-selling) in a typical e-commerce application, such as the electronic boutique. Moreover, we present the software metrics that will be used to study the resulting benefits after the implementation of each pattern. The benefits can be described as quantities by “measuring” the improvement in quality of source code after the several aspects of implementation of each pattern. The quality of code is evaluated by appropriate metrics and the differences in quality are measured by comparing the alterations of these specific metrics’ values. 2. DESIGN PATTERNS In order to achieve Design Principles, we will implement two specific object-oriented design patterns and two graphical user-interface design patterns. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. GUI patterns enhance the level of interaction between the user and the application. 2.1 MODEL VIEW CONTROLLER Model–View–Controller (MVC) is an object-oriented system design pattern that separates the representation of information from the user's interaction with it. It enforces the separation

APPENDIX

3

between the input, processing, and output of an application.[4] Under this approach, an application is divided into three core components: the model, the view, and the controller. Each of these components handles a discrete set of tasks. 2.1.1. View The view is the interfaces and classes the user sees and interacts with. For Web applications, this is usually an HTML or PHP interface. But new view options are rapidly appearing which include Macromedia Flash and alternate markup languages like XHTML, XML/XSL. A view must be registered with the model to be notified of changes to the model data. When a notification of such a change is received, the view component is responsible for determining if and how to represent this change. 2.1.2. Model The model represents enterprise data and business rules. Model includes databases and component objects like EJB and ColdFusion Components. The data returned by the model is display-neutral, meaning that the model doesn’t apply any formatting. This way, a single model can provide data for any number of display interfaces. This reduces code duplication, because model code is only written once and is then reused by all of the views. This component contains one or more classes and interfaces that are responsible for maintaining the data model. [8] To be able to notify view components of any change in the model, the model keeps a reference to each registered view. When a change occurs, every view component that has registered should be notified. 2.1.3. Controller The controller manages changes to the model. It interprets requests from the user and sends

4

commands to its associated view to change the view's presentation of the model. It takes the request and determines which model components to invoke and which formatting to apply to the resulting data. It can send commands to the model to update the model's state (e.g., editing a document). It keeps a reference to the model component, which is responsible for carrying out the change, whereas the controller calls one or more update methods.[3] The requests for change may also come from a view component. 2.2. FRONT CONTROLLER The Front Controller Pattern is a software design pattern, which provides a “centralized entry point for handling requests” in web applications. [6] They are often used in web applications to implement workflows. The front controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies. 2.2.1. Controller The controller is the initial contact point for handling all requests in the system. The controller may delegate to a helper to complete authentication and authorization of a user or to initiate contact retrieval. 2.2.2. Dispatcher A dispatcher is responsible for view management and navigation, managing the choice of the next view to present to the user, and providing the mechanism for vectoring control to this resource.[6] It can be encapsulated within a controller or can be a separate component working in coordination. The dispatcher provides either a static dispatching to the view or a more sophisticated dynamic dispatching mechanism.

Figure 1. Structure of Model View Controller

5

2.2.3. Helper A helper is responsible for helping a view or controller complete its processing. Thus, helpers have numerous responsibilities, including gathering data required by the view and storing this intermediate model. 2.2.4. View A view represents and displays information to the client. The view retrieves information from a model. Helpers support views by encapsulating and adapting the underlying data model for use in the display. 2.3. GUI DESIGN PATTERNS 2.3.1. Easy Undo The user can be provided with Undo facilities avoiding him to use navigation facilities for the purpose of editing some information.[7] It provides safe undoing capabilities in a complex process. Provide safe undoing capabilities in a complex process. This pattern extends the idea of backtracking typical in Web applications adapting it to the application’s semantics. Instead of returning to the last Web page (using the Back button), we return to the corresponding state to undo the operation. It uses a backtrack-forward algorithm that changes the usual browsing semantics adapting it to the needs of the store. It is important to stress that this difference is specific to this domain as the Web is based on a simple hypertext paradigm with a general backtrack functionality. This strategy has many variants due to the inherent conversational nature of interaction in e- commerce. The record of a particular customer activity (the “memory” of a vendor-client conversation, or “state” of such interaction) is a key component to implement the solution. Such “state” can be either Centralized or Client-Side according to the developer’s decision on the particular location of the information.[10] Once the information about the user activity is recovered, the actual implementation is reduced to the simple problem of establishing the right transition to the particular instant. Finally, there are several possibilities for the implementation of the necessary logic. It may reside as a script of a DHTML page sent to the client. Another possibility is through a server side code (as an ASP, JSSP, JSP, Perl and other scripting language program.

6

2.3.2. Cross Selling & Up Selling Cross selling is a strategy of selling other products to a customer who has already purchased (or signaled their intention to purchase) a product from the vendor.[10] Up-selling is a strategy which makes the customer purchase more expensive items, upgrades and other add-ons in an attempt to make more profitable sale. Cross-sell and upsell programs offer opportunities for marketers to increase revenue at a relatively small cost. Regardless of industry or channel, customer acquisition costs money, anywhere from pennies for simple search-engine marketing (SEM) or banner campaigns, to hundreds of pounds for sophisticated multichannel efforts. In contrast, cross-sell and upsell programs can be run at a fraction of those costs because they do not require the expense of sifting good prospects from a bunch of hand-raisers. Cross-sell and upsell programs involve a cherry-picked audience--people who have already bought something from a marketer. [8] It uses three different strategies: •Advantage of available data is taken: Data from

different channels and back-office systems are blended. It is a predictive model, which identifies new trends, and customer needs. For example, an offer for a Blu-ray player is sent to a customer who bought a TV. •Appropriate resources are deployed: Data

analysts or appropriate technology is used to both analyze the data and link the insight with cross-sell and up-sell opportunities that fit. For example, a transactional email solution can be tied into data warehouse to pull in relevant data and use it to identify the best cross-sell and up-sell targets. •Consider when and where to reach out: To

strategically find about when and where cross-sell and up-sell offers will be made. Identify best position on the screen. For example, to tag offer onto a transactional message, such as purchase confirmation or shipping notification, to take advantage of the closer attention that customers usually give to such communications.

3. SOFTWARE METRICS The goal of software metric is to measure the essential parameters that affect software development. Recent results indicate that the conscientious implementation and application of a software metrics program can help achieve better management results, both in the short run (for a given project) and in the long run (improving productivity on future projects).[1]

7

We will use the basic process model of input - process - output to discuss software entities. Software entities of the input type include all of the resources used for software research, development, and production. Software entities of the process type include software-related activities and events and are usually associated with a time factor. Software entities of the output type are the products of the software process.[5] The metrics that are used to evaluate how easily the source code can be maintained and extended before and after the implementation of each design pattern are: 3.1. Coupling Between Objects [CbO] Definition: CBO for class C stands for the number of other classes that C is coupled. A class is coupled to another if one uses other’s methods; attributes or one is inherited from the other. Interpretation: There are two types of coupling, internal and external. Internal coupling of a class C (fan-out of C) stands for how much C uses other classes’ services. On the other hand external coupling of C (fan-in of C) show how much other classes use C’s services.[1] It is showed that internal coupling increases fault proneness of class. It is expected since a class highly coupled to other classes will be unaware of the changes done to other classes and this may cause the class to function wrongly or errors to be carried to the class. However, external coupling does not increase fault proneness of the class itself since how much a class is used by others does not affect the class but external coupling means internal coupling for other classes and high external coupling increases overall coupling in software.[7] So both coupling types affect fault-proneness of software. CBO, containing both of these couplings, is a predictor of fault proneness therefore, maintainability. High CBO signals poor and complex design, decreases modularity and reuse, complicate testing of the class and as a result decreases understandability and testability.[7] So, CBO constitutes a measure for maintainability. 3.2. Weighted Methods per Class [WMC] Definition: Given a class C, WMC(C) =c1+c2+...+cn, where ci is the complexity of Mi which is a method of C and i is from 0 to n, n being number of methods of C.[9]

8

In, the method to calculate complexity of the methods is left to the concept in use. It is very common to choose it as the McCabe’s Cyclomatic Complexity (CC). CC is defined as the maximum number of linearly independent execution paths in a program . It is calculated as cyclomatic number of a program control graph; where cyclomatic number of a graph G is defined as V(G)= e-n+2p; where e is the number of edges, n is the number of nodes and p is the connected components in G.[2] To obtain the control graph of a program e is calculated as the number of branches, n is taken as the number of code blocks and p as connected program segments. Interpretation: Complexity is an indicator of the effort used for developing and to understand a code segment. Complexity is a good indicator of fault prone software. Fault prone software is not stable. WMC is the OO version of the complexity. High values of this metric mean a class with many complex methods.[12] Therefore, this metric can be chosen to be an indicator of maintainability since it affects fault proneness, stability and understandability. WMC is usually correlated with the effort needed to test that class. Since testability being a sub-character of maintainability, we can conclude that as WMC of a class increases maintainability of that class decreases. 3.3. Lack of Cohesion in Methods [LCOM] Definition: The number of common instance variables they use gives degree of similarity of two methods M1 and M2 of Ci.[1] Let P be the set of pairs of methods with degree of similarity zero and Q be the set of pairs of methods in C with degree of similarity being positive. Then LCOM of C is defined as: LCOM = |P| -|Q| ; if |P|> |Q| = 0 ; Otherwise Interpretation: LCOM for a class being positive means methods of that class form disjoint sets of methods that are working on disjoint sets of attributes. Then this means as the LCOM increases number of uncorrelated services in the class increases.[5] As an OO principle this type of classes should be divided according to the independent jobs they contain. Kemerer et. al. proposed that high values of LCOM signal complexity and therefore, error proneness. However, Briend et. al. experimented that LCOM has no significant effect on error-proneness. Case

9

studies showed different results; in one LCOM values increased with testability metrics whereas in the other decreased.[12] It can be concluded that LCOM is uncorrelated with the maintainability of the software under these discussions. It is included in the metric suite to experimentally evaluate its level of meaningfulness. 3.4. Response For Class [RFC] Definition: RFC of a class C is the cardinality of the set of methods that belong to C or is invoked by methods of C.[3] Interpretation: RFC is another measure of internal coupling since it contains the number of methods that the class is coupled to. Internal coupling is found to be the strong indicator of the class fault proneness. According to Chidamber and Kemerer , RFC indicates the complexity of a class and gives a measure of testing time. The statement is supported by experimental data since when a class is needed to be (unit) tested; tester has to cope with the initialization of the instances of classes whose methods are invoked by the class. To conclude, RFC affects the understandability, fault proneness and testability against maintainability. Therefore, as RFC increases, maintainability decreases.

10

4. CONCLUSION Design patterns at the application-functionality level like MVC (Model View Controller) and Front Controller have proven to boost the measure for Software Metrics proving it to be a worthwhile exercise to code applications using such design patterns.[11] Design patterns have proven to be both useful and harmful under circumstances of usage and programmers’ understanding of both the application and the design pattern.[9] Only time will tell if a standard set of patterns will be utilized to code applications in the future. Thus, software metrics provided a way to evaluate the credibility of the design patterns used. The following results table shows us the differences measured in Software Metrics between the base application and the design patterns-enabled application: Percentage change analysis of our application against the base application (reference paper).

Figure 2. Metrics Calculation Results for Ethnique Store Application

11

LCOM % Change

CBO % Change

12

RFC % Change

WMC % Change

13

5. REFERENCES [1] S. R. Chidamber, and C. F. Kemerer, A metrics

suite for object oriented design, IEEE Transactions on Software Engineering, vol. 20, no. 6, pp. 476-‐493, 1994.

[2] The Effects of Design Patterns application on

metric scores, Brian Huston, Systems Enginnering faculty, Southampton Institute , East Park Terrace, Southampton, UK, 2000.

[3] The effect of software design patterns

on,object-‐oriented software quality and maintainability, by Tuna Türk.

[4] Applied Java™ Patterns , Stephen Stelting

,Olav Maassen-‐ Publisher: Prentice Hall PTR [5] Object Oriented Static and Dynamic Software

Metrics For Design and Complexity, Varun Gupta , National Institute of Technology , kurukshetra, India, 2010.

[6] D. Alur, J. Crupi, and D. Malks, Core J2EE

Patterns: Best Practices and Design Strategies (2nd Edition). Santa Clara, CA: Prentice Hall / Sun Microsystems, 2003.

[7] J. Bansiya, and C. G. Davis, A hierarchical

model for object-‐oriented design quality assessment, IEEE Transactions on Software Engineering, vol. 28, no. 1, pp. 4-‐17, 2002.

[8] J. M. Bieman, G. Straw, H. Wang, P. W.

Munger, and R. T. Alexander, Design patterns and change proneness.

[9] An examination of five evolving systems, in

Proceedings 9th International Software Metrics Symposium, IEEE Computer Society Press, Sydney, Australia, Sep. 2003, pp. 40−49.

[10]Q. Chen, J. Yao, and R. Xing, Middleware

cmponents for e-‐commerce infrastructure: A analytical review, Issues in Informing Scence & Information Technology, vol. 3, pp. 137-‐146, 2006.

[11]W. Crawford and J. Kaplan, J2EE Design

Patterns. Sebastopol, CA: O'Reilly Media, 2003.

[12]M. Lorenz, and J. Kidd, Object-‐Oriented

Software Metrics. Upper Saddle River, NJ: Prentice Hall, 1994.

14

quantitative analysis of design patterns on an object oriented web application

Documents