Vous êtes sur la page 1sur 74

RÉPUBLI E ALGÉRIENNE DÉMOCRATI E ET POPULAIRE

MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE SCIENTIFI E


UNIVERSITÉ A.MIRA BEJAIA
FACULTÉ DES SCIENCES EXACTES
DÉPARTEMENT D’INFORMATI E

MSMOIRE DE ~IN DE CYCLE


EN VUE DE L’OBTENTION DU DIPLÔME DE LICENCE EN INRORMAtique GSNSRALE

Thème

Conception et réalisation d’une application mobile


pour la gestion des Véhicules de Transport avec
Chauffeur

Réalisé par :
Mlle AIT MEDDOUR NARIMENE
Mlle ATMANI FARAH
Mlle BAKOURI LETICIA
Mlle DAHMANI TINHINANE
Mlle KERKAR CAMILIA

Devant un jury composé de :


Présidente : Mme KHOULALENE NADJET M.A
.A
Examinatrice Mme AIT ABDELOUHAB KARIMA M.C.
: B
Encadrant : M. KHANOUCHE M. ESSAID M.C.
B

Année Universitaire 2016/2017


Remerciements

Nous tenons à exprimer de tout cœur nos sincères remerciements à notre encadrant
M. KHANOUCHE Mohamed Essaid pour avoir bien voulu nous accompagner tout au long de la
préparation de ce projet, pour les sages conseils et recommandations qui nous ont permis de réaliser
ce modeste travail. Qu’il trouve ici l’expression de notre profonde gratitude.

Nous tenons à remercier vivement M.OUZEGGUANE Redouane pour son accueil, et pour ses pré-
cieux conseils qui furent d’une aide précieuse pour la phase de réalisation de ce projet.

Nous tenons à remercier chacun des membres du jury pour l’intérêt qu’il a porté à ce travail en
acceptant de l’examiner et de l’enrichir.

Nous sommes redevables à nos chers parents pour leur soutien moral et matériel et aussi, pour
leur amour.

Nos sincères remerciements vont également à tous les enseignants du département d’Informatique
de l’université ABDERRAHMANE MIRA de Bejaia.

Ainsi qu’à ceux et celles qui par, leurs paroles, leurs écrits, leurs conseils et leurs critiques ont
guidé nos réfiexions et ont accepté à nous rencontrer et répondre à nos questions durant la
réalisation de ce travail.
Sommaire

Introduction Générale 1

1 Méthodologie de conception 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 La notation de l’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Les diagrammes de l’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Les méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 En quoi consistent les méthodes agiles ? . . . . . . . . . . . . . . . . . . . . 5
1.4 Les applications mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Types d’applications mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Critères pour une bonne application mobile . . . . . . . . . . . . . . . . . . 6
1.4.3 Caractéristiques des applications mobiles . . . . . . . . . . . . . . . . . . . 6
1.5 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Quelques applications de gestion des véhicules avec chauffeur . . . . . . . . . . . . 7
1.6.1 Uber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.2 Taxi diali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Analyse comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.1 Application mobile Uber : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.2 Application mobile Taxi diali : . . . . . . . . . . . . . . . . . . . . . . . . . .9
1.8 Cahier des charges...............................................................................................................10
1.9 Conclusion...........................................................................................................................11

2 Spécification des besoins 12


2.1 Introduction.........................................................................................................................12
2.2 Spécification des besoins.....................................................................................................12
2.2.1 Identification des acteurs........................................................................................12
2.2.2 Modélisation du contexte........................................................................................13
2.2.3 Identification des cas d’utilisation..........................................................................13
2.2.4 Relations dans un diagramme de cas d’utilisation.................................................14
2.2.5 Relations entre cas d’utilisation.............................................................................15
2.3 Les maquettes IHM.............................................................................................................18

i
2.3.1 Espace client...........................................................................................................19
2.3.2 Espace Chauffeur....................................................................................................19
2.3.3 Espace administrateur.............................................................................................20
2.4 Conclusion...........................................................................................................................20

3 Analyse des besoins. 21


3.1 Introduction.........................................................................................................................21
3.2 Concepts de base du diagramme de séquence système.......................................................21
3.2.1 Les diagrammes systèmes de l’application Quick Taxi...........................................22
3.3 Les modèle du domaine.......................................................................................................27
3.3.1 Identification des concepts du domaine..................................................................27
3.3.2 Modèle du domaine « Posséder un compte bancaire »...........................................28
3.3.3 Modèle du domaine du cas d’utilisation« Demander une course »........................28
3.3.4 Modèle du domaine « Effectuer une course »........................................................29
3.3.5 Modèle du domaine « Affecter un véhicule »........................................................29
3.3.6 Modèle du domaine « Échanger des notifications »...............................................30
3.4 Diagramme de classe participante.......................................................................................30
3.4.1 Diagramme de classe participante pour nos cas d’utilisation.................................30
3.5 Conclusion...........................................................................................................................34

4 Conception 35
4.1 Introduction.........................................................................................................................35
4.2 Diagramme d’interaction.....................................................................................................35
4.2.1 Diagrammes d’interactions du cas d’utilisation « S’authentifier »........................37
4.2.2 Diagrammes d’interaction des cas d’utilisation de l’acteur Client.........................38
4.2.3 Diagrammes d’interaction des cas d’utilisation de l’acteur Chauffeur..................42
4.2.4 Diagrammes d’interaction des cas d’utilisation de l’acteur Administrateur . 46
4.3 Diagramme de classe de conception...................................................................................48
4.4 le modèle relationnel...........................................................................................................49
4.5 Règles de dérivation du modèle relationnel à partir d’un modèle de classes.....................49
4.5.1 Présence de la cardinalité « * » sur un côté de l’association..................................49
4.5.2 Présence de la cardinalité « * » sur les deux côtés.................................................50
4.5.3 Présence d’une généralisation................................................................................51
4.6 Conclusion...........................................................................................................................52

5 Réalisation 53
5.1 Introduction.........................................................................................................................53
5.2 Environnement du développement......................................................................................53
5.2.1 Netbeans.................................................................................................................53

ii
5.2.2 Android Studio.......................................................................................................53
5.2.3 WampServer...........................................................................................................53
5.3 Outils de développement.....................................................................................................54
5.3. JD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 K . 4
5.3. SD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 K . 4
5.3. A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 V . 4
D
5.4 Langage de programmation................................................................................................54
5.4.1 JAVA.......................................................................................................................54
5.4.2 XML.......................................................................................................................54
5.4.3 JSON.......................................................................................................................54
5.4.4 PHP.........................................................................................................................55
5.5 Présentation des interfaces..................................................................................................55
5.5.1 Interface d’authentification.....................................................................................55
5.6 Espace client........................................................................................................................55
5.6.1 Interface d’inscription.............................................................................................55
5.6.2 Interface du choix de l’itinéraire............................................................................56
5.6.3 Interface du choix du type de Véhicule..................................................................56
5.6.4 Interface d’attente et d’annulation de la course......................................................57
5.7 Espace chauffeur.................................................................................................................57
5.7.1 Interface d’acceuil..................................................................................................57
5.7.2 Interface de notification..........................................................................................58
5.7.3 Interface de lancement et annulation de la course..................................................58
5.8 Espace administrateur..........................................................................................................59
5.8.1 Interface d’authentification.....................................................................................59
5.8.2 Interface ajout et suppression d’un chauffeur.........................................................59
5.9 Conclusion...........................................................................................................................60

Conclusion Générale 61

iii
Table des figures

1.1 Les interfaces qui composent l’application Uber. . . . . . . . . . . . . . . . . . . . . 9


1.2 Quelques interfaces qui composent l’application Taxi diali...............................................10

2.1 Diagramme de contexte de l’application Quick Taxi............................................................13


2.2 Représentation graphique de la relation d’association.......................................................14
2.3 Relation entre cas d’utilisation............................................................................................15
2.4 Diagramme de cas d’utilisation associé à l’acteur client....................................................16
2.5 Diagramme de cas d’utilisation associé à l’acteur chauffeur..............................................17
2.6 Diagramme de cas d’utilisation associé à l’acteur administrateur.....................................18
2.8 Les interfaces qui composent l’espace client.......................................................................19
2.9 Les interfaces qui composent l’espace chauffeur................................................................19
2.10 Les interfaces qui composent l’espace administrateur.......................................................20

3.1 Formalisme utilisé d’un diagramme séquence système......................................................22


3.2 Diagramme séquence système du cas d’utilisation « s’inscrire ».......................................23
3.3 Diagramme séquence système du cas d’utilisation « S’authentifier »................................23
3.4 Diagramme séquence système du cas d’utilisation« Demander une course »...................24
3.5 Diagramme séquence système du cas d’utilisation « Annuler une course »......................24
3.6 Diagramme séquence système du cas d’utilisation « Valider une course ».......................25
3.7 Diagramme séquence système du cas d’utilisation « Lancer/signaler la fin d’une
course »................................................................................................................................25
3.8 Diagramme séquence système du cas d’utilisation « Annuler une course »......................26
3.9 Diagramme séquence système du cas d’utilisation « Ajouter un chauffeurs »..................26
3.10 Diagramme séquence système du cas d’utilisation « Supprimer un chauffeurs ».............27
3.11 Modèle du domaine des acteurs « client et chauffeur »......................................................28
3.12 Modèle du domaine « Posséder un compte bancaire ».......................................................28
3.13 Modèle du domaine « Demander une course »...................................................................28
3.14 Modèle du domaine « Effectuer une course ».....................................................................29
3.15 Modèle du domaine « Affecter une course ».......................................................................29
3.16 Modèle du domaine « Échanger des notifications »...........................................................30
3.17 Diagramme de classe participante du cas d’utilisation « S’inscrire ».................................31
3.18 Diagramme de classe participante du cas d’utilisation « S’authentifier »..........................31
3.19 Diagramme de classe participante cas d’utilisation « Demander une course ».................32
3.20 Diagramme de classe participante du cas d’utilisation « Annuler une course ».................32
3.21 Diagramme de classe participante du cas d’utilisation « Valider une course »..................33
3.22 Diagramme de classe participante du cas d’utilisation« Signaler la fin d’une course ». 33
3.23 Diagramme de classe participante du cas d’utilisation « Ajouter un chauffeurs ».............34
3.24 Diagramme de classe participante du cas d’utilisation « Supprimer un chauffeurs ». 34

