Memoire Yvan - Fabrice Corrigee2

1
REPUBLIQUE DU BURUNDI
UNIVERSITE DU LAC TANGANYIKA
FACULTE D’INFORMATIQUE
CONCEPTION ET IMPLEMENTATION D’UNE APPLICATION WEB DE GESTION

DES ENTREES ET SORTIES DES PRODUITS D’UNE ALIMENTATION
<<
CAS DE L’ALIMENTATION DU MIDI>>
Par:
Yvan HARUSHIMANA
Et
Fabrice MUGISHA
Mémoire présenté et défendu publiquement en

vue de l’obtention du grade de Licencié en
Informatique
Option: Génie Logiciel
Sous la direction de:
Me SC. Rémeny NAHIMANA
Bujumbura, Décembre 2015

i
DEDICACES
A ma chère mère;
A mon regretté père;
A mes chers frères et sœurs;
A mes cousins et cousines;
A tous mes oncles et tantes;
A la famille BAHIZI Charles;
A tous mes amis et camarades de classe;
HARUSHIMANA Yvan
A ma chère mère;
A mon regretté père;
A mes chers frères et sœurs;
A mes cousins et cousines;
A tous mes neveux et nièces;
A la famille KIRIMUTUMYE Jean Paul;
A la famille DUNIA Prudence;
A tous mes amis et camarades de classe;
A tous ceux qui me donnent des raisons d’être ce que je suis;
Mugisha Fabrice
ii
REMERCIEMENTS
Le présent travail est le fruit des efforts consentis par différentes personnes tant physiques que
morales. Ainsi, au terme de celui-ci, c’est pour nous une heureuse occasion d’exprimer nos
sentiments de gratitude envers toutes les personnes qui, de près ou de loin, ont contribué à son
élaboration en nous prêtant main forte.
Nos sincères remerciements s’adressent plus particulièrement à Msc. Rémeny NAHIMANA,

Professeur à l’Université du Lac Tanganyika qui, malgré ses nombreuses obligations, a accepté
de diriger ce mémoire. En effet, ses conseils, ses directives et sa disponibilité nous ont permis
de mener à bien notre travail.
Nos remerciements s’adressent ensuite au Président et aux Membres du Jury qui ont accepté
de lire ce mémoire et de participer à son appréciation. Que tous les professeurs qui nous ont
enseigné durant tout notre parcours depuis l’école primaire, trouvent ici l’expression de notre
profonde gratitude. Vous avez fait de nous ce que nous sommes aujourd’hui.
A tous les camarades de classe, avec qui nous avons partagé les connaissances, merci d’avoir
été auprès de nous. Votre soutient et votre aide nous ont été précieux.
Nos remerciements sont encore adressés à tout le personnel de l’alimentation DU MIDI pour
leur appui lors de la documentation, plus particulièrement à sa patronne pour sa parfaite
collaboration; ils ont su répondre à nos questions les plus pertinentes qui nous ont permis de
mener à bien notre projet. Que son personnel soit rassuré de notre profonde reconnaissance.
Nous remercions enfin tous ceux qui, d’une façon ou d’une autre ont manifesté
un attachement particulier et ont témoigné leur amour et leur sympathie envers nous. Nous
pensons plus particulièrement à nos proches familles et amis; qu’ils soient rassurés de nos
remerciements sincères.
iii
LISTE DES SIGLES ET ABREVIATIONS
AJAX : Asynchronous JavaScript and XML

ALIMIDI : Alimentation DU MIDI
API : Application Programmable Interface
ASP : Active Server Page
ASVS : Application Security Verification Standard
CDK : Component Development Kit
CLI : Common Language Infrastructure
CLR : Common Language Runtime
CPU : Central Processing Unit
CRUD : Create - Read - Update – Delete
CSS : Cascading Style Sheet
DHTML : Dynamic HTML
DOM : Document Object Model
DOS : Denial Of Service
EJB : Enterprise JavaBeans
HTML : Hyper Text Markup Language
HTTP : Hyper Text Transfer Protocol
IDE : Integrated Development Environment
JMS : Java Message Service
JPA : Java Persistence API
JSF : Java Sever Faces
JSON : JavaScript Object Notation
JSP : Java Server Pages
JSR : Java Specification Request
JTA : Java Transaction API
MVC : Model View Controller
OMG : Object Modeling Group
OMT : Object Modeling Technique
iv
OOSE : Object Oriented Software Engineering

OWASP : Open Web Application Security Project
PHP : Hypertext Preprocessor
RI : Reference Implementation
RIA : Rich Internet Application
RPC : Remote Procedure Call
RUP : Rational Unified Process
SE : Système d’exploitation
SGBD : Système de Gestion de Base de donnée.
SPA : Single Page Application
SQL : Structured Query Language
UI : User Interface
ULT : Université du Lac Tanganyika
UML : Unified Modeling Language
UP : Unified Process
URL : Uniform Resource Locator
W3C : World Wide Web Consortium
WML : Wireless Markup Language
XHTML : eXtensible Hyper Text Markup Language
XML : eXtensible Markup Language
v
LISTE DES TABLEAUX
Tableau 1 : Scénario nominal du cas d’utilisation : S’authentifier ............................................... 25

Tableau 2 : Scénario nominal du cas d’utilisation : Elaborer une commande ............................. 26
Tableau 3 : Scénario nominal du cas d’utilisation : Elaborer une facture pro forma ................... 27
Tableau 4 : Scénario nominal du cas d’utilisation : Réserver un produit ..................................... 28
Tableau 5 : Scénario nominal du cas d’utilisation : Proposer le prix ............................................ 29
Tableau 6 : Scénario nominal du cas d’utilisation : Ajouter un une personne ............................. 30
Tableau 7 : Scénario nominal du cas d’utilisation : Vendre un produit (cash) ............................. 31
Tableau 8 : Scénario nominal du cas d’utilisation : Vendre un produit (crédit) ........................... 32
vi
LISTE DES FIGURES
Figure 1 : Evolution du langage UML .............................................................................................. 8

Figure 2 : Exemple de diagramme de classe ................................................................................. 10
Figure 3 : Exemple d’une multiplicité d’association ..................................................................... 12
Figure 4 : Exemple de multiplicité ................................................................................................ 13
Figure 5 : Exemple d’agrégation et de composition ..................................................................... 13
Figure 6 : Exemples de super-classes et sous-classes ................................................................... 14
Figure 7 : Exemple d’un diagramme de déploiement .................................................................. 15
Figure 8 : Représentations graphiques possibles d’un acteur ...................................................... 16
Figure 9 : Exemple d’un diagramme de cas d’utilisation .............................................................. 17
Figure 10 : Notion de base du diagramme d’Etats ....................................................................... 18
Figure 11 : Notion plus complète du diagramme d’états ............................................................. 19
Figure 12 : Exemple de diagramme d’activité avec couloir d’activité .......................................... 21
Figure 13 : Formalisme du diagramme de séquence.................................................................... 22
Figure 14 : Diagramme des cas d’utilisation de l’alimentation du midi ....................................... 24
Figure 15 : Diagramme d’Etats-transition pour l’objet « produit » .............................................. 33
Figure 16 : Diagramme d’activité de la vente des produits .......................................................... 34
Figure 17 : Diagramme de séquence <<Vente des produits>>..................................................... 35
Figure 18 : Diagramme de Séquences <<commander des produits>> ......................................... 36
Figure 19 : Diagramme de classes................................................................................................. 37
Figure 20 : Diagramme de Déploiement ....................................................................................... 38
Figure 21 : Utilisation de Primefaces par rapport à Richfaces et Icefaces ................................... 46
Figure 22 : Page d'accueil de l'application .................................................................................... 50
Figure 23 : Page de réservation des produits de l'alimentation du midi...................................... 52
Figure 24 : Réservation des produits ............................................................................................ 53
Figure 25 : Page de proposition des prix (fournisseur) ................................................................. 54
Figure 26 : Interface d'authentification d'un fournisseur............................................................. 55
Figure 27 : Visualisation des commandes d'un fournisseur ......................................................... 55
Figure 28 : Authentification des utilisateurs ................................................................................. 56
vii
Figure 29 : Page d'erreur............................................................................................................... 56

Figure 30 : Page de vente des produits ........................................................................................ 57
Figure 31 : Facture du client ......................................................................................................... 59
Figure 32 : Réception des produits livrés...................................................................................... 60
Figure 33 : Facture de Payement d'un fournisseur....................................................................... 61
Figure 34 : Enregistrement et mise à jour des produits ............................................................... 62
Figure 35 : Visualisation des coordonnées d’un fournisseur ........................................................ 63
Figure 36 : Tableau des statistiques (caissier). ............................................................................. 64
Figure 37 : Administration des personnes .................................................................................... 65
Figure 38 : Administration des utilisateurs ................................................................................... 66
Figure 39 : Gestion des fournisseurs............................................................................................. 67
Figure 40 : Gestion des commandes ............................................................................................. 68
Figure 41 : Publication des produits ............................................................................................. 69
Figure 42 : Facture pro forma ....................................................................................................... 70
Figure 43 : Contrôle de l’alimentation du midi ............................................................................. 71
viii
TABLES DES MATIERES
DEDICACES ....................................................................................................................................... i
REMERCIEMENTS .............................................................................................................................ii
LISTE DES SIGLES ET ABREVIATIONS ...............................................................................................iii
LISTE DES TABLEAUX ........................................................................................................................v
LISTE DES FIGURES .......................................................................................................................... vi
TABLES DES MATIERES .................................................................................................................. viii
CHAPITRE 0. INTRODUCTION GENERALE ........................................................................................ 1
0.1. Introduction...................................................................................................................... 1
0.2. Choix du sujet ................................................................................................................... 1
0.3. Intérêt du sujet ................................................................................................................. 1
0.4. Délimitation du sujet ........................................................................................................ 2
0.5. Problématiques ................................................................................................................ 2
0.6. Objectifs ........................................................................................................................... 3
0.6.1. Objectif global ......................................................................................................... 3
0.6.2. Objectifs spécifiques ................................................................................................ 3
0.7. Méthodologies et techniques utilisées ............................................................................ 3
0.8. Articulation du sujet ......................................................................................................... 4
CHAPITRE I. PRESENTATION GENERALE DE L’ALIMENTATION DU MIDI ........................................ 5
I.0. Introduction...................................................................................................................... 5
I.1. Concept alimentation ....................................................................................................... 5
I.2. Présentation de l’alimentation DU MIDI .......................................................................... 5
I.3. Analyse de l’existant......................................................................................................... 5
I.4. Critique de l’existant ........................................................................................................ 6

ix
I.5. Solutions proposées ......................................................................................................... 7
CHAPITRE II. CONCEPTION DU NOUVEAU SYSTÈME DE GESTION DES ENTRÉES ET SORTIES

DES PRODUITS POUR L’ALIMENTATION DU MIDI........................................................................... 8
II.0. Introduction...................................................................................................................... 8
II.1. Présentation des diagrammes UML ................................................................................. 9
II.1.1. Diagramme de Classes ............................................................................................ 10
II.1.2. Diagramme de Déploiement ................................................................................... 14
II.1.3. Diagramme de Comportements ............................................................................. 15
II.1.4. Diagramme de Cas d’utilisations ............................................................................ 15
II.1.5. Diagramme d’Etat-transition .................................................................................. 17
II.1.6. Diagramme d’Activités ............................................................................................ 19
II.1.7. Diagramme de Séquences ...................................................................................... 21
II.2. Modélisation du nouveau système de gestion des entrées et sorties des produits de
l’Alimentation DU MIDI ............................................................................................................. 23
II.2.1. Axe dynamique ....................................................................................................... 23
II.2.2. Axe Statique ............................................................................................................ 36
CHAPITRE III. PRESENTATION DE L’APPLICATION DE GESTION DES ENTREES ET SORTIES DES

PRODUITS ...................................................................................................................................... 39
III.1. Introduction.................................................................................................................... 39
III. 2. Choix des outils utilisés............................................................................................... 39
III.2.1. Choix du Système de Gestion de Base de Données (SGBD) ................................... 39
III.2.2. Choix du langage de Programmation ..................................................................... 41
III.2.3. Choix du Framework Prime faces ........................................................................... 43
III.2.4. Photoshop ............................................................................................................... 46
III.2.5. Optimisation du chargement de ressources........................................................... 47

x
III.2.6. Choix de l’I.D.E ........................................................................................................ 48
III. 3. Présentation des pages de l’application..................................................................... 50
III. 3.1. Démarrage de l’application..................................................................................... 50
III. 3.2. Partie client ............................................................................................................. 52
III. 3.3. Proposition des prix par les fournisseurs................................................................ 54
III. 3.4. Authentification des utilisateurs............................................................................. 56
CONCLUSION GENERALE ET RECOMMANDATIONS .................................................................. 73
Références .................................................................................................................................... 74
Ouvrages généraux.................................................................................................................... 74
Mémoires et Publications ......................................................................................................... 74
Dictionnaires ............................................................................................................................. 74
Webographie ............................................................................................................................. 75
1
CHAPITRE 0. INTRODUCTION GENERALE
0.1. Introduction
Toutes les entreprises multinationales comme les PME1 cherchent à être de plus en plus
performantes sur des marchés toujours plus concurrentiels. Elles font face à un certain
nombre de problèmes comme: une grande concurrence, une petite portée du marché, des
fournisseurs performants, etc. Face à une telle situation elles mettent en œuvre des
stratégies pour atteindre leurs objectifs de rentabilité à travers une amélioration des
méthodes de travail et la qualité des services.
Le besoin croissant des décideurs d'avoir la bonne information au bon moment trouve
satisfaction dans le traitement automatique de cette dernière. En effet, la disposition des
outils informatiques permet de traiter l'information pour qu'elle soit présentée à l'utilisateur
avec un sens qui lui confère toute sa valeur.
C’est dans ce cadre que s'inscrit notre projet de fin d'études qui consiste a concevoir et
implémenter une application web de gestion des entrées et sorties des produits d’une
alimentation.
0.2. Choix du sujet
L’absence de politique d’amélioration de services offerts est l’un des aspects qui freine la
bonne performance dans le domaine de l’offre et de la demande. En effet, un système basé
sur le traitement et la sauvegarde manuel des données observés dans divers services dont
les centres commerciaux peuvent être à la base de la lenteur dans l’apport de service au
client mais également dans la perte des données qui devaient servir pour les planifications à
court, à moyen et à long terme.
Les alimentations ne font pas exception à ces derniers, l’informatisation de ces derniers
aurait un impact positif sur la vie quotidienne.
0.3. Intérêt du sujet
Le présent travail vise la conception et l’implémentation d’une application web de gestion

