Approches d’analyse par API

Pour analyser et vérifier des modèles conformes à un langage, une autre démarche pos-sible est d’utiliser une API pour connecter un outil d’analyse générique à un moteur d’exécution du modèle. L’outil d’analyse peut ainsi contrôler et analyser l’exécution du modèle à travers les différentes requêtes de l’API.

2.5.4.1 Description

Le schéma conceptuel de cette approche est illustré sur la Figure 2.6. Un Modèle du sys-tème à concevoir, conforme au Langage de modélisation, est exécuté par un Moteur d’exé-cution. Ce moteur permet d’exécuter des modèles conformes à LM. Pour vérifier que le mo-dèle satisfait ses exigences, des Outils d’analyse génériques peuvent se connecter au Moteur d’exécution via un lien de communication (lien de com). Ces outils d’analyse peuvent ainsi contrôler, observer et analyser l’exécution du modèle via une API ou un protocole de commu-nication. Cette interface de communication doit être la moins contraignante possible pour le moteur d’exécution tout en offrant suffisamment de services aux outils d’analyse. Cette tech-nique offre l’avantage de réutiliser le moteur d’exécution de LM et de découpler les algorithmes de vérification des préoccupations spécifiques au langage de modélisation. Elle facilite ainsi l’interopérabilité entre les outils et la réutilisation des algorithmes de vérification.

2.5.4.2 Outils et protocoles

L’émergence de cette technique a notamment été facilitée par la création de nouveaux protocoles de communication et d’outils d’analyse modulaires.

Protocoles de Communication. Des protocoles ont été créés afin de faciliter la manipulation des langages et les interactions avec leurs outils de développement. On trouve notamment le Langage Server Protocol (LSP)¹⁵ qui permet d’interfacer un EDI avec un serveur de langages regroupant les différents services propres à un langage (p. ex. l’autocomplétion, l’accès à la do-cumentation). Un même serveur de langages peut ainsi être utilisé par différents éditeurs. Une extension de ce protocole est notamment utilisée par Gemoc Studio [Bou+16] pour connecter des addons (p. ex. des débogueurs) à différents moteurs d’exécution.

De façon similaire à LSP, le Debug Adapter Protocol (DAP)¹⁶ permet de connecter des débogueurs à des outils de développement afin de fournir les fonctionnalités usuelles au débo-gage (p. ex. l’ajout de points d’arrêt). Il vise ainsi à uniformiser les APIs de débodébo-gage propres à chaque EDI (p. ex. Eclipse, IntelliJ IDEA).

Le standard Functional Mockup Interface (FMI)¹⁷ définit quant à lui un protocole permet-tant à la fois de faire communiquer et de co-simuler des modèles de natures différentes (p. ex. informatique, électronique, mécanique, thermodynamique).

Model-checking. Concernant le model-checking, aucun protocole dédié n’a encore été stan-dardisé au même titre que le DAP pour le débogage. Le LSP paraît néanmoins déjà pouvoir être adapté à cet usage même s’il ne semble pas encore être utilisé dans ce but. Plusieurs model-checkers modulaires ont tout de même été développés en incluant la possibilité d’inter-agir avec des moteurs d’exécution externes. Cette approche offre ainsi l’avantage de pouvoir appliquer un même model-checker sur des modèles conformes à des langages différents.

En termes d’API, l’exploration de l’espace d’état d’un modèle nécessite trois requêtes : (i) une pour récupérer la configuration (c.-à-d. les données d’exécution) initiale du modèle, (ii) une pour récupérer la liste des transitions tirables à partir d’une configuration donnée et (iii) une pour tirer une transition (c.-à-d. pour exécuter un pas d’exécution). Cette API est exactement celle qui est implémentée par les model-checkers LTSmin [Kan+15] et OBP218. Les outils DI-VINE [Bar+17] et SPOT [DP04] implémentent quant à eux une variante de cette interface avec seulement deux requêtes : une pour récupérer la configuration initiale et une pour récupérer la liste des successeurs immédiats d’une configuration donnée. Les requêtes (ii) et (iii) sont donc

15. Language Server Protocol : https://microsoft.github.io/language-server-protocol/. 16. Debug Adapter Protocol : https://microsoft.github.io/debug-adapter-protocol/. 17. Functional Mock-up Interface : https://fmi-standard.org/.

2.6. Synthèse

regroupées en une seule, ce qui a pour effet de masquer les pas d’exécution.

Pour évaluer des propriétés formelles, il est également nécessaire d’évaluer des proposi-tions atomiques (aussi appelées atomes). Si un consensus semble avoir été trouvé sur l’API d’exploration de l’espace d’état, l’évaluation des propositions atomiques est toujours faite de façon ad-hoc sur chaque outil. Sur LTSmin, DIVINE et SPOT, les atomes sont évalués direc-tement par le model-checker sur l’ensemble des configurations explorées. Dans ce cas, le model-checker et le moteur d’exécution doivent utiliser une structuration unifiée des données pour la configuration. Par exemple pour LTSmin, la configuration est composée de vecteurs d’entiers de taille fixe permettant ainsi au model-checker de lire et d’interpréter les données. Pour éviter de contraindre la structure de la configuration, OBP2 utilise une requête de com-munication dédiée permettant de déléguer l’évaluation des propositions atomiques au moteur d’exécution.

2.6 Synthèse

Dans ce chapitre, nous avons étudié quatre types d’approches permettant l’analyse de modèles conformes à un langage donné : (1) les approches par raffinement, (2) les approches avec une transformation vers un langage d’analyse, (3) les approches d’analyse dédiées au langage et (4) les approches d’analyse par API.

Le Tableau 2.1 synthétise les avantages et inconvénients de chaque approche selon les dif-férents critères de comparaison : (LM == LA) indiquant si le formalisme d’analyse est identique au formalisme de modélisation, (Résultats) indiquant si les résultats d’analyse sont facilement compréhensibles, et (Réutilisabilité outils) indiquant si les outils d’analyse sont applicables à d’autres langages.

Types d’approches LM == LA Résultats¹⁹ Réutilisabilité outils

Par raffinement oui + non

sans traçabilité

-Avec transformation

vers LA avec traçabilité ^non + ^oui

ad-hoc non

Dédiée au langage

systématique ^{oui +} oui (méta-outils)

Par API oui + oui

TABLE2.1 – Synthèse des approches d’analyse de modèles.

On peut remarquer que les approches avec une transformation vers un langage d’analyse sont les seules pour lesquelles les outils d’analyse ne sont pas appliqués directement sur le

modèle de conception mais sur une traduction de ce modèle dans un autre langage. L’uti-lisation d’une transformation crée un fossé sémantique entre le modèle de conception et le modèle d’analyse. En conséquence, les résultats d’analyse ne sont plus exprimés en termes des concepts de LM. L’ajout de liens de traçabilité permet néanmoins de résoudre ce problème sans pour autant résoudre le fossé sémantique.

Les approches par raffinement et les approches dédiées ad-hoc ne permettent pas de réutiliser les outils d’analyse pour d’autres langages que celui pour lequel ils ont été conçus. Les approches dédiées systématiques et les approches d’analyse par API semblent donc les plus pertinentes car leurs outils sont applicables directement sur le modèle de conception tout en restant réutilisables pour d’autres langages.

CHAPITRE3

A

PPROCHES POUR L

’

EXÉCUTION ET

L

’

ANALYSE DE MODÈLES

Sommaire

3.1 Introduction . . . . 53 3.2 Contexte de développement . . . . 54 3.3 Problèmes pour l’analyse et l’exécution réelle . . . . 55 3.3.1 Fossés sémantiques . . . . 55 3.3.2 Problème d’équivalence . . . . 56 3.4 Approche 1 : traduction vers modèle vérifiable et code . . . . 58 3.5 Approche 2 : traduction vers modèle vérifiable puis code . . . . 59 3.6 Approche 3 : traduction vers code vérifiable . . . . 60 3.7 Approche 4 : traduction modèle vérifiable vers code . . . . 61 3.8 Approche 5 : raffinement de modèles jusqu’au code . . . . 62 3.9 Approche 6 : interprétations spécifiques pour vérification et exécution

réelle . . . . 63 3.10 Analyse des six approches . . . . 64 3.11 Approche X : interprétation unifiée pour vérification et exécution réelle . 65 3.12 Objectifs de recherche . . . . 67 3.13 Synthèse . . . . 68

3.1 Introduction

Le chapitre 1 a présenté les deux principales techniques permettant d’exécuter des mo-dèles : l’interprétation et la génération de code. Le chapitre 2 a décrit les différentes méthodes permettant d’appliquer des outils de V&V dynamiques sur ces modèles. Ce chapitre présente maintenant les différentes approches permettant de combiner ces différentes techniques d’exé-cution et d’analyse. En ce qui concerne l’exéd’exé-cution, il faut distinguer l’exéd’exé-cution du modèle pour la mise en œuvre des techniques d’analyse et l’exécution au sens déploiement du modèle sur la plateforme d’exécution réelle. Ce sont ces deux aspects que l’on considère ici. Ce chapitre

distingue six approches permettant à la fois d’appliquer des techniques de V&V sur des mo-dèles et de déployer ces momo-dèles sur une plateforme d’exécution.

Le Tableau 3.1 expose une classification de ces six approches (A#1 à A#6) en fonction des techniques d’analyse de modèles et des techniques d’exécution réelle. Il permet de positionner ces approches les unes par rapport aux autres mais offre également une vue d’ensemble des méthodes actuellement utilisées dans la littérature pour aborder ce sujet. Il positionne également l’approche A#X utilisée dans cette thèse pour concevoir l’approche EMI.

Exécution

Analyse

Raffinement Transformation Dédiée API

AC#1 AC#3

Compilation AC#5

AC#2 AC#4 ^AC#4

Interprétation - - AC#6 AC#X

TABLE 3.1 – Positionnement des approches par rapport aux techniques d’analyse et d’exécu-tion de modèles.

La section 3.2 présente le contexte de développement considéré dans cette thèse. La sec-tion 3.3 s’intéresse aux fossés sémantiques et au problème d’équivalence communément ren-contrés dans la littérature. Les sections 3.4 à 3.9 décrivent chacune des six approches d’ana-lyse et d’exécution de modèles. La section 3.10 identifie les trois problèmes majeurs auxquels elles sont confrontées puis la section 3.11 propose une nouvelle architecture permettant d’évi-ter ces problèmes. Pour mettre en œuvre cette architecture, des objectifs de recherche ont été identifiés en section 3.12. Enfin, la section 3.13 présente une synthèse de cet état de l’art.