Rapport - Projet Transformation d'un fichier XMI (XML) 2 SVG (JAVA et ATL)

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/

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) {

// TODO Auto-generated catch block e.printStackTrace();

} 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) { // TODO Auto-generated catch block e.printStackTrace(); } }

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); iteratorPropriete=Lpropriete.iterator(); } } 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) { iteratorElements=Lelements.iterator(); // iteratorProprieteU=LproprieteU.iterator(); parser(doc); //les cas d'utilisation do { element = (Element)iteratorElements.next(); 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 { propriete=(Element)iteratorPropriete.next(); 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])); } }while(iteratorPropriete.hasNext()); LUseCase.add(u); iteratorPropriete=Lpropriete.iterator(); } } while(iteratorElements.hasNext()); return LUseCase; }

56

La Fonction Association récupère la liste des Association, dans le fichier

XMI.

public ArrayList<Association> Associations(Document doc) { iteratorElements=Lelements.iterator(); iteratorPropriete=Lpropriete.iterator(); int x1=0,x2=0,y1=0,y2=0; String type=null; parser(doc); //les cas d'utilisation do { element = (Element)iteratorElements.next(); if(element.getAttributeValue("type",xmiNS).equals("uml:Association")) { Association a=new Association(); a.setId(element.getAttributeValue("id", xmiNS)); Lpropriete=diagram.getChildren("DiagramElement", umlNS); do { propriete=(Element)iteratorPropriete.next(); 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]); x2=Integer.parseInt(point2[0]); y2=Integer.parseInt(point2[1]); type="Association"; } }while(iteratorPropriete.hasNext()); a.setX1(x1); a.setY1(y1); a.setX2(x2); a.setY2(y2); a.setType(type); LAssociation.add(a); iteratorPropriete=Lpropriete.iterator(); } } while(iteratorElements.hasNext()); 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> Lpropriete=diagram.getChildren("DiagramElement", umlNS); for (Element item : Lpropriete) { if(item.getAttributeValue("preferredShapeType").equals("Generalization") && item.getAttributeValue("subject").equals(general)) { Association a=new Association(); String geometry=item.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]); x2=Integer.parseInt(point2[0]); y2=Integer.parseInt(point2[1]); 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); iteratorPropriete=Lpropriete.iterator(); do { Association a=new Association(); propriete=(Element)iteratorPropriete.next();

60

if(propriete.getAttributeValue("preferredShapeType").equals("Extend")) { 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]); x2=Integer.parseInt(point2[0]); y2=Integer.parseInt(point2[1]); type="Extend"; a.setX1(x1); a.setY1(y1); a.setX2(x2); a.setY2(y2); a.setType(type); LExtension.add(a); } }while(iteratorPropriete.hasNext()); iteratorPropriete=Lpropriete.iterator(); 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.dessinerLine(g, ns,0,24,30,24); JdomSvg.dessinerLine(g, ns,15,40,0,60); JdomSvg.dessinerLine(g, ns,15,40,30,60); 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

http://www.eclipse.org/downloads/

82

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)

http://www.eclipse.org/atl/atlTransformations/

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).

http://www.omg.org/spec/#M&M

http://www.w3.org/TR/SVG/

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

111

112

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

113

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