Le projet (académique) consiste à réalité 3 applications sur 3 plates-formes différentes (Desktop avec Langage Java + Swing / Web avec Framework Symfony2 et Mobile sous J2ME) Parmi les fonctionnalités demandées : - Consulter la liste des restaurants - Consulter les menus des différents restaurants - Commenter et noter un restaurant - Rechercher un restaurant selon des critères personnalisés - Simuler le coût - Effectuer une réservation - Trouver les bons plans - Ajouter un restaurant avec toutes ses préférences (photos, emplacement, menu, …) - Gérer la réservation et sa mise en place - Gestion de la facturation

1. Sommaire
Chapitre 1
I. Etude de contexte ................................................................................. 1
1. Identification des acteurs ..............................................................................................1
2. Identification des besoins fonctionnels :........................................................................2
3. Identification des besoins non fonctionnels :.................................................................3
II. Analyse globale......................................................................................... 4
1. Diagramme de cas d’utilisation globale :.......................................................................4
2. Diagramme de classe d’analyse globale : ......................................................................5
III. Modélisation de l’architecture logique et physique de l’application... 6
1. Modélisation de l’architecture logique : ........................................................................6
2. Modélisation de l’architecture physique :......................................................................6
IV. Elaboration du product backlog............................................................. 7
V. Elaboration des maquettes .................................................................... 11
VIII. Conclusion.............................................................................................. 13
Chapitre 2
I. Objectif................................................................................................... 15
II. Backlog de sprint.................................................................................... 16
1. Répartition en tache avec estimation ...........................................................................16
2. Scénario de test ............................................................................................................21
3. Burndown chart............................................................................................................22
III. Analyse.................................................................................................... 23
1. Diagramme de cas d’utilisation détaillé.......................................................................23
2. Diagrammes d’activités................................................................................................24
IV. Conception............................................................................................. 26

2. 2
1. Diagramme de séquence objet .....................................................................................26
2. Diagramme de classe conception.................................................................................29
V . Réalisation.............................................................................................. 30
1. Outils, bibliothèques et technologies utilisés...............................................................30
2. Captures d’écran de l’application ................................................................................31
VIII. Conclusion.............................................................................................. 34
Chapitre 3
I. Objectif.................................................................................................... 36
II. Backlog sprint......................................................................................... 37
1. Répartition des taches avec estimation : ......................................................................37
2. Scénarios de test...........................................................................................................39
3. Burndown chart...........................................................................................................41
III. Analyse.................................................................................................... 42
1. Diagramme de cas d’utilisation détaillé.......................................................................42
2. Diagramme de séquence système : ..............................................................................43
IV. Conception.............................................................................................. 44
V. Réalisation............................................................................................... 46
2. Captures d’écran de l’application réalisée: ..................................................................48
VI. Conclusion............................................................................................... 52
Chapitre 4
I. Objectif................................................................................................... 54
II. Backlog de sprint.................................................................................... 55
1. Répartition en tache avec estimation ...........................................................................55
2. Scénario de test ............................................................................................................59
3. Burndown chart............................................................................................................60
4. Procès verbale des réunions :.......................................................................................61
IV. Analyse.................................................................................................... 62

3. 3
1. Diagramme de cas d’utilisation raffiné........................................................................62
2. Diagrammes d’activités................................................................................................63
IV. Conception............................................................................................. 64
1. Diagramme de séquence objet .....................................................................................64
2. Diagramme de classe ...................................................................................................68
3. Diagramme de classe conception.................................................................................69
4. Diagramme de composants..........................................................................................70
V. Réalisation............................................................................................... 71
1. Outils, bibliothèques et technologies utilisés...............................................................71
2. Captures d’écran de l’application ................................................................................72
VIII. Conclusion.............................................................................................. 75

4. 4
Table de figures
figure 1: Acteur « Visiteur ».............................................................................................................1
figure 2: Acteur « Client »................................................................................................................1
figure 3: Acteur « Administrateur » .................................................................................................1
figure 4: Acteur « Restaurateur » .....................................................................................................1
figure 5: Diagramme de cas d’utilisation générale...........................................................................4
figure 6: Diagramme de classe d’analyse globale............................................................................5
figure 7: Architecture logique ..........................................................................................................6
figure 8: Architecture physique........................................................................................................6
figure 9: Product backlog ...............................................................................................................10
figure 10: Maquette de l’authentification .....................................................................................11
figure 11: Maquette de l’espace de gestion des commentaires.....................................................11
figure 12: Maquette de l’espace de gestion des comptes..............................................................12
figure 13: Maquette de la section pour la modification des informations du compte admin .......12
figure 14: Backlog sprint_Java.....................................................................................................20
figure 15: Burn Down chart 3D....................................................................................................22
figure 16: Left To do chart............................................................................................................22
figure 17: Diagramme de cas d’utilisation détaillé.......................................................................23
figure 18: Diagramme d’activité « effectuer une réservation »....................................................24
figure 19: Diagramme d’activité « authentification»....................................................................25
figure 20: Diagramme de séquence objet «authentification» .......................................................26
figure 21: Diagramme de séquence objet «réservation»...............................................................27
figure 22: Diagramme de séquence objet «authentification restaurateur» ...................................27
figure 23: Diagramme de séquence objet «authentification administrateur»...............................28
figure 24: Diagramme de classe conception.................................................................................29
figure 25: Interface « inscription » ..............................................................................................31
figure 26: Interface « authentification » .......................................................................................31
figure 27: Interface restaurateur « contacter un restaurateur ».....................................................32
figure 28: Interface restaurateur « gérer restaurant».....................................................................32
figure 29: Interface restaurateur « ajout d’une offre»...................................................................33
figure 30: Interface restaurateur « gérer les réservations»............................................................33
figure 31: Backlog sprint_Mobile.................................................................................................39

5. 5
figure 32: Burndown chart............................................................................................................41
figure 33: Cas d'utilisation............................................................................................................42
figure 34: Diagramme de séquence d’Authentification................................................................43
figure 35: Diagramme de séquence objet de consulter les offres .................................................44
figure 36: Diagramme séquence objet Inscription........................................................................45
figure 37: La bibliothèque de J2ME.............................................................................................46
figure 38: Transfert et récupération des données entre le serveur et l'émulateur .........................47
figure 39: Authentification ...........................................................................................................48
figure 40: Inscription Client..........................................................................................................48
figure 41: Inscription Restaurateur ...............................................................................................49
figure 42: Consulter Bons plans, Consulter offre, Envoyer SMS, Consulter Restaurant.............49
figure 43: Interface « Modifier Compte Client »..........................................................................50
figure 44: Interface « Accueil, Réserver, Noter un restaurant, Maps »........................................50
figure 45: Interfaces « Accueil, statistique, modification de compte restaurateur, réclamation »51
figure 46: Consulter informations d’un restaurant et afficher les informations ...........................51
figure 47: Backlog sprint_Web.....................................................................................................58
figure 48: Burn Down chart..........................................................................................................60
figure 49: Diagramme de cas d’utilisation détaillé.......................................................................63
figure 50: Diagramme d’activité « s’authentifier» .......................................................................63
figure 51: Diagramme de séquence objet «authentification» .......................................................64
figure 52: Diagramme de séquence objet «réservation»...............................................................65
figure 53: Diagramme de séquence objet «Consulter offre»........................................................66
figure 54: Diagramme de séquence objet «Chercher offre».........................................................67
figure 55: Diagramme de classe ...................................................................................................68
figure 56: Diagramme de classe conception.................................................................................69
figure 57: Interface « vue globale_gestion restaurateur » ...........................................................72
figure 58: Interface « acceuil_gestion restaurateur »....................................................................73
figure 59: Interface « consulter fiche restaurateur».....................................................................73
figure 60: Interface « Consulter les restaurants_frontOffice» .....................................................74
figure 61: Interface « Consulter une offre_backOffice»..............................................................74

