urbanisation-si.com

L'objectif de cet article est de vous montrer les principes de base d'une transformation de modèles avec ATL (ATLAS Transformation Language).

Si comme moi, cela fait longtemps que vous n'avez pas codé dans un langage, n'ayez crainte, je vous fourni tous les sources et vous n'aurez qu'à les copier-coller alors bon courage.

Sélectionnez le projet Families2Persons créé lors d'un article précédent avec les 2 métamodèles Families.ecore et Persons.ecore (voir la série de l'été 2015 consacrée à ATL).

1. File - New - Other - ATL - ATL File - File name = Families2Persons.atl
2. Next
3. Input Models - Add - Model Name = laissez IN par défaut - Metamodel Name = Families - Browse Workspace = Families.ecore
4. Output Models - Add - Model Name = laissez OUT par défaut - Metamodel Name = Persons - Browse Workspace = Persons.ecore

Ouvrez le fichier Families2Persons.atl avec l'éditeur de source, vous devez avoir :

Appliquons les bonnes pratiques de programmation consistant à créer des services (ou fonction, en ATL on parle de helpers comme dans Java).

Les 1er helper regarde si une occurrence de Membre est liée à un familyMother de type Family ou familyDaughter dans ce cas le helper isFemale() renvoie true et false dans le cas contraire.

Le 2ème helper retourne le lastName de tous les membres de la famille : père, mère, fils ou filles.

helper context Families!Member def: isFemale(): Boolean =
	if not self.familyMother.oclIsUndefined() then
		true
	else
		if not self.familyDaughter.oclIsUndefined() then
			true
		else
			false
		endif
	endif;

helper context Families!Member def: familyName: String =
	if not self.familyFather.oclIsUndefined() then
		self.familyFather.lastName
	else
		if not self.familyMother.oclIsUndefined() then
			self.familyMother.lastName
		else
			if not self.familySon.oclIsUndefined() then
				self.familySon.lastName
			else
				self.familyDaughter.lastName
			endif
		endif
	endif;

Pour finir, on ajoute 2 règles pour créer les "Person" : "Male" ou "Female" :

La règle Member2Male regarde si l'occurrence considérée n'est pas "Female" en appelant le helper précédent, crée une nouvelle instance de Male, concatène le "firstName" et "familyName" dans le fullName de la super classe abstraite Person  de Male.

La règle Member2Female fait la même chose mais pour "Female" bien sur.

rule Member2Male {
	from
		s: Families!Member (not s.isFemale())
	to
		t: Persons!Male (
			fullName <- s.firstName + ' ' + s.familyName
		)
}

rule Member2Female {
	from
		s: Families!Member (s.isFemale())
	to
		t: Persons!Female (
			fullName <- s.firstName + ' ' + s.familyName
		)
}

Créez le fichier des instances de Family et Member dans le projet Families2Persons :

1. File - New - File - sample-Families.xmi avec le contenu suivant :

<?xml version="1.0" encoding="ISO-8859-1"?>
<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns="Families">
	<Family lastName="March">
		<father firstName="Jim"/>
		<mother firstName="Cindy"/>
		<sons firstName="Brandon"/>
		<daughters firstName="Brenda"/>
	</Family>
	<Family lastName="Sailor">
		<father firstName="Peter"/>
		<mother firstName="Jackie"/>
		<sons firstName="David"/>
		<sons firstName="Dylan"/>
		<daughters firstName="Kelly"/>
	</Family>
</xmi:XMI>

Suspens, reste à exécuter la transformation ATL :

1. Clic droit sur le fichier Families2Persons.atl - Run As - Run Configuration - ATL Transformation - Families2Persons 
2. Onglet ATL Configuration
3. Source Models - IN = clic sur Workspace - Families2Persons - sample-Families.xmi
4. Target Models - OUT = clic sur Workspace - Families2Persons - saisir le nom de fichier sample-Persons.xmi qui contiendra le résultat de la transformation.
5. Pour ne pas à refaire la configuration de l'exécution : clic sur l'onglet Common
6. Sélectionner Shared file - Browse -  Families2Persons

Le suspens est à son comble : clic sur Apply puis sur Run

Le résultat se trouve dans le fichier sample-Persons.xmi qui doit ressembler à ceci :

<?xml version="1.0" encoding="ISO-8859-1"?>
<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns="Persons">
	<Male fullName="Jim March"/>
	<Male fullName="Brandon March"/>
	<Male fullName="Peter Sailor"/>
	<Male fullName="David Sailor"/>
	<Male fullName="Dylan Sailor"/>
	<Female fullName="Cindy March"/>
	<Female fullName="Brenda March"/>
	<Female fullName="Jackie Sailor"/>
	<Female fullName="Kelly Sailor"/>
</xmi:XMI>

