an empirical assessment of refactoring impact on software quality using a hierarchical quality

International Journal of Software Engineering and Its Applications

Vol. 5 No. 4, October, 2011

127

An Empirical Assessment of Refactoring Impact on Software Quality

Using a Hierarchical Quality Model

Raed Shatnawi1, Wei Li

2

Software Engineering Department, Jordan University of Science & Technology,

Irbid, Jordan 22110

Computer Science Department, University of Alabama in Huntsville,

AL 35899, USA,

[email protected], [email protected]

Abstract

Software refactoring is a collection of reengineering activities that aims to improve

software quality. Refactorings are commonly used in agile software processes to improve

software quality after a significant software development or evolution. There is belief that

refactoring improves quality factors such as understandability, flexibility, and reusability.

However, there is limited empirical evidence to support such assumptions. The aim of this

study is to confirm such claims using a hierarchal quality model. We study the effect of

software refactoring on software quality. We provide details of our findings as heuristics that

can help software developers make more informed decisions about what refactorings to

perform in regard to improve a particular quality factor. We validate the proposed heuristics

in an empirical setting on two open-source systems. We found that the majority of refactoring

heuristics do improve quality; however some heuristics do not have a positive impact on all

software quality factors. In addition, we found that the impact analysis of refactorings

divides software measures into two categories: high and low impacted measures. These

categories help in the endeavor to know the best measures that can be used to identify

refactoring candidates. We validated our findings on two open-source systems—Eclipse and

Struts. For both systems, we found consistency between the heuristics and the actual

refactorings.

Keywords: Refactoring, design measures, quality factors, QMOOD.

1. Introduction

A particular refactoring is a sequence of code changes that improves the quality of design

without changing the behavior of software [1]. Software refactoring is commonly used in

agile software processes to improve software quality [2]; it is used for continuous

improvement of the structure and the understandability of software artifacts during

development [3]. The purpose of these changes is to transform a program structure into a

better quality after fixing quality defects such as bad smells, anti-patterns, flaws, pitfalls,

anomalies, ill-nesses [4]. This kind of transformations reduces the cost and effort of software

maintainability for the long run by keeping software complexity within acceptable levels [5].

Refactoring has been used in practice to improve software quality for commercial and open-

source software systems. For example, Microsoft reserves 20% of the development effort on

code rewriting [6]. Lucent had redesigned systems with design patterns and refactored the



128

code to match a proposed design [7]. In an open-source system example, Mozilla’s code was

refactored in the beta phase [8]. The refactorings logged in ArgoUML code repository were

studied by [9], and found that after refactoring only few bugs were reported and few mails

have been written. Murphy et al. reported observations on interactions of 41 Eclipse

developers at several iterations of open-source development, they found evidence of using 11

kinds of refactoring operations available in Eclipse IDE and they found that move method

was the most used refactoring [10]. In amore recent study, Bowdidge reported experience

report on adding refactoring to Apple’s Xcode IDE for programs built in Objective-C [11].

The objective was to add a refactoring tool that can refactor 200,000 line programs

interactively and within acceptable timeframe. Software refactoring follows a systematic

process both in agile and non-agile development processes. Mens and Tourwé described

refactoring as a process that consists of many activities [12]: first, identify refactoring

candidates (i.e., where the software should be refactored); second, determine which

refactoring(s) to apply; third, guarantee that refactoring preserve behavior; fourth, assess the

effect of the refactoring on software product quality characteristics (e.g., complexity,

understandability, and maintainability) or software process (e.g., productivity, cost, and

effort). Many research studies have been conducted to find the classes that are in need of

refactoring. Zhao and Hayes used static measures to predict refactoring candidates [13].

Another common approach to detect where to refactor is the identification of bad smells [1]

[14] [15]. Simon et al. proposed a metric-based approach [16], while Kataoka et al. used

program invariants to indicate where refactorings might be applicable [17]. Fowler provided

a catalogue of refactoring and proposed when to use them to fix code smells [1]. To preserve

refactoring behavior, some studies used automatic code transformation [18]. In industry,

there are many development tools that can be used to automate software refactoring for many

OO languages and development environments, for example, Eclipse1, Together

ControlCenter2 and others. Although many software development environments include

refactoring tools, there are few comprehensive studies that assess the effect of a large number

of refactoring mechanics on software quality. In addition, there are few previous works that

provide a set of refactoring heuristics that can be used to detect refactorings and can work as

guidelines for developers when refactoring. Software developers have to refactor and then

validate the effect of their refactoring on software quality using other criteria such as

collecting metrics data, which is a time-consuming activity. In this paper, we aim to identify

refactoring heuristics that establish the relationship between software refactoring and software

quality. The objectives of this work are threefold:

1. To assess the effect of refactoring activities on both the internal and external quality

characteristics using a quality model. Quality models are tools that are used for the

quality assessment. A quality model defines a set of quality characteristics and the

relationships between them, which provide the basis for specifying quality requirements

and evaluating quality [19]. In this work, wehave adapted a hierarchal Quality Model for

Object-Oriented Design (QMOOD) that relates between internal and external quality

characteristics [20].

2. To establish refactoring heuristics3 that can help developers in making decisions whether

refactorings improve software quality characteristics or not.

1 www.eclipse.org 2 www.borland.com 3 Refactoring heuristics are experience-based refactorings that are used to reduce the need for calculations pertaining to software size or a tool performance.



129

3. To validate that refactoring heuristics are consistent with refactorings in real context,

open-source community.

The result of using a quality model is a list of refactoring heuristics that relates

refactoring to software quality. These heuristics inform developers whether to carry out

prescribed refactorings to improve the software quality or to search for other alternatives to

improve quality. In the remainder of this paper, we provide more details on the related work

in Section 2; the quality model (i.e., QMOOD) is described in Section 3; the research

methodology in Section 4, which elaborates on software measures and software refactorings.

In Section 5, we discuss the results and analyze the effect of refactoring heuristics on metrics

and quality factors. In Section 6, we empirically validate our findings on two real case

studies. Finally, we conclude our work and discuss the limitations and future work.

2. Related Work

Software refactoring improves core object-oriented (OO) design internal properties such

as encapsulation, abstraction, message passing, inheritance, and polymorphism [1] [2]. These

properties can be quantified by software measures as Bansiya and Davis have suggested in

[20]. The general belief is that improving these design properties leads to improvements on

external quality factors such as understandability, reusability, efficiency, usability and

functionality [21]. In addition, refactoring activities can be classified according to quality

factors that can be achieved through particular refactorings [22]. Such a classification allows

developers to selectively improve software quality. In most literature of software refactoring,

it is assumed that refactoring improves software quality to some extent. For example,

refactoring makes software design easier to modify [1], easy to extend and maintain [23], and

easy to reuse [24]. However, there is limited empirical evidence of such assumptions. In this

section we summarize many empirical studies that were conducted to find the impact of

refactorings on the quality of software systems. Sahraoui et al. used software measures for

detecting situations where a particular refactoring can be applied to improve the quality of a

software system [25]. They derived empirically a set of rules on coupling and inheritance

measures that can be used to select the best refactorings to improve software maintainability.

In an academic study with a group of students, Stroulia and Kapoor found that refactoring

decreases the size and coupling measures which they believe to increase the extendibility of

the software [26]. Demeyer found, in an empirical context, that program performance

improved after refactoring (e.g., replacing conditional logic by polymorphism) [27]. Kataoka

et al. used coupling measures in evaluating the effect of refactoring on maintainability of a

program and found that refactoring enhanced system maintainability [28]. Kataoka et al.

validated these results on a C++ program for two refactoring activities: Extract Method and

Extract Class. Bois and Mens have proposed a formalism framework [29], derived using

Abstract Syntax Tree notations borrowed from Mens et al. [30], for analyzing the impact of

software refactorings on internal measures describing the impact of refactorings on program

structure. They validated the proposed framework on a small demo program; the study

evaluated three refactorings only: Extract Method, Encapsulate Field, and Pull-up Method, on

many software measures (Number of Methods, Number of Children, Coupling, Response for

a Class, and Cohesion). The results in Bois and Mens’ work showed positive and negative

impacts on the studied measures. Leitch and Stroulia studied the effect of software

refactoring on software maintenance effort and costs using dependency graphs [31]. They

conducted their study on two systems to discover refactoring opportunities through detecting

bad smells. They provided a refactoring plan, which used two small refactorings, Extract

Method and Move Method, for most of the refactorings. Their study found that refactoring



130

