Vous êtes sur la page 1sur 75

République Tunisienne Projet de Licence appliquée en

Ministère de l’Enseignement Supérieur Informatique


et de la Recherche Scientifique

Université de Sfax Sciences et Technologies  


Institut Supérieur d’Informatique N° d’ordre: 201? ??nn
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
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.
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 I
ETUDE
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é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.
Cahier Ecriture du rapport
des
charges
Réalisation

Analyse et conception

Etude
théorique

Février Mars Avril Mai

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

Méthodologie
De Conception
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.
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 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.
- 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 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 ».

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

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.

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


ID L’identificateur d’une Entier
commande
Num Numéro du bon de Texte
commande
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 Entier
entreprise
Nom fournisseur Le nom du fournisseur Texte
(entreprise)
Responsable Texte
Adresse fournisseur L’adresse du fournisseur Texte
Tel Le téléphone du fournisseur Entier long
Fax fournisseur Identifie le fax du Entier long
fournisseur
Code_postal Le code postal de
la ville où se situe
l’ entreprise
E-mail fournisseur Identifie l’E-mail d’un Texte
fournisseur
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 Entier
acheté
Tableau 4: Table Ligne Du Bon de commande

Attribut Désignation Type

ID L’identificateur d’une ligne Entier


du bon commande
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 Entier
commande
Id_article_achete Clé étrangère de l’article Entier
acheté

Tableau 5: Table Bon de Livraison

Attribut Désignation Type

ID L’identificateur d’un bon de Entier


livraison
Date La date de livraison de la Date
commande
Id_facture Clé étrangère de facture Entier

Id_bon_commande Clé étrangère du bon de Entier


commande
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 Entier
du bon livraison
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 Entier
livraison
Id_article_achete Clé étrangère de l’article Entier
acheté
Tableau 7: Table Carte

Attribut Désignation Type


ID L’identificateur d’une Entier
entreprise
Nom_client Le nom du client fidèle Texte

Num Le numéro de la carte de Chaine


fidèlité
CIN Le numéro de la carte Chaine
d’identité
Tel Le téléphone du fournisseur Chaine
Nbr_point Identifie le nombre Entier
de points
Cout La conversion des Réel
points en monnaie
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 Entier


restaurant

Tableau 9: Table Famille

Attribut Désignation Type


ID L’identificateur d’une Entier
Famille
Nom Le nom de la famille Texte

Photo Chemin de photos Texte


Ordre Affichage Afficher les sous familles Entier
dans un ordre précis
Description Description de Famille Texte
Id Réduction Clé étrangère de Entier
réduction

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 Entier
règlement

Tableau 11: Table Evènement

Attribut Désignation Type


ID L’identificateur d’une Entier
Evènement
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’une Entier
Perte
Quantite Quantité de Perte Réel

Unite Unité Perte Texte


Description Description de Perte Texte
Id_ligne_stock Clé étrangère de ligne de Entier
stocke

Tableau 14: Table Mode Règlement

Attribut Désignation Type


ID L’identificateur d’une Mode Entier
Règlement
Type Type de Mode Règlement Texte

Description Description de Mode Texte


Règlement

Tableau 15: Table Pièce

Attribut Désignation Type


ID L’identificateur d’une Entier
Pièce
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 Texte
propriétaire du chèque
Id_devise Clé étrangère de Entier
devise
Id_reglement Clé étrangère de Entier
Règlement
Tableau 16: Table Pointage

Attribut Désignation Type


ID L’identificateur d’une Entier
Pointage
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 Entier
produit Lié et Clé étrangère de
Table Produit
Id_article_achete L’identificateur de table Entier
produit Lié et Clé étrangère de
Table Article Acheté
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 Texte
ticket
Id_restaurant Clé étrangère du Entier
restaurant
Id_reglement Clé étrangère pour Entier
faire un règlement
sur le ticket
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 Entier
famille
Nom_sous_famille Le nom d’un sous famille Texte

Ordre_affichage Afficher les sous familles Entier


