la vérification de modèles (model-checking) · – appelés structures de kripke – graphes...

Prouver les programmes

Gérard Berry

Collège de France Chaire Algorithmes, machines et langages

[email protected]

Cours 5, Paris, 25/03/2015 Suivi du séminaire de Véronique Cortier

(LORIA Nancy)

La vérification de modèles (Model-Checking)

• A system specification consists of a lot of elementary mathematics glued together with a tiny bit of temporal logic

25/03/2015 2 G. Berry, Collège de France

Les devises de Leslie Lamport

• Unfortunately, the computer science departments in many universities apparently believe that fluency in C++ is more important than a sound education in elementary mathematics. So, some readers may be unfamiliar with the math needed to write specifications.

•  If exposure to C++ has not destroyed your ability to think logically, you should have no trouble filling any gaps in your mathematics education

• Naissance dans les années 1980, dans un milieu très différent de celui de la preuve formelle : –  protocoles de communication (les précurseurs) –  circuits électroniques –  algorithmes distribués –  programmes réactifs et temps-réel


Le Model-Checking (systèmes d’états finis)

• Des idées-clefs développées indépendamment en France et aux USA → Prix Turing 2007 – J-P. Queille et J. Sifakis* à Grenoble –  E. Clarke* et E. Emerson* à CMU et U. Texas

• Deux grand principes : l’exploration systématique des exécutions, explicite ou implicite (symbolique), et l’expression des propriétés à prouver en logique temporelle (A. Pnueli*)

• De nombreux systèmes efficaces, dont plusieurs industriels

1.  Les logiques temporelles 2.  Les systèmes de transitions et la bisimulation 3.  La vérification par observateurs 4.  Les algorithmes de vérification explicite 5.  Le Sudoku en calcul booléen


Agenda



Agenda


Propriétés de sécurité (safety)

start open stopped closed

1.  Au départ, l’ascenseur ferme sa porte avant de démarrer

2.  Après un start, open ne doit jamais arriver jusqu’à stopped

3.  Après un open, start ne doit jamais arriver jusqu’à closed

A vérifier

Condition d’environnement l’ascenseur est initialement arrêté, porte ouverte

closed start stopped open closed start open closed

open start

L’ascenseur ne peut pas voyager la porte ouverte

start


Propriétés de vivacité (liveness)

call[i]

open stopped[i]

Après call[i], l’ascenseur finit par s’arrêter à l’étage i et y ouvre sa porte avant de redémarrer

A vérifier

Conditions d’environnement Quand il monte (rep. descend), l’ascenseur parcourt tous les étages dans l’ordre de la direction donnée, jusqu’à l’ordre d’arrêt (qui doit nécessairement arriver)

L’ascenseur ramasse les passagers qui l’appellent

start


Parler des exécutions • Structures de données : trois grands choix

–  graphes d’états étiquetés par des prédicats, –  appelés structures de Kripke –  graphes d’états-transitions, avec transitions étiquetées –  graphes mixtes états / transitions étiquetés

• Définition des prédicats d’états / transitions –  simples symboles non interprétés p, q, etc. –  ou prédicats sur le contrôle et les données d’un programme –  ou prédicats sur les horloges d’un système temporisé

• Définition des propriétés à vérifier (sûreté ou vivacité) –  formules de logique temporelle linéaire ou arborescente –  formules de µ-calcul –  propriétés définies par des observateurs –  équivalences ou raffinement de comportements


Structure de Kripke

K = (S, I, T, P, L)

S : ensemble d’états (states) I ⊂ S : ensemble d’états initiaux T ⊂ S×S : relation de transition totale à gauche ∀s∈S. ∃s’∈E. sTs’ → chemins infinis pour T P = {p, q, ...} : ensemble de prédicats atomiques

L : S→2P : fonction d’étiquetage L(s) = {p, r,…} ensembles des prédicats vrais en s

chemin : π = s0 → s1 → s2 → … suffixe : π[n] = sn → sn+1 → sn+2 → …


Exemple de structure de Kripke

s0

p s1

q

s2

p, r s3

q, r

Propriétés satisfaites : P1 : p et q ne sont jamais vraies en même temps P2 : tout q est immédiatement suivi d’un r P3 : tout chemin infini depuis un état initial atteint r


Exemple de structure de Kripke

s0

p s1

q

s2

p, r s3

q, r

Propriétés non satisfaites : P4 : tout p est immédiatement suivi d’un q P5 : tout chemin infini depuis un état initial atteint p

•  Intuition –  A φ : tous les chemins partant de l’état donné satisfont φ –  E φ : il existe un chemin partant de l’état donné qui satisfait φ –  Φ : l’état initial du chemin donné satisfait Φ –  G φ : tous les suffixes du chemin donné satisfont φ –  F φ : il existe un suffixe du chemin donné qui satisfait φ –  X φ , i.e., next φ : le premier suffixe du chemin donné satisfait φ –  φ U φ’ : le chemin donné satisfait φ jusqu’à satisfaire φ’, ce qu’il doit faire


La logique temporelle CTL*

Φ := ⊥ | ⊤ | p | ¬Φ | Φ∧Φ’ | Φ∨Φ’ | Φ⇒Φ’ | Φ⇔Φ’ | A φ | E φ φ := Φ | ¬φ | φ∧φ’ | φ∨φ’ | φ⇒φ’ | φ⇔φ’ | G φ | F φ | X φ | φ U φ’

Φ : formule d’états φ : formules de chemins


La logique temporelle CTL*

Interprétation K,s ⊨ Φ ou simplement s ⊨ Φ pour une structure de Kripke K et un état s s ⊨ p : le prédicat p est vrai en s s ⊨ ¬Φ : s ⊨ Φ , s ⊨ Φ∧Φ’ : s ⊨ Φ et s ⊨ Φ’, etc. s ⊨ A φ : tous les chemins partant de s vérifient φ s ⊨ E φ : il existe un chemin partant de s qui vérifie φ


Φ : formule d’états φ : formules de chemins


La logique temporelle CTL* Φ : formule d’états φ : formules de chemins

Interprétation π ⊨ φ pour K et un chemin π = s0 → s1 → s2 → … π ⊨ Φ : s0 ⊨ Φ , π ⊨ ¬φ : π ⊨ φ, π ⊨ φ∧φ’ : π ⊨ φ et π ⊨ φ’, etc. π ⊨ G φ : ssi ∀n. π[n] ⊨ φ, avec π[n] = sn → sn+1 → … π ⊨ F φ : ssi ∃n. π[n] ⊨ φ π ⊨ X φ : ssi π[1] ⊨ φ π ⊨ φ U φ’ ssi ∃n. (∀m<n. π[m] ⊨ φ) ∧ π[n] ⊨ φ’



La logique temporelle CTL* Φ : formule d’états φ : formules de chemins

nommage et notations équivalentes : pout tout chemin : ⃞ φ ≡ A φ il existe un chemin : ◊ φ ≡ E φ pour tout suffixe : ⃞ φ ≡ G φ il existe un suffixe : ◊ φ ≡ F φ prochain suffixe (next) : ⃝ φ ≡ X φ


• CTL* est très riche, car les modalités peuvent se combiner arbitrairement


Complexité de CTL*

• Complexité théorique : – satisfiabilité : pour une formule, existe-t-il une structure de

Kripke K la satisfaisant ? 2-ExpTime-complet L – vérification : étant donné K, s et Φ, quel est le coût de la

vérification de K,s ⊨ Φ ? Linéaire en K, PSpace-complet en Φ

• Rappel : pour taille n –  linéaire en n : coût en O(n) – polynomial en n : coût en O(nk) – PSpace-complet : mémoire en O(nk) temps supposé en O(kn)

– 2ExpTimeComplete : temps en O(2 ) 2n

• Formules seulement sur les chemins, formules d’états réduites aux prédicats p


La logique LTL : Linear Temporal Logic

φ := p | ¬φ | φ∧φ’ | φ∨φ’ | φ⇒φ’ | φ⇔φ’ | G φ | F φ | X φ | φ U φ’

φ := ... | ⃞ φ | ⃟ φ | ⃝ φ | φ U φ

•  Interprétation comme en CTL*, sur chaque chemin •  Limitation : pas de prédicats d’états non-triviaux, •  Limitation : donc pas de quantification sur les chemins

Avantages : simple, intuitive, applicabilité assez générale Avantages : algorithmes raisonnablement efficaces Vérifieurs : SPIN, MurΦ, Cospan, SMV, NuSMV, etc.

• De l’état initial, l’ascenseur doit fermer sa porte avant de partir

