Verifying Scenario-Based Aspect Specifications

Verifying Scenario-Based Aspect Specifications Emilia Katz

Verifying Scenario-Based Aspect Specifications Research Thesis Submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science Emilia Katz Submitted to the Senate of the Technion Israel Institute of Technology Shvat 5766 Haifa February 2006

The research was done under the supervision of Prof Shmuel Katz in the department of Computer Science The generous financial help of the AOSD-EUROPE Network of Excellence is gratefully acknowledged I wish to express my sincere gratitude to my supervisor Assoc Prof Shmuel Katz for his guidance and kind support

Contents Abstract 1 1 Introduction 2 11 Scenario-Based Specifications 2 12 Aspects and Scenarios 2 2 Related Work 6 21 Specifying and Verifying Systems with Aspects 6 211 Specifying Aspects by Scenarios 6 212 Modular Verification 6 22 Verification of Conformance for Non-Aspect Systems 7 221 Theorem Proving 7 222 Model Checking 8 3 Background on the CNV Tool 9 4 Verification of Systems with Aspects 12 41 Defining The Problem 12 42 Recognizing the Pointcuts: Four Options 14 43 Ensuring the Appearance of the Aspects 15 44 Arranging Non-Aspectual Scenarios 18 45 Proving Soundness 20 5 Example Description 26 6 Implemented Examples 30 61 ATM System Example 30 62 Buffer System Example 32 621 Checking Producers Performance 33 622 Detecting Risk of Overflow 35

7 Implementation Details 37 71 Extended CNV Tool Implementation 37 711 Using the Extended CNV 37 712 Extended CNV Structure 39 72 Complexity 40 8 Future Work 42 81 Full Treatment of Nested Aspects 42 82 Treatment of Before Advice 43 9 Conclusions 44 Appendix A: CNV Input File for ATM Example 47

List of Figures 61 ATM system pseudocode 31 62 Buffer system pseudo code - first try 33 63 Buffer system pseudo code - corrected version 34 64 Buffer system with longer advice - pseudo code 35 71 Time consumption of the verification when run on 4GB Linux machine (P4 with 32MHz cpu) 41

Abstract Software systems specifications are often described as a set of typical scenarios Some of the desired scenarios are crosscut by other requirements called aspects also naturally described as scenarios Aspect descriptions are independent of the description of the non-aspectual scenarios but the crosscutting relationship between them has to be specified so for each aspect a description of its join-points is provided When aspectual scenarios are added to the system we need to prove that every execution is equivalent to one in which the aspectual scenarios occur as blocks of operations immediately at their join-points and all the other operations form a sequence of non-aspectual scenarios interrupted only by the aspectual scenarios The verification process consists of three parts First the join-points of the aspectual scenarios are found Then we prove that each execution is equivalent to one in which the aspectual scenarios are applied correctly and the last part is to prove that the non-aspectual scenarios can indeed be formed into blocks interrupted only by aspect advices We extend an existing method of automatic verification for nonaspect systems to the case of systems with scenario-based aspect specifications A prototype implementation based on Cadence SMV is also extended accordingly and an efficient optimization is provided though not forced on the user 1

Chapter 1 Introduction 11 Scenario-Based Specifications Often when describing a system it is natural to think of its desired behavior as a collection of finite sequences of events called scenarios That can be done by using use-cases or sequence charts of UML [18] or the variant of Live Sequence Charts (LSCs) defined in [6] For example let us think of an ATM system of a bank consisting of one central computer with a database asynchronously communicating with several ATM machines It would be natural to describe the system behavior as possible scenarios such as money withdrawal bill payment or checking the account balance System computations in which only the described scenarios occur one after another in some order obviously satisfy such a specification and will be called convenient (using the notion of [4] [5]) However an execution of the system does not have to consist of the scenarios only because sometimes computations differ only in that independent operations occur in a different order Moreover often operations of one computation can be re-ordered by exchanging places of independent operations in such a way that a convenient execution is obtained In that case the original execution and the obtained convenient one are considered equivalent A system conforms with a scenario-based specification if every computation is equivalent to a convenient one 12 Aspects and Scenarios When stating requirements for a system behavior it is often the case that some of the requirements crosscut the others Those crosscutting requirements are called aspects The best way to deal with crosscutting requirements is to model them separately from other requirements and then weave them into the main system in programming notations like AspectJ [11] For each aspect a set of join-points called 2

