MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR

ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITÉ DE SOUSSE
‫المعهد العالي للعإلماية و تاقنيات التاصال بحمام سوسة‬

INSTITUT SUPÉRIEUR D’INFORMATIQUE

ET DES TECHNOLOGIES DE COMMUNICATION – HAMMEM SOUSSE

Département Réseaux et Multimédia

MÉMOIRE DE PROJET DE FIN D’ÉTUDES

Présenté en vue d’obtention du diplôme de Licence Appliqué

Technologies des réseaux informatiques

Conception et développement d’une application mobile pour

la détection des embouteillages

Réalisé par :

AMRI Amine

Encadré par :

Dr. BRAHEM Zaki

Année universitaire 2016-2017

 MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR

ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITÉ DE SOUSSE
‫المعهد العالي للعإلماية و تاقنيات التاصال بحمام سوسة‬

INSTITUT SUPÉRIEUR D’INFORMATIQUE

ET DES TECHNOLOGIES DE COMMUNICATION – HAMMEM SOUSSE

Département Réseaux et Multimédia

MÉMOIRE DE PROJET DE FIN D’ÉTUDES

Présenté en vue d’obtention du diplôme de Licence Appliqué

Technologies des réseaux informatiques

Réalisé par :

AMRI Amine

Encadrant :……………………………. Date :………………….. Signature :………………

Année universitaire 2016-2017

 DÉDICACES
Je dédie ce travail
À
Ma Famille
Et à toute personne
Qui
M’a soutenu de prés ou de loin.
Merci.
 REMERCIEMENTS

Je tiens à exprimer ma profonde reconnaissance et mes immenses remerciements à mon

encadrant Dr. BRAHEM Zeki, pour l’aide qu’il a apporté depuis le début et ses conseils qui ont facilité
mon travail. Vous avez bien voulu me confier ce travail riche d’intérêt. Vous n’avez pas hésité de me
guider si j’avais besoin de votre aide. Je saisis cette occasion pour vous exprimer ma profonde gratitude
tout en témoignant mon respect.

Profitant par la même occasion pour remercier tous les enseignants de l’ISITCom et
spécifiquement mes enseignants tout au long de mes trois années de formation, veuillez trouver ici
l’expression de ma respectueuse considération et ma profonde admiration pour toutes vos qualités
scientifiques et humaines.

Mon école qui décolle, ISITCom, MERCI.

AMRI Amine
Table des matières
Introduction Générale..............................................................................................................................12
Chapitre 1: Étude préalable.....................................................................................................................13
1 Introduction....................................................................................................................................14
2 Cadre général du projet:.................................................................................................................14
3 Présentation du projet :...................................................................................................................14
3.1 Problématique :.......................................................................................................................14
3.2 L’existant :..............................................................................................................................14
3.2.1 Waze :..............................................................................................................................15
3.2.2 Google Traffic :...............................................................................................................16
3.2.3 RTS Trafic:......................................................................................................................17
3.3 Critique de l’existant :............................................................................................................17
4 Solution proposée :.........................................................................................................................17
5 Conclusion :....................................................................................................................................17
Chapitre 2 : Analyse et spécification des besoins....................................................................................18
1 Introduction....................................................................................................................................19
2 Spécification des besoins :.............................................................................................................19
2.1 Identification des acteurs :......................................................................................................19
2.2 Spécification des besoins fonctionnels :.................................................................................19
3 Modélisation des fonctionnalités :..................................................................................................20
3.1 UML, définition:.....................................................................................................................20
3.2 Diagrammes de cas d’utilisation “Use Case” :.......................................................................21
3.2.1 Définition :......................................................................................................................21
3.2.2 Les cas d’utilisation de l’application :............................................................................21
3.2.2.1 Diagramme cas d’utilisation « vue globale » :........................................................21
3.2.2.2 Diagrammes détaillés par acteur :...........................................................................22
3.2.2.2.1 Diagramme de cas d’utilisation du Conducteur :............................................22
3.2.2.2.2 Diagrammes des cas d’utilisation du Conducteur_Enregistré :.......................23
4 Conclusion :....................................................................................................................................31
Chapitre 3 : Étude conceptuelle...............................................................................................................32
1 Introduction :..................................................................................................................................33
2 Conception générale :.....................................................................................................................33
2.1.1 L’architecture physique :.................................................................................................33
2.1.1.1 Les architectures physiques courantes :..................................................................34
2.1.1.2 L’architecture physique 3-tiers :..............................................................................39
2.2 La conception détaillée de la solution :..................................................................................40
2.3 Vues statiques :.......................................................................................................................40
2.3.1 Diagrammes des classes :................................................................................................40
Diagrammes des classes de l’application mobile :................................................................42
2.3.1.1 Diagrammes des classes du Backend:.....................................................................44
2.3.2 Conception de la base des données :...............................................................................47
2.4 Aspect dynamique :.................................................................................................................49
2.4.1 Diagrammes d’activité :..................................................................................................49
2.4.1.1 Diagramme d’activité de l’utilisateur :....................................................................49
2.4.2 Diagramme des séquences :............................................................................................52
2.4.2.1 Diagramme des séquences « Enregistrement » :.....................................................52
2.4.2.2 Diagramme des séquences « Authentification » :...................................................54
 2.4.2.3 Diagramme des séquences « ChoisirDestination » :...............................................57
