Vérification de propriétés temporelles par génération d annotations

Transcription

1 Université de Franche-Comté École doctorale SPIM UFR Sciences et Techniques Vérification de propriétés temporelles par génération d annotations THÈSE présentée et soutenue publiquement le 14 Septembre 2007 pour l obtention du grade de Docteur de l université de Franche-Comté (Spécialité Informatique) par Julien Groslambert Composition du jury Président : Directeurs : Rapporteurs : Examinateurs : Olga Kouchnarenko, Professeur à l Université de Franche-Comté, LIFC Jacques Julliand, Professeur à l Université de Franche-Comté, LIFC Alain Giorgetti, Maître de conférences à l Université de Franche-Comté, LIFC Christine Paulin-Mohring, Professeur à l Université Paris XI, LRI Sophie Tison, Professeur à l Université de Lille I, LIFL Françoise Bellegarde, Professeur à l Université de Franche-Comté, LIFC Loïc Correnson, Ingénieur de recherche à Trusted Logic Philippe Devienne, Chargé de Recherche au CNRS, LIFL Laboratoire d Informatique de l Université de Franche-Comté

2 Mis en page avec la classe thloria.

3 1 Remerciements Je tiens, tout d abord, à remercier comme il se doit mes deux encadrants, Jacques Julliand et Alain Giorgetti, pour leurs précieux conseils donnés tout au long de ces trois années, l écoute sans faille qu il ont su m accorder, qui a largement contribué à l aboutissement de ce travail, et l aboutissement, je l espère, de futurs collaborations. Je souhaite également remercier Olga Kouchnarenko, qui m a encadré durant la première année, pour sa forte implication dans ces travaux. La pertinence et la rigueur scientifique qu elle a apportées à nos collaborations, ainsi que sa sympathie et sa gentillesse naturelle, me laissera un excellent souvenir. Un grand merci également à Christine Paulin et à Philippe Devienne d avoir accepté la lourde et difficile tâche de rapporter ce travail. J en suis très honoré et je les remercie sincèrement, d une part, pour l intérêt qu ils ont porté à ce manuscrit, et d autre part, pour leurs remarques pertinentes qui ont permis d en améliorer la qualité. Je souhaite également remercier Loïc Correnson d avoir accepté de faire partie de ce jury en apportant ses compétences et son éclairage d ingénieur de recherche dans le milieu industriel, qui fûrent le fruit d intéressantes discussions cette dernière semaine, et qui, j espère, posent les fondations d une excellente collaboration à Trusted Labs. Enfin, je souhaite remercier Françoise Bellegarde, qui avait encadré mon DEA, pour son implication tout au long de ses trois années, ses précieux conseils distillés avec générosité et son enthousiasme permanent 1. Je souhaite remercier tous les membres du projet Geccoo 2, dans lequel s est intégré ce travail de thèse, ainsi que toutes les personnes qu il m a été donné de rencontrer dans le cadre de mes travaux et qui ont contribué, de façon directe ou indirecte, à la réussite de ce travail 3. Je souhaite également remercier, bien entendu, tous les membres du LIFC pour leur accueil chaleureux. Je n oublierai pas tous les moments de convivialité, les mercredis croissants, les journées des doctorants et autres réjouissances, mais également tous ces petits instants anecdotiques, les sourires dans les couloirs, les discussions endiablées devant la machine à café, qui additionnés les uns aux autres, font que l on se sent bien. En particulier, je salue les membres du désormais célèbre et mythique bureau 414C, les deux gardiens de ce temple de la science et l humour, Pierre-Cyrille et Frédéric, avec qui se fut un plaisir de partager la studieuse ambiance de travail, certe parfois interrompue par les inoubliables interventions de NS, les bonnes blagues du vendredi de Pierre-Cyrille, mes innom- 1 Et de lui souhaiter cette fois une très bonne vraie retraite, à présent que le dernier thésard en a terminé. 2 en particulier, un grand clin d œuil à Nicolas Stouls - courage la ligne d arrivée n est plus très loin. 3 Vive les EJCPistes 2005! Un petit salut à Pascal Fontaine - j ai fait un choix difficile - mais on se recroisera, je l espère de tout coeur.

4 2 brables gaffes 4. Je les remercie d avoir supporté l immense et abyssal désordre de mon bureau 5. Ces deux compères furent remplacés, au gré des changements de bureaux et des départs, Hala et Kamal. En compagnie de ces deux nouveaux collègues, touours souriants et adorables, le bureau 414C pris des allures de palais oriental, avec toutes ces pâtisseries délicieuses rammenées du Liban, bref, un petit coin de paradis pour terminer cette thèse. Cette fin de thèse marque également un changement de vie, de ville, de travail. Je ne sais pas si je rentrerai, plein d usage et raison, vivre entre mes parents, le reste de mon âge, mais j espère resté fidèle à mes deux petits Lyré à moi, Fontain et Besançon, où j ai passé tant d années et de bons moments. Je tiens à remercier tous les amis avec qui j ai partégés ces années et ces soirées, et plus particulièrement Nathalie 6, Yohann, Yann, Mathieu et Céline, Sabrina, Fix, Vincent, Pierre, Fabien 7, Julien, Sebastien, Tonio et la Ch tite Marie, Julien et Virginie 8, Elodie, Aude 9, Sylvain, Guillaume, Soisic, et tous les autres... Je tiens à avoir une pensée pour Magdalena, qui avait partagé ces trois ans de ma vie, Magdalena, Magda, Madzia, Madziunia, Madziuninucka. Je remercie également tous les amis parisiens et provinciaux de Peplum, et plus particulièrement par ordre preque alphabétique, Amandine,Améleia, Elise, Guilaine, Jean-Rémi, Jurassic, Lamalie 10, Lethée, Manon, Nolwenn, Solenn, Sophie et Montalte 11. Je souhaite également saluer tous les membres des clubs de Judo de Merey-sous-Montrond et Ecole Valentin, et plus particulièrement mon professeur, Jacky Carrez, ainsi que tous les membres du bureau de Merey-sous-Montrond, Jacques, Nadine, Guy, Thierry, Daniel, Pierre et Alexandre, qui m ont aidé, durant cinq ans, à m occuper de ce club. Un grand merci également à toute l équipe de Tango du Kiosque à Besançon et de Tango d or à Dijon, qui m ont fait découvrir cette danse si passionnante. En particulier, un grand merci à tous mes professeurs, Georges et Nadine, Claude et Fabienne, Stéphane et Carolina. Je salue également les salseros et salseras des lundis et vendredis soirs, l équipe du Théâtre de Fontain et le club photo de Gennes où j ai passé de mémorables soirées. Enfin, je tiens à remercier toute ma famille, et particulièrement mes parents et ma petite soeur adorée, mes deux grand-mères, mon parrain et ma marraine, pour leur soutien dans mes choix de carrière, et pour tant d autres choses... 4 je me souviendrai en particulier du jour où je les avaient enfermés dans le bureau en partant le soir 5 et d avoir su apprécié à sa juste valeur les qualités sonores de mon légendaire rire, qualifié d à la fois animal et surréaliste... et vive les lapins et les infirmières! 6 7 ans! 7 les marches de la citadelle, je m en souviendrai longtemps 8 fini les soirées pizzas/mamie nova du mercredi soir 9 il faudra te trouver un nouveau second cavalier pour les soirées, à moins que l on garde le titre à vie 10 qui pourra ajouter sur son site internet qu après la radio et le Figaro, que c est la première fois que le mot péplaute apparait dans une thèse scientifique 11 D où l ordre presque alphabétique, nous n allons pas laisser ce cher Pierre perdu au milieu de tous les autres.

5 Cette thèse est dédiée à Françoise Bellegarde Merci pour tout... 3

6 4 Cette thèse est également dédiée à Alfred Monterosso, mon grand-père, qui aurait, été si heureux d être là aujourd hui...

7 Table des matières I Contexte et problématique 13 1 Introduction La démarche de vérification et validation formelle de logiciels Problématiques abordées et contexte des travaux Vérification de propriétés temporelles Annotations de programme Génération automatique d annotations Programmation orientée objet Génération automatique de tests Contributions Contributions - Axe 1 : Génération d annotations à partir de propriétés temporelles Contributions - Axe 2 :Vérification de la cohérence d un ensemble d annotations Contributions - Axe 3 : Génération de tests à partir de propriétés temporelles et validation Plan du mémoire Panorama des travaux connexes aux contributions de cette thèse Logiques temporelles Généralités sur les logiques temporelles La logique temporelle linéaire et les automates de Büchi Vérification de propriétés temporelles Les schémas de spécification Bilan de la section

8 6 Table des matières 2.2 Annotations de programme Historique Langages d annotations Travaux autour des langages d annotations Bilan de la section Axe 1 : Génération d annotations à partir de propriétés temporelles Problématique Génération d annotations à partir du code Génération d annotations par propagation d annotations existantes Génération d annotations à partir de spécifications de haut niveau Axe 2 :Vérification de la consistance d un ensemble d annotations Problématique Consistance de modèle Bilan de la section Axe 3 : Génération de tests à partir de propriétés temporelles et validation Problématique Génération de tests à partir de modèles Génération de tests à partir de propriétés temporelles Synthèse II Vérification des propriétés temporelles par génération d annotations sur les programmes non-objets 43 3 Modèle de programme et sémantique de chemins d exécution Notations utilisées Notations ensemblistes Relations et ordres Fonctions Syntaxe et sémantique de programme Généralités Etat d un programme Système de transitions associé à un programme Séquences et chemins Présentation de B

9 le B.A.-BA Présentation d une machine B Exemple de machine B Consistance d une machine B Les systèmes d événements B Présentation des systèmes d événements Exemple de système d événements B Modalités B Sémantique de chemin des systèmes d événements de B Sémantique des systèmes d événements B Propriétés des systèmes d événements B Sémantique de programme annoté Annotations de programme et programme annoté Définitions Syntaxe du langage d annotation noyau Système de transitions d un programme annoté Etat d annotation et de programme annoté Système de transitions associé à un programme annoté Sémantique de chemin d un programme annoté et conformité Sémantique de chemin d un programme annoté Conformité d un programme vis-à-vis de ses annotations Génération d annotations pour vérifier des propriétés temporelles Présentation des automates de Büchi Définitions Caractérisation des sûretés et des vivacités Traduction d automates de Büchi en annotations de programme Méthode de traduction Correction de la traduction Application à la vérification de propriétés LTL sur les systèmes d événements B Rappels sur la LTL Méthode de génération pour B Exemple illustratif

