webmapping, gestion de la flotte
Transcription
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