a pointcut is defined identifying the states where the aspect code (called advice) should be executed When it is natural to describe a system by a scenario-based specification (eg for communication protocols or electronic funds transferring systems) aspects such as security privacy or monitoring are also naturally described as scenarios This approach is seen in [2] and also used here Thus a specification of a system is a set of scenarios and aspectual and non-aspectual scenarios are described independently In our bank system example above several aspectual scenarios might be needed For example we might need to count all the ATM operations for every account in order to make the client pay for the operations performed This concern is naturally solved by introducing an aspect scenario that will be run any time an ATM operation is completed successfully The join-points of this scenario will be all the places in the system executions at which the last operation of the money-withdrawal scenario the bill payment or the scenario of checking the account balance is performed To treat this aspect the state of the system will be extended by a set of new variables - a counter for each account Applying the aspect scenario changes only the value of the counter and does not affect the projection of the state on the previously defined ATM system: if the scenario is applied at some state s of the system execution after the aspect finishes to run the system will pass to a state s that differs from s by the value of the counter only Such an aspect is called spectative as defined in [20] and in [10] where the categories mentioned below also appear Another example of a cross-cutting requirement might treat communication failures: when a failure is detected the interaction of the user with the relevant machine is stopped the magnetic card is returned and a warning message appears After applying this scenario the ATM system will not return to the state it was before but will return to its initial state - waiting for a magnetic card to be inserted Thus it is a regulative aspect changing the control of the system Aspects can also be categorized as invasive Such an aspect changes the state of the original system but if it appears in the middle of some non-aspectual scenario the scenario proceeds after the advice finishes That is the case for example if we want the user to immediately pay for every ATM operation After applying such a scenario the amount of money in the user s account will change but the interrupted scenario will proceed from the place where it was interrupted We are interested in the verification of systems containing aspects i e systems where the code implementation of aspects is already woven in Actually it would be better to separate the aspects from the base system both in the description and 3

in the verification but unfortunately sometimes this is impossible One example of such a situation is a system that does not use any aspect-oriented language at the implementation stage Another possibility is that our goal is to check the weaver itself and thus we need to examine the result of its application which is the system with the aspect code woven in Also when there are complex interactions between the aspect code and the original program techniques do not exist to separately analyze the aspect In those cases the verification of the augmented system as a whole is necessary For such an augmented system the definition of the convenient executions should be refined The new convenient executions are those in which the aspectual scenarios appear always as (possibly nested) blocks of operations and exactly at the place they are needed The non-aspectual scenarios also appear as a block but with one difference: each block can be interrupted with blocks of the appropriate aspectual scenarios Depending on the aspect description the interruption can either cancel the continuation of the interrupted scenario (then it will be called strict interruption) or let the scenario proceed possibly after some invasive changes (then it will be called a weak interruption) In a general execution the operations of an aspectual scenario might not appear immediately after a join-point and could be interleaved with some other operations of aspectual or non-aspectual scenarios So in order to prove that a system conforms with a scenario-based specification that includes aspectual scenarios it is enough to show that every computation is equivalent to a convenient one (where the definition of the convenient executions is refined as above) We extend the model-checking approach and the CNV tool in [5] (described below in Chapter 3) with key modifications to automatically verify conformance of systems containing aspects with scenario-based specifications Our extension also supplies an optimization of the verification process for systems containing aspects This optimization enables us to perform the verification in two distinct and independent stages which reduces the size of the model to be model-checked and thus considerably reduces the verification effort in both time and space Note that unlike some attempts for verification of aspects that restrict themselves to spectative aspects only [12] we do not pose such a restriction We also treat nested aspect advices but in this version we do not treat the case of nested strictly-interrupting aspects (i e the case when a strictly-interrupting aspect is applied on other aspects) Meanwhile we also restrict ourselves to after advices only which are advices defined to be applied after their corresponding pointcut though later in Chapter 8 a way of treating before advices will be also discussed (The before advice analogously to after advice is defined to be applied before its corresponding pointcut A more 4

formal definition of the after and before advice appears later in Chapter 4) This treatment is possible but not yet implemented Our method consists of three parts 1 First of all the join-points of the aspectual scenarios are found 2 Then we prove that each execution is equivalent to one in which all the aspectual scenarios appear as blocks immediately at the corresponding join-points For that purpose appearance of the appropriate aspectual scenario is predicted at each join-point This kind of prediction will be fulfilled only if the needed aspectual scenario indeed appears somewhere in the continuation of the execution and it could have appeared immediately at the join-point (ie all the operations of the aspect scenario are independent of all the other operations occurring between the join-point and the actual occurrence of the aspect operations in the advice) 3 At last we show that if we ignore the appearance of the aspectual scenarios operations in the executions and perform each aspectual scenario as a whole at its join-point every such execution is equivalent to one in which the operations of the non-aspectual scenarios are organized as blocks Here we also need to notice that additional legal non-aspectual scenarios are defined in the system to treat the case of strictly-interrupting aspects: for each prefix of each previously specified scenario if the last operation of this prefix is a possible last operation of a pointcut of some strictly-interrupting aspect a new legal scenario is defined It consists of the above prefix in which the last operation is marked as the last operation of that pointcut The verification of the last two parts is done in two distinct stages That can be performed in either order The division to these stages is not necessary from the theoretical point of view but appears to bring a considerable optimization of the verification process The importance of such an optimization will be seen in Chapter 7 This thesis is organized as follows: In Chapter 2 an overview of existing works in verification of aspect-containing systems and in verification of non-aspectual scenario-based specifications appears and some basic definitions needed for equivalencebased verification are given Background on the earlier CNV tool is given in Chapter 3 In Chapter 4 we present our method of verification for systems with aspects and present the soundness proof An application example explained in more detail appears in Chapter 5 and some implemented examples are described in Chapter 6 Implementation details are discussed in Chapter 7 and some possible extensions of our work are described in Chapter 8 together with the ideas of their practical realization We conclude in Chapter 9 5

