Pointcut fragility is a well-documented problem in Aspect-Oriented Programming; changes to the base-code can lead to join points incorrectly falling in or out of the scope of pointcuts. In this paper, we present an automated approach that limits fragility problems by providing mechanical assistance in pointcut maintenance. The approach is based on harnessing arbitrarily deep structural commonalities between program elements corresponding to join points selected by a pointcut. The extracted patterns are then applied to later versions to offer suggestions of new join points that may require inclusion. To illustrate that the motivation behind our proposal is well founded, we first empirically establish that join points captured by a single pointcut typically portray a significant amount of unique structural commonality by analyzing patterns extracted from twenty-three AspectJ programs. Then, we demonstrate the usefulness of our technique by rejuvenating pointcuts in multiple versions of three of these programs. The results show that our parameterized heuristic algorithm was able to accurately and automatically infer the majority of new join points in subsequent software versions that were not captured by the original pointcuts.

1. Pointcut Rejuvenation: Recovering Pointcut
Expressions in Evolving Aspect-Oriented
Software
Raffi Khatchadourian, Ohio State University
Joint work with Phil Greenwood and Awais Rashid, Lancaster
University, UK and Guoqing Xu, Ohio State University
Work in progress at University of Tokyo with Hidehiko
Masuhara

2. Motivation

3. Motivation
• Software changes over
time:

4. Motivation
• Software changes over
time:
• Requirements evolve

5. Motivation
• Software changes over
time:
• Requirements evolve
• New platforms emerge
(e.g., mobile devices)

6. Motivation
• Software changes over
time:
• Requirements evolve
• New platforms emerge
(e.g., mobile devices)
• Frameworks
change(e.g., XML vs.
annotation-based)

7. Motivation

8. Motivation
Changing and/or maintaining large, complex software
systems can be non-trivial:
Tedious: May require changing many lines of
code.
Error-prone: Changes may be implemented
incorrectly.
May miss opportunities to produce
Omission-prone:
better code.

9. Motivation
Changing and/or maintaining large, complex software
systems can be non-trivial:
Tedious: May require changing many lines of
code.
Error-prone: Changes may be implemented
incorrectly.
May miss opportunities to produce
Omission-prone:
better code.

10. Motivation
Changing and/or maintaining large, complex software
systems can be non-trivial:
Tedious: May require changing many lines of
code.
Error-prone: Changes may be implemented
incorrectly.
May miss opportunities to produce
Omission-prone:
better code.

11. Motivation
Changing and/or maintaining large, complex software
systems can be non-trivial:
Tedious: May require changing many lines of
code.
Error-prone: Changes may be implemented
incorrectly.
May miss opportunities to produce
Omission-prone:
better code.

12. Approach

13. Approach
• Approaches made to
provide mechanical
assistance in evolution
tasks.

14. Approach
• Approaches made to
provide mechanical
assistance in evolution
tasks.
• Typically in the form of
plug-ins to IDEs.

15. Approach
• Approaches made to
provide mechanical
assistance in evolution
tasks.
• Typically in the form of
plug-ins to IDEs.
• Ease the burden of
software maintenance
and evolution.

16. Approach
Restrict
workspace to only
• Approaches made to displays elements
provide mechanical relevant to the
assistance in evolution task
tasks.
• Typically in the form of
plug-ins to IDEs.
• Ease the burden of
software maintenance
and evolution.

17. Approach
Restrict
workspace to only
• Approaches made to displays elements
provide mechanical relevant to the
assistance in evolution task
tasks.
• Typically in the form of
plug-ins to IDEs.
Restructure
•code the burden of
Ease while preserving
semantics (i.e.,
software maintenance
and evolution.
refactoring)

18. Goal and Outline

19. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.

20. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present:

21. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present:
• Existing work on altering broken pointcut
expressions using an automated technique.

22. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present: Pointcut Rejuvenation
• Existing work on altering broken pointcut
expressions using an automated technique.

23. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present:
• Existing work on altering broken pointcut
expressions using an automated technique.
• Current work on automatically detecting broken
pointcuts as the developer is typing.

24. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present:
• Existing work on altering broken pointcut
expressions using an automated technique.
• Current work on automatically detecting broken
pointcuts as the developer is typing.
Pointcut
Change Prediction

25. Crosscutting Concerns in Software

26. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.

27. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
• Code is usually:

28. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
• Code is usually:
• Scattered throughout many modules.

29. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
• Code is usually:
• Scattered throughout many modules.
• Tangled with unrelated modules.

30. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
• Code is usually:
• Scattered throughout many modules.
• Tangled with unrelated modules. include logging,
Classic CCCs
synchronization,
authentication.

31. Aspect-Oriented Programming

32. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:

33. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.

34. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:

35. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.

36. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
Base code

37. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.

38. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
• Advice is:

39. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
• Advice is:
• Bound to a pointcut.

40. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
• Advice is:
• Bound to a pointcut.
• Executed whenever control reaches any join point
selected by the pointcut.

41. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs: Focus of
today’s talk
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
• Advice is:
• Bound to a pointcut.
• Executed whenever control reaches any join point
selected by the pointcut.

42. Example Base Code
package p;
class A {
int f;
void m1() {
int a = f + 1;
}
void m2() {
int b = f + 2;
}
void n() {
f = 3;
}
}

43. Example Base Code
package p;
class A {
int f;
void m1() {
int a = f + 1;
}
void m2() {
int b = f + 2;
}
void n() {
f = 3;
}
}

44. Example Base Code
package p;
class A {
• Two methods whose int f;
name begins with the
character m. void m1
m1() {
int a = f + 1;
}
void m2
m2() {
int b = f + 2;
}
void n() {
f = 3;
}
}

45. Example Base Code
package p;
class A {
• Two methods whose int f;
name begins with the
character m. void m1() {
int a = f + 1;
• One method whose name }
does not begin with the
character m.
void m2() {
int b = f + 2;
}
void n
n() {
f = 3;
}
}

46. Example Base Code
package p;
class A {
• Two methods whose int f;
f
name begins with the
character m. void m1() {
int a = f + 1;
• One method whose name }
does not begin with the
character m.
void m2() {
int b = f + 2;
• Method bodies of m1 and }
m2 read from a field f. void n() {
f = 3;
}
}

47. Example Base Code
package p;
class A {
• Two methods whose int f;
f
name begins with the
character m. void m1() {
int a = f + 1;
• One method whose name }
does not begin with the
character m.
void m2() {
int b = f + 2;
• Method bodies of m1 and }
m2 read from a field f. void n() {
f = 3;
• Method body of n writes }
to field f.
}

48. Pointcut Example
pointcut mayBeFragile() :
execution(* m*(..));

49. Pointcut Example
pointcut mayBeFragile() :
execution(* m*(..));
• Selects m1() and m2()
but not n().

50. Pointcut Example
pointcut mayBeFragile() :
execution(* m*(..));
• Selects m1() and m2()
but not n().
• Assume that correct join
points are selected.

51. Pointcut Example
pointcut mayBeFragile() :
execution(* m*(..));
• Selects m1() and m2()
but not n().
• Assume that correct join
points are selected.
CCC
applies to m1 and m2
but not p.

52. Pointcut Properties

53. Pointcut Properties
• A pointcut is robust if it is able to continue to capture
the intended join points in future base code versions
without being altered.

54. Pointcut Properties
• A pointcut is robust if it is able to continue to capture
the intended join points in future base code versions
without being altered.
• Otherwise, it is fragile.

56. void p() {
int d = f + 4; A new method
} is added to the base
code

57. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
W
ha
ta
po bo
int ut
cu th
t? e

58. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().

59. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
• Assume CCC applies to p().

60. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
• Assume CCC applies to p().
• mayBeFragile() is fragile!

61. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
• Assume CCC applies to p().
• mayBeFragile() is fragile!
• p() silently fall out of pointcut’s scope.

62. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
• Assume CCC applies to p().
• mayBeFragile() is fragile!
• p() silently fall out of pointcut’s scope.
• May be difficult to identify in large base codes.

63. Phase I: Leverage Structural Commonality

64. Phase I: Leverage Structural Commonality
• Build a Concern Graph [Robillard, Murphy ’02].
m1
gets declares
f gets m2 declares A
sets declares
n

65. Phase I: Leverage Structural Commonality
• Build a Concern Graph [Robillard, Murphy ’02].
• Extract commonalities between currently selected
join points.
m1
gets declares
f gets m2 declares A
sets declares
n

66. Phase I: Leverage Structural Commonality
• Build a Concern Graph [Robillard, Murphy ’02].
• Extract commonalities between currently selected
join points.
• Find common sinks and sources in the graph.
m1
gets (A,declares,?)
declares
f (?,gets, f)
gets m2 declares A
sets declares
n

67. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
m1
gets declares
f gets m2 declares A
sets declares
n

68. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
{m1,m2}
m1
gets declares
f gets m2 declares A
sets declares
n

69. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
100%
confidence!
{m1,m2}
m1
gets declares
f gets m2 declares A
sets declares
n

70. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
100%
confidence!
{m1,m2} {m1,m2,n}
m1
gets declares
f gets m2 declares A
sets declares
n

71. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
100% 66%
confidence! confidence
{m1,m2} {m1,m2,n}
m1
gets declares
f gets m2 declares A
sets declares
n

72. Storing patterns for Phase II
(?,gets, f) (A,declares,?)
100% 66%
confidence! confidence
XML

73. Storing patterns for Phase II
XML

74. It’s a little more complicated ...

75. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.

76. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:

77. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.

78. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:

79. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.

80. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.
• Lastly, there is an abstractness evaluation:

81. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.
• Lastly, there is an abstractness evaluation:
• Considers the ratio of wild-cards (?) to concrete elements in
the pattern as patterns can be arbitrarily deep.

82. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.
• Lastly, there is an abstractness evaluation:
• Considers the ratio of wild-cards (?) to concrete elements in
the pattern as patterns can be arbitrarily deep.
• All three dimensions are combined to produce a patterns
confidence value.

83. SACTIONS OF SOFTWARE ENGINEERING, VOL. X, NO. Y, Z 20AB

0 if | Match (ˆ , Paths ( C G + ))| = 0
π
err (ˆ , PCE) =
π |PCE ∩ Match (ˆ , Paths ( C G + ))|
π
1 − otherwise
| Match (ˆ , Paths ( C G ))|
π +

1 if |PCE| = 0
err (ˆ , PCE) =
π |PCE ∩ Match (ˆ , Paths ( C G + ))|
π
1 − otherwise
|PCE|

1 if |ˆ | = 0
π
abs (ˆ ) =
π |ˆ | − |W(ˆ )|
π π
1 − otherwise
|ˆ |
π
conf (ˆ , PCE) =
π 1 − [err (ˆ , PCE)(1 − abs (ˆ )) + err (ˆ , PCE) abs (ˆ )]
π π π π
Pattern attribute equations.
allSpeed). Thus, the err rate for this pattern projection of wild card elements contained
e PCE found on line 3 of Figure 2, which selects π . Likewise, |W(ˆ )| represents the number o
ˆ π
ution of methods DieselEngine.increase(Fuel) and elements contained within pattern π . Then, t
ˆ

85. All join points

86. All join points
Pointcut

87. All join points
Pointcut
Pattern

88. All join points
Pointcut
Pattern
α

89. All join points
Pointcut
β
Pattern
α

90. All join points
Pointcut
β
Pattern
α
A ? ? ? ?

91. All join points
Pointcut
β
Pattern
α
A ? ? ? ?
abs

92. Phase II: Expression Recovery

93. Phase II: Expression Recovery
void p() {
int d = f + 4; A new method
} is added to the base
code

94. Phase II: Expression Recovery
void p() {
int d = f + 4; A new method
} is added to the base
code
m1
gets declares
f gets m2 declares A
sets declares
gets n declares
p

95. Phase II: Expression Recovery
void p() {
int d = f + 4; A new method
} is added to the base
code
m1
(?,gets, f)
gets (A,declares,?)
declares
f gets m2 declares A
sets declares
gets n declares
XML
p

97. (?,gets, f)

98. (?,gets, f)
{m1,m2,p}

99. (?,gets, f)
100%
confidence!
{m1,m2,p}

100. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p}

101. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2}

102. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}

103. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?)

104. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?)
{m1,m2,n,p}

105. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?)
66%
confidence
{m1,m2,n,p}

106. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?) execution(* m*(..))
66%
confidence
{m1,m2,n,p}

107. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?) execution(* m*(..))
66%
confidence
{m1,m2,n,p} {m1,m2}

108. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?) execution(* m*(..))
66%
confidence
{m1,m2,n,p} {m1,m2} = {n,p}

109. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?) execution(* m*(..))
66%
confidence
{m1,m2,n,p} {m1,m2} = {n,p}
p is suggested with (100 + 66) / 2 ≈ 83% confidence

110. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?) execution(* m*(..))
66%
confidence
{m1,m2,n,p} {m1,m2} = {n,p}
p is suggested with (100 + 66) / 2 ≈ 83% confidence
n is suggested with 66% confidence

111. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?) execution(* m*(..))
66%
confidence
{m1,m2,n,p} {m1,m2} = {n,p}
p is suggested with (100 + 66) / 2 ≈ 83% confidence
n is suggested with 66% confidence
execution(* m*(..)) || execution (* p())

