2. Vérification formelle du modèle. Les propriétés formelles issues des exigences sont vérifiées sur le modèle grâce au model-checking. Cette phase permet alors de détecter des deadlocks ou des erreurs de conception plus subtiles.
3. Déploiement du modèle sur la plateforme d’exécution réelle. Le modèle est déployé sur la plateforme d’exécution réelle du système (p. ex. une cible embarquée). On parle alors d’exécution réelle lorsque le système s’exécute afin de satisfaire le besoin pour lequel il a été conçu.
4. Monitoring du système à l’exécution. Il est possible de continuer la vérification des propriétés formelles à l’exécution en utilisant des moniteurs pour surveiller la trace d’exé-cution courante.
Ce cycle de développement est itératif. À chaque fois qu’une erreur de conception ou qu’un bogue logiciel est détecté, l’utilisateur doit mettre à jour le modèle de conception en proposant une correction. La modélisation du système bénéficie ainsi du retour des activités d’analyse pour pouvoir être améliorée d’itération en itération.
Grâce à ce cycle de développement, on constate que l’approche recherchée doit satisfaire trois besoins : (1) la possibilité d’exécuter un modèle conforme à n’importe quel langage, (2) le fait de pouvoir analyser l’exécution d’un modèle avec différents outils et différentes techniques d’analyse dynamiques (p. ex. simulation, débogage, model-checking) et (3) la possibilité de déployer un modèle sur une plateforme d’exécution réelle.
3.3 Problèmes pour l’analyse et l’exécution réelle
Dans la littérature, plusieurs approches permettent de répondre à ces différents besoins en combinant les techniques d’exécution et les techniques d’analyse de modèles. Ces approches reposent en général sur des transformations non prouvées qui sont à l’origine de plusieurs problèmes : des fossés sémantiques et un problème d’équivalence. Pour comprendre pourquoi ces problèmes se manifestent, cette section les présente plus en détail.
3.3.1 Fossés sémantiques
Un fossé sémantique apparaît lorsqu’un même modèle est exprimé dans deux langages dif-férents. L’utilisation de transformations exogènes (c.-à-d. des transformations pour lesquelles le langage source est différent du langage cible) est typiquement à l’origine de fossés séman-tiques. En effet, l’outil servant à la transformation capture (tout ou partie de) la sémantique du langage source pour exprimer les éléments du modèle source en termes des concepts du lan-gage cible. Ces transformations (p. ex. transformations de modèles, génération de code) sont souvent vues comme bénéfiques car elles permettent d’utiliser les outils d’analyse du langage
cible pour vérifier des modèles sources. Néanmoins, l’apparition d’un fossé sémantique rend l’établissement de liens entre les concepts du modèle source et ceux du modèle cible plus complexe. L’utilisation de transformations crée un risque d’erreur supplémentaire puisque sans preuve formelle, rien ne garantit que la correspondance entre les éléments sources et les élé-ments cibles est correcte. Dans certains cas, le fossé sémantique impacte également les outils d’analyse en les séparant en deux groupes : ceux s’appliquant au niveau du modèle et ceux s’appliquant au niveau du code exécutable. Ce problème de fossé sémantique est mentionné dans plusieurs travaux de la littérature [DT16 ; RDH03] et cité dans [Dub+13] comme l’un des challenges scientifiques clés pour la vérification et la validation des modèles.
Pour éviter les problèmes causés par les fossés sémantiques, une solution est de prou-ver formellement chacune des transformations utilisées mais cette tâche reste complexe. De nouvelles preuves doivent être établies pour chaque langage de modélisation pour lequel on souhaite analyser ou exécuter des modèles. Il est également possible d’utiliser des liens de traçabilité mais ceux-ci ne peuvent se substituer à des preuves formelles. Une autre solution est tout simplement d’éviter l’utilisation des transformations afin de conserver les concepts du langage de modélisation pour l’analyse et l’exécution.
3.3.2 Problème d’équivalence
Le problème d’équivalence se manifeste dès que le modèle d’analyse servant à la mise en œuvre des activités de V&V est différent du modèle exécutable (c.-à-d. du code exécutable déployé sur le système réel) et qu’aucune relation d’équivalence entre les deux n’a été établie et prouvée. Dès qu’une transformation non prouvée est utilisée, un problème d’équivalence ap-paraît en plus d’un fossé sémantique. Dans ce cas, il suffit de prouver la transformation pour ré-soudre le problème. En revanche, si le flot de développement se sépare en plusieurs branches, le problème d’équivalence devient plus complexe à résoudre. Par exemple, si deux transfor-mations sont appliquées à partir du modèle de conception pour obtenir à la fois des modèles d’analyse et le code exécutable du système, prouver indépendamment ces deux transforma-tions n’est plus suffisant. Il faut construire une preuve d’équivalence (cf. section 2.3.2). Cette preuve (ou relation) d’équivalence peut être construite entre différents artefacts :
1. Entre les modèles d’analyse et le code exécutable ;
2. Entre les différents outils qui capturent la sémantique du langage de conception (c.-à-d. entre l’outil de transformation de modèles qui permet d’obtenir un modèle d’analyse et l’outil de génération de code) ;
3. Entre la plateforme d’exécution réelle et la plateforme d’exécution utilisée pour les acti-vités d’analyse de modèles.
3.3. Problèmes pour l’analyse et l’exécution réelle
Dans le premier cas, il faut prouver que les modèles sont équivalents (à la fois d’un point de vue structurel et comportemental). Dans le second cas, la preuve doit garantir que les différents outils de transformation capturent exactement la même définition de la sémantique du langage de conception. Enfin, dans le dernier cas, il faut prouver que la plateforme d’exécution dédiée à l’analyse du modèle se comporte comme la plateforme réelle pour l’utilisation qui en est faite. Par ailleurs, le problème d’équivalence peut se manifester par des différences à plusieurs niveaux :
Au niveau de l’interprétation de la sémantique : Un même concept peut être interprété différemment par des outils différents. Ce problème peut se produire lorsqu’un concept a une signification complexe ou lorsque la description de sa sémantique est ambiguë. Par consé-quent, ce concept devient la source d’interprétations potentiellement erronées menant ainsi à des exécutions discordantes entre les différents outils (p. ex. pour Business Process Model And Notation (BPMN™) en [BGT20] ou pour UML-RT en [PD16]). Ceci est d’autant plus vrai pour les langages non formels ou semi-formels pour lesquels il existe souvent des points de variation sémantique.
Au niveau du sous-ensemble capturé : Des traces d’exécution différentes peuvent être obtenues si tous les outils ne capturent pas le même sous-ensemble du langage de conception. Par exemple, si le modèle de conception possède un concept qui est inclus dans le sous-ensemble capturé par l’outil d’analyse mais pas dans celui capturé par le générateur de code, alors le comportement du système obtenu via le code exécutable sera potentiellement différent de celui analysé durant la phase de V&V.
Au niveau du chargement du modèle : Chaque outil doit charger le modèle de conception en mémoire avant de pouvoir le transformer ou le manipuler. Le chargement du modèle peut être vu comme une transformation (texte vers représentation binaire) qui ne garantit pas que le modèle chargé en mémoire est fidèle au modèle de conception. Les multiples implémenta-tions des mécanismes de chargement de modèles sont donc une source supplémentaire de dissemblances entre les différents outils (p. ex. débogueurs, model-checkers).
Au niveau de la considération de la plateforme d’exécution : Les plateformes d’exécu-tion utilisées lors des phases d’analyse considèrent parfois certaines abstracd’exécu-tions (p. ex. sur le modèle de concurrence, la communication interprocessus, l’ordonnancement) [Bar+17]. Chan-ger la politique d’ordonnancement peut par exemple chanChan-ger complètement le comportement du système et l’ordre dans lequel les tâches sont exécutées.
Toutes ces différences peuvent potentiellement impacter le comportement du système lors des phases d’analyse et d’exécution. Une relation d’équivalence doit donc être établie et prou-vée afin de garantir que ce qui est exécuté est conforme à ce qui a été vérifié. Cependant, cette relation d’équivalence reste complexe à élaborer dans le cas général d’un langage quelconque. Pour résoudre le problème d’équivalence, plusieurs solutions peuvent être envisagées. La
première consiste à établir et à prouver formellement la relation d’équivalence en utilisant par exemple du theorem proving ou des preuves de bisimulation [Fer90 ; Com+09]. Ce type de preuve reste cependant complexe à mettre en œuvre pour un langage de modélisation quel-conque. Une autre solution consiste à utiliser un générateur de code certifié (p. ex. KCG pour SCADE [Ber07]) à partir du modèle d’analyse. Avec cette méthode, l’équivalence n’est prouvée qu’avec le modèle d’analyse ayant servi de référence pour la génération de code. Cependant, plusieurs modèles d’analyse utilisant des formalismes différents sont souvent nécessaires pour appliquer divers outils de V&V. Une autre alternative est de garantir l’équivalence à l’exécution par exemple en utilisant des moniteurs. Cette solution ne permet pas pour autant de se sub-stituer à une preuve formelle. Elle ne peut servir qu’à augmenter la confiance des ingénieurs dans le système.
Les sections qui suivent vont maintenant présenter six approches permettant d’exécuter, d’analyser et de déployer des modèles sur une plateforme d’exécution. L’ordre dans lequel les approches sont présentées n’est pas significatif mais seulement didactique.