1 / 30

Contract-based Verification for Aspect-oriented Refactoring

ICST 2008. 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.

iliana
Download Presentation

Contract-based Verification for Aspect-oriented Refactoring

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ICST 2008 Contract-based Verification for Aspect-orientedRefactoring NaoyasuUbayashi (Kyushu Institute of Technology) JinjiPiao (Kyushu Institute of Technology) SuguruShinotsuka (Kyushu Institute of Technology) Tetsuo Tamai (University of Tokyo) April 11, 2008

  2. 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 ! Fragile Pointcuts Unexpected Weaving

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

  4. Outline • Motivation • Refactoring by Contract • Contract template • Implementation • Related work • Conclusions

  5. 1. Motivation

  6. Aspect-oriented programming AOP is a programming paradigm in which crosscutting concerns are modularized as aspects. UpdateSignaling pointcut after (Shape s): (execution(void set*(..) || execution(void Shape+.moveBy(int,int))) && target(s) { s.redraw(); } AspectJ advice

  7. Refactoring catalogues for AOP 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 Refactoring catalogues [Cole 2005] [Monteiro 2005] 1. For extraction of crosscutting concerns Super Aspect 3 2 Aspect 2. For restructuring the internals of aspects 1 3. For dealing with generalization 27 refactoring patterns proposed by Monterio

  8. But, AO refactoring is not easy … • Correct refactoring should satisfy the following constraints • Behavior must be preserved before/after refactoring • Refactoring should improve the internal structure as defined by refactoring catalogues Correct ? How to verify?

  9. Example: 1st refactoring • Behavior preservation [OK] • Structure improvement [NG] Behave correctly • 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(); } • } • 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 • 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(); } • } • 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(); } • } Forget to remove redraw()

  10. Example: 2nd refactoring • Behavior preservation [NG] • Structure improvement [OK] • 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); Redraw() is called three times! • 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(); } • }

  11. Problems in AO refactoring • 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.

  12. Our approach We apply logic programming to verify the accuracy of aspect-oriented refactoring. Challenge In AOP, primitive predicates for specifying constraints must check the impact of weaving.

  13. 2. Refactoring by Contract

  14. RbC: Refactoring by Contract Precondition states under which conditions refactoring can be applied. Postcondition states what conditions should be verified after refactoring has been accomplished. Invariant states what conditions refactoring should preserve. Programmer Contract AO Program Check precondition before refactoring invariant postcondition after refactoring Check Program Structure Program Behavior

  15. COW: COntractWriting language COW is a language for describing predicates based on first-order logic. program structure class, method, extends, owner, aspect, pointcut, intertypeOwner, beforeAdvice, afterAdvice, aroundAdvice, etc. program behavior call, write, read, controlFlow, dataFlow, etc.

  16. Contract for 1st Refactoring 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) ); } Precondition Postcondition

  17. Contract for 2nd Refactoring contract LineBehavior restricts Line { void moveBy(int, int){ invariant (Redrawing.once()); } } 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() } }

  18. 3. Contract template

  19. Contract template ctemplate T_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>) ); }

  20. Template composition Contract X Contract Y ctemplate T_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>) ); } Ctemplate T_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>) ); } Parameter matching If postconditions of contract X are stronger than preconditions of contraxt Y, these templates can be composed.

  21. Evaluation: template coverage 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 %

  22. 4. Implementation

  23. COW Contract Verifier AspectJ Code Contracts Parser & Program Analyzer COW to Prolog Translator Prolog facts (CFG) Prolog Query Contract Checker

  24. CFG: Control Flow Graph s1: -in: Point.moveBy() call(’s1’, ’Point.moveBy(int,int)’) next(’s1’,’s2’,[’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. … s2: Point.moveBy(intdx, intdy) entry(’Point.moveBy(int,int)’,’s2’) next(’s2’,’s3’,[’Line.moveBy(int,int)’,’Point.moveBy(int,int)’]) s3: Point.x += dx next(’s3’,’s4’,[’Line.moveBy(int,int)’,’Point.moveBy(int,int)’]) s4: Point.y += dy next(’s4’,’s5’,[’Line.moveBy(int,int)’]) s5: -out: Point.moveBy()

  25. 5. Related Work

  26. Related work • Logic-based verification • AspectJ programming laws for deriving behavior-preserving transformations [Cole 2005] • Domain-specific language for Refactoring [Verbaere 2006] In RbC, domain-specific contract templates can be defined using COW predicates.

  27. 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] • 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.

  28. Related work (Cont’d) • Unit testing and DbC • Contract4J • JML • Cona [Skotiniotis 2004] • All dynamic behavior cannot necessarily be checked in our approach based only on static program analysis. • Unit testing helps our approach.

  29. 6. Conclusions

  30. 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.

More Related