Rapport PFE Application Web Mobiles belwafi bilel

5 401 vues

Publié le

application combiner web mobile

Publié dans : Technologie
1 commentaire
1 j’aime
Statistiques
Remarques
  • il a une erreur dans le slide 12 (les relations include ne sont pas correct)
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
5 401
Sur SlideShare
0
Issues des intégrations
0
Intégrations
10
Actions
Partages
0
Téléchargements
276
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Rapport PFE Application Web Mobiles belwafi bilel

  1. 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. 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. 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. 4. Chapitre I ETUDE PREALABLE
  5. 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. 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. 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. 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. 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. 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. 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 :
  12. 12. 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.
  13. 13. - 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».
  14. 14. 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.
  15. 15. - 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 ».
  16. 16. 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 ».
  17. 17. 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.
  18. 18. 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.
  19. 19. - 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.
  20. 20. 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.
  21. 21. 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 :
  22. 22. 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 ».
  23. 23. 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.
  24. 24. 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
  25. 25. - 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 ».
  26. 26. Chapitre III ANALYSE
  27. 27. 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.
  28. 28. 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
  29. 29. Diagramme de classe : (Domaine)
  30. 30. 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.
  31. 31. 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.
  32. 32. Authentification :
  33. 33. Commande : Session :
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. 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);
  47. 47.  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);
  48. 48.  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.
  49. 49. Chapitre IV CONCEPTION & REALISATION
  50. 50. 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
  51. 51. 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 :
  52. 52. 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.
  53. 53. 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
  54. 54. 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 :
  55. 55. 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.
  56. 56.  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.
  57. 57.  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].
  58. 58. - 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
  59. 59. - 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
  60. 60. - Cycle de vie d’une activité :
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. Page Paramétrage du 2ème style Page d’accueil du 1er style
  66. 66. Page d’accueil du 2ème style Interface Caissier du 1er style
  67. 67. Interface Caissier du 2ème style Interface Gestion du 1er style
  68. 68. Interface Gestion du 2ème style
  69. 69. 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.
  70. 70. 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
  71. 71. 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
  72. 72. 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 ‫الخلةصة‬:‫تقنيات‬ ‫دراسة‬ ‫وهو‬ ‫الحوسبة‬ ‫وفضل‬ ،‫القطاعات‬ ‫جميع‬ ‫في‬ ‫الكبير‬ ‫التكنولوجي‬ ‫التقدم‬ ‫من‬ ‫يعرف‬ ‫العالم‬ ‫إن‬ ‫المذكورة‬ ‫للخدمات‬ ‫السليم‬ ‫التشغيل‬ ‫لضمان‬ ‫المؤسسات‬ ‫تطوير‬ ‫في‬ ‫هاما‬ ‫ا‬ً ‫دور‬ ‫تلعب‬ ‫أنها‬ .‫التلقائية‬ ‫المعلومات‬ ‫معالجة‬ ‫وتطبيق‬ ‫الدراسات‬ ‫نهاية‬ ‫مشروع‬ ‫لدينا‬ ‫يوجه‬ ‫السياق‬ ‫هذا‬ ‫وفي‬ .‫النترنت‬ ‫شبكة‬ ‫على‬ ‫البرمجيات‬ ‫استخدام‬ ‫ا‬ً ‫شيوع‬ ‫الكثر‬ ‫لغة‬ ‫وبرمجة‬ ‫تصميم‬ ‫الموحد‬ ‫اللينيني‬ ‫الماركسي‬ ‫من‬ ‫كأسلوب‬ ‫تستخدم‬ ‫نحن‬ ‫بنا‬ ‫الخاص‬ ‫التطبيق‬ ‫لجعل‬ .‫مطعم‬ ‫لدارة‬ ‫ويجري‬ ‫البيانات‬ ‫قواعد‬ ‫إدارة‬ ‫نظم‬ ‫بيانات‬ ‫كقاعدة‬ ‫والخلية‬ ‫مسج‬ ،‫أياكس‬ ،[‫]ككفب‬ ‫النصي‬ ‫.البرنامج‬ ‫المفاتيح‬:

×