des entrées et sorties des produits dans l’alimentation DU MIDI. Le fruit de ce dernier sera
d’une grande utilité, chacun en ce qui le concerne. Ainsi :
 Pour nous : La réalisation de ce travail sera une occasion d’approfondir les

connaissances acquises au cours de nos études universitaires. Il nous permettra
de perfectionner nos connaissances dans l’analyse des systèmes d’information, la
conception, la modélisation et l’implémentation des systèmes informatiques ;
1
Petite et Moyenne Entreprise
2
 Pour l’alimentation DU MIDI : L’utilisation de cette Application leur facilitera la

tâche dans la gestion des entrées et sorties des produits ainsi ils verront leur
rendement s’accroître considérablement ;
 Pour les clients et Fournisseurs : Cette Application leur permettra d’économiser
le temps en leur donnant la possibilité d’effectuer leurs opérations étant à
distance ;
 Pour les Etudiants : Notre travail apportera sa modeste contribution à tous ceux
qui voudront se servir de ce travail comme une de leurs références.
0.4. Délimitation du sujet
Comme la plupart d’autres projets scientifiques, notre projet présente une complexité et il
est difficile de l’aborder dans son ensemble, donc nous l’avons délimité dans l’espace, dans
le domaine et dans le temps.
 Dans le domaine: le présent travail est fait sur un établissement de vente au

détail proposant en libre-service2 des produits alimentaires, plus précisément
l’Alimentation DU MIDI;
 Dans l’espace: le présent travail se limite à la Gestion des approvisionnements,
des ventes des produits ainsi que la Gestion des fournisseurs de l’Alimentation
DU MIDI;
 Dans le temps: l’Application que nous réaliserons dans ce mémoire tiendra
compte des opérations d’entrées et sorties des produits actuels dans
l’Alimentation DU MIDI issues des données que nous avons recueillies à partir du
mois de Septembre 2014 jusqu’au mois de Juillet 2015.
0.5. Problématiques
L’alimentation DU MIDI connaît certaines irrégularités dans son système de gestion.

Avec un nombre de clients de plus en plus croissant, la gestion manuelle des différentes
activités de cette alimentation devient de plus en plus délicate. Les principaux problèmes
auxquels fait face l’Alimentation DU MIDI sont les suivants :
 Temps suffisamment long pris par les services de l’alimentation pour répondre aux
demandes des clients, dans l’élaboration et diffusion des commandes et factures ;
 Accès difficile aux données de l’alimentation en temps voulue;
 Insécurité des données ;
 Difficultés de trouver des fournisseurs répondant aux normes;
 Petite portée du marché;
 Absence de données à base desquelles on peut faire une étude stratégique.
2
magasin où le client se sert lui-même.
3
0.6. Objectifs
0.6.1. Objectif global

En général, notre objectif est de pouvoir mettre à la disposition de l’alimentation DU MIDI
un outil qui leur permettra de répondre à leurs préoccupations citées dans la partie 0.5.
0.6.2. Objectifs spécifiques

Spécifiquement, le système que nous allons mettre à la disposition de l’alimentation DU
MIDI permettra :
 La Rapidité des services de vente pour répondre à la demande d’un client ;

 L’accès facile aux données de l’alimentation permettant ainsi au responsable de
prendre des décisions et une meilleure suivie des activités en temps réel ;
 Le stockage des données sur les supports informatiques pour les rendre exploitable
facilement ;
 La facilité de trouver les fournisseurs selon les souhaits ;
 La rapidité d’élaboration et diffusion des commandes ;
 La rapidité d’élaboration des factures ;
 La facilité de retrouver les redevances d’un client ;
 L’élargissement de la portée du marché ;
 La Rapidité dans l’élaboration et l’édition des factures pro forma.
0.7. Méthodologies et techniques utilisées

Au cours du présent travail, nous faisons recours aux méthodes et techniques scientifiques
ainsi qu’à des outils appropriés, comme toute autre recherche scientifique nous avons
procéder par :
 L’entretien : nous nous sommes entretenus avec le personnel de l’alimentation DU

MIDI pour qu’ils puissent nous expliquer les procédures de vente,
d’approvisionnement et de gestion appliquées à l’entrée et à sorties des produits ;
 L’observation : Pour bien comprendre les processus de gestion de cette alimentation

nous avons pris du temps suffisant d’observation des opérations effectuées par le
personnel mais aussi en allant nous-même acheter certains produits ;
 La documentation : Nous avons consulté différents livres, tutoriels3, mémoires sur

terrain ainsi que les sites web4.
3
Logiciel, programme, destine à l’apprentissage du fonctionnement et de l’utilisation d’une autre application.
4
Ensemble de pages web hyperliées entre elles et mises en ligne à une adresse web.
4
0.8. Articulation du sujet
Le présent travail intitulé « Conception et implémentation d’une application web de

gestion des entrées et sorties des produits dans l’alimentation DU MIDI » est réparti en
trois chapitres hormis l’introduction générale :
 Dans le premier chapitre, nous faisons la présentation générale de l’alimentation DU

MIDI ;
 Le second chapitre présente la méthode d’analyse et de conception par le langage de
modélisation UML, à base duquel nous modéliserons le nouveau système ;
 Le dernier chapitre concerne la présentation de l’application, l'évaluation de cette
dernière pour vérifier que les résultats correspondent aux objectifs fixés.
5
CHAPITRE I. PRESENTATION GENERALE DE L’ALIMENTATION DU MIDI
I.0. Introduction
Dans ce chapitre nous présentons brièvement le concept d’alimentation et de son

système d’information par après, nous procédons à l’analyse du système d’information de
notre domaine de travail.
I.1. Concept alimentation
D’après le dictionnaire LE NOUVEAU PETIT ROBERT, une Alimentation est un

magasin spécialisé dans la commercialisation des denrées alimentaires [14].
Selon Wikipédia, Une Alimentation est un établissement de vente au détail

proposant en libre-service5 des produits alimentaires [16].
Ainsi, nous pouvons dire, qu’une alimentation est un magasin ou une boutique6
qui, en général vend des produits alimentaires.
I.2. Présentation de l’alimentation DU MIDI
L’alimentation DU MIDI est une maison de vente pour la plupart des produits
alimentaires. Elle est localisée au centre-ville de BUJUMBURA capitale du Burundi, Quartier
ROHERO, sur la chaussée du Prince Louis RWAGASORE, plus précisément en face de l’ancien
marché central de Bujumbura.
L’alimentation DU MIDI a pour mission de vendre des produits alimentaires à toute la

population à un prix abordable.
I.3. Analyse de l’existant
Au moment des visites et des interviews à l’alimentation DU MIDI, nous avons pu constater
que pour promouvoir le bon fonctionnement de l’alimentation, les services de cette dernière
collaborent avec l’extérieur (fournisseurs) afin de satisfaire sa clientèle.
En effet, pour pouvoir fonctionner l’alimentation dépend en grande partie des produits en
provenance des fournisseurs. D’après le gestionnaire, les produits que l’alimentation
commercialise sont recueillis des points divers et en petite quantité suite au manque de
fournisseurs potentiels car d’une part, il doit lui-même se déplacer pour les chercher et
d’autres part ceux qui amènent eux-mêmes des produits ont souvent des quantités non
satisfaisantes pour l’alimentation. Une fois que les produits sont arrivés, le gestionnaire les
5
magasin où le client se sert lui-même.
6
Une maison consacrée à un commerce de détail ou, à la fois, à la fabrication et à la vente.
6
enregistre et les comptabilisent ensemble avec le caissier. Ils apposent des signatures qui
serviront dans le contrôle hebdomadaire.
Le fournisseur peut alors retirer son argent relative à la quantité qu’il a apporté. Tout doit
s’opérer en présence des trois. Si ce n’est pas un fournisseur avec qui ils se connaissent déjà
l’alimentation est contrainte de payer en totalité la somme au fournisseur. Les différents
produits sont rangés sur les étagères de l’alimentation selon les provenances et les qualités.
Ces derniers diffèrent les prix selon les qualités. Chaque produit est étiqueté de son prix et si
les produits sont nombreux les uns sont rangés dans les cartons.
Le personnel de l’alimentation ne se limite pas au Gestionnaire et au caissier cité ci-haut

dans nos paragraphes. S’il se présente un client, il est accueilli dans un premier temps par un
agent chargé de l’accueil de tout le monde qui sollicite un service de l’alimentation. Cette
personne oriente les visiteurs ou les clients au bon endroit selon les besoins de ces derniers,
et les aident dans la collecte des produits choisis.
Une fois que le client a effectué la collecte des produits qu’il souhaite, il les présente au
caissier qui effectue la somme des produits avec une petite machine calculatrice ou sur du
papier. Le caissier communique la somme au client qui selon ses moyens peut opter pour
retirer des produits. Si la somme lui convient, le caissier enregistre les produits dans le
registre pour constituer l’historique de vente et enfin, il établit une facture comportant tous
les articles choisis avec leurs quantités ainsi que le cachet de l’alimentation. S’il se présente
un client sollicitant une facture pro forma, le caissier appelle le gestionnaire qui rédige la
facture demandée sur son ordinateur portable et qu’il imprime dans les secrétariats publics
environnants.
L’alimentation DU MIDI possède entre autre le réfrigérateur pour conserver les produits qui
nécessitent une basse température et une microonde pour le chauffage de certains produits.
I.4. Critique de l’existant
Bien que le personnel fasse de son mieux pour l’avancement de l’alimentation, les
procédures d’entrée et de sorties des produits sont encore manuelles, ce qui entraine une
certaine faiblesse du système actuel.
Il essai de tenir à jour le stock grâce à leur registre, ceci se révèle être une lourde tâche qui
l’oblige de parcourir tous les reçus, comptabiliser les produits sortis par jour et mettre à jour
les documents. Cette situation conduit souvent aux erreurs et à une perte énorme de temps.
La vente quant à elle, elle est complètement manuelle. De plus, le personnel a du mal à se
souvenir de tous les produits en stock ce qui fait que si un client cherche le produit qui ne se
trouve pas dans le stock, le personnel doit parcourir la liste entière des produits. Ceci
conduit à une perte de temps et à un mauvais service fourni aux clients (lenteur).
7
Ce qui est plus ennuyant encore, à chaque fois qu'un client veut acheter des produits, le
personnel est obligé de calculer la somme que le client doit payer soit à la main, soit à l’aide
d’une machine calculatrice. La procédure devient fastidieuse.
Toutes ces limites du système actuel ont des répercussions sur la qualité du travail et par
conséquent un effet négatif sur les résultats escomptés de l’alimentation.
C'est dans cette situation que nous avons réalisé qu'un outil spécialisé qui automatise ces
tâches est nécessaire pour pouvoir améliorer la qualité du service offert, diminuer les
erreurs qui peuvent conduire à une faillite et aussi disposer des informations dont
l’alimentation a besoin au moment voulu.
I.5. Solutions proposées
Dans ce projet, nous nous proposons alors de pallier à ces problèmes cités ci-haut en
mettant en place un outil capable de résoudre les défis liés à la gestion des entrées et sorties
des produits de l’alimentation DU MIDI.
La dite solution consiste en la création d'une application web permettant :
 d’alléger considérablement le travail lié à la gestion de stocks ;

 des traitements plus rapides ;
 de faciliter l’élaboration et la transmission des factures ;
 l’élaboration des factures pro forma ;
 de chercher et faciliter la communication entre l’alimentation et les fournisseurs ;
 de faciliter la réservation des produits étant à distance ;
 d’avoir à temps des informations nécessaires à la prise de décision ;
 une sécurité et une sauvegarde des données plus sûres ;
 Le contrôle du personnel facilement.
L’exploitation de l’application sera rendu facile par l’achat du matériel nécessaire dont
l’alimentation ne possède pas pour le moment, son hébergement sur un serveur accessible
publiquement grâce au réseau internet et la formation des employés.
8
CHAPITRE II. CONCEPTION DU NOUVEAU SYSTÈME DE GESTION DES ENTRÉES ET

SORTIES DES PRODUITS POUR L’ALIMENTATION DU MIDI
II.0. Introduction
Pour faire face à la complexité croissante des systèmes d’information, de nouvelles

méthodes et outils ont été créés. La principale avancée des quinze dernières années réside
dans la programmation orientée objet (P.O.O.). Face à ce nouveau mode de programmation,
les méthodes de modélisation classique ont rapidement montré certaines limites et ont dû
s’adapter, de très nombreuses méthodes ont également vu le jour comme Booch, OMT7 …
Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception «

Orientée objet », l’OMG8 (Object Management Group) a eu comme objectif de définir une
notation standard utilisable dans les développements informatiques basés sur l’objet.
C’est ainsi qu’est apparu UML (Unified Modified Language « langage de modélisation objet
unifié »), qui est issu de la fusion des méthodes Booch, OMT (Object Modelling Technique)
et OOSE9 (Object Oriented Software Engineering).
Issu du terrain et fruit d'un travail d'experts reconnus, UML est le résultat d'un large
consensus.
De très nombreux acteurs industriels de renommé ont adopté UML et participent à son
développement.
Comme le montre la figure ci-dessous, en l'espace d'une poignée d'années seulement, UML
est devenu un standard incontournable [2].
Figure 1 : Evolution du langage UML
7
Méthode de spécification par modélisation des besoins à la mode en 1995.
8
L’OMG (Object Management Group) est une association américaine à but non-lucratif créée en 1989 dont
l’objectif est de standardiser et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la
base des spécifications UML, MOF, CORBA et IDL. L’OMG est aussi à l’origine de la recommandation MDA
9
Méthode d’analyse et de conception orienté objet
9
UML sert principalement à :
 Décomposer le processus de développement ;

 Mettre en relation les experts métiers et les analystes ;
 Coordonner les équipes d'analyse et de conception ;
 Séparer l'analyse de la réalisation ;
 Prendre en compte l'évolution de l'analyse et du développement ;
 Migrer facilement vers une architecture objet d'un point de vue statique et