4.1 Formalisme utilisé dans un diagramme d’interaction.........................................................36


4.2 Diagramme d’interaction du cas d’utilisation« S’authentifier ».........................................37
4.3 Diagramme d’interaction du cas d’utilisation « S’inscrire »...............................................38
4.4 Diagramme d’interaction du cas d’utilisation « Demander une course »...........................39
4.5 Diagramme d’interaction du cas d’utilisation « Annuler une course »...............................40
4.6 Diagramme d’interaction du cas d’utilisation « Gérer une course »...................................41
4.7 Diagramme d’interaction du cas d’utilisation « Valider une course »................................42
4.8 Diagramme d’interaction du cas d’utilisation « Lancer/Signaler la fin une cours »...........43
4.9 Diagramme d’interaction du cas d’utilisation « Annuler course »......................................44
4.10 Diagramme d’interaction du cas d’utilisation « Manager une course »..............................45
4.11 Diagramme d’interaction du cas d’utilisation « Ajouter un chauffeur ».............................46
4.12 Diagramme d’interaction du cas d’utilisation « Supprimer un chauffeur »........................47
4.13 Diagramme d’interaction du cas d’utilisation « Gérer un chauffeur »................................48
4.14 Diagramme de classe de conception...................................................................................49

5.1 Interface d’authentification.................................................................................................55


5.2 Interface d’inscription.........................................................................................................56
5.3 Interface de saisie................................................................................................................56
5.4 Liste de type de véhicule.....................................................................................................57
5.5 Interface d’attente/annulation..............................................................................................57
5.6 Interface d’accueil du client................................................................................................58
5.7 A@chage de la notification.................................................................................................58
5.8 Interface de lancement/annulation d’une course.................................................................59
5.9 Interface d’authentification.................................................................................................59
5.10 Interfaces d’ajout et suppression.........................................................................................60
Liste des tableaux

2.1 Les acteurs de l’application Quick Taxi................................................................................12


2.2 Les cas d’utilisation de l’application Quick Taxi..................................................................14
Liste des abréviations

AV D Android Virtual Device

BD Base de Données

GNSS Global Navigation Satellite System

HTTP Hyper Text Transfer Protocol

IDE Integrated Development Environment

IHM Interface Homme Machine

JDK Java Development Kit

JSON Java Script Objet Notation

MySQL My Structured Query Language

PHP Portable Hext Preprocessor

SDK Software Development Kit

SGBD Système de Gestion de Base de


Données
UML Unified Modeling Language

V TC Véhicule de Transport Avec Chauffeur

WiFi Wireless Fidelity

XML eXtenssible Markup Language


Introduction Générale

Au début du vingt-et-unième siècle, le marché de la téléphonie mobile a connu une véritable ré-
volution. En effet, seulement deux décennies ont été su@santes pour passer d’un simple téléphone
portable permettant d’émettre et recevoir des appels, à un téléphone intelligent, appelé Smartphone
doté de capacités proches de celles offertes par un ordinateur personnel. Légers, puissants et intel-
ligents, les Smartphones prennent une place de plus en plus préponderante dans notre quotidien.

Les téléphones intelligents sont alors de véritables concentrés technologiques dans le sens où ils
permettent la communication (par le réseau téléphonique 3G ou 4G, Wi-Fi, Bluetooth), le position-
nement satellitaires, l’utilisation de services multimédias (appareil photo,...), des processeurs de
plus en plus puissants. Toutes ces capacités ouvrent des possibilités pour la création d’applications
de plus en plus variées.

Le présent projet vise à développer une application mobile pour la gestion des Véhicules de
Transport avec Chauffeur (VTC). Ce projet est motivé par le besoin d’un outil permettant à un
individu de pouvoir profiter des multiples services qu’offre un VTC . L’objectif ici est de permettre
à un utilisateur de commander un véhicule avec chauffeur en ligne à partir de son Smartphone.

Ce travail est organisé en cinq chapitres. La présente partie constitue une introduction générale
incluant le contexte d’étude, la problématique du projet et l’organisation du mémoire.

Le premier chapitre est une description de "La méthodologie de conception". Nous présentons,
tout d’abord le langage UML et les méthodes agiles qui sont utilisées pour réaliser le reste de la
conception. Dans la suite du chapitre, nous effectuons une analyse comparative de certaines appli-
cations similaires à l’application à réaliser. Enfin, dans la dernière partie, nous décrivons le cahier
des charges listant les besoins et les exigences de l’utilisateur.

Le deuxième chapitre sera consacré à "La phase spécißcation des besoins". Cette spécification
consiste à décrire les fonctionnalités de l’application à développer à travers une modélisation basée
sur les diagrammes de cas d’utilisation. Nous construisons également, dans ce chapitre, les
maquettes IHM afin de mieux cerner les fonctionnalités de l’application à réaliser.

Le troisième chapitre se focalise sur "L’analyse des besoins". Nous établissons les diagrammes de sé-

1
quences système représentant l’enchaînement des opérations, le modèle du domaine où nous avons
identifié les entités de l’application à réaliser, le diagramme de classes participantes, ainsi que les
diagrammes d’interaction.

Le quatrième chapitre consiste en "la conception" de l’application. Nous présentons le diagramme


de classes associé à l’application ainsi que le modèle relationnel obtenu par l’application des règles
de passage.

Le dernier chapitre concerne "La réalisation". Nous présentons les outils de développement et les
langages de programmation utilisés. Nous illustrerons également quelques interfaces de l’applica-
tion développée.

Enfin, nous conclurons ce travail en résumant les connaissances acquises durant la réalisation de
ce projet.
Chapitre 1

Méthodologie de conception

1.1 Introduction
La réalisation d’une application mobile suscite une méthodologie rigoureuse d’analyse et de
conception. Cette méthodologie permet de décrire les étapes de développement d’une application
assidue à tous les besoins de l’utilisateur, et ce indépendamment de la grandeur et la complexité
de l’application. L’étape d’analyse permet de répertorier toutes les fonctionnalités de l’application
à réaliser, ainsi que toutes les qualités requises pour celle-ci. L’étape de la conception, quant à elle,
permet de modéliser d’une manière explicite le fonctionnement de la future application en utilisant
un langage de modélisation.
Dans ce chapitre, nous présentons des généralités sur le langage de modélisation unifié (UML)
et les méthodes agiles. Nous introduisons, dans la suite du chapitre, les applications mobiles, les
motivations du projet et une analyse comparative d’un ensemble d’applications similaires à l’appli-
cation à réaliser. Enfin, nous décrivons le cahier des charges listant les besoins et les exigences de
l’utilisateur.

1.2 Présentation de l’UML

1.2.1 La notation de l’UML


UML (unified modeling language) se définit comme un langage de modélisation graphique et
textuel. Il est destiné à décrire des besoins, spécifier et documenter des systèmes, esquisser des
archi- tectures logicielles, concevoir des solutions et communiquer des points de vue. UML unifie
également les notations nécessaires aux différentes activités d’un processus de développement
d’applications et offre, par ce biais, le moyen d’établir le suivi des décisions prises, depuis
l’expression des besoins jusqu’à l’étape de réalisation [1].

UML présente plusieurs avantages dont le gain de précision, la stabilité et la structuration cohé-
rente des fonctionnalités et des données. Toutefois, UML a l’inconvénient de nécessiter un temps
de travail relativement élevé, trop d’emphase sur la conception et, enfin, les diagrammes présentés
pour modéliser un système peuvent devenir écrasants.

1.2.2 Les diagrammes de l’UML


UML 2.0 propose treize diagrammes utilisés pour la description d’un système à développer.
Ces diagrammes sont regroupés dans deux grandes catégories [1].

Les diagrammes structurels permettent de modéliser la structure statique du système. On trouve : 1)


diagramme de classes qui exprime la structure statique d’un système en terme d’attributs, d’associa-
tions, d’opérations et de relations entre les classes ; 2) diagramme de structure composite qui décrit
les classes, les interfaces et le packages composant un système; 3) diagramme de composants qui
définit l’architecture physique et statique d’un système en terme de modules ( fichiers sources,
librai- ries et exécutables); 4) diagramme de déploiement pour décrire l’architecture technique et
matérielle de répartition d’un système; 5) diagramme d’objets qui représente graphiquement la
structure d’un système via des instances concrètes de classes, d’associations, et de dépendances; 6)
diagramme de package permet l’organisation du système ainsi que l’identification de généralisation
et de dépen- dance.

Les diagrammes de comportements : visualisent, construisent, et décrivent la partie dynamique d’un


