HAL Id: hal-02824320
https://hal.inrae.fr/hal-02824320
Submitted on 6 Jun 2020HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
recherche de données de profils fermentaires
Karim Hsini
To cite this version:
Karim Hsini. Conception d’une application web d’importation et de recherche de données de pro-fils fermentaires. [Stage] Institut Supérieur d’Informatique de Modélisation et de leurs Applications (ISIMA), Aubière, FRA. 2010, 54 p. �hal-02824320�
Institut Supérieur d’Informatique de Modélisation et de leurs Applications
Complexe des Cézeaux BP 125 63173 Aubière Cedex Institut National de la Recherche Agronomique Centre de Theix 63122 Saint Genès Champanelle
Stage de 2èmeannée
Filière : Réseaux et Télécommunications
Conception d’une application web
d’importation et de recherche
de données de profils fermentaires
Présenté par :
Karim H
SINIResponsable laboratoire : Didier MACHEBOEUF
Je souhaite tout d’abord remercier mon tuteur de projet au sein de l’INRA M. Didier Macheboeuf. Son soutien et sa patience m’ont permis de travailler dans une ambiance de travail cordiale, agréable et motivante.
Je tiens également à remercier l’ensemble de l’équipe de l’unité de recherche sur les herbivores digestion microbienne (URH DIMA), qui ont facilité mon intégration durant ce stage.
Enfin, je souhaite remercier mon tuteur de projet au sein de l’ISIMA, M.Philippe Lacomme, pour son encadrement.
Abstract
The study of digestion in ruminants with in vitro fermentation technics of rumen ecosystem generates numerous experiments. In the objective to optimize the feed use efficiency and improve the livestock production. There is a need at INRA (Institut National de la Recherche Agronomique) to centralize all results, also called fermentation patterns.
The project comes from the desire of automate several process, share data and allow multi-criteria search on these fermentation patterns. The objective is to design a web application to share these data with a search engine to filter the results. In a previous tutored project, I developed in tandem with another student specifications for this application, build a Conceptual Data Model (MCD) and studied the existing data.
I was in charge during this stage of the implementation of the application. I was primarily focused in technologies to implement for a web application and set up a test server. Then I realized devel-opment of the application on the basis of existing frameworks, to get robust and proven software architecture. Technologies used are PHP and MySQL with the framework TinyMVC on the server, HTML and JavaScript with the ExtJS framework for user interface.
Keywords
databases - fermentation profiles - web application - web server - software development - framework - PHP - MySQL - HTML - Javascript - ExtJS - TinyMVC
L’étude de la digestion chez les ruminants par des techniques in vitro de fermentation de l’écosystème ruminal génère de nombreuses expériences. Ceci afin de permettre une nutrition optimum de l’animal et d’améliorer les productions. Il existe à l’INRA (Institut National de la Recherche Agronomique) une nécessité pour centraliser tous les résultats obtenus, aussi appelés profils fermentaires.
Le projet résulte de la volonté d’automatiser certains traitements, de partager les données et de permettre une recherche multi-critères sur ces profils fermentaires. L’objectif est de concevoir une application web permettant d’effectuer le partage et la recherche sur ces données. Lors d’un précé-dant projet tutoré, j’ai élaboré en binôme avec un autre étudiant un cahier des charges pour cette application, construit son Modèle Conceptuel de Données (MCD) et étudié l’existant afin de stan-dardiser les données.
J’ai eu en charge durant ce stage la phase de réalisation de l’application. Je me suis tout d’abord intéressé aux technologies à mettre en oeuvre dans le cadre d’une application web et mis en place un serveur de test. J’ai ensuite réalisé le développement de l’application sur la base de framework ex-istant, afin de bénéficier d’une architecture solide et éprouvée. Les technologies utilisées sont PHP et MySQL avec le framework TinyMVC sur le serveur et HTML et Javascript avec le framework ExtJS pour l’interface utilisateur.
Mots Clés
base de données profils fermentaires application web serveur web développement applicatif -framework - PHP - MySQL - HTML - Javascript - ExtJS - TinyMVC
Table des matières
Introduction 1
I L’environnement 3
I.1 Présentation de l’institut et du laboratoire . . . 3
I.1.1 L’INRA . . . 3
I.1.2 Le contexte scientifique . . . 4
I.2 Le stage . . . 7
II Développement de l’application 9 II.1 Architecture . . . 9
II.1.1 L’architecture client/serveur . . . 9
II.1.2 Technologie de l’application cliente . . . 10
II.1.3 Technologie de l’application serveur . . . 10
II.1.4 Mise en place du serveur de test . . . 11
II.2 Les outils . . . 12
II.2.1 Framework . . . 12
II.2.2 TinyMVC . . . 12
II.2.3 ExtJS . . . 14
II.3 Les requêtes . . . 16
II.3.1 URL . . . 16
II.3.2 Cycle de vie d’une requête . . . 17
II.4 Le mode de développement . . . 19
II.4.1 Le développement par module . . . 19
II.4.2 Les fichiers de l’application cliente . . . 19
III Résultats 23
III.1 L’authentification . . . 24
III.2 La gestion de son profil . . . 25
III.3 La gestion des utilisateurs. . . 26
III.4 L’import des données . . . 27
III.5 La recherche. . . 28
III.6 Installation de l’application sur un serveur . . . 29
IV État d’avancement et perspectives 31 IV.1 Etat d’avancement. . . 31
IV.2 Les difficultés rencontrées . . . 32
IV.3 Perspectives . . . 33
IV.3.1 Le module d’import . . . 33
IV.3.2 Le module de recherche . . . 33
IV.3.3 La gestion des graphes et statistiques . . . 33
IV.3.4 La partie botanique . . . 34
Conclusion 35
Glossaire 36
Table des figures
1 Schéma organisationnel de l’INRA . . . 4
2 Schéma d’une expérience . . . 5
3 Schéma du projet dans son contexte . . . 7
4 Diagramme de Gantt . . . 8
5 Architecture Client/Serveur dans le cadre d’une application web . . . 9
6 Architecture MVC . . . 13
7 Interface utilisateur ExtJS . . . 14
8 Décomposition d’une URL . . . 16
9 Cycle de vie d’une requète . . . 18
10 Arborescence des fichiers . . . 20
11 Barre d’outils . . . 23
12 Interface d’authentification - Login . . . 24
13 Interface d’authentification - Perte de mot de passe . . . 24
14 Interface de gestion de son profil . . . 25
15 Interface de gestion des utilisateurs . . . 26
16 Interface d’import des données . . . 27
17 Interface de recherche d’expérience . . . 28
1
Introduction
Le monde de la recherche est extrêmement vaste et regroupe de nombreux domaines. L’a-gronomie est un domaine scientifique dans lequel les principales données relèvent de résultats d’expériences. L’INRA met en place de nombreux projets et génère énormément de données ex-périmentales.
Ainsi est né la volonté de faciliter l’utilisation et le partage de ces données. Le défi de l’organi-sation des données est un problème majeur. Il s’agit non seulement de regrouper les données, mais aussi de les rendre accessibles à des utilisateurs distants et identifiés.
Après avoir effectuer l’analyse et le cahier des charges lors d’un précédent projet tutoré, j’effectue durant ce stage la phase de réalisation du projet, le développement d’une application web d’import et de recherche de données de profils fermentaires.
Je me suis tout d’abord intéressé aux technologies à mettre en oeuvre dans le cadre d’une appli-cation web et mis en place un serveur de test. J’ai ensuite réalisé le développement de l’appliappli-cation sur la base de framework existant, afin de bénéficier d’une architecture solide et éprouvée.
Le résultat est une application Web qui automatise l’import des données de profils fermentaires et de permet une recherche multi-critère sur la base de données ainsi réalisé.
3
I
L’environnement
I.1
Présentation de l’institut et du laboratoire
I.1.1
L’INRA
L’Institut National de la Recherche Agronomique (INRA) est un organisme de recherche sci-entifique public, placé sous la double tutelle du ministère de l’Enseignement supérieur et de la Recherche, et du ministère de l’Alimentation, de l’Agriculture et de la Pêche. Il fut créé en 1946, à la fin de la seconde guerre mondiale, dans le but d’améliorer l’agriculture française et le domaine de l’agroalimentaire afin de pouvoir rendre la France autonome sur le plan de l’alimentation par l’intermédiaire de la recherche.
Ses recherches concernent les questions liées à l’agriculture, à l’alimentation, à l’environnement et à la gestion des territoires, avec une perspective de développement durable. Il est le troisième Etablissement Public à caractère Scientifique et Technologique (EPST) après le CNRS et le CEA. Aujourd’hui l’Inra compte 8 390 chercheurs, ingénieurs, techniciens et administratifs, 1 833 doc-torants, 14 départements scientifiques et 20 centres régionaux avec un budget de 745,68 millions d’euros pour 2008.
I.1.1.1 Le centre de recherche de Clermont-Ferrand / Theix
Le centre de recherche de Clermont-Ferrand / Theix rassemble 9% de l’effectif total de l’Institut et constitue le troisième des 20 Centres de recherche de l’Inra. Il regroupe 10 grandes unités de recherche implantées en Auvergne (Theix, Clermont-Ferrand, Crouël, Aurillac, Orcival, Laqueuille, et Marcenat). Les recherches du centre sont structurées autour de 4 axes :
– Génomique et physiologie végétales – Territoires, élevage, environnement – Qualités des produits animaux – Nutrition humaine préventive
I.1.1.2 L’unité de recherche sur les herbivores (URH) et l’équipe DIMA
L’unité de recherche sur les herbivores (UR1213) est située, avec 7 autres unités, sur l’implanta-tion de Theix, elle a pour mission de contribuer au développement des systèmes durables d’élevage des herbivores en conciliant viabilité socio-économique et développement rural, respect de l’envi-ronnement, qualité des produits et bien-être animal. Dans ce cadre, l’URH évalue les systèmes de production et propose des techniques innovantes pour optimiser ces systèmes.
L’équipe DIMA (DIgestion Microbienne et Absorption) au sein de laquelle j’ai effectué mon stage, est une des 8 équipes de recherches de l’URH. Elle a pour objectif de maîtriser, par l’ali-mentation, l’écosystème microbien du rumen et les flux digestifs de macronutriments et micronu-triments chez les ruminants, en vue d’améliorer la qualité nutritionnelle et sanitaire des produits animaux consommés par l’homme et de préserver la santé animale et l’environnement (gaz à effet de serre).
INRA
Départements de recherche Centres de recherche Unités
URH URx URy
D. Macheboeuf Y. Papon X.x
FIG. 1 – Schéma organisationnel de l’INRA
I.1.2
Le contexte scientifique
L’équipe étudie la digestion chez les ruminants dans le cadre de systèmes agricoles durables, respectueux de l’environnement et de la santé publique. Ces animaux ont pour caractéristiques de pouvoir digérer les végétaux grâce à un écosystème microbien très dense qu’ils hébergent dans un compartiment gastrique, le rumen.
I.1. PRÉSENTATION DE L’INSTITUT ET DU LABORATOIRE 5
Les polymères végétaux (cellulose, lignine, amidon, protéines) sont dégradés et transformés par les microbes au cours du processus en produits de fermentation qui sont libérés sous forme de gaz (hydrogène, méthane, CO2 ), d’acides gras volatils (AGV : acétate, propionate, butyrate, valérate...) et d’ammoniac. L’ensemble des produits de fermentation obtenus pour un aliment donné représente son profil fermentaire.
Ces profils fermentaires sont obtenus au cours d’expériences in-vitro que l’on peut simplifier à travers un schéma.
FIG. 2 – Schéma d’une expérience
I.1.2.1 Des contraintes environnementales et économiques
Les recherches portent sur la manipulation des fermentations ruminales et l’optimisation des pro-fils fermentaires pour d’une part, réduire les émissions de méthane (qui est un gaz à haut pouvoir de réchauffement global et représente une perte d’énergie pour l’animal et une perte économique pour l’éleveur), réduire la production d’ammoniac pour limiter les rejets azotés dans l’environnement et d’autre part, augmenter la production d’AGV pour améliorer l’efficacité alimentaire.
I.1.2.2 Des contraintes juridiques
Par ailleurs, depuis l’interdiction en 2006 par la communauté européenne de l’utilisation des an-tibiotiques et de tous les additifs de synthèse dans l’alimentation animale, il y a une demande impor-tante pour des additifs alimentaires d’origine naturelle. Des extraits de plantes riches en métabolites secondaires peuvent représenter dans certains cas des alternatives intéressantes.
I.1.2.3 Un objectif scientifique
Dans les 7 dernières années, de nombreux essais expérimentaux ont été réalisés in vitro en in-cubant des substrats végétaux avec les microbes du rumen dans des fermenteurs de type batch et ont aboutis à l’enregistrement en moyenne de 120 à 180 profils fermentaires par essai.
Dans l’objectif de mieux tirer parti de cette masse de données qui s’accumulent (par exemple sous forme de méta-analyse entre les essais), il était impératif d’organiser celles-ci dans un système permettant de les consulter et de les extraire rapidement selon les besoins.
I.2. LE STAGE 7
I.2
Le stage
Le projet et ses objectifs
Le stage que j’ai effectué s’inscrit dans le cadre d’un projet global de mise en base de données et de recherche sur les profils fermentaires par différents utilisateurs. Il a été précédé d’un projet tutoré que j’ai effectué en binôme avec un autre étudiant. Le but du projet tutoré était d’effectuer l’analyse de ce projet et d’en concevoir le cahier des charges.
Ce stage consiste donc en la phase de réalisation de l’application en se basant sur l’analyse et le cahier des charges effectué lors du projet tutoré.
Projet Cahier des charges Développement Application
Analyse Réalisation
FIG. 3 – Schéma du projet dans son contexte
L’objectif durant les 5 mois de ce stage est la réalisation d’une application permettant : – l’import des données de profils fermentaires en base de données,
– leur partage entre différents utilisateurs,
– la recherche multicritère à travers l’ensemble de ces données.
Bénéfices envisagés
Les chercheurs de l’équipe de digestion microbienne sont les premiers concernés par les aspects positifs de l’application. Les bénéfices envisagés sont la centralisation des données de tous ces profils fermentaires et la possibilité de méta-analyse. Par méta-analyse, on entend l’analyse des données entre les différents projets, un sujet d’étude aujourd’hui inexploité.
Les investigateurs des études bénéficient, eux, des apports dans un second temps. En effet, les rapports et conclusions des chercheurs seront les mêmes, mais apparaitront dans des délais plus courts. Ils pourront accéder aux profils fermentaires de n’importe quel ordinateur connecté à internet et procéder également à leur propre recherche.
Planning prévisionnel
En début de stage, nous avons définit un planning prévisionnel avec mon tuteur. Ce planning a permis de définir les différentes tâches à effectuer et le temps prévu afin de les réaliser. Ceci afin de définir un cadre à suivre et permettre de suivre l’avancée des travaux. La figure4montre le planning prévisionnel des travaux.
9
II
Développement de l’application
II.1
Architecture
II.1.1
L’architecture client/serveur
Les conclusions de l’analyse (qui a précédé le stage) ont défini le cadre de réalisation de cette application. Il s’agit de réaliser une application web, ce qui permettra de centraliser les données sur un serveur Web et les partager aux utilisateurs autorisés.
Une application web repose sur une architecture client/serveur. L’architecture client/serveur désigne un mode de communication entre plusieurs ordinateurs d’un réseau qui distingue un ou plusieurs clients du serveur : chaque logiciel client peut envoyer des requêtes à un serveur.
Le client et le serveur doivent bien sûr utiliser le même protocole de communication, le protocole HTTP (HyperText Transfer Protocol) dans le cas d’une application web. Un serveur est générale-ment capable de servir plusieurs clients simultanégénérale-ment.
Dans cette architecture, l’application web est scindé en deux parties. L’application cliente se charge de faire les affichages des données à travers un navigateur internet, et sert d’interface à l’utilisateur pour accéder aux données. L’application serveur se charge de traduire les requêtes du client, d’accéder à la base de données et de transmettre les résultats de ces requêtes à ce même client.
II.1.2
Technologie de l’application cliente
Pour l’application cliente, nous devons utiliser les technologies disponibles dans les navigateurs internet, HTML (Hypertext Markup Language) et Javascript. Le HTML est un langage de balisage qui permet de structurer et mettre en forme le contenu. Le Javascript est quant à lui un langage de script qui nous permet de gérer des évènements et les comportements associés sur les éléments HTML de notre application, afin d’obtenir un client léger riche. Les clients légers riches (Rich Inter-net Application ou RIA), sont nés de la volonté de proposer des applications web aux fonctionnalités proches des applications traditionnelles.
Les applications internet riches permettent de présenter des contenus à travers des composants avancés, qui ne sont pas fournis par défaut en HTML, comme les grilles de données par exemple. Comme pour toute application internet, l’utilisateur se connecte sur le serveur par le biais de son navigateur et peut utiliser l’application de n’importe quel poste.
II.1.3
Technologie de l’application serveur
L’application serveur utilise les technologies déployées sur les serveurs de production de l’INRA, à savoir le couple PHP5 et MySQL5.
Dans une utilisation Web, l’exécution du code PHP se déroule ainsi : lorsqu’un utilisateur génère un évènement sur l’application web, son navigateur envoie une requête au serveur HTTP correspon-dant. Le serveur appelle l’interprète PHP qui va traiter la requête, se connecter à la base de données MySQL s’il y a lieu et générer la réponse à renvoyer au serveur HTTP, qui l’envoie finalement au client.
II.1. ARCHITECTURE 11
II.1.4
Mise en place du serveur de test
La mise en place d’un serveur web est indispensable afin de pouvoir tester notre application au cours de son développement. Ce serveur de test doit être le plus proche possible de la configuration de production afin de limiter les erreurs dues à des différences de paramétrages entre le serveur de test et celui de production.
Je me suis donc rapproché de l’administrateur système de l’INRA afin de reproduire la configu-ration de leur serveur web. L’architecture des serveurs de production de l’INRA étant basés sur des logiciels libres, ils peuvent être installés sans problème de licence.
Pour mon serveur de test, j’ai du installer : – Linux, le système d’exploitation
– Apache, le serveur HTTP[?]
– MySQL, un système de gestion de bases de données (SGBD). Il permet de stocker et d’organiser des données ;
– PHP, permet le traitement de données et la communication avec le serveur MySQL.
La configuration de Apache, MySQL et PHP se fait par des variables recensées dans un fichier texte. L’administrateur de l’INRA m’a fournit les fichiers de configuration des serveurs de produc-tion afin que je la réplique.
II.2
Les outils
II.2.1
Framework
Un framework est un ensemble d’outils et de composants logiciels organisés conformément à un plan d’architecture et de patrons de conception. Les principaux avantages de ces frameworks sont la réutilisation de leur code, la standardisation du cycle de vie du logiciel, ils permettent de formaliser une architecture adaptée aux problématiques à résoudre.
Le choix des frameworks utilisés dans ce projet a été fait en fonction de deux critères fondamen-taux :
– ils sont opensource et sont donc libres d’utilisation sans frais de license
– ils sont simples d’utilisation et répondent strictement aux besoins de l’application
II.2.2
TinyMVC
J’ai choisi le framework TinyMVC pour l’application serveur. Ce framework offre uniquement un cadre pour structurer l’application, basé sur l’architecture Modèle/Vue/Con-trôleur (MVC). TinyMVC est un ensemble de fichier PHP qui peuvent être téléchargé sur http ://www.tinymvc.com/[?]
MVC est un modèle de conception qui impose la séparation entre les données, les traitements et la présentation. C’est pour cette raison que l’application est divisée en trois composants fondamen-taux : le modèle, la vue et le contrôleur. Chacun de ces composants tient un rôle bien défini.
La vue correspond à l’interface avec laquelle l’utilisateur interagit. Aucun traitement n’est effec-tué dans la vue ; elle sert uniquement à afficher les données et permettre à l’utilisateur d’agir sur ces données.
Le deuxième composant du MVC, le modèle, représente les données et les règles métier. C’est là que s’effectuent les traitements. Les accès à la base de données en font partie. Les données renvoyées par le modèle sont indépendantes de la présentation, c’est-à-dire que le modèle ne réalise aucune mise en forme. Les données d’un seul modèle peuvent ainsi être affichées dans plusieurs vues. Cette capacité permet de factoriser le code, car le code du modèle n’est écrit qu’une seule fois puis réutilisé par toutes les vues.
Pour finir, le contrôleur interprète les requêtes de l’utilisateur et appelle du modèle et de la vue nécessaires pour répondre à la requête. Ainsi, lorsque l’utilisateur clique sur un bouton ou soumet un formulaire HTML, le contrôleur ne produit rien et n’effectue aucun traitement. Il intercepte la requête et détermine quels modèles et quelles vues doivent êtres associés.
II.2. LES OUTILS 13
FIG. 6 – Architecture MVC
Pour résumer, une requête utilisateur est interprétée par le contrôleur, qui détermine quelles por-tions du modèle et de la vue doivent être appelées. Le modèle gère les interacpor-tions avec les données et applique les règles métier, puis renvoie les données. Enfin, le contrôleur sélectionne une vue et lui passe les données.
II.2.3
ExtJS
Pour l’application cliente, j’ai choisi d’utiliser le framework ExtJS. Le but de ce framework est de déployer une application client léger riche avec la technologie Javascript rapidement et très simplement.[?] ExtJS est un ensemble de fichier Javascript qui peuvent être téléchargé sur http ://www.sencha.com/[?]
ExtJS apporte un grand nombre de composants visuels tels que les arbres, des tableaux avancés (ou DataGrid), des onglets, des composants qui n’existent pas de base en HTML.
FIG. 7 – Interface utilisateur ExtJS
En plus de ces composants indispensables à notre application, ExtJS permet également la gestion des évènements et une standardisation des communications client/serveur en JSON (JavaScript Object Notation). JSON (JavaScript Object Notation) est un format de données textuel, générique,
II.2. LES OUTILS 15
dérivé de la notation des objets du langage JavaScript.
Listing II.1 – Exemple de données au format JSON 1 {"menu": {
2 "id":"file", 3 "value":"File", 4 "popup": {
5 "menuitem": [
6 {"value":"New","onclick":"CreateNewDoc()"}, 7 {"value":"Open","onclick":"OpenDoc()"}, 8 {"value":"Close","onclick":"CloseDoc()"}
9 ]
10 }
11 }}
Nous pouvons comparer les composants ExtJS à des briques de base pour l’interface de notre application. La première étape du développement de notre application consiste à créer l’interface utilisateur en associant les différents composants afin d’obtenir le rendu souhaité. Comme dans un jeu de briques, on associe les composant : dans un composant "Window", on ajoute une barre d’outils et une grille de données. Dans la barre d’outils on ajoute un menu, des boutons. Petit à petit notre interface utilisateur se construit, comme on peut voir un exmple sur la figure7
Ensuite nous mettons en place la couche évènementielle de l’application, en définissant les com-posants actifs de l’application et leur comportement. Enfin, ExtJS permet la communication avec le serveur et le traitement de réponse au format JSON.
II.3
Les requêtes
Une application web est une succession de requête et de réponse entre un client et le serveur. La compréhension du cycle de vie de ces requêtes permet d’appréhender le fonctionnement de l’application.
II.3.1
URL
Une requête est une demande de contenu au serveur à travers une URL (de l’anglais Uniform Resource Locator, littéralement « localisateur uniforme de ressource »), auquel se substitue in-formellement le terme adresse web. Cette adresse permet de localiser le serveur et le traitement à effectuer.
Prenons l’exemple d’une requête permettant d’accéder à la liste des projets. Dans l’application, un évènement (par exemple un clique sur un bouton) génère une requête au serveur pour avoir la liste des projets. L’application connait uniquement l’URL vers laquelle il faut aller chercher cette information, et le format de la réponse qu’elle attend pour poursuivre le traitement.
FIG. 8 – Décomposition d’une URL
Notre URL contient toutes les informations d’accès à cette ressource que nous souhaitons : – le protocole de communication avec le serveur
– adresse du serveur
– le chemin de la ressource sur le serveur – les paramètres à transmettre à cette ressource.
II.3. LES REQUÊTES 17
II.3.2
Cycle de vie d’une requête
Cette URL est transmise au navigateur et correspond donc à une requête au serveur. Nous allons maintenant suivre son cycle de vie :
– le navigateur se connecte au serveur Apache et lui transmet l’URL – Apache fait appel à PHP pour exécuter le traitement demandé.
– Notre framework TinyMVC analyse les paramètre de l’URL pour savoir quel contrôleur nous avons appeler.
– Le contrôleur exécute la demande en prenant les données dont il a besoin dans les modèles ou vues qui les contiennent.
– Dans notre cas, la liste des projets étant en base de données, le contrôleur va faire appel au modèle Projet qui contient la méthode getProjets. Cette méthode récupère les informations – sur les projets dans la base de données MySQL et les transmets au contrôleur. Celui ci
pour-suit son traitement en affectant ces données à une vue, qui définit le format d’affichage de celle ci. – Le contrôleur dispose maintenant des données, formatées grâce à la vue. Le PHP fini exécution
et transmet ces données formatées à Apache.
– Apache finalise la transaction en renvoyant la réponse à la requête initiale. – L’application cliente reçoit la réponse du serveur, et poursuit son traitement.
II.4. LE MODE DE DÉVELOPPEMENT 19
II.4
Le mode de développement
II.4.1
Le développement par module
Nous avons vu que notre application était séparée en deux, la partie serveur et la partie cliente. L’application serveur ne sert qu’à transmettre des données à la partie cliente. Aussi ces deux parties sont développés parallèlement sous forme de module. Chaque module correspond à une fonction-nalité de notre application et peut donc être développées de manière indépendante.
Notre application de recherche sur les profils fermentaires est découpée en 5 modules :
– L’authentification, qui permet de gérer l’accès à l’application et le recouvrement de son mot de passe
– La gestion de son profil, qui permet à l’utilisateur de modifier ses informations de profils
– La gestion des utilisateurs, qui permet à l’administrateur de gérer les utilisateurs de l’application – L’import des données, qui permet à l’administrateur de populer la base de données.
– La recherche, qui permet aux utilisateurs la recherche multicritère sur les profils fermentaires auxquels ils ont accès.
Chaque module dispose de plusieurs types de fichiers, chacun ayant un rôle précis. L’architec-ture mise en place et la séparation du code en fichier en fonction de son rôle permet de facilité l’organisation et la maintenance de l’application.
II.4.2
Les fichiers de l’application cliente
Du côté de l’application cliente, nous disposons de 3 types de fichiers. Tous ces fichiers sont du code JavaScript orienté objet utilisant le framework ExtJS.
Pour chaque module, il y a tout d’abord le fichier JavaScript qui définit l’interface utilisateur. Ce code ExtJS a pour but d’agencer les différents composants utilisés dans le module pour obtenir l’interface utilisateur.
Un second fichier JavaScript définit les comportements de ses composants, leur évènement et les traitements en résultant.
Enfin le dernier type de fichier correspondant à un concept introduit par ExtJS : les Store (ou source de données). Chaque composant ExtJS dispose de fonctionnalités permettant la manipulation des données qu’il contient. Le Store est là pour définir le format des données et l’URL permettant d’accéder à celles ci. Chaque module comporte autant de Store que de sources de données nécessités par ses composants.
II.4.3
Les fichiers de l’application serveur
Du côté de l’application serveur, la séparation des fichiers est imposé par le framework TinyMVC selon une architecture MVC. Nous retrouvons donc ici les 3 types de fichiers, modèle, vue et con-trôleur, comme vu précédement.
II.4.4
Arborescence des fichiers
FIG. 10 – Arborescence des fichiers
Le fichier « index.php » est le point d’entrée de l’application. C’est dans ce fichier que sont définis les variables de configuration de l’application, et que se fait le chargement de TinyMVC. Le répertoire « js » regroupe quant à lui tous les fichiers javascript de l’application cliente. Les fichiers PHP de l’application serveur sont stockés dans le répertoire « profils fermentaires ».
II.4.5
Méthode AJAX
Lorsque l’utilisateur se connecte à l’application, il envoie une requête de récupération de l’inter-face utilisateur du module qu’il souhaite utiliser. Une fois ce module chargé dans son navigateur, les technologies web traditionelles voudraient qu’à chaque nouvelle requête, l’intégralité de la page
II.4. LE MODE DE DÉVELOPPEMENT 21
internet et donc de notre application se recharge. Cet héritage des sites web statiques peut vite ren-dre l’ergonomie et l’utilisation d’une application infernale. Chaque évènement (comme un clique sur un bouton) peut potentiellement générer une requête et donc nécessite un rechargement de l’ap-plication. Les temps de lantence entre chaque évènement rendraient l’application inutilisable.
C’est pour combler cette lacune qu’existe la méthode AJAX. AJAX ( Asynchronous JavaScript And XML) est en fait un nom qui désigne l’utilisation conjointe de plusieurs technologies web, un mélange de Javascript et de DHTML. Pour simplifier, Ajax est un ensemble de fonctionnalités qui permet de recharger seulement une partie d’une page web.
ExtJS dispose d’une couche AJAX, elle est utilisée dans notre application pour faire des requêtes au serveur sans recharger la page. Cela permet à notre application de ne subir aucun rechargement de page tant que l’on reste dans un même module. Une fois le module chargé, la grande majorité des requêtes générées par des évènements correspondent au chargement de source de données. En utilisant la couche AJAX de ExtJS, seule la source de données sera rechargée.
23
III
Résultats
Le résultat de mon travail à l’INRA est une application web qui contient 2 pages web séparées. Une première contient uniquement le module d’authentification. L’utilisateur est automatiquement redirigé vers cette page s’il n’est pas authentifié sur le serveur, cela permet la sécurisation de l’ap-plication.
Une fois authentifié, l’utilisateur est dirigé vers une nouvelle page qui contient l’ensemble des mod-ules (hors module d’authentification). La navigation entre ces modmod-ules se fait grâce à un menu disponible dans une barre d’outils situé en haut de l’application.
Les menus disponibles sont fonctions du type d’utilisateur. Par exemple, un administrateur a accès au module d’import des données alors que l’utilisateur ne peut pas.
FIG. 12 – Interface d’authentification - Login
III.1
L’authentification
Le module d’authentification gère l’accès à l’application. L’interface utilisateur permet de se connecter à l’application en saisissant son email et son mot de passe, ou de recevoir son mot de passe par mail s’il a été oublié.
III.2. LA GESTION DE SON PROFIL 25
III.2
La gestion de son profil
FIG. 14 – Interface de gestion de son profil
La gestion de son profil permet à l’utilisateur de mettre à jour ses données personnelles ainsi que son mot de passe.
III.3
La gestion des utilisateurs
FIG. 15 – Interface de gestion des utilisateurs
La gestion des utilisateurs permet à l’administrateur l’ajout, la modification et la suppression d’utilisateurs de l’application. Chaque ajout d’utilisateur génère un envoi de mail automatique du serveur à l’utilisateur de la création de son compte, de son mot de passe et des paramètres d’accès à l’application.
III.4. L’IMPORT DES DONNÉES 27
III.4
L’import des données
FIG. 16 – Interface d’import des données
Le module d’import des données est la partie centrale de l’application. Les données des profils fermentaires sont actuellement stockées sous la forme de nombreux fichiers excel.
Il a fallu tout d’abord procéder à la standardisation de ces fichiers et à leur organisation afin de pouvoir les transférer dans une base de données SQL. Ceci a permis de découper l’import de la base de données en plusieurs étapes fonctionnant toutes sur le même modèle afin de factoriser les efforts de développement.
Pour chaque étape le fonctionnement est identique : l’administrateur télécharge le fichier excel standardisé sur le serveur et lance son traitement. Le résultat du traitement est l’affichage des don-nées du fichier dans une grille de dondon-nées dans l’interface utilisateur, pour validation. Les dondon-nées validées sont ensuite injectées dans la base de données.
III.5
La recherche
FIG. 17 – Interface de recherche d’expérience
L’interface de recherche est toujours en développement à ce stade du projet.
L’interface de recherche s’utilise en définissant un domaine de recherche. Le domaine de recherche correspond à la liste des projets et sous projets dans lesquels on souhaite effectuer la recherche. Une recherche peut donc être effectué à travers plusieurs projets, permettant une méta-analyse des données. Une fois le domaine de recherche défini, on peut filtrer les expériences à travers un moteur de recherche afin de ne lister que les expériences souhaitées. A ce stade, chaque filtre de recherche s’additionne afin de retourner les expériences correspondant à l’intersection des différents filtres.
La mise au panier permet de stopper ce processus et de réaliser une union entre différentes recherches. Le panier contient toutes les expériences obtenues à travers différents filtres. On peut maintenant les exporter dans un fichier CSV. Le fichier exporté sera traité à travers d’autres appli-cations tel que SAS afin d’en tirer différentes statistiques.
III.6. INSTALLATION DE L’APPLICATION SUR UN SERVEUR 29
III.6
Installation de l’application sur un serveur
L’installation de l’application se fait en 3 étapes : – La récupération des fichiers sur le subversion – La mise en place des fichiers sur le serveur
– L’importation de la base de données sur le serveur.
Les fichiers de l’application sont stockés sur le serveur subversion de l’INRA de Clermont-ferrand-Theix. Pour pourvoir y accéder, il faut tout d’abord faire une demande d’accès au service informatique. L’accès se fait ensuite grâce à un client subversion (tortoiseSVN est un client gratuit disponible sur Windows) sur l’URL :
Listing III.1 – Dépôt subversion de l’application 1 https:\\www1.clermont.inra.fr\svn\profils_fermentaires
Le login et mot de passe fournit par le service informatique vous sera indispensable pour vous connecter.
Une fois les fichiers récupérés, vous devrez les mettre en place sur un serveur PHP-MySQL. La configuration de l’application se fait grâce à des variables placées dans le fichier index.php situé à la racine de l’application.
Listing III.2 – Variables de configuration de l’application
1 /* if the /myapp/ dir is not inside the /tinymvc/ dir , uncomment and set here */
2 define(’TMVC_MYAPPDIR’,’/home/khsini/Bureau/svn/fermentation1.1/’); 3
4 ... 5
6 /* Definition des constantes de l ’ application */ 7 if(! defined(’HOME_PATH’))
8 define(’HOME_PATH’,’http://localhost/projet/’); 9 if(! defined(’EXTJS_PATH’))
10 define(’EXTJS_PATH’,’http://localhost/projet/js/ext-3.2.1/’); 11 if(! defined(’LOGIN_PATH’))
12 define(’LOGIN_PATH’,’http://localhost/projet/js/login/’); 13 if(! defined(’MAIN_PATH’))
14 define(’MAIN_PATH’,’http://localhost/projet/js/recherche/’); 15 if(! defined(’INCLUDE_PATH’))
16 define(’INCLUDE_PATH’,’/home/khsini/Bureau/svn/_sources/’); 17 if(! defined(’PHPMAILER_PATH’))
18 define(’PHPMAILER_PATH’, INCLUDE_PATH .’PHPMailer_v5.1/’); 19 // le repertoire d’upload doit avoir les droits d’ ecriture
20 if(! defined(’UPLOAD_PATH’))
21 define(’UPLOAD_PATH’,’/home/khsini/Bureau/svn/uploads/’); .
Il faudra également bien pensé à mettre les droits d’upload sur le répertoire définit pour les recevoir, comme indiqué dans le fichier de configuration.
Enfin, il faut importer la base de données dans MySQL. Un export MySQL est disponible dans le repertoire _sources sous la forme d’un fichier portant une extension .sql.
31
IV
État d’avancement et perspectives
IV.1
Etat d’avancement
FIG. 18 – Etat d’avancement des différents modules
A ce stade de mon stage, je ne suis pas parvenu à tenir le planning prévisionnel proposé à mon arrivée. L’architecture de l’application est en place et robuste mais l’intégralité des modules pro-posés n’ont pas pu être développés. Le module de recherche n’est pas abouti, seule une version préliminaire d’interface graphique est prête.
Le module d’import des données est le point bloquant de ce projet. En effet, l’application né-cessite d’être fournit en données afin de pouvoir valider le schéma de base de données, qui sont les fondations même du module de recherche. Tant que le module d’import n’est pas terminé, la recherche est donc bloquée.
Je pense pouvoir terminer le module d’import avant la fin de mon stage, ainsi qu’une version basique du moteur de recherche.
IV.2
Les difficultés rencontrées
La principale difficulté rencontrée au cours de mon stage a été d’apréhender le framework ExtJS. La courbe d’apprentissage de ce framework est longue, d’autant plus quand il faut assimiler le javascript. Il dispose néanmoins d’un forum et d’une documentation très complète [?], et des livres sont égalements disponible [?]. Une fois passé le cap de l’apprentissage de ce framework, il devient un outil puissant et indispensable.
Une autre grosse difficulté vient des outils d’éditions disponibles pour travailler sur ce type d’ar-chitecture.
La prise en charge des technologies web existe dans de nombreux outils d’éditions mais ils ne sont pas adapté pour travailler avec des framework qui impose un cadre d’architecture stricte. Il se limite à la coloration syntaxique en fonction du langage et il est très compliqué d’installer une plateforme homogène qui permet d’associer un outil d’édition à un debugger.
Ce type de plateforme existe sur des frameworks PHP beaucoup plus complexe mais pas adaptés à la taille de mon application. De fait, l’absence d’environnement de débuggage évolué devient très vite problématique.
Une autre difficulté est inhérente au travail dans un laboratoire scientifique, et pas dans un service informatique. L’absence de collègue informaticien se fait sentir lorsque l’on est confronté à un bug qui nous paraît insoluble. Pouvoir en discuter avec un collègue permet souvent de voir le problème sous un autre angle et comprendre l’erreur que l’on fait plus rapidement.
IV.3. PERSPECTIVES 33
IV.3
Perspectives
Maintenant que les bases de cette application sont posées, de nombreuses possiblités d’améliora-tions et d’évolud’améliora-tions peuvent être envisagées. Les besoins des chercheurs sont nombreux et l’archi-tecture de l’application développée peut servir de fondation à de nombreuses évolutions ou création de nouveaux modules.
IV.3.1
Le module d’import
Le module d’import correspond à une problématique de transfert des données de projets passés. Ces profils fermentaires ayant été saisie au format Excel, j’ai créer un import à partir de ces fichiers. Pour les projets futurs, il est possible d’envisager une interface de saisie des profils fer-mentaires directement dans l’application. Cette interface serait complémentaire de l’import, qui resterait disponible pour les données saisies sous le format Excel.
IV.3.2
Le module de recherche
Suite à une réunion pour préciser les volontés de recherche auprès de M. Didier Macheboeuf, il s’avère que de nombreuses demandes existent. De grosses perspectives s’ouvrent de ce côté, qui n’ont de limite que la variété des recherches que voudraient effectuer les chercheurs de l’URH.
Durant mon stage je me suis concentré sur les recherches sur les productions. Mais d’autres types de recherches sont déjà demandés et ouvrent de nouvelles possibilités :
– les recherches sur les substrats, en fonction des quantité ou du type d’utilisation, – les recherches sur les analyses chimiques
– les recherches sur les régimes alimentaires des animaux – les recherches sur les résidus de fermentations
Toutes ces données sont en base et ne nécessitent donc qu’une interface utilisateur pour les ex-ploiter...
IV.3.3
La gestion des graphes et statistiques
A l’heure actuelle l’application est conçu pour générer un export des données recherchées afin d’utiliser un outil externe de statistique et de génération de graphes.
On peut envisager d’intégrer cette génération de graphe dans l’outil. Le framework ExtJS dispose de tous les composants graphiques nécessaires à la génération de graphes. L’outil externe sera un intermédiaire supplémentaire supprimé, cela permettra un gain de temps appréciable.
IV.3.4
La partie botanique
La partie botanique avait déjà été abordé lors de mon projet tutoré. Les données des profils fer-mentaires contiennent toutes les informations sur les plantes qui servent de substrats. Une partie encyclopédique pourrait permettre la visualisation et le partage de ces données sous forme de fiche. Un travail de recensement et de récupération d’informations sur près de 400 plantes de la région est disponible, l’application pourrait permettre de partager ces informations.
35
Conclusion
Mon stage portait sur la réalisation d’une application pour l’INRA de Theix, dans le cadre de traitement de données de profils fermentaires.
J’ai pu durant ce projet suivre l’ensemble du processus de création d’une application web. Au cours d’un projet tutoré qui a précédé, j’ai réalisé l’ensemble de la phase d’analyse et de conception. Et pendant ce stage, j’ai pu mettre en oeuvre le cahier des charges et aborder la partie technique et production d’une application web.
Les objectifs de réalisation prévus pour ce projet ne sont pas tous atteints. Néanmoins l’applica-tion réalisée s’en rapproche et propose une architecture de développement évolutive et extensible sur laquel pourront se greffer de futur projet.
Le résultat de ce stage est un outil qui permettra aux chercheurs de l’INRA d’améliorer le temps de traitement de leurs données et d’explorer de nouveaux axes de recherches tels que la méta-analyse. De nouveaux domaines de recherche sur ces données deviennent accessible pour les chercheurs, qui auront de fait de nouvelles demandes. Je pense avoir répondu à ces problématiques et développé une application sur la base de fondations solides qui pourront être reprises par de futurs stagiaires.
Glossaire
ExtJS
Framework JavaScript permettant la réalisation de RIA HTML
Le format de données conçu pour représenter les pages web. IHM
L’interface homme-machine définit les moyens et outils mis en œuvre afin qu’un humain puisse contrôler et communiquer avec une machine.
INRA
L’Institut National de la Recherche Agronomique (INRA) est un centre de recherche national public
JSON
JavaScript Object Notation est un format de données textuel, générique, dérivé de la notation des objets du langage JavaScript.
MCD
Modèle conceptuel de données, il s’agit d’une représentation logique de l’organisation des informations et de leurs relations.
MVC
Modèle-Vue-Contrôleur, une architecture de conception qui impose la séparation entre les données, les traitements et la présentation
PHP
Langage de scripts libre principalement utilisé pour produire des pages Web dynamiques RIA
Rich Internet application (RIA), ou application Internet riche, est une application web qui offre des caractéristiques similaires aux logiciels traditionnels installés sur un ordinateur. SQL
Structured query language (SQL), ou langage structuré de requêtes, est un pseudo-langage informatique (de type requête) standard et normalisé, destiné à interroger ou à manipuler une base de données relationnelle
URH
Références
bibliographiques/webographiques
[1] Alan H. Lake. TinyMVC. http://www.tinymvc.com/.
[2] Ben Laurie and Peter Laurie. Apache La référence. O’REILLY, Août 2003. ISBN : 2-84177-225-X.
[3] Jorge Ramon. Ext JS 3.0 Cookbook : 109 Great Recipes for Building Impressive Rich Internet Applications Using the Ext Js Javascript Library. Packt Publishing Limited, Octobre 2009. ISBN-13 : 978-1847198709.
1 Diagramme de classes I
I
1
Diagramme de classes
FIG. 1 – Diagramme de Classes
III
2
Modèle conceptuel de données
FIG. 2 – MCD complet - partie 1
