Memoire version finale kenfack

INFORMATIQUE ET TELECOMMUNICATIONS
CONCEPTION ET REALISATION D’UNE
APPLICATION CLIENTE DE GTS ENTERPRISE
SUR ANDROID
Mémoire présenté et soutenu en vue de l’obtention du Diplôme d’INGENIEUR DE
TRAVAUX EN INFORMATIQUE DE GESTION / ANALYSTE PROGRAMMEUR
par
KENFACK DJEUFACK VALMY-ROI
Matricule : 11V434S
sous la direction de
M. DOUWE HALLAM VINCENT
Assistant
devant le jury composé de :
Président : Dr. KOSMA PHILIPPE
Rapporteur : M. DOUWE HALLAM VINCENT
Examinateur : M. WANSOUWE WANBITCHING
Invité : M. SERGE TAMPOLLA
Année Académique 2013 / 2014
Université de Maroua
****
Institut Supérieur du Sahel
****
Département d’Informatique et
des Télécommunications
****
The University of Maroua
****
The Higher Institute of the Sahel
****
Department of Computer Science
and Telecommunications
****

II
REMERCIEMENTS
Au terme de ce travail, nous tenons à remercier très sincèrement
 Le Dr. KOSMA PHILIPPE pour avoir accepté de présider le jury
 M. WANSOUWE WANBITCHING pour les corrections apportées à ce travail ;
 M. DOUWE HALLAM VINCENT pour sa disponibilité, son encadrement et les
multiples corrections apportées à ce travail ;
 M. SERGE TAMPOLLA pour avoir accepté de nous accueillir dans sa structure
afin que nous puissions effectuer notre stage ;
 Le Dr. BOSSOU OLIVIER VIDEME, Chef de Département d’Informatique et
des Télécommunications à l’Institut Supérieur du Sahel, pour tous les
enseignements qu’il nous a inculqué ;
 Les enseignants de l’Institut Supérieur du Sahel et en particulier ceux du
département Informatique et Télécommunication pour leurs enseignements tout
au long de notre formation ;
 Toute ma famille, en particulier ma maman Me. SONTSA VALERIE
MARGUERITTE pour leur soutien sans fin ;
 Tous mes amis et camarades pour leur soutien.

III
TABLE DES MATIERES
DEDICACE.......................................................................................................................I
REMERCIEMENTS.........................................................................................................I
LISTE DES SIGLES ET ABREVIATIONS.................................................................... VI
RESUME......................................................................................................................VII
ABSTRACT................................................................................................................. VIII
LISTE DES TABLEAUX ............................................................................................... IX
LISTE DES FIGURES ET ILLUSTRATIONS.................................................................X
INTRODUCTION GENERALE .......................................................................................1
CHAPITRE I : CONTEXTE ET PROBLEMATIQUE...................................................... 2
I.1) Présentation de l’entreprise.................................................................................. 2
I.2) Contexte................................................................................................................ 2
I.2.1) Fonctionnalités............................................................................................... 3
I.2.2) Plateformes supportées.................................................................................. 3
I.2.3) Architecture.................................................................................................... 4
I.3) Problématique ...................................................................................................... 4
I.4) Méthodologie........................................................................................................ 5
I.4.1) Planification et architecture........................................................................... 5
I.4.2) Le développement.......................................................................................... 5
I.4.3) Tests et intégration ........................................................................................ 6
I.4.4) La maintenance.............................................................................................. 6
I.5) Objectifs................................................................................................................ 6
CHAPITRE II : GENERALITES ..................................................................................... 7
II.1) L’informatique mobile......................................................................................... 7
II.2) Les applications mobiles.....................................................................................8

IV
II.3) La géolocalisation................................................................................................ 9
II.4) Les web services ................................................................................................ 10
II.5) Les méthodes agiles de développement.............................................................11
II.5.1) Définition .....................................................................................................11
II.5.2) Les valeurs des méthodes agiles..................................................................11
II.5.3) La méthodologie Scrum...............................................................................12
II.6) Le pattern MVC..................................................................................................13
CHAPITRE III : CONCEPTION ET MODELISATION.................................................15
III.1) Expression des besoins .....................................................................................15
III.1.1) Les besoins fonctionnels .............................................................................15
III.1.2) Les besoins non fonctionnels .....................................................................21
III.2) Le dictionnaire des données............................................................................22
III.3) Modélisation ....................................................................................................24
III.3.1) Le diagramme de classes ...........................................................................24
III.3.2) Diagrammes de cas d’utilisation............................................................... 24
III.3.4) Diagramme de package............................................................................. 27
III.3.3) Diagramme de déploiement......................................................................28
III.3.5) Architecture graphique de l’application ................................................... 29
III.5) Implémentation ...............................................................................................30
III.4.1) Android ......................................................................................................30
III.4.2) Java.............................................................................................................31
III.4.3) Les Google services ....................................................................................31
III.4.4) Les services web ReST................................................................................31
III.4.5) XML............................................................................................................31
III.4.6) L’IDE Eclipse et l’ADT Android................................................................ 32
III.4.7) L’émulateur AVD....................................................................................... 32

V
III.5) Utilisation ........................................................................................................ 32
CHAPITRE IV : RESULTATS ET COMMENTAIRES.................................................. 33
IV.1) Authentification et paramètres ........................................................................ 33
IV.1.1) Authentification.......................................................................................... 33
IV.1.2) Ajout des messages .................................................................................... 34
IV.1.3) Paramètres .................................................................................................34
IV.2) Traquer les terminaux...................................................................................... 36
IV.2.1) Accueil administrateur............................................................................... 36
IV.2.2) Accueil utilisateur..................................................................................... 36
IV.2.3) La liste des terminaux ............................................................................... 37
IV.2.4) Suivi de terminaux..................................................................................... 37
IV.3) Comparaison entre aGTS et d’autres applications clientes de GTS Enterprise
...................................................................................................................................42
IV.3.1) CelltacGTS..................................................................................................42
IV.3.2) OpenGTS Client......................................................................................... 42
CONCLUSION ET PERSPECTIVES............................................................................. 45
BIBLIOGRAPHIE.........................................................................................................46

VI
LISTE DES SIGLES ET ABREVIATIONS
ADT : Android Development Tool
API : Application Programming Interface
GNSS : Global Navigation Satellite System
GPS : Global Positionning System
GTS : GPS Tracking System
HTML : HyperText Markup Language
HTTP: HyperText Transfer Protocol
IDC : International Data Corporation
IDE : Integrated Development Environment
IOS : IPhone OS ou IDevice Operating System
JDK : Java Development Kit
MVC : Modèle-Vue-Contrôleur
ReST : Representational State Transfer
SDK : Software Development Kit
SIM : Subscriber Identity Module
SGBD : Système de Gestion de Bases de données
SGML : Standard Generalized Markup Language
SMS : Short Message Service
UML : Unified Modeling Language
URL : Uniform Resource Locator
WSDL : Web Services Description Language
XML : eXtensible Markup Language

VII
RESUME
GTS Enterprise est un projet disponible en Open Source conçu spécifiquement
pour fournir des services GPS basés sur le Web pour le suivi d’une flotte de terminaux.
Il est utilisé par de nombreuses entreprises dans le monde pour la surveillance de leurs
ressources mobiles. Il n’est disponible que pour les ordinateurs de bureau. Or de nos
jours les modes de travail évoluent de plus en plus vers la mobilité.
Ce document présente le processus de conception et de réalisation d’une application
cliente de GTS Enterprise pour les plateformes mobiles Android. Elle apportera de la
mobilité dans l’utilisation de GTS. Les différentes fonctionnalités que remplie cette
application sont les suivantes :
 positionner un terminal sur une carte, en occurrence Google Map ;
 commander les terminaux suivis via SMS ;
 avoir accès aux derniers évènements du terminal et représenter une partie de son
trajet sur une carte ;
 avoir connaissances d’autres informations supplémentaires sur un terminal
(vitesse, odomètre, quantité d’essence) si ceux-ci sont disponibles.
aGTS a été conçue tout en respectant les spécifications définies dans le cahier des
charges. Les détails de la conception et l’architecture de l’application sont précisés afin
d’assurer une maintenance facile.
Mots clés : GTS Enterprise, services web, Android, géolocalisation, Scrum.

