Measuring the Effects of Aspect-Oriented Refactoring on
Component Relationships: Two Case Studies
Reishi Yokomori§, Harvey Siy†, Norihiro Yoshida‡, Masami Noro§, Katsuro Inoue*§Department of Software Engineering, Nanzan University, Japan†Department of Computer Science, University of Nebraska at Omaha, USA‡Graduate School of Information Science, Nara Institute of Science and Technology, Japan*Graduate School of Information Science and Technology, Osaka University, Japan

yokomori@nanzan-u.ac.jp, hsiy@mail.unomaha.edu, yoshida@is.naist.jp,
yoshie@nanzan-u.ac.jp, inoue@ist.osaka-u.ac.jp
ABSTRACT
Aspect-oriented refactoring is a promising technique for improving modularity and reducing complexity of existing software systems through encapsulating crosscutting concerns.
As complexity of a system is often linked to the degree towhich its components (e.g., classes and aspects) are connected, we investigate in this paper the impact of such refactoring activities on component relationships. We analyze
two aspect-refactoring projects to determine circumstances
when such activities are eﬀective at reducing component relationships and when they are not. We measure two kindsof relationships between components, use and clone relations. We compare how these metrics changed between theoriginal and the refactored system. Our ﬁndings indicatethat aspect-oriented refactoring is successful in improving
the modularity and complexity of the base code. However,
we obtain mixed results when aspects are accounted for.
Based on these results, we also discuss constraints to thetechnology as well as other design considerations that may
limit the eﬀectiveness of aspect-oriented refactoring on actual systems.
Categories and Subject Descriptors: D.2.8 [Software
Engineering]:Metrics - Product metrics
General Terms: Measurement, Languages, Experimentation
Keywords: Use-relation analysis, code clone analysis, aspectoriented programming, refactoring, coupling

1. INTRODUCTION
Many projects have adopted an incremental approach tosoftware development. In such approach, readability andmaintainability can deteriorate due to the accumulation offeatures, so developers perform refactoring activities to reorganize code structure and to prepare for future extensions.
Refactoring[17] is a suite of activities for changing software’s

Permission to make digital or hard copies of all or part of this work forpersonal 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, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.
AOSD’11, March 21–25, 2011, Pernambuco, Brazil.
Copyright 2011 ACM 978-1-4503-0605-8/11/03 ...$10.00.

internal structure without modifying its existing functionality, in order to improve internal quality of the software, suchas readability and complexity of source code. Refactoringhas become one of the essential activities in development oflarge software systems, and there are a lot of studies, suggestions, and practices for diﬀerent refactoring approaches.
We focus attention on a refactoring approach based on
aspectization. A merit of aspect-oriented development[10]is the ability to modularize crosscutting code, that is, features implemented in a crosscutting manner would be separated from the structure of the base software source codeand moved into their own modules, known as aspects. On
the basis of these characteristics, extracting several features
as aspects from the existing system is suggested as a refactoring approach.
A commonality across most refactoring techniques is thatthey simplify code by consolidating similar pieces of code.
We expect this eﬀect to be even more pronounced withaspect-oriented refactoring as it enables consolidation of crosscutting code in ways that would not be possible with conventional refactoring techniques[13].
In this paper, we undertake an empirical study to assess how this consolidation aﬀects existing software systems.
Speciﬁcally, we investigate the following research questions:
Q1 Is aspect-oriented refactoring eﬀective for improving modularity and complexity?
Q2 What are the characteristics of classes likely to be strongly
aﬀected by such refactoring activities?
We address these questions with respect to the eﬀects oncomponent relationships. The degree of relatedness of asystem’s components aﬀects its modularity, which in turnaﬀects the complexity of maintaining it.

1.1

Overview of Methodology

We employ a multiple-case study approach to investigate
these questions. We identify several real-world projects thathave aspectized counterparts with the same functionalities.
We compare the diﬀerences in the aspectized and original
versions in terms of two classes of metrics: change in use
relations and change in clone relations.
Use relations indicate coupling between components interms of usage dependencies. We compute use relations
as a surrogate measure for modularity. More modular systems are expected to have fewer couplings. We conjecturethat crosscutting code that are part of the same concern aresomehow interrelated in the sense that they have usage dependencies with each other or use some other common component. By moving crosscutting code into aspects, scatteredusage dependencies between crosscutting code will now be
localized within the aspect. Also, usage dependencies with
common components will be consolidated and will originate
from the aspect rather than from multiple sources.
Clone relations indicate common code fragments sharedby two or more components. Code for many common crosscutting concerns such as logging and tracing are often homogeneous, that is, they share similar or nearly identicalcode fragments [4]. The presence of such clones increases
the complexity of subsequent maintenance activities due tothe potential need to update multiple places to implementa change. By refactoring them into aspects, homogeneouscrosscutting code will be factored out of the base and into
aspects, thus reducing complexity of maintenance. Clone relations provide a complementary perspective for tracking therefactoring process. While tracing use relations enables us
to trace the movement of programmatic relationships, tracing clone relations enables us to trace the actual movementof code from base to aspects.
We reﬁne our research questions in terms of these metrics:
Q1-1 Is refactoring eﬀective for reducing use and clone relations between classes?
Q1-2 Is refactoring eﬀective for reducing total use and clone
relations (classes and aspects)?
Q2-1 What kinds of components are likely to have fewer
use relations after refactoring?
Q2-2 What kinds of components are likely to have fewer
clone relations after refactoring?
We analyze two large software applications that have been
refactored into aspects, JHotDraw and Berkeley DB. In bothprojects, Java programs were refactored and some functions
were extracted and rewritten as aspects using AspectJ. For
each project, we compare the complexity of original structure with the refactored structure, ﬁrst without the aspects,
and then with aspects taken into account. By tracking thechanges to use and clone relationships, we can characterize
refactoring activities in a way that enables us to reach someconclusions about the eﬀectiveness of aspect-oriented refactoring as well as explain the observations recorded by theoriginal refactoring teams.
In Section 2, we introduce two types of component graphs,
which provide the conceptual model for the analysis of use
and clone relations. The results of analyzing two refactoring
projects are presented in Section 3. We discuss the eﬀectiveness of the refactoring by using aspects and related works in
Section 4.

2. BACKGROUND
2.1 Software Component
In general, a component is a modular part of a systemthat encapsulates its content and whose manifestation is replaceable within its environment [11]. It represents a logicalunit in the program source code, such as a class, function, or
package, etc. In this study, we treat classes and aspects ascomponents. We model relationships between components

using component graphs. We introduce two types of component graphs, one based on use relations and another basedon clone relations.

2.2

Use Relation Component Graph

