Modular Reasoning inAspect-oriented Languages
Tim Molderez
Promotor: prof. dr. Dirk Janssens
AnsymoAntwerp Systems and Software Modelling
2
Painting the big picture Software can get quite big and complex
How to keep software manageable?
Software tends to change
How to keep software flexible?
3
How to keep it manageable?:Divide and conquer
a class
4
Flexibility in the real world
Subcontractors can substitute for contractors
The client shouldn’t care who gets the job done
That is, as long as the job gets done right,
according to the contract!• The subcontractor cannot require more than the contractor• The subcontractor cannot promise less than the contractor
5
Flexibility in software There are classes and subclasses
Subclasses can substitute for classes
The client of a class shouldn’t have to care
Each class has its own contracts• what it requires (preconditions) and what it ensures (postconditions)
Behavioural subtyping:• A subclass cannot require more than a class• A subclass cannot promise less than a class
6
Aspect-oriented programming
Some functionality is difficult to separate in classes• Spread across several places in the code• Tangled with other functionality• Examples: security, transaction management, …
Unless we have aspects• An aspect is (like) a class, but is allowed to implicitly
intervene with multiple other classes• Normally, classes make use of other classes by explicitly
calling them
7
Modular reasoning in aspect-oriented languages
Modular reasoning (about calls):
If the preconditions that you expect are satisfied,
you will get the postconditions that you expect
(even if aspects can intervene)
Question is: How to enable modular reasoning in
aspect-oriented languages?
8
Contributions ContractAJ: a minimal aspect-oriented language
A two-part approach for modular reasoning
Proof that the approach is sound
Dynamic & static tools to check the approach
Frame inference analysis
Comparing frames in aspects and advised classes
9
Switching to English
10
ContractAJ exampleclass Bank { int getBalance(Account acc) { return acc.amount; }
void doDeposit(Account to, int m) { to.amount += m; }
void doTransfer(Account from, Account to, int m){ from.amount -= m; to.amount += m; }}
11
Once more, with contracts
class Bank { … @requires from.amount >= m @ensures from.amount == \old(from.amount) – m @ensures to.amount == \old(to.amount) + m void doTransfer(Account from, Account to, int m){ from.amount -= m; to.amount += m; }}
12
A (stereo)typical example of an aspect
class Logger {
after bankLog: call (* Bank.do*(..)) {
log.write(…);}…
}
pointcut(specifies a set of points in time,
aka “join points”)
advice kindadvice name
advice body
advice
13
Another aspect: authentication
class Security{…around auth: call (* Bank.do*(Account
a, ..)) {if(isLoggedIn(a.owner)) {
proceed(a);}
}…
}now call Bank.do*
run this advice instead of Bank.do*
14
Modular reasoning in aspect-oriented languages
Two-part approach
Key observation: Around advice are a lot like the
contractor-subcontractor story
15
Modular reasoning in AOP
Bank.doTransfer
pre
post
Security.auth
Proceed:
What the developer sees: What actually happens:
time
bank.doTransfer(acc1,acc2,50);
Bank.doTransfer
pre
post
pre’
post’
16
The advice substitution principle
Around advice• Cannot require more than the method (or advice) it is replacing• Cannot promise less than the method (or advice) it is replacing
An advice may replace multiple methods (or advice)!
17
Before and after advice Before advice
• Slightly different than around advice: postconditions refer to the moment before the implicit proceed call, instead of after.
• Advice postconditions may not invalidate the preconditions of X.y
After advice• Preconditions refer to the moment after the
implicit proceed call.• Advice preconditions can rely on the
postconditions of X.y
Before advice
Bank.doTransfer(implicit)
pre’
post’
Bank.doTransfer(implicit)
After advicepre’
post’
18
Special cases Principle also applies if:
• Multiple advice share join points• Advice intercept advice executions
(higher-order advice)
Logger.log
Profiler.measure
TransacMgmt.perform
Bank.doTransfer
19
If you can’t satisfy the advice subst. principle
class Security {…@requires proc@ensures if(isLoggedIn()){proc}else{true}around auth: call(* Bank.do*(Account
acc, ..)) {if(isLoggedIn(acc.getOwner())) {
proceed(acc);}
}…
}
20
Restoring modular reasoning with the @advisedBy
clauseclass Bank {
@requires a1.m >= m@ensures old(a1.m)-m=a1.m && old(a2.m)
+m=a2.m@advisedBy Security.authvoid doTransfer(Account a1, Account a2, int
m) {…
}…
}
21
Effective specifications Presence of an @advisedBy clause
• Makes callers aware of the listed advice• Effectively changes the pre/postconditions that must be taken into
account when calling the method• Listed advice become aware of each other too• Dynamic conditions included in the effective specification
22
Soundness Modular reasoning is guaranteed
(for pre-and postconditions) if:• All bodies correctly implement their own specifications
(, but they can assume modular reasoning).• All classes are behavioural subtypes.• All advice satisfy either the ASP, or are correctly mentioned in an
@advisedBy clause.• ASP-compliant advice have a lower precedence than the others.
Proof by induction on reduction length• Consider all possible ways a body can be reached from a
method/proceed call
23
Dynamic enforcement Contract enforcement advice check all contracts at
runtime and produce an error when the approach is
not satisfied.
Simple, but not exhaustive
AspectJ implementation (available on Github)
24
Static enforcement Exhaustive, but only checks whether the specifications
satisfy the approach
Core problem: Determine whether one contract is
weaker/stronger than another
SMT solver is used to test premeth && !preadv
AspectJ implementation (available on Github, thanks to Luis Mayorga!)
25
Frame conditions Frame conditions: Aside from what a body will
change, it should also be specified what the body
will not change
Typically specified by listing only those variables that
might change
26
Frame conditions and aspects
Advice in @advisedBy clause: No issues here
And advice that satisfy the adv. subst. principle?• How often does it happen that an advice needs to modify more?
27
Frame inference analysis Writing frame conditions manually is tedious and error-prone
Compositional
Keeps track of what may/must be modified
Implemented for Java/AspectJ, using Ekeko & Soot
(available on Github)
28
How often does an advice need to modify more?
Not very often, in these cases
Perhaps no need to take drastic measures
to restore modular reasoning
Name Advice ASP Bad ASP
AJHSQLDB 106 55 12
AJHotDraw 47 43 13
Healthwatcher 73 64 3
MobileMedia 77 54 5
SpaceWar 13 11 0
Telestrada 46 22 0
29
The future Modular reasoning about pointcuts
A larger data set of aspect-oriented programs
Beyond AspectJ; finding the essence of aspects
30
Summary
The end Modular reasoning with aspects
• To remain unaware of advice: Use the ASP• To become aware of advice: Use @advisedBy
The approach is sound
It can be tested dynamically and statically
Frames can be inferred
Take-away: Aspects are powerful,
but they can be wielded responsibly
Top Related