6. 6
Introduction générale
Réserver en quelques clics dans le restaurant de votre choix ! En effet, en indiquant les informations
concernant la date à laquelle vous souhaitez réserver, le nombre de personnes et l’heure.
C’est dans ce cadre s’inscrit ce présent travail ayant pour but de développer une application java,
mobile et web permettant de Retrouvez grâce à notre guide une sélection des
meilleurs restaurants de Tunisie.

7. 7
Chapitre 1

8. 1
I. Etude de contexte
1. Identification des acteurs :
figure 1: Acteur « Visiteur »
L’acteur « visiteur » est un utilisateur simple qui pourra simplement consulter la liste des
restaurants et des bons plans
figure 2: Acteur « Client »
L’acteur « client » après l’inscription et l’authentification il bénéficiera des droits liés à cet
acteur
figure 3: Acteur « Administrateur »
L’acteur « administrateur » bénéficiera des droits de la gestion des comptes des clients et des
commentaires
figure 4: Acteur « Restaurateur »
L’acteur « restaurateur » bénéficiera de la gestion d’un ou plusieurs restaurants, de leur menu
et des réservations

9. 2
2. Identification des besoins fonctionnels
L’application doit assurer les fonctionnalités suivantes aux visiteurs
● Consulter la liste des restaurants
● Consulter les menus des différents restaurants
● Rechercher un restaurant selon des critères personnalisés
● Simuler le coût (en fonction du nombre de personnes, nature des mets, …)
● Trouver les bons plans
L’application doit assurer à l’utilisateur de visualiser les bon plan ajouté par les
restaurateur
● Accéder aux services de Restaurant Tunisie via une application mobile
L’application doit assurer les fonctionnalités suivantes aux clients
● Commenter et noter un restaurant
● Effectuer une réservation
● Modifier les informations du compte
L’application doit assurer les fonctionnalités suivantes aux administrateurs
● Gérer les comptes des clients
L’application doit assurer la gestion des comptes des clients (l’ajout, suppression,
consultation, recherche).
● Gérer les commentaires
L’application doit assurer la gestion des commentaires des clients (la suppression,
consultation).
L’application doit assurer les fonctionnalités suivantes aux restaurateurs :
● Gérer la réservation

10. 3
L’application doit assurer au restaurateur la gestion des réservations des clients (la
validation et l’annulation).
● Gérer restaurants
L’application doit assurer au restaurateur la gestion d’un ou plusieurs restaurants
(l’ajout, la suppression, la consultation et la modification).
● Gérer les bons plans
● L’application doit assurer au restaurateur la gestion de ses bons plans (l’ajout, la
suppression et la consultation).
3. Identification des besoins non fonctionnels :
 La compatibilité : L’application doit être compatible avec la majorité des navigateurs
(Web), des systèmes d’exploitation (mobile et Desktop).
 L’ergonomie des interfaces homme-machine (IHM) :
Il s’agit d’une application (Web, Mobile, Desktop), elle doit présenter des interfaces
utilisateurs conviviales bien structurées du point de vue contenu informationnel.
 La sécurité :
Les droits d’accès au système doivent être bien attribués aux différents partenaires, afin
d’assurer la sécurité des données. De plus, le système doit disposer d’un mécanisme
d’authentification limitant l’accès aux utilisateurs.
 Les contraintes techniques :
Le système doit être développé en Open Source. En outre, il doit être portable et fonctionnel
sur plusieurs systèmes d’exploitation.

11. 4
II. Analyse globale
1. Diagramme de cas d’utilisation globale :
figure 5: Diagramme de cas d’utilisation générale

12. 5
2. Diagramme de classe d’analyse globale :
figure 6: Diagramme de classe d’analyse globale
1..1
Gérer
1..*
1..1
Gérer
0..*
1..1
Gérer
0..*
0..*
1..*
effectuer
0..*
1..*
Gérer
1..*
Attribuer
0..*
1..*
Attribuer
0..*
1..1
Avoir
0..*
1..*
Gérer
0..*
1..1
Gérer
0..*
1..1
Gérer
0..*
1..1
0..*
1..1
Appartient
1..1
Client
-
-
-
-
-
-
-
-
id_client
nom
prenom
adresse
email
tel
login
pass
: int
: String
: String
: String
: String
: int
: String
: String
Restaurant
-
-
-
-
-
-
-
-
-
-
id
nom
adresse
email
description
tel
site
heure_ouverture
heure_fermeture
image
: int
: String
: String
: String
: String
: int
: int
: int
: int
: blob
Menu
-
-
-
-
-
-
id
titre
info
prix
photo
etat
: int
: String
: String
: double
: String
: String
Restaurateur
-
-
-
-
-
-
-
-
id
nom
prenom
adresse
email
tel
login
pass
: int
: String
: String
: String
: String
: int
: String
: String
Commentaire
-
-
-
id
text
etat
: int
: String
: String
Note
-
-
id
note
: int
: int
Reservation
-
-
-
-
-
id
date_res
nbr_perso
commentaire
etat
: int
: Date
: int
: String
: String
Administrateur
-
-
-
-
-
-
id
nom
prenom
email
login
pass
: int
: String
: String
: String
: String
: String
Offre
-
-
-
-
-
id
description
prix
date_debut
date_fin
: int
: String
: double
: Date
: Date

13. 6
III – Modélisation de l’architecture
logique et physique de l’application :
1. Modélisation de l’architecture logique :
figure 7: Architecture logique
2. Modélisation de l’architecture physique :
figure 8: Architecture physique

14. 7
IV – Elaboration du product backlog

15. 8
ID
Feature User story Priorité
V1
V1.1 consulter
restaurant
V1.1.1 En tant que visiteur je veux consulter
la liste des restaurants
40
V1.1.2 En tant que visiteur je veux consulter
les menus des restaurants
45
1.2.1 S’inscrire En tant que visiteur je veux m’inscrire afin
de passer des réservations
HOW : sur une plateforme web
70
V1.2.2
S’inscrire
En tant que visiteur je veux m’inscrire afin
de passer des réservations
HOW : sur une plateforme mobile
72
V1.3
Rechercher un
restaurant
En tant que visiteur je veux rechercher un
restaurant
50
V1.4 Simuler le
cout de la réservation
En tant que visiteur je veux Simuler le cout
de la réservation
32
V1.5 Trouver
les bons plans
En tant que visiteur je veux consulter les
bons plans
30
C1
C1.1 Noter un
restaurant
En tant que client je veux noter un restaurant
25
C1.2
Commenter un
restaurant
En tant que client je veux commenter un
restaurant
25
C1.3 Effectuer
une réservation
En tant que client je veux effectuer une
réservation
60
C1.4 Modifier En tant que client je veux modifier les

16. 9
info compte informations de mon compte 55
A1
A1.1 Gérer les
comptes des clients
A1.1.1 En tant qu’administrateur je veux
consulter un compte
90
A1.1.2 En tant qu’administrateur je veux
supprimer un compte
85
A1.2 Gérer les
commentaires
A1.2.1 En tant qu’administrateur je veux
consulter les commentaires
80
A1.2.2 En tant qu’administrateur je veux
supprimer les commentaires
85
A1.2.3 En tant qu’administrateur je veux
valider des commentaires
75
R1
R1.1 S’inscrire En tant que restaurateur je veux m’inscrire
10
R1.2 Gérer
restaurent
R1.2.1 En tant que restaurateur je veux
ajouter un restaurant
25
R1.2.2 En tant que restaurateur je veux
supprimer un restaurant
13
R1.2.3 En tant que restaurateur je veux
modifier un restaurant
16
R1.3 Gérer les
réservations
R1.3.1 En tant que restaurateur je veux
valider les réservations
12
R1.3.2 En tant que restaurateur je veux
annuler les réservations
8
R1.4 Gérer les
bons plans
R1.4.1 En tant que restaurateur je veux
ajouter de bons plans

