Verification of class liveness properties with java modelling language

50

&

www.ietdl.org

Published in IET SoftwareReceived on 26th January 2008Revised on 2nd July 2008doi: 10.1049/iet-sen:20080008

In Special Issue on SAVCBS

ISSN 1751-8806

Verification of class liveness propertieswith Java modelling languageA. Giorgetti1,2 J. Groslambert3 J. Julliand2

O. Kouchnarenko1,2

1INRIA/CASSIS2LIFC/University of Franche-Comte, 16 route de Gray, Besancon Cedex F-25030, France3Trusted Labs, 5 rue du Bailliage, Versailles F-78000, FranceE-mail: [email protected]

Abstract: Static checking is key for the security of software components. As a component model, this paperconsiders a Java class enriched with annotations from the Java modelling language (JML). It defines a formalexecution semantics for repetitive method invocations from this annotated class, called the class in isolationsemantics. Afterwards, a pattern of liveness properties is defined, together with its formal semantics,providing a foundation for both static and runtime checking. This pattern is then inscribed in a completelanguage of temporal properties, called Java temporal pattern language, extending JML. The authorsparticularly address the verification of liveness properties by automatically translating the temporal propertiesinto JML annotations for this class. This automatic translation is implemented in a tool called JML annotationgenerator. Correctness of the generated annotations ensures that the temporal property is established for theexecutions of the class in isolation.

0T

1 IntroductionComponent-based development provides significantadvantages – portability, adaptability, re-usability and so on –when developing, for example Java Card smart cardapplications [1] or when composing Web services withinservice component architecture (SCA) – a relatively newinitiative advocated by users of Java technology. In thisframework, the use of components of distributed applicationsor component-based applications necessitates ensuring notonly invariance and safety properties but also partialcorrectness and liveness properties of components. Weconsider a component modelled by a Java class that isannotated in Java modelling language (JML).