Chapter 2 Related Work 21 Specifying and Verifying Systems with Aspects 211 Specifying Aspects by Scenarios The need to describe aspects by scenarios arises for example when specifying reactive systems In those cases the non-aspectual parts of the system are also described by scenarios Such is the motivation of [2 21] for considering scenario-based aspect specifications The goal of that work is early detection of conflicts and contradictions between the aspectual and the non-aspectual parts of the system specification where the system is specified by scenarios The authors propose an algorithm to detect the above incompatibilities at the requirements analysis stage of the software development cycle before the specified system is actually constructed 212 Modular Verification In [12] a way is presented to verify the base system and the aspects separately from each other Such modularity is obviously desired in many cases but the results of [12] can be applied only to a rather restricted class of programs: The aspects end in the same state as at the join-point (either are spectative or change the values back to those before the advice) The pointcuts are all defined by the state of the call stack Only preservation of properties can be verified (i e CTL properties true for the base system are shown to be true for the system with aspects) The idea of the modular verification is as follows: 6

Represent the base program and the advice as finite automatae Mark the states of the base system by all the subformulae of the verified property Verify the desired property on the base program Mark the potential pointcuts (their algorithm for doing that will be described in Section 42) Create a descriptive interface between the base program and the advice: Add an in and out states to the automaton of the advice in - before the first state of the advice and out - after the last Mark the in and out states by all the labels of their corresponding states from the base system: in - by the labels of the end-of-pointcut state preceding the entrance to the advice and out - by the labels of the state succeeding the return from the advice Verify the desired property on the advice using the information in the in and out states If all the verifications above succeed then the desired property indeed holds in the system with aspects Obviously that work does not relate to the question of whether the augmenter system conforms with a scenario-based specification 22 Verification of Conformance for Non-Aspect Systems 221 Theorem Proving Verification based on equivalence of computations was mechanized for the first time in [4] There a proof environment for the PVS Theorem Prover [15] was presented that included all the definitions and an inductive proof method needed to prove equivalence of computations based on independence of operations The paper deals with systems specified by a given set of convenient computations and conformance to such a specification is checked by showing that every computation is equivalent to some convenient one There is no restriction imposed on the set of the convenient computations Let us notice that the scenario-based specifications we deal with can be viewed as a special case here with convenient computations defined as sequences of scenarios 7

The paper also goes farther then checking conformance The issue of showing some property to hold for all the computations of a given system is also treated When a system conforms to its specification it is enough to check the property for the convenient computations only provided that the chosen equivalence relation preserves the property The proof environment presented in [4] can be reused for different problems without the need of re-justifying the basic principles There is yet a drawback in this method The proof in theorem-proving is inductive and the user needs to find suitable invariants and assertions to supply the theoremprover for this proof The verification process thus is complicated interactive and not really automatic 222 Model Checking Verification using theorem-proving is more general and powerful but also more complicated more interactive than model-checking Thus the second framework built to automatize the verification of conformance for systems without aspects was based on model-checking In [5] the CNV tool for automatically verifying conformance with non-aspectual scenario-based specifications has been presented In CNV the original system is automatically augmented by additional constructions and temporal logic assertions converted to the input-format of Cadence SMV [14] and then model-checked When all the properties are verified by the model-checking it follows that every computation of the original system is equivalent to some convenient one and thus the original system conforms to the specification Although the method is sound it is incomplete and a negative answer does not necessarily mean that the original system does not conform to the specification The CNV tool and the ideas behind it lie in the basis of our work and will be described in more detail in Chapter 3 8

Chapter 3 Background on the CNV Tool In our work we extend the CNV tool for automatical verification of conformance with non-aspectual scenario-based specifications presented in [5] Below we describe the original CNV tool and its verification method The verification is based on proving equivalence of executions so before describing the method we list the formal definitions needed for such a proof The definitions are taken from [5] The systems we are working on are Fair Transition Systems (FTS) as defined in [13] Definition 1 A computation of FTS M is an infinite sequence of state-transition pairs σ = (s 0 τ 0 ) (s 1 τ 1 ) such that s 0 satisfies the initial state condition of M i : s i+1 τ i (s i ) and the fairness requirements are not violated in σ (ie for each weakly fair transition τ it is not the case that τ is continually enabled beyond some position j in σ but not taken beyond j) Definition 2 Transitions τ 1 τ 2 are conditionally independent in state s (denoted CondIndep(s τ 1 τ 2 ))) iff τ 1 τ 2 τ 2 (τ 1 (s)) = τ 1 (τ 2 (s)) Definition 3 Let σ = (s 0 τ 0 ) (s 1 τ 1 ) be a computation of M such that for some i CondIndep(s i τ i τ i+1 ) holds Then the sequence σ = (s 0 τ 0 ) (s i τ i+1 ) (τ i+1 (s i ) τ i ) (s i+2 τ i+2 ) is also a legal computation of M and we say that σ and σ are one-swap-equivalent (σ 1sw σ ) We also define the swap-equivalence ( sw ) relation as the reflexive-transitive closure of one-swapequivalence Now let us give a more detailed description of the method for systems without aspects Given a fair transition system M together with the list of the desired scenarios and the independence relation between the operations of M an augmented system M called the transducer is built The transducer is a composition of M 9

