Kamou - m.academiepro.comm.academiepro.com/uploads/projets/2015_07_15_rapp… · Web viewet de la...

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

Transcript of Kamou - m.academiepro.comm.academiepro.com/uploads/projets/2015_07_15_rapp… · Web viewet de la...

Projet de Licence appliquée en Informatique

Sciences et Technologies  N° d’ordre: 201? ??nn

République TunisienneMinistère de l’Enseignement Supérieur

et de la Recherche Scientifique

Université de SfaxInstitut Supérieur d’Informatique

et de Multimédia de Sfax

PROJETPré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 DUPROJET

DE LICENCEPar

Bilel Belwafi Imen Soussi

Hatem HadrichSoutenu 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é EntrepriseAnnée Universitaire : 2012-2013

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

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

Chapitre IETUDE

PREALABLE 

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

Planning prévisionnelNotre 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 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

Cahier des charges

Analyse et conception

Ecriture du rapport

Réalisation

Etude théorique

Février Mars Avril Mai

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

Introduction :

Chapitre II

Méthodologie De

Conception

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 unsuperuseretuncaissier.La manièred’accéderauxservicesde l’application pour l’un et pourlesautresestlamême.Ladifférencerésidesurlesdroitsd’accèsetlesprivilègesde chacun. 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 :

Cas d’Utilisation : Gérer AchatsObjectif : 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 commande1. Le gérant demande au système de créer un nouveau bon de commande.2. Le système lui affiche l’interface de saisie3. 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’erreurE1 : 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. - 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».

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.- 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 fournisseur1. 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’erreurE1 : 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 ».

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 fournisseur1. 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 fournisseur1. 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'erreurE1 : 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 ».

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 fournisseur1. 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 fournisseurs2. Le système imprime la liste de fournisseurs.

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 livraison1. 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.- 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 livraison1. 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 livraison1. 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’erreurE1 : 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 livraison1. Le gérant demande au système de consulter la liste des livraisons.2. Le système imprime la liste des bons de livraison.

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 livraison1. 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’erreurE1 : 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 article1. Le gérant demande au système de créer un nouvel article2. Le système lui affiche l’interface de saisie.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’erreurE1 : 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 article1. 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 article1. 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 :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 COMMANDEActeur : ClientScé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’erreurE1 : Aucun produit choisi

Le système affiche le message d’erreur suivant : « Vous devez d’abord choisir un produit ».

E2 : Tiroir videLe système affiche le message d’erreur suivant : « il n’y a plus de papiers ».

CAS D’UTILISATION : AUTHENTIFICATIONActeurs: 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.

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 REGLEMENTSObjectif : 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’erreurE1 : 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’erreurE1 : Date d’échéance invalide

- 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’erreurE1 : Points de fidélité insuffisante

- Le système affiche le message d’erreur suivant : «Les points de fidélité sont

insuffisantes ».

Chapitre  III

ANALYSE 

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.

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

Diagramme de classe : (Domaine)

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.

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.

Authentification :

Commande :

Session :

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 TypeID L’identificateur d’une

commandeEntier

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

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

Texte

Code_tva Désigne le code TVA

Ville la ville où se situe l’entreprise

Tableau 3: Table Article Composé

Attribut Désignation TypeID L’identificateur de l’article Entier

Quantite La quantité de l’articleUnite L’unité de l’article

Id_produit Clé étrangère du produit Entier Id_article_achete Clé étrangère de l’article

achetéEntier

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 TypeID L’identificateur d’une ligne

du bon livraisonEntier

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

Tableau 7: Table Carte

Attribut Désignation Type

ID L’identificateur d’uneentreprise

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

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

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

Tableau 13: Table Perte

Attribut Désignation Type

ID L’identificateur d’unePerte

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 ModeRè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’unePiè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

Tableau 16: Table Pointage

Attribut Désignation Type

ID L’identificateur d’unePointage

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

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 TypeID L’identificateur d’un sous

familleEntier

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

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 TypeId L’identificateur de la ligne de

stockEntier

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 TypeId L’identificateur de magasin

de stockEntier

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

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

Id reduction Clé étrangère de réduction Entier

Tableau 28: Table Réduction

Attribut Désignation TypeId 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

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 EntierId_reduction Clé étrangère de réduction Entier

Tableau 32: Table espace

