Interfaçage Logiciel et Base de données

HAL Id: hal-02594631

https://hal.inrae.fr/hal-02594631

Interfaçage Logiciel et Base de données

Eléna Cadic

To cite this version:

Eléna Cadic. Interfaçage Logiciel et Base de données. Sciences de l’environnement. 2010. �hal-02594631�

DEPARTEMENT INFORMATIQUE - IUT 2 GRENOBLE

Année Universitaire 2009-2010 MEMOIRE DE STAGE

Interfaçage Logiciel et Base de données

AgroParisTech Engref – UMR TETIS

Cemagref – UMR G-EAU

Présenté par CemOA : archive ouverte d'Irstea / Cemagref

Remerciements

Je tiens à exprimer mes remerciements envers Géraldine ABRAMI et Flavie CERNESSON, mes deux responsables de stage, pour leurs conseils et la confiance qu’elles m’ont accordé.

De la même manière, un grand merci à Laura JOYCE et Yann LAURILLAU pour le soutien dont ils ont fait preuve lors de l’annulation de mon stage précédent.

Merci aussi à VASILISHINA Olga d’avoir apporté sa contribution à l’élaboration de l’analyse de sensibilité.

Enfin je tiens à remercier Gwenaëlle BUISSON, Mathieu CHEVALIER, Isabelle MAZZEO, Claire OBELLIANNE et Elodie PARIS pour m’avoir supporté au bureau des stagiaires pendant la période de mon stage.

CemOA

: archive

ouverte

d'Irstea

Table des matières

REMERCIEMENTS ...2

TABLE DES MATIERES ...3

INTRODUCTION ...5

PARTIE I. PRESENTATION DU CONTEXTE PROFESSIONNEL ...6

I.1 PRESENTATION DE L’ORGANISME D’ACCUEIL ...6

L’UMR FAVORISE 4 AXES DE RECHERCHE PRINCIPAUX : ...7

I.2 CADRE GENERAL DE TRAVAIL ...9

I.3 PRESENTATION DU SUJET ...9

II.4 PLANNING ...10

PARTIE II : OBJECTIFS ET SPECIFICATIONS ...11

II.1 OBJECTIF ...11

II.2 SPECIFICATION DES EXIGENCES ...12

II.3 ETUDE DES LOGICIELS ...14

II.4 EVOLUTIONS ...17

PARTIE III : STRUCTURE GLOBALE ET SPECIFICITES TECHNIQUES ...18

III.1 STRUCTURE GLOBALE ...18

III.2 CHOIX TECHNIQUES ...19

III.3 NAVIGATION ...20

III.4 INTERFACE GRAPHIQUE ...20

PARTIE IV : GESTION ET CONSULTATION DE LA BASE ...22

IV.1 OBJECTIFS ...22

IV.2 SPECIFICATION DES FONCTIONNALITES ...22

IV.3 CONCEPTION ...23

IV.4 REALISATION ...24

IV.5 TESTS ET EVOLUTIONS ...24

PARTIE V : INTERACTIONS AVEC R ...26

V.1 INTRODUCTION ...26

V.2 LES MOYENS D’INTERACTION ...26

V.3 L’ADAPTABILITE DU MODULE ...26

V.4 METHODES DE REDACTION D’UN PROGRAMME .R ...26

V.5 L’EXECUTION D’UN PROGRAMME .R ...28

V.6 REALISATION DE L’INTERACTION AVEC R ...28

V.7 LES MODIFICATIONS ENVISAGEES ...29 CemOA : archive ouverte d'Irstea / Cemagref

CemOA

: archive

ouverte

d'Irstea

Introduction

Dans le cadre de la formation DUT Informatique, Génie Logiciel dispensée à l’IUT2 de Grenoble (Université Pierre Mendès France), chaque étudiant est tenu d’effectuer un stage en entreprise d’une durée de 10 semaines minimum, au cours duquel il a l’opportunité de mettre en application ce qu’il a appris pendant les 2 ans de formation. Ce stage pratique permet ainsi une première approche du monde du travail, et fait prendre conscience aux étudiants de l’utilité du savoir qu’ils ont acquis. De cette manière, chaque étudiant est amené à travailler sur un problème ou un sujet concret, où un réel besoin est exprimé.

Le stage présenté s’articule autour de SURGE (Solidarité Urbain-Rural en Gestion de l’Eau), un projet de recherche pluridisciplinaire qui s’intéresse aux interdépendances liées à l’eau entre mondes urbains et ruraux. L’une de ces études de cas s’intéresse au suivi et à l’accompagnement de la phase « tendance et scénario » du Schéma d’Aménagement et de Gestion des Eaux (SAGE) du bassin de Thau (Hérault). Plus particulièrement, un modèle de type Systèmes Dynamiques est en cours d’élaboration à partir de réflexions et de prospections avec les membres du groupe de travail « tendance et scenarios du SAGE ». Cette étude est le fruit d’une collaboration entre l’unité mixte de recherche (UMR) TETIS et l’UMR G-EAU, situées à Montpellier.

Au cours de l’élaboration du modèle, les chercheurs ont besoin d’avoir accès à un certain nombre de données hydrologiques et socio-économiques afin de pouvoir simuler un certain nombre de scénarios définis au préalable. C’est de ce besoin qu’est né le stage : Offrir aux chercheurs la possibilité d’organiser et de manipuler les données récupérées afin de les aider au mieux dans la mise en place de simulations de scénarios, et d’assurer ainsi l’interopérabilité entre les différents logiciels utilisés.

Ce rapport est structuré de manière originale. Si la première et la deuxième partie présentent respectivement le contexte professionnel, et les objectifs et spécifications, il a semblé plus pertinent de regrouper les étapes de conception et réalisation sous chaque fonctionnalité importante développée. De ce fait, les chapitres suivants décrivent en détail les trois cas d’utilisations les plus importants, la manière dont ils ont été pensés, conçus, développés et

CemOA

: archive

ouverte

