Movatterモバイル変換


[0]ホーム

URL:


Aller au contenu
Wikipédial'encyclopédie libre
Rechercher

Vérification de modèles

Un article de Wikipédia, l'encyclopédie libre.
Principe dumodel checking.

Eninformatique, lavérification de modèles, oumodel checking en anglais, est le problème suivant : vérifier si le modèle d'un système (souventinformatique ouélectronique) satisfait une propriété. Par exemple, on souhaite vérifier qu'un programme ne se bloque pas, qu'une variable n'est jamais nulle, etc. Généralement, la propriété est écrite dans un langage, souvent enlogique temporelle. La vérification est généralement faite de manière automatique. Sur le plan pratique, la vérification de modèles est devenue, au niveau industriel, la méthode de vérification de code et de systèmes matériels la plus populaire et la plus utilisée aujourd'hui[réf. nécessaire].

Histoire

[modifier |modifier le code]

La vérification de modèles s'appuie sur lalogique temporelle dont l'un des pionniers estAmir Pnueli, qui reçut le prix Turing en 1996 pour« […] seminal work introducing temporal logic into computing science » (« […] travaux fondateurs qui introduisent la logique temporelle en informatique »)[1]. Lemodel checking commence avec les travaux d'Edmund M. Clarke,E. Allen Emerson[2],[3],[4],Jean-Pierre Queille[5]etJoseph Sifakis[6] au tout début des années 1980. Clarke, Emerson et Sifakis se sont vu attribuer leprix Turing 2007 pour leurs travaux sur le model checking[7],[8].

Description

[modifier |modifier le code]

Dans cette section, on précise ce que l'on entend par modèle et propriété puis par le problème de model checking.

Modèle

[modifier |modifier le code]
Système de transition d'états pour un distributeur de boissons.

Le système est modélisé par unsystème de transition d'états. Il s'agit d'ungraphe orienté : un sommet représente un état du système[9] et chaque arc représente une transition[10], c'est-à-dire une évolution possible du système d'un état donné vers un autre état. Chaque état du graphe orienté est étiqueté par l'ensemble des propositions atomiques vraies à ce point d'exécution (par exemple,i=2,le processeur 3 est en attenteetc.). Un tel graphe est aussi appelé unestructure de Kripke.

Exemple du distributeur de boissons

[modifier |modifier le code]

On donne ici l'exemple d'un distributeur de boissons qui peut être dans 4 états[11] : attente d'une pièce de monnaie, sélection d'une boisson, distribution d'une bouteille d'eau minérale et distribution d'une bouteille de jus d'orange.

Exemple de l'ascenseur

[modifier |modifier le code]

L'état du système est décrit par le niveau courant de l'ascenseur entre 0 et 3, l'état des appels (4 boutons, un par étage) et si l'ascenseur bouge et s'il patrouille vers le haut ou vers le bas[12] (il y a donc 4 × 2⁴ × 2 × 2 =256 états).

Propriété

[modifier |modifier le code]

La propriété à vérifier est écrite par une formule de logique temporelle. Par exemple, si l'on souhaite vérifier que x = 0 une infinité de fois, on peut écrire la formule GF(x = 0) qui se lit « toujours, dans le futur, x = 0 ». On distingue :

  • les propriétés de sécurité (safety en anglais), comme « l'ascenseur bouge toujours avec les portes fermées » ;
  • les propriétés de vivacité (liveneness en anglais), comme « si l'ascenseur est appelé à un certain étage, alors il ira à cet étage ».

Dwyer et al. ont identifié 55 types de spécification en logique temporelle linéaire qui apparaissent dans des applications industrielles[13].

Exemple du distributeur de boissons

[modifier |modifier le code]

Par exemple, (GFa → (G(s → F(e ou j))) (si la machine attend une infinité de fois une pièce, alors toujours, dès que l'on sélectionne une boisson, dans le futur, une boisson (eau minérale ou jus d'orange) est délivrée) est une propriété vraie pour le distributeur de boissons.

Problème du model checking

[modifier |modifier le code]

L'entrée du problème du model checking est un modèle (typiquement un système de transition d'états) et une propriété (typiquement écrite dans une logique temporelle). En sortie, on souhaite savoir si la propriété est vérifiée et, le cas échéant, un contre-exemple d'une exécution du système qui falsifie la propriété.

Algorithmes

[modifier |modifier le code]

Méthodes explicites

[modifier |modifier le code]

Pour des propriétés de sûreté (toujours,p est fausse), on peut faire unparcours en profondeur du graphe et vérifier que chaque état vérifiep. Des algorithmes d'étiquetage existent pour lalogique temporelle arborescente (en) (CTL). D'autres méthodes sont fondées sur les automates. On transforme la négation de la formule à vérifier en un automate puis on fait leproduit cartésien synchrone de l'automate et du modèle. On se ramène alors à tester si le langage de l'automate produit est vide ou non.

