chapter 11. aspect interaction analysis€¦ · chapter 11. aspect interaction analysis günter...

Vorlesung „Aspektorientierte Softwareentwicklung“Sommersemester 2008So e se este 008

Chapter 11Chapter 11.Aspect Interaction Analysis

Günter Kniesel

Computer Science Department

U i it f BUniversity of Bonn

[email protected]

R O O T S

Vorlesung „Aspektorientierte Softwareentwicklung“Kapitel 11: Aspect Interaction Analysisap te spect te act o a ys s

Interactions and Interferences

The Problem

Distinguishing Interactions and Interferences

Classification of Interferences and Examples

R O O T S

The Bad

Problem: crosscutting and tangled concernsth d f tthread safetypersistencesecurity...

crosscutting

tangling

Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-3 R O O T S

The Good

Multi-dimensional separation of concerns

Aspects = Modular representation of concernsp p

it

thread safetyaspect

persistenceaspect


security aspect

The Ugly

To be effective, aspects must be "woven" back into their base classesinto their base classesAspect Interaction Problem: How to compose i d d tl d l d t ???independently developed aspects???

it

thread safetyaspect

persistenceaspect


security aspect

Aspect Interaction

Aspect-base interactionEach aspect interacts with the base class to which it isEach aspect interacts with the base class to which it is appliedChanges its semantics in desired and undesired waysChanges its semantics in desired and undesired ways

Aspect aspect interactionAspect-aspect interactionEach aspect interacts with the other aspects applied to the same base classaspects applied to the same base classmay be intendedmay be unintended but not undesired How to may be unintended but not undesiredmay be undesiredmay be broken

distinguish these?

t


may be broken aspectinterference

Aspect Interaction

Aspect-base interactionEach aspect interacts with the base class to which itEach aspect interacts with the base class to which it is appliedChanges its semanticsg

Aspect-aspect interactionAspect aspect interactionEach aspect interacts with the other aspects applied to the same base classp ppmay be intendedmay be unintended but not undesired How to may be unintended but not undesiredmay be undesired but not brokenmay be broken

distinguish these?

aspect


may be broken aspectinterference

Unintended Interaction

An aspect interacts with another one although the programmer didn't anticipate itprogrammer didn t anticipate it The interaction is necessary for fulfilling the task

f th tof the aspectE.g. logging applies to a component of which I didn't even know that it exists That‘s OK, I want to log everything, anyway!

Analysis makes interactions visible Programmer gets confidence into his code 'Hey itProgrammer gets confidence into his code Hey, it works better than I thought!'


Undesired Interaction

An aspect interacts with onother one although it shouldn'tshouldn tPossibly a consequence of a too generic pointcut

E.g. Security aspect contains a wildcard template that matches code in other aspects, preventing them from

ki i t d dworking as intendedNot OK, I intended the security policy only for the b d M t t h i il dbase code. My aspects must have more priviledges.

Analysis makes intractions visible Programmer becomes aware of undesired interactions and can fix them


Undesired vs. Broken Interaction

Undesired interaction (⊂ Interference)An aspect interacts with onother one although it shouldn'tAn aspect interacts with onother one although it shouldn t

Write Interference: Change state that affects behaviour of otherRead Interference: Read state that should not be accessibleOutput Interference: Side effects in the wrong order

B k i t ti ( I t f )Broken interaction (⊂ Interference)Two aspects interact in a way that will lead to problems at weave-time

I l t iIncomplete weavingIncorrect weavingInfinite weaving

Analysis makes intraction patterns visible and diagnoses the faultProgrammer must find a solution, otherwise the program isunweavable


unweavable

Topics of this Talk

Aspect-aspect interaction and interferenceI t ti D t tiInteraction Detection

How to capture interaction precisely?

Interaction ResolutionHow to control interaction such that it does not breakHow to control interaction such that it does not break anything?

Interference DetectionInterference DetectionHow to capture interference precisely?


Constraints

Independent DevelopmentB lBase classesAspects

