Tutorial [] Integrating Object-oriented Design and ... - Semantic Scholar

Tutorial

Integrating Object-oriented Design and Deductive Verification of Software Part I

Bernhard Beckert Reiner Hähnle Vladimir Klebanov Peter H. Schmitt

Introduction

www.key-project.org

Integrated Formal Methods 2007 Oxford, UK July 2nd, 2007 Integrating Object-oriented Design and Deductive Verification of Software:

1 / 115

What is this Tutorial about?

Integrating Object-oriented Design and Deductive Verification of Software:

2 / 115

KeY Project Partners

Design University of Koblenz

Formal specification

Bernhard Beckert

Deductive verification of Object-oriented software

University of Karlsruhe Peter H. Schmitt

www.key-project.org

This tutorial has been developed in the KeY project. The demos will use the KeY tool.

Chalmers University Reiner Hähnle

Integrating Object-oriented Design and Deductive Verification of Software: Topic of the Tutorial

3 / 115


4 / 115

Integrated Formal Methods

Different Approaches Quality and Strength of Verified Properties

Specification UML + Object Constraint Language (OCL)

KeY:

Goal

Java Modeling Language (JML)

Verification Dynamic Logic

Deduktive Verifikation Model Checking

Decision procedures

Static Analysis

And . . . Static analysis Test case generation

Effort


5 / 115

Architecture of the KeY Tool

English

OCL/NL Tool

KeY Plugin OCL/FOL Translation

6 / 115

Choices for the Rule Base

UML/OCL Borland Together CT


JML Eclipse IDE KeY Plugin

Logic Taclets

In this tutorial: 100% Java Card Other rule bases: ODL, a minimal abstract object oriented language A subset of the C language

JML Browser

ASM, Abstract State Machines

[Stanislas Nachen, ETH Z¨ urich]

HyKeY, differential dynamic logic for hybrid systems [André Platzer, Univ. of Oldenburg]

JML/FOL Translation

Synthesis of Proof Obligations Rule Base KeY Prover

Integrating Object-oriented Design and Deductive Verification of Software: The KeY Tool

Rule Base KeY Prover

7 / 115


8 / 115

Java Card What is Java Card? Subset of Java, but with transaction concept Sun’s official standard for Smart Cards and embedded devices

Part II Specification

Why Java Card? Good example for real-world object-oriented language Java Card has no

Application areas

garbage collection

security critical

dynamical class loading

financial risk (e.g. exchanging smart cards is expensive)

multi-threading floating-point arithmetic


9 / 115


10 / 115

Design by Contract Part II Specification

Class Invariant

3

Design by Contract Operation

4

OCL Specification

5

JML Specification

Integrating Object-oriented Design and Deductive Verification of Software: Design by Contract

Precondition Modifies Clauses Postcondition Termination, more precisely: normal or exceptional

11 / 115

Integrating Object-oriented Design and Deductive Verification of Software: Design by Contract

12 / 115

OCL: Object Constraint Language Part II Object Constraint Language Part of the OMG standard UML

Specification

Present Version: 2.0 3

Adds formal constraints to UML (class) diagrams

Design by Contract

Accessible to people without a strong mathematical background 4

5

OCL Specification OCL/FOL Translation

JML Specification

Synthesis of Proof Obligations Rule Base KeY Prover

Integrating Object-oriented Design and Deductive Verification of Software: OCL Specification

13 / 115

Integrating Object-oriented Design and Deductive Verification of Software: OCL Specification

14 / 115

Design by Contract with OCL

Design by Contract with OCL

Class

context ATM

Invariant

inv:

Operation

context ATM::enterPin(pin: Integer) pre: insertedCard null and not customerAuthenticated and not pin = insertedCard.correctPIN and wrongPINCounter < 2 post: wrongPINCounter = wrongPINCounter@pre + 1 and not customerAuthenticated

Precondition

Postcondition

0 0; @ ensures @ (\ forall int x ; x == idx ; @ \ old ( a [0])== a [ x ] && \ old ( a [ x ])== a [0]) && @ (\ forall int i ; 0 a [ i ]==\ old ( a [ i ]))); @ diverges false ; @ */ void swapMax ( int [] a ) { ... }