d'Irstea

Partie I.

Présentation du contexte professionnel

I.1 Présentation de l’organisme d’accueil

Le stage a été réalisé dans un contexte d’étroite collaboration entre deux Unités Mixtes de Recherche, impliquant deux établissements de tutelle.

Les établissements de tutelle :

AgroParisTech

AgroParisTech est un établissement public à caractère scientifique, culturel et professionnel et est sous la tutelle du Ministère de l’Agriculture et de la Pêche. Considéré comme un établissement supérieur « leader » dans les sciences du vivant, il assure deux missions principales : la formation d’ingénieurs, et la production et la diffusion de connaissances (recherche et développement) en partenariat avec les grands organismes de recherche et les principaux centres techniques professionnels.

L’établissement est constitué de 2000 étudiants, 230 enseignants-chercheurs et 450 chercheurs associés. Il contient 5 départements de formation et de recherche différents. Le centre de Montpellier a comme domaines d’activité :

- Les eaux continentales : ressources, usages et services de l’eau, gestion des territoires de l’eau, gestion et développement des services urbains d’eau potable et d’assainissement

- La gestion environnementale des écosystèmes et forêts tropicales - L’information Géographique pour le Territoire et l’Environnement

Enfin, AgroParisTech comprend 29 unités mixtes de recherche, dont l’UMR TETIS et l’UMR G-EAU.

Cemagref

Le Cemagref ou institut de recherche en sciences et technologies de l'environnement (et originellement CEntre national du Machinisme Agricole, du Génie Rural, des Eaux et des Forêts) est aujourd'hui un organisme de recherche finalisée sur la gestion des eaux et des territoires, après avoir été chargé de développer le machinisme agricole et le génie rural et sylvicole. Il a le statut d’un Etablissement Public à caractère Scientifique est et Technologique (EPST). Cet institut de recherche comporte 9 centres en France métropolitaine et un sur l’île de la Martinique. CemOA : archive ouverte d'Irstea / Cemagref

Placé sous la double tutelle des ministères en charge de la recherche et de l'agriculture, le CEMAGREF compte actuellement 20 Unités de Recherche propres (UR), 5 Unités Mixtes de Recherche (UMR) et une Equipe de Recherche Technologique (ERT). Chaque UR est placée sous la responsabilité fonctionnelle de l’un des chefs de département ou de la direction scientifique (pour le Laboratoire d’Ingénierie des Systèmes Complexes), et sous la responsabilité hiérarchique du directeur régional. Les unités sont des lieux de gestion des compétences et des pôles relationnels locaux. Chacune des UR est constituée d’équipes bien identifiées, chaque équipe assurant la mise en œuvre totale ou partielle d’un thème de recherche.

Dans ce cadre, les équipes pluridisciplinaires de chercheurs et d'ingénieurs travaillent sur l'adaptation au changement global, associant les sciences expérimentales, les sciences économiques et sociales et la science informatique (modélisation, intégration de données). Les principaux domaines de recherche sont donc :

- Risques environnementaux : crues, inondations, avalanches, feux de forêt, pollutions diffuses,

- Surveillance des milieux aquatiques continentaux : ressources en eau, usages de l'eau,

- Technologies propres : écotechnologies, éco-évaluation, écotoxicologie, traitement et valorisation énergétique des déchets organiques,

- Aménagement du territoire,

- Economie et sociologie de l'environnement

- Observatoire de la biodiversité, télédétection, trames verte et bleue.

Les Unités de Recherche : UMR-TETIS

L’UMR «Territoires, environnement, télédétection et information spatiale» (Cemagref - CIRAD - ENGREF) est implantée à Montpellier et constitue un pôle de recherche appliquée de dimension européenne en approches spatiales, télédétection et information géographique pour l’environnement, l’agriculture et les territoires.

L’UMR favorise 4 axes de recherche principaux :

CemOA

: archive

ouverte

d'Irstea

UMR-GEAU

L’UMR G-EAU existe depuis le 1er janvier 2005, après validation par une commission de la Direction Générale de l’Enseignement et de la Recherche du Ministère en charge de l’agriculture et par les conseils et les comités scientifiques des 4 institutions partenaires que sont l’ENGREF, le CEMAGREF, le CIRAD et l’IRD. Cet UMR G-EAU regroupe donc 4 UR, une pour chacune des institutions partenaires. Ce regroupement formalise un partenariat lancé en 1998 par le CEMAGREF, le CIRAD et l’IRD sur un Programme de Coordination de leurs recherches sur les Systèmes Irrigués (PCSI) pour mieux répondre aux défis posés par la gestion de l’eau dans les bassins versants irrigués. Depuis le 1er janvier 2007, deux équipes du CIHEAM-IAMM et Montpellier SupAgro ont rejoint l'UMR G-EAU.

Les activités de recherche de l’UMR G-EAU sont structurées en trois axes : - axe 1 : Eaux - territoires - institutions,

- axe 2 : Outils de gestion et de pilotage des services d'eau,

- axe 3 : Pratiques et usages agricoles de l'eau.

CemOA

: archive

ouverte

d'Irstea

I.2 Cadre général de travail

Le stage s’est donc effectué au sein de l’UMR G-EAU, au CEMAGREF, sous la responsabilité conjointe de Géraldine ABRAMI, ingénieur de recherche Cemagref rattachée à G-EAU, et de Flavie CERNESSON, maître de conférences AgroParisTech rattachée à l’UMR TETIS. Le travail était individuel et effectué sur un poste informatique du centre, dans le bureau des stagiaires.

I.3 Présentation du sujet

Sujet de l’offre

Dans le cadre du projet SURGE au niveau du bassin de Thau, les chercheurs sont amenés à construire un modèle système dynamique pour simuler des scénarios et obtenir des tendances et des prévisions dues à l’évolution de facteurs clés. Il était ainsi nécessaire pour faire tourner le modèle de disposer de données facilement accessibles. En outre, un besoin plus « durable » était de construire un module facilitant l’accès aux données et l’interopérabilité entre les différents logiciels utilisés.