Aspects as ComponentsImplementation details unknownp

Unanticipated CompositionNobod can tell o ho aspects related to eachNobody can tell you how aspects related to eachother

St d PStressed ProgrammersLightweight approach


No extra specifications of aspect (or base) behaviour

Ordering of Aspects In AspectJ

Possibly Interfering Aspectsaspect DisallowNulls {

pointcut allTypeMethods(Type obj): call(* *(..)) && args(obj, ..);

before(Type obj): allTypeMethods(obj) { if (obj == null) throw new RuntimeException();

} }

aspect CountEntry {aspect CountEntry { pointcut allTypeMethods(Type obj): call(* *(..)) && args(obj, ..);

static int count = 0; before(): allTypeMethods(Type) {before(): allTypeMethods(Type) {

count++; }

}

Explicit Aspect Precedence Declarationaspect Ordering {

d l d C tE t Di ll N ll


declare precedence: CountEntry, DisallowNulls; }

Ordering of Aspects isn‘t sufficient!

ExampleBase program: contains method work()“Base program: contains method „work()Aspect „Move“: goInsideRoom before starting workand goOutsideRoom afterwardsand goOutsideRoom afterwardsAspect „Door“: openTheDoor before starting workand closeTheDoor afterwardsand closeTheDoor afterwardsOnly sensible order

openTheDoor goInsideRoom work goOutsideRoom closeTheDooropenTheDoor goInsideRoom work goOutsideRoom closeTheDoor

Not achievable with aspect-level ordering!Too coarse-grainedToo coarse grained

Ostermann and Kniesel: „Independent Extensibility --an open challenge for AspectJ and Hyper/J“, March


p g p yp30, 2000

Need for Automated Analysis

On the previous slide, one might conclude thatfiner-grained ordering would be sufficientfiner-grained ordering would be sufficient.

Explicitly specify relative order of individual advices!

However, this is …… tedious and error-prone if the number of advicesand introductions is not very small…impossible under the assumptions mentionedbefore

independent developmentblack box aspectsblack-box aspectsunanticipated composition

Therefore we need automated analysis!


Therefore we need automated analysis!


Weaving Interferences

R O O T S

The Problem isn't Aspect-Specific!

Collaborative software developmentH t h i i d d t i ltHow to synchronize independent, simultaneous refactorings?

C fi ti tConfiguration managementHow to merge different branches?

Pattern sequencesHow do multiple patterns interact?How do multiple patterns interact?How to apply them together?

C b liCommon baselineProgram transformations


gHow do transformations interact?

Outline

From Aspect Interaction to Transformation InteractionInteractionConditional Program Transformations (CTs) Example with CTsInteraction Analysis for CTsInteraction Analysis for CTsRelated workConclusions



Conditonal Transformations

- Textual Representation -

- Concrete Aspect Interaction Example -

- Interaction Resolution by Topological Sorting -

- Dealing with Cyclic Interaction Graphs -

R O O T S

Example

Concerns

Thread safety “Access” transformer yAdds getField() and setField() methods for every fieldReplaces field accesses by accessor method invocations

Performance tuning “Counter” transformer gAdds field "Field_counter" for every field named "Field"Adds code to increment "Field_counter" before any access to "Field"


Program, Conditions, Transformations, CTs

Alphabet Σ of program elements (choose your own)

e.g. Σ = { class(name), field(name,class), method(name,class),

Condition Language

getfield(field,encl), call(method, encl), increment(field, encl) }

g g

C ≡ EC ⏐ EC ∧ C ⏐ EC ∨ C ⏐ not(C) EC ≡ true ⏐ false ⏐ exists(elem) : elem ∈ Σ( )

Transformation Language

⏐T ≡ ET ⏐ ET , TET ≡ add(elem) ⏐ delete(elem) ⏐ replace(elem1,elem2) : elem ∈ Σ

Conditional Transformation Language

CT ≡ C → T // single CT


CT ≡ C → T // single CTCTS ≡ CT | CT && CTS | CT || CTS // CT sequences

Conditional Transformations

Syntax CT ≡ C → T

Precondition Transformation

E l

exists(field(F C)) ∧ exists(class(C)) ∧ not(exists(method(<get>F C))CT ≡

Example For brevity we leave out the 'exists' predicate on the next slides

exists(field(F,C)) ∧ exists(class(C)) ∧ not(exists(method(<get>F,C))

add(method(<get>F,C) ) , add(getfield(F,<get>F) )CT ≡

→

public class C {

B b = new B();

public class C {

B b = new B();

...

B getB() {return b;

}...


} }

AddGetter: Create Accessor Method

AddGetterfor all fields that have no getter method ...... add method that returns the field's value

field(F,C) ∧ class(C) ∧ not(method(<get>F,C) AddGetter ≡→

public class C { public class C {

add(method(<get>F,C)) , add(getfield(F,<get>F))→

B b = new B(); B b = new B();

B getB() {

...

return b;}

...


} }

UseGetter: Replace Field Accesses

UseGetterfor all fields that have a getter method andgfor all read accesses to the field outside of its getter method...... replace the read access by the getter invocation

class(C) ∧ field(F,C) ∧ method(<get>F,C) ∧getfield(F,M) ∧ M≠<get>F

UseGetter ≡

replace(getfield(F,M) , call(<get>F,M) )


→

B b = new B();

B getB() {...}

B b = new B();

B getB() {...}

foo() {...b.m();

foo() {...getB().m();


} }

} }

AddCnt: Add Counter Field

AddCntfor all fields F that do not have a counter field and are not th l t fi ldthemselves counter fields ... ... add a field named F_counter

field(F,C) ∧ class(C) ∧not(field(F<_count>,C) ) ∧ F ≠ *<_count>

AddCnt ≡

add(field(F<_count>,C) )


→

B b = new B(); B b = new B();

int b_count;

...

_

...


} }

IncCnt: Increment Counter

IncCntfor all read accesses to a field that has a counter that has noi t tiincrement operation ...... add an increment of the counter

getfield(F,M) ∧ field(F,C) ∧ field(F<_count>,C) ∧not(increment(F<_count>,M) )

IncCnt ≡

add(increment(F<_count>,M) )


→

B b = new B();

int b_count;

B b = new B();

int b_count;_

foo() {

b.m();

_

foo() {b_count++;b.m();


} }

} }