dynamique.
UML est vaste, et plusieurs ouvrages consacrent plusieurs centaines de page pour couvrir
tous les notions de ce langage. Nous ne prévoyons pas être exhaustifs dans ce travail, toute
fois nous estimons que c’est important de présenter quelques diagrammes que nous avons
utilisés [11].
II.1. Présentation des diagrammes UML
UML dans sa version 2 propose quatorze diagrammes qui peuvent être utilisés pour la
description d’un système. Ces diagrammes sont regroupés dans deux grands ensembles dont
[11]:
Les diagrammes structurels : ont vocation de représenter l’aspect statique d’un système. Ils
permettent d’identifier les objets constituant le programme, leurs attributs, leurs opérations
et les méthodes qui leurs sont associés. Ils sont au nombre de six à savoir :
 Diagramme de Classe ;
 Diagramme d’objet ;
 Diagramme de composant ;
 Diagramme de déploiement ;
 Diagramme de Paquetage ;
 Diagramme de structure composite.
Les diagrammes de comportement : Ces diagrammes représentent la partie dynamique d’un

système réagissant aux événements et permettant de produire les résultats attendus par les
utilisateurs. Sept diagrammes sont proposés par UML :
 Diagramme des cas d’utilisation ;
 Diagramme d’état-transition ;
 Diagramme d’activités ;
 Diagramme de séquence ;
 Diagramme de communication ;
 Diagramme global d’interaction ;
 Diagramme de temps ;
 Diagramme de profil.
10
II.1.1. Diagramme de Classes
Le diagramme de classes est le point central dans un développement orienté objet. En

analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs.
En conception le diagramme de classes représente la structure d’un code oriente objet ou, à
un niveau de détail plus important, les modules du langage de développement [2].
Figure 2 : Exemple de diagramme de classe
La description du diagramme de classe est fondée sur :
-Le concept d’objet ;

-Le concept de classe comprenant les attributs et les opérations ;
-Les différents types d’association entre classes [11].
 Classe
Une classe représente la description abstraite d’un ensemble d’objets possédant les mêmes
caractéristiques. On peut parler également de type [2].
Exemple : La classe personne, la classe voiture.
Une classe se représente à l’aide d’un rectangle comportant plusieurs compartiments :

Les trois compartiments de base sont :
o la désignation de la classe ;
o la description des attributs ;
o la description des opérations.
11
Deux autres compartiments peuvent être aussi indiqués :
o la description des responsabilités de la classe ;

o la description des exceptions traitées par la classe.
 Objet
Un objet est une entité aux frontières bien définies, possédant une identité et encapsulant
un état et un comportement. Un objet est une instance(ou Occurrence) d’une classe [2].
Par exemple : MUGISHA Fabrice est une instance de la classe Personne. Le présent livre est
une instance de la classe livre.
 Visibilité des attributs et opérations
Chaque attribut ou opération d’une classe peut être de type public, protégé, privé ou
paquetage. Les symboles + (public), # (protégé), - (privé) et ~ (paquetage) sont indiqués
devant chaque attribut ou opération pour signifier le type de visibilité autorisé pour les
autres classes. Les droits associés à chaque niveau de confidentialité sont :
• Public (+) : Attribut ou opération visible par tous.
• Protégé (#) : Attribut ou opération visible seulement à l’intérieur de la classe et pour

toutes les sous-classes de la classe.
• Privé (-) : Attribut ou opération seulement visible à l’intérieur de la classe.
• Paquetage (~) : Attribut ou opération ou classe seulement visible à l’intérieur du

paquetage où se trouve la classe.
 Attribut et Opération
Un attribut représente un type d’information contenue dans une classe.
Exemples : Le nom, prénom, Année_de_naissance, etc. sont les attributs de la classe

Personne ;
Une Opération représente un élément de comportement (un service) contenu dans une
classe. Nous ajouterons plutôt les opérations en conception objet, car cela fait partie des
choix d’attribution des responsabilités aux objets.
 Association
Une Association représente une relation sémantique durable entre deux classes.
Exemple : Une personne peut posséder des voitures. La relation possède est une association
entre les classes Personne et voiture.
12
Même si le verbe qui nomme une association semble privilégier un sens de lecture, une
association entre concepts dans un modèle du domaine est par défaut bidirectionnelle. Donc
implicitement, l’exemple précédent inclut également le fait qu’une voiture est possédée par
une personne [2].
Comment les représenter ?
Aux deux extrémités d’une Association, on doit faire figurer une indication de multiplicité.
Elle spécifie sous la forme d’un intervalle d’entiers positifs ou nuls le nombre d’objets qui
peuvent participer à une relation avec un objet de l’autre classe dans le cadre d’une
association [2].
Exemple : Une personne peut posséder plusieurs voitures (entre zéro et un nombre
quelconque) ; une voiture est possédée par une seule personne.
Figure 3 : Exemple d’une multiplicité d’association
 La multiplicité
La multiplicité indique un domaine de valeurs pour préciser le nombre d’une instance

d’une classe vis-à-vis d’une autre classe pour une association donnée. La multiplicité peut
aussi être utilisée pour d’autres usages comme par exemple un attribut multi-valué.
Le domaine de valeurs est décrit selon plusieurs formes :
 Intervalle fermé Exemple : 2, 3, ..15 ;

 Valeurs exactes Exemple : 3, 5, 8 ;
 Valeur indéterminée notée * Exemple : 1..* ;
 Dans le cas où l’on utilise seulement *, cela traduit une multiplicité 0..*.
Dans le cas de multiplicité d’associations, il faut indiquer les valeurs minimale et maximale
d’instances d’une classe vis-à-vis d’une instance d’une autre classe.
13
Figure 4 : Exemple de multiplicité
 Agrégation et composition
Une agrégation est un cas particulier d’association non symétrique exprimant une relation
de contenance. Les agrégations n’ont pas besoin d’être nommées : implicitement elles
signifient <<contient>>, <<et composé de>>.
Une composition est une agrégation plus forte impliquant que :
 Un élément ne peut appartenir qu’a un seul agrégat composite (agrégation non

partagée) ;
 La destruction de l’agrégat composite entraine la destruction de tous ses éléments (le
composite est responsable du cycle de vie des parties).
Figure 5 : Exemple d’agrégation et de composition

14
 GENERALISATION, SUPER-CLASSE, SOUS-CLASSE
Une Super-classe est une classe plus générale reliée à une ou plusieurs autres classes plus
spécialisées (Sous classes) par une relation de généralisation. Les sous-classes <<héritent >>
des propriétés de leur super-classe et peuvent comporter des propriétés spécifiques
supplémentaires.
Exemple : les voitures, les bateaux et les avions sont des moyens de transport. Ils possèdent
tous une marque, un modèle, une vitesse, etc. Par contre, seuls les bateaux ont un tirant
d’eau et seuls les avions ont une altitude
…
Figure 6 : Exemples de super-classes et sous-classes
Une classe abstraite est simplement une classe qui ne s’instancie pas directement mais qui
représente une pure abstraction afin de factoriser des propriétés communes. Elle se note en
italique. C’est le cas de Moyen de Transport dans l’exemple précédent.
II.1.2. Diagramme de Déploiement
Le diagramme de déploiement montre la configuration physique des différents matériels qui

participent à l’exécution du système, ainsi que les artefacts qu’ils supportent.
Ce diagramme est constitué de « nœuds » connecté par des liens physiques. Les symboles
des nœuds peuvent contenir des artefacts [2].
15
 Nœud
Un nœud correspond à une ressource matérielle de traitement sur laquelle des artefacts
seront mis en œuvre pour l’exploitation du système. Les nœuds peuvent être interconnectés
pour former un réseau d’éléments physiques. Un nœud ou une instance de nœud se
représente par un cube ou parallélépipède
 Artefact
Un artefact est la spécification d’un élément physique qui est utilisé ou produit par le
processus de développement du logiciel ou par le déploiement du système. C’est donc un
élément concret comme par exemple : un fichier, un exécutable ou une table d’une base de
données.
Figure 7 : Exemple d’un diagramme de déploiement
II.1.3. Diagramme de Comportements
Les diagrammes comportementaux sont focalisés sur la description de la partie dynamique

du système à modéliser. Ces diagrammes représentent la partie dynamique d’un système
réagissant aux événements et permettant de produire les résultats attendus par les
utilisateurs. Le modèle dynamique montre le comportement du système et l’évolution des
objets dans le temps. Il va identifier les différents événements venant du monde externe et
montrer l’enchaînement dans le système que provoquent ces événements externes.
Un événement : c’est quelque chose qui se produit à un moment donné dans le temps et qui
n’a pas de durée.
II.1.4. Diagramme de Cas d’utilisations
Ce diagramme permet de faire le point sur les besoins des acteurs par rapport au système. Il
comprend les fonctionnalités fournies par le système (cas d'utilisation), les utilisateurs qui
interagissent avec le système (acteurs), et les interactions entre ces derniers. Un diagramme
16
de cas d’utilisation capture le comportement d’un système, tel qu’un utilisateur extérieur le
voit.
Il constitue un des diagrammes les plus structurants dans l’analyse d’un système.
Les composants de base d’un diagramme des cas d'utilisations sont: l’acteur, le cas
d’utilisation et l’interaction entre l’acteur et le cas d’utilisation.
 Acteur
Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le système étudié.
Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou
en recevant des messages susceptibles d’être porteurs de données.
La représentation graphique standard de l’acteur en UML est l’icône appelée stick man, avec
le nom de l’acteur sous le dessin. On peut également figurer un acteur sous la forme
rectangulaire d’une classe, avec le mot-clé « actor ». Une troisième représentation
(intermédiaire entre les deux premières) est également possible avec certains outils, comme
cela est indiqué ci-après.
Figure 8 : Représentations graphiques possibles d’un acteur
Une bonne recommandation consiste à faire prévaloir l’utilisation de la forme graphique du

stick man pour les acteurs humains et une représentation rectangulaire pour les systèmes
connectés.
 Cas d’utilisation
Un cas d’utilisation ou un (« use case ») représente un ensemble de séquences d’actions qui

sont réalisées par le système et qui produisent un résultat observable intéressant pour un
acteur particulier.
Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme un

tout, sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce que
le futur système devra faire, sans spécifier comment il le fera.
17
Le diagramme de cas d’utilisation est un schéma qui montre les cas d’utilisation (ovales)
reliés par des associations (lignes) à leurs acteurs (icône du « stick man », ou représentation
graphique équivalente). Chaque association signifie simplement «participe à ». Un cas
d’utilisation doit être relié à au moins un acteur.
Figure 9 : Exemple d’un diagramme de cas d’utilisation
o Relations entre cas d’utilisation
Afin d’optimiser la formalisation des besoins en ayant recours notamment à la réutilisation

de cas d’utilisation, trois relations peuvent être décrites entre cas d’utilisation : une relation
d’inclusion (« include »), une relation d’extension (« extend ») et une relation de
généralisation.
 Une relation d’inclusion d’un cas d’utilisation A par rapport à un cas d’utilisation B
signifie qu’une instance de A contient le comportement décrit dans B.
 Une relation d’extension d’un cas d’utilisation A par un cas d’utilisation B signifie
qu’une instance de A peut être étendue par le comportement décrit dans B.
 Une relation de généralisation de cas d’utilisation peut être définie conformément
au principe de la spécialisation-généralisation déjà présentée pour les classes.
II.1.5. Diagramme d’Etat-transition
UML a repris le concept bien connu de machine à états finis, qui consiste à s’intéresser au
cycle de vie d’une instance générique d’une classe particulière au fil de ses interactions avec
le reste du monde, dans tous les cas possibles. Cette vue locale d’un objet, qui décrit
comment il réagit a des évènements en fonction de son état courant et comment il passe
dans un nouvel état, est représentée graphiquement sous la forme d’un diagramme d’états
[2].
18
Figure 10 : Notion de base du diagramme d’Etats
 Etat
Un état représente une situation durant la vie d’un objet pendant laquelle :
• Il satisfait une certaine condition ;
• Il exécute une certaine activité ;
• Ou bien il attend un certain événement.
Un objet passe par une succession d’états durant son existence. Un état a une durée finie,
variable selon la vie de l’objet, en particulier en fonction des évènements qui lui arrivent.
Etat initial et état final
En plus de la succession d’états « normaux » correspondant au cycle de vie d’un objet, le

diagramme d’états comprend également deux pseudo-états :
• L’état initial du diagramme d’états correspond à la création de l’instance.

• L’état final du diagramme d’états correspond à la destruction de l’instance.
 Transition
Une transition décrit la réaction d’un objet lorsqu’un événement se produit (généralement
l’objet change d’état). En règle générale, une transition possède un événement déclencheur,
une condition de garde, un effet et un état cible.
 Evénement
Un événement est un fait survenu qui déclenche une transition. Un événement se produit à
un instant précis et est dépourvu de durée. Quand un événement est reçu, une transition
peut être déclenchée et faire basculer l’objet dans un nouvel état.
 Effet : Action ou Activité [2]

Une transition peut spécifier un comportement optionnel réalisé par l’objet lorsque la
transition est déclenchée. Ce comportement est appelle « effet » : cela peut être une simple
action ou une séquence d’actions (une activité). Une action élémentaire peut représenter la
19
mise à jour d’un attribut, un appel d’opération, la création ou la destruction d’un autre
objet, ainsi que l’envoi d’un signal a un autre objet. Les activités associées aux transitions
sont considérées comme atomiques, c’est-à-dire qu’elles ne peuvent être interrompues. Ce
sont typiquement des séquences d’actions.
Les activités durables (do-activity), au contraire, ont une certaine durée, sont interruptibles
et sont donc associées aux états.
Figure 11 : Notion plus complète du diagramme d’états
II.1.6. Diagramme d’Activités
Le diagramme d’activité présente un certain nombre de points communs avec le diagramme

d’état-transition puisqu’il concerne le comportement interne des opérations ou des cas
d’utilisation. Cependant le comportement visé ici s’applique aux flots de contrôle et aux flots
de données propres à un ensemble d’activités et non plus relativement à une seule classe.
Les concepts communs ou très proches entre le diagramme d’activité et le diagramme
d’état-transition sont [11]:
• Transition ;
• Nœud initial (état initial) ;
• Nœud final (état final) ;
• Nœud de fin flot (état de sortie) ;
• Nœud de décision (choix).
20
Les concepts spécifiques au diagramme d’activité sont [11]:
 Nœud de bifurcation : un nœud de bifurcation (fourche) permet à partir, d’un flot

unique entrant, de créer plusieurs flots concurrents en sortie de la barre de
synchronisation.
 Nœud de jonction : un nœud de jonction (synchronisation) permet, à partir de
plusieurs flots concurrents en entrée de la synchronisation, de produire un flot
unique sortant. Le nœud de jonction est le symétrique du nœud de bifurcation.
 Nœud de test-décision : un nœud de test-décision permet de faire un choix entre
plusieurs flots sortants en fonction des conditions de garde de chaque flot. Un nœud
de test-décision n’a qu’un seul flot en entrée. On peut aussi utiliser seulement deux
flots de sortie : le premier correspondant à la condition vérifiée et l’autre traitant le
cas sinon.
 Nœud de fusion-test : un nœud de fusion-test permet d’avoir plusieurs flots entrants
possibles et un seul flot sortant. Le flot sortant est donc exécuté dès qu’un des flots
entrants est activé.
 Pin d’entrée et de sortie : un pin d’entrée ou de sortie représente un paramètre que
l’on peut spécifier en entrée ou en sortie d’une action. Un nom de données et un
type de données peuvent être associés au pin. Un paramètre peut être de type objet.
 Nœud d’objet : un nœud d’objet permet de représenter le flot de données véhiculé
entre les actions. Les objets peuvent se représenter de deux manières différentes :
soit en utilisant le pin d’objet soit en représentant explicitement un objet.
 Partition : UML permet aussi d’organiser la présentation du diagramme d’activité en
couloir d’activités. Chaque couloir correspond à un domaine de responsabilité d’un
certain nombre d’actions.
21
Figure 12 : Exemple de diagramme d’activité avec couloir d’activité
II.1.7. Diagramme de Séquences
L’objectif du diagramme de séquence est de représenter les interactions entre objets en

indiquant la chronologie des échanges. Cette représentation peut se réaliser par cas
d’utilisation en considérant les différents scénarios associés.
- Ligne de vie
Une ligne de vie représente l’ensemble des opérations exécutées par un objet. Un message
reçu par un objet déclenche l’exécution d’une opération. Le retour d’information peut être
implicite (cas général) ou explicite à l’aide d’un message de retour.
22
- Message synchrone et asynchrone
Dans un diagramme de séquence, deux types de messages peuvent être distingués :
o Message synchrone – dans ce cas, l’émetteur reste en attente de la réponse à son

message avant de poursuivre ses actions. La flèche avec extrémité pleine symbolise
ce type de message. Le message retour peut ne pas être représenté car il est inclus
dans la fin d’exécution de l’opération de l’objet destinataire du message.
o Message asynchrone – dans ce cas, l’émetteur n’attend pas la réponse à son
message, il poursuit l’exécution de ses opérations. C’est une flèche avec une
extrémité non pleine qui symbolise ce type de message.
Figure 13 : Formalisme du diagramme de séquence
UML possède plus de diagramme que celles présenté ci-haut. Nous ne pouvons pas les
présenter tous dans ce projet, de peur que cela soit long et que beaucoup de livre explique
déjà toutes ses notions de façon claire avec des exemples à l’appui. Pour plus d’information,
nous conseillons la consultation des livres UML2 par la pratique, Conception de bases de
données avec UML [15], Analyse et Conception [2] et UML 2 pour les développeurs [14] qui
ont été notre principale source d’inspiration dans cette partie.
23
II.2. Modélisation du nouveau système de gestion des entrées et sorties des produits de
l’Alimentation DU MIDI
Dans ce chapitre, nous mettons en pratique la théorie UML annoncé dans le deuxième
chapitre, en modélisant notre nouveau système.
En vue de construire le modèle du système de gestion des entrées et sorties des produits
d’une alimentation, il nous faut respecter les deux axes de modélisation du standard UML à
savoir :
 l’axe dynamique ou comportemental;

 l’axe statique ou structurel.
II.2.1. Axe dynamique
L’axe dynamique permet de proposer un mode de fonctionnement du système à travers les

diagrammes des cas d’utilisation, d’activités, de séquences et d’états. Cet axe permet de
suivre la succession des différentes fonctions selon les modalités.
II.2.1.1. Diagramme des cas d’utilisation

Le diagramme des cas d’utilisation est un modèle de haut niveau destiné à concevoir les
besoins des utilisateurs. Les cas d’utilisation, en anglais « use cases » nous ont permis de
structurer les besoins des utilisateurs et les objectifs correspondant à notre système. Pour
cela, les cas d’utilisation identifient les utilisateurs du système (acteurs) et leurs interactions
avec le système. Avec ce diagramme, nous avons classé les acteurs et structuré les objectifs
du système. Ce diagramme nous a permis de comprendre le fonctionnement du système.
II.2.1.1.1. Identification des acteurs

Les différents acteurs intervenants dans notre système sont:
 le gestionnaire : il a pour rôle de gérer l’alimentation en général, les utilisateurs du système.

Donc, il les enregistre, les modifie, les attribuent des rôles. Il a aussi le rôle de gérer les
différentes prestations. Il pourra les enregistrer ou les modifier. C’est lui qui se charge des
enregistrements des fournisseurs;
 le caissier : il a pour rôle d’enregistrer les clients (a crédits) ou de les modifier. Il a aussi le
rôle d’enregistrer les produits entrant et sortant ainsi que les paiements des ventes et des
fournitures;
 le client : il peut réserver les produits en ligne ;
 le fournisseur : il peut proposer des prix sur des produits que l’alimentation souhaite
intégrer dans le stock, il peut voir les commandes qui lui sont affectées.
24
Voici donc le diagramme de cas d’utilisations que nous avons établi :
N.B : Le mot gérer pour notre cas englobe la recherche, la création, la modification, la
suppression ;
Figure 14 : Diagramme des cas d’utilisation de l’alimentation du midi

25
II.2.1.1.2. Description textuelles des cas d’utilisation
Notre diagramme de cas d’utilisation étant grande, ici nous avons pris en considération
quelques cas d’utilisation les plus courant pour la description textuelle.
a) Cas d’utilisation : S’authentifier
Sommaire d’identification
Titre : L’authentification d’un utilisateur.
Résumé : Ce cas d’utilisation permet à l’utilisateur de s’authentifier pour accéder au

système réservé aux utilisateurs.
Acteur : Utilisateur
A. Description des scénarios
Précondition : étant connecté à l’internet, la page d’accueil de l’application est appelée à

partir du navigateur web
Acteur Système
1. L’utilisateur appelle la page

d’authentification ;
2. Le système affiche page d’authentification ;
3. L’utilisateur saisit son identifiant (nom

4. Le système compare les informations saisies
d’utilisateur et son mot de passe) puis valide ;
à celles de la base de données et affiche
l’interface réservé à l’utilisateur.
Tableau 1 : Scénario nominal du cas d’utilisation : S’authentifier
B. Enchainement Alternatif
Si le nom d’utilisateur et/ou le mot de passe ne sont pas correctes (à l’étape 3 du scénario
nominal) l’enchainement alternatif dirige l’utilisateur vers une page d’erreurs qui comprend
un lien vers la page d’accueil.
26
b) Cas d’utilisation : Elaborer une commande
Titre : L’élaboration d’une commande.
Résumé : Ce cas d’utilisation permet au Gestionnaire d’élaborer une commande.
Acteur : Gestionnaire
Précondition : l’Authentification.
Acteur Système
1. Le Gestionnaire choisit le menu commande;
2. Le système affiche la page correspondante

