Mo dul ar V eriÞcat io n of Asp ects … · Mo dul ar V eriÞcat io n of Asp ects Max Gol dma n Technion - Computer Science Department - M.Sc. Thesis MSC-2006-23 - 2006

Modular Verification of Aspects

Max Goldman

Technion - Computer Science Department - M.Sc. Thesis MSC-2006-23 - 2006


Modular Verification of Aspects

Research Thesis

Submitted in partial fulfillment of the requirementsfor the degree of Master of Science in Computer Science

Max Goldman

Submitted to the Senate of theTechnion — Israel Institute of Technology

Tamuz 5766 Haifa June 2006


This research was done under the supervision of Professor Shmuel Katz in theDepartment of Computer Science.

The generous financial support of the Technion and the AOSD-Europe Euro-pean Network of Excellence on Aspect-Oriented Software Development is gratefullyacknowledged.


Contents

Abstract 1

1 Introduction 21.1 Aspect-Oriented Programming . . . . . . . . . . . . . . . . . . . . . 21.2 Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Modular Aspectual Verification . . . . . . . . . . . . . . . . . . . . . 41.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background & Definitions 72.1 LTL Tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Pointcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Weaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.1 Constructing a Pointcut-Ready Machine . . . . . . . . . . . . 112.5.2 Constructing an Augmented Machine . . . . . . . . . . . . . 12

2.6 Weakly Invasive Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Verification Algorithm 143.1 Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Implementation 234.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 maven Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Examples in Action 295.1 Revisiting 3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Discount at the Checkout Counter . . . . . . . . . . . . . . . . . . . 305.3 Error Alert Messages: A Counterexample Analysis Case Study . . . 33

6 Related Work 38


7 Conclusions 40

Bibliography 42

A FSMA Aspect Specifications 45

B Messages Example FSMA Source 47


List of Figures

2.1 Constructing a pointcut-ready machine M! for the given M and LTLpast formula pointcut descriptor ! = a ! Y b ! Y Y b . . . . . . . . . 11

3.1 Using existing fair paths (small states) to guarantee existence of afair path (shaded) containing edge (s!i"1, s

!i) . . . . . . . . . . . . . . 16