Integrating Object-oriented Design and Deductive Verification of Software: JML Specification

Another Example

23 / 115

/* @ loop_invariant @ -1 implication

Can use reference implementations instead of first-order theories

equivalence

Symbolic execution is a natural interactive proof paradigm

! negation

Proven technology that scales up

Conditional terms \if(. . .)\then(. . .)\else(. . .)

Quantifiers \forall \exists

Integrating Object-oriented Design and Deductive Verification of Software: Java Card DL

35 / 115


36 / 115

Dynamic Logic Example Formulas

Variables Logical variables disjoint from program variables

(balance > 1 & amount > 1) −> hcharge(amount);i (balance > 1)

hx = 1;i ([while (true) {}] false)

Syntax? ok

No quantification over program variables Programs do not contain logical variables ”Program variables” actually non-rigid functions

\exists int x; ([x = 1;] (x = 1))

Syntax? bad

x cannot be a logical variable, because it occurs in the program

Program formulas can appear nested

x cannot be a program variable, because it is quantified

hint x;i \forall int val; ((hpi x = val) (hqi x = val)) Syntax? ok p, q equivalent relative to computation state restricted to x Integrating Object-oriented Design and Deductive Verification of Software: Java Card DL

37 / 115


Rigid and Flexible Terms

Type System

Example

Static types Partially ordered finite type hierarchy

hint i;i \forall int x; (i + 1 = x −> hi++;i (i = x)) Interpretation of i depends on computation state Interpretation of x and + must not depend on state

38 / 115

Terms are statically typed (like Java expressions) ⇒ flexible

Type casts in logic

⇒ rigid Dynamic types Each term value has a dynamic type

Locations are always flexible Logical variables, standard functions are always rigid

Dynamic type depends on state Dynamic types conform to static types Type predicates in logic


39 / 115


40 / 115

Semantics

Part III Logic and Calculus

Kripke semantics Semantics of a Java program is a partial function from states to states

6

Java Card DL

hpi F true in state s iff p terminates and F holds in the final state s 0 that is reached from s by running p

7

Sequent Calculus

8

Rules for Programs: Symbolic Execution

A Java Card DL formula is valid iff it is true in all states

9

A Calculus for 100% Java Card

10

Taclets and Taclet Language

11

Correctness of Proof Rules

12

Interactive and Automated Proof Construction

We need a calculus for checking validity of formulae


41 / 115

Sequents and their Semantics

Integrating Object-oriented Design and Deductive Verification of Software: Sequent Calculus

42 / 115

Sequent Rules

Syntax

General form ψ1 , . . . , ψm | {z }

==>

Antecedent

φ 1 , . . . , φn | {z }

Premisses

z

Succedent

}|

{

rule name Γ1 ==> ∆1

· · · Γr ==> ∆r Γ ==> ∆ | {z }

where the φi , ψi are formulae (without free variables)

Conclusion

Semantics (r = 0 possible)

Same as the formula (ψ1 & · · · & ψm )

−>

(φ1 | · · · | φn )


Soundness If all premisses are valid, then the conclusion is valid

43 / 115


44 / 115

Some Simple Sequent Rules not left

imp left

Sequent Calculus Proofs

Γ ==> A, ∆ Γ, !A ==> ∆ Proof tree Proof is tree structure with goal sequent as root

Γ ==> A, ∆ Γ, B ==> ∆ Γ, A −> B ==> ∆

Rules are applied from conclusion (old goal) to premisses (new goals) close goal

Γ, A ==> A, ∆

close by true

Γ ==> true, ∆

Rule with no premiss closes proof branch Proof is finished when all goals are closed

all left

Γ, \forall t x; φ, {x/e}φ ==> ∆ Γ, \forall t x; φ ==> ∆

where e var-free term of type t 0 ≺ t Integrating Object-oriented Design and Deductive Verification of Software: Sequent Calculus

45 / 115


46 / 115

Proof by Symbolic Program Execution


Sequent rules for program formulas? What corresponds to top-level connective in a program?

6

Java Card DL

7

Sequent Calculus

8


9


10


11


12

The Active Statement in a Program Example l:{try{ i=0; j=0; } finally{ k=0; }} | {z } | {z } π

active statement non-active prefix rest


Integrating Object-oriented Design and Deductive Verification of Software: Symbolic Execution

47 / 115

ω

i=0; π ω


48 / 115

Proof by Symbolic Program Execution


Sequent rules execute symbolically the first active statement Sequent proof corresponds to symbolic program execution

Example: The rule for if-then-else

(SIMPLIFIED VERSION!)

Γ, B ==> hπ p ωi φ, ∆ Γ, !B ==> hπ q ωi φ, ∆ Γ ==> hπ if (B) { p } else { q } ωi φ, ∆


49 / 115

6

Java Card DL

7

Sequent Calculus

8


9


10


11


12


Integrating Object-oriented Design and Deductive Verification of Software: A Calculus for 100% Java Card

Problems to Address

Other Issues

Object attributes & arrays Modelled as non-rigid functions

Further supported Java Card features

50 / 115

method invocation with polymorphism/dynamic binding arrays

Side effects Expressions in programs can have side effects

abrupt termination throwing of NullPointerExceptions, etc.

Example

object creation and initialisation

if ((y=3) + y < 0) {...} else {...}

bounded integer data types transactions

Aliasing Different names may refer to the same location

All Java Card language features are fully addressed in KeY

Example After o.a=17;, what is u.a? Integrating Object-oriented Design and Deductive Verification of Software: A Calculus for 100% Java Card

51 / 115


52 / 115

Java—A Language of Many Features


Ways to deal Program transformation, up-front


Local program transformation, done by a rule on-the-fly


Modeling with first-order formulas


Special-purpose constructs in program logic


Pro: Feature needs not be handled in calculus Contra: Modified source code Example in KeY: Very rare: treating inner classes


Pro: Flexible, easy to implement, usable Contra: Not expressive enough for all features Example in KeY: Complex expression eval, method inlining, etc., etc.

53 / 115












Pro: No logic extensions required, enough to express most features Contra: Creates difficult first-order POs, unreadable antecedents Example in KeY: Dynamic types and branch predicates


53 / 115

Pro: Arbitrarily expressive extensions possible Contra: Increases complexity of all rules Example in KeY: Method frames, updates

53 / 115


53 / 115

Handling Side Effects

Handling Side Effects Solution Calculus rules realise a stepwise symbolic evaluation (simple transformations)

Problem Expressions may have side effects

Restrict applicability of some rules

Terms in logic have to be side effect free

(e.g., if-then-else)

Example if ((y=3) + y < 0) {...} else {...}

Example

rewritten into (y=3) + y < 0 does not only evaluate to a boolean value, but also assigns a value to y


54 / 115

Handling Assignment: Explicit State Updates

y = 3; int val1 = y ; int val0 = val1 + y ; boolean guard = ( val0 < 0); if ( guard ) {...} else {...} Integrating Object-oriented Design and Deductive Verification of Software: A Calculus for 100% Java Card

55 / 115

Assignment Rule in KeY

Problem Because of aliasing, assignment cannot be handled as syntactic substitution

Γ ==> {loc := val}hπ ωi φ, ∆ Γ ==> hπ loc=val; ωi φ, ∆

Advantages no renaming required

Solution State updates as explicit syntactic elements

delayed proof branching Syntax Update simplification in KeY {loc := val}φ KeY system has powerful mechanism for simplifying and applying updates

where (roughly) loc is a program variable x, an attribute access o.a, or an array access a[i] val is same as val, a literal, or a logical variable Integrating Object-oriented Design and Deductive Verification of Software: A Calculus for 100% Java Card

56 / 115

eager simplification (also: parallel updates) lazy application Integrating Object-oriented Design and Deductive Verification of Software: A Calculus for 100% Java Card

57 / 115

Handling Abrupt Termination

Components of the Calculus

Example: try-throw 1

first-order rules rules for data-types rules for modalities the induction rule

Abrupt termination handled by “simple” program transformations Changing control flow

=

Non-program rules

rearranging program parts 2

Example

Rules for reducing/simplifying the program (symbolic execution) Replace the program by combination of case distinctions (proof branches) and sequences of updates

try-throw (exc simple) *π if (exc instanceof T) + {try {e=exc; r} finally {s}} φ Γ ==> else {s throw exc}; ω Γ ==> hπ try{throw exc; q} catch(T e){r} finally{s}; ωi φ


58 / 115

3

Rules for handling loops rules using loop invariants rules for handling loops by induction

4

Rules for replacing a method invocations by the method’s contract

5

Update simplification Integrating Object-oriented Design and Deductive Verification of Software: A Calculus for 100% Java Card

59 / 115

Taclets


Taclets are the “rules” of the KeY system 6

Java Card DL

7

Sequent Calculus

have logical content like rules of the calculus

8


have pragmatic information for interactive application

9


keep all these concerns separate but close to each other

10


can easily be added to the system

11


12


Taclets. . .

have pragmatic information for automated application

are given in a textual format

Integrating Object-oriented Design and Deductive Verification of Software: Taclets and Taclet Language

can be verified w.r.t. base taclets

60 / 115


61 / 115

Taclet Syntax

An Axiom and a Branching Rule

(by Example)

Modus ponens: Rule

Closure rule close goal { \find (==> b) \assumes (b ==>) \closegoal \heuristics(closure) };

Γ, φ, ψ ==> ∆ Γ, φ, φ −> ψ ==> ∆

Modus ponens: Taclet modus ponens{ \find (phi -> psi ==>) \assumes (phi ==>) \replacewith (psi ==>) \heuristics(simplify) }


Cut rule cut { \add (b ==>); \add (==> b) };

62 / 115

Java Card Taclets


63 / 115

Taclets: Summary

Rule if else split B = TRUE ==> hπ p ωi F B = FALSE ==> hπ q ωi F ==> hπ if (B) p else q ωi F

Taclets are . . . simple and (sufficiently) powerful

where B is a Boolean expression without side effects

compact and clear notation no complicated meta-language easy to apply with a GUI

Corresponding taclet

validation possible

if else split { \find (==> post) \replacewith (==> post) \add (#B = TRUE ==>); \replacewith (==> post) \add (#B = FALSE ==>) \heuristics(if split) }; Integrating Object-oriented Design and Deductive Verification of Software: Taclets and Taclet Language

64 / 115


65 / 115

Verification Calculus Soundness

Part III Logic and Calculus 6

Java Card DL

7

Sequent Calculus

8


9


10


A fundamental problem!

informal language specification

proof rules 11


12


Integrating Object-oriented Design and Deductive Verification of Software: Correctness of Proof Rules

66 / 115

formal semantics


Validating Soundness of Proof Rules

From the Java Language Specification

Bootstrapping Validate a core set of rules, generate and prove verification conditions for additional rules

PostIncrementExpression: PostfixExpression ++

Cross-verification against the Bali calculus for Java formalized in Isabelle/HOL [D. von Oheimb, T. Nipkow]

against the Java semantics in the Maude system [J. Meseguer]

67 / 115

At run time, if evaluation [. . . ] completes abruptly, then the postfix increment expression completes abruptly and no incrementation occurs. Otherwise, the value 1 is added to the value of the variable and the sum is stored back into the variable. Before the addition, binary numeric promotion is performed on the value [. . . ] The value of the postfix increment expression is the value of the variable before the new value is stored.

Tests Using the compiler test suite Jacks Integrating Object-oriented Design and Deductive Verification of Software: Correctness of Proof Rules

68 / 115


69 / 115

Rule for Postfix Increment

From the Jacks Conformance Test Suite

Intuitive rule (not correct!)

class T1241r1a { final int i =1; static final int j =1; static { } }

==> hπ x=y; y=y+1; ωi φ ==> hπ x=y++; ωi φ

class T1241r1b { /* @ public normal_behavior @ ensures \ result == 7; @ */ public static int main () { int s = 0; T1241r1a a = null ; s = s + a.j; try { s = s + a . i ;} catch ( Exception e ) { s = s + 2; a = new T1241r1a (); s = s + a . i + 3; } return s ; } }

