webmapping, gestion de la flotte

MEMOIRE POUR L’OBTENTION DU MASTER EN
INFORMATIQUE APPLIQUEE AUX SYSTEMES D’INFORMATION GEOGRAPHIE
(IASIG)
------------------------Année académique 2010-2011
THEME :
WEBMAPPING, GESTION DE LA FLOTTE :
DEVELOPPEMENT D'UNE APPLICATION DE GESTION SPATIALE
DE FLOTTE ET MAINTENANCE DES MOBILES VEHICULES
Auteur :
M. Siaka DIAKITE
Encadreurs :
Dr Mahamadou BELEM /Fondation 2iE
Dr Corentin SOME /Enseignant Fondation 2iE
DEDICACE
Je dédie ce mémoire contre toute attente peut-être, mais avec
conviction, et surtout avec le sentiment de reconnaissance du travail bien
fait, d’un homme sans l’abnégation de qui je ne serais peut-être jamais inscrit
à ce programme de master.
Je me rappelle encore, des premiers e-mails que je recevais la
sélection des candidats de la première promotion. Je ne saurais encore
oublier ces multiples e-mails de reports, de la date limite des inscriptions pour
me permettre de m’inscrire à ce master au moment où tous les espoirs
s’anéantissaient pour mon inscription à laquelle lui, il a toujours cru. Sans
mentionner ces innombrables autres e-mails intermédiaires entre ces deux
périodes m’apportant encouragements et conseils.
J’ai nommé ici, ce vaillant ingénieur de l’ENSG, Pascal BOULERIE.
Monsieur BOULERIE, tout simplement merci. Que Dieu vous accorde
davantage de savoirs et de savoir-être.
i
REMERCIEMENTS
Mes remerciements vont tout d’abord à Allah (SWT) qui m’a donné la
vie et tous les autres moyens qui ont été nécessaires pour suivre ce cursus de
master de l’université de Douala réalisé en partenariat avec l’Agence
Universitaire de la Francophonie (AUF), l’Ecole Nationale des Sciences
Géographiques (ENSG) et l’Université Paris Est Marne-la-Vallée (UPEMLV) de
France.
Je remercie tout spécialement mon épouse et nos enfants pour leur
endurance : « Habituellement, l’épouse est remerciée pour le sacrifice
consenti à cause des absences multiples de son époux, la laissant seule avec
les enfants, mais toi, tes efforts sont allés au-delà. Tu m’as aidé vertement
dans la production de ce mémoire par sa saisie et sa mise en forme. Initié,
Allah ka an to gnongon yé ».
En ce moment où ce stage s'achève sur une note de satisfaction de
notre part, et nous l'espérons aussi, de la part du commanditaire des travaux,
nous tenons à adresser nos plus vifs remerciements à tous ceux qui ont
contribué de près ou de loin à la production de ce mémoire, sans le
concours de qui, ce stage n'aurait probablement pas eu lieu tout
simplement. Il s’agit plus particulièrement de :
 Docteur Joseph Ngono MVOGO responsable académique de la
présente formation à l’Université de Douala ;
 Docteur Pascal BARBIER chargé de la formation à distance et
enseignant à l’ENSG ;
 Docteur Corentin SOME, enseignant chercheur à l’Institut International
de l’Ingénierie de l’Eau et de l’Environnement (2iE), et Docteur Mahamoudou
BELEM, également au 2iE, mes encadreurs lors de ce stage, pour la qualité de
l’encadrement ;
 Monsieur Marcel Guillaume MOUTOME, coordonateur administratif du
master à l’Académie internet, unique en son genre à la fois comique et
sérieux, très ouvert et prompte dans ses réactions à nos courriers ;
 Feu Docteur Ferdinand KENGMEZA qui était l'une des chevilles ouvrières
de ce cursus avec les modules comme Intro-Carto-SIG, Base de données
géographiques et serveurs cartographiques. Que la terre lui soit légère ;
 Docteur Bertrand TAMOKWE notre enseignant de management et
avec lui, tous nos enseignants du Cameroun pour leur sympathie et leur
dévouement pour ce master ;
 Le Professeur Jean Paul RUDANT enseignant à l’UPEMLV et tous ses
collègues de la partie française de ce partenariat exemplaire mis en œuvre
pour cette formation et qui nous ont marqués pour toujours ;
 Tous nos amis auxquels nous sommes et serons éternellement
reconnaissants pour leurs soutiens multiples et multiformes tout au long de
cette formation.
ii
RESUME
Au Burkina Faso, la dernière décennie a enregistré une avancée
significative des Technologies de l’Information et de la Communication (TIC)
mais étant un pays toujours en quête de positionnement parmi les pays en
voie de développement, il est confronté au faible niveau de pénétration des
technologies de pointe. En effet, si les différents projets nationaux font l’effort
de faire recours aux TIC tels que le stipulent les programmes et politiques
nationaux de développement comme la Cyber-Stratégie Nationale, un
domaine particulier, et non pas des moindres reste en réel déperdition : il
s’agit des Systèmes d’Information Géographiques (SIG) appliqués à la gestion
spatiale de flotte et maintenance des mobiles véhicules.
Les SIG sont une solution à certains problèmes récurrents rencontrés
dans la gestion courante des biens mobiles des particuliers ou de l’Etat. Il
n’est pas rare de relever de nombreuses insuffisances dans le suivi efficient
des flottes des sociétés privées ou des administrations publiques : situation
géographique pas toujours maîtrisée, utilisation des ressources consommables
et usables (carburant, pneumatique, etc) non optimale. Tout cela entache le
bon fonctionnement des services et entame le développement du pays dans
son ensemble.
Sur la base de ces constats, il opportun, voire indispensable qu’une
solution globale soit identifiée et proposée aux propriétaires ou gestionnaires
d’objets mobiles. C’est en cela que notre stage trouve sa justification pour
mener à la mise en place d’un système de géolocalisation et d’aide à la
maintenance de mobiles véhicules préconisé comme solution à tous ces
problèmes évoqués. Le stage a consisté donc, en l’étude de cette technique
pour en développer (conception et réalisation) pour le commanditaire.
Ainsi, les étapes fondamentales de notre travail se présentent comme
suit :
 Le cadrage de la mission ;
 L’étude préalable du système futur à partir de eXtreme Programming
(XP) adopté, dès à ce niveau, comme la méthode de développement à
suivre ;
 La conception détaillée de la solution retenue à l’aide du langage UML
choix en complément de la méthode XP ;
 Et une esquisse de réalisation qui a consisté à mettre d’abord en place
la base données nécessaire à la solution puis au développement d’une
interface web en relation avec la base données, à l’aide des
technologies OPENLAYERS et Web Feature Service (WFS) pour l’affichage
des résultats.
Mots-clés : géolocalisation, maintenance,
googlemaps, GPS, Webmapping
conception
de
logiciel,
iii
ABSTRACT
In Burkina Faso, the last decade saw a significant improvement of
Information Technology and Communication (ICT) but being a country still
searching for positioning among the countries in development, it still faces the
low level of penetration of advanced technologies. While the various national
projects make the effort to make use of ICT such as state policies and
programs of national development such as national e-strategy, a particular
area, not the least remains real loss: it These are Geographic Information
Systems (GIS) applied to the spatial management of fleet maintenance and
moving vehicles.
GIS is a solution to some persistent problems encountered in the
ongoing management of mobile assets of individuals or the state. It is not
uncommon to meet a number of shortcomings in the monitoring efficient
fleets of private companies or public authorities: location sometimes
uncontrolled, use of wearable and consumable resources (fuel, air, etc.) is not
optimal. All this mars the smooth running of services and begins the
development of the country as a whole.
Based on these findings, it appropriate, even essential that a solution is
identified and proposed to the owners or managers of moving objects. This is
where our training is justified to carry out the establishment of a geolocation
system and maintenance support for mobile vehicles advocated as a solution
to all these problems mentioned. The course consisted therefore in the study
of this technique to develop (design and implementation) for the sponsor.
Thus, the basic steps of our work are as follows:
 the framing of the mission;
 the preliminary study of the future system from eXtreme Programming
(XP) adopted at this level, such as the development method to be followed;
 detailed design of the solution using the UML language choices in
addition to the XP method;
 and a sketch of achievement that was to first put in place the basic
