Memoire Online - Prototype d'un système de webmapping interactif avec les jsp et les servlets

1 Les technologies et les outils existants pour la mise en oeuvre du Webmapping 13

TABLE DES MATIÈRES			2
2	Modélisation et conception de la solution		33
	2.1	Spécification des besoins et méthodologie adoptée	33
		2.1.1 Spécification des besoins	33
		2.1.2 Méthodologie adoptée	34
	2.2	Analyse fonctionnelle	35
		2.2.1 Identification des acteurs	35
		2.2.2 Identification des cas d'utilisation	36
		2.2.3 Les diagrammes de cas d'utilisation	36
		2.2.4 Description textuelle des cas d'utilisation	40
	2.3	Analyse dynamique	45
		2.3.1 Les diagrammes de séquence système	45
	2.4	Analyse statique	49
		2.4.1 Diagramme de classes	49
		2.4.2 Diagramme de paquetage	51
	2.5	Conception	52
		2.5.1 Le modèle relationnel	52
		2.5.2 Diagrammes d'états de navigation	53
3	Déploiement et mise en oeuvre d'un prototype du SYGeD		56
	3.1	Déploiement du Système	56
		3.1.1 Architecture physique du système	56
		3.1.2 Politique de sécurité adoptée	58
		3.1.3 Matériels requis	58
		3.1.4 Outils logiciels requis	59
	3.2	Réalisation de la base de données	59
		3.2.1 Structuration des tables géométriques	59
		3.2.2 Acquisition des données	61
	3.3	Configuration du serveur géographique	63
		3.3.1 Définition d'une couche cartographique	64
		3.3.2 Définition de style pour les couches cartographiques	65
	3.4	Présentation du prototype	68

Dédicace

Remerciements

Je témoigne ma gratitude à tous ceux qui de près ou de loin, matériellement ou moralement m'ont permis de poursuivre et de mener à terme mes études d'ingénierie informatique à l'Institut de Mathématiques et de Sciences Physiques (IMSP) de l'Université d'Abomey-Calavi (UAC).

Merci tout spécialement à mon maître de mémoire M. Eugène C. EZIN pour sa disponibilité et son souci du travail bien fait.

Merci à mes grands frères Barthélémy AKAKPO et Alexis AKAKPO pour les différents conseils et motivations.

Mes remerciements s'adressent également à l'ensemble du corps enseignant de la filière Génie Informatique et Sciences Appliquées (IGISA) de l'IMSP.

Je dois reconnaissance à tous ceux qui, par leurs travaux, idées, présentations, collaborations ou relectures, ont participé à la réalisation de ce mémoire, en particulier : Hervé M. AKAKPO, DANSOU Z. Alphonse, KOUNNOU M. Frédy et j'en oublie.

Une mention particulière à mon épouse Clémentine, mon enfant Précieux Manassé Nonvignon, mon frère Raoul et ma soeur Jocelyne qui m'ont supporté pendant tous ces temps d'études.

Résumé

La cartographie sur Internet ou webmapping est un domaine en plein essor et de nombreuses disciplines scientifiques y ont maintenant recours pour présenter des travaux cartographiques.

Les technologies disponibles actuellement se distinguent très nettement par leur complexité, leur coût et leur ouverture. Au sein de ces multiples approches, nous avons pris le parti de mettre en place un système simple, qui repose sur des outils libres et open sources utilisant la technologie Java.

Ce travail comprend trois volets à savoir la réalisation d'une base de données géographique avec postgresql/PostGIS, le déploiement d'un serveur géographique (GeoServer) et le développement d'une application Web qui interagit avec ceux-ci. La base de données contiendra les données spatiales et attributaires. Le serveur géographique se servira de ces données pour produire des couches cartographiques selon les requêtes de l'application Web. L'application Web est basée sur les JSP et les Servlets pour gérer le côté dynamique du système. Elle a pour principale fonction de rediriger les requêtes du client au serveur géographique afin de récupérer des images cartographiques pour le client.

L'utilisateur final se servira d'un simple navigateur pour explorer les domaines, faire des demandes d'autorisation pour l'occupation d'un domaine, formuler des plaintes sur l'état de son domaine et générer par exemple des arrêtésd'autorisation selon son profil.

Abstract

Mapping on the Internet or webmapping is a growing field and many scientific fields have now resorted to present cartographic work.

Currently available technologies differ markedly in their complexity, cost and openness. Within these multiple approaches, we took the party to up a simple system based on free tools and using open source technology Java.

This work has three components namely the implementation of a geographic database with PostgreSQL / PostGIS, the deployment of a geographic server (GeoServer) and the design of a web application that interacts with them. The database will contain spatial and attribute data. The geographic server will use these spatial data to produce map layers according to the requirements of the Web application. The Web application is based on the JSP and Servlets to manage the dynamic side of the system. Its main function is to redirect client requests to the geographic server in order to retrieve map images to the client.

The end user will use a browser to explore areas, apply Authorization for the occupation of an area, making complaints about the state of his area and generate such decrees authorization according to his profile.

Liste des tableaux

Table des figures

Introduction générale

La cartographie est née du besoin de l'homme à avoir sous forme symbolique et graphique les informations géolocalisées. Elle est la première étape de la création des systèmes d'information géographiques qui de nos jours ont connu une grande expansion notamment dans les domaines de la santé, de la climatologie, de la topographie, de la démographie etc [1] . La vulgarisation des moyens de communication modernes tels que Internet a très vite servi de support à la diffusion cartographique. De plus l'élaboration d'une normalisation par l'OGC ¹ a permis le développement d'applications dans le domaine du Webmapping² et dont la plupart se limitent seulement à l'affichage et à la diffusion d'informations spatiales de façon statique.

Au Bénin, le suivi de l'allocation des domaines publics est une véritable gageure surtout dans le cadre de la décentralisation. Ce suivi implique la délimitation et la géolocalisation du domaine, son affectation à un contribuable et sa restitution dans les conditions prévues. Actuellement, au Bénin, aucune commune ne dispose d'outils informatiques modernes pour le suivi des domaines tel que définis plus haut. Au plan national, seule une base de données géographique est disponible mais elle est très peu exploitée pour des fins économiques.

A travers ce mémoire, nous nous sommes proposé de mettre en oeuvre un système de Webmapping interactif et dynamique avec les technologies JSP et Servlet. Il s'agit d'un système qui ne se limitera pas seulement à l'affichage des domaines dans leur ensemble. L'affichage dépendra aussi des critères définis par l'utilisateur lui même (les domaines occupés ou non, les domaines situés au bord d'une voie donnée, les domaines sur lesquels est pratiquée une activité donnée, etc.). Pour cela ce système sera doté d'une base de données géographiques régulièrement mise à jour. Enfin

de distribution de cartes via un réseau tel que l'Internet, l'intranet ou l'extranet et leur visualisation dans un navigateur

le système aidera également les administratifs dans la prise de décision à travers la production automatique des arrêtés d'autorisation.

Pour y parvenir, il est nécessaire, d'une part, d'approfondir nos connaissances sur le concept du Webmapping au plan technique, et d'autre part de recueillir les besoins pour lesquels nous proposerons une solution qui sera modélisée et implémentée suivant les choix techniques effectués.

I. Problématique

Depuis le 15 janvier 1999, le Bénin a opté pour le régime de la décentralisation. Les départements sont alors subdivisés en collectivités territoriales administrées par des Maires. Le Maire avec ses conseillers disposent d'un large pouvoir autonome et de compétences propres pour gérer les ressources humaines, financières et matérielles de leur commune. Au coeur de cette gestion se trouve celle des espaces publics qui constitue souvent une source de mésentente entre l'administration et les administrés. Les causes de ces conflits sont de diverses origines à savoir :

- le manque de délimitation et d'identification géographique des domaines : les contribuables sont souvent tentés d'exploiter plus d'espace que prévu. Dans ce cas, l'administration éprouve des difficultés à gérer les conflits de proximité;

- le défaut de répertoire fiable associant à chaque domaine l'occupant d'une période donnée : le contrôle de la restitution des domaines reste manuel entrainant ainsi le non respect du délai d'occupation;

- le retard dans la délivrance des permis d'occupation qui souvent ne font pas mention des références géographiques du domaine en question;

L'essor des systèmes d'informations géographiques, de l'Internet et des technologies Web a permis l'apparition du Webmapping dans les années 90. Cette technique de diffusion de carte sur Internet continue de faire ses preuves surtout dans l'exploration spatiale. A travers ce mémoire, cette technique sera utilisée pour proposer une solution dans le but d'aider les administrés et l'administration dans la gestion quotidienne des domaines publics.

II. Objectifs

Dans le contexte de notre étude, il s'agit d'adapter la technologie Webmapping à nos réalités pour assister les administrations communales dans la gestion de l'allocation des domaines. Autrement dit, l'affichage des cartes sera interactif et dynamique pour permettre d'une part aux contribuables de demander en ligne un domaine répondant à des critères et d'autre part aux dirigeants de suivre l'évolution de l'occupation des domaines et leur restitution. Pour trouver une réponse à ces préoccupations, nous nous sommes fixé quelques objectifs à atteindre dans notre étude.

L'objectif principal de ce mémoire est de proposer un prototype d'un système de Webmapping pour la gestion de l'allocation des domaines publics, doté des mécanismes d'aide à la production des arrêtés d'autorisation. Les objectifs spécifiques sont :

