Fundamentals of Software Engineering

Similar documents
Formal Systems II: Applications

Fundamentals of Software Engineering

Formal Specification and Verification

Fundamentals of Software Engineering

Software Engineering using Formal Methods

Fundamentals of Software Engineering

Verifying Java Programs Verifying Java Programs with KeY

Verifying Java Programs with KeY

Verifying Java Programs Verifying Java Programs with KeY

Testing, Debugging, Program Verification

From OCL to Propositional and First-order Logic: Part I

Towards a GUI for Program Verification with KeY. Master of Science Thesis in the Programme Software Engineering and Technology

Formal Specification and Verification

Formal Methods for Java

Programming with Contracts. Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany

Introduction to JavaCard Dynamic Logic

A Short Introduction to First-Order Theorem Proving with KeY

Towards Combined Static and Runtime Verification of Distributed Software

Formal Methods for Software Development

The Java Modeling Language a Basis for Static and Dynamic Verification

Overview The Java Modeling Language (Part 1) Related Work

COMBINING PARTIAL EVALUATION AND SYMBOLIC EXECUTION

Lecture 10 Design by Contract

TRIAL EXAM C Software Engineering using Formal Methods TDA293 / DIT270

Program Verification (6EC version only)

Lecture Notes: Hoare Logic

JML What are model fields? Translation to JavaDL Demo. JML Model Fields. Christian Engel. ITI, Universität Karlsruhe. 08.

Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen

The Java Modeling Language JML

The Java Modeling Language (Part 1)

Formal Methods for Software Development

Handling Integer Arithmetic in the Verification of Java Programs

An Annotated Language

Spark verification features

EXAMINATIONS 2009 MID-TERM TEST. COMP 202 / SWEN 202 Formal Methods of Computer Science / Formal Foundations of Software Engineering WITH ANSWERS

ESC/Java2 Warnings David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen

Advances in Programming Languages

A short manual for the tool Accumulator

JML. Outline. Métodos Formais em Engenharia de Software. MI, Braga these slides were prepared by adopting/adapting teaching material

Static program checking and verification

Software Verification for Java 5

Backward Reasoning: Rule for Assignment. Backward Reasoning: Rule for Sequence. Simple Example. Hoare Logic, continued Reasoning About Loops

Testing, Debugging, and Verification

Programming Languages Third Edition

Verifying Java Programs. Verifying Java Programs. The Krakatoa/Why Tool Suite

Lecture 18 Restoring Invariants

Verifying Java Programs

Verification of Memory Performance Contracts with KeY

Outline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include

Hoare Logic: Proving Programs Correct

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning

KeY Quicktour for JML

Programming Languages and Compilers Qualifying Examination. Answer 4 of 6 questions.1

Logic-Flow Analysis of Higher-Order Programs

Chapter 19 Verification of Counting Sort and Radix Sort

Arguing for program correctness and writing correct programs

Typed First-order Logic

Overview of the KeY System

Violations of the contract are exceptions, and are usually handled by special language constructs. Design by contract

Verification Conditions. Juan Pablo Galeotti, Alessandra Gorla, Andreas Rau Saarland University, Germany

From OCL to Typed First-order Logic

Software Engineering using Formal Methods

Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen

CS 161 Computer Security

Formal Methods for Java

Proof-based Test Case Generation

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning

Go Bears! IE170: Algorithms in Systems Engineering: Lecture 4

Verification Condition Generation

Software Engineering

Chapter 3 (part 3) Describing Syntax and Semantics

ESC/Java2 vs. JMLForge. Juan Pablo Galeotti, Alessandra Gorla, Andreas Rau Saarland University, Germany

6. Hoare Logic and Weakest Preconditions

Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany

Softwaretechnik. Lecture 08: Testing and Debugging Overview. Peter Thiemann SS University of Freiburg, Germany

Formale Entwicklung objektorientierter Software

Outline Introduction The Spec# language Running Spec# Tutorials on Spec# Carl Leonardsson 2/

The Java Modeling Language (Part 2)

Advances in Programming Languages

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

Java Modelling Language (JML) References

Lecture Notes on Contracts

CIS 890: Safety Critical Systems

Program Verification. Program Verification 307/434

School of Informatics, University of Edinburgh

CSE 331 Midterm Exam 2/13/12