Joint Application

Independent development ofAddCnt, IncCnt and

readb_count++;

as shorthand for

AddGetter, UseGetterJoint application to same program

setB_count(getB_count()+1);

initial programmpublic class C {B b = new B();

expected resultpublic class C {B b = new B();();

void manipulB() { b.m();

}

();int b_count=0;void manipulB(){ getB().m();

}} }B getB() {b_count++;return b;

}

}

}int getB_count() {return b_count;

}}} }

Initial Program

AddCnt, IncCnt, AddGetter, UseGetter Chosen order of application

public class C {B b = new B();

void manipulB(){

b m();b.m(); }

}


Step 1

AddCnt, IncCnt, AddGetter, UseGetter

public class C {B b = new B();i t b t 0int b_count=0;void manipulB(){

b m();b.m(); }

}


Step 2


public class C {B b = new B();i t b t 0int b_count=0;void manipulB(){b_count++;b m();b.m();

}}


Step 3


public class C {B b = new B();i t b t 0int b_count=0;void manipulB(){b_count++;b m();b.m();

}B getB(){

return b;}int getB count(){int getB_count(){return b_count;

}}


}

Step 4


public class C {B b = new B();i t b t 0int b_count=0;void manipulB(){b_count++;getB() m();getB().m();

}B getB(){


}} No! IncCnt was not applied to all fields!Ready!?


} ppy

Step 4

AddCnt, IncCnt, AddGetter, UseGetterIf we're not ready,

why not simply start again?

