i12pschmitt/FSS/FormSpec.pdf · 4 Introduction to Dynamic Logic 74 4.1 A Motivating Example . . . ....

Formal Specification and Verification

P. H. Schmitt

Winter 2010

Contents

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1 Introduction to Event B 7

1.0.1 Basis Concepts . . . . . . . . . . . . . . . . . . . . . . 8

1.0.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1 Event B Mathematical Language . . . . . . . . . . . . . . . . 11

1.1.1 Set Theory With Urelements . . . . . . . . . . . . . . . 18

1.2 Refinement in Event B . . . . . . . . . . . . . . . . . . . . . . 26

1.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2 Using JML 40

3 Semantics of JML 42

3.1 A First Method Specification Example . . . . . . . . . . . . . 43

3.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3 The Java Black Box . . . . . . . . . . . . . . . . . . . . . . . 52

3.4 Undefinedness . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5 Expressions with Side Effects . . . . . . . . . . . . . . . . . . 58

3.6 Class And Interface Specification . . . . . . . . . . . . . . . . 63

3.7 Invariants And Ownership . . . . . . . . . . . . . . . . . . . . 66

1

4 Introduction to Dynamic Logic 74

4.1 A Motivating Example . . . . . . . . . . . . . . . . . . . . . . 75

4.2 Typed First-Order Logic . . . . . . . . . . . . . . . . . . . . . 81

4.2.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.2.3 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.2.4 Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.2.5 Special Symbols . . . . . . . . . . . . . . . . . . . . . . 91

4.2.6 Partial Functions . . . . . . . . . . . . . . . . . . . . . 92

4.2.7 Conditional Terms . . . . . . . . . . . . . . . . . . . . 95

4.3 Substitutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.4 The Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.4.1 The Vocabulary of Dynamic Logic . . . . . . . . . . . . 99

4.4.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.4.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.5 Formulas and Terms of Dynamic Logic . . . . . . . . . . . . . 101

4.5.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.5.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.5.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.6 Kripke Structures for Dynamic Logic . . . . . . . . . . . . . . 103

4.6.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.6.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.6.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.7 Truth Definition in Kripke Structures . . . . . . . . . . . . . . 106

4.7.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.7.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.7.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.8 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

2

4.8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.9 Sequent Calculus . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.9.1 Sequent Rules . . . . . . . . . . . . . . . . . . . . . . . 108

4.9.2 Proof Trees . . . . . . . . . . . . . . . . . . . . . . . . 110

4.9.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 112

4.10 The Assignment Rule . . . . . . . . . . . . . . . . . . . . . . . 113

4.10.1 The Rule . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.10.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.10.3 Soundness Proof . . . . . . . . . . . . . . . . . . . . . 114

4.10.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.11 A Branching Rule . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.11.1 The Rule . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.11.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.11.3 Soundness Proof . . . . . . . . . . . . . . . . . . . . . 116

4.11.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.12 A While Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

4.12.1 The Rule . . . . . . . . . . . . . . . . . . . . . . . . . 117

4.12.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 117

4.12.3 Soundness Proof . . . . . . . . . . . . . . . . . . . . . 117

4.12.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 118

4.13 Integer Induction Rule . . . . . . . . . . . . . . . . . . . . . . 119

4.13.1 The Rule . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.13.2 Soundness Proof . . . . . . . . . . . . . . . . . . . . . 119

4.13.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.13.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.14 Program Variables . . . . . . . . . . . . . . . . . . . . . . . . 120

4.15 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

3

5 Dynamic Logic for Java(under construction) 125

5.1 Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.1.2 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.2 Parallel Updates . . . . . . . . . . . . . . . . . . . . . . . . . 129

5.3 Assignments with Side Effects . . . . . . . . . . . . . . . . . . 130

5.3.1 The Rules . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.3.2 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 130

6 Solutions to Exercises 132

6.1 Solutions to Chapter 1 . . . . . . . . . . . . . . . . . . . . . . 133

6.2 Solutions to Chapter 4 . . . . . . . . . . . . . . . . . . . . . . 137

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

4

List of Figures

1.1 Actions (Generalizied Substitutions) . . . . . . . . . . . . . . 8

1.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Context for ListSum Maschine . . . . . . . . . . . . . . . . . . 9

1.4 The Abstract-ListSum Maschine . . . . . . . . . . . . . . . . . 10

1.5 The Machine weakInvariant . . . . . . . . . . . . . . . . . . . 34

1.6 The Machine AbsolutListSum . . . . . . . . . . . . . . . . . . 37

1.7 Refinement C-AbsolutListSum of the AbsolutListSum . . . . . 38

3.1 JML contract for midpoint program . . . . . . . . . . . . . . . 45

3.2 A program using the middle() method . . . . . . . . . . . 46

3.3 The AddPos Class . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 The class MyUtil . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.5 The class PairSum . . . . . . . . . . . . . . . . . . . . . . . . 54

3.6 An improved specification for MyUtil . . . . . . . . . . . . . . 57

3.7 A weakly pure method returning a new object . . . . . . . . . 59

3.8 A weakly pure method violating an invariant . . . . . . . . . . 61

3.9 A state violating an invariant . . . . . . . . . . . . . . . . . . 63

3.10 Difference between visible and observable states . . . . . . . . 64

3.11 An array-based list . . . . . . . . . . . . . . . . . . . . . . . . 69

3.12 Class BagWithMax . . . . . . . . . . . . . . . . . . . . . . . 70

3.13 Implementation of the addElems method . . . . . . . . . . . . 71

5

3.14 Example for Universe Type Checking . . . . . . . . . . . . . . 73

4.1 The Program αRM . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2 The Program αRM with annotations . . . . . . . . . . . . . . . 76

4.3 Improved contract for αRM . . . . . . . . . . . . . . . . . . . . 82

4.4 Examples of partial orders . . . . . . . . . . . . . . . . . . . . 83

4.5 Example of a Type Hierarchy . . . . . . . . . . . . . . . . . . 84

4.6 Typed Interpretation . . . . . . . . . . . . . . . . . . . . . . . 87

4.7 Union of Types . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.8 Equality Rules in Typed FOL . . . . . . . . . . . . . . . . . . 90

4.9 Rules for the Type Predicate . . . . . . . . . . . . . . . . . . . 92

4.10 Rules for the Cast Functions . . . . . . . . . . . . . . . . . . . 93

4.11 Rules for the Cast Functions (continued) . . . . . . . . . . . . 94

4.12 The Program Snippet Using Arrays . . . . . . . . . . . . . . . 107

4.13 Example of a closed proof tree . . . . . . . . . . . . . . . . . . 110

4.14 Example of an open proof tree . . . . . . . . . . . . . . . . . . 111

4.15 Proof of ∃x(p(x) → ∀yp(y))) . . . . . . . . . . . . . . . . . . . 112

6

Chapter 1

Introduction to Event B

7

The book [Habrias & Frappier, 2006] treats 18 specification methods amongthem Event B. The first set of slides presented in the lecture covers thismaterial. The following text is not self contained, it assumes some definitionsand background information from these slides and from further sources.

The following figures are included here for easy reference later in these lecturenotes.

1.0.1 Basis Concepts

Generalized Substitution Normalization

x :| P (x, x′) x :| P (x, x′)x := E(x, y) x :| (x′ = E(x, y′))x :∈ A(x, y) x :| (x′ ∈ A(x, y′))x1 := E1(x1, x2, y) ‖x2 := E2(x1, x2, y)

(x1, x2) :|(x′1 = E1(x1, x2, y

′) ∧x′2 = E2(x1, x2, y

′)

)x denotes a vector x1, . . . , xk of state variablesE(x, y) denotes a vector E1(x, y), . . . , Ek(x, y) of expressions.A(x, y) denotes a vector A1(x, y), . . . , Ak(x, y) of set expressions.‖ denotes parallel composition.

Figure 1.1: Actions (Generalizied Substitutions)

Event Before-after predicate

BEGIN x :| P (x, x′) END P (x, x′)WHEN G(x) THEN x :| Q(x, x′) END G(x) ∧Q(x, x′)ANY t WHERE G(t, x) THENx :| R(x, x′, t)

END∃t · (G(t, x) ∧R(x, x′, t))

Figure 1.2: Events

1.0.2 Examples

8

CONTEXT ListSumCtx

SETS

Zbag Bag (=List) of integers

CONSTANTS

sum summation over bags

cons constructor

nil constructor

AXIOMS

def1 : nil ∈ Zbagdef2 : cons ∈ Zbag × Z→ Zbag

def3 : sum ∈ Zbag→ Zsum1 : ∀l, n·(l ∈ Zbag ∧ n ∈ N⇒

sum(cons(l 7→ n)) = n+ sum(l))Definition of summation wrt. constructors

axm3 : sum(nil) = 0Definition of summation wrt. constructors

END

Figure 1.3: Context for ListSum Maschine

9

MACHINE Abstract-ListSum

SEES ListSumCtx

VARIABLES

S the sum of all added values

list internal storage for all current values

INVARIANTS

inv2 : list ∈ Natbag

inv1 : S ∈ Ninv3 : S = sum(list)

S is always the sum of all current values

EVENTS

Initialisation

begin

act2 : list := nil

act1 : S := 0

end

Event ADD =

any

value

where

grd1 : value ∈ Nthen

act1 : list := cons(list 7→ value)

act3 : S := sum(cons(list 7→ value))

end

END

Figure 1.4: The Abstract-ListSum Maschine

10

1.1 Event B Mathematical Language

The syntax of the Event-B mathematical language is unambiguously andprecisely described in [Metayer & Voisin, 2009], a document written in thestyle of a reference manual. In this section we present the material in a moretutorial fashion. We will restrict our presentation to a significant part of theEvent-B Mathematical Language and not strive for complete coverage.

The Event-B Mathematical Language is defined in the manual [Metayer &Voisin, 2009] by attribute grammars, a formalism well suited for an imple-mentation but less accessible to an intuitive understanding and theoreticalinvestigations. Our aim is to translate these definitions faithfully into in-ductive definitions as they are known from the study of formal logics. Itis possible to define the syntax of first-order predicate logic in a few lines(see [Schmitt, 2008, Sect.4.2]). The definition of the Event-B MathematicalLanguage however is much more involved. One reason is the fact that it is atyped language. But, the factor that contributes most to the complexity ofthe the definition is its special feature, that variables may be used in expres-sions and formulas without declaring their type. This nessecitates an analysiswhether for a candidate formula or expression a type assigment to variablescan be found such that all typing rules are satisfied. If such an assignmentdoes not exist or if more than one assignment can be found the candidate for-mula or candidate expression is rejected. Below we will use the terminologygeneralized formula and generalized expression instead of candidate formulaor candidate expression.

Definition 1 (Event-B Formulas (without typing rules)) The set ofgeneralized formulas, GFml, is given by the following inductive definition.

1. > and ⊥ are formulas.

2. If E1, E2 are expressions, then the following are formulasE1 = E2, E1 6= E2

E1 < E2, E1 ≤ E2, E1 > E2, E1 ≥ E2

E1 ∈ E2, E1 6∈ E2, E1 ⊂ E2, E1 ⊆ E2, E1 6⊂ E2,E1 6⊆ E2

3. If F1 and F2 are formulas then alsoF1 ∧ F2, F1 ∨ F2, F1 ⇒ F2, F1 ⇔ F2, and ¬F1.

11

4. If F is a formula and x1, . . . , xn a nonempty list of variables then:∀x1, . . . , xnF and ∃x1, . . . , xnF are formulas.

5. If E and E1, . . . En are expression thenfinite(E) and partition(E1, . . . En)are formulas.

In [Metayer & Voisin, 2009] what we here call a formula is called a predicate.

Definition 2 (Types)

1. Z and BOOL are basic types.

2. If T is a type then also P(T ).Semantics: P(T ) is the set of all subsets of T .

3. If T1, T2 are types then T1 × T2 is also a type.Semantics: T1 × T2 is the set of all ordered pairs (a, b) with a ∈ T1

and b ∈ T2.

4. User provided carrier sets are basic types.Notation: If Person is the identifier for a carrier set thentype(Person) = P(Person).

Every expression E has a unique type, denoted by type(E). Formulas do nothave a type.

In Definition 1 we have skipped the typing constraints imposed on formulas.These are given in the following definition in the form of equations thatwell-typed formulas should satisfy.

Definition 3 (Typing Rules for Formulas) Let E1, E2 be expressions.

1. E1 = E2, E1 6= E2

are well-typed if type(E1) = type(E2)

2. E1 < E2, E1 ≤ E2, E1 > E2, E1 ≥ E2

are well-typed if type(E1) = type(E2) = Z

12

3. E1 ∈ E2, E1 6∈ E2 are well-typed iftype(E2) = P(type(E1))

4. E1 ⊂ E2, E1 ⊆ E2, E1 6⊂ E2,E1 6⊆ E2 are well-typed iftype(E1) = type(E2) = P(T ).for some type T .

The definition of expressions follows the same patterns as the definition offormulas: we first define generalized expressions and then add typing rules.

For a complete definition of all Event-B expressions we refer to [Metayer &Voisin, 2009]. Here we will present a representative selection.

Definition 4 (Event-B Expressions (without typing rules))

1. Variables x are expressions,

2. c is an expression, if c is the name for a carrier set,

3. ∅, Z, N, BOOL are expressions,

4. If E,E1, E2 are expressions so areE1 7→ E2, prj1(E), prj2(E1)

5. If F is a formula and E,E1, . . . , En are expressions then alsoE | F, E1, . . . , Enare expressions,

6. If E,E1, E2 are expressions then so areE1 ∪ E2, E1 ∩ E2, E1 × E2, P(E),

7. If E,E1, E2 are expressions then so areE1 ↔ E2, dom(E), ran(E), E1 → E2,

8. If E,E1, E2 are expressions then so areE1 + E2, E1 ∗ E2, −E.

There is great redundancy in Definition 4.

Lemma 1

13

1. E1, . . . , En = x | x = E1 ∨ . . . ∨ x = En,2. E1 ∪ E2 = x | x ∈ E1 ∨ x ∈ E2,3. E1 ∩ E2 = x | x ∈ E1 ∧ x ∈ E2,4. E1 × E2 = x 7→ y | x ∈ E1 ∧ y ∈ E2,5. P(E) = A | A ⊆ E,6. E1 ↔ E2 = A | ∀x(x ∈ A → ∃x1, x2(x = x1 7→ x2 ∧ x1 ∈ E1 ∧ x2 ∈

E2)),7. dom(E) = x | ∃y((x 7→ y) ∈ E),8. ran(E) = x | ∃y((y 7→ x) ∈ E),9. E1 → E2 = A | A ∈ E1 ↔ E2 ∧ ∀x, y1, y2(x 7→ y1 ∧ x 7→ y2 → y1 =

y2),

Definition 5 (Event-B Expressions (with typing rules))

1. Variables x are expressions,type(x) = α, where α is a new type variable.

2. c is an expression, if c is the name for a carrier set,type(c) = P(c).

3. Z, N, BOOL ∅ are expressions,type(Z) = P(Z), type(N) = P(N), type(BOOL) = BOOL, type(∅) =P(α) for new type variable α for each occurence

4. If E,E1, E2 are expressions so areE1 7→ E2, prj1(E), prj2(E1)type(E1 7→ E2) = type(E1)× type(E2)type(E) = α× β ∧ type(prj1(E)) = α,type(E) = α× β ∧ type(prj2(E)) = β,

5. If F is a formula and E,E1, . . . , En are expressions then alsoE | F, E1, . . . , Enare expressions,type(E | F) = P(type(E))type(E1, . . . , En) = type(E1) ∧ type(E1) = . . . = type(En).

14

6. If E,E1, E2 are expressions then so areE1 ∪ E2, E1 ∩ E2, E1 × E2, P(E),type(E1) = type(E2) = P(α) ∧ type(E1 ∪ E2) = P(α)type(E1) = type(E2) = P(α) ∧ type(E1 ∩ E2) = P(α)type(E1 × E2) = type(E1)× type(E2), type(P(E)) = P(type(E))

7. If E,E1, E2 are expressions then so areE1 ↔ E2, dom(E), ran(E), E1 → E2,type(E1 ↔ E2) = P(type(E1)× type(E2))type(E) = P(α× β) ∧ type(dom(E)) = P(α)type(E) = P(α× β) ∧ type(ran(E)) = P(β)type(E1 → E2) = P(type(E1)× type(E2))

8. If E,E1, E2 are expressions then so areE1 + E2, E1 ∗ E2, −E.type(E1 + E2) = type(E1) = type(E2) = Ztype(E1 ∗ E2) = type(E1) = type(E2) = Z

So far we have dealt with typing equations and their solutions in an intuitivemanner. Hereare precise definitions.

Definition 6 (Type Equations)

Type Expression The set of type expressions is inductively defined by:

1. Type variable α, β etc are type expressions

2. Type constants are type expressions, e.g., Z or constants C forcarrier sets,

3. If T1, T2 are type expressions so are P(T1) and T1 × T2.

Type Equations A type equation is of the form E1 = E2 with Ei typeexpressions.

Solutions of Type Equations Let ES be a set of type equations. Asolution σ of ES is a mapping that assigns all type variables αoccuring in ES a variable free type expression σ(α). such that for all

15

type equations E1 = E2 ∈ ES we obtain the equality σ(E1) = σ(E2).We think of σ as a substitution and σ(E) denotes the application ofsubstitution σ to the expression E. Equality in this context meansequality of strings of symbols.

The above explanations of the solvability of ES may be summarized in math-ematical terms: the formula ∃α∧

ES is true in the free term algebra gen-erated by the constants and the functions P( ) and × . For the readers’convenience we repeat the definition of this algebra here.

Definition 7 (Free Term Algebra) The free term algebra of type expres-sions is the structure Ff with universe Ff = the set of all variable-free typeexpressions and the functions PFf , ×Ff defined for t1, t2 ∈ Ff by

PFf (t1) = P(t1)t1 ×Ff t2 = t1 × t2

Definition 8 (Triangular Set of Type Equations) A set ES of typeequations is called triangular if it is of the form

X1 = T1

X2 = T2...

...Xn = Tn

such that

1. all Xi are different type variables

2. Xi only occurs in terms Tj with j < i.

Note, that requirement (2) entails that Xi does not occur in Ti and Tn con-tains none of the variables X1 . . .Xn.

Lemma 2 For any set ES of type equations either ES is not solvable orthere is a triangular set of type equations ES1 with the same solutions.

16

Proof See Exercise 1.3.4.

Lemma 3

1. Any triangular set of type equations is solvable

2. If a triangular set ES of type equations contains no other type variablesthan X1 . . .Xn (in the notation of Definition 8) then there is one uniquesolution.

Proof: Replace all type variables other than X1 . . .Xn by an arbitrary typeexpressions without variables. Then the last equation fixes the solution forXn. Now substitute the solution for Xn in all other equations. Then Tn−1

does not contain any type variable and thus fixes the solution for Xn−1. Con-tinuing in this way we obtain a solution for all of ES. From this explanationit is also obvious that there is exactly one solution in case X1 . . .Xn are alltype variables occuring in ES.

Definition 9 (Event-B Expressions and Formulas)

1. A generalized Event-B expression is an Event-B expression if the set oftyping equations resulting from Definitions 5 has a unique solution.

2. A generalized Event-B formula is an Event-B formula if the set of typ-ing equations resulting from Definitions 5 and 3 has a unique solution.

If we want to emphasize the difference between generalized expressions andformula to expressions and formulas defined by this definition we sometimesspeak of typeable expressions or formulas.

Example 4 We look at the sets of equations that result from applying thetyping rules in Definitions 5 and 3. to a few examples.

1. ∀x(x = x)The type of the variable x will denoted by a type variables α. By (1)in Definition 3 we arrive at α = α. Since this (singleton) set ofequations allows more than one solution ∀x(x = x) is not a Event-Bformula.

17

2. x ∈ xBy (3) in Definition 3 we arrive at α = P(α), where the type variableα stands for the type of x. This equation is not satisfiable and thusx ∈ x not an Event-B formula.

3. x ≤ y ∧ x ∈ yIf α, β, γ are the type variables for the types of x, y, z we get from By(2) and (3) in Definition 3 the set of typing equations α = Z, β =Z, γ = p(α). This set has a unique solution. Thus x ≤ y ∧ x ∈ y is anEvent-B formula.

4. ∅ ⊆ Z ∧ ∅ ⊆ P(Z)This formula leads to the typing equations α1 = P(Z), α2 = P(P(Z))which has a unique solution. This is a bit strange and arises from thefact that the Event-B type system does not include a NULL type northe notion of subtype.One should also bear in mind, that as a consequence of this feature itis not true that every expression E has a unique type. Rather type(E)may depend on the occurence of E.