Checking Program Properties with ESC/Java

Formal Specification and Verification

JML Class Specifications The Java Modeling Language (Part 2) A Java Class

Midterm I Exam Principles of Imperative Computation Frank Pfenning. February 17, 2011

Cover Page. The handle holds various files of this Leiden University dissertation

Abstract Object Creation in Dynamic Logic

Reasoning about programs

Last time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise

Formal Methods for Java

Reasoning About Loops Using Vampire

CSE 331 Midterm Exam Sample Solution 2/13/12

Review: Hoare Logic Rules

Symbolic Execution and Proof of Properties

Transcription:

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, Reiner Hähnle (Chalmers University of Technology, Gothenburg, Sweden) Ina Schaefer FSE 1

Program Logic Calculus Repetition Calculus realises symbolic interpreter: works on first active statement decomposition of complex statements into simpler ones atomic assignments to updates accumulated updates capture changed program state control flow branching induces proof splitting application of updates on formula computes weakest precondition ψ = {U }φ......... ψ, {U}(isValid. = TRUE) = {U} {ok=true;}... φ ψ, {U}(isValid. = FALSE) = {U}... φ ψ = {t := j j := j + 1 i := j} if (isvalid) {ok=true;}... φ... ψ = {t := j} j=j+1;i=t;if (isvalid) {ok=true;}... φ ψ = t=j;j=j+1;i=t;if (isvalid) {ok=true;}... φ ψ = i=j++;if (isvalid) {ok=true;}... φ Ina Schaefer FSE 2

Are parallel updates sufficient? How to express using updates that a formula φ is evaluated in a state where program variable i has been set to 5? {i := 5}φ program variable i has been increased by 1? {i := i+1}φ program variables i and j swapped values? {i := j j := i}φ all components of an array arr of length 2 have value 0? {arr[0] := 0 arr[1] := 0}φ all components of an array arr of length n have value 0? And how do we then treat programs like int[] a = new int[n];... φ Ina Schaefer FSE 3

Quantified Updates Definition (Quantified Update) For T well-ordered type (no descending chains): quantified update: {\for T x; \ifφ(x); l(x) := r(x)} For all objects d in D T such that β d x = φ perform the updates {l(x) := r(x)} under β d x in parallel If there are several l with conflicting d then choose T -minimal one The conditional expression is optional Typically, x occurs in P, l, and r (but doesn t need to) There is a normal form for updates computed efficiently by KeY Ina Schaefer FSE 4

Quantified Updates Cont d Example (Initialization of field a for all objects in class C) {\for C o; o.a := 0} Example (Initialization of components of array a ) {\for int i; a[i] := 0} Ina Schaefer FSE 5

Quantified Updates Cont d Example (Integer types are well-ordered in KeY) {\for int i; a[0] := i}(a[0]. = 0) Non-standard order for Z (with 0 smallest and preserving < for arguments of same sign) Proven automatically by update simplifier Ina Schaefer FSE 6

Loop Invariants Symbolic execution of loops: unwind unwindloop Γ = U[π if (b) { p; while (b) p} ω]φ, Γ = U[π while (b) p ω]φ, How to handle a loop with... 0 iterations? Unwind 1 10 iterations? Unwind 11 10000 iterations? Unwind 10001 (and don t make any plans for the rest of the day) an unknown number of iterations? We need an invariant rule (or some other form of induction) Ina Schaefer FSE 7

Loop Invariants Cont d Idea behind loop invariants A formula Inv whose validity is preserved by loop guard and body Consequence: if Inv was valid at start of the loop, then it still holds after arbitrarily many loop iterations If the loop terminates at all, then Inv holds afterwards Encode the desired postcondition after loop into Inv Basic Invariant Rule loopinvariant Γ = UInv, Inv, b =. TRUE = [p]inv Inv, b =. FALSE = [π ω]φ Γ = U[π while (b) p ω]φ, (initially valid) (preserved) (use case) Ina Schaefer FSE 8

