Verifying data- and control-oriented properties combining static and runtime verification: theory and tools

Static verification techniques are used to analyse and prove properties about programs before they are executed. Many of these techniques work directly on the source code and are used to verify data-oriented properties over all possible executions. The analysis is necessarily an over-approximation as the real executions of the program are not available at analysis time. In contrast, runtime verification techniques have been extensively used for control-oriented properties, analysing the current execution path of the program in a fully automatic manner. In this article, we present a novel approach in which data-oriented and control-oriented properties may be stated in a single formalism amenable to both static and dynamic verification techniques. The specification language we present to achieve this that of ppDATEs, which enhances the control-oriented property language of DATEs, with data-oriented pre/postconditions. For runtime verification of ppDATE specifications, the language is translated into a DATE. We give a formal semantics to ppDATEs, which we use to prove the correctness of our translation from ppDATEs to DATEs. We show how ppDATE specifications can be analysed using a combination of the deductive theorem prover KeY and the runtime verification tool LARVA. Verification is performed in two steps: KeY first partially proves the data-oriented part of the specification, simplifying the specification which is then passed on to LARVA to check at runtime for the remaining parts of the specification including the control-oriented aspects. We show the applicability of our approach on two case studies.


Introduction
Runtime verification has been touted as a practical verification technique, and although it does not provide program analysis before deployment, it can check correct behaviour post-deployment by observing whether actual execution paths at runtime conform to the specification. Runtime verification scales up much more effectively than static analysis both in terms of performance and in terms of applicability to diverse contexts in which a program may interact with various other systems, services, libraries and be deployed.
Despite the fact that overheads induced by runtime verification might be small when compared to the computational effort required for static analysis, the fact that is done while the software is live can be problematic and prohibitive for certain systems. In this paper we present an approach to address the issue of runtime overheads through the use of static, deductive verification-an approach which also has the benefit of being able to verify parts of the specification a priori for all potential execution paths, leaving only parts which could not be proved before deployment to be checked dynamically.
Apart from the computational power required to perform the analysis, deductive and runtime verification have largely been applied to disjoint areas-whereas deductive analysis has been extensively used to verify properties focusing on a system's data, e.g., [2,23,28,30], runtime verification has been extensively used to verify control-flow properties with reasonable overheads [11,15,18,33]. Combining the two approaches has the additional benefit that static analysis might be more effective in proving the parts of a specification which dynamic analysis might struggle most with. The challenge is thus to design a specification language which allows the expression of combined data-and control-flow properties in such a manner that they can be effectively decomposed for the application of different verification techniques.
The StaRVOOrS framework [5] addresses these issues by identifying a specification notation for such properties and a verification methodology combining static and dynamic analysis to verify combined control-and data-oriented properties. Although one may envisage different ways to combine static and dynamic analysis tools, a crucial requirement is that the specification languages used in the tools chosen are either identical, or can be somehow combined to allow for rich specifications getting the best of both approaches. Similar to mode automata [31] we have chosen to adopt an automata-based specification language (for the control-flow properties) but extended with data-flow properties encoded in the different states of the formalism.
This article is a significantly extended and revised version of two papers. In [3] we introduced the formalism ppDATE, where parts of the syntax where left underspecified, and we gave a high-level description of the algorithm to translate ppDATE into DATE [18], the formalism used in the runtime verification tool Larva [19]. In [16] we presented the tool StaRVOOrS, a full implementation of the framework introduced in [3,5].
The novel contributions of this paper, going beyond the results reported in [3] and [16] are the following: (i) We present a complete formal definition of ppDATE automata, including a formal semantics for the formalism (Sect. 5); (ii) A proof of soundness of the algorithm to translate from ppDATE specifications into DATE ones (Sect. 7). (iii) The application of our approach to SoftSlate Commerce, an open-source Java shopping cart web application (Sect. 9); (iv) A description of the results of the case study including an analysis of the (where p 1 , p 2 , and q are Java fragments and φ is some postcondition). The sequent says that in each state where x and y are positive, the program given in the modality (which first swaps x and y using arithmetics) will terminate and result in a state where φ holds. When proving this sequent, the KeY prover will first, in a number of steps, turn the three leading assignments into explicit substitutions, apply the first to the second, the result to the third, and perform arithmetic simplification, arriving at where (x ← x+y y ← x x ← y) denotes the explicit (parallel) substitution resulting from symbolic execution of the first three statements. A 'right-win' semantics is adopted to resolve clashes in substitutions, such that the above simplifies to: In general, most proofs branch over case distinctions, often triggered by Boolean decisions in the source code. The branching happens by applying rules like the following, simplified 1 if rule: In our example, applying the if rule to the latest sequent results in splitting the proof into two branches, with the following sequents, respectively: Applying the substitution on the left side of either sequent results in: x > 0, y > 0, y%2 = 0 (y ← x x ← y) p 1 ;q φ (2) x > 0, y > 0, ¬(y%2 = 0) (y ← x x ← y) p 2 ;q φ (3) Note that in this step, by applying the swapping substitution, the branching condition (x being even or odd) on the state after swapping got translated into a condition on the prestate of the original program p, before the swapping. The resulting sequents tell us, among other things, that if y is even (respectively odd) in the prestate of p, then path p 1 (respectively p 2 ) is taken in the execution of p. In general, when building a proof in such a symbolic manner, the left side of sequents accumulate conditions on the original prestate through a particular execution path. Once all proof branches are closed, we have a complete proof of the root sequent. However, a proof attempt may result in a partial proof, only, where some proof branches are closed and others are not. Such partial proofs are important for the work presented in this article. In the above example, consider a partial proof where the left branch, i.e., the sub-proof for sequent (2), is closed, whereas the right branch, i.e., the sub-proof for sequent (3), is not closed. From this partial proof, we can conclude that the following modification of the root sequent (1) is valid: x > 0, y > 0, y%2 = 0 x=x+y;y=x-y;x=x-y;if(x%2==0){ p 1 }else{ p 2 };q φ (4) (We added y%2 = 0 to the left side of (1), as additional assumption.) This sequent can be proven by replaying the original proof, where now both branches would close. The left branch closes as the sub-proof for (2) will replay identically. The right branch closes because the following variant of (3) can be closed immediately, due to contradicting assumptions: x > 0, y > 0, y%2 = 0, ¬(y%2 = 0) (y ← x x ← y) p 2 ;q φ

The runtime verifier LARVA
Larva 2 [19] is an automata-based runtime verification tool for Java programs. As with many other runtime verifiers, Larva automatically generates a runtime monitor from a property written in a formal language, in its case using Dynamic Automata with Timers and Events (DATEs) [18]. Transitions in a DATE are of the form: event | condition → action, where event is what triggers the transition, the condition is checked and must hold in order the transition to take place, and the action is a code snippet to be performed when taking the transition (after checking the condition). DATEs are an extension of timed automata-they are effectively finite state automata, whose transitions are triggered by system events (primarily entry points f ↓ and exit points f ↑ of methods) and timers, but augmented with: (i) A symbolic state which may be used as conditions to guard transitions and can be modified via actions also specified on the transition; (ii) replication of automata, through which a new automaton is created for each discovered instance of an object; (iii) communication between automata using standard CCS-like channels with c! acting as a broadcast on channel c and which can be read by another automaton matching on event c? Full details of the formalisation of DATEs can be found in [19]. The automata illustrated in Fig. 1 represent an example of DATE automata describing a property which should hold during a connection. The first automaton ensures that if the connection drops (event connDrop ↓ ) occurs five times, a message is broadcast (over channel unreliable) to highlight the fact that the connection port is unreliable. The second automaton (with the foreach keyword) ensures that every time a file transfer is initiated, an automaton is created to monitor that transfer. If during the transfer (i.e. between the events start ↓ and end ↓ ) one receives event unreliable?, no further transfers may occur.
In order to monitor a system using Larva, the user must provide the system to be monitored (a Java program) and a set of properties in the form of a Larva script (a textual representation of DATEs). Larva transforms the set of properties into monitoring code together with AspectJ code to link the system with the monitors. Since the Java byte code is used for instrumentation, it is possible to monitor third-party software with Larva, though knowledge of methods names is still required.

ppDATE: a specification language for data-and control-oriented properties
In many cases, verification tools perform more effectively on a particular style of specification. In combining two different verification tools which use very different analysis techniques, one challenge is that if we adopt an off-the-shelf language, we cannot expect to derive useful verification results from both tools. Given that deductive verification tools like KeY perform much better on data-centric properties, while runtime verification tools like Larva perform better on control-flow properties, we have defined a specification language to combine the two types of properties. In real scenarios, there is often a need to specify both, rich data constraints and legal execution sequences. Data-oriented properties are typically written in expressive formalisms (like first-order logic), but typically give invariants about specific points in the execution of a system, rather than properties across traces of execution. JML is one such languages, which focuses primarily on pre/postconditions of method calls and class invariants, but is not well suited for specifying which sequences of events or states are correct. In contrast, control-oriented specification languages specialise primarily on identifying legal sequences of events or states, for instance using automata or temporal logics. Although constraints about the data are possible, they are usually cumbersome and greatly increase the computational complexity required to verify them. DATE is one such specification language.
Coding control-flow into data-centric languages, like coding legal execution traces via model/ghost fields in JML, or including data-flow information in control-centric languages, like considering variable updates as events in DATE specification, can lead to substantial increase in the complexity of the specification from an understandability and/or verification perspective.
In order to address this, we propose ppDATE, a formalism to deal with both types of properties ensuring understandability and tractability of analysis using the StaRVOOrS verification framework. ppDATE [3] is an automata-based formalism to specify both controland data-oriented properties. ppDATEs are basically transition systems with states and transitions between states. Transitions are labelled by a trigger (tr), a condition (c), and an action (a). Together, the label is written tr | c → a. A transition is enabled to be taken whenever its trigger is active and its condition holds. A trigger is activated by the occurrence of either a visible system event such as the invocation or termination of a method execution, or a ppDATE internal event generated by certain actions labelling other transitions. If a transition is taken, we will say that it fires. The conditions may depend on the values of system variables (i.e., variables of the system under scrutiny) and the values of ppDATE variables. The latter can be modified via actions in the transitions. ppDATE states represent the status of an observer of a system (rather then, directly, the status of a system itself). Note that each state essentially represents the set of observed system traces leading to that state. The language also offers parallelism on the specification side, in the sense that different ppDATEs run in parallel, possibly communicating which each other through events, and possibly creating new ppDATEs on demand. This parallelism allows for a strong separation of concerns in the specification.
In addition to the above, a particular feature of the ppDATE is that states may be tagged with any number of Hoare triples, to specify the computation of a method in a historycontext sensitive way. For instance, assume that a ppDATE state q is tagged with the Hoare triple {π} f oo{π }. This means that, if foo is invoked after a system trace which led the observer to q, and if furthermore π holds at the time of the invocation, then π should be satisfied upon termination of this execution of foo. This allows for data-centric specification of individual methods' behaviour (Hoare triple), however in a control sensitive manner (state).
Compared to usual automata based (or temporal logic based) specification approaches, ppDATE is more expressive concerning the computation on data. Compared to data-centric pre/post-specification (like, e.g., JML), ppDATE can avoid the coding of some notion of status into additional data and additional constraints in the pre/postconditions.
To write a ppDATE, a good approach may be to, first, define the control-oriented properties, i.e., the automata. Next, one shall proceed to define the different Hoare triples. Finally, one places the Hoare triples on the appropriate states of the ppDATE.
Below, we provide a few examples of ppDATE specifications. On this examples, tr ↓ means that the method associated to the trigger tr has just been called, and tr ↑ means that method associated to the trigger tr has terminated its execution.
Example 1 Let us consider a coffee machine system where after a certain amount of coffee cups are brewed, its filters have to be cleaned. If the limit of coffee cups is reached, the machine should not be able to brew any more coffee. In addition, while the coffee machine is active (a coffee cup is being brewed), it is not possible to start brewing another coffee, or to clean the filters. Figure 2 illustrates a ppDATE describing this part of the system. In other words, whenever the coffee machine is not active, i.e., the machine is not brewing a cup of coffee, and the method brew starts the coffee brewing process, then it is not possible either to execute this method again, or to execute the method cleanF (which initialises the task of cleaning the filter), until the initialised brewing process finishes.
The previous property can be interpreted as follows: initially being in state q, state which represents that the coffee machine is not active, whenever method brew is invoked and it is possible to brew a cup of coffee (i.e., the limit of coffee cups was not reached yet), then transition t 1 shifts the ppDATE from state q to state q . While in q , state which represents that the coffee machine is active, if either method brew or method cleanF are invoked, then transitions t 3 or transition t 4 shift the ppDATE to state bad, respectively. This indicates that the property was violated. On the contrary, if method brew terminates its execution, In addition to this, the Hoare triples in state q ensure the properties: (i) if the amount of brewed coffee cups has not reached its limit yet, then a coffee cup can be brewed; (ii) cleaning the filters sets the amount of brewed coffee cups to 0. Property (i) has to be verified if, while the ppDATE is on state q, the method brew is executed and its precondition holds. A similar situation stands for the property (ii) with respect to the method cleanF. Regarding state q , the Hoare triples in this state ensure the properties: (iii) no coffee cups are brewed; (iv) filters are not cleaned. Property (iii) and (iv) are verified if either method brew and method cleanF are executed, and their preconditions hold, respectively. Here, remember that this state represents that the coffee machine is active. Thus, if it occurs that either the method brew or the method cleanF are executed while the ppDATE is on this state, then, as this would move the ppDATE to state bad, one would expect the value of the variable cup to remain unchanged. This is precisely what is verified when either property (iii) or (iv) are analysed.
Note that none of the Hoare triples makes reference to the state of the coffee machine, i.e. there is no information about whether the machine is active or not. This is due to fact that the state of the machine is implicitly defined by the states of the ppDATE. If the ppDATE is in state q, the coffee machine is not active. However, if it is in state q , then the machine is active. Therefore, it is possible to assume that on each state the Hoare triples are context dependent and thus contain such information. This is the reason why, we can describe properties with the same precondition, but with different postconditions depending on the state of the ppDATE in which they are placed.

