Modélisation et développement d'une base de données centralisée dans le cadre du projet EnergéTIC

HAL Id: hal-02594307

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

Submitted on 15 May 2020

HAL 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.

Modélisation et développement d’une base de données

centralisée dans le cadre du projet EnergéTIC

A. Taib

To cite this version:

A. Taib. Modélisation et développement d’une base de données centralisée dans le cadre du projet EnergéTIC. Sciences de l’environnement. 2010. �hal-02594307�

Université Blaise Pascal Clermont-Ferrand II

Département de Mathématiques et Informatiques

Rapport de stage

1

_{année Master professionnel}

Stratégie Internet et Pilotage de Projets en Entreprise

Modélisation et développement d'une

base de données centralisée dans le

cadre du projet EnergéTIC

Réalisé par : Amine taïb Maîtres de stage : Géraldine andré

Jean-Claude champomier CemOA : archive ouverte d'Irstea / Cemagref

Remerciements

Je tiens tout d'abord à remercier mes maîtres de stage Jean-Claude champomier et Géraldine andré, pour m'avoir intégré rapidement au sein de l'entreprise et m'avoir accordé toute leur conance ; pour le temps qu'ils m'ont consacré tout au long de cette période, sachant répondre à toutes mes interrogations ; sans oublier leur participation au cheminement de ce rapport.

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance à mes collègues stagiaires ainsi que tout le personnel du Cemagref de Montoldre, pour l'expérience enrichissante et pleine d'intérêt qu'ils m'ont faite vivre durant ces quatorze semaines au sein de l'organisme.

CemOA

: archive

ouverte

d'Irstea

Table des matières

1.4 Présentation du site des Palaquins . . . 6

2 Le projet EnergéTIC 9 2.1 Présentation . . . 9

2.2 Cahier des charges . . . 12

3 Implémentation 14 3.1 Choix des technologies . . . 14

3.1.1 Modélisation . . . 14 3.1.2 Interface de saisie . . . 15 3.1.3 Serveur . . . 15 3.2 Base de données . . . 15 3.2.1 Modélisation . . . 15 3.2.2 Structure . . . 16 3.2.3 Réalisation . . . 18 3.3 Interface . . . 19 3.3.1 Administration . . . 21 3.3.2 Interface de saisie . . . 25 Conclusion . . . 30 CemOA : archive ouverte d'Irstea / Cemagref

Table des gures

1.1 Répartition des eectifs du Cemagref . . . 6

1.2 Le site de Montoldre . . . 7

1.3 Carte d'identité du Cemagref . . . 8

2.1 Calendrier du projet . . . 10

2.2 Carte des sites pilotes . . . 11

2.3 Principe de mise en ÷uvre du projet . . . 11

3.1 Modèle conceptuel de données simplié . . . 17

3.2 Extrait de la classe tâches . . . 19

3.3 Page d'identication . . . 20

3.4 Code d'ajout des tables dans l'interface d'administration . . . 21

3.5 Page d'accueil de la page d'administration . . . 21

3.6 Liste des utilisateurs dans la page d'administration . . . 22

3.7 Fenêtre secondaire d'ajout . . . 23

3.8 Page d'ajout/modication d'une tâche . . . 24

3.9 Onglet d'ajout des outils de mesure intégré dans la page d'ajout des travaux . . . 25

3.10 Page d'accueil de l'interface des utilisateurs . . . 26

3.11 Page contenant le forumlaire de saisie relié la table travail . . . 27

3.12 Page achant des erreurs suite à une saisie erronée . . . 29

CemOA

: archive

ouverte

d'Irstea

Liste des abréviations

CASDAR Compte d'Aectation Spécial pour le Développement Agricole et Rural NTIC Nouvelles Technologies de l'Information et de la Communication

ACV Analyse de Cycle de Vie UML Unied Modeling Language SQL Structured Query Language AGL Atelier de Génie Logiciel

SGBD Système de Gestion de Base de Données MVC Modèle-Vue-Contrôleur

HTTP HyperText Transfer Protocol HTML HyperText Mark-Up Language CSS Cascading Style Sheets

CemOA

: archive

ouverte

d'Irstea

Résumé

L'économie des énergies non renouvelables est un enjeux majeure qui s'impose dans toutes les disciplines de production actuelles, notament l'agriculture. Ce domaine est l'un des plus consommateur en matière d'énérgie. C'est dans ce cadre que le projet EnergéTIC à été initié en association avec plusieurs partenaires dans le but d'optimiser les dépenses énergétiques.

L'organisme de recherche Cemagref , étant l'un des partenaire, contribue en dévelop-pant des technologies permettant une collecte ne des données concernant les opérations eectuées dans une exploitation agricole.

La quantité et la complexité des données collectées nécessite un support de stockage informatisé an de les centraliser pour pouvoir les exploiter d'une manière ecace.

Pour mettre en place la base de données et l'interface, les outils et langages utilisés sont : Objecteering Modeler, le framework Django, MySQL, UML et Python.

CemOA

: archive

ouverte

d'Irstea

Introduction

Le changement climatique est l'une des préoccupations planétaire les plus urgentes du 21e _{siècle. Il est devenu impératif de déterminer les facteurs qui inuencent le plus}

l'environnement, d'où l'idée de maîtriser de plus en plus les dépenses en matière d'éner-gies non renouvelables. L'utilisation de ces énerd'éner-gies est désignée comme étant des moins respectueuses envers la planète.

Le Cemagref , étant un organisme de recherche spécialisé en sciences et technologies, s'appuie sur les écotechnologies an de mieux maîtriser les dépenses énergétiques dans le domaine agricole qui est, manifestement, l'un des domaines les plus consommateur en matière d'énergie. Ainsi, contrôler l'utilisation énergétique se traduit, à court terme, par une diminution de la facture des dépenses pour une exploitation agricole et, à long terme, la préservation de l'environnement.

Dans cette optique le Cemagref , l'ACTA et quatorze partenaires ont répondu à l'appel à projet du CASDAR : le projet EnergéTIC .

Le but de ce projet est de montrer, à l'aide des NTIC, la faisabilité et l'intérêt d'une collecte, en routine, de données au niveau des opérations eectuées dans les exploitations agricoles. Une telle collecte de données permettra d'élaborer des bilans énergie/matière plus spéciques concernant les parcelles, les ateliers de production ou les opérations dans l'entreprise agricole. Un niveau de précision aussi n servira à l'alimentation des réfé-rentiels de données utilisables en ACV, l'élaboration des performances énergétiques des exploitations agricoles et l'aide à la décision opérationnelle.

Le sujet de mon stage au sein du Cemagref s'inscrit dans le cadre du projet Energé-TIC , il se focalise sur la partie concernant le stockage de données. En eet, une fois les données acquises, il faut faciliter leur exploitation en mettant en place un système permet-tant l'interaction avec les utilisateurs et facilipermet-tant le transfert des informations recueillies lors des diérentes opérations réalisées dans les exploitations agricoles. Pour cela, le sto-ckage de données passera par la conception ensuite la réalisation d'une base de données ; et le système d'acquisition par une interface de saisie. Ainsi, cette collecte de données permettra, par la suite, de concevoir un entrepôt dans lequel seront stockées les données une fois traitées à partir de celles réunies dans la base de données initiale. L'entrepôt de données servira à obtenir avec précision des indices concernant la consommation d'énergie liée aux diérents types d'opérations.

CemOA

: archive

ouverte

d'Irstea

Dans une première partie, je vais présenter le Cemagref où j'ai eectué mon stage. Ensuite, j'aborderai le contexte du projet intitulé EnergéTIC dans lequel s'inscrit mon sujet de stage. Dans une troisième partie, je détaillerai mon projet technique ainsi que le développement des diérentes composantes de la base de données. Puis, la mise en place du prototype qui va servir de plateforme de teste. Enn, je nirai par une conclusion qui portera sur les diérents apports et les connaissances acquises tout au long de mon stage autant sur le plan professionel que personnel.

CemOA

: archive

ouverte

d'Irstea

Partie 1

Présentation de l'entreprise

J'ai eectué mon stage au sein de l'équipe COPAIN  qui fait partie de l'unité de recherche TSCF  du site du Cemagref situé à Montoldre.

1.1 Le Cemagref

Crée en 1981, le Cemagref est depuis 1986 un Établissement Public á caratère Scienti-que et Technologique (EPST). Il est placé sous la double tutelle des ministères en charge de la recherche et de l'agriculture. Les équipes de chercheurs et d'ingénieurs du Cemagref travaillent sur l'adaptation au changement global, associant les sciences expérimentales, les sciences économiques et sociales et les sciences informatiques (modélisation, intégration de données). Il a pour mission de répondre à des questions concrètes de société dans dié-rents domaines an de produire des connaissances nouvelles et des innovations techniques utiles aux gestionnaires, aux décideurs et aux entreprises :