Loop Invariants Cont d Basic Invariant Rule: Problem loopinvariant Γ = UInv, Inv, b =. TRUE = [p]inv Inv, b =. FALSE = [π ω]φ Γ = U[π while (b) p ω]φ, (initially valid) (preserved) (use case) Context Γ,, U must be omitted in 2nd and 3rd premise: Γ, in general don t hold in state defined by U 2nd premise Inv must be invariant for any state, not only U 3rd premise We don t know the state after the loop exits But: context contains (part of) precondition and class invariants Required context information must be added to loop invariant Inv Ina Schaefer FSE 9

Example Precondition:! a. = null & ClassInv int i = 0; while(i < a.length) { a[i] = 1; i++; } Postcondition: int x; (0 x < a.length > a[x]. = 1) Loop invariant: 0 i & i a.length & int x; (0 x < i > a[x]. = 1) &! a. = null & ClassInv Ina Schaefer FSE 10

Keeping the Context Want to keep part of the context that is unmodified by loop assignable clauses for loops can tell what might be modified @ assignable i, a[*]; How to erase all values of assignable locations in formula Γ? Analogous situation: -Right quantifier rule Replace x with a fresh constant * = x; φ To change value of program location use update, not substitution Anonymising updates V erase information about modified locations V = {i := c \for x; a[x] := f a (x)} (c, f a new constant resp. function symbol) Ina Schaefer FSE 11

Loop Invariants Cont d Improved Invariant Rule Γ = UInv, Γ = UV(Inv & b =. TRUE > [p]inv), Γ = UV(Inv & b =. FALSE > [π ω]φ), Γ = U[π while (b) p ω]φ, (initially valid) (preserved) (use case) Context is kept as far as possible Invariant does not need to include unmodified locations For assignable \everything (the default): V = { := } wipes out all information Equivalent to basic invariant rule Avoid this! Always give a specific assignable clause Ina Schaefer FSE 12

Example with Improved Invariant Rule Precondition:! a. = null & ClassInv int i = 0; while(i < a.length) { a[i] = 1; i++; } Postcondition: int x; (0 x < a.length > a[x]. = 1) Loop invariant: 0 i & i a.length & int x; (0 x < i > a[x]. = 1) Ina Schaefer FSE 13

Example in JML/Java Demo public int[] a; /*@ public normal_behavior @ @ @*/ public void m() { int i = 0; ensures (\forall int x; 0<=x && x<a.length; a[x]==1); diverges true; /*@ loop_invariant @ (0 <= i && i <= a.length && @ (\forall int x; 0<=x && x<i; a[x]==1)); @ assignable i, a[*]; @*/ while(i < a.length) { a[i] = 1; i++; } } Ina Schaefer FSE 14

Example from previous lectures int x; (x. = n x >= 0 [ i = 0; r = 0; while (i<n) { i = i + 1; r = r + i;} r=r+r-n; ]r. = x x) Demo Solution: How can we prove that the above formula is valid (i.e. satisfied in all states)? @ loop_invariant @ i>=0 && 2*r == i*(i + 1) && i <= n; @ assignable i, r; Ina Schaefer FSE 15

Hints Proving assignable The invariant rule assumes that assignable is correct E.g., with assignable \nothing; one can prove nonsense Invariant rule of KeY generates proof obligation that ensures correctness of assignable Setting in the KeY Prover when proving loops Loop treatment: Invariant Quantifier treatment: No Splits with Progs If program contains *, /: Arithmetic treatment: DefOps Is search limit high enough (time out, rule apps.)? When proving partial correctness, add diverges true; Ina Schaefer FSE 16

Total Correctness Find a decreasing integer term v (called variant) Add the following premisses to the invariant rule: v 0 is initially valid v 0 is preserved by the loop body v is strictly decreased by the loop body Proving termination in JML/Java Remove directive diverges true; Add directive decreasing v; to loop invariant KeY creates suitable invariant rule and PO (with... φ) Example (Same loop as above) @ decreasing a.length - i; Ina Schaefer FSE 17

Method Calls Repetition Method Call with actual parameters arg 0,..., arg n {arg 0 := t 0 arg n := t n c := t c } c.m(arg 0,..., arg n ); φ where m declared as void m(t 0 p 0,..., T n p n ) Actions of rule methodcall for each formal parameter p i of m: declare and initialize new local variable T i p#i =arg i ; look up implementation class C of m and split proof if implementation cannot be uniquely determined create method invocation c.m(p#0,..., p#n)@c Ina Schaefer FSE 18

