Rapport de projet - plateforme de certification de documents XML

Rémi Godard
Vivian Perez
Florian Pérugini
Bertrand Vitrant
Professeur responsable du projet :
Mr Fabrice LEFEVRE
Rapport de projet
Réalisation d’une plateforme Web de certification de documents XML
Université d’Avignon – Année 2007/2008 – Département Informatique
SOMMAIRE
1
2
3
4
Introduction ........................................................................................................................ 3
La mission .......................................................................................................................... 3
L’organisation du travail .................................................................................................... 4
La reprise de l'existant........................................................................................................ 4
4.1
Introduction ................................................................................................................ 4
4.2
Algorithme de comparaison de XyDiff ...................................................................... 5
4.3
Notre algorithme de comparaison .............................................................................. 6
4.4
Conclusion.................................................................................................................. 6
5
Les orientations choisies .................................................................................................... 7
5.1
Les choix de langages ................................................................................................ 7
5.2
Un comparateur à un niveau....................................................................................... 7
5.3
La répartition du travail.............................................................................................. 7
6
Les fonctionnalités ............................................................................................................. 8
6.1
Fonctionnalités de l’utilisateur ................................................................................... 8
6.1.1
Dépôt de fichier à comparer ............................................................................... 8
6.1.2
Consultation des résultats................................................................................... 8
6.2
Fonctionnalités du rédacteur ...................................................................................... 8
6.2.1
Dépôt d’un fichier modèle.................................................................................. 8
6.2.2
Gestion des fichiers ............................................................................................ 8
6.2.3
Récupération des fichiers ................................................................................... 8
6.3
Fonctionnalités de l’administrateur ............................................................................ 9
6.3.1
Ajout d’un nouveau profil .................................................................................. 9
6.3.2
Modification des profils existants ...................................................................... 9
7
Les données ...................................................................................................................... 10
8
Le problème de la sécurité................................................................................................ 11
8.1
Identification à l'aide du LDAP................................................................................ 11
8.2
Identification selon le profil ..................................................................................... 11
9
La réalisation du projet..................................................................................................... 12
9.1
Introduction .............................................................................................................. 12
9.2
La création de la plateforme Web ............................................................................ 12
9.2.1
La réalisation de toutes les fonctionnalités ...................................................... 12
9.2.2
La mise en forme – CSS – Javascript - Ajax.................................................... 12
9.3
La création du comparateur XML............................................................................ 14
9.3.1
Les différentes étapes dans l'avancement......................................................... 14
9.3.2
Le choix de l'architecture de l'arbre des différences ........................................ 14
10
Les difficultés rencontrées et leurs solutions ............................................................... 15
10.1 Les documents XML générés par OpenOffice......................................................... 15
10.2 La ressemblance des nœuds et le choix du meilleur ................................................ 15
11
La présentation des résultats ........................................................................................ 16
11.1 La présentation des résultats en terme XML............................................................ 16
11.2 La présentation des résultats avec transparence du XML ........................................ 16
12
La validation des programmes – Tests ......................................................................... 18
12.1 La validation de la plateforme.................................................................................. 18
12.2 La validation du comparateur................................................................................... 18
13
Conclusion.................................................................................................................... 29
ANNEXES ............................................................................................................................... 30
2
1 Introduction
Durant l’année, nous avons dû réaliser un projet qui se décomposait en deux parties
principales.
La première phase consistait à réaliser un cahier des charges de notre projet ainsi que
prévoir les outils nécessaires au développement, et faire un planning prévisionnel. De plus une
prévision de la répartition du travail devait être fournie.
La seconde étape consistait à concevoir ce projet qui s’intitule « Réalisation d‘une
plateforme Web de certification de documents XML ». Ce rapport traitera donc de la
conception de la plateforme et du comparateur XML.
Nous présenterons la mission à réaliser, l’organisation au sein du groupe, les solutions
choisies ainsi que celles qui auraient pu être envisagées, les fonctionnalités de l'application,
les modèles de données, la sécurité de la plateforme, la reprise de l’existant, la réalisation du
projet ainsi que les difficultés que nous avons rencontrées, puis la présentation des résultats et
les tests de validation.
2 La mission
Le but de ce projet a été de réaliser une plateforme Web permettant de certifier des
documents XML.
Afin de permettre l’utilisation à distance, nous avons choisi de mettre à disposition le
comparateur XML sur une plateforme Web.
Le document testé sera comparé à un document modèle qui aura été préalablement
déposé.
Le comparateur doit être générique afin de comparer divers documents à partir du
moment où leur structure est basée sur le langage XML. Par exemple les fichiers au format
OpenDocument de la suite OpenOffice sont en réalité des archives, qui contiennent des
fichiers XML décrivant le document. Ils peuvent donc être comparés.
Cette plateforme permet essentiellement selon le profil de l'utilisateur de déposer un
fichier modèle ou de comparer un document.
Deux cas ont été choisis afin de tester la compatibilité des documents avec notre
comparateur XML :
• la correction des examens rendus par les étudiants passant l’évaluation C2I
(Certification Informatique et Internet),
• la validation de format des fiches de compte rendu de projet des étudiants en M1 de
l’IUP GMI d’Avignon
3
3 L’organisation du travail
Un planning prévisionnel a été rédigé lors de la première phase du projet (pendant le
premier semestre), il aura été bien respecté dans l’ensemble. Nous avons modifié et ajouté
quelques étapes, comme la présentation des résultats d’une comparaison ou l’intégration de
l’annuaire LDAP de l’université d’Avignon.
Notre groupe était composé de quatre personnes, le travail a été reparti entre ces quatre
membres.
Un des objectifs notamment était que tout le monde conçoive le comparateur de près ou
de loin.
La conception du projet s’est découpée en deux grandes parties :
• La réalisation de la plateforme Web
• La réalisation du comparateur XML.
Une fois le projet fini, différents rapports ont été rédigés comme les documentations
techniques pour ceux qui reprendront ou utiliseront le projet, un manuel d’utilisateur qui
explique le fonctionnement de la plateforme ainsi que ses fonctionnalités et enfin un rapport
reprenant l’ensemble de ce qui a été fait ce semestre.
Planning du second semestre
4 La reprise de l'existant
4.1
Introduction
Il était important, avant de commencer à réaliser notre comparateur, de vérifier si des
applications ne proposaient pas déjà de comparer deux documents XML, ou quelque chose
qui s’en approche. Il était en effet intéressant d’étudier une application ressemblante à la nôtre
pour plusieurs raisons :
• Gagner en visibilité, ce qui permet d’améliorer la compréhension, voire la
modélisation, et éviter des erreurs classiques
• Gagner du temps sur des aspects sur lesquels on bloque
• S’inspirer de ce qui a déjà été fait et éviter de faire une partie qui a déjà été traitée
Fabrice Lefèvre nous a informés de l’existence d’une application permettant de contrôler
différentes versions d’un document OpenOffice, Office Version Control. En théorie, celle-ci
permet de distinguer les différences entre deux versions d’un document OpenOffice,
d’appliquer un patch (correspondant à une mise à jour) sur un document, ou au contraire
d’inverser un patch (correspondant au rétablissement d’une version antérieure). En réalité,
cette application ne fonctionne pas avec des documents OpenOffice, mais seulement avec des
fichiers XML purs. De plus la documentation est très mauvaise (le projet a été arrêté), il a
donc été difficile d’étudier Office Version Control.
L’aspect le plus intéressant est qu’il utilise XyDiff. XyDiff est un outil développé par
l’INRIA (Institut National de Recherche en Informatique et Automatique) qui permet de
comparer plusieurs versions d’un document XML, ou de comparer deux documents XML
ayant la même structure. Nous pensions donc au début que l’étudier pourrait nous aider à
améliorer notre comparateur, notamment et surtout au sujet de la comparaison d’une séquence
de nœuds. En effet notre comparateur s’arrête à un niveau. Le problème est que dans l’outil
XyDiff, la comparaison ne se faisant que sur le contenu, il est supposé que la structure
4
(l’arborescence des nœuds XML) soit la même pour les deux fichiers comparés. Ce qui
éloigne beaucoup cet outil du nôtre.
Nous avons quand même voulu observer le fonctionnement de XyDiff, pour savoir si
nous pouvions nous inspirer de certaines parties. Ceci n’a pas été facile, car l’outil nécessite
d’être paramétré, et bien qu’il soit complexe, il n’existe pourtant aucune documentation.
Le principe de XyDiff consiste à créer un fichier XML, puis créer aléatoirement un patch
de mise à jour et à l’appliquer sur une copie de ce fichier. Ces deux fichiers sont donc
ressemblants, ont la même structure et peuvent être comparés. Il est en théorie également
possible de comparer deux fichiers XML de notre choix, mais ceci ne fonctionne pas, et sans
documentation, nous avons renoncé à tenter de corriger l’erreur.
Nous avons donc étudié l’algorithme de comparaison de deux arbres XML utilisé par
XyDiff et l’avons comparé au nôtre.
4.2
Algorithme de comparaison de XyDiff
Classe : XMLCompareEngine
Fonction : compare(Noeud1, Noeud2)
Etapes
•
•
Test si les deux nœuds sont nuls (si oui => ERREUR)
Tests sur les types de nœuds (si différents => ERREUR)
o Type : élément
Comparaison des noms de nœuds
Comparaison des attributs : appel de compareAttributes(listAtt1, listAtt2)
Test si Noeud1 et Noeud2 ont des fils
• Si aucun des deux : Sortie fonction
• Si un des fils et l’autre non : ERREUR
• Si les deux ont des fils : Continue
On récupère le premier fils de chaque nœud
Boucle sur les fils de Noeud1
• Incrémentation de fils2
o Si fils2 nul : ERREUR
• Appel récursif de compare sur fils1 et fils2
A la fin de la boucle, s’il y a encore des fils2 : ERREUR
o Type : texte, CDATA
Test si Noeud1 et Noeud2 sont des chaînes de caractères
Comparaison des valeurs de Noeud1 et Noeud2
o Type : Commentaire
Vérification que les commentaires sont égaux
o Type : Entité
Non traité : ERREUR
o Type : différent (inconnu)
Non traité : ERREUR
Fonction : compareAttributes(ListAtt1, ListAtt2)
Etapes
•
•
Comparaison du nombre d’attributs
Parcours des attributs (par rapport à ListAtt1)
o Test si ListAtt2 possède l’attribut correspondant à ListAtt1(indice)
Si non : ERREUR
o Test de l’égalité des valeurs de ListAtt1(indice) et ListAtt2(indice)
5
4.3
Notre algorithme de comparaison
Fonction : parcoursArbre (NoeudModele, NoeudTeste)
Etapes
•
•
Test si les deux nœuds sont nuls
Sinon test si le nœud modèle est nul
Alors insertion.
• Sinon test si le nœud testé est nul
Alors délétion.
• Sinon les deux nœuds ne sont pas nuls :
- Compare (noeudModele, noeudTeste), qui effectue une comparaison sur les
types et noms de nœuds, et sur le nombre et la valeur de leurs attributs. Elle indique s’il y a
substitution, insertion, délétion ou si les nœuds sont identiques.
- Si le nœud modèle a des fils et l’autre non :
* Délétion de tous les fils.
- Si le nœud testé a des fils et l’autre non :
* Insertion de tous les fils.
-Si les deux nœuds ont des fils :
* On créé les listes des fils des nœuds modèle et testé.
* On créé une boucle afin de parcourir tous les fils modèles. Pour
chacun d’entre eux, tous les fils testés présents dans la liste sont parcourus et celui qui est le
plus ressemblant est choisi. La fonction parcoursArbre () est rappelée, paramétrée du nœud
modèle et du nœud testé sélectionné.
* Lorsque tous les nœuds modèles on été parcourus, on regarde s’il
reste des nœuds testés. Si c’est le cas, il y a une insertion.
4.4
Conclusion
L’algorithme utilisé par XyDiff est donc plus simple et moins performant que le nôtre, à
l’exception, au départ, des différents types de nœuds qui étaient mieux gérés. Nous avons
donc intégré à notre comparateur cette approche par type. Le temps de calcul du comparateur
est devenu, grâce à cette approche, beaucoup moins important.
Nous avons donc réellement amélioré notre comparateur XML grâce à l’étude de l’outil
XyDiff, même si ce n’est pas sur l’aspect que nous pensions avant l’étude. En effet, nous nous
sommes inspirés de XyDiff pour la comparaison par type de nœud, alors que nous pensions
l’étudier pour réussir à comparer une séquence de nœuds.
6
5 Les orientations
orientations choisies
Durant la réalisation du projet, il a fallu faire un certain nombre de choix que ce soit
pour la conception ou l’organisation. Nous vous présentons les principaux ci-dessous :
5.1
Les choix de langages
La plateforme Web a été développée à l’aide du langage PHP. Nous sommes basés sur
la norme XHTML 1.1 pour éditer les pages Web. Le langage JavaScript a été utilisé
également pour un certain nombre de scripts, associés parfois à la méthode AJAX.
Quant au comparateur XML, nous avons choisi de le développer en PHP, pour des
raisons de facilité d’intégration à la plateforme, celle-ci étant en PHP.
De plus, PHP5 propose les APIs DOM et XSL nécessaires au développement de notre
comparateur.
Il aurait été possible de développer le comparateur en Java qui propose également
différentes solutions pour les fichiers XML, comme l’API JAXP.
5.2
Un comparateur à un niveau
Lors de notre avancement nous avons réalisé la difficulté à comparer des fichiers assez
différents.
Une fois que le nœud comparé est différent de celui testé, le but est de regarder si les
fils de ceux-ci, sont identiques ou non. S’ils le sont, le nœud testé doit être associé au modèle
afin de « raccrocher » dans les arbres.
C’est pourquoi nous avons choisi de faire la comparaison sur un seul niveau : si une
différence est repérée, on regarde le nœud suivant, s’il est toujours différent on considère que
tout le sous-arbre est différent. Sinon on recommence à comparer à partir de ce nœud.
Une solution pour optimiser cette comparaison serait de travailler sur des séquences de
nœuds modèles, et d’effectuer des recherches dans tout l’arbre testé. Nous n’avons pas
implémenté cette méthode par manque de temps.
5.3
La répartition du travail
Afin d’avancer efficacement le projet, nous avons décidé de découper le projet en deux
phases de réalisation :
• la plateforme Web
• le module de comparaison
Ces dernières n’avaient rien en commun et pouvaient être développées en parallèles.
Une fois les deux parties terminées, le comparateur a été intégré à la plateforme. Ceci a
pris plus de temps que ce que nous avions prévu, mais s’est passé dans de bonnes conditions.
Cette solution nous a permis d’optimiser le rendement et de prendre de l’avance dès le
début du second semestre.
7
6 Les fonctionnalités
La plateforme Web propose différentes fonctionnalités selon le type de profil connecté.
On distingue trois profils :
• Administrateur
• rédacteur
• utilisateur
6.1
Fonctionnalités de l’utilisateur
6.1.1
Dépôt de fichier à comparer
Une fois connecté à la plateforme, l’utilisateur choisit le modèle de comparaison, puis
dépose son fichier.
6.1.2 Consultation des résultats
L’utilisateur peut consulter les résultats d’une comparaison. Si le document modèle
auquel se réfère un document à comparer possède une date de limite de dépôt, celle-ci doit
être passée pour que la consultation puisse être faite.
6.2
Fonctionnalités du rédacteur
Le rédacteur possède les droits de l’utilisateur, en plus des droits suivants.
6.2.1
Dépôt d’un fichier modèle
Une fois connecté à la plateforme, le rédacteur peut y charger un fichier modèle. Etant
donné que plusieurs modèles peuvent être déposés, le rédacteur donne une désignation à
chaque modèle ajouté pour l’identifier. Il doit de plus paramétrer plusieurs options :
• fixer ou non une date limite de dépôt de document à comparer
• fixer ou non la comparaison du contenu des documents
• choisir si l’utilisateur ayant déposé un fichier à comparer a le droit de consulter le
résultat de la comparaison
6.2.2 Gestion des fichiers
Le rédacteur peut modifier ou supprimer un fichier modèle, supprimer des fichiers
testés, des fichiers résultats ou des archives.
6.2.3
Récupération des fichiers
Il est proposé au rédacteur de télécharger sous forme d’archive un ou plusieurs
documents modèles, ou l’ensemble des documents à comparer ou résultats associés à un
document modèle.
8
6.3
Fonctionnalités de l’administrateur
L’administrateur possède les droits de l’utilisateur et du rédacteur, en plus des droits
décrits ci-dessous.
6.3.1
Ajout d’un nouveau profil
L’administrateur peut ajouter un nouvel profil (utilisateur, rédacteur ou administrateur)
à la plateforme Web. Celui-ci sera inscrit dans la base de données interne.
6.3.2 Modification des profils existants
L’administrateur peut modifier ou supprimer un profil. Dans le cas de la modification,
il est possible de changer l’identifiant et le mot de passe.
9
7 Les données
En cours de réalisation de la plateforme, nous avons modifié certaines fonctionnalités
et ajouté quelques options mineures, et il a fallu modifier la base de données. Nous avons jugé
que la table « admin_appli » liant un administrateur à une utilisation n’était plus nécessaire
étant donné qu’un administrateur l’est pour toute l’application. Nous l’avons donc supprimée.
Ensuite nous avons ajouté ou supprimé quelques colonnes dans certaines tables.
Par exemple, l’ajout de l’option de comparaison du contenu pour un document modèle
a eu pour conséquence l’ajout du champ « suppr_contenu » dans la table « doc_modele ».
Le modèle physique de données tel que nous l’avons conçu au premier semestre, n’a
tout de même subi aucun changement majeur.
10
8 Le problème de la sécurité
Il était nécessaire d’identifier les utilisateurs afin d’assurer la sécurité de la plateforme.
Cette dernière offre la possibilité de déposer des fichiers modèles ou encore de consulter des
résultats, il est donc évident qu’un simple utilisateur ne puisse pas accéder à ces
fonctionnalités.
Dans le cadre de l’université, il nous est possible de faire une connexion à l’annuaire
LDAP, qui est un annuaire recensant toutes les personnes de l’université.
Si l’utilisateur ne fait pas partie de la faculté, alors on recherche s’il fait partie de la base
de données interne de la plateforme.
8.1
Identification à l'aide du LDAP
Dans le cadre de la certification C2I, les utilisateurs sont des étudiants, il était donc
nécessaire de faire une identification par rapport à ce dernier.
Après identification dans le LDAP, on retrouve diverses informations sur l’utilisateur :
• Son nom
• Son prénom
• Son profil
• Son adresse email
• …
La donnée la plus importante pour la plateforme est le profil, car c’est elle qui détermine
quelles fonctionnalités seront disponibles pour l’utilisateur qui se connecte.
Par exemple, un utilisateur authentifié « student » ne pourra que déposer des fichiers à
comparer et consulter les résultats d’une comparaison.
Il existe cinq profils dans le LDAP :
• student, attribué aux étudiants (connecté en tant qu’utilisateur)
• employee, attribué aux professeurs (connecté en tant que rédacteur)
• faculty, attribué au personnel administratif (connecté en tant que rédacteur)
• researcher, attribué aux doctorants (connecté en tant qu’utilisateur)
• affiliate, attribué aux invités (connecté en tant qu’utilisateur)
8.2
Identification selon le profil
Dans le cas où l’utilisateur qui se connecte est inscrit sur l’annuaire LDAP, et si c’est sa
première connexion à la plateforme, son profil sera enregistré dans la base de données interne,
pour qu’il puisse déposer des documents (de quelque type qu’ils soient). Dans le cas contraire,
on recherche s’il fait partie de la base de données interne de la plateforme.
Dans cette base de données, il existe aussi différents profils que l’on a détaillés ci-dessus
ainsi que les fonctionnalités qui leur sont associées.
11
9 La réalisation du projet
Pour la réalisation du projet, on distingue deux grandes parties :
• la création de la plateforme Web
• la création du comparateur
9.1
Introduction
Nous avons créé cette application dans l’optique qu’elle soit réellement utilisée, et
nous nous sommes donnés les moyens pour arriver à cette fin.
Premièrement, la plateforme Web a été développée de façon très structurée.
L’arborescence des répertoires de l’application suit une logique, en étant composée d’une
partie générique, et d’autres parties propres à chaque cas d’utilisation, pour les graphismes et
les fichiers déposés et générés (pour plus d’information, cf. « Documentation technique
plateforme Web »). Le code a été commenté, et respecte la norme W3C pour le XHTML 1.1,
ce qui donne de la clarté et de l’harmonie dans la lecture. L’application est donc prête à être
utilisée, et un manuel a été rédigé pour expliquer pas à pas son fonctionnement (cf. « Manuel
utilisateur de la plateforme Web »). Il est également aisé de lui ajouter de nouveaux cas
d’utilisations, car ceux-ci sont séparés de l’application elle-même. Enfin la maintenabilité est
assurée car nous avons rédigé une documentation technique (cf. « Documentation technique
plateforme Web »).
Le comparateur, quant à lui, fonctionne de manière satisfaisante, même si nous savons
qu’il n’est pas encore optimal (notamment au niveau de la comparaison de deux séquences
nœuds, ou de l’interprétation de différences entre deux fichiers XML issus d’OpenOffice).
Mais nous avons fait en sorte qu’il puisse être amélioré, en créant une documentation
technique (cf. « Documentation technique du comparateur XML »), et en le développant de
manière claire et très commentée.
9.2
La création de la plateforme Web
9.2.1 La réalisation de toutes les fonctionnalités
Les diverses fonctionnalités ont été réalisées avant d’intégrer le graphisme. La
première étape a été de réaliser tous les formulaires avec leur traitement, puis de faire une
authentification avec la possibilité de choisir une application (TP de c2i ou comptes rendus de
réunion de projet).
Une fois les fonctionnalités réalisées, il était nécessaire de présenter le site de façon à
ce qu’il s’intègre aux divers modules de l’UAPV.
9.2.2 La mise en forme – CSS – Javascript - Ajax
Pour la mise en forme, nous avons utilisé le langage CSS et créé deux styles
graphiques :
• le premier est basé sur le style du site de la plateforme pédagogique de l’université
d’Avignon (http://e-uapv.univ-avignon.fr/) et concerne l’application de pré-correction
de TP pour la certification C2I.
12
•
le second est basé sur le style du site de l’IUP GMI d’Avignon et concerne
l’application de validation de format des fiches de comptes rendus de réunion de projet
de master première année.
L’implémentation de la plateforme a été pensée de manière à ce que si on voulait lui
ajouter une application, il suffirait alors de créer un répertoire pour cette application et de
respecter l’arborescence existante. Une bannière pourrait être redéfinie ainsi que le style
complet même si l’architecture resterait identique.
Une fonction JavaScript appliquée sur le menu permet de montrer ou cacher deux
fonctionnalités, à la manière de sous-menus.
Certaines fonctionnalités, comme le changement des droits, utilisent des fonctions
JavaScript et des requêtes AJAX. Cela permet de configurer en temps réel les profils
utilisateurs sans avoir à recharger une page, ce qui est beaucoup plus agréable pour
l’utilisateur.
Les autres fonctions JavaScript développées sont toutes destinées à rendre plus
agréable la navigation sur la plateforme en évitant des chargements de pages superflus.
Une fois terminée, nous avons validé la plateforme en respectant la norme W3C, pour le
CSS et l’XHTML 1.1.
13
9.3
La création du comparateur XML
9.3.1 Les différentes étapes dans l'avancement
La première étape a consisté en créer un comparateur qui détermine si le document
soumis était strictement identique au modèle ou non, les différences n’étaient pas repérées et
le comparateur retournait 0 ou 1.
Dans un second temps, nous avons essayé de repérer des différences en avançant dans
les deux arbres et en indiquant l’endroit ainsi que le nœud concerné.
L’étape suivante a consisté en, une fois la différence trouvée, continuer la comparaison
et indiquer toutes les différences repérées.
Les différences étant repérées, le but a été de les organiser afin de les interpréter
efficacement.
9.3.2 Le choix de l'architecture de l'arbre des différences
Le but étant de présenter les différences entre les deux arbres à un utilisateur, il était
nécessaire de stocker ces informations. Elles ont été classées en trois catégories dans un arbre
de différence.
Ces catégories sont « insertion », « délétion » et « substitution ».
Les nœuds qui apparaissent dans le document testé mais pas dans le document modèle
sont rangés dans « insertion ».
Lorsque l’on arrive sur un nœud du document modèle qui n’apparaît pas dans le
document testé, celui-ci est stocké dans « délétion ».
Il reste un dernier cas qui consiste à déterminer la ressemblance entre deux nœuds, car il
peut y avoir à un niveau donné autant de nœuds d’un coté que de l’autre et qui présentent des
ressemblances, dans ce cas on indiquera une « substitution ».
On distingue différentes substitutions entre deux nœuds :
• Substitution de nom
• Substitution d’attributs, le nom ou la valeur
• Substitution du nombre d’attributs
• Substitution de contenu
14
10 Les difficultés rencontrées et leurs solutions
10.1 Les documents XML générés par OpenOffice
Lors de la conception du comparateur, nous avons commencé avec des cas très simple
et qui fonctionnaient très bien. Au fur et à mesure nous avons tenté de complexifier les
fichiers XML, puis nous en sommes arrivés à tester des fichiers de traitement de texte
(fichiers à l’extension .odt) d’OpenOffice. Pour des fichiers très simples cela n’a pas posé de
difficulté particulière, mais pour des fichiers plus complexes les résultats se sont avérés moins
satisfaisants.
En analysant l’arbre de différence, les résultats retournés étaient justes. le problème ne
venait donc pas de la comparaison.
Il s’agit en fait d’une génération particulière des fichiers XML par OpenOffice.
En effet lors de la création d’un style généré lorsque l’on associe une mise en forme à
un contenu (par exemple : mettre un mot en gras), OpenOffice incrémente sa liste de styles
mais ne tient pas compte de l’ordre dans lequel il les crée.
Par exemple, si vous créez plusieurs styles dans les deux fichiers mais pas dans le même
ordre, vous obtiendrez pour le style « gras souligné » la valeur P1 dans le fichier modèle et la
valeur P3 dans le fichier testé.
A partir de ce constat nous comparions des nœuds qui dès le départ n’avaient rien en
commun et donc n’auraient pas dû être comparés.
Il s’agit alors de repérer le contenu d’un style puis de chercher dans l’autre fichier le
style qui est appliqué au même contenu.
Il n’était pas prévu au départ de travailler sur les contenus des nœuds. En effet,
l’objectif fixé était de ne comparer des fichiers XML que sur leur structure, et non sur le
contenu des nœuds de type « text ».
On peut facilement imaginer que la comparaison puisse être effectuée pour des styles
mais pas pour du contenu, si le contenu du nœud testé ne contient ne serait-ce qu’une lettre de
différence ou un espace vide, le nœud qui lui est associé ne sera jamais trouvé.
De plus lorsque qu’un style a été créé mais n’est plus utilisé dans le document, il est tout
de même généré lors de la transformation en arbre, ce qui pose de grosses difficultés étant
donné que le nombre de nœuds d’un côté est différent de l’autre. Cela peut donc éloigner deux
fichiers qui ont pourtant le même contenu.
10.2 La ressemblance des nœuds et le choix du meilleur
Lors de comparaisons, dans certains cas, certains nœuds modèle et testé se ressemblent
mais ne sont pas identiques. C’est pourquoi nous avons choisis d’associer des nœuds selon
certains critères sinon seulement deux cas auraient pu être traités, nœuds identiques ou non.
Les nœuds modèle et testés sont associés en fonction de leur type, leur nom, leurs
attributs (nombre et valeur) ainsi que leur contenu.
Le choix d’un nœud testé plutôt qu’un autre est assez délicat. Nous avons décidé de
donner des degrés d’importances aux similitudes. Le nœud testé qui possède le degré le plus
élevé est celui qui est sélectionné pour être comparé avec le nœud modèle. Bien entendu, sur
un même niveau, le nœud testé qui vient d’être choisi ne pourra plus l’être par le nœud
modèle suivant.
15
11 La présentation des résultats
Pour la présentation des résultats, nous avons choisi d’utiliser le langage XSL. Il permet
de présenter sous forme HTML les nœuds d’un document XML, et de modifier des nœuds à
volonté à l’aide des transformations XSLT et du langage XPath.
Pour chaque type de nœud (insertion, délétion ou substitution), un « template » est
appelé et propose une mise en forme.
Deux mises en forme ont été retenues, la première consiste à interpréter l’arbre des
différences dans le cas où l’utilisateur souhaite voir les problèmes de nœuds et la seconde où
la notion de XML ne doit pas être visible, et où il faut présenter les différences sous forme de
phrases explicatives.
11.1 La présentation des résultats en terme XML
Pour un utilisateur qui a proposé un fichier XML qu’il a conçu, il peut être intéressant
de voir le résultat interprété en termes de nœuds.
On entend par là que le fichier XSL va lui expliquer les endroits où il y a des erreurs
dans son arbre, s’il a commis des insertions, des délétions ou des substitutions de nœuds.
Pour chaque nœud de l’arbre des différences, on indiquera le nœud père qui le contient
afin de pouvoir le retrouver facilement, son niveau dans l’arbre et selon le type de l’erreur la
référence dans le fichier modèle et dans le fichier testé.
Dans le cas d’une insertion, on indiquera la référence du nœud ajouté dans le fichier
testé.
Dans le cas d’une délétion, c’est la référence du nœud oublié dans le fichier modèle qui
sera affichée.
Et dans le cas d’une substitution, les deux références affichées montreront que le nœud
modèle a été remplacé par le nœud testé, et vis versa.
11.2 La présentation des résultats avec transparence du XML
Dans le cas de la certification C2I par exemple, le XML doit être complètement
transparent.
C’est pourquoi les différences repérées doivent être expliquées à l’aide de phrases le plus
simple possible.
Par exemple dans le cas d’une substitution, on doit indiquer que le style1 a été appliqué
sur le contenu « XXX » au lieu du style 2.
16
Voir annexe pour une meilleure visibilité.
17
12 La validation des programmes – Tests
Une validation de la plateforme et du comparateur à l’aide de tests a été effectuée afin de
garantir le bon fonctionnement de ces derniers.
Une suite de tests a été réalisée pour s’assurer de la conformité des résultats obtenus.
12.1 La validation de la plateforme
Afin de garantir la conformité et la compatibilité de la plateforme Web, nous avons testé
cette dernière sur le site du W3C (World Wide Web Consortium) jusqu’à la validation, en
respectant la norme XHTML 1.1 et la norme CSS. C’est pourquoi les logos du W3C sont
apparents sur les pages du site.
12.2 La validation du comparateur
Des séries de tests ont été faites sur le comparateur afin de vérifier les résultats
retournés. Nous vous en présentons une partie ci-dessous.
18
Test sur des fichiers identiques.
Résultat dans l’arbre des différences
Le comparateur indique qu’il n’a pas repéré de différence.
19
Insertion d’un joueur.
Arbre modèle
Arbre testé
Résultat dans l’arbre des différences
Le comparateur a repéré des insertions de nœuds. Il indique qu’un nœud joueur a été ajouté du coté du
fichier testé. Il indique également toutes les caractéristiques du joueur étant donné qu’elles n’apparaissent pas
dans le fichier modèle.
21
Délétion d’un joueur.
Arbre modèle
Arbre testé
22
Résultat dans l’arbre des différences
Le comparateur indique une délétion d’un nœud joueur ainsi que les caractéristiques de ce nœud.
Effectivement il y a un joueur en plus dans le fichier modèle.
23
Test avec des noms de balises identiques mais avec des contenus textes différents.
Arbre modèle
Arbre testé
Résultat dans l’arbre des différences
Le comparateur repère une substitution de contenu, il indique le niveau, le type de la substitution ainsi
que le nœud concerné dans le fichier modèle et dans le fichier testé.
On peut ainsi retrouver rapidement que « US Open » a été remplacé par « Rolland Garros ».
24
Test avec des noms de balises différents mais avec un nombre et des noms d’attributs identiques.
Arbre modèle
Arbre testé
Résultat dans l’arbre des différences
Le comparateur repère une substitution. Il indique une substitution de nom car le nombre et le nom des
attributs sont identiques. A l’aide des références on peut alors voir que « nomTournoi » a été remplacé par
« nomTournoiATP ».
25
Test avec des noms de balises identiques, avec un nombre d’attributs identique mais avec des noms
d’attributs différents.
Arbre modèle
Arbre testé
Résultat dans l’arbre des différences
Le comparateur repère une substitution d’attributs. Il y en autant d’un coté que de l’autre mais en effet,
l’attribut « set » dans le fichier modèle a été remplacé par l’attribut « nbreSet » dans le fichier testé.
26
Test avec des noms de balises identiques, avec un nombre d’attributs différent mais avec des noms
d’attributs en commun.
Arbre modèle
Arbre testé
Résultat dans l’arbre des différences
Le comparateur indique une substitution mais cette fois avec un nombre d’attributs différents. A l’aide
des références, on peut retrouver les nœuds et voir que le nœud « nomtournoi » a comme attributs dans le
fichier modèle « set et pays » tandis que dans le fichier testé il n’a que « set ».
27
Test avec des noms de balises identiques, avec un nombre d’attributs différent et des noms d’attributs
différents.
Arbre modèle
Arbre testé
Résultat dans l’arbre des différences
Même si les attributs n’ont rien en commun, le comparateur indique qu’il y a une substitution de nombre
d’attributs.
28
13 Conclusion
Notre comparateur de documents XML fonctionne pour les fichiers XML en général, que
ce soient des fichiers XML traditionnels, ou ceux issus de la suite OpenOffice. Cependant ce
comparateur pourra être amélioré en favorisant les aspects plus particuliers d’OpenOffice et
en interprétant de façon plus large les résultats.
Ce projet nous a appris une fois de plus à gérer notre temps de travail et à travailler en
groupe. C’était la première fois pour nous quatre que nous avions à réaliser un projet sur toute
une année, et cette expérience a été très bénéfique, dans le sens où elle nous a permis de
prendre plus de recul sur notre travail, et de ne pas démarrer trop tard. En ce sens les réunions
avec notre tuteur de projet à peu près tous les mois nous ont aidés à garder un rythme de
travail régulier.
Nous nous sommes également perfectionnés dans la maîtrise du langage XML, avec
différentes variantes (XSL, XPath) et sa recommandation DOM, l’ayant utilisé intensément.
Notre objectif ayant été de réaliser une application générique et réutilisable, nous nous
sommes aussi appliqués à fournir un outil clairement codé, commenté, et avons rédigé des
documents facilitant son utilisation et sa maintenance en cas d’amélioration. Ces documents
sont les suivants :
• Documentation technique du comparateur XML
• Documentation technique de la plateforme Web
• Manuel utilisateur de la plateforme Web
ANNEXES
30
Annexe 1 - Planning du second semestre.
Planning second semestre
Les différentes étapes réalisées au second semestre.
Légende :
Vivian : V, Bertrand : B, Florian : F, Rémi : R, Tous : T
Étapes
A - Mise en place des outils nécessaires (serveur local, etc.)
B - Tests de fonctionnement des outils et des librairies
Jours
2
5
Groupe
T
T
C - Conception des différentes fenêtres de la plateforme Web générique
D - Création de la base de données
E - Mise en relation de la plateforme et de la base de données
F - Réalisation du module « comparateur XML »
Premier niveau : identique ou non
60
40
25
15
F-R
V-B
V-F
T
G - Second niveau : repérer les différences
H - Troisième niveau : lister les différences et exposer les problèmes
20
15
T
T
I - Tests du comparateur XML
J - Vérification du fonctionnement pour tout type de modèle
K - Tests des fonctionnalités de la plateforme
L - Intégration du module « comparateur XML » sur la plateforme Web
M - Présentation des résultats d’une comparaison
N - Tests de l’application générique
O - Mise en forme de la plateforme pour l’utilisation c2i
P - Mise en forme de la plateforme pour l’utilisation GED
Q - Intégration de l’annuaire LDAP de l’UAPV dans la plateforme
R - Tests de l’application pour le c2i
S - Tests de l’application pour la GED
T - Correction de bugs sur le comparateur
U - Nouveaux tests du comparateur
V - Rédaction du manuel d’utilisation de la plateforme
W - Rédaction de la documentation technique du comparateur
X - Rédaction de la documentation technique de la plateforme Web
Y - Rapport
Z - Préparation de la soutenance (diaporama, répétitions).
AA - Rendu du projet
AB - Soutenance
10
3
2
7
3
10
3
1
2
7
7
3
3
3
4
5
5
4
1
1
B-R
B-R
F-R
V-F
B-R
T
R
R
V-F
B-R
V-F
V-B
V-B
R
V
F
T
T
T
T
31
Annexe 2 - Solutions présentées pour les documents OpenOffice