Rapport de fin de phase II - serveur campus des écoles hes

22.06.2005 1/22
ISNet35 Rapport phase II
Cadre du projet
Ce projet à été déposé dans le centre de compétence Informatique de gestion et
systèmes (ISNet) dans le cadre du programme de la réserve stratégique de la HES-SO en
septembre 2001. Il est sous la responsabilité du Laboratoire de Technologie Objet de la
Haute Ecole de Gestion de Genève.
1.1. Rappel des objectifs du projet
Les objectifs du projet sont initialement définis ainsi :
A partir des classes Java obtenues à l'issue d'un processus d'Analyse et de Conception
• Concevoir un processus générique automatique d'implantation de la persistance
d'objets Java dans une base de données relationnelle-objet, offrant en particulier les
possibilités
¾ de gérer cette persistance de façon transparente pour le programme d'application
Java,
¾ de permettre l'accès aux données représentées par les objets Java par des
applications quelconques en préservant l'intégrité des données.
• Elaborer une démarche méthodologique permettant de comparer le résultat de ce
processus aux technologies existantes.
• Réaliser et valider un prototype implantant effectivement ce processus générique.
• Rédiger une publication qui sera soumise à une revue spécialisée.
1.2. Objectifs de la phase II
La phase II, intitulée Réalisation et validation du prototype est définie initialement par les
objectifs suivant :
• Implanter effectivement le prototype décrit par le cahier des charges obtenu à l’issue
de la première phase;
• Valider l’outil obtenu en développant au moins deux applications métier types selon
les deux processus de développement cités ; les applications seront à priori
différentes exploiteront un ensemble de données commun représentées par les trois
technologies (relationnelle pure, relationnelle-objet, vue relationnelle-objet)
• Appliquer la démarche méthodologique d’évaluation ;
• Produire un document de synthèse comprenant :
¾ Les résultats et conclusion de l’étude comparative
¾ Une description du processus de réalisation et de validation mis en œuvre

