La preuve

La preuve consiste à établir par une suite finie d’étapes de raisonnement (par mécanisme déductif ou par un système de réécriture) appelées inférence, qu’une certaine propriété est la conséquence logique d’axiomes ou d’un ensemble d’hypothèses décrivant le système étudié.

La preuve peut être appliquée à toutes les phases de développement du système, on peut par exemple chercher à prouver :

ƒ Qu’une spécification satisfait certaines bonnes propriétés

ƒ Qu’une étape de conception est correcte : une spécification détaillée satisfait une spécification plus abstraite (preuve de raffinement)

25

ƒ Qu’un programme est correct par rapport à une spécification détaillée (preuve de programme), ou qu’il termine toujours sous certaines conditions (preuve de terminaison). Une preuve peut être formelle ou informelle.

1.5.2.1 Preuve informelle

Une preuve informelle est une démonstration donnée en langage naturel, en utilisant éventuellement quelques notions mathématiques pour faciliter le discours. Dans le domaine informatique, la plupart des algorithmes de tolérance aux fautes sont publiés avec une preuve informelle. Une preuve informelle est validée par consensus : elle est lue et acceptée par les pairs. Ceci la distingue de la preuve formelle, qui peut être vérifiée automatiquement par des outils car le problème de vérification a été entièrement exprimé à l’aide des mathématiques.

1.5.2.2 Preuve formelle

L’assistance d’outil de preuve dans la preuve formelle nécessite la formalisation complète du problème de vérification. La description de l’algorithme, les hypothèses sur son environnement, et les propriétés attendues doivent être exprimées dans un langage ayant une syntaxe et une sémantique formelles, s’appuyant sur un cadre logique bien défini. Dans ce cadre, une preuve se ramène alors à des manipulations syntaxiques de formules. Les règles d’inférence indiquent comment produire des formules à partir des formules déjà produites, et une preuve peut être vue comme la construction d’un arbre de formules, dont les feuilles sont des axiomes et la racine la formule à prouver. Un cadre classique de preuve est le calcul des prédicats du premier ordre : il permet de raisonner sur des formules qui comportent des variables. Deux exemples de systèmes de déduction pour ce calcul sont la déduction naturelle et le calcul des séquents [Monin 00]. Il n’existe pas de procédure de décision qui, pour toute formule, déterminerait s’il existe une preuve ou non. Les démonstrateurs de théorèmes doivent donc mettre en œuvre des heuristiques, sans garantie d’aboutissement. En pratique, l’intervention d’un opérateur humain est souvent nécessaire pour guider la construction de la preuve. Malheureusement, il y a toujours le risque de se retrouver dans un cas d’échec de preuve : on ne peut arriver à déterminer si la formule à prouver est vraie ou non. L’investissement qu’a représenté la preuve a alors été inutile, ce qui constitue un sérieux inconvénient à l’utilisation de cette technique de vérification.

Pour permettre à l’utilisateur de comprendre la structure de la preuve, et faciliter l’analyse des parties en échec, il est souhaitable que l’environnement offre des facilités pour visualiser l’arbre de preuve. L’outil doit offrir une certaine visibilité sur les heuristiques qu’il a essayé de mettre en œuvre. L’arbre peut être montré à différents niveaux d’abstraction, par exemple en détaillant ou non les tactiques utilisées et les preuves de certains lemmes intermédiaires. Une étude des caractéristiques souhaitables des environnements de preuve peut être trouvée dans [Rushby 93] Nous présentons ci-dessous quelques outils et environnements de preuve existants.

26

1.5.2.3 Quelques outils et environnements de preuve

Il existe de nombreux systèmes de preuve. Selon le degré d’automatisation de la preuve, on parlera de vérificateur de preuve qui se contente de vérifier une preuve déjà construite, d’outil d’assistance à la preuve, ou de démonstrateur de théorèmes. Parmi ces outils nous citons :

Boyer-Moor : est un des ancêtres des démonstrateurs de théorèmes. Il est basé sur un système formel particulier, la logique de Boyer-Moor [Boyer et Moor 79] dans laquelle sont exprimées les propriétés à démontrer. Boyer-Moore comporte plusieurs heuristiques puissantes lui permettant de trouver des preuves non triviales, comme des preuves par introduction de lemmes. Il a été utilisé dans le projet SIFT [Wensly et al 78] dans les années 80.

LP (Larch Prover) [Garland et Guttag 91] : la spécification dans cet outil de vérification de preuve se fait en langage Larch [Guttag et al 85]. Le système est fondé sur un ensemble de fonctions déclarées, des propriétés et des axiomes sont exprimés sous forme d’équations, des règles de réécriture, des règles de déduction et des règles d’induction. La construction des preuves est assistée par le système TLP (Temporal Logic Prover) [Engberg 95] qui offre une extension du langage Larch pour la logique temporelle TLA (Temporal Logic of Action).

LCF (Logic of Computable Functions) [Gordon et al 79] : est un des premiers démonstrateurs de théorèmes. Il a été programmé en ML et son langage sert également à écrire des stratégies de preuve. LCF a aussi introduit le terme de tactique et l’idée de preuve à l’envers : un utilisateur commence avec le but désiré et divise ce but en sous-buts plus simples en appliquant des tactiques. C’est l’inverse de la façon dont les preuves mathématiques sont traditionnellement écrites.

