1. Projet de Licence appliquée en
Informatique
Sciences et Technologies
N° d’ordre: 201?− ??nn
République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
Université de Sfax
Institut Supérieur d’Informatique
et de Multimédia de Sfax
PROJET
Présenté à
L’Institut Supérieur d’Informatique
Et de Multimédia de Sfax
En vue de l’obtention du diplôme de
LICENCE APPLIQUÉE
En Technologies de l’Informatique et du Multimédia
Intitulé
TITRE DU
PROJET
DE LICENCE
Par
Bilel Belwafi
Imen Soussi
Hatem Hadrich
Soutenu le ?? Juin 2013, devant le jury composé de :
M. Prénom NOM Président
M. Prénom NOM Membre
M. Abir KALLEL Encadreur
M. Prénom NOM Invité Entreprise
Année Universitaire : 2012-2013

2. Remerciement
Nous tenons à exprimer nos remerciements avec un grand plaisir et un grand
respect à notre encadreur Mme Abir Kallel pour ses conseils, sa disponibilité et ses
encouragements qui nous ont permis de réaliser ce travail dans les meilleures
conditions.
Nous exprimons de même notre gratitude envers tous ceux qui nous ont accordé leur
soutien, tant par leur gentillesse que par leur dévouement.
A tous les enseignants qui nous ont aidés pendant les trois ans passés à l’ISIMS.
A toute personne ayant contribué de près ou de loin à l’avancement de notre projet.
A nos trois familles et amis pour leur aides.
Nous ne pourrons nommer ici toutes les personnes qui nous ont aidés et encouragés
de près ou de loin et nous les remercions vivement.

3. Introduction générale :
Ayant atteindre la troisième année de licence en Informatique et Multimédia, un
projet de fin d’étude est demandé d’accomplir. Notre choix s’est rapporté à concevoir
et réaliser un produit logiciel.
Après de nombreuses recherches et demandes de stage, nous avons réussi à
obtenir l’accord des responsables de la société MTD Application. Nous nous
sommes amenés à réaliser une application gestion de vente.
Nous avons choisi nos outils d’une manière cohérente avec notre philosophie de
travail.
Ainsi, la gestion de vente constitue un processus clé pour nombreuses entreprises
engagées pour l’amélioration de leur service client, l’accélération des flux
administratifs et la réduction des risques.
L’automatisation de la gestion de vente forme la solution idéale à la mise en œuvre
rapide et maitrisée de la politique des ventes. Ces atouts lui permettent de s’adapter
au profil de l’entreprise en satisfaisant ses clients et respectant son organisation
interne.
L’application que nous développons permet de :
- Gérer les fournisseurs.
- Gérer les commandes clients.
- Gérer les tables.
- Gérer les règlements.
Enfin, le présent projet intitulé gestion de vente s’articule autour des trois
chapitres suivants:
- Le premier chapitre sera consacré à l’étude préalable , dans lequel nous
donnerons un aperçu sur les objectifs de l’application, une étude et une
critique de l’existant.
- Dans le deuxième chapitre, nous aborderons la conception de l’application en
étudiant la modélisation conceptuelle des données.
- Et dans le troisième chapitre, nous décrirons notre solution et nous testerons
ses fonctionnalités.
En effet, nous voulons que notre système soit ouvert, extensible, évolutif et
ergonomique tout en gardant son efficacité.

4. Chapitre I
ETUDE
PREALABLE

5. Introduction :
Ce chapitre consiste, en premier lieu, à examiner le recueil regroupant les parties qui
permettent de définir le champ de l’étude et le planning prévisionnel. Et en second
lieu, l’étude de l’existant regroupe les parties qui permettent d’analyser l’existant et
nous dégageons, ainsi, les critiques du système actuel afin de développer une
application de qualité dans le futur. Et enfin, nous décrivons les objectifs à atteindre
et les avantages de l’application.
Présentation de la société :
MTD group est un groupe de sociétés qui a vu le jour à l'aube du 21ème siècle, le 01
janvier 2000.
Conscient de l'importance de l'Internet il n'a cessé de croître et d'investir dans
l'apprentissage et la maîtrise des technologies les plus avancées.
Depuis plus de 7 ans le groupe s'est engagé dans une stratégie de croissance par la
création de filiales spécialisées dans différentes activités et technologies.
Il compte aujourd'hui 8 filiales qui opèrent dans des activités allant de la création des
sites au développement des applications mobile et à la production en 3D.
MTD Application l'une des société de MTD Group est une Société Tuniso-
Allemande spécialisé dans la conception et le développement des applications Web.
La société a développé divers applications tels que :
› Gestion des agences de location de véhicules
› Gestion des agences d’assurance
› Gestion Commerciale des points de vente
› Gestion des opticiens
› Gestion de suivie des projets et des personnels
› Gestion de déléguées médicales
› Gestion de production
› Gestion de briqueterie
› Gestion d’usine de menuiserie…
Etude de l’existant et formalisation des besoins :
Analyse de l’existant :
Dans cette phase, nous allons faire une analyse de l’existant pour dégager les
faiblesses du système et le critique de l’existant.
Pour comprendre l’existant et déceler ses dysfonctionnements, nous avons pu réunir
les points suivants :
• Manque d’informations pertinentes et rapides à chaque opération de vente.
• Absence d’une stratégie ou une démarche qui permet d’élucider le choix des
fournisseurs et la décision d’achat.
• Aucune tentative n’a été faite pour mener à bien une codification des articles
et leur classification par famille d’articles.
• Aucun mécanisme n’assure des analyses et des statistiques sur le processus
de vente.
Critique de l’existant :

6. Les clients aujourd’hui souffrent d’un retard au niveau de la réception ; ils sont
obligés parfois d’attendre beaucoup pour juste passer une commande.
Le gérant n’est pas satisfait de l’application qu’il l’utilise.
En général, les serveurs passent la commande du client par des paperasses qui
circulent manuellement, et ça peut engendrer un désordre.
On constate aussi un retard au niveau de la préparation de la commande de la part
du cuisinier.
Objectifs à atteindre :
• L'encaissement et la facturation sur le point de vente
• Le contrôle des stocks et la gestion des fiches techniques
• La production des données statistiques réelles et prévisionnelles
• La gestion des débiteurs et comptes clients
• Le transfert des données en comptabilité
• Minimiser le temps de préparation de la commande.
• Gérer les réservations plus efficacement
• Une gestion moderne et individualisée
• Gérer les ventes en attente.
Avantages de l’application :
 Consulter le menu, commander et payer représentent les fonctionnalités
principales de cette application. Quant aux restaurateurs qui adoptent le
produit, ils bénéficient d'une fonction de vente incitative et de statistiques.
 Cette application est un menu intégralement illustré, permettant de voir des
photos et descriptions de chaque plat et dont l'interactivité offre de
nombreuses options supplémentaires, commodes pour les clients et
avantageuses pour les restaurateurs.
 Le menu et la commande dynamiques améliorent l'expérience du
consommateur
 Une tablette qui remplace le serveur
 Développer de manière très saine, à partir d'une conception UML entre
autres. C’est une application techniquement très au point, qui est développée
"sur pilotis" non comme d'autres applications.
 Configuration en multi-langue
 Définir des droits d'accès précis.
 Affichage du total à payer sur l’interface (coté client).

7. Planning prévisionnel
Notre travail a débuté par une étude théorique afin de mieux comprendre les
différents aspects fonctionnels du sujet qui nous a été proposé. Cette phase a été
suivie d’une analyse et une spécification des besoins fonctionnels de notre
système avant d’aborder la phase de conception pour passer finalement à la
réalisation.
Description des besoins fonctionnels pour l’application web de gestion des salons de thé
et des restaurants
Gestion des employés
• Pointage (entrée et sortie)
• Accès par code, badge ou code à barre
• Salaire et prime
• Offre et remise (café a moitie prix,…)
• Grade et droits d’accès
• Gestion des taches journalières
Gestion des tables
Cahier
des
charges
Analyse et conception
Ecriture du rapport
Réalisation
Etude
théorique
Février Mars Avril Mai

8. • Gestion de l’état de la table (libre, occupée, réservée)
• Gestion des réservations (nombre, tarif, période)
• Gestion de changement de table (extraire un nouveau ticket)
• Rappel ticket grâce au n° de table
Gestion des produits à servir
• Gestion famille et sous famille de produits
• Composition des menus avec des articles composés ou des articles liés.
• Gestion des tarifs (cout, marge) et des réductions (par période, par famille, par sous
famille ou par produit)
• Gestion de la présentation du produit servi au restaurant ou à emporter (tasse, sous-
tasse, gobelet…)
• Gestion de la spécificité du produit (sans sucre, bien sucré, sans sel,…)
• Temps de préparation nécessaire
Gestion des matières première et des équipements
• Gestion des fournisseurs
• Gestion du stock
• Gestion des achats
• Gestion des pertes
• Gestion des pannes machines (durée, frais de réparation)
• Amortissement des équipements
Suivi des clients
• Gestion des cartes de fidélité par point
• Gestion des remises
• Historique de la fidélité par client (tickets, gains)
• Gestion des réclamations
Gestion cuisine
• Réception des commandes

9. • Gestion des retards de préparation
• Gestion de retour des produits (perte + raison ou retour vers stock)
Gestion des événements
• Planification
• Gestion des coûts (animation, décoration, tickets, publicité,…) et des bénéfices
Caisse
• Paiement total et partiel des tickets
• Modes de règlement : carte bancaire, chèque, espèces, ticket restaurant
• Gestion des crédits
Conclusion :
Dans cette partie j’ai présenté une étude au préalable dans la quelle j’ai montré les
différents disfonctionnements des systèmes existants et j’ai essayé d’extraire des solutions.
A la suite de ce chapitre je vais présenter les différentes technologies et méthodologies
que j’ai utilisées dans la réalisation du site web.
Chapitre II
Méthodologie
De Conception

