Pointcut Rejuvenation: Recovering Pointcut Expressions in Evolving Aspect-Oriented Software

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

Motivation

• Software changes over
time:

Motivation

time:

• Requirements evolve

Motivation

time:

• New platforms emerge
(e.g., mobile devices)

Motivation

time:

• New platforms emerge
(e.g., mobile devices)

• Frameworks
change(e.g., XML vs.
annotation-based)

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.

Approach

• Approaches made to
provide mechanical
assistance in evolution
tasks.

Approach

provide mechanical
tasks.

• Typically in the form of
plug-ins to IDEs.

Approach

provide mechanical
tasks.

plug-ins to IDEs.

• Ease the burden of
software maintenance
and evolution.

Approach

Restrict
workspace to only
• Approaches made to displays elements
provide mechanical relevant to the
assistance in evolution task
tasks.

plug-ins to IDEs.

• Ease the burden of
and evolution.

Approach

Restrict
workspace to only
• Approaches made to displays elements
provide mechanical relevant to the
assistance in evolution task
tasks.

plug-ins to IDEs.
Restructure
•code the burden of
Ease while preserving
semantics (i.e.,
and evolution.
refactoring)

Goal and Outline

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

Goal and Outline

Oriented software.
• Will present:

Goal and Outline

Oriented software.
• Will present:
• Existing work on altering broken pointcut
expressions using an automated technique.

Goal and Outline

Oriented software.
• Will present: Pointcut Rejuvenation


Goal and Outline

Oriented software.
• Will present:
• Current work on automatically detecting broken
pointcuts as the developer is typing.

Goal and Outline

Oriented software.
• Will present:
• Current work on automatically detecting broken
pointcuts as the developer is typing.
Pointcut
Change Prediction

Crosscutting Concerns in Software


�� Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.


• Crosscutting concerns (CCCs) affect many
• Code is usually:


• Scattered throughout many modules.


• Tangled with unrelated modules.


• Tangled with unrelated modules. include logging,
Classic CCCs

synchronization,
authentication.

Aspect-Oriented Programming

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


• CCC implementations encapsulated in advice.


• Pointcuts:


• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.


• Pointcuts:

Base code


• Pointcuts:
• Denote where a CCC applies.


• Pointcuts:
• Advice is:


• Pointcuts:
• Advice is:
• Bound to a pointcut.


• Pointcuts:
• Advice is:
• Executed whenever control reaches any join point
selected by the pointcut.


localized implementations of CCCs: Focus of
today’s talk
• Pointcuts:
• Advice is:
• Executed whenever control reaches any join point
selected by the pointcut.

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;
}
}

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;
}
}

Example Base Code

package p;
class A {
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;
}
}

Example Base Code

package p;
class A {
f
int a = f + 1;
character m.
void m2() {
int b = f + 2;
• Method bodies of m1 and }
m2 read from a field f. void n() {
f = 3;
}
}

Example Base Code

package p;
class A {
f
int a = f + 1;
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.
}

Pointcut Example

pointcut mayBeFragile() :
execution(* m*(..));

Pointcut Example


• Selects m1() and m2()
but not n().

Pointcut Example


but not n().

• Assume that correct join
points are selected.

Pointcut Example


but not n().

• Assume that correct join
points are selected.

CCC
applies to m1 and m2
but not p.

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.

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.

Pointcut Rejuvenation: Recovering Pointcut Expressions in Evolving Aspect-Oriented Software

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

void p() {
int d = f + 4;
}


W
ha
ta
po bo
int ut
cu th
t? e

void p() {
int d = f + 4;
}


• Same pointcut selects m1() and m2() but not
n() and p().

void p() {
int d = f + 4;
}


n() and p().

• Assume CCC applies to p().

void p() {
int d = f + 4;
}


n() and p().

• mayBeFragile() is fragile!

void p() {
int d = f + 4;
}


n() and p().

• p() silently fall out of pointcut’s scope.

void p() {
int d = f + 4;
}


n() and p().

• p() silently fall out of pointcut’s scope.
• May be difficult to identify in large base codes.

Phase I: Leverage Structural Commonality

• Build a Concern Graph [Robillard, Murphy ’02].

m1
gets declares

f gets m2 declares A
sets declares

n

• Extract commonalities between currently selected
join points.

m1
gets declares

sets declares

n

• 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

Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)

m1
gets declares

sets declares

n

Evaluating Patterns

{m1,m2}
m1
gets declares

sets declares

n

Evaluating Patterns
100%
conﬁdence!

{m1,m2}
m1
gets declares

sets declares

n

Evaluating Patterns
100%
conﬁdence!

{m1,m2} {m1,m2,n}
m1
gets declares

sets declares

n

Evaluating Patterns
100% 66%
conﬁdence! conﬁdence

{m1,m2} {m1,m2,n}
m1
gets declares

sets declares

n

Storing patterns for Phase II

100% 66%
conﬁdence! conﬁdence

XML

Storing patterns for Phase II

XML

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.

pointcut.
• Another dimension is the β evaluation:

pointcut.
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.

pointcut.
by the pointcut.
• Lastly, there is an abstractness evaluation:

pointcut.
by the pointcut.
• Considers the ratio of wild-cards (?) to concrete elements in
the pattern as patterns can be arbitrarily deep.

pointcut.
by the pointcut.
• 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.

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
ˆ

All join points
Pointcut

Pattern

All join points
Pointcut

Pattern

α

All join points
Pointcut
β
Pattern

α

All join points
Pointcut
β
Pattern

α

A ? ? ? ?

All join points
Pointcut
β
Pattern

α

A ? ? ? ?
abs

Phase II: Expression Recovery

void p() {
code


void p() {
code
m1
gets declares

sets declares

gets n declares

p


void p() {
code
m1
(?,gets, f)
gets (A,declares,?)
declares

sets declares

gets n declares

XML
p

(?,gets, f)
100%
conﬁdence!

{m1,m2,p}

(?,gets, f) execution(* m*(..))
100%
conﬁdence!

{m1,m2,p}

100%
conﬁdence!

{m1,m2,p} {m1,m2}

100%
conﬁdence!

{m1,m2,p} {m1,m2} = {p}

100%
conﬁdence!

{m1,m2,p} {m1,m2} = {p}

(A,declares,?)

100%
conﬁdence!

{m1,m2,p} {m1,m2} = {p}

(A,declares,?)

{m1,m2,n,p}

100%
conﬁdence!

{m1,m2,p} {m1,m2} = {p}

(A,declares,?)

66%
conﬁdence
{m1,m2,n,p}

100%
conﬁdence!

{m1,m2,p} {m1,m2} = {p}

(A,declares,?) execution(* m*(..))

66%
conﬁdence
{m1,m2,n,p}

100%
conﬁdence!

{m1,m2,p} {m1,m2} = {p}


66%
conﬁdence
{m1,m2,n,p} {m1,m2}

100%
conﬁdence!

{m1,m2,p} {m1,m2} = {p}


66%
conﬁdence
{m1,m2,n,p} {m1,m2} = {n,p}

100%
confidence!

{m1,m2,p} {m1,m2} = {p}


66%
confidence
{m1,m2,n,p} {m1,m2} = {n,p}

p is suggested with (100 + 66) / 2 ≈ 83% confidence

100%
confidence!

{m1,m2,p} {m1,m2} = {p}


66%
confidence
{m1,m2,n,p} {m1,m2} = {n,p}

n is suggested with 66% confidence

100%
confidence!

{m1,m2,p} {m1,m2} = {p}


66%
confidence
{m1,m2,n,p} {m1,m2} = {n,p}

n is suggested with 66% confidence
execution(* m*(..)) || execution (* p())

100%
confidence!

{m1,m2,p} {m1,m2} = {p}


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())

mplementation Implementation

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

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

Evaluation: Phase 2

• Applied to 3 multi-versioned AspectJ projects.

Evaluation: Phase 2

• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).

Evaluation: Phase 2

• Maximum pattern length set to 2 edges.

Evaluation: Phase 2

• Able to identify 93% of new shadows introduced in
later versions that were not selected by previous
pointcut representations.

Evaluation: Phase 2

• On average, 3.97 suggestions appeared before true
positives.

Evaluation: Phase 2

• On average, 3.97 suggestions appeared before true
positives.
• On average, 10.95 secs. required to rejuvenate a
pointcut.

Future work

• Improve performance

Future work

• Use graph reduction techniques [Robillard, Murphy,
’02].

Future work

’02].
• Faster engine (e.g., PROLOG-based).

Future work

’02].
• Less conservative analysis (e.g., RTA, VTA).

Future work

’02].
• Dynamic analysis for dynamic pointcuts.

Future work

’02].
• Dynamic analysis for dynamic pointcuts.
• Faster intermediate representations (e.g., Soot/ABC).

More Future Work

• Additional language features:

More Future Work

• Inter-type declarations.

More Future Work

• Advice code analysis.

More Future Work

• Additional forms of commonality:

More Future Work

• Source code version repository history information.

More Future Work

• Source code version repository history information.
• For example, several methods may have been
committed together in one SVN version.

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.

Pointcut Rejuvenation: Recovering Pointcut Expressions in Evolving Aspect-Oriented Software

Related slideshows

More Related Content

Pointcut Rejuvenation: Recovering Pointcut Expressions in Evolving Aspect-Oriented Software

Editor's Notes