système à travers sept diagrammes. On compte : 1) diagramme de cas d’utilisation décrivant toutes
les fonctionnalités devant être fournies par le système et toutes les interactions entre le système et
les acteurs; 2) diagramme de séquence qui est la représentation séquentielle du déroulement des
traitements et des interactions entre les éléments du système et ses acteurs; 3) diagramme d’acti-
vité qui montre l’enchaînement des actions et décisions au sein d’une activité ; 4) diagramme d’état
permettant de décrire les états et les transitions d’un objet d’une classe ; 5) diagramme de communi-
cation est une autre représentation du diagramme de séquence, mais d’une manière plus simplifié
;
6) diagramme global d’interaction qui est une variante du diagramme d’activité et du diagramme de
séquence permettant la spécification de la dynamique du système; 7) diagramme de temps qui fu-
sionne les diagrammes d’états et de séquence pour montrer l’évolution de l’état d’un objet au cours
du temps.

1.3 Les méthodes agiles


Après avoir constaté que le taux de réussite des projets était faible, les concepteurs ont pensé
à de nouvelles méthodes qui seront en mesure de corriger les erreurs des méthodes traditionnelles,
ainsi les méthodes agiles sont apparues. Ces méthodes s’intéressent beaucoup plus au produit qu’au
projet et l’interaction entre les clients et les développeurs est très importante ce qui réduit l’effet
tunnel caractérisant les autres méthodes [2].
1.3.1 En quoi consistent les méthodes agiles ?
L’implication du client dans ces méthodes se fait du début à la fin du processus de développe-
ment. D’abord, le client présente sa vision du produit et décrit les fonctionnalités attendues et les
exigences. Cela permettra d’évaluer les coûts du produit. Ensuite, les développeurs divisent le projet
en itérations comportant les travaux de conception, les spécifications fonctionnelles, et techniques
si nécessaire, le développement et les tests avec une durée moyenne pour toutes ces itérations, ce
qui fait que le processus est itératif et incrémental. Après chaque itération, une réunion entre le
client et les développeurs est organisée dans le but de présenter le travail fait. cela permettra au
client d’évaluer la progression du projet ainsi que la possibilité de modifier, d’ajouter ou de retirer
certaines fonctionnalités moins prioritaire qui n’ont pas encore été réalisées, c’est ce qu’on appelle
la rétroaction. Enfin, une fois la phase de développement est achevée, le produit sera remis au client
[2].

1.4 Les applications mobiles


Les applications mobiles sont liées aux développements d’Internet et des télécommunications,
des réseaux sans fils et des technologies agents permettant d’accomplir une tâche prédéfinie de ma-
nière intelligente et autonome. Il existe plusieurs types d’applications mobiles couvrant une grande
variété de domaines et qui sont adaptés aux différents environnements techniques des Smartphones
et à leurs contraintes et possibilités ergonomiques. Les applications mobiles permettent générale-
ment un accès plus confortable et plus e@cace à des sites ou services accessibles en versions
mobile.

Une application mobile est un logiciel applicatif développé pour être installé sur un appareil électro-
nique mobile (par exemple, un smartphone, une tablette tactile) [3]. Les applications mobiles sont
conçues pour être petites, rapides et faciles à utiliser en tenant compte des exigences de l’utilisateur,
et des contraintes de ces appareils électroniques. Contrairement aux applications de bureau, les ap-
plications mobiles ne peuvent être obtenues qu’en les téléchargeant de façon gratuite ou payante
soit à partir du téléphone via une connexion internet depuis une boutique logicielle ou un service
mobile, soit à partir de son ordinateur lorsque le smartphone est relié à ce dernier.

1.4.1 Types d’applications mobiles


Il existe trois types d’application mobile que tout utilisateur peut rencontrer :

1.4.1.1 Application native

Il s’agit d’application conçue pour une grande partie des systèmes d’exploitation utilisés par
les Smartphones en se référant à un langage de programmation particulier à chacun de ces
smartphones
[4] .
1.4.1.2 Application web

Il s’agit d’un site Internet qui a été adapté pour un navigateur de mobiles. De la même
manière que les sites web, une application mobile web est généralement placée sur un serveur
HTTP et se manipule en actionnant des éléments d’interface XHTML à l’aide d’un navigateur
web [5] .

1.4.1.3 Application hybride

Il s’agit d’une application mobile qui fusionne entre les caractéristiques du web application et
celles de l’application native. De cette manière, l’application mobile sera accessible sur toutes les
plateformes d’application, elle est accessible exclusivement sur iphone et Android [4].

1.4.2 Critères pour une bonne application mobile


Le développement des applications mobiles tient compte de la rapidité, la fiuidité et la taille de
ces dernières, en effet une parfaite ergonomie et une bonne qualité d’a@chage sont assurées pour
séduire l’utilisateur, l’optimisation des ressources permet une bonne économie d’énergie [6].

1.4.3 Caractéristiques des applications mobiles


Des contraintes techniques sont à prendre en compte lors de la conception d’une application
mobile :

• Tailles d’écrans variables pouvant dans certains cas être assez réduite.
• Possibilité limitée de saisie de données.
• Puissance du processeur pouvant être limité sur les premiers Smartphones.
• Tailles de la mémoire pouvant varier.
• Autonomie du Smartphone.
• Débits variables de la bande passante Internet.

Outre ces aspects techniques, il est également important de prendre en compte l’ergonomie de
l’application Mobile à réaliser et c’est un point crucial à ne pas négliger :

• Utiliser des images petites et légères.


• Utiliser des éléments facilement accessibles.
• Maitriser l’utilisation du JavaScript pour économiser la batterie.
• Adapter le mode de saisie des informations [5].
1.5 Contexte du projet
Le besoin de transports se fait de plus en plus ressentir dans les grandes métropoles et trouver
un taxi n’est pas toujours aisé. Grâce à l’application mobile qu’on veut réaliser le client n’a plus
besoin de se déplacer à une station de taxi ou même d’attendre pendant longtemps pour prendre un
taxi.

Cette application mobile a pour objectif de garantir une grande amélioration et une meilleure
gestion des véhicules de transport avec chauffeur de surcroit faciliter l’interconnexion entre les
chauffeurs et les clients.

Notre future application permet au client de commander en ligne un véhicule avec chauffeur et ce
grâce à son téléphone mobile. Le client sélectionne un véhicule selon ses exigences puis renseigne
sa destination. En réponse, l’application repère les chauffeurs les plus proches géographiquement
du client et lui attribut un de ces chauffeurs. Le paiement d’une course est simple et automatique.

1.6 Quelques applications de gestion des véhicules avec


chauf- feur
De nos jours, plusieurs applications ont été conçues et mises en ligne pour la gestion des taxis.
Parmi ces applications nous citons Uber et Taxi diali.

1.6.1 Uber
(www.uber.com) 1 est une application mobile, lancée à San Francisco en 2009 par Travis Kala-
nick. Elle devient le leader des applications de véhicule du transport avec chauffeur. Cette
application permet de commander 24 h/24 et 7 j/7 un véhicule avec chauffeur de façon facile et
surtout immé- diate à partir d’un téléphone portable. Il existe aujourd’hui plusieurs types de
services proposés en fonction des besoins du client. De plus, Uber est disponible dans plus de 500
villes dans le monde, le paiement est simple et automatique.

1.6.2 Taxi diali


2
(www.taxi-diali.com) est une application destinée à faciliter la localisation et la ré-
servation d’un véhicule avec chauffeur en utilisant la géo localisation via Smartphone et la 3G. Taxi
diali est un service gratuit adapté à tous type de téléphone mobile fonctionnant sous système An-
droid ou iOs.

1. Le site web de uber


2. Le site web de Taxi diali
Toutes ces applications mobiles ont en commun la possibilité de commander un véhicule avec
chauf- feur en ligne.

1.7 Analyse comparative


L’analyse comparative consiste à comparer les idées, les procédures, les pratiques et les résul-
tats d’une formation ou d’un service ainsi qu’apprécier ses performances et la qualité de sa structure
par rapport à celles de ses principaux concurrents.

Dans ce qui suit, nous effectuons une analyse comparative des applications mobiles des deux plus
grands acteurs du véhicules de transport avec chauffeurs afin de nous inspirer de leurs constitutions
tout en déterminant quelques points forts et points faibles de chacune de ces applications.

1.7.1 Application mobile Uber :


Il s’agit d’une application mobile permettant de commander un véhicule avec chauffeur. L’in-
ternaute doit télécharger l’application sur son smartphone, s’inscrire, puis s’authentifier avant de
passer une demande de course.

L’interface principale permet de renseigner le lieu de prise en charge et la destination (Figure 1.1
a). Cette interaction n’est pas évidente pour les nouveaux utilisateurs. En effet, si le client déplace
légèrement le curseur, il perdra sa position, conduisant ainsi le chauffeur à une fausse adresse.
Après avoir saisi toutes les informations, une nouvelle interface a@che tous les chauffeurs
disponibles se trouvant à proximité du client, le temps d’attente et le prix de la course. Le client
choisit alors un chauffeur et valide la demande de course. Le paiement de la course est simple et
automatique en insérant le numéro du compte bancaire du client (Figure 1.1 b)

Le chauffeur s’inscrit à l’application afin d’avoir un compte. En s’authentifiant, le chauffeur se


met automatiquement en service. Le chauffeur reçoit une notification, lui indiquant l’adresse
du client ainsi que la durée du trajet à parcourir. Lorsque le chauffeur valide la course une
interface portant une carte lui traçant le parcours choisit par le client apparaît. Le chauffeur doit
suivre cet itinéraire afin d’arriver à son client. Après avoir fini sa course le chauffeur peut
consulter son revenu et il peut également connaître le nombre de courses réalisées.

Uber est une application très simple à utiliser, avec un minimum d’action et une sécurité idéale.
De plus Uber offre à la demande de ses clients un prix détaillé de la course.
(a) Commander course (b) payer une course.

FIGURE 1.1 – Les interfaces qui composent l’application Uber.

1.7.2 Application mobile Taxi diali :


Cette application mobile permet de demander un véhicule avec chauffeur. Le client doit
remplir un formulaire afin de s’inscrire à l’application, puis s’authentifie. Une interface d’accueil
demandant au client de faire un choix de langue apparaît avant chaque demande de course, ce qui
peut être désagréable pour le client (Figure 1.2.a).

Le client doit saisir son adresse pour pouvoir trouver tous les chauffeurs se trouvant à sa proxi-
mité (Figure 1.2.b). Ces derniers s’a@chent en une liste (Figure 1.2.c). Le client peut récupérer les
informations personnelles d’un chauffeur : sa photo, son nom, son numéro, son adresse ainsi que
son statut avant de passer une demande. En cas de problème, le client peut contacter les administra-
teurs de l’application. Cette application donne un aspect ergonomique très simple et basique avec
un choix restreint d’option.
(a) Choisir la langue. (b) Entré l’adresse. (c) Liste des chauffeurs.

FIGURE 1.2 – Quelques interfaces qui composent l’application Taxi diali.

1.8 Cahier des charges


L’objectif de ce travail consiste à mettre en relation des chauffeurs et des clients par le biais
d’une application mobile baptisée, nommée Quick Taxi, cette dernière permet de commander un
véhicule en quelques minutes. Le paiement est simple et automatique. L’application Quick Taxi
sera divisée en trois espaces :
• Un espace réservé au client, lui permettant de commander une course selon ses besoins. Le client
peut se positionner en cliquant sur la carte, en indiquant une adresse précise ou en utilisant le ser-
vice de géo localisation.

Lorsqu’un client entre sa destination, la demande de la course est envoyée aux chauffeurs se
trouvant dans la même zone géographique que le client. Ce dernier a un choix large de véhicule : un
van, une citadine ou une Berlin. Le client peut également annuler une course, mais après un temps
prédéfini, des frais de déplacement du chauffeur peuvent être débités sur le compte bancaire du
client.

Le client recevra une notification lui indiquant la position du chauffeur ainsi que ses informations
personnelles telles que son nom, sa photo et son numéro de téléphone, le type et le nom du véhicule
ainsi que son numéro d’immatriculation, afin de monter dans le bon véhicule.

•Un espace destiné au chauffeur. Lui permettant de se connecter à l’application afin de se mettre en
service.

Le chauffeur reçoit une notification comportant la destination et la position du client ainsi que ses
informations personnelles telles que sa photo et son numéro de téléphone. Lorsque le chauffeur va-
lide la demande de course d’un client, son statut passe à l’état indisponible. Il se rend ensuite sur les
lieux de prise en charge du client.
Le chauffeur lance la course lorsque le client est à bord du véhicule. Une fois arrivé à la destina-
tion sélectionnée par le client, le chauffeur arrête la course. Son statut se remet donc à disponible
automatiquement. Le chauffeur peut également annuler la course dans le cas d’une panne ou d’un
autre désagrément.

•Un espace conçue pour l’administrateur qui s’occupe de la gestion de l’application telle que l’ajout
d’un nouveau chauffeur ou la suppression d’un ancien. L’administrateur peut également gérer les
problèmes informatiques et techniques de l’application, tels que les bugs et les mises à jours.

1.9 Conclusion
Ce chapitre nous a servi à exposer le projet à réaliser. Nous avons présenté le langage de modé-
lisation UML et les méthodes agiles qui sont désignés pour réaliser le reste de la conception. Après
avoir effectué une analyse comparative de quelques applications mobiles de gestion de véhicule de
transport avec chauffeur, nous avons établit le cahier des charges listant tous les besoins et toutes
les exigences de l’utilisateur.
Chapitre 2

Spécification des besoins

2.1 Introduction
Ce chapitre est essentiellement consacré aux étapes fondamentales du développement de l’appli-
cation de gestion de véhicules de transport avec chauffeur Quick Taxi. L’analyse et la conception
de ladite application seront faites à l’aide du formalisme UML offrant une fiexibilité remarquable et
qui s’exprime par l’utilisation des diagrammes. En premier lieu, nous procédons à l’identification
des acteurs qui interagissent avec l’application Quick Taxi. Nous modéliserons, par la suite, des dia-
grammes de cas d’utilisation où nous identifions les différents cas d’utilisation. Enfin, nous
élaborons les diagrammes de séquence.

2.2 Spécification des besoins

2.2.1 Identification des acteurs


Un acteur représente un rôle joué par une entité externe. Cette entité peut être un utilisateur
humain, un dispositif matériel ou autre système interagissant directement avec l’application à réa-
liser ; celui-ci est appelé acteur principal. Quant aux acteurs secondaires, ils sont sollicités pour des
informations complémentaires.

Acteur Type Role


Client Principal Le client pourra accéder aux fonctionnalités de
l’ap-
plication après s’être authentifié.
Chauffeur Principal Il aura accès aux informations saisies par un client.
Administrateu Principal Il inscrira les chauffeurs à l’application.
r
Système Secondai Il débitera le montant de la course du compte du
bancaire re client à la fin de celle-ci.

TABLE 2.1 – Les acteurs de l’application Quick Taxi.


2.2.2 Modélisation du contexte
On représentera l’interaction des acteurs avec l’application Quick Taxi dans la figure ci dessous :

FIGURE 2.1 – Diagramme de contexte de l’application Quick Taxi.

2.2.3 Identification des cas d’utilisation


Un cas d’utilisation est utilisé pour définir le comportement d’un système ou la sémantique de
toute autre entité sans révéler sa structure interne. Chaque cas d’utilisation spécifie une séquence
d’action, y compris des variantes que l’entité réalise en interagissant avec les acteurs de l’entité[7].

Le tableau 2.2 décrit les cas d’utilisations de l’application Quick Taxi.


N Cas d’utilisation Acteur
o
0 S’inscrire Client
1
0 S’authentifier Tous les
2 acteurs
Demander une course
0 Gérer une course Client
3 Annuler la course
Notification de la confirmation d’une
0 Recevoir une course Client et
4 notification Chauffeur
Notification de l’annulation d’une course
Notification de la commande d’une course
0 Payement d’une Chauffeur
5 course
Lancer une course
0 Manager une course Annuler une course Chauffeur
6 Signaler la fin d’une course
Ajouter un chauffeur
0 Gérer les chauffeurs Administrateur
7 Supprimer un chauffeur

TABLE 2.2 – Les cas d’utilisation de l’application Quick Taxi

2.2.4 Relations dans un diagramme de cas d’utilisation


2.2.4.1 Relations entre un acteur et un cas d’utilisation

Relation d’association Une relation d’association est le chemin de communication entre un


acteur et un cas d’utilisation et est représentée par un trait continu .

FIGURE 2.2 – Représentation graphique de la relation d’association.

Acteur principal VS acteur secondaire un acteur est qualifié de principal pour un cas d’uti-
lisation donné lorsque ce cas rend service à cet acteur. Les autres acteurs sont alors qualifiés de se-
condaires. Un cas d’utilisation a au plus un acteur principal. Un acteur principal obtient un résultat
observable du système tandis qu’un acteur secondaire est sollicité pour des informations complé-
mentaires [7].
2.2.5 Relations entre cas d’utilisation
Relation d’inclusion un cas A inclut un cas B si le comportement décrit par le cas A inclut le
comportement du cas B. cette dépendance est symbolisée par le stéréotype « include »[7]. Rela-
tion d’extension un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A
peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut éventuellement en-
traîner l’exécution de A. Contrairement à l’inclusion, l’extension est optionnelle. Cette dépendance
est symbolisée par le stéréotype « extend ».[8] Relation de généralisation Un cas A est une
généralisation d’un cas B si B est un cas particulier de A [7].

(a) Inclusion. (b) Extension.

(c) Généralisation.

FIGURE 2.3 – Relation entre cas d’utilisation.

2.2.5.1 Diagramme de cas d’utilisation de l’application Quick Taxi

Un diagramme de cas d’utilisation est un graphe d’acteurs, un ensemble de cas d’utilisation en-
globés par la limite du système, des associations de communication entre les acteurs et les cas d’uti-
lisation, et des généralisations entre cas d’utilisation. Il est destiné à représenter les besoins des
utilisateurs par rapport au système [7].
Dans ce qui suit, nous décrivons les diagrammes de cas d’utilisation associés à chacun des acteurs
de l’application à réaliser.
FIGURE 2.4 – Diagramme de cas d’utilisation associé à l’acteur client.

Le diagramme de la figure 2.4 représente les cas d’utilisation associé à l’acteur « Client ». Le cas
d’utilisation « Gérer une course »représente soit le cas d’utilisation « Annuler une course ou »« De-
mander une course ». Ce dernier inclut les cas « Choisir un type de véhicule « , « le point de départ
« « choisir la destination« . Les cas d’utilisation « Recevoir une notification »et « Demander une
course »nécessitent l’authentification de l’acteur.
FIGURE 2.5 – Diagramme de cas d’utilisation associé à l’acteur chauffeur.

Le diagramme la figure « 2.5 »représente les cas d’utilisation associé à l’acteur chauffeur. Les cas
d’utilisation « Manager une course » et « recevoir une notification » doivent d’abord passer par
l’authentification, d’où la relation d’inclusion entre ces deux cas et le cas « s’authentifier ». Une
fois la course terminée, le système bancaire débitera le montant de la course du compte du client, ce
qui explique la relation d’inclusion entre les cas d’utilisations « signaler la fin d’une course » et «
Payement d’une course ».
FIGURE 2.6 – Diagramme de cas d’utilisation associé à l’acteur administrateur.

Le diagramme de cas d’utilisation représenté dans la Figure 2.6, illustre le rôle de l’administrateur
dans l’application le cas d’utilisation. « Gérer les chauffeurs » se fait par l’ajout des chauffeurs ou
leur suppression d’où la relation de généralisation entre ce cas et les deux cas d’utilisation « ajouter
un chauffeur » et « supprimer un chauffeur ». Pour réaliser cette fonctionnalité, l’administrateur
doit s’authentifier d’où la relation d’inclusion avec le cas d’utilisation « s’autentifier ».

2.3 Les maquettes IHM


Une maquette est un produit jetable permettant aux utilisateurs d’avoir une vue concrète mais non
définitive des interfaces de la future application. On parle aussi de prototypage d’IHM (Interface
Homme Machine). une maquette permet de bien cerner les fonctionnalités de l’application à réaliser
[1].
2.3.1 Espace client

(a) Autentification. (b) Inscription. (c) Commande course.

(a) Saisie de position. (b) Choix véhicule. (c) Interface d’attente.

FIGURE 2.8 – Les interfaces qui composent l’espace client.

2.3.2 Espace Chauffeur

(a) Acceuil. (b) Notification. (c) Manager Course. (d) Fin course.

FIGURE 2.9 – Les interfaces qui composent l’espace chauffeur.


2.3.3 Espace administrateur

FIGURE 2.10 – Les interfaces qui composent l’espace administrateur.

2.4 Conclusion
Ce chapitre nous a permis de spécifier les différentes fonctionnalités de l’application à réaliser.
Nous avons fourni une analyse détaillée des besoins en identifiant l’ensemble des cas d’utilisation.
Puis en les illustrants grâce à un diagramme de cas d’utilisation. Enfin, nous avons décrit les
maquettes IHM afin de mieux cerner les fonctionnalités de l’application à réaliser.
Chapitre 3

Analyse des besoins.

3.1 Introduction
L’objectif de la phase d’analyse est d’accéder à une compréhension des besoins et des
exigences du client. Un modèle d’analyse livre une spécification complète des besoins issus des cas
d’utilisa- tion et les structure sous une forme facilitant la compréhension, la préparation, la
médication et la maintenance du système à réaliser.

3.2 Concepts de base du diagramme de séquence système


Les diagrammes de séquence sont la représentation graphique des interactions entre les ac-
teurs et le système selon un ordre chronologique.Nous utilisons le terme de diagramme de séquence
« système » pour souligner le fait que nous considérons le système à modéliser comme une boîte
noire. Les concepts de base utilisés dans un diagramme de séquence sont :

• Objet représente une instance de la classe ou de l’interface responsable de la réalisation


des opérations définies. Il est représenté graphiquement dans le diagramme de séquence
par un carré comportant son identifiant [10].

• Ligne de vie des objets est représentée par une ligne verticale en traits pointillés placée sous
le symbole de l’objet concerné [10].

• Message synchrone et asynchrone : deux types de messages peuvent être distingués :

– Message synchrone
où l’émetteur reste bloqué durant l’invocation de l’opération. Graphiquement, un mes-
sage synchrone est représenté par une fièche en trait plein à l’extrémité pleine partant
de la ligne de vie d’un objet expéditeur vers celle de l’objet cible [10].
– Message asynchrone
où l’émetteur n’attend pas de réponse. Graphiquement, un message asynchrone est re-
présenté par une fièche en trait pleins à l’extrémité ouverte partant de la ligne de vie d’un
objet expéditeur vers celle de l’objet cible [10].

• Fragment d’interaction
Un fragment représente des articulations d’interactions. Il est défini par un opérateur et des
opérandes.
La description des opérateurs utilisés dans l’analyse de notre application se fera dans ce qui
suit :

– Alternative « alt » :correspond à une instruction de test avec une ou plusieurs


alternatives possibles. Il permet aussi d’utiliser les clauses de type sinon et se
représente dans un fragment possédant au moins deux parties séparées par des
pointillés.
– Référence « ref » :permet d’appeler une séquence d’interactions décrite par ailleurs,
consti- tuant ainsi une sorte de sous-diagramme de séquence.
– boucle « loop » : correspond à une instruction de boucle qui permet d’exécuter une sé-
quence d’interactions tant qu’une condition est satisfaite.

FIGURE 3.1 – Formalisme utilisé d’un diagramme séquence système .

3.2.1 Les diagrammes systèmes de l’application Quick Taxi


3.2.1.1 Diagramme séquence système pour le cas d’utilisation « s’inscrire »

Pour s’inscrire, l’utilisateur doit remplir un formulaire d’inscription puis valider. Le système
quant à lui vérifie si tous les champs sont bien remplis et envois au système bancaire le numéro de
compte de l’utilisateur pour l’authentifier (Figure3.2).
FIGURE 3.2 – Diagramme séquence système du cas d’utilisation « s’inscrire ».

3.2.1.2 Diagramme séquence système pour le cas d’utilisation « S’authentifier »

Une fois inscrit, l’utilisateur n’aura qu’à entrer son login et son mot de passe pour se connecter.
Lors des prochaines utilisations, l’authentification se fera automatiquement (Figure3.3).

FIGURE 3.3 – Diagramme séquence système du cas d’utilisation « S’authentifier ».

3.2.1.3 Diagramme séquence système pour le cas d’utilisation « Demander une course ».

Le client entre l’adresse du point de départ et sa destination, puis choisi le type de véhicule. Le
système vérifiera les données avant d’envoyer une notification au chauffeur (Figure3.4).
FIGURE 3.4 – Diagramme séquence système du cas d’utilisation« Demander une course ».

3.2.1.4 Diagramme séquence système pour le cas d’utilisation « Annuler une course ».

Le client a la possibilité d’annuler une course ce qui enclenchera l’envoi d’une notification au
chauffeur (Figure3.5).

FIGURE 3.5 – Diagramme séquence système du cas d’utilisation « Annuler une course ».
3.2.1.5 Diagramme séquence système pour le cas d’utilisation « Valider une course »

Lors de la réception de la notification de demande d’une course, le chauffeur la valide. Une


notification de confirmation est envoyée au client (Figure3.6).

FIGURE 3.6 – Diagramme séquence système du cas d’utilisation « Valider une course ».

3.2.1.6 Diagramme séquence système pour le cas d’utilisation « Lancer/signaler la fin


d’une course »

Le chauffeur lance la course, le système démarre le compteur. Lorsque le chauffeur signale la


fin de la course, l’application Quick Taxi envoie au système bancaire le montant à débiter
(Figure3.7).

FIGURE 3.7 – Diagramme séquence système du cas d’utilisation « Lancer/signaler la fin


d’une course ».
3.2.1.7 Diagramme séquence système pour le cas d’utilisation « Annuler une course »

Après avoir validé la course, le chauffeur peut annuler la course (Figure3.8).

FIGURE 3.8 – Diagramme séquence système du cas d’utilisation « Annuler une course ».

3.2.1.8 Diagramme séquence système pour le cas d’utilisation « gérer les chauffeurs »

L’administrateur pourra ajouter ou supprimer un chauffeurs, et le système vérifiera les données


entrées (Figure3.9) (Figure 3.10).

FIGURE 3.9 – Diagramme séquence système du cas d’utilisation « Ajouter un chauffeurs ».


Quant à la suppression d’un chauffeur est représentée ci dessous :

FIGURE 3.10 – Diagramme séquence système du cas d’utilisation « Supprimer un chauffeurs ».

3.3 Les modèle du domaine


Le modèle du domaine est une visualisation des concepts d’un domaine du monde réel. Il
s’agit d’une vue statique car on ne tient pas compte du facteur temporel dans le comportement du
sys- tème[1].

3.3.1 Identification des concepts du domaine


Le modèle du domaine est la première version du diagramme de classe. Ce modèle doit
contenir les classes qui modélisent les entités ou concepts présents dans le domaine, nommé aussi
métier de l’application. Il faut savoir que les classes du modèle du domaine ne doivent pas contenir
d’opéra- tions, mais des attributs seulement[1].

Un diagramme de classe du domaine comporte les éléments suivant :

• Les classes conceptuelles ou les entités du domaine .

• Les associations entre les différentes classes conceptuelles.

• Les attributs des classe conceptuelles.

3.3.1.1 Modèle du domaine des acteurs « client et chauffeurs »

Les deux classes Clients et Chauffeurs héritent de la classe Personnes


FIGURE 3.11 – Modèle du domaine des acteurs « client et chauffeur ».

3.3.2 Modèle du domaine « Posséder un compte bancaire »


Pour que le client puisse s’inscrire il devrait posséder un compte bancaire qui pourrait être
utilisé par plusieurs clients.

FIGURE 3.12 – Modèle du domaine « Posséder un compte bancaire ».

Les concepts fondamentaux sont : Client et CompteBancaire.

3.3.3 Modèle du domaine du cas d’utilisation« Demander une course »

FIGURE 3.13 – Modèle du domaine « Demander une course ».


