Réalisation des interfaces de partage de données

La réalisation des interfaces d'échanges a commencé le 4 mars 2008. Pour faciliter mon travail, j’ai utilisé mes diagrammes de classes avec l'outil Dia. J'ai ainsi pu générer automatiquement les classes et les prototypes des fonctions dans le formalisme du langage C++. J'ai alors repris ces sources générées automatiquement pour les transformer dans le langage PHP, j’ai ajouté par la même occasion tous les modèles de commentaires au formalisme utilisé par PHPDocumentor. (C.F. annexe 8.6 page 124 et 8.8 page 143)

Une fois les squelettes des classes, et les prototypes des fonctions réalisés, j’ai facilement préparé mes fonctions de test pour implémenter la méthode TDD.

5.3.13.1. Développement du package commun

J’ai logiquement commencé par la programmation du package qui est commun à l'interface centrale et à l'interface des ISS. Je me suis aidé, pour se faire, des librairies PEAR pour développer les fonctionnalités relatives à SSH, RSA et à la gestion des archives et mails.

Je n’ai pas rencontré de souci majeur dans la réalisation de ce package ; mise à part avec le cryptage des données. Celui ci fonctionne, mais demande trop de ressource processeur et est par conséquent trop long ; il me fallait à titre d’exemple plus de 5 minutes pour crypter une archive de 10 Mo. J’ai donc porté ma réflexion sur l’utilisation d’une méthode différente de cryptage, mais j'ai finalement fait le choix de simplement retirer dans un premier temps la gestion des cryptages, car les données sont transmises des sites ISS au site central par

J'ai par ailleurs détecté un bug dans la gestion des archives de la librairie de PEAR. En effet cette dernière ne fonctionne pas bien lors de la décompression d’archives contenant elles même d’autres archives. Dans ce cas précis les fichiers compressés à l’intérieur de l’archive sont omis et ils ne sont pas décompressés.

A titre indicatif l’implémentation du package commun s’est faite courant mars. 5.3.13.2. Développement de package Web central

Durant le mois d’avril, j’ai développé la partie fonctionnelle de l'interface centrale. Cette partie est largement basée sur le package commun et particulièrement sur la gestion des archives et des métadonnées. Lors du codage et des tests, je me suis rendu compte qu'il manquait quelques fonctionnalités à ce niveau et que ma conception initiale était incomplète.

J’ai, à titre d’exemple, bien pris en compte le mécanisme pour indexer les

métadonnées et les archives de données liées, mais je n’avais pas intégré le fait qu’il faille refaire l’index lorsque les métadonnées sont modifiées ou lorsqu’une archive de données est supprimée.

Une autre faiblesse au niveau de ma conception concerne le mécanisme de

synchronisation des informations entre l’interface du site central et les interfaces des ISS. Pour des raisons de sécurité et d’indépendance de chacun des sites d’études intensives, ce sont les interfaces distantes qui se connectent sur le site central pour remettre à jours les archives de données, et récupérer si nécessaire les informations des utilisateurs locaux modifiés. Dans ce contexte ma réflexion s’est portée sur une gestion désynchronisée par scripts exécutés régulièrement.

Côté serveur central un script vérifie les liens entre les métadonnées et les partages de données ainsi que les mots clefs saisis dans les nouvelles métadonnées. Le script vérifie en même temps s’il faut intégrer les données, met à jour le thésaurus et les informations des utilisateurs et conclut son travail en envoyant un mail de rapport à l’administrateur central.

Au niveau des ISS, un script a pour rôle de remettre à jour les archives de données dans le cas où les sources de données originales sont modifiées, puis ensuite remet ces archives sur le site central et récupère la dernière définition des utilisateurs locaux sur le site central. Ceci est fait pour que les utilisateurs locaux puissent se connecter même si la

connexion Internet est momentanément indisponible. Finalement un mail de rapport des opérations est envoyé à l’administrateur local.

Ce mécanisme est fonctionnel mais n’est pas efficient car le temps d’attente pour les utilisateurs dépend de la fréquence d’exécution des scripts. J’ai donc à ce moment refait un cycle de conception pour intégrer dans le système un mécanisme d’alerte.