10 8 Table des matières Justification de la méthode III Vérification et validation de propriétés temporelles sur les programmes Java à l aide d annotations JML 93 6 Modèle de programme Java Présentation générale de Java Syntaxe et concepts de Java Un exemple de programme Java Structure d un programme Java Ensembles généraux Structure d une classe Structure d un programme Expressions Java Commandes Java Un peu plus d expressivité! Etat d un programme Java et modèle mémoire Modèle mémoire Valeur associée à une variable Objets et instances d une classe Variables spéciales Comparaison avec d autres modèles mémoire Sémantique de chemin d un programme Java Chemin d exécution associé aux expressions Java Chemin d exécution associé aux commandes Java Sémantique de chemin d un programme Syntaxe et sémantique de JML Principes généraux de JML et exemple Syntaxe et sémantique des expressions JML Evaluation d une expression sans effet de bord Opérateurs booléens Opérateurs pré/post Etats visibles

11 9 7.4 Spécifications de classes JML Variables de spécification JML Invariant Contrainte historique Contrainte initiale Spécifications de méthodes JML Pré-condition Post-condition Post-condition exceptionnelle Condition de champ modifié Condition de divergence Notion de comportement Comportement mixte Comportement normal Comportement exceptionnel Comportements multiples et forme normale Génération d annotations JML à partir de propriétés temporelles Sémantique de classe Définition de la sémantique de classe Lien entre sémantique de classe et sémantique de programme Génération d annotations JML pour vérifier des propriétés temporelles sur une classe en isolation Expression des ensembles CLAUSE AnnDecl et CLAUSE AnnTrans Expression de l ensemble de clauses CLAUSE AnnCSync Expression de l ensemble de clauses CLAUSE AnnCBüchi Application au langage JTPL Syntaxe de JTPL Caractérisation des sûretés et vivacités Génération d annotations à partir d une formule JTPL Vérification de propriétés temporelles sur un programme Préservation des sûretés Préservation des vivacités : la condition de progrès du programme Vérification de la condition de progrès

12 10 Table des matières 9 Vérification de modèles JML Exemple introductif Représentation de la structure de classe Java/JML à l aide d une machine B Une machine pour les contrôler toutes Représentation des classes et des objets Traduction des types primitifs et représentation des attributs Représentation des spécifications JML Représentation des invariants et des contraintes historiques en B Représentation des spécifications des méthodes Représentation de la clause diverges Création d instances et représentation du constructeur Gestion des appels de méthode dans les prédicats Représentation de l héritage Instances et attributs Héritage de méthode Expérimentation sur l exemple De l échec de l obligation de preuve B à l erreur dans le modèle JML Détection d erreurs plus avancées Génération de tests à partir de propriétés temporelles JML et JML-RAC : Rappels et compléments L outil JML-TT Principe de l animation symbolique et de la génération de tests fonctionnels Critères de couverture Génération de tests à partir d une propriété temporelle Principe du calcul de la séquence de test Bilan de cette section IV Outils et expérimentations Outils développés et expérimentations sur un cas d étude Présentation de Demoney et modélisation JML Présentation générale de Demoney

13 Spécification fonctionnelle de Demoney Modélisation en JML de Demoney Modélisation incrémentale Choix méthodologiques Les modèles JML pour Demoney Modélisation des exceptions L outil JML2B Structure de l outil Expérimentations Degré d avancement et distribution de l outil L outil JAG Structure de l outil Exemple d utilisation Traçabilité des annotations et diagnostic Expérimentations Degré d avancement et distribution de l outil Couplage JAG/JML-TT Expérimentation sur Demoney V Conclusion et Perspectives 225 Conclusion 227 Perspectives 231 Bibliographie 235 A Annexes du chapitre A.1 Lien entre le programme annoté et non annoté : abstraction et raffinement. 245 A.1.1 Rappels sur l interpretation abstraite A.1.2 Caractérisation du lien entre programme annoté et non annoté A.1.3 Propriétés d inclusion de chemin B Annexes du chapitre 8 251

14 12 Table des matières C Annexes du chapitre C.1 Preuve de la correction de la traduction des spécifications de méthodes C.2 Représentation des classes Purse et LimitedPurse par une machine B

15 Première partie Contexte et problématique 13

16

17 Chapitre 1 Introduction Sommaire 1.1 La démarche de vérification et validation formelle de logiciels Problématiques abordées et contexte des travaux Vérification de propriétés temporelles Annotations de programme Génération automatique d annotations Programmation orientée objet Génération automatique de tests Contributions Contributions - Axe 1 : Génération d annotations à partir de propriétés temporelles Contributions - Axe 2 :Vérification de la cohérence d un ensemble d annotations Contributions - Axe 3 : Génération de tests à partir de propriétés temporelles et validation Plan du mémoire La démarche de vérification et validation formelle de logiciels A l heure actuelle, les systèmes informatisés sont devenus omniprésents dans les domaines industriels et scientifiques les plus pointus (médecine, avionique, industrie automobile, secteur bancaire). Mais ils sont également présents dans les gestes les plus simples de notre vie quotidienne. Depuis ce matin, j ai consulté mon , écouté un disque au format mp3 sur mon baladeur, retiré de l argent au distributeur, consulté mon compte en banque par internet, et enfin, écrit plusieurs pages du présent mémoire. Ces systèmes peuvent comporter des dysfonctionnements ou des erreurs de conception pouvant occasionner des dommages, dont les conséquences peuvent être anodines ou très graves. En effet, un dysfonctionnement de mon lecteur mp3 aura des conséquences moindres qu un 15

