Développement d'un éditeur XML

tonguescurlySoftware and s/w Development

Nov 17, 2012 (4 years and 8 months ago)

328 views

MEHAULT Maxime









L3 MMI

NICOLAS Rémi







INFO 0605

Développement d'un éditeur XML


Tuteur : Mr. RABAT Cyril









A
NNEE
2009

-

2010


MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
2

sur
22

1.

Introduction

................................
................................
................................
................................
.....

3

2.

Présentation du projet

................................
................................
................................
....................

4

a.

L
e contexte

................................
................................
................................
................................
..

4

b.

But du projet

................................
................................
................................
...............................

4

3.

Les outils utilisés

................................
................................
................................
..............................

5

a.

Le langage java

................................
................................
................................
............................

5

b.

Les environnements de développement

................................
................................
.....................

5

c.

Maven

................................
................................
................................
................................
..........

6

d.

SVN (subversion)

................................
................................
................................
.........................

6

4.

Expression fonctionnelle du besoin

................................
................................
................................

8

a.

Une interface simple et claire

................................
................................
................................
.....

8

b.

Gestion de projet, de plusieurs fichiers
................................
................................
.......................

8

c.

Gestion de fichiers xml selon une DTD

................................
................................
........................

8

d.

Simplifier l'utilisation du langage xml pour l'utilisateur

................................
..............................

8

e.

Possibilité de configurer le programme

................................
................................
......................

9

f.

Portabilité de l'application

................................
................................
................................
..........

9

5.

Cadre de réponse

................................
................................
................................
..........................

10

a.

Interface Simple et claire

................................
................................
................................
...........

10

b.

Gestion d'un projet

................................
................................
................................
....................

11

c.

Ges
tion des fichiers xml selon une dtd

................................
................................
.....................

15

d.

Simplifier l'utilisation du langage xml pour l'utilisateur

................................
............................

16

e.

Possibilité de configurer l'application

................................
................................
.......................

20

f.

Portabilité de l'application

................................
................................
................................
........

21

g.

Création de fichiers DTD

................................
................................
................................
............

21

6.

conclusion

................................
................................
................................
................................
......

22




MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
3

sur
22

1.

I
NTRODUCTION



Au sein du second semestre de Licence 3, il nous a été demandé de réaliser un projet. Ce
projet est une matière a part entière qui reprend l’ensemble des acquis que l’on peut voir en cours et
qui nous offrent la possibilité de les mettre en pratique. Le pr
ojet s’étale sur un semestre complet et
s’attache à la matière INFO0605.


Ce projet se passe comme un véritable projet en entreprise, en effet nous avons un cahier
des charges avec les fonctionnalités auxquelles notre application doit répondre. Et comme e
n
entreprise, une date est fixée à laquelle nous devons rendre le projet. M. Rabat, étant notre
encadrant, a également pour rôle d’être client, il doit prendre possession de l’application à la date
prévue.


Comme en entreprise, tout au long du projet, des
réunions ont été réalisées avec M. Rabat
afin de suivre sa volonté, ses besoins. Le suivi nous a permis de cerner correctement ses attentes et il
fut alors plus facile de mettre en place une solution dans le but de répondre à ces besoins.


Il s’agit d’un
projet à long terme, en effet notre projet ne représente qu’une partie d’un
ensemble plus important. C’est à dire qu’il y aura des futures personnes susceptibles de reprendre ce
projet et de l’approfondir afin d’y ajouter des fonctionnalités ou de l’intégr
er au sein d’un
programme plus important. C’est une notion importante à prendre en compte lors de la réalisation
d’un projet de cette envergure.




MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
4

sur
22

2.

P
RESENTATION DU PROJE
T

a.

L
E CONTEXTE