3 Conclusion:.....................................................................................................................................59
Chapitre 4 :Étude de l’environnement de développement.......................................................................60
1 Introduction....................................................................................................................................61
2 L’environnement de développement :............................................................................................61
2.1 L’environnement matériel :.....................................................................................................61
2.2 L’environnement logiciel :......................................................................................................61
2.3 Les outils de développement du Backend :............................................................................62
2.3.1 Python :...........................................................................................................................62
2.3.2 Web.py............................................................................................................................68
2.3.3 JSON :.............................................................................................................................70
2.4 Les outils de développement de l’application mobile :..........................................................73
2.4.1 Java :...............................................................................................................................73
2.4.2 Le SDK Android :...........................................................................................................73
2.4.3 AsyncHttpClient :............................................................................................................74
2.4.4 Les services Google Play :..............................................................................................74
2.4.5 L’API v3 Google Maps :.................................................................................................75
3 Conclusion:.....................................................................................................................................75
Phase de réalisation, évaluation et critique des limitations:.....................................................................76
1 Introduction:...................................................................................................................................77
2 Travail réalisé:................................................................................................................................77
2.1 Authentification :....................................................................................................................77
2.2 Créer compte :.........................................................................................................................80
2.3 L’interface du carte :...............................................................................................................81
2.4 Le Backend :...........................................................................................................................90
3 Évaluation et critique :...................................................................................................................90
4 Conclusion :....................................................................................................................................91
Conclusion Générale................................................................................................................................92
Table des figures
Logo de Waze...........................................................................................................................................16
Interface Waze..........................................................................................................................................16
Interface Google Traffic...........................................................................................................................17
Logo du RTS Trafic..................................................................................................................................18
Types des diagrammes UML version 2.0.................................................................................................22
Diagramme de cas d'utilisation global.....................................................................................................23
Cas d'utilisation "Créer compte"..............................................................................................................24
Cas d'utilisation Gérer compte.................................................................................................................24
Cas d'utilisation Gérer destination...........................................................................................................25
Cas d'utilisation Suivre position...............................................................................................................25
Architecture générale de la solution.........................................................................................................28
Architecture 2-tiers..................................................................................................................................29
Architecture 3-tiers..................................................................................................................................31
Architecture 3-tiers..................................................................................................................................32
Diagramme des classe de l'application mobile........................................................................................34
Diagramme de classe du Backend............................................................................................................37
Diagramme relationnel de la base des données........................................................................................41
Diagramme d'activité...............................................................................................................................46
Diagramme des séquences "Enregistrement"...........................................................................................48
Diagramme des séquences "Authentification".........................................................................................51
Diagramme des séquences "ChoisirDestination".....................................................................................54
Exemple d'une classe avec ses méthodes.................................................................................................58
Mots réservés au langage.........................................................................................................................59
"Hello world! en web.py"........................................................................................................................61
Objet en JSON.........................................................................................................................................62
Tableau en JSON......................................................................................................................................63
Types des valeurs.....................................................................................................................................63
Exemple JSON.........................................................................................................................................64
"Hello world!" en Java.............................................................................................................................65
Code AsyncHttpClient.............................................................................................................................66
Exemple du reverse geocoding................................................................................................................67
L'interface d'authentification....................................................................................................................69
Mot de passe vide.....................................................................................................................................70
Mot de passe de longueur inférieure à six caractères...............................................................................71
Interface de l'activité "Créer compte"......................................................................................................72
Interface initiale du carte..........................................................................................................................74
Carte centrée sur la position courante......................................................................................................75
La destination est marquée et le trajet est en rouge.................................................................................76
Embouteillage sur la carte........................................................................................................................77
La fonctionnalité du recherche.................................................................................................................78
Choix d'un autre trajet lors d'un embouteillage........................................................................................79
Un trajet alternatif....................................................................................................................................80
Le Backend en écoute..............................................................................................................................81
Requête d'authentification par l'application.............................................................................................81
Liste des tableaux
Tableau 1: Besoins fonctionnels par acteur..............................................................................................20
Tableau 1: Caractéristiques matérielles de l’environnement du production............................................47
Tableau 2: Outils logiciels........................................................................................................................47
 Introduction Générale
Le smartphone est devenu un élément essentiel de communication, de connexion, du jeu vidéo et
de navigation. Ceci a permis de développer des solutions à des problèmes diverses et complexes.

Android est couramment la plateforme dominante dans le marché mobile avec une pourcentage de
88 % au troisième trimestre de l’année 2016. Et avec un besoin de navigation rapide à travers du trafic
routier embouteillé, un smartphone Android devient une cible de développement des solutions de tel type
de navigation routière.

Dans ce contexte, s’inscrit notre projet qui s’intitule « Conception et développement d’une
application mobile pour la détection des embouteillages » qui a comme but de permettre à un individu de
savoir en temps réel où il y a des embouteillages et si possible de trouver un trajet plus rapide que le trajet
initiale embouteillé.

Notre application sera destinée au smartphones Android et s’appuyant sur l’API Google Maps,
l’API Google Maps Directions et un web service RESTful comme étant le Backend qui fait les calcules
complexes et gère l’authentification et les données concernant l’état du trafic, il est basé sur le framework
web.py.

Ce rapport est un synthèse des taches réalisées tout au long de la période de développement de la
solution. Il est découpé en cinq chapitres :

1. Étude préalable : Présenter les besoins concernant le problème du trafic embouteillé et

détailler la problématique, son cadre général et l’apport du projet.

2. Étude de cas : Présenter la spécification et l’analyse des besoins fonctionnels et non

fonctionnels de la solution.

3. Étude conceptuelle : Détailler la conception de l’application en UML.