3.2 The reachable portion of tableau T" for " = A G ((¬a ! b) " F a) . 193.3 A simple aspect machine A . . . . . . . . . . . . . . . . . . . . . . . 193.4 Augmented tableau !T", satisfying # = A G ((a ! b) " X F a) . . . . 203.5 One particular base machine M |= " . . . . . . . . . . . . . . . . . . 223.6 Augmenting M with A according to ! gives result !M |= # . . . . . . 22

4.1 Flow chart for a ‘model-based’ verifier implementation . . . . . . . . 244.2 Flow chart for a ‘code-based’ verifier implementation . . . . . . . . . 244.3 Flow chart for the maven prototype implementation . . . . . . . . . 26

5.1 FSMA source for the display example . . . . . . . . . . . . . . . . . 305.2 FSMA source for the discount example . . . . . . . . . . . . . . . . . 325.3 maven verification results for the discount example . . . . . . . . . . 335.4 Counterexample for the error alert message aspect, Version 1 . . . . 355.5 Counterexample for the error alert message aspect, Version 2 . . . . 36


Abstract

Aspects are separate code modules that can capture crosscutting concerns moree!ectively than existing object-oriented techniques. An aspect is combined, or “wo-ven,” with a base program at joinpoints, locations where the aspect code will runin the resulting augmented system.

We define a novel formal approach to verify that an aspect will provide desiredproperties to the augmented system whenever it is woven with a base program thatsatisfies the assumptions of the aspect. This verification uses state machine modelsof aspects, constructing a single state machine based on the linear temporal logic(LTL) description of the assumptions, a description of the joinpoints, and the statemachine of the aspect code. A theorem is shown that if this constructed machinesatisfies the desired properties, so will an augmented state machine built from anybase machine satisfying the assumptions. This theorem holds under a somewhatrestricted form of joinpoint description, and for aspects whose code always returnsto states reachable in the original base machine.

This technique is the first example of once-and-for-all verification of aspects inwhich the verification examines only the aspect in isolation, rather than an aug-mented system or the aspect together with a particular base program. The use-fulness of the technique is demonstrated with maven, a prototype implementationsu"cient to verify a number of example aspects. Language-based descriptions ofaspects, as in AspectJ, can be converted to state machine versions using existingtools, thus providing generic modular verification of code-level aspects.

1


Chapter 1

Introduction

This work is at the intersection of two fields still under heavy research, and whosepractical applications have reached only a fraction of their potential: aspect-orientedprogramming, and formal verification of programs. The techniques and tools pre-sented in this thesis were developed because the use of formal methods in the contextof aspect-oriented design can be particularly e!ective, and at the same time, aspect-oriented programming presents a unique and interesting challenge to our currentformal verification capabilities. The emphasis is on re-use of existing results in anentirely new context, attaining unforeseen mileage from proven ideas.

This introductory chapter presents background on both aspect-oriented program-ming and formal verification, then goes on to justify our particular approach to theproblem and outline the results we have achieved. In subsequent chapters, neces-sary terms and constructs are defined, and our algorithm is presented and provensound. In Chapter 4 we turn to implementation, describing the working prototypethat has been written and used to verify a variety of examples, some of which aredetailed in Chapter 5. Chapter 6 summarizes other works related to this one, andin Chapter 7 we conclude. The appendices contain the input format specificationfor our prototype aspect verifier, as well as the complete source code of an extendedexample.

1.1 Aspect-Oriented Programming

The aspect-oriented approach to software development is one in which concernsthat cut across many parts of the system are encapsulated in separate modulescalled aspects. The approach was first presented in the AspectJ [15] extension ofJava, and has been generalized to a variety of languages and aspect-oriented softwaredevelopment techniques (see, for example, [8]). When a concern such as security orlogging is encapsulated in an aspect, this aspect contains both the code associated

2


with the concern, called advice, and a description of when this advice should run,called a pointcut descriptor. The pointcut descriptor identifies those points in theexecution of a program at which the advice should be invoked, called joinpoints.The combination of some base program with an aspect (or in general, a collection ofaspects), is termed an augmented program.

Aspects are of particular interest as a software construct because the point-cuts that govern the execution of their advice are evaluated dynamically. When apointcut identifies joinpoints, these joinpoints are not static locations in the code;rather, in the most popular and expressive joinpoint models used by aspect-orientedprogramming languages, joinpoints available to be selected by a pointcut are well-defined points during the execution of a program. Depending on the runtime contextof a particular point, such as what methods are on the program’s stack, or whatvalues are currently in certain data fields, the same static code location might matcha pointcut at one time, but fail to match it at another. In order to give the pro-grammer access to these dynamic data, a pointcut may expose certain values to theadvice.

The usual language of aspect-oriented programming is to talk about three kindsof advice: before, after, and around. These types express when, in relation to theexecution of the code under a joinpoint, the advice is executed. To take an exam-ple, suppose that we write a pointcut to match calls to a particular method of aclass in our base system, and we write a certain piece of advice to run with thispointcut. If our advice is of the before variety, it executes before the base systemmethod; after advice runs after the method returns; and around advice is allowed tocontrol whether the method runs at all, in essence surrounding the joinpoint. Givenappropriate semantics and models, the verification technique in this work can be ap-plied in a system where such distinctions are made. Here our focus is on the formalmethods required to verify aspects, and the connection to high-level programminglanguage aspects is dealt with only briefly in later chapters.

1.2 Formal Verification

In this work we are concerned with generic formal verification of aspects relative toa specification. The specification of an aspect consists of assumptions about anybase program to which the aspect can reasonably be woven, and desired propertiesintended to hold for the augmented program (this terminology is applied to aspectsin [21]). We view both base programs and aspect code as nondeterministic finitestate machines, in which particular computations are realized as infinite sequencesof states within the machine. For both assumptions and desired properties to beverified we consider formulas written in linear temporal logic (LTL). An LTL formulaconsists of a path formula using temporal quantifiers and logical combinations of

3


atomic propositions, prefixed by a single (usually implicit) universal path quantifier.The atomic propositions in a formula refer to the labels of states in a finite statemachine; temporal quantifiers specify when these assertions about states must betrue. The universal path quantifier requires that, in order for some initial state tosatisfy an LTL assertion, all infinite paths from that state must satisfy the pathformula. In general, a state machine also includes a fairness constraint, and onlyfair paths are considered.

1.3 Modular Aspectual Verification

It is clear that given a base program, a collection of aspects with their pointcutdescriptors and advice, and a system for weaving together these components to pro-duce a stand-alone augmented program, we can verify properties of this augmentedsystem using the usual model checking techniques. Such weaving involves addingedges from joinpoint states of the base program to the initial states of the advice,and from the states at the end of an advice segment to states back in the baseprogram.

It would be preferable, however, if we could employ a modular technique in whichthe aspect can be considered separately from the base program. This would allowus to:

• obtain verification results that hold for a particular aspect with any base pro-gram from some class of programs, rather than for only one base program inparticular;

• use the results to reason about the application of aspects to base programs withmultiple evolving state machines describing changing configurations duringexecution, or to other base systems not amenable to model checking; and

• avoid model checking augmented systems, which may be significantly largerthan either their base systems or aspects, and whose unknown behavior mayresist abstraction.

The second point above relates to general object-oriented programs that createnew instances of classes (objects) with associated state machine components. Often,the assumption of an aspect about the key properties of those base state machines towhich it may be woven can indeed be shown to hold for every possible machine thatcorresponds to an object configuration of a program. For example, it may involve aso-called class invariant, provable by reasoning directly on class declarations, as in[1]. This point and more details on the connections between code-based aspects (asin AspectJ) and the state machine versions seen here are discussed in Chapter 6.

4


This problem of creating a single generic model that can represent any possibleaugmented program for an aspect woven over some class of base programs is espe-cially di"cult because of the aspect-oriented notion of obliviousness : base programsare generally unaware of aspects advising them, and have no control over when orhow they are advised. There are no explicit markers for the transfer of control frombase to advice code, nor are there guarantees about if or where advice will returncontrol to the base program.

1.4 Results

In this thesis we show how to verify once-and-for-all that for any base state machinesatisfying the assumptions of an aspect, and for a weaving that adds the aspectadvice as indicated in the joinpoint description, the resulting augmented state ma-chine is guaranteed to satisfy the desired properties given in the specification. Asingle generic state machine is constructed from the tableau of the assumption,the pointcut descriptor, and the advice state machine, and verified for the desiredproperties. Then, when a particular base program is to be woven with the aspect,it is su"cient to establish that the base state machine satisfies the assumptions.Thus the entire augmented program never has to be model checked, achieving truemodularity and genericity in the proof. This approach is especially appropriate foraspects intended to be reused over many base programs, e.g., those in libraries ormiddleware components. It was first presented in [9].

LTL model checking is based on creating a tableau state machine automatonthat accepts exactly those computations that satisfy the property to be verified.Usually, the negation of this machine is then composed as a cross-product with themodel to be checked. A counter-example is produced when the composed systemcontains some infinite path, and the property is satisfied for the model when thecross-product has no such paths. Here we use the tableau of the assumption in aunique way, as the basis of the generic model to be checked for the desired property.It represents any base machine satisfying the assumption, because the executionsequences of these base programs can be abstracted by sequences in the tableau.

For the soundness theorem presented in Section 3.1, the aspects treated are as-sumed to be weakly invasive, as defined in [13]. This means that when advice hascompleted executing, the system continues from a state that was already reachablein the original base program (perhaps for di!erent inputs or actions of the environ-ment). Many aspects fall into this category, including spectative aspects that nevermodify the state of the base system (logging is a good example), and regulative as-pects that only restrict the reachable state space (for example, aspects implementingsecurity checks). Also weakly invasive would be an aspect to enforce transactionalrequirements, which might roll back a series of changes so that the system returns

5


to the state it was in before they were made. Even a ‘discount policy’ aspect thatreduces the price on certain items in a retail system is weakly invasive, since theoriginal price given as input could have been the discounted one.

Additionally, we assume that any executions of an augmented program thatinfinitely often include states resulting from aspect advice will be fair (and thus mustbe considered for correctness purposes). The version here does not treat multipleaspects or joinpoints influenced by the introduction of advice, although the approachcan be expanded to treat such cases as well.

6


Chapter 2

Background & Definitions

2.1 LTL Tableaux

Intuitively, the tableau of an LTL formula f is a state machine whose fair infinitepaths are exactly all those paths which satisfy the formula f . This intuition will berealized formally in Theorem 1 below.

In the context of performing model checking to verify satisfaction of an LTLproperty, a tableau is constructed for the negation of that property, in order tocapture all possible computations that would cause a machine not to satisfy theformula in question. It is important to stress that here we use the tableau for theoriginal non-negated formula. Nevertheless, because of the use of tableaux by LTLmodel checking tools, modules to perform the construction of a formula’s tableauare available (the tableau construction of our prototype implementation uses onesuch module).

We define Tf , the tableau for LTL path formula f , as given in [4], in the chapteron “Symbolic LTL Model Checking” (6.7). In this construction, the original for-mula is decomposed into the set of elementary formulas it contains, where all othertemporal operators, such as from now on (G) and eventually (F), are expressed interms of next (X) and strong until (U). Each state in the tableau is a subset of theseelementary formulas, and the path relation between these states is defined by meansof a function sat(g), which captures the set of states in which subformula g of f issatisfied.

We denote Tf = (ST , ST0 , RT , LT , FT ), where ST is the set of states; ST

0 is the setof initial states, RT is the transition relation, LT is the labeling function, and FT isthe set of fair state sets. For ease of discussion, we clarify the definition as follows:

Define ST0 , where for $ = Af , we have Tf |= $:

ST0 = sat(f)

7


Define FT , where any fair path in Tf must visit each set in FT infinitely manytimes:

FT = {sat((¬(g U h)) # h) | g U h is a subformula of f}This fairness constraint guarantees that obligations of the form g U h are fulfilled,

either by visiting a state in sat(h) infinitely often, or by infinitely often visiting astate outside of sat(g U h), which can only be reached by going via sat(h) accordingto the construction of the path relation (not detailed here).

Two notable properties of Tf will be used below. First, if APf is the set of atomicpropositions in f , then LT : S " P(APf ) — that is, the labels of the states in thetableau will include sets of the atomic propositions appearing in f . A state in anymachine is given a particular label if and only if that atomic proposition is true inthat state.

The second interesting feature is a main theorem from the discussion in [4]:

Definition 1. For path %, let label(%) be the sequence of labels (subsets of AP )of the states of %. For such a sequence l = l0, l1, . . . and set Q, let l|Q = m0, m1, . . .where for each i $ 0, mi = li %Q.

Theorem 1. (from [4], 6.7, Theorems 4 & 5) Given Tf , for any Kripke structureM , for all fair paths %! in M , if M, %! |= f then there exists fair path % in Tf suchthat % starts in ST

0 and label(%!)|APf= label(%).

That is, for any possible computation of M satisfying formula f , there is a pathin the tableau of f which matches the labels within APf along the states of thatcomputation.

In the algorithm of Chapter 3, we restrict the tableau to its reachable component.Such restriction does not a!ect the result of this theorem, since all reachable pathsare preserved, but is necessary in order to achieve useful results. This follows fromthe observation that the tableau for the negation of a formula has precisely the samestates and transition relation, but the complementary set of initial states. Thus, anyunreachable portion of the tableau is liable to contain exactly those behaviors whichviolate the formula of interest.

Finally, for formula $ = Af , define T# = Tf as a convenient notation (a tableaucan only be constructed for a path formula).

2.2 Aspects

An aspect machine A = (SA, SA0 , SA

ret , RA, LA) over atomic propositions AP is de-fined as usual for a machine with no fairness constraint, with the following addition:

Definition 2. SAret is the set of return states of A, where SA

ret & SA and for anystate s ' SA

ret , s has no outgoing edges.

8


2.3 Pointcuts

Recall that a pointcut identifies the states at which an aspect’s advice should beactivated, and can include conditions on the present state and execution history.We do not give a prescriptive definition for pointcut descriptors here; in practicepointcut descriptions might take a number of forms. However, we require thatdescriptors operate in the following manner:

Definition 3. Given a pointcut descriptor ! over atomic propositions AP and afinite sequence l of labels (subsets of AP ), we can ask whether or not the end of l ismatched by !.

We define l |( ! to mean that finite label sequence l is matched by pointcutdescriptor ! in this way.

A reasonable choice for describing pointcuts might be LTL path formulas contain-ing only past temporal operators. For example, the descriptor !1 = a ! Y b ! Y Y bwould match sequences ending with a state where a is true, preceded by b, precededby another b (operator Y is the past analogue of X). Other languages could beimagined, for example regular expressions, where !2 = true# · b · b · a might be equiv-alent to !1. The use of regular expressions over automata is popular in industrialspecification languages and has been examined in formal combination with LTL forexample in [3].

While it may appear at first that the ability to examine past state is necessary foran expressive pointcut language, and there are certainly aspect-oriented languageswhere pointcut descriptors clearly have this expressive power, the expressivenessof pointcuts which examine only the current state (in the case of past LTL, theformula contains no temporal quantifiers) should not be underestimated. Much ofthe AspectJ pointcut language identifies joinpoints based on the contents of thestack. If stack contents are considered as part of the state, a valid technique formodeling call-and-return systems, any arbitrary quantification over the state of thestack is now a pointcut that examines only the current state.

2.4 Specifications

In addition to its advice, in the form of state machine A, and pointcut, describedby !, an aspect is considered to have two pieces of formal specification:

• Formula " expresses the assumptions made by the aspect about any basemachine to which it will be woven. This " is thus a requirement to be met byany such machine.

9


• Formula # expresses the desired result to be satisfied by any augmented ma-chine built by weaving this aspect with a conforming base machine. In otherwords, # is the guarantee of the aspect.

2.5 Weaving

Weaving is the process of combining a base machine with some aspect according toa particular pointcut descriptor; the result is an augmented machine that includesthe advice of the aspect.

The weaving algorithm has the following inputs:

• aspect machine A = (SA, SA0 , SA

ret , RA, LA) over AP ,

• pointcut ! over AP , and

• base machine B = (SB, SB0 , RB, LB, FB) over APB ) AP .

And it produces as output:

• augmented machine "B = (S"B, S "B0 , R"B, L"B, F"B).

Set AP can be thought of as the ‘visible’ labels of B with which the aspect isconcerned; labels local to the aspect are not included.

The weaving is performed in two steps. First we construct from the base machineB a new state machine B! which is pointcut-ready for !, wherein each state eitherdefinitely is or is not matched by !. Then we use B! and A to build the finalaugmented machine "B.

This two-step division of the weaving process means that the algorithm cannothandle a number of problematic cases: when the pointcut descriptor matches advicestates, and thus advice should be inserted on other advice; when the addition ofadvice states creates a new matching joinpoint in the computation, and adviceshould be inserted; and when the addition of advice states causes a location thatonce matched a pointcut descriptor not to match it any longer.

In order to handle these cases, a more complex weaving process would be re-quired. But this simple view captures many if not most aspect-oriented program-ming use cases. The invocation of advice within other advice is often explicitlyguarded against by the programmer. Engineers familiar with AspectJ will recall anumber of pointcut descriptor idioms that are used for this purpose, such as the useof !within(A) && ... in pointcuts of aspect A to prevent those pointcuts from match-ing inside the advice. As for the creation and destruction of matching joinpoints bythe addition of advice, with most aspects and pointcuts the problem does not arise.It would also be possible, under certain restricted circumstances, to make use of this

10


a b

M

(a) A simple base machine, where thestate labeled a may or may not matchthe pointcut.

M!

a b

ba

pointcut

(b) The pointcut-ready version, whereonly the pointcut state matches thepointcut, and always does so.

Figure 2.1: Constructing a pointcut-ready machine M! for the given M and LTLpast formula pointcut descriptor ! = a ! Y b ! Y Y b

two-step weaving. For example, if pointcuts are only removed by the addition ofadvice, then the weaving here is still sound when used to prove extension of safetyproperties from base to augmented system.

2.5.1 Constructing a Pointcut-Ready Machine

Pointcut-ready machine B! = (SB! , SB!

0 , RB! , LB! , FB!) is a machine in which un-winding of certain paths has been performed, so that we can separate paths whichmatch pointcut descriptor ! from those that do not. The pointcut-ready machinecontains states with a new label, pointcut, that indicates exactly those states wherethe descriptor has been matched.

This machine must meet the following requirements:

• SB! ) SB

• LB! is a function from SB! to P (APB * {pointcut})

• For all finite-length paths % = s0, . . . , sk in B! such that s0 ' SB!

0 , we havelabel(%) |( ! + sk |= pointcut .

• For all infinite sequences of labels l = (P(APB))$, there is a fair path %B! inB! where label(%B!)|APB = l if and only if there is a fair path %B in B wherelabel(%B) = l.

Note that since B and B! have the same paths (over AP , ignoring the addedpointcut label), they must satisfy exactly the same LTL formulas over AP .

11


Figure 2.1 shows a simple example of this construction. Note that in statediagrams, the absence of an atomic proposition indicates that the proposition doesnot hold, not that the value is unknown or irrelevant. This is in contrast to aformula, where unmentioned propositions are not restricted.

Finally, note that for a pointcut descriptor that examines only the current state,the splitting and unwinding is unnecessary, and pointcut can be added directly tothe states in which the pointcut descriptor is matched.

2.5.2 Constructing an Augmented Machine

We construct the components of augmented machine "B = (S"B, S "B0 , R"B, L"B, F"B) as

follows:

• S"B = SB! * SA

• S "B0 = SB!

0

• (s, t) ' R"B +

#$$$$$$%

$$$$$$&

(s, t) ' RB! ! s ,|= pointcut if s, t ' SB!

(s, t) ' RA if s, t ' SA

s |= pointcut ! t ' SA0

! LB!(s)|AP = LA(t) if s ' SB! , t ' SA

s ' SAret ! LA(s) = LB!(t)|AP if s ' SA, t ' SB!

Note that this relationship is ‘if and only if.’ In words, the path relation containsprecisely all the edges from the pointcut-ready base machine B! and from aspectmachine A, except that pointcut states in B! have edges only to matching startstates in A, and aspect return states have edges to all matching base states.

• L"B(s) =

'LB!(s) if s ' SB!

LA(s) if s ' SA

• F"B = {Fi * SA | Fi ' FB!}

From the definition of F"B, a path is fair in "B if it either satisfies the original fairnessconstraint of the pointcut-ready machine, or if it visits some aspect state infinitelymany times. The fairness condition is thus more inclusive, increasing the number ofpaths that will be considered. This conservatively inclusive definition is necessaryin order to guarantee the correctness of our verification algorithm.

A weaving is considered successful if every reachable node in S"B has a successoraccording to R"B.

12


2.6 Weakly Invasive Aspects

As mentioned above, we show our result for the broad class of aspects which, whenthey return from advice, do so to a reachable state in the base machine. Withoutthis restriction, the aspect may return to unreachable parts of the base machinewhose behavior is not bound by assumption formula ". In this case, the augmentedsystem contains portions with unknown behavior, and is di"cult to reason about ina modular way.

Definition 4. An aspect A and pointcut ! are said to be weakly invasive for abase machine B if, for all states in SB! that are reachable by following a fair pathin "B, those states were reachable by following a fair path in B!.

In particular, this means that all states to which the aspect returns are statesreachable in the pointcut-ready base machine. This could of course be checkeddirectly, but would require construction of the augmented machine — precisely theoperation we would like to avoid. In many cases, the aspect can be shown weaklyinvasive for any base machine satisfying its assumption ", by using local modelchecking, additional information (our reasoning in the discount price example fromSection 1.4 uses such information), or static analysis (both spectative and regulativeaspects can be identified in this way). For further discussion, see [13].

13


Chapter 3

Verification Algorithm

The modular verification algorithm builds a tableau from base requirement " andweaves A with this tableau according to pointcut descriptor !, then performs modelchecking to verify the result with respect to augmented result #. In the followingsection we prove that when this model check of the constructed augmented tableausucceeds, then for any base system satisfying ", applying aspect A according topointcut descriptor ! will yield an augmented system satisfying #.

Algorithm

Given:

• set of atomic propositions AP ;

• assumption " for base systems, an LTL formula over AP ;

• desired result # for augmented systems, an LTL formula over AP ; and

• aspect machine A and pointcut descriptor ! over AP .

Perform the following steps:

0. If it does not already, augment " with clauses of the form · · ·! (a#¬a),such that " contains every atomic proposition a ' AP , without alteringits meaning.

1. Construct T", the tableau for ". Since " contains every AP , the resultof Theorem 1 will hold when all labels in AP are considered.

2. Restrict T" to only those states reachable via a fair path.

3. Weave A into T" according to !, obtaining !T".

4. Perform model checking in the usual way to determine if !T" |= #.

14


3.1 Correctness

Given the components defined above, suppose that:

!T" |= # .

What we have shown, then, is that the tableau for assumption " woven withaspect A according to ! gives a resulting machine that satisfies desired augmentedresult #. Our goal is to use the properties of !T" to show that A and !, when wovenwith any possible base machine M for which M |= ", will always yield an augmented!M such that !M |= #.

We will show !M |= # for any such M by proving that for every infinite fairpath %!

M in !M , there is an infinite fair path %!T in !T" such that their labels match

(restricted to AP ). Since !T" |= #, every path in !T" must support #; if every path in!M has the same labels as some such path, then every path in !M supports # as well.

Before beginning the proof, let us establish that such a relationship alreadyholds for our original base machine M and tableau T", and in their pointcut-readyversions:

Lemma 1. Given M |= ", for every infinite fair path %M in M , there is aninfinite fair path %T in T" such that label(%M)|AP = label(%T )|AP .

Proof. Since M |= ", by Theorem 1, such a correspondence exists.

Lemma 2. Given M |= ", for every infinite fair path %M in M!, there is aninfinite fair path %T in T !

" such that label(%M)|AP = label(%T )|AP .

Proof. By construction, M! and T !" contain precisely the same fair paths as

M and T", respectively. Using Lemma 1, we see that this correspondence holds forthe pointcut-ready machines.

Intuitively, the proof of correctness will show that this relationship is preservedunder weaving according to the semantics we have defined, by showing that at everyedge along %!

M , at least one of the paths in !T" that has, up until this edge, matched%!

M will continue to do so for this edge as well. Consider two cases:

Unmodified path If the path %!M contains no state labeled pointcut, it must be

the same as some fair path in M!, for which we already know of a matchingpath in T !

". This matching path would have been unmodified during weaving,

and is identical to a path %!T in !T", a matching path for %!

M .

15


... ...

...

...

...

...

s!i"1 s!i

Figure 3.1: Using existing fair paths (small states) to guarantee existence of a fairpath (shaded) containing edge (s!i"1, s

!i)

Modified path In this case, our intuition is that the specific weaving semanticswe have defined, combined with the fact that our aspect is weakly invasive,will allow us to find a matching path in the augmented tableau, where theoperations of the weaver on T !

" ‘mirrored’ those that were performed on thispath in M!.

In order to prove the theorem, we will rely on the following central lemma. Weconsider the set # of finite-length prefixes of matching paths %!

T in !T" for a givenpath %!

M in !M , and show that at no point over the length of %!M is this set # ever

empty.Let %!

M = s!0, s!1, . . . be a path in !M . For the finite prefix of %!

M of lengthi, containing i edges and i + 1 nodes, let #i be the set of all finite prefixes oflength i of fair paths in augmented tableau !T" such that for all % ' #i, we havelabel(%)|AP = label(s!0, . . . , s

!i).