Example 2
In this example let us consider a file system where only 10 file transfers can be performed between a log in and log out of a user. Figure 3 illustrates a ppDATE describing part of the behaviour of this system. This ppDATE ensures the property: no more than 10 file transfers take place in a single login session. In other words, once a user logs in the system (login), she can only perform 10 file transfers (transferFile) before logging out (logout). This fact is tracked using the ppDATE variable c. This variable keeps count of the number of files transferred in a single session. Whenever a user logs in, the ppDATE moves to state q and c is set to 0 (zero). While in q , this variable is increased by one every time a file transfer is performed. If at some point the user transfers a file but the value of c is bigger than 10, then the ppDATE moves to state bad, i.e., the property was violated. In addition to this, the Hoare triples in state q ensure the properties: (i) the number of bytes transferred increases when a file transfer is done; (ii) renaming a file works as expected if the user has the sufficient rights.

The STARVOORS framework
The StaRVOOrS framework (Static and Runtime Verification of Object-Oriented Software), originally proposed in [5], combines the use of the deductive source code verifier KeY [2] with that of the runtime monitoring tool Larva [19], to analyse and monitor systems with respect to a ppDATE specification. Note that the definition of the specification language ppDATE, which enables the effective combination of the results from the two verification approaches, is a major contribution of StaRVOOrS. ppDATE allows our framework to naturally address the intrinsic differences between the verification tools-whereas one typically verifies data-centric properties in deductive verifiers like KeY, one typically focuses on control-flow properties using runtime verifiers like Larva.
The abstract workflow of the use of StaRVOOrS is given in Fig. 4. This workflow is applied fully automatically in four consecutive stages: Deductive Verification, Specification Refinement, Translation and Instrumentation, and Monitor Generation.
In the Deductive Verification stage, given a Java program P and a ppDATE specification S, the module Pre/post-Condition Generator transforms all the Hoare triples-assigned to the various states of S-into JML contracts , which are textually added to P as annotations of the respective methods. In this step, the association of pre/postcondition pairs to ppDATE states in S is lost, which is intentional and natural. Note that each ppDATE state represents the set of event histories leading to that state. The deductive verifier, however, offers analysis of the effect of methods in terms of system data, and has no notion of the history of events preceding a method call. 3 Once all JML contracts are generated, the Deductive Verifier module uses KeY in an attempt to statically verify each of them. The result is either a complete proof, or a partial proof where some branches are closed and others are not (see Sect. 2.1), or an entirely open proof, where no branches are closed. In our setting, partial proofs are the most common case. One reason is that we use KeY only fully automatically, not employing its interactive features. Also, we do not assume users to provide loop invariants, or similar annotations which support the prover. Finally, KeY has no knowledge of the context (ppDATE state) in which the Hoare triple at hand should hold. To illustrate this point, consider the Hoare triples (i) and (iii) from our (deliberately primitive) example in Fig. 2. The implementation of brew() is given by: if (!active && cups < limit) cups++; } KeY will produce partial proofs for these Hoare triples because the specification does not provide any information on how q and q relate to the field active. In general, the missing information can be an arbitrary condition on the system state, more than just a Boolean as is the case here.
In the Specification Refinement stage, 4 the Partial Specification Evaluation module evaluates the results produced by KeY in order to refine S. This refinement is performed in two steps. In the first step, all fully verified Hoare triples are deleted, resulting in a ppDATES' . Any Hoare triple related to a contract which is not fully verified by KeY is left in the states of S' to be verified at runtime. In the second step, S' is refined into a ppDATES" by strengthening the preconditions of those Hoare triples in S' which were partially verified by KeY. For that, the partial KeY proofs are analysed, to extract branch conditions corresponding to the closed branches of the proof. In the example in Sect. 2.1, that 'closed branch condition' is y%2 = 0 in sequent (4). Note again that the branch condition is a condition on the prestate of the code being verified. Let us abbreviate the 'closed branch(es) condition' as cbc for now. A Hoare triple {π} f oo{π } that was partially verified by KeY is clearly equivalent to having two Hoare triples {π ∧ cbc} f oo{π } and {π ∧ ¬cbc} f oo{π }. However, as we know that the first one is valid (by the proof replay argument from Sect. 2.1), only the second one needs to be checked at runtime. For this reason, every Hoare triple {π} f oo{π } in S' that was partially verified by KeY is replaced by {π ∧ ¬cbc} f oo{π }, resulting in S" . At runtime, checking such an optimised Hoare triple is trivial whenever π is false or cbc is true, as the postcondition does not need to be checked then. For instance, analysis of the partial proof of Hoare triple (i) in Fig. 2 will result in the closed branch condition ¬active. Therefore, (i) is replaced by {cups < limit ∧ active} brew() {cups == \old(cups)+1} (we simplified away double negation). Note that, in cases where the history context, i.e., ppDATE state, is the only information that was missing to close a partial proof, cbc actually represents a refinement of the according ppDATE state to a condition on internal system data, which will always be true when f oo is called in that state. We can remark already here that this is the phenomenon which made the monitoring speedup particularly dramatic in the Mondex case study, see Sect. 10.
In the Translation and Instrumentation stage, the Specification Translation module translates S" into an equivalent specification in DATE format (D), which can be used by the runtime verifier Larva (see the next stage). The most significant change of this translation is that the Hoare triples are translated away, using notions native to DATE (see Sect. 7.2). This change also requires to instrument P, through the Code Instrumentation module, in order to (i) distinguish between different executions of the same code unit, and to (ii) evaluate Hoare triples in the states of S" at runtime. Regarding (i), method declarations get a new argument which is used as a counter for invocations of this method. Regarding (ii), not every condition in a pre/postcondition of a Hoare triple can be directly written as a Java Boolean Expression, e.g., quantified expressions. Thus, methods which operationalise the evaluation of those conditions are added to P.
Finally, in the Monitor Generation stage, the instrumented version of P (P' ) and the DATE specification D are used by the Runtime Verifier module to generate a monitor M . For this, Larva generates M from D by using aspect-oriented programming techniques to capture relevant system events. Such events allow to link P' with M. Later, once deployed, M and P' are executed together. If M identifies any violation at runtime, it will report an error trace for further analysis.

Notation
We will use the following notation to write quantified formulae, based on the notation used by Gries [27].
These formulae mean "for all x satisfying R, B is fulfilled" and "there exists x satisfying R for which B is fulfilled", respectively. Both R and B are formulae potentially containing x as a free variable. We will refer to R and B as the range and body of the quantified formula, respectively. This notation relates to standard (un-ranged) quantified formulae in the following way:

ppDATE
In this section we formally define the notion of ppDATE previously introduced in Sect. 3. In order to do so, we first introduce formal definitions for triggers, conditions and actions. Definition 1 Given a set of method names Σ, the syntactic category of triggers is defined as follows: In the previous definition, systemtrigger matches a visible system event, such as the point of entry into a method or the termination of a method execution. Given a method name σ ∈ Σ, σ ↓ represents entering method σ and σ ↑ represents the termination of the execution of σ .
In addition, actevent represents an event generated by the execution of an action in a transition of a ppDATE, which we will call action events. This kind of events can only be generated by bang ("!") actions (see Definition 2). An action h! generates the action event h, which in the next step can activate the trigger h? This way, action events enable communication among ppDATEs, where h! and h? mean sending and receiving a message, respectively.
As we have mentioned before, whenever a transition is fired an action can be executed. The following shows the definition of actions.

Definition 2
Actions are syntactically defined as follows: skip is the effect-less action. The '=' is an assignment operator, v is a ppDATE variable and e is a (side-effect free) expression that may depend on system variables and ppDATE variables; actevent! represents the generation of action event actevent; create represents the creation of a ppDATE, where template is a ppDATE template to be instantiated (see Definition 8), and args are the values which the formal parameters of template are instantiated with; the ';' is the sequence operator for actions; if-then is a conditional whose branching condition depends on the valuations of system variables (Sys) and ppDATE variables (V ); and Program represents a side-effect free program (see Definition 3), i.e., it is restricted to not have any effect on the system which could in turn be observed by the (ppDATE generated) monitor. For instance, a Program could perform logging of system/monitor behaviour. More powerful Programs, which would for instance allow error recovery, are relevant, but left for future work.

Definition 3
A side-effect free program has the properties that -its execution always terminates, -the method calls on its body do not generate any observable system event, -it does not interfere with the system under scrutiny, i.e., it does not modify the values of system variables.
Boolean expressions are used in different contexts: (i) conditions (c) of transitions; (ii) conditions of if-then actions, and (iii) pre-and postconditions (π, π ) in Hoare triples. As a syntactic category for such Boolean expressions, we chose Boolean JML expressions. They extend Boolean Java expressions, and thereby allow Java methods as sub-expressions (like in 'm.get(k) == o'). Additional features of Boolean JML expressions include universal and existential quantification, which are frequently used in Hoare triples, the ability to refer in a postcondition to a) the return value (with '\result'), and b) the preexecution value of an expression (like in 'x == \old(x + y)').

Definition 4 Boolean JML expressions (BJMLE) are recursively defined as follows:
-any side-effect free Boolean Java expression is a BJMLE, -if a and b are BJMLEs, and x is a variable of type t, the following expressions are BJMLEs: -!a, a&&b, and a||b a == > b ("a implies b") a < == > b ("a is equivalent to b") -(\forall t x; a) ("for all x of type t, a holds") -(\exists t x; a) ("there exists x of type t such that a") -(\forall t x; a; b) ("for all x of type t fulfilling a, b holds") -(\exists t x; a; b) ("there exists an x of type t fulfilling a, such that b") -replacing any sub-expression e in a BJMLE with \old(e) gives a BJMLE, -replacing any sub-expression in a BJMLE with \result gives a BJMLE, (welltypedness is context dependent, see Definition 5) We do not give a formal definition of the semantics of BJMLE here, just the following comments. The meaning of negation, conjunction, disjunction, implication, and equivalence are standard. The same is true for the first two forms of quantification. Concerning the other two forms, ". . . a; b)", they relate to standard quantification in exactly the same way as was explained in Sect. 5.1. (The only difference is that there we discussed meta-level notation, whereas BJMLE is part of ppDATE.) The constructs \old and \result are only allowed in postconditions of Hoare-triples (i.e., in π ). \result refers to the return value of a (nonvoid) method. \old allows to evaluate sub-expressions not in the post-state (which is the default), but in the prestate of a method's execution. For instance, 'x == \old(x + y)' in a postcondition of method m says that the difference between the values of x before and after the execution of m is the value which y had before m's execution.
In order to allow or disallow \old and \result, in the following, we provide one syntactic category for postconditions, and one for all other conditions.

Definition 5
The syntactic category of postconditions over variables in Var, postcond V ar , is given by Boolean JML expressions over Var. (Well-typedness of postconditions is context dependent, assuming that \result has the same type as the specified method.) The syntactic category cond V ar is given by Boolean JML expressions over Var containing neither \result nor \old. Now we can formally define ppDATE. As a ppDATE describes properties about a particular system, we assume that every time we make reference to the set of system variables, these variables belong to the system under scrutiny.

Definition 6
Given a set of system variables Sys and a set of ppDATE variables V , a ppDATE m is a tuple (Q, t, B, q 0 , Π) such that: -Q is the finite set of states.
t is the transition relation among states in Q, where each transition is tagged with (i) a trigger; (ii) a condition; (iii) an action which may change the valuation of ppDATE variables: -Π is a function which tags each state of m with Hoare triples for particular method names in Σ: Π ∈ Q −→ P(cond Sys × Σ × postcond Sys ).
We will write q tr|c →a − −−− → m q to mean that, given a ppDATE m whose transition relation is t, (q, tr, c, a, q ) ∈ t. The subscript m is omitted if it is clear from the context. In addition, we will use the usual Hoare triple notation {π} σ {π } ∈ Π(q) to denote (π, σ, π ) ∈ Π(q).
Example 3 Consider once again, the ppDATE shown in Fig. 3. It can be formalised as follows: m = (Q, t, B, q 0 , Π), where, Furthermore, the transition relation t consists of four elements, including: In addition, relation Π is defined as follows: In addition to ppDATEs which exist up-front, and 'run' from the beginning of a system's execution, new ppDATEs can be created by existing ones. For instance, one may want to create a separate 'observer' for each new user logged into a system. For that, one needs to be able to define parameterised ppDATEs, which we call templates, and allow ppDATEs to create new instantiations of templates. Given a ppDATE m, the creation of a new ppDATE, which will run in parallel to m, can be achieved by using action create on a transition of m. This action receives as arguments a ppDATE template describing the ppDATE to be created and a list of arguments to instantiate the quantified variables on the template. Below, we formally define ppDATE templates.
Definition 7 ppDATE templates of order n are recursively defined as follows: -The set of ppDATE templates of order 0 is exactly the set of ppDATEs.
-Assume C is a syntactic sub-category of ppDATE (Definition 6), i.e., a syntactic (sub-)category of Q, t, B, q 0 , or Π, respectively. If m is a ppDATE template of order n, then λX:C.m is a ppDATE template of order n + 1, where m is the result of replacing, in m, some (sub-)term trm of category C by X . We call X the template variable of λX:C.m .
In the above definition, a template of order n + 1 is defined by 'abstracting' over templates of order n, annotating the abstracted 'hole' X by the right category, such that template instantiation (see below) can be guaranteed to result in a well-typed ppDATE. When constructing a ppDATE template, the choice of trm in Definition 7 does not matter. Its only role is to carry well-typedness of ppDATEs over to ppDATE templates. Informally, the above definition says that, within λX:C.m , the X can appear anywhere in m where a term of category C is expected.
We will refer to ppDATE templates without referring to an order to mean templates that are of order greater than 0. Formally:

Definition 8
The set of ppDATE templates T ppd , is defined as the union of ppDATE templates of order n ≥ 1.
If X is a vector of template variables X 1 , . . . , X n and C is a vector of syntactic categories C 1 , . . . , C n , then we can write λX:C.m to mean λX 1 :C 1 . . . λX n :C n .m.
Finally, we define what it means to instantiate a ppDATE template: Definition 9 Given a term trm of syntactic category C, the instantiation of a ppDATE template with term trm, denoted inst(m, trm), is defined by:

inst(λX:C.m, trm) = m[X/trm]
where m[X/trm] denotes the result of substituting all occurrences of X in m by trm.
We can expand template instantiation to multiple arguments in the following way. Given n ≥ 2, assume X = X 1 , . . . , X n , and C = C 1 , . . . , C n , and trm = trm 1 , . . . , trm n (with trm i ∈ C i ). We extend the instantiation function inst to an arbitrary number of arguments in the following way:  Figure 5 illustrates a ppDATE template, based on the ppDATE depicted in Fig. 2. Let us call it one-at-a-time. This template has two parameters: C, which represents a condition, and S, which represents a method name. Then, by executing the action create(one-at-a-time, cups < limit, brew), it would instantiate the ppDATE depicted in Fig. 6, i.e., C is instantiated with cups < limit and S is instantiated with brew. This ppDATE specifies the property: it is not possible to brew one more coffee cup until the brewing process is done.
one-at-a-time = λ C, S : cond, trigger. In the rest of this work we will only consider the use of deterministic ppDATEs. Formally:

Definition 10
We say that a ppDATE m is deterministic if, for any two transitions of m with same trigger tr which go from a state q to a different state, their conditions are mutually exclusive: ∀ tr, c, c , a, a , q, q , q · Note that the previous property should hold for any possible instance of the (boolean) variables appearing in both c and c . In addition, although determinism on the Hoare triples' preconditions is not problematic in itself, we choose to extend the determinism condition to ensure that for any two Hoare triples in a single state over the same function have disjoint precondition so as to have a more effective monitoring algorithm of these triples: for any After having defined (individual) ppDATEs, we can now define a network of ppDATEs.

Definition 11
A ppDATE network pn is represented with a tuple (M, V, ν 0 , T ppd ): -M is a set of ppDATEs. If m ∈ M, then we say that m = (Q m , t m , B m , q 0m , Π m ).
-V is a set of ppDATE variables.
ν 0 is the initial valuation 5 of variables in V.
-T ppd is a set of ppDATE templates.
Note that on a network, whenever a trigger is activated, several ppDATEs can have an enabled transition ready to be fired, i.e., a transition whose trigger is active and whose condition holds. Whenever this happens all these enabled transitions are fired in parallel. Also note that the set of ppDATE variables V is global to the network of ppDATEs, rather than local to individual ppDATEs. Thereby, V is effectively the 'shared memory' of the network.
Finally, we extend the notion of deterministic ppDATE to a ppDATE network.

Definition 12
A ppDATE network pn = (M, V, ν 0 , T ppd ) is deterministic whenever every ppDATE in M is deterministic and every ppDATE which can be created when executing action create is deterministic.

ppDATE semantics
In this section we present the semantics of a network of ppDATEs by introducing structural operational semantics (SOS) rules. These rules will show how a global configuration is shifted to a new one by considering events and system variables valuations in a system trace. Informally, a global configuration (L , ν) (of a ppDATE network) consists of a set L of local configurations (one for each ppDATE in the set of ppDATEs of the network and one for each generated instance of a ppDATE template), and a valuation ν of the set of ppDATE variables V (associated to the ppDATE network). The local configurations store the current state, and record, for each ongoing method execution whose precondition was fulfilled at call time, the postcondition to be checked on exit. Every time the system under scrutiny generates an event, e.g., by entering or leaving a method, all local configurations in L with enabled transitions will replace their current state value by the state indicated in the fired transition, and execute the action of this transition, all simultaneously. For instance, given a ppDATE m whose current state is q, and with a transition t 1 of the form q tr|c →a − −−− → m q , when a system event triggers tr (and condition c holds), then t 1 is fired, state q is replaced by q in the appropriate local configuration in L, and a is executed. If the executed actions contain ppDATE variables assignments, the valuation ν is updated. In addition, any action event generated by these executions will be stored in a buffer.
Once all the previous enabled transitions are fired, every transition that become enabled by the events in the buffer will be fired as well. For instance, let us assume that action a in transition t 1 (only) generates the action event h, i.e., a = h!, and that a ppDATE m running in parallel to m is in state q , and has a transition t 2 of the form q h?|true →a − −−−−−− → m q . Then, whenever t 1 is fired, execution of h! will add to the buffer an event which will enable t 2 , due to the fact that trigger h? is activated by h and its condition (trivially) holds. Therefore, after firing t 1 , t 2 will be also fired.
Note that the buffer will be emptied before firing the transitions enabled by the events consumed from the buffer. Therefore, the buffer only contains events generated by the recent action executions, and no events from previous ones. This procedure is repeated until no new action event is generated, i.e., the buffer is empty. In general, the process may not terminate, however if we want to guarantee termination, we can adopt an approach which ensures that there is no transitive mutual communication dependencies over the set of automata as explained in the original semantics of Larva [18].

Events, valuations, and traces
ppDATE networks describe which system behaviours are allowed, and which are not. Here, we consider as behaviour basically a series of system events, where each event also comes with a 'snapshot' of the values of (visible) system variables, taken at the time where the event occurs. Formally, these snapshots are valuations, i.e., mappings from variables to values (of adequate types). Apart from the observed system, the ppDATE networks themselves may create new events.
An event may therefore either be a system event (i.e., generated by the system under scrutiny due to entering or leaving a method) or an action event (i.e., generated by the execution of an action ! in a ppDATE transition). Formally:

Definition 13
Given a set of method names Σ, the syntactic category of events is defined as follows: ξ ::= systemevent | actevent systemevent ::= systemtrigger N A systemevent consists of a systemtrigger which is indexed with a natural number representing the nth execution of the method associated to the trigger. Such an index will be considered an identifier 6 unique to each execution of the method.
We distinguish the set of system variables valuations Θ Sys , with typical element θ , and the set of ppDATE variable valuations N , with typical element ν. We represent valuations both as functions and (functional) relations 7 , i.e., sets of pairs. This means that the notation β(v) = val is equivalent to the notation (v, val) ∈ β. The union of valuations is therefore a set union such that, for any two valuations β and β , In the presentation of examples, we limit the valuations to those variables which matter for the example at hand, for simplicity.
In our semantic rules, we will use union over valuations only when the domain of valuations do not overlap, as for instance in θ ∪ ν. Another operation on valuations is the modification of a valuation β at variable x by value val, written β[x ← val]. It is defined as: Given a set of variables S, a valuation β for S, and condition c ∈ cond S , we will write β | c to denote that c is satisfied by β. This is however not sufficient for postconditions as they can refer to two valuations, after and before ("\old") a method's execution. For that, | will be overloaded. Given a set of system variables Sys, valuations θ and θ , and a postcondition c ∈ postcond Sys , we will write θ, θ | c to denote that c is satisfied by θ and θ . When this is used, θ will be the current valuation of Sys when exiting a certain method execution, whereas θ holds the valuation from before that method execution. We only sketch the definition of | here as it follows the standard of first-order logic semantics. We use the two semantic truth values T and F. For c ∈ cond S , we define β | c iff eval β (c) = T , where eval β is recursively defined over the structure of c as standard in first-order logic 8 The only case in the definition where the pre-valuation θ matters is the evaluation of \old-expressions: eval θ,θ (\old(e)) = eval θ (e). This means that, in postconditions, the post-valuation θ acts as the default, however not inside \old-expressions, where instead the pre-valuation θ counts. The other additional operator in postconditions is \result. To handle its evaluation properly, we assume a special system variable named \result. Whenever a non-void method returns, its return value, say val, is assigned to \result, such that, in the postvaluation θ , we have θ (\result) = val.
A system trace is a sequence of tuples consisting of an event and a 'system snapshot', i.e., a valuation of the system variables taken at the time when that event occurs.

Configurations
Given a system trace w, each tuple in w will shift a global configuration of a ppDATE network to another. Global configurations are defined in terms of local configurations.