improved quality by reducing the size of code, increasing the number of procedures, reducing

the density of dependencies, and reducing regression testing. Tahvildari proposed a quality

framework for software re-engineering process that connects required software qualities with

program transformations to improve the intended qualities [32]. The framework considers

transforming programs to improve quality requirements, such as performance, and

maintainability, during the re-engineering process. They assessed the re-engineering

framework on two case studies (two different legacy systems written in C and migrated to

C++) and the results show that the use of design patterns produced a more maintainable and

higher performance system than the legacy system [33]. In another study, Tahvildari and

Kontogiannis used the same framework to evaluate the impact of six transformations on many

OO measures (coupling, cohesion, inheritance and complexity) [34]. The resulting impact is

used to guide the reengineering process to achieve a particular quality factor (maintainability)

in four open-source applications. Bois et al. proposed guidelines for enhancing cohesion and

coupling measures and obtained promising results by applying them in refactoring a open-

source software system—Apache Tomcat [35]. There were five refactorings under study:

Extract Method, Move Method, Replace Method with Method Object, Replace Data Value

with Object, and Extract Class. Bois et al. have provided a set of guidelines that serves

software maintainers in their endeavor to optimize software quality and ruled out those

refactorings of which the resolution will not lead to improve coupling or cohesion measures.

This study has shown that the effect of refactoring on coupling and cohesion measures ranged

from negative to positive. Ratzinger et al. showed that refactoring enhanced software

evolvability, i.e. reduced the change coupling [36]. They used the change history from

software repository to detect refactoring opportunities. After software refactoring, the

evolution of the system was more facilitated and did not lead to worse change couplings or

change smells. In another study, Moser used internal measures to assess the effect of

refactorings on reusability and found that refactoring enhanced reusability of hard-to-reuse

classes in an Agile process [37]. They conducted an empirical study on a commercial system

and used internal measures, cyclomatic complexity and the CK4 measures, as surrogates for

reusability. In a 2008 study, Moser and his colleagues found that refactoring not only

increased aspects of software quality, but also improved productivity [3]. To validate their

results, an empirical study was conducted on a commercial software system developed in Java

and the collected measures were LOC, CK4 measures, Effort (hour), and Productivity (LOC);

the study found that software refactoring reduces code complexity and coupling and increases

cohesion. Recently, a more comprehensive study was conducted by Alshayeb [38]; he

conducted his study to find the impact of eight refactorings on five quality factors:

adaptability, maintainability, understandability, reusability, and testability. The results in

Alsheyb’s work showed more negative relationships between the applied refactorings and the

software quality factors (adaptability, maintainability, understandability, reusability and

testability). Rech proposed a quality framework (defect diagnosis) that addresses the problem

of diagnosing and handling quality defects [4]. The application of the framework perceived

improvement of maintainability and productivity (finding defects). Most studies found a

positive relationship between software refactoring and the software quality, either indirectly

or directly measured. We summarize these studies in Table 1, which includes important

factors such as the studied systems, internal and external measures, the quality model (quality

index), and the validated refactorings. A quality index is a mathematical calculation of an

external quality factor from internal measures. From Table 1, we deduce that there are many

4 There are many empirical studies put the CK metrics into relationship with software quality, in particular with maintainability, reusability, and reliability.



131

challenges facing the researchers: 1) most studies evaluated one or two external quality

factors using internal measures without using a validated quality model; 2) most studies, that

are shown in Table 1, evaluated a small number of software refactorings or transformations

and that due to the massive effort needed to include more refactorings. To overcome these

challenges we conduct a study on a larger number of refactorings (43 refactorings) using a

quality model proposed by Bansiya and Davis [20] on four quality factors measured indirectly

using nine different software measures. The study is conducted on two large software

components: EclipseUI and Struts from Apache.

Table 1. A Summary of Related Work

Authors Case Study Internal

Measures

External

Measures

Quality

Model Refactorings

Sahraoui et al.

[25] A C++ program

Inheritance and coupling

measures

Fault-proneness No Extract Superclass, Extract

Subclasses, Extract

Aggregate Classes

Stroulia and

Kapoor [26] Academic

Size and

coupling

Design

extendibility No

Extract Superclass, Extract

abstract class

Demeyer [27] A small program - Performance No Replace Conditional with

Polymorphism

Kataoka et al.

[28] A C++ program Coupling Maintainability No

Extract Method and

Extract Class

Bois and Mens

[29]

A small demo

program

#Methods, CK

measures - No

Extract Method, Encapsulate Field, and

Pull-up Method,

Leitch and

Stroulia [31]

Academic and

commercial

Code size,

number of procedures

Maintenance

effort and costs No

Extract Method, and Move

Method

Tahvildari et

al. [33]

A project in

industrial

environment and open library; both

written in C.

Halstead's

efforts, LOC,

and number of Comment

lines per module

Maintainability

and performance

three software

maintainability

indexes and two performance

measures

Design patterns

Tahvildari and

Kontogiannis

[34]

Four open-source applications

coupling,

cohesion, inheritance and

complexity

Maintainability Metrics

interpretation Code Transformations

Bois et al. [25] open source

software

cohesion and

coupling - No

Extract Method, Move

Method, Replace Method w Method Object, Replace

Data Value w Object, and

Extract Class

Ratzinger et al. [36]

Open source system

Change coupling Evolvability No Change smells

Moser [37]

A project in

industrial environment

McCabe’s

cyclomatic

complexity, and CK measures

[39]

Reusability

metrics

interpretation

based on work of Dandashi and

Rine [40]

Not available

Moser et al.

[3]

A project in

industrial environment

LOC, CK

measures, Effort (hour),

Productivity

(LOC) No Not available

Alshayeb [38] Three small Open-

source projects CK measures, LOC, FOUT

adaptability, maintainability,

understandability,

reusability, and testability

metrics interpretation

based on work

of Dandashi and Rine [40].

Extract Class, Encapsulate

Field, Extract Subclass,

Move Class, Extract Method, Replace Temp

with Query, and Extract

Subclass



132

3. The Quality Model for Object-Oriented Design

To achieve the objectives of this research, we need a quality model that can be easily used

to evaluate and interpret system evolution when refactoring. To find the effect of refactoring

activities on software quality, the model must also measure both the internal and external

quality characteristics. Internal characteristics are used to measure software properties such

as information hiding, inheritance, and polymorphism. There are many quality models that

link between internal software properties and external quality factors. McCall and his

colleagues [40] defined a quality model as a hierarchy of factors, criteria, and measures. ISO

91265 [41] is a standard model that defines quality as a set of product characteristics at two

levels: internal and external. Squid a variant of the ISO 9126 model, but it depends on having

a past-experience database to establish a relationship between internal and external quality

characteristics [42]. Bansiya and Davis [20] proposed and validated a hierarchal Quality

Model for Object-Oriented Design (QMOOD) that relates between internal and external

quality characteristics. All these models are hierarchal and can be used to define measures

and the relationships between the internal and external quality characteristics. However they

differ at the low level of the hierarchy and the measure definition. QMOOD model can be

used at both the system and component levels and it is easy to assess, because it provides a

quantitative assessment of external quality factors from the measurements of the internal

design properties. QMOOD is a hierarchal quality model that is used to assess external

quality factors using design measures and can be applied to early stages (requirements and

design) to ensure that the product artifacts have favorable internal properties. This model

gives developers an opportunity to fix problems, remove irregularities and nonconformance to

standards, and eliminate unwanted complexity early in the development cycle [20]. QMOOD

assesses six external quality factors, eleven internal design properties, and OO design

components such as attributes, methods, classes, composition, and inheritance hierarchies.

We want to assess the effect of refactoring software components on four software quality

factors only. The definitions of the four quality factors are provided as follows:

Reusability: The degree to which a software module or other work product can be

used in more than one computer program or software system.

Flexibility: The ease with which a system or component can be modified for use in

applications or environments other than those for which it was specifically designed.

Extendibility: The ease with which a system or component can be modified to

increase its storage or functional capacity.

Effectiveness: The degree to which a design is able to achieve the desired

functionality and behavior using OO design concepts and techniques.

We have excluded the understandability factor because it is a subjective quality factor and

using a model of merely static measures to evaluate understandability is inadequate. In

addition, we have excluded the functionality factor because we assume that refactoring does

not change the behavior of systems, rather it changes the internal characteristics of systems

without changing functionality. The effect of refactorings on these quality factors cannot be

assessed directly. QMOOD links these factors to many design properties that are quantified

by software measures as shown in Table 2. Each quality factor is a function of many software