- concevoir un système de Webmapping doté d'une base de données géographiques devant apporter une meilleure lisibilité et rendre possible la gestion des conflits de proximité grâce à la visualisation de la cartographie des domaines;

- permettre une meilleure coordination des équipes chargées d'instruire des domaines et de contrôler les conditions de restitution de l'espace public;

- incorporer à ce nouveau système un module de production rapide des documents d'autori-

sation pour limiter au maximum la saisie d'informations, source d'éventuelles erreurs.

III. Organisation du contenu du mémoire

Le contenu de ce mémoire est structuré autour de trois chapitres qui constitueront les étapes suivies pour le développement du système.

Le premier chapitre présentera les technologies et les outils existants pour la mise en oeuvre du Webmapping. Cette exploration technique permettra d'effectuer des choix et de proposer une solution au problème posé. Le deuxième chapitre abordera la modélisation et la conception de cette solution. Enfin, le troisième chapitre traitera de la mise en oeuvre du prototype pour la gestion de l'allocation des domaines d'un marché public. Les différentes simulations permettront de souligner les limites de la solution et les perspectives qui y découlent.

Chapitre Premier

LEs TEcHNoLoGiEs ET LEs ouTiLs

EXisTANTs pouR LA MisE EN (EuvRE Du

Webmapping

Introduction

Plusieurs outils logiciels sont disponibles pour la mise en oeuvre d'une application Web et pour le déploiement d'une base de données géographiques. Ces outils libres ou non seront brièvement présentés avec leurs avantages. Nos investigations porteront surtout sur ceux qui utilisent la technologie java.

Le présent chapitre abordera dans une première partie les technologies Web utilisées pour le Webmapping, puis une seconde partie, se consacrera aux Systèmes de Gestion de Base de Données (SGBD) permettant le déploiement d'une base de données géographiques. Dans une troisième partie, il sera répertorié les logiciels libres mettant en oeuvre le Webmapping. Enfin, des choix seront faits dans le but de proposer une solution au problème posé.

1.1 Les technologies Web utilisées pour le Webmapping

1.1.1 Les langages de script Web

Les scripts de programmation Web servent à écrire des pages Web dynamiques et permettent l'extension de leurs fonctions par l'accès aux bases de données, les transactions d'e-commerce, le Webmapping, etc. Les Langages de scripts offrent des balises spécifiques permettant l'intégration

de ces différentes technologies dans des pages Web en HTML (HyperText Markup Language). Parmi les langages de script qui existent on peut citer : PHP, ASP, Servlets, JSP, JavaScript, CGI (Common Gateway Interface), CSS (Cascading Style Sheet), VBSript, WAP (Wireless Application Protocol), etc. Il nous paraît opportun de présenter quelques uns.

1.1.1.1 Hypertext Preprocessor

Le langage PHP (Hypertext Preprocessor) fut créé en 1994 par Rasmus Lerdorf. PHP est un langage de script libre principalement utilisé pour produire des pages Web dynamiques via un serveur http. Depuis la version 5, PHP dispose des fonctionnalités de modèle objet complètes. Il présente entre autres les atouts suivants :

- la gratuité et la disponibilité du code source sous la licence GPL (General Public License); - la simplicité d'interfaçage avec les bases de données;

PHP est un langage interprété. Ce qui est au détriment de la vitesse d'exécution du code. Aussi, les programmes PHP rencontrent-t-ils des problèmes de portabilité. Mais notons qu'il existe également des projets pour compiler du code PHP. Par exemple Quercus convertit un code PHP en bytecode Java exécutable sur une machine virtuelle Java et HiPHop for PHP transforme du PHP en C++ [2].

1.1.1.2 Active Server Pages

Active Server Pages (ASP) est un stantard mis au point par Microsoft en 1996 et qui permet le développement des pages Web interactives. ASP est une structure composée d'objets accessibles par deux principaux langages : le VBScript et le JScript. Il s'agit en réalité d'une technologie, ou plus exactement d'un environnement de développement, permettant de représenter sous forme d'objets les interactions entre le navigateur du client, le serveur Web, ainsi que les connexions à des bases de données grâce aux composants ActiveX. L'ASP est exécuté côté serveur et peut lire et écrire des documents issus d'office (Excel, Word, etc.). C'est un langage interprété comme le PHP. L' ASP.NET vient améliorer les performances de l'ASP surtout en terme de rapidité puisqu'il propose une exécution compilée. L'inconvénient majeur de ces technologies est qu'elles nécessitent

pour leur fonctionnement une plateforme Windows avec IIS (Internet Information Server) installé, ou encore une plateforme Linux ou Unix avec une version modifiée d'Apache [3].

1.1.1.3 Les servlets

Une servlet est un programme qui s'exécute côté serveur et permet l'extension des fonctions de ce dernier. Elle reçoit une requête du client, effectue des traitements et renvoie le résultat. La liaison entre la servlet et le client peut être directe ou passer par un intermédiaire comme par exemple un serveur http. Même si pour le moment, la principale utilisation des servlets est la génération de pages XHTML (eXtensible HTML) dynamiques utilisant le protocole http, n'importe quel protocole reposant sur le principe de requête/réponse peut en faire usage [9].

Ecrite en java, une servlet en retire ses avantages : la portabilité, l'accès à toutes les API de java dont JDBC pour l'accès aux bases de données, etc. Une servlet peut être invoquée plusieurs fois en même temps pour répondre à plusieurs requêtes simultanées. Une fois instanciée, elle reste en mémoire. Ce qui permet de garder des ressources système et gagner le temps d'initialisation. Les servlets sont indépendantes par rapport au serveur Web et peuvent être démarrées automatiquement lors du lancement du serveur.

Dans une architecture client/serveur trois tiers, la servlet se positionne dans le tiers du milieu entre le client léger chargé de l'affichage et la source de données. Les servlets sont limitées en matière d'interface graphique car elles s'exécutent côté serveur et une petite modification dans le code XHTML nécessite la recompilation de la servlet.

Pour développer et exécuter une servlet il faut le Java Servlet Development Kit (JSDK) qui est un package contenant l'ensemble des classes et des interfaces nécessaires. Le JSDK est incorporé dans des conteneurs Web ou serveurs d'application dont Apache Tomcat, Jetty, JBoss ou encore GlassFish. Le choix d'un serveur d'application doit tenir compte de la version du JSDK qu'il supporte pour être compatible avec celui utilisé pour le développement des servlets.

1.1.1.4 Java Server Pages

Les JSP (Java Server Pages) sont une technologie Java qui permettent la génération de pages Web dynamiques. La technologie JSP permet de séparer la présentation sous forme de code XHTML et les traitements sous forme de classes Java. Les JSP permettent d'introduire du code Java dans des balises prédéfinies à l'intérieur d'une page XHTML. Ils mélangent la puissance de

Java côté serveur et la facilité de mise en page de XHTML côté client. Une JSP est habituellement constituée :

- l'utilisation de Java qui permet une indépendance de la plate-forme d'exécution mais aussi du serveur Web utilisé;

- la séparation des traitements de la présentation : la page Web peut être écrite par un designer et les balises JSP peuvent être ajoutées ensuite par le développeur. Les traitements peuvent être réalisés par des composants réutilisables (des Java beans, servlets);

- les JSP sont basées sur les servlets : tout ce qui est fait par une servlet pour la génération de pages dynamiques peut être fait avec une JSP.

Concrètement, au premier appel de la page JSP, le moteur de JSP génère et compile automatiquement une servlet qui permet la génération de la page Web. Le code XHTML est repris intégralement dans la servlet.

Dans le fonctionnement d'une application Web basée sur la technologie JSP, lorsqu'une requête demandant une page JSP est envoyée par un client http, le serveur Web http transmet la requête au moteur de JSP qui va l'interpréter puis compiler le code et générer la réponse sous forme d'une page XHTML statique. Donc pour exécuter une page JSP, il faut, en plus d'un serveur http comme Apache, un moteur de JSP comme Tomcat, Jetty ou GlassFish. Sur le serveur d'application il faut installer un Java Development Kit (JDK) qui contient une Machine Virtuelle Java (MVJ).

1.1.2 Serveurs d'application et serveurs Web

Le serveur d'application et le serveur Web sont des logiciels nécessaires au niveau du serveur pour faire tourner une application Web. Les deux jouent des rôles différents mais se complètent. En effet, le serveur Web se charge uniquement du traitement des requêtes http et s'il constate que la requête reçue contient des codes destinés au serveur d'application, il la lui transmet. Il revient au serveur d'application de traiter le code pour envoyer la réponse via le connecteur.

Le serveur d'application et le serveur Web ne sont pas nécessairement séparés. Par exemple les

conteneurs d'application utilisant la technologie Java comme Tomcat, JBoss, Jetty ou Glassfish incluent un serveur Web généralement Apache. Ceci permet d'installer un serveur Web complet en utilisant moins de ressources. Cependant on peut séparer ces deux serveurs pour des raisons de productivité et de performance.

Dans cette section il sera présenté les conteneurs d'applications utilisant la technologie Java afin de choisir celui qui est approprié à notre application Web basée sur les JSP et les Servlets.

1.1.2.1 Serveur d'application Tomcat

Apache Tomcat, un projet de la fondation Apache, est un conteneur d'applications libre écrit en Java qui implémente les spécifications des servlets et des JSP de Sun Microsystems. Il inclut par défaut le serveur Web Apache et peut être utilisé en autonomie avec ce serveur Web, ou en collaboration avec d'autres comme IIS (Internet Information Server) par exemple [4]. Tomcat est libre et distribué sous une licence Apache.

Tomcat est un ensemble de plusieurs composantes ayant chacun un rôle. Il s'agit par exemple

- catalina : un conteneur servlet qui implémente les spécifications de Sun pour les servlets et les JSP;

- coyote : un connecteur http qui écoute le trafic entrant, dirige les requêtes au moteur de Tomcat et renvoie la réponse au client;

- jasper : un moteur JSP qui compile les fichiers JSP en tant que servlets et est capable de détecter les modifications des fichiers et de les recompiler à la volée.

- il est simple à administrer, beaucoup plus que les serveurs d'application Open Source complets;

il n'occupe que deux ports sur la machine (8080 : port propre de Tomcat et 8009 : port de communication entre Apache et Tomcat via le protocole AJP13 ¹ ).

La version actuelle Tomcat 7.0.25 (sortie en janvier 2012) implémente les spécifications Servlet 3.0, JSP 2.2 et EL (Expression Language) 2.2, support java 6, améliore la détection et la prévention des fuites de mémoire.

1.1.2.2 Serveur d'application Jetty

Jetty est un serveur http et un moteur de Servlets entièrement écrit en Java [4]. En raison de sa petite taille, il convient parfaitement pour fournir des services Web une fois embarqué dans une application Java. La première version date de 1995. Jetty peut être utilisé en autonomie, comme serveur Web traditionnel, ou peut être intégré dans un serveur d'application Java.

Jetty est un logiciel libre. Depuis 2009, le développement du noyau est hébergé par la fondation Eclipse. Il offre plusieurs avantages à savoir :

1.1.2.3 Serveur d'application JBoss

Créé en 1999, JBoss est un serveur d'applications J2EE² initié par un groupe de développeurs de la société JBoss Inc., entièrement écrit en Java, libre et distribué sous la licence LGPL (Licence Publique Générale Limitée GNU). Il est maintenu par le groupe JBoss gratuitement, mais tous les services consultants sont facturés [4].

JBoss fournit toute sorte de services standardisés : conteneur d'EJB (Enterprise Java Bean), gestion de mail, gestion de transactions, gestion de la sécurité, gestion du déploiement etc.

1.1.2.4 Serveur d'application JRun

JRun est un serveur d'application de Macromedia, basé sur Microsystem J2EE. JRun consiste en Java Server Page (JSP), Servlets Java, Enterprise JavaBeans (EJB), de Java Transaction Service (JST), et de Java Message Service (JMS). Il fonctionne avec la plupart des serveurs Web, comme Apache, IIS, et de manière générale, tout serveur Web supportant Internet Server Application Program Interface (ISAPI) ou les Common Gateway Interface (CGI) [4]. Il est réputé être le plus rapide du marché et existe en 4 versions : Développeur, Professionnelle, Avancée et Entreprise donnant chacune des prestations différentes :

2. J2EE : Java 2 Platform Enterprise Edition conçu par Sun Microsystems pour simplifier le développement d'application en environnement client léger.

- développeur : toute option, mais uniquement pour le développement, et limitée à 3 connexions simultanées;

- professionnelle : pour les entreprises hébergeant des Servlets et des applications à base de JSP, sur un seul serveur;

- entreprise : pour les entreprises créant et déployant des applications Java de e-commerce.

1.1.2.5 Serveur d'application GlassFish

Né en juin 2005, Sun Glassfish Enterprise Server est le premier serveur Open source ayant implémenté totalement la norme JEE 5. Il permet aux entreprises de créer et de déployer des applications Web à l'aide du profil Web Java EE léger et de faciliter l'exploitation de la puissance de la plateforme Java EE. La version 3.0 est sortie le 10 décembre 2009 en même temps que Java EE 6. Au niveau des standards, Glassfish recouvre JSP 2.1, Servlet 2.5 pour faire de l'injection de dépendance dans le conteneur Web. Avec la version 3, c'est un support complet de Java EE 6 qui est proposé avec la prise en compte de Servlet 3.0 . Il est léger, rapide, modulaire avec un interface administrateur simple. La distribution est placée sous double licence CDDL (Common Developpement and Distribution License) et GPLv2. Par défaut Glassfish intègre certains API comme JavaMail et JAAS³ .

L'administration de GlassFish peut se faire en interface graphique sur le port 4848 par défaut ou en ligne de commande nommée asadmin.

1.2 Les Systèmes de Gestion de Bases de données spatiales (SGBDS)

Les SGBDS sont des moteurs de gestion de bases de données qui intègrent des composantes spatiales et qui offrent la capacité de stocker et de gérer les données spatiales. Au cours de cette section, les plus connus sur le marché à savoir : Oracle avec sa cartouche spatiale Oracle Spatial, PostgreSQL avec sa cartouche spatiale PostGIS et MySQL avec sa cartouche MyGIS seront présentés et comparés. La norme OGC sera notre référence par rapport à la géométrie et les fonctions

3. JAAS : Java Authentification and Authorization Service est un framework de sécurité de Java.

1.2.1 La norme Open Geospatial Consortium

En 1997, l'OGC publie "l'OpenGIS Simple Features Specifications For SQL", un document qui propose plusieurs voix conceptuelles afin qu'un Système de Gestion de Bases de Données SQL supporte les données spatiales. Le but de cette spécification est de définir un schéma standard SQL qui permet le stockage, la récupération, l'interrogation et la mise à jour de données spatiales simples à travers un SGBD. Les données spatiales simples sont stockées, normalement, dans des colonnes géométriques dans un SGBD Relationnel. Les données non spatiales sont inscrites dans des colonnes dont les types de données ont été définis par le standard SQL92. Les données spatiales, quant à elles, sont inscrites dans des colonnes dont les types de données SQL sont basés sur le concept fondamental de données géométriques additionnelles pour le langage SQL. On distingue alors deux types d'environnement, l'environnement SQL92 et l'environnement SQL92 avec types de données géométriques. L'OpenGis Abstract Spécification spécifie les types géométriques utilisés par les SGBDS.

Les trois SGBDS cités plus haut (à savoir PostgreSQL/PostGIS, MySQL/MyGIS, Oracle/Oracle Spatial) seront examinés sur les points tels que les objets géométriques, les index spatiaux, les prédicats spatiaux, les fonctions spatiales et les systèmes de référence spatiale supportés.

1.2.2 La géométrie

Les trois SGBD Spatiaux utilisent le mode vecteur pour représenter les objets géographiques suivant le modèle spaghetti⁴ . Ils implémentent tous le modèle objet défini par l'OGC. Seul ORACLE permet le stockage d'arc de cercle comme parties d'une géométrie, mais il ne respecte pas les règles de nommage [5]. Le Tableau 1.1 récapitule les modes de représentation et les types géométriques utilisés par les trois SGBD spatiaux pour représenter les objets.

4. Modèle spaghetti : est un modèle de représentation des données spatiales où la géométrie d'un objet est décrite indépendamment de celle des autres.

	MySQL/MyGIS	PostgreSQL/ Post- Gis	Oracle/Oracle Spatial
Modes de re-	Mode vecteur suivant	Mode vecteur suivant	Mode vecteur suivant
présentation	le modèle spaghetti.	le modèle spaghetti.	le modèle spaghetti.
Types géomé-	- GEOMETRY	- GEOMETRY	- GEOMETRY
triques implé-	- POINT	- POINT	- POINT
mentés	- LINESTRING	- LINESTRING	- LINESTRING
	- POLYGON	- POLYGON	- POLYGON
	- GEOMCOLLE-	- GEOMCOLLE-	- GEOMCOLLE-
	CTION	CTION	CTION
	- MULTIPOINT	- MULTIPOINT	- MULTIPOINT
	- MULTILINE-	- MULTILINE-	- MULTILINE-
	STRING	STRING	STRING
	- MULTIPOLYGON	- MULTIPOLYGON	- MULTIPOLYGON
			- ARCLINESTRING
			- COMPOUNDLIN-
			ESTRING
			- COMPOUNDPOL-
			YGON
			- CIRCLES
			- RECTANGLES

1.2.3 Les index spatiaux

Les index sont au centre des SGBD car ils permettent d'augmenter la performance lors des requêtes en définissant des classements sur certaines tables.

Les trois SGBD spatiaux disposent d'un système d'indexation spatial et recommande voire obligent l'utilisation des index pour les colonnes qui contiennent des objets géographiques. En effet, les données spatiales sont souvent volumineuses et demandent par conséquent un temps de traitement important. Il convient donc de classer ces colonnes dans l'espace en utilisant un système d'indexation afin d'optimiser le traitement. Les trois SGBD spatiaux utilisent le système d'indexation R-Tree ⁵. En dehors de R-Tree, Oracle Spatial autorise le système d'indexation QuadTree⁶ alors que PostGis utilise également le système d'indexation GIST⁷ [5]. Le Tableau 1.2 présente les types d'index utilisés par chacun des trois SGBD spatiaux.

1.2.4 Les prédicats spatiaux

La notion de prédicats spatiaux regroupe les fonctions et/ou opérateurs permettant de tester les relations spatiales entre les objets. Ces prédicats utilisent souvent la notion de rectangles englobants(bbox) des objets pour réaliser les tests afin de rendre les calculs rapides.

La norme OGC définit un certain nombre de ces prédicats qui renvoient une valeur booléenne ou une valeur évaluable dans une condition booléenne. Il s'agit de :

- overlaps : vérifie s'il y a un chevauchement, une intersection entre deux objets; - contains : vérifie si un objet contient un autre objet;

- touches : vérifie si deux objets se touchent uniquement sur leurs frontières;

- relate : identifie tous les objets qui ont une relation particulière avec un objet donné. Oracle dispose en plus de ces prédicats, des prédicats supplémentaires afin d'élargir le champ d'analyse des objets, à savoir :

- SDO_FILTER : pour filtrer les objets qui peuvent avoir une relation avec un objet donné. Cette fonction utilise les bbox⁸ des objets uniquement et utilise les index spatiaux définis sur les objets.

- SDO_NN_DISTANCE : fonction pour connaître la distance de l'objet renvoyé par SDO_NN. Elle ne peut être appelée que lors d'un appel à SDO_NN.

- SDO_ON : pour tester si un objet est sur un autre (l'intérieur et la frontière d'un objet se trouvent sur la frontière d'un autre objet, par exemple une ligne couvrant le contour d'un polygone).

- SDO_WITHINDISTANCE : pour trouver les objets situés à une certaine distance d'un objet.

Le Tableau 1.3 résume les différents prédicats supportés par chacun des SGBD spatiaux.

1.2.5 Les fonctions spatiales

Les fonctions spatiales sont toutes les fonctions, autres que les prédicats, qui agissent sur les données spatiales afin de créer de nouveaux objets ou de renvoyer les informations sur les objets. Une étude comparative des SGBD spatiaux par rapport aux fonctions spatiales supportées est présentée dans le Tableau 1.4.

	MySQL/MyGIS	PostgreSQL/ Post- Gis	Oracle/Oracle Spatial
Fonctions	Supporte la plupart	Supporte l'ensemble	Supporte l'ensemble
d'information	des fonctions d'infor-	des fonctions d'infor-	des fonctions d'infor-
	mation définies par	mation définies par la	mation définies par la
	la norme OGC : par exemple les fonction	norme OGC.	norme OGC.
	Point_On_Surface et
	IsSimple ne sont pas disponibles.
Fonctions de	Néant	Supporte toutes les	Oracle locator ne dis-
création		fonctions de création de la norme OGC et en dispose d'autres.	pose d'aucune fonc- tion de création d'objet. Ces fonctionnalités sont ajoutées par la cartouche payante
			Oracle Spatial qui en propose d'autres non définies par la norme
			OGC.

1.2.6 Système de référence spatiale

Les données géographiquess étant représentées sur une surface presque sphérique, il est nécessaire de les projeter grâce à des formules mathématiques afin de les représenter sur des surfaces planes (carte ou écran). Les données ainsi transformées, sont dans un nouveau Système de Référence Spatiale (SRS). A ce titre, les différents SGBD spatiaux offrent des fonctionnalités très variées que nous présentons dans le Tableau 1.5.

1.3 Les logiciels SIG libres mettant en oeuvre le Webmap-

ping

Le Webmapping, est un domaine en pleine expansion grâce au développement des solutions Open Source. Suivant la philosophie GNU qui autorise la copie, la diffusion du logiciel et la modification du code source, ces programmes généralement gratuits et d'utilisation libre émergent à un rythme soutenu.

1.3.1 Les logiciels SIG propriétaires

Il s'agit des logiciels qui appartiennent à un éditeur et qui sont protégés par des licences. On retrouve sur le marché un nombre important dont les plus connus sont : la famille ArcGIS, Geoconcept, Mapinfo, Arcview et Autocad.

Ces solutions commerciales ont été évitées pour des raisons de besoins fonctionnels.

1.3.2 Les logiciels SIG libres

Ce sont des applications livrées gratuitement et parfois avec leurs sources, que l'on peut donc modifier à volonté pour l'adapter à ses besoins. On distingue les logiciels SIG généralistes et les logiciels SIG avec des clients légers.

1.3.2.1 Les logiciels SIG généralistes

Ils fonctionnent en mode client-serveur; sauf que dans ce cas le client est lourd. On peut citer :

- Grass : c'est le plus ancien logiciel SIG libre, le plus complet et développé en C++. Il se connecte directement à PostGIS pour traiter les données spatiales et supporte beaucoup de formats. Mais il est lourd avec une installation difficile. Il existe sous différentes plateformes et pour différents systèmes d'exploitation à noyau UNIX.

- Openjump : il est compatible avec tous les systèmes d'exploitation et est développé en java. Openjump prend en compte les connexions PostGIS ou WMS ⁹. Son inconvénient majeur est l'absence de fonctionnalités. Openjump s'organise en effet sous la forme d'un noyau gérant les fonctions SIG de base, sur lesquelles peuvent se greffer de nombreux plugin. Ces plugin ajoutent des fonctionnalités diverses, souvent disponibles uniquement dans les logiciels SIG avancés (interpolation, requêtes spatiales, mise en page, représentations graphiques, etc.).

- QuantumGIS : il est développé en C++, simple d'utilisation, et se connecte facilement à PostGIS. Il permet également d'importer des shapefiles¹⁰ dans PostGIS. QuantumGIS ne permet pas la modification de la géométrie d'une couche ni les requêtes attributaires et spatiales.

- UDIG (User Friendly Desktop Internet GIS) : il est construit autour de la plateforme Java Eclipse et peut se connecter à PostGIS. Son installation dans un environnement Windows est facile. Son avantage majeur est qu'il permet des modifications sur la géométrie des couches chargées en mettant directement à jour la table de données distant. Par contre il ne permet pas de faire des analyses thématiques ni de faire des requêtes spatiales [6].

	GRASS	OpenJump	QuantumGIS	UDIG
Langage de pro- grammation	C++	Java	C++	Java
Systèmes d'ex- ploitation	Multiplateforme	Multiplateforme	Multiplateforme	Multiplateforme
Bases de don- nées supportés	PostGIS, ODBC, My- GIS, Oracle	PostGIS, Oracle, ArcSDE	PostGIS	PostGIS, Oracle, DB2, ArcSDE
Standards OGC supportés	WMS, WFS (Web Feature Service), GML (Geography Markup Lan- guage)	WMS, WFS, GML, SFS (Simple feature SQL)	WMS, WFS, GML, SFS	WMS, WFS-T (WFS transac- tionnel), GML, SFS
Licence	GNU/GPL	GNU/GPL	GNU/GPL	GNU/LGPL

1.3.2.2 Les solutions clients-serveurs

De base, les solutions côté serveur Open Source apportent la possibilité à partir d'un navigateur Internet classique de visualiser des couches géographiques générées dynamiquement. Ces solutions respectent le principe du Webmapping. Il s'agit entre autres de :

- MapLab : il est une suite logicielle intégrée destinée à faciliter le déploiement de solutions de Webmapping. MapLab permet de construire graphiquement son mapfile, visualiser l'ensemble des données et y ajouter par exemple des couches à partir des requêtes WMS sur un serveur cartographique distant.

- MapServer : MapServer est un programme CGI qui s'exécute donc sur un serveur Web. En quelques mots, son rôle consiste à piocher dans des bases de données et autres ressources afin de générer des images de type matriciel, qui seront transmises à un client par l'intermédiaire d'un serveur Web. L'usage simple de MapServer consiste à régler quelques paramètres dans un fichier de configuration (le mapfile), et cela suffit pour mettre en place un serveur WMS

conforme aux normes OGC. Il est écrit en C et est multiplateforme. MapServer peut être utilisé en CGI ou avec MapScript. MapScript est une API C qui s'interface avec PHP, Perl, C#, Java et permet d'utiliser les fonctions de MapServer à partir de ces scripts.

Plus dur à mettre en oeuvre, il est aussi néanmoins plus souple et permet d'obtenir précisément le résultat attendu. MapServer a plusieurs avantages à savoir : l'adaptabilité et la flexibilité, l'interopérabilité, la stabilité remarquable et l'évolution rapide. Cependant, la solution MapServer nécessite un effort en développement. Il ne garantit pas la qualité graphique des cartes [7].

- CartoWeb : il n'est pas un serveur cartographique mais un client léger qu'on installe sur le serveur des données pour interagir avec celles-ci. Il permet la visualisation et la manipulation des données vectorielles et raster. CartoWeb se connecte avec PostGIS, s'intègre facilement dans un environnement Apache, PHP 5, Mapserveur 4.5 mais n'est pas compatible avec PHP 4. Son installation est complexe et nécessite une configuration particulière.

- GeoServer : GeoServer est un serveur open source développé en Java. Il supporte les standards de l'OGC : WMS, WFS et WCS (Web Coverage Service). Il possède une interface permettant de construire facilement des fichiers standardisés qui peuvent ensuite être partagés par différents types de clients (OpenLayers,uDig, ...). Ayant hérité tous les avantages de Java, Geoserver est multiplateforme. Sa configuration est facile avec une interface simple. GeoServer a une structure homogène en utilisant GeoAPI, GeoTools et en respectant la norme OGC. Il permet de se connecter facilement à PostGis pour extraire des données spatiales à partir d'une table ou d'une requête paramétrable. Avec GeoServer on note une finesse dans le rendu des cartes. Cependant, GeoServer est lent par rapport à MapServer, nécessite l'installation d'un JDK 1.4 ou plus et il est difficile de trouver une bonne documentation [8].

	MapLab	MapServer	CartoWeb	GeoServer
Langage de pro- grammation	C	C	PHP	Java
Systèmes d'ex- ploitation	Multiplateforme	Multiplateforme	Windows, Linux	Multiplateforme
Bases de don- nées supportés	PostGIS, Oracle	PostGIS, Oracle	PostGIS, MY- GIS	PostGIS, Oracle, ODBC, ArcSDE
Standards OGC supportés	WMS, WFS	WMS, WFS, WCS, WMC	Web Service SOAP complé- tant WMS et WFS	WMS, WFS, WCS
Licence	GNU/GPL	GNU/FDL	GNU/GPLv2	GNU/GPLv2

1.4 Choix et proposition de solution

Après une étude comparative, nous avons choisi les outils qui répondent le mieux à nos besoins. Les critères suivants sont pris en compte :

- l'application doit être consultée n'importe où avec un client léger comme un navigateur : mode client-serveur;

Au niveau applicatif, nous optons pour GlassFish vu sa souplesse, sa double fonctionnalité de serveur Web et serveur d'application. De plus, GlassFish est disponible sous une licence gratuite et est incorporé dans NetBeans, l'environnement de développement que nous avons choisi.

Pour la génération des couches cartographiques, GeoServer a été choisi comme Serveur géographique garantissant un meilleur rendu des cartes et une meilleure sécurité. Implémenté en Java, son choix nous permet d'avoir une homogénéité au niveau de tout le système à mettre en place.

Si nous avions à effectuer une classification sur l'ensemble des fonctionnalités offertes par les SGBDS étudiés, Oracle Spatial viendrait en tête suivie de PostgreSQL/PostGIS. Cependant,

nous portons notre choix sur le second du fait qu'il est libre et gratuit. Il est quasiment aussi performant que Oracle Locator qui est quant à lui un produit propriétaire et non gratuit. De plus PostgreSQL/PostGIS est facilement accessible par GeoServer, notre serveur géographique.

En résumé, nous proposons un système qui correspond à une architecture quatre tiers composée des éléments suivants :

la requête, en fonction de l'URL. Cette exécution peut nécessiter des images cartographiques d'où l'interpellation du serveur géographique (exemple : GeoServer) ou la consultation des sources de données attributaires comme des bases de données (exemple : PostgreSQL, 5' sur le schéma).

