Verification of JML Generic Types with Yices

1 Verification of JML Generic Types with Yices Néstor Cataño The University of Madeira, Carnegie Mellon University Portugal ncatano@uma.pt Camilo Rueda Pontificia Universidad Javeriana Colombia crueda@javerianacali.edu.co Sorren Hanvey The University of Madeira, Portugal sorrenhanvey@m-iti.org Abstract Despite some efforts to provide support to JML (Java Modelling Language) for Java 1.5 and 1.6, no full implementation for checking Java s new features has been carried out. In particular, there is still no full support to JML and Java generic types. This paper presents an approach to check satisfiability of JML generic types by mapping JML specifications into the input language of Yices and using Yices SMT solver to do the checking. Our primary motivation for mapping JML generic types into Yices is to be able to use an efficient solver to verify a JML model for social networking we had obtained as translation from B. Our work focuses on the mapping of JML generic classes for sets and relations since B machines specifications are essentially predicate logic and set theory. We use the JML model for social networking as a running example to present our ideas throughout the paper. Index Terms B, Java, JML Generics, Refinement Calculus, SMT Solvers, Yices I. INTRODUCTION JML [1], [2] is a model based language designed for specifying interfaces and behaviour of Java classes. JML provides support to the idea of design-by-contract [3]. JML specifications are typically embedded directly into Java class implementations using special comment markers. JML specifications include various forms of invariants as well as preand post-conditions for methods. The syntax of JML is intentionally similar to that of Java so that it is less intimidating for developers. In particular, the mathematical types that are heavily used in other model based specification languages (sets, sequences, relations and functions) are provided in JML as classes, and the operations on those types are specified in JML and implemented as Java methods. There are a number of tools that provide support to the verification of JML specifications. These tools implement various techniques, e.g. ESC/Java 2 and its predecessor ESC/Java do extended-static checking of Java programs [4]. The JML common tools is a suite of tools performing runtime assertion checking of JML specifications. The suite includes the jmle tool that transforms JML specifications into executable constraint programs [5], [6]. Other tools like Jack [7] and Loop [8] do full verification of programs, which includes the interaction with theorem provers like Coq [9], PVS [10], or 978-1-4577-0286-0/11 / $26.00 c 2011 IEEE AtelierB [11]. The Krakatoa tool transforms JML-specified Java programs into Why programs and uses the Why tool to check correctness [12], [13]. There also exist programming environments that provide support to the formal software development of (Java) programs with JML, e.g. the Mobius and the OpenJML verification environments, which have been implemented as Eclipse plug-ins. A recurrent problem with the implementation of JML tools is that they need to keep up with the last versions of Java, which often requires to re-implement the tool or undertake large changes in its design. As an example of this, Java 1.5 introduced generic types so that classes implementing abstract data types can be parametrised. However, existing JML tools do not provide full support to the verification of generic specifications in JML. This paper presents an approach to the verification of generic specifications in JML. We map JML specifications into the input language of Yices an use Yices SMT solver to check the specifications for satisfiability. We focus on JML specification libraries that implement sets and relations. In practice, sets and relations allow one to model a large set of problems and systems. As an example of this, we undertook a case study on the verification of a social networking model in JML. The JML model was obtained as direct translation from a B model for social networking the two first authors presented in [14]. We use the JML model as a running example throughout the paper. In fact, our primary motivation for translating JML generic specifications into Yices is the verification of the original B model for social networking. In the following, Section II mentions some existing efforts to provide support to the verification of generic types. Section III gives an introduction to JML and Section IV introduces Yices. Section V presents our mapping of JML generic types into Yices. This includes JML method specifications and class invariants. It also presents our implementation of sets and relations, the basic structures over which the mapping from JML to Yices relies. The mapping is presented with the aid of the JML model for social networking. Section VI presents experimental results with the implementation of the social network model in Yices. Section VII presents conclusions and future work. Currently, we translate JML generic types into

