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 refactoring precondition postcondition invariant after refactoring Programmer Contract Check AO Program Program Structure Program Behavior Refactoring

4 Outline 1. Motivation 2. Refactoring by Contract 3. Contract template 4. Implementation 5. Related work 6. Conclusions

5 1. Motivation

6 Aspect-oriented programming AOP is a programming paradigm in which crosscutting concerns are 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 Aspect 1-3 Extract Fragment into Advice 1-4 Extract Inner Class to Standalone 1-5 Inline Class within Aspect 1-6 Inline Interface within Aspect 1-7 Move Field from Class to Inter-type 1-8 Move Method from Class to Inter-type 1-9 Replace Implements with Declare Parents 1-10 Split Abstract Class into Aspect and Interface 2-1 Extend Marker Interface with Signature 2-2 Generalize Target Type with Marker Interface 2-3 Introduce Aspect Protection 2-4 Replace Inter-type Field with Aspect Map 2-5 Replace Inter-type Method with AspectMethod 2-6 Tidy Up Internal Aspect Structure 3-1 Extract Superaspect 3-2 Pull Up Advice 3-3 Pull Up Declare Parents 3-4 Pull Up Inter-type Declaration 3-5 Pull Up Marker Interface 3-7 Push Down Advice 3-8 Push Down Declare Parents 3-9 Push Down Inter-type Declaration 3-10 Push Down Marker Interface 3-11 Push Down Pointcut 1. For extraction of crosscutting concerns 2. For restructuring the internals of aspects 3. For dealing with generalization 27 refactoring patterns proposed by Monterio Aspect Super Aspect 1 3 2

But, AO refactoring is not easy …  Correct refactoring should satisfy the following constraints 1.Behavior must be preserved before/after refactoring 2.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 AO Program Precondition states under which conditions refactoring can be applied. Invariant states what conditions refactoring should preserve. Postcondition states what conditions should be verified after refactoring has been accomplished. Program Structure Program 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 ctemplate T_MoveMethodFromClassToIntertype { requires( owner(, ) ); ensures( // condition 1 owner(, ) && // condition 2 intertypeOwner(, ) && // condition 3 !owner(, ) ); }

Ctemplate T_ReplaceIntertypeMethodWithAspectMethod { requires( // condition 1 owner(, ) && // condition 2 intertypeOwner(, ) ); ensures( // condition 1 owner(, ) && // condition 2 !intertypeOwner(, ) ); } ctemplate T_MoveMethodFromClassToIntertype { requires( owner(, ) ); ensures( // condition 1 owner(, ) && // condition 2 intertypeOwner(, ) && // condition 3 !owner(, ) ); } Template composition 20 Parameter matching If postconditions of contract X are stronger than preconditions of contraxt Y, these templates can be composed. Contract XContract Y

Evaluation: template coverage 21 No. Refactoring pattern 1-1 Change Abstract Class to Interface 1-2 Extract Feature into Aspect 1-3 Extract Fragment into Advice 1-4 Extract Inner Class to Standalone 1-5 Inline Class within Aspect 1-6 Inline Interface within Aspect 1-7 Move Field from Class to Inter-type 1-8 Move Method from Class to Inter-type 1-9 Replace Implements with Declare Parents 1-10 Split Abstract Class into Aspect and Interface 2-1 Extend Marker Interface with Signature 2-2 Generalize Target Type with Marker Interface 2-3 Introduce Aspect Protection 2-4 Replace Inter-type Field with Aspect Map 2-5 Replace Inter-type Method with AspectMethod 2-6 Tidy Up Internal Aspect Structure 3-1 Extract Superaspect 3-2 Pull Up Advice 3-3 Pull Up Declare Parents 3-4 Pull Up Inter-type Declaration 3-5 Pull Up Marker Interface 3-7 Push Down Advice 3-8 Push Down Declare Parents 3-9 Push Down Inter-type Declaration 3-10 Push Down Marker Interface 3-11 Push Down Pointcut Patterns: 27 Templates: 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 Contract Checker

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