Conclusion

Le présent chapitre a exposé les différentes technologies en rapport avec ce projet et des études comparatives des outils libres pouvant nous aider à la mise en oeuvre du système. Ainsi nous avons exploré plusieurs outils parmi lesquels nous avons choisi les plus adaptés à notre solution. Ceci nous permet d'aborder les phases de l'analyse et de la conception avec des outils appropriés.

CHAPITRE DEUX

MoDELisATioN ET coNcEpTioN DE LA

soLuTioN

Introduction

Dans la mise en place d'un système informatique, la phase d'analyse permet de décrire à travers un modèle compréhensible les différentes composantes de ce système. Dans ce chapitre, il s'agit dans un premier temps de présenter les besoins et l'environnement du système à développer et dans un deuxième temps de modéliser tout ceci dans un langage compréhensible et universel comme UML. Enfin, on proposera une solution conceptuelle qui répond aux besoins définis et spécifiés lors de la phase d'analyse.

2.1 Spécification des besoins et méthodologie adoptée

Il devient beaucoup plus commode de partir des besoins de l'utilisateur pour concevoir une application qui répond au mieux à ses exigences. Ainsi, il nous revient de bien déterminer ces besoins et de se servir de méthodes éprouvées pour la planification et la modélisation.

2.1.1 Spécification des besoins

