MEMOIRE DE STAGE

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

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
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
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
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
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
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
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
 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
Chapitre 1 :
MODELISATION DU METIER

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
*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
-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
*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
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
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
 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
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
Chapitre 2:
CAPTURE DES BESOINS

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
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
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
 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.
 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
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
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.
 Pré condition : L’acteur est authentifié.
 Post conditions : Une réservation est affichée, ajoutée, modifiée ou
supprimée.
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».
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.
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
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
*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
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
*Si non, il vérifie le champ date réservation : s’il s’agit d’une date invalide
*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
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.
 Objectif : Ce CU est utilisé pour le suivi des réservations.
 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.
Consulter la recette journalière
1-Le gérant demande d’accéder à l’interface « Statistiques ».
3-Le gérant choisit l’option « Recette ».
5-Le gérant choisit l’option recette journalière.
6-Le système affiche la recette journalière.
Consulter la recette de chaque serveur
1- Le gérant demande d’accéder à l’interface « Statistiques ».

29
3-Le gérant choisit l’option « Recette ».
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
3-Le gérant choisit l’option « Consultation du stock »
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
3-Le gérant choisit l’option « Consultation du stock »
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
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.
 Objectif : Ce CU est utilisé pour le suivi des personnels.

30
 Post conditions : Un personnel est ajouté, affiché, modifié ou supprimé.
Ajouter personnel
1-Le gérant demande d’accéder à l’interface « Personnel » et choisit l’option
« Ajouter ».
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.
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.
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 ».
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
Supprimer un personnel
1-L’exécution du scénario « Consulter les informations d’un personnel ».
3-Le système supprime le client.
Exceptions :
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.
 Objectif : Ce CU est utilisé pour le suivi des articles.
 Pré condition : le gérant est authentifié.
 Post conditions : Un article est ajouté, affiché, modifié ou supprimé.
Ajouter article
Ce CU débute quand le gérant se connecte sur l’application, le processus se
1-Le gérant demande d’accéder à l’interface « Article » et choisit l’option
« Ajouter ».
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.
l’exception1.
introduites.

32
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 ».
l’exception1.
Supprimer un article
1-L’exécution du scénario « Consulter les informations d’un article ».
3-Le système supprime l’article.
Exceptions :
2-Le système affiche « Article inexistant ».
Cas d’utilisation « Gérer le stock »
Identification :
 Titre : Gérer le stock.
 Objectif : Ce CU est utilisé pour le suivi du stock.
 Post conditions : Le stock est affiché, modifié ou un article est ajouté au
stock.

33
Afficher stock
Ce CU débute quand le gérant se connecte sur l’application, le processus se
1-Le gérant demande d’accéder à l’interface « Stock».
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.
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».
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.
l’exception1.
7-Si le système n’a exécuté aucune exception, alors il enregistre l’ajout.
Exceptions :
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
 Pré condition : Le cuisinier/bar-man est authentifié.
 Post conditions : L’état d’une commande est modifié.
Modifier état commande
Ce CU débute quand le cuisinier/bar-man se connecte sur l’application, le
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.
 Pré condition : Le serveur est authentifié.
 Post conditions : Un client est ajouté.
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
4-Le serveur introduit les informations du client (pseudo, nom, prénom, adresse,
profession, numéro téléphone) et valide l’ajout.
l’exception1, il vérifie la valeur du champ pseudo existe déjà dans la base de
introduites et retourne au formulaire « Ajouter réservation ».
Exceptions :
2-Le système affiche « pseudo existant ».
Cas d’utilisation « Gérer commande »
Identification :
 Titre : Gérer commande.
 Acteur : Serveur.
 Objectif : Ce CU est utilisé pour la manipulation des commandes.
 Pré condition : Le serveur est authentifié.
 Post conditions : Une commande est ajoutée, affichée, modifiée ou
supprimée.
Ajouter commande
Ce CU débute quand le serveur se connecte sur l’application, le processus se
1-Le gérant demande d’accéder à l’interface « Commande » et choisit l’option
« Ajouter ».
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
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 ».
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.
 Pré condition : L’acteur est déjà authentifié.
 Post conditions : La liste des produits disponibles est affichée.

37
Consulter les produits
Ce CU débute quand le serveur ou le client se connecte sur l’application, le
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.

 Pré condition : Le client est déjà authentifié.
 Post conditions : La commande est passée.
Passer commande
Ce CU débute quand le client man se connecte sur l’application, le processusse
1-Le client demande d’accéder à l’interface « Passer commande».
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
Cas d’utilisation « Consulter état commande »
Identification :
 Titre : Consulter état commande.
 Objectif : Ce CU est utilisé pour passer une commande à partir d’un
compte client.
 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é.
Passer commande
Ce CU débute quand le client man se connecte sur l’application, le processusse
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.
 Objectif : Ce CU est utilisé pour réserver une tables à une date donnée et
pendant un intervalle horaire définit.
 Pré condition : Le client est déjà authentifié.
 Post conditions : Une réservation est établie.
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
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.
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 :
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.
 Objectif : Ce CU est utilisé que le client crée son propre compte.
 Pré condition : rien.
 Post conditions : Un compte client est crée.
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
l’exception1, il vérifie la valeur du champ pseudo existe déjà dans la base de
introduites.
Exceptions :
2-Le système affiche « pseudo existant ».
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
Chapitre 3:
ANALYSE

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
Figure 3-1 : Diagramme de classes

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
dat_embauc La date d’embauche d’un personnel modifierSalaireJourn()
salair_journ Le salaire journalier d’un personnel
Classe : Client
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
Classe : Reservation
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
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
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
Commande

46
Classe : Article
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
qte_comp La quantité d’une matière première
dans un article
modifierQteComposant()
Classe : LigneCmd
qte_cmd La quantité commandée d’un article
dans une commande
modifierQteCmd()
Classe : Facture
id_fact L’identifiant d’une facture ajouterFacture()
consulterFacture()
Tableau 3-7 : Dictionnaire de données concernant la classe Article
Composant
Tableau3-9 : Dictionnaire de données concernantla classe LigneCmd
Tableau 3-10 : Dictionnaire de données concernant la classe Facture

47
Classe : MatierePremiere
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
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
MatierePremiere
Tableau3-12 : Dictionnaire de données concernantla classeCategorie

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
: 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
: 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
: 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
: 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
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
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
Chapitre 4:
REALISATION

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
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

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

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
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
Figure 4-2 : Diagramme d’activités « modifier personnel »

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
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
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
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
- 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
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.

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.

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).

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
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
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
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
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
+ Est-ce que vousdésirezavoir « Mobi-Resto » comme un remplaçant de votre système courant
(une nouvelle technologie plusfacile,plusrapideque l’applicationcourante)?
………………………………………………………………………..………………………………………………………..…………………………
……………………………..………………………………………………………..……………………………………………………………………

MEMOIRE DE STAGE

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à MEMOIRE DE STAGE

Similaire à MEMOIRE DE STAGE (20)

MEMOIRE DE STAGE