Voilà fin du suspens et fin de notre 1ère saison sur ATL qui se termine avec un "happy end" à l'américaine.  

"La meilleure façon de combattre le mal est un progrès résolu dans le bien."
Lao-Tseu

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Dans les articles précédents nous avons vu que la transformation de modèles nécessitent que ceux-ci soient décrits par des métamodéles et qu'à leur tour les métamodéles le soient par un métamétamodéle en l'occurrence "Ecore" d'Eclipse pour le langage auquel nous nous intéressons : ATL (ATLAS Transformation Language).

Maintenant qu'Eclipse Modeling Tools, Papyrus et ATL sont installés, il est grand temps de passer aux choses sérieuses.

Si on se réfère à MDA (Model Driven Architecture), la norme de l'OMG (Object Management Group) pour les transformations de modèles, une des composantes de ce framework est le MOF (Meta Object Facility) qui décrit les 4 niveaux de modélisation : M0 la vraie vie (les objets avec leur état), M1 modèle, M2 métamodèle et M3 métamétamodèle auto décrit .

On part de la vraie vie c'est à dire des objets (par exemple la facture du 26/01 du client Martin), puis on remonte d'un niveau d'abstraction, au niveau modèle (les classes Facture et Client) puis encore plus abstrait avec le méta modèle (on modélise le modèle : par ex. en urbanisation du Système d'Information, on trouve : le métamodèle du niveau métier, le métamodèle du niveau fonctionnel, le métamodèle du niveau applicatif) puis enfin ça se termine avec le métamétamodèle du MOF où tout est représenté sous forme de Classe.

Pour récapituler, dans notre tutoriel consacré à ATL, le métamétamodèle est Ecore d'Eclipse, le métamodèle source est Families, le métamodèle cible est Persons.

Le modèles source est décrit dans le fichier sample-Families.xmi et est conforme au métamodèle Families et le modèle cible résultat de la transformation est décrit dans sample-Persons.xmi conforme au métamodèle Persons.

En fait fait les modèles à transformer correspondent au niveau M0 objet du MOF, mais comme dans IDM tout est modèle, on peut aussi les considérer au niveau M1 modèle.  

Alors commençons et comme dans tous les environnements, AGL ou autres, il faut créer un projet et Eclipse Modeling Tools n'échappe pas à la règle :

1. Menu Window - Open Perspective - Other - ATL
2. File - New - ATL Project - Project name = Families2Persons

Créez le métamodèle source Families.ecore.

1. Clic droit sur le projet - New - Other - Eclipse Modeling Framework - Ecore Model - File name = Families.ecore
2. Affichez la vue Properties : Window - Show View - Other - General - Properties
3. Nommez la racine du fichier : Families

Créez la classe Family :

1. Clic droit sur la racine - New Child - EClass - dans la vue properties : Name = Family 
2. Créez les attributs de la classe Family : clic droit sur la classe - New Child - EAttribute - Name = lastName - EType = EString - Lower Bound = 1 et Upper Bound = 1

Créez la classe Member de la même manière avec l'attribut firstName (EString).

Après les classes et les attributs, reste les relations :

1. Clic droit sur Family - New Child - EReference - Name = Father - EType = Member - EOpposite = familyFather : Family - Lower Bound = 1 - Containment = true
2. Idem pour mother et pour sons, daughters il faut modifier les multiplicités : Lower Bound = 0 et Upper Bound = -1 (signifie * identique à 0 ou pluseurs).
3. Mettre les rôles du coté Member : familyFather - EType = Family - EOpposite = father : Member - Containment = false - Lower Bound = 0 - Upper Bound = 1

Créer le métamodèle cible Persons.ecore de la même manière que précédemment.

Créez la classe abstraite Person sous la racine Persons avec :

1. l'attribut fullName (EString) et la multiplicité 1..1.
2. la propriété Abstract = true 

Créez les classes Male et Female et mettre la propriété ESuper Types = Person pour spécifier qu'elles héritent de la classe Person.

Voilà qui nous permettra d'écrire nos règles de transformation mais suspens jusqu'au prochain article.

Si vous ne voulez pas faire toutes ces manipulations, vous pouvez ouvrir votre fichier Families.ecore vide avec le Text Editor et copier-coller le contenu ci-dessous (idem pour Persons .ecore)

Families.ecore