dans un ordre précis
Description Description pour un sous Texte
famille
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 Entier
restaurant
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 Texte
un restaurant
Responsable Responsable du restaurant Texte

Code_TVA Code de Tax sur la Float


valeur ajoutée
Fax Le Fax du Texte
restaurant
Ville La ville où se trouve le Texte
restaurant
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 Réel


grade
Description Description de grade Texte

Tableau 23: Table Ligne_stock

Attribut Désignation Type


Id L’identificateur de la ligne de Entier
stock
Delai_expiration Le délai d’expiration pour Date
une ligne de stock
Unite L’unité de l’article Réel

Id_magasin_stock Clé étrangère d’un magasin de Entier


stock
Id_ligne_bon_livraision Clé étrangère du bon de ligne Entier
de bon livraison

Tableau 24: Table Magasin_stock

Attribut Désignation Type


Id L’identificateur de magasin Entier
de stock
Nom Le nom de magasin de stock Texte

Adresse L’adresse de magasin de stock Texte

Description Description sur le magasin de Texte


stock
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 Texte
plan
Specification La specification de plan Texte

Date Date de plan DateTime

Id_espace Clé étrangère de Entier


l’espace

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 Entier


de fidélité pour
chaque produit
Ordre L’ordre d’affichage Entier
de produit
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 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 Date
réservation
Tarif Tarif sur réservation réel

Description Description de Texte


réservation

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 Entier
chaque table
Etat L’état de table Texte

Tarif Tarif sur table Réel

Description Description de Texte


table
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 Entier
ticket
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 Entier
acheté
Nom_article Le nom de l’article Texte

Quantité Quantité de l’article acheté Réel

Quantite_alerte Quantité minimal de l’article Réel


acheté
Unite Unité sur quantité de l’article Texte
acheté
Type Type de l’article Texte
acheté
Prix_achat Le prix d’achat de l’article Réel
acheté
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 Entier
l’amortissement
Cout Cout sur amortissement Réel

Description Description de Texte


l’amortissement
Id_article_achete Clé étrangère de l’article Entier
acheté

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 Entier


acheté
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);
 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);

 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.
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 Core i3 4 Go Ram 320 Go


VPCE
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 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.
 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 Camera Flash Blinder(IPC)
Driver Driver Memory Driver

Audio Key Pad Power Wifi


Drivers Driver Management Driver
Figure 2 : Le noyau Linux

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

Android Runtime
Core Libraries Dalvik Virtual Machine

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

- Cadre de l’application (Application Framework) :


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

Application Framework
Activity Manager Window manager Content Providers

View System Package Manager Telephony Manager

Resource Manager Location Manager Notification Manager

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

Applications
Réveil Contacts Calculatrice Caméra

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. Figure 5 : Les applications

- Cycle de vie d’une activité :


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


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


Page Paramétrage du 2ème style

Page d’accueil du 1er style


Page d’accueil du 2ème style

Interface Caissier du 1er style


Interface Caissier du 2ème style

Interface Gestion du 1er 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

‫ وفضل الحوسبة وهو دراسة تقنيات‬،‫ إن العالم يعرف من التقدم التكنولوجي الكبير في جميع القطاعات‬:‫الخالصة‬
‫ أنها تلعب دوراً هاما في تطوير المؤسسات لضمان التشغيل السليم للخدمات المذكورة‬.‫معالجة المعلومات التلقائية‬
‫ وفي هذا السياق يوجه لدينا مشروع نهاية الدراسات وتطبيق‬.‫األكثر شيوعا ً استخدام البرمجيات على شبكة اإلنترنت‬
‫ لجعل التطبيق الخاص بنا نحن تستخدم كأسلوب من الماركسي اللينيني الموحد تصميم وبرمجة لغة‬.‫إلدارة مطعم‬
‫ مسج والخلية كقاعدة بيانات نظم إدارة قواعد البيانات ويجري‬،‫ أياكس‬،]‫البرنامج النصي [ككفب‬.

:‫المفاتيح‬

Vous aimerez peut-être aussi