présentée pour obtenir le titre de DOCTEUR EN SCIENCES DE L UNIVERSITÉ DE PARIS 7 Spécialité : INFORMATIQUE présentée et soutenue publiquement par

UNIVERSITÉ PARIS 7 - DENIS DIDEROT UFR INFORMATIQUE THÈSE présentée pour obtenir le titre de DOCTEUR EN SCIENCES DE L UNIVERSITÉ DE PARIS 7 Spécialité : INFORMATIQUE présentée et soutenue publiquement par NÉSTOR CATAÑO COLLAZOS MÉTHODES FORMELLES POUR LA VÉRIFICATION DES PROGRAMMES JAVA Dirigée par : Me. Marieke HUISMAN Soutenue le : Novembre 2004 JURY M. Guy COUSINEAU,Président M. John HATCLIFF,Rapporteur M. Erik POLL,Rapporteur Me. Marieke HUISMAN M. Thomas JENSEN M. Hubert GARAVEL

.

. FORMAL METHODS FOR JAVA PROGRAMS

.

Acknowledgments I wish to thank Dr. Marieke Huisman for leading me during this thesis; her rigor and endeavor in every undertaken activity is worthy of admiration. Thanks to Dr. Willem Visser for inviting me to NASA Ames and discussing topics on model checking and symbolic methods, also thanks to Dr. Corina Pasareanu with whom I had fruitful discussions on automatic loop-invariant generation. Many thanks to Dr. Juan-Francisco Díaz-Frías who first introduced me to research; I will always remember pleasantly the time spent in the AVISPA team. Finally, thanks to Dr. Guy Cousineau who gave me the opportunity of starting studies in France, and thanks to Karina Olmos for reading carefully the previous of this thesis.

.

Contents French Summary / Résumé français 11 1 Introduction 37 1.1 Motivation.............................. 37 1.2 Context................................ 38 1.3 Thesis overview............................ 40 2 Formal methods for Java 47 2.1 Specification languages for Java................... 47 2.1.1 JML: The Java Modeling Language............. 48 2.1.2 The ESC/Java specification language............ 52 2.1.3 BSL:The Bandera Specification Language.......... 54 2.2 Tools using JML as specification language............. 55 2.2.1 ESC/Java........................... 55 2.2.2 An overview of other tools.................. 56 3 Formal specification and static checking of Gemplus s electronic purse using ESC/Java 59 3.1 General outline of the electronic purse............... 63 3.2 Specifications for Smart Card applets................ 66 3.2.1 Lightweight vs. heavyweight specifications......... 66 3.2.2 Defensive vs. offensive specifications............ 68 3.2.3 Level of abstraction of specifications............ 69 3.3 Specifications for the Java Card API................. 70 3.4 Specification and checking of the electronic purse......... 71 3.4.1 Specifying when the implementation does not match the informal documentation................... 77 3.4.2 Implementation mistakes.................. 79 3.4.3 Class invariants........................ 82 3.5 On the use of ESC/Java....................... 85 3.6 Formal verification of the class Decimal.............. 87 3.7 Conclusion.............................. 88

8 CONTENTS 4 Chase: a static checker for JML s assignable clause 91 4.1 JML s assignable clause...................... 94 4.2 A syntactical method to check assignable clauses........ 97 4.2.1 The rules defining mod, modfe and modsuf....... 98 4.2.2 The extended membership relation............. 103 4.3 Limitations of our method...................... 105 4.4 Chase: a checker for assignable expressions............ 106 4.5 Experiences using Chase....................... 106 4.6 Derivation example for checking the JML s assignable clause.. 108 4.7 Conclusion and future work..................... 110 5 Combining symbolic execution and model checking to reduce dynamic program analysis overhead 113 5.1 Semantics of the observer...................... 117 5.2 Symbolic execution of programs................... 120 5.2.1 A simple example syntax for our programs......... 120 5.2.2 Symbolic execution as a means of showing program correctness............................. 122 5.2.3 Symbolic execution in more detail.............. 123 5.2.4 Program correctness for infinite symbolic execution trees. 125 5.2.5 Proving loop invariants by property strengthening..... 128 5.3 Symbolic execution in Java PathFinder............... 130 5.4 Eliminating useless emissions for Java sequential programs.... 132 5.5 Eliminating useless emissions in cycles............... 135 5.6 Compositional Instrumentation................... 138 5.7 Conclusion.............................. 139 6 Event spaces: a model for multi-threaded Java programs 141 6.1 Java event spaces........................... 146 6.2 Generating and model checking Java event spaces......... 148 6.2.1 Keeping track of the parallel behavior........... 150 6.2.2 Event spaces as finite-state automata........... 153 6.2.3 JEvent: a tool to generate Java event spaces........ 154 6.2.4 Model checking event spaces................ 160 6.3 Slicing event spaces in a context without aliasing......... 160 6.4 Slicing event spaces in a context with aliasing........... 164 6.5 PVS formalization of the slicing algorithm............. 167 6.5.1 Modeling aspects related to the proof........... 168 6.5.2 Proving the slicing algorithm................ 173 6.6 Conclusion.............................. 183 7 Conclusion 185 A Rules for checking the JML s assignable clause 195