VIII
ABSTRACT
GTS Enterprise in an open source project that provides a web based interface to
track « fleet » of devices. This tracking solution is used by many enterprises all over the
world. But, GTS is only available for desktop and nowadays we are moving toward
mobile devices.
This document presents the process of designing and realization of a client
application to GTS Enterprise for Android devices. aGTS will bring mobility in the use
of GTS. The following are the features that it fulfills:
 locate a device on a Map ;
 send SMS to a device;
 list the last events of a device and represent a portion of its journey on a map ;
 provide some additional informations about a device (speed, odometer, fuel
quantity…), if they are eventually available.
aGTS has being designed on terms and conditions specified. Details of designing
and the architecture of the application are clearly defined in order to ensure its
maintainability.
Key words: GTS Enterprise, web services, Android, geolocation, Scrum

IX
LISTE DES TABLEAUX
Tableau 1 : Lister les terminaux.................................................................................... 15
Tableau 2 : Localiser un terminal ................................................................................. 16
Tableau 3 : Lister les derniers évènements d’un terminal ............................................ 17
Tableau 4 : Représenter le trajet d’un terminal............................................................. 17
Tableau 5 : Envoyer un message à un terminal ............................................................ 18
Tableau 6 : Modifier l’URL du service web................................................................. 19
Tableau 7 : Lister les comptes ...................................................................................... 19
Tableau 8 : Ajouter un message au système................................................................. 20
Tableau 9 : Copier le nom d’un terminal...................................................................... 20
Tableau 10 : Copier le numéro d’un terminal............................................................... 21
Tableau 11 : Dictionnaire des données......................................................................... 23
Tableau 12 : Cas d'utilisation - traquer un terminal...................................................... 25
Tableau 13 : Cas d'utilisation - paramétrage................................................................ 26
Tableau 14 : Contraste cas d'utilisation - fonctionnalités ............................................. 27
Tableau 15 : Comparaison entre aGTS et les autres clients de GTS............................ 43

X
LISTE DES FIGURES ET ILLUSTRATIONS
Figure 1 : Interface de GTS Enterprise (tracé du trajet) .................................................... 2
Figure 2 : Architecture de GTS Enterprise.......................................................................... 4
Figure 3 : Déroulement d'un projet avec Scrum ................................................................ 13
Figure 4 : Diagramme de classe d’aGTS ............................................................................ 24
Figure 5 : Diagramme de cas d’utilisation - traquer un terminal..................................... 25
Figure 6 : Diagramme de cas d’utilisation – paramétrage................................................ 26
Figure 7 : Diagramme de package d’aGTS ........................................................................ 28
Figure 8 : Diagramme de déploiement d’aGTS................................................................. 29
Figure 9 : Charte graphique d’aGTS ................................................................................... 29
Figure 10 : Page d’authentification et de paramètres........................................................ 33
Figure 11 : Ajout de messages ............................................................................................. 34
Figure 12 : Menu de paramétrage........................................................................................ 35
Figure 13 : Page de modification de l’URL du service web ............................................ 35
Figure 14 : Vérification des paramètres d’authentification.............................................. 35
Figure 15 : Liste des comptes............................................................................................... 36
Figure 16 : Page d’accueil de l’utilisateur .......................................................................... 36
Figure 17 : Liste des terminaux............................................................................................ 37
Figure 18 : Menu contextuel................................................................................................. 37
Figure 19 : Localisation d’un terminal................................................................................ 38
Figure 20 : Liste des messages du système ........................................................................ 38
Figure 21 : Liste des applications de messagerie de l’appareil........................................ 39
Figure 22 : Message en édition pour envoi......................................................................... 39
Figure 23 : Derniers évènements de terminal..................................................................... 40
Figure 24 : Choix de l’intervalle de temps pour les évènements..................................... 40
Figure 25 : Trajet du terminal............................................................................................... 41
Figure 26 : Vitesse du terminal ............................................................................................ 41
Figure 27 : Celltrac/Free v1.4.3 ........................................................................................... 42
Figure 28 : OpenGTS client.................................................................................................. 43

1
INTRODUCTION GENERALE
De nombreuses entreprises dans divers secteurs disposent de ressources mobiles
opérant des missions sur le terrain. Ces missions peuvent concerner le contrôle ou la
mesure d’équipements chez un client ou sur un site, la livraison d’un courriel etc.
L’organisation de ces équipes nomades et la collecte des informations relatives aux
interventions est un enjeu majeur pour ces professionnels.
Aussi, avec l’avancée fulgurante que connait l’informatique nomade de nos jours,
l’on voit naître chaque jour des solutions applicatives pour appareils mobiles qu’utilisent
les entreprises. Les modes de travail évoluent donc vers plus de mobilité, mais aussi vers
plus de flexibilité.
GTS Enterprise (GPS Tracking System) est une application de suivi en temps réel
de terminaux mobiles. C’est une solution de suivi et de gestion de la flotte de terminaux
dont peut disposer une entreprise. Elle n’est disponible que pour ordinateur de bureau et
ne permet pas à ses utilisateurs de jouir de ses fonctionnalités dans leur mobilité.
Notre travail vise à réaliser une application cliente native de GTS pour
plateformes Android destinée à résoudre ce problème.
Pour ce faire, nous allons présenter au chapitre I le contexte afin de dégager la
problématique. Dans le chapitre II, nous présenterons quelques généralités qui tournent
autour du thème. Nous serons amenés à suivre dans le chapitre III les étapes de la
conception et de la modélisation de l’application cliente de GTS Enterprise. Enfin, au
chapitre IV nous présenterons les résultats obtenus après implémentation.

2
CHAPITRE I : CONTEXTE ET PROBLEMATIQUE
I.1) Présentation de l’entreprise
Situé au rond-point Maetur à Bonamoussadi (Douala), Grid Engineering est une
société de services d’ingénierie informatique composée d’une équipe pluridisciplinaire
d’ingénieurs certifiés et de hauts cadres d’entreprises. Présent sur le marché depuis près
d’une décennie, Grid Engineering concilie les besoins des entreprises et les opportunités
du monde technologique pour sophistiquer leurs solutions.
Grid a pour mission d’apporter des solutions technologiques simplifiées et
innovantes au service des objectifs des individus et des entreprises.
I.2) Contexte
GTS Enterprise est une application de géolocalisation et du suivi de terminaux
disponible en version web développé par GEOTelematic®
Solutions. Il est écrit en java,
et utilise les solutions comme Apache Tomcat pour le déploiement des web services
(services web) et MySQL pour le stockage des données.
Figure 1 : Interface de GTS Enterprise (tracé du trajet) [11]

3
I.2.1) Fonctionnalités
Ses principales fonctionnalités sont :
- Authentification basée sur le Web : chaque compte peut supporter plusieurs
utilisateurs et chaque utilisateur a son propre mot de passe et un accès contrôlé
aux sections dans le compte.
- la cartographie : GTS vient avec le support OpenLayers/OpenStreetMap en
plus des supports Google Maps, Microsoft Virtual Earth et Mapstraction. Grâce
à ce module, il est possible de tracer le trajet d’un terminal. En effet, en
recherchant les évènements d’un terminal ou d’un groupe de terminaux dans un
intervalle de temps précis, il est possible de placer chacun de ces évènements
sur une carte, le résultat étant le trajet du terminal dans cet intervalle de temps.
En plus, il est également possible de suivre en temps réel un terminal ou un
groupe (flotte) de terminaux dans son (leur) déplacement.
- la gestion des rapports : ce module offre à l’utilisateur un bref historique des
déplacements d’un terminal. Chaque terminal est configuré pour envoyer à des
intervalles de temps réguliers certaines informations (évènements) au serveur
de GTS. Il s’agit entre autre des coordonnées géographiques (latitude /
longitude), de l’adresse, de la vitesse, du statut (en déplacement, en arrêt), de
l’altitude, de l’odomètre (valeur de la distance parcourue), de la quantité
d’essence, etc. En fonction de la nature de l’équipement suivi, certaines
informations peuvent être activées sur celui-ci.
- la gestion de l’administration : les comptes utilisateurs, les identifiants des
véhicules sont gérés à ce niveau.
Il met à la disposition des utilisateurs un service web qui permet la communication
entre elle et d’autres applications clientes [12].
I.2.2) Plateformes supportées
GTS Enterprise est entièrement écrit en java et utilise les technologies comme
Apache Tomcat pour le déploiement des web services et MySQL pour le stockage
des données. A ce titre, GTS peut fonctionner sur n’importe quel système supportant

4
ces technologies : Linux, Mac OS X, FreeBSD, OpenBSD, Windows (XP, Vista, 7,
8).
I.2.3) Architecture
L’architecture de GTS Enterprise se présente comme suit :
Figure 2 : Architecture de GTS Enterprise src.[11]
Les serveurs de communication et les périphériques distants (périphériques de
suivi GPS) s’exécutent comme des processus séparés au-dessus de java. Les servlets
de track, comme tout servlet, s’exécutent à l’intérieur d’un conteneur de servlet, ici
Apache Tomcat.
I.3) Problématique
GTS Enterprise étant une application pour bureau, limite l’utilisateur dans son
utilisation. Il serait intéressant de permettre à ses utilisateurs de pouvoir utiliser les
fonctionnalités de GTS dans leurs déplacements. La problématique se résume en la
question suivante : comment permettre à l’utilisateur de pouvoir traquer les terminaux
gérés par GTS Enterprise dans sa mobilité ?

