Mmoire de Projet de Fin dEtude

Pour lObtention du Diplme BAC+5 en

Ingnierie des Systmes dInformation

Sujet
Conception et Ralisation dune Application de Gestion
Environnementale Selon la Norme ISO 14001











Anne Universitaire 2013-2014
Membres du Jury :

Mr. Mohammed EL KOUTBI: Prsident
Mr. Ahmed ZELLOU: Encadrant
Mr. Ahmed EL KHADIMI: Examinateur
Mr. Olivier HABERT: Examinateur
Soutenu par :
Mr. Yassine ECH-CHARAFI
Mr. Mourad HAMMANI


Ecole Suprieure de Management Universit de lorraine
DInformatique et de Tlcommunication METZ


2

Ddicace



Nous ddions ce travail :

A Nos chers parents que nous remercions de tous nos curs pour leurs
conseils qui nous ont guids tout au long de notre chemin dtude;

A Notre encadrant qui nous a normment aid et soutenu tout au long de
la ralisation de ce travail.

A Nos enseignants pour leurs formations, leurs conseils et leurs aides.

A Nos amis pour leurs encouragements et soutien.

A ceux qui nous ont indiqu la bonne voie en nous rappelant que la volont
fait toujours les grandes personnes.







3

Remerciements



Si jai vu plus loin, cest en me tenant sur les paules des gants qui mont prcd Isaac
Newton


Nous tiendrons remercier dans un premier temps, Monsieur Ahmed ZELLOU pour laide et les
conseils fournis lors des diffrents suivis se rapportant aux missions voques dans ce rapport.


Nous remercions tous les membres du jury qui ont accept dvaluer notre travail.


Nous remercions galement toute lquipe pdagogique de SUPMIT et tous les intervenants
professionnels pour avoir assur la partie thorique de notre formation.


Nous tenons aussi remercier lensemble du staff administratif et technique de lcole SUPMTI


Nous remercions dans un dernier temps nos ami(e)s et toutes les personnes qui ont contribu de prs
ou de loin la conception et au bon droulement de ce travail.





4


Rsum

La gestion environnemental, aussi appel management environnementale, ou co management, dsigne
les mthodes de gestion d'une entit (entreprise, service) visant prendre en compte l'impact
environnemental de ses activits, valuer cet impact et le rduire. Le management environnemental
s'inscrit dans une perspective de dveloppement durable.
Cest dans cette perspective que sinscrit ce projet qui sintitule: "conception et ralisation dune
application de gestion environnementale selon la norme ISO 14001 " et qui vise mettre en place un
systme de gestion environnemental adapt le mettre en uvre pour tous les types de projets.
Lobjectif de ce projet est de fournir lentreprise marocaine un outil de suivi et daudit de la gestion
environnementale propose par la norme mondiale de certification ISO 14001.
Nous avons ainsi men une tude approfondie de la spcification et la structure de base de lISO 14001
quil faut suivre pour obtenir la certification selon les lois en vigueur. A partir de cette tude, des
proprits spcifiques ce projet ont t mises en vidence et ont permis de proposer les entits de
lapplication suivantes :
Activits : cest lensemble des parties industriel de la socit.
Polluants : ce sont les diffrents types des rejets de lactivit.
Rglements : ce sont les lois rglementaires appliques lenvironnement.
Impacts : cest linfluence du contacte des polluants sur lenvironnement.
Actions : ce sont les oprations correctives faites par les spcialistes pour trouver des solutions
efficaces dun impact sur lenvironnement.
Mesurage : ce sont toutes les oprations de mesurage des impacts dun polluant, tout en respectant les
rglementations en vigueur.
Matriels : ce sont tous les matriels utiliss dans les activits.
Ce projet devrait, non seulement, avoir des effets directs sur les pratiques environnementales des
organisations mais galement des effets indirects sur ses organisations internes et ses communications
externes.
Pour la ralisation de ce projet, nous avons adopt le processus de dveloppement 2TUP qui fait une
large place la technologie et la gestion du risque, nous avons aussi utilis le langage UML pour la
modlisation.

5

En ce qui concerne le dveloppement, nous avons utilis le Framework Symfony2, le langage Php5,
JavaScript, jQuery, Ajax et MySQL pour la base de donnes.
Dans le prsent document nous allons dcrire plus en dtail les tapes que nous avons ralises dans le
cadre de notre projet.



Mots-cls : gestion environnementale, polluant, mesure.





















6

Abstract

The environmental management, also called environmental management or eco management, means
the management methods of an entity (company, department ...) to consider the environmental impact
of its activities, to assess this impact and to reduce it. Environmental management is part of a
sustainable development perspective.
It is in this perspective that the project entitled "Design and implementation of an application of
environmental management according to ISO 14001" which aims to establish a system of
environmental management appropriate to put implemented for all types of projects. The objective of
this project is to provide the Moroccan company a tool for monitoring and auditing of environmental
management proposed by the global standard ISO 14001 certification.
We have conducted a comprehensive study of the specification and the basic structure of ISO 14001
to be followed to achieve certification under the laws in force. From this study, specific to the project
properties were identified and allowed to propose the following entities of the app:
Activities: This is the set of industrial parts of society.
Pollutants: are the different types of discharges from the activity.
Regulations: are regulatory laws applied to the environment.
Impacts: it is the influence of the contact of pollutants on the environment.
Actions: These are remedial operations performed by experts to find an effective environmental impact
solutions.
Measurement: these are all the measuring operations impacts of a pollutant, while respecting the
regulations.
Materials: these are all materials used in the activities.
This project should not only have direct effects on the environmental practices of organizations but
also an indirect effect on its internal organizations and external communications.
For this project, we adopted the process of development that 2TUP a strong emphasis on technology
and risk management, we also used the UML for modeling.
With regard to development, we used the Symfony2 Framework, language Php5, JavaScript, jQuery,
Ajax and MySQL for the database.
In this paper we will describe in more detail the steps we have made in the context of our project.


7

Liste des abrviations
Abrviation Dsignation
2TUP 2 Track Unified Process
AJAX Asynchronous JavaScript and XML
BPMN Business Process Model and Notation
CSS Cascading Style Sheets
DOM Document Object Model
FTP File Transfer Protocol
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IHM Interface Homme Machine
MSP Microsoft Project
MVC Model View Controller
OMG Object Management Group
PBS Product Breakdown Structure
PHP Hypertext Preprocessor
RUP Rational Unified Process
SQL Structured Query Language
UML Unified Modelling Language
XML Extensible Markup Language
XP Extreme Programming
XSL Extensible Stylesheet Language






8

Table des figures

