ASSISTING REFACTORING TOOL DEVELOPMENT

HROUGH REFACTORING CHARACTERIZATION

Ra´ul Marticorena, Carlos L´opez

Language and Informatic Systems, University of Burgos, EPS Campus Vena Ediﬁcio 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-speciﬁc 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 deﬁned. 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 deﬁned which can be consid-

ered the ﬁrst refactoring catalog, advances in refac-

toring have been increased exponentially.

Fowler et al. published the ﬁrst book on refactor-

ing (Fowler, 2000) which spreads the seed all around.

This book contains the deﬁnition of one of the most

known refactoring catalogs

. 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

See also http://www.refactoring.com

Tourw´e, 2004) in order to succeed. The most widely

known IDEs include refactoring support, and many

refactoring-speciﬁc 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-speciﬁc 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

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

and describes some future work.

2 RELATED WORKS

In (Crespo and Marqu´es, 2001), we ﬁnd an analysis

of refactorings. This analysis is based on a classiﬁ-

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, ﬁeld, etc.– deﬁne a

feature named scope. Refactorings are then classiﬁed

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 deﬁnes just three large groups

of refactorings. Some additional implementation de-

cisions are difﬁcult to made, due to the lack of a more

ﬁne-grained classiﬁcation, which could allow reﬁning

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 deﬁnition. 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 difﬁcult 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

deﬁne simple features which can be extracted from

refactoring descriptions (from recipes or semiformal

deﬁnitions). 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 difﬁcult to apply, and to implement cer-

tain refactoring. We deﬁne 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. deﬁned in the design pattern

speciﬁcation. The designer or the programmer

must be acquainted with design pattern catalogs

and the different idioms for each language. In

(Kerievsky, 2004), we can ﬁnd 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 modiﬁed. 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 deﬁne 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 ﬁeld 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 deﬁned 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 ﬁeld

as the root input, but the user has also to select

the target class (additional input) where the ﬁeld

must be moved to. User interaction is mandatory

in order to to choose the target class.

We always need a root input that identiﬁes 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 deﬁne the speciﬁc 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 deﬁne 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 ﬁnal state, selecting one action that deﬁnes

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 classiﬁed.

Regarding source code edition, we can think about

basic text operations as copy, paste, delete, ﬁnd, 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-

ﬁed 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 ﬁrst 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-

ﬁne 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 difﬁcult

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 classiﬁed 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 ﬁrst 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 Modiﬁer, 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 classiﬁcation using the root input, also allows

to deﬁne 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 ﬁrst

steps? Some criteria should be applied to maximize

reuse and to minimize efforts.

In (Fowler, 2000), we ﬁnd 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 deﬁne

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 ﬁnd

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 ﬁrst 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

feature, it is

applied the i

+ 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 ﬁrst 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 deﬁnition, 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 conﬁdent on the initial decisions taken dur-

ing the ﬁrst steps of the refactoring tool development.

Nevertheless, using the proposed characterization

can also trigger some questions about the refactoring

deﬁnition itself. It can warn us to check whether the

refactoring has been correctly deﬁned, 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 deﬁnitions 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 deﬁned 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). Deﬁnici´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 Reﬂection. 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