Transcript [Slides (PPT)]

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
1
Aspects at a Shared Join Point
Aspect
A
Aspect
B
Aspect
C
…
…
shadow
join point
• Which aspects will be applied?
• In what order?
AspectJ
operational
semantics…
E. Katz, S. Katz
FOAL'10
2
“Zoom in”: Pointcut Occurrence
shadow j.p.
is reached
A
B
C
…
…
arrival + actual
join-point of A
arrival joinpoint of B
last state of
shadow j.p.
pointcut
occurrence of C
actual joinpoint of B
pointcut
occurrence of A
pointcut
occurrence of B
arrival +
actual joinpoint of C
E. Katz, S. Katz
FOAL'10
3
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
4
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
5
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
6
Logging vs. Encryption (1)
last state of
shadow j.p.
shadow j.p.
is reached
L2
Enc.
…
…
msg_to_send
becomes true
msg = <c, t>
Added to log:
<c, t>
msg =
<enc(c), t>
Reminder:
L2 logs messages as
they were actually
sent to the server
…
msg_to_send
becomes false;
msg_send
becomes true
msg =
<enc(c), t>
==> Goal of L2 is not reached:
message logged  message sent
E. Katz, S. Katz
FOAL'10
7
Logging vs. Encryption (2)
Added to log: <c, t>
L3
Enc.
…
msg = <enc(c), t>
…
msg = <c, t>
Reminder:
L3 logs messages
to measure network
activity only
…
msg =
<enc(c), t>
Enc.
Different states?
– Yes!
L3
Goal of L3 violated?
– No!
…
…
msg = <enc(c), t>
…
Goal of Enc violated?
– No!
Added to log: <enc(c), t>
E. Katz, S. Katz
FOAL'10
8
Aspect Influence Cases
New problems of shared join-points:
• Input variables changed before aspect
execution (between arrival and actual joinpoint)
• Variables changed after aspect execution
before they are used in the computation
• Pointcut invalidation before/after advice
execution
E. Katz, S. Katz
FOAL'10
9
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
10
The Setting: Aspect Specification
What is a “correct” aspect?
… since model-checking is
used in proof method
automatization …
LTL formulas
Specification of an aspect A is (PA, RA)
A assumes:
PA holds in the base system:
–
–
–
–
in any reasonable
base system for A
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
in any woven
system with A
possibly global!
E. Katz, S. Katz
FOAL'10
11
Temporal Logic Specifications
Gφ
φ
φ
φ
Fφ
φ
…
…
φ
φUψ
φWψ
φ
φ
…
φ
ψ
…
φ
…
φ
ψ
…
φ
φ
φ
φ
OR
E. Katz, S. Katz
φ
FOAL'10
…
12
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
13
Case 1: “Change Before”
Influence type: input variables changed before aspect execution
<c, t>
Enc.
<enc(c), t>
L1
…
…
arrival + actual
join-point of E.
arrival joinpoint of L1
…
Added to log: <enc(c), t>
actual joinpoint of L1
<enc(c), t>
Reminder:
L1 logs messages as
originally attempted
to be sent
==> Goal of L1 is not reached:
message logged  original message
E. Katz, S. Katz
FOAL'10
14
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))]
arrival join-point of A
• In our example:
–
–
–
–
the only candidate for
actual join-point of A
L1: Assumptions added: CB(c), CB(t)
L2: No
L3: No
L4: Assumptions added: CB(c), CB(t)
E. Katz, S. Katz
FOAL'10
15
Case 2: “Change After”
Influence type: variables changed before intended use
L2
<c, t>
Enc.
…
<enc(c), t>
…
…
arrival + actual
join-point of L2
actual joinpoint of E
arrival joinpoint of E.
<enc(c), t>
Added to log: < c, t>
Reminder:
L2 logs messages as
they were actually sent
==> Goal of L2 is not reached:
message logged  message sent
E. Katz, S. Katz
FOAL'10
16
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))]
return states of A
• 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
E. Katz, S. Katz
FOAL'10
17
Case 3: “Invalidation Before”
Influence type: aspect is not executed at all in its pointcut occurrence
<c, t>
Aut.
…
L4
message is
not sent
…
…
…
arrival + actual
join-point of A.
arrival joinpoint of L1
should’ve been
actual joinpoint of L4
L4 is never executed
in this pointcut
occurrence
Reminder:
L4 logs all the attempts
to send a message
==> Goal of L4 is not reached:
message is attempted to be sent, but
is not logged
E. Katz, S. Katz
FOAL'10
18
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))]
arrival join-point of A
actual join-point of A
• In our example:
– L1: No
– L2: No
– L3: No
– L4: Assumption IB is added
E. Katz, S. Katz
FOAL'10
19
Case 4: “Invalidation After”
Influence type: aspect is executed in its pointcut occurrence, though
its pointcut is invalidated by aspects applied after it
L2
<c, t>
…
Aut.
message is
not sent
…
…
…
arrival + actual
join-point of L2
arrival joinpoint of A.
actual joinpoint of A.
Added to log:
< c, t>
Reminder:
L2 logs messages as
they were actually sent
==> Goal of L2 is not reached: message
is logged, but is not actually sent
E. Katz, S. Katz
FOAL'10
20
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 presumablyfollowing event does not follow?
• Yes => provide predicates: foll_event and (optionally) vals_after_asp and
vals_at_foll_event; add an assumption:
presumably-following event
IA = G[(asp_ret(A) ∧ vals_after_asp) → F (foll_event ∧ vals_at_foll_event)]
return states of A
Connection between the state after A’s
execution and at the “following 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
E. Katz, S. Katz
FOAL'10
21
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
22
Interference summary for our example
second
E
first
E
A
L1
L2
L3
L4
---
CB
---
---
CB
---
---
---
IB
A
---
L1
---
IA
L2
CA
IA
L3
---
IA
L4
---
---
CB = Change Before
CA = Change After
IB = Invalidation Before
IA = Invalidation After
E. Katz, S. Katz
FOAL'10
23
Summary
Our 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
E. Katz, S. Katz
FOAL'10
24
Thank you!