5 ISO 9126 is software product quality standard that was superseded by SQuaRE series of International Standards (ISO/IEC 25000) (ref]



133

properties (measures). Refactoring activities change the internal design of a software system;

therefore we expect refactoring to impact external quality factors consequently. For example,

the reusability is an index of four weighted properties: coupling, cohesion, messaging, and

design size. Consequently, changing these properties, because of refactoring, affect

reusability as well. Increasing class coupling decreases class reusability, whereas increasing

class cohesion, message passing among objects, or number of classes increase the reusability

of the system’s components.

Table 2. Quality indices of external quality factors as adapted from [20]

Quality Factors Quality Index Calculation

Reusability –0.25 * Coupling + 0.25 * Cohesion + 0.5 * Messaging + 0.5 * Design Size

Flexibility 0.25 * Encapsulation – 0.25 * Coupling + 0.5 * Composition + 0.5 *

Polymorphism

Extendibility 0.5 * Abstraction – 0.5 * Coupling + 0.5 * Inheritance + 0.5 * Polymorphism

Effectiveness 0.2 * Abstraction + 0.2 * Encapsulation + 0.2 * Composition + 0.2 *

Inheritance + 0.2 * Polymorphism

Bansiya and Davis have proposed and validated these indexes empirically. Proportional

weights were assigned to indicate the influence of the properties on a quality factor [20].

Bansiya and Davis conducted an empirical study to determine the weights and the model was

validated on the evolution of two real systems. The weights (+0.5, +1) were used initially if a

measure positively influences a quality attribute and the weights (-0.5, - 1) were used for

negative influences. These weights were changed to ensure that the sum of weighted values

added to +1; for example, the sums of weighted values of the properties used to measure

Reusability add to 1 [44]. An increase on a quality factor after maintenance indicates

improvement of quality; otherwise a decrease indicates quality deterioration. QMOOD was

selected for this work because it provides quality indexes that are easy to interpret using

software measures. QMOOD provides these measures and how to assess them. The

evolution of a particular quality can be measured by considering the differences between

measuring the two consecutive releases. For example the effect of evolution on Flexibility is

denoted ∆Flexibility. Figure 1 shows how the effect on flexibility can be evaluated. This

mathematical evaluation applies to all other quality factors. From this figure we can notice

that if we know the differences between measures, which result from refactorings, then we do

not need to calculate the measures from source code before and after refactoring. Therefore,

we can use refactoring heuristics to find the effect of refactoring on the evolution of software

quality.

There are many research studies that used QMOOD to assess software quality. For

example, O’Keeffe and O´Cinneide used QMOOD to evaluate alternative designs that can

produce a better quality [45]. In another study, Hsueh et al. used QMOOD to validate

whether a design pattern is well-designed [46], i.e., it answers the question whether a

proposed structural model really resolves the quality problems described in the intent of

design patterns. Furthermore, using QMOOD has many advantages: it can be used to

measure software artifacts at many phases; it evaluates many external quality factors such as

reusability, flexibility, extendibility and effectiveness; it provides an assessment of the quality



134

of the software artifact after evolution, which is consistent with the measurements of the

external quality factors mentioned above; it gives one measurement for each quality factor,

therefore making the comparison between before and after refactoring easy to assess. Finally,

QMOOD is insensitive to the design size (number of classes), because we compare

normalized system measurements.

Figure 1. The evolution of software flexibility

4. Research Methodology

In this section, we describe the methodology to evaluate refactorings under study. First,

we introduce software measures. Next, we introduce how refactorings affect measures.

4.1 Software Measures

QMOOD uses eleven OO measures to quantify system design properties. However nine

measures only are used to measure the four quality factors. In this section, we provide a

description of how we evaluate the effect of refactoring activities on these measures6.

Refactoring changes the structure of software such as classes, relationships among classes

(inheritance, compositions, dependencies), and the constituents of classes (attributes and

methods). These class changes cause changes in the system, which are indicators of quality

change. We use a quality assurance tool, ckjm7, to collect the following measures:

Design size (DSC): measures the number of classes in a system. This measure is simple

and the effect of refactoring on this measure is easy to assess. Many refactorings affect this

measure such as Extract Class, and Replace Method with Method Object. Such refactorings

increase the number of classes in a design, whereas Inline Class decreases this measure.

Abstraction (ANA): measures abstraction of a system. ANA is computed by determining

the average of the depth of the inheritance tree (DIT). DIT is the length of the inheritance

chain from the root of the inheritance tree to the measured class [39]. This measure is an

indicator of the number of ancestors of a class and provides insight to the generalization in the

inheritance hierarchy. A refactoring such as Extract Superclass increases abstraction.

Encapsulation (DAM): measures the average of the data encapsulation in a system.

Data access measure (DAM) is the ratio of the private attributes to the total number of

attributes in a class. Every class encapsulates data and operations. The main criterion for a

good class is to have as much data invisible to non-member methods as possible; otherwise

6 We omitted the definitions of inheritance hierarchies and design complexity measurements because they are not used to measure the four quality factors in Table 2. 7 http://www.spinellis.gr/sw/ckjm/doc/index.html/.

The evolution of flexibility is measured as ∆Flexibility = Flexibility2 – Flexibility1 This is equivalent to

∆Flexibility = (0.25 * Encapsulation2 – 0.25 * Coupling2 + 0.5 * Composition2 + 0.5 * Polymorphism2) – (0.25 * Encapsulation1 – 0.25 * Coupling1 + 0.5 * Composition1 + 0.5 * Polymorphism1)

By using the redistributive property we get

∆Flexibility = 0.25 * (Encapsulation2 – Encapsulation1) – 0.25 * (Coupling2 – Coupling1) + 0.5 * (Composition2 – Composition1) + 0.5 * (Polymorphism2 – Polymorphism1)



135

the encapsulation is compromised. Encapsulate Field increases the encapsulation

(information hiding), because it converts a public attribute into private.

Coupling (DCC): Direct class coupling (DCC) counts the number of classes that a class

is directly connected to. The couplings include classes that are related by attribute

declarations and message passing. This measure is an indicator of the need to other classes.

Large values of DCC measure means that the system is highly coupled. Refactoring high

coupled classes can improve quality. For example, Change Bidirectional Association to

Unidirectional reduces the coupling among classes. Thus, this refactoring decreases coupling

in the system.

Cohesion (CAM): Cohesion among methods of classes (CAM) computes the relatedness

(similarities) among methods of a class. The class that does one thing (i.e., cohesive) is easier

to reuse and maintain than the class that does many different things (i.e., the class provides

many different services). The low cohesive classes may need to be refactored. Refactoring

attributes and methods in a class affects cohesion. When assessing the mechanics of

refactoring, we use our subjective perception to evaluate the change on CAM. For example,

Move Field is a refactoring that is considered increasing the cohesiveness of a class because

the moved field does not belong to the refactored class, i.e., reduces dissimilarities among the

methods. In the validation case studies, we use the cohesion measure that was defined by

Henderson-Sellers [47]. Henderson-Sellers revised the LCOM measure [39] to normalize it

for the number of methods and attributes in the class.

Composition (MOA): Measure of aggregation (MOA) in the system is a count of the

number of data declarations that are user defined classes. MOA measures the extent of the

part-whole relationships (composition), realized by using attributes. Objects can encapsulate

data attributes as well as other objects. The refactoring activity, Replace Array with Object,

replaces data stored in an array into an object. This refactoring introduces a part-whole

relationship and therefore increases the use of composition.

Inheritance (MFA): Measure of functional abstraction (MFA) is the ratio of the number

of inherited methods by a class to the total number of local methods in the class. MFA

measures the utilization of inheritance in a design. When inheritance is used effectively the

number of inherited methods increases. Many empirical and theoretical studies have shown

that inheritance is not utilized well in object-oriented systems [48]. Refactoring can be used

to increase the reusability via inheritance. Increasing the number of inherited methods is a

sign of a functional abstraction. For example, the Form Template Method uses inheritance to

pull-up the identical methods into a superclass. This refactoring increases the functional

abstraction in a design.

Polymorphism (NOP): Number of polymorphic methods (NOP) is a count of

polymorphic methods in a class. NOP measure counts the number of polymorphic methods.

We use the number of children as a surrogate of NOP. The number of children represents the

number of specializations and uses of a class. Changing parent classes (superclasses) also

changes the polymorphism in the inheritance hierarchy. For example, Replace Conditional

with Polymorphism increases the utilization of polymorphism by creating appropriate