Ainsi, lorsque des partages sont créés, mis à jours ou supprimés, les archives le sont aussi et sont remplacées sur le serveur central dans le même temps. Cela fait, une alerte est envoyée sur le site central pour qu’il réintègre les données si nécessaire et remette à jour l’index des métadonnées. De la sorte, lorsque l’utilisateur crée, supprime ou met à jour un partage de ressource, il n’est plus obligé d’attendre l’exécution des scripts et doit simplement patienter le temps du transfert de l’archive pour en voir le résultat effectif sur le serveur central. Je n’ai implémenté ce mécanisme que plus tard car j’ai considéré cette fonctionnalité comme une amélioration.

5.3.13.3. Développement du package ISS

Finalement j'ai développé le package de l'interface ISS du 5 au 16 mai 2008. J'avais initialement prévu de pouvoir aussi gérer des partages de données provenant des partages des réseaux locaux avec le protocole SMB/CIFS. Mais plusieurs

problèmes m’ont amené à abandonner cette solution. Aucune librairie de PEAR n’offre des classes pour faciliter la gestion des partages sous SMB/CIFS. Des solutions tierces existent en open source mais la gestion des mécanismes

de SMB me semble complexe et les codes sources que j’ai trouvés sont peu commentés. En tout état de cause j’ai été dans l’impossibilité de comprendre totalement leurs

fonctionnements.

Le fait que l’interface locale installée sur chaque ISS puisse directement accéder aux ressources des réseaux locaux par l’intermédiaire d’une solution pour laquelle je n’ai aucune confiance à priori, et dont je ne comprends pas l’entier fonctionnement, m’a paru être une prise de risque importante.

C’est pour cela que j'ai décidé d’abandonner cette fonctionnalité pour y revenir plus tard si nécessaire en phase d'amélioration. En tout état de cause, il est très simple de

contourner le problème dans un premier temps. Il est en effet possible de monter sur le serveur les lecteurs réseaux nécessaires. Pour l'interface PHP les ressources qui proviennent du réseau sont alors vues exactement de la même façon que le sont celles des disques de

directement les données disponibles dans leurs dossiers partagés depuis leur PC si ces partages ne sont pas déjà montés sur le serveur.

5.3.13.4. Développement des interfaces graphiques

Une fois le développement de mes différents packages terminés, j’ai développé les interfaces en tant que tel en y intégrant les interfaces graphiques.

J'ai donc dans ce but commencé à implémenter les interfaces graphiques. Je me suis rendu compte avec surprise que je n'avais pas pris en compte leurs spécifications dans ma conception. Lors de la conception, je me suis attaché au fonctionnel, mais à aucun moment je n'ai présenté de maquettes des interfaces. Cet oubli est principalement dû au fait que c'est l'interface graphique de « Geonetwork » qui est utilisé comme interface utilisateur central, et de ce fait l'interface utilisateur pour le partage des données et leur administration m’est sortie de l'esprit.

J'ai corrigé au plus vite ce manquement en réalisant des maquettes des interfaces pour présenter l’organisation des fonctionnalités et les successions de menus.

L’organisation des interfaces et la succession des écrans découlent naturellement de la logique fonctionnelle, l'accord sur l'essentiel à savoir sur le fonctionnel était déjà acquit, de sorte qu'il ne m'a pas était nécessaire de faire valider ce travail de conception. Une fois les maquettes réalisées je les ai directement implémentées.

La réalisation des interfaces graphiques pour les interfaces d'échanges se fait à l'aide du moteur de template « Smarty ». Cela permet de séparer l'organisation fonctionnelle de l'organisation graphique. Au final l'interface centrale contient 10 écrans différents, l'interface ISS en contient 8. Le développement de ces interfaces graphiques a pris 10 jours à savoir du 16 au 22 mai 2008 pour l’interface ISS et du 26 au 28 mai 2008 pour l’interface centrale. (c.f. annexe 8.7 page 132)

Voici quelques imprimes écrans des deux interfaces. J'ai décidé d'utiliser le même style graphique pour réaliser les deux interfaces et de les différencier uniquement par leur couleur. Cela a dégagé un gain de temps important, puisque le travail de design pour la réalisation de la seconde interface s'est limité à modifier la couleur des icônes et des textes.

5.3.14. Intégration de l’outil de gestion des métadonnées et des interfaces de partage des données