The component graph based on use relations is modeled asa directed graph. A node in the graph represents a software
component, and a directed edge from node x to y represents
a use relation meaning that component x uses component y.
By using the graph, we can easily identify the use relations
between components and count the incoming and outgoingedges of a component.
Use relation metrics are calculated using SPARS-J[7]. SPARSJ is a web-based Java code search engine and navigates a lotof registered components based on use relation between components. We use it to compute the use relations. SPARSJ identiﬁes use relations using static analysis, so dynamic
binding is excluded. In the graph, we treat Java classes ascomponents, and consider the following as use relations:• inheritance,• implementation of abstract class and interface,• declaration of variables,• creation of instances,• method calls, and• class attribute references.
In some analyses involving aspectized versions, we also
treat aspects as components, and take into consideration
use relations between aspects and classes to understand how
code fragments in original classes spread to aspects. We
deﬁne two kinds of use relation; those are use relations fromclasses to aspects and the ones from aspects to classes.
A directed edge from aspect a to class c represents a use
relation meaning that at least one advice from a uses c in themanners described above. A component graph with theseuse relations shows how the uses of the original component
spread to advices as a result of aspect refactoring.
On the other hand, a directed edge from class c to aspect
a represents weaving relationships between c and a, meaning that a has at least one advice that weaves into c. These
relations are determined by examining the pointcut speciﬁcations in a. Syntactically, the direction of the relationshipis from aspect to class, but logically, we can say that classc uses advices from aspect a, hence the direction of the directed edge is from class to aspect. This type of use relationshows how an original class is decomposed into base classand aspects, and how aspects are composed into the baseclass by refactoring.

2.3

Clone Relation Component Graph

A code clone is a code fragment that has a similar part toit in source code. It is pointed out that code clones makesoftware maintenance diﬃcult[8, 15, 20]. The code clone
problem can become serious, especially for large scale software. As with use relations, we model software systems
based on clone relations by using a graph. As these are
equivalence relationships, we use an undirected graph. A
node in the graph represents a software component, and anedge between x and y represents a clone relation meaningthat both component x and component y have similar codefragments.
Clone relation metrics are calculated using CCFinder[20].
In the graph, we treat Java ﬁles as components. Two ﬁles

have a clone relation if they have similar code fragments thatare longer than 25 tokens. In analyses involving aspectizedversions, we also take into account clone relations between
aspects and between aspects and classes(Java ﬁles) to understand how existing code clones in original classes spread toaspects or how clone relations are deleted or created newly
by aspect refactoring. In such case, an edge between aspect
x and class (or aspect) y represents a clone relation meaningthat advices(statements) in aspect x and class y(or advices
in aspect y) have similar code fragments that are longer than
25 tokens.

3. EMPIRICAL STUDY
3.1 Purpose of Study
We present case studies of two aspect refactoring projects.
In each of these projects, a large Java software system was
refactored into AspectJ aspects. By comparing the original Java software structure and the refactored structure, we
analyze how the use and clone relation component graphschanged during the refactoring process.

Thus, these methods have disappeared from the base because the declaration of Storable interface was moved to the
aspects. As a result of this, use relations from such ﬁgurerelated classes to the classes handling persistent output andinput were aﬀected by the refactoring. Figure 1 shows theuse relations that were extracted from the base.
Clone relations are also changed. Figure 2 shows the affected part of the clone relation graph. From this we conﬁrm
that some clone relations disappeared from modiﬁed Figurerelated classes. But when we take aspects into consideration,
we ﬁnd that many clone relations have in fact only moved.
As shown in Figure 3, we identiﬁed clone relations between
aspects and existing classes. Speciﬁcally, 32 out of the original 37 persistent read and write methods still remain in baseclasses. Thus, only a limited part of similar code fragments
moved to the created aspects. This indicates that the extracted aspects are part of larger features still implemented
in the base classes, so these Storable classes continue to be
used by many other existing classes.
Ver. 0.1 -> 0.2
Image Figure
Attribute
Figure

3.2 Preparation
The projects selected for this study are AJHotDraw1 , which
is an aspectized version of JHotDraw2 , and a refactoring
project3 for Berkeley DB Java Edition4 . Each project performed refactoring by extracting cross cutting features in theoriginal system. In both projects, aspect refactoring was
carried out in a systematic and disciplined manner, with
judicious use of available idioms and patterns. For eachproject, the changes in use and clone relations are analyzed.
These metrics are calculated using SPARS-J and CCFinder
and the result is manually organized. We will provide abrief overview of these projects and compare the originaland refactored structures.

3.3 AJHotDraw (AJHD)
JHotDraw is a Java-based GUI framework for technicaland structured graphics. The AJHotDraw project[21] wasformed to identify and evaluate template-based solutions forrefactoring object-oriented into aspect-oriented code [16]. It
branched oﬀ from JHotDraw 6.0 and released three versions,0.2, 0.3 and 0.4. Crosscutting concerns were extracted in incremental steps, and new aspects were created in each version. The aspectization process was guided by several patterns, as explained in detail in [16]. In the following sections,
we brieﬂy outline the aspects introduced in each version andthen analyze them in terms of the change in use and clone
relations. The JHotDraw aspect refactoring work was smallenough that it was possible to use graph visualization toillustrate how aﬀected use and clone relations moved fromclasses to aspects. As the number of aﬀected relations increased, the visualizations are supplemented by tabulating
the classes that were most impacted.

3.3.1

From Ver0.1 to Ver0.2

In version 0.2, 5 aspects were created. Each aspect weaves
persistent read and write methods to ﬁgure-related classes.
1

http://swerl.tudelft.nl/bin/view/AMR/AJHotDraw
http://www.jhotdraw.org/
3
http://wwwiti.cs.uni-magdeburg.de/iti db/research/berkeley
4
http://www.oracle.com/database/berkeley-db
2

EllipseFigureAttribute
FigureRound Rectangle Figure

Composite
FigureStorable

Rectangle

Input

FigureText Figure
Storable
OutputAbstract
FigureFigure 1: Use relations extracted in Ver. 0.2

3.3.2

From Ver0.2 to Ver0.3

In version 0.3, one empty class named GenericRole and4 aspects were created. Aside from an aspect (CmdCheckViewRef) that enforces a contract for all AbstractCommanddescendants, most aspects added here are concerned withsuperimposing an observer pattern for notifying and handling changes in selecting ﬁgures. GenericRole was extended
to encapsulate the observer and subject role. We compare
the refactored structure in version 0.3 with the one from version 0.2. Incoming edges to the FigureSelectionListener classwere extracted as in Figure 4.
Changes to the clone relations are shown in Figure 5.
At ﬁrst, 7 classes are strongly connected, however, we ﬁndthat this clone group is now decomposed into several smallerclone groups after a common method-call statement was extracted. When we take into account advices in the aspects,
we identify one new clone relation, between StandardDrawing
and FigureSelectionSubjectRole.aj, resulting from the extraction of a method in StandardDrawing that has similarities
with another method in this class. Other new aspects haveno clone relations with classes in the clone group. This isperhaps because all of classes in the group are modiﬁed atonce and the methodology of the refactoring is not based on
method extraction, but statement extraction.

Ver. 0.2 -> 0.3

Only Classes
Draw
Application

Arrow Trip

Drawing View

Text Figure

Composite
FigureText Area
FigurePert
FigureRectangle
FigureEllipse Figure

Poly Line
FigureRound
Rectangle
FigureFigure Selection
Listener

Null
Drawing View

CreatedStandard
Drawing View

Generic Role

Abstract
Command

Runtime
Exception

not changed clone relation
removed from base code
modified components

Image Figure

Figure 2: Clones changed in Ver. 0.2(only classes)

Figure 4: Use relations extracted in Ver. 0.3

Classes and Aspects
Arrow Trip

Persistent
Text Figure.aj

Ver0.2 -> 0.3

DrawApplication

Text Figure

Composite
FigureText Area
FigurePert
FigureRectangle
FigureEllipse Figure
Round
Rectangle
FigureImage Figure

Align
Command

PersistentImageFigure.aj

Persistent
Composite
Figure.aj

not changed clone relation
clone between class and aspect
created aspects

Un Group
Command

From Ver0.3 to Ver0.4

In version 0.4, one aspect was deleted and 22 aspects werecreated. In this update, several features, such as handling IO
exception, CommandListener, undo handling, were extracted
as aspects and existing aspects were also reorganized. The
biggest extraction is undo handling; undo-related classes
were aspectized, with undo features in each class extracted
as aspects. Regarding the aspectization approach, the pattern of extending GenericRole was also used as in the case ofversion 0.3. Moreover, we can ﬁnd other weaving patterns
in class related with CommandUndo and ToolUndo. These
details are diﬀerent, but all of these aspects weave similar
methods and advices to corresponding classes.
In this version, 10 classes and 96 use relation edges are
removed and 5 edges are added compared to version 0.3.
Deleted classes are mainly UndoActivity classes that had
been inner classes for each command class. To check theuse relations that were removed, the reduction in incoming
and outgoing edges of each component on the component
graph is analyzed. Table 1 is a list of components whose
outgoing edges decreased. Decrease in outgoing edges of acomponent implies that the component has stopped using
some classes. From Table 1, not only deleted inner classes,
Command-related and Tool-related classes are on the list.
This was because, in addition to undo features, other undorelated methods in each command class were also extracted
and moved to aspects.
Table 2 is a list of components whose incoming edges decreased. Decrease in incoming edges of a component implies
that some classes have stopped using this component. FromStandard
DrawingChangeAttribute
CommandBring To Front
CommandSelect All
Command

Poly Line
FigureFigure 3: Clones in Ver. 0.2(classes and aspects)

3.3.3

Group
Command

Send to Back
CommandFigureSelection
SubjectRole.aj

not changed clone relation
removed from base code
modified components

clone between class and aspect
created aspects

Figure 5: Clones changed in Ver. 0.3
Table 2, undo-related classes, such as UndoableAdapter, Undoable are on the list, and commonly used classes such as
DrawingView, Figure, FigureEnumeration and so on are also
on the list.
Table 1: The change of outgoing edges (0.3 and 0.4)
Class
0.3
0.4 changeGroupCommand$UndoActivity
9 removed-9
CutCommand$UndoActivity
8 removed-8
UndoableCommand
8 removed-8
standard.CutCommand
11
6-5
standard.DeleteCommand
105-5AlignCommand$UndoActivity
5 removed-5
DeleteCommand$UndoActivity
5 removed-5
PasteCommand$UndoActivity
5 removed-5ﬁgures.ConnectedTextTool
128-4ﬁgures.TextTool
15
11
-4

The aﬀected clone relations are shown in Figure 6. A large
number of clone relations disappeared, with all of clone relations removed from some modiﬁed classes. However, when
we take into account advices in the aspects (Figure 7), we
ﬁnd that most clone relations simply moved to the related
aspects as in the case of ver 0.2, and only 6 clone pairs actually disappeared. This implies that extracted undo-related
code have similarities to other fragments that remained in
the base classes. This is conﬁrmed by an inspection of thecode from which we ﬁnd 19 out of the original 26 UndoActivity classes are still in the base code.
Altogether, the number of clone relations decreased from

Only Classes

Table 2: The change of incoming edges (0.3 and 0.4)
Class
0.3
0.4 change
util.Undoable
48
35
-13
framework.DrawingView
131
121
-10
util.UndoableAdapter
3324-9PasteCommand$UndoActivity
7 removed-7
framework.Figure
135
129
-6
framework.FigureEnumeration
73
68-5
util.CommandListener4
0-4
standard.FigureTransferCommand
10
6-4
standard.FigureEnumerator
24
21-3
util.CollectionsFactory
47
44
-3

Connected
Text Tool

Text Area Tool

Align Command

Berkeley DB Java Edition (BDB JE) is a software component library that provides a high-performance embedded
database. The BDB JE refactoring project [9] set out toinvestigate the use of AspectJ to implement a product line
consisting of a common base and several optional featuresthat can be composed together. The refactoring was carriedout by identifying several features from BDB JE and thenrefactoring each into a combination of classes and associatedaspects.
We downloaded the publicly available refactored code which
consists of a base program and 28 aspectized features, containing a total of 107 aspects. And then, we extracted theset of Java classes from it, and compared the class structureof the refactored Java code with the original BDB JE code.
For the original BDB JE, we selected, among the versions
available on the BDB website, version 2.1.30, whose classstructure and source code descriptions are most similar to
the refactored code. To give the original version a resemblance to the refactored version, we removed some packages, such as test, example, collection, JEC and so on, fromthe original version. We also found that some packages wererenamed during refactoring project. However, if these renamed packages have approximate counterparts in the original version, we treat these packages as the same. In suchcases, we call such components by the name in version 2.1.30.
In what follows, we call the refactored system, ABDB,
and call the original (version 2.1.30), JBDB. We analyze
the change in use and clone relations between JBDB and
ABDB. We analyze the data by tabulating the classes thatwere most impacted with respect to changes in incoming
and outgoing use relations as well as clone relations. We
also check if the diﬀerences in use relations between JBDB
and ABDB are statistically signiﬁcant. Finally, we manuallyinspect the impacted classes to ﬁnd characteristics common
to these classes.

3.4.1

Impact on Use Relations

Reduction in outgoing edges
As in the case of AJHD, the reduction in outgoing edges isa good indicator to assess how much of the use of other com-

Group
Command

Send To Back
Command

Change Attribute
Command

Undoable Adapter

Cut Command

Delete Command

Border Tool
Select All
CommandConnection Tool

Bring To Front
CommandComposite Figure

Pert Figure
Abstract Tool

Undoable
Command

Undoable Tool

3.4 Aspect Refactoring of Berkeley DB (ABDB)

Paste
Command
Un Group
Command

Undoable Handle

206 in JHotDraw to 158 in AJHotDraw, so 23% of clone relations are aﬀected by these refactorings, and 1 new clone relation between class and aspect is created. Of the 48 aﬀectedclone relations, 16 are actually removed, 29 clone relations
are now between aspects and classes, and 3 clone relations
are purely between aspects.

JHD Drag
Source Listener

Text Tool

Abstract
Commandnot changed clone relation
removed from base code
modified components

Figure 6: Clones changed in Ver. 0.4(only classes)
Classes and Aspects

JHD Drag
Source Listener

Text Tool
Connected
Text Tool

Text Area Tool

Un Group
Command

AlignCommand
Undo.aj
ChangeAttribute.aj

Composite Figure
Undoable Adapter
Delete Command
Undo.aj
Undoable Handle
Undoable Tool

Paste Command
Undo.aj

Send To Back
CommandBring To Front
CommandCut Command
Undo.aj

Undoable
Command.ajGroup Command
Undo.aj

Border Tool
Select All
CommandConnection Tool