2 Yices manually. We plan to implement the translation as a tool in the future. II. RELATED WORK In [15], Julian Charles proposes to extend JML with the construct native for modelling Java native types in JML. Hence, if JML is translated to another formal language representation such as Coq [9] or Jack [7], then the definition of the native type in the target language representation would be driven from the semantics of its definition in JML. His approach furnishes an alternative to the verification of JML generic types by defining them as JML native types and by doing the verification in the target formal language. In [16], David Cok proposes a series of changes and new features to JML so as to provide support to the new versions of Java, Java 1.5. and 1.6, which includes generic types. However, the proposed changes would require re-factoring JML. New features are still not fully implemented in OpenJML and OpenJDK. III. THE JAVA MODELLING LANGUAGE A simple JML specification for a Java class consists of pre- and post-conditions added to its methods, and class invariants restricting the possible states of class instances. Specifications for method pre- and post-conditions are embedded as comments immediately before method declarations. JML predicates are first-order logic predicates formed of sideeffect free Java boolean expressions and several specificationonly JML constructs. Because of this side-effect restriction, Java operators like ++ and -- are not allowed in JML specifications. JML provides notations for forward and backward logical implications, ==> and <==, for non-equivalence <=!=>, and for logical or and logical and, and &&. The JML notations for the standard universal and existential quantifiers are (\forall T x; E) and (\exists T x; E), where T x; declares a variable x of type T, and E is the expression that must hold for every (some) value of type T. JML provides specifications for several mathematical types such as sets, sequences, functions and relations. JML specifications are inherited by subclasses subclass objects must satisfy superclass invariants, and subclass methods must obey the specifications of all super-class methods that they override. This ensures behavioural subtyping a subclass object can always be used (correctly) where a super-class object is expected. However, our mapping from JML to Yices does not deal with inheritance. In the following, we briefly review the JML specification constructs. The reader is invited to consult [17] for a full introduction to JML. requires P. specifies a method pre-condition P, which must be true when the method is called. Predicate P is a valid JML predicate. ensures Q. specifies a normal method post-condition Q. It says that if the method terminates in a normal state, i.e. without throwing an exception, then the predicate Q will hold in that state. Predicate Q is a valid JML predicate. signals (E e) R. specifies an exceptional method postcondition R. It says that if the method throws an exception e of type E, a subtype of java.lang.exception, then the JML predicate R must hold. Predicate R is a valid JML predicate. normal_behavior. specifies that if the method precondition holds in the pre-state of the method, then it will always terminate in a normal state, and the normal postcondition will hold in this state. exceptional_behavior. specifies that if the method pre-condition holds in the pre-state of the method, then it will always terminate in an exceptional state, throwing a java.lang.exception, and the corresponding exceptional post-condition will hold in this state. assignable L. specifies that the method may only modify location L. Any other location not listed in L may therefore not be modified. This must be true for both normal and exceptional post-conditions. Two special assignable specifications exist, assignable \nothing, which specifies that the method modifies no location, and assignable \everything, which specifies that the method may modify any location. \old(e). refers to the value of the expression e in the prestate of a method. This specification can only be used in a normal or exceptional method post-condition specifications. \result. represents the value returned by a method. It can only be used in a normal or an exceptional method postcondition. invariant I. declares a class invariant I. In JML, class invariants must be established by the class constructors, and must hold after any public method is called. Invariants can temporally be broken inside methods, but must be reestablished before returning from them. Figure 1 presents a partial JML specification of a socialnetworking class that has been obtained as a direct translation from the B model for social networking introduced in [14]. The B model (and the JML model) models social-network content, social-networks friendship relations and socialnetworks privacy policies. The JML specification uses the type Integer to represent the people and content involved in the network. Sets PERSON and RAWCONTENT are the sets of possible people and content items (represented in JML as instances of org.jmlspecs.models.jmlequals- Set<Integer>), while person and rawcontent represent the people and content who are currently part of the network. The content relation (represented as an instance of class JMLEqualsToEqualsRelation) maps people to the content on their personal pages. The initially clause (which is implicitly conjoined to the post-condition of every constructor) specifies that person, rawcontent and content are all initially empty. The invariant states properties that must hold in every visible system state - specifically before a method is called and after a method terminates (normally or by throwing an exception). This is semantically equivalent to conjoining the invariant to the

