Conception et développement d’un système d’alerte et notification d’une tournée de bus

Résumé
Ce projet de fin d’étude présenté dans ce rapport est
proposé dans le cadre de l'obtention du diplôme
d'ingénieur en informatique à l'école supérieur privée
d'ingénierie et de technologies Esprit et réalisé au sein
de la societé Philae-IT.Ce projet consiste à la conception
et le développement d'une application de notification et
d’alerte intitulé« BusMapper » qui facilite la vie
quotidienne du citoyen dans le domaine de transport en
commun le cas du « bus » ici, tout en lui offrant
plusieurs services de localisation et d’alerte sur la
position du bus ou toute urgence concernant le traffic et
les tournées de bus.
Mots-clés:autobus,trafic,alerte,notification,SMS,JEE
Abstract
This graduation project is proposed in the context to
obtain the computer engineering degree at the Private
Higher School of Engineering and Technology ESPRIT
realized within Philae-IT. This project consists of the
design and the development of an application entitled
« BusMapper » which make easier the daily transit life
of citizens by providing a real-time bus positions and
multiple other services like traffic information
,upcoming departure times, about bus tour and gives the
user the opportunity to get notified even if he has no
connection directly by SMS …
Keywords: autobus, traffic, alert,
notification,SMS,2TUP, JEE..

PROJET DE FIN D’ETUDE
Pour l’obtention du diplôme national d’ingénieur en informatique
Conception et développement
d’un système d’alerte et notification
d’une tournée de bus
«BusMapper »
Réalisé par : Encadré par :
Bilel KHALED Mme Rym ALOUANE
M. Najeh KHALED
Année universitaire : 2015-2016

Signatures des encadrants
Encadrant PHILAE-IT
Encadrante ESPRIT
Mme Rim ALOUANE (Esprit)
Signature et cachet : M. Najeh KHALED
Signature : Mme. Rym ALOUANE

Dédicace
A mes très chers parents Habib et Dalila
Auxquels je dois ce que je suis. Que Dieu vous protège.
A mes chères frères Anis et Moetaz
Pour leur amour et leur incontestable appui.
A la mémoire de mes grands-parents
Puisse Dieu les accueillir dans son infinie Miséricorde.
A toute ma famille & A tous mes chers amis
Je dédie ce travail à toutes les personnes chères à mon cœur. Qu’elles trouvent
ici l’expression de toute ma gratitude et mon amour.

Remerciement
C’EST parce que j’ai beaucoup vénéré tous ceux qui m’ont encadré que je tiens vraiment
à leur faire part de toute ma reconnaissance, et plus spécialement, je tiens à remercier à travers
ces lignes :
M. Najeh KHALED , mon encadrant, pour son aide précieuse et le temps qu’il m’a alloué
pour me guider et m’aider pour m’intégrer dans l’environnement ,ses efficaces conseils et son
dévouement qui m’ont permis à bien mener ce travail.
Mme. Rym ALOUANE , mon encadrante de l’université à qui j’adresse un hommage
particulier pour sa disponibilité ,ses suggestions et ses remarques.
M. Clément TRUNG, je porte un remerciement particulier à qui n’a cessé de suivre chacun de
mes pas tout au long de ce projet, pour ses encouragements, ses conseils sa rigueur dans le
travail.
A tous ceux qui, directement ou indirectement, ont aidé à la finalisation de ce travail
A Messieurs les membres de l’honorable jury qu’ils trouvent ici l’expression de ma
gratitude pour avoir accepté de juger mon travail

Table des matières
INTRODUCTION GENERALE.......................................................................................................... 1
Chapitre 1: ETAT DE L’ART ............................................................................................................. 3
I. Cadre du projet ............................................................................................................................. 4
II. Présentation de la société accueillante..................................................................................... 4
1. Présentation générale................................................................................................................ 4
2. Domaine d’activité : .................................................................................................................. 5
III. Etude de l’existant..................................................................................................................... 5
1. Ratp ............................................................................................................................................ 6
2. Moobee Bus................................................................................................................................ 6
IV. Problématique............................................................................................................................ 7
V. Solution proposée :........................................................................................................................ 8
VI. Méthodologie de développement.............................................................................................. 8
1. Un comparatif des méthodologies ............................................................................................ 8
2. Justification du choix de la méthodologie.............................................................................. 10
3. Application de la méthodologie 2TUP sur notre projet :..................................................... 12
4. Gestion de projet : Maven .......................................................................................................... 13
Chapitre 2: Analyse et spécification des besoins .............................................................................. 15
I. Spécification fonctionnelle.......................................................................................................... 16
1. Besoins fonctionnels ................................................................................................................ 16
2. Besoins non-fonctionnels......................................................................................................... 17
3. Modélisation des besoins......................................................................................................... 18
3.1 Identification des acteurs...................................................................................................... 18
3.2 Description des cas d’utilisation..................................................................................... 19
3.3 Diagramme de séquence système ................................................................................... 22
II. Spécification technique ........................................................................................................... 27
1. Choix technologique................................................................................................................ 27
1.1 Langage de développement............................................................................................. 27
1.2 Framework....................................................................................................................... 27
1.3 API Utilisées........................................................................................................................... 29
2. Choix Architectural................................................................................................................. 31
2.1 Architectures Multi-tiers ................................................................................................ 31

2.2 Architecture adoptée....................................................................................................... 32
Chapitre 3 : Etude conceptuelle......................................................................................................... 34
I. Conception préliminaire ............................................................................................................. 35
1. Diagramme de déploiement.................................................................................................... 35
2. Diagramme de classe d’analyse.............................................................................................. 36
II. Conception détaillé.................................................................................................................. 38
1. Les patrons de conception.......................................................................................................... 38
1.1 Service Locator...................................................................................................................... 38
1.2 Business Delegate................................................................................................................... 38
1.3 MVC (Model-View-Controller)............................................................................................ 38
2. Diagramme de séquence objet.................................................................................................... 39
2.1 Diagramme de séquence objet « Authentification »..................................................... 39
2.2 Diagramme de séquence objet « Afficher l’ensemble de notification » ...................... 40
2.3 Diagramme de séquence objet « gérer notification » ................................................... 41
Chapitre 4 : Codage et tests................................................................................................................ 43
I. Environnement de travail ............................................................................................................... 44
1. Environnement matériel ......................................................................................................... 44
2. Environnement logiciel ........................................................................................................... 44
II. Les nouvelles technologies utilisées :...................................................................................... 46
III. Chronogramme d’avancement du projet.............................................................................. 46
IV. Présentation des interfaces ..................................................................................................... 47
1. Interface accueil utilisateur .................................................................................................... 47
2. Interface Consultation du réseaux des stations sur Paris.................................................... 48
3. Interface traçage du plus court chemin................................................................................. 49
4. Interface consultation de la position du bus et notifications............................................... 50
5. Interface de gestions de notification ..................................................................................... 51
V. Tests et validation........................................................................................................................ 52
1. Test des API ............................................................................................................................. 52
2. Test de compatibilité mobile................................................................................................... 53
CONCLUSION et PERSPECTIVES................................................................................................. 55
Webographie........................................................................................................................................ 56
Glossaire............................................................................................................................................... 57