Ainsi, le besoin fort pour les chercheurs d’obtenir un système de gestion de données leur permettant de centraliser et d’organiser les informations nécessaires à la simulation de scénarios les a conduits à mettre en place le stage. L’offre de stage proposée portait alors plutôt sur le tri et l’acquisition de données existantes, ainsi que sur l’élaboration et la mise en place d’une base de données centralisant les informations recueillies. Cependant, afin d’assurer l’adéquation du stage avec le cahier des charges de l’IUT, et parce que les chercheurs avaient du retard dans la spécification des données dont ils avaient besoin, aussi bien que dans la construction du modèle en lui-même, le sujet du stage a été adapté.

Sujet du stage : CemOA : archive ouverte d'Irstea / Cemagref

II.4 Planning

Un retro-planning précis a été mis en place en début de stage pour assurer la finalisation du projet, et la remise du rapport dans les temps. Il s’articulait de la manière suivante :

- semaine 1 (28 juin - 2 juillet) : prise de contact et exploration des différents composants logiciels. Identification des possibilités techniques de connexion.

- semaines 2-3 : analyse des besoins et spécification du cahier des charges : spécification de la base, spécification des connexions entre les différents outils

- semaines 4-7 : développement logiciel.

- semaines 8-10 (30 août – 3 septembre) : rédaction du mémoire et préparation de la soutenance, rédaction des guides pour les utilisateurs, transfert (formation) et déploiement des outils logiciel sur les postes.

CemOA

: archive

ouverte

d'Irstea

PARTIE II : Objectifs et spécifications

II.1 Objectif

L’objectif du stage était d’améliorer le travail des chercheurs dans leur travail de modélisation et de simulation de flux au sein d’un projet particulier. L’enjeu était ainsi de construire un module permettant de regrouper les multitudes de données éparpillées dans une base de données unique et d’assurer une interface entre cette base et un logiciel particulier utilisé par les chercheurs. Après une première phase d’analyse des logiciels et des besoins, des enjeux plus spécifiques ont été dégagés. Il s’agissait notamment :

- D’offrir une possibilité d’interaction avec un logiciel de statistiques spécifique permettant de faire des opérations plus « poussées » sur les données.

- De mettre en place une interface avec des données spatialisées de type SIG (système d’information géographique). Cette fonctionnalité a été abandonnée faute de temps.

- De permettre la mise en place d’une analyse de sensibilité, suite à l’inclusion d’une stagiaire travaillant sur un autre projet mais avec les mêmes logiciels.

Les logiciels concernés étaient :

- le logiciel de modélisation de systèmes et de simulation de flux Stella (iSee systems) - le logiciel d’analyses statistiques R (CRAN)

- le SIG ArcGis

- le logiciel tableur Excel

CemOA

: archive

ouverte

d'Irstea

II.2 Specification des exigences

Le sujet du stage était relativement ouvert mais reposait sur une contrainte forte : la nécessité d’avoir fini le projet au terme des deux mois et demi. Le projet contenait ainsi à la fois la conception et la réalisation du module. L’enjeu des données spatialisées ayant été mis de côté, on peut identifier 3 composantes au module :

Gestion de la base

La base n’existant pas encore, il fallait offrir à l’utilisateur néophyte un moyen simple d’entrer les données de manière efficace, et de lui ouvrir un large choix d’options concernant la maintenance et la modulation de la base. De cette manière, le module devait contenir toutes les opérations basiques concernant la gestion d’une base de données. Dans le cas où une base de données structurée serait mise en place ultérieurement, une fonctionnalité permettant d’entrer directement une requête devait être offerte.

Interactions avec le logiciel R

Le module devait pouvoir faire interagir les données avec le logiciel de statistiques R : l’utilisateur devait avoir la possibilité d’entrer ses propres algorithmes R pour agréger les données. Le module devait par ailleurs pouvoir permettre de sortir les données sous un format utilisable par Stella.

Analyse de sensibilité

Le module devait enfin contenir une fonctionnalité permettant d’effectuer une analyse de sensibilité (voir Partie VI : Analyse de sensibilité) : faire tourner en boucle le modèle sur un grand nombre de données.

A partir de toutes ces informations plusieurs cas d’utilisations, regroupés en sous-parties, ont été répertoriés (figure 1) :

CemOA

: archive

ouverte

d'Irstea

Figure 1 : schéma des cas d’utilisation CemOA : archive ouverte d'Irstea / Cemagref

II.3 Etude des logiciels

Une partie du projet a été d’étudier la manière dont les logiciels à mettre en commun fonctionnaient.

Présentation de Stella

Stella est un logiciel propriétaire de modélisation et de simulation de flux. Il permet au travers d’un système de « conteneurs » et de « flux », de modéliser un système complexe selon le formalisme des systèmes dynamiques et de simuler différents scénarios appliqués à ce système pour effectuer des prévisions à différents pas de temps. Uilisé à la base pour concevoir et simuler les dynamiques de systèmes industriels, ses champs d’application se sont étendus notamment à la gestion des ressources naturelles.

Figure 2 : capture d’écran du logiciel Stella

La figure 2 montre un exemple de système développé à partir de Stella. Les valeurs des

CemOA

: archive

ouverte

d'Irstea

Importation des données sous Stella

Stella dispose d’une fonctionnalité pour créer un « lien dynamique » avec Excel. De cette manière, Stella importe des données depuis un classeur Excel et les attribue à des variables « en entrée ». Pour modifier des valeurs de variables sous Stella, il suffit ensuite de modifier les valeurs directement sous Excel. Cette importation de données joue un rôle très important dans l’analyse de sensibilité (voir : Partie V : Analyse de sensibilité).

Figure 3 : correspondance Stella – Excel

La figure 3 met en évidence la correspondance « variable sous Stella » et « cellule d’Excel ». CemOA : archive ouverte d'Irstea / Cemagref

Présentation de R

R est un logiciel dédié à l’analyse statistique qui propose un langage de programmation propre ainsi qu’un environnement de développement. Utilisé largement dans le monde de la recherche en mathématiques et plus largement par les utilisateurs et développeurs de modèles scientifiques, il permet la manipulation et l’agrégation de données à grande échelle, la création de graphiques, aussi bien que l’exécution de petits programmes via des fichiers scripts.

Développé en tant que logiciel libre, il bénéficie de nombreuses mises à jour et packages supplémentaires qui contribuent à son amélioration. Il dispose notamment de packages « système de gestion de base de données » permettant d’effectuer des requêtes pour interroger des bases de données SQL.

Figure 4 : capture d’écran du logiciel R

La figure 4 est une capture d’écran correspondant à l’interface de R. L’image met en évidence la facilité à se procurer de nouveaux packages pour obtenir de nouvelles fonctionnalités.

CemOA

: archive

ouverte

d'Irstea

II.4 Evolutions

Après avoir testé les différentes fonctionnalités proposées par l’application, une réunion de mise au point a été mise en place pour déterminer les choses à améliorer concernant les différents cas d’utilisation. Il est apparu que la manière dont les cas d’utilisation étaient proposés à l’utilisateur avait matière à être améliorée.

Les changements proposés ne sont pas encore effectifs au moment de la rédaction du rapport, mais sont destinés à être implémentés au cours des deux dernières semaines de stage, jusqu’à la soutenance. CemOA : archive ouverte d'Irstea / Cemagref

PARTIE III : Structure globale et spécificités techniques

III.1 Structure globale

Figure 5 : Schéma global d’organisation

La figure 5 résume la manière dont est agencé le module d’interface. L’utilisateur n’interagit qu’avec lui et c’est lui qui fait l’interface entre les différents logiciels. Lors de la gestion de la base, le module interagit directement avec la base de données, effectuant les modifications demandées par l’utilisateur. De même, lors d’une consultation, le module puise directement les informations dans la base de données.

Par ailleurs, le module peut lui-même exporter les données consultées en fichier Excel. En revanche, lors de l’agrégation de données, le module écrit un petit programme qui sera exécuté par R. Celui-ci récupère alors les données, les agrège, puis les exporte en fichier texte, csv, Excel, ou dans la base de données.

Enfin lors de l’analyse de sensibilité (voir analyse de sensibilité), le module effectue une boucle au cours de laquelle il récupère des données à partir de fichiers Excel, ou de tables de la base, et fait tourner Stella avec comme paramètres les données en entrée récupérées. Les données en sortie que calcule Stella sont ensuite exportées en fichier Excel et pourront être

CemOA

: archive

ouverte

d'Irstea

III.2 Choix techniques

Le langage du module

Le choix de la technologie utilisée était libre. S’agissant d’une application amenée à interagir avec une base de donnée, et à faire essentiellement du traitement de fichiers, le choix d’une application XHTML/CSS/PHP s’est imposé naturellement, avec un avantage considérable sur les autres langages : la portabilité extrême dans le cas où l’application serait hébergée sur un serveur local. Un navigateur web suffit alors pour utiliser l’application. Enfin, mon peu de connaissances de ce langage m’a encouragé à en apprendre les subtilités.

Le langage de la base

Le choix de la base a été le langage MySQL, de part sa très forte compatibilité avec PHP, sa popularité et sa simplicité. Bien qu’une base access aurait été plus adaptée à des utilisateurs non-inités, le module développé assurait une interface simple dans la gestion de la base de données.

Le langage système

Le module étant amené à faire intervenir plusieurs logiciels présents sur le même poste informatique, quelques scripts de commandes windows ont du être développés.

CemOA

: archive

ouverte

d'Irstea

III.3 Navigation

Figure 6 : Schéma de navigation

Comme le montre la figure 6, chacune des grandes fonctionnalités est accessible à partir de l’accueil. La consultation a été volontairement séparée de la gestion pure de la base de données, puisqu’elle n’a pas du tout les même finalités : il s’agit d’effectuer un travail de recherche, opposé à l’administration pure et simple de la base. Il est intéressant de noter que c’est à partir de cette consultation qu’un certain nombre de fonctionnalités sont disponibles. En effet, il faut garder à l’esprit que l’exécution d’un programme de R se fait toujours en fonction, et au niveau des données que l’on a extraites de la base. La gestion des scripts .R est accessible de la même manière que la gestion de la base. Enfin, de part ses spécificités et son utilisation délicate, l’analyse de sensibilité a été séparée du reste des fonctionnalités.

III.4 Interface graphique

CemOA

: archive

ouverte

d'Irstea

une certaine légereté à l’utilisateur.Les données affichées à l’écran sont dès que possibles insérées dans des tableaux pour structurer l’affichage et rendre la lecture plus facile. Enfin, quelques images ont été réalisées, par pur esthetisme.

Figure 7 : Capture d'écran de l'accueil

CemOA

: archive

ouverte

d'Irstea

Partie IV : Gestion et consultation de la base

IV.1 Objectifs

Le module étant amené à interagir avec une base de données destinée à évoluer, il était nécessaire d’offrir à l’utilisateur un certain nombre de fonctionnalités « simplifiées » permettant de moduler la base. La volonté de disposer d’un outil unique a grandement influé sur la mise en place de cette gestion de la base, plutôt que de compter sur une application d’administration de base de données telle que phpmyadmin ou easyphp, utilisables en parallèle avec le module développé.

Par ailleurs, les données « échantillons » récupérées et destinées à être intégrées à la base étaient structurées en tableurs Excel, et ne semblaient pas avoir de liens « direct » entre elles. La base semblait ainsi se prédestiner à être une juxtaposition de tables non structurées, et c’est en gardant à l’esprit cet élément que les fonctionnalités ont été mises en place.

IV.2 Spécification des fonctionnalités

Gestion des tables