Méthodes symboliques

[modifier |modifier le code]

Parcourir (ou énumérer) explicitement tous les mondes de la structure de Kripke peut être coûteux, c'est pourquoi des méthodes symboliques, introduites par Ken McMillan et Ed Clarke,sont plus pertinentes.[non neutre] Une approche, répandue pour la vérification de propriétés exprimées dans la logique temporelle arborescente, est fondée sur la représentation symbolique du modèle. De nombreuses méthodes de représentation d'ensembles d'états ont vu le jour[réf. nécessaire]. La plus connue utilise lesdiagrammes de décision binaire (BDD).

Discussions

[modifier |modifier le code]

Model checking borné

[modifier |modifier le code]

Au lieu de considérer l'ensemble des traces d'exécution du système, on peut se limiter à des traces finies, de longueur bornée : c'est lemodel checking borné[14]. L'existence d'une trace vérifiant une certaine propriété est équivalente à la satisfiabilité d'une certaine formule booléenne. En effet, si un état du système est décrit par unk-upletx{\displaystyle {\vec {x}}} de booléens, et que l'on s'intéresse aux traces de longueur bornée par un certain n, on se ramène au problème de la satisfiabilité d'uneformule propositionnelle (problème SAT). Plus précisément, si une formuleI{\displaystyle I} identifie les états initiaux du système, une formuleF{\displaystyle F} les états dont on veut tester l'accessibilité, et une formuleT{\displaystyle T} est une relation de transition, alors on considère la formule booléenneI(x1)T(x1,x2)T(xn1,xn)F(xn){\displaystyle I({\vec {x}}_{1})\wedge T({\vec {x}}_{1},{\vec {x}}_{2})\wedge \dots \wedge T({\vec {x}}_{n-1},{\vec {x}}_{n})\wedge F({\vec {x}}_{n})}xi{\displaystyle {\vec {x}}_{i}} sont des propositions atomiques qui représentent l'état à l'étape i de l'exécution du système. Il existe divers logiciels, appeléssolveurs SAT, qui peuvent décider « efficacement en pratique » le problème SAT. De plus, ces logiciels fournissent habituellement un exemple devaluation satisfaisant la formule en cas de succès. Certains peuvent produire des éléments d'une preuve de non-satisfiabilité en cas d'échec.

Une évolution récente[réf. nécessaire] est l'ajout, en sus de variables booléennes, de variables entières ou réelles. Les formules atomiques ne sont alors plus seulement les variables booléennes, mais des prédicats atomiques sur ces variables entières ou réelles, ou plus généralement des prédicats pris dans une théorie (par exemplex<5{\displaystyle x<5}, etc.). On parle alors desatisfiabilité modulo une théorie (par exemple, on pourra considérer comme prédicats atomiques les égalités et inégalités linéaires).

Autres modèles

[modifier |modifier le code]

Le modèle peut être plus riche que des automates finis. Il existe par exemple du model checking sur desautomates temporisés[15]. Aussi, le concept de model checking se généralise enlogique mathématique. Par exemple, la vérification de structures avec une formule de lalogique du premier ordre est PSPACE-complet ; de même pour une formule de lalogique monadique du second ordre. La vérification destructures automatiques avec une formule du premier ordre est décidable.

Abstraction

[modifier |modifier le code]