Liste des figures
Figure 1 : Logo de la société Philae-IT.............................................................................................. 4
Figure 2 :Logo Ratp .............................................................................................................................. 6
Figure 3:Logo Mobee............................................................................................................................ 7
Figure 4 : Le processus de développement en Y............................................................................... 11
Figure 5 : Application de la méthodologie 2TUP sur notre projet ................................................. 13
Figure 6 : Architecture du module web du projet............................................................................ 14
Figure 7 : Diagramme de cas d'utilisation général........................................................................... 20
Figure 9 : Use Case Tracer le plus court chemin.............................................................................. 21
Figure 10 : Use Case Afficher l’ensemble de notifications............................................................... 22
Figure 11: Diagramme de séquence "Authentification".................................................................. 23
Figure 12 : Diagramme de séquence système tracer le plus court chemin..................................... 24
Figure 13 Diagramme de séquence système afficher ensemble de notification ............................. 25
Figure 14.2 Diagramme de séquence système simuler une visite touristique en 3d ..................... 26
Figure 15: Logo Java........................................................................................................................... 27
Figure 16: Logo Hibernate ................................................................................................................. 28
Figure 17 : logo JSF framework......................................................................................................... 29
Figure 18 : logo Google Maps............................................................................................................. 29
Figure 19 : logo MapsHere ................................................................................................................. 30
Figure 20 : logo OpenStreetMap........................................................................................................ 30
Figure 21 : logo de Twilio ................................................................................................................... 31
Figure 22 : Schéma de l'architecture 3-tierces adoptée ................................................................... 32
Figure 23 : Diagramme de déploiement ............................................................................................ 35
Figure 24 : Diagramme de classe ....................................................................................................... 37
Figure 25 Diagramme séquence objet Authentification................................................................... 40
Figure 26:Diagramme séquence objet « afficher ensemble de notification »................................. 41
Figure 27 Diagramme séquence objet « gérer les notifications »................................................... 42
Figure 28 : Chronogramme du projet ............................................................................................... 46
Figure 29 : Interface d'accueil utilisateur ......................................................................................... 47
Figure 30 : Interface consultation du réseau des stations sur Paris................................................ 48
Figure 31: Interface traçage du plus court chemin .......................................................................... 49
Figure 32: Interface consultation de la position du bus................................................................... 50
Figure 33: Interface gestion de notifications..................................................................................... 51
Figure 35 : Interface de test avec l'outil Postmanp .......................................................................... 52
Figure 36:Interface de test de compatibilité mobile sur un iphone 5 ............................................. 53
Figure 37:Test de compatibilité sur une ipad ................................................................................... 54

Liste des tableaux
Tableau 1 : Comparatif des méthodologies....................................................................................... 10
Tableau 2 : Identification des acteurs................................................................................................ 18
Tableau 3: Afficher l’ensemble de notifications ............................................................................... 22
Tableau 4: Environnement de travail matériel................................................................................. 44
Tableau 5: Environnement de travail logiciel................................................................................... 44

Introduction générale
1
INTRODUCTION GENERALE
La révolution numérique ces dernières années a connu une croissance exponentielle
soutenue avec le développement de l’Internet mobile, du big data et l’apparition de l’open data.
Tout cela modifie profondément les manières traditionnelles de l’usage des différents services
à l’instar du transport en commun. Ces évolutions font émerger de nouvelles solutions au profit
des sociétés de transport afin de bien gérer la mobilité des voyageurs et créer d’autres usages
comme les flux urbains, les systèmes d'information voyageur, la gestion de flottes de transport
collectif, l’aide à la gestion du trafic et l'optimisation de l'utilisation des infrastructures de
transport.
En effet ces nouveaux systèmes qui ont vu le jour sont connus sous le nom de systèmes de
transport intelligents (STI) [1] qui désignent les applications des nouvelles technologies de
l'information et de la communication au domaine des transports. On les dit "Intelligents" parce
que leur développement repose sur des fonctions généralement associées à l'intelligence :
capacité sensorielles, mémoire, communication, traitement de l'information et comportement
adaptatif.
On trouve les STI dans plusieurs champs d'activité incorporé avec leurs différents services
offerts aux gestionnaires et aux usagers (particuliers et professionnels) à l’instar du traitement
de l’information en situation normale et perturbée ainsi que la gestion de flotte de transport
collectif pour expérimenter de nouveaux dispositifs (transports multimodaux, carrefours
intelligents, parkings dynamiques, voitures connectées et autonomes…) au service d’une
mobilité plus harmonieuse pour le citoyen et l’environnement.
Le présent document se décompose en quatre grands chapitres qui retracent de façon logique et
chronologique les différents travaux menés pendant ce projet :
Dans le premier chapitre, nous commençant par introduire le cadre général du travail à savoir
la présentation de l’organisme d’accueil et le contexte du projet et en second lieu une étude de
l'art sera décrite, qui comprendra une étude de l’existant, les problématiques posées, la solution
proposée et enfin la méthodologie adoptée pour la réalisation.
Dans le deuxième chapitre, nous exposerons l'analyse des besoins tout en établissant une étude
préliminaire divisée en deux ses deux grand aspect fonctionnel et technique : la spécification
fonctionnelle qui contiendra une énumération des besoins fonctionnels et non fonctionnels de

Introduction générale
2
la solution proposée avec une illustration des diagrammes de ca<s d’utilisation et la
spécification technique qui comprendra les choix technologiques et architecturaux.
Au cours du troisième chapitre nous traiterons l’étude conceptuelle qui sera présenté sur
deux étapes, la conception préliminaire suivie de la conception détaillée.
Dans le quatrième et le dernier chapitre, nous détaillerons la phase du codage .Tout d'abord,
l’accent sera mise sur l’environnement du travail. Ensuite, une énumération de la totalité des
fonctionnalités offertes par l'application sera détaillée à travers l’illustration de quelques
interfaces. Par la suite, une description de l’étape des tests et de validation sera présentée.

4
Introduction
Ce présent chapitre sera dédié à la mise en place de notre projet dans son cadre général. Dans
une première section, nous présenterons le cadre du projet. La deuxième section a pour objectif
de donner un aperçu sur la société accueillante. La troisième section définit les besoins à
remplir par l’application où nous exposons une étude de l’existant ensuite nous aborderons la
problématique et les différents objectifs et enfin nous mettrons en exergue la méthodologie
retenue.
I. Cadre du projet
Ce projet rentre dans le cadre de projet de fin d’études à l’école supérieure privée d’ingénierie
et de technologies (ESPRIT), en vue de l’obtention du diplôme d’ingénieur en informatique. Il
consiste en l’étude, la conception et l’implémentation d’une plateforme présentant un système
de notification et alerte d’une tournée de bus sous forme d'une application web.
Le projet s’est déroulé au sein de la société PHILAE-IT, durant la période du 17 décembre 2015
au 26 Mai 2016.
II. Présentation de la société accueillante
1. Présentation générale
Philae-IT est un cabinet de conseil en système informatique à forte valeur ajoutée
regroupe aujourd’hui plus de 15 ingénieurs .Elle a été fondée en 2014 par une équipe de
professionnels expérimentés et est actuellement installée à Paris et à Monastir.
Figure 1 : Logo de la société Philae-IT

5
2. Domaine d’activité :
PHILAE-IT met tout son expertise technique et son savoir-faire au service de ses clients
pour leur apporter l'assistance technique nécessaire pour la réussite de leurs projets SI et son
domaine d’activité se présente sur 3 axes d’expertises principaux.
Expertise en architecture IT :
 Choix et validation d'architectures
 Stratégie de migration technologique
Expertise en développement et intégration d’applications:
 Accompagnement au démarrage du projet
 Choix et validation de solutions techniques ( DA, SFD, SFT)
 Implémentation de la solution technique
 Stratégie de tests
 Recette
 Audit et diagnostic: Sécurité, Performance, code quality.
Expertise organisationnelle:
 Méthodologies Agiles: coaching SCRUM, XP
 Organisation de projet d'externalisation IT nearshore et offshore
III. Etude de l’existant
Après avoir fait une étude approfondie sur les applications mises à la disposition de
l’utilisateur, nous présentons une étude comparative et critique des applications existantes et
les plus utilisés en France afin d'introduire notre solution proposée.
A l’attention de cette partie, nous effectuons une description et une analyse de quelques
applications existante pour faciliter les transports au quotidien avec les autobus.
Les applications les plus connus et les plus utilisées en France, offrant des services optimisés
pour la géolocalisation des bus et les horaires des tournées sont :

6
1. Ratp
C’est l’application web de référence pour les transports en communs (RER, Métro, Bus) à Paris
et aux banlieues. C’est l’application officielle de la RATP elle est très complète et dispose de
nombreuses fonctionnalités (Horaires, Itinéraires, Prochains passages…)
Figure 2 :Logo Ratp
Les avantages :
 Géolocalisation des stations RER, Métro, Bus, Tramway et plan des métros.
 Consultation des horaires des prochains passages (bus + métro).
 Consultation du bulletin de trafic routier.
 Localisation des stations de bus et de métro les plus proches.
 Personnalisation de la page d’accueil pour consulter les horaires favoris.
Les Inconvénients :
 Manque de clarté et d’ergonomie de l’interface.
 Absence de plusieurs fonctionnalités innovantes comme l’alerte routier, communication
des utilisateurs entre eux.
 Absence de notification de l’arrivée du bus ou la possibilité de visualiser sa position en
temps réel.
2. Moobee Bus
C’est une application web munie d’une carte interactive complète qui permet d’avoir un visuel
rapide sur la disposition des stations de bus ainsi que les horaires de leurs départs et arrivés.

7
Figure 3:Logo Mobee
Les avantages :
 Présence de l’information sur le trafic ainsi que les éventuelles perturbations routières.
 Définition du trajet, cela dit, possibilité de définir des « Lignes favorites »
 Identification des arrêts de bus et de métro par itinéraire.
 Affichage de la plus proche station depuis la position actuelle de l’utilisateur jusqu’au
un autre point.
Les inconvénients :
 L’application est payante .
 Absence d’une alternative de notification en cas de rupture de connexion .
IV. Problématique
Dans le contexte concurrentiel d'aujourd'hui entre les agences d’autobus pour bien gagner
sa part de clientèle du marché et dans le but de résoudre les problème détectés dans les solutions
concurrente en offrant une application gratuite , complète et fonctionnelle en toute
circonstance « absence de connexion » notre client a trouvé indispensable de développer une
application qui va résoudre les problèmes un peu liés aux perturbations routières en notifiant
l’utilisateur sur le trafic, aux horaires exactes des tournées de bus ainsi le suivi du bus.
La résolution de ces problèmes et l’ajout de nouveaux services assurera la fidélisation de ses
utilisateurs ainsi étendra la flotte de sa clientèle pour faire face à la concurrence accru des
autre agences de bus.

8
V. Solution proposée :
L'objectif de notre projet est de développer une application qui présente un ensemble de services
pour faciliter la vie aux voyageurs et qui permettra :
 La consultation des différents horaires des tournées de bus
 L’affichage en temps réel la position du bus sur une ligne particulière
 L’affichage du temps restant jusqu’au passage du prochain bus à l’arrêt
 Le traçage du plus court chemin que l’utilisateur doit prendre depuis sa position
actuelle pour aller à une station de bus tout en choisissant le mode de parcours et en
afficher la durée ainsi que la distance à parcourir
 Simulation d’une visite touristique en 3D sur la ligne 58 qui relie Châtelet à Vanves.
 L’affichage de l’ensemble de réseau de station de bus sur toute Paris à l’aide d’une
carte interactif.
 Gestion du trafic routière et des urgences
 Notification par SMS ou par PUSH l’utilisateur de l’approche de son bus ou d’une
autre information urgente.
VI. Méthodologie de développement
Lors du développement de tout projet il est impérativement conseillé afin d’assurer son
évolution de suivre un processus et une méthode de conception afin de créer des applications
consistantes, d’estimer le temps de développement et d’augmenter la productivité.
1. Un comparatif des méthodologies
Au cours de ce paragraphe nous allons essayer d’énumérer quelques-unes des méthodes de
développement agiles les plus connues, afin de dégager les différences entre elles et ceci en
fournissant un tableau comparatif de ces dernières. Le tableau suivant, Tableau 1, compare
sommairement les méthodes courantes suivantes :
– Two Track Unified Process (2TUP)
– Extreme Programming (XP)
– Rational Unified Process (RUP)

9
Méthode Description Points clés Inconvénients
XP
-Ensemble de bonne
pratiques de
développement (travail
en équipe, transfert de
compétences).
-Ciblage de projet :
moins de 10 personnes.
Le développement est piloté
par les besoins du client.
- Les équipes sont réduites et
centrées sur le développement
par binôme.
-Les builds sont journaliers.
-Amélioration constante,
adaptabilité et portabilité aux
modifications
Focalisation sur l’aspect
individuel du
développement, au
détriment d’une vue
globale et des pratiques de
management ou de
formalisation.
Risque de manquer de
contrôle et de structuration
en laissant les
développeurs trop libres de
dériver par rapport aux
fonctions de l’application
RUP -Elaboré par rational.
-Le RUP est à la fois une
méthodologie et un outil
prêt à l’emploi
-Cible de projet : plus de
10 personnes.
– Processus complet et assisté
à la fois par des outils
– Les Rôles sont bien définis.
Lourd, largement étendu,
il peut être difficile à
mettre en œuvre de façon
spécifique.
Efficace pour les gros
projets qui génèrent
beaucoup de
documentation

10
2TUP
-Propose un cycle de
développement en Y.
-Cible les projets de
toutes tailles.
Propose un cycle de
développement qui sépare les
aspects fonctionnels des
aspects techniques.
-Itératif
-Consacre une large place à la
technique et à la gestion du
risque.
-Définit les profils des
intervenants, les livrables, les
plannings ainsi que les
prototypes.
Validation trop tardive et
présente un risque de
devenir très couteuses si
des erreurs sont constatées.
Tableau 1 : Comparatif des méthodologies
2. Justification du choix de la méthodologie
Notre choix méthodologique s’est porté sur le processus unifié 2TUP pour les raisons suivantes:
–Le projet est de nature assez spéciale vu le besoin d’une adéquation totale entres les exigences
techniques et les besoins en terme de fonctionnalités chez l’utilisateur.
-Le projet présente au niveau technique une certaine complexité vu la nécessité de prévoir une
phase pour l’étude des exigences technique qu’il faut prendre en considération.
-A un instant donné, pour vérifier de l’adaptation entre l’architecture technique et les besoins
de l’utilisateur on doit faire une liaison entre le modèle technique et le modèle fonctionnel.
Se basant sur un cycle en Y et vu que le projet ne présente pas une complexité au niveau
fonctionnel, la méthodologie 2TUP est la plus adaptée.

11
Définition de 2TUP
2TUP signifie « 2 tracks Unified Process » .C’est un processus qui répond aux caractéristiques
du processus Unifié et qui apporte une réponse aux contraintes de changement continuel
imposées aux systèmes d’information de l’entreprise. En ce sens, il renforce le contrôle sur les
capacités d’évolution et de correction de tels systèmes.
On dit que la méthode 2TUP est générique c’est-à-dire qu’elle définit un certain nombre de
critères de développement que chaque société peut par la suite personnaliser afin de créer son
propre processus plus adapté à ses besoins.
« 2 tracks » signifient littéralement que le processus suit deux chemins. Il s’agit des « chemins
fonctionnels » et « d’architecture technique », qui correspondent aux deux axes de changement
imposé au système d’information.
Figure 4 : Le processus de développement en Y [2]
Branche fonctionnelle :
Cette branche est constituée de :
 La capture des besoins fonctionnels qui produisent le modèle des besoins focalisés sur