Lemma 3. For #i as defined, for any i $ 0, #i is never empty.

Proof. The proof is by induction.The reader should note that states s!i below are always in the set of augmented

machine states S "M , and states in S!T"are always indicated by t!i.

Consider i = 0, where we must match the prefix consisting of the single initial

state of %!M . Since s!0 ' S "M

0 , we define #0 as:

#0 =(t!0

)))) t!0 ' S!T"0 ! L!T"

(t!0)))))AP

= L "M(s!0))))AP

*.

This #0 contains all initial states of the augmented tableau with the same labels ass!0, so it contains exactly all length-0 prefixes matching s!0. Furthermore, since s!0 is

16


a state in M!, there must be some path from s!0 in M! that is fair in that machine;by Lemma 2, this path must have a matching path in T !

" with a matching initial

state in ST !

"0 , which is equal to S

!T"0 . Therefore, #0 contains at least one match.

Now assume #i"1 contains the non-empty set of all prefixes of length i - 1matching s!0, . . . , s

!i"1 under AP . We follow an edge

+s!i"1, s

!i

,' R "M . Define #i as:

#i =(t!0, . . . , t

!i"1, t

!i

)))) t!0, . . . , t!i"1 ' #i"1

! (t!i"1, t!i) ' R!T"

! L!T"(t!i)

))))AP

= L "M(s!i))))AP

*

It is clear from this definition that #i contains all matching length-i prefixes,given the assumption, since it adds all matching states t!i reachable from any of thestates t!i"1 matched previously, and there cannot be any length-i match whose prefixof length i- 1 is not a match for that length of %!

M . It remains to show that this #i

is also non-empty in each of four possible cases based on the composition of S "M .

Base-to-aspect In this case, s!i"1 ' SM! and s!i ' SA. It must be that s!i"1 |=pointcut , which is true if and only if label(s!0, . . . , s

!i"1) |( !.

Since every t!0, . . . , t!i"1 ' #i"1 has the same labels as this prefix, they must

also match !, and every t!i"1 must be labeled with pointcut, and have edges tothe same aspect start state(s) as s!i"1.

Aspect-to-aspect In this case, s!i"1 ' SA and s!i ' SA. Since A is an identical

component of both !M and !T", if there was some edge to follow in the former,the same edge must be present in the latter.

Aspect-to-base In this case, s!i"1 ' SA and s!i ' SM! . It must be that s!i"1 ' SAret ,

so for some t!0, . . . , t!i"1 ' #i"1, t!i"1 ' SA

ret . By the definition of the transitionrelation of an augmented machine, we have edges from these t!i"1 to everyt!i with matching labels, and since we demand that the aspect weaving besuccessful, there must be at least one such edge.

Base-to-base In this case, s!i"1 ' SM! and s!i ' SM! . It must be that+s!i"1, s

!i

,'

RM! . Since s!i"1 is reachable by following a fair path in M!, and s!i is as well,

this edge is also part of the fair path that reaches s!i"1, goes along+s!i"1, s

!i

,,

and has some fair infinite continuation from s!i (see Figure 3.1). Again byLemma 2, this path has a corresponding path in T !

".

We can also be assured that s!i"1 ,|= pointcut , so the corresponding state in T !"

also is not labeled pointcut. Thus, there is an edge in !T" corresponding to this

17


edge in !M . Since #i"1 contains all prefixes of length i- 1 that match %!M , it

must contain the prefix that arrives to the state with this edge, giving at leastone path in #i"1 that we can extend and include in #i.

Therefore, the set #i of matching prefixes of length i is never empty for any case,concluding the proof of our lemma.

With this lemma, it is only a short step to reach our goal:

Theorem 2. Given AP , ", #, A, and ! as defined, if !T" |= #, then for anybase program M over a superset of AP such that A and ! are weakly invasive forM , if M |= " then !M |= #.

Proof. Consider any such M . By Lemma 3, for every infinite fair path %!M in

!M , there must be at least one corresponding infinite fair path %!T in !T", because the

set of matching finite prefixes is never empty as their length goes to infinity. Thispath %!

T is guaranteed to be fair since one of two conditions must hold:

• Either %!T visits some aspect state infinitely often, and is therefore fair by the

definition of F"B; or

• %!T has an infinite su"x in which no aspect states are visited, in which case it

is identical to a matching path in T", known to be fair from Theorem 1.

Since every path in !T" has been shown to support #, every path in !M must doso as well, so this correspondence completes the proof that !M |= #.

3.2 Example

By way of example, suppose we have an aspect with base system assumption " =A G ((¬a ! b) " F a) — that is, any state satisfying ¬a ! b is eventually followedby a state satisfying a. We would like to prove that the application of our aspectto any base system satisfying " will give an augmented system satisfying result# = A G ((a ! b) " X F a) — that is, any state satisfying a ! b will eventuallybe followed by a later state satisfying a. While this example may not have clearcorrelation to a code-level problem, it serves to illuminate the capabilities of ourtechnique.

Figure 3.2 shows the reachable portion of the tableau for the assumption ".In the diagram, shaded states are those contained in the only fairness set. Thenotation Xg, not formally part of the state label, designates states in the tableauwhich satisfy Xg for subformula g = F a (this labeling serves only to di!erentiatestates; other labels of this form have been omitted for clarity, and all such labels

18


a a b

