Formation à la Méthode B – Niveau 3

Formation B - niveau 3
la preuve avec l’Atelier B …
version 1.4 2005
1
La preuve avec l’Atelier B







Outils de preuve - Introduction
Preuve – Méthode générale
Preuve automatique - Utilisation
Prouveur interactif – visite guidée
Mise au point – Méthode générale
Phase de preuve formelle - Bases
Preuve - Administration
version 1.4 2005
2
Outils de preuve
Introduction
version 1.4 2005
3
Atelier B Main Tools
Modèles B
Type checker
B0 Checker
Translator
Proof Obligation Generator (POG ou GOP)
Final code
Prover
Demonstrations
version 1.4 2005
4
Fichiers de preuve
Obligations
de preuve (<component>.po)
Demonstrations
+ état de preuve (<component>.pmi)
Règles
utilisateur (<component>.pmm)
Règles
utilisateur projet (PatchProver)
version 1.4 2005
5
Outils de preuve
Mécanismes de preuve
Prouveur automatique
Base de Règles
Interpréteur de commandes
Prouveur arithmétique
Prouveur Interactif
Set Solver
Prouveur de Prédicats
version 1.4 2005
Solver d’inégalités arithmétiques
6
Prouveur automatique : structure
STATIQUE
Mécanismes de preuve
Selection
Base de Règles
DYNAMIQUE
Pile d’hypothèses
Deduction
But courant
Une fois qu’une hypothèse est montée dans la pile, elle
ne peut plus être modifiée.
version 1.4 2005
7
LA PREUVE
Méthode Générale
version 1.4 2005
8
Méthode générale
Ne pas prouver trop tôt.
Exemple :
• composant avec 300 PO non prouvées
• PO numéro 298 fausse : détecte un invariant incorrect
• Temps nécessaire pour démontrer les 297 premières PO :
5 jours
• Impact de la correction de l’invariant :
modification de toutes les PO
 Perte de 5 jours de travail
Faire une phase de mise au point avant la preuve formelle
version 1.4 2005
9
La mise au point
But : TROUVER LES PO FAUSSES
Si toutes les PO étaient toujours justes, il serait inutile de
faire la preuve...
En moyenne, 10% de PO fausses sur un projet neuf.
version 1.4 2005
10
La mise au point
Le risque en phase de mise au point :
• passer trop de temps
• entamer des démonstrations complexes
Précautions :
• se donner un délai maximum par PO (10 minutes)
• se donner une limite en nombre de commandes
de preuve (5 commandes)
version 1.4 2005
11
La phase de preuve formelle
Démontrer les PO restantes ;
Si découverte d’une PO fausse :
 repasser en mise au point.
En effet : si modification du composant,
d ’autres PO peuvent être devenues
fausses.
version 1.4 2005
12
Exemple de cycle de preuve
Un projet simple :
machine abstraite
Ecrire la machine abstraite
Preuve automatique
implantation
Mise au point machine (lecture PO non démontrées)
Ecrire l’implantation
Preuve automatique
Mise au point implantation (lecture PO non démontrées)
Preuve formelle de la machine et de l’implantation
version 1.4 2005
13
Les forces automatiques

Force rapide : légèrement plus rapide que la force 0, moins efficace


Force 0 : la force principale (70%, Tmoyen= 10 secondes)



pour composants très gros
à employer en premier
à employer pour la preuve interactive
Force 1 : procédé de simplification de chaque hypothèse avec les
précédentes (normalisation très poussée)
(+1%)

Force 2 : + génération d'hypothèses dérivées
(+2%)

Force 3 : + preuves par tentatives
(+1%)
version 1.4 2005
14
La documentation
Autour du poste de preuve :

Manuel de référence du langage B
 compréhension



B-Book
des symboles, propriétés
 catalogue
de propriétés mathématiques
 référence
des commandes de preuve
Manuel de référence du prouveur
Manuel utilisateur du prouveur
 principes
version 1.4 2005
et méthodes d'emploi
15
Ecran poste de preuve
Prouveur
interactif


Et...
Visualisation
des
composants
en cours de
preuve
Preuve d'une machine : visualiser la machine et ses dépendances
(SEES, INCLUDES)
Preuve d'une implantation : visualiser



l'implantation
sa spécification
les machines importées concernées
version 1.4 2005
16
Preuve automatique
utilisation
version 1.4 2005
17
Enchaînement des forces

Dans le projet BASES, ajoutez le composant Ressources.mch
(composant issu du premier exercice de la formation Niveau 1)

Lancez la preuve en force 2






contrôle de type, PO génération
preuve en force 0 : tout est prouvé sauf 3 PO
preuve en force 1 : aucune PO déchargée
preuve en force 2 : long, 1 PO déchargée
Les forces 0, 1, 2 et 3 sont chaînées
Les forces élevées (1) peuvent être longues, mais peuvent éviter
une démonstration interactive
version 1.4 2005
18
Conservation forces essayées

Relancez la preuve en force 0, puis en force 1, puis en force 2 :



aucune preuve n'est réessayée
Le prouveur mémorise les forces essayées pour chaque PO, ici il sait
que les deux PO restantes ne sont pas déchargées par les forces de
0 à 2.
Le prouveur conserve l'état de preuve : seules les PO non prouvées
sont concernées.
NOTA : raz à la prochaine modification « effective » (sauf
espaces et commentaires)
version 1.4 2005
19
Conservation des forces