3 pre- and post-conditions of each method specification (except for the pre-conditions of constructors). In the example in Figure 1, the people and content items involved in the network must be drawn from the sets of possible persons and items, respectively, and content is a total relation from person to rawcontent. JML Keyword model is used for specification-only components (that will not appear in a Java implementation). //@ model import org.jmlspecs.models.*; abstract class SOCIAL_NETWORK { /*@ model JMLEqualsSet<Integer> person; model JMLEqualsSet<Integer> PERSON; model JMLEqualsSet<Integer> rawcontent; model JMLEqualsSet<Integer> RAWCONTENT; model JMLEqualsToEqualsRelation<Integer,Integer> content; initially person.isempty() && rawcontent.isempty() && content.isempty(); invariant person.issubset(person) && rawcontent.issubset(rawcontent) && content.domain().equals(person) && content.range().equals(rawcontent); @*/ /*@ normal_behavior requires rawcontent.has(rc) && person.has(ow) && person.has(pe) &&!ow.equals(pe) &&!content.has(pe, rc); assignable content; ensures (\exists JMLEqualsSet<Integer> prs; prs.issubset(person); content.equals(\old(content.union( JMLEqualsToEqualsRelation.singleton(pe,rc)).union( ModelUtils.cartesian(prs, JMLEqualsSet.singleton(rc)))))); also exceptional_behavior requires!rawcontent.has(rc)!person.has(ow)!person.has(pe) ow.equals(pe) content.has(pe, rc); assignable \nothing; signals (Exception) true; @*/ abstract void transmit_rc(integer ow, Integer rc, Integer pe); } other expressions are evaluated in the poststate. All methods (except cartesian) that are called in this post-condition are specified and implemented in the model classes JMLEquals- Set and JMLEqualsToEqualsRelation (in the org.- jmlspecs.models package of JML). Class ModelUtils provides JML specifications and Java implementations of B operations that are not defined by the JML model classes. IV. THE SMT SOLVER YICES Yices is an SMT (Satisfiability Modulo Theories) solver developed at SRI International [18], [19]. It provides support for checking satisfiability of formulae containing uninterpreted function symbols with equality, linear real and integer arithmetic, bit-vectors, arrays, recursive data-types, universal and existential quantifiers, lambda expressions, tuples, and records. Hence, given a model in Yices, the solver returns sat, unsat, or unknown, meaning the model satisfiable, unsatisfiable or the solver cannot decide, respectively. The example below introduces a function foo in Yices. The symbol :: means it has type, so foo is a function over integers. foo is a lambda function that takes an integer element y and returns its successor. Variable x is declared and equalised to function foo applied to 1. The check instruction checks whether a valuation for x exists that equals foo evaluated in 1. The Yices model is therefore satisfiable (one needs to take x equals to 2). (define foo::(-> int int)) (assert (= foo (lambda (y::int) (+ y 1)))) (define x::int) (assert (= (foo 1) x)) (check) The Yices program below introduces a function foo over integers and asserts that all modelled functions return 0 when evaluated in 0. Hence, foo evaluated in 0 is not 1, and therefore the Yices program is unsatisfiable. Fig. 1. A partial JML specification of social networking class. The transmit_rc method adds a content item from one person s page to another person s page, as specified in the normal behavior case. The exceptional behavior case specifies that the method will throw an exception if the content can not be added. In the normal behavior case, the pre-condition (requires in JML) specifies that the people and content items involved are valid, that the two people involved are not actually the same person, and that the second person does not already have the content item on their page. As usual, if a method is called in a state that does not satisfy its precondition, nothing is guaranteed about the resulting poststate. The assignable clause is a frame condition specifying what locations may change from the prestate to the poststate (in this case, the content field). The prestate is the state on entry to the method and the poststate is the state on exit from the method. The post-condition (ensures in JML) specifies that the content item is transmitted to the second person, and possibly to some additional people represented by the set prs. Expressions in \old are evaluated in the prestate, while all (define foo::(-> int int)) (assert (forall (f::(-> int int)) (= (f 0) 0))) (assert (= (foo 0) 1)) (check) V. JML GENERIC TYPES IN YICES Our primary motivation for translating JML generic types into Yices input language is to use Yices SMT solver to check satisfiability of a JML model for social networking obtained as a translation from B. The B model is called Matelas [14]. It is a predicate calculus specification for social networking that models social-network content, social-network privacy policies, and social-network friendship relations. Matelas implements privacy polices with the aid of access permissions relations. The predicate calculus used is essentially predicate logic supplemented with set theory. In B, sets are set of integers. Social-network friendship, access permissions, etc. are essentially relations over integers. In the following, we first introduce our implementation of sets (of integers) and relations (over integers) in Yices, then discuss the translation of JML method and class specifications into Yices.