a Xga b

Xg

b XgXg

s0 s1

s2 s3

s4 s5

s6

Figure 3.2: The reachable portion of tableau T" for " = A G ((¬a ! b) " F a)

a b b

Figure 3.3: A simple aspect machine A

19


a a b

a Xga b

Xg

b XgXg

s0 s1

s2 s3

s4 s5

s6

a b

b

Figure 3.4: Augmented tableau !T", satisfying # = A G ((a ! b) " X F a)

become invalid after weaving). For the example pointcut descriptor ! = (a ! b),this tableau machine is also pointcut-ready for ! (since ! references only the currentstate), simply by adding pointcut to the labels of s3 and s5.

Figure 3.3 shows the state machine A for the advice of our aspect. This advicewill be applied at the states matched by !, and Figure 3.4 gives the weaving of Awith T" according to !. Model checking this augmented tableau will indeed establishthat it satisfies the desired property #. This result follows neither from the aspectnor base machine behavior directly, but from their combined behavior mediated by!. And since !T" |= #, any M |= " will yield !M |= #.

Reasoning intuitively about A and ! without examining the tableau supportsthis conclusion: the advice is invoked at all states of such an M that match (a! b),the advice always leads to a state satisfying (¬a ! b), and " guarantees that fromsuch a state we will always reach a state satisfying a, which is exactly the assertionof #.

Figure 3.5 depicts a particular base machine M satisfying ", as could be easilyverified by model checking. Again, the shaded states are those in the only fairnessset. Although this M is small, it does contain atomic proposition c not ‘visible’ tothe aspect, and it has a disconnected structure very much unlike the tableau.

From Figure 3.6, one sees it is indeed the case that the augmented machine !M

20


satisfies # — but there is no need to prove this directly by model checking. Thisholds true even though the addition of the aspect has made a number of invasivechanges to M : state s1 is no longer reachable, because its only incoming edge hasbeen replaced by an advice edge; a new loop through s0 has been added, while inM there was no path visiting s0 more than once; there is a new path connecting thepreviously separated left-hand component to the right-hand; and so forth. In morerealistic examples, the di!erence in size between the augmented tableau (involvingonly ", !, and A) and a concrete augmented system with advice over a full basemachine would be substantial.

21


b

a b c

a c

c

s0

s1

b

Figure 3.5: One particular base machine M |= "

a b b

b

a b c

a c

c

b

s0

s1

Figure 3.6: Augmenting M with A according to ! gives result !M |= #

22


Chapter 4

Implementation

The verification algorithm defined in the previous chapter has been implemented ina prototype system called maven. This chapter gives both an overview of the high-level design and a discussion of some implementation details; the following chapterprovides a number of example aspects that have been successfully verified using thisprototype.

4.1 Design

The most straightforward design for a system implementing the modular verificationalgorithm from Chapter 3 is shown as a flow chart in Figure 4.1. In the diagram, userinput is indicated at the top left in italics, and the output is verification success orfailure, on the right. The input takes the form of an aspect written in a code-levellanguage (AspectJ, etc.), along with its specification expressed as LTL formulas.From both of these inputs, models are created — a state machine model for theaspect advice, and a state machine tableau from the base system requirement portionof the specification. These models are then combined by a weaver according to thepointcut, which must also be translated into state machine terms along with theadvice code. The resulting augmented tableau model is passed to an LTL modelchecker for verification of the augmented system result formula.

In the diagram, the components indicated in gray are those that we assumealready to exist in usable form:

Model generator A tool which consumes code and produces a state machine rep-resentation of that code for use with model checking. The Bandera tool set [11],which creates models from Java code, is one example. An aspect version ofBandera for use with AspectJ is under development as part of the CAPEproject [7], but is not yet available.

23


Aspect CodeSpecification

LTL

Model

Generator

Model

Weaver

Tableau

Constructor

Tableau

Model

Aspect

Model

Woven Tableau

Model

Model

Checker

Success or

Failure

Figure 4.1: Flow chart for a ‘model-based’ verifier implementation

Aspect CodeSpecification

LTL

Tableau

Writer

Tableau

Code

Code

Weaver

Woven Tableau

Code

Model

Generator

Woven Tableau

Model

Model

Checker

Success or

Failure

Figure 4.2: Flow chart for a ‘code-based’ verifier implementation

24


Tableau constructor As we noted in Section 2.1, LTL model checking is oftenperformed with the use of a tableau; as such, components are readily availableto produce tableau automata in a variety of model languages.

Model checker An LTL model checker, presumably one which uses the modellanguage of the code and tableau modeling components, or which is integratedwith them, as is the case with Bandera.

Shown in white, the specialized component that remains to be written is the modelweaver, which combines tableau and aspect models according to the tableau weavingalgorithm. Assuming that the model generator, tableau constructor, and modelchecker are components of an integrated model checking system, this weaver wouldbe best implemented by operating on the internal model representation used by sucha package.

An alternative design that o!ers a di!erent trade-o! between reuse and writingof new components is given in Figure 4.2. We call this implementation ‘code-based,’in contrast with the previous ‘model-based’ implementation, because it shifts theemphasis from manipulating state machine models to manipulating high-level code.Here, instead of constructing a tableau model, we construct a tableau written incode, and use an existing code weaver to weave our aspect with the tableau. Onlyfrom the result do we then generate a model and perform model checking. A primeexample of such a code weaver is the AspectJ compiler, which produces Java byte-code from aspect-oriented source that uses AspectJ’s extensions. Such bytecode canbe fed to, e.g., Bandera in the same way as Java source.

This ‘code-based’ design has the advantage that verification is immediately avail-able for code-level aspects, without needing an aspect code to model translator.However, it has some significant drawbacks. Most importantly, the design assumesthat the output from the code-level weaver (given an aspect and a code tableau)can be used to generate a model that is equivalent to the specialized augmentedtableau model required in order for the verification to yield sound results. Provingthis property of the woven model could be quite di"cult, depending on the oper-ation of the weaver. Furthermore, since we rely on both the code-level weaver ofa specific language and a tableau writer which creates code-based tableaux in thatlanguage, this design is far less extensible to new languages in the future. Contrastthis with the former design, in which we can handle any aspect language for whicha model generator has been written, and where the tableau weaver is a specializedcomponent tailored to use precisely the necessary weaving semantics.

For our prototype implementation, we have chosen to use the first, ‘model-based’design.

25


Specification

LTL

FSMA

Weaver

ltl2smv

Tableau

SMV

Aspect

FSMA

Woven Tableau

SMV

NuSMVSuccess or

Failure

containing

Figure 4.3: Flow chart for the maven prototype implementation

4.2 maven Prototype

Finding a platform of existing components that could be used to demonstrate theverification algorithm as a working prototype was more di"cult than originally an-ticipated. After examining several alternatives, the NuSMVmodel checker [18] wasselected as the basis for our prototype implementation, called maven, for “ModularAspect VErificatioN.” This prototype is very preliminary in nature. maven oper-ates on the level of textual input to and output from NuSMV components, and assuch is and would not be appropriate for use with large aspect models. It is writtenin the Ruby scripting language [20]. A flow chart showing the components of mavenappears as Figure 4.3.

As can be seen from the flow chart, the conversion step from aspect code to aspectmodel has been elided. In the maven prototype, aspects are specified directly asstate machines, albeit using a more convenient and expressive language than directdefinition of the machine states and transitions, as explained below.

NuSMV is a CTL (branching-time logic) and LTL model checker that acceptsits input as textual definitions of state machine systems and their specifications.We have extended the NuSMV finite state machine language to create FSMA,for “finite state machine aspects,” which describes aspects and their specifications.The language is based closely on the usual input language of NuSMV, with some

26


added restrictions, and with a collection of new keywords used for aspect-specificdeclarations. A formal description of FSMA syntax is given in Appendix A. Thefollowing list of directives gives a brief explanation for each; the reader is encouragedto examine the examples in the following chapter to see how these directives are usedtogether to create a complete aspect definition and specification.

VAR – –BASE Following this directive, one or more definitions of base machinevariables can appear. NuSMV allows the user to specify variables which taketheir value from a symbolic set or numerical range, in addition to booleans,making complex systems considerably easier to express than when limited toboolean labels.

VAR – –ASPECT Following this directive, one or more definitions of aspect ma-chine variables can appear.

POINTCUT Describes the aspect’s pointcut. Only current-state expressions arevalid; (past) LTL syntax is not permitted. The complete pointcut is taken tobe the disjunction of all POINTCUT directives; this allows the user to specifymultiple logical pointcuts for the aspect.

INIT Describes the initial states of the aspect machine. The complete initial statepredicate is taken to be the conjunction of all INIT directives.

TRANS Gives a restriction on the set of valid transitions within the aspect machine.As in NuSMV, the conjunction of all TRANS directives forms the completerestriction. Unlike in NuSMV, TRANS is the only directive available forspecifying state machine transitions in FSMA. Thus, any pair of states forwhich all TRANS predicates hold is considered to be included in the aspecttransition relation.

RETURN Describes the return states of the aspect machine. Return states haveno outgoing transitions, even if there would exist transitions permitted byTRANS. The complete return state predicate is taken to be the disjunction ofall RETURN directives.

LTLSPEC – –BASE Defines an expression which must hold as part of the basesystem requirement. The complete base system requirement is taken to be theconjunction of these directives, and this complete requirement will be used toconstruct the tableau.

LTLSPEC – –AUGMENTED Defines an expression which must hold as part ofthe augmented system result. The complete base system requirement is takento be the conjunction of these directives, and this complete requirement willbe checked for satisfaction against the woven tableau.

27


Unlike NuSMV, each of these directives must be correctly terminated with asemicolon; this is a restriction from the more liberal NuSMV which considers ter-minating semicolons optional.

From the definition of the POINTCUT directive, one limitation of maven isimmediately clear: only pointcuts which are restricted to examining the currentstate are permitted. That is, this prototype does not include the step of creatingpointcut-ready machines during its weaving. However, as discussed in Section 2.3,allowing examination of past states in the pointcut may not be a requirement formodeling expressive pointcut languages.

The model checker in maven is NuSMV, as discussed above. The tableauconstruction is performed by ltl2smv, an independent component included in theNuSMV source distribution. The ltl2smv program takes as input an LTL formulain the syntax used by NuSMV, and outputs the corresponding tableau state machinein NuSMV syntax, modulo some slight irregularities. It is by modifying this textualrepresentation of the tableau that we weave it with the aspect according to thepointcut; the result is a valid NuSMV input file representing the woven tableauand the augmented system results that must hold in it, which can be given directlyto the model checker for verification.

The aspects verified while developing and testing maven have not yet reacheda size where meaningful performance numbers can be o!ered. For all the correctly-specified models verified heretofore, runtime has been trivial. For some incorrectFSMA files, the constructed augmented tableau has many nodes and a dense tran-sition relation, which NuSMV would take many hours to examine. Since mavenhas virtually no input error checking, in this case the user must terminate the modelchecking manually and reconsider his input. Given a reasonable model, however,the prototype is able to complete verification in a span of moments.