Hol (Higher Order Logic) [Gordon et Melham 93] : il a été développé principalement à l’université de Cambridge. Ce démonstrateur de théorèmes a été utilisé essentiellement pour des preuves de conception de matériel notamment celle du microprocesseur tolérant aux fautes Viper pour le RSRE (Royal Signals and Radars Establishment du ministère de la défense Britannique). Un des aspects les plus attrayants de ce système est la possibilité de définir des tactiques de démonstration adaptées à certains problèmes et à certains langages de spécification. Le système HOL a aussi été utilisé dans les domaines de la vérification matérielle [Kropf 99] et de la vérification de systèmes distribués [Prasetya 95].

PVS (Prototype Vérification Système) [Owre et al 95] : est développé au SRI (International Computer Science Laboratory) à Palo Alto (USA). Le démonstrateur de théorème PVS a été appliqué à de nombreux problèmes réels tel que la spécification et la modélisation des systèmes de contrôle de vol tolérants aux fautes de la navette spatiale [Crow et Vito 96]. La majorité des travaux de preuve se font au niveau de la spécification. Ces travaux peuvent concerner les propriétés temporelles comme les travaux de Dutertre qui portent sur la preuve en PVS du PCP (Priority Ceiling Protocol) [Dutertre 00]. Il s’est intéressé aux propriétés de synchronisation et de respect d’échéance de tâche.

B [Abrial 96] : est une méthode formelle utilisée avec succès en milieu industriel notamment dans le domaine ferroviaire comme le projet Météor (ligne de métro automatisé) [Behnia et Waeselynck 99]. Elle couvre toutes les étapes de développement du logiciel, de la spécification

27

jusqu’à la génération de code exécutable. L’intérêt principal de la méthode B est dans la possibilité de raffiner une spécification de haut niveau en une spécification suffisamment détaillée pour pouvoir être automatiquement traduite dans un langage de programmation.

Les démonstrateurs de théorème AUTOMATH [De Bruijn 68], COQ [Barras et al 99] et le prover ISABELLE [Paulson 94] sont également utilisés avec succès en milieu industriel notamment au niveau de la vérification de programme.

1.5.2.4 Limites de la preuve

La vérification par preuve est difficile à utiliser et à automatiser. Particulièrement, en méthode B, la vérification des contraintes dynamiques d’un système est effectuée par une technique de preuve, ce qui requiert que l’utilisateur, en plus d’être un expert en spécification, soit également un expert dans l’utilisation de cette technique. En effet la vérification des contraintes dynamiques est confiée à un outil informatique de démonstration de théorèmes, mais dès que cet outil n’arrive plus à progresser seul vers la solution, il fait appel à l’utilisateur pour continuer à avancer. En pratique, la vérification par preuve de contraintes dynamiques est rarement obtenue de manière automatique. De plus, le démonstrateur de théorème est confronté d’une part à la vérification de la correction partielle d’une propriété, et d’autre part à une vérification de terminaison pour certains schémas de contrainte dynamique.

Une autre façon d’attaquer le problème de vérification par preuve (formelle) des propriétés de haut niveau est de décomposer ces dernières en des propriétés de bas niveau (locales) et de les vérifier séparément. Mis à part le problème de faisabilité d’une telle décomposition, des hypothèses implicites sur l’environnement peuvent être rajoutées sans pour autant être satisfaites en vie opérationnelle.

Pour les systèmes de contrôle/commande, une modélisation détaillée de ces derniers, reproduisant les interactions entre le programme de contrôle et l’environnement physique, en prenant en compte les lois physiques du procédé contrôlé, les dispositifs matériels pour assurer ce contrôle et les occurrences possibles de fautes pouvant affecter ces dispositifs, est généralement infaisable. L’utilisation des approches formelles pour la vérification des propriétés de haut niveau s’avère insuffisante. En effet, deux cas d’école, très utilisés par les approches formelles, ont montré leurs limites : la cellule de production [Lewerentz et Lindner 95] et la chaudière à vapeur [Abrial 96]. Ces deux études de cas ont servi d’illustration et de comparaison de plusieurs méthodes de spécification et de vérification formelles. Sur ces deux études de cas, certaines propriétés ont été prouvées par des approches formelles et ont pu être violées au cours de test sur simulateur de l’environnement physique en exécutant un code conforme à sa spécification [Waeselynck et Fosse 99], [AtelierB]. Ceci est dû au fait que la vérification formelle est effectuée sur un modèle du logiciel en formulant des hypothèses sur l’environnement qui ne sont pas nécessairement satisfaites en réalité.

Les outils de preuve actuels ne sont pas orientés vers une description simple et une preuve directe de la dynamique discrète de systèmes complexes. Ils cherchent à traiter simultanément les données et la structure de contrôle et ne sont donc pas adaptés à l'analyse des relations de cause à effet d'un système modélisé sous la forme d'un réseau de Petri ou d'un ensemble d'automates communicants. Les travaux de [Rivière 03], et de [Khalfaoui 03] que nous allons présenter

28

brièvement dans la suite de ce chapitre peuvent être vus comme une réponse à ce manque. En s'appuyant sur une logique non classique (la logique linéaire) ils ont construit une démarche de preuve [Rivière 03] qui à travers l'analyse des relations de cause à effet permet d'élaborer des scénarios menant à des situations critiques [Khalfaoui 03]. Avant d'aborder ce point nous allons présenter un tour d'horizon des techniques de preuve qui se posent en alternative pragmatique lorsque vérification et preuve sont en échec.