Évaluation des outils d'analyse statique pour les graphes d'appels JavaScript

JavaScript est un langage de programmation super populaire utilisé à la fois côté client et serveur. Avec son utilisation massive, analyser le code JavaScript devient de plus en plus important. Beaucoup de méthodes pour déceler des vulnérabilités, des problèmes de codage ou des soucis de type dépendent de la compréhension du graphe d'appels d'un programme. Un graphe d'appels, c'est une carte qui montre comment les Fonctions d'un programme s'appellent entre elles.

Alors que l'analyse dynamique, qui consiste à faire tourner le programme, a ses avantages, l'Analyse Statique est précieuse parce qu'elle ne nécessite pas d'exécuter le programme. Les méthodes statiques pour créer des Graphes d'appels peuvent faire gagner du temps et des ressources. Dans cette étude, on a regardé cinq méthodes d'analyse statique populaires qui créent des graphes d'appels pour JavaScript. On a testé ces méthodes sur un ensemble de programmes de référence et des modules Node.js du monde réel pour voir comment elles se comportent en termes de vitesse, d'utilisation de mémoire et de précision.

#Qu'est-ce qu'un Graphe d'Appels ?

Un graphe d'appels affiche les fonctions d'un programme comme des nœuds et les appels entre ces fonctions comme des arêtes. Si une fonction appelle une autre, il y aura une arête dirigée de la fonction appelante à la fonction appelée. En analysant ce graphe, on peut déceler divers problèmes, comme des fonctions qui ne sont jamais appelées ou des erreurs dans le nombre d'arguments passés à une fonction.

Cette représentation est cruciale pour les vérifications de qualité et de sécurité en JavaScript. Par exemple, ça aide à construire des analyses plus complexes, comme des graphes de flux de contrôle, qui fournissent des aperçus plus profonds sur le fonctionnement d'un programme.

#L'Importance de l'Analyse Statique du Code

Avec l'essor des projets JavaScript, l'analyse statique du code a pris de l'importance. L'analyse statique fait référence à l'examen du code sans l'exécuter. Ça veut dire que les développeurs peuvent trouver des problèmes potentiels avant de faire tourner le code, ce qui leur fait gagner du temps et évite les bugs.

Il existe de nombreux outils pour effectuer une analyse statique, et la plupart d'entre eux dépendent des graphes d'appels pour offrir des aperçus sur le programme. Un graphe d'appels précis peut directement influencer l'efficacité de ces outils d'analyse.

Cependant, JavaScript est un langage dynamique et flexible, ce qui rend la création de graphes d'appels précis difficile. Les techniques qui fonctionnent bien avec d'autres langages peuvent ne pas être efficaces avec JavaScript en raison de ses caractéristiques uniques, comme le fait de permettre d'avoir des fonctions passées comme arguments ou créées à l'exécution.

#Outils d'Analyse Statique

Dans notre étude, on a examiné cinq outils qui créent des graphes d'appels pour JavaScript. Ces outils sont :

1. graphe d'appels npm
2. IBM WALA
3. Google Closure Compiler
4. Graphe d'Appels Approximatif (ACG)
5. Analyseur de Type pour JavaScript (TAJS)

Ces outils ont été choisis en fonction de leur popularité et de leur praticité. Chaque outil fonctionne différemment, mais tous visent à analyser le code JavaScript et à produire des graphes d'appels.

#Méthodologie

Pour comparer ces outils, on les a analysés en utilisant différents programmes de test. On a sélectionné 26 programmes de référence à partir de la suite de tests SunSpider, qui est largement utilisée pour mesurer la performance de JavaScript. On a également inclus six modules Node.js du monde réel connus pour leur complexité.

On a fait fonctionner chaque outil sur ces entrées, rassemblant des données sur combien de fonctions et d'appels chaque outil a trouvés. Les résultats ont été compilés et comparés pour une analyse plus poussée.

#Entrées de Test

On a regroupé nos entrées de test en trois catégories :

1. Exemples à fichier unique : Ce sont des programmes JavaScript simples qui contiennent tout leur code dans un seul fichier. Ils sont relativement petits et faciles à analyser.

2. Exemples Node.js multi-fichiers : Ce sont des programmes Node.js typiques qui utilisent plusieurs fichiers. Ils impliquent souvent une structure complexe et des dépendances externes.

3. Exemples générés : Pour tester les outils avec des programmes plus grands et plus complexes, on a généré du code JavaScript basé sur des motifs spécifiques. Ça nous permet de faire des tests de stress sur les outils.

#Analyse de Performance

Quand on analyse la performance des outils, on a pris en compte deux facteurs principaux : la vitesse et la consommation de mémoire.

1. Vitesse : On a mesuré combien de temps chaque outil a mis pour analyser les programmes d'entrée et produire un graphe d'appels.