The maven tool and usage instructions are available for download at:

http://www.cs.technion.ac.il/Labs/ssdl/thesis/finished/2006/max

The use of this prototype requires NuSMV (which includes ltl2smv), as well as theRuby interpreter. URLs for these tools can be found in the references. maven hasbeen tested under Mac OS X and Linux.

28


Chapter 5

Examples in Action

All of the examples of this chapter have been implemented with FSMA code andverified using the maven prototype of our verification algorithm. They have beenselected for their ability, in a simple and highly abstract way, to demonstrate real-world situations in which the verification technique is applicable and e!ective.

5.1 Revisiting 3.2

To convince the reader that the example in Chapter 3 is demonstrative of howrealistic aspect specification and verification will operate, at least on a high level,we restate the example in the terms of a real-world system where the user can requestthat the system update some display of the system’s status. Consider:

" = A G ((¬display ! request) " F display)# = A G ((display ! request) " X F display)

We can understand this specification — which has precisely the same mathemat-ical form as before — to mean the following: prospective base systems are knownto have the property that, whenever a request for a status display is made when thedisplay is not active at the same time, eventually the display will be shown. We wishto use an aspect to guarantee the new behavior that, when the request comes whilethe display is already active, a later status display will still occur, presumably withupdated information.

Figure 5.1, contains the FSMA source code corresponding to this specificationand the “simple aspect A” and pointcut ! used in Section 3.2, translated into thenew terms. Performing a verification on this file yields the result that our formula# holds in the augmented tableau, and the aspect satisfies its specification. Therelevant output from the maven system is:

29


1 VAR --BASE2 display : boolean ;3 request : boolean ;4 POINTCUT5 display & request ;6 TRANS7 display & request -> next(!display & !request) ;8 TRANS9 ! display & !request -> next(!display & request) ;

10 RETURN11 ! display & request ;12 LTLSPEC --BASE13 G ((! display & request) -> (F display)) ;14 LTLSPEC --AUGMENTED15 G (( display & request) -> (X F display)) ;

Figure 5.1: FSMA source for the display example

################################The transition relation is total : No deadlock state exists################################-- specification G (( display & request) -> X F display ) is true

The message that “no deadlock state exists” ensures that a weakly invasiveweaving with the tableau was possible, and the fact that our specification # holdsshows the correctness of the aspect with respect to its specification.

5.2 Discount at the Checkout Counter

The notion of a retail store discount policy aspect is discussed at length in [6]. In theintroduction, we noted that such an aspect is in fact weakly invasive, even though itis arbitrarily altering the prices of items. In this section, we give a concrete discountaspect whose specified goal is to implement a “50% O! the Entire Store” policy atthe point of purchase.

We model the process of purchasing an item with a state variable sale that canbe one of none, start, or finish. We will demand that in the base system, the startand finish states always appear in consecutive pairs, modeling a point of sale systemwhere a transaction is first set up, then executed. In FSMA code:

30


VAR --BASEsale : { none, start , finish } ;

LTLSPEC --BASEsale = none ;

LTLSPEC --BASEG (( sale = start) <-> X (sale = finish)) ;

The line sale = none is a requirement on initial states of the base system ensuringthat it does not start ‘in the middle’ of a start-finish pair.

Prices in our simple system are designated by integers from zero to ten. However,we specify as an invariant requirement on the base system that the value of the pricestate variable never in fact goes to zero:

VAR --BASEprice : 0..10 ;

LTLSPEC --BASEG price > 0 ;

With this base system in place, the goal of our aspect is to intercept transactionsas they are made, and reduce the price by 50% before the transaction is finalized.To do this, we use the following pointcut and advice machine:

POINTCUTsale = start ;

TRANSnext( sale ) = finish & next(price ) = (price + 1) / 2 ;

RETURNsale = finish ;

This defines a two-state machine where the sale variable goes from start to finish,and the price is reduced by half under integer division. To complete our aspectspecification, we give the desired augmented system result:

LTLSPEC --AUGMENTEDG price > 0 ;

LTLSPEC --AUGMENTEDG (( sale = finish ) -> (price <= 5)) ;

This result formula has two parts. The first is extending the non-zero priceinvariant of the base system to the augmented system. Thus, in our advice, we mustdefine the new value next(price) using (price + 1) / 2 to avoid the integer division of1/2 = 0 yielding a new price of 0. If this line is altered to read next(price) = price/ 2, a verification attempt will report that the augmented system has reachabledeadlock states, resulting from the fact that in the event of a zero price, the aspecthas no way to make a weakly-invasive return to the base system.

31


1 VAR --BASE2 sale : { none, start , finish } ;3 price : 0..10 ;4 POINTCUT5 sale = start ;6 TRANS7 next( sale ) = finish & next(price ) = (price + 1) / 2 ;8 RETURN9 sale = finish ;

10 LTLSPEC --BASE11 sale = none ;12 LTLSPEC --BASE13 G (( sale = start) <-> X (sale = finish)) ;14 LTLSPEC --BASE15 G price > 0 ;16 LTLSPEC --AUGMENTED17 G price > 0 ;18 LTLSPEC --AUGMENTED19 G (( sale = finish ) -> (price <= 5)) ;

Figure 5.2: FSMA source for the discount example

The second part of the augmented system result formula introduces an entirelynew property, not satisfied by many legal base systems, whose satisfaction is guaran-teed by the aspect. Here we only claim that all the new prices are less than or equalto five; obviously, a stronger claim could be made if desired. We can imagine morecomplex augmented result formulas that encode business-logic relationships betweeninitial and discounted prices, guaranteeing that aspects written to implement thesepolicies are not giving customers a better bargain than the store intended.

The complete FSMA source code is brought together in Figure 5.2. Lines 1through 9 define the aspect, and lines 10 through 19 give its specification, althoughthe order of directives in the file is up to the author’s discretion. The relevant veri-fication output is in Figure 5.3. The model checker has identified the deadlock stateassociated with a reduced price of zero, but the weakly invasive weaving is successfulbecause this state is unreachable in the woven tableau. Our two augmented systemspecification formulas have been combined for the model checker, and the aspect iscorrect.

32


################################The transition relation is not total . A state withoutsuccessors is :sale = finishprice = 0w aspect p = 1

However, all the states without successors arenon-reachable, so the machine is deadlock-free.################################-- specification ( G price > 0 & G (sale = finish -> price <= 5)) is true

Figure 5.3: maven verification results for the discount example

5.3 Error Alert Messages:A Counterexample Analysis Case Study

The previous two examples have o!ered a straightforward view of the modular ver-ification technique in action. However, in addition to using the prototype verifier todemonstrate positive verifications, we have also used it in cases where the verificationfails.

Failure of an aspect verification is not, however, the end of the road. When theaugmented tableau fails to satisfy the desired result formula, we are provided witha counterexample from the model checker. This counterexample is some path thatcould result from weaving the aspect in question with some (unknown) qualifyingbase machine. Examining this path allows us to see one possible combined behaviorof base machine, pointcut, and aspect in a specific set of circumstances under whichthe aspect fails to achieve the goals it was designed to meet.

By reasoning about the circumstances presented in a counterexample producedfrom model checking the augmented tableau, we can improve one or more of thespecification, pointcut, or advice of our aspect. The need to refine the specificationindicates either that our original base system assumption was not strong enough, orpossibly that our augmented result was too strong to prove. Refining the pointcutcan occur when the counterexample reveals a situation where the aspect fails toexecute advice when it is needed, or activates advice in an inappropriate situation.The advice may need to be altered if the counterexample reveals circumstancesunder which our original implementation is inadequate; in the case where the advicemodel has been derived via abstraction from source code, the counterexample couldindicate a place where our abstraction needs refinement.

In the present example, we examine the specification of an aspect whose purpose

33


is to alert the users of a system to the occurrence of errors. The aspect will use anexisting message sending and delivery mechanism whose implementation is unknownbut whose relevant properties will be encoded in the base system assumption. Afterinitial failure to achieve positive verification, we will revise our aspect based on newunderstanding. Appendix B lists the complete source code for each version, and theline numbers here correspond to lines in those listings.

To write Version 1 of our aspect, we begin by outlining the variables of our basesystem:

1 VAR --BASE2 error : boolean ;3 act : { send, rcv } ;4 msg : { normal, alert } ;

State variable error is here a simple boolean indicating error states, to be useddirectly in our pointcut description. For a real system, this state predicate might bedropped, and the pointcut itself would identify error states. Variable act indicatesthe present activity of the system, either sending or receiving, and msg is the messagebeing sent or received. In this simple model we abstract the set of possible messagesdown to two values, alert being the message we wish to send and subsequently receivewhen an error is seen.

The sending and receiving of messages is a function of the base system, andsince our aspect will rely on this function, we specify it as part of the base systemrequirement:

15 LTLSPEC --BASE16 G ((act = send & msg = normal) -> F (act = rcv & msg = normal)) ;17 LTLSPEC --BASE18 G ((act = send & msg = alert) -> F (act = rcv & msg = alert)) ;

That is, for both normal and alert messages, a send of the message is eventuallyfollowed by a receive of that message. This obligation seems to capture our intuitivenotion of how messages must be sent and delivered. The augmented result formulais straightforward as well:

19 LTLSPEC --AUGMENTED20 G (error -> F (act = rcv & msg = alert)) ;

The implementation is simple as well, here using variable pc as a program counterto control the evolution of the aspect state machine. We simply activate the aspectin any error state, and set the system to send an alert message:

5 VAR --ASPECT6 pc : 1..2 ;

34


error

send

normal

error

send

normal

send

alert

send

alert

Base Aspect

(a) Counterexample provided by themodel checker.

error

send

normal

error

send

normal

send

alert

send

alert

receive

normal

receive

alert

(b) One possible concrete base ma-chine (dark states) that would induceundesirable behavior after weaving.

Figure 5.4: Counterexample for the error alert message aspect, Version 1

7 POINTCUT8 error ;9 INIT

10 pc = 1 ;11 TRANS12 pc = 1 -> next(pc = 2) & next(act = send) & next(msg = alert) ;13 RETURN14 pc = 2 ;

However, attempting to verify this aspect leads to a negative result, expressed asa counterexample from the augmented tableau model check. A graphical depiction ofthis counterexample is given in Figure 5.4(a). In this computation, the base machinebegins in a state satisfying send ! normal ! error , triggering the aspect. The finalstate of the aspect advice satisfies send!alert!¬error , and it returns to an identicalbase state. From there, the base machine goes again to the send ! normal ! errorstate, creating a loop where error alerts are never received. Given this, we pose thequestion: what legal base machines would, when woven, give rise to this undesirablepath?

Constructing one such possible base machine, shown in Figure 5.4(b), which

35


error

receive

normal

error

receive

normal

error

send

alert

error

send

alert

error

send

alert

Base Aspect

Figure 5.5: Counterexample for the error alert message aspect, Version 2

