Sommaire
Chapitre 1
I. Etude de contexte ....................................................................................
2
1. Diagramme de séquence objet .....................................................................................26
2...
3
1. Diagramme de cas d’utilisation raffiné........................................................................62
2. D...
4
Table de figures
figure 1: Acteur « Visiteur ».............................................................................
5
figure 32: Burndown chart..................................................................................................
6
Introduction générale
Réserver en quelques clics dans le restaurant de votre choix ! En effet, en indiquant les informat...
7
Chapitre 1
1
I. Etude de contexte
1. Identification des acteurs :
figure 1: Acteur « Visiteur »
L’acteur « visiteur » est un utilisat...
2
2. Identification des besoins fonctionnels
L’application doit assurer les fonctionnalités suivantes aux visiteurs
● Cons...
3
L’application doit assurer au restaurateur la gestion des réservations des clients (la
validation et l’annulation).
● Gé...
4
II. Analyse globale
1. Diagramme de cas d’utilisation globale :
figure 5: Diagramme de cas d’utilisation générale
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....
6
III – Modélisation de l’architecture
logique et physique de l’application :
1. Modélisation de l’architecture logique :
...
7
IV – Elaboration du product backlog
8
ID
Feature User story Priorité
V1
V1.1 consulter
restaurant
V1.1.1 En tant que visiteur je veux consulter
la liste des r...
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...
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 restau...
11
V – Elaboration des maquettes
 A traves cette interface l’administrateur pourra s’authentifier
figure 10: Maquette de ...
12
 A travers cette interface l’administrateur pour gérer les comptes des clients, les
consulter ou les supprimer
figure ...
13
VIII - ConclusionCON
Bon
On espère que notre projet facilitera la tache pour ceux qui n’ont pas une bonne
visualisation...
14
Chapitre 2
15
I. Objectif
L’objectif de ce sprint et de concevoir et réaliser une application desktop du projet « Resto
Tunisie » en ...
16
II. Backlog de sprint
1. Répartition en tache avec estimation
17
ID
Feature User story Tache Technique Estimation Affectation
V1
S’inscrire En tant que visiteur je
veux m’inscrire
Elab...
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...
19
restaurateur codage
test
A1.3.4 En tant
qu’administrateur je
veux contacter un
restaurateur
Elaborer l’interface pour l...
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 ...
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...
22
3. Burndown chart
figure 15: Burn Down chart 3D
Le graphe ci-dessus représente le burndown chart, qui représente le pou...
23
III. Analyse
1. Diagramme de cas d’utilisation détaillé
figure 17: Diagramme de cas d’utilisation détaillé
24
Nous présentant ci-dessus le diagramme de cas d’utilisation détaillé avec les nouvelles
fonctionnalités ajoutés au nive...
25
figure 19: Diagramme d’activité « authentification»
Nous présentant ci-dessus le diagramme d’activité pour la fonctionn...
26
IV – Conception
1. Diagramme de séquence objet
figure 20: Diagramme de séquence objet «authentification»
Le diagramme c...
27
figure 21: Diagramme de séquence objet «réservation»
Le diagramme ci-dessus présente l’enchainement des actions et l’in...
28
Le diagramme ci-dessus présente l’enchainement des actions et l’interaction avec les objets de
la fonctionnalité de l’a...
29
2. Diagramme de classe conception
figure 24: Diagramme de classe conception
Nous présentons ci-dessous le diagramme de ...
30
V – Réalisation
1. Outils, bibliothèques et technologies utilisés
La mis en œuvre de ce projet nécessite l’utilisation ...
31
2. Captures d’écran de l’application
Nous présenterons ci-dessous quelques captures écran de notre application
figure 2...
32
figure 27: Interface restaurateur « contacter un restaurateur »
figure 28: Interface restaurateur « gérer restaurant»
33
figure 29: Interface restaurateur « ajout d’une offre»
figure 30: Interface restaurateur « gérer les réservations»
34
VIII - ConclusionCON
Bon
On espère que notre projet facilitera la tache pour l’administration du projet et avoir une
bo...
35
Chapitre 3
36
I. Objectif
Le nombre de terminaux ‘légers’ (PDA, téléphone…) dépasse largement celui des ordinateurs
personnels (400 m...
37
II. Backlog sprint
1. Répartition des taches avec estimation :
Id
story
Story Tache Estimation rôle
1.1 En Tant que
Cli...
38
3.1 En Tant que
restaurateur je
souhaite gérer
mon compte
via mobile
création de package restaurateur 20 min Mlika
créa...
39
3.5 En tant que
restaurateur je
souhaite
consulter les
statistiques
concernant
mon restaurant
via mobile
Codage et inté...
40
Étant donné 2 champs "login" et "password", Quand un client ‘foulen’ introduit un login ="*** " et
password ="***" diff...
41
3. Burndown chart
figure 32: Burndown chart
Le graphe ci-dessus représente le burndown chart, qui représente le pourcen...
42
III. Analyse
1. Diagramme de cas d’utilisation détaillé
figure 33: Cas d'utilisation
Client
Consulter les
restaurants
C...
43
Nous présentant ci-dessus le diagramme de cas d’utilisation détaillé avec les fonctionnalités du
sprint 2, au niveau de...
44
IV. Conception
1. Diagramme de Séquence Objet
figure 35: Diagramme de séquence objet de consulter les offres
DS_Consult...
45
figure 36: Diagramme séquence objet Inscription
sd:Ajouter Restaurant
verification
message d'erreur
ajouter à la liste ...
46
V. Réalisation
1. Outils, bibliothèques et technologies utilisés:
La mis en œuvre de ce projet nécessite l’utilisation ...
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...
48
2. Captures d’écran de l’application réalisée:
figure 39: Authentification
figure 40: Inscription Client
49
figure 41: Inscription Restaurateur
figure 42: Consulter Bons plans, Consulter offre, Envoyer SMS, Consulter Restaurant
50
figure 43: Interface « Modifier Compte Client »
figure 44: Interface « Accueil, Réserver, Noter un restaurant, Maps »
51
figure 45: Interfaces « Accueil, statistique, modification de compte restaurateur, réclamation »
figure 46: Consulter i...
52
VI. Conclusion
On a développé une application mobile qui permettra au client de choisir son restaurant, consulter
les o...
53
Chapitre 4
54
I. Objectif
L’objectif de ce sprint et de concevoir et réaliser une application Web du projet « Resto
Tunisie » en util...
55
II. Backlog de sprint
1. Répartition en tache avec estimation
56
ID
Feature User story Tache Technique Estimation Affectation
V1
S’inscrire En tant que visiteur
je veux m’inscrire et
m...
57
A1.2.2 En tant
qu’administrateur je
veux supprimer les
commentaires via
Web
Elaborer l’interface pour la
suppression de...
58
figure 47: Backlog sprint_Web
Via web Test 20
R1.2.5 En tant que
restaurateur je veux
consulter la liste des
restaurant...
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 s...
60
3. Burndown chart
figure 48: Burn Down chart
Le graphe ci-dessus représente le burndown chart, qui représente les tache...
61
4. Procès verbale des réunions :
PV 1
Date du jour : 21/04/2014 à 18h à Esprit Salle C35
Participants : toute l’équipe
...
62
IV. Analyse
1. Diagramme de cas d’utilisation raffiné
63
figure 49: Diagramme de cas d’utilisation détaillé
Nous présentant ci-dessus le diagramme de cas d’utilisation détaillé...
64
IV – Conception
1. Diagramme de séquence objet
figure 51: Diagramme de séquence objet «authentification»
Le diagramme c...
65
figure 52: Diagramme de séquence objet «réservation»
Le diagramme ci-dessus présente l’enchainement des actions et l’in...
66
figure 53: Diagramme de séquence objet «Consulter offre»
Le diagramme ci-dessus présente l’enchainement des actions et ...
67
figure 54: Diagramme de séquence objet «Chercher offre»
Le diagramme ci-dessus présente l’enchainement des actions et l...
68
2. Diagramme de classe
figure 55: Diagramme de classe
Nous présentons ci-dessous le diagramme de classe qui contient to...
69
3. Diagramme de classe conception
figure 56: Diagramme de classe conception
0..*
1..1
<<boundary>>
:IU_Interface_offre
...
70
Nous présentons ci-dessous le diagramme de classe de conception qui contient les méthodes
et les contrôleurs de notre p...
71
V – Réalisation
1. Outils, bibliothèques et technologies utilisés
La mis en œuvre de ce projet nécessite l’utilisation ...
72
2. Captures d’écran de l’application
Nous présenterons ci-dessous quelques captures écran de notre application
figure 5...
73
figure 58: Interface « acceuil_gestion restaurateur »
figure 59: Interface « consulter fiche restaurateur»
74
figure 60: Interface « Consulter les restaurants_frontOffice»
figure 61: Interface « Consulter une offre_backOffice»
75
VIII - ConclusionCON
Bon
Notre projet facilitera la tache pour la consultation et toutes les fonctionnalités sur notre
...
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é...
Prochain SlideShare
Chargement dans…5
×

Rapport de sprint finale (All Project part)

804 vues

Publié le

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

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
804
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
18
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Rapport de sprint finale (All Project part)

  1. 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. 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. 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. 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. 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. 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. 7 Chapitre 1
  8. 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. 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. 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. 11. 4 II. Analyse globale 1. Diagramme de cas d’utilisation globale : figure 5: Diagramme de cas d’utilisation générale
  12. 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. 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. 14. 7 IV – Elaboration du product backlog
  15. 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. 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. 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. 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. 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. 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. 21. 14 Chapitre 2
  22. 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. 23. 16 II. Backlog de sprint 1. Répartition en tache avec estimation
  24. 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. 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. 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. 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. 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. 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. 30. 23 III. Analyse 1. Diagramme de cas d’utilisation détaillé figure 17: Diagramme de cas d’utilisation détaillé
  31. 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. 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. 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. 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. 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. 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. 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. 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. 39. 32 figure 27: Interface restaurateur « contacter un restaurateur » figure 28: Interface restaurateur « gérer restaurant»
  40. 40. 33 figure 29: Interface restaurateur « ajout d’une offre» figure 30: Interface restaurateur « gérer les réservations»
  41. 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. 42. 35 Chapitre 3
  43. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 55. 48 2. Captures d’écran de l’application réalisée: figure 39: Authentification figure 40: Inscription Client
  56. 56. 49 figure 41: Inscription Restaurateur figure 42: Consulter Bons plans, Consulter offre, Envoyer SMS, Consulter Restaurant
  57. 57. 50 figure 43: Interface « Modifier Compte Client » figure 44: Interface « Accueil, Réserver, Noter un restaurant, Maps »
  58. 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. 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. 60. 53 Chapitre 4
  61. 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. 62. 55 II. Backlog de sprint 1. Répartition en tache avec estimation
  63. 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. 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. 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. 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. 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. 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. 69. 62 IV. Analyse 1. Diagramme de cas d’utilisation raffiné
  70. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 80. 73 figure 58: Interface « acceuil_gestion restaurateur » figure 59: Interface « consulter fiche restaurateur»
  81. 81. 74 figure 60: Interface « Consulter les restaurants_frontOffice» figure 61: Interface « Consulter une offre_backOffice»
  82. 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. 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.

×