La géolocalisation dans un système de gestion de flotte

Télécharger le fichier original (Mémoire de fin d’études)

ANALYSE ET SPECIFICATION DES BESOINS

Introduction

La réussite de toute étude dépend de la qualité dela phase de démarrage. De ce fait, l’étape d’analyse des besoins constitue la base de départ de notre travail, de plus qu’elle est une étape déterminante pour la suite. En outre, l’adéquationde toute application à réaliser, aux besoins des utilisateurs et aux traitements envisagés au niveau de ses opérations assurera la réussite de l’application et sa future utilité. Pour assurer ces objectifs, il est essentiel que nous parvenions à une vue claire des différents besoins escomptés denotre projet. Il faut déterminer au moindre détail les fonctionnalités attendues. Nous présentons dans la première section de ce chapitre l’ensemble des besoins fonctionnels et non fonctionnels que notre application doit fournir. La deuxième section portera sur les différents cas d’utilisation dans notre système.

Spécification des besoins

Pour la modélisation des besoins nous avons choisile formalisme UML (Unified Modeling Language). En fait, nous avons eu l’occasion, pour mener à bien ce travail, d’utiliser les concepts du langage UML qui fournissent les fondements pour spécifier, construire, visualiser et décrire les artefacts d’un logiciel. En fait, UML se base sur une sémantique précise et sur une notation graphique expressive. Il définit des concepts de base et offre également des mécanismes d’extension de ces concepts [20].

Besoins fonctionnels

Nous allons décrire, dans cette partie, les besoins fonctionnels aux quels devrait répondre notre outil logiciel :
Suivi de véhicule en temps réel :
– Visualiser les positions instantanées des véhiculeset des conducteurs sur une carte géographique.
– Afficher l’état du moteur, le niveau du carburant et la vitesse pour chaque véhicule.
Gestion des alertes et des urgences:
L’application doit informer l’utilisateur lors de al détection d’une anomalie dans l’utilisation d’un véhicule en générant une alerte. Les anomaliespeuvent être:
– La déviation d’un véhicule de sa trajectoire.
– La sortie d’une zone géographique donnée (geofencing).
– Un dépassement des seuils de la vitesse.
– Un accident
– Une panne
En cas d’accident, le système vérifie l’état du moteur et de l’airbag du véhicule afin d’évaluer la sévérité de l’accident puis il avertit automatiquement le service d’urgence le plus proche en envoyantautomatiquement un message (SMS) à ce derni er suivi d’un appel de confirmation de l’accident. Ce SMS comporte les informations essentielles permettant de traiter l’urgence :
– type et numéro de série du véhicule par lequel on connaît le type et les caractéristiques du véhicule ainsi que lenom du propriétaire
– numéro de téléphone GSM
– coordonnées GPS du véhicule
– mode de déclenchement, manuel ou automatique (airbag, prétensionneurs de ceintures de sécurité, …)
Historique du parcours :
– Donner le choix de la période du parcours.
– Afficher la liste des trajets parcourus pour chaque véhicule.
– Calculer le nombre de kilomètres parcourus, et le temps de conduite pour chaque trajet
Simulation de trajet :
– Affichage d’une animation graphique sur la carte indiquant le parcours réalisé par un véhicule.
– Option d’animation: marche, pause, stop, ralentir, accélérer.
Gestion des données :
– Gérer la liste des véhicules: ajouter une nouvellevoiture à la troupe de véhicules ou supprimer une voiture si elle n’en fait plus partie, les véhicules sont organisés par groupes.
– Gérer la liste des conducteurs: ajouter, supprimer ou modifier les paramètres d’un conducteur de la liste.
– Définitions des points d’intérêt : l’applicationrmetpe une saisie simple des points d’intérêt. On s’intéresse pour chaque pointà savoir sa position géographique ainsi qu’un ensemble de données attributaires: Le nom, l’adresse, description…
Un point d’intérêt ou POI (Point Of Interest), désigne un endroit ou une destination potentiellement intéressante. Ce terme est utilisépar différents logiciels de navigation et appareils GPS. Les points d’intérêt sont types station, parking, dépôt, etc.,
Gestion des comptes utilisateurs et des privilèges :
– Consiste à créer, modifier, supprimer ou à afficher les comptes utilisateurs ayant accès à l’application.
– Un compte utilisateur est défini par un login et un mot de passe, ainsi l’administrateur peut définir les comptes utilisateurs tout en précisant les privilèges associés.
– L’application contient un système de gestion des rôles et des permissions.
Génération de rapports statistiques:
– L’application permettra de générer des rapports d’activité imprimables et qui sont également disponibles sous format Texte,PDF, Excel.
– Afficher dans une charte les courbes de vitesse, la consommation de carburant…
Gestion de trafic routier :
Le système doit permettre à l’utilisateur :
– d’évaluer les risques de bouchon sur une route donnée à un moment donnée
– de trouver le chemin le plus rapide pour se rendre à une destination donnée

