conversion de modèles uml en format de graphes scolas...

Conversion de modèles UML en format de graphes

Scolas Laurent2ème licence informatique

Université de Mons-Hainaut

Directeur de mémoire : Tom MensRapporteurs : Mr Jef Wijsen, Mr Stefan Beauport

Remerciements

En préambule de ce mémoire, je souhaite adresser ici tous mes remerciements aux personnesqui m’ont apporté leur aide et qui ont ainsi contribué à la réalisation de ce mémoire.

Je tiens tout d’abord à remercier Monsieur Tom Mens, directeur de ce mémoire pour son aide,ses conseils et le temps qu’il a bien voulu me consacrer durant l’élaboration de ce mémoire. Jevoudrais aussi remercier mes amis pour leur soutien moral tout au long de l’élaboration de cemémoire.

1

Table des matières

1 Introduction 51.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Démarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 UML et formats de fichiers 92.1 La notation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Notion d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Les méthodes objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.4 Exemples de diagrammes UML . . . . . . . . . . . . . . . . . . . . . . 11

2.2 XML, XMI et GGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 XMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 GGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Choix d’un outil de modélisation 183.1 Critères de sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Format d’exportation/importation . . . . . . . . . . . . . . . . . . . . . 183.1.2 Version UML utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.3 Fichiers de RationalRose . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Tableau comparatif d’outils de modélisation . . . . . . . . . . . . . . . . . . . . 193.3 Visual Paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Choix d’un outil de transformation des modèles 214.1 Quelques exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Principe de transformation de graphes . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.1 Negative Application Condition . . . . . . . . . . . . . . . . . . . . . . 284.2.2 Type graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 AGG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4 Alternatives à AGG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2

5 Choix d’un outil de conversion 305.1 Description du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3.1 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3.2 Transformation d’un document XML avec des règles de transformation de

graphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4 Exemples de requêtes XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.4.1 Déclaration de règle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.4.2 Déclenchement de règles avec xsl :apply-templates . . . . . . . . . . . . 345.4.3 Sélection de la valeur d’un attribut . . . . . . . . . . . . . . . . . . . . . 345.4.4 Les conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Conversion du métamodèle 376.1 Correspondance Métamodèle - Type graph . . . . . . . . . . . . . . . . . . . . . 376.2 Processus de conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.3 Code XMI du métamodèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3.1 Les balises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.3.2 Les attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.4 Structure du fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.4.1 Première partie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.4.2 Seconde partie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4.3 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.5 Structure du fichier GGX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.6 Règles de conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.7 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Conversion d’un fichier XMI 487.1 Processus de conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.2 Un exemple simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.3 Exemple complexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.4 Processus itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.5 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.5.1 Balises uniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.5.2 Attributs des balises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8 Conversion d’un fichier GGX 558.1 Processus de conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2 Exemple simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.3 Exemple complexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.4 Processus itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3

8.5 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

9 Validation des résulats 609.1 Diagrammes d’états-transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.2 Validation de la feuille de conversion xmi2ggx . . . . . . . . . . . . . . . . . . . 659.3 Validation de la feuille de conversion ggx2xmi . . . . . . . . . . . . . . . . . . . 65

10 Génération de règles de construction d’un graphe 7110.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7110.2 Génération de règles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7110.3 Structure de la feuille de génération . . . . . . . . . . . . . . . . . . . . . . . . 7210.4 Structure d’une règle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7310.5 Méthode de recherche des attributs des noeuds . . . . . . . . . . . . . . . . . . . 7310.6 Génération des NACs pour les règles de type Add . . . . . . . . . . . . . . . . . 7410.7 Génération des NACs pour les règles de type Del . . . . . . . . . . . . . . . . . 7510.8 Le Dangling condition et les règles injectives . . . . . . . . . . . . . . . . . . . 7710.9 Validation des règles de construction . . . . . . . . . . . . . . . . . . . . . . . . 80

11 Conclusion 8311.1 Résumé et contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8311.2 Apports personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8411.3 Travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4

Chapitre 1

Introduction

1.1 Contexte

Un modèle, en informatique, a pour objectif de structurer les données. C’est une abstraction dequelque chose de réel qui permet de comprendre avant de construire, ou de retrouver les informa-tions nécessaires pour effectuer des entretiens, des modifications et des extensions. Ces modèlessont appliqués sur des programmes, des logiciels. Par exemple, nous pourrions voir le code del’application comme un premier niveau d’abstraction, tandis que le modèle lié à ce code repré-sente un deuxième niveau d’abstraction qui est plus élevé.

L’ingénierie dirigée par les modèles (en anglais : Model Driven Engineering) est le domaine del’informatique mettant à disposition des outils, des concepts et des langages pour créer et trans-former des modèles. La modélisation est l’utilisation efficace d’une représentation simplifiée d’unaspect de la réalité. Le but de l’ingénierie dirigée par les modèles est de développer, maintenir etfaire évoluer des logiciels complexes en s’élevant du niveau du code à un niveau d’abstraction plusélevé que le code. Ce but peut être atteint par la transformation des modèles.Pour pouvoir être transformés, ces modèles doivent être exprimés dans un langage de modélisa-tion. Le langage UML [6, 19] (en anglais : Unified Modeling Language) est le langage de modé-lisation le plus couramment utilisé. Il s’agit d’un langage visuel de modélisation d’une application.

Pour créer un modèle, nous utilisons un outil de modélisation UML. Mais bien souvent, ces ou-tils de modélisation ne supportent pas l’évolution d’un logiciel. Nous avons besoin de meilleursoutils, de meilleurs formalismes pour par exemple gérer les incohérences dans les modèles, pourappliquer un refactoring sur les modèles ou encore fusionner les modèles, etc. Un problème d’in-cohérence est par exemple l’appel d’une méthode qui n’existe pas.

Un exemple peut être trouvé à la figure 1.1 [17]. La méthode selectReverse n’existe dans au-cune des classes du diagramme de classes lié au diagramme d’états-transitions, ce qui crée uneincohérence.

5

FIG. 1.1 – Incohérence : La méthode selectReverse n’existe pas

Les incohérences dans les modèles sont inévitables. Ces dernières peuvent venir d’un mo-dèle qui n’a pas été bien compris, d’un modèle incomplet, d’un modèle complexe avec beaucoupd’inter-dépendances. Les types d’incohérences sont nombreux, cela peut aller d’incohérences syn-taxiques ou sémantiques, à des problèmes de modèles incomplets.

Notre mémoire se situe dans le contexte de la gestion d’incohérences de modèles. Le processuspour corriger les inconsistances dans les modèles est montré à la figure 1.2 [17, 33].

FIG. 1.2 – Processus de correction des inconsistances

Le processus démarre avec un modèle UML, contenant des incohérences. Ensuite ces dernièressont détectées par des règles de détection. Une des incohérences doit être sélectionnée pour êtrecorrigée avec une ou plusieurs règles de résolution. Il s’agit d’un processus itératif car lorsqu’uneincohérence est "réparée", elle peut en provoquer de nouvelles.

6

Pour que ces incohérences soient détectées, nous avons besoin d’un outil qui va trouver ces in-cohérences. D’un côté nous avons notre outil de modélisation qui nous permet de réaliser desmodèles et d’un autre côté nous avons notre outil de détection des incohérences. La figure 1.3résume le procédé. Un modèle est créé dans l’outil de modélisation, c’est la première versiondu modèle. Ce modèle est exporté vers l’outil de détection dans un format spécifique à cet outil,toujours dans sa première version. Une fois le travail de l’outil de détection et de résolution desincohérences accompli, le diagramme en est à sa deuxième version et est importé par l’outil demodélisation dans le format qui lui est propre.

FIG. 1.3 – Processus

Une alternative à ce procédé consiste en une synchronisation directe entre l’outil de modé-lisation et l’outil de transformation, chaque changement dans le premier outil étant suivi par unchangement dans le second, et vice versa. La raison pour laquelle nous n’avons pas retenu ce choixest qu’il n’existe pas encore1 d’outils de modélisation supportant le UML 2.0 ET en même tempsla transformation de modèles. Un outil se rapprochant de cette description est l’outil MOFLON[27]. Il ne s’agit pas d’un outil de modélisation mais il permet d’importer des modèles UML poureffectuer des transformations. Cependant, MOFLON a été lancé entre les mois de Décembre 2006et de Janvier 2007, nous n’avons donc pas retenu ce choix.

Dans ce mémoire, nous nous concentrerons sur la première solution, c’est-à-dire que nous nousconcentrerons sur les phases d’importations et d’exportations entre l’outil de modélisation et l’ou-til d’analyse et de transformation, en faisant en sorte que le format de l’outil de modélisationdevienne compatible avec l’outil d’analyse et de transformation.

1.2 Démarche

Pour pouvoir procéder à une exportation et à une importation, il nous faut choisir un outil demodélisation UML. Il nous faudra également choisir un outil de transformation. L’outil de modé-lisation devra pouvoir exporter le modèle dans un format assez générique, c’est-à-dire, réutilisablepour un autre outil. Nous devrons comprendre comment l’outil exporte le modèle, et rendre ce for-mat compatible avec le format de l’outil de détection, et donc nous devrons également comprendre

1Au moment de la rédaction de ce mémoire

7

comment l’outil de détection représente les modèles. Puisque les formats utilisés par l’outil de mo-délisation et l’outil de transformation sont différents, il nous faudra trouver un moyen de convertirle premier format dans le deuxième format. La phase d’importation consistera en la conversioninverse, c’est-à-dire du deuxième format au premier format. Enfin, un dernier travail consistera enl’élaboration de plusieurs règles de construction qui permettront de créer un modèle correct.

8

Chapitre 2

UML et formats de fichiers

Ce chapitre présente les différents formats de fichiers, les différents langages et concepts utili-sés au cours de ce mémoire.

2.1 La notation UML

Plusieurs notions sont nécessaires pour comprendre la notation UML.

2.1.1 Notion d’objets

La programmation orientée objet consiste à modéliser un ensemble d’éléments d’une partiedu monde réel en un ensemble d’entités informatiques. Ces entités informatiques sont appeléesobjets. Il s’agit de données informatiques regroupant les principales caractéristiques des élémentsdu monde réel ou virtuel (taille, couleur, ...) mais aussi de comportements (actions entre objets). Ladifficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d’objets,d’entités ayant une existence matérielle (chien, voiture, ampoule, ...) ou bien virtuelle (sécuritésociale, temps, ...). Un exemple est fourni à la figure 2.1. Il s’agit d’un objet voiture, on y retrouvecertaines caractéristiques d’une voiture, ainsi que les différentes actions qu’il est possible de faire.

2.1.2 Les méthodes objets

La modélisation objet consiste à créer une représentation informatique des éléments du monderéel auxquels on s’intéresse, sans se préoccuper de l’implémentation, ce qui signifie indépendam-ment d’un langage de programmation. Il s’agit donc de déterminer les objets présents et d’isolerleurs données et les fonctions qui les utilisent. Pour se faire, des méthodes, des processus métho-dologiques ont été mis au point. Au fil des années le nombre de ces méthodes n’a cessé de croître,si bien qu’en 1994 il existait plus de cinquante méthodes objets.

9

FIG. 2.1 – Objet voiture

2.1.3 UML

Parmi le nombre de ces méthodes, seulement trois se sont démarquées.

• La méthode OMT de Rumbaugh• La méthode BOOCH’93 de Booch• La méthode OOSE de Jacobson (Object Oriented Software Engineering)

En 1994, Rumbaugh et Booch unissent leurs efforts pour mettre au point la méthode uni-fiée(Unified Method 0.8), incorporant les avantages de chacune des méthodes précédentes. Laméthode unifiée à partir de la version 1.0 devient UML (Unified Modeling Language), une nota-tion universelle pour la modélisation objet.

UML est un moyen d’exprimer des modèles objet en faisant abstraction de leur implémentation. Lelangage UML 2.0 comporte treize types de diagrammes. Pour bien comprendre ces diagrammes,il peut être utile de les montrer de façon hiérarchique.

Il y a les diagrammes de structure (Structure diagrams) qui mettent l’accent sur ce que les chosesdoivent être dans le système qui est en train d’être modelisé et qui regroupent :

• Les diagrammes de classes• Les diagrammes de composants• Les diagrammes de structures composites• Les diagrammes de déploiement• Les diagrammes d’objets• Les diagrammes de paquets

10

Les diagrammes de comportement (Behavior diagrams) représentent ce qui se passe dans lesystème et qui regroupent :

• Les diagrammes d’activité• Les diagrammes d’états-transitions• Les diagrammes de cas d’utilisation

Les diagrammes d’interaction (Interaction diagrams) représentent les données échangées parmiles objets du système et qui regroupent :

• Les diagrammes de communication• Les diagrammes global d’interaction• Les diagrammes de séquence• Les diagrammes de temps

Ces diagrammes sont relativement différents les uns des autres. Pour que ces diagrammessoient cohérents, UML se repose sur un métamodèle, un modèle de plus haut niveau qui définitles éléments de UML (les concepts utilisables) et leur sémantique (leur signification et leur moded’utilisation), un de ces métamodèles est représenté à la figure 2.2. La version 2 de UML est vali-dée par l’OMG. De la même façon, les diagrammes que nous allons exporter au format de l’outilde transformation devront correspondre à un métamodèle de ce format. La figure 2.3 représente lasituation.

2.1.4 Exemples de diagrammes UML

Les diagrammes UML les plus connus sont sans doute les diagrammes de classes. Il s’agitd’un diagramme qui représente les classes et les interfaces d’un système ainsi que les relationsentre celles-ci. Ces relations sont par exemple l’héritage, l’association, la multiplicité ...

Le diagramme à la figure 2.4 représente par exemple un diagramme de classe d’une voiture.Une personne possède une voiture qui contient un moteur, qui lui-même contient une boîte devitesse. Cette boîte de vitesse peut être soit manuelle, soit automatique. Bien que ces boîtes soientdifférentes, il existe certaines similitudes entre elles qui sont reprises dans la classe Gear. C’estpourquoi les classes Automatic Gear et Hand Gear héritent de la classe Gear.

11

FIG. 2.2 – Métamodèle des diagrammes d’états-transitions

