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 –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

Major Classification 1.aspect-base composition 2.aspect-aspect composition especially at shared join points –(but not exclusively) 3.Due to weaving process/specification

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

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

'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) && && … –Extending Type Patterns pointcut updateMethods(): *) && * *(..));

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

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

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?”

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.”

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

Example: Protocol class void sendData(String) void receiveData(String) EncryptLogDecrypt Protocol class void sendData(String) void receiveData(String) EncryptLog Encrypt DecryptLog Decrypt Superimposition Composition

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

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

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

Semantic Interference Among Aspects: a formal view One aspect causes another to operate incorrectly even though: Aspect A satisfies its specification (P A, R A ) Aspect B satisfies its specification (P B, R B ) Recall P is assumption about base and R is guarantee about augmented We have a base system satisfying both P A and P B

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

Example: Internet Access to Bank Accounts Underlying system: Internet terminal Server send (login, password) grant_access (info)

Adding Password Encryption Aspect A, responsible for encryption. A’s pointcut: a password is sent from login screen A’s assumption, P A : password- containing messages are sent only from login screen A’s guarantee, R A : each time any password is sent, it is encrypted

Example – contd. Internet terminal Server send (login, password) grant_access (info) Aspect A: encrypt(password) System S:

Retrieve Forgotten Psw. Aspect B s the forgotten password if the security questions are answered B’s pointcut: a password is forgotten B’s assumption, P B : existence of an introductory operation, indicating that a password is forgotten B’s guarantee, R B : each time a password is forgotten, it’s ed to the user, provided security questions are answered

Example – contd.(2) Internet terminal Server send (login, encr(password)) grant_access (info) Aspect B: retrieved psw. S+A: forgot psw.

Example – contd.(3) Internet terminal Server send (login, encr(password)) grant_access (info) Unencrypted!!! (S+A)+B: forgot psw. B psw.

Cause of the problem Common join-points? – No. Updating shared variables? – No. The semantics of A and B? – Yes! 1. B’s advice ( ing 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

Semantic Interference – more formally A – aspect, specified by (P A, R A ) B – aspect, specified by (P B, R B ) Definition: A does not interfere with B if for every system S, (*) (*) Notation: OK AB Need to prove: OK AB and OK BA

Proving Non-Interference Theorem (dividing the proof task): To prove OK AB, it’s enough to show [KP AB ] (A preserves the assumption of B) [KR AB ] (B preserves the guarantee of A)

Direct Proof Method: Based on Maven tool explained earlier 1. Build tableau T for P A  P B 2. Use MAVEN to prove OK AB - weave A into T, then weave B - show R A  R B on the result 3. Use MAVEN to prove OK BA - weave B into T, then weave A - show R A  R B on the result

Incremental Proof Method 1.Use MAVEN to prove KP AB - build tableau T P for P A  P B - weave A into T P - show P B on the result 2. Use MAVEN to prove KR BA - build tableau T R for R A  P B - weave B into T R - show R A on the result 3, 4 (for KP BA, KR BA ) – symmetric (  OK BA )  OK AB

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

Bank system – verification failures KR AB fails  B can not be woven after A, because it does not preserve the guarantee of A, R A (B sends ed password unencoded) KP BA fails  B can not be woven before A, because B violates the assumption of A, P A (the passwords are sent not only from the “login” screen)

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

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

AOSD-Europe 6 th 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

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