Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Transformation de Modèles Principe de la Transformation de Modèles Dans le con

Transformation de Modèles Principe de la Transformation de Modèles Dans le contexte du MDA (Model Driven Architecture) : «Le processus de conversion d’un modèle dans un autre modèle du même système». IDM : « une transformation de modèles est la génération d’un ou de plusieurs modèles cibles à partir d’un ou de plusieurs modèles sources » La transformation se fait par l’intermédiaire de règles de transformations qui décrivent la correspondance entre les entités du modèle source et celles du modèle cible. La transformation se situe entre les métamodèles source et cible qui décrivent la structure des modèles cible et source. Le moteur de transformation de modèles prend en entrée un ou plusieurs modèles sources et crée en sortie un ou plusieurs modèles cibles. 2 3 Deux étapes : La première étape : permet d’identifier les correspondances entre les concepts des modèles source et cible au niveau de leurs métamodèles, ce qui induit l’existence d’une fonction de transformation applicable à toutes les instances du métamodèle source. La seconde étape : consiste à appliquer la transformation du modèle source afin de générer automatiquement le modèle cible par un programme appelé moteur de transformation ou d’exécution. Deux types de transformations : Transformation endogène: les modèles impliqués sont issus du même métamodèle (Dans le même espace technologique). Ex : transformation d'un modèle UML en un autre modèle UML Optimisation : améliorer les performances tout en maintenant la sémantique. Refactoring : transformation qui opère un changement dans la structure pour améliorer certains aspects de la qualité du logiciel tels que la compréhension, la maintenance, la modularité et la réutilisation sans changer le comportement observable. Simpliﬁcation ou normalisation : transformation dont le but est de réduire la complexité syntaxique. Transformation exogène : les modèles source et cible sont de différents métamodèles (Entre 2 espaces technologique différents), la transformation est dite exogène ou encore translation. Ex : - Transformation d'un modèle UML en programme Java - Transformation d'un fichier XML en schéma de BDD Synthèse : transformation d’un certain niveau d’abstraction vers un niveau d’abstraction moins élevé. Un exemple typique est la génération de code, Rétro-ingénierie : inverse de la synthèse, Migration : transformation d’un programme écrit dans un langage vers un autre langage du même niveau d’abstraction. 4 Transformation exogène vs transformation endogène 5 Approches de Transformation de Modèles Approche par programmation Utiliser les langages de programmation en général, et plus particulièrement les langages orientés objet. La transformation est décrite sous forme d’un programme informatique à l’image de n’importe quelle application informatique. Approche très utilisée car elle réutilise l’expérience accumulée et l’outillage des langages existants. L’approche par « Template » Définir des canevas des modèles cibles souhaités. Ces canevas sont des modèles cibles paramétrés ou des modèles Template. L’exécution d’une transformation consiste à prendre un modèle Template et à remplacer ses paramètres par les valeurs d’un modèle source. Cette approche est implémentée par exemple dans Softeam MDA Modeler (modelio/ objecteering). 6 L’approche par modélisation Appliquer les concepts de l’ingénierie des modèles aux transformations des modèles elles-mêmes. L’objectif est de modéliser les transformations de modèles et de rendre les modèles de transformation pérennes et productifs, en exprimant leur indépendance vis-à-vis des plates-formes d’exécution. Le standard MOF 2.0 QVT de l’OMG a été élaboré dans ce cadre et a pour but de définir un métamodèle permettant l’élaboration des modèles de transformation de modèles. Cette approche a été choisie par le groupe ATLAS à travers son langage de transformation de modèles «ATL». 7 Règles de Transformation « Les règles de transformation décrivent les correspondances entre les concepts utilisés en entrée de la transformation et ceux résultant de l'application de cette dernière » Il existe des langages impératifs qui décrivent comment une règle est exécutée et des langages déclaratifs qui décrivent ce qui est créé par la règle. Une règle de transformation passe par trois étapes : 1. La vérification de la condition correspond à l’analyse du modèle source de la transformation de manière à détecter la présence d’un ensemble de concepts qui correspond à ce que la règle « attend » en entrée. 2. L’exécution de la règle par le moteur de transformation pour ensemble de concepts vérifiant la condition. 3. La création consiste à générer un ensemble de concepts dans le modèle de sortie dont les champs sont remplis par les variables affectées durant l’exécution. L’agencement et la structuration des règles exécutées dans une transformation permettent de reconstruire l’ensemble du modèle de sortie. 8 Une règle de transformation contient deux parties : une partie gauche (Left-Hand Side «LHS») exprime des accès aux modèles sources, une partie droite (Right-Hand Side «RHS») indique les expansions (création, modification, suppression) dans les modèles cibles. Chacune des deux parties peut être représentée par une combinaison de : Variables : une variable contient un élément de modèle (source ou cible) ou une valeur intermédiaire nécessaire à l’expression de la règle. Patterns : un pattern désigne un fragment de modèle et peut contenir des variables. Il peut être représenté à l’aide d’une syntaxe abstraite ou concrète dans le langage des modèles correspondants. Cette syntaxe peut être textuelle ou graphique. Logique : une logique permet d’exprimer des calculs et des contraintes sur les éléments de modèles. Cette expression peut être non exécutable (expression de relations entre modèles) ou exécutable Une logique exécutable peut être sous une forme déclarative ou impérative : exemple de logique déclarative : des expressions de requêtes OCL pour extraire des éléments d’un modèle source et la création implicite des éléments du modèle cible via les contraintes. Une logique impérative est souvent exprimée par un langage de programmation qui fait appel à des APIs pour manipuler directement les modèles. 9 10 rule Journal2Book { from j : Biblio!Journal to b : Biblio!Book ( title <- j.title + '_(' + j.vol + '):' + j.num, authors <- j.articles ->collect(e | e.authors)->flatten()->asSet() chapters <- j.articles, pagesNb <- j.articles->collect(e | e.pagesNb)->sum() ) } Exemple : règle de transformation en ATL Cette règle génère un élément du modèle Book à partir d’un élément de modèle Journal : 1.Le “title” du “Book” correspond au “title” du “journal” concaténé avec “vol” et num; 2.Le “chapters” du “Book” correspond aux éléments de modèle qui seront générés à partir de “articles” de “Journal”; 3.L’entité “authors” de “Book” correspond à tous les “authors” des différents “articles” de “Journal” sans doublon; 4.L’attribut “pagesNb” est initialisé avec la somme des nombres de page (pagesNb) de tous les articles du modèle source “Journal”. Pattern source Pattern cible 11 Le métamodèle Biblio Approche MDA pour la Transformation de Modèles L’approche MDA est basée sur la manipulation de modèles, Le passage de l'un à l'autre (et vice versa) est une activité centrale de la méthode. 12 Les transformations réflexives de modèles : PIM/PIM (1), PSM/PSM (3), Code/Code (6) Sont effectuées soit lors d'ajout d'éléments pour représenter des niveaux d’abstraction différents, soit pour optimiser un modèle lorsqu'une transformation non réflexive est incomplète ou pas assez précise (raffinage). Il est important de noter que ces transformations réflexives ne sont pas toujours automatisables. Les transformations (4) et (7) : font partie de l'activité de rétro-ingénierie. Cette dernière fait partie de la philosophie de MDA. Génération du code (5) : Le passage d'un modèle type UML à du code écrit en langage évolué (Java, C++,...) que l'on considère ici comme un modèle. La transformation (2) : C’est la transformation centrale de MDA (et aussi la plus délicate) : Le passage du PIM vers le PSM. 13 Deux types de transformation de base : La transformation Horizontale : le niveau d’abstraction en terme de modélisation est préservé (PIM à PIM, ou bien PSM à PSM). permet de faire des mises à jour au niveau des modèles transformés. L’exemple du passage de l’analyse à la conception, illustre la transformation PIM à PIM. La transformation verticale : le niveau d’abstraction des deux modèles, source et cible est différent (PIM vers PSM, ou bien PSM au PIM). La passage de PIM vers PSM, permet par exemple d’intégrer les éléments spécifiques à une plateforme technique, tels que J2EE, CORBA, .NET, etc. L’abstraction PSM au PIM, s’avère très utile pour la reconstruction des systèmes en migration. 14 Propriétés des Transformations Les principales propriétés qui caractérisent les transformations de modèles sont : Réversibilité : une transformation est dite réversible si elle peut se faire dans les deux sens. Exemple : « Model to text » et « text to Model ». Traçabilité : permet de garder des informations sur le devenir des éléments des modèles au cours des différentes transformations qu’ils subissent. Dans un contexte d’IDM, l’information relative à la traçabilité est représentée par un modèle. Une instance de ce modèle est associée à chaque exécution d’une transformation tracée. La définition d’un métamodèle de traces nous permet de structurer les traces qui seront générées par la plate-forme de traçabilité et ainsi de mieux les manipuler. Réutilisabilité : permet de réutiliser des règles de transformation dans d’autres transformations de modèles. L’identification de patterns de transformation est un moyen pour mettre en œuvre cette réutilisabilité. Ordonnancement : l’ordonnancement consiste à uploads/Marketing/ transformation-de-mod-les.pdf