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