17. 10
figure 9: Product backlog
7
R1.4.1 En tant que restaurateur je veux
modifier les bons plans
9
R1.4.1 En tant que restaurateur je veux
supprimer les bons plans
5

18. 11
V – Elaboration des maquettes
 A traves cette interface l’administrateur pourra s’authentifier
figure 10: Maquette de l’authentification
 A travers cette interface l’administrateur aura accès à touts les commentaires non
confirmés
figure 11: Maquette de l’espace de gestion des commentaires

19. 12
 A travers cette interface l’administrateur pour gérer les comptes des clients, les
consulter ou les supprimer
figure 12: Maquette de l’espace de gestion des comptes
 A travers cette interface l’utilisateur gère les informations de son propre compte
figure 13: Maquette de la section pour la modification des informations du compte admin

20. 13
VIII - ConclusionCON
Bon
On espère que notre projet facilitera la tache pour ceux qui n’ont pas une bonne
visualisation sur touts les restaurants de la Tunisie
Après ce sprint (0) on va aborder le sprint (1) qui consiste à réaliser le module de
l’administration avec la technologie Java.
En procédant par étape et en y mettant la détermination, la persévérance et l’effort, le
parcours du succès est possible.

21. 14
Chapitre 2

22. 15
I. Objectif
L’objectif de ce sprint et de concevoir et réaliser une application desktop du projet « Resto
Tunisie » en utilisant le langage de programmation Java, on trouvera sur cette plateforme toutes les
fonctionnalités de ce projet.
Ce sprint est mis en œuvre surtout pour faciliter l’administration.

23. 16
II. Backlog de sprint
1. Répartition en tache avec estimation

24. 17
ID
Feature User story Tache Technique Estimation Affectation
V1
S’inscrire En tant que visiteur je
veux m’inscrire
Elaborer interface d’inscription 12 LINA
Méthode Insert dans la table
client
Méthode Insert dans la table
restaurateur
codage
Test unitaire et test de sécurité
C1
C1.1 consulter
restaurant
C1.1.1 En tant que
client je veux
consulter la liste des
restaurants
Elaborer interface
pour la consultation 2
FEDI
Méthode de consultation de la
liste des restaurants (DAO)
2
codage 5
Test
C1.2 Trouver un
restaurant
C1.2.1 En tant que
client je veux
rechercher un
restaurant
Codage et création de la
méthode de recherche d’un
restaurant par son nom
4
FEDI
Elaborer interface
pour la recherche
test
C1.2.2 En tant que
client je veux
consulter les bons
plans
Elaboration de l’interface pour la
consultation des bons plans
3
codage
test
C1.3 Noter un
restaurant
En tant que client je
veux noter un
restaurant
Elaborer l’interface pour noter
un restaurant (noter avec les
étoiles)
2
FEDI
Méthode «insert » de la note
dans la base de donnée
test
C1.4 Commenter
un restaurant
En tant que client je
veux commenter un
restaurant
Elaborer l’interface pour
l’insertion des commentaires 4
FEDI
Méthode insert des
commentaires dans la base
Codage
Test
C1.5 Effectuer
une réservation
En tant que client je
veux effectuer une
réservation
Elaborer l’interface pour
l’insertion des réservations 3
FEDI
Méthode insert des réservations
dans la base
Codage
Test
C1.6 Modifier
info compte
En tant que client je
veux modifier les
informations de mon
compte
Elaborer l’interface pour la
modification des informations 3
FEDI
Méthode update des
informations du client
Codage (contrôle saisie,
programmer les boutons)
Test

25. 18
A1
A1.1 Gérer les
comptes des
clients
A1.1.1 En tant
qu’administrateur je
veux consulter un
compte
Elaborer l’interface pour la
consultation d’un compte client 4
AHMED
codage
test
A1.1.2 En tant
qu’administrateur je
veux supprimer un
compte
Elaborer l’interface pour la
suppression d’un compte client
4 AHMED
codage
Méthode delete du compte
client
test
A1.1.2 En tant
qu’administrateur je
veux rechercher un
compte
Elaborer l’interface pour la
recherche d’un client
4 AHMED
Méthode select du compte client
codage
test
A1.2 Gérer les
commentaires
A1.2.1 En tant
qu’administrateur je
veux consulter les
commentaires
Elaborer l’interface pour la
consultation des commentaires 3
MILKA
Codage
Méthode select des
commentaires
test
A1.2.2 En tant
qu’administrateur je
veux supprimer les
commentaires
Elaborer l’interface pour la
suppression des commentaires
4
MILKA
Méthode delete des
commentaires
codage
test
A1.2.3 En tant
qu’administrateur je
veux valider des
commentaires
envoyer mail lors de
la validation
Elaborer l’interface pour la
validation des commentaires 9
MILKA
Méthode delete des
commentaires non validés
Codage et intégration du mail
test
A1.3 Gérer les
restaurateurs
A1.3.1 En tant
qu’administrateur je
veux consulter la liste
des restaurateurs
Elaborer l’interface pour la
consultation des restaurateurs
4 AYMEN
Méthode select de touts les
restaurateurs
codage
test
A1.3.2 En tant
qu’administrateur je
veux supprimer un
restaurateur
Elaborer l’interface pour la
suppression des restaurateurs
5 AYMEN
Méthode delete d’un
restaurateur
codage
test
A1.3.3 En tant
qu’administrateur je
veux modifier les
informations d’un
Elaborer l’interface pour la
modification des restaurateurs
4 AYMEN
Méthode update d’un
restaurateur

26. 19
restaurateur codage
test
A1.3.4 En tant
qu’administrateur je
veux contacter un
restaurateur
Elaborer l’interface pour l’envoi
d’un mail
3 AYMEN
Intégration des librairies mail
Codage et contrôle saisie
test
A1.4 Gérer les
administrateurs
A1.4.1 En tant
qu’administrateur je
veux ajouter un
administrateur
Elaborer l’interface de l’ajout
d’un administrateur
7 MLIKA
Méthode insert d’un
administrateur
codage
test
A1.4.1 En tant
qu’administrateur je
veux modifier le mot
de passe du compte
Elaborer l’interface pour la
modification du mot de passe
codage
Contrôle saisie et intégration du
système « code de vérification »
R1
R1.2 Gérer
restaurant
R1.2.1 En tant que
restaurateur je
visualiser les
statistiques
Elaborer l’interface pour les
statistiques 3
WAJDI
Intégration du code
test
R1.2.2 En tant que
restaurateur je veux
ajouter un restaurant
Elaborer l’interface pour l’ajout
d’un restaurant 4
HENI
Méthode insert d’un restaurant
codage
test
R1.2.3 En tant que
restaurateur je veux
supprimer un
restaurant
Elaborer l’interface pour la
suppression d’un restaurant 3
HENI
Méthode delete d’un restaurant
codage
test
R1.2.4 En tant que
restaurateur je veux
modifier un
restaurant
Elaborer l’interface pour la
modification d’un restaurant 3
HENI
Méthode update d’un restaurant
codage
test
R1.2.5 En tant que
restaurateur je veux
consulter la liste des
restaurants
Elaborer l’interface pour la
consultation des restaurants
3 HENI
Méthode select des restaurants
restaurant
codage
test
R1.2.6 En tant que
restaurateur je veux
contacter un
administrateur
Elaborer l’interface pour l’envoi
d’un mail
HENI
Intégration des librairies mail
Codage et contrôle saisie
R1.2.7 En tant que
restaurateur je veux
rechercher un
restaurant
Elaborer l’interface pour la
recherche des restaurants
4 HENI
Méthode SelectByNom des
restaurants

