2009: j paul gibsont&msp-csc 4504 : langages formels et applications event-b/proof.1 csc 4504 :...

2009: J Paul Gibson T&MSP-CSC 4504 : Langages formels et applications Event-B/Proof.1

CSC 4504 : Langages formels et applications

(La méthode Event-B)

J Paul Gibson, A207

[email protected]

http://www-public.it-sudparis.eu/~gibson/Teaching/Event-B/

Proof

http://www-public.it-sudparis.eu/~gibson/Teaching/Event-B/Proof.pdf

Thanks to Jean-Raymond Abrial


Language of Predicates


Language of Predicates: Classical Results


Language of Predicates: Refining the language


Predicates & Expressions

•A Predicate is a formal text that can be PROVED

•An Expression DENOTES AN OBJECT.

•A Predicate denotes NOTHING.

•An Expression CANNOT BE PROVED

•Predicates and Expressions are INCOMPATIBLE.


VARIABLES, PROPOSITIONS AND PREDICATES


WHAT CAN WE DO WITH A PREDICATE ?


SUBSTITUTION


UNIVERSAL QUANTIFICATION


Well-formedness

Each occurrence of an identifier in a formula (that is a predicate or an expression)can be either free or bound.

Intuitively, a free occurrence of an identifierrefers to a declaration of that identifier in a scope outside of the formula,

while a bound occurrence corresponds to a local declaration introduced by a quantifierin the formula itself.

For a formula to be considered well-formed, we ask that, beyond being syntacticallycorrect, it also satisfies the two following conditions:

1. Any identifier that occurs in the formula, should have only free occurrencesor bound occurrences, but not both.2. Any identifier that occurs bound in the formula, should be bound in exactlyone place (i.e., by only one quantifier).


Well-formedness: checking automatically

There are pages of rules for checking this on the abstract syntax of Event-B expressions.

For example:


Type Checking

Type checking consists of checking, statically, that a formula is meaningful ina certain context.

For that, we associate a type with each expression that occurs in a formula.

This type is the set of all values that the expression can take.

Then, we check that the formula abides by some type checking rules.Those rules enforce that the operators used can be meaningful.

Unfortunately, type checking, as it is a static check, cannot by itself prove that a formula is meaningful.

For some operators, like integer division, we will also need to checksome additional dynamic constraints (e.g., that the denominator is not zero).


Type Checking

A type denotes the set of values that an expression can take.

Moreover, we want this set to be derived statically, based on the form of the expression and the context in which it appears.

As a consequence, a type can take one of the three following forms:


Type Checking

A type variable is a meta-variable that can denote any type.

We shall use lowercase Greek letters to denote type variables.

A typing environment represents the context in which a formula is to be type checked. A typing environment is a partial function from the set of all identifiers to the set of all possible types. For instance, the typing environment


Type Checking - Rules

There are pages of rules for checking this on the abstract syntax of Event-B expressions.

For example:


Type Checking – Rules (Example)


Dynamic Checking

Static checks are not enough to ensure that a formula is meaningful.

For instance, expression x÷y passes all the static checks described above, nevertheless it is meaningless if y is zero.

The aim of dynamic checking is to detect these kind of meaningless formulas.

This is done by generating (and then proving) some well-definedness lemma.


Dynamic Checking (Well-definedness WD)

WD lemmas for predicates



WD lemmas for binary and unary expressions



WD lemmas for other expressions


Inference Rules: for (automated) reasoning

“Ich wollte zunächst einmal einen Formalismus aufstellen, der dem wirklichen Schließen möglichst nahe kommt. So ergab sich ein „Kalkül des natürlichen Schließens”.

(“First I wished to construct a formalism that comes as close as possible to actual reasoning. Thus arose a "calculus of natural deduction".)

— Gentzen, Untersuchungen über das logische Schließen (Mathematische Zeitschrift 39, pp.176-210, 1935)



nom

Antécédent

Conséquent

TabularNotation



Les règles d’inférence pour ^



Les règles d’inférence pour ¬

règles de contradiction ( “reductio ad absurdum”)



Une preuve ( à la main)


Principe général d’un prouveur de prédicats

• On procède par induction sur la syntaxe du but P d’un séquent HYP |- P.règles appliqué en arrière (backward).

• On ne monte en hypothèse (utilisation de DED) que des– prédicats simples (pas de ^, =>, . . .) ou– prédicats quantifiés universellement (∀) et normalisés

• on s’arrête avec un axiome ou sur HYP |- FAUX en cherchant une contradictiondans les hypothèses.

• sinon on relance une preuve en cherchant de nouvelles instanciations pour lesvariables des prédicats quantifiés (filtre + unification).


Règles d’un prouveur de prédicats (génériques)

opération générique


Règles d’un prouveur de prédicats (^)

générique

Instantiation with /\


Règles d’un prouveur de prédicats (=>)

générique

Tactique gagnante: On utilise =>4 en dernier

=>


Règles d’un prouveur de prédicats (not)

générique


Règles d’un prouveur de prédicats (les axioms)


Les prédicats quantifiés


Floyd Hoare Logic is a method of reasoning mathematically about imperative programs.

It is the basis of most mechanized program verification systems

Tony Hoare introduced the notation {P} C {Q}, called a partial correctness specification for specifying what a program does, where:

•C is a program (code) from the programming language whose programs are being specified •P and Q are conditions on the program variables used in C

Event-B is heavily influenced by Floyd-Hoare logic


Meaning of Hoare's Notation

{P} C {Q} is true if

whenever C is executed in a state satisfying P and if the execution of C terminates then the state in which C terminates satisfies Q

Example: {X = 1} X := X + 1 {X = 2}

P is the condition that the value of X is 1 Q is the condition that the value of X is 2 C is the assignment command X := X + 1 (i.e. `X becomes X + 1')

{X = 1} X := X + 1 {X = 2} is clearly true {X = 1} X := X + 1 {X = 3} is clearly false

BE CAREUL with partial correctness:{X = 1} WHILE true do skip {Y=3} is true


Total Correctness

Informally: Total correctness = Termination + Partial correctness

Total correctness is the ultimate goal It is usually easier to show partial correctness and termination separately

Termination is usually straightforward to show, but there are examples where it is not, e.g.: no one knows whether the program below terminates for all values of X

WHILE X > 1 DO IF ODD(X) THEN X := (3 × X) + 1 ELSE X := X DIV 2

Where the expression X DIV 2 evaluates to the result of rounding down X/2 to a whole number


Specification can be Tricky

"The program must set Y to the maximum of X and Y" [True] C [Y = max(X, Y)]

A suitable program (C)?: IF X >= Y THEN Y := X ELSE SKIP

Another? IF X >= Y THEN X := Y ELSE SKIP

Or even? Y := X

WARNING: Later we will be able to prove that all these programs are "correct"

WHY?: The postcondition "Y = max(X, Y)" says "Y is the maximum of X and Y in the final state"


SKIP: possibly the simplest axiomatisation

Syntax: SKIP Semantics: the state is unchanged

The SKIP Axiom :

|- {P} SKIP {P}

It is an axiom schema P can be instantiated with arbitrary predicate calculus formulae (statements)

Instances of the SKIP axiom are:

|- {Y = 2} SKIP {Y = 2} |- {True} SKIP {True} |- {R = X + (Y × Q)} SKIP {R = X + (Y ×Q)}


Substitution Notation and assignment axiom: the most difficult axiomatisation

Define P [E/V ] to mean the result of replacing all occurrences of V in P by E •read P [E/V ] as `P with E for V ' •for example: (X + 1 > X)[Y + Z/X] = ((Y + Z) + 1 > Y + Z)

Think of this notation as the `cancellation law': V [E/V ] = E

which is analogous to the cancellation property of fractions: v × (e/v) = e

The Assignment Axiom |- {P [E/V ]} V := E {P}

Where V is any variable, E is any expression, P is any statement and the notation P [E/V ] denotes the result of substituting the term E for all occurrences of the variable V in the statement P .

Example:|- {X + 1 = n + 1} X := X + 1 {X = n + 1}

|- can be proven


Precondition Strengthening is a typical development step

Recall that |- S 1 , . . . , |- Sn

|-S means |- S can be deduced from |- S 1 , . . . , |- Sn

Using this notation, the rule of precondition strengthening is:

|- P => P’ , |-{P’} C {Q} |- {P} C {Q}


Postcondition Weakening

Just as the previous rule allows the precondition of a partial correctness specification to be strengthened, the following one allows us to weaken the postcondition:

|- {P} C {Q’}, |- Q’ => Q |- {P} C {Q}

The rules precondition strengthening and postcondition weakening are sometimes called the rules of consequence


Existential Quantification


Comparing the Quantification Rules


Classical Results


Refining our Language: Equality (with classical results)


Refining our Language: Set Theory


Basic Set Operator Memberships (Axioms)


Set Inclusion and Extensionality Axiom


Classical Results with Relation Operators

Relations (like r, q and p)between Sets(like S) containing elements (like a and b)


Applying a Function


Invariant Preservation


Invariant Preservation: the rules


Deadlock Freedom


Event interpretation for refinement proofs

The execution of this event is enabled whenever there exist some values x and y suchthat the guard P is true, then z is assigned x+y


Event interpretation – Example

This event is always enabled (there always exists a natural number x > 10)The result of the event is that z is assigned an arbitrary natural number greater than 10.The event is equivalet to


Refinement is used to transform an abstract machine into aconcrete machine which does the same computation, but possibly using a different data structure and/or different internal execution

can be refined (possibly) into

Also if in the abstract machine we have a nondeterministic event, then this could be refined into a deterministic one in the concrete machines :


Names of context proof obligations:


Names of machine proof obligations:


Names of refinement proof obligations:


Names of variant proof obligations:


Names of Witness proof obligations:


Names of Deadlock Freeness proof obligations:

At the moment, the deadlock freeness proof obligation generation is incomplete.

If you need it, you can generate it yourself as a theorem saying the the disjunction of the abstract guards imply the disjunction of the concrete guards.


The Automatic Post-tactic: Rewrite rules

The following rewrite rules are applied automatically in a systematic fashion from left to right either in the goal or in the selected hypotheses.


Automatic inference rules

The following inference rules are applied automatically in a systematic fashion at the end of each proof step. They have the following possible effects:

• they discharge the goal,• they simplify the goal and add a selected hypothesis,• they simplify the goal by decomposing it into several simpler goals,• they simplify a selected hypothesis,• they simplify a selected hypothesis by decomposing it into several simpler selected hypotheses.


Preferences for the Auto-proverThe auto-prover can be configured by means of a preference page, which can be obtained as follows:press the ”Window” button on the top tooolbar. On the coming menu, press the ”Preferences” button. On the coming menu, press the ”Event-B” menue, then the ”Sequent Prover’, and finally the ”Auto-Tactic” button. This yields the following window:


Interactive inference rules: through the red buttons in prover window



… many more

2009: j paul gibsont&msp-csc 4504 : langages formels et applications event-b/proof.1 csc 4504 :...

Documents