chapter 11. aspect interaction analysis€¦ · chapter 11. aspect interaction analysis günter...
TRANSCRIPT
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
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-4 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-5 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-6 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-7 R O O T S
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!'
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-8 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-9 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-10 R O O T S
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?
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-11 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-12 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-13 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-14 R O O T S
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!
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-15 R O O T S
Therefore we need automated analysis!
Vorlesung „Aspektorientierte Softwareentwicklung“Kapitel 11: Aspect Interaction Analysisap te spect te act o a ys s
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-35 R O O T S
gHow do transformations interact?
Outline
From Aspect Interaction to Transformation InteractionInteractionConditional Program Transformations (CTs) Example with CTsInteraction Analysis for CTsInteraction Analysis for CTsRelated workConclusions
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-36 R O O T S
Vorlesung „Aspektorientierte Softwareentwicklung“Kapitel 11: Aspect Interaction Analysisap te spect te act o a ys s
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"
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-54 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-56 R O O T S
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;
}...
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-58 R O O T S
} }
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;}
...
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-59 R O O T S
} }
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) )
public class C { public class C {
→
B b = new B();
B getB() {...}
B b = new B();
B getB() {...}
foo() {...b.m();
foo() {...getB().m();
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-60 R O O T S
} }
} }
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) )
public class C { public class C {
→
B b = new B(); B b = new B();
int b_count;
...
_
...
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-61 R O O T S
} }
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) )
public class C { public class C {
→
B b = new B();
int b_count;
B b = new B();
int b_count;_
foo() {
b.m();
_
foo() {b_count++;b.m();
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-62 R O O T S
} }
} }
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(); }
}
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-64 R O O T S
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(); }
}
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-65 R O O T S
Step 2
AddCnt, IncCnt, AddGetter, UseGetter
public class C {B b = new B();i t b t 0int b_count=0;void manipulB(){b_count++;b m();b.m();
}}
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-66 R O O T S
Step 3
AddCnt, IncCnt, AddGetter, UseGetter
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;
}}
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-67 R O O T S
}
Step 4
AddCnt, IncCnt, AddGetter, UseGetter
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(){
return b;}int getB count(){int getB_count(){return b_count;
}} No! IncCnt was not applied to all fields!Ready!?
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-68 R O O T S
} 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(){
return b;}int getB count(){int getB_count(){return b_count;
}} No! IncCnt was not applied to all fields!Ready!?
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-69 R O O T S
} ppy
Step 5 (2nd Iteration)
AddCnt, IncCnt, AddGetter, UseGetter
public class C {B b = new B();i t b t 0
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?
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-70 R O O T S
}
Observations: Problem
AddCnt, IncCnt, AddGetter, UseGetter Expected Result
public class C {B b = new B();i t b t 0
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?
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-71 R O O T S
} }
Observations: Cause of Problem
AddCnt, IncCnt, AddGetter, UseGetter
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-72 R O O T S
} ... by removing a field access: b getB()
... by adding field access to b
Vorlesung „Aspektorientierte Softwareentwicklung“Kapitel 11: Aspect Interaction Analysisap te spect te act o a ys s
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-75 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-76 R O O T S
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.
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-77 R O O T S
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)
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-78 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-79 R O O T S
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)
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-80 R O O T S
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))
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-81 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-82 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-83 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-84 R O O T S
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 ))
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-85 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-86 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-87 R O O T S
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 ( , )
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-88 R O O T S
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
replace(getfield(F,M) , call(<get>F,M) )
UseGetter
UseGetter
IncCnt
replace(getfield(F,M) , call(<get>F,M) )
field(F,C) ∧ class(C) ∧ F ≠ *< count> ∧AddCnter
( , ) ( ) _not(field(F<_count>,C) )
add(field(F<_count>,C) )
getfield(F,M) ∧ field(F,C) ∧ field(F<_count>,C) ∧not(increment(F<_count>,M) )
IncCnter
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-89 R O O T S
add(increment(F<_count>,M) )
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
replace(getfield(F,M) , call(<get>F,M) )
UseGetter getter method
Use Increplace(getfield(F,M) , call(<get>F,M) )
field(F,C) ∧ class(C) ∧ F ≠ *< count> ∧AddCnter
UseGetter
IncCnt
( , ) ( ) _not(field(F<_count>,C) )
add(field(F<_count>,C) )
getfield(F,M) ∧ field(F,C) ∧ field(F<_count>,C) ∧not(increment(F<_count>,M) )
IncCnter
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-90 R O O T S
add(increment(F<_count>,M) )
Dependency Analysis (2)
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
fieldaccess
getter methodgetfield(F,M) ∧ field(F,C) ∧ class(C) ∧ method(<get>F,C)
∧ M≠<get>F
replace(getfield(F,M) , call(<get>F,M) )
UseGetter
Use Increplace(getfield(F,M) , call(<get>F,M) )
field(F,C) ∧ class(C) ∧ F ≠ *< count> ∧AddCnter
UseGetter
IncCnt
( , ) ( ) _not(field(F<_count>,C) )
add(field(F<_count>,C) )
getfield(F,M) ∧ field(F,C) ∧ field(F<_count>,C) ∧not(increment(F<_count>,M) )
IncCnter
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-91 R O O T S
add(increment(F<_count>,M) )
Dependency Analysis (3)
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
fieldaccess
getter methodgetfield(F,M) ∧ field(F,C) ∧ class(C) ∧ method(<get>F,C)
∧ M≠<get>F
replace(getfield(F,M) , call(<get>F,M) )
UseGetter
Use IncACGetfieldaccess
replace(getfield(F,M) , call(<get>F,M) )
field(F,C) ∧ class(C) ∧ F ≠ *< count> ∧AddCnter
UseGetter
IncCnt
( , ) ( ) _not(field(F<_count>,C) )
add(field(F<_count>,C) )
getfield(F,M) ∧ field(F,C) ∧ field(F<_count>,C) ∧not(increment(F<_count>,M) )
IncCnter
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-92 R O O T S
add(increment(F<_count>,M) )
Dependency Analysis (4)
field(F C) ∧ class(C) ∧ not(method(<get>F C) )AddGetter
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
getter methodgetfield(F,M) ∧ field(F,C) ∧ class(C) ∧ method(<get>F,C)
∧ M≠<get>F
replace(getfield(F,M) , call(<get>F,M) )
UseGetter
Use IncACGetfieldaccess
replace(getfield(F,M) , call(<get>F,M) )
field(F,C) ∧ class(C) ∧ F ≠ *< count> ∧AddCnter
UseGetter
IncCnt
( , ) ( ) _not(field(F<_count>,C) )
add(field(F<_count>,C) )
getfield(F,M) ∧ field(F,C) ∧ field(F<_count>,C) ∧not(increment(F<_count>,M) )
IncCnter
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-93 R O O T S
add(increment(F<_count>,M) )
Dependency Analysis (5)
field(F C) ∧ class(C) ∧ not(method(<get>F C) )AddGetter
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
replace(getfield(F,M) , call(<get>F,M) )
UseGetter
Use IncACGetfieldaccess
replace(getfield(F,M) , call(<get>F,M) )
field(F,C) ∧ class(C) ∧ F ≠ *< count> ∧AddCnter
UseGetter
IncCnt
( , ) ( ) _not(field(F<_count>,C) )
add(field(F<_count>,C) )
getfield(F,M) ∧ field(F,C) ∧ field(F<_count>,C) ∧not(increment(F<_count>,M) )
IncCnter
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-94 R O O T S
add(increment(F<_count>,M) )
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)
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-95 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-96 R O O T S
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?
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-98 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-99 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-101 R O O T S
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
Dr. G. Kniesel, D. Speicher Vorlesung „AOSD – Aspektorientierte Softwareentwicklung“, Sommersemester 2008 11-104 R O O T S
Nîmes, France, special issue of L Objet, Hermes Science Publishing, London, 2006.