public class C {B b = new B();i t b t 0

again?

Iterative weaving!int b_count=0;void manipulB(){b_count++;getB() m();getB().m();

}B getB(){


}} No! IncCnt was not applied to all fields!Ready!?


} ppy

Step 5 (2nd Iteration)



Fixpoint reached!int b_count=0;void manipulB(){b_count++;getB() m();

Further application of any CT does not change the

program anymore!getB().m();}B getB(){b count++; ready!

program anymore!

b_count++;return b;

}int getB count(){

ready!

int getB_count(){return b_count;

}}

But: Is this the intended result?


}

Observations: Problem

AddCnt, IncCnt, AddGetter, UseGetter Expected Result


public class C {B b = new B();i t b t 0int b_count=0;

void manipulB(){b_count++;getB() m();

int b_count=0;void manipulB(){

getB() m();getB().m();}B getB(){b count++;

getB().m();}B getB() {b count++;b_count++;

return b;}int getB count(){

b_count++;return b;

}int getB count() {O d d d t lt P d ?int getB_count(){

return b_count;}

}

int getB_count() {return b_count;

}}

Order dependent result iteration alone does not help

Possible orders: 4! = 24

Proper order?one or many?how to characterize it?


} }

Observations: Cause of Problem


public class C {B b = new B();i t b t 0int b_count=0;void manipulB(){b_count++; getB() m();getB().m();

}B getB(){b count++;b_count++;return b;

}int getB count(){int getB_count(){return b_count;

}}

Violation of trigger conditions UseGetter violates IncCnt condition

by removing a field access:

Triggering of conditions AddGetter triggers IncCnt condition

by adding field access to b


} ... by removing a field access: b getB()

... by adding field access to b


Approach

Describe effect of atomic transformation as postcondition

derive effect of transformation sequence as postcondition

derive triggering as postconditions that match preconditons

derive inhibition as postconditions that match the negation of preconditons

infer proper order from the interaction graph

R O O T S

Approach

Observation: Transformations influence truth of conditionstransformations make conditions true "triggering"transformations violate conditions "inhibition“

IdeaAnalyse set of CTs (independent of a base program)Find out about their potential triggering and inhibitionUse this knowledge to determine a "good" CT execution orderUse this knowledge to determine a good CT execution order

Three-Step ApproachDescribe effect of transformation on conditions

postconditionsCompare postconditions and preconditions to identify triggering and inhibition dependencies

dependency graphAnalyse the structure of the dependency graph to identify problems or order the CTs

l b l d di ti


global order or error diagnostics

Deriving the Postcondition of a CT

PreconditonExpresses what must be true

EffectExpresses what is true after a p

before a transformation is performed.

Transformation

ptransformation, regardless of what was true before.

InvariantTransformationEnsures a certain effectPossibly invalidates a part of

InvariantThe part of the precondition that is still true after the Possibly invalidates a part of

the precondition transformation

Effect(t)

d l(b)

Effect(t)

( b) )

not(b)

∨

Postcond

P diti

del(b)

I i t( t)

(a ∨ b) ∧ c)

T f ti t

( a ∨ b) ∧ c)

∨ dition(p,t


Precondition p Invariant(p,t)Transformation t )

Deriving the Postcondition of a CT

PreconditonExpresses what must be true

EffectExpresses what is true after a p

before a transformation is performed.

Transformation

ptransformation, regardless of what was true before.

InvariantTransformationEnsures a certain effectPossibly invalidates a part of

InvariantThe part of the precondition that is still true after the Possibly invalidates a part of

the precondition transformation

PostconditionExpresses what is true after aExpresses what is true after a transformation, considering the invariant.


Plan for the next slides

Single transformation tff t(t)effect(t)

CT c→t with single transformation tinvariant(c,t)postcondition(c,t)p ( , )

CT c→t with transformation sequence tt diti (c t)postcondition(c,t)


Effect of Single Transformation

Single Transformationadd l (A B) dd(B) d l (A)adddelete

Transformation effect

replace(A,B) = add(B) ° delete(A)

