PROJET DE FIN D ÉTUDES POUR L O.N.E.R.A.

Transcription

1 2010/2011 INSTITUT SUP GALILEE PROJET DE FIN D ÉTUDES POUR L O.N.E.R.A.

2 2

3 Table des matières I. Introduction... 4 II. L architecture de l interface... 5 A. Description du projet... 5 B. Les composants de l interface La partie graphique Le composant de lecture/écriture de fichiers XML : TinyXML... 6 C. Nos prévisions... 6 D. Architecture finale... 7 E. Gestion du temps... 7 III. Guide de développement... 8 A. Microsoft Windows Installation des outils Configuration des variables d environnements... 8 B. Linux Ubuntu bits C. Architecture du répertoire D. Remarques Erreurs avec CMake Remarque sur la compilation avec Visual Studio IV. Guide d installation V. Guide d utilisation A. Forme du fichier B. Balises non gérées C. Balises gérées D. Tutoriel d utilisation VI. Conclusion A. Les difficultés rencontrées B. Les évolutions à faire sur le projet C. Ce que nous avons appris de ce projet VII. Annexe : Cahier des Spécifications Fonctionnelles

4 I. Introduction Dans le but de clôturer notre cursus d ingénieur en informatique, nous sommes amenés à réaliser un projet de fin d études. Ce projet doit nous permettre d utiliser un grand nombre de connaissances acquises durant notre formation. En partant de ce constat, nous avons opté pour un projet, proposé par l Organisme National des Études et de la Recherche Aérospatiale, visant à réaliser une interface graphique permettant de créer simplement des fichiers XML à partir d un fichier de définition XSD. Ce projet doit permettre à un utilisateur ne connaissant pas forcément la syntaxe XML d employer et de créer des fichiers XML valides au sens de leurs fichiers de définition. La force du XML est qu il est structuré et structurant. Surtout, il est interprétable par des utilisateurs, qu ils soient humains ou non. Il constitue ainsi vecteur de transport de l information entre une machine et un humain de façon simple et claire. C est d ailleurs pour cela que le XML constitue un format d échange très utilisé dans le monde de l industrie ou de la recherche. Par exemple, un programme peut facilement générer des rapports d exécution, des copies d instances ou autres documents au format XML. Puis, un tel fichier peut être directement transmis à un utilisateur humain qui peut ensuite le comprendre facilement. L O.N.E.R.A. a donc besoin d un tel outil pour faciliter les communications entres ses employés et ses applicatifs. En effet, il peut arriver qu un utilisateur pas forcément à l aise avec l outil informatique veuille interagir avec une application. Or, un fichier XML est facilement interprétable par une application. A partir d un fichier de définition, notre outil pourra donc permettre, entre autres, à un utilisateur lambda de créer des fichiers d entrée pour un applicatif. Dans un premier temps, nous présenterons donc l architecture de notre programme. Nous en profiterons pour décrire les différents outils utilisés. Ensuite, nous décrirons le développement de notre produit. Puis, nous terminerons par une conclusion où nous parlerons des différents aspects de notre projet sur lesquels nous avons appris, notamment à partir des problèmes que nous avons rencontrés. Enfin, vous retrouverez en annexe de ce rapport le cahier des spécifications fonctionnelles que nous avons envoyé le 22/10/

5 II. L architecture de l interface A. Description du projet Comme décrit dans notre introduction, notre outil s appuiera sur une interface graphique afin d offrir un service de création de fichiers XML à partir d une description au format XSD. Ainsi, on peut constater que notre projet est composé de différents modules qui agissent de concert pour offrir le service dont il est le but. Voici un schéma récapitulatif de notre solution, où les rectangles représentent des modules du projet tandis que les ellipses sont des concepts : 5