Risques environnementaux crues, inondations, avalanches, feux de forêts, pollution diuses ;

Technologies propres écotechnologie, éco-évaluation, éco-toxicologie, traitement et va-lorisation énergétique des déchets organiques ;

Aménagement du territoire ;

Économie et sociologie de l'environnement observatoire de la biodiversité, télédé-tection.

1.2 Historique

En 1981 : Le Cemagref est fondé à partir d'équipes scientiques et techniques consti-tuées par l'État dans les années 1960-1970 ;

De 1981 à 1993 : Les employés du Cemagref sont répartis en 43 divisions et une direc-tion des programmes gère la cohésion entre les diérentes activités ;

CemOA

: archive

ouverte

d'Irstea

Présentation de l'entreprise 1994 à 1997 : Premier plan stratégique qui permet de mettre en place quatre départe-ments possédant chacun un plan quadriennal. Le Cemagref (originellement Centre National du Machinisme Agricole, du Génie Rural des Eaux et des Forêts) devient l'Institut de Recherche pour l'Ingénierie de l'Agriculture et de l'Environnement. La création du département Gestion des territoires témoigne du développement d'une nouvelle thématique ;

En 1998 : Une direction scientique et une direction du développement et de l'innova-tion sont mises en place. Cette distincl'innova-tion permet une amélioral'innova-tion en terme de qualication scientique et de recherche de partenaires ;

De 1999 à 2003 Un nouveau plan stratégique modie la maille des thèmes de recherches, qui devient celle du pilotage stratégique et du suivi rapproché par les départements ; De 2004 à 2008 : Un nouveau plan stratégique est mis en place. Ce dernier s'inscrit dans une vision sur dix ans et dans une optique d'insertion européenne. Le nombre de thèmes de recherche est réduit à 27 an de resserrer les collectifs thématiques par implantations.

Chaque collectif doit xer ses objectifs à 4 ans. Un des quatre départements s'oriente résolument vers le développement des écotechnologies ;

En 2009 : L'objectif xé par l'État est clair : le Cemagref doit devenir la référence en sciences pour l'ingénierie de la gestion durable des eaux et des territoires. La nouvelle dénomination de l'établissement, Sciences, eaux et territoires , conrme cette orientation. 2009 a été la première année de la mise en ÷uvre du nouveau plan stratégique  Cemagref 2020 . Ce plan à moyen terme oriente les ambitions scientiques de l'institut sur trois grands axes : l'eau et les territoires, les risques na-turels et la qualité environnementale et apporte une cohérence dans tous les thèmes de l'institut.

1.3 Champs d'activités

Établissement public à caractère scientique et technologique, le Cemagref forme un trait d'union entre la recherche fondamentale, les pouvoirs publics et les utilisateurs (constructeurs de machines agricoles, exploitants, etc.). En eet, le Cemagref développe ses recherches et travaille en collaboration avec d'autres organismes de recherche, uni-versité, industriels et collectivités territoriales publiques, ce qui lui permet d'intégrer les réalités du terrain.

Le Cemagref s'appuie aussi sur de nombreux partenariats, qu'ils soient scientiques, publics ou socio-économiques. Il répond aux besoins exprimés par les ministères de l'agri-culture et de l'environnement ainsi qu'à ceux des collectivités locales mais il développe

CemOA

: archive

ouverte

d'Irstea

Présentation de l'entreprise également des projets avec des industriels et des bureaux d'études. Par ailleurs, l'établis-sement valorise les résultats de sa recherche auprès des entreprises en déposant des brevets (au nombre de 45 à ce jour), en créant des marques (16 sont déposées) et en élaborant des logiciels professionnels (dont 11 sont commercialisés).

Une des missions de l'organisme de recherche est aussi de développer la production et la diusion de nouvelles connaissances. Ceci passe par des publications scientiques, au rythme d'environ 400 par an (pour 2009). Enn, les enseignants-chercheurs du Cemagref dispensent des cours aux étudiants de licence, master et doctorat à hauteur de 10 % du temps annuel des ingénieurs (soit 10 000 heures d'enseignement supérieur par an en 2009). La répartition des eectifs (1600 personnes) en fonction des diérentes activités de l'établissement est représentée gure 1.1.

Figure 1.1  Répartition des eectifs du Cemagref

1.4 Présentation du site des Palaquins

Le site des Palaquins est situé à Montoldre dans le département de l'Allier (03) (à mi chemin entre Moulins et Vichy), il dépend du groupement de Clermont-Ferrand et est rattaché à l'unité de recherche  technologies et systèmes d'information pour les agrosys-tèmes (TSCF), elle-même rattachée au département écotechnologie et agrosystème. Ce site à été attribué en 1967 au CNEEMA avant de devenir en 1981 un centre de recherche du Cemagref (g. 1.3). Ce site comprend une exploitation agricole d'une supercie de 140 Ha ce qui permet de disposer du matériel nécessaire aux essais et travaux de recherches (tracteurs, outils, banc d'essai, etc.). Le site accueille 30 employés.

Les recherches portent sur les technologies de la mobilité pour la sécurité et la qua-lité du travail des machines mais aussi sur les technologies d'épandage de matériaux organiques ou minéraux. Les systèmes écologiques sont également abordés, à travers les

CemOA

: archive

ouverte

d'Irstea

Présentation de l'entreprise technologies pour la perception et la caractérisation de l'environnement. Enn, des tra-vaux ont pour objectifs d'adapter les systèmes d'informations aux besoins individuels et collectifs de gestion des entreprises agricoles et des milieux naturels, de garantir la qualité de conception et de réalisation et d'accroître la communication inter-systèmes. Un pôle de recherche sur les épandages et l'environnement (PEE) mène les recherches dans ce do-maine et facilite l'appui aux industriels en matière d'innovation ainsi que la promotion du concept d'écotechnologie de l'épandage. Ce pôle est doté d'une plate forme technologique d'expérimentation de pointe unique en Europe. L'unité de recherche TSCF est membre de la fédération de recherche TIMS  Technologies de l'Information, de la Mobilité et de la Sûreté . Cette unité de recherche regroupe trois équipes réparties sur deux sites (Clermont-Ferrand et Montoldre (g. 1.2)) :

 Systèmes d'information agri-environnementaux communicants ;

 Technologies de la mobilité pour la sécurité et la qualité du travail des machines agrienvironnementales ;

 Technologies pour la caractérisation du sol appliquées aux éco et agro-systèmes ;  Sciences-technologies et procédés d'épandage.

L'unité de recherche TSCF dirigée par Monsieur Emmanuel hugo, regroupe 51 personnes (personnels permanents) dont :

 29 chercheurs ou ingénieurs, 16 assistants ingénieurs ou techniciens, 6 administratifs ;  ainsi que : 7 doctorants, 2 post-doctorants et 15 stagiaires par an en moyenne ; L'activité de l'équipe est consacrée aux méthodes d'ingénierie des systèmes d'information spatialisés dédiés à la gestion agri-environnementale.

Figure 1.2  Le site de Montoldre

CemOA

: archive

ouverte

d'Irstea

Présentation de l'entreprise Cet ensemble de méthodes couvre l'analyse des besoins des acteurs, la spécication des systèmes d'information, leur modélisation, leur conception, leur gestion et leur lien avec les sources de données. L'objectif de l'équipe est de développer des méthodes et des techniques selon deux axes :

 Déployer et gérer des réseaux de capteurs communicants adaptés aux problèmes agrienvironnementaux ;

 Concevoir et gérer des systèmes d'information, tels que des entrepôts de données ou des systèmes de gestion des connaissances adaptés au contexte de l'agri-environnement. Cette équipe est animée par Monsieur Jean-Pierre chanet. Cette équipe est aussi connue sous le nom de l'acronyme  COPAIN  qui avait pour origine COmunication Pour une Agriculture Informatisée. Son activité est basée sur les domaines de l'informatique, de la télécommunication et des réseaux de capteurs et se consacre aux méthodes d'ingénierie des systèmes d'informations spécialisés dédiés à la gestion agri-environnementale. Les membres de l'équipe s'occupent donc d'analyser les besoins des exploitants et d'y répondre en proposant des solutions technologiques s'appuyant sur des systèmes d'information. Elle est composée de 14 personnes.

Figure 1.3  Carte d'identité du Cemagref

CemOA

: archive

ouverte

d'Irstea

Partie 2

Le projet EnergéTIC

Le but de cette partie est de présenter de manière générale le projet EnergéTIC , les objectifs visés ainsi que le cahier des charges du projet technique.

2.1 Présentation

En 2009, le Cemagref et l'ACTA (le réseau des instituts des lières animales et végé-tales) ont proposé le projet EnergéTIC en réponse à l'appel d'ore du CASDAR (Compte d'Aectation Spécial pour le Développement Agricole et Rural). Ainsi est né le projet EnergéTIC dont le but est d'évaluer de manière précise les performances énergétiques des exploitations agricoles en utilisant les NTIC (capteurs bas-coûts, réseau sans l, en-trepôt de données, etc.) an de maitriser la consommation de l'énergie et améliorer les rendements.

L'objectif du projet est de montrer la faisabilité et l'intérêt d'une collecte automati-sée de données pour le pilotage des performances énergétiques des exploitations agricoles ainsi que pour l'élaboration de bilans énergétiques plus ns à l'échelle de la parcelle, de l'atelier de production ou de l'opération. Ainsi, toutes les dépenses énergétiques de l'exploitation, qu'elles soient directes (consommation d'énergie fossile par les agroéquipe-ments, consommation d'électricité pour les batîments) et/ou indirectes (apport d'aliments et de fertilisants, etc.) sont prises en compte. On peut donc résumer les objectifs du projet EnergéTIC en trois points :

 L'amélioration des performances énergétiques des exploitations agricoles an de maî-triser les coûts et les performances dans un souci de protection de l'environnement ;  L'incitation au développement des NTIC au sein des exploitations agricoles ;  L'élaboration de référentiels de données pour les analyses de cycle de vie et