Dans notre mémoire, nous nous sommes intéressés aux diagrammes d’états-transitions. Cesdiagrammes présentent la vue dynamique d’un système. Ils sont particulièrement importants dansla modélisation du comportement d’une classe ou d’une interface. La figure 2.5 présente un dia-gramme d’états-transitions. Il s’agit des actions qui sont entreprises lors d’un changement devitesse dans une voiture. Nous avons choisis de nous concentrer sur les diagrammes d’états-transitions car peu de travaux sont entrepris sur ces derniers. Ils sont pourtant importants en cequi concerne la dynamique d’un système. Il est à noter que la démarche technique de notre mé-moire ne se limite pas seulement à ces diagrammes. En effet, notre démarche pourrait être reprisepour travailler sur d’autres diagrammes.

12

FIG. 2.3 – Transformation d’un modèle UML conforme à un métamodèle

FIG. 2.4 – Diagramme de classes d’une voiture

13

FIG. 2.5 – Diagramme d’états-transitions

2.2 XML, XMI et GGX

Dans le cadre de ce mémoire nous utilisons des standards basés sur XML car les outils demodélisation s’échangent des fichiers basés sur XML. Il en va de même pour les outils de trans-formation de modèles.

2.2.1 XML

XML (Extensible Markup Language), est le standard soutenu par le W3C [7, 11] pour le ba-lisage de documents [11, 9]. L’objectif initial de XML est de faciliter l’échange automatisé decontenus entre systèmes d’informations hétérogènes (interopérabilité), notamment sur internet. Ildéfinit une syntaxe générique utilisée pour formater les données avec des balises simples et com-préhensibles par l’homme. Ce format est suffisamment souple pour être adapté à des contextesaussi variés que les sites web, l’échange de données électroniques, les dessins vectoriels, la généa-logie et bien d’autres.

XML permet la représentation des données sous la forme d’un arbre. Pour mieux comprendrele concept, voici la représentation en XML d’une personne s’appellant Alan Turing et possédantplusieurs professions.

1 2 <nom>3 <prenom>Alan< / prenom>4 < nom_fami l l e > Tu r in g < / nom_fami l l e >5 < / nom>6 i n f o r m a t i c i e n 7 m a t h é m a t i c i e n 8 c r y p t o g r a p h e 9 

14

2.2.2 XMIXMI (XML Metadata Interchange) est une forme encapsulée de balise XML. XMI est un stan-

dard créé par l’OMG pour l’échange d’informations de métadonnées UML basé sur XML. Il est leplus souvent utilisé comme standard d’échange entre différents outils de modélisation [8]. XMI sefonde sur trois standards : XML, UML et MOF1. XMI est un moyen de sauver de façon standarddes modèles UML en XML. De façon à ce que les modèles soient correctements retranscrits enXML, il faut que les documents se réfèrent à un document DTD2.

Voici la feuille DTD associée au code XMI représentant Alan Turing.

< !DOCTYPE xmi:XMI [<!ELEMENT o w n e d A t t r i b u t e EMPTY>< !ATTLIST o w n e d A t t r i b u t e

x m i : i d CDATA " "name CDATA #REQUIREDv a l u e CDATA #REQUIREDx m i : t y p e CDATA #REQUIRED>

< !ELEMENT ownedMember ( o w n e d A t t r i b u t e )+>< !ATTLIST ownedMember

x m i : i d CDATA #REQUIREDname CDATA #REQUIREDx m i : t y p e CDATA #REQUIRED>

< !ELEMENT xmi:XMI ( ownedMember ) >< !ATTLIST xmi:XMI

x m i : v e r s i o n CDATA #REQUIREDxmlns :uml CDATA #REQUIREDxmlns :xmi CDATA #REQUIRED>

] >

Un document XMI est donc constitué de deux parties : un document XML d’éléments tagués,et un document DTD qui définit les tags que le document XMI peut utiliser ainsi que la structurede ce document. Le document DTD peut être vu comme un plan de construction qui s’assure quele document XMI reste conforme à un certain standard

Voici le code XML représentant Alan Turing, en XMI.

1 <xmi:XMI x m i : v e r s i o n =" 2 . 1 ">2 <ownedMember x m i : i d ="OV. q i j f u u s e f " name=" p e r s o n n e " x m i : t y p e =" u m l : C l a s s ">3 < o w n e d A t t r i b u t e x m i : i d ="OY. juhahzdnd " name=" prenom " v a l u e =" Alan "4 x m i : t y p e =" u m l : P r o p e r t y " / >5 < o w n e d A t t r i b u t e x m i : i d ="OV. q f o f h f o s f " name=" nom_fami l l e " v a l u e =" T ur in g "6 x m i : t y p e =" u m l : P r o p e r t y " / >7 < o w n e d A t t r i b u t e name=" p r o f e s s i o n " v a l u e =" i n f o r m a t i c i e n " x m i : t y p e =" u m l : P r o p e r t y " / >8 < o w n e d A t t r i b u t e name=" p r o f e s s i o n " v a l u e =" m a t h é m a t i c i e n " x m i : t y p e =" u m l : P r o p e r t y " / >9 < o w n e d A t t r i b u t e name=" p r o f e s s i o n " v a l u e =" c r y p t o g r a p h e " x m i : t y p e =" u m l : P r o p e r t y " / >

10 < / ownedMember>11 < / xmi:XMI>

1Structure générale d’intégration pour tous les métas modèles, le MOF (Meta-Object Facility) fournissant un langagepour définir les métas modèles et aboutissant à un méta-méta-modèle.

2Document Type Definition.

15

2.2.3 GGX

Les fichiers GGX (Grammar Graph eXchange) sont stockés dans un format XML. L’outil detransformation de graphes AGG manipule des fichiers au format GGX. AGG permet de créer unensemble de règles de transformation de graphes que nous appelons grammaire. Cette grammaireest sauvée grâce au format GGX. Ci-dessous se trouve un exemple de fichier GGX qui représentela personne Alan Turing.

1 <Document v e r s i o n =" 1 . 0 ">2 <Types>3 <NodeType ID=" I2 " name=" P e r s o n n e%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : ">4 < A t t r T y p e ID=" I3 " a t t r n a m e =" prenom " typename=" S t r i n g " v i s i b l e =" t r u e " / >5 < A t t r T y p e ID=" I4 " a t t r n a m e =" nom_fami l l e " typename=" S t r i n g " v i s i b l e =" t r u e " / >6 < / NodeType>7 <NodeType ID=" I5 " name=" P r o f e s s i o n%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : ">8 < A t t r T y p e ID=" I6 " a t t r n a m e ="nom" typename=" S t r i n g " v i s i b l e =" t r u e " / >9 < / NodeType>

10 <EdgeType ID=" I7 " name=" t r a v a i l%:SOLID_LINE:java . awt . Co lo r [ r =0 , g =0 , b =0] : : [EDGE] : " / >11 < / Types>12 <Graph ID=" I8 " name=" AlanTur ing ">13 <Node ID=" I9 " t y p e =" I2 ">14 < A t t r i b u t e c o n s t a n t =" t r u e " t y p e =" I3 ">15 <Value >16 < j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 5 . 0 ">17 < s t r i n g >Alan< / s t r i n g >18 < / j a v a >19 < / Value >20 < / A t t r i b u t e >21 < A t t r i b u t e c o n s t a n t =" t r u e " t y p e =" I4 ">22 <Value >23 < j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 5 . 0 ">24 < s t r i n g > Tur in g < / s t r i n g >25 < / j a v a >26 < / Value >27 < / A t t r i b u t e >28 <NodeLayout X=" 295 " Y=" 87 " / >29 < a d d i t i o n a l L a y o u t age=" 0 " f o r c e =" 10 " f r o z e n =" f a l s e " zone=" 50 " / >30 < / Node>31 <Node ID=" I10 " t y p e =" I5 ">32 < A t t r i b u t e c o n s t a n t =" t r u e " t y p e =" I6 ">33 <Value >34 < j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 5 . 0 ">35 < s t r i n g > I n f o r m a t i c i e n < / s t r i n g >36 < / j a v a >37 < / Value >38 < / A t t r i b u t e >39 < / Node>40 <Node ID=" I11 " t y p e =" I5 ">41 < A t t r i b u t e c o n s t a n t =" t r u e " t y p e =" I6 ">42 <Value >43 < j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 5 . 0 ">44 < s t r i n g > M a t h é m a t i c i e n < / s t r i n g >45 < / j a v a >46 < / Value >47 < / A t t r i b u t e >48 < / Node>49 <Node ID=" I12 " t y p e =" I5 ">

16

50 < A t t r i b u t e c o n s t a n t =" t r u e " t y p e =" I6 ">51 <Value >52 < j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 5 . 0 ">53 < s t r i n g > C r y p t o g r a p h e < / s t r i n g >54 < / j a v a >55 < / Value >56 < / A t t r i b u t e >57 < / Node>58 < / Graph>59 < / Document>

17

Chapitre 3

Choix d’un outil de modélisation

Le choix d’un outil de modélisation doit répondre à plusieurs critères, c’est pourquoi nousregarderons plusieurs outils avant de nous décider.

3.1 Critères de sélection

Plusieurs critères de sélection se doivent d’être respectés.

3.1.1 Format d’exportation/importation

Le choix de l’outil de modélisation est motivé par le format d’exportation de celui-ci. En ef-fet, il faut que ce format soit assez indépendant de l’outil car si ce dernier disparaissait pour uneraison ou pour une autre, notre travail aurait été perdu. Il nous faut donc choisir un format d’ex-portation/importation standardisé, notamment XMI, de préférence la dernière version de celui-ci1.L’outil doit donc respecter ce standard.

La plupart des outils de modélisation comme ArgoUML [24], Poseidon [28], Visual Paradigm[31], BOUML [18] permettent d’exporter les diagrammes UML au format XMI. Cependant, tousles outils de modélisation n’exportent pas les diagrammes dans la dernière version de XMI. C’estle cas pour ArgoUML [24] qui exporte ses diagrammes au format XMI 1.0. Outre le fait qu’il soitpréférable de travailler avec la dernière version d’un produit, l’utilisation de XMI 1.0 peut poserdes problèmes. En effet, XMI 1.0 ne permet pas de représenter tous les concepts des diagrammesUML 2.0, or nous souhaitons travailler avec UML 2.0.

1XMI 2.1 lors de la rédaction de ce mémoire.

18

3.1.2 Version UML utilisée

Outre le format d’exportation/importation, la version de UML utilisée par l’outil était aussiimportante. En effet, certains outils de modélisation ne travaillent pas encore avec la dernièreversion de UML.

3.1.3 Fichiers de RationalRose

Plusieurs outils de modélisation permettent de travailler avec la dernière version de UML etla dernière version de XMI. Cependant, nous avons rencontrés une contrainte supplémentaire. Eneffet, notre outil doit être capable d’ouvrir les fichiers de IBM RationalRose [29] car le méta-modèle auquel nous devons nous référencer n’est disponible2 qu’au format propriétaire de IBMRationalRose. Or, très peu d’outils, et en particulier les outils sous licence libre, peuvent lire cesfichiers.

3.2 Tableau comparatif d’outils de modélisation

Le tableau 3.1 montre différents outils de modélisation avec la version de XMI supportée ainsique la version UML qu’ils utilisent.

2Au moment de la rédaction de ce mémoire

19

Modeling tools XMI XMI UML versionversion versionexport import

ArgoUML version 0.25.1 1.2 1.0 1.5argouml.tigris.org 1.1

1.2BOUML version 2.25 1.2 2.1 2.0http ://bouml.free.fr 2.1Fujaba Developer version 5.0.3 NA NA NAwww.fujaba.de

Umbrello UML Modeller version 1.5.7 1.0 NA NAhttp ://uml.sourceforge.net 1.1

1.2Eclipse UML Free Edition version 2.1 2.1 2.1 2.0www.omondo.com

MagicDraw Community Edition version 12.1 2.1 2.1 2.0www.magicdraw.com 1.4Poseidon For UML version 6.0 1.2 1.2 1.4http ://www.gentleware.com

RationalRose version 7.0 NA NA 2.0http ://www-306.ibm.com/software/rational/

Visual Paradigm version 6.0 1.0 1.0 2.0http ://www.visual-paradigm.com 1.2 1.2

2.1 2.1

TAB. 3.1 – Tableau comparatif de plusieurs outils de modélisation

3.3 Visual Paradigm

Notre choix s’est porté sur Visual Paradigm [31]. Ce logiciel permet de travailler avec la der-nière version de UML, d’exporter des diagrammes au dernier format de XMI comme nous pou-vons le constater au tableau 3.1. De plus, Visual Paradigm permet d’importer les fichiers au formatpropriétaire d’IBM RationalRose [29].

20

Chapitre 4

Choix d’un outil de transformation desmodèles

Pour le choix d’un outil de transformation des modèles, nous avons choisi un outil de trans-formation de graphes, car le format de graphe est une représentation générique qui permet dereprésenter de manière uniforme n’importe quel type de diagramme UML, ce qui facilitera le trai-tement, l’analyse et la transformation des modèles.

Un diagramme de classes est différent d’un diagramme d’états-transitions, pourtant leurs repré-sentations en graphes sont similaires. De plus, la théorie sur les transformations de graphes fournitun avantage concernant la transformation des modèles, cette théorie s’étant développée ces 30dernières années.

4.1 Quelques exemples

A la figure 4.1 est représenté le diagramme de classes d’une voiture. Ce diagramme décrit com-ment la voiture est structurée. Une voiture est composée d’un moteur qui est lui même composéd’une boite de vitesse. Cette boite de vitesse peut être soit automatique, soit manuelle. Qu’ellesoit automatique ou manuelle, certaines fonctions seront communes au deux, c’est pourquoi lesclasses Automatic Gear et Hand Gear héritent d’une classe plus abstraite, Gear.

21

FIG. 4.1 – Diagramme de classe d’une voiture

La figure 4.2 représente un diagramme d’états-transitions représentant la boîte de vitesse d’unevoiture. L’état Neutral représente le point mort, et les changements de vitesses y sont aussi repré-sentés. Il s’agit du même exemple représenté à la figure 2.5.

Ces diagrammes sont très différents les uns des autres. Par contre, si nous regardons la repré-sentation de ces diagrammes sous la forme d’un graphe, respectivement à la figure 4.3 et 4.4,nous nous apercevons qu’ils possèdent des similitudes. Par exemple, une classe où un état est re-présenté par un nœud (node) ainsi que les méthodes d’une classe ou les méthodes permettant depasser d’un état à un autre. Un arc (edge) permet de représenter le fait qu’une méthode appartienneà une classe.

