This document discusses ranking refactoring suggestions based on historical code volatility. It proposes using the historical volatility of code elements, measured by changes across prior versions, to prioritize refactoring efforts. It evaluates four forecasting models - random walk, historical average, exponential smoothing, and exponentially weighted moving average - for predicting future volatility to rank suggestions. The historical average model achieved the lowest error and produced rankings most similar to actual volatility, especially for elements with frequent changes, making it a suitable strategy. The goal is to focus refactoring on code most likely to undergo future maintenance changes.

1. Ranking Refactoring Suggestions
based on Historical Volatility
Nikolaos Tsantalis
Alexander Chatzigeorgiou
University of Macedonia
Thessaloniki, Greece
15th European Conference on Software Maintenance and Reengineering (CSMR 2011)

2. Design Problems
non-compliance with
design principles
excessive
metric values
violations
of design
heuristics
lack of
design patterns
Fowler’s
bad smells

3. Design Problems … can be numerous
Number of Smells
JFlex
90
80
70
60
50
40
30
20
10
0
Long Method
Feature Envy
State Checking
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.4
1.4.1
1.4.2
1.4.3
Versions
Number of Smells
JFreeChart
400
350
300
250
200
150
100
50
0
Long Method
Feature Envy
State Checking
Versions

4. Motivation
• Are all identified design problems worrying?
• Example: Why would it be urgent to improve a method suffering
from Long Method if the method had never been changed?
• Need to define (quantify) the urgency to resolve a problem
• One possible source of information: Past code versions
•Underlying Philosophy: code fragments that have been subject to
maintenance tasks in the past, are more likely to undergo changes
→ refactorings involving the corresponding code should have a
higher priority.

5. Goal
• To rank refactoring suggestions based on the urgency to resolve
the corresponding design problems
• The ranking mechanism should take into account:
• the number of past changes
• the extent of change
• the proximity to the current version

6. Inspiration

7. Forecasting in Financial Markets vs. Software
Financial Markets
• Trends in volatility are more predictable than trends in prices
• Volatility is related to risk and general stability of markets
• defined as the relative rate at which prices move up and down
• time: trading days
Software – Preventive Maintenance
• Risk lies in the decision to invest on resolving design problems
•volatility based on changes involving code affected by a smell
• time: successive software versions

8. Code Smell Volatility
volatilityi+1
σ
extent of
changei-1,i
transitioni
i-1
extent of
changei,i+1
transitioni+1
i
software versions
i+1

9. Forecasting Models
• Random Walk (RW)
ˆ
 t 1   t
• Historical Average (HA)
ˆ
 t 1 
1
t
i
t
i 1
• Exponential Smoothing (ES)
ˆ
ˆ
 t  1  (1   ) t  a  t
• Exponentially-Weighted Moving Average
ˆ
ˆ
 t  1  (1   ) t  a
1
t
  t 1 j
t
i 1

10. Examined Smells
• Detection tool: JDeodorant
• Identified smells:
• Long Method
• Feature Envy
• State Checking

11. Long Method
Pieces of code with large size, high complexity and low cohesion
int i;
int sum = 0;
int product = 1;
for(i = 0; i < N; ++i) {
sum = sum + i;
product = product *i;
}
System.out.println(sum);
System.out.println(product);

12. What to look for
The presence of Long Method implies that it might be difficult
to maintain the method
→ perform refactoring if we expect that the intensity of the
smell will change
Previous versions: detect changes in the implementation of the
method that affect the intensity of the smell
change

13. Long Method
Version i
int i;
int sum = 0;
int product = 1;
for(i = 0; i < N; ++i) {
sum = sum + i;
product = product *i;
}
System.out.println(sum);
System.out.println(product);
Extend of Change: number
of edit operations to convert
methodi to methodi+1
Version i+1
int i;
int sum = 0;
int product = 1;
int sumEven = 0;
for(i = 0; i < N; ++i) {
sum = sum + i;
product = product *i;
if(i%2 == 0)
sumEven += i;
}
System.out.println(sum);
System.out.println(product);
System.out.println(sumEven);

14. Feature Envy
A method is “more interested in a class other than the one it
actually is in”
Target
Source
m(Target t) {
t.m1();
t.m2();
t.m3();
}
m1()
m2()
m3()
m() {
m1();
m2();
m3();
}

15. Feature Envy
The Intensity of the smell is related to the number of “envied”
members
Version i
Version i+1
Source
Source
m(Target t) {
t.m1();
t.m2();
t.m3();
}
envies 3
members
m(Target t) {
t.m1();
t.m2();
t.m3();
t.m4();
}
envies 4
members
Extend of Change: variation in the number of “envied” members

16. State Checking
State Checking manifests itself as conditional statements that
select an execution path based on the state of an object
Context
Type
type
- type : int
- STATE_A : int = 1
- STATE_B : int = 2
+ method() {
switch(type) {
type.method();
} case STATE_A:
doStateA();
break;
case STATE_B:
doStateB();
break;
}
}
+method()
StateA
StateB
+method() {
+method() {
}
}

17. What to look for
State Checking: implies a missed opportunity for polymorphism
+
if (state == StateA) {
. . .
. . .
}
else if (state == StateB)
{
. . .
. . .
}
else if (state == StateC) {
. . .
. . .
(additional
. . . + . . .
. . . statements)
}
State
StateA
StateB
StateC
...
...
...