A ce moment du projet, les travaux de développement pour les deux parties

constituantes du système d’information étaient suffisamment avancés pour les intégrer. Le couplage de l’outil de gestion des métadonnées « Geonetwork » avec l’outil de gestion des partages de données incluant l’interface web centrale ainsi que l’interface web installée sur les différents ISS est pris en compte en conception et s’est fait simplement en fusionnant le schéma de la base de données de l’interface centrale avec celui de l’outil « Geonetwork ».

5.3.15. TDD et tests d’intégration avec des données

Chacune des fonctions codées a été testée par l’intermédiaire de la méthode TDD précédemment expliquée. A ces tests fonctionnels et de non régressions qui ont eu lieu en parallèle du codage, s’ajoute un test plus scénarisé et plus proche de l’utilisation finale des interfaces. Cette phase de test qui a eu lieu du 30 mai au 04 juin 2008 fait suite à celle d’intégration et utilise les différents composants du système d’information. J'ai pour cela, installé l'interface ISS sur un portable en laissant l’interface centrale ainsi que l’outil

« Geonetwork » sur mon poste de travail. Seule la nature du support physique du réseau et le nombre de connexions en simultané change vis à vis des conditions réelles d’exploitation. J’ai ainsi vérifié le bon fonctionnement de l’ensemble en mettant en œuvre les différents cas d'utilisations. Une partie de ce test consiste à utiliser les interfaces de partage de données pour intégrer et mettre en place deux partages de chaque type de ressources. J’ai donc utilisé les interfaces, la centrale et les locales pour créer :

• Un partage de carte vectorielle intégrée

• Un partage de carte de type raster intégré

• Un partage de répertoire

• Un partage de fichier

• Deux partages intégrés de jeux de données issus de base de données. Le partage, l’intégration et la consultation de ces six ressources différentes ont fait l’objet d’une première validation de mes interfaces de partages ainsi que de l’intégration des deux parties constituantes du système d’information.

La vision utilisateur mise en œuvre dans ces tests a révélé une faille de sécurité dans ma conception. En effet la gestion des autorisations d’accès aux données ainsi que les liens se font au niveau des métadonnées. A partir de cette constatation il est tout à fait imaginable qu’un partenaire qui n’a pas accès à une donnée partagée par un autre partenaire, crée lui-même un nouveau jeu de métadonnées pointant vers la lui-même ressource et puisse alors s’auto autoriser la consultation des données qui ne lui sont pas destinées. Cette constatation m’a amené à faire un cycle court de conception pour modifier le fonctionnement des interfaces de partage de sorte que ces dernières n’autorisent le partage de ressource uniquement dans le cas où l’origine du jeu de métadonnées et de la ressource, émanent du même ISS.

5.3.16. Développement d’une seconde version de l’interface de gestion des métadonnées

aux travaux de la communauté. Pour cette raison j’ai refait un bilan de l'outil pour voir si certains des problèmes soulevés dans mon précédent bilan avaient été corrigés dans cette version.

Parmi les problèmes éliminés dans celle ci se trouve la correction des bugs concernant les recherches géographiques, à savoir la recherche en elle-même ainsi que la gestion des métadonnées sans zone géographique. Une autre concerne l’indexation par le moteur d'index Lucene qui est désormais correctement remis à jour lorsque les autorisations des métadonnées sont modifiées. Enfin une amélioration opérationnelle, et que j’avais noté comme nécessaire, concerne l’affichage des erreurs de validation des métadonnées. Cet affichage est désormais plus clair pour les utilisateurs. J’ai aussi intégré la traduction de l’interface en allemand, ce travail de la communauté n’est pas partie intégrante de cette version et n’émane pas

directement de moi.

Nous allons maintenant expliquer plus en détail les développements relatifs aux fonctionnalités que j’ai dû implémenter moi-même.

5.3.16.1. Mise à jour du modèle de métadonnées

L’évolution de la directive INSPIRE m’a amené à remettre à jour les modèles de métadonnées. En effet des champs qui étaient par le passé requit n’y sont plus et inversement. Une lecture des dernières publications relatives à la norme a été complétée d’un travail de refonte des modèles de métadonnées pour suivre la dernière version de la directive

européenne.

