Outils d analyse statique

Transcription

1 Année : 2006/2007 GLG101 : Test et Validation du logiciel Nom du fichier : OUTILS_ANALYSE_STATIQUE.doc Rédacteur : Jean-Yves Bouttery Remis le 15 mai 2007 Destinataires : Mr ANDRZEJAK Willy Outils d analyse statique

2 INTRODUCTION. L analyse statique de programmes est une famille de techniques permettant de dériver des résultats sur l'exécution de programmes sans exécuter ces derniers. Au lieu de reconnaître le comportement du programme à l exécution, il s agit ici de découvrir ce qu il serait par une simple lecture et analyse du code source ou binaire selon le cas. Cette façon de faire offre des avantages sur l autre approche. Puisqu il n y a pas d exécution, la crainte de dommages n est plus et il n y a plus de temps d exécution. Par contre, il n est pas possible d être certain de certaines propriétés avec l analyse statique à cause du problème de l indécidabilité. Par exemple, dans un programme assembleur, une instruction indique de sauter à une adresse contenue dans un registre quelconque. Puisqu il n y a pas d exécution, on ne connaît pas cette adresse et les possibilités de valeurs du registre peuvent être très grandes. On ne pourra donc pas étudier statiquement tous les scénarios d exécution possibles du programme. Du fait de la complexité des programmes informatique, nous utilisons des programmes qui se nomment outils d analyse statique. Dans un premier chapitre, nous verrons les différentes utilisations possibles de ces outils. Nous verrons ensuite les informations utiles que nous pouvons retirer de cette analyse et nous essaierons de comprendre les méthodes qui permettent aux outils de trouver à ces informations. Nous terminerons enfin par une série de tableaux avec des noms d outils d analyse statique. 2

3 I. Les différents objectifs de l analyse statique Métriques. L analyse statique est utilisée en génie logiciel dans le but de calculer certaines métriques sur le code source d un programme. La proportion de code à l intérieur de boucles dans le programme et le nombre de scénarios d exécution possibles en sont des exemples. Une autre métrique peut être le taux de commentaires dans le programme. Cela a pour utilité d inciter et d aider les programmeurs à faire des programmes plus lisibles et donc plus faciles à maintenir. Détection d erreurs pouvant survenir à l exécution. Une autre fonctionnalité des outils d analyse statique est d étendre le travail des compilateurs. Il arrive que certaines erreurs provoquent l arrêt d un programme en cours d exécution parce qu elles n ont pas pu être détectées au cours de la compilation. Pour cette raison, ce sont ces problèmes de programmation qui prennent le plus de temps à être réglé. Les outils d analyse statique peuvent découvrir certaines de ces erreurs en lisant le code source. L accès à une variable à partir d un pointeur nul ou l accès à un tableau à l extérieur de ses bornes en sont des exemples. Les graphes. Certains outils d analyse statique construisent quelques types de graphes que nous verrons par la suite. Dans le cas où l outil en question ne va pas plus loin, c est-à-dire que son objectif est de faire les graphes associés à un programme, il faudrait être en mesure de récupérer la structure de données des graphes dans le but de l analyser avec un autre programme par la suite. Le découpage. Les outils qui font du découpage de programmes sont des outils d analyse statique. Puisque le découpage utilise le graphe de dépendance d un programme pour calculer ses résultats, le choix d un outil de découpage sera fait en fonction de la qualité des dépendances qu il trouve à l intérieur du programme analysé. 3

4 Politique de sécurité. Un outil d analyse statique peut faire de la détection de code malicieux. Il doit se baser sur une politique pour donner son verdict sur le programme analysé. Une façon de faire est l utilisation d automates de sécurité. Les transitions de ces automates correspondent aux instructions du programme. Ils comportent un ou plusieurs états qui ne doivent pas être atteints ; s ils le sont, cela signifie que la politique n a pas été respectée. Si un scénario d exécution du programme possède une suite d instructions, donc de transitions de l automate, qui fait atteindre un état tel que la politique n est pas respectée, le programme est considéré comme malicieux. 4