le métier des utilisateurs. Elle qualifie, au plus tôt, le risque de produire un système
inadapté aux utilisateurs.

12
 L’analyse consiste à étudier précisément la spécification fonctionnelle et non-
fonctionnel de manière à obtenir une idée de ce que va réaliser le système en terme de
métier.
Branche technique :
Cette branche se constitue de :
 La capture des besoins techniques, qui dénombre la totalité des contraintes sur les choix
de la conception du système.
 Le matériel et les outils sélectionnés ainsi que la prise en compte des contraintes
d’intégration avec l’existant s’il y’en a.
Branche conception :
Cette branche est constituée de :
 La conception préliminaire, qui représente une étape très importante et délicate,
puisqu’au cours du quelle on intègre notre modèle d’analyse fonctionnelle dans
l’architecture technique de façon à tracer la cartographie des composants du système à
développer.
 La conception détaillée, qui étudie ensuite comment réaliser chaque composant.
 L’étape de codage, qui assure la production de ces composants.
3. Application de la méthodologie 2TUP sur notre projet :
La figure suivante décrit la méthodologie 2TUP exploitées, cela, en décortiquant les traces de
chacune de ces branches.

13
Figure 5 : Application de la méthodologie 2TUP sur notre projet
4. Gestion de projet : Maven
Pour bien gérer et organiser notre projet et ses dépendances, nous avons choisi d’utiliser le
gestionnaire : « Maven ». C’est un outil populaire, utilisé largement dans le monde Java pour
le déploiement et la construction des projets. Il a été conçu de façon à supprimer les tâches
difficiles du processus de construction. Maven utilise une approche déclarative, où le contenu
et la structure du projet sont décrits, plutôt qu'une approche par tâche utilisée par exemple par
« Ant » ou les fichiers make traditionnels. Cela aide à mettre en place des standards de
développement au niveau d'une société et réduit le temps nécessaire pour l’écriture, le maintien
des scripts de construction et de déploiement et le projet.

14
Figure 6 : Architecture du module web du projet
Conclusion
Tout au long de ce chapitre, nous avons mis le projet dans son cadre, présenté l’organisme
d’accueil. Ensuite, on a consacré une partie pour l’étude et l’analyse des différentes applications
proposées au marché et dégagé les problématiques et la solution proposée.
A la fin, après l’exploitation de la comparaison des méthodologies, on a opté pour la méthode
de développement 2TUP.

15
Chapitre 2: Analyse et spécification
des besoins

16
Introduction
Avant d’entamer le développement de notre projet, il est nécessaire de bien identifier,
caractériser et challenger l'ensemble des besoins des utilisateurs, de prendre en compte
l'environnement du projet et de clarifier les fonctions à intégrer dans le projet. Comme indiqué
dans le cadre méthodique dans le chapitre précédent, nous allons suivre la méthodologie 2TUP.
L'étude préliminaire est la toute première étape de ce processus. Elle consiste à effectuer un
premier repérage des besoins fonctionnels et techniques.
I. Spécification fonctionnelle
L’analyse de ce sujet nous a permis l’identification des différents besoins auxquels doit
répondre notre application. Ces besoins dégagés sont classés en deux catégories à savoir les
besoins fonctionnels et les besoins non fonctionnels.
1. Besoins fonctionnels
Un besoin fonctionnel est un besoin spécifiant une action qu’un système doit être capable
d’effectuer, sans considérer aucune contrainte physique : besoin spécifiant un comportement
d’entrée/sortie d’un système. Dans cette partie, nous allons énumérer les différents besoins que
doit assurer le système. Dans notre contexte le système doit permettre les tâches suivantes:
 Gestion de profil Client : Le système doit permettre à l'utilisateur de gérer son
espace personnel où il peut ajouter et modifier des informations lui concernant ainsi que le
changement de la station du bus auquel il va s’abonner pour recevoir les notifications .
 Visualisation du réseau de station de bus de la RATP sur toute la France : Le
système doit permettre à l'utilisateur de voir un large éventail de station de bus sur une carte
interactive sous forme de bulles contenant le nombre de station relatif à chaque région
,département et rue ainsi d’autres informations entre autre les coordonnées géographiques de
chaque station pour un éventuel traçage du chemin le plus court vers celle-ci selon sa position
géographique dans la carte.
 Simulation d’une visite touristique réelle en 3d sur une ligne : Le système doit
permettre à l'utilisateur de visualiser sur deux cartes une simulation d’une visite touristique en
3D avec possibilité de navigation sur les rues et changement d’angle.

17
 Traçage du plus court chemin vers une station : Le système doit permettre à
l'utilisateur de tracer le plus court chemin depuis sa position vers une station ,afficher une
estimation de la durée ,la distance et un tableau de la direction à prendre chaque fois selon le
moyen qu’il a choisi voiture ,à pied ou bicyclette.
 Consultation des horaires des tournées de chaque journée : Le système doit
permettre à l'utilisateur de consulter la liste de début/fin de chaque tournée de bus sur chaque
station.
 Echange de message avec les autres utilisateurs par chat : Le système doit
permettre aux utilisateurs connectés l’échange les messages de chat en temps réel .
 Notification générale par mode push : Le système doit notifier l’utilisateur de la
position actuelle du bus ainsi que la suivante station et l’estimation du temps de son arrivée.
 Notification personnalisée par mode push : Le système doit notifier les utilisateurs
abonnés à une station N+1 de l’approchement du bus quand elle est à la station N .
 Génération de statistiques et rapport concernant les utilisateurs : Le système doit
générer à l’administrateur les statistiques des utilisateurs filtrés par tranche d’âge, sexe et
fonction ainsi des rapports concernant leurs informations.
 Envoie des notifications : Le système doit permettre à l’administrateur l’envoi des
files d’informations urgentes concernant les lignes de bus , d’envoyer des notifications
personnalisées par station ou des SMS aux utilisateurs .
2. Besoins non-fonctionnels
Une fois les besoins fonctionnels sont bien définis, les besoins non fonctionnels doivent être
pris en compte tout au long du processus de développement de l’application à savoir :
 Rapidité
L'application doit optimiser les traitements pour avoir un temps de génération raisonnable des
cartes aussi que l’affichage des notifications.
 Convivialité
Notre application doit fournir une interface ergonomique et conviviale (une interface facile à
manipuler, des boutons ainsi que des libellés significatifs, un design agréable etc…)

18
 Efficacité
L'application doit être fonctionnelle indépendamment de toutes circonstances pouvant
entourer l'utilisateur même en absence d’internet.
 Modularité :
L'application doit être bien structurée en module pour assurer une meilleure lisibilité, une
diminution du risque d'erreur et une possibilité de tests sélectifs.
 L'Evolutivité
Il est intéressant que le logiciel assure un pouvoir d’évolution, de développement et
d’amélioration au cours du temps et ce selon les besoins de l’utilisateur.
3. Modélisation des besoins
3.1 Identification des acteurs
Les acteurs sont les utilisateurs directs de l'application, ils interagissent avec à travers les
interfaces utilisateurs. Dans ce projet, nous nous sommes confrontés à deux acteurs qui
interagissent avec cette solution l’utilisateur et l'administrateur :
Acteur Description
Utilisateur
- C’est l’acteur principal de l’application, il a un ensemble complet de
services à consommer comme le traçage du plus court chemin entre deux
points. Il peut aussi consulter l’état de trafic, régler ses paramètres de
notification, simuler des visites touristiques virtuelles, communiquer
avec les autres utilisateurs connectés, consulter les horaires de tournées
de bus.
Administrateur - Il est le gérant des services, avec des outils incorporés à son interface
il assurera le bon fonctionnement des services offerts au client.
Tableau 2 : Tableau d'identification des acteurs