Transformation effectDescribes effect of transformation as condition Weakest condition that is guaranteed to hold after aWeakest condition that is guaranteed to hold after a transformation

Effect of atomic transformationeffect(add(elem)) ≡ exists(elem) effect(delete(elem)) ≡ not(exists(elem))

Example: effect(add(classDefT(Id,Pkg,N,M)) = exists(classDefT(Id,Pkg,N,M))

PropertyValid for all variable substitions for which the


programm-independentValid for all variable substitions for which theprecondition is true on any current program.

Invariant (Propositional Logic)Informal DefinitionInformal Definition

The part of the precondition that is not invalidated by t f tia transformation

Formal DefinitionLet c, c1, c2 denote conditions and let e be the effect of the single transformation t.

invar(c1 ∧ c2, t) ≡ invar(c1, t) ∧ invar(c2, t)invar(c1 ∨ c2, t) ≡ invar(c1, t) ∨ invar(c2, t)i (c t) c c and e different

The effect of tinvalidates a previously trueinvar(c, t) ≡ c : ¬c and e different

invar(c, t) ≡ false : ¬c and e equal

previously true subcondition

Exampledel(b)

Effect(t)

(a ∨ b) ∧ c)

not(b)


Precondition p Invariant(p,t)Transformation t ( a ∨ false) ∧ c)

Invariant (First-order Logic)Informal DefinitionInformal Definition

The part of the precondition that is not invalidated by a transformationa transformation

Formal DefinitionL t d t diti d l t b th ff tLet c, c1, c2 denote conditions and let e be the effect of the single transformation t. Let θ be the most general unifier of ¬c and e.general unifier of ¬c and e.

invar(c1 ∧ c2, t) ≡ invar(c1, t) ∧ invar(c2, t)invar(c1 ∨ c2, t) ≡ invar(c1, t) ∨ invar(c2, t)

Only the substitutions subsumed by θ are

invar(c, t) ≡ c : ¬c and e not unifiableinvar(c, t) ≡ c ∧ ¬eq(θ) : unifiable with unifier θ

subsumed by θ are invalidated, not the entire literal

Exampledel(b(A,2,B))

Effect(t)

(a ∨ b(X,Y,f) ∧ c)

not(b(A,2,B))


Precondition pInvariant(p,t)

Transformation t ( a ∨ (b(X,Y,f) ∧ ¬(X=A∧Y=2∧B=f)) ∧ c)

Unifiability Constraints(for First-Order Invariant)(for First Order Invariant)

Definition of eq(θ)Let θ be any substitution, that is, any (possibly empty) set ofbindings: θ = {vari ← termi | i=1..n} An empty substitution set corresponds to the condition „true“.p y p „A non-empty substitution corresponds to a conjunction ofunifiability constraints vari = termi

eq(θ) ≡ true : if θ = { }

Example 1

eq(θ) ≡ true : if θ = { }eq(θ) ≡ v1 = tnθ ∧ … ∧ vn = tnθ : if θ = {vi ← ti | i=1..n}

Example 1θ = {X ← A, Y ← 2, B ← f} = mgu( b(X,Y,f), b(A,2,B) ) eq(θ) ≡ X=A ∧ Y=2 ∧ B=f

Example 2θ = { } = mgu( meth(F,C), meth(F,C) )

(θ) t


eq(θ) ≡ true

Why take the mgu?

On the previous slide we used the most general unifier (mgu) of a query literal and the effectunifier (mgu) of a query literal and the effect

mgu( b(X,Y,f), b(A,2,B) ) Effect(t)not(b(A,2,B))

Precondition p

del(b(A,2,B))(a ∨ b(X,Y,f) ∧ c)

Transformation t ( a ∨ (b(X,Y,f) ∧ ¬(X=A∧Y=2∧B=f)) ∧ c)

JustificationTh th diti d hi h t

Invariant(p,t)