with a bounded history window H - a queue of fixed length L and an ω-automaton C called the chopper which reads its input from H and accepts only the desired scenarios M also has an error flag initially false The initial state of M is the state in which M is at its initial state H is empty and error is false The chopper has only one state in which it is waiting for the next scenario to be formed at the head of the history The transitions of M are as follows: All the transitions of M When a transition of M τ is performed at a state s of M the state of M changes according to τ and the pair (s τ) is inserted into H If there is no place in the history the insertion is impossible and the error flag is raised Once raised it never goes down again chop operation If some scenario appears at the head of the history it can be removed from the queue swap operation A pair of consecutive entries of H (s 1 τ 1 ) and (s 2 τ 2 ) can be swapped if τ 1 and τ 2 are conditionally independent at the state s 1 and the states at those entries are updated according to the result of applying the operations so that the two entries become (s 1 τ 2 ) (τ 2 (s 1 ) τ 1 ) predict operation Sometimes there is only one way to complete the prefix of the history to a whole scenario Then we may predict the remaining operations and chop the prefix of the scenario from the history (The cases when such prediction is possible are defined by the user) The prediction is done by inserting to the history the anti-transitions of the remaining transitions of the scenario after its prefix in the reversed order with appropriate states Then the anti-transitions are swapped backwards in the history by the swap pred (see below) operation to meet the remaining transitions of the scenario and to annihilate together with them after the cancel operation swap pred operation Swapping two consecutive entries in H (s 1 τ 1 ) and (s 2 τ 2 ) such that τ 1 is the anti-transition of some τ (denoted τ) and τ 2 is some transition of M that is independent of τ at s 2 cancel operation Removing a pair of consecutive entries of H (s 1 τ 1 ) and (s 2 τ 2 ) such that τ 1 is the anti-transition of τ 2 Now let us describe the added temporal assertions to be checked for the transducer by SMV (We will give only a brief verbal description here a fuller version is in [5]) 1 Legal Progress Legal progress of the computation is guaranteed: it is always possible to proceed without overflow of the history queue by chopping one more scenario and a place can always be reached at which the already performed prefix of the computation is equivalent to some convenient one 10

2 Correct Predictions The predictions are correct: whenever a prediction is made it is always fulfilled 3 No operation lost Every action performed in the computation appears in the convenient computation built ie whenever an operation enters the history it is eventually chopped (either explicitly - as a part of the head of the history queue or implicitly - as a part of some prediction) 4 Legal Independence The user-defined independence relation is legal: the operations that are declared independent indeed satisfy the CondIndep condition and their swapping preserves the values of the enabling conditions of operations so that a fair computation can be equivalent only to another fair computation This system is proven to be sound: if M is the above augmentation of M and all the above assertions hold in M it implies that every computation of M is equivalent to some convenient one 11

Chapter 4 Verification of Systems with Aspects 41 Defining The Problem We are given a system described by a scenario-based specification and containing aspects Our goal is to automatically verify the conformance of the system to its specification For that purpose we need to prove for every computation of the given system that it is equivalent to some good computation in which the aspectual operations appear as blocks immediately at the corresponding pointcuts and the non-aspectual scenarios also appear in blocks interrupted only by aspect advice We would like to divide the verification of conformance to two stages In the first stage we will show that the aspects appear correctly in the computation but we will not try to arrange the non-aspectual scenarios In the second stage we will view each aspect advice as performed atomically at its join-point assuming the aspects were proven to be applied properly and our goal will be arranging the nonaspectual scenarios This division is not necessary theoretically but it proves to be a considerable optimization of the verification process as will be seen in Chapter 7 Now let us describe the problem and our solution more formally First we give a more formal definition of aspects An aspect consists of two parts: a pointcut and an advice where the advice is a scenario that should be executed whenever the pointcut occurs In order to define the pointcut we need to introduce one more concept - the join-point: Definition 4 Given a sequence of operations op 1 op n an LTL past formula ϕ and a computation π we say that a state s in π is a join-point with respect to op 1 op n and ϕ iff there exists a sequence of states s 1 s n+1 (possibly interleaved by other states) in π such that: 12