List of Figures 1 Automate pour (ab) +........................ 28 2 Le modèle de mémoire de Java................... 30 3 Guide de lecture........................... 34 2.1 Fragment of the annotated class Decimal............. 53 3.1 Structure of the purse package.................... 64 3.2 Relation diagram for purse classes.................. 65 3.3 Differences between offensive and defensive specifications..... 68 3.4 Relation diagram for packages in the purse............ 72 3.5 Inheritance diagrams for utils and pacapinterfaces packages. 74 3.6 Specifications for class TransactionInterface.......... 76 4.1 Syntax for assignable expressions.................. 94 4.2 Syntax for full expressions and suffix expressions......... 98 4.3 Derivation example from the electronic purse........... 108 5.1 Automaton for (ab) +......................... 118 5.2 A simple Java imperative language................. 119 5.3 Symbolic execution tree for AbsValue program.......... 125 5.4 Symbolic execution tree for GreatestCommonDivisor program. 126 5.5 k-step for GreatestCommonDivisor................. 128 5.6 Base case for GreatestCommonDivisor............... 129 5.7 Loop invariant strengthening.................... 130 5.8 Mapping for (ab) +.......................... 133 6.1 Java Memory Model formalization.................. 147 6.2 Java event space generation..................... 149 6.3 Keeping track of the parallel behavior............... 152 6.4 Event spaces as finite-state automata................ 153 6.5 Model checking event spaces..................... 161 6.6 Sliced event space.......................... 163 6.7 Sliced event space when considering aliasing............ 167 6.8 PVS proof tree for preserving slice if............. 176 6.9 PVS proof tree for preserving slice fi............. 177

.

Résumé français Il nous a paru nécessaire de commencer la rédaction finale de cette thèse en recherchant pour méthodes formelles des définitions qui fussent elles-mêmes formelles. Il nous semblait utile de les confronter avec celle que nous avions forgée pendant les années de recherches et de travaux préparatoires à cette thèse et à laquelle nous avait amené les références bibliographiques. La première d entre elles non seulement coïncide avec notre propre définition mais va encore beaucoup plus loin : A broad view of formal methods includes all applications of (primarily) discrete mathematics to software engineering problems. This application usually involves modeling and analysis where the model and analysis procedure are derived from or defined by an underlying mathematically precise foundation. Elle émane de Nancy Leveson, professeur en aéronautique et astronautique au MIT. Cette définition fournit une vue assez ample des méthodes formelles en les considérant comme tout ce qui concerne l application des mathématiques au problème de la construction des logiciels. D autres définitions moins générales que celle-là non seulement coïncident avec la définition que nous en avions tirée au cours de ces années mais aussi avec la définition communément admise qui existe dans le monde de la recherche. Celle qui suit 1 considère les méthodes formelles comme étant : mathematically based techniques for the specification, development and verification of software and hardware systems. Cette définition conçoit les méthodes formelles du point de vu de sa composante formelle. À son tour, cette composante formelle considère qu il existent deux champs où la formalisation peut être utilisée : l un pour décrire le système, et l autre pour raisonner sur le système lui-même. Les langages pour la spécification formelle des propriétés sont donc une partie fondamentale de l étude des méthodes formelles. 1 Elle a été prise du site de la bibliothèque virtuelle de méthodes formelles, http://vl.- fmnet.info/

12 Résumé français Pourtant, la définition qui s approche peut être le plus à notre propre définition est la suivante 2 A formal method in software development is a method that provides a formal language for describing a software artifact (e.g. specifications, designs, source code) such that formal proofs are possible, in principle, about properties of the artifact so expressed. Cette dernière définition non seulement retient la composante formelle, mais incorpore aussi une composante méthode. Ces deux composantes ensemble nous permettent de raisonner correctement et, à travers de l utilisation des raisonnements logiques, nous offrent la possibilité de démontrer nos conjectures sur le fonctionnement d un système. Évidemment, il n est pas nécessaire d avoir fait des études en logique pour raisonner de manière correcte. Aristote disait que habituellement toutes nos facultés marchaient bien. Il existe donc une logique intrinsèque à chacun d entre nous ; ce que l on pourrait appeler le bon sens. Celui-ci non seulement suffit pour franchir les obstacles de notre quotidien, mais aussi pour le développement des sciences, puisque ni le physicien ni le mathématicien ne démarrent leurs études par la logique. Ils font confiance au bon jugement de la raison. À part cela, il est clair qu une culture intellectuelle complète comporte le besoin de ne pas se contenter de la logique spontanée de l esprit et de sa logique naturelle. On a besoin d élaborer une logique scientifique qui garantisse la rigueur de l activité intellectuelle. Cette dernière logique, appelons-la logique formelle, est précisément ce dont on parle dans notre définition de méthodes formelles et non celle où l on fait entière confiance à notre bon jugement. L idée d utiliser une logique formelle comme principe de nos raisonnements n est pas tout à fait nouvelle, elle date en réalité de l époque des grecs. Le premier individu à définir une logique formelle fut Aristote qui inventa la théorie du syllogisme. Ceci est constitué d une argumentation où, à partir d un antécédent qui compare deux termes avec un troisième, s en déduit forcement un conséquent qui relie ou sépare les deux premiers termes. Cette théorie, ainsi que son système de déduction, même primitifs, ont constitué une source d inspiration pour la conception des logiques de actuelles. Ces nouvelles logiques et les méthodes de déduction sous-jacentes sont des parties fondamentales des outils modernes faisant des méthodes formelles. On ne devrait donc pas être traité d audacieux en affirmer qu Aristote, même de façon simple, utilisait des méthodes formelles dans ses raisonnements, sûrement pas pour décider si un certain programme C avait des effets de bord, mais peut être pour décider si la bonheur appartient aux hommes qui dorment, sujet qui d ailleurs me semble nettement plus compliqué. Seul le sujet d étude a changé, l objet lui reste le même. Par bonheur pour moi et pour celui de ma directrice de thèse, le sujet de ma thèse s adapte plutôt à la première catégorie, donc ne nous faisons pas de souci. 2 Cette définition a été prise du site Web du DACS, http://www.dacs.dtic.mil/techs/- abstracts/formal.html.