4. Étude de l’environnement de développement : Présenter l’environnement matériel et

logiciel et le framework web.py.

5. Phase de réalisation, évaluation et critique des limitations : Présenter les taches de

réalisation, l’évaluation du résultat et critiquer les limitations de la solution finale.
Chapitre 1: Étude préalable
1. Introduction

2. Présentation du projet

3. Solution proposée

4. Conclusion
 1 Introduction
Dans ce chapitre, nous allons clarifier le contexte de notre projet. Nous introduisons
premièrement, le cadre général du projet. Par suite, nous donnons une présentation générale du projet en
expliquant la problématique lui donnant besoin. Pour mieux planifier notre travail, nous abordons dans
une étape subséquente à décrire et critiquer l'existant ainsi que la solution proposée. Nous terminons à la
fin par la présentation de l'approche de développement utilisée et nous présentons la démarche suivie pour
l'accomplissement de notre travail.

2 Cadre général du projet:

Ce projet s’inscrit dans le cadre de la préparation du projet de la fin d’études, en vue de l'obtention
du diplôme appliquée en informatique, option réseaux informatiques, de l’Institut Supérieur
d'Informatique et des Techniques de Communication Hammem Sousse.

3 Présentation du projet :
Nous présentons dans cette partie le contexte de notre projet. Puis, nous expliquons la
problématique suivie par la critique de l’existant et à la fin citer la solution proposée.

3.1 Problématique :
Il est difficile de choisir un trajet rapide pour le transport. Ceci fait naître la nécessité de concevoir
une application qui assurera :

• Le choix du trajet le plus court.

• Le choix du trajet le moins embouteillé

3.2 L’existant :
Il existe des applications qui répondes à la problématique. Elles sont :
3.2.1 Waze :
Waze est l’application qui a le plus grand nomber des utilisateurs. Elle fournit le chemin le plus
court avec des notifications de l’état routière (embouteillage, accident, etc ..).

Fig 1: Logo de Waze

Fig 2: Interface Waze

3.2.2 Google Traffic :
Google trafic affiche l’état du trafic en se reposant sur les données GPS des terminaux mobiles.
Elle affiche des zones colorées selon l’état du trafic (rouge : embouteillé, vert pistache : moins embouteillé,
vert foncé : chemin rapide).

Fig 3: Interface Google Traffic

3.2.3 RTS Trafic:
Elle donne les informations de la situation du trafic sur le réseau routier suisse en temps et sur les
places de parc disponibles dans les parkings des grandes ville de suisse. Elle permet aussi de trouver la
position actuelle de l’utilisateur.

Fig 4: Logo du RTS Trafic

3.3 Critique de l’existant :

Ces applications ne permettent pas de connaître le statut du trafic en Tunisie est spécifiquement le
trafic sur les réseaux secondaires.

4 Solution proposée :
Pour résoudre le problème, nous avons pensé à concevoir une application mobile sur la plateforme
Android qui permettra à un conducteur de trouve le chemin le plus court vers sa destination et de
contourner le trajets embouteillés.

5 Conclusion :
Ce chapitre a présenté la problématique et le besoins que notre solution doit les remplir. Le
chapitre qui suit fait décrire l’analyse et la spécification des besoins.
Chapitre 2 : Analyse et spécification des besoins
1. Introduction

2. Spécification des besoins

3. Identification des acteurs

4. Modélisation des fonctionnalités

5. Conclusion
1 Introduction
Suite à la proposition d’une solution théorique, nous allons aborder dans ce chapitre la phase de
spécification des besoins. Cette phase consiste à analyser le projet et exprimer ses exigences et ses besoins
pour assurer le développement d’une solution satisfaisante et utilisable d’où le succès du projet.

Dans ce chapitre, nous présentons la spécification des besoins auxquels doit répondre notre
application en tenant compte des acteurs qui l'utilisent. Puis, nous faisons une analyse compréhensive de
ces besoins fonctionnels et non fonctionnels, en utilisant la modélisation par les diagrammes de cas
d'utilisation.

2 Spécification des besoins :

Il existe deux types des besoins qui doivent être étudiés :

◦ Besoins fonctionnels : Des besoins qui sont au centre de fonctionnalités désirables.

◦ Besoins non fonctionnels : Des besoins qui sont secondaires.

Les étapes de spécification des besoins sont :

1. L’identification des acteurs.

2. Énumération des fonctionnalités offertes aux utilisateurs.

Pour achever ces deux étapes nous allons rédiger un description contextuelle claire de besoins
fonctionnelles et non fonctionnelles de l’application.

2.1 Identification des acteurs :

Un acteur est une représentation de l’entité externe qui agit sur le système (soit opérateur, soit un
autre système…). Il peut savoir et modifier l’état du système. Le système fournit un service qui
correspond à son besoin.

Les acteurs qui interagissent avec l’application sont :

▪ Le conducteur : Il a un compte qui lui permet de choisir une destination, supprimer la

destination choisie et choisir un trajet alternatif s’il y a un embouteillage.

2.2 Spécification des besoins fonctionnels :

Les besoins fonctionnels introduisent les fonctionnalités sans lesquelles le système ne devient pas
opérationnel. Il sont la raison « d’être de l’application ».
 Tableau 1: Besoins fonctionnels par acteur
