Pub00033517 PDF

Rapport de stage
2me anne ISIMA

prsent par
Mariem ZAIRI
Sujet: Dveloppement dune base de

connaissances interactive ddie aux barrages
Sujet : Dveloppement dune base de
connaissances interactive ddie aux barrages
Responsable entreprise
: Stphan BERNARD
Responsable ISIMA
: Gilles LEBORGNE
Institut Suprieur d'Information de

Modlisation et de leurs Applications
Dure : 5 mois du 4 avril au 2 septembre 2011
Dveloppement dune base de connaissances interactive ddie aux barrage
REMERCIEMENTS
Mes remerciements s'adressent principalement mon matre de stage, Stphan
Bernard, pour mavoir accord sa confiance dans ce projet et pour toute l'aide quil m'a
apport afin de me permettre de mieux cerner le travail raliser tout au long du stage.
De mme, je remercie mon responsable l'ISIMA, Gilles Leborgne, pour son suivi et
son soutien au cours de ce stage.
Mes remerciements vont galement Madame Murielle Mouzat, ma professeure de
communication pour m'avoir appris la bonne dmarche pour la ralisation d'un rapport et
d'une prsentation orale.
Enfin, merci toute lquipe TSCF, pour son accueil, sa disponibilit et sa bonne
humeur permanente.
RSUM ET ABSTRACT
RSUM
Depuis plusieurs annes, des recherches visant capitaliser la connaissance sur le
comportement des barrages sont ralises au CEMAGREF dAix-en-Provence. Ces travaux
ont pour but de dvelopper des mthodes daide lexpertise en complment aux mthodes
mcaniques pour valuer la sret de fonctionnement des barrages en service.
Dans la ligne des prcdents travaux raliss, qui ont permis dobtenir les diffrents
scnarios de vieillissement des barrages, mon travail a consist dvelopper une base de
connaissances interactive sur les pathologies des barrages.
Cette base de connaissances a pour but de structurer le maximum d'informations sur
les barrages, permettant ainsi ses utilisateurs de mieux en comprendre les diffrents
mcanismes de rupture et de dgradation.
Ce projet propose une solution pour stocker les informations de chaque barrage dans
une base de donnes, une visualisation par le biais d'une interface Web et une gestion des
droits daccs par un systme d'authentification.
Mots cls : Barrage, vieillissement, dgradation, interface Web, base de donnes
ABSTRACT
Research about knowledge capitalization for embankment dams behavior have been
conducted for many years in Cemagref, a public research institute, at its center based at Aixen-Provence. The goals of these works are on one hand to develop expertise assistance
methods, in addition to reliability mechanics methods, and on the other hand to assess
embankment dams operational safety methods.
To complete anterior researches, from which different embankment dams aging
scenarios have been obtained, my work consisted in the development of an interactive
knowledge database for embankment dams pathology.
This knowledge base is to structure the maximum amount of information on dams and
allow its users to have better understanding of the different failure mechanisms and
degradation of dams.
This project suggests a solution to store information for each dam in a database,
visualizing them through a web interface with the management of access rights thru an
authentication system.
Keywords : Dam, aging, degradation, web interface, database
TABLE DES FIGURES ET ILLUSTRATIONS

Illustration 1: Interactions entre le modle, la vue et le contrleur.........................................5
Illustration 2: Donnes d'un barrage.....................................................................................13
Illustration 3: Schma relationnel des Caractristiques physiques simples d'un barrage......14
Illustration 4: Schma relationnel des Caractristiques physiques multiples d'un barrage....15
Illustration 5: Schma UML des incidents............................................................................17
Illustration 6: Schma relationnel des incidents....................................................................18
Illustration 7: Exemple des actions correctives.....................................................................19
Illustration 8: Schma relationnel des actions correctives....................................................20
Illustration 9: Arborescence des actions correctives............................................................20
Illustration 10: Schma simplifi du fonctionnement des widgets........................................22
Illustration 11: Schma relationnel des notes .......................................................................23
Illustration 12: Table des permissions...................................................................................24
Illustration 13: Table des groupes.........................................................................................24
Illustration 14: Architecture simplifie de l'application........................................................26
Illustration 15: Authentification............................................................................................27
Illustration 16: Page d'accueil...............................................................................................28
Illustration 17: Page d'affichage d'un barrage.......................................................................29
Illustration 18: Ajout d'un incident.......................................................................................30
Illustration 19: Ajout d'une mesure.......................................................................................31
Illustration 20: Ajout d'un mdia..........................................................................................32
Illustration 21: Affichage du mdia......................................................................................33
Illustration 22: Ajout d'une tude hydrologique....................................................................33
Illustration 23: Page d'identification / Aperu de la logique de l'interface............................34
Illustration 24: Chronogramme.............................................................................................37
TABLE DES MATIRES