5
I.4) Méthodologie
Pour résoudre le problème posé plus haut, nous avons adopté la méthode Scrum.
Il s’agit d’une méthode agile de gestion de projets décrite en 2001 par Schwaber et
Beedle dans le livre «Agile software development with Scrum» (Schwaber et Beedle,
2001) [9]. Cette méthodologie regroupe de développement d’un logiciel en trois phases,
planification + Architecture, développement, test + intégration.
I.4.1) Planification et architecture
La planification consiste à définir les exigences du système et la date de livraison
des fonctionnalités. Cette phase regroupe trois étapes à savoir l’identification des
besoins, la conception et la modélisation.
I.4.1.1) L’identification de besoins :
Il est question ici, de définir les différentes fonctionnalités que devront remplir le
futur système. Ceci se fait par une étude du système principal, c’est-à-dire GTS
Enterprise, en conjonction avec les futurs utilisateurs.
I.4.1.2) La conception et la modélisation
Dans cette phase, nous définissons une architecture pour le futur système, en
produisant une représentation schématique des différentes interactions du système avec
les futurs utilisateurs. Nous utiliserons la notation UML (Unified Modeling Langage)
pour la modélisation du système [15].. Cette phase devra aussi produire une architecture
graphique de l’application. Il s’agit de la modélisation de la navigation entre toutes les
différentes interfaces de l’application.
I.4.2) Le développement
La phase de développement consiste à réaliser, construire, et créer les différents
composants de l’application. L’on utilise différents outils tels les frameworks, API
(Applications Programming Interface), langages de programmations, IDE
(environnement de développement intégré), et approches facilitant le travail,
permettant d’avoir au final les composantes du système.

6
I.4.3) Tests et intégration
Une fois qu’une fonctionnalité est réalisée, celle-ci doit être testée. Le test
s’effectue par une suite d’opérations où l’on envoie des données en entrées et on observe
le comportement à la sortie. Si le test est concluant, alors la fonctionnalité est intégrée
au système. Une fois le système complet, une documentation utilisateur est réalisée.
I.4.4) La maintenance
Il sera question dans cette phase, de former les utilisateurs de l’application, de
compléter la documentation du code, de produire un guide d’utilisation, de corriger les
bugs, et d’ajouter ou de modifier des fonctionnalités suggérées par les utilisateurs afin
que l’application rende un service de qualité.
I.5) Objectifs
Les différents objectifs à atteindre par l’application sont les suivants :
- avoir la liste des terminaux d’un utilisateur : chaque utilisateur possède sous
son compte plusieurs terminaux qu’il peut suivre. L’application devra lister à
l’utilisateur tous ces terminaux ;
- retrouver le trajet d’un véhicule sur une carte (Google Map par exemple). En
se servant des différents évènements qu’un terminal envoie au serveur,
l’application va positionner chaque point d’évènement sur une carte pour que
l’on retrouve le trajet du terminal ;
- localiser un terminal. Pour tout terminal doté d’un système de géolocalisation,
il est donc possible à tout moment de connaître la position de ce terminal ;
- commander un terminal. Chaque terminal peut être configuré de manière à
recevoir des commandes. Avec une commande, on peut par exemple démarrer
ou stopper le tracking. De plus, ces terminaux peuvent aussi recevoir ces
commandes via des simples messages textes ;
- donner accès à tous les comptes à l’administrateur. L’administrateur aura la
possibilité de voir tous les comptes du système et de choisir celui dont il veut
suivre les terminaux.

7
CHAPITRE II : GENERALITES
II.1) L’informatique mobile
La mobilité caractérise tout ce qui peut se mouvoir ou être mû. Cette notion de
l’activité humaine se traduit par trois aspects différents dans le domaine de
l’informatique : le nomadisme, l’ubiquité, les systèmes sensibles au contexte [5].
 Nomadisme
La première façon de considérer l'informatique mobile consiste à fournir un
dispositif portable aux utilisateurs. L'utilisation de ces dispositifs requiert toute
l'attention de l'utilisateur et s'applique à tout déplacement, indépendamment de celui-ci.
Cette approche est souvent appelée nomadisme, bien que ce terme puisse prendre
d'autres significations dans d'autres domaines, comme dans les systèmes distribués où
le nomadisme désigne la capacité d'un système à fournir à chaque utilisateur son
environnement de travail sur n'importe quelle station.
L’exemple le plus connu de nomadisme est l’ordinateur portable que nous amenons
avec nous afin d’emporter notre environnement informatique de travail.
 Informatique Ubiquitaire
La deuxième façon de considérer l'informatique mobile est de l'inscrire dans une
approche plus globale que constitue l'informatique ubiquitaire. L'informatique
ubiquitaire a pour but de rendre accessible toutes sortes de services, n'importe où, tout
en masquant l'ordinateur. Cette volonté d'affranchir l'utilisateur des contraintes actuelles
d'utilisation d'un ordinateur (être assis devant un clavier, un écran, etc.) lui rend sa liberté
d'actions, notamment sa liberté de mouvement. L'ubiquité permet donc souvent la
mobilité.

8
 Systèmes sensibles au contexte
Les systèmes sensibles au contexte sont des systèmes dont l'interaction dépend
de l'environnement physique de l'utilisateur (localisation). Lorsque par exemple un
archéologue désire accéder aux découvertes d'un site, il n'est possible que de lui
présenter les objets à proximité, dans un rayon d'influence qui reste à déterminer (soit à
la conception, soit en option par l'utilisateur, soit par une adaptation automatique du
logiciel). Pour indiquer à l'archéologue les objets à leurs places initiales, il convient de
considérer aussi l'orientation de l'archéologue, information complémentaire à la
localisation. En fonction des moyens techniques mis en œuvre, cette orientation peut
être celle du regard ou celle du dispositif utilisé. Disposant du couple d'information
localisation et orientation, le système peut alors filtrer les informations disponibles selon
la direction du regard de l'utilisateur.
II.2) Les applications mobiles
Une application mobile est un programme conçu pour les appareils électroniques
mobiles (assistant personnel, téléphone portable, baladeur numérique). Elle permet à son
l’utilisateur de jouir des fonctionnalités du monde numérique dans sa mobilité.
L’utilisateur peut avoir accès à son courrier électronique, aux informations
météorologiques tout en restant mobile. Pour une entreprise, les applications mobiles
augmentent la productivité des employés, facilite l’accès à l’information et augmente le
revenu [3].
Bien que trois plateformes dominent le marché des mobiles (Android de Google,
Windows Phone de Microsoft et IOS d’Apple), le système d’exploitation de Google
(Android) arrache la part du lion avec 82,2 % en 2014 d’après l’IDC [10].
On distingue trois grandes familles d’applications mobiles. Les applications
natives, les applications hybrides et les applications web [8].
- Les applications natives
Une application native est unique à une plateforme. Son utilisation nécessite au
préalable une installation dans le terminal. Elles sont disponibles dans le « store » de la

9
plateforme concernée (App store pour Apple, Google play pour Android et Windows
store pour les Windows phone). Le store est comme un magasin géré par les
propriétaires de la plateforme, dans lequel les développeurs d’applications peuvent venir
déposer leurs applications. On choisit en général ce type pour exploiter au maximum les
capacités du système.
- Les applications hybrides
Une application hybride est un mélange d’application native et d’application web.
Avec elle, l’on bénéficie des avantages des applications natives sans développer
l’intégralité du produit dans le langage de chaque plateforme. Les pages développées en
web (pour la partie web de l’application) peuvent être embarquées pour fonctionner hors
ligne mais elles sont statiques et nécessitent une re-soumission pour être mises à jour.
Dans le cas où la page web n’est pas embarquée, elle ne fonctionne pas hors ligne. L’une
des particularités des applications hybrides est qu’elles peuvent être installées sur
plusieurs plateformes différentes et peuvent être disponibles sur leurs stores.
- Les applications web
Une application web se différencie des deux précédentes par son point d’accès.
Elle peut uniquement être lancée depuis un navigateur web. Cette solution est également
basée sur des langages du web. C’est un site web pour appareils mobiles. Les langages
de programmation utilisés sont les mêmes que ceux utilisés pour le web : HTML/CSS
et JavaScript. Les coûts de développement sont limités et il n’y a aucune dépendance
avec le store d’une plateforme.
II.3) La géolocalisation
La géolocalisation est une méthode permettant d’obtenir et éventuellement
transmettre la position géographique d’une personne ou d’une ressource. Elle était à
l’origine destinée pour les besoins de l’armée américaine, et ce n’est qu’en 1993 que le
Président des Etats-Unis (Bill Clinton) décide de le mettre à la disposition du public
[14].