subclasses for each conditional statement.

Messaging (CIS): Class interface size (CIS) is a count of public methods in a class,

which is the size of the response set for the class. A class that has large number of

responsibilities tends to be large and has many interactions with other classes. Replace



136

Parameter with Method extracts the calculation of a parameter into a method; therefore

increases the interface size of the class.

4.2 Software Refactoring

Fowler has provided a catalogue of refactorings which includes 22 code smells and 72

possible refactoring activities. Fowler categorized these refactorings into: composing

methods, moving features between objects, organizing data, simplifying conditional

expressions, making method calls simpler, and dealing with generalizations [1[ . Software

developers use refactoring to fix code smells or other defects. We study the refactorings that

Fowler proposed to use to fix 22 code smells as listed in his catalogue. We found that only 43

refactorings are suggested to fixing the 22 code smells. Therefore, we have limited our

analysis to these refactoring activities. Brief descriptions of these refactoring activities are

listed in Appendix I. In Fowler's catalogue, each refactoring is described in a standard format

that characterizes refactoring throughout a rationale, a motivation, mechanics, and an

example. The rationale describes the situations that behind refactoring, i.e., when to refactor.

The motivation shows the benefits and costs of the refactoring. The mechanics illustrates the

refactoring in small steps. Applying refactoring mechanics make refactoring systematic and

can avoid the risk of introducing bugs into the code.

In our research, we evaluate the mechanics of each refactoring to produce refactoring

heuristics that can be used to make informed decisions when and how to refactor. These

heuristics are intended to be conceptually simple, potentially at the cost of accuracy or

precision. We documented the quantitative effect of each refactoring activity on design

properties as defined in QMOOD. To get indication of the effect of each refactoring activity

on the external quality factors, we need to assess the effect of refactoring mechanics on

design measures. For example Extract Class is a refactoring that is used to break a large

class, i.e., the class is doing a work of two or more classes and should be divided into more

classes. The Extract Class is usually used to fix the God Class (very large class). To measure

the effect of this refactoring on design measures, we follow the mechanics that are described

in Fowler's catalogue. The mechanics of Extract Class consist of the following steps: First,

decide how to split the class. Second, create the new class. Third, make a link between the

two classes. Fourth, move fields to the new class. And last, move methods to the new class.

This refactoring increases the number of classes. Since these two classes will be linked,

coupling between objects is increased (the DCC measure). Moving methods and fields to the

new class (the splitting process) increases the cohesion of both classes (CAM measure). This

refactoring is not intended to be used for inheritance hierarchy; therefore it has no effect on

the inheritance measures (ANA, MFA and NOP). The effects of this refactoring on software

measures are shown in Table 3. The Extract Class changes four measures. According to

QMOOD (Table 3), these changes improve three quality factors: Reusability, Flexibility, and

Effectiveness, and deteriorate one. Therefore, we generate refactoring heuristics that inform

developers about the effects of Extract Class.

In summary, the process of evaluating the mechanics of a particular refactoring consists

of three steps. First, we consider the mechanics of every refactoring as described in Fowler's

catalogue. Second, we evaluate the effect of the refactoring mechanics on design properties

and assess the changes in the relevant measures. We use + to denote an increase, - to denote a

decrease, or 0 to show no changes on measures. Third, we use the measure evolution to

evaluate the effect on the quality factors using QMOOD functions that are shown in Table 3.



137

Table 3. The heuristic resulting from the Extract Class

DSC ANA DAM DCC CAM MOA MFA NOP CIS

+ 0 0 + + + 0 0 0

This evaluation results in refactoring heuristics that can be used to make informed

decisions in software development process. We want to a show an evidence of the effect of

refactoring on software quality. To validate the consistency of the refactoring heuristics, we

want to test whether software refactorings do have a significant impact on software quality

attributes (reusability, flexibility, extendibility, and effectiveness). We conduct two case

studies to provide empirical evidence of the relationship between refactoring and software

quality.

5. Refactoring Analysis

In this section, we analyze the effect of software refactorings on measurements of the

internal design properties, and then we assess the effect of refactoring on the quality factors

that are defined by QMOOD.

5.1 Refactoring Impact Analysis

The evaluation of refactoring mechanics is conducted for the selected refactoring

activities to establish refactoring heuristics. The heuristics provide a list of refactorings that

make improvement on particular software quality factors and the ones that deteriorate

software quality. These heuristics are supposed to help developers in their endeavor to

improve quality without the time-consuming process of collecting measures. We present a

summary of refactoring effects in Table 4a through Table 4f. The refactorings that are used

in composing methods, Table 4a, affect the class interface and class coupling (three changes

for each). Refactorings that move features between objects, Table 4b, affect class coupling

and cohesion. Refactorings that organize data, Table 4c, affect many measures, but mostly

number of classes, coupling, composition, and class interface. Refactorings that simplify

conditional expressions, Table 4d, affect many measures but mostly class interface and class

complexity. Refactorings that make method calls simpler, Table 4e, have small effect on

many measures. Refactorings that deal with generalizations, Table 4f, affect many measures,

but mostly number of classes, abstraction, class interface, inheritance and polymorphism. In

summary, the most refactorings that have effect on software measures are the ones that

organize data (Table 4c) and deal with generalizations (Table 4f).

Table 4a. The effect of composing methods on software measures

Refactoring DSC ANA DAM DCC CAM MOA MFA NOP CIS

Extract Method 0 0 0 + - 0 0 0 +

Inline Method 0 0 0 - 0 0 0 0 -

Replace Temp with Query 0 0 0 0 0 0 0 0 +

Replace Method with

Method Object + 0 0 + 0 + 0 0 0

Substitute Algorithm 0 0 0 0 0 0 0 0 0

http://www.refactoring.com/catalog/extractMethod.html

http://www.refactoring.com/catalog/inlineMethod.html

http://www.refactoring.com/catalog/replaceTempWithQuery.html

http://www.refactoring.com/catalog/replaceMethodWithMethodObject.html


http://www.refactoring.com/catalog/substituteAlgorithm.html



138

Table 4b. The effect of moving features between objects on software measures


Move Method 0 0 0 - + 0 0 0 -

Move Field 0 0 0 0 + 0 0 0 0

Extract Class + 0 0 + + + 0 0 0

Inline Class - 0 0 - - - 0 0 0

Hide Delegate 0 0 0 - 0 0 0 0 0

Remove Middle

Man 0 0 0 + 0 0 0 0 0

Introduce Foreign

Method 0 0 0 + 0 0 0 0 +

Introduce Local

Extension + + 0 0 0 0 + + +

Table 4c. The effect of organizing data on software measures


Replace Data Value

with Object + 0 0 + 0 + 0 0 +

Replace Array with

Object + 0 + + + + 0 0 +

Duplicate Observed

Data + + 0 + 0 + + + +

Change Bidirectional

Association to

Unidirectional

0 0 0 - 0 0 0 0 0

Encapsulate Field 0 0 + 0 0 0 0 0 +

Encapsulate Collection 0 0 0 + 0 0 0 0 +

Replace Type Code

with Class + 0 0 + 0 + 0 0 +

Replace Type Code

with Subclasses + + 0 0 0 0 + + +

Replace Type Code

with State/Strategy + + 0 + 0 + + + +

Table 4d. The effect of simplifying conditional expressions on software measures


Decompose Conditional 0 0 0 0 0 0 0 0 +

Replace Conditional with

Polymorphism + + 0 0 0 0 + + +

Introduce Null Object + + 0 0 0 0 + + +

Introduce Assertion 0 0 0 0 0 0 0 0 0

http://www.refactoring.com/catalog/moveField.html

http://www.refactoring.com/catalog/extractClass.html

http://www.refactoring.com/catalog/inlineClass.html

http://www.refactoring.com/catalog/hideDelegate.html

http://www.refactoring.com/catalog/removeMiddleMan.html


http://www.refactoring.com/catalog/introduceForeignMethod.html


http://www.refactoring.com/catalog/introduceLocalExtension.html


http://www.refactoring.com/catalog/replaceDataValueWithObject.html

http://www.refactoring.com/catalog/replaceDataValueWithObject.html

http://www.refactoring.com/catalog/replaceArrayWithObject.html


http://www.refactoring.com/catalog/duplicateObservedData.html


http://www.refactoring.com/catalog/changeBidirectionalAssociationToUnidirectional.html



http://www.refactoring.com/catalog/encapsulateField.html

http://www.refactoring.com/catalog/encapsulateCollection.html

http://www.refactoring.com/catalog/replaceTypeCodeWithClass.html


http://www.refactoring.com/catalog/replaceTypeCodeWithSubclasses.html


http://www.refactoring.com/catalog/replaceTypeCodeWithStateStrategy.html


http://www.refactoring.com/catalog/decomposeConditional.html

http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html


http://www.refactoring.com/catalog/introduceNullObject.html

http://www.refactoring.com/catalog/introduceAssertion.html



139

Table 4e. The effect of making method calls simpler on software measures


Rename Method 0 0 0 0 0 0 0 0 0

Remove Parameter 0 0 0 0 0 0 0 0 0

Replace Parameter with

Explicit Methods 0 0 0 0 0 0 0 0 +

Preserve Whole Object 0 0 0 0 0 0 0 0 0

Replace Parameter with

Method 0 0 0 0 0 0 0 0 +

Introduce Parameter

Object + 0 0 + 0 0 0 0 0

Remove Setting Method 0 0 0 -1 0 0 0 0 -

Table 4f. The effect of dealing with generalizations on software measures


Pull Up Method 0 0 0 - 0 0 - - -

Push Down Method 0 0 0 + 0 0 + + +

Push Down Field 0 0 0 0 + 0 0 0 0

Extract Subclass + + 0 0 0 0 + + +

Extract Superclass + + 0 0 0 0 + + -

Extract Interface + + 0 0 0 0 + + 0

Collapse Hierarchy - - 0 0 0 0 - - 0

Form Template Method 0 0 0 0 0 0 + + +

Replace Inheritance with

Delegation 0 - 0 + 0 + - - +

Replace Delegation with

Inheritance 0 + 0 - 0 - + + -

From the results of refactorings analysis, we can notice that some measures are impacted

more than others. To characterize the effect of refactoring on software measures, for each

category, we count the number of times a measure is impacted by the refactorings in that

category. If a measure is impacted more than 50% of the times then it is considered highly

correlated with such a group, otherwise it is loosely correlated. Table 5 shows which

measures that best characterize the impact of refactoring. The measures in the second and

third columns are ordered by the number of times they have impact on the relevant category.

We notice that messaging (CIS measure) is the most common measure among highly

impacted refactorings. CIS measure is the only highly impacted measure for all categories

except for moving features between objects. The coupling measure (DCC) also changes in

most categories, but highly impacted when composing methods, moving features between

objects and organizing data. The measures that measure inheritance hierarchies are mostly

affected when dealing with generalizations. The cohesion (CAM) measure, which is

considered as an important measure to predict the quality of software, is impacted for only

few refactorings when features are moved between objects. CIS measure is the only measure

that is highly impacted for two categories. These two categories of refactoring target the

methods in classes; therefore for future work, we plan to include more measures that measure

http://www.refactoring.com/catalog/renameMethod.html

http://www.refactoring.com/catalog/removeParameter.html

http://www.refactoring.com/catalog/replaceParameterWithExplicitMethods.html


http://www.refactoring.com/catalog/preserveWholeObject.html

http://www.refactoring.com/catalog/replaceParameterWithMethod.html


http://www.refactoring.com/catalog/introduceParameterObject.html


http://www.refactoring.com/catalog/removeSettingMethod.html

http://www.refactoring.com/catalog/pullUpMethod.html

http://www.refactoring.com/catalog/pushDownMethod.html

http://www.refactoring.com/catalog/pushDownField.html

http://www.refactoring.com/catalog/extractSubclass.html

http://www.refactoring.com/catalog/extractSuperclass.html

http://www.refactoring.com/catalog/extractInterface.html

http://www.refactoring.com/catalog/collapseHierarchy.html

http://www.refactoring.com/catalog/formTemplateMethod.html

http://www.refactoring.com/catalog/replaceInheritanceWithDelegation.html


http://www.refactoring.com/catalog/replaceDelegationWithInheritance.html




140

quality at the method level. The results in Table 5 will be used in the validation part of the

study. We use the two dimensions (high and low impacts) to find matches between the

proposed heuristics and refactoring in real contexts.

Table 5. The effect of refactoring heuristics on measures Refactoring Category High Impact (measures

impacted >50% of times)

Low Impact (measures

impacted <=50% of times)

Composing methods CIS, DCC DSC, CAM, MOA

Moving features between objects DCC, CAM DSC, CIS, MOA

Organizing data CIS, DCC, DSC , MOA ANA, DAM, MFA, NOP

Simplifying conditional expressions CIS NOP, DSC, ANA, MFA

Making method calls simpler CIS DSC, DCC

Dealing with generalizations MFA, NOP, CIS, ANA DSC, DCC, MOA, CAM

5.2 Refactoring impact analysis on quality factors

In this section, we evaluate the effect of refactorings on quality factors by utilizing the

refactoring heuristics resulting from the last section. This evaluation tells us whether a

refactoring activity improves or deteriorates quality factors. The evaluations that are

presented in Table 6 result from using the impact of refactoring on software measures to

calculate the impact on quality factors. For example, by applying the Encapsulate Field, we

see three improvements and no deteriorations on software quality, therefore, we get a

refactoring heuristic: Encapsulate Field improves Reusability, Flexibility, and Effectiveness.

We present these refactoring activities in two tables. Table 6a consists of refactoring

activities that are considered safe (i.e., these refactorings have improvements more than

deteriorations); while Table 6b consists of refactoring activities that are not safe to use (i.e.,

these refactorings have more deteriorations than improvements). Five refactorings do not

have effect on any of the quality factors: Substitute Algorithm, Introduce Assertion, Rename

Method, Remove Parameter, and Preserve Whole Object, because these refactorings do not

have any effect on object-oriented design measures (i.e., zero values for all measures and

quality factors); therefore they are not presented neither in Table 6a nor Table 6b.

Software developers can use these refactoring heuristics to make decisions when to use

refactoring efficiently and to conduct goal-driven refactorings. For example, if a developer

wants to improve the reusability of a system, he or she can consider all refactoring activities

that are listed to increase reusability and avoid the ones that deteriorate reusability. For

example, Encapsulate Field is well-known to increase information hiding. We also found in

our study that Encapsulate Field increases three other quality factors and has no

deteriorations. Hide Delegate is well-known to make design changes easier. We found out

that it also improves reusability, increases flexibility of changing classes, and makes a class

easy to extend. From Table 6b, The Collapse Hierarchy deteriorates four quality factors.

Three refactorings do not have any improvements (Remove Middle Man, Inline Method, and

Remove Setting Method). If developers want to use these refactorings, they should be

precautious. For example, Remove Middle Man can be used when the hiding of delegations

is awkward. In summary, our research findings revealed more useful information on

refactoring than what was proposed by Fowler originally. In addition, the results in Table 6

can be reorganized by a particular quality factor and categorized into safe or unsafe

refactoring.




141

Table 6a. The Effect of refactorings on quality factors (safe refactorings)

Refactoring

Reu

sab

ility

Flex

ibility

Exten

dib

ility

Effectiv

eness

Deterio

ratio

ns

Imp

rovem

en

ts Introduce Local Extension + + + + 0 4

Duplicate Observed Data + + + + 0 4

Replace Type Code with

Subclasses + + + + 0 4

Replace Type Code with

State/Strategy + + + + 0 4

Replace Conditional with

Polymorphism + + + + 0 4

Introduce Null Object + + + + 0 4

Extract Subclass + + + + 0 4

Extract Interface + + + + 0 4

Form Template Method + + + + 0 4

Push Down Method + + + + 0 4

Encapsulate Field + + 0 + 0 3

Hide Delegate + + + 0 0 3

Change Bidirectional Association

to Unidirectional + + + 0 0 3

Extract Superclass 0 + + + 0 3

Replace Array with Object + + - + 1 3

Replace Method with Method

Object + + - + 1 3

Extract Class + + - + 1 3

Replace Data Value with Object + + - + 1 3

Replace Type Code with Class + + - + 1 3

Replace Delegation with

Inheritance - + + + 1 3

Move Method 0 + + 0 0 2

Inline Method - + + 0 1 2

Remove Setting Method - + + 0 1 2

Move Field + 0 0 0 0 1

Decompose Conditional + 0 0 0 0 1

Replace Parameter with Explicit

Methods + 0 0 0 0 1

Push Down Field + 0 0 0 0 1

Replace Temp with Query + 0 0 0 0 1

Replace Parameter with Method + 0 0 0 0 1









http://www.refactoring.com/catalog/introduceNullObject.html

http://www.refactoring.com/catalog/extractSubclass.html

http://www.refactoring.com/catalog/extractInterface.html

http://www.refactoring.com/catalog/formTemplateMethod.html

http://www.refactoring.com/catalog/pushDownMethod.html


http://www.refactoring.com/catalog/hideDelegate.html



http://www.refactoring.com/catalog/extractSuperclass.html




http://www.refactoring.com/catalog/extractClass.html




http://www.refactoring.com/catalog/inlineMethod.html

http://www.refactoring.com/catalog/removeSettingMethod.html

http://www.refactoring.com/catalog/moveField.html

http://www.refactoring.com/catalog/decomposeConditional.html



http://www.refactoring.com/catalog/pushDownField.html

http://www.refactoring.com/catalog/replaceTempWithQuery.html




142

Table 6b. The Effect of refactorings on quality factors (unsafe refactorings)

Refactoring

Reu

sab

ility

Flex

ibility

Ex

tend

ibility

Effec

tiven

ess

Deter

iora

tion

s

Imp

rov

emen

ts Collapse Hierarchy - - - - 4 0

Pull Up Method - - - - 4 0

Remove Middle Man - - - 0 3 0

Inline Class - - + - 3 1

Replace Inheritance with Delegation + - - - 3 1

Extract Method 0 - - 0 2 0

Introduce Foreign Method + - - 0 2 1

Encapsulate Collection + - - 0 2 1

Introduce Parameter Object + - - 0 2 1

5.3 Discussion

Before we validate our findings, we want to show some statistical observations from the

impact analysis of refactoring on software quality. In Table 7 we show a summary of the

relationships between refactorings and the four quality factors, which shows the proportions

of refactoring heuristics that deteriorate, keep unchanged, and improve quality factors.

Reusability is the quality factor that has the largest number of positives; 65% of the examined

refactoring activities have positive impact on reusability. This tells us that most refactoring

activities change classes to have the appropriate responsibilities and make the design more

reusable. The effectiveness improves for 42% of the refactorings, whereas it deteriorates for

9% only. The refactorings improve flexibility and extendibility of a system more than

otherwise. Therefore, most refactoring heuristics improve the four quality factors. There are

four pairs of refactorings where one is an inverse of another. These pairs are shown in Table

8. The effects of these pairs are also inversed. The refactorings in the first column appear

safer than there counterparts in the second column. Nevertheless, some refactorings in the

second column have improvements on software quality. Furthermore, applying these

refactoring does not always deteriorate quality. Rather they can be considered for trade off

analysis. Knowing that a particular refactoring deteriorates a particular quality should not

prevent software developers from refactoring; rather it should guide them through refactoring

to improve a target quality.

Table 7. The summary of the effect of refactorings on quality factors

Quality

Factors Deteriorated Unchanged Improved

Reusability 16% 19% 65%

Flexibility 21% 25.5% 53.5%

Extendibility 30% 28% 42%

Effectiveness 9% 49% 42%

http://www.refactoring.com/catalog/collapseHierarchy.html


http://www.refactoring.com/catalog/inlineClass.html


http://www.refactoring.com/catalog/extractMethod.html


http://www.refactoring.com/catalog/encapsulateCollection.html




143

Table 8. Refactoring Pairs

Refactoring Inversed refactoring

Push down method Pull up method

Extract class Inline class

Hide delegate Remove middle man

Replace delegation with

inheritance

Replace inheritance with

delegation

6. Empirical Validation

To validate the consistency of the resulted refactoring heuristics with real refactorings, we

use two real case studies. We use refactorings of Eclipse UI components and Struts Apache

as real case studies to assess the effect of individual refactoring activities on software quality.

We collected the software measures from the two versions (i.e., before and after refactorings).

The differences between the two versions were calculated and normalized and matched

against the heuristics derived in this work.

6.1 EclipseUI Case Study

The EclipseUI components are parts of the Eclipse development platform. The version

2.1.3 of these components was refactored to produce version 3.0. More than 80% of the

evolution of EclipseUI 2.1.3 was due to refactoring [49]. Each of these versions of EclipseUI

has over 1,000 classes. Dig et al. searched the EclipseUI’s evolution and identified many

refactorings among them two widely used refactorings: Move Method and Pull-up Method.

To get accurate results, we divided the matching into two parts based on the results that were

summarized in Table 5 for moving features between objects, the high and low impacts. For

the Moved Method, we found 100% match between the proposed refactoring heuristic and the

EclipseUI refactorings with the measures that have high impact (DCC, CAM) and 67% match

with the measures that have low impact (DSC, CIS, MOA). For Pull-up Method, we found

67% match between the proposed refactoring heuristic and the EclipseUI refactorings with

the measures that have high impact (MFA, NOP, CIS, ANA) and 50% match with the

measures that have low impact (DSC, DCC, MOA, CAM). These results show that not all

design properties are always affected and there are some measures that highly impacted

whenever refactoring.

6.2 Struts Case Study

The second case study was conducted on the evolution of two versions of an open source

framework for building Java web applications, Struts (struts.apache.org). We chose two

major releases of Struts, 1.1 and 1.2.4, which have more than 460 classes. As in the

EclipseUI case study, Dig et al. searched the Struts evolution and identified many refactorings

among them two widely used refactorings: Move Method and Pull-up Method [49]. Again,

we divided the matching into two, the high and low, impacts. For the Moved Method, we

found 100% match between the refactoring heuristic and the Struts refactorings with the

measures that have high impact (DCC, CAM) and 33% match with the measures that have

low impact (DSC, CIS, MOA). For Pull-up Method, we found 67% match between the

refactoring heuristic and the Struts’ refactorings with the measures that have high impact

(MFA, NOP, CIS, ANA) and 50% match with the measures that have low impact (DSC,

DCC, MOA, CAM). Again, these results show that not all design properties are always

affected and there are some measures that highly impacted whenever refactoring. Therefore,



144

refactoring heuristics can tell us more information about the relevant measures and the nature

of effect the refactoring has on these measures.

7. Conclusion

We assessed the effect of many refactoring activities on four software quality factors:

reusability, flexibility, extendibility, and effectiveness. We found that not all refactoring

activities improve quality factors and some deteriorate quality. We established the

refactoring heuristics that can help developers in following a goal-oriented refactoring

process, i.e., developers can use particular refactorings to improve particular quality. The

heuristics from our research findings, which were confirmed in two empirical studies,

revealed more detailed and useful information for developers than the refactoring definitions.

These heuristics can be used to classify the refactorings based on the quality it improves. For

example, we may reorganize refactorings based on Reusability to safe and unsafe. The safe

refactorings improve reusability and the unsafe refactorings do not improve reusability. This

organization makes developer more precautious whenever they carry out any refactoring

according to Fowler’s catalog. These results provide more insight to the relationship between

refactoring and software quality and evidence for developers to use these techniques more

objectively and conveniently.

7.1 Study Limitations and Future Work

There are possible threats to the validity of the results of this work. First, the work is

limited to the refactoring descriptions that appear in Fowler’s work and may not apply to

variations of these refactorings. Second, the evaluations of the refactorings in this work are

subjective and informal and that because software refactoring is inherently subjective. Third,

the assumption in this work that evolution of code is caused mostly by refactoring, which may

not be the case in real environments. In the future, we plan to conduct more studies on larger

systems either controlled or in real environments to confirm our findings. In addition, we

plan to provide a formalism model for validating the effect of the refactoring under this study.

References

[1]. M. Fowler, K. Beck, J. Brant, W. Opdyke, D. Roberts, Refactoring: Improving the Design of Existing Code, Addison Wesley, 1999.

[2]. K. Beck, Embracing Change with Extreme Programming, computer, 32 (10), (1999) pp. 70–77.

[3]. R. Moser, P. Abrahamsson, W. Pedrycz, A. Sillitti, G. Succi, ―A Case Study on the Impact of Refactoring on

Quality and Productivity in an Agile Team‖, In Balancing Agility and Formalism in Software Engineering,

Bertrand Meyer, Jerzy R. Nawrocki, and Bartosz Walter (Eds.). Lecture Notes In Computer Science, (5082).

Springer-Verlag, Berlin, Heidelberg, pp. 252-266, 2008.

[4]. J. Rech, Context-sensitive Diagnosis of Quality Defects in Object-Oriented Software Systems, Ph. D. Thesis.

Hildesheim: University of Hildesheim, Department IV, 2009.

[5]. R. Shatnawi, ―A quantitative Investigation Of The Acceptable Risk Levels of Object-Oriented Metrics in Open-Source Systems‖, IEEE Transactions on Software Engineering, 36 (2), (2010) pp. 216–225.

[6]. M. Cusumano, R. Selby, Microsoft Secrets, the Free Press, USA, 1995.

[7]. D. Mancl, Refactoring for Software Migration, IEEE Communications Magazine, 39 (10), (2001) pp. 88–93.

[8]. B. Eich, Mozilla Development Roadmap, http://www.mozilla.org/roadmap.html. 29-1-2002., 2002.

[9]. P. Weißgerber, S. Diehl, and C. Görg, ―Mining Refactorings in ARGOUML‖, In Proceedings of the 2006

international workshop on mining software repositories (MSR '06). ACM, New York, NY, USA, pp. 175-176, 2006.



145

[10]. G.C. Murphy, M. Kersten, L. Findlater, ―How Are Java Software Developers Using the Eclipse IDE?‖, IEEE Software, 23 (4), (2006) pp. 76-83.

[11]. R. Bowdidge, ―Performance Trade-offs Implementing Refactoring Support for Objective-C‖, 3rd Workshop on Refactoring Tools, OOPSLA 2009, Orlando FL.

[12]. T. Mens, T. Tourwe, ―A Survey of Software Refactoring, IEEE Transactions on Software Engineering‖, 30(2), (2004) pp. 126–139.

[13]. L. Zhao, J. Hayes, ―Predicting Classes in Need of Refactoring: An Application of Static Metrics‖, second

International PROMISE Workshop, Philadelphia, Pennsylvania USA (co-located with the IEEE Conference on Software Maintenance), 2006.

[14]. R. Marinescu, ―Detecting Design Flaws via Metrics in Object-Oriented Systems‖, Proceedings of the 39th

International Conference and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS39), pp. 173–182, 2001.

[15]. T. Miceli, H. Sahraoui, R. Godin, ―A metric Based Technique for Design Flaws Detection and Correction‖,

Proceedings of the 14th IEEE international conference on automated software engineering, pp.307–310,

1999.

[16]. F. Simon, F. Steinbruckner, C. Lewerentz, ―Metrics Based Refactoring‖, Proc. European Conf. Software

Maintenance and Reengineering, pp. 30–38, 2001.

[17]. Y. Kataoka, D. Notkin, M. Ernst, W. Griswold, ―Automated Support for Program Refactoring Using Invariants‖, 17th IEEE International Conference on Software Maintenance (ICSM'01), pp. 736–743.

[18]. W. Opdyke, Refactoring Object-Oriented Frameworks, PhD thesis, University of Illinois, 1992.

[19]. ISO/IEC 25000, Software Engineering -- Software Product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, Int’l Organization for Standardization, 2005.

[20]. J. Bansiya, C. Davis, ―A Hierarchical Model for Object-Oriented Design Quality Assessment‖, IEEE Transactions on Software Engineering, 28 (1), (2002) pp. 4–17.

[21]. B. Meyer, Object-Oriented Software Construction, Prentice Hall, second ed., 1997.

[22]. T. Mens, S. Demeyer, B.D. Bois, H. Stenten, P. Van Gorp, ―Refactoring: Current Research And Future Trends‖, Electronic Notes in Theoretical Computer Science, 82 (3), (2003) pp. 483–499.

[23]. M. Mäntylä, Bad Smells in Software–A Taxonomy and an Empirical Study, Master Thesis, Department of Computer Science and Engineering, Helsinki University Of Technology, 2003.

[24]. R. Ballew, S. Masover, Refactoring at Berkeley: Improving Code While Containing Costs, iNews: UC

Berkeley information technology news channels, http://inews.berkeley.edu/bcc/Fall2004/refactoring.html,

2010.

[25]. H.A. Sahraoui, R. Godin, T. Miceli, ―Can Metrics Help To Bridge The Gap Between The Improvement of

OO Design Quality And its Automation?‖ In: Proc. International Conference on Software Maintenance, pp. 154–162, 2000.

[26]. E. Stroulia, R.V. Kapoor, ―Metrics of Refactoring-Based Development: an Experience Report‖, In The seventh International Conference on Object-Oriented Information Systems, pp. 113–122, 2001.

[27]. S. Demeyer, Maintainability versus Performance: What’s the Effect of Introducing Polymorphism?, technical report, Lab. On Reengineering, Universiteit Antwerpen, Belgium, 2002.

[28]. Y. Kataoka, T. Imai, H. Andou, T. Fukaya, ―A Quantitative Evaluation of Maintainability Enhancement by

Refactoring‖, Proceedings of the International Conference on Software Maintenance (ICSM.02), pp. 576–585, 2002.

[29]. B.D. Bois, T. Mens, ―Describing the Impact of Refactoring on Internal Program Quality‖, In Proceedings of

the International Workshop on Evolution of Large-scale Industrial Software Applications (ELISA), Amsterdam, The Netherlands, pp. 37–48, 2003.

[30]. T. Mens, S. Demeyer, D. Janssens, ―Formalising Behaviour Preserving Program Transformations‖. In

Proceedings of the First International Conference ICGT 2002, Spain, (2002) pp. 286–301.

[31]. R. Leitch, E. Stroulia, ―Assessing the Maintainability Benefits of Design Restructuring Using Dependency

Analysis‖, Ninth International Software Metrics Symposium (METRICS'03), pp. 309–322.

[32]. L. Tahvildari, ―Quality-Driven Object-Oriented Re-engineering Framework‖. PhD Thesis. Department of

Electrical and Computer Engineering, University of Waterloo, Waterloo, Ontario, Canada, 2003.

[33]. L. Tahvildari, K. Kontogiannis, ―Improving Design Quality Using Meta-Pattern Transformations: A Metric-Based Approach‖, J. Software Maintenance. Evolution: Research and Practice, 16 (4-5), (2004) pp. 331–361.

[34]. L. Tahvildari, K. Kontogiannis, J. Mylopoulos, ―Quality-Driven Software Re-Engineering‖, Journal of

Systems and Software, Special Issue on: Software Architecture - Engineering Quality Attributes, 66(3), (2003) pp. 225-239.



146

[35]. B.D. Bois, S. Demeyer, J. Verelst, ―Refactoring–Improving Coupling and Cohesion Of Existing Code‖, In Belgian Symposium on Software Restructuring, Gent, Belgium, pp. 144–151, 2005.

[36]. J. Ratzinger, M. Fischer, H. Gall, ―Improving Evolvability Through Refactoring‖, Proceedings of the 2nd International Workshop on Mining Software Repositories (MSR’05), 1–5.

[37]. R. Moser, A. Sillitti, P. Abrahamsson, G. Succi, ―Does Refactoring Improve Reusability? ‖, Lecture Notes in Computer Science. 9th International Conference on Software Reuse, pp. 287–297, 2006.

[38]. M. Alshayeb, ―Empirical Investigation of Refactoring Effect on Software Quality‖, Information and Software

Technology, 51 (9), (2009) pp. 1319–1326.

[39]. S. Chidamber, C. Kemerer, ―A Metrics Suite for Object Oriented Design‖, IEEE Transactions on Software

Engineering, 20(6), (1994) pp. 476–493.

[40]. F. Dandashi, D.C. Rine, ―A Method for Assessing the Reusability of Object-Oriented Code Using A

Validated Set of Automated Measurements‖, Proceedings of 17th ACM Symposium on Applied Computing, pp. 997–1003, 2002.

[41]. J.A. McCall, P.K. Richards, G.F. Walters, Factors in Software Quality, vols. 1, 2, and 3, Nat’l Tech. Information Service, 1977.

[42]. ISO/IEC 9126, Information Technology—Software Product Evaluation—Quality Characteristics and

Guidelines for their Use, Int’l Organization for Standardization, 1991.

[43]. J. Bøegh, S. Depanfilis, B. Kitchenham, A. Pasquini, A Method for Software Quality Planning, Control, and

Evaluation, IEEE Software, Researcher’s Corner, 16 (2), (1999) pp. 69–77.

[44]. J. Bansiya, A Hierarchical Model for Quality Assessment of Object-Oriented Designs, PhD Dissertation,

Univ. of Alabama in Huntsville, (1997).

[45]. M. O’Keeffe, M. O´Cinneide, ―Search-Based Refactoring for Software Maintenance‖, The Journal of Systems and Software, 81 (4), (2008) pp. 502–516.

[46]. N. Hsueh, P. Chu, W. Chu, ―A Quantitative Approach for Evaluating the Quality of Design Patterns‖, The Journal of Systems and Software, 81(8), (2008) 1430–1439.

[47]. B. Henderson-Sellers, Object-Oriented Metrics: Measures Of Complexity. Prentice-Hall, 1996.

[48]. T. Mayer, T. Hall, ―A Critical Analysis of Current OO Design Metrics‖, Software Quality Journal, 8 (2), (1999) pp 97–110.

[49]. D. Dig, C. Comertoglu, D. Marinov, R. Johnson, ―Automated Detection of Refactorings in Evolving

Components‖, Proceedings of European Conference on Object-Oriented Programming (ECOOP'06), pp. 404–428.

Appendix I

In this section we provide a description of refactoring activities under study and the

evaluation of their impact on the design of a software system.

Activity Description Evaluation

Extract method A method is extracted form a long method to

have short methods. Short methods increase

reusability and become easier to read and

understand.

This activity increases responsibilities of

a class.

Inline Method This activity is the opposite for extract method.

This refactoring can be used when a group of

methods seem badly decomposed.

This activity decreases responsibilities of

a class.

Replace Temp with

Query

A temporary variable is replaced with a

method (query).

Adding new methods increases

responsibilities of a class.

Replace Method

with Method

Object

A long method that uses many local variables

which makes extract method hard to apply.

We introduce a new object that composes of

one method and many fields (the local

variables).

This activity increases number of classes

in the system and increases coupling and

messaging between objects while

decrease the complexity of the original

class.

Substitute

Algorithm

An algorithm needs to be replaced by a clearer

one.

This activity does not affect any OO

software property.



147

Move Method A method is used by more features of another

class than the class where it exists.

This activity decreases coupling,

responsibilities of a class and the

complexity of the refactored class.

Move Field A field is used by another class more than the

class where it exists. Move this field to that

class and change all its users.

This activity increases coupling to other

classes, cohesion among methods in the

refactoring classes, and responsibilities of

a class.

Extract Class A class does a work of two classes. We create

a new class and move the relevant fields and

methods to the new class.

This activity increases number of classes

in the system, coupling, and cohesion

among methods, while decreases

responsibility of classes.

Inline Class A class is not doing very much. Move all its

fields and methods into another class and

delete it.

This activity decreases number of classes,

coupling between classes and cohesion

among methods while increases


Hide Delegate A client class is calling a delegate class of an

object. Create methods on the server class to

hide the delegate.

This activity reduces coupling and


Remove Middle

Man

A class is doing too much simple delegation.

Get the client class to call the delegate directly.

This activity increases coupling and


Introduce Foreign

Method

A server class needs an additional method, but

the developer can not add it to the server class.

Create a method in the client class with an

instance of the server class as its first

argument.



Introduce Local

Extension

A server class needs several additional

methods, but the developers can't modify the

class. Create a new class that contains these

extra methods. Make this extension class a

subclass or a wrapper of the original.

This activity increases number of classes.

It also increases abstraction, and

utilization of inheritance and

polymorphism, while decreases coupling

and responsibilities of a class.

Replace Data

Value with Object

A data item needs additional data or behavior.

Encapsulate the data item in its own object.


It also increases data encapsulation,

coupling among objects, cohesion among

methods, use of composition, and


Replace Array with

Object

An array contains certain elements that mean

different things. Replace the array with an

object that has a field for each element.


It also increases data encapsulation,

coupling among objects, cohesion among

methods, use of composition, and


Duplicate

Observed Data

A data item is available only in a GUI control,

and some methods need to access it. Copy the

data to a domain object and add an observer to

synchronize the changes on the two pieces of

data.


It also increases abstraction, and

utilization of inheritance and messaging

among objects, while it decreases the

class interface that has the data item.

Change

Bidirectional

Association to

Unidirectional

There is a two-way association between two

classes but one class no longer needs the other.

Drop the unneeded end of the association.

This activity reduces coupling and


Encapsulate Field There is a public field. Make it private and

provide accessor methods.

This activity increases data encapsulation


Encapsulate

Collection

A method returns a collection which makes it

vulnerable to changes. Make it return a read-

only view and provide add/remove methods.

This activity increases data

encapsulation, coupling and use of

composition.

Replace Type Code

with Class

A class has a numeric constant that does not

affect its behavior. Replace the number with a

new class.

This activity increases the number of

classes, data encapsulation, coupling and

the use of composition.



148

Replace Type Code

with Subclasses

You have an immutable type code that affects

the behavior of a class. Replace each type

code with a subclass.

This activity increases number of classes,

data encapsulation, cohesion,

polymorphism, responsibilities of a class,

while it reduces the cyclomatic

complexity of the class.

Replace Type Code

with State/Strategy

You have a type code that affects the behavior

of a class, but subclassing can not be used.

Replace the type code with a state object.


data encapsulation, coupling, cohesion,

polymorphism, responsibilities of a class,

while it reduces the cyclomatic


Decompose

Conditional

You have a complex conditional (if-then-else)

statement. Extract methods from the

condition, then part, and else parts.


a class, while it reduces the cyclomatic


Replace

Conditional with

Polymorphism

You have a conditional that chooses different

behavior depending on the type of an object.

Move each leg of the conditional to an

overriding method in a subclass. Make the

original method abstract.


utilization of inheritance, and

polymorphism, while reduces the

cyclomatic complexity of the class.

Introduce Null

Object

You have repeated checks for a null value.

Replace the null value with a null object.


and polymorphism, while reduces the

cyclomatic complexity of the class.

Introduce Assertion A section of code assumes something about

the state of the program. Make the assumption

explicit with an assertion.

This activity has no effect on OO metrics.

Rename Method The name of a method does not reveal its

purpose. Change the name of the method.


Remove Parameter A parameter is no longer used by the method

body. Remove this parameter.


Replace Parameter

with Explicit

Methods

You have a method that runs different code

depending on the values of an enumerated

parameter. Create a separate method for each

value of the parameter.


a class, while reduces the cyclomatic


Preserve Whole

Object

You are getting several values from an object

and passing these values as parameters in a

method call.

Send the whole object instead.

This activity increases the encapsulation

and the interface size.

Replace Parameter

with Method

An object invokes a method and passes the

result as a parameter for a method. The

receiver can also invoke this method. Remove

the parameter and let the receiver invoke the

method.


a class while reduces the cyclomatic

complexity.

Introduce

Parameter Object

You have a group of parameters that naturally

go together. Replace them with an object.


encapsulation and responsibilities of a

class.

Remove Setting

Method

A field should be set at creation time and never

altered. Remove any setting method for that

field.

This activity decreases responsibilities of

a class.

Pull Up Method You have methods with identical results on

subclasses. Move them to the superclass.

This activity increases utilization of

inheritance.

Push Down

Method

Behavior on a superclass is relevant only for

some of its subclasses. Move it to those

subclasses.

This activity decreases utilization of

inheritance.

Push Down Field A field is used only by some subclasses. Move

the field to those subclasses.

This activity increases cohesion.

Extract Subclass A class has features that are used only in some

instances. Create a subclass for that subset of

features.


number of hierarchies, utilization of

inheritance, and polymorphism.



149

Extract Superclass You have two classes with similar features.

Create a superclass and move the common

features to the superclass.


number of hierarchies, abstraction, and

utilization of inheritance.

Extract Interface Several clients use the same subset of a class's

interface, or two classes have part of their

interfaces in common. Extract the subset into

an interface.


number of hierarchies, and abstraction.

Collapse Hierarchy A superclass and subclass are not very

different. Merge them together.

This activity decreases number of classes,

number of hierarchies, abstraction,

polymorphism and utilization of

inheritance, while increases


Form Template

Method

You have two methods in subclasses that

perform similar steps in the same order, yet the

steps are different. Get the steps into methods

with the same signature, so that the original

methods become the same. Then you can pull

them up.

This activity increases utilization of

inheritance and responsibilities of a class.

Replace

Inheritance with

Delegation

A subclass uses only part of a superclasses

interface or does not want to inherit data.

Create a field for the superclass, adjust

methods to delegate to the superclass, and

remove the subclassing.


responsibilities of a class, while

decreases number of hierarchies,

utilization of inheritance, and

polymorphism.

Replace Delegation

with Inheritance

You are using delegation and are often writing

many simple delegations for the entire

interface. Make the delegating class a subclass

of the delegate.

This activity increases number of

hierarchies, utilization of inheritance, and

polymorphism, while decreases coupling




150

an empirical assessment of refactoring impact on software quality using a hierarchical quality

Documents