⃞( init ⇒ (¬open U start) • Après start, jamais open jusqu’à stopped ⃞(start ⇒ ⃝(¬open U stopped)) • Après open, jamais start jusqu’à closed ⃞(open ⇒ ⃝(¬start U closed))


L’ascenseur en LTL

• Vivacité : l’ascenseur ramasse ses passagers: il est toujours vrai que s’il est appelé à l’étage i, l’ascenseur finira par s’arrêter à cet étage et y ouvrira sa porte avant de repartir

⃞(call[i] ⇒ ⃟(stopped[i] ∧ (¬start U open))


L’algorithme de Dekker Deux processus J1 et J2 essaient de prendre une ressource R. L’algorithme de Dekker donne un arbitrage équitable: 1. J1 et J2 ne sont jamais ensemble dans leur section critique 2. Chacun des deux obtient une infinité de fois la section critique s’il la demande une infinité de fois

N1 : J1 est dans une section non critique T1 : J1 essaie d’entrer en section critique C1 : J1 est en section critique T2 : visible en lecture seule

N2 : J2 est dans une section non critique T2 : J2 essaie d’entrer en section critique C2 : J2 est en section critique T1 : visible en lecture seule

tour = 0, 1, 2 : variable partagée en lecture / écriture

⃞¬(C1 ∧ C2) : Pas de conflit de section critique VRAI : simple vérification dans chaque état


N1 N2 tour=0

NC N2 T1

tour=1

N1 N2 T1 T2 tour=2

C1 N2 T1 T2 tour=1

NC N2 T1 T2 tour=1

C1 T2 T1 T2 tour=1

NC NC T1 T2 tour=2

N1 C2 T1

tour=2

NC C2 T1 tour=2

⃞⃟C1 : J1 entre infiniment souvent en section critique FAUX à cause de la boucle en haut à droite


N1 N2 tour=0

NC N2 T1

tour=1

N1 N2 T1 T2 tour=2

C1 N2 T1 T2 tour=1

NC N2 T1 T2 tour=1

C1 T2 T1 T2 tour=1

NC NC T1 T2 tour=2

N1 C2 T1

tour=2

NC C2 T1 tour=2

⃞(⃟T1⇒⃟C1) : J1 entre infiniment souvent en section critique s’il essaie infiniment souvent

Strong fairness : VRAI mais bien plus subtil ! 25/03/2015 22 G. Berry, Collège de France

N1 N2 tour=0

NC N2 T1

tour=1

N1 N2 T1 T2 tour=2

C1 N2 T1 T2 tour=1

NC N2 T1 T2 tour=1

C1 T2 T1 T2 tour=1

NC NC T1 T2 tour=1

N1 C2 T1

tour=2

NC C2 T1 tour=2


Amour un jour, amour toujours

(◊ amour) ⇒ (◊ � amour)

⇒

(◊ amour) ⇒ (� amour)

• CTL = la logique initiale d’E. Clarke et E. Emerson • Modalités acceptées : toute sous-formule de chemin G, F, X ou U

est immédiatement précédée de A ou E. • Depuis un état donné :

–  AG φ : tous les chemins satisfont toujours φ –  AF φ : tous les chemins satisfont un jour φ –  AX φ : tous les premiers suffixes des chemins satisfont φ –  A (φUφ’) : tous les chemins satisfont φ jusqu’à satisfaire φ’

–  EG φ : il existe un chemin satisfaisant toujours φ –  EX φ : il existe un chemin dont le premier suffixe satisfait φ –  EF φ : il existe un chemin satisfaisant un jour φ –  E (φUφ’) : il existe un chemin satisfaisant φ jusqu’à satisfaire φ’


La logique CTL : Computation Tree Logic


source Alessandro Artale, http://www.inf.unibz.it/~artale/

• Sur le protocole de Dekker


Propriétés exprimables en LTL et CTL

pas de conflit de section critique (vrai) LTL : ⃞¬(C1 ∧ C2) → CTL : AG ¬(C1 ∧ C2) J1 entre infiniment souvent en section critique (faux) LTL : ⃞⃟C1 → CTL : AF C1

J1 finit par entrer en section critique s’il essaie (vrai) LTL : ⃞(⃟T1 ⇒ ⃟C1) → AF (T1 ⇒ EF C1)


Les deux machines à café de R. Milner

€

c t

vc vt

Indistingables en LTL car les traces linéaires sont identiques : (. → € → c → vc → )* et (. → € → t → vt → )*

Distingables en CTL, par AG(€ ⇒ E(c U €)) : après avoir mis un €, je peux toujours avoir un café sans remettre un autre €

€

c t

vc vt

c t

vc vt

€ €


Exprimables soit en LTL soit en CTL

dans chaque exécution, J1 entre infiniment souvent en section critique s’il essaie infiniment souvent : ⃞(⃟T1⇒⃟C1)

• Exprimables en LTL mais pas en CTL (strong fairness)

• Exprimables en CTL mais pas en LTL, qui n’a pas EF Quand J1 est en section non-critique, il existe toujours un chemin où il entre en section critique AG(T1⇒ EF C1) :

Le choix de la logique dépend de la propriété à exprimer Certains moteurs gèrent une seule logique, d’autres les deux

Tout reste exprimable en CTL*, mais de toutes façons, les formules compliquées sont vite incompréhensibles...



Agenda

•  Les structures de Kripke conviennent pour des programmes fermés, mais moins pour des systèmes à entrées-sorties et des processus communicants


Les systèmes de transitions

• Alternative : les systèmes de transition, où les prédicats sont portés par les transitions et non par les états (quelquefois par les deux)

S : états ou processus T : transitions A : actions L : T → 2A :étiquetage des transitions par des actions

Beaucoup de liberté dans la définition: composants finis ou infinis, structure algébrique de A, etc.


Les deux machines à café

€ -

c- t-

vc vt

€ -

c- t-

vc vt

€

c t

vc-

vt-

p = € -.(c-.vc + t-.vt) q = € -.c-.vc + € -.t-.vt

€ -

Etats : termes p, q, ..., définis pas la grammaire suivante 0 : état inerte µ.p : action puis continuation p + q : choix entre p et q p | q : mise en parallèle de p et q p \ a : déclaration locale de a et a- dans p x, rec x.p(x) : id. de processus, appel récursif


CCS = Calculus of Communicating Systems R. Milner, 1994

Actions : atomes a, b, c, ..., plus action invisible τ inverses a-, avec a--

= a notation : α → a, a- et µ → a, a-, τ


Sémantique SOS de CCS

µ.p µ

p

p | q µ

p’ | q

µ p p’

p | q µ

p | q’

µ q q’

p + q µ

p’

µ p p’

p + q µ

q’

q q’ µ

p | q τ p’ | q’

a p p’ a- q q’

p \ a µ

p’ \ a

µ p p’ µ ≠ a, a-

rec x = p µ

p’ [x←rec x=p]

µ p p’

Idée centrale : communication = a.a- → τ , globale ou locale

• Comment dire que deux systèmes non-déterministes sont équivalents, i.e., indistingables par communication ?


La bisimulation forte

• Une bisimulation est une relation entre états vérifiant

si p et q sont bisimilaires,

si p peut faire α, alors q peut le faire aussi en restant bisimilaire, et réciproquement

•  La bisimulation forte est la plus grande bisimulation (beaucoup de caractérisations possibles).

•  c’est une équivalence et une congruence pour toutes les opérations

si p R q et p p’, alors ∃q’. q q’ et p’ R q’ α α

si p R q et q q’, alors ∃p’. p p’ et p’ R q’ α α


Les deux machines à café

€ -

c- t-

vc vt

€ -

c- t-

vc vt

€

c t

vc-

vt-

p = € -.(c-.vc + t-.vt) q = € -.c-.vc + € -.t-.vt

p et q ne sont pas bisimilaires : p (c-.vc+ t-.vt) vc € - t q t-.vt € - c

€ -

•  Idée : même définition, mais en tenant compte des chaînes d’actions internes τ, mais pas de leur longueur


La bisimulation faible, ou équivalence observationnelle

p p’ ssi p p1 ... pn p’1 ... p’ a τ τ τ a τ τ

•  p et q sont observationnellement équivalents s’ils sont fortement bisimilaires pour

• Attention : l’équivalence observationnelle n’est pas une congruence !


Réduction par équivalence observationnelle L’ascenseur ne peut pas voyager la porte ouverte

start open stopped- closed-

open

start

→ réduire le terme ascenseur \ {s1, s2,...,sn} où les si cachés sont tous les signaux sauf open, start, closed- et stopped-

open

open

start

closed-

stopped-

start

bug!

bug!

Vérifier = inspecter la réduction



Agenda


Vérification par observateur synchrone

Système réactif (ou interactif)

entrées sorties

Observateur Bug

A prouver: Bug ne peut jamais être émis L’observateur étant lui-même un système réactif, il peut être

programmé dans le même langage (Esterel, Lustre, etc.) Souvent plus simple que la logique temporelle.


Observateur Esterel L’ascenseur ne peut pas voyager la porte ouverte

start open stopped closed

signal danger in loop abort sustain danger when closed ; await open end loop || loop await start ; abort await immediate danger do emit Bug end when stopped end loop end signal

A prouver : Bug ne peut jamais être émis


Modéliser l’environnement

•  L’environnement dans lequel évolue le programme n’est pas arbitraire, et il est souvent indispensable de le modéliser

–  sinon les propriétés peuvent devenir fausses –  et pour minimiser la taille de l’espace d’états

Système réactif (ou interactif)

sorties

Observateur Bug!

Env


Modéliser l’environnement • Exemple pour l’ascenseur

–  il faut qu’une porte soit ouverte ou fermée –  pour aller du 2e au 4e, il faut passer par le 3e –  il n’y a pas de bouton pour aller vers le haut au dernier étage

• Attention : –  en logique temporelle, il faut prouver Env ⇒ Props –  il faut s’assurer que le modèle de Env est non-vide, –  sinon Env ⇒ Props devient trivial ! ⇒ problème de satisfiabilité des formules de logique temporelle



Agenda

• Objectifs : – construire la structure de Kripke ou le système de transitions de

l’application (programmée comme on le souhaite) – vérifier les propriétés de sécurité (safety) ou vivacité (liveneness) sur ce

système. Cela demande en général un prétraitement des formules, par exemple, leur transformation en automates observateurs.

– produire des diagnostics et contre-exemples sur les propriétés fausses –  lutter par tous les moyens contre l’explosion en taille, potentiellement

exponentielle


L’algorithmique du Model-Checking

• Deux grandes classes de méthodes 1.  méthodes explicites : énumérer explicitement (mais intelligemment)

les états et transitions 2.  méthodes implicites : travailler avec des formules logico-

numériques décrivant états et transitions sans les énumérer

Propriétés de sécurité : exploration d’états


état initial état potentiel transition potentielle

Propriété P = ensemble d’états


P fausse


Analyse en avant : marquer les états atteignables


P fausse


Analyse en avant : marquer les états atteignables (1)


P fausse

état initial état atteignable transition atteignable



P fausse




P fausse


Aucun mauvais état atteint ⇒ P est vraie

Analyse en avant : Production de contre-exemple


P fausse




P fausse


Bug !



P fausse


Bug !

Avantage : contre-exemple de longueur minimale

Analyse en arrière


P fausse


marqué

Analyse en arrière Marquer les états faux



marqué

Analyse en arrière Marquer les prédécesseurs (1)



marqué

Analyse en arrière Marquer les prédécesseurs (2)



L’état initial n’est pas marqué ⇒ P est vraie

marqué

Analyse en arrière Production de contre-exemple



marqué




Bug !

L’état initial est marqué ⇒ P est fausse

marqué




Bug !


Pas forcément plus rapide que l’analyse en avant...

marqué


• Principes de base : –  logiques temporelles : transformer les formules à prouver en

lobservateurs à explorer de façon synchrone avec le modèle (non ltrivial !)

–  construire explicitement les états et transitions –  lutter contre l’explosion de leur nombre –  produire des contre-exemples pour les propriétés fausses


Algorithmes explicites

• En pratique : –  exploration exhaustive ou aléatoire –  abstraction par hachage des états, avec collisions possibles

l(peut rater des bugs) –  réductions par ordres partiels (commutativité d’opérations) –  réduction par symétries (si les acteurs sont les mêmes) –  techniques d’abstraction de l’interprétation abstraite –  implémentations massivement parallèles


Algorithmes explicites • Systèmes principaux :

–  Historiques : CESAR de J-P. Queille et J. Sifakis, EMC de –  E. Clarke et A. Emerson –  SPIN de G. Holzmann, avec son langage Promela, proche de C, et

lune grande communauté d’utilsateurs (protocoles, algos distribués) –  COSPAN de R. Kurshan –  CADP de H. Garavel, R. Mateescu et. al., originellement sur LOTOS,

lcalcul de processus pour les télécommunications, puis adapté à lbeaucoup de langages

–  (Outils pour les réseaux de Petri, etc.)



Agenda


Résolution booléenne d’un Sudoku

http://www.cs.qub.ac.uk/~I.Spence/SuDoku/SuDoku.html


Définition booléenne d’une grille

114 ∧ 157 ∧ 169 ∧ 176 ∧ 239 ∧ 346 ∧ 388 ∧ 393 ∧ 497 ∧ 515 ∧ 548 ∧ 571 ∧ 617 ∧ 628 ∧ 651 ∧ 662 ∧ 684 ∧ 716 ∧ 725 ∧ 858 ∧ 877 ∧ 894 ∧ 934 ∧ 952 ∧ 973

729 variables xyz : vraie si la case (x,y) contient la valeur z

25 clauses booléennes


Contraintes booléennes du Sudoku

111 ∨ 112 ∨ 113 ∨ 114 ∨ 115 ∨ 116 ∨ 117 ∨ 118 ∨ 119

- la case 1-1 contient un entier de 1 à 9 : 1 clause

∧ (¬111 ∨ ¬112) ∧ (¬111 ∨ ¬113) … ∧ (¬111 ∨ ¬119) ∧ (¬112 ∨ ¬113) ∧ (¬112 ∨ ¬114) … ∧ (¬112 ∨ ¬119) ∧ … ∧ (¬118 ∨ ¬119)

- un seul entier dans la case 1-1 : 36 clauses

- à répéter pour les 81 cases : 81×(1+36) = 2997 clauses


Contraintes booléennes du Sudoku

∧ (111 ∨ 121 ∨ 131 ∨ 141 ∨ 151 ∨ 161 ∨ 171 ∨ 181 ∨ 191) - la ligne 1 contient l’entier 1 : 1 clause

∧ (¬111 ∨ ¬121) ∧ (¬111 ∨ ¬131) … ∧ (¬111 ∨ ¬191) ∧ (¬121 ∨ ¬131) ∧ (¬121 ∨ ¬141) … ∧ (¬121 ∨ ¬191) ∧ … ∧ (¬181 ∨ ¬191)

- l’entier 1 n’est qu’une fois dans la ligne 1 : 36 clauses

- idem pour chaque entier, ligne, colonne et carré 3×3 : 27×9×(1+36) = 8 991 clauses

- total contraintes : 2997+8991 = 11 988 clauses plus grille donnée 25 clauses total général 12 013 clauses

•  Logiques temporelles –  J-P. Queille, J. Sifakis. Specification and verification of concurrent systems in

CESAR. International Symposium of Programming, Springer LNCS 137, 1982, pp 337 – 351

– E.M. Clarke, E.A. Emerson, and A.P. Sistla. Automatic verification of finite-state concurrent systems using temporal logic specifications. ACM Trans. Program. Lang. Syst. 2, pp. 244–263 (1986).

–  Z. Manna, A. Pnueli. The temporal logic of reactive and concurrent systems. Springer, New York (1992).

–  L. Lamport. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers . Addison-Wesley (2002).

• Calculs de processus et bisimulation – R. Milner. Communication and Concurrency. Prentice Hall, 1989

• Observateurs – N. Halbwachs, F. Lagnier, and Pascal Raymond. Synchronous Observers and

the Verification of Reactive Systems. Third Int. Conf. on Algebraic Methodology and Software Technology, AMAST'93, Twente. Springer Verlag (1993).


Bibliographie

• Méthodes explicites – G. Holtzmann. The Spin Model Checker — Primer and Reference Manual,

Addison-Wesley, 2003 – H. Garavel, F. Lang, R. Mateescu, W. Serwe. CADP 2011: A Toolbox for the

Construction and Analysis of Distributed Processes International Journal on Software Tools for Technology Transfer (STTT), 15(2):89-107, April 2013.

• Méthodes implicites –  J. Burch, E.. Clarke, K. McMillan, D. Dill, L. Hwang: Symbolic Model Checking:

10^20 States and Beyond. Proc. LICS Conference 1990. – K. McMillan. Interpolation and SAT-based Model Checking. Proc Computer-

Aided Verification Converence (CAV03), 2003.

• Survey généraux – E. Clarke. The Birth of Model-Checking. 25 Years of Model Checking,

Springer-Verlag Berlin, Heidelberg, 2008. – R. Jahla, R. Majumdar. Model-Cheking Software Systems. ACM Computing

Surveys, Volume 41 Issue 4, October 2009.


Bibliographie

la vérification de modèles (model-checking) · – appelés structures de kripke – graphes...

Documents