Sélectionnez Ressources et utilisez l'option Unprove du menu
Prove


Lancez la preuve en force 0 :


Ne fait rien, aucune PO n'étant déchargée en force 1
Lancez la preuve en force 2 :


les seules PO qui sont reprouvées sont celles qui sont
déchargées en force 0, le prouveur n'affiche que des +
Lancez la preuve en force 1 :


après confirmation, toutes les PO du composant redeviennent
non prouvées.
La seule PO faite est celle qui aboutit en force 2
L'historique des forces est conservé.
version 1.4 2005
20
Le "Merge"

Modifiez le composant Ressources.mch :


Relancez la preuve en force 0



seules les PO de l'opération modifiée n'ont pas gardé leur état prouvé
les 2 PO non prouvées dans les opération non modifiées sont
réessayées
Comparaison nouvelles PO / anciennes PO :
•

dans l'opération signaler_ressource_reparee, employez SELECT plutôt
qu'une intersection pour ne rendre disponible la ressource que si elle
était cassée ;
les PO de même but sous des hypothèses au moins aussi fortes
gardent leur état ;
Remise à zéro de l'historique des forces.
version 1.4 2005
21
Interruption preuve automatique

Ajoutez ou prouvez les composants b_res, equi, equi_1


Passez à la PO suivante : bouton « Next PO »





preuve longue sur equi_1, en force 3
amenez le curseur dans la zone d ’interruption : les boutons ne
sont plus grisés
appuyez sur « Next PO » : les boutons redeviennent grisés
l ’interruption est prise en compte : un - s ’affiche
les forces élevées peuvent boucler : nécessité d'interrompre
ATTENTION : la prise en compte d ’une interruption n ’est pas
forcément immédiate

parfois quelques dizaines de secondes (si proche saturation)
version 1.4 2005
22
Démonstration interactive

Ouvrir en preuve interactive le composant Ressources

Aller sur la première PO non prouvée


Taper pp(10) : appel du prouveur de prédicats avec un
temps maximum de 10 secondes
la démonstration interactive est sauvegardée lorsqu'on
quitte la PO.
version 1.4 2005
23
Le rejeu


Sur le composant Ressources, faire Unprove
Lancer Prove Replay




dans une seule passe : toutes les PO sont passées en revue
celle qui étaient prouvée sont rejouées avec la démonstration
(automatique ou interactive) qui avait réussi. Le résultat est indiqué ( +
ou - )
les PO qui n'étaient pas démontrées sont sautées (affichage de - )
Le rejeu permet de refaire uniquement les preuves réussies


pour retenter la même démonstration sur les PO qui ont perdu leur état
de preuve, suite à un merge (affaiblissement des hypothèses)
pour garantir les démonstrations après modification des règles
manuelles ajoutées
version 1.4 2005
24
Le rejeu : rééssai

Faire une modification qui change tout dans Ressource.mch :


Générer les obligations de preuve :


toutes les PO sont non prouvées, car le changement de nom
ne permet aucune correspondance avec les anciennes PO.
Lancer Prove Replay :



changer le nom de la variable disponibles : devient libres
on retrouve l'état de preuve précédent. En effet, les
démonstrations conviennent toujours malgré le changement
de nom.
En particulier : la démonstration faite avec pp est retrouvée
Prove Replay permet de réessayer les démonstrations après une
modification importante.
version 1.4 2005
25
Le prouveur interactif
Visite
version 1.4 2005
26
Visite de l'interface



Dans le projet BASES, ajoutez le composant
Ressources, démontrez le en force 0.
Lancez le prouveur interactif
allez sur la prochaine PO non prouvée.
version 1.4 2005
27
Fenêtre de situation
version 1.4 2005
28
Fenêtre de situation


Zone du nombre de PO non prouvées (devient vert si prouvé)
Zone de choix des PO




Zone d'état de la PO courante :





Menu de visualisation et d'accès aux PO
Menu d'entrées / sorties externes (accès à la base de
règles)
Help = manuel de référence
état actuel / sauvegardé
commandes exécutées
commandes sauvées
Boutons quit et interrupt
modes spéciaux : fonte mathématique ou affichage asynchrone
version 1.4 2005
29
La fenêtre de commande
version 1.4 2005
30
La fenêtre des hypothèses
version 1.4 2005
31
Les fenêtres commande et
hypothèses


La fenêtre de commande et la fenêtre d'hypothèses
n'apparaissent que si on est sur une PO
La fenêtre de commandes :




zone de but, devient vert si preuve
zone de commandes
avec Shift Bouton 3 souris : recherches
La fenêtre des hypothèses



dialogue de filtrage des hypothèses (Hypothesis filter)
avec Shift Bouton 3 souris : recherches
triple clic + Bouton 3 souris : saisie d'une hypothèse
version 1.4 2005
32
Disposition classique
premier plan facile
à commuter
hypothèses
visibles et
copiables
but et commandes
version 1.4 2005
33
La phase de mise au point
Méthode générale
version 1.4 2005
34
Méthode




Rechercher les PO fausses
Ne pas dépenser de temps en démonstration
Visualiser les composants en cours de preuve
Utiliser les fonctionnalités du prouveur pour l'examen
des PO
version 1.4 2005
35
Recherche d'hypothèses



