Table des matières

Sommaire
Introduction générale.................................................................................................................. 6

CHAPITRE1 : Etude préalable .................................................................................................. 7

1. Introduction : ................................................................................................................... 8

2. Présentation de la société : .............................................................................................. 8

3. Définition de la mission : ................................................................................................ 8

3.1. Présentation de l’application : .................................................................................. 8

3.2. Objectifs à atteindre : ............................................................................................... 8

3.3. Planning prévisionnel : ............................................................................................ 9

4. Etude de l’existant : ......................................................................................................... 9

4.1. Analyse de l’existant : .............................................................................................. 9

4.2. Critique de l’existant : ............................................................................................ 13

4.3. Solution proposée : ................................................................................................ 13

5. Conclusion :................................................................................................................... 14

CHAPITRE2 : Analyse des besoins ......................................................................................... 15

1. Introduction : ................................................................................................................. 16

2. Choix de la méthodologie de conception et justification : ........................................... 16

3. Identification des besoins : ............................................................................................ 16

3.1. Les besoins fonctionnels : ...................................................................................... 16

3.2. Les besoins non fonctionnels : ............................................................................... 17

4. Identification des acteurs :............................................................................................. 17

5. Diagrammes de cas d’utilisation : ................................................................................. 17

5.1. Digramme de cas d’utilisation relatif au pèlerin : .................................................. 18

4.1. Digramme de cas d’utilisation relatif à l’administrateur : ..................................... 21

6. Conclusion :................................................................................................................... 24

Page 1
Chapitre3 : Modélisation conceptuelle ..................................................................................... 25

1. Introduction : ................................................................................................................. 26

2. Analyse des cas d’utilisations : diagramme de séquence : ............................................ 26

2.1. Diagramme de séquence : ...................................................................................... 26

2.1.1. Digramme de séquence : « inscription » ............................................................ 26

2.1.2. Digramme de séquence : « authentification» ..................................................... 27

2.1.3. Digramme de séquence : « Réservation OMRA» .............................................. 28

2.1.4. Digramme de séquence : « Ajouter hôtel» ......................................................... 28

3. Modélisation conceptuelle des données : ...................................................................... 29

3.1. Dictionnaire des données : ..................................................................................... 29

3.2. Représentation des classes : ................................................................................... 31

3.3. Représentation des associations : ........................................................................... 34

3.4. Diagramme de classes : .......................................................................................... 35

4. Conclusion :................................................................................................................... 37

Chapitre4 : Réalisation ............................................................................................................. 38

1. Introduction : ................................................................................................................. 39

2. Environnement du travail : ............................................................................................ 39

2.1. Environnement matériel : ....................................................................................... 39

2.2. Environnement logiciel : ........................................................................................ 39

2.3. Choix des langages de programmation : ................................................................ 41

3. Architecture de l’application : ....................................................................................... 41

3.1. Conception architectural : ...................................................................................... 41

3.2. Architecturale du système : .................................................................................... 43

3.3. Enchainement des programmes : ........................................................................... 44

4. Description des interfaces de l’application en version web et mobile : ........................ 45

4.1. Les interfaces web : ............................................................................................... 45

4.2. Les interfaces mobiles : ......................................................................................... 52

Page 2
 5. Conclusion :................................................................................................................... 54

Conclusion générale ................................................................................................................. 55

BIBLIOGRAPHIE ................................................................................................................... 56

Page 3
 Liste des figures

Figure 1 : Application mobile RyanAir.................................................................................... 10

Figure 2 : Application mobile Kayak ....................................................................................... 11
Figure 3 : Site Web de « ARIANE voyage » ........................................................................... 11
Figure 4 : Interface de pré-réservation Hajj 2019_ court Séjour 5*......................................... 12
Figure 5 : L'interface de demande d’OMRA sur mesure ......................................................... 13
Figure 6 : diagramme de cas d’utilisation relatif au pèlerin ..................................................... 18
Figure 7 : Diagramme de cas d’utilisation relatif à l’administrateur ....................................... 21
Figure 8 : Diagramme de séquence "inscription" .................................................................... 27
Figure 9 : Digramme de séquence "authentification" .............................................................. 27
Figure 10 : Diagramme de séquence de réservation OMRA ................................................... 28
Figure 11 : Diagramme de séquence Ajouter Hôtel ................................................................. 29
Figure 12 : Diagramme de classe ............................................................................................. 36
Figure 13 : Modèle MVC ......................................................................................................... 42
Figure 14: laravel MVC ........................................................................................................... 44
Figure 15: Modèle navigationnel ............................................................................................. 45
Figure 16 : Interface accueil ..................................................................................................... 46
Figure 17:Interface créer un compte ........................................................................................ 46
Figure 18 : Interface se connecter ............................................................................................ 47
Figure 19 : Interface Hajj ......................................................................................................... 48
Figure 20 : Interface réservation .............................................................................................. 49
Figure 21 : Interface payement en ligne ................................................................................... 49
Figure 22 : Interface Hôtel ....................................................................................................... 50
Figure 23 : Interface d'accueil de l'administrateur ................................................................... 50
Figure 24 : Interface programmer Omra .................................................................................. 51
Figure 25 : Interface Ajouter Hôtel .......................................................................................... 51
Figure 26 : Interface accueil de l’application mobile ............................................................... 52
Figure 27 : Interface Authentification de l'application mobile ................................................ 53
Figure 28 : Interface d'inscription ............................................................................................ 54

Page 4
 Liste des tables
Tableau 1 : Planning prévisionnel .............................................................................................. 9
Tableau 2 : Dictionnaire de données ........................................................................................ 29
Tableau 3 : Les classes et leurs attributs .................................................................................. 32
Tableau 4: les associations ....................................................................................................... 34

Page 5
 Introduction générale
Durant ces dernières années, tous les secteurs connaissent une avance technologique
considérable grâce à l’informatique. C’est la science qui étudie les techniques du
traitement automatique de l’information. Elle joue un rôle important dans le
développement des entreprises en leur apportant un support important dans la gestion de
leurs systèmes d’information.
D’autre part, la communication sur internet évolue à une vitesse monumentale au fur et
à mesure des avancées technologique. Les téléphones portables sont devenus les
premiers média de masse dans le monde, puisqu’ils sont considérés comme un autre
support à générer des formes médiatiques. C’est ainsi que le développement
d’application mobile se charge de couvrir de nombreux besoins que peuvent exprimer
les utilisateurs dans leurs vies quotidiennes.
Les applications web de réservation en ligne pour les agences de voyages contribuent à
un rapprochement entre l’agence et les voyageurs dans l’objectif d’impliquer ces
derniers d’une manière plus directe dans le choix des voyages, des hôtels, des
promotions offertes, etc. En parallèle, développer une application mobile de réservation
en ligne peut être efficace pour de telles agences qui vont devenir sans doute des acteurs
modernes proches de leurs clients.
C’est dans ce cadre que se situe notre projet de fin d’étude qui consiste à développer
une plateforme de réservation en ligne des pèlerins en version web et mobile pour
faciliter la réservation des vols Hajj et Omra.
Pour ce faire, nous procédons par une étude théorique afin de mieux cerner le contexte
de notre travail. Cette étude fait partie des objectifs de notre rapport qui est subdivisé en
4 chapitre
• Le premier chapitre intitulé Etude Préalable qui se focalise sur une étude détaillée du
sujet traité.
• Le deuxième chapitre s’intéresse à l’analyse et spécification des besoins, ou nous
identifions les besoins fonctionnels et non fonctionnels auxquels doit répondre notre
application, en modélisant à travers le diagramme de cas d’utilisation.
• Le troisième chapitre présente la modélisation conceptuelle
• Le quatrième chapitre comporte la réalisation et la mise en œuvre de l’application

Page 6
CHAPITRE1 : Etude préalable
 1. Introduction :
Ce chapitre sera réservé pour donner une présentation générale de notre projet. Pour
cela nous commençons par la présentation de l’organisme d’accueil, la société française
<<Ariane voyages>>. Ensuite, nous définissons la mission de ce projet et les objectifs à
atteindre. Par ailleurs, nous présentons l’étude de l’existant qui concerne l’analyse de
l’existant ainsi que son critique. Enfin, nous détaillons la solution proposée.

2. Présentation de la société :
Ariane voyages, société à responsabilité limitée, est en activité depuis 2009. Etablie à
BAGNOLET (93170) 50 rue HOUCHE France, elle est spécialisée dans le secteur des
activités des agences de voyage. Ariane voyages est une agence spécialisée seulement
dans le pèlerinage « HAJJ » et « OMRA ». Elle propose des services de séjour et
circuits de déplacement Hajj et Omra des pèlerins.

3. Définition de la mission :

3.1. Présentation de l’application :

Dans le cadre de notre projet de fin d’étude, nous avons été appelées à concevoir et à
développer une application web mobile pour l’agence de voyage Ariane. Il s’agit de
développer une plateforme paramétrable d’inscription en ligne des voyageurs via le site
web de l’agence ou directement à partir d’une simple photo de passeport. Elle
permettra aussi la gestion des séjours (départs, arrivée, durée, vols, nombre de places
disponibles …). D’autre part, elle permettra de notifier les voyageurs en cas de
changement de vol, pour venir récupérer leurs passeports, pour ramener des documents
manquants ou concernant un règlement à faire. Quant à l’administrateur, cette
application lui permettra d’organiser et de planifier des voyages Hajj et Omra. Aussi,
elle lui permettra de suivre les réservations effectués pour un voyage Hajj ou Omra.

3.2. Objectifs à atteindre :

Les objectifs visés par notre application sont les suivantes :
• Permettre à l’administrateur de créer un profil et d’accès à tous les services :
historique des réservations, enregistrement des données de profil…
• Garantir une meilleure présentation des services fournis par le système.

Page 8
 • Faciliter et accélérer les opérations de réservation en les rendre possible via
un téléphone mobile.
• Faciliter le contact des clients de l’agence.
• Informer instantanément le client en cas de modifications de vols, le besoin
de ramener des documents manquant ou concernant des règlements à faire.

3.3. Planning prévisionnel :

La clé principale de réussite d’un projet est un bon planning. En effet, le planning aide à
bien subdiviser le travail et séparer les taches à réaliser.
Le tableau 1 montre le planning que nous avons adopté pour mener à bien notre projet.
Tableau 1 : Planning prévisionnel

Taches Février Mars Avril Mai

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Etude
préalable
Conception

Réalisation

Rédaction
du rapport

4. Etude de l’existant :
L’étude de l’existant est une étape fondamentale pour le développement des
applications. Elle nécessite une analyse détaillée du système existant suivie d’une
critique permettant de dégager ses points faibles. Dans le but de remédier aux
problèmes détectés, il faut définir des solutions requises ainsi que des suggestions
d’amélioration.
Cette partie s’articule autour de deux volets : analyse de l’existant et critique de
l’existant.

4.1. Analyse de l’existant :

4.1.1. Description d’exemples d’application web mobile de réservation en

ligne:
Aujourd’hui, le lancement mondial de nouvelles fonctionnalités mobiles permet au
voyageur de rechercher et réserver des vols avec les applications mobiles.

Page 9
Prenons l’exemple de RyanAir Cheap Flights, l’application la plus utilisée en Europe
d’après le classement IATA (Trafic Aérien Mondial et grands compagnie aériennes).
Cette application mobile permet aux voyageurs de faire une réservation en ligne d’un
voyage. Sur la carte d’embarquement Ryan Air figurera le nom de voyageur, le numéro
de la porte d’embarquement et celui des sièges, ces derniers sont attribués
aléatoirement, cela dit les voyageurs sont dans la possibilité de choisir leurs sièges mais
c’est un service payant.
La figure 1 montre l’interface de l’application RyanAir.

Figure 1 : Application mobile RyanAir

Comme deuxième exemple d’application web mobile de réservation en ligne, nous