The mgu expresses the conditions under which a true substitution for the precondition literal b(X,Y,f) would be invalidated by the effect not(b(A,2,B)).y ( ( , , ))Adding these conditions to the invariant produces a single expression that describes exactly what is true ft th t f ti


after the transformation

Postcondition of a Simple CT

Simple CT cond → transContains only a single elementary transformation transContains only a single elementary transformation trans(see prev. slides)

CT PostconditionIs the weakest condition that is guaranteed to be true after the CT.The transformation effect is part of the postcondition

effect(trans) – as defined previously

The invariant is part of the postconditionThe invariant is part of the postconditioninvar(cond,trans) – as defined previously

post( cond, trans ) = effect(trans) ∨ invar(cond, effect(trans))

We ignore anything that is true but is not expressed in the

Disjunction because theeffect holds even if the


but is not expressed in the precondition cond

effect holds even if theinvariant is „false“

Postcondition of an Arbitrary CT

Arbitrary CT cond → t1…tnC t i bit t f ti t1 tContains arbitrary transformation sequence t1…tn

CT PostconditionIs the weakest condition that is guaranteed to be trueafter the CT.Later transformations possibly invalidatepreconditions and effects of previous onesTherefore the postcondition of a transformationsequence is the postcondition of the last t f ti t li d t th t dit f thtransformation, tn, applied to the postconditon of thetransformation Sequence t1…tn-1

t( cond t t ) ff t(t ) i ( t( cond t t ) ff t(t ))


post( cond, t1…tn ) = effect(tn) ∨ invar( post( cond, t1…tn-1 ), effect(tn))

Example: Derive Postcondition of CT

effect(add(elem)) ≡ exists(elem) effect(delete(elem)) ≡ not(exists(elem))

Summary of Formulas

effect(delete(elem)) ≡ not(exists(elem))invar(c1 ∧ c2, t) ≡ invar(c1, t) ∨ invar(c2, t)invar(c1 ∨ c2, t) ≡ invar(c1, t) ∨ invar(c2, t)invar(c, t) ≡ c : ¬c and e not unifiableinvar(c, t) ≡ c ∧ ¬eq(θ) : unifiable with unifier θpost( c, t1 ) ≡ effect(t1) ∨ invar(c, effect(t1)) p ( , 1 ) ( 1) ( , ( 1))post( c, t1…tn ) ≡ effect(tn) ∨ invar( post( c, t1…tn-1 ), effect(tn))

Input: The AddGetter CTexists(field(F,C)) ∧ exists(class(C)) ∧ not(exists(method(<get>F,C)))

add( method(<get>F,C) ) , add( getfield(F,<get>F) )

exists(field(F,C)) ∨ exists(class(C)) ∨ not(exists(method(<get>F,C)))i t ( th d( t F C) ) i t ( tfi ld(F t F) )

Output: Its Postcondition


exists( method(<get>F,C) ) ∨ exists( getfield(F,<get>F) )

Example: Derive Effect of CT

effect(add(elem)) ≡ exists(elem) effect(delete(elem)) ≡ not(exists(elem))

Summary of Formulas

effect(delete(elem)) ≡ not(exists(elem))invar(c1 ∧ c2, t) ≡ invar(c1, t) ∧ invar(c2, t)invar(c1 ∨ c2, t) ≡ invar(c1, t) ∨ invar(c2, t)invar(c, t) ≡ c : ¬c and e not unifiableinvar(c, t) ≡ c ∧ ¬eq(θ) : unifiable with unifier θpost( c, t1 ) ≡ effect(t1) ∨ invar(c, effect(t1)) p ( , 1 ) ( 1) ( , ( 1))post( c, t1…tn ) ≡ effect(tn) ∨ invar( post( c, t1…tn-1 ), effect(tn))effect( c, t1…tn ) ≡ effect(tn) ∨ invar( post( true, t1…tn-1 ), effect(tn))

exists(field(F,C)) ∧ exists(class(C)) ∧ not(exists(method(<get>F,C)))Input: The AddGetter CT

add( method(<get>F,C) ) , add( getfield(F,<get>F) )