Nous désir
ons réaliser une application
permettant d'exécuter des scrip
ts à distance via ssh.
Ces scripts doivent être au préalable transférés sur la plateforme (comme une grille telle que
Grid'5000 ou un calculateur tel que Romeo2) et ensuite être exécutés.


Pour réaliser ses différentes opérations, l'ensemble des procédure
s/commandes sont
décrites au sein de fichiers XML. Ces fichiers permettent de définir un ensemble de commandes
(procédure de connexion, méthodes de transfert, compte utilisateur...) et dépendent de la
plateforme, du gestionnaire de soumission ou encore de
l'application à exécuter.


L’application doit pouvoir gérer des projets de 4 fichiers de description XML définissant
l’ensemble des commandes du simulateur, de l’exécution, de l’infrastructure et de l’intergiciel
(gestionnaire de ressources).


À partir de
s fichiers XML,
l'application

doit être capable de transférer les fichiers nécessaires
et les exécuter.


b.

B
UT DU PROJET



Notre projet entre dans le cadre de cette application mais il s'arrête à la partie édition. En
effet, l
e but

principal

du projet est d
e réaliser un éditeur
capable de modifier facilement c
es fichiers
de description XML.


Pour cela, c
et éditeur doit être capable de gérer des projets formés par un ensemble de
fichiers XML
,

ainsi que de proposer différentes configurations
par défaut,...


De plus, i
l doit proposer une modi
fication simple de ces fichiers

car

cet éditeur peut être
utilisé par des utilisateurs ne connaissant pas la syntaxe XML.



MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
5

sur
22

3.

L
ES OUTILS UTILISE
S



Pour ce projet, nous avons utilisés différents outils qu'il est intéressant
de rappeler car ils
nous ont apporté une aide précieuse tout au long du développement.


a.

L
E LANGAGE JAVA



Le choix du langage utilisé pour réaliser s’est arrêté sur le JAVA, il nous a été proposé par
notre tuteur, M. Rabat. Il s’agit d’un choix judicieux
car le JAVA offre différentes caractéristiques
importantes pour le projet.


Premièrement, le JAVA possède une bibliothèque d’exécution indépendante du système
d’exploitation, il peut donc s’exécuter depuis n’importe quel système d’exploitation. Comme notre

application doit s'exécuter depuis n'importe quel système d'exploitation, c'est la raison principale de
notre choix.


De plus, le JAVA est un langage de programmation orienté objet, il s’agit d’une technique de
programmation qui se concentre sur les donné
es (objets) et sur les interfaces avec ses objets. Le
JAVA est langage relativement sécurisé, en effet, il n’est pas besoin d’allouer ou de libérer la
mémoire utilisée, un «garbage collector» s’en occupe, cela évite ainsi les fuites mémoires.


Pour finir,

le JAVA est langage relativement proche du C++, qui est utilisé de plus en plus dans
le milieu professionnel, ce qui en fait un langage
intéressant à connaître pour des étudiants en
informatique
.


b.

L
ES ENVIRONNEMENTS DE

DEVELOPPEMENT



Pour le développemen
t de notre application nous avons utilisé deux IDE différents : Eclipse et
NetBeans, qui sont tous deux des IDE (Integrated Development Environment) libres.


Eclipse permet de créer des projets de développement mettant en œuvre n'importe quel
langage de p
rogrammation. Il est principalement écrit en Java (à l'aide de la bibliothèque graphique
SWT, d’IBM), et ce langage, grâce à des bibliothèques spécifiques, est également utilisé pour écrire
des extensions.


Il nous a fortement aidés à la réalisation de not
re projet en JAVA, notamment avec l’outil
d’auto
-
complétion intégré, qui permet de proposer l’ensemble des possibilités du langage pour un
début de mot tapé.


Le second IDE que nous avons utilisé s'appelle NetBeans. Le plus de celui
-
ci pour la
réalisation

de ce projet est la création d'interface graphique. En effet, contrairement à Eclipse qui
MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
6

sur
22

donne très peu de maniabilité et d’interactivité dans la création de interface, Netbeans permet de
créer une fenêtre simplement avec la notion de «glisser
-
déposer».


Pour finir, l
’utilisation d’un IDE permet également d’avoir accès à un mode Debugger, qui
permet de placer des points d’arrêt et d’exécuter le code ligne après ligne afin de pouvoir consulter
l’ensemble des valeurs des variables et voir ainsi les différen
tes erreurs que peut avoir l’application.


c.

M
AVEN




Maven est un outil logiciel libre pour la gestion et l’automatisation de production des projets
logiciels JAVA. L’objectif recherché est comparable au système Make sous Unix : produire un logiciel
à parti
r de ses sources, en optimisation les tâches réalisées à cette fin et en garantissant le bon ordre
de fabrication. Maven utilise une approche déclarative, où le contenu et la structure du projet sont
décrits, plutôt qu'une approche par tâche utilisée par e
xemple par Ant ou les fichiers make
traditionnels. Cela aide à mettre en place des standards de développements et réduit le temps
nécessaire pour écrire et maintenir les scripts de build.


Une partie de la puissance de Maven vient des pratiques standardis
ées qu’il encourage. En
effet, lors de la création d’un projet sous Maven, il créé lui
-
même une arborescence de dossier
simple et claire. Cette arborescence sera la même pour chaque projet JAVA créé à l’aide de Maven,
ce qui permet au développeur familiari
ser avec Maven de ne pas perdre de temps à reconnaitre
l’arborescence du projet et reconstruire les scripts de compilation.


Maven fonctionne autour de plugin qu’il peut télécharger directement depuis internet, il
peut générer automatiquement l’applicatio
n au format JAR, l’API de l’application selon les
commentaires JAVADOC placés dans le code JAVA, et peut également réaliser l’ensemble des tests
unitaires.


d.

SVN

(
SUBVERSION
)



Subversion, ou SVN, est un système de gestion de sources et de contrôle de versions. Il
permet de conserver un historique des différentes versions des fichiers d’un projet. Il est alors
possible de réaliser un retour vers une version antérieure de ce proje
t. L’ensemble des modifications
réalisées sur le projet peuvent être accompagnées d’un commentaire. Cette fonction permet de
consulter un historique des modifications avec leur nature, leur date, leur auteur.


Le principe du SVN est de copier l’ensemble d
es sources sur le poste client et de synchroniser
avec le serveur SVN par internet ou réseau local. Il est ainsi possible de travailler en mode hors
-
ligne
et d’envoyer les modifications lorsque l’on est connecté.


De plus, SVN permet à des utilisateurs di
stincts et souvent distants de travailler ensemble sur
les mêmes fichiers. En effet il n’est pas nécessaire aux utilisateurs de se transférer les dernières
MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
7

sur
22

versions du projet, il suffit de mettre à jour la copie locale de ce projet depuis le serveur SVN. S
VN
propose une gestion des conflits si le fichier locale ne possède pas la même version que le fichier
distant, il propose alors le choix entre les différents fichiers possibles et il suffit à l’utilisateur de
choisir le fichier voulu.


Le projet actuel a

été mis sur le serveur SVN de Google, grâce à la fonctionnalité Google Code
et Google (moteur de recherche des projets hébergés :
http://code.google.com/hosting/
) et il est
possible de consulter les sources
du projet à l’adresse :
http://code.google.com/p/xml
-
project/
.


Sous Unix ou Mac, il est nécessaire d’utiliser la commande «svn» dans le terminal, tandis que
sous Windows, le logiciel «Tortoise» est dis
ponible pour accéder à un projet sous SVN.



MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
8

sur
22

4.

E
XPRESSION FONCTIONNE
LLE DU BESOIN

a.

U
NE INTERFACE SIMPLE
ET CLAIRE



L’application étant destinée à des utilisateurs non informaticiens, il est nécessaire de réaliser
l’application afin que celle
-
ci soit la plus
intuitive et simple possible. L’utilisateur «lambda» doit
pouvoir comprendre et utiliser l’application rapidement. De plus, le travail avec une application
simple et claire est plus facile, en effet il est difficile de travailler correctement lorsque l’app
lication
que l’on utilise est surchargée et imposante.


b.

G
ESTION DE PROJET
,

DE PLUSIEURS FICHIER
S



L’application doit pouvoir gérer la notion de projet, en effet le contexte impose une liaison
entre quatre fichiers XML. Chacun définissant les caractéristiq
ues d’un élément particulier : le
simulateur, l’exécution, l’infrastructure et l’intergiciel. La notion de projet permet de créer des
campagnes de calculs différentes selon les informations renseignées dans les fichiers XML. Un projet
permet de lier les qu
atre fichiers XML sous un même nom de projet et ainsi il est possible de
sauvegarder différentes configurations possibles.


c.

G
ESTION DE FICHIER
S

XML SELON UNE
DTD



Afin de respecter la syntaxe XML imposée par l’environnement de l’application, les fichiers

XML doivent respecter une DTD. La DTD (Document Type Definition) permet de définir les balises et
leurs attributs, l’imbrication des balises ainsi que les balises optionnelles ou obligatoires. On peut
définir la DTD comme le fichier définissant l’infrastr
ucture du fichier XML. Le fichier XML doit être
valide par rapport à ce fichier afin de pouvoir être déployé dans la campagne de calculs.



d.

S
IMPLIFIER L
'
UTILISATION DU LANGA
GE XML
POUR

L
'
UTILISATEUR



Le langage XML est un langage que l’on peut dire «à bal
ises», en effet il contient un
ensemble de balises dans lesquelles on peut stocker des données. Il s’agit d’un langage assez
complexe pour une personne qui n’est pas familiarisé avec l’informatique. Pour cela, l’application
doit pouvoir proposer de façon s
imple une méthode afin de remplir les différents fichiers XML tout
en lui laissant le contrôle. L’utilisateur «lambda» doit pouvoir saisir facilement, tandis que
l’utilisateur confirmé doit pouvoir avoir plus de contrôles et d’accès.

MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
9

sur
22

e.

P
OSSIBILITE DE
CONFIGURER LE PROGRA
MME



Afin de donner plus de flexibilité à l’application, certains points de configuration doivent être
mis en place.


Par exemple, les fichiers DTD sont identiques pour chaque projet, cependant il est possible
qu'à l'avenir, certaines

modifications soient apportées ou alors testées. Il est donc nécessaire de
pouvoir
changer ses fichiers DTD par défaut.


De plus, certaines configurations de fichiers XML vont être pré définis. Il faut donc laisser la
possibilité à l'utilisateur d'utilis
er directement à la création d'un projet ces fichiers XML pré
configurés.


Ensuite
, l’application

générale

doit pouvoir exécuter l’ensemble de ces fichiers XML à l’aide
d’une commande. Afin de ne pas figer l’application, cette commande
doit être

configurab
le dans
l’application, il est ainsi possible de choisir la commande que l’on souhaite utiliser pour exécuter le
projet.

Cette fonction d'exécution étant supplémentaire au projet INFO0605, seule la configuration
sera mise en place.


f.

P
ORTABILITE DE L
'
APPLIC
ATION



Afin de simplifier au maximum le déploiement et d'améliorer au maximum la portabilité de
l'application, il est important de mettre en place un système qui permet de n'avoir besoin que du JAR
de l'application pour l'exécuter. Tous
les fichiers
nécessaires à l'application doivent être incorporés
au JAR afin d'être déployé dans le dossier courant de l'application.


De plus, l'application doit pouvoir être exécutée depuis n'importe quel système
d'exploitation, d'où l'utilité principale du langage J
AVA.



MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
10

sur
22

5.

C
ADRE DE REPONSE

a.

I
NTERFACE
S
IMPLE ET CLAIRE



Le premier travail que nous avons réalisé est le développement de l'aspect général de notre
application et plus particulièrement la conception de l'interface.


Selon les consignes de notre tuteur, nous a
vons choisi une interface minimaliste qui va
directement à l'essentiel sans passer par de multiples fenêtres ou des menus avec plusieurs niveaux.


Une interface minimaliste ne veut pas dire une interface sans intérêt, sans rôle. Comme
l'application doit po
uvoir gérer un projet contenant plusieurs fichiers
,

nous avons
opté

pour interface
avec un système d'onglets. En effet, chaque fichier du projet va être ouvert

dans un onglet différent,
cela donne la possibilité à l'utilisateur de passer d'un fichier à l'a
utre directement, sans passer par un
menu du type "ouvrir un fichier".


Afin de gérer les différentes options de l'application nous avons ajouté à cette interface une
barre de menu contenant seulement trois parties :



La traditionnelle partie "
F
ichier", qui

contient les actions
typique
s

d'une application
comme nouveau, ouvrir, enregistrer, ... Ces fonctions s'applique
nt

toujours au projet
entier et non à l'onglet courant.



Une partie "
V
ue
s
", qui sera expliquée dans une partie suivante



Et une partie "
O
util
s
",
elle même expliquée plus tard


La dernière partie de notre interface permet d'afficher et de modifier les informations de
chaque onglet (de chaque fichier). C'est la partie principale de l'application.


Voici notre interface :


MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
11

sur
22

b.

G
ESTION

D
'
UN

PROJET

i.

L
A

REPRESENTATION

D
'
UN

PROJET



Afin

de pouvoir

gérer un projet dans une application, il est nécessaire de se demander ce que
doit contenir un projet. Dans notre cas, un projet doit contenir obligatoire
ment

un nom, un
emplacement, une liste de fichiers. Auss
i nous avons ajouté la date de création.

Il existera un fichier
pour définir le simulateur, un pour l'infrastructure, un pour l'exécution et un pour l'intergiciel.


Ensuite, il faut pouvoir représenter un projet dans le but de pouvoir accéder à ses attribu
ts
de manière simple et efficace. Étant donné que notre application porte sur la gestion de fichier
XML
,
il nous a paru assez évident d'utiliser ce format afin de modéliser un projet.


Nous avons donc créé une structure
XML

représentant un projet ainsi que

la DTD
correspondant
e
. Cette structure contient plusieurs éléments dont voici l'arborescence :

<projet>


<name> </name>


<datecreation></datecreation>


<emplacement> </emplacement>


<fichiers>



<infrastructure>




<nom> </nom>



</infrastructure>



<simu
lateur>




<nom> </nom>



</simulateur>



<execution>




<nom> </nom>



</execution>



<intergiciel>




<nom> </nom>



</intergiciel>


</fichiers>

</projet>


Nous avons choisi de décomposer au maximum chaque élément afin de pouvoir facilement
ajouter
certains éléments qui pourraient devenir intéressant dans l'avenir de l'application. Par
exemple pour les éléments "infrastructure", "simulateur", "execution" et "intergiciel" nous avons
choisi de leur ajouter un élément "nom" qui aurait pu être supprimé
,

car il est unique et donc il aurait
pu être placé dans l'élément parent. Cependant ce choix permet d'ajouter simplement de nouveaux
éléments à la suite de l'élément "nom".


Pour terminer la représentation d'un projet, nous avons choisi une extension .prj
pour notre
fichier projet qui est en fait un fichier XML.



MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
12

sur
22

ii.

A
RBORESCENCE D
'
UN PROJET



Une fois notre projet représenté par son fichier XML, nous nous sommes demandé comment
organiser l'ensemble des fichiers nécessaires à un projet. En effet un projet cont
ient plusieurs
fichiers, tout d'abord le fichier projet

(.prj) ainsi que sa DTD (.dtd)
,

puis l'ensemble des fichiers

XML
qu'il

contient
,

ainsi que pour chacun sa DTD.


Au début, nous avons choisi une arborescence qui sépare chaque type de fichiers : un dos
sier
(de même nom que le projet) qui contient le fichier projet (.prj) ainsi qu'un autre dossier (nommé
fichiers) qui contient lui
,