27. 20
figure 14: Backlog sprint_Java
codage
test
R1.3 Gérer les
réservations
R1.3.1 En tant que
restaurateur je veux
valider les
réservations
Elaborer l’interface pour la
validation des réservations 5
WAJDI
codage
Test
R1.3.2 En tant que
restaurateur je veux
annuler les
réservations
Interface pour l’annulation
3
WAJDI
codage
test
R1.4 Gérer les
bons plans
(offres)
R1.4.1 En tant que
restaurateur je veux
ajouter de bons plans
Elaborer l’interface pour l’ajout
des offres 4
WAJDI
Méthode insert des offres
codage
test
R1.4.1 En tant que
restaurateur je veux
modifier les bons
plans
Elaborer l’interface pour la
modification des offres
4 WAJDI
Méthode update des offres
codage
test
R1.4.1 En tant que
restaurateur je veux
supprimer les bons
plans
Elaborer l’interface pour la
suppression des offres
3 WAJDI
Méthode delete des offres
codage
test
Stoty Less
Création de la base de données 1 MLIKA
Authentification Interface authentification 13 LINA
Codage
test
Diagramme de séquence objets 2 LINA
Intégration du jasper report pour l’export de la liste des restaurants 1 HENI
Intégration du jasper report pour l’export de la liste des restaurateurs 1 AYMEN
Intégration du jasper report pour l’export de la liste des clients qui ont réservé 2 WAJDI
Diagramme de classe de conception 2 HENI
Burndownchart 2 HENI
Diagramme d’activité 2 FEDI
Elaboration backlog sprint1 (Répartition +estimation) 5 AYMEN
Elaboration Rapport sprint 1 2 AYMEN
Documentation 14 Tous les
membres du
groupe

28. 21
2. Scénario de test
 Scénario 1 :
Étant donné un client BBB qui possède un login et un mot de passe
Quand il saisie de fausses informations lors de l’authentification
Alors l’authentification est refusé et le message « login ou mot de passe incorrect » est
envoyé
 Scénario 2 :
Étant donné un administrateur A et un administrateur B
Quand l’administrateur A veut ajouter un administrateur avec le même login que B
Alors l’ajout est refusé et le message « login déjà utilisé »
 Scénario 3 :
Pour le user story « en tant qu’administrateur je veux modifier mon mot de passe» des
critères de test que j'ai identifiés sont :
-On ne peut modifier le mot de passe que si on introduit le code de vérification qui a été
envoyé à la boite mail de l’administrateur
 Scénario 4 :
Pour le user story « en tant que client je veux effectuer une réservation» des critères de test
que j'ai identifiés sont :
-On ne peut réserver que si un restaurant est sélectionné

29. 22
3. Burndown chart
figure 15: Burn Down chart 3D
Le graphe ci-dessus représente le burndown chart, qui représente le pourcentage du travail effectué
par rapport au nombre de jour du travail.
figure 16: Left To do chart
Le graphe ci-dessus représente les taches qui nous restent à réaliser en termes d’heures par rapport
aux jours totaux.

30. 23
III. Analyse
1. Diagramme de cas d’utilisation détaillé
figure 17: Diagramme de cas d’utilisation détaillé

31. 24
Nous présentant ci-dessus le diagramme de cas d’utilisation détaillé avec les nouvelles
fonctionnalités ajoutés au niveau du sprint 1, pour ce sprint on a 3 acteurs : client, restaurateur,
administrateur. Pour ce sprint on a pris la décision d’éliminer le visiteur puisque chaque
fonctionnalité nécessite une authentification
2. Diagrammes d’activités
figure 18: Diagramme d’activité « effectuer une réservation »
Nous présentant ci-dessus le diagramme d’activité pour la fonctionnalité « «réserver » qui est
lié à l’acteur « client » qui après avoir sélectionné un restaurant et le remplissage du formulaire il
pourra effectuer une réservation.

32. 25
figure 19: Diagramme d’activité « authentification»
Nous présentant ci-dessus le diagramme d’activité pour la fonctionnalité «s’authentifier», à
premier temps l’acteur choisis le type d’authentification et on saisie le login et le mot de passe et
après une vérification il accède à l’application.

33. 26
IV – Conception
1. Diagramme de séquence objet
figure 20: Diagramme de séquence objet «authentification»
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité de l’authentification client
-Après le remplissage des données (login et mot de passe)
-Les données seront traitées et interroger la base de donnée
-Si les données saisies sont similaires dans la base de données il le redirige vers l’interface
client

34. 27
figure 21: Diagramme de séquence objet «réservation»
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité de la réservation.
-Après avoir sélectionné un restaurant
-On rempli le formulaire de la réservation et on insère dans la base de données
figure 22: Diagramme de séquence objet «authentification restaurateur»

35. 28
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité de l’authentification du restaurateur
-Après le remplissage des données (login et mot de passe)
-Les données seront traitées et interroger la base de donnée
-Si les données saisies sont similaires dans la base de données il le redirige vers l’interface du
restaurateur
figure 23: Diagramme de séquence objet «authentification administrateur»
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité de l’authentification administrateur
-Après le remplissage des données (login et mot de passe)
-Les données seront traitées et interroger la base de donnée
-Si les données saisies sont similaires dans la base de données il le redirige vers l’interface
administrateur

36. 29
2. Diagramme de classe conception
figure 24: Diagramme de classe conception
Nous présentons ci-dessous le diagramme de classe de conception qui contient tout les entités
de notre projet
1..1
Gérer
1..*
1..1
Gérer
0..*
1..1
Gérer
0..*
0..*
1..*
effectuer
0..*
1..*
Gérer
1..*
Attribuer
0..*
1..*
Attribuer
0..*
1..1
Avoir
0..*
1..*
Gérer
0..*
1..1
Gérer
0..*
1..1
Gérer
0..*
1..1
0..*
1..1
Appartient
1..1
Client
-
-
-
-
-
-
-
-
id_client
nom
prenom
adresse
email
tel
login
pass
: int
: String
: String
: String
: String
: int
: String
: String
Restaurant
-
-
-
-
-
-
-
-
-
-
id
nom
adresse
email
description
tel
site
heure_ouverture
heure_fermeture
image
: int
: String
: String
: String
: String
: int
: int
: int
: int
: blob
Menu
-
-
-
-
-
-
id
titre
info
prix
photo
etat
: int
: String
: String
: double
: String
: String
Restaurateur
-
-
-
-
-
-
-
-
id
nom
prenom
adresse
email
tel
login
pass
: int
: String
: String
: String
: String
: int
: String
: String
Commentaire
-
-
-
id
text
etat
: int
: String
: String
Note
-
-
id
note
: int
: int
Reservation
-
-
-
-
-
id
date_res
nbr_perso
commentaire
etat
: int
: Date
: int
: String
: String
Administrateur
-
-
-
-
-
-
id
nom
prenom
email
login
pass
: int
: String
: String
: String
: String
: String
Offre
-
-
-
-
-
id
description
prix
date_debut
date_fin
: int
: String
: double
: Date
: Date

37. 30
V – Réalisation
1. Outils, bibliothèques et technologies utilisés
La mis en œuvre de ce projet nécessite l’utilisation de différentes outils et technologies parmi
les quels on cite :
Outils :
 PowerAMC : pour la création des différents diagrammes
 Netbeans 7.4
 WAMPSERVER : pour la création de la base de données
 Balsamiq Mockups : pour la création des maquettes
 Sprinttometer : pour la réalisation du burndownchart
Technologies :
 JAVA
 SQL
Bibliothèques :
 Java SWING : pour la création des interfaces graphiques
 Jfreechart : pour la réalisation des statistiques
 Les librairies pour l’envoi des mails

38. 31
2. Captures d’écran de l’application
Nous présenterons ci-dessous quelques captures écran de notre application
figure 25: Interface « inscription »
figure 26: Interface « authentification »

