Categories of Aspects

Shmuel KatzComputer Science Department

The TechnionHaifa, Israel

Aspects (and esp. AspectJ) Aspects: modular units that crosscut classes Aspects are defined by aspect declarations

and may include pointcut declarations: where to add/replace advice declarations: what to add or do instead Can introduce new methods, variables, code…

Weave (=bind) aspect to different systems (but not entirely separated yet…)

Categories of Aspects: the idea

Identify standard types of aspects using dataflow, type checking, or other code analysis

Each type should either automatically maintain classes of properties of the underlying system, or be easier to analyze for new properties.

Most other work so far: what are the types of classes and how to identify them

Here: Effect on temporal logic properties

Outline Identify categories of aspects, semantically Identify types of properties and how to

describe them in temporal logic Show how to check for category of aspect by

syntactic analysis (data-flow) Prove that for aspects of category A,

properties of type B Are automatically preserved if originally true Can be established by only considering the

aspect code Can be checked separately for the original and

the aspect

Spectative aspects

Only gather information about original system, in variables local to the aspect

Logging, performance evaluation, debugging

Can be checked on the code level of the advice: all assignments are to local variables (also parameters given values)

Regulative aspects Either like spectative, or only affect control

of basic, by shutting possibilities Can restrict the conditions for activating a

method call of the original system Adding password authorization, restricting

choices to ensure fairness, aborting Prune edges from the stategraph of the

original system, plus add spectative parts

Invasive aspects

Allow changing variables/state of the original system

Treating discount policy, overflow, security with encode/decode

Can have restricted versions, e.g., to treat invariant extension

More categories

Observer (Clifton-Leavens): methodology for development, points out problems of aliasing in effective identification

Classification (Rinard-Salcianu-Bugrara): implemented tool for AspectJ, using compilation techniques…finer distinctions, but proof implications are not clear.

Temporal Logic Lite

A logic over sequences of states (in a tree?) Gp: for every state later in the sequence, p Fp: there is a later state with p Xp: in the next state, p A(Gp): For every possible sequence, Gp E(Gp): There is a sequence with Gp Sequence= a possible execution of the

system

Types of Properties Safety: hold in every state, may relate to the

history leading to the state Invariant: relates to each state (no history) Class invariant: true before and after every

method call of a class (and initially) Temporal logic: AGp, (p has no future modalities)

Liveness: hold eventually for every execution Termination, eventual response to a request In temporal logic: AFp, or complex combinations

Types of Properties (cont.) Next-state properties: Connect a state and

the immediately following (or previous) one Written as Xp (usually q => Xp)

Existence properties: There is a possible computation of the system Written as EP (where P contains other temporal

assertions, e.g., EGFp) From each location, there is a path that reaches

an interrupt state Visibility properties: what is known outside

the module under consideration Special kind of safety properties, relates to all

methods, fields (including new ones from the aspect)

Terminology

Underlying (system): the system before an aspect has been woven (also Original or Basic)

Aspect: pointcut plus advice Augmented (system): the result

after weaving in an aspect

The Semantics of a system

A state graph expands as new objects are added Contracts as objects are removed

Temporal assertions are for all paths through each graph during execution

Consider the changes from Original to Augmented graphs—to justify claims

Statemachine of Aspect System

a a

a a

b b

b b

b b

b b

b

ret(f)

call(h)

ret(h)

ret(g)

a b

a b

call(f)

call(g)

Advice A:

call(h)

ret(h)

source

sink

ΦΦ = AG(A[aUb]) = AG(A[aUb])

P: call(g);true*P: call(g);true*Before1 Before2

After2 After1

propositions

Propositions

sub-formulas

b

bA[aUb],AG(A[aUb])

in

out

Spectative aspects--identification

C = set of variables/parameters of aspect code bound to those in underlying

No variable of C is assigned a value by the aspect code

Each advice is straightline code (or is guaranteed to terminate)

underlying resumes where interrupted (before/after, no exceptions thrown, or around with proceed)

Other analysis

Originally for optimization, now also for identifying categories in simplified AspectJ : (Sereni - de Moor)

Interference analysis, emphasizing the implications of inheritance and multiple instances (Storzer and Krinke)

Program slicing adapted to aspect languages

Spectative aspects--properties

All safety and liveness that are not next-state, and only involve underlying variables / methods—are maintained in augmented

No new properties of only underlying are added

For new properties, separate concerns: can check aspect variables in aspect, underlying variables in underlying

Note: visibility can be violated, due to new methods or variables of the aspect

Regulative aspects--identification

C, as before (all variables in aspect bound to variables of underlying)

Variables of C are not assigned (but…) Advice can throw exceptions that terminate

execution, or prevent external calls to methods of underlying (or, as before)

Strengthens conditions checked, so restricts possible transitions (erase edges in transition graph), but not skipping (which would add an edge)

Regulative-- properties Safety properties not next-state, involving

only variables/methods of underlying are maintained in augmented

Above is justified by considering the regulative augmented as a pruned graph of the underlying

Liveness properties may not be maintained May have new safety properties, even of just

the underlying variables If only external calls are restricted, existential

may be violated in augmented, but otherwise maintains safety and liveness like spectative

Invasive: how bad is it? Reconnection problem: changes can

create states not in the original, and continuing the underlying code can create entire new subgraphs…

Weak invasive: always reconnects to a state that existed in the original—so continuations are as before (Informally: fixes problems that might not arise)

Invariants for weak invasive

If the aspect is weak invasive, invariant of original can be extended to augmented by only checking the aspect statemachine

Example: an aspect that `resets’ the state to a fixed system state (in the original) under certain conditions

Allows model checking only the aspect, assuming the invariant both before and after

Strongly Invasive: extending invariants

For invariants of the underlying, that we want to also hold for augmented

Can we just check the advice? Yes, when the invariant is inductive: just itself

is needed to justify each step {I} s {I} has been shown for each step s of the

underlying—no matter what the state Then just show {I} t {I} for each step t of the

advice—without reproving for the underlying Otherwise, may have to recheck underlying too

Extending inductive invariants: an example

x > y > 0 is an inductive invariant of an underlying system

Add an aspect with changes like: <complex-pointcut> double(x,y)

Check {x>y>0} double(x,y) {x>y>0} The invariant will hold for the

augmented system, with no further checks and without analyzing <complex-pointcut>

Can be further refined….

Additional questions

Interactions among types of aspects Finer distinctions among Invasive Additional classes of properties Model checking for aspects Tools to be developed as part of a

Common Aspect Proof Environment (CAPE) within AOSD-Europe

Summary

Identifying categories of aspects can often be done by static code analysis

Theorems on types of properties preserved, or new ones established are done only once

Provide theoretical basis for static analysis Can save complex proof techniques, not yet

developed for aspects Will sometimes still need regular proofs