MEMOIRE DE STAGE

Faculté des Sciences Economiques et de GestionDépartement d’Informatique Appliquée à la Gestion

MEMOIRE DE STAGEPOUR 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é parSlim HAMMAMI

Encadré parMr Walid GARGOURI

JuryMr Omar HACHICHA: Président

Mme Monia LOULOU: ExaminateurMr Walid GARGOURI: Examinateur

Mr Amin DRIRA: Invité

Année universitaire2013/2014

MOBI RESTO Slim Hammami

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

2


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’adressent aussi à 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.

3


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

4


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émas logiques et physique des données :...................................................61

4.3.1. Construction du schéma logique des données brut :..........................................................61

5


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

6


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 collaboration informatisé.........................................................................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

7


Liste des tableaux

Tableau 1-1 : Echanges d’information entre les acteurs externes et le système de gestion de 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 concernant la classe Facture.................................................46

Tableau 3-11 : Dictionnaire de données concernant la classe MatierePremiere..................................47

Tableau 3-12 : Dictionnaire de données concernant la 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

8


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.

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

9


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.

10


11

Chapitre 1 :MODELISATION DU METIER


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 :

*produit simple : produits intégrés au stock et pouvant être vendus immédiatement ou utilisés pour la préparation d’autres recettes.1 Voir questionnaire Annexe page 74

12


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

-Tous les répondeurs au questionnaire, sont tenté disposer d’une application qui facilite et accélère le passage des commandes.

13


-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é. *La gestion de son compte personnel. *Le choix et la réservation d’une table.

14


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

15


Légende :

Numéro Désignation1 Consulter les produits disponibles2 Passer les commandes clients3 Vérifier les produits disponibles4 Consulter stock5 Consulter statistiques6 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

16

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


diagramme permet de décrire en général le métier et non le système informatique.

2

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).2 Voir Références

17

Figure 1-2 : Diagramme des cas d'utilisation métier


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

18


diagramme de cas d’utilisation métier ainsi que la description de chaque 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.

19


20

Chapitre 2:CAPTURE DES BESOINS


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

2.2. Modèle de contexte du système informatisé

21

Tableau 2-1 : Acteurs 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.13.Consulter / transférer les points de fidélité.

22

Figure 2- 2 : Diagramme de collaboration informatisé


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. Objectif : Ce CU est utilisé pour se connecter à l’application, et pour

assurer la sécurité des données.Description des scénarios :

3 Voir Références

23

Figure 2-3 : Diagramme des cas d'utilisation informatisé


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

24


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.

Exceptions :

1-Le système affiche « Champ obligatoire à saisir est vide ! » et retourne sur la saisie des informations.

25


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.


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

26


*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éservation1-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éservation1-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.

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

27


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

28


Consulter la liste des produits consommé par jour1-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ée1-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 jour1-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.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

29


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.


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

30


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.


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.

31


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 :

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

32


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

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

33


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

34


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

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.

35


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

36


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 processus se 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 ».

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

37


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 processus se 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 ».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.

38


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

39


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.

40


41

Chapitre 3:ANALYSE


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érences5 Voir Références

42

http://fr.wikipedia.org/wiki/Programme_informatique

http://fr.wikipedia.org/wiki/Programmation_objet

http://fr.wikipedia.org/wiki/Fonction_(informatique)

http://fr.wikipedia.org/wiki/Classe_(informatique)

http://fr.wikipedia.org/wiki/Dynamique

http://fr.wikipedia.org/wiki/Unified_modeling_language

http://fr.wikipedia.org/wiki/Statique

http://fr.wikipedia.org/wiki/Diagramme

http://fr.wikipedia.org/wiki/Interface_(informatique)

http://fr.wikipedia.org/wiki/Classe_(informatique)

Pers

onne

lda

t_em

bauc

sala

ir_jo

urn

mod

ifierS

alai

reJo

urn(

)

Pers

onne

id_p

ers

pseu

dom

ot_p

asse

nom

pren

omte

lad

ress

em

ail

desc

riptio

n

ajou

terP

erso

nne(

)co

nsul

terP

erso

nne(

)m

odifie

rPer

sonn

e()