39. 32
figure 27: Interface restaurateur « contacter un restaurateur »
figure 28: Interface restaurateur « gérer restaurant»

40. 33
figure 29: Interface restaurateur « ajout d’une offre»
figure 30: Interface restaurateur « gérer les réservations»

41. 34
VIII - ConclusionCON
Bon
On espère que notre projet facilitera la tache pour l’administration du projet et avoir une
bonne visibilité pour chaque acteur sur toutes ces fonctionnalités.
Ce sprint nous a permis de découvrir de nouveaux outils et d’acquérir de nouvelles
connaissances.
Après ce sprint (1) on va aborder le sprint (2) qui consiste à réaliser une application mobile de
notre projet.
En procédant par étape et en y mettant la détermination, la persévérance et l’effort, le
parcours du succès est possible.

42. 35
Chapitre 3

43. 36
I. Objectif
Le nombre de terminaux ‘légers’ (PDA, téléphone…) dépasse largement celui des ordinateurs
personnels (400 millions d’ordinateurs personnels dans le monde en 2002, un milliard de terminaux
‘légers’ en 2003). 30 à 50 % de ces terminaux ont une connectivité possible à l’Internet.
Les Smartphones par conséquence ont devenu un outil de communication incontournable. Sprint 2
consiste à il à élaborer une application mobile en J2Me. A base de cahier des charges qui vise à
implémenter des divers services au visiteur tels que : Consulter la liste des restaurants , consulter
les menus des différents restaurants, commenter et noter un restaurant, rechercher un restaurant
selon des critères personnalisés, effectuer une réservation, réserver et simuler le coût d’une
réservation, trouver les bons plans…
Cette applications mobile est applicable dans le cadre de permettre au visiteur de réservez dans les
meilleurs restaurants aux meilleurs prix.
Nous ne permettons pas seulement aux restaurateurs d’être visibles sur notre site… Nous leur
fournissons aussi des outils experts pour les aider dans la gestion de leur établissement : cahier de
réservation électronique, optimisation du taux de remplissage, gestion de la relation client…

44. 37
II. Backlog sprint
1. Répartition des taches avec estimation :
Id
story
Story Tache Estimation rôle
1.1 En Tant que
Client je
souhaite
consulter les
restaurants via
mobile
Codage « consulter un restaurant » 2H Aymen
création de la base de données 1H Mlika
Tester le travail du Fedi 1H Aymen
1.2 En Tant que
Client je
souhaite
consulter le
Mapp de
restaurant via
mobile
Intégration de la localisation map 2H Fedi,Aymen
implémenter l’interface
correspondante
1H Fedi
Tester le travail d’Aymen et Wajdi 1H Fedi
2.1 En Tant que
client je
souhaite
m’inscrire via
mobile
Méthode ajout client(inscription) 2H Lina
Tester le travail du Heni 1H 30 min Lina
2.2 En tant que
restaurateur je
souhaite
m’inscrire via
mobile
Méthode ajout
restaurateur(inscription)
1H Lina
Tester le travail de Heni 1H Lina

45. 38
3.1 En Tant que
restaurateur je
souhaite gérer
mon compte
via mobile
création de package restaurateur 20 min Mlika
création de midlet pour la gestion
des comptes
4H Mlika
Tester le travail d’Ahmed et Wajdi 50 min Mlika
3.2
En tant que
client je
souhaite écrire
un
commentaire
via mobile
Crud pour la consultation des
commentaires
2H Aymen
3.3 En tant que
restaurateur je
souhaite
envoyer et
modifier
compte
restaurateur
via mobile
Crud Réclamation 2H Ahmed
codage 2H 30 min Ahmed
Intégrer la visualisation d’une vidéo 1H Ahmed
Intégrer l’appel d’un numéro 1H 30 MIN Ahmed
tester le travail de Mlika 1H Ahmed
3.4 En tant que
client je
souhaite noter
un restaurant
via mobile
codage 30 min Heni
Crud « noter restaurant » 3H Heni
Crud « réservation » 2H Heni
tester le travail de Lina 50 min Heni
création package statistique 30 min Fedi

46. 39
3.5 En tant que
restaurateur je
souhaite
consulter les
statistiques
concernant
mon restaurant
via mobile
Codage et intégration du module
statistique
2H Fedi
Tester le travail du Aymen et Wajdi 1H Fedi
3.6 En tant que
Client je
souhaite
consulter les
offres,
attribuer note
et ajouter
commentaire
via mobile
Codage « consultation des offres » 1H 30 min Wajdi
Intégration du module d’envoi
d’un sms au restaurateur
1H Wajdi
Ajouter commentaire à l’offre 2H Wajdi
chercher les offres 2H Wajdi
Tester le travail d’Ahmed et Heni 1H Wajdi
figure 31: Backlog sprint_Mobile
2. Scénarios de test
Le story ‘S'authentifier ‘
Authentification acceptée
Étant donné 2 champs "login" et "password», Quand le client Mohamed s'authentifie en donnant
son login ="****" et mot de passe="****" Alors il peut accéder à l'accueil du site de Resto Tunisie
via mobile.
Authentification refusée

47. 40
Étant donné 2 champs "login" et "password", Quand un client ‘foulen’ introduit un login ="*** " et
password ="***" différent à celui qui existe dans la base il sera averti via mobile Alors l'accès est
refusé et le message "Login et Mot de passe incorrect" est lui retourner à l’interface de
authentification.
La Story :'Modification des informations du client'
Modification acceptée
Étant donné les champs "login" et "passwd" du formulaire,un client ‘foulen’ Quand il introduit via
mobile son login="" et son passwd="", Alors les nouvelles modifications qui l’à introduit dans le
formulaire seront enregistrés et un message de confirmation de modification des informations
personnelles sera affiché.
Modification refusée
Étant donné les champs "login" et "password" du formulaire, un client ‘foulen’ Quand il introduit
via mobile login="",password="", Alors les nouvelles modifications seront refusés et un message
d'erreur de modification des informations personnelles sera affiché "Vous devez remplir tous les
champs".
 La Story :'Effectuer une réservation via mobile'
Réservation effectuée
Étant donné les champs "login" et "password" du formulaire, un client ‘foulen’ Quand il introduit
via mobile le jour de la réservation après avoir désigné le restaurant Alors la réservation sera
enregistré.
Réservation refusée
Étant donné les champs "login" et "password" du formulaire, Quand un client ‘foulen’ ne
sélectionne pas un restaurant.

48. 41
3. Burndown chart
figure 32: Burndown chart
Le graphe ci-dessus représente le burndown chart, qui représente le pourcentage du travail effectué
par rapport au nombre de jour du travail.

49. 42
III. Analyse
1. Diagramme de cas d’utilisation détaillé
figure 33: Cas d'utilisation
Client
Consulter les
restaurants
Consulter les offres
Commenter un
Restauarant
Commenter les offres
Noter un Restaurant
Effectuer une
Reservation
envoyer un SMS
envoyer une
Reclamation
Consulter les rapports
des Statistiques
Modifier Compte Client
S'inscrire
Authentification
Localiser les
Restaurants
gérer restaurant
Restaurateur
supprimer
restaurant
modifier restaurantConsulter restaurant
Ajouter restauarnt
Modifier Compte restaurateur