5 II. Informations retirées et méthode utilisées 1. Les informations retirées. Dans les sections de ce chapitre, il sera d abord question des informations utiles qu on peut tirer du code source d un programme et leurs représentations, souvent sous forme de graphes. Ensuite, la technique du découpage (aussi appelé focalisation ou slicing) qui est utile entre autres pour la détection de code malicieux sera présentée. Enfin, il sera question de l étape de vérification du programme en se servant des différentes informations recueillies. L arbre syntaxique. Avant de tirer les informations pertinentes d un programme, il est important, dans le cas d un code source, de vérifier que ce dernier respecte bien les règles de syntaxe du langage utilisé pour l écrire. La syntaxe d un langage étant représentée par une grammaire, il est possible de faire un arbre syntaxique du programme. C est à partir de cet arbre que les informations seront tirées puisque ce dernier écarte les détails inutiles reliés au code comme les commentaires et l indentation. Dans le cas du code exécutable, il peut être nécessaire que le programme soit d abord désassemblé dans le but d obtenir le code assembleur et ainsi obtenir un arbre syntaxique pour ce type de code qui sera utilisé par la suite pour l analyse. Le graphe de flot de contrôle. Il s agit d un graphe orienté dans lequel les noeuds représentent des instructions. Pour tout noeud, un arc quitte vers chaque noeud pour lequel les instructions peuvent suivre immédiatement celles du noeud courant. Il met en évidence les boucles, instructions conditionnelles et branchements. Un chemin dans ce graphe représente un scénario void main() { int x = 0; int y = 1; while (y < 10) { y = 2 * y; x = x + 1; } printf ("%d",x); printf ("%d",y); } d exécution du programme. Le programme suivant servira à donner un exemple pour ce type de graphe (voir figure 2.1) et sera également utilisé pour les autres graphes. 5

6 Le graphe de dépendance de contrôle. Ce graphe montre quelles instructions seront exécutées en fonction de la valeur d une expression dans le programme. Les noeuds du graphe sont les mêmes que ceux du graphe de flot de contrôle. Pour deux noeuds p et q, un arc va de p vers q si la valeur de l expression p a un impact sur le fait que l instruction q soit exécutée ou non. La figure 2.2 en montre un exemple. Dans cet exemple, on peut noter que la présence de la boucle sur l expression y < 10 est dû au fait qu elle devra être évaluée de nouveau si elle est vraie puisque le corps de cette boucle doit s exécuter tant qu elle est vraie, c est à dire jusqu à ce qu elle soit fausse. L analyse du flot de données Le flot de données peut aussi être analysé. Il informe sur le déplacement des données entre le programme, les disques, le réseau, etc. Il s agit ici du flot de données à travers les périphériques, mais on peut aussi analyser le flot de données à l intérieur du programme. Il permet d avoir de l information sur l utilisation des variables dans le temps. Il y a vraiment plusieurs méthodes plus ou moins complexes pour étudier le flot de données et celles-ci mènent à des informations différentes. Par exemple, une information de base qui peut être très utile est l ensemble des variables utilisées et celui des variables modifiées pour chaque instruction du programme. Voici l illustration de cette méthode sur le programme étudié ; les ensembles sont décrits à la suite de chaque ligne de code. void main() { int x = 0; int y = 1; while (y < 10) { y = 2 * y; Utilise={} Définit={x} Utilise={} Définit={y} Utilise={y} Définit={} Utilise={y} Définit={y} x = x + 1; Utilise={x} Définit={x} } printf ("%d",x); Utilise={x} Définit={} printf ("%d",y); Utilise={y} Définit={} } 6

7 Le graphe de dépendance de données Un autre graphe dont les noeuds sont les mêmes que celui du graphe de flot de contrôle peut être fait. Dans ce graphe, un arc va de p vers q s il est possible que la valeur d une des variables modifiées à l instruction p soit utilisée à l instruction q sans qu elle ne soit modifiée entre temps. La figure 2.3 en montre un exemple. Le graphe de dépendance de programme ou du système Un nouveau graphe est le graphe de dépendance de programme. Il n est rien d autre que l union du graphe de dépendance de contrôle et du graphe de dépendance de données (voir figure 2.4). On peut, pour garder plus de précision, différencier dans ce graphe les arcs venant des deux graphes en les étiquetant arc de contrôle et arc de données, c est pourquoi on entend rarement parler des deux autres. 7

