Brevet FR3042291A1 — publié le 20170414

DISPOSITIF ET PROCÉDÉ DE VÉRIFICATION D'UN LOGICIEL L'invention concerne un dispositif de vérification de logiciel, mis en oeuvre par ordinateur, et notamment un tel dispositif adapté pour la vérification des logiciels de fonctionnement de véhicules spatiaux tels que des fusées et/ou des satellites ou encore de leurs installations au sol. L'invention s'étend également à un procédé mis en oeuvre par ordinateur adapté pour être exécuté par le dispositif de vérification du logiciel. De nos jours, de plus en plus de dispositifs complexes, encore parfois appelés "systèmes" notamment dans l'industrie spatiale, sont constitués d'éléments mécaniques, électriques et électroniques ainsi que d'une part grandissante d'éléments informatiques sans lesquels les autres éléments ne seraient pas en mesure d'interagir en vue de l'exécution d'une mission. Ainsi la qualité des éléments informatiques, et particulièrement des logiciels, est d'une importance au moins équivalente au respect des tolérances d'un élément mécanique ou électronique. De plus, de nombreux éléments tels que des capteurs ou des actionneurs sont fournis avec leur(s) logiciel(s) de fonctionnement servant par exemple à interroger un capteur pour qu'il fournisse une valeur physique et à interpréter la réponse du capteur ou à transmettre un paramètre à un actionneur, etc. Il convient donc de vérifier la qualité de ces logiciels, non seulement une fois assemblés dans le système complet, ce qui, compte tenu de la complexité du système, peut s'avérer extrêmement difficile et parfois source d'erreur, mais aussi individuellement, avant assemblage. Il existe deux méthodes principales pour tester un logiciel : une première méthode dite dynamique, qui consiste à préparer un jeu de données d'entrées telles que des valeurs de paramètres physiques susceptibles d'être délivrées par des capteurs, à exécuter le logiciel, en général sous sa forme d'instructions élémentaires fournies par une mémoire à un processeur (code objet) et à vérifier les réponses obtenues en termes de commandes appliquées à des actionneurs. Cependant, cette méthode de test, outre son coût très élevé, ne s'avère pas d'une exhaustivité suffisante, le jeu de données d'entrée ne permettant pas toujours 3042291 2 d'explorer tous les cas de figure du logiciel, particulièrement lorsque celui-ci comporte des opérations séquentielles, c'est-à-dire dépendant des états précédents du système. Une deuxième méthode a donc été développée, dite analyse 5 statique, permettant de prédire les comportements à l'exécution d'un programme par le seul examen de son code source. Selon un aspect de cette méthode, le code source de chaque logiciel est évalué au vu du respect d'un certain nombre de règles et/ou de métriques sans exécuter le logiciel. Dans le présent texte, on appelle "élément logiciel" un 10 programme d'ordinateur comportant une pluralité de lignes de code représentant des instructions en vue d'exécuter une fonction sur un ordinateur, notamment en relation avec des objets physiques tels que des capteurs, des actionneurs, des écrans de visualisation, etc. Chaque élément logiciel forme un tout pour exécuter une fonction et est écrit dans un langage unique. On appelle également "logiciel" un ensemble 15 d'éléments logiciels, adaptés pour fonctionner ensemble et formant la partie informatique d'un appareil ou d'un système complexe. On appelle "règle" une condition élémentaire qui doit être satisfaite par un élément logiciel, comme la présence ou l'absence d'une instruction prédéterminée, par exemple la présence d'un saut inconditionnel qui peut avoir pour 20 conséquence d'empêcher l'exécution d'autres instructions et entrainer un dysfonctionnement de l'élément logiciel. Le résultat d'un test selon une règle est en général binaire : passe / ne passe pas. On appelle "métrique" une mesure ou un comptage de certaines instructions ou groupes d'instructions exécutant une fonction 25 prédéterminée : par exemple une métrique peut être aussi simple que de compter le nombre d'instructions comprises entre deux bornes prédéfinies d'un sous-programme ou encore de compter le nombre de boucles d'itération prévues dans un sous-programme, etc. Le résultat d'un test selon une métrique est en général un nombre qui sera évalué par rapport à des limites prédéterminées. 3042291 3 Dans le présent texte, on appelle "module" un ensemble d'instructions informatiques formant un bloc cohérent susceptible d'être appelé en vue de son exécution par un autre programme, souvent de niveau supérieur. Dans ce texte, le terme "module" est réservé pour les programmes faisant partie du dispositif 5 de vérification d'éléments logiciels afin de les distinguer des éléments logiciels sur lesquels porte la vérification. Lorsqu'un module informatique est "adapté pour" exécuter une fonction, il convient de comprendre qu'il est programmé pour exécuter cette fonction. De manière générale, l'analyse statique d'un logiciel 10 commence par une représentation abstraite de celui-ci, comprenant en général une analyse lexicale permettant de déterminer une grammaire du logiciel, puis une analyse syntaxique qui conduit à la représentation du logiciel sous la forme d'un arbre syntaxique. Cet arbre syntaxique est ainsi une représentation simplifiée du logiciel sur laquelle on vérifie le respect des règles et/ou métriques. Cependant, la 15 création d'un arbre syntaxique est lourde et complexe et dépend du langage dans lequel est écrit le logiciel. Lorsque le logiciel est composé d'un assemblage de programmes, écrits dans divers langages et devant coopérer ensemble, il est difficile, voire impossible de créer un arbre syntaxique représentatif de l'ensemble du logiciel. 20 L'invention vise donc à fournir un dispositif de vérification capable de procéder à une analyse statique d'un logiciel formé d'éléments logiciels divers, le cas échéant écrits dans des langages différents. L'invention vise également un procédé de vérification d'un ensemble d'éléments logiciels permettant de vérifier le respect de règles ou de 25 métriques par ces éléments logiciels quel que soit le langage dans lequel ils sont écrits. L'invention vise encore un tel dispositif de vérification permettant une exécution rapide des différents tests, sans nécessiter d'étape d'analyse syntaxique approfondie du logiciel. 3042291 4 L'invention vise en outre un tel dispositif de vérification dans lequel l'ajout ou la suppression d'une ou plusieurs règle(s) est grandement facilité. L'invention vise également un tel dispositif de vérification permettant de retourner un résultat de test détaillé sous une forme synthétique et 5 facilement exploitable. Pour ce faire, l'invention concerne un dispositif de vérification d'éléments logiciels à analyser, comprenant au moins un ordinateur exécutant un logiciel principal, dit environnement de développement, des organes d'entrée de données comportant au moins un organe adapté pour lire un code source 10 de chaque élément logiciel et des moyens de visualisation d'un résultat d'analyse, et au moins un logiciel d'analyse, dit analyseur statique, comprenant une liste de règles de codage et de métriques à respecter par l'élément logiciel à analyser, caractérisé en ce que l'analyseur statique comprend deux modules d'extension : - un premier module, dit module graphique, adapté pour recevoir des 15 paramètres de test et traiter et afficher des résultats de test sur les moyens de visualisation, et - un second module, dit analyseur de test, adapté pour définir et exécuter une structure de test sur au moins un élément logiciel et pour fournir des résultats de test audit module graphique, ledit analyseur de test comprenant 20 au moins un séquenceur de test adapté pour définir pour chaque élément logiciel au moins un module de test, chaque module de test vérifiant la conformité de l'élément logiciel avec une et unique règle ou une et unique métrique. Le dispositif de vérification selon l'invention est un outil 25 informatique qui comprend un ordinateur équipé d'organes d'entrée de données comportant au moins un clavier et un organe de lecture, tel qu'un lecteur de disque, de CD ou DVD ou encore un organe de lecture d'une mémoire statique transportable telle qu'une clé USB, adapté pour transporter une ou plusieurs séries d'instructions formant le code source d'un ou plusieurs éléments logiciels à tester. 30 Bien entendu, l'ordinateur peut comprendre également des moyens de connexion 3042291 5 tels qu'une carte réseau pour entrer en communication avec un réseau d'ordinateurs dont l'un au moins contient et peut fournir le code source d'un élément logiciel à tester. L'ordinateur sur lequel est architecturé le dispositif de vérification comporte également des moyens de visualisation d'informations, tels qu'un écran et le cas 5 échéant des moyens de mémoire adaptés pour recevoir et enregistrer des résultats de test obtenus lors de la vérification des éléments logiciels. Cet ordinateur exécute un ensemble de programmes de base dont un logiciel principal dit environnement de développement. Cet environnement de développement permet, grâce à des liens de connexion préétablis dits points d'extension, de faire appel à des modules 10 d'extension (plug-in selon la terminologie anglo-saxonne) permettant d'exécuter des tâches et des fonctions non prévues initialement dans l'environnement de développement. Chaque module d'extension comporte également lui-même des points d'extensions permettent également de faire appel à d'autres modules d'extension en cascade. Ainsi, le dispositif de vérification selon l'invention 15 comporte un environnement de développement qui fait appel à un premier module d'extension appelé analyseur statique qui implémente un logiciel d'analyse, dont le rôle est de vérifier la conformité des éléments logiciels qui lui sont fournis à une liste de règles et/ou de métriques. L'analyseur statique fait à son tour appel à deux modules d'extension, un module graphique chargé de recevoir un paramétrage du ou 20 des tests à effectuer et d'afficher les résultats de test sur l'écran et/ou de les enregistrer dans des moyens de mémoire prévus à cet effet, et un second module, dit analyseur de test. L'analyseur de test comprend également des modules d'extension tels que des séquenceurs de test, chaque séquenceur de test étant adapté pour définir une liste de règles et/ou de métriques applicables aux éléments logiciels écrits dans 25 un langage prédéterminé et retourner cette liste à l'analyseur de test. Ce dernier fait alors appel aux modules de test définis par le séquenceur pour vérifier sur chaque élément logiciel une règle ou une métrique unique. Grâce à cette structure, il n'est plus nécessaire d'exécuter une préparation longue et complexe du logiciel à tester pour en définir une représentation sous la forme d'un arbre syntaxique. Le dispositif 30 permet d'exécuter sur chaque élément logiciel la vérification de la ou des règles 3042291 6 et/ou métriques appropriées au langage dans lequel est écrit l'élément logiciel. De plus, l'ajout ou la suppression d'une règle est simplifié : il suffit de rajouter (respectivement de supprimer) un séquenceur de test si un nouveau langage est à utiliser et/ou un module de test pour la règle ou la métrique considérée. Les 5 inventeurs ont ainsi pu constater que malgré la multiplicité des itérations effectuées pour vérifier chaque règle ou métrique sur chaque élément logiciel, l'efficacité totale du dispositif selon l'invention, tant lors de la mise en oeuvre que de l'exécution, se comparait favorablement aux dispositifs de la technique antérieure pour lesquels il est nécessaire d'établir un arbre syntaxique pour chaque langage et y appliquer la 10 vérification des règles. L'invention s'étend également à un procédé, mis en oeuvre par ordinateur, de vérification d'éléments logiciels à analyser, du type utilisant au moins un ordinateur exécutant un logiciel principal, dit environnement de développement, des organes d'entrée de données comportant au moins un organe adapté pour lire un 15 code source de chaque élément logiciel et des moyens de visualisation d'un résultat d'analyse, et au moins un logiciel d'analyse, dit analyseur statique, comprenant une liste de règles de codage et de métriques à respecter par l'élément logiciel à analyser, caractérisé en ce que, pour chaque élément logiciel à analyser : - un second module, dit analyseur de test, définit et exécute une structure de 20 test sur ledit élément logiciel, ledit analyseur de test comprenant au moins un séquenceur de test, - chaque séquenceur de test définit pour chaque élément logiciel au moins une liste de modules de test, - chaque module de test vérifie la conformité de l'élément logiciel avec une et 25 unique règle ou une et unique métrique, - l'analyseur de test retourne des résultats de test à un premier module, dit module graphique, - ledit module graphique affiche les résultats de test sur les moyens de visualisation. 3042291 7 Avantageusement et selon l'invention, chaque séquenceur de test est adapté au langage dans lequel l'élément logiciel est écrit. Ainsi, lorsque des éléments logiciels sont écrits dans des langages différents par exemple pour des capteurs ou actionneurs de divers fournisseurs, il n'est plus nécessaire de réécrire 5 ces éléments logiciels dans un langage commun à tous les éléments logiciels pour en tirer un arbre syntaxique adapté au langage considéré ou de réaliser autant d'arbres syntaxiques qu'il y a de langages utilisés. Il suffit de rajouter un module de test adapté pour vérifier la règle ou la métrique considérée dans le langage concerné, ou, le cas échéant, de rajouter un séquenceur de test correspondant au 10 langage utilisé pour y rattacher une pluralité de modules de règles ou de métriques adaptées. Avantageusement et selon l'invention, l'analyseur de test est adapté pour appeler une pluralité de séquenceurs de tests en fonction du langage dans lequel les éléments de logiciel sont écrits et d'une liste préétablie de règles 15 et/ou de métriques à vérifier. Ainsi, l'analyseur de test utilise des séquenceurs de test adaptés au langage considéré qui comportent chacun une liste de règles et/ou de métriques pertinentes pour ce langage ce qui évite de tenter de vérifier des règles inadaptées audit langage. Avantageusement et selon l'invention, l'analyseur de test est 20 adapté pour déclencher une lecture du code source d'au moins un élément logiciel, déterminer un séquenceur de test approprié à partir du langage dans lequel cet élément logiciel est écrit, extraire la liste des règles et/ou métriques adaptées audit langage et transmettre ledit élément logiciel au(x) module(s) de test correspondants. Ainsi, l'analyseur de test sélectionnera les éléments logiciels écrits dans le langage 25 du séquenceur de test déterminé et ignorera les autres afin de procéder à la vérification le plus rapidement possible. Avantageusement et selon l'invention, chaque module de test comporte un automate adapté pour exécuter le traitement d'une règle unique ou d'une métrique unique sur le code source d'un élément logiciel et pour retourner une 30 valeur représentative d'un résultat de la métrique considérée ou de conformité à la 3042291 8 règle considérée. En spécialisant chaque module de test pour l'exécution d'une et unique règle ou une et unique métrique, chaque module de test est simple à écrire et à valider et présente un temps d'exécution réduit. Avantageusement et selon l'invention, chaque module de test 5 retourne à l'analyseur de test une liste des éléments logiciels testés avec leur résultat pour la règle ou la métrique considérée. Ainsi, l'analyseur de test dispose d'une synthèse des résultats de la vérification de tous les éléments logiciels par rapport à une règle donnée. Avantageusement et selon l'invention, l'analyseur de test 10 transmet au module graphique la liste des éléments logiciels testés avec leurs résultats pour toutes les règles et métriques vérifiées en vue de leur affichage sur les moyens de visualisation. Avantageusement et selon l'invention, l'analyseur de test exécute chaque règle, respectivement chaque métrique, séquentiellement sur tous 15 les éléments logiciels. Dans ce mode d'exécution du procédé selon l'invention, l'analyseur de test exécute le module de test implémentant cette règle sur tous les éléments logiciels sur lesquels la vérification de la règle est prévue. Avantageusement et dans une variante du procédé selon l'invention, l'analyseur de test exécute séquentiellement toutes les règles, 20 respectivement toutes les métriques sur chaque élément logiciel. Cette variante peut s'avérer plus efficace dans certains cas, par exemple lorsque le nombre d'éléments logiciels à vérifier est important et que l'objectif est de cibler certaines parties de logiciel qui apparaissent plus complexes. L'invention s'étend également à un programme d'ordinateur 25 pour l'analyse statique du code source d'éléments logiciels caractérisé en ce qu'il comprend : - un premier module, dit module graphique, adapté pour recevoir des paramètres de test et traiter et afficher des résultats de test sur les moyens de visualisation, et 3042291 9 - un second module, dit analyseur de test, adapté pour définir et exécuter une structure de test sur au moins un élément logiciel et pour fournir des résultats de test audit module graphique, ledit analyseur de test comprenant au moins un séquenceur de test adapté pour définir pour chaque élément 5 logiciel au moins un module de test, chaque module de test vérifiant la conformité de l'élément logiciel avec une et unique règle ou une et unique métrique. L'invention concerne également un dispositif, un procédé et un programme de vérification d'éléments logiciels caractérisés en combinaison par 10 tout ou partie des caractéristiques mentionnées ci-dessus ou ci-après. D'autres buts, caractéristiques et avantages de l'invention apparaîtront au vu de la description qui va suivre et des dessins annexés dans lesquels : - la figure 1 représente un schéma d'un dispositif de vérification 15 selon l'invention; - la figure 2 représente un diagramme de déroulement d'une première partie du procédé selon l'invention; - la figure 3 représente un diagramme de déroulement détaillé d'une seconde partie du procédé selon l'invention; 20 - la figure 4 illustre un exemple d'automate de traitement d'une règle ou d'une métrique dans un module de test selon l'invention. La figure 1 représente un schéma bloc d'un dispositif 1 de vérification selon l'invention. Le dispositif 1 se compose d'au moins un ordinateur 2 comportant au moins un microprocesseur et des premiers moyens de mémoire 25 adaptés pour exécuter un logiciel principal sous la forme d'un environnement de développement 3, par exemple la plateforme "Eclipse" de la Fondation Eclipse. L'ordinateur est relié à un clavier 4 et à un lecteur 5 tels qu'un lecteur de bande, de CD-ROM ou de DVD ou tout autre moyen connu de l'homme du métier, ledit clavier 4 et ledit lecteur 5 servant d'organes d'entrée de données pour l'ordinateur 2. 3042 2 91 10 L'ordinateur 2 est également relié à un dispositif de visualisation sous la forme d'un écran 6, capable d'afficher les résultats des tests effectués. L'environnement de développement 3 est connecté par un point d'extension 15 à un module d'extension formant un analyseur statique 7. Cet 5 analyseur statique 7 comprend également des modules d'extension formant un module graphique 8 et un analyseur de test 9. L'analyseur de test 9 comporte une pluralité de modules d'extension formant des séquenceurs de test 10 qui eux-mêmes comportent des modules d'extension formant des modules de test 11 adaptés pour exécuter une 10 vérification de conformité d'un élément logiciel à une règle 12 ou à une métrique 13. Le module graphique 8 est adapté pour d'une part recevoir du clavier 4 des paramètres à appliquer dans l'exécution des tests et d'autre part recevoir des résultats de test fournis par l'analyseur de test 9. Des modules 15 d'extension spécialisés 16 permettent de définir et d'enregistrer les jeux de règles et de métriques définis par l'utilisateur ainsi que les préférences d'affichage des mesures en fonction du langage et/ou des règles considérées, chaque module d'extension spécialisé étant adapté pour traiter les spécificités de l'interface graphique en fonction du langage traité et/ou d'une règle ou d'une métrique donnée 20 et les retourner sous une forme homogène vers le module graphique 8 en vue de leur affichage sur l'écran 6. Chacun des modules d'extension est écrit en langage JAVA et comprend les classes JAVA permettant aux modules qui s'y rattachent d'hériter la majeure partie des classes et propriétés utiles à l'accomplissement de leur fonction. 25 En particulier les modules de test 11 sont créés à partir d'une écriture des règles 12 ou des métriques 13 en langage LEX qui permet de générer aisément des analyseurs lexicaux puis traduits en langage JAVA pour leur exécution. On se réfère maintenant aux figures 2 et 3 pour décrire le procédé de fonctionnement du dispositif 1. 3042291 11 Dans ces figures, on a représenté sur un axe vertical, de haut en bas, le déroulement temporel des différentes étapes du procédé et sur un axe horizontal, les échanges d'informations entre les différents modules. Ainsi, à la figure 2, le lancement du procédé de vérification 5 est effectué par l'utilisateur au moyen du clavier 4 ou d'un organe d'entrée de données équivalent tel qu'une souris à l'étape Si. Cet ordre est transmis à l'analyseur de test 9 via l'environnement de développement 3 et l'analyseur statique 7. À l'étape S2, l'analyseur de test 9 met en action le séquenceur de test 10 qui définit une liste de m modules de test 11 en fonction des paramètres de test définis par l'utilisateur 10 dans le module graphique 8 et du langage dans lequel sont écrits les éléments logiciels à tester et transmet, à l'étape S3 cette liste à l'analyseur de test 9. Dès lors, l'analyseur de test 9 actionne le lecteur 5 de manière à ce que celui-ci fournisse en entrée du premier module de test 111 un premier élément logiciel 141. A l'étape S4, le module de test 111 exécute la vérification de la règle ou de la métrique considérée 15 sur l'élément logiciel 141 puis l'analyseur de test 9 actionne le lecteur 5 pour que celui-ci fournisse l'élément logiciel suivant au module de test 111. Une fois tous les éléments logiciels 141 à 14' vérifiés pour la première règle ou métrique, le module de test 111 transmet à l'étape S5 les résultats du test de chaque élément logiciel 14 à l'analyseur de test 9. L'analyseur de test 9 met alors en action un second module de 20 test propre à vérifier une seconde règle ou métrique et actionne le lecteur 5 pour qu'il fournisse les éléments logiciels 14 au module de test 11. Ces opérations de test itératif de tous les éléments logiciels 14i se répètent jusqu'aux étapes S4m et S5m correspondant au module de test 11m exécutant la dernière des règles et/ou métriques considérées. 25 L'analyseur de test 9 retransmet tous les résultats de test à l'étape S6 en direction du module graphique 8 qui, le cas échéant, utilise des modules d'extension spécialisés 16 pour convertir certains résultats et retourne ces résultats à l'étape S7 à l'écran 6 pour affichage à destination de l'utilisateur. Bien entendu, ces résultats peuvent également être enregistrés pour référence ultérieure. 3042291 12 On se réfère maintenant à la figure 4 pour décrire le fonctionnement d'un exemple d'un module 11 de test de règle ou de métrique. L'exemple décrit s'applique à une règle simple, par exemple la vérification de la présence d'un mot interdit tel que "GOTO" ou "CONTINUE" qui sont susceptibles 5 de générer des sauts inconditionnels lors de l'exécution de l'élément logiciel. Le module de test utilisé dans l'exemple est adapté pour traiter des éléments logiciels écrits en langage FORTRAN. Lorsqu'à l'étape S4 l'analyseur de test 9 actionne le lecteur 5 pour qu'il fournisse le code source d'un élément logiciel à tester, ce code source est 10 transmis au module 11 sous la forme d'un fichier comportant plusieurs lignes de texte. Le module de test 11 comprend un automate permettant de lire chaque ligne de texte, de déterminer le type d'information qu'elle contient, par exemple commentaire, déclaration de variable ou instruction à exécuter, et d'effectuer un test prédéterminé en fonction du type d'information rencontré. 15 Le module de test 11 comprend une étape d'initialisation 5101 dans laquelle une première ligne de texte est lue et identifiée en tant que commentaire, déclaration de variable ou instruction. S'il s'agit d'une ligne vide, l'automate passe à l'étape 5102 qui déclenche la lecture d'une nouvelle ligne et son identification. Que ce soit à l'étape S101 ou S102, lorsque la ligne lue est une 20 déclaration de variable, l'automate passe à l'étape 5103 où, par exemple, un test est exécuté pour vérifier que le nom de la ou des variables ne comporte pas le mot interdit recherché. Si la ligne lue est une instruction, l'automate passe à l'étape 5104 où le contenu de l'instruction est testé de manière similaire. S'il s'agit d'un commentaire, l'automate passe à l'étape S105 dans laquelle le commentaire est 25 analysé pour vérifier la présence ou l'absence d'un mot recherché, par exemple dans le cas où la règle a pour objet la détection de mots interdits susceptibles de se trouver également dans les commentaires. À l'issue de chacune des étapes S103, S104 et S105, l'automate retourne à l'étape S102 pour lire une nouvelle ligne du fichier source de l'élément logiciel 14 en cours de traitement jusqu'à rencontrer un 30 code de fin de fichier. 3042291 13 À la fin du test de l'élément logiciel 14, des registres internes du module de test contiennent le résultat du test de l'élément logiciel considéré et sont à même de fournir ces résultats au séquenceur 10. Chaque module de test 11 exécute la vérification d'une et 5 unique règle ou métrique et est donc très simple à programmer. L'ajout d'une nouvelle règle ou métrique à la panoplie des règles ou métriques à tester est également simplifiée. Bien entendu, cette description est donnée à titre d'exemple illustratif uniquement et l'homme du métier pourra y apporter de nombreuses 10 modifications sans sortir de la portée de l'invention, comme par exemple choisir un environnement de développement distinct de l'environnement Eclipse et un langage de programmation différent de JAVA. De même, le procédé et/ou le dispositif décrit ci-dessus peuvent faire l'objet d'une adaptation en vue de leur utilisation dans des plateformes d'intégration continue ou de développement en continu de manière à 15 exécuter chaque test dès la fin de réalisation d'un élément logiciel. REVENDICATIONS1. Dispositif (1) de vérification d'éléments logiciels (14) à analyser, comprenant au moins un ordinateur (2) exécutant un logiciel principal, dit environnement de développement (3), des organes (4,5) d'entrée de données 5 comportant au moins un organe (5) adapté pour lire un code source de chaque élément logiciel et des moyens (6) de visualisation d'un résultat d'analyse, et au moins un logiciel d'analyse, dit analyseur statique (7), comprenant une liste de règles (12) de codage et de métriques (13) à respecter par l'élément logiciel à analyser, 10 caractérisé en ce que l'analyseur statique comprend deux modules d'extension : - un premier module, dit module graphique (8), adapté pour recevoir des paramètres de test et traiter et afficher des résultats de test sur les moyens (6) de visualisation, et - un second module, dit analyseur de test (9), adapté pour définir et exécuter 15 une structure de test sur au moins un élément logiciel et pour fournir des résultats de test audit module graphique, ledit analyseur de test comprenant au moins un séquenceur (10) de test adapté pour définir pour chaque élément logiciel au moins un module de test (11), chaque module de test vérifiant la conformité de l'élément logiciel avec une et unique règle ou une 20 et unique métrique. 2. Dispositif selon la revendication 1, caractérisé en ce que chaque séquenceur de test (10) est adapté au langage dans lequel l'élément logiciel (14) est écrit. 3. Dispositif selon l'une des revendications 1 ou 2, caractérisé 25 en ce que l'analyseur de test (9) est adapté pour appeler une pluralité de séquenceurs (10) de tests en fonction du langage dans lequel les éléments de logiciel sont écrits et d'une liste préétablie de règles et/ou de métriques à vérifier. 4. Dispositif selon l'une des revendications 1 à 3, caractérisé en ce que l'analyseur de test (9) est adapté pour déclencher une lecture du code 30 source d'au moins un élément logiciel (14), déterminer un séquenceur de test (10) 3042291 15 approprié à partir du langage dans lequel cet élément logiciel est écrit, extraire la liste des règles (12) et/ou métriques (13) adaptées audit langage et transmettre ledit élément logiciel au(x) module(s) de test (11) correspondants. 5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que chaque module de test (11) comporte un automate adapté pour exécuter un traitement d'une règle (12) unique ou d'une métrique (13) unique sur le code source d'un élément logiciel (14) et pour retourner une valeur représentative d'un résultat de la métrique considérée ou de conformité à la règle considérée. 6. Dispositif selon l'une des revendications 1 à 5, caractérisé 10 en ce que chaque module de test (11) retourne à l'analyseur de test (9) une liste des éléments logiciels (14) testés avec leur résultat pour la règle ou la métrique considérée. 7. Dispositif selon l'une des revendications 1 à 6, caractérisé en ce l'analyseur de test (9) transmet au module graphique (8) la liste des éléments 15 logiciels (14) testés avec leurs résultats pour toutes les règles et métriques vérifiées en vue de leur affichage sur les moyens (6) de visualisation. 8. Procédé, mis en oeuvre par ordinateur, de vérification d'éléments logiciels (14) à analyser, du type utilisant au moins un ordinateur (2) exécutant un logiciel principal, dit environnement de développement (3), des 20 organes (4,5) d'entrée de données comportant au moins un organe (5) adapté pour lire un code source de chaque élément logiciel et des moyens (6) de visualisation d'un résultat d'analyse, et au moins un logiciel d'analyse, dit analyseur statique (7), comprenant une liste de règles (12) de codage et de métriques (13) à respecter par l'élément logiciel à analyser, caractérisé en ce que, pour chaque élément logiciel à 25 analyser : - un second module, dit analyseur de test (9), définit et exécute une structure de test sur ledit élément logiciel, ledit analyseur de test comprenant un séquenceur (10) de test, - chaque séquenceur de test définit pour chaque élément logiciel au moins une 30 liste de modules de test (11), 3042291 16 - chaque module de test vérifie la conformité de l'élément logiciel avec une et unique règle ou une et unique métrique, - l'analyseur de test retourne des résultats de test à un premier module, dit module graphique (8), 5 - ledit module graphique affiche les résultats de test sur les moyens (6) de visualisation. 9. Procédé selon la revendication 8, caractérisé en ce que l'analyseur (9) de test exécute chaque règle (12), respectivement chaque métrique (13) séquentiellement sur tous les éléments logiciels (14). 10. Procédé selon la revendication 8, caractérisé en ce que l'analyseur (9) de test exécute séquentiellement toutes les règles (12), respectivement toutes les métriques (13), sur chaque élément logiciel (14). 11. Programme d'ordinateur comprenant des moyens pour l'exécution des étapes du procédé selon l'une quelconque des revendications 8 à 10 15 lorsque ledit programme est exécuté sur ordinateur pour l'analyse statique du code source d'éléments logiciels (14) caractérisé en ce qu'il comprend : - un premier module, dit module graphique (8), adapté pour recevoir des paramètres de test et traiter et afficher des résultats de test sur des moyens (6) de visualisation, et 20 - un second module, dit analyseur de test (9), adapté pour définir et exécuter une structure de test sur au moins un élément logiciel et pour fournir des résultats de test audit module graphique, ledit analyseur de test comprenant au moins un séquenceur (10) de test adapté pour définir pour chaque élément logiciel au moins un module de test (11), chaque module de test vérifiant la conformité de 25 l'élément logiciel avec une et unique règle ou une et unique métrique.