Definition 15 Given a set of method names Σ, a local configuration is a tuple (m, q, ρ)
where m is a ppDATE, q ∈ Q m , and ρ ⊆ P(systemevent × postcond Sys × Θ Sys ).
The tuple (m, q, ρ) is a configuration of ppDATE m-where q represents the current state, and ρ allows to monitor potential violations of Hoare triples. For that, ρ stores which exit event (∈ systemevent) should cause a checking of which postcondition (∈ postcond). The semantic rules described below (Sect. 6.4) will guarantee that only method exit events (of the form σ ↑ i ) will appear in ρ. During the processing of a trace, the appearance of (σ ↓ i , θ) at the same time as the current state has a Hoare-triple with a fulfilled precondition, θ | π, the corresponding postcondition π is associated with σ ↑ i in ρ, together with θ . Later, the appearance of (σ Example 5 Recall the ppDATE illustrated in Fig. 2, here called m. Its initial local configuration is (m, q, ∅). Then, after firing transition t 1 whenever the system event brew ↓ id (with id ∈ N) occurs, assuming that the field cups is valuated to zero, the next local configuration Before giving an example, we define the notion of initial global configuration for a ppDATE network.

Definition 17 Given a ppDATE network pn
In the above example, the action v = v + 1, does not generate any event. In general, however, actions may generate events. For storing action events (and process them in the next step), we introduce the concept of extended global configuration.

Definition 18
Given a ppDATE network pn = (M, V, ν 0 , T ppd ), and a set of system variables Sys, an extended global configuration for pn is a tuple (L , ν, E, θ) such that: E contains the events to be processed in the next (small) step. In the operational semantics to be described below, E will either be a singleton set containing a system event, or a set of action events generated by the executions of actions in the latest transition.

Example 7 Let us assume a ppDATE network pn
with q 1 and q 1 the initial states of m and m , respectively. In addition, let us assume that Then, when the given transition of m is fired, given that π holds and the current system variables valuation is θ , the next extended global configuration for pn is After that, event h in C 1 triggers the given transition of m , leading to the extended global configuration The structural operational semantics given in Sect. 6.4 formalises such behaviour.

Semantics of actions
When assigning meaning to actions, there are two levels to consider. One is the level of the local actions, executed when an individual ppDATE takes a transition. The semantics of those is sequential, as defined below. On top of the assignments changing the ppDATE variable valuation, the local actions may generate events, and create new instances of ppDATE templates.
The other level is parallel actions, where we compose simultaneous actions of transitions taken in parallel by different ppDATEs. Here, we need to devote special care to exclude conflicting writes to, as well as race conditions between reads and writes from/to, the same variable. Also, we need to make sure that if only one ppDATE writes to x, then the parallel composition propagates this effect. All this makes it necessary to keep track of all reads and writes at the local level, prior to execute the parallel composition. However, the treatment of the local effects and newly created ppDATEs is simpler: we just take the union of those when doing the parallel composition.

Definition 19
For each a ∈ action, its meaning [[a]] θ,ν (relative to system/ppDATE variable valuations θ and ν) is given by a tuple (ν , W, R, E, N ew), where: ν ∈ N is a ppDATE variable valuation computed (locally) in a, -W ⊆ V is a set of ppDATE variables written to in a, -R ⊆ V is a set of ppDATE variables read from in a, -E ⊆ actevent is a set of action events generated in a, -N ew ⊆ ppDATE is a set of ppDATEs newly created in a.
Given that pvars returns the ppDATE variables appearing in its argument(s), Following the definition of actions (Definition 2), the prog in the last line above is a side-effect free program, i.e., it has no effect which could be noticed in the current formalism, which is why we can simulate it with skip. prog will have purposes orthogonal to our formalisation, like logging.
We are now in the position to define the parallel composition of actions. Imagine we have a configuration with 5 parallel ppDATEs, 3 of which have enabled transitions, with actions a 1 , a 2 , and a 3 , respectively. Assume moreover that the current ppDATE variable valuation is ν. The parallel composition of the meaning of a 1 , a 2 , and a 3 , is performed by The function mergeParalActs takes a set of semantic actions as input, and computes a resulting valuation ν , a resulting set of events E , and a resulting set of newly generated ppDATEs, N ew . The sets E and N ew will simply be the union of the corresponding sets from But the resulting valuation is slightly more involved. Actions may conflict (e.g., we write to the same variable in different actions), or have race conditions (i.e., we read from a variable and write to it in different actions). In those cases, we leave the result of mergeParalActs deliberately undefined. In all other cases, the different effects of the actions are merged. The index of the merging function, ν, serves as a fall back for those variables which have not been written to. In particular, ν = ν in case the set of actions to be merged is empty.
These explanations are formalised in the following function, merging a set of action meanings (Definition 19):

Structural operational semantics
In this section we give structural operational semantics rules (SOS) for ppDATEs. These rules will have the following generic form: where name is a label used to identify the rule, Goal is the property enforced by the rule and the premises H 1 , · · · , H n are assumptions over the values of the Goal.

Auxiliary predicates
In the semantic definitions given below, we use the following predicates. activatedBy Given a (transition) trigger tr and an event e, predicate activated By(tr, e) holds if tr and e match, in the following way: For instance, the trigger σ ↓ is activated by the systemevent σ ↓ 3 , and the trigger h? is activated by actevent h (generated before by the execution of action h!). nextState Given a local configuration (m, q, ρ), a state q , an event e, a system variables valuation θ and a ppDATE variables valuation ν, predicate next State holds whenever there exists an enabled transition on m going from q to q . We formally write this as follows, activated By(tr, e) and θ ∪ ν | c checkOnExit Given a local configuration (m, q, ρ), a system event σ ↓ id , a system variables valuation θ , and a postcondition π , predicate check On E xit holds if there exists a condition π such that the Hoare-triple {π} σ {π } is associated to state q, and π holds. We formally write this as follows, enabled Given a local configuration l, an event e, a system variables valuation θ , and a ppDATE variables valuation ν, predicate enabled holds if either l has an enabled transition or it has a Hoare triple associated to q which has to be memorised. Formally, toBeExecuted Given a local configuration (m, q, ρ), an event e, a system variables valuation θ , a ppDATE variables valuation ν, and an action a, predicate toBeE xecuted holds if there exists an enabled transition such that a is its action.

Small steps for local configurations
The first step to define SOS rules describing the behaviour of a ppDATE network is to introduce rules showing how a local configuration performs a small step.
Given an event e, a system variables valuation θ , and a ppDATE variables valuation ν, a small local configuration step (or simply small step local), written (e,θ,ν) −−−→, takes a local configuration (m, q, ρ) to some other local configuration (m, q , ρ ). This step relation is defined by the rules shown in Fig. 7. If e is an entry event of the form σ ↓ id , there are three different possibilities: (i) there is an enabled transition in m going from state q to state q , and there is a Hoare triple {π} σ {π } associated to q such that π holds (entr y 1 ); (ii) there is an enabled transition in m going from state q to q , but no Hoare triple {π} σ {π } associated to q such that π holds (entr y 2 ); or (iii) there are no enabled transitions in m, but there is a Hoare triple {π} σ {π } associated to q such that π holds (entr y 3 ).
In case of (entr y 1 ), the next state reached by the enabled transition is q , and ρ gets extended by the tuple (σ ↑ id , π , θ), in order to track the information about the postcondition which has to be checked upon the exit of method σ . Entry event identifiers are assumed to be unique in traces, and thereby, σ ↑ id is unique in ρ. In case of (entr y 2 ) and (entr y 3 ), only one of these two effects takes place. Then, apart from entry events, whenever e is either an exit event, i.e., it has the form σ ↑ id , or an action event, by the rules exit and act, respectively,

Small steps for extended global configurations
Given an extended global configuration EC = (L , ν, E, θ), the relation small step for extended global configurations (or simply small step global), written as , takes EC to some extended global configuration (L , ν , E , θ) by following rule iter (depicted in Fig. 8). Note that in the rule's premises we define the set L en of all the local configurations (m, q, ρ) ∈ L such that m has an enabled transition whose triggers are activated by the events in E. L en is used to define both the set L nch of local configurations in L that will not change, and the set L ch of the local configurations obtained after performing a small step on the local configurations in L en . These two sets are used to define L . Next, we define the set Acts of all the actions which label the 'firing' transitions, and merge the meaning of those actions, which results in the valuation ν and events E of the new extended global configuration. We also initialise local configurations L new for the newly created ppDATEs from N ew . Finally, L is the union of L ch , L nch and L new . Note that if mergeParalActs is undefined, due to conflicts in parallel variable assignments (see Definition 20), then no global small step is defined, i.e., the execution aborts.

Big steps for global configurations
Given a ppDATE network pn = (M, V, ν 0 , T ppd ), a global configuration (L , ν) such that for all (m, q, ρ) ∈ L, m ∈ M and q ∈ Q m , and ν a valuation of the ppDATE variables V , a system event e and the system variables valuation θ , the relation big step rules for global configurations (or simply big step global), written ⇒ (L , ν ), by rule shift given in Fig. 9. Note that here e and θ are external to the global configuration of the ppDATE network: they come from the system acting as input to each step of the global configuration.
This rule means that whenever e occurs while the current system variables valuation is θ , (L , ν) shifts to (L , ν ) if the transitive closure of the relation small step global ( , Fig. 8) takes the extended global configuration (L , ν, {e}, θ) to the extended global configuration (L , ν , ∅, θ). We need the transitive closure because the execution of actions may generate action events which also have to be consumed, meaning that we iterate using small step global until the set obtained by applying rule iter is the empty set. After having reached (L , ν , ∅, θ), the small steps are saturated, because any configuration ( , , ∅, ) is a fixedpoint of .

Lemma 1
For each set of local configurations L, ppDATE variable valuation ν, and system variables valuation θ , the extended global configuration (L , ν, ∅, θ) is a fixed-point of the relation small step global, i.e., Proof In rule iter (Fig. 8), if E = ∅, then L en = L ch = Acts = ∅, and L nch = L. From the note below Definition 20, we deduce that We can now define the semantics of ppDATEs by identifying how a system trace changes the global configuration associated to a network of ppDATEs.

Definition 21
We define how a system trace w ∈ (systemevent × Θ Sys ) * shifts a ppDATE from the global configuration (L , ν) to the global configuration (L , ν ), written (L , ν) w ⇒ (L , ν ), by induction over w: For this definition we will overload the operator we previously introduced to represent the relation big step global, i.e., ⇒ since it is straightforward to distinguish between the two from the context.

Valid traces and violating traces
Before defining violating system traces, we have to introduce the notion of counter-example.

Definition 22 Given a network of ppDATEs
(The symbol + + represents the concatenation of traces.) This means that a counter-example either (i) ends in a bad state (in one of the local configurations), or (ii) ends with the exiting of a method execution who's postcondition (stored in ρ) is currently violated. Note that (i) and (ii) are not exclusive, so a counter-example may have both properties at once. Also note that violations of preconditions when entering methods is not mentioned here. In our semantics, the violation of preconditions does not as such result in a counter example. It only means that the postcondition of the corresponding Hoare triple does not need to be checked further on (see entr y 2 , Fig. 7).

Example 8
Recall the ppDATE m shown in Fig. 2, and let us assume that it is in state q. Then, for any system variables valuation θ , w = (brew

Definition 23
The set of violating system traces of a ppDATE network pn, written VT ( pn), is defined to be system traces which have a counter-example of pn as a prefix.

Definition 24
The set of valid system traces of a ppDATE network pn, written VAT ( pn), is defined to be the system traces which are not violating.

Example 9
The following system traces, for the coffee machine system of Fig. 2, are all valid:

From ppDATE to DATE
In our framework, KeY first tries to prove all Hoare-triples of a ppDATE m, and then the partial proofs are used to get an optimised ppDATE m . To make the property m runtimecheckable, we further translate away the (remaining/optimised) Hoare triples, to arrive at a set of parallel (pure) DATEs that can be processed by Larva.
In this section, we formally define DATEs, we present the algorithm used by StaRVOOrS to translate ppDATEs into DATEs, finally, after introducing the semantics of DATEs, we prove soundness of the translation.

DATE
DATE [18] is a formalism similar to ppDATE, except that the automata do not include Hoare triples in the states. DATEs also include support for timers, which are not in ppDATEs. However, since the work we present here does not use timers, we leave them out from the formalisation. Formally: 9 Definition 25 A DATE is a ppDATE of the form (Q, t, B, q 0 , Π ∅ ), where relation Π ∅ represents that there are no Hoare triples assigned to any of the states in Q, i.e., Π ∅ (q) = ∅, ∀q ∈ Q.
Note that since a DATE is effectively a ppDATE, the semantics for DATEs are already covered by the semantics of ppDATEs. We will also refer to a (deterministic) network of ppDATEs where each ppDATE in the network is a DATE, as a network of DATEs and similarly DATE templates.

Translation from ppDATEs to DATEs
Here we present how to translate a ppDATE (network) into a DATE (network). However, first, let us intuitively analyse how the ppDATE depicted in Fig. 2, which we will refer to as m, can be translated into a DATE m .
For simplicity, we assign the following names to the different Hoare triples in the states of m.
Then, we begin the translation by generating the DATE template illustrated in Fig. 10, which will be used to create DATEs in charge of controlling the postconditions of the previous Hoare triples.
Next, we start dealing with the translation of the transitions of m. m will have exactly the same set of states as m, and it will have similar transitions to the ones of m. The only difference is that the transitions in m will also have to address the verification of the Hoare triples. For instance, while being in state q, if the method brew() is executed and the precondition of h 1 holds, then its postcondition will have to be verified whenever method brew() finishes its execution.
In the previous transitions we have used as the conditions of the if-expressions in actions a 1 , a 2 and a 3 , the preconditions of the different Hoare triples to be verified in each case. Moreover, function part_eval partially evaluates its argument, replacing the expressions \old(e) operator the current value of e. If a postcondition does not include such operator, then part_eval is the identity. Note that even though the if-expression in the transitions t 1 and t 4 may seem unnecessary, we include it anyway in order to exactly reflect how the translation algorithm works. Translation to DATE of the ppDATE illustrated in Fig. 2 In addition, if at a certain state, a Hoare triple has to be verified, but in that state there are no outgoing transitions with an event related to the method in the Hoare triple, then a new transition is added to m in order to be able to control such Hoare triple. For instance, in state q the following self-transition has to be added in order to verify h 2 and h 3 .  Figure 11 illustrates the DATE obtained when translating m following the previous steps. Note that whole translation would consist on the previous DATE and the generated template exit_cond_checker.

Translation algorithm
For clarity of presentation we give two algorithms, one for the case when no Hoare triples clashes arise, and one for the full case. Intuitively, we call it a clash if the behaviour of a method σ , in a certain ppDATE state q, is defined by both, a Hoare triple in q, and an outgoing transition from q. Formally, we define a clashing Hoare triple as follows. We now present the algorithm to translate a clash-free ppDATE network into a DATE network. The translation works by replacing each Hoare triple {π} σ {π } in a state q of a ppDATE by a new reflexive transition (from q to q) triggered by an entry into function σ such that the precondition π holds, and a parallel DATE is created, checking the postcondition.
We assume a function part_eval ∈ postcond → cond, which removes \old constructs in postconditions. The function performs partial evaluation-replacing each \old(e) with the current value of e. Our algorithm syntactically places the part_eval function in an action that will be executed when the according method is entered, i.e., partial evaluation does not happen during the translation algorithm, but at runtime, when the method is entered.
Algorithm 1 Given a clash-free ppDATE network pn = (M, V, ν 0 , T ppd ), such that every ppDATE m ∈ M is defined as the tuple (Q m , t m , B m , q 0m , Π m )  This translation works well except that it would introduce non-determinism when the ppDATE includes clashes. To extend the translation to work in the presence of clashes, we transform Hoare triples clashing with a transition into a family of disjoint transitions, each of which performs the transition but also checks whether the postcondition checker should be created.

Proof of soundness of the translation algorithm
In this section we will show that the translation algorithms introduced in the previous section are sound.

Coupling invariant lemmas
Here, we formally introduce two lemmas which together form the coupling invariant that is used to prove soundness. The proofs of these lemmas can be found in "Appendix 1". Lemma 2 states that given a trace, both a ppDATE network pn and its translation to DATE will change their initial global configuration to global configurations (L , ν) and (L, ν ), respectively, such that ν = ν , and that for every (m, q, ρ) ∈ L where m is in pn, there is a local configuration (m , q , ∅) ∈L such that m is the translation of m and both m and m are in the same state, and vice versa.
In this lemma we represent the translation of a single ppDATE to DATE with the function κ ∈ ppDATE → DATE.
Lemma 3 states that given a trace, if this trace shifts a ppDATE network pn and its DATE translation from their respective initial global configuration to some global configurations (L , ν) and (L, ν ), respectively, then for each entry (σ ↑ id , π , θ) in a ρ component of a local configuration in L there is one local configuration inL whose DATE component is an instance of the template exit_cond_checker in charge of controlling π , and vice versa.

Proof of soundness
We can now prove the soundness of the translation algorithm. Below we provide the formalisation of this property and an intuitive explanation for it. However, a rigorous proof of this theorem can be found in "Appendix 2". Proof To prove the soundness of the translation algorithm we will show that both a ppDATE network pn and its translation to a DATE network have the same set of violating traces. Intuitively, we will prove that given a trace w which is violating for pn, i.e., w ∈ VT ( pn), is also violating for pn's translation, i.e., w ∈ VT (ppd2DATE( pn)), and vice versa.
In the case when w ∈ VT ( pn), by definition of counter-examples of ppDATEs, w has a prefix w such that either (i) w takes the initial global configuration C init ( pn) to a global configuration (L , ν ) such that the state component of L is a bad state; (ii) given a method σ and a system variables valuation θ , w can be written as w 1 + + (σ ↑ id , θ ) such that w 1 takes C init ( pn) to a global configuration (L , ν ) where there exists a local configuration in L whose ρ component contains a tuple (σ ↑ id , π , θ), such that π fails to be satisfied in the 'moment' event σ ↑ id appears. In the case of (i), we use the fact that (by Lemma 2), if w takes the translation from the initial global configuration C init (ppd2DATE( pn)) to a global configuration (L, ν), for every local configuration in L , there is a local configuration inL such that its state component is the same. Thus, there is a local configuration inL whose state component is a bad state, which means that w is a counter-example of the translation as well.
In the case of (ii), due to the fact that a Hoare triple {π} σ {π } has to be verified, we know that some local configuration will have a ρ component such that (σ ↑ id , π , θ) ∈ ρ. We can now use the fact that by Lemma 3, tuple is handled by a DATE in the translation (which verifies the postcondition). Thus, there exists a DATE controlling π which fails moving to a bad state, i.e., w is a counter-example of the translation as well.
In order to prove the opposite direction, we assume w ∈ VT (ppd2DATE( pn)). Again, since this is a counter-example and this is a DATE (and thus cannot fail due to a violated postcondition), it can be only the case that w has a prefix w such that this prefix takes the initial global configuration C init (ppd2DATE( pn)) to a global configuration (L, ν) such that there is a local configuration inL whose state component is a bad state. Then, assuming that w takes pn from the initial global configuration C init ( pn) to a global configuration (L , ν ), we proceed to do a case analyses depending whether the bad state belongs to a DATE which was controlling the postcondition of a Hoare triple or not. In the affirmative case, we will use this fact to show that, given certain method σ and a system variables valuation θ , w can be selected to be a prefix which can be written as w 1 + + (σ ↑ id , θ ) such that w 1 takes C init ( pn) to a global configuration (L , ν ) where the verification of the postcondition fails whenever event σ ↑ id occurs. Therefore, w is a counter-example of pn. Finally, (by Lemma 2), there is a local configuration in L such that its state component is the same as the bad state inL. Therefore, w is a counter-example of pn.

The STARVOORS tool implementation
In this section we present how the (fully automatic) verification tool StaRVOOrS [16] implements the framework presented in Sect. 4. To illustrate this, we use a running example of a bank system in which users log in to perform transactions. 10 The set of logged-in users is implemented as a Hashtable object, whose class represents an open addressing hashtable with linear probing as collision resolution. Method add, which is used to add objects into the hashtable, first attempts to put the corresponding object at the position of its computed hash code. However, if that index is occupied, then add searches for the nearest following index which is free. Figure 12 depicts a code snippet for this method. Within the hashtable object, users are stored into an array arr. This means that the set of logged-in users has its capacity limited by the length of arr. In order to check in a straightforward manner whether the capacity of arr is reached or not, a field size keeps track of the amount of stored objects and a field capacity represents the (total) number of objects that can be added into the hash table. In addition, this system has to fulfil the properties described with the ppDATE template depicted in Fig. 13. This template specifies the following properties: bad triple is only included in state q 1 since only a successful login leads to the execution of the method add, i.e., this Hoare triple is context dependent; and that login(f) ↓ means that method login associated to the trigger is the one defined within object f . In addition, we assume that the specification of the system has a ppDATE with a single state q and single

ppDATE specification as an input script for STARVOORS
Before describing how StaRVOOrS works, we need to introduce how a ppDATE specification is written as an input script for this tool. Below, we show the input script for the ppDATE template illustrated in Fig. 13, and the ppDATE which creates its instances. In addition, we give a brief description of each one of the sections this script. For a full description on how to write ppDATEs as an input script for our tool, one may refer to the The section IMPORTS lists the Java packages which may be used in any of the other sections of the script, in this case UserInterface and Hashtable. The section TEMPLATES contains the description of the ppDATE templates (tagged by TEMPLATE). Here, the section TRIGGERS is used to declare the different triggers which may be used in the transitions of the ppDATE, i.e, login_exit, logout_entry, deposit_entry, and the section PROPERTY describes the different states, i.e., q1, q2 and bad, and transitions of the ppDATE. Note that the syntax q1 (add_ok) associates the Hoare triple tagged as add_ok to state q1. This means that the Hoare triple add_ok has to be verified if the method associated to it, in this case method add, is executed whenever the ppDATE is in state q1. The section GLOBAL contains the description of the ppDATE. Here, ppDATEs are described in the same manner as in a TEMPLATE section. However, note that it is also possible, as it is the case in our example, to use the special section PINIT when describing the section PROPERTY. Section PINIT represents a ppDATE with single state, and a looping transition which is fired every time an object of the class listed within this section (UserInterface in our example) is declared, leading to the creation of an instance of the listed template for that object (prop-deposit-temp in our example). We have included this special case because it is quite common to have ppDATEs only focus on creating instances of a template upon declaration of a particular object. Regarding the section CINVARIANTS, class invariants are described by the syntax class_name {invariant}, meaning that invariant has to be fulfilled by all the methods in the class class_name. These invariants are only meant as a help for the deductive verification of the Hoare triples (see Sect. 8.2). If no invariants are needed, then this section can be omitted. Finally, the section HTRIPLES gives a list of named Hoare triples (tagged by HT). Here, PRE describes the precondition of the Hoare triple, POST describes the postcondition of the Hoare triple, METHOD indicates which one is the method associated to the Hoare triple, and ASSIGNABLE lists the (class) variables that might be modified when the method associated to the Hoare triple is executed. Note that the predicates in invariants, pre-and postconditions follows JML-like syntax and pragmatics. For instance, in the Hoare triple add_ok the second semicolon separates the range predicate (i > =0 && i < capacity) from the desired property over integers in that range, (arr[i]==o).

Running STARVOORS
StaRVOOrS is a fully automatic verification tool which takes the Java source code of the system under scrutiny and a file with the ppDATE specification for this system and produces (i) a runtime monitor, (ii) an instrumented version of the system given as input with event generation and additional code infrastructures required, (iii) a report summarising the results of the deductive verification of the Hoare triples, and (iv) a refined version (if any) of the provided ppDATE specification.
This tool implements the framework described in Sect. 4 with each stage of the framework, i.e., Deductive Verification, Specification Refinement, Translation and Instrumentation, and Monitor Generation, being performed automatically by the tool. Below, we describe the implementation of these stages through the use of the working example.

Deductive verification
The first step performed by StaRVOOrS is the deductive verification of the Hoare triples associated to the states of the ppDATE (template) using KeY. To accomplish this, StaR-VOOrS extracts the Hoare triples specified in the ppDATE script, converts them into JML contracts, and then annotates these contracts in the Java sources, before the corresponding method declaration. For instance, the following JML contract associated to method add is extracted from the Hoare triple add_ok: requires size < capacity; ensures (\exists int i; i>= 0 && i < capacity ; arr[i] == o); assignable size, arr[*]; Note that the requires clause describes the precondition of add, the ensures clause describes the postcondition of add, and the assignable clause lists the (class) variables that might be modified when add is executed.
Once all the JML contracts are in place, i.e., they are annotated in the code, StaRVOOrS uses KeY to verify them. First, KeY generates proof obligations in Java Dynamic Logic for each JML contract. Next, it attempts to prove the contracts automatically. Finally, it stores the results of all the verification attempts in a XML file. Here, note that even though it could be possible to allow for user interaction (using KeY's elaborate support for interactive theorem proving), we chose to use KeY in automatic mode, since StaRVOOrS targets users untrained in theorem proving. StaRVOOrS generates a report summarising the results produced by KeY in an easy to understand format.
Using our running example, when KeY tries to verify the previous JML contract, it will result in a partial proof. This analysis is shown in the following fragment of the generated XML file: <executionPath pathCondition="arr[hash_function(key)] = null" verified="true"/> <executionPath pathCondition="!arr[hash_function(key)] = null" verified="false"/> This indicates that while KeY was symbolically executing method add, there was a branching in the condition arr[hash_function(key)] = null, leading to two possible execution paths (depending on its truth value). Recalling the code snippet in Fig. 12, this condition corresponds to the condition on the if-expression in line 4. Thus, the execution path for the condition arr[hash_function(key)] = null corresponds to the case where the array arr has a free slot at the hash code of key, whereas the execution path for the condition !arr[hash_function(key)] = null corresponds to the case where the program enters the while-loop in line 10, searching for the next free slot in arr. In addition, in the XML, the component verified represents whether KeY was able to prove the branch of the proof (verified=true), or not (verified=false). Therefore, from the previous fragment of the XML file we know that KeY was able to close the branch where the array arr has a free slot (= null) at the hash code of key, but it was not able to verify the other case (where the program enters a loop searching for the next free slot). The main reason why KeY was not able to prove the latter case is the lack of loop invariants to deal with the while-loop.

Specification refinement
The output of KeY is then used to refine the Hoare triples in the specification based on what was (partially) proved. The Hoare triples associated to JML contracts which were fully verified by KeY are entirely removed from the specification, while the precondition of the Hoare triples associated to partially proved JML contracts are refined based on what KeY managed to prove. The new precondition is the conjunction of the original precondition with the disjunction of new preconditions corresponding to open proof goals, i.e., the path condition on each different execution paths. Note that StaRVOOrS generates a new ppDATE specification script based on such refinements, instead of modifying the provided ppDATE script.
In the example, the precondition of the Hoare triple add_ok will be refined with the condition for the one goal not closed by KeY, i.e., !(arr[hash_function(key)] == null). The Hoare triple will thus be strengthened as follows:

Translation and instrumentation
Once the refined ppDATE specification is ready, StaRVOOrS translates it into (pure) DATE formalism using the algorithm from Sect.7.2. This enables the monitor generation by Larva (explained in the next stage). In addition, in order to properly address the refined ppDATE, our tool operationalise the conditions and instruments the code, as described below.

Pre/postcondition operationalisation
In this step, the tool syntactically analyses the specification for expressions in pre-and postconditions of the Hoare triples which may have to be operationalised, i.e., transformed into algorithmic procedures. For instance, transforming either existential or universal quantifications into loops.
During the operationalisation process, the tool creates Java code containing the implementation of all necessary methods for runtime verification, including those generated to algorithmically check the pre/postconditions.
In our example, as the postcondition of the Hoare triple add_ok has an existential quantifier, it has to be operationalised, producing the following method: The for-loop declaration in line 3 is created from the conditions in the range of the existential quantification, i.e., i > =0 && i < capacity, and the condition of the if-expression in line 4 is created from the condition in the body of the existential quantification, i.e., arr[i]==o. Thus, if any value on the range of the existential quantification fulfils its body, then this method returns true, i.e., exists a value that fulfils the existential quantification. Otherwise, it returns false, i.e., it does not exist a value fulfilling the existential quantification.

Code instrumentation
Next, StaRVOOrS instruments the Java source code of the system adding identifiers to each method associated to a Hoare triple in the refined ppDATE specification script, and additional code to get fresh identifiers. As mentioned in Sect. 4, these identifiers will be used to distinguish different executions of the same method. However, in order to avoid modifying all the calls to these methods in the entire system, we have opted to introduce this instrumentation in the form of auxiliary methods. For instance, in our working example the method add has to be instrumented, resulting in: The method addAux implementation corresponds to the body of method add in Fig. 12. This method represents the instrumentation of method add with the extra argument Integer id, which is used as identifier. In addition, method add now simply calls addAux, but generating a fresh identifier for the call using function fid.getNewId.
Moreover, the previously generated DATE specification is modified accordingly, to refer to the instrumented version of the methods. In our example, the DATE specification would be modified to refer to method addAux instead of method add.

Monitor generation
Finally, StaRVOOrS uses Larva to automatically generate a monitor from the DATE specification obtained in the previous stage. Larva takes this DATE and generates the monitoring system and aspects instrumenting the communication between the system and the monitor [19].

Case study: SoftSlate Commerce
SoftSlate Commerce (or simply SoftSlate) [36] is an open-source Java shopping cart web application designed following a Model-View-Controller architecture. A user of SoftSlate sends a request to a server hosting the application via a web browser. Then, the server processes the received request and executes an action associated to it (Controller layer). Such action may require to interact with and/or modify the information in the database (Model layer), e.g., information about users, products, orders, etc. Finally, once the request is fully processed, the server sends back a response to the user. The information in this response will be reflected on a web page loaded on the browser (View layer). The administrator of the application interacts with it in a similar fashion.
SoftSlate offers a basic implementation of a shopping cart web application featuring outer space related pictures, whose server is set up by using Apache Tomcat [1]. This implementation is meant to be used by developers to start building their own web applications.
In this case study we analyse an extension of the SoftSlate basic implementation. This extension increases modularity of parts of the implementation, to better link it to the required properties. Basically, we have created a few helper methods in order to better observe the various steps performed by a user to checkout a purchase. In addition, we have modified a few methods to receive an entire object instead of some of its components, and to properly access the components.
As our main focus is to verify the source code offered by SoftSlate, in our extension we are not adding any new feature to the ones already provided in the basic implementation, i.e., the functionality of the basic implementation and our extension is the same.
Note that when we started developing this case study there was an open source version of SoftSlate available online. However, later, this version was not available anymore. Thus we cannot distribute the sources we have used. However, in [38] one may find the files for the ppDATE specifications described below.

ppDATE specification
Here we introduce two ppDATEs specifications, one describing a property related to the log in and log out of users in the web application, and one describing a property related to the checkout of the purchases performed by the users of the application. These properties address basic functionalities which we consider that a web cart application should offer.
Note that even though we could have either described more properties or specified more control-and data-oriented behaviour in the properties we are depicting in this section, the ppDATEs introduced here are sufficient to highlight the benefits of using StaRVOOrS in a real application. In addition, for readability reasons, Hoare triples are not going to be included on the figures depicting the ppDATEs. Moreover, as the application is placed in a server, the monitor generated by our tool is placed in the server as well.

Login-logout
Users can freely browse through the web site of the application. However, if they want to buy products (i.e., pictures), they have to be logged in the application, to be able to proceed to the checkout section. Figures 14 and 15 illustrate the specification. The ppDATE in Fig. 14 creates instances of the ppDATE template login-logout whenever an object of class User is created, and the ppDATE template login-logout (Fig. 15) describes the following properties:

i) A user has to be logged in the application in order to perform a purchase, i.e., the checkout of a purchase can only happen between a login and a logout. (ii) If a user is logged in, then that user cannot successfully log in again in the application until she logs out from it. (iii) If a user is not logged-in, then that user cannot successfully log out from the application. (iv) A user can only proceed to the checkout section if her status is a valid one.
(v) A user who is not a costumer cannot proceed to the checkout section.
The transitions of the ppDATE described by the template control properties (i)-(iii). Initially, this ppDATE is in state logout. Then, whenever there is a successful login, the ppDATE moves to state login. Later, once the user logs out, the ppDATE returns to state logout. Therefore, if a purchase is performed (i.e., an order is checkout) while the ppDATE is in state login, then the ppDATE remains in that state. However, if a purchase is performed while the ppDATE is in state logout, then it shifts to state bad. 12 In addition, while being at state logout, if an attempt to log in is not successful, then the ppDATE stays in that state; and if there is a successful logout, then the ppDATE shifts to state bad due to the fact the user is considered to be logged out while the ppDATE is in that particular state. Something similar happens when the ppDATE is in state login. (In Fig. 15, Fails and Ok are abbreviations, for presentation purpose, of real Java expression checking the failure or success of the respective operations.) Regarding properties (iv) and (v), they are addressed using Hoare triples. For instance, property (iv) is represented as follows: { !baseForm.getUserStatus().equals("Registered") && !baseForm.getUserStatus().equals("Unapproved"); } prepareCheckout(baseForm) { \result.equals("success"); } As the only non valid statuses are "Registered" and "Unapproved", if the status of the user is not one of these values, then starting a purchase, i.e., using method prepareCheckout, should return "success". Regarding property (v), a user is only considered to be a costumer if she has logged-in into the application. Even though this property seems to be similar to property (i), this similarity is only apparent. Property (i) only addresses the proper order in which the methods should be executed, whereas property (v) focuses on controlling how the data related to a user is modified during such executions. Finally, both properties (iv) and (v) are only placed in state login because that is the only state in which a successful purchase can occur, i.e., (iv) and (v) are context dependent data-oriented properties.

Purchases checkout
We consider that a purchase starts whenever an item (i.e., a product) is added to the cart. A user can continue either by adding other items to the cart or by removing some of the items from the cart. We refer to all the items in a cart as the order.
Once the user finishes the creation of her order, she may proceed to the checkout page. In SoftSlate, a checkout is realised in four steps. First, the user enters the contact information and delivery address. Then, the shipping method is selected (either ground transport or air transport), after which the user enters her credit card details. Finally, a confirmation for the order is requested. If accepted, the order is settled. Later, when the user receives the items, the order is considered to be completed.  Note that a user can modify her order as long as she has not yet confirmed it. If so, whenever she proceeds to the checkout section again, all its required steps have to be performed one more time. In addition, if the user removes all the items in an order, clears the cart or logs out, 13 then the order is considered to be removed. Figures 16 and 17 illustrate a ppDATE specification where the ppDATE in Fig. 16 creates instances of the ppDATE template prop-checkout whenever an object of class User is created, and the ppDATE template prop-checkout (Fig. 17) describes the following properties: (1) The checkout of a purchase should be performed following the four required steps.
(2) It should not be possible to buy zero or less items. Again, consider the transitions of the ppDATE described by the template. When the first item is added to the cart, the ppDATE shifts to state one. In this state, once the first step of the checkout is completed, the ppDATE shifts to state two, and so on until reaching state four. In state four, once the order is settled, the ppDATE shifts back to state start in order to wait for a possible new purchase. Moreover, while being at either state one, two, three or four, if there is any change in the order, then the ppDATE shifts to state one, meaning that all the steps of the checkout have to be performed again. This is enough to control property (1).
Note that for readability reasons, in states one, two, three and four we have not included transitions going to state start whenever the user logs out, the cart is cleared or all the items in the cart are removed. In addition, we have not included transitions going to state bad from either state one, two, three or four if a step of the checkout was performed in a wrong way. For instance, if while being at state one either a second step, a third step or a fourth step of a purchase occurs instead of the first step, then the ppDATE shifts to state bad.
Regarding property (7), since the method in charge of updating the orders whenever the price of an item changes in the database is fully implemented using different Java libraries, writing an appropriate Hoare triple for it would require introducing several work-arounds. Instead, we implemented a method which compares the prices of the items in the order with their prices in the database, and include it as part of the information validation process corresponding to the fourth step of the purchase. Thereby, in state four there are two transitions controlling the result of this method [Most real world applications of this kind would guarantee prices for some defined duration, and adjust it when that time has passed. For simplicity, we only model the latter in (7).].
Properties (2)(3)(4)(5)(6) are addressed with Hoare triples. Properties (2)(3)(4) are related to the integrity of the information introduced by either the users, in the case of (2) and (3), or the administrator, in the case of (4), on their requests to the server. Property (5) is related to the proper processing of taxes associated to the items in the current order. Property (6) enforces that the total amount that the user has to pay for her order should be equal to the sum of the totals of all the items included in the order.
As items could be added to the cart at any time during a purchase, property (2) is included in all the states of the ppDATE, with exception of the state bad.
On the other hand, property (3) is context dependent. This property should only be enforced on state three, which represents the step of a purchase where a user enters her credit card details. Note that, as it is in this case, a single property might be associated to several Hoare triples. For instance, below we introduce two of the four Hoare triples which describe property (3) Regarding property (4), we assume that initially all the data in the database is properly set. Therefore, this property should only be enforced every time that the administrator modifies the price of an item. As this may happen at any time during a purchase, this property is included in all the states of the ppDATE, with exception of the state bad.
In relation to property (5), in SoftSlate whenever the taxes of items are processed, the status of the order changes to "Tax processed". This change is done by using the following method, public void setStatus(String s) { status = s;} This method might be simply specified as follows: { true; } setStatus(s) { status.equals(s); } However, due to the fact that taxes are processed while the ppDATE is in state four, that we know which particular value should be written when updating the status of the order, i.e., "Tax processed", and that ppDATE allows us to write context dependent properties, we include in four the following Hoare triple: In short, the new total amount is equal to the old total amount plus the amount of the newly added item.

Using STARVOORS
The previous specifications were analysed on a PC Pentium Core i7 using a sinlge core. A similar setup was used to perform the experiments in the following Sect. (9.3). Since SoftSlate uses many Java libraries, to perform static analysis on its source code it was necessary to generate stub files for some of these libraries in order to allow KeY to find information about their method declarations.

Login-logout
When feeding StaRVOOrS with this property and the source code of SoftSlate, it automatically generates a runtime monitored version of the application and a report which summarises the results obtained from the static analysis.
Regarding the result of the translation, it consisted of a DATE specification which looks exactly like the original ppDATE specification. The static analysis and instrumentation process takes 11 seconds, where most time is used by KeY to statically analyse the Hoare triples (approximately 7 seconds). By inspecting the report we notice that KeY successfully verified all the Hoare triples in the ppDATE specification. Thus, the refined ppDATE specification to be translated was already a DATE, .i.e, the translation process did not have add any new transitions to the specification.

Purchases checkout
When feeding StaRVOOrS with this property and the source code of SoftSlate, it automatically generates a runtime monitored version of the application and a report which summarises the results obtained from the static analysis. The static analysis and instrumentation process takes 23 seconds, where most time is used by KeY to statically analyse the Hoare triples (approximately 20 seconds). By inspecting the report we can see that properties (2) and (3) are fully proved, properties (4) and (5) are not proved, and that property (6) and (7) are partially proved.
Regarding property (7), as KeY does not have any information about the state of purchases, and this property is context dependent, obviously, it is not able to prove it. However, thanks to the use of StaRVOOrS we can include this property in an appropriate state of the ppDATE, fact which guaranties that whenever a purchase reaches such state, this property is going to be verified at runtime by the generated monitor.
Regarding property (6), the report shows that this property postcondition is going to be checked upon entering method updateOrderAndDeliveryTotals only if the condition user.getOrder() != null holds. Thereby, this property is refined by StaRVOOrS as follows: This refined version of property (6) is the one verified by the generated monitor at runtime. Finally, the result of the translation consisted on one DATE to create instances of the obtained DATE template prop-checkout (the translation of its homonymous ppDATE template), and three generated DATE templates whose instances verify properties (4)- (6). Note that the instances of the generated DATE templates are created by actions on the transitions of the DATE template prop-checkout.

Login-logout
Although this property may appear to be simple, by verifying it we discovered unexpected behaviour in SoftSlate when a user logs in, performs a purchase, and logs out. In spite of the fact that the user was logged in the application, the monitor flagged a violation of property (iii). It turned out that after performing the purchase, SoftSlate replaced the object representing the logged-in user by a new one.
More concretely, the log file generated by the monitor showed that a new monitor, corresponding to a new instance of the template login-logout, was generated for the 'new' user. So, we got two different user objects, the one who originally logged in into the system (let's call it u logged ) and the new generated one (let's call it u new ). The new monitor (corresponding to the user u new ) would then be in its initial state, that is in the state logout. Thus, when the (real) user tried to log out, the monitor corresponding to user u new shifted to a bad state, while the monitor corresponding to user u logged remained in state login. As a consequence, property (iii) was violated.
In order to understand whether this is an error in the implementation we inspected the source code to better understand how the login and purchase were implemented. We found that each instance of class User was associated to a session, whose information was unique for each different execution of the application. Though the relation between (real) users and the session is bijective (for each real user there is a unique session, and vice versa), there were (at least) two instances of the class User, u logged and u new , associated with each session. Fig. 18 Extension on the ppDATE describing properties related to the log in and log out of users illustrated in Fig. 15 We were not sure what were the real reasons behind this design decision, but the implementation seemed correct, and our specification did not capture this situation. So, we decided to change our ppDATE template to capture this by including a Boolean variable reflecting whether the (real) user was connected or not, which we refer to as active. The updated ppDATE template is shown in Fig. 18. Further executions of the system (reproducing the previous executions and providing new ones) did not violate this property.

Purchases checkout
We also run the system many times in order to analyse whether the execution of SoftSlate fulfils the properties described by the provided ppDATE specification.
First, we performed several purchases to analyse if property (1) was fulfilled. We added some items to the cart, bought them, and added and removed items at any stage of the checkout of a purchase, and then completed the purchase. None of these operations violated this property. We re-run the system executing the same steps as above to check property (5), which was not violated.
Next, we continued performing purchases, but this time the administrator of the application introduced modifications in the price of some items during the purchases. By doing so we were able to analyse whether properties (4), (6) and (7) were violated. 14 In order to check whether property (4) held, we executed the system logged in as administrator and as a normal user (in parallel). The user performed a purchase (and thus the item was added to the cart), and as administrator we modified the price of the item introducing a negative value as its new price. At this moment the monitor reported that property (4) was violated. By inspecting the price of the modified item in the database, we could confirm that the negative value provided by the administrator was actually assigned to the item. This clearly was an error. We corrected this by not allowing to input negative numbers, and thus property (4) was finally satisfied. On the other hand, when the administrator modified the price of an item introducing a positive value as its new price, then property (4) was fulfilled as expected. However, we noticed that property (7) was violated: some of the prices of the items in the order did not match with the prices in the database. 15 In particular, the mismatched values were those that were modified by the administrator: the new prices were propagated to the database but they were not updated in the visualisation of the cart (to the user). This was an error, and when inspecting the code we realised that there was a method implementing the propagation of the update, but it was not called when the change (done by the administrator) was performed. We have not yet corrected this error in the original code.
Property (6) was not violated by any of the previous executions.

Runtime verification overhead analysis
In this section we analyse the overhead added to SoftSlate by the monitor generated using StaRVOOrS. To perform this analysis, we considered three scenarios: several users performed one purchase, 10 purchases in a row, and 100 purchases in a row. Table 1 shows the average execution time of: (a) an unmonitored execution of SoftSlate; (b) a monitored execution of SoftSlate using the original ppDATE specification S, and (c) a monitored execution of SoftSlate using specification S , obtained from S via static (partial) proof analysis using StaRVOOrS. In all three scenarios, the users and the server hosting SoftSlate were ran in different computers, but with identical specifications. Note that as SoftSlate is an interactive application, in order to perform these experiments we have implemented a program which uses url connections to access the application and perform a purchase. 16 Therefore, our experiments consist on executing this program repeatedly and measuring its execution time.
As expected, adding a monitor to SoftSlate introduced overhead on its execution time. However, when we compared the overhead added by the monitor which uses the original ppDATE specification (without optimisations) (b), with the one added by the monitor which was generated using StaRVOOrS (c), one could notice a reduction in overheads gained by using our tool.
Through optimisations introduced by StaRVOOrS, we obtained a version of the monitor which, in relation to the times in (a), introduced in average a 25% of overhead to the execution time of the system. On the contrary, the monitor without the optimisations of StaRVOOrS introduced a 50% of overhead to the execution time.
Even though these results are not as impressive as the one we obtained on the case study analysed in [3] (Mondex, also reported here in Sect. 10), the monitor generated by our tool for SoftSlate still has a better performance than the one which uses the original ppDATE specification. The main difference lies in the amount of Hoare triples which have to be runtime verified in each case study. Every time an experiment is performed to analyse SoftSlate, the optimise monitor generated by StaRVOOrS verifies 3 Hoare triples, whereas the monitor using the original ppDATE specification (without optimisations) verifies 5. However, each experiment performed on Mondex requires the verification of 7 Hoare triples when using the unoptimised version of the monitor, whereas the optimised one does not have to verify any Hoare triples at all (cf. Sect. 10).

Case study: Mondex
Mondex is an electronic purse application which is used by smart cards products [32], and has been considered as a verification benchmark problem since 2006, originally appearing as case study as part of the Verified Software Grand Challenge [42]. Mondex's original sanitised specification can be found in [37]. It consists of a Z specification [35], together with hand-written proofs of several properties.
Mondex essentially provides a financial transaction system supporting transferring of funds between accounts, or purses. Whenever a person has to make a transaction, electronic money is taken from their electronic purse and transferred to the target electronic purse. Such transactions are performed following a multi-step message exchange protocol: (1) the source and destination purses should (independently) register with the central fund transferring manager; (2) await a request to deduct funds from the source purse; (3) await a request to add the funds to the destination purse; and finally (4) an acknowledgement is sent to indicate that the transfer took place before the transaction ends.
In our version of this case study we consider a Java implementation running on a desktop computer instead of a Java Card implementation running on smart cards. The principal difference in the implementation is that in our version some methods return values to indicate whether their output is normal or erroneous, instead of raising Java Card exceptions. Our specification is strongly inspired by the JML formalisation presented in [40]. The full specification and source code of our case study can be found in [38]. The specification (see Fig. 19) consists of a ppDATE with 10 states, 25 transitions and a total of 26 different Hoare triples. The implementation of Mondex consists on 514 lines of code (without comments) which are distributed over 8 files.
Note that ppDATE allows us to represent the overall status of the observer using ppDATE states. In other pre/post-style specification approaches, one would instead introduce additional data, and corresponding additional constraints, as is indeed done in [40] when specifying Mondex with JML. Such additional data implies a certain complexity of the specification, which somehow lacks the structure of the problem. We believe that specifications of this kind are sometimes developed with an automaton in mind. In ppDATE, we can make that automaton explicit. This being said, we want to stress again that we took great advantage of the JML specification of Mondex in [40].   At the automaton level, the ppDATE specifies the control-oriented property which indicates how the multi-step message exchange protocol is suppose to work. For instance, after the parties are initialised (encoded in state Parties Initialised), a message requesting to transfer more money than the one available in the source purse should fail. Otherwise, such a message should take the ppDATE to a state in which the protocol now allows for the money to be transferred to the destination purse (named Money deducted). Note that the ppDATE will not take any explicit action whenever the state BAD STATE is reached. It will stay in this state until the whole monitor is restarted.
In contrast, the pre/postconditions properties placed on the states of the ppDATE ensure the well-behaviour of the methods involved in the individual steps of the protocol, behaviour which obviously changes together with the status of the protocol. For instance, once two purses agree on participating in a money transfer and the destination purse has requested for certain amount of money, (encoded in state Money Deducted), method val_operation which transfers money from the source purse to the destination one should succeed and increase the money of the destination purse by the sent amount (provided the limit of its account has not been reached), as shown in the Hoare triple below: Note that both Hoare triples above have the same precondition, but depending on the state of the ppDATE (i.e., the state of the protocol) different behaviours (i.e., postconditions) are expected for method val_operation.

Using STARVOORS
For this case study, we have used a setup identical to the one described in Sect. 9.2. Running StaRVOOrS on the source code of Mondex and the ppDATE depicted in Fig. 19 automatically produces a runtime monitored version of the application and a report summarising the results obtained from the static analysis. The static analysis and instrumentation process takes 1 minute 20 seconds, where most time is used by KeY to statically analyse the Hoare triples (approximately 1 minute 15 seconds).
The monitor generated by our tool consists one DATE to control the main property, and 24 DATEs templates to control the postconditions which were only partially verified by KeY, with 106 states and 196 transitions in total. By inspecting the report we can see that the two Hoare triples associated to the initialisation and termination of a transaction were fully proved, and that all the other 24 triples about the methods involved in the transaction protocol were the partially verified ones. For instance, let us consider the property already discussed in the previous section about method val_operation, which we will refer here to as val_operation_ok: The report shows that the postcondition will have to be checked at runtime only when the condition status != 2 holds upon entering val_operation (i.e., the destination purse This refined version of the property is the one which will be runtime verified by the generated monitor. The size of the source code of the original implementation of Mondex was 23.5kB. After running the tool, the total size of all the generated files (i.e. instrumented version of the source code and the implementation of the monitor) grows to 277.4kB.

Experimentation
We now summarise the experimental results of applying our approach to the Mondex case study.

Normal behaviour
The Table 2 shows the execution time of: (a) an unmonitored implementation of Mondex; (b) a monitored implementation using the original ppDATE specification S, and (c) a monitored implementation using specification S' , obtained from S via static (partial) proof analysis using StaRVOOrS. In all three scenarios, the system is run over a numbers of transactions which do not violate the specification. Note that in case (c), statically analysing all the Hoare triples took KeY around 1 minute, which however is done once and for all prior to deployment.
As one would expect, the addition of a monitor to the system introduces execution time overhead (b). However, if we compare this overhead to the one added by the monitor which was generated by StaRVOOrS (c), one can see a substantial overhead reduction, gained through the use of our tool. Through our optimisations we obtain a version which is at least 10 times faster for a low number of transactions, and this factor rises up to 900 when the number of transactions is increased. This significant reduction in execution time overheads is mainly due to the fact that monitoring data-centric properties may be prohibitively expensive. In fact, using S, each method invocation involved in the transfer protocol creates an additional DATE that will check the postcondition on exit. However, the postcondition checker is only created if the precondition holds on method invocation. In this case study, this causes large overheads when monitoring the unoptimised specification. Using the results from static verification, however, strengthens the preconditions by additional constraints, which in the Mondex case state were always falsified at invocation time, meaning that no postcondition checker is ever created. Apparently, in Mondex, the algorithmic complexity of the individual method implementations is limited enough such that KeY could fully prove the methods correct (automatically) if only the internal constraints corresponding to the ppDATE states were provided to KeY. But as they are not, KeY generates those constraints (closed branch conditions, see Sect. 4), and adds their negation to the preconditions. With that, the preconditions are never true at runtime. This phenomenon cannot be fully generalised to cases where KeY really lacks (automated) proving power for the code at hand, or where the code is faulty of course.

Faulty behaviour
Usually, it is hard to get full proofs when using a static verifier like KeY without considering either user interaction with the prover or the use of special annotations, e.g., loop invariants, to help the prover on its task. However, it might be the case that the static verifier does not succeed in closing a branch in the proof due to the fact that the remaining open goal was generated by an erroneous execution path. KeY cannot per se determine which one of these situations is dealing with. Fortunately, Larva can detect the occurrence of the erroneous case whenever it appears at runtime.
We have intentionally injected errors into Mondex source to verify that the optimised monitor still detects them. Consider the case of a bug in the implementation of method val_operation-the value of variable balance is incremented with a different amount from the one given in the specification of the method. When analysing property val_operation_ok, KeY obviously does not manage to prove it. Therefore, the whole property will have to be runtime verified. The monitor spots this error reaching a bad state.
In addition, we have also considered incomplete and wrong specifications. In the case where the specification is too weak, the implementation may fulfil it for wrong reasons. As in all verification approaches, we may not catch this kind of problem. When using our verification approach there lies the possibility that the problem propagates to a state in which the specification is strong enough to identify it. For example, consider if the specification does not specify how the variables of a purse should be initialised by the ConPurse class constructor, and there is an implementation error where the variable balance is initialised to −1 instead of being initialised to 0. In spite of the error in the specification, KeY would proceed normally with the proofs and the previous particular situation would not be directly controlled on runtime. However, this erroneous initialisation leads to an erroneous initial charge of money in the purses (performed using the method chargeMoney in class ConPurse). As balance is negative, the previous method fails to update it with the new amount of money. Hence, after applying chargeMoney the value of balance is still −1. Thereby, whenever a purse tries to begin a transfer, either the method initialising the sender purse during a transaction or the method initialising the receiver purse during a transaction will fail its execution (the former due to insufficient funds and the latter due to a value overflow). This failure leads to an unsuccessful termination of the transfer, which is detected by the monitor controlling the transaction protocol and takes it to a bad state. This analysis can be easily conclude by inspecting the execution trace generated by the monitor. This trace allows one to backtrack through the execution of the different methods until reaching which was the problem which was the cause the failure. In this scenario, it is important to note that in spite of the fact that we have not enforced any Hoare triple on the constructor of class ConPurse, it was specified and proved correct using KeY.
On the other hand, if a Hoare triple has an overly weak precondition or overly strong postcondition, then KeY will fail to prove the Hoare triple. StaRVOOrS thus ensures that the Hoare triple is checked at runtime, which allows us to realise when expected results arise. Finally, another scenario is when the user uses erroneous data, not detected by the application. For instance, a user might request a transfer exceeding the amount of money in a purse. In this situation, the method initialising the sender purse during a transaction will fail its execution due to insufficient funds and this will lead to an unsuccessful termination of the transfer. This unsuccessful termination is detected by the runtime monitor controlling the transaction protocol.

Related work
The combination of different verification techniques is gaining more and more popularity. One active area of research is the combination of testing and static analysis, e.g. [8,14,17,20,25,26,39]. A direct comparison of our work with those would not be fully fair as we have different objectives. We are not aiming at generating test cases, but at monitoring the actual post-deployment runs of the system. What we have in common is that static analysis/verification is used to limit the dynamic efforts, there by filtering test cases, here by filtering checks at runtime.
Another line of research is the combination of testing and runtime verification. Decker et al. in [22] introduce an extension of the testing framework JUnit, which adds runtime verification artefacts to it. In this extension, during the execution of a test, a monitor is in charge of checking whether the actual executed test conforms with the property being monitored. In [7] Artho et al. present a framework where automated test case generation benefits from the use of runtime verification in a similar way to [22]. Falzon and Pace [24] study the combination of QuickCheck and Larva by presenting a technique which extracts monitors from a QuickCheck testing specifications. Even though this line of work have a different objective compare to ours, it is worth mentioning that the QuickCheck automata used in [24] are quite similar to ppDATEs. QuickCheck automata employ pre/postconditions as part of their transitions, as opposed to ppDATEs which include them in the states of the automata. This similarity may suggest that it might be possible to extend our approach by also including the possibility of perform testing.
Another area worth mentioning is the combination of runtime assertion checks with runtime verification. In [21] de Boer et al. present SAGA, a framework which combines runtime assertion checking with monitoring. In contrast to our approach which targets general dataand control-oriented properties, SAGA focuses on the verification of both data-flow and control-flow properties of Java classes and interfaces, e.g., interaction protocol among objects.
However, we are mainly interested in the combination of static verification and runtime verification such that static verification is used to reduce the overhead introduced to the system execution by monitoring properties. Wonisch et al. in [41] make use of program transformations in order to avoid unsafe program executions. In [12] the efficiency of runtime monitoring based on tracematches is improved by using a static analysis technique which reduces the runtime instrumentation needed. The technique consists on three stages: exclusion of some tracematches, elimination of inconsistent instrumentation points, and additionally refinement of this analysis considering the order of execution.
Other works use this kind of combination but with different goals. In [13] Bodden and Lam present CLARA, a framework which uses static techniques aiming to improve the monitors themselves, instead of verifying software. The work by Zee et al. in [43] investigates the combination of static and runtime verification, but aiming at a specification language whose specifications may be both statically and runtime checked. With this goal in mind, they extend the static verifier Jahob by adding techniques to verify specifications at runtime. In this approach, most of the properties which can be verified are data-oriented, as opposed to ours where control-oriented properties are covered as well. In [34] Sözer integrates static code analysis and runtime verification. On this approach, runtime verification statements are created from static code analysis alerts, in order to generate monitors which will allow to both check for possible faults in the system and eliminate false positives obtained in the static phase.
Many specification approaches, such as SPARK [9], JML [29] and SPEC# [10] are supported by both static and runtime verification tools. Nevertheless, to the best of our knowledge, static verification is not used to optimise the runtime verification of properties.

Conclusions
In this paper we have presented StaRVOOrS, a framework for verifying integrated dataand control-oriented properties for Java programs, using a combination of static and runtime verification. The StaRVOOrS tool-chain uses KeY [2] for static verification, and Larva [19] for the verification performed at runtime.
We have presented the language ppDATE which is based on automata and pre/post conditions to describe properties of both, the control flow and the data computations. The basic structuring principle of the language is the composition of parallel automata, whose transitions fire simultaneously in reaction to events of the observed system, but also in reaction to events generated by some automata in the previous step. A distinguishing feature of the language is the inclusion of functional properties of computation units into the above, thereby capturing the dependency of functional properties on the history of previous events, by assigning Hoare triples to (automata-theoretic) states. Finally, the template concept allows to parameterise components in a great variety of ways, and create concrete instantiations dynamically.
We also presented here a semantics of ppDATEs, precisely describing the interplay of transitions, event consumption and generation, Hoare triple monitoring, creation of template instances. We then use the semantics to prove soundness of the algorithm our tool uses to translate ppDATE into DATE, allowing us to employ the DATE tool Larva as a back-end for runtime verifying ppDATE specifications.
This article also reports on the application of StaRVOOrS to SoftSlate, an open-source shopping cart web application. In this case study, we analyse ppDATEs describing properties about the proper behaviour of the system while users perform purchases. We selected this case study because verifying a real application is always quite challenging, and dealing with it would gave us a better perspective regarding the benefits which can be obatined when using our tool. We also report on the application of StaRVOOrS to the verification benchmark Mondex, an electronic purse application. We demonstrate how properties can be verified using combined static and runtime verification. This case study was selected because it is a usual benchmark in the static verification community, and we thought that it would be interesting to analyse what the use of runtime verification could bring into play.
As with all case studies, the empirical observations are difficult to generalise. However, our experimental results give an indication of what gains are possible with our technique. For SoftSlate, the overhead of pure runtime verification (without employing static verification) is roughly 50%, a penalty which we get down to roughly 25% when using StaRVOOrS, by facilitating static verification (cf. Sect. 9.3.2). These differences are much smaller compared to when we applied StaRVOOrS to the Mondex case study, where pure runtime verification created a much higher overhead. Compared to that, the monitor created by StaRVOOrS was 10 times faster for a low number of transactions, and up to 900 times faster as the number of transactions increase. ' When using the monitor generated from the original specification provided for Mondex, the execution of each method involved in a transaction (7 in total) creates an additional DATE to be traversed in parallel, which is in charge of checking the postcondition. This would lead to the large overheads obtained in that case study. However, when using the monitor generated by StaRVOOrS, thanks to the optimisations introduced in the specification by this tool, no additional DATEs are created when a transaction is performed, because the additional checks in the preconditions are false at runtime.
As a final remark, note that the efficiency gain for monitoring will benefit from any improvements in the used static and runtime verifiers. For instance, if KeY is improved in such a way that more branches are closed during the static proof, then this will have an immediate effect in StaRVOOrS thus reducing the runtime overhead. Similarly, any optimisation performed in Larva will only bring benefits to our tool.
We are currently looking at ways of pushing our techniques further. On one hand, we are looking at techniques to add control-flow static analysis to StaRVOOrS, thus benefiting from further optimisation prior to deployment. We are also looking at extending the framework to deal with distributed systems [6], which brings in new challenges, and might require assume-guarantee reasoning to enable us to perform static analysis based optimisations.
Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Appendix 1: Proofs of coupling invariant lemmas
In order to prove both Lemmas 4 and 5, we introduce the following two propositions. Proposition 1 says that the translation algorithm only modifies the actions of the transitions in the translated ppDATE network. Proposition 2 says that for every transition in the translation either there is a similar transition in the original ppDATE network, or there is not such a transition, due to the fact that the transition is a new loop transition (added by the translation to control Hoare triples).
Remember that we represent the translation of a single ppDATE to DATE with the function κ ∈ ppDATE → DATE. Proof Given a ppDATE m ∈ M and a state q ∈ Q m , whenever Π m (q) = ∅, Π m (q) = ∅ but there is no Hoare triple associated to the method related to trigger tr, or the trigger is associated to exiting a method, by Step 3b., transitions remain unchanged in the translation. Therefore, a = a in these cases. Proof Each transition t ∈ t m for any m ∈ M is obtained by applying either step 3a 1 , 3a 2 or 4b.
If t was obtained by applying step 3a 1 , then it is a new loop transition added by the translation, i.e., its origin and destination states are the same, and given a ppDATE m ∈ M such that κ(m) = m , there not exists a transition associated to t in m. Therefore, the right side of the disjunction holds.
If t was obtained by applying step 3a 2 , then, given a ppDATE m ∈ M such that κ(m) = m , either there exists one transition on m with the same trigger, same condition, and similar action (but without including the if-expression checking the precondition), or t is a new loop transition added by the translation. In the first case the left side of the disjunction holds, whereas in the the second case the right side of the disjunction holds.
Finally, if t was obtained by applying step 3b, then, given a ppDATE m ∈ M such that κ(m) = m , m has exactly the same transition. Therefore, the left-hand side of the disjunction holds in these cases. Now, we proceed to prove the lemmas.
Proof We proceed to prove this lemma by induction on the length of the trace w.
-Base case: w = ε (empty trace) By Definitions 17 and 21, we know that L 0 = L and ν 0 = ν and L 0 =L and ν 0 = ν Then, we proceed with the proof by assuming the antecedent of the implication. This assumption allows us to remove the existential quantifiers in the antecedents by introducing the fresh values L and ν in (i), and the fresh valuesL and ν in (ii). Therefore, we have Next, by IH we know (iii) ∀ m, q, ρ · (m, q, ρ) ∈ L , m ∈ M· ∃ m , q · (m , q , ∅) ∈L · κ(m) = m and q = q and (iv) ∀ m , q · (m , q , ∅) ∈L , m ∈ M · ∃ m, q, ρ · m ∈ M, κ(m) = m , (m, q, ρ) ∈ L · q = q and (v) ∀ m, q, ρ · (m, q, ρ) ∈ L , m / ∈ M· ∃ m , q · (m , q , ∅) ∈L, m / ∈ M · q = q and (vi) ∀ m , q · (m , q , ∅) ∈ L , m / ∈ M · ∃ m, q, ρ · (m, q, ρ), m / ∈ M ∈L · q = q and (vii) ν = ν In relation to L, by (i) we know it is obtained from L after performing a big step with (e, θ). Thereby, the local configurations on L are either the same as in L , a modified version of the ones in L , or new local configurations added to control a DATE which is a new instance of a template.
Let us introduce the sets L nc , L c and L new , to represent the local configurations in each one of the previous categories, respectively. Then, we know that (viii) L = L nc ∪ L c ∪ L new In addition, by using a similar approach withL and (ii), we introduce the following sets.
(i x)L =L nc ∪L c ∪L new Let us come back now to the expression we want to prove.
(x) ∀ m, q, ρ · (m, q, ρ) ∈ L , m ∈ M· ∃ m , q · (m , q , ∅) ∈L · κ(m) = m and q = q and (xi) ∀ m , q · (m , q , ∅) ∈L, m ∈ M · ∃ m, q, ρ · m ∈ M, κ(m) = m , (m, q, ρ) ∈ L · q = q and (xii) ∀ m, q, ρ · (m, q, ρ) ∈ L , m / ∈ M· ∃ m , q · (m , q , ∅) ∈L, m / ∈ M · q = q and (xiii) ∀ m , q · (m , q , ∅) ∈ L , m / ∈ M · ∃ m, q, ρ · (m, q, ρ), m / ∈ M ∈L · q = q and (xiv) ν = ν By (iii) and (iv), as the values in both L nc andL nc are the same as in L andL , respectively, we know that these values fulfil all the previous expressions. Thereby, we can reduce (viii) and (i x) to Regarding the newly created local configurations in both L new andL new , they do not fulfil the ranges of the universal quantifications in neither (x) nor (xi). In addition, by Propositions 1 and 2, we know that the only difference in the executed actions in the ppDATEs in pn and their translation is that the actions in the DATEs may include the creation of an instance of template exit_cond_checker. Besides, by step 4 in the translation algorithm, we now that both the ppDATEs templates and their translations have similar transitions and are initialised in the same state. Thus, (xii) and (xii) are fulfilled for these values, and we can reduce (viii) and (i x) to (viii ) L = L c (i x )L =L c Therefore, we have to prove, (x ) ∀ m, q, ρ · (m, q, ρ) ∈ L c , m ∈ M· ∃ m , q · (m , q , ∅) ∈L c · κ(m) = m and q = q and (xi ) ∀ m , q · (m , q , ∅) ∈L c , m ∈ M · ∃ m, q, ρ · m ∈ M, κ(m) = m , (m, q, ρ) ∈ L c · q = q and (xii ) ∀ m, q, ρ · (m, q, ρ) ∈ L , m / ∈ M· ∃ m , q · (m , q , ∅) ∈L c , m / ∈ M · q = q and (xiii ) ∀ m , q · (m , q , ∅) ∈ L c , m / ∈ M · ∃ m, q, ρ · (m, q, ρ), m / ∈ M ∈L c · q = q and (xiv) ν = ν By (iii) and Proposition 1 we know that for every enabled transition of a ppDATE m ∈ M, there is one enabled transition in κ(m) ∈ M performing the same change of state and, if any, generating the same action events. Thereby, both pn and its translation will shift the local configurations in L c andL c , respectively, in the same manner, i.e., (x ) holds.
In addition, by (iv) and Proposition 2 we know that for every enabled transition in a DATE m ∈ M , there is either an enabled transition in a ppDATE m ∈ M, where κ(m) = m , such that this transition performs the same change of state and, if any, generates the same action events, or the transition enabled in m is a loop transition.
In the first case, both pn and its translation will shift the local configurations in L c and L c , respectively, in the same manner. Thus, (xi ) holds.
In the second case, the local configuration obtained after the shift is in the same state as before the shift. Thus, by (iv), this (xi ) holds.
Moreover, by IH, Propositions 1 and 2 we know that whenever a ppDATE in pn creates an instance of a template, its translation will create an instance of the translation of such template, and vice versa. Besides, by the step 4 in the translation algorithm, as such instances have similar transitions, they will shift the local configuration associated to them in the same manner. Therefore, both (xii ) and (xiii ) are fulfilled.
Finally, in relation to (xiv), by Propositions 1 and 2 we know that only difference in the executed actions in pn and its translation is that the actions of the latter may include the creation of an instance of template exit_cond_checker (whose actions do not modify ppDATE variables valuations). In addition, by step 4 in the translation algorithm we know that both an instance of a ppDATE template and a similar instance of the translation of the template will fire similar transitions (with the same actions). Therefore, they perform the same modifications in the valuations ν and ν . Thus, by (vii), (xiv) holds. where, ψ(L ,L) = ∀ m, q, ρ · (m, q, ρ) ∈ L · ∀ σ ↑ id , π , θ · (σ ↑ id , π , θ) ∈ ρ · ∃ m , q · (m , q , ∅) ∈L · inst (exit_cond_checker, σ, π ) = m and ∀ m , q · (m , q , ∅) ∈L, m / ∈ M · ∃ σ ↑ id , π · inst (exit_cond_checker, σ, π ) = m implies ∃ m, q, ρ, θ · (m, q, ρ) ∈ L · (σ ↑ id , π , θ) ∈ ρ Proof We proceed to prove this lemma by induction on the length of the trace w.
∀ m, q, ρ · (m, q, ρ) ∈ {(m, q 0m , ∅) | m ∈ M} · true Finally, as the body of the previous universal quantification is simply the value true and its range is not empty, the whole expression is trivially evaluated to true. Now, let us analyse the expression, ∀ m , q · (m , q , ∅) ∈ {(m , q 0m , ∅) | m ∈ M }, m / ∈ M · ∃ σ ↑ id , π · inst (exit_cond_checker, σ, π ) = m implies ∃ m, q, ρ, θ · (m, q, ρ) ∈ {(m, q 0m , ∅) | m ∈ M}· (σ ↑ id , π , θ) ∈ ρ As in the initial configuration of the translation of pn there are no instances of DATE templates, the range of the universal quantification is always evaluated to false. Therefore, ∀ m , q · f alse· ∃ σ ↑ id , π · inst (exit_cond_checker, σ, π ) = m implies ∃ m, q, ρ, θ · (m, q, ρ) ∈ {(m, q 0m , ∅) | m ∈ M}· (σ ↑ id , π , θ) ∈ ρ Thus, as the range of the universal quantification is empty (i.e., false), the whole expression is trivially evaluated to true. Thereby, the base case holds. Then, we proceed with the proof by assuming the antecedent of the implication. This assumption allows us to remove the existential quantifiers in the antecedents by introducing the fresh values L and ν in (i), and the fresh valuesL and ν in (ii). Therefore, we have In relation to L, by (i ) we know it is obtained from L after performing a big step with (e, θ). Thereby, the local configurations on L are either the same as in L , a modified version of the ones in L , or new local configurations added to control a DATE which is a new instance of a template.
Let us introduce the sets L nc , L c and L new , to represent the local configurations in each one of the previous categories, respectively. Then, we know that (iv) L = L nc ∪ L c ∪ L new In addition, by using a similar approach withL and (ii ), we introduce the following sets.
(v)L =L nc ∪L c ∪L new As in the translation the setL new contains both the instances of ordinary templates and the instances of the templates about Hoare triples, we splitL new into the setsL new andL h , to represent each one of the previous categories, respectively. Thus, Now, let us come back to the expression ψ(L ,L). By (iv) and (v ), we replace it by ψ(L nc ∪ L c ∪ L new ,L nc ∪L c ∪L new ∪L h ) By (iii), as the values in both L nc andL nc are the same as in L andL , respectively, we know that the former fulfil ψ. Thereby, we can reduce the previous expression to In addition, newly created local configurations in both L new andL new do not fulfil the ranges of the quantified expressions in ψ. Then, we can discard them.
If event e is an entry event which requires the check of Hoare triples, then by Lemma 4 and Proposition 1, we know that for every enabled transition which requires the verification of a Hoare triple in pn, a similar transition will be fired in its translation whose action will create a DATE in charge of controlling such Hoare triple. Thus, for every new entry in a ρ component in L c , a new local configuration is added inL h . Thereby, (vi) holds.
Regarding (vii ), if event e is either an exit event, or an entry event which does not require to verify any Hoare triple, thenL h = ∅. Thus, as the range of universal quantification is empty, (vii ) is trivially fulfilled in both cases.
If event e is an entry event which requires the check of Hoare triples, then by the rules entr y 1 and entr y 3 in the relation small step local, we know that a new tuple is going to be added to the ρ component of the local configuration in L c which are associated to the ppDATEs whose current state possess a Hoare triple that has to be verified. In addition, a local configuration is going to be included inL h for the DATE instantiated to control the corresponding Hoare triple. Thereby, (vii ) holds.
We will assume that the ppDATE m and the valuation θ are the ones fulfilling (1). Note that the index id is introduced by Lemma 3. Next, as m is in a bad state we know that whenever σ ↑ id occurs, π is not fulfilled. Thus, let us assume that the selected prefix is of the form w = w 1 + + (σ ↑ id , θ ) . Thereby, by Definition 22, w is a counter-example of pn, i.e. w ∈ VT ( pn).
On the other hand, if the bad state inL does not belongs to a local configuration associated to a DATE m which is an instance of the template exit_cond_checker, then by Lemma 2 we know that there is a local configuration in L such that its state component is the same as the bad state inL. Therefore, w is a counter-example of pn, i.e. w ∈ VT ( pn).