Une ontologie pour les techniques de V&V

La correction d’un système vis-à-vis du comportement désiré est vérifiée avec une certaine méthode de V&V, qui détermine si le modèle considéré du système satisfait une formule décrivant ce comportement appelée Property. La plus grande partie de ce travail est la classification des techniques deV&V.

L'ontologie de V&V (VVO)

Figure 1.11 — Une partie de la hiérarchie des techniques de V&V

Le concept V&V Une grande variété de stratégies et techniques deV&Vsont disponibles. Une technique deV&Vpeut être appliquée sur une ou plusieurs abstractions d’un système selon le formalisme utilisé pour la description du système et la propriété qui doit être véri- fiée.

Par technique de vérification, nous entendons une technique permettant de déterminer si un système satisfait certaines exigences explicites (spécification de systèmes) et donc que le système est conforme à sa spécification. Par technique de validation, nous entendons une technique qui permet d’assurer que le modèle est correct par rapport aux besoins implicites de l’utilisateur futur du système et donc que le système est conforme aux besoins de l’uti- lisateur (c’est exactement ce que voulait exprimer l’utilisateur). L’objectif est d’augmenter la confiance que nous avons sur le système développé. Cela peut être fait avec différentes approches.

La figure 1.11 montre une petite partie de la hiérarchie proposée dans la VVO pour les techniques de V&V. Cette hiérarchie est organisée sur plusieurs niveaux. Le concept Analysispar exemple possède 60 sous-catégories.

Les techniques deV&V illustrées sur la Figure1.11 sont utilisées pour laV&V maté- rielle et logicielle. Baier, C. et al. dans [BK+08] montrent que le PeerReview et Testing sont les techniques de vérification logicielle les plus utilisées en pratique. Le PeerReview est de préférence effectué par une équipe d’ingénieurs qui n’étaient pas impliqués dans le développement du logiciel. Selon cette technique, le code source n’est pas exécuté mais examiné statiquement. Les études montrent que cette technique est efficace et permet de dé-

1.3. L'implémentation de la VVO

Figure 1.12 — La définition du PeerReview

Figure 1.13 — La définition du Testing

tecter entre 31% et 93% des défauts. PeerReview est définie dans [GRL07] et dans laVVO

comme illustré sur la figure1.12.

Le test logiciel constitue aussi une partie significative de n’importe quel projet. Entre 30% et 50% du coût du projet lui est consacré [BK+_{08]. Contrairement au PeerReview qui} permet d’analyser le code sans l’exécuter, le test est une technique dynamique qui exécute le code.

Le test permet pour le code compilé d’une partie du logiciel avec des paramètres appe- lées jeux de tests de déterminer la correction de l’ensemble de chemins d’exécution traversés. En se basant sur l’observation durant l’exécution, les résultats du logiciel sont comparées aux résultats attendus selon la spécification

L’avantage principal du test est qu’il peut être appliqué à tous les types de logiciels ou de systèmes (des applications, des compilateurs ou des systèmes d’exploitation).

Éviter les erreurs dans la conception matériel est vital. Le matériel a généralement un coût de fabrication important ; corriger les défauts puis transmettre une mise à jour aux uti- lisateurs est difficile au contraire des erreurs logiciels. Corriger les erreurs matérielles après la livraison nécessite souvent la refabrication et le redistribution, ce qui a des conséquences économiques énormes. Par exemple le remplacement du processeur Pentium II a coûté à Intel environ 475 millions $. Des études ont montré que plus de 50% de tous les ASICs (Application-Specific Integrated Circuits) ne fonctionnent pas correctement après le design initial et la fabrication. Ce n’est pas étonnant que les constructeurs invertissent beaucoup de leur temps pour assurer que leur design est correct. La conception dans un matériel typique prend environ 27% du temps total ; le reste du temps est consacré à la détection des erreurs. L’émulation (Figure1.14), la simulation et l’analyse structurelle sont les techniques ma- joritairement utilisées dans la vérification matérielle. L’analyse englobe aussi plusieurs tech-

L'ontologie de V&V (VVO)

Figure 1.14 — La définition de Emulation

Figure 1.15 — La définition de Simulation

niques spécifiques comme la synthèse, l’analyse temporelle et le test d’équivalence. L’ému- lation est un type de test ; dans cette technique un système matériel reconfigurable est pa- ramétré pour se comporter comme le circuit considéré. Comme le test logiciel, l’émulation exploite un ensemble de stimuli du circuit et compare les sorties générées avec celle prévues dans la spécification. Pour tester intégralement le circuit, toutes les combinaisons d’entrés possibles dans chaque système doivent être examinées. Ceci n’est pas pratique et le nombre de tests doit être réduit d’une manière significative, ce qui peut mener à des erreurs non découvertes.

Avec la simulation (Figure1.15), un modèle est décrit typiquement avec un langage de description de matériel comme Verilog [TM02] ou VHDL [Ash08] qui sont standardisés par l’IEEE ; en se basant sur des stimuli, les chemins d’exécution sont examinés en utilisant le simulateur. Les stimuli peuvent être données par un utilisateur ou automatiquement par un générateur. Une non-correspondance entre la sortie des simulateurs et la sortie décrite dans la spécification détermine la présence des erreurs [BK+08].

Le concept Requirement La correction d’un système par rapport à un comportement spécifique est contrôlée en vérifiant que le modèle satisfait une formule décrivant le com- portement désiré appelé Property. Pour décrire une propriété, nous pouvons utiliser plu- sieurs langages de description de propriétés (PDL). A titre d’exemple, la figure1.16présente une partie de la hiérarchie des logiques temporelles [Pri03] que nous utilisons dans le cas d’étude dans la Section1.4.

Nous pouvons distinguer plusieurs logiques temporelles, la logique temporelle linéaire (LTL) [Pnu77], "Computational Tree Logic" (CTL) [EH86] [CE08] et "State Event-LTL" (SE- LTL) [CCO+04] sont des sous-classes de la logique temporelle présentée sur la Figure1.16.