112. (?,gets, f) execution(* m*(..))
100%
confidence!
{m1,m2,p} {m1,m2} = {p}
(A,declares,?) execution(* m*(..))
66%
confidence
{m1,m2,n,p} {m1,m2} = {n,p}
p is suggested with (100 + 66) / 2 ≈ 83% Suggestions
confidence
n is suggested with 66% confidence sorted by confidence
in IDE
execution(* m*(..)) || execution (* p())

113. mplementation Implementation

114. Evaluation: Phase I
subject KL. cls. PC shd. KP. α β t (s)
AJHotDraw 21.8 298 32 90 3.36 0.32 0.06 101
Ants 1.57 33 22 297 1.25 0.15 0.23 43
Bean 0.12 2 2 4 0.02 0.24 0.23 4
Contract4J 10.7 199 15 350 1.80 0.26 0.44 115
DCM 1.68 29 8 343 2.47 0.15 0.45 4
Figure 0.10 5 1 6 0.02 0.11 0.45 8
Glassbox 26.0 430 55 208 2.62 0.1 0.29 228
HealthWatcher 5.72 76 27 122 1.00 0.21 0.16 22
Cactus 7.57 93 4 222 2.15 0.21 0.52 8
LoD 1.59 29 5 164 0.54 0.15 0.41 46
MobilePhoto 3.80 52 25 25 0.78 0.23 0.00 11
MySQLa 44.0 187 2 3016 17.6 0.12 0.58 379
NullCheck 1.47 27 1 112 0.10 0.17 0.55 293
N-Version 0.55 15 4 9 0.08 0.19 0.24 1
Quicksort 0.07 3 4 7 0.06 0.19 0.15 3
RacerAJ 0.58 13 4 9 0.02 0.23 0.09 5
RecoveryCache 0.22 3 4 14 0.07 0.11 0.21 6
Spacewar 1.42 21 9 58 0.23 0.15 0.22 37
StarJ-Pool 38.2 511 1 3 0.07 0.25 0.00 75
Telecom 0.28 10 4 5 0.03 0.21 0.02 7
Tetris 1.04 8 18 27 0.50 0.16 0.01 14
TollSystem 5.20 88 35 85 1.68 0.26 0.06 20
Tracing 0.37 5 16 132 0.68 0.17 0.4 1
Totals: 174 2137 298 5308 37.1 0.18 0.16 1431

115. Evaluation: Phase I
subject KL. cls. PC shd. KP. α β t (s)
AJHotDraw 21.8 298 32 90 3.36 0.32 0.06 101
Ants 1.57 33 22 297 1.25 0.15 0.23 43
Bean 0.12 2 2 4 0.02 0.24 0.23 4
Contract4J 10.7 199 15 350 1.80 0.26 0.44 115
DCM 1.68 29 8 343 2.47 0.15 0.45 4
Figure 0.10 5 1 6 0.02 0.11 0.45 8
Glassbox 26.0 430 55 208 2.62 0.1 0.29 228
HealthWatcher 5.72 76 27 122 1.00 0.21 0.16 22
Cactus 7.57 93 4 222 2.15 0.21 0.52 8
LoD 1.59 29 5 164 0.54 0.15 0.41 46
MobilePhoto 3.80 52 25 25 0.78 0.23 0.00 11
MySQLa 44.0 187 2 3016 17.6 0.12 0.58 379
NullCheck 1.47 27 1 112 0.10 0.17 0.55 293
N-Version 0.55 15 4 9 0.08 0.19 0.24 1
Quicksort 0.07 3 4 7 0.06 0.19 0.15 3
RacerAJ 0.58 13 4 9 0.02 0.23 0.09 5
RecoveryCache 0.22 3 4 14 0.07 0.11 0.21 6
Spacewar 1.42 21 9 58 0.23 0.15 0.22 37
StarJ-Pool 38.2 511 1 3 0.07 0.25 0.00 75
Telecom 0.28 10 4 5 0.03 0.21 0.02 7
Tetris 1.04 8 18 27 0.50 0.16 0.01 14
TollSystem 5.20 88 35 85 1.68 0.26 0.06 20
Tracing 0.37 5 16 132 0.68 0.17 0.4 1
Totals: 174 2137 298 5308 37.1 0.18 0.16 1431

