E. Katz, S. Katz FOAL'10 1

Semantic Aspect Interactions and Possibly Shared Join Points

Authors: Emilia Katz, Shmuel Katz {emika,katz}@cs.technion.ac.il

The Technion

E. Katz, S. Katz FOAL'10 2

Aspects at a Shared Join Point

……

shadow join point

Aspect A

Aspect B

Aspect C

• Which aspects will be applied?

• In what order? AspectJ operational

semantics…

E. Katz, S. Katz FOAL'10 3

… …

A B Cshadow j.p. is reached

last state of shadow j.p.

“Zoom in”: Pointcut Occurrence

pointcut occurrence of B

pointcut occurrence of A

arrival + actual join-point of A

arrival join-point of B

pointcut occurrence of C

arrival + actual join-point of C

actual join-point of B

E. Katz, S. Katz FOAL'10 4

Motivating Example

Aspects for systems with message sending (part of communication aspects library):

• Logging (4 variants)– Log messages before sending

• Encryption– Encrypt messages before sending

• Authorization– Is the user allowed to send this message to this server?

Shared join-point: the moment when a message is about to be sent

E. Katz, S. Katz FOAL'10 5

Logging Aspect Variants

• L1: log sent messages as they were originally attempted to be sent

• L2: log messages as they were actually sent to the server

• L3: log messages, but ignore content

• L4: log all the attempts to send a message, even the aborted ones

E. Katz, S. Katz FOAL'10 6

Aspect Application Order

• Question: When does the order of aspect application matter?

• “Matter” = lead to aspect interference

• One approach: different resulting states for different application orders

• Our claim: Not necessarily so!

• Two different cases:

E. Katz, S. Katz FOAL'10 7

Logging vs. Encryption (1)

… …

L2 Enc.

shadow j.p. is reached

last state of shadow j.p.

msg_to_send becomes true

…

msg_to_send becomes false;

msg_send becomes true

msg = <c, t>msg =

<enc(c), t>

msg = <enc(c), t>

==> Goal of L2 is not reached: message logged message sent

Added to log: <c, t>

Reminder:L2 logs messages as they were actually sent to the server

E. Katz, S. Katz FOAL'10 8

Logging vs. Encryption (2)

… …

L3 Enc.

…

msg = <c, t>

msg = <enc(c), t>Added to log: <c, t>

… …

Enc. L3

…

msg = <c, t>

msg = <enc(c), t> Added to log: <enc(c), t>

Different states? – Yes!

Goal of L3 violated? – No!

Goal of Enc violated? – No!

Reminder:L3 logs messages to measure network activity only

msg = <enc(c), t>

msg = <enc(c), t>

E. Katz, S. Katz FOAL'10 9

Aspect Influence Cases

New problems of shared join-points:

• Input variables changed before aspect execution (between arrival and actual join-point)

• Variables changed after aspect execution before they are used in the computation

• Pointcut invalidation before/after advice execution

E. Katz, S. Katz FOAL'10 10

The Setting: System Representation

• Advice, base system = state machine– Abstract representation as state-transition system of all

possible states– Obtained during the modeling stage, or built from code

(e.g., by tools like Bandera)• Pointcut = state predicate about the base system• Weaving (abstract version):

– Every join-point in the base is connected to the corresponding initial states of the advice (instead of its former next states)

– Every last state of the advice is connected to all the corresponding states in the base system model

E. Katz, S. Katz FOAL'10 11

The Setting: Aspect Specification

Specification of an aspect A is (PA, RA) A assumes:

PA holds in the base system:– what’s true at joinpoints– global properties of base system– properties of aspect parameters– what’s true for computations starting from all A’s resumption states

that were unreachable in the base system

A guarantees: RA is true in the woven system– new properties added by A– properties of base system maintained in woven system

What is a “correct” aspect?

LTL formulas

in any reasonable base system for A

in any woven system with A

possibly global!

… since model-checking is used in proof method

automatization …

E. Katz, S. Katz FOAL'10 12

Temporal Logic Specifications

φ φ …

…φ φ ψ …

φ φφG φ

…φF φ

φ W ψ

…φ φ ψ …φ U ψ

φ φ …φ φφ

OR

E. Katz, S. Katz FOAL'10 13

Specification Refinement Goals

• For each aspect, which cases of influence are harmful?

• What assumption would ensure that no harmful influence of other aspects at a shared join-point is possible?

E. Katz, S. Katz FOAL'10 14

Case 1: “Change Before”Influence type: input variables changed before aspect execution

… …

Enc. L1

…

<c, t>

<enc(c), t>

Added to log: <enc(c), t>

<enc(c), t>

arrival + actual join-point of E.

arrival join-point of L1

actual join-point of L1

==> Goal of L1 is not reached: message logged original message

Reminder:L1 logs messages as originally attempted to be sent

E. Katz, S. Katz FOAL'10 15

Question 1• Are there any input variables of A for which the advice of