i t ( th d( t F C) ) i t ( tfi ld(F t F) )

Output: Its Effect


exists( method(<get>F,C) ) ∨ exists( getfield(F,<get>F) )

Dependencies

A possibly triggers BA‘s postcondition makes a literal in B's preconditon true

BAA s postcondition makes a literal in B s preconditon true

… ∨ exists(e1) ∨ …Post(CTA) ≡ ... exists(e2) ... ...CTB ≡

A possibly inibits B BA

∃ γ = mgu(e1,e2)

A possibly inibits BA‘s postcondition makes a literal in B's preconditon false

… ∨ exists(e1) ∨ …Post(CTA) ≡ ... not(exists(e2)) ... ...CTB ≡

∃ γ = mgu(e1,e2)

Dependency computation is independent of a programDependencies describe potential interactions

γ g ( , )


Dependencies describe potential interactions

Dependency Analysis of Sample CTs

Addfield(F C) ∧ class(C) ∧ not(method(<get>F C) )AddGetter

AddCnt

AddGetter

field(F,C) ∧ class(C) ∧ not(method(<get>F,C) )add(method(<get>F,C) ) , add(getfield(F,<get>F) )

UseGetter

Use Inc

getfield(F,M) ∧ field(F,C) ∧ class(C) ∧ method(<get>F,C) ∧ M≠<get>F


UseGetter

UseGetter

IncCnt


field(F,C) ∧ class(C) ∧ F ≠ *< count> ∧AddCnter

( , ) ( ) _not(field(F<_count>,C) )



IncCnter



Dependency Analysis (1)

field(F C) ∧ class(C) ∧ not(method(<get>F C) )AddGetter

Addfield(F,C) ∧ class(C) ∧ not(method(<get>F,C) )add(method(<get>F,C) ) , add(getfield(F,<get>F) )

UseGetter

AddCnt

AddGetter

getfield(F,M) ∧ field(F,C) ∧ class(C) ∧ method(<get>F,C)∧ M≠<get>F


UseGetter getter method

Use Increplace(getfield(F,M) , call(<get>F,M) )


UseGetter

IncCnt




IncCnter






UseGetter

AddCnt

AddGetter

fieldaccess

getter methodgetfield(F,M) ∧ field(F,C) ∧ class(C) ∧ method(<get>F,C)

∧ M≠<get>F


UseGetter

Use Increplace(getfield(F,M) , call(<get>F,M) )


UseGetter

IncCnt




IncCnter






UseGetter

AddCnt

AddGetter

fieldaccess


∧ M≠<get>F


UseGetter

Use IncACGetfieldaccess



UseGetter

IncCnt




IncCnter





Add fieldfield(F,C) ∧ class(C) ∧ not(method(<get>F,C) )add(method(<get>F,C) ) , add(getfield(F,<get>F) )

UseGetter

AddCnt

AddGetter

counterfield

fieldfieldaccess


∧ M≠<get>F


UseGetter




UseGetter

IncCnt




IncCnter





Add fieldfield(F,C) ∧ class(C) ∧ not(method(<get>F,C) )add(method(<get>F,C) ) , add(getfield(F,<get>F) )

UseGetter

AddCnt

AddGetter

getter method

counterfield

fieldfieldaccessgetfield(F,M) ∧ field(F,C) ∧ class(C) ∧ method(<get>F,C)

∧ M≠<get>F


UseGetter




UseGetter

IncCnt




IncCnter



Result: Dependency Graph

What does it tell us?S lf I hibiti AddSelf-Inhibition

Necessary, to prevent

AddCnt

AddGetter

infinite application of thesame CT to the same data

Use IncIssue a warning, for eachCT without self-inhibition!

ACGetUseGetter

IncCnt

Automatically determininethe "right" order

Use graph without self-inhibition arcs (next slide)


Automatic Ordering

Topological sortingP d d th t t

12

AddProduces order that respectsall dependencies:AddCnt AddGetter UseGetter IncCnt