deux dossiers, un dossier
"
xml
"

contenant l'ensemble des fichiers XML et un
dossier
"
dtd
"

contenant l'ensemb
le des fichiers
DTD.

Nous obtenons

donc une arborescence de ce type
:


Dossier "projet_toto"



Projet_toto.prj



Dossier "fichiers"




Dossier "xml"





Titi.xml





...




Dossier "dtd"






Titi.dtd





...


Cette arborescence nous paraissait la plus logique
,

cependant
nous nous sommes rendu
compte plus tard qu'elle posait quelques problèmes lors de la vérification des fichiers XML en
fonction de leur DTD associé.
Effectivement, le chemin de la DTD d'un fichier XML est inscrit dans
celui, or dans notre cas nous utilisons

les chemins relatifs et plus particulièrement l'accès au
répertoire parent, ce qui donne par exemple :




"../dtd/Titi.dtd"



Cependant, l'accès au répertoire parent par le biais de "../" engendr
e

une erreur lors de la
vérification du fichier XML. Pour pallier à ce problème, nous avons décidé de modifier l'arborescence
pour supprimer cet accès au répertoire parent. Nous obtenons donc une arborescence du type :



Dossier "projet_toto"



Projet_toto
.prj



Dossier "fichiers"




Titi.xml




...