Introduction............................................................................................................................ 1
I. Prsentation du contexte de stage........................................................................................2
1. Prsentation de l'organisme daccueil : le Cemagref de Clermont-Ferrand ...................2
2. Prsentation du l'organisme client : le Cemagref d'Aix en Provence..............................2
II. Projet.................................................................................................................................. 4
1. Besoin des experts..........................................................................................................4
1.1. Cahier des charges..................................................................................................4
1.2. tude du cahier des charges....................................................................................4
2. Choix technologique......................................................................................................4
2.1. La Mthode Modle-Vue-Contrleur (MVC).........................................................5
2.1.1. Le modle .......................................................................................................5
2.1.2. La vue..............................................................................................................6
2.1.3. Le contrleur....................................................................................................6
2.2. From Scratch, Framework ou CMS ?......................................................................6
2.2.1. Codage From Scratch.......................................................................................6
2.2.2. Utilisation d'un CMS.......................................................................................6
2.2.3. Utilisation d'un Framework.............................................................................7
2.3. Solution retenue......................................................................................................7
2.3.1. Comparatif des principaux framework PHP....................................................8
2.3.2. Choix final.....................................................................................................10
2.4. Comparatif des deux ORM...................................................................................12
3. Ralisation de lapplication .........................................................................................13
3.1. Schma relationnel................................................................................................13
3.1.1. Caractristiques physiques.............................................................................13
3.1.2. Les vnements..............................................................................................16
a. Les incidents................................................................................................16
b. L'hritage....................................................................................................17
c. Les actions correctives................................................................................18
d. Les Widgets.................................................................................................22
3.1.3. Notes.............................................................................................................. 23
4. Gestion des utilisateurs.................................................................................................24
5. Estimation de la volumtrie de la base de donne........................................................25
6. Prsentation de l'application.........................................................................................25
6.1. Fonctionnement gnral........................................................................................25
6.2. Front-end............................................................................................................... 26
6.3. Back-end...............................................................................................................34
III. Rsultats.........................................................................................................................35
1. Rsultat obtenu.............................................................................................................35
2. Amlioration future......................................................................................................35
IV. Bilan............................................................................................................................... 36
1. Difficults rencontres.................................................................................................36
2. Apport pour l'entreprise................................................................................................36
3. Bilan personnel............................................................................................................. 36
Conclusion............................................................................................................................ 38
Glossaire............................................................................................................................... 39
Rfrences Bibliographique..................................................................................................41
INTRODUCTION
Des accidents lis aux dgradations des barrages, due au vieillissement de ces derniers,
une mauvaise conception ou encore laction de lhomme, peuvent se produire et
entraner la rupture de ces ouvrages. Par ailleurs, cette rupture peut avoir des consquences
humaines, conomiques ou encore environnementales non ngligeables.
Ainsi, il est donc ncessaire de produire des mthodes et des outils permettant de
matriser la scurit des ouvrages hydrauliques, afin de pouvoir dterminer la fiabilit de ces
derniers.
Parmi diffrentes mthodes possibles, certains travaux reposent sur lexpertise de ces
ouvrages, et plus prcisment sur la formalisation des dires dexperts dans le but dvaluer
la performance globale du barrage et sa sret de fonctionnement. Ces travaux sont raliss
pour permettre de vrifier que les barrages sont dans un tat de scurit satisfaisant, et si ce
nest pas le cas, d'effectuer des actions correctives pour rhabiliter ces ouvrages.
La thmatique de mon stage que j'ai effectu au sein du Cemagref de ClermontFerrand, sinscrit dans ce contexte de formalisation des dires dexperts afin de pouvoir,
bnficier d'un outil permettant d'valuer la performance dun barrage vis--vis de diffrents
modes de rupture dj constats. Le dveloppement dune base de connaissances interactive
des barrages permet entre autres de rassembler en un seul outil un certain nombre de
connaissances, de pouvoir faire une interrogation guide des informations stockes et de
fixer une terminologie commune concernant les phnomnes de dgradations des fonctions
de ces ouvrages.
Pour commencer, ce rapport prsente une synthse du contexte professionnel.
Elle est suivie d'une partie plus technique. Je commencerai par prsenter la partie
analyse du projet, puis les choix technologiques, et enfin le dveloppement de l'application.
Ce rapport se terminera par une conclusion de ce stage, comment je lai ressenti, une
explication des diffrents problmes rencontrs et un bilan personnel.
M. Zairi
I. PRSENTATION DU CONTEXTE DE STAGE

1. Prsentation de l'organisme daccueil : le Cemagref de ClermontFerrand
tablissement public caractre scientifique et technologique, cre en 1981, le Centre
national dtudes sur le Machinisme Agricole, le Gnie Rural, les Eaux et Forts
(CEMAGREF) se concentre sur l'ingnierie de l'agriculture et de l'environnement. Il dpend
du Ministre de l'agriculture et du Ministre de la recherche.
Les activits du Cemagref sont regroupes au sein des 3 dpartements de recherche qui
portent sur leau, les cotechnologies et les territoires ; son organisation comprend un ple
recherche et innovation ainsi quun ple soutien la recherche.
Le CEMAGREF de Clermont-Ferrand accueille 3 Units de Recherche et d'Expertise
(URE) :
DFCF : Dynamiques et Fonctions des espaces ruraux
TSCF : Technologies, Systmes d'information et procds pour l'agriculture et
l'agro-alimentaire
LISC : Laboratoire d'Ingnierie des Systmes Complexes
Pour ma part, jai t accueillie au sein de lquipe COPIN de TSCF qui est compos d'une
soixantaine d'agents du Cemagref pour raliser une application propose par le
CEMAGREF d'Aix en Provence.
Le stage a t effectu au Cemagref de Clermont-Ferrand. En effet, lquipe TSCF travaille
sur le systme d'information tandis que le Cemagref d'Aix sont spcialiss dans les barrages.
2. Prsentation du l'organisme client : le Cemagref d'Aix en Provence

Le Centre d'Aix-en-Provence est l'un des dix groupements du Cemagref, tablissement
public caractre scientifique et technologique (EPST). Les activits de recherche et
d'expertise sont conduites par les Units de Recherche (UR) comptence nationale. Les
quatre Units de Recherche d'Aix-en-Provence travaillent principalement dans deux
domaines : l'eau et les espaces ruraux.
Eau
Ur Ouvrages hydrauliques et hydrologie : Scurit des ouvrages hydrauliques et hydrologie
Ur Hydrobiologie : Structuration et fonctionnement biologiques des cours d'eau
quipe LERM : Performances et impact environnemental de l'irrigation
M. Zairi
Espaces ruraux
Ur cosystmes mditerranens et risques : Dynamique des espaces agricoles et forestiers,
notamment en zone pri-urbaine, risques lis aux feux de fort
M. Zairi
II. PROJET
1. Besoin des experts
1.1. Cahier des charges
Actuellement, les connaissances explicites sur la conception-ralisation et les modes
de rupture et dgradation des barrages sont nombreuses mais disperses. Elles prsentent en
outre des formats diffrents tels que des textes, des photographies ou des vidos. Il est donc
intressant de rassembler, capitaliser et expliciter les connaissances actuelles et futures. Les
experts souhaitent donc avoir une base de connaissances ddie aux barrages et axe plus
particulirement sur leur conception et leur ralisation ainsi que leurs modes de rupture et de
dgradation. Lexistence dune telle base de connaissances a plusieurs intrts et permet de :
Capitaliser les connaissances, les rassembler en un seul outil et enrichir cet outil au
fur et mesure de la cration de nouvelles connaissances.
Constituer un outil de formation : elle permet par exemple un utilisateur de trouver
des dfinitions, elle aide la formation dun jeune expert.
Produire un outil de documentation : elle permet alors un utilisateur de se rfrer
un barrage qui aurait subi un mme dsordre ou daccder une prconisation
daction corrective.
Faciliter la communication entre les utilisateurs notamment par la dfinition dun
vocabulaire commun. Cet outil de communication peut tre usage interne dun panel
dexperts dialoguant sur un mme problme mais aussi usage externe entre un
animateur non expert et un groupe dexperts.
1.2. tude du cahier des charges

Le cahier des charges tant trs permissif, il fallait plutt se fixer des limites, ou tout
du moins, avoir une ide plus prcise de ce que serait l'application.
C'est pour cela qu' partir de ce cahier des charges, j'ai ralis des croquis pour
prsenter mes ides mon tuteur d'une manire plus visuelle. C'est ainsi que certains points
ont t amliors. Comme par exemple la page daccueil ou ldition des incidents.
2. Choix technologique
La premire question qui s'est pose pour la ralisation de la partie technique du projet
t de choisir une architecture pour l'application.
M. Zairi
2.1. La Mthode Modle-Vue-Contrleur (MVC)