Besoins non fonctionnels

Contrainte ergonomique
L’application doit présenter des informations extraites de la base de données dans une interface conviviale et ergonomique pour faciliter l’utilisation de l’application par un utilisateur, qu’il soit spécialiste ou non, Cet interface doit également assurer la maintenabilité et la réutilisabilité de notre application.
Contrainte sur la fiabilité de l’application
Le serveur d’applications doit être capable de gérer un grand nombre d’accès et de requêtes simultanées. D’autre part, en matière deitessev ou de temps de réponse, l’accès des utilisateurs à leurs tableaux de bords doit être fourni au bout d’un temps réduit, ce qui met au point la nécessite d’un SGBD relationnelqui peut prendre en charge un taux élevé de requêtes.
Contrainte d’évolution
L’application doit permettre une maintenance facile et doit être évolutive.

Description générale du fonctionnement du système

L’architecture générale du système à développer estdécrite par la figure 2 .01:
Figure 2.01: Architecture générale de l’application
L’équipement GPS permet au récepteur de définir précisément sa localisation, puis il envoie ces coordonnées via GPRS/EDGE vers le serveur en utilisant le protocole HTTP. Après réception et enregistrement des données GPS chez le serveur, l’application récupère ces informations à travers un socket java qui permet d’insérer les données duserveur dans la base de données de l’application.

Diagramme de cas d’utilisation

Les diagrammes de cas d’utilisation représentent les cas d’utilisation, les acteurs et les relations entre les cas d’utilisation et les acteurs. Les cas d’utilisation permettent de structurer et d’articuler les besoins en fonctionnalités et de définir la manière dont les utilisateurs voudraient interagir avec le système.
L’analyse débute par la recherche des acteurs (catégories d’utilisation) du système de contrôle de flotte. Un acteur représente un rôle joué par une personne ou par une chose qui interagit avec le système.

Identification des acteurs

Les acteurs se recrutent parmi les utilisateurs du système et aussi parmi les responsables de sa configuration et sa maintenance. Ils se répartissen dans les catégories suivantes :
L’administrateur du système
Le système doit permettre à l’administrateur de :
– Gérer les comptes utilisateurs.
– Attribuer des privilèges.
– Gérer les groupes.
– Gérer les géo zones.
– Paramétrer le système (Profil, connectivités, seuilde vitesse).
– Générer des rapports des équipements (rapports détaillés, rapports de performance).
– Localiser un véhicule en temps réel
– Appeler les secours ou les dépanneurs en cas de pannes ou d’accident.
L’utilisateur du système
Le système doit permettre à l’exploitant de :
– Visualiser les véhicules sur la carte.
– Consulter l’historique des trajets parcourus avec simulation de trajet.
– Générer des rapports imprimables détaillant l’historique des véhicules.
– Consulter des graphes statistiques.
– Gérer les chauffeurs.
– Gérer les véhicules.
– Gérer les points d’intérêt
Les acteurs interagissent avec le système. L’étude des cas d’utilisation a pour objectif de déterminer ce que chaque acteur attend du système. La détermination des besoins est basée sur la représentation de l’interaction entre l’acteur et el système. Cette approche présente l’avantage de forcer l’utilisateur à définir précisément ce qu’il attend du système.

Cas d’utilisation général

