Rapport XMI To SVG

UNIVERSITE HASSAN II-MOHAMMEDIA
FACULTE DES SCIENCES BEN MSIK
DEPARTEMENT DES MATHEMATIQUES ET
INFORMATIQUE –CASABLANCA
Master Qualité Logiciel
Année Universitaire : 2014/2015
Réalisé par :
ABOUNASR MERYEM
BOUJADI SOUKAINA
Encadré par :
Dr. ABDESSAMAD BELANGOUR
Rapport Transformation des fichiers
XMI en fichiers SVG avec JAVA et ATL

2
Table des matières
LISTE DES FIGURES...............................................................................................................4
INTRODUCTION ...................................................................................................................5
CHAPITRE 1 : INTRODUCTION AUX FORMALISMES XML ET XMI ............................................6
1.1 Extensible Markup Language : XML.................................................................................................7
1.2 XML Metadata Interchange :XMI ..................................................................................................10
1.2.1 Formalisme XMI......................................................................................................................10
1.2.2 Objectifs XMI ..........................................................................................................................10
1.2.3 Exemple fichier XMI généré à partir du visual paradigm .......................................................11
1.3 Le parsing d’un fichier XML ...........................................................................................................12
1.3.1 L’API JDOM .............................................................................................................................13
CHAPITRE 2 : TRANSFORMATION XMI EN SVG EN JAVA......................................................23
2.1 SVG : Scalable Vector Graphics......................................................................................................24
2.1.1 Introduction à SVG................................................................................................................24
2.1.2 Un premier document SVG....................................................................................................24
2.1.3 Les formes de base ................................................................................................................29
2.1.4 Les transformations...............................................................................................................41
2.2 Exemple transformation XML en SVG avec JAVA..........................................................................47
2.2.1 Diagramme de cas d’utilisation avec Visual Paradigm...........................................................47
2.2.2 Export sous format XMI.........................................................................................................49
2.2.3 Parsing avec Java pour extraire les données nécessaires ......................................................49
2.2.3 Transformation du diagramme en SVG.................................................................................61
CHAPITRE 3 : TRANSFORMATION XMI EN SVG AVEC ATL ...................................................71
3.1 Introduction....................................................................................................................................72
3.2 Le langage ATL................................................................................................................................72
3.2.1 Vue d’ensemble sur la transformation ATL...........................................................................72
3.2.3 Installation Eclipse ................................................................................................................81
3.3 Votre premier projet ATL :.............................................................................................................84
3.4 Transformation du diagramme avec ATL : ....................................................................................92

3
3.4.1 Définir Les méta-Modèles .......................................................................................................94
3.4.2 Un exemple de Modèle de diagramme de use case au format xml........................................98
3.4.3 Définir Les transformations ATL...........................................................................................101
3.4.4 Exécution des Fichiers ATL....................................................................................................107

4
LISTE DES FIGURES
Figure 1 JDOM Représentation arborescente 'un document XML ......14
Figure 2 Méthodes de la classe Document..........................................16
Figure 3 Méthodes de la classe Element .............................................17
Figure 4 Méthodes de la classe Attribute............................................18
Figure 5 Diagramme de cas d'utilisation .............................................48
Figure 6 Partie du Fichier XMI .............................................................49
Figure 7 Diagramme de cas d'utilisation en SVG ................................69
Figure 8 Vue d’ensemble sur la transformation ATL...........................73
Figure 9 Méta-modèles Book et Publication .......................................76
Figure 10 Transformations ATL (UML à Text) .....................................93
Figure 11 Méta-Modèle SVG ...............................................................95
Figure 12 Méta-Modèle Diagramme Use Case....................................96
Figure 13 Méta-Modèle Diagramme Use Case (zoomé).....................97
Figure 14 Méta-Modèle XML...............................................................98
Figure 15 Transformation Uml 2 SVG ................................................101
Figure 16 Exemple de transformation UseCaseUml2EllipseSVG.......102
Figure 17 Transformation SVG 2 XML................................................103
Figure 18 TextSvg2ElementXML........................................................105
Figure 19 Fichier SVG généré avec ATL..............................................112
Figure 20 Fichier SVG généré avec ATL zoomé..................................113

5
INTRODUCTION
Dans le cadre d’une évaluation dans le module «génie Logiciel», Notre
professeur nous a demandé de réaliser des projets pour nous initier à
l’approche d'ingénierie des modèles, c’est une approche qui Propose de
modéliser les applications à un haut niveau d’abstraction
Ce qui nous a été demandé est de transmettre un fichier XMI ou bien XML à
un fichier SVG Avec le langage JAVA puis avec le langage de transformation
des Modèles ATL.
Le présent rapport décrit avec détail la démarche que nous avons suivi pour
réaliser les deux projets. Il comporte trois chapitres :
 le premier chapitre présente les formalismes XML et XMI.
 Le deuxième chapitre expose le langage SVG ainsi que les étapes à
suivre pour transformer un fichier xmi en SVG avec le langage JAVA.
 Le troisième chapitre est consacré à la transformation en SVG
avec le langage ATL.

6
CHAPITRE 1 : INTRODUCTION AUX
FORMALISMES XML ET XMI

7
1.1 Extensible Markup Language : XML
Le formalisme XML (Extended Markup Language) permet la représentation
structurée d'informations dans un format texte. Il peut par conséquent être
utilisé comme format syntaxique de transport de modèles et de méta-
modèles. La structure de l'information est alors définie dans un fichier
annexe au format DTD (Document Type Description). L'avantage d'un tel
formalisme est de permettre l'échange d'informations dès lors que l'on base
celle-ci sur une DTD normalisée.
Voici un exemple de document XML représentant un livre et sa table des
matières :
<?xml version="1.0" ?>
<!DOCTYPE Livre "Livre.dtd">
<Livre Auteur="Michel Nakhlé et Charles Modiguy">
<Titre>Rapport</ Titre >
<Chapitre id="1">
Premier Chapitre. Introduction.
</Chapitre >
<Chapitre id="2">
Second Chapitre. Glossaire.
</Chapitre >
</Livre>

8
Dans ce formalisme, nous trouvons la notion d'élément. Les éléments sont
définis avec un marqueur de début et un marqueur de fin. Le marqueur de
début constitué simplement du nom de l'élément tandis que le marqueur de
fin est constitué du nom de l'élément préfixé du caractère "/".
Dans l'exemple précédent, nous avons les éléments
 Rapport représentant les rapports,
 Titre représentant le titre des rapports et
 Chapitre représentant l'intitulé d'un chapitre.