l'éva-luation des impacts.

Le déroulement se décompose en deux phases découpées en plusieurs volets :

CemOA

: archive

ouverte

d'Irstea

Le projet EnergéTIC Phase 1 : Analyse de l'existant et dénition des cahiers des charges

1. État de l'art des travaux existants sur les bilans énergétiques et les indicateurs de performances ;

2. Étude préalable des sites pilotes ;

3. État de l'art des solutions technologiques existantes ;

4. Expression des besoins et dénition des cahiers des charges ; Phase 2 : Mise en ÷uvre sur les sites pilotes et retours d'expérience

5. Développement et/ou adaptation de solutions technologiques à partir du cahier des charges établi ;

6. Mise en place d'un système d'acquisition et d'information opérationnel dans chacun des sites pilotes et collecte des données ;

7. Élaboration des bilans et valorisations possibles. Le projet dure 3 ans et s'étend de 2009 jusqu'en 2011 (g. 2.1).

Figure 2.1  Calendrier du projet

Co-piloté par l'ACTA et le Cemagref et nancé par le CASDAR, plusieurs parte-naires sont impliqués dans le projet EnergéTIC . Ainsi, l'ACTA, l'Institut de l'Élevage, ARVALIS-Institut du Végétal, la FNCUMA et SOLAGRO vont apporter leur savoir faire en terme d'expertise métier dans le domaine du pilotage énergétique des exploitations agricoles, d'une part. D'autre part, le Cemagref , l'ENESAD, l'ENITAB et l'EPLEFPA Vesoul vont apporter leur expertise scientique et technique dans la conception de so-lutions technologiques pour l'acquisition de données opérationnelles, en lien étroit avec l'enseignement supérieur et technique (EPLEFPA Brioude, Marmilhat, Moulins, Vesoul).

CemOA

: archive

ouverte

d'Irstea

Le projet EnergéTIC Dans le but de collecter des jeux de données réelles à diérentes échelles (ateliers, parcelle, exploitation), le projet EnergéTIC est mis en ÷uvre sur huit exploitations pi-lotes réparties sur toute la France (stations expérimentales, exploitations agricoles des EPLEFPA). Ainsi, selon les priorités identiées sur chacun des sites, des systèmes d'ac-quisition et d'information ont été mis en place. Une telle implantation permet, non seule-ment, une collecte rapide de données, mais aussi une vision globale et diversiée des tâches et pratiques agricoles en France (g. 2.2).

Figure 2.2  Carte des sites pilotes

En résumé, le projet EnergéTIC a pour but de mettre en place une collecte de don-nées avec des systèmes d'acquisition pour aboutir à une base de dondon-nées qui regroupera les informations collectées lors des opérations soit à partir des ches remplies par les opérateurs, soit en se basant sur les solutions technologiques (g. 2.3) :

• Diérents ux de consomation d'énergies considérés : carburant, électricité, engrais, phytosanitaires, aliments, etc.

• Diérents postes de consommation étudiés : distribution d'aliments, traite, épan-dage, travail du sol, irrigation, récolte, etc.

• Diérentes solutions technologiques envisagées, capteurs bas-coûts, GPS, RFID, jauge à carburant, débitmètre, capteur d'état, etc.

Figure 2.3  Principe de mise en ÷uvre du projet

CemOA

: archive

ouverte

d'Irstea

Le projet EnergéTIC

2.2 Cahier des charges

Le sujet du stage consiste à construire une base de données centralisée pour le projet EnergéTIC . En s'appuyant sur les données collectées dans les huit exploitations agricoles pilotes, le choix de la mise en place d'une base de données regroupant toutes les données collectées suite aux diérentes opérations s'est imposé pour pouvoir les exploiter et obtenir des résultats satisfaisants. Les données brutes proviennent soit des ches ayant été remplies par les opérateurs qui eectuent les tâches, soit des capteurs installés sur les équipements. Ainsi, pour stocker les données il faut penser une structure de données incluant un niveau de détails assez élevé et qui s'adapte aux ches de collecte (annexe I) préétablies. Ensuite, envisager une interface permettant d'intégrer les données de diérentes sources (capteurs, ches des opérateurs) sur l'ensemble des sites pilotes. Pour cela, construire une interface de saisie, sous forme d'une application web, qui se chargera d'adapter les informations saisies à la structure de données élaborée.

Par la suite, ceci permettra de construire un entrepôt de données dans lequel seront stockées des données obtenues en s'appuyant sur la base de données initiale. Pour ar-river à l'objectif principal du projet EnergéTIC en l'occurrence : l'évaluation ne des performances énergétiques des entreprises agricoles.

Le déroulement du stage s'est établi selon les étapes suivantes : Appropriation du sujet

Premièrement s'adapter au sujet en assimilant la terminologie agricole utilisée dans l'ensemble des informations destinées à êtres stockées dans la base de données ; Analyse des besoins et des contraintes techniques

Mettre en avant les élements clés ainsi que les attribus associés tout en prenant en compte l'exploitation future des ces données ;

Choix des technologies à utiliser pour le développement

Étude des diérentes technologies pouvant servir à la réalisation de la base de don-nées ainsi que l'interface de saisie ;

Conception et développement de la base de données

Établir un modèle conceptuel de données á partir des besoins dégagés lors de l'ana-lyse, s'appuyer sur ce dernier pour construire un modèle physique de données et ensuite générer la base de données ;

Prototypage en lien avec l'exploitation agricole du site de Montoldre

Réalisation d'une interface de saisie reliée á la base de données et mise en place d'un serveur d'hébergement qui permettra aux utilisateurs de se connecter et de saisir des données an d'eectuer des tests.

CemOA

: archive

ouverte

d'Irstea

Le projet EnergéTIC Une fois l'interface mise en place, la base de données contiendra une quantité assez conséquente d'informations brutes qui permettera, par la suite, de constituer un entrepôt de données susament fourni pour obtenir des résultats signicatifs. Ainsi, les indices de performances énergétiques seront déduits avec une précision satisfaisante.

CemOA

: archive

ouverte

d'Irstea

Partie 3

Implémentation

Cette partie traite du déroulement du projet ainsi que des diérentes étapes de la réalisation.

3.1 Choix des technologies

Dans le but de bien mener le projet, diérents facteurs ont été pris en compte concer-nant le choix des technologies utilisées. Il s'agit donc de choisir les technologies les mieux adaptées à la réalisation de l'interface an d'optimiser le processus de création et d'assu-rer un résultat satisfaisant tout en étant adapté aux équipements (informatiques) déjà en place. En second lieu, permettre á une tierce personne, d'assurer la maintenance, d'ap-porter une évolution aisée au modèle de données, d'adapter l'interface à l'évolution de la base de données mais aussi une modication relativement simple de l'interface de saisie an de répondre aux besoins futures du projet EnergéTIC .

