The Journal of Systems and Software 105 (2015) 18–39

Contents lists available at ScienceDirect

The Journal of Systems and Software
journal homepage: www.elsevier.com/locate/jss

Improving multi-objective code-smells correction usingdevelopment history
Ali Ouni a,∗, Marouane Kessentini b, Houari Sahraoui c, Katsuro Inoue a, Mohamed Salah Hamdi daGraduate School of Information Science and Technology, Osaka University, Osaka, Japan
Computer and Information Science Department, University of Michigan, Michigan, USAc
DIRO, Université de Montréal, QC, Canadad
IT Department, Ahmed Ben Mohamed Military College, Qatarba r t i c l e

i n f oArticle history:
Received 2 December 2013
Revised 7 January 2015
Accepted 11 March 2015
Available online 19 March 2015
Keywords:
Search-based software engineering
Refactoring
Code-smells

a b s t r a c t
One of the widely used techniques to improve the quality of software systems is refactoring. Software
refactoring improves the internal structure of the system while preserving its external behavior. These twoconcerns drive the existing approaches to refactoring automation. However, recent studies demonstrated
that these concerns are not enough to produce correct and consistent refactoring solutions. In addition
to quality improvement and behavior preservation, studies consider, among others, construct semantics
preservation and minimization of changes. From another perspective, development history was proven as a
powerful source of knowledge in many maintenance tasks. Still, development history is not widely exploredin the context of automated software refactoring. In this paper, we use the development history collectedfrom existing software projects to propose new refactoring solutions taking into account context similarity
with situations seen in the past. We propose a multi-objective optimization-based approach to ﬁnd good
refactoring sequences that (1) minimize the number of code-smells, and (2) maximize the use of development
history while (3) preserving the construct semantics. To this end, we use the non-dominated sorting genetic
algorithm (NSGA-II) to ﬁnd the best trade-offs between these three objectives. We evaluate our approach
using a benchmark composed of ﬁve medium and large-size open-source systems and four types of codesmells (Blob, spaghetti code, functional decomposition, and data class). Our experimental results show theeffectiveness of our approach, compared to three different state-of-the-art approaches, with more than 85%
of code-smells ﬁxed and 86% of suggested refactorings semantically coherent when the change history isused.
© 2015 Elsevier Inc. All rights reserved.

1. Introduction
During software maintenance and evolution, software systems undergo continuous changes, through which new features are added,
bugs are ﬁxed, and business processes are adapted constantly (Mensand Demeyer, 2008; Zimmermann et al., 2005). To support these activities, many tools emerged to manage source code such as concurrent versions system (CVS), and subversion (SVN) (Cederqvist andDec, 2003) where all documentation, conﬁguration, and code-changes
are archived and called “software-development history”. Hence, these
historical data in software engineering provide a lot of solid knowledge that can be used to make sound data driven decisions for solving
many software engineering problems (Ratzinger et al., 2007; Soetens
et al., 2013; Beyer and Noack, 2005; Ying et al., 2004) and designing∗

Corresponding author. Tel.: +15143436111.
E-mail addresses: ouniali@iro.umontreal.ca, ali@ist.osaka-u.ac.jp (A. Ouni),
marouane@umich.edu (M. Kessentini), sahraouh@iro.umontreal.ca (H. Sahraoui),inoue@ist.osaka-u.ac.jp (K. Inoue), mshamdi@abmmc.edu.qa (M.S. Hamdi).
http://dx.doi.org/10.1016/j.jss.2015.03.040
0164-1212/© 2015 Elsevier Inc. All rights reserved.

software engineering tools (Hassan and Holt, 2004; Gall et al., 1998;
Ratiu et al., 2004). Furthermore, reuse is a common practice for developers during software development/maintenance to save time andefforts.
One of the widely used techniques during software development/maintenance to improve code quality is refactoring, the processof improving the internal structure of software systems without affecting its overall behavior (Opdyke, 1992). In general, to apply refactoring, we need to identify (1) where a program should be refactoredand (2) which refactorings to apply (Fowler et al., 1999; Mens andTourwé, 2004). Automating the refactoring suggestion task is essential and useful to eﬃciently help software developers in improving
the quality of their code such as reusability, maintainability, ﬂexibility, and understandability, etc.
Recently,search-based approaches have been applied to automate
software refactoring (O’Keeffe and Cinnéide, 2006; Ouni et al., 2012;
Harman and Tratt, 2007; Seng et al., 2006). Most of these works
formulated refactoring as a single-objective optimization problem,in which the main goal is to improve code quality while preserving

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

the behavior (see, for example, O’Keeffe and Cinnéide, 2006; Senget al., 2006; Kessentini et al., 2011; Qayum and Heckel, 2009). In
other works, other objectives are also considered such as reducing
the effort (number of code changes) (Ouni et al., 2013a), preserving
semantic coherence (Ouni et al., 2012), and improving quality metrics (O’Keeffe and Cinnéide, 2006). However, structural and semantic
information are not, sometimes, enough to generate powerful refactoring strategies (Ouni et al., 2013b,c).
The use of development history can be helpful to propose eﬃcientrefactoring solutions (Ouni et al., 2013b,c). Code fragments that are
modiﬁed over the past in the same period are semantically connected(i.e. belong to the same feature). Furthermore, fragments that are extensively refactored in the past bear a high probability for refactoringin the future. Moreover, code fragments to refactor can be similar
to some patterns that can be found in the development history thus
developers can easily reuse and adapt them. However, despite its
importance, the history of code changes has not been widely investigated/used in the context of refactoring (Ouni et al., 2013c; Kagdi
et al., 2007).
To the best of our knowledge, the use of historical data to automate software refactoring is not explored before our recent work in
Ouni et al. (2013c). In this paper, we extend this work, published in
GECCO 2013 (Ouni et al., 2013c), which uses the change history of asoftware system to suggest new refactoring opportunities to ﬁx codesmells (Ouni et al., 2013c). We considered three different measures:(a) similarity with previous refactorings applied to the same codefragments within the same system, (b) number of changes applied in
the past to the same code elements to be refactored, and (c) a scorethat characterizes the co-change of elements that will be refactored.
The approach was successfully applied and evaluated on two different software systems using their change history and three types ofcode smells. However, the proposed approach can be applied only tosystems with existing histories of changes.
In this paper, we consider the situation when the change history
is not available or when we deal with newly developed software systems. We extend our previous work (Ouni et al., 2013c) by considering
the history of past refactorings, applied to similar contexts, borrowed
from different software projects. The primary contributions of thispaper can be summarized as follows:(1) We introduce a novel measure that aims at calculating thecontext similarity score between proposed refactoring operations, and a set of refactorings collected from different software
projects.
(2) We deﬁne an extended formulation of the mutation genetic
operator to better explore the search space.
(3) We extend the evaluation of the approach. We present an empirical study based on a quantitative and qualitative evaluation
using (a) three additional subject systems, (b) an additional
type of code-smells, and (c) two new quantitative evaluation
metrics, hypervolume and spread (Zitzler et al., 2003; Deb,2009), to better evaluate the performance of our approach. The
quantitative evaluation investigates whether our approach isable to improve software quality while ﬁxing code-smells using
the development change history. For the qualitative evaluation,
we evaluated the eﬃciency of our approach with three subjects
from both academia and industry.
Our experimental results show that most of the detected codesmells were ﬁxed with an average of 85%, and an average of 86%
of suggested refactorings were semantically coherent. In addition,
statistical analysis of our experiments over 31 runs shows that NSGAII performed signiﬁcantly better than state-of-the-art metaheuristic
techniques in terms of hypervolume and spread (Zitzler et al., 2003;
Deb, 2009).
The rest of this paper is organized as follows: Section 2 describes
the relevant background and summarizes the related work in which

19

the current paper is located; Section 3 describes the refactoring challenges through a motivating example. Section 4 describes the used
multi-objective search-based algorithm and its design. Experimental results and evaluation of the approach are reported in Section 5.
Section 6 is dedicated to the discussion, while Section 7 presents thethreats to validity. Finally, concluding remarks and directions for future work are provided in Section 8.

2. Background2.1. Deﬁnitions
2.1.1. Code-smells
Code-smells, also called anomalies (Fowler et al., 1999), antipatterns (Brown et al., 1998), design ﬂaws (Marinescu, 2004) or bad
smells (Fowler et al., 1999), are problems resulting from bad design
and programming practices and refer to situations that adversely affect the software maintenance and evolution. According to Fowler
et al. (1999), code-smells are unlikely to cause failures directly, but
may do it indirectly. In general, they make a system diﬃcult to change,
which may in turn introduce bugs. Different types of code-smells,presenting a variety of symptoms, have been studied in the intent
of facilitating their detection (Moha et al., 2010) and suggesting improvement solutions. Most of code-smells identify locations in thecode that violate object-oriented design heuristics, such as the situations described by Riel (1996) and by Coad and Yourdon (1991).
Code-smells are not limited to design ﬂaws since most of them occur
in code and are not related to the original design. In fact, most ofcode-smells can emerge during the evolution of a system. In Fowler
et al. (1999), Beck deﬁnes 22 sets of symptoms of code-smells andproposes the different possible refactoring solutions to improve thesystem design. These include large classes, feature envy, long parameter lists, and lazy classes. Each code-smell type is accompanied byrefactoring suggestions to remove it. Van Emden and Moonen (2002)
developed one of the ﬁrst automated code-smell detection tools forJava programs. Mantyla studied the manner of how developers detect and analyze code smells (Mäntylä et al., 2003). Previous empiricalstudies have analyzed the impact of code-smells on different software
maintainability factors including defects (Monden et al., 2002; Li and
Shatnawi, 2007; Sjoberg et al., 2013) and effort (Deligiannis et al.,2003, 2004). In fact, software metrics (quality indicators) are sometimes diﬃcult to interpret and suggest some actions (refactoring) as
noted by Marinescu (2004) and Anda et al. (Mens and Demeyer, 2008).
Code-smells are associated with a generic list of possible refactorings
to improve the quality of software systems. In addition, Yamashita
and Moonen (2013a,b) show that the different types of code-smells
can cover most of maintainability factors (Yamashita and Moonen,2012). Thus, the detection of code-smells can be considered as a goodalternative of the traditional use of quality metrics to evaluate thequality of software products. Brown et al. (1998) deﬁne another category of code-smells that are documented in the literature, and named
anti-patterns. In this paper, we focus on the four following code-smell
types to evaluate our approach:- Blob: It is found in designs where one large class monopolizes the
behavior of a system (or part of it), and the other classes primarily
encapsulate data.
- Data class: It contains only data and performs no processing onthese data. It is typically composed of highly cohesive ﬁelds andaccessors.
- Spaghetti code: It is a code with a complex and tangled control
structure.
- Functional decomposition: It occurs when a class is designedwith the intent of performing a single function. This is found incode produced by non-experienced object-oriented developers.

20

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

We decided to focus our attention on these code-smells because
they are among the most related to faults or change proneness(Khomh et al., 2009) and the most common in the literature andfrequently targeted for detection and correction in recent studies(see, for example, Kessentini et al., 2011; Ouni et al., 2013a,b,c; Moha
et al., 2010). Hence, various approaches and tools supporting codesmells detection have been proposed in the literature such as JDeodorant (Tsantalis et al., 2008), infusion (Infusion hydrogen 2012), Décor(Moha et al., 2010), iPasma (iPlasma, 0000) Kessentini et al. (2011),
Ouni et al. (2013a). The vast majority of these tools provide different
environments and methods to detect code-smells. However, the correction is not mature yet, and several problems should be addressed.
2.1.2. Refactoring
One of the well-known development activities that can help ﬁx
code-smells and reduce the increasing complexity of a software system is refactoring. Fowler et al. (1999) deﬁne refactoring as a disciplined technique for restructuring an existing body of code, altering
its internal structure without changing its external behavior. The notion of refactoring was introduced by Opdyke (1992), which provided
a catalogue of refactorings that could be applied in speciﬁc situations (Opdyke, 1992). The idea is to reorganize variables, classes andmethods to facilitate future adaptations and extensions. This reorganization is used to improve different aspects of software-quality
such as maintainability, extensibility, reusability, etc. (Fowler et al.,
1999; Mens and Tourwé, 2004). For these precious beneﬁts on design
quality, some modern integrated development environments (IDEs),such as Eclipse,1 NetBeans,2 and Refactoring Browser,3 provide semiautomatic support for applying the most commonly used refactorings, e.g., move method, rename class, etc. However, automaticallysuggesting/deciding where and which refactorings to apply is stilla real challenge in software engineering. Roughly speaking, we canidentify two distinct steps in the refactoring process: (1) detect wherea program should be refactored and (2) identify which refactorings
should be applied (Fowler et al., 1999).
2.1.3. Construct semantics
Construct semantics represents the semantic coherence in the
structure of program entities. In object-oriented (OO) programs, objects reify domain concepts and/or physical objects. They implement
their characteristics and behavior. Unlike for other programming
paradigms, grouping data and behavior into classes is not guided bydevelopment or maintenance considerations. Operations and ﬁelds ofclasses characterize the structure and behavior of the implemented
domain elements. Consequently, a program could be syntacticallycorrect, implement the right behavior, but violates the domain andconstruct semantics if the reiﬁcation of domain elements is incorrect.
During the initial design/implementation, programs capture well theconstruct semantic when the OO principles are applied. However,when these programs are (semi) automatically modiﬁed during maintenance, the adequacy with domain semantics could be compromised.
To this end, it is important to preserve the construct semantics during
refactoring.
2.2. Related work
In this section, we review and discuss related work on software
refactoring, and the use of change history for several purposes in software engineering. A large number of research works have addressed
the problem of code-smells correction and software refactoring in1

http://www.eclipse.org/.
https://netbeans.org/.
3
http://www.refactory.com/refactoring-browser.
2

