Travaux sur le test de transformations de modèles

Si les transformations de modèles sont un sujet dont l’étude s’est bien développée, il y a peu de travaux traitant de la vérification de ce type de programme. Nous les présentons dans cette sous-section.

Dans [Steel'04] les auteurs présentent un retour d’expérience issue de la validation d’un moteur de transformation de modèles déclarative. Pour le test de ce moteur, chaque donnée de test est une transformation et un modèle d’entrée. La transformation est exécutée par le moteur avec ce modèle et le modèle de sortie obtenu est comparé avec le modèle de sortie attendu. Les auteurs remarquent que ce processus de test est très similaire à un processus de vérification de transformations de modèles. Les auteurs discutent des différents problèmes rencontrés et des solutions envisagées pour les résoudre. La première difficulté identifiée est la complexité de manipuler des modèles comme donnée de test qui impose de disposer d’outils pour éditer et sérialiser les modèles. Le problème du critère de test est également évoqué mais la solution adoptée par les auteurs n’est ni systématique ni automatisable.

Küster a réalisé différents travaux sur le test de transformations de modèles. Il a commencé par aborder la validation de transformations de modèles UML en exploitant une spécification formelle de la transformation sous forme de règles de transformation de graphes attribués et typés [Küster'03]. Dans [Küster'04, Küster'06a], l’auteur identifie le besoin de techniques pour la vérification et le test de transformations de modèles. La technique qu’il permet la vérification de propriétés syntaxiques pour des transformations de modèles décrites par un ensemble de règles de transformations. Les vérifications effectuées dans son approche considèrent la correction syntaxique des règles, la convergence, et la terminaison d’un ensemble de règle.

Dans [Küster'06b], Küster et al. choisissent d’utiliser une approche boîte blanche (test structurel). Ils définissent un langage de template pour générer des modèles de test en se basant sur la structure des règles de la transformation. Cette méthode est fortement dépendante du langage de l’implantation, elle doit être adaptée ou complètement redéfinie pour un autre langage. L’avantage d’une approche boîte blanche est d’imposer que chaque étape de la transformation soit individuellement considérée. Le testeur doit créer des modèles de test pour chacune de ces étapes. De cette manière, le critère de test est plus détaillé et efficace que des critères boîte noire qui ne peuvent pas s’appuyer sur la mécanique interne de la transformation.

Dans [Podnieks'05], Podnieks étudie l’exactitude d’une version simplifiée de la transformation de modèles class2rdbms. Il impose que les modèles d’entrée (diagramme de classes) et de sortie (schéma RDBMS) soient sémantiquement équivalents. Cette condition

permet de produire une transformation inversible (contrairement à la spécification complète de la transformation class2rdbms) qui facilite son test. Narayanan et al. étudient [Narayanan'08] la vérification de transformations de modèles sous forme de graphes mais ils ne considèrent qu’un type de transformations : celles dont les modèles d'entrée et de sortie sont sémantiquement équivalentes. Nous ne restreignons pas notre étude aux transformations de cette nature particulière. Nous considérons pour nos expériences une version complexe de class2rdbms qui ne permet pas d’exploiter cette condition (d’équivalence sémantique) par exemple.

Différents travaux traitent de la création de modèles de test :

Dans [Fleurey'04, Fleurey'07a], Fleurey et al. proposent de transposer l’approche de [Andrews'03] pour le test fonctionnel de transformations de modèles. Une transformation de modèles est créée à partir des méta-modèles sources et cibles. Puisque les méta-modèles sont décrits par le MOF, ils sont semblables aux diagrammes de classes UML (avec l’utilisation de classes, d’attributs, d’héritage, d’associations). Les critères de couverture proposés dans [Fleurey'04, Fleurey'07a] peuvent être utilisés pour couvrir les méta-modèles. Ceci nous donne des critères génériques pour produire des données pour le test de n’importe quelle transformation. Cependant ces critères sont uniquement basés sur la capacité des modèles de test à couvrir les méta-modèles sources de transformations. Même si ces critères fournissent une première mesure de la qualité des modèles de test, cette approche doit être améliorée pour considérer l’intention de la transformation testée.

Dans [Brottier'06], Brottier et al. présentent un processus et un outil pour la génération automatique de modèles de test satisfaisant les critères de test de [Fleurey'07a]. Le processus se base sur les critères pour générer des modèles incomplets car non conformes au méta-modèle source. Puis il complète les modèles pour en faire des modèles de test appartenant au domaine d’entrée de la transformation. Ce domaine d’entrée est spécifié par un méta-modèle effectif qui est un sous-ensemble du méta-modèle source dans lequel seules les méta-classes impliquées dans la transformation sont conservées. Lamari et al. [Lamari'07] proposent un outil génère automatiquement ce méta-modèle effectif. Pour appliquer cette méthode, la spécification de la transformation doit être écrite formellement en MTSpecL, le langage proposé dans l’article.

Dans [Sen'07], le travail pour obtenir des modèles complètement conforme à un méta- modèle [Brottier'06] est repris avec une approche différente. La méthodologie proposée permet en plus de combiner différentes contraintes exprimées en Prolog. De cette manière, il est possible d’obtenir des modèles complets à partir des critères définies par Fleurey et al., du méta- modèle source d’une transformation, et de contraintes complémentaires comme les pré- conditions de la transformation. Cependant Prolog ne permettant pas de contraindre suffisamment la génération, une alternative est fournie avec l’outil de génération de modèles Cartier [Sen'08] qui exprime l’ensemble des paramètres de génération en Alloy. Alloy est un langage avec une logique de premier ordre relationnelle qui supporte la clôture transitive et les quantifieurs.

Dans [Anastasakis'07], Anastasakis et al. exploitent le solveur de contraintes d’Alloy [Jackson'08] directement pour vérifier des transformations de modèles. Ils réalisent la

43 Test de transformations de modèles

vérification en deux étapes. Dans la première étape, les méta-modèles source et cible sont transformés en Alloy ainsi que les règles de la spécification de la transformation sous test. Dans la deuxième étape, si le solveur n’est pas capable d’obtenir une instance de la transformation à partir d’un modèle de test et du modèle correspondant, alors une défaillance est révélée. Si la deuxième étape du processus est intéressante, les hypothèses de la première étape limitent la portée de cette méthode de test. Tout d’abord, le travail pour transformer les règles de la spécification en Alloy est difficile et donc source d’erreur. Cet obstacle est similaire aux précédents travaux cités sur la génération de test qui se base sur une spécification formelle. Ensuite, Alloy utilise une logique de premier-ordre qui peut être insuffisante pour exprimer la totalité de la spécification d’une transformation. Dans ce cas, il n’est pas certain que la méthodologie produira des résultats exacts (sans faux-négatif, ni faux-positif) ou alors en étant fortement limité par la complexité de la transformation à tester.

Dans [Ehrig'06], Ehrig et al. proposent également une technique pour générer automatiquement des ensembles de modèles conformes à un méta-modèle. Leur approche est basée sur une dérivation automatique de grammaires de graphes à partir du méta-modèle. Ils analysent le méta-modèle et génèrent des règles pour créer et associer des instances des méta- classes concrètes du méta-modèle. Cette approche a un certain nombre de limitations. Les valeurs des attributs des objets générés ne sont pas initialisées. Les auteurs proposent d’utiliser un solveur de contrainte pour vérifier que le modèle produit satisfait les contraintes OCL définies dans le méta-modèle, mais ils n’exploitent pas les contraintes pour la génération, il s’agit d’une sélection à posteriori.

Dans [Darabos'06], Darabos et al. considèrent des règles de transformation de graphes comme spécification de la transformation sous test. Ils proposent de générer des modèles de test à partir de cette spécification. Leur technique se focalise sur le test du pattern matching qu’ils considèrent comme particulièrement critique dans le processus d’une transformation. Ils proposent plusieurs classes de fautes qui peuvent être commises pendant la mise en œuvre du pattern matching. Ils développent aussi une technique de génération de tests visant certaines erreurs.

D’autres travaux permettent d’aborder le test de transformations avec des approches formelles :

Dans [Poernomo'08], Poernomo exploite une spécification formelle de la transformation sous test pour en réaliser la preuve. La spécification de la transformation doit pouvoir être transcrite dans le langage formel. La spécification de la transformation ne doit donc pas imposer de construction impérative pour pouvoir appliquer cette méthode. Le travail de formalisation est important et peut entraver la mise en œuvre de ce type de preuve si la transformation est complexe. L’exemple de l’article ne considère d’ailleurs qu’une version de la transformation class2rdbms dont la spécification textuelle ne fait que trois lignes.

Dans leurs travaux, Varró et al. [Varró'03, Varro'02] proposent également de réaliser la vérification des transformations de modèles avec une approche formelle. Ils exploitent une

technique de « model checking » qu’ils appliquent à des transformations implantées avec des règles de transformation de graphes.

Dans [Giese'06], Giese et al. s’intéressent à la vérification formelle de propriétés critiques de transformations de modèles. Les auteurs utilisent des grammaires "triple graph grammars" (TGG) pour représenter le système et les transformations dans le but d’utiliser des méthodes formelles et représenter les propriétés critiques vérifiées par un outil de démonstration de théorème.

Les approches à base de formalisation peuvent être utiles en complément du test quand la spécification formelle est disponible ou peu coûteuse à obtenir. Nous ne considérons pas cette approche formelle dans nos travaux car il nous parait essentiel de disposer de moyens pour obtenir la version formelle de la spécification avant d’essayer de l’exploiter.

Dans le chapitre 4, nous traitons la problématique de l’oracle pour le test de transformations. Nous avons vu dans la section 2.4 que l’oracle de test de logiciels peut être réalisé à partir de contrats ou de résultat attendu. Pour cette raison, nous introduisons ici différents travaux qui exploitent les contrats. Puis nous consacrons le point suivant à la comparaison de modèles.

Dans [Cariou'04], Cariou et al. montrent qu’OCL est adapté pour spécifier les transformations de modèles (UML particulièrement). Il s’agit de pré et post-conditions pour la transformation et aussi de contraintes liant les modèles d’entrée et de sortie. Cela montre que les hypothèses que nous faisons sur les possibilités de formalisation de la spécification sont justifiées et nous permettent d’envisager l’utilisation des contrats pour l’oracle.

Dans [Solberg'06], Solberg et al. proposent des patterns pour exprimer les pré et post- conditions d’une transformation. Ces patterns sont des templates qui décrivent des propriétés attendues des modèles d’entrée et de sortie et qui peuvent être vus comme une spécialisation des méta-modèles source et cible. Les patterns de pré-condition sont utilisés pour contraindre la génération de modèles de test, tandis que les patterns de post-condition sont utilisés pour vérifier l’exactitude des modèles de sortie.