Après évaluation de di¯entes technologies, j'ai choisi d'utiliser Django bien que je ne le connaisse pas. Cela m'a permis d'acquérir de nouvelles compétences, notamment en programmation Python. Les seules contraintes imposées par le projet étaient de réaliser une base de données avec une interface de saisie par internet.

3.1.1 Modélisation

Ojecteering Modeler est un logiciel de modélisation permettant de créer toutes sortes de diagrammes en utilisant le langage UML. L'utilisation de ce logiciel a permis de réaliser le diagramme de classes représentant le modèle conceptuel de données et de lui apporter les modications nécessaires tout au long du processus de modélisation.

Une fois la structure de la base de données modélisée, ce logiciel permet de générer automatiquement un modèle physique de données. Des modules peuvent êtres intégrés an d'apporter le support du langage SQL. Ce support permet de générer un script qui, une fois lancé sur un SGBD, génère la base de données.

CemOA

: archive

ouverte

d'Irstea

Implémentation

3.1.2 Interface de saisie

An de réaliser l'interface sous forme d'une application web, le langage de program-mation Python a été retenu pour sa simplicité, sa polyvalence et pour pouvoir proter du FrameWork Django. Le framework Django est basé sur l'architecture MVC permet-tant de séparer le projet en trois parties distinctes : le modèle de données, l'apparence de l'application et le contrôleur qui sert de lien entre l'interface et la base de données. Cette architecture permet d'optimiser le processus de réalisation de l'interface en évitant toute redondance dans les sources mais aussi de simplier les mises à jour futures de l'ensemble du projet selon les besoins.

Ainsi, suivant la méthode de conception MVC, le framework Django permet d'optimi-ser la réalisation de l'interface en retranscrivant le modèle conceptuel de données en code Python pour l'inclure au projet et pouvoir manipuler les données et cela indépendamment du SGBD. Ce framework permet d'automatiser la création de l'interface d'administration (interface permettant de gérer l'ensemble des données) et celle des formulaires servant aux utilisateurs pour saisir le contenu.

3.1.3 Serveur

L'installation d'un serveur est nécessaire pour assurer l'accès à l'interface sur l'en-semble des sites pilotes et ainsi, centraliser l'enl'en-semble des données saisies. L'enl'en-semble des formulaires servant à la saisie des données et l'interface d'administration seront acces-sible via chaque poste relié au réseau. Le serveur web Apache a été utilisé pour diuser l'interface associée au SGBD MySql servant à stocker les données gérées avec l'interface phpMyAdmin permettant de manipuler la structure de données.

Le module WSGI a permi d'intégrer l'interface réalisée en code Python au serveur web Apache. Pour apporter le support du SGBD MySql au langage Python.

3.2 Base de données

3.2.1 Modélisation

Dans le but de mener à bien la réalisation de la base de données correspondant aux multiples besoins du projet EnergéTIC , il a fallu commencer par l'étape de la conception. Des ches ont été établies dans le cadre du projet EnergéTIC , an de contenir le plus de détails possible concernant les opérations eectuées dans les exploitations agricoles. Cela concerne les équipements utilisés (la marque et le modèle), les travaux, les opérateurs qui les eectuent ainsi que les tâches qui composent chaque travail. Ensuite, le type

CemOA

: archive

ouverte

d'Irstea

Implémentation production lié à chaque opération (production utilisée ou produite) et la localisation de celle-ci. Chaque élément est accompagné par ses caractéristiques ce qui ore un niveau de détails assez élevé. Ces ches sont destinées à êtres complétées par des utilisateurs situés dans chaque exploitation.

La conception de la base de données passe par la structuration de la totalité des in-formations indiquées sur les ches présentées ci-dessus. Ainsi, chaque entité de la base de données, accompagnée de ses attributs, correspond à un élément et à ses détails présents dans les ches. Cela permet de réaliser une structure de données prête à accueillir l'en-semble des informations et de stocker celles déjà recueillies, mais aussi les adapter pour une exploitation ultérieure. Une fois la base renseignée, le but est de pouvoir en extraire et traiter les données signicatives an de les stocker dans un entrepôt de données. Cet entrepôt permettra une lecture plus claire des informations et notamment d'analyser les consommations d'énergies à une échelle plus ne de l'exploitation agricole (le travail, la parcelle, le matériel, etc).

Une fois la base de données modélisée, l'AGL Objecteering Modeler (logiciel de mo-délisation orienté objet) a été utilisé dans le but de retranscrire le modèle conceptuel de données en langage de modélisation UML. Ce logiciel a servi à modéliser les diérents éléments en entités contenant les caractéristiques modélisées, à leur tour, en attributs. Ceci a permis de faire évoluer le modèle tout au long du stage en y apportant diverses améliorations et modications suite au nombreuses discussions avec les membres du projet qui souhaitent continuer à faire évoluer la structure de la base tout en étant conscient des dicultés que cela posera une fois que la contiendra des données. Du modèle conceptuel de données, Ojecteering Modeler, a permis de générer un modèle physique de données qui a servi à construire concrètement la base de données.

3.2.2 Structure

Le modèle conceptuel de données construit (annexe II) repose sur quatres entités prin-cipales : Travail, tâches, équipements et produits (g. 3.1). L'entité travail est composée de l'ensemble des opérations eectuées qui sont, elles, modélisées par l'entité tâches. Un travail réalisé est caractérisé par la consommation globale, la date mais aussi la durée de réalisation ainsi que les préparations eectuées avant et après la réalisation. L'entité équipements, reliée à elle même et au travail, représente les diérents équipements uti-lisés an d'eectuer le travail associé. La masse, la consommation moyenne, le type de motorisation ainsi que la présence ou non d'un moteur font partie des propriétés modé-lisées dans l'entité équipements. Un travail est donc relié à l'ensemble des équipements utilisés et aux diérentes tâches qui le composent, ces dernières sont caractérisées par la surface travaillée, le régime de prise de force, la consommation d'énergie directe, le temps

CemOA

: archive

ouverte

d'Irstea

Implémentation total de travail, etc. Le fait de relier l'entité équipements à elle même permet de ne pas limiter le nombre de combinaisons des matériels à une liste prédénie. Par exemple, le tracteur X avec charrue Y peut eectuer un travail de labour sur plusieurs parcelles, et le même tracteur X pourra aussi être utilisé avec un épandeur Z. Cela permet de conserver dans la base les diérentes combinaisons équipements-équipements et en même temps d'associer un travail à un ensemble de plusieurs équipements. Chaque tâche est reliée à un ou plusieurs produits qui comptent parmi leurs caractéristiques la quantité, la nature (apporté, exporté), etc. Un produit peut être relié à une ou plusieurs tâches (relation plusieurs-plusieurs)

Les entités principales sont accompagnées de diérentes entités permettant d'apporter plus de détails aux opérations eectuées. Ainsi, travail est relié à l'entité opérateurs représentant l'opérateur ayant eectué l'ensemble des tâches. Chaque tâche, en fonction de sa nature, peut être aectée soit à un lot d'animaux soit à une parcelle culturale, ces dernières étant modélisées par des entités du même nom. Pour assurer une certaine évolutivité au modèle, les tâches sont reliées à une entité type de tâche qui permet de spécier sa nature. Enn, dans le but de fournir encore plus de détails, les lots d'animaux et les parcelles culturales sont accompagnés des entités telles que cultures végétales et animaux qui sont, elles aussi, reliées à d'autres entités.

Par exemple, l'opération épandage d'engrais constitue un travail composé de

plu-Figure 3.1  Modèle conceptuel de données simplié

CemOA

: archive

ouverte

d'Irstea

Implémentation sieurs tâches :  Attelage de l'épandeur ;  Chargement de l'épandeur ;  Aller au champ ;  L'épandage ;  Retour du champ ;  Le dételage.

Le travail est eectué à l'aide de deux équipements, le tracteur qui est motorisé et l'épan-deur qui ne l'est pas. L'opération utilise de l'engrais qui constitue un produit apporté.

3.2.3 Réalisation

La création de la base de données, à partir du modèle réalisé, au niveau du SGBD permet à l'interface d'interagir avec les données. Le framework Django assure cette prise en charge indépendament du SGBD utilisé. Pour cela, il sut de retranscrire le modèle conceptuel de données en code Python. Un seul chier contient toutes les entités, les at-tributs et leur types. Cette centralisation simplie l'accès à la base de données en évitant l'utilisation des requêtes SQL, puisque à travers des commandes en Python, toute sorte de manipulation est possible. Le code décrivant la structure de données peut être accom-pagné d'un méta-modèle contenant les libellés des entités et des attributs mais aussi une description et des précisions à propos des données à saisir. Le modèle écrit en code Python ainsi que le méta-modèle l'accompagnant peuvent être réutilisé à travers toute l'interface qu'il s'agisse de la création de champs pour la saisie ou diérentes sortes de manipulation concernant la base de données.

Par exemple dans le code suivant se trouve l'entité tâches retranscrite par le biais d'une classe en Python ainsi qu'une partie de ses attributs :

Cette partie du code dénit les diérents attributs de l'entité, y compris les clés étran-gères (ForeignKey) liées aux autres entités (Unites représentée elle aussi par une classe). Chaque attribut, déni par son type (date, chaine de charactères, etc), peut contenir un champs verbose_ name contenant un libellé adapté à l'achage pour les utilisateurs. La classe Meta, une sous classe de la classe tâches, contient des méta-données portant sur les propriétés de l'entité 'travail' comme le nom de la table, représenté par la classe, dans la base de données. Les relations plusieurs-plusieurs peuvent êtres integrées (Many-ToManyField pour l'attribut id_produits). La fonction __unicode__  fournit un nom d'achage, en relation avec les données stockées, servant à faciliter le repérage des tâches dans une liste.