op i is the operation performed at the state s i s = s n+1 ϕ holds at s Now the pointcut is defined as follows: Definition 5 The pointcut described by a sequence of operations op 1 op n and an LTL past formula ϕ is the set of all the join-points that are defined by op 1 op n and ϕ An occurrence of the pointcut in a computation π is a sequence of states of π s 1 s n+1 (possibly interleaved by other states) such that the state s = s n+1 is a join-point in π with respect to op 1 op n and ϕ (The occurrence of the pointcut is exactly the sequence s 1 s n+1 that appears in the definition of the join-point) There are different types of aspect advice One way of classification of the advice is according to the relation of its place in the computation to the place of its pointcut: Definition 6 Let σ a be the advice of aspect A When defining A it is possible to specify that σ a should be performed after its join-point in every computation In that case σ a is called after advice Similarly it is possible to specify that σ a should be performed before its join-point in every computation In that case σ a is called before advice Another important classification of advices is according to their influence on the scenario interrupted by the advice invocation Definition 7 Let σ a be the advice of aspect A t - the last operation of A s pointcut and σ = op 1 t op i op n - a scenario interrupted by A Both A and its advice are called strictly-interrupting iff the specification of A is such that whenever σ a interrupts σ after t the execution of σ does not proceed after σ a finishes ie the tail op i op n of σ is not performed The above definition is for the case of after advice The case for before advice can be defined symmetrically Our verification problem consists now of three parts treated separately: 1 To recognize the appearance of the pointcuts in the computation 2 To ensure that the operations of the appropriate aspect advice can be brought (by swapping) to appear as a block immediately at the pointcuts 3 To examine the computation we get after arranging all the aspect advice as blocks and show that all the non-aspectual scenarios can also be arranged in blocks of consecutive operations interrupted only by advice blocks 13

We extend the CNV system to provide automatically generated solutions to the problem Identifying the pointcuts is considered in Section 42 The main change to the CNV system is the automatic creation of a new module the advisor as a part of the augmented system M The advisor is in charge of arranging the aspect advice Some changes to the swapper module are also needed for that purpose - as will be seen in Section 43 the swapping of the end-of-pointcut operations should differ from the regular one Finally as will be seen from Section 44 arranging the non-aspectual scenarios requires changing the chopper module 42 Recognizing the Pointcuts: Four Options Some known techniques already exist for pointcut recognition and we will assume that the given system M has already been pre-processed by one of them Cross-Product Automaton If ϕ is the past formula of a pointcut we may build a finite automaton A ϕ that recognizes ϕ as in [13] or [16] and take the crossproduct of M with A ϕ In this new system each time a transition is inserted into the history the automaton updates its state If an accepting state is reached a pointcut is recognized in that state and the state becomes a join-point of the appropriate aspect This is obviously a correct solution but also a very costly one Several optimizations are possible all based on pre-processing of the system M in order to mark the states that are join-points Static Analysis One possibility is to perform static analysis as in [19] The pointcuts are restricted to be described by regular expressions over the call stack Such expressions are called pointcut designators (P CDs) The call graph of the system is built: the set of paths from the start vertex v to a node representing procedure call p is the set of all possible call stacks at point p during program execution For each procedure call p if all the possible stacks satisfy a PCD of some advice A then this procedure call is recognized as a place where A should always be applied and if none of the possible stacks satisfies the PCD of A this procedure call is recognized as a place where A should never be applied The advantage of this approach is its simplicity and relative cheapness but there are many cases when the analysis is inconclusive Moreover the class of the possible pointcuts recognized is rather narrow Model-Checking Analysis This approach is proposed by [12] Here the pointcuts are described by temporal logic formulas The algorithm is based on modelchecking using future time CTL over a modified program state machine with reversed 14

transitions (arrows) The result of the model-checking is identifying the states corresponding to each join-point A state is marked as a join-point if there is an execution in which this state is the join-point even if there is another possibility of reaching this state in which the pointcut does not occur Thus this algorithm detects potential pointcuts rather than real ones So in cases in which the previous algorithm would be inconclusive this algorithm will give a positive answer which might be wrong for the concrete computation we are interested in but in the cases in which the previous algorithm was able to give an answer this algorithm will give a correct answer too The advantage of the model-checking algorithm is the ability to deal with a much wider class of pointcuts than the previous one can handle It is also efficient though less simple than the static analysis algorithm Using Regular Expression Languages for Triggers RuleBase [3] allows identifying using a regular expression a trigger state after which a temporal logic property should hold It could be possible to use this in order to identify join-points although this possibility has not yet been exploited in practice Let us notice that all the above methods are applied to the woven system as a whole The consequence of it is that if a join-point of aspect B appears inside the advice of aspect A in some state s this state will indeed be marked as a join-point of B That enables us to treat the case of nested aspect advices Later in Section 43 we will see that there is yet one restriction we have to impose on B in such a case: B must not be a strictly-interrupting aspect 43 Ensuring the Appearance of the Aspects At this stage we are not interested in trying to arrange the non-aspectual scenarios so here we build the transducer M 1 for the system M with a modified list of scenarios It is built as defined in Chapter 3 except for the difference in the scenarios and a special treatment of end-of-pointcut operations The list of non-aspectual scenarios here contains each non-aspectual operation as a scenario on its own All the aspectual scenarios and their pointcuts are defined and let us suppose that the pointcuts are all recognized as described above The end-of-pointcut operations are treated as follows: Let p be a pointcut of the aspect A and let t be its last transition performed at a state s of M Then in M 1 when t is performed by M in the above case instead of inserting the pair (s t) into the history the pair (s t_ptc) is inserted The transition t_ptc is automatically created for every t that is the last transition of some pointcut The t_ptc has the same enabling condition as t and is defined 15