Le MVC est une architecture et une mthode de conception qui organise l'Interface
Homme-Machine d'une application logicielle (dans notre cas un site Web) en trois parties :
Les donnes (Modle).
Linterface home-machine (Vue).
La logique de contrle (Contrleur).
Grossirement, cela permet une sparation entre les traitements de donnes et la
prsentation.
Illustration 1: Interactions entre le modle, la vue et le contrleur
2.1.1. Le modle
Le modle reprsente les structures de donnes. Typiquement, les classes modles
contiennent des fonctions qui aident rcuprer, insrer et mettre jour des informations de
la base de donnes.
M. Zairi
2.1.2. La vue
La vue correspond l'interface avec laquelle l'utilisateur interagit. Elle se prsente
sous la forme d'un template reprsentant l'interface, mais sans les donnes.
2.1.3. Le contrleur
Il gre l'interface entre le modle et le client. Il va interprter la requte de ce dernier
pour lui envoyer la vue correspondante. Il effectue la synchronisation entre le modle et les
vues.
2.2. From Scratch, Framework ou CMS ?

Les trois grandes possibilits existantes pour raliser ce type de site Web sont : le
codage from scratch , c'est dire en partant de zro, l'utilisation d'un CMS ou l'utilisation
d'un framework.
2.2.1. Codage From Scratch

Le codage from scratch consiste programmer une application du dbut jusqu' la
fin. Cette solution t immdiatement abandonne, car elle est trop lourde et longue
dvelopper, et rendue totalement inutile grce la quantit de framework et CMS open
source mise disposition par l'norme communaut de dveloppeurs Web sur internet.
2.2.2. Utilisation d'un CMS

Un CMS est un systme de gestion de contenu. C'est un site Web dj ralis qu'il faut
ensuite adapter ses propres besoins. Les fonctions incontournables d'un CMS sont :
Sparation entre contenu et prsentation (systme de templates).
dition de page simplifie par diteur WYSIWYG.
Gestion des droits.
Utilisation d'interface Web d'administration (back-end) pour la gestion du contenu.
Systme de plug-ins ou greffons.
Le CMS semble donc offrir beaucoup d'avantages en fournissant une plate-forme prte
l'emploi et modulaire. La plupart des CMS disposent d'normment de fonctionnalits,
comme un forum, un systme de commentaires, et beaucoup de fonctionnalits dites Web
2.0 , c'est--dire communautaires.
M. Zairi
2.2.3. Utilisation d'un Framework

Un framework ou kit de dveloppement est un espace de travail modulaire, c'est dire
une suite d'outils et de bibliothques qui facilitent et acclrent le dveloppement d'un
logiciel. Il contient toutes les fonctions de base utiles au dveloppement d'un type de
programme, et permet donc de ne pas avoir besoin de r-crire les mmes fonctions
chaque programme cr. Il en existe dans tous les langages de programmation.
Cette solution est mi chemin entre le codage from scratch et l'utilisation d'un
CMS. En effet, l'utilisation d'un framework n'interdit pas le codage, bien que certains
comme Ruby on Rails ont des fonctionnalits de gnration automatique de code.
Parmi les frameworks Web, je me suis plus particulirement intresse aux
frameworks Web PHP. Dans leur grande majorit, ils sont conus sur le modle MVC, ce
qui permet de structurer les donnes. Ils imposent un cadre et des normes de dveloppement
qui permettant une programmation propre et modulaire.
De plus, depuis la version 5 de PHP, qui introduit la Programmation Oriente Objet
(POO), il est beaucoup plus facile et intuitif de programmer des systmes modulaires.
2.3. Solution retenue

La solution retenue a t de dvelopper la base de donnes interactive l'aide d'un
framework, et ceci pour plusieurs raisons :
Un CMS n'est pas adapt pour le genre de base de donnes interactive que souhaite les
experts du Cemagref.
En effet, l'application a raliser n'est pas un site public ouvert tout le monde, c'est
dire que la plupart des fonctionnalits d'un CMS ne seraient que fioriture. Et dans
l'hypothse o l'on utiliserait un CMS, il faudrait dsactiver ces fonctionnalits, et donc
modifier directement le code source.
La lenteur d'accs aux bases de donnes qui est visible surtout l'affichage des pages
est un grand inconvnient d'un CMS.
L'application reprsentera les barrages et des donnes confidentielles, il est alors exclu
d'utiliser des lments pr-construits que l'on peut retrouver sur d'autre sites.
L'utilisation d'un CMS semble donc difficile, car il faudrait tout transformer.
En revanche, l'utilisation d'un framework implique le dveloppement sur-mesure de
tous les lments du site l'aide de fonctions relativement simples. L'apprentissage au
dveloppement avec un framework apparat plus simple qu'avec un CMS.
C'est pourquoi, j'ai dcid d'utiliser un framework pour le dveloppement de
l'application.
M. Zairi
2.3.1. Comparatif des principaux framework PHP

Il existe de nombreux framework PHP open-source, c'est dire gratuits, librement
modifiables et distribuables. J'ai test et tudi les plus connus pour trouver le plus adapt.
Zend Framework
Zend Framework est un cadre de dveloppement pour PHP5, orient objet, cr par
Zend. Zend tant le crateur du langage PHP, cela lui confre une grande crdibilit. Ses
principales fonctionnalits sont :
Scurit : systme de protection contre les attaques par injections SQL et des attaques
de types cross-site-scripting (XSS).
Sparation du code en trois couches MVC.
URL simples et claires.
Architecture du cur mme de framework totalement modulaire, c'est dire que l'on
peut inclure uniquement les fonctionnalits dont on a besoin.
Grce cela et la grande communaut de dveloppeurs, le Zend Framework
bnficie de beaucoup de fonctionnalits comme un systme de template, un systme de
cache, plusieurs implmentations d'AJAX, accs des sources de donnes diverses et
beaucoup d'autres.
Ce framework est surtout destin aux sites forte charge et aux dveloppeurs web de
mtier qui peuvent se permettre de passer des semaines le prendre en main.
Symfony
Symfony est un Framework MVC open-source crit en PHP 5, donc orient objet. Ses
principales fonctionnalits sont :
Une sparation du code en trois couches, selon le modle MVC.
Un systme de template volu.
Des performances optimises et un systme de cache pour garantir des temps de
rponse optimums.
Une gestion des url parlantes, qui permet de formater l'url d'une page indpendamment
de sa position dans l'arborescence fonctionnelle.
Un systme de configuration en cascade qui utilise de faon extensive le langage
YAML8.
M. Zairi
Un gnrateur de back-office.
Un systme de gestion de langue (pour internationaliser un site).
Une couche de mapping objet-relationnel (ORM) et une couche d'abstraction de
donnes.
Le support de l'Ajax.
Une architecture extensible, permettant la cration et l'utilisation de plugins.
Symfony semble le framework le plus volu. Son gnrateur de back-office et son
systme de configuration par langage YAML, l'instar de Ruby on Rails est
particulirement intressant.
Il semble une trs bonne alternative Zend, disposant des fonctions quivalentes celui-ci
mais plus simple matriser de par sa conception. Sans oublier la gnration automatique de
code-source par fichier de configuration YAML. De plus, malgr son jeune ge, il est fiable
et prouv.
Copix
Copix est un framework pour le langage PHP dvelopp par une communaut de
dveloppeurs franais. Il est construit en cinq couches : coordination, services, domaines,
persistance et prsentation. Ses principales fonctionnalits sont :
Un gestionnaire de langue (internationalisation).
Un systme simple et complet de rewriting d'URL.
Des DAO automatiques permettant l'accs aux donnes par de multiples moyens.
Un systme de modules pour dcouper une application en plusieurs sous-systmes
facilement exportables.
Un systme de cache.
Un systme de template.
Le modle en cinq couches de Copix semble plus complexe et moins naturel que le
modle MVC. De plus, par certains aspects, Copix (notamment son back-end) se
rapprochent plus d'un CMS que d'un rel Framework.
M. Zairi
2.3.2. Choix final