10
La localisation des objets, des personnes, la gestion des flottes de véhicules sur
un plan ou une carte à l’aide de coordonnées géographiques sont alors devenues
possibles. Ces coordonnées sont obtenues à l’aide de systèmes de radionavigation par
satellites (GNSS). Le système le plus connu de nos jours est le GPS (Global Positioning
System).
Parmi les nombreux avantages que procure la géolocalisation, on peut citer :
 la gestion efficace et l’amélioration de la sécurité des ressources dans une
entreprise ;
 la gestion optimale des itinéraires lors des interventions sur le terrain ;
 le suivi en temps réel des ressources mobiles notamment les véhicules à travers
une cartographie dynamique ;
 une meilleure allocation des moyens pour des prestations à accomplir en des lieux
dispersés notamment pour des interventions d’urgence. L’on peut par exemple
identifier l’employé le plus proche d’une panne d’ascenseur ou l’ambulance la
plus proche d’un accident.
II.4) Les web services
Un web service (service web) est un mécanisme permettant la communication
entre applications via un réseau. Il est mis à disposition (sur Internet) par une entité
appelée fournisseur de service et accessible par les clients à travers des protocoles de
l’Internet standards tel que le HTTP. Le mécanisme de communication entre le client et
le fournisseur de service est généralement du XML. Ce même mécanisme est utilisé
pour décrire l’interface de communication avec le service web contenu dans un fichier
WSDL. L’utilisation de cette interface rend la communication indépendante des plates-
formes et des langages de développement sur lesquels ils reposent. L’on utilise les web
services généralement pour consommer les ressources mis à disposition par le
fournisseur. Ceci nous permet d’avoir des clients plus légers, car on ne se souciera plus
du stockage des données.

11
II.5) Les méthodes agiles de développement
II.5.1) Définition
Les méthodes agiles reposent sur des cycles de développement itératifs et
adaptatifs en fonction des besoins évolutifs du client. Elles permettent d'impliquer
l'ensemble des collaborateurs ainsi que le client dans le développement du projet [7].
Ces méthodes permettent généralement de mieux répondre aux attentes du client
en un temps limité (en partie grâce à l'implication de celui-ci) tout en faisant monter les
collaborateurs en compétences. Ces méthodes constituent donc un gain en productivité
ainsi qu'un avantage compétitif tant du côté client que du côté du fournisseur.
II.5.2) Les valeurs des méthodes agiles
Les méthodes agiles se reconnaissent toutes dans les valeurs suivantes [1] :
Les individus et leurs interactions plus que les processus et les outils. Dans la vision
agile, l'équipe est bien plus importante que les outils ou les procédures de
fonctionnement. Il est préférable d'avoir une équipe soudée et dont les membres
communiquent entre eux, composée de développeurs de niveaux différents, plutôt
qu'une équipe composée d'experts qui travaillent de manière isolée. La communication
est donc une notion fondamentale dans un contexte de développement agile.
Des logiciels opérationnels plus qu’une documentation exhaustive. Il est primordial
que le projet fonctionne, c'est la priorité avant toute chose. La documentation technique
et les autres outils (de tests, de reporting) constituent une aide précieuse mais ne sont
pas une fin en soi. Il est parfois préférable de simplement commenter abondamment le
code lui-même et surtout de transférer la totalité des compétences et connaissances du
métier à l'ensemble des collaborateurs de l'équipe.
La collaboration avec les clients plus que la négociation contractuelle. Le client doit
être impliqué dans le développement. Le fournisseur ne doit pas se contenter de négocier
un contrat au début du projet puis de refuser l'évolution des besoins du client. Le client

12
doit collaborer avec l'équipe et fournir des comptes rendus réguliers sur l'adaptation du
logiciel à ses attentes.
L’adaptation au changement plus que le suivi d’un plan. La planification initiale et
la structure du projet doivent être flexibles afin de permettre les évolutions attendues par
le client. En effet, les premières livraisons du projet donnent très souvent suite à des
demandes d'évolution.
II.5.3) La méthodologie Scrum
La méthode Scrum est une méthode agile, créée en 2001, dont le nom est un terme
emprunté au rugby qui signifie « la mêlée ». Elle s'appuie sur le découpage des projets
en itérations encore nommées « sprints ». Un sprint peut avoir une durée qui varie
généralement entre deux semaines et un mois [7].
Avant chaque sprint, les tâches sont estimées en temps et en complexité. Ces
estimations permettent à la fois de planifier les livraisons mais aussi d'estimer le coût de
ces tâches auprès du client. Les fonctionnalités (encore appelées « user stories ») qui
font l'objet d'un sprint constituent ce que l'on appelle un « sprint backlog » du produit
éventuellement livrable à la fin du sprint. Le « product backlog » correspond à
l'ensemble des fonctionnalités attendues pour le produit sur l'ensemble des sprints.
La méthode Scrum est aussi caractérisée par une « mêlée » quotidienne, encore
appelée « morning » ou « stand up », dans laquelle les collaborateurs (chefs de projets,
développeurs et responsables fonctionnels) indiquent tour à tour les tâches qu'ils ont
effectuées la veille, les difficultés rencontrées et enfin ce sur quoi ils vont poursuivre
leur travail le jour suivant. Cela permet d'évaluer l'avancement du projet, de mobiliser
des ressources là où cela est le plus nécessaire, mais aussi de venir en aide aux
collaborateurs rencontrant des difficultés lorsque celles-ci ont déjà été rencontrées
auparavant par d'autres membres de l'équipe.

13
Figure 3 : Déroulement d'un projet avec Scrum src.[7]
La méthode Scrum définit trois rôles pour un projet.
1. Le Scrum master. Il s'agit d'une personne chargée de veiller à la mise en
application de la méthode et au respect de ses objectifs. Il ne s'agit pas d'un chef
de projet, mais d'une personne chargée de lever les obstacles éventuels qui
empêcheraient l'avancement de l'équipe et du projet pendant les différents sprints.
2. Le product owner. Il s'agit du représentant officiel du client au sein d'un projet
Scrum. Il est l'interlocuteur principal du Scrum Master et des membres de
l'équipe. Il définit les besoins du produit et rédige les spécifications. Il peut se
faire aider de responsables fonctionnels pour la rédaction des spécifications. Il
est également chargé de définir et définir les priorités des users stories pour
chaque sprint.
3. L'équipe (« team members »). Elle est constituée des personnes chargées de la
réalisation du sprint et d'un produit utilisable en fin de sprint. Il peut s'agir de
développeurs, architectes, personnes chargées de faire des tests fonctionnels…
II.6) Le pattern MVC
Le pattern MVC permet de bien organiser son code source.. Le but de MVC est
justement de séparer la logique du code en trois parties que l'on retrouve dans des
fichiers distincts, comme l'explique la description qui suit.

14
- Le modèle
Les données manipulées par le modèle. Il assure la gestion et garantit l’intégrité
des données.
- La vue
La vue constitue l’interface entre le système et l’utilisateur. Elle est responsable
de l’affichage des données. Elle est aussi responsable de la gestion des actions de
l’utilisateur (sélection d’entrée, bouton, clic de souris, etc.). Lorsqu’elle reçoit un
évènement, elle le transmet au contrôleur.
- Le contrôleur
La synchronisation entre le modèle et la vue est réalisée par le contrôleur.
Lorsque l’utilisateur enclenche un évènement le contrôleur le reçoit et lance l’action
associée. Le contrôleur est souvent scindé en plusieurs parties dont chacune reçoit les
événements d'une partie des composants.

15
CHAPITRE III : CONCEPTION ET MODELISATION
Nous présenterons dans ce chapitre chaque étape du cycle de vie de notre
application. De la conception à l’implémentation, nous verrons ses différents
diagrammes UML, ainsi que son architecture.
L’ensemble des besoins à satisfaire pour un système est exprimé dans le cahier
des charges [17].
III.1) Expression des besoins
Cette section décrit les besoins fonctionnels (opérations que le système doit
réaliser) et non fonctionnels du système (spécification qui n’exprime pas une fonction
du logiciel). Chaque besoin possède les attributs suivants :
1. un identifiant unique
2. la catégorie du besoin
3. la description
4. une liste de termes le référant
5. la justification
6. la priorité
7. la vérification
Le champ catégorie a deux valeurs possibles : fonctionnel ou non fonctionnel,
tandis que le champ priorité à trois valeurs possibles : haute, moyenne, faible.
III.1.1) Les besoins fonctionnels
- La liste des terminaux
Tableau 1 : Lister les terminaux
Identifiant F1
Catégorie Fonctionnel
Description Le système devra lister tous les terminaux d’un utilisateur. Cette
fonctionnalité permettra à l’utilisateur de choisir parmi les terminaux