19
3.2 Description des cas d’utilisation
Dans le diagramme du cas d’utilisation général nous regroupons tous les cas d’utilisations
basique pour avoir une vue globale du fonctionnement de notre système et afin de mettre en
évidence les éventuels relations qui peuvent les relier.
La figure ci-dessous illustre le cas d’utilisation général de l’application où le diagramme décrit
les grandes fonctionnalités de l’application de point de vue des acteurs, mais n’expose pas de
façon détaillée le dialogue entre les acteurs. Dans le chapitre qui suit nous détaillerons, avec
raffinement itératif, différents cas d’utilisation.

20
Cas d’utilisation général :
Figure 7 : Diagramme de cas d'utilisation général

21
Cas d’utilisation raffiné « Tracer le plus court chemin»
Figure 8 : Use Case Tracer le plus court chemin
Cas n°2 : Tracer plus court chemin
Acteur : Utilisateur
But : Ce cas d’utilisation permet à un client de trouver le plus court chemin vers une station de bus , la
distance à parcourir ainsi que la durée pour y arriver .
Déclencheur : L’utilisateur choisit le type de parcours, adresse de début/arrivé ou tout simplement déplace les deux
marqueurs sur la carte .
Flot d’information : Scénario 1 :
1. L’Utilisateur pointe le marqueur A sur sa position actuelle et déplace le marqueur B sur sa
destination.
2. Le système géolocalise , les deux points ensuite calcule la distance et la durée.
3. Le système trace un polyligne présentant les directions à suivre et affiche un tableau avec les
étapes à suivre chaque fois
Scénario 2 :
1. L’utilisateur peut effectuer un filtrage du mode de parcours.
2. L’utilisateur saisit l’adresse de départ et l’adresse d’arrivée.
3. Le système géolocalise le plus court chemin disponibles selon le mode choisit par l’utilisateur.
4. Le système trace le plus court chemin et affiche la distance et la durée pour y arriver.
Extension Si le(s) mot(s) saisi(s) n’est (sont) pas trouvé(s) le système affiche un message indiquant qu’aucun
endroits est disponible.
Tableau 4 : Tracer le plus court chemin

22
Cas d’utilisation raffiné « Afficher l’ensemble de notifications»
Figure 9 : Use Case Afficher l’ensemble de notifications
Cas n°3 : Afficher l’ensemble de notifications
Acteur : Utilisateur
But : Ce cas d’utilisation permet à un client de trouver liste des horaires des tournées de bus, afficher le trafic
routier ainsi que les actualités concernant sa ligne de bus
Déclencheur : L’utilisateur choisit l’affichage de l’ensemble de notification
Flot d’information :
1. l’utilisateur sélectionne la zone de notification
2. le système affiche une carte interactive avec le trafic et les perturbations routière.
3 .le système récupèrent les notifications générales et les affiches en dessous de la carte
4. le système récupère les notifications propres à l’utilisateur connecté et les affiche.
Extension L’état du trafic n’est pas à jour, un message d’alerte s’affiche pour notifier l’utilisateur
Tableau 3: Afficher l’ensemble de notifications
3.3 Diagramme de séquence système
Le diagramme de séquence système décrit la dynamique du système, en effet il décrit
l'interaction entre les acteurs et le système.

23
 Cas authentification
Le diagramme ci-dessous présente la première opération à effectuer par l’utilisateur. En fait,
ce dernier doit saisir son login et son mot de passe pour se connecter à l’application. S’il
n’est pas reconnu par le système il ne sera pas autorisé à y accéder et un message d’erreur
lui sera affiché.
Figure 10: Diagramme de séquence "Authentification"

24
 Cas tracer le plus court chemin
Ce diagramme présente l’opération à effectuer par l’utilisateur s’il veut rechercher le plus court
chemin pour une station choisie après une authentification sur le système. En fait, ce dernier
doit choisir le mode de parcours vers son point d’arrivé, il devra donc soit déplacer les deux
marqueurs mises à sa disposition le premier sur son point de départ l’autre sur une des stations
de la ligne de bus 58 sachant que tous les résultats fournis sont consommés depuis l’API
Google Direction.
Figure 11 : Diagramme de séquence système tracer le plus court chemin

25
 Cas afficher ensemble de notification
Ce diagramme présente l’opération à effectuer par l’utilisateur s’il veut afficher l’ensemble de
notification comme le trafic routier et les informations concernant les tournées pour lignes de
bus .En fait, ce dernier doit sélectionner son dashboard sachant que tous les résultats
fournis sont consommés depuis l’API(MapsHere) ou par notre base de données.
Figure 12 Diagramme de séquence système afficher ensemble de notification

26
 Cas simuler une visite touristique en 3D
Ce diagramme présente l’opération à effectuer par l’utilisateur s’il veut lancer une simulation
3d d’une tournée de bus sur la ligne 58 sur Paris depuis Châtelet vers Vanves .En fait, ce dernier
doit sélectionner Start a Touristic Tour pour commencer la visite.
Figure 13 Diagramme de séquence système simuler une visite touristique en 3d

27
II. Spécification technique
1. Choix technologique
1.1 Langage de développement
Java est un langage de développement orienté objet représentant la synthèse des bons côtés de
plusieurs langage de programmation notamment C++ qui a réussi à obtenir une très grande
notoriété en seulement quelques années grâce à ses qualités. De nos jours, Java est largement
utilisé notamment en entreprise et pour les applications mobiles.
Figure 14: Logo Java
1.2 Framework
Pour le besoin d’implémentation et de mise en place de notre application nous avons eu
recours à l’utilisation des frameworks suivants :
 JEE (Java Entreprise Edition)
Java EE est un ensemble de spécifications pour la technologie Java d’oracle qui sont
implémentés par différent conteneurs présentant les environnements d’exécution pour le code
tout en offrant différents services aux composants qu’ils hébergent : injection de dépendances,
gestion de cycles de vie...
La communication entre l’infrastructure de Java EE et les autres composants se fait tout
en respectant un certain standard (fichiers archives) avant d'être déployés. Java EE
étant une partie sur tout un ensemble de la plate-forme Java SE, favorise l’utilisation des API
de cette dernière par n'importe quel composant de Java EE

28
 Hibernate
Hibernate est le framework open-source Java utilisé pour gérer la persistance des données des
différents systèmes développés lors de ce projet aussi la notion d’ORM (Object Relational
Mapping) ,y est également très souvent associés il s’agit d’une technique permettant de faire
correspondre des tables ,des objets et leurs relations dans une base de données relationnelles.
Ce framework est très largement utilisé, tant dans le domaine de l’entreprise que dans les
différents projets open-source.
Dans notre architecture, « Hibernate » sera associé au système de gestion de base de
données (SGBD) : « Mysql ». Il s’agit là encore d’un SGBD Open-Source qui a une
excellente réputation auprès des programmeurs.
Figure 15: Logo Hibernate
 Java Server Faces (JSF)
Java Server Faces (JSF) [2] est un Framework java ayant pour objectif le développement des
applications web. JSF est un Framework MVC basé sur la notion des composants, c'est-à-dire
que l’état d’un composant est enregistré lors de rendu de la page, pour être ensuite restauré au
retour de la requête. Il est constitué essentiellement de :
 Un ensemble d’APIs pour la gestion des composants, des événements, de la validation des
entrées, la conversion des sorties et l’accessibilité ainsi que la navigation entre les vues.
 De jeux de composants standards HTML et Core.
 De bibliothèques de balises JSP pour la construction de vues JSF.
 Un modèle événementiel coté serveur.
 Les Managed-Beans qui présentent la couche de contrôle de JSF.
 Langage d’expression Unifié (EL) qui sert à la liaison entre la vue et les managed-