aux commandes;
3. Le Gestionnaire appelle le formulaire d’un
nouveau commande en cliquant sur le bouton
« nouveau commande » ;
4. Le système affiche le formulaire d’une
nouvelle commande ;
5. Le Gestionnaire choisit le produit, le

fournisseur; 6. le système propose au gestionnaire de saisir
la quantité;
7. Le Gestionnaire saisie la quantité et clique
le bouton ajouter;
9. Le Gestionnaire valide la commande ; 8. Le système ajoute la commande sur la liste ;
10. Le système informe le Gestionnaire via un

message que la commande a été bien crée.
Tableau 2 : Scénario nominal du cas d’utilisation : Elaborer une commande

27
Si le gestionnaire saisie une quantité négative ou égale à zéro (étape 8 du scénario nominal), le
système informe le gestionnaire que la quantité ne doit pas être inferieur ou égale à zéro,
l’enchainement alternatif recommence à l’étape 7 du scénario nominal.
c) Cas d’utilisation : Elaborer une facture pro forma
Titre : L’élaboration d’une facture pro forma.
Résumé : Ce cas d’utilisation permet au gestionnaire d’élaborer une facture pro forma.
Précondition : le Gestionnaire étant authentifié et le client ayant ses coordonnées dans le

système.
Acteur Système
1. Le Gestionnaire choisit le menu pro forma ;
2. Le système affiche l’interface d’élaboration

d’une facture pro forma ;
3. Le Gestionnaire choisit les produits que
souhaite le client, leurs quantités et les
ajoute sur le pro forma;
4. Le système calcule le prix total sur les produits ;
5. Le Gestionnaire demande l’impression du
facture pro forma ;
6. Le système imprime la facture pro forma.
Tableau 3 : Scénario nominal du cas d’utilisation : Elaborer une facture pro forma
Si le gestionnaire ajoute une quantité inférieure ou égale à zéro, le système lui informe que la
quantité ne doit pas être inférieure ou égale à zéro, l’enchainement alternatif recommence à
l’étape 3 du scénario nominal.
28
d) Cas d’utilisation : Réserver un produit
Titre : Réservation d’un produit.
Résumé : Ce cas d’utilisation permet au client de réserver un produit.
Acteur : Client
Précondition : connexion internet.
Acteur Système
1. Le client appelle la page d’accueil de

l’alimentation;
2. Le système affiche la page d’accueil de
l’application ;
3. Le client choisit le menu correspondant à la

réservation;
4. Le système affiche la page correspondante à

5. Le client choisit le produit qu’il veut la réservation ;
réserver ;
6. Le client saisit la quantité ;

7. Le système lui propose de saisir le mot clé ;
8. Le client valide la réservation;
9. Le système génère et affiche le nouveau

mot clé que le client présentera à
l’alimentation et informe le client que sa
réservation a été bien effectuée ;
Tableau 4 : Scénario nominal du cas d’utilisation : Réserver un produit

29
Si le client saisie une quantité inférieure ou égale à zéro, ou supérieur à la quantité disponible
au stock, le système lui informe via un message la marge de la quantité qu’il doit saisir.
L’enchainement alternatif recommence à l’étape 6 du scenario nominal.
e) Cas d’utilisation : proposer le prix
Titre : proposition du prix d’un produit.
Résumé : Ce cas d’utilisation permet au fournisseur de proposer le prix d’un produit.
Acteur : Fournisseur
Précondition : connexion internet et l’authentification fournisseur.
Acteur Système
2. Le système propose au fournisseur de saisir

le prix auquel il peut livrer le produit ;
1. Le fournisseur choisit le produit qu’il veut
proposer ;
5. Le système informe le fournisseur via un
3. Le fournisseur saisit le prix auquel il peut message que sa proposition a été bien
livrer le produit; effectuée;
4. Le fournisseur valide la proposition ;
Tableau 5 : Scénario nominal du cas d’utilisation : Proposer le prix
B. Enchainement alternatif
Si le fournisseur ne saisit pas le prix auquel il veut proposer le produit (étape 3 du scénario
nominal), l’enchainement alternatif redémarre à l’étape 2.
30
f) Cas d’utilisation : Ajouter une personne
Titre : Ajout d’une personne
Résumé : Ce cas d’utilisation permet au gestionnaire d’ajouter une personne.
Précondition : S’authentifier
Acteur Système
1. Le Gestionnaire choisit le Menu personne.

2. Le système affiche la page dédié aux
personnes.
3. Le Gestionnaire appelle le formulaire d’une

nouvelle personne en cliquant le bouton
« nouveau ». 4. Le système affiche le formulaire d’une
nouvelle personne.
5. Le Gestionnaire saisit les informations

relatives à une personne, puis valide. 6. Le système contrôle et compare les
informations saisies par rapport à celles
attendues
7. Le système informe le Gestionnaire via un

message que la personne a été bien
enregistrée.
Tableau 6 : Scénario nominal du cas d’utilisation : Ajouter un une personne
Si les informations saisies ne sont pas valides (étape 5 du scénario nominal), l’enchainement
alternatif redémarre à l’étape 4 du scénario nominal.
g) Cas d’utilisation : Vendre un produit (cash)
Titre : Vente d’un produit (Cash)
31
Résumé : Ce cas d’utilisation permet au caissier de vendre un produit (cash) se trouvant

dans le stock.
Acteur : Caissier
Pré-conditions : S’authentifier
Acteur Système
1. Le Caissier choisit le menu Vente.
2. Le système affiche la page de l’application

dédié à la vente des produits de l’alimentation.
3. Le Caissier ouvre le menu de recherche du
produit souhaité par le client et y saisit le nom 4. Le système affiche le résultat de la
du produit. recherche du produit trouvé.
5. Le Caissier saisit la quantité souhaité par le 6. Le système affiche le prix total

client. correspondant à la quantité totale souhaité
par le client.
7. Le Caissier ajoute le produit sur la liste de
vente.
8. Le Caissier confirme l’achat. 9. Le Système calcul le prix total, enregistre la

vente et met à jour le stock
10. Le Caissier lance l’impression de la facture;

11. Le système imprime la facture.
Tableau 7 : Scénario nominal du cas d’utilisation : Vendre un produit (cash)
Si le Caissier saisit la quantité qui n’est pas disponible dans le stock ou une quantité inférieure
ou égale à zéro (à l’étape 5), Le système affiche un message indiquant la quantité disponible
dans le stock et l’enchainement alternatif recommence à l’étape 5 du scenario nominal.
h) Cas d’utilisation : Vendre un produit (crédit)
Titre : Vente d’un produit (crédit)
32
Résumé : Ce cas d’utilisation permet au caissier de vendre un produit (crédit) se trouvant