13 En plus d avoir besoin d une logique pour démontrer nos raisonnements, nous avons besoin d un langage de spécification pour pouvoir les exprimer. Dans la suite, nous aborderons le sujet des langages de spécification et de leur importance pour les méthodes formelles. Les langages de spécification. En bref, on définit une spécification comme une description abstraite du comportement d un système. On est donc intéressé à décrire ce que le système fait, plutôt qu à chercher à savoir de quelle manière le système le fait. Un des avantages de spécifier un système est que, même dans le processus de rédaction des spécifications, on est obligé de penser sérieusement au problème réel, et donc beaucoup d erreurs peuvent être détectées dès la spécification. Les spécifications sont souvent rédigées en langage naturel. Cependant, ceci n est pas souhaitable, car le langage naturel prête aux confusions et à l interprétation des individus. Pour donner un exemple, à partir de la seule phrase Espagnole ella duerme mientras que yo trabajo surviennent trois interprétations différentes en Français. À savoir, elle dort pendant que je travaille (au même temps), elle dort alors que (ou tandis que) je travaille (il y a un contraste), elle dort tant que je travaille (aussi longtemps que je travaille elle dormira). Pour cet exemple en particulier, on s aide en Espagnol, soit de la tonalité de sa voix, ou soit d un geste de contentement ou mécontentement, pour faire remarquer laquelle d entre ces trois interprétations notre interlocuteur est censé comprendre. Néanmoins, nous serions tout de même d accord pour affirmer que l interprétation humaine se prête aux ambiguïtés, et que deviner l intention de quelqu un en prenant comme point du départ la tonalité de la voix ou la couleur de sa peau est une affaire assez compliquée. Dans les systèmes formels de telles ambiguïtés ne sont guère désirables et doivent être évitées à tout prix. Une alternative aux langages naturels est donc de considérer l utilisation d un langage mathématique comme langage de spécification, évitant ainsi toute ambiguïté. Cette option est néanmoins difficile à mettre en oeuvre, car les langages mathématiques sont pleins de symboles compliqués à assimiler pour la plupart des utilisateurs de méthodes formelles. Dans nos temps modernes, une condition obligée pour un langage de spécification est qu il puisse être aisément utilisé par quelqu un qui n a a priori aucune connaissance des notations complexes de la logique. À quoi servirait-il d avoir un langage de spécification si finalement on ne peut pas l utiliser pour exprimer des propriétés auxquelles on est intéressé?. Ceci rejoint un des problèmes que je me suis posé pendant le déroulement de ma thèse : la spécification adéquate des applications, mais aussi le développement de techniques qui permettent d améliorer les langages de spécification déjà existants. En conséquence, on doit considérer des langages spécialement créés pour être utilisés en tant que langages de spécification, en ayant une syntaxe bien définie et une sémantique précise. Ces langages devraient être formels aussi, car autrement il existerait toujours le risque d introduire des ambiguïtés : si la propriété que

14 Résumé français l on veut spécifier ne coïncide pas fidèlement avec la propriété telle qu elle est interprétée par le langage de spécification, on serait donc en train de discuter sujets différents. On se sert souvent des langages de spécification pour faire des méthodes formelles. Ce dernier sujet est donc abordé dans la suite. À quoi ça sert les méthodes formelles? Les méthodes formelles peuvent concerner tout le cycle de développement des applications, dès l étape d élaboration du cahier de charges, en passant par la spécification, la conception de l application, le codage, et finalement les étapes de test et maintenance. De plus, les méthodes formelles ont influencé fortement le développement de plusieurs langages de programmation et des outils associés à ces langages. Les méthodes formelles permettent d assurer la fiabilité des applications, et par conséquent immédiate, elles nous permettent d empêcher la présence des comportements indésirables. Mais les méthodes formelles ont-elles aussi leurs limites. Prenons l exemple d un extrait de la revue Scientific American de 1994, repris de [67] : Despite 50 year of progress, the software industry remains years perhaps decades short of the mature engineering discipline needed to meet the needs of an information-age society. Apparemment, ce jugement semble sans appel. Toutefois, il nous reste donc à travailler pour réduire cette brèche entre l état de l art des techniques de vérification formelle, et les besoins existants. Sur les techniques pour la vérification formelle des applications. Le model checking (model checking) et la preuve de théorèmes (theorem proving) sont des techniques pour la vérification formelle dont l utilisation assez répandue dans certains centres académiques. Malheureusement, ces techniques ne comptent pas autant d adeptes dans le monde industriel qu on le souhaiterait. Dans la suite nous décrivons brièvement ces deux techniques. Le model checking est une technique pour la vérification automatique de systèmes réactifs. Elle a été conçue pour être automatique. Avec le model checking, le système à vérifier est modélisé comme une structure de Kripke, une sorte d automate qui étiquette chacun de ses états avec les propriétés qui sont vraies dans cet état. Á leur tour, les structures de Kripke peuvent être vues comme des arborescences (computation trees), autrement dit, comme des graphes formés quand on prend l état initial de la structure comme le sommet du graphe, et on forme les arcs a partir du système de transitions. Le graphe ainsi formé est infini. Le model checking [25, 9] est une méthode exhaustive qui consiste à explorer une arborescence pour vérifier une certaine propriété qualifiée de temporelle. Si la propriété n est pas vérifiée, une trace qui mène au bogue est affichée. En pratique, le model checking n est appliqué qu à des systèmes qui peuvent être exprimés comme des systèmes de transition d états. En plus, il doit être combiné avec d autres techniques, telles que les méthodes symboliques, pour