beans.

29
Il existe plusieurs composants additionnels qui peuvent être utilisés avec JSF on peut citer
JBOSS Richfaces et Ajax4JSF qui sont composés d’un ensemble de composants riches, libres
et supportant Ajax.
Figure 16 : logo JSF framework
1.3 API Utilisées
Pour assurer l’exploitation des différents services de géocodage en temps réel, l’obtention des
différentes stations du réseau de la RATP sur toute la France, l’affichage de trafic routier
quotidien on a eu recours à plusieurs API.
 Google Maps API
Google Maps [3] est un service gratuit de cartographie en ligne offrant un ensemble d’api
performants et simple qui ont contribué à bien cerner et accomplir les fonctionnalités de notre
projet.
L’usage de ces différent API se résume comme suit :
 Google Direction API , en effet, avec les fonctionnalité de géocodage implémenter
par cette api notre application retournera le plus court chemin entre la position de
l’utilisateur et la station cible ainsi que la durée et la distance .
 Google Street View API, qui a permis l’affichage et la navigation en 3d dans une
fenêtre au fur et au mesure avec le déplacement du bus pour en simuler une visite
touristique sur la ligne 58 .
Figure 17 : logo Google Maps

30
 MapsHere API
Maps Here [4] est une carte interactive qui affiche en temps réel les trafics routiers, les
constructions en cours et les perturbations tout en affichant leurs dates de début et de fin.
Figure 18 : logo MapsHere
 OpenStreetMap
Nous avons eu recourt à cette carte qui présente un outil très puissant pour afficher l’ensemble de
toutes les stations de bus d’une manière simple et élégante à travers des bulles interactives
Figure 19 : logo OpenStreetMap
L’Api nous permet :
 La recherche des endroits : renvoie une liste des lieux basés sur la localisation ou la
recherche de données saisies par l’utilisateur.
 L’affichage en détail des endroits (restaurent cafés…) suite à une simple requête
concernant un lieu spécifique, y compris l’affichage des avis et notes des utilisateurs.
 Ajouter un endroit : il nous permet d’ajouter les données dans la base de données
de Google Places avec ses outils simple de vérification.
 Consulter les cartes interactives des stations de bus sur tout Paris ainsi leurs
coordonnées.

31
 Twilio
L'API Twilio [5] est une API RESTful qui offre des fonctionnalités vocaux et d’SMS aux
applications .C’est une plateforme en tant que service PaaS ,Twilio permet aux développeurs la
programmation de la réception et l’envoi des appels téléphonique ou SMS préprogrammés
utilisant des services web à partir de sa bibliothèque . Les services de Twilio sont accessibles
à travers des requêtes HTTP et facturés par utilisation.
Figure 20 : logo de Twilio
L’api nous a permis :
 L’envoi d’SMS personnalisés et ciblés pour les abonnées d’une station choisie.
 L’envoi d’SMS d’urgence ciblés pour les utilisateurs
 L’envoi d’SMS de notification à l’utilisateur de l’approche de son bus et estimation
du temps de son arrivé afin qu’il se prépare à l’attraper.
2. Choix Architectural
2.1Architectures Multi-tiers
JEE propose différentes structures afin de développer une application web sur des bases
saines. Typiquement les architectures JEE spécifient plusieurs couches complémentaires qui
comportent différents éléments ou composants de l’application JEE déployée
Ces architectures se découpent selon différents scénarios :
– Une architecture à deux niveaux, comportant un serveur web JEE et un serveur de base de
de données. Ce modèle est de type modèle client-serveur.
– Une architecture à trois niveaux, plus précisément de trois couches.
La couche présentation : associée au client qui de fait est dit « léger » dans la mesure où il
n’assume aucune fonction de traitement

32
 La couche métier : liée au serveur, qui dans de nombreux cas est un serveur d’application
JEE qui va exécuter tous les calculs ou faire des requêtes vers d’autres serveurs additionnels
(exemple vers des SGBD).
 La couche de données : liée au serveur de base de données (SGBD) :
– Une architecture n-tiers, comportant souvent la partie cliente sur laquelle s’exécute des
applications clientes, un serveur web JEE, un serveur métier JEE et un serveur de base de
données
2.2 Architecture adoptée
L’architecture adopté dans notre développement sera à trois niveaux afin d’avoir un découpage
entre les différentes parties de l’application, à savoir la présentation, le métier et les données. On
a choisi Wildfly [7] comme serveur d’application pour notre couche métier.
Cette séparation respectant tout à fait le paradigme MVC une évolution des niveaux
indépendamment les uns des autres sera possible à l’avenir et permettra donc une meilleure
évolutivité de la solution.
De plus ce type d’architecture est relativement extensible, en vue par exemple de
l’insertion de nouveaux tiers. La figure ci-dessous provenant du site internet de Sun
Microsystems illustre l’architecture adoptée par la plupart des applications web J2EE.
Figure 21 : Schéma de l'architecture 3-tierces adoptée [6]

33
Conclusion
Dans ce chapitre, les besoins ont été présentés à travers les diagrammes des cas d’utilisations
et éclairci avec des descriptions textuelles. Ensuite on a exposé les grands choix technologiques
et architecturaux. Ce chapitre donne alors le feu vert pour l’amorçage de l’étude conceptuelle
qui sera décrite dans le chapitre suivant.

34
Chapitre 3 : Etude conceptuelle

35
Introduction
La phase de conception se voit parmi les phases les plus importantes dans un cycle de vie
logiciel. Par souci de clarté, nous débuterons la conception préliminaire de l'application.
Ensuite, une présentation de la modélisation de la conception détaillée sera faite. Ces
fonctionnalités seront donc notre but majeur de ce chapitre.
I. Conception préliminaire
Cette étape est la plus importante du processus 2TUP vu qu’elle en représente le cœur. En effet,
dans cette étape, nous allons abandonner nos deux branches gauche et droite afin de faire la
fusion entre les deux études technique et fonctionnelle. Cependant, nous allons développer les
catégories d’analyse en couches logicielles conformément au modèle retenu de la solution
technique tout en restant le plus indépendant possible des outils de développement.
1. Diagramme de déploiement
Le diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de
l'infrastructure physique par le système et la manière dont les composants du système sont
répartis ainsi que la relation entre eux. Les éléments utilisés par un diagramme de déploiement
sont principalement les nœuds, les composants, les associations. Les caractéristiques des
ressources matérielles physiques et des supports de communication peuvent être précisées par
stéréotype.
Figure 22 : Diagramme de déploiement

36
2. Diagramme de classe d’analyse
Le diagramme de classe est le point central dans un développement orienté objet. En analyse,
il a pour objectif de décrire la structure des entités manipulées par les utilisateurs. Il décrit la
structure de système à travers les classes, les attributs et les relations qui les associent.

37
Figure 23 : Diagramme de classe