would be woven into an augmented machine containing the given counterexample,suggests a possible source of the problem: the behavior of the base machine hasbeen insu"ciently specified. The example we have chosen is of a base machinewhose construction is a single loop structure, in which our aspect will end up simplybypassing the receive states, thus preventing the alert initiated by the aspect fromever being delivered. While the behavior of this possible base machine may appearrather degenerate, it does satisfy the base machine requirement. And while the factthat this machine seems to receive an alert before the first send occurs is suspect, theproblem is more precisely that the aspect’s assumption about the message handlingcapability of the base system is not strong enough to ensure that this messagehandling will continue to work correctly when the aspect is added.

For Version 2 of our aspect, therefore, we will make a small change to the basesystem requirements, introducing a new value for the state variable act in the pro-cess:

1 VAR --BASE3 act : { send, rcv , idle } ;

15 LTLSPEC --BASE16 G ((act = send & msg = normal)17 -> X ((act = idle) U (act = rcv & msg = normal))) ;18 LTLSPEC --BASE19 G ((act = send & msg = alert)20 -> X ((act = idle) U (act = rcv & msg = alert))) ;

While the rest of the FSMA file is unchanged, here we have introduced an idleoption for the base machine’s action, and specified that after a send, the messagesending and delivery mechanism of the base should be idle until a receive of that

36


message is performed. This will eliminate the undesirable behavior evidenced in thecounterexample from Version 1, and should move our aspect specification closer tocorrectness.

Indeed, this is the case — the specification is perhaps closer to correct, but stillfails to verify. Figure 5.5 shows the new counterexample, which in this case we willexamine on its own. The problematic behavior is clear: because we did not specifywhat the advice code does with the error flag, it is possible that this state variablewill still be true when the advice returns — immediately invoking our advice again.

To address this infinite error loop issue, our first change for Version 3 of theaspect is to lower the error flag in the advice:

11 TRANS12 pc = 113 -> next(pc = 2) & next(act = send) & next(msg = alert) & next(!error) ;

This change is not likely to be su"cient, however, because we can imagine longercounterexample traces where the error flag would be re-raised during message trans-mission, allowing for loops that never reach a receive state. So we also make anatural strengthening of our base system requirement, demanding that errors notoccur so long as the system is idle:

16 LTLSPEC --BASE17 G ! ( error & (act = idle )) ;

With these changes, verification of Version 3 of the error alert message aspectsucceeds.

The resolution given here is only one way to correct the original verificationproblems. Other solutions might be more appropriate, depending on the real-worldcircumstances we have abstracted away in this example. The important point is thatby using the modular verification method, we were able to reason about the aspect’scorrectness independent of any particular base machine. Furthermore, the methodhas forced us to think carefully and precisely about what the aspect will assume,do, and guarantee; precision and certainty being the goal of formal analysis.

37


Chapter 6

Related Work

The first work to separately model check the aspect state machine segments thatcorrespond to advice is [16], where the verification is modular in the sense thatbase and aspect machines are considered separately. The verification method alsoallows for joinpoints within advice to be matched by a pointcut and themselvesadvised. However, the treatment there is for a particular aspect woven directly to aparticular base program. Additionally, it shows only how to extend properties whichhold for that base program, proving that the augmented program satisfies them aswell (properties are specified in branching-time logic CTL). A key assumption oftheir method is that after the aspect machine completes, the continuation is alwaysto the state following the joinpoint in the original base program. This requirementis much stronger than the assumption used here of a weakly invasive aspect.

In [14], model checking tasks are automatically generated for the augmentedsystem that results from each weaving of an aspect. That approach has the disad-vantage of having to treat the augmented system, but o!ers the benefit that neededannotations and set-up need only be prepared once. That work takes advantage ofthe Bandera [11] system that generates input to model checking tools directly fromJava code, and can be extended to, for example, the aspect-oriented AspectJ lan-guage, as noted in Section 4.1. Bandera and other systems like Java Pathfinder [12]that generate state machine representations from code can be used to connect com-mon high-level aspect languages to the state machines used in the results here.

In [13] a semantic model based on state machines is given, and the treatment ofcode-level aspects and joinpoints defined in terms of transitions, as in AspectJ, isdescribed. In particular, the variations needed to express in a state machine weavingthe meaning of before, after, and around with proceed advice are outlined. Workremains to fully capture the intended semantics, and is one area of future work thatwill directly support the results here.

The notion of reasoning about systems composed from two or more state ma-chines is not new, and the most prevalent method for doing so is the assume-

38


guarantee paradigm, which forms the basis of this work. In [5] and [22], amongothers, an assume-guarantee structure for aspect specification is suggested, similarto the specifications here, but model checking is not used. In [5], proof rules aredeveloped to reason in a modular way about aspect-oriented programs modeled asalternating transition systems; the treatment is for a particular base program incombination with an aspect. And in [22], aspects are examined as transition systemtransformers, but a verification technique is not introduced.

In most model checking works based on assume-guarantee, the notion of com-positionality is one in which two machines are composed in parallel. Composingmachine M with M ! yields a machine in which composed states are pairs of originalstates that agree on atomic propositions shared by the two machines. The work of[10] introduced tableaux to modular verification. In [17], the complexity of modularmodel checking in this regime is investigated. Under the parallel composition model,no issue analogous to aspect invasiveness arises, because the machines are combinedaccording to jointly-available states.

An interesting discussion on the “pragmatics” of using such verification for re-active systems can be found in [19]. Although the work was done significantly priorto the development of aspects, many of its conclusions are supported and reflectedhere. For example, the assertion that “some way of referring to the past is veryhelpful in any compositional approach” prefigures the operation of pointcuts.

An alternative mode of verification for composed systems is presented in [2],where the subject is feature-oriented programs that are built from collections ofstate machines that implement di!erent features within a system. Consequently,this framework uses a weaving-like process of adding edges between initial and re-turn states of individual machines, but these feature machines explicitly receive andrelease control over the global state, unlike the oblivious base machine in aspect-oriented systems.

39


Chapter 7

Conclusions

By reusing the notion of a tableau that contains all possible behaviors that satisfy aparticular formula, we can achieve a modular verification for aspects. The approachis based on augmenting this tableau with the advice according to a pointcut descrip-tor and examining the result. In order to do so we must restrict our view to aspectswhich are weakly invasive and always return to states which were reachable in theoriginal base system, and we take a liberal view of fairness in which any computationthat infinitely often visits an aspect state is considered fair.

A number of directions for future work present themselves quite clearly. Whilethe current technique only addresses a single aspect and pointcut descriptor, inprinciple it can be extended to work for multiple aspects, given proper definitionsof the weaving mechanics. In fact, we can already express multiple logical pointcutsand advice bodies by using a disjunction in our pointcut descriptor, and providingseveral advice initial states leading to di!erent, unconnected advice sub-machines.However, this requires us to specify and verify all aspects together, contrary to theprinciple of modularity.

Further development of how weaving is formulated will also allow treatment ofcases where advice introduction changes the set of joinpoints selected by a pointcut,overcoming the restrictions of a two-step weaving where machines are first madepointcut-ready. The use of a ‘rolling’ weaver, where paths are examined in a step-by-step fashion, applying advice where pointcuts are matched, might be one solution.And taking the more sophisticated view of pointcut descriptors as automata hasalready yielded good results in other works noted in the previous chapter.

Additionally, the entire discussion here is given in terms of states and statemachines, while, as noted earlier, the usual basic vocabulary of aspect-orientedprogramming talks about events during program execution, with respect to whichadvice is executed before, after, or around. The language-level aspect terminologyand problems of real object systems still must be fully expressed in the state-basedmodel checking used here. This is a matter of developing the right semantics and

40


model structures to be used when generating tableaux (and aspect machines) thatcan be woven accordingly.

Finally, this work has only yielded a verification algorithm for aspects that areweakly invasive. Although, as we have argued, many interesting aspects do indeedfall into this category, we would naturally like to eliminate this restriction. Of noteis that fact that our LTL tableau, before restricting it to the reachable component,contains complete information about both the property for which it was generated,and that property’s negative. By making use of the unreachable portion of thetableau, it may be possible to develop a modular verification for strongly invasiveaspects. One might imagine that invariants or other su"cient conditions could begenerated that a base system would have to satisfy even in previously unreachablesections, or that would be demanded of aspect return states, even if they couldreturn to unreachable states in the base machine.

Despite these restrictions, the generic proof method in this paper allows us forthe first time to model check aspects independently of a concrete base program,and already the maven modular aspect verifier can provide useful results. Thistechnique is a significant step toward the truly modular verification of aspects.

41


Bibliography

[1] E. Abraham, F.S. de Boer, W.-P. de Roever, and M. Ste!en, An assertion-based proof system for multithreaded Java, Theoretical Computer Science331 (2005), no. 2-3, 251–290.

[2] C. Blundell, K. Fisler, S. Krishnamurthi, and P. Van Hentenryck, Pa-rameterized interfaces for open system verification of product lines, Proc.19th IEEE International Conference on Automated Software Engineering,ASE’04 (Washington, DC), IEEE Computer Society, 2004, pp. 258–267.

[3] Doron Bustan, Alon Flaisher, Orna Grumberg, Orna Kupferman, andMoshe Y. Vardi, Regular vacuity, Proc. of Correct Hardware Design andVerification Methods, CHARME’05 (Dominique Borrione and WolfgangPaul, eds.), LNCS, vol. 3725, Springer, 2005, pp. 191–206.

[4] E. M. Clarke, Jr., O. Grumberg, and D. A. Peled, Model Checking, MITPress, Cambridge, MA, 1999.

[5] B. Devereux, Compositional reasoning about aspects using alternating-time logic, Proc. of Foundations of Aspect Languages Workshop(FOAL03), 2003.

[6] R. Douence and M. Sudholt, A model and a tool for Event-based Aspect-Oriented Programming (EAOP), TR 02/11/INFO, Ecole des Mines deNantes, 2002.

[7] E. Dror and S. Katz, The architecture of the CAPE, Technical ReportAOSD-Europe-Technion-4, AOSD-Europe, February 2006, Available athttp://www.aosd-europe.net.

[8] Robert E. Filman, Tzilla Elrad, Siobhan Clarke, and Mehmet Aksit (eds.),Aspect-Oriented Software Development, Addison-Wesley, Boston, 2005.

[9] M. Goldman and S. Katz, Modular generic verification of LTL proper-ties for aspects, Proc. of Foundations of Aspect Languages Workshop(FOAL06), 2006.

42


[10] Orna Grumberg and David E. Long, Model checking and modular verifi-cation, ACM Transactions on Programming Languages and Systems 16(1994), no. 3, 843–871.

[11] J. Hatcli! and M. Dwyer, Using the Bandera Tool Set to model-checkproperties of concurrent Java software, Proc. 12th Int. Conf. on Concur-rency Theory, CONCUR’01 (K. G. Larsen and M. Nielsen, eds.), LNCS,vol. 2154, Springer-Verlag, 2001, pp. 39–58.

[12] K. Havelund and T. Pressburger, Model checking Java programs usingJava PathFinder, International Journal on Software Tools for TechnologyTransfer (STTT) 2 (2000), no. 4, 366–381.

[13] S. Katz, Aspect categories and classes of temporal properties, Transactionson Aspect Oriented Software Development, Volume 1, LNCS 3880, 2006,pp. 106–134.