dans le stock.
Acteur : Caissier
Pré-conditions : S’authentifier
Acteur Système
1. Le Caissier choisit le menu Vente ; 2. Le système affiche la page de l’application

dédiée à la vente des produits de
l’alimentation;
3. Le Caissier enregistre le client ;
4. Le Caissier ouvre le menu de recherche du 5. Le système affiche le résultat de la

produit souhaité par le client et y saisit le nom recherche de produit trouvé ;
du produit ;
6. Le Caissier saisit la quantité souhaité par le

client ;
7. Le Caissier ajoute le produit sur la liste de

vente ;
8. Le système calcule et affiche le prix total
9. Le Caissier saisit la somme présentée par le correspondant à la quantité totale souhaitée
client à la place du prix total généré par le par le client ;
système ;
10. Le Système calcule la différence qui est le
11. Le Caissier confirme l’achat ; crédit, enregistre la vente et met à jour le
stock ;
12. Le Caissier lance l’impression de la
facture ; 13. Le système imprime la facture.
Tableau 8 : Scénario nominal du cas d’utilisation : Vendre un produit (crédit)
Si le Caissier saisit la quantité qui n’est pas disponible dans le stock ou qui est inférieure ou
égale à zéro (à l’étape 6), Le système affiche un message indiquant la quantité disponible dans
le stock et l’enchainement alternatif recommence à l’étape 6 du scenario nominal.
33
Si le Caissier ne saisit pas le client (étape 3 du scénario nominal) Le système affiche un message
lui indiquant qu’il faut saisir le client, l’enchainement alternatif lui amène à l’étape 5 du
scenario nominal.
II.2.1.2. Diagramme d’Etat -transitions
Représentation du diagramme d’Etats-transition de l’objet produit dans notre système :
Figure 15 : Diagramme d’Etats-transition pour l’objet « produit »
II.2.1.3. Diagramme d’Activités
Les diagrammes d’activités nous permettent de décrire beaucoup plus en détails le flux des
activités pour chaque cas d’utilisation. Ici nous considérons le cas le plus courant qui est la
vente des produits :
34
Figure 16 : Diagramme d’activité de la vente des produits
II.2.1.4. Diagramme de Séquences
Il s'agit d'une explication détaillée d'un cas d'utilisation. Les principales informations contenues
dans un diagramme de séquence sont les messages échangés entre les objets de différentes
classes, présentés dans un ordre chronologique.
a) vendre des produits

35
Figure 17 : Diagramme de séquence <<Vente des produits>>
b) commander des produits

36
Figure 18 : Diagramme de Séquences <<commander des produits>>
II.2.2. Axe Statique
Précédemment nous avons parlé de deux grandes catégories de diagrammes UML (statique et
dynamique) l'un des diagrammes statiques nous intéresse beaucoup pour pouvoir implémenter
le code, il s'agit du diagramme de Classes.
II.2.2.1. Diagramme de Classes
Le schéma ci-dessous nous donne une vue globale de notre application. On a les classes
principales qui vont nous servir à réaliser l'application.
37
Figure 19 : Diagramme de classes

38
II.2.2.2. Diagramme de Déploiement
Enfin, nous terminons notre modélisation avec le diagramme de déploiement qui décrit
l’architecture physique de notre application.
Figure 20 : Diagramme de Déploiement

39
CHAPITRE III. PRESENTATION DE L’APPLICATION DE GESTION DES ENTREES ET SORTIES DES

PRODUITS
III.1. Introduction
Ce chapitre a pour objectif de présenter les pages utilisateurs de l’application web de Gestion
des entrées et sorties des produits d’une alimentation. Pour la réalisation de cette dernière,
nous avons utilisé UML comme langage de modélisation, MYSQL comme SGBD dans la création
de notre Base de Données(BD), JAVA comme langage de programmation, PRIMEFACES comme
framework10, et ECLIPSE comme IDE.
III. 2. Choix des outils utilisés
III.2.1. Choix du Système de Gestion de Base de Données (SGBD)
Un Système de Gestion de Base de Données (SGBD) est un logiciel (ou un ensemble de logiciels)
permettant de manipuler les données d'une base de données. Manipuler, c'est-à-dire
sélectionner et afficher des informations tirées de cette base, modifier des données, en ajouter
ou en supprimer (ce groupe de quatre opérations étant souvent appelé "CRUD" pour Create,
Read, Update et Delete) [11].
Il existe des dizaines de SGBD, chacun ayant ses avantages et ses inconvénients. Parmi les plus
connus on peut citer : MySQL, PostgreSQL, SQLite, Oracle Database, Microsoft SQL Server, MS
Access, etc. Certains sont payant et d'autres sont libres.
 MySQL : Il est donc un Système de Gestion de Bases de Données Relationnelles11, qui

utilise le langage SQL12. C'est un des SGBD les plus utilisés. Sa popularité est due en
grande partie au fait qu'il s'agit d'un logiciel Open Source 13[11].
 Oracle database : édité par Oracle Corporation (qui, édite également MySQL) est un
SGBDR payant. Son coût élevé fait qu'il est principalement utilisé par des entreprises.
Oracle gère très bien de grands volumes de données. Il est inutile d'acheter une licence
oracle pour un projet de petite taille, car les performances ne seront pas bien
différentes de celles d'un autre SGBD [11].
10 Ensemble de composants structurels permettant de construire des logiciels ou des sites internet.
11Les données sont contenues dans ce qu'on appelle des relations, qui sont représentées sous forme de tables.
12Langage informatique qui permet d'interagir avec des bases de données relationnelles.
13Code source librement disponible et que quiconque qui en ressent l'envie et/ou le besoin peut modifier pour l'améliorer ou
l'adapter à ses besoins.

40
 PostgreSQL : PostgreSQL est un logiciel Open Source. Il est cependant moins utilisé,