recent years. We start by surveying those works that can be classiﬁed mainly into two broad categories: manual and semi-automatedapproaches, and search-based approaches.
2.2.1. Manual and semi-automated approaches
We start by summarizing existing manual and semi-automatedapproaches for software refactoring. In Fowler’s book (Fowler et al.,1999), a non-exhaustive list of low-level design problems in sourcecode has been deﬁned. For each design problem (i.e., code-smell), a
particular list of possible refactorings is suggested to be applied bysoftware maintainers manually. Indeed, in the literature, most of theexisting approaches are based on quality metrics improvement to deal
with refactoring. Sahraoui et al. (2000) have proposed an approach todetect opportunities of code transformations (i.e., refactorings) basedon the study of the correlation between some quality metrics andrefactoring changes. To this end, different rules are deﬁned as a combination of metrics/thresholds to be used as indicators for detecting code-smells and refactoring opportunities. For each code-smella pre-deﬁned and standard list of transformations should be appliedin order to improve the quality of the code. Another similar work is
proposed by Du Bois et al. (2004) who starts from the hypothesis thatrefactoring opportunities correspond of those which improve cohesion and coupling metrics to perform an optimal distribution of features over classes. Du Bois et al. analyze how refactorings manipulate
coupling and cohesion metrics, and how to identify refactoring opportunities that improve these metrics. However, these two approaches
are limited to only some possible refactoring operations with a small
set of quality metrics. In addition, improving some quality metrics
does not mean that existing code-smells are ﬁxed.
Moha et al. (2008) proposed an approach that suggests refactorings using formal concept analysis (FCA) to correct detected codesmells. This work combines the eﬃciency of cohesion/coupling metrics with FCA to suggest refactoring opportunities. However, the link
between code-smells detection and correction is not obvious, whichmake the inspection diﬃcult for the maintainers. Similarly, Joshi and
Joshi (2009) have presented an approach based on concept analysis aimed at identifying less-cohesive classes. It also helps identify
less-cohesive methods, attributes and classes in one go. Further, theapproach guides refactoring opportunity identiﬁcation such as extract class, move method, localize attributes and remove unused attributes. In addition, Tahvildari and Kontogiannis (2003) also proposed a framework of object-oriented metrics used to suggest to thesoftware engineer refactoring opportunities to improve the quality ofan object-oriented legacy system.
Other contributions are based on rules that can be expressed asassertions (invariants, pre and post-condition). The use of invariants
has been proposed to detect parts of code that require refactoringby Kataoka et al. (2001). In addition, Opdyke (1992) has proposed
the deﬁnition and the use of pre- and post-condition with invariants
to preserve the behavior of the software when applying refactoring.
Hence, behavior preservation is based on the veriﬁcation/satisfactionof a set of pre and post-condition. All these conditions are expressedin terms of rules.
The major limitation of these manual and semi-automated approaches is that they try to apply refactorings separately without
considering the whole program to be refactored and its impact on
the other artifacts. Indeed, these approaches are limited to only somepossible refactoring operations and a few quality metrics to assess
quality improvement. In addition, improving some quality metrics
does mean necessary that actual code-smells are ﬁxed.
2.2.2. Search-based approaches
Search-based approaches can be classiﬁed into two main categories: mono-objective and multi-objective optimization approaches.
In the ﬁrst category, the majority of the existing work combinesseveral metrics in a single ﬁtness function to ﬁnd the best sequence

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

of refactorings. Seng et al. (2006) have proposed a single-objective
optimization-based approach using genetic algorithm to suggest alist of refactorings to improve software quality. The search processuses a single ﬁtness function to maximize a weighted sum of several quality metrics. The used metrics are mainly related to various
class level properties such as coupling, cohesion, complexity and stability. Indeed, the authors have used some pre-conditions for eachrefactoring. These conditions serve at preserving the program behavior (refactoring feasibility). However, in this approach, the semantic
coherence of the refactored program is not considered. In addition,
the approach was limited only on the refactoring operation “movemethod”. Furthermore, there is another similar work of O’Keeffe andCinnéide (2006) that have used different local search-based techniques such as hill climbing and simulated annealing to provide anautomated refactoring support. Eleven object-oriented design metrics have been used to evaluate the quality improvement. One of theearliest works on search-based approaches is the work by Qayum andHeckel (2009) who considered the problem of refactoring schedulingas a graph transformation problem. They expressed refactorings as
a search for an optimal path, using ant colony optimization, in thegraph where nodes and edges represent respectively refactoring candidates and dependencies between them. However the use of graphs
is limited only on structural and syntactical information and therefore
does not consider the domain semantics of the program neither its
runtime behavior. Furthermore, Fatiregun et al. (2004) showed how
search-based transformations could be used to reduce code size andconstruct amorphous program slices. They have used small atomic
level transformations in their approach. In addition, their aim wasto reduce program size rather than to improve its structure/quality.
Recently, Kessentini et al. (2011) have proposed a single-objective
combinatorial optimization using genetic algorithm to ﬁnd the best
sequence of refactoring operations that improve the quality of thecode by minimizing as much as possible the number of code-smells
detected on the source code. Also, Otero et al. (2010) use a new searchbased refactoring. The main idea behind this work is to explore theaddition of a refactoring step into the genetic programming iteration.
There will be an additional loop in which refactoring steps drawn
from a catalogue of such steps will be applied to individuals of the
population. Jensen and Cheng (2010) have proposed an approach that
supports composition of design changes and makes the introductionof design patterns a primary goal of the refactoring process. They usedgenetic programming and software metrics to identify the most suitable set of refactorings to apply to a software design. Furthermore,
Kilic et al. (2011) explore the use of a variety of population-based approaches to search-based parallel refactoring, ﬁnding that local beam
search could ﬁnd the best solutions.
In the second category of work, Harman and Tratt (2007) have proposed a search-based approach using Pareto optimality that combines
two quality metrics, CBO (coupling between objects) and SDMPC(standard deviation of methods per class), in two separate objectivefunctions. The authors start from the assumption that good design
quality results from a good distribution of features (methods) amongclasses. Their Pareto optimality-based algorithm succeeded in ﬁnding good sequence of “move method” refactorings that should provide the best compromise between CBO and SDMPC to improve code
quality. However, one of the limitations of this approach is that it islimited to unique refactoring operation (move method) to improve
software quality and only two metrics to evaluate the preformed improvements. Recently, Ó Cinnéide et al. (2012) have proposed a multiobjective search-based refactoring to conduct an empirical investigation to assess some structural metrics and to explore relationships
between them. To this end, they have used a variety of search techniques (Pareto-optimal search, semi-random search) guided by a setof cohesion metrics. One of the earliest works on multi-objective
search based refactoring is the work by Ouni et al. (2013a) who proposed a multi-objective optimization approach to ﬁnd the best se-21

quence of refactorings using NSGA-II. The proposed approach is basedon two objective functions, quality (proportion of corrected codesmells) and code modiﬁcation effort, to recommend a sequence of
refactorings that provide the best trade-off between quality and effort.
To conclude, the vast majority of existing search-based software
engineering approaches focused only on the program structure improvements. However, the main limitation is that the semantics
preservation is not considered in the search process. Moreover, suggesting new refactorings should not be made independently to previous changes and maintenance/development history. This is one of themost relevant limitations on search-based refactoring approaches,
which do not consider how the software has been changed andevolved and how software elements are impacted by these changes.
2.2.3. The use of historical data in software engineering
There is some few research work that uses the change history
in the context of refactoring. Soetens et al. (2013) proposed an approach to detect (reconstruct) refactorings that are applied between
two software versions based on the change history. The scope of thiscontribution is different than the one proposed in this paper, since
our aim is to suggest refactoring solutions to be applied in the future
to improve software quality while maintaining the consistency withthe change history. Ratzinger et al. (2007) used change history mining
to predict the likelihood of a class to be refactored in the next twomonths using machine learning techniques. Their goal is to identify
classes that are refactoring or non-refactoring prone. In their prediction models they do not distinguish different types of refactorings (e.g.
create super class, extract method, etc.); they only assess the fact thatdevelopers try to improve the design. In contrast, in our approach,
we suggest concrete refactoring solution to improve code quality andnot only identifying refactoring opportunities.
In addition, data extraction from development history/repositoryis very well covered. Research has been carried out to detect andinterpret groups of software entities that change together. Theseco-change relationships have been used for different purposes.
Zimmermann et al. (2005) have used historical changes to point developers to possible places that need change. In addition historicalcommon code changes are used to cluster software artifacts (Beyer
and Noack, 2005; Gîrba et al., 2007), to predict source code changes bymining change history (Zimmermann et al., 2005; Ying et al., 2004),
to identify hidden architectural dependencies (Gall et al., 1998) or to
use them as change predictors (Hassan and Holt, 2004). In addition,
recently, co-change has been used in several empirical studies in software engineering. However, in the best of our knowledge, until now,the development change history is not used for software refactoring.
3. Refactoring challenges
3.1. Limitations and challenges
Various techniques are proposed to automate the refactoring process (Mens and Tourwé, 2004; Ouni et al., 2012, 2013a; Seng et al.,2006; Choinzon and Ueda, 2006; Mens and Tourwé, 2004). Most ofthese techniques are based on structural information using a set of
quality metrics. The structural information is used to ensure that applied refactorings improve some quality metrics such as the numberof methods/attributes per class, coupling, and cohesion. However, this
could not be enough to conﬁrm that a refactoring makes sense andpreserves the design semantic coherence. It is important to preserve
the rationale behind why and how code elements are grouped andconnected.
To solve this issue, semantic measures are used to evaluate refactoring suggestions such as those based on coupling and cohesion or
information retrieval techniques (e.g. cosine similarity of the used vocabulary) (Ouni et al., 2012). However, these semantic measures depend heavily on the meaning of code elements name/identiﬁer (e.g.,22

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

name of methods, name of classes, etc.). Indeed, due to some timeconstraints, developers often select meaningless names for classes,
methods, or ﬁelds (e.g., not clearly related to the functionalities). Thus,
it is risky to only use techniques such as cosine similarity to ﬁnd asemantic approximation between code fragments. In addition, when
applying a refactoring like move method between two classes manytarget classes can have the same values of coupling and cohesion withthe source class. To make the situation worse, it is also possible thatthe different target classes have the same structure. Furthermore,suggesting new refactorings should not be made independently toprevious changes and maintenance/development history. This is oneof the most relevant limitations existing work, which do not consider
how the software has been changed and evolved and how software
elements are impacted by these changes.
To circumvent the above mentioned problems, we use, in thispaper, knowledge mined from past maintenance and development
history to suggest refactoring solutions. Many aspects can help toimprove the automation of refactoring (Ouni et al., 2013c): (1) code
elements which underwent changes in the past, at approximately
the same time, are in general semantically dependent, (2) code elements changed many times in the past have a good probability to be“badly-designed”, (3) the development history can be used to propose
new refactoring solutions in similar contexts. However, when we deal
with newly developed software systems or with systems where thedevelopment is not available, other considerations should be taken
into account to ﬁnd similarities between the new candidate refactoring solutions and refactorings applied in other projects in similar
contexts.

in previous versions of JFreeChart some methods (such as drawPrimaryLinePath(), initialise(), and equals()) that have been moved from theclass XYLineAndShapeRenderer to the class XYSplineRenderer. Moreover, we found in JHotDraw that the method draw() has been moved
from the class ArrowTip to the class AbstractLineDecoration. These
recorded refactorings in both JFreeChart and JHotDraw are applied
to similar context with the structure of our classes being refactored
in JVacation (i.e., the classes DBClient and CustomerModel). The similarity between code fragments can be estimated using not only quality
metrics (e.g. coupling, number of methods, number of attributes, etc.)
but also using semantic similarity measures (Ouni et al., 2012). As aconsequence, moving methods and/or attributes from the class DBClient to the class CustomerModel has a high probability of correctness.
Thus, in this paper, we are based on the hypothesis that the more arecommended refactoring is similar to refactorings applied to different software projects in the past in similar contexts, the more themeaningfulness of the recommended refactoring is high. The idea isto encourage the reuse of collected refactorings that are applied tosimilar contexts in different software projects.
The refactorings applied in the previous versions of a system canbe detected using existing refactoring detection tools such as RefFinder. Several remarkable techniques have been proposed for recording code changes directly in the development framework as they areapplied by a developer (Kim et al., 2013; Ekman and Asklund, 2004) orby analyzing two versions of a system and computing the differences
between them. However, this is the ﬁrst attempt to use development
history to propose new refactoring solutions after our contribution in
Ouni et al. (2013c).

3.2. Motivating scenario

4. Multi-objective search-based refactoring

To illustrate some of the above-mentioned issues, Fig. 1 shows aconcrete example extracted from JVacation,4 an open-source standalone travel-booking-client for travel-agencies written in Java.
JVacation was developed in 2007, and contains a large number ofcode-smells, which has been at the origin of the slowdown of their development. It has not been actively maintained/evolved since its ﬁrst
release. Consequently, JVacation has no development change history
since it has not been widely used by the open-source community.
We consider a design fragment that contains four classes DBClient,
Booking, CustomerModel and JourneyModel. Using the detection rules
proposed in Ouni et al. (2013a), two code-smells are detected.
The class DBClient is detected as a blob code-smell, and the class
CustomerModel is detected as a data class. One possible refactoring solution to improve the design quality is to move some methods and/or
ﬁelds from the blob class to other classes in the program, mainly dataclasses. In this way, we will reduce the number of functionalities implemented in the blob class DBClient and add additional behavior/functionalities to some other data classes such as CustomerModel. A
refactoring is proposed to move the method checkNotation() fromthe smelly class DBClient to another suitable class in a way that we
preserve the semantic coherence of the original program. Based on semantic and structural information (Ouni et al., 2012) many other target classes are possible, including Booking, CustomerModel and JourneyModel using vocabulary-based measures, cohesion and coupling(Ouni et al., 2012). However, since JVacation has no developmentchange history, there are no refactorings applied in the past to thesecode fragments, and consequently, the history measures we deﬁned
in Ouni et al. (2013c) are not useful for this case.
An alternative solution can be to use the development history ofother projects that are refactored in the past in similar contexts. Thus,
we found in other software projects such as JFreeChart and JHotDraw
similar contexts to our classes to refactor described in Fig. 1. We foundIn this section, we give an overview about our proposal where
the use of development history is adapted to overcome the different
limitations discussed in Section 2. Then, we describe our formulationof the refactoring suggestion problem and how the non-dominatedsorting genetic algorithm (NSGA-II) (Deb, 2009) is used.

4

https://sourceforge.net/projects/jvacation/.

4.1. Approach overview
Our approach aims at exploring a huge search space to ﬁnd refactoring solutions, i.e., a sequence of refactoring operations, to correct code-smells. We have three objectives to optimize: (1) maximize quality improvement (code-smells correction); (2) minimize
the number of construct semantic incoherencies by preserving theway how code elements are semantically grouped and connected together; and (3) maintain the consistency with the previous refactorings applied to similar contexts using cross-project context similarity. To this end, we consider the refactoring task as a multi-objective
optimization problem instead of a single-objective one using the nondominated sorting genetic algorithm (NSGA-II) (Deb, 2009).
The general structure of our approach is sketched in Fig. 2. It takes
as input the source code of the program to be refactored, a list of possible refactorings that can be applied, a set of code-smells detection
rules (Ouni et al., 2013a; Kessentini et al., 2011), a set of semantic
measures (Ouni et al., 2012), and a history of applied changes (CVS,change log, collected refactorings). Our approach generates as output the optimal set of refactorings, selected from the list of possible
refactorings, which improves the software quality by minimizing as
much as possible the number of code-smells, preserving constructsemantics, and maximizing the reuse of development change history
to similar contexts.
4.2. Problem formulation
In our previous work (Ouni et al., 2013c), we proposed an automated approach, to improve the quality of a system while preserving

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