data necessary for the solution and the development of a web interface in
relation to the database, using OpenLayers technology and Web Feature
Service ( WFS) for displaying results.
Keywords: geolocation, maintenance, software design, googlemaps, GPS,
Webmapping
iv
ACRONYME /ABREVIATIONS
AUF
Agence Universitaire de la Francophonie
ENSG
Ecole Nationale des Sciences Géographiques
GPRS
General Packet Radio Service
GPS
Global Positionning System
GSM
Global System for Mobile Communication
IANA
Internet Assigned Numbers Authority
IASIG
IDE
Informatique Appliquée aux Systèmes d’Information
Géographique
Integreted Development Environnement
IP
Internet Protocol
OMG
Object Management Group
RFID
Radio Frequency IDentification
SGBD
Système de Gestion de Base de Données
SIG
Systèmes d’Information Géographique
SMS
Short Message Service
SQL
Structured Query Language
TIC
Technologies de l’Information et de la Communication
UML
Unified Modeling Language
UPEMLV
Université Paris Est Marne-la-vallée
WFS
Web Feature Service
XP
eXtrême Programming
v
SOMMAIRE
PREMIERE PARTIE : PRESENTATION DU THEME ........................................................................ 2
I-
CONTEXTE ET JUSTIFICATION ................................................................................... 3
II -
PROBLEMATIQUE....................................................................................................... 7
III -
OBJECTIFS DU STAGE................................................................................................ 8
IV -
ORGANISATION DU TRAVAIL ................................................................................... 9
DEUXIEME PARTIE : CONCEPTION DE LA SOLUTION ........................................................... 19
I. -
SPECIFICATION DES BESOINS (CAHIER DES CHARGES) ........................................ 20
II. -
CHOIX TECHNOLOGIQUES .................................................................................... 25
III. -
CONCEPTION DETAILLEE ........................................................................................ 35
IV. -
POLITIQUE DE SECURITE .......................................................................................... 41
vi
INTRODUCTION GENERALE
Le présent mémoire est rédigé pour l’obtention du diplôme de Master
en Informatique de l’Université de Douala en partenariat avec l’Agence
Universitaire de la Francophonie (AUF), l’Université Paris Est Marne-la-vallée
(UPEMLV), l’Ecole Nationale des Sciences Géographiques (ENSG) de France.
L’étude qui a conduit à la production de ce mémoire a été menée à
Full Space, une entreprise privée de droit burkinabé exerçant dans le
domaine des Systèmes d’Information Géographique (SIG). Le thème de ce
mémoire « Webmapping, gestion de la flotte : Développement d'une
application de gestion spatiale de flotte et maintenance des mobiles
véhicules » est un sujet d’actualité parce qu’il s’agira de proposer un système
de gestion de la flotte impliquant l’informatique, à même d’améliorer
l’actuel ; et cela n’est pas sans conséquences positives sur l’environnement
qui cristallise aujourd’hui tous les débats scientifiques.
Le problème majeur que nous devons résoudre se pose avec acuité
tant dans les structures privées (entreprises, association, ONG…) que dans les
structures de l’état : le suivi en temps réel des équipements mobiles et la
question de leur entretien lié soit à la distance parcourue pendant une
période donnée soit simplement au temps qui s’écoule. C’est l’exemple du
suivi en temps réel des véhicules des sapeurs pompiers qui ne se fait pas
actuellement mais qui pourrait permettre, si cela se faisait, d’améliorer
l’efficacité de ces derniers par l’apport d’une plus grande rapidité dans
l’affectation des véhicules aux différents cas de sinistres qui se situeraient
dans une ville. C’est un exemple parmi tant d’autres qui jonchent
malheureusement le quotidien des gestionnaires de flottes de mobiles. C’est
justement pour apporter notre contribution à tous ces gestionnaires de parc
automobile dans la résolution de leurs problèmes de suivi spatial en temps
réel et de maintenance que la présente étude est menée. Elle devra aboutir
à la mise en place d’une plateforme de géolocalisation1 associée à un
module de maintenance des mobiles2 véhicules qui devrait définitivement
résorber les problèmes évoqués.
Ainsi, ce mémoire se composera de deux parties. Dans la première
partie nous apporterons plus d’éléments pour éclaircir davantage le sujet et
élucider la consistance de la mission qui est la nôtre et la seconde partie sera
consacrée à la conception de la solution que nous proposons.
La conclusion viendra mettre fin à cette étude en évaluant les acquis
engrangés et en donnant les suites probables à réserver à la solution.
La géolocalisation ou encore géoréférencement est une technique permettant de
positionner un objet ou une personne sur un plan ou une carte à l'aide de ses coordonnées
géographiques.
2 Au sens de l’étude actuelle, un mobile est tout ce qui capable de se déplacer et auquel un
terminal a été associé pour son suivi. Il conviendra de distinguer un mobile véhicule qui est
doté d’un moteur mécaniques pour ses déplacements d’une part, et d’autre part d’un
mobile non véhicule qui peut-être soit une personne soit un animal.
1
1
PREMIERE PARTIE :
PRESENTATION DU THEME
2
Le but de cette partie, comme son titre l’indique, est de présenter le
thème du présent stage en donnant dans un premier temps des éléments
d’informations relatifs à son contexte et dans un deuxième temps sa
justification. Ensuite, après avoir posé la problématique de l’étude, les
objectifs recherchés seront définis et les moyens mis en œuvre pour sa
réalisation seront présentés finalement.
I - CONTEXTE ET JUSTIFICATION
I.1
Contexte
Le Burkina Faso, environnement de déroulement du projet, est un pays
enclavé avec une superficie de 274 200 km2 est situé au cœur de l’Afrique
Occidentale entre 15°03’13.05’’ et 09°21’18.95 de latitude Nord et 05°36’09.21
de longitude Ouest et 02°21’47.56’’ de longitude Est. Il est limité au Nord et à
l’Ouest par le Mali, à l’Est par le Niger et au Sud par le Benin, le Togo, le
Ghana et la Côte d’Ivoire.
Cameroun
Carte 1: Le Burkina Faso sur une carte du monde
L’économie du pays est essentiellement agricole (50% du PIB) avec 90% de la
population active exerçant dans ce domaine. Très peu de place y est donc
accordée au secteur tertiaire et en particulier aux Technologies de
l’Information et de la Communication (TIC) puisque c’est le reste de la
3
population active soit 10% qui s’occupent des autres secteurs de l’économie.
Avec une population de plus de 15 millions d’habitants, le potentiel de la
clientèle susceptible d’utiliser les résultats de notre projet est dans la frange
urbaine et est estimée à seulement environ 3 millions [CIA 2011]. Dans un tel
contexte d’emblée très peu favorable où les premières préoccupations des
populations sont à situer ailleurs que dans la géolocalisation, notre projet peut
paraître trop futuriste et sans enjeux. Mais loin s’en faut car son utilité est
certaine et les avantages qu’il est censé apporter à la gestion des mobiles
sont indéniables.
Malgré les handicaps que nous avons évoqués, des efforts sont faits et
le pays progresse et n’est pas resté en marge de l’évolution des TIC que
connaît le monde dans sa globalité :
- le nombre d’entreprise travaillant directement dans l’informatique s’est
multiplié avec un chiffre d’affaire global qui croit continuellement ;
- le niveau d’informatisation du pays est relativement meilleur à celui
qu’il avait, il y a une décennie ;
- de grandes infrastructures de télécommunications existent. Le pays est
même très en avance par rapports à nombreux de ses voisins et
constitue une référence en matière des TIC dans la sous région ouest
africaine ;
- le parc automobile et autre engins mobiles (sans les vélos) susceptible
d’être concerné par notre produit est estimé à environ un million ;
- plusieurs entreprises de location de voitures existent de nos jours et sont
de potentielles utilisatrices du produit ;
Nous avons évoqué plus haut la question démographique. Il dire que le taux
d’alphabétisation de la population s’est considérablement améliorer ces
dernières années.
4
I.2
Justification
Le problème majeur qui justifie notre projet est l’absence notoire de
visibilité des équipements mobiles sur le terrain. Les acteurs (futurs clients) se
plaignent notamment du fait que dans l’état actuel de la gestion, il est :
- impossible de savoir en temps réel où se trouve un véhicule d’un parc :
pour les transporteurs par exemple, il serait intéressant de savoir avec
exactitude la position d’un camion de marchandises en transit entre
une ville du pays et un port se situant dans un autre pays (puisque le
pays est sans littoral). Ils pourraient ainsi être rassurés et les aidés dans
les prévisions de ravitaillement de leur clientèle ;
- impossible de disposer des statistiques fiables sur les déplacements d’un
véhicule d’un parc ;
- impossible encore pour les pompiers et autres policiers de gérer en
temps réel une mission de terrain depuis la base. Or, s’ils disposaient
d’une telle possibilité leur efficacité et leur rendement s’en trouverait
ainsi améliorés.
Les avantages du système futur à mettre en place sont nombreux et nous
pouvons citer entre autres :
- la gestion en temps réel du déroulement d’une mission de terrain
depuis la base par les agents de sécurité et de l’ordre ;
- permettre à un service de secours d’arriver plus vite sur un lieu
d’intervention en choisissant le véhicule le plus proche ;
- permettre à une société de livraison de sécuriser le trajet d’un fourgon
lors d’une livraison sensible en le « pistant » ou encore d’optimiser la
planification de tournées de livraisons, en comparant les itinéraires
empruntés avec les itinéraires optimaux ;
- dès lors que l’activité de l’entreprise fait appel à plusieurs véhicules
dans des secteurs géographiques différents, le système pourrait
permettre d’optimiser la sécurité et la gestion de sa flotte ;
- pour un particulier, cela lui permettrait de surveiller les éléments de sa
famille ou autres bien mobiles de manière à les retrouver facilement en
cas de malheur ;
- permettre de repérer facilement les mobiles volés ou détournés ;
- permettre aux pompiers d’être efficients. En effet, le maintien d’un
véhicule en de fin mission dans une zone où un autre cas de sinistre
vient de se produire est plus efficace et plus économique que de
vouloir soit attendre que ce véhicule rejoigne la base avant de repartir
dans la zone du sinistre soit (simplement) affecter un autre véhicule à la
nouvelle mission comme cela se fait dans les pratiques actuelles, avec
tous les frais que cela engendre ;
- permettre, du même coup la réduction dans l’émission des gaz à effets
de serre pour la préservation de l’environnement par la diminution de
la consommation des hydrocarbures utilisés par ces véhicules.
5
Ce sont toutes ces raisons qui nous motivent à mettre en place notre
solution surtout qu’actuellement aucune autre n’existe véritablement3 au
Burkina Faso. Des attentes légitimes d’une certaine frange de la population,
certes pas très nombreuse mais croissante, seraient satisfaites tant est aussi
forte notre motivation. C’est aussi là, tout l’enjeu de ce projet qui devra être
pérenne en s’améliorant au fil des années pour atteindre la rentabilité
escomptée. Les potentielles cibles utilisatrices (futur clients) du système sont :
les compagnies de transport ;
les agences de location de véhicules ;
les particuliers (membre de la famille, voitures…) ;
le parc automobile de l’Etat ;
les grandes entreprises ;
les forces de l’ordre et de sécurité ;
les pompiers ;
3
Quelques solutions commencent à voir le jour mais restent toutes encore inconnues du grand public car très
récentes. Le marché reste donc ouvert. Il y a entre autres les solutions de TRAMIGO et ISEC. En plus, ce sont
des solutions étrangères tentant de s’installer au Burkina.
6
II - PROBLEMATIQUE
Notre projet s’inscrit tout d’abord dans une dynamique d’appui aux
gestionnaires logistiques (logisticiens) des entreprises qui n’ont aucune visibilité
sur les équipements gérés une fois que ces derniers sont sur le terrain. Le futur
outil de gestion de flotte en conception interviendra surtout au niveau du
contrôle car gérer c’est aussi contrôler. En effet, Henri Fayol serait le premier à
étudier le métier de gestionnaire. « Son approche en cinq composantes
(prévoir, organiser, commander, coordonner et contrôler [POCCC]) reste à la
base des réflexions sur le contenu de la fonction de direction… » [TAM, 2011].
L’outil permettra au gestionnaire de flotte de mieux contrôler et pouvoir
prendre des décisions éclairées. En un mot, il aidera à une meilleure gestion
des flottes. Ensuite, il peut intéresser toute personne désirant avoir une visibilité
en temps réel sur un quelconque mobile en sa possession et qu’il aimerait
surveiller pour des raisons diverses.
Aussi, l’outil à mettre en place devra aider à la maintenance des
mobiles véhicules. Ce point précis de la maintenance constitue le défi majeur
à relever dans ce projet. En effet, nous avons connaissance de solutions qui
existent de part le monde (par exemple, une en Chine que nous utilisons
actuellement pour étudier les terminaux acquis dans le cadre de ce projet, et
celles qui tentent de s’installer ; TRAMIGO) mais qui ne prennent pas en
compte cette question de la maintenance comme nous l’entendons. Aussi,
avons-nous souhaité mettre en place notre propre système capable
d’apporter l’appui nécessaire à la maintenance de mobile tout en
garantissant, tout aussi efficacement sinon mieux que celui que nous utilisons
actuellement (la plateforme chinoise), leur gestion spatiale.
Comme signalé ci-dessus, actuellement au Burkina, les habitudes en
matière de gestion logistique n’incluent pas le volet du suivi en temps réel des
mouvements des véhicules. Ainsi, les gestionnaires se contentent d’allouer les
ressources aux utilisateurs (chauffeurs notamment) sans avoir la moindre
possibilité de vérifier si elles (les ressources) sont utilisées à bon escient.
Impossible également pour eux de savoir si les mobiles ont effectivement fait
le parcours initialement prévu, pour lequel les ressources avaient été
allouées ; et ce, même pas en différé encore moins en temps réel. Nous
restons convaincus que ce présent projet comblera largement ce manque à
gagner pour les gestionnaires de flotte et améliorera leur gestion et leur
rendement.
Le défi essentiel pour nous, dans le cadre de ce stage est d’aboutir, à
l’issue des phases conceptuelle et de réalisation, à une plateforme de
géolocalisation ayant pour finalité d’améliorer aussi bien la gestion spatiale
des flottes que la maintenance, selon plusieurs indicateurs, des mobiles
véhicules.
7
III - OBJECTIFS DU STAGE
III.1 -
Objectifs du système futur
L’objectif global du présent stage est de proposer un système de
gestion de flotte à même de combler toutes les insuffisances de la gestion de
flotte actuelle. Il s’agira plus spécifiquement de mettre en place une solution
complète de gestion de flotte, basée sur le Webmapping4, qui offrira les
fonctionnalités suivantes :
 Suivi des déplacements d’un mobile en temps réel ;
 Consultation de l’historique de déplacements d’un mobile ;
 Suivi de toute ou partie d’une flotte en temps réel ;
 Consultation de historique des activités de toute ou partie d’une flotte ;
 Création de points d’intérêt pour la configuration d’alertes sur des
événements impliquant les mobiles (ou les flottes) et lesdits points ;
 Création de zones d’intérêt pour la configuration d’alertes également ;
 Localisation des mobiles les plus proches d’un point ;
 Calcul d’itinéraires à emprunter par un mobile pour l’optimisation de
ses parcours ;
 Forçage de l’arrêt d’un ou plusieurs mobiles véhicules à une position
donnée en cas de besoin ;
 Configuration d’alertes (entrée/sortie de zone d’intérêt, dépassement
de vitesse, atteinte d’un point d’intérêt, changement de filtres, d’huile,
de roues …) par mail ou SMS ;
 Génération de rapports périodiques automatiques ou à la demande
sur le temps de conduite, le temps d’arrêt, la distance parcourue, la
vitesse moyenne sur un parcours, les zones couvertes (ou traversées)
par les mobiles, etc.
Il s’agit plus exactement d’une plateforme de géolocalisation annexée
à un module aussi léger soit-il, de gestion de la maintenance assistée à
l’ordinateur (GMAO).
III.2 -
Résultats attendus
Notre stage devra aboutir à la production des éléments suivants :
 Un dossier de conception de la solution décrite ci-dessus ;
 Les scripts de création de la base de données nécessaire à la mise en
place de la solution ;
 Une version exploitable de la solution ;
 Les programmes sources de cette version ;
