République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de Jendouba

institut supérieur d’informatique du kef

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme de la Licence en Sciences Informatique

Spécialité : Génie logiciel

Par

Angham Jbeli

développement d’une application mobile pour gérer

les réservations des places du parking en ligne

Encadrant entreprise : Mr Ahmed Nafetti

Encadrante académique : Dr.Aymen LOUATI

Réalisé au sein de Bee coders

entre 1 février 2022 et 31 mai 2022

Année Universitaire 2016 - 2017

J’autorise l’étudiant à faire le dépôt du rapport de stage de projet de fin d’études.

Encadrant de l’entreprise, Mr Ahmed Naffeti

Le

J’autorise l’étudiant à faire le dépôt du rapport de stage de projet de fin d’études.

Encadrante académique, Dr.Aymen Louati

Le
Dédicaces

Je dédie ce mémoire à ma mère qui ne cesse de m’assister sur le plan moral, matériel et
surtout affectif. Pour cela, je lui souhaite une longue et heureuse vie pleine de joie et de
succès, avec mon cher père qui, lui aussi, était, toujours, à mes côtés, dans les moments
difficiles...
Votre cher fils Angham qui vous chérit tant.

Jbeli Angham

i
Remerciements

Je souhaite rendre hommage à tous ceux qui ont contribué à la réalisation de ce travail.
Je tiens, avant tout, à adresser mes plus vifs remerciements à Madame Houda ZOUARI
OUNAIES, mon encadrante à l’Ecole Nationale d’ingénieurs de Carthage, pour l’encadrement
sérieux dont elle a fait preuve ainsi qu’à nos enseignants de l’Enicarthage à qui je dois ma
formation.

Je tiens à exprimer ma gratitude à M. Tawfik ZAMMEL, mon tuteur, pour m’avoir intégré
rapidement au sein de l’entreprise et m’ avoir accordé toute sa confiance ; pour le temps qu’il
m’ a consacré tout au long de cette période, sachant répondre à toutes mes interrogations sans
oublier sa participation au cheminement de ce rapport.

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance aux

personnes suivantes, pour l’expérience enrichissante et pleine d’intérêt qu’elles m’ ont fait
vivre durant ces quatre mois au sein de Linedata Tunisie :

Monsieur Mehdi CHAOUACHI,mon ancien encadrant, pour la qualité de son suivi incessant,
pour son accueil et pour sa confiance qu’il m’a accordé.

Enfin, j’ adresse mes remerciements aux membres du jury pour m’ avoir honoré en acceptant
d’évaluer ce travail.

Sans oublier tous ceux qui ont participé de prés ou de loin à l’accomplissement de ce projet.

ii
Table des matières

1 contexte général du projet 2

1.1 Présentaion de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Organigramme de bee coders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de notre client«Thor system » . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Solution proposé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Processus unifié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2 La méthode 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Analyse et spécification des besoins 9

2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Prototype des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Le cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Diagramme de cas d’utilisation raffiné . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 Diagramme de cas d’utilisation «s’authentifier» . . . . . . . . . . . . . . . . . . 13
2.6 Diagramme détaillé de cas d’utilisation de client . . . . . . . . . . . . . . . . . . . . . 15
2.6.1 Diagramme de cas d’utlilisation raffiné « gérer réservation » . . . . . . . . . . . 15
2.6.2 Diagramme de cas d’utlilisation raffiné « gérer données personnels » . . . . . . 18
2.7 Diagramme de cas d’utlilisation raffiné « gérer véhicule» . . . . . . . . . . . . . . . . . 20
2.7.1 Diagramme de cas d’utlilisation raffiné « la carte crédit» . . . . . . . . . . . . . 23
2.7.2 Diagramme de cas d’utlilisation raffiné « Consulter l’historique de réservations» 25
2.8 Diagramme détaillé de cas d’utilisation de l’administrateur . . . . . . . . . . . . . . . 25

iii
 2.8.1 Diagramme de cas d’utlilisation raffiné « Consulter utilisateur » . . . . . . . . . 25
2.9 Diagramme de cas d’utlilisation raffiné «consulter les frais» . . . . . . . . . . . . . . . 27
2.9.1 Diagramme de cas d’utlilisation raffiné «consulter les réservations» . . . . . . . 28

3 Conception 31
3.1 diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Les diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 Définition et composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Diagramme de séquence s’authentifier . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 Diagramme de classe de conception S’authentifier . . . . . . . . . . . . . . . . . 35
3.2.4 Diagrammes de séquence inscription . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.5 Diagramme de classe de conception inscription . . . . . . . . . . . . . . . . . . 37
3.2.6 Diagrammes de séquence «gérer réservation» . . . . . . . . . . . . . . . . . . . 37
3.2.7 diagramme de séquence consulter historique . . . . . . . . . . . . . . . . . . . . 41
3.2.8 Diagramme de séquence «éditer les données personnelles» . . . . . . . . . . . . 41
3.2.9 Diagrammes de séquence «gérer véhicule» . . . . . . . . . . . . . . . . . . . . . 42
3.2.10 Diagramme de séquence «Consulter clients» . . . . . . . . . . . . . . . . . . . . 44
3.2.11 Diagramme de séquence «Consulter les frais» . . . . . . . . . . . . . . . . . . . 44
3.2.12 Diagramme de séquence «Consulter réservations» . . . . . . . . . . . . . . . . . 45

4 Réalisation 46
4.1 Architecture de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.2 Environment logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.3 Langages de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.4 Langage de modélisation et outil de conception . . . . . . . . . . . . . . . . . . 51
4.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.2 Interface d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.3 Les interfaces du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.4 Interface d’inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.5 les interfaces de ladministrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.6 Liste des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

iv
Conclusion générale 62

v
Table des figures

1.1 Logo Bee coders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Logo Bee coders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 cycle du processus unifié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Processus 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Diagramme de cas d’utilisation «s’authentifier» . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Diagramme de cas d’utilisation «gérer réservation» . . . . . . . . . . . . . . . . . . . . 16
2.5 Diagramme de cas d’utilisation «gérer les données personnels» . . . . . . . . . . . . . . 19
2.6 Interface des données personnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Diagramme de cas d’utilisation «gérer réservation» . . . . . . . . . . . . . . . . . . . . 21
2.8 Interface du véhicule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Diagramme de cas d’utilisation «gérer paiement» . . . . . . . . . . . . . . . . . . . . . 23
2.10 Interface de carte de crédit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.11 Diagramme de cas d’utilisation «Consulter historique» . . . . . . . . . . . . . . . . . . 25
2.12 Interface de l’historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.13 Diagramme de cas d’utilisation «gérer paiement» . . . . . . . . . . . . . . . . . . . . . 26
2.14 Interface de liste des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.15 Diagramme de cas d’utilisation «gérer paiement» . . . . . . . . . . . . . . . . . . . . . 27
2.16 Interfaces des frais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.17 Diagramme de cas d’utilisation «consulter les frais» . . . . . . . . . . . . . . . . . . . . 29
2.18 Interface de liste des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 diagramme de séquence s’authentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Diagramme de classe de conception S’authentifier . . . . . . . . . . . . . . . . . . . . . 35
3.4 Diagrammes de séquence inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Diagramme de classe de conception d’inscription . . . . . . . . . . . . . . . . . . . . . 37
3.6 Diagramme de séquence «Ajouter réservation» . . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Diagramme de séquence «Consulter réservation» . . . . . . . . . . . . . . . . . . . . . 39
3.8 Diagramme de séquence «Supprimer réservation» . . . . . . . . . . . . . . . . . . . . . 40