4 A. Sets and Relations Sets and relations are the basic structures over which the mapping from JML to Yices relies. Hence, sets and relations need to be implemented efficiently. Our primary motivation was to write Java code for mobile applications that can be verified efficiently (within a couple of seconds) by checking against our mapping of JML specifications into Yices. Our first attempts to implement sets and relations in Yices sought to furnish algebraic specifications for sets and relations and to use Yices SMT solver to do satisfiability checking. For instance, an integer set can be modelled as a function that takes an element of type set-type and returns true or false whether the element is in the set or not (see below). (define-type set-type) (define-type jmlset (-> set-type bool)) (define jmlset-is-equal::(-> jmlset jmlset bool) (lambda(s1::jmlset s2::jmlset) (forall (x::set-type) (= (s1 x) (s2 x))))) (define jmlset-singleton::(-> set-type jmlset) (lambda(a::set-type) (lambda(b::set-type) (= b a)) ) ) (define x::set-type) (assert (jmlset-is-equal (jmlset-singleton x) (jmlset-singleton x))) (check) Function jmlset-is-equal returns true of two sets if they are equal, and function jmlset-singleton builds a singleton set. However, Yices returns unknown when asked whether two singleton sets containing the same element are equal. The reason of this is that Yices reasons algebraically on the equality of this two sets for which one would need a full axiomatisation (of sets and relations). Therefore, we adopted a different approach to modelling sets and relations. We encoded sets and relations as bit-vectors. A set of integers is encoded by the type jmlset, defined as a bit-vector of fixed size, say 8. The elements of the set are those positions with bit equals to 1. A relation over integers, encoded by the type jmlrel, is defined as a bit-vector of size 64 (see below). Our experience shows that these sizes are big enough to check satisfiability of our JML specifications in Yices. (define-type jmlset (bitvector 8)) (define-type jmlrel (bitvector 64)) In implementing sets and relations, our main concern is that the evaluation of a single formula must be performed within seconds. Hence, we avoided recursive definitions of functions manipulating sets and relations. As an example of this, function jmlset-singleton below, which builds a singleton set of an integer, could have been implemented recursively using the bit-vector function bv-shift-left0 of Yices, which introduces 0 from the right to the left of a bit-vector (Yices disallows expressions (bv-shift-left0 bv a) for a general expression a, though). (define set-bv0::(bitvector 8) (mk-bv 8 0)) (define jmlset-singleton::(-> int jmlset) (lambda(a::int) (if (= a 0) set-bv0 (if (= a 1) set-bv1 (if (= a 2) set-bv2 (if (= a 3) set-bv3 (if (= a 4) set-bv4 (if (= a 5) set-bv5 (if (= a 6) set-bv6 (if (= a 7) set-bv7 (if (= a 8) set-bv8 set-bv0 ) )))))))))) Other function definitions are trickier, e.g. a non-recursive definition for the inverse of a relation (not shown here) requires extracting elements of type jmlset (bit-vectors of size 8) from the relation, and operating them to produce a proper element of type jmlrel (bit-vector of size 64). The definition of jmlrel-get-range (shown below), which returns the range of a relation, utilises a similar strategy: it extracts proper bit-vectors from the given relation, using the function bv-extract, and then calculates their union. (define jmlrel-get-range::(-> jmlrel jmlset) (lambda (r::jmlrel) (bv-extract 7 0 r) (bv-extract 15 8 r) (bv-extract 23 16 r) (bv-extract 31 24 r) (bv-extract 39 32 r) (bv-extract 47 40 r) (bv-extract 55 48 r) (bv-extract 63 56 r) ))))))))) B. JML Method Specifications JML predicates are naturally mapped into predicates in Yices. JML logical operators such as ==>, &&, and are naturally mapped into predicates imp, and, and or respectively. JML abstract model variables modelling carrier sets (e.g. PERSON and RAWCONTENT in Figure 1) are mapped into global variables of type jmlset. For instance, the JML abstract variable declaration //@ model JMLEqualsSet<Integer> PERSON gives origin to the following variable declaration in Yices. (mk-bv 8 127) builds a bit-vector of size 8 with initial value 127. The initial value of person-carrier ensures that the set it represents includes every possible element in its domain. (define person-carrier::jmlset (mk-bv 8 127)) The mapping of JML normal and exceptional postconditions into Yices rely upon the use of lambda expressions that capture the semantics of the JML specifications (see the transmit_rc and its use of normal_behavior and exceptional_behavior specifications in Figure 1). We define two predicates in Yices that implement the mapping of JML method specifications. The first predicate models the