supp

rimer

Pers

onne

()

Rese

rvatio

nid

_res

dat_

res

heur

_deb

_res

heur

_fin

_res

ajou

terR

eser

vatio

n()

mod

ifierR

eser

vatio

n()

cons

ulte

rRes

erva

tion(

)su

pprim

erRe

serva

tion(

)ch

ange

rEta

tRes

erva

tion(

)

Lign

eCm

dqt

e_cm

d

mod

ifierQ

teCm

d()

Com

posa

ntqt

e_co

mp

mod

ifierQ

teCo

mpo

sant

()

Cate

gorie

id_c

atlib

_cat

pts_

fid

ajou

terC

ateg

orie

()co

nsul

terC

ateg

orie

()m

odifie

rPts

Cate

gorie

()su

pprim

erCa

tego

rie()

Mat

iere

Prem

iere

id_m

atde

sign

atio

n_m

atpr

ix_a

chat

ajou

terM

atie

re()

cons

ulte

rMat

iere

()m

odifie

rMat

iere

()su

pprim

erM

atie

re()

Fact

ure

id_f

act

ajou

terF

actu

re()

cons

ulte

rFac

ture

()

Artic

leid

_art

desi

gnat

ion

prix

_uni

t

ajou

terA

rticl

e()

cosu

lterA

rticl

e()

mod

ifierA

rticl

e()

supp

rimer

Artic

le()

11.

.*

1..*

1..*

Clie

ntcr

edit_

fid

cons

ulte

rCre

dit()

augm

ente

rCre

dit()

retra

nche

rCre

dit()

Com

man

deid

_cm

dda

t_cm

dm

nt_c

md

etat

_cm

d

ajou

terC

omm

ande

()co

nsul

terC

omm

ande

()m

odifie

rCom

man

de()

chan

gerE

tatC

omm

ande

()

1

0..*

1

0..*

11

1..*

0..1

Tabl

enu

m_t

abca

paci

teet

at

ajou

terT

able

()m

odifie

rCap

acite

Tabl

e()

cons

ulte

rTab

le()

mod

ifierE

tatT

able

()su

pprim

erTa

ble(

)

0..*

0..*

0..*1

0..*

0..*

0..*

1

0..*

11

1

0..1

1..*

1..*

1

1..*

1..*

0..*1


3.1.3. Dictionnaire des données :

43

Figure 3-1 : Diagramme de classes


Classe : PersonneAttribut Désignation Méthodesid_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 : PersonnelAttribut Désignation Méthodesdat_embauc La date d’embauche d’un personnel modifierSalaireJourn()salair_journ Le salaire journalier d’un personnel

Classe : ClientAttribut Désignation Méthodes

credit_fid Le crédit de fidélité d’un clientconsulterCredit()augmenterCredit()retrancherCredit()

Classe : ReservationAttribut Désignation Méthodesid_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 de début d’une réservation

heur_fin_res L’heure de fin d’une réservation

44

Tableau 3-1 : Dictionnaire de données concernant la classe Personne

Tableau 3-2 : Dictionnaire de données concernant la classe Personnel


Classe : TableAttribut Désignation MéthodesNum_tab Le numéro d’une table ajouterTable()

modifierCapaciteTable()consulterTable()changerEtatTable()supprimerTable()

capacite La capacité d’une tableetat L’état de disponibilité d’une table à

la date système.

Classe : CommandeAttribut Désignation Méthodesid_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

Classe : ArticleAttribut Désignation Méthodesid_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

45

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


Classe : ComposantAttribut Désignation Méthodesqte_comp La quantité d’une matière première

dans un articlemodifierQteComposant()

Classe : LigneCmdAttribut Désignation Méthodesqte_cmd La quantité commandée d’un article

dans une commandemodifierQteCmd()

Classe : FactureAttribut Désignation Méthodesid_fact L’identifiant d’une facture ajouterFacture()

consulterFacture()

Classe : MatierePremiereAttribut Désignation Méthodesid_mat L’identifiant d’une matière

premièreajouterMatiere()consulterMatiere()modifierMatiere()supprimerMatiere()

designation_mat La désignation d’une matièreprix_achat Le prix d’achat d’une matière

