Génération de Transformations de Modèles

Ingénierie dirigée par les modèles

   Le génie logiciel voit régulièrement apparaître de nouveaux paradigmes de programmation. On peut notamment citer la programmation fonctionnelle, le paradigme objet et plus récemment les composants et les aspects. Chacun ayant ses avantages et inconvénients selon les utilisations, chaque paradigme induit une vision différente de la programmation. Par ailleurs, avec l’augmentation des besoins encouragée par l’amélioration des performances des ordinateurs, la taille des programmes n’a eu de cesse d’augmenter et le besoin d’outils pour appréhender de grandes quantités de code s’est fait ressentir. Ainsi des langages proposant des représentations des différentes étapes du développement avec un plus haut niveau d’abstraction sont apparus, tels que UML [Booch et al., 1998] ou Merise [Tardieu et al., 1983]. Le langage UML en particulier présente de nombreux diagrammes dont l’utilité apparaît à différentes étapes du développement, et se veut suffisamment complet pour parer à toutes les situations. Mais il s’est avéré trop limité, ne pouvant prendre en compte tous les paradigmes de programmation existant ou nouvellement créés et ne pouvant être totalement en adéquation dans toutes les situations possibles. L’ingénierie des modèles (IDM [Estublier et al., 2005]) est née de ce besoin de pouvoir créer des langages de modélisation adaptés à chaque situation. Le principal objectif de l’IDM est de placer la modélisation au centre du développement en considérant les modèles comme des éléments de première classe du processus de développement. D’après [Rothenberg, 1989], dont voici un extrait traduit : « la modélisation au sens le plus large est l’utilisation la plus rentable d’une chose à la place d’une autre pour un certain but. Cela nous permet d’utiliser quelque chose de plus simple, de plus sûr ou de moins coûteux qu’en réalité à la place de la réalité pour un certain but. Un modèle représente la réalité pour un but donné ; le modèle est une abstraction de la réalité dans le sens où il ne peut pas représenter tous les aspects de la réalité. Cela nous permet de traiter avec le monde d’une manière simplifiée, en évitant la complexité, le danger et le caractère irréversible de la réalité. »

Les Transformations de modèle

   Dans [Kleppe et al., 2003] on trouve pour les transformations de modèles les définitions suivantes :
– « Une transformation est la génération automatique d’un modèle cible à partir d’un modèle source, suivant une définition de la transformation » ;
– « Une définition de transformation est un ensemble de règles de transformation qui, réunies, décrivent comment un modèle dans un langage source peut être transformé dans un langage cible » ;
– « Une règle de transformation est une description de la manière dont une ou plusieurs structure du langage source peuvent être transformées en une ou plusieurs structures du langage cible ». Mens et Gorp généralisent cette définition en considérant qu’une transformation peutavoir plusieurs modèles source et cible. Ils présentent dans leur état de l’art [Mens et Gorp, 2006] une classification des différentes transformations de modèles selon les critères suivants :
– similarité des espaces techniques : l’espace technique correspond aux langages de représentations supportés pour représenter les modèles en machine. On peut citer par exemple XMI [OMG, 2007] défini par l’OMG.
– transformation endogène versus transformation exogène : une transformation endogène est une transformation dont les modèles source et cible ont le même métamodèle tandis qu’ils sont différents pour une transformation exogène.
– transformation horizontale versus transformation verticale : une transformation horizontale est une transformation où les modèles source et cible sont au même niveau d’abstraction, tandis qu’ils sont différents dans les transformations verticales. Le niveau d’abstraction dépend du niveau de détails dans le modèle, mais ne dépend pas forcément du méta-modèle, ainsi une transformation endogène, telle qu’un raffinement de modèles, peut-être considérée comme verticale.
– transformation syntaxique versus transformation sémantique : une transformation syntaxique se contente de modifier la syntaxe de représentation des modèles tandis qu’une transformation plus complexe est considérée comme sémantique. On considère notamment le passage d’un syntaxe concrète vers une syntaxe abstraite comme une transformation syntaxique. Les transformations peuvent être écrites dans différents langages :
– des langages généralistes auxquels on ajoute un framework ou des librairies permettant la manipulation des modèles, par exemple EMF [Budinsky et al., 2003] avec JAVA ou FAME [Kuhn et Verwaest, 2008] qui est disponible dans plusieurs langage ;
– des langages spécialisés tels que KERMETA [Muller et al., 2005] qui est un langage orienté objet, ATL [Bézivin et al., 2003] qui est un langage déclaratif ou VIATRA [Csertán et al., 2002] qui est un langage basé sur les transformations de graphes. L’écriture d’une transformation nécessite de manipuler les éléments définis dans le méta-modèle, ainsi la programmation d’une transformation nécessite une bonne connaissance du méta-modèle, ainsi que le lien entre les éléments définis dans le méta-modèle et la syntaxe concrète lorsque celle-ci existe. Par exemple dans le cas d’UML [OMG, 2010] une association reliant deux classes dans un diagramme de classe possède des rôles aux quels sont associés des cardinalités et peut être navigable dans les deux sens dans le cas où les deux extrémités de l’association ont connaissance de celle-ci ou dans un seul sens lorsqu’une seule des deux extrémités à connaissance de l’association. En syntaxe abstraite une association est un élément de type Association et les rôles sont des éléments de type Property reliés à l’association par une relation de type MemberEnd. Mais la difficulté se situe au niveau de la navigabilité qui n’est pas définie par un attribut dans l’association mais de la manière suivante : si la Property est reliée à l’Association par une relation de type owningAssociation alors l’extrémité représentée par la Property n’est pas navigable, si la Property est reliée à une Class par une relation de type owningClass, alors l’extrémité représentée par la Property est navigable (la figure 3.2 représente un extrait du méta-modèle UML dans lequel on peut voir la définition des Association). Il est à noter qu’une Property reliée à une Class par une relation de type owningClass peut aussi représenter un attribut si la Property n’est pas associée à une Association. Ceci montre bien qu’avoir une bonne connaissance d’un langage comme UML n’implique pas nécessairement de maîtriser son méta-modèle or ces deux compétences sont nécessaires pour écrire une transformation de modèles

Génération de transformations de modèle basée sur l’alignement de Méta-modèles

   La génération de transformations de modèles à partir d’alignement de méta-modèles est fortement inspirée des méthodes d’alignement de schémas, que nous aborderons plus en détails dans la section 3.1. Cela peut s’appliquer lorsque les méta-modèles source et cible sont proches à la fois sémantiquement et structurellement pour permettre la déduction de la transformation automatiquement à partir des seules informations contenues dans les méta-modèles. Ce type d’approche se trouve donc approprié dans le cadre de migrations de modèles, c’est-à-dire lorsque  les méta-modèles sources et cibles sont deux langages proches dédiés à un même but. Une première approche est présentée dans [Lopes et al., 2005, 2006] où les auteurs présentent une approche de génération automatique de transformation dans laquelle nous pouvons dégager deux parties :
– Dans une première partie, les auteurs définissent un algorithme d’alignement automatique de méta-modèles appelé SAMT4MDE. Il s’agit d’établir un ensemble de correspondances entre les éléments du méta-modèle source et du méta-modèle cible. Pour cela, l’approche propose de comparer les éléments des méta-modèles de même type et d’appliquer sur chaque couple possible une fonction mesurant la similarité entre les éléments. La fonction est définie différemment selon que les éléments à comparer sont des classes, des types primitifs ou des énumérations, mais pour chaque couple elle donne un résultat permettant d’évaluer son degré de similarité. L’ensemble des couples ayant un degré de similarité suffisamment élevé par rapport à une borne définie formeront alors un alignement.
– Dans une seconde partie, les auteurs définissent un outil de génération de transformations à partir d’un alignement appelé MT4MDE. Cet outil est basé sur un métamodèle d’alignement permettant de représenter les différentes correspondances entre les éléments des méta-modèles. À partir d’un modèle d’alignement, l’outil génère alors une transformation de modèle en code ATL. La première partie de cette approche a été par la suite améliorée dans [Lopes et al., 2009] : les modifications portent principalement sur la fonction d’évaluation du degré de similarité, qui évalue non seulement des similarités de valeur au niveau des noms ou des attributs, mais elle évalue aussi la similarité au niveau de la structure des éléments en prenant en compte les éléments qui leur sont liés. Dans [Del Fabro et Valduriez, 2007] les auteurs présentent une approche similaire à la précédente. Il s’agit ici de générer par transformations de modèles un modèle dit de tissage (weaving model en anglais) similaire aux modèles d’alignement vus précédemment. Ce modèle s’obtient grâce à un processus d’alignement qui comme dans les précédentes approches définit d’abord une fonction de similarité appliquée à tous les couples d’éléments des méta-modèles source et cible. Cette fonction de similarité permet de définir un degré de similarité pour chaque couple, il est ici calculé à partir de comparaison de chaînes de caractères, de comparaison de noms à l’aide d’un dictionnaire de synonymes et d’éléments de structure. Le similarity flooding [Melnik et al., 2002] est utilisé pour propager la similarité. Le principe du similarity flooding est basé sur l’hypothèse que les voisins respectifs d’éléments reconnus comme similaires ont de grandes chances d’être eux aussi similaires. Ainsi les voisins d’éléments ayant une similarité importante voient leur similarité augmenter ce qui permet, par propagation, de compléter l’alignement. L’étape finale consiste à prendre les couples dont la similarité est la plus élevée pour obtenir alors le modèle de tissage permettant la génération d’une transformation

Approche utilisant la logique inductive

   La spécification [Varró, 2006] a été suivie par [Balogh et Varró, 2009], une proposition d’implémentation de l’approche précédente utilisant la programmation par logique inductive (ILP [Muggleton et De Raedt, 1994]). La logique inductive est une méthode de machine learning consistant à créer des règles logiques à partir de faits et règles existantes. De manière informelle l’ILP est basée sur un système d’inférence qui s’apparente à de l’apprentissage par généralisation sur un ensemble de faits positifs et négatifs. À partir d’un ensemble B de règles logiques que l’on nommera les connaissances de base, d’un ensemble E + de faits positifs, c’est-à-dire des faits qui sont considérés comme vrais mais qui ne peuvent pas être déduits à partir de B et d’un ensemble E− de faits négatifs, c’està-dire des faits qui sont considérés comme faux mais qui ne peuvent pas être déduits à partir de B, le mécanisme d’induction permet de trouver une hypothèse H telle que B ∧ H permet de déduire E + sans en déduire E−.Dans cette approche, les connaissances de base sont formées par un ensemble de clauses décrivant les modèles sources et cibles alors que les faits positifs sont formés par les liens d’appariement et les faits négatifs par l’ensemble des couples d’éléments sourcecible qui ne sont pas appariés entre eux. À partir de ces données, un moteur d’inférence en logique inductive (ici [ALEPH] est utilisé) peut induire une hypothèse pour chaque type d’appariement sur les propriétés communes des éléments sources et cibles.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Remerciements
Table des figures
Liste des tableaux
1 Introduction 
1.1 Contributions 
1.2 Plan 
2 État de l’art 
2.1 Ingénierie dirigée par les modèles 
2.2 Les Transformations de modèle 
2.3 Génération de transformations de modèles
2.3.1 Génération de transformations de modèle basée sur l’alignement de Méta-modèles
2.3.2 Génération de transformations de modèle basée sur des modèles d’exemple
2.4 Conclusion 
3 Alignement de modèles 
3.1 Aperçu sur les méthodes d’appariement 
3.2 Appariement de modèles 
3.2.1 Exemple illustratif
3.2.2 Appariement basé sur les valeurs d’attributs
3.2.3 Adaptation de l’approche AnchorPROMPT
3.3 Étude de cas 
3.3.1 Outil
3.3.2 Sélection des exemples
3.3.3 Métriques
3.3.4 Résultats
3.4 Conclusion 
4 Génération de transformations 
4.1 Exemple illustratif
4.2 Analyse Relationnelle de Concepts 
4.2.1 Analyse Formelle de concepts
4.2.2 Analyse Relationnelle de concepts
4.3 Spécification de l’approche de génération de transformation 
4.3.1 Classification des éléments du modèle
4.3.2 Classification des liens d’appariements
4.3.3 Interprétation des treillis et création de règles
4.3.4 Gestion des liens dans le modèle cible
4.4 Étude de cas
4.4.1 Outil
4.4.2 Résultats
4.5 Conclusion
5 Conclusion et Perspectives 
5.1 Perspectives
5.1.1 Alignement de modèles
5.1.2 Génération de transformation de modèles
Bibliographie
A Liste détaillée des exemples pour les études de cas
A.1 Transformations endogènes
A.2 Transformations exogènes
B Correction de problèmes de généralisation dans les diagrammes de cas d’utilisation UML

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *