Compte-Rendu d UV Libre : Système d Information du Bureau Des Etudiants de l INSA de Rouen

Transcription

1 Compte-Rendu d UV Libre : Système d Information du Bureau Des Etudiants de l INSA de Rouen Réalisé par Maxime Chambreuil maxime.chambreuil@free.fr Encadré par Nicolas malandain nicolas.malandain@insa-rouen.fr 16 janvier 2003

2 Table des matières 1 Introduction 2 2 Présentation du sujet Objectif de l UV Les contraintes techniques La collaboration Déroulement du projet Analyse de l existant Situation initiale Choix techniques Conception Conception du schéma de la base de données Conception de l application Documentation Implémentation ESQL Logicsheets Database Actions Modular Database Actions Problèmes rencontrés Problème de répartition du temps Problème de motivation Problème de débugguage Problème de sécurit e Problème de fonctionnement Conclusion Ce que j ai appris Ce qu il m a manqué Ce qu il reste à faire

3 Chapitre 1 Introduction Le Bureau Des Etudiants de l INSA de Rouen utilise pour la gestion financière de l association plusieurs logiciels propriètaires différents, qui ne répondent pas à l intégralité du besoin. Depuis 2 ans, le BDE utilise déjà un logiciel, développé par une étudiante pour répondre à ce besoin. Cependant, aprés ses 2 années d utilisation, il apparait que certaines fonctionnalités ont été omises et s avèrent nécessaires à l heure actuelle. 2

4 Chapitre 2 Présentation du sujet 2.1 Objectif de l UV Aprés une utilisation et une analyse approfondie du logiciel existant et ses fonctionnalités, mon objectif était de réaliser le logiciel de vente version Le produit final doit donc comporter : - Le logiciel proprement dit - La documentation de la conception - La documentation de la réalisation technique - La documentation pour son utilisation, avec un tutoriel Le travail doit aussi se conclure par une formation des étudiants, qui vont utiliser le logiciel. Cette formation permettra de soumettre la documentation destiné aux utilisateurs et de la faire évoluer. Il est intéressant aussi de savoir qui a suivi la formation pour faire une base de connaissances et avoir une transmission sans perte de connaissances, les personnes ne restant que 5 ans. 2.2 Les contraintes techniques Les contraintes techniques se résument surtout à la technologie utiliée pour l implémentation du produit : XML / Cocoon. Je ne les avais jamais utilisé auparavant, on comprend donc aisément les objectifs pédagogiques de cette UV : découvrir un nouvel outil. 2.3 La collaboration Durant ce semestre, de nombreuses UV libres axées sur la technologie XML/Cocoon ont été proposées. Cette technologie étant nouvelle, il s est avéré très formateur de travailler avec les autres membres des UV, malgré le caractére individuel de la mienne. 3

5 Chapitre 3 Déroulement du projet Voici les différentes phases du projet. 3.1 Analyse de l existant Situation initiale Le logiciel du BDE v2000 est actuelment installé sur chaque poste de l association, qui n a qu une seule trésorerie. On comprend donc l utilité de centraliser les applications. Le projet a été développé sous Microsoft Access De plus, de nombreux bugs á l affichage rende l application parfois inutilisable. Le projet n a jamais été documenté, je n ai pas pu travailler à son adaptation et je suis donc reparti de zéro, au niveau implémentation. De toute facon, c était imposé par les contraintes techniques du projet. Par ailleurs, chaque utilisateur avait accés á toutes les données confidentiels á la trésorerie : solde du compte, montant des factures, etc... On avait donc un gros problème de sécurité Choix techniques J ai donc décidé d installer le nouveau système sur le serveur Linux Mandrake de l association. L accés à l application se fait par le web grâce à des logiciels légers, répandus et couramment utilisés comme Microsoft Internet Explorer, Netscape ou Mozilla. Comme un serveur web apache est déjà en place sur la machine, j ai du installé un connecteur pour spécifier l application (Apache ou Tomcat) grâce à l URL. Ma préférence s est porté sur les logiciels libres : Le serveur web Tomcat, version L application web Cocoon, version 2.0.3, utilisant la technologie Java Le Java Development Kit, version Le connecteur Apache/Tomcat, version

6 Le serveur de base de données PostgreSQL, version 7.2 Le driver JDBC de PostgreSQL, version Conception La conception s est faite en simultanée avec la lecture de la documentation, que nous étudierons juste après. Le travail de conception s est décomposée en 2 parties : celle du schéma de la base de données et celle de l application Conception du schéma de la base de données Au départ, je n avais que pour seul document le schéma physique de la base de données du premier logiciel, générée par Access. Cela m a permis d avoir une bonne idée de la taille de l application à mettre en oeuvre. J ai donc commencé par faire le schéma conceptuel selon le modèle Entités / Associations. J ai un peu perdu du temps à utiliser et à retoucher mon schéma avec un outil de développement peu adéquat : Dia. Par la suite, j ai découvert et apprécié Power Designer 9 grâce à sa version d essai. Une fois que le schéma fut validé, Power Designer m a généré le modéle physique, ainsi que le script sql pour implémenter la base dans le serveur PostgreSQL Conception de l application L application a été concu suivant les groupes d utilisateurs : Le trésorier générale Les trésoriers d Amicale de chaque site géographique Les différentes personnes assurants des permanences dans chacun des sites A chaque groupe correspond un pipeline de l application, et à chaque connexion correspond des variables de session : le username, qui va renvoyer sur le pipeline correspondant au groupe ; et le site, qui va permettre à un site de ne pas voir les transactions des autres. Sur chaque pipeline, on peut ainsi spécifier les pouvoirs de chaque utilisateur : insertion dans une table, affichage, mise à jour, etc... L appel de toute page du logiciel implique à une requête sur la base de données : selection, insertion, mise á jour, effacement. Chacune de ses transactions pouvant être sur un ou plusieurs tuples, et sur une ou plusieurs bases. 5

7 3.3 Documentation Comme je l ai dit précédemment, j ai lu la documentation fourni par M. Malandain pendant la phase de conception. Elle provient principalement d IBM et est disponible à cette adresse : http :// Introduction to Cocoon 2 Working with XSP in Apache Cocoon 2 Build database-driven sites Celle-ci m a permis de mettre en place l environnement de l application, nécessaire pour envisager son implémentation. J ai aussi pu comprendre le fonctionnenement de Cocoon, son mécanisme de génération de page html, son interaction avec les bases de données, son architecture (ou trouver les fichiers de log ou d erreurs, utiles pour le debugguage), etc... Ainsi, j avais en tête toute la théorie sur les différentes technologies à employer : ESQL, Logicsheets, Database Actions, Modular Database Actions ; suivant la problématique de ma page html. 3.4 Implémentation Elle s est faite par ordre croissant des difficultés : ESQL J ai tout d abord cherché à afficher les données présentes dans ma base. La technologie ESQL s inscrivait idéalement dans cette problématique. J ai ainsi pu me faire la main sur la génération de page et mettre en forme mes résultats en personnalisant la feuille de style fourni par Cocoon, exemple sur lequel je me suis principalement basé Logicsheets J ai ensuite envisagé de faire la même chose mais en utilisant la technologie Logicsheets : en déclarant mes propres balises auprés de Cocoon dans le fichier cocoon.xconf. Jusque là, l implémentation s est plutôt bien passé : J ai eu quelques erreurs qui m ont permis de trouver et d utiliser les outils de débugguage : access.log et error.log Database Actions A la suite logique de l implémentation, venaient les transactions simples d interaction avec la base : insertion, mise à jour et effacement d un tuple. C est là que c est devenu plus compliqué : durant l exécution d une seule requête (URL), je pouvais avoir des erreurs à plusieurs endroits (sitemap, fichier de description de la base, évaluation des champs du formulaire, etc... 6

8 De plus, les informations fournis par les fichiers de log ne permettaient pas d en apprendre beaucoup sur les erreurs. Par exemple, j ai eu à de nombreuses reprises des problèmes avec le fichier descripteur de la base, mais je ne savais pas si le fichier comportait une erreur, ou s il ne recevait pas les paramètres de la page html Modular Database Actions Je n ai pas eu assez de temps pour faire l implémentation des mod-dba. Ils sont nécessaires à l application, qui comporte plusieurs héritages dans le schéma de la base. Avec les transactions sur plusieurs tables, les mod-dba permettent aussi les transactions multi-tuples, qui seront également bien utile au nouveau logiciel de vente. 7

9 Chapitre 4 Problèmes rencontrés 4.1 Problème de répartition du temps A mon sens, j ai perdu beaucoup de temps sur la conception de la base de données : mon schéma n a été validé qu à mi-semestre. Ceci m a laissé que trop peu de temps pour le codage, surtout que la technologie m était inconnue. 4.2 Problème de motivation Durant ce semestre, j étais souvent tout seul avec mes problémes. Même si plusieurs étudiants avaient le même type d UV, j ai du concevoir le schéma de la base de données sans dynamique de groupe. Par ailleurs, j allais voir mon tuteur, M. Malandain, tous les 15 jours pour l entendre dire que je ne travaillais pas. Ceci m a découragé et je ne suis plus retourné le voir dés que mon schéma de base était validé. 4.3 Problème de débugguage Ce problème provient principalement du fait que les erreurs sont très mal explicitées. Les sources d information pour le développeur sont peu nombreuses, et souvent mal concues : on vous indique une erreur sur un fichier lors d une compilation intermédiaire du process, et les numéros de ligne fournis ne correspondent pas du tout à celle de votre fichier source, il devient alors périlleux de trouver l erreur. 4.4 Problème de sécurité En effet, l accés à la base de données n est pas sécurisé. Le fonctionnement simultané du logiciel et de l interface web PhpPgAdmin ne permet pas 8

10 de garantir des conditions de sécurité optimales pour ce genre d application et constitue une faille pour le système. 4.5 Problème de fonctionnement Durant l implémentation, j ai effectué mes tests en requétant sur le port Or, ce port n est pas accessible depuis les postes clients, les utilisateurs n ont donc pas accés à l application. L installation du connecteur entre Apache et Tomcat aurait pu résoudre ce problème, mais cela n a jamais été une priorité dans l objectif pédagogique de l UV. 9

11 Chapitre 5 Conclusion 5.1 Ce que j ai appris Cette UV m a permis d appliquer mon cours sur les bases de données, de découvrir un nouvelle technologie web, d être capable de proposer une nouvelle alternative face au langage PHP, d aborder le monde Java par le web. Par ailleurs, apprendre seul, c est démotivant surtout quand ca ne peut pas marcher. 5.2 Ce qu il m a manqué Une 2ème personne m aurait permise d avancer plus rapidement sur chaque partie, de finir les mod-dba et dans un même temps le logiciel. Si la technologie avait été maitrisée, j aurais pu envisager la rédaction des documentations pour les utilisateurs et l administrateur du logiciel. Si l implémentation avait été terminée, j aurais pu prévoir de faire la formation. 5.3 Ce qu il reste à faire Comme je l ai évoqué précédemment, aucune documentation n est en cours de rédaction. Le logiciel ne fonctionne pas et les mod-dba ne marchent pas. Comme le besoin du BDE n est toujours pas satisfait, que la technologie XML/Cocoon demande un gros investissement d apprentissage au départ, je pense redévelopper l application en PHP. Il sera ainsi plus simple aux administateurs successifs du logiciel de maintenir l application. 10