A depends on their value at the arrival join-point?• Yes => list these variables• For each v in the list, add an assumption:

CB(v) = G[(at(ptc) ∧ v=V) → (v=V W (after_prev_asp(A) ∧ v=V))]

• In our example:– L1: Assumptions added: CB(c), CB(t)– L2: No– L3: No– L4: Assumptions added: CB(c), CB(t)

arrival join-point of A the only candidate for actual join-point of A

E. Katz, S. Katz FOAL'10 16

Case 2: “Change After”Influence type: variables changed before intended use

Reminder:L2 logs messages as they were actually sent

… …

L2 Enc.

…

==> Goal of L2 is not reached: message logged message sent

<c, t>

arrival + actual join-point of L2

arrival join-point of E.

actual join-point of E

<enc(c), t>

Added to log: < c, t>

<enc(c), t>

E. Katz, S. Katz FOAL'10 17

Question 2• Are there any state variables of the system, the value of

which should be preserved after A’s execution is finished?• Yes => list of “<variable, state of use>”• For each <v,use_v> in the list, add an assumption:

CA(v) = G[(asp_ret(A) ∧ v=V) → (v=V W (use_v ∧ v=V))]

• In our example:– For L1, L2, L3 use_v = msg_send– L1: Assumptions added: CA(msg_t )– L2: Assumptions added: CA(msg_c ) , CA(msg_t ) – L3: Assumptions added: CA(msg_t )– L4: No

return states of A

E. Katz, S. Katz FOAL'10 18

Case 3: “Invalidation Before”Influence type: aspect is not executed at all in its pointcut occurrence

… …

Aut. L4

…

arrival + actual join-point of A.

arrival join-point of L1

should’ve been actual join-point of L4

==> Goal of L4 is not reached: message is attempted to be sent, but is not logged

Reminder:L4 logs all the attempts to send a message

…

L4 is never executed in this pointcut

occurrence

message is not sent

<c, t>

E. Katz, S. Katz FOAL'10 19

Question 3

• Is it an error if the condition for A’s application is invalidated by previously executed aspects?

• Yes => add an assumption:

IB = G[at(ptc) → (ptc W (after_prev_asp(A) ∧ ptc))]

• In our example:– L1: No– L2: No– L3: No– L4: Assumption IB is added

arrival join-point of A actual join-point of A

E. Katz, S. Katz FOAL'10 20

Case 4: “Invalidation After”Influence type: aspect is executed in its pointcut occurrence, though

its pointcut is invalidated by aspects applied after it

… …

L2 Aut.

…

arrival + actual join-point of L2

arrival join-point of A.

actual join-point of A.

==> Goal of L2 is not reached: message is logged, but is not actually sent

…

message is not sent

Reminder:L2 logs messages as they were actually sent

<c, t>

Added to log: < c, t>

E. Katz, S. Katz FOAL'10 21

Question 4

• Q.4.1. Does the reason for a state to be A’s join-point lie in the future of the computation?

• Yes => Q.4.2. Is it an error if A’s advice is performed, but the presumably-following event does not follow?

• Yes => provide predicates: foll_event and (optionally) vals_after_asp and vals_at_foll_event; add an assumption:

IA = G[(asp_ret(A) ∧ vals_after_asp) → F (foll_event ∧ vals_at_foll_event)]

• In our example:– For L1, L2, L3, foll_event = msg_send– L1 and L3: vals_after_asp = vals_at_foll_event = “msg_t = T”– L2: vals_after_asp = vals_at_foll_event = “msg_c = C ∧ msg_t = T”– L4: No

return states of A

presumably-following event

Connection between the state after A’s execution and at the “following event”Connection between the state after A’s execution and at the “following event”

E. Katz, S. Katz FOAL'10 22

Full Verification Process• Verification goal: given a library of aspects

– Correctness check of each aspect individually– Interference freedom check of the library– Modular verification (independent of any concrete base

system; enables offline checks and reuse without proof)

• In presence of possibly shared join-points:– Perform user-guided specification refinement and

extend model before running existing verification tools

• Verification tools used:– MAVEN: modular aspect verification (GK’07, KK’09)– InterFree: interference detection (KK’08)

E. Katz, S. Katz FOAL'10 23

Interference summary for our example

secondfirst E A L1 L2 L3 L4

E --- CB --- --- CB

A --- --- --- --- IB

L1 --- IA

L2 CA IA

L3 --- IA

L4 --- ---

CB = Change BeforeCA = Change AfterIB = Invalidation BeforeIA = Invalidation After

E. Katz, S. Katz FOAL'10 24

SummaryOur contributions:• In-depth analysis of aspect semantics and mutual influence

at shared join-points Helps to distinguish between potential and actual interference at

shared join-points• Interactive semi-automatic procedure for specification

refinement Helps to define the desired aspect behavior more precisely Enables modular verification and interference detection among

aspects

Future work:• Implementation of the specification-refinement procedure• Implementation of aspect modeling for aspects with

possibly shared join-points, for verification purposes

Thank you!