116. Evaluation: Phase I
subject KL. cls. PC shd. KP. α β t (s)
AJHotDraw 21.8 298 32 90 3.36 0.32 0.06 101
Ants 1.57 33 22 297 1.25 0.15 0.23 43
Bean 0.12 2 2 4 0.02 0.24 0.23 4
Contract4J 10.7 199 15 350 1.80 0.26 0.44 115
DCM 1.68 29 8 343 2.47 0.15 0.45 4
Figure 0.10 5 1 6 0.02 0.11 0.45 8
Glassbox 26.0 430 55 208 2.62 0.1 0.29 228
HealthWatcher 5.72 76 27 122 1.00 0.21 0.16 22
Cactus 7.57 93 4 222 2.15 0.21 0.52 8
LoD 1.59 29 5 164 0.54 0.15 0.41 46
MobilePhoto 3.80 52 25 25 0.78 0.23 0.00 11
MySQLa 44.0 187 2 3016 17.6 0.12 0.58 379
NullCheck 1.47 27 1 112 0.10 0.17 0.55 293
N-Version 0.55 15 4 9 0.08 0.19 0.24 1
Quicksort 0.07 3 4 7 0.06 0.19 0.15 3
RacerAJ 0.58 13 4 9 0.02 0.23 0.09 5
4.8 secs per
RecoveryCache
Spacewar
0.22
1.42
3
21
4
9
14 0.07 0.11 0.21
58 0.23 0.15 0.22
6
37
pointcut StarJ-Pool
Telecom
38.2 511
0.28 10
1
4
3 0.07 0.25 0.00
5 0.03 0.21 0.02
75
7
Tetris 1.04 8 18 27 0.50 0.16 0.01 14
TollSystem 5.20 88 35 85 1.68 0.26 0.06 20
Tracing 0.37 5 16 132 0.68 0.17 0.4 1
Totals: 174 2137 298 5308 37.1 0.18 0.16 1431

117. Evaluation: Phase 2

118. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.

119. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).

120. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
• Maximum pattern length set to 2 edges.

121. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
• Maximum pattern length set to 2 edges.
• Able to identify 93% of new shadows introduced in
later versions that were not selected by previous
pointcut representations.

122. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
• Maximum pattern length set to 2 edges.
• Able to identify 93% of new shadows introduced in
later versions that were not selected by previous
pointcut representations.
• On average, 3.97 suggestions appeared before true
positives.

123. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
• Maximum pattern length set to 2 edges.
• Able to identify 93% of new shadows introduced in
later versions that were not selected by previous
pointcut representations.
• On average, 3.97 suggestions appeared before true
positives.
• On average, 10.95 secs. required to rejuvenate a
pointcut.

124. Future work

125. Future work
• Improve performance

126. Future work
• Improve performance
• Use graph reduction techniques [Robillard, Murphy,
’02].

127. Future work
• Improve performance
• Use graph reduction techniques [Robillard, Murphy,
’02].
• Faster engine (e.g., PROLOG-based).

128. Future work
• Improve performance
• Use graph reduction techniques [Robillard, Murphy,
’02].
• Faster engine (e.g., PROLOG-based).
• Less conservative analysis (e.g., RTA, VTA).

129. Future work
• Improve performance
• Use graph reduction techniques [Robillard, Murphy,
’02].
• Faster engine (e.g., PROLOG-based).
• Less conservative analysis (e.g., RTA, VTA).
• Dynamic analysis for dynamic pointcuts.

130. Future work
• Improve performance
• Use graph reduction techniques [Robillard, Murphy,
’02].
• Faster engine (e.g., PROLOG-based).
• Less conservative analysis (e.g., RTA, VTA).
• Dynamic analysis for dynamic pointcuts.
• Faster intermediate representations (e.g., Soot/ABC).

131. More Future Work

132. More Future Work
• Additional language features:

133. More Future Work
• Additional language features:
• Inter-type declarations.

134. More Future Work
• Additional language features:
• Inter-type declarations.
• Advice code analysis.

135. More Future Work
• Additional language features:
• Inter-type declarations.
• Advice code analysis.
• Additional forms of commonality:

136. More Future Work
• Additional language features:
• Inter-type declarations.
• Advice code analysis.
• Additional forms of commonality:
• Source code version repository history information.

137. More Future Work
• Additional language features:
• Inter-type declarations.
• Advice code analysis.
• Additional forms of commonality:
• Source code version repository history information.
• For example, several methods may have been
committed together in one SVN version.

138. Downloads
• Tool research prototype publicly available at http://
code.google.com/p/rejuvenate-pc.
• Research related material publicly available at http://
sites.google.com/site/pointcutrejuvenation.