10. Introduction :
La conception constitue une phase fondamentale dans le cycle de vie d’une
application. La réussite de ce dernier dépend de cette phase. L’un des soucis était
d’avoir une idée globale en avance de ce que nous devons programmer. Pour ce
faire, nous avons commencé par les diagrammes de cas d’utilisation qui permettent
de donner une vue globale de l’application. En deuxième lieu, nous allons présenter
les diagrammes de classe. Et enfin, nous finirons par la présentation chronologique
des opérations par les diagrammes de séquence.
Acteurs du système informatisé
Dans cette partie, nous allons identifier les différents acteurs de l’application en présentant
lesdifférents cas d’utilisationet diagrammes de séquences.
Acteurs
Un acteur est une personne extérieure au système en cours de modélisation. L’acteur peut
consulter ou modifier l’état du système. Les acteurs peuvent être classés, suivant les besoins
de notre système on peut présenter deux acteurs. Il s’agit d’un administrateur ou un
superuseretuncaissier.La manièred’accéderauxservicesde l’application pour l’un et pour
lesautresestlamême.Ladifférencerésidesurlesdroitsd’accèsetlesprivilègesde chacun.

11. Acteurs internes
• Le gérant : Il doit s’authentifier pour accéder à son interface sécurisé avec le code.
• Le caissier : C’est un employé qui possède un code lui permettant d’exécuter des
opérations de vente.
• Le serveur : C’est un employé qui possède un code lui permettant d’accéder à ses
tâches journalières.
Acteurs externes
• Un client : peut acheter un ou plusieurs produits.
Elaboration du modèle des cas d’utilisation :
Diagramme de cas d’utilisation :
Le but de ces diagrammes est d’avoir une vision globale sur les interfaces du futur
logiciel.
Présentation globale de cas d’utilisation :

13. Cas d’Utilisation : Gérer Achats
Objectif : Saisie, modification, suppression, impression, consultation, et recherche
d’un bon de commande.
Acteur : Gérant.
Flux d’évènements :
Flux normal : Ce cas d’utilisation débute quand le gérant se connecte sur le système
d’information après authentification pour effectuer les tâches suivantes :
 Saisie d’un bon de commande.
 Modification d’un bon de commande.
 Suppression d’un bon de commande.
 Consultation d’un bon de commande.
 Recherche d’un bon de commande.
Scénario 1 : Saisie d’un bon de commande
1. Le gérant demande au système de créer un nouveau bon de commande.
2. Le système lui affiche l’interface de saisie
3. Le gérant demande la liste des fournisseurs.
4. Le système affiche la liste de tous les fournisseurs.
5. Le gérant sélectionne le fournisseur en cas d’existence, si ce n’est pas le cas,
le gérant appelle le cas d’utilisation « Gérer Fournisseur ».
6. Le gérant demande au système la liste des articles.
7. Le système affiche la liste des articles.
8. Le gérant choisit les articles à commander.
9. Le gérant fait appel au cas d’utilisation « Consulter Stock » pour vérifier la
disponibilité de l’article choisi.
10.Le système calcule automatiquement : le total net HT, le total des taxes et le
montant en TTC et fournit la date de la commande.
11.Le gérant demande au système de valider les informations saisies.
12.Le système vérifie que toutes les données obligatoires sont saisies
correctement et enregistre le bon de commande (le système affecte un
numéro à cette commande).
Exceptions : Enchainements d’erreur
E1 : Aucun fournisseur choisi.
- L’enchainement E1 démarre au point 12 du scénario nominal.
- Le système affiche le message d’erreur suivant : « vous devez d’abord
sélectionner un fournisseur »
E2 : Commande vide.
- L’enchainement E2 démarre au point 12 du scénario nominal.

14. - Le système affiche l e message d’erreur suivant : « votre commande est vide».
E3 : Quantité invalide
- L’enchainement E3 démarre au point 12 du scénario nominal.
- Le système affiche le message d’erreur suivant : « la quantité à commander est
invalide ».
E4 : Produit non disponible
- L’enchainement E4 démarre au point 12 du scénario nominal.
- Le système affiche le message d’erreur suivant : « la quantité à commander est
non disponible. »
Scénario 2 : Modification d’un bon de commande
1. Le gérant demande au système de présenter la liste de toutes les commandes
saisies et non encore livrées.
2. Le système lui affiche la liste des commandes.
3. Le gérant sélectionne la commande en question et demande au système d’afficher
toutes les informations de cette commande.
4. Le système affiche les informations relatives à cette commande.
5. Le gérant procède à la modification des produits commandés.
Trois cas sont possibles :
Cas 1 : Ajout d’une nouvelle ligne :
- Le gérant demande au système de visualisé la liste de tous les produits par
catégories
- Le système affiche la liste des produits et demande au gérant de sélectionner le
produit en question
- Le gérant sélectionne un produit qui sera par la suite ajouté dans la liste des
produits commandés.
Cas 2 : Suppression d’une ligne :
- Le gérant sélectionne une ligne commande et demande au système de la
supprimer.
- Le système supprime la ligne.
Cas 3 : Modification de la quantité commandée d’un produit :
- Le gérant modifie la quantité commandée et demande au système d’enregistrer
la modification.
- Le système valide la modification.
6. Finalement le système recalcule de nouveau le total en HT, le total des taxes et le
montant TTC et valide la modification de la commande.
Exceptions : Enchainements d’erreur
E1 : bon de commande vide
- L’enchainement E1 démarre au point 6 du scénario nominal.
- Le système affiche le message d’erreur suivant : « votre commande est vide».

15. E2 : Quantité modifiée invalide.
- L’enchainement E2 démarre au point 6 du scénario nominal.
- Le système affiche le message d’erreur suivant : « la quantité à commander est
invalide. »
Scénario 3 : consultation d’un bon de commande
1. Le gérant demande au système de lister des différentes commandes.
2. Le système présente la liste des commandes.
3. Le gérant consulte la commande en question
Scénario 4 : suppression d’un bon de commande
1. Le gérant demande au système de présenter la liste de toutes les commandes.
2. Le système lui affiche la liste de commandes
3. Le gérant sélectionne la commande en question et demande au système de
supprimer.
4. Le système vérifie que la commande n’est pas encore livrée et demande au gérant
de confirmer la suppression (le système affiche le message suivant « voulez-vous
vraiment supprimer la commande ?»)
5. Le gérant confirme la suppression.
6. Le système supprime la commande et toutes ses lignes.
Exceptions : Enchainements d’erreur
E1 : Commande déjà livrée
- L’enchainement E1 démarre au point 4 du scénario nominal.
- Le système affiche le message d’erreur suivant : « suppression interdite :
Commande déjà livrée. »
Scénario 5 : Impression d’un bon de commande
1. Le gérant demande au système de consulter la liste des commandes.
2. Le système lui affiche la liste des commandes.
3. Le gérant sélectionne la commande en question et demande au système de
l’imprimer.
4. Le système imprime la commande.
Scénario 6: Recherche d’un bon de commande
1. Le gérant demande au système de rechercher une commande dans un
intervalle de date donnée.
2. Le système affiche l’interface de la recherche.
3. Le gérant saisit la date début, la date fin et demande au système d’afficher le
résultat de la recherche.
4. Le système vérifie la validité des dates et affiche le résultat de recherche
Exceptions : Enchainements d’erreur
E1 : date non saisie.
- L’enchainement E1 démarre au point 4 du scénario nominal.
- Le système affiche le message d’erreur suivant : « veuillez indiquer la date de
commande. »
E2 : date invalide.
- L’enchainement E2 démarre au point 4 du scénario nominal.

16. - Le système affiche le message d’erreur suivant : « date invalide. »
E3 : date début supérieur à la date fin
- L’enchainement E3 démarre au point 4 du scénario nominal.
- Le système affiche le message d’erreur suivant : « la date début doit être
inférieur ou égal à la date fin. »
CAS D’UTILISATIONS : GERER FOURNISSEURS
Objectif : création, modification, suppression, impression et recherche d’un
fournisseur.
Acteurs : gérant
Flux d’événements :
Flux normal : ce cas d’utilisation débute quand le gérant se branche sur le systéme
d’information après authentification pour effectuer les tâches suivantes :
- Création d’un fournisseur.
- Recherche d’un fournisseur.
- Modification d’un fournisseur.
- Suppression d’un fournisseur.
- Impression d’un fournisseur.
Scénario1 : Création d’un nouveau fournisseur
1. Le gérant demande au système de créer un nouveau fournisseur.
2. Le système lui affiche l’interface de saisie et demande au gérant de saisir les
coordonnées du fournisseur.
3. Le gérant saisit toutes les informations du fournisseur : le nom, la civilité,
l’adresse, le code postal, la ville, la matricule fiscale, le numéro de téléphone,
le numéro de fax et l’adresse E-mail. Puis, il demande au système de valider
les informations saisies.
4. Le système vérifie que toutes les données obligatoires sont saisies
correctement, fournit automatiquement un numéro à ce fournisseur et
enregistre les informations saisies.
Exceptions : Enchainements d’erreur
E1 : Nom invalide
- Le système affiche le message d’erreur suivant : « Le nom saisi est invalide ».
E2 : Adresse invalide
- Le système affiche le message d’erreur suivant : « L’adresse saisie est invalide ».
E3 : Code postal invalide
- Le système affiche le message d’erreur suivant : « Le code postal saisi est
invalide ».
E4 : Ville invalide
- Le système affiche le message d’erreur suivant : « La ville saisie est invalide ».