FIGURE 1: LE PROCESSUS DE DEVELOPPEMENT EN Y .............................................................................................................................. 19
FIGURE 2: PLANNING PREVISIONNEL DU PROJET .................................................................................................................................... 23
FIGURE 3: BRANCHE FONCTIONNELLE DU PROCESSUS Y .......................................................................................................................... 25
FIGURE 4: DIAGRAMME DES CAS DUTILISATION DE LACTEUR DIRECTEUR ................................................................................................. 27
FIGURE 5: DIAGRAMME DES CAS DUTILISATION DE LACTEUR RESPONSABLE ACTIVITE ................................................................................. 28
FIGURE 6: INTERFACE HOMME/MACHINE D'AJOUT D'UNE ACTIVITE .......................................................................................................... 29
FIGURE 7: DIAGRAMME DES CAS DUTILISATION DE LACTEUR JURISTE ENVIRONNEMENTALISTE ..................................................................... 30
FIGURE 8: DIAGRAMME DES CAS DUTILISATION DE LACTEUR TECHNICIEN ENVIRONNEMENTALISTE ............................................................... 30
FIGURE 9: INTERFACE HOMME/MACHINE MESURAGE D'UN POLLUANT ...................................................................................................... 31
FIGURE 10: DIAGRAMME DES CAS DUTILISATION DE LACTEUR COORDINATEUR ......................................................................................... 32
FIGURE 11: DIAGRAMME DES CAS DUTILISATION DE LACTEUR AUDITEUR ................................................................................................ 32
FIGURE 12: DIAGRAMME DES CAS DUTILISATION GLOBAL ..................................................................................................................... 33
FIGURE 13: DIAGRAMME DE SEQUENCE (AUTHENTIFICATION) ................................................................................................................. 34
FIGURE 14: DIAGRAMME DE SEQUENCE (AJOUTER ACTIVITE)................................................................................................................... 35
FIGURE 15: DIAGRAMME DE SEQUENCE (SUPPRIMER ACTIVITE) ............................................................................................................... 36
FIGURE 16: DIAGRAMME DE SEQUENCE (CONSULTER ENTITE) ................................................................................................................. 37
FIGURE 17: DIAGRAMME DE SEQUENCE (MESURER POLLUANT) ............................................................................................................... 38
FIGURE 18: DIAGRAMME DE SEQUENCE (AUDITER ACTIVITES) ................................................................................................................. 39
FIGURE 19: BRANCHE TECHNIQUE DU PROCESSUS Y .............................................................................................................................. 41
FIGURE 20: ARCHITECTURE 3 TIERS .................................................................................................................................................... 44
FIGURE 21: ARCHITECTURE DU DESIGNE PATTERN MVC ........................................................................................................................ 44
FIGURE 22: PHASE DE MISE EN UVRE DANS LE PROCESSUS Y ................................................................................................................. 48
FIGURE 23: ARCHITECTURE LOGICIELLE DU PROJET ................................................................................................................................ 49
FIGURE 24: LA PREMIERE PARTIE DE NOTRE DIAGRAMME DE CLASSES ........................................................................................................ 52
FIGURE 25: LA DEUXIEME PARTIE DE NOTRE DIAGRAMME DE CLASSES ....................................................................................................... 53
FIGURE 26: DIAGRAMME DE CLASSES ................................................................................................................................................. 54
FIGURE 27: DIAGRAMME DE SEQUENCES (AJOUT D'ACTIVITE) ................................................................................................................. 57
FIGURE 28: DIAGRAMME DE SEQUENCES (MESURER POLLUANT) ............................................................................................................. 58
FIGURE 29: DIAGRAMME DE SEQUENCES (AJOUTER PROGRAMME) .......................................................................................................... 58
FIGURE 30: DIAGRAMME DACTIVITE (MESURER UN POLLUANT) .............................................................................................................. 59
FIGURE 31: DIAGRAMME DACTIVITE (AJOUTER POLLUANT).................................................................................................................... 60
FIGURE 32: DIAGRAMME DES PAQUETAGES ......................................................................................................................................... 61
FIGURE 33: PHASE DE REALISATION DANS LE PROCESSUS Y ..................................................................................................................... 63
FIGURE 34: FONCTIONNEMENT DE SYMFONY2 ..................................................................................................................................... 65
FIGURE 35: L'INTERFACE D'ACCUEIL DE L'APPLICATION ........................................................................................................................... 71
FIGURE 36: L'INTERFACE D'AUTHENTIFICATION .................................................................................................................................... 71
FIGURE 37: L'INTERFACE DE CREATION D'UN TYPE DE PROFIL ET SON ROLE ................................................................................................. 72
FIGURE 38: L'INTERFACE D'AJOUT D'UNE ACTIVITE ................................................................................................................................ 72
FIGURE 39: L'INTERFACE DE LISTER DES MESURAGES.............................................................................................................................. 73
FIGURE 40: L'INTERFACE DE VISION DUN PROGRAMME ......................................................................................................................... 73
FIGURE 41: L'INTERFACE DES MESURAGES DES IMPACTS ......................................................................................................................... 74



9





Liste des tableaux

TABLE 1: TABLEAU COMPARATIF ENTRE LES PROCESSUS DE DEVELOPPEMENT [B3] ...................................................................................... 18
TABLE 2: LIVRABLE DU PROJET .......................................................................................................................................................... 20
TABLE 3: LES ESTIMATIONS DES RISQUES ............................................................................................................................................. 21
TABLE 4: LISTE DES ACTEURS ............................................................................................................................................................. 27
TABLE 5: LES VUES DE L'APPLICATION ................................................................................................................................................. 50
TABLE 6: DESCRIPTION DE CLASSE ACTIVITE.......................................................................................................................................... 56
TABLE 7: DESCRIPTION DE LA CLASSE FORMATION ................................................................................................................................. 57
TABLE 8: LES TESTS UNITAIRES DE L'APPLICATION .................................................................................................................................. 75


















10

Table Matires


INTRODUCTION GENERALE ............................................................................................................................................... 12
CHAPITRE 1 : CONTEXTE GENERAL DU PROJET .................................................................................................................. 13
1- CONTEXTE DU PROJET ................................................................................................................................................... 14
1.1- Dfinition de la gestion environnementale ......................................................................................................... 14
1.2- ISO et lenvironnement ........................................................................................................................................ 14
1.3- Avantage ISO 14001 ............................................................................................................................................ 14
2- CAHIER DES CHARGES ................................................................................................................................................... 15
2.1- Recueil des besoins fonctionnels.......................................................................................................................... 16
2.2- Recueil des besoins oprationnels ....................................................................................................................... 17
3- CONDUITE DU PROJET ................................................................................................................................................... 17
3.1- Processus de dveloppement ............................................................................................................................... 17
3.2- Livrable ................................................................................................................................................................ 20
3.3- Matrice des risques .............................................................................................................................................. 20
3.4- Langage de modlisation .................................................................................................................................... 22
3.5- Planification du projet ......................................................................................................................................... 22
4- CONCLUSION ............................................................................................................................................................ 23
CHAPITRE2 : ETUDE FONCTIONNELLE ................................................................................................................................ 24
1- LETUDE FONCTIONNELLE DANS LE PROCESSUS Y ........................................................................................................ 25
2- CAPTURE DES BESOINS FONCTIONNELS ......................................................................................................................... 25
3- IDENTIFICATION DES ACTEURS ...................................................................................................................................... 26
4- DIAGRAMME DE CAS DUTILISATION ............................................................................................................................ 27
5- DIAGRAMME DE SEQUENCE (BOITE NOIRE).................................................................................................................... 34
6- CONCLUSION ................................................................................................................................................................. 39
CHAPITRE 3 : ETUDE TECHNIQUE ...................................................................................................................................... 40
1- LETUDE TECHNIQUE DANS LE PROCESSUS Y ................................................................................................................ 41
2- CAPTURE DE BESOIN TECHNIQUE .................................................................................................................................. 41
3- SPECIFICATION TECHNIQUE ........................................................................................................................................... 41
3.1- Spcification darchitecture ................................................................................................................................. 42
3.2- Design patterns MVC ......................................................................................................................................... 44
4- CONCEPTION GENERIQUE .............................................................................................................................................. 46
5- CONCLUSION ................................................................................................................................................................. 46
CHAPITRE 4 : MISE EN UVRE DE LA SOLUTION................................................................................................................ 47
1- LA MISE EN UVRE DANS LE PROCESSUS Y ................................................................................................................... 48
2- LA CONCEPTION PRELIMINAIRE ..................................................................................................................................... 48
2.1- Architecture logicielle implmente .................................................................................................................... 49
2.2- numration des vues de lapplication ................................................................................................................ 49
3- DIAGRAMME DE CLASSES .............................................................................................................................................. 51
4- LA CONCEPTION DETAILLEE ......................................................................................................................................... 55
4.1- Conception des attributs ...................................................................................................................................... 55
4.2- Conception des classes......................................................................................................................................... 55

11

4.3- Description des classes ........................................................................................................................................ 55
5- DIAGRAMME DE SEQUENCES (BOITE BLANCHE) ............................................................................................................ 57
6- DIAGRAMME DACTIVITE ............................................................................................................................................. 59
7- DIAGRAMME DES PAQUETAGES ..................................................................................................................................... 60
8- CONCLUSION ................................................................................................................................................................. 61
CHAPITRE 5 : REALISATION ................................................................................................................................................ 62
1- LA REALISATION DANS LE PROCESSUS Y ...................................................................................................................... 63
2- TECHNOLOGIES ET OUTILS UTILISEES ............................................................................................................................ 63
2.1- Symfony2 ............................................................................................................................................................. 63
2.2- Doctrine ............................................................................................................................................................... 66
2.3- Twig ..................................................................................................................................................................... 66
2.4- PHP 5.................................................................................................................................................................... 66
2.5- JavaScript ............................................................................................................................................................. 67
2.6- jQuery .................................................................................................................................................................. 67
2.7- AJAX ..................................................................................................................................................................... 67
2.8- Microsoft Project ................................................................................................................................................. 68
2.9- PHPUnit ................................................................................................................................................................ 69
2.10- PHP Storm ............................................................................................................................................................ 69
2.11- Enterprise Architect ............................................................................................................................................. 69
2.12- MAMP .................................................................................................................................................................. 69
2.13- LabVIEW............................................................................................................................................................... 70
3- IMPLEMENTATION DES IHM .......................................................................................................................................... 70
3.1- Linterface daccueil de lapplication ................................................................................................................... 71
3.2- Linterface dauthentification .............................................................................................................................. 71
3.3- Linterface de cration dun type de profil et son rle ......................................................................................... 72
3.4- Linterface dajout dune activit ......................................................................................................................... 72
3.5- Linterface de lister des mesurages ...................................................................................................................... 73
3.6- Linterface de vision dun programme ................................................................................................................. 73
3.7- Linterface de lister les mesurages des impacts avec LabView ............................................................................ 74
4- PHASE DE TESTS ET VALIDATION ................................................................................................................................... 74
5- CONCLUSION ................................................................................................................................................................. 75
CONCLUSION GENERALE ET PERSPECTIVES........................................................................................................................ 76
BIBLIOGRAPHIE ET WEBOGRAPHIE .................................................................................................................................... 77







12

Introduction gnrale

Ces dernires annes, les proccupations environnementales sont devenues de plus en plus importantes
pour toutes les parties prenantes de nombreuses organisations. Aucune entreprise ne peut se permettre
d'ignorer cette tendance, cest dans ce cadre que s'inscrit notre projet de fin dtude qui consiste
concevoir une application web pour mettre en place un systme de gestion de lenvironnement et qui a
aussi pour objectif de rduire les cots, damliorer les performances et de parfaire limage de
lentreprise en utilisant le standard ISO 14001.
La solution mettre en place sera compose dun modle mtier pour la gestion des diffrentes
activits, le mesurage des polluants et impacts, lapplication des exigences rglementaires, le suivi de
lhistorique, et la gestion des diffrents programmes de communication interne et externe.
Afin dapporter des lments de rponse cette demande, le prsent mmoire dtaille travers ses
diffrents chapitres la dmarche adopte et les rsultats atteints. Le prsent rapport comporte cinq
chapitres :
Le premier chapitre sera consacr au contexte gnral du projet. Ainsi, nous prsentons le cahier des
charges, nous dfinissons la conduite suivre, en choisissant une mthode pour le processus de
dveloppement (la mthode en Y), toute en respectant une planification bas sur trois mois et un plan
dassurance qualit.
Dans le deuxime chapitre nous formulons ltude fonctionnelle. Nous nous intressons la capture
des besoins fonctionnels, nous spcifions les acteurs (Directeur, Responsable dactivit, Juriste,
Technicien Environnementale, Coordinateur et lAuditeur), Ensuite, nous ralisons les diffrents
diagrammes de cas dutilisation que nous adossons par la description de squence des scnarios les
plus importants.
Au niveau du troisime chapitre, nous dtaillons la partie de ltude technique. Nous abordons dune
part la description de la spcification technique par le choix dun style darchitecture en 3 tiers, et
dautre part la programmation gnrique.
Dans le quatrime chapitre, qui est consacr la mise en uvre de la solution, nous prsentons les
conceptions prliminaire et dtaille.
Le cinquime chapitre concrtisera le modle de conception entam lors des prcdents chapitres,
surtout en des couches applicatives et des interfaces homme/machine, ainsi que les technologies et les
outils utilises comme le Framework Symfony2, LabVIEW, PHP5, JavaScript, jQuery, Ajax,
PhpStorm, MAMPen utilisant la mthode darchitecture MVC.
Dans la conclusion, nous synthtisons le travail ralis et numrons les perspectives envisages.

13






Chapitre 1 : Contexte gnral du projet

Ce chapitre prsente le sujet du projet. Il prcise lobjectif et la conduite du projet ainsi que le planning
gnral de sa ralisation.













14

1- Contexte du projet
1.1- Dfinition de la gestion environnementale
La gestion environnemental, aussi appel management environnementale, ou co management, dsigne
les mthodes de gestion d'une entit (entreprise, service) visant prendre en compte l'impact
environnemental de ses activits, valuer cet impact et le rduire. Le management environnemental
s'inscrit dans une perspective de dveloppement durable.
Les motivations de l'entreprise peuvent tre de plusieurs types : respecter des rglementations,
amliorer l'image de l'entreprise, amliorer les relations avec les riverains (pour les entreprises
polluantes), faire des conomies, obtenir une certification environnementale ou un colabel rclame
par les clients de l'entreprise [W1].
1.2- ISO et lenvironnement
Pour grer la relation avec lenvironnement, la famille ISO 14000 traitent divers aspects du
management environnemental. Elle propose des outils pratiques aux entreprises et organisations qui
souhaitent identifier et matriser leur impact sur lenvironnement, et constamment amliorer leur
performance environnementale. Les normes ISO 14001:2004 et ISO 14004:2004 se concentrent sur les
systmes de management environnemental. Les autres normes de la famille traitent daspects
spcifiques, notamment lanalyse du cycle de vie, la communication et laudit. [B1].
La norme ISO 14001 se base sur trois niveaux mettre en place dun systme de management
environnemental. Chaque niveau contient plusieurs tapes avec un ou plusieurs rsultats atteindre a
selon critres dvaluation. De plus chaque niveau traite le principe damlioration continue et peut
faire lobjet dune certification par tierce-partie
1.3- Avantage ISO 14001
Parmi les avantages de la certification ISO 14001, nous citons:

Amliorer les performances environnementales en diminuant les impacts.
Connatre et prvenir les risques et incidents lis lactivit de lentreprise.
Renforcer la confiance des partenaires commerciaux.
Rpondre aux exigences environnementales des grands donneurs dordre et des parties
intresses.
Matriser le budget en rduisant des postes de dpenses.
Parfaire limage de lentreprise en affichant les engagements.

15

Gagner de nouveaux marchs.
Fdrer et motiver les quipes autour de ce projet.

Lobjectif principal de mise en place dun systme de management environnementale est
dencourager les entreprises adopter une dmarche volontaire damlioration constante des
performances environnementales de leurs sites industriels, pour rpondre aussi des pressions
extrieures croissantes dans le domaine de lenvironnement. Cest pour cela que nous avons choisi ce
projet qui consiste concevoir et mettre en place un systme de gestion environnementale.

2- Cahier des charges

Notre projet consiste mettre en place une application web, destine la gestion de lenvironnement
suivant le standards ISO 14001.
Le manuel ISO 14001[B2] nous a dcrit les grandes lignes pour le dveloppement dun systme de
gestion environnementale est dcrites sous forme de cinq tapes cls et deux activits de support:
Les cinq tapes sont :
Lengagement de dirigeants et la politique environnementale.
Linventaire de pollutions et leurs impacts.
La mise en uvre des obligations rglementaires environnementales.
Lamlioration de la performance environnementale.
Lautocontrle et auto-surveillance.

Les activits de support sont :
La sensibilisation et formation du personnel.
La communication interne et externe.

L'application devra tre conforme la norme ISO 14001, nous devons alors atteindre les rsultats
suivants :
Prendre en considration tous les ingrdients de la norme (activits, polluants, actions,
impacts.)
Disposer d'un module d'administration de l'application permettant la gestion, le reporting, les
alarmes, les alertes,

16

Ceci en suivant les tapes suivantes :
Lutilisation dune mthodologie.
La mise en place dun planning.
Lextraction des diffrents acteurs et diffrents cas dutilisations de lapplication.
Lanalyse des diffrents scnarios gnraux de lapplication.
La conception de lapplication a traves la mise en place du diagramme de classe.
Limplmentation de la base de donnes pour la persistance.
Le dveloppement de lapplication.
La validation de l'application par des scnarios de tests d'excution.

2.1- Recueil des besoins fonctionnels
Lanalyse du cahier des charges nous a permet dexpliciter les besoins fonctionnels spcifiant un
comportement dentre sortie du systme en effet, le systme concevoir doit offrir les modules
suivants :
Un module de gestion des entits de lapplication
Il sagit dun outil permettant deffectuer des oprations de gestion telles que lajout, la suppression, la
modification et la consultation de diffrentes entits du projet.
Un module dauthentification
Dans un souci de scurit, le systme doit offrir un module dauthentification garantissant la protection
de linformation. Avant deffectuer une tche quelconque, tous les utilisateurs du systme doivent
sauthentifier en saisissant leurs identificateurs et leurs mots de passe respectifs.
Un module de reporting
Lapplication doit offrir un module de reporting permettant la gnration des rapports, des bilans, des
statistiques au format PDF afin de faciliter la supervision et le pilotage du systme.
Un module de monitoring
Lapplication doit offrir un module de monitoring permettant doffrir un tableau de bord qui rassemble
lensemble d'indicateurs de pilotage, ddi au responsables et dcideurs, afin de leurs guider dans la
prise de dcisions et le dclanchement des actions en vue d'atteindre les performances de la gestion
environnementale.


17

2.2- Recueil des besoins oprationnels
Lanalyse technique du projet nous a permet dextraire les besoins non fonctionnels ou oprationnels
suivants. Ce sont des contraintes prendre en considration pour mettre en place une solution adquate
aux attentes des utilisateurs du systme. Ainsi, lapplication doit rpondre aux besoins oprationnels
suivants :
Lauthentification
Le systme doit garantir l'authentification des utilisateurs, et restituer ses rles afin de dterminer les
fonctionnalits auxquelles ils ont droit.
Intgrit des donnes
Le systme mettre en place devra garantir lintgrit des donnes en toute circonstance.
Disponibilit
Le systme doit tre en permanence la disposition de ses utilisateurs.
Fiabilit
Le systme doit excuter les fonctions attendues avec la prcision requise.
Performance
Le systme devra tre capable de rpondre aux requtes des diffrents utilisateurs en un temps
raisonnable.

3- Conduite du projet
Afin de mieux organiser le droulement des activits du projet, nous avons suivi une dmarche de
gestion de projet pour aboutir aux objectifs en organisant le droulement temporel des tches, partir
de llaboration du cahier des charges la ralisation du produit souhait.
3.1- Processus de dveloppement
En gnral, la gestion dun projet informatique consiste choisir un processus de dveloppement
adquat. Ce dernier constitue un facteur dterminant dans la russite dun projet, du fait quil cadre ses
diffrentes phases et caractrise les principaux traits de sa conduite.
Le choix dune mthode de dveloppement, qui soit adquate aux exigences fonctionnelles dun projet
doit tre labor au pralable afin dobtenir un produit qui rpond aux besoins et attentes des utilisateurs
dans le temps et des couts prvisible.

18

Devant une multitude de mthodologies disponibles, le choix devient difficile, Pour cela, nous tions
amenes effectuer un benchmarking entre les principaux processus [B3]...
Le tableau 1 suivant prsente une tude comparative entre diffrents processus :
Description Points Forts Points Faibles
RUP
RUP est la fois une
mthodologie de
conduite et de
dveloppement de
projets et un outil prt
l'emploi
Propose des modles
de documents, et des
canevas pour des
projets types
Coteux personnaliser.
Trs ax processus, au
dtriment du
dveloppement : peu de
place pour le code et la
technologie
XP
XP est une mthode
agile plus
particulirement
oriente sur l'aspect
ralisation d'une
application, sans pour
autant ngliger l'aspect
gestion de projet
Prparation des
phases de vrification
au moment de
lAnalyse et de la
Conception
Obligation de la
prsence du client
Dveloppement en
binme.
2TUP
2TUP propose un cycle
de dveloppement en Y,
qui dissocie les aspects
techniques des aspects
fonctionnels
Fait une large place
la technologie et la
gestion du risque
Ne propose pas de
documents types
Table 1: Tableau comparatif entre les processus de dveloppement [B3]
Nous constatons que toutes ces mthodologies proposent de travailler de faon itrative, que ce soit au
niveau des plannings, des spcifications ou du dveloppement. Si l'itratif s'est impos, c'est parce qu'il
rduit la complexit de ralisation des phases en travaillant par approches successives et incrmentales.
Il est alors possible de prsenter rapidement aux utilisateurs des lments de validation. De plus,
l'itratif permet une gestion efficace des risques en abordant, ds les premires itrations, les points
difficiles. Le choix de la technologie et de larchitecture logicielle et applicative de notre futur systme
est lune des phases les plus importantes de notre projet vu le degr lev de sa complexit technique.
Ainsi, 2TUP semble tre le mieux adapt pour mener bien notre projet, puisquil rserve une branche
entire aux aspects techniques dans le processus de dveloppement.

19

Le processus 2TUP propose un cycle de dveloppement en Y, qui dissocie les aspects techniques des
aspects fonctionnels. Illustr en figure 1, le processus en Y s'articule autour de 3 branches [W1]:
Une branche fonctionnelle
Une branche technique
Une phase de ralisation.


Figure 1: Le processus de dveloppement en Y
La branche fonctionnelle capture des besoins fonctionnels pour laborer un modle des besoins
focaliss sur le mtier des utilisateurs. Elle qualifie au plus tt le risque de produire un systme inadapt
aux utilisateurs. De son ct, la matrise duvre consolide les spcifications et en vrifie la cohrence
et lexhaustivit de lanalyse, qui consiste tudier prcisment la spcification fonctionnelle de
manire obtenir une ide de ce que va raliser le systme en termes de mtier. Les rsultats de
lanalyse ne dpendent daucune technologie particulire.
Quant la branche technique, elle permet de rassembler les besoins techniques (scurit, monte en
charge, intgration l'existant..). Elle propose galement une architecture logicielle et applicative qui
rpond aux contraintes prsentes dans le dossier technique. Enfin elle permet de proposer des rgles
de dveloppement afin d'industrialiser l'implmentation (gestion des exceptions, rgles de nommage,
rgles de codage, ...).

20

La troisime branche comporte la conception qui intgre le modle danalyse et de larchitecture
technique puis tudie comment raliser chaque composant. Elle comporte aussi ltape de codage qui
produit ces composants et teste les units de codes ralises et ltape de validation qui consiste enfin
valider les fonctions du systme dvelopp.

3.2- Livrable
Le tableau 2 prsente les diffrents livrables durant les phases du projet.
phases Livrables Date de livraison
prvue
Date de livraison
relle
Date de validation
Planification et
tude du projet
Plan de qualit de
projet(PQP)
25/06/2014 23/06/2014 24/06/2014
Analyse des
besoins du projet
Cahier des charges 15/07/2014 14/07/2014 16/07/2014
Conception
dtailles
Dossier des
spcifications
fonctionnelles
30/06/2014 30/06/2014 01/07/2014
Ralisation Application
dapprovisionnement
08/09/2014 En cours 08/09/2014
Documentation Rapport de projet 09/09/2014 15/09/2014 15/09/2014
Table 2: Livrable du projet

3.3- Matrice des risques
Maitriser les risques est une proccupation majeure en conduite de projets informatiques. Les risques
quun projet ne sexcute pas conformment aux prvisions, aux dates, aux couts ou la qualit sont
considrs comme difficilement acceptable, voir inacceptables.
Pour maitriser les risques, plusieurs activits sont mettre en uvre de manire itrative pendant toute
la dure du projet : lanalyse des risques du projet, la rduction des risques et leur suivi.
Le tableau 3 illustre la matrice des risques identifis susceptible daffecter le droulement normal du
projet, leurs impacts et les actions prventives raliser pour limiter la probabilit de lapparition de
chaque risque.

21

Description Impact probabilit Niveau
dimpact
classement Actions
prventives
Risques techniques :
Absence de
sauvegarde
Perte de
donnes
Possible Performant Moyenne Prvoir une
sauvegarde
rgulire
des
donnes.
Blocage sur les
limites de la
technologie
Difficult de la
mise en place
des exigences
et dpassement
de capacit du
dveloppement.
Trs
possible
Retard de
livraison
Dangereux Analyse
technique
Instabilit de
lenvironnement
Blocage
lavancement
projet
Souvent Retard de
livraison
Svre Choix de
version du
logiciel
Risque matriels :
Panne inattendu
du matriel
Ralentissement
du travail
possible Retard de
livraison
Moyenne Avoir des
copies du
travail et
utilis
dautres
machines
Risque organisationnels :
Absence du
planning
adquat
Retard dans la
livraison du
projet
Possible Performant Moyenne Revoir le
planning
revoir les
dlais
Absence ou
maladie
Ralentissement
du travail
Possible Retard de
livraison
Moyenne Doubler
leffort
Indisponibilit
des ressources
Impact sur le
dlai
Trs
possible
Retard de
livraison
Dangereux Sauvegarde
des
ralisations
Table 3: les estimations des risques

22

3.4- Langage de modlisation
La phase de conception ncessite un langage de modlisation permettant de mettre en place un modle
sur lequel le nouveau systme va sappuyer. En effet, la modlisation consiste crer une reprsentation
visuelle dune ralit de telle faon faire ressortir les points intressants.
UML offre une manire standard pour reprsenter le systme selon diffrentes vues complmentaires
grce aux diagrammes et au canevas de dveloppement structur. Cest ce qui a motiv notre choix. Ainsi,
UML est un concept permettant de modliser un problme de faon standard. Ce langage est n de la
fusion de plusieurs mthodes existant auparavant, et est devenu dsormais la rfrence en terme de
modlisation objet, un tel point que sa connaissance est souvent ncessaire pour obtenir un poste de
dveloppeur objet [B3].
UML se dcompose en plusieurs sous-ensembles :
Les vues : Les vues sont les lments observables du systme. Elles dcrivent le systme d'un point
de vue donn, qui peut tre organisationnel, dynamique, temporel, architectural, gographique,
logique, etc. En combinant toutes ces vues il est possible de dfinir (ou retrouver) le systme
complet.

Les diagrammes : Les diagrammes sont des graphiques. Ceux-ci dcrivent le contenu des vues,
qui sont des notions abstraites. Les diagrammes peuvent faire partie de plusieurs vues.

Les modles d'lment : Les modles d'lment sont les briques des diagrammes UML, ces
modles sont utiliss dans plusieurs types.
3.5- Planification du projet
Conduire un projet, cest assur le pilotage dun processus de changement avec des ressources ddies
en optimisant les comptences, lorganisation, les systmes et les outils de conduite.
Une approche managriale ractive, souple et systmatique pour mener bien des changements
importants, complexes, cibls sur le but atteindre. Il y a trois niveaux de gestion de projet : la gestion
de la production, des ressources et du temps. Afin de satisfaire ce dernier critre quest la gestion du
temps, il est ncessaire dtablir un planning prvisionnel. Sachant que la ressource affecte ce projet
est deux lves ingnieurs et que le prsent planning est rajust au fur et mesure de lavancement
du projet.
La premire tape de notre projet a t danalyser des besoins fonctionnels du systme en tudiant les
spcifications de notre projet. Cette tape nous a permis de dgager les besoins fonctionnels du projet.
Ensuite, nous avons effectu des recherches sur larchitecture logicielle afin de choisir lenvironnement
de dveloppement le plus adquat aux exigences techniques de notre application.

23

La seconde tape a t de proposer la modlisation du systme, puis la dernire tape a t de mettre
en uvre lenvironnement et implmenter notre application.
La Figure suivant prsente sommairement le planning des tapes du droulement de notre projet
Figure 2 :

Figure 2: Planning prvisionnel du projet

4- CONCLUSION

Apres avoir survol le contexte gnral dans lequel sinscrit notre projet dans cette premire partie de
ce mmoire, la dmarche prconise pour le raliser et, la description des besoins du projet, ltude
fonctionnelle sera dtaille dans le chapitre suivant.








Chapitre2 : Etude Fonctionnelle



Nous prsentons dans ce chapitre la spcification fonctionnelle, les acteurs, les diagrammes
de cas dutilisation et ceux de squence.











25

1- Ltude fonctionnelle dans le processus Y
La branche fonctionnelle Figure 3 du processus Y a pour objectif la capture des spcifications
et des contraintes fonctionnelles. Durant lanalyse, nous nous concentrons sur le mtier
indpendamment de toute technologie, et nous essayons dadapter le plus possible notre
systme aux besoins des utilisateurs.

Figure 3: Branche fonctionnelle du processus Y

2- Capture des besoins fonctionnels
La capture des besoins fonctionnels est la premire tape de la branche gauche du cycle en Y.
Dans cette section, nous allons formaliser et dtailler ce qui a t bauch au cours de ltude
prliminaire.
La capture des besoins fonctionnels a pour objectif :
Lidentification des cas dutilisation du systme par ses acteurs.
La description des cas dutilisation.
Lidentification des classes des modles danalyse.


26

3- Identification des acteurs
Un acteur reprsente labstraction dun rle jou par des entits externes (utilisateur, dispositif
matriel ou autre systme) qui interagissent directement avec le systme tudi. Il peut
consulter et/ou modifier directement ltat du systme, en mettant et/ou en recevant des
messages ventuellement porteurs des donnes [B4].
Aprs la phase danalyse, nous avons identifis six catgories dutilisateurs: Directeur,
Responsable dactivit, Juriste_envirommentaliste, Technicien_envirommentaliste, Auditeur
et Coordinateur.
Le tableau 4 suivant prsente les six acteurs identifient ainsi que le rle de chacun deux:
Acteur Type Description du Rle

Directeur
Humain
Son principal rle est de consulter
toutes les rubriques de lapplication.

Responsable dactivit
Humain
Il gre les activits et la relation avec
les autres entits.

Juriste_environemmentaliste
Humain
Il gre la partie rglementaire de
lenvironnement et assure une bonne
maitrise des impacts caus par les
polluants toute en prsentant les
actions entreprendre.

Technicien_envirommentaliste
Humain
Il mesure les polluants et leurs
impacts dans les activits.

Coordinateur
Humain Il gre les programmes et les tches.

27


Auditeur
Humain Il gre la partie audit de lapplication.
Table 4: Liste des acteurs
Nous avons dtermin tous les acteurs de lapplication, pour connaitre linteraction des acteurs
avec le systme, nous allons tablir le diagramme de cas dutilisation
4- Diagramme de cas dutilisation
Les diagrammes de cas d'utilisation sont des diagrammes UML utiliss pour donner une vision
globale du comportement fonctionnel d'un systme logiciel. En effet un cas dutilisation
reprsente une unit discrte d'interaction entre un utilisateur (humain ou machine) et le
systme. Cest une unit significative de travail. Dans un diagramme de cas d'utilisation, les
utilisateurs sont appels acteurs (actors) et ils interagissent avec les cas dutilisation (use
cases) [B3].
Ainsi, UML dfinit une notation graphique pour reprsenter les cas d'utilisation. Cette notation
est appele diagramme de cas d'utilisation. Il est ais de croire que cette notation graphique
suffit elle seule pour dcrire la nature d'un cas d'utilisation. Dans les faits, une notation
graphique ne peut donner qu'une vue gnrale simplifie d'un cas ou d'un ensemble de cas
d'utilisation. Les diagrammes de cas d'utilisation sont souvent confondus avec les cas
d'utilisation.
La figure 4 prsente le diagramme de cas d'utilisations de lacteur directeur et qui peut
consulter toutes les entits du projet.

Figure 4: Diagramme des cas dutilisation de lacteur Directeur

La figure 5 prsente le diagramme de cas d'utilisations de lacteur responsable dactivit. Il
peut grer les activits, les matriaux, les matires, le personnel et les emplacements.

28


Figure 5: Diagramme des cas dutilisation de lacteur Responsable activit

Description textuelle : UC Ajouter activit
Nom : Ajouter activit
Acteur(s) : Responsable activit
Description : Lajout dune activit se fait par un responsable activit.
Prconditions : Lutilisateur doit tre authentifi en tant que responsable activit.
Poste-condition : lajout de lactivit effectu.
Dmarrage : Lutilisateur a demand la page Ajouter activit
Scnario nominale :
Le systme affiche une page contenant la liste des activits.
Le responsable activit slectionne ajouter activit.
Le systme cherche les matriels.
Le responsable activit slectionne un matriel demand.
Le systme cherche les matires.
Le responsable activit slectionne une matire demande.
Le systme cherche les personnels.
Le responsable activit slectionne un personnel demand.

29

Le systme cherche les emplacements.
Le responsable activit slectionne un emplacement demand.
Le systme cherche les polluants.
Le responsable activit slectionne un matriel demand.
Le juriste enregistre lactivit.
Le systme affiche lactivit cre.

Scnario dexception :
Il peut que le polluant nexiste pas.
Scnario alternatif :
Demander au juriste environnementaliste dajouter le polluant dsir.

Maquette IHM : La figure 6 reprsente linterface homme /machine pour ajouter une activit.


Figure 6: Interface homme/machine d'ajout d'une activit

La figure 7 prsente le diagramme de cas d'utilisations de lacteur juriste environnementaliste.
Il peut grer les rglements, les polluants, les impacts et les actions.

30


Figure 7: Diagramme des cas dutilisation de lacteur Juriste environnementaliste

La figure 8 prsente le diagramme de cas d'utilisations de lacteur technicien
environnementaliste. Il peut mesurer les polluants et les impacts.

Figure 8: Diagramme des cas dutilisation de lacteur Technicien environnementaliste

Description textuelle : UC Ajouter mesurage
Nom : Ajouter mesurage
Acteur(s) : technicien environnementaliste
Description : Lajout dun mesurage se fait par un technicien environnementaliste pour
respecter la frquence du mesurage dun polluant.

31

Prconditions : Lutilisateur doit tre authentifi en tant que technicien environnementaliste.
Dmarrage : Lutilisateur a demand la page Mesurage
Scnario nominale :
Le systme affiche la liste la liste des activits.
Le technicien slectionne lactivit demand.
Le systme affiche la liste la liste des polluants de cette activit.
Le technicien slectionne un polluant demand.
Le technicien saisi les donnes et enregistre son opration.
Le systme affiche la liste mesurages.

Scnario dexception :
Lactivit nexiste pas.
Scnario alternatif :
Un message derreur qui demande dajouter une activit.
Maquette IHM : La figure 9 reprsente linterface homme /machine pour mesurer un polluant.

Figure 9: Interface homme/machine mesurage d'un polluant

La figure 10 prsente le diagramme de cas d'utilisations de lacteur coordinateur. Il peut grer
les programmes.

32


Figure 10: Diagramme des cas dutilisation de lacteur Coordinateur

La figure 11 prsente le diagramme de cas d'utilisations de lacteur auditeur. Il peut auditer les
activits.

Figure 11: Diagramme des cas dutilisation de lacteur Auditeur

La figure 12 prsente le diagramme de cas d'utilisations global de notre application.

33


Figure 12: Diagramme des cas dutilisation global

34

5- Diagramme de squence (boite noire)
Les diagrammes de squence sont couramment utiliss par un bon nombre d'acteurs d'un
projet. En effet, le diagramme de squence est une reprsentation intuitive lorsque l'on
souhaite concrtiser des interactions entre deux entits (deux sous-systmes ou deux classes
d'un futur logiciel).
Ils permettent l'architecte/designer de crer au fur et mesure sa solution. Cette
reprsentation intuitive est galement un excellent vecteur de communication dans une quipe
d'ingnierie pour discuter cette solution [B3].
Les diagrammes de squence peuvent galement servir pour les tests. Les traces d'excution
d'un test peuvent en effet tre reprsentes sous cette forme et servir de comparaison avec les
diagrammes de squence raliss lors des phases d'ingnierie.
Les diagrammes de squence tels que dfinis en UML souffraient cependant d'un gros
inconvnient. La quantit de diagrammes raliser pouvait atteindre un nombre lev ds lors
que l'on souhaitait dcrire avec un peu de dtail les diffrentes branches comportementales
d'une fonctionnalit.
La figure 13 montre la squence d'authentification. C'est la premire squence dclenche dans
ce projet. Lutilisateur envoi son login et password et attend la rponse pour tre redirig vers la
page d'accueil correspondante son profil.

Figure 13: diagramme de squence (Authentification)

35

La Figure 14 dmontre le processus suivi par le chef dactivit pour ajouter une activit.

Figure 14: diagramme de squence (Ajouter activit)

La Figure 15 dmontre le processus suivi par le chef dactivit pour supprimer une activit.

36


Figure 15: diagramme de squence (Supprimer activit)

La figure 16 reprsente la faon avec laquelle un directeur consulte toutes les entits du projet.

37


Figure 16: diagramme de squence (Consulter entit)

38

La Figure 17 dmontre le processus suivi par le technicien environnementaliste pour mesurer
des polluants.

Figure 17: diagramme de squence (Mesurer Polluant)

La Figure 18 dmontre le processus suivi par lauditeur pour auditer les activits.

39


Figure 18: diagramme de squence (Auditer Activits)

6- Conclusion
Dans ce chapitre, nous avons prsent les acteurs de notre systme, les diagrammes des cas
dutilisation avec leurs descriptions ainsi que les diagrammes de squence des scnarios les
plus importants. Le chapitre suivant sera consacr ltude technique du projet.


Projet de Fin dtudes 2013-2014









Chapitre 3 : Etude technique


Ce chapitre est consacr conformment au cycle de dveloppement en Y, la branche
technique. Dans cette partie, nous allons aborder la capture des besoins techniques,
Larchitecture-tiers, les designs patterns, les systmes et la conception gnrique.














41

1- Ltude technique dans le processus Y
Lobjectif de la branche technique du processus Y Figure 19 est de recenser les
contraintes et les choix techniques et matriels dimensionnant la conception du systme.
Le but est dviter les risques techniques et les problmes que lapplication pourrait
rencontrer tels que les problmes dintgration, de maintenance, d'volution

Figure 19: Branche technique du processus Y

2- Capture de besoin technique
La capture des besoins techniques couvre, par complmentarit avec celle des besoins
fonctionnels, toutes les contraintes qui ne traitent ni de la description du mtier des
utilisateurs, ni de la description applicative. La spcification technique est une activit
primordiale pour la conception darchitecture.
3- Spcification technique
Les prrequis techniques ont t exprims dans ltude prliminaire, lors de lexpression
des besoins oprationnels. Elles concernent la performance daccs aux donnes, la
scurit du systme, linteroprabilit, lintgrit des donnes, la disponibilit, et la
fiabilit.

42

3.1- Spcification darchitecture
Lexpression des prs requis techniques implique galement le choix dun style
darchitecture client/serveur. Ce choix conditionne la faon dont seront organiss et
dploys les composants dexploitation du systme.
Composant dexploitation et composant mtier
Un composant dexploitation est une partie du systme logiciel qui doit tre connue,
install, dclar et manipul par les exploitants du systme.
Un composant dexploitation doit tre interchangeable entre diffrentes versions et
peut tre arrt ou dmarr sparment. Il assume des fonctions bien identifies
dans le systme, de sorte quen cas de dysfonctionnement, le composant incrimin
est facilement reprable.
Un composant mtier est un composant dexploitation dont la fonction est de
distribuer les services dun ou de plusieurs objets mtier de lentreprise.
Lintgration de composants mtier implique le recours un style darchitecture 3-tiers.
Style darchitecture en tiers :
Le style darchitecture en tiers (tiers signifie partie en anglais) spcifie lorganisation
des composants dexploitation mis en uvre pour raliser le systme. Chaque partie
indique une responsabilit technique laquelle souscrivent les diffrents composants
dexploitation dun systme.
Nous avons distingu donc plusieurs types de composants en fonction de la responsabilit
technique quils jouent dans le systme. Un systme client/serveur fait rfrence au moins
deux types de composants, qui sont les systmes de base de donnes en serveur, et les
applications qui en exploitent les donnes en client.
Le style darchitecture 2-tiers correspond la configuration la plus simple dun systme
client/serveur. Dans ce cas, il incombe aux clients de grer linterface utilisateur et les
processus dexploitation. Les serveurs ont pour responsabilit de traiter le stockage des
donnes.

43

Lintgration des objets mtier sous la forme de composants mtiers fait passer
larchitecture client/serveur du 2-tiers au 3-tiers, car elle implique un nouveau type de
composants dexploitation qui sinsre entre les clients et les serveurs de donnes.
Larchitecture 3-tiers Figure 20 a t davantage choisie parce quelle permet de satisfaire
les exigences techniques que nous avons repris au niveau de la spcification des besoins
techniques savoir essentiellement :
La scurit : elle permet de la dfinir indpendamment de service et de chaque
niveau.
La performance : elle est assure du fait du partage des tches entre les diffrents
serveurs.
La disponibilit : elle est assure pour les mmes raisons que la performance

Larchitecture adopte pour notre application est celle la plus utilise dans le
dveloppement des grandes applications, cest larchitecture 3-tiers. Elle permet de rendre
les trois couches (prsentation, mtier et accs aux donnes) indpendantes les unes des
autres grce aux interfaces :
La couche Prsentation : Elle reprsente le premier niveau de larchitecture et est la
partie visible de lapplication et interactive avec lutilisateur. Dans notre cas, elle est
reprsente en HTML et est exploite par des navigateurs Web.

La couche Mtier : Cest la couche du second niveau de larchitecture. Elle reprsente
la partie fonctionnelle de lapplication. Cette couche opre sur les donnes en fonction
des requtes des utilisateurs effectues au travers de la couche prsentation (Couche
intermdiaire).

La couche accs aux donnes : La fonction principale de cette couche est de grer les
donnes. La faon dont elle organise, manipule et stocke les donnes est transparente
vis--vis des applications externes et des utilisateurs.


44


Figure 20: Architecture 3 tiers
Nous peuvons citer quelques avantages de cette architecture, savoir :
Les fonctionnalits de chaque couche peuvent valuer sans induire de changement dans
les autres couches.
Amlioration de la scurit des donnes, en supprimant le lien entre lapplication et les
donnes.
Vrification de lintgrit et la validit des donnes avant de les envoyer dans la couche
de donnes.
Meilleure rpartition de la charge entre diffrents serveurs dapplication.

3.2- Design patterns MVC
Pour raliser notre projet nous avons utilis les Pattern MVC Figure 21 :

Figure 21: Architecture du dsigne pattern MVC


45

L'architecture (Modle Vue Contrleur) est une mthode de conception pour le
dveloppement d'applications logicielles qui spare le modle de donnes, l'interface
utilisateur et la logique de contrle. Ce modle d'architecture impose la sparation entre les
donnes, les traitements et la prsentation, ce qui donne trois parties fondamentales dans
l'application finale le modle, la vue et le contrleur :
Le Modle : reprsente le comportement de l'application : traitements des donnes,
interactions avec la base de donnes, etc. Il dcrit les donnes manipules par
l'application et dfinit les mthodes d'accs.
La Vue : correspond l'interface avec laquelle l'utilisateur interagit. Les rsultats
renvoys par le modle sont dnus de toute prsentation mais sont prsents par les
vues. Plusieurs vues peuvent afficher les informations d'un mme modle. Elle peut tre
conue en html, ou tout autre langage de prsentation. La vue n'effectue aucun
traitement, elle se contente d'afficher les rsultats des traitements effectus par le
modle, et de permettre l'utilisateur d'interagir avec elles.
Le Contrleur : prend en charge la gestion des vnements de synchronisation pour
mettre jour la vue ou le modle. Il n'effectue aucun traitement, ne modifie aucune
donne, il analyse la requte du client et se contente d'appeler le modle adquat et de
renvoyer la vue correspondant la demande
En rsum, lorsqu'un client envoie une requte l'application, celle-ci est analyse par le
contrleur, qui demande au modle appropri d'effectuer les traitements, puis renvoie la
vue adapte au navigateur, si le modle ne l'a pas dj fait. Un avantage apport par ce
modle est la clart de l'architecture qu'il impose. Cela simplifie la tche du dveloppeur
qui tenterait d'effectuer une maintenance ou une amlioration sur le projet. En effet, la
modification des traitements ne change en rien la vue. Par exemple on peut passer d'une
base de donnes de type SQL XML en changeant simplement les traitements d'interaction
avec la base, et les vues ne s'en trouvent pas affectes. Comme exemple, Swing la
bibliothque graphique de Java pour la cration dinterfaces graphiques, est base sur le
modle MVC.



46

4- Conception gnrique

Elle consiste dvelopper la solution qui rpond aux spcifications techniques que nous
avons prsentes ltape capture des besoins techniques. Cette conception est qualifie
de gnrique car elle est entirement indpendante des aspects fonctionnels spcifis au
niveau de la branche de gauche. La conception gnrique reste donc une activit de la
branche de droite.
La standardisation des techniques de dveloppement, laquelle nous avons assist ces
dernires annes, rend cette tape moins consquente quavant. En effet, la diffusion de
composants gratuits, tels que Framework Symfony2, MAMP, propose en quelque sorte
des architectures logicielles cls en main, et gnralement de qualit, quil suffit de
rutiliser. Cest pour cette raison que nous allons focaliser sur lexigence technique
principale de notre projet, nous avons cit les technologies, Framework et composants
utiliss.

5- Conclusion
Dans ce chapitre, nous avons abord la description des spcifications techniques et
larchitecture logicielle.
Le chapitre suivant sera consacr la phase de Mise en uvre de la solution.


Projet de Fin dtudes 2013-2014







Chapitre 4 : Mise en uvre de la
solution


Lobjectif de ce chapitre, nous allons successivement aborder les phases suivantes :
Conception prliminaire,
Conception dtaille.



48

1- La mise en uvre dans le processus Y
Aprs les tudes fonctionnelle et technique, nous prsentons dans ce qui suit la phase de
conception prliminaire et dtaille pour chaque module (Figure 22).

Figure 22: Phase de mise en uvre dans le processus Y

2- La conception prliminaire
La conception prliminaire est certainement ltape la plus dlicate du processus 2TUP
car elle en reprsente le cur du projet. Cest en effet cette occasion que seffectue la
fusion des tudes fonctionnelles et techniques. En consquence, plusieurs activits doivent
coexister. Il convient de:
Passer de lanalyse objet la conception.
Intgrer les fonctions mtier et applicatives du systme dans larchitecture
technique.
Adapter la conception gnrique aux spcifications fournies par lanalyse. La
conception prliminaire sappuie sur les points de vue de spcification fonctionnelle
et structurelle de lanalyse.

49

2.1- Architecture logicielle implmente
Larchitecture logicielle vient pour dmontrer comment le systme informatique doit tre
conu de manire rpondre aux spcifications de la matrise douvrage. Larchitecture
logicielle implmente se prsente comme suit Figure 23 :

Figure 23: Architecture logicielle du projet

2.2- numration des vues de lapplication

Cette section consiste lister les interfaces IHM qui dfinissent les vues travers
lesquelles les utilisateurs interagissent avec les diffrents composants du systme.
Nous prsentons dans le tableau ci-aprs, les plus importantes dentre elles Tableau 5 :
IHM Description
Linterface de prise en
compte dun utilisateur
Linterface dajout dun utilisateur qui permet ladministrateur
dajouter un utilisateur et lui affecter un rle ce qui va lui donner
des privilges sur ses propres vues.

50

Linterface dajout dune
activit
Linterface dajout dune activit. Dans laquelle le responsable
dactivit saisit les champs suivant : Type d'Activit, Condition
de Fonctionnement, Emplacement, Matire, Quantit matire,
Matriel, Quantit matriel, Personnel, Date affectation, Date
fin, Polluant, Frquence mesure et le Seuil.
Linterface dajout dun
polluant
Linterface dajout dun polluant dans laquelle le juriste
environnementaliste saisit les champs suivant : Nom polluant,
Rglement, Type action, Cout action, Standard, Degr gravite,
Mesurage, Action, Date traitement, Degr conformit et
Commentaire traitement.
Linterface de mesurage
dun polluant
Linterface de mesurage dun polluant dans laquelle le
technicien environnemental saisit les champs suivant : Type de
mesurage, Type de rejet, Point de mesure, Paramtre mesurer,
Laboratoire, Date de mesurage, Activit, Polluant et Rsultat.
Linterface dauditer les
activits
Cette interface permet lauditeur dauditer les activits
prcdentes et lister les anciennes erreurs pour dvelopper les
activits au futur.
Linterface de grer tous
les programmes
Cette interface permet au coordinateur de grer tous les
programmes disponibles dans lapplication (afficher, modifier
ou supprimer)
Linterface
dauthentification
Cette interface permet de connecter chaque utilisateur
(Directeur, Responsable dactivit, Juriste Environnementaliste,
Technicien Environnemental, Coordinateur et lAuditeur) et le
redirige vers son propre vue selon son privilge.
Table 5: Les vues de l'application



51

3- Diagramme de classes
Le diagramme de classes est un schma utilis en gnie logiciel pour prsenter les classes
et les interfaces d'un systme ainsi que les diffrentes relations entre celles-ci. Ce
diagramme appartient la partie statique d'UML. Car il fait abstraction des aspects
temporels et dynamiques [B3].
Une classe dcrit les responsabilits, le comportement et le type d'un ensemble d'objets.
Les lments de cet ensemble sont les instances de la classe. En particulier, une classe est
un ensemble de fonctions et de donnes (attributs) qui sont lies ensembles par un champ
smantique. Les classes sont utilises dans la programmation oriente objet. Elles
permettent de modliser un programme et ainsi de dcouper une tche complexe en
plusieurs petits travaux simples.
Les classes peuvent tre lies entre elles grce au mcanisme d'hritage qui permet de
mettre en vidence des relations de parent. D'autres relations sont possibles entre des
classes, chacune de ces relations est reprsente par un arc spcifique dans le diagramme
de classes.
Elles sont finalement instancies pour crer des objets (une classe est un moule objet :
elle dcrit les caractristiques des objets, les objets contiennent leurs valeurs propres pour
chacune de ces caractristiques lorsqu'ils sont instancis).
Notre diagramme de classes est prsent dans ce qui suit .Nous lavons divis en deux
parties pour la lisibilit des entits.

La premire partie :
La figure 24 reprsente la premire partie du diagramme de classe

52


Figure 24: La premire partie de notre diagramme de classes


La deuxime partie :
La figure 25 reprsente la deuxime partie du diagramme de classes

53


Figure 25: La deuxime partie de notre diagramme de classes

Le diagramme de classes final obtenu aprs fusion des diffrentes parties se prsente
comme suit Figure 26 :

54


Figure 26: Diagramme de classes

55

4- La Conception dtaille
La conception dtaille qui vient juste aprs est une activit qui sinscrit dans lorganisation
dfinie par la conception prliminaire. Le modle logique en Y est particulirement
important dans la mesure o cest dans cette tape quon gnre le plus grand nombre
dinformations. Il est ainsi possible de confier les catgories des personnes diffrentes,
qui pourront travailler indpendamment les unes des autres. Les concepteurs dans cette
phase construisent les classes, les vues dIHM, les interfaces, les tables et les mthodes qui
vont donner une image prte coder de la solution.
4.1- Conception des attributs
Dans cette section, nous allons dfinir le type dattributs identifis en analyse. Nous
pouvons dores et dj constater que tous les attributs des diffrentes classes se satisfassent
des types de base de PHP5. Concevoir les attributs, cest galement prciser leur visibilit
et leur mode daccs. Pour notre part, les attributs sont privs. Enfin concevoir les attributs
cest aussi spcifier les mthodes qui servent la mise jour des attributs.
4.2- Conception des classes
Les classes issues de lanalyse sont conformes aux possibilits offertes par PHP5 le
langage dimplmentation choisi. Nous navons donc pas dautres classes en dehors de
celles provenant de lanalyse.
4.3- Description des classes
Dans cette section nous allons dcrire quelques classes tableau 6 et 7:
Classe : Activit

Attributs
Visibilit Nom Description Type Contrainte
Private id
Identifiant de
lactivit
Entier
Cl unique
Private typeActivite Nom de lactivit Texte
Private conditionFonctionnement
Condition de
fonctionnement
de lactivit
Texte

Private emplacement
Lemplacement
de lactivit
Objet


56

Private activiteMatieres
Les matires de
lactivit
Collection

Private activiteMateriels
Les matriels de
lactivit
Collection

Private activitePersonnels
Les personnels
de lactivit
Collection

Private activitePolluants
Les polluants
fournis par
lactivit
Collection

Private mesurageActivitePolluants
Les mesurages
des polluants de
lactivit
Collection

Private audits
Les audits de
lactivit
Collection


Mthode
s
Visibilit Nom Description
Public addEmplacement ()
Permet dajouter lemplacement
de lactivit

Public addActivitePolluant ()
Permet dajouter les polluants de
lactivit

Public
addMesurageActivitePollu
ant ()
Permet dafficher les mesurages
des polluants de lactivit.

Public
removeActivitePersonnel
()
Permet de supprimer les
personnels de lactivit.

Table 6: Description de classe activit

Classe : Polluant

Attributs
Visibilit Nom Description Type Contrainte
Private id
Identifiant de
polluant.
Entier
Cl unique
Private nomPolluant
Nom de
polluant
Texte

Private reglement
Les rglements
pour un
polluant.
Objet


57

Private actions
les actions de
polluant.
Collection

Private
polluantMesurageActi
ons
les mesurages
et les actions
de polluant.
Collection


Mthodes
Visibilit Nom Description
Public getActivitePolluants ()
Permet dafficher les activits
dont le polluant est survenu.

Public
addPolluantMesurage
Action ()
Permet dajouter un
mesurage et une action pour
un polluant.

Public setReglement ()
Permet de modifier un
rglement dun polluant.

Public removeAction ()
Permet de supprimer une
action existante.

Table 7: Description de la classe formation

5- Diagramme de squences (Boite blanche)
Nous prsentons dans ce qui suit, Figure 27, le diagramme de squences en boite
blanche de l'ajout d'une nouvelle activit par un chef dactivits.








Figure 27: Diagramme de squences (Ajout d'activit)


58

La Figure 28 prsente le processus de mesurage dun polluant par un technicien
environnementaliste.








Figure 28: Diagramme de squences (Mesurer polluant)

La Figure 29 prsente le processus dajout dun programme par un coordinateur.








Figure 29: Diagramme de squences (Ajouter programme)





59


6- Diagramme dActivit
Un diagramme d'activit permet de modliser un processus interactif, global ou partiel pour
un systme donn (logiciel, systme d'information). Il est recommandable pour exprimer
une dimension temporelle sur une partie du modle, partir de diagrammes de classes ou
de cas d'utilisation, par exemple [B3].
Le diagramme d'activit est une reprsentation proche de l'organigramme ; la description
d'un cas d'utilisation par un diagramme d'activit correspond sa traduction algorithmique.
Une activit est l'excution d'une partie du cas d'utilisation, elle est reprsente par un
rectangle aux bords arrondis.
Le diagramme d'activit est smantiquement proche des diagrammes de communication
(appels diagramme de collaboration en UML 1), ou d'tat-transitions, ces derniers offrant
une vision microscopique des objets du systme.
Dans notre projet nous avons ralis deux diagrammes dactivit, la figure 30 suivante
prsente le diagramme dactivit du mesurage dun polluant :

Figure 30: diagramme dactivit (Mesurer un polluant)

60

Nous prsentons ci-dessous, dans la Figure 31 le diagramme dactivit dajoute dun
polluant :

Figure 31: Diagramme dactivit (Ajouter polluant)

7- Diagramme des paquetages
Les diagrammes de paquetages sont la reprsentation graphique des relations existant
entre les paquetages (ou espaces de noms) composant un systme, dans le langage UML.
Les paquetages peuvent avoir des relations de dpendances UML classiques , ou bien
des dpendances spciales de types package import (importation de paquetage) et
package merge (fusion de paquetages) [B4].
Un package import est une relation entre un paquetage important un espace de nom et
un paquetage, indiquant que l'espace de nom qui importe ajoute les noms des membres
du paquetage son propre espace de nom. Par dfaut, une dpendance entre deux
paquetages est interprte comme une relation de type package import.

61

Un package merge est une relation dirige entre deux paquetages, indiquant que les
contenus des deux paquetages doivent tre combins. Elle est trs similaire la relation
de gnralisation dans le sens o l'lment source ajoute conceptuellement les
caractristiques de l'lment cible ses propres caractristiques, rsultant en un lment
combinant les caractristiques des deux.
Les diagrammes de paquetages peuvent utiliser des paquetages pour illustrer les
diffrentes couches de l'architecture en couches d'un systme logiciel. Les dpendances
entre paquetages peuvent tre pares d'tiquettes ou de strotypes pour indiquer les
mcanismes de communication entre les couches.
Dans notre projet nous avons ralis un diagramme des paquetages, la figure 32 suivante
prsente le diagramme des paquetages de notre application :

Figure 32: Diagramme des paquetages

8- Conclusion
Dans ce chapitre nous avons prsent la conception prliminaire, la conception dtaille
par le biais du diagramme de classes, celui de squences en boite blanche et celui
dactivit (package ou dploiement) documenter.
Nous prsentons dans le chapitre suivant, ltape de ralisation travers les choix
technologiques ainsi que les diffrentes captures dcrans.

62











Chapitre 5 : Ralisation


Lobjectif de ce chapitre qui constitue la dernire branche du processus de dveloppement
2TUP, est la concrtisation du modle de conception prsent lors des prcdents chapitres
en des couches applicatives et des interfaces homme/machine et de les tester pour valuer
les objectifs. Dans cette partie, nous allons essentiellement nous taler sur les tches
suivantes:
Implmentation des IHM.
Codage et tests.
Dploiement.





63

1- La Ralisation dans le processus Y
Aprs la phase de conception prliminaire et dtaille, nous dtaillons la phase de codage
et les tests pour chaque module (Figure 33). Ces modules sont tests unitairement en vue
dtre intgres dans le systme tout entier. Une fois cette tape est termine, le systme
sera prt pour lactivit de test dacceptation. Cette activit a pour but de tester le systme
fabriqu en implmentation.

Figure 33: Phase de ralisation dans le processus Y

2- Technologies et outils utilises
Pour satisfaire les besoins fonctionnels et techniques numrs dans ltude prliminaire,
nous avons opts pour les technologies suivantes :
2.1- Symfony2
Symfony2 est un Framework MVC libre crit en PHP 5. En tant que Framework, il facilite
et acclre le dveloppement de sites et d'applications Internet et Intranet.
Le site du Framework Symfony a t lanc en octobre 2005. l'origine du projet, on trouve
une agence web franaise, Sensio, qui a dvelopp ce qui s'appelait l'poque Sensio

64

Framework pour ses propres besoins et a ensuite souhait en partager le code avec la
communaut des dveloppeurs PHP.
Le projet est alors devenu Symfony (car le crateur voulait garder les initiales SF comme
"Sensio Framework"), puis Symfony partir de la version 2.02.
La version 2 de Symfony casse la compatibilit avec la branche 1.x. Ses fonctionnalits
font choisir ce Framework comme base de la version 8 du populaire systme de gestion de
contenu Drupal.
Symfony2 propose entre autres :
Une sparation du code en trois couches, selon le modle MVC, pour une plus
grande maintenabilit et volutivit.
Un templating simple, fond sur PHP et des jeux de fonctions additionnelles pour
les gabarits nommes helpers.
Des performances optimises et un systme de cache afin d'assurer des temps de
rponse optimaux.
Une gestion des url parlante, permettant une page d'avoir une URL distincte de sa
position dans l'arborescence.
Un systme de configuration en cascade utilisant pleinement le langage YAML.
Un gnrateur de back-office et un lanceur de module (scaffolding).
L'internationalisation native.
Une couche de mapping objet-relationnel (ORM) et une d'abstraction de donnes.
Le support d'AJAX.
Une architecture extensible permettant crations et utilisations de plugins.
Symfony fournit une interface en ligne de commande pour amliorer la productivit
en crant un code de base modifiable volont.


65

La figure 34 suivante prsente le fonctionnement du Framework Symfony2 avec lentit
activit de notre projet:




















Figure 34: Fonctionnement de Symfony2



66

2.2- Doctrine
Doctrine est un Object-Relational Mapping(ORM) compos dnormes fonctionnalits
commencer par le DQL (Doctrine Query Language). Le DQL permet de crer et dexcuter
les requtes via le paradigme de la programmation oriente objet. Il sest beaucoup fait
connaitre grce au Framework Symfony, dans la mesure o Doctrine est un projet toujours
maintenu [W4].
2.3- Twig
Twig est un moteur de Template PHP directement intgr dans Symfony 2. Trs puissant,
Twig permettra de grer lhritage entre Template et Layout, sparer les couches de
prsentation et les couches mtiers... Idal pour travailler en quipe avec des intgrateurs,
qui nauront qu modifier les Template dans le rpertoire views/ de bundle de symfony.
Lobjectif des templates twig, est de sparer le code PHP du code HTML. [W4].
2.4- PHP 5
PHP 5 est un langage de programmation. Sa principale application se situe au niveau de la
gestion des sites web dynamiques [B6].
Les capacits de PHP 5 ne sarrtent pas la cration de pages web. Il est aussi possible de
manipuler des images, de crer des fichiers PDF, de se connecter des bases de donnes
ou des serveurs LDAP, et mme dinstancier des objets Java. Un module annexe lui permet
galement de fournir des interfaces graphiques classiques (client lourd, sans navigateur ou
serveur web).
PHP 5 est lorigine un langage de script conu spcifiquement pour agir sur les serveurs
web. En ajoutant quelques lignes de PHP 5 une page HTML, le serveur excute les
instructions correspondantes pour crire du code HTML la place. Le rsultat (le code
HTML initial ajout celui produit par PHP 5) est envoy au navigateur. Cela permet par
exemple dafficher la date du jour un endroit bien prcis du visuel. On parle alors de page
dynamique.
PHP dispose de prs de 3 000 fonctions utilisables dans des applications trs varies et
couvre pratiquement tous les domaines en rapport avec les applications web. PHP 5 et ses
nouveauts propulsent PHP dans le monde des plates-formes dentreprises comme .Net ou
J2EE.

67

2.5- JavaScript
Cest un langage de script incorpor dans un document HTML. Historiquement il s'agit du
premier langage de script pour le Web. Ce langage est un langage de programmation qui
permet d'apporter des amliorations au langage HTM pour excuter des commandes du
ct client, c'est--dire au niveau du navigateur et non du serveur web. JavaScript a t mis
au point par Netscape en 1995. A l'origine, il se nommait LiveScript et tait destin
fournir un langage de script simple au navigateur Netscape Navigator 2. Il a, l'poque,
longtemps t critiqu pour son manque de scurit, son dveloppement peu pouss et
l'absence de messages d'erreur explicites rendant difficile son utilisation. Le 4 dcembre
1995, suite une association avec le constructeur Sun, Netscape rebaptise son langage
JavaScript (un clin d'il au langage Java dvelopp par Sun). A la mme poque, Microsoft
mit au point le langage Jscript, un langage de script trs similaire [W5].
Ainsi, pour viter des drives de part et d'autre, un standard a t dfini pour normaliser les
langages de script, il s'agit de l'ECMA 262, cr par l'organisation du mme nom (ECMA,
European Computer Manufactures Association).
2.6- jQuery
jQuery est une bibliothque JavaScript libre et multi-plateforme cre pour faciliter
l'criture de scripts ct client dans le code HTML des pages web1. La premire version
est lance en janvier 2006 par John Resig [B9].
La bibliothque contient notamment les fonctionnalits suivantes :
Parcours et modification du ;
vnements ;
Effets visuels et animations ;
Manipulations des feuilles de style en cascade;
Ajax ;
Plugins ;
Utilitaires (version du navigateur web).
2.7- AJAX
Ajax dsigne une approche innovante dans la conception de pages web dont l'objectif est
d'optimiser leur interactivit et leur confort d'utilisation conjointe dans les pages web de

68

diffrentes technologies [B8]. Ainsi AJAX incorpore :
le XHTML et les feuilles de style CSS
le JavaScript
le DOM
lObject XMLHttpRequest
le XML et le XSL
2.8- Microsoft Project
Microsoft Project (ou MS Project ou MSP) est un logiciel de gestion de projets dit par
Microsoft. Il permet aux chefs de projet et aux planificateurs de planifier et piloter les
projets, de grer les ressources et le budget, ainsi que d'analyser et communiquer les
donnes des projets [W6].
Microsoft Project permet la planification des projets, cest--dire la cration dun plan. Il
permet la cration de tches et de jalons, leur hirarchisation, et de dfinir des liens entre
les tches. Une estimation de la dure et de la charge (ou travail) ncessaire la ralisation
de chaque tche peut ensuite tre ralise.
Microsoft Project permet la gestion des ressources de chaque projet, cest--dire la cration
de lquipe projet puis laffectation des ressources dfinies.
Microsoft Project offre une palette de possibilits danalyse des donnes du projet et
propose de nombreux rapports. Il est mme possible dexporter les informations du projet
dans Microsoft Excel ou Microsoft Visio pour analyser le travail et les cots du projet en
fonction de diffrents axes danalyse (tches, ressources, affectation, temps), via des
tableaux, graphiques et diagrammes croiss dynamiques.
Microsoft Project permet de communiquer les informations des projets : copie du
diagramme de Gantt, impression et surtout, depuis la version 2010, possibilit de crer une
frise chronologique exportable vers Microsoft PowerPoint ou dans un message
lectronique.

69

2.9- PHPUnit
PHPUnit est un Framework de tests unitaires open source ddi au langage de
programmation PHP. Cr par Sbastian Bergmann, il intgre les concepts communs aux
bibliothques de tests unitaires xUnit [W7].
2.10- PHP Storm
PHP Storm est un diteur de code pour PHP avec la coloration syntaxique , code tendu
configuration mise en forme, sur la vole de contrle d'erreur, et la compltion de code .
Cest un EDI qui regroupe dans une mme interface les fonctionnalits indispensables la
ralisation et au suivi du projet tout au long de son cycle de vie. Il contient un diteur
performant simplifiant lcriture de code, mais aussi un dbogueur, un outil de gestion de
versions, un outil de gestion de tches, la prise en charge des tests unitaires ou encore des
outils de dploiement. PHP Storm intgre tout ceci de faon intuitive et efficace.
2.11- Enterprise Architect
Outil de Modlisation UML / BPMN / SysML et dingnierie dirige par les modles
(Model-Driven) Enterprise Architect est lun des outils de modlisation UML les plus
utiliss dans le monde. Ce succs est d plusieurs facteurs : un support complet dUML
2.4.1, une excellente ergonomie, un niveau de performance lev, des versions frquentes
et enfin un cot dacquisition et de maintenance ultra comptitifs.
Enterprise Architect bnficie dune communaut trs active et de lapprobation des
organismes de standardisation tels que lOMG. Il a fait ses preuves par des rsultats
exceptionnels sur de nombreux projets.
Fort de 12 ans de dveloppement par Sparx Systems, Enterprise Architect est employ par
de nombreuses entreprises dans tous les domaines dactivit ainsi que par diffrents
organismes de normalisation [W8].
2.12- MAMP
MAMP est une application libre regroupant en son sein un serveur web apache, un serveur
de base de donnes (MySQL), un serveur FTP mais galement PHP qui communique avec
le serveur web apache et traite les pages PHP. Il offre aussi d'une interface agrable
(PHPMyAdmin) pour grer aisment les bases de donnes [W9].

70

2.10.1- MySQL
MySQL est un systme de gestion de bases de donnes relationnelles SQL dvelopp dans
un souci de performances leves en lecture, ce qui signifie qu'il est davantage orient vers
le service de donnes dj en place que vers celui de mise jour frquentes et fortement
scurises. Il est multi-thread et multi-utilisateur. C'est un logiciel dvelopp sous double
licence en fonction de l'utilisation qui en est faite: dans un produit libre ou dans un produit
propritaire [W10].
2.10.2- Apache
Apache est un serveur HTTP cr et maintenu au sein de la fondation Apache. C'est le
serveur HTTP le plus populaire du World Wide Web. Il est distribu selon les termes de la
licence Apache.
Apache est conu pour prendre en charge de nombreux modules lui donnant des
fonctionnalits supplmentaires : interprtation du langage Perl, PHP, Python et Ruby,
serveur proxy, Common Gateway Interface, Server SideIncludes, rcriture d'URL,
ngociation de contenu, protocoles de communication additionnels, etc. Nanmoins, il est
noter que l'existence de nombreux modules Apache complexifie la configuration du
serveur web [W11].
2.13- LabVIEW
LabVIEW (abrviation de laboratoire virtuel des instruments d'ingnierie Workbench) est
une plate-forme de conception du systme et de l'environnement de dveloppement d'un
langage de programmation visuel de National Instruments .
Le langage graphique est nomm G ( ne pas confondre avec G-Code ). Initialement
publi pour le Apple Macintosh en 1986, LabVIEW est couramment utilis pour
l'acquisition des donnes , le contrle de l'appareil , et l'automatisation industrielle sur une
varit de plates-formes, y compris Microsoft Windows , les diffrentes versions de UNIX
, Linux et Mac OS X [W12].

3- Implmentation des IHM
Nous prsentons dans cette section un aperu de quelques interfaces homme-machines de
lapplication, rsultat de la ralisation des diffrents modules fonctionnels conus.

71

3.1- Linterface daccueil de lapplication
Cest la page daccs par dfaut lapplication. Parmi les composants principaux de la
page daccueil:
Zone pour afficher les statistiques de lapplication.
Zone de gestion des profils.
Zone des diffrents modules disponibles.


Figure 35: L'interface d'accueil de l'application
3.2- Linterface dauthentification
A partir de cette interface lutilisateur peut accder son profil selon son rle.

Figure 36: L'interface d'authentification

72

3.3- Linterface de cration dun type de profil et son rle
Cette vue reprsente le formulaire qui permet ladministrateur de crer un type de
profil et son rle sur la plateforme de lapplication.

Figure 37: L'interface de cration d'un type de profil et son rle

3.4- Linterface dajout dune activit
Un formulaire saffiche lors que le responsable dactivit veut ajouter une activit dans la
plateforme de lapplication.

Figure 38: L'interface d'ajout d'une activit

73

3.5- Linterface de lister des mesurages
Cette vue permet lauditeur, directeur et technicien environnemental de lister les
mesurages raliss dans lapplication.


Figure 39: L'interface de lister des mesurages

3.6- Linterface de vision dun programme
Cette vue permet au coordinateur de consulter un programme parmi les listes des
programmes de lapplication.

Figure 40: L'interface de vision dun programme

74

3.7- Linterface de lister les mesurages des impacts avec
LabView
Cette vue permet lutilisateur de lister les impacts et dafficher ses tats.

Figure 41: L'interface des mesurages des impacts

4- Phase de tests et validation
En informatique, un test dsigne une procdure de vrification partielle d'un systme
informatique. Le but en est de trouver un nombre maximum de comportements
problmatiques du logiciel, car il est impossible de prouver qu'un logiciel fonctionne bien
dans tous les cas. Plus on trouve d'erreurs, plus il y a de chances qu'il y ait davantage
d'erreurs dans le composant logiciel vis. Les tests de vrification ou de validation visent
s'assurer que ce systme ragit de la faon prvue par ses concepteurs (spcifications) ou
est conforme aux attentes du client l'ayant command (besoins), respectivement.

Nous avons utiliss Le Framework de Test PHPUnit qui fournit un Framework de test
complet. Nous allons prsenter une liste des modules de test, scnario de test et le rsultat
obtenu partir du tableau 8 :

Module Scnario de test Rsultat obtenu
Connexions lapplication Entre un login et un mot de
passe correcte
Excution correcte

75

Entre un login et un mot de
passe incorrecte
Excution correcte
Connexion la base des
donnes
Slectionner des donnes de
la base de donnes
Excution correcte
Gestion des donnes
statiques
Insertion des donnes
statiques
Excution correcte
Consultation des donnes Excution correcte
Gestion des interfaces
graphique
Insertion des donnes
alphabtique la place des
numrique
Excution correcte
Gestion des exceptions
Insertion de donnes
existantes
Excution correcte
Slectionne des donnes
inexistantes dans la base des
donnes.
Excution correcte
Transfert correcte des
informations entres les
interfaces
Excution correcte
Mise jour de la base des
donnes chaque
modification
Excution correcte
Envoyer une requte au
serveur

Insertion dans la base des
donns
Excution correcte
Table 8: Les tests unitaires de l'application


5- Conclusion
Dans ce chapitre, nous avons prsent, larchitecture logicielle et applicative ainsi que
linterface homme/machine.
Ce chapitre boucle galement le processus 2TUP qui nous avons adopt pour mener
bien ce projet.

76

Conclusion gnrale et perspectives

Tout au long de ce projet nous avons t amens concevoir et implmenter une
application web pour la gestion de lenvironnement selon la norme ISO 14001 sous le
Framework Symfony2. Conformment ce que nous avons spci, nous sommes
parvenus mettre en uvre une application web pour la gestion environnementale.
Le projet ralis a consist en la mise en place dune application permettant la gestion des
entits, des activits, des polluants, de la rglementation, des formations environnementales
de lapplication
Nous avons aussi ralis une module de Un module de reporting pour lextraction des
rapports, des bilans, des statistiques, des seuils, au format PDF afin doptimiser la
supervision et le pilotage environnemental de lorganisme.
Nous avons aussi ralis dans ce projet un module de monitoring permettant doffrir aux
dcideurs un tableau de bord qui rassemble lensemble d'indicateurs de pilotage, facilitant
la prose de dcision environnementale.
Ce projet a t trs bnque pour nous, ctait une occasion pour appliquer dans un cadre
professionnel les connaissances acquises durant notre formation SUPMIT. En effet, il
mlait ensemble plusieurs disciplines et nous avons permis de mettre niveau les tudes
suivies durant notre cursus au sein de SUPMTI. Les acquis du cours de programmation
objet taient sans cesse sollicits et ce nouveau dveloppement de projet en PHP5 nous a
encore permis daller plus loin dans les possibilits du langage et dacqurir de nouvelles
connaissances surtout en Framework PHP qui est le Symfony2. Enn, les fonctionnalits
offertes par cette application sont immenses, notamment en matire daide
ladministrateur du site pour enrichir lapplication avec des nouveauts au niveau du
planning de programme des formations et la sensibilisation des collectivits locales.
En guise de perspective, nous pouvons amliorer notre projet par lajout de dautre service.
Par exemple un service de notification automatique des responsables des diffrents cas
derreur dans le systme via des emails ou des SMS


77

Bibliographie et Webographie

B1- [GIZ, 2009] Manuel de bonne gestion environnementale dans
lentreprise - Outils pratiques
B2- [afnor Groupe, MAI 2008] Les apports de la certification ISO 14001
B3- [Roques & Valle, 2007]
4me dition EYROLLES
UML2 en action De lanalyse des besoins la conception
B4- [Pascal roques]
Eyrolles 5me dition
UML2 par la pratique - tudes de cas et exercices
corrigs
B5- [AFNOR, ditions 2009] Pour une certification qualit gagnante
B6- [Eric Daspet & Cyril Pierre de
Geyer]
4me dition EYROLLES
PHP 5 avanc
B7- [Vincent Capitaine, 2010]
Dunod, Collection InfoPro
Project 2010 : guide pratique pour les chefs de projet

B8- [Luc VAN LANCKER]
ENI dition
AJAX Dvelopper pour le Web 2.0
B9- [Nassoub et Sainior] Open
OenClassRooms
Un site web dynamique avec jQuery !


W1- [gaea21] http://www.gaea21.org/wpg21/systeme-de-gestion-
environnemental/

78

W2- [Mmoire Online] http://www.memoireonline.com/06/11/4565/m_Gestion-du-
patrimoine-immobilier-OPGI-de-Khenchela15.html
W3- [ISO] http://www.iso.org/iso/fr/iso14000
W4- [Site du Zro] http://fr.openclassrooms.com/informatique/cours/developpez-
votre-site-web-avec-le-framework-symfony2
http://www.siteduzero.com/informatique/tutoriels/votre-
serveur-local/mamp
W5- [Comment a Marche] http://www.commentcamarche.net/contents/577-javascript-
introduction-au-langage-javascript
W6- [Neuroactive] http://neuroactive.fr/formation-project-niort/
W7- [Sparx Systems] https://phpunit.de/
W8- [PHPUnit] http://www.sparxsystems.fr/
W9- [MAMP] http://www.mamp.info
W10- [Internet Avallon] http://www.internetavallon.net/MYSQL.html
W11- [Scribd] http://fr.scribd.com/doc/178687713/Serveur-LAMP
W12- [National
Instruments]
http://www.ni.com/labview/why/graphical-programming/f/