Acteur Fonctionnalités
Conducteur • L’authentification:
◦ Permettre à l’acteur de s’authentifier en
utilisant un nom d’utilisateur (Login) et
un mot de passe.
• Gestion de profil :
◦ Permettre à l’acteur de créer un compte
◦ Permettre à l’acteur de consulter les
informations de son compte.
◦ Permettre à l’acteur de modifier l’email,
le nom d’utilisateur et le mot de passe.
• Gestion du destination :
◦ Permettre à l’acteur de choisir une
destination
◦ Permettre à l’acteur de supprimer la
destination.

3 Modélisation des fonctionnalités :

3.1 UML, définition:
UML, Unified Modeling Language, est un langage de modélisation graphique qui à l’aide d’un
logiciel de modélisation permet de créer de graphes modèles d’un système informatique (l’application dans
notre cas) indépendamment du langage et de la méthodologie d’implémentation.

UML 2.0 définie treize types de diagrammes répartis sur trois catégories :

▪ Diagrammes des structures : Englobe le diagramme des classes, le diagramme des

objets, le diagramme des composantes, le diagramme de la structure composite, le

diagramme des paquetages et le diagramme de déploiement.

▪ Diagrammes de comportement : Englobe le diagramme de cas d’utilisation, le

diagramme d’activité et le diagramme état-transition.

▪ Diagrammes des interactions :est une sous catégorie des diagrammes de

comportement. Contient le diagramme des séquences, le diagramme de communication,

le diagramme de temps et le diagramme global d’interaction.

 Fig 1: Types des diagrammes UML version 2.0

3.2 Diagrammes de cas d’utilisation “Use Case” :

Un cas d’utilisation décrit les interactions qui permettent à l’utilisateur d’atteindre son objectif.

3.2.1 Définition :
Un diagramme de cas d’utilisation donne un vision globale du comportement d’un système donné.

3.2.2 Les cas d’utilisation de l’application :

En ce qui suit, nous allons présenter une vue globale des différents cas d’utilisation puis nous les
détaillerons chacun dans son diagramme. Enfin, nous présenterons les diagrammes des séquences des
actions principales effectuées par l’acteur.

3.2.2.1 Diagramme cas d’utilisation « vue globale » :

Un utilisateur peut créer un compte pour devenir un utilisateur enregistré qui peut gérer la
destination (ajouter, supprimer, changer) et gérer son compte (changer l’adresse e-mail, le nom
d’utilisateur ou le mot de passe).
 Donc les cas d’utilisation sont :

▪ Créer compte

▪ Gérer compte

▪ Gérer destination

Fig 2: Diagramme de cas d'utilisation global

Nous allons détailler chaque cas d’utilisation en se qui suit.

3.2.2.2 Diagrammes détaillés par acteur :

Si dessous c’est détaillé les cas d’utilisation pour les acteurs : Conducteur et
Conducteur_Enregistré.

3.2.2.2.1 Diagramme de cas d’utilisation du Conducteur :

Un Conducteur peut créer un compte en fournissant un nom d’utilisateur, un e-mail et un mot de
passe(de longueur ≥ 6). La figure ……. visualise ce cas.
 Fig 3: Cas d'utilisation "Créer compte"

3.2.2.2.2 Diagrammes des cas d’utilisation du Conducteur_Enregistré :

Les cas d’utilisation d’un « Conducteur_Enregistré » sont :

▪ Gérer Compte : Il s’agit de modifier le nom d’utilisateur, le mot de passe ou

l’adresse e-mail

▪ Gérer destination : Il s’agit de choisir une destination, la supprimer ou choisir un

autre trajet si il est fournit d’après l’API GoogleMaps lors d’un embouteillage.

▪ Suivre position : C’est un cas d’utilisation qui répond à un besoin non fonctionnel.
Il s’agit de permettre à l’utilisateur de suivre sa position en temps réel.

Gérer Compte :

Fig 4: Cas d'utilisation Gérer compte

Gérer destination :

Fig 4: Cas d'utilisation Gérer destination

Un utilisateur ne peut supprimer une destination que s’il a choisi une destination à priori.

S’il y a un embouteillage sur le trajet, l’utilisateur a la possibilité de choisir un trajet alternatif s’il
est fourni de l’API GoogleMaps.

Suivre position :

Fig 5: Cas d'utilisation Suivre position

4 Conclusion :
Nous avons présenté les différent besoins fonctionnels et non fonctionnels que l’application doit les
répondre. En ce qui suit, nous décrivons la conception de l’application.
Chapitre 3 : Étude conceptuelle
1. Introduction

2. Conception générale

3. Conception détaillé

4. Conclusion
1 Introduction :
La conception est une phase vitale du développement de l’application. Elle permet de définir les
différents modules de l’application et de clarifier l’architecture de cette dernière.

Nous allons présenter l’architecture générale de l’application. Puis nous justifierons nos choix
architecturales. Enfin, nous présenterons l’abstraction orientée objet de l’application et du Backend, les
diagrammes entité-relation de la base des données, les diagrammes de séquence et les diagrammes
d’activités.

2 Conception générale :
La solution est structurée sur deux composantes :

▪ L’application mobile : affiche le trajet de transport selon une destination et la position

courante. Notifier l’utilisateur lors d’un embouteillage.

▪ Le service web (RESTful backend) : fournit les données, assure l’authentification et fait les
calculs nécessaires.

La figure si dessous visualise l’architecture générale :

Fig 1: Architecture générale de la solution

2.1.1 L’architecture physique :

La distribution logique de la solution n’est qu’une abstraction logiciel sur une couche physique.
Alors, il faut bien avoir une idée claire sur la distribution physique de la solution. En ce qui suit nous
allons présenter les différentes architectures physiques.
2.1.1.1 Les architectures physiques courantes :
Parmi les différentes architectures physiques, les plus utilisées sont :