Des techniques comme CEGAR (Counterexample-Guided Abstraction Refinement, « raffinement de l'abstraction guidé par les contre-exemples »)[16] permettent de transformer un programme (écrit enC par exemple) en un modèle abstrait puis de raffiner successivement le modèle s'il est trop grossier.

Logiques modales

[modifier |modifier le code]

Leslogiques modales forment une extension de lalogique propositionnelle permettant de représenter desmodalités. Parmi celles-ci, on trouve par exemple les logiques temporelles, telles queLTL, CTL,CTL* ou lemu-calcul, mais aussi deslogiques épistémiques, deslogiques déontiques...Différents algorithmes de model-checking ont été conçu afin de traiter ces différentes logiques[17].

Logique pour les systèmes multi-agents

[modifier |modifier le code]

Dans lessystèmes multi-agents, on s'intéresse à des propriétésépistémiques comme « l'agent sait quex = 0 » d'où l'utilisation delogique épistémique et de logiques qui mélangent logique temporelle et épistémique[18]. On s'intéresse à raisonner sur l'existence de stratégies dans unjeu : il existe des logiques pour écrire des propriétés sur les jeux comme « l'agent a une stratégie pour qu'un jourx = 0 » (alternating-time temporal logic (en))[19].

Outils

[modifier |modifier le code]

Depuis 2011, les outils qui le souhaitent participent auModel Checking Contest[32] (MCC), compétition internationale scientifique permettant de comparer les performances des « model checkers » sur différents types de calculs.

Complexité

[modifier |modifier le code]

Un aspect important de la recherche enmodel checking est de démontrer qu'une certaine classe de propriétés, ou une certaine logique, estdécidable, ou que sa décision appartient à une certaineclasse de complexité. La table suivante indique les complexités du model checking pour les trois logiques temporelles LTL, CTL et CTL*. La quantité |M| est la taille du modèle représenté explicitement. La quantité |φ| est la taille de la spécification en logique temporelle. La complexité de programme évalue la complexité du model checking lorsque la formule temporelle est fixée[33].

Logique temporelleComplexité temporelle d'un algorithmeComplexité du model checkingComplexité de programme du model checking
LTLO(|M| ×2|φ|)PSPACE-complet[34]NLOGSPACE-complet
CTLO(|M| ×|φ|)P-completNLOGSPACE-complet
CTL*O(|M| ×2|φ|)PSPACE-completNLOGSPACE-complet

Orna Kupferman et Moshe Y. Vardi ont introduit le problème du model checking de systèmes ouverts, abrégé enmodule checking[35]. En module checking, l'entrée du problème est un système de transition où certains états sont contrôlés par le système proprement dit, et d'autres sont contrôlés par l'environnement. Une propriété temporelle est vraie dans un tel système de transition si elle est vraie quels que soient les choix de l'environnement. Plus précisément, étant donné un système de transition M, on considère son dépliage VM, qui est un arbre infini. Une propriété est vraie dans ce système si elle est vraie dans tout arbre obtenu en élaguant/supprimant de VM certains sous-arbres dont la racine est un successeur d'un état contrôlé par l'environnement. Pour le module checking, Orna Kupferman et Moshe Y. Vardi ont montré que les complexités atteignent celle du problème de satisfiabilité dans les logiques correspondantes :

Logique temporelleComplexité du module checkingComplexité de programme du module checking
LTLPSPACE-completNLOGSPACE-complet
CTLEXPTIME-completP-complet
CTL*2EXPTIME-completP-complet

Allur et al. ont étudié le model checking avec une extension de CTL et CTL* pour raisonner sur des stratégies dans un système multi-agent[19]. La table suivante donne les résultats de complexité pour le model checking sur ATL et ATL*.

Logique temporelleComplexité du model checkingComplexité de programme du module checking
ATLP-completNLOGSPACE-complet
ATL*2EXPTIME-completP-complet

Comme le signalent Allur et al.[19], le problème de model checking d'ATL* est proche du problème de synthèse LTL qu'ont développé Pnueli et Rosner[36], lui 2EXPTIME-complet également.

Algorithmes efficaces

[modifier |modifier le code]

Un autre aspect de la recherche enmodel checking est de rechercher des algorithmes efficaces sur des cas intéressants en pratique, de les implémenter, et de les appliquer à des problèmes réels.

Notes et références

[modifier |modifier le code]
  1. (en)« Amir Pnueli »,Association for Computing Machinery.
  2. E.Allen Emerson et Edmund M.Clarke, « Characterizing correctness properties of parallel programs using fixpoints »,Automata, Languages and Programming,‎(DOI 10.1007/3-540-10003-2_69).
  3. Edmund M. Clarke, E. Allen Emerson:"Design and Synthesis of Synchronization Skeletons Using Branching-Time Temporal Logic". Logic of Programs 1981: 52-71.
  4. E. M.Clarke, E. A.Emerson et A. P.Sistla, « Automatic verification of finite-state concurrent systems using temporal logic specifications »,ACM Transactions on Programming Languages and Systems,vol. 8,no 2,‎,p. 244(DOI 10.1145/5397.5399).
  5. Il est en particulier l'auteur de la première version du système CESAR :Jean-Pierre Queille, « The CESAR System: An Aided Design and Certification System. »,Proceedings of the 2nd International Conference on Distributed Computing Systems, Paris, France, IEEE Computer Society,‎
  6. J. P.Queille et J.Sifakis, « Specification and verification of concurrent systems in CESAR »,International Symposium on Programming,‎(DOI 10.1007/3-540-11494-7_22).
  7. (en)Press Release: ACM Turing Award Honors Founders of Automatic Verification Technology.
  8. USACM: 2007 Turing Award Winners Announced.
  9. En terminologie des structures de Kripke, on parle d'unmonde.
  10. En terminologie des structures de Kripke, on parle d'accessibilité.
  11. ChristelBaier et Joost-PieterKatoen,Principles of Model Checking (Representation and Mind Series),The MIT Press,, 975 p.(ISBN 978-0-262-02649-9 et0-262-02649-X,lire en ligne).
  12. « An introduction to model checking ».
  13. Matthew B.Dwyer, George S.Avrunin et James C.Corbett, « Patterns in Property Specifications for Finite-state Verification »,Proceedings of the 21st International Conference on Software Engineering, ACM, iCSE '99,‎,p. 411–420(ISBN 1581130740,DOI 10.1145/302405.302672,lire en ligne, consulté le)
  14. (en) EdmundClarke, ArminBiere, RichardRaimi et YunshanZhu, « Bounded Model Checking Using Satisfiability Solving »,Formal Methods in System Design,vol. 19,no 1,‎1er juillet 2001,p. 7–34(ISSN 0925-9856 et1572-8102,DOI 10.1023/A:1011276507260,lire en ligne, consulté le)
  15. (en) RajeevAlur, CostasCourcoubetis et DavidDill, « Model-checking for real-time systems »,Fifth Annual IEEE Symposium on Logic in Computer Science,‎,p. 414–425(ISBN 0-8186-2073-0,DOI 10.1109/LICS.1990.113766,lire en ligne)
  16. (en) EdmundClarke, OrnaGrumberg, SomeshJha et YuanLu,Counterexample-Guided Abstraction Refinement, Springer Berlin Heidelberg,coll. « Lecture Notes in Computer Science »,(ISBN 978-3-540-67770-3 et9783540450474,lire en ligne),p. 154–169.
  17. EdmundClarke et Orna Y.Grumberg, « Verification tools for finite-state concurrent systems. »,Lecture Notes in Computer Science,vol. 803,‎,p. 124–175(ISBN 9783540484233,lire en ligne, consulté le)
  18. (en) AlessioLomuscio et WojciechPenczek,Symbolic Model Checking for Temporal-Epistemic Logic, Springer Berlin Heidelberg,coll. « Lecture Notes in Computer Science »,1er janvier 2012(ISBN 978-3-642-29413-6 et9783642294143,lire en ligne),p. 172–195.
  19. ab etcRajeevAlur, Thomas A.Henzinger et OrnaKupferman, « Alternating-time Temporal Logic »,J. ACM,vol. 49,‎1er septembre 2002,p. 672–713(ISSN 0004-5411,DOI 10.1145/585265.585270,lire en ligne, consulté le).
  20. Alloy.
  21. AltaRica.
  22. UPPAAL.
  23. Ix-labs/apmc, ix-labs,(lire en ligne)
  24. CADP.
  25. Csml, Mcb.
  26. Smv.
  27. Spin.
  28. GerardHolzmann,Spin Model Checker, the : Primer and Reference Manual, Addison-Wesley Professional,, 596 p.(ISBN 0-321-22862-6,lire en ligne).
  29. Spot.
  30. NuSMV.
  31. Tina.
  32. Model Checking Contest.
  33. (en) Moshe Y.Vardi,Logics for Concurrency, Springer, Berlin, Heidelberg,coll. « Lecture Notes in Computer Science »,(ISBN 3-540-60915-6,DOI 10.1007/3-540-60915-6_6,lire en ligne),p. 238–266
  34. A. P.Sistla et E. M.Clarke, « The Complexity of Propositional Linear Temporal Logics »,J. ACM,vol. 32,no 3,‎,p. 733–749(ISSN 0004-5411,DOI 10.1145/3828.3837,lire en ligne, consulté le)
  35. (en) OrnaKupferman et Moshe Y.Vardi, « Module checking »,Computer Aided Verification, Springer, Berlin, Heidelberg, lecture Notes in Computer Science,‎,p. 75–86(ISBN 3540614745,DOI 10.1007/3-540-61474-5_59,lire en ligne, consulté le)
  36. (en) AmirPnueli et RoniRosner, « On the synthesis of an asynchronous reactive module »,Automata, Languages and Programming, Springer, Berlin, Heidelberg, lecture Notes in Computer Science,‎,p. 652–671(ISBN 9783540513711,DOI 10.1007/BFb0035790,lire en ligne, consulté le)

Voir aussi

[modifier |modifier le code]

Articles connexes

[modifier |modifier le code]

Bibliographie

[modifier |modifier le code]

En français

[modifier |modifier le code]

En anglais

[modifier |modifier le code]
v ·m
Codage
Modèles de calcul
Algorithmique
Syntaxe
Sémantique
Logique mathématique
Mathématiques discrètes
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Vérification_de_modèles&oldid=226525699 ».
Catégories :
Catégories cachées :

[8]ページ先頭

©2009-2026 Movatter.jp