citons Kayak qui effectue des recherches sur des centaines de sites de voyage afin de
satisfaire les critères de recherches fixes par l’internaute. Ce site permet de trouver des
vols, des hôtels, des séjours (vol+hôtel), des trains et le type de vol (aller simple , aller-
retour ou multi-directions, le nombre de voyageurs adultes et celui des enfants ainsi que
les dates de départ et de retour.
La figure 2 montre l’interface de l’application Kayak.

Page 10
 Figure 2 : Application mobile Kayak

4.1.2. Description
tion de l’application : web existante de « Ariane voyages » :
La société « Ariane voyages » permet de faire une réservation OMRA/HAJJ à travers
le site web www.partiralamecque.com.
www.partiralamecque.com Le pèlerin peut effectuer des réservations
réservation pour
un voyage OMRA/HAJJ programmé à l’avance ou faire une demande d’OMRA sur
mesure qui donne la main au pèlerin
p de proposer une OMRA à une date précise.
précise
La figure 3 montre la page d’accueil du site web partiralamecque.

Figure 3 : Site Web de « ARIANE voyage »

Page 11
Comme le montre la figure 3, l’interface d’accueil permet de consulter les voyages
programmés OMRA et HAJJ, les hôtels conventionnés avec l’agence, des vidéos pour
des voyages antérieurs et des informations utiles (centres de vaccinations, taxes
OMRA…). En consultant un voyage programmé d’OMRA ou HAJJ, l’utilisateur peut
effectuer une pré-réservation. Il doits alors remplir le formulaire présenté a la figure 4
en indiquant :
• Ses coordonnées (nom, prénom, adresse, email, téléphone)
• Le type de chambre (quadruple, triple ou double)
• Le nombre d’adultes et le nombre de bébés (-2 ans)
Suite à cette étapes, l’utilisateur peut visualiser un récapitulatif de pré-réservation
englobant, en plus des informations saisies, le cout totale du voyage.

Figure 4 : Interface de pré-réservation Hajj 2019_ court Séjour 5*

Comme le montre la figure 5, pour effectuer une demande d’OMRA sur mesure.
L’utilisateur doit saisir :
• Ses coordonnées (nom, prénom, téléphone et email).
• Les dates de départ et de retour souhaitées.
• Le nombre de personnes.
• Le budget par personne.

Page 12
 Figure 5 : L'interface de demande d’OMRA sur mesure

4.2. Critique de l’existant :

Aucun système de gestion n'est parfait. Tous ont leurs avantages et leurs inconvénients,
dont les observateurs attentifs devraient être conscients
Suite à l’étude de l’application existante « Ariane voyages », nous avons dégagé les
critiques suivantes :
 Absence d’inscription en ligne des utilisateurs.
 Lenteur de communication entre l’administrateur et les pèlerins.
 Absence du service payement en ligne des frais OMRA ou HAJJ.
 La visite d’un site web pour effectuer la réservation nécessite beaucoup
de temps car elle se fait à travers un navigateur web, alors que les
applications mobiles sont natives et plus rapides.
 Les sites web manquent de visibilité par rapport aux applications qui
disposent de stores directement dans les téléphones.
 Les sites web gèrent encore très mal les coupures réseau alors qu’une
application mobile bien faite permet de conserver durablement les
données sur le téléphone.

4.3. Solution proposée :

• Face aux limites dégages dans la partie « critique de l’existant » nous
proposons l’application web mobile de réservation en ligne qui doit être
caractérisée par :
• L’accès sécurisé aux données.

Page 13
 • une base de données adéquate aux fonctionnalités d’inscription en ligne et de
réservations en ligne de HAJJ et OMRA.
• Une interface homme-machine simple et interactive facilitant les tâches
d’administration.
L’application doit aussi être caractérisée par :
• Sa convivialité
• Sa rapidité à l’affichage
• Sa simplicité
• Sa fiabilité et sa bonne ergonomie

5. Conclusion :
Ce chapitre nous a permis de couvrir l’étude préalable de notre projet en ce qui
concerne la présentation de l’application avec ses objectifs. Aussi, nous avons présenté
une description du site actuel de l’agence Ariane et nous avons dégage ses limites.
Dans le chapitre suivant, nous établirons une étude de conception pour modéliser les
différentes parties de notre projet. En effet modéliser un système avant sa réalisation
permet de mieux comprendre son fonctionnement .

Page 14
CHAPITRE2 : Analyse des besoins
 1. Introduction :
En informatique une bonne spécification des besoins est primordiale. En effet, elle
représente le travail, le plus délicat et le plus significatif. Une bonne spécification des
besoins n’est autre que la question que doit poser tout ingénieur au début de son travail
« Qu’est ce qu’on veut que nous fassions ?». Dans ce chapitre nous allons présenter
notre réponse à cette question. Cette phase consiste à mieux comprendre le contexte du
système. En déterminant ses fonctionnalités en identifiant les cas d’utilisation initiaux.

2. Choix de la méthodologie de conception et justification :

Actuellement, les méthodologies de conception des applications sont multiples. Pour la
modélisation conceptuelle de notre application mobile pour l’agence de voyage Ariane,
nous avons choisi l’approche orientée objet est plus précisément le langage de
modélisation UML puis qu’il est devenu le standard en terme de modélisation objet,
universellement reconnu celui –ci est polyvalent et performant.
• UML est un langage semi formel, itératif et incrémental : ce qui permet de
mieux maitriser le risque.
• Bonne intégration avec UML
• Langage de modélisation des systèmes standard
• Langage de modélisation orienté objet
• Ce langage offre un ensemble de diagrammes qui facilitent la présentation
graphique du système

3. Identification des besoins :

L’identification des besoins constitue une étape importante dans la convergence des
notations utilisées dans le domaine de l’analyse de besoins puisqu’elle représente une
synthèse pour notre système.
Les besoins de l’application se divisent en des besoins fonctionnels et non fonctionnels

3.1. Les besoins fonctionnels :

Le but principal d’un système informatique est de satisfaire les besoins et les exigences
de ses différents utilisateurs. Il s’agit alors des fonctionnalités du système. Ce sont les
Besoins spécifiant le comportement d’entrée/sortie du système. Le système présent
plusieurs fonctionnalités qui nous pouvons regrouper dans les modules :
o l’identification de l’utilisateur.
 o la réservation du voyage Hajj ou Omra.
o le paiement en ligne des frais Hajj et Omra.
o le suivi de l’historique des réservations.
o la notification du pèlerin, d’annulation ou de modification.

3.2. Les besoins non fonctionnels :

Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumis le
système pour sa réalisation et son bon fonctionnement.
L’application web/mobile de réservation en ligne doit répondre aux critères suivants :
o confidentialité : l’application doit garantir la confidentialité des données
personnelles des pèlerins.
o la rapidité : l’application doit optimiser les traitements pour avoir un court
temps de réponse pour l’édition du récapitulatif de réservation et le calcul
des frais à payer.
o La Maintenabilité et la scalabilité : le code de l’application doit être lisible et
compréhensible afin d’assurer son état évolutif et extensible par rapport aux
besoins des administrateurs de l’application..

4. Identification des acteurs :

Un acteur est celui qui utilise le système et communique avec lui
Acteur 1 : L’administrateur
L’application de réservation en ligne Hajj /Omra de l’agence Ariane voyage présente
plusieurs administrateurs. Un administrateur a comme rôle de planifier les voyages
Omra et Hajj en gérant les hôtels et les chefs de groupe. Aussi, l’administrateur peut
suivre les réservations effectuées et notifier les pèlerins en cas de besoin.
Acteur 2 : le pèlerin
Le pèlerin peut consulter les voyages planifiés Omra et Hajj et effectué une
réservation en ligne Aussi, consulter les hôtels et effectuer Omra sur mesure
Aussi, effectué une réservation en ligne.

5. Diagrammes de cas d’utilisation :

Le diagramme de cas d’utilisation identifie les fonctionnalités fournies par le système
(cas d’utilisation), les acteurs et les interactions entre eux.
Un cas d’utilisation est une séquence d’actions réalisées par le système. Il fournit un
résultat observable ayant une valeur ajoutée pour un acteur particulier

Page 17
 5.1. Digramme de cas d’utilisation relatif au pèlerin :
La figure 6 présente le digramme de cas d’utilisation relatif au pèlerin.
uc Use Case Model

Cerer un compte

effectuer un
Effectuer payement en ligne
reserv ation «extend»

«include»

s'authentifier

reserv er HAJJ
reserv er OMRA
Pélerin

Consulter v oyage
planifié OMRA

Consulter v oyage
planifié HAJJ

effectuer demande Consulter les hotels

OMRA sur mesure

Figure 6 : diagramme de cas d’utilisation relatif au pèlerin

5.1.1. Description textuelle du cas d’utilisation « créer compte » :

Titre :
Créer un compte.
Résume :
Ce cas d’utilisation permet au pèlerin de s’inscrire.
Acteur :
Pèlerin
Pré_condition :

Post_condition :
Un compte est créé pour pèlerin.
Scénario nominal :
1- Le pèlerin se connecte à l’application.

Page 18
 2- Le système affiche l’interface d’accueil.
3- Le pèlerin clique sur « créer un compte ».
4- Le système affiche l’interface de l’inscription.
5- Le pèlerin remplit le formulaire.
6- Le système vérifie la saisie.
7- le compte du pèlerin est ajouté à la base de données.
8- Un message de confirmations affiche pour le pèlerin.
Scénario alternatif :
Le scénario alternatif démarre au point 6.
Si les champs ne sont pas tous remplis par l’utilisateur, le système affiche une alerte pour
vérifier le remplissage.

5.1.2. Description textuelle du cas d’utilisation « Effectuer réservation

OMRA » :
Titre :
Effectuer réservation OMRA
Résume :
Le pèlerin réserve sur un voyage OMRA déjà planifié sur le site
Acteur :
Pèlerin
Pré_condition :
Le pèlerin doit s’authentifier.
Post_condition :
Une réservation voyage a s’effectuée.
Scénario nominal :
1. Le pèlerin se connecte à l’application.
2. Le système affiche l’interface d’accueil
3. Le pèlerin clique sur « se connecter».
4. Le système affiche l’interface de la connexion.
5. Le pèlerin saisit son identifiant et son mot de passe.
6. Le système vérifie la saisie est affiche menu.
7. Le membre clique sur « OMRA ».
8. Le pèlerin choisit sur un voyage Omra planifié et clique dessus.
9. Le système affiche le formulaire de réservation Omra.
10. Le pèlerin remplit le formulaire de réservation.

Page 19
 11. Le pèlerin confirme les données.
12. Le système enregistre la première étape de réservation et affiche une autre interface
qui concerne le pèlerin.
13. Le pèlerin saisi ses données personnel.
14. Le système vérifie la saisie et enregistre les données.
15. Le pèlerin doit saisir le numéro du passeport du pèlerin avant la confirmation de la
dernière étape de réservation.
16. Le système vérifie la saisie et enregistre la troisième étape de la réservation puis
affiche le formulaire de payement.
Scénario alternatif :
Le scénario alternatif démarre :
- Au point 6 :
Si les données saisies par l’utilisateur sont manquantes, le système affiche une alerte pour
vérifier ses données.
- Aux points 15 et 18 :
si les champs ne sont pas touts remplis par le membre, le système affiche une alerte pour
vérifier le remplissage. si non les données se sont enregistrées à la table de pèlerin

5.1.3. Description textuelle du cas d’utilisation « Consulter Hôtel » :

Titre :
Consulter hôtels
objectif :
L’utilisateur consulte les hôtels de Makka et Medina conventionnés avec l’agence Ariane
Acteur principale :
Pèlerin
Pré_condition :
Post_condition :
Pèlerin a consulté les hôtels.
Scénario nominal :
1- Pèlerin se connecte à l’application.
2- Le système affiche l’interface d’accueil.
3- Pèlerin clique sur « hôtels ».
4- Le système Affiche la liste des hôtels conventionnés avec l’agence.
5- Le Pèlerin peut cliquer sur n’importe quel hôtel de la liste affichée.
6- A partir de l’interface, le pèlerin peut consulter les détails de l’hôtel (photo,
caractéristique,..)

Page 20
 Scénario alternatif :
Le scénario alternatif démarre au point 4 et au point 7 : le système connecte au web service
pour récupérer les données.

4.1. Digramme de cas d’utilisation relatif à l’administrateur :

uc Use Case Model

consulter
modifier reserv ation
reserv ation OMRA «extend»

«extend»
«extend»
annuler reserv ation

«extend» env oyer email

consulter
reserv ation HAJJ
«extend»
modifier reserv ation

«extend» env oyer message

Gerer les «extend»
reserv ations «extend»

env oyer message

env oyer email

annuler reserv ation
Gerer OMRA

«include»

modifier OMRA «include»

administrateur
aj outer OMRA
supprimer OMRA

s'authentifier

«include»
Gerer HAJJ

supprimer HAJJ

modifier HAJJ «include»

aj outer HAJJ

«include»
Gerer hotel

supprimer hotel

aj outer hotel

aj outer chef de
group

Gereer chef de
group

supprimer chef de
group

Consulter demande
OMRA sur mesure

«extend»
«extend» Adapter OMRA sur
«extend» mesure
Refuser OMRA sur
mesure
env oyer email
OMRA sur mesure

Figure 7 : Diagramme de cas d’utilisation relatif à l’administrateur

Page 21
Dans le paragraphe suivant, nous décrivons les différentes activités de l’administrateur.
L’administrateur, après avoir effectuée l’opération d’authentification avec succès a la
possibilité d’accéder aux différents services offerts par l’application.
Tous les cas d’utilisation sont précédés par une étape d’authentification.

4.2.1. Description textuelle du cas d’utilisation « Authentification » :

Titre :
Authentification
Résume :
L’administrateur utilise son login et son mot de passe pour s’identifier auprès du système.
Acteur :
Administrateur
Pré_condition :
L’administrateur possède un login et mot de passe.
Le système est en marche
Post_condition :
L’administrateur accède au système.
Scénario nominal :
1- L’administrateur accède à l’application.
2- Afficher interface d’authentification.
3- L’administrateur saisit son login et son mot de passe.
4- L’administrateur valide les informations saisies.
5- Le système vérifie les coordonnées.
6- Le système affiche l’interface principale.
Scénario alternatif :
En cas d’erreur d’authentification une exception est lancée.
Le scénario alternatif démarre au point 5.
Le système affiche « login et / ou mot de passe ».
Le scenario nominal reprend au point 2.

4.2.2. Description textuelle du cas d’utilisation « Ajouter hôtel » :

Titre :
Ajouter les hôtels
Objectif :
Mètre à jour les hôtels relatifs aux personnels, hôtel, personne et moyen de transport bus.
Acteur principale :
Administrateur

Page 22
Pré_condition :
L’administrateur s’authentifie.
Ressource sont mises à jour.
Post_condition :
L’administrateur s’authentifie et ajouter hôtels.
Scénario nominal :
1- L’administrateur se connecte à l’application.
2- L’administrateur s’authentifie.
3- Le système vérifie le login et mot de passe.
4- Le système affiche l’interface d’accueil.
5- L’administrateur clic sur ajouter hôtel.
6- Le système affiche le formulaire.
7- L’administrateur remplir le formulaire.
8- Le système vérifie les informations remplis.
9- Le système ajouter un nouveau hôtel.

4.2.3. Description textuelle du cas d’utilisation « Modifier réservation

OMRA» :
Titre :
Modifier réservation OMRA
Acteur principale :
Administrateur
Pré_condition :
L’administrateur s’authentifie.
Post_condition :
Une réservation a été modifiée
Scénario nominal :
1- L’administrateur se connecte à l’application.
2- L’administrateur s’authentifie.
3- Le système vérifie le login et mot de passe.
4- Le système affiche l’interface de manipulation des ressources.
5- L’administrateur modifie la réservation OMRA
6- Le système envoie une notification au pèlerin pour renfermer la modification d’une
réservation
Scénario alternative :

Page 23
 6. Conclusion :
Dans ce chapitre nous avons spécifié les besoins puis de définir les cas d’utilisation
concernant l’utilisation de notre système.
Le chapitre suivant met en évidence de concevoir l’étude conceptuelle et l’analyse de
notre système.

Page 24
Chapitre3 : Modélisation conceptuelle
 1. Introduction :
Dans ce chapitre, nous détaillons la conception de notre application. Nous présentons en
premier lieu la vue dynamique a travers les diagrammes de séquences correspondants
aux cas d’utilisation définis dans le chapitre précédent.
Ensuite, nous décrivons la vue statique à travers le diagramme de classe et les
associations.

2. Analyse des cas d’utilisations : diagramme de séquence :

2.1. Diagramme de séquence :

Le diagramme de séquence représente les objets et leurs interactions selon une ligne
temporelle. Il représente les échanges de messages entre les objets, dans le cadre d’un
fonctionnement particulier du système. Ce diagramme sert à développer une analyse des
scénarios d’utilisation du système. Ce diagramme montre typiquement un utilisateur ou
un acteur et les objets ou les composants avec les quels il interagi au cours de
l’exécution du cas d’utilisation.
Dans ce qui suit, nous élaborons les principaux diagrammes de séquence pour decrire le
dynamisme de notre application.

2.1.1. Digramme de séquence : « inscription »

Le diagramme de séquence « Inscription » présente le séquencement des interactions
entre l’acteur utilisateur, l’interface d’inscription et l’objet « utilisateur » (voir Figure
8).

Page 26
sd Package1

Pélerin
:interface menu :interface inscription :pelerin
inscription controller

1:cliquer sur inscription

()

2:saisir(nom, email,mot-passe,confirmation-mot-passe)

3:inscription(nom, email,mot-passe,confirmation-mot-passe)

4:verif()

alt
5:afficher("champ manquant ou non valide")
[non valide]

[else] 6: ajouter pèlerin(nom, email,mot-passe,confirmation-mot-passe)

7:afficher("bienvenue nom pèlerin)

Figure 8 : Diagramme de séquence "inscription"

2.1.2. Digramme de séquence : « authentification»

Le diagramme de séquence du cas d’utilisation « Authentification » indique
l’interaction entre l’utilisateur et le système avant la demande de réservation(voir Figure
9).
sd Use Case Model

Pèlerin
: interface menu :interface :Authentification : Pèlerin
Authentification controller
1: cliquer sur connecter()

2:saisir(Email,mot-passe)

3:connexion(Email,mot-passe)

4: select()

alt 4: afficher("authentification non valide")

[pèlerin inexistant]

[else] 6:afficher ("bienvenue nom pèlerin")

Figure 9 : Digramme de séquence "authentification"

Page 27
 2.1.3. Digramme de séquence : « Réservation OMRA»
Le diagramme de séquence du cas d’utilisation « réservation Omra » indique
l’interaction entre l’utilisateur et le système pour effectuer une réservation d’un voyage
OMRA programmé (voir Figure 10).
sd Use Case Model

Utilisateur
: interface Menu :interface OMRA OMRA controller :v oyage : Reserv ation :Pèlerin

1: choisir voyage OMRA

()

2: recherche()

3:select()

4: afficher donnees OMRA()

5:saisir information reservation()

6:cliquer bouton "reserve"()

7:reserver()

8:verification disponibilité()
alt
[complet]
9:affiche message ("OMRA complet")

[else] 10:insert(reservation)

11:update(nbre_place_disponible)

12:insert (pèlerin)

13:afficher message("reservation reussi")

Figure 10 : Diagramme de séquence de réservation OMRA

2.1.4. Digramme de séquence : « Ajouter hôtel»

Le diagramme de séquence du cas d’utilisation « ajouter hôtel » indique l’interaction
entre l’administrateur et le système. Il est présenté dans la figure 11.

Page 28
 sd Use Case Model

Administrateur
: interface menu :interface Aj out- :aj out-hotel :hotel
Hotel

cliquer sur "hotel"()

2:remplir formulaire Ajout_hotel ( nom , categorie , image )

3:ajouter_hotel ( nom , categorie , image )

4:verif-saisie()

alt

[non valide] 5:affiche("champ monquant ou non valid")

[else]
alt 6:insert()
[hotel existe]
7:afficher message("hotel existe deja")

[else]
8: afficher message("hotel ajouté avec succées")

Figure 11 : Diagramme de séquence Ajouter Hôtel

3. Modélisation conceptuelle des données :

3.1. Dictionnaire des données :

Le dictionnaire des données est l’ensemble des données gérées par le système de gestion
des bases des données. Il permet de s’avoir quelles sont les données de la bases et de
connaitre leurs structures. Le dictionnaire de données de notre application est présenté
dans le tableau 2 :
Tableau 2 : Dictionnaire de données

Numéro Code Description

1 Id_pèlerin L’identifiant d’un pèlerin
2 NomP Nom d’un pèlerin
3 PrenomP Prénom d’un pèlerin
4 AdresseP Adresse d’un pèlerin
5 TelephoneP Numéro téléphone d’un pèlerin
6 Num-passeport Numéro passeport d’un pèlerin
7 Code-postale Code postale d’un pèlerin
8 Ville Ville d’un pèlerin

Page 29
9 Email Email d’un pèlerin
10 PhotoPasseport Photo de passeport d’un pèlerin
11 Id_user L’identifiant d’un utilisateur
12 NomU Nom d’un utilisateur
13 Email Email d’un utilisateur
14 Mot_passe Mot passe d’un utilisateur
15 TypeU Type d’utilisateur
16 Id_voyage L’identifiant du voyage
17 Prix Le prix d’un voyage
18 DateDebut Date début du voyage
19 DateFin Date fin du voyage
20 Détail Détail du voyage
21 nbrePlace Nombre de la place dans un voyage
22 nbrePlaceDisp Nombre de la place disponible dans un
voyage
23 Id_administrateur L’identifiant d’un administrateur
24 EmailA Email d’un administrateur
25 Mot_passeA Mot passe d’un administrateur
26 Id_OMRAM L’identifiant d’OMRA sur mesure
27 DatedebutSouhaité La date de début d’OMRA sur mesure
29 DatefinSouhaité La date de fin d’OMRA sur mesure
30 Nbre-personne Le nombre de personne qui réserver
31 CategorieHôtel Catégorie d’hôtel d’une OMRA sur
mesure
32 Budget_par_personne Le budget par personne d’une OMRA sur
mesure
33 dateDemande Date de la demande OMRA sur mesure
34 Id_hôtel L’identifiant de l’hôtel
35 Nomh Nom de l’hôtel
36 categorieHôtel Categorie de l’hôtel
37 Id_vol L’identifiant d’un vol
38 Date_dep Date de départ d’un vol
39 Date_arrivé Date d’arrive d’un vol
40 Typev Type d’un vol
41 Id_agence L’identifiant de l’agence
42 adresseAgence L’adresse de l’agence

Page 30
43 nomAgence Le nom de l’agence
44 telAgence Le numéro du téléphone de l’agence
45 Id_Chef L’identifiant de la chef de groupe
46 nomChef Nom du chef de groupe
47 PrenomChef Prénom du chef de groupe
48 nbreChambreDouble Nombre de la chambre double
49 Nbrenuit Nombre de la nuit
50 dateDebutHôtel La date début du réservation dans l’hôtel
51 dateFinHôtel La date fin du réservation dans l’hôtel
50 Id_resérvation L’identifiant de la réservation
51 Nbre_adulte Le nombre d’adulte
52 Nbre_bébé Le nombre du bébé
53 Type_chambre Le type de la chambre
54 DateResérvation La date de la réservation
55 etatResérvation L’état de la réservation
56 Id_bus L’identifiant du bus
57 Responsable Responsable du bus
58 Nbre_place Nombre de la place dans le bus
59 Id_Aéroport L’identifiant de l’aéroport
60 ville La ville de l’aéroport
61 Id_paiement L’identifiant du paiement
62 type Le type du paiement
63 id_facture L’identifiant de la facture
64 montantFact Le montant de la facture
65 dateFact La date de la facture
66 datePaiement La date du paiement de la facture

3.2. Représentation des classes :

Une classe est composée de :
• Attributs : représentant des données dans les valeurs représentent l’état objet.
• Méthodes : il s’agit des opérations applicables aux objets.
Apres avoir dégagé le dictionnaire de données, nous pouvons représenter les classes qui
seront d’intérêt pour notre application. La liste des classes ainsi que leurs méthodes
seront présentes dans le tableau 3.

Page 31
 Tableau 3 : Les classes et leurs attributs

N CLASSE ATTRIBUTS IDENTIFIANT METHODE

°
1 Pèlerin Id_pèlerin Id_pèlerin Authentifier ()
Nomp Gérer ()
Prenomp
Adressep
Telephonep
Num_passeport
Code_postale
Ville
Photo_passeport
Email
2 Administrateur Id_administrateur Id_administrateur Authentifier ()
EmailA Gérer ()
Mot_passeA
3 Voyage Id_voyage Id_voyage Consulter ()
Prix Gérer ()
Datedebut Réserver ()
Datefin
Détail
nbrePlace
nbrePlaceDisp
Date_HAJJ
4 OMRA sur Id_OMRAM Id_OMRAM
mesure Datedebut_souhai
té
Datefin_souhaité
Nbre_personne
Categoriehôtel
Budget_par_perso
nne
DateDemande

Page 32
4 Hôtel Id_hôtel Id_hôtel
Nomh
Categorieh
5 Vol Id_vol Id_vol
Date_dep
Date_arrivé
Typev
6 Réservation Id_resérvation Id_resérvation Etat ()
Nbre_adulte Prix ()
Nbre_bébé
Type_chambre
dateResérvation
etatResérvation
7 User Id_user Id_user Authentifier ()
Login Gérer ()
Mot_passe
nomU
8 Agence Id_agence Id_agence
adresseAgence
nomAagence
telAgence
9 Bus Id_bus Id_bus
Responsable
Nbre_place
10 Chef_groupe Id_Chef Id_Chef
nomChef
PrenomChef
11 Detail_hôtel nbreChambreDou Id_voyage
ble
Nbrenuit
dateDebutHôtel
dateFinHôtel
12 Aéroport Id_Aéroport Id_Aéroport
ville
13 Facture id_facture id_facture

Page 33
 montantFact
dateFact
datePaiement
14 Mode-de- Id_paiement Id_paiement
paiement type

3.3. Représentation des associations :

Le tableau 4 présente la description des associations entre les classes définies dans la
section 3.2.
Tableau 4: les associations

N Nom relation Objets Cardinalités Attributs

° participants
1 Réserver User [1-N] Type_champre
Voyage [1-N] Nbreadulte
2 Programmer Administrateur [1-N] Id_voyage
Voyage [1-1] Id_administrateur
3 Déposer –Doc Pèlerin [1-1] Id_agence
Agence [1-N] Id_pèlerin
4 Aller Vol [0-N] Id_voyage
Voyage [1-1] Id_vol
5 Retour Vol [0-N] Id_voyage
Voyage [1-1] Id_vol
6 Demande User [1-N] Id_ OMRAM
OMRAsurMesu [1-1] Id_user
re
7 Mahram Pèlerin [0-N] Id_pèlerin
Pèlerin [0-1] Id_pèlerin
8 Detail_hôtel Voyage [1-N] Nbrechambredou
ble
Hôtel [1-N] Id_voyage
9 Res_pèl Pèlerin [1-N] Id_pèlerin
Réservation [1-N] Id_voyage

Page 34
 3.4. Diagramme de classes :
Le diagramme de classe est une description statique du système focalisée sur le concept
de classe et d’association.
Une classe représente un ensemble d’objets qui possèdent des propriétés similaires et
des comportements communs décrits en termes d’attributs et d’opérations.
Une association consiste à présenter les liens entre les instances de classe.
La figure 12 présente le diagramme de classes des entités de notre application.

Page 35
class Class Model

Hotel
Mode_de_payement
+ id_hotel: int
Chef-Groupe + nomh: char Facture Mahram
+ id_payement: int
+ categorieHotel: char + type: char
+ id_chef: int 1 + id_facture: int 0..1
0..* + 0..*
+ nomChef: char montantFact: double
+ prenomChef: char + dateFact: char Pélerin
+ datePaiement: char
1 + id_pélerin: int
1..* 0..1 + adressep: char
+ nomp: char
Bus + code-postale: int
Reserv ation
+ prenomp: char
1
+ id_bus: int detail-hotel + id_reservation: int + villep: char
+ responsable: char res-pel
+ type_chambre: char 1..* + photoPasseport
+ nbre_place: int + nbrechambredouble: int + nbre_adulte: int + telephonep: char
+ nbrenuit: int + nbre_bébé: int 1..* + num_pasport: char
1..*
+ dateDebutHotel: char + dateReservartion: char
+ dateFinHotel: char + etatReservation: char
1..* 1..*
+ Etat()
v oyage + prix()
1..*
+ id-voyage: int
Déposer-Doc
Vol + datedebut: char
1..* + prix: int User
+ id-vol: int retour + datefin: char
+ id_user: int 1
+ date-arriver: char 0..* + detail: char
Reserver + Email: char
+ date-dep: char 1 allée + nbrePlace: int 1..*
0..* + nbrePlaceDisp: int + mot_passe: char Agence
+ typev: char
1 1..* + nomU: char
1..* + id_agence: int
+ reserver() + typeU: char
+ consulter() + adresseAgence: char
+ gerer() + Authentifier() + nomAgence: char
+ gerer() + telAgence: int
1..* 1..* programmer
1
depart arrivee demande
OMRA-sur-mesure

OMRA HAJJ Administrateur + id_OMRAm: int

1 1
1..* + budget_par_personne: double
+ authentifier() + categorie_hotel: char
Aéroport 1 + gerer() + dateDebutSouhaité: char
+ datefinSouhaité: char
+ id_Aéroport: int + nbre_personne: int
+ ville: char + dateDemande: char

Figure 12 : Diagramme de classe

  Modèle relationnel :
Bus (id_bus, responsable, nbre_place)
Chef_groupe (id_chef, nomChef, prénomChef )
Hôtel (id_hôtel, nomHôtel, categorieH)
Detail_hôtel (#id_Hôtel, #id_oyage, nbreDouble, nbreNuit, dateDebutHôtel,
dateFinHôtel)
Vol (id_vol, dateArriveé, dateDep, typeV, # id_aéroDep, #id_aéroArriv)
Voyage (id_voyage, dateDébut, prix, dateFin, détail, nbrePlace, nbrePlaceDisp,
#id_chef, #id_volAllée, #id_volRetour, #id_admin)
Réservation (id_resérvation, typ_chambre, nbr_adulte, nbr_bébé, dateRéservation,
etatResérvation, #id_voyage, #id_user)
Pèlerin (id_pelèrin, nomP, prénomP, adresseP, code_postal, villeP, téléphoneP,
num_passeport, PhotoPasseport, #id_mahram, # id_agence)
Agence (id_agence, adresseAgence, nomAgence, telAgence)
User (id_user, Email, mot_passe, nomU, typeU)
Omra_sur_mesure (id_omram, budgetParPersonne, catégorieHôtel, dateDébutSouhaité,
dateFinSouhaité, demande, date_demande, #id_user)
Mode payement (id_mode, type)
Aéroport (id_aéroport, ville)
Facture (id_facture,montantFact, dateFact, datePaiement, #id_réservation,
#id_mode_paiement)
Bus_voy (#id_voyage, #id_vol)
hôtel_voy (#id_voyage, #id_hôtel)
Res_pel(#id_réservation, #id_pèlerin)

4. Conclusion :
Tout au long de ce chapitre, nous avons mené une conception détaillée de notre projet
affin de garantir la fiabilité et l’efficacité de la phase de réalisation de l’application. En
particulier, nous avons précisé la façon dont les objets doivent interagir ensemble par
l’utilisation des diagrammes de séquences. Par ailleurs, nous avons décrit l’aspect
statique avec un diagramme de classe global. Nous présentons dans le chapitre suivant
la réalisation de notre application.
Chapitre4 : Réalisation
1. Introduction :
Dans ce chapitre, nous mettons l’accent sur l’étape de la réalisation du projet, qui
consiste à mettre en œuvre les outils matériels, logiciels et de développement pour
aboutir à la création d’un logiciel qui répond aux spécifications fonctionnelles fixées
dans la partie conception du projet.

2. Environnement du travail :

2.1. Environnement matériel :

Pour la réalisation du projet, nous avons utilisé un ordinateur
ordinateur portable dont les
caractéristiques sont les suivantes :
- Processeur
sseur Intel Core2.40 GHz.
- 4 G de mémoire vive.
- 700 G d’espace disque.
- Système d’exploitation Microsoft Windows 7 professionnel.

2.2. Environnement logiciel :

Dans cette partie, nous présentons les
les différentes technologies utilisées pour la
réalisation de notre application.
 ATOM 1.36.1 :
Atom est un éditeur de texte libre pour MacOs, GNU/Linux et Windows
développé par Git hub. Il supporte des plug-ins
plug ins écrits en Node.js et
implémente Git control. La plupart des
es extensions sont sous libre et sont
maintenues par la communauté. Atom est basé sur chromium et Electron
est écrit en coffeeScript. Il est aussi utilisé en tant qu’environnement de développement
(EDI) [URL1].
 Système de gestion de base de données MySQL
MySQL est un serveur de bases de données relationnelles Open Source.
Un serveur de bases de données stocke les données dans des tables
séparées plutôt que de tout rassembler dans une seule table. Cela
améliore la rapidité et la souplesse de l'ensemble. Les tables sont
reliées par des relations définies, qui rendent possible la combinaison de données entre
plusieurs tables durant une requête. Le SQL dans "MySQL" signifie "Structured Query
Language" : le langage standard pour les traitements
itements de bases de données [URL2].

Page 39
  phpMyAdmin
Il s'agit de l'une des plus célèbres interfaces pour gérer une
base de données MySQL sur un serveur PHP. De
nombreux hébergeurs, gratuits comme payants, le
proposent ce qui évite à l'utilisateur d'avoir à l'installer.
l
Cette interface pratique permet d'exécuter, très facilement et sans grandes connaissances
en bases de données, des requêtes comme les créations de table de données, insertions,
mises à jour, suppressions et modifications de structure de la base de données, ainsi que
l'attribution et la révocation de droits et l'import/export. Ce système permet de
sauvegarder commodément une base de
de données sous forme de fichier.
fichier Sql et d'y
transférer ses données,
onnées, même sans connaître SQL [URL3].
 Xampp
Xampp est un ensemble de logiciels permettant de mettre en
place facilement un serveur Web confidentiel. Un serveur de
messagerie électronique. Il s’agit d’une distribution de
logiciels libres (X (cross) Apache
A MySQLperlPHP)) offrant une bonne souplesse.
souplesse
[URL4]
 Laravel
Laravel est un Framework web gratuit à code source ouvert,
créé par Taylor Otwell et destiné au développement
d'applications Web suivant le modèle architectural modèle-
vue-contrôleur (MVC) et basé sur Symfony . Parmi les fonctionnalités
nnalités de Laravel,
citons un système de packaging modulaire avec un gestionnaire de dépendances dédié,
différentes manières d'accéder aux bases de données relationnelles [URL5].
 Android Studio :
C’est un environnement pour développement et programmation entièrement intégré qui
a été récemment lancer par Google pour les systèmes
Android.il a été conçu pour fournir un environnement de
développement et une alternative à Eclipse
Eclips qui est l’IDE le
plus utilisé. Android Studio permet de voir chacun des changements visuels que vous
effectuez sur votre application en temps réel,
réel vous pourrez
rez voir aussi son effet sur
différents appareils Android, chacune avec différentes configurations et configurations
simultanément [URL6].

Page 40
2.3. Choix des langages de programmation :
Le choix du langage de programmation et des outils est important puisqu’il permet
d’accélérer ou retarder l’élaboration du progiciel.
 PHP :
C’est un langage open source qui est d’origine un langage de script
conçu spécifiquement pour agir sur les serveurs web. Avec la sortie de la
version 5, PHP est devenu plus robuste mais également plus simple avec l’apparition
d’un socle commun pour la gestion des appels aux bases de données PHP Data
Object(PDO) [URL7].
 Json :
(JavaScript Object Notation – Notation Objet issue de JavaScript) est un
forma t générique de données textuelles. Il permet de représenter
l’information structurée comme XML [URL8].
 HTML5 :
Le HTML5 est un langage de base pour la création de site internet, il sert à
structurer vote document. D’autre langage peut s’ajouter lors de la
conception, mais tous les sites web contiennent du HTML. HTML5
désignant la version du langage HTML [URL9].
 JavaScript :
C’est un langage de programmation orienté objet, développé par Sun
Microsystems. Java donne la possibilité de développer des programmes
pour les mobiles [URL10].
 Xml :
Xml permet de multiplier les espaces de nommage des balises et
emprunter les définitions d’autres utilisateurs [URL11].

3. Architecture de l’application :

3.1. Conception architectural :

L’architecture d’un système informatique est la façon dont les fonctions ou traitements
du système sont distribués entre ses divers composants matériels et logiciels. Pour notre
cas, nous avons choisi d'utiliser l'architecture MVC (Model-View-Controller). Il s'agit
d'un modèle architectural très puissant 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. Il tire sa puissance de son concept de base qui est la

Page 41
séparation des données (modèle), de l'affichage (vue) et des actions (contrôleur)
[Openclassrooms, 2016].
Le Modèle: Correspond aux données stockées généralement dans une base de
données. Dans un langage orientée objet ces données sont exploitées sous forme de
classes. Le modèle peut aussi agir sur la vue en mettant à jour ses données.
La Vue: Ne contenant que les informations liées à l'affichage, elle se contente
d'afficher le contenu qu'elle reçoit sans avoir connaissance des données. En bref, c'est
l'interface homme machine de l'application.
Le Contrôleur: Sert à faire l'interface entre le modèle et la vue. En effet, puisque le
modèle et la vue sont censés être au maximum indépendants, le contrôleur sert à faire le
lien pour faire communiquer l'un (M) avec l'autre (V). En particulier, il permet de
récupérer les informations, de les traiter en fonction des paramètres demandés par la vue
(c'est par l'utilisateur), puis de renvoyer à la vue les données afin d'être affichées.
L'interaction entre ces trois couches est décrite à l'aide de la figure suivante :

Figure 13 : Modèle MVC

Page 42
3.2. Architecturale du système :
Le MVC (Model View Controller) est une méthode d’organisation du développement
d’applications Web permettant de séparer les différents concepts résultant de nos pages
PHP.
En effet, trois grandes « actions » peuvent être identifiées lorsque nous développons en
PHP :
• Les requêtes en base de données (Model)
• Le traitement des données (Controller)
• L’affichage de pages HTML (View)
Dans les faits, le navigateur de l’utilisateur chargera le contrôleur, qui interrogera la
base de données par l’intermédiaire du modèle, celui-ci répondra au contrôleur qui
traitera les données et les passera à la vue (View), celle-ci étant en charge de générer le
code HTML qui est renvoyé au navigateur.
 Les Modèles (Models)
Ce que nous appelons un Modèle est en réalité un fichier PHP qui ne fait que gérer
les échanges avec la base de données. Lorsque nous avons besoin de lire ou écrire
dans la base de données, nous faisons appel au Modèle.
 Les Vues (Views)
Les vues sont principalement des fichiers HTML contenant le code destiné à être
transmis au navigateur de l’utilisateur. Nous disposerons des données transmises par le
contrôleur afin de les intégrer dynamiquement dans nos pages.
 Les Contrôleurs (Controllers)
Véritable tour de contrôle de notre application, le contrôleur a pour fonction de faire
l’interface entre les modèles et les vues. Il est chargé de demander les données par
l’intermédiaire des modèles, de traiter ces données et de les transmettre aux vues, prêtes
à être utilisées.
 Le routing
Bien qu’indépendant de l’architecture MVC, le routing fait partie intégrante de tous
les frameworks PHP.
Dans une architecture classique, nous pointons vers des fichiers :
http://monsite.fr/index.php
http://monsite.fr/inscription.php
http://monsite.fr/login.php

Page 43
Dans une architecture MVC, nous allons pointer vers des dossiers virtuels appelés
routes
http://monsite.fr/user/inscription
http://monsite.fr/user/login
http://monsite.fr/blog/article
Cette architecture offre de nombreux avantages :
Protection des fichiers, ceux-ci n’étant plus affichés par le navigateur
Des URLs plus simples à mémoriser pour les utilisateurs
Amélioration du référencement si les routes contiennent des mots-clés contenus dans
la page correspondante

Figure 14: laravel MVC

3.3. Enchainement des programmes :

La structure hiérarchisée est une façon d’organiser des blocs d’information complexes.
Ce schéma d’organisation s’adapter particulièrement bien au site web car les différents
thèmes dépendent ainsi d’une seule page d’index ou page d’accueil.
Nous présentons ci-dessous l’architecture navigationnel de notre application :

Page 44
 class Domain Model

Partiralamecque

Accueil

Haj j Omra Hôtel Agence Se connecter Creer un compte

programme haj j Emplacement de

programme omra liste hôtels
l'agence

Haj j Omra Sur Hôtel Agence

Omra
Mesure

programme Omra programme Omra Demande liste des hôtels Emplacement de

l'agence

réserv ation haj j réserv ation omra

payement en
ligne

Figure 15: Modèle navigationnel

4. Description des interfaces de l’application en version web et

mobile :

4.1. Les interfaces web :

Cette étapes consiste à réaliser et à mettre aux points les programmes en fonction des
spécifications décrites, ainsi que de présenter les principales interfaces de l’application.
 Interface d’accueil :
L’interface d’accueil apparait à l’utilisateur dès l’ouverture du site. Cette interface
Permet à l’utilisateur de consulter les voyages programmés d’omra ou hajj.il peut aussi
consulter les hôtels de la Mecque et la Médine conventionnés avec l’agence (voir Figure
16).

Page 45
 Figure 16 : Interface accueil

 Espace utilisateur :
• Interface créer un compte :
L’utilisateur doit créer un compte pour permet de réserver un voyage OMRA\HAJJ
OMRA en
ligne (voir Figure 17).

Figure 17:Interface créer un compte

• Interface se connecter :
Pour accéder à son compte, L’utilisateur devra d’abord s’identifier en saisissant son login
et son mot de passe. En cas d’erreur quelconque, un message d’erreur sera affiché
indiquant la nature de cette erreur (voir Figure 18).

Page 46
 Figure 18 : Interface se connecter

Une fois les données d’identification sont valides, l’utilisateur accédé a son compte.
Cette interface lui donne la possibilité d’accéder à plusieurs services.
• Interface Hajj
ajj :
Lorsque l’utilisateur cliquee sur l’icône Hajj, le système affiche l’interface qui permet
de consulter la liste de voyage de Hajj disponibles il peut alors effectuer une
réservation d’ voyage choisi (voir Figure 19).

Page 47
 Figure 19 : Interface Hajj

• Interface réservation :
Cette interface permet à l’utilisateur d’effectuer une réservation après la consultation
d’un voyage Omra ou Hajj, et ce en fournissant les informations : nom, prénom, date de
naissance, ville, code postale, adresse, téléphone, email, numéro du passeport chaque
champ de saisie est contrôlé lors de la clique sur « créer » (voir Figure 20).

Page 48
 Figure 20 : Interface réservation

• Interface payement en ligne :

Lorsque l’utilisateur rempli le formulaire et il clique sur « créer », une autre interface
s’affiche pour le payement en ligne (voir Figure 21).

Figure 21 : Interface payement en ligne

• Interface Hôtel :
Par le biais de cette interface, l’utilisateur peut consulter les listes de l’hôtel (voir
(v Figure
22).

Page 49
 Figure 22 : Interface Hôtel

 Espace administrateur
• Interface accueil :
Pour accéder au compte, l’administrateur devra d’abord se connecter, le système affiche
l’interface accueil (voir Figure 23).

Figure 23 : Interface d'accueil de l'administrateur

Page 50
 • Interface programmer Omra :
A partir de cette interface, l’administrateur peut ajouter Omra en fournissant ses détail :
type, vol, description, programme, guide, hôtel, etc. (Voir Figure
Figur 24).

Figure 24 : Interface programmer Omra

• Interface Ajouter Hôtel :

L’administrateur doit remplir les champs nom hôtel, catégorie, image pour ajouter un
hôtel (voir Figure25).

Figure 25 : Interface Ajouter Hôtel

Page 51
4.2. Les interfaces mobiles :
Nous avons commencé a élaboré les premières versions d’interfaces de test sans base de
données qui figure sur l’annexe puis nous avons inclus la base de données dans la version
final.
• Interface d’accueil :
Lors du lancement de l’application, une interface apparait mentionnant le nom de
l’application, une image significative et des boutons.

Figure 26 : Interface accueil de l’application mobile

• Interface Authentification :
Cette interface nous permettant à saisir le login et le mot de passe pour accéder à son
espace et un bouton « se connecter » comme l’indique la figure 27.

Page 52
 Figure 27 : Interface Authentification de l'application mobile

• Interface inscription :
Cette interface montre la page inscription ou vous pouvez inscrire pour connecter à notre
application comme l’indique la figure 28.

Page 53
 Figure 28 : Interface d'inscription

5. Conclusion :
Dans ce chapitre nous avons décrit l’ensemble de l’environnement logiciel utilisé pour la
mise en œuvre de notre application en version web et mobile. Nous avons aussi illustré la
phase de test de l’application à travers un ensemble des captures d’écran qui décrire les
différentes fonctionnalités de notre système.

Page 54
 Conclusion générale

Dans le cadre de notre de fin d’études pour l’obtention du diplôme en Licence

Fondamentale en Informatique et Multimédia, nous avons développé une application web
et mobile de la réservation en ligne Omra/Hajj l’agence française « Ariane voyage ». Cette
application est conçue pour faciliter la tâche de réservation pour les pèlerins en la rendre
possible à partir d’un téléphone portable. L’application donne l’accès à l’utilisateur pour :
• Consulter les voyages programmés d’Omra et Hajj,
• Effectuer une réservation d’Omra ou Hajj pour un ou plusieurs pèlerins,
• Effectuer la demande d’Omra sur mesure.
Quant à l’administrateur, la partie web de l’application lui donne l’accès pour gérer le site,
programmer des voyages d’Omra ou Hajj et notifier l’utilisateur en cas de besoin de
documents à fournir, ou en cas de modifications du voyage réservé.
Ce travail nous a permis de prendre certaines responsabilités et de consolider de plus en
plus nos connaissances théoriques et pratiques acquises en conception et en
programmation. Il nous a permis aussi de s’adapter avec un nouvel environnement de
développement informatique, notamment les outils Laravel et Android Studio.
Nous avons entamé notre étude par le pointage sur les besoins qui est une étape nécessaire
pour mieux assimiler le système déjà existant. Ensuite, nous avons procédé à la conception
dans laquelle nous avons utilisé UML comme langage de modélisation. C’est ainsi que
trois types de diagrammes ont été présentés : le diagramme de cas d’utilisation, le
diagramme de classes et le diagramme de séquences. La dernière étape concerne le
développement de notre application en tenant compte de l’environnement logiciel choisi.
Comme perspectives à ce travail, nous envisageons d’enrichir la partie mobile de
l’application par de nouvelles fonctionnalités afin de faciliter la tâche de réservation et de
notification l’utilisateur.

Page 55
 BIBLIOGRAPHIE

[URL1] https://fr.wikipedia.org/wiki/Atom_(%C3%A9diteur_de_texte)
[URL2] https://www.futura-sciences.com/tech/definitions/internet-mysql-4640/
[URL3] https://fr.wikipedia.org/wiki/PhpMyAdmin
[URL4] https://fr.wikipedia.org/wiki/XAMPP
[URL5] https://fr.wikipedia.org/wiki/Laravel
[URL6] https://android.developpez.com/cours/
[URL7] https://uml.developpez.com/
[URL8] https://java.developpez.com/
[URL9] https://php.developpez.com/
[URL10] https://javascript.developpez.com/
[URL11] https://xhtml.developpez.com/

Page 56