18 16 Chapitre 1. Introduction dysfonctionnement de ma transaction bancaire. De ce fait, tous les systèmes informatiques sousjacents ne sont pas à considérer avec le même niveau de responsabilité. De manière générale, les logiciels dont le dysfonctionnement peut entraîner la mise en danger de vie humaine (électronique des voitures, avionique,... ) ou d importantes pertes d argent (transactions bancaires,...) sont dits critiques. Plus les dommages potentiels en cas de dysfonctionnement sont élevés, plus les exigences de sécurité sont, elles aussi, élevées. D un point de vue matériel, on pourra avoir recours à des matériaux plus solides, ou résistant mieux au changement de température. D un point de vue logiciel, on aura recours à l utilisation de méthodes formelles durant le processus de développement, afin de valider et/ou vérifier le logiciel. Méthodes formelles Les méthodes formelles sont fondées sur l utilisation de notations mathématiques et/ou logiques sur lesquelles on peut raisonner de façon rigoureuse. L idée est de décrire dans ce formalisme le cahier des charges (ou une partie de celui-ci), sachant que ce dernier est, le plus souvent, écrit de manière informelle. Ce travail se traduit généralement par la création d un modèle formel du logiciel, c.-à-d., un modèle exprimé par des notations mathématiques ou logiques. C est ce modèle qui sert généralement de base aux techniques de validation et de vérification. Vérification de programmes La vérification consiste à s assurer de manière formelle qu un énoncé (par exemple l implantation d une application) est conforme vis-à-vis d un autre énoncé (généralement le modèle de l application) 12. Le modèle est une description formelle (appelée formalisation) du cahier des charges ou d une partie de celui-ci dans un langage formel ou semi-formel. Deux grandes familles de techniques de vérification sont couramment utilisées pour répondre à ces problèmes : les techniques dites de model-checking ou méthodes algorithmiques. Développées indépendament dans les années 80 par Clarke et Emerson d une part [46], et par Queille et Sifakis d autre part [124], elles consistent à explorer l ensemble de toutes les configurations possibles d un système afin de s assurer qu aucune d elles ne présente de dysfonctionnement. L intérêt principal du model-checking est que c est une méthode automatique, c.-à-d. que l utilisateur donne à l algorithme les données d entrée du problème (par exemple, le système et la propriété à vérifier) et n a pas à intervenir pour obtenir le résultat de la vérification. Cependant, ce type de technique se heurte à deux problèmes principaux. Tout d abord, dans le cas général, elle ne peuvent pas traiter des systèmes infinis, c est-à-dire des systèmes présentant un nombre infini de configurations possibles. Il existe cependant des algorithmes de model-checking pour certaines classes de systèmes infinis. De plus, l explosion combinatoire du nombre de configurations à explorer peut rendre la vérification impossible à mettre en oeuvre pour des systèmes finis de grande taille. les techniques dites de preuves, initiées par les travaux de Hoare [75], consistent à traduire la conformité du programme vis-à-vis du modèle en un ensemble de formules ma- 12 Différentes notions de conformité existent. On pourra citer par exemple l inclusion de langages [86] ou l équivalence observationnelle [48]. Celle-ci doivent donc être décrites formellement.

19 1.2. Problématiques abordées et contexte des travaux 17 thématiques, appelées obligation de preuves (OP). La validité de ces formules mathématiques (la preuve qu elles sont vraies vis-à-vis d une théorie) assure alors que le système est conforme à son modèle ou à une propriété donnée. Dans la pratique, un logiciel, appelé prouveur, est chargé de réaliser de manière automatique la preuve de ces formules mathématiques. Cependant, en cas d échec, la preuve doit être réalisée manuellement. Bien qu il existe des assistants de preuve pouvant aider l utilisateur dans cette tâche, elle requiert une grande expertise de l utilisateur. Ces techniques de vérification sont coûteuses dans le sens où elles impliquent de fortes ressources machine dans le cas du model-checking et une grande expertise de l utilisateur dans le cas des techniques de preuves. De plus, elles font l hypothèse que le modèle est bien représentatif du cahier des charges. Pour cette raison, ces techniques de vérification nécessitent d être combinées avec des techniques de validation du modèle ou de l implantation. Validation de programmes La validation est une notion moins forte que la vérification. Alors que la vérification cherche à prouver l absence d erreurs, la validation cherche à détecter la présence d erreurs. Si aucune erreur n est détectée lors de la phase de validation, le système pourra être considéré comme relativement sûr. La technique de validation la plus courante est le test de logiciel. Dans ce cas, un programme sera valide, c est-à-dire relativement sûr, s il n est pas mis en défaut par une batterie de tests. La validation est une notion plus faible que la vérification dans le sens où elle n assure pas l absence totale d erreurs dans un système puisque l on ne teste pas toutes les configurations possibles de celui-ci. Cependant, elle permet d accroître la confiance que l on peut avoir dans ce système. En particulier, une phase de validation du modèle est nécessaire, pour s assurer de sa conformité vis-à-vis du cahier des charges 13. Cette étape se fait généralement par des techniques d animation, qui consistent à simuler l exécution de ce dernier. Combiner vérification et validation pour la sécurité logicielle D un point de vue pratique, il peut être intéressant de combiner des techniques de vérification et de validation pour assurer la sécurité des logiciels. Cette combinaison peut consister par exemple à entreprendre tout d abord une phase de validation du modèle ou de l implantation afin de détecter les erreurs les plus grossières, puis d effectuer la vérification du modèle ou de l implantation ainsi validé. De même, en cas d échec de la vérification par preuve, on ne peut, en général, pas savoir si l échec est dû à la présence effective d une erreur ou à l impossibilité du prouveur automatique à réussir la preuve. Dans ce cas, une phase de validation spécifique pourra être mise en place pour tenter, soit d exhiber un contre-exemple, soit d accroître la confiance dans les parties du logiciel qui n auront pu être vérifiées. 1.2 Problématiques abordées et contexte des travaux Les travaux présentés dans cette thèse ont été réalisés au Laboratoire d Informatique de l Université de Franche-Comté (LIFC). Ce laboratoire, fondé en 1993 par le Pr. Michel Tréhel, 13 Le cahier des charges n étant pas décrit de façon formelle, il n est pas possible d effectuer une vérification de cette phase de formalisation.

20 18 Chapitre 1. Introduction est actuellement dirigé par le Pr. Jacques Julliand depuis J ai été accueilli au sein du Laboratoire en 2003 lors de mon DEA, sous la direction du Pr. Françoise Bellegarde, directrice de l équipe Techniques Formelles et à Contraintes, équipe actuellement dirigée par le Pr. Olga Kouchnarenko. Mes travaux s inscrivent dans l activité Expression et vérification par raffinement et ont été encadrés par le Pr. Jacques Julliand et co-encadrés par Olga Kouchnarenko (en deuxième année) et par Alain Giorgetti, maître de conférences au LIFC. Cette thèse s insère dans le cadre d une collaboration extérieure à travers l ACI 14 GECCOO (GEnération de Code Certifié pour les applications Orientées Objet), menée par le Pr. Christine Paulin-Mohring. Ce projet national a débuté en Septembre 2003 et a pris fin en Janvier Il implique l équipe DEMONS du Laboratoire de Recherche en Informatique (LRI) d Orsay, le Laboratoire Logiciel, Système et Réseaux (LSR) de Grenoble, l équipe EVEREST de l INRIA de Sophia Antipolis et le Laboratoire Lorrain de Recherche en Informatique et Automatique (LORIA). Le contexte scientifique de cette thèse est fortement lié aux thématiques abordées dans le cadre de ce projet, ainsi qu aux savoir-faire de l équipe TFC Vérification de propriétés temporelles Une branche importante de la vérification logicielle s intéresse à la vérification des propriétés de sécurité des systèmes. Elle consiste à exprimer dans une logique adéquate les propriétés de sécurité du système requises dans le cahier des charges. La nature des propriétés que l on souhaite vérifier sur un système peut être très variée. Elle peut aller de la vérification de la confidentialité des données ("Le code secret de la carte est confidentiel, personne ne peut le lire") au contrôle d accès ("Seul un terminal identifié peut débiter la carte"). Divers formalismes ont été proposés, chacun adapté à une certaine classe de propriétés, afin, d une part, d exprimer ces propriétés et d autre part, d y associer des méthodes de vérification sur le modèle et/ou l implantation du logiciel. Dans le cadre de ce mémoire, nous nous sommes intéressés à un certain type de propriétés, décrivant l évolution de l état du système au cours du temps 15. On distinguera particulièrement deux types de propriétés. Les propriétés dites statiques, spécifiées généralement par des invariants, qui consistent à décrire une propriété qui doit être assurée sur tous les états du système au cours du temps. Par exemple, sur un porte-monnaie électronique, on pourra décrire la propriété statique suivante : le solde de la carte ne doit jamais être négatif. Quelle que soit l opération qui est exécutée, cette propriété doit toujours être vérifiée. Les propriétés dites dynamiques, qui décrivent l évolution du système au cours du temps. Par exemple, on ne peut pas créditer la carte si le code secret n a pas été vérifié au préalable est une propriété temporelle puisqu elle implique un ordonnancement dans l ordre des états et/ou des actions : pour effectuer une action de crédit, il est nécessaire qu il y ait eu avant un état où le code a été vérifié. 14 Action Concerté Incitative. 15 NB : la notion du temps est ici un temps discret, et non un temps continu

21 1.2. Problématiques abordées et contexte des travaux Annotations de programme Un point de vue pour spécifier et vérifier du code consiste à travailler directement au niveau du code source en insérant des annotations logiques (invariants, pré et post-conditions). L origine des annotations de code revient à Owicki et Gries [118] qui proposèrent d insérer des assertions à l intérieur même des programmes afin de rendre la preuve de programme, basée sur la logique de Hoare, applicable en pratique. Cette approche d annotation de programme a ensuite été reprise dans des travaux plus récents, notamment avec le langage Larch [74], un langage d annotation pour C et le concept de la conception par contrats (design by Contract) défini par B. Meyer dans le langage Eiffel [109]. Un exemple très récent de cette approche de conception par contrat est le langage JML (Java Modeling Language) [90], développé par Gary. T. Leavens et son équipe à l université de l Iowa. JML permet d intégrer des spécifications formelles au code Java (pré-condition, postcondition, invariant, etc.). Dans le cadre de cetle thèse et de l ACI GECCOO, nous nous sommes particulièrement intéressés à ce langage d annotation qui permet de combiner aisément preuve formelle et validation [92] Génération automatique d annotations Si la vérification par le biais d annotations facilite l intégration des méthodes formelles au cours du développement logiciel, celle-ci reste cependant un tâche fastidieuse. Pour pallier ce problème, une proposition est de générer de manière automatique tout ou partie des annotations de code Programmation orientée objet Le projet GECCOO s intéresse à une classe particulière de programmes appelée programmes orientés objets. Ces programmes diffèrent des programmes séquentiels classiques dans le sens où les données du programme sont regroupées ou encapsulées dans des entités appelées objets. Chaque objet représente un concept indépendant contenant ses propres données et ses propres méthodes. Par exemple, dans le cas de notre porte-monnaie electronique, le portemonnaie lui-même sera un objet, le terminal de paiement un autre objet, le terminal de crédit encore un autre objet, etc. Un programme est un ensemble d objets qui forment les briques" ou modules du programme. Un objet peut être lui-même composé de plusieurs objets. Par exemple, un terminal de paiement est composé d un lecteur de carte, d un clavier, d un écran... et un objet utilisé dans un programme peut être réutilisé dans un autre. Les objets sont regroupés par classe. Intuitivement, une classe est une collection d objets ayant des caractéristiques communes. Par exemple, on pourra avoir une classe porte-monnaie électronique, une classe terminal, etc. Un objet appartenant à une classe est appelé une instance de cette classe. Comme dans la vie réelle, chaque instance est unique. Les notions d héritage et de sous-typage permettent de créer une hiérarchie entre les classes. Par exemple, la classe terminal de paiement et la classe terminal de crédit seront toutes deux des sous-classes de la classe terminal. Elles hériteront des caractéristiques et fonctionnalités du