50. 43
Nous présentant ci-dessus le diagramme de cas d’utilisation détaillé avec les fonctionnalités du
sprint 2, au niveau de ce sprint on a 2 acteurs : client, restaurateur.
2. Diagramme de séquence système :
figure 34: Diagramme de séquence d’Authentification
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité de l’authentification du restaurateur
-Après le remplissage des données (login et mot de passe)
-Les données seront traitées et interroger la base de donnée
-Si les données saisies sont similaires dans la base de données il le redirige vers l’interface
restaurateur
sd:Authenti fi cati on
4:Affi cher un m essage d'erreur
3 : Affi cher l 'i nterface
2: véri fi cati on
1:sai si r(l ogi n , m dp)()
restaurateur
<<system e>>
Restaurant
[ l ogi n et m dp correcte ]
[l ogi n ou m dp i ncorrecte ]
al t
4:Affi cher un m essage d'erreur
3 : Affi cher l 'i nterface
2: véri fi cati on
1:sai si r(l ogi n , m dp)()

51. 44
IV. Conception
1. Diagramme de Séquence Objet
figure 35: Diagramme de séquence objet de consulter les offres
DS_Consulter offre
10: Afficher(Msg)
9: AfficherOffre()
8: ReponseSelect()
6: ReponseSelect()
7: Select()
5: Select()
4: Chercher()
3: Cliquer"Suivant"
2: Formulaire afficher()
1: Demande formulaire()
Client
<<boundary>>
:UI_interface offre
<<entity>>
:offre
<<control>>
:consulter_offre
<<entity>>
:Restaurant
[offre=true]
else
alt
10: Afficher(Msg)
9: AfficherOffre()
8: ReponseSelect()
6: ReponseSelect()
7: Select()
5: Select()
4: Chercher()
3: Cliquer"Suivant"
2: Formulaire afficher()
1: Demande formulaire()

52. 45
figure 36: Diagramme séquence objet Inscription
sd:Ajouter Restaurant
verification
message d'erreur
ajouter à la liste des restaurateur
saisir code
envoyer un SMS pour confirmer
Remplire formulaire
formulaire afficher
Demande d'afficher formulaire Ajouter
Restaurateur()
Restaurateur
Systeme
[code=correcte]
[code=incorrecte]
alt
ref
sd:Authentification()
verification
message d'erreur
ajouter à la liste des restaurateur
saisir code
envoyer un SMS pour confirmer
Remplire formulaire
formulaire afficher
Demande d'afficher formulaire Ajouter
Restaurateur()

53. 46
V. Réalisation
1. Outils, bibliothèques et technologies utilisés:
La mis en œuvre de ce projet nécessite l’utilisation de différentes outils et technologies parmi les
quels on cite :
Outils :
 PowerAMC : pour la création des différents diagrammes
 Netbeans 7.4
 Wamp : pour la création de la base de données
 BalsamiqMockups : pour la création des maquettes
 Sprinttometer : pour la réalisation du burndownchart
Technologies :
 J2ME
 MySQL
Bibliothèques :
figure 37: La bibliothèque de J2ME

54. 47
L’API lcdui est chargée de gérer l’ensemble des contrôles graphiques proposés par ce profile.
Quant à la gestion des événements, elle suit le modèle des listeners du J2SE avec un
CommandListener appelé en cas d’activation d’un contrôle. Donc io et rms, eux, fournissent les
routines nécessaires aux entrées/s orties réseau et à la prise en charge d’une zone physique de
stockage.
Les Midlets
Les Midlets sont l'élément principal d'une application Java embarquée. Pour bien saisir leur mode
de fonctionnement, il suffit de prendre comme analogie les Applets ou les Servlets. Le cycle de vie
d’une Applet est géré par un conteneur, en l’occurrence le Navigateur Web, dont le rôle est
d’interagir avec celle-ci sous la forme de méthodes de notifications prédéfinies
Une servlet possè de les mêmes caractéristiques qu’une Applet excepté le fait que le contenu r est
un moteur de servlet (Tomcat, WebSphere, WebLogic, …).
Quant aux Midlets, ils représentent le pendant des Applets et des Servlets pour J2ME avec comme
conteneur votre téléphone mobile ou votre assistant personnel. Ainsi, en cas de mise à jour d’une
application embarquée, un simple téléchargement de code Midlet est nécessaire à partir d’un
quelconque serveur. De cette manière, un programme développé pour un profile donné est en
mesure de s’exécuter sur tous les périphériques correspondant à cette famille.
C’est aussi une manière de découpler le socle technique des applicatifs puisque le seul lien
Existant entre les logiciels embarqués et le terminal est l’API J2ME.
wireless toolkit 2.5:
figure 38: Transfert et récupération des données entre le serveur et l'émulateur

55. 48
2. Captures d’écran de l’application réalisée:
figure 39: Authentification
figure 40: Inscription Client

56. 49
figure 41: Inscription Restaurateur
figure 42: Consulter Bons plans, Consulter offre, Envoyer SMS, Consulter Restaurant

57. 50
figure 43: Interface « Modifier Compte Client »
figure 44: Interface « Accueil, Réserver, Noter un restaurant, Maps »

58. 51
figure 45: Interfaces « Accueil, statistique, modification de compte restaurateur, réclamation »
figure 46: Consulter informations d’un restaurant et afficher les informations

59. 52
VI. Conclusion
On a développé une application mobile qui permettra au client de choisir son restaurant, consulter
les offres et les bons plans et réserver et d'avoir plusieurs autres services reliés à notre application
« Resto Tunisie », J2ME est une bonne sélection parmi plusieurs technologies pour les applications
mobiles. Après ce sprint (2) on va aborder par la suite le sprint (3) qui consiste à réaliser une
application web de notre projet.

60. 53
Chapitre 4

61. 54
I. Objectif
L’objectif de ce sprint et de concevoir et réaliser une application Web du projet « Resto
Tunisie » en utilisant plusieurs technologies comme le langage PHP et un framework PHP, Html,
javascript.
Pour cela on doit concevoir deux plateformes : Le front-Office (l’interface d’interaction pour
les visiteurs et les clients) et le Back-Office (Pour la gestion et l’administration)

62. 55
II. Backlog de sprint
1. Répartition en tache avec estimation

63. 56
ID
Feature User story Tache Technique Estimation Affectation
V1
S’inscrire En tant que visiteur
je veux m’inscrire et
m’authentifier
Via Web
Intégration du FOS user Bundle 40 LINA
Test de sécurité 30
C1
C1.1 consulter
restaurant
C1.1.1 En tant que
Visiteur je veux
consulter la liste des
restaurants
Via Web
Elaborer interface
pour la consultation 20
FEDI
Méthode de consultation de la
liste des restaurants
20
Test 20
C1.3 Noter un
restaurant
En tant que client je
veux noter un
restaurant via Web
Elaborer l’interface pour noter
un restaurant 20
Ahmed
Méthode «insert » de la note
dans la base de donnée
20
Test 20
C1.4 Commenter
un restaurant
En tant que client je
veux commenter un
restaurant via Web
Elaborer l’interface pour
l’insertion des commentaires 40
FEDI
Méthode insert des
commentaires dans la base
30
Test 20
C1.5 Effectuer
une réservation
En tant que client je
veux effectuer une
réservation via Web
Elaborer l’interface pour
l’insertion des réservations 30
FEDI
Méthode insert des réservations
dans la base
20
Test 30
A1
A1.1 Gérer les
comptes des
clients
A1.1.1 En tant
qu’administrateur je
veux consulter un
compte via Web
Elaborer l’interface pour la
consultation d’un compte client 40
AHMED
Test 30
A1.1.2 En tant
qu’administrateur je
veux supprimer un
compte via Web
Elaborer l’interface pour la
suppression d’un compte client
40 AHMED
Méthode delete du compte
client
30
Test 20
A1.1.2 En tant
qu’administrateur je
veux rechercher un
compte via Web
Elaborer l’interface pour la
recherche d’un client
40 AHMED
Méthode select du compte
client
40
Test 20
A1.2 Gérer les
commentaires
A1.2.1 En tant
qu’administrateur je
veux consulter les
commentaires Via
Web
Elaborer l’interface pour la
consultation des commentaires 30
MILKA
Méthode select des
commentaires
40
Test 20