Les besoins sont d'ordre fonctionnel et d'ordre non-fonctionnel. 2.1.1.1 Les spécifications fonctionnelles

Les besoins fonctionnels sont précis et varient d'un utilisateur à un autre comme suit : tout utilisateur peut visualiser, localiser ou demander l'occupation d'un domaine précis ;

- l'occupant d'un domaine peut formuler et envoyer des plaintes via le système;

- le Chargé des Affaires Domaniales peut consulter les plaintes afin de proposer d'éventuelles interventions;

- le Maire doit recevoir du système, des demandes et générer automatiquement les décrets d'autorisation;

- l'occupant est informé par courrier électronique et par SMS de l'avis d'autorisation, suite à la génération de son arrêté d'autorisation.

2.1.1.2 Les spécifications non-fonctionnelles

La spécification non-fonctionnelle décrit le système informatique dans lequel l'application sera implantée, son interaction avec les autres composantes du système informatique. Dans le cas de ce système, les différents besoins non-fonctionnels sont les suivants :

- le seul client nécessaire pour l'utilisation de l'application devra être un navigateur Web;

- tous les outils et bibliothèques à utiliser pour l'implémentation du SIG devront être gratuits et libres d'utilisation;

- l'application doit être hautement paramétrable afin de faciliter l'évolution du noyau du SIG par l'ajout de nouvelles couches de domaine et l'extension dans toute la commune sans grande modification du code source;