Pert Figure
Abstract Tool

Command
Observer.aj

not changed clone relation
clone between class and aspect
created aspects
disappeared relation

Figure 7: Clones in Ver. 0.4(classes and aspects)

ponents was moved to aspects. The reduction in outgoingedges of each component is analyzed by comparing the baseclass structures of ABDB and JBDB. In terms of the component graph for use relations, JBDB has 331 nodes and 1977
edges while the base class structure of ABDB has 336 nodes
and 1681 edges. Thus, about 15% of edges are aﬀected by
the refactoring. Furthermore, a one-tailed paired WilcoxonMann-Whitney test5 of the distributions for outgoing edgesof ABDB and JBDB classes also reports that the distribution of outgoing edges in JBDB classes is greater than theones corresponding to classes in ABDB (p < 0.0001).
Figure 8 is a histogram of the outgoing edges of each classfor JBDB and ABDB, (the third item is also ABDB, but
includes outgoing edges to aspects, and is explained later).
From the graph, we can conﬁrm that a number of components that have no outgoing edges or have a low degreeof outgoing edges increased after the refactoring. On theother hand, a number of components that have a high degree of outgoing edges decreased slightly overall. We consider these aﬀected components are not only classes which
5
The non-parametric Wilcoxon-Mann-Whitney test [19] wasused here and in subsequent statistical testing because the
distributions being compared were not normally distributed,
as conﬁrmed by the Shapiro-Wilk test [18] for normality.

implement the extracted feature, but also local or core components which use the extracted feature.
Table 3 is a list of components whose outgoing edges
decreased signiﬁcantly. We observe that some DB-relatedclasses which use a lot of another classes are deleted during
refactoring. Impl and Manager classes organize and control
some major features, and Environment, Tree, and Databaseclasses are part of the BDB API. In JBDB, such management and API classes used various features, which were extracted in the refactoring.

Table 4: The change of incoming edges
Class
JBDB
ABDB change
dbi.MemoryBudget31
0-31
utilint.Tracer
23 removed-23
latch.LatchSupport
24
6-18
StatsConﬁg
19
1-18
Transaction
140-14
EnvironmentStats12
0-12
latch.Latch
15
4-11
LockStats
11
1-10
Environment
1910-9DatabaseException
71
63
-8

200
180
160
140
120
100

outgoing_JBDB

80

outgoing_ABDB

60
40

ABDBwithAspect

20
0Figure 8: Distribution of number of outgoing edges

slightly decreased are mainly classes used by the extracted
features.
Table 4 is a list of such components. Classes central toextracted features, such as MemoryBudget, Latch, and Transaction, are on the list. In addition, classes to collect and holdthe execution information are also on the list. These components’ features were extracted during the refactoring project,and codes and methods which use these features were also
extracted.
300

Table 3: The change of outgoing edges
Class
JBDB
ABDB change
dbi.DatabaseImpl
45
23
-22
utilint.DbScavenger
22 removed-22
dbi.EnvironmentImpl
54
34
-20
util.DbRunAction
18 removed-18
txn.TxnManager
18
8-10
util.DbLoad
10 removed-10
util.DbCachesize
10 removed-10
log.FileManager
28
19-9tree.Tree
50
41-9
Database
36
28-8Environment
28
20
-8

Reduction in incoming edges
As in the case of outgoing edges, reduction in incomingedges of each component is analyzed by comparing the Javaclass structures in ABDB and JBDB. The reduction in incoming edges is a good indicator to assess how much of
the usage of a component was moved to aspects. We also
performed a Wilcoxon-Mann-Whitney test on the distributions for incoming edges of ABDB and JBDB as in the caseof outgoing edges. It also reports that the distribution of
JBDB’s incoming edges is signiﬁcantly greater than the oneof ABDB’s incoming edges (p < 0.0001). This shows thatthe scale of the refactoring was large enough to aﬀect the
distribution of incoming edges.
Figure 9 is a histogram of incoming edges of each classfor JBDB and ABDB (the third item is also ABDB, but
includes incoming edges from aspects, and is also explainedlater). From the graph, we can conﬁrm that a number ofcomponents that have no outgoing edges increased throughthe refactoring. On the other hand, a number of componentsthat have a high degree of outgoing edges also decreasedslightly overall. We consider classes whose incoming edges
are completely removed are mainly classes for implementing
extracted features, and classes whose incoming edges are

250
200
150
100
50

incoming_JBDB
incoming_ABDBABDBwithAspect

0

Figure 9: Distribution of number of incoming edges

Including use relations from/to aspects
Next, we checked the impact on the component graphwhen aspects are included as components. In this analysis,
we considered two types of use relations: from class to aspect
and from aspect to class.
First, we consider use relations from class to aspect, asdeﬁned in Section 2.2, that is, weaving relations between aclass and the aspects that weave to it (as speciﬁed in the
pointcut). In object-oriented systems, to understand how aclass works, we often check how it uses other classes. Similarly for an aspect-oriented system, we will check not onlyclasses used by a class, but the aspects it uses as well. We
treat this weaving relation as a use relation from class to
aspect, and we checked number of outgoing edges from eachclass. This gives a rough estimation of the eﬀort for understanding how the class works.
In total, we ﬁnd 260 such use relations to 107 aspects in
ABDB. Table 5 is the list of classes most frequently targetedby aspects. Implementation classes, such as EnvironmentImpl
and CursorImpl, management classes, such as FileManager
are on the list. Moreover, classes handling information on
the execution, such as Params and Stats, and main classes
for certain database helper functions, such as Cleaner andCheckpointer are also on the list. This implies that theseclasses use the features extracted by these aspects, or theextracted features use these classes to store and handle related information.
The third item in Figure 8 is a distribution of outgoingedges of each class for ABDB with aspects. The numberof classes who have no outgoing edges are almost same as
the original JBDB, and the Wilcoxon-Mann-Whitney test
indicates that the diﬀerence between the two distributions
is not statistically signiﬁcant (p = 0.6086). Thus we canconﬁrm that uses of other class are completely replaced by
the aspect weaving in some classes.
Table 5: How many aspects weave to each class?
Class
Aspects
dbi.EnvironmentImpl
24
Environment
15log.FileManager
11
dbi.CursorImpl
10
conﬁg.EnvironmentParams
9
Database
8
EnvironmentStats
8
recovery.Checkpointer7
cleaner.Cleaner
7dbi.DatabaseImpl
7

Next, we consider use relations from aspects to classes,
counting how many aspects use each target class in theiradvices. Determining how a class is used or referred to byother classes is also an important activity to understandhow it works. In the case of aspect-oriented systems, suchinformation spreads also into advices in several aspects. So
we treat such use relation in advices in each aspect as use
relation from the aspect to class, and we checked the total
number of incoming edges to each class. It gives a roughestimation of the eﬀort for understanding how the class ismanaged in the system.
Table 6: How much is each component used by aspects?
Class
Aspects
DatabaseException
81
dbi.EnvironmentImpl
60
StatsConﬁg
23
dbi.DatabaseImpl
20tree.IN
20
dbi.DbConﬁgManager
17
latch.LatchSupport
17
dbi.MemoryBudget
17
EnvironmentStats
16
conﬁg.EnvironmentParams
15

In this way, we identify 700 edges from 107 aspects toclasses. The third item in Figure 9 is a distribution of incoming edges of each class for ABDB with aspects. The
number of classes who have no incoming edges are almost
same as the original JBDB’s one, and in fact, the WilcoxonMann-Whitney test indicates that the number of incoming
use relations has increased and this increase is statisticallysigniﬁcant (p < 0.0001). Thus we can conﬁrm that most of
the extracted use relations are moved to aspects and newuse relations are fanned in from multiple aspects.
Table 6 is a list of classes with the most incoming edges
from aspects. In general, methods implementing a feature
are more likely to call other methods that are also part ofTable 7: The change of incoming edges from classes
and aspects
Class

JBDB
Class

Tracer
dbi.MemoryBudget
TreeWalkerStatsAccumulator
Transaction
LockStats
EnvironmentConfig
config.ConfigParam
DbInternal
DatabaseStatslatch.SharedLatch
Class
DatabaseException
dbi.EnvironmentImpl
tree.IN
OperationContext
dbi.DatabaseImpl
tree.BIN
dbi.DbConfigManager
txn.Locker
dbi.CursorImpl
EnvironmentParams

ABDB
Aspectremoved17
removedTotalchange
-23
-14
-8

23
31
8

0

14
11
16
16
19
6
6

0
1
10
12
12
2
2

7
4
1
0
3
2
2

7
5
11
12
15
4
4

-7
-6
-5
-4
-4
-2
-2

Class
63
93
44
12
53
20
22
38
14
24

ABDB
Aspect
81
60
20
6
20
12
17
12
13
15

Total
144
153
64
18
73
32
39
50
27
39

change
73
58
19
18
18
12
12
11
11
11

JBDB
71
95
45
new
55
20
27
39
16
28

17

that feature, thus if the feature is refactored into aspects, oneside of the use relations are moved to aspects. We ﬁnd a large
number of aspects calling feature code still in base featureclasses such as LatchSupport and MemoryBudget or in classes
that handle execution information such as StatsConfig andEnvironmentStats.
However, it is striking that 81 of 107 aspects use DatabaseException in their advices for exception handling, and 60 aspects use EnvironmentImpl in their advices. EnvironmentImpl
encapsulates an entire execution, so the class is used frequently as an argument passed by methods, and some of its
members are accessed in the method.
Table 7 lists the classes that have a large diﬀerence inincoming edges when edges from aspects are accounted for.
The upper table is in ascending order. Classes for a certain
extracted feature, such as Transaction and MemoryBudget
and so on, and classes encapsulating execution information,such as StatsConfig, EnvironmentConfig and so on, are on
the list. The use relations of such classes were reduced,
so we can conﬁrm that refactoring into aspects managed
to successfully encapsulate the extracted features and data
structure.
The lower table is in decreasing order of diﬀerence. Implementation classes such as EnvironmentImpl, DatabaseImpl,
CursorImpl and classes for the B-tree such as IN, Tree are on
the list. These components increase in number of incomingedges after refactoring and are used frequently in argument
passing of methods. Such classes that control some major
features are used widely by both remaining classes and extracted aspects, so users of the class are scattered over thesoftware system.
Analyzing distribution of edges related to aspects
Next, we compare the change between edges in ABDB’s
base structure (without aspects) and the one in JBDB fromthe change between edges in ABDB’s structure with aspects
and the one in JBDB.

300
250
200
150
100
50

The change ofoutgoing edges( Class)
The change ofoutgoing edges( Class and Aspect)0

Figure 10: Distribution of the change of outgoingedges
Figure 10 shows a distribution of the change of outgoingedges for each class. From this graph, we can conﬁrm thefollowing two things; By comparing only in the class structure (the ﬁrst item), we can conﬁrm some outgoing edges are
extracted. By comparing the total structure(with aspects),
that is the second item, we can conﬁrm the total number ofoutgoing edges are not changed so much. From a statistical
testing about distributions for outgoing edges of JBDB and
ABDB with aspect, we cannot conﬁrm that the distributionof JBDB’s outgoing edges is greater than the one of outgoingedges of ABDB with aspects. The use of other classes aremoderately replaced to the weaving by aspects, and total
eﬀort to check based on outgoing use relations would be notchanged so much.

pliﬁed use relations in the base structure. Components in
the right side of the y-axis are mostly newly created. Some
components are plotted along the line of x = y, this is because there are created classes through refactoring.
We observe that many components are below the x-axis,
that is, their total edges decreased even when use relations
from aspects are taken into consideration. These include
removed components, but also for components of certain
extracted features. However, we observe that a lot of components are above the x-axis, and especially for incomingedges, we can conﬁrm many components are plotted in theupper side of the graph. It indicating that their total edges
are almost the same or increase when use relations from aspects are accounted for, however, incoming edges to classes
are easy to increase. Total edges are not necessarily reduced
even if developer removes a lot of use relations from the target class. This indicates that, for many components, they
got codes from aspects in response to the number of extracted features that they use, or their usage was dispersed
into several similar aspects.
80

incoming edge

60
outgoing edge

40

20

The change ofoutgoing /incoming-80edges( Class)

250
200
150
100
50
0

0
-60

-40

-20

0

20

-20

-40

The change ofincoming edges( Class)
The change ofincoming edges( Class and Aspect)

The change of outgoing / incoming edges ( Class + Aspect)

Figure 12: The distribution of change of edges

3.4.2
Figure 11: Distribution of the change of incoming
edges
Figure 11 shows a distribution of the change of incomingedges for each class. From this graph, we can conﬁrm thefollowing two things; By comparing only in the class structure (the ﬁrst item), we can conﬁrm some incoming edges are
extracted from a lot of classes. However, by comparing thetotal structure(with aspects) from the original structure, we
can conﬁrm the total number of incoming edges tend to increase in the distribution. From a statistical testing, we canconﬁrm that the distribution of incoming edges of ABDB
with aspects is greater than the one of JBDB’s incomingedges. So, there is a diﬀerence between distribution of thechange of outgoing edges and the change of incoming edges;
total eﬀort to check based on used-by relations may increase.
Figure 12 is a distribution of changes of outgoing and incoming edges for each class. The x-axis plots the change between edges in ABDB’s base structure and the one in JBDB,
and the y-axis plots the change between edges in ABDB’s
structure with aspects and the one in JBDB.
We observe that many components are near the graph origin; these components were not aﬀected by the refactoring.
Figure 12 also shows that a large majority of components arein the left side of the y-axis, indicating that refactoring sim-

Impact on Clone Relations