Aprs une trs forte hsitation entre le Zend Framework et Symfony, j'ai dcid
d'utiliser Symfony, tant sduite par ses philosophies : rendre le PHP beaucoup plus
confortable, l'AJAX plus abordable, l'optimisation du rfrencement (url rewriting) plus
simple, l'internationalisation (i18n) triviale.
M. Zairi
10
Fonctionnement de symfony
Larborescence dune application Symfony sur le serveur Web se prsente de la
manire suivante :
Mon_Projet
- apps : Ensemble des applications Symfony
o mon_appli : Application Symfony
i18n : Dossier de traduction
modules : Liste des modules
mon_module
o actions : Actions du module (Contrleur)
o templates : Templates du module (Vue)
- cache : Fichiers mis en cache
- config : Fichiers de configuration
o doctrine : Type dORM (Information dans la page suivante)
schema.yml : Fichier de configuration de la base de donnes
- data : Donnes insres dans la base
o fixtures : Insertion des donnes par dfaut
o sql : Scripts de cration de BD
- lib : Librairie de lapplication
o filters : Configuration des filtres de recherche
o forms : Configuration des formulaires
o model : Classes PHP correspondantes la BD
- log : Fichiers des logs de lapplication
- test : Fichiers des tests unitaires et fonctionnels
- web : Fichiers utiles pour le rendu
o css : Feuilles de style
o images : images de lapplication
o js : Scripts javascript
o uploads : Dossier de sauvegarde des documents uploads
o index.php : Fichier charg par le serveur web
Le dveloppement de lapplication sest fait en deux temps : lapprentissage de

Symfony et le dveloppement de lapplication.
Lapprentissage sest fait grce au tutoriel prsent sur le site du framework. Ce tutoriel
prsente une vue globale des fonctionnalits de Symfony.
Le premier choix faire pour le dveloppement a t celui du mapping des objets
relationnels (ORM). Ce mapping permet de faire une correspondance entre la base de
donnes relationnelle et les objets du langage.
M. Zairi
11
2.4. Comparatif des deux ORM

ORM (Object Relational Mapping) est une technique de programmation informatique
qui cre l'illusion d'une base de donnes oriente objet partir d'une base de donnes
relationnelle.
Symfony se base sur l'un ou l'autre des deux principaux ORM du langage PHP :
Doctrine et Propel. Ils ont des fonctionnalits quasi identiques. Ils possdent tous les deux
des oprations CRUD (Oprations de base : Create, Read, Update, Delete). Les deux
peuvent gnrer le code des classes PHP. Cependant Propel est bas sur XML alors que
Doctrine est bas sur YAML. Pour la rdaction des requtes, Propel utilise lapproche
Criteria/peer alors que Doctrine utilise un langage driv de SQL (le DQL).
Exemple de requte (Rcupration du Barrage N 5) dans les deux ORM :
Sous Propel :
$b = new Criteria();
$b->add(BarragePeer::ID, 5);
$items = BarragePeer::doSelect($b);
Sous Doctrine :
$items = Doctrine_Query::create()
->from('Barrage b')
->where('b.id = ?', 5)
->execute();
La solution propose par Doctrine est donc plus facile interprter que celle de Propel.
Laffectation de valeurs aux attributs est diffrente. Propel gnre tous les accesseurs alors
que Doctrine utilise des proprits magiques . Donc la solution de Propel prsente
lavantage dtre compatible avec la majorit des outils de dveloppement comme Eclipse.
Malgr cet inconvnient, Doctrine possde une bonne documentation et lcriture du
modle est plus facile avec le format YAML que le format XML sans outil supplmentaire.
C'est pourquoi j'ai choisi Doctrine pour mon application.
Une fois le modle dORM choisi, il faut implmenter la base de donnes, donc
rdiger le fichier YAML. La structure de schma est trs importante pour l'affichage de
l'application car certaines pages sont automatiquement gnres avec le schma relationnel.
Quand cette tape est termine, le codage de lapplication peut commencer.
M. Zairi
12
3. Ralisation de lapplication
3.1. Schma relationnel
Un barrage a des caractristiques physiques, peut subir des vnements tels que des
incidents ou des actions correctives. Chacun de ces lments, dcrit dans la base de donnes,
peut tre enrichi l'aide de fichiers texte ou de fichiers multimdias.
Caractristiques physiques :
- Hauteur
- Matriaux
- Type ...
Notes :
- Documents textes
- Fichiers multimdia
vnement :
- Incidents
- Actions correctives
Illustration 2: Donnes d'un barrage
3.1.1. Caractristiques physiques

