Formal Specification and Verification
|
|
|
- Reginald Gray
- 5 years ago
- Views:
Transcription
1 Formal Specification and Verification Proof Obligations Bernhard Beckert Based on a lecture by Wolfgang Ahrendt and Reiner Hähnle at Chalmers University, Göteborg Formal Specification and Verification: Proof Obligations B. Beckert 1 / 55
2 This Part making the connection between JML and Dynamic Logic / KeY Formal Specification and Verification: Proof Obligations B. Beckert 2 / 55
3 This Part making the connection between JML and Dynamic Logic / KeY generating, Formal Specification and Verification: Proof Obligations B. Beckert 2 / 55
4 This Part making the connection between JML and Dynamic Logic / KeY generating, understanding, Formal Specification and Verification: Proof Obligations B. Beckert 2 / 55
5 This Part making the connection between JML and Dynamic Logic / KeY generating, understanding, and proving DL proof obligations from JML specifications Formal Specification and Verification: Proof Obligations B. Beckert 2 / 55
6 Tutorial Example we follow KeY Quicktour for JML (cited below as [KQJ]) scenario: simple PayCard Formal Specification and Verification: Proof Obligations B. Beckert 3 / 55
7 Inspecting JML Specification inspect quicktour/jml/paycard/paycard.java follow [KQJ, 2.2] Formal Specification and Verification: Proof Obligations B. Beckert 4 / 55
8 New JML Feature I: Nested Specification Cases method charge() has nested specification public requires requires amount+balance<limit && ensures \result == ensures balance == amount + @ requires amount + balance >= ensures \result == ensures == \old(unsuccessfuloperations) + assignable } Formal Specification and Verification: Proof Obligations B. Beckert 6 / 55
9 Nested Specification Cases nested specification cases allow to factor out common public requires requires ensures @ requires ensures assignable } expands to... (next page) Formal Specification and Verification: Proof Obligations B. Beckert 8 / 55
10 Nested Specification Cases (previous page)... expands public requires requires ensures @ public requires requires ensures assignable A2; Formal Specification and Verification: Proof Obligations B. Beckert 10 / 55
11 Nested Specification public requires requires amount+balance<limit && ensures \result == ensures balance == amount + @ requires amount + balance >= ensures \result == ensures == \old(unsuccessfuloperations) + assignable } expands to... (next page) Formal Specification and Verification: Proof Obligations B. Beckert 12 / 55
12 Nested Specification Cases (previous page)... expands public requires requires amount+balance<limit && ensures \result == ensures balance == amount + @ public requires requires amount + balance >= ensures \result == ensures == \old(unsuccessfuloperations) + assignable unsuccessfuloperations; Formal Specification and Verification: Proof Obligations B. Beckert 14 / 55
13 New JML Feature II: assignable \nothing method charge() has exceptional behavior public requires amount <= assignable \nothing; Formal Specification and Verification: Proof Obligations B. Beckert 16 / 55
14 New JML Feature II: assignable \nothing method charge() has exceptional behavior public requires amount <= assignable \nothing; assignable \nothing prohibits side effects difference to pure: pure also prohibits non-termination assignable clause is local to specification case (here: local to exceptional_behavior) Formal Specification and Verification: Proof Obligations B. Beckert 16 / 55
15 Generating Proof Obligations (POs) generate EnsuresPost PO for normal behavior of charge() Formal Specification and Verification: Proof Obligations B. Beckert 17 / 55
16 Generating Proof Obligations (POs) generate EnsuresPost PO for normal behavior of charge() follow [KQJ, ] summary: start KeY prover in quicktour/jml, open paycard select charge and EnsuresPost inspect Assumed Invariants Formal Specification and Verification: Proof Obligations B. Beckert 17 / 55
17 Generating Proof Obligations (POs) generate EnsuresPost PO for normal behavior of charge() follow [KQJ, ] summary: start KeY prover in quicktour/jml, open paycard select charge and EnsuresPost inspect Assumed Invariants assuming less invariants: is fully sound can compromise provability Formal Specification and Verification: Proof Obligations B. Beckert 17 / 55
18 Generating Proof Obligations (POs) generate EnsuresPost PO for normal behavior of charge() follow [KQJ, ] summary: start KeY prover in quicktour/jml, open paycard select charge and EnsuresPost inspect Assumed Invariants assuming less invariants: is fully sound can compromise provability sometimes invariants of other classes also needed (select class+inv.) Formal Specification and Verification: Proof Obligations B. Beckert 17 / 55
19 Generating Proof Obligations (POs) generate EnsuresPost PO for normal behavior of charge() follow [KQJ, ] summary: start KeY prover in quicktour/jml, open paycard select charge and EnsuresPost inspect Assumed Invariants assuming less invariants: is fully sound can compromise provability sometimes invariants of other classes also needed (select class+inv.) select contract which modifies balance Formal Specification and Verification: Proof Obligations B. Beckert 17 / 55
20 Generating Proof Obligations (POs) generate EnsuresPost PO for normal behavior of charge() follow [KQJ, ] summary: start KeY prover in quicktour/jml, open paycard select charge and EnsuresPost inspect Assumed Invariants assuming less invariants: is fully sound can compromise provability sometimes invariants of other classes also needed (select class+inv.) select contract which modifies balance (in JML: modifies synonymous for assignable) Formal Specification and Verification: Proof Obligations B. Beckert 17 / 55
21 Generating Proof Obligations (POs) generate EnsuresPost PO for normal behavior of charge() follow [KQJ, ] summary: start KeY prover in quicktour/jml, open paycard select charge and EnsuresPost inspect Assumed Invariants assuming less invariants: is fully sound can compromise provability sometimes invariants of other classes also needed (select class+inv.) select contract which modifies balance (in JML: modifies synonymous for assignable) Current Goal pane displays proof obligation as DL sequent Formal Specification and Verification: Proof Obligations B. Beckert 17 / 55
22 Generating Proof Obligations for loading more proof obligations: re-open Proof Obligation Browser under Tools menu generate EnsuresPost PO for normal behavior of isvalid() Formal Specification and Verification: Proof Obligations B. Beckert 18 / 55
23 Generating Proof Obligations for loading more proof obligations: re-open Proof Obligation Browser under Tools menu generate EnsuresPost PO for normal behavior of isvalid() generate EnsuresPost PO for exceptional behavior of charge() Formal Specification and Verification: Proof Obligations B. Beckert 18 / 55
24 Generating Proof Obligations for loading more proof obligations: re-open Proof Obligation Browser under Tools menu generate EnsuresPost PO for normal behavior of isvalid() generate EnsuresPost PO for exceptional behavior of charge() generate PreservesOwnInv PO for charge() expressing that charge() preserves all invariants (of its own class) Formal Specification and Verification: Proof Obligations B. Beckert 18 / 55
25 Generating Proof Obligations for loading more proof obligations: re-open Proof Obligation Browser under Tools menu generate EnsuresPost PO for normal behavior of isvalid() generate EnsuresPost PO for exceptional behavior of charge() generate PreservesOwnInv PO for charge() expressing that charge() preserves all invariants (of its own class) follow [KQJ, ] Formal Specification and Verification: Proof Obligations B. Beckert 18 / 55
26 Translating JML to POs in DL in the following: principles of translating JML to proof obligations in DL issues in translating arithmetic expressions translating this identifying the method s implementation translating boolean JML expressions to first-order logic formulas translating preconditions translating class invariants translating postconditions storing \old fields prior to method invocation storing actual parameters prior to method invocation expressing that exceptions are (not) thrown putting everything together Formal Specification and Verification: Proof Obligations B. Beckert 19 / 55
27 Translating JML to POs in DL WARNING: following presentation is incomplete not fully precise simplifying omitting details/complications deviating from exact implementation in KeY Formal Specification and Verification: Proof Obligations B. Beckert 20 / 55
28 Translating JML to POs in DL WARNING: following presentation is incomplete not fully precise simplifying omitting details/complications deviating from exact implementation in KeY aim of the following: enable you to read/understand proof obligations Formal Specification and Verification: Proof Obligations B. Beckert 20 / 55
29 Translating JML to POs in DL WARNING: following presentation is incomplete not fully precise simplifying omitting details/complications deviating from exact implementation in KeY aim of the following: enable you to read/understand proof obligations (notational remark: stick to ASCII syntax of KeY logic in this lecture) Formal Specification and Verification: Proof Obligations B. Beckert 20 / 55
30 Issues on Translating Arithmetic Expressions often: KeY replaces arithmetic Java operators by generalized operators, generic towards various integer semantics (Java, Math), example: + becomes javaaddint KeY inserts casts like (jint), needed for type hierarchy among primitive types, example: 0 becomes (jint)(0) Formal Specification and Verification: Proof Obligations B. Beckert 21 / 55
31 Issues on Translating Arithmetic Expressions often: KeY replaces arithmetic Java operators by generalized operators, generic towards various integer semantics (Java, Math), example: + becomes javaaddint KeY inserts casts like (jint), needed for type hierarchy among primitive types, example: 0 becomes (jint)(0) (no need to memorize this) Formal Specification and Verification: Proof Obligations B. Beckert 21 / 55
32 Translating this both explicit implicit this reference translated to self Formal Specification and Verification: Proof Obligations B. Beckert 23 / 55
33 Translating this both explicit implicit this reference translated to self e.g., given class public class MyClass {... private int f;... } Formal Specification and Verification: Proof Obligations B. Beckert 23 / 55
34 Translating this both explicit implicit this reference translated to self e.g., given class public class MyClass {... private int f;... } f translated to self.f this.f translated to self.f Formal Specification and Verification: Proof Obligations B. Beckert 23 / 55
35 Identifying the Method s Implementation Java s dynamic dispatch selects a method s implementation at runtime Formal Specification and Verification: Proof Obligations B. Beckert 24 / 55
36 Identifying the Method s Implementation Java s dynamic dispatch selects a method s implementation at runtime for a method call m(args), KeY models selection of implementation from package.class by m(args)@package.class Formal Specification and Verification: Proof Obligations B. Beckert 24 / 55
37 Identifying the Method s Implementation Java s dynamic dispatch selects a method s implementation at runtime for a method call m(args), KeY models selection of implementation from package.class by m(args)@package.class example: charge(x)@paycard.paycard executes class paycard.paycard s implementation of method call charge(x) Formal Specification and Verification: Proof Obligations B. Beckert 24 / 55
38 Translating Boolean JML Expressions first-order logic treated fundamentally different in JML and KeY logic JML formulas no separate syntactic category instead: Java s boolean expressions extended with first-order concepts (i.p. quantifiers) KeY logic formulas and expressions completely separate truth constants true, false are formulas, boolean constants TRUE, FALSE are expressions atomic formulas take expressions as arguments; e.g.: x - y < 5 b = TRUE Formal Specification and Verification: Proof Obligations B. Beckert 25 / 55
39 F Translates boolean JML Expressions to Formulas F(v) = v = TRUE F(f) = T (f) = TRUE F(m()) = T (m)() = TRUE F(!b 0) =!F(b 0) F(b 0 && b 1) = F(b 0) & F(b 1) F(b 0 b 1) = F(b 0) F(b 1) F(b 0 ==> b 1) = F(b 0) -> F(b 1) F(b 0 <==> b 1) = F(b 0) <-> F(b 1) F(e 0 == e 1) = E(e 0) = E(e 1) F(e 0!= e 1) =!E(e 0) = E(e 1) F(e 0 >= e 1) = E(e 0) >= E(e 1) v/f/m() boolean variables/fields/pure methods b 0, b 1 boolean JML expressions e 0, e 1 Java expressions T may add self. (see pp.16,17) E may add casts, transform operators (see p.15) Formal Specification and Verification: Proof Obligations B. Beckert 27 / 55
40 F Translates boolean JML Expressions to Formulas F((\forall T x; e 0)) = \forall T x;!x=null -> F(e 0) F((\exists T x; e 0)) = \exists T x;!x=null & F(e 0) F((\forall T x; e 0; e 1)) = \forall T x;!x=null & F(e 0) -> F(e 1) F((\exists T x; e 0; e 1)) = \exists T x;!x=null & F(e 0) & F(e 1) Formal Specification and Verification: Proof Obligations B. Beckert 29 / 55
41 Translating Preconditions if selected contract Contr has requires b_n; they are translated to Formal Specification and Verification: Proof Obligations B. Beckert 31 / 55
42 Translating Preconditions if selected contract Contr has requires b_n; they are translated to PRE(Contr) = F(b_1) &... & F(b_n) Formal Specification and Verification: Proof Obligations B. Beckert 31 / 55
43 Translating Class Invariants the invariant class C {... //@ invariant inv_i;... } is translated to Formal Specification and Verification: Proof Obligations B. Beckert 33 / 55
44 Translating Class Invariants the invariant class C {... //@ invariant inv_i;... } is translated to IN V(inv_i) = \forall C o; ((o.<created> = TRUE &!o = null) -> {self:=o}f(inv_i)) Formal Specification and Verification: Proof Obligations B. Beckert 33 / 55
45 Translating Postconditions if selected contract Contr has ensures b_n; they are translated to Formal Specification and Verification: Proof Obligations B. Beckert 35 / 55
46 Translating Postconditions if selected contract Contr has ensures b_n; they are translated to POST (Contr) = F(b_1) &... & F(b_n) Formal Specification and Verification: Proof Obligations B. Beckert 35 / 55
47 Translating Postconditions if selected contract Contr has ensures b_n; they are translated to POST (Contr) = F(b_1) &... & F(b_n) special treatment of expressions in post-condition: see next slide Formal Specification and Verification: Proof Obligations B. Beckert 35 / 55
48 Translating Expressions in Postconditions below, we assume the following assignable assignable <assignable_fields> ; Formal Specification and Verification: Proof Obligations B. Beckert 37 / 55
49 Translating Expressions in Postconditions below, we assume the following assignable assignable <assignable_fields> ; translating expressions in postconditions (interesting cases only): E(\result) = result E(\old(e)) = E old (e) E old defined like E, with the exception of: E old (e.f) = fatpre(e old (e)) E old (f) = fatpre(self) for f <assignable_fields> Formal Specification and Verification: Proof Obligations B. Beckert 37 / 55
50 Translating Expressions in Postconditions below, we assume the following assignable assignable <assignable_fields> ; translating expressions in postconditions (interesting cases only): E(\result) = result E(\old(e)) = E old (e) E old defined like E, with the exception of: E old (e.f) = fatpre(e old (e)) E old (f) = fatpre(self) for f <assignable_fields> fatpre meant to refer to field f in the pre-state Formal Specification and Verification: Proof Obligations B. Beckert 37 / 55
51 Storing Pre-State of a Field given an assignable field f of class C class C {... private T f;... } translation of postcondition replaced f in \old(..) by fatpre (p.24) left to do: store pre-state values of f in fatpre Formal Specification and Verification: Proof Obligations B. Beckert 39 / 55
52 Storing Pre-State of a Field given an assignable field f of class C class C {... private T f;... } translation of postcondition replaced f in \old(..) by fatpre (p.24) left to do: store pre-state values of f in fatpre ST ORE(f) = Formal Specification and Verification: Proof Obligations B. Beckert 39 / 55
53 Storing Pre-State of a Field given an assignable field f of class C class C {... private T f;... } translation of postcondition replaced f in \old(..) by fatpre (p.24) left to do: store pre-state values of f in fatpre ST ORE(f) = \for C o; fatpre(o) := o.f Formal Specification and Verification: Proof Obligations B. Beckert 39 / 55
54 Storing Pre-State of a Field given an assignable field f of class C class C {... private T f;... } translation of postcondition replaced f in \old(..) by fatpre (p.24) left to do: store pre-state values of f in fatpre ST ORE(f) = \for C o; fatpre(o) := o.f note: not a formula, but Formal Specification and Verification: Proof Obligations B. Beckert 39 / 55
55 Storing Pre-State of a Field given an assignable field f of class C class C {... private T f;... } translation of postcondition replaced f in \old(..) by fatpre (p.24) left to do: store pre-state values of f in fatpre ST ORE(f) = \for C o; fatpre(o) := o.f note: not a formula, but a quantified update Formal Specification and Verification: Proof Obligations B. Beckert 39 / 55
56 Storing Pre-State of All Assignable Fields if selected contract Contr has assignable f_1,..., f_n; then pre-state of all assignable fields can be stored by Formal Specification and Verification: Proof Obligations B. Beckert 41 / 55
57 Storing Pre-State of All Assignable Fields if selected contract Contr has assignable f_1,..., f_n; then pre-state of all assignable fields can be stored by one parallel update: Formal Specification and Verification: Proof Obligations B. Beckert 41 / 55
58 Storing Pre-State of All Assignable Fields if selected contract Contr has assignable f_1,..., f_n; then pre-state of all assignable fields can be stored by one parallel update: ST ORE(Contr) = { ST ORE(f_1)... ST ORE(f_n) } Formal Specification and Verification: Proof Obligations B. Beckert 41 / 55
59 Expressing Normal Termination how can you express in DL: method call m() will not throw an exception Formal Specification and Verification: Proof Obligations B. Beckert 43 / 55
60 Expressing Normal Termination how can you express in DL: method call m() will not throw an exception (if method body from class C in package p is invoked) Formal Specification and Verification: Proof Obligations B. Beckert 43 / 55
61 Expressing Normal Termination how can you express in DL: method call m() will not throw an exception (if method body from class C in package p is invoked) \<{ exc = null; try { m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\> exc = null Formal Specification and Verification: Proof Obligations B. Beckert 43 / 55
62 Expressing Normal Termination how can you express in DL: method call m() will not throw an exception (if method body from class C in package p is invoked) \<{ exc = null; try { m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\> exc = null note difference: Java assignments equation, i.e., formula (in KeY output format) Formal Specification and Verification: Proof Obligations B. Beckert 43 / 55
63 Expressing Exceptional Termination how can you express in DL: method call m() will throw an exception Formal Specification and Verification: Proof Obligations B. Beckert 45 / 55
64 Expressing Exceptional Termination how can you express in DL: method call m() will throw an exception (if method body from class C in package p is invoked) Formal Specification and Verification: Proof Obligations B. Beckert 45 / 55
65 Expressing Exceptional Termination how can you express in DL: method call m() will throw an exception (if method body from class C in package p is invoked) \<{ exc = null; try { m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\>!exc = null Formal Specification and Verification: Proof Obligations B. Beckert 45 / 55
66 Expressing Exceptional Termination how can you express in DL: method call m() will throw an exception (if method body from class C in package p is invoked) \<{ exc = null; try { m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\>!exc = null & <typing of exc> Formal Specification and Verification: Proof Obligations B. Beckert 45 / 55
67 PO for Normal Behavior Contract PO for a normal behavior contract Contr for void method m(), with chosen assumed invariants inv_1,..., inv_n ==> IN V(inv_1) &... & IN V(inv_n) & PRE(Contr) -> ST ORE(Contr) \<{ exc = null; try { m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\> exc = null & POST (Contr) Formal Specification and Verification: Proof Obligations B. Beckert 47 / 55
68 PO for Normal Behavior Allowing Non-Termination PO for a normal behavior contract Contr for method m(), where Contr has clause diverges true; ==> IN V(inv_1) &... & IN V(inv_n) & PRE(Contr) -> ST ORE(Contr) \[{ exc = null; try { m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\] exc = null & POST (Contr) Formal Specification and Verification: Proof Obligations B. Beckert 49 / 55
69 PO for Normal Behavior of Non-Void Method PO for a normal behavior contract Contr for non-void method m(), ==> IN V(inv_1) &... & IN V(inv_n) & PRE(Contr) -> ST ORE(Contr) \<{ exc = null; try { result = m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\> exc = null & POST (Contr) Formal Specification and Verification: Proof Obligations B. Beckert 51 / 55
70 PO for Normal Behavior of Non-Void Method PO for a normal behavior contract Contr for non-void method m(), ==> IN V(inv_1) &... & IN V(inv_n) & PRE(Contr) -> ST ORE(Contr) \<{ exc = null; try { result = m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\> exc = null & POST (Contr) recall: POST (Contr) translated \result to result (p.24) Formal Specification and Verification: Proof Obligations B. Beckert 51 / 55
71 PO for Preserving Invariants assume method m() has contracts Contr 1,..., Contr j PO stating that: Invariants inv_1,..., inv_n are preserved in all cases covered by a contract. ==> IN V(inv_1) &... & IN V(inv_n) & ( PRE(Contr 1 )... PRE(Contr 1 ) ) -> \[{ exc = null; try { m()@p.c; } catch (java.lang.throwable e) { exc = e; } }\] IN V(inv_1) &... & IN V(inv_n) Formal Specification and Verification: Proof Obligations B. Beckert 53 / 55
72 Examples don t fit on slide: execute quicktour with KeY instead Formal Specification and Verification: Proof Obligations B. Beckert 54 / 55
73 Literature for this Lecture Essential KeY Quicktour Formal Specification and Verification: Proof Obligations B. Beckert 55 / 55
Fundamentals of Software Engineering
Fundamentals of Software Engineering Reasoning about Programs - Selected Features Ina Schaefer Institute for Software Systems Engineering TU Braunschweig, Germany Slides by Wolfgang Ahrendt, Richard Bubel,
Verifying Java Programs Verifying Java Programs with KeY
Verifying Java Programs Verifying Java Programs with KeY Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
Formal Systems II: Applications
Formal Systems II: Applications Functional Verification of Java Programs: Java Dynamic Logic Bernhard Beckert Mattias Ulbrich SS 2017 KIT INSTITUT FÜR THEORETISCHE INFORMATIK KIT University of the State
Verifying Java Programs with KeY
Verifying Java Programs with KeY Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at Wolfgang
Formal Specification and Verification
Formal Specification and Verification Formal Specification, Part III Bernhard Beckert Adaptation of slides by Wolfgang Ahrendt Chalmers University, Gothenburg, Sweden Formal Specification and Verification:
Verifying Java Programs Verifying Java Programs with KeY
Verifying Java Programs Verifying Java Programs with KeY Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
The Java Modeling Language JML
The Java Modeling Language JML Néstor Cataño ncatano@puj.edu.co Faculty of Engineering Pontificia Universidad Javeriana The Java Modelling Language JML p.1/47 Lecture Plan 1. An Introduction to JML 2.
Formal Methods for Java
Formal Methods for Java Lecture 1: Introduction Jochen Hoenicke Software Engineering Albert-Ludwigs-University Freiburg October 26, 2011 Jochen Hoenicke (Software Engineering) Formal Methods for Java October
Formale Entwicklung objektorientierter Software
Formale Entwicklung objektorientierter Software Praktikum im Wintersemester 2008/2009 Prof. P. H. Schmitt Christian Engel, Benjamin Weiß Institut für Theoretische Informatik Universität Karlsruhe 5. November
Formal Methods for Java
Formal Methods for Java Lecture 6: Introduction to JML Jochen Hoenicke Software Engineering Albert-Ludwigs-University Freiburg May 15, 2017 Jochen Hoenicke (Software Engineering) Formal Methods for Java
Programming with Contracts. Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany
Programming with Contracts Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany Contract A (formal) agreement between Method M (callee) Callers of M Rights Responsabilities Rights Responsabilities
KeY Quicktour for JML
KeY Quicktour for JML Christian Engel and Andreas Roth 1 Introduction/Prerequisites This document constitutes a tutorial introduction to the KeY-Tool using the JML interface, called JMLKeY in the sequel.
Formal Methods for Software Development
Formal Methods for Software Development Java Modeling Language, Part I Wolfgang Ahrendt 04 October 2018 FMSD: Java Modeling Language /GU 181004 1 / 36 Role of JML in the Course programming/modelling property/specification
Overview The Java Modeling Language (Part 1) Related Work
Overview The Java Modeling Language (Part 1) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
JML tool-supported specification for Java Erik Poll Radboud University Nijmegen
JML tool-supported specification for Java Erik Poll Radboud University Nijmegen Erik Poll - JML p.1/41 Overview The specification language JML Tools for JML, in particular runtime assertion checking using
Advanced JML Erik Poll Radboud University Nijmegen
JML p.1/23 Advanced JML Erik Poll Radboud University Nijmegen JML p.2/23 Core JML Remember the core JML keywords were requires ensures signals invariant non null pure \old, \forall, \result JML p.3/23
Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen
Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2 & JML Tutorial p.1/30
Program Verification (6EC version only)
Program Verification (6EC version only) Erik Poll Digital Security Radboud University Nijmegen Overview Program Verification using Verification Condition Generators JML a formal specification language
Advances in Programming Languages
O T Y H Advances in Programming Languages APL8: ESC/Java2 David Aspinall (including slides by Ian Stark and material adapted from ESC/Java2 tutorial by David Cok, Joe Kiniry and Erik Poll) School of Informatics
JML What are model fields? Translation to JavaDL Demo. JML Model Fields. Christian Engel. ITI, Universität Karlsruhe. 08.
ITI, Universität Karlsruhe 08. Juni 2005 Outline JML 1 JML 2 3 4 JML JML...... is a specification language tailored to Java. JML JML...... is a specification language tailored to Java.... serves as an
Verifying Java Programs. Verifying Java Programs. The Krakatoa/Why Tool Suite
Verifying Java Programs Verifying Java Programs Wolfgang Schreiner Wolfgang.Schreiner@risc.uni-linz.ac.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.uni-linz.ac.at
The Java Modeling Language a Basis for Static and Dynamic Verification
The Java Modeling Language a Basis for Static and Dynamic Verification Wolfgang Ahrendt Chalmers University of Technology, Gothenburg, Sweden School on Runtime Verification Praz sur Arly 19 Mar. 2018 Java
Verifying Java Programs
Verifying Java Programs Wolfgang Schreiner Wolfgang.Schreiner@risc.uni-linz.ac.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.uni-linz.ac.at
Formal Methods for Software Development
Formal Methods for Software Development Java Modeling Language, Part II Wolfgang Ahrendt 29 September 2017 FMSD: Java Modeling Language /GU 171029 1 / 62 JML Modifiers JML extends the JAVA modifiers by
Static program checking and verification
Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer March 2007 June 2007 Slides: Based on KSE06 With kind permission of Peter Müller Static program checking and verification Correctness
Rigorous Software Development CSCI-GA
Rigorous Software Development CSCI-GA 3033-009 Instructor: Thomas Wies Spring 2013 Lecture 6 Disclaimer. These notes are derived from notes originally developed by Jochen Hoenicke. They are copyrighted
Advanced JML. and more tips and pitfalls. David Cok, Joe Kiniry, and Erik Poll
Advanced JML and more tips and pitfalls David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2
From OCL to Typed First-order Logic
22c181: Formal Methods in Software Engineering The University of Iowa Spring 2008 From OCL to Typed First-order Logic Copyright 2007-8 Reiner Hähnle and Cesare Tinelli. Notes originally developed by Reiner
Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen
Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen Erik Poll - JML p.1/39 Overview Assertions Design-by-Contract for Java using JML Contracts and Inheritance Tools for JML Demo
The Java Modeling Language (Part 1)
The Java Modeling Language (Part 1) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
JML. Outline. Métodos Formais em Engenharia de Software. MI, Braga these slides were prepared by adopting/adapting teaching material
Métodos Formais em Engenharia de Software JML José Carlos Bacelar Almeida Departamento de Informática Universidade do Minho MI, Braga 2008 Outline Design by Contract and JML Design by Contract Java Modeling
Verification Condition Generation
Verification Condition Generation Jorge Sousa Pinto Departamento de Informática / Universidade do Minho jsp@di.uminho.pt www.di.uminho.pt/~jsp Outline (1) - From Hoare Logic to VCGen algorithms: an architecture
ESC/Java2 Warnings David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen
ESC/Java2 Warnings David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2 & JML Tutorial p.1/??
TRIAL EXAM C Software Engineering using Formal Methods TDA293 / DIT270
TRIAL EXAM C Software Engineering using Formal Methods TDA293 / DIT270 also serving as additional training material for the course Formal Methods for Software Development, TDA294/DIT271 1 Exam/Tenta SEFM
Assertions, pre/postconditions
Programming as a contract Assertions, pre/postconditions Assertions: Section 4.2 in Savitch (p. 239) Specifying what each method does q Specify it in a comment before method's header Precondition q What
Testing, Debugging, and Verification
Testing, Debugging, and Verification Formal Specification, Part II Srinivas Pinisetty 23 November 2017 Introduction Today: Introduction to Dafny: An imperative language with integrated support for formal
Overview of the KeY System
22c181: Formal Methods in Software Engineering The University of Iowa Spring 2008 Overview of the KeY System Copyright 2007-8 Reiner Hähnle and Cesare Tinelli. Notes originally developed by Reiner Hähnle
Software Engineering using Formal Methods
Software Engineering using Formal Methods Reasoning about Programs with Dynamic Logic Wolfgang Ahrendt & Richard Bubel & Wojciech Mostowski 5 October 2011 SEFM: Java DL /GU 111005 1 / 45 Dynamic Logic
The Java Modeling Language (Part 2)
The Java Modeling Language (Part 2) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
Java Modelling Language (JML) References
Java Modelling Language (JML) References G. T. Leavens and Y. Cheon. Design by Contract with JML, August 2005. L. Burdy, Y. Cheon, D. Cok, M. Ernst, J. Kiniry, G. T. Leavens, K. R. M. Leino, and E. Poll.
Fundamentals of Software Engineering
Fundamentals of Software Engineering Reasoning about Programs with Dynamic Logic - Part I Ina Schaefer Institute for Software Systems Engineering TU Braunschweig, Germany Slides by Wolfgang Ahrendt, Richard
Fundamentals of Software Engineering
Fundamentals of Software Engineering Reasoning about Programs with Dynamic Logic - Part II Ina Schaefer Institute for Software Systems Engineering TU Braunschweig, Germany Slides by Wolfgang Ahrendt, Richard
From OCL to Propositional and First-order Logic: Part I
22c181: Formal Methods in Software Engineering The University of Iowa Spring 2008 From OCL to Propositional and First-order Logic: Part I Copyright 2007-8 Reiner Hähnle and Cesare Tinelli. Notes originally
Fundamentals of Software Engineering
Fundamentals of Software Engineering Reasoning about Programs with Dynamic Logic - Part II Ina Schaefer Institute for Software Systems Engineering TU Braunschweig, Germany Slides by Wolfgang Ahrendt, Richard
Lecture 10 Design by Contract
CS 5959 Writing Solid Code Fall 2015 Nov-23 Lecture 10 Design by Contract Zvonimir Rakamarić University of Utah Design by Contract Also called assume-guarantee reasoning Developers annotate software components
Advances in Programming Languages
T O Y H Advances in Programming Languages APL4: JML The Java Modeling Language David Aspinall (slides originally by Ian Stark) School of Informatics The University of Edinburgh Thursday 21 January 2010
JML Class Specifications The Java Modeling Language (Part 2) A Java Class
JML Class Specifications The Java Modeling Language (Part 2) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria
Operational Semantics. One-Slide Summary. Lecture Outline
Operational Semantics #1 One-Slide Summary Operational semantics are a precise way of specifying how to evaluate a program. A formal semantics tells you what each expression means. Meaning depends on context:
Motivation. Correct and maintainable software Cost effective software production Implicit assumptions easily broken
Spec# Andreas Vida Motivation Correct and maintainable software Cost effective software production Implicit assumptions easily broken Need more formal f specification Integration into a popular language
Formal methods What are they? Uses Tools Application to software development
FormalMethods Page 1 Formal methods introduction 9:26 PM Formal methods What are they? Uses Tools Application to software development FormalMethods Page 2 What are formal methods? 9:49 PM Do you have any
Jive/JML Generating Proof Obligations From JML Specifications
Jive/JML Generating Proof Obligations From JML Specifications Ghislain Fourny gfourny@student.ethz.ch Swiss Federal Institute of Technology Zurich Software Component Technology Group Semester Project March
Testing, Debugging, Program Verification
Testing, Debugging, Program Verification Automated Test Case Generation, Part II Wolfgang Ahrendt & Vladimir Klebanov & Moa Johansson 12 December 2012 TDV: ATCG II /GU 2011-12-12 1 / 17 Recap Specification-/Model-Based
Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Lecture 13. Notation. The rules. Evaluation Rules So Far
Lecture Outline Operational Semantics of Cool Lecture 13 COOL operational semantics Motivation Notation The rules Prof. Aiken CS 143 Lecture 13 1 Prof. Aiken CS 143 Lecture 13 2 Motivation We must specify
A Short Introduction to First-Order Theorem Proving with KeY
1 What is KeY? 1.1 Software Verification Karlsruher Institut für Technologie Institut für Theoretische Informatik Prof. Dr. Peter H. Schmitt Mattias Ulbrich A Short Introduction to First-Order Theorem
Towards a GUI for Program Verification with KeY. Master of Science Thesis in the Programme Software Engineering and Technology
Towards a GUI for Program Verification with KeY Master of Science Thesis in the Programme Software Engineering and Technology Chalmers University of Technology University of Gothenburg Department of Computer
KeY Quicktour. 1 Introduction/Prerequisites Version Information Logical Foundations The KeY-Prover... 2
KeY Quicktour Thomas Baar University of Karlsruhe Dept. of Computer Science D-76128 Karlsruhe baar@ira.uka.de Reiner Hähnle Chalmers University of Technology Dept. of Computing Science S-41296 Gothenburg
Specifying JAVACARD API in OCL
Specifying JAVACARD API in OCL Daniel Larsson 1 Wojciech Mostowski 2 Computing Science Department Chalmers University of Technology Göteborg, Sweden Abstract We discuss the development of an OCL specification
An Annotated Language
Hoare Logic An Annotated Language State and Semantics Expressions are interpreted as functions from states to the corresponding domain of interpretation Operators have the obvious interpretation Free of
Towards Combined Static and Runtime Verification of Distributed Software
Towards Combined Static and Runtime Verification of Distributed Software Wolfgang Ahrendt Chalmers University of Technology, Gothenburg, Sweden Seminar on Distributed Runtime Verification Bertinoro, 18
JML in Feature-Oriented Programming
JML in Feature-Oriented Programming Fabian Benduhn, Supervisor:Thomas Thüm March 23rd, 2012 University of Magdeburg, Germany Java Modeling Language (JML) Specification language for Java Specification as
Verifying Object-Oriented Programs with KeY: A Tutorial
Verifying Object-Oriented Programs with KeY: A Tutorial Wolfgang Ahrendt 1, Bernhard Beckert 2, Reiner Hähnle 1, Philipp Rümmer 1, and Peter H. Schmitt 3 1 Department of Computer Science and Engineering,
ESC/Java2 Use and Features
ESC/Java2 Use and Features The ESC/Java2 tool David Cok, Joe Kiniry, Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2
Typed First-order Logic
22c181: Formal Methods in Software Engineering The University of Iowa Spring 2008 Typed First-order Logic Copyright 2007-8 Reiner Hähnle and Cesare Tinelli. Notes originally developed by Reiner Hähnle
ESC/Java2 Use and Features
ESC/Java2 Use and Features David Cok, Joe Kiniry, Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2 & JML Tutorial
OOP Design by Contract. Carsten Schuermann Kasper Østerbye IT University Copenhagen
OOP Design by Contract Carsten Schuermann Kasper Østerbye IT University Copenhagen 1 Today's schedule Design by Contract why the term contract what design issue is captured, and why bother what is a pre-condition
CS 161 Computer Security
Wagner Spring 2014 CS 161 Computer Security 1/27 Reasoning About Code Often functions make certain assumptions about their arguments, and it is the caller s responsibility to make sure those assumptions
Testing Library Specifications by Verifying Conformance Tests
Testing Library Specifications by Verifying Conformance Tests Joseph R. Kiniry, Daniel M. Zimmerman, Ralph Hyland ITU Copenhagen, UW Tacoma, UCD Dublin 6th International Conference on Tests & Proofs Prague,
Objectives for this class meeting. 1. Conduct review of core concepts concerning contracts and pre/post conditions
CSE1720 Click to edit Master Week text 01, styles Lecture 02 Second level Third level Fourth level Fifth level Winter 2015! Thursday, Jan 8, 2015 1 Objectives for this class meeting 1. Conduct review of
Introduction to Programming Using Java (98-388)
Introduction to Programming Using Java (98-388) Understand Java fundamentals Describe the use of main in a Java application Signature of main, why it is static; how to consume an instance of your own class;
Hoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré
Hoare Logic COMP2600 Formal Methods for Software Engineering Rajeev Goré Australian National University Semester 2, 2016 (Slides courtesy of Ranald Clouston) COMP 2600 Hoare Logic 1 Australian Capital
Model-based Development of Web Services using Design-by-Contract
Model-based Development of Web Services using Design-by-Contract Reiko Heckel University of Leicester, UK Lesster Joint work with M. Lohmann, A. Cherchago, J.H. Hausmann, Paderborn, TU Berlin, 5. 12. 2005
Java: advanced object-oriented features
Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Java: advanced object-oriented features Chair of Software Engineering Carlo A. Furia, Marco Piccioni, Bertrand Meyer Packages
Proof-based Test Case Generation
Chapter 12 Proof-based Test Case Generation Wolfgang Ahrendt, Christoph Gladisch, Mihai Herda 12.1 Introduction Even though the area of formal verification made tremendous progress, other validation techniques
Lectures 20, 21: Axiomatic Semantics
Lectures 20, 21: Axiomatic Semantics Polyvios Pratikakis Computer Science Department, University of Crete Type Systems and Static Analysis Based on slides by George Necula Pratikakis (CSD) Axiomatic Semantics
(Not Quite) Minijava
(Not Quite) Minijava CMCS22620, Spring 2004 April 5, 2004 1 Syntax program mainclass classdecl mainclass class identifier { public static void main ( String [] identifier ) block } classdecl class identifier
Java Modelling Language (JML) References
Java Modelling Language (JML) References www.jmlspecs.org G. T. Leavens and Y. Cheon, Design by Contract with JML, August 2005. C. Marché, C. Paulin-Mohring, and X. Urbain, The Krakatoa Tool for Cerification
Formal Specification and Verification
Formal Specification and Verification Introduction to Promela Bernhard Beckert Based on a lecture by Wolfgang Ahrendt and Reiner Hähnle at Chalmers University, Göteborg Formal Specification and Verification:
Proving well-formedness of interface specifications. Geraldine von Roten
Proving well-formedness of interface specifications Geraldine von Roten Master Project Report Software Component Technology Group Department of Computer Science ETH Zurich http://sct.inf.ethz.ch/ Fall/2007
Semantic Analysis Type Checking
Semantic Analysis Type Checking Maryam Siahbani CMPT 379 * Slides are modified version of Schwarz s compiler course at Stanford 4/8/2016 1 Type Checking Type errors arise when operations are performed
1 Introduction. 3 Syntax
CS 6110 S18 Lecture 19 Typed λ-calculus 1 Introduction Type checking is a lightweight technique for proving simple properties of programs. Unlike theorem-proving techniques based on axiomatic semantics,
Hoare Logic: Proving Programs Correct
Hoare Logic: Proving Programs Correct 17-654/17-765 Analysis of Software Artifacts Jonathan Aldrich Reading: C.A.R. Hoare, An Axiomatic Basis for Computer Programming Some presentation ideas from a lecture
Fortgeschrittene objektorientierte Programmierung (Advanced Object-Oriented Programming)
2014-03-07 Preface Fortgeschrittene objektorientierte Programmierung (Advanced Object-Oriented Programming) Coordinates: Lecturer: Web: Studies: Requirements: No. 185.211, VU, 3 ECTS Franz Puntigam http://www.complang.tuwien.ac.at/franz/foop.html
Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?
Part II. Hoare Logic and Program Verification Part II. Hoare Logic and Program Verification Dilian Gurov Props: Models: Specs: Method: Tool: safety of data manipulation source code logic assertions Hoare
JML. Java Modeling Language
JML Java Modeling Language Overview About the JML Project DBC Design By Contract JML concepts, examples, syntax and capabilities Basics Exceptions Invariants Assertions Quantifiers Other keywords JML hiding
Spark verification features
Spark verification features Paul Jackson School of Informatics University of Edinburgh Formal Verification Spring 2018 Adding specification information to programs Verification concerns checking whether
CS558 Programming Languages
CS558 Programming Languages Fall 2016 Lecture 7a Andrew Tolmach Portland State University 1994-2016 Values and Types We divide the universe of values according to types A type is a set of values and a
EXAMINATIONS 2009 MID-TERM TEST. COMP 202 / SWEN 202 Formal Methods of Computer Science / Formal Foundations of Software Engineering WITH ANSWERS
T E W H A R E W Ā N A N G A O T E Ū P O K O O T E I K A A M Ā U I VUW V I C T O R I A UNIVERSITY OF WELLINGTON Time Allowed: 90 minutes EXAMINATIONS 2009 MID-TERM TEST COMP 202 / SWEN 202 Formal Methods
Program Correctness and Efficiency. Chapter 2
Program Correctness and Efficiency Chapter 2 Chapter Objectives To understand the differences between the three categories of program errors To understand the effect of an uncaught exception and why you
ESC/Java2 vs. JMLForge. Juan Pablo Galeotti, Alessandra Gorla, Andreas Rau Saarland University, Germany
ESC/Java2 vs. JMLForge Juan Pablo Galeotti, Alessandra Gorla, Andreas Rau Saarland University, Germany ESC/Java2: the formula is built using Dijsktra s Weakes precondition. Automatic theorem prover: Simplify
Runtime Checking for Program Verification Systems
Runtime Checking for Program Verification Systems Karen Zee, Viktor Kuncak, and Martin Rinard MIT CSAIL Tuesday, March 13, 2007 Workshop on Runtime Verification 1 Background Jahob program verification
Safety SPL/2010 SPL/20 1
Safety 1 system designing for concurrent execution environments system: collection of objects and their interactions system properties: Safety - nothing bad ever happens Liveness - anything ever happens
Type Hierarchy. Lecture 6: OOP, autumn 2003
Type Hierarchy Lecture 6: OOP, autumn 2003 The idea Many types have common behavior => type families share common behavior organized into a hierarchy Most common on the top - supertypes Most specific at
Pace University. Fundamental Concepts of CS121 1
Pace University Fundamental Concepts of CS121 1 Dr. Lixin Tao http://csis.pace.edu/~lixin Computer Science Department Pace University October 12, 2005 This document complements my tutorial Introduction
Specification tips and pitfalls
Specification tips and pitfalls David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2 & JML
Integrating verification in programming languages
Integrating verification in programming languages Thomas Jensen, INRIA Seminar INRIA Rennes, 04/11/2015 Collège de France Chaire Algorithmes, machines et langages x / y Types For division to make sense,
Property Specifications
Property Specifications Jim Browne Table of Contents Overview Temporal Logics Specification Patterns The major part of this lecture is taken from slides by David Garlan 9/4/2008 Unification of Verification
The JML Tool. Faculty of Engineering Pontificia Universidad Javeriana. The JML Tool p.1/23
The JML Tool Néstor Cataño ncatano@puj.edu.co Faculty of Engineering Pontificia Universidad Javeriana The JML Tool p.1/23 Tools for JML 1. Parsing and type-checking 2. Checking assertions at runtime 3.
CS 6110 S11 Lecture 25 Typed λ-calculus 6 April 2011
CS 6110 S11 Lecture 25 Typed λ-calculus 6 April 2011 1 Introduction Type checking is a lightweight technique for proving simple properties of programs. Unlike theorem-proving techniques based on axiomatic
Proof Carrying Code(PCC)
Discussion p./6 Proof Carrying Code(PCC Languaged based security policy instead of OS-based A mechanism to determine with certainity that it is safe execute a program or not Generic architecture for providing
Translating Java bytecode to BoogiePL
Recap Changes Coq Boogie Conclusion Master project - Final presentation September 29, 2006 Recap Changes Coq Boogie Conclusion Outline Recap What has changed? Formalization of the translation Boogie modifications