15 réussir à gérer des systèmes de grande taille. L idée sous-jacente aux méthodes symboliques consiste à représenter puis manipuler plusieurs états comme s ils n étaient qu un seul. Contrairement au model checking, la preuve de théorèmes est une technique déductive. Quand on fait de la preuve de théorèmes, on exprime en logique les propriétés auxquelles on s intéresse, et puis on utilise le système de déduction sous-jacent pour prouver que ces propriétés sont vérifiées. Le gros problème avec la preuve de théorèmes est son manque d automatisation. En outre, le processus de preuve est dispendieux et requiert l intervention de quelqu un qui maîtrise aussi bien la sémantique de la logique derrière le prouver que l outil implémente. Lorsque la mise en oeuvre de telles techniques formelles s avère impossible, on est souvent obligé d utiliser des techniques de vérification plus légères, c.à.d. moins formelles mais plus faisables. Il existe une ample gamme de ce genre de techniques, depuis le test (testing), en passant par l analyse statique (static checking) et arrivant à la vérification dynamique (runtime verification). Nous ne donnerons aucune description de telles techniques dans la suite ; remarquons seulement que dans le déroulement de cette thèse nous avons utilisé autant de techniques formelles que d informelles. Nous arguons même de l utilisation de telles techniques légères au préalable est souhaitable pour rendre la charge de la vérification formelle moins lourde. Dans le déroulement de ma thèse je me suis intéressé aux cartes intelligentes comme un des champs d application des techniques formelles de vérification. Cela constitue le sujet abordé dans la suite. Les cartes intelligentes : un premier champ d application pour les méthodes formelles. Comme conséquence de l influence de Internet dans le monde moderne, les types de transactions tendent à évoluer vers un système où le plus grand défi consisterait à s asseoir face à un ordinateur, de taper un code, et finalement de faire clic avec notre souris pour confirmer une transaction. La réussite d une transaction, faite que ce soit par Internet ou par un dispositif électronique, dépend en grande mesure de la fiabilité de la transaction. Les cartes intelligentes constituent un moyen efficace pour assurer le commerce. La fiabilité et la sécurité deviennent donc des sujets d étude importantes pour les personnes qui travaillent sur les cartes intelligentes. Les champs d application pour les cartes intelligents comportent l industrie de télécommunications, les cartes téléphoniques prépayées et les systèmes GSM (Global System for Mobile communication). Un téléphone GSM sans-fil est équipé d une puce qui se situe dans une rainure à l intérieur du téléphone. La puce est capable non seulement d identifier le porteur de la carte, mais aussi de lui fournir des clefs cryptées pour la communication vocale. La clef temporaire cryptée générée pour la puce est régénérée après chaque utilisation du téléphone. Cela afin de réduire la malveillance. Quand à leur apparence physique, les cartes intelligentes ont la même taille qu une carte de crédit, mais à la différence de celle-ci, elles sont fournies d une

16 Résumé français puce en silicone qui porte une mémoire et qui est capable de lancer (exécuter) un programme. Ce programme est capable de stocker et de traiter de l information, donc il ne requiert point de faire une transaction à longue distance. Une autre application pour les cartes intelligentes constitue les porte-monnaie électroniques. Un porte-monnaie électronique fournit à l utilisateur une appliquette (applet) capable de réaliser des opérations bancaires telles que crédit, débit et changement de monnaie. Ainsi par exemple, si la valeur de la transaction actuelle est au-dessus du balance du porte-monnaie, celui fera une requête à la centrale bancaire pour un crédit qui permettra de couvrir la différence. Si la centrale bancaire donne son feu vert à cette pétition, alors l utilisateur pourra finir normalement la transaction, et le crédit actuel sera donc mise à jour conformément à la valeur créditée pendant la transaction. Si la centrale en refuse, l utilisateur a encore une option. Puisque les cartes à puce gèrent un système de fidélité, à chaque fois que l utilisateur du porte-monnaie fait un achat, une somme de points de fidélité seront accumulés. Ces points de fidélité servent à jouer le rôle de points d achat (crédit) au moment où il n y aura plus de crédit disponible dans le porte-monnaie. Pendant le déroulement de ma thèse je me suis intéressé à la spécification et à la vérification de cartes intelligentes, en particulier à celles programmées en Java Card. Dans la suite nous donnons une description brève de Java Card, puis nous abordons le sujet des langages de spécification pour les applications Java. Java Card. Le langage Java Card possède la plupart des constructions du langage Java mais, pour des raisons de mise en oeuvre, quelques caractéristiques de Java ont été supprimées, notamment les types de données long, double et float, ainsi que les chaînes de caractères, les tableaux à plusieurs dimensions, le chargement dynamique de classes, le ramasse-miettes, les opérations multitâches, et finalement le clonage d objets. Toutefois, ce n est pas pour autant que Java Card manque d intérêt ; au contraire, l existence d un ensemble d instructions bien défini et une spécification plus claire (que Java) fait de Java Card une bonne base de travail pour les méthodes formelles. Les langages pour la spécification de programmes Java et Java Card. Quand on développe des applications de grande taille, une partie importante de notre temps se passe à rédiger la documentation de l application de manière claire et précise. La documentation sert aux développeurs pour la maintenance du code puisqu elle permet de mieux comprendre les décisions prises au moment de l écriture du code. Cependant, la documentation n est vraiment utile que si elle décrit l implémentation de manière exacte. Une façon d atteindre ce but consiste à écrire une spécification formelle, autrement dit, une description logique du fonctionnement du programme, et puis à vérifier sa correction. Récemment, des progrès importants ont été faits au niveau des langages de programmation et des outils de support à la programmation. D abord, on a vu apparaître des langages de spécification avec une syntaxe très proche

