La problématique du test de transformations de modèles est vaste et comporte encore de nombreux problèmes à résoudre. Nos travaux ouvrent certaines perspectives pour traiter certains de ces problèmes.
La principale activité du test que nous n’avons pas traitée est la localisation d’erreur. Il s’agit de la phase du processus qui suit l’application de l’oracle et la production du verdict. L’évolution logique à nos travaux consiste à perfectionner les fonctions d’oracles proposées. Il est possible d’envisager que l’oracle ne renvoie pas uniquement le verdict mais qu’il soit capable de fournir des informations sur la défaillance. En décrivant précisément la nature de la défaillance et les éléments incorrects du modèle de sortie, la localisation de l’erreur serait facilitée. Les techniques de traçabilité [Glitia'08, Bondé'05, Amar'08] apportent un gain puisqu’elles permettent de maintenir un lien entre les éléments du modèle d’entrée et le modèle
réalisées par la transformation sur les modèles. La localisation de l’erreur pourrait être faite en déterminant quelles opérations de la transformation ont :
modifié les éléments erronés du modèle de sortie,
consulté les éléments du modèles d’entrée correspondant aux éléments erronés du modèle de sortie (cette correspondance étant déjà fournie par les outils existants comme ETraceTool1).
L’exploitation des travaux de traçabilité pour le test de transformations de modèles est une première perspective qui nous intéresse.
Nous pouvons également envisager de spécialiser les techniques de test développées au test de transformations particulières. En particulier, les transformations iso-fonctionnelles introduisent une problématique intéressante. Les transformations de modèles ont parfois une propriété : l’entrée et la sortie sont sémantiquement équivalentes, les modèles d’entrée et de sortie ont le même sens et le même but.Dans ce cas, elles sont iso-fonctionnelles. Les oracles pour tester ces transformations sont complexes. Ils doivent vérifier principalement deux choses :
que le traitement que souhaite réaliser la transformation a été correctement effectué, que la transformation n’a pas affecté la sémantique du modèle.
Nous avons expérimenté l’utilisation de l’oracle pour le test d’une de ces transformations. Elle « aplatit » un diagramme d’état composite. Un exemple est donné dans la figure 2-5, avec à gauche un diagramme d’état avec un état composite, et à droite une version aplatie de ce diagramme. Pour vérifier que le diagramme d’état produit n’a plus d’état composite, nous pouvons utiliser un oracle avec un contrat générique. Il est possible de vérifier que deux diagrammes correspondent mais il est plus difficile de vérifier qu’ils ne correspondent pas.
La première raison est la définition même de l’équivalence fonctionnelle de modèles en particulier parce que les spécifications sont rarement formelles. La spécification de la sémantique des diagrammes d’états d’UML par exemple laisse trop de liberté. La seconde raison est que cette transformation n’est pas déterministe et que parfois, de nombreux diagrammes d’état aplatis peuvent être générés. En effet la question de l’iso-fonctionnalité entre deux modèles est posée parce que le lien entre les modèles d’entrée et de sortie n’est pas direct et que plusieurs modèles peuvent potentiellement avoir la même sémantique. Dans notre exemple (de la figure 2-5), il est par exemple possible de produire un autre modèle de sortie qui comprend deux états finaux (un pour l’état 3 et l’autre pour l’état 4). Les model snippets permettent de définir des alternatives et de proposer plusieurs solutions simultanées pour l’oracle. Mais dans les cas où les possibilités sont trop nombreuses, toutes nos approches sont limitées. La conservation de la sémantique des modèles au cours d’une transformation est un sujet d’étude encore ouvert.
145 Conclusions et perspectives
La dernière perspective que nous envisageons concerne la gestion du test après l’évolution des transformations. Nous avons proposé différentes fonctions d’oracle et analysé que les fonctions les plus intéressantes pour le test de transformations sont les deux utilisant des assertions OCL et des model snippets. Elles permettent en particulier de modulariser les vérifications de l’oracle. L’avantage est de pouvoir les réutiliser si la transformation évolue. En effet, la réutilisation des transformations est courante dans l’IDM, elle justifie d’ailleurs l’effort consacré au développement de ces transformations complexes. En revanche, une transformation n’est pas forcément réutilisée en l’état [Siikarla'08b, Siikarla'08a, Fleurey'07b]. Sa spécification peut varier sur le plan fonctionnel, en fonction de contraintes de plate-forme qui évoluent, ou en fonction du domaine d’application. Ainsi si le méta-modèle d’entrée ou de sortie varie, les modèles de test ne seront plus systématiquement valides. Nous avons aussi expliqué que certains oracles peuvent être rejetés parce qu’ils sont affectés par les changements d’un méta- modèle (quand leur couplage est trop important). Mais il est plus complexe d’envisager et d’automatiser la sélection d’artéfact de test quand les changements sont fonctionnels. De la même façon que pour les problèmes d’iso-fonctionnalité, il est difficile de décider quels éléments sont affectés par un changement s’il n’est pas formalisé. Des recherches sont nécessaires pour étudier la sélection automatique des modèles de test et des oracles qui sont valides après une évolution de la transformation.
Annexe A
Dans cette annexe, nous illustrons ce chapitre avec la présentation des différentes données d’oracle utilisées pour vérifier la transformation de cinq modèles de test. Sont regroupés :
Les six modèles de test permettant d’atteindre le score de mutation de 100%. Nous les avons obtenus au chapitre 3.
Les six modèles attendus en sortie par la transformation de ces cinq modèles de test. Les contrats génériques développés.
Les assertions OCL.
Les assertions de patterns de model snippets.
Tous les cas de test que ces différentes données d’oracle permettent de définir. La transformation utilisée ne permet pas d’implémenter de transformation inverse. En revanche il est possible d’utiliser une transformation de référence comme celle développée par Lawley et Steel [Lawley'05].
147 Annexe A