Dans le projet BASES, ajouter Ressources0.mch, démontrer ce
composant en force 0
Ouvrir en preuve interactive, aller sur la première PO non prouvée
Taper mp


lancement du prouveur jusqu'à son point d'échec, a priori plus
simple que le but initial
exemple de recherches avec "SearchHyp" :




sh(disponibles) : recherche des hypothèses concernant cette
variable
sh(disponible _and rr) : hypothèses contenant disponibles et rr
sh(a=b) : hypothèses contenant une forme égalitaire. Les
variables à une lettre sont des "jokers"
sh(p,(a=b)) : hypothèses qui sont une égalité
version 1.4 2005
36
Examen d'une PO




Dans le composant Ressources0, aller sur la dernière PO non
prouvée (liberer_ressources.4)
dd(0) : montée et simplification des hypothèses, pour pouvoir
examiner le but seul
rp : (Reduce Po) examen des hypothèses ayant un symbole en
commun avec le but
rechercher une justification du but : ici

disponibles i cassees = 0

rr n'est pas élément de cassees
donc disponible u {rr} n'a aucun élément commun avec
cassees : but vrai.


Pendant le temps d'examen, on peut lancer pp (ici : succès)

si pas trop d'hypothèses
version 1.4 2005
37
Po fausse avec but complexe
Comment faire pour examiner une PO qui contient des expressions
complexes ?




Utiliser le prouveur pour simplifier l'expression
Si mauvaise simplification : employer dc (DoCases) pour se placer
dans un cas particulier
Si PO présumée fausse : dc pour essayer les valeurs de contreexemple
eh(var,val,AllHyp) (Equality in hypothesis) : pour remplacer var par
val dans toutes les hypothèses, pour détecter d'éventuelles PO
contradictoires
version 1.4 2005
38
Po fausse avec but complexe (2)

Exemple : visualiser les composants aig.mch et aig_2.imp



reprise du TP "aiguille" (formation N2) avec une programmation
plus synthétique
ajouter ces composants, prouver aig_2 en force 0
preuve interactive :