Currently, more and more tools aiming at the verificationof Java programs are adopting JML as property specificationlanguage (see [2] for an overview). JML is a specificationlanguage syntactically and semantically close to Java, thusmaking specifications more accessible to Java programmers(see http://www.jmlspecs.org). JML allows adding basic

he Institution of Engineering and Technology 2008

formal annotations – like method pre- and post-conditionsor invariants – to the Java class, thus proposing a way tomodularly verify Java applications. However, it is difficult todirectly specify complex dynamic properties in JML, liketemporal properties [3], that are often needed to expressthe security policies that the Java implementation has toensure. Therefore Huisman and Trentelman [4] proposed alanguage of temporal properties – later called JTPL, forJava temporal pattern language [5].

Our main purpose is to verify liveness properties of Java/JML components using a JML extension. The firstcontribution is a formal execution semantics for repetitivemethod invocations from this component, called the classin isolation semantics. To infer class invariants by abstractinterpretation, Logozzo [6] proposed a semantics of partialexecution paths of an object-oriented program and of theso-called class in isolation. Our work follows this approachbut, for verifying liveness properties, we define a completeexecution path semantics of a class in isolation. Moreover,since we consider Java/JML components, we take into

IET Softw., 2008, Vol. 2, No. 6, pp. 500–514doi: 10.1049/iet-sen:20080008

IETdoi

www.ietdl.org

account the JML semantics to define the class in isolationsemantics. The second contribution is an extension of theJML type specifications with a temporal specification ofliveness by introducing a new specification clause in Javaclasses – called the liveness clause. A deep integration ofthis liveness clause in JML is achieved by using the samesemantics of visible states as for JML invariant andconstraint clauses. The third contribution is a verificationmethod for liveness properties by generating JMLinvariants and history constraints. The fourth contributionis a systematic translation of temporal properties into JMLannotations. Thanks to the semantics, we establish thecorrectness of the translation. Notice that the second andthird contributions were presented in [7] without proofsnor explicit examples. To make it short, the mainextensions to [7] are (1) a complete formal semantics forthe executions of a Java/JML component, and (2) thetranslation of all the liveness formulae of the JTPLtemporal logic into standard JML annotations.

This paper is organised as follows: Section 2 quicklypresents JML on an example. Section 3 introduces themathematical background used in the next sections. Section4 presents the semantic framework of the paper. Inparticular, it defines a semantics for a class in isolation andgives the semantics of JML main annotations. Moreover,the semantics of visible states is recalled and formalised(upon an ad hoc semantics of a Java class). Next, Section 5defines the liveness clause and its formal semantics. Section5 also presents the verification of liveness properties on aclass in isolation through appropriate annotation generation.Section 6 presents the application of the annotationgeneration method to the JTPL temporal liveness propertiesbased on their translation into the liveness clause that wepropose to extend JML. Section 7 presents the JAG (JMLannotation generator) tool implementing this automaticgeneration of annotations. Section 8 concludes by givingsome perspectives and future work.

2 Overview of JML and exampleJML [8] is a specification language especially tailored for Javaapplications. Originally, JML was proposed by Leavens andhis team; the development of JML is now a communityeffort. JML has been successfully used in several case studiesto specify Java applications, and more especially to specifysmart card applications [1, 9]. JML is developed followingthe design by contract approach [10], where classes areannotated with class invariants and method pre- and post-conditions. The predicates are side-effect free Boolean Javaexpressions, extended with specific constructs. Specificationsare written as Java comments marked with an @, that is,annotations follow //@ or are enclosed between /�@ and@�/. Fig. 1 presents some JML annotations on the simpleexample of a buffer.

The class Buffer works as follows: a methodstoreData() customises the application by setting the

Softw., 2008, Vol. 2, No. 6, pp. 500–514: 10.1049/iet-sen:20080008

transaction length. Then, one can initialise a new transactionwith the method begin(), creating a new temporarybuffer. Afterwards, a write() method fills themodifications in the temporary buffer that is validated,that is, assigned to the attribute status, by an invocation ofcommit(). It is also possible to abort the transaction by aninvocation of the method abort().

Fig. 1 displays a class invariant, that is, a predicatethat has to hold on every so-called JML visible state.History constraints allow expressing a relation betweenthe pre- and post-state of all methods. Pre-state values ofexpressions are denoted by the JML keyword \old. Usingthe clause for, one may specify the methods list for whichthe history constraint must be satisfied. When this clause isomitted, the constraint must hold for all the class methods.The clause requires denotes the pre-condition of themethod, that is, a predicate that must be true when themethod is called. A post-condition is expressed with anensures clause. A method may exceptionally terminateby throwing an exception and satisfying the exceptionalpost-condition (signals clause). The methodspecification can also contain a diverges clause (notdisplayed in this example). If the predicate of a divergesclause of a method m is satisfied by the pre-state of m, thenthe execution of m may not terminate. Otherwise themethod must terminate. By default, the JML divergesclause is set to false. JML also introduces its ownvariables - declared with the keyword ghost. A specialset annotation exists to assign their value. For instance,trDepth = true means that a transaction is inprogress. This variable allows expressing that every openedtransaction must eventually be closed. This is an example ofliveness property that will be translated into a set of JMLannotations. The correctness of a Java class w.r.t. JMLannotations can be established by model-checking [11] orby a prover (B or Coq) via a proof obligation generator(Jack [12] or Krakatoa [13]).

3 PreliminariesThis section introduces some definitions and notations usedin the other sections. It recalls the notion of sequence andsome useful results for the existence of fixpoints in lattices.

3.1 Notations

Familiarity with basic set theory is assumed. Given a binaryrelation R # S1 � S2, dom(R) is its domain, ran(R) is itsrange and R21 is the inverse relation. If dom(R) ¼ S1, thenthe relation is total. A relation f # S1 � S2 is a partialfunction from S1 to S2, if each element of its domain has asingle image. It is a (total) function, denoted S1! S2, if it istotal and a partial function. An endofunction of S is afunction from S to itself. For any function f : S1! S2, x [ S1

and y [ S2, the update of f with y at x, denoted

501

& The Institution of Engineering and Technology 2008

50

&

www.ietdl.org

Figure 1 JML annotated transaction system

Every opened transaction must eventually be closed

f [x 7! y], is the unique function such that

f [x 7! y](u) ¼f (u) if u = x

y if u ¼ x

�

More generally, we write f [x1 7! y1, . . ., xn 7! yn], instead off [x1 7! y1] . . . [xn 7! yn], when x1 . . . xn are all different.

3.2 Sequences

Let S be a (non-empty) set. A sequence is a partial function s

from N to S such that the set dom(s) is either N or a finitesubset [0, . . ., k] for some k in N. The empty sequence,whose domain is the empty set, is denoted e. A sequence s

is infinite if dom(s) ¼ N, finite otherwise. The lengthlen(s) of a sequence s is n if it is finite and ifdom(s) ¼ [0, . . ., n 2 1], v otherwise. The last elementlast(s) of a sequence s is s(len(s) 2 1) if this sequence isfinite and non-empty, v otherwise. We use S�, Sþ, Sv, S�v

and Sþv to, respectively, denote the sets of finite, non-empty finite, infinite, finite or infinite, and non-emptyfinite or infinite sequences.

The concatenation a . b of two sequences a, b [ S�v oflength l ¼ len(a) and m ¼ len(b) is a sequence of lengthlen(a . b) ¼ l � m, where � extends the addition of N

to N < fvg, with v� n ¼ n� v ¼ v for anyn [ N < {v}. s ¼ a . b is defined by s(i) ¼ a(i) for0 � i , l and s(i) ¼ b(i � l ) for l � i , len(s).Concatenation of sequences extends to sets of sequences ina standard way, with the same notation.

2The Institution of Engineering and Technology 2008

Two non-empty sequences a, b [ Sþv of lengthl ¼ len(a) and m ¼ len(b) are joinable iff last(a) is b(0) orv. When they are joinable, their join (or junction) a_b isa sequence s of length len(s) ¼ (l � m) � 1, where �extends the subtraction of N to N < fvg, with v �

n ¼ v for any n [ N < fvg. s ¼ a _ b is such thats(i) ¼ a(i) for all 0 � i , l and s(i) ¼ b(i 2 lþ 1) for alll � i , len(s) when l , v. The junction S _ T of the setsof non-empty sequences S and T is the set of junctions a _

b of joinable sequences a [ S and b [ T .

3.3 Complete lattices

A partial orderv on a set S is a relation on S which is reflexive(8x [ S � x v x), transitive (8x, y, z [ S � (x v y ^ y v z)) x v z) and antisymmetric (8x, y [ S � (x v y ^ y v x)) x ¼ y). A partially ordered set kS, v l, or poset, is a setequipped with a partial order v. A lower bound l ofU # S is an element l of S such that 8x [ U � l v x. Agreatest lower bound of U is a lower bound g of U suchthat l v g holds for all lower bound l of U. A (least) upperbound of U for v is a (greatest) lower bound of U for theinverse partial order v�1. By antisymmetry of v, greatestlower and least upper bounds, when they exist, are unique.

A complete lattice kS, v , t , u l is a poset kS, v lwhere every subset U # S has a least upper bound,denoted uU , and a greatest lower bound, denoted tU. Anendofunction f of S is monotone if 8x, y [ S � x v y)f (x) v f (y). A consequence of Tarski’s fixpoint theorem[14] is the existence of least and greatest fixpoints for anymonotone function in a complete lattice.


IETdo

www.ietdl.org

Proposition 1: Every monotone endofunction f on acomplete lattice kL, v , t , u l admits a least fixpointlfp(f ) ¼ def u {xjx [ L ^ f (x) v x} and a greatest fixpointgfp(f ) ¼ def t {xjx [ L ^ x v f (x)}.

3.4 Sequence set lattice

When a program can either run forever or end, its execution(or trace) semantics is a set of finite or infinite sequences(of states). Following [15], these sets can be specified asfixpoints in the set 2Sþv of sets of non-empty finite orinfinite sequences. The following proposition defines alattice over this set by fusion of the complete latticesk2Sþ , # , < , > l and k2Sv , $ , > , < l of sets of,respectively, non-empty finite and infinite sequences. Aproof that they are complete lattices can be found in [10],Th. 11 and 12. In all that follows, Xþ (resp. X v) shortensX > Sþ (resp. X > Sv) for any X in 2Sþv.

Proposition 2: (Corollary of [15], Theorem 9):Let 2Sþv be the (disjoint) union of 2Sþ and 2Sv . For any Xin 2Sþv , let v be defined by X v Y ¼ Xþ # Y þ^

Xv $ Y v. For any subset Z of 2Sþv , let t and u be,respectively, defined by tZ ¼

SX [Z Xþ <

TX [Z Xv and

uZ ¼T

X [Z Xþ<S

X [Z Xv.

Then k2Sþv , v , t , u l is a complete lattice.

4 Execution semanticsOur aim is to verify liveness properties of Java/JMLcomponents. A suitable semantics for this is a set ofmaximal execution paths. Intuitively, an execution path (orsimply an execution) is a sequence of states reached duringan execution of the class. An execution path is maximal ifit cannot be extended to form a longer execution path. Amaximal execution path is either infinite or is terminatingwith a blocking state.

4.1 Context restrictions

We study a component that is a Java class enriched with someJML annotations: invariant, constraint andghost variables for the class, behavior for methodsand set in their bodies. The annotation pure means thata method is side-effect free. The annotations helper andassignable are useless in defining the livenessproperties that we address. Consequently, we do not takethese annotations into account. We do not address theproblems of inheritance, multithreading and exceptionhierarchy. To simplify the presentation, we do not take intoaccount the finalisers and the static methods. Theexecution of the component environment is restricted tocreating only one instance of the class. The executioninvokes only the non-static methods.

We assume that the environment and the class respect thecontract defined by the JML specifications. That means that

Softw., 2008, Vol. 2, No. 6, pp. 500–514i: 10.1049/iet-sen:20080008

the environment calls method m from a memory state thatsatisfies its requires condition. It is assumed that theannotated class is consistent, that is, each method m leadsto a state that satisfies either its ensures condition if mdoes not diverge and does not raise an exception or thesignals predicate if it raises an exception.

4.2 Java subset semantics

In this section, Definitions 1 and 2 describe the Java/JMLcomponents that we consider. Then an execution semanticsof a Java subset is given in Definition 4 as a sequence ofmemory states, defined in Definition 3.

A component is a Java class defining a set of methods and aset of attributes and ghost variables. The class can beannotated with JML annotations as invariant,constraint and behavior. A behaviour is a methodannotation. A class can also contain ghost variables andset annotations. A component is, therefore, an annotatedclass in Java/JML defined as follows:

Definition 1 (annotated class): An annotated class C is atuple (VC, IC, CC, MC) where VC is the set of attributes andghost variables of the class, IC is a set of JML invariants, CC

is a set of JML constraints and MC is the set of all methodnames of the class except the constructor iC. A methodnamed m in MC is defined by a tuple (behaviourm,paramListm, bodym) where behaviourm is the JMLspecification of a canonical behaviour, paramListm is its set ofparameters and bodym is the Java program that implements m.

By a desugaring operation [16], the method m behaviours canbe reduced to a single canonical behaviour annotation:behavior; requires Pm; diverges Dm;ensures Qm; signals (Exception e) Rm;. Inthe rest of the paper, Pm, Dm, Qm and Rm, respectively,denote the requires, diverges, ensures and signals predicatesof the behaviour of method m.

The addressed Java subset to define method bodies bodym

is composed of atomic and method call statements,respectively, denoted by as and m(E, . . ., E), sequential,conditional and iterative statement compositions, andexception handling. An atomic statement is any statementthat does not define other memory states than the statesbefore and after its execution. A typical example is anassignment of a variable in VC.

Definition 2 (Java subset): Let E be a Java expression, ma Java identifier and P a Java predicate (a Boolean Javaexpression). We consider the Java statement subset Tdefined by the following abstract syntax:

T ::¼ as j m(E, . . . , E) j T ; T j if (P) {T } else {T }

j while (P) {T } j throw j try {T } catch {T }

j try {T } finally {T }:

503


50

&

www.ietdl.org

A memory state assigns values to variables. For a component inisolation, we consider three sets of variables, namely: the set VC

of attributes and ghost variables, the set PC ¼ <m[MC

paramListm of parameters of all the methods (to simplify, weassume that distinct methods have disjoint parameter sets),and a set of three special variables to control the execution.

Definition 3 (memory state): A memory state s iscomposed of:

† two total functions VC! VAL and PC! VAL < f ? g,where VAL is the set of all values of the different Java typesand ? � VAL; the former function assigns a value to anyattribute and ghost variable of C; the latter assigns a valueto any parameter of any method of C; when the parameteris not used, its value is undefined – denoted ? .

† a boolean variable excp; the predicate s(excp) indicates thatan exception has been thrown,

† a variable cM [ MC, indicating the name of the methodcurrently performed,

† a variable sH, that is a natural number that represents theheight of the execution stack.

This definition simplifies memory models for object-orientedlanguages [13, 17]. The Java memory also contains anexecution stack [18]. As in[6], we do not explicitly use theexecution stack, but we observe it with the threespecialvariables excp, cM and sH. Given a state s and a variable xin VC < PC < {excp, cM , sH }, s(x) denotes the value of xin the state s, when it is defined. We denote by STATEthe set of memory states of a class C.

Let E be a Java/JML expression. We consider an evaluationfunction, written eval(E, s), that returns the value of E in the


state s. We suppose that expressions are side-effect free anddo not contain method calls. They are denoted by E, Ei.JML predicates are boolean expressions defined overattributes, ghost variables and values of their types. Somepredicates, for example in the constraint or ensuresclauses, are pre-/post-predicates using the values of variablesin the previous state by the \old notation. Let P be a JMLpredicate and s, s0 be two memory states. If P does notcontain the keyword \old, s o P denotes that eval(E,s) ¼ true. Otherwise, (s, s0) o P denotes that theevaluation of P w.r.t. the states s and s0 is true. The subterms tof P appearing as \old(t) in P are evaluated in the state s,and the subterms t0 that are not included in the keyword\old are evaluated in the state s0.

Intuitively, we define the semantics of a Java statement Tas the execution s[[T ]] that is generated by the execution of Tfrom the memory state s of STATE. An execution is asequence of memory states, that is, an element ofSTATEþv.

Definition 4 (Java subset semantics): Let T be a Javastatement and s [ STATE a memory state withoutexception (:s(excp)). The execution s[[T ]] is defined inFig. 2, where fas : STATE ! STATE is the statetransformer of the atomic statement as.

Each equality in this definition must be understood asfollows:

1. The execution for an atomic statement as is the outputstate resulting from as.

2. When a method m is called, the first state sin is a pre-statethat contains the value of every parameter of m. In this state,the current method is m and the stack height is incremented.If sin does not satisfy the pre-condition Pm of method m, the

Figure 2 Java subset semantics


IETdo

www.ietdl.org

execution raises an exception. Otherwise, the state sin isfollowed by the sequence of states resulting from theexecution of the body of m. When this execution is finite,it ends with a last state sexit whose parameters, cM and sH,are equal to their values in the first state s and whose othervalues are those of the last state of the body execution.

3. The execution for a sequence of T1 and T2 is theconcatenation of the executions of T1 and T2 if T1

terminates without raising an exception. Otherwise, it isthe execution of T1.

4. The execution for the conditional statement is the executionof T1 if s satisfies P and the execution of T2 otherwise.

5. Defining the execution semantics of the iterative whilestatement is a difficult point. For any predicate P andstatement T, this execution is either reduced to thesequence s if the state s does not satisfy P, or the executionof T if T does not terminate or raises an exception, or theconcatenation of a first execution of T and the execution ofthe same iterative statement from the last state of this firstexecution of T. This is the intended meaning of the fifthequality in Fig. 2. The trouble is that this ‘definition’ of(ls:s[[while (P){T }]]) is circular. The question remainswhether this equation admits a solution and, if it admitsmore than one, which one should be retained as theright definition. A basic answer is to define this solutionas a fixpoint over an adequate lattice. Consider the set [[T ]]of executions starting from any memory state in STATE.This set is related to the unique execution s[[T ]] aftera given state s by [[T ]] ¼ {s:sjs [ STATE ^ s [ s[[T ]]}.[[while (P){T }]] could be defined in the sequence setlattice from Proposition 2 as the least fixpoint ofthe endofunction W defined by W ¼ (lX � {s [STATEþv j len(s) ¼ 1 ^ s(0)j=P} < {s [ STATEþvjs[ [[T ]] ^ s(0) o P ^ last(s)(excp)} < {s [ STATEþvjs[ [[T ]] ^ s(0) o P ^ :last(s)(excp)}_X ) with theconvention that v(excp) ¼ false. On the one hand, thisfunction is monotone. On the other hand, a proof byinduction on the statement language shows that theexecution set W (X ) contains exactly one execution startingfrom any given state, for any execution set X. Thens[[while (P) {T }]] is defined as the execution starting withs in the least fixpoint of W.

6. The execution for the try fT1g catch fT2g statement isthe execution of T1 if T1 either does not terminate orterminates without raising an exception. Otherwise, whenT1 terminates, the raised exception is removed and theexecution continues with the execution of T2.

7. The execution for the try fT1g finally fT2g

statement is the execution of T1 if T1 does not terminate.Otherwise, when T1 terminates either normally or bythrowing an exception, the raised exception is caughtif necessary and the execution continues with the executionof T2.


8. The throw statement assigns the special variable excp totrue. If the throw statement is in the T1 part of atryfT1gcatchfT2g statement, the execution continueswith the execution of T2 as it is specified by its semantics.Otherwise, the execution stops.

One might expect the same semantics for s[[while (P) {T }]]and s[[m()]] when m() is for instance defined by void m()fif (P) fT; m()g else f. . .gg where the dots are replacedwith some statement producing an empty execution. Infact, these two semantics differ for the following reasons.The main reason is that the semantics of every method callhas to begin with an entry state sin and, if finite, to endwith an exit state sexit, whereas these two states should notappear in the semantics of the while statement. Thesetwo states for method calls are compulsory because theexecution semantics is designed for defining the ensuresJML clause in Section 4.6, that must hold between thisentry state and the corresponding exit state. Another reasonis that a method call assigns the special variables cM andsH, whereas a while statement does not modify them.Modulo these differences, s[[while(P) {T }]] is solution ofan equation obtainable from the equation satisfied bys[[m()]] by removing the first state of each computedsequence and also the last state of each finite one.

4.3 Class semantics

As explained in Section 1, we aim to verify that a class Csatisfies a liveness property. This satisfaction obviouslydepends on the context of use of that class. Here, we focuson the life cycle of a single object of type C, after itsconstruction. We assume the encapsulation hypothesis, thatis, that the class attributes can be modified only by theinvocation of class methods. Consequently, the class useonly depends upon the manner invoking the class methods.The class executions result from the activation of theconstructor followed by a finite or infinite sequence ofmethod calls that respect the contract – each of themprotected by an exception recuperation statement. Thisclass semantics SC

þv is defined in this section.

A method execution at toplevel is a (maximal) execution ofa method m that starts from any state where the executionstack is empty and the exception flag is down. The set ofexecutions of a class C at toplevel is denoted by [[C]] anddefined by

[[C]]¼ def {s:s[[try{m(v(p1), . . . , v(pn))}catch{}]] jm [ MC ^

v [ paramListm!VAL ^ s [ STATE ^ :s (excp)

^ s(sH )¼ 0 ^ soPm}

where paramListm ¼ fp1, . . ., png.

Let C be an annotated class, STATE its set of states, [[C]] [STATEþv its execution semantics and S0 # STATE the setof initial states resulting from the constructor iC of C. The set

505


50

&

www.ietdl.org

f (C) of blocking (or final) states for the class C is defined byf (C) ¼ STATEn{s(0) js [ [[C]]}. With these notations,the maximal execution semantics of an annotated class can bedefined thanks to the following endofunction.

Proposition 3: In the complete lattice k2STATEþv , v ,t, u l, the endofunction F defined by F (X ) ¼ f (C) <([[C]]_X ) is monotone.

Proof: Notations are the same as in Proposition 2, except for Sreplaced here with the set STATE of memory states.By separating finite and infinite sequences, one hasF (X )þ ¼ f (C) < ([[C]]þ_Xþ) and F (X )v ¼ ([[C]]þ_Xv)<[[C]]v. X v Y implies that F(X )þ # F(Y )þ andF(X )v $ F(Y )v, that is, F(X )vF(Y ). A

When [[C]] is a transition relation, that is, when it is a set ofexecutions of length 2, this proposition is a corollary ofTheorem 13 from [15], proved by fusion of fixpoints onthe two lattices of non-empty finite and infinite executions.The present result is more general, since [[C]] may containfinite executions of any length, and even infinite executions.A consequence is that a proof by fusion is no more possible.

By Propositions 1 and 3, F admits a leastfixpoint, denotedby lfp(F ).

Definition 5 (class semantics): The restriction of lfp(F )to executions starting from the states resulting from theconstructor is called the class semantics and is denoted bySþvC ¼ def lfp(F ) > (S0

_STATEþv).

4.4 Visible states

The semantics of the JML invariant and constraintclauses is based on the notion of ‘visible’ states. This sectionformalises this notion and its semantics. Under thehypotheses of Section 4.1, the original definition of visiblestates, given in the JML reference manual [8], is restrictedto three cases, as follows. A visible state is a state that occursat one of these moments in a program’s execution: at thefirst state of the execution, just after the end of a constructorinvocation that has created the executed object; at thebeginning or end of a (non-static non-finaliser) methodinvocation; outside of the execution of any constructor,finaliser or method when the execution stack is empty.

Let us first formalise the notions of pre- and post-states fora method m as follows.

Definition 6 (pre- and post-states): Let C be a class,s [ S

þvC an execution, m a method of class C and

0 � i , len(s). For i . 0, the ith state s(i) of s is a pre-state of m, denoted prestate(s, i, m), if s(i)(cM) ¼ m ands(i)(sH ) ¼ s(i � 1)(sH )þ 1. The ith state of s is a post-state of m, denoted poststate(s, i, m), if s(i)(cM) ¼ m ands(i)(sH ) ¼ s(i þ 1)(sH )þ 1.


With this definition, for any execution of class C, weformalise – in conformity with [8] – what a visible state is.

Definition 7 (visible states): Given an executions [ S

þvC , the ith state s(i) of s is a visible state, denoted

visible(s, i), iff i ¼ 0, s(i)(sH ) ¼ 0 or there is a methodm [ MC in C s.t. pre-state(s, i, m) or post-state(s, i, m).

It is now possible to abstract any execution by keeping only itsvisible states. The following definition of this abstraction isbased on an auxiliary partial function nv : N� S

þvC ! N,

such that nv(i, s) is the position of the iþ 1th visible statein s, when it exists. Let min(S) denote the minimum ofany subset S of N. nv is inductively defined bynv(0, s) ¼ min({j j 0 � j , len(s) ^ visible(s, j)}) and nv(i, s) ¼ min({j j nv(i � 1, s) , j , len(s) ^ visible(s, j)})for i . 0.

Definition 8 (visible state abstraction): The visible stateabstraction of a class C, denoted vsaC, is the endofunction ofSþvC defined by vsaC (s)(i) ¼ s(nv(i, s)) for any s in S

þvC

and any 0 � i , len(s).

4.5 Class in isolation semantics

The semantics of a class in isolation is defined as the set ofabstractions to visible states of complete (maximal) classexecutions. Following [6], this execution semantics is calledthe class in isolation semantics. It is defined as follows:

Definition 9 (class in isolation semantics): The class inisolation semantics of a class C is defined by SC ¼ def

{vsaC (s) js [ SþvC }.

4.6 Annotated class consistency

To express temporal properties by JML annotations, we needan execution semantics of JML annotations. To ourknowledge, JML semantics has been given in terms of wp-calculus (see e.g. [13]), but never in terms of properties ofthe executions. In this section, we give an executionsemantics of JML annotations defining their consistencywith the set of executions SC of the class in isolation.

In an annotated class, there are three canonical kinds ofannotations: invariant, constraint and behavior.Their semantics are given by Definition 11 w.r.t. thedefinition in [8]. In Definition 11, we use the predicatemp(s, j, m, i) that is true if s( j) is the matching post-stateof the pre-state s(i) (Definition 10).

Definition 10 (matching post-state of a state for amethod in an execution): The jth state of s [ S

þvC is

the matching post-state of the ith state of s for method m,denoted mp(s, j, m, i), if

poststate(s, j, m) ^ s(j)(sH ) ¼ s(i)(sH ) ^ 8k:

(i , k , j ) s(k)(sH ) s(i)(sH )):


IETdo

www.ietdl.org

Definition 11 (consistency): Let C be an annotated class.We define that an execution s of SC satisfies a JMLannotation A of the class C, denoted s :A, according to theformulae in Fig. 3.

This definition must be understood as follows:

† Invariant: The invariant must be satisfied by eachvisible state [see (1) in Fig. 3].

† Constraint: For the body of each method includedin the for clause, the constraint must hold between twoconsecutive visible states that arise during the execution ofthe method, that is, all visible states between the pre-stateand the matching post-state of the method [see (2) in Fig. 3].

† Behavior method specification: This JML specificationis interpreted over an execution as follows. If the predicate Pm

of the requires clause is satisfied by the pre-state of themethod m, that implies:

– If Dm does not hold (:Dm), then the method mustterminate, that is, it must have a post-state. Moreover, if itis a normal termination (s( j)(excp)), the predicate Qm ofthe ensures clause must be satisfied between the pre-state and the post-state, and the predicate Rm of thesignals clause must be satisfied otherwise (see the case:Dm in (3)).

– If Dm holds and the method terminates, then the pre-stateand its matching post-state satisfy the same conditionpostcontract(s, j, m, i) as in the previous case (see the caseDm in (3)).

5 Liveness propertiesLiveness properties extend the notion of program terminationby stipulating that a program must eventually reach some givenstates. This section deals with the expression and verificationof liveness properties on a class C.

5.1 Liveness operator

The liveness properties under consideration are thoseexpressible by the Loop operator defined in this section.For any state predicate Q, the temporal formula Loop(Q)


corresponds to the linear-time temporal logic (LTL)property GF:Q for infinite sequences of states. It is alsosatisfied by finite sequences of states ending in a statewhere Q does not hold. Its semantics is based on thenotion of visible states in JML. It is defined on finite andinfinite executions as follows:

Definition 12 (loop operator): Let Q be a predicate. Theexecution s [ SC satisfies the liveness operator Loop(Q),written s o Loop(Q), if

8i:(0 � i , len(s)) 9j:(i � j , len(s) ^ s(j) o :Q)):

This satisfaction relation is lifted up to sets of executions withthe semantics that every execution in the set satisfies theformula.

5.2 Class liveness

In object-oriented programming, defining and checking thesatisfaction of a liveness property on a whole program –composed of many classes – may be an heavy task. As afirst step, this section presents the semantics of a livenessproperty attached to a single Java class.

A liveness property Loop(Q) declared in a class C musthold for every object o of type C. For the sake of simplicity,C is assumed to have no static attribute. Thus, Q is a JMLpredicate with variables among the (non-static) attributes ofC. The satisfaction of Loop(Q) on an execution of SC

intuitively means that if, during the execution, any instanceof the class C is in a state satisfying Q, then it is alwayspossible to reach a state satisfying :Q by invoking methodsof C on this instance. In other words, C satisfies theliveness property Loop(Q) if SC o Loop(Q).

5.3 Proving liveness

Along the line of Floyd’s total correctness proof method, weplan to prove liveness with the help of a variant function thatassigns a value to each program state. That value shoulddecrease at each program step, according to a well-foundedordering. In the deterministic case, it is sufficient [19] toconsider variants taking their values in N, totally orderedwith ,.

Figure 3 Consistency between JML annotations and executions

507


50

&

www.ietdl.org

In the present case, some program steps are calls tomethods of a class C. It is obvious that a call to a side-effect free method of C cannot change the value of anyvariant. Thus, the variant of a liveness property will berequired to decrease strictly for a subset of methods withside effects. Consequently, when assigning a livenessproperty to a Java class, the user is asked to specify avariant V and a set M of progress methods. This extensionof the Loop operator with V and M, attached to a class C,is denoted LoopC (Q, V, M ).

In order to verify SC o LoopC(Q, V , M), we need toassume progress of the environment, that is, that theenvironment invokes the methods of the subset M.

Definition 13 (progress hypothesis): For any set ofmethods M, an execution s [ SC satisfies the progresshypothesis, written s o PH (M), if

8i:(0 � i , len(s)) 9j:(i � j

, len(s) ^_

m[M

prestate(s, j, m))):

This satisfaction relation extends to sets of executions in astandard way. The semantics of LoopC(Q, V, M ) is givenby the following definition, where 1M is the characteristicfunction of set M, whose value 1M(m) at m is 1 if m [ M,0 otherwise.

Definition 14 (liveness clause): Let C ¼ (VC , IC ,CC , MC ) be an annotated class, Q a predicate on theattributes of C, V :VC ! N a variant function andM # MC a set of methods of C. An execution s [ SC

satisfies the liveness clause LoopC (Q, V , M), writtens o LoopC(Q, V , M), if

s o PH (M)) 8i:((0 � i , len(s)� 1)) (s(i) o

Q)^

m[MC

V (s(i))� V (s(i þ 1)) 1M (m))):

The variant-based liveness proof method is summarised inthe following proposition.

Proposition 4: For any execution s [ SC satisfying theprogress hypothesis PH(M ), if s o LoopC (Q, V , M) thens o Loop(Q).

5.4 Approximation with JML annotations

This section shows how to use existing JML tools forverifying liveness properties on a class in isolation. The ideais to replace the liveness clause with standard JMLannotations, whose satisfaction is sufficient to establishSC o LoopC (Q, V , M).

Verification of the LoopC (Q, V , M) property is quitesimilar to a termination proof. As long as Q holds, it must


be possible to invoke a method of M, and methods in Mmust decrease the variant V. Here we propose proofobligations – inspired from [20] – expressed as JMLannotations. These proof obligations guarantee thesatisfaction of the LoopC(Q, V , M) property by theexecutions of the class C in isolation.

Let A1–5 be the following set of JML annotations

invariantV .¼ 0; (A1)

constraintQ¼¼. V , nold( V ) for M ; (A2)

constraintQ¼¼. V ,¼ nold( V ); (A3)

invariantQ¼¼._

m[M

Pm; (A4)

invariantQ¼¼.^

m[MC

(Pm¼¼. !Dm); (A5)

Remember that JML invariants have to hold on all visiblestates, and JML constraints have to hold between any twosuccessive visible states [8]. These annotations A1–5 relateto Q, V, M, and a class C and its methods as follows:

A1 The variant V is actually greater than zero, it is a functionreturning a natural number.

A2 As long as Q holds, the variant V must decrease when amethod in M is executed.

A3 As long as Q holds, the variant V must not increase whena method of C is executed.

A4 As long as Q holds, there should always be a method in Mthat may be called, that is, whose pre-condition Pm (in theclause requires Pm) holds. This ensures the deadlock-freeness of the system.

A5 As long as Q holds, all callable methods must not diverge,according to the clause diverges Dm. This ensures thenon-divergence of the system.

In the rest of the paper, s :A1–5 denotess :A1 ^ � � � ^ s :A5.

Theorem 1: Let s [ SC be an execution. If s :A1–5 thens o LoopC(Q, V , M).

Proof 1: There are two cases:

1. If s [ SC is a finite execution, the definitions in Section 4imply that last(s) p Pm for any method m in MC, andthat last(s) is the prestate of no method. That falsifiesPH(M ) for any M # MC when i ¼ len(s)� 1. Thus s oLoopC (Q, V , M).

2. If s is an infinite execution, the proof is by contradiction.Suppose there exists s [ SC such that s o LoopC


IEd

www.ietdl.org

(Q, V , M). By Definitions 13 and 14,

s o PH (M) (1)

and there are some i, 0 � i , len(s)� 1 and some methodm [ M , s.t. s(i) o Q and

V (s(i))� V (s(i þ 1)) , 1M (m) (2)

Since s [ SC , by the progress hypothesis (Definition 13),we have

8k 0: 9k2 k: 9m [ M : prestate(s, k2, m)

The above property being true for each index k 0, it is alsothe case for each index k i

8k i: 9k2 k: 9m [ M : prestate(s, k2, m) (3)

Independently, from the semantics of Java statements(Definition 4) and the definition of pre-states (Definition6), we derive

8k 0: 8m [ MC : prestate(s, k, m)) s(k) o Pm (4)

On the one hand, from (3) and (4), we obtain

8k i: 9k2 k: 9m [ M : prestate(s, k2, m) ^ s(k2)

o Pm (5)

On the other hand, from (2) and (A5), we have

8m [ M :s(k2) o Pm ) s(k2) p Dm (6)

Then, from (5) and (6), we obtain

8k i: 9k2 k: 9m [ M : prestate(s, k2, m) ^ s(k2)

o Pm ^ s(k2) p Dm (7)

By Definition 11 (Fig. 3), when using default values [8] of allbut Dm of thebehavior clause ons above, item (3) results in

8k i: 9k2 k: 9m [ M : prestate(s, k2, m) ^ 9k3

k2:mp(s, k3, m, k2) (8)

By (A2), (8) and transitivity of history constraints (Definition11, item (2) in Fig. 3), we obtain

8k i: 9k2 k: 9m [ M

prestate(s, k2, m) ^ 9k3 k2: mp(s, k3, m, k2) ^

ks(k2), s(k3)l o V , nold(V )

(9)

T Softw., 2008, Vol. 2, No. 6, pp. 500–514oi: 10.1049/iet-sen:20080008

By a similar reasoning, we also obtain, from (A3)

8k i: 9m [ MC

prestate(s, k, m)) 9j k: mp(s, j, m, k) ^

ks(k), s( j)l o V � nold(V )

(10)

Consequently, from (9) and (10) one deduces that the variantV decreases infinitely during the execution. And so, A1

cannot be established. A contradiction. A

In JML side-effect free methods can be identified syntaxicallythanks to the keyword pure. Let PureC be the set of puremethods of the class C. Let PMC ¼MCnPureC denotethe set of the so-called progress methods of the class C,that is, with a side effect. An interesting property isobtained when M ¼ PMC . In this particular case, theprogress hypothesis PH(M ) is not only sufficient but alsonecessary.

Proposition 5: Let s [ SC be an execution. If s oLoopC (Q, V , PMC Þ and C :A1�5 then s o PH (PMC ).

6 Liveness temporal patternsIn [7], we have presented a way to verify liveness propertiesexpressed with the LoopC operator. This section presentsa practical context of Java/JML verification where thisverification method is applied.

Along the line of helping Java programmers in writingformal specifications, Trentelman and Huisman [4] proposeda temporal extension of JML inspired by the pragmatic workof the SanTos Specification Pattern Project [21]. We referto this temporal extension of JML as JTPL, for TemporalPattern Language, prefixed by a ‘J’ to denote its adaptationto Java. The semantics of temporal formulae in JTPL andtranslation rules into JML annotations are detailed in [4] forsafety properties and in [22] for liveness properties. Thissection defines a verification technique for liveness propertiesexpressible in JTPL, a problem left open by Trentelman andHuisman [4]. This verification is performed by translatingthese properties into the LoopC operator.

6.1 Language overview

JTPL provides the user with patterns to express commontemporal requirements of Java classes. Moreover, the languagedeals with normal and abnormal method terminations. JTPLis based on the notion of trace property which is either alwaysP, eventually P, or the conjunction or disjunction of two traceproperties. always P is true on an execution s if P holds onevery state of s. eventually P is true on an execution s if Pholds on at least one state of s.

It is often useful to reduce the scope of a trace property,that is, specifying it only for subparts of an execution. Thisis made possible by the notion of event. An event can be:(i) m called, denoting that the method m has been invoked;

509


51

&

www.ietdl.org

(ii) m normal, denoting that the method m has terminatednormally, that is, without throwing any exception; (iii) mexceptional, denoting that the method m has terminated bythrowing an exception or (iv) m terminates, denoting thatthe method m has terminated either normally or bythrowing an exception.

Now, a temporal property in JTPL is inductively defined asfollows: let E be a disjunction of events, C a trace property andT a temporal property. A temporal property can be either:(a) after E T, which is true on an execution s if the suffix ofs starting after each occurrence of an event in E satisfies thetemporal formula T; (b) before E C, which is true on anexecution s if the prefix of s ending with each occurrence ofan event in E satisfies the trace property C; (c) C until E,which is true on an execution s if an event in E occurs andif the trace property C is satisfied on the segment of s

ending with an event in E; (d) C unless E, which is true onan execution s if an event in E occurs and the trace propertyC is satisfied on the segment of s ending with an event inE, or the trace property C is satisfied on the whole executions and E never happens; or (e) between E E0 C, which is trueon an execution s if the temporal formula after E (C untilE0) holds on s, or (f ) a trace property C.

6.1.1 Safety and liveness characterisation: Theproperties described by this extension of JML are either safetyproperties or liveness properties. The following propositionmakes it possible to distinguish them syntactically:

Proposition 6 (characterisation of safety and livenessproperties): The properties containing only the keywordsafter, before, unless and always are safety properties. Theproperties containing the keyword eventually iff theycontain the keyword before also are safety properties. Theother properties are liveness properties.

For liveness properties, the verification is based on thedecrease of a well-founded variant given by the user.Therefore we propose to extend the syntax of livenessformulae with the following clause:

under [invariant ,JMLProp. ] variant ,JMLExpr.[for ,Methods.]

In the above clause, ,JMLProp. is a JML predicate whichis an optional local invariant – like a loop invariant – that canhelp the proof, ,JMLExpr. is the variant expression (itstype is a natural number), and ,Methods. is a list of Javamethod names.

6.1.2 Back to the example: Using JTPL formulae, onecan express the following properties on the Buffer example(Fig. 1 Section 2):

1. After the invocation of storeData (after storeDatacalled), the variable customized is always true, expressed


in JTPL as follows:

after storeData called always customized (S)

2. After starting a transaction, that is, after normaltermination of the method begin (after begin normal), astate where trDepth is false must eventually be reached.

after begin normal eventually !trDepth

under variant getBufferLess()

for begin, commit, abort, write; (L)

Property S is a safety property and property L is a livenessproperty. Notice that in (L), the event is begin normaland not begin called since a buffer transaction starts onlywhen the method begin terminates normally. Notice alsothat since (L) is a liveness property, the user has to give avariant and a set of progress methods with the JTPL clauseunder variant . . . for. Here, the variant corresponds to thefree space in the Buffer, and the for clause contains a listof methods that can potentially modify the value of thevariant. So, storeData is not in the list.

6.2 Embedding liveness properties intothe Loop clause

This section presents a translation of a JTPL livenessproperty into a LoopC clause completed with other JMLannotations. First, we present the translation for the basicafter E eventually P liveness property. Then, we generaliseto the other JTPL liveness properties.

Let us consider a temporal formula of the form

after E eventually P under variant V for M (11)

To translate liveness JTPL properties, like (11), into a LoopC

clause, one needs to observe whether a particular event hasalready occurred or whether a state satisfying a predicate hasalready been reached. For that, we define a witnessprimitive, denoted JML(X1, X2), where X1 and X2 are eitherJML predicates or JTPL events. Intuitively, given anexecution s, JML(X1, X2) is satisfied on all states of s

between the states satisfying X1 and X2.

Definition 15 (witness primitive): Let s be anexecution and i a natural number between 0 andlen(s)� 1. A state s (i) satisfies JML(X1, X2) iff 9j:(0 � j ,

i ^ s( j) o X1 ^ 8k:( j , k , i) s(k) p X2)).

The witness primitives are expressed by JML ghostvariables that are assigned w.r.t. events occurring in the


IETdo

www.ietdl.org

formula. The general rules can be easily derived from thefollowing examples:

Example 1 (ghost variables generation for S): The ghostvariable witness_S corresponds to the event storeDatacalled of S. It is initially declared with the value false(see annotation Sa in Fig. 5) and it is set to truewhen the method storeData is called (see annotation Sb).So, in each state after the event storeData called,the value of the ghost variable witness_S is true,that is, witness_S is true exactly with the scope of theproperty.

Example 2 (ghost variables generation for L): The ghostvariable witness_L, corresponding to the event beginnormal of the temporal property L is also declared withthe value false (annotation La in Fig. 5). Theghost variable witness_L is assigned using atry {try {T1} catch {T2} } finally {T3} statement(see annotation Lb). Notice that in the case of exception,the caught exception is re-thrown. The reader can see thatwitness_L is set to true only when begin normaloccurs. The ghost variable witness_L is set to:trDepth again by adding a set statement (annotationLc) to each method.

Thanks to an adequate witness, one can give a LoopC

clause ensuring property (11). Using the semantics of JTPLin [1] and the semantics in Section 4, one can show thatproperty (11) holds on the execution s if s o LoopC

(JML(E, P), V , M).

In a similar way, the other JTPL liveness patterns can betranslated into JML annotations (using the LoopC clause)by the rules given in Fig. 4. For each LoopC(Q, V, M ), thelocal invariant J is expressed by an invariant clauseinvariant Q ¼¼. J . The safety part of the property isalso translated into an invariant.


Example 3 (generation of annotations for L): The JMLtranslation of L is

LoopC (witness L, getBufferLess(),

{begin, commit, abort, write})

The corresponding annotations are displayed in Fig. 5 (seeannotations Lloop). Notice that, since no method ofBuffer diverges, annotation A5 does not appear.

7 JML annotation generatorThe automatic generation of JML annotations for safetyproperties in [4] and for liveness properties in Section 5has been implemented in a tool, called JAG [23]. TheJAG release parses a Java file – possibly already JMLannotated – with the JML parser included in theCommon JML tools and takes a file containing temporalformulae as other input. JAG is freely available from pagehttp://jag.univ-fcomte.fr.

7.1 Translating temporal formulae intointermediate primitives

The tool reduces each temporal property into one or moreintermediate primitives, like the witness primitive, thatare semantically equivalent [4, 22]. These primitives are aninternal format which is independent of the JML syntax,allowing an easy extension of the annotation generation toother specification languages, such as Spec].

7.2 Translating intermediate primitivesinto standard JML annotations

Each intermediate Inv primitive representing the safety partof a property is translated into a JML invariant. Eachintermediate Loop primitive representing the liveness partof the property is translated into a set of invariantsand history constraints that imply the decreasing

Figure 4 Translation of JTPL liveness patterns using the LoopC clause

511


51

&

www.ietdl.org

Figure 5 Buffer with generated annotations

of the variant and the deadlock-freeness of the system.Each witness is translated into a JML ghost variable.Finally, the tool generates an output file including theoriginal file and enriched with the generated JMLannotations. Fig. 5 contains the result of the translation ofproperties S and L.

Example 4 (invariant generation for S): The invariant for S isdisplayed in Fig. 5 (annotation Sc). It means that when thevariable witness_S is true, that is, after the firstoccurrence of storeData called, the predicate must betrue – the definition of property S.

7.3 Trace preservation

The tool is able to keep the trace of the generated annotations,that is, it is possible, given a generated annotation, to find theoriginal intermediate primitive and the original temporalproperty.

7.4 Experiments

Since the generated output file contains standard JMLannotations, it can be used with other JML tools [2] to


validate or prove the temporal formulae. For instance,Table 1 – where ‘PO’ stands for ‘Proof Obligation’ –summarises the results we have obtained with the JACKtool [12]. All the 277 POs in fourth column have beenproved either fully automatically (for 274 POs) orinteractively (for remaining three POs by enforcinginvariants) with the B4free tool as a back-end theoremprover.

TransactionSystem and AtmTransaction are two academicexamples. TransactionSystem is adapted from [4] andinspired by the JavaCard transaction mechanism, thatensures that every transaction in a smart card is atomic.AtmTransaction implements a transactional mechanismbetween a smard card and a terminal. Notice that ourtheoretical contributions have been applied not only to thatacademic examples but also to the Demoney system, a JavaCard Electronic Purse application we have developed in theframework of an industrial collaboration with TrustedLogic (http://www.trusted-logic.com/), via the ACIGECCOO project. For this application (whosedemonstrative electronic purse – card specification isavailable at http://www.doc.ic.ac.uk/~siveroni/secsafe/), wewrote over 500 lines of JML annotations.

Table 1 Results for temporal properties verification

Example name Number of temporalproperties to verify

Number of generatedannotation lines

Number of POs (automaticallyproved)

TransactionSystem 2 18 92 (91)

AtmTransaction 2 21 171 (171)

Electronic purse (Demoney) 2 25 14 (12)


IEd

www.ietdl.org

Moreover, we have successfully used the JAG tool for thefollowing purposes:

† Verification of the correctness of the Java code w.r.t. theJML annotations with the proof obligation generators Jack[12] and Krakatoa [13];

† Validation of a JML model with JML-TT [24];

† Formal verification of a JML model with the JML2Bmethod [25];

† Test generation and runtime assertion checking with thetest generators Tobias [26], Jartege [27] and JML-TT [28].

Test generation and Runtime Assertion Checking using JAGhave been studied on an industrial Java Card application [29].

8 Conclusion and future worksThis paper presents a way to verify liveness properties onJava classes in isolation by generating appropriate JMLannotations. This requires that the user specify a variantfor the verification of a Loop clause to which livenessproperties are reduced. The generated JML annotations areverified (or validated) with any tool handling JML. TheJAG tool implements this translation. It has been used forseveral toy examples and a Java Card Electronic PurseSpecification (over 500 lines of JML).

To the best of our knowledge, this is the first attempt toverify liveness properties for potentially infinite-state systemsusing a translation into JML. We are working on extensionsof JAG to other temporal properties. In particular, wecurrently address the verification of properties expressed byBuchi automata. Assuming that a liveness is established onthe class in isolation, another challenge is to providetechniques for verifying that the (single- or multi-threaded)environment effectively satisfies a progress hypothesis.

9 AcknowledgmentsWe would like to thank Pierre Lescanne for his helpfuladvice, Marieke Huisman for her interesting and helpfulcomments and suggestions to improve this work, and theanonymous referees for their corrections, comments andadvice. This research is partially funded by the FrenchNational Research Agency, ANR-06-SETI-017 TACOS.

10 References

[1] BREUNESSE C-B., CATANO N., HUISMAN M., JACOBS B.: ‘Formalmethods for smart cards: an experience report’, Sci.Comput. Program., 2005, 55, (1–3), pp. 53–80

[2] BURDY L., CHEON Y., COK D., ET AL.: ‘An overview of JML toolsand applications’. FMICS 03, 2003, (LNCS, 80), pp. 73–89

T Softw., 2008, Vol. 2, No. 6, pp. 500–514oi: 10.1049/iet-sen:20080008

[3] LAMPORT L.: ‘Proving the correctness of multiprocessprograms’, IEEE Trans. Softw. Eng., 1977, 3, (2), pp. 125–143

[4] TRENTELMAN K., HUISMAN M.: ‘Extending JML specificationswith temporal logic’. AMAST’02, 2002, (LNCS, 2422),pp. 334–348

[5] GIORGETTI A., GROSLAMBERT J.: ‘Un programme annote en vautdeux’. JFLA’07, Journees francophones des langages applicatifs,Aix-les-Bains, France, January 2007 INRIA pp. 87–101

[6] LOGOZZO F.: ‘Class invariants as abstract interpretationof trace semantics’, Comput. Lang., Syst. Struct., To bepublished.

[7] GROSLAMBERT J., JULLIAND J., KOUCHNARENKO O.: ‘JML-basedverification of liveness properties on a class in isolation’.SAVCBS’06, Specification and Verification of Component-Based Systems, Portland, Oregon, USA, November 2006,pp. 41–48

[8] LEAVENS G.T., POLL E., CLIFTON C., ET AL.: ‘JML ReferenceManual’. Department of Computer Science, Iowa StateUniversity, Available at http://www.jmlspecs.org, 2003

[9] JACOBS B., MARCHE C., RAUCH N.: ‘Formal verification of acommercial smart card Applet with multiple tools’.AMAST’04, 2004, (LNCS, 3116), pp. 21–22

[10] MEYER B.: ‘Object-Oriented Software Construction’(Prentice Hall, 1997, 2nd rev. edn.)

[11] ROBBY E.R., DWYER M., HATCLIFF J.: ‘Checking strongspecifications using an extensible software model checkingframework’. TACAS 2004, 2004, (LNCS, 2988), pp. 404–420

[12] BURDY L., REQUET A., LANET J.L.: ‘Java Applet correctness:a developer-oriented approach’. FM’03, 2003, (LNCS, 2805),pp. 422–439

[13] MARCHE C., PAULIN-MOHRING C., URBAIN X.: ‘The Krakatoatool for certification of Java/Java Card programsannotated in JML’, J. Log. Algebr. Program., 2004, 58,(1–2), pp. 89–106

[14] TARSKI A.: ‘A lattice-theoretical fixpoint theorem and itsapplications’, Pac. J. Math., 1955, 5, (2), pp. 285–309

[15] COUSOT P.: ‘Constructive design of a hierarchy of semanticsof a transition system by abstract interpretation’, Electr. NotesTheor. Comput. Sci., 1997, 6, p. 25

[16] RAGHAVAN A.D., LEAVENS G.T.: ‘Desugaring JML methodspecifications’, Technical Report No., 00-03d, Iowa StateUniversity, Department of Computer Science, July 2003

[17] VAN DEN BERG J., HUISMAN M., JACOBS B., POLL E.: ‘Atype-theoretic memory model for verification of

513


www.ietdl.org

51

&

sequential java programs’. WADT, 1999, pp. 1 – 21, (LNCS,1827)

[18] LINDHOLM T., YELLIN F.: ‘The Java virtual machinespecification’ ‘The Java Series’, Addison-Wesley, Reading,MA, USA, 1997

[19] DIJKSTRA E.W.: ‘On weak and strong termination’,Selected Writings on Computing: A Personal Perspective,1982, pp. 355–357

[20] BURSTALL R.M.: ‘Program proving as hand simulation witha little induction’. IFIP Congress, 1974, pp. 308–312

[21] DWYER M.B., AVRUNIN G.S., CORBETT J.C.: ‘Patterns in propertyspecifications for finite-state verification’. In Proceedings ofthe 21st International Conference on Software Engineering,ICSE ’99, Los Angeles, CA, USA, 16 – 22 May 1999, IEEEComputer Society, Los Alamitos, CA, USA, pp. 411–420

[22] BELLEGARDE F., GROSLAMBERT J., HUISMAN M., JULLIAND J.,KOUCHNARENKO O.: ‘Verification of liveness properties withJML’. Technical Report RR-5331, INRIA, 2004

[23] GIORGETTI A., GROSLAMBERT J.: ‘JAG JML annotationgeneration for verifying temporal properties’. FASE’2006,


Fundamental Approaches to Software Engineering, 2006,(LNCS, 3922), pp. 373–376

[24] BOUQUET F., DADEAU F., LEGEARD B., UTTING M.: ‘JML-testing-tools: a symbolic animator for JML specifications usingCLP’. TACAS’05 Tool session, 2005, (LNCS, 3440), pp. 551–556

[25] BOUQUET F., DADEAU F., GROSLAMBERT J.: ‘Checking JMLspecifications with B machines’. ZB’05, 2005, (LNCS,3455), pp. 435–454

[26] LEDRU Y., DU BOUSQUET L., MAURY O., BONTRON P.: ‘FilteringTOBIAS combinatorial test suites’. FASE 2004, 2004, (LNCS,2984), pp. 281–294

[27] ORIAT C.: ‘Jartege: a tool for random generation of unittests for java classes’. SOQUA 2005, 2005, (LNCS, 3712),pp. 242–256

[28] BOUQUET F., DADEAU F., LEGEARD B.: ‘Automated boundarytest generation from JML specifications’. FM’06, 2006,(LNCS, 4085), pp. 428–443

[29] BOUQUET F., DADEAU F., GROSLAMBERT J., JULLIAND J.: ‘Safetyproperty driven test generation from JML specifications’.FATES/RV’06, 2006, (LNCS, 4262), pp. 225–239


Verification of class liveness properties with java modelling language

Documents

Transcript of Verification of class liveness properties with java modelling language