16
de son compte celui à suivre. L’administrateur aura accès à tous les
comptes du système, donc il peut voir tous les terminaux du système.
Pour tout autre utilisateur, une fois connecté, il verra le nombre de
terminaux de son compte.
Termes aGTS, terminaux, utilisateur
Justification L’utilisateur peut avoir plusieurs terminaux à suivre, il faudrait qu’il
puisse choisir celui dont il va s’occuper.
Priorité Haute
Vérification Ajouter des terminaux à l’utilisateur dans GTS, le connecter à son
mobile avec le compte de cet utilisateur et vérifier si les terminaux
ajoutés y figurent.
- Localiser le terminal
Tableau 2 : Localiser un terminal
Identifiant F2
Description L’utilisateur devra être capable de géo localiser un terminal, c’est-à-
dire le positionner sur une carte. On pourra aussi connaître la vitesse
du terminal au moment de la localisation ainsi que l’adresse de
localisation. Pour y arriver, l’utilisateur choisit un terminal et ensuite
indique au système qu’il souhaiterait le localiser. Le système
récupèrera alors la position du terminal et positionnera un marqueur
sur une carte représentant la position du terminal. En cliquant sur le
marqueur, nous obtiendrons la vitesse du terminal à cet instant.
Termes aGTS, terminaux, vitesse, géolocalisation.
Justification L’utilisateur peut avoir besoin de situer son terminal pour prendre une
certaine décision en fonction de sa position
Priorité Haute
Vérification Lancer la localisation d’un terminal et vérifier si l’on a le même
résultat en faisant une localisation avec GTS

17
- Les derniers évènements du terminal
Tableau 3 : Lister les derniers évènements d’un terminal
Identifiant F3
Description Le système permettra à l’utilisateur de voir les derniers évènements
qu’un terminal a envoyé au serveur. L’utilisateur choisit un terminal
et indique au système qu’il veut obtenir les évènements récents de ce
terminal. Le système affichera alors à l’écran ces évènements.
Termes aGTS, terminaux, utilisateur.
Justification La connaissance des derniers évènements du terminal participe à la
gestion des ressources. Cette fonction permet à l’utilisateur d’avoir
connaissance des différents endroits où sont passés son terminal, et à
quel moment.
Priorité Haute
Vérification Se connecter avec le compte du terminal actuel sur GTS Enterprise et
vérifier si la liste des derniers évènements du terminal correspond
avec celle qu’affiche l’application
- Avoir une portion du trajet du terminal
Tableau 4 : Représenter le trajet d’un terminal
Identifiant F4
Description Le système fournit une interface permettant à l’utilisateur de
visualiser le trajet d’un terminal. Lorsque l’utilisateur possède les
derniers évènements de son terminal, il peut cliquer sur un lien qui
positionnera les différentes coordonnées d’évènement sur une carte
sous forme de marqueurs. Si l’utilisateur possède déjà dans son
appareil mobile une carte où le système peut positionner les
coordonnées, il verra directement ses marqueurs aux points adéquats.
S’il n’en possède pas une, alors le système essaiera d’en télécharger

18
une en ligne, bien sûre il lui faudra une connexion internet (pour la
première représentation). Sinon, les marqueurs seront positionnés sur
une carte blanche.
Termes aGTS, terminaux, utilisateur, carte, trajet.
Justification La connaissance du trajet d’un terminal participe à la gestion des
ressources ainsi qu’à leur sécurité. Cette fonction permet à
l’utilisateur d’avoir connaissance des différents endroits où sont
passés son terminal, et à quel moment.
Priorité Haute
Vérification Lorsque les marqueurs seront placés sur la carte du mobile, comparer
le résultat avec celui de la fonction Map de GTS.
- Envoyer des messages à un terminal
Tableau 5 : Envoyer un message à un terminal
Identifiant F5
Description Le système devra permettre à l’utilisateur d’envoyer des messages à
partir de son mobile directement à son terminal. Une fois le terminal
choisi, l’utilisateur sélectionne l’option envoyer message. Il obtient
alors la liste des messages enregistrés dans le système. Il fera alors le
choix du message qu’il souhaite envoyer à son terminal. S’il a
plusieurs applications de messagerie installées, il faudra qu’il
choisisse celle avec laquelle il voudra envoyer le message. Une fois
le choix opéré, l’application s’ouvrira en mode édition, les champs
message et destinataire étant préalablement remplis avec les
informations prises dans le système. Il pourra alors les modifier à sa
guise avant envoi.
Termes aGTS, terminaux, utilisateur, message
Justification Les terminaux du système sont configurés pour recevoir des
commandes, et celles-ci peuvent venir sous forme de message texte.

19
Priorité Haute
Vérification Envoyer un message à un terminal dont le numéro de téléphone est
connu et vérifier si celui-ci est arrivé.
- Modifier l’URL du service web
Tableau 6 : Modifier l’URL du service web
Identifiant F6
Description Le système doit permettre à l’utilisateur de modifier l’URL du service
web.
Termes aGTS, paramètres
Justification L’URL du web service correspond en quelque sorte à l’adresse de
communication avec le serveur. C’est elle qui permet au système de
se connecter au serveur. En plus, l’utilisateur peut vouloir utiliser
cette application sur plusieurs ‘serveurs’ différents. Il n’aura qu’à
modifier cette URL.
Priorité Haute
Vérification Modifier l’URL et essayer de se connecter sur le nouveau ‘serveur’.
- La liste des comptes
Tableau 7 : Lister les comptes
Identifiant F7
Description Lorsqu’on se connecte en tant qu’administrateur, on verra la liste de
tous les comptes du système.
Termes aGTS, comptes, administrateur
Justification L’administrateur pourra avoir besoin de suivre les terminaux d’un
autre compte.
Priorité Moyenne

20
Vérification Créer des comptes, se connecter en tant qu’administrateur et vérifier
si on a bien la liste de comptes
- Ajouter de message
Tableau 8 : Ajouter un message au système
Identifiant F8
Catégorie Non fonctionnel
Description Avant que l’utilisateur ne s’authentifie, il pourra enregistrer des
messages dans son système. L’ajout d’un message se fait en saisissant
le code du message, ou le message intégral, et une description pour
ce message.
Termes aGTS, terminaux, messages
Justification Facilite l’édition du message à envoyer à un terminal.
Priorité Haute
Vérification Ajouter un message au système, il apparaîtra dans la liste des
messages ajoutés. Il sera aussi présent dans la liste des messages
présents pour envoi à un terminal.
- Copier le nom du terminal
Tableau 9 : Copier le nom d’un terminal
Identifiant F9
Description Lorsque l’utilisateur a choisi un terminal, il peut décider de copier le
nom du terminal.
Termes aGTS, terminaux, utilisateur, nom, message.
Justification L’utilisateur peut faire communiquer l’application avec d’autres. Dans
un cas par exemple où il veut envoyer un message à un tiers contenant

21
le nom d’un terminal, avec cette fonctionnalité il n’aura pas à retenir le
nom du terminal, un copier-coller ira.
Priorité Faible
Vérification Copier le nom du terminal, ouvrir un autre éditeur ou toute application
où l’on peut saisir et y faire un coller. Le nom du terminal doit y
apparaître en clair.
- Copier le numéro du terminal
Tableau 10 : Copier le numéro d’un terminal
Identifiant F10
Description Lorsque l’utilisateur a choisi un terminal, il peut décider de copier le
numéro du terminal.
Termes aGTS, terminaux, utilisateur, numéro, message.
Justification L’utilisateur peut faire communiquer l’application avec d’autres. Dans
un cas par exemple où il veut envoyer un message à un tiers contenant
le numéro d’un terminal, avec cette fonctionnalité il n’aura pas à retenir
le numéro du terminal, un copier-coller ira.
Priorité Faible
Vérification Copier le numéro du terminal, ouvrir un autre éditeur ou toute
application où l’on peut saisir et y faire un coller. Le numéro du terminal
doit y apparaître en clair
III.1.2) Les besoins non fonctionnels
Les besoins non fonctionnels spécifient les propriétés du système telles que les
contraintes d'environnement et d'implémentation, la performance, la maintenance,
l’ergonomie, l'extensibilité et la flexibilité.
 Les contraintes ergonomiques