première

46

Tableau 3-7 : Dictionnaire de données concernant la classe Article

Tableau 3-8 : Dictionnaire de données concernant la classe Composant

Tableau 3-9 : Dictionnaire de données concernant la classe LigneCmd

Tableau 3-10 : Dictionnaire de données concernant la classe Facture


Classe : CategorieAttribut Désignation Méthodesid_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

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 souci de simplification, on représente l'acteur principal à gauche du diagramme, et les

47

Tableau 3-11 : Dictionnaire de données concernant la classe MatierePremiere

Tableau 3-12 : Dictionnaire de données concernant la classe Categorie

http://fr.wikipedia.org/wiki/Diagramme_des_cas_d'utilisation

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


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 sont symbolisé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érences7 Voir Références

48

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


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.

49

Figure 3-2 : Diagramme de séquences pour un scénario d’authentification

: Gerant : Gerant : Interface personnels : Interface personnels : Personnel : Personnelp : 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")

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

50Figure 3-4 : Diagramme de séquences pour un scénario de

modification d’un personnel

Figure 3-3 : Diagramme de séquences pour un scénario d’ajout d’une réservation

: Gerant : Gerant : Interface statistiques : Interface statistiques : controlleur statistiques

: controlleur statistiques

: Commande : Commande

1: 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()



17: stat:=demandenfo(periodDeb,periodFin)

18: afficher(stat)


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.

51

: Gerant : Gerant : Interface statistiques : Interface statistiques : controlleur statistiques

: controlleur statistiques

: Commande : Commande



3: Afficher(options)

4: clic:=choisiroptions()

5: [clic=parServeur]demandeListeServeurs()

6: afficher(listeServeurs)

7: choisir(serveur)

8: recupererDonnee(serveur)

9: afficher("choisir periode")



12: stat:=demandenfo(serveur,periodDeb,periodFin)

13: afficher(stat)

14: [clic=totale]demandePeriode()



17: stat:=demandenfo(periodDeb,periodFin)

18: afficher(stat)

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

52

Figure 3-5 : Diagramme de séquences pour un scénario de consultation des statistiques

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

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éservationLe diagramme ci-dessous représente les changements d’état possible lorsque le gérant crée une nouvelle réservation client.

53

Figure 3-6 : Diagramme d’état transitions concernant «l’authentification»

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


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.

54

Figure 3-7 : Diagramme d’état transitions concernant l’ajout d’une réservation client


55

Chapitre 4:REALISATION


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éristiquesMarque HP Pavilion dv6000 Processeur AMD Athlon™ 64 X2 Dual-Core

Processor TK-57 1.90 GhzRAM 3GoDisque Dur 5OOGoEcran 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

56

Tableau 4-1 : Ressources matérielles utilisées

http://www.techno-science.net/glossaire-definition/Projet.html

http://www.techno-science.net/glossaire-definition/Environnement-de-developpement-integre.html

http://www.techno-science.net/glossaire-definition/Microsoft-Office.html

http://www.techno-science.net/glossaire-definition/Logiciel.html

http://www.techno-science.net/glossaire-definition/Microsoft-Word.html


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 Rose est 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 Rose permet également de sauvegarder et d'imprimer ces diagrammes, ainsi que de générer le code source 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érences10 Voir Références11 Voir Références12 Voir Références

57

http://fr.wikipedia.org/wiki/PHP:_Hypertext_Preprocessor

http://fr.wikipedia.org/wiki/C%2B%2B

http://fr.wikipedia.org/wiki/Java_(langage)

http://fr.wikipedia.org/wiki/G%C3%A9n%C3%A9ration_de_code_source

http://fr.wikipedia.org/wiki/IBM

http://fr.wikipedia.org/wiki/Unified_Modeling_Language

http://fr.wikipedia.org/wiki/Unified_Modeling_Language

http://fr.wikipedia.org/wiki/Logiciel

http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_objet

http://fr.wikipedia.org/wiki/D%C3%A9veloppement_logiciel

http://fr.wikipedia.org/wiki/Pictogramme

http://fr.wikipedia.org/wiki/Langage