AddCnt

AddGetter

This is the "right" order

AddCnt, AddGetter, UseGetter , IncCnt

Use IncEach CT is executedafter all CTs that cani fl it

ACGet

3 4

UseGetter

IncCnt

influence it

ConsequencesNo missed triggers: no iteration necessaryNo missed inhibition: no undo necessary


No missed inhibition: no undo necessaryComplete, correct and efficient weaving!

Cyclic Dependencies

Long Inhibition Cycle: contains inhibitions only (more than one)CTs prevent each otherCTs prevent each other⇒ joint application not possible⇒ potential conflict⇒ error message

T2T1

⇒ error message

Triggering cycle: contains triggering dependencies onlyTransformations trigger each otherTransformations trigger each other⇒ iteration could lead to a fixpoint⇒ iterative application required

k h th t it tT2T1 ∞

Mixed cycle: contains triggering and inhibition dependencies

⇒ ask whether to iterate

no automatic resolution possibleask the user T1 T2?


Triggering Cycles: Classification based on Trigger Action Classification based on Trigger Action

add

T2T1 ∞addTriggered by addition

implies monotonic "growth" of programfixpoint guaranteed – if iteration terminates

add

delete

fixpoint guaranteed if iteration terminates

Triggered by deletionimplies monotonic "shrinking" of programfixpoint guaranteed

T2T1 ∞delete

fixpoint guaranteedtermination guaranteed

Mi d t i i

delete

addMixed triggeringnon-monotonicno guarantee for a fixpoint

? T2T1

add


g pdelete

Summary

Dependency analysisBased on program independent description of "transformation effect"Based on program-independent description of transformation effectGenerates graph of inhibition and triggering dependencies

Interpretation of dependency graphInterpretation of dependency graphidentifies incomplete preconditions / pointcuts

missing self-inhibitionsmissing self-inhibitionsidentifies conflicts

negative cyclesidentifies required iteration

monotonic positive cyclesidentifies cases that require user inputidentifies cases that require user input

mixed cycles and mixed triggers in positive cyclesif there are no cycles, generates order that respects all dependencies

topological sorting of dependency graph

Benefits

Joint application ofindependently developed CT‘s

ibl

It works!

possibleCompleteness and correctness

No useless iterationNo missed triggers

It is efficientNo missed triggers

No undo necessary Simple infrastructure sufficientNo undo necessaryNo missed inhibition

Simple infrastructure sufficient


References: CTs and their Analysis

A Logic Foundation for Conditional Program TransformationsGünter KnieselTechnical Report IAI-TR-2006-1, Computer Science Department III, University ofTechnical Report IAI TR 2006 1, Computer Science Department III, University of Bonn. ISSN 0944-8535. January 2006.

Static Composition of RefactoringsGünter Kniesel, Helge KochGünter Kniesel, Helge KochIn: Ralf Lämmel (Ed.): Science of Computer Programming 52 (2004), special issue on "Program Transformation", p. 9-51, Elsevier Science, 2004.Digital Object Identifier: doi:10.1016/j.scico.2004.03.002If the DOI or Wiley website is unreachable, here is a local copy of a preprint.

Next WeekAn Analysis of the Correctness and Completeness of Aspect Weaving

Gü t K i l U B dGünter Kniesel, Uwe Bardey in Proceedings of Thirteenth Working Conference on Reverse Engineering (WCRE 2006), Oct. 23-27, Benevento, Italy, ISBN 0-7695-2719-1, p. 324-333, IEEE 2006.

Transformation dependency analysis - A comparison of two approachesTom Mens, Günter Kniesel, Olga RungeProceedings of Langages et Modèles à Objets (LMO2006), March 22-24, 2006, Nîmes France special issue of L'Objet Hermes Science Publishing London


Nîmes, France, special issue of L Objet, Hermes Science Publishing, London, 2006.

chapter 11. aspect interaction analysis€¦ · chapter 11. aspect interaction analysis günter...

Documents