Sémantique Axiomatique ou Logique de Hoare - Ensiie

Sémantique Axiomatique ou 

Logique de Hoare 

C. Dubois 

ENSIIE 

(ENSIIE) Hoare 1 / 52

Sémantique axiomatique (logique de Hoare) 

Pour les langages impératifs 

Sémantique orientée vers la preuve de programmes 

Avec cette méthode sémantique, un programme est vu comme un 

transformateur de propriétés logiques (comme la sémantique des 

substitutions généralisées de B). 


Le langage 

Syntaxe (abstraite) d’un “petit” langage impératif appelé 

communément WHILE : 

Expressions 

a ::= n | x | a + a | a ∗ a | a − a | a ÷ a 

Conditions 

b ::= true | false | a = a | a ≤ a | . . . 

Commandes/instructions 

c ::= skip | x := a | c; c | if b then c else c | while b do c 


Triplets de Hoare 

triplet de Hoare : {P} i {Q} avec P, Q des assertions logiques et i une 

instruction 

P est appelée la précondition, Q la postcondition. 

Elles constituent la spécification du programme. 

assertions logiques : formules du premier ordre, avec comme formules 

atomiques les expressions du langage de programmation 

Remarque importante : identification entre les variables du programme 

et les variables des assertions (si x est une variable du programme, au 

point de l’assertion, x signifie valeur de x en ce point) 

{P} i {Q} : lire 

si la propriété P est vraie pour les valeurs des variables du programme 

avant l’exécution de i et si l’exécution termine alors la propriété Q 

est vraie après l’exécution de i 

correction partielle 


Pour correction totale : autre forme de triplet : 

[P] i [Q] : lire 

si la propriété P est vraie pour les valeurs des variables du programme 

avant l’exécution de i alors l’exécution termine et la propriété Q est 

vraie après l’exécution de i 

Correction totale = correction partielle + preuve de terminaison 


Dans la suite, nous considérerons la correction partielle 

Pourquoi ne pas insister sur la terminaison ? 

Dans certains on ne veut pas la terminaison 

On simplifie le raisonnement 

Si nécessaire, on peut prouver la terminaison séparément. 


Exemple de spécification et de programme (Fact) 

{x = n ∧ n > 0} 

y := 1 ; 

while not(x = 1) do (y := y * x ; x := x - 1) od 

{y = n! ∧ n > 0} 

Ici n est variable logique (elle permet de se référer à la valeur initiale 

de x) 


** 

* @param a an integer 

* @returns integer square root of a 

**/ 