notamment par les débutants, car moins connu. La raison de cette méconnaissance
réside sans doute en partie dans le fait que PostgreSQL a longtemps été disponible
uniquement sous Unix. La première version Windows n'est apparue qu'à la sortie de la
version 8.0 du logiciel, en 2005 [11].
 MS Access : MS Access ou Microsoft Access est un logiciel édité par Microsoft (comme
son nom l'indique). Par conséquent, c'est un logiciel payant qui ne fonctionne que sous
Windows. Il n'est pas du tout adapté pour gérer un grand volume de données et a
beaucoup moins de fonctionnalités que les autres SGBD. Son avantage principal est
l'interface graphique intuitive qui vient avec le logiciel [11].
 La particularité de SQLite est de ne pas utiliser le schéma client-serveur utilisé par la

majorité des SGBD. SQLite stocke toutes les données dans de simples fichiers. Par
conséquent, il ne faut pas installer de serveur de base de données, ce qui n'est pas
toujours possible (certains hébergeurs web ne le permettent pas). Pour de très petits
volumes de données, SQLite est très performant. Cependant, le fait que les informations
soient simplement stockées dans des fichiers rend le système difficile à sécuriser (autant
au niveau des accès, qu'au niveau de la gestion de plusieurs utilisateurs utilisant la base
simultanément) [11].
 Microsoft SQL Server : le SGBD de Microsoft [5].
Suite à ces récapitulatifs des SGBD cites ci-haut, nous avons choisi MySQL pour la réalisation
d’une base de donnée de notre application de Gestion des entrées et sorties des produits d’une
alimentation, parce il présente plusieurs avantages :
 MySQL est rapide et stable. Ceci constitue la clé de son succès. Des études qui ont été
réalisées sur plusieurs bases de données majeures incluant ORACLE, Microsoft SQL
Server, DB2, et MySQL, l’étude a montré que MySQL et Oracle étaient les meilleurs.
 MySQL est un logiciel gratuit mais aussi commercial. Tous les logiciels MySQL demeurent
gratuits sous forme de ce qu’on appelle GPL (General Public Licence) mais on peut aussi
acheter une version commerciale si on en a besoin.
 MySQL soutient une grande majorité d’outils considérés comme importants par la
communauté de bases de données à savoir : les transactions, blocage basé sur une
ligne, clé étrangère, les sous requêtes et la recherche basée sur des mots complets.
41
 MySQL possède une grande adaptabilité. Il est utilisé par des clients très rigoureux
comme Yahoo ! Finance, Slashdot, US Census Bureau, Google, pour ne citer que ceux-là.
MySQL est un outil défiant toute concurrence concernant l’apprentissage de base de données
en général grâce à sa facilité d’installation et d’utilisation et l’espace très réduit qu’il occupe sur
le disque dur et la mémoire [13].
Le Modèle Client-serveur
La plupart des SGBD sont basés sur un modèle Client-serveur. C'est-à-dire que la base de
données se trouve sur un serveur qui ne sert qu'à ça, et pour interagir avec cette base de
données, il faut utiliser un logiciel "client14" qui va interroger le serveur et transmettre la
réponse que le serveur lui aura donnée. Le serveur peut être installé sur une machine
différente du client(le cas du web) ; c'est souvent le cas lorsque les bases de données sont
importantes.
Par conséquent, lorsque vous installez un SGBD basé sur ce modèle (c'est le cas de MySQL),
vous installez en réalité deux choses (au moins) : le serveur15, et le client. Chaque requête
(insertion/modification/lecture de données) est faite par l'intermédiaire du client. Jamais vous
ne discuterez directement avec le serveur (d'ailleurs, il ne comprendrait rien à ce que vous
diriez). Vous avez donc besoin d'un langage pour discuter avec le client, pour lui donner les
requêtes que vous souhaitez effectuer. Dans le cas de MySQL, ce langage est le SQL [13].
III.2.2. Choix du langage de Programmation
Bien qu'en théorie, on peut écrire l'application dans n'importe quel langage de programmation,
les langages présentent des fonctionnalités différentes qui peuvent devenir soit des avantages
soit des inconvénients dans certains cas selon les besoins de l'application. Dans notre cas, nous
souhaitons réaliser une application web. Ceci impose que le langage que nous allons choisir soit
un langage offrant des fonctionnalités de développement web. En ajoutant ce paramètre de
filtrage, notre choix s'est alors réduit aux langages les plus populaires suivants: PHP, JAVA, ASP,
PYTHON, ColdFusion, Ruby on rails, Django.
14
Les termes client dans ce livre peut prêter confusion car il sera utilisé dans deux contexte différents: Dans un
contexte économique, le client est celui qui prend la décision d'acheter un bien de consommation. En
Informatique, le mot client est utilisé dans le contexte du modèle client-serveur. Il peut désigner une machine
cliente qui accède à un service fourni par une machine distincte, ou l'utilisateur derrière cette machine ou le
logiciel qui réalise cet accès.
15
Logiciel ou ordinateur destiné à fournir un service à distance aux applications clients connectées au réseau.
42
Voici les raisons qui nous ont conduits à choisir finalement JAVA comme langage de
programmation:
-Prix : Il est gratuit,

-Portabilité : il s’'exécute dans presque n’ importe quel système d’exploitation
(Windows, Linux, Unix, Mac OS, téléphones mobiles, robots,...). Le slogan de JAVA est
“Write Once runEverywhere”,
-Flexibilité : Avec Java, on peut créer des applications desktop, web, mobile, interagir
avec différents SGBD, créer des programmes fonctionnant en réseaux (client /
Serveurs),…
-Extensibilité : Il existe des nombreuses bibliothèques et Frameworks tierces chacun

spécialisé dans un domaine spécifique. Il est donc rare de manquer la bibliothèque
appropriée pour les besoins courants,
-Orientée Objet : L'approche objet permet de bien concevoir les applications orientées
métiers,
-Disponibilité des outils : Java est un langage libre ce qui fait que de nombreux éditeurs
créent des outils de développement souvent libre. Ainsi des nombreux IDE, serveurs
web et serveurs d'application sont disponibles gratuitement sur le marché,
-Gestion efficace de la mémoire : Java intègre un mécanisme d'allocation et

désallocation automatique de la mémoire (Garbagecollector) permettant au
développeur de se concentrer sur la logique de l'application. La fuite de la mémoire est
le principal bug des logiciels écrits en C/C++,
-Disponibilité de plusieurs implémentations : Java est basé sur des spécifications JSR.
Ainsi lorsqu'une fonctionnalité est manquante, elle est soumise à la communauté via le
JSR, les décideurs de JAVA créent alors une spécification qui est rendu publique. Ce qui
permet à n'importe quel éditeur de développer une implémentation de la spécification,
-Bien maintenu : L'évolution du langage est assurée par Oracle et ses collaborateurs qui
effectuent des mises à jour régulières et des corrections de bugs. Il n'y a pas de risque
que le langage disparaisse du jour au lendemain,
-Une grande communauté : JAVA est le second langage le plus utilisé au monde. Ceci
indique la maturité du langage ce qui signifie qu’il y a beaucoup de ressources (Articles,
tutoriels, livres, cours, forums) à la disposition du programmeur.
43
III.2.3. Choix du Framework Prime faces
Sur un projet JSF il est très utile, voire indispensable, de sélectionner une bibliothèque de
composants graphiques pour gagner en productivité et efficacité. Cela évite de réinventer la
roue. Parmi les différentes bibliothèques disponibles, celle qui a particulièrement retenu notre
attention est PrimeFaces.
PrimeFaces est une bibliothèque développée par la société Prime Teknoloji,
Son créateur et principal développeur de PrimeFaces, Çağatay Çivici (@cagataycivici), est très
impliqué dans le monde JSF puisqu’il fait lui-même partie des membres de l’expert group JSF
[17].
Cette bibliothèque est open source (sous licence Apache License V2) et se compose de trois
projets :
 Prime UI pour les composants graphiques destinés principalement aux interfaces

desktop ;
 Prime Mobile pour les composants graphiques destinés aux appareils mobiles (basé sur
jQuery Mobile);
 PrimePush pour utiliser du push dans un navigateur en communication client-serveur
(basé sur la librairie Atmosphère).
PrimeFaces fonctionne uniquement sous JSF2.
Richesses des composants
L’intérêt principal de PrimeFaces réside dans la diversité et la qualité des composants proposés.
Ils sont nombreux, plus de 100, et répondent le plus souvent en standard aux besoins des
applications. Ce sont des composants graphiques avancés qui possèdent des fonctionnalités
prêtes à l’emploi, aidant ainsi à créer aisément des RIA (Rich Internet Application). L’ensemble
des composants est présenté dans une page de démonstration, avec le code (à la fois Xhtml et
Java) s’y rapportant [19].
Il existe 13 catégories de composants :
 AJAX Core : les fonctionnalités AJAX de PrimeFaces ;

 Input : De composant d’entrée utilisateur ;
 Button : Remplacement des boutons de JSF ;
 Data : Présentation des données ;
 Panel : Mise en page ;
 Overlay : Fenêtre de dialog ;
44
 Menu : Menus contextuels ;

 Charts : Graphiques ;
 Message : Messages destinés à l’utilisateur ;
 Multimedia : Intégration avec des images, utilisation d’une webcam ;
 File : Upload et download de fichier ;
 Drag Drop : Déplacement d’élément du DOM ;
 Misc : Catégorie fourre-tout (lecteur de flux rss, Captcha).
Comme certains pourraient le constater, les composants graphiques ressemblent à ceux de

jQuery ui, puisqu’ils étaient à la base des encapsulations de ces derniers. De cette
encapsulation il reste les classes css et la structure html du composant. C’est un gage de qualité
de rendu des composants.
Par ailleurs, le code généré est simple, lisible et évite (contrairement à RichFaces) l’utilisation
de tableaux pour la mise en page, ce qui est un plus indéniable.
Il est à noter que l’utilisation d’AJAX est très présente dans PrimeFaces. Par exemple, l’action
déclenchée par les boutons qu’il propose est par défaut en AJAX.
Voici quelques-uns des composants qui ont attiré le plus notre attention :
 AJAXStatus
Ce composant, facile d’utilisation, offre un indicateur lors des requêtes AJAX faites par les
composants PrimeFaces [20].
 Partial Submit
C’est un composant utile dans le cadre de l’optimisation d’une application car il permet de
réduire le trafic dans les requêtes AJAX en transmettant seulement le contenu de certains
composants d’entrée [21].
 Growl
Celui-ci affiche des messages à l’utilisateur à la manière du Growl sur Mac, c’est-à-dire à l’aide
de notifications [22].
45
Thèmes
Les nombreux thèmes disponibles dans PrimeFaces apportent un réel plus en ce sens qu’ils
rendent les applications particulièrement attrayantes, avec peu d’effort et de connaissances en
css. Par défaut PrimeFaces utilise le thème Aristo, rappelant les interfaces MacOS. De plus,
depuis peu le fameux thème du Twitter Bootstrap a été mis à disposition.
Ces thèmes se présentent sous la forme de jars contenant à la fois le css et les images dont il a
besoin. Les thèmes s’installent aisément dans le classpath et sont appliqués dans le web.xml.
Si un thème est conçu pour une entreprise en utilisant sa charte graphique, le jar créé peut être
ajouté aux applications utilisant PrimeFaces pour harmoniser leurs rendus. Il sera ainsi possible,
en cas de modification de la charte graphique de changer l’aspect général de ces applications
via un simple changement de jar. La tâche est ainsi largement simplifiée puisqu’elle évite ainsi
la modification du css des applications. C’est pour cela qu’il est parfois préférable d’utiliser les
composants PrimeFaces en remplacement de ceux fournis avec JSF, car ils utilisent par défaut le
thème sélectionné.
De plus, comme nous l’avons vu précédemment, les composants étaient initialement basés sur
jQuery UI, il est donc facile de créer des thèmes personnalisés via le ThemeRoller de jQuery
disponible sur http://jqueryui.com/themeroller/.
Communauté et suIIIi
Un des avantages indéniables est l’engouement et la communauté qui existent autour de

PrimeFaces. Nous trouvons ainsi aisément la réponse à ses questions et des solutions adaptées
à ses problèmes.
La documentation quant à elle, est complète et conséquente (près de 500 pages au format pdf).
Chaque composant y est décrit avec les paramètres offerts par le tag. Cependant la plupart du
temps, nous avons trouvé qu’il est plus simple d’aller sur la page de démonstration du
composant et de voir le code html et java associé pour en comprendre l’utilisation.
Le projet PrimeFaces quant à lui est régulièrement mis à jour, soit pour corriger des bugs soit
pour ajouter des nouvelles fonctionnalités. D’ailleurs la politique des développeurs est
d’intégrer gratuitement dans PrimeFaces les nouvelles fonctionnalités, initialement demandées
par les entreprises ayant un support payant.
Cet engouement a engendré le projet PrimeFaces Extensions qui apporte des fonctionnalités
supplémentaires à PrimeFaces, manquantes pour les développeurs.
46
Ce qui nous a intéressé le plus dans PrimeFaces est son approche web, respectueux des
standards et basé sur jQuery. Les composants sont également simples d’utilisations, mais
néanmoins puissants lorsqu’on les exploite avec plus de paramètres. Par exemple, il est
possible de passer d’un simple tableau à un tableau trié avec pagination en AJAX tout en faisant
du lazy-loading).
De plus, PrimeFaces s’installe sans difficulté dans un projet soit manuellement en plaçant
l’unique jar dans le classpath, soit via Maven en ajoutant le repository et la dépendance
suivante dans le pom.xml (http://primefaces.org/downloads.html). Puis il suffit de rajouter le
namespace « xmlns:p=http://primefaces.org/ui » dans la page xhtml pour indiquer que l’on
souhaite utiliser les composants PrimeFaces.
Enfin, sur notre projet nous hésitions entre PrimeFaces et RichFaces. Une des craintes provenait
de la pérennité du projet face au mastodonte qu’est RichFaces (JBoss). Nous avons fait le pari
de PrimeFaces sur ce projet et nous ne regrettons pas ce choix.
Ci-dessous le diagramme sur l’utilisation de Primefaces par rapport à richfaces et icefaces dès
2014 jusqu’aujourd’hui.
Figure 21 : Utilisation de Primefaces par rapport à Richfaces et Icefaces
III.2.4. Photoshop
« Photoshop est un logiciel de retouche, de traitement et de dessin assisté par ordinateur ».

Édité par Adobe Systems, il fait partie d'une longue suite logicielle touchant dans le domaine du
multimédia qui est connue sous le nom d'Adobe CreativeSuite (Photoshop, Illustrator, InDesign,
Dreamweaver, Flash, entre-autres).
Il est surtout utilisé pour le traitement de photos numériques (ce que l'on appelle plus
communément la retouche photographique), mais sert également à la création d'images.
47
"Reconnu principalement par les infographistes professionnels à travers sa puissante galerie de

filtres et d'outils graphiques performants, il est maintenant enseigné dans les plus grandes
écoles et est utilisé par une grande majorité des studios et agences de créations."
Adobe Photoshop est un logiciel dédié aux professionnels de l'imagerie informatique. Il s'agit
donc d'un programme payant (plus ou moins 1000 euros).
Pour ceux qui n'ont pas toute cette fortune, il existe une version d'évaluation de Photoshop qui
vous permet d'utiliser le programme avec toutes ses fonctionnalités pendant 30 jours, c'est
suffisant si vous faites preuve d'assiduité dans l’apprentissage [10].
Dans le présent travail, suite à une bonne connaissance de Photoshop, nous avons fait recours
à ce logiciel spécialement pour le traitement des images contenues dans les différentes
interfaces de notre application. Notons que nous avons utilisé quelques fonctionnalités de ce
logiciel qui nous permettent le redimensionnement des images et d’écrire dedans des titres à
notre convenance.
III.2.5. Optimisation du chargement de ressources
La manière dont les navigateurs chargent les ressources de l’application (images, fichiers CSS,
JavaScript) influent également sur les performances de l’application. Malgré les efforts fournis
pour optimiser les traitements effectués côtés serveurs, si le navigateur doit charger une page
qui contient plusieurs fichiers (images, fichiers CSS et JavaScript) l’application apparaitra
toujours moins performant.
Il existe de nombreux outils de mesure des performances de rendus des pages web comme
firebug16 , Page speed17 et YSlow18, pour ne citer que cela.
Ces plugins fournissent des outils pour inspecter le code source, mesurer le temps de
chargement de la page, suggérer les optimisations à apporter aux pages et bien d’autres
informations pratiques. Voici quelques règles qu’il est recommandé d’appliquer :
16
http://getfirebug.com/
17
https://developers.google.com/speed/pagespeed/
18
http://developer.yahoo.com/yslow/
48
Optimisation du CSS
Voici quelques règles d’optimisation du CSS : [11]
 Mettre le code CSS dans l’entête du document et dans un fichier à part : Mettre le CSS
dans un fichier à part permet au navigateur de pouvoir le mettre en cache et le mettre
dans l’entête permet de diminuer le temps de rendu ;
 Eviter certaines expressions CSS : Certains attributs comme @import sont connu d’avoir
des problèmes de performances. Yahoo developer Network19de préférer<link> à la
place ;
 Minimiser les fichiers CSS : Il faut utiliser des outils de compressions disponibles sur
internet comme CSS Compressor20qui éliminent les espaces entre les lignes pour réduire
la taille du fichier et diminuer ainsi le temps de chargement.
Optimisation des Images
Pour les images, il est recommandé de :
 Utiliser les tailles nécessaires des images : Il faut éviter de charger des grandes images et
réduire les tailles grâce aux attributs width et height ;
 Privilégier les sprites CSS : Un sprite CSS est une technique de chargement d’une seule
image qui contient plusieurs petites images qu’on affiche en jouant avec les attributs de
positionnement CSS. Cela évite aux navigateurs de charger plusieurs fichiers images à
chaque rechargement de la page ;
 Compresser les images : Smushit21 est un outil de compression d’images qui permet de
réduire le poids des images tout en gardant une bonne résolution pour réduire le temps
de chargement de ces derniers.
III.2.6. Choix de l’I.D.E
Bien qu'il soit possible de développer des applications avec un simple éditeur de texte comme
Notepad, personne ne se lance plus dans ce genre d'aventure d'autant plus que des outils
appropriés appelées I.D.E sont disponibles sur le marché.
L'environnement de développement intégré (Integrated Development Environment en anglais)
est un logiciel qui facilite le développement des applications regroupant les outils suivants :
 Un éditeur de texte : Un programme qui permet de saisir les codes. La plupart des IDE
modernes possèdent une coloration syntaxique qui facilite de repérer les erreurs
19
http://developer.yahoo.com/
20
http://iceyboard.no-ip.org/projects/css_compressor
21
www.smushit.com
49
syntaxique et l'auto-complétion de code qui augmentent considérablement la

productivité du programmeur ;
 Le compilateur : C'est un programme qui peut traduire le code source du programme en
un code compréhensible par l'ordinateur. (code binaire ou un code intermédiaire pour
les langages exécutés dans une machine virtuelle comme le JAVA ou le C#) ;
 Le débogueur : C'est un programme qui aide à repérer les erreurs logiques de
programmation en permettant de suivre pas par pas l'exécution du programme.
Le choix de l'IDE a été vite fait car après avoir éliminé les logiciels payants de nos choix
potentiels, il nous est resté uniquement deux IDE populaire concurrents à savoir Eclipse et
NetBeans.
Notre expérience avec Eclipse nous a poussés à le préférer par rapport à NetBeans. De plus
Eclipse est une plateforme très extensible, offrant la possibilité d'ajouter/supprimer des
fonctionnalités grâce à des plugins développés par les communautés tierces.
C'est cette particularité qui nous a finalement convaincu à l'adopter. En installant le plugin
JBOSS TOOLS, Eclipse parvient à supporter intégralement le développement JSF2 et Primefaces.
Ce plugin inclut des outils facilitant le développement des applications Primefaces (Wizard de
création de projet, auto-complétion de code, coloration syntaxique, gestion des serveurs,
déploiement automatique sur le serveur, etc.) ce qui simplifie considérablement certains
problèmes de développement et augmente la productivité.
50
III. 3. Présentation des pages de l’application
Dans cette partie nous mettons en œuvre les objectifs fixées en présentant l’application de
gestion des entrées et sorties des produits d’une alimentation via les interfaces.
En effet, notre application comprend deux principales parties : la partie publique et la partie
privée.
 La partie publique
 Qui donne la possibilité aux clients de voir les produits que l’alimentation est entrain
de vendre et de les réserver ;
 Qui permet à toute personne susceptible d’être fournisseur de visualiser les produits
que l’alimentation veut se procurer en proposant le prix sur lequel il peut le fournir.
 La partie privée
Cette partie est lié en général à la gestion interne de l’alimentation, spécifiquement la gestion
des entrées et sorties des produits. L’application est déployée sur un serveur et est accessible à
partir d’un poste client possédant un navigateur web, comme nous l’avons spécifié dans le
diagramme de déploiement au troisième chapitre.
III. 3.1. Démarrage de l’application
Après le lancement de l’application tout utilisateur voit l’interface ci-dessous :
Figure 22 : Page d'accueil de l'application

51
Description Sommaire de la page d’accueil
De 1 à 7 : Menu général de l’application ;
1: Permet de naviguer vers cette même page d’accueil ;

2: Permet de naviguer vers la page Boutique où le client a la possibilité de voir, choisir et
réserver les produits pour enfin passer les récupérer à l’alimentation ;
3: Permet de naviguer vers la page de proposition des prix (fournisseur), sur les produits que
l’alimentation veut se procurer ;
4,5 ,6 : permet de lier l’application vers les réseaux sociaux, spécifiquement vers facebook,
google+ et twitter ;
7 : Permet d’avoir l’aide de l’application ;
8 : Permet de choisir la langue dans lequel on veut utiliser l’application ;
9 : Permet de choisir le thème de l’application ;
10 : Le bouton d’authentification pour les utilisateurs interne de l’alimentation ;
11 : Slide show permettant de visualiser les images des produits en vente par l’alimentation ;
12 : Logo de l’alimentation ;
13 : Slide show Permettant de visualiser les produits que l’alimentation souhaite avoir des
fournisseurs ;
14 : Slide show permettant de faire les publicités de l’alimentation avec des images qui sont
chargées dynamiquement par le gestionnaire.
Utilisation
Le Menu allant de 1 à 7 permet de naviguer vers les différentes pages de l’application ainsi que
les liens vers les réseaux sociaux.
52
III. 3.2. Partie client
Cette page permet au client de visualiser les produits en vente par l’alimentation du midi, elle
permet au client de réserver des produits qu’il pourra récupérer plus tard ;
Figure 23 : Page de réservation des produits de l'alimentation du midi
Description sommaire de la page de réservation
1: Les produits en vente par l’alimentation du midi;

2: Le panier, qui va contenir les produits choisis par le client;
3 : Guide de réservation des produits.
Utilisation
Le client choisit un produit dans la partie (1), le glisse vers la partie (2) ensuite il apparait des
boutons lui permettant ainsi de réserver ces produits comme le montre la figure 23.
53
III. 3.2.1. Réservation des produits
Une fois que le client choisit ses produits, il continu la procédure de réservation en cliquant sur
le bouton réserver, qui fait apparaitre les produits choisit en détail ainsi que les champs pour la
saisie de la quantité et du mot clé.
Figure 24 : Réservation des produits
Description de l’interface
1 : Bouton permettant d’annuler ou de continuer le processus de réservation;

2 : Champ de saisie de la quantité souhaitée par le client;
3 : Champ de saisie du mot clé, que le client présente à l’alimentation;
4 : Bouton de réservation;
5 : Une fois la réservation effectuée, l’application génère un mot clé que le client récupère, c’est
ce dernier qu’il présentera à la caisse de l’alimentation.
Utilisation
En cliquant sur le bouton Réserver, il apparait une fenêtre montrant en détails les produits que
veux réserver le client, il saisit la quantité qui doit être inférieur ou égal à la quantité totale du
stock, il saisit ainsi le mot clé de son souhait ; Enfin en cliquant sur le bouton de confirmation, le
système lui génère le mot clé qu’il va présenter à la caisse.
54
III. 3.3. Proposition des prix par les fournisseurs
Cette page donne possibilité au fournisseur de proposer le prix à un produit qu’il souhaite
fournir.
Figure 25 : Page de proposition des prix (fournisseur)
Description et utilisation de l’interface
1 : Bouton permettant au fournisseur de se connecter pour avoir le droit de proposer le prix

auquel il peut fournir un produit, mais aussi pour voir les commandes qui lui sont attribuées
ainsi que ceux dont il n’a pas encore fini de livrer comme le montre la figure 25;
2 : Bouton permettant à une personne qui n’a pas encore le compte fournisseur de
s‘enregistrer;
3 : Les produits qui n’ont pas encore trouvé de fournisseurs;
4 : Ce champ est dynamique. D’une part, une fois que le fournisseur s’authentifie, il apparait un
bouton lui permettant d’envoyer ses propos, d’autre part s’il ne s’est pas encore authentifier le
bouton n’apparait pas;
5 : Guide pour la proposition des prix.
55
III. 3.3.1. Authentification d’un fournisseur
Figure 26 : Interface d'authentification d'un fournisseur
Description et utilisation de l’interface
Si le client clique sur le bouton se connecter, il obtient la possibilité de saisir son nom
d’utilisateur ainsi que son mot de passe, en confirmant si ces derniers sont correctes, il peut
voir les commandes qui lui sont attribuées ainsi que ceux dont il n’a pas encore fini de livrer.
III. 3.3.2. Visualisation des commandes d’un fournisseur
Une fois que le fournisseur arrive à s’authentifier, il apparait un lien qui lui indique la page à
partir de laquelle il peut voir les commandes qui lui sont attribuées et celles dont il n’a pas
encore fini de livrer.
Figure 27 : Visualisation des commandes d'un fournisseur

56
III. 3.4. Authentification des utilisateurs
Avant d’utiliser l’application, chaque utilisateur doit d’abord s’authentifier grâce à un

formulaire qui apparait en cliquant sur le bouton «se connecter » qui se trouve en haut à
gauche.
Figure 28 : Authentification des utilisateurs
Après authentification, l’utilisateur est redirigé vers la bonne page selon son profil. Si
l’utilisateur saisit mal ses identifiants, il est redirigé vers la page d’erreur :
Figure 29 : Page d'erreur

57
Si l’utilisateur est bloqué, le système génère une page lui renseignant sur les procédures à
suivre pour le déblocage ;
Notre système comporte deux profils dans la partie privée : Le Gestionnaire qui est le patron
en charge de l’approvisionnement et le caissier qui est charge des ventes.
III. 3.4.1. Vente des produits
Cette partie concerne le caissier, après son authentification, il est directement rediriger vers la
page de vente des produits :
Figure 30 : Page de vente des produits
1 : l’utilisateur connecté au système;

2 : bouton de déconnection pour quitter le système;
3-7 : menu caissier;
3 : page de vente et de livraison de produit réservé par les clients;
4 : Page permettant d’enregistrer les livraisons d’un fournisseur et de lui payer;
5 : Page d’enregistrement ou de modification d’un produit;
6 : Page permettant de visualiser un fournisseur;
7 : Page de visualisation des statistiques de l’alimentation;
58
8 : Menu contenant la liste des produits que le caissier peut vendre ;

9 : Menu contenant la liste de toutes les personnes déjà enregistrées dans le système ;
10 : Bouton permettant de créer un nouveau client ;
11 : prix du produit sélectionné au menu (8) ;
12 : Quantité que souhaite le client ;
13 : Bouton d’ajout d’un produit sur la liste de vente ;
14 : Bouton permettant de retirer un produit de la liste ;
15 : liste des produits qui apparaitront sur la facture ;
16 : Champ dans lequel le caissier saisit la somme payée par le client associé à un bouton de
validation de la vente et celui de l’impression de la facture ;
17 : Menu de visualisation des réservations faites par les clients et aussi en cliquant sur son plus
proche bouton à droite, il permet de visualiser les ventes déjà effectuées par conséquent le
caissier peut réimprimer la facture ;
18 : Ce menu associé à son bouton de validation permet de visualiser elle aussi les réservations
faites par les clients et on peut les annuler ;
19 : Ce menu permet de visualiser les réservations et ventes annulées pour les restaurer ;
20 : C’est la facture d’un client qui a réservé les produits, mais aussi celle qui peut être
réimprimée ;
21 : Cet ensemble de bouton a pour rôle de valider la réservation d’un client, supprimer des
produits s’il a changé d’avis mais aussi imprimer ou réimprimer la facture ;
22 : Menu permettant de visualiser les clients endettés ;
23 : Le champ contenant la somme totale que le client doit à l’alimentation et le bouton de
validation ;
24 : Liste des clients endettés.
Utilisation
Si le client se présente à l’alimentation, le caissier choisit les produits que le client désire (8),
saisit leurs quantités (12) et les ajoute sur la liste(13), il est possible de retirer un produit en le
choisissant sur la liste et de le supprimer à l’aide du bouton (14), s’il veut choisir le client et que
ce dernier est déjà enregistré dans le système, cette étape n’est pas obligatoire sauf dans le cas
où le client va acheter les produits à crédit. Il peut confirmer la vente(16) et imprimer la facture
qui apparait sur la figure 30.
59
Figure 31 : Facture du client
Si c’est la réservation, le gestionnaire cherche à l’aide du mot clé que le client présente (17).
L’ensemble des boutons (21), offre les possibilités de confirmer la vente effectuée à distance et
imprimer la facture, le client peut aussi décider de retirer les produits sur sa facture.
Au point (18), le gestionnaire peut annuler la réservation ce qui va mettre à jour le stock en
ajoutant la quantité qui avait été réservée (19) et vice versa du point (18).
Le Gestionnaire va aussi recevoir la somme payée par les clients endettés en sélectionnant le
client qui va payer (22).
60
III. 3.4.2. Réception des produits livrés par un fournisseur
Figure 32 : Réception des produits livrés
1 : Liste des fournisseurs n’ayant pas encore fini de livrer leur produit ;
2 : Liste des produits que va livrer le fournisseur choisit(1) ;
3 : quantité que va livrer le fournisseur ;
4 : Quantité totale du produit que l’alimentation avait commandée;
5 : Quantité restante ;
6 : Quantité déjà livrée ;
7 : Bouton permettant d’ajouter la livraison sur la liste ;
8 : Liste des produits prête à être livrée ;
9 : Série de boutons permettant d’enregistrer la livraison ou de retirer les produits de la liste ;
10 : Liste de fournisseurs ayant livrés leurs produits, qui n’ont pas encore retiré leur argent ;
11 : Liste de livraisons effectuées par le fournisseur ;
12 : Champ de saisie de la somme payée ;
13 : Bouton permettant d’ajouter la somme payée ;
14 : Facture confirmant le payement d’un fournisseur ;
15 : Paire de boutons l’un pour la confirmation du payement et l’autre pour l’impression de la
commande.
61
Utilisation
-La partie droite
Apres avoir attribué une commande par le gestionnaire à un fournisseur, le fournisseur se

présente pour livrer les produits. Le caissier cherche le fournisseur dans le menu (1) qui met à
jour le menu (2) pour visualiser les produits qu’il n’a pas encore livré. Dans le menu(2), il choisit
le produit que présente le fournisseur, ce dernier met à jour les champs (4), (5) et (6) pour
montrer respectivement la quantité totale qui doit être livrée, la quantité restante et celle qui
est déjà livrée. Il saisit ensuite la quantité à livrer pour le produit dans le champ de saisie (3),
ajoute (7) la livraison sur la liste (8) et à l’aide des boutons Enregistrer, il peut confirmer la
livraison ou supprimer (9) le produit de la liste (8). Signalons qu’en choisissant un de nouveau,
un autre fournisseur annulera la livraison du précédent.
-La partie Gauche (payement du fournisseur)
Le caissier sélectionne le fournisseur(10) automatiquement et la liste des livraisons effectuées

par ce dernier (11) se met à jour. En sélectionnant une livraison (11), la somme que
l’alimentation lui doit sur cette livraison est affichée (12). Le caissier peut modifier la somme en
lui payant moins selon l’argent liquide disponible (13), il peut aussi ajouter le montant sur la
somme totale de la facture et confirmer le payement ainsi que l’impression de la facture
comme le montre la figure 33.
Figure 33 : Facture de Payement d'un fournisseur

62
III. 3.4.3. Produit (partie caissier)
Sur cette page le client a la possibilité de manipuler les produits
Figure 34 : Enregistrement et mise à jour des produits
Description
1 : Bouton d’appel du fiche d’enregistrement d’un produit ;

2 : Bouton d’appel du fiche de modification d’un produit ;
3 : fiche de modification d’un produit ;
4 : fiche d’enregistrement d’un produit.
Utilisation
En cliquant sur le bouton créer produit (1) en bas, le caissier voit apparaitre une fiche (4) pour
créer un nouveau produit, il saisit les informations nécessaires et enregistre et directement la
liste des produits (5) se met à jour.
Le Bouton mettre à jour (2) lui permet d’appeler le formulaire pour modifier un produit déjà
enregistré de même que pour l’enregistrement d’un nouveau produit. S’il y a la confirmation de
la modification, la liste (5) est directement mise à jour.
63
III. 3.4.4. Visualisation d’un fournisseur (caissier)
Figure 35 : Visualisation des coordonnées d’un fournisseur
Description
1 : Menu contenant la liste des fournisseurs (3) ;

2 : Les cordonnées d’un fournisseur sélectionné au menu (1) ;
3 : liste des fournisseurs.
Utilisation
Pour un fournisseur qui se présente à l’alimentation pour y effectuer une opération (retrait
d’argent, livraison des produits,…..), le caissier voudra savoir si celui qui va effectuer l’opération
est réellement autorisé pour faire cette opération. Ce dernier va alors vérifier si les
informations se trouvant sur la carte correspondent à ceux du fournisseur sélectionné (2).
Signalons que le caissier n’a pas droit à la modification ou suppression des informations.
64
III. 3.4.5. Statistiques des ventes et la situation du stock (caissier)
Pour prendre des décisions relatives à son poste, chaque utilisateur peut voir les statistiques
des ventes hebdomadaires ainsi que la situation du stock.
Figure 36 : Tableau des statistiques (caissier).
Description et utilisation
1: Diagramme des statistiques des ventes des sept derniers jours ;

2 : Diagramme relevant la situation actuelle du stock.
Le caissier a la possibilité de voir sur le diagramme (1) les ventes effectuée toute la semaine
c'est-à-dire si on compte à partir du jour où nous sommes en retranchant 7 jours. Il peut
également voir la situation du stock actuelle (2) : donc les produits et leurs pourcentages.
65
III. 3.4.6. Page d’administration des personnes
Le gestionnaire est l’administrateur du système, c’est lui qui donne les tâches au sein de
l’alimentation, fait les contrôles du stock, organise l’interface de l’application, il peut donner ou
retirer des droits aux utilisateurs, etc.
Dans cette partie du gestionnaire, nous décrivons comme nous l’avons fait pour d’autres
utilisateurs certaines des fonctionnalités essentielles.
Figure 37 : Administration des personnes
Description et utilisation
1 : Liste des personnes actives dans le système ;

2 : bouton permettant d’appeler la fiche d’une nouvelle personne ;
3 : bouton permettant d’appeler le formulaire permettant de modifier et de supprimer une
personne.
Toute personne pouvant interagir avec le système apparait sur la liste (1), le gestionnaire peut
opérer des opérations de modification, de suppression ainsi que l’ajout d’une nouvelle
personne.
Lorsqu’une personne est enregistrée comme client, fournisseur ou bien utilisateur, des
informations communes pour toutes les personnes se trouvant dans la base de données
apparaissent directement dans la partie personne.
66
III. 3.4.7. Page d’administration des utilisateurs
Pour bien gérer l’entrée et la sortie des produits dans l’alimentation, le système a besoin des
utilisateurs à qui on associe les opérations effectuées, les rôles de chacun sont distribués par le
gestionnaire : il peut changer le rôle d’un utilisateur, modifier ses identifiants, le désactiver ou
l’activer.
Figure 38 : Administration des utilisateurs
Description
1 : Menu contenant les personnes qui n’ont pas encore de rôle;

2 : Bouton de création d’un nouveau utilisateur ;
3 : Bouton permettant d’appeler le formulaire de modification d’un utilisateur ;
4 : Bouton permettant d’appeler le formulaire de suppression d’un utilisateur ;
5 : Liste des utilisateurs.
Utilisation
Seul le gestionnaire a le droit d’accéder sur cette page. Pour créer un utilisateur, il complète le
formulaire au-dessous de la liste des utilisateurs (1) et valide (2). Pour modifier ou changer le
rôle d’un utilisateur, il appelle le formulaire grâce au bouton (3), de même pour supprimer, il
67
appelle le formulaire permettant de choisir et de supprimer l’utilisateur sélectionné. Notons

que si un utilisateur est supprimé, son identification reste dans la base de données.
III. 3.4.8. Gestion des fournisseurs
Le rôle du caissier a des limites sur cette page, par contre le gestionnaire peut modifier,
supprimer ou ajouter un fournisseur.
Figure 39 : Gestion des fournisseurs
Description
1 : Menu permettant de sélectionner un fournisseur qui par la suite le gestionnaire peut

modifier ;
2 : Bouton permettant de confirmer la modification ;
3 : Bouton permettant l’impression de la carte du fournisseur ;
4 : Liste des fournisseurs ;
5 : Bouton permettant d’appeler le formulaire d’enregistrement du nouveau fournisseur ;
6 : Bouton permettant de créer un fournisseur à base d’une personne existante dans le
système.
68
Utilisation
L’utilisation de cette interface est semblable à celles qui précédent pour faciliter l’exploitation
de l’application sauf que pour le bouton (6), la création d’un utilisateur n’implique pas une
nouvelle personne dans la base de données si ce n’est que celui qui existe déjà dans le système.
III. 3.4.9. Gestion des commandes
La page suivante permet la création de nouvelles commandes, leur modification ainsi que leur
suppression. Sur cette page le gestionnaire peut attribuer des produits aux fournisseurs.
Figure 40 : Gestion des commandes
Description
1 : Bouton (en menu) permettant d’appeler les formulaires de création d’une nouvelle
commande, un nouveau produit,…. ;
2 : Bouton permettant d’appeler le formulaire d’un nouveau fournisseur ;
3 : Comme à la figure 38, création d’un fournisseur à base d’un fournisseur existant dans la base
de données ;
4 : Liste des commandes déjà prêtes et celles dont la livraison n’a pas encore fini ;
5 : Liste des commandes pour la modification ;
6 : Liste des produits se trouvant sur la commande sélectionnée au menu 5 ;
69
7 : Liste des produits se trouvant sur les commandes mais qui n’ont pas encore trouvé de
fournisseurs ;
8 : Liste des fournisseurs qui se sont prononcés sur un produit sélectionné au menu 7 ;
9 : Bouton permettant d’attribuer le produit (7) au fournisseur (8) ;
10 : Liste des produits qui n’ont pas encore eu de fournisseur.
Utilisation
Pour l’élaboration d’une nouvelle commande, le gestionnaire choisit un produit et l’attribue à

un fournisseur qui peut le fournir. Pour l’attribution des produits, une fois sélectionnés, les
fournisseurs qui se prononcent sur un produit (8) permettent au gestionnaire de visualiser le
prix auquel il souhaite fournir un produit. Le gestionnaire sélectionne un fournisseur selon son
choix et peut lui attribuer le produit (7).
III. 3.4.10. Publication des produits
Une fois la livraison du produit est finie, le gestionnaire est tenu de le publier pour qu’elle soit
visible dans la partie client et la partie du caissier.
Figure 41 : Publication des produits

70
Description
1 : Menu contenant la liste des produits qui n’ont pas encore été publiés ;
2 : Le nom et la quantité du produit sélectionné pour être publié ;
3 : Champ de la description qui apparaitra sur la page de réservation ;
4 : Le prix sur lequel le produit a été acheté chez un fournisseur ;
5 : Champ de saisie du prix sur lequel l’alimentation vendra le produit ;
6 : Bouton de validation de la publication ;
Utilisation
Pour publier un produit, le gestionnaire le sélectionne (1) et ne complète que deux champs :
celui de la description (3) et celui du prix de vente (5) puis valide (6).
III. 3.4.11. La facture pro forma
Cette facture est élaborée par le gestionnaire, en choisissant les produits souhaités par le client,
le système calcule automatiquement le prix total sur un produit ainsi que la somme totale de la
commande. Ci-dessous un aperçu de la facture pro forma prête à être imprimé.
Figure 42 : Facture pro forma

71
Description
En haut à gauche, il y a le logo de l’alimentation, vers la droite le nom du client, en bas il y a la

liste des produits que souhaitent le client, juste après la liste il y a le prix total de la facture et
enfin la date à laquelle elle est délivrée.
III. 3.4.12. Suivi des activités de l’alimentation
Les données22 stockées sur des outils informatiques facilitent leur exploitation pour enfin
permettre aux décideurs de l’alimentation de prendre des mesures le plus tôt possible.
La figure ci-dessous nous illustre les données sur des diagrammes.
Figure 43 : Contrôle de l’alimentation du midi
Description
1 : Liste des clients endettés ;

2 : Menu contenant la liste des caissiers ;
3 : Liste des ventes opérées par le gestionnaire durant sept jours ;
4 : Liste des produits en stock avec leurs quantités respectives ;
5 : Diagramme de visualisation des pourcentages de ventes durant sept jours écoulés ;
6 : Situation du stock en pourcentage.
22
Représentation d’une information sous une forme conventionnelle destinée a facilité son traitement.
72
Utilisation
L’utilisation de cette interface ne demande pas d’effort car à la première vue, il y a présentation
des diagrammes qui décrivent les ventes (5) effectuées au cours de la semaine écoulée et la
situation du stock (6).
73
CONCLUSION GENERALE ET RECOMMANDATIONS
Avant de mettre un point final sur notre travail de recherche, il nous convient de s’autoévaluer
pour voir si les objectifs que nous nous sommes fixés ont été atteints. Rappelons que l’objectif
principal était de faciliter l’entrée et la sortie des produits dans l’alimentation DU Midi. Pour
atteindre cet objectif, nous avons jugé bon de subdiviser le travail en plusieurs chapitres :
1. Dans le premier chapitre, nous avons fait une brève présentation de l’alimentation du midi
sans oublier de bien analyser l’existant, de faire nos critiques sur ce dernier et en fin de
proposer des solutions ;
2. Le second chapitre est une approche théorique du langage de modélisation UML dans lequel
nous décrivons certains des diagrammes de ce langage et a base duquel nous modélisons le
nouveau système d’information de l’alimentation DU MIDI;
3. Le troisième chapitre qui est le dernier, nous avons fait la justification de quelques outils que
nous avons utilisés ainsi que la présentation des interfaces de l’application que nous avons
réalisées.
Grâce à ce procédé méthodique, nous avons pu mener à bien notre projet. Nous pouvons
maintenant affirmer que les problèmes de l’Alimentation DU MIDI identifiés dans la partie 0.5
et 1.4.ont été résolue, entre autre : Le temps suffisamment long pris par les services de
l’alimentation pour répondre aux demandes des clients, dans l’élaboration et diffusion des
commandes et factures prendra le temps suffisamment court grâce à l’accès rapide aux
données ; etc.
En conclusion, nous pouvons dire que nous avons atteint les objectifs que nous nous sommes
fixés. Néanmoins, les développeurs le savent, un logiciel sans bug23 n’existe pas. D’autres diront
« Rien n’est parfait dans ce monde ». Malgré les efforts fournis pour les éviter, nous ne
pouvons malheureusement pas garantir que ceux-ci n’apparaissent jamais. Avec la
collaboration des utilisateurs nous espérons pouvoir les identifier et les corriger dans les
versions futures.
Nous suggérons aux utilisateurs (clients, fournisseurs et au personnel) de l’alimentation DU

MIDI d’exploiter l’application et de signaler tout disfonctionnement ou fonctionnalité
manquante pour nous aider à améliorer l’application. Nous suggérons également aux étudiants,
de baser leurs développements sur des méthodes et techniques approuvés plutôt que de
commencer à partir de zéro.
23
Erreurs de programmation pouvant occasionner le disfonctionnement du logiciel.
74
Références
Ouvrages généraux
[1] Xavier Blanc et Isabelle Mounier. UML 2 pour les développeurs, 2008 ;
[2] Pascal Roques, UML2 Par la Pratique, 6e Édition, avril 2008 ;
[3] Mathieu Neubra, Réussir son site web avec XHTML et CSS, 2008 ;
[4] Joseph Gabay et David Gabay, UML2 Analyse et conception, 2008 ;
[5] Mathieu Neubra, Administrer vos bases de données avec MYSQL, 2012 ;
[6] Mathieu Nebra., Concevez votre site avec PHP et MySQL, 2012 ;
[7]Xavier Blanc et Isabelle Mounier, UML 2 pour les développeurs, 2009 ;
[8] Gilles Roy, Conception de bases de données avec UML, 2009 ;
[9] CagataycIIIici, Prime faces User Guide, 2013;
[10] Yannick Piault (sp0z), Débutez sur Adobe Photoshop, Janvier 2013;
Mémoires et Publications
[11] Conception et réalisation d’une application web de gestion des ventes des produits
pharmaceutiques « cas de new sidiphar », Olivier DUSABIMANA et Joëlle-Fidès GAKUBA, ULT,
Octobre 2013 ;
[12] Conception et réalisation d’une application web de suivi automatisé des patients « Cas de
la maison médicale de Bujumbura », Fleury BUTOYI et Christian NDIKURIYO, ULT, Décembre
2013;
[13] Conception et Réalisation d’une application web de gestion des horaires et résultats
académiques d’une université : « Cas de l’ULT », Théodore KAZE et Arnaud NININAHAZWE, ULT,
Janvier 2013;
Dictionnaires
[14] LE ROBERT; Édition; Le ROBERT Pour Tous ; Nouvelle édition (15 août 1998) ;
[15] Nouveau Littré ; Le Nouveau Petit Robert ; Paris, 1967 ;

75
Webographie
[16] www.wikipedia.org , mars 2015 ;
[17] http://www.notrefamille.com/dictionnaire/definition/libre-service , mars 2015;
[18] http://blog.soat.fr/2012/12/retour-dexperience-sur-lutilisation-de-primefaces/, Janvier

2015 ;
[19] http://www.primefaces.org/showcase/ui/home.jsf, janvier 2015 ;
[20] http://www.primefaces.org/showcase/ui/AJAXStatusStandard.jsf, janvier 2015 ;
[21] http://www.primefaces.org/showcase/ui/partialSubmit.jsf, janvier 2015 ;
[22] http://www.primefaces.org/showcase/ui/growl.jsf, janvier 2015 ;

Langue

Memoire Yvan - Fabrice Corrigee2

Transféré par

Informations du document

Description :

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Memoire Yvan - Fabrice Corrigee2

Titre original :

Transféré par

Description :

Droits d'auteur :

Formats disponibles

1

UNIVERSITE DU LAC TANGANYIKA

CONCEPTION ET IMPLEMENTATION D’UNE APPLICATION WEB DE GESTION

Mémoire présenté et défendu publiquement en

Sous la direction de:

Me SC. Rémeny NAHIMANA

Bujumbura, Décembre 2015

A mon regretté père;

A mes chers frères et sœurs;

A mes cousins et cousines;

A tous mes oncles et tantes;

A la famille BAHIZI Charles;

A tous mes amis et camarades de classe;

A mon regretté père;

A mes chers frères et sœurs;

A mes cousins et cousines;

A tous mes neveux et nièces;

A la famille KIRIMUTUMYE Jean Paul;

A la famille DUNIA Prudence;

A tous mes amis et camarades de classe;

A tous ceux qui me donnent des raisons d’être ce que je suis;

Nos sincères remerciements s’adressent plus particulièrement à Msc. Rémeny NAHIMANA,

LISTE DES SIGLES ET ABREVIATIONS

AJAX : Asynchronous JavaScript and XML

OOSE : Object Oriented Software Engineering

LISTE DES TABLEAUX

Tableau 1 : Scénario nominal du cas d’utilisation : S’authentifier ............................................... 25

LISTE DES FIGURES

Figure 1 : Evolution du langage UML .............................................................................................. 8

Figure 29 : Page d'erreur............................................................................................................... 56

TABLES DES MATIERES

LISTE DES SIGLES ET ABREVIATIONS ...............................................................................................iii

LISTE DES TABLEAUX ........................................................................................................................v

LISTE DES FIGURES .......................................................................................................................... vi

TABLES DES MATIERES .................................................................................................................. viii

CHAPITRE 0. INTRODUCTION GENERALE ........................................................................................ 1

0.2. Choix du sujet ................................................................................................................... 1

0.3. Intérêt du sujet ................................................................................................................. 1

0.4. Délimitation du sujet ........................................................................................................ 2

0.5. Problématiques ................................................................................................................ 2

0.6. Objectifs ........................................................................................................................... 3

0.6.1. Objectif global ......................................................................................................... 3

0.6.2. Objectifs spécifiques ................................................................................................ 3

0.7. Méthodologies et techniques utilisées ............................................................................ 3

0.8. Articulation du sujet ......................................................................................................... 4

CHAPITRE I. PRESENTATION GENERALE DE L’ALIMENTATION DU MIDI ........................................ 5

I.1. Concept alimentation ....................................................................................................... 5

I.2. Présentation de l’alimentation DU MIDI .......................................................................... 5

I.3. Analyse de l’existant......................................................................................................... 5

I.4. Critique de l’existant ........................................................................................................ 6

I.5. Solutions proposées ......................................................................................................... 7

CHAPITRE II. CONCEPTION DU NOUVEAU SYSTÈME DE GESTION DES ENTRÉES ET SORTIES

II.1. Présentation des diagrammes UML ................................................................................. 9

II.1.1. Diagramme de Classes ............................................................................................ 10

II.1.2. Diagramme de Déploiement ................................................................................... 14

II.1.3. Diagramme de Comportements ............................................................................. 15

II.1.4. Diagramme de Cas d’utilisations ............................................................................ 15

II.1.5. Diagramme d’Etat-transition .................................................................................. 17