Attribut Désignation TypeId 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

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 TypeId 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 TypeId_ticket Clé étrangère de ticket Entier

Id_règlement Clé étrangère de règlement acheté

Entier

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,description_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_achat,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,nbr_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);

Employes(id,code_emp,cin_emp,name_fr,name_ar,name_ang,adresse_fr,adresse_ar,adresse_ang,ville_fr,ville_ar,ville_ang,num_tel,description_fr,description_ar,description_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,description_ar,description_ang,#reduction_id);

Fournisseurs(id,name_fr,name_ar,name_ang,adresse_fr,adresse_ar,adresse_ang,tel,responsable,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,description_ang);

Journalieres(id,name_fr,name_ar,name_ang,reclamation_fr,reclamation_ar,reclamation_ar,reclamation_ang,periode,description_fr,description_ar,description_ang,#grade_id);

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,description_fr,description_ar,description_ang,#restaurant_id);

Mode_reglements(id,type_fr,type_ar,type_ang,description_fr,description_ar,description_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_fr,bangue_ar,bangue_ang,#devise_id,#reglement_id);

Plans(id,position_x,position_y,unite,specification_fr,specification_ar,specification_ang,date,#espace_id);

Pointages(id,name_fr,name_ar,name_ang,date_pointe,#employe_id);

Point(id,prix);

Produit_options(#produit_id,#option_id);

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,description_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,responsable,code_tva,fax,ville_fr,ville_ar,ville_ang,code_postal,description_fr,description_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,#journaliere_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.

Chapitre  IV

CONCEPTION &

REALISATION 

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 :

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

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

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 :

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.

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

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

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.

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

Linux Kernel Display

Driver

Camera

Driver

Flash

Memory

Blinder(IPC)

Driver

Audio

Drivers

Key Pad

Driver

Power

Management

Wifi

Driver

- 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 del’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].

- Cadre de l’application (Application Framework) :Le cadre de l’application (Application Framework) fournit les principaux services pour la plateforme Android [www05].

Figure 2 : Le noyau Linux

Application Framework Activity Manager

View System Package Manager

Window manager Content Providers

Telephony Manager

Resource Manager Location Manager Notification Manager

Android Runtime

Core Libraries Dalvik Virtual Machine

Figure 3 : Le moteur d'exécution d'Android

Figure 4 : Le cadre de l'application

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

- Cycle de vie d’une activité :

Applications Réveil Contacts Calculatrice Caméra

Figure 5 : Les applications

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émoireonStop 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éesonDestroy 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 applicationAttention, 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

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 biend’autres bases de données, notamment celles dotées d’un pilote ODBC (OpenDatabase Connectivity).

Connexion avec PHP et MySQL sous Android

Android : Clôture: La clôture de caisse permet de suivre les ventes par vendeurs ainsi que dechercher 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 surlesquels 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 fairepartie d'une base de données et accéder aux informations qu'elle contient enenvoyant des commandes SQL à un serveur pour lire ou écrire des données. Dansce cas, la base de données fonctionne dans un processus indépendant de celui del'application, et parfois sur une machine différente. Les composants permettantl'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 êtrepartagé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

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 1 er style

Page Paramétrage du 2 ème style

Page d’accueil du 1 er style

Page d’accueil du 2 ème style

Interface Caissier du 1 er style

Interface Caissier du 2 ème style

Interface Gestion du 1 er style

Interface Gestion du 2 ème style

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.

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

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

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

وفضل : الخالصة القطاعات، جميع في الكبير التكنولوجي التقدم من يعرف العالم إن . تطوير في هاما ً دورا تلعب أنها التلقائية المعلومات معالجة تقنيات دراسة وهو الحوسبة

استخدام ً شيوعا األكثر المذكورة للخدمات السليم التشغيل لضمان المؤسسات . الدراسات نهاية مشروع لدينا يوجه السياق هذا وفي اإلنترنت شبكة على البرمجيات

. الماركسي من كأسلوب تستخدم نحن بنا الخاص التطبيق لجعل مطعم إلدارة وتطبيق [ والخلية [ مسج أياكس، ، ككفب النصي البرنامج لغة وبرمجة تصميم الموحد اللينيني

ويجري البيانات قواعد إدارة نظم بيانات .كقاعدة

:المفاتيح