Après avoir identifié les cas d’utilisation et leurs acteurs, nous allons les représenter graphiquement sur un diagramme de cas d’utilisation général (figure 2.02) Dans ce diagramme on utilise les notions suivantes :
Si le rôle d’un acteur n’est pas principal, nous de vons le mentionner explicitement en écrivant « secondaire » ;
Les ellipses correspondent à des cas d’utilisation ;
Les flèches indiquent l’association entre l’acteur et le cas d’utilisation qui est généralement une consommation d’information du système ;
La relation « Extend » entre cas d’utilisation : elle est utilisée lorsqu’un cas d’utilisation peut fonctionner tout seul, mais peut également être complété par un autre ;
La relation « Include » entre cas d’utilisation : le cas d’utilisation inclus n’est jamais exécutée seule, mais seulement en tant que partie d’un cas de base plus vaste.
La figure 2.02 représente le diagramme de cas d’utilisation général.

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1 : LA GEOLOCALISATION
1.1 Introduction
1.2 Définition
1.3 Problématique et contexte du travail
1.4 Généralités sur la localisation
1.4.1 Historique et évolution des besoins de localisation
1.4.2 Les moyens de localisation actuels
1.4.2.1 Les communications par satellite
1.4.2.2 Réseau de téléphone cellulaire
1.4.2.3 Réseau Wi-Fi
1.4.3 Principe de la géolocalisation
1.4.4 Les outils et les techniques de géolocalisation
1.4.4.1 Boitier de géolocalisation
1.4.4.2 Système GPS
1.4.4.3 Service GPRS
1.4.4.4 Les fournisseurs de cartes de géolocalisation
1.4.5 Avantages de la géolocalisation
1.4.6 La géolocalisation dans un système de gestion de flotte
1.4.7 La géolocalisation appliquée à la gestion des secours
1.4.8 La géolocalisation dans un système de gestion du trafic routier
1.5 Etude des systèmes existants
1.5.1 Critique des systèmes existants
1.5.2 Description de la solution proposée
1.6 Conclusion
CHAPITRE 2 : ANALYSE ET SPECIFICATION DES BESOINS
2.1 Introduction
2.2 Spécification des besoins
2.2.1 Besoins fonctionnels
2.2.2 Besoins non fonctionnels
2.3 Description générale du fonctionnement du système
2.4 Diagramme de cas d’utilisation
2.4.1 Identification des acteurs
2.4.2 Cas d’utilisation général
2.4.3 Cas d’utilisation « Gérer les comptes utilisateurs »
2.4.4 Cas d’utilisation« Gérer les groupes des véhicules »
2.4.5 Cas d’utilisation« Gestion des véhicules »
2.4.6 Cas d’utilisation« Gestion des chauffeurs »
2.4.7 Cas d’utilisation« Gestion des points d’intérêts»
2.4.8 Cas d’utilisation« Visualiser et suivre les véhicules»
2.4.9 Cas d’utilisation« Simulation des trajets»
2.4.10 Cas d’utilisation« Gérer les géo zones»
2.4.11 Cas d’utilisation« Gestion des rapports»
2.5 Conclusion
CHAPITRE 3 : CONCEPTION
3.1 Introduction
3.2 Diagrammes de Séquence système
3.2.1 Diagramme de séquence «S’authentifier»
3.2.2 Diagramme de séquence « Gestion des comptes utilisateurs »
3.2.3 Diagramme de séquence « Gestion des groupes »
3.2.4 Diagramme de séquence « Gestion des véhicules »
3.2.5 Diagramme de séquence « Gestion des chauffeurs»
3.2.6 Diagramme de séquence « Suivi des véhicules en temps réel»
3.2.7 Diagramme de séquence « consulter l’historique des trajets et simulation des parcours»
3.2.8 Diagramme de séquence « Gestion des géo-zones »
3.2.9 Diagramme de séquence « Génération des rapports»
3.2.10 Diagramme de séquence « Analyser les coordonnées GPS»
3.2.11 Tableau récapitulatif
3.3 Diagramme de classes
3.4 Diagramme d’état Transition
3.5 Diagrammes de collaboration
3.6 Conclusion
CHAPITRE 4 : REALISATION
4.1 Introduction
4.2 Présentation du système
4.3 Fonctionnalités de l’application Vehicle Tracking System
4.4 Plateformes supportées
4.5 Architecture de l’application « Vehicle Tracking System »
4.6 Environnement du travail
4.6.1 Environnement logiciel
4.6.2 Environnement de développement
4.6.2.1 La plateforme J2EE
4.6.2.2 Le Framework MVC
Généralités
Architecture
4.7 Travail réalisé
4.7.1 La page d’authentification
4.7.2 La page d’accueil
4.7.3 Module: Suivi en temps réel
4.7.4 Module: Historique
4.7.5 Module: Gestion des données
4.8 Conclusion
CONCLUSION GENERALE ET PERSPECTIVES
ANNEXES
ANNEXE I : LA TECHNOLOGIE GPS
ANNEXE II : LE SERVICE GPRS
ANNEXE III : LA TRAME MEITRACK
BIBLIOGRAPHIE
FICHE DE RENSEIGNEMENTS
RESUME
ABSTRACT