Ces éléments peuvent ensuite disposer d'attributs. Les attributs
correspondent généralement au niveau le plus fin de décomposition des
éléments. Dans l'exemple précédent, nous avons l'attribut Auteur défini sur
l'élément Rapport et représentant le nom de l'auteur du rapport et l'attribut
id sur l'élément Chapitre indiquant le numéro du chapitre.
Le rôle du fichier au format DTD est de décrire tous les éléments que l'on est
susceptible de rencontrer dans le fichier XML ainsi que tous les attributs que
ces éléments sont susceptibles de disposer.
Ainsi, la DTD nommée livre.dtd qui a permis de construire le fichier XML
précédent est la suivante :
<!DOCTYPE Livre [

9
Cette DTD décrit les trois éléments Rapport, Titre et Chapitre ainsi que leurs
attributs.
Actuellement, l’utilisation de DTD pour décrire le contenu des fichiers XML
est en train de disparaître au profit des schémas. Les schéma sont des
fichiers au format XML (ce qui n’était pas le cas des fichiers DTD) et
proposent un certain nombre de facilités pour la définition de la structure
des fichiers XML.
L’un des avantages de XML est sa souplesse et sa lisibilité tandis que ses
désavantages sont l’aspect « verbeux » du langage entraînant rapidement
des fichiers d’une taille importante et le fait que les données représentées
dans un fichier XML le sont sous la forme d’un arbre. En effet dès que l’on
souhaite représenter des graphes dans un document XML, il est nécessaire
de définir des références qui vont alors à l’encontre de la souplesse et la
lisibilité. Or les modèles et les méta-modèles sont plus généralement
constitués de graphes que d’arbres.
< !ELEMENT Rapport(Titre, Chapitre+)>
< !ATTLIST Rapport Auteur CDATA #REQUIRED>
< !ELEMENT Titre (#PCDATA)>
< !ELEMENT Chapitre (#PCDATA)>
<!ATTLIST Chapitre id ID #REQUIRED>
]>

10
1.2 XML Metadata Interchange : XMI
1.2.1 Formalisme XMI
XMI est le langage d’échange entre le monde des modèles et le monde XML
(eXtensible Markup Language). C’est le format d’échange standard entre les
outils compatibles MDA. XMI décrit comment utiliser les balises XML pour
représenter un modèle UML en XML. Cette représentation facilite les
échanges de données (ou métadonnées) entre les différents outils ou plates-
formes de modélisation. En effet, XMI définit des règles permettant de
construire des DTD* (Document Type Definition) et des schémas XML à
partir de méta-modèle, et inversement. Ainsi, il est possible d’encoder un
méta-modèle
Dans un document XML, mais aussi, à partir de document XML il est possible
de reconstruire des méta modèles. Les méta-modèles MOF et UML sont
décrits par des DTD et les modèles traduits dans des documents XML
conformes à leur DTD correspondante. XMI a l’avantage de regrouper les
métadonnées et les instances dans un même document ce qui permet à une
application de comprendre les instances grâce à leurs méta-données. Ceci
facilite les échanges entre applications.
1.2.2 Objectifs XMI
L'objet principal de XMI est de permettre l'échange de méta données entre
outils de modélisation basés sur UML et la communication des répertoires de
méta données basés sur le MOF deux standards de l'OMG.

11
L'effet économique et technique est important, parce que jusqu'ici il était à
peu près impossible à une communauté de travail, un groupe d'entreprises…
de travailler sur des modèles communs en utilisant des outils de conception
provenant de fournisseurs différents.
XMI se fonde sur les trois standards XML, UML et MOF :
 UML est un formalisme orienté objet de conception et de
documentation d'applications,
 MOF est une technologie de définition et de représentation de méta
données en tant qu'objets CORBA. Pour mémoire, CORBA est un
concept permettant à deux applications de communiquer entre elles
sans se soucier de leur localisation ou de leur mode de conception.
Les spécifications de XMI consistent à proposer un ensemble de règles de
transformation de structures MOF en DTD XML, des DTD pour UML et MOF,
un ensemble de règles de production de documents XML pour manipuler
des méta données MOF. XMI est donc la rencontre entre deux mondes
importants, celui des objets et celui des structures de données et documents.
1.2.3 Exemple fichier XMI généré à partir
du Visual paradigm
En guise d’exemple, pour bien comprendre le formalisme, voyons ce fichier
XMI, qui représente un diagramme de cas d’utilisation avec un acteur
«Journaliste » et un cas d’utilisation «Rediger Article ».

12
1.3 Le parsing d’un fichier XML
Ile est essentiel pour le receveur d’un document XML de pouvoir extraire les
données du document. Cette opération est possible à l’aide d’un outil appelé
parseur.

13
Le parseur permet de créer une structure hiérarchique contenant les
données contenues dans le document XML. On en distingue deux types selon
l’approche qu’ils utilisent pour traiter le document :
 Les parseurs utilisant une approche hiérarchique : ceux-ci construisent
une structure hiérarchique contenant des objets représentant les
éléments du document, et dont les méthodes permettent d’accéder aux
propriétés. La principale API utilisant cette approche est DOM
(Document Object Model).
 Les parseurs basés sur un mode événementiel permettent de réagir à
des événements (comme le début d’un élément, la fin d’un élément) et
de renvoyer le résultat à l’application interface utilisant l’aspect
événementiel.
1.3.1 L’API JDOM
JDOM est une API open source Java dont le but est de représenter et
manipuler un document XML de manière intuitive pour un développeur Java
sans requérir une connaissance pointue de XML. Par exemple, JDOM utilise
des classes plutôt que des interfaces. Ainsi pour créer un nouvel élément, il
faut simplement instancier une classe.
Malgré la similitude de nom entre JDOM et DOM, ces deux API sont très
différentes. JDOM est une API uniquement Java car elle s'appuie sur un
ensemble de classes de l'API Java notamment celles de l'API Collection.
Le site officiel de l'API est à l'url http://www.jdom.org/

14
1.3.1.1 La présentation de JDOM
Le but de JDOM n'est pas de définir un nouveau type de parseur mais de
faciliter la manipulation au sens large de document XML : lecture d'un
document, représentation sous forme d'arborescence, manipulation de cet
arbre, définition d'un nouveau document, exportation vers plusieurs formats
cibles ...
Figure 1 JDOM Représentation arborescente 'un document XML
Dans le rôle de manipulation sous forme d'arbre, JDOM possède moins de
fonctionnalités que DOM mais en contrepartie il offre une plus grande facilité
pour répondre aux cas les plus classiques d'utilisation.
Cette facilité d'utilisation de JDOM lui permet d'être une API dont l'utilisation
est assez répandue.

15
JDOM est donc un modèle de documents objets open source dédié à Java
pour encapsuler un document XML. JDOM propose aussi une intégration de
SAX, DOM, XSLT et XPath.
JDOM n'est pas un parseur : il a d'ailleurs besoin d'un parseur externe de
type SAX ou DOM pour analyser un document et créer la hiérarchie d'objets
relative à un document XML. L'utilisation d'un parseur de type SAX est
recommandée car elle consomme moins de ressources que DOM pour cette
opération. Par défaut, JDOM utilise le parseur défini via JAXP.
Un document XML est encapsulé dans un objet de type Document qui peut
contenir des objets de type Comment, Processing Instruction et l'élément
racine du document encapsulé dans un objet de type Element.

16
Figure 2 Méthodes de la classe Document
Les éléments d'un document sont encapsulés dans des classes dédiées :
Element, Attribute, Text, ProcessingInstruction, Namespace, Comment,
DocType, EntityRef, CDATA.

17
Figure 3 Méthodes de la classe Element

18
Figure 4 Méthodes de la classe Attribute
Un objet de type Element peut contenir des objets de type Comment, Text et
d'autres objets de type Element.
A l'exception des objets de type Namespace, les éléments sont créés en
utilisant leur constructeur.

19
JDOM vérifie que les données contenues dans les éléments respectent la
norme XML : par exemple, il n'est pas possible de créer un commentaire
contenant deux caractères moins qui se suivent.
Une fois un document XML encapsulé dans un arbre d'objets, il est possible
de modifier cet arbre dans le respect des spécifications de XML.
JDOM permet d'exporter un arbre d'objets d'un document XML dans un flux,
un arbre DOM ou un ensemble d'événements SAX.
JDOM interagit donc avec SAX et DOM pour créer un document en utilisant
ces parseurs ou pour exporter un document vers ces API, ce qui permet de
facilement intégrer JDOM dans des traitements existants. JDOM propose
cependant sa propre API.
1.3.1.2 Les fonctionnalités et les caractéristiques
JDOM propose plusieurs fonctionnalités :
 Création de documents XML
 Encapsulation d'un document XML sous la forme d'objets Java de l'API
 Exportation d'un document dans un fichier, un flux SAX ou un arbre
DOM
 Support de XSLT
 Support de XPath

20
Les points caractéristiques de l'API JDOM sont :
 elle est développée spécifiquement en et pour Java en utilisant les
fonctionnalités de Java au niveau syntaxique et sémantique (utilisation
des collections de Java 2, de l'opérateur new pour instancier des
éléments, redéfinition des méthodes equals(), hashCode(), toString(),
implémentation des interfaces Cloneable et Serializable, ...)
 elle se veut intuitive et productive notamment grâce à des classes
dédiées à chaque élément instancié via leur constructeur et l'utilisation
de getter/setter
 elle se veut rapide et légère
 elle veut masquer la complexité de certains aspects de XML tout en
respectant ses spécifications
 elle doit permettre les interactions entre SAX et DOM. JDOM peut
encapsuler un document XML dans un hiérarchie d'objets à partir d'un
flux, d'un arbre DOM ou d'événements SAX. Il est aussi capable
d'exporter un document dans ces différents formats.
Il est légitime de se demander qu'elle est l'utilité de proposer une nouvelle
API pour manipuler des documents XML en Java alors que plusieurs

21
standards existent déjà. En fait le besoin est réel car JDOM propose des
réponses à certaines faiblesses de SAX et DOM.
DOM est une API indépendante de tout langage : son implémentation en Java
ne tient donc pas compte des spécificités et standards de Java ce qui rend sa
mise en œuvre peu aisée. JDOM est plus intuitif et facile à mettre en œuvre
que DOM.
Comme DOM, JDOM encapsule un document XML entier dans un arbre
d'objets. Par contre chaque élément du document est encapsulé dans une
classe dédiée selon son type et non sous la forme d'un objet de type Node.
JDOM peut être utilisé comme une alternative à DOM pour manipuler un
document XML. JDOM ne remplace pas DOM puisque ce n'est pas un parseur,
de plus il propose des interactions avec DOM en entrée et en sortie.
L'utilisation de DOM requiert de nombreuses ressources notamment à cause
de son API qui de surcroît n'est pas n'est pas intuitive en Java. DOM est
développé de façon indépendante de tout langage et son organisation est
proche de celle des spécifications XML (tous les éléments sont des Nodes par
exemple).
SAX est particulièrement bien adapté à la lecture rapide avec peu de
ressources d'un document XML mais son modèle de traitement par
événements n'est pas intuitive et surtout SAX ne permet pas de modifier ni
de naviguer dans un document.

22
JDOM propose d'apporter une solution à ces différents problèmes dans une
seule et même API.

23
CHAPITRE 2 : TRANSFORMATION XMI
EN SVG EN JAVA

24
2.1 SVG : Scalable Vector Graphics
2.1.1 Introduction à SVG
SVG est l'acronyme de Scalable Vector Graphics, un langage de description des
graphiques bidimensionnels en XML. Puisque les images sont générées “en
code” à base de formes géométriques et non de pixels, elles sont “zoomables”
à l’infini et on peut les redimensionner sans perte de qualité
SVG inclut un rendement de qualité, des possibilités de zoom et de
panoramique, les filtres sur les objets, le remplissage des formes avec des
textures et des gradients, les masques, les animations et l'interactivité et bien
d'autres choses encore!
2.1.2 Un premier document SVG
2.1.2.1 Structure basique d’un document SVG
Vos documents SVG devront toujours avoir cette structure :

25
Pour faciliter leur référencement, vous pouvez aussi ajouter un titre et un
description :
<!xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904
/DTD/svg10.dtd">
<svg width="400px" height="300px" xml:lang="fr"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<![CDATA[?xml version="1.0" encoding="utf-8"?>
"http://www.w3.org/TR/2001/REC-SVG-
20010904/DTD/svg10.dtd">

26
Explications
Décomposons le document :
On commence d’abord par le prologue XML dans lequel on indique la version
de XML utilisée et l’encodage. Il y a beaucoup de chances que votre éditeur
de texte enregistre les documents en iso-8859-1. Si ce n’est pas le cas, vous
devriez trouver une option vous permettant de choisir. Attention : rappelez
vous que si rien n’est indiqué, l’encodage par défaut est l’UTF-8 !
Ensuite, nous avons le DOCTYPE permettant au navigateur d’avoir ce qu’il
affiche. Ici, c’est bien évidemment du SVG !
<!DOCTYPE indique au processeur XML qu’il s’agit d’un DOCTYPE ; ensuite
<title>Mon premier document SVG !</title>
<desc>Salut, ceci est mon premier document SVG  !</desc>
</svg>
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

27
viens le type de document : SVG ; puis on a l’identifiant public (-
//W3C//DTD SVG 20010904//EN) ; enfin l’adresse de la DTD.
On arrive enfin à notre première balise SVG !
Il s’agit bien sur de l’élément racine de notre document.
Les attributs width et height servent à spécifier respectivement la longueur
et la largeur du dessin. On peut spécifier ces longueurs en pixel, mais il n’y a
pas moins de 9 unités possibles :
 px : le pixel
 mm : le millimètre
 cm : le centimètre
 in : le pouce
 pc : le pica (1/6 de pouce)
</svg>
Une des règles fondamentales de XML est qu’un élément (une balise)
doit contenir toutes les autres. Par exemple, la balise html contient
toutes les autres balises <HTML /> dans un document Web.

28
 pt : le point (1/72 de pouce)
 em : la taille du carré em, soit le plus souvent la taille d’une ligne
 ex : la taille de la lettre x
 % : le pourcentage de la zone de visualiation, c’est à dire de la fenêtre
de votre navigateur si vous ouvrez un dessin SVG dedans.
Si vous n’écrivez pas les attributs width et height, alors le processeur SVG
considérera que ces deux valeurs valent 100%.
On arrive ensuite au namespaces.
Le mécanisme des namespaces sert, concrètement, à indiquer au
parseur XML de quel langage il s’agit. Il évite donc les conflits entre deux
balises ayant le même nom mais appartenant à deux langages différents,
par exemple les balises <text/> de SVG et de XSLT.
On utilise un préfixe pour indiquer à quel namespace appartient une
balise ou un attribut. Par exemple « xlink:href » appartient au
namespace XLink, son nom qualifié (qname) est « xlink:href », son nom
local (localname) est « href » et son préfixe est « xlink ».
On doit déclarer un espace de nommage avant de l’utiliser (grâce à
l’attribut xmlns) de cette façon :
xmlns:prefix="URI de l’espace de nommage"

29
Pour SVG, il suffit juste d’indiquer le namespace de SVG, la DTD se chargeant
de XLink. Cependant, dans un soucis d’interopérabilité et puisque ça nous ne
coûte rien, on va quand même le mettre. En plus ça nous évitera des
problèmes lors d’un traitement avec XSLT.
On peut aussi spécifier deux balises enfants de <svg/>  : <title/> et <desc/>.
<title/> sert à donner un titre à notre dessin. Son contenu ne sera donc
pas affiché dans la zone de dessin. Par contre, il est probable qu’il s’affiche
dans la barre d’état de votre navigateur ou dans une info bulle lors du survol
du document SVG par la souris. Il n’est pas obligatoire mais pour des raisons
d’accessibilité, on devrait toujours mettre un titre évocateur, comme dans un
document (X)HTML.
<desc/> donne la description de notre dessin. Renseigner cette balise peut
s’avérer utile lorsqu’on souhaite que le document soit référencé par un
moteur de recherche.
2.1.3 Les formes de base
Nous l’avons vu, SVG sert à dessiner des formes. Nous allons donc
commencer par dessiner des formes de base : les rectangles, les cercles et les
ellipses, les lignes et les polygones.
 Les rectangles
 Les cercles et les ellipses
 Les lignes
 Les lignes polygonales et les polygones

30
 Les rectangles
Pour dessiner un rectangle, on utilise la balise rect qui a quatre attributs :
 x qui détermine l’abscisse de départ ;
 y qui détermine l’ordonnée de départ ;
 width qui nous donne la longueur ;
 height qui est la hauteur.
Dessinons un rectangle de 100 pixels de longueur et 40 de hauteur, décalé de
50 pixels vers le bas et vers la droite :
<! xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG
20010904//EN"
20010904/DTD/svg10.dtd">
<title>Mon premier dessin SVG</title>

31
Avec l’exemple précédent, on obtient :
 Les cercles et les ellipses
Pour dessiner un cercle, on utilise la balise circle. Elle doit avoir trois
attributs :
 cx donne à SVG l’abscisce du centre du cercle ;
 cy l’ordonnée du centre ;
 r est le rayon.

<rect x="50" y="50" width="100" height="40"/>
</svg>

32
Avec
l’exemple précédent, on obtiens :
<![CDATA[?xml version="1.0" encoding="utf-8"?>
20010904//EN"
20010904/DTD/svg10.dtd">
<title>Des cercles, des cercles, encore des
cercles…</title>
<circle cx="200" cy="240" r="30"
style="fill:thistle;"/>
</svg>

33
Maintenant que nous savons tracer des cercles, intéressons nous aux ellipse.
C’est sensiblement la même chose, sauf qu’on utilise la balise ellipse. Elle
requiert quatre attributs :
 cx comme pour le cercle est l’abscisse du centre ;
 idem pour cy ;
 rx est le rayon « horizontal » de l’ellipse ;
 ry le rayon « vertical ».
Notez que comme pour le cercle, si cx et/ou cy ne sont pas renseignés, ils
prennent zéro comme valeur.
20010904//EN"
20010904/DTD/svg10.dtd">
<title>Des ellipses de toutes les couleurs avec
SVG</title>

34
<ellipse cx="200" cy="150" rx="180" ry="50"
style="fill:none;stroke:lightsteelblue;stroke-
width:30px;stroke-opacity:0.5;"/>
<ellipse cx="200" cy="150" rx="50" ry="130"
style="fill:none;stroke:lightsteelblue;stroke-
width:30px;stroke-opacity:0.5;"/>
</svg>

35
 Les lignes
Pour dessiner un ligne, on utilise la balise <line/> qui a besoin de quatre
attributs :
 x1 renseigne l’abscisse du point de départ ;
 y1 l’ordonnée du point de départ ;
 x2 l’abscisse du point d’arrivé ;
 y2 l’ordonnée du point d’arrivé.
Une ligne n’a pas de couleur de remplissage (fill) et si le viewer d’Adobe en
dessine, c’est une erreur 
20010904//EN"
20010904/DTD/svg10.dtd">

36
<title>Des lignes de toutes les couleurs avec
SVG</title>
<line x1="100" x2="20" y1="20" y2="200"
style="fill:none;stroke:springgreen;stroke-
width:2px;"/>
<line x1="150" x2="70" y1="40" y2="220"
style="fill:none;stroke:palegreen;stroke-
width:4px;"/>
<line x1="200" x2="120" y1="60" y2="240"
style="fill:none;stroke:lightgreen;stroke-
width:8px;"/>
<line x1="250" x2="170" y1="80" y2="260"
style="fill:none;stroke:yellowgreen;stroke-
width:16px;"/>
<line x1="300" x2="220" y1="100" y2="280"
style="fill:none;stroke:mediumseagreen;stroke-
width:32px;"/>
</svg>

37
 Les lignes polygonale et les polygones
Derrière l’appellation « lignes polygonales » se cache en fait une suite de
segments, tout simplement. C’est la balise <polyline/> qu’on utilise et elle n’a
besoin que d’un attribut : points qui contient une liste de couples de points
qui délimitent notre ligne polygonale. Ces couples peuvent être séparés par
des espaces blancs ou des virgules. Par exemple :

38
20010904//EN" "http://www.w3.org/TR/2001/REC-
SVG-20010904/DTD/svg10.dtd">
<title>Exemple d’utilisation de la balise
polyline</title>
<polyline points="20,10 40,30 60,10 80,30 100,10
120,30 140,10 160,30 180,10
200,30 220,10 240,30 260,10 280,30 300,10 320,30
340,10 360,30 380,10"/>
<polyline points="20,60 40,80 60,60 80,80 100,60
120,80 140,60 160,80 180,60
200,80 220,60 240,80 260,60 280,80 300,60 320,80
340,60 360,80 380,60"
style="fill:none;stroke:black;stroke-width:4px;"/>
<polyline points="50,150 250,150 300,200 250,250

39
Passons aux polygones. En fait c’est quasiment la même chose, à deux
différences près : un segment est automatiquement tracé entre le dernier
point et le premier et on utilise l’élément <polygon/> au lieu de <polyline/>.
C’est tout !
50,250"
style="fill:none;stroke:cornflowerblue;stroke-
width:10px;stroke-dasharray:3,4,10,4;stroke-
dashoffset:-7;"/>
</svg>

40
20010904//EN"
20010904/DTD/svg10.dtd">
<title>Un test de l’élément SVG polygon</title>
<polygon points="20,20 70,60 120,30 150,80
200,20 250,80 280,30 330,60 380,20
320,150
380,280 330,240 280,270 250,220 200,280
150,220 120,270 70,240 20,280
80,150"
style="fill:cornsilk;fill-
opacity:0.6;stroke:darkblue;stroke-
width:7px;stroke-miterlimit:40;"/>
</svg>

41
2.1.4 Les transformations
Il y a cinq transformations possibles en SVG : la translation (translate), la
rotation (rotate), le changement d’échelle (scale), la transformation par
inclinaison de l’axe des abscisse (skewX) et celle par inclinaison de l’axe des
ordonnées (skewY).
Cependant, on n’utilise qu’un seul attribut pour effectuer les
transformations : l’attribut transform. La syntaxe pour effectuer un
transformation est : transform="mot-clé(valeur1, valeur2, valeurn)".
 La translation :

42
La translation requiert deux paramètres : le premier est la translation sur
l’axe des abscisses et le second sur l’axe des ordonnées. Effectuons une
translation pour placer un cercle au milieu de la zone de dessin :
20010904//EN"
20010904/DTD/svg10.dtd">
<svg width="400" height="300" xml:lang="fr"
<title>Translation d’un cercle avec SVG</title>
<circle r="120"
style="fill:indigo;fill-
opacity:0.22;stroke:indigo;stroke-
width:3px;stroke-dasharray:5,5;"
transform="translate(200,150)"/>
</svg>

43
 La rotation :
20010904//EN"
20010904/DTD/svg10.dtd">
<title>Rotation d’un rectangle avec SVG</title>

44

<rect x="0" y="0" width="400" height="300"
style="fill:none;stroke:black;stroke-width:2px;"/>
fill:none;stroke:limegreen;stroke-
width:14px;stroke-linejoin:bevel;"/>
fill:none;stroke:limegreen;stroke-
width:14px;stroke-linejoin:bevel;"
transform="rotate(30)"/>
</svg>

45
C’est donc toute la zone de dessin qui subit une rotation autour de son point
d’origine de coordonnées 0,0. C’est d’ailleurs la même chose avec la
translation. Heureusement, il est tout à fait possible de spécifier le centre de
rotation avec un second et un troisième paramètre. Le second est l’abscisse
du centre de rotation et le troisième est l’ordonnée. Par exemple, sur un
carré :

46
20010904//EN"
20010904/DTD/svg10.dtd">
<title>Rotation d’un carré sur lui même avec
SVG</title>
style="fill:none;stroke:darkmagenta;stroke-
width:10px;stroke-linejoin:round;"
transform="rotate(45, 200, 150)"/>
<circle cx="200" cy="150" r="1"/>
</svg>

47
Bien sur, les longueurs n’ont pas été prises au hasard : le point 200,150 est le
centre du carré. Notez que la rotation se fait dans le sens indirect, c’est à dire
dans le sens des aiguilles d’une montre
2.2 Exemple transformation XML en SVG
avec JAVA
Le but de cette partie est de montrer comment parser un ficher XMI avec le
langage JAVA utilisant L’API jdom2 .Pour cela on va
 Créer un diagramme de cas d’utilisation avec Visual Paradigm
 L’Exporter sous format XMI
 Parser avec Java pour extraire les données nécessaires
 Et enfin on va redessiner le diagramme avec SVG
2.2.1 Diagramme de cas d’utilisation avec Visual
Paradigm

48
Figure 5 Diagramme de cas d'utilisation

49
2.2.2 Export sous format XMI
Figure 6 Partie du Fichier XMI
2.2.3 Parsing avec Java pour extraire les données
nécessaires
Fonction pour parser le fichier XMI avec SaxBuilder :
public Document GetDocument(File file)
{
Document doc=null;
try {
doc= saxBuilder.build(file);
}
catch (JDOMException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
}
return doc;
}

50
Fonction pour charger la liste des éléments :
public void parser(Document doc)
{
try {
// Obtenir la racine de l’élément
racine = doc.getRootElement();
model = racine.getChild("Model", umlNS);
// Obtenir les Acteurs ,cas d’utilisation et Association
Lelements=model.getChildren("ownedMember");
// Les propriétés pour dessiner les éléments
diagram=racine.getChild("Diagram", umlNS);
diagram=diagram.getChild("Diagram.element", umlNS);
Lpropriete=diagram.getChildren("DiagramElement", umlNS);
}
catch (Exception e) {
}
}
On va créer une classe Actor , UseCase et Association telle que :
public class Actor {
// Nom de l’acteur
String nom;
// Id de l’acteur
String id;
// Relation de généralisation
String general=null;
// les coordonnées pour dessiner un acteur
int x;
int y;
int rx;
int ry;
}

51
public class UseCase {
// Id du cas d’utilisation
String id;
// Nom du cas d’utilisation
String nom;
//Les points d’extension du Cas d’utilisation
ArrayList extensionPoint=new ArrayList<>();
// les coordonnées pour dessiner un acteur
int x;
int y;
int rx;
int ry;
}
public class Association {
String id;//id de lassociation
String source;//La source de l’association
String destination; //La destination de
l’association
String type;// extension , inclusion,…
// les coordonnées pour dessiner l’association
int x1;
int y1;
int X2;
int y2;
}

52
Maintenant on va parcourir la liste des éléments pour récupérer la liste des
Acteurs, dans le fichier XMI :
public ArrayList<Actor> Acteurs(Document doc)
{
parser(doc);
iteratorElements=Lelements.iterator();
do
{
iteratorPropriete=Lpropriete.iterator();
element = (Element)iteratorElements.next();
//les Acteurs
if(element.getAttributeValue("type",xmiNS).equals("uml:Actor"))
{
Actor a=new Actor();
a.setId(element.getAttributeValue("id", xmiNS));
a.setNom(element.getAttributeValue("name"));
do
{
propriete=(Element)iteratorPropriete.next();
if(propriete.getAttributeValue("preferredShapeType").equals("Actor")
&&
propriete.getAttributeValue("subject").equals(
element.getAttributeValue("id", xmiNS)))
{
String geometry=propriete.getAttributeValue("geometry");
String[] attributs=geometry.split(",");
a.setX(Integer.parseInt(attributs[0]));
a.setY(Integer.parseInt(attributs[1]));
a.setRx(Integer.parseInt(attributs[2]));
a.setRy(Integer.parseInt(attributs[3]));
}
}while(iteratorPropriete.hasNext());

53
if(element.getChildText("generalization") != null)
{
a.setGeneral(element.getChild("generalization").getAttributeValue("id",
xmiNS));
}
LActor.add(a);
}
} while(iteratorElements.hasNext());
return LActor;
}

54
Fonction pour parcourir la liste des éléments pour récupérer la liste des Cas
d’utilisations dans le fichier XMI :
public ArrayList<UseCase> UseCases(Document doc)
{
// iteratorProprieteU=LproprieteU.iterator();
parser(doc);
//les cas d'utilisation
do
{
if(element.getAttributeValue("type",xmiNS).equals("uml:UseCase"))
{
UseCase u=new UseCase();
u.setId(element.getAttributeValue("id", xmiNS));
u.setNom(element.getAttributeValue("name"));

55
do
{
if(propriete.getAttributeValue("preferredShapeType").equals("UseCase")
&&
propriete.getAttributeValue("subject").equals(element.getAttributeValue("id
", xmiNS)))
{
String geometry=propriete.getAttributeValue("geometry");
String[] attributs=geometry.split(",");
u.setX(Integer.parseInt(attributs[0]));
u.setY(Integer.parseInt(attributs[1]));
u.setRx(Integer.parseInt(attributs[2]));
u.setRy(Integer.parseInt(attributs[3]));
}
LUseCase.add(u);
}
return LUseCase;
}

56
La Fonction Association récupère la liste des Association, dans le fichier
XMI.
public ArrayList<Association> Associations(Document doc)
{
int x1=0,x2=0,y1=0,y2=0;
String type=null;
parser(doc);
//les cas d'utilisation
do
{
if(element.getAttributeValue("type",xmiNS).equals("uml:Association"))
{
Association a=new Association();
a.setId(element.getAttributeValue("id", xmiNS));
do
{
if(propriete.getAttributeValue("preferredShapeType").equals("Association")
&&
propriete.getAttributeValue("subject").equals(element.getAttributeValue("id
", xmiNS)))
{

57
{
String
geometry=propriete.getAttributeValue("geometry");
String[] attributs=geometry.split(";");
String[] point1= attributs[0].split(",");
String[] point2=attributs[1].split(",");
x1=Integer.parseInt(point1[0]);
y1=Integer.parseInt(point1[1]);
type="Association";
}
a.setX1(x1);
a.setY1(y1);
a.setX2(x2);
a.setY2(y2);
a.setType(type);
LAssociation.add(a);
}
return LAssociation;
}
La Fonction Generalization récupère la liste des Généralisations entre les
acteurs , dans le fichier XMI :

58
public ArrayList<Association> Generalization(Document doc)
{
int x1=0,x2=0,y1=0,y2=0;
String type=null;
parser(doc);
//les actors
for(int i=0;i<LActor.size();i++)
{
if(LActor.get(i).getGeneral()!=null)
{
String general=LActor.get(i).getGeneral();
List<Element>
for (Element item : Lpropriete)
{
if(item.getAttributeValue("preferredShapeType").equals("Generalization")
&&
item.getAttributeValue("subject").equals(general))
{
String
geometry=item.getAttributeValue("geometry");
String[] point1= attributs[0].split(",");
type="Generalization";
a.setX1(x1);
a.setY1(y1);
a.setX2(x2);
a.setY2(y2);
a.setType(type);
LGeneralization.add(a);

59
La Fonction Extension récupère la liste des Extensions entre les cas
d’utilisations , dans le fichier XMI :
}
}
}
}
return LGeneralization;
}
public ArrayList<Association> Extensions(Document doc)
{
int x1=0,x2=0,y1=0,y2=0;
String type=null;
parser(doc);
Lpropriete=diagram.getChildren("DiagramElement",
umlNS);
do
{

60
if(propriete.getAttributeValue("preferredShapeType").equals("Exten
d"))
{
String
geometry=propriete.getAttributeValue("geometry");
String[] point1=
attributs[0].split(",");
type="Extend";
a.setX1(x1);
a.setY1(y1);
a.setX2(x2);
a.setY2(y2);
a.setType(type);
LExtension.add(a);
}
return LExtension;
}

61
2.2.3 Transformation du diagramme en SVG
Maintenant on a récupérer tous les éléments nécessaires pour dessiner notre
diagramme de cas d’utilisation Avec SVG .
Pour cela on va créer une Classe « JdomSvg » qui contient les fonctions pour
dessiner le diagramme
/*
cette fonction écrit du code XML dans le document qui va être générer
*/
public static void writeFile(
String fname, Document doc){
try{
FileOutputStream out = new FileOutputStream(fname);
XMLOutputter xmlOut =new XMLOutputter(Format.getCompactFormat());
xmlOut.output(doc,out);
out.flush();
out.close();
}
catch (IOException e){
System.err.println(e);
}
}

62
/*
Fonction pour créer la balise SVG dans le document
*/
public static Element makeSvg(
String ns,//namespace URI
int svgWidth,// largeur de la fenêtre
int svgHeight,// Hauteur de la fenêtre
){
Element svg = new Element("svg",ns);
//Les valeurs par défaut des attributs
svg.setAttribute("version","1.1");
svg.setAttribute("preserveAspectRatio","none");
svg.setAttribute("width",""+svgWidth);
svg.setAttribute("height",""+svgHeight);
svg.setAttribute("viewBox",
vbMinX + vbMinY + ""+vbWidth + " "+vbHeight);
return svg;
}

63
// Fonction pour ajouter une balise au document
static Element AjouterNoeud (Element parent,
String namespace,
String nodeType,
String[] data){
Element element = new Element(nodeType,namespace);
parent.addContent(element);
//si la balise n’a pas d’attributs
if(data == null){
return element;
}
// Sinon
for(int cnt=0;cnt<data.length;cnt+=2){
String name = data[cnt];
String value = data[cnt+1];
element.setAttribute(name,value);
}
// Fonction pour dessiner un ellipse
public static Element DessinerEllipse(
Element parent,
String namespace,
int cx,//Abscisse Centre
int cy,//Ordonnée Centre
int rx,//Rayon Horizontal
int ry //Rayon Vertical
){
Element ellipse = new Element("ellipse",namespace);
parent.addContent(ellipse);
//valeurs par défauts
ellipse.setAttribute("fill","rgb(122,207,245)");
ellipse.setAttribute("stroke","black");
ellipse.setAttribute("stroke-width","1");
//les coordonnées de l’ellipse.
ellipse.setAttribute("cx",""+cx);
ellipse.setAttribute("cy",""+cy);
ellipse.setAttribute("rx",""+rx);
ellipse.setAttribute("ry",""+ry) ;
return ellipse;}

64
return element;
}
/*
Fonction pour dessiner un cercle
*/
public static Element dessinerCercle(
Element parent,
String namespace,
double e,//Abscisse Centre
double f,//Ordonnée Centre
double d // Rayon du Cercle
)
{
Element circle = new Element("circle",namespace);
parent.addContent(circle);
//Les valeurs par defaults
circle.setAttribute("fill","yellow");
circle.setAttribute("stroke","black");
circle.setAttribute("stroke-width","2");
//les coordonnées du cercle
circle.setAttribute("cx",""+e);
circle.setAttribute("cy",""+f);
circle.setAttribute("r",""+d);
return circle;
}

65
/*
Fonction pour écrire du texte dans le document SVG
*/
static Element ecrireText(Element parent,
String namespace,
int x,
int y,
String text){
Element textNode = new Element("text",namespace);
parent.addContent(textNode);
textNode.setAttribute("x",""+x);
textNode.setAttribute("y",""+y);
textNode.setAttribute("stroke","none");
textNode.setAttribute("space","preserve");
textNode.addContent(text);
return textNode;
}
/*
Focntion pour dessiner une ligne
*/
public static Element dessinerLine(
Element parent,
String namespace,
int x1,//Abscisse 1er point
int y1,//Ordonnée 1er point
int x2,//Abscisse 2eme point
int y2 //Ordonnée 2eme point
){
Element line = new Element("line",namespace);
parent.addContent(line);
//Les valeurs par défaut
line.setAttribute("stroke","black");
line.setAttribute("stroke-width","1");

66
//Les coordonnées de la ligne
line.setAttribute("x1",""+x1);
line.setAttribute("y1",""+y1);
line.setAttribute("x2",""+x2);
line.setAttribute("y2",""+y2);
return line;
}
/*
Fonction pour dessiner un polygon
*/
static Element dessinerPolygon(Element parent,
String namespace,
int[] points){
Element polygon = new Element("polygon",namespace);
parent.addContent(polygon);
//Les valeurs par défauts
polygon.setAttribute("stroke","black");
polygon.setAttribute("stroke-width","1");
polygon.setAttribute("fill","none");
//Les coordonnées du polygone
String dataPoints = "";
for(int cnt=0;cnt<points.length;cnt++){
dataPoints += "" + points[cnt] + ",";
}
polygon.setAttribute("points",dataPoints);
return polygon;
}

67
Exemple pour dessiner un acteur
String[] data=new String[4];
data[0]="font-size";
data[1]="14";
data[2]="transform";
int trans=y;
data[3]="translate(42,"+trans+")";
Element g = JdomSvg.AjouterNode(svg,//parent
ns,//namespace
"g",
data
);
JdomSvg.dessinerCircle(g, ns,14.5,7.5,7.5);
JdomSvg.dessinerLine(g, ns,15,15,15,40);
JdomSvg.EcrireText(g, ns,-10,70,Journaliste);
}
Exemple pour dessiner un cas d’utilisation

68
String[] data=new String[4];
data[0]="font-size";
data[1]="14";
data[2]="transform";
data[3]="translate("+transX+","+transY+")";
Element g = JdomSvg.ajouterNode(svg,//parent
ns,//namespace
"g",
data
);
Element ellipse=JdomSvg.dessinerEllipse(g,ns,Rx1,Ry1,Rx2,Ry2);
JdomSvg.ecrireText(g, ns, x ,y ,”Rediger Article”);
}
Exemple pour dessiner la flèche Généralisation
String[] data={ "stroke-linejoin","round"};
Element g= JdomSvg.ajouterNode(svg, ns , "g",data );
JdomSvg.dessinerLine(g, ns,
as.getX1(),
as.getY1()+10,
as.getX2(),
as.getY2()
);
int[] points={x1,y1,x2,y2,x3,y3};
JdomSvg.makePolygon(g, ns, points);

69
Le document SVG généré a partir de notre
programme
Figure 7 Diagramme de cas d'utilisation en SVG

70
Si on dessine avec les coordonnées de l’attribut « geometry » à partir
du fichier XMI on va avoir une image comme la figure dessous
Pour remédier à ce problème on va faire une translation , Par exemple
Pour dessiner le cas d’utilisation « rediger Article » on va prendre
Les coordonnées de l’attribut geometry : (810,250, 140,40)
Pour dessiner l’ellipse :
<g font-size="14" transform="translate(810,250)">
<ellipse fill="rgb(122,207,245)" stroke="black" stroke-width="1"
cx="70" cy="20" rx="70" ry="20" />
</g>
/*
Cx= rx/2= 140/2
Cy= rx/2=140/2
Rx= rx/2= 140/2
Ry= rx/2=140/2
*/

71
CHAPITRE 3 : TRANSFORMATION XMI
EN SVG AVEC ATL

72
3.1 Introduction
le langage transformation de modèles ATL (ATLAS Transformation
Language) est une réponse du groupe de recherche INRIA et LINA à
l’OMG MOF (Meta Object Facilities (MOF, 2003)) / QVT (Query View
Transformation (QVT, 2010)).
ATL est un langage de transformation de modèles dans le domaine de
l’IDM (Ingénierie Dirigée par les Modèles) ou MDE (Model-Driven
Engineering). Il fournit aux développeurs un moyen de spécifier la manière
de produire un certain nombre de modèles cibles à partir de modèles
sources.
3.2 Le langage ATL
3.2.1 Vue d’ensemble sur la transformation ATL
Une transformation de modèles définit la façon de générer un modèle Mb,
conforme au méta-modèle MMb, à partir du modèle Ma conforme au méta-
modèle MMa. Un élément majeur dans l'ingénierie des modèles est de
considérer, dans la mesure du possible, tous les objets traités comme des
modèles. La transformation de modèles doit être donc, lui-même, définie
comme un modèle (MMa2MMb.atl). Ce modèle de transformation doit
être conforme au méta-modèle qui définit la sémantique de transformation
de modèles (ATL).

73
Tous les méta-modèles doivent être conformes au méta-méta-modèle
considérée (Ecore).La figure suivante donne une vue d’ensemble sur la
transformation ATL.
Figure 8 Vue d’ensemble sur la transformation ATL
Le langage ATL offre différents types d'unités, qui sont définis dans des
fichiers d'extension « .atl » distincts. Ces unités sont le module permettant
de définir les opérations des transformations des modèles, des requêtes
ATL et des bibliothèques qui peuvent être importées par les différents
types d'unités ATL, y compris les autres bibliothèques. Un aperçu de ces
différents types d’unités est fourni dans la suite.

74
3.2.2.1 Les modules ATL
Un module ATL correspond à la transformation d’un ensemble de modèles
sources vers un ensemble de modèles cibles conformes à leurs méta-
modèles. Sa structure est composée d’une section d’en-tête, d’une section
d’importation facultative, d’un ensemble de helpers et d’un ensemble de
règles.
 La section d’en-tête
La section d’en-tête définit le nom du module de transformation ainsi que le
nom des variables correspondantes aux modèles sources et cibles. Elle
encode également le mode d’exécution du module qui peut être soit le
mode normal (défini par le mot clé from) ou le mode de raffinage (défini
par le mot clef refining). La syntaxe de la section d’en-tête est définie comme
suit :
 La section d’importation
Cette section est optionnelle, elle permet de déclarer les bibliothèques
ATL qui doivent être importées. La syntaxe de la section d'importation est
définie comme suit :
module MMa2MMb;
Create Mb : MMb [from|refining] Ma : MMa;
uses nom_bibliothèque;

75
 Les helpers
Les fonctions ATL sont appelées des helpers d’après le standard OCL
(Object Constraint Language (OCL)) sur le quel ATL se base. OCL définit
deux sortes de helpers : opération et attribut.
La syntaxe d’un helper opération est définie comme suit :
La syntaxe d’un helper attribut est définie comme suit :
Un helper peut être spécifié dans le contexte d’un type OCL (par
exemple String ou Integer) ou d’un type venant du méta-modèle source,
comme il peut être sans contexte dans ce cas il prendra le contexte par
défaut ; celui du module ATL. Les helpers peuvent utiliser la récursivité, de
plus, le helper opération peut être polymorphe.
Il existe une différence dans la sémantique d’exécution du helper
opération et du helper attribut, le premier est calculé à chaque appel tandis
que le deuxième est calculé une seule fois selon l’ordre de sa déclaration
dans le fichier ATL.
helper [context type_du_contexte]? def : nom_du_helper
(nom_paramètre1 :type_paramètre1 , nom_paramètre2 : type_paramètre2):
type_de_retour = expression;
helper [context type_du_contexte]? def : nom_du_helper : type_de_retour
= expression;

76
Si nous considérons l’exemple de la transformation du méta-modèle
Book vers le méta modèle Publication (ATL) présentés par la figure
suivante.
Figure 9 Méta-modèles Book et Publication
Nous pouvons définir un helper opération qui permet de calculer la somme
des pages du livre en fonction de la somme des pages de ces chapitres,
ceci se présente comme suit :
 Les règles
Le langage ATL est un langage hybride, il contient aussi bien les
constructions déclaratives que les constructions impératives. Le style
helper context Book!Book def : getSumPages() : Integer =
self.chapters->collect(f|f.nbPages).sum();

77
recommandé est le style déclaratif, cependant, pour faciliter les
constructions plus ou moins compliqués il est possible d’avoir recourt au
style impératif. Le langage comprend trois types de règles déclaratives et un
type de règles impératives.
 Les règles standards (Matched rules) : Ils constituent le noyau de la
transformation déclarative. Elles sont appelées une seule fois pour
chaque tuple correspondant à leurs motifs d’entrée trouvé dans
les modèles source. Elles permettent de spécifier, pour quels
éléments sources, les éléments cibles sont générés, ainsi que, la façon
dont ces éléments cibles sont initialisés. Ces règles ont le format
suivant
rule rule_name {
from
in_var : in_type [( condition )]?
[using { var1 : var_type1 = init_exp1;
...
varn : var_typen = init_expn;}]?
to
out_var1 : out_type1 (bindings1),
...
out_varn : out_typen (bindingsn)
[do { action_block }]?
}

78
Les variables de la section optionnelle using sont des variables locales.
Le bloc impératif (action block) contient une séquence d’instructions
impératives.
La règle de l’exemple précédent se traduit comme suit :
Dans cette règle les instances de la méta-classe Book sont traduites en des
instances de la méta-classe Publication en gardant le même titre et le même
nombre de pages. Ce dernier est calculé par le helper getSumPages pour les
instances de Book.
 Les règles paresseuses (lazy rule): Elles ressemblent aux règles
standards, à la différence qu’elles ne sont déclenchées que par
d’autres règles. Elles sont appliquées sur chaque tuple autant de fois
qu’elles sont référencées.
rule Book2Publication {
from b : Book!Book
to out : Publication!Publication (
title <- b.title,
nbPages <- b.getSumPages()
)}

79
 Les règles paresseuses uniques (unique lazy rule): Identiques aux
règles paresseuses non uniques, à la différence qu’elles sont
appliquées une unique fois pour chaque tuple.
 Les règles appelées (called rules) : Ils fournissent le style de
programmation impératif. Elles peuvent être vues comme des helper
particuliers. Elles doivent être déclenchées explicitement. Exemple de
règle appelée:
 Les modes d’exécution des modules
 Le moteur d'exécution ATL définit deux modes d'exécution pour
les différents modules ATL.
 Le mode normal : C’est le mode d'exécution par défaut, il faut
spécifier explicitement la manière dont les éléments de modèle cible
doivent être générés à partir des éléments du modèle source. Ce
mode est spécifié par le mot clef from dans l’en-tête. Il est utilisé
entrypoint rule NewPublication (t: String, n: Integer)
{
to p : Publication!Publication (
title <- t
)
do { p.nbPages <- n
}
}

80
dans le cas d’une transformation exogène : le méta modèle source
et cible sont différents.
 Le mode de raffinage : Dans ce mode d’exécution la conception de
la transformation qui vise à dupliquer le modèle source avec
seulement quelques modifications. Concevoir cette transformation
dans le mode d'exécution par défaut nécessite la spécification des
règles, aussi bien pour les éléments qui vont être modifiés, que
ceux ne vont de être modifiés. Ce mode est spécifié par le mot clef
refining dans l’en-tête. Il est utilisé dans le cas d’une transformation
endogène : un même méta-modèle source et cible.
3.2.2.2 Les requêtes ATL
Une requête ATL peut être considérée comme une opération qui calcule une
valeur primitive d'un ensemble de modèles de source. Ces règles ont le
format suivant :
query query_name = exp;
3.2.2.3 Les bibliothèques ATL
Une bibliothèque ATL permet de définir un ensemble de helpers qui
peuvent être appelés à partir des différentes unités ATL. Ce fichier est défini
par l’en-tête :
library nom_bib;

81
3.2.3 Installation Eclipse
Téléchargez l’IDE environnement de développement intégré Eclipse depuis
l’adresse suivante : http://www.eclipse.org/downloads/
Après l’installation d’Eclipse , il faut ajouter les plugins : ATL et GMF

83
Pour S’assurer de l’ajout des Plugins, allez sur :
« File » -> « new » -> « Other » :
Et vérifiez si les dossiers « ATL » et « Graphical Modeling Framework »
existent .

84
Vous trouvez dans ce site des bons exemples concernant les transformations
ATL (le code source et la documentation).
http://www.eclipse.org/atl/atlTransformations/
3.3 Votre premier projet ATL :
Objectifs
 Créer un projet ATL
 Structurer votre projet ATL
 créer un Meta-Model ecore (ajouter une classe , un
attribut à une classe, marquer une classe abstraite,
faire une association de type composition)
 Créer un fichier ATL (Model 2 Model )
 Créer un fichier ATL (Model 2 Text)
 Exécuter un fichier ATL)

85
1. Créer un projet ATL New -> Other
Donner un nom à votre Projet ATL, puis cliquer sur Finish.
2. Pour bien structurer votre projet ; créer trois dossiers

86
Transformations : les fichiers ATL.
Metamodels : les fichiers Metamodels que vous avez besoin dans ce projet.
Models : les fichiers Models.
3. Créer un Méta-Model nommé SVG (c’est un fichier ecore)

87
Vous avez deux méthodes pour manipuler votre méta-modèle :
Méthode 1 : avec Sample Ecore Model Editor
 Ajouter une classe à un Méta-Modèle




 Ajouter un attribut à une classe
Il a besoin d’un nom, un type et la multiplicité
Si Properties ne s’affiche pas ; aller à windows -> show View -> other ->
tapez properties -> cliquer sur Ok.

88
Méthode 2 :Ecore Diagram Editing
On va vous passer maintenant au mode graphique
 Marquer une classe abstraite :
 Créer une association de type composition (one to many)
- Créer par exemple d’autre classe qui s’appelle shape
- Cliquer sur EReference

89
4. Créer un Fichier ATL (Model to Model)

90
5) Créer un fichier ATL (Model To Text)

91
6) Exécuter un fichier ATL

92
3.4 Transformation du diagramme avec
ATL :
Le Model XML généré par Visual Paradigm donne plus de détails pour
dessiner un diagramme Uml avec SVG, pour cette raison on a choisi XML.
Dans ce chapitre on vous montrer la transformation De XML vers SVG avec
ATL.
Les étapes à suivre pour réaliser ce projet
1) Créer les Méta Modèles (SVG , Diagramme Use Case).
2) Un exemple de Modèle de diagramme de use case au format xml
3) Définir Les transformations ATL.
4) Exécution de fichiers ATL
Voici un schéma explicatif, qui montre les trois étapes pour transformer un
Model UML de diagramme de use case à un fichier Text d’extension .svg ).

93
Figure 10 Transformations ATL (UML à Text)
- Dans ce projet, on a traité les deux cas d’ATL Model to Model et Model
to Text.
- Dans le figure ci-dessus ; Les fichiers Models ont l’extension xmi ou
bien xml.
- Le fichier Text a le format svg.

94
3.4.1 Définir Les méta-Modèles
 Méta-Modèle de Diagramme de Use case
Vous pouvez baser aux spécifications de Méta-Modèle d’uml dans le site
officiel d’omg : http://www.omg.org/spec/#M&M
Sinon vous pouvez faire votre propre Méta-Modèle , en se basant sur
plusieurs modèles de diagramme de use case généré par le logiciel Visual
Paradigm.
Dans Notre projet nous étions basées à la deuxième méthode . (Voir figure
12 et 13 ci-dessous).
 Méta-Modèle de SVG :
Vous pouvez baser au site officiel du standard svg
http://www.w3.org/TR/SVG/ . (Voir figure 11 ci-dessous).
 Méta-Modèle de XML :
Il est téléchargeable (vous pouvez le trouver dans le site des exemples
de ATL transformations, qu’on a déjà cité). (Voir figure 14 ci-dessous).

95
Figure 11 Méta-Modèle SVG

96
Figure 12 Méta-Modèle Diagramme Use Case

97
Figure 13 Méta-
Modèle
Diagramme Use
Case (zoomé)

98
Figure 14 Méta-Modèle XML
3.4.2 Un exemple de Modèle de diagramme de use
case au format xml
Après avoir définir tous le méta-Modèles qu’on aura besoin ; maintenant on a
besoin d’un exemple de Modèle de Diagramme Use Case .
Pour bien savoir l’entête que vous devez mettre dans le fichier xml généré
par le logiciel Visual Paradigm vous devez suivre ces étapes :

99
Un fichier project.xmi sera créé.
Dans notre cas, voici ce qui est généré

100
Voilà l’exemple de Modèle de Diagramme de Use Case généré par Visual
Paradigm.
Après on ajoute à la balise project , les autres attributs générés

101
3.4.3 Définir Les transformations ATL.
Maintenant, C’est le moment pour passer vers les transformations
 Transformation UML to SVG :
Figure 15 Transformation Uml 2 SVG
Cette Schéma ci-dessus montre les exemples de transformations d’UMl vers
SVG.
Par exemple chaque Généralisation dans le Modele de diagramme de Use
case sera transformer en SVG par une Line et un Polygon.

102
Exemple de code Source qui montre la transformation d’un UseCase de Uml
vers l’Ellipse et Text de SVG
Figure 16 Exemple de transformation UseCaseUml2EllipseSVG
 Transformation de SVG 2 XML
Pourquoi on a pensé d’ajouter les 2 dernières transformations ?
Il y a deux problèmes que nous avons rencontrés dans la 1ère transformation.
Elle ne permet pas d’afficher la valeur de text par exemple <text> bonjour
</text>.

103
Le message bonjour ne peut pas être affiché par la 1er transformation, mais
avec XMl il y a une classe qui s’appelle Text , qui permet par un traitement
dans la 3eme transformation d’écrire le message .
Le 2ème problème il y a des attributs qui contient – ou _ qui génère une
erreur de compilation dans un fichier ATL, par exemple l’attribut stroke-
width. Pour éviter ce problème on doit nommer cet attribut par un autre
nom dans le meta Modele de SVG , et dans la transformation de SVG 2 Xml on
va le nommer comme on veut.
. Exemples de transformations possibles de
Meta-Model SVG vers le Meta-Model XML
Figure 17 Transformation SVG 2 XML

104
Dans le Shéma au-dessus , il montre que SVG sera le Root du fichier Xml
généré.
Ainsi chaque classe, son correspandant en XML est un Element.
Chaque attribut d’une classe de SVG, sera remplacer par Attribute en XML.
Et chaque value de la classe Text de SVG , son correspandant en XML est un
Text .
 L’image ci-dessous montre le code source de la transformation de la
classe Text de SVG vers la classe Element de XML (1) ,et l’attribut de la
classe Text de SVG vers la classe Text de XML(2).

105
Figure 18 TextSvg2ElementXML

106
 Transformation de XML to Text

107
3.4.4 Exécution des Fichiers ATL
Voici l’arborescence de projet
Il faut exécuter dans l’ordre :
-Le fichier ATL UML2SVG
-Le fichier ATL SVG2XML
-Le fichier ATL XML2TEXT

108
 Exécuter le fichier UML2SVG
Génération du fichier svgModel.xml

109
 Exécuter le fichier SVG2XML
Génération du fichier svgModel_XML.xml

110
 Exécuter le fichier XML2TEXT
Génération du fichier
DiagramUseCase.svg

112
Figure 19 Fichier SVG généré avec ATL

113
Figure 20 Fichier SVG généré avec ATL zoomé

Rapport XMI To SVG

Recommandé

Recommandé

Contenu connexe

Similaire à Rapport XMI To SVG

Similaire à Rapport XMI To SVG (20)

Plus de Soukaina Boujadi

Plus de Soukaina Boujadi (15)

Dernier

Dernier (19)

Rapport XMI To SVG