Dossier "dtd"






Titi.dtd





...


Cette arborescence permet d'accéder au fichier DTD à partir du fichier XML en utilisant
seulement l'accès au répertoire courant
". /dtd/Titi.dtd"

et donc de supprimer notr
e problème.

MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
13

sur
22

iii.

S
A GESTION AU SEIN DE

L
'
APPLICATION



Maintenant que nous savons comment est représenté notre projet et comment il est
hiérarchisé sur notre disque dur, il est intéressant d'expliquer comment

l'utilisateur va gérer un
projet au sein de l'applic
ation.



L'ensemble des possibilités de l'utilisateur se trouve dans notre menu, dans la partie
"Fichier". L'utilisateur va pouvoir créer un nouveau projet, ouvrir un projet existant, enregistrer ou
enregistrer sous un projet et aussi le fermer.


Voici le

menu :



Les fonctionnalités ouvrir, enregistrer, enregistrer sous et fermer sont des fonctions typiques
et sont similaires à quasiment tout
es

autre
s

application
s
.

Par exemple, pour l'ouverture d'un projet,
l'application ouvre un explorateur de fichier
s

qui filtre les fichiers avec une extension .prj.


Cependant, la création d'un nouveau projet nécessite la création d'une nouvelle boîte de
dialogue qui va permettre à l'utilisateur de spécifier l'ensemble des paramètres d'un projet :