22.06.2005 2/22
1.3. Document
Le présent document est le rapport de synthèse du travail du groupe de compétence
ISNet-Ne de la Haute école Neuchâteloise en fin de phase II du projet, son contenu devra
s’intégrer dans le cadre global du projet.
Suite aux résultats de la phase I, l’activité de l’équipe neuchâteloise s’est principalement
orientée sur la réalisation d’un prototype de génération de script de création d’objets
persistant dans la base de données à partir de leurs spécifications contenues dans un
fichier XMI. Le modèle de persistance retenu est le modèle relationnel-objet d’Oracle.
Prototype de générateur SQL-DDL
1.4. Introduction
Le prototype que nous avons réalisé permet de générer le script SQL-DDL (Data
Defintion Language) pour une base de données relationnelle (le SGBD cible retenu lors
de l'étape I est Oracle) à partir d'un fichier XMI contenant un modèle de domaine UML
(seul les diagrammes de classes sont pris en considération).
Le prototype est loin d'être une solution de production. Notre objectif était de monter la
faisabilité d'une transformation XMI-UML vers SQL-DDL. Un certain nombre de choix ont
été implémentés sans forcément utiliser la solution la plus propre. Par exemple, nous
utilisons un stéréotype pour gérer les contraintes NOT NULL au lieu d'utiliser la
multiplicité à disposition pour les attributs UML. Nous avons également simplifié certaine
partie de la mise en correspondance afin de respecter les délais qui nous étaient
initialement fixés. Par exemple, pour le moment, les associations doivent être navigable
que dans un sens. De ce fait, l'analyse du fichier XMI s'en trouve facilitée puisque nous
avons contourné le problème posé par les associations bi-directionnelles (graphe
cyclique).
Les critères du génie logiciel et les principes de la conception orientée objet n'ont pas
forcément été respectés dans le cadre de ce travail. En effet, nous avons réutilisé
quelques classes issues d'un autre travail sur la génération de code SQL-DDL qui
n'étaient initialement pas prévues pour être intégrées à ce projet. De plus, nous avons
privilégié la fonctionnalité sur la bonne odeur du code source (au sens XP du terme).
Dans le cas d'une implémentation de production de notre prototype, un important travail
de refactoring sera nécessaire pour obtenir une solution de qualité.
1.5. Parsing XML
Dans le cadre du développement de ce prototype, nous avons utilisé l’API de Sun JAXP
(Java API for XML Processing) pour effectuer le parsing des fichiers XMI. Nous avons
retenu la méthode de parsing de type DOM (Document Object Model). Par manque de
temps, nous n’avons pas pu étudier l’autre alternative orientée événements qui s’appelle
SAX (Simple API for XML).
De toute façon, il nous semble absolument évident qu’une version de production du
générateur devrait être construite sur la base de la norme Xpath du W3C. Etant donné,
les évolutions futures d’XMI (la version 2.0 d’UML devrait bientôt être publiée), il faut

22.06.2005 3/22
absolument minimiser la maintenance nécessaire concernant les changements liés à
l’organisation des fichiers XMI sur laquelle nous n’avons aucune influence. Nous avons
déjà connu de telles difficultés car Rational Rose supporte XMI en version 1.1 et Poseidon
for UML en version 1.2. De ce fait notre générateur ne fonctionne qu’avec des fichiers
XMI générés à partir de Rational Rose.
L’avantage de JAXP est de permettre au développeur de ne pas utiliser de classes
spécifiques à un parseur X ou Y mais de travailler de façon abstraite avec n’importe quel
parseur. Le choix du parseur se fait au niveau du système et l’instanciation de celui-ci est
délégué à la classe DocumentBuilderFactory dans le cas du DOM.
1.5.1. Parsing DOM
La manipulation d’un fichier XML avec le DOM se fait au moyen des interfaces Document
et Node. Pour rappel, le DOM propose une méthode d’accès au contenu d’un fichier XML
de type arborescente. A partir du nœud racine, il est possible d’accéder aux nœuds
enfants et ainsi de suite.
L’interface Node disposent des méthodes suivantes :
Un nœud est une entité polymorphe qui peut-être un ELEMENT, un ATTRIBUTE, ou
encore du texte. La méthode getNodeType() permet de connaître le type exacte du
nœud.
Comme nous l’avons dit plus haut, en utilisant JAXP, le code Java est indépendant du
parseur utilisé. De ce fait, il faut recourir à une fabrique pour l’instanciation de celui-ci.
DocumentBuilderFactory bf = DocumentBuilderFactory.newInstance();
Une fois la fabrique instanciée, il est possible de paramétrer celle-ci. Le paramétrage
étant effectué, il ne reste plus qu’à demander la création d’une instance de parseur. Dans
le contexte du DOM, un parseur s’appelle un DocumentBuilder.
DocumentBuilder b = bf.newDocumentBuilder();
Le parsing ne s’effectue pas automatiquement. Il faut pour ce faire appeler la méthode
parse() et lui indiqué en paramètre le nom du fichier XML à traiter. Cette méthode
retourne une instance conforme à l’interface Document qui sert de point de départ pour
la manipulation de l’arbre qui vient d’être construit en mémoire sur la base du fichier
XML.
Document doc = b.parse("fichier.xml");
A partir du document, on peut obtenir le nœud racine au moyen de la méthode
getDocumentElement().

22.06.2005 4/22
Element root = doc.getDocumentElement() ;
L’interface Element est une interface qui hérite de Node qui offre des méthodes
spécifiques au traitement des balises XML (<!ELEMENT> dans une DTD).
A partir de maintenant, puisque nous sommes en possession du nœud racine du
document, JAXP ne nous est plus d’aucune utilité puisque c’est à nous d’écrire le code
nécessaire pour traiter le document XML selon nos propres besoins. Il s’agit de s’appuyer
sur la méthode getChildNodes() de l’interface Node pour réaliser ces traitements.
1.5.2. Parsing XPath
Nous présentons dans la seconde partie de ce rapport l’utilisation d’une base de données
Oracle pour l’interrogation d’un document XML au moyen de la norme XPath. Il nous
semblait cependant intéressant de montrer qu’il est également possible d’utiliser ce
mécanisme depuis un programme Java en utilisant un moteur de transformation XSL.
Pour ce test, nous avons choisi d’utiliser l’outil Xalan de la fondation Apache. Nous
n’avons malheureusement pas eu le temps de regarder si JAXP offrait une couche
d’abstraction pour ce genre d’outil comme c’est le cas pour les parseurs DOM et SAX.
En nous basant sur l’exemple de manipulation présenté ci-dessous dans la partie sur
XPath et Oracle, voici la requête XPath qui devrait nous retourner le nom de la classe
contenue dans le fichier XMI :
/XMI/XMI.content/UML:Model/UML:Namespace.ownedElement/UML:Class/@name
La première étape consiste à créer une instance compatible avec l’interface Document
(voir la section ci-dessus Parsing DOM) qui sera ensuite transmise au moteur de
recherche XPath.
DocumentBuilderFactory bf = DocumentBuilderFactory.newInstance();
DocumentBuilder b = bf.newDocumentBuilder();
Document doc = b.parse("demo.xmi");
Il ne nous reste plus qu’à demander au moteur de recherche XPath d’effectuer notre
requête. Celui-ci retourne, en fonction de la méthode utilisée, une instance de Node ou
une collection de Node.
Node n = XPathAPI.selectSingleNode(doc, request) ;
La variable request est une chaîne de caractères contenant la requête XPath à appliquer
au document XML représenté par la variable doc. Le nœud reçu en réponse à notre
requête peut maintenant être traité au moyen des méthodes de l’interface Node comme
si nous avions effectué laborieusement le parsing de façon traditionnelle au moyen d’un
arbre DOM.
Grâce à l’utilisation de XPath pour le parsing de fichier XMI, il devient possible d’assurer à
moindre frais l’évolutivité de l’application en regard des changement de la spécification
XMI et/ou UML. Le chemin d’accès pourrait être prédéfinis dans un fichier de
configuration afin de pouvoir être changés sans nécessiter la recompilation de
l’application.
L’utilisation de XPath peut se faire soit en utilisant un outil comme Xalan ou alors en
utilisant les fonctionnalités d’une base de données XML comme Oracle (voir prochain
chapitre). Dans ce deuxième cas, les tests réalisés ont montré un certain degré
d’immaturité dans la solution proposée par Oracle c’est pourquoi la solution Xalan

22.06.2005 5/22
pourrait bien être une alternative intéressante. De plus l’utilisation d’un outil comme
Xalan permet d’offrir une solution indépendante d’un quelconque SGBD du marché.
Vous trouverez des plus amples informations sur XPath dans la deuxième partie de ce
document ainsi que sur le site du W3C (http://www.w3.org/TR/xpath). Xalan est
disponible sur le site XML de la fondation Apache (http://xml.apache.org/xalan-
j/index.html).
1.6. Implémentation du générateur SQL-DDL
1.6.1. Présentation générale
De façon très simplifiée, le générateur fonctionne grâce à la collaboration des objets de
trois classes. Une instance de la classe XmiAnalysator lit un fichier XMI et récupère les
méta-données dans un conteneur de type XmiData. Ces méta-données sont ensuite
transmise à une instance de ScriptGenerator. Celui est responsable de la transformation
des méta-données au format relationnel (ajout de l’attribut clé étrangère par exemple).
La classe SQL_DDLCreator est la façade du système. Elle coordonne l’analyse du fichier
XMI et la production du fichier SQL-DDL correspondant.
Il est possible de lancer l'application en mode ligne de commande ou en mode graphique
(Swing).