Formation de composants de transformation de modèles

Le modèle proposé pour former des composants de transformations de modèles de confiance est basé sur l’intégration de la spécification et du test des composants logiciels. Ce modèle est particulièrement adapté à l’approche de design-by-contract [Meyer]. Dans ce cas, la spécification est systématiquement traduite en contrats exécutables (invariant, pré/post conditions). La figure 5-1 représente ce modèle de composant avec un diagramme en triangle. Les trois sommets de ce triangle symbolisent les trois éléments constitutifs d’un composant de confiance :

ƒ L’implémentation de la transformation de modèles. ƒ Les cas de test.

ƒ La spécification sous forme exécutable.

Ce modèle a été proposé dans des travaux de Le Traon et al. [Le Traon'99, Baudry'00b] qui se concentraient sur les programmes orientés objets. Dans nos travaux de thèse, nous considérons son application pour les transformations de modèles. Dans ce contexte, l’implémentation peut être réalisée avec des langages orientés objet ou dans d’autres langages

113 Construction de composants de transformation de modèles de confiance

dédiés à la transformation de modèles (section 2.2.3). Nous avons étudié dans les deux précédents chapitres les modèles de test et les différentes fonctions d’oracles qui sont employées pour l’élaboration de cas de test. La spécification est transcrite en une version exécutable avec des contrats. Ils peuvent être écrits en OCL ou dans un autre langage de contraintes. Le contexte des transformations de modèles implique que les contrats soient complexes, car ils sont appliqués à des modèles. Les contrats sont exprimés à un niveau sémantique et traduits en propriétés exécutables qui sont vérifiées pendant l’exécution de la transformation. Aujourd’hui il n’y a pas de standard pour exprimer les contrats des transformations de modèles ou pour définir la spécification d’une transformation.

composant de transformation de modèles

Implantation

Spécification

exécutable

Ensemble

de cas de test

Mise en œuvre de la transformation Associations d’un modèle de test avec un oracle Méta-modèle &

Contrats entre le client et le composant

Figure 5-1. Modèle de composant de transformation de modèles

Dans la suite nous distinguons deux niveaux de contrats respectant la classification de Beugnard et al. [Beugnard'99]. Dans la figure 5-2, nous illustrons le positionnement de ces différents contrats dans le processus de la transformation :

ƒ Contrats basiques : le premier niveau, basique, ou syntaxique, est requis simplement pour faire fonctionner le système. Des langages de définition d’interface, ainsi que des langages typés ou orientés objet, laissent le concepteur du composant spécifier : les opérations que le composant peut réaliser, les paramètres d’entrée et de sortie que chaque composant requiert, et les exceptions possibles qui peuvent être levées pendant l’opération. Appliqués aux composants de transformations de modèles, les méta-modèles source et cible décrivent la structure des données manipulées. Un méta-modèle est formé d’un modèle, écrit en Ecore par exemple, ainsi que d’invariants. Les méta-modèles font partie de la spécification, les modèles d’entrée/sortie doivent s’y conformer. L’ensemble des méta-modèles source et cible (dont leurs invariants) fait également partie de la spécification exécutable et est donc intégré aux composants. Néanmoins, les domaines d’entrée et de sortie définis par les méta- modèles source et cible peuvent être trop étendus. En particulier, le domaine d’entrée de la transformation a besoin d’être contraint davantage pour que les modèles puissent être transformés sans mettre la transformation en échec. Ces contraintes sont exprimées avec des pré-conditions basiques. Nous distinguons trois catégories de contrats basiques :

o contrats du méta-modèle source CMS (dans des invariants du méta-modèle) o contrats basiques du domaine d’entrée CBDE (dans des pré-conditions)

ƒ Contrats de sémantique comportementale : au second niveau, les contrats de sémantique comportementale augmentent le niveau de confiance dans le contexte d’exécution pour une transformation de modèles spécifique. Par exemple, le méta-modèle source de class2rdbms ne définit pas qu’une classe du modèle d'entrée doit inclure au moins un attribut. Ainsi, des contraintes spécifiques peuvent être attachées au domaine d’entrée de la transformation, qui joue le rôle de pré-condition spécifique pour la transformation. Nous distinguons trois catégories de contrats de sémantique comportementale :

o contrats sémantiques du domaine d’entrée CSDE (dans des pré-conditions) expriment des propriétés qui spécifient le domaine source plus précisément que le méta-modèle et les pré-conditions basiques, d’un point de vue sémantique

o contrats sémantiques du domaine de sortie CSDS (dans des post-conditions) expriment des propriétés spécifiques dans les modèles de sortie propres au comportement attendu de la transformation.

o contrats sémantiques reliant entrée et sortie CSR (dans des post-conditions) expriment des propriétés reliant les modèles d’entrée et de sortie. Ces contrats mettent directement en relation le modèle d’entrée avec le résultat de sa transformation pour vérifier qu’elle soit réalisée conformément à la spécification.

Transformation de modèles P os t-condi tions C S R P o st -c ondi ti ons C S D S P ré -condi tions C B D E P ré -condi tions C S DE

Domaine d’entrée défini par le méta-modèle +contraintes basiques +contraintes sémantiques Méta-modèle source : Modèle structurel + invariants CMS Méta-modèle cible : Modèle structurel + invariants CMC

Domaine de sortie défini par le méta-modèle +contraintes sémantiques

Modèle d’entrée

Modèle de sortie

Figure 5-2 - Contrats basiques et sémantiques dans le processus d'une transformation

Formés de cette manière, les trois sommets du composant sont exécutables. Ils permettent de constituer un composant autotestable.

Dans le document Oracles et qualification du test de transformations de modèles (Page 113-115)