23

DBClient
connector : DBConnector...

CustomerModelcontroller : MaintenanceController
customerList : List<Customer>
CustomerModel()addChangeListener()
fireStateChanged()
getCustomerList()
searchCustomer()
getAllCustomerList()
addCustomer()deleteCustomer()
getTableData()

DBClient()
getObjectList()
saveObject()
updateObjectList()
updateObject()deleteObjectList()deleteObject()
getTourOperatorList()
getTourOperatorObject()
saveTourOperator()
updateTourOperatorList()
updateTourOperator()deleteTourOperator()deleteTourOperatorList()
getCustomerList()
getCustomerObject()getAllCustomer()
getCustomerById()
searchCustomer()saveCustomerList()
saveCustomer()
updateCustomerList()
updateCustomer()deleteCustomer()deleteCustomerList()
getLodgingList()
getLodgingObject()getAllLodging()
getLodgingById()
searchLodging()
searchLodgingFilter()saveLodgingList()
saveLodging()
updateLodgingList()
updateLodging()
deleteLodging()
deleteLodgingList()
getBookingList()
getBookingObject()getAllBooking()
getBookingById()
searchBooking()
saveBookingList()
saveBooking()
updateBookingList()
updateBooking()
deleteBooking()
deleteBookingList(List)
getBookingLodgingList()
getBookingLodgingObject()getAllBookingLodging()
getBookingLodgingById()
searchBookingLodging()
saveBookingLodgingList()
saveBookingLodging()
updateBookingLodgingList()
updateBookingLodging()
deleteBookingLodging()
deleteBookingLodgingList()
getFlightList()
getFlightObject()getAllFlight()
getFlightById()
searchFlights()
getAiportMap()...

Booking_ID : String_BOOKING_ID : String_CUSTOMER_ID : String_DB_PRIMARY_KEY : String_DB_TABLE : Tablebooking_id : int
customer_id : int
flight_id : int
booked_places : int
travellers : String
price : float...
Booking()Booking()
getBooked_places()
setBooked_places()
getBooking_id()
setBooking_id()
getCustomer_id()
setCustomer_id()
getFlight_id()
setFlight_id()
getPrice()
setPrice()
getTravellers()
setTravellers()
toString()

Code-smell: Data class

JourneyModelcontroller : MaintenanceController
bookingList : List<Booking>bookingLodgingList : List<BookingLodging>
JourneyModel()addChangeListener()
fireStateChanged()
getBookingLodgingList()
getBookingList()deleteBooking(Booking)deleteBookingLodging()
getTableDataBooking()
getTableDataBookingLodging()
searchBookingLodgingFilter()searchBookingFilter()getAllBookingLodgingList()
getAllBookingList()

Code-smell: BlobFig. 1. Design fragment extracted from JVacation v1.0.

24

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

Historical data
Co-change
MatrixAvailable refactoring
operations
Versioning System

Classes change
frequency

Search-based Refactoring

Suggested refactoring
solutions(NSGA-II)

Collected
refactorings

Original sourcecode

Semantic
similarity
Fig. 2. The use of development history for recommending software refactoring: an overview.

its construct semantics. It uses multi-objective optimization to ﬁnd
the best compromise between code quality improvement and construct semantics preservation. Improving software quality corresponds to correcting code-smells. We used code-smell detection
rules, proposed in our previous work (Ouni et al., 2013a), to ﬁnd thebest refactoring solutions, from the list of possible refactorings, whichshould ﬁx as much as possible the number of detected code-smells. On
the other hand, preserving the construct semantics after applying thesuggested refactorings is ensured by maximizing different semantic
measures: (1) vocabulary-based similarity (cosine similarity between
words: name of code elements); and (2) dependency-based similarity (call-graph, coupling and cohesion) (Ouni et al., 2012). Moreover,
we seek to maximize the use of development history to improve theconstruct semantics preservation.
Due to the large number of possible refactoring solutions and theconﬂicting objectives related to the quality improvements and theconstruct semantic preservation, we considered the refactoring as amulti-objective optimization problem instead of a single-objective
one (O’Keeffe and Cinnéide, 2006; Seng et al., 2006; Kessentini et al.,2011). The search-based process takes as inputs, the source code,
code-smells detection rules, a set of refactoring operations, and a callgraph for the whole program. As output, our approach recommends a
set of refactoring solutions. A solution consists of a sequence of refactoring operations that should be applied to improve the quality of the
input code. The used detection rules are expressed in terms of metrics and threshold values. Each rule detects a speciﬁc code-smell type(e.g., blob, spaghetti code, functional decomposition, etc.) and is expressed as a logical combination of a set of quality metrics/thresholdvalues (Kessentini et al., 2011; Ouni et al., 2013a). The process ofgenerating a correction solution (refactorings) can be viewed as themechanism that ﬁnds the best list among all available refactoring operations that best reduces the number of detected code-smells andat the same time, preserves the construct semantics of the initialprogram. In other words, this process aims at ﬁnding the best tradeoff between these two conﬂicting criteria.
We extend, in this paper, our previous work (Ouni et al., 2013c)
by considering the history of collected refactorings from different
software projects applied to similar contexts. Concretely, we consider
three different measures: (a) similarity with previous refactorings
applied to similar contexts in other software projects, (b) number ofchanges applied in the past to the same code elements to modify, and(c) a score that characterizes the co-change of elements that will be
refactored.
4.2.1. Similarity with recorded refactorings applied to similar contexts
The overall idea is to maximize/encourage the use of new refactorings that are similar to those applied to different software projects insimilar contexts. To calculate the cross-project refactoring similarity
score between a candidate refactoring operation and a set of collectedrefactorings, we use the following function:

SimRef actoringHistory (RO) =n

wROi ∗ ContextSimilarity(RO, ROi )

i=1

(1)
where:- n is the number of recorded refactoring operations collected fromdifferent software systems;- wi is a refactoring weight that reﬂects the similarity between thesuggested refactoring operation RO and the recorded refactoring
operation ROi . Table 1 describes the used weigh values. The weight
wi is computed as follows: if the two refactoring operations being compared have exactly the same type (e.g., “Move Method”
and “Move Method”), the weight wi = 2. If the refactoring operations being compared are similar, the weight wi = 1. We consider
two refactoring operations as similar if their implementations are

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

25

Table 1
Similarity weights between refactoring types.

Move method
Move ﬁeld
Pull up ﬁeld
Pull up method
Push down ﬁeld
Push down method
Inline classMove class
Extract class
Extract interfaceMovemethodMove
ﬁeld

Pull upﬁeld

Pull upmethodPush down
ﬁeldPush down
methodInline
class

Move
class

Extract
class

Extract
interface

2
1
0
1
0
1
1
1
1
0

1
2
1
0
1
0
1
1
1
0

0
0
2
1
0
0
1
1
0
1

1
0
1
2
0
0
1
1
0
1

0
1
0
0
2
1
1
1
0
1

1
0
0
0
1
2
1
1
0
1

0
0
0
0
0
0
2
0
0
0

0
0
0
0
0
0
0
2
0
0

1
1
0
0
0
0
0
1
2
0

0
0
1
1
1
1
0
0
0
2

similar, or if one of them is composed by the other. For instance,some complex refactoring operations, such as “Extract Class”, canbe composed by combining other refactoring operations such as“Move Method”, “Move Field”, “Create New Class”, etc. Otherwise,
the weight wi = 0.
To calculate the similarity score of the whole proposed refactoring solution with historical code changes, we calculate thesum of the similarity value of each refactoring operation in thissolution with the base of collected refactorings. The function
ContextSimilarity(CRO , CRO i ) aims at calculating the context similarity between the refactoring operation RO applied to the codefragment CRO and the refactoring operation ROi applied to the codefragments CRO i . The aim of this measure is to estimate whether
two refactorings are in similar contexts. The similarity score is
calculated using (1) structure-based and (2) semantic-based metrics (Ouni et al., 2012), to assess the context similarity between
original code to be refactored and code from different software
projects that underwent refactorings in the past. Context similarity between two refactorings RO and ROi is deﬁned as follows:

ContextSimilarity(RO, ROi )(CBOsim (CRO, CROi ) + Dsim (CRO, CROi ))
= α×
+β
2
× SemanticSim(CRO , CROi )


 




CBOsim CRO , CROi = CBO CRO − CBO CROi (2)

4.2.1.1. Structural similarity. This measure can be formalized using
quality metrics (Chidamber and Kemerer, 1994). In our approach,we consider CBO (coupling between objects) that was deﬁned by
Chidamber and Kemerer (1994) and formulated later in Briand et al.’s
metrics catalogue (Briand et al., 1999). We chose CBO because of its
ability to capture the context in which a class is located with respect
to the rest of classes in the system. Moreover, CBO is one of the mostused metrics to detect and ﬁx code-smells (Kessentini et al., 2011;
iPlasma, 0000) as well as ﬁnding refactoring opportunities (O’Keeffeand Cinnéide, 2006; Harman and Tratt, 2007; Ó Cinnéide et al., 2012),
predict changeability, and impact analysis. By deﬁnition, CBO counts
the number of other classes to which a given class is coupled and,hence, denotes the dependency of one class on other classes in thedesign. Formally, CBO is deﬁned as follow:(3)

where C is the set of all classes in the system and uses(x, y) is apredicate that is true if there is a relationship between the two classes(4)

We also consider the dependency-based similarity (Dsim ; Ouni
et al., 2012) when comparing the context similarity. In fact, somerefactorings involve only one class to be applied (e.g., extract method),whereas other refactorings involve a pair of classes (e.g., movemethod, move ﬁeld, inline class). For the latter, we approximate
context similarity between classes starting from their mutual dependencies. The intuition is that classes that are strongly or slightly
connected (i.e., having dependency links) are likely to be involved in
speciﬁc changes such as move method or move ﬁeld, etc. To comparecontext similarity in terms of Dsim between a candidate refactoring
RO that involves the code fragments CRO = {c1 , c2 }, and a recorded
refactoring ROi applied in the past that involves the code fragments
CROi = {c1 , c2 }, we deﬁne the function Dsim as follow:


 


Dsim CRO , CROi = coup (c1 , c2 ) − coup c 1 , c 2 

where α + β = 1 are the coeﬃcients for the two components
representing the structural and semantic similarities. In our experiments, we give equal weight values to both coeﬃcients(α = β = 0.5). These two parameters can be adjusted according to the maintainer preferences. The obtained values are thennormalized in the range [0, 1] using min–max normalization anddeﬁned as follow:

CBO(c) = |{d ∈ C − {c}\| uses(c, d) ∨ uses(d, c)}|x and y e.g. a method call from x to y, an attribute or local variable oftype y in x.
To measure the context similarity between a candidate refactoring
RO that involves the code fragments CRO , and a recorded refactoring
ROi applied in past that involves the code fragments CROi , we deﬁne
the function CBOsim as follow:(5)

where coup(x, y) returns the number of relationships between thetwo classes x and y, e.g. method calls, attribute or local variable oftype x in y or vice versa.
4.2.1.2. Semantic similarity. We consider another kind of coupling toassess the context similarity. This measure is based on vocabularybased similarity (Soetens et al., 2013), also called conceptual coupling(Poshyvanyk and Marcus, 2006), and uses semantic information obtained from source, encoded in identiﬁers and comments.
This kind of coupling is interesting to consider when measuring
the context similarity of a class with the rest of classes in the system. The vocabulary could be used as an indicator of the semantic
similarity between different code elements (e.g., method, ﬁeld, class,etc.). We start from the assumption that the vocabulary of an actor
is borrowed from the domain terminology and therefore could be
used to determine which part of the domain semantics is encoded byan actor (e.g., class, method, package, interface, etc.). Thus, two code
elements could be semantically similar if they use similar vocabularies. The vocabulary is extracted from the code element identiﬁers(i.e., names of methods, ﬁelds, variables, parameters, types, etc.) as
well as comments. Tokenization is performed using the Camel Case
Splitter which is one of the most used techniques in Software Maintenance tools for the preprocessing of identiﬁers. To extract vocabulary
from comments, a stop word list is used to cut-off and ﬁlter all common English words.5 In addition, we excluded all the Java keywords

5

http://www.textﬁxer.com/resources/common-english-words.txt.

26

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39(e.g., Boolean, abstract, class, string, etc.). Furthermore, our semantic similarity utilizes WordNet6 to enrich the extracted vocabulary.
WordNet is a widely used lexical database that groups nouns, verbs,
adjectives, etc. into the sets of synsets, i.e., cognitive synonyms, each
representing a distinct concept. Then all the extracted vocabulary
is stored as a vector where each dimension represents an extracted
word. Furthermore, more vocabulary can also be extracted from documentation and commits information. We then calculate the semantic
similarity between extracted vocabulary from these code elements(e.g., classes) using information retrieval-based techniques (e.g., cosine similarity). Eq. (6) calculates the cosine similarity between twoclasses. Each class is represented as a n dimensional vector, where
each dimension corresponds to a vocabulary term. The cosine of theangle between two vectors is considered as an indicator of similarity.
Using cosine similarity, the semantic similarity between two classes
c1 and c2 in the same project is determined as follows:−→ −→c1 · c2−→ −→Sim(c1 , c2 ) = cos(c1 · c2 ) =    
−
→ −
→
 c1  ∗  c2 ni=1 (wi,1 ∗ wi,2 )

= 
n
2 n
2
i=1 (wi,1 )
i=1 (wi,2 )

(6)

(7)

One
can
recommendacandidaterefactoringR:
move_method(getCustomerObject(), DBClient, CustomerModel)
to JVacation. In this settings, the context similarity between thecandidate refactoring R and our recorded refactorings R1, R2, R3 andR4 is calculated as follows:
i=1

wRi ∗ ContextSimilarity(R, Ri )= wR1 ∗ ContextSimilarity(R, R1 )+ wR2 ∗ ContextSimilarity(R, R2 )+ wR3 ∗ ContextSimilarity(R, R3 )+ wR4 ∗ ContextSimilarity(R, R4 )6

wordnet.princeton.edu.

1where:


CBOsim CR , CR1= |CBO(DBClient) − CBO(XYLineAndShapeRenderer)|+ |CBO(CustomerModel) − CBO XYSplineRenderer |Dsim (CR , CR1 )= |coup(DBClient, CustomerModel)

R1: move_method(drawPrimaryLinePath(), XYLineAndShapeRenderer, XYSplineRenderer)
R2: move_method(initialize(), XYLineAndShapeRenderer, XYSplineRenderer)
R3: move_method(equals(), XYLineAndShapeRenderer, XYSplineRenderer)
R4: move_method(draw(), ArrowTip, AbstractLineDecoration)

4

move method (XYLineAndShapeRenderer, XYSplineRenderer))