A partir de cette figure nous remarquons deux concepts fondamentaux : Client et Course.

3.3.4 Modèle du domaine « Effectuer une course »


Pour qu’une course soit effectuer le client doit choisir un type de véhicule et à partir de ça nous
extrayons trois concepts fondamentaux : Course,Véhicule et Type.

FIGURE 3.14 – Modèle du domaine « Effectuer une course ».

3.3.5 Modèle du domaine « Affecter un véhicule »


Chaque véhicule est affecté à un chauffeurs, qui pourrait posséder un ou plusieurs véhicule
dans le temps.

FIGURE 3.15 – Modèle du domaine « Affecter une course ».

A partir de cette figure, les concepts fondamentaux sont : Chauffeur et Véhicule.ainsi que la
classe association affecter.
3.3.6 Modèle du domaine « Échanger des notifications »
Entre le client et le chauffeur des notifications sont échangées, à partir de la nous avons deux
concepts fondamentaux Personnes qui est la classe mère de Clients et Chauffeurs, ainsi que notifi-
cation. et nous avons aussi la classe association Échanger qui relis nos deux classes.

FIGURE 3.16 – Modèle du domaine « Échanger des notifications ».

3.4 Diagramme de classe participante


Les diagrammes de classes participantes sont particulièrement importants car ils font la jonc-
tion entre les cas d’utilisation, la maquette vu dans le chapitre précèdent et les diagrammes de
conception logicielle[1].

Pour compléter ce travail d’identification, nous allons ajouter des attributs et des opérations
dans les classes d’analyse.

• Les entités vont seulement posséder des attributs. Ces attributs représentent en général des
informations persistantes de l’application [1].

• Les contrôles vont seulement posséder des opérations. Ces opérations montrent les compor-
tements du système informatique[1].

• Les dialogues vont posséder des attributs et des opérations. Les attributs représenteront des
champs de saisie ou des résultats et les opérations représenteront des actions de l’utilisateur
sur l’IHM [1].

3.4.1 Diagramme de classe participante pour nos cas d’utilisation


Nous allons représenter dans cette section les classes dialogue et contrôle quant aux classes
entités nous les avons représenté dans la section précédente.
3.4.1.1 Diagramme de classe participante pour le cas d’utilisation « s’inscrire »

L’utilisateur doit s’inscrire pour accéder aux fonctionnalités de l’application. Il n’y a qu’un seul
dialogue pour remplir le formulaire, avec deux contrôles ainsi la figure ci dessous.

FIGURE 3.17 – Diagramme de classe participante du cas d’utilisation « S’inscrire ».

3.4.1.2 Diagramme de classe participante « S’authentifier ».

Pour s’authentifier, l’utilisateur devra entrer son login et son mot de passe, d’où la présence
d’un seul dialogue et un seul contrôle.

FIGURE 3.18 – Diagramme de classe participante du cas d’utilisation « S’authentifier ».

3.4.1.3 Diagramme de classe participante pour le cas d’utilisation « Demander une course »

Pour la demande d’une course, le client accéder a deux dialogue consécutifs, avec un seul
contrôle.
FIGURE 3.19 – Diagramme de classe participante cas d’utilisation « Demander une course ».

3.4.1.4 Annuler la course

Dans ce cas d’utilisation, le client annule la course, et pour cela il n’y a qu’un seul dialogue et
deux contrôles.

FIGURE 3.20 – Diagramme de classe participante du cas d’utilisation « Annuler une course ».

3.4.1.5 Diagramme de classe participante pour le cas d’utilisation « Valider une course »

Dans ce cas d’utilisation nous aurons deux dialogues et un seul contrôle.


FIGURE 3.21 – Diagramme de classe participante du cas d’utilisation « Valider une course ».

3.4.1.6 Lancer/Signaler la fin d’une course

En effectuant la course le chauffeur lancer la course et signale sa fin, il y aura alors qu’un seul
dialogue et deux contrôles.

FIGURE 3.22 – Diagramme de classe participante du cas d’utilisation« Signaler la fin d’une course ».

3.4.1.7 Diagramme de classe participante pour le cas d’utilisation « Gérer les chauffeurs »

Pour ce cas d’utilisation, nous retrouvons deux cas d’utilisations : Le premier est « ajouter un
chauffeur »où nous trouverons un dialogue et un contrôle.
FIGURE 3.23 – Diagramme de classe participante du cas d’utilisation « Ajouter un chauffeurs ».

Et le deuxième est « supprimer un chauffeur »qui possède un dialogue et un contrôle.e

FIGURE 3.24 – Diagramme de classe participante du cas d’utilisation « Supprimer un chauffeurs ».

3.5 Conclusion
Dans ce chapitre nous avons vu les diagrammes de séquences système où nous avons pu dé-
tailler l’enchaînement des opérations, le modèle du domaine dans le quel nous avons identifié les
entités de notre système et le diagramme de classe participante qui nous a permis de faire le lien
entre les cas d’utilisation et les maquettes IHM. Ce qui nous permettra la modélisation des
diagrammes d’interactions ainsi que le diagramme de classe de conception que nous verrons dans le
chapitre suivant.
Chapitre 4

Conception

4.1 Introduction
La phase de conception nécessite des méthodes permettant de mettre en place un modèle sur
lequel on va s’appuyer. La modélisation consiste à créer une représentation virtuelle d’une réalité
de telle façon à faire ressortir les points auxquels nous nous intéressons.

4.2 Diagramme d’interaction


Par rapport aux diagrammes de séquence système du chapitre précèdent, nous allons remplacer
le système vu comme une boîte noire par un ensemble d’objets en interaction[1]. Pour cela, nous
utiliserons encore dans ce chapitre les trois types de classes d’analyse, à savoir les dialogues, les
contrôles et les entités. Nous respecterons également les règles que nous avions fixées sur les re-
lations entre classes d’analyse, mais en nous intéressant cette fois-ci aux interactions dynamiques
entre objets :

• Les acteurs ne peuvent interagir (envoyer des messages) qu’avec les dialogues[8].

• Les dialogues peuvent interagir avec les contrôles[8].

• Les contrôles peuvent interagir avec les dialogues, les entités, ou d’autres contrôles[9].

• Les entités ne peuvent interagir qu’entre elles[8].

Le changement de niveau d’abstraction par rapport au diagramme de séquence système peut ainsi
se représenter comme sur la figure ci-dessous :
FIGURE 4.1 – Formalisme utilisé dans un diagramme d’interaction.
4.2.1 Diagrammes d’interactions du cas d’utilisation « S’authentifier »

FIGURE 4.2 – Diagramme d’interaction du cas d’utilisation« S’authentifier ».


4.2.2 Diagrammes d’interaction des cas d’utilisation de l’acteur Client
4.2.2.1 Cas d’utilisation « S’inscrire »

FIGURE 4.3 – Diagramme d’interaction du cas d’utilisation « S’inscrire ».


4.2.2.2 Cas d’utilisation « Demander une course »

FIGURE 4.4 – Diagramme d’interaction du cas d’utilisation « Demander une course ».


4.2.2.3 Cas d’utilisation « Annuler une course »

FIGURE 4.5 – Diagramme d’interaction du cas d’utilisation « Annuler une course ».


4.2.2.4 Cas d’utilisation « Gérer une course »

FIGURE 4.6 – Diagramme d’interaction du cas d’utilisation « Gérer une course ».


4.2.3 Diagrammes d’interaction des cas d’utilisation de l’acteur Chauffeur
4.2.3.1 Cas d’utilisation « Valider une course »

FIGURE 4.7 – Diagramme d’interaction du cas d’utilisation « Valider une course ».


4.2.3.2 Cas d’utilisation « Lancer/Signaler la fin d’une course »

FIGURE 4.8 – Diagramme d’interaction du cas d’utilisation « Lancer/Signaler la fin une cours ».
4.2.3.3 Cas d’utilisation « Annuler une course ».

FIGURE 4.9 – Diagramme d’interaction du cas d’utilisation « Annuler course ».


4.2.3.4 Cas d’utilisation « Manager une course ».

FIGURE 4.10 – Diagramme d’interaction du cas d’utilisation « Manager une course ».


4.2.4 Diagrammes d’interaction des cas d’utilisation de l’acteur Adminis-
trateur
4.2.4.1 Cas d’utilisation « Ajouter un chauffeur ».

FIGURE 4.11 – Diagramme d’interaction du cas d’utilisation « Ajouter un chauffeur ».


4.2.4.2 Cas d’utilisation « Supprimer un chauffeur ».

FIGURE 4.12 – Diagramme d’interaction du cas d’utilisation « Supprimer un chauffeur ».


4.2.4.3 « Gérer un chauffeur ».

FIGURE 4.13 – Diagramme d’interaction du cas d’utilisation « Gérer un chauffeur ».

4.3 Diagramme de classe de conception


L’objectif de cette étape est de produire le diagramme de classes qui servira pour
l’implémenta- tion, Une première ébauche du diagramme de classes de conception a déjà été
élaborée en parallèle du diagramme d’interaction . Il faut maintenant le compléter en précisant les
opérations privées des différentes classes. Il faut prendre en comptes les choix techniques, comme le
choix du langage de programmation, le choix des différentes bibliothèques utilisées (notamment
pour l’implémentation de l’interface graphique)[9].
FIGURE 4.14 – Diagramme de classe de conception.

4.4 le modèle relationnel

4.5 Règles de dérivation du modèle relationnel à partir d’un


modèle de classes
Dans cette section, nous procédons à la construction pas à pas du modèle relationnel
implé- mentant la base de données de notre application à partir du modèle de classes obtenues.
Les régles utilisées pour le passage sont :

