ASSISTING REFACTORING TOOL DEVELOPMENT
T
HROUGH REFACTORING CHARACTERIZATION
Ra´ul Marticorena, Carlos L´opez
Language and Informatic Systems, University of Burgos, EPS Campus Vena Edificio C, Burgos, Spain
Javier P´erez, Yania Crespo
Department of Computing, University of Valladolid, ETSII Campus Miguel Delibes, Valladolid, Spain
Keywords:
Refactoring tools, Characterization, IDE, Object-oriented programming.
Abstract:
Tool support for refactoring is widespread nowadays. The most widely known IDEs include refactoring sup-
port, and many refactoring-specific tools are also available. Developers are aware of refactoring activities and
they do refactor their applications even manually or in an assisted way.
For the users of refactoring tools, the current state of the art is well documented in refactoring catalogs, where
objectives, motivation, mechanisms, etc. are defined. There are also available collections of criteria to detect
refactoring opportunities; compilations of guidelines to help decide when and how to apply refactorings. How-
ever, refactoring tool implementors can not only base their work on the documentation available in refactoring
catalogs because they do not offer clear guidelines on how to build the tools to automate these refactorings.
Implementing refactoring tools without any guidance, involves reasoning about which will be the better plan
to implement refactoring operations in the tool, their complexity or their graphical interface design, etc. This
paper introduces a refactoring characterization, and proposes how it can help refactoring tool implementors
on making decisions.
1 INTRODUCTION
Refactoring has become a well known and use-
ful technique for software developers in a short
time. Since 1992, where W. Opdyke (Opdyke, 1992)
stamped the term and defined which can be consid-
ered the first refactoring catalog, advances in refac-
toring have been increased exponentially.
Fowler et al. published the first book on refactor-
ing (Fowler, 2000) which spreads the seed all around.
This book contains the definition of one of the most
known refactoring catalogs
1
. Other well known cat-
alogs can be found in (Kerievsky, 2004), (Ambler
and Sadalage, 2006), (Lippert and Roock, 2006) and
(Meszaros, 2007).
The impact of refactoring is so that developers are
aware of refactoring activities and they do refactor
their applications even manually or in an assisted way.
Nevertheless, authors agree that the activities con-
cerning refactorings must be automated (Mens and
1
See also http://www.refactoring.com
Tourw´e, 2004) in order to succeed. The most widely
known IDEs include refactoring support, and many
refactoring-specific tools are also available. Imple-
menting refactoring tools involves reasoning about
which will be the better schedule to implement refac-
toring operations in the tool in a rational and effective
way. This includes issues on reusability, complexity
and graphical user interface design.
In this work, we will present a characterization of
refactoring operations. It will provide some objec-
tive criteria, that should drive decisions in the refac-
toring tools development process, to developers of
refactoring-specific tools or IDEs’ refactoring mod-
ules.
In the remainder of this paper, some related works
on refactoring implementation and refactoring char-
acterization approaches are detailed in Section 2. Sec-
tion 3 describes the proposed characterization based
on features. Section 4 provides the characterization
of the Fowler’s catalog and shows how the character-
ization was used to help making decisions in the de-
velopment of a refactoring tool. Section 5 concludes
232
Marticorena R., López C., Pérez J. and Crespo Y..
ASSISTING REFACTORING TOOL DEVELOPMENT THROUGH REFACTORING CHARACTERIZATION.
DOI: 10.5220/0003610902320237
In Proceedings of the 6th International Conference on Software and Database Technologies (ICSOFT-2011), pages 232-237
ISBN: 978-989-8425-77-5
Copyright
c
2011 SCITEPRESS (Science and Technology Publications, Lda.)
and describes some future work.
2 RELATED WORKS
In (Crespo and Marqu´es, 2001), we find an analysis
of refactorings. This analysis is based on a classifi-
cation, in order to characterize and to compare refac-
torings from several works. The characterization is
made from seven features:
Motivation: reuse, requirement changes or mainte-
nance.
Direction: vertical (inheritance), horizontal (client).
Effects: preserve clients, preserve objects, aggres-
sive.
Consequences: global, localized.
Initiated: by inference, by demand.
Human Interaction: automatic, semiautomatic,
manual.
Target: analysis, design, implementation artifacts.
Some conclusions can be extracted from this
work, that helps to infer refactoring properties. How-
ever, this work is performed from a high-level point
of view that is not useful to solve refactoring imple-
mentation problems at a lower level of abstraction.
In (Zannier and Maurer, 2003), a new refactoring
characterization is presented. This characterization
is organised around three complexity levels: atomic,
sequential and complex. Basic object-oriented con-
cepts –package, class, method, field, etc.– define a
feature named scope. Refactorings are then classified
using the scope of the input and output elements of the
refactoring. This approach has some advantages: it is
easy to apply and it does not depend on implemen-
tation details, therefore it can be applied with several
goals. Nevertheless, it defines just three large groups
of refactorings. Some additional implementation de-
cisions are difficult to made, due to the lack of a more
fine-grained classification, which could allow refining
these big groups.
On the basis of (Crespo and Marqu´es, 2001),
(L´opez et al., 2006) proposed a characterization
aimed at helping in refactoring definition. The main
features of this characterization are:
Knowledge Requirement: required design patterns.
Target: design models, code implementation.
Inputs: system, class, attribute, method, instruction,
entity.
Preconditions: system, class, attribute, method, in-
struction, entity.
Actions: create, update, delete.
Postconditions: system, class, attribute, method, in-
struction and entity.
Additionally, it takes into account low level de-
tails, such as the number or type of the elements used
in preconditions, actions or postconditions. This ap-
proach depends on a particular solution and program-
ming language and, therefore, it is difficult to reuse
in other contexts. Gathering all that information is
useful but, as a negative consequence, some decisions
should be made before knowing certain details. As
a consequence, it could be possible that some imple-
mentation changes could have effects on the refactor-
ing characterization. This situation must be avoided.
3 REFACTORING
CHARACTERIZATION
The main goal which drives this characterization is to
define simple features which can be extracted from
refactoring descriptions (from recipes or semiformal
definitions). These features should also be objective,
in the sense that different people should obtain the
same values from their descriptions. Therefore, we
try to avoid a subjective issue.
Hence, instances of characterization features must
be extracted from catalogs with a basic observation,
hiding language and implementation details. Next
subsections detail each feature.
3.1 Design and Language Issues
Design and language issues, required to apply certain
refactoring, points out some clues about its complex-
ity. Programmers can have different knowledge and
experience on the programming language, making it
easier or more difficult to apply, and to implement cer-
tain refactoring. We define three levels:
Basic: a refactoring uses common concepts of
Object-Oriented (OO) languages (modules,
classes, attributes, methods and inheritance). It
talks about concepts of an OO programming lan-
guage, which can be managed by any developers
with basic knowledge of OO programming.
Advanced: advanced concepts of OO programming,
such as contracts, exceptions, genericity, dele-
gates and annotations. These concepts require
a good knowledge of the programming language
and skills in well known “good practices” of OO
programming and design.
ASSISTING REFACTORING TOOL DEVELOPMENT THROUGH REFACTORING CHARACTERIZATION
233
Design Pattern: the refactoring involves some de-
tails regarding design patterns, such as partici-
pants, roles, etc. defined in the design pattern
specification. The designer or the programmer
must be acquainted with design pattern catalogs
and the different idioms for each language. In
(Kerievsky, 2004), we can find a complete calatog
of these refactorings.
Some examples of the application of this feature
are: Inline Method (basic), Replace Exception with
Test (advanced) and Form Template Method (design
pattern) (Fowler, 2000). We assume that each level
subsumes the previous ones. Those programmers
which apply design patterns, are also knowledgeable
on basic and advanced OO concepts.
This feature is interesting in education because it
allows gradating contents.
3.2 Scope
This feature tries to observe the refactoring effects as
seen by the users, without implementation details.
When we apply a refactoring, we can log three
different change levels:
Intraclass (I): changes that do not affect other
classes. Changes are contained within the class’
scope. They modify the methods’ body or those
entities not referenced from other classes (e.g.
private or non-exported methods). Contracts be-
tween classes remain without changes.
Client (C): client classes need to be updated (with
changes in the contracts). Changes affect public
or exported properties which are used by client
classes belonging to the same or different pack-
ages, namespaces or workspaces.
Inheritance (H): classes with inheritance relation-
ships are modified. The class hierarchy is affected
by changes to the inherited properties. The basic
effect is that changes must be usually propagated
in both ways: ancestors and descendants.
A refactoring can have effects at the three levels.
For example, Add Parameter (Fowler, 2000), appar-
ently a simple refactoring, has effects on its own class
(Intraclass), clients that use the method (Client), and
ancestor or descendants that define or override the
method (inHeritance).
3.3 Inputs
Inputs are the cornerstone of refactorings, because the
users want to refactor “something” (refactoring tar-
get) and additional information is needed to drive the
refactoring execution. If the refactoring offers differ-
ent alternative paths, user interaction is mandatory.
The refactoring inputs are important factors for
characterizing refactorings. Basically, the program-
mer needs to identify:
Root Input: (or target element) the software element
that users select when invoking the refactoring,
from visual inspection or aided detection. For
example: Self Encapsulate Field (Fowler, 2000),
needs only one target input, the field to encap-
sulate. The remaining refactoring actions do not
need user interaction.
Additional Inputs: it is very common that users pro-
vide some extra information about how to run the
refactoring. They are defined as additional inputs.
Wizards and other graphical components are built
to assist the users to introduce these values. For
example: Move Field (Fowler, 2000) needs a field
as the root input, but the user has also to select
the target class (additional input) where the field
must be moved to. User interaction is mandatory
in order to to choose the target class.
We always need a root input that identifies which
kind of refactoring can be applied. This point is used
intensively in currently available tools. All of them
give some sort of inference, showing the closed set of
refactorings that can be applied to the element the user
has selected. Therefore, we need to classify refactor-
ings by their root element because this will be used
to define the specific set of refactorings that should
be enabled in our refactoring tool or IDE when some
kind of element is selected for refactor.
One of the current problems that users face when
applying refactorings, appears when the tool does not
offer any assistance about the applicable set of refac-
torings. Some works such as (Emerson Murphy-Hill,
2008) point out this problem. As a consequence of
this, people are reluctant to apply refactorings be-
cause they do not have a clear idea of what refactor-
ings can be applied.
3.4 Actions
We define actions as operations that change the
source code state. Refactorings usually involve many
smaller actions. From reviewing refactoring mecha-
nisms (Fowler, 2000) or even low-level refactorings
(Opdyke, 1992), we can deduce that many actions
are performed by executing one simple refactoring.
These actions are linked to the implementation so-
lution (metamodels, logic predicates, grammarware,
XML, etc.), but for the sake of simplicity one ab-
stract action must characterize the refactoring. In this
ICSOFT 2011 - 6th International Conference on Software and Data Technologies
234
work, refactoring snapshots are considered, from the
initial to final state, selecting one action that defines
the refactoring.
Enlarging these catalogs by adding new refactor-
ings, would make it very easy to add new actions.
Nevertheless the characterization purpose is to give
a simple and easy method. Therefore, we must gener-
alize this feature to a closed set of actions, with a nar-
row number of options, where any refactoring could
be classified.
Regarding source code edition, we can think about
basic text operations as copy, paste, delete, find, etc.
In concern of the refactoring process, we can think
in similar terms, and reduce the number of applicable
actions to (ordered from lower to greater complexity):
Add: it links a previously created element to its
scope where it will be contained.
Rename: it changes the name of an element identi-
fied in the system by name.
Remove: it cuts the relationship between an element
and the scope where it was contained.
Replace: as the sequential run of Remove and Add
in the same scope.
Move: as the sequential run of Remove and Add in
different scopes.
4 THE REFACTORING
CHARACTERIZATION IN
PRACTICE
In this section, some refactorings from the classi-
cal Fowler’s catalog (Fowler, 2000) are characterized.
Most of currently available tools and IDEs choose this
catalog as the first reference to follow. It is an advan-
tage because it provides a common point of view, with
a well known vocabulary.
4.1 Applications on Building Graphical
User Interface
A common problem with refactorings tools is to de-
fine a graphical library or API that allows to build
refactoring user screens that guide refactoring execu-
tion. Inputs give an approximation of the refactoring
complexity. Big number of inputs are more difficult
to manage, with more complicated graphical user in-
terfaces. This is a basic question, and it is relatively
easy to give an answer using the inputs feature of the
refactoring characterization. If we have a refactoring
with only one input (root input), it can be classified as
automatic and it will be initiated automatically from
the environment selection by the programmer. On the
other hand, if the refactoring needs some additional
parameters, we need user interaction and the refactor-
ing is semiautomatic. In the first case, you do not
need any dialog window or wizard, but with semiau-
tomatic refactorings, some kind of graphical support
must be available.
Figure 1: Running available refactorings.
Next step is to use the root input type. Depending
on the tool, certain software elements could be avail-
able or not. Since it is important to mark the root input
type. If your tool only works at design level, refactor-
ings with a block of instructions as input, do not have
sense and could not be included.
From a reuse point of view, we need to know
what refactorings have a similar GUI. These ques-
tions can also be answered with this characteriza-
tion. For example, refactorings as Replace Error
Code with Exception, Replace Exception with Test,
Replace Method with Method Object, Replace Param-
eter with Explicit Methods, Replace Parameter with
Method and Separate Query from Modifier, have the
same inputs: one method (as root input) and one code
fragment. All these refactorings will have a common
GUI, since the refactoring GUI API could be reused
in a great number of refactorings.
Other different case is the Add Parameter refac-
toring. We need one method (as root input), one type
and one name to build the new parameter. There is no
other refactoring that shares these inputs, as this con-
crete GUI could not be reused. From our previous ex-
perience (Marticorena et al., 2007) (Marticorena and
Crespo, 2008), we used our characterization. Refac-
toring classification using the root input, also allows
to define clearly the set of available refactorings. If
the tool includes one concept (i.e. class, method, etc.),
it is relatively easy to help users showing just refactor-
ings with its suitable type input. Our Eclipse plug-in
points current available refactorings depending on the
current selected element. As can be seen in Fig.1, it
ASSISTING REFACTORING TOOL DEVELOPMENT THROUGH REFACTORING CHARACTERIZATION
235
ExtractClass
MoveField MoveMethod
InlineClass
HideDelegate RemoveMiddleMan IntroduceForeignMethod
IntroduceLocalExtension
Figure 2: Moving Features Between Objects.
Table 1: Moving Features Between Objects Characterization.
Refactoring Design and Lan-
guage Issues
Scope Root
Input
Additional Inputs Action
Hide Delegate Design Pattern ICH 1 Class N Classes Move
Remove Middle Man Design Pattern ICH 1 Class N Classes Remove
Introduce Local Extension Basic ICH 1 Class 1 Class, N methods Add
Extract Class Basic ICH 1 Class N Attributes Move
Inline Class Basic ICH 1 Class 1 Class Move
Move Method Basic ICH 1 Method 1 Class Move
Move Field Basic ICH 1 Attribute 1 Class Move
Introduce Foreign Method Basic IC 1 Class N Instructions Add
is selected the
check
method in the text editor and
Available Refactorings view shows the suitable refac-
toring list.
4.2 Applications on Scheduling
A different and more complicated problem is to deter-
mine a schedule of refactoring implementation. If we
have a set of refactorings, extracted from some cata-
logs, what refactorings should be implemented at first
steps? Some criteria should be applied to maximize
reuse and to minimize efforts.
In (Fowler, 2000), we find the “use” relationship,
but these relationships are established by the author,
from his own experience. Refactorings are grouped
by functional criteria, but these groups do not define
any implementation order.
We could take the “use” dependency graph ex-
tracted from (Fowler, 2000) and begin to build the
refactorings using this graph following a topological
sorting. This method is also used in bottom-up test-
ing. Nevertheles, our proposal tries to give a sim-
ple method, with similar results, but without previous
experience applying the refactoring set (usually in a
manual way).
In order to divide the problem, we will face
the refactoring implementation focused on functional
groups (Fowler, 2000), instead on focusing on the
complete set of refactorings. For example, in the
group Moving Features Between Objects, we find
seven refactorings. In Figure. 2, the graph of “use”
relationships inferred from the catalog in (Fowler,
2000) is presented.
The process uses the previously explained crite-
ria: Design and Language Issues, Scope, Inputs (root
and additional inputs and Action type. These criteria
are used to schedule the refactoring implementations,
from the first criterion to the last in a similar way to
the clause
order by
in a SQL query (the order in the
clause marks the precedence in the results). When
two elements have same values in the i
th
feature, it is
applied the i
th
+ 1 to solve the tie.
An example of applying the proposed character-
ization to the refactorings is shown in Table 1 on
the Category Moving Features Between Objects from
(Fowler, 2000). The elements in the table are ob-
tained in descending complexity. If we take the or-
dered refactorings in Table 1, it is very similar to one
of the possible topological sorting extracted from the
dependency graph of (Fowler, 2000) (see Fig. 2).
Some refactorings, as Remove Middle Man or Intro-
duce Foreign Method, without dependencies in the
graph, can be scheduled following the proposed or-
der.
About refactoring implementation schedule, our
solution is based on repositories. These repositories
contain functions and predicates that allow to ensem-
ble the refactoring pieces (pre/postconditions and ac-
tions). Applying previous features explained in Sec.
3, we obtain those refactoring with lowest complexity
as the first candidates to be implemented.
ICSOFT 2011 - 6th International Conference on Software and Data Technologies
236
5 CONCLUSIONS AND FUTURE
WORK
The characterization presented in this position paper
uses only static information, that can be extracted
from an abstract refactoring definition, with some de-
gree of language independence. This level of abstrac-
tion has some advantages. It offers a starting point to
implement a refactoring, therefore the tool builder can
be more confident on the initial decisions taken dur-
ing the first steps of the refactoring tool development.
Nevertheless, using the proposed characterization
can also trigger some questions about the refactoring
definition itself. It can warn us to check whether the
refactoring has been correctly defined, or even to rea-
son about if two different characterization refers to the
same refactoring. Our approach can be used as a tool
to compare how different people understand the refac-
toring definitions included in refactoring catalogs.
Future work could include to apply this method
to very different catalogs. For example, in (Am-
bler and Sadalage, 2006), refactorings are applied to
databases. Concepts such as design and language is-
sues, scope, inputs and actions, should be adapted to
new domains. Although, we think that a similar char-
acterization could be defined and applied with low ef-
fort, partially reusing the results of this work.
ACKNOWLEDGEMENTS
Ra´ul Marticorena, Carlos L´opez, Javier P´erez and Ya-
nia Crespo are partially funded by the spanish gov-
ernment (Ministerio de Ciencia e Innovaci
´
on, project
TIN2008-05675).
REFERENCES
Ambler, S. W. and Sadalage, P. J. (2006). Refactoring
Databases: Evolutionary Database Design. Addison-
Wesley Professional.
Crespo, Y. and Marqu´es, J. M. (2001). Definici´on de un
Marco de Trabajo para el An´alisis de Refactoriza-
ciones de software. Actas JISBD’01,VI Jornadas de
Ingenier´ıa del Software y Bases de Datos, pages 297–
310.
Emerson Murphy-Hill, A. P. B. (2008). Refactoring tools:
Fitness for purpose. IEEE Software, 25(5):38 – 44.
Fowler, M. (2000). Refactoring. Improving the Design of
Existing Code. Addison-Wesley.
Kerievsky, J. (2004). Refactoring to Patterns. Addison-
Wesley.
Lippert, M. and Roock, S. (2006). Refactoring in Large
Software Projects: Performing Complex Restructur-
ings Successfully. Wiley, 1st edition.
L´opez, C., Marticorena, R., and Crespo, Y. (2006).
Caracterizaci´on de Refactorizaciones para la Imple-
mentaci´on en Herramientas. In Actas JISBD’06, XI
Jornadas de Ingenier´ıa del Software y Bases de Datos,
Sitges, Barcelona, 2006. ISBN:84-95999-99-4, pages
538–543.
Marticorena, R. and Crespo, Y. (2008). Dynamism in
Refactoring Construction and Evolution. A Solution
Based on XML and Reflection. In 3rd International
Conference on Software and Data Technologies (IC-
SOFT), pages 214 – 219.
Marticorena, R., L´opez, C., Crespo, Y., and P´erez, J. (2007).
Reuse Based Refactoring Tools. In WRT’07, 1st
Workshop on Refactoring Tools, Berlin, Germany.,
pages 21–23. ECOOP’07.
Meszaros, G. (2007). xUnit Test Patterns: Refactoring Test
Code (Addison Wesley Signature Series). Addison-
Wesley Longman, Amsterdam.
Opdyke, W. F. (1992). Refactoring Object-Oriented Frame-
works. PhD thesis, University of Illinois at Urbana-
Champaign, IL, USA.
Zannier, C. and Maurer, F. (2003). Tool support for complex
refactoring to design patterns. In Marchesi, M. and
Succi, G., editors, XP, volume 2675 of Lecture Notes
in Computer Science, pages 123–130. Springer.
ASSISTING REFACTORING TOOL DEVELOPMENT THROUGH REFACTORING CHARACTERIZATION
237