= 0.5 ∗ CBOsim CR , CR1 + Dsim CR , CR1 /2

 
 
+ 0.5 ∗ SemanticSim CR − SemanticSim CR 

= |38 − 30| + |7 − 10| = 11 (Eq. (4))

where Sim(x, y) returns the cosine similarity between the two classes
x and y, as deﬁned in Eq. (6). The less the SemanticSim value is, themore the two refactorings are in similar contexts.
To illustrate the context similarity for both structural and semantic measures, let us consider the example of our motivating scenario
described in Section 3.2. The aim is to recommend refactoring operations to our running software system JVacation using recorded refactorings from other projects (i.e., JHotDraw and JFreeChart). The list ofrecorded refactorings includes the following refactoring operations:

SimRef actoringHistory(R) =ContextSimilarity R, R1
= ContextSimilarity R, R2 = ContextSimilarity R, R3
= ContextSimilarity(move method DBClient, CustomerModel ,

and,

−
→
where c1 = (w1,1 , . . . , wn,1 ) is the term vector corresponding to actor−→
c1 and c2 = (w1,2 , . . . , wn,2 ) is the term vector corresponding to c2 .
The weights wi,j is computed using information retrieval based technique, i.e., term frequency - inverse term frequency (TF-IDF) method.
The vocabulary is gathered and saved as vector.
To calculate the cross-project similarity in terms of semantic similarity between a candidate refactoring RO that involves the codefragments CRO = {c1 , c2 }, and a recorded refactoring ROi applied in
the past that involves the code fragments CROi = {c1 , c2 } , we deﬁne
the function SemanticSim as follow:

 



Semantic Sim CRO , CROi = Sim (c1 , c2 ) − Sim c1 , c2 

where:
According to Table 1: WR1 = WR2 = WR3 = WR4 = 2
And according to Eq. (2):− coup(XYLineAndShapeRenderer, XYSplineRenderer)|= |7 − 5| = 2 (Eq. (5))
According to Eq. (7):SemanticSim(CR , CR1 )= |sim(DBClient, CustomerModel)− sim(XYLineAndShapeRenderer, XYSplineRenderer)|= |0.39 − 0.5| = 0.11
After normalizing each of the CBOsim and Dsim values in the scale[0, 1] using min-max normalization, we obtain:ContextSimilarity R, R1 = ContextSimilarity R, R2
= ContextSimilarity R, R3 = 0.31
Similarly:ContextSimilarity R, R4 = 0.36
Finally,

SimRef actoringHistory(R)= WR1 ∗ ContextSimilarity R, R1
+ WR2 ∗ ContextSimilarity R, R2
+ WR3 ∗ ContextSimilarity R, R3
+ WR4 ∗ ContextSimilarity R, R4= 2 ∗ 0.31 + 2 ∗ 0.31 + 2 ∗ 0.31 + 2 ∗ 0.36 = 2.58
The aim behind these structural and semantic similarities is to ﬁnd
patterns and regularities when applying refactoring. For instance, as
shown in the previous example, the case of move method refactoring
is often applied between semantically and structurally similar classes.
The more CBOsim , Dsim and semantic similarity values between thepair of classes being refactored are close to the ones of collectedrefactorings, the more the suggested refactoring is encouraged.
4.2.2. Change frequency
In a typical software system, important code fragments are those
who change frequently during the development/maintenance process to add new functionalities, to accommodate new changes or to
improve its structure. Moreover, as reported in the literature (Olbrichet al., 2010; Olbrich et al., 2009; Khomh et al., 2009), classes participating in design problems (e.g., code-smells) are signiﬁcantly more likely
to be subject to changes and to be involved in fault-ﬁxing changes

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39(bugs; Khomh et al., 2009). Indeed, if a class undergoes many changes
in the past and it is still smelly, so it needs to be ﬁxed as soon as
possible. On the other hand, not every code-smell is assumed to havenegative effects on the maintenance/evolution of a system. It has
been shown that in some cases, a large class might be the best solution (Olbrich et al., 2010). Moreover, it is reported that if a code-smell(e.g., god class) is created intentionally and remains unmodiﬁed or did
not change frequently, the system may not experience any problems(Olbrich et al., 2010). For these reasons, code-smells related to more
frequently changed classes should be prioritized during the correction
process.
This score represents the number of changes applied during thepast to the same code elements to modify. If this number is high,then we can conclude that this is a good indication that this codefragment is badly designed, thus represents a refactoring opportunity.
This second measure is deﬁned as:n ChangeFrequency RO =
t (e)

27
Software version archive

Commit 1
Commit 2

A

B

B

C
A

F
C

Commit 4

Commit 3

Commit 5

F
D

D

C

B
A

Changed files

Co-change matrix
(CCM)
CCM

A B C D E F G
A 3 3 1 1 0 1 1
B 3 3 1 1 0 1 1
C 1 1 3 1 1 1 0
D 1 1 1 2 1 1 0
E 0 0 1 1 1 1 0
F 1 1 1 1 1 2 1
G 1 1 0 0 0 1 1

(8)

i=1

where t(e) is the number of times that the code element(s) e wasrefactored in the past and n is the size of the list of possible refactoring
operations.

Fig. 3. Co-changes matrix.

4.2.3. Co-change
Recently, research has been carried out to mining software version repositories (Gall et al., 1998; Zimmermann et al., 2005; Beyer
and Noack, 2005; Gall et al., 1998). One of the important challenges
addressed is to detect and interpret groups of software entities thatchange together. These co-change relationships have been used for
different purposes: to identify hidden architectural dependencies(Gall et al., 1998), to point developers to possible places that needchange (Zimmermann et al., 2005), or to use them for software clustering (Beyer and Noack, 2005). Detecting historical co-changes ismostly based on mining versioning systems such as CVS and in identifying pairs of changed entities. Entities are usually ﬁles, and thechange is determined through observing additions or deletions oflines of code. In the past decades, many CVS archives of open-source
and industrial systems are freely available, e.g., via SourceForge.net.
We analyze CVS repositories to identify which classes have beenchanged together at the same time. To this end, we use only sourcecode ﬁles to extract co-change; however, other non-useful ﬁles (e.g.,documentation, conﬁguration ﬁles, etc.) are ﬁltered out. We consider
that when a source code ﬁle has been changed then each class inthis ﬁle is changed (almost only one or two classes per ﬁle are implemented in actual systems). Each commit/revision contains a lotof information such as the ﬁle name, the commit/revision number,the developer who performed the commit, the log message, and thetimestamp of the check-in. Co-change can be easily detected by mining version archives, and is less expensive than program analysis(coupling, cohesion, etc.) (Ying et al., 2004). We depict in Fig. 3 anexample of how to detect the co-change between classes through different commits from version history archives to generate a co-change
matrix CCM. CCMi,j represented how many times the class i have beenchanged at the same (i.e., in the same commit)time with class j (cochange). In our adaptation, code changes are applied at the same time
if they are introduced in the same commit. For example, we can observe that almost when the class A change, the class B change also.
This reveals that the implementations and semantics of these twoclasses are strongly related. Therefore, moving code elements (methods/attributes) between them is likely to be semantically coherent
since many changes have been manually performed between them inthe past by software developers.
In the next sections we give an overview of NSGA-II, and its adaptation for the problem of refactoring using the change history.

4.3. NSGA-II overview
The basic idea of NSGA-II (Deb et al., 2002) is to make a population of candidate solutions evolve toward the near-optimal solution
in order to solve a multi-objective optimization problem. NSGA-II is
designed to ﬁnd a set of optimal solutions, called non-dominated solutions, also Pareto set. A non-dominated solution is the one which
provides a suitable compromise between all objectives without degrading any of them. As described in Algorithm 1, the ﬁrst step in
NSGA-II is to create randomly a population P0 of individuals encodedusing a speciﬁc representation (line 1). Then, a child population Q0 is
generated from the population of parents P0 using genetic operatorssuch as crossover and mutation (line 2). Both populations are merged
into an initial population R0 of size N (line 5).
Fast-non-dominated-sort (Deb et al., 2002) is the algorithm used
by NSGA-II to classify individual solutions into different dominancelevels. Indeed, the concept of Pareto dominance consists of comparing
each solution x with every other solution in the population until it isdominated by one of them. If no solution dominates it, the solution x
will be considered non-dominated and will be selected by the NSGAII to be one of the set of Pareto front. If we consider a set of objectives
fi , i  1 . . . n, to maximize, a solution x dominates x

iff

 

 

∀i, fi x ≤ fi (x) and ∃j|fj x < fj (x) .

The whole population that contains N individuals (solutions) is
sorted using the dominance principle into several fronts (line 6). Solutions on the ﬁrst Pareto-front F0 get assigned dominance level of
0.Then, after taking these solutions out, fast-non-dominated-sort calculates the Pareto-front F1 of the remaining population; solutions on
this second front get assigned dominance level of 1, and so on. The
dominance level becomes the basis of selection of individual solutions
for the next generation. Fronts are added successively until the parent
population Pt+1 is ﬁlled with N solutions (line 8). When NSGA-II has
to cut off a front Fi and select a subset of individual solutions withthe same dominance level, it relies on the crowding distance (Debet al., 2002) to make the selection (line 9). This parameter is used topromote diversity within the population. This front Fi to be split, issorted in descending order (line 13), and the ﬁrst (N-|Pt+1 |) elementsof Fi are chosen (line 14). Then a new population Qt+1 is created using selection, crossover and mutation (line 15). This process will be28

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

repeated until reaching the last iteration according to stop criteria(line 4).

Table 2
Refactoring operations and their controlling parameters.
Refactoring operation

ActorsRoles

Move method

Class
MethodSource class, target class
Moved method

Move ﬁeld

Class
Field

Source class, target class
Moved ﬁeld

Pull up ﬁeld

Class
Field

Sub classes, super class
Moved ﬁeld

Pull up method

Class
MethodSub classes, super class
Moved method

Push down ﬁeld

Class
Field

Super class, sub classes
Moved ﬁeld

Push down method

Class
MethodSuper class, sub classes
MethodInline class

Class

Source class, target class

Extract class

Class
Field
MethodSource class, new class
Moved ﬁelds
Moved methods

Move class

Package
Class

Source package, target package
Moved class

Extract interface

Class
Field
MethodSource classes, new interface
Moved ﬁelds
Moved methods

Algorithm 1. High-level pseudo-code of NSGA-II.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

Create an initial population P0
Generate an offspring population Q0
t=0;
while stopping criteria not reached do
Rt = Pt  Qt ;F = fast-non-dominated-sort (Rt );Pt+1 =  and i=1;
while | Pt+1 | +|Fi |  N do
Apply crowding-distance-assignment(Fi );Pt+1 = Pt+1  Fi ;i = i+1;
end
Sort(Fi ,  n);
Pt+1 = Pt+1  Fi [1 : (N-| Pt+1 |)];
Qt+1 = create-new-pop(Pt+1 );t = t+1;
end

4.4. NSGA-II design
This section describes how NSGA-II (Deb, 2009) can be used forthe refactoring suggestion problem. In general, to apply NSGA-II to a
speciﬁc problem, the following elements have to be deﬁned: representation of the individuals (solution coding), evaluation of individuals using a ﬁtness function for each objective to optimize, selection of
the individuals to transmit from one generation to another, creationof new individuals using genetic operators (crossover and mutation)
to explore the search space, and generation of a new population.
4.4.1. Solution coding
As deﬁned in the previous sections, a solution comprises a sequence of n refactoring operations applied to certain elements in thesource code under refactoring. To represent a candidate solution (individual), we use a vector-based representation. Each dimension of
the vector represents a refactoring operation where the order of application of the refactoring operations corresponds to their positions in
the vector. The standard approach of pre- and post-conditions (Fowler
et al., 1999; Opdyke, 1992) is used to ensure that the refactoring operation can be applied while preserving program behavior. For eachrefactoring operation, a set of controlling parameters (e.g., actors androles as illustrated in Table 2) is randomly picked from the program
to be refactored. Assigning randomly a sequence of refactorings tocertain code fragments generates the initial population. An example of a solution is given in Fig. 4 containing eight refactorings. To
apply a refactoring operation we need to specify which actors, i.e.,code fragments, are involved/impacted by this refactoring and whichroles, they play to perform the refactoring operation. An actor can
be a package, class, ﬁeld, method, parameter, statement or variable.
Table 2 depicts, for each refactoring, its involved actors and its role.
To generate an initial population, we start by deﬁning the maximum vector length (maximum number of operations per solution).

move field (Person, Employee, salary)extract class(Person, Adress, streetNo, city, zipCode, getAdress(), updateAdress())

The vector length is proportional to the number of refactorings thatare considered, the size of the program being refactored, and the initial number of detected code-smells. A higher number of operations
in a solution does not necessarily mean that the results will be better.
Ideally, a small number of operations should be suﬃcient to provide
a good trade-off between the ﬁtness functions. This parameter can be
speciﬁed by the software maintainer or derived randomly from thesizes of the program, the given refactoring list, and the initial number of detected code-smells. During the creation, the solutions haverandom sizes inside the allowed range. To create the initial population, we normally generate a set of PopSize solutions randomly in thesolution space.
4.4.2. Selection
To guide the selection process, NSGA-II uses a binary tournament
selection based on dominance and crowding distance (Deb et al.,2002). NSGA-II sorts the population using the dominance principle
which classiﬁes individual solutions into different dominance levels.
Then, to construct a new population, NSGA-II uses a comparison operator based on a calculation of the crowding distance (Deb et al., 2002)
to select potential individuals having the same dominance level.
4.4.3. Genetic operators
Two genetic operators are deﬁned: the crossover and mutation
operators. To better explore the search space, in this paper, we extend
our previous deﬁnition of genetic operators used in Ouni et al. (2013c).
4.4.3.1 Mutation. Mutation operator simply picks at random somepositions in the vector and changes them by other refactoring operations. For each of the selected refactorings, we apply randomly oneof the following possible changes using equal probabilities:

move method (Person, Employee, getSalary())
push down field (Person, Student, studentId)
inline class (Car, Vehicle)
move method (Person, Employee, setSalary())
move field (Person, Employee, tax)
extract class (Student, Course, courseName, CourseCode, addCourse(), rejectCourse()
Fig. 4. Solution coding.

- Refactoring type change (RTC): It consists of replacing a given
refactoring operation (the refactoring type and controlling parameters) by another one which is selected randomly from the initiallist of possible refactorings. Pre- and post-conditions should bechecked before applying this change.
- Controlling parameters change (CPC): It consists of replacing
randomly, for the selected refactoring, only their controlling parameters. For instance, for a “move method”, we can replace theA. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

Intitialrefactoring
solution

Producedrefactoring
solution1

move field (f18_2, c18, c23)

2

move method (m4_6, c4, c89)

3extract class (c31, f31_1 , m31_1, m31_4)

4
5
6

29

1

move field (f18_2, c18, c23)

2

move method (m5_2, c5, c36)

3

extract class (c31, f31_1 , m31_1, m31_4)

pull up field (f8_1, c8, c14)

4

inline class (c24, c82)

move method (f41_2, c41, c129)

5

move method (f41_2, c41, c129)

move field (f12_8, c12, c52)

6

move field (f12_8, c12, c13)

Mutation

After mutation

Before mutation
Fig. 5. Example of mutation operator.

Parent 1

Parent 2

1

move field (f18_2, c18, c23)

1

move field (f18_2, c18, c23)

2

move method (m4_6, c4, c89)

2

move method (m4_6, c4, c89)

3extract class (c31, f31_1 , m31_1, m31_4)

3

extract class (c31, f31_1 , m31_1, m31_4)

4

move field (f12_10, c12, c119)

5

inline class (c24, c82)

First solution
produced

Child 1

4

pull up field (f8_1, c8, c14)

5

move method (f41_2, c41, c129)

6

move field (f12_8, c12, c52)

1

move method (m5_1, c5, c112)

2

Inline class (c5, c31)

3

push down method (m231_3, c231, c19)

3

push down method (m231_3, c231, c19)

4

pull up field (f8_1, c8, c14)

4

move field (f12_10, c12, c119)

5

move method (f41_2, c41, c129)

5inline class (c24, c82)

6

move field (f12_8, c12, c52)

Crossover(i = 3)
Second solution
produced

Child 2

1

move method (m5_1, c5, c112)

2

Inline class (c5, c31)

After crossover

Before crossover
Fig. 6. Example of crossover operator.

source and/or target classes by other classes that can be selectedfrom the whole system.
A mutation example is shown in Fig. 5. Three refactorings are randomly selected from the initial vector: one refactoring type change(dimension number 4), and two controlling parameters change (dimensions number 2 and 6).
4.4.3.2 Crossover. For crossover, we use a single, random, cut-pointcrossover. It starts by selecting and splitting at random two parent
solutions. Then crossover creates two child solutions by putting, forthe ﬁrst child, the ﬁrst part of the ﬁrst parent with the second partof the second parent, and, for the second child, the ﬁrst part of thesecond parent with the second part of the ﬁrst parent. This operator must ensure that the length limits are respected by eliminating
randomly some refactoring operations. As illustrated in Fig. 5, eachchild combines some of the refactoring operations of the ﬁrst parent
with some ones of the second parent. In any given generation, eachsolution will be the parent in at most one crossover operation. An
example of crossover is given by Fig. 6.
4.4.4. Fitness functions
After creating a solution, it should be evaluated using ﬁtness function to ensure its ability to solve the problem under consideration. The
solution proposed in this paper is based on studying how to preserve
the way how code elements are semantically grouped and connected
together when refactorings are decided automatically, and how to use
the development change history to automate refactoring suggestion.
Semantic preservation is captured by different heuristics/measuresthat could be integrated into existing refactoring approaches to help
preserving semantic coherence. Since we have three objectives, wedeﬁne three different ﬁtness functions:(1) Quality ﬁtness function calculates the ratio of the number ofcorrected code-smells over the initial number of code-smells
using detection rules (Ouni et al., 2013a).
(2) Semantic ﬁtness function corresponds to the weighted sum of
semantic measures (Ouni et al., 2012): vocabulary similarity(cosine similarity), and structural dependency (shared method
calls and shared ﬁeld access) used to approximate the semantic
proximity between modiﬁed code elements. Hence, the semantic ﬁtness function of a refactoring solution corresponds to theaverage of the semantic measure for each refactoring operationin the vector.
(3) History of changes’ ﬁtness function calculates an average of threemeasures described in Section 3.2: (a) similarity with previous refactorings applied to similar contexts, (b) number ofchanges applied in the past to the same code elements to modify (change frequency), and (c) a score that characterizes theco-change of code elements (actors) that will be refactored. In
the case when the program is newly developed or if the development history is not available, only the ﬁrst measure isconsidered.
5. Evaluation
In this section, we describe the evaluation of our approach, including the research questions to address, the studied open-source

30

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

systems, the evaluation metrics considered in our experiments, andthe results’ analysis.

Table 3
Systems statistics.

5.1. Research questions and objectives
In our study, we assess the performance of our refactoring approach by ﬁnding out whether it could generate meaningful sequences of refactorings that ﬁx code-smells while preserving theconstruct semantics of the original design, and reusing as much as
possible the development history applied to similar contexts. Our
study reﬁnes and extends the research questions presented in ourprevious work (Ouni et al., 2013c). We conduct now a quantitativeand qualitative evaluation on ﬁve subject systems instead of two, an
additional type of code smells, and two new evaluation metrics tobetter evaluate the scalability and the performance of our approach.
Consequently, we address the following research questions:
RQ1.1 (SBSE validation): How does NSGA-II perform compared torandom search? We compared our NSGA-II formulation withrandom search to make sure that there is a need for an intelligent method to explore the search-space. The next two
sub-questions are related to the comparison between our proposal and other multi and mono-objective metaheuristics that
address also the refactoring problem within the same formulation. These three questions are a standard ‘baseline’ questions
asked in any attempt at an SBSE formulation.
RQ1.2 (SBSE validation): How does NSGA-II perform compared toanother multi-objective algorithm in terms of code-smells correction and refactoring suggestion meaningfulness? We compare NSGA-II with another popular multi-objective algorithm,
MOGA (multi-objective genetic algorithm) (Zitzler and Thiele,
1998), using the same adaptation (solution coding, ﬁtness functions, etc.) to justify the use of NSGA-II.
RQ1.3 (SBSE validation): How does our approach using NSGA-II
performs compared to mono-objective evolutionary algorithms?
This comparison is required to ensure that the refactoring solutions, found by a multi-objective search (i.e., NSGA-II and
MOGA) provide better trade-offs between quality and refactoring meaningfulness, than those found by a mono-objective
approach, e.g., genetic algorithm (GA) (Fonseca and Fleming, 1993). Otherwise, there is reason to use multi-objective
optimization.
RQ2 (Eﬃciency): To what extent can the proposed approach correct code-smells in the situation where the change history is notavailable? We compare the eﬃciency of our approach in ﬁxing code-smells in both situations where the change history isavailable and where it is not available.
RQ3 (Usefulness): To what extent can the proposed approach
recommend meaningful refactorings in the situation where thechange history is not available? We compare the meaningfulness of the recommended refactorings in both situations
where the change history is available and where it is notavailable.
RQ4 (Comparison to state-of-the-art): How does our NSGA-II approach perform comparing to existing refactoring approaches? Acomparison with existing refactoring approaches (Kessentini
et al., 2011; Ouni et al., 2012) and (Harman and Tratt, 2007) is
helpful to evaluate the eﬃciency of our proposed approach.
RQ5 (Insight): How our multi-objective refactoring approach can be
useful for software engineers in real-world setting? The expected
beneﬁt from refactoring is not limited to ﬁxing code-smells but
to improve also the user understandability, reusability, ﬂexibility, as well as the effectiveness of the refactored program.
To this end, it is important to also evaluate the beneﬁt of ourapproach from this perspective.

Systems

Release# classes# codesmells

KLOC# previous
code-changes

Xerces-J
JFreeChart
GanttProject
ArtofIllusion
JHotDraw

v2.7.0v1.0.9v1.10.2
v2.8.1
V7.0.6

991
521
245
459
468

87
84
45
68
16

240
170
41
87
57

7493
2009
91
594
1006

Table 4
Analyzed versions and data collection.
Systems

Xerces-J
JFreeChart
GanttProject
ArtofIllusion
JHotDraw

Releasev2.7.0v1.0.9v1.10.2
v2.8.1v7.0.6

Collected refactorings# previous

Previous releases# Refactoringscode-changes

v1.4.2–v2.6.1
v1.0.6–v1.0.9
v1.7–v1.10.2
v1.2–v1.8.2
v5.1–v6.1

70
76
91
247
64

7493
2009
91
594
1006

5.2. Experimental setting
5.2.1. Systems studied
We applied our approach to a benchmark composed of ﬁve
medium and large-size well-known open-source java projects:
Xerces-J,7 JFreeChart,8 GanttProject,9 ArtOfIllusion,10 and JHotDraw.11 Xerces-J is a family of software packages for parsing XML.
JFreeChart is a powerful and ﬂexible Java library for generating charts.
GanttProject is a cross-platform tool for project scheduling. JHotDraw
is a GUI framework for drawing editors. Finally, Art of Illusion is a 3Dmodeller, renderer and raytracer written in Java.
Table 3 provides some descriptive statistics about these ﬁve software systems. We selected these systems for our validation because
they range from medium to large-sized open-source projects, whichhave been actively developed over the past 10 years, and their design
has not been responsible for a slowdown of their development. In
addition, these systems are well studied in the literature, and theircode-smells have been detected and analyzed manually (Moha et al.,2010; Kessentini et al., 2010, 2011; Ouni et al., 2013a). In these corpuses, the four following code smell types were considered: Blob (alarge class that monopolizes the behavior of a system or part of it,
and the other classes primarily encapsulate data); Data Class (a classthat contains only data and performs no processing on these data);
Spaghetti Code (code with a complex and tangled control structure)and Functional Decomposition (when a class performs a single function, rather than being an encapsulation of data and functionality).
We chose these code-smell types in our experiments because they
are among the most common ones that are detected and corrected
in recent studies and existing corpuses (Kessentini et al., 2010, 2011;
Ouni et al., 2013a; Moha et al., 2010).
To collect refactorings applied in previous versions of the studied
systems, we use Ref-Finder (Prete et al., 2010). Ref-Finder is a tool
implemented as an Eclipse plug-in that identiﬁes refactoring operations between two consecutive releases of a software system. Table 4shows the analyzed versions and the number of refactoring operations collected using Ref-Finder between each subsequent couple ofanalyzed versions, after a manual validation. In our study, we consider
only the set of refactoring types described in Table 2.

7

http://xerces.apache.org/xerces-j/.
http://www.jfree.org/jfreechart/.
9
www.ganttproject.biz.
10
www.artoﬁllusion.org/.
11
http://www.jhotdraw.org/.
8

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

5.2.2. Analysis method
We designed our experiments to answer our research questions.
To answer RQ1, we conduct a qualitative and quantitative evaluation
to evaluate the eﬃciency of our approach.
5.2.2.1. Qualitative evaluation. To evaluate the usefulness of the suggested refactorings, we performed a qualitative evaluation with three
Ph.D. students in Software Engineering; two of whom are working at
General Motors as senior software engineers. The subjects have an
average of 6.5 years programming experience in Java and familiar
with the ﬁve studied systems. We asked the participants to manually evaluate, for each system, a sample of 10 refactoring operations
that are selected at random from the suggested refactoring solutions.
To this end, we asked them to apply the proposed refactorings using Eclipse12 and check the semantic coherence of the modiﬁed codefragments. When a construct semantic incoherency is found manually, participants consider the refactorings related to this change as abad recommendation. In this setting, participants assign a meaningfulness score in the range [0, 5] for each refactoring according to its
coherence with the program semantics. We consider a refactoring operation as meaningful if its assigned score is greater than or equal to 3.
Participants were aware that they are going to evaluate the semantic
coherence of refactoring solutions, but do not know the particular experimental research questions (the approaches and algorithms being
compared). To this end, we deﬁne the metric refactoring meaningfulness (RM) that corresponds to the number of meaningful refactoring
operations, in terms of construct semantic coherence, over the total
number of evaluated refactorings. RM is given by Eq. (9).

RM =# meaningf ul ref actorings# evaluated ref actorings(9)

5.2.2.2. Quantitative evaluation. To answer RQ1.∗, we used mainly
two performance indicators to compare the different algorithms
used in our experiments. When comparing two mono-objective algorithms, it is usual to compare their best solutions found so far during the optimization process. However, this is not applicable whencomparing two multi-objective evolutionary algorithms since eachof them gives as output a set of non-dominated (Pareto equivalent)solutions. Different metrics for measuring the performance of multiobjective optimization methods exist. Zitzler et al. (2003) provide acomprehensive review of quality indicators for multi-objective optimization, ﬁnding that many commonly used metrics do not reliably
reﬂect the performance of an optimization algorithm. One of the few
recommended metrics is the Hypervolume and the Spread indicators.
- Hypervolume (HV): This metric calculates the proportion of thevolume covered by members of a non-dominated solution set
returned by the algorithm. A higher Hypervolume value means
better performance, as it indicates solutions closer to the optimal
Pareto Front. The most interesting features of this indicator are
its Pareto dominance compliance and its ability to capture bothconvergence and diversity.
- Spread (): It measures the distribution of solutions into a given
front. The idea behind the spread indicator is to evaluate diversity among non-dominated solutions. An ideal distribution has
zero value for this metric when the solutions are uniformly distributed. An algorithm that achieves a smaller value for Spreadcan get a better diverse set of non-dominated solutions. For further details about the formulation of these indicators, please refer
to Deb (2009) and Zitzler et al. (2003).
In addition to these two multi-objective performance evaluation
measures, we used other metrics to assess the eﬃciency and the usefulness of our approach and to compare mono-objective and multiobjective approaches.
12

http://www.eclipse.org/.

31

To answer RQ2, we compare the refactoring results in terms ofcode-smells correction ratio in the situation where the change history
is available and where it is not. To this end, we deﬁne the metric codesmells correction ratio (CCR). CCR is given by Eq. (10) and calculates
the number of corrected code-smells over the total number of codesmells detected before applying the proposed refactoring sequence.

CCR =# corrected code_smells∈ [0, 1]# code_smells bef ore applying ref actorings(10)

To answer RQ3, we also consider both cases where the refactoringhistory is available and where it is not available. We used mainly aqualitative validation based on the refactoring meaningfulness (RM)
as described in Eq. (9). To this end, we perform a ﬁve-fold cross validation. Each fold consists of a set of refactorings collected from foursystems as a base of historical refactorings and the remaining system as the test system (we consider that its development history
is not available). In other words, we execute our approach on thissystem while calculating the cross-project refactoring similarity withthe other four projects. In this setting, the higher the RM metric is,
the more the change history from other projects in similar context is
useful.
To answer RQ4, we compared our refactoring results to those produced by three state-of-the-art approaches (Harman and Tratt, 2007;
Kessentini et al., 2011; Ouni et al., 2012). Harman and Tratt (2007) proposed a multi-objective approach that uses two quality metrics (coupling between objects, and standard deviation of methods per class)to improve after applying the refactorings sequence. In Kessentini
et al. (2011), a single-objective genetic algorithm is used to correct
code-smells by ﬁnding the best refactoring sequence that reduces thenumber of code-smells. Ouni et al. (2012) have proposed a new multiobjective refactoring to ﬁnd the best compromise between quality
improvement and semantic coherence using two heuristics related
to the vocabulary similarity and structural coupling. In all contributions, the development history is not used explicitly. We evaluate theeﬃciency of our refactoring solutions in producing more coherentchanges than those produced by Harman and Tratt (2007), Kessentini
et al. (2011), and, Ouni et al. (2013a).
Finally, to answer RQ5, we assess the beneﬁt of the suggested
refactoring solutions on software quality. Thus, although our primary
goal in this work is to demonstrate that code-smells can be automatically refactored using change history information, it is also important
to assess the refactoring impact on the design quality. The expected
beneﬁt from refactoring is to enhance the overall software design
quality as well as ﬁxing code-smells (Fowler et al., 1999). We use the
QMOOD (quality model for object-oriented design) model (Bansiya
and Davis, 2002) to estimate the effect of the suggested refactoring
solutions on quality attributes. We choose QMOOD, mainly because(1) it is widely used in the literature (O’Keeffe and Cinnéide, 2006;
Jensen and Cheng, 2010; Seng et al., 2006) to assess the effect of
refactoring, and (2) it has the advantage that deﬁne six high level
design quality attributes (reusability, ﬂexibility, understandability,
functionality, extendibility, and effectiveness) that are calculated using 11 lower level design metrics (Bansiya and Davis, 2002). In ourstudy we consider the following quality attributes:
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
modiﬁed for use in applications or environments other than thosefor which it was speciﬁcally designed.
• Understandability: The properties of designs that enable it to beeasily learned and comprehended. This directly relates to the complexity of design structure.
•

32

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

Table 5QMOOD quality factors (Bansiya and Davis, 2002).
Quality attribute

Quality index calculation

Reusability
Flexibility
Understandability= −0.25 ∗ DCC + 0.25 ∗ CAM + 0.5 ∗ CIS + 0.5 ∗ DSC= 0.25 ∗ DAM − 0.25 ∗ DCC + 0.5 ∗ MOA + 0.5 ∗ NOP= −0.33 ∗ ANA + 0.33 ∗ DAM − 0.33 ∗ DCC + 0.33 ∗ = CAM− 0.33 ∗ NOP + 0.33 ∗ NOM − 0.33 ∗ DSC= 0.2 ∗ ANA + 0.2 ∗ DAM + 0.2 ∗ MOA + 0.2 ∗ MFA + 0.2 ∗NOP

Effectiveness

Table 6QMOOD quality metrics for design properties.

•

Design property

MetricDescription

Design size
Complexity
Coupling
Polymorphism
Hierarchies
Cohesion
Abstraction
Encapsulation
Composition
Inheritance
Messaging

DSC
NOM
DCC
NOP
NOH
CAM
ANA
DAM
MOA
MFA
CIS

Design size in classes
Number of methods
Direct class coupling
Number of polymorphic methods
Number of hierarchies
Cohesion among methods in class
Average number of ancestors
Data access metricMeasure of aggregation
Measure of functional abstraction
Class interface size

bestSoln−1= M ini=0(1 − Quality[i])2 + (1 − Semantic[i])2 + +(1 − ContextSimilarity[i])2(12)

where n is the number of solutions in the Pareto front returned by
NSGA-II.
5.3. Experimental results

Effectiveness: The degree to which a design is able to achieve thedesired functionality and behavior using OO design concepts andtechniques.

We did not assess the functionality factor because we assume that,by deﬁnition, refactoring does not change the behavior/functionalityof systems; instead it changes the internal structure. We have also
excluded the extendibility factor because it is relatively a subjective
quality factor; and, still, using a model of merely static measures toevaluate extendibility is inadequate. Tables 5 and 6 summarize the
QMOOD formulation of these quality attributes (Bansiya and Davis,
2002). For space reasons, we omit references for the metric deﬁnitions.
The quality gain is calculated by comparing each of the quality
attributes values before and after refactoring independently to thenumber of ﬁxed code-smells. Hence, the total gain in quality G foreach of the considered QMOOD quality attributes qi before and after
refactoring can be estimated as:

Gqi = qi − qimagnitude. In order to quantify the latter, we compute the effectsize by using the Cohen’s d statistic (Cohen, 1988). The effect size isconsidered: (1) small if 0.2  d < 0.5, (2) medium if 0.5  d < 0.8, or(3) large if d  0.8.
Furthermore, as for our evaluation we need to select only one
solution from the entire Pareto front, with the same manner for
all the trial runs, we use a technique similar to the one describedin Ouni et al. (2013a). Eq. (12) is used to choose the solution that
corresponds of the best compromise between our three objectivefunctions: quality, semantic coherence, and context similarity. In ourcase the ideal solution has the best quality value (equals to 1), thebest semantic coherence value (equals to 1), and the highest context similarity value (equals to 1 after normalization). Hence, we
select the nearest solution to the ideal point in terms of Euclidian
distance.

(11)

where q’ and qi represent the value of the quality attribute i respectively after and before refactoring.
5.2.3. Used inferential statistical methodology
Due to the stochastic nature of the algorithms/approaches weare studying, they can provide different results for the same problem instance from one run to another. To cater for this issue and to
make inferential statistical claims, our experimental study is performed based on 31 independent simulation runs for each algorithm/technique studied. The obtained results are statistically analyzed using the Wilcoxon rank sum test (Arcuri and Briand, 2011)
with a 95% conﬁdence level (α = 5%). Wilcoxon rank sum test (Arcuri
and Briand, 2011) is applied between NSGA-II and each of the otheralgorithms/techniques (Kessentini et al., 2011, Ouni et al., 2012, GA,
MOGA, and random search) in terms of CCR. Our tests show that theobtained results are statistically signiﬁcant with p-value<0.05.
In the result reported in this paper, we are considering the medianvalue for each approach through 31 independent runs. The Wilcoxon
rank sum test allows verifying whether the results are statisticallydifferent or not, however it does not give an idea about the differenceThis section describes and discusses the results obtained for thedifferent research questions of Section 5.1.
Results for RQ1 (SBSE validation): For the ﬁrst research question RQ1.1, we describe the obtained results in terms of the two used
quality indicators: Hypervolume (HV) and Spread (). For the HV, thehigher the value is, the better is the quality of the obtained results.
Fig. 7 describes our ﬁnding through 31 runs of NSGA-II, MOGA, andrandom search. According to the obtained results in Fig. 7(a), random search results are generally poor, whereas NSGA-II and MOGA
obtain good results for all the ﬁve systems. Moreover, as illustrated
in Fig. 7(a), NSGA-II signiﬁcantly outperforms MOGA when applied
to Xerces, GanttProject, and JHotDraw while presenting comparable
performance for JFreeChart and ArtOfIllusion. This provides evidence
the effectiveness of NSGA-II over MOGA in ﬁnding a well-converged
and well-diversiﬁed set of Pareto-optimal refactoring solutions. For
the , it is also desired that a multi-objective evolutionary algorithm
maintains a good spread of solutions in the obtained set of solutions.
Fig. 7(b) shows that NSGA-II has the better spread among all the othersearch-based algorithms in all systems.
To summarize, the Wilcoxon rank sum test showed that in 31 runs,
both NSGA-II and MOGA results were signiﬁcantly better than random
search. We conclude that there is an empirical evidence that ourmulti-objective formulation surpasses the performance of random
search thus our formulation is adequate (this answers RQ1.1).
Another element that should be considered when comparing theresults of the three algorithms is that multi-objective evolutionary
algorithms do not produce a single solution like GA, but a set of optimal solutions (non-dominated solutions). The maintainer can choosea solution from them depending on his preferences in terms of compromise. However, at least for our evaluation, we need to select only
one solution. To make the comparison fair, we use Eq. (12) as described in Section 5.2.3 to automatically select a candidate solution
from the Pareto front.
To answer the next research question, RQ1.2, we ﬁrst compared
NSGA-II to another widely used multi-objective algorithm, MOGA, using the same adapted ﬁtness functions, solution representation, andgenetic operators. Then, to answer RQ1.3 we compared NSGA-II toa widely used single-objective evolutionary algorithm, genetic algorithm (GA), using a single ﬁtness function that calculates the averageof the three measures we use (quality, construct semantics preservation, and development history reuse). Fig. 8 reports the comparison results between NSGA-II, MOGA and GA in terms of CCR and RM

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

33

Fig. 7. Boxplots using the quality measures (a) HV, and (b) spread applied to NSGA-II, MOGA, and random search through 31 independent runs.

median values representing obtained over 31 independent simulation
runs of the three algorithms. The Wilcoxon test provides evidence
that all the CCR and RM values obtained employing NSGA-II weresigniﬁcantly better than those obtained with each of MOGA. Fig. 8
shows that both NSGA-II and MOGA provide the best results regarding the CCR and RM metrics. Moreover, NSGA-II outperforms MOGA in
most of the cases for both CCR and RM. MOGA outperforms the NSGAII approach only in GanttProject in terms of CCR, which is the smallest
open source system considered in our experiments, having the lowest number of ﬁxed code-smells (89% of CCR for MOGA, only 87% for
NSGA-II), so it appears that MOGA’s search operators make a bettertask of working with a smaller search space. In terms of refactoring
meaningfulness (RM), our experiments reported in Fig. 8b provides
evidence that NSGA-II gives better results for the ﬁve systems withan average of 86%, whereas only 76% and 70% are obtained for MOGA
and GA respectively. In addition, NSGA-II outperforms MOGA in termsof both performance indicators HV and  as illustrated in Fig. 7. Regarding HV, NSGA-II outperforms signiﬁcantly MOGA in three out ofﬁve systems. For the  indicator, NSGA-II outperforms MOGA in all
studied systems.
Results for RQ2 (Eﬃciency): Fig. 9 presents the obtained results. We observe that the majority of suggested refactorings by ourapproach (where the change history is not available) succeeded in
improving signiﬁcantly the code quality with good correction scores(an average of 85% of detected code-smells was ﬁxed for all the ﬁvesystems). These results are comparable to the ones obtained by theoriginal approach where the change history is available (an average of
84% for all systems). We observe that our approach achieved slightly
superior CCR values with respect to the original approach in two out
ﬁve projects, and identical results in one out of ﬁve projects. For instance, for GanttProject, both approaches provides identical resultswith 90% of CCR score; while for JHotDraw, our approach provides
slightly better CCR results (88%) comparing to the original approachhaving a CCR score of 81%.
As interesting observation from the results of Fig. 9 is that the
CCR medians are close, the results are statistically different but theeffect size (Cohen, 1988) which quantiﬁes the difference is small for
most of the systems considered in our experiments. The Wilcoxon
rank sum test allows verifying whether the results are statisticallydifferent or not. However, it does not give any idea about the difference magnitude. The statistical analysis of the obtained results
provides evidence that the cross-project similarity did not have a signiﬁcant effect on CCR on almost all systems, especially for medium
and large systems.
Results for RQ3 (Usefulness): Fig. 10 reports the obtained resultsof the RM values for our approach (using cross-project similarity) andthe original one (when the change history is available). For this evaluation measurement, our approach achieved similar results comparing
to the original one. In three systems, there were identical distributions between both approaches (i.e., on the systems ArtOfIllusion,

34

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

Fig. 8. (a) CCR and (b) RM median values of 31 independent runs of NSGA-II, MOGA, and GA.

Fig. 9. CCR median values of 31 independent runs of our approach where the change
history is not available and the original one where the change history is available.

Fig. 10. RM values of our approach where the change history is not available comparing
to the original approach where the change history is available.

GanttProject, and Xerces), while only in two systems (i.e., JHotDraw
and JFreeChart) there was a signiﬁcant differences found but small
effect size.

In average, over 31 independent runs, our approach utilizing crossproject similarity achieved 86% of RM, while our original approachachieved 90% of RM for all the projects.

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39
Table 7
CCR median values of 31 independent runs, and RM values.
Systems

Approach

CCR

RM

Xerces-J

Our approach
Ouni et al. (ICSM 2012)
Harman et al. (2007)
Kessentini et al. (2011)

80% (70|87)
78% (68|87)
N.A.
90% (78|87)

90%
80%
60%
60%

JFreeChart

Our approach
Ouni et al. (ICSM 2012)
Harman et al. (2007)
Our approach

83% (70|84)85% (71|84)
N.A.
89% (75|84)

80%
80%
60%
50%

GanttProject

NSGA-II (our approach using
context)
Ouni et al. (ICSM 2012)
Harman et al. (2007)
Kessentini et al. (2011)

87% (39|45)90%89% (40|45)
N.A.
93% (42|45)

80%
60%
60%

ArtofIllusion

Our approach
Ouni et al. (ICSM 2012)
Harman et al. (2007)
Kessentini et al. (2011)

87% (59|68)
87% (59|68)
N.A.
90% (61|68)

80%
70%
50%
50%

JHotDraw

Our approach
Ouni et al. (ICSM 2012)
Harman et al. (2007)
Kessentini et al. (2011)

88% (14|16)
81% (13|16)
N.A.
81% (13|16)

90%
80%
50%
50%

Average values
for all systems

Our approach
Ouni et al. (ICSM 2012)
Harman et al. (2007)
Kessentini et al. (2011)

85%
84%
N.A.
88%

86%
78%
58%
54%

Based on the results of Fig. 10, we noticed that RM medians areclose, the results are statistically different but the effect size (Cohen,1988) which quantiﬁes the difference is small for most of the systems
considered in our experiments.
This slight degradation might due to the nature of the studied
projects coming from different sizes, different code-smell distributions, and different development teams. That is the same set ofcode-smell types that we are considering in our experiments (blob,spaghetti code, functional decomposition, and data classes) are detected in all the studied projects but with different distributions;consequently such regularities cannot be easily found. Furthermore,in general, from a software engineer stand point, there are no common practices on how refactoring is applied or decided; this depends
mainly on the opinion/decision of the developer. For instance to ﬁx
a blob class, a programmer may refer to many possible alternatives
refactorings such as move method, move ﬁeld or extract class, etc.
(Fowler et al., 1999). Hence, lower RM score is obtained for JHotDraw,
this might be due to the fact that JHotDraw is a relatively mature andwell-designed and implemented system after more than 10 years ofactive development, and which have much less code-smell instances
comparing to the other projects.
To sum up, despite this slight degradation in terms of RM theobtained results with cross-project similarity are considered as good
(86% for all ﬁve systems). We can conclude that, despite the nonavailability of change history such collected data from other projects
can be a valuable knowledge for recommending software refactoring.
Results for RQ4 (Comparison to state-of-the-art): We compare
our approach with three existing approaches: Ouni et al. (2012),
Kessentini et al. (2011), and Harman et al. (2007). Table 7 presents
the obtained results. We observe that our approach achieved muchbetter results comparing to the three other approaches in terms of
RM. Overall, of all the ﬁve studied projects, our approach provides
86% RM, while Ouni et al., Kessentini et al., and Harman et al., provide
only 78%, 58% and 54% respectively. For instance, for Xerces-J, 90% (9out of 10) of the evaluated refactoring operations by our participants
do not generate construct semantic incoherencies, while the otherapproaches achieved respectively 80%, 60% and 60% of RM.

35

Using historical software changes, our approach succeeded inproposing more meaningful refactorings and reducing the numberof construct semantic incoherencies when applying refactoring. At
the same time, after applying the proposed refactoring operations,
we found that most of the detected code-smells are ﬁxed with anaverage of 85% of CCR. The corrected code-smells were from different types (blob, spaghetti code, functional decomposition, and dataclasses (Ouni et al., 2013a)). The majority of non-ﬁxed code-smells
are related to the blob type. This type of code-smell usually requiresa large number of refactoring operations and is then very diﬃcult tocorrect. This obtained correction score is comparable to the one ofother existing approaches that do not use development history (89%).
Thus, the slight loss in the CCR is largely compensated by the significant improvement of the construct semantic coherence. In addition,
this slight loss in terms of CCR can be justiﬁed by the nature of the
problem under consideration; there is a kind of trade-off between
CCR and RM: when RM increase, then CCR decrease. This provides evidence that the quality of the refactoring solutions (number of ﬁxed
code-smells) is inherently in conﬂict with construct semantic. For thisreason, we used a multi-objective optimization approach instead of asingle objective one.
In conclusion, our approach provides good refactoring suggestions
from both perspectives: CCR and construct semantics coherence using
the development change history.
To sum up, the development history collected from different software projects represents a valuable knowledge that can be very usefulin improving automated software refactoring. This provides evidence
that, in the context of refactoring, eﬃcient and effective reuse is extremely important to the success of refactoring strategies. This aligns
well with software reuse principles as a common practice for softwaredevelopers to save time and efforts.
Results for RQ5 (Insights): To answer RQ5, we show in Fig. 11 theobtained quality gain values (in terms of absolute value) that we calculated for each QMOOD quality attribute before and after refactoringfor each studied system. We found that the systems quality increase
across the four QMOOD quality factors. Understandability is the quality factor that has the highest gain value; whereas the effectivenessquality factor has the lowest one. This mainly due to many reasons(1) the majority of ﬁxed code-smells (blob, spaghetti code) are known
to increase the coupling (DCC) within classes which heavily affect
the quality index calculation of the effectiveness factor; (2) the vast
majority of suggested refactoring types were move method, moveﬁeld, and extract class (Fig. 11) that are known to have a high impact on coupling (DCC), cohesion (CAM) and the design size in classes(DSC) that serves to calculate the understandability quality factor.
Furthermore, we noticed that JHotDraw produced the lowest quality
increase for the four quality factors. This is justiﬁed by the fact that
JHotDraw is known to be of good design and implementation practices (Kessentini et al., 2010) and contains few number of code-smells
comparing to the four other studied systems.
To sum up, we can conclude that our approach succeeded in improving the code quality not only by ﬁxing the majority of detected
code-smells but also by improving the user understandability, thereusability, the ﬂexibility, as well as the effectiveness of the refactored program.
6. Discussions
We noticed that our approach outperforms the other approaches
that do not use development history for ﬁxing code-smells and construct semantic coherence. Moreover, we had promising refactoring results even when the development history is not available andonly similar collected refactorings applied to similar contexts is used.
We also found that our NSGA-II based approach performs much better than two other popular multi and mono-objective evolutionary

36

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

Fig. 11. The impact of best refactoring solutions on QMOOD quality attributes.

RM (%), CCR(%), Dev. History (%)

Time (min)

100
95
90
85
80
75
70
65
60
55
50

59
57
55
53
51

the idea is to move elements from the blob class to other classes (e.g.,
data classes) in order to reduce the number of functionalities fromthe blob and add behavior to other classes (mainly data classes) or
to improve some quality metrics such as coupling and cohesion (related to spaghetti code). As such, refactorings like move ﬁeld, movemethod, and extract class are likely to be more useful to ﬁx the blob,and data class code-smells.

49
47

7. Threats to validity

45

210 211 224 226 234 237 241 245 257 259 280 284 287 311 316 327
Number of refactorings
RP (%)CCR (%)Development history reuse (%)

Time (min)Fig. 12. Impact of the number of refactorings on multiple simulation runs on Xerces-J.

algorithms: MOGA, and GA in terms of Hypervolume, Spread, CCR,
and RM. We also studied the results of multiple executions with theexecution time to evaluate the performance and the stability of ourapproach. Over 31 independent simulation runs on Xerces-J, the average value of RM, CCR, development history reuse and execution
time for ﬁnding the optimal refactoring solution with a number of
iterations (stopping criteria) ﬁxed to 8000 was respectively 90%, 82%,
73% and 47min85s as shown in Fig. 12. The standard deviation values
were lower than 2, except for development history reuse (2.36). This
indicates that our approach is reasonably scalable from the performance standpoint. Moreover, we evaluate the impact of the numberof suggested refactorings on the RM, development history reuse, andCCR scores in 31 different executions. The best RMand CCR scores arealso obtained with a higher number of suggested refactorings. Thus,
we could conclude that our approach is scalable from the performance standpoint, especially that quality improvement is not related
in general to real-time applications where time-constraints are very
important. In addition, the results’ accuracy is not affected by the
number of suggested refactorings.
Another important consideration is the refactoring operations’ distribution. We contrast that most of the suggested refactorings are related to move method, move ﬁeld, and extract class for almost all thestudied systems. For instance, in GanttProject, we had different distribution of different refactoring types as illustrated in Fig. 13. We noticethat the most suggested refactorings are related to moving code elements (ﬁelds, methods) and extract/inline class. This is mainly due tothe speciﬁc code-smells types detected in GanttProject. Most of thecode-smells are related to the blob, data classes, and spaghetti codethat need particular refactorings. For instance, to ﬁx a blob code-smell,

Some threats need to be considered when interpreting our study
results.
The ﬁrst threat concerns the conclusion validity. We used the
Wilcoxon rank sum test with a 95% conﬁdence level to test if signiﬁcant differences existed between the measurements for different
treatments. This test makes no assumption that the data is normally
distributed and is suitable for ordinal data, so we can be conﬁdent
that the statistical relationships we observed are signiﬁcant. For theinternal validity, the used a technique for detecting code-smells maylead to a few number of false positives; this may have an impact on
the results of our experiments.
External validity refers to the generalizability of our ﬁndings. In
this study, we performed our experiments on several different widelyused open-source systems belonging to different domains and withdifferent sizes. However, we cannot assert that our results can begeneralized to industrial Java applications, other programming languages, and to other practitioners. Another threat can be the limited
number of subjects and studied systems, which externally threatens
the generalizability of our results. Future replications of this study arenecessary to conﬁrm our ﬁndings.
Construct validity is concerned with the relationship between theory and what is observed. The manual evaluation of suggested refactorings depends on the expertise of the subjects involved in our experiments. Another threat concerns the data about the collected refactorings of the studied systems where we use Ref-Finder, which is known
to be eﬃcient. Indeed, Ref-Finder was able to detect refactoring operations with an average recall of 95% and an average precision of 79%.
(Prete et al., 2010).To ensure the precision, we manually inspect andﬁlter the set of refactorings found by Ref-Finder.
8. Conclusions and future work
In this paper, we presented a novel search-based approach to improve the automation of refactoring. We used software-development
history, combined with structural and semantic information, toA. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

Number of Refactorings

Number of Refactorings

100
80
60
40
20

80
60
40
20
0

0

1 2 3 4 5 6 7 8 9 10 11

1 2 3 4 5 6 7 8 9 10 11(b) JFreeChart
Number of Refactorings

Number of Refactorings(a) Xerces-J
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11(c) GanttProject

100
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11(d) ArtOfIllusion

50
Number of Refactorings

37

1. Move method
2. Move field
3. Extract class
4. Inline class
5. Extract interface
6. Move class
7. Pull up field
8. Pull up method
9. Push down method
10. Push down field
11. Other refactorings

40
30
20
10
0
1 2 3 4 5 6 7 8 9 10 11(e) JHotDraw

Fig. 13. Suggested refactorings distribution.

improve the precision and eﬃciency of new refactoring suggestions.
We start by generating some solutions that represent a combinationof refactoring operations to apply. A ﬁtness function combines threeobjectives: maximizing design quality, construct semantic preservation and the re-use of the history of changes applied to similar
contexts.
To ﬁnd the best trade-off between these objectives, NSGA-II algorithm is used. We found promising refactoring results, on a set of
5 open source systems, even when the development history is notavailable, and only similarity collected refactorings applied to similar
contexts is used. Moreover, to evaluate the feasibility and eﬃciencyof our approach, we applied three state-of-the-art multi and monoobjective metaheuristics (MOGA, Random Search, and GA) for the
refactoring problem using the same adaptation (solution coding, genetic operators, ﬁtness functions). We found that our NSGA-II based
approach has been the one computing the best results regarding to
two performance indicators (Hypervolume and Spread) over a benchmark composed of ﬁve open-source software systems. Moreover, ourapproach outperforms signiﬁcantly three state-of-the-art refactoring
approaches (Kessentini et al., 2011; Harman and Tratt, 2007; Ouni
et al., 2012) in terms of code-smells correction ratio, and constructsemantic coherence.
As part of our future work, we will extend our validation to include additional systems and code-smell types to ﬁx and compare
our NSGA-II approach with other existing refactoring approaches(O’Keeffe and Cinnéide, 2006; Seng et al., 2006). An interesting future
direction to our work would be the investigation of a new strategy
where both good and bad changes recorded in the past will be considered. The aim is to maximize the dissimilarity with bad changes
applied in the past and maximize the similarity with good ones.

Furthermore, another research direction worth to explore is to investigate the effect of code-smells correction on the number of faults
on the system. Indeed, recent empirical studies (Hall et al., 2014;
D’Ambros et al., 2010) have found that code-smells do correlate with
software defects, and an increase in the number of code-smells is
likely to generate bugs (D’Ambros et al., 2010). Other studies havefound that some code-smells do indicate fault-prone code in somecircumstances but the effect that these smells have on faults is small(Hall et al., 2014). While based on some empirical studies ﬁxing codesmells is likely to reduce implicitly faults, it will be interesting toinvestigate, as future work, whether ﬁxing code-smells through refactoring can reduce the number of faults.
Acknowledgements
This work is partially supported by Japan Society for the Promotionof Science, Grant-in-Aid for Scientiﬁc Research (S) (No. 25220003),
and also by Osaka University Program for Promoting International
Joint Research.
References
Arcuri, A., Briand, L.C., 2011. A practical guide for using statistical tests to assess randomized algorithms in software engineering. In: Proceedings of the 33rd International
Conference on Software Engineering. ACM, New York, NY, USA, pp. 1–10.
Bansiya, J., Davis, C.G., 2002. A hierarchical model for object-oriented design quality
assessment. IEEE Trans. Softw. Eng. 28 (1), 4–17.
Beyer, D., Noack, A., 2005. Clustering software artifacts based on frequent common
changes. In: Proceedings of the 13th International Workshop on Program Comprehension. St. Louis, MO, USA, pp. 259–268.
Briand, L.C., Daly, J.W., Wust, J.K., 1999. A uniﬁed framework for coupling measurementin object-oriented systems. IEEE Trans. Softw. Eng. 25 (1), 91–121.

38

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39

Brown, W.J., Malveau, R.C., Brown, W.H., III, H.W.M., Mowbray, T.J., 1998. Anti Patterns:
Refactoring Software, Architectures, and Projects in Crisis, 1st edition John Wileyand Sons.
Cederqvist, P., Dec. 2003. Version Management with CVS, www.cvshome.org/
docs/manual/.
Chidamber, S.R., Kemerer, C.F., 1994. A metrics suite for object-oriented design. IEEE
Trans. Softw. Eng. 20 (6), 293–318.
Choinzon, M., Ueda, Y., 2006. Detecting defects in object oriented designs using design metrics. In: Proceedings of the 7th conference on Knowledge-Based Software
Engineering. Amsterdam, The Netherlands, pp. 61–72.
Coad, P., Yourdon, E., 1991. Object-Oriented Design. Prentice Hall.
Cohen, J., 1988. Statistical Power Analysis for the Behavioral Sciences Evanston. Routledge, IL, USA.
D’Ambros, M., Bacchelli, A., Lanza, M., 2010. On the impact of design ﬂaws on software
defects. In: International Conference on Quality Software.
Deb, K., 2009. Multi-Objective Optimization Using Evolutionary Algorithms. Wiley.
Deb, K., Pratap, A., Agarwal, S., Meyarivan, T., 2002. A fast and elitist multiobjective
genetic algorithm: NSGA-II, IEEE Trans. Evol. Comput. 6, 182–197.
Deligiannis, I., Shepperd, M., Roumeliotis, M., Stamelos, I., 2003. An empirical investigation of an object-oriented design heuristic for maintainability. J. Syst. Softw. 65,
127–139.
Deligiannis, I., Stamelos, I., Angelis, L., Roumeliotis, M., Shepperd, M., 2004. A controlled
experiment investigation of an object-oriented design heuristic for maintainability.
J. Syst. Softw. 72, 129–143.
Du Bois, B., Demeyer, S., Verelst, J., 2004. Refactoring—improving coupling and cohesion of existing code. In: Proceedings of the 11th Working Conference on Reverse
Engineering. Tampere, Finland, pp. 144–151.
Ekman, T., Asklund, U., 2004. Refactoring-aware versioning in eclipse. Electron. Notes
Theor. Comput. Sci. 207, 57–69.
Fatiregun, D., Harman, M., Hierons, R., 2004. Evolving transformation sequences using
genetic algorithms. In: 4th IEEE International Workshop on Source Code Analysis
and Manipulation. Los Alamitos, California, USA, pp. 65–74.
Fonseca, C.M., Fleming, P.J., 1993. Genetic algorithms for multiobjective optimization:
formulation, discussion and generalization. In: Proceedings of the 5th International
Conference on Genetic Algorithms. San Mateo, CA, USA, pp. 416–423.
Fowler, M., Beck, K., Brant, J., Opdyke, W., Roberts, D., 1999. Refactoring – Improving
the Design of Existing Code, 1st ed. Addison-Wesley.
Gall, H., Hajek, K., Jazayeri, M., 1998. Detection of logical coupling based on productrelease history. In: Proceedings of the International Conference on Software Maintenance. Los Alamitos, CA, pp. 190–198.
Gîrba, T., Ducasse, S., Kuhn, A., Marinescu, R., Daniel, R., 2007. Using concept analysis todetect co-change patterns. In: Proceedings of International Workshop on Principlesof Software Evolution. Dubrovnik, Croatia, pp. 83–89.
Hall, T., Zhang, M., Bowes, D., Sun, Y., 2014. Some code smells have a signiﬁcant but
small effect on faults. ACM Trans. Softw. Eng. Methodol. 23 (4(33)).
Harman, M., Tratt, L., 2007. Pareto optimal search based refactoring at the design level.
In: Proceedings of the Genetic and Evolutionary Computation Conference. London,
UK, pp. 1106–1113.
Hassan, A., Holt, R., 2004. Predicting change propagation in software systems. In: Proceedings 20th International Conference on Software Maintenance. Chicago, Illinois,
USA, pp. 284–293.
Infusion hydrogen, (2012): Design ﬂaw detection tool. Available at:
http://www.intooitus.com/products/infusion.
iPlasma (0000): http://loose.upt.ro/iplasma/index.html.
Jensen, A., Cheng, B., 2010. On the use of genetic programming for automated refactoring and the introduction of design patterns. In: Proceedings of the 12th annual
conference on Genetic and evolutionary computation. Portland, Oregon, pp. 1341–
1348.
Joshi, P., Joshi, R.K., 2009. Concept analysis for class cohesion. In: Proceedings of the 13th
European Conference on Software Maintenance and Reengineering. Kaiserslautern,
Germany, pp. 237–240.
Kagdi, H.H., Collard, M.L., Maletic, J.I., 2007. A survey and taxonomy of approaches
for mining software repositories in the context of software evolution. J. Softw.
Mainten. 19 (2), 77–131.
Kataoka, Y., Ernst, M.D., Griswold, W.G., Notkin, D., 2001. Automated support for program refactoring using invariants. In: International Conference on Software Maintenance. Florence, Italy, pp. 736–743.
Kessentini, M., Kessentini, W., Sahraoui, H., Boukadoum, M., Ouni, A., 2011. Design
defects detection and correction by example. In: Proc. of the 19th IEEE Int. Conf. on
Program Comprehension. Kingston, ON, Canada, pp. 81–90.
Kessentini, M., Vaucher, S., Sahraoui, H., 2010. Deviance from perfection is a better
criterion than closeness to evil when identifying risky code. In: Proceedings of theInternational Conference on Automated Software Engineering. Lawrence, Kansas,
USA, pp. 113–122.
Khomh, F., Penta, M.D., Gueheneuc, Y.-G., 2009. An exploratory study of the impact
of code smells on software change-proneness. In: Proceedings of the 16th IEEE
Working Conference on Reverse Engineering. Kaiserslautern, Germany, pp. 75–84.
Kilic, H., Koc, E., Cereci, I., 2011. Search-based parallel refactoring using populationbased direct approaches. In: Proceedings of the 3rd international Symposium on
Search Based Software Engineering. Szeged, Hungary, pp. 271–272.
Kim, M., Notkin, Grossman, D., Wilson, D., Jr, G., 2013. Identifying and summarizing systematic code changes via rule inference. IEEE Trans. Softw. Eng. 39 (1),45–62.
Li, W., Shatnawi, R., 2007. An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution. J. Syst. Softw. 80, 1120–
1128.

Mäntylä, M.V., Vanhanen, J., Lassenius, C., 2003. A taxonomy and an initial empirical
study of bad smells in code. In: IEEE International Conference on Software Maintenance. Amsterdam, The Netherlands, pp. 381–384.
Marinescu, R., 2004. Detection strategies: metrics-based rules for detecting design
ﬂaws. In: Proceedings of the 20th International Conference on Software Maintenance. IEEE Computer Society Press, Chicago, Illinois, USA, pp. 350–359.
Mens, T., Demeyer, S. (Eds.), 2008. Software Evolution. Springer.
Mens, T., Tourwé, T., 2004. A survey of software refactoring. IEEE Trans. Softw. Eng. 30(2), 126–139.
Moha, N., Guéhéneuc, Y.-G., Duchien, L., Meur, A.-F.L., 2010. DECOR: A method for the
speciﬁcation and detection of code and design smells. IEEE Trans. Softw. Eng. 36(1), 20–36.
Moha, N., Hacene, A., Valtchev, P., Guéhéneuc, Y-G., 2008. Refactorings of design defects using relational concept analysis. In: Proceedings of the 4th International
Conference on Formal Concept Analysis. Montréal, QC, Canada, pp. 289–304.
Monden, A., Nakae, D., Kamiya, T., Sato, S., Matsumoto, K., 2002. Software quality analysis by code clones in industrial legacy software. In: IEEE Symposium on Software
Metrics. Ottawa, Canada, pp. 87–94.
Ó Cinnéide, M., Tratt, L., Harman, M., Counsell, S., Moghadam, I.H., 2012. Experimental
assessment of software metrics using automated refactoring. In: Proceedings of
the ACM-IEEE International Symposium on Empirical Software Engineering andManagement, pp. 49–58.
O’Keeffe, M., Cinnéide, M.O., 2006. Search-based refactoring for software maintenance.
J. Syst. Softw. 81 (4), 502–516.
Olbrich, S., Cruzes, D., Basili, V.R., Zazworka, N., 2009. The evolution and impact of code
smells: A case study of two open source systems. In: 3rd International Symposiumon Empirical Software Engineering and Measurement. Lake Buena Vista, Florida,
USA, pp. 390–400.
Olbrich, S.M., Cruzes, D.S., Sjoberg, D.I.K., 2010. Are all code smells harmful? A studyof god classes and brain classes in the evolution of three open source systems. In:
International Conference Software Maintenance. Timișoara, Romania, pp. 1–10.
Opdyke, W.F., 1992. Refactoring: A Program Restructuring Aid in Designing ObjectOriented Application Frameworks (Ph.D. thesis). University of Illinois at UrbanaChampaign.
Otero, F.E.B., Johnson, C.G., Freitas, A.A., Thompson, S.J., 2010. Refactoring in automatically generated programs. In: International Symposium on Search Based Software
Engineering. Benevento, Italy.
Ouni, A., Kessentini, M., Sahraoui, H., 2013b. Search-based refactoring using recorded
code changes. In: Proceedings of the 17th European Conference on Software Maintenance and Reengineering. Genova, Italy, pp. 221–230.
Ouni, A., Kessentini, M., Sahraoui, H., Boukadoum, M., 2013a. Maintainability defects
detection and correction: a multi-objective approach. J. Autom. Softw. Eng. 20 (1),47–79 Springer.
Ouni, A., Kessentini, M., Sahraoui, H., Hamdi, M.S., 2012. Search-based refactoring:towards semantics preservation. In: Proceedings of the 28th IEEE International
Conference on Software Maintenance (ICSM). Riva Del Garda, Italy, pp. 347–356.
Ouni, A., Kessentini, M., Sahraoui, H., Hamdi, M.S., 2013c. The use of development history in software refactoring using a multi-objective evolutionary algorithm. In: The
Genetic and Evolutionary Computation Conference. Amsterdam, The Netherlands,
pp. 1461–1468.
Poshyvanyk, D., Marcus, A., 2006. The conceptual coupling metrics for object-oriented
systems. In: In the 22nd IEEE International Conference on Software Maintenance.
Philadelphia, Pennsylvania, USA, pp. 469–478.
Prete, K., Rachatasumrit, Sudan, N., Kim, M., 2010. Template-based reconstruction ofcomplex refactorings. In: Proceedings of the International Conference on Software
Maintenance. Timișoara, Romania, pp. 1–10.
Qayum, F., Heckel, R., 2009. Local search-based refactoring as graph transformation. In:
Proceedings of 1st International Symposium on Search Based Software Engineering.
Cumberland Lodge, Windsor, UK, pp. 43–46.
Ratiu, D., Ducasse, S., Gîrba, T., Marinescu, R., 2004. Using history information to improve design ﬂaws detection. In: Proceedings of the Conference on Software Maintenance and Reengineering. Tampere, Finland, pp. 223–232.
Ratzinger, J., Sigmund, T., Vorburger, P., Gall, H., 2007. Mining software evolution to predict refactoring. In: Proceedings of the 1st International Symposium on Empirical
Software Engineering and Measurement. Madrid, Spain, pp. 354–363.
Riel, A.J., 1996. Object-Oriented Design Heuristics, 1st ed. Addison-Wesley, Boston, MA,
USA.
Sahraoui, H., Godin, R., Miceli, T., 2000. Can metrics help to bridge the gap between
the improvement of OO design quality and its automation? In: International
Conference on Software Maintenance, 2000. San Jose, California, USA, pp. 154–
162.
Seng, O., Stammel, J., Burkhart, D., 2006. Search-based determination of refactorings
for improving the class structure of object-oriented systems. In: Proceedings of the
Genetic and Evolutionary Computation Conference. Seattle, WA, USA, pp. 1909–
1916.
Sjoberg, D.I., Yamashita, A., Anda, B.C.D., Mockus, A., Dyba, T., 2013. Quantifying
the effect of code smells on maintenance effort. IEEE Trans. Softw. Eng. 39 (8),1144–1156.
Soetens, Q.D., Perez, J., Demeyer, S., 2013. An initial investigation into changebased reconstruction of ﬂoss-refactorings. In: Proceedings of the 29th IEEE
International Conference on Software Maintenance. Eindhoven, The Netherlands,
pp. 384–387.
Tahvildari, L., Kontogiannis, K., 2003. A metric-based approach to enhance design quality through meta-pattern transformation. In: Proceedings of the 7st European
Conference on Software Maintenance and Reengineering. Benevento, Italy,
pp. 183–192.

A. Ouni et al. / The Journal of Systems and Software 105 (2015) 18–39
Tsantalis, N., Chaikalis, T., Chatzigeorgiou, A., 2008. JDeodorant: identiﬁcation and removal of type-checking bad smells. In: 12th European Conference on Software
Maintenance and Reengineering. Athens, Greece, pp. 329–331.
Van Emden, E., Moonen, L., 2002. Java quality assurance by detecting code smells. In:
Proceedings of the 9th Working Conference on Reverse Engineering. Budapest,
Hungary, pp. 97–106.
Yamashita, A.F., Moonen, L., 2012. Do code smells reﬂect important maintainability
aspects? In: Proceedings of the 28th IEEE International Conference on Software
Maintenance. Riva Del Garda, Italy, pp. 306–315.
Yamashita, A.F., Moonen, L., 2013a. To what extent can maintenance problems be
predicted by code smell detection? – An empirical study. Inf. Softw. Technol. 55(12), 2223–2242.
Yamashita, A.F., Moonen, L., 2013b. Do developers care about code smells? An exploratory survey. In: the Proceedings of the 20th Working Conference on Reverse
Engineering. Genova, Italy, pp. 242–251.
Ying, T.T., Murphy, G.C., Ng, R., Chu-Carroll, M.C., 2004. Predicting source code changes
by mining change history. IEEE Trans. Softw. Eng. 30 (9), 574–586.
Zimmermann, T., Zeller, A., Weissgerber, P., Diehl, S., 2005. Mining version histories toguide software changes. IEEE Trans. Softw. Eng. 31 (6), 429–445.
Zitzler, E., Thiele, L., 1998. Multiobjective optimization using evolutionary algorithms– A comparative case study. In: Parallel Problem Solving from Nature. Springer,
Germany, pp. 292–301.
Zitzler, E., Thiele, L., Laumanns, M., Fonseca, C.M., Fonseca, da V.G., 2003. Performanceassessment of multiobjective optimizers: an analysis and review. IEEE Trans. Evol.
Comput. 7, 117–132.
Ali Ouni is a research assistant professor at Osaka University (Japan). He holds a Ph.D. in computer science from the
University of Montreal (Canada) in 2014. He is a member of
the Software Engineering Laboratory, in the graduate schoolof information science and technology at Osaka University.
He received his Master Degree Diploma (MSc.) and his bachelor degree (BSc.) in computer science from the Higher Institute of Applied Sciences and Technology (ISSAT), University of Sousse, Tunisia, respectively in 2010, and 2008. His
research interests include the application of artiﬁcial intelligence techniques to software engineering (search-based
software engineering). Since 2011, he published several papers in well-ranked journals and conferences. He serves as
program committee member and reviewer for several conferences such as GECCO 2015,
NASBASE 2015, CMSEBA 2014, GECCO 2014.
Marouane Kessentini is a tenure-track assistant professor
at University of Michigan. He is the founder of the researchgroup: Search-based Software Engineering@Michigan. He
holds a Ph.D. in Computer Science, University of Montreal (Canada), 2011. His research interests include theapplication of artiﬁcial intelligence techniques to software engineering (search-based software engineering),
software testing, model-driven engineering, software quality, and re-engineering. He has published around 50 papers in conferences, workshops, books, and journals including three best paper awards. He has served as programcommittee/organization member in several conferences
and journals.

39

Houari A. Sahraoui is full professor at the department ofcomputer science and operations research (GEODES, software engineering group) of University of Montreal. Before
joining the university, he held the position of lead researcherof the software engineering group at CRIM (Research centeron computer science, Montreal). He holds an Engineering
Diploma from the National Institute of computer science(1990), Algiers, and a Ph.D. in Computer Science, Pierre &Marie Curie University LIP6, Paris, 1995. His research interests include the application of artiﬁcial intelligence techniques to software engineering, object-oriented metrics andquality, software visualization, and re-engineering. He has
published around 100 papers in conferences, workshops,
books, and journals, edited three books, and gives regularly invited talks. He has served
as program committee member in several major conferences (IEEE ASE, ECOOP, METRICS, etc.), as member of the editorial boards of two journals, and as organization
member of many conferences and workshops (ICSM, ASE, QAOOSE, etc). He was thegeneral chair of IEEE Automated Software Engineering Conference in 2003.

Katsuro Inoue received the BE, ME, and DE degrees in information and computer sciences from Osaka University,
Japan, in 1979, 1981, and 1984, respectively. He was an assistant professor at the University of Hawaii at Manoa from1984−1986. He was a research associate at Osaka University
from 1984−1989, an assistant professor from 1989−1995,
and a professor beginning in 1995. His interests are in various topics of software engineering such as program analysis,
repository mining, software development environment, andsoftware process modeling. He is a member of the IEEE, theIEEE Computer Society, and the ACM.

Mohamed Salah Hamdi is currently an Associate Professor at Ahmed Bin Mohammed Military College (Qatar). He
earned a “Diplom-Informatiker” Degree in Computer Science from the Technical University of Munich (Germany)in 1993 and a Ph.D. Degree in Computer Science from the
University of Hamburg (Germany) in 1999. His researchinterests are focused on intelligent autonomous agents,
e-learning, information customization, effects of ICT on thesociety, software engineering, neural networks, machinelearning, and on artiﬁcial intelligence in general. He has published a large number of papers in conferences, books, andjournals. He has also served as program-committee member
in several conferences and journals.