Soutenance de thèse de Omar CHEBARO le 13/12/2011 au CEA SACLAY

La validation des logiciels est une partie cruciale dans le cycle de leur d´eveloppement. Deux techniques de vérification et de validation se sont démarquées au cours de ces dernières années : l’analyse statique et l’analyse dynamique.
Les points forts et faibles des deux techniques sont compl´ementaires.
Nous présentons dans cette th`ese une combinaison originale de ces deux techniques. Dans cette combinaison, l’analyse statique signale les instructions risquant de provoquer des erreurs à l’exécution, par des alarmes dont certaines peuvent ˆetre de fausses alarmes, puis l’analyse dynamique (g´en´eration de tests) est utilisée pour confirmer ou rejeter ces alarmes. L’objectif de cette thèse est de rendre la recherche d’erreurs
automatique, plus pr´ecise, et plus efficace en temps.
Appliquée à des programmes de grande taille, la génération de test, peut manquer de temps ou d’espace mémoire avant de confirmer certaines alarmes comme de vraies erreurs ou conclure qu’aucun chemin faisable peut atteindre l’´etat d’erreur de certaines alarmes et donc rejeter ces alarmes. Pour surmonter ce problème, nous proposons de r´eduire la taille du code source par le slicing avant de lancer la génération de test. Le slicing transforme un programme en un autre programme plus simple, qui est ´equivalent au
programme initial par rapport à certains critères.

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’ensemble 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 test 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´ee each, le slicing est
effectu´e s´epar´ement par rapport `a chaque alarme. Cependant, la g´en´eration de test est ex´ecut´ee pour
chaque programme et il y a un risque de redondance d’analyse si des alarmes sont incluses dans d’autres
slices.
Pour pallier ces inconv´enients, nous avons ´etudi´e les d´ependances entre les alarmes et nous avons introduit
deux utilisations avanc´ees du slicing, nomm´ees min et smart, qui exploitent ces d´ependances. Dans
l’utilisation min, le slicing 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 sousensembles
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 certaines slices peut 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’une slice, des slices plus simples sont calcul´ees.
Nous prouvons la correction de la m´ethode propos´ee. Ces travaux sont implant´es dans sante, notre
outil qui relie l’outil de g´en´eration de test PathCrawler et la plate-forme d’analyse statique Frama-C.
Des exp´erimentations ont montr´e, d’une part, que notre combinaison est plus performante que chaque
technique utilis´ee ind´ependamment et, d’autre part, que la v´erification devient plus rapide avec l’utilisation
du slicing. La simplification du programme par le slicing rend les erreurs d´etect´ees et les alarmes
restantes plus faciles `a analyser.