vi
3.9 Diagramme de classe de conception «Gérer réservation» . . . . . . . . . . . . . . . . . 40
3.10 diagramme de séquence consulter historique . . . . . . . . . . . . . . . . . . . . . . . . 41
3.11 Diagramme de séquence «éditer les données personnelles» . . . . . . . . . . . . . . . . 42
3.12 Diagramme de séquence «modifier véhicule» . . . . . . . . . . . . . . . . . . . . . . . . 43
3.13 Diagramme de classe de conception «Gérer véhicule» . . . . . . . . . . . . . . . . . . . 44
3.14 Diagramme de séquence «Consulter les frais» . . . . . . . . . . . . . . . . . . . . . . . 45

4.1 MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Logo Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Logo Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Logo Dart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Logo Json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6 Logo Yaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 Logo UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.8 Logo UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.9 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.10 Interface d’inscription 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.11 Interface d’inscription 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.12 Interface page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.13 Interface de selection date et heure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.14 Interface de selection date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.15 Interface de temp de début . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.16 Interface de temp de fin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.17 Interface du plan du parking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.18 Interface de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.19 Interface des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.20 ticket de réservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.21 Interface de liste des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.22 Interface de liste des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.23 Interface de liste des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.24 Interface de liste des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.25 Interface de liste des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.26 Interface de liste des réservations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

vii
Liste des tableaux

2.1 tableau de Description des besoins fonctionnels de client . . . . . . . . . . . . . . . . . 11

2.2 tableau de Description des besoins fonctionnels de l’administrateur . . . . . . . . . . . 11
2.3 tableau descriptif du cas d’utilisation S’authentifier . . . . . . . . . . . . . . . . . . . . 14
2.4 tableau descriptif du cas d’utilisation Ajouter réservation . . . . . . . . . . . . . . . . . 17
2.5 tableau descriptif du cas d’utilisation Consulter réservation . . . . . . . . . . . . . . . 18
2.6 tableau descriptif du cas d’utilisation Supprimer réservation . . . . . . . . . . . . . . . 18
2.7 tableau descriptif du cas d’utilisation Consulter données personnels . . . . . . . . . . . 19
2.8 tableau descriptif du cas d’utilisation Modifier données personnelles . . . . . . . . . . . 20
2.9 tableau descriptif du cas d’utilisation Consulter véhicule . . . . . . . . . . . . . . . . . 21
2.10 tableau descriptif du cas d’utilisation modifier véhicule . . . . . . . . . . . . . . . . . . 22
2.11 tableau descriptif du cas d’utilisation Modifier carte de crédit . . . . . . . . . . . . . . 23
2.12 tableau descriptif du cas d’utilisation Consulter Carte de crédit . . . . . . . . . . . . . 24
2.13 tableau descriptif du cas d’utilisation Consulter historique . . . . . . . . . . . . . . . . 25
2.14 tableau descriptif du cas d’utilisation Consulter clients . . . . . . . . . . . . . . . . . . 27
2.15 tableau descriptif du cas d’utilisation Consulter les frais . . . . . . . . . . . . . . . . . 28
2.16 tableau descriptif du cas d’utilisation Consulter réservations . . . . . . . . . . . . . . . 29

viii
Liste des abréviations

— BI = Business Intelligence

— CXF = Celtix XFire

— HTML = HyperText MarkupLanguage

— JEE = Java Enterprise Edition

— JS = JavaScript

— ORM = Object Relation Management

— PHP = Hypertext Preprocessor

— UML = Unified Model Language

ix
Introduction générale

1
 Chapitre 1

contexte général du projet

Plan
1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Prototype des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Diagramme de cas d’utilisation raffiné . . . . . . . . . . . . . . . . . . . . . . 13

6 Diagramme détaillé de cas d’utilisation de client . . . . . . . . . . . . . . . 15

7 Diagramme de cas d’utlilisation raffiné « gérer véhicule» . . . . . . . . . . 20

8 Diagramme détaillé de cas d’utilisation de l’administrateur . . . . . . . . 25

9 Diagramme de cas d’utlilisation raffiné «consulter les frais» . . . . . . . . . 27

Chapitre 1. contexte général du projet

Introduction

Dans ce premier chapitre, nous mettrons l’accent sur le cadre du projet. De ce fait, nous
commencerons par présenter l’entreprise d’accueil Bee coders et notre client Thor system. Par la suite,
nous détaillerons le sujet du projet, en présentant la problématique et une description de l’existant.
Enfin, la dernière partie sera consacrée à la méthodologie adoptée pour la réalisation de ce projet.

1.1 Présentaion de l’organisme d’accueil

La figure 1.1 représente le logo de Bee coders

Figure 1.1 : Logo Bee coders

Beecoders est une entreprise qui est fondée sur les services numériques spécialisée dans le
développement web et mobile(Android et IOS), le design web, le consulting IT et les formations à
distance. La flexibilité est l’atout majeur de Beecoders dont elle assure le développemnt des projets des
clients dans les meilleurs conditions et elle offre des modules de formations de qualité qui s’alignent sur
les nouvelles exigences du marché d’emploi en IT. En plus elle offre pour leurs clients un consulting IT
pour garantir l’optimisation de leurs stratégie IT.

1.1.1 Organigramme de bee coders

Le schéma suivant représente l’organigramme de l’organisme d’accueil « Bee coders»

3
Chapitre 1. contexte général du projet

Figure 1.2 : Logo Bee coders

1.2 Présentation de notre client«Thor system »

1.3 Etude de l’existant

L’étude de l’existant est une étape primordiale pour la mise en route de tout projet, elle
représente le cœur de la phase d’analyse d’un projet et qui permet de définir le contexte de fonctionnement
et de dégager les différents insuffisances et imperfections dans le système actuel afin de les corriger.

1.3.1 Description de l’existant

Depuis des années, la circulation à Tunis connaît des embouteillages monstres, notamment
pendant les heures de pointe. Le stationnement constitue aussi un problème épineux. En entrant dans
la capitale, le conducteur ne sait pas où garer sa voiture. Il est contraint de faire plusieurs tours pour
dénicher une place. La mauvaise gestion des espaces de stationnement et les renseignements insuffisants
sur la disponibilité des espaces occasionnent des bouchons de circulation, font perdre du temps précieux
aux automobilistes, entraînent un gaspillage de carburant. Les conducteurs préfèrent de stationner leurs
voitures dans un parking privé pour être assurés qu’il soit en sécurité. C’est bien pour ce faire qu’il
est préférable d’opter pour ce type de parking, plutôt que de garer leurs voiture dans n’importe quel
endroit.
Les conducteurs doivent se présenter tôt pour obtenir leur place de stationnement dans un parking et
parfois il prend plusieurs minutes pour trouver une place à l’intérieur de parking.
En plus, le propriétaire du parking n’a pas une vue claire et précise sur l’occupation du parking en
temps réel et sur le taux de remplissage de leur parking.

4
Chapitre 1. contexte général du projet

1.3.2 Critique de l’existant

Aprés une analyse de l’existant nous avons relever quelques lacunes tels que : -Une mauvaise
gestion des espaces de stationnement. -L’absence d’une méthode pour une réservation et paiement à
distance -Une méthode classique pour collecter et calculer les frais -Le propriétaire de parking n’avait
pas une vue claire et précise sur l’occupation de son parking

1.4 Solution proposé

Après une étude approfondie de divers problèmes dégagés nous visons à concevoir et développer
une application mobile qui offrir une gestion intelligente et proactive du parking en permettant les
clients du consulter les places du parking en temps réel, planifier et effectuer des réservations par
prendre leurs propres décisions quant au moment et l’endroit où se garer, d’obtenir des tickets, payer
ses réservations en ligne en utilisant son carte de crédit, et de consulter l’historique de ces réservations.
La place de parking est attribuée au client de façon immédiate et celui-ci n’a pas besoin d’attendre
une confirmation. Le système se met à jour en temps réel, empêchant ainsi que deux client ne puissent
réserver la même place. Cette application doit permettre l’administrateur de consulter les frais, la liste
des clients et la liste de tous les réservations effectuées par les clients ce qui permet d’avoir une vue
claire et bien précise sur l’occupation du parking.

1.5 Méthodologie de travail

Il n’y a aucun travail scientifique élaboré sans méthode, car cette dernière nous montre quel
chemin faut –il prendre pour arriver à atteindre les objectifs que nous nous sommes assignés. Bien
qu’il existe nombreux choix de méthodologies de développement de logiciels, le choix d’une méthode
pour le projet un point vital, qui va nous suivre de début jusqu’à la fin. Après une longue réflexion,
on a fait une comparaison entre une approche classique et adaptative, en pesant les "avantages" et les
"inconvénient". Le choix de la méthodologie doit se faire par rapport à la prédictibilité, plus le projet
est rigide et prévisible c’est le choix d’une approche classique qui impose, plus le projet est flexible et
tend vers l’inconnue, alors dans ce cas c’est l’approche agile qu’il nous faut. Tandis que l’agilité est
de plus en plus utilisée pour les projets digitaux, car elle est plus moderne et adaptative aux besoins
des clients qui évoluent aux cours du projet, le choix de méthodologies ne doit pas dépendre de leur
popularité, mais plutôt choisir la plus adaptée pour coordonner et de maîtriser au mieux l’ensemble
des activités qui mènent à l’atteinte de l’objectif tout en respectant les exigences de qualité, de coûts
et de délais. Les tableaux dans les tableaux 1.1 et 1.2 montre que les deux approches ont leurs points
forts et leurs faiblesses.

5
Chapitre 1. contexte général du projet

1.5.1 Processus unifié

Le processus unifié est un processus de développement centré sur des diagrammes de cas
d’utilisation, itératif et incrémental qui utilise un langage de modélisation unifié.
Un processus unifié peut être appliqué à différents systèmes logiciels avec différents niveaux de complexité
technique. Le processus unifié répète un certain nombre de cycles qui se termine par la livraison d’une
version du produit aux clients. Le processus unifié s’organise en quatre phases :
création, élaboration, construction et transition. Chacune d’entre elles se subdivise à leur tour aux cinq
itérations suivantes (figure1.3) :
-Expression des besoins : Elle permet de définir des besoins tels que les besoins fonctionnels
permettant la modélisation des cas d’utilisation et des besoins non fonctionnels obéissant à une liste
d’exigences du système.
-Analyse : Accéder à une compréhension des besoins et des exigences du client. Il s’agit de livrer des
spécifications sous forme de scénarios qui facilitent la compréhension, la préparation, la modification
et la maintenance du futur système.
-Conception : Acquérir une compréhension approfondie des contraintes liées aux langages de programmation.
Elle détermine les principales interfaces et les transcrit à l’aide d’une notation commune. Elle constitue
un point de départ à l’implémentation en décomposant la conception en sous-systèmes.
-Implémentation : C’est le résultat de la conception pour implémenter le système sous formes de
composants qui se transforme en code source. Les objectifs principaux de l’implémentation sont de
planifier les intégrations des composants pour chaque itération.
-Tests : Vérifier des résultats de l’implémentation en testant la construction pour chaque itération, les
implémenter en créant des cas de tests en prenant en compte le résultat de chacun.

Figure 1.3 : cycle du processus unifié

6
Chapitre 1. contexte général du projet

1.5.2 La méthode 2TUP

Le processus 2TUP (Two Track Unified Process) ou le cycle en Y est un processus unifié qui
dissocie les aspects techniques des aspects fonctionnels. Le processus s’articule, autour de trois branches
essentielles (Figure 1.4).

-Branche fonctionnelle :
Consiste à capturer les besoins et à étudier les spécifications fonctionnelles afin d’obtenir une idée de ce
que nous allons réaliser dans notre système. Au cours de cette phase nous avons fait des recherches sur
l’existant qui nous ont permis d’extraire les besoins fonctionnels et non-fonctionnels de notre système.
-Branche technique : Comporte deux étapes, la première est pour la capture des besoins
techniques tels que le choix des outils et le matériel ainsi que la prise en compte des contraintes
d’intégration avec l’existant. La deuxième consiste à définir les composants nécessaires à la construction
de l’architecture technique. Durant cette phase, nous avons dégagé les pré requis et besoins techniques
associés aux outils avec lesquelles nous allons implémenter notre chaîne.
-Phase de la réalisation :
Regroupe les informations des branches technique et fonctionnelle afin d’aboutir au système final
initialement envisagé. Nous avons fusionné, au cours de cette phase, les deux branches fonctionnelles
techniques afin de mener une conception applicative permettant de livrer une solution adaptée aux
besoins signalés.

Figure 1.4 : Processus 2TUP

7
Chapitre 1. contexte général du projet

1.5.3 Choix de la méthodologie

Une étude de ces différentes méthodologies révèle qu’elles ont un tronc commun, mais elles se
différencient par leur degré de formalisme, les revues, le rythme du projet, le nombre et la longueur des
itérations et à la taille de projets. Donc, après cette étude comparative, notre choix s’est focalisé une
démarche par activités qui s’inspire du processus unifié puisque sa qualité principale est la simplicité.
ingénieur.

Conclusion

Dans ce chapitre, nous avons commencé par introduire l’entreprise d’accueil Bee coders. Par la
suite, on a présenté notre client Thor system . Après, nous avons présenté le contexte du projet en
précisant la problématique, et la solutions proposée. Enfin, nous avons fixé la méthodologie à suivre
pour l’élaboration du travail en précisant pourquoi nous avons fait ce choix. Nous passerons par la
suite dans le chapitre suivant à l’analyse et spécification des besoins.

8
 Chapitre 2

Analyse et spécification des besoins

Plan
1 diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2 Les diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapitre 2. Analyse et spécification des besoins

Introduction

L’étape de spécification des besoins constitue la base de départ de ce travail. En outre, l’adéquation
de toute l’application à réaliser, aux besoins des utilisateurs et aux traitements envisagés au niveau de
ses opérateurs assurera sa réussite et son utilité future. Pour assurer ces objectifs, il est essentiel que
nous parvenions à une vue claire des différents besoins pour déterminer les fonctionnalités attendues.

2.1 Identification des acteurs

L’administrateur et le client sont les acteurs qui interagissent avec notre projet.
• Administrateur : gére tous le systéme
• client : qui veut satisfaire ses besoins

2.2 Spécification des besoins

La spécification des besoins doit décrire le logiciel à développer. On va identifier les fonctionnalités
et les acteurs du système, et présenter les diagrammes de cas d’utilisations suivis de description textuelle
des principaux cas d’utilisation.

2.2.1 Besoins fonctionnels

Il est primordial de définir les besoins fonctionnels de notre recherche car cela nous permet de
cibler le cadre du système et de prévoir les fonctionnalités qu’il doit remplir. Il faut rappeler que le
but ultime de cette application est de donner la possibilité aux utilisateurs de gérer les activités que
nous définirons plus en détails dans les parties suivantes. Les objectifs de l’application s’atteigne par
le biais d’une interface à laquelle se connectent les utilisateurs.
Le tableau suivant nous décrivant la description des besoins fonctionnels pour le client :

10
Chapitre 2. Analyse et spécification des besoins

Utilisateur Description des besoins fonctionnels

L’application offre à un client la possibilité de :

- S’authentifier
- Gérer ces réservations
Client - Gérer ses données personnelles
- Gérer son paiement à distance
- Consulter l’historique de toutes les réservation effectuée qu’il a effectuées
- Gérer son véhicule

Tableau 2.1 : tableau de Description des besoins fonctionnels de client

Utilisateur Description des besoins fonctionnels

L’application offre à l’administrateur la possibilité de :

- S’authentifier
Administrateur - Consulter les frais
- Consulter les utilisateurs
- Consulter les réservations

Tableau 2.2 : tableau de Description des besoins fonctionnels de l’administrateur

2.2.2 Les besoins non fonctionnels

Les besoins non fonctionnels Le comportement et la performance que le produit doit avoir.
Quand les besoins fonctionnels expriment les fonctionnalités concrètes du produit, les besoins non
fonctionnels sont des indicateurs de qualité de l’exécution des besoins fonctionnels.
•Ergonomie : L’application doit être facile à utiliser et offre des interfaces confortables à l’utilisateur.
•Fiabilité : La fiabilité se présente lorsque la fonction requise du logiciel est parfaitement accomplie.
•Sécurité : La sécurité se manifeste par le choix des solutions adéquates pour la protection de
l’utilisateur de l’application.
•Le gain du temps : Accès aux différentes tâches effectuées doit se faire en un temps de réponse qui
doit être le plus court possible.

2.3 Prototype des interfaces

Un prototype est un modéle original qui posséde toutes les qualités techniques et toutes les
caractéristiques de fonctionnement d’un nouveau produit. Dans le domaine de développement applications

11
Chapitre 2. Analyse et spécification des besoins

une technique est apparue intéressant : il s’agit du prototypage.Cette technique consiste à préparer
quelques interfaces graphiques de l’application en utilisant un outil de conception de prototypes afin de
valider le choix du client cela nous permettra d’améliorer et optimiser avant la réalisation pour éviter
de se bloque dans des choix erron´es qu’il lui serait difficile de modifier une fois l’application crée.

2.4 Diagramme de cas d’utilisation

Les diagrammes de cas d’utilisation a pour but de donner une vision globale sur les interfaces
de futur application . C’est le premier diagramme UML constitué d’un ensemble d’acteurs qui agit
sur des cas d’utilisation et qui décrit sous la forme d’actions et des réactions, le comportement d’un
systéme du point de vue utilisateur. Un cas d’utilisation représente une unité significative de travail.
Dans un diagramme de cas d’utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent
avec les cas d’utilisation (use cases) .

2.4.1 Le cas d’utilisation

Un cas d’utilisation est une unité cohérente représentant une fonctionnalité visible de l’extérieur.Il
réealise un service de bout en bout, avec un d´eclenchement, un déroulement et une fin, pour l’acteur
qui l’initie. Un cas d’utilisation modélise donc un service rendu par l’application, sans imposer le monde
de réalisation de service.

2.4.2 Diagramme de cas d’utilisation globale

Le diagramme du cas d’utilisation générale décrivent les cas d’utilisations basique pour avoir
une vue globale du fonctionnement de l’application.

12
Chapitre 2. Analyse et spécification des besoins

Figure 2.1 : Diagramme de cas d’utilisation globale

nous allons assurer par la suite le raffinement des tâches de gestion des ressources et faire
apparaitre plus de fonctionnalités que l’utilisateur peut exploiter.

2.5 Diagramme de cas d’utilisation raffiné

Le raffinement est une opération nécessaire est fortement significative car elle va permettre de
mieux comprendre avec plus de détails les fonctionnalités de l’application

2.5.1 Diagramme de cas d’utilisation «s’authentifier»

L’authentification est un processus permettant au systéme de s’assurer de la légitimité de la

demande d’accées faite par l’utilisateur afin d’autoriser l’accés des ressources de l’application.

13
Chapitre 2. Analyse et spécification des besoins

Figure 2.2 : Diagramme de cas d’utilisation «s’authentifier»

Dans le tableau suivant nous présentons une description textuelle de la figure2.2 :

Cas
S’authentifier
d’utilisation

Acteurs Administrateur / client

Pré-condition -L’utilisateur doit avoir un compte existé

Post condition -Page d’accueil affichée

-L’utilisateur lance l’application

-L’application affiche la page de connexion
Scénario(s) -L’utilisateur saisie son login et mot de passe
Nominal -L’application vérifie si les champs obligatoires sont remplis
-L’application recherche dans la base de données
-L’application affiche la page d’accueil

-Si un champ manquant le système affiche un message d’erreur

Scénario(s)
-Si l’utilisateur ne se trouve pas dans la base de données le système affiche un
Alternatif
message d’erreur

Tableau 2.3 : tableau descriptif du cas d’utilisation S’authentifier

•Prototype de l’interface d’authentification

14
Chapitre 2. Analyse et spécification des besoins

Figure 2.3 : Interface d’authentification

2.6 Diagramme détaillé de cas d’utilisation de client

Cette partie est dédiée a toutes les fonctionalités assurés par le client.

2.6.1 Diagramme de cas d’utlilisation raffiné « gérer réservation »

La figure 3.14 représente le diagramme de cas d’utilisation «Gérer réservation»

15
Chapitre 2. Analyse et spécification des besoins

Figure 2.4 : Diagramme de cas d’utilisation «gérer réservation»

Dans le tableau suivant nous présentons une description textuelle ajouter réservation de la
figure2.4

16
Chapitre 2. Analyse et spécification des besoins

Cas
Ajouter réservation
d’utilisation

Acteurs Client

Pré-condition -Client authentifié

Post condition -Une place est réservé

-Le client clique sur le bouton « nouvelle réservation»

-L’application affiche un interface pour choisir la date et l’intervalle de temps
-Le client clique sur « choisir la date et le temps»
-L’application affiche une calendrier
-Le client choisi l’année, le mois et le jour
-L’application affiche une horloge pour choisir le temps de début.
-Le client sélectionne le temps de début de réservation.
-L’application affiche une horloge pour choisir le temps de la fin de la
Scénario(s)
réservation.
Nominal
-Le client sélectionne le temps de fin de réservation.
-L’application affiche un plan du parking dans l’intervalle de temps sélectionnée
par l’utilisateur.
-Le client cliquer sur une place
-L’application afficher au-dessous du plan un butons « réserver »
-Le client clique sur le bouton « réserver »
-L’application affiche le frais à payer avec plus de détail sur la réservation
-Le client clique sur le bouton « payer ».

Scénario(s)
-Pas du solde suffisant
Alternatif

Tableau 2.4 : tableau descriptif du cas d’utilisation Ajouter réservation

Dans le tableau suivant nous présentons une description textuelle consulter réservation de la
figure3.14

17
Chapitre 2. Analyse et spécification des besoins

Cas
Consulter réservation
d’utilisation

Acteurs Administrateur / Client

-Client authentifié
Pré-condition
-réservation existant

Post condition -Réservation affiché

- Le client clique sur l’icône de réservation

-L’application affiche les réservation en cours du client
Scénario(s)
-Le client clique sur une réservation
Nominal
-L’application affiche le ticket du réservation choisi qui contient un QR code
avec des informations détaillées concernant cette réservation

Scénario(s)
-Pas d’une réservation en cours à afficher
Alternatif

Tableau 2.5 : tableau descriptif du cas d’utilisation Consulter réservation

Dans le tableau suivant nous présentons une description textuelle supprimer réservation de la figure3.14

Cas
Supprimer réservation
d’utilisation

Acteurs Client

Pré-condition -Client authentifié -Réservation existant

Post condition -Réservation supprimé

Scénario(s) -Le client clique sur le bouton « Supprimer »

Nominal -L’application supprime la réservation.

Scénario(s)
Rien à afficher
Alternatif

Tableau 2.6 : tableau descriptif du cas d’utilisation Supprimer réservation

2.6.2 Diagramme de cas d’utlilisation raffiné « gérer données personnels

»

La figure représente le diagramme de cas d’utilisation «Gérer données personnels»

18
Chapitre 2. Analyse et spécification des besoins

Figure 2.5 : Diagramme de cas d’utilisation «gérer les données personnels»

Dans le tableau suivant nous présentons une description textuelle Consulter données personnels
de la figure 2.5

Cas
Consulter données personnels
d’utilisation

Acteurs client

Pré-condition -Client authentifié

Post condition -Données personnelles affichés

Scénario(s) -L’utilisateur clique sur le bouton «données personnelles»

Nominal -L’application affiche les données personnelles du client

Scénario(s)
Rien à afficher
Alternatif

Tableau 2.7 : tableau descriptif du cas d’utilisation Consulter données personnels

Dans le tableau suivant nous présentons une description textuelle modifier données personnelles
de la figure 2.5

19
Chapitre 2. Analyse et spécification des besoins

Cas
Modifier données personnelles
d’utilisation

Acteurs client

Pré-condition -Client authentifié

Post condition -Données personnelles édités

-Le client clique sur l’icône d’édit

-L’application affiche le formulaire de modification des données personnelles.
Scénario(s) -Le client remplit le formulaire
Nominal -Le client clique sur le bouton « Enregistrer »
-L’application vérifie si les champs obligatoires sont manquants
-L’application ajoute les données dans la base de donnés.

Scénario(s)
-Si un champ obligatoire est manquant l’application affiche un message d’erreur
Alternatif

Tableau 2.8 : tableau descriptif du cas d’utilisation Modifier données personnelles

•Prototype de l’interface des données personnelles

Figure 2.6 : Interface des données personnelles

2.7 Diagramme de cas d’utlilisation raffiné « gérer véhicule»

La figure2.11 représente le diagramme de cas d’utilisation «Gérer véhicule»

20
Chapitre 2. Analyse et spécification des besoins

Figure 2.7 : Diagramme de cas d’utilisation «gérer réservation»

Dans le tableau suivant nous présentons une description textuelle Consulter véhicule de la
figure2.11

Cas
Consulter véhicule
d’utilisation

Acteurs client

Pré-condition -Client authentifié

Post condition -Véhicule édité

- Le client clique sur le bouton «les données du véhicule»

Scénario(s)
- Le système affiche les données du véhicule
Nominal

Scénario(s)
Rien à afficher
Alternatif

Tableau 2.9 : tableau descriptif du cas d’utilisation Consulter véhicule

Dans le tableau suivant nous présentons une description textuelle modifier véhicule personnelles
de la figure 2.11

21
Chapitre 2. Analyse et spécification des besoins

Cas
Modifier véhicule
d’utilisation

Acteurs client

Pré-condition -Client authentifié

Post condition -Véhicule édité

-L’utilisateur clique sur le bouton «carte de crédit»

-L’application affiche la carte de crédit du client
-Le client clique sur l’icône d’édit
Scénario(s) -L’application affiche le formulaire de modification du véhicule
Nominal -Le client remplit le formulaire
-Le client clique sur le bouton « Enregistrer »
-L’application vérifie si le champs obligatoire est manquants
-L’application ajoute les données dans la base de donnés.

Scénario(s)
-Si un champ obligatoire est manquant l’application affiche un message d’erreur
Alternatif

Tableau 2.10 : tableau descriptif du cas d’utilisation modifier véhicule

•Prototype de l’interface Gérer véhicule

Figure 2.8 : Interface du véhicule

22
Chapitre 2. Analyse et spécification des besoins

2.7.1 Diagramme de cas d’utlilisation raffiné « la carte crédit»

La figure représente le diagramme de cas d’utilisation «Gérer paiemnt »

Figure 2.9 : Diagramme de cas d’utilisation «gérer paiement»

Dans le tableau suivant nous présentons une description textuelle modifier carte de crédit
personnelles de la figure2.9

Cas
Modifier carte de crédit
d’utilisation

Acteurs client

-Client authentifié
Pré-condition -Carte de crédit existant

Post condition Carte de crédit modifié

-L’utilisateur clique sur le bouton «carte de crédit»

-L’application affiche la carte de crédit du client
-Le client clique sur l’icône d’édit
Scénario(s) -L’application affiche le formulaire de modification de la carte de crédit
Nominal -Le client remplit le formulaire
-Le client clique sur le bouton « Enregistrer »
-L’application vérifie si les champs obligatoires sont manquants
-L’application ajoute les données dans la base de donnés.

Scénario(s)
-Si un champ obligatoire est manquant l’application affiche un message d’erreur
Alternatif

Tableau 2.11 : tableau descriptif du cas d’utilisation Modifier carte de crédit

23
Chapitre 2. Analyse et spécification des besoins

Dans le tableau suivant nous présentons une description textuelle Consulter carte de crédit de
la figure2.9

Cas
Consulter carte de crédit
d’utilisation

Acteurs client

-Client authentifié
Pré-condition -Carte de crédit existant

Post condition -Carte de crédit affiché

- le client clique sur le bouton «carte de crédit »

Scénario(s)
- Le système affiche la carte de crédit
Nominal

Scénario(s)
Rien à afficher
Alternatif

Tableau 2.12 : tableau descriptif du cas d’utilisation Consulter Carte de crédit

•Prototype de l’interface Gérer carte de crédit

Figure 2.10 : Interface de carte de crédit

24
Chapitre 2. Analyse et spécification des besoins

2.7.2 Diagramme de cas d’utlilisation raffiné « Consulter l’historique de

réservations»

La figure représente le diagramme de cas d’utilisation «Gérer données personnels»

Figure 2.11 : Diagramme de cas d’utilisation «Consulter historique»

Dans le tableau suivant nous présentons une description textuelle consulter l’historique des
réservations de la figure2.11

Cas
Consulter historique
d’utilisation

Acteurs client

Pré-condition -Client authentifié

Post condition -L’historique des réservations affichées

Scénario(s) -L’utilisateur clique sur l’icone de l’historique

Nominal -L’application affiche les réservation du client.

Scénario(s)
-Pas des réservations à afficher
Alternatif

Tableau 2.13 : tableau descriptif du cas d’utilisation Consulter historique

•Prototype de l’interface de l’historique

2.8 Diagramme détaillé de cas d’utilisation de l’administrateur

2.8.1 Diagramme de cas d’utlilisation raffiné « Consulter utilisateur »

La figure représente le diagramme des cas d’utilisation «Consulter clients»

Dans le tableau suivant nous présentons une description textuelle Consulter utilisateur de la
figure2.13

25
Chapitre 2. Analyse et spécification des besoins

Figure 2.12 : Interface de l’historique

Figure 2.13 : Diagramme de cas d’utilisation «gérer paiement»

Cas
Consulter clients
d’utilisation

-Administrateur authentifié
Acteurs
-Clients existants

Pré-condition -Client affiché

Post condition -L’historique des réservations affichées

- -L’administrateur clique sur l’icone de client

Scénario(s) -L’application affiche la liste des clients
Nominal -L’administrateur clique sur le nom du clients
- L’application affiche l’utilisateur

Scénario(s)
-Pas des réservations à afficher
Alternatif

26
Chapitre 2. Analyse et spécification des besoins

Tableau 2.14 : tableau descriptif du cas d’utilisation Consulter clients

•Prototype de l’interface de consultation des clients

Figure 2.14 : Interface de liste des clients

2.9 Diagramme de cas d’utlilisation raffiné «consulter les frais»

La figure représente le diagramme des cas d’utilisation «consulter les frais»

Figure 2.15 : Diagramme de cas d’utilisation «gérer paiement»

Dans le tableau suivant nous présentons une description textuelle consulter les frais de la
figure2.15

27
Chapitre 2. Analyse et spécification des besoins

Cas
Consulter les frais
d’utilisation

Acteurs Administrateur authentifié

Pré-condition Les frais affiché

Post condition -L’historique des réservations affichées

Scénario(s) -L’utilisateur clique sur le bouton « consulter les frais »

Nominal -L’application affiche les frais pour chaque jour

Scénario(s)
Rien à afficher
Alternatif

Tableau 2.15 : tableau descriptif du cas d’utilisation Consulter les frais

•Prototype de l’interface consultatuion du frais

Figure 2.16 : Interfaces des frais

2.9.1 Diagramme de cas d’utlilisation raffiné «consulter les réservations»

La figure représente le diagramme des cas d’utilisation «Consulter les frais»

Dans le tableau suivant nous présentons une description textuelle consulter réservations de la
figure4.8

28
Chapitre 2. Analyse et spécification des besoins

Figure 2.17 : Diagramme de cas d’utilisation «consulter les frais»

Cas
Consulter réservations
d’utilisation

Acteurs Administrateur authentifié

Pré-condition -Tous les réservations affichées

Post condition -Tous les réseravtions affichés

-L’utilisateur clique sur le bouton «consulter les réservations»

Scénario(s)
-L’application affiche tous les réservations
Nominal

Scénario(s)
Rien à afficher
Alternatif

Tableau 2.16 : tableau descriptif du cas d’utilisation Consulter réservations

•Prototype de l’interface consultatuion de liste des réservations

Figure 2.18 : Interface de liste des réservations

29
Chapitre 2. Analyse et spécification des besoins

Conclusion

Dans ce chapitre, on a énuméré les besoins fonctionnels et les besoins Non fonctionnels de ce
projet. De plus, on a élaboré les différents diagrammes de cas d’utilisation ainsi que leurs descriptions
textuelles. Dans le chapitre suivant, nous allons procéder la modélisation de ces fonctionnalités par une
étude conceptuelle afin de mieux comprendre le développement de cette application.

30
 Chapitre 3

Conception

Plan
1 Architecture de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . 48

3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Chapitre 3. Conception

Introduction

La conception est la phase la plus importante de cycle de développement permettant aux

concepteurs de d´ecrire un syst´eme d’information avec des diagrammes illustr´es avant de le d´evelopper,
ainsi que aprés avoir sp´ecifie les besoins fonctionnels et non fonctionnels de l’application, nous faisons
la conception de diff´erentes parties du projet moyennant des diagrammes crées avec le langage UML.

3.1 diagramme de classe

Le diagramme de classe fait une description détaillée de l’ensemble des classes d’un système en
montrant la structure interne, en identifiant les propriétés de chaque classe. Les différentes associations
entre les classes y sont également représentées

Figure 3.1 : Diagramme de classe

3.2 Les diagrammes de séquences

3.2.1 Définition et composition

Le diagramme de séquences est un diagramme UML ( Unified Modeling Langage ), permet de

cacher les interactions d’objets dans le cadre d’un scénario d’une utilisation, un souci de simplification,
on présente l’acteur principal à gauche du diagramme et les acteurs secondaires éventuels à droite
du systéme. Le but étant de décrire comment se déroulent les actions entre les acteurs et les objets.
Acteurs :personne ou une chose extérieur au systéme étudié qui interagit avec le systéme étudié. Le
même être humain peut avoir alternativement plusieurs rôles.
objets :Les objets sont des entités appartenant au systéme les objets interviennent dans l’interaction(envoi

32
Chapitre 3. Conception

de message entre objets).

Messages :Les objets communiquent en échangeant des messages représentés sous la forme des fléches.
Les messages sont étiquetés par le nom de l’opération ou du signal invoqué.

3.2.2 Diagramme de séquence s’authentifier

Acteurs :Administrateur et client.

Le diagramme ci-dessous explique le scénario d’authentification, l’utilisateur remplit le formulaire qui
apparaît dès que l’utilisateur ouvre l’application. Le contrôleur vérifie si les champs sont remplis puis
le modèle vérifie la validité des données puis redirige l’utilisateur vers la page d’accueil. Dans les cas
contraire, le formulaire affiche des messages d’erreur éventuels.

33
Chapitre 3. Conception

Figure 3.2 : diagramme de séquence s’authentifier

34
Chapitre 3. Conception

3.2.3 Diagramme de classe de conception S’authentifier

Figure 3.3 : Diagramme de classe de conception S’authentifier

3.2.4 Diagrammes de séquence inscription

Acteur :Administrateur et client.

Pour faire l’inscription, le systéme vérifie d’abord si les données saisies par l’utilisateur ne sont pas
déjà existés, si la vérification se termine avec succés l’utilisateur peut acccéder à son espace par son
adresse e-mail et son mot de passe.

35
Chapitre 3. Conception

Figure 3.4 : Diagrammes de séquence inscription

36
Chapitre 3. Conception

3.2.5 Diagramme de classe de conception inscription

Figure 3.5 : Diagramme de classe de conception d’inscription

3.2.6 Diagrammes de séquence «gérer réservation»

3.2.6.1 Diagramme de séquence «Ajouter réservation»

