modular reasoning in aspect- oriented languages
Post on 23-Feb-2016
45 Views
Preview:
DESCRIPTION
TRANSCRIPT
Modular Reasoning inAspect-oriented Languages
Tim Molderez
AnsymoAntwerp Systems and Software Modelling
2
Aspect-oriented programming (AOP)
Typically extension of object-oriented language
Aims to improve separation of concerns by
modularizing crosscutting concerns
Crosscutting concerns: • Scattered in several places• Tangled with other concerns• Examples: logging, authentication, caching, profiling, …
3
A (stereo)typical example: logging
class Logger {…after bankLog: call(* Bank.do*(..)) {
log.write(stuff);}…
} advice
pointcut(specifies a set of “join points”)
kind (before/after/around) name
body
After every call to Bank.do*(…) , update the log
* Not AspectJ code; this is ContractAJ
4
Another example: authentication
class Security{…around auth: call(* Bank.do*(Account
acc, ..)) {if(isLoggedIn(acc.getOwner())) {
proceed(acc);}
}…
}calls Bank.do*
Execute advice instead of Bank.do*
5
AOP and obliviousness Obliviousness: Advice is executed implicitly
I’m calling silver bullet! With AOP, we can implement crosscutting concerns independent of everything else!
AOP considered harmful! An advice could break my existing code at any time!
Chill out you guys! There’s a middle ground here.
6
Modular reasoning The ability to reason about a module’s behaviour,
considering only the module itself
(and anything it explicitly refers to)
In imperative languages: no surprises…
In OOP: All classes must be behavioral subtypes (LSP)
… but what about AOP?
7
Modular reasoning To benefit from obliviousness,
advice may not cause any surprising behaviour.
8
Modular reasoning in OOP
Bird.fly
pre
post
Duck.fly
pre’
post’
Bird bird = new Duck();bird.fly();
What the developer sees: What happens at runtime:
time
9
Modular reasoning in OOP To avoid surprising behaviour, the Liskov
substitution principle should be respected.
All classes should be behavioural subtypes:• Precondition may not be strengthened• Postcondition may not be weakened• Invariants must be preserved
10
Modular reasoning in AOP
Bank.doTransfer
pre
post
Security.authpre’
post’
What the developer sees: What happens at runtime:
time
bank.doTransfer(acc1,acc2,50);
Proceed:Bank.doTransfer
11
Modular reasoning in AOP Similar to OOP, if all advice are seen as around advice:
An advice effectively substitutes for whatever it
advises.
Advice substitution principle (ASP):• Advice’s precondition may not be stronger than
the precondition of the advised join point• Postcondition may not be weakened• Invariant must be preserved
12
So.. that’s all there is to it? Yes*
* .. well, there are some big buts (and I cannot lie)• Before and after advice• Higher-order advice• Multiple advice sharing join points• Quantification• Call and execution pointcuts• What if you can’t satisfy the advice substitution principle?
Quantification Call and execution pointcuts Before and after advice …
13
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
Implicit proceed
pre
post
Implicit proceed
After advicepre
post
14
Special cases Principle also applies if:
• Multiple advice share join points• Advice intercept advice executions
Example• Advice 1,2 and 3 only need to comply with
Method’s contracts• Meta-advice complies with Advice 3’s
contracts
Advice 1
Advice 2
Meta-advice
Advice 3
Method
15
Quantification ASP defined in terms of a single join point
However, pointcuts are a quantification mechanism
and can match with many different join points• An advice may need to comply with many different contracts
(e.g. Bank.do* can match with several methods..)• Complying with the ASP becomes more difficult as the number of
contracts grows• Scaling problem can be mitigated using contract enforcement tools,
as well as using definitions of observers/spectators
16
What if you can’t satisfy the ASP?
class Security {…@pre proc@post if(isLoggedIn()){proc}else{true}around auth: call(* Bank.do*(Account
acc, ..)) {if(isLoggedIn(acc.getOwner())) {
proceed(acc);}
}…
}
ASP violation: This postcondition is weaker than the postcondition of Bank.do*
ASP violation cannot be prevented :The advice’s very purpose is to block (the postcondition of) Bank.do* when necessary.
17
Restoring modular reasoning with the @advisedBy
clauseclass Bank {
@pre a1.m >= m@post old(a1.m)-m=a1.m && old(a2.m)+m=a2.m@advisedBy Security.auth, Transaction.commitvoid doTransfer(Account a1, Account a2, int
m) {…
}…
}
• Explicitly expecting to be advised bySecurity.auth and Transaction.commit(in that order)
• @advisedBy added to all Bank.do* methods
18
Quantification Doesn’t the act of adding all these @advisedBy clauses
cancel out the benefits of quantification?• Yes, if you like to add the clauses manually.• In AspectJ: @advisedBy annotations can be generated fully automatically.• In ContractAJ: You can easily introduce a quantification mechanism to add
clauses in the right places.
Sidenote: It goes to show that programming concerns
more than just the language; the tools around it can be a
crucial component too.
19
Overriding advice Overriding only has purpose when you expect one thing,
but another thing is executed.
Nobody expects the Spanish inq execution of advice!
.. unless an @advisedBy clause is used.
The expectation @advisedBy Authentication.auth
could be filled in by e.g. RemoteAuthentication.auth
Satisfies the open-closed principle
20
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,aka the “effective pre/postconditions”
• Likewise, listed advice become aware of each other too, as theeffective pre/postcondition of proceed calls changes too
Intuition behind effective pre/postcondition:• Pre/postcondition of the first advice that will be executed,
as far as you can tell statically
21
Effective specificationsFind the next advice that will be executed;dynamic parts of pointcuts become part of the specification!
Fill in each occurrence of the proc keyword (with the next advice)
Before/after advice must include implicit proceed call
22
Effective specifications.. can be much simpler if none of the pointcuts have
dynamic parts: (which is the more common case)
23
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
24
Dynamic enforcement Contract enforcement advice check all contracts at
runtime and throw an exception when the approach
is not satisfied.
Simple, but not exhaustive
AspectJ implementation:
https://github.com/timmolderez/adbc
25
Static enforcement Work in progress (see Luis’s internship & thesis)
Core problem: Determine whether one contract is
weaker/stronger than another
Can be done with an SMT solver (Z3) by converting
contracts to SMT-lib format
presuper && !presub should not have a solution
26
Frame conditions Basic pre/postconditions and invariants don’t cut it to
perform formal verification.
Frame conditions: Aside from what a body will do, it
should also be specified what the body will not do.
Typically defined as @assignable clauses, which list
only those variables that might change.
27
Inferring frame conditions Built on top of Ekeko and Soot
Flow-sensitive: Traverse CFG of each body, keeping track
of aliases and modifications
Path-insensitive: Information is merged when if/while
branches join
Incremental: Only update what’s necessary
Modular: Okay to assume modular reasoning
28
Frame conditions in AOP Frame conditions can be used for multiple purposes
• Detect which fields an ASP-compliant advice is allowed to modify• Detect which properties a proceed call can preserve• Detect which advice can be executed concurrent to the
body being advised
29
Summary An approach to modular reasoning in AOP:
• Advice subsitution principle• @advisedBy clause
The approach is sound, and can be enforced both
dynamically and statically.
Modular reasoning in AOP is possible;
there is a useful middle ground.
top related