Categories of Aspects Shmuel Katz Computer Science Department The Technion Haifa, Israel

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

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

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)

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: 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 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:  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 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 Can save complex proof techniques, not yet developed for aspects Will sometimes still need regular proofs