Faculté des Sciences Economiques et de Gestion
Département d’Informatique Appliquée à la Gestion
MEMOIRE DE STAGE
POUR L’O...
MOBI RESTO Slim Hammami
2
DÉDICACES
A Dieu source de toute connaissance
A ma chère mère, pour son amour, son soutien moral...
MOBI RESTO Slim Hammami
3
REMERCIEMENTS
Louanges tout d’abord à ALLAH qui est l’origine de toute réussite dans notre
vie.
...
MOBI RESTO Slim Hammami
4
AVANT- PROPOS
Cette étude entre dans le cadre de la préparation d'un mémoire de stage de fin
d'é...
MOBI RESTO Slim Hammami
5
Table des matières
Introduction ...................................................................
MOBI RESTO Slim Hammami
6
4.3.2. Construction du schéma logique des données optimisé : ......................................
MOBI RESTO Slim Hammami
7
Liste des figures
Figure 1- 1 : Diagramme de collaboration métier..................................
MOBI RESTO Slim Hammami
8
Liste des tableaux
Tableau1-1 : Echangesd’informationentre lesacteursexternesetle systèmede gest...
MOBI RESTO Slim Hammami
9
Introduction
e l'âge de la pierre à nos jours, l'esprit perfectionniste de l'homme n'a
cessé de ...
MOBI RESTO Slim Hammami
10
 Le troisième chapitre nommé « Analyse » traite l’analyse et la
conception avec la constructio...
MOBI RESTO Slim Hammami
11
Chapitre 1 :
MODELISATION DU METIER
MOBI RESTO Slim Hammami
12
1. Modélisation du métier :
1 .1 : Définition de la mission :
La concurrence entre les restaura...
MOBI RESTO Slim Hammami
13
*produit simple : produits intégrés au stock et pouvant être vendus
immédiatement ou utilisés p...
MOBI RESTO Slim Hammami
14
-Tous les répondeurs au questionnaire, sont tenté disposer d’une application
qui facilite et ac...
MOBI RESTO Slim Hammami
15
*La gestion de son compte personnel.
*Le choix et la réservation d’une table.
1.1.2 : Objectifs...
MOBI RESTO Slim Hammami
16
Légende :
Numéro Désignation
1 Consulter les produits disponibles
2 Passer les commandes client...
MOBI RESTO Slim Hammami
17
La description des processus métier apportent une vision du métier réelle, et
constitue un exce...
MOBI RESTO Slim Hammami
18
 Processus métier «Passer commande client »
Le serveur a la possibilité de passer une commande...
MOBI RESTO Slim Hammami
19
processus métier. Aussi nous avons critiqué l’existant pour dégager les
anomalies du système ac...
MOBI RESTO Slim Hammami
20
Chapitre 2:
CAPTURE DES BESOINS
MOBI RESTO Slim Hammami
21
2. Capture des besoins :
Introduction :
Nous essayons de présenter dans ce chapitre, d’établir ...
MOBI RESTO Slim Hammami
22
2.2. Modèle de contexte du système informatisé
Légende :
1. Ajouter / modifier / consulter un c...
MOBI RESTO Slim Hammami
23
13.Consulter / transférer les points de fidélité.
14.Changer l’état d’une commande de l’état « ...
MOBI RESTO Slim Hammami
24
 Objectif : Ce CU est utilisé pour se connecter à l’application, et pour
assurer la sécurité d...
MOBI RESTO Slim Hammami
25
3-Le gérant introduit les informations du client (pseudo, nom, prénom, adresse,
profession, num...
MOBI RESTO Slim Hammami
26
Exceptions :
1-Le système affiche « Champ obligatoire à saisir est vide ! » et retourne sur la
...
MOBI RESTO Slim Hammami
27
3-Le système demande au gérant ou au serveur de saisir les informations
nécessaires (numéro de ...
MOBI RESTO Slim Hammami
28
Exceptions :
1-Le système affiche « Champ obligatoire à saisir est vide ! ».
2-Le système affic...
MOBI RESTO Slim Hammami
29
3-Le gérant choisit l’option « Recette ».
4-Le système affiche l’interface correspondante.
5-Le...
MOBI RESTO Slim Hammami
30
Description des scénarios :
 Pré condition : Le gérant est authentifié.
 Post conditions : Un...
MOBI RESTO Slim Hammami
31
4-Si le système n’exécute aucune exception alors il enregistre les modifications.
Supprimer un ...
MOBI RESTO Slim Hammami
32
 Scénarios alternatifs :
Consulter les informations d’un article :
1-Le gérant demande d’accéd...
MOBI RESTO Slim Hammami
33
Afficher stock
Ce CU débute quand le gérant se connecte sur l’application, le processus se
pour...
MOBI RESTO Slim Hammami
34
Description des scénarios :
 Pré condition : Le cuisinier/bar-man est authentifié.
 Post cond...
MOBI RESTO Slim Hammami
35
4-Le serveur introduit les informations du client (pseudo, nom, prénom, adresse,
profession, nu...
MOBI RESTO Slim Hammami
36
 Scénarios alternatifs :
Consulter une commande :
1-Le serveur demande d’accéder à l’interface...
MOBI RESTO Slim Hammami
37
 Scénario nominal :
Consulter les produits
Ce CU débute quand le serveur ou le client se conne...
MOBI RESTO Slim Hammami
38
Cas d’utilisation « Consulter état commande »
Identification :
 Titre : Consulter état command...
MOBI RESTO Slim Hammami
39
2-Le système demande au client de saisir les informations nécessaires (numéro
de table, date de...
MOBI RESTO Slim Hammami
40
4- Le système vérifie s’il y a un champ non rempli, si oui il exécute
l’exception1, il vérifie ...
MOBI RESTO Slim Hammami
41
Chapitre 3:
ANALYSE
MOBI RESTO Slim Hammami
42
3. Analyse :
Introduction
Ce chapitre va nous permettre d’avoir une idée claire sur notre domai...
MOBI RESTO Slim Hammami
43
Figure 3-1 : Diagramme de classes
MOBI RESTO Slim Hammami
44
3.1.3. Dictionnaire des données :
Classe : Personne
Attribut Désignation Méthodes
id_pers Ident...
MOBI RESTO Slim Hammami
45
Classe : Reservation
Attribut Désignation Méthodes
id_res L’identifiant d’une réservation ajout...
MOBI RESTO Slim Hammami
46
Classe : Article
Attribut Désignation Méthodes
id_art L’identifiant d’un article ajouterArticle...
MOBI RESTO Slim Hammami
47
Classe : MatierePremiere
Attribut Désignation Méthodes
id_mat L’identifiant d’une matière
premi...
MOBI RESTO Slim Hammami
48
3.2. Développement du modèle dynamique
3.2.1Construction des diagrammes de séquences
3.2.1.1 Dé...
MOBI RESTO Slim Hammami
49
: Utilisateur: Utilisateur
: Ecran d'authentification: Ecran d'authentification
: Controleur
au...
MOBI RESTO Slim Hammami
50
: Gerant: Gerant : Ecran ajouter réservation: Ecran ajouter réservation : controleur reservatio...
MOBI RESTO Slim Hammami
51
: Gerant: Gerant
: Interface personnels: Interface personnels : Personnel: Personnel
p : Person...
MOBI RESTO Slim Hammami
52
: Gerant: Gerant : Interface statistiques: Interface statistiques : controlleur
statistiques
: ...
MOBI RESTO Slim Hammami
53
Affichage page
d'authentification
Accéder à l'application
Champs pseudo et
mot de passe
S'ident...
MOBI RESTO Slim Hammami
54
S'identifier
[Refusé]
Nouvelle fiche
de réservation
Saisie des
informations
Vérifier existance ...
MOBI RESTO Slim Hammami
55
Chapitre 4:
REALISATION
MOBI RESTO Slim Hammami
56
4. Réalisation :
Introduction
Dans ce chapitre, nous allons illustrer les matériaux, logiciels ...
MOBI RESTO Slim Hammami
57
par IBM) extensible, universel et polyvalent, permettant
potentiellement de créer des projets d...
MOBI RESTO Slim Hammami
58
est un langage de programmation libre4 principalement utilisé
pour produire des pages Web dynam...
MOBI RESTO Slim Hammami
59
Il s’agit d’une architecture client/serveur. Le "client" c’est l’application
Androïd, le "serve...
MOBI RESTO Slim Hammami
60
DEBUT
[Refusé]
Identification
Interface
psersonnels
Sélectionner
personnel
Liste
personnels
Mod...
MOBI RESTO Slim Hammami
61
[Validé]
Identification
[Refusé]
Interface
reservations
Liste
reservations
Sélectionner
reserva...
MOBI RESTO Slim Hammami
62
4.3.2. Construction du schéma logique des données optimisé :
Personne (id_pers, pseudo, mot_pas...
MOBI RESTO Slim Hammami
63
N° Table Attribut Clé
primaire
Clé
étrangère
Type
4 Commande
id_cmd * NUMBER
montant NUMBER
dat...
MOBI RESTO Slim Hammami
64
4.3.4. Présentation des interfaces :
Interface d’authentification
A l’ouverture de notre applic...
MOBI RESTO Slim Hammami
65
- Consulter le menu des articles disponibles et commander un ou plusieurs
articles.
- Réserver ...
MOBI RESTO Slim Hammami
66
Interface « Tableau de bord serveur »
Si l’utilisateur authentifié est un serveur alors, cette ...
MOBI RESTO Slim Hammami
67
Interface « Tableau de bord gérant »
Si l’utilisateur authentifié est un gérant alors, cette in...
MOBI RESTO Slim Hammami
68
Interface « Ajouter une réservation client »
Cette interface permet au gérant d’ajouter une rés...
MOBI RESTO Slim Hammami
69
MOBI RESTO Slim Hammami
70
Conclusion générale
L’objectif de ce projet est de concevoir et de développer une application
A...
MOBI RESTO Slim Hammami
71
Aussi que nous proposons le développement d’une application « Desktop »
comme une version pour ...
MOBI RESTO Slim Hammami
72
Bibliographie
o -‘Courde conception orienté objet des systèmes d’information’ « Mme
Mounira BEN...
MOBI RESTO Slim Hammami
73
Références
2-‘Cour de conception orienté objet des systèmes d’information’ « Mme
Mounira BEN AB...
MOBI RESTO Slim Hammami
74
Annexe
« Mobi-Resto » est un projet d’une application Androïd dansle domaine de la gestion des
...
Prochain SlideShare
Chargement dans…5
×

application android gestion restaurants

7 360 vues

Publié le

rapport d'une application android pour la gestion des restaurants et des salon de thé

Publié dans : Services
6 commentaires
9 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
7 360
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
383
Commentaires
6
J’aime
9
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

application android gestion restaurants

  1. 1. Faculté des Sciences Economiques et de Gestion Département d’Informatique Appliquée à la Gestion MEMOIRE DE STAGE POUR L’OBTENTION DE LA LICENCE FONDAMENTALE EN INFORMATIQUE APPLIQUEE A LA GESTION Développement d’une application Androïd pour la gestion des restaurants et des salons de thé Réalisé par Slim HAMMAMI Encadré par Mr Walid GARGOURI Jury Mr Omar HACHICHA: Président Mme Monia LOULOU: Examinateur Mr Walid GARGOURI: Examinateur Mr Amin DRIRA: Invité Année universitaire 2013/2014
  2. 2. MOBI RESTO Slim Hammami 2 DÉDICACES A Dieu source de toute connaissance A ma chère mère, pour son amour, son soutien moral et son encouragement. A mon cher père, pour son encouragement, son soutien moral et matériel, ses conseils précieux espérant avoir répondu à son souhait, de me voir réussir. A ma chère sœur en témoigne de mon affectation profonde, avec tous mes vœux de les voir réussir dans leur vie. A tous ceux qui me connaissent surtout l’équipe Trio STARS, Association Tunisiennes des Jeunes et tous ceux qui me connaissent, pour leur affectation, leur conseil, leur aide et leur soutien moral, qu’ils n’ont cessé de m’offrir afin de me garantir les conditions favorables à mes études. J’espère qu’ils trouvent dans ce travail l’expression de ma gratitude. Aimablement… Je dédie ce modeste travail… Slim HAMMAMI
  3. 3. MOBI RESTO Slim Hammami 3 REMERCIEMENTS Louanges tout d’abord à ALLAH qui est l’origine de toute réussite dans notre vie. J’adresse l’expression de ma à Monsieur Walid GARGOURI qui m’a confié ce sujet et qui a assumé l’encadrement de mon projet, l’intérêt qu’il a porté à notre travail, sa bienveillance, nos rigueur scientifique, ses discussions fructueuses, ses hautes qualités humaines, ont constitué une aide précieuse et m’ont permis de mener à terme ce travail. Pour la même occasion, j’adresse mes remerciements aux personnels de la boite de développement Oxygène Technologies, particulièrement à Mr Amin DRIRA, ingénieur dans la boite de développement Oxygène Technologies, aux personnels de la Pépinière d’entreprise Sfax Innovation I en particulier Mr Hichem El Ayeb. Je remercie également tous mes enseignants pour leurs efforts qui m’ont guidé et enrichi mes travaux tout au long de mes études universitaires. Enfin, mes remerciements s’adressentaussi à tous ceux qui ont participé, de près ou de loin, à l’élaboration de ce projet de fin d’études et en particulier ma famille et mes amis.
  4. 4. MOBI RESTO Slim Hammami 4 AVANT- PROPOS Cette étude entre dans le cadre de la préparation d'un mémoire de stage de fin d'étude en License Fondamentale en Informatique de Gestion au sein de la Faculté des Sciences Economiques et de Gestion de Sfax pour l'obtention de la Licence. C'est ainsi que j’ai eu l'occasion de passer un stage au sein de la boite de développement « Oxygène Technologies » pour concrétiser mes connaissances théoriques et pratiques par la réalisation d’un cas pratique d’une application Androïd « Gestion Restaurant ».
  5. 5. MOBI RESTO Slim Hammami 5 Table des matières Introduction ................................................................................................................................. 9 1.Modélisation du métier : ...........................................................................................................12 1 .1 : Définition de la mission :...................................................................................................12 1.1.1: Présentation de l’application :......................................................................................14 1.1.2: Objectifs à atteindre :..................................................................................................15 1.2 :Repérage du domaine :......................................................................................................15 1.3 :Modélisation du métier :....................................................................................................16 1.4: Critique de l’existant :........................................................................................................18 Conclusion :.............................................................................................................................18 2.Capture des besoins : ................................................................................................................21 Introduction :...........................................................................................................................21 2.1 : Les acteurs du système informatisé :..................................................................................21 2.2. Modèle de contexte du système informatisé.......................................................................22 2-3. Elaboration du modèle des cas d’utilisation.........................................................................23 2.3.1 Diagramme des cas d’utilisation....................................................................................23 Conclusion...............................................................................................................................40 3.Analyse :...................................................................................................................................42 Introduction.............................................................................................................................42 3.1. Construction du diagramme de classes................................................................................42 3.1.1. Définition....................................................................................................................42 3.1.2. Présentation du diagramme de classes de l’application « Mobi Resto » :.........................42 3.1.3. Dictionnaire des données :...........................................................................................44 3.2. Développement du modèle dynamique...............................................................................48 3.2.1Construction des diagrammes de séquences..................................................................48 3.2.2. Construction des diagrammes d’états...........................................................................53 Conclusion :.............................................................................................................................54 4. Réalisation :.............................................................................................................................56 Introduction.............................................................................................................................56 4.1. Environnement de développement :...................................................................................56 4.2. Conception des classes :....................................................................................................59 4.3. Conception des schémaslogiqueset physique des données :...............................................61 4.3.1. Construction du schéma logique des données brut :......................................................61
  6. 6. MOBI RESTO Slim Hammami 6 4.3.2. Construction du schéma logique des données optimisé : ...............................................62 4.3.3. Construction du schéma physique des données :...........................................................62 4.3.4. Présentation des interfaces :........................................................................................64 Conclusion générale.....................................................................................................................70 Bibliographie ...............................................................................................................................72 Webographie...............................................................................................................................72 Références...................................................................................................................................73 Annexe........................................................................................................................................74
  7. 7. MOBI RESTO Slim Hammami 7 Liste des figures Figure 1- 1 : Diagramme de collaboration métier...........................................................................16 Figure 1-4 : Diagramme des cas d'utilisation métier........................................................................17 Figure 2- 2 : Diagramme de collaborationinformatisé ....................................................................22 Figure 2-3 : Diagramme des cas d'utilisation informatisé ................................................................23 Figure 3-1 : Diagramme de classes.................................................................................................43 Figure 3-2 : Diagramme de séquences pour un scénario d’authentification......................................49 Figure 3-3 : Diagramme de séquences pour un scénario d’ajout d’une réservation...........................50 Figure 3-4 : Diagramme de séquences pour un scénario de modification d’un personnel..................50 Figure 3-5 : Diagramme de séquences pour un scénario de consultation des statistiques .................52 Figure 3-6 : Diagramme d’état-transitions concernant «l’authentification»......................................53 Figure 3-7 : Diagramme d’état-transitions concernant l’ajout d’une réservation client.....................54 Figure 4-1 : Architecture 3-tiers de l’application.............................................................................59 Figure 4-2 : Diagramme d’activités « modifier personnel » .............................................................60 Figure 4-3 : Diagramme d’activités « supprimer réservation ».........................................................61
  8. 8. MOBI RESTO Slim Hammami 8 Liste des tableaux Tableau1-1 : Echangesd’informationentre lesacteursexternesetle systèmede gestionde restaurant...................................................................................................................................16 Tableau 2-1 : Acteurs du système informatisé................................................................................21 Tableau 3-1 : Dictionnaire de données concernant la classe Personne.............................................44 Tableau 3-2 : Dictionnaire de données concernant la classe Personnel ............................................44 Tableau 3-3 : Dictionnaire de données concernant la classe Client ..................................................44 Tableau 3-4 : Dictionnaire de données concernant la classe Reservation.........................................45 Tableau 3-5 : Dictionnaire de données concernant la classe Table...................................................45 Tableau 3-6 : Dictionnaire de données concernant la classe Commande..........................................45 Tableau 3-7 : Dictionnaire de données concernant la classe Article .................................................46 Tableau 3-8 : Dictionnaire de données concernant la classe Composant..........................................46 Tableau 3-9 : Dictionnaire de données concernant la classe LigneCmd............................................46 Tableau 3-10 : Dictionnaire de données concernantla classe Facture..............................................46 Tableau 3-11 : Dictionnaire de données concernantla classe MatierePremiere ...............................47 Tableau 3-12 : Dictionnaire de données concernantla classe Categorie...........................................47 Tableau 4-1 : Ressources matérielles utilisées................................................................................56 Tableau 4-2 : Schéma physique de la base de données (partie 1) ....................................................62 Tableau 4-3 : Schéma physique de la base de données (partie 2) ....................................................63
  9. 9. MOBI RESTO Slim Hammami 9 Introduction e l'âge de la pierre à nos jours, l'esprit perfectionniste de l'homme n'a cessé de lui permettre d'améliorer sa vie quotidienne. Le passage de la mécanique aux domaines d'informatique, d'électronique, d'automatique et de domotique a révolutionné la vie journalière de l'être humain. Les nouvelles technologies de l'information et de communication illustrent ce phénomène. Aujourd'hui, vu l'intérêt croissant de vouloir gagner en temps, de conserver les données, de limiter le nombre d'employés et pas mal d'autres raisons, ont poussé les petites, moyennes et grandes entreprises à chercher des solutions informatiques capables de répondre à leurs besoins. Dans ce cadre s'inscrit notre projet qui consiste à réaliser une application Androïd qui assure le déroulement des différentes fonctionnalités d’un restaurant ou un salon de thé. En effet, l’automatisation des différents processus de la gestion d’un restaurant est devenue un besoin obligatoire pour assurer la bonne gestion. Elle consiste généralement à organiser le passage des commandes aussi que la gestion des personnels, des articles, des réservations etc. Donc, les propriétaires cherchent toujours à assurer une bonne gestion de leur restaurant en rendant cette pénible tâche informatisée : C’est dans ce cadre que cette application présente notre projet de fin d’étude en informatique au sein de la boite de développement « Oxygène Technologies ». Le présent rapport s’articule autour de quatre chapitres à savoir :  Le premier chapitre nommé « Modélisation du Métier » consiste à décrire l’activité de la société et à donner une présentation générale du projet à travers la définition de la mission, le repérage du domaine et le diagramme de cas d’utilisation.  Le deuxième chapitre intitulé « Capture des besoins » décrit une présentation des besoins fonctionnels et techniques envers le système à développer tout en précisant les différents acteurs du futur système, le modèle de contexte et le modèle des cas d’utilisation du système informatisé avec la description textuelle pour chaque cas. D
  10. 10. MOBI RESTO Slim Hammami 10  Le troisième chapitre nommé « Analyse » traite l’analyse et la conception avec la construction du diagramme de classe, la spécification des scénarios de cas d’utilisation à travers la construction des diagrammes de séquence, et des diagrammes d’états.  Le quatrième chapitre « Réalisation » décrit l’implémentation et la réalisation de l’application. Egalement, il définit l’environnement de développement avec la description de l’environnement de réalisation, la conception des classes et la conception des schémas logiques et physique de données.
  11. 11. MOBI RESTO Slim Hammami 11 Chapitre 1 : MODELISATION DU METIER
  12. 12. MOBI RESTO Slim Hammami 12 1. Modélisation du métier : 1 .1 : Définition de la mission : La concurrence entre les restaurants/salon de thé a augmenté d’une façon énorme. Chaqu’un veut offrir à ses clients un service idéal pour garantir leurs retour. Afin d’améliorer les services de ce domaine, on a constaté que l’utilisation des systèmes informatisés est nécessaire pour mieux organiser les processus de travail, ainsi que pour faciliter la gestion des restaurants/salon de thé. Lors d’une statistique établie sur un échantillon de dix restaurants/salons de thé1, dont on a interrogé les gérants/propriétaires, on a dégagé les remarques suivantes: -Le domaine de restauration a évolué dernièrement d’une façon remarquable. Donc, il est nécessaire d’avoir des systèmes informatisés pour garantir le bon fonctionnement. En effet, les différentes fonctionnalités nécessaires sont : la gestion des commandes, la gestion du stock, la gestion des produits, la réservation des tables, la gestion des personnels, la gestion de fidélité, la gestion des clients aussi que la consultation des statistiques. -Les étapes de passage d’une commande débutent par notification sur papier des produits commandés par le client. Ensuite, le serveur la saisie dans le terminal du système. Enfin, il en informe oralement le cuisinier/bar man. Notre mission consiste à automatiser le passage de la commande de tel sorte qu’on annule le contact direct entre les personnels. -Le stock est géré d’une façon manuelle en introduisant la quantité de stock en entrée ainsi que la quantité en sortie par jour. Donc notre mission consiste à informatiser la gestion de stock de tel sorte que chaque mise à jour du stock doit être effectué d’une façon automatique aussi qu’on attribue à chaque article stocké un seuil minimum de tel façon qu’une ligne commande sera ajoutée automatiquement dans la liste des commandes fournisseur pour le produit concerné. -Il existe trois catégories de produits : 1 Voir questionnaireAnnexe page 74
  13. 13. MOBI RESTO Slim Hammami 13 *produit simple : produits intégrés au stock et pouvant être vendus immédiatement ou utilisés pour la préparation d’autres recettes. *recette : produit composé de plusieurs autres produits (cocktails, recette de cuisine). On peut ainsi gérer les fiches techniques de manière détaillée. Le stock des produits constituants la recette est automatiquement impacté lors de chaque vente. *produit rapide : produit qui est intégré dans le stock de la même façon que les recettes et pouvant être crée très rapidement (ex : plat du jour). -La réservation des tables : c’est le fait de la prise des réservations des clients et optimiser le taux d’occupation du restaurant grâce à une vue planning. Donc il s’agit du contrôle de chaque réservation afin d'éviter les chevauchements pour un horaire et une table. Actuellement, cette fonction n’est pas informatisée elle est traité d’une façon manuelle donc on risque de perdre des informations. -La gestion des personnels nécessite trois fonctionnalités : * L’enregistrement des informations personnelles pour chaque embauché. * Le contrôle des absences et des heures supplémentaires des personnels. * Calcul de salaire pour chaque personnel en prenant en considération les absences et les heures supplémentaires. -La gestion de fidélité est le fait de gérer les points de fidélités pour chaque client aussi que l’attribution des points pour chaque produit et l’attribution des montants des points de fidélités pour chaque cadeau. En fait, cette fonctionnalité est inexistante dans les systèmes courants. -La consultation des statistiques qui concerne : *La consultation de la recette journalière. *La recette de chaque serveur. *La quantité consommée. *La quantité restante de chaque produit en stock. *La quantité sortante de chaque produit fini.
  14. 14. MOBI RESTO Slim Hammami 14 -Tous les répondeurs au questionnaire, sont tenté disposer d’une application qui facilite et accélère le passage des commandes. -Aussi, ils ont le besoin de diminuer le contact direct entre les personnels (serveurs, cuisiniers, bar man…) afin de diminuer le vol des matières premières ainsi que les produits finis. -La majorité des personnes interrogées ont demandé un système de gestion de fidélité pour leurs clients. -Les personnes ciblées dans ce questionnaire, demandent une nouvelle application en gardant les anciennes fonctionnalités offertes par leurs systèmes courants et en exploitant les nouvelles technologies. 1.1.1 : Présentation de l’application : Notre application intitulée « MOBI-RESTO », est une application Androïd, consiste à informatiser la gestion des commandes, la gestion de stock, la gestion des produits, la réservation des tables, la gestion des personnels, la gestion de fidélité, la gestion des clients et la consultation des statistiques. L’application à réaliser permettre l’accès sécurisé : -Par le gérant qui dispose des différentes fonctionnalités : *La gestion du stock. *La gestion des clients. *La gestion des produits. *La gestion des personnels. *La réservation des tables. *La consultation des statistiques. -Par le serveur qui dispose divers fonctionnalités : *la consultation des produits disponibles. *le passage des commandes client. *la réservation des tables. -Une session pour le client qui dispose comme accès à différentes options : *La consultation des produits disponibles. *Le passage d’une commande interne. *La consultation du crédit fidélité.
  15. 15. MOBI RESTO Slim Hammami 15 *La gestion de son compte personnel. *Le choix et la réservation d’une table. 1.1.2 : Objectifs à atteindre : L’application « MOBI-RESTO » permettre l'ajout de l’efficacité aux processus internes d’un restaurant. Elle doit permettre d’atteindre les objectifs suivants :  Accélérer et faciliter la procédure de passage de commandes.  Le contrôle du stock et des entrées/sorties.  Gérer les personnels  Gagner du temps et une meilleure organisation du travail.  Stocker les commandes et notifier l’utilisateur pour le changement de l’état de la commande.  Stocker les informations des clients.  Gagner la confiance et la fidélité du client.  Gérer les réservations des tables.  Consultation des statistiques journalières (recette journalière totale, recette journalière pour chaque serveur, la quantité sortante de chaque produit fini).  La mobilité des différents processus de travail. 1.2 Repérage du domaine : Le repérage du domaine permet de déterminer le domaine d’étude et ses échanges avec l’environnement en utilisant le diagramme de collaboration métier comme formalisme de présentation. En effet, ce diagramme permet de constituer un premier niveau de compréhension du système d’information relatif au domaine d’étude en présentant le domaine comme une boîte noire et les messages échangés entre ce domaine et ses acteurs métier. D’après notre étude, nous avons pu dégager les acteurs métier «serveur», «client», «cuisinier/bar man» et «gérant».
  16. 16. MOBI RESTO Slim Hammami 16 Légende : Numéro Désignation 1 Consulter les produits disponibles 2 Passer les commandes clients 3 Vérifier les produits disponibles 4 Consulter stock 5 Consulter statistiques 6 Changer état commande 1.3 Modélisation du métier : Le diagramme de cas d’utilisation métier est un ensemble de processus métier. Chaque action d’un processus métier s’appuie sur des interactions réalisées par différents acteurs collaborant pour délivrer un résultat bien défini. En effet, ce diagramme permet de décrire en général le métier et non le système informatique. 2 2 Voir Références Figure 1- 1 : Diagramme de collaboration métier Tableau 1-1 : Echanges d’information entre les acteurs externes et le système de gestion de restaurant
  17. 17. MOBI RESTO Slim Hammami 17 La description des processus métier apportent une vision du métier réelle, et constitue un excellent instrument de formalisation et d’analyse dans la construction des systèmes.  Processus métier «Gérer stock » Le gérant qui peut gérer le stock, c'est-à-dire consulter et modifier le stock des matières premières.  Processus métier «Consulter statistiques » Le gérant a la possibilité de consulter la recette journalière pour chaque serveur aussi la recette totale. En effet, il peut consulter la liste des produits vendus par chaque serveur ou bien la liste totale des produits vendu. Ainsi, il peut de consulter la recette mensuelle et le chiffre d’affaire par année.  Processus métier «Consulter produits » Le client ou le serveur ont la possibilité de consulter la liste des produits disponibles avec quelques informations pour chaque produit (prix, disponibilité du produit, les composants du produit pour les produits composés). Figure 1-4 : Diagramme des cas d'utilisation métier
  18. 18. MOBI RESTO Slim Hammami 18  Processus métier «Passer commande client » Le serveur a la possibilité de passer une commande client en choisissant un ou plusieurs produits parmi ceux qui sont disponibles.  Processus métier «Changer état commande » Le cuisinier peut changer l’état d’une commande d’un état « commande en cour de préparation » à un état « commande prête ». 1.4: Critique de l’existant : Actuellement, le passage des commande se fait d’une façon transactionnelle (le serveur prend manuellement la commande du client sur un carnet, puis tape la commande sur la machine) donc il y a le risque de perte de quelques informations aussi que la perte du temps. Aussi, de la part du cuisinier/bar-man, il informe verbalement le serveur du changement d’état d’une ou plusieurs commandes. Le contact direct entre les personnels (serveurs, cuisiniers, bar-man) peut causer le vol de quelques ressources : +Financière : le serveur n’enregistre pas la commande dans le système ce qui peut causer le vol du prix de cette commande. +On risque de voler les matières premières. Les interrogés se sont trouvée face à des inconvénients, d’où de la naissance de la solution « MOBI-RESTO », notre solution proposée permet:  D’avoir une interface facile à utilisée.  De faire un répertoire pour les clients fidèles ainsi que les récompenser d’un programme de fidélité.  D’établir des statistiques.  Enregistrer toutes les opérations effectuées.  La mobilité des différentes fonctionnalités offerte par cette solution. Conclusion : Nous avons présenté dans ce chapitre la description de l’application ainsi que la modélisation métier en présentant le modèle de contexte métier, le diagramme de cas d’utilisation métier ainsi que la description de chaque
  19. 19. MOBI RESTO Slim Hammami 19 processus métier. Aussi nous avons critiqué l’existant pour dégager les anomalies du système actuel. Dans le chapitre suivant nous allons construire le diagramme de classe, les diagrammes des séquences et les diagrammes d’états.
  20. 20. MOBI RESTO Slim Hammami 20 Chapitre 2: CAPTURE DES BESOINS
  21. 21. MOBI RESTO Slim Hammami 21 2. Capture des besoins : Introduction : Nous essayons de présenter dans ce chapitre, d’établir une description détaillée des différentes fonctionnalités du futur système. En effet, nous identifions les besoins fonctionnels et techniques et les messages échangés entre les différents acteurs du système et leurs interactions en se basant sur les diagrammes de contexte et de cas d’utilisation du système informatisé et la description textuelle des scénarios. 2.1 : Les acteurs du système informatisé : Acteur Rôle Gérant  Gérer les clients  Consulter les statistiques  Gérer les personnels  Gérer les articles  Gérer le stock  Gérer les réservations Serveur  Gérer les commandes  Consulter les produits disponibles  Gérer les réservations Client  Consulter les produits disponibles  Passer une commande  Réserver table  Gérer les points de fidélité Cuisinier / bar man  Changer état commande Tableau 2-1 : Acteurs du système informatisé
  22. 22. MOBI RESTO Slim Hammami 22 2.2. Modèle de contexte du système informatisé Légende : 1. Ajouter / modifier / consulter un client. 2. Consulter la recette journalière, la recette journalière par serveur, la quantité consommée de chaque produit, la quantité restante de chaque produit, la liste des produits fini sortants. 3. Ajouter / modifier / consulter /supprimer un personnel. 4. Ajouter / modifier / consulter /supprimer un article. 5. Consulter / modifier le stock des matières premières. 6. Ajouter / modifier / consulter /supprimer une réservation. 7. Ajouter / modifier / consulter /supprimer une commande non encore préparé. 8. Consulter les produits finis disponibles. 9. Ajouter / modifier / consulter une réservation. 10.Consulter les produits finis disponibles. 11.Passer une commande. 12.Ajouter / modifier / consulter une réservation. Figure 2- 2 : Diagramme de collaboration informatisé
  23. 23. MOBI RESTO Slim Hammami 23 13.Consulter / transférer les points de fidélité. 14.Changer l’état d’une commande de l’état « en cour de préparation » à l’état « commande prête ». 2-3. Elaboration du modèle des cas d’utilisation 2.3.1 Diagramme des cas d’utilisation Un cas d’utilisation (use case) représente un ensemble de séquences d’actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier. Un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur concerné.3 Cas d’utilisation «Authentification » Identification :  Titre : Authentification.  Acteurs : Gérant, Client(s), Serveur(s), cuisinier(s)/bar man. 3 Voir Références Figure 2-3 : Diagramme des cas d'utilisation informatisé
  24. 24. MOBI RESTO Slim Hammami 24  Objectif : Ce CU est utilisé pour se connecter à l’application, et pour assurer la sécurité des données. Description des scénarios :  Pré condition : L’utilisateur doit avoir un nom d’utilisateur et un mot de passe enregistré dans une base de données bien sécurisée.  Post conditions : L’utilisateur accède à l’application.  Scénario nominal : Cet UC débute quand l’utilisateur demande d’accéder à l’application, le système affiche une fenêtre d’authentification et le processus se poursuit comme suit : 1. L’utilisateur saisit son nom d’utilisateur et son mot de passe. 2. L’utilisateur valide la saisie. 3. Le système vérifie le nom d’utilisateur et le mot de passe. Si l’utilisateur a fourni un nom d’utilisateur et/ou un mot de passe incorrect, alors il faut exécuter l’exception1. 4. Le système affiche un message de confirmation. Exceptions : 1. Le système refuse l’accès et affiche « Vérifier votre nom d’utilisateur et/ou votre mot de passe ». Cas d’utilisation « Gérer Clients » Identification :  Titre : Gérer clients.  Acteur : Gérant.  Objectif : Ce CU est utilisé pour le suivi des clients. Description des scénarios :  Pré condition : le gérant est authentifié.  Post conditions : Des informations sont ajoutées, affichées, modifiées ou supprimées.  Scénario nominal : Ajouter client Cet UC débute quand le gérant se connecte sur l’application, le processus se poursuit comme suit: 1-Le gérant demande d’accéder à l’interface « Clients » et choisit l’option « Ajouter ». 2-Le système affiche l’interface correspondante.
  25. 25. MOBI RESTO Slim Hammami 25 3-Le gérant introduit les informations du client (pseudo, nom, prénom, adresse, profession, numéro téléphone) et valide l’ajout. 4- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1, il vérifie la valeur du champ pseudo : si elle est existante alors il exécute l’exception2 et vérifie le champ numéro de téléphone : s’il est différent à 8 chiffres alors il exécute l’exception3. 5-Le système enregistre les informations introduites.  Scénarios alternatifs : Consulter un client : 1-Le gérant demande d’accéder à l’interface « Clients » et choisit l’option « Consulter ». 2-Le gérant introduit le pseudo d’un client et demande au système de chercher ses coordonnées. 3-Le système vérifie l’existence du client, s’il existe alors il affiche ses informations personnelles, si non il exécute l’exception4. Modifier les informations personnelles du client 1-L’exécution du scénario « Consulter un client ». 2-Le gérant choisit l’option « Modifier » et modifie une ou plusieurs des champs affichés et valide la modification. 3- Le système vérifie s’il y a un champ non rempli, si oui : *Il exécute l’exception1. *Si non, il vérifie la valeur du champ pseudo existe déjà dans la base de données : si elle est existante alors il exécute l’exception2 et vérifie le champ numéro de téléphone : s’il est différent à 8 chiffres alors il exécute l’exception3. 4-Si le système n’exécute aucune exception alors il enregistre les modifications. Supprimer un client 1-Le gérant consulte la liste de tous les clients. 2-Le gérant sélectionne un client. 3-Le système affiche les informations du client sélectionné. 4-Le gérant choisit l’option « Supprimer ». 5-Le système demande à l’utilisateur une confirmation de suppression d’un client. 6-Si oui alors le système supprime le client.
  26. 26. MOBI RESTO Slim Hammami 26 Exceptions : 1-Le système affiche « Champ obligatoire à saisir est vide ! » et retourne sur la saisie des informations. 2-Le système affiche « pseudo existant » et retourne sur la saisie des informations. 3-Le système affiche « Numéro de téléphone invalide » et retourne sur la saisie des informations. 4-Le système affiche « Client inexistant » et retourne sur la saisie des informations. Cas d’utilisation « Gérer les réservations » Identification :  Titre : Gérer les réservations.  Acteur : Gérant, Serveur(s).  Objectif : Ce CU est utilisé pour le suivi des réservations. Description des scénarios :  Pré condition : L’acteur est authentifié.  Post conditions : Une réservation est affichée, ajoutée, modifiée ou supprimée.  Scénario nominal : Afficher réservation Ce CU débute quand le gérant ou le serveur se connecte sur l’application, le processus se poursuit comme suit: 1-L’acteur demande l’accès à l’interface « réservations». 2-Le système affiche l’interface correspondante. 3-Le gérant ou le serveur introduit la date désirée. 4-Le système affiche les numéros de tables réservées à cette date aussi que l’heure de début et l’heure de fin de chaque réservation.  Scénarios alternatifs : Ajouter une réservation 1-L’acteur demande au système d’ajouter une réservation. 2- Le système exécute le scénario « Consulter client ».
  27. 27. MOBI RESTO Slim Hammami 27 3-Le système demande au gérant ou au serveur de saisir les informations nécessaires (numéro de table, date de la réservation, l’heure de début de la réservation, l’heure de fin de la réservation ainsi que l’identifiant du client). 4-L’acteur valide cette insertion : * Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1. *Si non, il vérifie le champ numéro de table : si le numéro de table n’existe pas alors il exécute exception2. *Si non, il vérifie le champ date réservation : s’il s’agit d’une date invalide alors il exécute exception3. *Si non, il vérifie les champs heure de début de la réservation et l’heure de fin de la réservation : s’il s’agit d’une heure invalide alors il exécute l’exception4. *Si non, il vérifie le champ identifiant client : s’il n’existe pas alors il exécute l’exception5. *Si non, s’il s’agit d’une réservation existante alors il exécute l’exception6. 6-Si le système n’exécute aucune exception alors il valide la réservation. Modifier une réservation 1-Le système exécute le scénario « Afficher toute réservation ». 2- L’acteur sélectionne une réservation parmis la liste. 3-Le système affiche les informations de la réservation sélectionné. 4- L’acteur choisit l’option « Modifier » et modifie une ou plusieurs des champs affichés et valide la modification. 5-L‘acteur valide cette insertion : * Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1. *Si non, il vérifie le champ numéro de table : si le numéro de table n’existe pas alors il exécute exception2. *Si non, il vérifie le champ date réservation : s’il s’agit d’une date invalide alors il exécute exception3. *Si non, il vérifie les champs heure de début de la réservation et l’heure de fin de la réservation : s’il s’agit d’une heure invalide alors il exécute l’exception4. Supprimer réservation 1-Le système exécute le scénario « Afficher réservation ». 2- Le gérant choisit l’option « Supprimer ». 3- Le système supprime le client.
  28. 28. MOBI RESTO Slim Hammami 28 Exceptions : 1-Le système affiche « Champ obligatoire à saisir est vide ! ». 2-Le système affiche « Numéro de table inexistant ». 3-Le système affiche « Date invalide ». 4-Le système affiche « Heure invalide ». 5-Le système affiche « Client inexistant » et donne l’autorisation d’ajouter un client. 6-Le système affiche « Table indisponible ». Cas d’utilisation « Consulter les statistiques » Identification :  Titre : Consulter les statistiques.  Acteur : Gérant.  Objectif : Ce CU est utilisé pour le suivi des réservations. Description des scénarios :  Pré condition : Le gérant est authentifié.  Post conditions : la recette journalière, la recette de chaque serveur, la quantité consommée et la quantité restante de chaque produit en stock et la quantité sortante de chaque produit fini sont affichés.  Scénario nominal : Consulter la recette journalière Cet UC débute quand le gérant se connecte sur l’application, le processus se poursuit comme suit: 1-Le gérant demande d’accéder à l’interface « Statistiques ». 2-Le système affiche l’interface correspondante. 3-Le gérant choisit l’option « Recette ». 4-Le système affiche l’interface correspondante. 5-Le gérant choisit l’option recette journalière. 6-Le système affiche la recette journalière.  Scénarios alternatifs : Consulter la recette de chaque serveur 1- Le gérant demande d’accéder à l’interface « Statistiques ». 2-Le système affiche l’interface correspondante.
  29. 29. MOBI RESTO Slim Hammami 29 3-Le gérant choisit l’option « Recette ». 4-Le système affiche l’interface correspondante. 5-Le gérant choisit l’option « Recette journalière par serveur ». 6-Le système affiche la liste des serveurs fonctionnels pendant la date système. 7-Le gérant choisit un serveur parmi la liste affiché. 8-Le système affiche la recette journalière pour le serveur choisit. Consulter la liste des produits consommé par jour 1-Le gérant demande d’accéder à l’interface « Statistiques ». 2-Le système affiche l’interface correspondante. 3-Le gérant choisit l’option « Consultation du stock » 4-Le système affiche l’interface correspondante. 5-Le gérant choisit l’option « Consulter la liste des produits consommés aujord’hui ». 6-Le système affiche la liste des produit consommés pour une date égale à la date système ainsi que la quantité consommé pour chaque produit. Consulter la liste des produits restant à la fin de la journée 1-Le gérant demande d’accéder à l’interface « Statistiques ». 2-Le système affiche l’interface correspondante. 3-Le gérant choisit l’option « Consultation du stock » 4-Le système affiche l’interface correspondante. 5-Le gérant choisit l’option « Consulter la liste des produits restant aujord’hui ». 6-Le système affiche la liste des produits restants pour une date égale à la date système ainsi que la quantité restante pour chaque produit. Consulter la liste des produits finis sortantes par jour 1-Le gérant demande d’accéder à l’interface « Statistiques ». 2-Le système affiche l’interface correspondante. 3-Le gérant choisit l’option « Produits finis consommés » 4-Le système affiche la liste des produits finis vendus pour une date égale à la date système ainsi que la quantité vendu pour chaque produit. Cas d’utilisation « Gérer Personnels » Identification :  Titre : Gérer personnels.  Acteur : Gérant.  Objectif : Ce CU est utilisé pour le suivi des personnels.
  30. 30. MOBI RESTO Slim Hammami 30 Description des scénarios :  Pré condition : Le gérant est authentifié.  Post conditions : Un personnel est ajouté, affiché, modifié ou supprimé.  Scénario nominal : Ajouter personnel Cet UC débute quand le gérant se connecte sur l’application, le processus se poursuit comme suit: 1-Le gérant demande d’accéder à l’interface « Personnel » et choisit l’option « Ajouter ». 2-Le système affiche l’interface correspondante. 3-Le gérant introduit les informations du personnel (identifiant, nom, prénom, adresse, tâche, salaire, numéro téléphone) et valide l’ajout. 4- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1, et vérifie le champ numéro de téléphone : s’il est différent à 8 chiffres alors il exécute l’exception2. 5-Si le système n’exécute aucune exception alors il enregistre les informations introduites.  Scénarios alternatifs : Consulter les informations d’un personnel : 1-Le gérant demande d’accéder à l’interface « Personnel » et choisit l’option « Consulter ». 2-Le gérant introduit l’identifiant d’un personnel et demande au système de chercher ses coordonnées. 3-Le système vérifie l’existence du personnel, s’il existe alors il affiche ses informations personnelles, si non il exécute l’exception3. Modifier les informations d’un personnel 1-L’exécution du scénario « Consulter les informations d’un personnel ». 2-Le gérant choisit l’option « Modifier » et modifie une ou plusieurs des champs affichés et valide la modification. 3- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1 et vérifie le champ numéro de téléphone : s’il est différent à 8 chiffres alors il exécute l’exception2.
  31. 31. MOBI RESTO Slim Hammami 31 4-Si le système n’exécute aucune exception alors il enregistre les modifications. Supprimer un personnel 1-L’exécution du scénario « Consulter les informations d’un personnel ». 2-Le gérant choisit l’option « Supprimer ». 3-Le système supprime le client. Exceptions : 1-Le système affiche « Champ obligatoire à saisir est vide ! ». 2-Le système affiche « Numéro de téléphone invalide ». 3-Le système affiche « Personnel inexistant ». Cas d’utilisation « Gérer articles » Identification :  Titre : Gérer articles.  Acteur : Gérant.  Objectif : Ce CU est utilisé pour le suivi des articles. Description des scénarios :  Pré condition : le gérant est authentifié.  Post conditions : Un article est ajouté, affiché, modifié ou supprimé.  Scénario nominal : Ajouter article Ce CU débute quand le gérant se connecte sur l’application, le processus se poursuit comme suit: 1-Le gérant demande d’accéder à l’interface « Article » et choisit l’option « Ajouter ». 2-Le système affiche l’interface correspondante. 3-Le gérant introduit les informations de l’article (identifiant, libellé, nombre de composants, quantité de chaque composant, prix unitaire, disponibilité) et valide l’ajout. 4- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1. 5-Si le système n’exécute aucune exception alors il enregistre les informations introduites.
  32. 32. MOBI RESTO Slim Hammami 32  Scénarios alternatifs : Consulter les informations d’un article : 1-Le gérant demande d’accéder à l’interface « Article » et choisit l’option « Consulter ». 2-Le gérant introduit l’identifiant d’un article et demande au système de chercher ses informations. 3-Le système vérifie l’existence de l’article, s’il existe alors il affiche ses informations si non il exécute l’exception2. Modifier les informations d’un article 1-L’exécution du scénario « Consulter les informations d’un article ». 2-Le gérant choisit l’option « Modifier » et modifie une ou plusieurs des champs affichés et valide la modification. 3- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1. 4-Si le système n’exécute aucune exception alors il enregistre les modifications. Supprimer un article 1-L’exécution du scénario « Consulter les informations d’un article ». 2-Le gérant choisit l’option « Supprimer ». 3-Le système supprime l’article. Exceptions : 1-Le système affiche « Champ obligatoire à saisir est vide ! ». 2-Le système affiche « Article inexistant ». Cas d’utilisation « Gérer le stock » Identification :  Titre : Gérer le stock.  Acteur : Gérant.  Objectif : Ce CU est utilisé pour le suivi du stock. Description des scénarios :  Pré condition : Le gérant est authentifié.  Post conditions : Le stock est affiché, modifié ou un article est ajouté au stock.  Scénario nominal :
  33. 33. MOBI RESTO Slim Hammami 33 Afficher stock Ce CU débute quand le gérant se connecte sur l’application, le processus se poursuit comme suit: 1-Le gérant demande d’accéder à l’interface « Stock». 2-Le système affiche l’interface correspondante. 3-Le gérant choisit l’option « consulter ». 4-Le système affiche la liste des produits ainsi que la quantité en stock de chaque produit.  Scénarios alternatifs : Ajouter modifier stock 1- Le système exécute le scénario « Consulter stock ». 2-Le gérant choisit un article parmi la liste affiché, modifie la quantité en stock et valide la modification. Ajouter un article au stock 1- Le gérant demande d’accéder à l’interface « Stock». 2-Le système affiche l’interface correspondante. 3-Le gérant choisit l’option « Ajouter ». 4-Le système affiche le formulaire d’ajout d’un article au stock. 5-Le gérant saisie les informations de l’article (code article, libellé, quantité en stock) et valide l’ajout. 6- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1. 7-Si le système n’a exécuté aucune exception, alors il enregistre l’ajout. Exceptions : 1-Le système affiche « Champ obligatoire à saisir est vide ! ». Cas d’utilisation « Changer état commande » Identification :  Titre : Changer état commande.  Acteur : cuisinier/bar-man.  Objectif : Ce CU est utilisé pour changer l’état d’une commande existante.
  34. 34. MOBI RESTO Slim Hammami 34 Description des scénarios :  Pré condition : Le cuisinier/bar-man est authentifié.  Post conditions : L’état d’une commande est modifié.  Scénario nominal : Modifier état commande Ce CU débute quand le cuisinier/bar-man se connecte sur l’application, le processus se poursuit comme suit: 1- Le cuisinier/bar man demande d’accéder à l’interface « Commandes existantes ». 2-Le système affiche la liste des commandes qui ont un état différent à « Commande prête et servie ». 3- Le cuisinier/bar man choisit une commande parmi la liste et change son état à « commande prête et non servis ». Cas d’utilisation « Ajouter client » Identification :  Titre : Ajouter client.  Acteur : Serveur.  Objectif : Ce CU est utilisé pour ajouter un client à fin de lui affecté une réservation. Description des scénarios :  Pré condition : Le serveur est authentifié.  Post conditions : Un client est ajouté.  Scénario nominal : Ajouter client Ce CU débute quand le serveur se connecte sur l’application et veut affecter une réservation à un client inexistant. Le processus se poursuit comme suit: 1-Le gérant demande d’accéder à l’interface « Réservation » et choisit l’option « Ajouter réservation ». 2-Le système affiche l’interface correspondante et exécute le scénario « Consulter client ». 3-Si le système affiche le message « Client inexistant » alors il affiche le formulaire d’ajout d’un client.
  35. 35. MOBI RESTO Slim Hammami 35 4-Le serveur introduit les informations du client (pseudo, nom, prénom, adresse, profession, numéro téléphone) et valide l’ajout. 5- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1, il vérifie la valeur du champ pseudo existe déjà dans la base de données : si elle est existante alors il exécute l’exception2 et vérifie le champ numéro de téléphone : s’il est différent à 8 chiffres alors il exécute l’exception3. 6-Si le système n’exécute aucune exception alors il enregistre les informations introduites et retourne au formulaire « Ajouter réservation ». Exceptions : 1-Le système affiche « Champ obligatoire à saisir est vide ! ». 2-Le système affiche « pseudo existant ». 3-Le système affiche « Numéro de téléphone invalide ». Cas d’utilisation « Gérer commande » Identification :  Titre : Gérer commande.  Acteur : Serveur.  Objectif : Ce CU est utilisé pour la manipulation des commandes. Description des scénarios :  Pré condition : Le serveur est authentifié.  Post conditions : Une commande est ajoutée, affichée, modifiée ou supprimée.  Scénario nominal : Ajouter commande Ce CU débute quand le serveur se connecte sur l’application, le processus se poursuit comme suit: 1-Le gérant demande d’accéder à l’interface « Commande » et choisit l’option « Ajouter ». 2-Le système affiche l’interface correspondante. 3-Le gérant introduit les informations de la commande (articles commandés et la quantité de chaque article) et valide l’ajout. 4- Le système enregistre la commande ajoutée en donnant un identifiant pour chaque commande et un état de commande égale à « commande non prête ».
  36. 36. MOBI RESTO Slim Hammami 36  Scénarios alternatifs : Consulter une commande : 1-Le serveur demande d’accéder à l’interface « Commande » et choisit l’option « Consulter ». 2-Le serveur introduit l’identifiant de la commande et demande au système de chercher ses informations. 3-Le système vérifie l’existence de l’identifiant : s’il existe il affiche les informations concernant la commande, si non il exécute l’exception1. Modifier commande 1-L’exécution du scénario « Consulter commande ». 2-Le gérant choisit l’option « Modifier » et ajoute un ou plusieurs produits à cette commande en affectant une quantité pour chaque produit et valide la modification. 3-Le système enregistre les modifications. Supprimer un article 1-L’exécution du scénario « Consulter commande ». 2-Le gérant choisit l’option « Supprimer ». 3-Si l’état de commande est égal à « commande prête » ou « Commande en cour de préparation » alors le système exécute l’exception2. 3-Si le système n’exécute aucune condition alors il supprime l’article. Exceptions : 1-Le système affiche « Commande inexistante !! ». 2-Le système affiche « Impossible de supprimer la commande !! ». Cas d’utilisation « Consulter les produits disponibles » Identification :  Titre : Consulter les produits disponibles.  Acteur : serveur, client.  Objectif : Ce CU est utilisé pour consulter les produits disponibles ainsi que leurs informations. Description des scénarios :  Pré condition : L’acteur est déjà authentifié.  Post conditions : La liste des produits disponibles est affichée.
  37. 37. MOBI RESTO Slim Hammami 37  Scénario nominal : Consulter les produits Ce CU débute quand le serveur ou le client se connecte sur l’application, le processus se poursuit comme suit: 1- L’acteur demande d’accéder à l’interface « Produits disponibles ». 2-Le système affiche la liste des produits qui ont un état différent à « non disponible ». Cas d’utilisation « Passer commande » Identification :  Titre : Passer commande.  Acteur : Client.  Objectif : Ce CU est utilisé pour passer une commande à partir d’un compte client.  Description des scénarios :  Pré condition : Le client est déjà authentifié.  Post conditions : La commande est passée.  Scénario nominal : Passer commande Ce CU débute quand le client man se connecte sur l’application, le processusse poursuit comme suit: 1-Le client demande d’accéder à l’interface « Passer commande». 2-Le système affiche l’interface correspondante. 3-Le client introduit les informations de la commande (articles commandés et la quantité de chaque article) ainsi que le numéro de sa table et valide l’ajout. 4- Le système vérifie que le champ « numéro de table » :s’il est vide ou inexistant alors il exécute l’exception1 si non il enregistre la commande ajoutée en donnant un identifiant pour chaque commande et un état de commande égale à « commande non prête ». Exceptions : 1-Le système affiche « numéro de table inexistant ».
  38. 38. MOBI RESTO Slim Hammami 38 Cas d’utilisation « Consulter état commande » Identification :  Titre : Consulter état commande.  Acteur : Client.  Objectif : Ce CU est utilisé pour passer une commande à partir d’un compte client. Description des scénarios :  Pré condition : Le client est déjà authentifié est à passer une commande qui a comme état une valeur différente à « commande prête et servie ».  Post conditions : L’état de la commande est affiché.  Scénario nominal : Passer commande Ce CU débute quand le client man se connecte sur l’application, le processusse poursuit comme suit: 1-Le client demande d’accéder à l’interface « Consulter l’état de ma commande ». 2-Le système affiche l’état actuel de la commande. Cas d’utilisation « Réserver table » Identification :  Titre : Réserver table.  Acteur : Client.  Objectif : Ce CU est utilisé pour réserver une tables à une date donnée et pendant un intervalle horaire définit. Description des scénarios :  Pré condition : Le client est déjà authentifié.  Post conditions : Une réservation est établie.  Scénario nominal : Passer commande Cet UC débute quand le client man se connecte sur l’application, le processus se poursuit comme suit: 1-Le client demande d’accéder à l’interface « Réserver une table ».
  39. 39. MOBI RESTO Slim Hammami 39 2-Le système demande au client de saisir les informations nécessaires (numéro de table, date de la réservation, l’heure de début de la réservation, l’heure de fin de la réservation ainsi que l’identifiant du client). 3-Le client valide cette insertion. 4- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1, vérifie le champ numéro de table : si le numéro de table n’existe pas alors il exécute exception2, vérifie le champ date réservation : s’il s’agit d’une date invalide alors il exécute exception3, vérifie les champs heure de début de la réservation et l’heure de fin de la réservation : s’il s’agit d’une heure invalide alors il exécute l’exception4 et exécute le scénario « Afficher réservation » : s’il s’agit d’une réservation existante alors il exécute l’exception5. 5-Si le système n’exécute aucune exception alors il valide la réservation. Exceptions : 1-Le système affiche « Champ obligatoire à saisir est vide ! ». 2-Le système affiche « Numéro de table inexistant ». 3-Le système affiche « Date invalide ». 4-Le système affiche « Heure invalide ». 5-Le système affiche « Table indisponible ». Cas d’utilisation « Créer compte client » Identification :  Titre : Créer compte client.  Acteur : Client.  Objectif : Ce CU est utilisé que le client crée son propre compte. Description des scénarios :  Pré condition : rien.  Post conditions : Un compte client est crée.  Scénario nominal : Créer compte client 1-Le client demande à accéder à l’interface « S’inscrire ». 2-Le système affiche le formulaire d’inscription. 3-Le client introduit ses informations personnelles (pseudo, nom, prénom, adresse, profession, numéro téléphone) et valide l’ajout.
  40. 40. MOBI RESTO Slim Hammami 40 4- Le système vérifie s’il y a un champ non rempli, si oui il exécute l’exception1, il vérifie la valeur du champ pseudo existe déjà dans la base de données : si elle est existante alors il exécute l’exception2 et vérifie le champ numéro de téléphone : s’il est différent à 8 chiffres alors il exécute l’exception3. 5-Si le système n’exécute aucune exception alors il enregistre les informations introduites. Exceptions : 1-Le système affiche « Champ obligatoire à saisir est vide ! ». 2-Le système affiche « pseudo existant ». 3-Le système affiche « Numéro de téléphone invalide ». Conclusion Après avoir présenté les besoins fonctionnels et techniques envers le système à développer, à travers la définition des acteurs du système et la construction du modèle de contexte et le diagramme des cas d’utilisation du système informatisé, et leurs descriptions textuelles sous forme de différents scénarios. Dans le prochain chapitre, nous exposons le diagramme de classe avec son dictionnaire de donnés, les diagrammes de séquences et d’états.
  41. 41. MOBI RESTO Slim Hammami 41 Chapitre 3: ANALYSE
  42. 42. MOBI RESTO Slim Hammami 42 3. Analyse : Introduction Ce chapitre va nous permettre d’avoir une idée claire sur notre domaine d’étude en procédant à une conception détaillée. En effet, nous allons présenter un modèle statique par le diagramme de classes, et un modèle dynamique qui s’intéresse à l’organisation des scénarios en diagrammes de séquences et en nous référant à la description du cycle de vie d’une classe particulièrement par le biais des diagrammes d’états. 3.1. Construction du diagramme de classes 3.1.1. Définition Le diagramme de classes est un schéma pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et dynamiques.4 Une classe est un ensemble de fonctions et de données (attributs) qui sont liées ensemble par un champ sémantique. Les classes sont utilisées dans la programmation orientée objet. Elles permettent de modéliser un programme et ainsi de découper une tâche complexe en plusieurs petits travaux simples.5 3.1.2. Présentation du diagramme de classes de l’application « Mobi Resto » : 4 Voir Références 5 Voir Références
  43. 43. MOBI RESTO Slim Hammami 43 Figure 3-1 : Diagramme de classes
  44. 44. MOBI RESTO Slim Hammami 44 3.1.3. Dictionnaire des données : Classe : Personne Attribut Désignation Méthodes id_pers Identifiant d’une personne. ajouterPersonne() consulterPersonne() modifierPersonne() supprimerPersonne() pseudo Pseudo d’une personne. mot_passe Le mot de passe d’une personne. nom Le nom d’une personne. prenom Le prénom d’une personne. tel Le numéro de téléphone d’une personne. adresse L’adresse d’une personne. mail L’adresse e-mail d’une personne. description La description d’une personne. Classe : Personnel Attribut Désignation Méthodes dat_embauc La date d’embauche d’un personnel modifierSalaireJourn() salair_journ Le salaire journalier d’un personnel Classe : Client Attribut Désignation Méthodes credit_fid Le crédit de fidélité d’un client consulterCredit() augmenterCredit() retrancherCredit() Tableau 3-1 : Dictionnaire de données concernant la classe Personne Tableau3-2 : Dictionnaire de données concernant la classe Personnel Tableau 3-3 : Dictionnaire de données concernant la classe Client
  45. 45. MOBI RESTO Slim Hammami 45 Classe : Reservation Attribut Désignation Méthodes id_res L’identifiant d’une réservation ajouterReservation() consulterReservation() modifierReservation() supprimerReservation() changerEtatReservation() dat_res La date d’une réservation heur_deb_res L’heure dedébut d’une réservation heur_fin_res L’heure de fin d’une réservation Classe : Table Attribut Désignation Méthodes Num_tab Le numéro d’une table ajouterTable() modifierCapaciteTable() consulterTable() changerEtatTable() supprimerTable() capacite La capacité d’une table etat L’état de disponibilité d’une table à la date système. Classe : Commande Attribut Désignation Méthodes id_cmd L’identifiant d’une commande ajoutercommande() consulterCommande() supprimerCommande() changerEtatCommande() dat_cmd La date d’une commande mnt_cmd Le montant d’une commande etat_cmd L’état d’une commande Tableau 3-4 : Dictionnaire de données concernant la classe Reservation Tableau 3-5 : Dictionnaire de données concernant la classe Table Tableau 3-6 : Dictionnaire de données concernant la classe Commande
  46. 46. MOBI RESTO Slim Hammami 46 Classe : Article Attribut Désignation Méthodes id_art L’identifiant d’un article ajouterArticle() consulterArticle() modifierArticle() supprimerArticle() designation La désignation d’un article prix_unit Le prix unitaire d’un article Classe : Composant Attribut Désignation Méthodes qte_comp La quantité d’une matière première dans un article modifierQteComposant() Classe : LigneCmd Attribut Désignation Méthodes qte_cmd La quantité commandée d’un article dans une commande modifierQteCmd() Classe : Facture Attribut Désignation Méthodes id_fact L’identifiant d’une facture ajouterFacture() consulterFacture() Tableau 3-7 : Dictionnaire de données concernant la classe Article Tableau 3-8 : Dictionnaire de données concernant la classe Composant Tableau3-9 : Dictionnaire de données concernantla classe LigneCmd Tableau 3-10 : Dictionnaire de données concernant la classe Facture
  47. 47. MOBI RESTO Slim Hammami 47 Classe : MatierePremiere Attribut Désignation Méthodes id_mat L’identifiant d’une matière première ajouterMatiere() consulterMatiere() modifierMatiere() supprimerMatiere() designation_mat La désignation d’une matière prix_achat Le prix d’achat d’une matière première Classe : Categorie Attribut Désignation Méthodes id_cat L’identifiant d’une catégorie d’article ajouterCategorie() consulterCategorie() modifierCategorie() supprimerCategorie() lib_cat Le libellé d’une catégorie d’article pts_fid Les points de fidélité attribués à une catégorie d’article Tableau 3-11 : Dictionnaire de données concernant la classe MatierePremiere Tableau3-12 : Dictionnaire de données concernantla classeCategorie
  48. 48. MOBI RESTO Slim Hammami 48 3.2. Développement du modèle dynamique 3.2.1Construction des diagrammes de séquences 3.2.1.1 Définition Le diagramme de séquences permet de cacher les interactions d'objets dans le cadre d'un scénario d'un Diagramme des cas d'utilisation. Dans un soucide simplification, on représente l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets.6 La dimension verticale du diagramme représente le temps, permettant de visualiser l'enchaînement des actions dans le temps, et de spécifier la naissance et la mort d'objets. Les périodes d'activité des objets sontsymbolisées par des rectangles, et ces objets dialoguent par le biais de messages.7 Authentification : Le digramme, exposé ci-dessous, décrit les scénarios possibles lors d’une opération d’authentification. En effet après l’ajout d’un utilisateur à la base de données de notre application Androïd, l’administrateur donne un pseudo et un mot de passe à l’utilisateur ou bien l’utilisateur choisit son pseudo et mot de passe. Le système à son tour affichera une interface contenant des champs à remplir, l’utilisateur saisit son pseudo et son mot de passe et valide. Le système va vérifier l’existence du pseudo et de mot de passe qu’il lui correspondant dans la base. En cas d’existence des données dans la base, le système vérifie la valeur du champ description de l’utilisateur authentifié et selon cette valeur il affiche l’interface convenable. Si non, le système affiche un message d’erreur. 6 Voir Références 7 Voir Références
  49. 49. MOBI RESTO Slim Hammami 49 : Utilisateur: Utilisateur : Ecran d'authentification: Ecran d'authentification : Controleur authentification : Controleur authentification : Personne: Personne p : Personnep : Personne 1: Saisir(pseudo,pass) 2: récupérer(pseudo,pass) 3: verif:=verifier(pseudo,pass) 5: [verif=valide];desc:=récupérerDesc(pseudo,pass) 4: [verif:=invalide]afficher("données d'authentification incorrects") 6: afficher(EcranAcceuil(desc)) Ajouter une réservation : Le diagramme ci-dessous décrit les scénarios possibles lors d’une opération d’ajout d’une réservation client de la part du gérant. Le gérant introduit le pseudo du client, le numéro de table, la date et l’heure. Le système vérifie l’existence du client dans la base : s’il existe alors il vérifie l’état de la table à la date et l’heure choisis. Si la table est indisponible alors le système propose des suggestions de numéros de tables disponibles à cette heure et date. Si la table est disponible alors la réservation est enregistrée. Si le client n’existe pas, le système affiche que ce client est inexistant dans la base. Figure 3-2 : Diagramme de séquences pour un scénario d’authentification
  50. 50. MOBI RESTO Slim Hammami 50 : Gerant: Gerant : Ecran ajouter réservation: Ecran ajouter réservation : controleur reservation: controleur reservation : Client: Client : Reservation: Reservation 1: Ajouter(pseudoClt,numTab,date,heure) 2: recuperer(pseudoClt,numTab,date,heure) 3: verif:=verifierExistance(pseudoClt) 4: [verif=faux]afficher(client inexistant) 5: [verif=vrai]ver:=verifierDispo(numTab,date,heure) 6: [ver=vrai]ajouterRes(pseudoClt,numTab,date,heure) 7: [ver=faux]afficher(table indisponible) Modifier les données personnelles d’un personnel : Le diagramme ci-dessous décrit les scénarios possibles lors d’une opération de modification des données personnelles d’un personnel embauché de la part du gérant. Le gérant demande la consultation de la liste de tous les personnels. Le système la liste. Le gérant choisi le personnel à modifier. Le système affiche ces données. Le gérant modifie un ou plusieurs champs puis il confirme la modification. Le système vérifie les mots de passes s’ils sont identiques, la validité du numéro de téléphone ainsi que la validité de l’adresse électronique. Si ces contrôles sont validés, alors le système enregistre les modifications. Si non, il affiche un message d’erreur. Figure 3-3 : Diagramme de séquences pour un scénario d’ajout d’une réservation
  51. 51. MOBI RESTO Slim Hammami 51 : Gerant: Gerant : Interface personnels: Interface personnels : Personnel: Personnel p : Personnelp : Personnel 1: ConsulterListePersonnel() 2: DemandeListe() 3: Afficher(ListePers) 4: ChoisirPers(p) 5: DemandeInfo(p) 6: Afficher(données(p)) 7: saisir(pass1,pass2,nom,prenom...) 8: b:=verif(pass1,pass2tel,mail) 9: [b=faux]afficher("données invalides") 10: [b=vrai]Modifier(pass1,pass2,nom,prenom...) 11: afficher("Modification avec succées") Consultation des statistiques: Le diagramme ci-dessous décrit les scénarios possibles lors d’une opération de consultation des statistiques de la part du gérant. Ce scénario débute lorsque le gérant choisit l’option « Statistiques ». L’interface « Statistique » affiche les options possibles (statistiques par serveur, statistiques totales). Ensuite le gérant introduit l’intervalle de dates au cours duquel on désire établir les statistiques.
  52. 52. MOBI RESTO Slim Hammami 52 : Gerant: Gerant : Interface statistiques: Interface statistiques : controlleur statistiques : controlleur statistiques : Commande: Commande 1: demandeStatistiques() 2: demandeStatistiques() 3: Afficher(options) 4: clic:=choisiroptions() 5: [clic=parServeur]demandeListeServeurs() 6: afficher(listeServeurs) 7: choisir(serveur) 8: recupererDonnee(serveur) 9: afficher("choisir periode") 10: saisir(periodDeb,periodFin) 11: recuperer(periodDeb,periodFin) 12: stat:=demandenfo(serveur,periodDeb,periodFin) 13: afficher(stat) 14: [clic=totale]demandePeriode() 15: saisir(periodDeb,periodFin) 16: recuperer(periodDeb,periodFin) 17: stat:=demandenfo(periodDeb,periodFin) 18: afficher(stat) Figure 3-5 : Diagramme de séquences pour un scénario de consultation des statistiques
  53. 53. MOBI RESTO Slim Hammami 53 Affichage page d'authentification Accéder à l'application Champs pseudo et mot de passe S'identifier Erreur de saisie Saisie correct Vérifier Vérifier Traiter erreur Session propre à l'utilisateur Accéder à une session Session gérant Session client Session personnel Accéder à une session gérant Accéder à une session client Accéder à une session personnel 3.2.2. Construction des diagrammes d’états Le diagramme d’activité représente les règles d’enchaînement des activités et actions dans le système. Il permet d’une part de consolider la spécification d’un cas d’utilisation, d’autre part de concevoir une méthode. Authentification Le diagramme ci-dessous représente les changements d’état possible lorsqu’une personne (gérant, serveur, client) s’authentifie pour accéder à sa session. Figure 3-6 : Diagramme d’état transitions concernant «l’authentification»
  54. 54. MOBI RESTO Slim Hammami 54 S'identifier [Refusé] Nouvelle fiche de réservation Saisie des informations Vérifier existance client [Client inexistant] Vérifier disponibilité table [Client existant] [Table indisponible] Enregistrement Ajouter une réservation Le diagramme ci-dessous représente les changements d’état possible lorsque le gérant crée une nouvelle réservation client. Conclusion : Après le développement du diagramme de classes et la construction des diagrammes de séquences et des diagrammes d’états, on passe maintenant à la définition de l'architecture du système et la conception du schéma logique des données. Dans le dernier chapitre, nous détaillons les différents outils et logiciels qui ont été utilisés pour la réalisation de cette application, les diagrammes d’activités, ainsi que le modèle logique et physique de la base de données utilisée. Figure 3-7 : Diagramme d’état transitions concernant l’ajout d’une réservation client
  55. 55. MOBI RESTO Slim Hammami 55 Chapitre 4: REALISATION
  56. 56. MOBI RESTO Slim Hammami 56 4. Réalisation : Introduction Dans ce chapitre, nous allons illustrer les matériaux, logiciels de base et les outils de développement qui sont mis en œuvre pour la réalisation de notre application web ainsi que le modèle physique et logique de la base de données utilisée. 4.1. Environnement de développement :  Matériel : La programmation de l’application a été effectuée sur un ordinateur ayant les caractéristiques suivantes : Composant Caractéristiques Marque HP Pavilion dv6000 Processeur AMD Athlon™ 64 X2 Dual-Core ProcessorTK-57 1.90 Ghz RAM 3Go Disque Dur 5OOGo Ecran 15.3“ Système d’exploitation Microsoft Windows 7 professionnelle  Logiciels : o Word 2007 pour le traitement du texte : Microsoft Word est un logiciel de traitement de texte édité par Microsoft, composant majeur de Microsoft Office. Depuis la version 2003, le logiciel s'appelle Microsoft Office Word au lieu de Microsoft Word. Il occupe environ les neuf dixièmes du marché depuis les années 1990.8 o Eclipse ADT (Androïd Development Touls) comme environnement des applications ANDROID : -Eclipse IDE est un environnement de développement intégré libre (le terme Eclipse désigne également le projet correspondant, lancé 8 Voir Références Tableau 4-1 : Ressources matérielles utilisées
  57. 57. MOBI RESTO Slim Hammami 57 par IBM) extensible, universel et polyvalent, permettant potentiellement de créer des projets de développement mettant en œuvre n'importe quel langage de programmation. Eclipse IDE est principalement écrit en Java (à l'aide de la bibliothèque graphique SWT, d'IBM), et ce langage, grâce à des bibliothèques spécifiques, est également utilisé pour écrire des extensions.9 -ADT (Androïd Developer Tools) est un plugin pour Eclipse qui fournit une suite d'outils qui sont intégrés à l'IDE Eclipse. Il vous offre accès à de nombreuses fonctionnalités qui vous permettent de développer des applications Androïd rapidement. ADT propose l'accès à l'interface graphique de la plupart des outils du SDK de ligne de commande ainsi que d'un outil de conception d'interface utilisateur pour le prototypage rapide, la conception et la construction de l'interface utilisateur de votre application.10 o UML (Unified Modeling Language) comme langage de conception : En informatique UML (de l'anglais Unified Modeling Language), ou Langage de modélisation unifié, est un langage de modélisation graphique à base de pictogrammes. Il est utilisé en développement logiciel, et en conception orientée objet. UML est couramment utilisé dans les projets logiciels.11 o IBM Rational Rose comme outil de modélisation conceptuelle : Rational Roseest un logiciel édité par l'entreprise Rational Machines (plus tard renommée Rational Software) pour créer et éditer les différents diagrammes du modèle UML (Unified Modeling Language) d'un logiciel. Rational Software a été vendu pour 2,1 milliards de dollars à IBM le 20 février 2003. Rational Rosepermet également de sauvegarder et d'imprimer ces diagrammes, ainsi que de générer le codesource Java ou C++ qui leur correspondent.12 o PHP (PHP: Hypertext Preprocessor ou ancien nom : Personal Home Page) comme environnement de développement des services web pour la récupération des données de la base de données : 9 Voir Références 10 Voir Références 11 Voir Références 12 Voir Références
  58. 58. MOBI RESTO Slim Hammami 58 est un langage de programmation libre4 principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe quel langage interprété de façon locale. PHP est un langage impératif orienté- objet.13 o MySQL (My Structured Query Language) comme Système de Gestion de Bases de Données : Un serveur de bases de données stockeles données dans des tables séparées plutôt que de tout rassembler dans une seule table. Cela améliore la rapidité et la souplesse de l'ensemble. Les tables sont reliées par des relations définies, qui rendent possible la combinaison de données entre plusieurs tables durant une requête.14 o FileZilla pour héberger les fichiers dans le serveur distant : FileZilla Client (FileZilla) est un client FTP, FTPS et SFTP, développé sous la licence publique générale GNU. Il existe également un logiciel de serveur FTP du nom de FileZilla Server. FileZilla a été créé en 2001 par Tim Kosseet deux camarades d'études.15 o NotePad++ comme éditeur de texte pour les services web PHP : Notepad++ est un éditeur de texte générique codé en C++, qui intègre la coloration syntaxique de code source pour les langages et fichiers C, C++, Java, C#, XML, HTML, PHP, JavaScript, makefile , art ASCII, doxygen, .bat, MS fichier ini, ASP, Visual Basic/VBScript, SQL, Objective- C, CSS, Pascal, Perl, Python, R, MATLAB, Lua, TCL,Assembleur, Ruby, Lisp, Scheme, Properties, Diff, Smalltalk, PostScript et VHDL ainsi que pour tout autre langage informatique, car ce logiciel propose la possibilité de créer ses propres colorations syntaxiques pour un langage quelconque.16 13 Voir Références 14 Voir Références 15 Voir Références 16 Voir Références
  59. 59. MOBI RESTO Slim Hammami 59 Il s’agit d’une architecture client/serveur. Le "client" c’est l’application Androïd, le "serveur" c’est le service distant. On parle d’architecture 3-Tiers parce que le "serveur" est divisé en deux parties : une partie « logicielle » et une partie « base de données ». 4.2. Conception des classes : *Diagrammes d’activités : Le diagramme d’activités représente la répartition des rôles entre les acteurs et permet de décrire les activités d’un processus métier ou d’un processus support. Une activité peut mettre en jeu une ou plusieurs entités. Dans ce cas, elle fait appel à une opération de l’entité. Si l’entité fait partie du domaine d’étude, l’opération doit se retrouver sur le diagramme d’états- transitions de cette entité. Si l’entité ne fait pas partie du domaine d’étude, cela Figure 4-1 : Architecture 3-tiers de l’application
  60. 60. MOBI RESTO Slim Hammami 60 DEBUT [Refusé] Identification Interface psersonnels Sélectionner personnel Liste personnels Modifier personnel Enregistrement FIN [Non valide] [Valide] signifie que l’activité fait appel à un service d’un autre domaine. On doit retrouver cet appel sur le diagramme de collaboration entre domaines.17 17 Voir Références Figure 4-2 : Diagramme d’activités « modifier personnel »
  61. 61. MOBI RESTO Slim Hammami 61 [Validé] Identification [Refusé] Interface reservations Liste reservations Sélectionner reservation Supprimer reservation [Annulé] Enregistrement DEBUT FIN 4.3. Conception des schémas logiques et physique des données : 4.3.1. Construction du schéma logique des données brut : Personne (id_pers, pseudo, mot_pass, nom, prenom, tel_pers, adresse, mail_pers,description). Client (id_pers#, credit_fid). Personnel (id_pers#, dat_embauch, salair_journ). Commande (id_cmd, montant, dat_cmd, etat_cmd, id_clt#,id_serv#, num_tab). Facture (id_fact, id_cmd#). Table (num_tab, capacite, etat_disp). Reservation (id_res, date_res, heure_deb_res, heure_fin_res, num_tab#, id_client#) Categorie(id_cat, libelle_cat, cumul_pts). Article (id_art, designation_art , prix_unit, id_cat#). Matiere_prem(id_mat, designation_mat, prix_achat). Composant (id_mat #, id_art#, qte_cmp). Ligne_cmd (id_art#,id_cmd#, qte_cmd). Figure 4-3 : Diagramme d’activités « supprimer réservation »
  62. 62. MOBI RESTO Slim Hammami 62 4.3.2. Construction du schéma logique des données optimisé : Personne (id_pers, pseudo, mot_pass, nom, prenom, tel_pers, adresse, mail_pers,description). Client (id_pers#, credit_fid). Personnel (id_pers#, dat_embauch, salair_journ). Commande (id_cmd, montant, dat_cmd, etat_cmd, id_clt#, num_tab#). Facture (id_fact, id_cmd#). List_tab (num_tab, capacite, etat_disp). Reservation (id_res, date_res, heure_deb_res, heure_fin_res, num_tab#, id_client#) Categorie(id_cat, libelle_cat, cumul_pts). Article (id_art, designation_art , prix_unit, id_cat#). Matiere_prem(id_mat, designation_mat, prix_achat). Composant (id_mat #, id_art#, qte_cmp). Ligne_cmd (id_art#,id_cmd#, qte_cmd). 4.3.3. Construction du schéma physique des données : N ° Table Attribut Clé primaire Clé étrangère Type 1 Personne id_pers * NUMBER pseudo VARCHAR2 mot_pass VARCHAR2 nom VARCHAR2 prenom VARCHAR2 tel_pers NUMBER adresse VARCHAR2 mail_pers VARCHAR2 description VARCHAR2 2 Client id_pers * * NUMBER credit_fid NUMBER 3 Personnel id_pers * * NUMBER dat_embauch DATE salair_journ NUMBER Tableau 4-2 : Schéma physique de la base de données (partie 1)
  63. 63. MOBI RESTO Slim Hammami 63 N° Table Attribut Clé primaire Clé étrangère Type 4 Commande id_cmd * NUMBER montant NUMBER dat_cmd DATE etat_cmd BOOLEAN id_clt * NUMBER num_tab * NUMBER 5 Facture id_fact * NUMBER id_cmd * NUMBER 6 List_tab num_tab * NUMBER capacite NUMBER etat_disp BOOLEAN 7 Rerservation id_res * NUMBER date_res DATE heure_deb_res TIME heure_fin_res TIME num_tab * NUMBER id_client * NUMBER 8 Categorie id_cat * NUMBER libelle_cat VARCHAR2 cumul_pts NUMBER 9 Article id_art * NUMBER designation_art VARCHAR2 prix_unit NUMBER id_cat * NUMBER 10 Matiere_prem id_mat * NUMBER designation_mat VARCHAR2 prix_achat NUMBER 11 Composant id_mat * * NUMBER id_art * * NUMBER qte_cmp NUMBER 12 Ligne_cmd id_art * * NUMBER id_cmd * * NUMBER qte_cmd NUMBER Tableau 4-3 : Schéma physique de la base de données (partie 2)
  64. 64. MOBI RESTO Slim Hammami 64 4.3.4. Présentation des interfaces : Interface d’authentification A l’ouverture de notre application, la page d’authentification s’affiche. Dans cette interface, chaque utilisateur que ce soit le gérant, un client ou un serveur possède un propre pseudo et mot de passe à fin de le permettre d'accéder à sa session. Ou bien un nouvel utilisateur peut s’inscrire pour s’authentifier plus tard en tant qu’un client. Interface « Tableau de bord client » Si l’utilisateur authentifié est un client alors, cette interface s’affiche qui présente le tableau de bord client et qui permet de donner quelques privilèges à un client :
  65. 65. MOBI RESTO Slim Hammami 65 - Consulter le menu des articles disponibles et commander un ou plusieurs articles. - Réserver une table à une date et heure donnée. - D’accéder à son propre compte. - Se déconnecter de l’application. Interface « Gestion d’un compte client » Cette interface permet un client de gérer son propre compte : - Modifier ses informations personnelles. - Consulter son crédit fidélité.
  66. 66. MOBI RESTO Slim Hammami 66 Interface « Tableau de bord serveur » Si l’utilisateur authentifié est un serveur alors, cette interface s’affiche qui présente le tableau de bord serveur et qui permet de donner quelques privilèges à un serveur embauché dans ce restaurant : - Consulter le menu des articles disponibles et commander un ou plusieurs articles. - Passer une réservation client d’une table à une date et heure donnée. - Se déconnecter de l’application.
  67. 67. MOBI RESTO Slim Hammami 67 Interface « Tableau de bord gérant » Si l’utilisateur authentifié est un gérant alors, cette interface s’affiche qui présente le tableau de bord gérant et qui permet de donner quelques privilèges à un gérant: - Gérer les clients, les personnels, les articles, le stock, les réservations et les tables. - Consulter les statistiques. -Ajouter une catégorie produit. - Se déconnecter de l’application.
  68. 68. MOBI RESTO Slim Hammami 68 Interface « Ajouter une réservation client » Cette interface permet au gérant d’ajouter une réservation d’un client en introduisant les données nécessaires (pseudo du client, numéro de table, date de la réservation et l’heure de la réservation).
  69. 69. MOBI RESTO Slim Hammami 69
  70. 70. MOBI RESTO Slim Hammami 70 Conclusion générale L’objectif de ce projet est de concevoir et de développer une application Androïd pour la gestion d’un restaurant ou d’un salon de thé. La démarche que nous avons adoptée pour atteindre nos objectif consiste à étudier en premier lieu les besoins des différents intervenants sur notre système : les gérants, les personnels embauchés dans un restaurant ou un salon de thé aussi que quelques clients à l’aide d’un questionnaire. Egalement, nous avons effectué une étude critique sur le fonctionnement actuel de la majorité des restaurants et des salons de thé ayant une catégorie bien ciblé. En second lieu, nous étions amenés à modéliser toutes les fonctionnalités identifiées en se basant sur la modélisation UML (diagramme de flux des données, de cas d’utilisation, diagramme de séquence, diagramme d’état- transition, diagramme d’activité et diagramme de classe). En dernier lieu, nous avons implémenté les modules, la base de données, les spécifications techniques modélisées et les interfaces mobiles. Maintenant, l’application existante permet de faire les fonctionnalités suivantes : -Gérer les clients. -Gérer les personnels. -Gérer les articles. -Passer une commande. -Gérer les articles. -Gérer les réservations. -Consulter les statistiques. Comme perspective à ce travail, on propose de développer une version qui fonctionne sur d’autre systèmes d’exploitations mobiles tel que : -iOS de Apples’s. -Windows Phone de Microsoft. - BlackBerry OS de RIM's. -Tizen de Samsung…
  71. 71. MOBI RESTO Slim Hammami 71 Aussi que nous proposons le développement d’une application « Desktop » comme une version pour l’administrateur afin de mieux gérer l’application mobile.
  72. 72. MOBI RESTO Slim Hammami 72 Bibliographie o -‘Courde conception orienté objet des systèmes d’information’ « Mme Mounira BEN ABDALLAH 2013 - 2014» : (Assistante à la Faculté des Sciences Economique et de Gestion de Sfax) o UML 2 en action, P. Roques & F. Vallée, Eyrolles, 2002 Webographie o www.stackoverflow.com o www.facebook.com/groups/anroidtuto o www.commentcamarche.net o www.androidhive.info o www.wikihow.com o www.developpez.com o www.tutomobile.fr o www.enis-androidclub.tk o http://blog.rolandl.fr o http://stdioe.blogspot.com o www.tutorialspoint.com o http://answers.ros.org o https://github.com o http://www.phonesdevelopers.com
  73. 73. MOBI RESTO Slim Hammami 73 Références 2-‘Cour de conception orienté objet des systèmes d’information’ « Mme Mounira BEN ABDALLAH 2013 - 2014» : (Assistante à la Faculté des Sciences Economique et de Gestion de Sfax). 3- UML 2 en action De l’analyse des besoins à la conception 4e édition PascalRoques • Franck Vallée, 2002 4- http://fr.wikipedia.org/wiki/Diagramme_de_classes 5- http://fr.wikipedia.org/wiki/Diagramme_de_classes 6- http://fr.wikipedia.org/wiki/Diagramme_de_s%C3%A9quence 7- http://fr.wikipedia.org/wiki/Diagramme_de_s%C3%A9quence 8- http://www.techno-science.net/?onglet=glossaire&definition=7703 9- http://fr.wikipedia.org/wiki/%C3%89clipse 10- http://developer.android.com/tools/help/adt.html (Traduit par https://translate.google.com.tn) 11- http://fr.wikipedia.org/wiki/UML_(informatique) 12- http://fr.wikipedia.org/wiki/Rational_Rose 13- http://fr.wikipedia.org/wiki/PHP 14- http://www.futura-sciences.com/magazines/high-tech/infos/dico/d/internet- mysql-4640/ 15- http://fr.wikipedia.org/wiki/Filezilla 16- http://fr.wikipedia.org/wiki/Notepad++ 17- lomag-man.org
  74. 74. MOBI RESTO Slim Hammami 74 Annexe « Mobi-Resto » est un projet d’une application Androïd dansle domaine de la gestion des restaurants/salons de théqui nécessite des appareils mobiles (tablettes ou Smartphones) fonctionnant sur le système androïd. En parallèle, une application à la portée des clients afin de lancer leurs commandes ainsi qu’effectuer leurs réservations. +Quellessontlesétapesde passage d’unecommande dèsqu’unclientlapasse jusqu’àsonarrivée à la phase de préparation ?(merci de nousdonnerlesétapesavecprécision) ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..…………………………………………………………………… ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..…………………………………………………………………… + Est-ce que vousdisposezunsystème de gestionde votre restaurant/salonde thé (gestionde stock, gestionde commandes,gestion de personnel etc.…) ? ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..…………………………………………………………………… + Si non,désirez-vousavoirune application Androïd qui estàbase destablettesoudesSmartphones présentantune nouvelletechnologie facile àutiliseretplusperformantepourlagestionde votre restaurant/salonde thé ? ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..…………………………………………………………………… + Si oui,quelssontlespointsfaiblesde votre système,lesfonctionnalitésque vousdésirezavoirdans un nouvel système? ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..…………………………………………………………………… +Désirez-vousavoirunsystème de gestion de fidélité de vosclients? ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..…………………………………………………………………… + Est-ce que vousdésirezavoir « Mobi-Resto » comme un remplaçant de votre système courant (une nouvelle technologie plusfacile,plusrapideque l’applicationcourante)? ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..……………………………………………………………………

×