▪ L’architecture 1-tiers :

En une architecture 1-tiers, les couches logicielles tournent sur une seule
composante matérielle. Alors on parle d’un système centralisé.

▪ L’architecture 2-tiers :

En une architecture 2-tiers, les composantes logicielles sont distribuées sur deux
tiers matériels, un tiers client et un tiers de données. Alors on parle d’un système distribué.

Fig 2: Architecture 2-tiers

▪ Architecture 3-tiers :

En une architecture 3-tiers, les composantes logicielles sont distribuées sur trois
tiers matériels :

• Tiers client : Il présente la couche présentation de l’application. (interface

graphique)

• Tiers métier : Il comporte la couche métier de l’application responsable à faire

les opérations logiques ,les calcules nécessaires et la validation des données.

• Tiers des données : Il comporte la couche d’accès au données de l’application

qui fait les opérations CRUD (create, read, update et delete).

Fig 3: Architecture 3-tiers

 2.1.1.2 L’architecture physique 3-tiers :
L’architecture la plus convenable pour notre solution est celle des 3-tiers. Son principe est simple
comme nous avons décrit en si dessus. L’application mobile va tourner sur un smartphone Android, le
Backend(RESTful) va utiliser le framework web.py (basé sur le langage python) et nous allons utilisé
SQLite comme un DBMS qui sera interrogé à travers le medium CRUD de web.py.

Fig 4: Architecture 3-tiers

2.2 La conception détaillée de la solution :

Nous allons présenter la conceptions détaillée en utilisant des vues statiques et les autres
dynamiques.

▪ Vues statiques :

• Diagramme des classes.

• Le diagramme ERD de la base des données.Vues dynamiques :

• Diagrammes d’activité.

• Diagrammes des séquences.

2.3 Vues statiques :
2.3.1 Diagrammes des classes :
Le diagramme des classe appartient à la catégorie des diagrammes de structure d’après la
spécification UML 2.x. Il représente les entités d’un système et leurs interactions, ce qui facilite la
production du code source.

Un diagramme de classe se compose des :

• Entité : Elle modélise un objet (matériel ou information).

• Les attribues d’une entité : Ils modélisent les propriétés d’un objet (ie, couleur de voiture).

• Les méthodes d’une entité : Ils modélisent les opérations qui peuvent être effectuées sur
une instance d’un objet.

• Les relations entre les entités : une entité peut être une généralisation des autres entités
filles(héritage) ou un élément composant d’une autre entité(agrégation/composition) ou
peut communiquer des avec des autres entités (association).
Diagrammes des classes de l’application mobile :
Le diagramme contient les classes les plus importantes, le plus possible indépendamment du
plateforme Android.

Fig 5: Diagramme des classe de l'application mobile

• Map : Présente la carte GoogleMaps sur laquelle sera affiché la position courante de l’utilisateur
(en utilisant le système GPS du mobile), la destination, le trajet entre la position courante et la
destination et tout embouteillage éventuelle.

• Point: C’est un point en espace qui a des coordonnées (type LatLng qui convient à un objet
représentant une latitude et une longitude du point).

• PolyLine: C’est la structure géométrique désigné par l’API GoogleMaps comme un ensemble des
points.

• Trajet: Le trajet est le chemin le plus convenable (plus rapide) entre la position courante de
l’utilisateur et la destination désirée il n’est qu’une abstraction autour d’un PolyLine.
• Embouteillage: Présente un embouteillage du trafic sur un chemin.

Les relations entre les classes sont :

▪ Un Map contient zéro ou un trajet.

▪ Un Map contient zéro ou plusieurs embouteillages.

▪ Un trajet subit zéro ou plusieurs embouteillages.

▪ Un trajet se compose d’un seul et un seul PolyLine.

▪ Un PolyLine se compose d’un ou plusieurs points.

2.3.1.1 Diagrammes des classes du Backend:

Fig 6: Diagramme de classe du Backend

 • Utilisatuer : Présente un utilisateur qui a un id, login, email, mot de passe (password) et un salt
pour sécuriser le hachage du mot de passe.

• Register : C’est la classe responsable à l’enregistrement d’un nouveau utilisateur.

• Login : C’est la classe qui assure l’authentification de l’utilisateur.

• SendCords : C’est la classe qui envoie à l’application mobile les coordonnées d’un embouteillage.

• Coordonnées : C’est la classe qui présente les coordonnées d’un embouteillage (longitude,
latitude).

Les relations entre les classes sont :

▪ Un utilisateur est enregistré une seule est une seule fois.

▪ Un utilisateur s’authentifie une seule est une seule fois.

▪ Le Backend envoie un ou plusieurs coordonnées.

2.3.2 Conception de la base des données :

Puisque nous n’avons pas des autres smartphones qui envoient leurs positions et nous n’avons pas
trouver aucune méthode pour simuler plusieurs smartphones qui font des mouvements sur une carte réelle
nous avons écrit le Backend de façon qu’elle généré des embouteillages sur un rayon aléatoire au prés de la
position courante de l’utilisateur. Alors les embouteillages serons générés « on the fly » d’où la simplicité
de la base des données.

Alors notre base des données contiendra deux entités :

• users : Présente les comptes d’utilisateurs.

• Sessions : Présente les sessions des utilisateurs.

La présentation logique des entités est :

• users(id, username, email, salt)