8 Jusqu ici, les explications n ont pas fait mention qu un programme peut être composé de plusieurs procédures. Si c est le cas, on commence par faire le graphe de dépendance de programme pour chaque procédure de façon indépendante. Il y a ensuite une façon de relier ces graphes pour faire le graphe de tout le programme que l on appellera graphe de dépendance du système. Pour chaque appel de fonction, le noeud représentant le point d appel est relié par un arc de contrôle au point d entrée de la fonction appelée ainsi qu à un noeud représentant chaque paramètre effectif et la sortie effective (variable qui accepte la valeur retournée par la fonction). Ce dernier point, s il existe, possédera des dépendances de données vers les instructions qui utilisent sa valeur. à l intérieur de la fonction appelée, il y a un arc de dépendance de contrôle qui va du point d entrée vers un noeud représentant chaque paramètre formel et la sortie formelle (valeur retournée par la fonction). Il y a un arc de dépendance de données de chaque paramètre effectif vers le paramètre formel associé ainsi que de la sortie formelle vers la sortie effective pour chaque point d appel. De plus, il y aura les arcs de dépendance de données adéquats des paramètres formels vers les instructions de la fonction et des instructions vers la sortie formelle. La figure 2.5 montre un exemple de graphe de dépendance du système pour le programme suivant. Dans ce graphe, les arcs inter procéduraux sont en pointillés. Parmi ces arcs, ceux en lignes courbes sont des arcs de contrôle, les autres sont des arcs de données. int somme(int a,int b) { int c; c = a + b; return c; } void main() { int x; int y; x = somme(2,3); printf("%d",x); y = somme(x,3); printf("%d",y); } 8

9 Le découpage. Le découpage est une technique utilisée dans le but de faire ressortir certaines instructions d un programme en relation avec une propriété. Le Résultat du découpage est donc un sousensemble du programme. Il en existe deux types, le découpage arrière et le découpage avant dont les résultats seront présentés à la section suivante. Cette technique est utile à la réutilisation du code. Par exemple, si un programme calcule plusieurs résultats simultanément en mélangeant les calculs nécessaires à chacun d eux, mais qu un seul de ces résultats est utile pour un autre programme, un découpage arrière sur la variable qui contient ce résultat dans le programme donne un sous-programme sans les instructions superflues. Elle sert aussi à comprendre des programmes compliqués puisque son résultat est un programme plus petit, donc plus facile à analyser. Une utilité particulièrement intéressante est la possibilité de réduire le problème de l indécidabilité de l analyse statique. Pour appliquer cette technique sur un programme composé d une seule fonction, on se sert du graphe de dépendance du programme. Il est aussi possible de faire le découpage selon le flot de données seulement ou le flot de contrôle seulement en ne considérant que les arcs de contrôle ou les arcs de données dans le graphe. Dans le graphe de dépendance du programme, on choisit le noeud correspondant à l instruction sur laquelle on désire effectuer le découpage. Dans le cas du découpage arrière, il s agit des noeuds qui peuvent atteindre le noeud choisi, ceux accessibles en suivant les arcs à contresens à partir du noeud choisi. La figure 2.6 montre le graphe de dépendance de programme en mettant en évidence (par des arcs en gras) le découpage arrière sur l instruction printf(y). La figure 2.7 montre le nouveau graphe de flot de contrôle pour le sous-programme résultant de ce découpage. 9

10 Dans le cas du découpage avant, le sous-programme contient les instructions représentées par les noeuds que l on peut atteindre à partir du noeud choisi en suivant les arcs. Voici maintenant comme faire pour un programme composé de plusieurs fonctions. Le découpage est plus difficile à faire lorsqu il nécessite une analyse inter procédurale. Dans ce cas, il faut utiliser le graphe de dépendance du système. La façon de faire est la même que pour le découpage intra procédural, mais il faut faire attention à une chose. Par exemple, pour le découpage avant, si on entre dans une fonction en suivant les flèches, lorsqu on arrivera à la sortie formelle qui est le dernier point à l intérieur de la fonction appelée avant d en ressortir, il faudra seulement choisir l arc qui retourne vers le site d appel et non tous les arcs comme il faut faire d habitude. Dans le cas du découpage arrière, c est la même chose, il faut revenir sur les arcs qui vont vers les paramètres effectifs du site d appel par lequel on était entré (par la sortie) dans la fonction appelée. La figure 2.8 montre un découpage avant sur le deuxième appel de la fonction somme fait à partir du graphe de dépendance du système à la figure 2.5 en mettant les arcs et les noeuds en gras. A la sortie de la fonction somme, une croix est dessinée sur une des flèches pour montrer qu il ne faut pas l emprunter, car elle ne retourne pas dans la fonction main à l endroit où la fonction somme a été appelée. 10

11 2. Les méthodes utilisées. Analyse statique par analyse lexicale et syntaxique L analyse lexicale consiste à découper le programme en petites entités appelées tokens (opérateurs, mots réservés, variables, constantes numériques, alphabétiques ). Exemple : for i :=1 to vmax do a :=a+i; On peut dégager la suite de tokens suivante et construire la table des symboles. Ensuite, l énoncé peut s écrire sous la forme d une suite de référence à la table des symboles : 10, 1000, 100, 5001, 11, 1002, 12, 1001, 100, 1001, 101, 1000, 13 for i := 1 to vmax do a + a + i ; Lors de l'analyse syntaxique, on vérifie que l'ordre des tokens correspond à l'ordre défini pour le langage. On dit que l'on vérifie la syntaxe du langage à partir de la définition de sa grammaire. Cette phase produit une représentation sous forme d'arbre de la suite des tokens obtenus lors de la phase précédente (fig. suivante). 11

12 A partir de ces analyses, on peut extraire certaines métriques. Les métriques de complexité Halstead ont été développées par le défunt Maurice Halstead comme un moyen de déterminer une mesure quantitative de complexité directement des opérateurs et opérandes dans le module afin de mesurer la complexité d'un module de programme directement depuis le code source. Parmi les précurseurs de la métrique de logiciel, ils sont les indicateurs forts de la complexité de code. Du fait qu'ils soient appliqués au code, ils sont plus souvent utilisés comme une métrique de maintenance. Il est évident que les mesures Halstead sont aussi utiles durant le développement, pour accéder à la qualité du code dans les applications denses. Elles font partie des plus vieilles mesures de complexité de programme (introduites en 1977). Les métriques de Halstead sont basées sur l'interprétation du code comme une séquence de marqueurs, classifiés chacun comme étant un opérateur ou une opérande. nombre d'opérateurs uniques (distints)(n1) nombre d'opérandes uniques (distinctes)(n2) nombre total d'opérateurs (N1) nombre total d'opérandes (N2) Le nombre d'opérateurs et opérandes uniques (n1 et n2), aussi bien que le nombre total d'opérateurs et d'opérandes (N1 et N2) sont calculés en collectant les fréquences de chacun des opérateurs et opérandes pris dans le programme source. D'autres mesures sont dérivées de ces quatre quantités avec des formules décrites plus tard. Les Opérandes : Les marqueurs des catégories suivantes sont comptés comme des opérandes par CMT++ 1 IDENTIFIER Toutes les marques qui ne sont pas des mots réservés TYPENAME TYPESPEC CONSTANT (spécificateurs de type) Mots réservés qui spécifient le type : bool, char, double, float, int, long, short, signed, unsigned, void. Cette classe inclut aussi quelques mots clefs non standards spécifiques de compilateur. caractère, nombre, constante ou chaîne de caractères. 1 CMT++ et CMT JAVA : outils de mesure de complexité pour c++ et java. 12