5 pre-condition part of the JML method specification and the second models the post-condition part of it. Function precondition-transmit-rc implements the normal pre-condition of method transmit_rc in Yices. The function makes use of predicate jmlset-is-member, which checks for the existence of an element in a set, and the standard Yices function mk-tuple, which constructs a pair of elements. (define precondition-transmit-rc:: (-> jmlset jmlset jmlrel (-> int int int bool)) (lambda(rawcontent::jmlset person::jmlset content::jmlrel) (lambda(ow::int rc::int pe::int) (and (jmlset-is-member rawcontent-carrier rc) (jmlset-is-member rawcontent rc) (jmlset-is-member person-carrier ow) (jmlset-is-member person ow) (not (= ow pe)) (not (jmlrel-is-member content (mk-tuple pe rc))))))) Function postcondition-transmit-rc implements the normal post-condition of method transmit_rc in Yices. JML existential quantifiers are naturally mapped to the predicate exists in Yices. Function jmlrel-product-set-singleton implements the cross product between a general set with a singleton set in Yices. Function jmlrel-add-element adds a pair of elements to a relation, function jmlrel-is-equal checks for equality between two relations, and function jmlrel-union calculates the union between two relations. The implementation of these functions is not shown here, though. (define postcondition-transmit-rc:: (-> jmlset jmlset jmlrel (-> jmlset jmlset jmlrel (-> int int int bool))) (lambda(rawcontent-prestate::jmlset person-prestate::jmlset content-prestate::jmlrel) (lambda(rawcontent::jmlset person::jmlset content::jmlrel) (lambda(ow::int rc::int pe::int) (exists(prs::jmlset) (and (jmlset-is-subset prs person-prestate) (jmlrel-is-equal content (jmlrel-union (jmlrel-add-element content-prestate (mk-tuple pe rc)) (jmlrel-product-set-singleton prs rc))) (= rawcontent-prestate rawcontent) (= person-prestate person) )))))) JML frame-conditions (which are written with the aid of the assignable clause of JML) can be rephrased as method post-conditions stating that every variable except for the ones mentioned in the assignable specification changes its value from the pre-state to the poststate of the method. As an example of a translation of a JML assignable into Yices, the assignable content; specification in Figure 1 is mapped into the conjunction of the equalities (= rawcontent-prestate rawcontent) and (= person-prestate person) in postcondition-transmit-rc above. In general, a JML specification such as //@ assignable \nothing would generate equality conditions for every variable, and //@ assignable \everything would generate no equality checking. Finally, the parameters of the predicates mapping JML method pre- and post-conditions are the class fields (except for the fields representing carrier sets), and the parameters of the method in JML. For example, the parameters of the predicate for the normal post-condition of transmit_rc are person and rawcontent of type jmlset, content of type jmlrel, and ow, rc, and pe of type integer. C. Beyond Method Specifications JML enforces behavioural subtyping - an overriding method inherits the specifications of all methods that it overrides, which causes the behaviour of subclasses to be consistent with the behaviour of all super-classes. Our current translation of JML specifications into Yices does not deal with inheritance. JML invariant specifications restrict the possible states of class objects. In JML, class invariants are implicitly added as pre- and post-conditions of every (public) class method. In verifying method specifications with Yices, we keep trace of the pre- and post-state value of class fields, and thus conditions are added that constraint how class fields change their state (how they evolve). Hence, the JML invariant //@ invariant person.issubset(person) is asserted (using the command assert of Yices) as several conditions that constraint the value of person in the pre- and post-state of every method. Additionally, the initial value of person is restricted by the specification //@ initially person.isempty(). VI. EXPERIMENTAL RESULTS We carried out some preliminary experiments on the performance of the implementation of the JML social-network functions in Yices. Table I presents user and system time for the execution of these functions. The time required by the Yices SMT solver to give an answer is shown in seconds. The solver returns sat for the execution of all the functions. Function create-rc creates a new content in the social network, create-content creates a user account, edit-rc modifies a particular content, hide-rc changes the status of a content from visible to invisible, make-visible changes the status of a content from invisible to visible, remove-rc and remove-owned-rc remove a (owned) content from the network, transmit-rc sends a copy of a particular content from a user s account to another, upload-rc transfers a newly created content into a person s page, and comment-rc uploads a content to a person s wall. These functions use further functions, e.g. to transmit a content, one needs to create the content previously. Last column in Table I tells the number of these additional functions. For some of the considered functions, e.g. transmit-rc, make-visible, comment-rc, or edit-rc, the Yices