2. Consommation de Mémoire : On a regardé combien de mémoire chaque outil utilisait pendant le processus d'analyse.

En comparant ces facteurs, on peut déterminer quels outils sont plus efficaces ou capables de gérer des entrées plus grandes.

#Résultats des Programmes de Référence

On a calculé diverses statistiques à partir de nos tests des programmes de référence SunSpider. Chaque outil a montré des résultats différents en termes de nombre de fonctions et d'appels identifiés. Dans certains cas, les outils ont produit des résultats similaires, surtout pour les petits programmes où il y avait moins de fonctions.

Cependant, pour les programmes plus grands ou plus complexes, les résultats variaient fortement entre les outils, illustrant que chaque outil a ses forces et ses faiblesses. Certains outils étaient meilleurs pour identifier certains types d'appels, tandis que d'autres les ont complètement ratés.

#Analyse des Modules Node.js

Quand on a regardé les modules Node.js, on a trouvé que tous les outils n'étaient pas capables de les analyser complètement. Certains outils avaient du mal avec la structure multi-fichiers et ne pouvaient pas résoudre les appels entre différents fichiers. Seuls deux outils, Closure Compiler et ACG, pouvaient analyser efficacement ces entrées plus complexes.

On a rassemblé des statistiques sur les fonctions et les appels trouvés par les deux outils dans les modules Node.js. Le recoupement des appels trouvés par ces deux outils était substantiel, montrant qu'ils pouvaient identifier correctement beaucoup des mêmes connexions, mais des différences existaient quand même.

#Analyse Qualitative

En plus de mesurer la performance, on a également effectué une analyse qualitative. Ça impliquait d'examiner les appels identifiés par les outils et de déterminer lesquels étaient de vrais positifs sur la base de nos évaluations manuelles.

À travers cette analyse, on a pu voir combien des appels identifiés étaient précis et comment les outils se comparaient en termes de précision et de rappel. La précision se réfère à la proportion d'appels vrais positifs parmi tous les appels identifiés, tandis que le rappel indique combien d'appels vrais positifs ont réellement été trouvés par l'outil.

#Observations et Comparaison des Outils

Chaque outil avait ses avantages et ses inconvénients :

• Closure Compiler : Cet outil a montré de bonnes Performances pour identifier les appels récursifs et avait un bon équilibre entre vitesse et consommation de mémoire. Cependant, sa précision était affectée par sa dépendance à un simple appariement de noms.

• ACG : Cet outil avait une excellente précision et pouvait suivre des flux de contrôle complexes efficacement. Cependant, il a raté certains appels de fonctions de plus haut niveau, qui sont courants en JavaScript.

• WALA : WALA a pu identifier des appels de fonctions plus complexes mais a souffert d'un rappel plus faible et d'une consommation de mémoire plus élevée par rapport aux autres outils.

• graphe d'appels npm : Cet outil avait une haute précision mais n'a identifié aucun appel unique qui était vrai.

• TAJS : Bien que TAJS ait produit des résultats avec une précision presque parfaite, il avait un faible rappel.

#Performance Combinée des Outils

En combinant les forces de différents outils, on a découvert que l'utilisation de plusieurs outils ensemble menait souvent à de meilleurs résultats. Par exemple, ACG et TAJS se complétaient bien, offrant un équilibre presque parfait de précision et de rappel lorsqu'ils étaient combinés.

Ça suggère qu'une approche idéale pour l'analyse statique pourrait être de développer des algorithmes qui intègrent les meilleures caractéristiques des outils existants.

#Discussion sur les Résultats

Les résultats de notre recherche indiquent qu'aucun outil unique n'est supérieur pour toutes les situations. La nature dynamique de JavaScript signifie que certains types d'appels de fonctions sont intrinsèquement plus difficiles à suivre. Différents outils se concentrent sur différents aspects du code, ce qui entraîne des variations dans leurs résultats.

Les améliorations futures de l'analyse statique pourraient bénéficier de la construction sur les forces de plusieurs outils, visant à créer un cadre d'analyse plus complet qui peut gérer les particularités du code JavaScript plus efficacement.

#Conclusion

En résumé, l'analyse statique de JavaScript est cruciale dans le processus de développement, compte tenu de son utilisation croissante dans diverses applications. Les cinq outils qu'on a examinés offrent chacun des capacités uniques en matière de création de graphes d'appels. En comprenant leurs forces et faiblesses, les développeurs peuvent choisir l'outil adapté à leurs besoins spécifiques et améliorer la qualité globale de leur code JavaScript.

À mesure que la technologie continue d'évoluer, il est essentiel de continuer à améliorer ces outils et à développer de meilleures méthodes pour analyser la nature dynamique et complexe des programmes JavaScript. Les insights tirés de cette étude peuvent guider les efforts de recherche et de développement futur dans l'analyse statique du code.