La gestion des tables propose tout d’abord les fonctionnalités classiques propres aux systèmes d’administration de base de données telles que phpmyadmin, easyphp. On y retrouve ainsi la création, la mise à jour et la suppression de tables, en proposant à l’utilisateur un cheminement guidé et étape par étape.

Les tables n’étant, à priori pas amenées à être confrontées entre elles (voir (1)), la gestion de la structure interne de la base (clés primaires, étrangères) a dans un premier temps été mise de côté, pour simplifier grandement l’administration et l’utilisation de la base de données. Cependant, le code a été aménagé de sorte à pouvoir fonctionner dans le cas où une base structurée serait mise en place ultérieurement.

Cette grande simplification de la base de données a donné naissance à une nouvelle fonctionnalité : l’importation de données structurées Excel. L’utilisateur peut ainsi, s’il dispose de données structurées selon le format adéquat, entrer d’un seul coup toutes les données dont il dispose. Le module demande alors à l’utilisateur de sélectionner un fichier, qui sera ensuite parcouru et analysé pour déterminer les noms des attributs et leur type, et créer une table dont le contenu sera introduit au fur-et-à-mesure que le module parcourt le fichier. CemOA : archive ouverte d'Irstea / Cemagref

Gestion des valeurs

De la même manière que pour la gestion des tables, la gestion des valeurs propose les fonctionnalités classiques d’un système d’administration de base de données. Comme précédemment, l’ajout, la modification et la suppression de lignes de valeurs (n-upplets) est simplifiée au maximum pour offrir à l’utilisateur non-initié un moyen efficace d’administrer sa base de données.

Consultation de la base

C’est l’une des principales fonctionnalités du module. L’utilisateur doit pouvoir extraire les informations précises qu’il désire. Un cheminement pas-à-pas permet de le guider dans sa consultation, avec l’ajout de conditions et de possibilité de tris.

Cette consultation débouche sur deux fonctionnalités importantes : l’agrégation des données extraites via R, et l’exportation de ces données dans un autre fichier, pouvant éventuellement être réintégré à la base (insertion automatique d’une table), afin de disposer d’une table plus précise et plus axée sur le besoin du moment.

IV.3 Conception

Guidage de l’utilisateur

Les informations saisies par l’utilisateur sont dès que possibles suggérées par le module par le biais de listes déroulantes, afin d’éviter le plus possible les erreurs dues aux fautes de frappe. Une seconde base de données dite « utilitaire » a été mise en place dans ce sens. Elle contient notamment les types disponibles pour la création et la mise à jour de table et les opérateurs de comparaison disponibles lors de la mise en place de conditions pour une requête de consultation.

De cette manière, chaque fois que l’utilisateur doit entrer une information technique, il doit choisir celle-ci dans une liste que le module remplit en puisant les informations requises dans la base de données utilitaire.

CemOA

: archive

ouverte

d'Irstea

IV.4 Réalisation

Le codage de cette partie du projet n’a pas rencontré de problème particulier. La manière d’organiser les fonctionnalités a été la même pour chaque cas d’utilisation de manière à assurer une certaine logique de l’application. Chaque page xhtml développée correspond ainsi à un cas d’utilisation.

IV.5 Tests et évolutions

Réorganisation des cas d’utilisation

Il est apparu que dans certains cas, centraliser les différents cas d’utilisation offrait à l’utilisateur une meilleure compréhension dans sa manière de manipuler l’application. En outre, certains cas d’utilisations intimement liés pouvaient être fusionnés, afin que l’utilisateur s’y retrouve mieux dans une liste de fonctionnalités plus concise et claire. Enfin, quelques fonctionnalités en plus étaient nécessaires pour assurer une certaine cohérence du module. De cette manière, les cas d’utilisation concernant la gestion des valeurs avaient matière à être regroupés en une seule fonctionnalité : « modifier le contenu d’une table ». Par ailleurs, cette fonctionnalité découlait directement de la gestion de la base.

Nouvelle liste des cas d’utilisation

La gestion de la base comprendrait alors ainsi les fonctionnalités suivantes : - Ajouter une table

- Supprimer une table

- Modifier la structure d’une table - Modifier le contenu d’une table

Le cas d’utilisation « modifier le contenu d’une table » regrouperait alors en une seule fonctionnalité l’ajout, la modification, et la suppression de ligne de valeurs. La fonctionnalité « Modifier la structure d’une table » permettrait quant à elle d’ajouter, de supprimer, et de modifier les attributs de la table.

CemOA

: archive

ouverte

d'Irstea

Par ailleurs, le cas d’utilisation « Consulter la base » inclurait deux nouvelles fonctionnalités : - Remplacer la table : Permettre à l’utilisateur de remplacer la table complète par celle issue de la consultation, restreignant ainsi la table aux valeurs les plus pertinentes.

- Créer une nouvelle table : Offrir à l’utilisateur la possibilité de créer automatiquement la table issue de la consultation comme une nouvelle table à part entière.

Plus d’informations sur le contenu

L’actuelle disposition du module est particulièrement déroutante au premier abord. En effet l’absence de fenêtres d’aides et d’informations sur le contenu de la base porte préjudice à la clarté et la facilité d’utilisation du module.

De ce fait, un remaniement des cas d’utilisation en incluant systématiquement un affichage du contenu manipulé a été décidé. Il permettrait notamment un aperçu du contenu de la base choisie lors des opérations de gestion des tables (par exemple on a un aperçu de la table qu’on s’apprête à supprimer). CemOA : archive ouverte d'Irstea / Cemagref

Partie V : Interactions avec R

V.1 Introduction

La récupération d’un grand nombre de données brutes et difficilement utilisables directement a conduit à la volonté de disposer d’un outil puissant pour pouvoir agréger et synthétiser les données et ainsi ressortir des résultats clairs et parlants. Le choix de cet outil mathématique plus qu’un autre s’est imposé de par son utilisation par les chercheurs du centre, sa puissance, et l’existence de packages spécialisés dans la consultation de base de données.