- la gestion des données doit être centralisée et facilitée par une application dédiée; - le serveur cartographique doit être accessible via une page d'accueil;

2.1.2 Méthodologie adoptée

Il est généralement nécessaire de se servir de méthodes approuvées pour la modélisation et la planification de tout processus. La démarche utilisée dans ce projet est inspirée de la philosophie proposée par Pascal Roques dans l'article « Une démarche de modélisation "agile" pour passer des besoins des utilisateurs au code» [10].

La mise en place d'un SIG est une tâche complexe et ardue, et nécessite une démarche-projet rigoureuse pour atteindre les objectifs assignés. C'est ainsi que pour ce projet nous avons adopté la méthode UP (Unified Process) qui est centré autour de l'utilisateur [10]. L'analyse est structurée

- l'analyse fonctionnelle à travers laquelle nous décrivons les différents cas d'utilisation;

- l'analyse dynamique qui nous permet de décrire le cycle de vie de l'objet par les diagrammes de séquence;

- l'analyse statique qui permet la description de la structure des objets grâce aux diagrammes des classes.

2.2 Analyse fonctionnelle

Dans cette section, les différents acteurs, leurs rôles et les fonctions étendues du système seront identifiés et présentés.

2.2.1 Identification des acteurs

Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système étudié [10]. Nous avons identifié les acteurs suivants qui interagissent avec le système :

- citoyen : un utilisateur dont les fonctionnalités se limitent à la visualisation, la localisation et la demande d'un domaine;

- occupant de domaine : c'est un citoyen qui a déjà reçu une autorisation d'occupation de domaine et qui peut formuler et consulter des plaintes;

- personnel administratif : il s'agit de tout agent de l'administration communale autorisé pour l'usage des fonctionnalités comme la consultation des demandes, la consultation des plaintes et la consultation des interventions;

- Maire : il est un personnel administratif bénéficiant d'une fonctionnalité particulière qui est la génération automatique des arrêtés d'autorisation;

- Chargé des Affaires Domaniales (CAD) : le CAD est également un personnel administratif qui peut proposer des interventions sur les domaines ayant fait l'objet d'une plainte. administrateur du système : c'est lui qui gère le système. Il met à jour la base de données spatiales et gère les différents utilisateurs.

2.2.2 Identification des cas d'utilisation

Un cas d'utilisation (use case) représente un ensemble de séquences d'actions réalisées par le système et produisant un résultat observable et intéressant pour un acteur particulier. Un cas d'utilisation modélise un service rendu par le système. Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera. L'ensemble des cas d'utilisation doit décrire exhaustivement les exigences fonctionnelles du système [10].

Le Tableau 2.1 résume les cas d'utilisation ou fonctionnalités de notre système.

N	Cas d'utilisation	Principaux acteurs
1	s'authentifier	Tous les acteurs sauf un citoyen visiteur
2	Consulter les domaines	Tous les acteurs
3	Demander un domaine	Citoyen
4	Formuler une plainte	Occupant d'un domaine
5	Consulter une demande	Personnel administratif
6	Consulter une plainte	Personnel administratif
7	Consulter un document	Personnel administratif
8	Consulter des interventions	Personnel administratif
9	Générer un arrêté d'autorisation	Maire
10	Proposer une intervention	CAD

2.2.3 Les diagrammes de cas d'utilisation

Utilisé dans l'activité de spécification des besoins, le diagramme de cas d'utilisation montre les interactions fonctionnelles entre les acteurs et le système étudié [10].

2.2.3.1 Diagramme de cas d'utilisation du citoyen (visiteur et occupant)

- Tout citoyen peut visualiser un domaine et lancer une demande pour son occupation. - L'occupant d'un domaine est un citoyen autorisé à formuler et à consulter des plaintes.

2.2.3.2 Diagramme de cas d'utilisation du personnel administratif (Maire, Chargé des Affaires Domaniales et autres)

- Le Maire et le Chargé des Affaires Domaniales sont des personnels administratifs.

- En dehors de la visualisation des domaines, ils peuvent consulter les demandes, les plaintes et les interventions sur les domaines.