22 20 Chapitre 1. Introduction terminal (présence d un lecteur de carte par exemple), et en auront d autres spécifiques (par exemple, la vérification du code secret pour le terminal de crédit). Les langages orientés objet, du fait de leurs spécificités de conception (en particulier la réutilisabilité des classes dans plusieurs programmes), posent des problèmes de sécurité et de modélisation différents des langages classiques. Le projet GECCOO s est intéressé à la sécurité de tels langages par une combinaison d approches de vérification et de validation (preuves, raffinements, validation de modèles par animation symbolique, génération de tests,...) Génération automatique de tests Dans la cadre de la validation logicielle, les travaux du LIFC se sont focalisés sur la génération de tests à partir de modèles formels. Les résultats de ces travaux de recherche ont abouti à l outil de génération de test BZ-Testing-Tools (BZ-TT) 16, aujourd hui transféré dans le cadre industriel à l entreprise Leirios Technologies 17. Dans le cadre de l ACI Geccoo, une extension de cet outil pour les programmes orientés objets, et en particulier pour l outil Java/JML, a été développée par Frédéric Dadeau, dans le cadre de sa thèse [55]. Ces travaux consistent à générer un jeu de tests pour un ensemble de classes à partir de leurs annotations JML. 1.3 Contributions Le travail présenté dans ce mémoire de thèse porte sur la spécification et la validation de propriétés temporelles par génération automatique d annotations. La démarche s appuie sur deux langages principaux : la méthode B, le langage d annotation JML. Les contributions principales présentées dans ce mémoire de thèse se décomposent en trois axes principaux. Génération automatique d annotations à partir de propriétés temporelles (Axe 1) Vérification de la consistance d un ensemble d annotations (Axe 2) Génération de tests à partir de propriétés temporelles et validation (Axe 3) Nous décrivons, à présent, ces trois axes de contribution de manière succinte Contributions - Axe 1 : Génération d annotations à partir de propriétés temporelles La première contribution présentée dans ce mémoire s intègre dans la thématique de la génération automatique d annotations. A partir d une propriété temporelle, nous générons un ensemble d annotations de programme. La satisfaction de ces annotations assure alors que la

23 1.3. Contributions 21 propriété est satisfaite. Les travaux s attachent à la vérification d une classe particulière de propriétés temporelles, les propriétés temporelles linéaires exprimées par la logique LTL. Cette démarche a été implantée dans l outil JAG [67], développé au cours de cette thèse. Nous avons appliqué cette méthode à deux cas Tout d abord aux langages non-objets, que nous illustrons dans le cadre de la méthode B. Ces contributions ont été publiées dans [71] où nous expliquons, dans le cadre de la méthode B, comment vérifier des propriétés LTL par génération d annotations. L implantation de ces travaux a été publiée dans [70] Nous avons proposé d étendre la démarche au langage orienté objet Java et à son langage d annotation JML. Dans ce cadre, nous nous intéressons plus particulièrement à un langage de propriétés temporelles adapté à Java, JTPL, défini dans [130]. Pour cela, nous contribuons à l état de l art sur les points suivants : 1. Nous définissons des règles de traduction du langage JTPL vers la logique LTL. 2. Nous étendons la syntaxe JTPL pour permettre la vérification de propriétés de vivacité. 3. Nous définissons une sémantique de trace d exécution pour un sous-ensemble du langage Java. En particulier nous définissons la sémantique d un programme et la sémantique d une classe en isolation. 4. Nous exprimons les annotations JML dans cette sémantique. 5. Nous proposons une traduction des propriétés JTPL en annotations JML. 6. Nous avons implanté cette traduction dans l outil JAG. 7. Nous proposons une méthode pour vérifier qu une propriété temporelle satisfaite sur une classe en isolation est préservée lorsque la classe est utilisée par un programme. Ces travaux autour de JML ont donné lieu à différentes publications [72, 66, 67] Contributions - Axe 2 :Vérification de la cohérence d un ensemble d annotations Le second axe de contributions s inscrit dans la thématique de la vérification par preuve et de la détection d erreurs dans le cadre des annotations JML. Les outils de vérification pour JML s assurent que le code Java est conforme aux annotations JML. Cependant, s il existe une inconsistance dans les annotations, par exemple, si deux invariants sont en contradiction ou si une post-condition ne peut jamais être établie, alors, aucune implantation Java ne pourra satisfaire ces annotations. Partant de ce constat, nous proposons de vérifier, au préalable, que le modèle JML, c est à dire l ensemble des annotations d une classe, ne présente pas d inconsistance avant de le confronter au code Java. La méthode adoptée, presentée dans [28], consiste à traduire un modèle JML en une machine B dont la consistance implique la consistance du modèle JML. Cette traduction a été implantée dans le cadre de cette thèse dans l outil JML2B [29].