to change the state of M in the same way as t does The chopper is modified to treat t_ptc in the same way as t In our case all the non-aspectual scenarios contain one operation only so only the scenario consisting of t_ptc itself will be the new additional scenario recognized by the chopper Even if we would not do the optimization the modification of the chopper is such that if t appears in some nonaspectual scenario σ = op 1 t op n the scenario op 1 t_ptc op n will still be recognized by the chopper The only difference between t and t_ptc should be that whenever t_ptc occurs we should be able to ensure the following: It is followed by the advice of A σ a somewhere later in the computation The operations of σ a can be brought by legal swap operations to appear as a block immediately after t_ptc where this block can be interrupted only by a nested advice of another aspect in case that its pointcut occurs inside σ a Then the nested advice will also appear immediately after its pointcut Let σ a = a 1 a n be the advice of A To ensure the first property above we make a prediction of σ a immediately after inserting the t_ptc entry to the history ie the anti-transitions a n a 1 are inserted into the history after the t_ptc entry If some predicted transition does not appear later in the computation or can not be brought to the place where prediction was made then the prediction fails Thus if prediction succeeds the first property is guaranteed Remark 1 Let us explain why we restrict nested aspects not to be strictly interrupting Let A B be aspects such that pointcut of B can appear inside the advice of A and B is strictly interrupting When the pointcut of A occurs in a computation we must either detect that A will be cut by B in this case and then predict only the prefix of the advice of A that ends by the pointcut of B or see that in the given case A will not be interrupted and then predict the whole advice of A at that point In the version of the tool implemented at this time we cannot treat these alternatives so we need to pose the restriction on B However this detection is not impossible and a way of treating nested strictly interrupting aspects will be shown in Chapter 8 The prediction mechanism also would be enough to ensure the second property if we knew that t_ptc would never be swapped with any other operation But if t_ptc is swapped with some transition τ we need to show that all the operations of σ a can be swapped with τ in the same direction to be re-unified with t_ptc because even if it is swapped with some independent operation t_ptc continues to be the last operation of the pointcut due to the correctness of the independence relation Let us show two examples when such a swapping is needed: Let σ 1 t σ 2 be a legal scenario Let the following sequence of operations be a prefix of H: < σ 1 σ 2 t_ptc a 1 a n > such that σ 2 and t are independent 16

in the state where σ 2 appears In order to chop the scenario σ 1 t σ 2 from the history we need the sequence < σ 1 σ 2 t_ptc a 1 a n > to be equivalent to the convenient sequence < σ 1 t_ptc a 1 a n σ 2 > Thus we would like to enable the swap of σ 2 with t_ptc only if σ 2 is independent of t and of all the a i -s at the relevant states Let σ 1 σ 2 t be a legal scenario Let the following sequence of operations be a prefix of H: < σ 1 t_ptc a 1 a n σ 2 > such that σ 2 and t are independent in the state where t_ptc appears In order to chop the scenario σ 1 σ 2 t from the history we need the sequence < σ 1 t_ptc a 1 a n σ 2 > to be equivalent to the convenient sequence < σ 1 σ 2 t_ptc a 1 a n > Thus again the swap of t_ptc with σ 2 is possible only if t and all the a i -s are independent of σ 2 at the relevant states As we see from the examples above the independence relation of t_ptc should be different from the one of t If the sequence (s 1 τ) (s t_ptc) appears in the history in some computation of M we would like to enable the swap of τ and t_ptc only when the following sequence of swaps is possible: first the swap of τ and t and then the swap of τ with each of a 1 a n Thus we will say that τ and t_ptc are independent at s 1 (I(s 1 τ t_ptc)) iff the following conditions hold: 1 I(s 1 τ t) is true 2 I(t(s 1 ) τ a 1 ) I(a 1 (t(s 1 )) τ a 2 ) and (2 i n 1)I(a i ( (a 1 (t(s 1 ))) ) τ a i+1 ) If the sequence (s t_ptc) (s 2 τ) appears in the history we would like to enable the swap of t_ptc and τ only when the following sequence of swaps is possible: first the swap of each of a n a 1 (notice the reversed order!) with τ and then the swap of t with τ But as we will now see we needn t perform any additional checks at the moment of the swap except for checking the independence of t and τ at the state s because we couldn t have arrived at such a state of the history without performing all the additional checks at some previous moment Indeed there are only two possible ways of getting the sequence (s t_ptc) (s 2 τ) to appear in the history The first possibility is that τ occurred after t_ptc in the original computation of M In this case τ could be brought to appear next to t_ptc in the history only if it was possible to swap τ with the prediction of σ a first because of the prediction of σ a that was inserted into the history immediately after t_ptc Thus the swap of τ with the advice is indeed possible 17