64. 57
A1.2.2 En tant
qu’administrateur je
veux supprimer les
commentaires via
Web
Elaborer l’interface pour la
suppression des commentaires
MILKA
Méthode delete des
commentaires
40
Test 20
A1.2.3 En tant
qu’administrateur je
veux valider des
commentaires
envoyer mail lors de
la validation via Web
Elaborer l’interface pour la
validation des commentaires 50
MILKA
Méthode delete des
commentaires non validés
30
Codage et intégration du mail 30
Test 20
A1.3 Gérer les
restaurateurs
A1.3.1 En tant
qu’administrateur je
veux consulter la liste
des restaurateurs
Via Web
Elaborer l’interface pour la
consultation des restaurateurs
40 AYMEN
Méthode select de touts les
restaurateurs
40
Test 30
A1.3.2 En tant
qu’administrateur je
veux supprimer un
restaurateur
Via web
Elaborer l’interface pour la
suppression des restaurateurs
40 AYMEN
Méthode delete d’un
restaurateur
30
Test 20
A1.3.3 En tant
qu’administrateur je
veux modifier les
informations d’un
restaurateur
Via Web
Elaborer l’interface pour la
modification des restaurateurs
40 AYMEN
Méthode update d’un
restaurateur
20
Test 20
A1.3.4 En tant
qu’administrateur je
veux ajouter un
restaurateur
Via web
Elaborer l’interface pour l’ajout
des restaurateurs
30 AYMEN
Méthode insert d’un
restaurateur
30
Codage et contrôle saisie 20
Test 20
R1
R1.2 Gérer
restaurant R1.2.2 En tant que
restaurateur je veux
ajouter un restaurant
Via web
Elaborer l’interface pour l’ajout
d’un restaurant 40
HENI
Méthode insert d’un restaurant 30
Test de travaille 20
R1.2.3 En tant que
restaurateur je veux
supprimer un
restaurant
Via web
Elaborer l’interface pour la
suppression d’un restaurant
30 HENI
Méthode delete d’un restaurant 20
Test 20
R1.2.4 En tant que
restaurateur je veux
modifier un
restaurant
Elaborer l’interface pour la
modification d’un restaurant
30 HENI
Méthode update d’un
restaurant
20

65. 58
figure 47: Backlog sprint_Web
Via web Test 20
R1.2.5 En tant que
restaurateur je veux
consulter la liste des
restaurants
Via web
Elaborer l’interface pour la
consultation des restaurants
30 HENI
Méthode select des restaurants
restaurant
30
Test 20
R1.2.6 En tant que
restaurateur je veux
contacter un
administrateur
Via web
Elaborer l’interface pour l’envoi
d’un mail
20 HENI
Intégration des librairies mail 20
Codage et contrôle saisie 20
R1.2.7 En tant que
restaurateur je veux
rechercher un
restaurant
Via web
Elaborer l’interface pour la
recherche des restaurants
40 HENI
Méthode Select ByNom des
restaurants
30
Test 20
R1.3 Gérer les
réservations
R1.3.1 En tant que
restaurateur je veux
valider les
réservations
Via web
Elaborer l’interface pour la
validation des réservations
30 WAJDI
Test 30
R1.3.2 En tant que
restaurateur je veux
annuler les
réservations
Via web
Interface pour annuler les
résérvations
20 WAJDI
Test 20
R1.4 Gérer les
bons plans
(offres)
R1.4.1 En tant que
restaurateur je veux
ajouter de bons plans
Via web
Elaborer l’interface pour l’ajout
des offres
30 WAJDI
Méthode insert des offres 30
Test 2
R1.4.1 En tant que
restaurateur je veux
modifier les bons
plans
Via web
Elaborer l’interface pour la
modification des offres
30 WAJDI
Méthode update des offres 30
Test 20
R1.4.1 En tant que
restaurateur je veux
supprimer les bons
plans
Via web
Elaborer l’interface pour la
suppression des offres
30 WAJDI
Méthode delete des offres 20
Test 20

66. 59
2. Scénario de test
 Scénario 1 :
Étant donné un client Amin qui possède un login et un mot de passe amin56
Quand il saisie de fausses informations lors de l’authentification
Alors l’authentification est refusé et le message « login ou mot de passe incorrect » est
envoyé
Sinon il sera redirigé vers la page d’accueil.
 Scénario 2 :
Étant donné un administrateur Ahmed et un administrateur Samir
Quand l’administrateur Ahmed veut ajouter un administrateur avec le même login que B
Alors l’ajout est refusé et le message « login déjà utilisé »
Sinon l’administrateur sera ajouté et un message de confirmation sera ajouté
 Scénario 3 :
Pour le user story « en tant qu’administrateur je veux modifier mon mot de passe» des
critères de test que j'ai identifiés sont :
-On ne peut modifier le mot de passe que si on introduit le code de vérification qui a été
envoyé à la boite mail de l’administrateur
 Scénario 4 :
Pour le user story « en tant que client je veux effectuer une réservation» des critères de test
que j'ai identifiés sont :
-On ne peut réserver que si un restaurant est sélectionné

67. 60
3. Burndown chart
figure 48: Burn Down chart
Le graphe ci-dessus représente le burndown chart, qui représente les taches qui reste à faire en
termes de temps.

68. 61
4. Procès verbale des réunions :
PV 1
Date du jour : 21/04/2014 à 18h à Esprit Salle C35
Participants : toute l’équipe
Discussion :
- La répartition des taches entre les membres de groupe
-Créer un plan pour améliorer les processus de travail
-Les difficultés rencontrées : Le manque de communication et de l’esprit d'assistance
mutuelle entre les membres d'équipe.
-Qu'aurions-nous pu changer ? Mieux communiquer.
PV 2
Date du jour : 25/04/2014 à 18h à Esprit Salle C35
Participants : toute l’équipe
Discussion :
- Choisir un template front-office et un template back-office
-Résoudre quelques difficultés rencontrées au niveau de l’intégration du template

69. 62
IV. Analyse
1. Diagramme de cas d’utilisation raffiné

70. 63
figure 49: Diagramme de cas d’utilisation détaillé
Nous présentant ci-dessus le diagramme de cas d’utilisation détaillé, pour ce sprint on a 4
acteurs : visiteur, client, restaurateur, administrateur.
2. Diagrammes d’activités
figure 50: Diagramme d’activité « s’authentifier»
Nous présentant ci-dessus le diagramme d’activité pour la fonctionnalité « s’authentifier » qui
est lié à tout les acteurs qui après avoir saisi le login et le pass il sera redirigé vers l’interface
demandé selon les privilèges.

71. 64
IV – Conception
1. Diagramme de séquence objet
figure 51: Diagramme de séquence objet «authentification»
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité de l’authentification client
-Après le remplissage des données (login et mot de passe)
-Les données seront traitées et interroger la base de donnée
-Si les données saisies sont similaires dans la base de données il le redirige vers l’interface
client

72. 65
figure 52: Diagramme de séquence objet «réservation»
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité de la réservation.
-Après avoir sélectionné un restaurant
-On rempli le formulaire de la réservation et on insère dans la base de données

73. 66
figure 53: Diagramme de séquence objet «Consulter offre»
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité « «consultation d’une offre »
-Le client demande la liste de toutes les offres
-Après il choisie une offre d’un restaurant bien données
-Si la requête est aboutie la fiche de l’offre concernée sera affichée
DS_Consulter offre
10: Afficher(Msg)
9: AfficherOffre()
8: ReponseSelect()
6: ReponseSelect()
7: Select()
5: Select()
4: Chercher()
3: Cliquer"Suivant"
2: Formulaire afficher()
1: Demande formulaire()
Client
<<boundary>>
:UI_interface offre
<<entity>>
:offre
<<control>>
:consulter_offre
<<entity>>
:Restaurant
[offre=true]
else
alt
10: Afficher(Msg)
9: AfficherOffre()
8: ReponseSelect()
6: ReponseSelect()
7: Select()
5: Select()
4: Chercher()
3: Cliquer"Suivant"
2: Formulaire afficher()
1: Demande formulaire()

