Atelier B et Rodin

Présentation des outils

Par rapport aux outils précédents, ces deux outils ne sont pas des outils que nous avons écrits, mais des outils existants.

L’atelier B² est l’outil de spécification de la méthode B. Il est développé par Clearsy. Il est nécessaire pour permettre de générer les obligations de preuves de cohérence de la méthode.

L’outil Rodin3 est l’outil de spécification de la méthode Event-B. C’est un outil basé sur Eclipse. Il permet de générer les obligations de preuves liées aux spécifications Event-B et décrites dans la méthode. De plus, puisqu’il est basé sur éclipse il permet l’ajout deplug-in. Unplug-in a d’ailleurs été développé pour traduire les spécifications Event-B en langage B (il s’agit de remplacer les mots-clés et certains opérateurs qui diffèrent légèrement). Si le développement de l’outil de spécification utilisant graphiti

1. https://github.com/ThomasFay/ASTD2B

2. www.atelierb.eu

pouvait être terminé, il serait intéressant d’utiliser le fait que les deux outils soient sous éclipse. On pourrait imaginer par exemple qu’on puisse extraire d’une spécification astd ^{l’ensemble des étiquettes de transition qu’elle contient et qu’on puisse créer} une machine contenant l’ensemble de ces étiquettes. On pourrait également imaginer qu’un plug-in permette de mettre en place la méthode de raffinement décrite dans la partie 2.3.2 et de générer les obligations de preuve associées.

Preuve de correction de la

traduction des automates en

langage B

3.1 Introduction

La méthode définie dans le chapitre 2 nécessite de traduire les_astddans le langage B. Dans sa thèse, Milhau [Mil11] a défini des règles de traduction systématique des astd ^{vers le langage B, mais sans en fournir la preuve de correction. Sans preuve de} ces règles de traduction, la confiance dans la méthode présentée diminue. Pour pouvoir utiliser notre méthode dans un cadre formel, il est important de valider la traduction des _astd vers le langage B. Il s’agit ici de montrer que toute spécification _astd traduite par notre outil est équivalente au sens de la bisimulation à la spécification en langage B obtenue après la traduction. Plusieurs méthodes permettent de valider une traduction d’un langage vers un autre.

La méthode la plus immédiate consiste à prouver la correction de l’outil de tra-duction. La preuve de l’outil de traduction consiste à montrer que la spécification obtenue après la traduction de n’importe quelle spécification valide est équivalente à

la spécification d’origine. C’est la méthode utilisée notamment dans le projet Comp-Cert [Ler09]. Ce projet a pour objectif d’écrire un compilateur C réaliste et certifié (un compilateur C est en fait un traducteur du langage C vers le langage assembleur). Dans le projet CompCert, la preuve de l’outil de traduction a été réalisée en utili-sant l’assistant de preuve Coq [Coq]. Le principal avantage de cette méthode est que l’utilisateur final peut utiliser l’outil de traduction en toute confiance. Cependant, à chaque changement d’un des langages ou du traducteur, l’outil de traduction doit être reprouvé intégralement.

Une deuxième méthode consiste à valider la traductiona posteriori [PSS98]. Dans cette méthode, l’outil de traduction est développé en utilisant des méthodes de dé-veloppement classiques et seul un outil de validation de la traduction est prouvé formellement. Après chaque traduction, l’outil de validation vérifie que la traduction obtenue est correcte. L’avantage de cette méthode est que généralement, la preuve de l’outil de validation est beaucoup plus simple que la preuve de l’outil complet, ce qui réduit considérablement les coûts de développement de l’outil de traduction. De même, si les langages ou l’outil de traduction changent, seul l’outil de validation doit être corrigé. Cependant, pour faciliter le processus de traduction, il est important de trouver un moyen d’automatiser la preuve de validité. De plus, cette méthode dé-place la découverte d’erreurs dans l’implémentation de la traduction au moment de l’utilisation de l’outil.

Enfin, une méthode non formelle consiste à faire écrire deux logiciels de traduction par deux équipes distinctes. À chaque traduction, on vérifie alors que les deux outils de traduction renvoient les mêmes résultats. Cette méthode permet de garantir plutôt facilement un niveau de confiance assez élevé. Cependant, pour pouvoir facilement comparer les spécifications obtenues après la traduction, les deux équipes doivent préalablement s’entendre sur des conventions d’écriture du langage cible. Et comme la méthode précédente, une traduction d’une spécification valide peut échouer et nécessiter des corrections de l’outil de traduction. C’est la méthode utilisée dans le projet METEOR d’automatisation de ligne 14 du métro parisien pour traduire les spécifications B en Ada [Dol06].

Dans le cadre de la méthode développée dans le chapitre précédent, nous sou-haitons traduire les _astd dans le langage B. La sémantique de ces deux langages

étant fixée, les règles de traduction ne sont pas amenées à changer. Il serait donc intéressant de développer un outil de traduction certifié. La certification d’un outil de traduction consiste à montrer que quelle que soit une spécification _astd valide donnée en entrée du traducteur, cette spécification peut être traduite en langage B et la spécification obtenue en sortie est équivalente à la spécification d’entrée au sens de la bisimulation. La preuve de bisimulation avec un assistant de preuve est un travail long. Pour des raisons de temps, seule une preuve partielle de l’outil de traduction a été réalisée. Les_astdsont des automates étendus par des opérateurs des algèbres de processus. Nous présentons la preuve que pour tout automate, si l’outil de traduction peut calculer une traduction, alors l’automate simule la spécification B obtenue par l’outil de traduction (ce qui correspond à la preuve de correction de la traduction). Les autres opérateurs des_astdne sont pas considérés. Pour réaliser cette preuve, les règles de traduction décrites dans la thèse de Milhau [Mil11] ont été traduites dans le langage de programmation de l’assistant de preuve Coq, qui a ensuite été utilisé pour effectuer la preuve de simulation. Un travail de preuve similaire aurait pu être réalisé avec l’outil Isabelle/HOL. Ici Coq a été choisi, notamment pour sa proximité avec le langage OCaml, dans lequel un analyseur syntaxique et un outil de traduction ont déjà été développés.

La suite du chapitre est organisée de la manière suivante. La section 3.3 présente la formalisation du problème. Nous y présentons la sémantique des automates des astd^{, la sémantique du sous-ensemble du langage B nécessaire pour la traduction,} les règles de traduction des automates et la formalisation du théorème à prouver. Pour chaque point, nous présentons quelques intuitions sur la manière de traduire ces formalisations en Coq. Dans la section 3.4, nous présentons le schéma de la preuve. Mais auparavant, la section 3.2 présente l’assistant de preuve Coq et les notions importantes à la compréhension de ce chapitre.