Ajout de l’expression de la sémantique pour chaque type de relation ajouté

Comme décrit dans la troisième activité du processus, l’expert intégrateur est amené à préciser la sémantique de chaque type de relation ajouté (de type DSR). Les types de relation de type DIR possèdent déjà une sémantique (qu’il est possible de modifier) dans la mesure où ils font partie du noyau générique du métamodèle MMC. Nous supposons que le MMC est une

entrée de notre processus de mise en correspondance donc une activité de spécification de la sémantique des types de relation a déjà été effectuée au moment de la définition du noyau générique MMC. L’activité que nous décrivons ici consiste à enrichir le MMC avec des expressions sous forme d’annotations. Dans ce qui suit nous présentons l’expression de la sémantique des types de relation de correspondance par un langage spécifique que nous appelons SED (Semantic Expression Description). Nous utilisons dans cette phase une sémantique opérationnelle exprimée dans un modèle conforme au SED. Ce DSL, décrit par la Figure IV-11, a été proposé afin d’attribuer et de contrôler la sémantique des différents types de relation, qui peuvent différer d’un domaine à un autre (par exemple le type de relation Requirement peut avoir une signification différente d’un domaine à l’autre).

Figure IV-11 : DSL d'expression de la sémantique (SED)

L’activité d’ajout de la sémantique déclenche la création d’un modèle SE à partir du SED. Pour la création de ce modèle, un parcours du MMC doit être effectué afin de récupérer automatiquement la liste des types de relation (de base, et ceux ajoutés par l’expert intégrateur). Le SED permet à l’expert de définir pour chaque type de relation une expression de la sémantique. Chaque expression se compose du type d’élément (ou de la liste des types d’éléments) source et un type d’élément (ou de la liste des types d’éléments) cible (i.e. dans le cas du type Similarity on n’aura que des éléments source étant donné que ce type de relation n’est pas dirigé). L’expression permet aussi de définir une condition qui contient le corps à exécuter dans un langage qui devra être renseigné tel que : OCL, Java, HQL, Ruby, etc. L’attribut format permet de spécifier si le corps de la condition est défini en se basant sur des éléments de modèles (MBF: Model Based Format) ou bien sur des éléments d’ontologies (OBF: Ontology Based Format). Dans le deuxième cas, une transformation (des métamodèles du système étudié) de l’espace technologique de modèles vers celui des ontologies est nécéssaire. La condition définit aussi deux opérations permettant de récupérer les éléments source et cible d’une correspondance. Si l’expression dans un langage formel n’est pas possible, l’expert a la possibilité d’utiliser une expression (tout de même structurée) en langage naturel. Cette structuration est assurée par la définition du type des éléments à relier ainsi que la langue à travers laquelle l’expression est écrite.

du domaine (DIR) − dont l’expression sémantique est donc récupérée du MMC − qui se différencient par le fait que le premier est décrit par un langage formel alors que le deuxième est décrit par une expression en langage naturel, et trois types de relation spécifiques au domaine (DSR). Le détail de l’expression sémantique associé à chaque type de relation est décrit dans la section IV.7.3.2. Le type de relation Similarity, par exemple, est utilisé dans une correspondance impliquant deux éléments (récupérés par la fonction importSourceElts()) de types indifférents (le premier Any pour le premier élément et le second Any pour le deuxième). Il est décrit par une expression en Langage Java. L’expression explicite, à l’aide de la fonction sameAs, que les deux éléments sont similaires. Par ailleurs, pour le type de relation Dependency, étant donné qu’on n’a pas pu décrire le corps de la condition avec un langage informatique, il a été exprimé en langage naturel en précisant le type source concerné.

Figure IV-12 : Extrait du modèle d'expression de la sémantique pour le système CMS

Concernant le type de relation Requirement, de type DSR, il est utilisé pour relier un élément de type Task à un autre de type indéfini. Le corps de la condition, décrit en Java, se base sur la méthode contain. Concernant le type de relation Contribution, il repose sur la même fonction contain sauf que cette fois-ci elle est appliquée entre le parent de l’élément source (par exemple dans le cas du méta-élément Operation c’est le méta-élément Entity, et Table dans le cas de Column) et l’objet véhiculant les données (DataObject) de l’élément cible. Enfin, le corps de la condition pour du type de relation Play reproduit la même fonction sameAs sauf que cette fois-ci, l’élément cible ne peut être que de type Pool.

Dans cette même activité, le modèle SE d’expression de la sémantique est ensuite tissé au MMC à la manière du développement de logiciel par aspects (Filman et al., 2004) (cf. Figure IV-13). Dans notre cas, cela consiste à greffer au MMC les différentes expressions sous la forme d’annotations sur les types de relation ajoutés, comme le montre le MMC annoté résultant (Figure IV-14). Nous avons choisi l’annotation UML comme syntaxe concrète du SED.

Figure IV-13 : Principe du tissage des expressions sémantiques au MMC

L’avantage de l’utilisation du DSL SED est premièrement d’avoir une définition structurée commune de chaque type de relation ; deuxièmement, cela permet de construire le modèle M2C de façon assistée à l’aide des informations sur les types d’éléments reliés (sourceEltType et targetEltType) et troisièmement cela permet d’exploiter le corps des conditions pour filtrer les correspondances lors du raffinement afin de ne garder que celles qui sont en concordance avec la sémantique du type de relation. L’exécution du corps de la condition n’a pas d’effet de bord car il est utilisé uniquement pour évaluer la validité d’une correspondance.