int root (int a) { 

int i = 0; 

int k = 1; 

int sum = 1; 

while (sum

Spécification de root 

1 root comme une fonction partielle 

Precondition : a ≥ 0 

Postcondition : i ∗ i ≤ a < (i + 1) ∗ (i + 1) 

2 root comme une fonction totale 

Precondition : true 

Postcondition : 

(a ≥ 0 ) ⇒ i*i ≤ a < (i+1)*(i+1) 

∧ 

(a < 0 ⇒ i=0) 


Un état (mémoire) d’un programme associe une valeur à chaque 

variable du programme. Un état peut être vu comme une fonction des 

variables vers les valeurs (ici entières). 

z := 0; 

x := 1; 

y := 2; (1) 

z := x + y; (2) 

Au point de programme (1), l’état σ 1 est {z ↦→ 0; x ↦→ 1; y ↦→ 2} 

Au point de programme (2), l’état σ 2 est {z ↦→ 3; x ↦→ 1; y ↦→ 2} 


On dit qu’un état satisfait une assertion P quand l’interprétation de P 

est vraie lorsque les variables libres de P ont leur valeur courante 

(dans l’état). 

z := 0; 

x := 1; 

y := 2; (1) 

z := x + y; (2) 

En (1), l’assertion z ≥ x est fausse, 

En (2), l’assertion z ≥ x est vraie. 


Quelques triplets de Hoare valides 

{true} x := 5 { x=5 } 

{ x = y } x := x + 3 { x = y + 3 } 

{ x > 0 } x := x * 2 { x > -2 } 

{ x=a } if (x < 0) then x := -x else skip { x=abs(a) } 

Mais {x0 } n’est pas valide. 


Logique de Hoare 

Langage d’assertions + ensemble de règles de déduction (règles 

d’ingérence) sur les triplets 

Les règles s’utilisent comme des règles d’inférence de logique. 

Pour montrer qu’un triplet est dérivable, on doit construire un arbre de 

dérivation de racine le triplet à démontrer et en appliquant les règles 

d’inférence. 

1 règle par construction du langage + 2 règles logiques 


Le langage d’assertions 

Ici le langage des prédicats (logique du 1er ordre). 

P ::= b|P ∧ P|P ∨ P | ¬P|P ⇒ P|∀x.P|∃x.P 

Toutes les expressions booléennes du langage impératif sont des 

assertions 

Mélange des variables du programme et des variables logiques. 

Implicitement les variables prennent des valeurs entières 

On dispose d’une sémantique pour ce langage d’assertions 


Les règles d’inférence 

{P}skip{P} (skip) 

{P ∧ e}i 1 {Q} {P ∧ ¬e}i 2 {Q} 

{P}if e then i 1 else i 2 {Q} 

(if ) 

{P[x → e]}x := e{P} (aff ) 

{P}i1{Q} {Q}i2{R} 

(seq) 

{P}i1; i2{R} 

{I ∧ e}i{I} 

{I}while e do i{I ∧ ¬e} (while) 

⊢ P ⇒ P ′ {P ′ }i{Q} 

(consG) 

{P}i{Q} 

{P}i{Q ′ } ⊢ Q ′ ⇒ Q 

(consD) 

{P}i{Q} 


The rule for the empty statement 

{P}skip{P} 

skip does not change the state .... 


The rule (axiom) for the assignment statement 

{P[x ← e]}x := e{P} 

P[x → e] : it is the formula P where all the free occurrences of x 

are replaced by e. 

e.g. x > 1[x ← x + 1] is x + 1 > 1. 

Assignments change the state so we expect Hoare triples for 

assignments always to reflect that change. 

The meaning of this rule is clearer when read from right to left. 

Intuition : 

If we want x to have some property Q after the assignment, then 

that property must hold for the value (e) being assigned to x 

before the assignment is executed. 

{(x +1) > 5} x := x+1 {x > 5} is an instance of the assignment 

axiom 


The rule for the sequence 

Imperative programs consist of a sequence of statements, affecting the 

store one after the other. 

{P}i1{Q} {Q}i2{R} 

{P}i1; i2{R} 

Instance example : 

{x > 2}x := x + 1{x > 3} {x > 3}x := x + 2{x > 5} 

{x > 2}x := x + 1; x := x + 2{x > 5} 


Exercice 

temp := x; 

x:= y; 

y := temp 

Let P this program. 

Prove using the Hoare’s rules that 

is valid. 

{x = a ∧ y = b}P{x = b ∧ y = a} 

The standard approach consists in working backwards through the 

code. 

How ? Answer : a derivation tree or a more linear presentation 


The rule for the conditional statement 

{P ∧ cond}i 1 {Q} {P ∧ ¬cond}i 2 {Q} 

{P}if cond then i 1 else i 2 {Q} 

When a conditional is executed, either i 1 or i 2 is executed. 

Therefore, if the conditional is to establish Q, both i 1 and i 2 must 

establish Q. 

Similarly, if the precondition for the conditional is P, then it must 

also be a precondition for the two branches i 1 and i 2 . 

The choice between i 1 and i 2 depends on evaluating cond in the 

initial state, so we can also assume cond to be a precondition for 

i 1 and ¬cond to be a precondition for i 2 . 


Suppose we wish to prove : 

{x > 2}if x > 2 then y := 1 else y := −1{y > 0} 

The proof rule for conditionals suggests we prove : 

Simplifying : 

{x > 2 ∧ x > 2}y := 1{y > 0} 

{x > 2 ∧ ¬(x > 2)}y := −1{y > 0} 

{x > 2}y := 1{y > 0} (1) 

{false}y := −1{y > 0} (2) 

For subgoal (1) the assignment axiom tells us that 

{1 > 0}y := 1{y > 0} 

For subgoal (2) the assignment axiom tells us that 

How to go on ? 

−→ we need logical rules 

{−1 > 0}y := −1{y > 0} 


Logical rules consG and ConsD 

A condition P is said stronger than Q in the cases where P ⇒ Q. 

Similarly Q is weaker than P. 

P ⇒ P ′ {P ′ }i{Q} 

{P}i{Q} 

(consG) 

It is safe to make a pre-condition more specific (stronger). This rule 

allows for strengthening pre-conditions 

An instance : 

(x = 4) ⇒ (x > 2) {x > 2}x := x + 1{x > 3} 

{x = 4}x := x + 1{x > 3} 


{P}i{Q ′ } Q ′ ⇒ Q 

(consD) 

{P}i{Q} 

It is safe to weaken a post-condition so it says less. This rule allows for 

weakening post-conditions 

An instance : 

{x > 2}x := x + 1{x > 3} (x > 3) ⇒ (x > 1) 

{x > 2}x := x + 1{x > 1} 


Come back to the conditional example 

To end the proof we can use twice the logical rule. 

Let us detail the proof ! 

From x > 2 ⇒ 1 > 0 (valid formula why ?) and 

from {1 > 0}y := 1{y > 0} 

we can deduce (with the logical rule on preconditions) 

{x > 2}y := 1{y > 0} (1) 

and also from false ⇒ (−1 > 0) (valid ! why ?) and from 

{−1 > 0}y := −1{y > 0} 

we can deduce (with the logical rule on preconditions) 

{false}y := −1{y > 0} (2) 

Altogether we obtain an inference tree (or derivation tree) that sums up 

the demonstration and the way we have reasoned. 


The rule for the loop 

I is called the loop invariant. 

{I ∧ cond}i{I} 

{I}while cond do i{I ∧ ¬cond} 

I remains true each time around the loop (but not necessarily 

during execution of the loop body) 

If the loop terminates the control condition must be false, so 

¬cond appears in the post-condition. 

In the premise of the rule, the body of the loop i is only executed if 

cond is true, so it appears in the pre-condition. 


Exercice 

Let L the following piece of code : 

while (x

Exercice 

Let L the following piece of code : 

while (i != n) do 

i:=i+1; 

s:=s+(2*i-1) 

Check s = i ∗ i is an invariant for L ! 


And now let’s prove a program ! 

Program (with specification) : 

{ TRUE } 

i:=0; 

s:=0; 

while (i != n) do 

i:=i+1; 

s:=s+(2*i-1) 

{ s=n*n } 

(The sum of the first n odd numbers is n 2 ) 


Exercice 

On peut montrer : 

- {x = n ∧ n > 0} y := 1 {x = n ∧ n > 0 ∧ y = 1} 

- {x = n ∧ n > 0 ∧ y = 1} 

while not(x = 1) do y := y * x ; x := x - 1 od 

{y = n! ∧ n > 0} 

et conclure 

{x = n ∧ n > 0} 

y := 1 ; while not(x = 1) do y := y * x ; x := x - 1 od 

{y = n! ∧ n > 0} 


Quelques remarques et questions sur les règles de Hoare 

Pour la plupart, règles dirigées par la syntaxe 

☹ Quand appliquer la règle de la conséquence ? 

☹ Comment trouver les invariants ? 

☹ Comment prouver les implications de la règle de conséquence ? 

Comment la démonstration automatique ou assistée entre-t-elle 

en jeu ? 


Exercice 

Démontrer que pour P et pour tout i, on {P} i {true} 

Vérifier en utilisant les règles de Hoare que {P} while true do c {Q} 

est dérivable pour tout P, Q et c. 


Correction des règles 

Les règles de Hoare sont correctes : tout triplet dérivable est valide. 

Plus formellement, on prouve la correction par rapport à la sémantique 

opérationnelle du langage (voir plus tard, transparents ISL) 


Plus faible précondition - Weakest Precondition 

But : automatiser des preuves en logique de Hoare 

Définition (Plus faible précondition) 

Soit i un programme et Q une formule (assertion). On notera WP(i, Q) 

la plus faible précondition telle que si i termine, alors i termine dans un 

état qui satisfait Q 

C’est une précondition qui amène à Q {WP(i, Q)}i{Q} 

C’est la plus faible : toute précondition qui amène à Q est plus forte 

(elle implique donc la plus faible) 

Pour tout prédicat P, si {P}i{Q} alors P ⇒ WP(i, Q) 

Théorème (correction partielle avec WP) 

Pour prouver {P}i{Q} il suffit de prouver P ⇒ WP(i, Q). 


Calcul de WP 

Calcul de WP(i,Q) (c’est un prédicat) : (défini par induction sur la forme 

de l’instruction) 

WP(skip, Q)=Q 

WP(x :=e,Q) = Q[x/e] 

WP(i1 ;i2,Q) = WP(i1,WP(i2,Q)) 

WP(if e then i1 else i2,Q) = (e ⇒ WP(i1,Q)) ∧ (¬ e ⇒ WP(i2,Q)) 

Rappel : Q[x/e] désigne la formule Q dans laquelle on a remplacé 

toutes les occurences libres de x par e. 

WP(x :=x+y, x = 2 ∗ y)= x + y = 2 ∗ y 


Exercice : - Calculer WP(x :=x+1 ; y :=y-1, x > y) 

=WP(x :=x+1 ; x > y − 1) = x + 1 > y − 1 

- Calculer WP(if (x>y) then x :=x-y else y :=y-x endif, x ≥ 0 ∧ y ≥ 0) 

=x > y ⇒ WP(x :=x-y ; x ≥ 0 ∧ y ≥ 0) ∧ 

¬x > y ⇒ WP(y :=y-x ; x ≥ 0 ∧ y ≥ 0) 

=x > y ⇒ (x − y ≥ 0 ∧ y ≥ 0) ∧ ¬x > y ⇒ (x ≥ 0 ∧ y − x ≥ 0) 

- Prouver le triplet suivant en utilisant le calcul de WP 

{x = x 0 }if pair(x) then x := x + 2 else x := x + 1{x > x 0 ∧ pair(x)} 

soit P = WP(.., x > x 0 ∧ pair(x)) = 

pair(x) ⇒ (x+2 > x 0 ∧pair(x+2))∧¬pair(x) ⇒ (x+1 > x 0 ∧pair(x+1)) 

Il reste à montrer que x = x 0 ⇒ P, ce qui est vrai. 


Pour la boucle : 

WP(while e do i,Q) = pas de formule simple ! 

En effet, while b do i est équivalent à if b then i ;while b do i else skip. 

WP(while b do i, Q) = WP(if b then i ;while b do i else skip, Q) 

= b ⇒ WP(i, WP(while b do i, Q)) ∧ ¬b ⇒ Q) 

Equation récursive (on sait la résoudre dans la théorie des domaines 

mais ce n’est pas simple ! ! ! !) 

Impossible à calculer en général, et pas utilisable en pratique 

Y aurait-il quelque chose de plus simple à calculer et utilisable 

automatiquement ? 

⇒ Réponse = conditions de vérification 


Programme annoté et Conditions de vérification 

On part d’un programme annoté (invariant de boucle et spécifications 

des fonctions) 

On note VC(i,Q) la condition de vérification de i pour l’assertion Q 

(postcondition). 

VC(i,Q) plus forte que WP(i,Q) 

mais heureusement on a : 

pour P ∈ Pre(i, Q), P ⇒ VC(i,Q) et VC(i,Q) ⇒ WP(i,Q) 

avec Pre(i, Q)=l’ensemble des assertions R telles que {R}i{Q} 


Traditionnellement VC est calculé en arrière (en remontant le 

programme) : 

cette technique fonctionne bien avec du code structuré 

on peut aussi faire le calcul en avant 

◮ ça marche aussi avec du code non structuré, ex. assembleur 

◮ ce calcul utilise la technique de l’évaluation symbolique (cf cours de 

test 2A) 

VC : même calcul que précédemment pour WP sauf pour la boucle : 

l’invariant est donné 

Le résultat de VC est un prédicat. Les constructions du langage ont 

disparu. Il peut être confié à n’importe quel prouveur. Voir par exemple 

l’approche multi-prouveur de Frama-C/Why. 


VC(skip, Q)=Q 

VC(x :=e,Q) = Q[x/e] 

VC(i1 ;i2,Q) = VC(i1,VC(i2,Q)) 

VC(if e then i1 else i2,Q) = (e ⇒ VC(i1,Q)) ∧ (¬ e ⇒ VC(i2,Q)) 

VC(while e do invariant Inv i ,Q) = 

Inv 

(l’invariant est vérifié à l’entrée de la boucle) 

∧(∀x 1 . . . x m .Inv ∧ e ⇒ VC(i, Inv)) 

(l’invariant est préservé par une itération) 

∧(¬e ⇒ Q) 

La postcondition est satisfaite lorsque la boucle termine 

(x 1 , . . . x n sont les variables modifiées dans i) 

On pose : 

VC’({P} i {Q}) = P ⇒ VC(i,Q) 


Exemple : retour sur le programme fact 

On prend pour invariant de boucle l’assertion 

y ∗ x! = n! ∧ n > 0 ∧ x > 0. Elle est notée Inv ci-dessous. 

VC’({x = n ∧ n > 0} Fact {y=n ! ∧n > 0})= 

x=n ∧ n>0 ⇒ VC(y :=1 ;while ..., y=n ! ∧n > 0) = 

x=n ∧ n>0 ⇒ VC(y :=1, VC(while ..., y=n ! ∧n > 0)) = 

x=n ∧ n>0 ⇒ VC(y :=1 ; Inv ∧ (∀ x, y. Inv ∧ not(x=1) ⇒ y*x*(x-1) !=n ! ∧ x-1>0 

∧ n>0) ∧ (¬not(x=1) ∧ Inv ⇒ y=n ! ∧ n>0)= 

x=n ∧ n>0 ⇒ (Inv[y ← 1] ∧ (∀ x, y. Inv ∧ not(x=1) ⇒ y*x*(x-1) !=n ! ∧ x-1>0 ∧ 

n>0) ∧ (¬ not(x=1) ∧ Inv ⇒ y=n ! ∧ n>0)[y← 1]) = 

x=n ∧ n>0 ⇒ ((1*x !=n ! ∧ x>0 ∧ n>0) ∧ (∀ x, y. Inv ∧ not(x=1) ⇒ 

y*x*(x-1) !=n ! ∧ x-1>0 ∧ n>0) ∧ (¬not(x=1) ∧ 1*x !=n ! ∧ x>0 ∧ n>0 ⇒ 1=n ! 

∧ n>0)) 

La formule est grosse mais elle se décompose en petits morceaux qui 

peuvent se démontrer séparément. 


VC peut être adapté pour prouver l’arrêt d’une boucle si celle-ci est 

annotée par un variant (correction totale) 

VC(while e do Invariant Inv, Variant V i ,Q) = 

Inv 

∧(∀x 1 . . . x m .Inv ∧ e ⇒ VC(i, Inv)) 

∧(¬e ⇒ Q) 

∧(Inv ⇒ V ∈ N) 

Le variant est une quantité positive 

∧(Inv ∧ e ∧ V = V 0 ⇒ VC(i, V < V 0 )) 

... qui décroit strictement au cours d’une itération 

(x 1 , . . . x n sont les variables modifiées dans i) 


Générateur de condition de vérification VC et triplet de Hoare 

On vérifie que {VC(i, Q)}i{Q} 

ce qui signifie, informellement, VC(i,Q) est une précondition qui 

permet d’atteindre Q au final. 

Démonstration : par induction sur i (essayez !) 

Théorème fondamental : 

Si on peut prouver la condition de vérification générée par VC’({P} 

i {Q}) alors le triplet est dérivable (i.e. on a {P} i {Q}) 

Démonstration : elle se fait par induction sur i en montrant qu’il 

existe une dérivation dont les conditions d’applicabilité sont 

exactement celles calculées par VC({P} i {Q}). 

(essayez !) 


Grâce aux programmes annotés et à VC, on obtient une méthode 

réaliste pour faire de la preuve de programmes impératifs : 

1 Ecrire un programme contenant nécessairement des assertions 

sur les boucles et (éventuellement) des assertions sur les points 

difficiles de la preuve 

2 Transmettre ce code annoté à un outil qui engendre les conditions 

de vérification (i.e. qui implante la fonction VC ou VC’) 

3 Prouver ces conditions de vérification (de préférence avec un 

prouveur automatique (simplify, Z3, Zenon par exemple) ou 

interactif (Coq, Isabelle) par exemple) 


Pour aller plus loin sur les conditions de vérification : 

Les conditions de vérification sont conservées après une 

optimisation à la compilation 

Elles peuvent servir pour vérifier la correction d’une optimisation. 

Utilisables aussi bien sur du code source et du code bas niveau 

Conservation des obligations de preuve entre JML/Java et 

BML/bytecode Java 

Gilles Barthe, Benjamin Grégoire, Mariela Pavlova : Preservation 

of Proof Obligations from Java to the Java Virtual Machine. IJCAR 

2008 : 83-99 


De nombreux travaux ont fait suite à la logique de Hoare originale, 

pour étendre le formalisme et résoudre des difficultés, par exemple : 

Avoir des effets de bord dans les expressions. 

Traiter l’appel de sous-programmes. 

Prouver la terminaison des programmes (terminaison des boucles 

while). 

Supporter les break, continue, les exceptions 

Manipuler des structures de données complexes : tableaux, 

structures, etc. 

Manipuler les pointeurs : logique de séparation 

Travailler sur des entiers bornés, et vérifier le non-débordement 

des opérations sur les entiers. 


Les assertions à la Hoare sont fortement utilisées dans les outils 

et langages pour les méthodes formelles. 

La notion de contrat (Eiffel, JML) est inspirée des assertions à la 

Hoare ⇒ obligations pour les méthodes appelantes et les 

méthodes appelées. 

L’intégration de la vérification des assertions au processus de la 

compilation donne naissance à ce que l’on appelle les 

compilateurs certifiants (certifying compilers) 

Plus largement les assertions servent à spécifier, vérifier, tester 


TP : utilisation du plugin Jessie de Frama-C 

Frama-C : plateforme développé par le CEA pour la vérification de 

programmes C (analyse statique, preuve déductive ...) 

www.ensiie.fr~/dubois/ISL10/JessieTP.html 


Quelques mots sur Jessie 

Programmes C + annotations ACSL 

ACSL (Ansi C specification language), langage permettant de 

spécifier le comportement des programmes C (inspiré de JML, 

langage d’annotations pour les programmes Java) 

Langage du 1er ordre, syntaxe à la C 

Permet d’écrire des contrats (requires, ensures), de mettre des 

assertions dans le code (assert) 

Correction totale : invariant, variant dans les boucles 

⇒ Génération d’obligations de preuve 


Jessie utilise Why, générateur d’obligations de preuve (J.C Filliatre) 

(Jessie successeur de Caduceus) 



Les vérifications de Jessie 

vérifications de sûreté (safety checks) 

◮ Mémoire : validité des accès à la mémoire 

◮ Entiers : absence d’overflows, validité des opérations sur les entiers 

(absence de division par 0) 

vérifications fonctionnelles 

◮ invariants de représentation (par ex. alpha[i] et alpha_inv[i] 

cohérents) 

◮ invariants du modèle (α0 involution, α 1 permutation) 

◮ comportement des opérations 


Vérification ’Safety’ 

Modèle mémoire 

Un pointeur p est représenté par une paire (adresse de base, 

décalage dans le bloc) 

valid (p) ≡ p ≠ null ∧ 0 ≤ offset(p) < blocklength(p)

Sémantique Axiomatique ou Logique de Hoare - Ensiie

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?