- La consultation des plaintes relatives à un domaine peut aboutir à la consultation des interventions correspondantes et vice versa.

- Après avoir consulté une plainte, le Chargé des Affaires Domaniales peut proposer des interventions sur le domaine concerné.

- La consultation d'un domaine peut aboutir à la consultation des demandes dont elle a fait l'objet et vice versa.

- Après avoir consulté une demande, le Maire peut générer le décret autorisant son occupation.

2.2.3.3 Diagramme de cas d'utilisation de l'administrateur

L'administrateur est le gestionnaire de tout le système. La gestion de l'utilisateur s'exprime

par l'ajout d'un nouvel utilisateur, la suppression ou la modification du profil d'un utilisateur. L'administrateur peut aussi supprimer, modifier ou ajouter un domaine.

2.2.4 Description textuelle des cas d'utilisation

Les acteurs sont : l'administrateur, le Maire, le Chargé des Affaires Domaniales, l'occupant de domaine.

L'utilisateur peut accéder au formulaire d'authentification pour saisir son login et son mot de passe afin de pouvoir se connecter au système.

5 a- L'utilisateur saisit un profil et/ou un login et/ou un mot de passe incorrecte(s).

1. le système refuse la connexion et demande à nouveau le profil et/ou le login et/ou le mot de passe.

L'utilisateur est authentifié et est enregistré dans la session courante; la page personnelle de l'utilisateur est affichée.

Tous les citoyens peuvent accéder au portail d'accueil du système et demander la visualisation d'un domaine précis.

5 a- le système ne trouve aucune carte qui réponde aux critères de sélection;

1. le système n'affiche aucune carte et propose à l'utilisateur de lancer une nouvelle requête;

6 a- l'utilisateur tente de faire un zoom sans afficher au préalable une carte;

1. le système affiche un message pour demander à l'utilisateur d'afficher une carte.

Tous les citoyens peuvent accéder au portail d'accueil du système et formuler une demande de l'autorisation d'occupation d'un domaine.

Un citoyen occupant un domaine peut accéder à sa page personnelle pour formuler des plaintes suite à une anomalie constatée sur son domaine.

Le Maire peut faire générer automatiquement un arrêté autorisant l'occupation d'un domaine suite à la demande d'un citoyen.

1. le système alerte le Maire sur l'invalidité de la référence saisie et le cas d'utilisation prend fin.

9 a- Le système de gestion financière des domaines n'autorise pas l'attribution du domaine. 1. le système alerte le Maire sur le refus de l'attribution;

2. un courrier avec avis non favorable est envoyé au demandeur et le cas d'utilisation prend fin.

- un courrier comportant une copie de l'arrêté d'autorisation est envoyé au demandeur; - une copie de l'arrêté d'autorisation est enregistrée sur le serveur FTP.

2.3 Analyse dynamique

L'analyse dynamique permet le suivi de l'évolution des objets et la compréhension de leur fonctionnement dans le système. Elle se base sur plusieurs diagrammes dont le diagramme de séquence [10].

2.3.1 Les diagrammes de séquence système

Au niveau analyse nous utilisons le diagramme de séquence système pour décrire selon un point de vue temporel et de façon chronologique les interactions entre les acteurs externes et le système.

2.3.1.1 Diagramme de séquence système : Authentification

- tout utilisateur authentifié accède à sa page personnelle en fonction de son profil;

- pour les raisons de sécurité, après trois tentatives de connexion l'utilisateur est redirigé vers la page d'accueil.

2.3.1.2 Diagramme de séquence système : Visualisation de domaine

L'utilisateur a la possibilité de demander un affichage simple, sans critère, ou de demander un affichage avancé en saisissant des critères de sélection.

2.3.1.3 Diagramme de séquence système : Demande de domaine

La prise en compte d'une demande est subordonnée à la saisie de certaines informations nécessaires pour créer un compte utilisateur à un citoyen dont la demande est acceptée.

2.3.1.4 Diagramme de séquence système : Génération d'arrêté d'autorisation

La synchronisation entre le système et le système de gestion financière des domaines est nécessaire afin d'autoriser seulement la génération des arrêtés des demandeurs solvables;

- le demandeur recevra un courrier électronique pour avis favorable ou non à sa demande;

afin de garder la trace des arrêtés générés, le système enregistre chaque arrêté généré sur un serveur FTP.

2.4 Analyse statique

L'analyse statique est la phase de l'analyse qui s'occupe de la description structurelle des différentes composantes du système. Dans cette section nous allons décrire les différentes classes d'objets à travers le diagramme des classes. En tenant compte des interactions qu'il peut y avoir entre les différentes classes, nous pouvons les réorganiser dans le diagramme de paquetage.

2.4.1 Diagramme de classes

L'étape typiquement orientée objet de l'analyse est la décomposition d'un domaine d'intérêts en classes conceptuelles représentant les entités significatives de ce domaine. Il s'agit simplement de créer une représentation virtuelle des objets du monde réel dans un domaine donné. Dans la notation UML, le modèle conceptuel se résume en un ensemble de diagrammes de classes [10].

Le diagramme de classes de la Figure 2.8 montre les différentes classes du système avec les interactions entre elles.

2.4.2 Diagramme de paquetage

L'analyse des rapports sémantiques entre les différentes classes nous a permis d'identifier quatre (4) paquetages à savoir : gestion des utilisateurs, gestion des plaintes, gestion des demandes et les entités géographiques. Le Tableau 2.2 récapitule les différentes classes ayant constitué chaque paquetage. On en déduit le diagramme de paquetage de la figure 2.9.

2.5 Conception

2.5.1 Le modèle relationnel

En informatique, une base de données relationnelles est un stock d'informations décomposées et organisées dans des matrices appelées relations ou tables conformément au modèle de données relationnelles. Le modèle de données relationnelles est basé sur la notion de relation qui est une matrice contenant un ensemble de groupes de valeurs (les n-uplets) stockés dans les enregistrements d'une base de données. Les règles ci-après sont appliquées pour passer du diagramme des classes au modèle relationnel :

R2 : Une classe d'association, qu'elle soit simple, agrégation ou composition, se transforme en relation.

R4 : Dans une relation d'héritage, ne dupliquer dans les relations sous-types que l'identifiant du sur-type.

R5 : Les clés primaires des classes reliées par une classe d'association migrent vers cette dernière et se transforment en clés étrangères.

A partir du diagramme des classes du système (Figure 2.8) le modèle relationnel suivant est déduit :

DEMANDEUR(ID_Ddeur, IFU, RefCiv, Nom, Prenom, Date_Nais, LieuNais, Nationalite, Profession,Adresse,Tel,Email,Commune,Arrondissement,Village)

UTIISATEUR(ID_UTIL, Nom_UTIL, Pren_UTIL, Login_UTIL, PW_UTIL, Profil_UTIL) OCCUPANT(ID_UTIL, ID_Ddeur)