Un barrage possde des caractristiques physiques simples et d'autres multiples :
Caractristiques physiques simples
Les caractristiques physiques simple d'un barrage sont les types de donnes uniques.
Par exemple :
Le pays (un barrage ne peut appartenir qu' un seul pays).
Le type (un barrage ne peut tre que d'un seul type la fois).
Hauteur maximale par rapport au terrain naturel.
La capacit.
Le superficie.
M. Zairi
13
La longueur.
Ainsi que d'autre donnes importantes pour son dimensionnement. J'ai choisi
l'enregistrement de tout ces derniers dans une seule table persa_barrage .
Illustration 3: Schma relationnel des Caractristiques physiques simples d'un barrage
persa_type_evacuateur , persa_pays et persa_type sont des tables en relation

OneToMany avec la table persa_barrage . Cela permet que les attributs correspondants
dans la table persa_barrage aient des valeurs appartenant une liste prdfinie. Cette
liste peut en outre tre facilement enrichie au cours du temps.
M. Zairi
14
Caractristiques physiques multiples

Un barrage a aussi des caractristiques physiques multiples. En effet, il peut tre
construit avec plusieurs matriaux, possder plusieurs dispositifs de mesure, diffrentes
natures de fondations et beaucoup d'autre caractristiques physiques.
Toutes ces caractristique sont en relation ManyToMany avec la table persa_barrage .
Cela permet aux utilisateurs de lapplication d'avoir des listes droulantes choix multiple.
Illustration 4: Schma relationnel des Caractristiques physiques multiples d'un barrage

M. Zairi
15
3.1.2. Les vnements

Les vnements que peut subir un barrage sont des incidents lis des dgradations ou
des phnomnes naturels. Ces incidents peuvent tre traits par un ensemble d'actions
correctives.
a. Les incidents
Un barrage peut avoir subi un ou plusieurs incidents. Chaque incident peut tre li
une ou plusieurs sources qui dsignent les origines de l'incident, et avoir une ou plusieurs
consquences qui participent la dgradation et deviennent elles-mmes des incidents. De
plus, il y a deux types de modes de rupture d'un barrage. En effet, lincident peut tre li
des phnomnes naturels ou la conception-ralisation du barrage.
Cas 1 : Incident li une source
Si l'utilisateur de l'application souhaite ajouter un incident de type source, il doit avoir
le choix du type de mode de dgradation : Phnomne ou Conception-Ralisation
Cas 2 : Incident li une consquence
Si l'utilisateur choisit d'ajouter un incident de type consquence, le mode de
dgradation est forcment de type Phnomne.
Pour raliser cela, j'ai d'abord tudi une solution de type ManyToMany mais cette
solution a t vite abandonne, car en l'utilisant, le type de mode de dgradation tait
dupliqu pour chaque catgorie.
Catgorie A Phnomne Type 1
Catgorie A Conception-Ralisation Type 2
Catgorie B Phnomne Type 3
Catgorie B Conception-Ralisation Type 4
On voit bien que pour chaque catgorie il y a deux sous-catgories Phnomne et
Conception-Ralisation. Il y aura une redondance des donnes.
Lhritage est donc la meilleure solution pour grer cette situation.
M. Zairi
16
b. L'hritage
Schma Uml des incidents
Pour viter la redondance des informations dans la base de donnes on utilise
lhritage :
Catgorie type incident
1..n
0..1
1..n
Type incident
Phnomene
Concption-Ralisation
1..n
0..1
0..1
Consquence
1..n
0..1
Incidents
1..n
0..1
Source
Illustration 5: Schma UML des incidents
Phnomne et Conception-Ralisation sont deux tables filles qui hritent de la

classe mre Type incident .
La table Consquence est une table intermdiaire entre Phnomne et
Incidents . Comme tous les incidents de type consquence ont un mode de rupture de
type Phnomne, il n'y a aucune utilit de les relier avec la table Type incident .
La table Source est aussi une table intermdiaire mais elle est relie directement
la classe mre. Ici, l'utilisateur doit pouvoir choisir entre les deux tables filles.
La table Catgorie type incident est en relation OneToMany avec la table type
incident . Elle permet de stocker toutes les catgories d'un incident.
Schma relationnel des incidents
Symfony intgre trois stratgies diffrentes pour grer les hritages de table selon les
besoins de l'application en termes de performance, d'atomicit, d'efficacit ou bien encore de
simplicit. Ces trois stratgies natives sont lhritage simple, l'hritage par agrgation de
colonnes et l'hritage concret.
M. Zairi
17
Pour mon application, j'ai choisi lhritage par agrgation de colonne. Cet hritage
stocke toutes les colonnes, y compris celles des tables filles dans la table mre (ici
type_incidents ) ainsi qu'une colonne type pour identifier les diffrents types
d'enregistrement. Par consquent, lorsqu'un enregistrement persiste en base de donnes, une
valeur est affecte cette colonne afin de dterminer quelle classe il appartient.
Ici les deux tables filles sont reprsentes par la variable type de table
type_incident .
Illustration 6: Schma relationnel des incidents
c. Les actions correctives

Il peut y avoir plusieurs actions correctives pour un incident. Les actions correctives
doivent tre associes l'incident concern :
Exemple :
Incident pathologie n1
Action corrective associe n1
Action corrective associe n2
Incident pathologie n2
Action corrective associe n1...
M. Zairi
18
De plus, on a une structure arborescente trois niveaux : catgories, sous-catgories et

type d'action corrective. Pour grer cette arborescence j'ai utilis deux relations de type
OneToMany.
Cependant certaines actions sarrtent au niveau 2 (pas de type d'action corrective) il
fallait donc grer ceci avec un boolen.
L'illustration suivante reprsente l'arborescence des actions correctives. En effet
chaque lment de catgorie peut avoir un ou plusieurs lments de sous catgorie et de
mme pour ce dernier qui peuvent avoir aucun ou plusieurs type d'action corrective.
Illustration 7: Exemple des actions correctives
Schma relationnel des actions correctives

La table categorie_action_corrective contient toute les catgories d'action
corrective. Chaque lment de cette table est reli au moins un lment de la table
sous_categorie_action_corrective . De mme pour les lments de la table
sous_categorie_action_corrective qui ont une relation OneToMany avec les lments de
la table type_action corrective .
M. Zairi
19
Illustration 8: Schma relationnel des actions correctives
Le schma relationnel prcdent permet de stocker une arborescence trois niveaux

comme le montre le schma suivant.
sous_catgorie_action_corrective
catgorie_action_corrective
lment 1
lment 2
lment 3
lment 1.1
lment 1.2
lment 1.3...
lment 2.1
lment 2.2...
lment 3.1
lment 3.2
type_action_corrective
lment 1.1.1
lment 1.1.2
lment 1.2.1
lment 1.3.1
lment 2.1.1
lment 3.1.1
lment 3.1.2
lment 3.1.3
lment 3.2.1
Illustration 9: Arborescence des actions correctives

M. Zairi
20
Pour des raisons de fonctionnalits, l'affichage des relations ManyToMany propos par
Symfony via des widgets ne convenait pas notre application. Symfony affiche les relations
ManyToMany avec des listes droulantes choix multiple qui contient tout les types.
Cependant nous voulions une liste droulante trois niveaux. Il a donc fallu crer des
widgets personnaliss.
M. Zairi
21
d. Les Widgets
Le framework de formulaire de symfony est livr avec un lot de widgets utiles qui
fournissent les fonctionnalits de base. Cependant, pour afficher les champs d'un formulaire
particulier, il est ncessaire dvelopper des widgets personnaliss.
BDD
getTypes ()
P
H
Mon_Widget(){
P
...
}
JavaScript
Function selectChanged()
{
select1.hide();
select2.show();
}
Genre
HTML
onChange()
Illustration 10: Schma simplifi du fonctionnement des widgets
Le code PHP gnre le code HTML des diffrentes listes afficher partir de la base
de donnes. Le JavaScript affiche ou cache les listes droulantes en fonction de la slection
de l'utilisateur.
M. Zairi
22
3.1.3. Notes
En plus des diffrentes caractristiques physiques et des divers vnements qui
peuvent concerner un barrage, son tude peut tre enrichie par un ensemble de documents
jugs utiles par les experts, tels que des fichiers texte ou multimdia.
Chaque barrage et chaque incident peut tre reli un ensemble de photos, des
documents PDF voire mme des vidos.
Les utilisateurs de l'application auront la possibilit d'associer des fichiers leurs
barrages leurs incidents, mais aussi d'attacher des fichiers multimdias la page
daccueil.
La table multimdia persa_media est en relation ManyToMany avec la table des
barrages persa_barrage : un barrage peut avoir un ou plusieurs fichiers mdia et un
fichier mdia peut tre reli un ou plusieurs barrages en mme temps. Il en est de mme
pour les incidents.
Illustration 11: Schma relationnel des notes

M. Zairi
23
4. Gestion des utilisateurs

Pour dfinir les utilisateurs, j'ai utilis sfDoctrineGuardPlugin qui est le plugin
utiliser pour la gestion des utilisateurs de Symfony.
Il comporte des formulaires didentification et dinscription trs basiques, mais son
principal point fort est la gestion des droits associs aux utilisateurs et la possibilit de grer
des groupes.
Le modle de donnes du plugin comporte la table des Utilisateurs, des Groupes et des
Permissions ainsi que les tables dassociations entre les Utilisateurs et les Permissions, les
Groupes et les Permissions et les Utilisateurs et les Groupes.
Pour mon application, on a 6 types de permissions pour 3 groupes d'utilisateurs
Nom
Description
Permission_admin
Permission administrateur
Permission_create
Permission de cration de fiche
Permission_update
Permission de mise jour de ses propres fiches
Permission_update_all
Permission de mise jour des fiches de tout le monde
Permission_validate
Permission de valider ses propres fiches
Permission_validate_all
Permission de valider les fiches de tout le monde

Illustration 12: Table des permissions
Nom du groupe
Description
Permission du groupe
Group_admin
Groupe
administrateur
Permission_admin, Permission_create,
Permission_update, Permission_update_all,
Permission_validate, Permission_validate_all
Group_expert
Groupe expert
Permission_create, Permission_update,
Permission_update_all, Permission_validate
Group_prof
Groupe professeur
Permission_create, Permission_update
Illustration 13: Table des groupes

M. Zairi
24
5. Estimation de la volumtrie de la base de donne

Les experts barrages ont expliqu que l'application n'enregistra pas plus de 50
barrages. Pour tester la monte en charge de la base de donnes, j'ai enregistr 1000
barrages. L'enregistrement de ces dernier n'a occup que 0,4063 Mga-Octet de plus.
On peut en conclure qu'il n'y aura aucun problme de taille dans le futur.
6. Prsentation de l'application
6.1. Fonctionnement gnral
Voir Illustration 14 : Architecture simplifie de l'application, page 26.
Fichier HTML
Le format HTML (Hypertext Markup Language soit langage de balisage dhypertexte
en franais) contient le contenu et la structure de la page Web. C'est le fichier qui sera
rcupr par le navigateur, puis lu. Aprs cette lecture, le navigateur charge les fichiers
annexes comme les fichiers CSS, JS, les images, etc. Le format XHTML est bas sur
l'XML.
Fichier CSS
Le format CSS (Cascading Style Sheets ou feuilles de style en cascade en franais) sert
dcrire la prsentation des documents HTML et XML. C'est ce fichier qui gre le
positionnement du contenu, les couleurs, polices, etc.
Fichier JS
Les fichiers JS contiennent du code Java Script qui est excut sur le navigateur du
client. Le Java Script permet de modifier le contenu des fichier HTML, de modifier les
rgles CSS (ce qui permet de crer des animations), mais aussi de rcuprer des donnes via
des requtes AJAX.
Fichier TPL
Les fichiers de template correspondent aux vues du modle MVC, ils contiennent des
morceaux de code XHTML avec des instructions spcifiques comprises par le moteur de
template charg de fusionner la vue aux modles (donnes). Ses vues sont ensuite associes
par le contrleur pour obtenir le fichier HTML final de la page.
M. Zairi
25
Fichier PHP
Ces fichiers contiennent du code PHP. PHP (acronyme rcursif pour PHP : Hypertext
Preprocessor), est un langage de scripts libre principalement utilis pour la gnration de
fichiers HTML dynamiques. Le serveur web utilise l'interprteur PHP pour gnrer les
pages HTML via PHP qu'il envoie ensuite au client.
Illustration 14: Architecture simplifie de l'application
6.2. Front-end
Ici je vais vous dtailler les diffrentes fonctionnalits de linterface web. Vous pouvez
voir ci-dessous la page de connexion de l'application.
M. Zairi
26
Illustration 15: Authentification
Cette page (Illustration 15) permet l'identification d'un utilisateur grce un login et
un mot de passe. L'utilisateur est oblig de se connecter si il souhaite accder aux autres
pages et fonctionnalits de l'application.
Une fois lauthentification russie, lutilisateur est redirig automatiquement vers la
page affichant tous les barrages qui sont rpertoris dans la base de donnes et tris par type.
Cependant, ces droits changent d'un utilisateur un autre. En effet, certains utilisateurs ont
le droit de voir ou de modifier la liste des barrages et d'autres non.
M. Zairi
27
Illustration 16: Page d'accueil
Depuis la page daccueil lutilisateur pourra donc afficher les dtails d'un barrage et
selon ses droits. Il pourra modifier ou supprimer un barrage qui est enregistr dans la base
de donnes.
En effet, il existe 4 types de barrages :
Les Barrages (en noir et en gras) : ce sont les barrages valids par l'administrateur, il
peuvent tre affichs par tout le monde et dont le propritaire est l'utilisateur connect.
Les Barrages (en noir) : ce sont les barrages valids par l'administrateur, il peuvent
tre affichs par tout le monde et dont le propritaire n'est pas l'utilisateur connect.
Les Barrages (en gris et en gras) : ce sont les barrages non valids, leurs donnes ne
sont pas publiques et leur propritaire est l'utilisateur connect.
Les Barrages (en gris) : ce sont les barrages non valids, leurs donnes ne sont pas
publiques et leur propritaire n'est pas l'utilisateur connect.
M. Zairi
28
Lorsque le barrage est affich, l'utilisateur peut galement ajouter des nouveaux
incidents, mesures, tudes hydrologiques, ou des mdias au barrage. Pour cela il doit cliquer
sur les menus Nouvel incident , Nouvelle mesure , Nouvelle hydrologie , ou
Nouveau mdia qui sont gauche de la page.
Un barrage doit avoir obligatoirement un propritaire. Ce dernier a la possibilit de
valider son propre barrage pour le rendre visible tout le monde.
Illustration 17: Page d'affichage d'un barrage
M. Zairi
29
Si l'utilisateur souhaite ajouter un incident pour un barrage, il sera rdig vers la page
suivante. Pour chaque incident plusieurs sources, consquences ou actions correctives
peuvent tre ajoutes.
Illustration 18: Ajout d'un incident
De la mme faon que les incidents, l'utilisateur de l'application peut ajouter des
nouvelles mesures au barrage. Il peut choisir le type de ce dernier l'aide d'une liste
droulante 2 niveaux, rdiger un commentaire et mettre le nombre de mesures.
M. Zairi
30
Illustration 19: Ajout d'une mesure
Il est possible d'ajouter pour chaque barrage et/ou incident des fichiers textes, des PDF,
des images, des vidos. L'utilisateur a aussi la possibilit d'attacher des documents
uniquement aux barrages qu'il a le droit de modifier.
S'il s'agit d'un document gnral concernant tout les barrages de la base de donne il
est possible de l'attacher la page daccueil.
M. Zairi
31
Illustration 20: Ajout d'un mdia
Une fois l'image enregistre, l'utilisateur sera redirig vers une page lui permettant de
voir le fichier qu'il a tlcharg au format rduit ou rel. Il aura aussi la possibilit de l'diter
ou de le supprimer.
M. Zairi
32
Illustration 21: Affichage du mdia
Si il y a eu des tudes hydrologiques sur un barrage, l'utilisateur peut les ajouter la base de
donnes l'aide du menu Nouvelle hydrologie .
Illustration 22: Ajout d'une tude hydrologique
M. Zairi
33
6.3. Back-end
Le back-end est la partie servant grer tout le contenu du site visible par les visiteurs
sur le front-end. Par dfinition, l'accs au back-end doit tre protg par mot de passe
puisqu'il permet de modifier le contenu du site. L'interface graphique du back-end devait
tre claire et pouvoir afficher de grandes quantits d'information, ce qui n'est pas le cas de
l'interface du front-end qui est de taille fixe.
Illustration 23: Page d'identification / Aperu de la logique de l'interface
L'interface d'administration est dcoupe en deux parties : la partie de gauche qui sert
afficher de l'aide et des liens vers d'autres fonctions ; et la partie de droite qui contient tout
le contenu et les contrles. Ces deux parties peuvent tre charges indpendamment ou
ensemble par AJAX sans rechargement du navigateur.
M. Zairi
34
III. RSULTATS
1. Rsultat obtenu
Actuellement, les fonctions de saisie ont t implmentes. C'est--dire que
lutilisateur peut crer, diter ou supprimer des barrages, des incidents, des actions
correctives, et excuter les sous-fonctions associes comme par exemple : ajouter des
documents multimdia, ou des mesures un barrage donn. De plus, pour toutes les parties
principales, lutilisateur peut afficher des donnes en fonction de diffrents critres (Pays,
type ..).
La gestion des donnes multimdia est implmente. C'est--dire que lutilisateur peut
ajouter des images , des vidos ou des fichier PDF pour enrichir le barrage.
Pour la gestion des utilisateurs et de leur droits, tout est mis en place grce au plugin
sfDoctrineGuardPlugin .
Le systme de validation fonctionne : l'administrateur peut valider un barrage saisi par
un utilisateur, c'est--dire publier ses informations pour qu'elles soient visibles des autres
utilisateurs de l'application.
Pour le moment, l'envoie automatique d'un email ladministrateur en cas de
modification des donnes d'un barrage n'est pas mis en place faute de paramtres
d'authentification au serveur SMTP de l'tablissement pour l'application.
Cot application backend rserve aux administrateurs, les principaux formulaires de
saisie et de contrles de donnes ont t gnrs.
Au niveau des tests automatiques, les principales saisies de donnes et la navigation
ont t testes : la gestion des filtres de recherche pour tous les modules, les suppressions
groupes et en cascade des lments...
Lapplication respecte les conventions du W3C lexception de quelques
avertissements gnrs automatiquement par Symfony. De plus, lapplication au niveau du
design et de la navigation fonctionne correctement sur la plupart des navigateurs tests
(Firefox, Opera, Google Chrome, Safari ). Cependant, sur Iceweasel et Konqueror, le menu
droulant ne fonctionne pas correctement.
2. Amlioration future
La partie affichage, cration et modification des barrages tant ralise, il faut
maintenant ajouter l'envoi automatique d'un email informatif l'administrateur en cas de
modification de donnes d'un barrage par un expert. Dans ce cas, ladministrateur pourra
valider ou pas ces modifications.
M. Zairi
35
L'autre fonctionnalit est le dveloppement d'un glossaire contenant les termes relatifs
au domaine d'tude permettant d'avoir une prise de contact avec la terminologie propre au
domaine des barrages.
IV. BILAN
1. Difficults rencontres
La principale difficult a t lapprentissage de Symfony. En effet, mme si le langage
de base est le PHP, le framework possde une architecture et des mthodes qui lui sont
propres. Ces diffrences de mthodes sont principalement les accs la base de donnes et
la cration de formulaires.
L'autre problme majeur que j'ai rencontr, tait au niveau du schma relationnel. En
effet, celui-ci a t modifi un grand nombre de fois afin d'ajouter les fonctionnalits
demandes mais galement pour amliorer la cohrence entre les tables. Cela m'a amen
de nombreux dysfonctionnements de l'application qu'il fallait trouver et corriger.
2. Apport pour l'entreprise

Le Cemagref d'Aix en Provence possde maintenant une base de connaissances sur les
barrages, les incidents et leurs actions correctives. Maintenant, les experts peuvent consulter
l'historique des incidents d'un barrage et en tirer de nombreux enseignements. Cette base de
connaissances constitue de plus un moyen efficace pour partager les informations recueillies
par chacun.
3. Bilan personnel
Ce projet a permis damliorer mes connaissances dans la gestion de projets et les
lments principaux prendre en compte pour planifier et attribuer des tches. Ce projet
ma galement permis dapprendre comment fonctionne un systme de gestion
d'information.
Au niveau du dveloppement, jai dcouvert Symfony et le dveloppement l'aide
d'un framework web. Ce projet tait une occasion pour amliorer mes connaissances sur le
dveloppement des applications web en prenant en compte les diffrentes contraintes qui se
prsentent en plus dun dveloppement classique.
Ce projet ma permis galement de dvelopper mon sens de lautonomie, de la
rflexion et de la rsolution des problmes et ainsi de bien attribuer les diffrentes phases de
la ralisation au cours du temps.
M. Zairi
36
Avril
Mai
Juin
Juille t
Aot
Se pte mbre
tude du cahier des charges

Apprentissage du Framework
Dveloppement de l'application
Amlioration de l'application
Rapport
Illustration 24: Chronogramme
M. Zairi
37
CONCLUSION
Ce stage a t sous plusieurs aspects riche denseignements.
Le stage consistait raliser une base de donne interactive pour faciliter le travail
d'experts. Il m'a permis d'amliorer mes connaissances en cration d'application web, et
notamment en ce qui concerne le respect strict des standards du Web et l'utilisation pousse
de technologies comme l'UML, le SQL, le Java Script, et la POO.
l'heure actuelle, l'application est prte tre utilise. On peut donc affirmer que le
but qui mavait t fix a t atteint.
Le contact avec le monde de la recherche ma permis de progresser dans de nombreux
domaines, notamment sur le thme de lanalyse de donnes. Jai aussi dcouvert le
framework Symfony.
En conclusion, mon stage m'a permis de mettre en uvre des comptences scolaires,
professionnelles et humaines pour un sujet intressant. J'ai de plus acquis de nouvelles
comptences dans le domaine du dveloppement web.
M. Zairi
38
GLOSSAIRE
AJAX : Technique utilisant des technologies comme le javascript et le XML pour charger
des donnes dans une page web sans rechargement de la page.
CMS : Un systme de gestion de contenu ou SGC ((en) Content Management Systems

ou CMS) est une famille de logiciels destins la conception et la mise jour
dynamique de site web ou d'application multimdia.
diteur WYSIWYG : What you see is what you get. Champ de saisie de texte similaire
celle d'un traitement de texte, c'est--dire avec des options de mises en forme (police,
taille du texte, couleur, alignement, etc).
IHM : Interface Homme Machine.
MVC : Le Modle-Vue-Contrleur (en abrg MVC, de l'anglais Model-ViewController) est une architecture et une mthode de conception qui organise l'interface
homme-machine (IHM) d'une application logicielle.
POO : Programmation Oriente Objet. Consiste en la dfinition et l'assemblage de

briques logicielles appeles objet, un objet reprsente un concept, une ide ou une entit
quelconque.
PHP : HyperText Preprocessor est un langage de programmation pour permettre la

cration de page HTML de manire dynamique.
Template : Un template est un modle de prsentation des donnes. On parle aussi de

patron comme en couture ou de gabarit.
M. Zairi
39
YAML : Langage de srialisation de donnes qui reprend des concepts d'autres langages
comme XML, mais en organisant les donnes sous forme de listes.
Relation OneToMany : Une relation se produit lorsque chaque enregistrement dans une
table A peut avoir plusieurs enregistrements lis une table B, mais chaque
enregistrement dans la table B peut avoir qu'un seul enregistrement correspondant dans la
table A.
Relation ManyToMany : Une ligne dans la table A peut avoir plusieurs lignes
correspondantes dans la table B, et vice versa.
Fixture : Fichier au format YAML servant remplir la base de donnes.
Ruby on Rails : Framework web libre crit en Ruby (http://www.rubyonrails.org/).
M. Zairi
40
RFRENCES BIBLIOGRAPHIQUE
http://www.symfony-project.org/ : Site officiel du Framework de Symfony, on y retrouve
des tutoriels, documentation, plug-in...
http://www.developpez.net/forums/f663/php/bibliotheques-frameworks/symfony/
:
Communaut de dveloppeurs en Symfony, trs utile lorsque quon est bloqu sur quelque
chose.
http://www.php.net/manual/fr/ : Documentation sur le langage PHP.
M. Zairi
41

Pub00033517 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pub00033517 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de stage

2me anne ISIMA

Sujet: Dveloppement dune base de

Institut Suprieur d'Information de

Dure : 5 mois du 4 avril au 2 septembre 2011

Dveloppement dune base de connaissances interactive ddie aux barrage

Dveloppement dune base de connaissances interactive ddie aux barrage

Dveloppement dune base de connaissances interactive ddie aux barrage

TABLE DES FIGURES ET ILLUSTRATIONS

Dveloppement dune base de connaissances interactive ddie aux barrage

TABLE DES MATIRES

Dveloppement dune base de connaissances interactive ddie aux barrage

Dveloppement dune base de connaissances interactive ddie aux barrage

Dveloppement dune base de connaissances interactive ddie aux barrage

I. PRSENTATION DU CONTEXTE DE STAGE

2. Prsentation du l'organisme client : le Cemagref d'Aix en Provence

Dveloppement dune base de connaissances interactive ddie aux barrage

Dveloppement dune base de connaissances interactive ddie aux barrage

1.2. tude du cahier des charges

Dveloppement dune base de connaissances interactive ddie aux barrage

2.1. La Mthode Modle-Vue-Contrleur (MVC)

Illustration 1: Interactions entre le modle, la vue et le contrleur

Dveloppement dune base de connaissances interactive ddie aux barrage

2.2. From Scratch, Framework ou CMS ?

2.2.1. Codage From Scratch

2.2.2. Utilisation d'un CMS

Dveloppement dune base de connaissances interactive ddie aux barrage

2.2.3. Utilisation d'un Framework

2.3. Solution retenue

Dveloppement dune base de connaissances interactive ddie aux barrage

2.3.1. Comparatif des principaux framework PHP

Dveloppement dune base de connaissances interactive ddie aux barrage

Dveloppement dune base de connaissances interactive ddie aux barrage

2.3.2. Choix final

Dveloppement dune base de connaissances interactive ddie aux barrage

Le dveloppement de lapplication sest fait en deux temps : lapprentissage de

Dveloppement dune base de connaissances interactive ddie aux barrage

2.4. Comparatif des deux ORM

Dveloppement dune base de connaissances interactive ddie aux barrage

Illustration 2: Donnes d'un barrage

3.1.1. Caractristiques physiques

Dveloppement dune base de connaissances interactive ddie aux barrage

Illustration 3: Schma relationnel des Caractristiques physiques simples d'un barrage

persa_type_evacuateur , persa_pays et persa_type sont des tables en relation

Dveloppement dune base de connaissances interactive ddie aux barrage

Caractristiques physiques multiples

Illustration 4: Schma relationnel des Caractristiques physiques multiples d'un barrage

Dveloppement dune base de connaissances interactive ddie aux barrage

3.1.2. Les vnements

Dveloppement dune base de connaissances interactive ddie aux barrage

Illustration 5: Schma UML des incidents

Phnomne et Conception-Ralisation sont deux tables filles qui hritent de la

Dveloppement dune base de connaissances interactive ddie aux barrage

Illustration 6: Schma relationnel des incidents

c. Les actions correctives

Dveloppement dune base de connaissances interactive ddie aux barrage

De plus, on a une structure arborescente trois niveaux : catgories, sous-catgories et

Illustration 7: Exemple des actions correctives

Schma relationnel des actions correctives

Dveloppement dune base de connaissances interactive ddie aux barrage

Illustration 8: Schma relationnel des actions correctives

Le schma relationnel prcdent permet de stocker une arborescence trois niveaux

Illustration 9: Arborescence des actions correctives