Method Calls Cont. Method Body Expand 1. Execute code that binds actual to formal parameters T i p#i =arg i ; 2. Call rule methodbodyexpand Γ = π method-frame(source=c, this=c){ body } ω φ, Γ = π c.m(p#0,...,p#n)@c; ω φ, Symbolic Execution Only static information available, proof splitting; Runtime infrastructure required in calculus Ina Schaefer FSE 19

Problem Formal specification of Java API and other called methods How to perform symbolic execution when Java API method is called? 1. Method has reference implementation in Java Inline method body and execute symbolically Problems Reference implementation not always available Too expensive Impossible to deal with recursion 2. Use method contract instead of method implementation Ina Schaefer FSE 20

Method Contract Rule Normal Behavior Case Warning: Simplified version JML /*@ public normal_behavior @ requires prenormal; @ ensures normalpost; @ assignable mod; @*/ Γ = UF(preNormal), (precondition) Γ = UV mod (F(normalPost) π p ω φ), Γ = U π result = m(a1,..., an) p ω φ, (normal) JML F( ): translation to Java DL V mod : anonymising update (similar to loops) Ina Schaefer FSE 21

Method Contract Rule Exceptional Behavior Case Warning: Simplified version JML /*@ public exceptional_behavior @ requires preexc; @ signals (Exception exc) excpost; @ assignable mod; @*/ Γ = UF(preExc), (precondition) Γ = UV mod (( (exc =. null) F(excPost)) π throw exc; p ω φ), Γ = U π result = m(a1,..., an) p ω φ, F( ): translation to Java DL V mod : anonymising update (similar to loops) JML (exceptional) Ina Schaefer FSE 22

Method Contract Rule Combined Warning: Simplified version KeY uses actually only one rule for both kinds of cases. Therefore translation of postcondition φ post as follows (simplified): ((exc. = null F(\old(preNormal)) F(normalPost)) (( (exc. = null) F(\old(preExc))) F(excPost)) Γ = U(F(preNormal) F(preExc)), (precondition) Γ = UV modnormal ((exc =. null φ post ) π p ω φ), (normal) Γ = UV modexc (( (exc =. null) φ post ) π throw exc; p ω φ), (exceptional) Γ = U π result = m(a1,..., an) p ω φ, F( ): translation to Java DL V mod : anonymising update (similar to loops) Demo Ina Schaefer FSE 23

Verification with Java API and other called methods How to perform symbolic execution when method is called? 1. Method has reference implementation in Java Call method and execute symbolically Problem Implementation not always available Problem Too expensive Problem How to deal with recursion 2. Use JML contract of method: 2.1 Show that requires clause is satisfied 2.2 Obtain postcondition from ensures clause 2.3 Delete updates with modifiable locations from symbolic state Java Card API in JML or DL DL version available in KeY, JML work in progress See W. Mostowski http://www.cs.ru.nl/~woj/software/software.html Ina Schaefer FSE 24

Understanding Proof Situations Reasons why a proof may not close bug or incomplete specification bug in program maximal number of steps reached: press start/continue again if necessary, increase number of steps automatic proof search fails and manual rule applications necessary Understanding open proof goals follow the taken control-flow from the root to the open goal branch labels may give useful hints identify (part of) the post-condition or invariant that cannot be proven sequent remains always in pre-state. I.e., constraints like i >= 0 refer to the value of i before executing the program (exception: formula is behind update or modality) remember: Γ = o. = null, is equivalent to Γ, (o. = null) = Ina Schaefer FSE 25

Summary Most Java features covered in KeY Several of remaining features available in experimental version Simplified multi-threaded JMM Floats Degree of automation for loop-free programs is high Proving loops requires user to provide invariant Automatic invariant generation sometimes possible Symbolic execution paradigm lets you use KeY w/o understanding details of logic Ina Schaefer FSE 26

Literature for this Lecture Essential KeY Book Verification of Object-Oriented Software (see course web page), Chapter 10: Using KeY KeY Book Verification of Object-Oriented Software (see course web page), Chapter 3: Dynamic Logic, Sections 3.1, 3.2, 3.4, 3.5, 3.6.1, 3.6.2, 3.6.3, 3.6.4, 3.6.5, 3.6.7, 3.7 Ina Schaefer FSE 27