Le savoir faire en IDM

</XMI.content> </XMI>

FIGURE 6. UN MODELE UML ET SA REPRESENTATION EN XMI

1.2. Le savoir faire en IDM

De la même manière qu’il existe une collection de modèles ayant diverses propriétés, diverses fonctionnalités sur ces modèles peuvent être réalisées. La gestion de modèles englobe tous les types de fonctionnalités qui permettent la représentation et/ou la manipulation de modèles.

La représentation de modèles correspond aux fonctionnalités de base sur les modèles. Elle regroupe toutes les fonctionnalités d’édition de modèles telles que : l’affichage-présentation, la capture-récupération, le stockage, etc.

La manipulation de modèles comprend aussi les fonctionnalités qui permettent de comparer les modèles telles que : la confrontation de modèles, la mise en correspondance, l’alignement, la fusion, la transformation, etc. Etant donné que le but de l’IDM est d’encapsuler le savoir faire sur les

modèles autour d’un processus de transformation et de vérification de la cohérence, nous avons choisi de leur consacrer une partie pour mieux les expliciter.

1.2.1. La transformation de modèles

Selon [Mens et al., 2006] une transformation peut être vue comme un ensemble de règles qui décrivent comment un ou des modèles sources sont transformés en modèles cibles. Les règles d’une transformation se basent sur les méta-modèles dans lesquels sont exprimés les modèles.

Le modèle produit par une transformation peut être du code, des cas de test, des modèles graphiques, etc.

Il y a plusieurs types de transformation : modèles vers modèles et modèles vers code (ou modèles vers texte) [Czarnecki et al., 2003]. L’IDM, considère toutes ces opérations sur des modèles comme des transformations. C’est une des idées clef dans l’IDM « considérer toutes les opérations génératives de la même manière ».

Actuellement, différents travaux de transformation de modèles [Bézivin et al., 2006], [Jouault, 2006], [Czarnecki et al., 2003] existent. Ces approches visent à considérer une transformation comme un autre modèle (cf. figure 7) conforme à son propre méta-modèle (lui-même défini à l’aide d’un langage de méta-modélisation, par exemple MOF). La figure 6 illustre le principe de transformation d’un modèle. La transformation d’un modèle source Ma : par exemple, le diagramme de cas d’utilisation (conforme à son méta-modèle MMa : par exemple, UML) vers un modèle cible Mb : par exemple, l’arbre de tâches (conforme à son méta-modèle MMb : par exemple, DSL) est réalisé par le modèle de transformation Mt (conforme à son méta-modèle MMt : par exemple, ATL). Touts les méta-modèles utilisés dans le processus de transformation doivent être conformes à une spécification commune, par exemple la MOF, proposée par l’OMG. Finalement ces méta-modèles peuvent être outillés en utilisant la plate-forme Eclipse.

FIGURE 7. LE PRINCIPE DE TRANSFORMATION D’UN MODELE

On peut définir un méta-modèle de transformation pour définir un langage abstrait de transformations. Les modèles instances de ce méta-modèle sont des spécifications de transformations entre deux méta-modèles spécifiques. De cette manière, la spécification de transformation devient lisible (comprendre un modèle est plus facile que de comprendre du code), et réutilisable (le méta-modèle représente les règles de transformation de manière abstraite indépendante du langage de sa mise en œuvre).

Les règles de transformation sont établies entre le méta-modèle source et le méta-modèle cible, c'est-à-dire entre l’ensemble des concepts du modèle source et celui du modèle cible. Le processus de transformation prend en entrée un modèle conforme au méta-modèle source et produit en sortie un ou plusieurs autre(s) modèle(s) conforme(s) au méta-modèle cible, en utilisant les règles préalablement établies. Un exemple de transformation qui explicite le mécanisme de la transformation d’un diagramme de cas d’utilisation vers des arbres de tâches, est présenté dans la section suivant. La transformation permet de générer une tâche pour chaque cas d’utilisation et de structurer partiellement ces tâches.

1.2.2. Les standards et langages pour la transformation de modèles

De nombreux langages de transformation sont à ce jour disponibles :

• les langages graphiques comme TrML [Etien et al., 2007],

• les langages ad-hoc comme MOLA [Kalmins et al., 2004] et MTL [Vojtisek et al., 2004],

• et enfin, les langages basés sur le standard (Query, View, Transformation) QVT [OMG-QVT, 2005].

QVT est une spécification de l’OMG. Il définit plusieurs types de syntaxes : déclarative, impérative, hybride (QVT-relation, etc.) ainsi qu’une sémantique (QVT-Core). Les principes de QVT ont été implémentés dans de nombreux langages comme ATL [Allilaire et al., 2004], Medini QVT [MediniQVT, 2007], Viatra2 [Horvath et al., 2006] et TGG [Greenyer, 2006].