DECRET(ID_DECRET, Lib_DECRET, Empl_DECRET, Date_Effet, Date_Exp, #ID_Dem) ZONE(ID_ZONE, Desc_ZONE, Geom_ZONE, Composer_de)

BOUTIQUE(ID_BOUT,Desc_BOUT, BoutOccuper PrixLocation,#ID_Bat) DEMANDE(ID_Dem, Date_Dem, Activite, Debut_Occ, Fin_Occ, #ID_DOM, #ID_BOUT, #ID_Act, #ID_Ddeur)

PLAINTE(ID_PLAINTE, DATE_PLAINTE, Obj_PLAINTE, DETAIL_PLAINTE, #ID_BOUT, #ID_DOM, #ID_UTIL)

PROPOSITION_INT(ID_PROPO, Date_PROPO, Date_Deb_ExecP, Date_Fin_ExecP ,Date_D Date_Fin_ExecEff, Observation, Executer, #ID_PLAINTE)

2.5.2 Diagrammes d'états de navigation

UML offre la possibilité de représenter graphiquement l'état de navigation dans l'interface homme-machine en produisant des diagrammes dynamiques qu'on appelle diagrammes de navigation. Le concepteur a le choix d'opter pour cette modélisation entre des diagrammes d'étatstransitions et des diagrammes d'activités. Puisque nous allons modéliser un comportement événementiel dans le cas d'espèce, nous optons pour les diagrammes d'états de navigation par acteur.

Conclusion

La phase d'analyse a permis de cerner le contour du système à travers les différents diagrammes fonctionnels, dynamiques et statiques afin d'aboutir à la conception. Cette phase permet de bien canaliser la phase suivante abordée dans le chapitre III à savoir le déploiement et la mise en oeuvre d'un prototype du SYGeD¹ .

CHAPITRE TROIS

DEpLoiEMENT ET MiSE EN (EuvRE D'uN

pRoToTypE Du SYGED

Introduction

Ce dernier chapitre du mémoire sera consacré à la mise en oeuvre de la solution retenue. Elle permettra d'aborder de façon détaillée le déploiement des différentes composantes du système et l'implémentation de l'application Web qui lui servira de portail. Les différents tests permettront d'évaluer les performances du prototype et de détecter ses limites.

3.1 Déploiement du Système

3.1.1 Architecture physique du système

Les modèles de déploiement et de configuration matérielle s'expriment tous deux à l'aide d'un diagramme de déploiement.

Le modèle de configuration matérielle a pour but d'exprimer les contraintes de mise en oeuvre au niveau physique. On y trouve les noeuds et les connexions physiques du système, qui sont les différents types de machines connectées par des moyens divers. Le modèle de configuration matérielle permet de spécifier, de documenter et de justifier tous les choix d'organisation physique en fonction des machines dédiées aux diverses fonctions techniques du système [10] .

La Figure 3.1 représentant le diagramme de déploiement de notre système décrit la répartition physique des fonctions-métiers du système et la localisation des différents serveurs.

Nous proposons une architecture physique dont la communication est basée sur le protocole TCP/IP.

Au niveau applicatif, l'échange de données entre le serveur d'application (également serveur Web) et le SGBD se fait grâce au JDBC (Java DataBase Connectivity) qui est une API Java très utilisée pour l'accès aux bases de données. De même, entre le serveur de données et le serveur géographique, l'API JDBC est utilisé pour les échanges des données. Par ailleurs, les différents clients demandent des services au serveur d'application en émettant des requêtes basées sur le protocole http.

L'internaute (contribuable ou personnel administratif) par le biais d'un navigateur émet une

requête http qui sera reçue par le serveur Web. Cette requête peut demander une ressource statique ou une ressource dynamique. Lorsqu'il s'agit d'une ressource statique, elle est directement fournie par le serveur Web. Une requête qui demande une ressource dynamique (image cartographique par exemple) est redirigée par le serveur Web vers le serveur d'application qui est capable de la traiter. Ce dernier exécute les morceaux de servlets concernés et interroge le serveur géographique chargé de la production des cartes. Ceci peut nécessiter la consultation de la source de données spatiales. Une fois la carte produite, elle est renvoyée au serveur d'application qui la présente à son tour au serveur Web sous forme de page HTML. Ainsi, le serveur Web est capable de l'interpréter pour enfin présenter la réponse au client sous forme d'une page statique.

3.1.2 Politique de sécurité adoptée

Il faut remarquer au niveau du diagramme de déploiement une DMZ (DeMilitarized Zone ¹⁾ regroupant le serveur d'application, le serveur géographique et le serveur de données. Il s'agit d'une zone dont l'accès est régi par la politique de sécurité définie comme suit :

- le trafic d'un réseau externe vers la DMZ est autorisé s'il s'agit d'une requête adressée au serveur d'application (requête http);

- le trafic du réseau interne vers la DMZ est autorisé seulement pour les requêtes http adressées au serveur d'application;

Deux pare-feux, l'un situé entre la DMZ et le réseau extérieur et l'autre entre la DMZ et le réseau intérieur, sont délégués pour la gestion de ces politiques de sécurité.

3.1.3 Matériels requis

- des micro-ordinateurs pour les machines clientes, ayant minimum 2 Go de RAM et 2 GHz de processeur;

un serveur IBM sur lequel seront installés les deux serveurs (Web et d'application), le Système de Gestion de Base de Données et le Serveur Géographique.

1. DMZ : région d'un intranet dotée d'une sécurité intermédiaire entre l'extérieur et l'intérieur.

3.1.4 Outils logiciels requis

Les logiciels et les principales API suivants sont nécessaires pour la réalisation du prototype : - système d'exploitation Windows (XP, Vista ou 7) ou Linux;

- un Système de Gestion de Base de Données doté de sa composante spatiale : PostgreSQL 9.0 avec sa composante spatiale PostGIS 1.5.

- OpenLayers, une API JavaScript utilisée pour l'affichage des cartes côté client après leur réalisation par le serveur géographique;

- un navigateur récent (Internet Explorer, Opéra, Mozilla Firefox etc.);

- js_mail 1.4, une bibliothèque d'API Java qui permet l'envoie des messages électroniques via un serveur SMTP (Simple Mail Transfer protocol).

3.2 Réalisation de la base de données

3.2.1 Structuration des tables géométriques

La base de données est implémentée sur le SGBD PostgreSQL version 9.0 avec sa composante spatiale PostGIS version 1.5. Nous notons ici une particularité avec les tables ayant des colonnes géométriques. En effet, ces tables se créent en deux étapes à savoir :

la création de ses colonnes géométriques qui peut se faire de deux manières. La première manière consiste à utiliser la fonction ADDGEOMETRYCOLUMN() qui prend en paramètre le nom de la base de données, le nom de la table contenant la colonne géométrique, le nom de la colonne géométrique, l'identifiant du système de référence (SRID), le type géométrique et la dimension de l'objet. Ainsi la table GEOMETRY_COLUMNS est remplie automatiquement avec les paramètres passés dans ladite fonction. La deuxième manière qui est moins courante, consiste à agir directement sur la table de méta données GEOMETRY_COLUMNS en uti-

Les requêtes ci-après permettent la création de ces tables ayant des colonnes géométriques.

select AddGeometryColumn ('SYGeDOK','BATIMENT','Geom_Bat' ,4326 ²,'POINT',2); select AddGeometryColumn ('SYGeDOK','ROUTE','Geom_Route' ,4326,'LINESTRING',2) ; select AddGeometryColumn ('SYGeDOK','DOMAINE','Geom_Dom' ,4326,'POLYGON',2); select AddGeometryColumn ('SYGeDOK','ZONE','Geom_Zone' ,4326,'POLYGON',2); select AddGeometryColumn ('SYGeDOK','ZONE','est_composee_de' ,4326,'MULTIPOLYGON',2);

3.2.2 Acquisition des données

Les données destinées à la production de la base de données géographiques proviennent de diverses sources :

- photographies aériennes; - cartographies existantes; - données recueillies sur le terrain (à l'aide d'un récepteur GPS).

3.2.2.1 Les récepteurs GPS

Le GPS (Global Positioning System) est un système de positionnement par satellites capables de donner n'importe où sur le globe une position à quelques mètres près.

A l'origine, le GPS a été conçu afin de fournir aux forces armées américaines un système de repérage global de très bonne précision [6]. Afin de permettre aux applications civiles et militaires d'utiliser ce système, les États-Unis ont imaginé le compromis suivant :

- un service de grande précision réservé aux militaires, c'est le mode PPS (Precise Positioning System) ;

2. 4326 : l'identifiant associé au système de référence WGS84 dans notre SGBD spatial.

- un second service aux possibilités dégradées (environ 100 mètres) auquel aurait accès toute

personne muni d'un récepteur, c'est le mode SPS (Standard Positioning System).

Le mode PPS exploite pleinement le système pour une précision de moins de 10 mètres. Le mode SPS qui utilise une électronique simplifiée est en plus soumis a une dégradation volontaire des signaux satellitaires pour une précision de 100 mètres environs.

Tous les satellites émettent en même temps sur 2 fréquences L1 : 1.575 GHz et L2 : 1.227 GHz. Les données repérées par un récepteur GPS étant l'altitude, la latitude et la longitude; celle-ci se compte de 0 degré à 180 degré, positivement vers l'est et négativement vers l'ouest.

3.2.2.2 Le traitement des données

Les données recueillies étant exprimées selon les unités des coordonnées sphériques non compréhensibles par les SGBDRS, il faut les convertir dans un système de projection donné.

Les systèmes de projection sont un ensemble de techniques géodésiques permettant de représenter la surface de la Terre dans son ensemble ou en partie sur la surface plane d'une carte [6]. C'est une relation mathématique qui fait correspondre aux coordonnées géographiques d'un point quelconque de la terre, des coordonnées cartésiennes. On distingue les projections suivantes :

- la projection cylindrique (Projection de Peters, Projection de Robinson, Projection UTM

- la projection conique (Projection conique conforme de Lambert, Projection d'Albers);

- la projection azimutale ou planaire zénithale : une projection cartographique dans laquelle on projette l'ellipsoïde sur un plan tangente en un point.

Le WGS84 a été développé par le département américain de la défense. Il a été obtenu à partir d'observations Doppler sur satellites. Il utilise la projection cylindrique et particulièrement la projection UTM qui est constituée de 60 fuseaux de 6 degrés d'amplitude en longitude [6]. Ce système est accessible au travers des éphémérides radiodiffusées par les satellites GPS . Ainsi, tout utilisateur de GPS obtient directement et de manière implicite des coordonnées référencées dans le système WGS84.

Lorsque les coordonnées cartésiennes sont obtenues après traitement, l'insertion des données dans la table correspondante se fait de la manière suivante :

insert into domaine values ('D02_DBR' ,0,'Z1',GeometryFromText('POLYGON((65 50,85 60,80 80,60 60, 65 50))',4326),'domaine bâtiment riderk',0);

3.3 Configuration du serveur géographique

Lorsqu'un utilisateur envoie une requête http pour afficher une carte dans le navigateur, cette requête est redirigée vers le serveur géographique qui, à son tour, communique avec le serveur de base de données pour avoir les données nécessaires à la production de la carte demandée. GeoServer 2.1.1 est le serveur géographique utilisé pour le prototype. Dans un premier temps, il doit être configuré pour communiquer avec PostgreSQL/PostGIS, le serveur de données.

Après son démarrage, GeoServer offre la possibilité à l'utilisation de créer son espace de travail (par exemple SYGeD). Après avoir créé l'espace de travail, il peut configurer une source de données dans cet espace. La configuration se fait pour les sources de base de données en fournissant les informations telles que :

3.3.1 Définition d'une couche cartographique

Une base de données géographiques peut être définie comme un ensemble de couches superposables. La conception d'une carte revient à sélectionner les différentes couches (couche des domaines, couche des bâtiments, etc.) qui entre dans sa composition. La définition d'une couche géographique se fait au niveau du serveur géographique. Pour se faire, GeoServer offre la possibilité de prendre directement les données d'une table ou de se servir d'une requête pouvant mettre en jeu plusieurs tables. La requête suivante définit une couche qui montre un domaine dont l'identifiant est fourni en paramètre :

3.3.2 Définition de style pour les couches cartographiques

Geoserver offre la possibilité de créer une feuille de style définissant l'apparence d'affichage de la couche à laquelle elle est associée. C'est une feuille de script XML qui décrit les données à afficher sur les cartes et leur aspect graphique suivant des critères. Le code XML suivant définit le style associé à la couche "domaine". Suivant ce style, les domaines non occupés sont coloriés en vert, les domaines occupés sont coloriés en rouge et sur chaque domaine la description est affichée.

3.4 Présentation du prototype

3.4.1 La page d'accueil

La page d'accueil comprend trois principales parties à savoir la bannière, la zone de navigation et le corps (voir Figure 3.4). La zone de navigation comporte les boutons accueil, visualiser, connexion et demander.

- le bouton "accueil" permet à l'utilisateur de revenir à tout moment à la page d'accueil; - le bouton "visualiser" permet à tout visiteur de visualiser les domaines;

- le bouton "connexion" permet à un utilisateur, qui a un compte utilisateur, de se connecter pour accéder à sa page personnelle afin d'avoir plus d'options;

- le bouton "demander" permet à un internaute quelconque d'accéder à la page de demande d'un domaine ou d'une boutique.

3.4.2 Visualisation de domaines

La page de visualisation de domaines est constituée de deux parties. Une partie gauche où sont affichées les options d'affichage avancées et une partie droite où s'affiche la carte selon l'option choisie. La Figure 3.5 donne un aperçu de cette page.

3.4.3 Demande de domaine ou de boutique

Le processus de demande d'un domaine ou d'une boutique commence par un clic sur le bouton "Demande". Le système recherche et affiche uniquement les domaines ou les boutiques disponibles afin de permettre à l'usager de faire son choix (voir Figure 3.6).

Après avoir consulté les domaines ou les boutiques disponibles, l'internaute clique sur l'action "Demander" du domaine ou de la boutique qu'il veut. Ainsi, il accède au formulaire de demande de la Figure 3.7.

3.4.4 Authentification et accès à la page personnelle

Conformément à ce qui est prévu au niveau de la conception, tout utilisateur qui veut accéder à sa page personnelle doit, après avoir cliqué sur le bouton connexion, renseigner les champs profil, login et password puis valider. Pour cela, nous avons associé au bouton valider un module qui vérifie les valeurs saisies avant d'afficher la page personnelle si ces valeurs sont valides (voir Figure 3.8).

3.4.5 Génération d'arrêté d'autorisation

Lorsque le Maire est sur sa page personnelle, il a la possibilité de choisir l'une des opérations prévues dans la liste déroulante "opération". Ces opérations sont les cas d'utilisation qui le concernent. S'il choisit de générer un arrêté, le système lui affiche toutes les demandes en cours comme le montre la Figure 3.7. Nous avons associé à cette option un module qui applique un filtre à la carte afin d'afficher uniquement les domaines qui ont fait l'objet d'une demande en cours (voir Figure 3.9).

La page de la génération proprement dite montre les détails concernant une demande. Cette page s'affiche lorsque le Maire clique sur le lien "détail" d'une demande. La Figure 3.10 montre son aperçu.

3.5 Limites du prototype

Le prototype réalisé illustre un système de Webmapping dynamique qui s'appuie uniquement sur les technologies JSP et Servlets avec des outils libres. Toutefois, le système que nous avons proposé ne prend pas en compte les analyses géographiques.

Une autre limite réside dans la non prise en compte de l'affichage en 3D des objets géométriques. En effet, cette fonctionnalité serait propice pour bien explorer les objets dans toutes leurs dimensions. Il faut aussi noter que pour le moment, notre système ne communique pas avec le système de gestion financière des domaines. L'intégration de cette fonctionnalité pourra permettre au système d'avoir de façon automatique les données sur l'état de solvabilité des demandeurs. Ainsi, la prise de décision pour la génération des arrêtés d'autorisation serait beaucoup plus automatique.

Conclusion

Le déploiement et la réalisation du prototype ont été décrits de long en large dans le présent chapitre. Nous avons aussi effectué et présenté les différents essais qui ont permis d'apprécier la performance du système. S'il est vrai que les objectifs fixés au départ ont été atteints, il est tout aussi avéré que le système de Webmapping proposé présente quelques limites qui peuvent rapidement être levées.

Conclusion générale et Perspectives

Les systèmes de Webmapping constituent un moyen de plus en plus important dans la diffusion des cartes géographiques. Dans ce projet, nous nous sommes donné comme objectif principal, la conception d'un système de Webmapping dynamique au service des administrations locales pour la gestion de l'allocation des domaines. Dans ce cadre, nous avons utilisé les technologies JSP et Servlets et des bibliothèques Java pour mettre en oeuvre un prototype.

Le système proposé permet de diffuser les cartes géographiques et de suivre de visu l'évolution de l'occupation des domaines. Son dynamisme permet aux internautes de bien cibler le domaine ou la boutique voulu pour en faire la demande. Il dispose d'une grande possibilité d'extension et est portable.

Grâce aux différents tests, nous pouvons conclure que les objectifs ont été atteints. Toutefois, notons que le système proposé ne prend en compte ni les analyses géographiques, ni la présentation en 3D des objets.

- introduire les analyses géographiques pour bien gérer les conflits de proximité;

- implémenter une présentation en 3D des objets. Le contribuable peut donc bien apprécier le domaine ou la boutique qui fait l'objet de sa demande;

- mettre le système de Webmapping en interaction avec le système de gestion financière afin de rendre la décision d'autorisation plus automatique.

Prototype d'un système de webmapping interactif avec les jsp et les servlets

Table des matières

Dédicace

Remerciements

Résumé

Abstract

Liste des tableaux

Table des figures

Introduction générale

I. Problématique

II. Objectifs

III. Organisation du contenu du mémoire

Chapitre Premier

LEs TEcHNoLoGiEs ET LEs ouTiLs

EXisTANTs pouR LA MisE EN (EuvRE Du

Webmapping

Introduction

1.1 Les technologies Web utilisées pour le Webmapping

1.1.1 Les langages de script Web

1.1.1.1 Hypertext Preprocessor

1.1.1.2 Active Server Pages

1.1.1.3 Les servlets

1.1.1.4 Java Server Pages

1.1.2 Serveurs d'application et serveurs Web

1.1.2.1 Serveur d'application Tomcat

1.1.2.2 Serveur d'application Jetty

1.1.2.3 Serveur d'application JBoss

1.1.2.4 Serveur d'application JRun

1.1.2.5 Serveur d'application GlassFish

1.2 Les Systèmes de Gestion de Bases de données spatiales (SGBDS)

1.2.1 La norme Open Geospatial Consortium

1.2.2 La géométrie

1.2.3 Les index spatiaux

1.2.4 Les prédicats spatiaux

1.2.5 Les fonctions spatiales

1.2.6 Système de référence spatiale

1.3 Les logiciels SIG libres mettant en oeuvre le Webmap-

ping

1.3.1 Les logiciels SIG propriétaires

1.3.2 Les logiciels SIG libres

1.3.2.1 Les logiciels SIG généralistes

1.3.2.2 Les solutions clients-serveurs

1.4 Choix et proposition de solution

Conclusion

CHAPITRE DEUX

MoDELisATioN ET coNcEpTioN DE LA

soLuTioN

Introduction

2.1 Spécification des besoins et méthodologie adoptée

2.1.1 Spécification des besoins

2.1.1.2 Les spécifications non-fonctionnelles

2.1.2 Méthodologie adoptée

2.2 Analyse fonctionnelle

2.2.1 Identification des acteurs

2.2.2 Identification des cas d'utilisation

2.2.3 Les diagrammes de cas d'utilisation

2.2.3.1 Diagramme de cas d'utilisation du citoyen (visiteur et occupant)

2.2.3.2 Diagramme de cas d'utilisation du personnel administratif (Maire, Chargé des Affaires Domaniales et autres)

2.2.3.3 Diagramme de cas d'utilisation de l'administrateur

2.2.4 Description textuelle des cas d'utilisation

2.3 Analyse dynamique

2.3.1 Les diagrammes de séquence système

2.3.1.1 Diagramme de séquence système : Authentification

2.3.1.2 Diagramme de séquence système : Visualisation de domaine

2.3.1.3 Diagramme de séquence système : Demande de domaine

2.3.1.4 Diagramme de séquence système : Génération d'arrêté d'autorisation

2.4 Analyse statique

2.4.1 Diagramme de classes

2.4.2 Diagramme de paquetage

2.5 Conception

2.5.1 Le modèle relationnel

2.5.2 Diagrammes d'états de navigation

Conclusion

CHAPITRE TROIS

DEpLoiEMENT ET MiSE EN (EuvRE D'uN

pRoToTypE Du SYGED

Introduction

3.1 Déploiement du Système

3.1.1 Architecture physique du système

3.1.2 Politique de sécurité adoptée