SlideShare une entreprise Scribd logo
1  sur  75
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
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
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.
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 ».
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
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
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
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
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
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.
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 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
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.
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é.
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».
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
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
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
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.
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 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é
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é
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é
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.
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.
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 ».
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.
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.
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.
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.
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.
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 :
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.
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.
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 ».
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.
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 ».
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 ».
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.
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.
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 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
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 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
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
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
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
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
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
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
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.
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
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»
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
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 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
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
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
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
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 »
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 »
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)
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)
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 :
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é.
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.
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.
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).
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
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…
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.
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
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
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?
………………………………………………………………………..………………………………………………………..…………………………
……………………………..………………………………………………………..……………………………………………………………………
MOBI RESTO Slim Hammami
75
+ Est-ce que vousdésirezavoir « Mobi-Resto » comme un remplaçant de votre système courant
(une nouvelle technologie plusfacile,plusrapideque l’applicationcourante)?
………………………………………………………………………..………………………………………………………..…………………………
……………………………..………………………………………………………..……………………………………………………………………

Contenu connexe

Tendances

gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
Oussama Yoshiki
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
Siwar GUEMRI
 

Tendances (20)

Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site Web
 
E-learning
E-learningE-learning
E-learning
 
Présentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobilePrésentation pfe Développement d'une application bancaire mobile
Présentation pfe Développement d'une application bancaire mobile
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Présentation PFE
Présentation PFEPrésentation PFE
Présentation PFE
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
 
Presentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskPresentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help desk
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
 
E-Front : Plateforme d’enseignement à distance
E-Front : Plateforme d’enseignement à distanceE-Front : Plateforme d’enseignement à distance
E-Front : Plateforme d’enseignement à distance
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats Conception et Réalisation d’une Plateforme Web de Gestion des achats
Conception et Réalisation d’une Plateforme Web de Gestion des achats
 
Etude d'une application de gestion d'une bibliothèque numérique
Etude d'une application de gestion d'une bibliothèque numérique Etude d'une application de gestion d'une bibliothèque numérique
Etude d'une application de gestion d'une bibliothèque numérique
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 

En vedette

Conception et refonte d'un site web : les bonnes pratiques
Conception et refonte d'un site web : les bonnes pratiquesConception et refonte d'un site web : les bonnes pratiques
Conception et refonte d'un site web : les bonnes pratiques
Tarn Tourisme
 
Gestion d’une agence de voyage routière (Blondel Seumo)
Gestion d’une  agence  de  voyage  routière (Blondel Seumo)Gestion d’une  agence  de  voyage  routière (Blondel Seumo)
Gestion d’une agence de voyage routière (Blondel Seumo)
Gantner Technologies
 
Amazon ppt
Amazon pptAmazon ppt
Amazon ppt
aftabssm
 

En vedette (20)

E commerce 2012
E commerce 2012E commerce 2012
E commerce 2012
 
Cergeco informatique de gestion
Cergeco informatique de gestionCergeco informatique de gestion
Cergeco informatique de gestion
 
Ttechwebvideo
TtechwebvideoTtechwebvideo
Ttechwebvideo
 
What's the big deal about big data 1 30-2015
What's the big deal      about big data 1 30-2015What's the big deal      about big data 1 30-2015
What's the big deal about big data 1 30-2015
 
La sécurité toujours en éveil au cœur du processeur avec Intel et McAfee
La sécurité toujours en éveil au cœur du processeur avec Intel et McAfee La sécurité toujours en éveil au cœur du processeur avec Intel et McAfee
La sécurité toujours en éveil au cœur du processeur avec Intel et McAfee
 
Track 2 - Atelier 2 - Introduction à redshift
Track 2 - Atelier 2 - Introduction à redshiftTrack 2 - Atelier 2 - Introduction à redshift
Track 2 - Atelier 2 - Introduction à redshift
 
Conception et refonte d'un site web : les bonnes pratiques
Conception et refonte d'un site web : les bonnes pratiquesConception et refonte d'un site web : les bonnes pratiques
Conception et refonte d'un site web : les bonnes pratiques
 
Amazon.com analyse stratégique
Amazon.com analyse stratégiqueAmazon.com analyse stratégique
Amazon.com analyse stratégique
 
Sécurite Amazon Web Services
Sécurite Amazon Web ServicesSécurite Amazon Web Services
Sécurite Amazon Web Services
 
Rapport pfev7
Rapport pfev7Rapport pfev7
Rapport pfev7
 
Gestion d’une agence de voyage routière (Blondel Seumo)
Gestion d’une  agence  de  voyage  routière (Blondel Seumo)Gestion d’une  agence  de  voyage  routière (Blondel Seumo)
Gestion d’une agence de voyage routière (Blondel Seumo)
 
Pay Pal
Pay PalPay Pal
Pay Pal
 
Amazon by alex
Amazon by alexAmazon by alex
Amazon by alex
 
La Stratégie d'Amazon selon Jeff Bezos
La Stratégie d'Amazon selon Jeff BezosLa Stratégie d'Amazon selon Jeff Bezos
La Stratégie d'Amazon selon Jeff Bezos
 
Authentification Forte Openid Avec Certificat Software
Authentification Forte Openid Avec Certificat SoftwareAuthentification Forte Openid Avec Certificat Software
Authentification Forte Openid Avec Certificat Software
 
Sécurité des systèmes d'information
Sécurité des systèmes d'informationSécurité des systèmes d'information
Sécurité des systèmes d'information
 
Aryavrit travels inde voyage agences hotel booking services
Aryavrit travels inde voyage agences hotel booking servicesAryavrit travels inde voyage agences hotel booking services
Aryavrit travels inde voyage agences hotel booking services
 