17 des langages de programmation. Cette décision cherche à faciliter la tâche de spécification menée par les programmeurs. Le langage de programmation Eiffel [69] fut le premier exemple d un langage de spécification qui ressembla à son propre langage de programmation. Également, plusieurs langages de spécification pour Java tels que JML [58, 59] (Java Modeling Language), ESC/Java [33] et Jass [49] furent créés. Ces langages suivent la même stratégie de Eiffel de ressembler à son langage de programmation. JML a été introduit par G. Leavens à l université de l Iowa, puis amélioré successivement par des personnes du monde de la recherche. Il existe également un groupe de nouveaux utilisateurs et de développeurs pour discuter de l amélioration du langage. Plusieurs aspects font de JML un langage intéressant pour spécifier des applications Java : i. il a été spécialement conçu pour cela et offre une syntaxe claire et intuitive pour quelqu un qui maîtrise la syntaxe de Java, ii. il compte beaucoup d adeptes non seulement en milieu académique, mais aussi récemment dans le monde industriel, iii. finalement, il existe de nombreux outils qui utilisent JML comme langage de spécification (dont JML lui-même) et qui font de la vérification formelle. Nous avons utilisé JML comme langage de spécification pour les applications Java Card auxquelles nous nous sommes intéressés. Dans la suite, nous donnons plus de détails sur le modèle général de spécification utilisé par JML, puis nous nous concentrons sur ESC/Java, un sous-ensemble de JML [30]. JML et le modèle de spécification par contrat. L idée de base qui soustend la spécification par contrat est qu il existe un contrat entre toute classe et tout objet (appelé client) qui se sert des méthodes de cette classe. Pour pouvoir appeler les méthodes d une classe, un client doit vérifier certaines conditions (les préconditions de la méthode). En retour, si un client vérifie la précondition d une méthode, une classe doit garantir qu après son exécution une certaine postcondition sera vérifiée. L idée d utiliser des préconditions et des postconditions pour spécifier des programmes n est pas tout à fait récente ; on la trouve déjà dans un article sur la vérification formelle écrit par C.A.R. Hoare en 1969 [45]. En revanche, ce qui est récent est l idée de rendre exécutables les contrats. JML a été conçu pour être facile à comprendre pour la moyenne des programmeurs de Java. En JML, les spécifications sont données en syntaxe Java et sont placées dans le code sous forme de commentaires. Les marques spéciales /*@...@*/ permettent aux outils de vérification utilisant JML de reconnaître les spécifications. Pour écrire des spécifications tenant sur une seule ligne, on utilise en JML la marque spéciale //@. Une spécification JML consiste à ajouter des préconditions et des postconditions à une méthode quelconque. Par exemple, une spécification telle que requires P; exprime que le prédicat P doit être vrai avant que la méthode puisse être appelée. La spécification ensures Q; dit que si la méthode ter-

18 Résumé français mine son exécution normalement, c.à.d. sans déclencher une exception, alors le prédicat Q sera vrai. En JML on peut spécifier aussi des postconditions d exception (exceptional postcondition) avec le mot-clé exsures ou signals. Une spécification telle que exsures (E) R; dit que si l exécution d une méthode déclenche une exception de type E, alors le prédicat R sera vrai. Il est courant par exemple de spécifier qu une exception est déclenchée avant qu un champ puisse être modifié. Cela permet de préserver l invariant d une classe. En JML, une spécification telle que invariant I; déclare un invariant I pour une certaine classe. Il est possible aussi de spécifier des conditions de modification (frame conditions) pour une méthode. Ainsi, une spécification telle que modifies L; dit que L représente le seul ensemble de cellules mémoire que la méthode en question peut modifier. En JML, les spécifications pour les préconditions, les postconditions et les conditions de modification sont placées juste à l avant de la déclaration de la méthode. Les prédicats P, Q et R ci-dessus sont formés par toute expression booléenne en Java n ayant pas d effets de bord. Ceci signifie par exemple que les opérateurs d incrémentation et de décrémentation, ++ et --, sont interdits dans les spécifications JML. Il en va de même pour les opérateurs =, +=, -=, etc. Une autre restriction imposée par JML est que les méthodes utilisées dans les spécifications ne peuvent effectuer d effet de bords. Expressions en JML. Nous décrivons dans la suite les extensions JML au langage Java. Premièrement, JML utilise le mot-clé \result pour décrire le résultat d une méthode. Ce mot-clé ne peut être utilisé que dans la postcondition normale d un méthode. Également la notation \old(e) décrit la valeur d une expression E avant l appel à la méthode respective. Cette notation est utilisée par exemple pour exprimer comment la nouvelle valeur d une variable quelconque dépend de son ancienne valeur. Remarquez que le seul endroit où l on peut utiliser \old dans une spécification est dans la postcondition (normale ou d exception). En aucun cas, il n est possible d utiliser \old dans une précondition, car la précondition est évaluée avant que l appel de la méthode ait eu lieu. JML comporte aussi des notations pour l implication logique, ==> et <==, pour l équivalence logique, <==>, et pour la non-équivalence, <=!=>. D autres opérateurs plus élaborés donnent à JML une flexibilité plus grande. Par exemple, les quantificateurs universel et existentiel (\forall T V; E) et (\exists T V; E), où T V déclare une variable V de type T, et E est l expression à vérifier. Nous illustrons notre propos avec l exemple de la méthode setheure de la classe Heure, une des classes spécifiées dans le cas d étude présenté au chapitre 3. La classe Heure déclare deux champs, heure et minute, qui ont comme fonction de modéliser les heures et les minutes. Le mot-clé /*@ spec_public @*/ permet à un champ privé d être utilisé dans une spécification publique. La précondition de la méthode setheure mot-clé requires dit que l on peut mettre à jour la valeur de l heure actuelle, à condition que cette valeur

