Figure 14. Aperçu de
l'affichage des couches PostGIS dans QGIS
2.2.1.3. Ajout et actualisation de la BD dans
PostGIS
La base de données créée est dynamique.
Ceci suppose qu'elle peut connaître des ajouts ou des actualisations. Si
un nouveau PGES est approuvé dans la Région du Sud, on va
simplement introduire ses informations dans la base de données du
PostGIS et visualiser automatiquement les informations sur QGIS. Il suffit
juste d'ouvrir la table dans PostGIS et remplir la nouvelle donnée et
rafraichir et elle (nouveau PGES) apparait dans QGIS.
2.2.2. Conception d'un outil de surveillance et suivi
environnemental de mise en oeuvre des PGES de la Région du
Sud
2.2.2.1. Choix de la méthode
Pour la réalisation de l'application proposée,
le choix a été porté sur le Processus Unifié. En
effet, le processus unifié est une solution de développement
logiciel adaptéeà tout type de projet. Ces traits distinctifs
tiennent compte de trois notions : piloté par les cas d'utilisation,
centrésur l'architecture, itératif et incrémental
(Saïche et Ouyougoute, 2015).
Le langage de modélisation que nous avons
utilisé est UML, qui est une partie intégrantede la
démarche du Processus Unifié (PU). Ces diagrammes sont largement
utilisés dans chaque étape et phase de ce processus de
développement.
Aussi dans l'élaboration de l'application a suivi les
étapes suivantes :
- le recueil des besoins ;
- la modélisation du problème via le logiciel
ULM ;
- le choix des outils à utiliser ;
- l'implémentation ;
- le déploiement.
2.2.2.2. Identification des besoins
Le Processus Unifié distingue deux types de besoins
:
· les besoins fonctionnels qui conduisent à
l'élaboration des cas d'utilisation ;
· les besoins techniques (non fonctionnels) qui
aboutissent à la rédaction d'une des exigences de système
pour sa réalisation et son bon fonctionnement.
· Les besoins fonctionnels
Ce sont les besoins spécifiant un comportement
d'entrée/sortie du système.il s'agit des besoins propres à
notre système. Notre application pour être efficace, devra remplir
les besoins suivants :
· créer/supprimer un compte sur la plateforme ;
· créer /modifier un projet ;
· ajouter/modifier/supprimer un Plan de Travail Annuel
(PTA) ;
· consulter un PTA en fonction du site
(évaluateur) ;
· évaluer l'effectivité des mesures d'un
PTA ainsi que l'efficacité desdites mesures ;
· télécharger un PTA ;
· télécharger les résultats de
l'évaluation
· envoyer mail.
· Les besoins non fonctionnels
Ce sont des besoins non propres à
l'application :
· l'application doit permettre de crypter les mots de
passe avant de les sauvegarder dans la base de données ;
· le temps de latence doit être faible : le
chargement de l'application, ouverture d'écran et des délais de
rafraîchissement, etc. ;
· le système doit être capable de stocker un
volume important de données ;
· l'ergonomie du système doit être
assurée ;
· l'application doit avoir des interfaces conviviales.
2.2.2.3. Analyse des besoins
Cette partie traite de l'analyse fonctionnelle du projet.
D'abord il est identifié les acteurs impliqués, ensuite les cas
d'utilisations de l'application sont spécifiés.
· Identification des acteurs
Les différents acteurs qu'on va trouver dans nos
diagrammes de cas d'utilisation sont :
· Le promoteur du projet disposant d'un
PGES : l'acteur principal. C'est lui qui
- charge les informations sur le projet ;
- élabore un PTA ;
- auto évalue la mise en oeuvre de son PTA ;
- exporte les résultats sous forme de PDF.
· L'Opérateur du suivi du PGES (SDPGE, DR,
CSPGES, DD, CBDD) : C'est l'évaluateur institutionnel de
la mise en oeuvre des PGES. Il :
- consulte les informations renseignées par le
promoteur ;
- évalue la mise en oeuvre du PTA ;
- exporte les résultats sous forme de PDF.
· L'administrateur du site : est le
responsable de la gestion depuis la conception jusqu'àla maintenance de
l'application web.
· L'identification des cas d'utilisations de
l'application
Le diagramme des cas d'utilisations (figure 15) identifie les
fonctionnalités fournies par le système, les utilisateurs qui
interagissent avec le système (acteurs), et les interactions entre ces
derniers (Conallen, 2000 cité par Saïche et Ouyougoute, 2015). Un
cas d'utilisation correspond à un certain nombre d'actions que le
système devra exécuter en réponse à un besoin d'un
acteur (Roques et Vallee cités par Saïche et Ouyougoute, 2015).La
figure sise ci-dessous présente le digramme global des cas d'utilisation
de notre application.
Figure 15. Diagramme globale des cas d'utilisation.
2.2.2.4. Diagramme des séquences
Les diagrammes de séquences sont la
représentation graphique des interactions entre les acteurs et le
système selon un ordre chronologique dans la formulation UML. Ces
communications entre les classes sont reconnues comme des messages. Le
diagramme des séquences énumèredes objets horizontalement,
et le temps verticalement. Il modélise l'exécution des
différentsmessages en fonction du temps(Saïche et Ouyougoute,
2015).Pour réaliser les diagrammes des séquences nous avons
utilisé des opérateurs d'interactions. Un opérateur
d'interaction définit le type d'un fragment composé. Les
opérateurs d'interaction que nous avant utilisés dans les
diagrammes de séquences sont :
· Référence (ref) : cet opérateur
désigne que le fragment fait référence à un cas vue
précédemment ;
· Alternative(Alt) : cet opérateur désigne
que le fragment composé représente un choix de comportement. Un
opérande d'interaction au maximum sera choisi. L'opérande choisi
doit avoir une expression de garde implicite ou explicite qui a la valeur
"true" à ce point de l'interaction ;
· Loop : cet opérateur désigne que le
fragment composé représente une boucle. L'opérande "loop"
sera répétée plusieurs fois.
Lafigure 16présente le diagramme des séquences
`s'authentifier'
| 