Par ailleurs, la directive Inspire dans sa version antérieure imposait déjà l’utilisation du thésaurus GEMET, et d’au

moins un mot clef provenant de ce thésaurus dans les

métadonnées. Pour répondre à cette exigence, j’ai intégré une petite partie de celui de GEMET concernant le lexique forestier dans le thésaurus EVOLTREE puis dans les modèles de métadonnées.

5.3.16.2. Cryptage MD5 des mots de passe

Au cours de l’intégration du système de gestion des métadonnées “Geonetwork” avec mes interfaces de partage de données, j’ai constaté que le codage des mots de passe n’était pas le même. Je pensais à priori que le codage des mots de passe sous Geonetwork était fait avec l’algorithme MD5, mais il n’en était rien, et l’application utilisait un encodage propre. J’ai donc modifié le code source de Geonetwork pour faire en sorte que les deux systèmes utilisent l’algorithme MD5 et puissent donc être inter opérables.

5.3.16.3. Evolution du workflow

J’ai développé une version plus complète de mon workflow, ajoutant au suivi des dates de modification, de création, et des auteurs, un système plus complet permettant aux contrôleurs de contenu de connaître d’un simple coup d’œil l’état de publication des métadonnées et des données qui y sont liées. Ce système fonctionne sur la base de codes

couleurs appliqués à deux images différentes. Une image M représente les droits sur les métadonnées et une image D symbolise les droits appliqués aux données.

Cette nouvelle fonctionnalité améliore le suivi des métadonnées pour les contrôleurs de contenu qui peuvent ainsi rapidement repérer les métadonnées qui doivent être validées ou encore les données qui n’ont pas la bonne visibilité.

5.3.16.4. Modification de la gestion des autorisations Lors de la spécification initiale, il

était entendu que l’administrateur central serait responsable de la gestion des associations utilisateurs / ISS. Mais par la suite Monsieur François LEFEVRE, qui est coordinateur des ISS et qui va tenir le rôle d’administrateur central de l’outil de gestion des métadonnées, m’a demandé de mettre en place une gestion plus évoluée des utilisateurs pour faire en sorte qu’il soit possible aux

administrateurs locaux de chaque ISS de gérer ces associations. Cela répartit ainsi le travail de suivi des utilisateurs en fonction de leurs projets.

J’ai aussi effectué une

modification dans la gestion des droits des métadonnées de sorte qu’un utilisateur puisse affecter des droits à son groupe mais aussi aux groupes dont il n’est pas membre, ce qui n’était pas possible initialement. La gestion des autorisations pour Internet reste le privilège des contrôleurs de contenu et des administrateurs.

Un dernier travail que j’ai réalisé pour faciliter le travail des éditeurs et des contrôleurs de contenu est de mettre

en place une gestion par défaut des autorisations pour l’accès aux métadonnées. Ainsi lorsqu’un jeu de métadonnées est créé, le droit de lecture est directement accordé à tous les autres ISS. Et lorsqu’un contrôleur de contenu ou un administrateur vérifie et enregistre à nouveau le jeu de métadonnées le droit de publication pour Internet est ajouté.

5.3.16.5. Amélioration de l’interface

Une de mes tâches a été de faire évoluer la mise en forme de ma première version de l’interface de Geonetwork pour que le résultat soit plus « propre ». Cela s'est fait en modifiant les images mais aussi le contenu des onglets de l’outil qui n’avait pas encore été personnalisé pour le projet Evoltree.

Un autre travail très simple mais très utile a été de modifier l’icône qui symbolise la suppression de bloc ou de champs dans les métadonnées pour le faire passer en rouge et ainsi le différencier très facilement de l’icône d’ajout.

J’ai pensé à cette évolution suite à l’observation d’un utilisateur qui s’était trompé de bouton et avait perdu une partie de la description de son jeu de données.

5.3.16.6. Correction du bug relatif à la recherche par groupes

Un bug de Geonetwork était présent dans le moteur de recherche et plus précisément dans la partie permettant de faire une recherche par groupe d’utilisateurs. Il se trouve que les développeurs de FAO ont confondu deux paramètres que sont les groupes autorisés et les groupes propriétaires. J’ai modifié la gestion des requêtes avec Lucene pour que le bon paramètre soit recherché à savoir le groupe propriétaire.