[14] S. Katz and M. Sihman, Aspect validation using model checking, Proc. ofInternational Symposium on Verification, LNCS 2772, 2003, pp. 389–411.

[15] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G.Griswold, An overview of AspectJ, Proc. ECOOP 2001 (J. L. Knud-sen, ed.), LNCS 2072, Springer-Verlag, 2001, http://www.aspectj.org,pp. 327–353.

[16] S. Krishnamurthi, K. Fisler, and M. Greenberg, Verifying aspect advicemodularly, Proc. SIGSOFT Conference on Foundations of Software Engi-neering, FSE’04, ACM, 2004, pp. 137–146.

[17] Orna Kupferman and Moshe Y. Vardi, An automata-theoretic approach tomodular model checking, ACM Transactions on Programming Languagesand Systems 22 (2000), no. 1, 87–128.

[18] NuSMV, http://nusmv.irst.itc.it/.

[19] A. Pnueli, In transition from global to modular temporal reasoning aboutprograms, Logics and Models of Concurrent Systems (Berlin) (K. R. Apt,ed.), Springer-Verlag, 1985, pp. 123–144.

[20] Ruby, http://www.ruby-lang.org/.

[21] M. Sihman and S. Katz, Superimposition and aspect-oriented program-ming, BCS Computer Journal 46 (2003), no. 5, 529–541.

43


[22] H.B. Sipma, A formal model for cross-cutting modular transition systems,Proc. of Foundations of Aspect Languages Workshop (FOAL03), 2003.

44


Appendix A

FSMA Aspect Specifications

The specifications below are in the same format as that used by the NuSMV 2.3User Manual. The following expressions are defined there:

<RET> A newline.

atom A symbolic constant.

type A type specifier.

simple expr An expression containing current state variables only, thus representinga set of states.

next expr An expression containing (and usually relating) current and next statevariables, thus expressing a set of transitions.

ltl expr An expression containing LTL temporal quantifiers and logical connectives.

FSMA files

The syntax of a FSMA file containing the specification and model for a singleaspect is:

aspect :: [ base var ][ aspect var ][ pointcut ][ init ][ trans ][ return ][ base spec ][ augmented spec ]

45


Base machine variables

base var :: “VAR --BASE” <RET>atom “:” type “;”atom “:” type “;”...

Aspect machine variables

aspect var :: “VAR --ASPECT” <RET>atom “:” type “;”atom “:” type “;”...

Pointcut descriptors

The use of a simple expr in this definition restricts pointcuts to examine thecurrent state only.

pointcut :: “POINTCUT ” simple expr “;”

Aspect machine initial states

init :: “INIT ” simple expr “;”

Aspect machine transitions

trans :: “TRANS ” next expr “;”

Aspect machine return states

return :: “RETURN ” simple expr “;”

Base system requirements

base spec :: “LTLSPEC --BASE” <RET> ltl expr “;”

Augmented system results

augmented spec :: “LTLSPEC --AUGMENTED” <RET> ltl expr “;”

46


Appendix B

Messages Example FSMA Source

Each version of the error alert messages example is given in its entirety; the discus-sion in Section 5.3 highlights the di!erences between successive versions.

Version 1

1 VAR --BASE2 error : boolean ;3 act : { send, rcv } ;4 msg : { normal, alert } ;5 VAR --ASPECT6 pc : 1..2 ;7 POINTCUT8 error ;9 INIT

10 pc = 1 ;11 TRANS12 pc = 1 -> next(pc = 2) & next(act = send) & next(msg = alert) ;13 RETURN14 pc = 2 ;15 LTLSPEC --BASE16 G ((act = send & msg = normal) -> F (act = rcv & msg = normal)) ;17 LTLSPEC --BASE18 G ((act = send & msg = alert) -> F (act = rcv & msg = alert)) ;19 LTLSPEC --AUGMENTED20 G (error -> F (act = rcv & msg = alert)) ;

47


Version 2

1 VAR --BASE2 error : boolean ;3 act : { send, rcv , idle } ;4 msg : { normal, alert } ;5 VAR --ASPECT6 pc : 1..2 ;7 POINTCUT8 error ;9 INIT

10 pc = 1 ;11 TRANS12 pc = 1 -> next(pc = 2) & next(act = send) & next(msg = alert) ;13 RETURN14 pc = 2 ;15 LTLSPEC --BASE16 G ((act = send & msg = normal)17 -> X ((act = idle) U (act = rcv & msg = normal))) ;18 LTLSPEC --BASE19 G ((act = send & msg = alert)20 -> X ((act = idle) U (act = rcv & msg = alert))) ;21 LTLSPEC --AUGMENTED22 G (error -> F (act = rcv & msg = alert)) ;

48


Version 3

1 VAR --BASE2 error : boolean ;3 act : { send, rcv , idle } ;4 msg : { normal, alert } ;5 VAR --ASPECT6 pc : 1..2 ;7 POINTCUT8 error ;9 INIT

10 pc = 1 ;11 TRANS12 pc = 113 -> next(pc = 2) & next(act = send) & next(msg = alert) & next(!error) ;14 RETURN15 pc = 2 ;16 LTLSPEC --BASE17 G ! ( error & (act = idle )) ;18 LTLSPEC --BASE19 G ((act = send & msg = normal)20 -> X ((act = idle) U (act = rcv & msg = normal))) ;21 LTLSPEC --BASE22 G ((act = send & msg = alert)23 -> X ((act = idle) U (act = rcv & msg = alert))) ;24 LTLSPEC --AUGMENTED25 G (error -> F (act = rcv & msg = alert)) ;

49


!"#$%&' () "*(+,+- .+-"'

/-,(+0 &$-



!"#$%&' () "*(+,+- .+-"'

!"#$ %& !'()#

!*'+, +%("% +'-)!., %- )"%# )'%)$ /-%(-#$, )&.$( /)&.$% !01)2$

/-,(+0 &$-

%*!-)% )2'%'340 5'4$ — 5')340, 031% -2',2006 )3') ,6)# '71-+ 8'$+


.(-#$, )&.$% ,0%'"6( 974 %*'$- :6'!6 +))#3,( ,-&3 !"#$,.)+'$%+-,( ,().3, +)614, ,4)$+, %& AOSD-Europe-%' 5')340% ,.'$ )3*


!"1"12 /3+.

1 ."(01'4 *"5$.

2 6-,$6 1

2 . . . . . . . . . . . . . . . . . . . . . . . . /)0"61* ,#3'$ +'34)+ 1.13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . )%$!'6 +'$)* 1.24 . . . . . . . . . . . . . . . . . . . . . /)0"61* %- )!%'.'$ +'$)* 1.35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +'*;'+ 1.4

7 .+*,06+ 2$* 2

7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LTL '%(0 2.18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /)0"61* 2.29 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . !'-)" )0").!6 2.39 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +');")6);61 2.4

10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,2)!* 2.511 . . . . . . . . . . . . . !'-)" 0").!6% ,34'$ ,3'4$ +))3( 2.5.112 . . . . . . . . . . . . . . . . . . . . . +(%'-$ ,3'4$ +))3( 2.5.213 . . . . . . . . . . . . . . . . . . . ,-%# ,!';( /))3-%'6 /)0"61* 2.6

14 .+-"' !."*+0(' 3

15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +'3'43 3.118 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *$2'. 3.2

23 )+-"- 4

23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5'4)+ 4.126 . . . . . . . . . . . . . . . . . . . . . . . . . . . . maven 1'6)0-(* 4.2

29 (2+%4 .+'-0+, 5

29 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2-% ,!8# 5.130 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,6'"( ,#3, 5.233 . . . . . +').23 +'*$2'. #'+)3 %& !"#$ ,!"$ :+'*)2- %& +'&!+, 5.3


38 !+7.4 .+,+42 6

40 .+1$&- 7

42 6"%*0+"(4"4

45 FSMA !"#$%&' .+"5$"%"5%& '

47 .+2*.66 .-0+,( FSMA ,+$ 4


!"*+"' .-")*

0").!6' 5'+3, M-, !'(& M! !'-)" 0").!6% ,34'$ ,3'4$ +))3( 2.111 . . . . . . . . . ! = a ! Y b ! Y Y b !(&( LTL ,#1'3 ,!';( !'-)"

/))"- #)0(,% ).4 (/)30" /)(;$) /)32', /)%'%1$( -'$)-, 3.116 . . . . . . . . . . . . . . (s!i"1, s

!i) !(&$ %)4$- (!'6*() 52', %'%1$

19 . . . . . . " = A G!!¬a ! b

"" F a

"!'(& T" '%(0 %- 2)-), "%#, 3.2

19 . . . . . . . . . . . . . . . . . . . . . . . . A ,0'-6 0"61* +3'4$ 3.320 . . . . . . # = A G

!!a ! b

"" X F a

"+* "61$- #T" (%'-$ '%(0 3.4

22 . . . . . . . . . . . . . . . . . . . . . . . M |= " +#* 1)1( +3'4$ 3.522 . . . . . . . . . . . . #M |= # ,*;'+ !;') ! )6% A /& M %- ('%)-, 3.6

24 . . . . . . . . . /)%.'$ ,#3'$ +'$)* )%4 %- -'$)$% ,$)!8 /)-!+ 4.124 . . . . . . . . . . . .'" ,#3'$ +'$)* )%4 %- -'$)$% ,$)!8 /)-!+ 4.226 . . . . . . . . . . . . . . maven 1'6)0,-(* -'$)$% ,$)!8 /)-!+ 4.3

30 . . . . . . . . . . . . . . . . . . . . . . . . . . 2; +$2'.% FSMA .'" 5.132 . . . . . . . . . . . . . . . . . . . . . . . ,#3, +$2'.% FSMA .'" 5.233 . . . . . . . . . . . . . . . . . ,#3, +$2'.% maven +'$)* +'*;'+ 5.335 . . . . . . . . . 1 ,1!)2 ,+'*)2- +'&!+, 0"61* !'(& +).23 *$2'. 5.436 . . . . . . . . . 2 ,1!)2 ,+'*)2- +'&!+, 0"61* !'(& +).23 *$2'. 5.5


*"5$.

.'" +'.)#) /, /)0"61* ./)0"61* %- /+'3'43 %- ,#4',% ,0)- ,2);$ '8 ,.'(&,-)2 .+4!&$ %- /)(! /)()4!$ <!. (#'!% /)4+'#- /)3))3&( %60% +'%'4)- +'.!63+'")340' +'6-( ,#+'6 8*$' ,Java %- [15] AspectJ ,(#!,( ,3'-*!% ,2;', '8.1)1( +34+ /& ,!"0*+'- '* ,/)(%'-$ /)0"61* ,/)0"61* ,#3'$ +'34)+( .+'3'-,;&, %& )+$ %- !'*)+ 5,' ,652 *!"3, ,'%- 5))3&% <)'-$, .'", +* 5, %)4$ 0"61*+')$3)., +'.'"3, 5+'* +* ,,8$ !'-)", 0").!6 .*+)"$ #$",*% *!"3, ,%'&6%+)34+ %- ('%)-, .*+)"$ .+,+$1 5$-- ,,;&, %&6'+ ,( !-* +)34+ %- ,&';)((