24 22 Chapitre 1. Introduction Contributions - Axe 3 : Génération de tests à partir de propriétés temporelles et validation La dernière contribution de cette thèse s intègre dans les travaux du LIFC sur la génération automatique de tests à partir de modèles. Ces travaux s appuient sur l outil JML-TT, développé par F. Dadeau au cours de sa thèse [71]. L outil JML-TT permet de générer des cas de tests fonctionnels par animation symbolique à partir d un modèle JML. Les tests sont ensuite validés sur l implantation. Nous avons étendu la démarche pour générer des tests à partir d une propriété temporelle exprimée en JTPL. Les tests sont alors exécutés sur l implantation. Les annotations JML générées par l outil JAG servent d oracle pour le test. Pour mettre en place cette méthode, nous avons dû : définir différentes stratégies de génération de tests complémentaires des stratégies nécessaires à la génération des tests fonctionnels déjà implantés dans l outil JML-TT, ainsi que les algorithmes qui leur sont associés. définir une méthode pour générer automatiquement, à partir d une formule JTPL, la stratégie de génération de test correspondante. Ces travaux ont été publiés dans [30]. 1.4 Plan du mémoire Ce mémoire s organise en 11 chapitres répartis en 5 parties. Nous présentons la structure de ce document. La première partie décrit le contexte de ces travaux de thèse. Elle contient les deux chapitres suivants : Le chapitre 1 décrit le contexte des travaux de ce mémoire, les problèmatiques scientifiques abordées durant la thèse et les trois axes de contribution. Le chapitre 2 présente l état de l art associé à ces travaux, pour chacun des trois axes de contribution. La deuxième partie présente les travaux de cette thèse dans le cadre des programmes linéaires. Elle est illustrée par une application aux systèmes d événements B. Cette partie contient 3 chapitres. Le chapitre 3 définit la sémantique de programme qui sera utilisée tout au long du mémoire. Le chapitre 4 définit la notion d annotation de programme et sa sémantique. Le chapitre 5 présente notre contribution à la vérification des propriétés temporelles par génération d annotations (Axe 1) et son application aux systèmes d événements B. La troisième partie propose d étendre les résultats de la génération d annotations à Java/JML. Elle est composée de 5 chapitres : Le chapitre 6 propose une extension de la sémantique donnée dans le chapitre 3 adaptée aux programmes objets (Axe 1). Le chapitre 7 présente de manière informelle les principales annotations du langage JML et les illustrent par un exemple. Le chapitre 8 explique comment les résultats du chapitre 5 ont été adaptés pour per-

25 1.4. Plan du mémoire 23 mettre la génération d annotations JML à partir de propriétés exprimées en JTPL (Axe 1). Le chapitre 9 définit une notion de consistance de modèles de classe JML et propose une technique pour la vérifier (Axe 2). Le chapitre 10 propose une méthode de validation des propriétés JTPL combinant la génération automatique d annotations et la génération automatique de cas de tests guidée par la propriété à vérifier (Axe 3). La quatrième partie présente les outils et les expérimentations qui ont été menées dans le cadre de cette thèse. Elle est composée d un seul chapitre. Le chapitre 11 présente les deux outils développés dans le cadre de cette thèse : JML2B et JAG. Il rapporte également les expérimentations qui ont été menées sur une étude de cas Javacard : Demoney. Ce chapitre présente comment les résultats théoriques présentés dans ce rapport ont été appliqués sur ce cas d étude. La dernière partie conclut ce document et présente les perspectives de travaux futurs.

26 24 Chapitre 1. Introduction

27 Chapitre 2 Panorama des travaux connexes aux contributions de cette thèse Sommaire 2.1 Logiques temporelles Généralités sur les logiques temporelles La logique temporelle linéaire et les automates de Büchi Vérification de propriétés temporelles Les schémas de spécification Bilan de la section Annotations de programme Historique Langages d annotations Travaux autour des langages d annotations Bilan de la section Axe 1 : Génération d annotations à partir de propriétés temporelles Problématique Génération d annotations à partir du code Génération d annotations par propagation d annotations existantes Génération d annotations à partir de spécifications de haut niveau Axe 2 :Vérification de la consistance d un ensemble d annotations Problématique Consistance de modèle Bilan de la section Axe 3 : Génération de tests à partir de propriétés temporelles et validation Problématique Génération de tests à partir de modèles Génération de tests à partir de propriétés temporelles Synthèse

