Probl´ ematiques et motivations

v´erifient qu’une propri´et´e `a la fois.

[CS05] pr´esente une nouvelle combinaison d’analyse statique et de g´en´eration de tests pour la d´etection des erreurs `a l’ex´ecution. Cet outil n’est ni correct ni complet. Les utilisa-teurs doivent faire face `a un travail lourd d’annotation et un taux ´elev´e de fausses alarmes.

C’est dans cette cat´egorie d’approches que se situe cette th`ese, en fournissant une nou-velle combinaison d’analyse de valeurs, de simplification syntaxique et de test structurel pour la v´erification des programmes ´ecrits en C.

1.2 Probl´ ematiques et motivations

L’´equipe d’enquˆete charg´ee de d´eterminer les causes de l’explosion d’Ariane 5 a af-firm´e dans sa conclusion que les tests effectu´es en cours du d´eveloppement d’Ariane 5 ne comprenaient ni une analyse ad´equate ni des tests du syst`eme de contrˆole de vol complet, ce qui aurait peut-ˆetre suffi pour d´etecter la d´efaillance potentielle [LLF⁺96].

Dans le cas d’Ariane 5, une erreur du programme a eu des cons´equences financi`eres tr`es fortes. Dans le cas du missile Patriot, les pertes humaines ´etaient catastrophiques.

Il est donc primordial, avant d’utiliser des programmes dans des syst`emes embarqu´es, de s’assurer de leur bon fonctionnement. Le g´enie logiciel pr´econise le recours aux m´ethodes formelles permettant de v´erifier les syst`emes pour assister les ing´enieurs de d´eveloppement.

Etant incomplet, le processus de validation par des tests n’est pas suffisant pour ´eva-luer la fiabilit´e des syst`emes logiciels, surtout avec l’augmentation de la taille des logiciels.

Ce processus ne peut pas ˆetre fond´e sur des techniques d’abstraction trop impr´ecises. La tendance actuelle des industriels est de se concentrer sur les techniques correctes. Ces techniques devraient pouvoir passer `a l’´echelle pour des programmes de grande taille.

Elles devraient aussi s’appliquer `a des programmes C existants de fa¸con automatique. Les utilisateurs ne devraient pas avoir besoin d’intervenir pour guider la v´erification et pour produire des r´esultats pr´ecis.

Une derni`ere motivation importante de ce travail est de fournir automatiquement `a l’ing´enieur de validation non seulement les donn´ees de test et le chemin du programme menant `a une erreur, mais aussi autant d’informations que possible sur l’erreur d´etect´ee.

Par exemple, l’erreur peut ˆetre illustr´ee sur un programme plus simple, avec un chemin plus court conduisant `a l’instruction erron´ee et un ensemble de contraintes r´eduit por-tant sur les variables utiles seulement. La plupart des outils de v´erification modernes ne font pas ces simplifications et ne fournissent pas ces informations simplifi´ees, qui peuvent r´eduire consid´erablement le temps n´ecessaire `a un d´eveloppeur de logiciels pour analyser et corriger l’erreur. Dans notre m´ethode, nous proposons d’introduire une phase de sim-plification syntaxique, appel´ee plus couramment slicing, afin de simplifier le programme analys´e et les contre-exemples produits. Le programme simplifi´e est appel´eslice. L’apport

de la simplification est particuli`erement int´eressant dans le cas de la g´en´eration automa-tique de code `a partir de mod`eles, o`u le d´eveloppeur qui investigue la source d’erreur n’a pas de connaissance profonde du code source analys´e.

1.3 Contributions

Nous traitons les probl´ematiques discut´ees ci-dessus en mettant en place une m´ethode automatique combinant la compl´etude de l’analyse de valeurs, la simplification par trans-formation syntaxique et la pr´ecision de l’analyse dynamique.

Notre premi`ere contribution est une combinaison originale des deux techniques d’ana-lyse statique et d’anad’ana-lyse dynamique afin d’am´eliorer la pr´ecision en classant plus de menaces. Notre deuxi`eme contribution est l’int´egration de la simplification syntaxique (slicing) dans notre combinaison. La troisi`eme contribution de cette th`ese est la formali-sation de la m´ethode propos´ee et la preuve de sa correction. La quatri`eme contribution consiste en l’impl´ementation de la m´ethode dans l’outil nomm´e sante. Notre derni`ere contribution consiste `a ´evaluer en pratique par des exp´erimentations les techniques pro-pos´ees dans cette th`ese en utilisant l’impl´ementation.

1.3.1 Combinaison d’analyse de valeurs et d’analyse dynamique

Dans cette combinaison, l’analyse statique (analyse de valeurs) signale les instructions risquant de provoquer des erreurs `a l’ex´ecution par des alarmes, dont certaines peuvent ˆetre de fausses alarmes. Puis l’analyse dynamique (g´en´eration de tests) est utilis´ee pour confirmer ou rejeter ces alarmes. Cette contribution a ´et´e publi´ee dans [CKGJ10b], o`u nous avons pr´esent´e santeet la technique de g´en´eration de tests guid´ee par les alarmes, ainsi que les premi`eres exp´erimentations.