13 Les opérateurs : Les marqueurs des catégories suivantes sont tous comptés comme opérateurs par les directives du pré processeurs de CMT++ (cependant, les marqueurs asm et this sont comptés comme opérandes) : SCSPEC TYPE_QUAL RESERVED OPERATOR (spécificateurs de classes de stockage) mots réservés qui spécifient la classe de stockage : auto, extern, inlin, register, static, typedef, virtual, mtuable. (qualifieurs de type) mots réservés qui qualifient le type : const, friend, volatile. Autres mots réservés de C++ : asm, break, case, class, continue, default, delete, do, else, enum, for, goto, if, new, operator, private, protected, public, return, sizeof, struct, switch, this, union, while, namespace, using, try, catch, throw, const_cast, static_cast, dynamic_cast, reinterpret_cast, typeid, template, explicit, true, false, typename. Cette classe inclut aussi quelques mots clefs non standards spécifiques de compilateur. Un des suivants :!!= % %= & && &= ( ) * *= =, = ->.... / /= : :: < << <<= <= = == > >= >> >>=? [ ] ^ ^= { } = ~ Les structures de contrôle suivantes case...: for (...) if (...) seitch (...) while for (...) et catch (... )sont traitées d'une manière spéciale.les ':' ';' et les parenthèses sont considérés comme étant une partie des constructions. Le cas et les ':' ';' ou les for (...) if (...) switch (...) while for (...) et catch (...) et les parenthèses sont comptés ensemble comme un opérateur. Les commentaires : COMMENTS Les commentaires délimités par /* et */ ou // et les nouvelles lignes n'appartiennent pas à l'ensemble de marques de C++, mais ils sont comptés par CMT++. 13

14 Le nombre d'opérateurs et opérandes uniques (n1 et n2), aussi bien que le nombre total d'opérateurs et opérandes (N1 et N2) sont calculés en collectant les fréquences de chaque opérateur et opérande trouvé dans le programme source. Toutes les autres mesures de Halstead sont dérivées des quatre quantités utilisant l'ensemble suivant de formules. La longueur du programme (N) : La longueur du programme (N) est la somme du nombre total d'opérateurs et d opérandes du programme : N = N1 + N2 La taille du vocabulaire (n) : La taille du vocabulaire (n) est la somme du nombre d'opérateurs et d opérandes uniques: n = n1 + n2 Le volume du programme (V) : Le volume du programme (V) est le contenu de l'information du programme, mesuré en bits mathématiques. Il est calculé avec la longueur du programme multipliée par le logarithme 2 de la taille du vocabulaire (n) : V=N* Log2(n) Le volume d'halstead (V) décrit la taille de l'implémentation d'un algorithme. Le calcul de V est basé sur le nombre d'opérations effectuées et d'opérandes gérées dans l'algorithme. Par conséquent V est moins sensible à la disposition du code que les mesures de lignes de code. Le volume d'une fonction devrait être au moins de 20 et au plus de Le volume d'une fonction, d'une ligne et sans paramètre, qui n'est pas vide est d'environ 20. Un volume plus grand que 1000 indique de la fonction comporte probablement trop de choses. Le volume d'un fichier devrait être d'au moins 100 et au plus Ces limites sont basées sur les volumes mesurés pour les fichiers pour lesquels LOCpro et v(g) sont près de leurs limites recommandées. Les limites de volume peuvent être utilisées pour une double vérification. CMT++ calcule les métriques de lignes de code suivantes : LOCphy: nombre de lignes physiques (total des lignes des fichiers source) LOCbl: nombre de lignes vides (une ligne vide comprennant un bloc de commentaires est considéré comme une ligne de commentaires) 14

