An automatic refactoring approach to establish and maintain
quality models within the source code
Frederik Schmidt, Stephen G. MacDonell, Andrew M. Conner
SERL, Auckland University of Technology
Private Bag 92006, Auckland 1142
New Zealand
{fschmidt, stepehen.macdonell, andrew.connoer}@aut.ac.nz
Abstract
This paper describes a novel automatic refactoring approach to
establish or maintain quality goals witin the actual source code of
the software system. align the source code of software system
with user defined quality models.
A prototype has been developed and evaluated within a
quantitative experiment setup to refactor the JDepend software
systems to meet
Problems with automatic refactoring engines are that it is
complex to select a sufficient
Releated Work
A Quality Model Based Refactoring Engine
Categories and
Engineering]:
General Terms
Subject
Descriptors
D.2.7
[Software
Algorithms, Measurement, Design.
Keywords Refactoring Tool, search based software engineering,
quality models
Introduction
The erosion of software design is a pressing problem in the
software engineering discipline. The initial system design is
Systems start of with a simple design. Requirements changes and
time pressure lead into the erosion of system. Unwanted
dependencies are
One measure is the establishment and maintenance of quality
models. The introduction of quality models once substantial
erosion is evident is painful.
Hence, we believe that calculating an average value for quality
metrics does not . We rather suggests an approach, which focuses
on the
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full
citation on the first page. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee.
WRT’12 June 01, 2012, Rapperswil, Switzerland.
Copyright © 2012 ACM 1-59593-XXX-X/0X/000X…$5.00.
This section illustrates the implementation of an automatic
refactoring approach to establish or maintain a quality model
within the source code. A prototype has been developed to
evaluate the feasibility of the proposed approach. This prototype
consists of a Refactoring Engine and a Quality Goal verification
component. Figure 1 illustrates an abstraction of the activities to
realign a software system with a given source code instance.
1.1 Definition of Quality Goals
The aim of this research is to align the source code of a
software system with a defined quality goal. A quality model is
defined and the source code instance is verified with the quality
model to identify quality violations. Within the implementation of
the prototype we use the Sonar framework. Sonar offers a defined
interface and representation to access and configure quality
models. Currently, sonar is a conglomeration of various quality
and metric measurement and monitoring libraries such as
Checkstyle, PMD, Findbugs. In this configuration sonar offers to
enable about 600 coding rules and the definition of thresholds for
standard software quality metrics. Additionally, an extendable
plugin concept offers to add further metric calculations and
quality monitoring concepts. Additionally, the rules of a defined
quality model, violations and metric measurements can be
accessed via JSON, Maven, ant or via Java-API interface.
1.2 Refactoring Methods
A refactoring is a behavior obtaining transformation of the
source code. The goal of a refactoring is to create instances of the
source code, which feature improved quality such as better
understandability, reusability, encapsulation, cohesion, etc. At this
stage four refactoring have been designed to improve such
qualities of the source code. These refactorings have been
implemented with the RECODER source code transformation
framework. As a consequence the prototype allows only
refactoring of java based software systems.
The section illustrate the method of operation for these four
type of refactoring.
1.2.1 Move Method
A method is moved to a different class. The references within that
field are replaced with getter and setter methods and the object
reference from the source class is passed as a parameter to the
method within the new object. If there is no object reference to the
target class a new reference is created by declaring and initializing
a local variable to the target class. We are aware that this is not
ideal design as an additional dependency between source and
target class is introduced. Hence, the refactoring output needs
further review and a TODO tag is placed in the comment section
of the
1.2.2 Move Field
A field is moved to a different class. The existing dependencies
are replaced with getter and setter methods.
1.2.3 Extract Method
The extract method extracts a method from a method. The extract
method algorithm indentifies The method is
1.2.4 Create Class
This refactoring creates an empty class. This refactoring is
meaningless on its own however it
We have made very good experience with
Within this work we
Rearchitecturer Tool
Automatic refactoring have its downside in often just shifting
problems within the source code. The complexity of one . Hence,
average metric to
A prototype has been developed to test the feasibility of the
planned approach.
In comparison to other
Quality Model
A multi objective problem programming and hence the finding
the solution is complex due to the . Additionally, it is hard to
identify a suitable solution. However, there are propably a variety
of solutions which fit the quality model.
Refactorings
So far a set of four behavior preserving refactorings have been
implemented to transfer
It is evident that these methods are in particular focus on the
distribution of responsibilities of functionality in different parts of
the system.
The refactorings create classes and methods independently.
Hence, these method and class names which feature no
meaningful names. The classes and methods are annotated with
TO-DO tags to help the developer to run through the
The refactorings are annotated within the source code. This
allows the developer to
To DO tags in refactored
Fitness Function
The Fitness function
The focus onto defined quality
The Search Algorithm/fitness function
The goal of this research is to identify a source code instance
which complies with a given quality model. To achieve this goal a
set of refactorings is applied to alter the structure of the source
code. However, it is not possible to predetermine the exact effect
of a refactoring to the quality of the source code. Thus, it is not
possible to determine which sequences of refactorings are feasible
to transform a source code instance to comply with a given quality
model. Additionally, the various refactorings and their
applicability to multiple source code elements and the relevance
of the order of application create a very large space of possible
candidate solutions even with relatively small input systems.
Hence, the complexity of the search space does not allow
verifying all solutions to select the best solution. However,
depending on the individual software system and defined quality
model there are probably a variety of source code instances which
comply with the defined quality model. However, the objective of
this research is not necessarily to
Within this research optimizations strategies are applied to
overcome the . The iteratively search process should enable to
find a good solution.
Two metaheuristics have been implemented to
Greedy algorithm
Evaluation
Preliminary experiments with various software systems have
shown that the approach is capable to influence size, cohesion,
coupling and complexity metrics. As a specific example this
section illustrates the feasibility of the approach on the basis of
the open source library JDepend1 2.9.1. JDepend is a java
package dependency and design quality metric analyzer and
features a size of 4.2kloc, 29 classes, 4 packages and 308
methods.
A simple Quality Model with the two coding rules maximum
method length (50) and maximum class length (400) has been
defined. We are aware that this is a simple and quite restrictive
quality model, which will hardly be found in practice. However,
the purpose of this quality model is the creation of violations,
which at least should be possible to be tackled by our refactorings.
The JDepend system manifests a total of ten violations if
validated with the defined quality model.
Further Work
The preliminary results of this research have shown that an
automatic refactoring approach has the capability to align a
software system with a given source code quality model.
However, the approach and the prototype is not further developed.
Hence, further work is required to identify the full potential and
shortcomings. This further development and evaluation will target
the extension and enhancement of refactorings and selection
algorithms, the evaluation and applicability of more complex
software systems and quality model. Additionally, a qualitative
analysis of the refactoring results and the potential to actually
integrate such an approach in the life development process need
further research. Additionally, some of the shortcomings of the
current approach such as long progressing time and
has the potential to enable the approach to transform the system
and also to align the system with more
refactor the system towards more complex quality models.
Extension
Conclusion
The particular contribution of this work is a directed selection of
the refactorings. The benefit is a faster navigation towards
promising . The project is just in the progress to be build up.
1
http://clarkware.com/software/JDepend.html