4.5.1 Présence de la cardinalité « * » sur un côté de l’association


1. Chaque classe se transforme en une relation.

2. Chaque attribut de classe se transforme en un champs de relation.

3. L’identifiant de la classe qui est associée à la cardinalité « 1 » devient une clé étrangère dans
l’autre classe
En appliquant cette règle à notre modèle, nous obtenons les relations suivantes :

• Clients( idPersonne, Nom, Prenom, Datedenaissance,Login,MotdePasse,Numtel,


NumCompte) Où :
NumCompte est une clé étrangère qui fait référence au schéma de relation ComptesBancaires.

• Chauffeurs( idPersonne, Nom, Prenom, Datedenaissance,Login,MotdePasse, Numtel,


idCourse) Où :
idCourse est une clé étrangère qui fait référence au schéma de relation course.

• Notifications(idNotification, Objet)

• Types(NomT, Coutunitaire)

• Courses(idCourse, PointdeDepartCl, DestinationCl, Datedepart, Heuredepart


idPersonne,Matricule) Où :
idPersonne est une clé étrangère qui fait référence aux deux schémas de relation Chauffeurs et
Clients. Matricule est une clé étrangère qui fait référence au schéma de relation Véhicules

• Vehicules(Matricule,Marque, Modèle, Couleur, NomT


) Où :
NomT est une clé étrangère qui fait référence au schéma de relation Types.

• ComptesBancaires(idCompte,Domiciliation)

4.5.2 Présence de la cardinalité « * » sur les deux côtés


1. Chaque classe se transforme en une relation.

2. Chaque attribut de classe se transforme en un champs de relation.

3. L’association se transforme en une relation qui aura comme champs. l’identifiant de chacune
des deux classes (plus d’éventuels autres attributs)

En appliquant cette règle à notre modèle, nous obtenons les relations suivantes :

• Affecter( idPersonne, Matricule, Datedebut,Datefin)


Où :
idPersonne est une clé étrangère qui fait référence au schéma de relation Chauffeurs.
Matricule est une clé étrangère qui fait référence au schéma de relation Véhicules.

• Echanger( i dPersonne,idNotification,Datenotif,Heure,TypeNotif )
Où :
idPersonne est une clé étrangère qui fait référence aux deux schémas de relation Clients et
Chauffeurs.
idNotification est une clé étrangère qui fait référence au schéma de relation Notifications.
4.5.3 Présence d’une généralisation
1. Décomposition descendante (push-down) :

(a) Créer une relation pour chaque sous type


(b) Chaque relation se compose des attributs génériques et des attributs spécifiques

En appliquant cette règle à notre modèle, nous obtenons les relations suivantes :

• Clients (idpersonne,Nom, Prenom, Datedenaissance, Login,MotdePasse, Numtel)


• Chauffeurs (idpersonne,Nom, Prenom, Datedenaissance,Login,MotdePasse,Numtel)

2. Décomposition ascendante (push-up) :

(a) Créer une relation avec tous les attributs des classes.
(b) Ajouter un attribut pour distinguer les types des objets

En appliquant cette règle à notre modèle, nous obtenons les relations suivantes :

• Personnes(idpersonne, typepersonne, Nom, Prenom, Datedenaissance, Login, Motde-


Passe,Numtel)

3. Décomposition par distinction :

(a) Créer une relation par classe et les relier par des associations

En appliquant cette règle à notre modèle, nous obtenons les relations suivantes :

• Personnes(idpersonne, Nom, Prenom, Datedenaissance, Login,MotdePasse,Numtel)

• Clients (idPersonne)

• Chauffeurs (idPersonne)

où idPersonne est une clé étrangère qui fait référence au schéma de relation Personne.

Enfin ,le modèle obtenue :

• Clients( idPersonne, Nom, Prenom, Datedenaissance, Login,MotdePasse,Numtel


NumCompte) Où :
NumCompte est une clé étrangère qui fait référence au schéma de relation ComptesBancaires.

• Chauffeurs( idPersonne, Nom, Prenom, Datedenaissance, Numtel,Login,MotdePasse,


idCourse) Où :
idCourse est une clé étrangère qui fait référence au schéma de relation course.
• Notifications(idNotification, Objet)

• Types(NomT, Coutunitaire)

• Courses(idCourse, PointdeDepartCl, DestinationCl, Datedepart, Heuredepart


idPersonne,Matricule) Où :
idPersonne est une clé étrangère qui fait référence aux deux schémas de relation Chauffeurs et
Clients.
Matricule est une clé étrangère qui fait référence au schéma de relation Véhicules

• Affecter( idPersonne, Matricule, Datedebut,Datefin)


Où :
idPersonne est une clé étrangère qui fait référence au schéma de relation Chauffeurs.
Matricule est une clé étrangère qui fait référence au schéma de relation Véhicules.

• Echanger( i dPersonne,idNotification,Datenotif,Heure,TypeNotif )
Où :
idPersonne est une clé étrangère qui fait référence aux deux schémas de relation Clients et
Chauffeurs.
idNotification est une clé étrangère qui fait référence au schéma de relation Notifications.

• Vehicules(Matricule,Marque, Modèle, Couleur, NomT


) Où :
NomT est une clé étrangère qui fait référence au schéma de relation Types.

• ComptesBancaires(idCompte,Domiciliation)

4.6 Conclusion
Ce chapitre a permis de clôturer la phase de conception. Nous avons mis en avant les inter-
actions entre les différents objets constituant notre application. Par la suite, nous avons defini les
relations entre les entités et nous avons conçu le diagramme de classes de conception donnant ainsi
une vue plus structurée des éléments qui formeront la base de données liée à l’application Quick
Taxi.
Chapitre 5

Réalisation

5.1 Introduction
Après avoir achevé la phase conception, nous entamons dans ce chapitre la phase réalisation
de l’application Quick Taxi. Nous allons spécifié en premier les outils, les langages et les techniques
utilisés et enfin les différentes interfaces qui correspondent a l’application Quick Taxi .

5.2 Environnement du développement

5.2.1 Netbeans
Netbeans est un Environnement de Développement Intégré (EDI). Il permet la prise en charge
de divers langages de programmation tels le C, C++, et XML. Cet environnement est disponible
sous différents systèmes d’exploitation. Il constitue une plate forme qui permet le développement
d’applications spécifiques et il offre toutes les facilitées d’un IDE moderne.[10]

5.2.2 Android Studio


Android Studio est un environnement de développement permetant de développer des appli-
cations android. Il permet d’éditer les fichiers Java et les fichiers de configuration d’une application
mobile. Il fournit les outils nécessaires pour la création de tout type d’application android [11].

5.2.3 WampServer
Wamp server est une plateforme de développement Web dynamique qui permet le fonctionne-
ment local des scripts PHP. cet plateforme comporte deux serveurs (Apache et MySQL) et possède
également PHPMyadmin pour la gestion des bases de données relationnelles [12].

MYSQL est un système de Gestion de Base de Données (SGBD) permettant d’entreposer des
données de manière structurée (base de données, table, champ, enregistrement, etc.). L’accès aux
information stockées se fait via un langage spécifique nommé SQL (Structured Query Language).
Dans la réalisation de l’application Quick Taxi le choix de MYSQL est fait grâce à ses divers
avantages [13].

5.3 Outils de développement

5.3.1 JDK
Le Java Development Kit (JDK) est un ensemble de bibliothèques logicielles de base du
langage de programmation Java , ainsi que les outils nécessaires pour la compilation du code Java
qui est transformé en bytecode destiné à la machine virtuelle Java.[14]

5.3.2 SDK
Les initiales SDK signifient "Software Development Kit" ou kit de développement logiciel, il
s’agit d’un ensemble d’outils utilisés par les programmeurs pour réaliser et tester des applications
Android. [15]

5.3.3 AVD
L’Android Virtual Device est un émulateur de terminal sous Android.
C’est un outil indispensable pour le développement mobile. A chaque version d’Android est
associée une version de l’émulateur, permettant au développeur de voir exactement à quoi
ressemblera son application sur un matériel réel [16].

5.4 Langage de programmation

5.4.1 JAVA
Java est un langage de programmation Orienté Objet qui reprend en grande partie la syntaxe
du langage C++. Les logiciels écrits dans ce langage sont facilement portable sur plusieurs systèmes
d‘exploitation, comme il permet aussi de développer des applications autonomes [17].

5.4.2 XML
XML ( eXtensible Markup Language et traduit Langage à balises étendu, ou Langage à balises
extensible) Il s’agit d’un langage permettant de mettre en forme des documents grâce à des balises
[18].

5.4.3 JSON
JSON (Java Script Objet Notation) est un format léger d’échange de données, il permet de re-
présenter les informations de façon structurée ,il est basé sur un sous ensemble de langage de pro-
grammation JavaScript ces propriétés font de JSON un langage d’échange de données idéal [19].

5.4.4 PHP
PHP est un langage de programmation libre créé pour les développeurs web mais pouvant
également fonctionner comme n’importe quel langage interprété de façon locale. PHP est un
langage impératif orienté objet [20].

5.5 Présentation des interfaces


Les interfaces graphiques d’une application sont très importantes dans la mesure où elles per-
mettent de faciliter le dialogue entre l’utilisateur et la machine ainsi que d’améliorer les perfor-
mances de l’application. Dans la conception des interfaces de l’application Quick Taxi, nous avons
respecté un ensemble des choix ergonomiques comme la lisibilité, la compréhensibilité, etc. Dans
ce qui suit, une présentation de quelques interfaces de l’application est donnée.