<?xml version="1.0" encoding="ISO-8859-1"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="Families">
<eClassifiers xsi:type="ecore:EClass" name="Family">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="lastName" ordered="false"
unique="false" lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="father" ordered="false"
lowerBound="1" eType="#//Member" containment="true" eOpposite="#//Member/familyFather"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="mother" ordered="false"
lowerBound="1" eType="#//Member" containment="true" eOpposite="#//Member/familyMother"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="sons" ordered="false" upperBound="-1"
eType="#//Member" containment="true" eOpposite="#//Member/familySon"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="daughters" ordered="false"
upperBound="-1" eType="#//Member" containment="true" eOpposite="#//Member/familyDaughter"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Member">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="firstName" ordered="false"
unique="false" lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="familyFather" ordered="false"
eType="#//Family" eOpposite="#//Family/father"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="familyMother" ordered="false"
eType="#//Family" eOpposite="#//Family/mother"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="familySon" ordered="false"
eType="#//Family" eOpposite="#//Family/sons"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="familyDaughter" ordered="false"
eType="#//Family" eOpposite="#//Family/daughters"/>
</eClassifiers>
</ecore:EPackage>

Persons.ecore

<?xml version="1.0" encoding="ISO-8859-1"?>
<xmi:XMI xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore">
<ecore:EPackage name="Persons">
<eClassifiers xsi:type="ecore:EClass" name="Person" abstract="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="fullName" ordered="false"
unique="false" lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Male" eSuperTypes="#/0/Person"/>
<eClassifiers xsi:type="ecore:EClass" name="Female" eSuperTypes="#/0/Person"/>
</ecore:EPackage>
</xmi:XMI>

"Gagner sa vie ne vaut pas le coup, attendu qu'on l'a déjà. Le boulot y en a pas beaucoup, faut le laisser à ceux qui aiment ça."

Coluche

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Dans notre série estivale consacrée aux transformations de modèles, je vous propose après les articles de présentation sur la théorie, de passer à la pratique.

Pour cela, il va falloir faire des installations, mais je vous rassure, rien de bien compliquer.

