interferences: aspect-base and between aspects
DESCRIPTION
Interferences: aspect-base and between aspects. Shmuel Katz, using slides from Lodewijk Bergmans. Composition Conflicts (code interference). Syntactical e.g. in the case of source code weaving the woven code can no longer compile Structural - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/1.jpg)
Interferences: aspect-base and between aspects
Shmuel Katz,
using slides from Lodewijk Bergmans
![Page 2: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/2.jpg)
Composition Conflicts(code interference)
• Syntactical– e.g. in the case of source code weaving the woven code can no longer
compile
• Structural– E.g. when introducing an existing method or creating cyclic inheritance
• Semantic– Sometimes directly derivable from code
• e.g. variable access, calling dependencies
– design intentions• "is it a bug, or is it a feature?"• e.g. ordering of actions/events
![Page 3: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/3.jpg)
Major Classification
1. aspect-base composition
2. aspect-aspect composition • especially at shared join points
– (but not exclusively)
3. Due to weaving process/specification
![Page 4: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/4.jpg)
1. Aspect-base interference
• Obliviousness is bliss?– obliviousness ≠ (programmer) ignorance
• it is about reducing (cyclic) coupling
• hence tool support can make a large practical difference– scalability is an issue, though
– Goal: developer responsible for creating a dependency must be accountable for the consequences: so one introducing an aspect should show it does not make new problems (“cause no harm”)
• kind of interferences:– behavioral conflicts (changing state or control flow)
– through structural changes
![Page 5: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/5.jpg)
Design information in pointcuts:treating the fragile pointcut problem
• Fragile pointcuts: – susceptible to ‘break when changes are made to the (base)
program. e.g. “call(void *.set*(Object))”
• Design intentions• or: semantic information (semantic properties)
– are implicitly present (encoded, hard-wired) in the sources of the program
– Semantic property is an abstract notion; e.g. behavior of a program element, its intended meaning.
• We would like to use design intentions as concrete ‘hooks’ to identify join points– hence not rely on the 'accidental' structure and naming
conventions of the program
![Page 6: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/6.jpg)
'Semantic Pointcuts'expressing design intentions in
pointcuts• Be able to refer to annotations in pointcuts
• Reduces the obliviousness: need annotations
• Example (in AspectJ 5):– Dedicated Pointcuts
pointcut foo(Customer c):
target(c) &&
hasAttribute(c, @PersistentRoot) && …
– Extending Type Patterns pointcut updateMethods():
within(@PersistentRoot *) && execution(@Update * *(..));
![Page 7: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/7.jpg)
2. Aspect-Aspect interference
• Indirectly through the base program– affecting the base program causes other
aspects to break• because their assumptions are violated
– can be due to:• state change• control flow changes• structural changes
![Page 8: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/8.jpg)
Aspect-Aspect interference Cont'd
• Interference at shared join points– depending on the correct composition
operators• Can have one affect the other, or both relate only
to base• dependencies among aspects• e.g. conditional execution
– semantic incompatibility• among aspects/advices—in every composition• only in specific base context
– i.e.aspect1/aspect2/baseX conflict
– affected by different orderings
![Page 9: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/9.jpg)
Aspect Interference
• How can this happen?– Separation of concerns:
• Pointcuts are developed separately
• Thus, we may not be aware of shared join points
– Aspects are usually written in Turing complete advices AspectJ, AspectC++, AspectWerkz, JBossAOP …
• This makes it hard to reason about the sanity of the composition
• E.g. “What is the intended behavior of not calling the proceed in one specific around advice?”
![Page 10: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/10.jpg)
Aspect Interference
• Semantic conflicts– Is the intended behavior preserved when composing two
aspects?– Hard to detect as you have to know the semantics of advice– “A semantic conflict, is a situation where the composition of
multiple advices influences the behavior of the advices or of the base system, causing the system requirements to be violated.”
![Page 11: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/11.jpg)
Example:• Encryption:
– Encrypt all outbound traffic on some protocol• call(* *.sendData(String)) && args(data) Encrypt advice
– Decrypt all inbound traffic on some protocol• call(* *.receiveData(String)) && args(data) Decrypt advice
• Logging:– Log all sent and received data on the protocol:
• call(* *.receiveData(String) || * *.sendData(String)) && args(data) Log advice
![Page 12: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/12.jpg)
Example:
Protocol class
voidsendData(String)
voidreceiveData(String)
Encrypt Log Decrypt
Protocol class
voidsendData(String)
voidreceiveData(String)
Encrypt Log
Log Encrypt
Decrypt Log
Log Decrypt
Superimposition
Composition
![Page 13: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/13.jpg)
Example:
• Both orderings are correct from a compiler point of view!
• However, depending on the requirements one order might be intended.– In a hostile domain we want to ensure that no
unencrypted data is read.
– In a protocol debugging domain we need to read the unencrypted data.
• Assume we want the latter option:– Log before Encrypt and Decrypt before Log
![Page 14: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/14.jpg)
Other examples
• “If the authorization aspect denies access for a state-changing operation, a second aspect may not be executed"– e.g. the authorization around advice does not do a proceed()
• "combining a real-time constraint aspect and a (possibly blocking) synchronization constraint"
• "two advices that both modify e.g. the arguments or return value of a call"– unless these are associative modifications
![Page 15: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/15.jpg)
Aspect ordering
• Ordering of advice at shared join points– execution 'must' be sequential
• an order is always chosen
– ordering may affect behavior• desired order is determined by requirements!
explicit, finegrained ordering specification is required• AspectJ: 'declare precedence'
• EAOP: advice composition ()
• Compose*: declarative, fine-grained composition specification– ordering
– conditional execution
– static constraints
![Page 16: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/16.jpg)
Semantic Interference Among Aspects: a formal view
• One aspect causes another to operate incorrectly even though:
• Aspect A satisfies its specification (PA, RA)• Aspect B satisfies its specification (PB, RB)• Recall P is assumption about base and R
is guarantee about augmented• We have a base system satisfying both PA
and PB
![Page 17: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/17.jpg)
Aspect Interference
A, B – aspects; S – underlying system
(S + A) +B WRONG
S + A OK OR
(S + B) +A WRONG
S + B OK OR
S + (A+B) WRONG
![Page 18: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/18.jpg)
Example: Internet Access to Bank Accounts
Underlying system:
Internet terminal
Server
send (login, password)
grant_access (info)
![Page 19: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/19.jpg)
Adding Password Encryption
Aspect A, responsible for encryption.
A’s pointcut: a password is sent from login screen
A’s assumption, PA: password-containing messages are sent only from login screen
A’s guarantee, RA: each time any password is sent, it is encrypted
![Page 20: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/20.jpg)
Example – contd.
Internet terminal
Server
send (login, password)
grant_access (info)
Aspect A: encrypt(password)
System S:
![Page 21: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/21.jpg)
Retrieve Forgotten Psw.
Aspect B e-mails the forgotten password if the security questions are answered
B’s pointcut: a password is forgotten
B’s assumption, PB: existence of an introductory operation, indicating that a password is forgotten
B’s guarantee, RB: each time a password is forgotten, it’s e-mailed to the user, provided security questions are answered
![Page 22: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/22.jpg)
Example – contd.(2)
Internet terminal
Server
send (login, encr(password))
grant_access (info)
Aspect B: e-mail retrieved psw.
S+A:
forgot psw.
![Page 23: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/23.jpg)
Example – contd.(3)
Internet terminal
Server
send (login, encr(password))
grant_access (info)
Unencrypted!!!
(S+A)+B:
forgot psw.
B
e-mail psw.
![Page 24: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/24.jpg)
Cause of the problem
• Common join-points? – No.
• Updating shared variables? – No.
• The semantics of A and B? – Yes!
1. B’s advice (e-mailing password) violates A’s guarantee (all passwords encrypted) B can not be woven after A.
2. B’s advice violates A’s assumption (passwords sent from Login Screen only) A can not be woven after B
![Page 25: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/25.jpg)
Semantic Interference – more formally
A – aspect, specified by (PA, RA)
B – aspect, specified by (PB, RB)
Definition: A does not interfere with B if for every system S,
(*)
(*) Notation: OKAB
• Need to prove: OKAB and OKBA
( | ) (( ) | )A B A BS P P S A B R R
![Page 26: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/26.jpg)
Proving Non-Interference
• Theorem (dividing the proof task):
To prove OKAB, it’s enough to show
[KPAB]
(A preserves the assumption of B)
[KRAB]
(B preserves the guarantee of A)
(( | ) ( | ))A B BS S P P S A P
(( | ) ( | ))A B AS S R P S B R
![Page 27: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/27.jpg)
Direct Proof Method: Based on Maven tool explained earlier
1. Build tableau T for PA PB
2. Use MAVEN to prove OKAB
- weave A into T, then weave B
- show RA RB on the result
3. Use MAVEN to prove OKBA
- weave B into T, then weave A
- show RA RB on the result
![Page 28: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/28.jpg)
Incremental Proof Method
1. Use MAVEN to prove KPAB
- build tableau TP for PA PB
- weave A into TP
- show PB on the result
2. Use MAVEN to prove KRBA
- build tableau TR for RA PB
- weave B into TR
- show RA on the result
3, 4 (for KPBA, KRBA) – symmetric ( OKBA)
OKAB
![Page 29: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/29.jpg)
Incremental method - advantages
1. Easier weaving
2. Quicker verification
3. Simplifications to 2 verification tasks (in not-so-rare special cases)
4. Advantage in failure analysis:
the verification step at which we obtained the counterexample helps show exactly which aspect caused interference and how (= which property was violated)
Cause: smaller models and TL formulas
![Page 30: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/30.jpg)
Bank system – verification failures
• KRAB fails B can not be woven after A, because it does not preserve the guarantee of A, RA (B sends e-mailed password unencoded)
• KPBA fails B can not be woven before A, because B violates the assumption of A, PA (the passwords are sent not only from the “login” screen)
![Page 31: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/31.jpg)
Ongoing research
• Analyze counterexamples to correct assumption/pointcut/advice/guarantee
• Investigate various weaving strategies including advice with joinpoints inside
• Show categories of aspects have special interference properties
• Detect interference problems for real-life collections of aspects
![Page 32: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/32.jpg)
A Common Aspect Proof Environment (CAPE)
• A framework with multiple tools for analyzing aspects and augmented systems
• Preliminary version is under development by Technion, INRIA , Twente Univ., Lancaster Univ.
• Includes syntactic analysis, model checking, type checking, for common internal representations
• Can treat different aspect languages
![Page 33: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/33.jpg)
AOSD-Europe
• 6th Programme EU Network of Excellence on Aspect-Oriented Software Development
• Includes those already listed, IBM, Siemens, and 5 other Universities
• Developing tools for aspects, including easy aspect verification
• See http://www.aosd-europe.net
![Page 34: Interferences: aspect-base and between aspects](https://reader036.vdocuments.us/reader036/viewer/2022062321/56813205550346895d9858a4/html5/thumbnails/34.jpg)
Conclusions
• Aspects provide opportunities, but need analysis– New kind of modularity (cross-cutting) and reuse– Potential for “on-demand” adaptation– Relevant for all stages of software development
• Formal Methods for software deserve consideration– Elegant applications of mathematics (logic)– Software crisis in reliability, expensive debugging– Tools are finally becoming practical
• Their combination has especially interesting questions and is potentially useful and practical