The remaining possibility is that τ occurred before t_ptc in the original computation of M But then in order to bring t_ptc to occur before τ in the history we had to swap them at some previous moment and at the moment of this swap the checks for swapping (s 1 τ) (s t_ptc) were performed as described above (and now we just swap them back bringing t_ptc closer to the place at which σ a was originally predicted) Thus the aspect advice has been already taken into account and can be swapped with τ (Notice that there is no contradiction here with the second example of needed swapping: in the example σ 2 will never occur next to t_ptc if the swapping of a n a 1 with σ 2 is not possible) Thus indeed to swap t_ptc with a following operation no strengthening is needed beyond the prediction and we have that I(s t_ptc τ) iff I(s t τ) We can show that the above treatment is correct for nested advices as well as for advices that interrupt only non-aspectual scenarios Let σ a = a 1 a n be the advice of aspect A and σ b = b 1 b k be the advice of aspect B where B is not strictly interrupting and a i is the last operation of the pointcut of B Then if the above defined prediction succeeds for A and B the operations of their advices can indeed be arranged in the following sequence: a 1 a i b 1 b k a i+1 a n due to the correctness of the above defined swap operation for the pointcuts Let us notice that the appearance of the suffix a i+1 a n is required as B is not a strictly interrupting aspect After the transducer M 1 is built from M as described above the temporal logic properties listed in Chapter 3 are checked on it In Section 45 we prove that if all those properties are verified it means that every computation of M is equivalent to one in which the aspectual scenarios appear as (possibly nested) blocks immediately after their pointcuts 44 Arranging Non-Aspectual Scenarios We arrive at this stage after proving that in every computation of M the operations of the aspectual scenarios can be arranged to appear as (possibly nested) blocks immediately after the corresponding pointcut It now follows that given a computation g of M we can for the purpose of our proof ignore the appearance of the aspectual operations in it and assume that every aspect scenario is actually performed as an atomic operation at its join-point We do not change the underlying system M and the list of scenarios is the original non-aspectual-scenarios list but when building the transducer M 2 from M we slightly change the construction rules from 18