22

FIG. 4.2 – Diagramme d’états-transitions d’une boite de changement de vitesse

FIG. 4.3 – Représentation en graphe du diagramme de classe d’une voiture

23

FIG. 4.4 – Représentation en graphe du diagramme d’états-transitions

4.2 Principe de transformation de graphes

La transformation de graphes se fait grâce à des règles de transformation. Ces règles sont ap-pliquées sur un graphe, et si les règles trouvent plusieurs concordances, elles effectuent les chan-gements déterminés en opérant des remplacements, des ajouts ou des suppressions. Le processusde transformation s’effectue en deux étapes, en partant d’un graphe de départ pour produire ungraphe d’arrivée qui a été modifié.

Il existe plusieurs formalismes pour représenter les règles de transformations. Dans ce mémoire,nous utilisons des règles qui sont exprimées visuellement. Une règle est constituée de deux parties,le Left Hand Side (LHS) et le Right Hand Side (RHS). Le LHS est une partie du graphe, destinée àêtre mise en concordance avec les parties du graphes où nous voulons appliquer la règle. Le RHSquant à lui décrit la modification qui sera effectuée.

Un exemple d’une de ces règles visuelles est montré à la figure 4.6. Elle consiste à ajouter unetransition entre deux éléments du graphe. Soit un graphe de départ composé d’un nœud Region etde trois nœuds State représenté à la figure 4.5 :

24

FIG. 4.5 – Graphe de départ

Et une règle de transformation qui consiste à ajouter une transistion entre deux éléments dugraphe :

Left Hand Side Right Hand Side

FIG. 4.6 – Left Hand Side et Right Hand Side

Dans cette règle de transformation, nous pouvons déjà observer que certaines composantes dugraphe de gauche et du graphe de droite sont mises en correspondance. On retrouve cette corres-pondance grâce à une numérotation des éléments des graphes. Cette mise en correspondance estnécessaire pour identifier les éléments qui vont être préservés.

Lorsque la règle est appliquée sur le graphe de départ, plusieurs correspondances avec les élé-ments du graphe sont détectées. Le nœud Region du LHS est mis en correspondance avec celui dugraphe. Les nœuds Vertex 2 et 3 sont mis en correspondance avec deux des nœuds State du graphe.Il est à noter que cette correspondance doit être effectuée manuellement. Si cette correspondancen’était pas faite, la règle détecterait qu’il existe un nœud Region et plusieurs nœuds State sur les-quels s’appliquer. La mise en correspondance avec les éléments du graphe permet donc de choisirles éléments sur lesquels la règle agira.

25

FIG. 4.7 – Application d’une règle

Le nœud Transition va être ajouté au graphe de départ ainsi que deux arcs entre les nœudsTransition et State.

Lorsqu’une règle est appliquée, il se peut que celle-ci demande à l’utilisateur une valeur pourun ou plusieurs attributs. C’est le cas ici avec le nœud Transition qui doit demander à l’utilisateurle nom de la transition. Une boite de dialogue similaire à celle représentée à la figure 4.8 demandesi l’utilisateur veut rentrer une valeur pour l’attribut.

FIG. 4.8 – Boite de dialogue de la définition d’un attribut

26

Si tel est le cas, une fenêtre permet de rentrer la valeur souhaitée. Il s’agit ici de la valeur "nomde la transition" pour l’attribut nom du nœud Transition.

FIG. 4.9 – Définition d’un attribut

Une fois que la règle a été appliquée sur le graphe de départ nous obtenons un graphe d’arrivéequi contient le nœud Transition, ainsi que les différents arcs présents dans la règle.

FIG. 4.10 – Graphe d’arrivée

27

4.2.1 Negative Application Condition

Les règles peuvent également être enrichies par un ensemble de conditions d’applicationsnégatives1. Ces NACs servent à vérifier l’absence des morceaux de graphes qu’elles définissent.Reprenons notre règle permettant d’ajouter une transition entre deux nœuds State. Supposonsà présent qu’une transition ne puisse pas être ajoutée entre deux nœuds State s’il y a déjà unetransition entre ces derniers. La règle de la figure 4.11 permet d’ajouter une transition seulement sila partie NAC est respectée, c’est-à-dire, qu’il n’y ait pas déjà une transition entre les deux nœudsState où nous voulons ajouter cette transition.

FIG. 4.11 – Negative Application Condition

Si nous essayons d’appliquer cette règle sur notre graphe de la figure 4.10, la règle refusera des’appliquer car un nœud Transition existe déjà entre les nœuds State 2ème état et 3ème état. Lerésultat de la tentative de l’application de cette règle est montrée à la figure 4.12.

FIG. 4.12 – NAC violation

4.2.2 Type graph

De façon analogue aux modèles UML, un graphe peut être conforme à un graphe plus abstraitappelé Type graph. Un type graph est aux graphes ce que le métamodèle est aux modèles UML. LeType graph permet de spécifier le nombre de nœuds d’un certain type qui peut être présent dans ungraphe, le nombre d’arcs pouvant relier plusieurs nœuds, ainsi que de spécifier les attributs qu’unnœud ou un arc doit posséder.

1Negative Application Condition.

28

4.3 AGG

Parmi les outils qui effectuent la transformation des graphes, nous trouvons AGG [22]. Lesystème AGG2 (Attributed Graph Grammar) est l’outil utilisé dans ce mémoire. Il s’agit d’unenvironnement de travail destiné à la transformation de graphes au moyen d’une approche algé-brique. Cet environnement est basé sur le principe d’application de règles qui servent à définir destransformations (tel que cela a été expliqué précédemment).

AGG est capable de représenter des graphes, des graphes de type et des règles de transformation.L’outil permet d’éditer les graphes visuellement3, il est capable d’appliquer des transformations etd’assurer la conformité d’un graphe par rapport à un Type graph donné.

4.4 Alternatives à AGG

Il existe plusieurs alternatives à AGG.– MOFLON [27]– VIATRA [30]– Fujaba [25]– GReAT [26]

2La version d’AGG utilisée dans ce mémoire porte le numéro 1.5.03Les figures de la section précédente ont été réalisées avec AGG

29

Chapitre 5

Choix d’un outil de conversion

Ce chapitre décrit l’outil de conversion que nous allons choisir.

5.1 Description du problème

Notre objectif est de convertir un document se basant sur la structure XML en un autre do-cument se basant sur la même structure. Le choix qui s’est imposé à notre esprit a été le langageextensible de transformations à feuilles de style (eXtensible Stylesheet Language Transformations)ou encore XSLT. Plusieurs alternatives à ce langage s’offrent à nous, nous les détaillons dans cechapitre.

5.2 XSLT

XSLT a pour rôle de faciliter la manipulation et le formatage du contenu de documents XML.XML permet de structurer les données d’un document tandis que XSLT permet de travailler surces données. Il est ainsi possible de manipuler ces données ou de créer des documents. Il est clairque XSLT remplit parfaitement notre objectif, pouvoir transformer un document XML en un autredocument XML.

Le lecteur peut se demander pourquoi, dans ce mémoire, nous utilisons deux langages de transfor-mation. La raison de l’utilisation de ces deux langages est que l’outil de transformation de graphesne permet pas de travailler avec des fichiers générés par l’outil de modélisation. Nous avons doncbesoin d’un outil capable de nous fournir un fichier sur lequel l’outil de transformation de graphespuisse travailler.

XSLT fonctionne avec des règles qui vont transformer le document. Il est à noter que les feuilles detransformations XSLT sont elles-mêmes des documents XML. XSLT utilise XPath qui est un lan-gage d’expression qui permet, au moyen de chemins de localisation, de constituer des ensembles

30

d’éléments extraits d’un arbre XML. Les chemins déterminent la façon dont l’arbre doit être par-couru de même que la sélection des données à extraire.

Pour appliquer les feuilles XSLT sur des documents XML, nous utilisons un processeur XSLT.Ce processeur permet de générer le résultat des règles de transformations contenues dans la feuilleXSLT. Nous avons choisi de nous orienter vers les processeurs autonomes1, nous devons en effetcréer un nouveau fichier et pas seulement afficher le résultat.

Il existe plusieurs processeur XSLT autonome :

• 4XSLT - Processeur XSLT Python. [5]

• iXSLT - Processeur XSLT exploitable depuis la ligne de commande.

• Saxon - Processeur XSLT qui implémente totalement XSLT et XPath, ainsi que plusieursextensions. [14]

• Xalan java - Implémentation java de la recommandation XSLT du W3C ainsi que de XPath.[32]

• libxslt - Implémentation Open Source ; processeur et librairie XSLT pour le langage C. [4]

• XML : :XSLT - Processeur XSLT écrit en Perl qui implémente une partie de la recomman-dation XSLT. [13]

• ...

Pour utiliser un processeur autonome, il faut utiliser l’invite de commande et dire au processeurquel est le fichier source, le fichier de sortie à générer, et la feuille XSLT qui est appliquée sur lefichier source.

1C’est-à-dire des processeurs qui ne sont pas contenus dans un navigateur.

31

5.3 Alternatives

Il y a bien sûr plusieurs alternatives à XSLT.

5.3.1 XQuery

L’une de ces alternatives est XQuery, il s’agit d’un langage de requête pour les documentsXML. Comme XSLT, Xquery utilise XPath pour spécifier le chemin où rechercher les informa-tions. XQuery considère la structure d’un document XML comme un arbre ordonné, annoté, danslequel les nœuds ont une identité et peuvent être associés à des types simples ou complexes [10].

Nous n’avons pas retenu cette alternative car notre but était de convertir complètement un fichierXMI en un fichier GGX et vice versa. XQuery est utile lorsqu’il faut interroger des documentsXML. Dans le cadre de ce mémoire, XSLT convenait mieux à nos attentes.

5.3.2 Transformation d’un document XML avec des règles de transformation degraphes

Une autre alternative consiste à utiliser un travail déjà effectué par les créateurs de AGG[21, 22]. Ces derniers ont créé une feuille de transformation XSLT qui permet de convertir undocument au format XML (et non XMI) en un document GGX, xml2ggx. A partir de ce fichier, etavec des règles de transformation de graphes, le document XML est transformé en un graphe.

Nous n’avons pas retenu ce choix car pour pouvoir tirer profit de ce travail, il nous aurait falluconstruire une feuille XSLT qui permet de convertir un document XMI en un document XML. Ilnous a donc semblé plus logique d’appliquer directement une feuille XSLT qui permet de convertirun document XMI en un document GGX.

32

5.4 Exemples de requêtes XSLT

Cette section présente les requêtes en XSLT qui nous ont été les plus utiles.Pour montrer les résultats des requêtes XSLT, nous appliquerons ces dernières sur le documentGGX ci-dessous :

<Document v e r s i o n =" 1 . 0 ">< G r a p h T r a n s f o r m a t i o n S y s t e m ID=" I1 " name=" u n t i t l e d ">

<TaggedValue Tag=" A t t r H a n d l e r " TagValue=" Java Expr "><TaggedValue Tag=" Package " TagValue=" j a v a . l a n g " / ><TaggedValue Tag=" Package " TagValue=" j a v a . u t i l " / ><TaggedValue Tag=" Package " TagValue="com . o b j e c t s p a c e . j g l " / ><TaggedValue Tag=" Package " TagValue=" genged . a l p h a b e t . d a t a t y p e s " / >

< / TaggedValue><TaggedValue Tag="CSP" TagValue=" t r u e " / ><TaggedValue Tag=" i n j e c t i v e " TagValue=" t r u e " / ><TaggedValue Tag="NACs" TagValue=" t r u e " / ><TaggedValue Tag=" c o n s i s t e n c y " TagValue=" t r u e " / ><TaggedValue Tag=" showGraphAf te rS tep " TagValue=" t r u e " / ><TaggedValue Tag=" TypeGraphLevel " TagValue="DISABLED" / ><Types>

<NodeType ID=" I2 " name=" Region%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : ">< A t t r T y p e ID=" I4 " a t t r n a m e =" name " typename=" S t r i n g " v i s i b l e =" t r u e " / >

< / NodeType><NodeType ID=" I5 " name=" P s e u d o s t a t e%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : ">

< A t t r T y p e ID=" I7 " a t t r n a m e =" name " typename=" S t r i n g " v i s i b l e =" t r u e " / >< / NodeType><EdgeType ID=" I8 "

name=" c o n t a i n e r _ s u b v e r t e x%:SOLID_LINE:java . awt . Co lo r [ r =0 , g =0 , b =0] : : [EDGE] : " / >< / Types><Graph ID=" I10 " name=" Sta teMach ineDiagram1 ">

<Node ID=" I11 " t y p e =" I5 ">< A t t r i b u t e c o n s t a n t =" t r u e " t y p e =" I7 ">

<Value >< j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 6 . 0 _01 ">

< s t r i n g > I n i t i a l < / s t r i n g >< / j a v a >

< / Value >< / A t t r i b u t e ><NodeLayout X=" 295 " Y=" 87 " / >< a d d i t i o n a l L a y o u t age=" 0 " f o r c e =" 10 " f r o z e n =" f a l s e " zone=" 50 " / >

< / Node><Node ID=" I14 " t y p e =" I2 ">

<NodeLayout X=" 100 " Y=" 87 " / >< a d d i t i o n a l L a y o u t age=" 0 " f o r c e =" 10 " f r o z e n =" f a l s e " zone=" 50 " / >

< / Node><Edge ID=" I16 " s o u r c e =" I14 " t a r g e t =" I11 " t y p e =" I8 ">

<EdgeLayout bendX=" 0 " bendY=" 0 " t e x t O f f s e t X ="−56" t e x t O f f s e t Y =" 0 " / >< a d d i t i o n a l L a y o u t a k t l e n g t h =" 200 " f o r c e =" 10 " p r e f l e n g t h =" 200 " / >

< / Edge>< / Graph>

< / G r a p h T r a n s f o r m a t i o n S y s t e m >< / Document>

33

La feuille XSLT est de la forme suivante :

<? xml v e r s i o n =" 1 . 0 " e n c o d i n g =" ISO−8859−1" ?>< x s l : s t y l e s h e e t v e r s i o n =" 2 . 0 " x m l n s : x s l =" h t t p : / /www. w3 . org / 1 9 9 9 / XSL / Trans fo rm "

xmlns :uml =" h t t p : / / schema . omg . org / spec /UML/ 2 . 0 "xmlns :xmi =" h t t p : / / schema . omg . org / spec /XMI / 2 . 1 "x m l n s : x l i n k =" h t t p : / /www. w3 . org / 1 9 9 9 / x l i n k ">

< x s l : t e m p l a t e match=" / ">< s o l u t i o n >

< !−−La r e q u ê t e se t r o u v e i c i−−>< / s o l u t i o n >

< / x s l : t e m p l a t e >< / x s l : s t y l e s h e e t >

5.4.1 Déclaration de règle

Une règle est définie par un élément de premier niveau xsl :template. Cet élément comprenddes attributs qui décrivent les conditions de déclenchement de la règle, et un contenu ou corps derègle décrivant le texte à produire quand la règle est déclenchée. Par exemple, la règle <xsl :tem-plate match="/"> se déclenche lorsque le nœud racine d’un document est rencontré. Le corps derègle est défini ici par les balises <solution> et </solution>.

5.4.2 Déclenchement de règles avec xsl :apply-templatesL’élément xsl :apply-templates désigne un ensemble de nœuds avec une expression XPath, et

demande l’application d’une règle pour chaque nœud.

Si, dans notre exemple de feuille XSLT, nous rajoutons la règle suivante :

< x s l : t e m p l a t e match=" Node ">< s o l u t i o n N o d e >

< x s l : t e x t >La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node< / x s l : t e x t >< / s o l u t i o n N o d e >

< / x s l : t e m p l a t e >

Et que nous modifions la requête < !—La requête se trouve ici—> par :

< x s l : a p p l y−t e m p l a t e s s e l e c t =" / / Node " / >

Après l’exécution de la feuille XSLT sur notre document GGX, le résultat sera :< s o l u t i o n >

< s o l u t i o n N o d e >La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node< / s o l u t i o n N o d e >< s o l u t i o n N o d e >La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node< / s o l u t i o n N o d e >

< / s o l u t i o n >

5.4.3 Sélection de la valeur d’un attribut

Lorsque nous souhaitons prendre la valeur d’un attribut d’une balise, nous utilisons la règle<xsl :value-of select="./@nameOfAttribute"/>. Où nameOfAttribute est le nom de l’attribut dont

34

nous souhaitons prendre la valeur. Le "./" signifie que nous prenons l’attribut du noeud courant, iln’est pas utile de mettre "./" car nous travaillons toujours avec le nœud courant. L’attribut selectde cette règle est composé d’un chemin XPath et de la commande "@" pour prendre la valeur del’attribut.

Si nous reprenons notre document GGX et que nous modifions la règle qui sélectionne les Nodeen :

< x s l : t e m p l a t e match=" Node ">< s o l u t i o n N o d e >

< x s l : t e x t >La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node e t i l a v a i t l ´ I D < / x s l : t e x t >< x s l : v a l u e−of s e l e c t ="@ID" / >

< / s o l u t i o n N o d e >< / x s l : t e m p l a t e >

Cela donne le résultat suivant :

< s o l u t i o n >< s o l u t i o n N o d e >

La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node e t i l a v a i t l ´ I D I11< / s o l u t i o n N o d e >< s o l u t i o n N o d e >

La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node e t i l a v a i t l ´ I D I14< / s o l u t i o n N o d e >

< / s o l u t i o n >

5.4.4 Les conditions

Nous pouvons également rajouter des conditions. Si nous voulons uniquement sélectionner lenoeud qui possède un ID égale à I14 deux solutions s’offrent à nous.

Premièrement, nous pouvons ajouter une condition dans le match de la règle comme montré ci-dessous :

< x s l : t e m p l a t e match=" Node [@ID=" I14 " ] ">< s o l u t i o n N o d e >

< x s l : t e x t >La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node e t i l a v a i t l ‘ ID< / x s l : t e x t >< x s l : v a l u e−of s e l e c t ="@ID" / >

< / s o l u t i o n N o d e >< / x s l : t e m p l a t e >

La règle ne se déclenchera que lorsqu’elle rencontrera un noeud ayant un ID égale à I14.

Deuxièmement, nous pouvons laisser la règle telle quelle et ajouter une condition dans le corps dela règle de la façon suivante :

35

< x s l : t e m p l a t e match=" Node ">< x s l : i f t e s t ="@ID=" I14 " ">

< s o l u t i o n N o d e >< x s l : t e x t >La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node e t i l a v a i t l ´ I D < / x s l : t e x t >< x s l : v a l u e−of s e l e c t ="@ID" / >

< / s o l u t i o n N o d e >< / x s l : i f >

< / x s l : t e m p l a t e >

Certains utilisateurs préfèrent utiliser la première solution car la règle ne se déclenche quequand la condition est respectée. La solution est identique pour les deux façons de procéder.

< s o l u t i o n >< s o l u t i o n N o d e >

La f e u i l l e XSLT a r e n c o n t r é une b a l i s e Node e t i l a v a i t l ´ I D I14< s o l u t i o n N o d e >

< / s o l u t i o n s >

36

Chapitre 6

Conversion du métamodèle

Ce chapitre a pour but d’expliquer comment, à partir d’un fichier XMI contenant le métamo-dèle UML, nous sommes parvenus à créer un fichier compatible avec l’outil de transformation degraphes.

6.1 Correspondance Métamodèle - Type graph

Nous avions mentionné au chapitre 2 que les modèles UML devaient correspondre à un méta-modèle. C’est ce métamodèle qui définit les éléments de modélisation (les concepts manipulés parle langage), ainsi que la sémantique de ces éléments (leur définition et le sens de leur utilisation).Nous pouvons voir cela comme un programme Java devant être conforme à la grammaire java.

Dans le logiciel AGG, les graphes doivent être conformes à un Type graph. Ce Type graph joue lemême rôle que le métamodèle en UML ou encore, la grammaire Java pour les programmes.La figure 6.1 permet de résumer la situation.

FIG. 6.1 – Relation UML - Graphes

Notre première conversion doit donc se faire au niveau du métamodèle et du Type graph.Ainsi, lors de l’importation de graphes, nous pourrons vérifier s’ils sont conformes ou non à ceType graph.

37

6.2 Processus de conversion

Avec notre outil de modélisation Visual Paradigm [31] nous avons importé le métamodèleUML fournit dans un format d’IBM Rational Rose que nous avons ensuite exporté dans un formatXMI. Notre but étant de créer une feuille XSLT permettant de convertir le métamodèle en un Typegraph qui sera conforme au métamodèle. La figure 6.2 résume la situation de façon graphique.

FIG. 6.2 – Processus de conversion du métamodèle vers le Type graph

6.3 Code XMI du métamodèle

Le fichier XMI du métamodèle est grand (plus de 43.000 lignes) car il contient toutes les spé-cifications pour le langage UML. Il est évidemment trop long pour pouvoir être recopié dans cechapitre ou pour être mis en annexe, c’est pourquoi nous allons essayer de donner les points im-portants concernant la structure et les informations dont nous avons besoin. Pour pouvoir convertirle fichier XMI source en un fichier GGX cible, il nous faut, au préalable, connaître les différentesbalises qui forment le document. Cette section présente les différentes balises du fichier XMI dumétamodèle, ainsi que les attributs les plus importants.

6.3.1 Les balises

Les balises étant fort nombreuses, nous proposons au tableau 6.1 un récapitulatif reprenant lesbalises qui sont les plus importantes et nécessaires à la compréhension de la conversion.

38

Balises Explications

<xmi:XMI x m i : v e r s i o n =" 2 . 1 ">< / xmi:XMI>

Il s’agit des balises formant le document XMI, l’attributxmi :version indique le numéro de version de XMI utilisé

<uml:Model name=" . . ">< / uml:Model>

Partie du document contenant toutes les informations re-latives aux différents diagrammes, c’est-à-dire tous leséléments qui forment un diagramme.

<ownedMember x m i : t y p e =" . . " . . >< / ownedMember>

Balise contenant les informations sur un élément d’undiagramme. Ces balises se situent entre les balises<uml :Model> et </uml :Model>

<uml:Diagram >< / uml:Diagram >

Ces balises contiennent les informations du layout deséléments d’un diagramme. Les coordonnées, la couleur,la hauteur, la largeur,...

< lowerVa lue v a l u e =" 0 " / >< uppe rVa lue v a l u e =" 1 " / >< uppe rVa lue v a l u e ="∗ " / >

Ces balises contiennent les valeurs de la multiplicité deséléments. Par exemple, si une transition fait partie d’undiagramme, il faut obligatoirement que cette transitionappartienne à une région, la lowerValue vaudra donc 1

< g e n e r a l i z a t i o n >< / g e n e r a l i z a t i o n >

Ces balises sont contenues dans un élément, et donc entrebalises de type <ownedMember>. Elles contiennent l’identi-fiant d’un autre élément qui est le parent (la généralisa-tion) de cet élément.

< o w n e d A t t r i b u t e >< / o w n e d A t t r i b u t e >

Ces balises sont contenues entre des balises de type <ow-nedMember> Elles contiennent les différents attributs d’unélément.

TAB. 6.1 – Tableau des différentes balises

6.3.2 Les attributs

Il peut y avoir de nombreuses balises dans un document XMI. De façon similaire, une balisepeut posséder beaucoup d’attributs. Il peut s’agir d’un nom, d’un type, de l’identifiant d’une ba-lise, de la couleur d’un élément,...

Tous les attributs ne nous ont bien sûr pas été nécessaires. Par exemple, l’attribut contenant lavaleur du taux de transparence dans Visual Paradigm [31] ne nous servira à rien dans le format

39

GGX qui n’utilise pas la transparence.

Le tableau 6.2 établit une liste des attributs les plus importants et les plus nécessaires à la compré-hension de la conversion.

Attributs Explicationsxmi :id Il s’agit du numéro d’identification de la balise.name Cet attribut contient le nom d’un élément du diagramme.xmi :type Cet attribut contient le type d’élément ou le type de relation entre

deux éléments d’un diagramme. Il peut s’agir d’un uml :Com-ment ou de uml :State,...

diagramType Comme son nom l’indique, l’attribut contient le type de dia-gramme UML (ClassDiagram, UseCaseDiagram)

geometry Les données du layout sont contenues dans cet attribut, il s’agitprincipalement des coordonées et de la taille de l’objet

subject Il s’agit d’un attribut important. Il permet de faire référence àune balise ayant un xmi :id égale à cet attribut subject

connectionPointType Il s’agit d’un attribut possédant un nombre qui dit s’il s’agitd’une flèche ou d’un objet

TAB. 6.2 – Tableau des différents attributs

6.4 Structure du fichier

Le fichier se compose principalement de 2 parties :

– La partie où sont contenus les éléments des diagrammes avec leurs attributs, c’est-à-direles classes avec leurs méthodes et leurs variables, les composants d’un diagramme d’états-transitions, les éléments d’un diagramme de séquence, ...

– La partie où se situe les propriétés visuelles comme la taille, la transparence, la positiondans le plan ...

6.4.1 Première partie

La première partie se situe entre les balises <uml :Model> et </uml :Model> . Les balises setrouvant à cet endroit sont les balises <ownedMember> . A la figure 6.3 est représentée la classeState. Nous avons pris cette classe comme exemple mais il en existe évidemment d’autres commemontré à la figure 6.4.

40

FIG. 6.3 – Classe State

FIG. 6.4 – Classes Trarnsition et Pseudostate

Ci-dessous se trouve une partie du code XMI1. Il est à noter que tous les attributs ne se trouventpas sur cet exemple, la raison en est simple, l’exemple serait devenu illisible si nous avions mistoutes les balises et tous les attributs.

<ownedMember i s A b s t r a c t =" f a l s e " name=" S t a t e " v i s i b i l i t y =" p u b l i c "x m i : i d ="OVEsQiGAqACLVvI" x m i : t y p e =" u m l : C l a s s ">

< o w n e d A t t r i b u t e name=" i s C o m p o s i t e " t y p e =" B o o l e a n _ i d "x m i : i d ="OVEsQiGAqACLVvf" x m i : t y p e =" u m l : P r o p e r t y " / >

< o w n e d A t t r i b u t e name=" i s O r t h o g o n a l " t y p e =" B o o l e a n _ i d "x m i : i d ="OVEsQiGAqACLVv8" x m i : t y p e =" u m l : P r o p e r t y " / >

< o w n e d A t t r i b u t e name=" i s S i m p l e " t y p e =" B o o l e a n _ i d "x m i : i d ="OVEsQiGAqACLVwZ" x m i : t y p e =" u m l : P r o p e r t y " / >

< o w n e d A t t r i b u t e name=" i s S u b m a c h i n e S t a t e " t y p e =" B o o l e a n _ i d "x m i : i d ="OVEsQiGAqACLVw2" x m i : t y p e =" u m l : P r o p e r t y " / >

< g e n e r a l i z a t i o n g e n e r a l =" EtEsQiGAqACLXIF "x m i : i d ="OVEsQiGAqACLVxT" x m i : t y p e =" u m l : G e n e r a l i z a t i o n " / >

< g e n e r a l i z a t i o n g e n e r a l =" RiEsQiGAqACLdFa "x m i : i d ="OVEsQiGAqACLVxx" x m i : t y p e =" u m l : G e n e r a l i z a t i o n " / >

< g e n e r a l i z a t i o n g e n e r a l ="gEEsQiGAqACLaQR"x m i : i d ="OVEsQiGAqACLVyA" x m i : t y p e =" u m l : G e n e r a l i z a t i o n " / >

< / ownedMember>

Nous pouvons remarquer que le nom des variables, isComposite, isOrthogonal, ..., sont lesvaleurs des attributs name des balises ownedAttribute.

1Nous ne montrons le code XMI que pour la classe State de la figure 6.3, les autres classes (comme celles de lafigure 6.4) étant représentées de façon semblable.

41

6.4.2 Seconde partieLa seconde partie est constituée de balises qui contiennent les valeurs "visuelles" des objets

des diagrammes. Il s’agit de coordonnées dans le diagramme, de taux de transparence, de la cou-leur du texte, ...

<uml :DiagramElement c o n n e c t i o n P o i n t T y p e =" 2 " geomet ry =" 9 ,214 ,126 ,32 "s u b j e c t ="OVEsQiGAqACLVvI" x m i : i d ="OVEsQiGAqACLVyP">

< x m i : E x t e n s i o n x m i : E x t e n d e r = ‘ ‘ V i s u a l Paradigm f o r UML´´>< c a p t i o n B o u n d s x m i : v a l u e =" 12 ,217 ,−1 ,−1 " / >< s h o w A t t r i b u t e T y p e x m i : v a l u e =" 1 " / ><showOpera t ionType x m i : v a l u e =" 1 " / >

< / x m i : E x t e n s i o n >< e l e m e n t F o n t bo ld =" f a l s e " c o l o r =" Cr:0 , 0 , 0 , 2 5 5 " i t a l i c =" f a l s e " name=" D ia lo g "

s i z e =" 11 " s t y l e =" 0 " / >< e l e m e n t L i n e c o l o r =" Cr:153 , 0 , 5 1 , 2 5 5 " s t y l e =" 1 " t r a n s p a r e n c y =" 0 " w e i gh t =" 1 . 0 " / >< e l e m e n t F i l l c o l o r 1 =" Cr:255 , 2 5 5 , 2 5 5 , 2 5 5 " c o l o r 2 =" " s t y l e =" 1 " t r a n s p a r e n c y =" 0 " t y p e =" 1 " / >

< / uml :DiagramElement >

6.4.3 Résumé

Voici une vue d’ensemble pour mieux se représenter la situation.

<xmi:XMI x m i : v e r s i o n =" 2 . 1 ">< xmi :Documen ta t i on x m i : E x p o r t e r = ‘ ‘ V i s u a l Paradigm f o r UML´´ x m i : E x p o r t e r V e r s i o n =" 5 . 1 " / ><uml:Model name=" memory_scolas " x m i : i d =" model_Id ">

<ownedMember i s A b s t r a c t =" f a l s e " name=" S t a t e " v i s i b i l i t y =" p u b l i c "x m i : i d ="OVEs" x m i : t y p e =" u m l : C l a s s ">

. .

. .

< / ownedMember>

Tous l e s é l é m e n t s des d i f f é r e n t s diagrammes se t r o u v e n t i c i

. .

. .

< / uml:Model><uml:Diagram diagramType=" ClassDiagram " d o c u m e n t a t i o n =" " name = ‘ ‘ S t a t e M a c h i n e s ´ ´

x m i : i d ="OY. A a k d s i i e k s ">

. .

. .

< / uml:Diagram >

Tous l e s diagrammes se t r o u v e n t i c i

. .

. .

< / xmi:XMI>

42

Bien que nous nous soyons concentrés sur le métamodèle des diagrammes d’états-transitions,la démarche que nous avons effectué reste valide pour d’autres métamodèles.

6.5 Structure du fichier GGX

Pour convertir de façon correct le métamodèle, nous avions besoin de connaître la structured’un document GGX.

Ce dernier se compose de 2 parties également :

• La partie contenant les types de nodes (NodeTypes) et les types de edges (EdgeTypes).

• La partie contenant le ou les graphes.

La partie contenant les types de nodes et de edges contient aussi le Type graph. Il s’agit enfait d’un graphe mais qui se trouve dans la partie Types. La partie contenant un ou plusieursgraphes contient des nodes et des edges. Ces nodes et ces edges font respectivement référence auxNodeTypes et aux EdgeTypes, il s’agira de mettre un attribut type et d’y mettre l’identifiant duNodeType.

La figure 6.5 présente un noeud State avec un attribut name. Et la figure 6.6 présente le Typegraph correspondant qui est un nœud State et qui doit posséder un attribut name.

FIG. 6.5 – Node State avec un attribut name

FIG. 6.6 – Node State avec un attribut name

43

Le code qui suit montre comment GGX structure ses données pour que le node State et que leType graph puissent exister.

<Document v e r s i o n =" 1 . 0 ">< G r a p h T r a n s f o r m a t i o n S y s t e m ID=" I1 " name=" Metamodel ">

<Types><NodeType ID=" I2 " name=" S t a t e%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : " p a r e n t =" I3 ">

< A t t r T y p e ID=" I3 " a t t r n a m e =" name " typename=" S t r i n g " v i s i b l e =" t r u e " / >< / NodeType><Graph ID=" model_ID " name=" TypeGraph ">

<Node ID=" I4 " t y p e =" I2 "><NodeLayout X=" 842 " Y=" 95 " / >< a d d i t i o n a l L a y o u t age=" 0 " f o r c e =" 10 " f r o z e n =" f a l s e " zone=" 50 " / >

< / Node>< / Graph>

< / Types><Graph ID=" model_ID " name=" Graph ">


<Value >< j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 5 . 0 ">

< s t r i n g >nom de l ´ é t a t < / s t r i n g >< / j a v a >


< / Node>< / Graph>

< / G r a p h T r a n s f o r m a t i o n S y s t e m >< / Document>

La première balise <Graph> contient le Type graph car cette balise est contenue dans la balise<Types>. La deuxième balise <Graph> contient les éléments du graphe proprement dit. Commenous pouvons le constater, le nœud fait référence au NodeType ayant l’ID I2. Nous pouvons éga-lement remarquer qu’à la différence de XMI qui sépare les propriétés visuelles et les propriétésstructurelles, GGX ne fait pas de distinction.

6.6 Règles de conversion

Le fichier XMI regroupe plusieurs métamodèles. Il s’agit des métamodèles des différents dia-grammes UML. Celui sur lequel nous travaillons est celui des diagrammes d’états-transitions.Nous ne pouvons pas convertir des éléments se trouvant dans la première partie du document cartous les éléments de tous les diagrammes se trouvent dans cette partie. Il nous faut donc nousrestreindre aux éléments du diagramme d’états-transitions.

Notre travail s’effectue en plusieurs étapes :

• Construire les NodeTypes et les EdgeTypes de façon à ce qu’il n’y ait qu’un seul Nodetypeet EdgeType d’un seul type. Chaque NodeType et EdgeType étant respectivement une classe

44

ou une flèche du métamodèle. Il se peut en effet qu’une classe soit représentée plusieursfois dans le métamodèle, ce qui peut conduire à avoir plusieurs fois le même NodeType. Demême, il se peut que le métamodèle contienne plusieurs fois la même transition.

• Respecter l’héritage entre les classes. Information que nous retrouvons dans la balise <ge-neralization>.

• Construire le Type graph en créant des nodes et des edges conformes aux Nodetypes et auxEdgeTypes. Chaque node et chaque edge représentant un élément du métamodèle.

Pour isoler les éléments dont nous avions besoin nous avons créé la règle suivante :

< x s l : t e m p l a t e match=" uml:Diagram [ @diagramType=" ClassDiagram " and @name=" S t a t e Machines " ] ">S e l e c t i o n n e r t o u s l e s é l é m e n t s de ce diagramme e t l e s c o n v e r t i r en NodeType e t en EdgeType< / x s l : t e m p l a t e >

Cette règle permet en effet de ne sélectionner que les balises dont un des attributs est Class-Diagram et dont le nom est State Machines.

Bien évidemment, notre feuille de transformation XSLT ne contient pas que cette simple règle.Il y a un ensemble de règles qui permettent de construire les NodeTypes et les EdgeTypes corres-pondants aux éléments du diagramme, ainsi qu’un deuxième ensemble de règles qui ont commetravail de créer les Nodes et les Edges.

6.7 Exemples

Les figures 6.7 et 6.8 présentent respectivement le métamodèle UML et le Type graph qui luicorrespond.

45

FIG. 6.7 – Metamodèle d’un diagramme d’états-transitions

46

FIG. 6.8 – Type graph conforme au metamodèle

47

Chapitre 7

Conversion d’un fichier XMI

Ce chapitre a pour but d’expliquer comment nous sommes parvenus à convertir un modèleUML au format XMI en un graphe au format GGX. A travers plusieurs exemples nous tenteronsd’expliquer les différentes étapes par lesquelles nous sommes passés pour obtenir cette conversion.Le point suivant a pour but de présenter le processus de conversion.


Pour rappel, la figure 7.1 présente le processus de conversion d’un fichier XMI créé par l’outilde modélisation Visual Paradigm [31].

FIG. 7.1 – Evolution d’un fichier XMI

Une fois le diagramme UML créé, l’outil permet l’exportation de ce diagramme au formatXMI 2.1. Une fois le fichier exporté, l’application d’une feuille de transformations XSLT permetde créer un fichier au format GGX compatible avec le logiciel AGG. C’est cette feuille XSLT quiest l’élément clé dans ce processus de conversion.

48

Pour pouvoir convertir le format source au format cible, nous devions au préalable connaître lastructure des informations présentes dans le fichier source et le fichier cible.

Notre démarche a donc consisté à étudier des cas simples et de regarder le fichier XMI générépar Visual Paradigm [31]. Une fois ces cas simples maîtrisés, nous avons pu convertir des modèlesbeaucoup plus complexes, et ainsi, convertir des modèles complets.

Cette feuille de conversion est différente de la précédente. En effet, nous ne devons plus construireun Type graph mais bien un graphe. Les éléments composant le diagramme sont aussi différentsque ceux composant le métamodèle.

7.2 Un exemple simple

Nous avons commencé par analyser le fichier XMI d’un modèle UML ne contenant qu’un étatinitial. Comme pour le Type graph, le fichier XMI est décomposé en deux parties. Une contenantles éléments du modèle, et la seconde partie contenant les informations concernant la position, lacouleur, etc. Nous nous intéresserons donc ici à la partie contenant les éléments. Cette partie étantévidemment la plus importante.

<uml:Model name=" c a s s i m p l e " x m i : i d =" model_Id "><ownedMember x m i : i d =" s t a t e M a c h i n e _ i d " x m i : t y p e =" u m l : S t a t e M a c h i n e ">

< r e g i o n x m i : i d =" s t a t e M a c h i n e _ r e g i o n _ i d " x m i : t y p e =" u m l : r e g i o n ">< s u b v e r t e x k ind =" i n i t i a l " name=" I n i t i a l " x m i : i d =" dRv2tkiGAqACAwh0 "

x m i : t y p e =" u m l : P s e u d o s t a t e ">< x m i : E x t e n s i o n x m i : e x t e n d e r =" V i s u a l Paradigm f o r UML">

< / x m i : E x t e n s i o n >

< / s u b v e r t e x >< / r e g i o n >

< / ownedMember>< / uml:Model>

Connaissant la structure du document GGX que nous devions générer, nous avons pu construirele squelette de notre feuille XSLT xmi2ggx. Ce squelette se trouve ci-dessous.

< x s l : t e m p l a t e match=" / "><Document v e r s i o n =" 1 . 0 ">

< G r a p h T r a n s f o r m a t i o n S y s t e m >< x s l : a t t r i b u t e name=" ID ">

< x s l : v a l u e−of s e l e c t =" xmi:XMI / uml:Model / @xmi:id " / >< / x s l : a t t r i b u t e >< x s l : a t t r i b u t e name=" name ">

< x s l : v a l u e−of s e l e c t =" xmi:XMI / uml:Model / @name" / >< / x s l : a t t r i b u t e >

<Types>< x s l : a p p l y−t e m p l a t e s s e l e c t =" / / uml:Model / ownedMember [ @xmi:type=" u m l : S t a t e M a c h i n e " ] " / >

< / Types>

< x s l : f o r −each >

49

< x s l : a p p l y−t e m p l a t e s s e l e c t =" / / uml:Diagram [ @diagramType=" S t a t e D i a g r a m " ] " / >< / x s l : f o r −each >

< / x s l : t e m p l a t e >

La règle <xsl :apply-templates select="//uml :Model/ownedMember[@xmi :type="uml :StateMa-chine"]"/> permet de trouver toutes les balises de type ownedMember descendant directementd’une balise uml :Model et qui possèdent un attribut xmi :type=uml :StateMachine.

Une fois qu’une balise de ce genre est trouvée, nous devons regarder quels éléments se trouventdans le modèle. Dans notre exemple nous avons une Region de type uml :Region et un subvertexde type uml :Pseudostate.

Pour ces deux différents éléments, nous devons créer un NodeType Region et un NodeType Pseu-dostate. Nous pouvons déjà penser au cas où, dans le modèle, il pourrait y avoir plusieurs étatsde type Pseudostate. En effet, dans le fichier GGX, un NodeType de type Pseudostate ne doit setrouver dans le fichier qu’une seule fois. La solution consiste donc à compter le nombre d’élémentsqui sont de type Pseudostate comme le montre cette partie de code ci-dessous.

< x s l : c a l l −t e m p l a t e name=" m a k e P s e u d o s t a t e ">< x s l : w i t h−param name=" n u m b e r O f P s e u d o s t a t e "

s e l e c t =" c o u n t ( / / s u b v e r t e x [ @xmi:type=" u m l : P s e u d o s t a t e " ] ) " / >< / x s l : c a l l −t e m p l a t e >

La règle <xsl :call-template name="makePseudostate"> appelle une règle du nom de makePseu-dostate en lui passant en paramètre le nombre de Pseudostate présents dans le modèle. C’est danscette règle que nous allons pouvoir vérifier s’il existe au moins un Pseudostate dans le modèle.

< x s l : t e m p l a t e name=" m a k e P s e u d o s t a t e ">< x s l : p a r a m name=" n u m b e r O f P s e u d o s t a t e " / >

< x s l : i f t e s t =" n u m b e r O f P s e u d o s t a t e "><NodeType ID=" p s e u d o s t a t e _ I D "

name=" P s e u d o s t a t e%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : ">< A t t r T y p e ID=" Pseudos ta teName_ID " a t t r n a m e =" name " typename=" S t r i n g " v i s i b l e =" t r u e " / >

< / NodeType>< / x s l : i f >

< / x s l : t e m p l a t e >

Ce que nous venons de faire pour un subvertex de type uml :Pseudostate est valable pour lesautres types de subvertex, les balises de type uml :Region ou de type uml :Transition. Il est à noterque puisque la balise subvertex se trouve dans la balise region, il nous faut ajouter un arc de typecontainer_subvertex pour que le graphe soit conforme au Type graph que nous avons construitprécédemment.

Une fois que les NodeTypes et les EdgeTypes ont été construits, nous pouvons construire les Nodeset les Edges. Dans notre exemple il s’agit d’un Pseudostate. Grâce à une autre règle similaire à laprécédente, nous allons créer la partie de code suivante :

50

<Node ID=" dRv2tkiGAqACAwh0 " t y p e =" p s e u d o s t a t e _ I D ">< A t t r i b u t e c o n s t a n t =" t r u e " t y p e =" Pseudos ta teName_ID ">

<Value >< j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 5 . 0 ">


< / Value >< / A t t r i b u t e >

< / Node>

La figure 7.2 montre l’état initial dans Visual Paradigm [31] et sa conversion dans le logicielAGG [22].

FIG. 7.2 – Etat intial avant et après

7.3 Exemple complexe

Une fois la conversion d’un cas simple effectuée, nous sommes passés à d’autres cas, commeun état final, un état simple, une transition simple, etc ..

Petit à petit nous avons pu évoluer vers des modèles plus complets et plus complexes. La figure7.3 présente un modèle contenant un état contenant un sous-état, un état inital, un état final, ainsiqu’une transition.

FIG. 7.3 – Etat contenant des éléments

51

De par ce que nous avions déjà entrepris, nous avions déjà le code qui permet de convertir unétat, un état initial, un état final, et deux transitions. La difficulté dans cet exemple réside dans lefait que tous les éléments1 se situent dans un état.

Une partie du code XMI de cet exemple se trouve ci-dessous :

<uml:Model name=" u n t i t l e d " x m i : i d =" model_Id "><ownedMember x m i : i d =" s t a t e M a c h i n e _ i d " x m i : t y p e =" u m l : S t a t e M a c h i n e ">

< r e g i o n x m i : i d =" s t a t e M a c h i n e _ r e g i o n _ i d " x m i : t y p e =" uml :Reg ion ">< s u b v e r t e x name=" E t a t q u i c o n t i e n t " x m i : i d ="F7e7DkiGAqACAwh0" x m i : t y p e =" u m l : S t a t e ">

< r e g i o n name=" Region " x m i : i d =" tlp7DkiGAqACAwii " x m i : t y p e =" uml :Reg ion ">< s u b v e r t e x name=" E t a t q u i e s t c o n t e n u " x m i : i d ="mQp7DkiGAqACAwiR"

x m i : t y p e =" u m l : S t a t e " / >< s u b v e r t e x k ind =" i n i t i a l " name=" I n i t i a l " x m i : i d ="Gq57DkiGAqACAwiu"

x m i : t y p e =" u m l : P s e u d o s t a t e " / >< s u b v e r t e x k ind =" f i n a l " name=" F i n a l S t a t e " x m i : i d ="_QD7DkiGAqACAwjG"

x m i : t y p e =" u m l : P s e u d o s t a t e " / >< / r e g i o n >< t r a n s i t i o n name=" t r a n s i t i o n 1 " s o u r c e ="Gq57DkiGAqACAwiu" t a r g e t ="mQp7DkiGAqACAwiR"

x m i : i d ="mnj7DkiGAqACAwjW" x m i : t y p e =" u m l : T r a n s i t i o n ">< guard x m i : i d =" mnj7DkiGAqACAwjW_guard " x m i : t y p e =" u m l : C o n s t r a i n t ">

< s p e c i f i c a t i o n body=" " x m i : i d =" mnj7DkiGAqACAwjW_guard_spec "x m i : t y p e =" uml :OpaqueExpre s s ion " / >

< / gua rd >< / t r a n s i t i o n >< t r a n s i t i o n name=" t r a n s i t i o n 2 " s o u r c e ="mQp7DkiGAqACAwiR" t a r g e t ="_QD7DkiGAqACAwjG"

x m i : i d ="Vgz7DkiGAqACAwjn" x m i : t y p e =" u m l : T r a n s i t i o n ">< guard x m i : i d =" Vgz7DkiGAqACAwjn_guard " x m i : t y p e =" u m l : C o n s t r a i n t ">

< s p e c i f i c a t i o n body=" " x m i : i d =" Vgz7DkiGAqACAwjn_guard_spec "x m i : t y p e =" uml :OpaqueExpre s s ion " / >

< / gua rd >< / t r a n s i t i o n >

< / r e g i o n >< / ownedMember>

< / uml:Model>

Au travers de nos différents cas, nous nous sommes aperçus que tous éléments étaient conte-nus dans une balise region (à part l’élément region lui-même). Il nous a donc suffit de rappeler lesrègles qui permettaient de créer un node de type region, à l’intérieur de la règle construisant unnode State.

Le code GGX construit à partir de cet exemple est trop long pour pouvoir être montré dans sonintégralité, nous n’en montrerons donc que le résultat graphique à la figure 7.42.

1A part les transitions qui sont des cas particuliers2Les transitions sont un cas particulier. En effet, les transitions appartiennent toutes à la première region dans le

code XMI. Notre algorithme tiens compte des relations père-fils des balises, c’est pourquoi nous voyons que les noeudsTransitions appartiennent à la première region à la figure 7.4

52

FIG. 7.4 – Résultat après conversion

7.4 Processus itératif

Les cas les plus simples ayant été convertis avec succès, nous sommes passés aux détails, enconvertissant la guard d’une transition, en ajouter des nodes behavior à un état, en passant par lesétats historiques utilisés moins fréquement ...

Cette manière de procéder est itérative car nous ne passons au cas suivant que lorsque le casprésent a été résolu, ou converti au format GGX dans notre cas.

7.5 Problèmes rencontrés

Dans le processus de l’élaboration de la feuille XSLT XMI2GGX nous avons rencontrés plu-sieurs problèmes.

7.5.1 Balises uniques

Le principal problème a été que deux balises NodeType de même type, ne peuvent pas existerdans un fichier GGX. Par exemple, considérons que notre fichier XMI contienne deux balisessubvertex de type uml :Pseudostate. Notre première approche avait été de traiter ces balises de lafaçon suivante :

53

pour chaque b a l i s e subvertexcréer l e Nodetype et l e Edgetype correspondant

Malheureusement, cette solution nous donnait le résultat suivant (pour cet exemple) :

<NodeType ID=" P s e u d o s t a t e _ I D "name=" P s e u d o s t a t e%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : " / >

<NodeType ID=" P s e u d o s t a t e _ I D "name=" P s e u d o s t a t e%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : " / >

Cela posait évidemment problème. La solution consiste à compter le nombre d’éléments detype uml :Pseudostate et à ajouter un élement NodeType lorsqu’il y en a au moins un, et de ne pasen ajouter lorsqu’il n’y en a aucun. Cette solution est valable pour les balises qui ne sont pas detype uml :Pseudostate.

7.5.2 Attributs des balises

Le second problème a été de nous apercevoir que les balises subvertex n’avaient pas toutes lesmêmes attributs. Par exemple, un Pseudostate et un State ont l’attribut name en commun, mais lePseudostate possède l’attribut kind en plus. Nous avons donc dû créer deux règles distinctes pourtraiter des cas tels que celui-ci.

54

Chapitre 8

Conversion d’un fichier GGX

Ce chapitre a pour but d’expliquer comment, avec notre expérience de la conversion d’un fi-chier XMI en un fichier GGX, nous sommes parvenus à faire le processus inverse, c’est-à-dire deconvertir un fichier XMI en un fichier GGX.

Ce chapitre est fort similaire au précédent, dans le sens où nous avons effectué la même démarche,mais en sens inverse.


Pour rappel, la figure 8.1 montre le processus de conversion d’un fichier GGX.

FIG. 8.1 – Evolution d’un fichier GGX

55

8.2 Exemple simple

De façon similaire à la construction de la feuille xmi2ggx, nous avons procédé étape par étapeen commençant par des nœuds simples.

Reprenons l’exemple de l’état initial uml :Pseudostate. Avant de s’intéresser au code GGX dece nœud, nous savions que ce Pseudostate devait être contenu dans une région, la région princi-pale qui contient tous les éléments. Nous avons donc écrit une règle qui crée directement la baliseregion lorsque la feuille XSLT est appliquée sur un document GGX1.

FIG. 8.2 – Etat intial dans AGG

Ci-dessous se trouve le code représentant la figure 8.2 :

<Document v e r s i o n =" 1 . 0 ">< G r a p h T r a n s f o r m a t i o n S y s t e m ID=" I1 " name=" u n t i t l e d ">

<Types><NodeType ID=" I2 " name=" Region%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : ">

< A t t r T y p e ID=" I4 " a t t r n a m e =" name " typename=" S t r i n g " v i s i b l e =" t r u e " / >< / NodeType><NodeType ID=" I5 " name=" P s e u d o s t a t e%:RECT: java . awt . Co lo r [ r =0 , g =0 , b =0] : : [NODE] : ">

< A t t r T y p e ID=" I7 " a t t r n a m e =" name " typename=" S t r i n g " v i s i b l e =" t r u e " / >< / NodeType><EdgeType ID=" I8 "

name=" c o n t a i n e r _ s u b v e r t e x%:SOLID_LINE:java . awt . Co lo r [ r =0 , g =0 , b =0] : : [EDGE] : " / >< / Types><Graph ID=" I10 " name=" Sta teMach ineDiagram1 ">


<Value >< j a v a c l a s s =" j a v a . beans . XMLDecoder " v e r s i o n =" 1 . 6 . 0 _01 ">



< / Node><Node ID=" I14 " t y p e =" I2 ">

<NodeLayout X=" 100 " Y=" 87 " / >< a d d i t i o n a l L a y o u t age=" 0 " f o r c e =" 10 " f r o z e n =" f a l s e " zone=" 50 " / >

< / Node><Edge ID=" I16 " s o u r c e =" I14 " t a r g e t =" I11 " t y p e =" I8 ">

<EdgeLayout bendX=" 0 " bendY=" 0 " t e x t O f f s e t X ="−56" t e x t O f f s e t Y =" 0 " / >< a d d i t i o n a l L a y o u t a k t l e n g t h =" 200 " f o r c e =" 10 " p r e f l e n g t h =" 200 " / >

< / Edge>< / Graph>

1Sous les conditions que ce document soit non vide et contienne au moins un noeud.

56

< / G r a p h T r a n s f o r m a t i o n >< / Document>

En regardant ce premier exemple, nous pouvons déjà écrire le squelette de la feuille de trans-formation qui contient l’algorithme suivant :

pour chaque node et pour chaque edgec o n s t r u i r e l a b a l i s e de type NodeType ou EdgeType du node ou edge couranta j o u t e r les a t t r i b u t s du node ou du edge courant dans l a b a l i s e

Pour pouvoir créer la balise correspondante au noeud uml :Pseudostate, nous avons écrit lecode suivant :

< x s l : i f t e s t =" / / NodeType [@ID= t h i s T y p e ] / s u b s t r i n g−b e f o r e (@name, ’% ’)= " P s e u d o s t a t e " ">< x s l : i f t e s t =" c o u n t ( / / Edge [ @type= I D C o n t a i n e r S u b v e r t e x and

@t a rge t =$ t h i s I D and@source != IDNodeRegion ] ) = 0 ">

< s u b v e r t e x k ind =" i n i t i a l ">< x s l : a t t r i b u t e name=" name ">

< x s l : v a l u e−of s e l e c t =" . / A t t r i b u t e [ p o s i t i o n ( ) = 1 ] / Value / j a v a / s t r i n g " / >< / x s l : a t t r i b u t e >< x s l : a t t r i b u t e name=" x m i : i d ">

< x s l : v a l u e−of s e l e c t ="@ID" / >< / x s l : a t t r i b u t e >< x s l : a t t r i b u t e name=" x m i : t y p e ">

< x s l : t e x t > u m l : P s e u d o s t a t e < / x s l : t e x t >< / x s l : a t t r i b u t e >< x m i : E x t e n s i o n x m i : E x t e n d e r =" V i s u a l Paradigm f o r UML">

< / x m i : E x t e n s i o n >

< / s u b v e r t e x >< / x s l : i f >

< / x s l : i f >

Ce code dit pour le nœud courant Si le type du noeud courant est un Pseudostate et que lenœud courant est rattaché à une region alors nous pouvons créer la balise. La démarche restesimilaire pour les autres types de nœud.

8.3 Exemple complexe

Reprenons notre exemple complexe du chapitre 7.Il s’agissait d’un état contenant une région et plusieurs éléments. Notre solution pour créer unerégion lorsqu’un état en possède une est la suivante. Il faut chercher les états qui possède un edgedu nom de region_state. En effet, cet arc dit que à un nœud State est une associé un nœud region.

57

La partie de code suivant permet de créer une sous-region lorsqu’il y en a une :

< x s l : t e m p l a t e match=" Edge " mode=" s u b s t a t e R e g i o n ">

< x s l : v a r i a b l e name=" t h i s T y p e " s e l e c t =" @type " / >< x s l : v a r i a b l e name=" t h i s T a r g e t " s e l e c t =" @ta rge t " / >< x s l : v a r i a b l e name=" typeOfReg ion "

s e l e c t =" / / NodeType [ s u b s t r i n g−b e f o r e (@name, ’% ’)=& quo t ; Region&quo t ; ] / @ID" / >

< x s l : i f t e s t =" / / EdgeType [@ID=$ t h i s T y p e ands u b s t r i n g−b e f o r e (@name, ’% ’)=& quo t ; r e g i o n _ s t a t e&quo t ; ] ">

< r e g i o n >< x s l : a t t r i b u t e name=" name ">

< x s l : v a l u e−of s e l e c t =" / / Node [@ID=$ t h i s T a r g e t and@type=$ typeOfReg ion ] / A t t r i b u t e / Value / j a v a / s t r i n g " / >

< / x s l : a t t r i b u t e >< x s l : a t t r i b u t e name=" x m i : i d ">

< x s l : v a l u e−of s e l e c t =" $ t h i s T a r g e t " / >< / x s l : a t t r i b u t e >< x s l : a t t r i b u t e name=" x m i : t y p e ">

< x s l : t e x t > uml :Reg ion < / x s l : t e x t >< / x s l : a t t r i b u t e >

< x s l : a p p l y−t e m p l a t e s s e l e c t =" / / Edge [ @source =$ t h i s T a r g e t ] " mode=" s u b s t a t e " / >< / r e g i o n >

< / x s l : i f >< / x s l : t e m p l a t e >

La règle <xsl :apply-templates select="//Edge[@source=thisTarget]" mode="substate"/> va recher-cher les noeuds qui sont attachés à cette région.

La figure 8.3 présente le résultat du fichier GGX converti en fichier XMI.

FIG. 8.3 – Etat et sous-états

Comme nous pouvons le constater les éléments ne sont pas bien placés. Cela est dû au faitqu’une partie des informations du fichier XMI est perdue lorsque nous le convertissons. De même,nous ne pouvons pas recréer certains éléments qui sont inconnus dans le fichier GGX, comme latransparence des éléments, si le nom des états est écrit en gras, etc. Néanmoins, il suffit de modifierla place des éléments pour que le diagramme reprenne une structure correcte. Il est important denoter que la structure du fichier XMI créé est correcte, il ne s’agit ici que de défauts visuels.

58

8.4 Processus itératif

Lors de la conception de la feuille XSLT nous avions mentionné qu’il s’agissait d’un processusitératif. Il est évident que pour réaliser le travail équivalent en sens inverse, il s’agit encore d’unprocessus itératif.

8.5 Problèmes rencontrés

Lorsque nous avons commencé à écrire la feuille XSLT ggx2xmi, nous avons travaillé en pa-rallèle avec la feuille xmi2ggx que nous venions de créer. Nous pensions en effet qu’il serait plusfacile de reprendre les valeurs des ID des différents NodeTypes2. Nous nous sommes rendu comptequ’AGG, lorsqu’il importait des fichiers GGX, renumérotait tous les identifiants. De ce fait, notrefeuille était basée sur des ID qui ne correspondaient plus avec les différentes règles que nousavions écrites. La solution a donc été de se baser, non pas sur l’identifiant, mais sur le nom desNodeTypes et des EdgeTypes.

Un autre problème est que GGX ne permet pas de conserver toutes les spécificités liés à un outilde modélisation, comme la transparence ou la profondeur. En effet, le format GGX n’a pas étécréé dans ce but. La plupart des valeurs ne pouvant pas être converties ont été remplacées par desvaleurs par défaut3.

2Un NodeType ou un EdgeType étant unique, nous avions utilisé une valeur d’identification simple comme Pseudo-state_ID.

3Les noms des états sont tous de couleur noire par exemple.

59

Chapitre 9

Validation des résulats

Dans les chapitres précédents, nous avons expliqué comment nous avons créé les feuilles detransformation nécessaires à la conversion d’un code XMI en un code GGX, d’un code GGX enun code XMI. Dans ce chapitre, nous allons nous intéresser à la validation de celles-ci.

Pour tester nos feuilles de conversion, nous les avons utilisées sur des diagrammes que nousavions nous-mêmes créés. Pour cette étape de validation, nous allons convertir des diagrammesque nous n’avons pas réalisés nous-mêmes. Dans une première partie, nous proposons diffé-rents diagrammes d’états-transitions sur lesquels nous appliquerons notre feuille de transformationxmi2ggx pour pouvoir l’importer dans le logiciel AGG.

Ensuite, nous appliquerons notre feuille de transformation inverse ggx2xmi sur le graphe qui auraété créé dans la première étape pour valider notre seconde feuille. Et si tout va bien, le résultataprès l’application de cette transformation devrait être le même diagramme que celui sur lequelnous avons appliqué la première feuille.

9.1 Diagrammes d’états-transitions

Pour ces validations, nous utiliserons quatre diagrammes d’états-transitions différents, trouvésdans la littérature ou sur Internet. Le premier diagramme représenté à la figure 9.1 [3] représenteles différents états par lesquels passe une machine à laver les voitures. Le diagramme de la figure9.2 représente les états par lesquels passe un téléphone. La figure 9.3 [23] représente les états parlesquels une transaction banquaire doit passer. Enfin, la figure 9.4 [20] les états par lesquels passeune application de gestion.

60

FIG. 9.1 – Machine à laver les voitures

61

FIG. 9.2 – Etats d’un téléphone

62

FIG. 9.3 – Etats d’une transaction banquaire

63

FIG. 9.4 – Etats d’un logiciel de gestion

64

9.2 Validation de la feuille de conversion xmi2ggx

Voici les graphes générés à partir des trois diagrammes. Les trois graphes ont été importés avecsuccès dans AGG et n’ont pas généré d’erreurs lorsque nous avons testé s’ils étaient conformesau Type graph. Nous avons essayé d’agencer les noeuds et les arcs de façon à ce que les graphessoient lisibles le plus possible. La figure 9.5 est le graphe généré à partir du fichier XMI de lafigure 9.1. La figure 9.6 représente le graphe généré à partir du fichier XMI de la figure 9.2. Cegraphe étant un peu moins lisible que le précédent, nous avons mis en évidence les noeuds de typeState. La figure 9.7 représente le graphe généré à partir du fichier XMI de la figure 9.3. Ce grapheétant encore plus illisible que le précédent, nous avons de nouveau mis les noeuds de type State enévidence. Enfin, la figure 9.8 présente le graphe généré à partir du fichier XMI de la figure 9.4.

9.3 Validation de la feuille de conversion ggx2xmi

Après nous être assuré que les graphes générés étaient valides et conformes au Type graph,nous avons pû appliquer sur les fichiers GGX de ces graphes notre feuille de transformation inverseggx2xmi. Il n’y a pas de différences entre les diagrammes avant et après conversion pour lesdiagrammes des figures 9.1, 9.2 et 9.4. Nous ne voyons donc pas l’utilité de remettre les mêmesimages. La figure 9.9 par contre, présente quelques différences. Nous pouvons en effet constaterque la couleur de certains états a changé. Cela est dû au fait que la couleur des états, dans la feuillede transformation, est une valeur constante.

65

FIG. 9.5 – Graphe correspondant au diagramme de la figure 9.1

66


67


68


69

FIG. 9.9 – Diagramme d’états-transitions d’une transaction banquaire après reconversion

70

Chapitre 10

Génération de règles de constructiond’un graphe

Ce chapitre présente le déroulement du travail que nous avons dû effectuer pour obtenir plu-sieurs règles de construction. Il s’agit de règles qui vont permettre de construire un graphe qui seraconforme au Type graph.

10.1 Motivation

La génération de règles de ce genre est motivée par plusieurs raisons. La première étant qu’unutilisateur, même novice, c’est-à-dire un utilisateur qui ne connaît pas les détails du Métamodèle(Type graph), pourra construire un modèle (un graphe) correct (c’est-à-dire conforme au Typegraph) en utilisant une séquence de transformation de graphes. La seconde raison est que cettegénération permettra, dans le futur, de générer des modèles de façon automatique. Cette générationautomatique peut être très utile si nous souhaitons effectuer des tests ou si nous avons besoin d’ungrand nombre de model test. Enfin, cela premettra aussi dans le futur de détecter des dépendancesséquentielles et parallèles entre des règles. Par exemple, un nœud State ne peut pas être construits’il n’existe pas déjà un nœud Region.

10.2 Génération de règles

Les règles doivent respecter la multiplicité des éléments du type graph. Par exemple, si dansle type graph il ne pouvait exister que deux nœuds State, nous devrions nous assurer qu’aprèsla construction de deux nœuds State, l’ajout d’un troisième ne serait pas possible. Nous avonsdonc généré ces règles de construction à partir du Type graph. Pour se faire, nous avons écrit unefeuille XSLT dont le but est de parcourir le fichier GGX contenant le Type graph et de générer unerègle qui, pour chaque nœud et arc, ajoute cet élément, et une règle qui retire cet élément, tout enrespectant la multiplicité et les contraintes imposées par le Type graph.

71

10.3 Structure de la feuille de génération

La construction des règles s’est effectuée en deux parties. Nous nous sommes basés sur le typegraph construit au chapitre 6. Pour concevoir les règles et les utiliser dans AGG, il était nécessaired’avoir le type graph ET les règles de construction dans le même fichier. La première partie dutravail a donc consisté à recopier le type graph dans le fichier cible.

La seconde partie a été de construire les règles proprement dites. Ce travail a été effectué enparcourant le type graph. Lors de ce parcours, lorsqu’un nœud est rencontré, les contraintes liéesà ce nœud sont vérifiées et pour chacune de ces contraintes une règle du nom Add + nom de l’arcde la contrainte et une règle du nom Del + nom de l’arc de la contrainte sont ajoutées, tout enrespectant les contraintes de multiplicité et les contraintes de construction.

Les contraintes de construction sont des contraintes qui spécifient qu’un nœud ne peut être construitque si certaines conditions sont remplies. Par exemple, un nœud State ne peut pas être construits’il n’existe pas de nœud Region dans lequel le nœud State devrait être inclus.

Ci-dessous se trouve le squelette de notre feuille de construction makeRule.

<? xml v e r s i o n =" 1 . 0 " e n c o d i n g =" ISO−8859−1" ?>< x s l : s t y l e s h e e t v e r s i o n =" 2 . 0 " x m l n s : x s l =" h t t p : / /www. w3 . org / 1 9 9 9 / XSL / Trans fo rm "

xmlns :uml =" h t t p : / / schema . omg . org / spec /UML/ 2 . 0 "xmlns :xmi =" h t t p : / / schema . omg . org / spec /XMI / 2 . 1 "x m l n s : x l i n k =" h t t p : / /www. w3 . org / 1 9 9 9 / x l i n k ">

< !−− Première p a r t i e −−>< !−−Recop iage du t y p e graph−−>

< !−−===============================================================−−>

< !−− Deuxième p a r t i e −−>

Pour chaque noeuds q u i ne s o n t pas a b s t r a i t sa j o u t e r une r è g l e de c o n s t r u c t i o n de t y p e Adda j o u t e r une r è g l e de c o n s t r u c t i o n de t y p e Del

< / x s l : s t y l e s h e e t >

La deuxième partie va traiter tous les nœuds qui ne sont pas abstraits, c’est-à-dire des nœudsqui n’ont pas de spécialisation. Le fait que certains nœuds soit abstraits n’était pas indiqué dans leType graph. Pour ce faire, nous avons ajouté un nœud de type Abstract et l’avons mis en relationavec les nœuds que nous considérions commme abstraits. Il était en effet inutile de générer desrègles de construction pour un nœud abstrait. Le Type graph demeure néanmoins conforme à l’an-cien Type graph puisque nous n’avons retiré aucune information. Par exemple, le nœud Namespacene sera pas traité car il possède plusieurs spécialisations qui sont Region et State.

72

10.4 Structure d’une règle

Une règle en AGG, et donc, dans un fichier GGX est structurée de la manière suivante :

<Rule ID=" IdOfRule ">. .

<Graph ID=" IdOfLe f tGraph " name=" Lef tOf_nameOfRule ">Graphe de gauche c o n s t i t u é de d i f f é r e n t s noeuds d e s t i n é s au mappage

< / Graph><Graph ID=" IdOfRigh tGraph " name=" RightOf_nameOfRule ">

Graphe de d r o i t e q u i a j o u t e ou r e t i r e des noeuds au g r ap he d ’ o r i g i n e</ Graph ><Morphism name=" nameOfRule ">

Crée un l i e n d ’ i d e n t i t é e n t r e l e s noeuds des d i f f é r e n t s g r a p h e s< / Morphism>< A p p l C o n d i t i o n >

<NAC><Graph ID=" IdOfNacGraph ">

Les d i f f é r e n t s noeuds c o n s t i t u a n t l a p a r t i e NAC< / Graph>

< /NAC>< / A p p l C o n d i t i o n >

< / Rule >

Comme nous l’avions expliqué au chapitre 4, les règles en AGG se composent en général dedeux graphes, le Left Hand Side et le Right Hand Side. Ces deux graphes peuvent êtres accompa-gnés d’un ou de plusieurs graphes de type NAC1.

La structure d’une règle reprend exactement ces trois graphes. Le graphe de gauche reprenantles nœuds destinés à la mise en correspondance, par exemple, s’il y a deux nœuds State dans legraphe que nous construisons et que la règle est destinée à ajouter un nœud d’un autre type à unnœud State, comment définir que nous voulons que ce soit sur le premier nœud State que cetterègle s’applique ? La mise en correspondance est là pour désigner ce nœud.

Le graphe de droite reprend les éléments qui seront ajoutés ou retirés par la règle. La partie dela règle contenant le NAC2 contient elle aussi un graphe représentant une condition négative sousforme de graphe.

10.5 Méthode de recherche des attributs des noeuds

Les différents nœuds du Type graph héritent de nœuds parents. Lors des différents essais quenous avons effectué pour tester les différentes règles, AGG ne voulait pas exécuter la requête cartous les attributs du nœud que nous essayions de créer n’étaient pas initialisés. Par exemple, pour

1Negative Application Condition.2Plusieurs NACs peuvent exister dans une même règle.

73

le nœud State qui hérite de deux autres nœuds comme le montre la figure 10.1, il faut initialiser lesattributs de State. Les plus significatifs étant name et isSubmachineState. Il est évident que nousavons dû écrire une méthode qui permet de demander à l’utilisateur de rentrer une valeur pour lesdifférents attributs.

FIG. 10.1 – Le noeud State hérite des noeuds Namespace et NamedElement

La demande d’une valeur d’un attribut en AGG dans un fichier GGX se fait de la manièresuivante. Reprenons le morceau de code définissant une règle de la section précédente. Les balisesci-dessous permettent de demander à l’utilisateur d’initialiser les attributs name et isSubmachineS-tate pour l’ajout d’un nœud State.



Nous avons créé une méthode en XSLT qui recherche les attributs d’un nœud, qu’ils soienthérités ou pas, et qui ajoute les balises aux endroits appropriés.

10.6 Génération des NACs pour les règles de type Add

Les règles de construction de type Add peuvent être soumises à plusieurs conditions. Il se peutpar exemple que le nombre de nœuds d’un certain type soit limité par la multiplicité indiquée surles arcs ou sur les nœuds dans le Type graph ou que le Type graph oblige le nœud qui va être créé

74

à être en relation avec un minimum de deux nœuds (ces contraintes étant les multiplicités mini-males et maximales). Nous avons donc écrit une méthode qui recherche à partir de la multiplicitéindiquée sur les arcs et sur les nœuds du Type graph les conditions supplémentaires à ajouter à larègle. Prenons l’ajout d’un nœud de type Behavior et d’un arc de type entry_state à un nœud State.Le Type graph indique qu’un nœud State peut avoir au plus (c’est-à-dire une multiplicité 0..1) unnœud behavior et un arc entry_state.

La solution pour créer un NAC de ce type consiste donc à regarder la multiplicité maximale ducoté du nœud Behavior et d’ajouter un arc entry_state et un nœud Behavior au nœud State. Lafigure 10.2 montre le résultat de l’algorithme de façon graphique.

FIG. 10.2 – L’ajout d’un NAC à une règle

Il est important de noter que la génération des NACs pour les différentes règles n’a pas étéeffectuée de façon manuelle.Nous avons repris les contraintes du Type graph de façon automatique, ce qui rend les règles deconstructions conformes au Type graph.

10.7 Génération des NACs pour les règles de type Del

La construction des NACs pour les règles de construction de type Del est similaire à la géné-ration des NACs pour les règles de type Add. Néanmoins l’algorithme de génération est différentcar les contraintes ne sont plus les mêmes. En effet, si nous reprenons l’exemple de l’ajout d’unnœud Behavior à un nœud State, la contrainte pour cette règle ne correspond plus à la contrainted’enlèvement de ce type de nœud.

Pour pouvoir enlever un nœud, il faut vérifier qu’un ou plusieurs autres nœuds ne sont pas at-tachés à lui. Pour pouvoir ajouter ce nouveau type de contrainte à tous les nœuds, nous avonsélaboré un nouvel algorithme qui parcours le Type graph et qui regarde quels nœuds et quels arcspeuvent être attachés au nœud courant.

Supposons que lors du parcours du Type graph nous soyons sur le nœud State. Le Type graphnous dit que ce nœud est susceptible de posséder un nœud de type Region, un nœud de type Pseu-

75

dostate, ConnectionPointReference, Constraint, Trigger et Behavior, il peut également être reliépar les différents arcs qui relient le nœud State aux autres nœuds comme le montre la figure 10.3.

FIG. 10.3 – Le noeud State et ses relations

Pour chacun de ces nœuds, nous n’allons plus regarder la multiplicité mais simplement ajouterune relation arc-nœud au nœud State. La figure 10.4 montre les NACs ayant été créés par notrealgorithme. De façon similaire aux NACs pour les règles de construction de type Add, ces NACsont été construits de façon automatique, selon les contraintes du Type graph.

76

FIG. 10.4 – Les NACs pour la règle DelState

10.8 Le Dangling condition et les règles injectives

Une alternative aux NACs des règles de type Del est le dangling condition. Il s’agit d’uneoption du logiciel AGG qui vérifie, lors de la suppression d’un nœud, si d’autres noeuds y sontattachés. Par exemple, la figure 10.5 présente un graphe qui contient un nœud Region, contenantlui-même un nœud State qui possède un nœud Region et deux nœuds Behavior.

77

FIG. 10.5 – Graphe

La figure 10.6 montre le résultat de l’application de la règle DelState sur ce graphe et si l’option"Dangling" est cochée dans AGG.

FIG. 10.6 – Graphe

Autrement dit, si le nœud contient des éléments et si l’option Dangling condition est activéealors la règle refusera d’effectuer la transformation demandée. Avec l’option Dangling conditionactivée, les NACs de type Del ne sont plus nécessaires. Néanmoins, dans un souci de complémen-tarité, nous les avons tout de même générés.

Les règles injectives permettent de référencer deux fois un même nœud. Il se peut que voulionsajouter une transition qui part d’un état pour arriver à ce même état. L’option injective est uneautre option de AGG. Si cette option est cochée, il est impossible d’ajouter ce genre de transition.Par exemple, si nous reprenons notre règle permettant d’ajouter une transition entre deux nœuds àla figure 10.7, et que nous essayons de faire une mise en correspondance avec les nœuds Vertex unnœud State du graphe, AGG refusera d’effectuer la transformation et affichera le message montréà la figure 10.8.

78

FIG. 10.7 – Graphe - Injective condition

FIG. 10.8 – Graphe - Bad Mapping

79

Si, au contraire, nous décochons l’option Injective dans AGG, il sera alors possible d’effectuerune mise en correspondance avec un seul nœud du graphe comme le montre la figure 10.9.

FIG. 10.9 – Graphe - Good Mapping

10.9 Validation des règles de construction

Pour valider nos règles de construction, nous avons construit les graphes des quatre différentsdiagrammes introduits au chapitre 9, en utilisant uniquement nos règles de construction. Nousétions dès lors certains que ces graphes seraient conformes au Type graph. Une fois les graphesconstruits, nous avons appliqué notre feuille de conversion inverseggx2xmi pour créer les dia-grammes d’états-transitions correspondants. Les diagrammes générés sont identiques aux figures9.1, 9.2, 9.3 et 9.4. Dans le but de vérifier si notre feuille de génération de règles de constructionest correcte, nous avons appliqué celle-ci sur d’autres Type graph et nous en avons regardé lesdifférentes règles. Les figures 10.10, 10.11, 10.12 et 10.13 présentent les Type graph sur lesquelsnous avons appliqué notre feuille. A chaque fois, notre feuille nous a fourni un ensemble de règlespermettant d’ajouter et de retirer des éléments du Type graph tout en respectant les contraintes decelui-ci.

80

FIG. 10.10 – Type graph simple d’un diagramme de classes

FIG. 10.11 – Type graph 2

81

FIG. 10.12 – Type Graph 3

FIG. 10.13 – Type graph 4

82

Chapitre 11

Conclusion

L’objectif de ce mémoire était de réaliser une conversion entre les fichiers d’un outil de modé-lisation UML et d’un outil de transformation.

11.1 Résumé et contributions

Pour ce faire, nous avons d’abord analysé les moyens mis en oeuvre par les outils de modéli-sation pour exporter les différentes données contenues dans un modèle UML. Nous nous sommesfocalisés sur un modèle UML en particulier, les diagrammes UML d’états-transitions. Nous avonsprésenté le concept de Métamodèle UML qui établit la façon dont un modèle UML doit être repré-senté. Nous avons présenté le standard XMI, la façon dont l’outil de modélisation UML que nousavons choisi structure les données dans ce fichier XMI. Nous avons vu que, bien que XMI soit unstandard, beaucoup d’outils de modélisation UML ne permettent pas de sauvegarder des modèlesselon ce standard.

Ensuite nous avons choisi un outil de transformation des modèles. Nous avons vu que les graphessont des représentations abstraites des différents modèles UML, nous avons également introduit lafaçon dont un logiciel de transformations de graphes pouvait créer plusieurs règles et ainsi, trans-former un graphe. Nous avons introduit les fichiers GGX qui sont les fichiers qu’utilise l’outilAGG.

Nous avons choisi par après un outil de conversion, XSLT, nous en avons introduit le conceptet le mode de fonctionnement. Puis, nous avons expliqué comment nous avons réalisé une feuillede transformation XSLT qui rend possible la conversion du métamodèle UML des diagrammesd’états-transitions en un Type graph. De la même façon, nous avons expliqué comment nous avonsprocédé pour réaliser les feuilles de transformation qui rendent possible la conversion entre un mo-dèle et un graphe.

83

L’utilisation de XSLT a été un avantage car il permettait, en se basant sur un fichier de type XML,de créer un autre fichier de type XML. Il s’agissait clairement de l’outil dont nous avions besoinpour pouvoir convertir les fichiers entre l’outil de modélisation UML et l’outil de transformationdes modèles.

Par la suite, nous avons montré que l’utilisation de règles de construction pouvait rendre possiblela construction d’un graphe correspondant au Type graph, et donc, au métamodèle des diagrammesd’états-transistions, et ainsi, construire un modèle qui ne contient pas d’erreurs. De plus, l’utilisa-tion de ces règles permet de créer un grand nombre de graphes, et ce, de façon automatique. Celapeut être très intéressant si, dans l’avenir, des tests doivent être effectués sur un grand nombre degraphes de ce genre.

Avec notre approche, nous avons montré qu’il était possible de créer un modèle UML (dans cecas ci, un diagramme d’états-transitions) avec un outil de modélisation UML, de spécifier ce mo-dèle en tant que graphe (qui est un point de vue plus abstrait qu’un diagramme), et de spécifierles transformations de modèles en règles de transformations de graphes, choses qui ne sont paspossibles dans les outils de modélisation actuelles. Notre approche permet donc à un outil demodélisation UML de supporter la transformation de modèles via un outil de transformation degraphes.

11.2 Apports personnel

Ce mémoire nous a permis d’approfondir nos connaissances dans le standard d’échange de mo-dèles UML [6] que représente XMI [8], dans les transformations de graphes, dans les diagrammesd’états-transitions UML, ainsi que dans le langage de transformation XSLT et également en XPathqui permet de désigner une partie d’un arbre XML.

11.3 Travaux futurs

Plusieurs travaux se basant sur ce que nous avons fait sont envisageables. En premier lieu,il serait intéressant de rendre compatibles les feuilles de transformations avec plusieurs outils demodélisation. Lors de la réalisation de ce mémoire, nous avons vu que les outils de modélisationsutilisaient XMI pour s’échanger des modèles. Nous avons vu aussi que tous les outils de modéli-sations n’utilisaient pas la même version de XMI. De plus, des informations propres à l’outil demodélisation viennent s’ajouter aux fichiers contenant les modèles. De ce fait, notre travail fournitpour un outil de modélisation ne fonctionnera peut-être pas avec un autre outil de modélisation,utilisant une plus vieille version de XMI par exemple. Il serait donc intéressant de voir ce travailde conversion s’étendre à plusieurs outils de modélisation.

Un second travail pourrait être de créer une autre version de nos feuilles de conversion pour

84

les rendre compatible avec d’autres outils de transformation comme AGG. Comme nous l’avonsmentionné, AGG n’est pas le seul outil de transformation de graphes. Il existe déjà des outils detransformation capables d’importer un modèle UML et de travailler sur ce dernier. C’est le cas deMOFLON qui est un outil récent1 apparu lors de la réalisation de ce mémoire.

Une troisième possiblité pourrait être de concevoir un outil qui serait un outil de modélisationET un outil de transformation de graphes. Nous pourrions utiliser cet outil pour créer un grapheconforme au Type graph, et avec l’utilisation de nos feuilles de conversion, le modèle serait crééimmédiatement. De même, un changement dans le modèle serait accompagné d’un changementdans le graphe et vice versa.

1Janvier 2007

85

Bibliographie

[1] Bernd Amann and Philippe Rigaux. Comprendre XSLT. OREILLY, 2003.

[2] Enrico Biermann, Karsten Ehrig, Christian Köhler, Günter Kuhns, Gabriele Taentzer, andEduard Weiss. Graphical definition of in-place transformations in the eclipse modeling fra-mework. In MoDELS, pages 425–439, 2006.

[3] Jean Didier. Introduction à UML, 06 2007. http ://lsc.univevry.fr/didier/pedagogie/uml2.pdf.

[4] John Fleck. libxslt, 06 2007. http ://xmlsoft.org/XSLT/.

[5] Fourthought. 4XSLT, 06 2007. http ://4suite.org/index.xhtml.

[6] Object Management Group. UML, 06 2007. http ://www.uml.org/#UML2.0.

[7] W3C group. W3C, 06 2007. http ://www.w3.org/.

[8] W3C group. XMI, 06 2007. http ://www.omg.org/technology/documents/formal/xmi.htm.

[9] W3C group. XML, 06 2007. http ://www.w3.org/XML/.

[10] W3C group. Xquery 2.0 : An XML query language, 2007. http ://www.w3.org/TR/xquery/.

[11] Elliotte Rusty Harold and W. Scott Means. XML en concentré, Manuel de référence rapide.O’REILLY, 2002.

[12] Steven Holzner. XSLT par la pratique. EYROLLES, 2003.

[13] Geert Josten, Egon Willighagen, Mark A. Hershberger, Bron Gondwana, and JonathanStowe. XML : :XSLT, 06 2007. http ://xmlxslt.sourceforge.net/.

[14] Michael Kay. Saxon, 06 2007. http ://www.saxonica.com/.

[15] Björn Lundell, Brian Lings, Anna Persson, and Anders Mattsson. Uml model interchangein heterogeneous tool environments : An analysis of adoptions of xmi 2. In MoDELS, pages619–630, 2006.

[16] Sal Mangano. XSLT en action. O’REILLY, 2003.

[17] Tom Mens. On the use of graph transformations for model refactoring. In GTTSE, pages219–257, 2006.

[18] Bruno Pagès. BOUML, 06 2007. http ://bouml.free.fr/.

[19] Dan Pilone and Neil Pitman. UML 2 en concentré. O’REILLY, 2006.

86

[20] Pierre Sunier. Atelier de génie logiciel, 06 2007.http ://lgl.isnetne.ch/isnet43/phase3/altb/images/modmet1_automateglobal.gif.

[21] Gabriele Taentzer and Giovanni Toffetti Carughi. A graph-based approach to transform xmldocuments. In FASE, pages 48–62, 2006.

[22] The AGG Team. AGG, 06 2007. http ://tfs.cs.tu-berlin.de/agg/.

[23] The Altova Team. State machine diagram, 06 2007.http ://www.altova.com/manual2007/UModel/index.htmlumstate_machine_diagram.htm.

[24] The ArgoUML Team. ArgoUML, 06 2007. http ://argouml.tigris.org/.

[25] The Fujaba Team. Fujaba, 06 2007. http ://www.fujaba.de/.

[26] The GReAT Team. GReAT, 06 2007. http ://repo.isis.vanderbilt.edu/tools/get_toolGReAT.

[27] The MOFLON Team. MOFLON, 06 2007. http ://www.moflon.org/.

[28] The Poseidon Team. Poseidon for UML, 06 2007. http ://www.gentleware.com/index.php.

[29] The Rational Team. Rational rose, 06 2007. http ://www-306.ibm.com/software/rational/.

[30] The VIATRA Team. VIATRA, 06 2007. http ://dev.eclipse.org/viewcsv/indextech.cgi/gmt-home/subprojects/VIATRA2.

[31] The VisualParadigm Team. Visual paradigm, 06 2007. http ://www.visual-paradigm.com/.

[32] The Xalan Team. Xalan, 06 2007. http ://xml.apache.org/xalan-j/.

[33] Jean-Francois Warny. Détection et résolution des incohérences des modèles UML avec unoutil de transformation de graphes. Master’s thesis, Université de Mons-Hainaut, 2006.

87

conversion de modèles uml en format de graphes scolas...

Documents