5.5.1 Interface d’authentification


Cette première figure présente l’interface d’authentification dans laquelle on entre un login et
un mot de passe pour commencer à utiliser notre application. Cette interface constitue la fenêtre
d’accueil de notre application. A travers cette fenêtre les deux utilisateurs le chauffeur ainsi que le
client s’authentifient pour utiliser l’application.

FIGURE 5.1 – Interface d’authentification.

5.6 Espace client

5.6.1 Interface d’inscription


Ces deux interfaces ont pour but l’ajout du client s’il ne figure pas dans la BDD.
FIGURE 5.2 – Interface d’inscription.

5.6.2 Interface du choix de l’itinéraire


Dans cette interface le client entre les adresses constituant l’itinéraire.

FIGURE 5.3 – Interface de saisie.

5.6.3 Interface du choix du type de Véhicule


L’interface ci-dessous représente une liste de type de véhicules ,le client sélectionnera le type
de son choix
FIGURE 5.4 – Liste de type de véhicule.

5.6.4 Interface d’attente et d’annulation de la course


A partir de cette interface le client attend son chauffeur, il peut aussi annuler la course s’il le
souhaite

FIGURE 5.5 – Interface d’attente/annulation.

5.7 Espace chauffeur

5.7.1 Interface d’acceuil


L’interface d’acceuil du chauffeur nous pourrons voir le nom et prenom du chauffeur ainsi que
sa photo et sa disponibilité, il peut aussi consulté ses notification
FIGURE 5.6 – Interface d’accueil du client.

5.7.2 Interface de notification


Cette interface représente une notification d’une commande de course .

FIGURE 5.7 – A@chage de la notification.

5.7.3 Interface de lancement et annulation de la course


A partir de cette interface , le chauffeur peut lancer une course où en annuler une.
FIGURE 5.8 – Interface de lancement/annulation d’une course.

5.8 Espace administrateur

5.8.1 Interface d’authentification


Cette première figure présente l’interface d’authentification dans laquelle on doit entrer un
login et un mot de passe pour commencer la gestion des chauffeurs.

FIGURE 5.9 – Interface d’authentification.

5.8.2 Interface ajout et suppression d’un chauffeur


Afin d’ajouter un chauffeur,l’administrateur procède a l’introduction des informations qui sont
relatives aux chauffeurs à partir de l’interface ci-dessous. Les données seront ajouter automatique-
ment a la base de données à l’aide d’une requête dynamique.Tant dit que pour la suppression, l’ad-
ministrateur n’aura qu’à sélectionner le chauffeur qu’il veut supprimer de la liste des chauffeurs,
puis il valide en appuyant sur « Supprimer », ce dernier sera supprimé automatiquement de la
base de donnée.

FIGURE 5.10 – Interfaces d’ajout et suppression.

5.9 Conclusion
À travers ce chapitre, nous avons présenté les différents environnements de développement,
les outils et langage de programmation utilisés pour la réalisation de l’application Quick Taxi ainsi
que les interfaces graphique les plus importantes.
Conclusion Générale

L’objectif de ce travail consiste à simplifier la gestion des véhicule de Transport avec Chauf-
feur, à travers l’application mobile Quick Taxi qui met en relation directe les clients et les
chauffeurs. Cette dernière permet de géolocaliser, via un Smartphone, le véhicule le plus proche de
soi pour en- suite le réserver. L’application propose deux processus d’inscription. Un pour les
chauffeurs, et qui est géré par l’administrateur, et l’autre pour les clients. Ces derniers peuvent
réserver un véhicule de leurs choix en quelques secondes. Pour cela ils ont juste à ouvrir
l’application, entrer leur adresse de destination et choisir parmi une liste de chauffeurs disponibles à
proximité . Une fois ces derniers acceptent le trajet, le passager peut choisir dans la liste des
conducteur celui qui lui convient.

Pour mettre en œuvre ce projet, on été amené dans un premier lieu a une étude axée sur les gé-
néralités des applications mobiles. Ce qui nous a permis d’approfondir nos connaissances et d’en
savoir plus sur ces concepts. Nous avons établie, par la suite, une étude comparative des applica-
tions semblables à la nôtre afin de présenter la problématique et l’objectif de la présente étude.

Nous avons traité, tout au long de ce travail, les fonctionnalités de Quick Taxi après avoir effectué
une analyse des besoins pour la réalisation de notre application. Ces fonctionnalités appelés « Cas
d’utilisation », ont été traduites en différents diagrammes UML. Une fois ces dernières recensées
nous avons présenté la conception de notre application par les diagrammes de séquence système
pour l’enchainement des opérations, le modèle de domaine dans lequel nous avons identifié les en-
tités de notre système, le diagramme de classes participantes pour le lien entre les cas d’utilisation
et les maquettes IHM. Ces opérations nous ont permis la modélisation des diagrammes d’interac-
tions ainsi que le diagramme de classes de conception. La méthodologie utilisé a été conduite par
les méthodes agiles qui offrent une planification souple et ouverte au changement afin d’évaluer la
progression du projet.

Cette expérience a été une occasion enrichissante dans notre parcours universitaire. Elle nous a
permis de nous familiariser avec les notions de développement informatique . Afin de concrétiser
notre application, nous avons utilisé des outils et langages de programmation, tels que NetBeans
pour les interfaces de l’administrateur, Android Studio pour les interfaces du client et du chauffeur
et, enfin, WampServer pour la gestion des bases de données.

De ce qui précède, il est di@cile de prétendre avoir eu une solution idéale. Toutefois, nous espé-
rons avoir répondu tant soi peu à la problématique posée et confirmé nos hypothèses. En effet, ce
travail étant une œuvre humaine, n’est pas un modèle unique et parfait, c’est pourquoi nous restons
ouverts à toutes les critiques et sommes prêts à recevoir toutes les suggestions et remarques tendant
à améliorer d’avantage cette application.
Bibliographie

[1] Pascale Roques,Les cahiers du programmeurs, UML2 Modeliser une application web, 4e
edition Eyrolles.

[2] www.agiliste.fr/introduction-methodes-agiles visité le 09/01/2017

[3] https ://fr.wikipedia.org/wiki/Applicationmobile

[4] https ://www.taktilcommunication.com/blog/applications-mobile/definition-typologie-


applications-mobiles.html. visité le 05/03/2017

[5] https ://blog.clever-age.com/fr/2010/04/22/comment-aborder-un-projet-de-mobilite/ visité le


05/03/2017

[6] http ://www.appmobile.paris/criteres-pour-une-bonne-application-mobile visité le 02/03/2017

[7] http ://laurent-audibert.developpez.com/Cours-UML/ ?page=diagramme-cas-utilisationL2-2-


visité le 09/01/2017

[8] http ://laurent-audibert.developpez.com/Cours-UML/ ?page=diagrammes-interaction visité le


18/03/2017

[9] laurent-audibert.developpez.com/Cours-UML/ ?page=mise-en-oeuvre-uml visité le 18/03/2017

[10] https ://fr.wikipedia.org/wiki/NetBeans visité le 10/04/2017

[11] https ://fr.wikipedia.org/wiki/Android Studio visité le 10/04/2017

[12] https ://fr.wikipedia.org/wiki/WampServer visité le 10/04/2017

[13] https ://fr.wikipedia.org/wiki/MySQL visité le 10/04/2017

[14] https ://fr.wikipedia.org/wiki/JavaDevelopmentKit visité le 10/04/2017

[15] https ://developer.android.com/index.html?q=sdk visité le 10/04/2017

[16] http ://stacktips.com/tutorials/android/what-is-avd visité le 10/04/2017

[17] http ://ipeti.forumpro.fr/t21-definition-de-langage-java-java-script visité le 10/04/2017

[18] https ://fr.wikipedia.org/wiki/ExtensibleMarkupLanguage visité le 10/04/2017


[19] http ://www.json.org/json-fr.html visité le 10/04/2017

[20] https ://fr.wikipedia.org/wiki/PHP visité le 10/04/2017


Résumé

Dans le but d’automatiser la procédure de demande d’un véhicule de transport avec chauffeur,
et afin de faciliter l’interconnexion entre un client et un chauffeur, nous proposons de concevoir
et de mettre en œuvre une application mobile assurant la gestion des véhicules de transport avec
chauffeur. Pour ce faire, nous avons choisi de modéliser avec le formalisme UML 2 vu sa simplicité
et sa performance en matière de conception. Nous avons réalisé une application sous
l’environnement de développement Android Studio et Netbeans. Quant au serveur de base de
donnée, nous avons utilisé "MySQL". La réalisation des interfaces est faite avec les langages de
programmation Java et XML. L’IDE Android Studio et la base de données de l’application ont été
interconnectés en utilisant PHP et JSON.

Mots-clés : UML 2.0, Android, Méthodes agiles, Internet, map, application mobile.

Abstract

In order to automate the procedure for requesting a transport vehicle with a driver, and in order
to simplify the interconnection between a customer and a driver, we propose to design and
implement a mobile application that manages transport vehicles with drivers. For this fact we
chose to model with the UML 2 formalism considering its simplicity and its performance in
terms of design.
We realized an application under the development environment Android Studio and Netbeans and
as database server, we used "MySQL".
The realization of the interfaces is done with the programming languages Java and XML. The
IDE Android Studio and the database were interconnected using PHP and JSON.

Key word : UML2.0, Android, Agile methods, Internet, map, mobile app.