V.2 Les moyens d’interaction

Un travail de réflexion a été effectué sur la manière de faire interagir le module avec R. Le logiciel permet la lecture et l’exécution de petits programmes rédigés dans son langage. L’idée adoptée comme moyen d’interaction a donc été de faire générer ces programmes par le module qui demande ensuite à R de se lancer en chargeant le programme rédigé. Pour la récupération des résultats, R permet aussi une gestion efficace des fichiers. Ainsi, les résultats obtenus sont inscrits dans un fichier temporaire qui sera ensuite lu par le module, qui à son tour, affichera à l’utilisateur les résultats.

V.3 L’adaptabilité du module

Bien que les opérations effectuées sur les données récupérées sont souvent les mêmes (moyenne, écart-type, maximum, minimum…), il est possible d’avoir besoin d’algorithmes de tris ou d’opérations plus puissants ou complexes. De ce fait, l’enjeu de l’interaction avec R était d’offrir à l’utilisateur un moyen simple de créer ses propres algorithmes. Enfin, quelques algorithmes de base sont malgré tout proposés afin de faciliter le travail de l’utilisateur et de lui servir d’exemple dans la manière de rédiger ces algorithmes.

V.4 Méthodes de rédaction d’un programme .R

L’écriture d’un programme .R du module s’effectue en deux temps. Comme le but de l’interaction avec R est de faire des opérations sur les données qu’on consulte, l’exécution d’un programme .R découle directement du cas d’utilisation « Consultation de la base ». Cependant, R n’a a priori aucun moyen d’avoir accès aux données qui ont été consultées au préalable. CemOA : archive ouverte d'Irstea / Cemagref

L’entête : spécifique à chaque consultation

Ainsi, le module commence la rédaction du programme par l’écriture d’un entête qui permettra à R de récupérer les données consultées au préalable. Cet entête contient deux instructions principales : d’abord le chargement d’un paquet permettant à R d’interagir avec un système de gestion de base de données (SGBD), puis la réexécution de la requête SQL effectuée par le module ; requête qui, une fois construite, a été gardée en mémoire et introduite dans l’entête du programme.

Le logiciel R ré-exécute ainsi la requête et se retrouve en possession des données consultées, prêt à les agréger.

Le corps du programme : réutilisable

Le corps du programme est constitué d’un algorithme qui va agréger les données. L’algorithme pouvant être généralisé à n’importe quel type de données et pas seulement à celles consultées (c’est toujours la même méthode pour calculer une moyenne, un écart-type etc…), il semblait dommage de ne pas proposer un moyen pour réutiliser chaque algorithme. Un système de gestion des programmes .R a donc été mis en place (cas d’utilisation : créer un script .R, supprimer un script .R). L’utilisateur dispose ainsi d’une fonctionnalité pour créer un fichier ‘.R’ qui contiendra un algorithme « général ». Le fichier est inséré dans la base « utilitaire », et peut être à tout moment supprimé par la fonctionnalité «Supprimer un script .R». CemOA : archive ouverte d'Irstea / Cemagref

V.5 L’exécution d’un programme .R

Après avoir effectué une consultation, l’utilisateur peut choisir d’agréger les données qu’il a récupérées. L’entête du programme est alors généré à partir de la requête effectuée précédemment. L’utilisateur choisit ensuite l’algorithme qu’il désire dans une liste alimentée par la base de données « utilitaire ».

Le module fusionne alors l’entête et le corps du programme ’.R’ dans un fichier temporaire et lance un script batch relativement simple demandant à R de s’ouvrir et d’exécuter le programme.

V.6 Réalisation de l’interaction avec R

L’exemple de R-PHP

Un module permettant de lier R et PHP existait déjà. En réalité, il s’agissait seulement d’une page web avec un texte à saisir. L’utilisateur écrivait des instructions .R que PHP décortiquait. Une fois la syntaxe vérifiée, PHP faisait s’exécuter le programme avec un logiciel R installé sur le même server que la page web et retournait le résultat à l’utilisateur. Même si ce module ne permettait pas l’interaction avec une base de données l’étude de son fonctionnement a permis de déterminer la méthode pour créer l’interaction.

Le codage

Le codage de cette partie du projet n’a pas été le plus long. C’est en effet la conception, avec une phase de test et de recherche de documentations conséquentes, qui a pris le plus temps.

Les problèmes

Outre les erreurs de codages, quelques problèmes dus à la correspondance entre certains caractères depuis le module vers R sont devenus récurrents. Le passage de chaînes de caractères contenant notamment des guillemets (« ») était mal interprété par R, ce qui produisait des erreurs quant à la récupération des données de la base lors d’une consultation (on rappelle que le module construit les requêtes SQL et les transmet à R, sous la forme de chaînes de caractères, voir Parties V.3 et V.4).

CemOA

: archive

ouverte

d'Irstea

CemOA

: archive

ouverte

d'Irstea

V.7 Les modifications envisagées

Après discussion, il est apparu intéressant d’avoir la possibilité d’intégrer les résultats des opérations directement au sein de la base de données, dans le cas ou des programmes contenant des algorithmes de tris statistiques précis seraient mis en place.

Par ailleurs, pouvoir consulter le contenu des programmes R existants pour aider l’utilisateur dans sa propre rédaction d’algorithme était un point important à développer. Enfin, avoir un affichage de quelques lignes de description sans ouvrir le script semblait être nécessaire.

CemOA

: archive

ouverte

d'Irstea

Partie VI : Analyse de sensibilité

VI.1 Introduction

L’analyse de sensibilité est un processus par lequel on évalue le comportement d’un modèle en observant comment les résultats de l’analyse varient en fonction de variables clés lorsque celles-ci sont modifiées dans un intervalle donné. Ce processus consiste donc à répéter un grand nombre de fois un scénario en changeant les valeurs des variables à l’entrée. Les resultats en sortie sont ensuite soumis à des analyses afin de comprendre comment les différentes variables d’un modèle affectent son comportement.