..4(+)- +)34+ *!"3 ,2)!* ).) %& /)0"61* !+') '* .#* /& .#) 1)1(

+'3'4+, +* /)"61$ /)0"61*- +$*% +3$ %& ,-).# +)%$!'6 ,-)2 /)!).2$ '3*+'#3,, +* +'"61$- 1)1( +')34+ /& /)2!'*$ /, !-*4 +'(%'-$ +'4!&$% +')';!,!'-)" )0").!6 )%&( !+') '* .#* 0"61* ,1)1( +)34+ ,3'+3 !-*4 ./)0"61*, %-+(%'-$ +)34+ !';)% ,!0$( '%* /)()4!$ %- ').#) ,2)!*% ,0)-' ,/,%-$ ,;&'+").( +'0)- +'&;$*( '8 +(%'-$ +)34+ %- +'3'4+ +$*% /)%'4) '3* )4 !'!( ,+#*

.+'%)2!, %.'$,

)*$;& 56'*( 0"61* %4 "'.(% 5+)3 ,( +)!%'.'$ ,-)2( +*8 +$'&% -$+-3 /*/& .#) 2'!*, 5'+3 0"61*% /)6"+, +'$)* +'*;'+% &)2,% %4'3 ,1)1( +)34+%"! +'$)* /'"$( ,')+'#3, +* +'"61$, 1)1(, +')34+ +;'("$ 1)1( +)34+ %4+'(%'-$ +'4!&$% %.'$ +'").($ /)&3$3 '3* ,=1'3( .,3'+3 +#* 1)1( +)34+ !'(&!-",( +)-&3 '8 +)!%'.'$ +'$)* +!'; ./)(;$ 9';)6 %- ,)&(% /!'2 5%.'2 !-*:(LTL) +)!*)3)% +)%*!'6$0 ,")2'%( +'*#1'3 2'84 !.2'$, 0"61* %- ,);")6);61%

%'4) 0"61*,- 1)1( +3'4$ %4 )(2% 0"61* %- +'#3,, +* ,!).2$ " ,#1'3 •.,)%* 2!*'$ +'),%

+3(3, +(%'-$ ,3'4$ %4 ).) %& '"6'1)- +')';!, +'*;'+, +* ,!).2$ # ,#1'3 •." ,#3,, +* +$))"$- 1)1( +3'4$ /& .#) 0"61*, %- ,2)!* +'&;$*(

+!.2'$ 0"61* %- '+;& ./)0"61* %- (;$ +'3'4$ )%.'$ %& 11'($ +'$)*,/)(;$ +;'(" (;$ +3'4$ %- /)%)2!, /)()4!$% =1'3( ,( !-* ,A (;$ +3'4$4-) 0"61*% .!,('+ '%* /)(;$ +!0$ ,2)!*, +!.2,( ./)!(&$ /,$ 5)*- /)!8'#


*', ! !'-)" 0").!6 .+)0!"3'" ,!.2, /)3+'3 *% '3* '% !-* ,!'-)" 0").!6 =*+'!)#( .(%'%1$ ='1 5'24) (;$ )3'$)1 %- +)6'1 ,!.)1 ='1% /)*+$ !-* 0").!6+'%)4$, LTL %'%1$ +'*#1'3 +'),% +'%'4) !'-)" )0").!6 !'(& 5'$)1% +')!-6*

./))!%'2! /))'0)( '* ,!(& %- /)%!'6$0 /)!'0*!6'* "!

+4!&$ +*;'+' ," 1)1( +4!&$ +-)!. ,! !'-)" 0").!6 /& 5'+3 A 0"61* !-*4/)$))"$, /)('-)#, %4 +* +2;))$, ,+(4# +*!"3, ,,3'4$ /)3'( '3* ,# +(%'-$(;$ +3'4$ %("3 .'8 ,3'4$ <'+% A ,;&, +* +2;))$, ,3'4$, +* /)2!*$' ," +*<4 ,# +* +"61$ /)%("$ '3*- +(%'-$, ,3'4$, /* )4 ,*!3 '3* .+)!32 +(%'-$T" '%(0, ." +* +"61$- 1)1( +3'4$ %4$ +)3(3, +(%'-$ ,3'4$ # +* "61+ /2/)-$+-$ '3* ." +* /)"61$ !-* /)%'%1$, %4 +* ")'.$( +%%'4 # LTL ,#1'3%./- +'#4'$ /)'(%0 %- +'%)&'$, +')03(%!, +'3'4+,' ,[4]-( ,3'+3, T" %- ,!.2,(

0").!6 )6% A 0"61* /& ('%(0, ,5*4) B 1)1( +3'4$ ('%)- .*.8 ,,2)!*, <)%,+0").!6% 1)1(, +3'4$ +* /)3)4$ '3* 5'-*!, (%-( ./)(%- )3-( ,-&3 ,! !'-)"/)*+,% *% '* /)*+,% )'-& 1)1(( 5'+3 (;$- *), ,)&(, )%%4 56'*( .!'-)",/& ,3'4$ !';)% +3$ %& .')%& '&)2, '+'&;$*( %'%1$% /*+,( !'-)", 0").!6%0%#'$ 56'*(- '* (;$ %4 ,( <* ,LTL-( +')'2,3+, 5+'* 54' ,/)%'%1$, /+'* "').()"%# %- ,1)!6 /)&;($ '3* ,!'-)", 0").!6 +* "61$ *% 0%#'$ 56'*( '* "61$/)(;$, ,B! +*!"3, ,+%("+$, ,3'4$( .!'-)", 0").!6% /)$)*+$ !-* %'%1$

.pointcut -.# 5$)1( /)3$'1$ !-% /)$)*+$,

,3'4$ /)!;') /;&( '3* <4 .+)3(3 $B +(%'-$, ,3'4$, ,,2)!*, %- )3-, (%-(/)!(&$, %4 +* "').( ,%)4$ /)!(&$, ,);%! !-* ,A-' B! %- /)(;$, %4 /&/))+%#+,, /)(;$, %4% /)!(&$ "! -) B!-( pointcut )(;$%- <4$ 9'# ,A-' B!-$B!-( /)(;$, %4% /)!(&$ /3-) A-( ,!8# )(;$%' ,/)$)*+$ /)3'$)1 /,(- A %-,);%!( 5( -) $B-( (;$ %4% ,( +#* *), +#%;'$ ,2)!* ./)$)*+$ /)3'$)1 /,(-#T" /* ,T" '%(0 5'+3' ,#-' ," ,! ,A 5'+3 :,3), ,-)2, %- +)84!$, ,30, ./)!(&$,M %4% 8* ,#T" |= # /* 8* ,! )6% A /& T" %- 2)-), "%#, %- ,2)!* %- ,*;'+ *',

. #M |= #-- <4 #M +(%'-$ ,3'4$ .)$+ !';)+ ! )6% A /& M +2)!* ,M |= "-- <4

"1)(+% *!"3, /)0"61* %- !+')( (#! 2'1% '8 ,3&0 %- ,+'3'4'3 +* /)#)4'$ '3*/)2)-) /)(;$% "! /)!(&$ -) ,9'&)$ /)!8'#-4 ,,84 0"61*( .[13] 6)(7 6*+54+3'4$ %- /)2)-) )+%( /)"%#% !'8#% )'-& 0"61* '8 ,%(2$ *%% .1)1(, +3'4$(%& ,-"$ '8 ,.('& ." ,#3,, +#1'3 ).) %& +%(2'$ ,3)* ,+'2,3+, !-* 1)1(,!"#$% /'#+ ,3), +')%%4 +'!8# /)-!$ 54- /)0"61*% ,%%4, <* ,+)!%'.'$ ,()-#/)0"61* %%'4 ,,-%# ,!';( /)-%'6, +)!'20" <'+( /)%6'3 /)(! /)0"61* .).)+&/)%)(2$ /)0"61*' ,1)1(, +4!&$ %- ,(;$ +* /)3-$ /3)* /&6 =* !-* /)6)"-$!-* )3-%'6 0"61* %4% =1'3( +*8 ..(%( /)2)-), /)(;$, +;'(" +* /)%)(2$ !-*56'*( ,%4) 1)1(, +4!&$- /)4!&, #''0 <'+( /3), 1)1(, +4!&$$ &.)$% /)'3)-,+;'(" ,54% .,3'- 0%" /& '* )!$2% !#* 56'*(- +'!$% ,,$;&( ')%& &)2,% )+!'*+/)*('$ /"%#' ,/)(! /)3))3&$ /)0"61* +%%'4 ,-%# ,!';( /)-%'6, /)0"61*,


'%- !'-)", 0").!6 !-* .#* 0"61*% 5*4 /)%(2'$ =* '3* .'8 ,.'(&( +'*$2'.4)0").!6 '* .#)( /)0"61* !61$( /)%60$ '33)* ..(%( 1)1(, +4!&$% /*+'$

.9'&) +61'+$ /)&6-'$, !'-)"

-'$)$% 1'6)0-(* '3#+)6 ,'3%- +'$)*, /+)!'2%* %- '+#4',' '+!.2,% =1'3(-$+-$ maven .NuSMV %.'$ ".'( %& 11'($ ,8 1'6)0-(* .maven *!"3, ,,-)2,+* ".'(' ,0"61* +2)!* &;($ ,LTL '%(0 +'3(% NuSMV %- ltl2smv ()4!$(+!-6*$ ,FSMA ,,8 1'6)0-(* %- 0%", +61 .NuSMV-% ,*)!" ).) %& ,*;'+,/)0"61* %- +'*$2'. !61$ ./,%- +');")6);61, /& .#) (;$ +3'4$ )0"61* 0!6%/)11'($, /)0"61* %- /)!'*)+ .5*4 /)2;'$ /"%#' ,maven +'&;$*( '".(3+'&;$*( (;$ +3'4$% /)$2!'+$ +'),% /)%'4) ,AspectJ %-$% ,+'34)+ +6- %&..'" %& /)11'($ /)0"61* %- )!32 )!%'.'$ +'$)* &;(% 5+)3- <4 ,/)$))" /)%4.)$+%' .#* +'$)*% ,3'-*!, *$2'., ,3), 5*4 ,2;',- ,#4',% +)!32, ,0)-,,+(%'-$, +4!&$, +").( *%% 0"61*% "! 1#))+$ +'$)*, ,(- ,/)0"61* %-+* 2);$ maven 1'6)0,-(* .+$)'1$ 1)1( +4!&$ /& .#) 0"61*, +").( *%%')+)-&+' )+)$* )!%'.'$ +'$)* +*!"% ('-# .; ,'',$ '8 ,0)- .+'*;'+, +')-'$)-

./)0"61* %-


Documents

Mo dul ar V eriÞcat io n of Asp ects … · Mo dul ar V eriÞcat io n of Asp ects Max Gol dma n Technion - Computer Science Department - M.Sc. Thesis MSC-2006-23 - 2006