1 contract-based verification for aspect-oriented refactoring naoyasu ubayashi(kyushu institute of...
TRANSCRIPT
1
Contract-based Verification for Aspect-oriented Refactoring
Naoyasu Ubayashi (Kyushu Institute of Technology)Jinji Piao (Kyushu Institute of Technology)Suguru Shinotsuka (Kyushu Institute of Technology)Tetsuo Tamai (University of Tokyo)
April 11, 2008
ICST 2008
Refactoring in AOP
Refactoring is a method for improving a program‘s structure without changing its external behavior.
Refactoring is a promising approach to assisting reliable software evolution.
However, in AOP, refactoring is not easy !
2
Unexpected Weaving
Fragile Pointcuts
Today’s my talk We propose the notion of RbC (Refactoring
by Contract), an AO refactoring verification method based on first-order logic.
RbC originates in DbC. [Meyer]
3
before refactoringprecondition
postcondition
invariant
after refactoring
Programmer Contract
Check
Check AO Program
Program StructureProgram Behavior
Refactoring
4
Outline
1. Motivation2. Refactoring by Contract3. Contract template4. Implementation5. Related work6. Conclusions
5
1. Motivation
6
Aspect-oriented programming
AOP is a programming paradigm in which crosscutting concernsare modularized as aspects.
after (Shape s):(execution(void set*(..) || execution(void Shape+.moveBy(int,int))) && target(s) { s.redraw(); }
advice
pointcut
AspectJ
UpdateSignaling
Refactoring catalogues for AOP
7
Refactoring catalogues[Cole 2005] [Monteiro 2005]
No. Refactoring pattern
1-1 Change Abstract Class to Interface 1-2 Extract Feature into Aspect1-3 Extract Fragment into Advice1-4 Extract Inner Class to Standalone 1-5 Inline Class within Aspect1-6 Inline Interface within Aspect1-7 Move Field from Class to Inter-type1-8 Move Method from Class to Inter-type1-9 Replace Implements with Declare Parents1-10 Split Abstract Class into Aspect and Interface
2-1 Extend Marker Interface with Signature2-2 Generalize Target Type with Marker Interface2-3 Introduce Aspect Protection2-4 Replace Inter-type Field with Aspect Map2-5 Replace Inter-type Method with AspectMethod2-6 Tidy Up Internal Aspect Structure
3-1 Extract Superaspect3-2 Pull Up Advice3-3 Pull Up Declare Parents3-4 Pull Up Inter-type Declaration3-5 Pull Up Marker Interface3-7 Push Down Advice3-8 Push Down Declare Parents3-9 Push Down Inter-type Declaration3-10 Push Down Marker Interface3-11 Push Down Pointcut
1. For extraction of crosscutting concerns
2. For restructuring the internals of aspects
3. For dealing with generalization
27 refactoring patternsproposed by Monterio
Aspect
SuperAspect
1
3
2
But, AO refactoring is not easy …
Correct refactoring should satisfy the following constraints1. Behavior must be preserved before/after
refactoring2. Refactoring should improve the internal
structure as defined by refactoring catalogues
8
Correct ?
How to verify?
public class Line implements Shape {
public void setP1(Point p1) { this.p1 = p1; } public void setP2(Point p2) { this.p2 = p2; } public void moveBy(intdx, intdy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; } public void redraw() { Display.update(); }}
Example: 1st refactoring
9
public class Point implements Shape {
public void setX(int x) { this.x = x; } public void setY(int y) { this.y = y; } public void moveBy(intdx, intdy) { x += dx; y += dy; } public void redraw() { Display.update(); }}
aspect UpdateSignaling {
pointcut change(Shape s): (execution(void set*(..) || execution(void Shape+.moveBy(int,int))) && target(s);
after(Shape s) returning: change(s){ s.redraw(); }}
Move Method from Class to Inter-type
aspect UpdateSignaling {
public void redraw() { Display.update(); }
pointcut change(Shape s): (execution(void set*(..) || execution(void Shape+.moveBy(int,int))) && target(s);
after(Shape s) returning: change(s){ s.redraw(); }}
aspect UpdateSignaling {
public void Shape.redraw() { Display.update(); }
pointcut change(Shape s): (execution(void set*(..) || execution(void Shape+.moveBy(int,int))) && target(s);
after(Shape s) returning: change(s){ s.redraw(); }}
Forget to remove redraw()
1.Behavior preservation [OK]
2.Structure improvement [NG]
Behave correctly
Example: 2nd refactoring
10
public class Line implements Shape {
public void setP1(Point p1) { this.p1 = p1; } public void setP2(Point p2) { this.p2 = p2; } public void moveBy(intdx, intdy) { p1.x += dx; p1.y += dy; p2.x += dx; p2.y += dy; } public void redraw() { Display.update(); }}
p1.moveBy(dx, dy);p2.moveBy(dx, dy);
aspect UpdateSignaling {
public void redraw() { Display.update(); } pointcut change(Shape s): (execution(void set*(..) || execution(void Shape+.moveBy(int,int))) && target(s);
after(Shape s) returning: change(s){ s.redraw(); }}
Redraw() is called three times!
1.Behavior preservation [NG]
2.Structure improvement [OK]
Problems in AO refactoring
11
In AOP, it is not necessarily easy for a programmer to understand the overall behavior of a woven program because the weaving modifies the behavior.
Unexpected bugs can be embedded in a program if the programmer does not modify the program carefully.
Our approach
12
We apply logic programming to verify the accuracy of aspect-oriented refactoring.
In AOP, primitive predicates for specifying constraints must check the impact of weaving.
Challenge
2. Refactoring by Contract
13
RbC: Refactoring by Contract
before refactoringprecondition
postcondition
invariant
after refactoring
Programmer Contract
Check
Check AO Program
Precondition states under which conditions
refactoring can be applied.
Invariant states whatconditions refactoring should preserve.
Postcondition states what conditions should be verified after refactoring has been accomplished.
Program StructureProgram Behavior 14
COW: COntractWriting language
15
class, method, extends, owner,aspect, pointcut, intertypeOwner, beforeAdvice, afterAdvice, aroundAdvice, etc.
COW is a language for describing predicates based on first-order logic.
program structure
program behavior
call, write, read, controlFlow, dataFlow, etc.
contract MoveMethodFromClassToIntertype {
requires( class(Point) && method(redraw) && owner(redraw, Point) );
ensures( // condition 1 aspect(UpdateSignaling) && method(redraw) && owner(redraw, UpdateSignaling) &&
// condition 2 intertypeOwner(redraw, Point) &&
// condition 3 class(Point) && !owner(redraw, Point) );}
Contract for 1st Refactoring
16
Precondition
Postcondition
contract LineBehavior restricts Line {
void moveBy(int, int){ invariant (Redrawing.once()); }}
Contract for 2nd Refactoring
17
contract Redrawing { define statement(s) { target(t) && entry(t, e) &&controlFlow(t, s, e) }
define updating() { statement(s) && call(s, Display.update) }
define multiple() { statement(s1) && call(s1, Display.update) && statement(s2) && call(s2, Display.update) && !equal(s1, s2) }
define once() { updating() && !multiple() }}
3. Contract template
18
Contract template
19
ctemplateT_MoveMethodFromClassToIntertype
<class C, method M, aspect A>{ requires( owner( <M>, <C>) );
ensures( // condition 1 owner( <M>, <A>) &&
// condition 2 intertypeOwner( <M>, <C>) &&
// condition 3 !owner( <M>, <C>) );}
CtemplateT_ReplaceIntertypeMethodWithAspectMethod
<class C, method M, aspect A>{
requires( // condition 1 owner( <M>, <A>) &&
// condition 2 intertypeOwner( <M>, <C>) );
ensures( // condition 1 owner( <M>, <A>) &&
// condition 2 !intertypeOwner( <M>, <C>) );}
ctemplateT_MoveMethodFromClassToIntertype
<class C, method M, aspect A>{ requires( owner( <M>, <C>) );
ensures( // condition 1 owner( <M>, <A>) &&
// condition 2 intertypeOwner( <M>, <C>) &&
// condition 3 !owner( <M>, <C>) );}
Template composition
20
Parametermatching
If postconditions of contract X are stronger than preconditions of contraxt Y, these templates can be composed.
Contract X Contract Y
Evaluation: template coverage
21
No. Refactoring pattern
1-1 Change Abstract Class to Interface 1-2 Extract Feature into Aspect1-3 Extract Fragment into Advice1-4 Extract Inner Class to Standalone 1-5 Inline Class within Aspect1-6 Inline Interface within Aspect1-7 Move Field from Class to Inter-type1-8 Move Method from Class to Inter-type1-9 Replace Implements with Declare Parents1-10 Split Abstract Class into Aspect and Interface
2-1 Extend Marker Interface with Signature2-2 Generalize Target Type with Marker Interface2-3 Introduce Aspect Protection2-4 Replace Inter-type Field with Aspect Map2-5 Replace Inter-type Method with AspectMethod2-6 Tidy Up Internal Aspect Structure
3-1 Extract Superaspect3-2 Pull Up Advice3-3 Pull Up Declare Parents3-4 Pull Up Inter-type Declaration3-5 Pull Up Marker Interface3-7 Push Down Advice3-8 Push Down Declare Parents3-9 Push Down Inter-type Declaration3-10 Push Down Marker Interface3-11 Push Down Pointcut
Patterns: 27Templates: 18
Coverage = 67 %
4. Implementation
22
COW Contract Verifier
23
Parser & Program Analyzer
AspectJ Code
Prolog facts(CFG)
Prolog Query
COW to Prolog
Translator
Contracts
ContractChecker
CFG: Control Flow Graph
s1: -in: Point.moveBy() call(’s1’, ’Point.moveBy(int,int)’)
s2: Point.moveBy(intdx, intdy) entry(’Point.moveBy(int,int)’,’s2’)
s3: Point.x += dx
s4: Point.y += dy
s5: -out: Point.moveBy()
next(’s1’,’s2’,[’Line.moveBy(int,int)’])
next(’s2’,’s3’,[’Line.moveBy(int,int)’,’Point.moveBy(int,int)’])
next(’s3’,’s4’,[’Line.moveBy(int,int)’,’Point.moveBy(int,int)’])
next(’s4’,’s5’,[’Line.moveBy(int,int)’])
controlFlow(Scope, Goal, Start) :- traverse(Scope, Goal, Start, []).
traverse(Scope, Goal, Start, Visited) :- next(Start, Next, ScopeList), member(Scope, ScopeList), \+member(Next, Visited), Next = Goal. …
24
5. Related Work
25
Related work
Logic-based verification AspectJ programming laws for deriving behavior-
preserving transformations [Cole 2005] Domain-specific language for Refactoring
[Verbaere 2006]
26
In RbC, domain-specific contract templates can be defined using COW predicates.
Related work (Cont’d) Software Evolution and Interfaces
Aspect-aware interface [Kiczales 2005] Crosscut programming interface (XPI) [Griswold
2006] Open Modules [Aldrich 2005] Harmless advice [Dantas 2006] Aspect integration contracts [Lagaisse2004]
27
AO refactoring can be considered a special case of software evolution in which AO interfaces play an important role.
Contracts for refactoring should add the information that complements interfaces.
Related work (Cont’d)
Unit testing and DbC Contract4J JML Cona [Skotiniotis 2004]
28
All dynamic behavior cannot necessarily be checked in our approach based only on static program analysis.
Unit testing helps our approach.
6. Conclusions
29
Conclusions
The notion of RbC and a contract description method using COW are given.
These mechanisms provide the foundation for verifying the correctness of AO refactoring.
30