But . . . x = 5 ==> hx=x++;i (x = 6)

INVALID

Correct rule

==> hπ v=y; y=y+1; x=v; ωi φ ==> hπ x=y++; ωi φ Integrating Object-oriented Design and Deductive Verification of Software: Correctness of Proof Rules

70 / 115


71 / 115

Interaction and Automation

Part III Logic and Calculus 6

Java Card DL

7

Sequent Calculus

8


9


10


11


12


Integrating Object-oriented Design and Deductive Verification of Software: Proof Construction

For realistic programs: Fully-automated verification impossible

72 / 115


73 / 115

Interaction and Automation

Working with Sequents: Sequent View

Goal in KeY: Integrate automated and interactive proving All easy or obvious proof steps should be automated

For goals (leaves of tree)

Sequents presented to user should be simplified as far as possible Primary steps that require interaction: induction, treatment of loops

Obtaining information about formulas/terms (press Alt key) Selecting formulas/terms, applying rules to them

Taclets enable interactive rule application mostly using mouse

Typical workflow when proving in KeY (and other interactive provers) 1

Prover runs automatically as far as possible

2

When prover stops user investigates situation and gives hints (makes some interactive steps)

3

Go to 1 Integrating Object-oriented Design and Deductive Verification of Software: Proof Construction