18. State Checking
The intensity of the smell is primarily related to the number of
conditional structures checking on the same states
Version i
Version i+1
ClassX
ClassZ
ClassY
- type : int
- STATE_A : int = 1
- STATE_B : int = 2
- type : int
- STATE_B : int = 2
- STATE_C : int = 3
+ method() {
switch(type) {
case STATE_A:
doStateA();
break;
case STATE_B:
doStateB();
break;
}
}
+ method() {
switch(type) {
case STATE_B:
doStateB();
break;
case STATE_C:
doStateC();
break;
}
}
1 cond.
structure
- type : int
- STATE_A : int = 1
- STATE_B : int = 2
- STATE_C : int = 3
2 cond.
structures
Extend of Change: variation in the number
of conditional structures
+ method() {
switch(type) {
case STATE_A:
doStateA();
break;
case STATE_B:
doStateB();
break;
case STATE_C:
doStateC();
break;
}
}

19. Application
1.
2.
3.
Calculate past volatility values (for each
refactoring opportunity)
Estimate future volatility
Rank suggestions according to this estimate

20. Evaluation
• Goal: To compare the accuracy of the four examined models
• performed along two axes:
• direct comparison of forecast accuracy (RMSE)
• comparison of rankings produced by each model and according
to the actual volatility
• Context: two open source projects
• JMol: 26 project versions (2004 ..)
• JFreeChart: 15 project versions (2002 ..)

21. JMol
KSLOC
600
200
180
160
140
120
100
80
60
40
20
0
500
300
200
100
0
State Checking
Feature Envy
Extent of Change (State Checking)
0.14
0.0045
0.004
0.12
0.0035
0.1
0.003
0.08
0.0025
0.06
0.002
0.0015
0.04
0.001
0.02
0.0005
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Transitions between software versions
19
20
21
22
23
24
25
Extent of Change (Feature Envy)
#classes
400
KSLOC
#classes

22. JFreeChart
KSLOC
700
200
180
160
140
120
100
80
60
40
20
0
600
#classes
500
400
300
200
100
0
KSLOC
#classes
Long Method
Extent of Change
0.06
0.05
0.04
0.03
0.02
0.01
0
1
2
3
4
5
6
7
8
9
10
11
12
Transitions between software versions
13
14

23. Comparison of Forecast Accuracy
Long Method /
JFreeChart
1
RMSE 
N
N
 ˆ i
i
2
i 1
0.07
0.06
0.05
RMSE
0.04
EWMA
ES
0.03
HA
RW
0.02
0.01
0
1
2
3
4
5
6
7
8
9
Transitions between software versions
10
11
12
both consider the
average of all
historical values

24. Comparison of Forecast Accuracy
Feature Envy /
JMol
RMSE 
1
N
N
 ˆ i
i
2
i 1
Peaks in RMSE when
versions with zero
volatility are followed
by abrupt change
0.005
0.004
RMSE
0.003
EWMA
ES
HA
0.002
RW
0.001
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23
Transitions between software versions
Random Walk is
being favored by
successive versions
with zero volatility

25. Comparison of Forecast Accuracy
Overall RMSE for each smell and forecasting model
Random
Walk
Long Method
(JFreeChart)
Feature Envy
(JMol)
State Checking
(JMol)
Historical
Average
Exponential
Smoothing
EWMA
0.032646
0.031972
0.032176
0.032608
0.003311
0.003295
0.003309
0.003301
0.052842
0.052967
0.053051
0.053879
• HA achieves the lowest error for Long Method and Feature Envy
• more sophisticated models that take proximity into account do
not provide higher accuracy
• Simplicity and relatively good accuracy of HA 
appropriate strategy for ranking refactoring suggestions

26. Ranking Comparison
• Forecasting models extract the anticipated smell volatility for
future software evolution
• Therefore, estimated volatility for the last transition can be
employed as ranking criterion for refactoring suggestions
• Evaluation:
Rankings produced
by each model
Compare
Rankings produced
by actual volatility in
the last transition

27. Ranking Comparison
• To compare the similarity between alternative rankings (of the
same set) we used Spearman’s footrule distance
S
Fr
S
 1 ,  2   
i 1
A
B
C
D
E
F
A
B
C
D
E
F
NFr = 0
A
B
C
D
E
F
F
E
D
C
B
A
NFr = 1
A
B
C
D
E
F
A
C
B
E
F
D
NFr = 0.333
 1 (i )   2 (i )

28. Ranking Comparison - Spearman’s footrule
(Long Method / JFreeChart)
Actual
Random
Walk
0.6220
Historical
Average
0.3255
Exponential
Smoothing
0.5334
(Feature Envy / JMol)
Actual
Random
Walk
0.0096
Historical
Average
0.0210
Actual
Historical
Average
0.13
EWMA
0.3238
low frequency
of changes
Exponential
Smoothing
0.0199
(State Checking / JMol)
Random
Walk
0.07
high frequency
of changes
EWMA
0.0213
low frequency
of changes
Exponential
Smoothing
0.14
EWMA
0.13

29. Conclusions
Refactoring suggestions can be ranked:
• according to design criteria
• according to past source code changes (higher priority for
pieces of code that have been the subject of maintenance)
Simple forecasting models, such as Historical Average
• lowest RMSE error
• similar rankings to those obtained by actual volatility (frequent
changes)
Future Work #1: Analyze history at a more fine-grained level
Future Work #2: Combination of structural and historical criteria

30. Thank you for your attention
15th European Conference on Software Maintenance and Reengineering (CSMR 2011)