CemOA

: archive

ouverte

d'Irstea

Implémentation

class Taches ( models . Model ) :

id_tache = models . AutoField ( primary_key=True ) etat_sol = models . I n t e g e r F i e l d ( ' e t a t du s o l ' )

TYPES = ( ( 5 4 0 , ' 540 ' ) , (750 , ' 750 ' ) , (1000 , ' 1000 ' ) , )

regime_prise_force = models . I n t e g e r F i e l d ( ' regime de p r i s e de f o r c e ( t r / min ) ' , c h o i c e s=TYPES, n u l l=True , blank=True )

conso_energie_directe = models . F l o a t F i e l d ( " consomation d ' e n e r g i e d i r e c t e " , n u l l=True , blank=True )

id_unite = models . ForeignKey ( Unites , verbose_name=" unite " )

regime_moteur = models . CharField ( ' regime du moteur ' , max_length=50, blank=True )

temps_mort_type = models . BooleanField ( " cocher s i l e temps mort e s t estime ( sinon i l e s t mesure ) " )

id_produits = models . ManyToManyField ( Produits , verbose_name=' p r o d u i t s ' ) observations_tache = models . TextField ( ' o b s e r v a t i o n s ' , blank=True )

def __unicode__( s e l f ) :

return u '%s ' % s e l f . id_tache class Meta :

db_table = u ' taches ' verbose_name = ' tache '

Figure 3.2  Extrait de la classe tâches

3.3 Interface

La réalisation de l'interface et de la base de données nécessite la création d'un projet sous Django qui contiendra plusieurs applications chacune chargée de traiter une partie du projet (base de données, interface d'administration, interface de saisie, etc).

Ainsi, la structure du projet créée avec Django se présente sous la forme suivante :

+ i n t e r f a c e _ e n e r g e t i c + i d e n t i f i c a t i o n + media + s a i s i e + stockage __init__ . py admin . py models . py views . py + templates __init__ . py manage . py CemOA : archive ouverte d'Irstea / Cemagref

Implémentation

s e t t i n g s . py u r l s . py

Les dossiers (précédés par le signe +) représentent les applications. Chaque application prend en charge une partie de l'interface. Dans toutes les applications se trouve des chiers (d'extension py) contenant une partie précise du code. Par exemple models.py contient le modèle de données et admin.py s'occupe de l'intégration du modèle dans l'interface d'administration. Le dossier templates contient tout les chiers chargés de l'apparence de l'interface (chiers HTML).

An d'unier l'interface, les utilisateurs et l'administrateur se connectent sur le même écran d'accueil (g. 3.3). Cet écran leur permet de s'identier à l'aide d'un nom d'uti-lisateur et d'un mot de passe. En fonction des identiants saisis, l'utid'uti-lisateur est dirigé soit vers la page d'administration, qui lui permettra de contrôler les données, soit vers l'interface de saisie.

Figure 3.3  Page d'identication

L'identication des utilisateurs permet de créer une session basée sur le protocole HTTP dans le but de garder les utilisateurs connectés. Ceci permet d'assurer une certaine stabilité lors de la saisie des formulaires en plusieurs étapes. Ainsi, si un utilisateur change (accidentellement) de page au niveau du navigateur en pleine saisie, il lui sut d'aller à l'adresse de l'interface pour reprendre la saisie à la même étape. Cela évite le problème de la répétition dans la saisie des données qui peut engendrer une certaine duplication des données dans la base de données.

CemOA

: archive

ouverte

d'Irstea

Implémentation

admin . s i t e . r e g i s t e r ( Travail ) admin . s i t e . r e g i s t e r ( Taches ) admin . s i t e . r e g i s t e r ( Equipements )

Figure 3.4  Code d'ajout des tables dans l'interface d'administration

3.3.1 Administration

L'administrateur bénécie d'une interface spécique qui lui permet de contrôler l'inté-gralité des données. Il peut, ainsi manipuler toutes les données dénies dans le modèle. Le framework Django permet de générer cette interface à partir du modèle déjà déni en code Python (g. 3.2) basé lui même sur le modèle conceptuel de données. La personnalisation de cette interface reste quand même possible bien qu'elle soit générée automatiquement. Le code suivant permet d'intégrer une partie des entités modélisées dans l'interface administrateur. Une fois toutes les entités integrées à l'interface d'administration (g. 3.5), l'administrateur aura l'accès à l'ensemble de la base de donnèes.

Figure 3.5  Page d'accueil de la page d'administration

Sur cette page, se trouve l'identiant de l'administrateur et ore la possibilité de le déconnecter, mais aussi celle de changer de mot de passe. Ensuite, la liste de toutes les tables dénies dans le modèle. Chaque table présentée dans la liste est accompagnée de deux boutons permettant soit d'ajouter une entrée dans la table soit de modier une déjà

CemOA

: archive

ouverte

d'Irstea

Implémentation existante.

Django intègre même la gestion des utilisateurs et des droits. Cette gestion permet à l'administrateur d'ajouter, de supprimer ou de modier des utilisateurs. Toutefois, an d'adapter la gestion des utilisateurs (g. 3.6) au modèle conceptuel de données, l'entité dénissant les utilisateurs est surchargée an de les relier aux exploitations.

Figure 3.6  Liste des utilisateurs dans la page d'administration

L'interface d'administration permet d'ajouter (resp. modier) des entrées dans la base de données, cela par le biais des pages d'ajout (resp. modication) (g. 3.8). Ces pages, sont générées automatiquement à partir du chier models.py dans lequel se trouve la description de la base de données en code Python. Dans cette page chaque champ est associé à une case dans la base de données. Un libellé précède chaque champ, le texte du libellé se trouve dans le méta-modèle. Les types des champs sont déduits des types des attributs. Les clés étrangères sont représentées par des listes déroulantes contenant le contenu des tables reliées. Des entrées peuvent êtres ajoutées aux tables an de permettre de les sélectionner en tant que clés étrangères. Ceci est possible grâce au bouton qui se situe juste à côté de la liste déroulante. L'ajout de ces entrées s'eectue à travers une fenêtre secondaire qui contient, à son tour, tous les champs servants à remplir une entrée dans une table. La saisie des dates est simpliée par l'ajout d'un bouton qui permet d'acher un calendrier et de reprendre le résultat directement dans le champs à remplir. En ce qui concerne les relations plusieurs-plusieurs, django prend en charge la création automatique des tables intermédiaires. Au niveau de l'interface cela se traduit par deux listes. Dans l'une d'elles se trouve l'ensemble des entrées d'une table. Cela permet d'ajouter les éléments désirés dans l'autre liste, ce qui facilite la sélection de plusieurs éléments à la fois. Les champs plusieurs-plusieurs sont, comme les champs des clés étrangères,

CemOA

: archive

ouverte

d'Irstea

Implémentation

Figure 3.7  Fenêtre secondaire d'ajout

accompagnés d'un bouton permettant l'ajout d'une entrée dans la table liée.

An de correspondre aux besoins spéciques du modèle de données, les pages d'ajout (resp. modication) sont modiées. Changer ces pages permet d'ordonner les champs, d'en situer plusieurs sur la même ligne ou de tout simplement d'en exclure quelques uns. Par exemple, le code en Python suivant, a permis de modier l'achage de la page d'ajout (resp. modication) des entrées dans la table des tâches dans l'interface d'administration :