For inner nodes Inspecting parts involved in rule application (highlighted)

74 / 115

Extension of Proof: Application of Single Taclets


75 / 115

Applying Taclets using Drag-and-Drop Possible for taclets with find-part and one assumption, like . . . Rewriting a term using an equation

Taclet application requires A proof goal

Instantiating formulas with universal-type quantifier

Focus of rule application: term/formula in the goal Applying equations Drag the equation onto the term to be rewritten

Instantiation of schema variables Main procedure for applying a taclet interactively 1

Select an application focus using mouse pointer

2

Select a particular rule from the context menu

3

Instantiate schema variables


Instantiating quantifiers Drag instantiation term onto the quantified formula

76 / 115


77 / 115

Means of Automation Implemented in KeY

Strategies Currently Present in KeY

Strategies optimized for . . . Parameterized strategies for applying rules automatically Symbolic execution of programs

Free-variable first-order calculus (non-destructive, proof-confluent)

Come in different flavours: with/without unwinding loops, etc. Concentrate on eliminating program and simplifying sequents

Invocation of external theorem provers, decision procedures: Simplify (from ESC/Java) ICS Any other with SMT-LIB interface

Handling first-order logic Implements a complete first-order theorem prover Includes arithmetics solver



78 / 115

79 / 115

Part IV Further Topics Part IV 13