Une difficulté de l’analyse de sensibilité est de générer des scénarios de combinaisons de valeurs des variables qui parcourent de manière économique l’espace de ces valeurs. On ne peut pas se contenter de regarder ce qui se passe quand on fait varier une seule variable car en général le modèle peut réagir très différement à la variation de la valeur d’une variable selon les valeurs qu’ont les autres variables. Il faut donc pouvoir regarder toutes les combinaisons générées par les différentes valeurs des variables auxquelles on s’intéresse. Mais en général cela fait beaucoup et il faut donc ne sélectionner que certaines de ces combinaisons.

Tout un champ des mathématiques appliquées travaille sur ce problème de sélectionner un nombre minimum de combinaisons pour voir un maximum de choses dans le comportement du modèle et R propose de nombreuses fonctionnalités pour cela.

Au niveau du projet, l’analyse de sensibilité consiste ainsi à faire tourner plusieurs fois le modèle Stella développé par les chercheurs, et à récupérer les données résultats dans un tableur pour ensuite générer des tendances.

V.2 Travail en collaboration

Les circonstances

Ce travail de réflexion a été effectué en collaboration avec une stagiaire travaillant sur Stella pour un autre projet, et désireuse d’effectuer elle-aussi une analyse de sensibilité sur

CemOA

: archive

ouverte

d'Irstea

installer de paquets supplémentaires), le langage VisualBasic correspondait en effet parfaitement au besoin du moment.

La réalisation de la version prototype

Disposant ainsi de modèles concrets, fonctionnels et finalisés, il n’a pas été difficile de mettre en place la bonne méthode pour réaliser une analyse de sensibilité ponctuelle sur son propre projet.

En tout 5 jours ont été nécessaires pour dégager les spécifications, découvrir le langage, rédiger le programme, le tester , et corriger les erreurs et la mise en forme des résultats en sortie. Il ne restait ainsi plus qu’à adapter la méthode au module.

VI.3 Conception : méthode globale mise en oeuvre

Les données en entrée

Stella permet la création de liens dynamiques avec des fichiers données en entrée et des fichiers résultats en sortie. Cependant, le logiciel n’offre aucune fonctionnalité pour automatiser la modification des valeurs du fichier de données en entrée. La « pirouette » a ainsi été de considérer le fichier disposant du lien dynamique en entrée comme un fichier temporaire, disposant d’une unique ligne de valeurs qui correspond au « scénario du moment ».

Figure 9

De ce fait, comme le montre la figure 5, le module puise, pour chaque scénario à simuler, une

CemOA

: archive

ouverte

d'Irstea

CemOA

: archive

ouverte

d'Irstea

Les données en sortie

De la même manière que pour les fichiers en entrée, Stella peut exporter les valeurs résultat de variables, conteneurs et flux selectionnés. On a ainsi encore recourt ici à un fichier temporaire qui accueillera les resultats bruts de la simulation. Ces resultats sont ensuite traités par le module et mis en forme selon les besoins.

Un travail de réflexion a été mené pour déterminer le format le plus adéquat pour effectuer la synthèse des résultats. L’analyse de sensibilité se déroulant dans un intervalle donné (en général assez long : 6mois, 1an, avec un pas-de-temps d’1mois), il semblait intéressant de différencier deux formats de sortie différents :

- Un format : « un fichier pour chaque scénario », contenant toutes les variables résultat à tous les pas-de-temps, ce qui permet d’avoir une vue globale des conséquences de chaque scénario.

- Un format : « un fichier par variable », contenant pour chaque variable, tous les scénarios, et pour chaque scénario, les valeurs de la variable à tous les pas-de-temps. Ce format permet d’étudier l’évolution précise de chaque variable en fonction du scénario et au cours du temps.

La boucle

Une fois la gestion des entrées-sorties effectuée, il ne reste plus qu’à boucler autant de fois qu’il y a de lignes de scénario dans le fichier principal en entrée.

VI.4 Réalisation au niveau du module

L’analyse de sensibilité est un cas d’utilisation à part puisqu’il demande un certain nombre de spécificités : notamment la saisie du fichier contenant tous les scénarios, des fichiers contenant un lien dynamique « en entrée » et « en sortie » avec Stella. Les contraintes sont grandes : le fichier « scénario » doit être correctement formaté, les liens correctement réalisés.

Pour diminuer un peu la quantité astronomique d’erreurs pouvant résulter d’une mauvaise saisie de fichier, le module propose une saisie pseudo-automatique des fichiers de manière progressive. L’utilisateur choisit par ailleurs le format dans lequel il désire récupérer les données (voir IV.3 : les données en sortie).

Une fois les informations saisies, le processus s’exécute assez simplement : le module parcourt le fichier, récupère les informations en tant que chaînes de caractères, les écrit dans les fichiers adéquats, fait tourner Stella, traite et organise les données récupérées, et continue

CemOA

: archive

ouverte

d'Irstea

Les problèmes

Outre les quelques erreurs qui se sont naturellement glissé lors de l’écriture du code, quelques problèmes ont ralenti la production de cette partie du projet. Ceux-ci provenaient du logiciel Stella, lors de la création d’un lien dynamique « en entrée » (voir II.3 Importation des données sous Stella).

Alors que la création de lien dynamique fonctionnait parfaitement avec d’autres tableurs tels qu’OpenOffice Calc, celle-ci générait une erreur lorsqu’elle était réalisée à partir d’Excel, pourtant logiciel privilégié par les développeurs de Stella. Le problème était d’autant plus important que Stella tentait quand même de lancer Excel, ce qui créait des problèmes de disponibilité du fichier concerné (les logiciels tableur s’accaparent l’écriture exclusve du fichier tant qu’ils sont ouverts).