Les contraintes ergonomiques sont les contraintes liées à l'adaptation entre les
fonctionnalités de l'application, leurs interfaces et leur utilisation.

22
Pour notre application, nous devons obéir aux contraintes ergonomiques suivantes :
- permettre un accès rapide de l'information ;
- Interface simple et compréhensible ;
- L'organisation des rubriques, des onglets, etc ;
- L'application doit guider le client ou le visiteur pour avoir sa demande c'est à dire
qu'elle doit être développée avec un langage compréhensif par l'utilisateur, présenter les
informations d'une façon simple et claire, faire apparaître les choix ou les saisis du client.
 Les contraintes techniques
- Il faut que toute interface de notre application soit homogène, en effet, les différentes
pages doivent suivre le même modèle de représentation (couleurs, images, textes, etc.) ;
- le code doit être extensible et maintenable pour faciliter toute opération d'amélioration
ou d'optimisation.
 Les contraintes de matériel
L'application sera installée sur un téléphone mobile à système Android.
III.2) Le dictionnaire des données
Les différentes données traitées par l’application et leurs attributs sont les suivantes :
 Compte. Un compte regroupe un ensemble d’utilisateurs contrôlant un ensemble
de terminaux. Ses attributs sont les suivant : l’identifiant, le nom et le mot de
passe ;
 utilisateur. Un utilisateur est toute personne ayant droit à utiliser le système. Ses
attributs sont les suivants : le nom et le numéro de téléphone ;
 terminal. Un terminal représente un élément ou équipement suivi par le système.
Comme attributs d’un terminal, nous avons la vitesse, le nom, les coordonnées
(latitude et longitude), le numéro de la SIM, le code de statut ;

23
 évènement. Un évènement est un ensemble d’informations envoyées au serveur
par un terminal. Ses attributs sont l’adresse, la latitude, la longitude, la vitesse, et
le temps ;
 message. Les messages sont stockés pour être envoyés aux terminaux. Comme
attributs pour un message, nous avons le code et la description.
Tableau 11 : Dictionnaire des données
Code Désignation Type
Id_c Identifiant d’un comte alphanumérique
Nom_c Nom d’un compte alphanumérique
Password_c Mot de passe d’un compte alphanumérique
Nom_u Nom d’un utilisateur alphanumérique
Phone_u Numéro de téléphone d’un utilisateur alphanumérique
Nom_t Nom d’un terminal alphanumérique
Latitude_t Latitude d’un terminal numérique
Longitude_t Longitude d’un terminal numérique
Sim_t Numéro de SIM d’un terminal alphanumérique
Statut_t Code du statut d’un terminal alphanumérique
Adresse_e Adresse d’envoi d’un évènement alphanumérique
Latitude_e Latitude d’envoi d’un évènement numérique
Longitude_e Longitude d’envoi d’un évènement numérique
Vitesse_e Vitesse du terminal à l’envoi de l’évènement numérique
Temps_e Heure d’envoi de l’évènement date
Code_m Code d’un message alphabétique
Description_m Description d’un message alphanumérique

24
III.3) Modélisation
III.3.1) Le diagramme de classes
Le diagramme de classe permet de donner la représentation statique du système
à développer. Cette représentation est centrée sur les concepts de classes et
d’associations. Chaque classe se décrit par les données et les traitements dont elle est
responsable pour elle-même et vis-à-vis des autres classes. Les traitements sont
matérialisés par des opérations.
Par rapport à notre application, un utilisateur possède un compte et plusieurs
utilisateurs peuvent se retrouver dans un même compte. Sous un compte on peut
regrouper plusieurs terminaux et chaque terminal envoie des évènements au serveur à
des intervalles de temps réguliers. Un utilisateur peut envoyer des messages à un
terminal. Ceci est illustré par la figure 4.
Figure 4 : Diagramme de classe d’aGTS
III.3.2) Diagrammes de cas d’utilisation
Un cas d’utilisation ou use case décrit l’usage que les acteurs font du système,
produisant un résultat intéressant pour ceux-ci.
 Identification des utilisateurs du système
Pour l’utilisation de notre système, on peut distinguer deux catégories d’utilisateurs :

25
 l’utilisateur normal, qui est toute personne qui possède un compte dans le système
de GTS Enterprise ;
 l’administrateur, qui est responsable de la gestion des comptes dans GTS. Dans
notre système, il a la possibilité de naviguer entre les comptes.
Tableau 12 : Cas d'utilisation - traquer un terminal
ID Description
U1 Envoyer un message au terminal
U2 Localiser un terminal
U3 Obtenir les derniers évènements d’un terminal
U4 Avoir une représentation du trajet d’un terminal
U5 Choisir un compte
U6 Voir la liste des terminaux
U7 Voir la liste des comptes
Les figures suivantes illustrent les différents cas d’utilisation du système.
Figure 5 : Diagramme de cas d’utilisation - traquer un terminal
Cette figure représente le cas d’utilisation traquer un terminal. L’utilisateur
pourra envoyer un message à un terminal, localiser un terminal, obtenir les évènements
d’un terminal, avoir une représentation du trajet d’un terminal. Avant de réaliser toutes
ces opérations, il faudrait qu’il ait au préalable la liste des terminaux. L’administrateur

26
quant à lui a la possibilité de choisir un compte dans la liste des comptes qui lui est
proposée.
Tableau 13 : Cas d'utilisation - paramétrage
ID Description
U8 Ajouter des messages
U9 Copier le nom d’un terminal
U10 Copier le numéro d’un terminal
U11 Modifier l’URL du service web
La figure 6 représente le cas d’utilisation paramétrer. Ce diagramme regroupe les
cas d’utilisation qui entourent le suivi d’un terminal. L’utilisateur a la possibilité
d’ajouter des messages dans le système, de copier le numéro ou le nom d’un terminal et
de modifier l’URL du service web.
Figure 6 : Diagramme de cas d’utilisation – paramétrage
 Cas d’utilisation contre besoins
Cette section relie les besoins présentés dans la section III.2 aux cas d’utilisation
décrits ci haut. Cette relation est présentée dans le tableau suivant :

27
Tableau 14 : Contraste cas d'utilisation - fonctionnalités
Cas d’utilisation Description Besoins
U1 Envoyer un message au terminal F5
U2 Localiser un terminal F2
U3 Obtenir les derniers évènements d’un
terminal
F3
U4 Avoir une représentation du trajet d’un
terminal
F4
U5 Choisir un compte F7
U6 Voire la liste des terminaux F1
U7 Voire la liste des comptes F7
U7 Ajouter des messages F8
U8 Copier le nom d’un terminal F9
U10 Copier le numéro d’un terminal F10
U11 Modifier l’URL du service web F6
III.3.4) Diagramme de package
La figure 8 ressort l‘architecture interne de l’application.
Le package modèle est composé de deux sous packages. Il est responsable de la
représentation de nos données, et en plus de la connexion avec le serveur.
Les package adapter et core contiennent un ensemble de fonctions regroupées en
classes selon le service rendu.
Le package client contient les classes responsables du formatage des données qui
seront affichées, tandis que le package layout contient les différentes interfaces
utilisateurs.

28
Figure 7 : Diagramme de package d’aGTS
III.3.3) Diagramme de déploiement
Le diagramme de déploiement ressort les relations entre le logiciel et le matériel.
Il donne le placement des composants et objets dans le système réparti.
La figure 9 présente le diagramme de déploiement du système. Ce dernier est
constitué de deux sous-systèmes, GTS Enterprise, installé sur un poste ayant comme
système d’exploitation Windows, Linux ou Mac OS. Il fera office de serveur. Le second
sous-système est l’application proprement dite. Elle sera installée sur les terminaux
Android, dont la version minimale est 2.2. Les deux sous système communiqueront en
utilisant le protocole HTTP.

29
Figure 8 : Diagramme de déploiement d’aGTS
III.3.5) Architecture graphique de l’application
L’architecture de la future application est la suivante :
Figure 9 : Architecture graphique d’aGTS
Les différents axes de navigation dans l’application y sont présents.

30
Lorsque l’utilisateur lance l’application, la page d’authentification se présente à
lui. A partir de cette page il peut soit aller à la page des paramètres pour la modification
de l’URL du service web, soit aller à la page d’ajout de messages, soit il s’authentifie.
L’authentification donne lieu à deux résultats dépendant du type de l’utilisateur : s’il
s’agit de l’administrateur, il sera dirigé vers la page qui listera les comptes du système
pour qu’il choisisse celui dont il veut suivre les terminaux ; pour tout autre utilisateur, il
sera dirigé vers une page d’accueil qui lui résumera quelques-unes de ses informations
personnelles et un lien indiquant nombre de terminaux qu’il peut suivre. Ce lien le
mènera à la page qui liste les terminaux de son compte. Lorsque ce dernier choisit un
terminal sur cette page, un menu contextuel apparaît contenant les différentes opérations
que l’on peut effectuer avec un terminal. S’il choisit d’envoyer un message au terminal,
alors il sera dirigé vers la page qui liste les messages du système. S’il choisit le localiser
le terminal, alors il sera dirigé vers une page indiquant la position du terminal sur une
carte. S’il choisit d’obtenir les derniers évènements du terminal alors il sera dirigé vers
la page qui liste ces évènements. Une fois sur cette page, il peut changer l’intervalle de
temps pour les plages horaires (car les évènements affichés sont ceux envoyés au serveur
à partir de minuit jusqu’à l’heure de consultation). Une fois qu’il est en possession de
ces évènements, il peut alors les placer sur une carte, le résultat étant une représentation
du trajet du terminal dans l’intervalle de temps choisi. S’il choisit d’avoir des détails sur
le terminal, alors une page contenant certaines informations (vitesse, odomètre, quantité
d’essence …) sur le terminal sera affichée.
III.5) Implémentation
III.4.1) Android
Android est un système d’exploitation pour appareils mobiles (tablettes,
smartphones, notebook, automobiles). Il a été développé par la startup Android Inc. et
racheté par Google en 2005. Android offre de nombreuses possibilités pour le
développement d’applications mobiles en proposant un environnement de
développement libre basé sur le noyau Linux. Il met à la disposition du développeur de
nombreuses librairies à travers son SDK (ici la version 22). Il propose un nombre

31
important d’API, permettant de développer facilement des applications qui interagissent
avec le terminal (caméra, GPS, accéléromètre, messagerie …) [16]. La version utilisée
pour développer aGTS est la 4.2. Les applications Android sont écrites en utilisant le
langage de programmation Java.
III.4.2) Java
Java est un langage de programmation orienté objet et multiplateforme,
développé par Sun Microsystems en 1995. C’est un langage interprété riche en
bibliothèques et en outils qui facilitent le développement de tous les types d’applications
[4]. Nous utiliserons la version 1.7 du JDK (Java Development Kit) fournie par Sun
Microsystems.
III.4.3) Les Google services
Le système d’exploitation Android est détenu par le géant de l’informatique
Google. Ce dernier met à la disposition des développeurs un certain nombre de services.
Ceux-ci ne sont pas inclus dans la plateforme Android mais sont utilisable par la plupart
des terminaux. Parmi ces services, celui qui nous intéresse est le service Google Maps.
Car il permet d’ajouter une carte à notre application, et de gérer son contenu [13].
III.4.4) Les services web ReST
ReST (Representational State Transfert) est un moyen qui permet d’utiliser les
protocoles standards du web pour consommer les services web. C’est un style
d’architecture pour systèmes distribués dont le terme a été introduit par Roy Fielding
dans sa thèse en 2000. La communication entre entités dans un système reparti se fait
en utilisant de simples messages. Avec ReST, les messages sont de simples requêtes
HTTP sans encodages. La conséquence directe de ce fait est que nous pouvons avoir des
entités d’implémentation totalement indépendantes dans un même système [6].
III.4.5) XML
XML est un langage balisé qui dérive de SGML (Standard Generalized Markup
Language) et du HTML (HyperText Markup Language). C’est un format de document
texte et est utilisé aussi bien pour le stockage de données que pour la transmission de
données entre applications [13].

32
III.4.6) L’IDE Eclipse et l’ADT Android
Eclipse est un IDE développé par IBM, gratuit et disponible pour la plupart des
systèmes d'exploitation. Il simplifie la programmation en proposant un certain nombre
de raccourcis et d'aide à la programmation. Android Development Tools (ADT) est un
plugin conçu pour faire d’Eclipse une IDE de développement d’applications Android.
III.4.7) L’émulateur AVD
Le manageur AVD (Android Virtual Device) nous donne une interface graphique
dans laquelle nous pouvons créer des terminaux virtuels Android et effectuer nos tests.
III.5) Utilisation
Cette application est une application cliente de GTS Enterprise pour mobile. Les
services qu’elle offre sont mis à disposition par GTS. Avec cette application, l’utilisateur
pourra :
- retrouver le trajet d’un véhicule sur une carte (Google Map par exemple) ;
- localiser un terminal ;
- commander un terminal ;
- obtenir les derniers évènements d’un terminal.

33
CHAPITRE IV : RESULTATS ET COMMENTAIRES
Le chapitre précédent présentait le cahier des charges et l’architecture de
l’application cliente de GTS. Ici, nous présentons les résultats obtenus suite à
l’implémentation des différentes fonctionnalités.
Note : les données utilisées pour le test de notre application proviennent d’un
compte Demo qui vient avec l’application GTS Enterprise.
IV.1) Authentification et paramètres
IV.1.1) Authentification
Avant d’accéder aux services fournis par l’application, l’utilisateur est amené à
entrer ses paramètres d’authentification. Il s’agit de son nom de compte, du nom
d’utilisateur et du mot de passe. Ces paramètres sont stockés (pas dans une base de
données) sur les champs de saisie et seront utilisés pour la consommation du service
web. Ils identifient l’utilisateur et lui donne accès aux données le concernant. La page
d’authentification est la première qui s’affiche à l’utilisateur lorsqu’il lance
l’application.
Figure 10 : Page d’authentification et de paramètres

34
IV.1.2) Ajout des messages
La communication avec les terminaux est possible grâce à l’envoi des messages
à ceux-ci. La possibilité lui est donnée à l’utilisateur d’enregistrer les messages dans le
système. Ces messages pourront ensuite être envoyés plus tard. Pour accéder à la page
d’ajout de messages, il suffit de cliquer sur le bouton Messages de la page
d’authentification.
Figure 11 : Ajout de messages
L’utilisateur peut saisir le code du message. Il s’agit en réalité du pré-contenu du
message, étant donné qu’il peut le modifier pendant l’envoi. Il peut aussi saisir la
description du message, ça l’aidera dans le choix du message à envoyer.
IV.1.3) Paramètres
Il s’agit ici de renseigner les paramètres nécessaires pour la connexion au serveur.
La figure 12 montre la page de paramètres. Elle est constituée de deux liens. Le
premier lien permet de définir l’URL (Uniform Ressource Locator) du service web. Le
second quant à lui permet de désactiver la vérification de certificat avant l’établissement
de toute connexion avec le serveur. Cependant cette opération n’est pas conseillée.

35
Figure 12 : Menu de paramétrage
- Page de modification du service web
Figure 13 : Page de modification de l’URL du service web
L’url du service web respecte le format : http(s)://www.domain.com/track/Service
- Page de vérification des informations d’authentification
Figure 14 : Vérification des paramètres d’authentification

36
IV.2) Traquer les terminaux
IV.2.1) Accueil administrateur
L’administrateur a la possibilité de voir la liste des comptes du système. Il pourra
ainsi faire le choix du compte dont il souhaite suivre les véhicules.
Figure 15 : Liste des comptes
Le choix d’un compte conduira à la liste de ses terminaux.
IV.2.2) Accueil utilisateur
L’utilisateur peut voir s’afficher sur cette page son numéro de téléphone, son
adresse email, et un lien indiquant le nombre de terminaux qu’il peut suivre.
Figure 16 : Page d’accueil de l’utilisateur
En cliquant sur ce lien, l’utilisateur arrive sur la page qui liste ces terminaux.

37
IV.2.3) La liste des terminaux
Etant donné que l’on peut avoir plusieurs terminaux pour un même compte,
l’affichage de la liste des terminaux permettra à l’utilisateur de choisir celui qu’il veut
suivre.
Figure 17 : Liste des terminaux
IV.2.4) Suivi de terminaux
- Le menu
Figure 18 : Menu contextuel
La figure 18 liste les opérations que l’on peut réaliser avec un terminal (sept
opérations au total).

38
Figure 19 : Localisation d’un terminal
La position du terminal est repérée grâce au système de GPS qu’il possède. Le
système se charge ensuite de positionner le terminal sur une carte.
- Envoyer des messages aux terminaux
L’onglet Envoyer message permet d’envoyer directement des commandes à un
terminal via SMS. Le message doit au préalable être enregistré.
Tout d’abord, l’utilisateur est amené à choisir parmi les messages enregistrés celui
qu’il souhaite envoyer au terminal. Ceci se passe sur la page suivante :
Figure 20 : Liste des messages du système

39
Une fois le message sélectionné, il choisit avec quelle application de messagerie
il souhaite envoyer le message (Hangouts de Google, Skype, Viber, et l’application
de messagerie de l’appareil), bien sûr ça dépend de ce qui est installé sur l’appareil.
Figure 21 : Liste des applications de messagerie de l’appareil
La figure suivante montre le message en mode édition pour envoi. Le champ de
contact est déjà rempli avec le numéro de contact du terminal, ainsi que le champ du
contenu du message qui est pré-rempli avec le message sélectionné.
Figure 22 : Message en édition pour envoi
- Derniers évènements du terminal et représentation du trajet

40
L’onglet Obtenir les évènements récents permet comme son nom l’indique, d’obtenir
les derniers évènements que le terminal a envoyé. On pourra voir par exemple la vitesse
du mobile (en bleu), son adresse et l’heure à laquelle il était à cette position.
On pourra à partir de ces évènements retracer le parcours du terminal sur une carte.
Figure 23 : Derniers évènements de terminal
Si l’utilisateur veut d’autres évènements, il pourra cliquer sur le calendrier au fond
supérieur droit de la page des évènements (figure 23) pour spécifier l’intervalle de temps
et le nombre d’évènements maximal à retenir.
Figure 24 : Choix de l’intervalle de temps pour les évènements

41
Un clic sur la carte au coin supérieur droit de la page des évènements (figure 23)
place ces différents points sur une carte, représentant ainsi une portion du trajet du
terminal.
Figure 25 : Trajet du terminal
- Vitesse du terminal sur un point du trajet
Il suffit juste de toucher un marqueur sur la carte pour voire cette vitesse.
Figure 26 : Vitesse du terminal

42
IV.3) Comparaison entre aGTS et d’autres applications clientes
de GTS Enterprise
IV.3.1) CelltacGTS
CelltracGTS™/Free est l’application cliente officielle de GTS Enterprise pour
Android. Il a été développé par GEOTelematic. Il est disponible en téléchargement dans
le store de Google (Google play).
Figure 27 : Celltrac/Free v1.4.3
IV.3.2) OpenGTS Client
OpenGTS Client est unr application cliente de GTS Enterprise disponible pour
les plateformes Android et IOS. Il existe en version payante et gratuite. Cette application
capture les informations de géolocalisation et les envois au serveur GTS. Il est
disponible en téléchargement sur Google play.

43
Figure 28 : OpenGTS client
Le tableau ci-dessous nous présente une comparaison entre aGTS et les
applications citées plus haut.
Tableau 15 : Comparaison entre aGTS et les autres clients de GTS
Fonctionnalités aGTS CelltracGTS OpenGTS
Client
Localiser un terminal de GTS Oui Non Non
Envoyer des messages aux
terminaux
Oui Non Non
Lister les terminaux suivis avec
GTS
Oui Non Non
Lister les évènements d’un
terminal
Oui Non Non
Représenter le trajet d’un
terminal
Oui Non Non
Supporte plusieurs plateformes Non Non Oui
Envoyer des évènements au
serveur
Non Oui Oui
Récupérer les paramètres du
terminal (vitesse, coordonnées
…)
Non Oui Oui
Pour résumer cette comparaison nous disons simplement que aGTS a des
fonctionnalités totalement opposées des autres applications clientes de GTS dans ce sens

44
que aGTS ne se contente que de récupérer des données sur GTS, alors que les autres
applications peuvent servir de fournisseur de données à GTS.

45
CONCLUSION ET PERSPECTIVES
Rappelons que l’objectif de ce travail est de rendre accessible certaines
fonctionnalités de GTS Enterprise sur les appareils mobiles. Pour cela, nous avons
réalisé une application pour les plateformes mobiles Android utilisant les services web
offerts par GTS pour fonctionner.
La réalisation de l’application a débuté avec la compréhension du contexte du
projet. Ensuite, nous avons suivi la méthodologie Scrum pour conduire le projet. La
première phase de cette méthodologie nous a permis de dresser le cahier des charges
de l’application. Nous nous sommes ensuite servi de ce cahier des charges pour
modéliser l’application grâce à UML et enfin implémenter les différentes
fonctionnalités désirées. Ces fonctionnalités sont : positionner le terminal sur une
carte, envoyer des messages aux terminaux suivi via SMS, voir la liste des véhicules
qu’on peut suivre avec GTS Enterprise, avoir accès aux derniers évènements d’un
terminal, tracer une partie de son trajet sur une carte. Toutes ces fonctionnalités ont
été réalisées avec succès.
Les interfaces utilisateur de l’application ont été réalisées en tenant compte des
contraintes des équipements utilisateur. Il est à noter que les appareils mobiles ont
généralement des écrans de petites tailles. Aussi, l’application tient compte des
capacités limitées des appareils mobiles en termes de consommation de mémoire.
En perspective, d’autres fonctionnalités pourraient être ajoutées pour faciliter
l’utilisation d’aGTS, notamment un sélecteur de terminaux dans la page qui liste les
terminaux. En plus l’application pourrait être développée pour les autres plateformes
mobiles, notamment IOS d’Apple et les Windows phone.

46
BIBLIOGRAPHIE
[1] Agile Alliance, Manifeste pour le développement Agile de logiciels. (2014,
Septembre 30, 12 :15). Récupéré sur http://agilemanifesto.org/iso/fr/
[2] Android developers, Google services. (2014, Juillet 22, 16 :15). Récupéré sur
http://developer.android.com/google/
[3] CERFI, Mobilité en entreprise: avantages, inconvénients, nos solutions! (2014,
Aout 29, 17 :10). Récupéré sur http://www.cerfi.ch/fr/CeRFI/Actualites/A-la-
une/Mobilite-en-entreprise-avantages-inconvenients-nos-solutions.html
[4] Claude Delannoy, Programmer en Java, EYROLLES, Paris Cedex 05, France, 5e
édition, 2008
[5] Département Informatique - Université Nice Sophia Antipolis, L’informatique
mobile. (2014, Octobre 1er
, 17:10). Récupéré sur
http://deptinfo.unice.fr/~renevier/corrections/theseHTML/informatiquemobile.html
[6] Developpez.com, Introduction aux services web Rest avec WCF 3.5. (2014, Juillet
20, 15:30). Récupéré sur http://badger.developpez.com/tutoriels/dotnet/web-service-
rest avec-wcf-3-5/
[7] Developpez.com, Présentation des méthodes agiles et Scrum. (2014, Juillet 25,
16 :30). Récupéré sur http://ineumann.developpez.com/tutoriels/alm/agile_scrum/
[8] Ekito, Application mobile : web ou natif ? (2014, Juillet 20, 10 :15). Récupéré sur
http://www.ekito.fr/people/application-mobile-web-ou-natif/
[9] Houda Bagane, Analyse des principes du génie logiciel au niveau du développement
agile, Mémoire présenté comme exigence partielle de la maîtrise en informatique,
Université du Québec, Montréal, Mars 2011. Récupéré à partir du lien :
http://www.archipel.uqam.ca/4010/1/M12003.pdf
[10] IDC, Smartphone Momentum Still Evident with Shipments Expected to Reach 1.2
Billion in 2014 and Growing 23.1% Over 2013, According to IDC. (2014, Août 28,
16:34). Récupéré sur http://www.idc.com/getdoc.jsp?containerId=prUS24857114

47
[11] Mark Phillips, GeoTelematic Tutorial and Guide for the GTS Enterprise, édité et
mis à jour par Martin D. Flynn, 15 Mai 2011. Récupéré à partir du lien
http://www.geotelematic.com/docs/GTSEnterprise_Tutorial.pdf
[12] Martin D. Flynn, GeoTelematic Web Services Guide, 2011. Récupéré à partir du
lien http://www.geotelematic.com/docs/GTSEnterprise_WebService.pdf
[13] Olivier Carton, L’essentiel de XML : Cours XML, Paris, France, 2014
[14] Orange, La géolocalisation : définition, usages et limites. (2014, Juillet 11, 15 :30).
Récupéré sur le lien http://www.orange-business.com/fr/blogs/relation-client/contact-
multicanal/la-geolocalisation-definition-usages-et-limites
[15] Pascal Roques, UML2 par la pratique, EYROLLES, Paris Cedex 05, France, 5e
édition, 2006
[16] Reto Meier, Professional Android Application Development, Wrox, Indianapolis,
Etats-Unis, 2009
[17] Software Engineering Standards Committee. Guide de l'IEEE pour la
Spécification d'Exigences de Système. IEEE-SA Standards Board, 1998

Memoire version finale kenfack

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Memoire version finale kenfack

Semelhante a Memoire version finale kenfack (20)

Memoire version finale kenfack