17. E5: Numéro de téléphone erroné
- Le système affiche le message d'erreur suivant: «il faut saisir correctement le
numéro de téléphone portable".
E6: Numéro de fax erroné
- Le système affiche le message d'erreur suivant: «il faut saisir correctement le
numéro de fax".
E7: Adresse Email erroné
- Le système affiche le message d'erreur suivant: «Adresse Email invalide".
E8: Fournisseur déjà existant
- Le système affiche le message d'erreur suivant: «Fournisseur déjà existant".
- Les enchainements d’E1 à E9 démarrent au point 4 du scénario nominal
Scénario2 : Recherche d'un fournisseur
1. Le gérant demande au système de rechercher un fournisseur.
2. Le système affiche l'interface de la recherche.
3. Le gérant saisit éventuellement les informations correspondantes et demande
au système de rechercher le fournisseur.
4. Le système vérifie l'existence de l'information à rechercher et affiche le
résultat de recherche.
Exceptions: Enchainement d'erreur
E1: Aucune information à rechercher
- L'enchainement E1 démarre au point du scénario normal.
- Le système affiche le message d'erreur suivant: «il faut indiquer au moins le nom
ou la ville du fournisseur".
Scénario 3: Modification d’un fournisseur
1. Le gérant demande au système de présenter la liste de tous les
fournisseurs.
2. Le système lui affiche la liste des fournisseurs et demande au gérant
de sélectionner le fournisseur à modifier.
3. Le gérant sélectionne le fournisseur en fournisseur en question et
procède à la modification.
4. Le système vérifie que la modification est correctement faite puis il
valide la modification
Exceptions: Enchainements d'erreur
E1 : Nom invalide
- Le système affiche le message d’erreur suivant : « Le nom saisi est invalide ».
E2 : Adresse invalide
- Le système affiche le message d’erreur suivant : « L’adresse saisie est invalide ».