• sessions(session_id, atime, data)

Fig 7: Diagramme relationnel de la base des données
2.4 Aspect dynamique :
Un diagramme d'activité est l’un des diagrammes comportementaux. Il permet de modéliser un
processus interactif, global ou partiel d’un système donné. Sa présentation est une représentation proche
de l’organigramme. En effet, la modélisation d'un cas d'utilisation par un diagramme d'activité correspond
à sa traduction algorithmique. Il est dit aussi diagramme de navigation. Alors, c’est une représentation
graphique des passages entre les activités.

Dans ce qui suit, nous allons présenter le diagramme d’activité pour un utilisateur de l’application.

2.4.1 Diagrammes d’activité :

2.4.1.1 Diagramme d’activité de l’utilisateur :
L’enchaînement se décrit comme ceci :

• L’utilisateur démarre l’application mobile.

• Pour créer un compte l’utilisateur doit fournir les données

• Pour s’authentifier l’utilisateur doit fournir un login et un mot de passe

• L’utilisateur peut choisir une destination

• Après l’application entre une boucle de mise à jour du position de l’utilisateur et du trajet
entre la position courante et la destination

• Si un embouteillage est détecté, la boucle sera interrompue et l’utilisateur peut choisir un

autre trajet s’il est fourni par l’API GoogleMaps.

• L’utilisateur peut interrompre la boucle pour se déconnecter

Fig 8: Diagramme d'activité
2.4.2 Diagramme des séquences :
Le diagramme des séquence clarifie les interactions entre les différents objets du système. Il
montre séquentiellement l’envoie des messages et des signaux entre les objets. Alors un diagramme

des séquences présente une vue dynamique du cas d’utilisation.

Chaque instance d’un classe, ou notamment un objet a une ligne de vie qui permet d’organiser
chronologiquement les messages envoyés ou reçus par un objet. Un message convient à un l’exécution
d’une méthode.

Le diagramme doit être lue de haut en bas. Au cours du vie d’un objet, il peut être activé ou
désactivé par la réception ou l’envoie d’un message.

Nous présentons en ce qui les trois diagrammes :

▪ Enregistrement (création d’un nouveau compte)

▪ Authentification

▪ ChoisirDestination

2.4.2.1 Diagramme des séquences « Enregistrement » :

• Acteur : Utilisateur

• Pré-Condition : Rien

• Scénario nominal :

1. L’acteur lance l’application.

2. Le formulaire d’authentification s’affiche avec un lien pour créer un nouveau compte

3. L’acteur saisie l’email, le login et le mot de passe.

4. Si les champs sont valides le formulaire d’authentification s’affiche de nouveau.

• Enchaînement alternatif:

4.1 S’il y a des champs vides :

4.2 Une alerte s’affiche.

4.3 S’il y a des champs invalides :

4.5 Une alerte s’affiche.

• Post-condition : L’acteur peut s’authentifier.

La figure présente le diagramme des séquences « Enregistrement ».

Fig 9: Diagramme des séquences "Enregistrement"
2.4.2.2 Diagramme des séquences « Authentification » :
• Acteur : Utilisateur

• Pré-Condition : Rien

• Scénario nominal :

1. L’acteur lance l’application.

2. Le formulaire d’authentification s’affiche

3. L’acteur saisie le login et le mot de passe.

4. Si les champs sont valides la carte centrée sur la position courante de l’utilisateur s’affiche.

• Enchaînement alternatif:

4.1 S’il y a des champs vides :

4.2 Une alerte s’affiche.

4.3 S’il y a des champs invalides :

4.5 Une alerte s’affiche.

• Post-condition : L’acteur peut choisir une destination.

La figure présente le diagramme des séquences « Authentification ».

Fig 10: Diagramme des séquences "Authentification"
2.4.2.3 Diagramme des séquences « ChoisirDestination » :
• Acteur : Utilisateur

• Pré-Condition : L’acteur doit être authentifié

• Scénario nominal :

1. L’acteur tape sur la destination.

2. Le marqueur du destination s’affiche sur la carte.

3. Le trajet primaire s’affiche sur la carte.

• Enchaînement alternatif:

2.1 Si l’API google ne retourne rien :

2.2 Une alerte s’affiche.

4.3 S’il y a embouteillage :

4.5 Une alerte s’affiche et l’acteur peut choisir un trajet alternatif s’il existe.

• Post-condition : Rien.

La figure présente le diagramme des séquences « Choisir destination ».

Fig 11: Diagramme des séquences "ChoisirDestination"
3 Conclusion:
Nous avons présenté l’architecture du solution et les diagrammes des classes (conception statique)
et les diagrammes des séquences (conception dynamique) en UML ainsi que le diagramme entité relation.

En ce qui suit nous présenterons l’environnement du développement et les étapes du production du

code source.
Chapitre 4 :Étude de l’environnement
de développement
1. Introduction

2. L’environnement du développement

3. Conclusion
 1 Introduction
La phase de réalisation est celle qui met en œuvre l’étape du conception. Le choix des outils est
très important et il influence la qualité du produit final. Donc il faut bien choisir les outils adéquats selon
les besoins de production et le résultat qu’on désire achever.

Ce chapitre commence par la description de l’environnement matériel et des outils logiciels utilisés
utilisés pour implémenter l’application mobile et le Backend.

2 L’environnement de développement :
Nous allons présenter la configuration matérielle et logicielle de notre environnement de
production.

2.1 L’environnement matériel :

Le tableau si dessous présente l’environnement matériel :