5. x > 0 ∧ y ⊆ z ∧ x ∈ zleads to the set of type equations α = Z, β = γ, y = P(α) that can beuniquely satisfied by the substiution α 7→ Z, β 7→ P(Z), γ 7→ P(Z.

1.1.1 Set Theory With Urelements

The Event-B mathematical language is based on set theory, more preciselyon a version of Zermelo-Fraenkel set theory with urelements. We will firstdescribe this theory and investigate later how the Event-B mathematicallanguage relates to it.

The presentation of set theory with urelements, STU for short, in this sectionis based on [Suppes, 1960]. The axioms of STU will be written in two-sortedfirst-order predicate logic. There will be one sort Gen called the sort ofgeneral elements, and a subsort Set v Gen of sets. To avoid clumsy notationslike Gen : u and Set : ss we will agree to denote variables of the general sortby lower case letters from the end of the alphabet and variables of sort Set byupper case letters from the beginning of the alphabet. The elements that are

18

not elements of types Set are called urelements. This terminology becamepopular later, Suppes used the term individuals in his book.

The axioms of STU will only use the following two symbols

= Gen×Gen∈ Gen× Set

Definition 10 (STU) The axioms of set theory with urelements are

A1 Extensionality ∀x(x ∈ A↔ x ∈ B) → A = BA2 Separation ∃B(∀x(x ∈ B ↔ x ∈ A ∧ φ)A3 Pairing ∃A(∀z(z ∈ A↔ z = x ∨ z = y))A4 Sum ∃C(∀x(x ∈ C ↔ ∃B(B ∈ A ∧ x ∈ B)))A5 Power Set ∃B(∀C(C ∈ B ↔ C ⊆ A))A6 Regularity ∃x(x ∈ A) → ∃x(x ∈ A ∧ ∀y(y ∈ x→ ¬y ∈ A))A7 Infinity ∃A(∅ ∈ A ∧ ∀B(B ∈ A→ B ∪ B ∈ A))

As usual the free variables in the above axioms are implicitly universallyquantified. We omitted the replacement axiom and the axiom of choice sincewe will have no opportunity to make use of them. We chose to stick to thenames of the axioms used in [Suppes, 1960] which follow standard conventionwith the exception of A2 which is more often called the subset axiom. ForA6 also the name foundation axiom is in use.

Note, that A2 differs from the other axioms in that it is an axiom scheme.Thus, A2 stands for infinitely many axioms, one for each choice of the formulaφ.

Also note, that axioms A5,A7 are not formulated in the original vocabulary.They make use of the new defined symbols

symbol definition⊆ ∀A∀B(A ⊆ B ↔ ∀x(x ∈ A→ x ∈ B))∅ A = ∅ ↔ ∀x(¬x ∈ A)y A = y ↔ ∀x(x ∈ A↔ x = y)∪ ∀x(x ∈ A ∪B ↔ x ∈ A ∨ x ∈ B)

We slightly deviate from the language used in [Suppes, 1960]. Suppes useda unary predicate isSet and the typographical convention that ∀Aφ standsfor ∀u(isSet(u) → φ) and ∃Aφ stands for ∃u(isSet(u) ∧ φ), In our setting

19

this is not just a typographical convention but a multisorted language. Thepredicate isSet is now dispensible since it can be defined by isSet(u) ↔∃A(A = u). In Suppes notation the symbol for the emtpy set is a primitivesymbol and cannot be introduced by a definition. In contrast this is possiblein our two-sorted language, see Lemma 5 below.

Note on notation For a formula φ with one free variable x we write for anelement a in the universe of M in short M |= φ[a] instead of (M, β) |= φ forthe variable assignment β with β(x) = a. For formulas ψ with more than onefree variable we write correspondingly M |= φ[a1, . . . , ak] where we assumethat the correspondace which position in the list [a1, . . . , ak] is assigned towhich variable is clear from the context.

If M is a model for the theory STU the universe M of M is partitioned intotwo subuniverses Mset = a ∈ M | M |= ∃A(x = A)[a] and Mur = a ∈M | M |= ¬∃A(x = A)[a]. On the other hand the collection a ∈ M |∃y(x = y)[a] equals M .

Other accounts on axiomatic set theory , e.g., [Takeuti & Zaring, 1971] con-tain an empty set axiom ∃B(∀x(¬x ∈ B)).

Lemma 5 (Empty Set) The following is derivable from the axioms in Def-inition 10

∃B(∀x(¬x ∈ B))

Proof This derivation makes use of the fact, that the semantics of two-sorted first-order logic assumes that in every model M there is at least oneelement of each sort. This entails that every models contains at least oneelement X ∈ M fo sort Set. We can now use the subset axiom A2 with theformula φ ≡ x 6= x to derive the existence of the empty set.

Lemma 6 (Union) The following is derivable from the axioms in Definition10

∀X∀Y ∃Z(∀x(x ∈ Z ↔ x ∈ X ∨ x ∈ Y ))

The set Z will be called the union of X and Y and denoted by Z = X ∪ Y .

20

Proof Axiom A3 guarantees the existence of the set C = X, Y . AxiomA4 yields the existence of a set Z such that ∀x(x ∈ Z ↔ ∃B(B ∈ C∧x ∈ B)).Since C = X, Y this is equivalent to ∀x(x ∈ Z ↔ (x ∈ B ∨ x ∈ Y )), asdesired.

Lemma 7 (Ordered Pair) The following is derivable in STU

∀x∀y∀x′∀y′(x, x, y = x′, x′, y′ ↔ x = x′ ∧ y = y′)

Proof Easy computation.

Because of Lemma 7 the set x, x, y is called the ordered pair of x andy denoted by 〈x, y〉.

Lemma 8 (Direct Product) The formula

∀X∀Y ∃Z(∀z ∈ Z ↔ ∃x ∈ X∃y ∈ Y (z = 〈x, y〉))is a theorem of STU.The set Z will be called the direct product of X and Y and denoted by Z =X × Y .

Proof Sketch By Lemma 6 the union X ∪ Y exists. Two applicationsof A5 yields a set P , the powerset of the powerset of X ∪ Y , such that∀x ∈ X∀y ∈ Y (〈x, y〉 ∈ P ). By A2 we get the existence of a set Z suchthat ∀z(z ∈ Z ↔ z ∈ P ∧ φ(z)) with φ(z) = ∃y ∈ Y (z = 〈x, y〉). By theproperties of set P this is equivalent to ∀z(z ∈ Z ↔ z ∈ φ(z)). as desired.

Lemma 9 () The following formula are derivable from STU

1. ∀X∀Y (P(X) = P(Y ) ↔ X = Y )

2. ∀X1∀X2∀Y1∀Y2(X1 6= ∅ ∧X2 6= ∅ ∧ Y1 6= ∅ ∧ Y2 6= ∅ →(X1 ×X2 = Y1 × Y2 ↔ X1 = Y1 ∧X2 = Y2)

3. ∀X∀Y1∀Y2(P(X) 6= Y1 × Y2)

21

Proofs(1) Assume P(A) = P(B). Since A ∈ P(A) we must also have A ∈ P(B)which is by definition of the powerset A ⊆ B. A symmetric argument yieldsB ⊆ A, thus A = B.(2) Let A1, A2, B1, B2 non-empty sets with A1 × A2 = B1 × B2. Pickan element c ∈ A2. For an arbitrary a ∈ A1 we have 〈a, c〉inA1 × A2.By assumption this implies 〈a, c〉inB1 × B2. By the definition of the directproduct there are bi ∈ Bi with 〈a, c〉 = 〈b1, b2〉. By the properties of orderedpairs, see Lemma 7, this yields a = b1 and c = b2. In total we have shownso far A1 ⊆ B1. A symmetric argument yields B1 ⊆ A1, thus A1 = B1. Theequation A2 = B2 is obtained along the same lines.Note, that the non-emptiness requirements are necessary. Since A × ∅ = ∅,we get A× ∅ = B × ∅ for arbitrary sets A,B.(3) In any case we have ∅ ∈ P(A) for an arbitrary set A (even for A = ∅).An equality P(A) = B1×B2 would yields ∅ ∈ B1×B2. But, an ordered pair〈b, c〉 never is the empty set.

In Definition 7 we have presented the free term algebra as a structure forthe interpretation of type expressions. We can now present more concreteinterpretations of types expressions, that we call the set algebras of typeexpressions.

Definition 11 Let M = (M,∈M) be a model of STU. A set algebra for typeexpressions is a structure Fs with universe Fs = M and the functions PFs,×Fs defined for sets A1, A2 ∈M by

PFs(A1) = X | X ⊆ A1A1 ×Fs A2 = A1 × A2

The constant symbols c ∈ C that we allow to occur in type expressions standfor carrier sets or the built in types of the EventB language. We assume that⋃

c∈C cFs = Mur and the cFs are mutually disjoint which implies in particular

cFs 6= ∅.

For the proof of the next lemma we have to make use of quite advancedconcepts of set theory: the theory of ordinal numbers and the rank of a set.

Definition 12 The rank function for sets is defined by

22

1. r(∅) = 0

2. r(e) = 0 for any urelement e.Formally ∀a(¬∃A(a = A) → r(a) = 0).

3. r(A) = supr(b) + 1 | b ∈ A

Lemma 10 Let Fs = (M,PFs ,×Fs , cFs | c ∈ C) be a set algebra for typeexpressions and F be a type expression such that the variables α = α1, . . . αn

occur in F and F itself is not a type variable. Let β : α1, . . . αn → M bean assigment of elements from the universe of Fs to the variables, such thatβ(αi) 6= ∅ for all i. Then

(Fs, β) |= αi 6= F

Proof We abbreviate β(αj) by bj. We will prove bi 6= F (Fs,β) by showingthat under the assumptions of the lemma r(F (Fs,β)) > r(bi).

The simplest cases are F ≡ P(αi) and F ≡ αi × t, since F is not allowed tobe a variable and should contain αi . The only requirement on term t is thatt(Fs,β) 6= ∅ and we ignore the symmetric case F ≡ t× αi.r(P(ci)) = supr(b) + 1 | b ∈ P(ci). Since ci ∈ P(ci) we obtain r(P(ci)) >r(ci).

r(ci × t(Fs,β)) = supr(〈x, y〉) + 1 | x ∈ b1, y ∈ t(Fs,β)= supmax(r(x), r(y)) + 2 | x ∈ b1, y ∈ t(Fs,β)≥ supr(x) + 1 | x ∈ b1= r(bi)

If we know already r(t(Fs,β)) > r(bi) then also r(P(t(Fs,β))) > r(t(Fs,β)) >r(bi). At last we consider F = t1 × t2 and assume without loss of generality

that αi occurs in t1. Furthermore we assume t(Fs,β)i 6= ∅. By induction

hypothesis we thus know r(t(Fs,β)1 > r(bi) We get (t1 × t2)

(Fs,β) 6= ∅ and

r(t(Fs,β)1 × t

(Fs,β)2 ) = supr(〈x, y〉) + 1 | x ∈ t(Fs,β)

1 , y ∈ t(Fs,β)2

= supmax(r(x), r(y)) + 2 | x ∈ t(Fs,β)1 , y ∈ t(Fs,β)

2 ≥ supr(x) + 1 | x ∈ t(Fs,β)

1 = r(t

(Fs,β)1 )

23

Theorem 11 Let C be a set of constants, Fs = (M,PFs ,×Fs , cFs | c ∈ C)be a set algebra for type expressions, such that for no c ∈ C there exists avariable-free type expression Ec with constants only from C \ c such thatFs |= c = Ec, and let F,G be arbitrary type expression.If there is a solution β of the equation F = G in Fs with β(α) 6= ∅ for alltype variables αthen F = G is also solvable in the free term algebra Ff .

Proof With lemmas 9 and 10 the claim of the lemma is reduced to thefollowing special case:

Let E be a set of type equation such that

1. The righthand sides of all equations are constant or variable symbols,

2. If c = E occurs in ES then c does not occur in E,

3. If α = E occurs in ES then α does not occur in E.

If ES is solvable in Fs then it is also solvable in Ff (1.1)

If an equation between two type variables αi = αj occurs in ES replaceαi by αj everywhere and keep in mind that in the solution β we shouldhave β(αi) = β(αj). Using the same arguments as in the proof of Lemma 2(Exercise 1.3.4) we may assume that ES is in triangular normal form. Forany variable α that occurs only on the righthand side of equations we maychoose an arbitrary value, we choose β(α) = cFs for some constant c ∈ C.The rest of a solution β is then uniquely determined. We observe that weget this way β(α) = EFs

α for some variable-free type expressions Eα. Againappealing to lemmas 9 and 10 we see that β is also a solution to the systemES in the free algebra Ff .

Lemma 12 Let E be an EventB expression, ES the typing equationsassociated with E and γ a solution of ES in the free algebra Ff . At thispoint we do not assume that γ is the only solution, but γ(e) for E and itssubexpressions does not contain type variables.

24

Let furthermore M = (M,∈) be a model of STU, β an assignment of thevariables V in E to elements in M , i.e., β : V → M . The types γ(e) areagain EventB expressions and ay such may be evaluated in M. We assumefurthermore for all v ∈ V that β(v) ∈ γ(v)M.Then

E(M,β) ∈ γ(E)M

Proof The proof, obviously, proceeds by induction on the complexity ofthe expression E.E a variable: The claim in this case reads β(v) ∈ γ(v)M, which is one ofthe assumptions.E = E1 7→ E2 : E(M,β) = 〈E(M,β)

1 , E(M,β)2 〉.

Let Ti = γ(Ei)M. The typing equations require γ(E) = T1 × T2. The claim

can thus be reduced to the statement

〈E(M,β)1 , E

(M,β)2 〉 ∈ γ(E1)

M × γ(E2)M

which follows from the hypothesis E(M,β)i ∈ γ(Ei)

M.E = E1 ↔ E2 :

E(M,β) = R | ∀x(x ∈ R→ ∃x1∃x2(x = 〈x1, x2〉))and

γ(E) = P(γ(E1)× γ(E2))

25

1.2 Refinement in Event B

Many concepts of refinement have been considered and studied in computerscience. We will describe here the basic ideas of refinement as it is used withinEvent B. The following definition abstracts away from most of the details ofthe Event-B system to keep the presentation simple and allow to concentrateon the essential points. More details can be filled in from [Hallerstede, 2008][Abrial & Hallerstede, 2007] and [Metayer & Voisin, 2009].

Definition 13 An Event-B machine M is given by the following compo-nents

1. Context C declaring carrier sets, constants and predefined sets as e.g.,Z. Furthermore a conjunction A of axioms is asserted in C.

2. A finite vector of variables v = (v1, . . . , vk)

3. A conjunction of invariants I(v)

4. A finite set of events E, containing a designated initialising event e0.For simplicity we will assume that there is only one initialising eventin E.

5. Every event e ∈ E consists of a formula ge(v), called the guard of eand an action part.For the initialising event we have ge0(v) = >.The effect of the action part is described by a formula Be(v, v

′), calledthe before-after-predicate. For the initialising event Be0 must not de-pend on the variables v.

Example 13 Some States of the ListSum Machine, see Figures 1.4 and 1.3

26

s0 list = nilS = 0

s1 list = cons(nil,5)S = 5

s2 list = cons(cons(nil,5),2)S = 7

s3 list = cons(nil,3)S = 3

s4 list = cons(cons(cons(nil,5),2)5)S = 12

Some Traces: s0, s1, s2, s4 and s0, s3

State s2 satisfies the invariant, S = sum(list), if the formula

7 = sum(cons(cons(nil, 5), 2))

can be derived from the axioms. We will denote this statement by

A ` (S = sum(list))(s2),

where A is shorthand for AXIOMS.

For technical reasons we assume that there is an event skip ∈ E with gskip => and Bskip ≡ v = v′.

For the purposes of this section we need not look into the details, how thebefore-after-predicate is constructed. All we will make use of is the fact thatthe before-after predicate Be(v, v

′) of an action e is defined in such a waythat A ` Be(v, v

′) ⇒ ge(v) is true, see Figure 1.2.

When we write a formula F in the form F (v) we want to convey the informa-tion that formula F contains at most the variables in the vector v. In someEvent-B documents or slides also the occurence of constants in a formulais made explicit in the same way. We will not do this here. In the abovedefinition v′ is a vector of new variables.

We need some terminology and explanations before we can go on. At anymoment during the execution of an Event-B machine M its variables v holdspecific values. A function that associates values with variables in v is calledan assignment. We require that an assignment s respects the typing con-straints on the variables. An assignment is also called a state.

27

It is a recurring task to establish that some formula F (v) containing at mostthe free variables v is true in a given state s. To solve this task we first replacethe variables v in F (v) by their values as given by s and then determinewether the resulting formula F (v/s) can be derived from the axioms A givenin the context C. This works if the values s(v) are all given by variable-freeexpressions built up from constants and operations declared in the contextC or built-in. Otherwise F (v/s) will not be a legal formula since it containselements from the semantic domain that do not belong to the syntax. Allcases occuring in the examples are of the special former kind and we will notrun into troubles. But, it has to be admitted that using F (v/s) in general ischeating. The alternative would be to introduce the concept of a structureA for first-order logic and a variable assignment s and inductively definewhen a formula F is true in A under variable assigment s, usuable writtenas (A, s) |= F . We asssume that the reader is familiar with the lecture notes[Schmitt, 2008] and can fill in these details. These additional details do notshow up in the application of the Event-B method. They would be relevantwhen discussing the correctness of the proof rules, in particular the proofrules dealing with quantifiers, employed by Event-B provers. But, this is notour concern.

We will write F (s) instead of F (v/s) and F (s, s′) for F (v/s, v′/s′) hopingthat no confusion will arise.

Event-B adopts an axiomatic approach. So, if we want to determine if aformula F stating some property of Z is true, we do not argue about theelements and relations of Z. Instead we trust that the prover knows enoughaxioms of Z such that F can be derived from these axioms. In these lecturenotes we assume that all axioms used by the prover are in A.

We will write A ` F (s) if F (s) can be derived from A and A 6` F (s) otherwise

Definition 14 Let M be an Event-B machine.

1. The set of states S (or if need be SM) of M is the set of all valuationsof the variables v.

2. A sequence of states s0, . . . sn, . . . is called a trace for M if there isa matching sequence e0, e1, . . . en, . . . of events with e0 the initialisingevent, such that

28

(a) For every i, 0 < i A ` gei(si−1)

(b) For every i, 0 < i A ` Bei(si−1, si)

(c) A ` Be0(s0)

Note, that the initialising event can only occur once.In other context a trace may also go by the name of a run or compu-tation sequence.Traces may be finite or infinite.

3. A state s ∈ S is called reachable if there is a finite trace s0, . . . sn endingin s i.e., sn = s.

4. A state s is called a deadlock if for all e ∈ E \ e0, skip we get A 6`ge(s).

Definition 15 We say that an Event-B machine M satisfies its invariantsif for every reachable state s

A ` I(s)is true.

Lemma 14 If we can verify for a given Event-B machine M the proof obli-gations

INIT A ` Be0(v) ⇒ I(v)

INV For all e ∈ E \ e0, skip A ` I(v) ∧Be(v, v′) ⇒ I(v′)

then M satisfies its invariants.

Proof This can easily be proved by induction on the number of eventsnecessary to reach a state.

To understand the content of Lemma 14 let us look at the example in Figure1.5. We can easily convince ourselves that the invariant of the machineweakInvariant is true, but a proof of the second item in Lemma 14 fails.This second proof obligation says: in any state s where the invariant holds

29

and an action e can be performed, after execution of e the invariant is againtrue. The state s may be unreachable from an initial state. Adding therequirement that s is assumed to be reachable would completely change thegame. The size of the state space would become an important parameter andthe state space explosion, that is known from model checking would arise.The remedy for the example in Figure 1.5 is a strengthening of the invariantby adding x ≥ y.

It is worth remarking that Lemma 14 does not depend on the events beingfeasible in the sense of the following definition.

Definition 16 An event e ∈ E is called feasible if

A ` I(v) ∧ ge(v) ⇒ ∃v′Be(v, v′)

is provable.

This is not exactly the definition commonly found in the Event-B literaturebut it is equivalent.

If an event e is not feasible there can still be some states s such thatI(s) ∧ ge(s) and ∃v′Be(s, v

′) are provable. Thus an infeasable event maywell contribute to reachability as defined in Definition 14(3).

The Event-B proof obligation that all events be feasable is thus not necessaryto establish that a Event-B machine satisfies its invariants, but an infeasableevent is surely an indication that something is not well thought out. E.g., itcould be that a stronger guard should be used.

It is a simple exercise to show that the proof obligation for feasibility isequivalent to > if a deterministic assignment of the form v′ := t is usedasdescription of the action of an event. Only if the choice is indeterministic,it remains to be shown that the assignment is indeed feasible.

Another frequent requirement is that an Event-B machine has no deadlocks.This may be achieved by requiring that all events are feasible and

A ` I(v) ⇒∨

e∈E0

ge(v)

where E0 = E \ skip, e0.

30

Now assume that the Event-B machine N is a refinement of the Event-B machine M and that we have already established that M satisfies itsinvariants. What requirement would we ask fromN ? A minimal requirementis, of course, that N satisfies its invariant. But, that alone is not useful.The invariant for M could have been val ≥ 0 while the invariant for N isval1 + val2 ≥ 0. So, only the combined invariant val1 + val2 ≥ 0 ∧ val =val1 + val2 is actually useful. This is what is called the glue invariant inEvent-B speech. One could say that val = val1 +val2 is the glue and val ≥ 0is the invariant. But, Event-B does not support this finer distinction. Animproved requirement could now read: for every reachable state sc of Nthere is a reachable state sa of M such that the instantiation J(sc, sa) ofthe glue invariant J(vc, va) is provable. There might be situations where thisrefinement concept is sufficient. In most cases though we want closer tiesbetween M and its refinement N .

Definition 17 Let N and M be Event-B machines with common context C.N is called a simple refinement of M if for any finite trace sc

1, . . . , scn of N

with associated sequence ec1, . . . , e

cn of events there is a trace sa

1, . . . , san of M

with associated sequence ea1, . . . , e

an of events such that

1. J(sai , s

ci) is provable for all 0 ≤ i ≤ n.

2. The eci is declared to be a refinement of the event ea

i for all 0 ≤ i ≤ n.

In (2) we allow eai = skip.

The general case that machine M sees context Da and N sees context Dc

can be reduced to the considered case by let them both see the contextC = Da ∪Dc.

Lemma 15 Let M be an Event-B machine that satisfies its invariants.Let N be another Event-B machine with common context C.N is a simple refinement of M if

• every event ec ∈ EN is a refinement of an event ea ∈ EM

and the following proof obligations are satisfied:

31

REFINE A ` I(x) ∧ J(x, y) ∧Bec(y, y′) ⇒ ∃x′(Bea(x, x′) ∧ J(x′, y′))is true for all events ec ∈ EN that refine an event ea ∈ EM \e0, skip.

REFINE-Skip A ` I(x) ∧ J(x, y) ∧Bec(y, y′) ⇒ J(x, y′)is true for all new events ec ∈ EN i.e. those refining skip.

REFINE-Init A ` Beco(y) ⇒ ∃x(Bea

0(x) ∧ J(x, y))

Here I is the invariant for M and J is the glue invariant.

Proof Easy induction on the length n of the finite trace sc1, . . . , s

cn in Def-

inition 17. It should be noted that this proof makes use of the fact that wealready know that M satisfies its invariants. This is needed to justify thatI(x) occurs on the lefthand side of the implication ⇒ in the first two proofobligations.

Lemma 16 Let M and N be Event-B machines, ea ∈ EM and ec ∈ ENsuch that

1 ea is feasible2 A ` I(x) ∧ J(x, y) ∧ gec(y) ⇒ gea(x)

strengthening the guard3 A ` J(x, y) ∧Bea(x, x′) ∧Bec(y, y′) ⇒ J(y, y′)

compatibility of before-after-predicates

then the REFINE proof obligation for ea and ec is satisfied.

Proof Here is an informal argument. According to the definition of theREFINE proof obligation we have to show

A ` I(x) ∧ J(x, y) ∧Bec(y, y′) ⇒ ∃x′(Bea(x, x′) ∧ J(x′, y′))

By strengthening of the guard we get

A ` I(x) ∧ J(x, y) ∧Bec(y, y′) ⇒ gea(x)

Here we use A ` Be(v, v′) ⇒ ge(v). Using feasability of ea we get

A ` I(x) ∧ J(x, y) ∧Bec(y, y′) ⇒ ∃x′Bea(x, x′)

32

Compatibility of the before-after-predicate leads to

A ` I(x) ∧ J(x, y) ∧Bec(y, y′) ⇒ ∃x′(Bea(x, x′) ∧ J(x′, y′))

as desired.

Lt us look at an example to illustrate what has been gained by Lemma 16.

33

MACHINE WeakInvariant

VARIABLES

x, y, u

INVARIANTS

typing : x, y, u ∈ Ninv : z ≥ 0

EVENTS

Initialisation

begin

init : x, y, u := 1, 0, 0

end

Event ADD =

any

z

where

grd1 : z ∈ Zthen

addxy : x, y := x + z, y + z

diff : u := y − x

end

END

Figure 1.5: The Machine weakInvariant

34

Figure 16 shows a slight variation of the Abstract-ListSum Machine fromFigure 1.4 using the common context from Figure 1.3. We now allow integersas inputs but store in S the sum of their absolute values.

Both can be easily proved. In particular the existential quantifier in theREFINE condition for the general case in Lemma 15 is not needed in thespecial case covered by Lemma 16.

We want to use lemma 16 to prove that the machine in Figures 1.7 is asimple refinement of abstract AbsolutListSum machine. This involves toshowthat event ADD1 refines ADD and that ADD2 refines ADD. The glueinvariant J(u, v) in both cases equals u = v. Feasability of the abstract eventADD is obvious, as is assumption (2) in the lemma. The abstract guard issyntactically and conjunctively a part of the conrete guards. Assumption (3)of the lemma reads for the ADD1 refinement

List′ = cons(list 7→ value)∧S ′ = sum(cons(list 7→ value)∧value ≥ 0∧ ⇒ List′ = List′′ ∧ S ′ = S ′′

List′′ = cons(list 7→ value)∧S ′′ = sum(cons(list 7→ abs(value))

and for the ADD2 refinement

List′ = cons(list 7→ value)∧S ′ = sum(cons(list 7→ −value)∧value < 0∧ ⇒ List′ = List′′ ∧ S ′ = S ′′

List′′ = cons(list 7→ value)∧S ′′ = sum(cons(list 7→ abs(value))

A machine that only refines event ADD to ADD1 and does not containADD2 would also satisfy the definition of a refinement. But this machinewould not be deadlock-free.

We called the refinement defined in Definition 17 a simple refinement sincestronger notions are possible and sometimes desirable or necessary. Onecould e.g., require that the refinement does not introduce new deadlocks.Or, what is more frequently required that the refinement does not introducenew non-termination traces.

Definition 18 A simple refinement from M to N is called termination pre-serving if there is no infinite trace (si)i≥0 for the concrete machine N with

35

matching sequence (ei)i≥0 of events from EN such that for some n all ej withj ≥ n are new.

Assume that (si)i≥0 and (ei)i≥0 are as in the above definition. By the propertyof a simple refinement there would be a trace (sa

i )i≥0 and a matching sequenceof events (ea

i )i≥0 of M with A ` J(sai , si) for all i ≥ 0 and for all j ≥ n the

event eaj would equal skip. This somehow anomalous behaviour is not allowed

for termination preserving refinements.

Lemma 17 Let N be a simple refinement of M. If the following proofobligation is satisfied

VARIANT A ` I(x) ∧ J(x, y) ∧Be(y, y′) ⇒ V (y) > V (y′)

for alll new events e ∈ EN . Where V is a function on a well-foundeddomain (D,>).

then the refinement is termination preserving.

Proof If the refinement were not termination preserving there would ac-coring to Definition 18 be an infinite trace (si)i≥0 for N with match-ing sequence (ei)i≥0 such that all ej for j ≥ n are new. Since we as-sumed the VARIANT proof obligation to be satisfied this would lead toV (sn) > V (sn+1) > . . . > V (sj) > . . .. This contradicts the well-foundednessof the ordering (D,>).

36

MACHINE Abstract-AbsolutListSum

SEES ListSumCtx

VARIABLES

S the sum of all added absolute values


INVARIANTS

inv2 : list ∈ Zbaginv1 : S ∈ Zinv3 : S = sum(list)

S is always the sum of all current absolute values

EVENTS

Initialisation

begin

act2 : list := nil

act1 : S := 0

end

Event ADD =

any

value

where

grd1 : value ∈ Zthen


act3 : S := sum(cons(list 7→ abs(value)))

end

END

Figure 1.6: The Machine AbsolutListSum

37

MACHINE C-AbsolutListSum refines Abstract-AbsolutListSum

SEES ListSumCtx

VARIABLES

S the sum of all added absolute values


INVARIANTS

inv2 : list ∈ Natbag

inv1 : S ∈ N

inv3 : S = sum(list)S is always the sum of all current absolute values

EVENTS

Initialisation

begin

act2 : list := nil

act1 : S := 0

end

Event ADD1 refines ADD b=any

value

where

grd1 : value ≥ 0 & value ∈ Z

then


act3 : S := sum(cons(list 7→ value))

end

Event ADD2 refines ADD b=any

value

where

grd1 : value < 0 & value ∈ Z

then


act3 : S := sum(cons(list 7→ −value))

end

END

Figure 1.7: Refinement C-AbsolutListSum of the AbsolutListSum

38

1.3 Exercises

Exercise 1.3.1 Show that the following formulas are derivable from the STUaxioms.

1. ∀A(A 6∈ A)

2. ∀A∀B(¬(A ∈ B ∧B ∈ A))

3. In any model of STU for any n ∈ N there can be no elementsM1, . . . ,Mn satisfying M1 ∈Mn ∈Mn−1 ∈ . . . ∈M1.

Exercise 1.3.2 Prove the following identities:

1 r[a] = ran(a¢ r)2 dom(r1 ¢− r2) = dom(r1) ∪ dom(r2)3 (a ∪ b) ¢− r = (a¢− r) ∩ (b¢− r)4 r1 ¢− (r2 ¢− r3) = (r1 ¢− r2) ¢− r35 r ∈ α× β is transitive iff r; r ⊆ r

Exercise 1.3.3 Prove the following identity:

1 f ∈ s→ t ⇔ ∀x(x ∈ s⇒ x¢ f ∈ x → t)2 f ∈ s 7→ t ∧ x ∈ dom(f) ⇒ x 7→ f(x) ∈ f3

f ∈ s 7→ t ∧ g ∈ s 7→ t∧dom(f) ¢ g = dom(g) ¢ f

⇒ dom(f \ g) = dom(f) \ dom(g)

4 P(s) ⊆ P(t) ⇒ s ⊆ t

This indentities are taken from the book [Abrial, 1996, page 87, Property2.5.1].

Exercise 1.3.4 For any set ES of type equations either ES is not solvableor there is a triangular set of type equations ES1 with the same solutions.

39

Chapter 2

Using JML

40

This Chapter will explain in a hands-on manner how to use the Java ModelingLanguage.

41

Chapter 3

Semantics of JML

42

In this chapter we will try to give a precise meaning of the JML languageconstructs without using too heavy notation and concepts. The main refer-ence is the JML Manual [Leavens et al., 2008] and the Diploma thesis [Bruns,2009] that presents an attempt for a formal semantics of JML.

The goal of a precise semantics are twofold:

1. For the tool builder a precise semantics should clearly state what thetool should verify in order that a program may be said to satisy itsJML specifications.

2. For the user a precise semantics should clearly state what the user canassume after a tool has verified a program to be correct with respectto its JML specification.

It will become apparent that JML is almost but not quite a logical languagein the traditional sense. JML attempts to strike a balance between theprogramming language and the mathematical logical perspective. Whetherthis is possible, desirable, or useful remains to be seen.

Since JML is tightly coupled with the Java programming language one mightthink that a formal semantics of JML should include a formal semantics ofJava itself. We try to separate both and treat Java as a black box. What thatreally means will become clearer as we go along. The alternative approach,to built the semantics of JML on top a formal semantics of (a significant partof) Java is persued in [Nauman et al., 2007 revised].

3.1 A First Method Specification Example

The different parts of a method specification are in JML jargon called clauses.There are about a dozen clauses that may occur in a method specification.We start with the most important ones: the requires and the ensures

clauses, which in other context are called the preconditions and postcon-ditions. In Figure 3.1 we see examples of these clauses for the methodmiddle(). Repeated entries, as occur here for the ensures clause, are treatedas conjunction.

Definition 19 A contract

43

/*@ mod normal_behavior

@ requires pre;

@ ensures post;

@*/

mod int meth(p1 ,..,pk) ...

is satisfied if for any state s1

if the preconditions pre are satisfied in s1

then the method meth terminates, say in state s2,and s2 satisfies the postconditions post

and no exception is thrown.

Two immediate clarifications are in order.

The initial state s1 is the state when method meth is called after passing ofthe parameters p1,..,pk.

Method meth might well throw exceptions during its execution as long asthey are all caught. It is not allowed to throw an exception that leads toabrupt termination.

A state is an abstraction of the machine state. For the example at hand astate s should provide us with the value for the implicit variable this, thevalues of the object fields p1,p2,p3 and the local variables m, c12,c23,c13.We will denote these values respectively by

thiss, this.p1s, this.p2s, this.p3s, ms, c12s, c23s, c13s

An alternative, offen used notation is vals(this.p1). We chose this.p1s forits brevity.

In addition to giving the values of syntactic elements of Java a state s shouldalso evaluate JML syntax. In the example in Figure 3.1 the JML keyword\result occurs. We again use \results to denote the value of \result instate s.

The next question to answer is what happens if the precondition is not satis-fied. When we try to verify, e.g., that method middle() satisfies its contract,then there is nothing to be done in this situation. The precondition behavessimilar to the lefthand side of a logical implication. The case is different ifwe want to use a contract. Consider the method mid() in Figure 3.2 that

44

public class P3

public int p1,p2,p3;

/*@ public normal_behavior

@ requires p1!=p2 && p1!=p3 && p2!=p3;

@ ensures \result ==p1||\ result ==p2 ||\ result ==p3;

@ ensures \result >p1 || \result >p2 || \result >p3;

@ ensures \result <p1 || \result <p2 || \result <p3;

@ assignable \nothing;

@*/

public int middle ()

int m=0;

boolean c12 ,c23 ,c13;

c12 = p1 < p2;

c13 = p1 < p3;

c23 = p2 < p3;

if ((! c12 || !c13) && ( c12 || c13 )) m=p1;

if ((! c23 || c12) && ( c23 || !c12 )) m=p2;

if (( c23 || c13) && (!c13 || !c23 )) m=p3;

return m;

Figure 3.1: JML contract for midpoint program

uses the middle() method. A moment’s inspection will convince us that atthe call point of middle() the precondition of its contract is indeed satisfied.But, what happens in cases where the precondition is not satisfied? Thereference manual [Leavens et al., 2008] does not cover this case. But, thereis a broad consensus in the JML community that a method m2 that calls amethod m1 in a state where the precondition of m1 is violated does not sat-isfy its contract. This is called the blocking semantics of preconditions. Thusmethod discount() in Figure 3.3 would not satisfy its contract since in thestate method add(a,b) is called its precondition need not be true. The block-ing semantics has a definite advantage for modular verification; it dependssolely on the contract of a method and not on its implementation. On theother hand it places strong demands on the correct precondition. Look againat Figure 3.2. Method discount() does not satisfy its contract with respectto the (official) blocking semantics. On the other hand if we inline method

45


@ ensures \result >=p1|| \resul >=p2|| \resul >=p3;

@ ensures \result <=p1|| \result <=p2|| \result <=p3;


@*/

public int mid()

int m=0;

if (p1 == p2 || p1 == p3) m=p1;

else if (p2 == p3) m=p2;

else m = middle ();

return m;

Figure 3.2: A program using the middle() method

add(a,b), i.e., the command end = add(a,b) is replaced by the code ofmethod add(a,b) and its contract is dropped completely, then the contractof discount() is indeed satisfied. The example in Figure 3.3 could easily befixed by changing the precondition of add(a,b) to ‘‘requires a+b >= 0’’.In general it might not be so easy to find a complete precondition in the senseof the following definition.

Definition 20 A precondition pre for a method meth is called complete iffor any state s that does not satisfy pre method meth called in state s willnot satisfy its contract.

So, while blocking semantics is certainly the preferable choice, it might makesense for a verification tool to at least offer the option of non-blocking se-mantics.

Another question with respect to Definition 19 is how we arrive at state s2

from state s1? For all purposes of the semantics definition we need not knowthis. The semantics clearly states what should be checked to demonstratethat the contract is satisfied. In the case of Definition 19, a verification toolshould be able to analyse the code of method meth to check wether it ter-minates without exception and should provide sufficient information on thepost-state s2 to check wether posts2 = true. The semantics should not place

46

public class AddPos

public int a,b,end;


@ requires 0<= d && d <= 2 && a>0;

@ ensures end >= 0;

@ assignable end;

@*/

public void discount(int d)

if (d==0) b = 0;

if (d==1) b = -(a/3);

if (d==2) b = -(a/2);

end = add(a,b);


@ requires a>= 0 && b>= 0;

@ ensures \result >= 0;


@*/

public int add(int a,int b)

return a + b;

Figure 3.3: The AddPos Class

any restrictions on how the tool does this. It could compute weakest precon-ditions, do symbolic execution, translate the Java code into an intermediatelanguage or approximate verification by run-time checking.

3.2 States

The concept of a state in its full generality is quite complex. The first thingto say is that a state s is a function that maps all relevant basic syntacticalelements to values. The values of compound syntax expressions will then becomputed from its basic elements. The first definition will detail the domainand range of s. The second definition list restrictions a function needs tosatisfy to be counted as a (legal) state. Further clarifications and discussions

47

will follow.

Definition 21 (States)A state s is a function that

1. maps any type symbol T into a set of values T s,

2. for any field f of T1 with type T2 and any element o ∈ T s1 maps the

pair (o, f) into (o.f)s ∈ T s2 ,

3. maps local variables and method parameters v of declared type T tovs ∈ T s.

4. provides a value callstacks that is a finite sequence of pairs (µ, r)with µ a method instantiation and r an object. The entry µ consistsof a method name, its signature (parameter types and return type), theclass T that contains the code to be executed (thus dynamic dispatch isalready taken care of). If µ is a non-static method then r ∈ T s is thecalling object, in case µ is a constructor r is the generated object. If µis a static method then r is missing.

The part of a state s covered by item 2 is usually called the heap, while item3 goes by the name stack.

The function s needs to satisfy the following restriction:

1. Type restrictions

(a) For a primitive type T the value set T s is as decribed in the Javalanguage specification. E.g.; longs = −263, . . . ,+263 − 1. ThusT s is independent of s and we write VT for the set of values ofprimitive type T .

(b) For the JML model class \bigint we have T s\bigint = Z.

(c) If T1 is a subtype of T2 (T1 v T2) then T s1 ⊆ T s

2 .

(d) For every reference type T the values set T s is infinite. It isthought of as a reservoir of all objects that could be generated.There is an implicit field \created in type Object with the inten-tion that o ∈ T s | o.\created = true is the set of objects that

48

exist in state s.This approach is called the constant domain assumption. As aconsequence the set of possible values of a reference type T doesnot depend on the state s and we may denote it again by VT .

(e) For every reference type T there is a null object onull ∈ T s andnulls = onull.

(f) If T is an interface then o ∈ T s only if there is a subtype T0 v Twith o ∈ T s

0 .

(g) The JML manual [Leavens et al., 2008, Subsect. 7.1.2.2] in-troduces a type \TYPE whose interpretation is declared to bejava.lang.Class. We will not cover \TYPE here.

2. Field restrictions

(a) For any array type T [] there are implicit fields length and [n] forn ∈ N. For o ∈ (T [])s, as expected, o.lengths is the length ofarray o while o[n]s is the n-th entry in o.

(b) For static fields f in a class C we require (o1.f)s = (o2.f)s for allo1, o2 ∈ Cs.

(c) For objects o1, o2 if o1.f.\created = true then o1.\created = true.

3. Stack restrictions

(a) We assume that there is a mechanism that disambiguates namesof local variables and methods parameters.

4. Call stack restrictions

(a) For all objects o occuring as receiver object in an entry in thesequence callstacks we have o.\created = true.

Comments

State as partial function With respect to the stack part of a state s onecould argue that s should be a partial function that only assigns values tovariables that are visible in s and undefined otherwise. That is probably thebetter choice. But, we trust that no harm is done by allowing s to assignvalues that will never be used.

49

Constant domains The constant domain assumption has been the topicof many debates. Almost all formal Java semantics adopt it because of itstechnically simplicity. In formal semantics it is in addition desirable to useas few basic principles as possible. The constant domain assumption gets ridof the action that extends the set of existing elements when passing from onestate to another. This state change is reduced to the change of a field value.

In [Nauman et al., 2007 revised] a set Ref of abstract addresses is assumedfrom the start. The currently allocated objects are determined by the ref-erence context function ρ. Our o.\created = true would correspond toρ(o) 6= unit. f(a) = unit is the PVS way of saying that function f is notdefined for the argument a. There is a difference to our approach in that theelements in Ref do not have a type. Ref thus acts as the reservoir for objectof any type to be created. In our approach VT is the reservoir for objects oftype T .

In describing a formal semantics one may introduce artefacts soley for thispurpose. Like the reference context function ρ in the Core JML semanticsor the callstack in item 4 of Definition 21. The question is to what extentthese artefacts should be accessible using JML. We certainly do not want toinclude a field for the callstack. The discussion within the JML communityif a \created model field should be included has still not reached its finalconclusion. There is however little doubt that by default quantification overelements of reference types should range over created elements only. This iscontrary to Subsection 11.4.24.6 of [Leavens et al., 2008]. It would not hurthowever to still offer the possibility to quantify over the reservoir of possibleobject.

Callstack The callstack (clause 4 of Definition 21) is only used occasionallyin the definition of JML semantics, notably when it comes to explains themeaning of class invariants. Maybe, sometime in the future it will be replacedby something different.

Locations We have deliberatly been abstract on the heap part of a states. All we required was, that for any field f and any object o of the correcttype there should be a value (o.f)s. There are a couple of ways how thiscould be done in detail.

50

A In the simplest version s maps a pair (o, f) to the value (o.f)s. This isa quite popular approach. The pairs (o, f) are called locations.

B A slight variation of this approach is to map a field f into a functionf s : VT1 → VT2 for the appropriate types T1, T2. Then (o.f)s = f s(o).

C The third possibility takes a more dramatic step. Upto now the heaps h(i.e., the restriction of the map s to the set of locations) and the set of fieldsexisted only at the meta-level. Now, classes Heap and Field are introducedto model heaps and fields on the object language level. Furthermore, thefollowing functions operating on these classes are needed:

1. source takes a field as its argument and returns the class the field isdefined in,

2. target takes a field as its argument and returns its type,

3. get takes a location (o, f) (with o ∈ Vsource(f)) and a heap h as itsarguments and returns the value h(o, f) = (o.f)s,

4. set that takes a location (o, f) (with o ∈ Vsource(f)), an object o′ ∈Vtarget(f) and a heap h and returns a heap element h′ = set((o, f), o′, h).We think of h′ as

h′(x, y) =

h(x, y) if (x, y) 6= (o, f)o′ if (x, y) = (o, f)

As a last requirement we need a new program variable H of type Heap, thatpoints to the current heap.

The functions source, target, get, set do not change during progam execu-tion, only H may be evaluated to different values Hs for different states s.In this case (o.f)s = get((o, f), Hs).

This looks definitely more complicated than the approaches (A) and (B). Theadvantages of (C) will become evident when also accessible and assignableclauses are considered.

51

3.3 The Java Black Box

The concept which was named Java Black Box in [Bruns, 2009] is themechanism by which we decouple the JML semantics specification from theJava specification. When we want to specify when a piece πA of JML an-notated Java code satisfies its contracts, we need to know at least to someextend what happens by executing π. The back box list all the informationthat is needed.

Definition 22 The Java Black Box takes as input a system state s and pieceof JML annotated code πA assuming that πA is started in s and returns

1. An object Ω indicating

(a) abrupt termination, in this case Ω is the thrown exception object

(b) normal termination, in this case Ω = null

(c) of thrown and not caught exceptions in case of abrupt termination,

2. The information wether πA terminates when started in s and in thepositive case the resulting final state s2,

3. Sets LAC, LAS of locations that have been accessed, respectively assignedduring execution of πA,

4. A return value ρ in case πA is the implemenation of a method withnon-void return type and normal termination. If πA is a constructor ρwill hold the newly generated object.

5. In some cases we require the black box to return a run R of the programπA starting in s, i.e., an infinite or finite sequence of states.

When investigating method contracts we will use the black box where πA

is the implementation of a method plus the method contracts. In general,especially when assume and assert clauses are used, also more general codefragments have to be considered.

Some explanations are in order.

We ignore the case that a program terminates with an error that is not anexception. When general code fragments are considered termination caused

52

by break, continue or return statements without throwing an exceptionmay occur. These are counted as normal termination.

JML considers Java to be a deterministic language, i.e., for every piece of codeπA and every start state there is at most one final state. In JML terminologytermination includes normal and abrupt termination.

The black box works on annotated code. We assume that the effect of assign-ments to ghost fields are properly reflected in a final state s2. The concept ofrepresents clauses for model fields needs a separate, detailed explanationand analysis.

The concept of a run is still preliminary. It is, e.g., not clear what shouldcount as an intermediate state. Object creation could be considered as onstep, or broken down into a series of again intermediate steps. As a workinghypothesis we assume that a state change corresponds to the execution ofone Java command.

3.4 Undefinedness

We start by motivating why undefinedness in specifications is an issue. Weuse the example given in Figures 3.4 and 3.5 from [Chalin, 2007]. The classMyUtil contains the two methods minLen and sumUpTo. Method minLen

takes as arguments to integer arrays and returns the length of the smallerone, or the common length of both if they are of the same length. In [Chalin,2007] the specification reads

/*@ ensures \result ==

@ java.lang.Math.min(a1.length ,a2.length );

@*/

We have in Figure 3.4 replaced the reference to the Java math library by theexplicit definition of the minimum of two numbers. Method sumUpTo takes

as arguments an array a and an integer n and returns the sum Σi=(n−1)i=0 a[i].

Both method from the class MyUtil are used in the class PairSum in thebody of the methods pairSum. This method takes two arrays a, b as inputan returns the point-wise sum of both arrays Σ0≤i<n(a[i] + b[i]) upto thelength n of the smaller array.

53

public class MyUtil

/*@ ensures \result ==

@ (a1.length <= a2.length?a1.length:a2.length );


@*/

public static int minLen(int[] a1 ,int[] a2);

/*@ requires n <= a.length;

@ ensures \result ==

@ (\bsum int i; 0 ; n ; a[i]);


@*/

public static int sumUpTo(int[] a, int n);

Figure 3.4: The class MyUtil

The JML contract for method pairSum just ensures normal termination. Us-ing the method contracts of minLen and sumUpTo the contract of pairSumcan easily be proved. Chalin reports that ESC/Java2 can prove this and ver-ification using the KeY system also completes successfully. So, a programmermight be quite satisfied with this code. But, running method pairSum willresult in a null pointer exception. We have to use a bit of imagination at thispoint, since neither here nor in the cited paper [Chalin, 2007] do we find thecode of the methods minLen and sumUpTo.

public class PairSum


@ ensures true;

@*/

public static int pairSum(int[]a,int[]b)

int n = MyUtil.minLen(a, b);

return MyUtil.sumUpTo(a,n) + MyUtil.sumUpTo(b,n);

Figure 3.5: The class PairSum

54

Obviously, something is wrong with the specification of these two methods.There is more than one way to fix this problem. Chalin’s point is thatthe JML expression (a1.length <= a2.length?a1.length:a2.length) isundefined in case a1 or a2 is the null object. Undefinedness is a commonphenomenon in formal logic. The simplest example is division x/y of twointeger variables x and y that is undefined if y has value 0. There is a hugeamount of literature on how to deal with this problem, see e.g., [Hahnle,2005] for a survey on undefinedness in specification languages. The JMLposition is explained in [Leavens et al., 2008, Sect. 2.7]:

Within JML annotations, Java expressions have the values thatare defined in the Java Language Specification [Gosling et al.,2000]. . . .(This) . . .means that exceptions may arise during evaluation ofsubexpressions within assertions. These exceptions should beavoided by the specifier and tools are encouraged to warn userswhen they detect that an exception may arise during assertionevaluation.

Definition 23 A JML assertion is satisfied in a state s if

1. it does not cause an exception to be raised,

2. yields the value true.

In [Leavens et al., 2008] this is called the strong validity semantics. (Thisis not to be confused with the notion of validity in the traditional treatmentof logic, e.g., in [Schmitt, 2008].)

For the contract of method minLen in Figure 3.4 a tool should have warnedthe user in some way that an exception may occur during evaluation of theexpression (a1.length <= a2.length?a1.length:a2.length).

A formal semantics for JML should thus not only explain for every state s andevery expression t the value ts of t in s but should also define a predicate wds

such that wds(t) = true if and only if t is defined in s. As an example we lookat the definition of wd for shortcut Boolean and the arithmetic operators.The example will make use of a phenomenon we have not yet treated. InJML evaluation of an expression may also change the state. This does nothappen very often but frequently enough. A detailed explanation follows inthe next section.

55

Example 18

wds(a || b) iff as = true and wds(a) orwds(a) and wds1(b)

wds(a && b) iff as = false and wds(a) orwds(a) and wds1(b)

wds(x/y) iff wds(x) and wds2(y)and ys2 6= 0

Here s1 is the state reached after evaluating a and s2 the state after evaluatingx. In the terminology of the Definition 25 to come: s1 = ωs(a) and s2 =ωs(x).

We close this section by pointing out that the problem with the specificationsin class MyUtil could also have been solved by improving them, as in Figure3.6.

56

public class MyUtil2


@ requires a1!=null && a2!=null;


@ (a1.length <= a2.length?a1.length:a2.length );


@ also

@ public exceptional_behavior

@ requires a1==null || a2==null;

@ signals_only NullPointerException;

@*/

public static int minLen(int[] a1,int[] a2);


@ requires a!=null && n <= a.length;


@ (\bsum int i; 0 ; n ; a[i]);


@ also

@ public exceptional_behavior

@ requires a==null || n > a.length;

@ signals_only NullPointerException ,

@ ArrayIndexOutOfBoundsException;

@ signals (NullPointerException) a == null;

@ signals

@ (ArrayIndexOutOfBoundsException) n>a.length;

@*/

public static int sumUpTo(int[] a, int n);

Figure 3.6: An improved specification for MyUtil

57

3.5 Expressions with Side Effects

According to [Leavens et al., 2008, Sect. 7.1.1.3] a method declared with theJML keyword /*@pure*/ always terminates and does not change the state.Technically this can be made precise as follows:

Definition 24

1. Declaring a non-constructor method as pure amounts to adding theclauses

diverges false;

assignable \nothing;

to its specification.

2. Declaring a constructor method as pure amounts to adding the clauses

diverges false;

assignable this .*;

It is already clear from this definition that pure methods are allowed to createnew objects and change them arbitrarily. This is why JML pure methods arefrequently called weakly pure. We will follow this terminology and reservethe attribute pure for those methods that do not even generate new object.In other contexts pure methods are called queries or query methods.

The most dramatic consequence of declaring a method weakly pure, at leastas far as the topic of the current chapter is concerned, is that weakly puremethods may be used in JML specifications. This is a dramatic step. Theevaluation of a specification expression may now change the state even if onlyin a restricted way. This runs straight against the principles of tradionallogic and is also forbidden in other specification languages, e.g., in OCL.Nevertheless, the use of weakly pure methods in specifications is appealing.

We distinguish two cases. In the simpler, first case a method generates anew object, e.g., an iterator object, which after termination is no longeraccessible. In the second case the method returns a new object. This is afrequent situation since in Java information is typically represented as anobject. An example is outlined in Figure 3.7. Notice that the pure methodgetNextDate(Date from) is used in the specification in line 17.

58

1 class Date

23 class Appointment

4 /** get the next day on which a recurrent

5 * appointment is scheduled after a given date.

6 * may be complex computation e.g. Easter

7 */

8 public /*@pure */ Date getNextDate(Date from);

9

1011 class AppointmentChecker

12 public static final Date TODAY;

13 /*@

14 @ ensures (\ forall Appointment x;

15 @ \created(x) && x != null;

16 @ \result.contains(x) <==>

17 @ x.getNextDate(TODAY ). equals(TODAY ));

18 @*/

19 public List <Appointment > getTodaysAppointments ();

20

Figure 3.7: A weakly pure method returning a new object

In our formal semantics the use of weakly pure methods in a specificationexpression t will be reflected by the fact that for any state s not only thevalue ts of t and the definedness condition wds(t) will be explained, but alsoωs(t) :

Definition 25 For any state s and any JML expression t

ωs(t)

denotes the state reached after evaluating t in s.

(Note, this has already been used in Example 18).

The next example for the first time shown all three parts of the semanticsdefini

59

Example 19 Let b be a JML expression of type Boolean and c, d expressionsof compatible type and s a state. We show the semantics of the conditionalexpression b?c : d.

• (b?c : d)s =

cs if bs = trueds if bs = false

• wds(b?c : d) iff

– bs = true and wds(b) and wdωs(b)(c) or

– bs = false and wds(b) and wdωs(b)(d)

• ωs(b?c : d) =

ωωs(b)(c) if bs = trueωωs(b)(d) if bs = false

As a second example let us present the semantics of the invocation of aweakly pure method meth. The interesting case is when meth is not a staticmethod. For simplicity we assume the meth has no parameters. The generalcase may be found in [Bruns, 2009, page 105].

Example 20 Consider a weakly pure, non-static method meth without pa-rameters declared ion type T , an expression a of type T and a state s.

• (a.meth)s = ρ(here ρ is the return value of the code fragment a.meth according toDefinition 22)

• wds(a.meth) iffwds(a) and as 6= null and (a.\created)s = true and Ω = null(Ω = null signals that method call a.meth terminates normally. Seethe first item in Definition 22)

• ωs(a.meth) = s2

(here s2 is the terminating state of the method call a.meth. See item 2in Definition 22)

60

Figure 3.8 shows an example from [Adam Darvas & Muller, 2006] that theauthors use to illustrate that reasoning about annotations containing weaklypure methods without taking the involved state change into account leads tounsoundness. This example involves the concept of an invariant. Invariantswill be investigated more closely in later section. To follow this example onlya basic understanding of invariants suffices.

1 class Unsound

2 int f;

3 /*@ invariant f != 0; @*/

45 /*@ private normal_behavior

6 @ assignable f;

7 @ ensures this.f == 0;

8 @*/

9 /*@ pure helper @*/ private Unsound () f = 0;


12 @ requires v == (new Unsound ()).f;

13 @ assignable \nothing;

14 @*/

15 int divide(int v) return 5 / v;

1617 int showIt () return divide (0);

18

Figure 3.8: A weakly pure method violating an invariant

Their arguments are as follows.

Assume method divide(int v) is called in state s. By the semantics ofinvariants it is assumed that o.f!=0 holds for all objects o existing in s. Ifthe fact that evaluating the precondition changes s to s′ is ignored we canprove that divide(int v) does not terminate abruptly. Which is obviouslywrong. If the generation of proof obligations on the other hand takes intoaccount that divide(int v) is called in state s′ then there is no guaranteethat s′ satisfies all invariants. Note also, that the contract for the constructoris also satisfied, because methods with the modifier /*@helper@* are not

61

required to preserve invariants.

Also the static checks for method showIt() are passed successfuly. It needsto be verified that the precondition for calling divide(0) are satisfied, whichis in this case 0 == (new Unsound()).f;. But this readily follows from thepostcondition of the constructor.

One could object that the example in Figure 3.8 may also be taken as anargument against the use of the /*@helper@* modifier for constructors. Nev-ertheless, the point that static analysis needs to take the state change causedby weakly pure methods into account it brought home. A more direct exam-ple would be to consider an invariant that requires that there exist no morethan 4 object of type T . If a weakly pure methods generating a new objectof type T is called in a state where already 4 T -objects exist, preservation ofinvariants would fail.

62

3.6 Class And Interface Specification

The first question to be answered is when invariant should be true.

1 class Inv

2 int a,b,c;

3 /*@ invariant c >= 0; @*/


6 @ requires b >= a;

7 @ assignable c;

8 @*/

9 void balance(int a,int b)

10 c = c-a;

11 c = c+b;

12

Figure 3.9: A state violating an invariant

If the invariant c >= 0 is true in the state before calling method balance inFigure 3.9 then it will again be true in the poststate. But, it is violated inthe state after execution of line 10.

In JML invariants can be declared /*@static@* or /*@instance@*. Theinvariant in Figure 3.9 is a typical instance invariant. Remember z>=0 isshorthand for this.z>=0. Invariants that use only static fields are static,but also \forall Inv o;o.\created ;o.this >=0 would be static. TheJML Manual does not say what happens to invariants with incompatibledeclaration, e.g., if z>=0 is declared static.

The proposal presently discussed in the JML community is that invariantsshould be true in all visible states.

Definition 26 A state s is called visible for an object o if one of the followingis true:

1. s is the poststate of a non-helper constructor for that initialises o,

2. s is the prestate or poststate of a non-static non-helper method call withreceiver object o,

63

3. s is the prestate or poststate of a static non-helper method call in classT where T is a superclass of the class of o,

4. in s no constructor or non-static method invocation as described in item2, or static method invocation for a method as described in item 3 is inprogress.

A state s is called visible for class T if one of the following is true:

1. s is the poststate after static initialisation of T is complete

2. there is an object o of type T such that s is visible for o.

1 public class Invariants

2 private int z = 1;

3 /*@ private invariant z > 0; @*/

45 public void a()

6 z ++= 0;

78 public void b()

9 z = 0;

10 a();

11

Figure 3.10: Difference between visible and observable states

Visible states semantics requires that a static invariant in class T is true inall visible states for T and an instance invariant is true for all instances oand all visible states for o.

Method a in Figure 3.10 preserves the invariant z > 0, since in its poststatez has value 1. Also the poststate after execution of method b satisfies z > 0.However, the state reached after execution of line 9 is visible according toitem 2 in Definition 26. So, method b does not preserve the invariant in thevisible state semantics.

In the KeY system the observable state semantics is used. Pre- and poststatesof method calls are observable, but no intermediate states. Thus in the

64

observable state semantics method b preserves the invariant. In this approachthere is no fixed discipline which invariants should be true in the prestate ofa method call. The user decides for each preserves invariants proof obligationfor a method meth which invariants should be assumed and which invariantshave to be established. This necessitates, of course, a precise bookkeeping tomake sure that in the verification of a program all assumed invariants havealso been established.

Invariant in JML are attached to classes although their scope is universal.Any method in class D needs to preserve all invariants of class C. In manycases it will be apparent that a method from a different class D cannot influ-ence the invariants in class C. But, there are also tricky cases. The drawbacksof the visible state semantics are discussed at length in [Leavens et al., 2008,Sect. 8.2]. Notably, the fact that it does not support modular verification isstressed. A final decision on the adoption of the visible state semantics isstill pending. Other options are considered, e.g; the use some mechanism forobject ownership and alias control, to be addressed in the next section.

65

3.7 Invariants And Ownership

This section is mainly based on the paper [Muller et al., 2006]. In particularthe examples in Figures 3.11 and 3.12 are taken from there.

We start with the presentation of the idea of the ownership concept. Thiswill then be followed by explanations how this idea can be realised. Theownership concept applies to object-oriented programming languages andimposes a structure on the objects on the heap in any given state of programexecution.Each object is owned by at most one other object, called its owner. Theowner of an object o is determined when o is created and is never changed.A context is the set of all objects with the same owner. The set of objects

without owner is called the root context. The ownership relation is acyclic.Thus the contexts form a tree with the root context as root. A context ∆ isa child of context Γ if the owner of all objects in ∆ is an object in Γ.

Mathematically this could be described by a simple structure.

Definition 27 (Ownership Structure) An ownership structure (U, ow)consists of a set U and a binary relation ow ⊆ U × U such that

1. ow−1 is a partial function,i.e. ∀x1, x2∀y(ow(x1, y) ∧ ow(x2, y) → x1 = x2)

2. ow is acyclic,i.e. there is no finite sequence u1, . . . , un of elements from U such thatn ≥ 1, ow(ui, ui+1) for all 1 ≤ i < n and ow(un, u1).

Notice, that in particular ¬ow(x, x) is true in every ownership structure.Furthermore, ownership is not transitive. If, x is the owner of y, ow(x, y),and y is the owner of z, ow(y, z), then x is certainly not the owner of z,¬ow(x, z).

Lemma 21 Let (U, ow) be an ownership structure.Let C be the collection of subsets C of U of the form

C(x) = y ∈ U | ow(x, y) the context of x orCr = y ∈ U | ¬∃x(ow(x, y)) the root context.

For C1, C2 define

C1 < C2 ⇔ ∃x ∈ C2(∀y ∈ C1(ow(x, y)))

66

Then (C, <) is a tree, i.e.

1. (C, <) is acyclic, i.e. there is no finite sequence C1 < . . . Cn < C1,

2. if C < C1 and C < C2 then C1 = C2.

3. (C, <) is weakly connected.

We notice that ∃x ∈ C2(∀y ∈ C1(ow(x, y)) is equivalent to ∃x ∈ C2(∃y ∈C1(ow(x, y)) and for all C,D ∈ C C ∩D 6= ∅ already yields C = D.

Proof A cycle in (C, <) would imply a cycle in (U, ow) and the situationC < C1 and C < C2 would imply the existence of elements u, u1, u2 withow(u1, u) and ow(u2, u) and thus u1 = u2. Which is enough to ensure C1 =C2.

The ownership relation of a new object ob is defined at creation time. Anannotation following an occurence of the new operation in the code will con-trol who is the (single) owner of ob. There are three possible annotationsrep, peer, and readonly. We will only treat the first two. We work on theassumption that at any time during the execution of a Java program thereis an object tob, that is the current value of the variable this.

It is an unresolved issue what the current reference object should be duringexecution of a static method. So, we will exclude static methods from thefurther considerations in this section.

If a new object ob is generated by execution of the program code

new /*@ rep @*/ T();

then the owner of ob will be the object tob. This happens, e.g., in line 23in Figure 3.11. If a new object ob is generated by execution of the programcode

new /*@ peer @*/ T();

then the owner of ob will be the owner of tob. If no annotation is given peer

is assumed as the default.

67

This completes the explanation of the ownership structure. We would like toachieve the following encapsulation control:

In any state s during the execution of a program P if there are objects o1, o2

and a field f such that o1.fs = o2 then

1. either o1, o2 belong to the same context

2. or o1 is the owner of o2.

We will describe the main features of a type system, called the universetype system, such that any program P that is correct with respect to it willsatisfy the above property. A full description of the universe type system iscontained in [Muller, 2002].

A type system consists of the set of types involved and the typing rules. Forany Java reference type T the universe type system will contain the two typesTrep and Tpeer. A type T 1 will be a subtype of T 2, in symbols T 1 v T 2 iffthere are Java types T1, T2 with T1 v T2 and

1. T 1 = T1,rep and T 2 = T2,rep

2. T 1 = T1,peer and T 2 = T2,peer

In particular types Srep and Tpeer are disjoint for all S and T .

68

1 class List

2 private /*@ spec_public rep @*/ int[] array;

3 private /*@ spec_public @*/ int n;

45 /*@ public invariant array != null

6 @ && 0<=n && n<=array.length

7 @ && (\ forall int i; 0<=i && i<n;array[i]>=0)

8 @ && (\ forall int i; n<=i && i<array.length;

9 @ array[i]==0); @*/

10 /*@ requires k>=0 && n < Integer.MAX_VALUE;

11 @ assignable array ,array[n],n;

12 @ ensures n==\ old(n+1)

13 @ && array[\old(n)]==k

14 @ && (\ forall int i;0<=i && i<\old(n);

15 @ array[i]==\ old(array[i]));@*/

16 public void add(int k)

17 if (n==array.length) resize ();

18 array[n] = k;

19 n++;

20

2122 //@ assignable array n;

23 public void resize () /*...*/

24 public List() array = new /*@ rep @*/ int [10];

25 public void addElems(int[] elems) /*...*/

26 public /*@ pure @*/ int size() return n;

27 public void append(int i) /*...*/

28 // other methods omitted

29

Figure 3.11: An array-based list

69

1 class BagWithMax

2 private /*@ spec_public rep @*/ List theList;

3 private /*@ spec_public @*/ int maxElem;

45 /*@ public invariant theList != null

6 @ && (\ forall int i;

7 @ 0<= i && i<theList.n;

8 @ theList.array[i] <= maxElem );

910 //@ requires k>=0

11 public void insert(int k)

12 theList.add(k);

13 if (k>maxElem) maxElem = k;

14

15 // other methods and constructors omitted

16

Figure 3.12: Class BagWithMax

70

An assignment t = s in a program P is type correct if the type of s is asubtype of the type of t.

If t is an expression and f a field then the ownership type of t.f is computedby the following table:

case t f t.f

1 peer peer peer2 peer, t = this rep rep3 rep peer rep4 peer, t 6= this rep error

rep rep error

1 /*@ requires elems != null &&

2 @ (\ forall int i;0<= i && i<elems.length;

3 @ elems[i]>=0); @*/

45 public void addElems(int[] elems)

6 if (n==0)

7 array = elems;

8 n = elems.length ;

9 else ...

10

Figure 3.13: Implementation of the addElems method

Example 22 Let us consider the assignment in line 7 of the code in Figure3.13. The type of array is (int[])rep as declared in line 2 in Figure 3.11. Thetype of the parameter elems is (implicitely) declared as (int[])peer. Thus theassignment does not type check.

Motivation for Typing Rules Let e be an expression of type Tpeer andf a field declared in T with type Speer then in any state s:

the owner of es is the owner of thiss.for any ob the owner of (ob.f)s is the owner of ob.Thus, the owner of (e.f)s is the owner of thiss.

71

If f is declared in T with type Srep then in any state s:

the owner of es is the owner of thiss.for any ob, ob is the owner of (ob.f)s.The owner of (e.f)s is ?.

(e.f)s is neither owned by thiss nor in the same context as thiss.

If f is of type Speer then in any state s:

thiss is the owner of es.the owner of (ob.f)s is the owner of ob for any ob.

Then thiss is the owner of (e.f)s.

Conclusion: The type of e.f is Srep.

Examples how Universe Type checking works are contained in the code ofFigure 3.14.

Theorem 23 Let P be a program that is type correct in the universe typesystem. Then for any execution state s of P , any two objects o1, o2 such thatthere is a direct reference in s from o1 to o2 then

1. either o1, o2 belong to the same context

2. or o1 is the owner of o2.

The simplest example of a direct reference is a field f such that o1.fs = o2.

The next simplest example is the case that o1 is an array object and there isan index n such that (o1[n])s = o2.

Proof See [Muller, 2002].

72

1 class T

2 private /*@ spec_public peer@ */ Super out;

34 public void setOut(/*@ peer @*/ Super o)

5 out = o;

6

78 class Super

9 private /*@ rep @*/ T superT;

1011 private /*@ rep @*/ T leak () return superT ;

1213 public void bad(/*@ peer @*/ Super s)

14 superT = s.superT;

15 superT = s.leak ();

16 superT.setOut(this );

1718 public void init ()

19 superT.setOut(null );

20

Figure 3.14: Example for Universe Type Checking

73

Chapter 4

Introduction to Dynamic Logic

74

For a thorough introduction to Dynamic Logic we recommend [Harel, 1984]or [Kozen & Tiuryn, 1990] or the recent book [Harel et al., 2000] . A niceexample how to use propositional dynamic logic may be found in [Shilov &Yi, 2001].

We start our introduction in the next section by an example that shows howDynamic Logic can be used to verify programs.

4.1 A Motivating Example

1 public class RussM

2 static int a,b,c;

34 public static int russm(int a, int b)

5 int c = 0;

6 while (b!=0)

7 if ((b / 2) * 2 == b)

8 a = 2*a;

9 b = b / 2;

10 else

11 c = c + ((b >=0)?a:-a);

12 a = 2*a;

13 b = b / 2;

14 ;

15 return c;

16

Figure 4.1: The Program αRM

Figure 4.1 shows a simple Java program. This algorithm is sometimes referedto as Russian peasant’s multiplication. We abbreviate the program in Figure4.1 by αRM and will use it to illustrate the basic concepts of Dynamic Logicand to demonstrate program verification.

To express formal properties of programs we use JML annotations, see Figure4.2.

75


2 static int a,b,c;

34 /*@

5 @ public normal_behavior

6 @ requires b != 0;

7 @ ensures \result == a * b;

8 @ diverges true;

9 @*/


11 int c = 0;

12 /*@ loop_invariant a*b + c == x*y;

13 @ assignable a, b, c;

14 @*/

15 while (b!=0)

16 if ((b / 2) * 2 == b)

17 a = 2*a;

18 b = b / 2;

19 else

20 c = c + ((b >=0)?a:-a);

21 a = 2*a;

22 b = b / 2;

23 ;

24 return c;

25

Figure 4.2: The Program αRM with annotations

76

It is a very typical situation that one wants to assert that after some compu-tation the input values have been processed in some specific manner. E.g. inFigure 4.2 we assert that after the while-loop the program variable c equalsthe value of the product of the variables a and b before the while-loop wasentered. This can be accomplished by the use of new variables, sometimescalled external variables. This are a1 and b1 in the above example. Atthe beginning of the program the external variables are declared equal tothe program variables. Furthermore external variables are chosen such thatthey do not occur within the program itself, i.e. they will be changed by theprogram.

JML offers a more user friendly solution. The postcondition, the ensures

clause, could be expressed as

@ ensures \result == \olda * \oldb;.

But, when this is translated into a proof obligation we end up with somethingvery similar to the annotations in Figure 4.2. So, for our first example let usstick with this more elementary formulation.

Dynamic Logic takes an approach different from annotations. Rather thanusing formulas within programs it uses programs within formulas. Thisproves more flexible in many cases, allows to express properties that can-not be obtained by program annotation and makes the description of thegeneration of proof obliations more transparent.

In a first approximation the proof obligation arising from the annotations inFigure 4.2 would be written as:

b 6= 0 → [αRM ](c = a1 ∗ b1) (4.1)

We have already eliminated the JML keyword \result to make things easier.The expression in brackets [αRM ] is called a modal operator, more preciselya modal box operator. The language of Dynamic Logic will contain for everyJava program α a modal box operator [α] and also a modal diamond operator〈α〉. The meaning of a Dynamic Logic formula is determined with respectto a given state. Informally [αRM ]F is true in state s, written as s |= [αRM ]Fif the program αRM started in state s either does not terminate or terminatesin a state s′ such that s′ |= F . In contrast s |= 〈αRM〉F is true, if the programαRM started in state s does terminate and s′ |= F for the terminating states′.

77

More precisely the proof obligation 4.1 is to be understood, that for all initialvalues of a and b the given formula should be true. Making this explicit willlead to

∀int x, y(a := xb := y(b 6= 0 → [αRM ](c = a1 ∗ b1))) (4.2)

We will explain this revised proof obligation in detail. First, it shows thatin Dynamic Logic universal and (not seen here) existential quantification isallowed. The DL we will use is a typed language, so the quantified variablesare typed. Here we use universal quantification of integer valued variables.For the moment the integers are the mathematical integers. Of course, weshould argue with Java integers. But, let us postpone this additional twistfor later. Secondly, in the Dynamic Logic we use, there will be a clear dis-tinctions between program variables and logical variables. Program variablesmay occur everywhere in a formula, but they cannot be quantified. Logicalvariables can be quantified, but they are not allowed within programs. Obvi-ously, we need some kind of interface between logcial and program variables.This what updates are for. An update in its simplest form is an expressionof the form a := t where the left-hand side typically is a program variable,or an array or field access expression and the left-hand side is an arbitraryDynamic Logic expression of matching type. An formula a := tF is truein a state s, s |= a := tF if s1 |= F is true, where s1 is the state arisingfrom s by updating the value of the program variable a to ts, i.e., the valuet evaluates to in state s. This explains the meaning of proof obligation 4.2.

We will slowly step through an informal proof of obligation 4.2. This willnot cover everything that a prover, in particular the KeY prover would check.E.g., we omit parts of the proof that show the absence of null pointers.

How now would we attack a prove of statement 4.2?

It is a sensible strategy to unravel the program αRM . At a first step we getαRM = c = 0;αRM1 which leads to

∀int x, y(a := xb := y(b 6= 0 → [c = 0;αRM1](c = a1 ∗ b1))) (4.3)

Now, we symbolically execute the first statement c = 0. In the originalHoare calculus, on which our approach is based, one would substitute c by0 everywhere in the formula. For simple artificial languages that is easily

78

possible, but for general Java programs this is hard to get right. We thusturn a Java assignment into an update and continue with symbolic execution.We thus arrive at

∀int x, y(a := xb := y(b 6= 0 → c := 0[αRM1](c = a1 ∗ b1)) (4.4)

Repeating this for the next two assignments we obtain

∀int x, y(a := xb := y(b 6= 0→ c := 0, a1 := a, b1 := b[αRMwhile](c = a1 ∗ b1)))

(4.5)

Here αRMwhile denotes the rest of the program αRM after the first threeassigments have been chopped off.

The next job is to unravel the while-program αRMwhile. One way to do thisis via invariants. The general pattern goes as follows: to prove that afterexecution of a while program while(B)body the statement A is true onesearches for another statement Inv, called an invariant such that

1. Inv is true before execution of the while-program.

2. Inv ∧B → [body]Inv is true in any state.

3. Inv ∧ ¬B → A is true after termination of the loop.

For the program αRMwhile the invariant has been supplied as

a*b + c == a1*b1;

This instantiation yields the following three proof obligations:

∀int x, y(a := xb := y(b 6= 0→

c := 0, a1 := a, b1 := b, b0 := ba ∗ b+ c == a1 ∗ b1))(4.6)

The previous proof obligation was to be shown to be true in the state that isreached from the initial state by symbolic execution of the program upto thebeginning of the while loop. In contrast, the following implication should betrue after every loop iteration. Thus the formula is not placed in the scope

79

of updates. While the partial update c := 0 characterises the state beforethe first iteration of the loop it will most likely not correctly refelct the valueof c in later iterations. Thus there are no updates in the following proofobligation.

Inv ∧ b 6= 0 → [αbody]Inv (4.7)

a ∗ b+ c = a1 ∗ b1 ∧ b = 0→

c = a1 ∗ b1))(4.8)

The proof obligations 4.6 does not contain the modal operator any more. Inthis case it is easy to evaluate the updates as substitutions. Doing this forall updates, observing the sequential order in which they occur yields thefollowing proof obligation

∀int x, y(y 6= 0 → x ∗ y + 0 = x ∗ y) (4.9)

which is obviously true.

Also proof obligation 4.8 can be immediately seen to be true, since b = 0 anda ∗ b+ c = a1 ∗ b1 yields the desired conclusion.

That leaves us with 4.7 to take care of. Here αbody is the body of the whileloop, i.e.

if((b/2) ∗ 2 == b)a = 2 ∗ a; b = b/2; elsec = c+ a; a = 2 ∗ a; b = b/2;

Notice that the branching condition of the if statement (b/2)∗ 2 == b just isa round-about way to express that b is even. Let us abbreviate the programαbody as

if(even(b))branch0 elsebranch1A formula of the form [αbody]A is then treated as a case distinction anddecomposed into two claims, one for each branch of the if construct.

(a ∗ b+ c = x ∗ y ∧ even(b) ∧ b 6= 0→ [αbranch0 ] a ∗ b+ c = x ∗ y) (4.10)

(a ∗ b+ c = x ∗ y ∧ ¬even(b) ∧ b 6= 0→ [αbranch1 ] a ∗ b+ c = x ∗ y) (4.11)

80

The remaining programs αbranch0 and αbranch1 only contain assigment com-mands. Converting them into updates produces the following to claims:

(a ∗ b+ c = x ∗ y ∧ even(b) ∧ b 6= 0→ a := 2 ∗ a, b := b/2; [] a ∗ b+ c = x ∗ y) (4.12)

(a ∗ b+ c = x ∗ y ∧ ¬even(b) ∧ b 6= 0→ c := c+ a, a := 2 ∗ a, b := b/2[] a ∗ b+ c = x ∗ y) (4.13)

Since the modal operators are now empty they can be dropped and theupdates can be applied as substitutions:

(a ∗ b+ c = x ∗ y ∧ even(b) ∧ b 6= 0→ (2a) ∗ (b/2) + c = x ∗ y) (4.14)

(a ∗ b+ c = x ∗ y ∧ ¬even(b) ∧ b 6= 0→ (2a) ∗ (b/2) + c+ a = x ∗ y) (4.15)

Proof obligations 4.14 and 4.15 are not totally trivial, but a moments thoughtwill reveal their truth and a good decision procedure will find this out auto-matically.

The method of invariants used above is a push-button approach, once theinvariants are given. But sometimes it is very tricky to find an invariant thatdoes the job.

There is another issue that we have not addressed so far. When you run theprogram in Figure 4.1 with a = 1073741824 and b = 4 the result is c = 0which is certainly not the product a∗b. The problem arises since a∗b is greaterthan the maximal integer in the Java programming language. The onlysensible way to resolve this problem is a strengthening of the preconditionthat prevents the product to exeed the bounds for Java integers. A, rathergenerous, possibility is shown in Figure 4.3.

4.2 Typed First-Order Logic

We will assume that the reader is familiar with the basic concepts of first-order predicate logic. In fact, we need a bit more than is usually covered

81


2 static int a,b,c;

34 /*@ public normal_behavior

5 @ requires b >= 0 && b <= 45 000;

6 @ requires a <= 45 000;

7 @ ensures (a >=0)?(a <=45000):( -a <=45000);

8 @ diverges true;

9 @*/


11

12

Figure 4.3: Improved contract for αRM

in logic for Computer Science textbooks or undergraduate courses. We needfirst-order predicate logic with types and partial functions. We will quicklyreview what is needed. A full account can be found e.g., in [Beckert et al.,2007].

4.2.1 Types

Before anything else, even before the declaration of a signature, the set T ofavailable types and the subtype relation v among them needs to be given.The structure (T ,v) is called a type hierarchy.

It is convenient to assume that the type hierarchy (T ,v) posseses greatestlower bounds. That is to say, for any two elements A,B ∈ T there is aC ∈ T that is smaller than both, C v A and C v B and for any otherelement D ∈ T that is smaller than A and B we have D v C. More formalywe require that (T ,v) satisfies the formula

∀A∀B∃C(C v A ∧ C v B ∧ ∀D(D v A ∧D v B → D v C))

Partial orders with this property are called lower semi-lattices. Figure 4.4shows a positive and a negative example. The greatest lower bound of twotypes A and B will be denoted by A uB.

82

C1 C2

A B

(a) not a semi-lattice

C1 C2

C

A B

(b) semi-lattice

Figure 4.4: Examples of partial orders

In the later development of typed first-order logic on the syntax side everyterm will have a unique type in T and on the semantic side every elementin the universe of a structure will have a unique exact type. This mirrorsthe distinction between static and dynamic types in programming languages.One might want to have types A ∈ T that never occur as the exact type ofany element. This is e.g, useful to model A as an abstract type in Java. Thisleads to a partition T = Ta ∪ Td with Ta the set of abstract types. Sometimesthe types in T are referred to as static types while those in Td are nameddynamic types.

Depending on the application domain one might want to require that certaintypes are present in T . It is always useful to have the empty type ⊥ and theuniversal type > present. Since no element in any structure will ever havetype ⊥ this type classifies as an abstract type, e.i., ⊥ ∈ Ta. The empty type⊥ should not be confused with Java’s NULL type. In the Java world thereexist objects of type NULL.

When typed first-order logic is used in the verification of Java programs onewill of course want to include all relevant Java types in T , see Figure 4.5.

4.2.2 Syntax

The declaration of the available function and predicate symbols, this is usu-ally called the signature, of a particular instance of typed first-order logicand traditionally denoted by Σ now needs to include typing information for

83

⊤

int

Object

AbstractCollection List

AbstractList

ArrayList

Null

⊥

Figure 4.5: Example of a Type Hierarchy

each symbol in addition its number of arguments. The declaration

f : A1, . . . , An → Ap : A1, . . . , An

introduces a function symbol f that expects n arguments of the types A1,. . . , An in this order and produces an output of type A. The predicatesymbols p expects n arguments of the types A1, . . . , An in the given order.A constant symbol c will, as always, be regarded as a function symbol withn = 0 arguments and its typing information reduces to c : → A.

Further simplification of the signature Σ could be achieved by dispensingwith predicate symbols altogether and use function symbols of type Booleaninstead. It is a matter of personal taste that we do not make use of thissimplification. In addition to the symbols in Σ variable symbols x, y, z ansimilar will be used as elementary building blocks for terms and formulas.We insist that the type of a variable be declared beforehand. To this endthe set of variable declarations VSym contains pairs x : A to signify thatthe symbol x is to be used as a variable of type A. Other approaches allowvariables without typing information and use a preprocessing step to infer acorrect typing. We consider this an orthogonal issue that could be applied

84

on top of the present definitions.

Instead of simply the set of types we define in typed first-order logic for everytype A the set TrmA of terms of type A:

Definition 28

• x ∈ TrmA for any variable x : A ∈ VSym,

• f(t1, . . . , tn) ∈ TrmA

for any function symbol f : A1, . . . , An → A ∈ Σ,and terms ti ∈ TrmA′i with A′i v Ai for i = 1, . . . , n,

Note, that for every term t there is exactly on type A with t ∈ TrmA, wewrite σ(t) for this type.

Definition 29 An atomic formula is one of

1. p(t1, . . . , tn) with p : A1, . . . , An ∈ Σ and terms ti ∈ TrmA′i with A′i v Ai

for i = 1, . . . , n,

2. t1.= t2 for arbitrary terms t1, t2 (no typing constraints).

The set of all formulas ForΣ for signature Σ is built up from the atomicformulas in exactly the same way as in untpyed predicate logic. We assumethat the reader is familiar with the concept of bound and free occurences ofvariables which also carries over unchanged from untyped first-order logic.

Substitution of a term t for a variable x has to be subjected to the conditionthat the type of t is a subtype of the type of x. Otherwise no changes areneeded. We write s(t/x) and F (t/x) for the term respectively formula thatresults from s by replacing every occurrence of x in s by t, respectively byreplacing every free occurrence x in F by t.

Example 24

1. Assume that types Apple and Orange occur in T . How would youexpress that these are disjoint types?

85

2. Assume that types Apple and Orange and Banana occur in T . Howwould you express the fact that their union is already the whole univers?

Answers

1. Add Apple uOrange = ⊥ to the type hierarchy.

2. Add the axiom ∀x(∃u(u = x) ∨ ∃v(v = x) ∨ ∃w(w = x))with the variable declarations x : >, u : Apple, v : Orange, and w :Banana.

The purpose of this example is to show the usefulness of the types ⊥ and >.

4.2.3 Semantics

In the untyped case a structure for first-order logic M = (M, I) consists ofthe universe M and an interpretation I of the function and relations symbols.In the typed version the universe is subdivided into the various domains DA

for every type A ∈ T . such that

1. DA ⊆ DB if A v B follows from the type hierarchy

2. DAuB = DA ∩DB

3. D⊥ = ∅ and D> = M .

This information can be presented in a more succinct form if let a structurefor typed first-order logic be given by M = (M, δ, I) where δ : M → Td.

Lemma 25 Let M = (M, δ, I) be a structure for typed first-order logic.Define for A ∈ T the type universe DA of M by

DA = m ∈M | δ(m) v AThen the following are true

1. DA ⊆ DB if A v B follows from the type hierarchy

2. DAuB = DA ∩DB

3. D⊥ = ∅ and D> = M .

86

Proofsad 1 Assume A v B and m ∈ DA. By definition of type universes we haveδ(m) v A. By transitivity of the subtype relation this implies δ(m) v B andthus m ∈ DB.ad 2 If m ∈ DAuB then δ(m) v A u B since A u B is a lower bound of Aand B we obtain A u B v A and A u B v B, which yields δ(m) v A andδ(m) v B. By definition of DX this implies m ∈ DA ∩DB. If on the otherhand we start with m ∈ DA ∩DB we obtain δ(m) v A and δ(m) v B. SinceAuB is the greatest lower bound of A and B we get δ(m) v AuB and thusm ∈ DAuB.ad 3 m ∈ D⊥ would imply δ(m) v ⊥. This is only possible if δ(m) = ⊥.By declation of δ this is not possible since ⊥ 6∈ Td. For the second equationwe observe that X v > is true for any type x ∈ T . In particular we we getδ(m) v > for all m ∈M , i.e., D> = M .

DA

DC

DB

I(f)

A ⊓ C = ⊥, B ⊑ C, and f : A→ C.

Figure 4.6: Typed Interpretation

The interpretation I yields for every function symbol f : A1, . . . , An → Bin Σ a function I(f) from the set DA1 × . . . × DAn of n-tupels into DB.Likewise for any predicate symbol p : A1, . . . , An in Σ the interpretation I(p)is a subset of n-tupels from DA1 × . . . × DAn . See Figure 4.6 for a visual

87

representation.

The definition of an interpretation I(t) of any variable free term t now isliterally the same as in untyped logic. If a function symbol f : A→ B occurswithin t then the interpretion I(f) is not defined outside the type universeDA. The well-typedness of t ensures however that in the computation of thevalue I(t) we will only use I(f)(m) for values m ∈ DA.

In general a term t may contain variables. In this case we need in additionto the structure M an assignment β : VSym → M of domain elements tovariables. The evaluation of t is then denoted by val(M,β)(t) or t(M,β) orsimply valM(t) or tM if β is understood from the context or superfluous.The obvious restriction on the variable assignment β applies: if variable x isof type A then β(x) ∈ DA.

The set-up we have described, or recalled, so far guarantees type correctness,that is to say, the dynamic type of a term is always a subtype of its statictype. The following lemma provides a precise statement of this fact.

Lemma 26 Let t a a term of static type σ(t) = A.Let furthermore an arbitrary structure M = (M, δ, I) and a variable assign-ment β be given such that t evaluates to m = val(M,β)(t) ∈M then

δ(m) v A

Proof The proof is simple. The leading function symbol f : A1, . . . , An →B of t determines its static type, σ(t) = B. So val(M,β)(t) is obtained asI(f)(n) for some n ∈M . But the range of I(f) is DB. So δ(m) v B.

The definition of truth of a formula φ in a structure, which we denote by(Mβ) |= φ, carries no suprises. The only, but obvious modification is thatquantified variables only range over the domain of their type. We just repeatthe two relevant clauses where x : A

• (M, β) |= ∀x.φ iff (M, βdx) |= φ for every d ∈ DA.

• (M, β) |= ∃x.φ iff there is some d ∈ DA with (M, βdx) |= φ.

88

⊥

C1 C2 Cn−1. . . Cn

A

⊤

Figure 4.7: Union of Types

Here βdx is the usual modification of β given by βd

x(y) :=

d if y = x

β(y) otherwise

It is a recurring question in the semantics of class diagrams whether for thehierarchy depicted in Figure 4.7 DA = DC1 ∪ DC2 ∪ . . . ∪ DCn−11 ∪ DCn isrequired or DA ⊂ DC1 ∪ DC2 ∪ . . . ∪ DCn−11 ∪ DCn is allowed. The answerin our set-up is clear. If A ∈ Ta is an abstract type then the equality DA =DC1 ∪ DC2 ∪ . . . ∪ DCn−11 ∪ DCn has to hold in any model M = (M, δ, I)since A does not occur in the range of δ. Otherwise, for A ∈ Td models Mwith DA a proper subset of DC1 ∪DC2 ∪ . . .∪DCn−11 ∪DCn are allowed. Thisleads to a remarkable observation that has no parallel in untyped logic. Ifwe assume that Figure 4.7 shows the complete type hierarchy and A is anabstract class then the formula

Φ ≡ ∀x(n∨

i=1

∃xi(x = xi))

with x of type A and xi of type Ci for all 1 ≤ i ≤ n is a tautology. If weextend the type hierarchy by adding another class Cn+1 on the same level asall the other Ci then Φ is no longer a tautology in the logic with signature thusextended. In untyped logic the tautology property of a formula only dependson the symbols that occur in it. In the above example the tautology property

89

of φ depends on the existence of the class Cn+1 that is not mentioned in it.To avoid this phenomenon one could bar the use of abstract types, whichin most cases would be too restrictive or check carefully not to use formulasthat show this kind of non-modular behaviour. Admittedly this behavioursledom occurs in a natural context.

4.2.4 Calculus

We assume that the reader is familiar with the basic concepts of the sequentcalculus. Most of the rules for typed first-order logic are literally the sameas for the untyped case. The rules for equality, shown in Figure 4.8 are anexception. They include explicit reference to the static type σ(t) of terms t.

eq− left

Γ, t1.= t2, [z/t1](φ), [z/t2](φ) =⇒ ∆

Γ, t1.= t2, [z/t1](φ) =⇒ ∆

if σ(t2) v σ(t1).

eq− right

Γ, t1.= t2 =⇒ [z/t2](φ), [z/t1](φ),∆

Γ, t1.= t2 =⇒ [z/t1](φ),∆

if σ(t2) v σ(t1).

eq− symm− leftΓ, t2

.= t1 =⇒ ∆

Γ, t1.= t2 =⇒ ∆

eq− closeΓ =⇒ t

.= t,∆

Figure 4.8: Equality Rules in Typed FOL

To read the rules correctly we need to explain the notation [z/t](φ) occuringseveral times in their description. The formula [z/t](φ) is obtained from theformula φ be replacing all free occurences of z in φ by the term t. So far,so simple. But, why does this construct occur in the presentation of sequentcalculus rules? Suppose pred(f(c), a, f(c)) is part of the premisse of a ruleand we want to use a formula that arises from pred(f(c), a, f(c)) by replacingsome occurences of f(c) by g(d) in the conclusion of the rule. An elegant

90

way to do this is to start from pred(f(c), a, f(c)) = [z/f(c)](φ0) and replaceit by [z/g(d)](φ0). Here z is a new variable and the possible choices for φ0

are pred(z, a, f(c)), pred(z, a, z), pred(f(c), a, z), or pred(f(c), a, f(c)).

It may not be immediately clear why, e.g., in the rule eq−left, the restrictionσ(t2) v σ(t1) is necessary. We will give an example why the rule

eq− left− wrongΓ, t1

.= t2, [z/t1](φ), [z/t2](φ) =⇒ ∆

Γ, t1.= t2, [z/t1](φ) =⇒ ∆

without this restriction is unsound. Consider

1. types B v A, but B 6= A,

2. constants a : → A and b : → B,

3. a predicate p : B,

Applying the eq-left rule on the sequent

b.= a, p(b) =⇒

yieldsb.= a, p(b), p(a) =⇒

But p(a) is not a correctly typed formula!

4.2.5 Special Symbols

We have presented typed first-order logic in almost its most general form.For particular application domains it is useful to assume that certain domainspecific concepts are included in the type hierarchy or in the signature. Wetarget the verification of Java programs. In this case it is useful to assumethat the types NULL and Object are always present in the type hierarchy.What other types occur in T depends of course on the particular programunder verification, but those two types we want always be available in thelogic. Furthermore we want to write formulas x@− A. This is made possibleby requiring that the unary type predicates @−A be present in Σ for any typeA. The typing is @−A : (>). This is as definitional extention given by

∀x : >(x@− A↔ ∃y : A(y.= x))

91

type− eq

Γ, t1.= t2, t2 @− σ(t1), t1 @− σ(t2) =⇒ ∆

Γ, t1.= t2 =⇒ ∆

type− glb

Γ, t@− A, t@−B, t@− A uB =⇒ ∆

Γ, t@− A, t@−B =⇒ ∆

type− staticΓ, t@− σ(t) =⇒ ∆

Γ =⇒ ∆

type− abstractΓ, t@− A, t@−B1 | · · · | t@−Bk =⇒ ∆

Γ, t@− A =⇒ ∆with A ∈ Ta and B1, . . . , Bk the direct subtypes of A.

Figure 4.9: Rules for the Type Predicate

With type predicates the formula Φ following Figure 4.7 can be written moresuccinctly Φ ≡ ∀x : >(

∨ni=1 x@− Ci).

One could of course replace every occurence of a tpye predicate by its defi-nition and be done. It is however more efficient to add special rules for thespecial symbols. The rules necessary for dealing with the type predicates areshown in Figure 4.9. Note, that rule type− glb makes use of the existence ofgreatest lower bounds in the partial ordering of types.

4.2.6 Partial Functions

Other special symbols that would be convenient in a program logic for theverification of Java programs are type cast functions. For every type A ∈ Twe include a unary function symbol (A)() : > → A in Σ. In any structureM = (M, δ, I) we want I((A)(d)) = d for any d ∈ DA ⊆ M . But, whatshould be I((A)(d)) for d ∈ M and d 6∈ DA? This phenomenon of partialfunctions has so far not considered in our logic. This is why we devote a newsubsection to it.

92

cast− add− left

Γ, [z/t](φ), t@− A, [z/(A)t](φ) =⇒ ∆

Γ, [z/t](φ), t@− A =⇒ ∆

where A v σ(t).

cast− add− right

Γ, t@− A =⇒ [z/(A)t](φ), [z/t](φ),∆

Γ, t@− A =⇒ [z/t](φ),∆

where A v σ(t).

cast− del− left

Γ, [z/t](φ), [z/(A)t](φ) =⇒ ∆

Γ, [z/(A)t](φ) =⇒ ∆

where σ(t) v A.

cast− del− right

Γ =⇒ [z/t](φ), [z/(A)t](φ),∆

Γ =⇒ [z/(A)t](φ),∆

where σ(t) v A.

Figure 4.10: Rules for the Cast Functions

In the end we place greater emphasis on the way a theorem prover handlespartial functions than on what their model theoretic semantics should be.So let us approach an answer from the proof theoretic side. We propose tochange the calculus we have accumulated so far as little as possible. We donot revoke or change any of the previous rules and add the new rules shownin Figures 4.10 and 4.11. Let us play a bit with these rules to get some feelingwhere this will lead us.

Assume t is a term with syntactic type A, i.e., σ(t) = A. By the rule eq−closein Figure 4.8 we obtain the derivability of the sequence Γ =⇒ (A)t

.= (A)t,∆.

By rule cast−del−right in Figure 4.10 we get Γ =⇒ (A)t.= (A)t, (A)t

.= t,∆.

That is certainly what we expect.

Among the rules that we did not repeat in this subsection are the following:

all− rightΓ =⇒ [x/c](φ),∆

Γ =⇒ ∀x.φ,∆with c : → A a new constant, if x : A.

93

cast− type− left

Γ, (A)t@−B, t@− A, t@−B =⇒ ∆

Γ, (A)t@−B, t@− A =⇒ ∆

cast− type− right

Γ, t@− A =⇒ t@−B, (A)t@−B,∆

Γ, t@− A =⇒ (A)t@−B,∆

close− subtypeΓ, t@− A =⇒ t@−B,∆

with A v B.

close− emptyΓ, t@−⊥ =⇒ ∆

Figure 4.11: Rules for the Cast Functions (continued)

and

ex− rightΓ =⇒ ∃x.φ, [x/t](φ),∆

Γ =⇒ ∃x.φ,∆with t ∈ TrmA′ ground, A′ v A, if x : A.

Application of the first rule to the sequent Γ =⇒ ∀x∃y((A)x.= y),∆ for

variables x : > and y : A yields Γ =⇒ ∃y((A)c.= y,∆ followed by an

application of the second rules yields Γ =⇒ ∃y((A)c.= y), (A)c

.= (A)c,∆

which obviously is derivable. We have thus shown that ∀x∃y((A)x.= y) is a

tautology. This is a bit counterintuitive. On the other hand we will find aftersome experimenting that the formula (A)c1

.= c2 for new constant symbols

c1 : >, c2 : A cannot be logically derived. Thus in the suggested approachfor handling the functions (A)(.) we treat them as total functions but forarguments that are not of type A we have no information on their value.This approach to dealing with partial functions is called underspecification.It can be proved that a formula φ can be derived in the calculus we presentedif and only if it is true in all structures M = (M, δ, I) with I((A)(d)) = dfor any d ∈ DA. For d 6∈ DA a tautology φ has in particular to be true inall structures Me = (M, δ, Ie) for all e ∈ DA ⊆ M that differ from M onlyin Ie((A))(d) = e. Regardless of the fact that all functions have to be totalthe tautological property of φ cannot depend on a particular value outside

94

the defined part of the partial functions (A)(.). In the same all other partialfunctions are treated, e.g., integer division. Details may be found in the book[Beckert et al., 2007].

4.2.7 Conditional Terms

In this section we introduce a new syntactical concept into Dynamic Logic,that will later turn out to be helpful. While if A then B else C is a frequentlyused operation in propositional logic, terms whose value depends on the truthvalue of a formula is very uncommon in first-order logic.

Definition 30 If t1, t2 are terms then

if u.= w then t1 else t2

is a conditional term.

In a state (A, β) conditional terms are interpreted as follows:

(if u.= w then t1 else t2)

(A,β) =

t(A,β)1 if β(u) = β(w)

t(A,β)2 otherwise

As the next lemma shows, conditional terms in first-order formulas are amere convenience.

Lemma 27 • Let φ be a first-order formula without quantifiers and occan occurence of the conditional term if u

.= w then t1 else t2 in φ. Let

φ1 be obtained from φ by replacing occ by t1 and φ2 by replacing occ byt2. Then

φ↔ (u.= w ∧ φ1) ∨ (u 6= w ∧ φ2)

• For any first-order formula φ with conditional terms there is an equiv-alent formula without conditional terms.

Proof: Before we can start the proof of the lemma we state and prove acorresponding claim for term. Let s be an arbitrary term in the extendedsyntax, occ and occurence of if u

.= w then t1 else t2 in t. Let s1, s2 be the

95

term arising from s by replacing occ by t1, t2. then we get for any state(A, β)

s(A,β) =

s(A,β)1 if β(u) = β(w)

s(A,β)2 if β(u) 6= β(w)

The proof is by induction on the complexity of the term s. If s is just avariable, then s1 = s2 = s, and the claim is obvious. If s = f(s1, . . . , sk)then si = f(s1

i , . . . , ski ) for i = 1 or i = 2. Evaluating s we get first s(A,β)

= fA((s1)(A,β), . . . , (sk)(A,β)) Using the induction hypothesis we conclude incase β(u) = β(w) that s(A,β) = fA((s1

1)(A,β), . . . , (sk

1)(A,β)). Where, as you

may have guessed, sj1 arises from sj by replacing occ by t1. The last equation

now immediately yields s(A,β) = s(A,β)1 . If we use, likewise, sj

2 to denotethe term obtained from sj by replacing occ by t2, we obtain in the caseβ(u) 6= β(w): s(A,β) = fA((s1

2)(A,β), . . . , (sk

2)(A,β)). Which again leads to the

desired conclusion s(A,β) = s(A,β)2 .

It remains to consider the case s = if x.= y then s1 else s2 The subcase,

that s is in fact the occurence occ to be replaced, and consequently x ≡ u,y ≡ v,and si ≡ ti is immediately obvious. It remains to consider the subcasethat occ occurs in s1 or s2. Let us first take up the case β(u) = β(v). This

splits, naturally, again in two subcases. If β(x) = β(y) then s(A,β) = s(A,β)1

and induction hypothesis yields s(A,β)1 = s

(A,β)1,1 . If β(x) 6= β(y) then s(A,β) =

s(A,β)2 and the induction hypothesis helps us to get s

(A,β)2 = s

(A,β)2,1 . In total

we have seen s(A,β) = s(A,β)1 .

In case β(u) 6= β(v) we obtain s(A,β) = s(A,β)2 , completely analogous.

We are now ready to attack the proof of the lemma itself using structuralinduction on φ. Furthermore, the best approach to prove for each step withthis inductive proof that the given equivalence is true in any state (A, β), isto procced by case distinction wether β(u) = β(v).

For the simplest case φ = r(s1, . . . , sk) for a relation symbol r we arrive atthe proof obligations:

(A, β) |= r(s1, . . . , sk) ↔ r(s1,1, . . . , sk,1) in case β(u) = β(v)(A, β) |= r(s1, . . . , sk) ↔ r(s1,2, . . . , sk,2) in case β(u) 6= β(v)

96

By the first half of the proof we know

s(A,β)i = s

(A,β)i,1 in case β(u) = β(v)

s(A,β)i = s

(A,β)i,2 in case β(u) 6= β(v)

which settles the case immediatedly.

If the induction hypothesis supplies us with (A, β) |= φi ↔ φi,1 in case β(u) =β(v) then we also get (A, β) |= φ1∧φ2 ↔ φ1,1∧φ2,1 and (A, β) |= ¬φ1 ↔ ¬φ1,1

in case β(u) = β(v). Likewise, for other propositional connectives and theother case β(u) 6= β(v).

Part 2 An arbitrary formula φ is first transformed into an equivalent prenexnormal form Q1x1 . . . Qkxkφ0, with Qi ∈ ∀, ∃. For the quantifierfree for-mula φ0 we repeat for every occurrence of a conditional term the constructionfrom part 1 and obtain a formula φ1 with

∀x1 . . . ∀xk(φ0 ↔ φ1)

This implies also

Q1x1 . . . Qkxkφ0 ↔ Q1x1 . . . Qkxkφ1)

Comments

There is no obstacle to use if φ then t1 else t2 for arbitrary formulas φ insteadof u

.= w.

4.3 Substitutions

For later reference we review here the concept of substitution in first-orderlogic.

Let N be the well acquainted structure of the natural numbers and A theformula z ≥ 2 ∧ ∀x(div(x, z) → (x = 0 ∨ x = 1 ∨ x = z). Then (N, β) |=A if β(z) is a prime number. Let A′ be the formula obtained from A by

97

substituting the term t = 2z − 1 for z, in symbols A′ = A(t/z). Then(N, β) |= A′ if and only if t(N,β)=2β(z)− 1 is a prime number. If we substitutethe term s = 2 ∗ x for z we get A′′ = 2 ∗ x ≥ 2 ∧ ∀x(div(x, 2 ∗ x) → (x =0 ∨ x = 1 ∨ x = 2 ∗ x). Obviously (N, β) |= A′′ is always false.

The first substitution somehow preserves the meaning of the formula A whilethe second does not. The informal notion of a substitution σ preserving themeaning of the formula A is made precise by requiring that the substitutionprinciple holds true.

Definition 31 For a substitution σ and a formula A the substitution prin-ciple requires that for all states (M, β)

(M, β) |= σ(A) iff (M, β′) |= A

with β′(x) = σ(x)(M,β) for all variables x.

Definition 32 A substitution σ is allowed for a formula A if for all freevariable occurrences x in A and all variables z in σ(x) the occurrence x isnot within the scope of a quantifier binding z.

The following lemma is a well-known result of first-order logic. Its proof istedious but straight forward.

Lemma 28 (Substitution Lemma for First-Order Logic)If A is a formula of first-order logic and σ an allowed substitution for A,

then the substitution principle holds true.

4.4 The Vocabulary

In Section 4.1 we have already seen examples of formulas of Dynamic Logic.So far we depend on a rather vague understanding of the meaning of theseformulas. A precise definition of the semantics of Dynamic Logic still hasto wait till section 4.7. Here we are only concerned with the syntax. Twoobservations are important here. There are syntactic constructs, the angular〈〉 and square brackets [ ], that go beyond first-order logic. These are modaloperators. The text within brackets of both kinds is obviously very different

98

from the text outside. The first category is called the program part, thesecond the logical part.

In modal logic the modal operators occur in the simple forms 2, 3, or inmulti-modal logics in the indexed forms 2i, 3i. In Dynamic Logic modaloperators are much more complex. For every program π there will be modaloperators 〈π〉 and [π].

4.4.1 The Vocabulary of Dynamic Logic

To fix a particular instance of Dynamic Logic we have to decide on a vocab-ulary. The vocabulary comes in two parts

• A vocabulary for the logical part,

• A vocabulary for constructing programs,

The vocabulary for the logical part consists of

1. A type hierarchy (T ,v) with set set of types T ,

2. A set Σ of function and relation symbols.

Σ itself is made up of different parts

Σ = Σfnr ∪ Σf

r ∪ Σrnr ∪ Σr

r

Σfnr contains the non-rigid function symbols, Σf

r the rigid function symbolsand respectively Σr

nr and Σrr the non-rigid and rigid relation symbols. Intu-

itively rigid function and relation symbols do not change in the system modelunder consideration. Typically, one may think of functions and relations ondata types, like addition and the ≤-relation on integers. With everyn-ary function symbol f we associate the types s1, . . . , sn of its argumentsand its value type s. This information is frequently presented in the formf : s1 × . . . × sn → s. With every n-ary relation symbol r we associate thetypes of its arguments, r : s1 × . . .× sn.

The equality.=: >×> is always assumed to be present in Σr

r.

For every type s ∈ T there will be an unlimited reservoir of variablesxs, ys, xs

i , ysk of type s.

99

Function symbols may have 0 arguments, then they are called constants. Alsorelation symbols may have 0 arguments, then they are called propositionalvariables.

The syntax of the program part offers a much wider range of possibilities.We will in these lecture notes be mostly concerned with Dynamic Logic forsequential Java. It is impossible in a text like this to get anywhere close tocomplete coverage even of this part of a real programming language. We willcontend ourselves in illustrating tpyical features. A complete listing of therules used e.g., in the KeY verification system is available in the tool itself.To demonstrate the basic ideas will will sometimes take refuge to simplifiedlanguage constructs.

We use the symbol Π to denote all allowed programs and Π0 to stand for thebasic commands, assignments.

4.4.2 Example

By Lr we denote the instance of Dynamic Logic needed to talk about theexample program in Figure 4.1 . The vocabulary of Lr, as defined above,is given as follows. It is to be implicitely understood that all parts ot thevocabulary considered in this subsection belong to Lr. This saves us puttingan extra index r on every symbol.

The set T of types for Lr is

T = int, bool

There are only rigid function and relation symbols, i.e.

Σ = Σr = Σfr ∪ Σr

r.

Σfr : != : int× int → bool

/ : int× int → int∗ : int× int → int+ : int× int → int

== : int× int → bool0 : → int2 : → int

Σrr contains the equality relation

.=.

100

4.4.3 Comments

The vocabulary of an instance L of Dynamic Logic is also called the signatureof a L.

For a vocabulary Σ = Σfnr ∪Σf

r ∪Σrnr ∪Σr

r we will also use the abbreviationsΣr = Σf

r ∪ Σrr and Σnr = Σf

nr ∪ Σrr.

In this section we are only concerned with what is called the abstract syntax,i.e. we only talk about what categories of syntactical objects exist. Concretesyntax, on the other hand, determines details such as: function names shouldstart with a lowercase or uppercase letter, a function may or may not havethe same name as a relation, a unary function may or may not have the samename as a binary function etc.

4.5 Formulas and Terms of Dynamic Logic

4.5.1 Definitions

We will define terms and formulas for the instance Lr of Dynamic Logic withlogical vocabulary Σ and T as set of types. This is fairly general. The onlyrestriction is in the choice of the program part. For the sake of presentationwe will use while-programs. Our main interest will however in DynamicLogic for sequential Java programs.

Definition 33 For every type s ∈ T the set TermsLr

of all terms of type sis inductively defined by:

1. Every variable x : s is in TermsLr

.

2. If f : s1 × . . . × sn → s is a function symbol in Σ and ti are terms in

Terms′iLr

with s′i v si for all 1 ≤ i ≤ n then f(t1, . . . , tn) is a term inTerms

Lr.

For t ∈ TermsLr

we write σ(t) = S. The set TermsLr

does not depend on theallowed programs.

A term t is called flexible or non-rigid if it starts with a non-rigid functionsymbol, i.e. t = f(t1, . . . , tn) with f ∈ Σnr. The set of formulas FmlLr andprograms Πwhile

Lrare defined by simultaneous induction:

101

Definition 34

1. If r : s1× . . .× sn is a relation symbol in Σ and ti are terms in Terms′iLr

with s′i v si for all 1 ≤ i ≤ n then r(t1, . . . , tn) is a formula in FmlLr .

2. If t1, t2 are terms (of arbitrary types) then t1.= t2 is in FmlLr .

3. If F1, F2 are in FmlLr then also F1 ∨ F2 F1 ∧ F2, F1 → F2, ¬F1, ∀xsF1

and ∃xsF1 are in FmlLr .

4. If F is a formula in FmlLr and π is a program in ΠwhileLr

then [π]F and〈π〉F are formulas in FmlLr .

5. If x is a variable of type s and t is a term of type s′ with s′ v s thenx = t is in Πwhile

r .

6. If t is a term of type s and f is a flexible term of type s′ with s′ v sthen f = t is in Πwhile

r .

7. If π1,π2 are in Πwhiler then also π1; π2 is in Πwhile

r .

8. If con is in TermboolLr

and π a program in Πwhiler then

while (con) πis a program in Πwhile

r .

9. If con is in TermboolLr

and π1, π2 are programs in Πwhiler then

if (con) π1 else π2is in Πwhile

r .

4.5.2 Examples

The following are well-formed formulas of Lr:

∀aint∀bint∀zint 〈αRM〉 true∀xint∀yint∀aint∀bint∀zint( x

.= a ∧ y .

= b→ [αRM ] z.= x ∗ y)

∀xint∀yint∀aint∀bint∀zint( x.= a ∧ y .

= b→ 〈αRM〉 z .= x ∗ y)

102

4.5.3 Comments

Item 6 in Definition 34 is not part of the usual definition of Dynamic Logic.The program in Figure 4.1 contains no example of a non-rigid (i.e. flexible)symbols. The first example of these will occur in Section 4.8.

It is common to distinguish logical variables from program variables. Thishas not yet been done in Definition 34. This distinction requires the inclusionof another basic concept, that we call updates, that serve, among other things,as an interface betwenn logical and program variables.

4.6 Kripke Structures for Dynamic Logic

4.6.1 Definitions

A Kripke structure in general consists of states, sometimes also called worlds,and an accessibility relation between states. In the case of multi-modal logicsthere is one accessibility relation for every modality. In the case of Kripkestructures for Dynamic Logic, DL-Kripke structures for short, there will bean accessibility relation, usually denoted by ρ(π), for every program π.The state space of the Kripke structures for an instance of Dynamic Logicdepends first of all on the allowed programs and on the vocabulary. If onlyimperative programs are considered and all functions and relations are rigidstates may be identified with assignments to the program variables. Belowwe give the definition of Kripke structures for Lr. In this case states areidentified with structures of typed first-order predicate logic.

Definition 35 The set of states S (or worlds) of a DL-Kripke structure Kfor the Dynamic Logic Lr with vocabulary Σ = Σr ∪ Σnr is subject to thefollowing requirements

• There is a Σr-structure Ar called the rigid part of K,

• S consists of pairs (A, β), where A is a Σ-structure and β a variableassignement, i.e. a function from the set of all variables V ar into theuniverse of Ar,

103

• For every pair (A, β) in S the restriction of A to the signature Σr equalsAr, in symbols A|Σr = Ar.

• For every pair (A, β) with A a Σ-structure such that A|Σr = Ar weknow (A, β) ∈ S.

• For any pair (A, β) in S the universe of A is a fixed set U0.(constant domain assumption)

Definition 36 A DL-Kripke structure K = (S, ρ) consists of a set S ofstates (or worlds) and a function ρ that maps every program π to a binaryrelation ρ(π) on S. The ρ(π) are called the accessibility relations.

The restrictions on the evaluation of ρ(π), see Definition 37, are such thatthere is only one possible function ρ interpreting the program constructs usedto build Πwhile

r in the usual way.

4.6.2 Examples

For any Kripke structureA for our special example language Lr the rigid partAr coincides with the whole structure, i.e. A = Ar, because Σ = Σr. Thereis only one exception: the value of x/0 is not part of the structure Ar. Thisshows that Ar is not a structure for first-order logic in the usual sense. Wemight call it a partial structure since we do not require that the interpretationIr of Ar be totally defined. We trust that this short explanation suffices toconvey the general idea, details may be found in [Beckert et al., 2007]. Thestructures A occuring as first entry in a pair in S are structures in the ususalsense. So integer division in an arbitrary (A, β) ∈ S is fixed for all n/m withm 6= 0 and for any two numbers n, k we find at least one (A, β) ∈ S withA |= n/0 = k.

Back to our example. The universe Ar of Ar is the disjoint union of Zand B, i.e. Ar = Z ∪ B and Z ∩ B = ∅, with Z the set of integers andB = true, false. The interpretation of the functions and relation symbolsfrom Σ is standard. Only integer division needs, maybe, an explanation:

a/b = the greatest integer x with x ∗ b ≤ a.

Thus 8/2 = 4 and 7/2 = 3.

104

For any Kripke structure K = (S, ρ) of Lr the set of states S consists ofall pairs (A, β), where A is the fixed structure described above and β is, asusual, a variable assignment.

Here are some examples. Since the first component of all states is fixed weidentify S with the set of all variable assignments. The definition of theaccessability relation for the assignment command then reads:

ρ(zint = aint) = (β, β′) | β′(z) = β(a)

4.6.3 Comments

Notational variations of the definition of Kripke structures occur in the liter-ature. Most notably, Kripke structures are occasionally presented as tripelsK = (S0, I, ρ), where I is an interpretation function that associates struc-tures I(s) with states s ∈ S0. In this case S0 is just an abstract set. InDefinition 36 we have set, loosely speaking, S = I(s) | s ∈ S0. This isalways possible if ρ does depend on I(s) only, i.e. if (I(s1), I(s2) ∈ ρ(π) andI(si) = I(ti) implies (I(t1), I(t2) ∈ ρ(π).

Definition 36 contains a principle decision on the basic definition of a Kripkestructure. It endorses the concept of a constant domain Kripke structure, i.e.all structures occuring as the first component of a pair in S share a commonuniverse, the universe A of Ar. The theory of Kripke structures with variabledomains is decisively more complicated than the constant domain case andnot much is know about it. (For the best account to date, see the book[Fitting & Mendelsohn, 1999]). What is the price to be paid for workingwith constant domains? Do we not sometimes want to add new objects toa class? and does this not contradict the constant domain principle? Thesolution, that has also been adopted in other similar situations is as follows:The constant domain universe of the structures as part of states is seen asan infinite reservoir of possible elements. Adding new elements is achievedvia a 0− 1-function < created >. (obj). < created >= 1 means that objectobj exists, (obj). < created > e = 0 means that obj sits in the reservoirwaiting to be born. A new object is created by picking an element c fromthe reservoir with c. < created >= 0 and changing the value of < created >to c. < created >= 1.

105

4.7 Truth Definition in Kripke Structures

4.7.1 Definitions

As explained in Subsection 4.2.3 a structure A for typed first-order logic is ofthe form A = (A, δ, I), where A is the universe of A, δ the dynamic typingfunctions and I associates with every item in the vocabulary its semanticinterpretation in A. In particular, for a term t with variables x1, . . . , xk itsinterpretation I(t) is an n-ary function from A into A. For every type symbols ∈ T Ss = a ∈ A | δ(a) v s ⊆ A is the domain of elements of type s.Refer back to subsection 4.2.3 for more details. If necessary we write IAinstead of I.

Definition 37 Let K = (S, ρ) be a given DL-Kripke structure, (A, β) a statein S, F a formula in FmlLr and π a program in Πwhile

r . The evaluation t(A,β)

of terms t is defined as usual. We will define by simultaneous induction thesemantics of π, ρ(π), and (A, β) |= F , F is true in state (A, β) of K:

1. (A, β) |= r(t1, . . . , tk) iff (t(A,β)1 , . . . , t

(A,β)k ) ∈ I(r).

2. (A, β) |= t1 = t2 iff t(A,β)1 = t

(A,β)2

3. (A, β) |= F is defined as usual if the principal logical operator of F isone of the classical operators ∧, ∨, →, ¬, or one of the quantifiers ∀, ∃.

4. (A, β) |= 〈p〉F iff there is a pair ((A, β), (B, γ)) ∈ ρ(p) with (B, γ) |= F .

5. (A, β) |= [p]F iff (B, γ) |= F for all pairs ((A, β), (B, γ)) of statesin ρ(p).

6. If x is a variable, ρ(x := s) = ((A, β), (A, β[x/s(A,β)])) | (A, β) ∈ S.7. If t = f(t1, . . . , tn) is a non-rigid term, then ρ(t := s) consists of

all pairs ((A, β), (B, β)) such that B coincides with A except for theinterpretation of f , which is given by

fB(b1, . . . , bn) =

s(A,β) if (b1, . . . , bn) = (t

(A,β)1 , . . . , t

(A,β)n )

fA(b1, . . . , bn) otherwise

106

8. ρ(π1; π2) consists of all pairs ((A, β), (C, γ)) such that ((A, β), (B, δ)) ∈ρ(π1) and ((B, δ), (C, γ)) ∈ ρ(π2).

9. ((A, β), (B, γ)) ∈ ρ(while(F0)π) iff there is an n ∈ N and there arestates (Ai, βi) for 0 ≤ i ≤ n such that

(a) (A0, β0) = (A, β),

(b) (An, βn) = (B, γ),(c) (Ai, βi) |= F0 for 0 ≤ i < n

(d) (An, βn) |= ¬F0

(e) ((Ai, βi), (Ai+1,β i+ 1)) ∈ ρ(π) for 0 ≤ i < n

10. ((A, β), (B, γ)) ∈ ρ(if(F0)π1 elseπ2) iff (A, β) |= F0 and((A, β), (B, γ)) ∈ ρ(π1) or (A, β) |= ¬F0 and ((A, β), (B, γ)) ∈ ρ(π2)

4.7.2 Examples

4.7.3 Comments

Definition 37 is as usual, see e.g. [Kozen & Tiuryn, 1990], with the exceptionof clause 7.

4.8 Arrays

4.8.1 Example

for (int a = p; a < l − 1; a = a+ 1)seq[a] = seq[a+ 1];

Figure 4.12: The Program Snippet Using Arrays

A number of papers have been published on how to treat arrays in HoareLogic or Dynamic Logic, see e.g. [Apt, 1981]. The usual approach tried to

107

stay as close as possible to the initial set-up of these logics. We took (inSection 4.4) a more radical step by indroducing non-rigid functions.

Consider the code snippet in Figure 4.12. To model its semantics weintroduce, among others, (program) variables p, a and a non-rigid func-tion symbol seq into the vocabulary. If π consists of the single statementseq[a] = seq[a+ 1];,then

((M, β), (M1, β)) ∈ ρ(π)

if M1 coincides with M except for the interpretation of the function symbolseq which is given by

seqM1(x) =

seqM(x) if x 6= β(a)seqM(x+ 1) if x = β(a)

This is a first example that uses an assignment statement whose left-handside is not just a variable.

4.9 Sequent Calculus

We assume that the reader has some familarity with the sequent calculus.Extensive accounts may be found e.g. in [Gallier, 1986, Sperschneider &Antoniou, 1991] or in the lecture notes [Menzel & Schmitt, 2001]. We quicklyreview here what will be needed for the following sections.

4.9.1 Sequent Rules

Definition 38

1. A sequent is of the formΓ => ∆

where Γ and ∆ are sets of formulas. Traditionally, the part to the leftof the sequent arrow, i.e. Γ in our example, is called the antecedentand the right part, i.e. ∆ in our example, is called the succedent of thesequent.

108

2. Let K = (S, ρ) be a DL-Kripke structure, (A, β) a state in S. A sequentΓ => ∆ is true in K for state (A, β), in symbols (A, β) |= Γ => ∆ iff

(A, β) |=∧

Γ →∨

∆

3. A sequent Γ => ∆ is true in K, in symbols K |= Γ => ∆ iff (A, β) |=∧Γ → ∨

∆ for all (A, β) ∈ S.

4. A sequent Γ => ∆ is called universally valid if K |= Γ => ∆ holds forall Kripke structures K in the signature of the sequent.

Definition 39

1. A sequent rule is of the form

Γ1 => ∆1

Γ2 => ∆2or

Γ1 => ∆1 Γ′1 => ∆′1

Γ2 => ∆2

Γ1 => ∆1 and Γ′1 => ∆′1 are called the premise(s) of the rule and

Γ2 => ∆2 is called the conclusion.

2. A sequent ruleΓ1 => ∆1 Γ′1 => ∆′

1

Γ2 => ∆2

is sound if Γ2 => ∆2 is universally valid whenever Γ1 => ∆1 andΓ′1 => ∆′

1 are universally valid.

Here are some examples of sound sequent rules.

1.Γ1, A,Γ2 => ∆1, A,∆2

2.Γ,Γ′ => ∆, A,∆′

Γ,¬A,Γ′ => ∆,∆′

3.Γ => ∆, A(y/x),∆′

Γ => ∆,∀xA,∆′

where y has no free occurrence in a formula in Γ,∆,∆′

4.Γ, A,Γ′ => ∆ Γ,Γ′ => ∆, A,∆′

Γ,Γ′ => ∆,∆′

109

4.9.2 Proof Trees

The rules of a sequent calculus, like S0 e.g., are used to built proof trees.A proof tree is a tree whose nodes are labeled by sequents. Suppose, wewant to prove that a formula F is a tautology. Then we start the proof withthe root node => F . Using the rules from bottom to top we built prooftrees as e.g. shown in Figures 4.13 and 4.14. The rules with two premisesyield the branching of the proof tree. In the rule system S0, a proof tree iscalled closed if every leaf node is labeled by an axiom. We will also speak ofbranches of a proof tree in the usual sense. A branch is called closed if itsleaf node is labelled by an axiom, otherwise it is called open. Thus in S0 aproof tree is closed iff all its branches are closed.

A,B,A B,C axioms

A,B A→B,C A,B,C C

A,B, (A → B)→C C

A∧B, (A→ B)→ C C

(A→ B)→ C (A ∧B)→C

((A→ B)→ C)→((A ∧B)→ C)

impl-right

impl-right

and-left

impl-left

impl-right

Figure 4.13: Example of a closed proof tree

A proof tree T in the system Sfv0 is closed if there is a substitution τ of the

free variables in T by ground terms such that every branch of the proof tree

110

opengoals

B,A,C A,C B B,C B A,C

axioms

A∧B,A,C C A,C B B,C B A∧B,C

(A ∧B)→C A,C (B,A ∧B)→C C

A→B, (A ∧B)→ C C

(A ∧B)→ C (A→ B)→C

((A ∧B)→ C)→((A→ B)→ C)

impl-right

impl-right

impl-left

impl-left impl-left

and-right and-right

Figure 4.14: Example of an open proof tree

111

τ(T ) is closed.

Theorem 29 Let S = Γ => ∆ be a sequent containing only formulas offirst-order predicate logic without free variables.

Then S is a tautology iff there is a closed proof tree with root label S.

axiom6 p(d), p(c) p(c),∀yp(y)

5 p(d) p(c), p(c)→∀yp(y)

4 p(d) p(c),∃x(p(x) → ∀yp(y))

3 p(d) ∀yp(y),∃x(p(x) → ∀yp(y))

2 p(d)→∀yp(y),∃x(p(x) → ∀yp(y))

1 ∃x(p(x) → ∀yp(y))

ex-right

impl-right

all-right

ex-right

impl-right

(a) in S0

closed by τ(X) = c4 p(X) p(c),∃x(p(x) → ∀yp(y))

3 p(X) ∀yp(y),∃x(p(x) → ∀yp(y))

2 p(X)→∀yp(y),∃x(p(x) → ∀yp(y))

1 ∃x(p(x) → ∀yp(y))

ex-right

impl-right

all-right

(b) in Sfv0

Figure 4.15: Proof of ∃x(p(x) → ∀yp(y)))

4.9.3 Comments

Note, that in our approach antecedents and succedents are sets of formulas.This is in contrast with many other versions of sequent calculi, where se-quences or multi-sets are used instead. Treating antecedents and succedents

112

as sets simplifies the rules; we do not need rules re-ordering formulas in asequent or omitting duplicate occurrences. On the other hand the implemen-tation of sets is less straight forward.

In a sequent Γ => ∆ the sets Γ and ∆ may be empty, even both at thesame time. Truth and validity is in this case determined by the (usual)stipulation that an empty disjunction is false and an empty conjunction istrue. The sequent ∅ => ∅ is thus logically equivalent to true => false andthus evaluates to false in any state of any Kripke structure. Empty sets areusually omitted. Thus we write => instead of ∅ => ∅.The rules themselves do not suggest any preference on how to built prooftrees. One could, following a mathematically oriented method, start fromaxioms and apply proof rules from top to bottom until the desired rootsequent is reached. Alternatively, one could start from the sequent to beproved and apply proof rules from bottom to top until every branch ends inan axiom. We prefer the second, goal oriented view. This is the reason, whywe call sequents in a proof goals.

4.10 The Assignment Rule

4.10.1 The Rule

Γ(z/x), x.= t(z/x) => F,∆(z/x)

Γ => 〈x = t〉F,∆where x and t are of type s and F a first-order formua.

4.10.2 Examples

Here is a correct instance of the assignment rule:

z/2.= y, x

.= z + 2 => x/2

.= y + 1

x/2.= y => 〈x = x+ 2〉 x/2 .

= y + 1

We may continue the above proof search by

z/2.= y => (z + 2)/2

.= y + 1

z/2.= y, x

.= z + 2 => x/2

.= y + 1

x/2.= y => 〈x = x+ 2〉 x/2 .

= y + 1

113

4.10.3 Soundness Proof

To prove soundness (see Definition 39 ) of the assignment rule we assumethat the premise Γ(z/x), x

.= t(z/x) => F,∆(z/x) is universally valid and

aim to show that the conclusion Γ => 〈x = t〉F,∆ is also.

We fix a DL-Kripke structure K = (S, ρ) and an arbitrary state (A, β) in S,assuming (A, β) |= Γ. Let

β′(u) =

β(u) if u 6= zβ(x) if u = z

Since the variable z is new, it does not occur in Γ. Therefor we still have(A, β′) |= Γ. But we also have (A, β′) |= Γ(z/x) by the substitution lemmafor first-order formulas. Let β′′ be defined by

β′′(u) =

β′(u) if u 6= xt(A,β′) if u = x

We want to show (A, β′′) |= F ,

First, we note that we still have (A, β′′) |= Γ(z/x) since β′′ amd β′ differonly at the variable x which does not occur in Γ(z/x). Furthermore weobserve t(A,β′) = t(z/x)(A,β′) = t(z/x)(A,β′′). Thus (A, β′′) |= x

.= t(z/x). By

assumption we have (A, β′′) |= F,∆(z/x). If (A, β′′) |= ∆(z/x) is the case, wealso have (A, β′) |= ∆(z/x) (since x does not occur in ∆(z/x)) and thereforalso (A, β) |= ∆ and we are finished. This leaves us with the case (A, β′′) |= Fwhich again finishes the proof, because this shows (A, β′) |= 〈x = t〉F .

Note, that we have used the substitution Lemma 28 with the substitution

σ(u) =

u if u 6= xz if u = x

It is obvious that σ is not an allowed formula for Γ or ∆ if Γ or ∆ containsnone-first-order formulas. In general x will occur again on the left-hand sideof an assigment within Γ or ∆. Thus there is no chance to generalize theabove rule for arbitrary dynamic logic formulas.

4.10.4 Comments

This rule lies at the very heart of Hoare logic and therefore also of Dynamiclogic. It effects the transition from program variables to logic variables. In

114

the program statement, x = x + 2, of the above example the same symbolx appears on both sides of the assignment operator, but different values areassociated with these occurrences. No logic variable could do this. Thesolution is to introduce a new variable, z in this case, which intuitively holdsthe value of x before execution of the assignment operation. The variable xthen holds the value of x after execution of the assignment. In the generalrule every occurrence of x intended to refer to the old value of x is replaced byz. The occurrences of x refering to the new value remain unchanged. Noticethat these occurrences are the left-hand side of the assignment statementitself and all occurrence of x in the formula F . All other occurrences of xrefer to the previous value.

An alternative assigment rule We again turn the occurences of thevariable x in the assignment x = t into different logical variables, but thistime we let x denote the value of x before execution and z the value afterexecution. This yields the rule:

Definition 40Γ, z

.= t => F (z/x),∆

Γ => 〈x = t〉F,∆where x and t are of type s and F a first-order formua.

4.11 A Branching Rule

4.11.1 The Rule

Γ, F0 => 〈π1〉F,∆ Γ,¬F0 => 〈π2〉F,∆Γ => 〈if(F0)π1 elseπ2〉F,∆

4.11.2 Examples

( b2∗ 2 = b) => 〈a = 2; 〉z = y (b/2) ∗ 2 6= b) => 〈z = a〉z = y

=> 〈 if((b/2) ∗ 2 == b)a = 2; elsez = a; 〉z = y

115


This is an easy rule. But let us nevertheless spell out the proof. Assuminguniversal validity of the sequents Γ, F0 => 〈π1〉F,∆ and Γ,¬F0 => 〈π2〉F,∆we set out to prove universal validity of Γ => 〈if(F0)π1 elseπ2〉F,∆.Again we fix an arbitrary state (A, β) of an arbitrary Kripke structure Ksatisfying (A, β) |= Γ. There are two cases to be distinguished

1. (A, β) |= F0

2. (A, β) |= ¬F0

Let us follow case (1) here. The other case is absolutely analogous. Ourassumption yields (A, β) |= 〈π1〉F,∆. If we have in fact (A, β) |= ∆, then weare through. From now on may assume (A, β) |= 〈π1〉FLet (B, γ) be the unique state with ((A, β), (B, γ)) ∈ ρ(π) with π ≡if(F0)π1 elseπ2. If we can show (B, γ) |= F we are finished.

Following Definition 37 clause 10 we obtain ((A, β), (B, γ)) ∈ ρ(π1) and using(A, β) |= 〈π1〉F we conclude (B, γ) |= F .

4.11.4 Comments

Since this was so easy let us pause a moment to point out another issue. Therules we have seen so far work both ways. More precisely their conclusion isuniversally valid if and only if all premisses are universally valid, see Exercises4.15.8 and 4.15.7. What is the significance of this? Let us look at thefollowing first-branch-only rule

Γ => F0,∆ Γ => 〈π1〉F,∆Γ => 〈if(F0)π1 elseπ2〉F,∆

It can be easily seen that this is a valid rule and there might even be proofsituations where it could be usefully employed. But, in general it is a dan-gerous rule to use: We usually contruct proofs from bottom to top. Our goalis to show that Γ => 〈if(F0)π1 elseπ2〉F,∆ is universally valid. If we re-place this goal by the two goals Γ => F0,∆ and Γ => 〈π1〉F,∆ we attempt

116

to prove something that is stronger than necessary. If we succeed, we arelucky, otherwise we have to backtrack and restart our proof in the situationjust before applying the first-branch-only rule. There are more complex sit-uations where we cannot avoid going down blind alleys, but we should try asbest we can to avoid this.

4.12 A While Rule

4.12.1 The Rule

Γ => I,∆ I, F0 => [π]I I,¬F0 => FΓ => [while(F0)π]F,∆

4.12.2 Example

x.= a ∧ y .

= b ∧ z .= 0 => a ∗ b+ z

.= x ∗ y

a ∗ b+ z.= x ∗ y,¬(b

.= 0) => [αRMbody]a ∗ b+ z

.= x ∗ y

a ∗ b+ z.= x ∗ y, b .= 0 => z

.= x ∗ y

x.= a ∧ y .

= b ∧ z .= 0 => [while(b! = 0)αRMbody] z .

= x ∗ ywhith αRMbody the example program from Section 4.1. It is only for typo-graphical reasons that we have printed the three premises vertically ratherthan horizontally.


We assume the following three sequents to be universally valid

1 Γ => I,∆2 I, F0 => [π]I3 I,¬F0 => F

and try to prove (A, β) |= [while(F0)π]F,∆ for all states (A, β) satisfying(A, β) |= Γ in all Kripke structure K. From 1) we obtain (A, β) |= I,∆. Incase (A, β) |= ∆ we are immediately finished. So we assume from now on

1a Γ => I

117

Unravelling the remaining proof obligation we need to show for every n ≥ 0and every sequence (Ai, βi), 0 ≤ i ≤ n of states satisfying

a (A0, β0) = (A, β)b ((Ai, βi), (Ai+1, βi+1)) ∈ ρ(π) for all 0 ≤ i < nc (Ai, βi) |= F0 for all 0 ≤ i < nd (An, βn) |= ¬F0

that(An, βn) |= F

is true. From assumption (1a),(a) and (c) we obtain (A0, β0) |= I ∧F0. Now(2),(b) and (c) imply (Ai, βi) |= I ∧ F0 for all 0 ≤ i < n. While (2) and(d) imply (An, βn) |= I ∧ ¬F0. Now assumption (3) gives (An, βn) |= F asdesired.

4.12.4 Comments

It should be noted that ∆ occurs on the left-hand side only in the conclusionand in the third premise of the while-rule. Likewise Γ occurs only on theright-hand side in the conclusion and in the first premise. This is crucial forthe soundness of the rule, see Exercise 4.15.9.

Since there is a new syntactic entity, I, occuring in the premises of the rule,but not in its conclusion, it does not make sense to require the conversedirection of the soundness claim.

The given while rule may have its merrits, but it is certainly a disadvantagethat termination of the while-loop has to be proved in addition. A possibilityto handlethe diamond modality for while-loops will be given int he nextSection 4.13

118

4.13 Integer Induction Rule

4.13.1 The Rule

Γ => F (0/z),∆Γ => ∀v : int(v ≥ 0 ∧ F (v/z) → F ((v + 1)/z)),∆

Γ,∀v.int(v ≥ 0 → F (v/z)) => ∆Γ => ∆

Since there are no requirements placed on Γ or ∆ this rule can be alwaysapplied. It is a kind of cut rule. Apparently the rule sets up a proof byinduction on integers. The notation v : int signals that the variable v is oftype integer. We refer to the three sequents in the premise respectively asbase case, step case and use case.


Assume universal validity of

Γ => F (0/z),∆Γ => ∀v : int(v ≥ 0 ∧ F (v/z) → F ((v + 1)/z)),∆

Γ, ∀v : int(v ≥ 0 → F (v/z)) => ∆

and (A, β) |= Γ for an arbitrary state d (A, β) with the aim to prove (A, β) |=∆. From the base case we get (A, β) |= F (0/z),∆. If (A, β) |= ∆ is true weare finished, so we assume (A, β) |= F (0/z). In the same way we obtain fromthe step case (A, β) |= v : int(v ≥ 0∧F (v/z) → F ((v+1)/z)) By the principleof integer induction we get from this (A, β) |= ∀v : int(v ≥ 0 → F (v/z)).For this it is, of course, essential the the interpretation of the sort int in thestructure A are the integers. Now the use case yields (A, β) |= ∆ as desired.

4.13.3 Examples

The first is a typical example of induction on natural numbers. In thepremises we use the appreviations

Γ for a(0, y) .= y, a(s(x), y) = f(a(x, y)), a(f(x), y) = f(a(x, y))

∆ for ∀x(a(x, a(x, x)) .= a(a(x, x), x))

119

Γ => ∀y, z((a(0, a(y, z)) .= a(a(0, y), z))),∆

Γ => ∀x(∀y, z(a(x, a(y, z)) .= a(a(x, y), z))

→ ∀y, z(a(s(x), a(y, z)) .= a(a(s(x), y), z))),∆

Γ, ∀x∀y∀z(a(x, a(y, z)) .= a(a(x, y), z) => ∆

a(0, y).= y, a(s(x), y) = f(a(x, y)) => ∀x(a(x, a(x, x)) .

= a(a(x, x), x))

The second example is less obvious and shows a way to approach total cor-rectness claims for while-loops.

Let π be the program while(j > 0)r = r + 1; j = j − 1; and F be theformula ∀v〈j = z; r = v; π〉(j .

= 0).

j ≥ 0, r.= 0 => F (0/z), 〈π〉(j .

= 0)j ≥ 0, r

.= 0 => ∀v : int(v ≥ 0 ∧ F (v/z) → F ((v + 1)/z)), 〈π〉(j .

= 0)j ≥ 0, r

.= 0,∀v.int(v ≥ 0 → F (v/z)) => 〈π〉(j .

= 0)j ≥ 0, r

.= 0 => 〈π〉(j .

= 0)

It is an easy exercise to show that all thre premises can be shown to beuniversally valid.

4.13.4 Comments

This is by the way an interesting example. An attempt to prove∀x(a(x, a(x, x)) .

= a(a(x, x), x)) directly by induction on x fails. The gener-alzation to ∀x(∀y, z(a(x, a(y, z)) .

= a(a(x, y), z)) is necessary.

4.14 Program Variables

We have postponed one important issue until now.

In the logic Lr of regular programs presented so far there was no differencebetween variables used in formulas and variables used in programs. So wecould write easily ∀x(〈x = 1〉x .

= 1). Suppose we want to derive the sequent

=> ∀x.(〈x = 1〉x .= 1)

120

formally. The first rule that come to mind to start a proof is

all− rightΓ =⇒ [x/c](φ),∆

Γ =⇒ ∀x.φ,∆with c : → A a new constant, if x : A.

Literally applying the all − right rule yields => 〈c = 1〉c .= 1) for the newconstant c. This is no longer a legal formula since the constant symbol c hasto be regarded as a rigid symbol and can thus not occur on the left-handside of an assignment statement. The all− right rule that we know is soundfor first-order formulas φ thus turns out to be problematics when φ containsmodal operators. Various possibilties to correct the situation come to mind.One could e.g., require that the constant c be non-rigid. This would createother problems. The easiest and also intuitively appealing solution is theseparation of logical variables and program variables.

For every type s there are disjoint infinite sets V arls of logical variables of

type s and V arps of program variables of type s such that

1. logical variables never occur within programs

2. program variables cannot be quantified.

Thus ∀x(〈x = 1〉x .= 1) is no longer a legal formula since it contains the

universally quantified program variable x. To express what we want we needto write now ∀x(x .

= p→ 〈p = 1〉p .= 1). Logical variables are rigid symbols,

no program can effect the value of a logical variable. Program variables onthe other hand now simply are non-rigid constant symbols.

4.15 Exercises

Exercise 4.15.1 1 Prove claim 4.15 from page 81.

Exercise 4.15.2 Show that the following variation of the cast− type− leftrule from Figure 4.11 is unsound

wrong − cast− type− leftΓ, [z/(A)t](φ), t@− A, [z/t](φ) =⇒ ∆

Γ, [z/(A)t](φ), t@− A =⇒ ∆

Note, that the restriction σ(t) v A is missing here.

121

Exercise 4.15.3 Which of the following character stings are well-formedDynamic Logic formulas

1. P → 〈x := t〉 Q2. P → 〈t(i++) = u; 〉 Q3. 〈α∗〉 F ↔ F ∨ 〈α〉〈α∗〉 F4. 〈x = 1〉x .

= 1

5. [RM(true)] false

6. (〈α〉 x .= y) ↔ (〈β〉 x .

= y)

7. ∃x〈α〉true

8. (F?;α)∗;¬F?

Exercise 4.15.4 Show that the construction given in Lemma 27, part 1,does not work for formulas with quantifiers. More precisely, find a formulaφ with quantifiers such that

φ 6↔ (u = v ∧ φ1) ∨ (u 6= v ∧ φ2)

Exercise 4.15.5 Find a formula φ in Dynamic Logic (as opposed to first-order logic) such that the claim of Lemma 27 is not true.

Exercise 4.15.6 Prove the soundness of the alternative assignment rule inDefinition 40.

Exercise 4.15.7 Prove the inverse of the soundness of the assignment rulefrom Subsection 4.10.1, i.e. universal validity of the conlcusion of this rulealso implies universal validity of its premise.

Exercise 4.15.8 Prove the inverse of the soundness of the branching rule,i.e. universal validity of the conclusion of this rule also implies universalvalidity of both of its premises.

Exercise 4.15.9

1. Give an example to show that the following version of the while rule isnot sound:

Γ => I,∆ I, F0 => [π]I,∆ I,¬F0 => F,∆Γ => [while(F0)π]F,∆

122

2. Give an example to show that also following version of the while ruleis again not sound:

Γ => I I, F0 => [π]I I,¬F0 => F,∆Γ => [while(F0)π]F,∆

3. Could you think of a restriction on ∆ (besides ∆ = ∅ of course) thatwould restore the soundness of both versions of the while rule?

Exercise 4.15.10 Give an example to show that following version of thepost-increment rule is not sound:

Γ => 〈x = y; y = y + 1;α〉F,∆Γ => 〈x = y++;α〉F,∆

Exercise 4.15.11

Definition 41 Let p be a deterministic program, φ a formula. A formulaψ is called the weakest precondition for p and φ if

1. for any state s that satisfies ψ the program p terminates when startedin s and in the end state φ is true.

2. if ψ′ is another formula with the property (1) then ψ′ → ψ is universallyvalid.

Show that 〈p〉φ is the weakest precondition of p and φ.

Exercise 4.15.12 In this exercise we will use the notation w(p, φ) to de-note the weakest precondition of p and φ, see the previous exercise 4.15.11.Dijkstra has set up an axiomatic calculus for reasoning with weakest precon-ditions, see e.g., [O’Regan, 2006, Chapter 7]. Here are some of these axioms

1. wp(p, false) ↔ false

2. (φ→ ψ) → (wp(p, φ) → wp(p, ψ))

3. wp(p, φ ∨ ψ) ↔ (wp(p, φ) ∨ wp(p, ψ))

123

4. wp(p1; p2, φ) ↔ wp(p1, wp(p2, φ))where p1; p2 denotes sequential composition of programs.

Prove universal validity of these axioms using the result from the previousexercise.

Exercise 4.15.13

Definition 42 Let p be a deterministic program, φ a formula. A formulaχ is called the strongest postcondition for p and φ if

1. for any state s that satisfies φ the program p terminates when startedin s and in the end state χ is true.

2. if χ′ is another formula with the property (1) then χ→ χ′ is universallyvalid.

Show that ?? is the strongest postcondition of p and φ.

124

Chapter 5

Dynamic Logic for Java(under construction)

125

In this chapter we will address some changes that need to made when thedynamic logic Lr presented in the previous chapter 4 for simple while pro-grams is to be used for the verification of real Java programs. We will callthis new logic Java Dynamic Logic and denote it by LJavaDL. The definitionof the set of formulas FmlJavaDL of Java DL closely follows Definitions 33and 34. The only differences are

1. The addition of the new concept of updates, see Section 5.1 below.

2. The set of regular while-programs Πwhiler is replaced by the set ΠSeqJava

of sequential Java programs. The precise definition of syntax and se-mantics of ΠSeqJava is now given by the Java language specification[Gosling et al., 2000].

Java Dynamic Logic has been implemented in the KeY system, see http:

//key-project.org/. This implementation does not cover all Java features.In particular parallelism and floating-point operations are not supported andat the moment of this writing still Java 1.4 is the basis. On the other handthe Javacard fragment of Java is completely covered.

5.1 Updates

This section explains syntax, semantics, and proof rules for the logic LJavaDL

as far as the addition of updates is concerned.

Definitions 33 and 34 are extended as follows

Definition 43 (Syntax and Semantics of Updates)Let x be a programm variable and t a JavaDL term.

1. If t1 is a JavaDL term, so is x := tt1.2. If φ is a JavaDL formula, so is x := tφ.

The new modal operators of the form x := t are called updates.For a given Kripke structure K = (S, ρ) and a state (A, β) in S we definethe semantics of updates:

126

1. (x := tt1)(A,β) = t(A′,β)1 .

2. (A, β) |= x := tφ iff (A′, β) |= φ.

where A′ arises from A by the only change xA′= t(A,β).

The assignment rule presented in Section 4.10 works well for the simpleregular while programs but is problematic for a real programming languagelike Java. We replace it by the following rule:

assignΓ =⇒ Ul := t〈π ω〉φ,∆Γ =⇒ U〈π l = t; ω〉φ,∆

Here π denotes the inactive prefix. These are parts of the program occuringwithin modal operators that are not executable. The inactive prefix maye.g., contain labels or information about the call stack.

Since the assign rule may be applied repeatedly we have to take into accountthe situation that already a sequence U of updates has occurred.

The assign rule accumulates updates in front of modal operators. Once theprograms contained in these modal operators have been completely executedupdates occur in front of conventional first-order formulas. The rewrite rulesof the following lemma may then be used to eliminate updates.

Lemma 30 The following rewrite rules are sound with the respect to thesemantics of updates.

program variable x := ty ; y

x := tx ; t

logical variable x := tw ; w

complex term x := tf(t1, . . . , tn) ; f(x := tt1, . . . , x := ttn)

FOL formula x := t(φ & ψ) ; x := tφ & x := tψ· · ·

x := t(∀y : T φ); ∀y : T (x := tφ)

program formula x := t(〈p〉φ) ; x := t(〈p〉φ) unchanged!

127

Proof Obvious

5.1.1 Example

The following example derivation shows that the code fragment x = x+y; y =x − y;x = x − y switches the values of the program variables x and y. Tosimplify presentation we only show the right-hand side of the sequents in thisderivation. The left-hand sides are all empty.

∀int : i∀int : j(x := iy = j〈x=x+y; y=x-y; x=x-y〉x = j ∧ y = i) 1x := ciy = cj〈x=x+y; y=x-y; x=x-y 〉x = cj ∧ y = ci 2x := ciy = cjx := x + y〈y=x-y; x=x-y〉x = cj ∧ y = ci 3x := ciy = cjx := x + yy := x− y〈x=x-y〉x = cj ∧ y = ci 4x := ciy = cjx := x + yy := x− yx := x− y〈〉x = cj ∧ y = ci 5x := ciy = cjx := x + yy := x− yx := x− y(x = cj ∧ y = ci) 6x := ciy = cjx := x + yy := x− y(x− y = cj ∧ y = ci) 7x := ciy = cjx := x + y(x− (x− y) = cj ∧ x− y = ci) 8x := ciy = cj(y = cj ∧ x = ci) 9(cj = cj ∧ ci = ci) 10true

Line 1 states the claim to be proved, from which line 2 is obtained byskolemisation. Lines 3 to 5 arise by successively applying the assign rule tosymbolically execute the three assigment statements. In line 6 the emptydiamond operator is deleted and a first-order formula with 5 preceeding up-dates is arrived at. Lines 7 to 10 show the results of successively applyingthe rewrite rules from Lemma 30 that formalize the application of updatesto formulas.

5.1.2 Comments

The assignment rule discussed in Section 4.10 basically turns an assigmentto a program variable into a substitution on the logical level. This is onlya sound proof rule (as proved in Subsection 4.10.3) if the substiution is ap-plied to a first-order formula, as opposed to a Dynamic Logic formula. Ifwe wanted to stick with this rule we would be forced to work backwards,i.e., symbolically execute the last program statement first. For verification

128

methodologies, e.g., those using the weakest precondition calculus, that areintended to work completely automatically this will not make a difference.Our goal was to offer, if only as a last resort, the possibility of an interactiveproof. For this it is essential that the user is confronted with the usual for-ward execution of programs. It is mainly for this reason that the concept ofupdates was introduced: assignments are turned into substitutions on logi-cal formulas, but their application is postponed till all modal operators havebeen eliminated.

5.2 Parallel Updates

During symbolic execution of a program repeated application of the assignrule leades to deep nestings of updates, as can already be seen in the Ex-ample 5.1.1. We present in this section the concept of parallel updates andcorresponding rewrite rules that allow simplification of sequences of updates.

Definition 44 Parallel updates are syntactically of the form

x1 := t1|| . . . ||xk := tkwhere each xi = ti is an ordinary (non-parallel) update.Parallel updates may be used just as ordinary updates to construct new for-mulas and term

x1 := t1|| . . . xk := tkφx1 := t1|| . . . xk := tkt

A parallel update x1 := t1|| . . . xk := tk is called consistent if the programvariables xi are pairwise different.

If U = x1 := t1|| . . . ||xk := tk is a consistent update the following semanticdefinitions apply:

1. (Ut)(A,β) = t(UA,β).

2. (A, β) |= Uφ iff (UA, β) |= φ.

where UA arises from A by the changes xUAi = t(A,β)i .

An inconsistent update (. . . ||xr := tr|| . . . ||xs := ts|| with r < s and xr = xs

is replaced by (. . . ||xr := tr|| . . . ||, i.e., the earlier update is dopped. Thisprocess is repeated until a consistent updated is reached.

129

5.3 Assignments with Side Effects

5.3.1 The Rules

Γ => 〈y = y + 1;x = y;α〉F,∆Γ => 〈x = ++y;α〉F,∆

Γ => 〈z = y; y = y + 1;x = z;α〉F,∆ z a new variableΓ => 〈x = y++;α〉F,∆

We know that ((A, β), (A, γ)) ∈ ρ(z = y; y = y + 1;x = z; ) holds true ifthere are states (A, β1) and (A, β2) with((A, β), (A, β1)) ∈ ρ(z = y)((A, β1), (A, β2)) ∈ ρ(y = y + 1; )((A, β2), (A, γ)) ∈ ρ(x = z; )

From this we get

β1(x) = β(y)β1(y) = β(y)β1(z) = β(y)

andβ2(x) = β1(x)β2(y) = β1(y) + 1β2(z) = β1(z)

andγ(x) = β2(z)γ(y) = β2(y)

From this the claim immediately follows.Let us now turn to the case that x and y are the same symbol, i.e.; we arelooking at the command x = x + +. The requirement γ(x) = β(x) andγ(x) = β(x) + 1 would now be contradictory. In fact, what Java does in thiscase is: γ(x) = β(x). Following the above argument with x ≡ y reveals thatthe rule is also sound in this case.

The correctness of the pre-increment rule is proved with the same strategy.Note, that the introduction of a new variable is not needed in this case.

5.3.2 Comments

As can be seen from the soundness argument the following rules is also sound:

Γ, 〈y = y + 1;x = y;α〉F => ∆Γ, 〈x = ++y;α〉F => ∆

130

Γ => [y = y + 1;x = y;α]F,∆Γ => [x = ++y;α]F,∆

This shows that for practical purposes it will be useful to write rules in amore general schematic fashion. The above group of rules could e.g. besummarized by the following general rule

whenever you see on the left- or right-hand side of the sequentarrow => within an arbitrary modality, 〈p〉 or [p] a program pof the form x = ++y; prem, then you are allowed to replace p byy = y + 1;x = y; prem.

We will not go into this level of detail. The interested reader may consult[Beckert et al., 2004] for an example of a rule specification language.

131

Chapter 6

Solutions to Exercises

132

6.1 Solutions to Chapter 1

Exercise 1.3.1ad 1Let M be an arbitrary set. Apply axiom A6 with the quantifier ∀A instan-tiated by M. The axiom says in this case M ∩ M = ∅. Thus M 6∈ M .ad 2Assume for the sake of a contradiction that there are sets M1,M2 in a modelof STU with M1 ∈M2 ∧M2 ∈M1. Apply the regularity axiom A6 with theuniversal quantifier ∀A instantiated with M1,M2. The axioms say thateither M1∩M1,M2 = ∅ or M2∩M1,M2 = ∅. By our assumption we getM2 ∈ M1 ∩ M1,M2 and M1 ∈ M2 ∩ M1,M2. Thus contradicting both.ad 3After the preparations in the previous two step this should now be easy. Ap-ply axiom A6 with A instantiated by M1, . . . ,Mn yields the claim that forat least one i we should have Mi ∩ M1, . . . ,Mn = ∅. But our assumptionsentail Mi+1 ∈ Mi ∩ M1, . . . ,Mn if i < n or M1 ∈ Mn ∩ M1, . . . ,Mn ifi = n.

Exercise 1.3.2ad 1r[a] = y | ∃x(x ∈ a ∧ (x 7→ y) ∈ r definition of r[a]

= y | ∃x((x 7→ y) ∈ (a¢ r)) definition of a¢ r= ran(a¢ r) definition of ran

ad 2dom(r1 ¢− r2) = x | ∃y((x 7→ y) ∈ (r1 ¢− r2)) definition of dom

= x | ∃y((x 7→ y) ∈ r2) ∪x | ∃y(x 6∈ dom(r2) ∧ (x 7→ y) ∈ r1)) definition of ¢−

= dom(r2) ∪ definition of dom(r2)dom(r1) \ dom(r2) definition of dom(r1)

= dom(r1) ∪ dom(r2)ad 3(a ∪ b) ¢− r = x 7→ y | (x 7→ y) ∈ r ∧ x 6∈ (a ∪ b) definition of ¢−

= x 7→ y | (x 7→ y) ∈ r ∧ x 6∈ a ∧ x 6∈ b definition of ∪= x 7→ y | (x 7→ y) ∈ r ∧ x 6∈ a ∩

x 7→ y | (x 7→ y) ∈ r ∧ x 6∈ b simple set theory= (a¢− r) ∩ (b¢− r) definition of ¢−

ad 4

133

r1 ¢− (r2 ¢− r3) = (x 7→ y) | (x 7→ y) ∈ (r2 ¢− r3) ∧ x ∈ dom(r2 ¢− r3) or(x 7→ y) ∈ r1 ∧ x 6∈ dom(r2 ¢− r3)

= (x 7→ y) | (x 7→ y) ∈ r3 ∧ x ∈ dom(r3) or(x 7→ y) ∈ r2 ∧ x ∈ dom r2 ∧ x 6∈ dom(r3) or(x 7→ y) ∈ r1 ∧ x 6∈ dom(r2 ¢− r3)

= (x 7→ y) | (x 7→ y) ∈ r3 ∧ x ∈ dom(r3) or(x 7→ y) ∈ r2 ∧ x ∈ dom r2 ∧ x 6∈ dom(r3) or(x 7→ y) ∈ r1 ∧ x 6∈ dom(r2) ∪ dom(r3)

= (x 7→ y) | (x 7→ y) ∈ r3 ∧ x ∈ dom(r3) or(x 7→ y) ∈ r2 ∧ x ∈ dom r2 ∧ x ∈ dom(r2) \ dom(r3) or(x 7→ y) ∈ r1 ∧ x 6∈ (dom(r2) ∪ dom(r3)

= (x 7→ y) | (x 7→ y) ∈ r3 ∧ x ∈ dom(r3) or(x 7→ y) ∈ (r1 ¢− r2) ∧ x 6∈ dom(r3)

= (r1 ¢− r2) ¢− r3ad 5By definition of the relational product operator r; r ⊆ r is equivalent to

∀x, y, z((x 7→ y ∈ r ∧ y 7→ z ∈ r) → x 7→ z ∈ r)

This is obviously the definition of a transitive relation.

Exercise 1.3.3First we write down the definition of membership in the set of total functions:

f ∈ s→ t ⇔ ∀u(u ∈ f → ∃x ∈ s∃y ∈ t(u = (x 7→ y)))∧∀x∀y, y′(x ∈ s ∧ (x 7→ y) ∈ f ∧ (x 7→ y′) ∈ f→ y = y′)∧

∀x(x ∈ s→ ∃y(y ∈ t ∧ (x 7→ y) ∈ f)

(6.1)

For the special case s = a this yields after some simplifications:

g ∈ a→ t ⇔ ∀u(u ∈ g → ∃y ∈ t(u = (a 7→ y)) ∧∀y, y′((a 7→ y) ∈ g ∧ (a 7→ y′) ∈ g → y = y′) ∧∃y(y ∈ t ∧ (a 7→ y) ∈ g)

(6.2)

We want to prove f ∈ s→ t⇒ ∀x(x ∈ s⇒ x¢ f ∈ x → t)

So, consider an arbitrary a ∈ S with the goal of showing a¢ f ∈ a → t.

134

To shows this we substitute a¢f for g in 6.2 obtaining the proof obligation:

a¢ f ∈ a→ t ⇔ ∀u(u ∈ a¢ f → ∃y ∈ t(u = (a 7→ y)) ∧∀y, y′((a 7→ y) ∈ a¢ f ∧ (a 7→ y′) ∈ a¢ f→ y = y′) ∧

∃y(y ∈ t ∧ (a 7→ y) ∈ a¢ f)

(6.3)

Note, that

u ∈ a¢ f ⇔ ∃y(u = (a 7→ y) ∧ (a 7→ y) ∈ f) (6.4)

(x 7→ y) ∈ a¢ f ⇔ x = a ∧ (x 7→ y) ∈ f (6.5)

Let us look at every one of the three conjunctions on the right-hand side ofthe equivalence 6.3 separately.

1. Conjunct To prove

∀u(u ∈ a¢ f → ∃y ∈ t(u = (a 7→ y)) (6.6)

we fix u ∈ a¢ f and try to arrive at ∃y ∈ t(u = (a 7→ y)).

u ∈ a¢ f ⇔ ∃y(u = (a 7→ y) ∧ (a 7→ y) ∈ f) by 6.4⇔ u = (a 7→ b) ∧ (a 7→ b) ∈ f for some bonly b ∈ t is missingthis follows from 6.1


∀y, y′((a 7→ y) ∈ a¢ f ∧ (a 7→ y′) ∈ a¢ f → y = y′) (6.7)

we fix interpretations b, b′ for y, y′

(a 7→ b) ∈ a¢ f ∧ (a 7→ b′) ∈ a¢ f ⇔ (a 7→ b), (a 7→ b′) ∈ f by 6.5⇒ b = b′ by 6.1


∃y(y ∈ t ∧ (a 7→ y) ∈ a¢ f) (6.8)

we use 6.1 to obtain b such that

b ∈ t ∧ (a 7→ b) ∈ f ⇔ b ∈ t ∧ (a 7→ b) ∈ a¢ f by 6.5

135

Exercise 1.3.4The transition form ES to ES1 is in addition quite simple. In a first phaseperform the following operations as long as possible

1. If ES contains an equation of the form P(T1) = P(T2) replace it byT1 = T2

2. If ES contains an equation of the form T1× S1 = T2× S2 replace it bythe two equations T1 = T2 and S1 = S2

3. If ES contains an equation of the form P(T1) = S2 × S2 declare itunsolvable.

This will result in a system of type equations of the form

X1 = T1

X2 = T2...

...Xn = Tn

If Xi ≡ Xj repeat the above process with the equation Ti = Tj added. Inthe end we may assume that all Xi are different.Define Xi /

1 Xj if Xi occurs in Tj and Tj is not a variable. Let / be thetransitive closure of /1. If the /-relation contains a loop, i.e. if Xi / Xi forsome i, then the system of equations is not solvable. To see this we considera loop Xi1 / Xi2 / . . . Xik ≡ Xi1 . Any solution of the system ES is also asolution of the equation Xik ≡ Xi1 = Ti1 [Xik−1

/Tik−1], where every occurence

of Xik−1in Tik ≡ Ti1 is replaced by Tik−1

. In the same way we see that anysolution of ES is also a solution of Xi1 = Ti1 [Xik−1

/Tik−1] . . . [Xi2/Ti2 ]. By

the definition of /1 the type variable Xi1 occurs in Ti2 and also in the termT ′ ≡ Ti1 [Xik−1

/Tik−1] . . . [Xi2/Ti2 ] obtained by successive subsitutions. But

the equation Xi1 = T ′ has no solution, since no matter what we substitutefor Xi the righthand side will always be longer than the lefthand side. Theargument just given works for k > 1. But, for k = 1 the equation Xi1 withTi1 not a variable and Xi1 occuring in Ti1 is already unsolvable. Thus wehave convinced ourselves that there are no /-loops. Ignore for a momentequations among variables. We now rearrange the equations in ES to satisfythe triangularity condition. Since there are no loops we can choose a maximalXi, i.e. an Xi such that there is no Y with Xi / Y , i.e.Xi does not occur on

136

any righthand side. We repeat this process among the remaining equations.In the end we add the equations among variables add the bottom of theprevious list. The omit the details of this last phase.

6.2 Solutions to Chapter 4

Exercise 4.15.1The goal is to prove

(a ∗ b+ c = x ∗ y ∧ ¬even(b) ∧ b 6= 0 → (2a) ∗ (b/2) + c+ a = x ∗ y)If b is an uneven number that we may write b = 2b0+1. In this case b/2 = b0.Thus(2a) ∗ (b/2) + a = (2a) ∗ b0 + a

= a ∗ (2b0) + a= a ∗ (2b0 + 1)= a ∗ b

Exercise 4.15.2Consider a predicate p that expects an argument of type A. Assume thatA v B and c is a constant of type B. Applying the wrong − cast − type −left rule to the sequent Γ, p((A)c), c @− A =⇒ ∆ we obtain the sequentΓ, p((A)c), c@− A, p(c) =⇒ ∆ with the ill-typed formula p(c).

Exercise 4.15.3to be done



137






Exercise 4.15.11The claim wp(p, φ) = 〈p〉φ follows directly from the semantics definition ofthe modal operator 〈〉.

Exercise 4.15.12Using the equation wp(p, φ) = 〈p〉φ from the previous exercise 4.15.11 weobtain the following claims

1. 〈p〉false ↔ false

2. (φ→ ψ) → (〈p〉φ) → 〈p〉ψ))

3. 〈p〉(φ ∨ ψ) ↔ (〈p〉φ) ∨ 〈p〉ψ))

4. 〈p1; p2〉φ) ↔ 〈p1〉〈p2〉φ

138

Bibliography

[Abrial & Hallerstede, 2007] Jean-Raymond Abrial & Stefan Hallerstede.Refinement, decomposition, and instantiation of discrete models: Appli-cation to event-b. Fundamenta Informaticae, 77:1–28, 2007.

[Abrial, 1996] Jean-Raymond Abrial. The B-Book. Cambridge UniversityPress, 1996.

[Adam Darvas & Muller, 2006] Adam Darvas & Peter Muller. Reasoningabout method calls in interface specifications. J. of Object Technology(JOT), 05(5):59–85, 2006. Special Issue: ECOOP 2005 Workshop FTfJP.

[Apt, 1981] K. R. Apt. Ten years of Hoare logic: A survey - part I. ACMTrans. on Prog. Languages and Systems, 1981.

[Beckert et al., 2004] Bernhard Beckert, Martin Giese, Elmar Habermalz,Reiner Hahnle, Andreas Roth, Philipp Rummer, & Steffen Schlager.Taclets: A new paradigm for constructing interactive theorem provers.RACSAM, Rev. R. Acad. Cien. Serie A. Mat., page to appear, 2004.

[Beckert et al., 2007] Bernhard Beckert, Reiner Hahnle, & Peter H. Schmitt,editors. Verification of Object-Oriented Software: The KeY Approach.LNCS 4334. Springer-Verlag, 2007.

[Bruns, 2009] Daniel Bruns. Formal semantics for the Java Modeling Lan-guage. Diplomarbeit, Universitat Karlsruhe, Fakultat fur Informatik, June2009.

[Chalin, 2007] Patrice Chalin. A sound assertion semantics for the depend-able systems evolution verifying compiler. In Proc. Int.Conf.on SoftwareEngineering (ICSE), 2007.

139

[Fitting & Mendelsohn, 1999] Melvin Fitting & Richard L. Mendelsohn.First-Order Modal Logic, volume 277 of Synthese Library. Kluwer Aca-demic Publishers, 1999.

[Gallier, 1986] Jean H. Gallier. Logic for Computer Science: Foundations ofAutomated Theorem Proving. Harper and Row, New York, 1986.

[Gosling et al., 2000] James Gosling, Bill Joy, Guy Steele, & Gilad Bracha.The Java Language Specification. Addison Wesley, 2nd edition, 2000.

[Habrias & Frappier, 2006] Henri Habrias & Marc Frappier, editors. Soft-ware Specification Methods. ISTE, 2006.

[Hahnle, 2005] Reiner Hahnle. Many-valued logic, partiality, and abstractionin formal specification languages. Logic Journal of the IGPL, 13(4):415–433, July 2005.

[Hallerstede, 2008] Stefan Hallerstede. On the purpose of EventB proof obli-gations. In E.Borger & etal, editors, Proc. ABZ 2008, volume 5238 ofLNCS, pages 125–138. Springer, 2008.

[Harel et al., 2000] David Harel, Dexter Kozen, & Jerzy Tiuryn. DynamicLogic. The MIT Press, 2000.

[Harel, 1984] David Harel. Dynamic logic. In Handbook of PhilosophicalLogic, volume II Extensions of Classical Logic, pages 497 – 604. D.Reidel,1984.

[Kozen & Tiuryn, 1990] Dexter Kozen & Jerzy Tiuryn. Logics of programs.In van Leeuwen [van Leeuwen, 1990], chapter 14, pages 791–840.

[Leavens et al., 2008] G.T. Leavens, E. Poll, C.Clifton, Y. Cheon, C. Ruby,D. Cok, P. Muller, J. Kiniry, P. Chalin, D.M. Zimmerman, & W. Dietl.JML Reference Manual, May 2008.

[Menzel & Schmitt, 2001] Wolfram Menzel & Peter H. Schmitt. FormaleSysteme. Vorlesungsskript (in deutsch), 2001.

[Metayer & Voisin, 2009] Christophe Metayer & Laurent Voisin. The Event-B Mathematical Language. Systerel, March 2009.

140

[Muller et al., 2006] Peter Muller, Arnd Poetzsch-Heffter, & Gary T. Leav-ens. Modular invariants for layered object structures. Sci. Comput. Pro-gram., 62(3):253–286, 2006.

[Muller, 2002] Peter Muller. Modularspecification and Verification of Object-Oriented Programs, volume 2262 of LNCS. Springer, 2002.

[Nauman et al., 2007 revised] D. Nauman, Gary T. Leavens, & Stan Rosen-berg. Preliminary definition of core JML. Cs report, Stevens Institute ofTechnology, 2007 (revised).

[O’Regan, 2006] Gerard O’Regan. Mathematical Approaches to SoftwareQuality. Springer, 2006.

[Schmitt, 2008] Peter H. Schmitt. Formale Systeme. Vorlesungsskript (indeutsch), 2008.

[Shilov & Yi, 2001] N. V. Shilov & K. Yi. How to find a coin: propositionalprogram logics made easy. Bulletin of the EATCS, 75:127–151, October2001.

[Sperschneider & Antoniou, 1991] Volker Sperschneider & G. Antoniou.Logic, a foundation for computer science. Addison-Wesley, 1991.

[Suppes, 1960] Patrick Suppes. Axiomatic Set Theory. The University Seriesin Undergraduate Mathematics. D. van Nostrand Co, 1960.

[Takeuti & Zaring, 1971] Gaisi Takeuti & Wilson M. Zaring. Introduction toAxiomatic Set Theory. Graduate Texts in Mathematics. Springer, 1971.

[van Leeuwen, 1990] Jan van Leeuwen, editor. Handbook of Theoretical Com-puter Science, volume B : Formal Models and Semantics. Elsevier, Ams-terdam, 1990.

141

Index

Πr, 102Σ, 99Σnr, 101Σr, 101Terms

Lr, 101

αRM , 75Lr, 100ρ(π), 103`, 28

FmlLr , 102

accessability relation, 103annotation, 75antecedent, 109assignment, 27assignment rule, 113, 130

before-after-predicate, 26black box, 52box operator, 77branch, 110branching rule, 115

clauses, JML-, 43closed branch, 110, 112complete precondition, 46conclusion, 109conditional expression, 60conditional term, 95constant, 100constant symbols, 84

context, 26, 66root, 66

deadlock, 29diamond operator, 77Dynamic Logic

formula, 102Kripke structure, 103terms, 102vocabulary, 99

event, 26feasible, 30

Event-B machine, 26expression

conditional, 60external variable, 77

feasible event, 30first-order structure, 86flexible term, 101formula

Lr, 102first-order, 85

functionnon-rigid, 99rigid, 99symbol, 84, 99

glue invariant, 31goal, 113greatest lower bound, 82

142

guard, 26

if then else rule, 115induction rule, 119invariant, 26, 79

glue, 31

JMLclauses, 43ensures, 43requires, 43

Kripke structure, 103DL∼, 103

location, 51logic

predicate, 82logical part, 99

modal operator, 77, 98

non-rigid, 99non-rigid term, 101

odered pair, 21open branch, 110operator

box, 77diamond, 77modal, 77, 98

owner, 66

preconditioncomplete, 46

predicate symbols, 84premise, 109program

part, 99proof tree, 110

branch, 110closed, 110, 112

pure, 58

reachable state, 29refinement

simple, 31termination preserving, 36

relationaccessability, 103non-rigid, 99rigid, 99symbol, 99

restriction, 104rigid, 99rigid part, 103root context, 66rule

sequent, 109run, 29, 52

sequent, 109antecedent, 109succedent, 109

sequent calculusproof tree, 110

sequent rule, 109assignment, 113, 130branching, 115conclusion, 109induction, 119premise, 109sound, 109while, 117

signature, 84, 101simple refinement, 31sound

sequent rule, 109

143

state, 29, 103in Kripke structure, 103reachable, 29visible, 64

strong validity, 55structure

first-order, 86Kripke, 103

STU, 19substitution, 85

allowed for formula, 98principle, 98

succedent, 109symbol

constant, 84function, 84predicate, 84

syntaxabstract, 101concrete, 101

term, 85, 101conditional, 95dynamic logic, 101flexible, 101non-rigid, 101

termination preserving, 36trace, 29type, 99type correct, 71

universally valid, 109universe type system, 68update, 126

parallel, 129urelement, 19

validuniversally, 109

validitystrong, 55

variableassignment, 88, 103bound, 85external, 77free, 85logical, 120program, 120propositional, 84, 100typed, 99

`, 28visible state, 64vocabulary, 99

logical part, 99program part, 99

weakly pure, 58while rule, 117world, 103

144

i12pschmitt/FSS/FormSpec.pdf · 4 Introduction to Dynamic Logic 74 4.1 A Motivating Example . . . ....

Documents

Transcript of i12pschmitt/FSS/FormSpec.pdf · 4 Introduction to Dynamic Logic 74 4.1 A Motivating Example . . . ....