We also compared the clone relation graphs of JBDB and
ABDB. When considering only classes, there are 277 nodes
and 365 clone relations in the component graph of JBDB,
and 282 nodes and 158 clone relations in ABDB. During
this refactoring, 13 Java ﬁles are removed and 18 Java ﬁlesare added. Some clone relations are also removed and others created; 218 clone relations are removed and only 11
clone relations are created, while the remaining 147 clone
relations are not aﬀected. In this way, a large percentage
of clone relations disappear from the class structure. Table 8 lists classes which lost the highest number of clone
relations. Central classes of certain features, such as Checkpointer, Cleaner, DbLoad, Tracer, Evictor, and Txn, and several Manager classes are on the list. This indicates that a
lot of similar code fragments are extracted from these ﬁles.
Next, we consider clone relations when aspects are accounted for. In our analysis, we identiﬁed 81 new clone relations, 35 between class and aspect, and 46 between aspects.
Thus 218 clone relations removed from the class structure
are replaced by a much smaller set of 81 clone relations.
This indicates that over half of clone relations removed fromclass structure are actually removed. We can still ﬁnd somestrongly connected clone groups consisting of classes andaspects in the graph. But overall, this refactoring was very
eﬀective from the perspective of clone removal.

Table 8: The change of clone relations
File
JBDB
ABDB change
Checkpointer34
7-27
Cleaner28
1-27
RecoveryManager
31
8-23
TxnManager
20
0-20
DbLoad19 removed-19
Tracer17 removed-17
EnvironmentStats17
0-17
Evictor
20
16
-16
IN
26
10
-16
Txn
19
4
-15

4. DISCUSSION
We revisit our research questions from Section 1, discussing the eﬀectiveness and characteristics of aspect-oriented
refactoring. We answer the speciﬁc questions ﬁrst and thensummarize the discussion to answer the main questions.

4.1 Effectiveness of Refactoring
4.1.1

Q1-1: Is refactoring effective for reducing use
and clone relations between classes?

From Figure 12, we observe that the use relations between
classes (x-axis) are mostly reduced after refactoring. This
reduction is also conﬁrmed to be statistically signiﬁcant. At
the component level, use-relations which form coupling relations were moved out of the base code as indicated by
Figures 1 and 4, so refactoring contributes to the simpliﬁcation of use relations between classes. We consider thatrefactoring of features into aspects is eﬀective if the feature
already has a localized class structure. In this case, not only
the feature itself, but also statements using the feature are
moved to aspects cleanly. In this way, such relations between classes are simpliﬁed, and refactoring contributes tomodularizing scattered information.
From the result, we also ﬁnd that scattered, similar codeare extracted to aspects, so clone relations are also reduced
after refactoring, especially classes which become a core ofcertain features.

4.1.2

Q1-2: Is refactoring effective for reducing total use and clone relations (classes and aspects)?

As shown in Figure 12 and Tables 6 and 7, the refactoring
may cause an increase in incoming use relations if components are widely used in aspects and classes. In ABDB, suchcomponents are frequently used as arguments. In general,classes like these are a global resource of the system; theclass is used widely by both remaining classes and extracted
aspects, so use relations to the class are scattered over many
components in the system. This phenomenon may make it
more diﬃcult to understand the global behavior of the system when aspects are considered. The additional couplings
also make it more diﬃcult to evolve the behavior of corecomponents. The BDB refactoring project [9] also reported
several limitations in refactoring using AspectJ, for example, it was impossible to add new exceptions to the existing
methods, so they declared all throwable exceptions of all features in the base code. As a result, numerous aspects had toreference base classes such as DatabaseException, thus driving up the number of incoming use relations to such classes(see Table 7).

Figure 13 shows the distribution of changes of incomingedges from classes, and from classes and aspects for three
versions of AJHD. In the graphs, almost all of the components are around the origin and x-axis, so use relations did
not increase signiﬁcantly.
As discussed in the AJHD project [16], modiﬁcations tothe base requires an awareness of the advice that applies toit. The ABDB project [9] also reported similar issues. In
spite of their best eﬀorts, they were dissatisﬁed with the results because maintainability, fragility and code readability
became worse. We think the propagation of use relations in
aspects contributes to the dissatisfaction.
From the perspective of clone reduction, ABDB’s refactoring eﬀort was quite successful. Over 100 clone relations
were actually removed, with a small number that moved
to aspects. Some clone relations between aspects were also
produced when similar code fragments were extracted into
diﬀerent aspects; in many cases, this situation cannot be
avoided if feature boundaries need to be preserved.
As shown in Figure 14, a clone relation between class andaspect forms when only one part of a clone group is extracted. This means that the scope of the classes considered for aspect extraction could have been extended so as
to include all clone fragments. If a size of the scope wasadequate, the number of clone relations would decrease or
the number of clones between aspects would increase as in
the case of ABDB.The opposite can be said for AJHD. Most
clone groups were only partially moved to aspects, implyingthat perhaps other design considerations had to be taken
into account in determining the scope of extraction.
Only a part ofcode fragments
is extracted.

Aspect A---------

Weave
Class A’

Class B---------Class AClass B

-----

-----

-----

-----

Code Clone

Aspect A

Aspect B

-----

-----

-----

-----

Class A’

Class B’

Weave
Both of codefragments
are extracted bydifferent aspects.

Weave

Figure 14: Extraction of code fragments in diﬀerent
classes
If developers need to modify extracted code fragments after refactoring, it may be better to modify clones from two
aspects than having to modify clones in both class and aspect. If there is a clone relation between class and aspect, adeveloper may need two kinds of modiﬁcations, one to theclass and the other to its clone pair in the aspect. If the
aspect is not conceptually related to the class, it would beeasy to neglect to modify one or the other, particularly overtime or with new developers. On the other hand, in thecase of clone relations between aspects, we speculate thatthe aspect-to-aspect symmetry as in the scenario depicted
in Figure 14 would lead developers to check similar aspects
when making updates, so clones would not be as likely to beneglected.

4.1.3

Q1: Is aspect-oriented refactoring effective for
improving modularity and complexity?

In general, refactoring by aspects improves the base code’s

6incoming edge2

incoming edge
outgoing edge

3

1

2
2

incoming edge

Use relation(Class) -6

0
-5

4

outgoing edge

-4

-3

-2

-1

0

1

-1

-2

-3

Use relation( Class) -4

-2

-1

0
-1

-5

-2

Use relation (Class + Aspect)

Use relation (Class + Aspect)(b) AJHD Version 0.3

0
-15

-10

-5

-2

0

5

-4

0
-3

-4

(a) AJHD Version 0.2

Use relation (Class)

outgoing edge

-6
-8
-10

Use relation (Class + Aspect)(c) AJHD Version 0.4

Figure 13: The distribution of change of incoming edges from classes and aspects for AJHotDraw

modularity by reducing the number of use relations. However, care must be taken to pay attention to the dispersingof use relations to aspects. This hinders the maintainabilityof the base as changes to classes can have an impact on the
aspects which use it. If inadequate attention is paid to use
relations from aspects, the maintenance of some components
can become more complex and error prone. To mitigate theincrease of use relations, an object-oriented refactoring of
the code may split up some of the highly used classes. An
object-oriented refactoring prior to aspect-oriented refactoring was also suggested in [16]. In many cases, the increasein use relations is unavoidable when the refactoring projectis constrained to preserve existing component interfaces andwork with some of the existing object designs.
Refactoring by aspects also simpliﬁes the base code’s complexity by factoring out clones. But from the results of two
projects, aspect refactoring may move clone relations to aspects. To sustain maintainability, developers should determine the scope of extraction carefully. If the scale is too
small, this will be reﬂected directly in the number of code
clones between class and aspect. A ﬁner-grained approach,based on extracting statements rather than methods, as performed in AJHD ver 0.3, is also eﬀective to minimize propagation of clones. However, the granularity may be too small
to apply on a large scale. A complementary approach is touse a clone detection tool like CCFinder [23] to guide developers in determining the proper scope by identifying allclone relations in the code.
While we can get the desired result if the refactoring isdone perfectly, it seems that there is a very high bar tocomplete it in real software systems. We need experts in
aspect refactoring as well as experts who have a global understanding of the system. Without enough preparation,
the refactoring produces suboptimal results. However, if we
can characterize classes that are suitable for aspect refactoring it may be possible to develop analysis tools that canidentify the best candidates for refactoring. We discuss suchcharacterizations next.