1. Installez Java : aller à https://www.java.com/fr/ et cliquer sur "Téléchargement gratuit de Java". Suivez les indications, si vous ne savez pas s'il faut prendre la version 32 ou 64 bits, prenez la 32 qui marchera dans tous les cas.
2. Installez Eclipse Modeling Project : http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/luna/SR2/eclipse-modeling-luna-SR2-win32.zip et cliquer sur download.   (Remarque si vous êtes sur que votre machine supporte le 64 bits, prenez la version 64).
3. Décompressez le fichier récupéré (par ex.  eclipse-modeling-luna-SR2-win32.zip). Le répertoire eclipse est créé.
4. Vérifiez que Eclipse Modeliing démarre en cliquant sur eclipse.exe dans le répertoire eclipse.
5.  Téléchargez le plugin Papyrus de modélisation UML 2 et SysML : http://www.eclipse.org/papyrus/downloads/ cliquer sur All-In-One Update Site (1.1.0 (2015/06/10))
6. Décompressez le zip dans un répertoire.
7. Dans Eclipse, allez dans le menu Help - Install new software - Add - Local - sélecionnez le répertoire de Papyrus - nommez et OK
8. Téléchargez ATL (ATLAS Transformation Language) : http://www.eclipse.org/downloads/download.php?file=/mmt/atl/downloads/drops/3.6.0/R201505180909/m2m-atl-Update-3.6.0.zip&protocol=http et cliquez sur Download .
9. Décompressez le zip ( m2m-atl-Update-3.6.0.zip ) dans un répertoire.
10. Pour installer le plugin ATL, procédez exactement de la même manière que pour Papyrus.
11. Vérifiez dans Eclipse - Help - Help Contents que Papyrus et ATL sont bien installés (voir l'image en début de cet article).

Que faire ensuite, nous verrons cela au prochain épisode, quel suspens ...

"Aujourd'hui on ne sait plus parler, parce qu'on ne sait plus écouter."
Jules Renard

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Voici un exemple de transformation de modèles. Cet exemple est l'équivalent du fameux "Hello world" que fait presque par tradition tous les débutants dans un langage ou un outil.

La transformation "Author2Person" génère un modèle cible "Person" conforme à un métamodèle "MMPerson" à partir d'un modèle source "Author" conforme à un métamodèle "MMAuthor".

La transformation spécifiée en ATL (ATLAS Transformation Language) est conforme au métamodèle ATL.

Dans cet exemple que l'on développera dans d'autres articles, les 3 modèles sont conformes au métamétamodèle Ecore d'Eclipse.

"Je me moque de savoir beaucoup de choses : je veux savoir des choses que j'aime."
Jules Renard

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Dans le périmètre de l'Ingénierie Dirigée par les Modèles ( IDM ) (ou Model Driven Engineering MDE), la transformation de modèles vise à spécifier le processus de production de modèles cibles à partir d'un nombre quelconque de modèles sources.

Formellement, une simple transformation doit définir la manière pour générer un modèle Mb conforme à un métamodèle MMb à partir d'un modèle Ma conforme à un métamodèle MMa.

Tous les éléments utilisés dans l'Ingénierie Dirigée par les Modèles (IDM) sont considérés comme des modèles.

Une transformation est elle même considérée comme un modèle et elle doit se conformer à un métamodèle de transformation spécifiant la sémantique de transformation.

Un modèle Ma conforme au métamodèle MMa est transformé en modèle Mb conforme au métamodèle MMb. La transformation est définie par le modèle de transformation Mt, conforme au métamodèle MMt. Les métamodèles  doivent être conformes au métamétamodèle MMM (MOF de l'OMG ou Ecore d'Eclipse).

ATL ( Atlas Transformation Language ) est un langage de transformation de modèles permettant de spécifier comment un ou plusieurs modèles cibles peuvent être générés à partir d'un ensemble de modèles sources.

Autrement dit ATL défini un ensemble de concepts dans le but de décrire une transformation de modèles.

Nous verrons dans un prochain article un exemple concret de type "Hello world" (terme générique utilisé pour le premier exemple concret réalisé par les débutants apprenant un outil ou un langage de développement), mais on n'en dira pas plus pour faire monter le suspens ... 

"Il n'y a qu'une façon d'être un peu moins égoïste que les autres : c'est d'avouer son égoïsme."
Jules Renard

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Les modèles constituent le socle de l'architecture pilotée par les modèles ( Model Driven Architecture MDA ). Dans le model driven engineering, un modèle est défini selon la sémantique d'un modèle de modèles appelé métamodèle. Un modèle respectant la sémantique d'un métamodèle est dit "conforme" à ce métamodèle.

Le modèle du réseau de Petri est composé de différents éléments : places, transitions et arcs.

Ils sont définis dans le métamodèle du réseau de Petri. De même, dans un modèle conforme à un métamodèle, il existe une relation entre les éléments du modèle et ceux du métamodèle appelée "méta relation", associant chaque élément du modèle instancié à un élément du métamodèle.

Mais un métamodèle est lui même un modèle qui doit être conforme à son propre métamodèle. Pour cela le Model Driven Architecture MDA défini un 3ème niveau correspondant au métamétamodèle.

Un métamétamodèle a pour objectif de définir la sémantique nécessaire à la spécification du métamodèle qui sera donc conforme à son métamétamodèle. 

Pour éviter d'avoir un mécanisme sans fin ( métamétaméta... ), le métamétamodèle se défini lui même c'est à dire qu'il peut être spécifié avec sa propre sémantique. Par conséquent un métamétamodèle est conforme à lui même.

Plusieurs métamétamodèles sont disponibles.

Le langage ATL ( Atlas Transformation Language ), dont nous parlerons tout au long de notre série d'articles estivales, fourni 2 technologies :

• Meta Object Facilities ( MOF 1.4 ) de l'Object Management Group OMG
• Ecore metametamodel défini par Eclipse Modeling Framework (EMF).

Cela signifie que ATL peut gérer des métamodèles spécifiés avec la sémantique du MOF ou de Ecore.

Suspens, suite au prochain épisode ...

"Le véritable courage consiste à être courageux précisément quand on ne l'est pas."
Jules Renard

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Les séries de l'été sont à la mode, je vous propose donc une série sur le Model-Driven Engineering (MDE) ou Ingénierie Dirigée par les Modèles (IDM) en français.

Les modèles sont de plus en plus intégrés aux processus d'ingénierie logicielle.

Cependant, il faut bien reconnaître qu'ils sont la plupart du temps cantonnés à un rôle documentaire au lieu d'un rôle prépondérant dans le processus d'ingénierie.

A l'opposé de cette approche passive, le champ du Model-Driven Engineering (MDE) met en avant les modèles et les considère comme les pièces maîtresses de processus de développement logiciel. Dans le cadre de pensée MDE, tout peut être représenté sous forme de modèles, aussi bien les outils que les référentiels, les entités métier, les concepts, ... L'approche du pilotage par les modèles suppose de fournir les modèles de conception et  de développement avec un ensemble d'opérations dédiées à la manipulation de modèles.

Dans ce contexte, la transformation de modèle apparaît comme une opération centrale pour le traitement des modèles avec comme objectif majeur la possibilité de spécifier les manières de produire plusieurs modèles cibles à partir d'un ensemble de modèles sources.

Dans le champ du MDE, cela signifie que les transformations de modèles, comme n'importe quels outils basés sur les modèles, sont elles même modélisées et sont donc des modèles à part entière.

Nous verrons au prochain épisode les principaux concepts de l'architecture pilotée par les modèles (attention ! MDA = Model Driven Architecture est une marque déposée de l'OMG Object Managment Group, c'est pour cela que nous resterons indépendant en utilisant l'acronyme MDE), les notions de modèles, métamodèles et métamétamodèles.

"Si je devais recommencer ma vie, je n'y voudrais rien changer ; seulement j'ouvrirais un peu plus grand les yeux."
Jules Renard

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/