Tableau 1: Caractéristiques matérielles de l’environnement du production

Modèle HP
Micro Processeur Intel i5
RAM 6 Go
Disque Dur 500Go
Carte Graphique Intel HD Graphics
Écran 15”
Système d’exploitation GNU/Linux

2.2 L’environnement logiciel :

Le tableau si dessous présente les outils logiciels :

Tableau 2: Outils logiciels

Produit développé Outils
Application mobile • IDE : Android studio 2.3
• Système d’exploitation : Android 7 (min
Android 4)
• JDK 8
Backend • Éditeur texte : Vim 8
• DBMS : SQLite 3.8
• Langage : python 3.5
• Serveur Web : serveur web.py
• Framework : web.py
2.3 Les outils de développement du Backend :
2.3.1 Python :
Python est un langage de programmation interprété orienté objet, fonctionnel, dynamiquement
typé crée à la fin des années 80 par Guido Van Ressum. Le langage est en développement continu et
concentré, et est couramment en version 3.x.

La maturité du python (plus que vingt versions), sa flexibilité, sa documentation détaillé et sa

simplicité l’a rendu le choix des plusieurs leaders technologiques comme Google et NASA.

La figure si dessous représente un exemple de deux classes qui servent à faire l’addition, la
soustraction, la multiplication et la division.

Fig 1: Exemple d'une classe avec ses méthodes

La figure si dessous représente les mots réservés au langage.

Fig 2: Mots réservés au langage

2.3.2 Web.py
Web.py est un micro framework de développement web en python conçu par Aaron Schwartz en
2005. Le but de web.py est de rester le plus simple possible pour permettre au développeur de se
concentrer sur son code et non pas le code du web.py. Web.py supporte les templates (non utilisées dans
notre projet).

La figure si dessous présente le plus simple exemple qui utilise web.py :

Fig 3: "Hello world! en web.py"

2.3.3 JSON :
JSON ou javascript object notation est un format d’échange des données et elle est basée sur la
notation des objets en javascript (Ecmascript 3 èmme édition). Avec JSON on peut échanger des données de
type simple ou des objets.

Le format général de JSON est :

‘nom_objet1’ : valeur,

[valeur],

……….. }

La valeur peut être :

• Un autre objet

• Un tableau

• Un nombre

• Vrai / Faux

• null

Un objet, qui est un ensemble de couples nom/valeur non ordonnés. Un objet commence par
{ (accolade gauche) et se termine par } (accolade droite). Chaque nom est suivi de : (deux-points) et les couples
nom/valeur sont séparés par , (virgule).

Fig 4: Objet en JSON

 Un tableau est une collection de valeurs ordonnées. Un tableau commence par [ (crochet gauche) et
se termine par ] (crochet droit). Les valeurs sont séparées par , (virgule).

Fig 5: Tableau en JSON

Une valeur peut être soit une chaîne de caractères entre guillemets, soit un nombre, soit true ou
false ou null, soit un objet soit un tableau. Ces structures peuvent être imbriquées.

Fig 6: Types des valeurs

La figure suivant présente un exemple d’un objet JSON :

Fig 7: Exemple JSON

2.4 Les outils de développement de l’application mobile :
2.4.1 Java :
Java est un langage haut niveau orienté objet et fonctionnel conçue par « Sun microsystems »
(Oracle depuis 2009) en 1995. Java se compile par le JVM(java virtual machine) en code intermédiaire
qui s’appelle bytecode. Java est le langage du programmation le plus populaire selon TIOBE index.

L’API Android est implémenté en Java et nous avons utilisé la version 8 du JDK.

La figure si dessous présente un exemple ‘Hello world !’ en Java :

Fig 8: "Hello world!" en Java

2.4.2 Le SDK Android :

Le SDK (software development kit) Android est un SDK développé par Google dés 2009. Il
contient une série des outils de développement Android qui inclut un outil de débogage, les librairies,
l’émulateur QEMU et la documentation. La version du SDK utilisée est 25 avec un support minimal du
version 15. Le SDK est écrit en Java est il est intégré avec Android studio.
2.4.3 AsyncHttpClient :
AsyncHttpClient est la librairie utilisée pour faire des requêtes asynchrones avec le service web.
Couramment en version 1.4.9 et c’est celle que nous avons utilisé.

Fig 9: Code AsyncHttpClient

2.4.4 Les services Google Play :

Les services Google Play permettent l’exploitation des derniers services offertes par Google,
comme la service GoogleMaps, la service Google+ et les service de position. l’exploitation des services
Google Play nous a permis d’implémenter la carte(play-services-maps:10.2.1) et de récupérer la position
courante de l’utilisateur (play-services-location:10.2.1).
2.4.5 L’API v3 Google Maps :
Grâce à l’API de Google Maps (couramment en version 3) nous avons pût implémenté le
« Reverse Geocoding » qui permet de trouver l’adresse d’un point à partir de ses coordonnées.

Fig 10: Exemple du reverse geocoding

3 Conclusion:
Nous avons présenté l’environnement de développement matériel et logiciel et les outils que nous
avons utilisé pour implémenté l’application mobile et le Backend.

Nous allons aborder le dernier chapitre qui expose le travail réalisé et une évaluation critique du
produit final.
Phase de réalisation, évaluation et critique des
limitations:
1. Introduction

2. Travail réalisé

3. Évaluation et critique

4. Conclusion
1 Introduction:
Ce chapitre présente le produit final et l’expose à l’aide des imprimes écrans. À la fin du chapitre,
nous allons faire une évaluation et un critique des limitations du produit final.

2 Travail réalisé:
L’interface de l’application mobile doit être le plus simple possible et le plus intuitive pour que
l’utilisateur ne trouve pas une difficulté d’utilisation.

2.1 Authentification :
L’interface de l’authentification contient le champ de Login et du mot de passe, l’utilisateur peut
choisir de rester connecté ou de créer un compte. La figure si dessous présente la vue d’authentification :

Fig 1: L'interface d'authentification

 Si le mot de passe est vide ou de longueur inférieur à 6 caractères alors un message d’erreur
s’affiche :

Fig 2: Mot de passe vide

Fig 3: Mot de passe de longueur inférieure à six caractères
2.2 Créer compte :
L’interface de création d’un nouveau compte contient :

▪ Un champ texte pour l’adresse émail.

▪ Un champ texte pour le nom d’utilisateur.

▪ Un champ mot de pass pour le mot de passe

La figure si dessous montre l’interface de cette activité :

Fig 4: Interface de l'activité "Créer compte"

2.3 L’interface du carte :
La carte est centrée initialement au centre au coordonnées (0, 0). Le marqueur violet est celui de
la position courant de l’utilisateur (le marqueur rouge juste un test au centre).

L’interface est composée de :

▪ Une zone texte qui permet de chercher une destination rapidement.

▪ Le bouton qui exécute la recherche.

▪ Une case à cocher qui permet de suive la position courante avec le caméra.

▪ Les boutons pour l’augmentation/diminution du zoom.

L’interface initiale est présentée par la figure suivante :

Fig 5: Interface initiale du carte
 Si l’utilisateur coche la case pour suivre la position, l’application fait un zoom automatique centré
à la position courante, comme c’est présenté par la figure suivante :

Fig 6: Carte centrée sur la position courante

 Si l’utilisateur fait un clic sur la carte, la destination sera marquée par un marqueur vert et le
chemin le plus court sera dessiné en rouge, comme il est présenté par la figure suivante :

Fig 7: La destination est marquée et le trajet est en rouge

 S’il y a un embouteillage il sera dessiné sur la carte comme une cercle noire avec une contour
rouge. La figure suivante montre ça :

Fig 8: Embouteillage sur la carte

 Si l’utilisateur cherche une destination, la carte sera centrée sur cette dernière et le marqueur du
destination en place. La figure suivante montre ça :

Fig 9: La fonctionnalité du recherche

 Si un embouteillage est détecté sur le trajet alors un message sera affiché pour l’utilisateur est il
peut choisir un chemin alternatif comme le monte la figure suivante :

Fig 10: Choix d'un autre trajet lors d'un embouteillage

Fig 11: Un trajet alternatif
2.4 Le Backend :
Le serveur du Backend fait l’écoute sur le port 8080 comme le montre la figure suivante :

Fig 12: Le Backend en écoute

L’API du Backend s’interroge avec des requêtes POST vers un lien sous la forme :

http://addresse_backend/page

Page peut être :

▪ login : pour s’authentifie

▪ registration : pour créer un compte.

▪ Cords : pour récupérer les positions des embouteillages.

La figure suivante montre une requête d’authentification par l’application mobile :

Fig 13: Requête d'authentification par l'application

3 Évaluation et critique :
Nous avons réussi à créer une interface simple et intuitive pour l’utilisation mais malheureusement
le manque d’une source des données GPS (plusieurs utilisateur en mouvement) nous a obligé d’émuler un
embouteillage aléatoire à un rayon donnée de l’utilisateur courant.
 La limite journalière des requêtes permises par l’API Google nous a obligé d’émuler seulement
deux embouteillages. Pourtant que nous sommes débutant en développement Android, nous avons essayé
le plus possible d’implémenter une application fonctionnelle.

4 Conclusion :
Dans ce chapitre nous avons présenté notre travail réalisé à l’aide des imprimes écrans. Nous
avons implémenté une interface basique qui aide l’utilisateur à choisir une destination et changer le trajet
s’il est possible lors d’un embouteillage. Malheureusement à cause de l’absence des outils de simulation du
mouvement de plusieurs utilisateurs sur une carte nous avons utilisé une simple émulation.
 Conclusion Générale
Ce rapport fait un synthèse du travail réalisé dans le cadre du projet de fin des études en licence
appliquée en informatique. Le projet avait comme but de concevoir et développer une application mobile
qui aide un utilisateur (conducteur) de naviguer son chemin à travers les embouteillages.

Le rapport présente la problématique, la conception et se termine par la présentation du produit

final.

Nous sommes arrivés à accomplir les principales fonctionnalités de l’application mobile mais
malheureusement le manque des données GPS nous a limité à une émulation de l’embouteillage d’où
l’absence des fonctionnalités de prédictions des ces derniers. Notre application est limité par l’API
GoogleMaps.

Ce projet a été une opportunité pour mieux comprendre le processus de développement d’une
application mobile. En effet, il nous a permis d’approfondir nos connaissances en développement orientée
objet, au développement des services web RESTful et la une meilleur compréhension des taches
asynchrones.

Notre application n’est qu’à sa première version. Il y a pleinement de fenêtre pour l’amélioration
et le développement incrémental. Nous envisageons comme perspectives de développer un outil de
simulation des mouvements des terminaux mobiles sur une carte, l’ajout un interface du commande vocale
et l’amélioration de l’interface de l’application.

Notre projet peut évoluer tant que nous sommes capables d’imaginer !