class TachesAdmin ( admin . ModelAdmin ) : f i e l d s e t s = ( ( None , { ' f i e l d s ' : ( ' ordre_tache ' , ( ' s u r f a c e _ t r a v a i l l e e ' , ' s u r f a c e _ t r a v a i l l e e _ t y p e ' ) , ( ' temps_total_passe ' , ' temps_total_passe_type ' ) , ' etat_sol ' , ( ' v i t e s s e _ t r a v a i l ' , ' v i t e s s e _ t r a v a i l _ t y p e ' ) , ' l a r g e u r _ t r a v a i l ' , ' regime_prise_force ' , ' profondeur_travail ' , ( '

conso_energie_directe ' , ' id_unite ' ) , ' regime_moteur ' , ( ' temps_mort ' , ' temps_mort_type ' ) , ' distance_parcourue ' , '

i d _ t r a v a i l ' , ' id_operation_technique ' , ' i d _ l o c a l i s a t i o n ' , ' id_produits ' , ' observations_tache ' )

}) , )

f i l t e r _ h o r i z o n t a l =( ' id_produits ' , )

Dans certains cas la saisie des champs de deux tables peut être liée. Il est plus simple pour l'utilisateur d'accéder à la modication des deux tables sur la même page d'ajout (resp. modication) (g. 3.9). Ainsi, la page d'ajout (resp. modication) d'une entrée dans la table travail, est modiée an d'intégrer celle qui correspond à la table outils de mesure.

Pour arriver à eectuer une telle intégration, il faut créer une classe qui redénit l'apparence de la page de modication de la table outils de mesure et ensuite intégrer cette classe dans celle qui dénit l'agencement des champs de la table travail. Le code

CemOA

: archive

ouverte

d'Irstea

Implémentation

Figure 3.8  Page d'ajout/modication d'une tâche Python suivant permet d'apporter une telle modication.

class OutilsMesureInLine ( admin . Ta bul arI nlin e ) : model = OutilsMesure

can_delete = False

class TravailAdmin ( admin . ModelAdmin ) : f i e l d s e t s = ( CemOA : archive ouverte d'Irstea / Cemagref

Implémentation ( None , { ' f i e l d s ' : ( ' l i b e l l e _ t r a v a i l ' , ' id_operateur ' , ( ' date_debut ' , ' date_fin ' ) , ( ' plein_reservoir_debut ' , ' p l e i n _ r e s e r v o i r _ f i n ' ) , ( ' compteur_heures_debut ' , ' compteur_heures_fin ' ) , ( ' releve_kms_compteur_debut ' , ' releve_kms_compteur_fin ' ) , ' o u t i l _ p r e s e n t ' , ( ' o u t i l _ a t t e l e ' , ' o u t i l _ d e t e l e ' ) , ' distance_parcourue_hp_estimee ' , ' outil_retour_hors_exploitation ' , ( ' conso_energie_directe_mesuree ' , ' id_unite ' ) , ' duree_totale_travail_estimee ' , ' nbre_ar_parcelle_siege ' , ' nbre_ar_parcelle_lc ' , ' o b s e r v a t i o n s _ t r a v a i l ' ) }) , ) i n l i n e s = [ OutilsMesureInLine , ]

L'administrateur peut suivre les changements eectués à partir de l'interface d'admi-nistration. Pour cela un onglet Actions récentes, situé dans la page d'accueil de la page d'administration, ache les derniers modications apportées à la base de données.

Figure 3.9  Onglet d'ajout des outils de mesure intégré dans la page d'ajout des travaux

3.3.2 Interface de saisie

L'interface permet aux utilisateurs, aprés identication, de saisir des informations relatives aux opérations eectuées. Cela s'eectue sur plusieurs étapes vu la quantité importante des informations à saisir.

L'interface d'identication de Django dirige l'utilisateur en fonction des ses identiants (nom d'utilisateur et mot de passe) soit vers l'interface de saisie soit vers celle d'admi-nistration. Pour cela, l'interface fourni par défaut est surchargée, puisque cette dernière

CemOA

: archive

ouverte

d'Irstea

Implémentation dirige tous types d'utilisateur vers l'interface d'administration. Ceci passe par la réecriture de la page d'identication. Ainsi, une nouvelle page d'identication est crée sous forme d'une application sous Django. Cette application est intitulée identication. La classe login située dans le chier views.py de l'application qui s'occupe d'acher la page en utilisant le chier d'apparence (template) login_identication.html.

Une fois l'utilisateur connecté, il accède à la page d'accueil des utilisateurs (g 3.10). L'aspect de cette page est basée sur l'apparence uniformisée pour toute l'interface de saisie. Ainsi, le nom de l'utilisateur est aché en haut de la page juste à côté d'un lien lui permettant de se déconnecter à tous momment.

Figure 3.10  Page d'accueil de l'interface des utilisateurs

L'utilisateur peut alors accèder aux formulaires de saisie. L'ensemble des formulaires est groupé dans un seul chier forms.py appartenant à l'application saisie. Ces formu-laires sont générés à partir du modèle prédéni en code Python. Ainsi, toute modication dans la modèle de données implique une adaptation automatique des formulaires à rem-plir.

L'extrait de code suivant contient une classe qui permet de générer le formulaire cor-respondant à la table équipements.

class EquipementsForm ( models . ModelForm ) : getNom = Equipements . _meta

nom = getNom . verbose_name . c a p i t a l i z e ( ) class Meta :

model = Equipements

exclude = ( ' i d _ t r a v a i l ' , )

Des champs peuvent être retirés des formulaires an d'être gérés en arrière plan par l'interface de saisie.

Bien que les classes des formulaires se chargent de stocker les informations saisie dans la base de données, les classes contenues dans le chiers views.py se chargent de les relier aux pages d'achage (g 3.11).

Les pages de saisie contiennent un bouton permettant de vérier les informations introduites et, si elles sont valides, de les stocker dans la base de données puis diriger

CemOA

: archive

ouverte

d'Irstea

Implémentation

Figure 3.11  Page contenant le forumlaire de saisie relié la table travail l'utilisateur vers l'étape suivante.

Le fonctionnement de l'interface de saisie dépend des classes contenues dans le chier views.py. Ces classes permettent de charger les formulaires, de les intégrer aux pages en utilisant le moteur de rendu adapté.

L'extrait de code suivant, présente la classe qui permet de saisir une entrée dans la table travail et une autre dans la table outils de mesure reliée à la première. Cette

CemOA

: archive

ouverte

d'Irstea

Implémentation classe permet d'acher le formulaire mais aussi de le ré-acher dans le cas où il y a une erreur de saisie. Si les données saisies sont valides, elles sont stockées dans la base de données et puis l'utilisateur est dirigé vers le formulaire suivant. Les étapes de saisie sont stockées dans la session du protocole HTTP an d'acher automatiquement la page correspondante à l'étape. Le formulaire ainsi que ses caractéristique sont ensuite transmis à la page adaptée à l'achage des formulaires travail et outils de mesure.

def s a i s i e T r a v a i l ( r e q u e s t ) : i f r e q u e s t . method == "POST" :

form = TravailForm ( r e q u e s t .POST)

outilsForm = OutilsMesureForm ( r e q u e s t .POST) i f form . i s _ v a l i d ( ) :

r e s u l t a t = form . save ( ) t r a v a i l = r e s u l t a t . pk

o u t i l s = outilsForm . save ( commit=False )

o u t i l s . i d _ t r a v a i l = Travail . o b j e c t s . get ( i d _ t r a v a i l=t r a v a i l ) o u t i l s . save ( ) r e q u e s t . s e s s i o n [ ' etape ' ] = 2 return HttpResponseRedirect ( ' ./% s ' % t r a v a i l ) else : form = TravailForm ( ) outilsForm = OutilsMesureForm ( ) return render_to_response ( ' s a i s i e / t r a v a i l . html ' , { ' form ' : form , ' outilsForm ' : outilsForm , ' user ' : r e q u e s t . user , ' t i t l e ' : form . nom, } , context_instance=RequestContext ( r e q u e s t ) )

Ainsi, ces classes permettent traiter les données du côté du serveur et de les inte
ger aux chiers dédiés à l'apparence pour qu'elles puissent être achées. Dans le cas où des champs ont été laissés vide alors qu'il doivent êtres impérativement remplis ou les données saisies ne correspondent pas au type des champs (un format de date erroné par exemple), la page achée à l'envoi des données (g. 3.12) indiquera les erreurs commises an d'être corrigés.

Les pages dédiées à l'apparence sont situées dans le dossier template du projet. Ces pages sont écrites en code HTML et CSS an de gérer la mise en page. Des balises compatibles avec le framework Django sont incluses an d'acher toutes sorte de données relatives au traitement de données. Par exemple, les formulaires générés automatiquement sont transmis au chier d'apparence an d'être aché sur la page web.

CemOA

: archive

ouverte

d'Irstea

Implémentation

Figure 3.12  Page achant des erreurs suite à une saisie erronée

Le code suivant représente le code source du chier travail.html qui s'occupe de l'apparence de la page de saisie des équipements.

{% extends " s a i s i e /change_form . html" %} {% load i18n %}

{% block content %}

<hr style=" height : 5 px ; " />

<form method=" post " action=""> {% csrf_token %} <table width="100%"> {% f o r f i e l d in form %} <tr> {% i f f i e l d . e r r o r s %} <tr><td colspan="2">{{ f i e l d . e r r o r s }}</td></ tr> {% e n d i f %} <td>{{ f i e l d . label_tag }}</td> <td>{{ f i e l d }}

<p class=" help ">{{ f i e l d . help_text | s a f e }}</p> </td> </ tr> {% endfor %} </ table> </form> {% endblock %}

Les chiers d'apparence contiennent des bloques de code qui permettent d'acher ou non des éléments en fonction des données envoyées de la part des classes qui les contrôlent. L'ensemble des formulaires est aché grâce à des boucles qui parcours le modèle source des formulaires. An d'uniformiser toutes les pages de saisie, les chiers d'apparence héritent des caractéristiques d'autres chiers d'apparence sur lesquels ils sont basés. Ces derniers contiennent les éléments qui ne changent pas à travers les diérentes étapes de la saisie des données. CemOA : archive ouverte d'Irstea / Cemagref

Implémentation

Conclusion

Ce stage arrivant à terme, j'ai acquis plusieurs connaissances tant au niveau personnel que professionnel. L'élaboration du modèle conceptuel de données en équipe m'a permis de développer mon sens de communication et du travail en équipe. J'ai également appris à utiliser Objecteering modeler, un outil qui m'était jusque là inconnu. Durant l'élaboration de l'interface j'ai découvert de nouveaux outils (Django framework et Python) qui m'ont aidé à optimiser le processus de la création. J'ai également du mettre en application mes compétences en informatique, tel que le langage UML.

Ce stage fut pour moi une occasion de mieux appréhender le milieu professionnel et d'intéragir avec ses diérents acteurs. J'ai su faire face aux diérentes problématiques auxquelles j'ai été confronté grâce aux conseils précieux de mes maîtres de stage.

La base de données et l'application que j'ai d
veloppé vont être utilisés dans le cadre du projet EnergéTIC pour le stockage des informations recueillies sur les diérentes ex-ploitations pilotes.

Ces données serviront ensuite à une analyse ne des performances énergétiques dans les exploitations agricoles grâce à un entrepôt de données qui sera construit à partir de cette base de données.

Finalement, ce stage a été pour moi une bonne expérience durant laquelle j'ai du répondre à un certain nombre de besoins tout en acquérant des connaissances valorisantes pour ma formation. CemOA : archive ouverte d'Irstea / Cemagref

Annexe I

Nom du tracteur/automoteur : Nom de l'outil associé :

Début du chantier Outils de mesure utilisés pendant le chantier

Préparation

Caractéristiques des mélanges apportés/récoltés (à compléter si besoin)

Caractéristiques du chantier Données générales : O N E M O N E M O N E M E M E M E M E M E M E M Données "équipements" : E M E M E M Données "produits" : (recto)

Date début : Montre : Pompe à fuel : Plateforme de pesée : Capteur de pesée : Relevé km compteur début : Débitmètre :

Relevé heure compteur début : Chronomètre : Jauge :

Durée préparation : Plein du réservoir : Oui Non Outil déjà attelé : Oui Non Non

Nom du mélange et quantité totale Nom du(des) produit(s)

composant le mélange Quantité totale de produit (en l ou kg) Quantité de fuel consommée : Outil présent sur l'exploitation : Oui

ex : Mélange 1

JOA 6 l

Virtuose 6 l

200l Eau 188 l

Nom parcelle(s) parcourue(s) :1

ere _parcelle : 2eme parcelle : 3eme parcelle : Culture : Opération technique : Surface travaillée : 100 % de

la parcelle sinon surface en ha

100 % de

la parcelle sinon surface en ha

100 % de

la parcelle sinon surface en ha

Temps passé dans parcelle Temps mort : Quantité de fuel consommée : Distance parcourue dans la parcelle : Etat du sol : Vitesse de travail : Largeur de travail : Profondeur de travail : Régime moteur : Régime prise de force (540, 540 eco, 750…) : Nom du mélange/produit apporté/récolté : CemOA : archive ouverte d'Irstea / Cemagref

Caractéristiques du chantier (suite) Données générales : O N E M O N E M O N E M E M E M E M E M E M E M Données "équipements" : E M E M E M Données "produits" : E M E M E M

Rangement Fin du chantier

Nb aller/retour parcelles/siège d'exploitation : Nb aller/retour parcelles/lieu de chargement : Nom parcelle(s) parcourue(s) : 4

eme parcelle : 5eme parcelle : 6eme parcelle : Culture : Opération technique : Surface travaillée : 100 % de

la parcelle sinon surface en ha

100 % de

la parcelle sinon surface en ha

100 % de

la parcelle sinon surface en ha

Temps passé dans parcelle Temps mort : Quantité de fuel consommée : Distance parcourue dans la parcelle : Etat du sol : Vitesse de travail : Largeur de travail : Profondeur de travail : Régime moteur : Régime prise de force (540, 540 eco, 750…) : Nom du mélange/produit apporté/récolté : Quantité apportée/récoltée Durée rangement : Quantité de fuel consommée :

Plein du réservoir : Oui Non Date fin : Retour outil sur

l'exploitation : Oui Non

Relevé heure compteur fin : Outil dételé : Oui Non

Quantité totale de fuel consommée :

Observations :

Aide :

La saisie des données est facultative pour les zones hachurées. E signifie valeur Estimée et M valeur Mesurée.

Une fiche correspond à un ensemble de travail (attelage) et à un type de chantier. Une nouvelle fiche doit être créée pour tout nouveau Relevé km compteur fin : Chauffeurs :

Estimation de la durée totale du chantier :

Estimation de la distance totale parcourue hors parcelle :

CemOA

: archive

ouverte

d'Irstea

Annexe II

1 1 mesures 1 * de_type 1 * s itue_dans * 1 contient * 1 opere_dans 0 ..1 0 ..1 equipement_principal 0 ..1 * as s ociation constitue 1 * ef fectue_par 1 * opere_produits * * de_type 1 * unite_quantite 0 ..1 * compose_de 1 1 ..*

dis pos e_de * 0 ..1 ass ocie * 1 contient * ₁ s itue 1 * unite_capacite 1 * unite_debit * 0 ..1 reference * 1 cons tructeur 1 * unite_quantite_matiere_active * 0 ..1 cons o_tache unites * 0 ..1 unite_conso_energie * 0 ..1 0..1 modifie_dans 1 * utilisateurs outils_mesure parcelles_culturales parcelles_physiques exploitations types_taches equipements localisations types_produits animaux types_animaux lots_animaux types_cultures zone_pedo_climatique unites produits operations_techniques cultures_vegetales modeles marques operateurs taches Travail 1 +pa ss : string +login : strin g

+id_utilisa teu r : integ er {prima ryKey (1)}

+ca pteu r_pesee : boo le an +p la teform e_pesee : bo olean +d ebitm etre : boo le an +jau ge : boo le an +p omp e_fuel : boo le an +ch rono me tre : b oolean +m ontre : b oolean

+id_outil_m esure : integer {prim aryKey (1)}

+superficie_tra vaillable : integer +objectif_pro duction : in tege r +type_ge ome trie : bo olean {typ e (en um )} +precede nt : string

+cam pag ne : string

+date_fin : und efined {sq lT ype (datetim e)} +date_debu t : unde fined {sqlType (datetim e)} +intitule : string

+id_parcelle _c : inte ger {prim aryKey (1)}

+sup erficie_travail : integer {sqlTyp e (de cim al)} +sup erficie_to tale : integer {sq lT ype (decim al)} +type_geom etrie_pp : string

+parce lle_physique : string

+id _pa rcelle_p : integ er {prima ryKey (1)}

+description : undefined {sqlType (text)} +sau : integer

+exploita tion : strin g

+id _ex ploitatio n : integ er {prima ryKey (1)}

+type_ta che : string

+id_type_tache : intege r {prim aryKe y (1)}

+du ree_vie : intege r {sqlTyp e (d ecimal)} +de bit_hyd rauliqu e : in tege r {sqlType (d ecimal)} +gu id age : boo le an

+m otricite : boole an {type (enum )}

+caracte ristiques_emission : u ndefined {sqlType (text)} +con so_ann uelle_moyenn e : in teg er {sqlType (d ecima l)} +temp s_fct_an nuel : inte ger {sqlType (decim al)} +pu issance : inte ger {sqlType (decim al)}

+caracte ristiques_equipem ent : unde fined {sqlType (tex t)} +type _transport : bo olean {type (en um)}

+de bit : integ er {sqlType (decim al)} +an nee_construction : integer +cap acite : inte ger {sqlType (decim al)} +largeur_principale_trava il : inte ger +m asse : integer {sq lT ype (decim al)} +com m enta ire : und efined {sqlT ype (te xt)}

+id_equipe men t : inte ger {p rima ryKey (1)}

+type _g eom etrie : string +localisation : string

+id_localisa tion : inte ger {prim aryKey (1)}

+typ e_p rodu it : string

+id_type_produit : integer {prim aryKe y (1)}

+nom bre_anim aux : integer

+date _fin _an im au x : undefined {sqlType (datetim e)} +date _de but_an im aux : u ndefined {sqlType (date time )}

+id _an im aux : in tege r {prim aryKey (1)}

+type_anim aux : strin g

+id_typ e_a nima ux : integ er {p rima ryKey (1)}

+lot_m oye n : integ er {sqlType (decima l)} +objectif_pro d : in tege r {sqlType (d ecimal)} +cond uite_elevage : strin g

+intitule : string

+id_lo t_anim aux : inte ger {prim aryKey (1)}

+type_cultu re : string

+id_type_culture : in teg er {primaryKey (1)}

+p lu viom etrie_annu elle _m oyenne : integer {sq lT yp e (de cim al)} +typ e_sol : string

+id_zone_pc : inte ger {prim aryKey (1)}

+type_unite : boolean {type (enum )} +unite : string

+id_u nite : integer {prim aryKey (1)}

+d ensite_prod uit : inte ger {sqlType (decim al)} +q uantite_ma tiere _active : integer {sq lT ype (de cim al)} +q uantite_type : boo le an

+libelle_pro duit : strin g +a pporte_exp orte : boolean +q uantite : inte ger {sqlType (decim al)}

+id_produit : integer {prim aryKe y (1)}

+operation _techniqu e : string

+id_o pera tion_te chnique : integer {prim aryKe y (1)}

+itineraire_te chnique : string

+id_cu lture : in tege r {primaryKey (1)}

+m odele : strin g

+id_mo dele : inte ger {p rima ryKey (1)}

+ma rque : string

+id _m arque : inte ger {prim aryKey (1)}

+annee _na issance : integer +formation_ecocon duite : bo olean +operateu r : string

+id _op erateur : in tege r {prim aryKey (1)}

+distance _pa rcou rue : integer {sq lT ype (decim al)} +te mps_mort_type : bo olean

+te mps_mort : integer +re gime_m oteu r : string +ordre_ta che : inte ger

+conso_energie_directe : integ er {sqlType (decim al)} +observations_tache : un define d {sqlTyp e (text)} +profon deur_travail : in tege r {sqlType (d ecimal)} +re gime_prise_fo rce : inte ger {sqlType (decim al)} +larg eur_travail : integer {sq lT yp e (de cim al)} +vitesse_travail_type : b oolean +vitesse_travail : integer {sq lT yp e (de cim al)} +etat_so l : bo olean {typ e (en um )} +te mps_total_pa sse_type : boo lean +te mps_total_pa sse : inte ger +surface_tra vaillee_type : bo olean +surface_tra vaillee : integer {sq lT ype (decim al)}

+id_tache : intege r {prim aryKe y (1)} +nb re_ar_pa rcelle_lc : integer +nb re_ar_pa rcelle_siege : in tege r

+du ree_totale_travail_estim ee : inte ger {sqlType (decim al)} +con so_en ergie_dire cte_m esu ree : integer {sq lT ype (de cim al)} +ob servations_tra vail : und efined {sqlT ype (te xt)} +plein_rese rvoir_fin : boo le an

+ou til_d etele : bo olean

+ou til_reto ur_hors_explo itation : b oolean

+distan ce_parco urue _hp _e stim ee : integer {sq lT ype (de cim al)} +releve _k ms_co mpteur_fin : in tege r {sqlType (d ecima l)} +com pteur_he ures_fin : inte ger {sqlType (decim al)} +da te_fin : un define d {sqlTyp e (da tetime)} +ou til_a tte le : b oolean

+ou til_p resent : b oolean

+releve _k ms_co mpteur_d ebut : intege r {sqlTyp e (de cimal)} +com pteur_he ures_debu t : integ er

+plein_rese rvoir_debut : boolea n +da te_deb ut : und efine d {sq lT ype (da tetim e)}

+id_travail : integer {prim aryKey (1)}

1 0..1 CemOA : archive ouverte d'Irstea / Cemagref

Annexe III

Étapes de la mise en place du projet :

Pour mettre en place la base de données ainsi que l'interface il sut de suivre les étapes suivantes :

• Télécharger et installer le serveur WAMP. http ://www.wampserver.com/ • Télécharger et installer Python 2.x. http ://www.python.org/download/

• Ajouter le dossier de Python (ex : c:\python26) dans les variables d'environnement de Windows. (si ça n'a pas été automatiquement fait lors de l'installation)

• Télécharger et installer le programme :

http ://www.technicalbard.com/les/MySQL-python-1.2.2.win32-py2.6.exe

Ce programme permettra d'int
grer MySql á Python et ainsi eectuer des opérations sur la base de données MySql á partir du code écris en Python.

• Intégrer Python à Apache (installé avec WAMP) :

 Télécharger le module WSGI (en choisissant la version qui correspond aux versions de Apache et de Python). http ://code.google.com/p/modwsgi/downloads/list

(ex : mod_wsgi-win32-ap22py26-3.0.so) ensuite le renommer en mod_wsgi.so puis le copier dans le dossier qui contient tout les modules de Apache.

(ex : C:\wamp\bin\apache\Apache2.2.11\modules)

 Modier le chier de conguration de Apache : httpd.conf situé dans le dossier de conguration de Apache (ex : C:\wamp\bin\apache\Apache2.2.11\conf), pour in-clure le module WSGI, en y ajoutant la ligne suivante :

LoadModule wsgi_module modules/mod_wsgi.so • Télécharger l'archive du Framework Django sur le site

http ://www.djangoproject.com/download/ (ex : Django-1.2.1.tar.gz) et le décompresser dans un dossier sur le disque local (la localisation de ce dossier n'ayant pas d'importance) (ex : c:\django)

• Installer Django :

 Exécuter la commande suivante dans le dossier où se trouve le Framework. (ex : c:\django)

> python setup.py install

 Ensuite ajouter le dossier où est installé Django (situé maintenant, dans les packages de Python) dans les variables d'environnement

(ex : C:\Python26\Lib\site-packages\django\bin)

• Créer un dossier où seront localisés les chiers source du projet (ex : c:\projet) • Inclure le projet dans le serveur apache installé avec WAMP :

 Dénir un dossier où sera localisé le projet (ex : c:\projet\interface_energetic)  Modier le chier django.wsgi inclus dans les chiers source de façon à ce que le

dossier indiqué dans la ligne suivante soit celui du projet. sys.path.append('c:/projet')

 Ajouter les lignes suivantes dans le chier de conguration de Apache modié précède-ment httpd.conf :

WSGIScriptAlias /energetic "c:/projet/interface_energetic/django.wsgi" <Directory "c:/projet"> Order deny,allow CemOA : archive ouverte d'Irstea / Cemagref

Allow from all </Directory> <Directory "c:/projet/interface_energetic/media/"> AllowOverride None Options None Order allow,deny Allow from all </Directory>

Alias /media/ "c:/projet/interface_energetic/media/"

 Ne pas oublier de changer les chemins (ex : c:/projet/interface_energetic/) en fonction de celles choisies lors de la mise en place des chiers source.

 Bien mettre des slash "/" au lieu des antislash "\" en ce qui concerne les chemins dans le chier httpd.conf

• Créer la base données prédénie dans les sources :

 Initialiser dans une base de données intitulée energetic_bdd (utiliser l'interface PhpMyAdmin pour cela)

 Exécuter la commande suivante en se positionant dans le dossier du projet. (ex : c:\projet)

> python manage syncdb

• Accéder à l'interface en allant, dans un navigateur, à l'adresse suivante : http://localhost/energetic CemOA : archive ouverte d'Irstea / Cemagref