http://fr.wikipedia.org/wiki/Informatique

http://www.techno-science.net/?onglet=glossaire&definition=11378


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 stocke les 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 Kosse et 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érences14 Voir Références15 Voir Références16 Voir Références

58

http://fr.wikipedia.org/wiki/VHDL

http://fr.wikipedia.org/wiki/PostScript

http://fr.wikipedia.org/wiki/Smalltalk

http://fr.wikipedia.org/wiki/Diff

http://fr.wikipedia.org/wiki/Scheme

http://fr.wikipedia.org/wiki/Lisp

http://fr.wikipedia.org/wiki/Ruby

http://fr.wikipedia.org/wiki/Assembleur

http://fr.wikipedia.org/wiki/Tool_Command_Language

http://fr.wikipedia.org/wiki/Lua

http://fr.wikipedia.org/wiki/MATLAB

http://fr.wikipedia.org/wiki/R_(logiciel)

http://fr.wikipedia.org/wiki/Python_(langage)

http://fr.wikipedia.org/wiki/Perl_(langage)

http://fr.wikipedia.org/wiki/Pascal_(langage)

http://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade

http://fr.wikipedia.org/wiki/Objective-C

http://fr.wikipedia.org/wiki/Structured_Query_Language

http://fr.wikipedia.org/wiki/VBScript

http://fr.wikipedia.org/wiki/Visual_Basic

http://fr.wikipedia.org/wiki/Visual_Basic

http://fr.wikipedia.org/wiki/Active_Server_Pages

http://fr.wikipedia.org/wiki/.bat

http://fr.wikipedia.org/wiki/Doxygen

http://fr.wikipedia.org/wiki/Art_ASCII

http://fr.wikipedia.org/wiki/Make

http://fr.wikipedia.org/wiki/Make

http://fr.wikipedia.org/wiki/JavaScript

http://fr.wikipedia.org/wiki/PHP

http://fr.wikipedia.org/wiki/Hypertext_Markup_Language

http://fr.wikipedia.org/wiki/Extensible_Markup_Language

http://fr.wikipedia.org/wiki/C_sharp

http://fr.wikipedia.org/wiki/Java_(langage)


http://fr.wikipedia.org/wiki/C_(langage)

http://fr.wikipedia.org/wiki/Langage_de_programmation

http://fr.wikipedia.org/wiki/Coloration_syntaxique


http://fr.wikipedia.org/wiki/%C3%89diteur_de_texte

http://fr.wikipedia.org/wiki/2001

http://fr.wikipedia.org/wiki/FileZilla_Server

http://fr.wikipedia.org/wiki/Client-serveur

http://fr.wikipedia.org/wiki/Licence_publique_g%C3%A9n%C3%A9rale_GNU

http://fr.wikipedia.org/wiki/SSH_file_transfer_protocol

http://fr.wikipedia.org/wiki/File_Transfer_Protocol_over_SSL

http://fr.wikipedia.org/wiki/File_Transfer_Protocol

http://fr.wikipedia.org/wiki/Client-serveur

http://fr.wikipedia.org/wiki/Programmation_imp%C3%A9rative

http://fr.wikipedia.org/wiki/Langage_interpr%C3%A9t%C3%A9_(informatique)

http://fr.wikipedia.org/wiki/Langage_interpr%C3%A9t%C3%A9_(informatique)

http://fr.wikipedia.org/wiki/Serveur_HTTP

http://fr.wikipedia.org/wiki/Page_Web_dynamique

http://fr.wikipedia.org/wiki/PHP#cite_note-fsfphplicense-4

http://fr.wikipedia.org/wiki/Logiciel_libre

http://fr.wikipedia.org/wiki/Langage_de_programmation


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

59

Figure 4-1 : Architecture 3-tiers de l’application

DEBUT

[Refusé]

Identification

Interface psersonnels

Sélectionner personnel

Liste personnels

Modifier personnel

Enregistrement FIN

[Non valide]

[Valide]

[Validé]

Identification

[Refusé]

Interface reservations

Liste reservations

Sélectionner reservation

Supprimer reservation

[Annulé]

Enregistrement

DEBUT

FIN


60

Figure 4-2 : Diagramme d’activités « modifier personnel »

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

61

Figure 4-3 : Diagramme d’activités « supprimer réservation »


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é

primaireClé étrangère

Type

1 Personne

id_pers * NUMBERpseudo VARCHAR2mot_pass VARCHAR2nom VARCHAR2prenom VARCHAR2tel_pers NUMBERadresse VARCHAR2mail_pers VARCHAR2description VARCHAR2

2 Client id_pers * * NUMBERcredit_fid NUMBER

3 Personnelid_pers * * NUMBERdat_embauch DATEsalair_journ NUMBER

N° Table Attribut Clé primaire

Clé étrangère

Type

id_cmd * NUMBERmontant NUMBERdat_cmd DATE

62

Tableau 4-2 : Schéma physique de la base de données (partie 1)


4 Commande etat_cmd BOOLEANid_clt * NUMBERnum_tab * NUMBER

5 Facture id_fact * NUMBERid_cmd * NUMBER

6 List_tabnum_tab * NUMBERcapacite NUMBERetat_disp BOOLEAN

7 Rerservation

id_res * NUMBERdate_res DATEheure_deb_res TIMEheure_fin_res TIMEnum_tab * NUMBERid_client * NUMBER

8 Categorieid_cat * NUMBERlibelle_cat VARCHAR2cumul_pts NUMBER

9 Articleid_art * NUMBERdesignation_art VARCHAR2prix_unit NUMBERid_cat * NUMBER

10 Matiere_premid_mat * NUMBERdesignation_mat VARCHAR2prix_achat NUMBER

11 Composantid_mat * * NUMBERid_art * * NUMBERqte_cmp NUMBER

12 Ligne_cmdid_art * * NUMBERid_cmd * * NUMBERqte_cmd NUMBER

4.3.4. Présentation des interfaces :

Interface d’authentification

63

Tableau 4-3 : Schéma physique de la base de données (partie 2)


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 :

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

64


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

65


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.

66


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.

67


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

68


69


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…

70

http://fr.wikipedia.org/wiki/Research_in_Motion

http://fr.wikipedia.org/wiki/BlackBerry_OS


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.

71


Bibliographieo -‘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)

o UML 2 en action, P. Roques & F. Vallée, Eyrolles, 2002

Webographieo 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

72


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 Pascal Roques • 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

73


Annexe« Mobi-Resto » est un projet d’une application Androïd dans le 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.

+Quelles sont les étapes de passage d’une commande dès qu’un client la passe jusqu’à son arrivée à la phase de préparation ? (merci de nous donner les étapes avec précision)

………………………………………………………………………..………………………………………………………..………………………………………………………..………………………………………………………..……………………………………………………………………………………………………………………………………………..………………………………………………………..………………………………………………………..………………………………………………………..……………………………………………………………………

+ Est-ce que vous disposez un système de gestion de votre restaurant /salon de thé (gestion de stock, gestion de commandes, gestion de personnel etc.…) ?

………………………………………………………………………..………………………………………………………..………………………………………………………..………………………………………………………..……………………………………………………………………

+ Si non, désirez-vous avoir une application Androïd qui est à base des tablettes ou des Smartphones présentant une nouvelle technologie facile à utiliser et plus performante pour la gestion de votre restaurant /salon de thé ?

………………………………………………………………………..………………………………………………………..………………………………………………………..………………………………………………………..……………………………………………………………………

+ Si oui, quels sont les points faibles de votre système, les fonctionnalités que vous désirez avoir dans un nouvel système ?

………………………………………………………………………..………………………………………………………..………………………………………………………..………………………………………………………..……………………………………………………………………

+Désirez-vous avoir un système de gestion de fidélité de vos clients ?

74


………………………………………………………………………..………………………………………………………..………………………………………………………..………………………………………………………..……………………………………………………………………

+ Est-ce que vous désirez avoir « Mobi-Resto » comme un remplaçant de votre système courant (une nouvelle technologie plus facile, plus rapide que l’application courante)?

………………………………………………………………………..………………………………………………………..………………………………………………………..………………………………………………………..……………………………………………………………………

75

Internet

MEMOIRE DE STAGE