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) &&

hasAttribute(c, @PersistentRoot) && …

– Extending Type Patterns pointcut updateMethods():

within(@PersistentRoot *) && execution(@Update * *(..));

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

voidsendData(String)

voidreceiveData(String)

Encrypt Log Decrypt

Protocol class

voidsendData(String)

voidreceiveData(String)

Encrypt Log

Log Encrypt

Decrypt Log

Log 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 (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

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, PA: password-containing messages are sent only from login screen

A’s guarantee, RA: 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 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

Example – contd.(2)

Internet terminal

Server

send (login, encr(password))

grant_access (info)

Aspect B: e-mail 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

e-mail psw.

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

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

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

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

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

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

• 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)

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

• 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

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