1.3.2 Int´ egration de la simplification syntaxique

Appliqu´ee `a des programmes de grande taille, la g´en´eration de tests peut manquer de temps ou d’espace m´emoire avant de confirmer certaines alarmes comme de vraies erreurs ou de conclure qu’aucun chemin faisable ne peut atteindre l’´etat d’erreur de certaines alarmes et donc rejeter ces alarmes. Pour surmonter ce probl`eme, nous proposons de r´e-duire la taille du code source par le slicing avant de lancer la g´en´eration de tests. Le slicing transforme un programme en un autre programme plus simple, qui est ´equivalent au programme initial par rapport `a certains crit`eres. Les crit`eres utilis´es dans notre m´e-thode pr´eservent une ou plusieurs instructions mena¸cantes.

Quatre utilisations du slicing sont ´etudi´ees. La premi`ere utilisation est nomm´ee all.

Elle consiste `a appliquer le slicing une seule fois, le crit`ere de simplification ´etant

l’en-1.3. Contributions semble de toutes les alarmes du programme qui ont ´et´e d´etect´ees par l’analyse statique.

L’inconv´enient de cette utilisation est que la g´en´eration de tests peut manquer de temps ou d’espace et les alarmes les plus faciles `a classer sont p´enalis´ees par l’analyse d’autres alarmes plus complexes. Dans la deuxi`eme utilisation, nomm´eeeach, leslicing est effectu´e s´epar´ement par rapport `a chaque alarme. Cependant, la g´en´eration de test est ex´ecut´ee pour autant de programmes que d’alarmes et il y a un risque de redondance d’analyse si des alarmes sont incluses dans plusieurs programmes. Ces contributions ont ´et´e publi´ees dans [CKGJ11], o`u nous avons pr´esent´e la m´ethode int´egrant leslicing avec les utilisations all eteach.

Pour pallier les inconv´enients des deux options pr´esent´ees, nous avons ´etudi´e les d´e-pendances entre les alarmes et nous avons introduit deux utilisations avanc´ees duslicing, nomm´ees min et smart, qui exploitent ces d´ependances. Dans l’utilisation min, le sli-cing est effectu´e par rapport `a un ensemble minimal de sous-ensembles d’alarmes. Ces sous-ensembles sont choisis en fonction de d´ependances entre les alarmes et l’union de ces sous-ensembles couvre l’ensemble de toutes les alarmes. Avec cette utilisation, on a moins de slices qu’avec each, et des slices plus simples qu’avec all. Cependant, l’analyse dynamique de certainesslices peut encore manquer de temps ou d’espace avant de classer certaines alarmes, tandis que l’analyse dynamique d’une slice ´eventuellement plus simple permettrait de les classer. L’utilisation smart consiste `a appliquer l’utilisation pr´ec´edente it´erativement en r´eduisant la taille des sous-ensembles quand c’est n´ecessaire. Lorsqu’une alarme ne peut pas ˆetre class´ee par l’analyse dynamique d’uneslice, desslicesplus simples sont calcul´ees. Ces deux options sont d´etaill´ees dans [CKGJ12].

1.3.3 Formalisation

Nous formalisons la m´ethode propos´ee et nous prouvons sa correction. Nous prouvons que lorsqu’une alarme est class´ee sans risque sur un programme simplifi´e, ce classement serait le mˆeme sur le programme initial. Lorsqu’une erreur est d´etect´ee pour une alarme sur le programme simplifi´e, une simple confirmation par ex´ecution du programme initial permet de v´erifier le statut de cette alarme dans le programme initial.

1.3.4 Impl´ ementations

Ces travaux sont implant´es dans sante, nouvel outil qui relie l’outil de g´en´eration de test PathCrawler [WMM03, WMMR05, BDHTH⁺09] et la plate-forme d’analyse statique Frama-C[Fra11, CS09]. Cette contribution a ´et´e publi´ee dans [Che10], o`u nous avons pr´esent´e l’outil sante controller.

1.3.5 Evaluation exp´ ´ erimentale

Les exp´erimentations ont ´et´e men´ees en utilisant l’impl´ementation pour valider notre approche sur un ensemble de programmes et mettre en ´evidence ses limites. Nous compa-rons notre m´ethode avec l’analyse de valeurs seule et l’analyse dynamique seule sur des crit`eres tels que le nombre de menaces restantes non class´ees et le temps requis par chaque analyse. Nous mesurons aussi l’effet de la simplification syntaxique sur la longueur des chemins analys´es et leur nombre, ainsi que sur la taille du programme. Ces r´esultats sont pr´esent´es dans [CKGJ10b] et [CKGJ12].