74. 67
figure 54: Diagramme de séquence objet «Chercher offre»
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité pour la recherche d’une offre
-Au niveau de l’interface pour la consultation des offres, le client recherche le restaurant
-Après l’interaction avec les entités la liste des offres du restaurant concerné sera affichée
DS_Chercher offre
2: Cliquer"Chercher" 3: Chercher()
7: Afficher(Msg)
6: AfficherOffre()
5: Select()
4: Select()
1: SaiasieNomRestau()
Client
<<boundary>>
:UI_interface offre
<<entity>>
:offre
<<control>>
:consulter_offre
<<entity>>
:Restaurant
[offre=true]
else
alt
2: Cliquer"Chercher" 3: Chercher()
7: Afficher(Msg)
6: AfficherOffre()
5: Select()
4: Select()
1: SaiasieNomRestau()

75. 68
2. Diagramme de classe
figure 55: Diagramme de classe
Nous présentons ci-dessous le diagramme de classe qui contient toutes les entités de notre
projet
1..1
Gérer
1..*
1..1
Gérer
0..*
1..1
Gérer
0..*
0..*
1..*
effectuer
0..*
1..*
Gérer
1..*
Attribuer
0..*
1..*
Attribuer
0..*
1..1
Avoir
0..*
1..*
Gérer
0..*
1..1
Gérer
0..*
1..1
Gérer
0..*
1..1
0..*
1..1
Appartient
1..1
Client
-
-
-
-
-
-
-
-
id_client
nom
prenom
adresse
email
tel
login
pass
: int
: String
: String
: String
: String
: int
: String
: String
Restaurant
-
-
-
-
-
-
-
-
-
-
id
nom
adresse
email
description
tel
site
heure_ouverture
heure_fermeture
image
: int
: String
: String
: String
: String
: int
: int
: int
: int
: blob
Menu
-
-
-
-
-
-
id
titre
info
prix
photo
etat
: int
: String
: String
: double
: String
: String
Restaurateur
-
-
-
-
-
-
-
-
id
nom
prenom
adresse
email
tel
login
pass
: int
: String
: String
: String
: String
: int
: String
: String
Commentaire
-
-
-
id
text
etat
: int
: String
: String
Note
-
-
id
note
: int
: int
Reservation
-
-
-
-
-
id
date_res
nbr_perso
commentaire
etat
: int
: Date
: int
: String
: String
Administrateur
-
-
-
-
-
-
id
nom
prenom
email
login
pass
: int
: String
: String
: String
: String
: String
Offre
-
-
-
-
-
id
description
prix
date_debut
date_fin
: int
: String
: double
: Date
: Date

76. 69
3. Diagramme de classe conception
figure 56: Diagramme de classe conception
0..*
1..1
<<boundary>>
:IU_Interface_offre
+
+
+
+
Demander formulaire ()
Cliquer "suivant" ()
Afficher offre ()
Afficher ("Msg") ()
<<control>>
:ConsulterOffre
+
+
Chercher ()
ReponseSelect ()
<<entity>>
:Offre
-
-
-
-
-
-
id
description
prix
date_debut
date_fin
commantaire
: int
: String
: double
: Date
: Date
: String
+ Select ()
<<entity>>
:Resturant
-
-
-
-
-
-
-
-
-
-
id
nom
addresse
email
description
tel
site
heure_ouverture
heure_fermeture
image
: int
: String
: String
: String
: String
: int
: String
: String
: String
: byte
+
+
Select ()
Ajouter ()
<<entity>>
:Administrateur
-
-
-
-
-
-
id
nom
prenom
email
login
password
: int
: String
: String
: String
: String
: String
<<entity>>
:Client
-
-
-
-
-
-
-
-
id_client
nom
prenom
adresse
email
tel
login
pass
: int
: String
: String
: String
: String
: int
: String
: String
<<entity>>
:commantaire
-
-
-
id
text
etat
: int
: String
: String
<<entity>>
:note
-
-
id
note
: int
: int
<<entity>>
:Reservation
-
-
-
-
-
id
date_reservation
nbr_pers
commantaire
etat
: int
: String
: int
: String
: String
<<entity>>
:Restaurateur
-
-
-
-
-
-
-
-
id
nom
prenom
addresse
email
tel
login
pass
: int
: String
: String
: String
: String
: int
: String
: String
1..*
0..*
<<boundary>>
:IU_Interface_Restaurateur
+
+
+
+
Demander formulaire ()
Formulaire Afficher ()
Remplire formulaire ()
Afficher ("Msg") ()
<<control>>
:GérerRestaurant
+ Enregistrer ()
0..*
1..*
0..*
0..*
1..*
1..*
0..*
<<boundary>>
:IU_Interface_Administrateur
<<control>>
:GérerClient
+ Enregistrer ()
1..*
0..*
1..*
0..*
0..*
<<boundary>>
:IU_Interface_CLient
<<control>>
:ConsulterSite
+ Chercher ()
<<control>>
:GéreRestaurant
0..*
<<entity>>
:Menu
-
-
-
-
-
id
titre
description
prix
etat
: int
: int
: String
: double
: int
+
+
Select ()
Ajouter ()
...
0..*

77. 70
Nous présentons ci-dessous le diagramme de classe de conception qui contient les méthodes
et les contrôleurs de notre projet
4. Diagramme de composants
Gerer profil
Gerer restaurant
Client
Gerer client
Gerer reservation
Gerer offre
Restaurateur
Admin
Interface gestion
profil
Interface gestion
offre
Interface gestion
restaurant
Interface gestion
reservation
Interface gestion
client
gerer commentaire
Interface gestion
commentaire

78. 71
V – Réalisation
1. Outils, bibliothèques et technologies utilisés
La mis en œuvre de ce projet nécessite l’utilisation de différentes outils et technologies parmi
les quels on cite :
Outils :
 PowerAMC : pour la création des différents diagrammes
 Netbeans 8
 Framework Symfony
 WAMPSERVER : pour la création de la base de données
 Balsamiq Mockups : pour la création des maquettes
 Sprinttometer : pour la réalisation du burndownchart
Technologies :
 PHP
 SQL
 HTML
 JAVASCRIPT
Bibliothèques :
 FOS user Bundle : pour la gestion des droits d’accès
 Ob/highcharts-bundle : pour la réalisation des statistiques

79. 72
2. Captures d’écran de l’application
Nous présenterons ci-dessous quelques captures écran de notre application
figure 57: Interface « vue globale_gestion restaurateur »

80. 73
figure 58: Interface « acceuil_gestion restaurateur »
figure 59: Interface « consulter fiche restaurateur»

81. 74
figure 60: Interface « Consulter les restaurants_frontOffice»
figure 61: Interface « Consulter une offre_backOffice»

82. 75
VIII - ConclusionCON
Bon
Notre projet facilitera la tache pour la consultation et toutes les fonctionnalités sur notre
portail Web et d’avoir une bonne visibilité pour chaque acteur sur les fonctionnalités qui lui ont été
permise.
Ce sprint nous a permis de découvrir de nouveaux outils et d’acquérir de nouvelles
connaissances.

83. 76
Conclusion générale
C'est le temps de laisser notre empreinte dans ce marché dont le but d'un gain d'or en tant qu’ingénieur
en premier plan et d'avoir de nouvelles connaissances en deuxième plan.
En procédant par étape et en y mettant la détermination, la persévérance et l’effort, le
parcours du succès est possible.
Ce projet nous a permis de découvrir de nouveaux outils et d’acquérir de nouvelles
connaissances.