Approches avec une transformation vers un langage d’analyse

Pour assurer qu’un modèle de conception satisfait ses exigences, une autre stratégie con-siste à transformer ce modèle dans un langage cible afin de pouvoir réutiliser tous les outils d’analyse disponibles dans l’espace technique cible.

2.5.2.1 Description

Le principe général de cette approche est illustré sur la Figure 2.4. Un Modèle LM décrivant le système à concevoir est conçu avec le Langage de modélisation. Cependant, l’Espace tech-nique de LM ne possède pas d’outils d’analyse permettant l’analyse des modèles décrits dans LM. Pour résoudre ce problème, un Traducteur capture la sémantique de LM afin de traduire le Modèle LM dans un autre langage que l’on qualifiera de Langage d’analyse noté LA. Cette transformation permet ainsi d’obtenir le Modèle LA, c.-à-d. une représentation du modèle de conception dans les termes de LA. L’Espace technique de LA possède divers Outils d’analyse implémentant la sémantique de LA et pouvant s’appliquer aux modèles décrits dans LA. L’uti-lisation d’une transformation permet ainsi de réutiliser les outils d’analyse existants sans avoir à repayer le coût de leurs développements pour LM. De plus, un changement de la syntaxe abstraite ou de la sémantique de LM nécessite seulement de mettre à jour la transformation sans avoir besoin de changer les outils d’analyse de LA. La transformation permet ainsi de faire le pont entre le langage de modélisation LM et un langage d’analyse LA.

2.5. Approches pour l’analyse et la vérification logicielle

Même si cette technique offre de nombreux avantages, l’utilisation d’une transformation de modèles fait apparaître un fossé sémantique entre le modèle de conception et le modèle d’analyse. Ce fossé sémantique complexifie notamment la compréhension des résultats d’ana-lyse d’un point de vue de LM. En effet, les langages LM et LA reposent généralement sur des concepts différents rendant ainsi difficile d’établir une correspondance entre les concepts de ces deux langages.

Pour résoudre ce problème, plusieurs techniques peuvent être utilisées. Le round-trip engi-neering [Cic14] consiste à annoter le modèle de conception avec des back-annotations [Heg+10] permettant ainsi de traduire les résultats d’analyse en termes des concepts de LM. Une autre méthode est de construire des liens de traçabilité [Jou05 ; Bou15] lors de la transformation du modèle de conception vers le modèle d’analyse. Ces liens de traçabilité peuvent ensuite être utilisés a posteriori pour exprimer les résultats d’analyse avec les concepts de LM. Ces techniques permettent ainsi de résoudre un des problèmes majeurs causés par le fossé sé-mantique.

L’un des points clés de cette approche par transformation vers un langage d’analyse ré-side dans le choix de LA. Les critères de choix dépendent notamment de la variété des outils disponibles dans le langage cible et de la facilité à implémenter la transformation de LM vers LA.

2.5.2.2 Langages et outils

Pour des raisons historiques, cette approche par traduction est typiquement employée pour transformer des modèles vers des langages formels et ainsi appliquer des algorithmes de model-checking. Il existe en effet un certain nombre de model-checkers dont le formalisme d’entrée est un langage formel conçu uniquement dans l’objectif de pouvoir modéliser et vé-rifier formellement des systèmes logiciels. En général, ces outils ne peuvent s’appliquer qu’à des modèles spécifiés dans un seul et unique langage d’entrée. Ce langage est alors qualifié de langage pivot car des modèles écrits dans divers langages peuvent être transformés vers ce langage unique afin d’appliquer des outils d’analyse.

Model-checking. Parmi ces outils, le model-checker Spin¹² [Hol97] est utilisé pour véri-fier des applications logicielles concurrentes spécifiées dans le langage Promela. Cet outil a notamment été utilisé pour vérifier des systèmes industriels dont des algorithmes pour des missions sur Mars et certains protocoles de transmission de données dans le domaine mé-dical. De manière similaire, le model-checker OBP1 [Dha+12 ; Teo+16 ; TDL17] a été déve-loppé à l’ENSTA Bretagne pour permettre la vérification de modèles conformes au langage

Fiacre [Ber+08]. Ce langage a initialement été développé pour l’atelier Toolkit in Open Source for Critical Applications & Systems Development (TOPCASED) [Far+06] comme un langage pivot entre différents langages de modélisation (p. ex. UML, Specification and Description Language (SDL), Architecture Analysis and Design Language (AADL)) et les langages for-mels des model-checkers. D’autres model-checkers ont aussi été développés avec un lan-gage d’entrée spécifique dont CADP [Gar+13] pour la vérification de programmes écrits en LOTOS, Tina-selt [BV06] et Romeo [Lim+09 ; Gar+05] pour les modèles de Petri-Nets tempori-sés, Mocha [Alu+98] et PRISM [KNP09] pour les modèles utilisant des variantes des modules réactifs, TLC [YML99] pour les modèles en TLA+ ou encore ProB [LB08] pour des modèles écrits en B. D’autres outils ont également leur propre langage d’entrée comme SMV [McM92], NuSMV [Cim+02], NuXmv [Cav+14], Maude [Cla+03] ou Uppaal [LPY97]. FDR [FW99] permet quant à lui de vérifier les raffinements des modèles de l’algèbre des processus Communicating Sequential Processes (CSP). Alcoa [JSS00] réalise des analyses sur des modèles Alloy en se basant sur des solveurs de contraintes. Enfin, Bogor [RDH03] est un model-checker mo-dulaire ayant un langage d’entrée spécifique mais extensible pour s’adapter aux constructions des Domain Specific Languages (DSLs).

Outils de transformation. Pour traduire les modèles dans des langages formels, il est pos-sible d’utiliser les outils génériques de transformation de modèles (cf. section A.2.1.3) comme ATLAS Transformation Language (ATL) [JK06], Query/View/Transformation (QVT^™) [OMG16] ou Epsilon Transformation Language (ETL) [KPP08]. D’autres outils permettent d’automatiser la phase de transformation mais ils sont spécifiques à un seul formalisme d’entrée. Ces ou-tils intègrent généralement le model-checker directement comme back-end afin de proposer un environnement complet de vérification pour un langage donné. Parmi ces outils, on trouve notamment les outils Hugo/RT [KMR02 ; KW06] et vUML [LP99] qui permettent d’appliquer le model-checker Spin en transformant les modèles UML vers Promela (description plus détaillée en section A.3.4). On peut également citer Java PathFinder v1 [HP00] et Bandera [Cor+00] pour la vérification de programmes Java avec Spin, Cadena [Hat+03] pour la vérification de modèles Corba avec Spin ou Mbeddr [Voe+12] pour la vérification de programmes C avec NuSMV.

Certains de ces outils implémentent également une transformation des résultats d’analyse en termes des concepts du langage d’entrée. C’est par exemple le cas des outils Hugo/RT et vUML qui fournissent une représentation des résultats en UML notamment sous forme de dia-grammes de séquence. En dehors du model-checking, d’autres travaux offrent des exemples d’application du round-trip engineering pour monitorer des propriétés non-fonctionnelles en [Cic14], ou de l’utilisation des liens de traçabilité pour analyser des traces [Sad+19 ; CGR11] ou faire du débogage [BMW17 ; BW19].

2.5. Approches pour l’analyse et la vérification logicielle