Acteurs :client.
Après l’authentifié le client peut ajouter une réservation en cliquant sur le bouton «nouvelle réservation»
puis l’application affiche une interface pour sélectionner la date et l’intervalle du temps de la réservation.
Le client clique sur le bouton « entrée » puis l’application affiche un calendrier alors le client doit
sélectionner la date de la réservation puis l’application affiche une horloge pour sélectionner le temps
d’entrer dans le parking, puis l’application retourne une interface qui affiche les données sélectionnée,
le client clique sur le bouton «fin réservation » alors l’application affiche une deuxième horloge pour
sélectionner le temps de la fin de réservation. Puis l’application affiche l’interface qui contient tous les
informations. Le client clique sur le bouton «choisir place», l’application affiche le plan du parking dans
le moment sélectionné Le client clique sure une place vide puis le client clique sur le bouton «réserver»
pour afficher tous les données de la réservation (date, l’intervalle du temps, nom du client, nom de la
place, prix . . .), finalement le client clique sur le bouton «payer» pour payer son réservation. Si le solde

37
Chapitre 3. Conception

suffisant la réservation et effectué avec succès.

Figure 3.6 : Diagramme de séquence «Ajouter réservation»

38
Chapitre 3. Conception

3.2.6.2 Diagramme de séquence «Consulter réservation»

Acteurs :client.
Si le client déjà ajouté une ou plusieurs réservations, il peut le consulter comme illustre le diagramme
de séquence suivant :

Figure 3.7 : Diagramme de séquence «Consulter réservation»

3.2.6.3 Diagramme de séquence «Supprimer réservation»

Acteurs :client.
Si le client déjà ajouté une réservation, il peut la supprimer comme illustre le diagramme de séquence
suivant :

39
Chapitre 3. Conception

Figure 3.8 : Diagramme de séquence «Supprimer réservation»

3.2.6.4 Diagramme de classe de conception «Gérer réservation»

Figure 3.9 : Diagramme de classe de conception «Gérer réservation»

40
Chapitre 3. Conception

3.2.7 diagramme de séquence consulter historique

Acteurs :client.
Après l’authentification le client peut consulter l’historique de ses réservations comme l’illustre le
diagramme de séquence suivant :

Figure 3.10 : diagramme de séquence consulter historique

3.2.8 Diagramme de séquence «éditer les données personnelles»

Acteurs :client.

41
Chapitre 3. Conception

Figure 3.11 : Diagramme de séquence «éditer les données personnelles»

3.2.9 Diagrammes de séquence «gérer véhicule»

3.2.9.1 Diagramme de séquence «modifier véhicule»

Après l’authentifié le client peut modifier son véhicule qu’il est saisi lors de l’inscription

42
Chapitre 3. Conception

Figure 3.12 : Diagramme de séquence «modifier véhicule»

43
Chapitre 3. Conception

3.2.9.2 Diagramme de classe de conception «Gérer véhicule»

Figure 3.13 : Diagramme de classe de conception «Gérer véhicule»

3.2.10 Diagramme de séquence «Consulter clients»

Acteurs :Administrateur.

3.2.11 Diagramme de séquence «Consulter les frais»

Acteurs :Administrateur.

44
Chapitre 3. Conception

Figure 3.14 : Diagramme de séquence «Consulter les frais»

3.2.12 Diagramme de séquence «Consulter réservations»

Acteurs :Administrateur.

Conclusion

La phase conceptuelle est une étape fondamentale pour la réalisation de n’importe quel projet.
Elle permet de faciliter le systéme d’information et réaliser l’implémentation de la base de données et
le traitement.Dans ce chapitre nous avons présenté les diagrammes de séquences et les diagrammes
de classes de notre application.Le chapitre suivantest consacré à la phase de réalisation de notre
application

45
 Chapitre 4

Réalisation
Chapitre 4. Réalisation

Introduction

Une manipulation souple et aisée reste toujours parmi les critéres les plus décisifs pour le
succés de tout projet. C’est pourquoi le choix des outils de programmation doit être bien étudié.Dans
ce chapitre nous présentons en premier temps l’architecture et l’environnement de développement
utilisés.Dans un second temps nous illustrons la réalisation de notre travail par des imprimes écran des
interfaces les plus importantes de notre application.

4.1 Architecture de développement

Afin de bien concevoir notre application et bien organiser notre code, nous avons opté pour
l’architecture MVC. Le MVC signifie Model-View-Controller est un modèle architectural qui sépare
une application en trois composants logiques principaux : modèle, vue et le contrôleur. Chacun de ces
composants est construit pour gérer des aspects de développement spécifiques du notre application.

Figure 4.1 : MVC

-Modèle :
Le modèle contient les données manipulées par le programme. Il assure la gestion de ces données et
garantit leur intégrité. Dans le cas typique d’une base de données, c’est le modèle qui la contient.
Le modèle offre des méthodes pour mettre à jour ces données (insertion suppression, changement de
valeur). Il offre aussi des méthodes pour récupérer ses données. Dans le cas de données importantes,
le modèle peut autoriser plusieurs vues partielles des données.

-Vue :
La vue fait l’interface avec l’utilisateur. Elle permet d’afficher les données qu’elle a récupérées auprès
du modèle et de recevoir tous les actions de l’utilisateur. Ses différents événements sont envoyés au
contrôleur. La vue peut aussi donner plusieurs vues, partielles ou non, des mêmes données.

47
Chapitre 4. Réalisation

-Contrôleur :
Le contrôleur est chargé de la synchronisation du modèle et de la vue. Il reçoit tous les événements de
l’utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des données, le
contrôleur demande la modification des données au modèle et ensuite avertit la vue que les données
ont changé pour que celle-ci se mette à jour. Certains événements de l’utilisateur ne concerne pas les
données mais la vue. Dans ce cas, le contrôleur demande à la vue de se modifier.

4.2 Environnement de développement

Nous présentons dans cette section l’environnement matériel mis à la disposition du présent
projet , ainsi que l’environnement logiciel utilisé pour le développement et la mise en place de notre
application.

4.2.1 Environnement matériel

Pour l’implémentation du notre projet, nous avons utilisé :

Entité Description

Modèle : HP
Processeur : Intel® Core™ i5 CPU
Pc portable RAM : 8G
Disque dur : 465 Go
Système d’exploitation : Windows 10

4.2.2 Environment logiciel

Dans ce qui suit nous présentons l’environnement logiciel utilisé pour mener à terme ce sujet

4.2.2.1 Framework utilisés

Flutter
Flutter est un Framework de développement d’applications multiplateforme utilisant la langage Dart
, il est utilisé pour développer des applications Android , IOS , Windows , Mac, Linux, Fuchsia et
web à partir d’une seule base de code ce qui permet de simplifier et réduire le temps et le cout de
développement . La stratégie de Flutter « Tout est un widget » intègre de manière systématique
la programmation orientée objet jusque dans l’interface utilisateur : l’interface d’un programme se
compose de différents widgets pouvant être imbriqués les uns dans les autres.Il offre un accès à des
bibliothèques complètes d’éléments d’IU préconçus , une implémentation facile de flux de données

48
Chapitre 4. Réalisation

pour la mise à jour continue des utilisateurs et une compilation extrement rapide grâce à la propriété
rechargement à chaud (« Hot Reload ») pour que l’application se recharge automatiquement quand le
code est modifié de manière presque instantané.

Figure 4.2 : Logo Flutter