La figure 8 montre un exemple d’une règle de transformation en ATL pour la transformation du diagramme de cas d’utilisation en arbre de tâches [Pérez-Medina et al., 2007].

La première partie de la règle de transformation spécifie qu’à un cas d’utilisation correspond une tâche. Dans la transformation ATL, nous pouvons voir que nous partons d’un cas d’utilisation (partie 1) pour obtenir une tâche (partie 2). Pour créer la tâche (partie 2), le nom du cas d’utilisation (u.nom) est récupéré et utilisé pour donner un nom (nom) à la tâche créée.

La deuxième partie de la règle de transformation exprime le fait qu’un « include » d’un diagramme de cas d’utilisation donne lieu à une sous-tâche dans un arbre de tâches (fille<-u.include). Ainsi un « include » entre deux cas d’utilisation donne lieu à une sous tâche. Les sous-tâches seront juste classées en tant que tâches filles d’une tâche donnée. Ainsi, une inclusion de cas d’utilisation donne lieu à un lien mère/fille (partie 3). Par contre, rien n’est spécifié pour le séquencement (partie 4). Nous obtenons un arbre de tâches conforme à son méta-modèle. Ce modèle reste néanmoins incomplet. Le concepteur en IHM devra donc le compléter, avec en particulier, les opérations de séquencement entre tâches.

FIGURE 8. EXEMPLE DE REGLE DE TRANSFORMATION EN ATL [PEREZ-MEDINA ET AL., 2007]

1.2.3. La mise en correspondance par tissage

L’IDM n’est pas limitée aux transformations de modèles. [Didonet del Faro et al., 2005] propose une autre opération sur les modèles appelée « le tissage de modèles ou méta-modèles ». Le tissage est une opération sur les modèles qui précise les différents types de relations (i.e. des liens) entre les éléments de modèles (ou méta-modèles). Ce lien propose alors la relation entre le modèle source et

le modèle cible de la transformation. Elle permet également de voir quelles règles sont utilisées pour réaliser cette transformation.

Afin d'expliquer le tissage de modèles, nous considérons un système d'information simple pour une bibliothèque décrit dans [Didonet et al., 2007]. Dans ce contexte, la figure 9 montre un exemple d’un modèle de tissage qui capture les relations entre un méta-modèle avec des structures fixes et des relations référentielles : « Foreign Keys » (représentant une clé étrangère en base de données relationnelle, de référence : « R1 ») et un méta-modèle qui contient des structures imbriquées (« Nested ») (représentant une base hiérarchique de données en XML, de référence : « X1 »). Ainsi, les deux schémas représentent la même information, mais des structures de données différentes sont utilisées. Une opération de tissage est spécifiée pour saisir les liens entre les deux schémas avec toutes les informations sémantiquement pertinentes.

FIGURE 9. LIENS ENTRE UN MODELE RELATIONNEL ET UN SCHEMA XML

Dans la figure précédente, la base de données relationnelle (« RI ») possède deux tables : Livres

(avec les attributs : ISBN, Titre, Auteur, SID) et Sujets (SID, Name). L’attribut SID référencie les sujets d’un livre. Le schéma X1a la même structure de base, sauf pour la clé référentielle dans livres, cette correspondance est représentée par la structure imbriquée (« nested ») entre les livres et les sujets.

Les liens entre R1 et X1 sont représentés par le modèle de tissage R1_X1 comme l’illustre la figure 8. Par exemple : alors que les sujets ont un « nom » dans R1, ils sont appelés « Descr » dans X1. Le modèle de tissage dispose de trois structures de tissage : 1) « Equals » une correspondance entre inter-schéma qui indique les égalités telles que R1.Books.ISBN = X1.Books.ISBN, R1.Books.Title = X1.Books.Title ; 2) « ForeignKey (FK) » une correspondance intra-schéma qui indique la contrainte d’intégrité référentielle entre R1.Books.SID et R1.Subjects.SID ; 3) « Nested » une autre intra-correspondance qui représente la relation entre X1.Books et X1.Books.Subjects.

Deux langages à ce jour sont disponibles pour effectuer la mise en correspondance de modèles :

• Atlas Model Weaver language, est un langage de tissage (weaving language) qui a une partie « core » fournissant les concepts génériques de base permettant de créer les liens structurels entre les modèles [Didonet Del Faro et al., 2005]. Les liens inter-modèles sont

stockés dans un modèle appelé « weaving model » qui est défini sur la base du méta-modèle « weaving metamodel ».

• Embedded Constraint Language (ECL) [Gray et al., 2001] est un langage de contraintes qui est une extension du langage de contraintes OCL. ECL définit un ensemble d’opérateurs permettent de naviguer dans la structure hiérarchique d’un modèle.