6 Function User (Sec) Sys (Sec) # Funcs create-rc 0.03 0.02 1 create-content 0.02 0.01 1 edit-rc 174.05 1.97 4 hide-rc 60.08 1.71 5 make-visible 286.44 19.89 4 remove-rc 180.31 1.98 4 remove-owned-rc 130.34 2.21 4 transmit-rc 180.55 1.96 5 upload-rc 180.02 2.18 3 comment-rc 202.98 1.92 5 TABLE I YICES IMPLEMENTATION OF THE MODEL FOR SOCIAL NETWORKING SMT solver takes considerable time for giving an answer. This is mainly due to the fact that Yices needs to resolve existential quantifiers that range over (a large subset of) integers. We circumvent this problem by transforming existential predicates into lambda expressions with an extra parameter: an element making the predicate true. Existential quantification in Yices is obtained from direct translation of the JML existential predicate \exists. VII. CONCLUSION AND FUTURE WORK Reliability of systems is an issue in software engineering and in other disciplines. Reliability is determined by the presence of absence of bugs. Bugs are a permanent companion of software developers and a source of dissatisfaction of users of software systems. Light-weight formal tools (semiautomatic) are appealing to formal methods users that want to check for the correctness of their programs. Hence, one can check program correctness quickly and use the tool feedback to evolve the formal model. However, the model (e.g. a program in Yices) often needs to be tweaked so as to get the right level of automation. This often requires user expertise and ingenuity. This paper presents an approach to check the satisfiability of JML generics by mapping JML specifications into the input language of Yices, and using Yices solver to perform the checking. This work is part of a more general work in which we plan to use Proof Carrying Code techniques [20] to check Java implementations of social networking applications for mobile devices [21]. The Java code is specified with JML, the JML specifications are ported into Yices input language, and Yices solver is used to check the specifications. The work presented in this paper focus on particular JML specifications classes that relate to sets, e.g. JMLEqualsSet, JMLEqualsToEqualsRelation. Hence, many problems can be modelled and verified using our approach. The translation of JML generics into Yices is done manually, having a tool-supported translation is future work. We do not deal with inheritance of JML specifications. This is also future work. REFERENCES [1] G. Leavens, A. Baker, and C. Ruby, Preliminary design of JML: A behavioral interface specification language for Java, ACM SIGSOFT, vol. 31, no. 3, pp. 1 38, 2006. [2] Robby and P. Chalin, Preliminary design of a unified JML representation and software infrastructure, in Symposium on Formal Techniques for Java-like programs (FTfJP). ACM, 2009, pp. 1 7. [3] B. Meyer, Applying design by contract, Computer, vol. 25, no. 10, pp. 40 51, October 1992. [4] C. Flanagan, K. R. M. Leino, M. Lillibridge, G. Nelson, J. B. Saxe, and R. Stata, Extended static checking for java, in Programming Languages Design and Implementation (PLDI), 2002, pp. 234 245. [5] B. Krause and T. Wahls, jmle: A tool for executing JML specifications via constraint programming, in Formal Methods for Industrial Critical Systems (FMICS), ser. Lecture Notes in Computer Science, L. Brim, Ed., vol. 4346. Springer-Verlag, August 2006, pp. 293 296. [6] N. Catano and T. Wahls, Executing jml specifications of java card applications: A case study, in 24th ACM Symposium on Applied Computing, Software Engineering Track (SAC), Waikiki Beach, Honolulu, Hawaii, March 8-12 2009. [7] L. Burdy, Y. Cheon, D. Cok, M. Ernst, J. Kiniry, G. Leavens, K. Leino, and E. Poll, An overview of JML tools and applications, in Formal Methods for Industrial Critical Systems (FMICS), ser. Electronic Notes in Theoretical Computer Science, T. Arts and W. Fokkink, Eds., no. 80. Elsevier, Amsterdam, 2003. [8] J. van den Berg and B. Jacobs, The LOOP compiler for Java and JML, in Tools and Algorithms for the Construction of and Analysis of Systems (TACAS), ser. Lecture Notes in Computer Science, no. 2031. Springer, 2001, pp. 299 312. [9] Y. Bertot and P. Castéran, Interactive Theorem Proving and Program Development. Coq Art: The Calculus of Inductive Constructions, ser. Texts in Theoretical Computer Science. Springer Verlag, 2004. [10] S. Owre, N. Shankar, J. Rushby, and D. Stringer-Calvert, PVS Language Reference, Computer Science Laboratory, SRI International, Menlo Park, CA, 2011. [11] J. R. Abrial, The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996. [12] J.-C. Filliâtre, Why: a multi-language multi-prover verification tool, LRI, Université Paris Sud, Research Report 1366, 2003. [13] J.-C. Filliâtre and C. Marché, The Why/Krakatoa/Caduceus platform for deductive program verification, in Conference on Computer-Aided Verification (CAV), ser. Lecture Notes in Computer Science, W. Damm and H. Hermann, Eds., vol. 4590, 2007, pp. 173 177. [14] N. Catano and C. Rueda, Matelas: A predicate calculus common formal definition for social networking, in ASM, Alloy, B, and Z, ABZ, ser. Lecture Notes in Computer Science, M. F. et al., Ed., vol. 5977, Québec, Canada, 2010, pp. 259 272. [15] J. Charles, Adding native specifications to JML, in Formal Techniques for Java-like Programs (FTfJP), 2006. [16] D. R. Cok, Adapting jml to generic types and java 1.6, in Specification and Verification of Component-Based Systems (SAVCBS), 2008, pp. 27 35. [17] G. Leavens, E. Poll, C. Clifton, Y. Cheon, C. Ruby, D. Cok, P. Müller, J. Kiniry, and P. Chalin, JML reference manual, http://www.eecs.ucf.edu/ leavens/jml/jmlrefman/- jmlrefman_toc.html. [18] B. Dutertre and L. de Moura, A Fast Linear-Arithmetic Solver for DPLL(T), in Computer-Aided Verification (CAV), ser. Lecture Notes in Computer Science, vol. 4144. Springer-Verlag, 2006, pp. 81 94. [19] B. Duterte and L. de Moura, The YICES SMT solver, Computer Science Laboratory, SRI International, Tech. Rep., 2006. [20] G. C. Necula, Proof-carrying code, in Symposium on Principles of Programming Languages (POPL), Paris, January 1997, pp. 106 119. [21] G. Necula and P. Lee, Research on proof-carrying code for untrustedcode security, in Symposium on Security and Privacy, 1997, p. 204. ACKNOWLEDGEMENTS Research funding was provided by FCT, under grant PT/SE/0028/2008.