Firebase
Firebase est une plateforme de développement d’applications mobiles de Google dotée de puissantes
fonctionnalités pour le développement, la manipulation et l’amélioration des applications. Firebase
est fondamentalement un ensemble d’outils sur lesquels les développeurs peuvent compter, créant des
applications et les développant en fonction de la demande.
Firebase vise à résoudre trois problèmes principaux pour les développeurs :
• Créer une application, rapidement
• Publiez et supervisez une application en toute confiance
• Faire participer les utilisateurs
Les développeurs qui s’appuient sur cette plateforme ont accès à des services qu’ils devraient développer
eux-mêmes, et cela leur permet de se concentrer sur la fourniture d’expériences d’applications robustes.
Parmi les caractéristiques les plus remarquables de la plateforme Google Firebase, citons les bases de
données, l’authentification, les messages « push », l’analyse, le stockage de fichiers, et bien plus encore.
Comme les services sont hébergés dans le cloud, les développeurs peuvent effectuer une mise à l’échelle
à la demande sans aucun problème. Firebase est actuellement l’une des principales plateformes de
développement d’applications sur lesquelles s’appuient les développeurs du monde entier.

Figure 4.3 : Logo Firebase

49
Chapitre 4. Réalisation

4.2.3 Langages de développement

Dart
Dart est un langage de programmation web développé par Google. Son but initial est de remplacer
JavaScript pour devenir la nouvelle langue du développement web, néanmoins la priorité actuelle des
développeurs est que le code Dart puisse être converti en code JavaScript compatible avec tous les
navigateurs modernes, ainsi que sur le développement d’application multi-plateforme. Dart peut aussi
être utilisé pour la programmation côté serveur, ainsi que le développement d’applications mobiles (via
l’API Flutter).

Figure 4.4 : Logo Dart

JSON
JSON est un format de données textuelles dérivé de la notation des objets du langage JavaScript. Il
permet de représenter de l’information structurée comme le permet XML par exemple. Dans notre
projet il nous a servi lors de l’échange de données entre notre back et le front de notre application
facilitant ainsi une communication fluide entre les deux parties.

Figure 4.5 : Logo Json

YAML
YAML est un langage sous format de représentation de données par sérialisation Unicode. Il reprend des
concepts d’autres langages comme XML. Son objet est de représenter des informations plus élaborées
que le simple CSV en gardant cependant une lisibilité presque comparable, et bien plus grande en tout
cas que du XML.

50
Chapitre 4. Réalisation

Figure 4.6 : Logo Yaml

4.2.4 Langage de modélisation et outil de conception

4.2.4.1 Présentation du langage UML

Le langage UML ( Unified Model Language ) est un langage de modélisation graphique base de
pictogrammes Conçu pour fournir une méthode normalisée pour spécifier,visualise,modifier et construire
la conception d’un systéme.Il est couramment utilisé en développement logiciel et en conception orienté
objet. UML est essentiellement un support de communication, qui facilite la représentation et la
compréhension de solution objet.Sa notion graphique permet d’exprimer visuellement une solution
object,ce qui facilite la compraison et l’évaluation des solutions.L’aspect de sa notion, limite l’ambiguité
et les incompréhensions. Une façon d’UML mettre en oeuvre est considérer vues qui peuvent se
superposer pour collaborer à la définition du systéme.

Figure 4.7 : Logo UML

4.2.4.2 astah

Astah est un outil de modélisation UML créé par la compagnie japonaise ChangeVision. Il
fonctionne avec l’environnement d’exécution Java. Le nom vient de l’acronyme Java and UML developers’
environment. Astah est un logiciel propriétaire qui était distribué gratuitement en version "community".

Figure 4.8 : Logo UML

51
Chapitre 4. Réalisation

4.3 Réalisation

La phase de réalisation consiste au développement de la solution par l’utilisation de différents

outils et technologies. Durant cette phase, nous avons implémenté les différentes fonctionnalités mentionnées
précédemment dans la conception avec la transformation des maquettes en interfaces utilisateurs.

4.3.1 Interface d’authentification

Lors de l’ouverture de notre système, la première page que nous rencontrons est la page
d’authentification présentée dans la figure?? L’utilisateur doit d’abord saisir son email et son mot
de passe puis en appuyant sur le bouton "Se connecter", il sera redirigé vers l’interface home

Figure 4.9 : Interface d’authentification

52
Chapitre 4. Réalisation

4.3.2 Interface d’inscription

Figure 4.10 : Interface d’inscription 1

Figure 4.11 : Interface d’inscription 2

4.3.3 Les interfaces du client

4.3.4 Interface d’inscription

4.3.4.1 Page d’accueil

Après l’authentification une page d’accueil s’affiche. la figure 4.26

53
Chapitre 4. Réalisation

Figure 4.12 : Interface page d’accueil

4.3.4.2 les interfaces de réservations

L’application va afficher l’interface présenté dans la figure4.26

Figure 4.13 : Interface de selection date et heure

après cliquer sur le bouton "début réservation" l’application affichera un calendrier pour choisir
la date de réservation

54
Chapitre 4. Réalisation

Figure 4.14 : Interface de selection date

La deuxième étape est sélectionner l’heure exacte de début de réservation

Figure 4.15 : Interface de temp de début

La troisième étape est sélectionner l’heure exacte de fin de réservation

55
Chapitre 4. Réalisation

Figure 4.16 : Interface de temp de fin

Après avoir sélectionné la date et l’heure de début et de fin l’application affichera le plan du
parking dans l’intervalle de temps sélectionné par le client , les places disponibles affichés sous forme
des rectangles verts comme l’illustre le figure suivant , le client choisir l’étage et clique sur la place où
il veut garer

Figure 4.17 : Interface du plan du parking

La dernière étape est payer son réservation , le prix est affiché comme l’illustre le figure4.26

56
Chapitre 4. Réalisation

Figure 4.18 : Interface de paiement

4.3.4.3 la liste des réservations

Le client consulte ses réservations comme l’illustre la figure suivant

Figure 4.19 : Interface des réservations

57
Chapitre 4. Réalisation

4.3.4.4 Ticket de réservation

Figure 4.20 : ticket de réservation

4.3.4.5 l’historique des réservations

Figure 4.21 : Interface de liste des réservations

58
Chapitre 4. Réalisation

4.3.4.6 L’interface des données personnelles

Figure 4.22 : Interface de liste des réservations

4.3.4.7 l’interface du véhicule

4.3.4.8 l’interface de carte de crédit

Figure 4.23 : Interface de liste des réservations

59
Chapitre 4. Réalisation

4.3.5 les interfaces de ladministrateur

4.3.5.1 l’interface des frais

Figure 4.24 : Interface de liste des réservations

4.3.5.2 Liste des clients

Figure 4.25 : Interface de liste des réservations

60
Chapitre 4. Réalisation

4.3.6 Liste des réservations

Figure 4.26 : Interface de liste des réservations

Conclusion

Tout au long de notre chapitre , nous avons atteint la fin d’´etude du projet.Dans ce dernier
chapitre , nous avons ‘a la fois d´ecrit les environnements matriels , logiciels, et les langages utilis´ees
sur lesquels nous avons construit notre application.Ensuite ,nous avons illustr´e les fonctionnalit´es
importantantes de l’application en fournissant quelques interfaces graphiques.Au pr´esent , nous passons
‘a la conclusion g´en´erale et les perspective de notre projet.

61
Conclusion générale

62
Conclusion générale

63