Dealing with Integers

14

Proof Reuse

15

Generating Test Cases

16

Concurrency

Further Topics


80 / 115

Integrating Object-oriented Design and Deductive Verification of Software: Integers

81 / 115

Specification of Integer Square Root

Data Type Gap

Taken from: Preliminary Design of JML [G. Leavens et al.] /* @ requires y >= 0; @ ensures @ \ result * \ result 1 Integrating Object-oriented Design and Deductive Verification of Software: Integers

82 / 115

Examples


83 / 115

More Formal Semantics of Java Integer Types

Valid for Java integers MAX INT + 1 = MIN INT

Range of primitive integer types in Java

MIN INT ∗ (−1) = MIN INT ∃x, y . (x 6= 0 ∧ y 6= 0 ∧ x ∗ y = 0)

Type byte short int long

Not valid for Java integers ∀x.∃y . y > x

Range [−128, 127] [−32768, 32767] [−2147483648, 2147483647] [−263 , 263 − 1]

Bits 8 16 32 64

Not a sound rewrite rule for Java integers x +1>y +1 x >y


84 / 115


85 / 115

Options for Integer Semantics Rules in KeY Part IV Java semantics Faithfully axiomatises the overflow semantics of Java integers

Further Topics

Leads to hard verification problems (lack of intuition)

Arithmetic semantics Leads to easier verification problems

13


14

Proof Reuse

15


16

Concurrency

Incorrect Arithmetic semantics with overflow check Correct Leads to moderate verification problems Incomplete (there are programs that are correct despite overflows) Integrating Object-oriented Design and Deductive Verification of Software: Integers

86 / 115

Proof Reuse

Integrating Object-oriented Design and Deductive Verification of Software: Proof Reuse

87 / 115

Proof Reuse

Basic Use Case 1 Verification attempt fails 2

Amend program

3

Recycle unaffected proof parts

Observations Similar program rule applications focus on similar program parts Program rules applicable at a limited number of goals Proof structure follows program structure

Example: Incremental Verification 1

Program correct w.r.t. arithmetic semantics? ✔

2

Program correct w.r.t. overflow checking semantics? ✘

1

Identify changes in program (program diff)

3

Fix bug, reuse proof ✔

2

Identify subproofs beginning with unaffected statements

3

Similarity-guided proof replay

Steps

Successfully used in case studies


88 / 115


89 / 115

Generating Test Cases Part IV Testing makes sense, even in cases when a formal proof exists Testing can uncover bugs in environment (hardware, compiler, operating system, virtual machine)

Further Topics 13

Testing can uncover specification errors


Testing can uncover bugs w.r.t. unspecified properties (e.g. timing) 14

Proof Reuse

15


16

Concurrency

Tests can be generated from incomplete proofs

Idea: Use a formal proof to generate test cases KeY provides the path condition for each execution path High code coverage (feasible execution paths) For infinite number of paths: Unwind loops finite number of times, inline method bodies

Integrating Object-oriented Design and Deductive Verification of Software: Generating Test Cases

90 / 115

Test Case Ingredients

Integrating Object-oriented Design and Deductive Verification of Software: Generating Test Cases

Example

91 / 115

(Finite Number of Execution Paths)

Compute the middle of three numbers p u b l i c s t a t i c i n t middle ( i n t x , i n t y , i n t z ){ i n t mid = z ; i f ( y value . length ) expandCapacity ( newcount ); value [ count ++] = c ; return this ; }

Integrating Object-oriented Design and Deductive Verification of Software: Concurrency

strb. = 0 ∧ ¬strb = null ∧ strb.count = 0 → ∀n. n > 0 → h{n} strb.append(c);{0} i strb.count

= n∧

∀k. 0 ≤ k < n → strb.value[k] = c(p1 (k + 1))

96 / 115


97 / 115

Three-Step Programme

Statistics

Proof steps: 14622 1

Unfold

Branches: 238 (3 relevant)

2

Prove atomicity invariant

Interactions: 2

3

Symbolic execution + induction

Runtime: ∼1 minute Result: conjecture false for n ≥ MAX INT


98 / 115

Concurrency Verification Problems

99 / 115

Alas. . .

Number of threads ➥ symmetry reduction (this work)

No thread identities in programs

Number of interference points ➥ exploit locking, data confinement

No dynamic thread creation (but unbounded concurrency)

Java Memory Model ➥?



Currently only atomic loops

100 / 115


101 / 115

The Calculus Is Built On. . .


symmetry reduction

symmetry reduction

. . . and explicit scheduler formalization



102 / 115


102 / 115


symmetry reduction

Part V Wrap Up



102 / 115


103 / 115

“Fundamental” Case Studies: Libraries Part V Wrap Up

Java Collections Framework (JCF) Part of JCF (treating sets) specified using UML/OCL

17

Case Studies

18

Current Directions of Work

Parts of reference implementation verified

Java Card API Reference Implementation Covers whole of latest API used in practice (2.2.1)

19

60 classes, 4,500 lines of Java code

Acknowledgments

Effort: 2–3 (expert) months

Integrating Object-oriented Design and Deductive Verification of Software: Case Studies

104 / 115

Algorithm Verification


105 / 115

Security Case Studies: Java Card Software

Demoney Electronic purse application provided by Trusted Logic S.A. Schorr-Waite Algorithm Graph-marking algorithm (memory-efficient garbage collection)

Mondex Card Smart card for electronic financial transactions

Very complicated loop invariant One single proof with 17,000 steps

Issued by NatWest in 1996 Proposed as case study in Grand Challenge KeY used to verify a reference implementation in Java Card


106 / 115


107 / 115

Safety Case Study Part V Wrap Up Avionics Software Java implementation of a Flight Manager module at Thales Avionics Comprehensive specification using JML, emphasis on class invariants

17

Case Studies

18


19

Acknowledgments

Verification of some nested method calls using contracts

Virtual Machine for Real Time Secury Java Verification of some library functions of the Jamaica VM from Aicas


108 / 115

Some Current Directions of Research in KeY

Integrating Object-oriented Design and Deductive Verification of Software: Current Directions of Work


Multi-threaded Java

Multi-threaded Java

Integration of deduction and static analysis


Integration of verification and testing


Counter examples

Counter examples

Symbolic error propagation


Verification of MISRA C


Proof visualization, proving as debugging


Extension of dynamic logic for multi-threading Symbolic execution calculus Prototype available, StringBuffer class verified


109 / 115

Mutual call of analyser/prover, common semantic framework Implementation of static analysis in theorem proving frame

110 / 115


110 / 115



Multi-threaded Java

Multi-threaded Java





Counter examples

Counter examples







Generation of test cases from proofs Symbolic testing New coverage criteria


Generate counter example from failed proof attempt Counter example search as proof of uncorrectness

110 / 115



110 / 115


Multi-threaded Java

Multi-threaded Java





Counter examples

Counter examples







Symbolic error classes modeled by formulas Error injection by instrumentation of Java Card DL rules Symbolic error propagation via symbolic execution


110 / 115


110 / 115



Multi-threaded Java

Multi-threaded Java





Counter examples

Counter examples








110 / 115


110 / 115

Acknowledgments Part V Wrap Up Funding agencies 17

Case Studies

18


Deutsche Forschungsgemeinschaft (DFG) Deutscher Akademischer Auslandsdienst (DAAD) Vetenskapsradet (VR) VINNOVA STINT

19

European Union (within the IST framework)

Acknowledgments

Integrating Object-oriented Design and Deductive Verification of Software: Acknowledgments

111 / 115


112 / 115

Acknowledgments Part V Wrap Up

Students The many students who did a thesis or worked as developers

Alumni W. Menzel (em.), T. Baar (EPFL), A. Darvas (ETH), M. Giese (RICAM), W. Mostowski (U Nijmegen), A. Roth (SAP), S. Schlager

Colleagues who collaborated with us J. Hunt, K. Johanisson, A. Ranta, D. Sands


113 / 115

More Information

The KeY Book B. Beckert, R. Hähnle, P. H. Schmitt (eds.)

Verification of Object-Oriented Software: The KeY Approach Springer-Verlag, LNCS 4334, 2007.

Web site

www.key-project.org Integrating Object-oriented Design and Deductive Verification of Software: More Information

115 / 115

17

Case Studies

18


19

Acknowledgments

Integrating Object-oriented Design and Deductive Verification of Software: More Information

114 / 115

Tutorial [] Integrating Object-oriented Design and ... - Semantic Scholar

Tutorial [] Integrating Object-oriented Design and ... - Semantic Scholar

Suggest Documents

Supporting Concurrent Design by Integrating ... - Semantic Scholar

COMMUNICATING, INTEGRATING AND ... - Semantic Scholar

COMMUNICATING, INTEGRATING AND ... - Semantic Scholar

softdesk energy: a design tool integrating cad and ... - Semantic Scholar

Integrating Design and Formal Verification of Java ... - Semantic Scholar

Integrating IMS Learning Design and IMS Question ... - Semantic Scholar

ScaLAPACK Tutorial - Semantic Scholar

Testing ObjectOriented Software

FastFlow tutorial - Semantic Scholar

A Tutorial on Hybrid PLL Design for ... - Semantic Scholar

A Tutorial on Hybrid PLL Design for ... - Semantic Scholar

Tutorial 1 - Introduction to ASIC Design Methodology - Semantic Scholar

EPIC Tutorial Slides_DK6 - Semantic Scholar

CIKM 2013 tutorial - Semantic Scholar

AIED 2009 Tutorial: Categorisation and ... - Semantic Scholar

ESWEEK 2011 Tutorial - Semantic Scholar

Jgroup Tutorial and Programmer's Manual - Semantic Scholar

SVM Tutorial: Classification, Regression, and ... - Semantic Scholar

A methodology for integrating design for quality in ... - Semantic Scholar

Integrating human factors in the design of ... - Semantic Scholar

An IPC-based Prolog design pattern for integrating ... - Semantic Scholar

integrating eco-design into business environments - Semantic Scholar

Integrating Knowledge Management and Human ... - Semantic Scholar

Integrating Service and Network Management ... - Semantic Scholar