4
Webmapping ou cartographie sur internet.
8
IV -
ORGANISATION DU TRAVAIL
IV.1 - Méthodologie
Pour conduire la mission de mise en œuvre de la solution, une
méthodologie de travail qui s’inspire des bonnes pratiques, a été adoptée.
Dans cette partie du document, la démarche est clairement présentée pour
donner une meilleure lisibilité de notre approche. Ainsi nous adoptons une
approche Agile comme méthodologie de travail, et le langage UML nous
servira d’appui à la modélisation du système à informatiser. Pour la
présentation du langage UML, nous y reviendrons plus loin.
IV 1.1 - Vers une méthode agile
Les méthodologies classiques sont des approches prédictives basées
sur des activités séquentielles : recueil des besoins, analyse détaillée,
conception détaillée, réalisation du produit, test, contrôle qualité, intégration,
livraison au client. Cette rigidité qui a été à l’origine de l’échec de nombreux
projets, a révélé les limites de ces approches traditionnelles. Du coup, la
nécessité de disposer de méthodes s’adaptant aux évolutions constantes des
besoins des utilisateurs s’est posée.
Concevoir n’étant pas une activité linéaire mais plutôt une tâche très
complexe avec souvent la nécessité de considérer de nouvelles
compréhensions du problème posé, nous privilégions ici une approche
itérative, orientée résultat et non séquentielle, approche qui puisse nous
permettre de gagner du temps dans la mise en œuvre de notre solution [VER
2009].
Ainsi, nous avons adopté comme méthodologie de travail, eXtrême
Programming (XP), une méthode agile souple face aux besoins d’adaptation,
facilitant ainsi l’agilité de notre solution au regard des contraintes de mise en
œuvre.
XP propose d'utiliser un cycle très court de design, développement et
test, avec des mises en productions fréquentes. L'objectif est d'augmenter la
flexibilité, de diminuer le risque associé à de longs délais, et de créer de la
valeur le plus rapidement et le plus souvent possible pour le client. Les
grandes étapes de XP sont :
Étape 1 : exploration : il s’agit du niveau de planification global établi à partir
de la vision du produit et du product backlog priorisé par le client. Il
correspond au plan initial ou enveloppe globale. C’est la pièce maîtresse du
dispositif qui définit une estimation relative des fonctionnalités. A ce stade
d’avancement, les fonctionnalités ou exigences ne sont pas homogènes en
granularité : il s’agit pour l’équipe d’évaluer très grossièrement l’importance
ou la taille des différentes fonctionnalités, afin de les positionner dans les
différentes versions. En fait, c’est la définition des objectifs, la ligne d’arrivée.
9
Étape 2 : planning : à l’intérieur de cette zone, entre le début et la ligne
d’arrivée, on pose des jalons intermédiaires. Des versions successives du
produit doivent être livrées en fonction des priorités définies par le client ;
chaque livraison constituant une release, une version majeure du produit. Les
fonctionnalités de haut niveau sont affectées aux différentes releases en
tenant compte des contraintes client, des événements marketing, d’une
stratégie de l’entreprise, qui agissent comme une moule. Les dates à
l’intérieur ne sont pas nécessairement fixes. Ce sont les facteurs externes qui
vont influer sur la durée des releases.
Étape 3 : plan de la release : une release se définit par une date de début et
une date de fin, un thème et une sélection de fonctionnalités à implémenter.
A l’intérieur d’une release, on définit des itérations, auxquelles sont affectées
les différentes stories. Planifier une release revient donc à ventiler des
fonctionnalités dans des itérations de taille déterminée, pour obtenir un plan
de release c’est-à-dire, pour cette release, le nombre d’itérations, leurs dates
de début et de fin, ainsi que les fonctionnalités à y développer.
Étape 4 : plan d’itération : à l’intérieur des jalons de fin et début d’itération, on
définit ce que l’on va y faire. Lorsque l’itération débute, les stories retenues
sont détaillées, à leur tour, pour estimer les activités à réaliser. Au sein d’une
release, seule l’itération qui débute est planifiée en détail ; toutes les activités
techniques pour réaliser les stories affectées à l’itération sont concernées :
analyse, conception, développement, test, documentation… indispensables
à l’implémentation complète d’une fonctionnalité de haut niveau
potentiellement livrable à la fin de l’itération. Une telle fonctionnalité n’est
donc considérée comme achevée que lorsqu’elle a été validée par le client
et documentée [KEN 2001].
Étape 5 : cycle quotidien : une équipe agile se réunit chaque jour pour suivre
l’avancement de l’itération en cours : c’est le daily stand-up meeting, rapide
réunion de quinze à vingt minutes au cours de laquelle chaque membre de
l’équipe fait le point sur ce qu’il a fait la veille, ce qui va être fait le jour même
et les éventuels blocages rencontrés. Cette réunion permet de réajuster très
rapidement le planning, l’organisation ou la répartition des taches pour la
journée à venir, et prendre des décisions tactiques, sans attendre la fin de
l’itération. La figure ci-dessus illustre le cycle de vie d’un projet XP.
10
Figure I. Cycle de vie d’un projet XP [BUS, 2001]
Une méthode agile est une approche incrémentale et itérative, favorisant
une franche collaboration entre les acteurs du projet (le concepteur,
l’utilisateur…). Elle conduit à un produit de qualité capable d’évoluer en
fonction des futurs besoins des clients.
Une méthode agile offre les avantages suivants :
Une approche incrémentale et itérative: les itérations sont des
découpages du projet en de petites étapes dont le déroulement ne requiert
que quelques semaines. Chaque itération débouche nécessairement sur une
version du logiciel que le client appréciera pour valider ou pas.
Le logiciel se construit ainsi progressivement au fil des itérations : c’est
l’approche incrémentale. Chaque itération est donc un mini-projet en soi qui
comporte toutes les activités de développement, menées en parallèle :
analyse, conception, codage et test. L’objectif est d’obtenir au terme de
chaque itération, un sous-ensemble opérationnel du système cible, et au
terme de la dernière itération, la version finale du produit.
Un esprit collaboratif : les méthodes agiles privilégient la
communication entre les différents membres de l’équipe chargée de la mise
en œuvre effective du projet. Au lieu de commander et contrôler son équipe,
le chef de projet doit être le manager qui sait créer les conditions optimales
pour permettre à chacun de contribuer efficacement au résultat de l’équipe
en vue d’une meilleure satisfaction du client. Les méthodes agiles privilégient
également la communication entre l’équipe et ses différents interlocuteurs
comme le client et les utilisateurs.
Une réduction des risques : motivée par la livraison de valeur ajoutée
pour le client, soucieuse de démontrer son adaptabilité et guidée par une
meilleure visibilité, une équipe agile réduit les risques d’échec du projet.
Grâce au feedback permanent, les dérives ou les dysfonctionnements sont
détectés précocement ou à temps, et peuvent être amoindris, par
l’acceptation du changement.
11
IV 1.2 - Parlons UML
Notre choix pour la modélisation du système a porté sur le langage de
modélisation UML (Unified Modeling Language : langage de modélisation
unifié) qui lui aussi comme la méthode XP, préconise une démarche itérative
et incrémentale, guidée par les besoins des utilisateurs du système et centrée
sur l'architecture logicielle.
Une démarche itérative et incrémentale consiste à modéliser un
système complexe en affinant son analyse par étapes. Cette démarche
s'applique à tout le cycle de développement et favorise le prototypage5.
Une démarche guidée par les besoins des utilisateurs consiste à
délimiter le périmètre du système. Les besoins des utilisateurs servent de fil
conducteur tout au long du cycle de développement. A chaque phase
(analyse, conception, réalisation, test, ...) on vérifie l'effectivité de la prise en
compte des besoins des utilisateurs.
Enfin, une démarche centrée sur l'architecture consiste à définir une
architecture adaptée qui décrit les choix stratégiques déterminant la qualité
du système (adaptabilité, performances, fiabilité, ...).
UML est un langage graphique de modélisation des données et des
traitements. C'est une formalisation très aboutie et non-propriétaire de la
modélisation objet utilisée en génie logiciel. UML est l'accomplissement de la
fusion des précédents langages de modélisation objet que sont Booch, OMT,
OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et
Ivar Jacobson, UML est à présent un standard défini par l'Object
Management Group (OMG). L'OMG diffuse depuis novembre 2007 la version
UML 2.1.2, et travaille à présent sur la version 2.2. UML propose neuf (09)
diagrammes qui sont classés en deux catégories :
Les
diagrammes
structurels
(vue
statique)
et
les
diagrammes
comportementaux (vue dynamique).
VUE
Statique
Dynamique
DIAGRAMMES
Cas d’utilisation, Classes, Objets
Composants, Déploiement
Séquence, Collaboration
Activités, Etats-transitions
Tableau I : liste des diagrammes du langage UML
Signalons que tous ces diagrammes ne sont nécessaires encore moins
obligatoire à la conception d’une solution. C’est des moyens que UML met à
Prototypage : Le prototypage (ou maquettage) est la méthode de base pour la
conception des interfaces en ergonomie informatique. Il présente l’intérêt de matérialiser
l’interface, et par la même occasion le logiciel ou le site web, et sert de référence aux
différents acteurs du projet qui, par ce biais, vont s’accorder sur un langage commun. Le
prototype peut également servir à la promotion commerciale du produit et être utilisée à des
fins de démonstration par les équipes commerciales avant le lancement officiel du produit.
5
12
la disposition des concepteurs de logiciels pour leur permettre de se faire des
visions variées sur la solution à réaliser. Pour des besoins de concisions et
d’efficacité nous présenterons ici, deux diagrammes qui serviront dans la
conception de notre solution : le diagramme des cas d’utilisation et le
diagramme de classes.
IV 1.2.1. Le Diagramme de cas d’utilisation
Les cas d’utilisations, appelés aussi « use case » permettent de
modéliser les fonctionnalités du système. Le diagramme des cas d’utilisation
fait ressortir les acteurs et les fonctions d’interface offertes par le système. Un
acteur est une personne ou une machine agissant sur le système dans le but
de modifier ou de consulter. Les cas d’utilisations sont une description du
comportement du système vis-à-vis de l’utilisateur. C’est la représentation
d’une fonctionnalité, déclenchée en réponse à une stimulation du système
par un acteur.
Package
Cas d'utilisation 1
Acteur
Cas d'utilisation 2
Figure II : illustration d’un digramme de cas d’utilisation
IV 1.2.2 Le Diagramme de classes
Le diagramme de classes est considéré comme le plus important de la
modélisation orientée objet ; il est le seul élément obligatoire lors d’une telle
modélisation. Il montre la structure interne du système. Il permet de fournir une
représentation des objets du système qui vont interagir ensemble pour réaliser
les cas d’utilisation décrits plus loin. Il s’agit d’une vue statique faisant
abstraction des aspects dynamiques et temporels dans le comportement du
système.
En d’autres termes, le diagramme de classes est une collection
d'éléments de modélisation statiques (classes, Paquetages, interfaces...),
connectés entre eux (relations, agrégations, héritages…) pour former un
graphe qui montre la structure d'un modèle. Il représente la description
statique du système en intégrant dans chaque classe la partie dédiée aux
données et celle consacrée aux traitements. C'est le diagramme pivot de
l'ensemble de la modélisation d'un système. Le diagramme de classes
13
modélise les concepts du domaine d’application ainsi que les concepts
internes créés de toutes pièces dans le cadre de l’implémentation d’une
application. Il permet de modéliser les classes du système et leurs relations
indépendamment d’un langage de programmation particulier.
Une classe est une représentation descriptive d'un ensemble d'objets
ayant des propriétés similaires (les attributs) et des comportements communs
(les opérations ou méthodes). Une classe se caractérise donc, par :
- ses attributs (ou champs, ou variables d'instances) : Les attributs d'une
classe décrivent la structure des objets que représente ladite classe ;
- ses méthodes (ou opérations de la classe) : Les méthodes décrivent les
opérations qui sont applicables aux objets de la classe.
Une agrégation est une association correspondant à une relation qui
lorsqu'elle est lue dans un sens signifie "est une partie de" et lorsqu'elle est lue
dans l'autre sens elle signifie "est composé de".
Figure III : Illustration d’un diagramme de classes
14
IV 1.3 - Organisation des acteurs du projet
Les différents groupes de travail constitués pour la mise en place du
système futur sont les suivants :
 Un comité de pilotage dont le rôle est de définir les grandes
orientations stratégiques et technologiques liées au projet. Il est composé de
deux personnes :
Dr. Corentin SOME, responsable et commanditaire du projet ;
Et Dr. Mahamoudou BELEM, encadreur du présent mémoire ;
 Un groupe de projet qui sera chargé de la mise en œuvre effective du
projet par la conception, la réalisation et le déploiement de la solution
retenue. Son travail est régulièrement soumis à validation au comité de
pilotage. Il est composé pour cette première itération de M. Siaka DIAKITE
dans le cadre de son stage de fin master IASIG.
15
IV.2 - planning prévisionnel
N°
01
02
03
04
05
06
ACTIVITE
ECHEANCE
CADRAGE DE LA MISSION
Jusqu’en début juin
Juin à juillet
Août à octobre
Novembre à décembre
Janvier
Février
ETUDE PREALABLE
CONCEPTION DETAILLEE
REALISATION
MISE EN ŒUVRE (TEST)
DEPLOIEMENT
Tableau II : Planning prévisionnel de déroulement du stage
Chaque étape est sanctionnée par un rapport qui devra être validé
par le comité de pilotage avant le passage à l’étape suivante afin d’éviter
de développer un produit qui ne répondrait pas au objectifs définis ci-dessus.
Ainsi, la compilation de ces rapports d’étape constituera l’essentiel de notre
mémoire. Néanmoins, il faut noter que ce planning est simplement indicatif
car susceptible de changer en fonction de l’évolution du stage ou de
nouveaux objectifs du système futur qui peuvent être fixés à tout moment par
le comité de pilotage.
16
IV.3 - recherches documentaires
Il faut dire que la littérature est abondante sur le sujet de la
géolocalisation, mais exceptés quelques documents, la plupart reste
superficielle et n’aborde pas le volet technique en détail ; et ce tant sur le
plan numérique (Internet pour l’essentiel) que sur le plan des livres imprimés.
Là encore, c’est la géolocalisation seule qui est traitée et la question de la
maintenance associée est loin d’être perçue par les auteurs. Autant dire
donc, que notre thème se caractérise par son originalité mais pas seulement,
car il demeure pertinent et reste d’actualité et surtout un défit qu’il faut
relever. Néanmoins, nous avons pris connaissance dans le cadre de ce
présent stage avec une multitude de livres hautement riches pour la
conception, la réalisation et la maintenance de système d’information
géographique en général et que nous avons mis à profit pour la bonne
conduite de nos travaux. L’ensemble de tous les documents utilisés pour la
production de ce mémoire est présenté dans la bibliographie en indiquant à
l’appui tous les emprunts faits.
17
CONCLUSION PARTIELLE
Au terme de cette première partie, le thème étant clairement
expliqué, les objectifs à atteindre définis, il ne reste plus qu’à s’attaquer au
problème et à le résoudre. Nous allons donc passer à la conception de notre
solution en utilisant la méthode XP présentée plus haut.
18
DEUXIEME PARTIE :
CONCEPTION DE LA SOLUTION
19
L’objectif à ce niveau est d’aboutir à un dossier complet de
conception de notre solution à partir duquel la première itération de la phase
de réalisation, comme préconisée par la méthode XP, pourra commencée.
Ainsi, nous traiterons successivement de la question du cahier des charges
utilisateur du système futur, des choix techniques et/ou technologiques à
opérer pour toute la phase de réalisation, des différents diagrammes de la
modélisation détaillée du système avant de terminer par la proposition d’une
politique de sécurité.
I. - Spécification des besoins (cahier des charges)
L’étude conceptuelle a débuté par le recueil des besoins à travers les
interviews auprès du commanditaire de l’étude et les potentiels clients. Ces
interviews nous ont permis très vite de cerner les contours du système futur, de
spécifier et d'identifier de façon précise toutes les fonctionnalités à
développer. Aussi, cette analyse nous a-t-elle permis d’estimer l’ampleur du
travail et le temps nécessaire à la réalisation de la solution préconisée.
Ainsi, le produit à développer devra prendre en charge :
 le stockage des données générées par un mobile dans une base de
données SIG (automatique);
 la mise à jour des informations relatives à un mobile (création,
modification, suppression)
 le suivi en temps réel des activités d’une flotte ;
 la consultation de l’historique d’une flotte ;
 la génération d’un rapport périodique (temps de conduite ou d’arrêt,
distance parcourue, zones couvertes…) ;
 la création de points et de zones d’intérêt ;
 la localisation des mobiles les plus proches d’un point ;
 le calcul d’itinéraires à emprunter par un mobile lors d’une mission ;
 l’envoi de commandes de configuration à un terminal6 ;
 la configuration et l’envoi d’alertes (entrée/sortie de zone d’intérêt,
atteinte de points d’intérêt, dépassement de vitesse, changement de filtres,
d’huile, de roues des véhicules…) par e-mail ou SMS.
Pour réussir la conception et faciliter le travail de la réalisation du
produit, une analyse a permis de regrouper les besoins exprimés en trois
catégories. En plus, un module cartographique sera nécessaire pour avoir
une plateforme complète de géolocalisation et parce que la « présentation
graphique est indispensable à la gestion du résultat d’une interrogation
spatiale » [MIC 2002]. Nous trouvons en « googlemaps » un module
cartographique suffisamment élaboré par conséquent, notre travail
consistera uniquement à développer un module web en relation avec une
Un terminal est un équipement électronique associé à un mobile pour la détermination des
informations de navigations. Selon la technologie, il peut être un ordinateur équipé d’une
carte réseau informatique (wifi ou Ethernet), un téléphone portable ou autre. Dans notre cas
il s’agit d’un navigateur GPS spécial présenté plus loin.
6
20
base de données couvrant les trois catégories de besoins déterminés qui en
constitueront les packages7 :
- l’administration du système ;
- la gestion spatiale des mobiles ;
- la maintenance des mobiles.
Le système est décomposé en package, et chaque package est considéré comme un
module qu’on peut développer de façon autonome.
7
21
I.1 - L’administration du système
Ce module regroupe les fonctionnalités d'administration de la plateforme en général et des comptes utilisateurs. Ainsi, les informations suivantes
doivent être considérées pour la gestion des comptes :
1. code du client ;
2. type du client ;
3. nom et prénoms du client ;
4. date et lieu de naissance du client ;
5. sexe du client ;
6. nationalité du client ;
7. situation matrimoniale du client ;
8. domaine d’activité du client ;
9. raison sociale du client.
10. adresse (téléphone, courriel, boite postale,…) du client ;
11. code de l’utilisateur ;
12. type de l’utilisateur ;
13. nom et prénoms de l’utilisateur ;
14. date et lieu de naissance de l’utilisateur ;
15. sexe de l’utilisateur ;
16. nationalité de l’utilisateur ;
17. situation matrimoniale de l’utilisateur ;
18. domaine d’activité de l’utilisateur ;
19. fonction de l’utilisateur chez le client ;
20. adresse (téléphone, courriel, boite postale,…) de l’utilisateur ;
21. login de l’utilisateur ;
22. mot de passe de l’utilisateur ;
L’administrateur étant considéré comme utilisateur avec des privilèges
importants, il n’est pas considéré comme une entité à part entière.
22
I.2 - La gestion spatiale
Ce module constitue la partie essentielle du produit. Il permettra de
localiser les mobiles sur le terrain en associant à chaque mobile ses
coordonnées géographiques placées sur une carte à chaque fois que
l’utilisateur le souhaite. Les informations gérées à ce niveau sont :
1.
2.
3.
4.
5.
le code du mobile ;
le code du terminal ;
l’IMEI du terminal ;
le type de mobile ;
le code la flotte. Une flotte est simplement un ensemble (dont le
nombre être limité) de mobile à la disposition d’un même client ;
6. le motif de la création d’une flotte ;
7. les coordonnées géographiques du mobile ;
8. l’instant t (la date et l’heure précise) de la prise des coordonnées ;
9. la vitesse du mobile à l’instant t ;
10. l’immatriculation du mobile véhicule.
23
I.3 - La maintenance des mobiles
A ce niveau, il s’agit d’une gestion de la maintenance assistée à
l’ordinateur comme énoncé plus haut. Il s’agira essentiellement d’alerter le
client par SMS ou par e-mail quand un événement précis adviendrait sur les
éléments de maintenance liés soit à la distance soit au temps. Les éléments à
considérés pour cette première itération sont :
Maintenance liée à la distance :
1. changement du filtre et du pré filtre à essence/gasoil ;
2. changement du filtre à essence/gasoil ;
3. changement du filtre à air ;
4. vidange moteur ;
5. vidange boîte de vitesse ;
6. vidange du pond-essieu ;
7. changement de la courroie de distribution ;
Maintenance liée au temps :
8. l’assurance ;
9. la visite technique.
Autres éléments pour la logistique :
10. rapport mensuel sur les distances parcourus ;
11. la durée de déplacement ;
12. la consommation de carburant ;
13. les coûts de fonctionnement.
Tout au long de la réalisation, un accent particulier devra être mis sur
les critères de qualité logicielle en général et en particulier sur l'ergonomie et
la convivialité. Il est important d'insister également sur la simplicité d’utilisation
du système à mettre en œuvre.
24
II. - Choix technologiques
Cette phase représente la branche technique de la démarche XP. Elle
couvre tous les déterminants et les choix nécessaires pour une architecture
appropriée à la conception du système. Elle nous permet ainsi de déterminer
les technologies, les outils et le matériel adapté pour la mise en place du
système en prenant en compte les contraintes de son environnement.
II.1 - Principe de géolocalisation : choix matériels
Comme nous venons de voir ci-dessus [objectifs du système futur], notre
mission consiste à mettre en place une plateforme de géolocalisation devant
également aider à la maintenance des mobiles. Sur le plan matériel voici,
globalement un schéma de l’environnement du système futur.
Système GPS
serveurs
GSM/GPRS
inter
net
Client
Mobile*
*Mobile au sens de l’étude.
Figure IV: architecture matérielle de la solution
Cette figure représente l’architecture matérielle que nous avons choisie
pour le système futur que nous proposons. Les éléments constitutifs de ce
système de géolocalisation par le système GPS, schématisé ci-dessus sont
essentiellement les suivants :
- le mobile associé à un terminal servant à calculer les informations de
navigation (coordonnées géographiques, vitesse …) relatives audit
mobile ;
25
-
-
le système GPS utilisé par le terminal pour ses calculs ;
Un réseau GSM/GPRS que le terminal utilisera pour transmettre les
données aux serveurs ;
Un ensemble de serveurs constituant physiquement la plateforme. Il se
compose d’un serveur de base de données, d’un serveur d’application
et d’un serveur cartographique ;
Et enfin, un réseau informatique pour la diffusion des données [WIK, 1]
(notamment internet ou un intranet).
D’ores et déjà, il faut dire qu’il existe plusieurs types de solutions de
géolocalisation liés à l’architecture matérielle. Ils utilisent tous des
technologies variées pour la constitution de leur architecture matérielle mais
la technique de géolocalisation reste globalement invariable dans ses étapes
fondamentales qui sont au nombre de trois (3) :
1. la détermination des informations de navigation relatives au mobile
notamment les coordonnées géographiques du mobile suivi ;
2. la transmission, la réception, le stockage et le traitement par les serveurs
des informations venant de la première étape ;
3. l’affichage sur un fond cartographique des résultats des traitements
effectués à la deuxième étape (c’est-à-dire par les serveurs).
Dans les solutions de géolocalisation qui existent, on rencontre à
chaque étape (citée ci-dessus) une certaine combinaison des éléments
énumérés plus haut pour arriver au résultat qui est de pouvoir obtenir et
positionner les informations de navigation du mobile sur une carte.
C’est à l’étape de la détermination des informations de navigation du
mobile suivi, que subsiste généralement des différences majeures entre les
solutions en matière de technologies mise en œuvre. En effet, pour la
détermination des informations de navigation, on rencontre dans certaines
solutions l’usage de technologies satellitaires. Tandis que dans d’autres
solutions ce sont des technologies comme le wifi, le GSM, les adresses IP (sur
internet) ou le RFID (la radio-identification) qui sont utilisées. Autant donc de
solutions aussi variées que nombreuses.
Parlant du wifi et du GSM, c’est le même principe qui est utilisée. Elle
consiste à déterminer les informations de navigation (la position notamment)
d’un terminal (wifi ou GSM selon le cas) en se basant sur certaines données
relatives à des points matériels fixes (pilonnes pour le GSM ou points d’accès
pour le wifi) dans ces réseaux sans fil. La précision avec ces technologies
dépend de la densité du réseau et est au mieux de l’ordre de 200 mètres.
Pour les adresses IP, le principe se base sur la très contrôlées gestion des
adresses IP au monde assurée par l’IANA. Cette technique de détermination
des informations de navigation par les adresses IP reste très peu efficace car
la précision est de l’ordre du pays ou souvent dans le meilleur des cas, de
l’ordre de la ville.
Quant au RFID, c’est une technologie qui peut être utilisée pour la
géolocalisation en intérieur où le système GPS est parfois inefficace, surtout
avec les premiers navigateurs.
26
Il faut noter qu’il existe des solutions qui utilisent à la fois plusieurs de ces
technologies que nous venons d’évoquer. Toujours par rapport à cette
première étape de la géolocalisation qu’est la détermination des
informations de navigation des mobiles, nous avons vu que pour notre
solution c’est une technologie satellitaire à savoir le système GPS qui a été
choisi. Le système GPS est présenté ci-après ainsi que le terminal associé ;
lequel dans notre solution, intervient tant à la première étape qu’à la
deuxième.
Il existe plusieurs autres technologies matérielles (toutes étapes
confondues) mise en œuvre dans la géolocalisation mais nous ne pouvons
pas toutes les décrire ici. Ce qu’il faut retenir, c’est que nous avons fait les
meilleurs choix possibles au regard de nos moyens financiers et de la
simplicité de mise en œuvre qu’il faudrait pour notre solution.
27
II.1.1.
Le système GPS
Le réseau satellite pour la détermination des informations de navigation
le plus connu, bien que l'alternative européenne nommée Galileo soit en
cours de déploiement, le GPS est à l’origine, un outil de l’armée américaine
en évolution continue depuis 1973. Il se compose de trois parties essentielles
qui sont :
 le secteur spatial : il constitué actuellement par une constellation de 32
satellites 8 autres de secours [USN 2011]. Les 24 satellites tournant autour de la
terre à une fréquence d’environ 2 tours par jour et à une altitude de 20 200
km, sont en orbites dans 6 plans différents de 4 satellites chacune. Les plans
des orbites ont une inclinaison par rapport à l’équateur de 55° optimisant
ainsi, la qualité de la couverture au dessus des Etats-Unis ;
 le secteur de contrôle : maintenant tout le système constamment
disponible, il est la propriété absolue de l’armée américaine. Il est constitué
de 5 stations de poursuites observant permanemment les satellites du GPS
pour assurer le contrôle et la modification, si besoin en est, de leurs
trajectoires. Ces stations dont la principale est située au Colorado aux EtatsUnis, assure également la transmission des informations de navigation aux
satellites qui se chargent de les diffusées pour le monde entier ;
 le secteur utilisateur : c’est l’ensemble des utilisateurs du système. Pour
utiliser le système il faut disposer d’un récepteur GPS. Pour les applications
civiles, l’accès est gratuit et anonyme et la précision est de l’ordre de 5
mètres. Aujourd’hui, il existe de nombreux modèles de récepteur et nous
avons choisi un pour notre solution qui est présenté ci-dessous.
Carte 2 : Trace des satellites du GPS en 24 heures [SER 2006]
28
II.1.2.
Le terminal
Dans le mode de fonctionnement du terminal il peut exister des
différences entre les solutions. En effet, on distingue trois types de terminaux
qui transmettent les données soit en temps réel automatiquement ou à la
demande soit en différé :
- les « data loggers » stockent en leur sein les données qui seront
transférées plus tard pour traitement ;
- les « data pullers » qui envoient à la demande, les données pour
traitement et ;
- les « data pushers » qui envoie automatiquement les données de
positionnement pour traitement à intervalle de temps régulier. Cet
intervalle de temps étant modifiable à volonté [WIK, 2].
Notre solution est basée sur les « data pushers » qui sont les plus utilisés
par les plateformes qui se veulent professionnelles. A terme, la plateforme
devra prendre en compte les terminaux (data pushers) de plusieurs
constructeurs mais pour cette première itération nous avons opté pour le
modèle GZ102 de GPS TRACKER qui nous vient de la chine. En général, les
« data pushers sont en même temps des data pullers » c’est le cas par
exemple pour celui que nous avons choisi.
Image 1 : GPS GZ102 (extrait du manuel d’utilisation)
29
C’est un data pusher qui est associé à un mobile et est configuré pour
envoyer automatiquement à la plateforme via un réseau GSM/GPRS8 [WIK, 3]
les informations de navigations dudit mobile selon une fréquence modifiable
à volonté. Il prend donc une carte SIM d’un opérateur de téléphonie mobile
de la place à travers le réseau duquel les données sont transmises à notre
plateforme en transitant par internet. Vu l’importance du flux que cette carte
SIM gèrera, Il est conseillé qu’elle soit de type data ce qui minimisera les coûts
d’exploitation. Le GPS GZ102 intègre également l’option « data puller ». Ainsi,
à travers un téléphone portable autorisé, sécurité oblige, les informations de
navigations peuvent être obtenues en composant le numéro de téléphone
associé au terminal. Le terminal reçoit également ses commandes de
configuration par SMS envoyés au numéro associé. Pour une description plus
détaillée de l’équipement, se référer à l’annexe 1.
Il s’agit de deux technologies complémentaires de téléphonie mobile. Le GSM (Global
System for Mobile Communication) est un réseau commuté plus adapté au transport de la
voix. Il a par la suite été étendu par la norme GPRS (General Packet Radio Service) offrant un
débit plus élevé et plus apte au transport de données. Le réseau GSM/GPRS est utilisable en
géolocalisation à deux niveaux : soit pour la détermination des informations de navigation
soit pour le transfert de ces mêmes informations du terminal à la plateforme. Dans une
solution, il est aussi possible de le trouver à tous les deux niveaux en même temps. Dans notre
cas, il intervient uniquement au niveau du transfert des données vers la vers la plateforme.
8
30
II.2 - Architecture logicielle
Les données de suivi à collecter et à traiter étant très sensibles, la
solution envisagée doit obéir aux règles suivantes :
- centraliser les données dans une base de données avec accès
individuel pour chaque utilisateur ;
- assurer une sécurité accrue et une disponibilité permanente des
données pour les utilisateurs ;
- assurer la fiabilité des traitements ;
- assurer l’intégrité des données : les données issues des terminaux ne
doivent en aucun cas être manipulées par les acteurs ;
- permettre une maintenance facile ;
- assurer la capacité à résister aux pannes ;
- permettre une évolution continue du système ;
- faciliter la gestion des utilisateurs et le paramétrage du système ;
- faciliter la gestion des terminaux en stocke ;
- permettre une faciliter d’exploitation ;
- traiter des volumes de données de plus en plus grands ;
- accéder de façon transparente à des données situées sur des serveurs
différents.
Ces règles orientent notre choix vers une architecture à plusieurs
niveaux encore appelée multi-tiers où chaque composante a une fonction
spécifique.
Ainsi nous aurons une architecture avec un serveur de base de
données, un serveur de cartographies et un serveur d’application/web soit 4tiers en considérant les postes clients intervenant dans le système.
NIVEAU 1
Requêtes
http, SQL,
openlaye
rs,wfs,...
NIVEAU 2
Envoie des
requêtes
NIVEAU 4
SQL/WFS
Réception des
réponses
Client
NIVEAU 3
openlayers
Serveur web
Données
Serveur
cartographique
Serveur de base
de données
Figure V. Schéma globale de l’architecture multi-tiers utilisée par notre système
En effet l’architecture 4-tiers de notre système offre :
- Une plus grande flexibilité du système ;
- Une plus grande sécurité des services ;
- Une meilleure performance par le partage des tâches côté serveurs.
31
FRONT OFFICE
- Navigateur
- HTTP
-etc.
Portable
Module web
(Ensemble applicatif des
pages web)
Module cartographique
(googlemaps)
Openlayers
Apache
Système de Gestion de
Base de données
(PostGreSQL/PostGIS)
WFS / SQL
Fichiers reçus
des terminaux
Script PHP
(pour le renseignement
de la base de données)
Serveur cartographique
Serveur web
Serveur de données
BACK OFFICE
Figure VI. Architecture logicielle du système
A travers cette architecture, il ressort clairement les différents éléments
logiciels auxquels nous faisons recours pour la réalisation de notre solution.
Elle met en exergue les échanges entre ces éléments du système. Nous y
voyons notamment que les utilisateurs accèdent au système en passant par
les pages web se trouvant sur le serveur web qui à son tour est chargé à
travers son composant essentiel (apache) de mettre à disposition les autres
ressources que sont le module cartographique et les données. C’est la
combinaison judicieuse des données et de la carte à l’aide notamment des
technologies « OPENLAYERS9 » et « WFS » qui est renvoyée aux utilisateurs.
L’ensemble serveur cartographique, serveur web et serveur de base de
données constitue le « back office » car fonctionnant en arrière plan et de
façon transparente aux utilisateurs se trouvant en avant-poste ou « front
office » avec les outils clients pour l’accès au système.
C’est une bibliothèque (libre) de fonctions JavaScript constituant un ensemble de
fonctionnalités de base pour la mise en place d'applications clientes Web de
cartographique.
9
32
II.3 - Les outils de développement
II.3.1 -
Choix du langage de programmation
La technique de géolocalisation nous impose un certain nombre de
contraintes au niveau du choix du langage de programmation.
Pour ce faire, en fonctions de nos objectifs il nous faut trouver un langage
respectant les spécifications suivantes :
- Assurer une bonne productivité : il faut des outils permettant de gérer la
connexion à une base de données géographique. Il faut également
que ce langage permette d’envoyer des requêtes vers un serveur
cartographiques ;
- Garantir la faisabilité : existe-t-il dans ce langage des ressources pour
satisfaire aux spécifications fonctionnelles de l’application ? existe-t-il
dans ce langage des ressources pour le déploiement et le
fonctionnement du système dans son ensemble ?
- Assurer la fiabilité de l’application : existe-t-il dans ce langage des
Framework de test, des Framework de login, des véritables outils de
débogage ?
- Possibilité de maintenance, extensibilité, flexibilité : le langage doit être
orienté objet ;
- Possibilité de management : il faut qu’il existe au moins un IDE qui
intègre et complète ce langage et les principaux outils et Framework
évoqués ci-dessus pour l’orchestration de toutes ces ressources ;
- Garantir la performance de l’application : existe-t-il dans ce langage
des outils permettant d’effectuer une bonne performance dans
l’exécution et même à distance ?
- Portabilité du langage ;
- Assurer la production d’une produit ergonomique ;
Le langage PHP intégrant JavaScript à travers « OPENLAYERS » et « WFS » obéit
à toutes ces spécifications et répond de façon efficace à toutes les questions
posées. Pour toutes ces raisons, notre choix s’est objectivement porté sur
cette combinaison de langage. L’avantage déterminant de cette
combinaison PHP et JavaScript est qu’elle offre une meilleure adéquation
assez fiable des solutions modélisées et réalisées avec les besoins exprimés
par le client.
II.3.2 -
Choix du Système de Gestion de Base de Données (SGBD)
Le choix du Système de Gestion de Base de Données (SGBD) obéit aux
spécifications suivantes :
- Capacité du système à gérer des données géographiques ;
- Possibilité d’offrir un service d’accès au web ;
- Possibilité de manipuler une grande quantité de données : le système
gère l’espace mémoire secondaire en utilisant des techniques de
33
regroupement physique, d’indexation, d’optimisation de requêtes et
de gestion de cache ;
- Garantie d’une fiabilité des données : le système assure la cohérence
des données par la gestion des contraintes d’intégrité et la sécurité des
accès par l’affectation des privilèges adéquats ;
- Possibilité de partage des données : le système est multiutilisateur et
gère des mécanismes de verrous pour contrôler les accès concurrents ;
- Facilité d’interrogation : le système permet à l’utilisateur d’interroger la
base de données à l’aide du langage de requêtes SQL que nous
maîtrisons le mieux ;
- L’intégration
d’un
langage
complétant
des
fonctionnalités
d’interrogation de données spatiales par des fonctionnalités de
présentation géographique des résultats [EGE 90].
Il existe plusieurs SGBD qui satisfont à ces exigences notamment Oracle
Spatial et PostgreSQL/PostGIS. Nous avons opté pour PostgreSQL/PostGIS car
c’est un SGBD libre et gratuit contrairement à Oracle, du reste très cher. Ici,
notre choix est simplement guidé par des préoccupations financières.
En sommes, les choix technologiques opérés qui donnent déjà une
orientation stratégique à la mise en place du système futur se résument au
tableau suivant :
Outils
Type de solution
Terminal
Technologie de transmission des
données
Architecture
Langage
SGBD
Serveur web
Autres technologies
Choix
Plateforme de géolocalisation par GPS
GPS GZ102
GSM/GPRS
Client serveurs (4-tiers)
PHP - JavaScript
PostgreSQL/PostGIS
Apache
OPENLAYERS, WFS
Tableau III : récapitulatif des choix technologiques
34
III. - Conception détaillée
Le travail consistera à décrire les différentes représentations
fonctionnelles que nous nous faisons du système futur tant au niveau des
données qu’à celui des traitements. Les représentations seront faites à l’aide
du langage UML présenté plus. Nous présenterons successivement le
diagramme des cas d’utilisation puis celui des classes, comme cela est
généralement recommandé.
III.1 - Diagramme de cas d’utilisation
Les acteurs du système sont :
- Les souscripteurs
- L’administrateur
- Les utilisateurs
- Les terminaux
Ils sont décrits dans les lignes qui suivent.
III.2.1
Diagramme de cas d’utilisation du package Administration
 Description des acteurs du package
Les souscripteurs : Un Souscripteur est un client disposant d’une ou plusieurs
flottes de mobiles et qui souscrit à un ou plusieurs des services offerts par la
plateforme pour la gestion spatiale et la maintenance de sa flotte. Ce sont
ces Souscripteurs qui sont facturés par l’administrateur. Il est de la
responsabilité de l’administrateur de la plateforme de collecter des
informations et faire la facturation des souscripteurs. Cependant ce volet est
hors du périmètre de la présente étude. Comme exemple de Souscripteur,
nous pouvons citer :
une compagnie de transport ;
une agence de location de véhicules ;
un particulier (pour la surveillance des membres de la famille, des
voitures…) ;
l’Etat (pour son parc automobile) ;
une grande entreprise ;
l’armée ou la police ;
une brigade de sapeurs pompiers.
L’acteur sera noté Client sur le diagramme.
L'acteur Souscripteur, dans cette première itération et dans le package
Administration, réalise les cas d'utilisation suivants :
- Inscrire un Souscripteur (en partie) ;
- Modifier un compte Souscripteur (les informations sur son compte) ;
- Souscrire à un service pour Souscripteur ;
- Consulter les souscriptions de services ;
- Modifier une souscription de service Souscripteur ;
- Consulter les statistiques Souscripteur ;
35
L’administrateur : Il s’agit de l'opérateur de la plateforme, chargé
d’administrer et de surveiller les conditions d’utilisation des services. Il effectue
toutes les actions nécessaires pour maintenir la plateforme en condition
opérationnelle. Cet acteur est impliqué dans les cas d'utilisation suivant :
- Initialiser la plateforme ;
- Paramétrer un service ;
- Paramétrer un mobile ;
- Inscrire un Souscripteur (en partie) par la validation de son inscription ;
- Suspendre un compte Souscripteur ;
- Désactiver un service ;
- Activer un service ;
- Ouvrir un compte Administrateur ;
- Résilier une souscription ;
- Consulter les statistiques.
 Liste des cas d’utilisation
Pour cette première itération, nous nous limiterons aux cas cités cidessus dans la présentation des acteurs. Les deux acteurs cités ci-dessus sont
les seuls qui interviennent dans l’administration du système.
36
Le diagramme de cas d’utilisation pour le package Administration se
présente donc comme suit :
Administration
consulter les statistiques sur un compte
ouvrir compte client
initialiser la plateforme
primaire
parametrer un service
sécondaire
Modifier un compte client
fermer un compte
Client
sécondaire
primaire
Administrateur
souscrire à un service
parametrer un terminal
consulter la liste des services
suspendre un compte
resilier une souscription à un service
désactiver un service
Modifier une souscription
ouvrir un compte administrateur
Figure VII : Diagramme de cas d’utilisation du package Administration
37
III.2.2
Diagramme de cas d’utilisation des packages gestion spatiale et
maintenance des mobiles
 Description des acteurs du package
Les utilisateurs : les utilisateurs sont les personnes agissant pour le compte des
souscripteurs. Ils sont chargés de l’exploitation des services au compte des
clients (souscripteurs) ;
Les terminaux : ce sont les équipements électroniques fixés sur les mobiles qui
sont suivis. Ils sont chargés dans notre système d’une part, de la détermination
des informations de navigations à l’aide du système GPS et d’autres
informations liées aux déplacements du mobile et d’autre part de l’envoi
automatique à la plateforme de ces données recueillies sur le terrain
nécessaires pour le fonctionnement du système.
 Liste des cas d’utilisation de cet ensemble pour la première itération est
comme suit :
-
Enregistrer un élément (mobile, flotte…) ;
Mettre à jour un acteur (modification, suppression) ;
Suivre les déplacements d’un élément (mobile, flotte) ;
Consulter l’historique des activités d’un élément (mobile, flotte) ;
Transmettre les données ;
Générer un rapport ;
Créer un point ou une zone d’intérêt ;
Localiser les mobiles les plus proches d’un point ;
Calculer un itinéraire ;
Forcer l’arrêt d’un mobile véhicule ;
Configurer une alerte ;
Alerter.
38
Le diagramme se présente donc comme suit :
Gestion spatiale et maintenance
Créer d’un point d’intérêt
Mettre à jour une flotte
Enregistrer un mobile
Mise à jour d’un mobile
Enregistrer une flotte
Consulter historique d’une flotte
Consulter l’historique d’un mobile
Utilisateur
Suivre un mobile
Transmettre les données
Terminal
Suivre une flotte
Générer un rapport
dépend
Calculer un itinéraire
Localiser des mobiles les plus proches d’un point
Forcer l’arrêt d’un mobile véhicule
Configurer une alerte
Créer une zone d’intérêt
A
B = A inclu B
Figure VIII : Diagramme de cas d’utilisation du package Administration
39
III.2 - Diagramme de classes
Les classes identifiées pour notre application sont décrites dans le diagramme
de classes qui suit :
TypeEvenement
Evenement
0..*
- CodeTypeEven : int
- LibTypeEven
: String
TypeClient
1..1
-
a3
- codetype
: int
- libellé type : String
- Code Terminal : int
- NumIMEI
: int
- Nom Terminal : String
1..1
a4
int
String
int
Date
0..*
concerne
1..1
0..*
associe
1..1
0..1
Client
CodeClient
NomClient
Prénom Client
Raison sociale
Email client
TéléphoneClient
:
:
:
:
+ Alerter () : int
Termina l
-
CodeEven
LibEven
Condition
Echéance
:
:
:
:
:
:
int
String
String
String
String
int
Mobile
Flotte
1..1
détient
1..*
- CodeMobile
: int
- TypeMobile
: String
- Immatriculation : String
1..*
comporte
- CodeFlotte : int
- Motif
: String
1..1
+ Nombre de mobile () : int
+ Distance parcourue () : int
+ Donner position ()
: int
+ Donner historique () : int
+ CreerFlotte ()
: int
+ Abonner Service () : int
0..*
1..1
emploie
1..1
a2
1..*
possède
1..*
1..1
TypeUtilisateur
Utilisateur
-
Code Utilisateur
Nom Utilisateur
Prenom Utilisateur
TéléphoneUtil
Login
Mot de passe
Email
:
:
:
:
:
:
:
int
String
String
int
String
String
String
+
+
+
+
+
Se connecter ()
Se déconnecter ()
AdministrerSys ()
UtiliserSys ()
Offir Service ()
:
:
:
:
:
int
int
int
int
int
a1
0..*
1..1 - CodeTypeUtil
: int
- LibélleTypeUtil : int
TypeMobile
- codeTypeMob
: int
- libelléTypeMob : int
Positions
-
Code Position
Date position
Coordonnées position
Vitesse position
:
:
:
:
int
Date
int
Number
+ Donner les statistiques () : int
Figure IX : Diagramme de classes de notre solution
Ainsi, prend fin la phase de la conception détaillée qui pourrait se
prolonger si d’autres diagrammes avaient été pris compte. Néanmoins ce qui
est fait nous permet déjà de passer à la réalisation d’une première version de
notre solution et penser en même temps aux mesures de sécurité qui pourront
être prises pour pérenniser le futur système.
40
IV. -POLITIQUE DE SECURITE
V.1 - Procédures transitoires
La phase transitoire correspond au passage du système actuel au
système futur. C’est la phase pendant laquelle le système devra être soumis
à une série de tests afin de s’assurer que le système répond aux attentes des
utilisateurs. Ces tests permettront de déceler des défaillances dans certains
modules qui feront l’objet de correction afin d’aboutir à une application
fiable.
Pour cette phase, nous préconisons le fonctionnement en parallèle des
deux systèmes c'est-à-dire l’actuel et le futur, la solution que nous
développons. Ainsi, les mobiles à gérer par l’entreprise responsable du
système futur (le commanditaire) seront repartis en deux groupes dont un
premier est suivi par la plateforme chinoise et l’autre par notre solution. En cas
de problème majeur entrainant un blocage de notre solution, la gestion des
mobiles du second groupe devra systématiquement être confiée à la
plateforme chinoise en attendant de lever le blocage. Et ainsi, il faudra
procéder jusqu’à la stabilisation de notre solution.
Le fonctionnement en parallèle des deux (2) systèmes a pour but :
 d’éviter un brusque arrêt des services offerts par le responsable
ou propriétaire de la plateforme;
 De permettre la prise en charge progressive par la nouvelle
plateforme de l’ensemble des mobiles à gérer ;
 De vérifier la fiabilité et la robustesse de la nouvelle solution.
V.2 - Procédures de secours
Ce sont les procédures à appliquer en cas de défaillance du système.
Plusieurs cas de figures peuvent se présenter. Notre système étant reparti sur
internet, il faut s’attendre à ce que le client et le serveur ne soient pas sur le
même site. Nous allons énumérer ci-dessous quelques procédures standards
et applicables à tout système informatique fonctionnant en réseau et sur du
courant ondulé :
 En cas de panne électrique du côté du client, il faudrait que les
différents postes de travail enregistrent l’ensemble des traitements en cours
pendant la période d’autonomie de l’onduleur ; faute de quoi les données
en cours seront perdues. Ce risque est quasi nul du côté serveur qui est chez
un hébergeur sûr où la politique de sécurité est telle que la disponibilité du
système garantie à pratiquement 100% ;
 En cas de panne prolongée de serveur, de disposition seront pour
permettre le basculement de tout le système vers un autre serveur sur un site
miroir ;
 Les données continueront être enregistrées sur ce serveur
d’échange et sauvegardées en entendant le dépannage du serveur
titulaire ;
41
 Après le dépannage du serveur et avant son utilisation, une mise
à jour de la base de données se fera grâce aux sauvegardes réalisées durant
la période d’indisponibilité de celui-ci ;
 En cas de panne d’un poste de travail chez un client, l’utilisateur
de ce poste pourra grâce au fait que la disponibilité du système est
indépendante des postes clients, utiliser les postes de ses collègues pour
effectuer ses opérations. Et cela jusqu’à la remise en service de son poste.
Conclusion partielle
Cette partie nous a permis de décrire un peu plus en détail notre
solution à travers les différents choix stratégiques technologiques et surtout les
diagrammes de cas d’utilisation et de classes. Nous nous attèlerons déjà à la
production des programmes sources de la première itération de façon à
donner définitivement vie notre solution qui est la mise en place d’une
plateforme de géolocalisation propre à nous.
42
CONCLUSION GENERALE
Somme toute, ce mémoire a permis de poser les premiers jalons d’une
solution de géolocalisation propre au Burkina sinon à toute l’Afrique. En effet,
dans nos investigations dans le cadre de ce stage toutes les solutions que
nous avons pu rencontrer sont toutes d’origine les pays d’Amérique, d’Europe
ou d’Asie et qui sont proposées sur notre continent.
A ce niveau, les objectifs assignés à notre stage sont globalement
atteints. En rappel, les objectifs étaient les suivants :
 Un dossier de conception de la solution décrite ci-dessus ;
 Les scripts de création de la base de données nécessaire à la mise en
place de la solution ;
 Une version exploitable de la solution ;
 Les programmes sources de cette version.
Ce présent mémoire constitue le dossier de conception, la base de
données est créée. La version exploitable qui est cours d’élaboration ne
tardera pas à finir et les codes sources seront disponibles. Déjà une partie des
codes sources existe il reste donc à les compléter.
Le mémoire ainsi produit servira à n’en pas douter, de point de départ
d’une étude technique plus affinée qui constitue l’étape suivante de notre
solution que nous tenons impérativement à mettre en place. Cette étape
s’intéressera particulièrement aux aspects techniques les plus pointus de la
solution proposée notamment des diagrammes de vue dynamiques pour
montrer le déroulement complet des cas d’utilisation et la définition précise
de la procédure d’alimentation de la base de données par les terminaux. Ce
travail complémentaire permettra de faciliter la réalisation et la mise en
œuvre de la future application devant répondre à toutes nos attentes.
43
BIBLIOGRAPHIE
[MIC 2002] Michel MAINGUENAUD, Langages pour les SIG : Conception,
développement et IHM, p. 53, 2002 ;
[TAM, 2011] Bertrand TAMOKWE, Eléments de cours de Management, p. 10,
2010-2011 ;
[BUS, 2001] Business Interactif, Extreme Programming - Méthodes agiles, p. 29,
2001;
[EGE 90] EGENHOFER M., Interaction with GISs via spatial queries: Visual
Languages and Computing, 1990;
[KEN 2001] Kent BECK, eXtrême Programming, La référence : une nouvelle
vision des projets de développement professionnels, 2001 ;
[VER 2009] Véronique Messager ROTA, Gestion de projet Ŕ Vers les méthodes
agiles, 2009 ;
[SER 2006] Serge BOTTON, GEODESIE Ŕ Présentation Générale du système GPS,
p. 11 à 17, 2006.
44
WEBOGRAPHIE
[WIK, 1] wikipédia, http://fr.wikipedia.org/wiki/G%C3%A9olocalisation, juin 2011
[WIK 2] wikipédia, http://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9phonie_mobile, juin
2011;
[WIK 3] wikipédia
http://fr.wikipedia.org/wiki/General_Packet_Radio_Service juillet 2011,
http://fr.wikipedia.org/wiki/Global_System_for_Mobile_Communications juillet 2011;
[CIA 2011] https://www.cia.gov/library/publications/the-world-factbook/geos/uv.html,
novembre 2011 ;
[USN 2011] United States National Observatory,
http://tycho.usno.navy.mil/gpscurr.html, 10 novembre 2011;
http://www.gpsdw.net/EN/Default.aspx , plateforme chinoise, depuis août 2011
http://www.tramigo.net/, site de TRAMIGO cité en exemple plus haut juin 2011
45
LISTE DES FIGURES :
Figure I. Cycle de vie d’un projet XP [BUS, 2001] ....................................................... 11
Figure II : illustration d’un digramme de cas d’utilisation ........................................ 13
Figure III : Illustration d’un diagramme de classes .................................................... 14
Figure IV: architecture matérielle de la solution ........................................................ 25
Figure V. Schéma globale de l’architecture multi-tiers utilisée par notre système ...... 31
Figure VI. Architecture logicielle du système ............................................................... 32
Figure VII : Diagramme de cas d’utilisation du package Administration .......... 37
Figure VIII : Diagramme de cas d’utilisation du package Administration ......... 39
Figure IX : Diagramme de classes de notre solution ................................................ 40
LISTE DES TABLEAUX :
Tableau I : Planning prévisionnel de déroulement du stage ................................. 16
Tableau II : récapitulatif des choix technologiques ................................................. 34
Tableau III : liste des diagrammes du langage UML ................................................ 12
LISTE DES CARTES
Carte 1: Le Burkina Faso sur une carte du monde ...................................................... 3
Carte 2 : Trace des satellites du GPS en 24 heures [SER 2006] ............................... 28
46
TABLE DES MATIERES
DEDICACE.................................................................................................................................... I
REMERCIEMENTS ......................................................................................................................... II
RESUME ..................................................................................................................................... III
ABSTRACT .................................................................................................................................. IV
ACRONYME /ABREVIATIONS ..................................................................................................... V
SOMMAIRE ................................................................................................................................. VI
INTRODUCTION GENERALE .......................................................................................................... I
PREMIERE PARTIE : PRESENTATION DU THEME ............................................................................ 2
I - CONTEXTE ET JUSTIFICATION .................................................................................................................. 3
I.1
Contexte ........................................................................................................................... 3
I.2
Justification....................................................................................................................... 5
II III -
PROBLEMATIQUE ............................................................................................................................. 7
OBJECTIFS DU STAGE ...................................................................................................................... 8
III.1 -
Objectifs du systeme futur .......................................................................................... 8
III.2 -
Resultats attendus ....................................................................................................... 8
IV IV.1 -
ORGANISATION DU TRAVAIL ......................................................................................................... 9
Méthodologie .............................................................................................................. 9
IV 1.1 - Vers une méthode agile ............................................................................................. 9
IV 1.2 - Parlons UML ................................................................................................................ 12
IV 1.2.1. Le Diagramme de cas d’utilisation .......................................................................... 13
IV 1.2.2 Le diagramme de classes .......................................................................................... 13
IV 1.3 - Organisation des acteurs du projet ......................................................................... 15
IV.2 -
Planning prévisionnel ................................................................................................ 16
IV.3 -
Recherches documentaires ..................................................................................... 17
DEUXIEME PARTIE : CONCEPTION DE LA SOLUTION ................................................................ 19
I. -
SPECIFICATION DES BESOINS (CAHIER DES CHARGES) ............................................ 20
I.1 -
L’administration du système ........................................................................................ 22
I.2 -
La gestion spatiale ........................................................................................................ 23
I.3 -
La maintenance des mobiles ...................................................................................... 24
II. -
CHOIX TECHNOLOGIQUES ......................................................................................... 25
II.1 -
Principe de géolocalisation : choix matériels ........................................................... 25
II.1.1.
Le système GPS .............................................................................................................. 28
II.1.2.
Le terminal ...................................................................................................................... 29
II.2 -
Architecture logicielle .................................................................................................. 31
II.3 -
Les outils de développement ...................................................................................... 33
II.3.1 -
Choix du langage de programmation ....................................................................... 33
47
II.3.2 -
Choix du Système de Gestion de Base de Données (SGBD) .................................. 33
III. -
CONCEPTION DETAILLEE ............................................................................................ 35
III.1 -
Diagramme de cas d’utilisation .................................................................................. 35
III.2.1
Diagramme de cas d’utilisation du package Administration ................................. 35
III.2.2
Diagramme de cas d’utilisation des packages gestion spatiale et maintenance
des mobiles .............................................................................................................................. 38
III.2 -
Diagramme de classes ................................................................................................. 40
IV. -
Politique de sécurite ..................................................................................................... 41
V.1 -
Procédures transitoires .................................................................................................. 41
V.2 -
Procédures de secours ................................................................................................. 41
CONCLUSION GENERALE ......................................................................................................... 43
BIBLIOGRAPHIE ......................................................................................................................... 44
WEBOGRAPHIE.......................................................................................................................... 45
LISTE DES FIGURES : ................................................................................................................... 46
LISTE DES TABLEAUX : ................................................................................................................ 46
LISTE DES CARTES ...................................................................................................................... 46
TABLE DES MATIERES ................................................................................................................. 47
ANNEXES .................................................................................................................................. 49
48
ANNEXES
49
Annexe 1 : description du terminal
Les spécifications techniques
Une vue des commandes prises en compte
50
Annexe 2 : script de création de la base de données
51