38
II. Conception détaillé
1. Les patrons de conception
Un patron de conception est un concept qui vise à résoudre plusieurs problèmes selon l’approche
orienté objet son but principale est de minimiser le temps de développement d’un logiciel tout en
augmentant la qualité de résultat, en appliquant des meilleurs pratiques qui sont déjà existantes à des
problèmes courants de conception
1.1 Service Locator
On a utilisé ce design pattern, afin de localiser et centralise l’accès aux objets dans l’arbre JNDI et pour
que le système devienne plus flexible en nous facilitant ses récupération. En effet, au lieu d’ajouter le
code technique à chaque classe de notre couche métier on le place dans une seule classe .On a optimisé
aussi son fonctionnement en utilisant un cache.
1.2 Business Delegate
On a utilisé le design pattern Business Delegate après l’isolement de notre code JNDI dans un
Service Locator pour déléguer son appel. L’idée de ce pattern est de regrouper à un seul endroit tous
les appels distants de nos méthodes de la couche métier et d’avoir une classe Business Delegate par
service qui redéfinit chaque méthode distante.
1.3 MVC (Model-View-Controller)
Le patron d'architecture modèle-vue-contrôleur (en abrégé MVC, en anglais model-view-controller) est
très recommandé dans l'univers JEE. C’est un modèle destiné à répondre aux besoins des applications
interactives en séparant les problématiques liées aux différents composants au sein de
leur architecture respective.
La vue : cette partie représente l'interface utilisateur avec lequel l'utilisateur réagit. Elle n'exécute aucun
traitement, se contente simplement d'afficher les résultats provenant des objets model .
Le modèle : les modèle représente les données de l'application et définit la logique avec laquelle les
données seront manipulés tout en offrant les méthodes pour la récupération et la mise à jour de ces
données.
Le contrôleur : le contrôleur est responsable sur la gestion de l'interaction avec l'utilisateur. En effet,
il constitue l’intermédiaire entre les objets vue et les objets modèle et c'est dans cette partie l’interaction
entre ces deux objets se fait .Cela dit, les objets contrôleurs reçoivent les requêtes utilisateurs puis
déterminent quelles parties des objets vues et modèles sont requises.

39
Figure 24 Modèle MVC 2
2. Diagramme de séquence objet
Nous présentons ici quelques diagrammes de séquence objet :
2.1 Diagramme de séquence objet « Authentification »
Le diagramme exposé ci-dessous explique le scénario d’authentification, le client remplit le
formulaire de saisie de données et confirme l’authentification. Le contrôleur vérifie si les
données sont validées puis redirige l’utilisateur vers la page d’accueil. Dans le cas contraire, le
formulaire affiche des messages d’erreur éventuels

40
Figure 24 Diagramme séquence objet Authentification
2.2 Diagramme de séquence objet « Afficher l’ensemble de notification »
Le diagramme présenté ci-dessous explique le scénario de consulter l’ensemble des
notifications (urgences, actualités, informations, trafic...) .L’utilisateur accède tout d’abord à
l’accueil de l’application cela dit son espace personnel et puis il accède à la section dashboard.
Le contrôleur vérifie l’id de l’utilisateur connecté et exécute l’action qui permet d’afficher
l’ensemble de notifications cela dit le contrôleur communique avec les entités nécessaires pour
récupérer les notifications générales ainsi que les notifications propres à l’utilisateur connecté
et le trafic.

41
Figure 25:Diagramme séquence objet « afficher ensemble de notification »
2.3 Diagramme de séquence objet « gérer notification »
Le diagramme présenté ci-dessous explique le scénario de la gestion des notifications de
l’administrateur après son authentification il accède à sa section de gestion nommée dashboard.
L’administrateur saisit le contenue de l’actualité à déposer pour tous les utilisateurs puis appuis
sur la confirmation d’envoi, il peut aussi les supprimer . Deux autres critères de notifications
sont mis à sa disposition « notification personnalisée » par station en mode (PUSH ou SMS).
Le contrôleur vérifie le type de notification et exécute l’action qui permet de les persister dans
la base de données ou d’initier la fonctionnalité SMS et consommer ses services.

42
Figure 26 Diagramme séquence objet « gérer les notifications »
Conclusion
L’étape de la conception est la phase la plus importante dans la résolution d’un problème donné.
La réalisation de cette phase nous a permis de décortiquer avec précision l’architecture de
l’application ainsi que la réalisation de sa conception détaillée, cela nous a permis d’entamer
la phase d’implémentation sur la base d’une architecture stable et delà passer à la phase de
construction.
Durant le chapitre qui va suivre nous allant essayer d’accomplir l’implémentation de notre
application et nous allons décrire l’environnement du travail matériel et logiciel.

43
Chapitre 4 : Codage et tests

44
Introduction
Au cours de cette dernière partie, nous exposons le travail accompli. Nous commençons par la
présentation de l’environnement de travail logiciel et matériel ainsi que les différents choix
techniques utilisés pendant cette phase. Puis, nous décrivons le procédé suivi pour la réalisation
en présentant les différents problèmes rencontrés au cours de la réalisation que pendant la
validation.
I. Environnement de travail
1. Environnement matériel
Pour l’implémentation de notre projet on a choisi :
Entité Description
Pc Portable
 Modèle : Lenovo 8070
 Processeur : Intel CORE i7-4510U (2.60 GHZ)
 Ram : 12 Go.
 Disque dur : 1 Téra
Tableau 4: Environnement de travail matériel
2. Environnement logiciel
Pour la réalisation de notre projet on a opté à utiliser l’environnement logiciel décrit dans le
tableau ci-dessous :
Langage de développement Java
Framework développement Web JEE
Conception et Conception Visual Paradigm
Outil de développement Eclipse Luna
SGBD Mysql
Serveur d’application Wildfly 8.1.0
Editeur Microsoft office Word 2013
Tableau 5: Environnement de travail logiciel

45
I. Choix techniques
 XHTML :
XHTML est un langage de balisage ses racines puisent dans HTML qui sert à écrire des pages
web, mais avec une reformulation en XML strict. Ceci signifie qu’un document XHTML est
un document XML qui respecte un schéma strict.
 Javascript :
Javascript est un langage dynamique orienté objet de programmation de script employé dans
les pages web interactives et aussi dans les serveurs. Sa syntaxe s'inspire des langages Java et
C. Dans cette application on l’a utilisé largement pour coder plusieurs fonctions javascript(le
mouvement des bus, pour l’affichage des stations, pour la consommation des API de direction
et pour l’algorithme du plus court chemin..)
 Templating « Facelets »
Facelets est une technologie de présentation pour le développement d'applications web en Java.
En plus de son introduction de nouvelles fonctionnalités au-delà de celles présentés par JSF elle
offre la possibilité de créer des composants personnalisés sans taper aucune ligne de code
JAVA et un système de templating.
Le templating offre plusieurs avantages :
 Uniformiser la structure des pages
 Simplifier la mise à jour : une modification dans le template se propage automatiquement
dans toutes les pages qui l'utilisent.
 Gain en productivité : moins de code à écrire : une page ne contient que ce qui lui est
propre.
Un template est une page xhtml ordinaire puisqu’il est basé sur xml, qui définit la structure du
document avec des emplacements spécifiques où les pages qui utilisent ces templates (pages
clientes) insèreront leur contenu. On utilise un ensemble de tag pour la définition de tels
emplacements.
 GTFS ( General Transit Feed Specification)
GTFS [8] présente une spécification générale d’un format libre conçu par Google afin d’intégrer
et optimiser les données du transport commun cela dit les horaires de voyage ainsi que les

46
informations géographique associées comme les tracés des lignes de transport, les itinéraires
des arrêts de bus ainsi que d’autre informations utiles codées sous forme de plusieurs fichiers
textes standards à l’instar de (agency ,routes,trips,shapes,stoptimes…) .
II. Les nouvelles technologies utilisées :
Les nouvelles technologies que nous avons utilisé dans le développement sont :
 JQuery :
JQuery est une bibliothèque JavaScript libre qui porte sur l'interaction entre JavaScript
(comprenant AJAX) et HTML, et a pour but de simplifier des commandes communes de
JavaScript.
 Primefaces:
PrimeFaces est un framework open source, qui peut être assimilé à une suite de composants
d'interfaces riches pour JSF et apporte des éléments très basiques d'UI. PrimeFaces va plus loin
et propose plus de 100 composants, plus de 35 thèmes, des composants mobiles et bien plus
encore. C'est actuellement de loin la suite pour JSF la plus populaire, ainsi qu'un outil graphique
très populaire partout pour le développement de Java Web.
III. Chronogramme d’avancement du projet
La figure ci-dessous présente le chronogramme d’avancement du projet où chaque branche de
cette figure représente la durée d’une tâche.
Figure 27 : Chronogramme du projet

47
IV. Présentation des interfaces
1. Interface accueil utilisateur
Figure 28 : Interface d'accueil utilisateur
 Description
- C’est l’interface d’accueil de l’utilisateur à gauche on trouve les différent services proposées
par l’application, elle présente un tableau affichant les différents messages d’urgences et au-
dessous une carte regroupant le trafic routier ainsi que les différentes perturbations routière sur
tout Paris avec la date de début et de fin de chaque perturbation.

48
2. Interface Consultation du réseaux des stations sur Paris
Figure 29 : Interface consultation du réseau des stations sur Paris
 Description
Cette interface permet à l’utilisateur de visualiser le nombre et les itinéraires de tous les points
de station de bus sur la région de l’île-de -France et ses départements.

49
3. Interface traçage du plus court chemin
Figure 30: Interface traçage du plus court chemin
 Description
Cette interface permet à l’utilisateur le traçage automatique avec les directions à droite du plus
court chemin depuis sa position vers n’importe quel position en l’occurrence les stations de bus
ici juste en glissant les deux marqueurs rouge et vert afin d’obtenir la durée et la distance à
parcourir pour y arriver tout en avoir la possibilité de choisir son mode de parcours entre
bicyclette , voiture ou à pieds.

50
4. Interface consultation de la position du bus et notifications
Figure 31: Interface consultation de la position du bus
 Description
Cette interface permet à l’utilisateur ou à l’administrateur de suivre la position en temps réel du
bus, sa position sur la carte ainsi que la station suivante du bus et la durée en minutes pour y
arriver.
En haut on a aussi une bulle contenant le nombre de notification concernant la station sur
laquelle il est abonné.

51
5. Interface de gestions de notification
Figure 32: Interface gestion de notifications
 Description
Cette interface présente l’accueil de l’administrateur et lui permet de gérer le flux de
notification des utilisateurs entre autre supprimer ou envoyer différent type de notifications aux
utilisateurs concernant les perturbations du réseau de transport commun, des tournées de bus,
des offres d’excursions…
La notification est raffinée à 3 niveaux : notification générale (pour tous les utilisateurs),
notification par station (juste pour les abonnées de la station choisi) et notification par SMS .

52
V. Tests et validation
1. Test des API
Afin de tester nos résultats des requêtes http fournis par les web services développés à l’aide
de Google Maps , nous avons utilisés le client REST Postman et voici ci-dessous un résultat de
test d’une requête http permettant l’affichage de la réponse du serveur Google après une requête
demandant la géolocalisation de la direction entre un point de départ et un autre d’arrivé.
Figure 33 : Interface de test avec l'outil Postman

53
2. Test de compatibilité mobile
Le test d’adéquation à l’utilisation sur appareil mobile de notre application sur 2 appareils
mobile un iphone 5 et une ipad afin de nous a donné des apercus lors de son usage à partir
d’une appareil mobile et comme resultats on peut dire que :
 Les fenêtres sont correctement configurées.
 Le contenu de la page est adapté à la largeur de l’appareil.
 Le texte sur la page est lisible.
 Les liens et les cibles sont suffisamment grands et conviviaux.
Figure 34:Interface de test de compatibilité mobile sur un iphone 5

54
Figure 35:Test de compatibilité sur une ipad
Conclusion
Au bout de ce chapitre, nous avons parcourus les différents outils utilisés afin d’assurer
l’implémentation de l’application. Nous avons décrit aussi, les différentes interfaces de notre
projet. Ainsi que les tests effectués.

55
CONCLUSION et PERSPECTIVES
Mon projet a consisté en la conception, le développement et l’intégration d’une application de
notification et d’alerte d’une tournée de bus pour le compte d’une société cliente, en guise
d’apporter une valeur ajoutée et un meilleur service plus moderne à ses clients.
Au cours de ce stage j’avais eu l’occasion de mieux comprendre la méthodologie de travail
ainsi que le processus de recherche
La mission la plus délicate était de s’intégrer avec les méthodologies de recherche, analyser les
significations et les buts du cahier de charge ainsi que les points pas encore
exploités ou dépassés afin de les incorporer ou les améliorer .Pour cela une grande partie de
mon travail a consisté à analyser les modèles ensuite à proposer un nouveau plus général.
Le processus du développement s’est basé essentiellement sur les directives de mon encadrant
sa persévérance ainsi que sa patiente afin de me montrer les bonnes pratiques de se lancer
dans des grands projets et d’extraction des besoins. Le fait de se baser sur des scénarios réels
de problèmes rencontrés concernant le transport public et de les collecter depuis une gamme
large de personnes de différents niveaux et des forums en ligne permet d’élargir l’espace des
connaissances et d’imagination pour l’ajout de nouveaux services innovants et créatifs.
Les apports du stage sont alors assez nombreux, on évoque donc la proposition d’un
nouveau modèle complet et fonctionnel en permanence à toutes les circonstances (rupture de
connexion) et l’imagination de nouveaux systèmes plus moderne et sophistiqué qui
remplaceront ceux qui existent déjà. Les apports personnels du stage concernant les
connaissances et les procédures du développement sur la plateforme de Java sont abondants
puisque on s’est impliqué dans les basses couches du système.
Certainement, comme perspectives, nous envisageons incorporer un module de GPS afin de
mieux suivre la position en temps réel du bus ainsi raffiner l’estimation de son arrivée et intégrer
les files d’attentes RabbitMq pour gérer le flux croissant des requêtes utilisateurs tout en gardant
les performances de nos serveurs.

56
Webographie
[1]“STI“ système de transport intelligent” http://www.transport-intelligent.net/ ,dernière visite
15/05/2016
[2] “Processus en Y “ http://jlafoss:e.developpez.com/Methodologie/2TUP/diagrame/ ,
dernière visite 15/01/2016
[2]“JSF” , https://dzone.com/refcardz/javaserver-faces-20 ,dernière visite 15/05/2016
[3]“Google Maps” https://developers.google.com/maps/documentation/ ,dernière visite
15/05/2016
[4]“ MapsHere “ “https://developer.here.com/rest-apis/. ,dernière visite 15/05/2016
[5]“ Twilio “ https://www.twilio.com/docs/libraries ,dernière visite 01/06/2016
[6]“Architecture 3 tiers“ http://jlafoss:e.developpez.com/java/developpement-n-tiers/plate-
forme-java-EE/, dernière visite 18/04/2016
[7]“Wildfly “ https://docs.jboss.org/author/display/WFLY8/ ,dernière visite 15/05/2016
[8]“GTFS” , http://www.normes-donnees-tc.org/category/gtfs/ ,dernière visite 15/05/2016

57
Glossaire
GTFS General Transit Feed Specification
RATP Régie autonome des transports parisiens
RER Réseau express régional,
JSF Java Server Faces
JPA Java Persistence Architecture
Xhtml eXtensible HyperText Markup Language
CSS Cascading Style Sheet
XML Extensible Markup Language JPQL Java Persistence
JEE Java Enterprise Edition

Conception et développement d’un système d’alerte et notification d’une tournée de bus

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Conception et développement d’un système d’alerte et notification d’une tournée de bus

Similaire à Conception et développement d’un système d’alerte et notification d’une tournée de bus (20)

Dernier

Dernier (20)

Conception et développement d’un système d’alerte et notification d’une tournée de bus