Chapter 3 by modifying the process of inserting elements into the history queue We would like the history to behave as if all the aspectual scenarios are atomically performed at their join-points together with the end-of-pointcut operations Thus the changes are as follows: 1 In M 2 we do not insert the aspectual operations to the history queue at all (All the other operations are still inserted as before) 2 Any end-of-pointcut operation should behave as if it was the whole aspect scenario executed atomically together with the last operation of its pointcut Let t_ptc be the end-of-pointcut of aspect A and σ a = a 1 a n the advice of A When t_ptc occurring at state s is to be inserted into the history the state of M is advanced to become s = (a n ( (a 1 (t_ptc(s))) ) instead of just (t_ptc(s)) Moreover if τ is the next operation performed by M the pair (s τ) will be inserted into the history after (s t_ptc) Let us notice that the state s is an existing state of M and reachable from s because we arrive at this stage after showing that all the aspectual scenarios can be arranged as uninterrupted blocks at their pointcuts This change is equivalent to changing the transition function of M If the sequence (s 1 τ) (s 2 t_ptc) appears in the history and is to be swapped the result of the swap will be (s 1 t_ptc) (a n ( (a 1 (t_ptc(s 1 ))) ) τ) The enableness of such a swap will be checked in the same way as described in Section 43 3 As it was done when defining M 1 here also the chopper will treat t_ptc in such a way that if t appears in some non-aspectual scenario σ = op 1 t op n the scenario op 1 t_ptc op n will be recognized by the chopper Yet another change in the scenarios chopped from the history is required Apart from the regular scenarios specified in the system M a new type of scenario appears and should be recognized by the chopper: the prefixes of regular scenarios that are cut by strictly interrupting aspects Those new scenarios are defined automatically by the following algorithm: For every aspect advice A that is defined as strictly interrupting For every scenario σ = op 1 op n For every 1 i n If op i = t where t is the last operation of the pointcut of A then add scenario σ = op 1 op i 1 t_ptc to the scenario list Note that the chopper of M 2 recognizes prefixes of scenarios as legal scenarios only if they are indeed cut by some strictly interrupting aspect advice because only in that case was t_ptc substituted for t 19

Remark 2 It is obvious that the result of the above changes is that the transducer M 2 we get is exactly the one we would obtain by applying the procedure of building a transducer for a system M a without aspects (as defined in Chapter 3) but where the pointcuts have an atomic transformation that includes all the effect of the advice at that pointcut Let us notice that the (non-aspectual-)scenarios list here includes the truncated scenarios ending with end-of-pointcut operations of strictly interrupting aspects The computations of M a are thus exactly all the computations of M in which the aspectual scenarios were performed as a block immediately after the corresponding pointcuts only that the blocks of aspectual scenarios and their pointcuts are replaced by one atomic operation After the transducer M 2 is built from M as described above the temporal logic properties listed in Chapter 3 are checked on it In Section 45 we prove that if all those properties are verified it means that every computation of M is equivalent to one in which the non-aspectual scenarios appear as blocks interrupted only by aspect advices 45 Proving Soundness First let us give some definitions needed to state and prove the soundness of the system Here we ignore predictions added by non-aspectual scenarios since they can be shown equivalent to a version without predictions but with a longer history as it was done in [5] Definition 8 Let M be a transducer built from M as defined in Chapter 3 or in Section 43 A computation g of M follows a computation g of M if the error flag is never raised in g and g is the projection of g on M proj M (g ) (ie g is obtained from g by deleting all the operations that are not operations of M and all the assignments to state variables that are not defined in M) Note that due to Remark 2 the above definition can be applied also to computations of M 2 and M a as defined in Section 44 Given a computation g that follows g we can say that any moment i in g naturally divides all the operations of g to three subsequences: chopped(g i) - the sequence of operations already chopped h(g i) - the contents of the history and suffix(g i) - all the rest of g Now let us look at a sequence of executions R(g ) = {r i } i= i=0 where r i = chopped(g i) h(g i) proj M (suffix(g i)) We have r 0 = g and the only difference between r i and r i+1 can be one swap of consecutive independent operations so ir i 1sw r i+1 R(g ) is a special case of a reduction sequence from g which is defined as a sequence of swap-equivalent executions starting from g We 20

will say that a reduction sequence {r i } i=0 converges to some computation c iff for any prefix of c 1 of c we can find an index j such that for every i j every r i will have that prefix c 1 We also need to define formally equivalence of infinite computations For that we will first define that c g for infinite computations g c iff from every finite prefix c 1 of c there exists a continuation h such that c 1 h sw g Definition 9 Two infinite computations g and c are conditional trace equivalent (c g) iff c g and g c Definition 10 We will define by AtomAsp(g) the following function from (a subset of) computations of M to computations of M a defined in Remark 2: Let g be a computation of M in which all the aspectual scenarios are performed as (possibly nested) blocks immediately after their corresponding pointcuts Then AtomAsp(g) is a computation g a of M a constructed from g in the following way: Each block of end-of-pointcut operation t followed by aspect advice σ a that appears in g is replaced by a single operation t_ptc such that its effect is the effect of atomically performing t followed by σ a In all the rest g a is identical to g It is obvious that g a is indeed a legal computation of M a Let us also notice that the reverse function AtomAsp 1 (g) is well defined Given any computation g a of M a we can replace each t_ptc with a sequence t σ a and obtain a legal computation of M Definition 11 A computation g a of M a is convenient iff it is comprised of blocks of (non-aspectual) scenario operations Definition 12 A computation g of M is convenient iff the following holds: whenever a pointcut appears in g it is immediately followed by the corresponding aspect advice and no non-aspectual operations of the system M appear between the operations of the aspect if an advice σ a is interrupted by another advice σ b then σ b appears as a nested block inside σ a The non-aspectual operations in g appear as blocks that might be interrupted only by aspect advice In order to show the soundness of the new system we need to prove: 21

Theorem 3 When M 1 and M 2 are built from M M a is as defined in Section 44 and the convenient computations are defined as in Definition 11 and Definition 12 the temporal assertions described in Chapter 3 being true for both M 1 and M 2 imply that every computation of M is conditionally trace equivalent to some convenient one (of M) We begin by showing a key property - the existence of a convenient computation c such that c g That is for every finite prefix of c there is a continuation so that the prefix followed by a continuation are swap-equivalent to g First we will show that given g as above there always exists a computation g 1 of M such that g 1 g and whenever a pointcut occurs in g 1 it is immediately followed by the corresponding aspect advice as a block and that we can restrict our further discussion only to the case of g 1 above (Step1 of the proof outline) In that case g 1 a = AtomAsp(g) is well defined and Step2 of the proof will show that g 1 a is reducible to some convenient computation c 1 a of M a Finally at Step3 we will prove that if c 1 a g 1 a then there indeed exists a convenient computation c of M such that c g Step1: Let g be a computation of M 1 that follows a computation g of M The Correct Predictions property from Chapter 3 holds in M 1 and whenever a pointcut occurred in g the appropriate aspect advice was predicted This together with the Legal Independence property implies the existence of a computation g 1 of M 1 such that g 1 g and whenever a pointcut occurs in g 1 it is immediately followed by the appropriate aspect advice as a block that might be interrupted only by a nested block of another aspect advice Let g 1 be the projection of g 1 on M It is a computation of M The error flag is never raised in g as it is a computation of M 1 and M 1 satisfies the Legal Progress and the No operation lost properties from Chapter 3 Thus g 1 follows g 1 As g 1 g the following lemma will imply that also g 1 g and so it is enough to show that there exists a convenient computation c such that c g 1 Lemma 1 Let g g 1 g g 1 be as above Then if g 1 g it follows that g 1 g Proof As g 1 g there exists a reduction sequence R 1 = R(g 1 ) = {r 1i } i=0 i= that converges to g and a reduction sequence R 2 = R(g ) = {r 2j } j= j=0 that converges to g 1 Let us examine a sequence R 1 = {r 1i } i= i=0 where each r 1i is the projection of r 1i on M It is a reduction sequence in M starting from g 1 and converging to g In the same way the sequence R 2 = {r 2j } j= j=0 where each r 2j is the projection of r 2j on M is a reduction sequence in M starting from g and converging to g 1 Thus we have that both g 1 g and g g 1 so indeed g 1 g QED It follows that it is indeed enough to restrict our further proof only to computations in which all the aspect advice are applied correctly 22