6 B. Les composants de l interface Nous venons de voir dans la partie précédente que notre produit est constitué de plusieurs modules. Nous allons donc décrire ici les différentes solutions techniques retenues quant à la création de chacun de ces composants. 1. La partie graphique La création d une application comportant une interface graphique implique l utilisation d une bibliothèque d objets graphiques. Pour cela, il existe différentes solutions logicielles possibles. Cependant, pour davantage de portabilité, nous avons décidé d utiliser Qt. En effet, Qt est disponible sur de multiples plateformes telles que : Mac OS, MS Windows, GNU/Linux, Symbian. En partant du constat que l O.N.E.R.A. utilise des machines, principalement, sous Linux et MS Windows, le choix de Qt s impose assez naturellement. Par ailleurs, les objets graphiques disponibles dans Qt sont très nombreux et nous permettent par ailleurs d offrir un outil respectant le «look n feel» du système d exploitation hôte. 2. Le composant de lecture/écriture de fichiers XML : TinyXML L interface doit avoir un système d écriture et de lecture de fichiers XML (XSD inclus). Ce module permet de lire ou créer des balises de tout type de façon simple. L écriture et la lecture sont ainsi simplifiées par une API performante et rapide. Ce module de lecture/écriture est directement piloté par le parseur XSD pour créer la représentation en mémoire du fichier lu. Par ailleurs, l écriture de fichiers XML via TinyXML est directement pilotée par la partie graphique du projet. En effet, les différentes actions d écritures étant effectuées par cette dernière, il est plus simple de faire une telle inclusion dans la partie graphique. C. Nos prévisions Comme énoncé dans le cahier des spécifications que nous vous avons envoyé le 22 octobre 2010, il était prévu d utiliser différents outils pour le parcours du fichier XSD. En effet, nous comptions utiliser une architecture permettant de représenter les fichiers XSD au sein de la mémoire via une collection de classes que nous allions développer. Une fois ces classes entièrement faites, nous nous sommes aperçus qu il était préférable, dans le temps imparti, d abandonner cette piste. En effet, elle réclamait ensuite beaucoup de temps 6

7 pour être utilisée convenablement. Par exemple, dans un fichier XSD, il est possible de définir des types de données. Ces types de données peuvent ensuite être utilisés au sein d autres balises pour définir de nouveaux types de données. Il est alors nécessaire d avoir une fonctionnalité de résolution récursive des types afin de savoir, à tout moment, quels sont les types de données demandées. Le parcours direct utilisant TinyXML permet de s affranchir de cette difficulté, puisque il est seulement nécessaire de remplacer la balise effectuant une référence par la liste de balises filles dépendantes et précédemment mémorisées via un parcours itératif du fichier XSD. D. Architecture finale Finalement, les modifications par rapport aux cahiers des spécifications concernent principalement la partie de lecture du fichier XSD pour en créer l interface graphique associée. Ainsi, le schéma montré en partie A est encore valide. La collection de classes qui devaient nous servir à représenter en mémoire une structure arborescente analogue au fichier XSD nous sert finalement à fournir un validateur structurel de fichiers XSD. E. Gestion du temps Pour ce projet, nous avons fait notre possible pour réussir à tenir nos délais. Malheureusement, nous accusons un léger retard pour l étape de livraison du produit finalisé. Le planning prévu est celui indiqué dans le cahier des spécifications fonctionnelles fourni en annexe. Il est représenté par le diagramme de Gantt suivant : 7

8 III. Guide de développement Nous avons utilisé l utilitaire multiplateforme CMake. Celui-ci permet de générer des projets, avec les liens adéquats entre les différentes librairies et dépendances du projet, pour divers IDE (Environnement de Développement Intégré) tels que Visual-Studio, Eclipse... CMake permet aussi de générer des scripts MakeFile sous Linux. Ainsi, nous allons vous expliquez ci-dessous comment installer et configurer vos systèmes d exploitation pour d éventuels développements futurs sur notre projet, et notamment pour faciliter l utilisation de la librairie Qt. A. Microsoft Windows Notre projet a été développé, compilé et exécuté sur Microsoft Windows 7 64 bits sans ennui. Il n y a aucune raison valable, selon nous, pour que ce même projet ne puisse être repris sur Microsoft Windows XP. 1. Installation des outils Pour être compilé, notre projet a donc besoin de CMake afin de générer un projet compatible avec les outils disponibles sur le système courant. Pour Windows, nous avions à disposition Microsoft Visual Studio Pour commencer, il faut installer l outil CMake. Pour cela, il suffit d aller sur le site de l éditeur ( de télécharger l exécutable et de l installer. De la même manière, Qt doit être installé. Pour cela, il suffit de récupérer l archive correspondant au système Windows sur le site du développeur ( Puis, il est nécessaire d installer la bibliothèque. C est un fichier exécutable, donc une simple exécution permet d installer tout correctement et avec les paramètres par défauts. 2. Configuration des variables d environnements Maintenant que nous disposons d un environnement de travail installé, il est nécessaire de passer à l étape de configuration. En effet, afin que CMake puisse faire les liens avec QT, il faut configurer des variables d environnement. Dans un premier temps, nous allons ouvrir l interface de configuration des variables. Celle-ci se trouve dans : Panneau de configuration -> Système -> Paramètres système avancés -> onglet Paramètres système avancés. Cliquez sur Variables d'environnement. 8

9 Dans la partie supérieure de la fenêtre, on va alors créer deux nouvelles variables. Cliquez sur «Nouvelle...». Dans Nom de la variable rentrez QMAKESPEC, et dans «Valeur de la variable», mettez «win32-msvc2010». Cette variable va indiquer à QMake (gestionnaire de QT) quel compilateur utiliser, pour créer les bons MakeFile. Même procédure pour la deuxième variable qui a pour nom «QTDIR» et pour valeur le chemin d'installation de Qt «C:\Qt\4.7.0». Cette variable est nécessaire au compilateur pour savoir où chercher les fichiers sources. La dernière étape consiste à éditer une variable système déjà existante : la variable «path». Elle se trouve dans le cadre en bas de la fenêtre. Sélectionnez-la et cliquez sur «Modifier...». À la fin de cette variable, rajoutez «;%QTDIR%\bin\». Il ne reste alors plus qu à lancer le programme cmake-gui pour configurer et générer le fichier de projet compatible avec l IDE préféré du développeur. Ce fichier de projet, quand Visual Studio est choisi comme IDE, est au format sln et est dans le répertoire build de l archive. 9

10 Les principales données à entrer dans l exécutable sont : Le chemin vers la racine de l archive, Le chemin vers le répertoire build. Sur la capture ci-dessus, vous retrouverez un exemple de configuration. Puis, on lance la configuration en cliquant sur le bouton «Configure». C est à cette étape que l on détermine quel sera l IDE qui devra supporter le projet. Enfin, cliquer sur le bouton generate aura pour effet de créer le fichier de projet adapté à l IDE choisi. B. Linux Ubuntu bits Le développement sous Linux est une chose que nous trouvons relativement aisée, puisque tous les outils sont soit préinstallés, soit simples d accès via les différents gestionnaires de paquets. Dans notre cas, Qt n est pas inclus sur notre distribution. De ce fait, les variables d environnement 10

11 inhérentes à son bon fonctionnement ne son pas configurées. Cependant, sous notre distribution Ubuntu bits, il nous a suffit d entrer la commande suivante pour tout installer et configurer : sudo apt-get install cmake qtcreator qt4-qmake lib-qt4* cmake-qt-gui Cette commande aura pour effet d installer : L outil de compilation multiplateforme CMake Qtcreator, qui est un outil de la gamme Qt permettant de créer différentes applications avec Qt rapidement et de façon graphique. Cet outil n est pas utilisé dans notre projet. Cependant, son installation via un gestionnaire de paquets permet d installer toutes les dépendances (et donc les bibliothèques Qt) et de configurer toutes les variables d environnement automatiquement. La tâche de configuration est donc simplifiée à son maximum. Qt4-qmake est un outil permettant de simplifier la compilation multiplateforme des applications Qt. Il est utilisé par les bibliothèques Qt. On installe avec l expression lib-qt4* toutes les librairies Qt. Il sera alors possible de donner de nombreuses pistes d évolution au projet. Cmake-qt-gui est une application graphique permettant la configuration de la compilation du projet pour une plateforme donnée. En fait, il s agit de la copie Linux de l application vue dans la partie Microsoft Windows. Si un problème d installation survient, on peut aussi installer le SDK de Qt directement avec la commande : sudo apt-get install qt-sdk Ou bien, si un problème survient à nouveau, on peut directement récupérer le SDK à partir du site internet de Qt ( Puis, il faut extraire l archive dans un répertoire, et entrer les commandes :./configure && make && make install Ensuite, le développeur doit entrer dans une console la commande : cmake-qt-gui ou, dans certains cas : cmake-gui 11

12 On retourne alors dans le cas vu pour Windows. En effet, on obtient la fenêtre suivante : La configuration du chemin vers le répertoire contenant le projet et vers le répertoire où sera généré le projet compatible au système courant (build) se fait de la même manière que pour Windows. Le développeur souhaitant compiler le projet doit ensuite se déplacer directement, avec une console, dans le répertoire build. Il doit ensuite entrer la commande : make Si toutes les étapes précédentes ont été effectuées sans encombre, la compilation démarre. Après quelques minutes, l exécutable est généré et n a plus qu a être déployé. 12

13 C. Architecture du répertoire L archive fournie contient tout notre projet. Différents répertoires composent cette archive et structurent notre projet en différents éléments qui ont chacun leur importance. Voici le contenu de chacun d entres-eux : build est le répertoire contenant les fichiers nécessaires à l incorporation du projet dans l IDE choisi via CMake, doc contient la documentation au format Doxygen du projet. include est le répertoire contenant les fichiers d en-têtes de la partie centrale du projet (le moteur d analyse XSD notamment). lib contient les bibliothèques utilisées par notre solution logicielle. On y retrouve alors le code source de TinyXML et de notre collection de classes XSD libxsd. qt_files contient le code source d implémentation du module graphique de notre solution. src contient le code source en rapport avec les headers définis dans le dossier include. src_test contient le code source du main utilisant notre solution. Ce main permet de créer l exécutable. test_files n est pas un répertoire prépondérant dans la compilation de notre projet. En effet, ce répertoire contient simplement quelques fichiers de tests pour notre solution logicielle. D. Remarques 1. Erreurs avec CMake Il se peut que CMake produise des erreurs lors de la configuration comme ci-dessous : 13

14 Nous n avons pas trouvé de solutions pour remédier à ce problème. Cependant si on reproduit la procédure de configuration normalement (Configure puis Generate), alors le projet est bien généré. Il se peut aussi que Visual Studio génère des erreurs lors du premier lancement. De la même manière, si on continue la procédure normale, le projet sera compilé et s exécutera correctement. Ce problème a été rencontré que ce soit sous Linux ou Microsoft Windows indifféremment. En ce qui concerne les systèmes d exploitation 64-Bits, la création d un projet via CMake ne génère pas d erreur mais la compilation du projet en 64-Bits est impossible car la librairie QT est compilée en 32-Bits de base pour Windows. La version des DLLs de Qt en 64 bits est tributaire de l acceptation de la licence commerciale. Pour rester Open Source, il faut alors recompiler la librairie QT en 64-Bits si vous voulez générer des projets en 64-Bits. Mais cette opération, peut prendre plusieurs heures. Cependant, en configurant CMake de telle façon à ce qu il utilise un compilateur 32 bits (même si l OS est 64 bits), alors l exécutable généré est quand même fonctionnel. En effet, nos machines de travail fonctionnent sous Microsoft Windows XP 32 bits et 7 64 bits. L exécutable généré avec le compilateur 32 bits sous 7 est utilisable, même si l OS est 64 bits. Sous Linux, nous avons laissé les différents compilateurs fournis en natifs (64 bits), et tout s est passé correctement. 14

15 2. Remarque sur la compilation avec Visual Studio Une fois que le projet est généré avec CMake et ouvert dans Microsoft Visual Studio, la génération de la solution ne peut être lancée immédiatement. En effet, il faut d abord préciser que le projet de démarrage est le projet IHM_XML, et non le projet ALL_BUILD. Il suffit alors, dans l explorateur de solution, de faire un clic droit sur le projet IHM_XML et de choisir l option «set as Startup Project». Une fois que cela est fait, la génération peut être lancée. 15

16 IV. Guide d installation L application, une fois compilée, est presque un stand-alone. Elle ne dépend que de peu d autres choses sur le système. Ainsi, après avoir été compilée en mode «release» via Visual Studio, il suffit de déplacer l exécutable avec les DLL de Qt adéquates dans un répertoire de fonctionnement donné (dans un répertoire XSD2XML à l intérieur de Program Files par exemple). En effet, en important les DLLs QtGui4.dll et QtCore4.dll, on dispose d un outil fonctionnel. On a alors un répertoire contenant ces DLLs et l exécutable compilé en mode release. Un simple double-clique sur l icône lance l application. Cependant, sur certaines configurations, des DLLs systèmes peuvent être manquantes. Ainsi, notre application a besoin de deux DLLs qui devraient être présentes dans le répertoire system32 de Windows. En effet, MSVCP100.dll et MSVCR100.dll sont les deux bibliothèques manquantes. Cependant, dans un souci de compatibilité, nous fournissons ces DLLs dans l archive contenant le code source. Elles fonctionnent sur notre système Microsoft Windows 7 64 bits. 16

17 V. Guide d utilisation A. Forme du fichier La norme XSD permettant un grand nombre de mises en formes différentes pour un même résultat, nous avons du commencer par fixer notre norme. Nous l avons choisie en tenant compte de la flexibilité du langage XSD, de la facilité à lire et interpréter la structure du document, de la réutilisabilité des fichiers XSD. Ainsi les fichiers devront être formés comme suit pour être correctement interprétés par notre programme. <?xml version="1.0" encoding="iso "?> <xs:schema xmlns:xs=" <xs:include schemalocation="testenum.xsd"/> On peut utiliser xs ou xsd comme namespace du fichier. La balise «include» permet d intégrer d autres fichiers XSD dans le fichier courant. Le fichier à rechercher doit être dans le même répertoire que le fichier courant. <! - - un commentaire XML - - > Les commentaires de forme XML sont autorisés dans les fichiers XSD. Cependant une fonction de formatage les supprimera localement lors de la lecture du fichier. <xs:group name="custgroup"> <xs:sequence> <xs:element name="customer" type="xs:string"/> <xs:element name="orderdetails" type="xs:string"/> <xs:element name="billto" type="xs:string"/> <xs:element name="shipto" type="xs:string"/> </xs:sequence> </xs:group> <xs:attributegroup name="personattr"> <xs:attribute name="attr1" type="string"/> <xs:attribute name="attr2" type="integer"/> </xs:attributegroup> <xs:simpletype name="codetype"> <xs:restriction base="xs:string"> <xs:enumeration value="undef" /> <xs:enumeration value="code1" /> <xs:enumeration value="code2" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="regex"> <xs:restriction base="xs:string"> <xs:pattern value="[a-za-z0-9]{8}"/> </xs:restriction> </xs:simpletype> <xs:complextype name="caressence"> <xs:sequence> <xs:element name="octane" type="xs:string"/> <xs:element name="fournisseur" type="xs:string" /> </xs:sequence> </xs:complextype> La balise «group» permet de définir des groupes de balises. Une fonction de formatage du fichier local convertira les groupes en balise fils. La balise «attributegroup» permet de définir des groupes de balises. Une fonction de formatage du fichier local convertira les groupes en balise fils. Les balises «simpletype» sont gérées et devront être définies comme une balise de 1 er ordre. Une balise de 1 er ordre est une balise fille de la balise racine «Shema». Les différents types gérés dans ces balises seront définis dans la suite de ce document. Les balises «complextype» sont elles aussi gérées en balise de 1 er ordre. Elles peuvent être composées d un 1 er fils de type : - Sequence 17

18 <xs:complextype name="moteur"> <xs:sequence> <xs:element name="marque" type="xs:string" /> <xs:element name="modele" type="xs:string" /> <xs:element name="essence" type="caressence"/> <xs:element ref="caressence"/> </xs:sequence> <xs:attribute name="id" type="xs:string"/> </xs:complextype> <xs:element name="text" type="xs:string" default="montext"/> <xs:element name="rootchoice"> <xs:complextype> <xs:choice> <xs:element ref="helicoptere" /> <xs:element name="string" type="text" /> <xs:element ref="avion" /> <xs:element ref="personne" /> </xs:choice> </xs:complextype> </xs:element> - All - Choice - Attribut Les fils doivent être obligatoirement de type «element». Si un complextype doit être inséré, on utilisera alors l attribut «type» avec la balise «name» comme l exemple joint, ou bien l attribut «ref». Les balises «element» peuvent être définies en balise de 1 er ordre. Elles peuvent être unaires ou complexes. Si elles sont complexes, on se référera alors au paragraphe ci-dessus concernant les «complextype». B. Balises non gérées Malheureusement, le temps a manqué pour permettre de gérer les très nombreux cas offert par le format XSD. En effet, certaines balises, ayant des actions sémantiques propres, ont du être ignorées. Néanmoins, il apparait que pour gérer certaines balises, l utilisateur confirmé pourra reformer à la main certaines structures XSD pour coller avec l utilisation de la définition XML que nous autorisons avec notre application. La sémantique du fichier modifiée ne changera pas après de telles modifications. En effet, certaines des balises que nous ne gérons pas nativement ne nécessitent qu une simple réécriture. C est notamment le cas pour xs:any et xs:anyattribute. Enfin, la liste des balises disponibles dans le langage XSD étant, comme dit précédemment, relativement grande, nous ne gérons pas non plus les balises suivantes : xs:appinfo xs :complexcontent xs :documentation xs :extension xs :field xs :import xs :key xs :keyref xs :notation 18

19 xs :redefine xs :selector xs :simplecontent xs :union xs :unique Néanmoins, même si ces balises ne sont pas gérées pour la création de fichier XML, le validateur est capable de dire si des fichiers de définitions utilisant ces balises sont valides ou non. C. Balises gérées Toutes les autres balises qui ne sont pas marquées comme non gérées dans la partie précédentes sont autorisées. En particulier, les nombreuses balises possibles permettant de définir un type simple (simpletype). En effet, nous avons mis en place une structure qui permet de manipuler de tels types de données. La vérification des types de données est effectuée lorsque l utilisateur clique sur le bouton d ajout. Voici la liste des «simpletype» autorisés et leurs utilités. Nom balise enumeration fractiondigits length list maxexclusive maxinclusive maxlength minexclusive mininclusive minlength pattern totaldigits whitespace Sert a Définir une valeur possible du champ de saisie. Spécifier le nombre maximum de digits autorisés dans la partie décimale. Spécifier le nombre exact de caractères autorisés. Définir une liste de valeurs. Spécifier la borne supérieure d une valeur numérique. La valeur saisie dans le champ doit être strictement inférieure à la valeur définie dans maxexclusive. Spécifier la borne supérieure d une valeur numérique. La valeur saisie dans le champ doit être inférieure à la valeur définie dans maxinclusive. Spécifier la borne supérieure d une chaine de caractères. La valeur saisie dans le champ doit être inférieure à la valeur définie dans maxlength. Spécifier la borne inférieure d une valeur numérique. La valeur saisie dans le champ doit être strictement supérieure à la valeur définie dans minexclusive. Spécifier la borne inférieure d une valeur numérique. La valeur saisie dans le champ doit être supérieure à la valeur définie dans mininclusive. Spécifier la borne inférieure d une chaine de caractères. La valeur saisie dans le champ doit être supérieure à la valeur définie dans minlength. Définir la séquence de caractères ou expression régulière que doit suivre la chaîne de caractères. Spécifier le nombre exact de digits autorisés dans une expression numérique. Spécifier la gestion des espaces. Les différentes fonctions de validations vont donc permettre de savoir si les valeurs entrées par l utilisateur dans les champs de l IHM sont valides selon le type déterminé dans le fichier XSD. 19

20 D. Tutoriel d utilisation Une fois que le programme est démarré par un simple double-clique sur l exécutable, la fenêtre ci-dessous s ouvre. Elle comporte plusieurs fonctionnalités disponibles via la barre de menus en haut de la fenêtre. On peut alors : Quitter l application, Ouvrir un fichier XSD pour créer un fichier XML valide selon la définition choisie, Charger en mémoire un fichier XML valide pour un XSD. Le fichier sera alors analysé en vue d être accessible en édition via l application, Générer un fichier XSD correspondant à un fichier XML que l on choisit. Générer un fichier XML selon un fichier XSD que l on aura déjà choisi. Les champs qui auront été remplis via l application seront alors récupérés. Le fichier XML désiré sera alors généré et écrit. Dans le cas où l utilisateur souhaite ouvrir un fichier XSD dans le but de créer un fichier XML (cas d utilisation de base), la fenêtre suivante apparait : 20

21 Elle permet à l utilisateur de choisir quel sera le nœud racine de son fichier XML qu il souhaite générer. En effet, dans un fichier XSD, plusieurs choix de racines sont possibles. Or, le choix de racine que l utilisateur souhaite utiliser, l application ne peut le deviner. Donc il est nécessaire de lui demander son choix. Une fois que ce choix est fait, l application connait la structure du fichier XML à respecter pour être valide selon ce XSD. Dans ce contexte, on retrouve dans la colonne de gauche les différents types et éléments disponibles à l instanciation. Pour chacun de ces éléments, en cliquant dessus, la partie centrale de l application affiche les champs nécessaires à l instanciation de l objet. Par exemple, pour un hélicoptère, on a besoin de connaitre sa marque, son modèle, la date de construction, C est ce qu on retrouve dans la capture suivante. On note alors que, pour chacun des types de bases reconnus, on a associé un objet graphique Qt qui lui est propre. Par exemple, la date de construction d un hélicoptère est reliée au type xs:date. L application sait que, pour un tel type, il faut afficher un objet graphique de type calendrier. 21

22 En ajoutant une liste exhaustive de ce genre, on peut gérer de nombreux types. Malheureusement, et comme vu précédemment, nous ne les gérons pas tous. En effet, dans le temps imparti, nous avons préféré ne pas prendre en compte les types exotiques. Par exemple, nous gérons le type xs:date afin de pouvoir représenter une date. En revanche, nous ne pouvons pas assurer la bonne fonctionnalité du système lorsque le type gday est utilisé. Il en est de même pour duration, gmonth, gmonthday, gyear et gyearmonth. De manière analogue, nous gérons les types de bases tels que bool, float et double. En revanche, le système ne prend pas en charge les types base64binary, hexbinary, anyuri et notation. Lorsque l utilisateur a inséré ses données dans les différents champs, il peut instancier l objet en cliquant sur le bouton en bas à gauche de la fenêtre : créer <objet>. S il s agit d un type nécessaire à l instanciation d un autre objet, l application demandera à l utilisateur de donner un nom pour cet objet. S il s agit d un élément amené à apparaitre en tant qu instance dans le fichier XML, alors il apparait immédiatement dans le fichier XML. Plus particulièrement, certains objets ont besoin d autres objets pour être instanciés. Ainsi, un avion a besoin d un moteur pour être instancié. Il faut donc d abord instancier l objet moteur. Puis, l application demandera à l utilisateur de donner un nom à cette instance de moteur (juste pour la retrouver au sein de l application). Ensuite, lorsqu on instanciera l objet avion, alors une liste 22

23 déroulante indiquera les différentes instances de moteur précédemment définies. Il suffit alors de choisir l instance que l utilisateur souhaite. En fait, dans la colonne de gauche, un marquage spécifique des noms de types est spécifié et permet à l utilisateur de s y retrouver. En effet, un nom de type écrit entre des chevrons représente un type instanciable issu d un élément du fichier XSD. En outre, un nom écrit entre crochets permet, quant à lui, de déterminer un type définit par une balise complextype. Enfin, un nom écrit entre parenthèses décrit un type qu il n est pas possible d instancier. C est le cas s il s agit d un certain type de complextype. 23

24 VI. Conclusion A. Les difficultés rencontrées Pendant le développement, on s est aperçu que la création de la partie de traitement XSD/XML avec l architecture que nous avions évoquée dans le cahier des spécifications ne pouvait être faite dans le temps imparti. Surtout, elle complexifiait de façon conséquente le codage de l application. C est pourquoi nous avons décidé, en cours de développement, de modifier notre architecture. Ainsi, nous devions utiliser une bibliothèque que nous avons implémentée : libxsd. Celle-ci permet de représenter en mémoire l arborescence du fichier XSD lu avec la bibliothèque TinyXML. Cependant, il s est avéré plus simple d utiliser directement le contenu de TinyXML pour créer notre interface graphique dynamiquement à partir du fichier XSD correspondant. Nous aurions probablement pu, avec davantage d expérience, voir cet écueil avant le codage et la perte de temps que cela entraine. Néanmoins, nous sommes maintenant en mesure d offrir, au prix de quelques modifications que nous avons faites, un parseur de fichier XSD avec outil de validation. En effet, nous avons implémenté une fonction récursive parcourant le fichier XSD et recréant l arborescence correspondante en mémoire. En ajoutant la vérification des cas où un nœud ne peut être affilié à son nœud parent. Il reste alors à générer une erreur. Par ailleurs, ce projet était pour nous le premier utilisant Qt. Or la configuration pour utiliser Qt et CMake nous a réellement posé problème. En effet, il existe des tutoriels sur internet expliquant comment créer un projet CMake utilisant Qt. Mais la plupart du temps, soit le projet n est uniquement compatible pour Microsoft Windows 32 bits, soit le projet généré contient des erreurs lorsque nous l ouvrons avec Visual Studio. Mais avec plus de temps en recherche, nous avons réussi à trouver une solution permettant de générer notre solution, et ce pour Linux ou Microsoft Windows indifféremment. Enfin, le planning que nous nous sommes donnés au tout début du projet était assez réaliste, mais difficile à tenir. En additionnant le problème rencontré dans nos choix d architecture logicielle cité ci-dessus, le planning s est alors révélé hors de portée. Néanmoins, pour des étudiants, nous pensons que le retard accusé au final (une semaine environ), pour un projet d une durée 4 mois environ, est acceptable. B. Les évolutions à faire sur le projet Pour la majorité d entre nous, nous manquons d expérience dans l utilisation d un outil aussi complet que Qt. En effet, Qt est un outil extrêmement complet et ne se limite pas qu à la création d applications graphiques. Ainsi, plutôt que d utiliser un outil comme TinyXML, nous aurions pu utiliser directement le parseur XML offert par la bibliothèque Qt. En outre, nous avons utilisé des objets graphiques de la bibliothèque Qt. Le résultat est, selon nous, satisfaisant. Mais avec davantage 24

25 d aisance à utiliser Qt, nous aurions pu rendre un outil avec une qualité professionnelle, d un point de vue esthétique et ergonomique. C est d ailleurs dans cette optique que, avec plus de connaissances de Qt et de temps, nous aurions pu implémenter une fonctionnalité qui avait été demandée de façon facultative. Celle-ci consistait à mettre un petit signe «+» à côté de chacun des blocs XML présents dans la partie droite de l application (zone de visualisation). Ceci permettant de naviguer de façon ergonomique au sein d un fichier volumineux. Enfin, notre état de l art rapporte que de nombreux outils permettant la création d un fichier XSD à partir d un fichier XML existent. Ils ne permettent pas de définir des restrictions sémantiquement correctes, mais ont le mérite de donner une structure de base relativement complète. Cette structure peut ensuite être étoffée à la main. Ainsi, une des évolutions de notre solution serait de lui adjoindre un tel système de création de fichier XSD. On aurait alors un outil complet, capable de gérer les deux sens de création (XSD vers XML et XML vers XSD). C. Ce que nous avons appris de ce projet Comme démontré dans la partie sur les problèmes rencontrés, l expérience est importante au sein d un groupe de développeurs. Ainsi, avec des individus plus à l aise sur certains types de technologies et sur certaines méthodologies adéquates associées à ces technologies dans notre équipe, nous aurions gagné un temps précieux qui nous aurait probablement permis d implémenter davantage de fonctionnalités dans notre projet. Néanmoins, notre formation s avère complète puisque chacun d entre nous à pu prendre part à la réalisation de ce projet sans souci notable. Que ce soit pour la conception, l implémentation ou bien encore la rédaction de la documentation, chaque membre du groupe a participé et a ainsi permis de fournir un outil qui, nous espérons, répondra aux attentes de notre client : l O.N.E.R.A. 25

26 VII. Annexe : Cahier des Spécifications Fonctionnelles 26