15 LOCpro: nombre de lignes de programme (déclarations, définitions, directives, et code) LOCcom: nombre de lignes de commentaire v(g) : Le nombre cyclomatique de McCabe v(g) montre la complexité du flux de contrôle dans une partie du code. v(g) est le nombre de branches conditionnelles dans l'organigramme. La complexité cyclomatique (également référée comme complexité de programme ou complexité de McCabe) est le membre le plus largement répandu des métriques statiques. Il peut être considéré comme une large mesure de solidité et de confiance pour un programme. La complexité cyclomatique a été introduite par Thomas McCabe en Elle mesure le nombre de chemins linéaires indépendants dans un module de programme. La complexité McCabe est l'un des métriques de software les plus largement acceptées, elle est conçue pour être indépendante du langage et du format de langage. Le nombre cyclomatique McCabe v(g) est calculé à partir des définitions de fonctions (ou membres) et des déclarations de classes/structures. Il est calculé sur le fichier source en entier. Lorsque le test est concerné, le nombre cyclomatique v(g) est l'une des plus importantes mesures de complexité. Du fait que le nombre cyclomatique décrive la complexité du flux de contrôle, il est évident que les modules et les fonctions ayant un nombre cyclomatique élevé auront besoin de plus de cas de tests que les modules ayant un nombre cyclomatique plus bas. Comme principe de base, chaque fonction devrait avoir un nombre de cas de tests au moins égal au nombre cyclomatique. Le nombre cyclomatique d'une fonction devrait être inférieur à 15. Si une fonction a un nombre cyclomatique de 15, il y a au moins 15 (mais probablement plus) chemins d'exécution dans son contenu. Plus de 15 chemins sont difficiles à identifier et tester. Les fonctions contenant un état de sélection avec beaucoup de branches constituent une exception. Un nombre cyclomatique limite raisonnable maximum d'un fichier est de 100. En résumé, pour le calcul du nombre cyclomatique, les constructions de langage suivants incrémentent le nombre cyclomatique: if (...), for (...), while (...), case...:, catch (...), &&,,?, #if, #ifdef, #ifndef, #elif.. 15

16 Le niveau de difficulté (D) : Le niveau de difficulté ou propension d'erreurs du programme est proportionnel au nombre d'opérateurs uniques dans le programme. D est aussi proportionnel au ratio entre le nombre total d'opérandes et le nombre d'opérandes uniques (ex : si les mêmes opérandes sont utilisées plusieurs fois dans le programme, il est plus enclin aux erreurs) : D = ( n1 / 2 ) * ( N2 / n2 ) Le niveau de programme (L) : Le niveau de programme (L) est l'inverse de la propension d'erreurs du programme Ex : un programme de bas niveau est plus enclin aux erreurs qu'un programme de haut niveau. L = 1 / D L effort à l'implémentation (E) : L'effort à l'implémentation (E) ou la compréhension d'un programme est proportionnel au volume et au niveau de difficulté du programme : E = V * D Le temps pour implémenter (T) : Le temps pour implémenter ou comprendre un programme (T) est proportionnel à l'effort. Des expérimentations empiriques peuvent être utilisées pour le calibrage de cette quantité. Halstead a découvert que diviser l'effort par 18 donne une approximation pour le temps en secondes : T = E / 18 Le nombre de bugs fournis (B) : Le nombre de bugs fournis (B) corrèle avec la complexité globale du logiciel. Halstead donne la formule suivante pour B : B = ( E (2/3) ) / 3000 Les bugs livrés d'halstead sont une estimation du nombre d'erreurs dans l'implémentation. Les bugs livrés dans un fichier devraient être moins de 2. Des expériences ont montrées que, quand on programme en C ou C++, un fichier source contient presque toujours plus d'erreurs que B ne suggère. Le nombre de défaut tend à grandir plus rapidement que B. Quand le test de dynamique est concerné, la métrique de Halstead la plus importante est le nombre de bugs livrés. Ce nombre approche le nombre d'erreurs dans un module. Comme objectif, au moins autant d'erreurs que B indique devraient être trouvées pendant le test du module. 16