Atelier numérique réservation en ligne
Atelier numérique réservation en ligne Atelier numérique réservation en ligne
Atelier numérique réservation en ligne
 
Amazon ppt
Amazon pptAmazon ppt
Amazon ppt
 
Cas amazon final
Cas amazon   finalCas amazon   final
Cas amazon final
 

Similaire à MEMOIRE DE STAGE

Effets du système de management de la sécurité de l'information sur la perfor...
Effets du système de management de la sécurité de l'information sur la perfor...Effets du système de management de la sécurité de l'information sur la perfor...
Effets du système de management de la sécurité de l'information sur la perfor...
Harold NGUEGANG
 
Gestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceGestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distance
ahmed oumezzine
 
Reconnaissance faciale
Reconnaissance facialeReconnaissance faciale
Reconnaissance faciale
Aymen Fodda
 

Similaire à MEMOIRE DE STAGE (20)

MISE EN PLACE D'UNE SOLUTION INFORMATIQUE ‘ ALSTOM _ ACCUEIL ’
MISE EN PLACE D'UNE SOLUTION INFORMATIQUE ‘ ALSTOM _ ACCUEIL ’MISE EN PLACE D'UNE SOLUTION INFORMATIQUE ‘ ALSTOM _ ACCUEIL ’
MISE EN PLACE D'UNE SOLUTION INFORMATIQUE ‘ ALSTOM _ ACCUEIL ’
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
 
MISE EN PLACE D’UNE Progressive Web App Pour la Gestion des Rapports d’Audit
MISE EN PLACE D’UNE Progressive Web App Pour la Gestion des Rapports d’AuditMISE EN PLACE D’UNE Progressive Web App Pour la Gestion des Rapports d’Audit
MISE EN PLACE D’UNE Progressive Web App Pour la Gestion des Rapports d’Audit
 
application-de-gestion-de-cong-zehouani-fatma-767_compress (1).pdf
application-de-gestion-de-cong-zehouani-fatma-767_compress (1).pdfapplication-de-gestion-de-cong-zehouani-fatma-767_compress (1).pdf
application-de-gestion-de-cong-zehouani-fatma-767_compress (1).pdf
 
MISE EN PLACE D’UNE application web E-commerce
MISE EN PLACE D’UNE application web E-commerceMISE EN PLACE D’UNE application web E-commerce
MISE EN PLACE D’UNE application web E-commerce
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
 
Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24
 
Mise en place d'une solution VOIP sécurisée
Mise en place d'une solution VOIP sécuriséeMise en place d'une solution VOIP sécurisée
Mise en place d'une solution VOIP sécurisée
 
ERP médical pour la TRANSTU : module de gestion pharmaceutiques
ERP médical pour la TRANSTU : module de gestion pharmaceutiquesERP médical pour la TRANSTU : module de gestion pharmaceutiques
ERP médical pour la TRANSTU : module de gestion pharmaceutiques
 
Effets du système de management de la sécurité de l'information sur la perfor...
Effets du système de management de la sécurité de l'information sur la perfor...Effets du système de management de la sécurité de l'information sur la perfor...
Effets du système de management de la sécurité de l'information sur la perfor...
 
Gestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distanceGestion d'erreurs et accès à distance
Gestion d'erreurs et accès à distance
 
Rapport de stage exchange
Rapport de stage exchangeRapport de stage exchange
Rapport de stage exchange
 
Marketing Information System Memoir Jsr Manga
Marketing Information System Memoir Jsr MangaMarketing Information System Memoir Jsr Manga
Marketing Information System Memoir Jsr Manga
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
Memoire version finale kenfack
Memoire version finale kenfackMemoire version finale kenfack
Memoire version finale kenfack
 
Reconnaissance faciale
Reconnaissance facialeReconnaissance faciale
Reconnaissance faciale
 
Rapport PFE : Cloud Insights
Rapport PFE : Cloud InsightsRapport PFE : Cloud Insights
Rapport PFE : Cloud Insights
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 
Mesure de la performance du SI de camtel nguimo hermann 5.0
Mesure de la performance du SI de camtel  nguimo hermann 5.0Mesure de la performance du SI de camtel  nguimo hermann 5.0
Mesure de la performance du SI de camtel nguimo hermann 5.0
 
Capitalisation et valorisation des acquis du projet d’appui à la structuratio...
Capitalisation et valorisation des acquis du projet d’appui à la structuratio...Capitalisation et valorisation des acquis du projet d’appui à la structuratio...
Capitalisation et valorisation des acquis du projet d’appui à la structuratio...
 

MEMOIRE DE STAGE

  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. MOBI RESTO Slim Hammami 11 Chapitre 1 : MODELISATION DU METIER
  • 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. 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. 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. 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. 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. 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. 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. 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. MOBI RESTO Slim Hammami 20 Chapitre 2: CAPTURE DES BESOINS
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. MOBI RESTO Slim Hammami 41 Chapitre 3: ANALYSE
  • 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. MOBI RESTO Slim Hammami 43 Figure 3-1 : Diagramme de classes
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. MOBI RESTO Slim Hammami 55 Chapitre 4: REALISATION
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. MOBI RESTO Slim Hammami 69
  • 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. 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. 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. 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. 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? ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..……………………………………………………………………
  • 75. MOBI RESTO Slim Hammami 75 + Est-ce que vousdésirezavoir « Mobi-Resto » comme un remplaçant de votre système courant (une nouvelle technologie plusfacile,plusrapideque l’applicationcourante)? ………………………………………………………………………..………………………………………………………..………………………… ……………………………..………………………………………………………..……………………………………………………………………