18. E3 : Code postal invalide
- Le système affiche le message d’erreur suivant : « Le code postal saisi est
invalide ».
E4 : Ville invalide
- Le système affiche le message d’erreur suivant : « La ville saisie est invalide ».
E5: Numéro de téléphone erroné
- Le système affiche le message d'erreur suivant: «il faut saisir correctement le
numéro de téléphone portable".
E6: Numéro de fax erroné
- Le système affiche le message d'erreur suivant: «il faut saisir correctement le
numéro de fax".
E7: Adresse Email erroné
- Le système affiche le message d'erreur suivant: «Adresse Email invalide".
E8: Fournisseur déjà existant
- Le système affiche le message d'erreur suivant: «Fournisseur déjà existant".
- Les enchainements d’E1 à E9 démarrent au point 4 du scénario nominal
Scénario 4: Suppression d'un fournisseur
1. Le gérant demande au système de présenter la liste de tous les
fournisseurs.
2. Le système lui affiche la liste des fournisseurs.
3. Le gérant sélectionne le fournisseur à supprimer et demande au système
de la supprimer.
4. Le système vérifier que toutes ses commandes sont livrées et que toutes
ses factures sont complètement réglées et demande au gérant de
confirmer la suppression (le système affiche le message suivant : «voulez-
vous vraiment supprimer ce fournisseur?")
5. Le gérant confirme la suppression.
6. Le système supprime le fournisseur.
Exceptions: Enchainements d'erreur
E1:Le fournisseur a encore des factures des factures non réglées ou des
commandes non livrées
- L'enchainement E1 démarre au point 4 du scénario nominal.
- Le système affiche le message d'erreur suivant: «Suppression interdite :ce
fournisseur a encore des factures ou des commandes non réglées!".
Scénario 5: Impression de tous les fournisseurs.
1. Le gérant demande au système l’impression la liste des fournisseurs
2. Le système imprime la liste de fournisseurs.

19. CAS D'UTILISATION: GERER BONS DE LIVRAISON
Objectif: Saisie, consultation, annulation, impression et recherche d'un bon de
livraison.
Acteurs: gérant.
Flux d'événements:
Flux normal: ce cas d'utilisation débute quand le gérant sur le système d'information
après authentification pour effectuer les tâches suivantes:
- Saisie d'un bon de livraison.
- Consultation d'un bon de livraison.
- Annulation d'un bon de livraison.
- Impression d'un bon de livraison.
- Recherche d'un bon de livraison.
Scénario 1:Saisie d'un bon de livraison
1. Le gérant demande au système de créer un nouveau bon de livraison.
2. Le système lui affiche l'interface de saisie.
3. Le gérant demande au système de lister les différentes commandes
non encore livrées.
4. Le système affiche la liste des commandes demandées.
5. Le gérant choisit la commande à livrer.
6. Le système affiche toutes les informations de la commande
sélectionnée.
7. Le gérant choisit les produits à livrer au fournisseur, saisit la quantité à
livrer, choisit le mode de livraison et demande au système de valider
les informations saisies.
8. Le système vérifie que toutes les données obligatoires sont saisies
correctement, puis calcule automatiquement la remise à accorder au
fournisseur, le total net HT, le total des taxes et le net à payer TTC et
enregistre la livraison (le système fournit automatiquement un numéro
au bon de livraison).
Exceptions : Enchainements d’erreur
E1: Aucune commande choisie
- L’enchainement E1 démarre au point 7 du scénario nominal.
- Le système affiche le message d’erreur suivant : « Vous devez d’abord
sélectionner une commande ».
E2 : Quantité invalide
- L’enchainement E2 démarre au point 7 du scénario nominal.

20. - Le système affiche le message d’erreur suivant : « la quantité à livrer est
invalide ».
E3 : Quantité à livrer supérieur à celle en stock
- L’enchainement E3 démarre au point 7 du scénario nominal.
- Le système affiche le message d’erreur suivant : « La quantité en stock est
insuffisante ».
E4 : Bon de livraison vide
- L’enchainement E4 démarre au point 7 du scénario nominal.
- Le système affiche le message d’erreur suivant : « votre bon de livraison est
vide ».
Scénario 2 : Consultation d’un bon de livraison
1. Le gérant demande au système de lister les différentes livraisons.
2. Le système présente la liste des livraisons.
3. Le gérant sélectionne le bon de livraison et demande au système d’afficher
son contenu.
4. Le système affiche toutes les informations relatives au bon de livraison.
Scénario 3: Annulation d’un bon de livraison
1. Le gérant demande au système de présenter la liste de tous les bons de
livraison.
2. Le système lui affiche la liste des livraisons.
3. Le gérant sélectionne le bon de livraison et demande au système de l’annuler.
4. Le système vérifie que le bon de livraison n’est pas encore facturé et
demande au gérant de confirmer la suppression (le système affiche le
message suivant : « Voulez-vous vraiment supprimer le bon de livraison et
toutes ses lignes ? ».
5. Le gérant confirme la suppression.
6. Le système supprime toutes les lignes de la livraison, ainsi que la livraison
elle-même en mettant à jour le stock.
Exceptions : Enchainement d’erreur
E1 : Bon de livraison déjà facturé
- L’enchainement E1 démarre au point 4 du scénario nominal.
- Le système affiche le message d’erreur suivant : « Suppression interdite : Bon de
livraison déjà facturé ».
Scénario 4 : Impression d’un bon de livraison
1. Le gérant demande au système de consulter la liste des livraisons.
2. Le système imprime la liste des bons de livraison.

21. 3. Le gérant sélectionne le bon de livraison et demande au système de
l’imprimer.
4. Le système imprime le bon immédiatement.
Scénario 5 : Recherche d’un bon de livraison
1. Le gérant demande au système de rechercher un bon de livraison.
2. Le système lui affiche l’interface de la recherche.
3. Le gérant saisit la date début, la date fin et demande au système d’afficher le
résultat de la recherche.
4. Le système vérifie la validité des dates et affiche le résultat de recherche.
Exceptions : Enchainements d’erreur
E1 : Date non saisie
- L’enchainement E1 démarre au point 4 du scénario nominal.
- Le système affiche le message d’erreur : « Veuillez indiquer la date de livraison ».
E2 : Date invalide
- L’enchainement E2 démarre au point du scénario nominal.
- Le système affiche le message d’erreur suivant : « Veuillez indiquer la date de
livraison ».
E3 : Date supérieure à la date fin
- L’enchainement E3 démarre au point 4 du scénario nominal.
- Le système affiche le message d’erreur suivant : « La date début doit être
inférieure ou égale à la date fin ».
CAS D’UTILISATION : GERER ARTICLES
Objectif: Ajout, modification, suppression d’un article.
Acteurs: gérant.
Flux d'événements:
Flux normal: ce cas d'utilisation débute quand le gérant sur le système d'information
après authentification pour effectuer les tâches suivantes:
- Ajout d’un nouvel article.
- Modification d’un article.
- Suppression d’un article.
Scénario 1 : Ajout d’un nouvel article
1. Le gérant demande au système de créer un nouvel article
2. Le système lui affiche l’interface de saisie.

22. 3. Le gérant saisit toutes les informations suivantes : le nom, le type, la
désignation, la quantité et le point de vente.
4. Le gérant demande au système de valider les informations saisies.
5. Le système vérifie que toutes les données obligatoires sont saisies
correctement et valide l’ajout.
Exceptions : Enchainement d’erreur
E1 : Prix invalide
- L’enchainement E1 démarre au point 5 du scénario nominal.
- Le système affiche le message d’erreur suivant : « Prix invalide ».
E2 : Article existe déjà
- L’enchainement E2 démarre au point 5 du scénario nominal.
- Le système affiche le message d’erreur suivant : « Attention article existe déjà ».
Scénario 2 : Modifier un article
1. Le gérant demande au système de présenter la liste des articles.
2. Le système lui affiche la liste des articles et demande au gérant de
sélectionner l’article à modifier.
3. Le gérant sélectionne l’article en question et procède à la modification.
4. Le système vérifie que la modification est correctement faite puis il valide la
modification.
Exceptions :
E1 : Article existe dans une commande, une facture ou un bon de livraison
- L’enchainement E1 démarre au point 4 du scénario nominal.
- Le système affiche le message d’erreur suivant : « Modification interdite ».
Scénario 3 : Supprimer un article
1. Le gérant demande au système de présenter la liste des articles.
2. Le système lui affiche la liste des articles.
3. Le gérant sélectionne un article et demande au système de le supprimer.
4. Le système vérifie que la quantité en stock de ce produit est égale à zéro et
que ce dernier n’existe pas dans une commande et demande au gérant de
confirmer sa suppression. (Le système affiche le message suivant : « voulez
vous vraiment supprimer cet article ? »).
5. Le gérant confirme la suppression.
6. Le système supprime l’article.
Exceptions :

23. E1 : Article ayant une quantité en stock supérieure à zéro ou bien existe dans une
commande, une facture ou un bon de livraison
- L’enchainement E1 démarre au point 4 du scénario nominal.
- Le système affiche le message d’erreur suivant : « Suppression interdite ».
Diagramme de cas d’utilisation (client):
CAS D’UTILISATION : LANCER COMMANDE
Acteur : Client
Scénario : Commande Produit
1. Le client choisit les produits à commander et valide la commande.
2. Le système affiche le message suivant : « Commande envoyée ».
3. Le système envoie la commande sur l’écran de caissier et de cuisinier (ou
deux tickets selon le paramétrage de l’application).
Exceptions : Enchainement d’erreur
E1 : Aucun produit choisi
Le système affiche le message d’erreur suivant : « Vous devez d’abord choisir un
produit ».
E2 : Tiroir vide
Le système affiche le message d’erreur suivant : « il n’y a plus de papiers ».

24. CAS D’UTILISATION : AUTHENTIFICATION
Acteurs:
Personnel (Gérant ou Employé)
Objectif:
Ce cas d’utilisation permet aux personnels de s’authentifier par leur login et leur mot de
passe.
Pré-conditions:
Le personnel doit s’authentifier.
Post-conditions:
Chaque personnel, déjà authentifié, selon son autorité (son statut) va être redirigé vers
son menu pour pouvoir interagir aux différents droits d’accès.
Scénario nominal:
1. Le personnel accède à l’application.
2. Le système affiche la page d’accueil pour s’authentifier.
3. Le personnel saisit son login et son mot de passe.
4. Le personnel valide l’authentification.
5. Le système vérifie les données saisies.

25. 6. Le personnel est authentifié et redirigé vers son menu.
Exceptions:
E1 : Authentification invalide
- L’enchainement E1 démarre au point 4 du scénario nominal.
- Si le personnel ne valide pas l’authentification, il ne peut pas accéder à
l’application.
E2 : Login erroné
- L’enchainement E2 démarre au point 5 du scénario nominal.
- Si le système ne connait pas le personnel ou le personnel saisit des données
erronées, l’interface affiche le message : « Erreur : Login invalide !!!» (Retour au
point 3 du scénario nominal).
CAS D’UTILISATION : GERER REGLEMENTS
Objectif : Ce cas d’utilisation permet la saisie et la consultation d’un paiement.
Acteur : Caissier, Gérant
Scénario nominal : Saisi d’un payement
Le système affiche l’interface de règlement selon le mode de règlement choisi. Trois
cas peuvent se présenter :
Cas 1 : Règlement par espèce
1. Le caissier saisit le montant et demande de valider le paiement.
2. Le système vérifie que toutes les données obligatoires sont présentes et
valide le paiement.
Exceptions : Enchainement d’erreur
E1 : Aucun ticket choisi
- Le système affiche le message d’erreur suivant : «vous devez choisir un ticket ».
Cas 2 : Règlement par chèque
1. Le caissier saisit le numéro de chèque, la date d’échéance et demande au
système de valider le paiement.
2. Le système vérifie que toutes les données obligatoires sont saisies
correctement et valide le paiement.
Exceptions : Enchainement d’erreur
E1 : Date d’échéance invalide

26. - Le système affiche le message d’erreur suivant : «Date d’échéance invalide ».
Cas 3 : Règlement par carte
1. Le caissier demande au système de convertir les points de fidélité.
2. Le système convertit les points et vérifie que le montant est suffisant et valide
le paiement.
Exceptions : Enchainement d’erreur
E1 : Points de fidélité insuffisante
- Le système affiche le message d’erreur suivant : «Les points de fidélité sont
insuffisantes ».

27. Chapitre III
ANALYSE

28. ANALYSE ARCHITECTURALE
Diagramme de package : (deux couches)
Gestion de Stock : (Achat)
En cas de manque de stock, le gérant s’approvisionne avec un bon de commande
chez l’un des fournisseurs. Chaque bon de commande est composé de plusieurs
lignes commandes. Les marchandises arrivent avec un bon de livraison de côté
fournisseur. De même chaque bon de livraison est composé de plusieurs lignes
livraisons.
Après chaque entrée ou sortie des articles, l’état du stock doit être modifié. Au cas
où, nous avons une diminution accidentelle du stock (perte, casse, …), le gérant doit
indiquer la quantité perdue.

29. Gestion Commerciale : (Vente)
La réception d’une commande d’une telle table, fait synchroniser le processus de
gestion commerciale. En effet, le cuisinier prépare les produits demandés.
Après la préparation de la commande, le caissier établit un ticket contenant tous les
détails de la commande

31. Diagramme de classe : (Domaine)

32. Diagramme de séquence :
Après la description de quelques cas d’utilisation, on va présenter les diagrammes
de séquence relatifs à ces cas d’utilisation.
Un diagramme de séquence est un diagramme qui explique l’enchaînement entre
un acteur (utilisateur) et le système (machine).
Authentification :
Lorsque le gérant demande l'accès à l'application, il doit tout d'abord s'identifier par
son code. S'il est accepté, donc il y'aura l'accès à l’application. Sinon, le serveur
d'application lui retourne à la page d’accueil en affichant un message de refus.

33. Ajout Employé :
Diagramme d'activité permet de modéliser un processus interactif,
global ou partiel pour un system donnée (logiciel, system
d'information). Il est recommandable pour exprimé une dimension
temporelle sur une partie du model, à partir du diagramme de class ou
de cas d'utilisation.
le digramme d'activité est une représentation proche de l'organigramme;
la description d'un cas d'utilisation par un diagramme d'activité
correspond à ça traduction algorithmique. Une activité est l'exécution
d'une partie du cas d'utilisation, elle est représentée par un
rectangle aux bords arrondis.

34. Authentification :

35. Commande :
Session :

37. Dictionnaire apuré des données
Suite à l’analyse des documents et après épuration des données déjà codifiées on a élaboré le
dictionnaire de données sans redondance, sans anonyme et sans polysémie :
Tableau 1 : Table Bon de commande
Attribut Désignation Type
ID L’identificateur d’une
commande
Entier
Num Numéro du bon de
commande
Texte
Date La date de commande Date
Id_fournisseur Clé étrangère du fournisseur Entier
Id_restaurant Clé étrangère de restaurant Entier
Tableau 2: Table Fournisseur
Attribut Désignation Type
ID L’identificateur d’une
entreprise
Entier
Nom fournisseur Le nom du fournisseur
(entreprise)
Texte
Responsable Texte
Adresse fournisseur L’adresse du fournisseur Texte
Tel Le téléphone du fournisseur Entier long
Fax fournisseur Identifie le fax du
fournisseur
Entier long
Code_postal Le code postal de
la ville où se situe
l’ entreprise
E-mail fournisseur Identifie l’E-mail d’un
fournisseur
Texte
Code_tva Désigne le code TVA
Ville la ville où se situe l’entreprise
Tableau 3: Table Article Composé
Attribut Désignation Type
ID L’identificateur de l’article Entier
Quantite La quantité de l’article
Unite L’unité de l’article
Id_produit Clé étrangère du produit Entier
Id_article_achete Clé étrangère de l’article
acheté
Entier

38. Tableau 4: Table Ligne Du Bon de commande
Attribut Désignation Type
ID L’identificateur d’une ligne
du bon commande
Entier
Quantite La quantité d’une ligne du
bon commande
Prix Le prix d’une ligne du bon
commande
Id_bon_commande Clé étrangère du bon de
commande
Entier
Id_article_achete Clé étrangère de l’article
acheté
Entier
Tableau 5: Table Bon de Livraison
Attribut Désignation Type
ID L’identificateur d’un bon de
livraison
Entier
Date La date de livraison de la
commande
Date
Id_facture Clé étrangère de facture Entier
Id_bon_commande Clé étrangère du bon de
commande
Entier
Id_restaurant Clé étrangère de restaurant Entier
Tableau 6: Table Ligne Du Bon de Livraison
Attribut Désignation Type
ID L’identificateur d’une ligne
du bon livraison
Entier
Quantite La quantité d’une ligne du
bon de livraison
Prix Le prix d’une ligne du bon de
livraison
Unite L’unité de l’article livré
Id_bon_livraison Clé étrangère du bon de
livraison
Entier
Id_article_achete Clé étrangère de l’article
acheté
Entier

39. Tableau 7: Table Carte
Attribut Désignation Type
ID L’identificateur d’une
entreprise
Entier
Nom_client Le nom du client fidèle Texte
Num Le numéro de la carte de
fidèlité
Chaine
CIN Le numéro de la carte
d’identité
Chaine
Tel Le téléphone du fournisseur Chaine
Nbr_point Identifie le nombre
de points
Entier
Cout La conversion des
points en monnaie
Réel
Description La description de la carte Texte
Id_point Clé étrangère de la table point Entier
Tableau 8: Table Charge
Attribut Désignation Type
ID L’identificateur d’une Charge Entier
Cout Le coût de la charge Entier
Période Période de charge Texte
Type Type de charge Texte
Id_règlement Clé étrangère de règlement Entier
Id_restaurant Clé étrangère de
restaurant
Entier
Tableau 9: Table Famille
Attribut Désignation Type
ID L’identificateur d’une
Famille
Entier
Nom Le nom de la famille Texte
Photo Chemin de photos Texte
Ordre Affichage Afficher les sous familles
dans un ordre précis
Entier
Description Description de Famille Texte

40. Id Réduction Clé étrangère de
réduction
Entier
Tableau 10: Table Facture
Attribut Désignation Type
ID L’identificateur d’une facture Entier
Réf Reference de facture Texte
Prix total Prix total de facture Réel
Date paiement Date de paiement DateTime
Date facture Date facture DateTime
Id règlement Clé étrangère de
règlement
Entier
Tableau 11: Table Evènement
Attribut Désignation Type
ID L’identificateur d’une
Evènement
Entier
Date Date d’Evènement Date
Prix Prix d’Evènement float
Description Description d’Evènement Texte
Tableau 12: Table Option
Attribut Désignation Type
ID L’identificateur d’option Entier
Nom Le nom du Option Texte
Description Description d’Option Texte
Id produit Clé étrangère de Produit Entier

41. Tableau 13: Table Perte
Attribut Désignation Type
ID L’identificateur d’une
Perte
Entier
Quantite Quantité de Perte Réel
Unite Unité Perte Texte
Description Description de Perte Texte
Id_ligne_stock Clé étrangère de ligne de
stocke
Entier
Tableau 14: Table Mode Règlement
Attribut Désignation Type
ID L’identificateur d’une Mode
Règlement
Entier
Type Type de Mode Règlement Texte
Description Description de Mode
Règlement
Texte
Tableau 15: Table Pièce
Attribut Désignation Type
ID L’identificateur d’une
Pièce
Entier
Propriétaire Propriétaire de Pièce Texte
Num Numéro de Pièce Entier
Date_echeance Date d’échéance Date
Banque Le Banque où appartient le
propriétaire du chèque
Texte
Id_devise Clé étrangère de
devise
Entier
Id_reglement Clé étrangère de
Règlement
Entier

42. Tableau 16: Table Pointage
Attribut Désignation Type
ID L’identificateur d’une
Pointage
Entier
Type Type de Pointage Texte
Date_pointage Date de Pointage DateTime
Id_employe Clé étrangère d’Employé Entier
Tableau 17: Table journalière
Attribut Désignation Type
ID L’identificateur de journalière Entier
Nom_journalière Le nom de journalière Texte
Réclamation Réclamation de journalière Texte
Periode Période de journalière Date
Description Description de journalière Texte
Id_grade Clé étrangère de grade Entier
Tableau 18: Table Produit Lié
Attribut Désignation Type
Id_produit L’identificateur de table
produit Lié et Clé étrangère de
Table Produit
Entier
Id_article_achete L’identificateur de table
produit Lié et Clé étrangère de
Table Article Acheté
Entier
Tableau 19: Table Ticket
Attribut Désignation Type
ID L’identificateur d’un ticket Entier
Numéro Le numéro de ticket Entier
Date Date de la création ticket DateTime

43. Prix total Le prix total d’un ticket Réel
Description Quelque information sur le
ticket
Texte
Id_restaurant Clé étrangère du
restaurant
Entier
Id_reglement Clé étrangère pour
faire un règlement
sur le ticket
Entier
Id_table Clé étrangère de la table Entier
Id_carte Clé étrangère de la carte Entier
Id_employe Clé étrangère du l’employé Entier
Tableau 20: Table Sous famille
Attribut Désignation Type
ID L’identificateur d’un sous
famille
Entier
Nom_sous_famille Le nom d’un sous famille Texte
Ordre_affichage Afficher les sous familles
dans un ordre précis
Entier
Description Description pour un sous
famille
Texte
Id_famille Clé étrangère d’une famille Entier
Id_reduction Clé étrangère de réduction Entier
Tableau 21: Table Restaurant
Attribut Désignation Type
ID L’identificateur d’une
restaurant
Entier
Nom_restaurant Le nom d’un restaurant Texte
Adresse L’adresse du restaurant Texte
Téléphone Le numéro de téléphone pour
un restaurant
Texte
Responsable Responsable du restaurant Texte
Code_TVA Code de Tax sur la
valeur ajoutée
Float
Fax Le Fax du
restaurant
Texte

44. Ville La ville où se trouve le
restaurant
Texte
Code_Postal Code postale de ville Entier
Description Information sur un restaurant Texte
Tableau 22: Table grade
Attribut Désignation Type
ID L’identificateur de grade Entier
Nom_grade Le nom de grade Texte
Prix_heure Prix de l’heure pour chaque
grade
Réel
Description Description de grade Texte
Tableau 23: Table Ligne_stock
Attribut Désignation Type
Id L’identificateur de la ligne de
stock
Entier
Delai_expiration Le délai d’expiration pour
une ligne de stock
Date
Unite L’unité de l’article Réel
Id_magasin_stock Clé étrangère d’un magasin de
stock
Entier
Id_ligne_bon_livraision Clé étrangère du bon de ligne
de bon livraison
Entier
Tableau 24: Table Magasin_stock
Attribut Désignation Type
Id L’identificateur de magasin
de stock
Entier
Nom Le nom de magasin de stock Texte
Adresse L’adresse de magasin de stock Texte
Description Description sur le magasin de
stock
Texte
Id_restaurant Clé étrangère du restaurant Entier

45. Tableau 25: Table Plan
Attribut Désignation Type
ID L’identificateur de plan Entier
Position X Position de plan sur X Réel
Position Y Position de plan sur Y Réel
Unite L’unité de chaque position de
plan
Texte
Specification La specification de plan Texte
Date Date de plan DateTime
Id_espace Clé étrangère de
l’espace
Entier
Tableau 26: Table Point
Attribut Désignation Type
Id L’identificateur de point Entier
Prix Prix de point Réel
Tableau 27: Table Produit
Attribut Désignation Type
ID L’identificateur d’un produit Entier
Nom_produit Le nom d’un produit Texte
Quantite Quantité de produit Réel
Marge Produit La valeur ajoutée par produit Réel
Prix Produit Le prix de produit Réel
Point_fidélité Le nombre de point
de fidélité pour
chaque produit
Entier
Ordre L’ordre d’affichage
de produit
Entier
Description Description de produit Texte
Id_sous_famille Clé étrangère de sous famille Entier
Id_restaurant Clé étrangère de restaurant Entier

46. Id reduction Clé étrangère de réduction Entier
Tableau 28: Table Réduction
Attribut Désignation Type
Id L’identificateur de réduction Entier
Valeur La valeur sur réduction Réel
Date_début La date de début de réduction Date
Date_fin La date de fin de réduction Date
Description Description de réduction Texte
Tableau 29: Table Réservation
Attribut Désignation Type
ID L’identificateur de réservation Entier
Nom_client Le nom de client Texte
Date La date de réservation Date
Date_max La date maximum pour
réservation
Date
Tarif Tarif sur réservation réel
Description Description de
réservation
Texte
Tableau 30: Table Table
Attribut Désignation Type
ID L’identificateur de table Entier
Num_table Le numéro de table Entier

47. Nombre place Le nombre de place pour
chaque table
Entier
Etat L’état de table Texte
Tarif Tarif sur table Réel
Description Description de
table
Texte
Id_plan Clé étrangère de plan Entier
Id_restaurant Clé étrangère de restaurant Entier
Tableau 31: Table détail ticket
Attribut Désignation Type
ID L’identificateur de détail
ticket
Entier
Quantité Quantité de produit Entier
Date Date de commande Date
Id_ticket Clé étrangère de ticket Entier
Id_produit Clé étrangère de produit Entier
Id_evenement Clé étrangère de l’évènement Entier
Id_reduction Clé étrangère de réduction Entier
Tableau 32: Table espace
Attribut Désignation Type
Id L’identificateur de l’espace Entier
Description Description de l’espace Texte
Tableau 33: Table article acheté
Attribut Désignation Type
ID L’identificateur de l’article
acheté
Entier
Nom_article Le nom de l’article Texte
Quantité Quantité de l’article acheté Réel
Quantite_alerte Quantité minimal de l’article
acheté
Réel
Unite Unité sur quantité de l’article
acheté
Texte

48. Type Type de l’article
acheté
Texte
Prix_achat Le prix d’achat de l’article
acheté
Réel
Désignation Désignation de l’article acheté Entier
Tableau 34: Table devise
Attribut Désignation Type
Id L’identificateur de devise Entier
Nom Nom de devise Texte
Tableau 35: Table droit
Attribut Désignation Type
ID L’identificateur de droit Entier
Nom_droit Le nom de droit Texte
Description Description de droit Texte
Tableau 36: Table Amortissement
Attribut Désignation Type
ID L’identificateur de
l’amortissement
Entier
Cout Cout sur amortissement Réel
Description Description de
l’amortissement
Texte
Id_article_achete Clé étrangère de l’article
acheté
Entier
Tableau 37: Table détail règlement
Attribut Désignation Type
Id_ticket Clé étrangère de ticket Entier
Id_règlement Clé étrangère de règlement
acheté
Entier

49. Tableau 38: Table acompte
Attribut Désignation Type
ID L’identificateur d’acompte Entier
Date Date d’acompte Date
Type Type d’acompte Texte
Montant Montant d’acompte Float
Description Description d’acompte Texte
Id_employe Clé étrangère de l’employé Entier
Construction du schéma logique des données
 Acces(#grade_id,#droit_id);
 Acomptes(id,date,type_fr,type_ar,type_ang,montant,description_fr,description_ar,des
cription_ang,#employe_id);
 Amortissements(id,cout,description_fr,description_ar,description_ar,description_ang,
#article_achte_id)
 Article_achetes(id,name_fr,name_ar,name_ang,quantite,quantit_alert,unit,type,prix_a
chat,designation_fr,designation_ar,designation_ang);
 Article_composes(id,quantite,unit,#produit_id,#article_achete_id);
 Bon_commandes(id,num,date,#fournisseur_id,#restaurant_id);
 Bon_commande_lignes(id,quantite,prix,#bon_commande_id,#article_achete_id);
 Bon_livraisons(id,date,#bon_commande_id,#facture_id,#restaurant_id);
 Bon_livraison_lignes(id,prix,quantite,unite,#bon_livraison_id,#article_achete_id);
 Cartes(id,num,name_client_fr,name_client_ar,name_client_ang,cin_client,tel_client,n
br_point,cout,description_fr,description_ar,description_ang,#point_id);
 Charges(id,cout,period_fr,period_ar,period_ang,type,#reglement_id,#restaurant_id);
 Detail_reglements(#ticket_id,#reglement_id);
 Detail_tickets(id,quantite,date,#ticket_id,#produit_id,#evenement_id);
 Devises(id,name);
 Droits(id,name_fr,name_ar,name_ang,description_fr,description_ar,description_ang);

50.  Employes(id,code_emp,cin_emp,name_fr,name_ar,name_ang,adresse_fr,adresse_ar,a
dresse_ang,ville_fr,ville_ar,ville_ang,num_tel,description_fr,description_ar,descriptio
n_ang,#grade_id,#tarif_id,#restauran_id);
 Espaces(id,description_fr,description_ar,description_ang);
 Evenements(id,datetime,prix,description_fr,description_ar,description_ang);
 Factures(id,ref_fr,ref_ar,ref_ang,prix_total,date_paiement,date_facture,#reglement_id
);
 Familles(id,name_fr,name_ar,name_ang,photo,ordre_affichage,description_fr,descript
ion_ar,description_ang,#reduction_id);
 Fournisseurs(id,name_fr,name_ar,name_ang,adresse_fr,adresse_ar,adresse_ang,tel,re
sponsable,email,code_tv,fax,ville_fr,ville_ar,ville_ang,code_postal);
 Grades(id,name_fr,name_ar,name_ang,prix_heur,description_fr,description_ar,descri
ption_ang);
 Journalieres(id,name_fr,name_ar,name_ang,reclamation_fr,reclamation_ar,reclamati
on_ar,reclamation_ang,periode,description_fr,description_ar,description_ang,#grade_i
d);
 Ligne_stocks(id,delai_expiration,unite,#magasin_stock_id,#bon_livraison_ligne_id);
 Magasin_stocks(id,name_fr,name_ar,name_ang,adresse_fr,adresse_ar,adresse_ang,de
scription_fr,description_ar,description_ang,#restaurant_id);
 Mode_reglements(id,type_fr,type_ar,type_ang,description_fr,description_ar,descripti
on_ang);
 Options(id,name_fr,name_ar,name_ang,description_fr,description_ar,description_ang
,#produit_id);
 Pertes(id,quantite,unite,description_fr,description_ar,description_ang,#ligne_stock_id
)
 Pieces(id,num,date,echeance,proprietaire_fr,proprietaire_ar,proprietaire_ang,bangue_f
r,bangue_ar,bangue_ang,#devise_id,#reglement_id);
 Plans(id,position_x,position_y,unite,specification_fr,specification_ar,specification_an
g,date,#espace_id);
 Pointages(id,name_fr,name_ar,name_ang,date_pointe,#employe_id);
 Point(id,prix);
 Produit_options(#produit_id,#option_id);

51.  Produits(id,name_fr,name_ar,name_ang,quantite,marge_prod,prix_prod,point,fidelite
,ordre,description_fr,description_ar,description_ang,#sous_famille_id,#restaurant_id,#
reduction_id);
 Produit lies (#produit_id,#article_achete_id);
 Réductions (id,valeurs,date_debut,date_fin);
 Règlements (id,montant,date);
 Reservations(id,nom_client_fr,nom_client_ar,nom_client_ang,date,date_max,tarif,de
scription_fr,description_ar,description_ang);
 Restaurant articles (#restaurant_id,#article_achete_id);
 Restaurant produits (#restaurant_id,#produit_id);
 Restaurants(id,name_fr,name_ar,name_ang,adresse_fr,adresse_ar,adresse_ang,tel,res
ponsable,code_tva,fax,ville_fr,ville_ar,ville_ang,code_postal,description_fr,descriptio
n_ar,description_ang);
 Sous familles (id,name_fr,name_ar,name_ang,order_affichage,description_fr,
description_ar, description_ang,#famille_id,#reduction_id);
 Tables(id,num,nbr_place,etat,tarif,description_fr,description_ar,description_ang,#plan
_id,#restaurant_id);
 Tarifs (id,date,tarif);
 Tickets (id,num,date,prix_total,description_fr,description_ar,description_ang,
#restaurant_id,#reglement_id,#table_id,#carte_id,#employe_id);
 Unites(id,name);
 Validations(id,date,desgnation_fr,designation_ar,designation_ang,#employe_id,#jour
naliere_id);
Conclusion :
Dans ce chapitre, nous avons étudié la conception de cette application. A ce
propos, nous avons adopté la méthode de conception UML pour l’élaboration des
diagrammes de cas d’utilisation, de classe et de séquence.
Dans ce qui suit, nous allons présenter la description des différentes interfaces
de l’application.

52. Chapitre IV
CONCEPTION
&
REALISATION

54. Introduction :
Une fois la partie de la conception achevée, tous les éléments nécessaires au
développement de l’application deviennent disponibles.
Ce chapitre sera consacré à la phase de réalisation. La présentation de l’environnement
de réalisation fera l’objet de la première section. Une deuxième section sera consacrée
aux détails de réalisation et d’implémentation.
Environnement de travail
Nous allons consacrer cette section à la présentation des différents langages,
technologies et outils logiciels utilisés dans le cadre de ce projet.
Matériels
L’équipement utilisé pour ce projet est le suivant :
Tableau des caractéristiques du matériel de base
Technologies et langages
JavaScript
Le JavaScript est un langage de script incorporé dans un document HTML.
Historiquement il s'agit même du premier langage de script pour le Web. Ce langage est
un langage de programmation qui permet d'apporter des améliorations au langage
HTML en permettant d'exécuter des commandes du côté client, c'est-à-dire au niveau du
navigateur et non du serveur web.
HTML
L’Hypertext Markup Language, généralement abrégé HTML, est le format de
données conçu pour représenter les pages web. C’est un langage de balisage qui permet
d’écrire de l’hypertexte. HTML permet également de structurer sémantiquement et de
mettre en forme le contenu des pages, d’inclure des ressources multimédias dont des
images, des formulaires de saisie, et des éléments programmables tels que des applets. Il
permet de créer des documents interopérables avec des équipements très variés de
Micro-ordinateur Processeur Mémoire Disque dur
Sony Vaio série
VPCE
Core i3 4 Go Ram 320 Go
Dell inspiron 1720 Core i2 2 Go Ram 320 GO
Dell inspiron Core i3 4 Go Ram 500 GO

55. manière conforme aux exigences de l’accessibilité du web. Il est souvent utilisé
conjointement avec des langages de programmation (JavaScript) et des formats de
présentation (feuilles de style en cascade).
CakePHP :
CakePHP est un framework web libre écrit en PHP. Il suit le motif de
conception Modèle-Vue-Contrôleur. Aujourd'hui, la communauté se divise en multiples
branches ayant pour but la promotion du framework, la rédaction de manuels comme le
Cookbook1
permettant une prise en main rapide et facile de celui-ci. De plus la richesse
des blogs de développeurs, tutoriels sur le web et autres centres de développement
d'applications offrent une source d'information très appréciable.
CSS :
Le terme CSS est l'acronyme anglais de Cascading Style Sheets qui peut se traduire par
"feuilles de style en cascade". Le CSS est un langage informatique utilisé sur l'internet
pour mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi
appelé les fichiers CSS, comprennent du code qui permet de gérer le design d'une page
en HTML.
Eclipse et SDK Android
Eclipse est un environnement de développement intégré libre extensible, universel et
polyvalent, permettant de créer des projets de développement mettant en œuvre n'importe quel
langage de programmation. Dans notre projet, nous avons installé. L’environnement de
développement afin de nous adonner à la construction d'application pour Android. Nous avons
installé eclipse l'ide (environnement de développement intégré), le SDK d’Android (kit de
développement) ainsi que le plugin ADT (interface entre le SDK et eclipse). L’installation est
détaillée dans l'annexe.
JQuery :
JQuery est une bibliothèque JavaScript libre qui porte sur l'interaction entre JavaScript
(comprenant Ajax) et HTML, et a pour but de simplifier des commandes communes de
JavaScript.
AJAX :
AJAX : Asynchronous Javascript And Xml (AJAX) : il désigne un nouveau type de
conception de pages Web permettant l'actualisation de certaines données d'une page
sans procéder au rechargement total de cette page.
Cette méthode de conception repose sur la combinaison de technologies déjà existantes :
HTML/CSS, Javascript/DOM, XML et les requêtes HTTP, avec une demande réalisée
au serveur, en version dynamique.
SQL :

56. SQL (Structured Query Language, en français langage de requête structurée) est
un langage informatique normalisé servant à effectuer des opérations sur des bases de
données relationnelles. La partie langage de manipulation de données de SQL permet de
rechercher, d'ajouter, de modifier ou de supprimer des données dans les bases de
données relationnelles.
En plus du langage de manipulation de données, la partie langage de définition de
données permet de créer, et de modifier l'organisation des données dans la base de
données, la partie langage de contrôle de transaction permet de commencer et de
terminer des transactions, et la partie langage de contrôle de données permet d'autoriser
ou d'interdire l'accès à certaines données à certaines personnes.
Environnement logiciel :
Adobe Photoshop CS5
Pour les opérations de conception graphiques des interfaces, nous avons utilisé Adobe
Photoshop CS5 qui représente la référence en matière de création et de retouche
graphique pour l’impression et le web. Il a été utilisé pour créer l’aspect graphique des
interfaces ainsi que les éléments graphiques qu’ils les constituent.
Xampp :
XAMPP est un ensemble de logiciels permettant de mettre en place facilement
un serveur Web et un serveur FTP. Il s’agit d’une distribution de logiciels libres
(X Apache MySQL Perl PHP) offrant une bonne souplesse d’utilisation, réputée
pour son installation simple et rapide. Ainsi, il est à la portée d’un grand nombre
de personnes puisqu’il ne requiert pas de connaissances particulières et
fonctionne, de plus, sur les systèmes d’exploitation les plus répandus. Cette «
distribution » se chargera donc d’installer l’ensemble des outils dont vous
pourriez avoir besoin lors de la création d’un site Web. Plus d’une dizaine
d’utilitaires sont intégrés, comme MySQL, PHP, Perl ou encore PhpMyAdmin. Il
est distribué avec différentes bibliothèques logicielles qui élargissent la palette
des services de façon notable : OpenSSL, Expat (parseur XML), PNG, SQLite,
Zlib, … ainsi que différents modules Perl et Tom cat, FileZilla Server.

57. Netbeans :
Netbeans est un environnement de développement intégré (EDI), placé en open
source par Sun en juin 2000 sous licence CDDL et GPLv2 (Common
Development and Distribution License). En plus de Java, Netbeans permet
également de supporter différents autres langages, comme Python, C, C+
+, JavaScript, XML, Ruby, PHP et HTML. Il comprend toutes les
caractéristiques d'un IDE moderne (éditeur en couleur, projets multi-
langage, refactoring, éditeur graphique d'interfaces et de pages Web).
Conçu en Java, Netbeans est disponible
sous Windows, Linux, Solaris (sur x86 et SPARC), Mac OS X ou sous une
version indépendante des systèmes d'exploitation (requérant une machine
virtuelle Java). Un environnement Java Development Kit JDK est requis pour
les développements en Java.
Netbeans constitue par ailleurs une plateforme qui permet le développement
d'applications spécifiques (bibliothèque Swing (Java)). L'IDE Netbeans s'appuie
sur cette plateforme.
Word :
WORD est un logiciel de traitement de texte très performant qui nous permet de
créer un document. Ce document peut être une lettre, une étiquette, un dessin,
un tableau ou une enveloppe.
Ce logiciel permet aussi de faire une mise en page du document en utilisant les
différents outils disponibles tels que le formatage automatique, les bordures, la
pagination, etc. De plus, le correcteur d'orthographe et de grammaire, et le
dictionnaire des synonymes et antonymes sont d'autres outils qui aideront à
créer des documents bien écrits.
Star UML :
Star UML est un logiciel de modélisation UML, cédé comme open source par
son éditeur.
Sublime 2 du texte :
Sublime 2 du texte est l'un des plus rapides et les plus incroyables éditeurs de
code à être libérés dans un temps long! Avec un écosystème de la
communauté et le plugin aussi passionné que celui-ci, il pourrait bien être

58. impossible pour n'importe quel autre éditeur de rattraper son retard. Je vais
vous montrer mes trucs et astuces favorites aujourd'hui.
Sublime texte 2 est actuellement disponible pour toutes les plateformes
principales: OS X, Linux et Windows.
Rational Rose :
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.
Eclipse et SDK Android
Eclipse est un environnement de développent intégré libre extensible, universel
et polyvalent, permettant de créer des projets de développement mettant en
œuvre n’importe quel langage de programmation.
Dans notre projet, nous avons installé l’environnement de développement afin
de nous adonner à la construction d’application pour Android. Nous avons
installé Eclipse L’IDE (environnement intégré), le SDK d’Android (kit de
développement) ainsi que le plugin ADT (interface entre le SDK et Eclipse).
L’installation est détaillée dans l’annexe.
Nous l'avons vu, une application Web suit le principe d'une architecture client-serveur :
L'objectif de ce tutoriel étant de réaliser des applications Web en JEE, l'architecture de
nos solutions devra intégrer la notion de client-serveur et suivre le schéma suivant :
La couche appelée précédemment "interface utilisateur" est désormais remplacée par un
client Web, lié par Internet (ou un réseau local) aux autres modules présents, eux, sur un
serveur :

59. Architecture logicielle
Architecture 3-tiers et mise en place du modèle MVC
Une application web [URL2] possède souvent une architecture 3-tier :
 la couche dao s'occupe de l'accès aux données, le plus souvent des données
persistantes au sein d'un SGBD.
 la couche métier implémente les algorithmes "métier" de l'application. Cette couche
est indépendante de toute forme d'interface avec l'utilisateur. Ainsi elle doit être
utilisable aussi bien avec une interface console, une interface web, et une interface
de client riche. Elle doit ainsi pouvoir être testée en-dehors de l'interface web et
notamment avec une interface console. C'est généralement la couche la plus stable
de l'architecture. Elle ne change pas si on change l'interface utilisateur ou la façon
d'accéder aux données nécessaires au fonctionnement de l'application.

60.  la couche interface utilisateur qui est l'interface (graphique souvent) qui permet à
l'utilisateur de piloter l'application et d'en recevoir des informations.
 Les couches métier et DAO sont normalement utilisées via des interfaces Java. Ainsi
la couche métier ne connaît de la couche DAO que son (ou ses) interface(s) et ne
connaît pas les classes les implémentant. C'est ce qui assure l'indépendance des
couches entre-elles : changer l'implémentation de la couche DAO n'a aucune
incidence sur la couche métier tant qu'on ne touche pas à la définition de l'interface
de la couche DAO. Il en est de même entre les couches interface utilisateur et métier.
L'architecture MVC prend place dans la couche interface utilisateur lorsque
celle-ci est une interface web. La figure 1.3 illustre l’architecture 3-tiers et la
mise en place du MVC.
Figure 1.1 : Architecture 3-tiers et mise en place du MVC
Alors, Le traitement d'une demande d'un client se déroule selon les étapes
suivantes :
1. Le client fait une demande au contrôleur : celui-ci voit passer toutes les demandes
des clients. C'est la porte d'entrée de l'application. C'est le C de MVC.
2. Le contrôleur C traite cette demande : pour ce faire, il peut avoir besoin de l'aide
de la couche métier. Une fois la demande du client traitée, celle-ci peut appeler
diverses réponses. Un exemple classique est :
 une page d'erreurs si la demande n'a pu être traitée correctement.

61.  une page de confirmation sinon.
3. Le contrôleur choisit la réponse (une vue) à envoyer au client : choisir la réponse à
envoyer au client nécessite plusieurs étapes :
 choisir l'objet qui va générer la réponse : c'est ce qu'on appelle la vue V, le V de
MVC. Ce choix dépend en général du résultat de l'exécution de l'action
demandée par l'utilisateur.
 lui fournir les données dont il a besoin pour générer cette réponse. En effet,
celle-ci contient le plus souvent des informations calculées par le contrôleur.
Ces informations forment ce qu'on appelle le modèle M de la vue, le M de
MVC. L'étape 3 consiste donc en le choix d'une vue V et en la construction du
modèle M nécessaire à celle-ci.
4. Le contrôleur C demande à la vue choisie de s'afficher. Il s'agit le plus souvent de
faire exécuter une méthode particulière de la vue V chargée de générer la réponse
au client.
5. Le générateur de vue V utilise le modèle M préparé par le contrôleur C pour
initialiser les parties dynamiques de la réponse qu'il doit envoyer au client.
6. la réponse est envoyée au client. La forme exacte de celle-ci dépend du
générateur de vue. Ça peut être un flux HTML, PDF, Excel...
Android est basé sur le noyau Linux et utilise la plateforme java pour mes
applications.
L’architecture d’Android se compose cinq couches : le noyau Linux, les
bibliothèques, le moteur d’exécution Android, le cadre de l’application et la
couche d’applications [www02].
- Linux Kernel (Le noyau Linux) :
Android est basé sur le noyau Linux (2.6.24). Alors, il y a plusieurs avantages
comme grand mémoire, gestion de processus, modèle de sécurité, soutien de
bibliothèque partagé, etc. Il fournit les pilotes pour communiquer entre les
composants matériels et leurs logiciels. De plus il y a les parties d’augmentation
d’énergie comme la gestion [www02].

62. - Bibliothèque :
JSON (JavaScript Object Notation) : Est un format de données textuelles,
générique, dérivé de la notation des objets. Il permet de représenter de
l’informat ionstructurée.
- Moteur d’exécution d’Android (Android Runtime) :
Le moteur d’exécution d’Android se compose des bibliothèques niveau cœur et de
la machine virtuelle Dalvik [www02].
Linux Kernel
Display
Driver
Camera
Driver
Flash
Memory
Blinder(IPC)
Driver
Audio
Drivers
Key Pad
Driver
Power
Management
Wifi
Driver
Figure 2 : Le noyau Linux
Android Runtime
Core Libraries Dalvik Virtual Machine
Figure 3 : Le moteur d'exécution d'Android

63. - Cadre de l’application (Application Framework) :
Le cadre de l’application (Application Framework) fournit les principaux services
pour la plateforme Android [www05].
- Applications :
Ce sont les applications qui fonctionnent sous la plateforme Android comme : le
réveil, la calculatrice, le calendrier, la caméra, les contacts, etc. Toutes les
applications sont développées par Java et XML. Tous les composants d’Android
sont développés selon la technologie Open-Source [www06].
La plupart des applications se composent de plusieurs écrans. Chaque écran peut
être réalisé par activité. Si un nouvel écran s’ouvre, le système utilise une pile
d’histoire pour stocker les écrans précédents et pouvoir reprendre l’état précédent
ou l’enlever.
Application Framework
Activity Manager
View System Package Manager
Window manager Content Providers
Telephony Manager
Resource Manager Location Manager Notification Manager
Figure 4 : Le cadre de l'application
Applications
Réveil Contacts Calculatrice Caméra
Figure 5 : Les applications

64. - Cycle de vie d’une activité :

66. Nous devons donc connaître quand ces fameuses méthodes seront lancées et quelles
sont leurs utilités.
onCreate est appelé au début de la création de l’activité et n’est appelé qu’une seule
fois. Il est équivalent du constructeur et sert donc à initialiser des variables, affecter des
listener..
onStart sert à lancer les animations, ou généralement tout ce qui est liée à l’affichage
graphique, car elle est également appelé lors d’un retour de focus sur l’activité (dans ce
cas onRestart est appelé avant).
onResume est appelé de suite après onStart et sert généralement à lancer ou relancer
des process tel que le rafraichissement des informations sur l’écran..
onPause est appelé toujours avant un on stop ou lorsque l’application à besoin de
mémoire
onStop est appelé lorsque une activité (par ex l’activité téléphone) s’affiche par dessus
ou lorsque nous cliquons sur la maison. Nous fermons donc toutes les ressources
graphites utilisées
onDestroy sera appelé lorsque l’on quitte l’activité avec le bouton flèche arrière.
Il arrive également que la machine soit en manque de mémoire et que l’activité soit
détruite pour pouvoir récupérer la mémoire manquante. Si l’utilisateur re-intéragie, une
nouvelle instance est appelée et onCreate est à nouveau appelé.
En rentrant dans les détails du fonctionnement, nous savons que c’est le garbage qui
détruit toute les mémoires non utilisés, et que bien sur, si nous n’arrêtons pas les thread
et autres processus dans le onDestroy, ceux ci ont des chances de continuer à tourner.
Donc concrètement onDestroy ne signifie pas la destruction physique de l’objet mais
tout simplement que la mémoire n’est plus gérée par android. Donc les fameuses
méthodes du cycle de vie sont une sorte de gestion applicative de la création/destruction
de l’objet.
En réalité pour chaque application lancé, une instance de la machine virtelle est lancée
et un processus est alloué pour cette application
Attention, une activité n’est pas l’application. Une activité est l’un des points d’entrée
de cette application. On ne termine pas l’application lorsque l’activité est fermée, donc
le processus utilisé pour cette activité continu de tourner.
Afin de développer votre application Android, vous devrez utiliser les composants mis à
disposition par Google. Nous reviendrons par la suite sur chacun de ces points, mais il
est important que vous ayez ce vocabulaire basique en tête :
Emulator (Emulateur) : Même si vous avez un téléphone Android, vous ne pourrez
tester le comportement de votre application sur n versions d'Android et n écrans
différents. Pour faciliter les développements, Google a donc inclus dans son SDK un
émulateur permettant d'avoir accès à toutes les versions d'Android. Les constructeurs
jouent aussi le jeu en fournissant des émulateurs pour chacun de leurs téléphones (HTC,
Samsung, ...).
Activity (Activité) : Voyez une activité comme une fenêtre de dialogue. Sous Android,
la taille de l'écran ne vous permet pas souvent d'afficher plusieurs fenêtres en parallèle
mais plutôt un passage d'écrans en écrans : de gauche à droite pour avancer dans
l'application, de droite à gauche pour revenir en arrière. Ces écrans successifs sont
appelés des activités.
Content Provider (Fournisseur de contenu) : Les différentes applications sur votre
terminal ne doivent pas obligatoirement être indépendantes. En effet, vous pouvez avoir

67. besoin d'informations stockées dans d'autres applications (récupération des SMS, des
paramètres du téléphone, etc.)
Intents (Intentions) : Les intentions vont permettre aux programmes d'avoir des
notifications sur des évènements. Ces derniers peuvent être envoyés par le terminal
(réception d'un appel, d'un SMS, connexion internet perdue) ou par une autre
application souhaitant vous envoyer une information.
Services : Votre application va être développée sous formes de n activités, chacune en
appelant une autre. Cependant votre activité peut être arrêtée à tout moment lorsque
l'utilisateur décide de quitter votre application. L'objectif des services est de pouvoir
continuer à lancer des opérations alors que votre application n'est pas « lancée », c'est-à-
dire non visible sur le terminal. Ceci peut vous permettre de contacter toutes les n
minutes un serveur pour vérifier s'il y a de nouveaux éléments (articles de journaux,
emails, RSS, etc.) ou encore de jouer de la musique en streaming en tâche de fond.
Réalisation :
Application Android :
 web service: Il est souvent associé à la base de données open source MySQL et au
serveur apache pour réaliser des sites web dynamiques. Il permet d’exploiter bien
d’autres bases de données, notamment celles dotées d’un pilote ODBC (Open
Database Connectivity).
Connexion avec PHP et MySQL sous Android

68. Android :
Clôture: La clôture de caisse permet de suivre les ventes par vendeurs ainsi
que de
chercher une vente par date.
 Android: C’est un système d'exploitation open source utilisant le noyau Linux,
une startup rachetée par Google, né en juillet 2005.
 Service web : Une technologie permettant à des applications de dialoguer à
distance via Internet indépendamment des plates-formes et des langages sur
lesquels elles reposent.
 Middleware : C’est l’ensemble des couches réseau et services logiciels qui
permettentledialogueentrelesdifférentscomposantsd’une application.
 Architecture client/serveur : Les applications les plus complexes peuvent faire
partie d'une base de données et accéder aux informations qu'elle contient en
envoyant des commandes SQL à un serveur pour lire ou écrire des données. Dans
ce cas, la base de données fonctionne dans un processus indépendant de celui de
l'application, et parfois sur une machine différente. Les composants permettant
l'accès aux données sont séparés du reste de l'application.
La raison de cette approche est de centraliser les données afin de permettre à
plusieurs utilisateurs d'y accéder simultanément. Les données peuvent ainsi être
partagées entre plusieurs utilisateurs de l'application.
Implémentation
Cette application comporte deux parties de réalisation:
♦ Partie web : développée en cake PHP
♦ Partie mobile : développée en Android

69. L’application comprend deux styles différents
D’après la page « paramétrage », nous pouvons modifier La langue (français, anglais ou
arabe), le point de vente et le style de l’application.
Ainsi, nous pouvons créer un évènement, attribuer (une remise, une réduction, un
règlement)
Page Paramétrage du 1er
style

70. Page Paramétrage du 2ème
style
Page d’accueil du 1er
style

71. Page d’accueil du 2ème
style
Interface Caissier du 1er
style

72. Interface Caissier du 2ème
style
Interface Gestion du 1er
style

73. Interface Gestion du 2ème
style

74. Conclusion
Ce dernier chapitre a été réservé pour la description de l’environnement du travail
et aussi, des différentes interfaces de l’application.
A la fin de ce rapport, nous allons citer quelques avantages extraits non seulement
de notre formation, mais aussi par la réalisation de ce projet.

76. BIBLIOGRAPHIE
Ouvrages
[liv1] Jim Conallen. Concevoir des applications Web avec UML. Editions eyrolles,
2000.
[liv2]
[liv3] Le cahier de programmeur UML 2 Pascal Roque
Sites Internet
• http://uml.free.fr/cours/p5.html#ptf
• http://www.supinfo-projects.com/en/2004/conception_uml/1/
• http://blog.wikimemoires.com/2011/04/developpement-du-modele-dynamique/
• http://wiip.fr/content/choisir-le-bon-interclassement-mysql-pour-utf-8
• http://www.grafikart.fr/tutoriels/cakephp/console-cakephp-116
• http://book.cakephp.org/2.0/fr/core-libraries/internationalization-and-
localization.html
• http://www.youtube.com/watch?
feature=player_detailpage&list=PL73F07FE653C272E3&v=qqh94SbK3Wk

77. CONCLUSION GENERALE
L’étude théorique à travers l’analyse des besoins des organismes et l’analyse des
atouts que l’application doit fournir nous a permis de constater que les trois
objectifs, organisationnel, technique et méthodologique sont vérifiés.
Bien que nous avons rencontré quelques difficultés au niveau de la recherche,
la documentation et la spécification pour la réalisation de ce projet, cette
application nous a été bénéfique car elle nous a permis de bien nous familiariser
à programmer en cakephp et aussi bien d’affronté la vie professionnelle de notre
domaine.
La réussite de ce site a nécessité :
♦ Une bonne gestion administrative pour les différents modules de
l’application.
♦ Une bonne conception pour les différents cas d’utilisations de
l’application.
♦ Une bonne organisation de sa conduite durant sa réalisation.
L’objectif général de cette application est de minimiser les paperasses circulant
dans un restaurant tout en gardant leurs objectifs et améliorant leurs efficacités.
Mon projet ne manque pas de perspectives. En effet, on peut envisager
d’améliorer ce site en ajoutant d’autre module comme

78. TITRE DU PROJET DE LICENCE
Bilel Belwafi
Imen Soussi
Hatem Hadrich
Résumé : Le monde connait des progrès technologiques importants dans tous les
secteurs, et grâce à l’informatique qui est l’étude des techniques de traitements
automatique de l’information. Elle joue un rôle important dans le développement
d’institutions pour assurer son bon fonctionnement parmi les services les plus
couramment on cite l’utilisation des logiciels en ligne. Dans ce contexte s’oriente notre
projet de fin d’études qui consiste à réaliser une application permet de gérer un
restaurant.
Pour réaliser notre application nous avons utilisés comme méthode de conception UML
et langage de programmation de script CakePHP, Ajax, JQuery et MYSQL comme
étant un SGBD de base de données.
Mots clés: CakePHP, Ajax, JQuery, MYSQL
Abstract: The world knows of the significant technological advances in all sectors,
and through information technology which is the study of techniques of automatic data
processing. It plays an important role in the development of institutions to ensure proper
operation of the services most commonly cited use of online software. In this context
orients our project of end of studies which is an application to manage a restaurant.
To make our application we used as a design method UML and programming language
CakePHP, Ajax, JQuery and MYSQL as a DBMS database.
Key-words: CakePHP, Ajax, JQuery, MYSQL
‫الخلةصة‬:‫تقنيات‬ ‫دراسة‬ ‫وهو‬ ‫الحوسبة‬ ‫وفضل‬ ،‫القطاعات‬ ‫جميع‬ ‫في‬ ‫الكبير‬ ‫التكنولوجي‬ ‫التقدم‬ ‫من‬ ‫يعرف‬ ‫العالم‬ ‫إن‬
‫المذكورة‬ ‫للخدمات‬ ‫السليم‬ ‫التشغيل‬ ‫لضمان‬ ‫المؤسسات‬ ‫تطوير‬ ‫في‬ ‫هاما‬ ‫ا‬ً ‫دور‬ ‫تلعب‬ ‫أنها‬ .‫التلقائية‬ ‫المعلومات‬ ‫معالجة‬
‫وتطبيق‬ ‫الدراسات‬ ‫نهاية‬ ‫مشروع‬ ‫لدينا‬ ‫يوجه‬ ‫السياق‬ ‫هذا‬ ‫وفي‬ .‫النترنت‬ ‫شبكة‬ ‫على‬ ‫البرمجيات‬ ‫استخدام‬ ‫ا‬ً ‫شيوع‬ ‫الكثر‬
‫لغة‬ ‫وبرمجة‬ ‫تصميم‬ ‫الموحد‬ ‫اللينيني‬ ‫الماركسي‬ ‫من‬ ‫كأسلوب‬ ‫تستخدم‬ ‫نحن‬ ‫بنا‬ ‫الخاص‬ ‫التطبيق‬ ‫لجعل‬ .‫مطعم‬ ‫لدارة‬
‫ويجري‬ ‫البيانات‬ ‫قواعد‬ ‫إدارة‬ ‫نظم‬ ‫بيانات‬ ‫كقاعدة‬ ‫والخلية‬ ‫مسج‬ ،‫أياكس‬ ،[‫]ككفب‬ ‫النصي‬ ‫.البرنامج‬
‫المفاتيح‬: