| Date post: | 19-Jun-2015 |
| Category: |
Technology |
| Upload: | raffi-khatchadourian |
| View: | 474 times |
| Download: | 0 times |
Rejuvenate PointcutA Tool for Pointcut Expression Recovery in Evolving
Aspect-Oriented Software
Raffi Khatchadourian1 Phil Greenwood2 Awais Rashid2
Guoqing Xu1
1Ohio State University
2Lancaster University
International Conference on Aspect-Oriented SoftwareDevelopment, 2009
A
MotivationApproach
EvaluationMore Information
Outline
1 Motivation
2 Approach
3 Evaluation
4 More Information
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Base-code
Two methods whosename begins with thecharacter m.
package p;
public class A {
int f;
void m1() {
int a = f + 1;
}
void m2() {
int b = f + 2;
}
void n() {
int c = f + 3;
}
}
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Base-code
Two methods whosename begins with thecharacter m.
One method whose namedoes not begin with thecharacter m.
package p;
public class A {
int f;
void m1() {
int a = f + 1;
}
void m2() {
int b = f + 2;
}
void n() {
int c = f + 3;
}
}
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Base-code
Two methods whosename begins with thecharacter m.
One method whose namedoes not begin with thecharacter m.
All method bodies accessa field f.
package p;
public class A {
int f;
void m1() {
int a = f + 1;
}
void m2() {
int b = f + 2;
}
void n() {
int c = f + 3;
}
}
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Along Came a Pointcut
pointcut fragile() : execution(* m*(..));
Base-code V1
Selects m1() and m2() but not n().
Assume pointcut is correct in V1.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Along Came a Pointcut
pointcut fragile() : execution(* m*(..));
Base-code V1
Selects m1() and m2() but not n().
Assume pointcut is correct in V1.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Along Came a Pointcut
pointcut fragile() : execution(* m*(..));
Base-code V1
Selects m1() and m2() but not n().
Assume pointcut is correct in V1.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
Evolution
// . . .void p() {
int d = f + 4;
}
// . . .
pointcut fragile() : execution(* m*(..));
Base-code V2
Same pointcut selects m1() and m2() but not n() and p().
Fragile!
CCC applies to p() in V2 but not selected!
How to identify such join points as code evolves?
Evolution
// . . .void p() {
int d = f + 4;
}
// . . .
pointcut fragile() : execution(* m*(..));
Base-code V2
Same pointcut selects m1() and m2() but not n() and p().
Fragile!
CCC applies to p() in V2 but not selected!
How to identify such join points as code evolves?
Evolution
// . . .void p() {
int d = f + 4;
}
// . . .
pointcut fragile() : execution(* m*(..));
Base-code V2
Same pointcut selects m1() and m2() but not n() and p().
Fragile!
CCC applies to p() in V2 but not selected!
How to identify such join points as code evolves?
Evolution
// . . .void p() {
int d = f + 4;
}
// . . .
pointcut fragile() : execution(* m*(..));
Base-code V2
Same pointcut selects m1() and m2() but not n() and p().
Fragile!
CCC applies to p() in V2 but not selected!
How to identify such join points as code evolves?
Evolution
// . . .void p() {
int d = f + 4;
}
// . . .
pointcut fragile() : execution(* m*(..));
Base-code V2
Same pointcut selects m1() and m2() but not n() and p().
Fragile!
CCC applies to p() in V2 but not selected!
How to identify such join points as code evolves?
Pointcut Rejuvenation: Leveraging Commonality
Phase I: Analysis using Concern Graphs
Extract commonalities between currently selected join points.
Phase II: Rejuvenation
Apply extracted patterns to new version of the base-code.
A.m2()
A.f
gets_field
A.n()gets_field
Adeclares_field
A.m1()
declares_method
declares_method
declares_method
gets_field
pcontains
Would execution(* A.n()) also be suggested?
Pointcut Rejuvenation: Leveraging Commonality
Phase I: Analysis using Concern Graphs
Extract commonalities between currently selected join points.
Phase II: Rejuvenation
Apply extracted patterns to new version of the base-code.
A.m2()
A.f
gets_field
A.n()gets_field
Adeclares_field
A.m1()
declares_methoddeclares_method
declares_method
gets_field
pcontains
Would execution(* A.n()) also be suggested?
Pointcut Rejuvenation: Leveraging Commonality
Phase I: Analysis using Concern Graphs
Extract commonalities between currently selected join points.
Phase II: Rejuvenation
Apply extracted patterns to new version of the base-code.
A.m2()
A.f
gets_field
A.n()gets_field
Adeclares_field
A.m1()
declares_method
declares_method
declares_method
gets_field
pcontains
Would execution(* A.n()) also be suggested?
Pointcut Rejuvenation: Leveraging Commonality
Phase I: Analysis using Concern Graphs
Extract commonalities between currently selected join points.
Phase II: Rejuvenation
Apply extracted patterns to new version of the base-code.
A.m2()
A.f
gets_field
A.n()gets_field
Adeclares_field
A.m1()
declares_method
declares_method
declares_method
gets_field
pcontains
Would execution(* A.n()) also be suggested?
Pointcut Rejuvenation: Leveraging Commonality
Phase I: Analysis using Concern Graphs
Extract commonalities between currently selected join points.
Phase II: Rejuvenation
Apply extracted patterns to new version of the base-code.
A.m2()
A.f
gets_field
A.n()
A.p()
gets_field
gets_field
Adeclares_field
A.m1()
declares_method
declares_method
declares_method
declares_method
gets_field
pcontains
Would execution(* A.n()) also be suggested?
Pointcut Rejuvenation: Leveraging Commonality
Phase I: Analysis using Concern Graphs
Extract commonalities between currently selected join points.
Phase II: Rejuvenation
Apply extracted patterns to new version of the base-code.
A.m2()
A.f
gets_field
A.n()
A.p()
gets_field
gets_field
Adeclares_field
A.m1()
declares_method
declares_method
declares_method
declares_method
gets_field
pcontains
Would execution(* A.n()) also be suggested?
Pointcut Rejuvenation: Leveraging Commonality
Phase I: Analysis using Concern Graphs
Extract commonalities between currently selected join points.
Phase II: Rejuvenation
Apply extracted patterns to new version of the base-code.
A.m2()
A.f
gets_field
A.n()
A.p()
gets_field
gets_field
Adeclares_field
A.m1()
declares_method
declares_method
declares_method
declares_method
gets_field
pcontains
Would execution(* A.n()) also be suggested?
Pointcut Rejuvenation: Leveraging Commonality
Phase I: Analysis using Concern Graphs
Extract commonalities between currently selected join points.
Phase II: Rejuvenation
Apply extracted patterns to new version of the base-code.
A.m2()
A.f
gets_field
A.n()
A.p()
gets_field
gets_field
Adeclares_field
A.m1()
declares_method
declares_method
declares_method
declares_method
gets_field
pcontains
Would execution(* A.n()) also be suggested?
Suggestion Ranking Scheme
Measurements for Suggestion Ranking
α error: How strong are the relationships between advisedshadows compared to ones captured by a pattern?
β error: How well does the pattern express the sameintentions as the pointcut?
Suggestion Ranking Scheme
Measurements for Suggestion Ranking
α error: How strong are the relationships between advisedshadows compared to ones captured by a pattern?
β error: How well does the pattern express the sameintentions as the pointcut?
All Join Point Shadows
Suggestion Ranking Scheme
Measurements for Suggestion Ranking
α error: How strong are the relationships between advisedshadows compared to ones captured by a pattern?
β error: How well does the pattern express the sameintentions as the pointcut?
All Join Point Shadows! a join point shadow; code corresponding to a join pointA a piece of adviceApce a pointcut bound to advice A; a set of join point shadowsApce! a subsequent revision of Apce
P the original program, the underlying base-codeP ! a subsequence revision of program P!P the set of join point shadows contained within program PIGP a finite graph representing structural relationships be-
tween program elements in P" an acyclic path (sequence of arcs) in IGP ; an intention"P a set of acyclic paths derived from program P"̂ an intention pattern (sequence of vertices and arcs) de-
rived from ", possibly containing wildcards"̂P a set of intention patterns derived from program P
Figure 4. Algorithm formalism notation.
produced successfully inferring new join points that shouldbe incorporated in a revised version of the PCE.
For the sake of presentation, we further make severalsimplifying assumptions about the underlying source codeto be analyzed; we discuss in Section 4.1 how much ofthese are relaxed in our implementation. We assume thatthe source code utilizes only a subset of weaving semanticsavailable to the underlying AO language, such as AspectJ[31]. Specifically, we exclude the ability of an aspect to stat-ically crosscut a base program, i.e., introduce and modifyfacets of the base-code at compile time (e.g., member intro-duction, class hierarchy alteration). Furthermore, althoughit is possible for a PCE to capture join points associatedwithin an advice body (possibly the one it is bound to), weadopt the perspective that aspects are indeed separate fromthe base-code; advice may only apply to join points associ-ated with classes, interfaces, and other Java types. We alsoassume that we are able to statically identify all referencesto program entities contained within the base-code. This as-sumption could be invalidated through the use of reflectionand custom class loaders. Moreover, we assume that theoriginal source code successfully compiles under a AJDT1.62 compiler.
Recall that a join point refers to a well-defined point inthe execution of the base-code; thus, the definition of a joinpoint is dynamic in nature. A join point shadow, on theother hand, refers to base-code corresponding to a join point[50], i.e., a point in the program text where the compilermay actually perform the weaving [39]. Whether or not thecompiler actually performs weaving at that point is depen-dent on (i) advice being applicable at that point, and (ii)possible dynamic conditions being met. As such, we con-sider a given program P as consisting of a set of join pointshadows !P (see Figure 4) that may or may not be currentlyunder the influence of advice3. Moreover, a given piece of
2http://www.eclipse.org/ajdt3This definition differs slightly from those given in the literature.
function Rejuvenate(Apce ,P,P !, d)
1: IGP ! BuildGraph(P) /*Construct the intention graph forthe original program*/
2: "̂P ! CreatePatterns(Apce , IGP , d) /*Derive intentionpatterns relevant to the PCE from the graph of the originalprogram*/
3: IGP! ! BuildGraph(P !) /*Construct the intention graphfor the revised program*/
4: "̂P! ! CreatePatterns(Upce , IGP! , d) /*Derive all possi-ble intention patterns from the graph of the revised program*/
5: "̂P"P! ! "̂P " "̂P! /*Intersect the patterns derived fromthe old version with the ones from the new version.*/
6: S ! MakeSuggestions("̂P"P! , IGP!) /*Create a set ofsuggestion, confidence pairs*/
7: Apce! ! ! /*The rejuvenated PCE to be returned*/8: for all (!, c) # Sort(S) do /*For all suggestion, confidence
pairs by descending confidence*/9: Suggest(!, c)
10: if Selected(!) then11: Apce! ! Apce! $ {!}12: end if13: end for14: return Apce!
Figure 5. Top-level rejuvenation algorithm.
advice A specifies its applicability to a base program P viaits bound pointcut expression Apce , which selects a sub-set of shadows contained within P , i.e., A applies to P at!P !Apce . Therefore, each ! " !P !Apce specifies whereA should apply to P but does not specify when. That is,we assume that no dynamic conditions are associated withApce ; thus, we utilize solely static information in our anal-ysis. Section 4.1 discusses how our implementation conser-vatively relaxes this assumption so that PCEs utilizing dy-namic conditions may nevertheless be used as input to ourtool; in Section 6 we briefly touch on how the approach pre-sented here may be extended to leverage dynamic analysistechniques in light of such PCEs.
Lastly, we assume that we can accurately resolve thedeclaration of a particular piece of advice across varyingversions of the software. This assumption is important toour analysis since, in AO languages like AspectJ, advice isconsidered to be anonymous, which may make it difficultto track in consequent versions. Section 4.1 also discusseshow our tool enforces the validity of this assumpiton in or-der to make rejuvenation possible.
3.2. Pointcut Rejuvenation
Figure 5 depicts the Rejuvenate function, the top-levelpointcut rejuventation algorithm that drives the approach.Input to the function is a pointcut Apce from the originalprogram P to be recovered as a result of the new version ofthe program P !. Conceptually, applying this function to the
4
Suggestion Ranking Scheme
Measurements for Suggestion Ranking
α error: How strong are the relationships between advisedshadows compared to ones captured by a pattern?
β error: How well does the pattern express the sameintentions as the pointcut?
All Join Point Shadows! a join point shadow; code corresponding to a join pointA a piece of adviceApce a pointcut bound to advice A; a set of join point shadowsApce! a subsequent revision of Apce
P the original program, the underlying base-codeP ! a subsequence revision of program P!P the set of join point shadows contained within program PIGP a finite graph representing structural relationships be-
tween program elements in P" an acyclic path (sequence of arcs) in IGP ; an intention"P a set of acyclic paths derived from program P"̂ an intention pattern (sequence of vertices and arcs) de-
rived from ", possibly containing wildcards"̂P a set of intention patterns derived from program P
Figure 4. Algorithm formalism notation.
produced successfully inferring new join points that shouldbe incorporated in a revised version of the PCE.
For the sake of presentation, we further make severalsimplifying assumptions about the underlying source codeto be analyzed; we discuss in Section 4.1 how much ofthese are relaxed in our implementation. We assume thatthe source code utilizes only a subset of weaving semanticsavailable to the underlying AO language, such as AspectJ[31]. Specifically, we exclude the ability of an aspect to stat-ically crosscut a base program, i.e., introduce and modifyfacets of the base-code at compile time (e.g., member intro-duction, class hierarchy alteration). Furthermore, althoughit is possible for a PCE to capture join points associatedwithin an advice body (possibly the one it is bound to), weadopt the perspective that aspects are indeed separate fromthe base-code; advice may only apply to join points associ-ated with classes, interfaces, and other Java types. We alsoassume that we are able to statically identify all referencesto program entities contained within the base-code. This as-sumption could be invalidated through the use of reflectionand custom class loaders. Moreover, we assume that theoriginal source code successfully compiles under a AJDT1.62 compiler.
Recall that a join point refers to a well-defined point inthe execution of the base-code; thus, the definition of a joinpoint is dynamic in nature. A join point shadow, on theother hand, refers to base-code corresponding to a join point[50], i.e., a point in the program text where the compilermay actually perform the weaving [39]. Whether or not thecompiler actually performs weaving at that point is depen-dent on (i) advice being applicable at that point, and (ii)possible dynamic conditions being met. As such, we con-sider a given program P as consisting of a set of join pointshadows !P (see Figure 4) that may or may not be currentlyunder the influence of advice3. Moreover, a given piece of
2http://www.eclipse.org/ajdt3This definition differs slightly from those given in the literature.
function Rejuvenate(Apce ,P,P !, d)
1: IGP ! BuildGraph(P) /*Construct the intention graph forthe original program*/
2: "̂P ! CreatePatterns(Apce , IGP , d) /*Derive intentionpatterns relevant to the PCE from the graph of the originalprogram*/
3: IGP! ! BuildGraph(P !) /*Construct the intention graphfor the revised program*/
4: "̂P! ! CreatePatterns(Upce , IGP! , d) /*Derive all possi-ble intention patterns from the graph of the revised program*/
5: "̂P"P! ! "̂P " "̂P! /*Intersect the patterns derived fromthe old version with the ones from the new version.*/
6: S ! MakeSuggestions("̂P"P! , IGP!) /*Create a set ofsuggestion, confidence pairs*/
7: Apce! ! ! /*The rejuvenated PCE to be returned*/8: for all (!, c) # Sort(S) do /*For all suggestion, confidence
pairs by descending confidence*/9: Suggest(!, c)
10: if Selected(!) then11: Apce! ! Apce! $ {!}12: end if13: end for14: return Apce!
Figure 5. Top-level rejuvenation algorithm.
advice A specifies its applicability to a base program P viaits bound pointcut expression Apce , which selects a sub-set of shadows contained within P , i.e., A applies to P at!P !Apce . Therefore, each ! " !P !Apce specifies whereA should apply to P but does not specify when. That is,we assume that no dynamic conditions are associated withApce ; thus, we utilize solely static information in our anal-ysis. Section 4.1 discusses how our implementation conser-vatively relaxes this assumption so that PCEs utilizing dy-namic conditions may nevertheless be used as input to ourtool; in Section 6 we briefly touch on how the approach pre-sented here may be extended to leverage dynamic analysistechniques in light of such PCEs.
Lastly, we assume that we can accurately resolve thedeclaration of a particular piece of advice across varyingversions of the software. This assumption is important toour analysis since, in AO languages like AspectJ, advice isconsidered to be anonymous, which may make it difficultto track in consequent versions. Section 4.1 also discusseshow our tool enforces the validity of this assumpiton in or-der to make rejuvenation possible.
3.2. Pointcut Rejuvenation
Figure 5 depicts the Rejuvenate function, the top-levelpointcut rejuventation algorithm that drives the approach.Input to the function is a pointcut Apce from the originalprogram P to be recovered as a result of the new version ofthe program P !. Conceptually, applying this function to the
4
12
err!(!̂,Apce) =
8><>:
0 if |Match(!̂,Paths(CG+P))| = 0
1! |Apce "Match(!̂,Paths(CG+P))|
|Match(!̂,Paths(CG+P))| o.w.
(1)
err"(!̂,Apce) =
8<:
1 if |Apce | = 0
1! |Apce "Match(!̂,Paths(CG+P))|
|Apce |o.w.
(2)
abs(!̂) =
8<:
1 if |!̂| = 0
1! |!̂|! |W(!̂)||!̂| o.w.
(3)
conf (!̂,Apce) = 1! err!(!̂,Apce)(1! abs(!̂)) + err"(!̂,Apce)abs(!̂) (4)
Fig. 6. Pattern attribute equations.
Definition 5 A pattern !̂ matches a path ! iff
– for each vertex u along ! at position i there exists a vertex v in !̂ at the sameposition i in which either u = v or v is a wild-card,
– for each arc (p, q) along ! at position j there exists an arc (s, t) in !̂ at the sameposition j in which either "(p, q) = "(s, t) or (s, t) is a wild-card.
Given that a pattern matches a particular path, suggested shadows are ones repre-sented by graph elements (vertices and/or arcs) along the path which matched enabledwild-cards in the pattern. Vertices representing method declarations matched by enabledwild-cards produce a suggested shadow associated with the execution of that method.Likewise, arcs representing relationships, e.g., calls, field reads, field writes, betweenprogram elements matched by enabled wild-cards produce a suggested shadow associ-ated with that relationship, e.g., call, get, set, between the program elements, e.g.,withincode for method declarations, represented by the source and target vertices. In
terms the graph subset portrayed in Figure 4, the pattern ?! cm!!" ?sf!" overallSpeed
would match increase(Fuel) ! overallSpeed and increase(Current) !overallSpeed. Also note that the same pattern would also match the path increase
(double) ! overallSpeed had we augmented the graph in Figure 4 with the re-vised version of the base code portrayed in Figure 1(d) from our motivating example.Furthermore, notice that increase(double) would be represented by a vertex thatwould match an enabled wild-card element in the pattern, thus, this method would besuggested to be included in a rejuvenated version of the PCE.
Suggestion sorting. Line 7, Figure 3 commences the final rejuvenation process byinitializing the new PCE Apce! to be returned by the function as the empty set of shad-ows. Then, for each shadow, confidence (explained next) pair sorted by decreasing con-fidence (line 8), the suggestion is presented to developer along with its confidence (line9). The (developer) selected shadows (line 10) are then augmented to the rejuvenatedPCE Apce! (line 11) and returned (line 14).
A confidence c paired with each suggested shadow # is a real number in the inter-val [0, 1] that represents the degree to which we believe a revised version of the original
Suggestion Ranking Scheme
Measurements for Suggestion Ranking
α error: How strong are the relationships between advisedshadows compared to ones captured by a pattern?
β error: How well does the pattern express the sameintentions as the pointcut?
All Join Point Shadows! a join point shadow; code corresponding to a join pointA a piece of adviceApce a pointcut bound to advice A; a set of join point shadowsApce! a subsequent revision of Apce
P the original program, the underlying base-codeP ! a subsequence revision of program P!P the set of join point shadows contained within program PIGP a finite graph representing structural relationships be-
tween program elements in P" an acyclic path (sequence of arcs) in IGP ; an intention"P a set of acyclic paths derived from program P"̂ an intention pattern (sequence of vertices and arcs) de-
rived from ", possibly containing wildcards"̂P a set of intention patterns derived from program P
Figure 4. Algorithm formalism notation.
produced successfully inferring new join points that shouldbe incorporated in a revised version of the PCE.
For the sake of presentation, we further make severalsimplifying assumptions about the underlying source codeto be analyzed; we discuss in Section 4.1 how much ofthese are relaxed in our implementation. We assume thatthe source code utilizes only a subset of weaving semanticsavailable to the underlying AO language, such as AspectJ[31]. Specifically, we exclude the ability of an aspect to stat-ically crosscut a base program, i.e., introduce and modifyfacets of the base-code at compile time (e.g., member intro-duction, class hierarchy alteration). Furthermore, althoughit is possible for a PCE to capture join points associatedwithin an advice body (possibly the one it is bound to), weadopt the perspective that aspects are indeed separate fromthe base-code; advice may only apply to join points associ-ated with classes, interfaces, and other Java types. We alsoassume that we are able to statically identify all referencesto program entities contained within the base-code. This as-sumption could be invalidated through the use of reflectionand custom class loaders. Moreover, we assume that theoriginal source code successfully compiles under a AJDT1.62 compiler.
Recall that a join point refers to a well-defined point inthe execution of the base-code; thus, the definition of a joinpoint is dynamic in nature. A join point shadow, on theother hand, refers to base-code corresponding to a join point[50], i.e., a point in the program text where the compilermay actually perform the weaving [39]. Whether or not thecompiler actually performs weaving at that point is depen-dent on (i) advice being applicable at that point, and (ii)possible dynamic conditions being met. As such, we con-sider a given program P as consisting of a set of join pointshadows !P (see Figure 4) that may or may not be currentlyunder the influence of advice3. Moreover, a given piece of
2http://www.eclipse.org/ajdt3This definition differs slightly from those given in the literature.
function Rejuvenate(Apce ,P,P !, d)
1: IGP ! BuildGraph(P) /*Construct the intention graph forthe original program*/
2: "̂P ! CreatePatterns(Apce , IGP , d) /*Derive intentionpatterns relevant to the PCE from the graph of the originalprogram*/
3: IGP! ! BuildGraph(P !) /*Construct the intention graphfor the revised program*/
4: "̂P! ! CreatePatterns(Upce , IGP! , d) /*Derive all possi-ble intention patterns from the graph of the revised program*/
5: "̂P"P! ! "̂P " "̂P! /*Intersect the patterns derived fromthe old version with the ones from the new version.*/
6: S ! MakeSuggestions("̂P"P! , IGP!) /*Create a set ofsuggestion, confidence pairs*/
7: Apce! ! ! /*The rejuvenated PCE to be returned*/8: for all (!, c) # Sort(S) do /*For all suggestion, confidence
pairs by descending confidence*/9: Suggest(!, c)
10: if Selected(!) then11: Apce! ! Apce! $ {!}12: end if13: end for14: return Apce!
Figure 5. Top-level rejuvenation algorithm.
advice A specifies its applicability to a base program P viaits bound pointcut expression Apce , which selects a sub-set of shadows contained within P , i.e., A applies to P at!P !Apce . Therefore, each ! " !P !Apce specifies whereA should apply to P but does not specify when. That is,we assume that no dynamic conditions are associated withApce ; thus, we utilize solely static information in our anal-ysis. Section 4.1 discusses how our implementation conser-vatively relaxes this assumption so that PCEs utilizing dy-namic conditions may nevertheless be used as input to ourtool; in Section 6 we briefly touch on how the approach pre-sented here may be extended to leverage dynamic analysistechniques in light of such PCEs.
Lastly, we assume that we can accurately resolve thedeclaration of a particular piece of advice across varyingversions of the software. This assumption is important toour analysis since, in AO languages like AspectJ, advice isconsidered to be anonymous, which may make it difficultto track in consequent versions. Section 4.1 also discusseshow our tool enforces the validity of this assumpiton in or-der to make rejuvenation possible.
3.2. Pointcut Rejuvenation
Figure 5 depicts the Rejuvenate function, the top-levelpointcut rejuventation algorithm that drives the approach.Input to the function is a pointcut Apce from the originalprogram P to be recovered as a result of the new version ofthe program P !. Conceptually, applying this function to the
4
12
err!(!̂,Apce) =
8><>:
0 if |Match(!̂,Paths(CG+P))| = 0
1! |Apce "Match(!̂,Paths(CG+P))|
|Match(!̂,Paths(CG+P))| o.w.
(1)
err"(!̂,Apce) =
8<:
1 if |Apce | = 0
1! |Apce "Match(!̂,Paths(CG+P))|
|Apce |o.w.
(2)
abs(!̂) =
8<:
1 if |!̂| = 0
1! |!̂|! |W(!̂)||!̂| o.w.
(3)
conf (!̂,Apce) = 1! err!(!̂,Apce)(1! abs(!̂)) + err"(!̂,Apce)abs(!̂) (4)
Fig. 6. Pattern attribute equations.
Definition 5 A pattern !̂ matches a path ! iff
– for each vertex u along ! at position i there exists a vertex v in !̂ at the sameposition i in which either u = v or v is a wild-card,
– for each arc (p, q) along ! at position j there exists an arc (s, t) in !̂ at the sameposition j in which either "(p, q) = "(s, t) or (s, t) is a wild-card.
Given that a pattern matches a particular path, suggested shadows are ones repre-sented by graph elements (vertices and/or arcs) along the path which matched enabledwild-cards in the pattern. Vertices representing method declarations matched by enabledwild-cards produce a suggested shadow associated with the execution of that method.Likewise, arcs representing relationships, e.g., calls, field reads, field writes, betweenprogram elements matched by enabled wild-cards produce a suggested shadow associ-ated with that relationship, e.g., call, get, set, between the program elements, e.g.,withincode for method declarations, represented by the source and target vertices. In
terms the graph subset portrayed in Figure 4, the pattern ?! cm!!" ?sf!" overallSpeed
would match increase(Fuel) ! overallSpeed and increase(Current) !overallSpeed. Also note that the same pattern would also match the path increase
(double) ! overallSpeed had we augmented the graph in Figure 4 with the re-vised version of the base code portrayed in Figure 1(d) from our motivating example.Furthermore, notice that increase(double) would be represented by a vertex thatwould match an enabled wild-card element in the pattern, thus, this method would besuggested to be included in a rejuvenated version of the PCE.
Suggestion sorting. Line 7, Figure 3 commences the final rejuvenation process byinitializing the new PCE Apce! to be returned by the function as the empty set of shad-ows. Then, for each shadow, confidence (explained next) pair sorted by decreasing con-fidence (line 8), the suggestion is presented to developer along with its confidence (line9). The (developer) selected shadows (line 10) are then augmented to the rejuvenatedPCE Apce! (line 11) and returned (line 14).
A confidence c paired with each suggested shadow # is a real number in the inter-val [0, 1] that represents the degree to which we believe a revised version of the original
α
Suggestion Ranking Scheme
Measurements for Suggestion Ranking
α error: How strong are the relationships between advisedshadows compared to ones captured by a pattern?
β error: How well does the pattern express the sameintentions as the pointcut?
All Join Point Shadows! a join point shadow; code corresponding to a join pointA a piece of adviceApce a pointcut bound to advice A; a set of join point shadowsApce! a subsequent revision of Apce
P the original program, the underlying base-codeP ! a subsequence revision of program P!P the set of join point shadows contained within program PIGP a finite graph representing structural relationships be-
tween program elements in P" an acyclic path (sequence of arcs) in IGP ; an intention"P a set of acyclic paths derived from program P"̂ an intention pattern (sequence of vertices and arcs) de-
rived from ", possibly containing wildcards"̂P a set of intention patterns derived from program P
Figure 4. Algorithm formalism notation.
produced successfully inferring new join points that shouldbe incorporated in a revised version of the PCE.
For the sake of presentation, we further make severalsimplifying assumptions about the underlying source codeto be analyzed; we discuss in Section 4.1 how much ofthese are relaxed in our implementation. We assume thatthe source code utilizes only a subset of weaving semanticsavailable to the underlying AO language, such as AspectJ[31]. Specifically, we exclude the ability of an aspect to stat-ically crosscut a base program, i.e., introduce and modifyfacets of the base-code at compile time (e.g., member intro-duction, class hierarchy alteration). Furthermore, althoughit is possible for a PCE to capture join points associatedwithin an advice body (possibly the one it is bound to), weadopt the perspective that aspects are indeed separate fromthe base-code; advice may only apply to join points associ-ated with classes, interfaces, and other Java types. We alsoassume that we are able to statically identify all referencesto program entities contained within the base-code. This as-sumption could be invalidated through the use of reflectionand custom class loaders. Moreover, we assume that theoriginal source code successfully compiles under a AJDT1.62 compiler.
Recall that a join point refers to a well-defined point inthe execution of the base-code; thus, the definition of a joinpoint is dynamic in nature. A join point shadow, on theother hand, refers to base-code corresponding to a join point[50], i.e., a point in the program text where the compilermay actually perform the weaving [39]. Whether or not thecompiler actually performs weaving at that point is depen-dent on (i) advice being applicable at that point, and (ii)possible dynamic conditions being met. As such, we con-sider a given program P as consisting of a set of join pointshadows !P (see Figure 4) that may or may not be currentlyunder the influence of advice3. Moreover, a given piece of
2http://www.eclipse.org/ajdt3This definition differs slightly from those given in the literature.
function Rejuvenate(Apce ,P,P !, d)
1: IGP ! BuildGraph(P) /*Construct the intention graph forthe original program*/
2: "̂P ! CreatePatterns(Apce , IGP , d) /*Derive intentionpatterns relevant to the PCE from the graph of the originalprogram*/
3: IGP! ! BuildGraph(P !) /*Construct the intention graphfor the revised program*/
4: "̂P! ! CreatePatterns(Upce , IGP! , d) /*Derive all possi-ble intention patterns from the graph of the revised program*/
5: "̂P"P! ! "̂P " "̂P! /*Intersect the patterns derived fromthe old version with the ones from the new version.*/
6: S ! MakeSuggestions("̂P"P! , IGP!) /*Create a set ofsuggestion, confidence pairs*/
7: Apce! ! ! /*The rejuvenated PCE to be returned*/8: for all (!, c) # Sort(S) do /*For all suggestion, confidence
pairs by descending confidence*/9: Suggest(!, c)
10: if Selected(!) then11: Apce! ! Apce! $ {!}12: end if13: end for14: return Apce!
Figure 5. Top-level rejuvenation algorithm.
advice A specifies its applicability to a base program P viaits bound pointcut expression Apce , which selects a sub-set of shadows contained within P , i.e., A applies to P at!P !Apce . Therefore, each ! " !P !Apce specifies whereA should apply to P but does not specify when. That is,we assume that no dynamic conditions are associated withApce ; thus, we utilize solely static information in our anal-ysis. Section 4.1 discusses how our implementation conser-vatively relaxes this assumption so that PCEs utilizing dy-namic conditions may nevertheless be used as input to ourtool; in Section 6 we briefly touch on how the approach pre-sented here may be extended to leverage dynamic analysistechniques in light of such PCEs.
Lastly, we assume that we can accurately resolve thedeclaration of a particular piece of advice across varyingversions of the software. This assumption is important toour analysis since, in AO languages like AspectJ, advice isconsidered to be anonymous, which may make it difficultto track in consequent versions. Section 4.1 also discusseshow our tool enforces the validity of this assumpiton in or-der to make rejuvenation possible.
3.2. Pointcut Rejuvenation
Figure 5 depicts the Rejuvenate function, the top-levelpointcut rejuventation algorithm that drives the approach.Input to the function is a pointcut Apce from the originalprogram P to be recovered as a result of the new version ofthe program P !. Conceptually, applying this function to the
4
12
err!(!̂,Apce) =
8><>:
0 if |Match(!̂,Paths(CG+P))| = 0
1! |Apce "Match(!̂,Paths(CG+P))|
|Match(!̂,Paths(CG+P))| o.w.
(1)
err"(!̂,Apce) =
8<:
1 if |Apce | = 0
1! |Apce "Match(!̂,Paths(CG+P))|
|Apce |o.w.
(2)
abs(!̂) =
8<:
1 if |!̂| = 0
1! |!̂|! |W(!̂)||!̂| o.w.
(3)
conf (!̂,Apce) = 1! err!(!̂,Apce)(1! abs(!̂)) + err"(!̂,Apce)abs(!̂) (4)
Fig. 6. Pattern attribute equations.
Definition 5 A pattern !̂ matches a path ! iff
– for each vertex u along ! at position i there exists a vertex v in !̂ at the sameposition i in which either u = v or v is a wild-card,
– for each arc (p, q) along ! at position j there exists an arc (s, t) in !̂ at the sameposition j in which either "(p, q) = "(s, t) or (s, t) is a wild-card.
Given that a pattern matches a particular path, suggested shadows are ones repre-sented by graph elements (vertices and/or arcs) along the path which matched enabledwild-cards in the pattern. Vertices representing method declarations matched by enabledwild-cards produce a suggested shadow associated with the execution of that method.Likewise, arcs representing relationships, e.g., calls, field reads, field writes, betweenprogram elements matched by enabled wild-cards produce a suggested shadow associ-ated with that relationship, e.g., call, get, set, between the program elements, e.g.,withincode for method declarations, represented by the source and target vertices. In
terms the graph subset portrayed in Figure 4, the pattern ?! cm!!" ?sf!" overallSpeed
would match increase(Fuel) ! overallSpeed and increase(Current) !overallSpeed. Also note that the same pattern would also match the path increase
(double) ! overallSpeed had we augmented the graph in Figure 4 with the re-vised version of the base code portrayed in Figure 1(d) from our motivating example.Furthermore, notice that increase(double) would be represented by a vertex thatwould match an enabled wild-card element in the pattern, thus, this method would besuggested to be included in a rejuvenated version of the PCE.
Suggestion sorting. Line 7, Figure 3 commences the final rejuvenation process byinitializing the new PCE Apce! to be returned by the function as the empty set of shad-ows. Then, for each shadow, confidence (explained next) pair sorted by decreasing con-fidence (line 8), the suggestion is presented to developer along with its confidence (line9). The (developer) selected shadows (line 10) are then augmented to the rejuvenatedPCE Apce! (line 11) and returned (line 14).
A confidence c paired with each suggested shadow # is a real number in the inter-val [0, 1] that represents the degree to which we believe a revised version of the original
α
Suggestion Ranking Scheme
Measurements for Suggestion Ranking
α error: How strong are the relationships between advisedshadows compared to ones captured by a pattern?
β error: How well does the pattern express the sameintentions as the pointcut?
All Join Point Shadows! a join point shadow; code corresponding to a join pointA a piece of adviceApce a pointcut bound to advice A; a set of join point shadowsApce! a subsequent revision of Apce
P the original program, the underlying base-codeP ! a subsequence revision of program P!P the set of join point shadows contained within program PIGP a finite graph representing structural relationships be-
tween program elements in P" an acyclic path (sequence of arcs) in IGP ; an intention"P a set of acyclic paths derived from program P"̂ an intention pattern (sequence of vertices and arcs) de-
rived from ", possibly containing wildcards"̂P a set of intention patterns derived from program P
Figure 4. Algorithm formalism notation.
produced successfully inferring new join points that shouldbe incorporated in a revised version of the PCE.
For the sake of presentation, we further make severalsimplifying assumptions about the underlying source codeto be analyzed; we discuss in Section 4.1 how much ofthese are relaxed in our implementation. We assume thatthe source code utilizes only a subset of weaving semanticsavailable to the underlying AO language, such as AspectJ[31]. Specifically, we exclude the ability of an aspect to stat-ically crosscut a base program, i.e., introduce and modifyfacets of the base-code at compile time (e.g., member intro-duction, class hierarchy alteration). Furthermore, althoughit is possible for a PCE to capture join points associatedwithin an advice body (possibly the one it is bound to), weadopt the perspective that aspects are indeed separate fromthe base-code; advice may only apply to join points associ-ated with classes, interfaces, and other Java types. We alsoassume that we are able to statically identify all referencesto program entities contained within the base-code. This as-sumption could be invalidated through the use of reflectionand custom class loaders. Moreover, we assume that theoriginal source code successfully compiles under a AJDT1.62 compiler.
Recall that a join point refers to a well-defined point inthe execution of the base-code; thus, the definition of a joinpoint is dynamic in nature. A join point shadow, on theother hand, refers to base-code corresponding to a join point[50], i.e., a point in the program text where the compilermay actually perform the weaving [39]. Whether or not thecompiler actually performs weaving at that point is depen-dent on (i) advice being applicable at that point, and (ii)possible dynamic conditions being met. As such, we con-sider a given program P as consisting of a set of join pointshadows !P (see Figure 4) that may or may not be currentlyunder the influence of advice3. Moreover, a given piece of
2http://www.eclipse.org/ajdt3This definition differs slightly from those given in the literature.
function Rejuvenate(Apce ,P,P !, d)
1: IGP ! BuildGraph(P) /*Construct the intention graph forthe original program*/
2: "̂P ! CreatePatterns(Apce , IGP , d) /*Derive intentionpatterns relevant to the PCE from the graph of the originalprogram*/
3: IGP! ! BuildGraph(P !) /*Construct the intention graphfor the revised program*/
4: "̂P! ! CreatePatterns(Upce , IGP! , d) /*Derive all possi-ble intention patterns from the graph of the revised program*/
5: "̂P"P! ! "̂P " "̂P! /*Intersect the patterns derived fromthe old version with the ones from the new version.*/
6: S ! MakeSuggestions("̂P"P! , IGP!) /*Create a set ofsuggestion, confidence pairs*/
7: Apce! ! ! /*The rejuvenated PCE to be returned*/8: for all (!, c) # Sort(S) do /*For all suggestion, confidence
pairs by descending confidence*/9: Suggest(!, c)
10: if Selected(!) then11: Apce! ! Apce! $ {!}12: end if13: end for14: return Apce!
Figure 5. Top-level rejuvenation algorithm.
advice A specifies its applicability to a base program P viaits bound pointcut expression Apce , which selects a sub-set of shadows contained within P , i.e., A applies to P at!P !Apce . Therefore, each ! " !P !Apce specifies whereA should apply to P but does not specify when. That is,we assume that no dynamic conditions are associated withApce ; thus, we utilize solely static information in our anal-ysis. Section 4.1 discusses how our implementation conser-vatively relaxes this assumption so that PCEs utilizing dy-namic conditions may nevertheless be used as input to ourtool; in Section 6 we briefly touch on how the approach pre-sented here may be extended to leverage dynamic analysistechniques in light of such PCEs.
Lastly, we assume that we can accurately resolve thedeclaration of a particular piece of advice across varyingversions of the software. This assumption is important toour analysis since, in AO languages like AspectJ, advice isconsidered to be anonymous, which may make it difficultto track in consequent versions. Section 4.1 also discusseshow our tool enforces the validity of this assumpiton in or-der to make rejuvenation possible.
3.2. Pointcut Rejuvenation
Figure 5 depicts the Rejuvenate function, the top-levelpointcut rejuventation algorithm that drives the approach.Input to the function is a pointcut Apce from the originalprogram P to be recovered as a result of the new version ofthe program P !. Conceptually, applying this function to the
4
12
err!(!̂,Apce) =
8><>:
0 if |Match(!̂,Paths(CG+P))| = 0
1! |Apce "Match(!̂,Paths(CG+P))|
|Match(!̂,Paths(CG+P))| o.w.
(1)
err"(!̂,Apce) =
8<:
1 if |Apce | = 0
1! |Apce "Match(!̂,Paths(CG+P))|
|Apce |o.w.
(2)
abs(!̂) =
8<:
1 if |!̂| = 0
1! |!̂|! |W(!̂)||!̂| o.w.
(3)
conf (!̂,Apce) = 1! err!(!̂,Apce)(1! abs(!̂)) + err"(!̂,Apce)abs(!̂) (4)
Fig. 6. Pattern attribute equations.
Definition 5 A pattern !̂ matches a path ! iff
– for each vertex u along ! at position i there exists a vertex v in !̂ at the sameposition i in which either u = v or v is a wild-card,
– for each arc (p, q) along ! at position j there exists an arc (s, t) in !̂ at the sameposition j in which either "(p, q) = "(s, t) or (s, t) is a wild-card.
Given that a pattern matches a particular path, suggested shadows are ones repre-sented by graph elements (vertices and/or arcs) along the path which matched enabledwild-cards in the pattern. Vertices representing method declarations matched by enabledwild-cards produce a suggested shadow associated with the execution of that method.Likewise, arcs representing relationships, e.g., calls, field reads, field writes, betweenprogram elements matched by enabled wild-cards produce a suggested shadow associ-ated with that relationship, e.g., call, get, set, between the program elements, e.g.,withincode for method declarations, represented by the source and target vertices. In
terms the graph subset portrayed in Figure 4, the pattern ?! cm!!" ?sf!" overallSpeed
would match increase(Fuel) ! overallSpeed and increase(Current) !overallSpeed. Also note that the same pattern would also match the path increase
(double) ! overallSpeed had we augmented the graph in Figure 4 with the re-vised version of the base code portrayed in Figure 1(d) from our motivating example.Furthermore, notice that increase(double) would be represented by a vertex thatwould match an enabled wild-card element in the pattern, thus, this method would besuggested to be included in a rejuvenated version of the PCE.
Suggestion sorting. Line 7, Figure 3 commences the final rejuvenation process byinitializing the new PCE Apce! to be returned by the function as the empty set of shad-ows. Then, for each shadow, confidence (explained next) pair sorted by decreasing con-fidence (line 8), the suggestion is presented to developer along with its confidence (line9). The (developer) selected shadows (line 10) are then augmented to the rejuvenatedPCE Apce! (line 11) and returned (line 14).
A confidence c paired with each suggested shadow # is a real number in the inter-val [0, 1] that represents the degree to which we believe a revised version of the original
α
β
MotivationApproach
EvaluationMore Information
Suggestion Confidence
Each suggestion is associated with a confidence value ([0,1]).
A suggestion inherits the confidence of the pattern thatproduced it.
A pattern’s confidence is calculated using a combination of α,β, and the depth of the patterns.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Suggestion Confidence
Each suggestion is associated with a confidence value ([0,1]).
A suggestion inherits the confidence of the pattern thatproduced it.
A pattern’s confidence is calculated using a combination of α,β, and the depth of the patterns.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Suggestion Confidence
Each suggestion is associated with a confidence value ([0,1]).
A suggestion inherits the confidence of the pattern thatproduced it.
A pattern’s confidence is calculated using a combination of α,β, and the depth of the patterns.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
Implementation
MotivationApproach
EvaluationMore Information
But How Well Does It Work?
Correlation analysis (Phase I) on 20+ AspectJ benchmarks.
Average confidence was 0.66.
Applied to 4 multi-versioned AspectJ projects (Phase II).
Rejuvenated pointcuts in major releases (26 in total).Able to identify 94% of new shadows introduced in laterversionsOn average, appearing in the top 4% of results.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
But How Well Does It Work?
Correlation analysis (Phase I) on 20+ AspectJ benchmarks.
Average confidence was 0.66.
Applied to 4 multi-versioned AspectJ projects (Phase II).
Rejuvenated pointcuts in major releases (26 in total).Able to identify 94% of new shadows introduced in laterversionsOn average, appearing in the top 4% of results.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
But How Well Does It Work?
Correlation analysis (Phase I) on 20+ AspectJ benchmarks.
Average confidence was 0.66.
Applied to 4 multi-versioned AspectJ projects (Phase II).
Rejuvenated pointcuts in major releases (26 in total).Able to identify 94% of new shadows introduced in laterversionsOn average, appearing in the top 4% of results.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
But How Well Does It Work?
Correlation analysis (Phase I) on 20+ AspectJ benchmarks.
Average confidence was 0.66.
Applied to 4 multi-versioned AspectJ projects (Phase II).
Rejuvenated pointcuts in major releases (26 in total).Able to identify 94% of new shadows introduced in laterversionsOn average, appearing in the top 4% of results.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
But How Well Does It Work?
Correlation analysis (Phase I) on 20+ AspectJ benchmarks.
Average confidence was 0.66.
Applied to 4 multi-versioned AspectJ projects (Phase II).
Rejuvenated pointcuts in major releases (26 in total).Able to identify 94% of new shadows introduced in laterversionsOn average, appearing in the top 4% of results.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
But How Well Does It Work?
Correlation analysis (Phase I) on 20+ AspectJ benchmarks.
Average confidence was 0.66.
Applied to 4 multi-versioned AspectJ projects (Phase II).
Rejuvenated pointcuts in major releases (26 in total).Able to identify 94% of new shadows introduced in laterversionsOn average, appearing in the top 4% of results.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Tool and Material Downloads
Tool research prototype publicly available athttp://code.google.com/p/rejuvenate-pc.
Research related material publicly available athttp://sites.google.com/site/pointcutrejuvenation.
Full evaluation available in corresponding technical report.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Tool and Material Downloads
Tool research prototype publicly available athttp://code.google.com/p/rejuvenate-pc.
Research related material publicly available athttp://sites.google.com/site/pointcutrejuvenation.
Full evaluation available in corresponding technical report.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
MotivationApproach
EvaluationMore Information
Tool and Material Downloads
Tool research prototype publicly available athttp://code.google.com/p/rejuvenate-pc.
Research related material publicly available athttp://sites.google.com/site/pointcutrejuvenation.
Full evaluation available in corresponding technical report.
Khatchadourian, Greenwood, Rashid, Xu Rejuvenate Pointcut