17 Analyse statique par interprétation abstraite. Les logiciels complexes comportant quasiment tous des erreurs, les chercheurs ont développé des méthodes de preuve de la correction des programmes. Ceci consiste à fournir une sémantique décrivant formellement les exécutions d'un programme, puis à démontrer un théorème exprimant que ces exécutions ont une certaine propriété (comme par exemple qu'un résultat attendu est fourni en un temps fini). Des résultats mathématiques fondamentaux montrent qu'il n'est pas possible de faire faire ces preuves automatiquement par des ordinateurs. Devant cette difficulté fondamentale, l'interprétation abstraite procède par approximation correcte de la sémantique. Si l'approximation est suffisamment grossière, elle est calculable par un ordinateur. Si elle est suffisamment fine, elle permet d'obtenir une preuve formelle de correction. L'objectif est donc de rechercher des approximations suffisamment précises et peu coûteuses à calculer. L'analyse statique par interprétation abstraite a été introduite par P. Cousot et R. Cousot 2. Elle s'appuie sur la sémantique des langages de programmation, l abstraction choisie sur le domaine de la sémantique et l analyseur statique pour décrire mathématiquement les comportements d'un programme informatique. Avec cette description, il est possible de vérifier statiquement (sans exécution du programme) des propriétés dynamiques, c'est-à-dire dépendantes de l'exécution (code mort, débordement de tableau, flot de données, etc.). A un programme P décrit dans un langage de programmation quelconque, on associe une sémantique concrète définissant le comportement de P. Cette sémantique est souvent trop "précise" et on ne peut pas vérifier le comportement du programme pour toutes les entrées possibles. La génération de tests pour les logiciels permet de choisir des valeurs particulières pour connaître si le programme P fait bien ce qu'on attend de lui, dans certains cas. Le "model checking"(spin/promela, etc.) modélise le programme sous une forme différente (réseaux de Pétri, automates, etc.) et teste exhaustivement tous les états du programme. L'explosion combinatoire empêche, dans une grande partie des cas, d'aboutir sur des résultats concluants. L'analyse statique peut permettre, grâce à l'utilisation de la logique de Hoare 3 de prouver certaines propriétés des programmes. (outil Caveat),

18 Ces propriétés peuvent être de différentes natures : - fonctionnelles : le système remplit la fonction attendue, - structurelles, par exemple l'absence de code mort ou encore la couverture des instructions par un ensemble de tests, - de sûreté, par exemple l'absence d'erreurs à l'exécution comme une division par zéro ou un blocage, - etc. L'interprétation abstraite modifie la sémantique concrète du programme en une sémantique abstraite, moins précise, permettant de limiter les états du programme. Par cette méthode, il est ainsi plus aisé de vérifier que, pour une certaine plage d'entrées, l'exécution du programme P ne génère pas certaines erreurs. L'avantage principal de cette méthode est de permettre une automatisation du procédé d'analyse. Cette technique se base sur des outils mathématiques telles que les fonctions monotones sur des ensembles ordonnés, en général des treillis. Il faut cependant montrer que la sémantique abstraite décrit correctement, par rapport à la sémantique concrète le comportement du programme même si une approximation est faite. La correspondance entre la sémantique abstraite et la sémantique concrète se fait par le biais d'une correspondance de Galois 4. Cette construction mathématique permet de définir la sémantique abstraite constructivement à partir de la sémantique concrète, et permet ainsi de garantir la correction de l'analyse. PolySpace C Verifier est un outil d analyse statique conçu par la compagnie PolySpace Technologies. Il détecte les erreurs pouvant survenir à l exécution dans les programmes en langage C en se servant de l interprétation abstraite. Cet outil n est pas gratuit, mais il est possible d en demander une copie d évaluation. Polyspace technologies et sa technologie unique au monde consiste à détecter les erreurs commises sur les programmes de logiciels embarqués. Avec ses deux produits phares, Polyspace Ada Verifier (Ariane v) et Polyspace C Verifier, cette PME détient 90 % du marché pour les systèmes embarqués (en 2001) et se positionne dans les domaines critiques (aéronautique, ferroviaire, l'automobile, l'énergie ou le médical)

19 III. Bibliographie des outils trouvés : Voici une liste des outils trouvés présentée par les tableaux suivants. Cette liste ne peut pas être exhaustive tant le nombre d outils d analyse statique est grand. 19

20 Les deux tableaux ci-dessous donnent un complément (fig. 3.1 et 3.2). 20

21 21

22 Des analyseurs syntaxiques sont aussi développés dans les universités. Conclusion. Nous avons vu que les outils d analyse statique peuvent répondre à beaucoup de questions telles que l analyse de métriques, les problèmes de fonctionnement d un programme, les problèmes liés à la sécurité, la qualité du développement Mais l analyse statique n est pas suffisante pour garantir le bon fonctionnement d un programme. En effet il y a toujours le problème de l indécidabilité de certaines actions, c est pour cela que l analyse statique doit être couplée à l analyse fonctionnelle. 22