28 26 Chapitre 2. Panorama des travaux connexes aux contributions de cette thèse Cette thèse s attachant à la vérification et à la validation de propriétés temporelles à l aide d annotations, et ce, tout au long d un développement formel de logiciels, les thématiques abordées sont relativement variées, allant de la génération de tests à la vérification de spécifications, en passant par l expression de propriétés temporelles. De ce fait, ce chapitre, présentant un état de l art de ces thématiques, est composé de 6 sections. La section 2.1 s intéresse à la notion de logique temporelle. Elle présente différentes logiques temporelles, en particulier la logique temporelle linéaire ainsi que les travaux et techniques de vérification qui lui sont associés. La section 2.2 présente la notion d annotation de programme, ainsi que les différents langages d annotations existants et les outils de vérification et de validation qui leur sont associés. La section 2.3 établit un état de l art des différentes techniques de génération automatique d annotations. La section 2.4 s intéresse aux travaux liés à la vérification de la consistance de modèles et de la conformité de programme vis-à-vis de ses annotations. La section 2.5 dresse un panorama des techniques de génération de tests à partir de propriétés temporelles. Les trois dernières sections dressent un état de l art spécifique sur les trois axes de recherche sur lesquels contribuent les travaux présentés dans ce mémoire. Chacune de ces sections donne un positionnement de nos contributions vis-à-vis de l état de l art. Enfin nous concluons ce chapitre en réalisant une synthèse de cet état de l art et un positionnement global de nos travaux. 2.1 Logiques temporelles Les premiers travaux connus sur la logique temporelle sont dus au philosophe grec Aristote, qui étendit sa logique binaire du premier ordre avec les premières modalités temporelles. Les logiques temporelles sont un sous-ensemble des logiques modales 18 qui associent une valeur de vérité non pas à un état, mais à une séquence d états, représentant l évolution d un système au cours du temps (d où le terme de logique temporelle). Premièrement, la section introduit les formalismes les plus courants en logique temporelle afin de positionner, vis-à-vis des autres formalismes, la logique temporelle linéaire (LTL) qui nous intéresse particulièrement. Cette logique sera plus détaillée dans la section Les méthodes de vérification de la LTL seront quant à elles présentées dans la section Pour terminer, la section présente les notions de schéma de spécification et de modalités, qui sont des alternatives aux logiques temporelles pour exprimer et vérifier des propriétés temporelles Généralités sur les logiques temporelles L éventail des logiques temporelles proposées dans la littérature est très large. De ce fait, nous n évoquerons ici que les logiques permettant de positionner les deux logiques utilisées 18 logiques augmentées d opérateurs, appelés modalités, permettant d exprimer la possibilité, l interdiction, l éventualité, la fatalité, le doute, etc. sur une proposition logique.

29 2.1. Logiques temporelles 27 dans le cadre de nos travaux, c.-à-d. la LTL (Linear Temporal Logic : logique temporelle linéaire), les automates de Büchi et la JTPL (Java Temporal Pattern Language : langage de schémas temporels pour Java). Les logiques temporelles sont obtenues en étendant la logique des propositions avec des opérateurs temporels permettant d exprimer l évolution d un système au cours du temps, tels que toujours, jusqu à, fatalement.... Classiquement, on décompose les logiques temporelles en deux grandes classes : 1. Les logiques arborescentes (CTL,CTL ). 2. Les logiques linéaires (LTL) La logique temporelle linéaire et les automates de Büchi La logique temporelle linéaire a été définie par Pnueli [123]. Comme les autres logiques temporelles, une formule LTL exprime une propriété sur un chemin d exécution, c.-à-d. une séquence d états. Soit φ, ψ des formules temporelles. Les formules de la LTL sont : Xφ (next - suivant), qui indique que la propriété φ doit être vérifiée à partir de l état suivant l état courant. Fφ (eventually - fatalement), qui indique qu il existe forcément (dans le sens de inévitablement) un état futur de l exécution qui vérifie φ. Gφ (always - toujours), qui indique que tous les états à partir de l état courant doivent vérifier φ. φuψ (until - jusqu à ce que), qui indique qu à partir de l état courant, tous les états vérifient φ jusqu à ce que l on atteigne un état vérifiant ψ, cette atteignabilité étant obligatoire. Classiquement, les propriétés LTL se classent en deux catégories [88] : les propriétés de sûreté, qui assurent que quelque chose de mauvais ne doit pas arriver ; les propriétés de vivacité, qui assurent que quelque chose de bon doit finir inévitablement par arriver. En d autres termes, si le préfixe d une exécution met en défaut une propriété de sûreté, alors toute exécution commençant par ce préfixe mettra lui aussi en défaut la propriété, ce qui n est pas le cas pour les vivacités. En effet, si un préfixe d exécution ne satisfait pas une propriété de vivacité, il peut exister une exécution commençant par ce préfixe et prolongée différemment la satisfaisant [88]. Le problème de la caractérisation sûreté/vivacité d une formule LTL a été montré décidable [7], c est-à-dire qu étant donné une formule LTL, il existe un algorithme qui termine et qui est capable de déterminer si cette formule est une sûreté ou une vivacité. Cette distinction trouve son origine dans le cadre de la vérification par preuve. En effet, ces types de propriétés correspondent à deux méthodes de vérification différentes : la satisfaction d une sûreté peut se ramener à la vérification d un invariant quand la preuve de la satisfaction d une vivacité est basée sur la décroissance d un variant bien fondé. Cette distinction a aussi son intérêt pour la préservation de propriétés dans la cadre de la simulation [111]. Les sûretés sont préservées par des τ-simulations alors que les vivacités nécessitent des τ-simulations sans introduction de dead-locks, c.-à-d. d introduction de blocages qui n étaient pas présent dans le système d origine, ni de live-locks, c est-à-dire de boucle qui n étaient pas présentes dans le système d origine.