Son nom via un champ t
exte



Son emplacement via un explorateur



L'ensemble des fichiers (simulateur, infrastructure,...) via des listes de choix ("combobox").
Chaque liste est initialisée avec des fichiers XML prédéfinis où certain
s

champs sont déjà pré
remplis
, ou le cas par
défaut où les champs du fichier XML

seront vides, dans ce cas
l'utilisateur devra en plus spécifier le nom qu'il donne au fichier à l'aide du champ texte à
côté.




MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
14

sur
22

Voici cette boîte de dialogue :





Lorsque l'utilisateur valide la création d'un nouveau projet, l'application vérifie l'ensemble
des champs
nécessaires
, puis cré
e l'arborescence du proje
t dans l'emplacement spécifié.

Enfin, elle
copie les fichiers nécessaires
(XML et DTD)
dans les répertoi
res correspondant
s
. L'utilisateur ne
spécifie pas les fichiers DTD car ils sont identiques pour chaque projet.



MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
15

sur
22

c.

G
ESTION DE
S

FICHIERS XML SELON U
NE DTD

i.

LA C
LASSE
D
OC
X
ML



Afin de gérer les
fichiers

XML à l'intérieur de l'application, c'est à dire de façon
transparente
pour l'utilisateur, nous avons créé une classe nommé "DocXML" qui contient, entre autre, un attribut
"
org.w3c.dom.Document
" qui est un objet disponible dans le langage java qui permet de représenter
un
fichier

XML sous forme d'objet
, de docume
nt XML
.

Nous parlerons donc maintenant de document
XML qui est une représentation, une modélisation sous forme d'objet d'un fichier XML.


Cette classe va nous permette de définir l'ensemble des fonctions nécessaires à notre
application pour gérer les doc
uments XML, comme par exemple la récupération
d'un élément

ou
alors l'ajout et la suppression d'élément.


L'objet "
org.w3c.dom.Document
" est l'élément

principal de notre classe, il contient déjà
plusieurs fonctions qui permettent de gérer les documents XML
. Cependant, elles ne sont pas
forcément utilisables directement pas notre application, c'est pourquoi nous avons créé cette classe
qui s'adapte directement aux besoins de notre application.

Par exemple nous avons créé une
fonction
qui retourne le contenu
du document XML sous forme
de chaîne de caractères. Cette
fonction va être utilisée lors des enregistrements ou aussi avec la vue "éditeur" que nous allons voir
plus tard.


Nous travaillerons la plus part du temps avec ces documents XML qui seront créés à
l'ouverture d'un projet à partir des fichiers XML. Toutes les modifications faites par l'utilisateur se
feront sur ces documents et non sur les fichiers directement. Ce n'est qu'à l'enregistrement que les
fichiers XML seront modifiés en récupérant le conte
nu de ces documents XML.


ii.

L'
ANALYSE



Le second point important de la gestion d'un
fichier

XML est son analyse. En effet l'un des
intérêts du langage XML est qu'il est formalisé. Il est donc nécessaire de vérifier cette structure au
sein de l'application. De plus, notre applicat
ion doit gérer

la validation par un fichier DTD. Cette
validation p
ermet
en plus
de vérifier la syntaxe du fichier XML
, de valider le contenu de celui
-
ci.


On peut facilement faire une analogie entre cette partie et le cours INFO0602 "langage et
compilation". La vérification du fichier XML est comparable à "Lex" qui véri
fie la syntaxe du fichier
tandis que "Yacc" valide une grammaire comparable à un fichier DTD.


La validation de nos fichiers XML va s'effectuer lors de la création de nos documents XML, via
le constructeur de notre classe DocXML. Pour cela, nous avons
utilisé des fonctions des bibliothèques
"
javax.xml.parsers"

et "
javax.xml.transform
" inclues dans JAVA. Ces bibliothèques permettent avec
quelques options de construire notre document XML tout en vérifiant la syntaxe XML ainsi que

la
validation par le fich
ier DTD spécifié dans le fichier XML.

MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
16

sur
22

d.

S
IMPLIFIER L
'
UTILISATION

DU LANGAGE XML POUR

L
'
UTILISATEUR

i.

M
ISE EN PLACE DE DEUX

VUES



Cette partie est certainement la plus importante du projet car elle représente l'utilité même
de notre application. Effectivement
si nous ne trouvons pas de façon de simplifier la modification des
fichiers XML, seul la gestion de projet est intéressante pour notre application.


Nous avons donc mis en place, toujours grâce aux indications de notre tuteur, un système de
vue qui permet
à notre application de proposer de vues différentes. A l'instar de logiciel comme
"NetBeans" ou "
Dreamweaver
" qui propose plusieurs vues, une on l'on voit le véritable code et une
autre ou l'on voit le rendu
, nous avons décidé de créer une vue "éditeur" qu
i propose le fichier XML
brut tel un éditeur tout simple et une vue "formulaire" qui propose un rendu plus simple à
comprendre et à modifier.


Ces deux vues sont accessibles depuis le menu "Vues", la vue par défaut à l'ouverture d'un
projet est la vue "for
mulaire" car elle permet de ne pas décourager un utilisateur "lambda" qui n'a
jamais utilisé un fichier XML.


ii.

V
UE EDITEUR
:

L
'
UTILISATEUR A

TOUT LE CONTROLE



La vue "éditeur" est la vue la plus simple à réaliser. Elle consiste à récupérer le contenu

du
d
o
cument XML et à l'afficher dans une zone de texte modifiable.


Voici cette vue :


MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
17

sur
22


Lors de notre première mis en place de cette vue, nous nous basions sur le fichier XML
directement, cependant cette manière de faire posait des problèmes lorsque l'utilisat
eur
passait

d'une vue à l'autre. Effectivement, l'autre vue se base sur le document XML en mémoire et non sur le
fichier XML véritable, donc pour qu'une modification

faite par l'utilisateur dans la vue formulaire soit
effective dans la vue "éditeur", il fa
llait que celui
-
ci enregistre le projet pour que le fichier XML soit
écrasé par le contenu du document XML en mémoire.


Pour corriger se problème, nous avons créé une fonction qui récupère le contenu du
document XML et c'est ce contenu qui nous affichons d
ans la zone de texte modifiable.


Dans cette vue, l'utilisateur à tous les pouvoirs sur son document XML, il peut modifier le
chemin du fichier DTD correspondant, supprimer n'importe quelles balises,... Elle correspond aux
utilisateurs confirmés qui ne ser
aient pas satisfait de l'autre vue, mais elle n'offre en réalité aucun
avantage par rapport à un éditeur de texte classique.


La validation de ce document XML ne se fait que lors d'un changement de vue ou lors de
l'enregistrement.
L
'utilisateur
se rend

com
pte

seulement à ces étapes qu'il a fait des erreurs et que
son document n'est plus valide.


Cette vue est nécessaire car il est toujours intéressant de pouvoir accéder à l'ensemble du
fichier sans contrainte, mais dans la plus part des cas, la vue suivante

sera beaucoup plus adaptée est
simplifiera grandement la modification de tous les fichiers XML de chaque projet.


iii.

V
UE FORMULAIRE
:




La seconde vue nommée "formulaire" tient son nom de l'aspect général de celle
-
ci. En effet,
cette vue ressemble fortement

à un formulaire type que l'on trouve un peu partout.


Voici un aperçu de cette vue :


MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
18

sur
22


Dans cette vue chaque élément du document XML est représenté dans une ligne qui contient
son nom et ensuite :



Pour un élément père (qui peut contenir un ou plusieurs
fils) : on deux boutons qui
permette d'ajouter un fils ou alors de supprimer cet élément (y compris ses fils).



Pour un élément fils (qui ne peut pas contenir de fils) : on un champ texte qui permet
de modifier la valeur de l'élément et un bouton pour suppr
imer cet élément.




Pour afficher cette vue, il est donc nécessaire de parcourir chaque élément du document
XML (grâce aux fonctions de la classe DocXML), de tester si celui
-
ci est un père ou un fils et d'ajouter
les éléments correspondants. Les champs te
xtes sont initialisés dès l'ouverture par les valeurs
contenues dans chaque élément fils.



La partie la plus compliquée dans le développement de cette vue a été la mise en place des
fonctions d'ajout et de suppression. En effet, afin de pousser au
maximum la simplicité d'utilisation
tout en respectant la validation de la DTD, il est nécessaire de proposer ou de refuser à l'utilisateur
certaines actions.



Effectivement, lorsque l'utilisateur choisit d'ajouter un élément, il faut vérifier tout d'abor
d si
l'utilisateur peut ajouter un élément tout en respectant la DTD. Si l'ajout est possible, il faut proposer
à cet utilisateur quels sont les éléments qu'il peut ajouter. De même si l'utilisateur veut supprimer un
élément, il faut au préalable vérifier
que l'élément n'est pas obligatoire. De plus, il est possible dans
un fichier DTD de spécifier des choix, c'est à dire qu'un élément père doit contenir un élément a ou
un élément b ou un élément c mais pas plusieurs pour le même élément père. Concrètement,

dans
ce cas là, lors de la suppression d'un élément l'application oblige l'utilisateur à choisir l'élément qui
va remplacer l'élément à supprimer.



Voici quelques exemples de dialogue avec l'application :











Pour pouvoir
proposer ces différents choix, il a fallut trouver un moyen de représenter le
fichier DTD en mémoire afin de pouvoir accéder à ses différents éléments et donc savoir quelles
possibilités offrir à l'utilisateur.

MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
19

sur
22


Après plusieurs recherches sur l'Internet i
nfructueuses pour trouver des objets JAVA gérant
les fichiers DTD de façon similaire aux objets concernant les fichiers XML. Nous avons décidé de créer
nos propres objets. Nous avons développé la classe ElementDTD qui représente un élément d'un
fichier DTD
. Afin de gérer

l'ensemble d'un fichier DTD, nous parcourons le fichier en question et à
chaque élément DTD rencontré nous créons en fonction de ses attributs un ElementDTD que nous
ajoutons ensuite dans une liste (de type ArrayList). C'est cette liste qui

sera notre représentation en
mémoire des différents fichiers DTD utilisés.



Afin de représenter tous les cas possibles d'élément DTD, c'est à dire : est
-
ce qu'il peut être
présent plusieurs fois dans son élément père,

est
-
il obligatoire, doit
-
il être rem
placé par un autre
élément en cas de suppression, ou quels sont ses fils possibles,...

Il faut définir plusieurs attributs à
notre ElementDTD :



Son nom



Son type : si c'est un père ou un fils



Son opérateur : qui représente le symbole de l'élément DTD (+ :
au moins une fois, * :
présent de 0 à n fois, ? : 0 ou 1 fois, | quand c'est un choix, ou rien : unique et
obligatoire)



Sa liste de fils (liste d'ElementDTD) : dans le cas où c'est un père



Sa liste d'amis (liste d'ElementDTD) : dans le cas où c'est un choi
x



C'est donc
grâce à cette liste d'ElementDTD que l'application propose les différentes
possibilités à l'utilisateur. Ce système a deux points positifs, tout d'abord il permet de respecter
directement la DTD du fichier puis aussi il permet de simplifier
grandement la modification du
document XML car il permet à l'utilisateur de ne pas se servir des balises XML et aussi de ne pas se
demander quel élément ajouter ou supprimer car c'est l'application qui le fait pour lui.



MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
20

sur
22

e.

P
OSSIBILITE DE CONFIG
URER L
'
APPLIC
ATION



À ce stade du développement, l'application est fonctionnelle
,

cependant elle n'est pas du
tout flexible et la plus part des configurations son en "dur" dans le code.

Ce fait est un très gros
problème car une application de ce type ne permet aucune
évolution ou mise à jour.


Le point important qui va être développé, est la possibilité au sein de l'application de
modifier chaque fichier DTD qui est utilisé par défaut lors de la création d'un projet. Cette
configuration ne consiste pas à modifier le fi
chier DTD en lui même mais à spécifier un nouveau
fichier DTD qui sera pris par défaut pour les nouveaux projets créés.


Pour cela, une fenêtre de configuration a été créée, elle permet de lister le contenu des
répertoires des fichiers DTD de chaque élémen
t du projet (infrastructure, intergiciel,...) et de
permettre à l'utilisateur de choisir quel fichier prendre en compte par défaut. Il suffit donc à
l'utilisateur d'ajouter, dans le répertoire contenant les fichiers DTD de base de l'infrastructure par
exem
ple, un nouveau fichier DTD correspondant à un nouveau type d'infrastructure. Et ensuite de le
sélectionner dans la fenêtre de configuration.



De plus, nous avons ajouté dans cette fenêtre de configuration, la possibilité de modifier la
taille de la fenêt
re principale de l'application
selon le choix de l'utilisateur. Cette modification ne sera
prise en compte qu'après le redémarrage de l'application.


Ensuite, il est possible de modifier le manager, c'est à dire la commande qui sera chargée
d'e
xécuter dans

l'avenir du projet
, l'ensemble des fichiers XML.


Voici cette fenêtre de configuration :



Afin de pouvoir sauvegarder cette configuration, pour les prochaines utilisations de
l'application. Nous avons utilisé un fichier "properties" assez typique d'une
application JAVA qui
permet de récupérer des valeurs dans ce fichier à l'aide d'une organisation clé / valeur.

MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
21

sur
22

f.

P
ORTABILITE DE L
'
APPLICATION



Premièrement, il faut rappeler que le langage JAVA permet déjà une grande portabilité de
l'application car il
permet d'exécuter une application JAVA indépendamment du système
d'exploitation de la machine hôte.


De plus, l'ensemble des fichiers nécessaires au déroulement de l'application (les images, les
fichiers DTD et XML de base) sont stockés dans le fichier JAR
, l'exécutable de l'application.


À chaque démarrage de l'application, une fonction est chargée de tester le contenu du JAR et
ensuite de vérifie si l'ensemble de ces fichiers sont présents dans le répertoire courant de
l'application et dès qu'un fichier e
st manquant l'application le copie dans le bon répertoire.
Concrètement, cette fonction va recréer la même arborescence présente dans son JAR dans le
répertoire courant de l'application.


Ce système permet donc de déployer une application viable en déploya
nt seulement
l'exécutable (le JAR) de l'application. C'est ensuite l'application au démarrage qui va se charger de
copier l'ensemble des fichiers qu'elle a besoin dans le répertoire courant.


g.

C
REATION DE FICHIERS
DTD



L'un des tr
avaux

que nous a demandé Mr RABAT

a été de créer des fichiers DTD à partir de
diverses informations réelles basées sur une configuration actuellement mis en place. Notre tuteur
nous a fourni en plus de ces informations des exemples de fichiers XML correspondant
s

à ses
indications
.


Cette partie ne fait pas vraiment partie de notre développement, mais ce sont les fichiers que
nous utilisons actuellement de base pour notre application. Ce travail est donc plus en rapport avec
le contexte de notre projet.


Voici un

exemple de fichier DTD que nous avons créé et qui est le fichier DTD par défaut de
base dans notre application pour l'exécution :

<!ELEMENT execution (parameter*) >

<!ELEMENT parameter (name,(values|interval)) >

<!ELEMENT name (#PCDATA) >

<!ELEMENT value
s (value+) >

<!ELEMENT value (#PCDATA) >

<!ELEMENT interval (minimum,maximum,step) >

<!ELEMENT minimum (#PCDATA) >

<!ELEMENT maximum (#PCDATA) >

<!ELEMENT step (#PCDATA) >



MEHAULT Maxime

NICOLAS Rémi

INFO 0605

Page
22

sur
22

6.

CONCLUSION



Nous souhaitons tout d’abord remercier M. Rabat pour son soutien et s
on aide pour réaliser
ce projet.


Ce projet, mis en place en INFO0605, nous a permis de nous mettre en situations
d’entreprise. En effet, M. Rabat étant le client, il était de notre devoir de répondre à ses besoins et
de respecter les contraintes qu’il im
posait. Le suivi du projet, comme pour les projets professionnels,
nous a permis de correctement cerner les objectifs du projet. Nous avons pu mettre en pratique
l’en
semble des nos acquis

afin de réaliser une application propre et claire. Ce projet nous a
forcés à
utiliser des outils que l’on ne connaissait nécessairement pas, des outils utilisés dans le monde
professionnel tel que Maven ou SVN. Comme dans le monde professionnel, ce projet est susceptible
d’être repris dans le futur, ce qui nous a permis de

mettre un maximum de commentaire et d’aide
pour faciliter le travail des futurs programmeurs.


L’application répond à l’ensemble des objectifs demandés par M. Rabat malgré les différents
problèmes que nous avons pu rencontrés. Nous avons du surmonter ces
problèmes afin de pouvoir
répondre à l’ensemble des attentes de notre encadrant. Nous avons du réaliser différentes
recherches sur
l'I
nternet afin de pouvoir répondre à ces problèmes.