4.2 Classes Suitable for Aspect Refactoring
4.2.1

Q2-1: What kinds of components are likely tohave fewer use relations after refactoring?

Figures 1 and 4, and Tables 1 and 3 indicate that outgoingedges for using the extracted features are removed from classstructure. If the extraction is conducted on a large scale, use

relations of management classes, such as Impl and Manager
classes, and API classes, are greatly simpliﬁed.
A lot of aspects weave advices to management classes and
API classes as shown in Table 5. In the advices, statements
call a lot of classes central to extracted features, as well asstats classes holding execution information, as shown in Table 6. Management classes and API classes are also usedin the advices and methods, often passed in as arguments.
From Table 7, such components are still used in the remaining classes.
Figures 1 and 4, and Tables 2 and 4 indicate that incoming edges to components whose features are extracted
are removed from class structure. If the extraction is conducted on a large scale, use relations to management classes
and API classes are also removed, however, the reduction in
number of incoming edges for such classes is not signiﬁcant.

4.2.2

Q2-2: What kinds of components are likely tohave fewer clone relations after refactoring?

Results of AJHD (Figure 2,5, and 6) indicate a signiﬁcantreduction of clone relations between classes that implement
similar features. Clone relations completely disappear whensimilar crosscutting code are extracted from all applicableclasses at the same time. Otherwise, clone relations remain
and get moved to relations between classes and aspects, likeundo related aspects in ver 0.4 (Figure 7).
Results from ABDB (Figure 8) show a large reduction inclone relations from classes that implement similar features,indicating a signiﬁcant amount of similar code crosscuttingthese classes.

4.2.3

Q2: What are the characteristics of classes
likely to be strongly affected by such refactoring activities?

In general, the number of use relations between classes
decreases as a result of aspect refactoring. The reduction ofedges arises on the class around the features extracted by
aspect refactoring. If the extraction is conducted on a large
scale, not only the components which implements or uses
certain features, but also the management classes and APIclasses will see a reduction in use relations.
In this study, we also conﬁrm a reduction of clone relations mainly on the classes which implement similar features.
Similar code fragments form readily in such classes because
similar features tend to have similar code, requiring similar
behavior as well as pre- and post-processing. Through as-pect refactoring, code for such processing can be factored
out into aspects.

4.3 Threats to Validity
4.3.1

Construct validity

Construct validity refers to how well we have measured thequalities under study, namely modularity and complexity.
Modularity was examined from the perspective of coupling,
speciﬁcally usage dependencies; the fewer dependencies wehave, the more modular the system. It can be argued thatthe use relations identiﬁed may not adequately capture all
usage dependencies, such as inherited dependencies due topolymorphism as well as type parameter dependencies due
to generics. Inherited dependencies are an example of indirect relationships. We have conducted additional analyses
using component ranking [7] which can account for such indirect relationships. The results when indirect relationships
were taken into account are consistent with our ﬁndings here.
Generics were not used in the versions we examined of thetwo projects.
Complexity was examined from the perspective of diﬃculty of maintenance, speciﬁcally due to clones. It can beargued that the clones identiﬁed may not capture all clone
dependencies, especially clones with less than 25 tokens incommon. We tried several thresholds before settling on 25
tokens since, from the data, this was the typical size of an exception block, which was a commonly aspectized code fragment.

4.3.2

Internal validity

Internal validity refers to the ability to make causal conclusions between treatments and eﬀects, in this case, between aspect-oriented refactoring and modularity and code
consolidation. By comparing the aspect-oriented and nonaspect-oriented version of the same project, we controlled
for diﬀerences in the application complexity. Thus, these
versions act as natural controls for making controlled observations [14]. Also, in all the analyses, we made certain
to explain the results with corroborating observations of examples from the projects. Furthermore, when possible, wehighlighted the consistency of our ﬁndings with the results
the refactoring teams also arrived at.

4.3.3

External validity

External validity refers to the ability to generalize the results of our study, in this case, whether the projects chosen
are representative of industrial systems. Unlike toy examples, both JHotDraw and BDB are relatively large projects
with a history of accommodating real-world needs. This is
attested to by the fact that they are used by a number ofother industrial applications. Obviously, they do not reﬂect
the wide diversity of all real-world projects. Therefore, further replications are needed to verify if our conclusions holdwith additional data from other aspect-refactoring projects.
The consistency of results between our 2 large projects gives
us some conﬁdence that other refactored systems will also
have the similar results.

4.4 Related Works
Our work is the ﬁrst comparison study of large scale aspectoriented refactoring projects. Other researchers have studied impacts of object-oriented refactoring in real-world sys-tems. For example, Du Bois, et al. [2] investigated the impact of standard refactoring activities (e.g., Move Method,
Extract Class, etc.) on coupling and cohesion in Apache
Tomcat. Their results conclude that refactoring opportunities that improve coupling and cohesion are hard to ﬁnd; formany forms of refactoring, couplings just move elsewhere.
Our ﬁndings also indicate that use relations mostly do notdisappear; they just move into aspects.
Our work also complements a growing body of researchassessing the beneﬁts that aspect-oriented systems oﬀer tosubsequent maintenance and evolution activities [1, 3, 22].
It is our hope that our work on use and clone relation change
can provide additional quantitative information for explaining the results of such studies.
Eaddy, et al. [5] proposed a set of concern metrics for
precisely measuring scattering and tangling. While theirwork is mostly predictive in nature and useful for detecting crosscutting code, our work is retrospective, studying
crosscutting code that is already in aspects. This suggests
a future thread of investigation studying how much of thecrosscutting code suggested by such concern metrics wereactually refactored into aspects.
Our empirical study approach is similar to Kulesza, et al.
[12], which investigated the eﬀectiveness of designing basedon aspect oriented languages. In their experiments, they
compared aspect-oriented and object-oriented implementations of the same system using several general metrics. They
also analyzed a refactored structure without the aspects, as
we did here. While their results were mostly in favor of
the aspect-oriented implementation, we note that the system
was smaller, which was adequate for the purpose of their experiments comparing the performance of maintenance tasks
on both implementations. We also note that the aspectoriented implementation was designed from the ground up,
following the same principles as the object-oriented design
but not constrained to preserve speciﬁc component interfaces or subsystem boundaries of the object-oriented implementation.
Our work on clone relation analysis is also similar to Yoshida,
et al. [23], where CCFinder was used to detect sets of clones
in order to inform the refactoring process. Case studies wereconducted to detect such clones in large systems such as
ANTLR, Apache Tomcat and JBoss. We extend their results by examining how detected clone groups are actually
reﬂected in aspects after refactoring.

5.

CONCLUSION

In this paper, we examined the eﬀectiveness of aspectoriented refactoring in improving code modularity and complexity through factoring out crosscutting code from existing
non-aspect-oriented systems. We conducted a multiple-casestudy on two large projects. For each project, we compared
an original Java software structure and the refactored structure with respect to changes in use and clone relations. Even
though these projects had diﬀerent purposes, they reachedsimilar conclusions regarding the beneﬁts and limitations ofaspect-oriented refactoring. Our analysis adds to their contributions by providing quantitative conﬁrmation of theirevaluation results.
We conﬁrmed that refactoring causes propagation of use
relations for a certain set of classes. In general, such classes
are global resources of the software system, used widely byremaining classes and extracted aspects. Hence, use rela-tions to such classes are scattered all over the software system. Thus, while the overall modularity of the base Java
code appears to improve, coupling increases when accounting for use relations from aspects. On the other hand, we
also conﬁrmed the number of clone relations between classand aspect increases if only one part of a clone group is
extracted. These hinder the maintainability of the base aschanges to classes can have a negative impact on the classes
and aspects which use it. Some of the problems may be
attributed to the limitations of AspectJ, as pointed out by
the developers of AJHD and ABDB. We also attribute thesediﬃculties to the scope of the original code considered foreach extraction. In many cases though, this is unavoidable,
especially when the refactoring project is constrained to preserve existing component interfaces and to work with someof the existing object designs.
As future work, we plan to apply our analysis to otheraspect refactoring projects. In addition to component relationships, other types of metrics related to cohesion and concern diﬀusion similar to those used by Garcia, et al. [6] will
be studied as well. We would also like to analyze whether
certain types of object-oriented refactoring can prepare asystem for aspect-oriented refactoring. Finally, we also plan
to investigate the link between aspect refactoring patterns
and patterns of change in relations.

6. REFERENCES[1] M. Bartsch and R. Harrison. “An exploratory study ofthe eﬀect of aspect-oriented programming on
maintainability”. Software Quality Journal,
16(1):23–44, 2008.
[2] B. D. Bois, S. Demeyer, and J. Verelst. “Refactoring Improving Coupling and Cohesion of Existing Code”.
In Proceedings of the 11th Working Conference on
Reverse Engineering, pages 144–151, 2004.
[3] Y. Coady and G. Kiczales. “Back to the Future: A
Retroactive Study of Aspect Evolution in Operating
System Code”. In Proceedings of the 2nd international
conference on Aspect-oriented software development,
pages 50–59, Boston, MA, USA, 2003.
[4] A. Colyer and A. Clement. “Large-scale AOSD for
Middleware”. In Proceedings of the 3rd international
Conference on Aspect-Oriented Software Development,
Lancaster, UK, 2004.
[5] M. Eaddy, A. Aho, and G. C. Murphy. “Identifying,
Assigning, and Quantifying Crosscutting Concerns”.
In Proc. of the First International Workshop on
Assessment of Contemporary Modularization
Techniques, page 2, Washington, DC, USA, 2007.
[6] A. Garcia, C. Sant’Anna, E. Figueiredo, U. Kulesza,
C. Lucena, and A. von Staa. “Modularizing design
patterns with aspects: a quantitative study”. In
Proceedings of the 4th international Conference on
Aspect-Oriented Software Development, Chicago,
Illinois, USA, 2005.
[7] K. Inoue, R. Yokomori, T. Yamamoto, M. Matsushita,
and S. Kusumoto. “Ranking Signiﬁcance of Software
Components Based on Use Relations”. IEEE
Transactions on Software Engineering, 31(3):213–225,
2005.
[8] L. Jiang, G. Misherghi, Z. Su, and S. Glondu.
“DECKARD: Scalable and Accurate Tree-Based

Detection of Code Clones”. In Proceedings of the 29th
international conference on Software Engineering,
pages 96–105, 2007.
[9] C. Kastner, S. Apel, and D. Batory. “A Case Study
Implementing Features Using AspectJ”. In Proceedingsof the 11th International Software Product Line
Conference, pages 223–232, Kyoto, Japan, 2007.
[10] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda,
C. Lope, J.-M. Loingtier, and J. Irwin.
“Aspect-Oriented Programming”. In Proceedings of
ECOOP ’97, pages 220–242, 1997.
[11] C. Krueger. “Software Reuse”. ACM Computing
Surveys, 24(2):131–183, 1992.
[12] U. Kulesza, C. Sant’Anna, A. Garcia, R. Coelho,
A. von Staa, and C. Lucena. “Quantifying the Eﬀects
of Aspect-Oriented Programming: A MaintenanceStudy”. In Proceedings of the 22nd IEEE International
Conference on Software Maintenance (ICSM06), pages
223–233, Philadelphia, PA, USA, 2006.
[13] R. Laddad. “Aspect-oriented Refactoring: Taking
Refactoring to a New Level. ”. In Tutorial at theInternational Conference on Aspect-Oriented Software
Development (AOSD2005), Chicago, USA, 2005.
[14] A. S. Lee. “A scientiﬁc methodology for MIS casestudies”. MIS Quarterly, 13(1):33–50, 1989.
[15] Z. Li, S. Lu, S. Myagmar, and Y. Zhou. “CP-Miner:
Finding Copy-Paste and Related Bugs in Large-Scale
Software Code”. IEEE Transactions on Software
Engineering, 32(3):176–192, 2006.
[16] M. Marin, A. Deursen, L. Moonen, and R. Rijst. “Anintegrated crosscutting concern migration strategy andits semi-automated application to JHotDraw”.
Automated Software Engineering, 16(2):323–356, 2009.
[17] W. F. Opdyke. “Refactoring object-oriented
frameworks”. PhD thesis, University of Illinois at
Urbana-Champaign, 1992.
[18] S. Shapiro and M. Wilk. “An analysis of variance test
for normality (complete samples)”. Biometrika,
52(3-4):591–611, 1965.
[19] S. Siegel and J. Castellan. “Nonparametric Statistics
for The Behavioral Sciences”. McGraw-Hill, 1988.
[20] T.Kamiya, S.Kusumoto, and K.Inoue. “CCFinder: A
multilinguistic token-based code clone detection
system for large scale source code”. IEEE Transactions
on Software Engineering, 28(7):654–670, 2002.
[21] A. van Deursen, M. Marin, and L. Moonen.
“AJHotDraw: A showcase for refactoring to aspects”.
In Proceedings of the Workshop on Linking Aspects
and Evolution. 4th International Conference on
Aspect-Oriented Programming, Chicago, USA, 2005.
[22] R. Walker, E. L. A. Baniassad, and G. C. Murphy. “AnInitial Assessment of Aspect-oriented Programming”.
In Proc. of the 21st International Conference on
Software Engineering, pages 120–130, 1999.
[23] N. Yoshida, Y. Higo, T. Kamiya, S. Kusumoto, andK. Inoue. “On Refactoring Support Based on CodeClone Dependency Relation”. In Proceedings of the
11th IEEE International Software Metrics Symposium,
page 16(10 pages), Como, Italy, 2005.