19 soit entre 0 et 24. De même, les minutes doivent être entre 0 et 60. La spécification modifies heure, minute; dit que les seules variables que la méthode setheure peut modifier sont heure et minute. La postcondition normale mot-clé ensures assure qu après l appel à la méthode, heure aura la valeur h et minute la valeur m. Enfin, la postcondition d exception mot-clé exsures dit qu en aucun cas la méthode ne déclenchera une exception de type HeureException. public class Heure extends Object { private /*@ spec_public @*/ byte heure; private /*@ spec_public @*/ byte minute; /*@ @ requires h >= 0 && h < 24 && m >= 0 && m < 60; @ modifies heure, minute; @ ensures heure == h && minute == m; @ exsures (HeureException) false; @*/ public void setheure(byte h, byte m) throws HeureException{ if ( 0 <= h && h < 24 ){ if ( 0 <= m && m < 60 ){ heure = h; minute = m; else HeureException.throwIt(HeureException.ERREUR_MINUTE); else HeureException.throwIt(HeureException.ERREUR_HEURE); Les invariants et les contraintes en JML. Le comportement attendu d une classe quelconque peut être restreint par la déclaration d un invariant. Les invariants sont des propriétés qui doivent être vérifiées dans tout état visible. Les états visibles sont le début et la fin de toute méthode publique, mais aussi la fin de tous les constructeurs de classe. Les spécifications pour les invariants sont placées tout au début de la classe. Par exemple, l invariant suivant pour la classe Heure déclare que les champs heure et minute auront toujours des valeurs dans des intervalles acceptables. public class Heure extends Object{ //@ invariant heure >= 0 && heure < 24; //@ invariant minute >= 0 && minute < 60;.

20 Résumé français.. Il est possible aussi de restreindre l ensemble d états atteignables par un objet, en utilisant des spécifications du type constraint. Une contrainte est une relation entre la précondition et la postcondition d une méthode qui restreint la façon dont une variable peut évoluer. Par exemple, on pourrait spécifier qu une variable est en fait une constante, ou que cette variable peut seulement être incrémentée. Remarquez qu il est possible d exprimer des invariants et des contraintes en termes des préconditions et postconditions des méthodes de la classe. Toutefois, si l on spécifie explicitement un invariant ou une contrainte, on gagnera en abstraction. Les assertions. Il peut arriver aussi que l on souhaite rendre explicite l intention qu une condition doit être vérifiée à un certain point du programme. Pour cela, JML fournit la construction assert. Si une méthode possède une spécification assert P; à un certain point de contrôle, cela indiquera qu à chaque fois que l exécution atteint ce point de contrôle, la condition P doit être vérifiée. Cela sert, par exemple, à établir que certains points de contrôle dans une méthode ne seront pas atteints. Également, on utilise les constructions assert pour dessiner des traces de preuve, autrement dit, pour indiquer tous ces points intermédiaires qu une preuve doit respecter. Les variables abstraites. Finalement, pour atteindre un certain niveau d abstraction dans les spécifications, JML nous permet de déclarer des variables abstraites (model variables). Ces variables existent seulement au niveau de la spécification et non au niveau de l implémentation. Les variables abstraites se déclarent de la même façon que les variables normales mais, à la différence d une variable concrète, une variable abstraite est précédée par le mot-clé model. On peut exprimer une relation entre une variable abstraite et une variable normale à travers l un des mots-clés represents ou depends. Le mot-clé represents sert à spécifier comment la valeur d une variable abstraite peut être calculée à partir de la valeur d une variable concrète. Le mot-clé depends spécifie de quelles variables concrètes une variable abstraite dépend. Pour plus d information sur l utilisation des mots-clés represents et depends, et de leur utilisation en vérification modulaire, le lecteur est prié de consulter le travail de K.R.M. Leino en [60]. Maintenant, nous donnons plus de précisions sur ESC/Java. Le langage de spécification ESC/Java. Le langage de spécification utilisé par ESC/Java n est pas exactement un sous-ensemble de celui utilisé par JML [30]. Toutefois, dans le cadre de ce document, les différences exactes entre ces deux langages n ont aucune importance. La seule chose que l on doit savoir ici, c est que ESC/Java supporte tous les mots-clés déjà introduits pour JML, à l exception de constraint et model. En outre, ESC/Java fournit une variante

21 plus simple des variables abstraites : les variables ghost. Néanmoins, avec la construction ghost de ESC/Java, aucune clause depends ou represents n a été introduite. Maintenant, nous effectuons un survol des outils qui utilisent JML en tant que langage de spécification. Les outils qui utilisent JML comme langage de spécification. Il existe une large gamme d outils qui utilisent JML comme langage de spécification, est qui font que JML est devenu le langage standard pour spécifier les programmes Java. Puisque nous avons utilisé ESC/Java dans le déroulement de cette thèse, nous démarrons notre présentation par cet outil. Pour avoir une description complète des outils utilisant ESC/Java et JML comme langage de spécification, le lecteur est invité à consulter [13]. ESC/Java. ESC/Java a été développé à Compaq dans le groupe dirigé par K.R.M. Leino [63]. Actuellement, il n est plus maintenu par le groupe de Compaq, mais reste toujours disponible depuis leur site Web. Le but initial de ESC/Java était le développement d un outil pour trouver de manière efficace des erreurs qui apparaissent souvent en programmation, par exemple l accès à un tableau hors de ses bornes, ou la référence à l objet null. Pour vérifier une spécification, comment ESC/Java procède-t-il? D abord, il génère des obligations de preuve basées sur les spécifications et le code du programme. Les conditions de preuve sont ensuite envoyées vers l outil de preuve Simplify associé a ESC/Java 3. Si Simplify n arrive pas à vérifier l obligation de preuve, alors ESC/Java fait un rapport d erreur. Cependant, ce rapport d erreur n implique pas forcement que le programme est incorrect, car Simplify et ESC/- Java lui-même sont incorrects et incomplets. Les concepteurs de ESC/Java ont fait ce choix pour des raisons de simplicité et d efficacité. Nous présentons rapidement l un des cas qui rendent cet outil incomplet. Par exemple, ESC/Java effectue des abstractions sur des boucles en remplaçant toute instruction while(c){b par un simple test if(c){b, ce qui revient à remplacer plusieurs itérations par une seule. Le manuel de ESC/Java [63] fournit une liste complète de toutes les sources d incomplétudes de ESC/Java. LOOP. L outil LOOP a été développé à l université de Nimègue. Le but principal de cet outil est d offrir un environnement de vérification correct, afin que des programmes Java spécifiés avec JML puissent être vérifiés avec PVS [73]. Le fonctionnement de LOOP est assez simple. Grosso modo, le compilateur de LOOP est alimenté avec le code Java et les spécifications JML. À partir du code Java, le compilateur génère du code PVS. Cette génération de code est basée sur la définition PVS de la partie séquentielle de Java qui existe dans LOOP. Puis, les spécifications JML sont traduites sous forme de prédicats. Le 3 Pour plus d information sur Simplify, consultez http://research.compaq.com/src/esc/- Simplify.html.

22 Résumé français travail consiste donc à prouver (avec PVS) ces prédicats sur le code PVS généré à partir du code Java. Un survol d autres outils. Dans l intention d illustrer l ample gamme de techniques formelles pour JML qui sont disponibles aujourd hui, dans la suite nous donnons un survol d autres outils qui utilisent JML comme langage de spécification. Nous commençons par JML lui-même. Dès le départ, JML fut pensé pour être utilisé avec un vérificateur dynamique des assertions (runtime assertion checker). L outil JML, développé à l université d état de l Iowa, fait exactement cela : il traduit des spécifications JML sous forme de vérifications effectuées à l exécution. Lorsque le code traduit est exécuté, JML déclenche une exception si la spécification n est pas vérifiée. D autres outils ont été inspirés par ESC/Java. Par exemple, Chase (chapitre 4), développé à l INRIA de Sophia Antipolis, est un outil qui vérifie l utilisation correcte des spécifications modifies dans des annotations JML. Également, Calvin [37], développé à Compaq, est utilisé pour vérifier des propriétés de programmes Java multi-tâches. Calvin utilise une technique qui consiste à exprimer obligations de preuve multi-tâches en obligations de preuve mono-tâches qui seront ensuite vérifiées avec ESC/Java. Plan de cette thèse Cette thèse porte sur l utilisation adéquate des méthodes formelles pour la vérification de programmes Java. Nous défendons l idée que les techniques de vérification ne sont pas seulement importantes pour elles-mêmes, mais surtout par leurs domaines d application. Nous pensons même que seule l utilisation commune de plusieurs techniques de vérification rend possible la vérification d applications significatives. Le chapitre 3 est un exemple clair de ce genre de travail : nous démontrons que l utilisation des techniques d analyse statique telles qu elles sont conçues par ESC/Java et de la preuve de théorèmes à la manière de l outil LOOP peut augmenter notre confiance en la correction d une application. Grosso modo, on fait d abord de l analyse statique pour se débarrasser des bogues les grossières, qui compliqueraient sinon la vérification formelle proprement dite, et puis on fait de la vérification formelle sur les parties du code qui ont besoin d être certifiées. Le chapitre 4 poursuit cet esprit en améliorant la vérification telle qu elle est conçue par ESC/Java. En bref, ESC/Java ne vérifie pas les spécifications élaborées avec le mot-clé modifies. Pour résoudre cela, nous avons conçu et implémenté une méthode pour faire cette vérification. Ceci nous a permis aussi de corriger et d améliorer les spécifications élaborées au chapitre 3. Le chapitre 5 démontre que le model checking, lors qu il est complété par des techniques d exécution symbolique, s avère plus important, en tant que méthode de preuve, que le model checking explicite (explicit state model checking) 4. L uti- 4 Cette phrase met en avant le fait que nous considérons le model checking une technique de réfutation plutôt que de preuve.

Plan de cette thèse 23 lisation commune de ces deux techniques nous a permis de prouver que certaines parties du code d un programme sont inutiles, puisqu elles ne modifient pas la validité des propriétés sous-jacentes. Le chapitre 6 va au delà de la vérification de programmes séquentiels et aborde le sujet de la vérification de programmes Java multi-tâches. Nous proposons l utilisation des espaces d événements Java (Java event spaces) comme modèle pour nos programmes. L un des aspects le plus intéressants de l utilisation d espaces d événements Java comme modèle est qu ils considèrent finement l évolution des objets en mémoire. En plus, un espace d événements peut être mis sous une forme permettant le model checking. Nous démontrons que l utilisation d une technique telle que l abstraction par tranches (slicing) rend possible l utilisation du model checking sur le modèle proposé. Dans la suite nous décrivons en détail chaque chapitre de cette thèse. Chapitre 3. Spécification et vérification formelle d une application carte à puce. Le chapitre 3 présente la spécification et la vérification formelle d une appliquette Java Card qui implémente un porte-monnaie électronique. Pour cette appliquette, nous avons spécifié en JML 27 classes et 432 Ko entre le code et la documentation, puis nous avons vérifié cette spécification avec ESC/Java. Le travail fait dans ce chapitre cherche à démontrer comment notre approche de spécification et de vérification dans le cadre de ESC/Java complète parfaitement celle utilisée par C. Breunesse, B. Jacobs et J. van den Berg in [11, 12]. Ceux-ci ont vérifié des algorithmes mathématiques très complexes dans le cadre de LOOP [65]. En utilisant ESC/Java, ou d autres outils qui font de l analyse statique, ces algorithmes n auraient pas pu être vérifiés. En revanche, la vérification complète de l appliquette Java Card, telle que nous l avons faite, n aurais pas pu atteindre sa fin avec LOOP. Cet outil est plutôt utilisé pour vérifier des programmes de petite taille. Nous ne soutenons pas que l approche à la spécification et à la vérification telle que nous la concevons est meilleure que celle des auteurs cités auparavant. Au contraire, nous arguons que ces deux approches à la vérification se complètent de façon très naturelle, et doivent donc être utilisées ensemble. En bref, nous considérons que pour vérifier une grosse spécification, on devrait faire de l analyse statique au style ESC/Java au préalable. Cela permettrait de détecter des bogues qui troublent l application, et permettrait d augmenter notre niveau de confiance en la spécification, qui doit décrire fidèlement l implantation. Ensuite, on devrait faire de la vérification formelle à la manière de LOOP. Ainsi, l effort consacré à la vérification formelle serait nettement réduit. Ce chapitre présente les spécifications en JML que nous avons élaborées. Nous démontrons que la spécification formelle d un programme permet de créer une documentation libre d ambiguïtés. Nous discutons aussi sur la possibilité d améliorer le code source, en supprimant les parties qui ne seront jamais atteintes par l exécution d un programme. La réduction de la taille des programmes est un problème vital pour les applications Java Card, puisque en Java

24 Résumé français Card la quantité de mémoire utilisée par un programme lors de son exécution ne doit pas dépasser une certaine limite. Nous avons démarré la spécification du porte-monnaie électronique par des propriétés qui étaient décrites dans la documentation informelle de l application. Puis, lors de la vérification, nous avons trouvé que plusieurs de ces propriétés n étaient pas vérifiées. À la différence de la documentation informelle que l on incorpore dans le code source d un programme, les spécifications en JML n ont pas d ambiguïté. Par conséquent les spécifications en JML fournissent une description formelle du comportement attendu de l application. À notre connaissance, la spécification que nous avons élaborée en ESC/- Java constitue la plus grande spécification existante à ce jour. Ce travail de spécification et de vérification que nous avons mené a agréablement surpris l équipe de Gemplus, à tel point que ses ingénieurs ont construit leur propre outil de vérification appelé Jack [14] 5. Á partir des spécifications JML, Jack génère des obligations de preuve, lesquelles sont prouvées ensuite en utilisant les plates-formes de vérification supportées par Jack. Finalement, nous avons élaboré une liste des points faibles de ESC/Java. Ces points faibles comportent des problèmes avec le langage de spécification aussi bien que des inconvénients avec le vérificateur Simplify de ESC/Java. La plupart de ces points faibles ont été pris en compte dans la construction de la nouvelle version de ESC/Java, appelée ESC/Java 2. Cette nouvelle version de ESC/Java a comme but de rendre compatible les langages de spécification de JML et de ESC/Java. Le développement de cette nouvelle version est conduit par J. Kiniry, qui travaille à l université de Nimègue dans le group SoS, et D. Cok, qui travaille à Kodak. Chapitre 4. Chase : un vérificateur statique de la clause assignable de JML. Une des faiblesses de ESC/Java est qu il ne vérifie pas les spécifications construites en utilisant le mot-clé modifies. Nous considérons qu il s agit d une lacune importante à laquelle nous allons essayer de remédier. En JML, une spécification telle que modifies L; exprime le fait que l ensemble de cellules mémoire telles qu elles sont décrites par L sont les seules cellules que la méthode peut modifier. Pour mieux comprendre l importance de la vérification des spécifications construites en utilisant le mot-clé modifies, nous devons d abord parler sur la vérification modulaire dans ESC/Java. En ESC/Java la vérification est faite de façon modulaire, chaque méthode à la fois. À cause de la liaison dynamique (Dynamic binding), quand on fait de l analyse statique, on ne peut pas établir à l avance laquelle des implémentations une méthode est censée utiliser à l exécution : si celle de le type de l objet dans la déclaration, ou celles des ses sous-classes. Nous avons donc décidé de suivre l approche proposée dans [64] qui utilise le type statique de l objet qui appel la méthode. En plus, pour réduire l incorrection (unsoundness), on doit démontrer que la méthode dans la sous-classe vérifie la spécification de la méthode dans la 5 Jack est développé actuellement au sein du groupe Everest [34] à l INRIA de Sophia Antipolis

Plan de cette thèse 25 sur-classe. Quand on raisonne de cette façon, la seule spécification fonctionnelle d une méthode (voir préconditions et postconditions) ne suffisent pas pour la vérifier. On a besoin de savoir aussi quelles variables la méthode est capable de modifier. Pour mieux comprendre cela, prenons le code suivant : public class C { int[] arr; //@ postcondition arr.length >= 4; public void m(){ arr = new int[5]; p(); //@ modifies \nothing; public void p(){ arr = new int[2]; Pour établir la postcondition de la méthode m, laquelle dit que le nombre d éléments du tableau arr ne sera jamais inférieur à 4, la méthode p (appelée depuis m) doit garantir qu elle ne modifie pas l état de la mémoire, c.à.d. elle modifies \nothing;. Si la spécification de p n est pas vérifiée, alors la vérification de m devient impossible. Pour corriger cela, nous avons défini un ensemble de règles syntaxiques qui vérifient que l implémentation d une méthode ne modifie pas de cellules mémoire autres que celles spécifiées par le mot-clé modifies. Puis, nous avons fourni une implémentation sous le nom de Chase. Pour donner un exemple de comment la vérification des spécifications construites utilisant le mot-clé modifies fonctionne, prenons le cas de la vérification de l assignation x = E ; contre la spécification modifies L;. Pour vérifier cette assignation, on doit vérifier que x est compris dans L, et puis récursivement vérifier E contre L. Cela peut être exprimé pour la règle Assg présentée en bas. Dans cette règle, ce qu il y à gauche du symbole mod corresponde á l expression à être vérifiée, et ce qu il y a à sa droite les seules cellules mémoire qui peuvent être modifiées. x L E mod L (Assg) x = E mod L Nous ne donnerons plus de détails sur ces règles, cela constitue le sujet auquel le chapitre 4 a été consacré. Nous voulons tout simplement remarquer ici que la vérification en question devient plus compliquée lorsque l on considère la syntaxe de Java et des expressions modifies en leurs totalité. Ainsi par exemple, dans L, il n est seulement possible de faire allusion à un tableau a à une certaine position i, a[i], ou faire allusion à tous les éléments du tableau, a[*], mais aussi aux champs d un objet o quelconque, \fields_of(o). Chapitre 5. Utilisation de l exécution symbolique comme un moyen pour réduire des émissions inutiles. Le chapitre 5 traite le problème de