aller sur la prochaine PO non prouvée : but complexe
mp : preuve jusqu'au point d'échec : but toujours complexe
dc(m1, POSITION) : preuve par cas sur toutes les valeurs de m1 ;
pr : le premier cas est démontré ; pr : le deuxième cas bloque
la PO semble fausse. On passe en preuve par contradiction : cts
D'après les hypothèses : m1,m2,m3 = gauche,droite,gauche
convient, vérifier avec dc(m2 = droite) & mp & dc(m3 = gauche &
mp
eh(m1,gauche,AllHyp) & eh(m2,droite,AllHyp) &
eh(m3,gauche,AllHyp) & pr : toujours pas de contradiction, nous
avons probablement le contre-exemple.
version 1.4 2005
39
La simplification des expressions
Tout projet juste n'est pas forcément "raisonnablement" démontrable.

Redécouper un projet dont la preuve est complexe

ajout de niveaux de raffinement

découpage des opérations

ASSERT et ASSERTIONS

Mettre les expressions sous la forme rendue par le prouveur

Chercher les égalités littérales
version 1.4 2005
40
Pousser la preuve automatique

UNIQUEMENT sur de gros composants, et SANS
BLOQUER LE TRAVAIL DE MISE AU POINT




la nuit ou sur une autre machine !!!
Tenter les passes utilisateurs “connues”

mp & tp(Hyp)

dd(2) & pr & pr

pp(rp.0)

dd(0) & pp(rp.1)

pp (attention long !!!)
Tenter des passes utilisateur avec des démontrastions récupérées dans les versions précédentes
du composant / projet
Tenter des forces élevées (attention très long !!!)
version 1.4 2005
41
Utilisation d’assertions


Rappels : les assertions sont des prédicats écrits dans un composant B
et dont l'unique but est de faciliter la preuve du composant.
On distingue :


les assertions de la clause ASSERTIONS, qui sont globales à un
composant.
Elles doivent être déduites de l'invariant et des assertions
précédentes.
Elles sont utilisées comme hypothèses dans les PO d'opérations.
Les assertions des substitutions ASSERT, qui sont locales à une
opération.
Chaque assertion doit être prouvée en fonction des propriétés des
variables à l'endroit où elle est située dans l'assertion.
Elle est utilisée en hypothèse dans les PO d'opérations concernant
les substitutions situées après l'assertion.
version 1.4 2005
42
Utilisation d’assertions (2)

Les assertions de la clause ASSERTIONS

Exemple : machines Assertions et Assertions0 (avec et sans assertion)






examiner les différences entre ces 2 machines,
l'assertion est vraie car : une fonction strictement croissante est
injective
les ajouter dans le projet et lancer le prouveur en force 3,
statistiques : Assertions Assertions0
1 PO non prouvée
4 PO non prouvées
toutes les PO sont du même ordre de difficulté
Avantage : les assertions permettent de factoriser la preuve des opérations
d'un composant.
version 1.4 2005
43
Utilisation d’assertions (3)


Les assertions de la substitution ASSERT
Exemple : machine Assert et raffinements Assert_1 et Assert_0
(avec et sans assertion)






examiner les différences entre ces 2 raffinements,
l'assertion précise comment est raffiné le IF, le cas yy > 1
correspond au cas xx > 0 de la spécification,
les ajouter dans le projet et lancer le prouveur en force 0,
statistiques : Assert_1
Assert_0
1 PO non prouvée
2 PO non prouvées
toutes les PO sont du même ordre de difficulté
Avantage : les assertions permettent de faciliter la preuve d'une
opération.
version 1.4 2005
44
Phase de preuve formelle
Bases
version 1.4 2005
45
Les démonstrations
Du point de vue du prouveur, une démonstration est une suite de
commandes interactives.





Aller sur la PO obtenir_ressource.3 du composant Ressource0
Ouvrir dans un éditeur le fichier DemoRessL
Ouvrir la fenêtre "Extern Selection" du prouveur
Copier la ligne de démonstration de DemoRessL dans cette fenêtre
et presser "Paste"
Dans la fenêtre de commande du prouveur, taper Return

la démonstration importée s'exécute, et elle aboutit
version 1.4 2005
46
Les démonstrations (2)

La démonstration est visible dans la fenêtre des commandes
exécutées, indentée suivant l'arbre de preuve :
Force(0) & indication de la force employée
mp & on commence par mp
ah(disponibles-{rr}u(occupeesu{rr})ucassees ( 0..uu) &
pr &
premier but de ah : démontrer l'hypothèse
mp &
on continue sous cette hypothèse
ah(0..uu ( disponibles-{rr}u(occupeesu{rr})ucassees) &
mp &
ah(xx: disponiblesuoccupeesucassees) &
eh(disponiblesuoccupeesucassees) &
pr &
pr &
pr &
pr &
Next

Le contenu de cette fenêtre peut être copié dans un éditeur
version 1.4 2005
47
Les démonstrations (3)

Une telle démonstration peut aussi se représenter par un
arbre :


le n° de colonne devient le n° de ligne dans l'arbre
chaque commande est reliée aux commandes indentées
dessous
Force(0)
mp
ah(…)
pr
mp
ah(…)
mp
ah
eh(…)
pr
pr
pr
pr
version 1.4 2005
48
Utilisation de mp

mp en force 0 et 1 lance le prouveur sans les tactiques de preuve par
cas


Exemple





bénéficier des simplifications du prouveur sans risque de poursuivre
dans des cas dédoublés
ajouter la machine MiniPr, appeler le prouveur en force 3,
examiner la PO non prouvée, le but est simplifiable,
mp, dans le but l'expression 0..10 i {3} est simplifié en {3}
pp(rp.0) la PO est démontrée
Différence entre mp et pr


reprendre la démonstration en remplaçant mp par pr : re & pr &
pp(rp.0)
il reste à prouver not(vv = 3) y Q en fait le prouveur a fait deux cas
à cause de l'hypothèse vv = 3 y not(a = {uu}), c'est inutile ici
version 1.4 2005
49
Ajout d'hypothèse


Ajouter un intermédiaire de preuve quand on a l'intuition que cela
avance la preuve
Exemple






ajouter le composant AddHyp et lancer le prouveur en force 0
(attention : force 2 démontre…),
une PO n'est pas prouvée, faire dd(0),
la PO est vraie car ff est surchargée avec des éléments de ff,
donc le résultat de cette surcharge reste égal à ff,
le prouveur n'a pas l'idée de démontrer 0..5 r ff ( ff
faire ah(0..5 r ff ( ff) & pr & pr
la PO est démontrée
version 1.4 2005
50
Utilisation de pp (1)

Utiliser très préférentiellement ah(hypothèses existantes) & pp(rp.0) :



Pour ramener les hypothèses utiles dans le but :




ajout d ’hypothèses existantes pour les ramener dans le but
pp(rp.0) pour démontrer le sous lemme autonome ainsi formé
triple clic sur une hypothèse dans la fenêtre d ’hypothèses : sélection
de la ligne complète
clic bouton de droite : l ’hypothèse est cadrée
ah(<paste) et return
Former un sous lemme autonome à démontrer par pp :


à partir du but principal de la PO
pour démontrer un sous but intermédiaire
version 1.4 2005
51
Utilisation de pp (2)

Attention : éviter une utilisation de pp sans réduction d ’hypothèses sur un
composant appelé à évoluer



si le nombre d ’hypothèses dans le composant augmente : impact
direct sur la durée de l ’appel à pp
si temps maxi dépassé : échec preuve
Message « pp failed to prove » immédiat : erreur de contrôle de type


vérifier le terminal de contrôle : message « can ’t resolve (formule) »
éliminer (formule) du lemme à prouver :
 souvent une forme A-B, remplacer par -B+A si numérique
version 1.4 2005
52
Utilisation de pp (3)

Si échec pp :




le sous lemme contient des calculs, des cardinaux : renoncer !
le sous lemme contient des formes f(x) : ajouter x :dom(f)
très souvent : il manque une hypothèse f :A 2 B. Dans un raisonnement
intuitif, on utilise très souvent le caractère fonctionnel d ’une variable
sans s ’en rendre compte.
Utiliser vr (Verify Rule) : appel de pp pour vérifier une règle manuelle


Pour vérifier à l ’avance une règle à ajouter dans fichier.pmm
 souvent pp est plus efficace sur une règle isolée
Pour vérifier rapidement une règle utilisée dans le raisonnement intuitif
 ex : vr(Back, (f : A >+> B => f[E-F] = f[E]-f[F]))
version 1.4 2005
53
Ajout d'hypothèse guidé par une règle


Ajouter une hypothèse pour qu'une règle puisse s'appliquer
Reprenons l'exemple précédent (composant AddHyp)




faire re & mp,
chercher les règles pour transformer le but : sr(Rewr, (f + g == f))
la règle trouvée est :
SimplifyRelOveXY.6
binhyp(g ( f) &
binhyp(f : s 2 t) &
blvar(Q) &
Q\(g ( f)
y
(f + g == f)
on voit que l'hypothèse qui manque est 0..5 r ff ( ff
version 1.4 2005
54
Différence entre dd et dd(0)

Exemple





ajouter la machine DDZero et lancer le prouveur en force 0, une PO
fausse est engendrée (utilisée pour des raisons didactiques),
faire mp
puis dc(bool(not(uu = 0)) = FALSE)
observer les différences entre dd et dd(0) (faire dd puis ba & dd(0)
),
dans le cas de dd(0) les déductions supplémentaires suivantes
apparaissent :
uu = 0 & vv = 0 & ww = 0
dd(0) : déduction avec les mécanismes de la force 0

de la même manière essayer dc(uu : 10..20)
version 1.4 2005
55
Simplification des égalités

Exemple : machine Eql avec une assertion fausse



examiner la machine Eql lancer la preuve et faire mp sur la PO
d'assertion
Les variables sont simplifiées par groupe d'égalité
Pour chaque groupe, un élément représentatif est choisi,


si c'est possible un littéral est choisi,
les expressions ne sont pas concernées.
x1

x2
x3
Attention, l'effet est non rétroactif sur les hypothèses


5
x4
essayer en faisant dc(x1 = x2)
Attention, ce mécanisme n'est pas appelé avec la commande dd
version 1.4 2005
56
Simplification des égalités

Comment remplacer e1 par e2



Si on a l’hypothèse e1 = e2, bien sûr
Si e1 est une variable et e2 une expression complexe, le
prouveur ne fait pas le remplacement sans bonne raison…
Commande interactive




eh :
eh(e1,e2) pour remplacer dans le but
eh(e1) pour remplacer dans le but avec la plus récente
hypothèse e1 = e2
eh(e1,e2,AllHyp) pour créer toutes les nouvelles hypothèses
possibles par remplacement (violent !)
eh(e1,e2,Hyp(H)) à partir des hypothèses qui matchent sur H
version 1.4 2005
57
Les PO existentielles

Exemple : machine Suggest et son raffinement Suggest_1




le prouveur ne sait pas faire ce genre de tentatives (jusqu'à la
force 3), il ne sait que faire : #x . (P(x) & x = a) e P(a)
Démonstration interactive


examiner ces composants, les ajouter et lancer leur preuve en
force 0,
il faut montrer qu'il existe une valeur de ss telle que ss est un
ensemble non vide et 3 : ss
mp & se({3}) & pr
Les PO existentielles se rencontrent


dans un ANY xx WHERE ... non directement raffiné :
 ajouter une variable lastxx := xx dans le composant, conserver
cette variable dans le raffinement
dans le cas de constantes abstraites non raffinées
version 1.4 2005
58
Les hypothèses dérivées

Hypothèse dérivée : hypothèse produite automatiquement par les
mécanismes tels que dd(0)



sur ces hypothèses, certains mécanismes comme la simplification
des égalités ne sont pas branchés, ce serait trop long,
pour appliquer ces mécanismes repasser l'hyp dans le prouveur par
ah(hyp)
Remarque


souvent mp & tp(Hyp) réussit à prouver dans le cas de blocages
par hypothèses dérivées ;
tp(Hyp) essaie de prouver le but en commençant par ajouter des
hypothèses qui permettent d'appliquer une règle.
version 1.4 2005
59
Création d’hypothèses dérivées


A partir d’un “quel que soit” : ph (particularize hypothesis)
 ph(x0, !x.(P(x)=>Q(x))) pour faire prouver P(x0) et générer Q(x0)
A partir d’un “implique” : mh (modus ponens in hypothesis)
 mh(P=>Q) pour faire prouver P et générer Q
version 1.4 2005
60
Démonstration manuelle ou mixte

Démonstration mixte : démonstration interactive utilisant à la fois des
mécanismes du prouveur et les commandes purement interactives
Démonstration manuelle : on n’applique aucun mécanisme du prouveur

Exemple : machine Manual qui ne passe pas en force 3


en faisant mp les hypothèses sont normalisées et peu lisibles,
en particulier, on ne voit plus les hypothèses :
nP y k = 1 &
P y k=0
version 1.4 2005
61
Démonstration manuelle
dd
dc ( aa * 10 < bb - 3 )
pr
valide car le sous but est prouvé
dd
mh ( not ( aa * 10 < bb - 3 ) y kk = 1)
pr

on n’utilise uniquement les mécanismes du prouveur lorsque ceux-ci
aboutissent directement
version 1.4 2005
62
Démonstration mixte

Tentative : si l ’on commence la preuve par dc ( aa * 10 < bb - 3 ),
donc avant la montée des hypothèses, on aura peut-être simplification,
dc ( aa * 10 < bb - 3 )
pr
pr



Démonstration mixte : peut être plus rapide
Démonstration manuelle : pas de tentatives et une meilleure maîtrise
Avec l'habitude : démonstrations mixtes plus rapides et plus
généralisables.
version 1.4 2005
63
Les simplifications du GOP

Exemple : machine GopSimpl



la machine est similaire à Manual, examiner les 2 machines,
cependant, dans le cas de GopSimpl toutes les PO sont déchargées
par le GOP
Dans certains cas, le GOP transforme 1 PO en de nombreuses PO plus
simples


risque : saturation du GOP
statistiques : GopSimpl
Manual
11 obvious 6 obvious
0 PO
1 PO
version 1.4 2005
64
Preuve par tentative


Preuve pour laquelle le prouveur tente de démontrer des hypothèses
intermédiaires
Souvent efficace :


en force 0, tenter la démonstration suivante :
mp
tp(Hyp) (preuve par tentative à partir des hypothèses)
dans une démonstration interactive, tenter :
tp(Goal) (génération d ’hypothèses utiles à partir du but)
version 1.4 2005
65
La preuve par cas sur des énumérés


Principe : dans le cas de preuve où les variables sont des énumérés, il suffit
de prouver pour toutes les valeurs possibles des variables
Exemple : machine aig et raffinement aig_1




par rapport à la solution déjà vue en TP, un calcul plus général est fait,
par différences,
dans l’implantation, 3 PO sont non prouvées en force 3,
on prouve par :
dc(m1, POSITION) & bb( dc(m2, POSITION) &
bb( dc(m3, POSITION) & bb(pr) ) )
en fait, il suffit de faire :
mp & bb( dc(m2, POSITION) & bb(pr) )
car mp fait le premier dc sur m1
version 1.4 2005
66
Model checking

commande mc




tente la preuve par exploration de tous les cas sur les variables
discrètes
bloque souvent : trop de variables discrètes, preuve échoue sur un
cas avec toutes les variables discrètes instanciées
usage :
mc (sans arguments) : liste de variables automatique
mc(v1, v2, v3) : liste de variables donnée
essayez sur la PO précédente : blocage
version 1.4 2005
67
Le solver arithmétique

Le solver arithmétique simplifie les expressions arithmétiques, son champ
d’action est déterminé par la force :



force 0 : simplification des prédicats arithmétiques : a = b
force > 0 : simplification de toutes les expressions
Exemple : machine Solv avec une PO fausse pour observer les
simplifications


preuve en force 0
x1 < x3 reste toujours telle quelle
x1 + x2 + (3 - 6 * x1) - x3 + 1 < x2 + x3
l’hypothèse en y est également simplifiée
l’expression max n’est pas simplifiée
preuve en force 1
l’expression max est simplifiée
version 1.4 2005
simplifiée
68
Autres solveurs

ap solveur arithmétique


Pour des inégalités
ss (Set Simplifier) : spécialisé dans la réduction d’expressions ensemblistes

Si le but se simplifie en btrue : tapez pr
version 1.4 2005
69
Essayer une démonstration partout

te (Try Everywhere)

Une démonstration bien choisie peut s’appliquer à d’autre PO


Cas typiques :



Parfois plus qu’on ne le croit…
dc(cas1) & pr
eh(…) & pr
Syntaxe habituelle:


te (sans argument) : essayer la démonstration juste terminée sur
toutes les PO non prouvées de l’opération actuelle
te(mon_op.x, Replace.Gen.Unproved) : essayer la démonstration de
mon_op.x sur toutes les PO non prouvées du composant
version 1.4 2005
70
Utilisation des règles manuelles
Les règles manuelles sont le dernier recours. Leur démonstration manuelle
devra être jointe au dossier de preuve. Leur nombre doit rester petit.


Ajouter le composant Regles du projet BASES, générez les PO, ouvrez
en preuve interactive (ne pas faire la preuve en force 0).
Allez sur AssertionLemmas.5. Ouvrez le fichier de règles manuelles
(Edit PO Method) et ajoutez :
THEORY MyRules IS
0<=a &
0<=b
=>
0<=a+b
END
version 1.4 2005
71
Règles manuelles (2)

Compilez le fichier de règles : pc (PmmCompile), faites dd pour monter les
hypothèses et appliquez la règle : ar(MyRules.1,Once)



Cette règle n'est pas une règle d'équivalence : si nous l'appliquons pour a
et b non positifs, elle conduit la preuve dans une impasse



la règle s'est appliquée avec a = x1 et b = x2
les buts qui apparaissent sont les antécédents de la règle. Démontrez
les avec pr.
allez sur AssertionLemmas.3 ; dd & ar(MyRules.1,Once)
le premier but généré est vrai mais le deuxième est faux : la preuve est
dans une impasse
Toutes les règles du prouveur sont des règles d'équivalence : les règles
manuelles simplement implicatives sont souvent utiles.
version 1.4 2005
72
Règles manuelles (3)
L'instantation des jokers (variables à une lettre) d'une règle se fait dans le
but uniquement. Si un joker doit s'instantier sur une hypothèse, il faut
employer binhyp.


Aller sur AssertionLemmas.1, dd pour monter les hypothèses
Ajoutez la règle suivante (attention : ; obligatoire entre deux règles)
f: S +-> T => S<|f = f

Compilez et appliquez cette règle : pc & ar(MyRules.2,Once)


Le but qui apparaît contient un joker non instantié :
indémontrable.
Corrigez la règle
binhyp(f: S +-> T) => S<|f = f

Réessayez : fonctionnement correct.
version 1.4 2005
73
Règles manuelles (4)
Les règles de réécriture s'appliquent sur toutes les réécritures possibles. Si elles
ont des antécédents, ceux ci doivent être démontrés avant la réécriture.


Tapez re & ah((0..10)u0 = 0u0u(0..10)) : observation de réécritures dans ce
nouveau but
Ajoutez la règle suivante (attention : ; obligatoire entre deux règles)
A\/{} == A

Compilez et appliquez cette règle : pc & ar(MyRules.3,Goal) & pr

La réécriture s'est appliquée plusieurs fois. Attention : pas de
commutativité automatique.
version 1.4 2005
74
Règles manuelles (5)


Tapez re & ah(max({3}u(10..5)) = 3) : observez les réécritures dans le
nouveau but
Ajoutez la règle suivante (attention : ; obligatoire entre deux règles)
B = {} => A\/B == A




Compilez et appliquez cette règle : pc & ar(MyRules.4,Goal)
Le premier but est 10..5 = 0. Démontrez le avec pr.
Le but suivant est le résultat de la réécriture.
Placez-vous sur AssertionLemmas.1, dd puis ar(MyRules)
ar(nom de théorie) permet l'application (multiple) de toutes les
règles qui matchent sur le but courant.
A partir de la version 3.4.6 : des outils de preuve de règles (prouveur de
prédicats et prouveur arithmétique) peuvent être appliqués aux règles
manuelles.

version 1.4 2005
75
Règles manuelles (précautions)

Attention à ne pas créer d ’expressions mal typées : par exemple, les
règles suivantes sont très dangereuses
x : dom(f) => f(x) : ran(f)
 problème si f est une relation, mais pas une fonction
A : POW(B) => card(A) <= card(B)
 problème si B est infini
binhyp(x = 3) => x == 3
 problèmes : captures de variables muettes : vv = 3 en
hypothèse, !vv.P(vv) dans le but
binhyp(x = 0) & blvar(Q) & Q\x => x == 0
 problème s ’il existe des variables x$i
x-x == 0
 problème pour des expression E-E ensemblistes
version 1.4 2005
76
LA PREUVE
Gestion et administration
version 1.4 2005
77
Gestion de la mémoire
Process
d ’interface :
benv ou bbatch
Process de
preuve :
Logic Solver (krt)
Consommation de mémoire

Paramétrer le Logic Solver en fonction de la machine



taille au départ (plus rapide que l'allocation dynamique)
facteur d'expansion maxi (permet de s'arrêter en cas de boucle)
Savoir récupérer la mémoire après preuve : Quit Project
version 1.4 2005
78
Paramétrage du Logic Solver





Le paramétrage de l'Atelier B s'effectue en modifiant le fichier
$HOME/.AtelierB
Ce fichier, s'il n'existe pas déja, peut être créer en sélectionnant «
Preferences... » puis « Edit User Resources File ».
Dans ce fichier, ajoutez ou supprimer le “!” devant la ligne :
ATB*ATB*Logic_Solver_Command: krt -a m4000000e40
Lancez l'Atelier B par ./startAB
Preuve du composant mm du projet GESTION : éditer les règles
manuelles
THEORY ess IS
x == x+0
END

Cette règle est évidemment bouclante.
version 1.4 2005
79
Paramétrage du Logic Solver (2)

Faites ps -l dans le terminal




Lancez la règle : ar(ess)
Observez les messages dans le terminal : arrêt par blocage sur le facteur
d'expansion, arrêt de la preuve interactive
Faites ps xl dans le terminal


le Logic Solver (krt) fait environ 15M
Le Logic Solver fait toujours 15M


le Logic Solver (krt) fait environ 6M
sous Unix standard, allocation dynamique unidirectionnelle
Quittez le projet : le Logic Solver est arrêté, la mémoire est rendue.
version 1.4 2005
80
La sauvegarde des preuves



La preuve est un travail long  SAUVEGARDES
Méthode préconisée : utiliser Archive Project
Dans la fenêtre des projets :







Restore Project
choisir l'archive : tarPROJ.arc
créer le répertoire d'arrivée (celui qui contiendra spec, bdp, lang)
sélectionner ce répertoire d'arrivée
choisir un nom pour le nouveau projet
Le projet est désarchivé et son état de preuve est retrouvé
Attention : la version de l ’Atelier B doit être identique (sinon refus), et
le réglage doit être identique (ex : génération ou non des « obvious
PO »)
version 1.4 2005
81
La sauvegarde des preuves (2)


Dans la fenêtre des projets :

choisir Archive Project

ATTENTION : personne ne doit utiliser ce projet et l'Atelier B ne doit
pas avoir été arrêté brutalement sur ce projet (sinon : cd bdp; rm
aaaa* *.lock .usedby*)

choisir le répertoire d'arrivée et le nom de l'archive
Le projet est archivé, on peut le détruire (Detach Project, rm -r)
version 1.4 2005
82
La sauvegarde des preuves (3)
Comment restaurer un état de preuve tout en conservant des modifications
?



Restaurer le projet dans un répertoire séparé
Recopier la nouvelle version des composants dans ce répertoire
Prove force 0 puis Prove Replay



Après génération Obligations de Preuve, le "Merge" récupère au
mieux les Obligations de Preuve inchangées
La preuve en force 0 élimine 70% des nouvelles Obligations de
Preuve
Replay réessaie les démonstrations sur les Obligations de Preuve
ayant changé
version 1.4 2005
83
La sauvegarde des preuves (4)
Le piège de la simplification :
 Un composant est prouvé ;
 on perfectionne ce composant, avec en particulier une nouvelle
partie totalement indépendante dans l'invariant
 invariant plus fort : le "Merge" récupère facilement les PO
démontrées avant
 on élimine la nouvelle partie
 affaiblissement de l'invariant : TOUTES LES PO DEVIENNENT
NON PROUVEES (Prove Replay global nécessaire)

Il vaut mieux repartir d'une sauvegarde

sauvegarde à chaque étape stable du projet
version 1.4 2005
84
Le rejeu
Le rejeu des preuves est très important pour :
 Final :


vérifier la preuve correcte d'un projet (règles provisoires enlevées)
Travail :


éviter les décalages dans les numéros de règles manuelles
vérifier la résistance des démonstrations aux hypothèses nouvelles
 PO prouvée par une démonstration
 Modification du composant : le but reste identique, hypothèses
nouvelles
 Merge : hypothèses plus fortes, la PO reste prouvée (elle est
vraie)
 Les hypothèses nouvelles peuvent gêner le déroulement de la
démonstration d'origine
 exemple : démonstration avec pp. Nouvelles hypothèses : risque
de dépasser le temps de coupure. Utiliser pp(rp.0) ou pp(rp.1)
version 1.4 2005
85
Le rejeu (2)

Projet GESTION : ajouter le composant Unknown, prouver en force 0









2 PO : une fausse (problème isolé, à admettre), 1 nécessite règle
manuelle
Entrer en preuve interactive, 1° PO non prouvée
Editer les règles manuelles : règle p et règle 28 = 256
mp & ar(MyRules.2, Goal) & pr : démonstration première PO
ne & ar(MyRules.1, Once) : admission deuxième PO
Preuve finie : Unprove Replay correct
Modifier les règles manuelles : supprimer p
Unprove Replay : 0 PO prouvées
Décalage dans les numéros de règles : démonstration PO1 perdue!

Mettre les règles provisoires dans des théories isolées
version 1.4 2005
86
Le rejeu (3)
Projet Fini Prouvé = règles manuelles
vérifiées + Unprove/Replay global avec
succès

En moyenne : Replay au moins 1 fois / semaine !
version 1.4 2005
87
Les règles d'admission
Admettre une Obligation de Preuve = la mettre de côté





pour ne pas ralentir la preuve automatique sur les autres PO
si une PO boucle en automatique : permet la poursuite de la preuve
composant Unknown : contient une PO fausse que l'on veut admettre
ouvrir en preuve interactive, aller sur la PO concernée
Edit PO Method : ajouter dans une théorie réservée aux admissions
binhyp(c.o.n) &
bcall(WRITE: bwritef("\nPO %.%.% admise\n », c,o,n))
=>
p


pc & ar(Admis) : la PO est admise, message dans la console
Attention : \n obligatoire, sinon interférence avec l'interface
version 1.4 2005
88
LA PREUVE
Les pièges
version 1.4 2005
89
Le terminal de contrôle
Il est toujours important de surveiller le terminal de contrôle en cours
de preuve.


Messages concernant l ’allocation de mémoire
Messages en cas d ’erreur au contrôle de type d ’une formule
envoyée à pp
version 1.4 2005
90
Les bouclages
Bouclage en force N : décourage l ’opérateur d ’essayer les forces > N, qui
pourtant pourraient démontrer

Un projet dont certaines PO bouclent en force 0 est-il mauvais ?


pas forcément
Comment poursuivre des phases de preuve automatique alors qu ’une
PO boucle et bloque en force N ?


Interrompre avec « Next PO » la preuve bloquante :
 Cette force est alors considérée comme échouant sur cette PO
 Preuve jamais relancée dans cette force sur cette PO jusqu ’au
prochain merge
Utiliser une règle d ’admission pour remettre cette PO à plus tard
 Attention : la PO qui boucle en force N aurait peut-être été
prouvée en force N+1
version 1.4 2005
91
Les symboles non traités
Certains symboles plus rarement employés ne sont pas entièrement
définis dans le prouveur.
Le prouveur ne sait démontrer que certaines choses sur ces
symboles
Composant Unknown du projet BASES : PO non démontrée en
force 3
ouvrir en preuve interactive, aller sur cette PO, mp :





sr(All,(x**y)) : recherche des règles concernant la puissance


Il faut démontrer 28 = 256
aucune règle permettant de faire le calcul (en fait, le solveur
arithmétique permet de simplifier des puissances par 0 et 1 :
essayer ah(21 = 2) )
Il faut ajouter des règles manuelles
version 1.4 2005
92
Les symboles non traités (2)

Règles manuelles : trois possibilités
–
28 == 256 : règle simplement vérifiable, mais peu réutilisable
–
bnum(x) & btest(n2)  (xn == x*(x(n-1) )) : règle simple et générale,
mais entre chacune de ses applications il faut appeler le prouveur
pour simplifier n-1: utiliser pr(Tac(Expo)) & ah(21 = 2) & pr & pr
–
bnum(x) & btest(n2) & bguard((ARI;RES): bresult(n-1),m)  (xn ==
x*(xm )) : nous sommes en train de programmer dans le prouveur !
version 1.4 2005
93