Après quelques jours de casse-tête, de recherche, et de discussion avec la stagiaire qui ne rencontrait pas ces problèmes, il est apparu que Stella utilisait les normes internationales lorsqu’il traitait les fichiers Excel. Or comme Excel est configuré selon les préférences de langue de l’ordinateur et que celles-ci sont différentes en France, il se créait un conflit entre les deux formats.

Au final il suffisait de changer les paramètres de l’ordinateur, mais cela entraîna quelques problèmes vis-àvis des fichiers Excel existants sous la norme française, l’ordinateur étant alors configuré selon la norme internationale.

VI.5 Les modifications envisagées

D’importants changements ont été décidés dans le déroulement de la saisie des informations nécessaires à l’analyse de sensibilité (voir VI.4). Une approche plus légère et instinctive pour l’utilisateur a en effet été adoptée.

Plutôt que de saisir l’emplacement de chaque fichier spécifique un par un, l’utilisateur indique l’endroit où est situé le fichier contenant tous les scénarios. Le module génère alors un fichier temporaire à partir de celui saisi, lance Stella, et invite l’utilisateur à créer le lien dynamique entre le modèle Stella et le fichier temporaire fraichement crée.

Cette approche plus instinctive permet en outre la meilleure compréhension du

CemOA

: archive

ouverte

d'Irstea

Conclusion

Dans l’ensemble le stage a été une bonne expérience. La principale difficulté a été de développer une application sans avoir de données et de modèles concrets pour la tester. En effet, les chercheurs travaillant sur plusieurs projets à la fois, avaient du mal à avancer le modèle et arriver à dégager les besoins réels. Le travail collaboratif effectué lors de l’analyse de sensibilité a ainsi été doublement bénéfique. Non seulement il m’a donné une première approche du travail en équipe, mais il m’a aussi permis de travailler sur des données concrêtes, que j’ai continué à utiliser en test pour mon propre module. Par ailleurs, le timing serré dû au retard du stage (commencé le 28juin, et terminé le jour de la soutenance) a posé quelques soucis de cohérence avec la rédaction du présent rapport, la partie réalisation n’ayant pas encore été finalisée.

Cependant, la possibilité de travailler sur un projet informatique pendant une longue période, et d’aborder en détail les différentes parties du processus de création d’une application (de la conception au test et au débogage) a été une première expérience professionnelle enrichissante. Enfin, l’environnement de travail était particulièrement agréable, que ce soit au niveau de la restauration, des stagiaires présents dans le bureau ou des chercheurs et du personnel du centre.

Le développement de chacune des parties a été intéressante, et a nécessité une certaine réflexion, ce qui a ajouté un peu de plaisir à la réalisation (voir que ce qu’on a imaginé est applicable et fonctionne).

Concernant la gestion de la base de données, celle-ci reste malgré tout basique et nécessiterait d’être développée plus en profondeur. L’ajout de petites fonctionnalités facilitant encore plus l’usage à l’utilisateur serait ainsi appréciable. Néanmoins la liste des améliorations effectuées après la phase de test a déjà contribué à rendre l’interface plus ergonomique.

Pour la partie interaction avec R, la manière de rédiger les scripts « en fonction » des données qu’on consulte rend la tâche assez ardue. Un travail colossal mais appréciable aurait pu être d’intégrer littéralement l’environnement au module, plutôt que de jouer sur les entrées sorties et la gestion de fichiers.

Enfin pour l’analyse de sensibilité, le fait de devoir forcer l’utilisateur à créer lui-même les liens dynamiques entre le fichier et le logiciel Stella complique inutilement le procédé. Le rêve aurait été de pouvoir modifier le code du logiciel propriétaire et d’automatiser cette création de liens. Malgré tout, la manière dont sera agencé le module après ajout des améliorations devrait pallier un minimum à cette contrainte.

Au final, c’est surtout le manque de temps qui aura été la principale difficulté. Outre l’abandon de l’intégration des données spatialisées, tout le travail d’acquisition et d’intégration des données « réelles » a du être mis de côté. Enfin, l’optimisation du code est quelque chose que j’aurais vraiment aimé pouvoir réaliser.

CemOA

: archive

ouverte

d'Irstea

Annexes

Captures d’écran des différents menus :

CemOA

: archive

ouverte

d'Irstea

CemOA

: archive

ouverte

d'Irstea

CemOA

: archive

ouverte

d'Irstea

CemOA

: archive

ouverte

d'Irstea

Capture d’écran des différentes lignes de paramètres à l’entrée et d’extraits de résultats en sortie : CemOA : archive ouverte d'Irstea / Cemagref

Capture d’écran de la table « Utilitaire » : CemOA : archive ouverte d'Irstea / Cemagref

Capture d’écran des fichiers résultats d’une analyse de sensibilité : CemOA : archive ouverte d'Irstea / Cemagref

Résumé :

Dans le cadre du projet SURGE (Solidarité Urbain-Rural en Gestion de l’Eau), une étude, menée par les unités mixtes de recherche TETIS et G-Eau, s’intéresse à la construction de modèles type système dynamique permettant de prévoir l’évolution du bassin de Thau (Hérault) selon les variations d’un certain nombre de facteurs clés. De telles simulations nécessitant une certaine quantité de données, la mission était donc de développer un outil permettant d’interagir facilement avec ces données, de les manipuler, et de les mettre en relation avec différents logiciels; afin de faciliter le travail des chercheurs.

Mots clés :

Base de données, interfaçage, logiciel de simulation, système dynamique.

Abstract :

Under SURGE project (Solidarité Urbain-Rural en Gestion de l’Eau), a research, led by the UMR (unite mixte de recherche) TETIS and G-Eau, is about the build of dynamic dystem model, which permit to anticipate the change of the Basin of Thau (Hérault, France) according to the variation of a big number of key-factors. As such simulations need a lot of data, the assignment was to develop a tool which would permit to interact with those data, and to manipulate them, and to connect them with some different software; in order to make the work of the researchers easier.

Keywords :

Data bases, interface, simulation software, dynamic system.

CemOA

: archive

ouverte

d'Irstea