Rapport final

Gestion du moulin d'olive
1
Introduction générale
La Tunisie est le pays le plus connu dans la culture d’oliviers et ce dans la région sud
méditerranéenne « plus de 30% de sa terre cultivable est consacrée à la culture d'olives (1.68
million d'hectare) » [1]. Elle est devenue le plus grand producteur d’huile d’olive dans
l’Afrique, et arrive en quatrième place mondiale après l'Espagne, l'Italie et la Grèce. Mais si
on exclut l’union européenne, la Tunisie sera la puissance mondiale principale dans le secteur
d'huile d'olive [1].
Dans ce cadre la Tunisie est entrain de fournir de grands efforts afin de restructurer et
moderniser ce secteur ainsi que de relever la qualité d'huile d'olive et d’augmenter la surface
cultivée.
La culture des olives a également participé au développement de l’équilibre régional
parce qu’elle reste la seule récolte possible dans les régions les moins favorisées; c'est pour
cette raison la société VISS a proposé l’idée de développer une application web de « Gestion
du Moulin d'olive ». En effet cette application a pour objectif le suivi des différentes tâches
du travail du Moulin d’olive.
En plus de l’introduction et la conclusion générale, ce mémoire comporte quatre chapitres :
Nous commençons par la « Présentation du projet » pour définit le contexte de travail et les
objectifs de notre projet de fin d’études.
Après, nous nous intéressons à l’ « Analyse et spécification des besoins », qui consiste à
présenter un recueil des besoins fonctionnels et techniques envers le système à développer.
Ensuite, nous passons à l' « Etude conceptuelle », qui agit au développement des
modèles de ce que le système doit faire.
Pour terminer, nous procédons à la « Réalisation et mise en œuvre » du travail en
présentant l’environnement de l’implémentation des différents modules constituants notre
système, les technologies utilisés et la mise en œuvre de l’enchainement des interfaces
graphiques.

2
Chapitre1 : Présentation du projet
Introduction :
Ce chapitre présente d’une manière générale le contexte de travail et les objectifs de
notre projet de fin d’études. Pour cela, nous commençons par présenter le projet et le cadre du
projet. Puis, nous présentons la méthodologie choisie et la démarché envisagée au long de
notre travail. Enfin nous donnons une description de la modélisation du métier.
1. Cadre du projet :
1.1. Faculté des sciences
La Faculté des Sciences de Sfax (FSS) a été créée en 1987. Elle a pour vocation de
dispenser des formations fondamentale et appliquée dans le domaine des sciences exactes et
naturelles.
La Faculté des Sciences a pour principal objectif l'employabilité, qui consiste pour elle
à tout mettre en œuvre pour permettre à l'étudiant d'être immédiatement opérationnel au terme
de ses études tout en développant en lui, la capacité d’évoluer dans nouveaux métiers qu’i
aura à exercer.
1.2. L’organisme d’accueil
Vision Internet Soft & Services (VISS) c’est une agence de communication
multimédia. Elle accompagne les entreprises dans la conception, la gestion et la promotion de
leurs projets multimédia et internet en leur offrant une variété de services (design, web et
logiciels).
L’adresse de la société est : Avenue Khaled Ibn El walid Imm. Erriadh N°133 (3000) Sfax .
2. Présentation du projet :
2.1. Sujet :
Face à l'individualisation de plus en plus poussée de la gestion de production dans le
domaine d'agriculture, les industriels agricole doivent trouver les solutions informatique
nécessaires pour optimiser la gestion, le suivie et la qualité de leur travail.
Le suivi de production est une problématique classique du monde industriel. Il est
progressivement adopté au secteur agricole, et particulièrement au moulin d'olive.

3
Dans ce cadre, la société VISS nous a proposé de développer une application de gestion de
moulin d'olive qui permet de gérer les clients, les achats, les ventes, le stock...
Notre projet de fin d’étude est intitulé « développement d’une application web gestion du
moulin d'olive » est réalisé dans le but d’obtention da la « licence fondamentale en
informatique » au sein de la FSS.
2.2. Problématique:
Dans le marché économique actuel, la gestion du moulin d'olive pose un grand
problème pour le gérant car l’opération était auparavant une opération manuelle qui s’effectue
sur papier, ce qui cause des problèmes de différents types.
2.3. Les objectifs du projet:
Le moulin d'olive ne possède aucun outil informatique simple et standardisé pour
gérer les différentes tâches du travail. Pour cela, notre objectif consiste à développer une
application, permettant la gestion des différentes fonctionnalités, relatives au stock d'huile,
clients, les opérations d'achats et de ventes et les maintenances des machines.
2.4. Solution proposée :
Cette application a pour but de concentrer les informations du stock, des employés,
des clients et des fournisseurs comme les opérations de vente et d'achat par le biais d’une
base de données, et permettant aussi d'organiser les déférentes informations dans un tableau
de bord.
Afin de pallier aux défaillances observées, nous proposons d’informatiser le processus de
gestion du moulin d'olive. Pour cela, nous optons pour le développement d’une application
web dynamique qui va être exploité par plusieurs intervenants et son principal objectif est la
gestion de vente et d'achat, suivi le stock du moulin et de gérer la caisse.
L’application doit pouvoir faciliter le processus de suivi de gestion du moulin d'olive et
permet au responsable de contrôler mieux ces activités.
3. Méthodologie du travail:
3.1. Choix de la méthodologie :
Le dossier de conception présenté ici est une traduction des besoins exprimés dans le
cahier des charges remis par la maîtrise d’ouvrage. Afin de formaliser ces spécifications, nous
avons utilisé le langage UML.

4
UML (Unified Modeling Langage), est un langage de modélisation des systèmes standard,
qui utilise des diagrammes pour représenter chaque aspect d'un système: statique,
dynamique,....en s'appuyant sur la notion d'orienté objet qui est un véritable atout pour ce
langage [2].
En effet, nous exprimons les besoins clients recueillis dans le cahier des charges
fonctionnels à l'aide d'un diagramme de cas d'utilisation, pour permettre de les découper en
fonctionnalités. Ensuite, chacune d'elles est détaillée avec un triplé diagramme d'activité,
feuille de scenario et le diagramme de séquence, afin de décrire précisément l'enchainement
des messages entre les utilisateurs et le système lors de la réalisation d'une fonctionnalité.
Le travail suivant consiste à répertorier les objets à manipuler dans le système pour en
déduire un diagramme de classes.
Figure 1 : méthodologie de conception adoptée
3.2. Démarche envisagée :
Le cycle de vie d’un logiciel (en anglais software lifecycle), désigne toutes les étapes
du développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel
découpage est de permettre de définir des jalons intermédiaires permettant la validation du
développement logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la
vérification du processus de développement, c’est-à-dire l’adéquation des méthodes mises en
œuvre.

5
Pour chaque produit (ou application) conçu et développé on choisi une démarche pour la
suivre tout au long du projet que l’on appelle cycle de vie du produit. Il existe plusieurs types
de cycles de vie (cycle de vie en V, en cascade,…..).
Pour notre projet nous avons choisi de suivre le cycle de vie en cascade qui est décrit par la
figure 2:
Figure 2 : Cycle de vie en cascade
Le diagramme de GANTT (figure3) réalisé par Microsoft XL présente le plan de
déroulement des différentes phases de notre projet, illustrant à la fois l'ordonnancement des
tâches dans le temps et leur durée.
Figure 3 : Diagramme de Gantt
Le projet a débuté le 15 mars 2016 et s'achève le 31 mai 2016 ce qui fait presque deux
mois et demi. Il comporte quatre phases primordiales pour tout projet de développement:
 Phase d'initialisation regroupant la découverte de l'organisme d'accueil, réunion de
démarrage avec le directeur de l'entreprise VISS, et le contact avec quelques Moulins
d’olives.

6
 La phase de spécification qui consiste à faire des analyses en se référant à ce qui
existe déjà et en considérant les besoins du client pour sortir avec une spécification
fonctionnelle et non fonctionnelle du projet.
 La phase conceptuelle qui occupe à peu près 20 jours, est basée sur le cahier de
charges et la méthodologie UML et ses diagrammes : cas d’utilisation, le digramme
de classe et diagramme d’activité, afin sortir avec une conception déterminant les
classes à utiliser, les tables et les relations à créer et les interfaces à implémenter en
nombre et en forme.
 La phase de la réalisation qui occupe 36 jours de préparation d’interfaces et codage
et de tests afin de terminer l'application et faire une démonstration devant l'encadrant.
4. Modélisation du métier:
4.1. Repérage du domaine :
Il s'agit de trouver les acteurs métier et de représenter les limites du domaine. Le
diagramme utilisé est un diagramme de collaboration qui représente le domaine comme boite
noire et les messages échangés entre ce domaine et les acteurs métier.
Figure 4 : Diagramme de collaboration métier

7
4.2. Diagramme de cas d'utilisation métier :
Il s'agit de définir les travailleurs du métier, de décrire leur rôle et de représenter les
différents processus du métier et les liens entre eux.
Ainsi, il faut construire un diagramme de cas d'utilisation dans lequel nous représentons
chaque processus métier par un cas d'utilisation. Ensuite, nous décrivons chaque processus
métier en précisant les flots d’événements de chacun, les activités qui le composent et les
règles de gestion à respecter pour ces activités. Cette description est textuelle.
Figure 5 : Diagramme de cas d’utilisation métier
Le responsable à plusieurs tâches de service :
a. Gérer les employés :
 Analyse, vérifie et actualise la documentation sur l’employé du Moulin d’olive et les
procédures à respecter, notamment dans le recrutement, l’offre de formation,
l’évaluation des performances, etc.
 Effectue des recommandations en matière de rémunérations.

8
 Réalise des rapports sur la gestion d’employé pour l’administrateur du Moulin d’olive.
 Enregistre les données individuelles des salariés d’employés du Moulin d’olive, dont
leur adresse, les rémunérations, les relevés de présences, les rapports de hiérarchie sur
les performances, etc.
 Recueille les informations légales, des attestations de précédents employeurs, ou toute
autre pièce permettant d’apprécier la recevabilité d’une candidature pour le Moulin
d’olive.
 Réalise diverses tâches administratives, telles que le renseignement téléphonique,
l’envoi d’offres d’emploi, etc.
b. Gérer les ventes :
 Recensement des besoins en relation avec les acheteurs d’huile.
 Mise en application des procédures des ventes d’huile.
 Elaboration des bons de commandes.
 Suivis et contrôle de l’exécution des marchés.
 Etablir un cahier des charges / une commande recensant l’ensemble des besoins en
produits (huiles) et services (clients).
 Facturation et enregistrement des ventes d’huile aux clients.
 Mise à jour et suivi des fiches clients du Moulin d’olive.
 Suivi et relance de la clientèle.
 Développer une relation de confiance avec les clients du Moulin d’olive.
c. Gérer les achats :
 Négocier avec les fournisseurs d’olive et définir les modalités du contrat (tarifs, délais
de livraison d’olive…).
 Prendre en charge les échanges et le suivi quotidien des fournisseurs d’olive et des
sous-traitants.
 Mettre en place avec les fournisseurs d’olive sélectionnés un plan
d’approvisionnement.
 Gérer et optimiser les flux et les stocks de matières premières (olive).

9
 Superviser les opérations d’approvisionnement.
d. Gérer les réservations :
 Mise en application des procédures de réservations des machines de presse d’huile
d’olive.
 Mettre en œuvre les besoins des clients qui sont en train de faire une réservation.
 Enregistrer et suivre les documents des rendez-vous (agenda).
e. Gérer les maintenances :
 Réagir en cas de panne grave avec la machine de presse d’huile d’olive et résoudre les
problèmes rapidement.
 Gérer le budget maintenance.
Apres avoir présenté le diagramme de cas d'utilisation métier, nous passons à une
conclusion.
Conclusion :
Ce chapitre a été le point de départ pour la présentation de notre projet, dans la mesure
où il décrit son contexte général en présentant l’organisme d’accueil VISS, le cadre du
projet, la modélisation métier, les objectifs généraux à atteindre et les étapes de sa
mise en œuvre et méthodologie de conception adoptée. Dans le chapitre suivant, nous
présentons l’analyse et la spécification des besoins.

10
Chapitre 2: Analyse et spécification
des besoins
Introduction :
Parmi les étapes de développement de cycle de vie de notre projet, nous avons l’étape
de l’analyse. Cette étape nous permet de s’étaler dans la compréhension du problème et des
besoins. Elle a donc pour objectif de dégager les besoins fonctionnels et non fonctionnels de
l’application à réaliser et cela à partir de la réalisation d’un cahier des charges qui nous
permet de modéliser ces besoins par des cas d’utilisation en utilisant UML.
1. Etude de l'existant :
1.1. Présentation de l'existant :
L’étude de l’existant est une phase importante pour bien comprendre le système actuel
et définir ses limites.
Le responsable de moulin d'olive gère les employés, les fournisseurs, les clients, les
opérations des ventes et des achats et aussi l'agenda du travail d’une façon manuelle. Etant
donné que le responsable stocke toutes les informations de gestion comme les bons d'achat,
les fiches d'employés, les fiches de stock dans une boite d’archive, coche la présence de
chaque employé, remplit des factures pour les clients manuellement, ainsi il suit l'état du stock
actuel sur des feuilles comportant des tableaux indiquant la quantité d'huiles et d'olives
disponibles dans un moment donné. Il est obligé alors de rechercher puis modifier la feuille
juste pour chaque activité établie dans le moulin d'olive. En bref, tout ce travail est manuel.
Le Moulin d’olive a aussi un grand problème qui se manifeste sur la maintenance de la
machine de presse d’huile d’olive. Il y a d’autres contraintes qui influent sur la mise en
marche des rendez-vous et les réservations de la machine en même temps.
1.2. Critique d'existant:
La critique des processus de travail et des processus de gestion des données permet de
montrer les points forts et les points faibles :les points forts sont à consolider, les points
faibles sont à éviter dans le nouveau système.

11
Nous remarquons que plusieurs tâches se répètent d’une façon manuelle. Les principaux
fonctionnements de la situation actuelle sont :
 Les exploitations manuelles qui gèrent les éléments de paie entrainent une perte de
temps considérable et augmentent les risques d’erreurs.
 L’archivage des documents sous forme de papiers augmente le risque de perte avec
une difficulté lors de leur recherche en cas de besoins.
 Un accès lent aux informations.
 L’accès aux données n’est pas assez sécurisé: n’importe quelle personne peut consulter
les documents dans l'archive.
2. Objectifs à atteindre :
Les objectifs à atteindre sont celle de l’organisme en question suite à la réalisation de ce
projet.
L'application de gestion du Moulin d'olive doit donc développer un outil pour gérer la
gestion du Moulin d’olive. Cette application doit permettre de :
 Faciliter la recherche d’une information sur les employés, les fournisseurs d’olive, les
clients, les fournisseurs de maintenance, etc.
 Faciliter l’accès aux données des fournisseurs, des clients, du stock et des employés
sous forme de clique bouton.
 Gérer les rendez-vous sous forme d’agenda pour les clients (sous forme d’annuaire)
demandeurs de service de pression.
 Automatiser quelques tâches pour gagner du temps.
 Les interfaces doivent êtres conviviales et faciles à utiliser et à manipuler.
 La mise à jour des données doit être facile.
 Définir les méthodes de calcul de prix.
 Impression de facture.
3. Définition des exigences :
La modélisation du système commence par l’identification des acteurs et des cas
d’utilisation et se poursuit par leur description afin d’aboutir à une meilleure compréhension

12
de la modélisation. L’application envisagée doit satisfaire les besoins fonctionnels qui seront
exécutés par le système et les besoins non fonctionnels qui perfectionnent la qualité logicielle
du système.
3.1. les besoins fonctionnels :
Ce présent projet consiste à étudier et à réaliser une application Web permettant de
présenter des méthodes qui faciliteront la gestion du Moulin d'olive.
Les besoins fonctionnels dégagés dans notre cas sont :
 Gestion des employés : un salarié peut être créé, modifié, supprimé et nous avons la
possibilité de consulter les différentes informations relatives à cette personne.
 Gestion des clients : un client peut être créé, modifiée, supprimée et nous avons la
possibilité de consulter les différentes informations (réservations et factures) relatives
à cette personne.
 gestion des fournisseurs: un fournisseur (soit fournisseur d'olive ou de maintenance)
peut être créé, modifié, supprimé et nous avons la possibilité de consulter les
différentes informations (bon d'achat ou maintenance) relatives à cette personne.
 Gestion des maintenances : une maintenance peut être créé (avec le nom du
fournisseur de maintenance), modifiée, supprimée et nous avons la possibilité
consulter les différentes informations relatives à cette maintenance.
 Gestion de stock : une citerne peut être créé, modifiée, supprimée et nous avons la
possibilité de consulter les différentes informations relatives à cette citerne. Une cuve
peut être créé, modifié, supprimé et nous avons la possibilité de consulter les
différentes informations relatives à cette cuve.
Nous avons la possibilité aussi d'ajouter d'huile, de retirer d'olive et de vider la cuve.
 Gestion des réservations : une réservation peut être créé, modifiée, supprimée pour
chaque client.
 Gestion des ventes: une commande peut être créé, modifiée, supprimée, avec
l'impression de la facture.
 Gestion des achats : un achat peut être créé (avec le nom du fournisseur d'olive),
modifié et supprimé.
 Gestion de la caisse : initialisation de la caisse avec le pouvoir de modifier.

13
3.2. Les besoins non fonctionnels :
Les besoins non fonctionnels présentent les exigences internes pour le système qui
sont primordiales pour atteindre notre objectif. Parmi ces besoins nous citons :
 L’ergonomie : notre application web doit présenter des interfaces utilisateurs
conviviales bien structurées du point de vue contenu informationnel. Cet effet est
assuré par la combinaison du texte et du graphique avec un bon choix des couleurs et
du style d’écriture.
 Vérification des paramètres manipulés : notre application web doit permettre la
vérification des différents paramètres manipulés.
 Facilité d’utilisation : notre application web doit être simple à utiliser.
 Performance : notre application web doit avoir des temps de réponse assez faibles
pour permettre la réalisation des différentes étapes du travail de manière conviviale.
 Maintenance : Le code doit être facile à maintenir pour des raisons de réutilisation et
de modification.
 Fiabilité : notre application web doit toujours être en mesure de fonctionner
correctement : il ne doit pas y avoir de problèmes de fonctionnement ou des cas
limites qui donnent des résultats non souhaités ou erronés.
4. Formalisationdu problème :
Concernant cette partie, il s’agit de formuler le problème afin de limiter le champ de l’étude.
Acteurs de système informatisé :
Dans la modélisation par les diagrammes des cas d’utilisation, deux concepts
fondamentaux interviennent: les acteurs et les cas d’utilisations.
Les acteurs : un acteur représente un ensemble cohérent de rôles joués par des entités
extrêmes (les personnes en interactions avec les cas d’utilisations) qui interagissent
directement avec l’application. De ce fait, l'acteur de notre application est :
Le responsable : c’est le responsable qui une fois authentifié, permet de gérer la caisse, gérer
les employés, gérer les fournisseurs, gérer les clients, gérer le stock, gérer les maintenances,
gérer les ventes et gérer les achats.

14
5. Elaboration du modèle des cas d'utilisation :
L’élaboration du modèle des cas d’utilisation consiste à présenter le diagramme des cas
d’utilisation et la description textuelle des cas d’utilisations.
5.1. Diagramme des cas d'utilisation :
Il s'agit de représenter sous forme d'un diagramme de cas d'utilisation les fonctionnalités
du système comme vues par les futurs utilisateurs et les liens entre elles.
Figure 6 : Diagramme de cas d’utilisation
5.2. Description textuelle des cas d'utilisation :
Un cas d’utilisation représente un ensemble de séquences d’interaction entre le système
et ses acteurs. Afin de décrire sa dynamique, nous recensons toutes ces interactions de façon
textuelle détaillée.

15
Tous les scénarios doivent être pris en compte (nominaux, alternatifs et exception).
Cas d'utilisation "S'authentifier" :
Identification :
Titre : S’authentifier.
Acteur : Responsable.
Objectif : Accéder aux différentes fonctionnalités de l'application d'une manière sécurisée.
Flot de donnés : Login et mot de passe
Description des scénarios :
Pré condition :
Accès à l'application.
Post condition :
Le responsable est connecté au système.
Scénario normal :
1. Une interface graphique est présentée au responsable comme un moyen d’interaction
IHM afin qu’il puisse saisir son login et mot de passe.
2. Une vérification de ses informations est alors effectuée. Après que la réussite de la
connexion, le responsable est redirigé vers sa page d’accueil. Il pourra ainsi avoir
accès aux fonctionnalités de l’application Web.
3. Le système vérifie le login, le mot de passe et le rôle de l'utilisateur, s’il est correct
alors le système affichera le menu d’accueil. Si non il appellera Exception1.
Exceptions :
Exception1 : Login et mot de passe incorrects, connexion refusée.
Gérer les clients :
Le même principe pour les employés et les fournisseurs.
Identification :
Titre : Gérer les clients.

16
Acteur : Responsable.
Objectif : Permettre la création d'un nouveau Client en introduisant toutes les informations
nécessaires.
Pré condition :
Responsable s'authentifie.
Post condition :
Client créé.
Scénario nominal :
 Ajouter un client :
1. Le responsable demande d’ajouter un nouveau client.
2. Le système affiche le formulaire d’ajout d’un nouveau client.
3. Le responsable saisit les informations nécessaires pour l’ajout du client et confirme
l'ajout.
4. Le système récupère les informations saisies pour ajouter un client dans la BD locale
après vérification des champs saisies.
5. S’il y’a une information manquante ou n'est pas renseigné par le système, il faut
exécuter Exception2.
6. Enfin un message s'affiche indiquant si l'opération est terminée avec succès ou échec.
Scénarios alternatifs :
 Modifier client existant :
1. Le responsable consulte la liste des clients.
2. Le système affiche la liste des clients.
3. Le responsable sélectionne le client concerné dont il veut modifier les caractéristiques.
4. Le système affiche les anciennes informations du client dans un formulaire d'édition.
5. Le responsable effectue les modifications puis confirme.
6. Le système récupère les nouvelles informations pour le modifier dans la BD.

17
7. Le système vérifie les informations saisis. S’il y a erreur, il faut exécuter l'Exception2.
8. Enfin un message s'affiche indiquant si l'opération est terminée avec succès ou échec.
 Rechercher les clients existants :
1. Le système propose au responsable de rechercher le client selon sa CIN ou son nom.
2. Le système affiche les clients répondu au critère de recherche s’il existe ou affiche
l'Exception3.
 Supprimer un client existant :
1. Le système affiche dans l’écran la liste des clients.
2. Il sélectionne le client concerné dans la liste des clients.
3. Le responsable choisit de supprimer le client.
4. Le système affiche un message de demande de confirmation de suppression.
5. Si le responsable confirme la suppression alors le client est supprimé avec toutes ses
activités existantes dans la base.
Exceptions :
Exception2 : Le système affiche « ERREUR !! »
Exception3 : Le système affiche « Client introuvable »
Gérer les ventes :
Identification :
Titre : Gérer les ventes.
Acteurs : Responsable.
Objectif : Passer et suivre les ventes des clients.
Pré condition :
Huile existe dans la citerne.
Post conditions :

18
Facture créé.
Scénario nominal :
 Enregistrer la vente :
Cette partie constitue les fonctionnalités les plus basiques de l’application et celles qui
sont accessibles au responsable.
1. Le responsable demande de créer une nouvelle vente d’huile.
2. Dans le formulaire de saisi, le responsable saisit le CIN de client qui a passé une
commande.
3. Le système affiche le nom du client qui concerne au CIN saisie, ou introuvable si le
client n’existe pas.
4. Si le client n’est pas trouvé, il faut appeler le cas d'utilisation "Gérer les clients". Avec
un lien déjà existant dans le formulaire.
5. Le système affiche en formulaire une liste des citernes.
6. Pour toute huile commandée :
o Le responsable sélectionne l'unité de calcule d'huile avec un bouton radio.
o Le responsable saisit la quantité demandée.
7. Le système vérifie l’unité de calcul d’huile demandée (Kilogramme ou Litre), si le
responsable a oublié de le préciser, alors il faut exécuter l'Exception4.
8. Le système vérifie que la quantité d’huile est disponible dans le stock, si elle n’est pas
disponible, alors il faut exécuter l'Exception5.
9. Après la saisie de la commande, le système affiche le montant TTC de vente et la
quantité totale d’huile achetée.
10. Le responsable sélectionne chaque type d’huile commandé dans la liste des citernes.
11. Après la sélection, le système affiche toute la commande demandée dans le formulaire.
12. Le responsable demande la validation de la commande.
13. Le système vérifie que toutes les données obligatoires sont saisies. Si non, il faut
exécuter l'Exception6.
14. Avec l’enregistrement de la vente dans la BD, le responsable imprime la facture du
client.
15. Le scénario se termine lorsque le responsable imprime la facture.

19
 Supprimer une facture :
1. Le système propose au responsable de chercher le client selon sa CIN.
2. Le système affiche toutes les factures du client répondant au critère de recherche.
3. Le responsable sélectionne la commande concernée dont il veut supprimer.
4. Le responsable effectue la suppression puis confirme.
5. Enfin un message confirmant le succès.
 Consulter les ventes :
Objectif : Permettre à un utilisateur de consulter les factures préalablement archivées pour
chaque client.
Scenario nominal :
1. Le responsable demande de consulter la facture.
2. Le responsable saisit le numéro de carte d’identité du client.
3. Le système affiche toutes les factures du client précisé.
Exceptions :
Exception4 : Le système affiche « s’il vous plaît choisir l’unité d’huile ».
Exception5 : Le système affiche le message suivant « La quantité demandée est supérieure à
la quantité trouvable dans la citerne ».
Exception6 : Le système affiche « Vérifier les informations de cette commande !».
Gérer les achats :
Identification :
Titre : Gérer les achats.
Objectif : Achat d'olive pour la pression.
Pré condition :

20
Responsable s'authentifié.
Post conditions :
Olive acheté, quantité d'olive ajoutée dans le stock.
Quand le responsable remarque une diminution au niveau de la quantité d’huile stockée dans
les citernes et les cuves d'olive, il doit contacter le fournisseur pour acheter une quantité
d'olive.
Scénario nominal :
Cette partie est très importante pour que le moulin d’olive reste en œuvre.
 Enregistrer l'achat d'olive :
1. Dans le formulaire de saisi, le responsable saisit le CIN du fournisseur.
2. Le système affiche le nom du fournisseur qui concerne au CIN saisie ou introuvable si
le fournisseur n’existe pas.
3. Si aucun fournisseur n’est trouvé, il faut appeler le cas d'utilisation "Gérer les
fournisseurs". Avec un lien déjà existant dans le formulaire.
4. Le responsable entre toutes les informations qui correspondent à la quantité d'olive
achetée et confirme l'achat.
5. Le système vérifie que toutes les données obligatoires sont saisies, s’il y’a une erreur,
il faut exécuter l'Exception2.
6. Tant que la commande n'est pas enregistrée, elle peut être à tout moment annulée.
 Modifier l'achat :
1. Le système propose au responsable de chercher le fournisseur selon sa CIN.
2. Le système affiche tous les bons d'achats du fournisseur répondant au critère de recherche
ou affiche l'Exception7.
3. Le responsable sélectionne l'achat concerné dont il veut modifier.
4. Le système affiche les anciennes informations d'achat dans un formulaire d'édition.

21
5. Le responsable effectue les modifications puis confirme. S'il y a une erreur le système
affiche l'Exception2.
6. Le système récupère les nouvelles informations et les modifié dans la BD.
 Supprimer l'achat :
1. Le système propose au responsable de chercher le fournisseur selon sa CIN.
2. Le système affiche tous les bons d'achats du fournisseur répondant au critère de
recherche ou affiche l'Exception7.
3. Le responsable sélectionne le bon achat concerné dont il veut supprimer.
4. Le responsable effectue la suppression puis confirme.
Exceptions :
Exception7 : Le système affiche « Fournisseur introuvable »
Gérer les réservations:
Identification :
Titre : Gérer la réservation.
Objectif : Permettre la réservation de la machine au client pour la pression de son huile.
Pré condition :
Post conditions :
Réservation enregistrée.
Le client contacte le responsable du moulin d'olive et affirme qu'il veut réserver la machine
pour la pression de son olive.

22
Scénario nominal :
1. Le responsable consulte l'agenda de la réservation (où il y a tous les réservations).
2. Le responsable donne une date au client pour la pression de son olive.
3. Si le client refuse la date; le scenario s'arrête si non:
o Le responsable saisir dans le formulaire le CIN du client.
o Le système affiche le nom du client concerne au CIN saisie ou introuvable si le
client n’existe pas.
4. Si aucun client n’est trouvé, il faut appeler le cas d'utilisation "Gérer les clients". Avec
un lien déjà existant dans le formulaire.
5. Le système affiche le nom du client.
6. Le responsable saisit la date et le prix de la réservation.
7. Le système vérifie que toutes les données obligatoires sont saisies. S’il y’a une
information manquante, il faut exécuter l'Exception2.
 Modifier la réservation :
1. Le responsable consulte la liste des réservations.
2. Le système affiche la liste des réservations.
3. Le responsable sélectionne la réservation concernée dont il veut modifier.
4. Le système affiche les anciennes informations de réservation dans un formulaire
d'édition.
6. Le système récupère les nouvelles informations pour les modifier dans la BD.
7. Le système vérifie les informations saisies. S’il y a erreur, il faut exécuter
l'Exception2, si non, le système effectue la modification.
 Supprimer une réservation :
1. Le responsable sélectionne la réservation concernée dont il veut supprimer.
2. Le responsable confirme la suppression.

23
 Consulter l'agenda de réservation :
1. Le responsable demande de consulter l'agenda de réservation.
2. Le système affiche la liste des réservations du moulin d'olive avec la possibilité de
rechercher les réservations par la date.
Exceptions :
Exception2 : Le système affiche le message : « ERREUR!! »
Gérer le stock :
Identification :
Titre : Gérer le stock.
Objectif : Créer une citerne, créer une cuve, mise à jours de l'état du stock.
Pré condition :
Post conditions :
Citerne créé.
Scénario nominal :
Le même pour la cuve.
 Ajouter une citerne :
1. Le responsable demande l’ajout d’une citerne.
2. Le système affiche le formulaire d’ajout d’une nouvelle citerne.
3. Le responsable saisit les informations nécessaires pour l’ajout de la citerne et choisit
de confirmer l'ajout.
4. Le système récupère les informations saisies pour ajouter la citerne dans la BD après
vérification des champs saisies.

24
5. Le système vérifie que toutes les données obligatoires sont saisies. S’il y’a une erreur,
il faut exécuter l'Exception2.
Scénario alternatifs :
 Modifier une citerne :
1. Le responsable consulte la liste des citernes.
2. Le système affiche la liste des citernes.
3. Faire sélectionner la citerne concernée puis cliqué modifié.
4. Le système affiche les anciennes informations de la citerne dans un formulaire
d'édition.
6. Le système récupère les nouvelles informations pour les modifier dans la BD.
7. Le système vérifie les informations saisies. S’il y a erreur, il faut exécuter
l'Exception2, si non, le système effectue la modification.
 Supprimer citerne :
1. Le responsable consulte la liste des citernes.
2. Le système affiche la liste des citernes.
3. Le responsable sélectionne la citerne concernée dans le formulaire de gestion de stock.
4. Le responsable choisit de supprimer la citerne.
5. Le système affiche un message de demande de confirmation de suppression. Si le
responsable confirme la suppression alors la citerne sera supprimée.
 Consulter le stock :
1. Le responsable demande de consulter la liste des citernes.
2. Le système affiche la liste des citernes d’huile.
3. Si le responsable veut consulter l'état d’une citerne précis, il saisit seulement la
référence de la citerne préférée.
4. Le système affiche toutes les informations de la citerne ou affiche l'Exception8.

25
 Ajouter d’huile :
1. Le responsable choisit la citerne d’huile.
2. Le responsable saisit la quantité ajoutée dans la citerne si la quantité ajoutée est
supérieure à la quantité trouvable dans la citerne, le système affichera Exception9.
3. Le responsable confirme l’ajout.
 Retirer d’olive (pour la cuve) :
1. Le responsable choisit la cuve d’olive.
2. Le responsable saisit la quantité retirée de la cuve.
3. Le responsable confirme l’action.
 Vider une cuve (pour la cuve) :
1. Le responsable choisit la cuve d’olive.
2. Le responsable confirme l’action.
Exceptions :
Exception8 : Le système affiche « Citerne introuvable »
Exception9 : Le système affiche « La quantité ajoutée est supérieure à la quantité trouvable
dans la citerne ».
Gérer la caisse :
Identification :
Titre : Gérer la caisse.
Objectif : Initialiser la caisse.
Pré condition :
Post conditions :
Caisse initialisée.

26
Scénario nominal :
1. Le responsable saisit le budget du moulin puis confirme.
2. Le système récupère l'information saisie dans la BD après la vérification du champ
saisi.
Gérer les Maintenances :
Identification :
Titre : Gérer les maintenances.
Objectif : permettre le suivi du frais de maintenance.
Pré condition :
Post conditions :
Maintenance archivée.
Scénario nominal :
1. Dans le formulaire de saisi, le responsable saisit la CIN du fournisseur de
maintenance.
2. Si cette CIN n’existe pas, il faut appeler le cas d'utilisation "Gérer les fournisseurs".
3. Sinon le système affiche le nom du fournisseur.
4. Le responsable fait entrer toutes les informations nécessaires et valide l'opération.
 Modifier maintenance :
1. Le responsable sélectionne la fiche de maintenance concernée dont il veut modifier.
2. Le système affiche les anciennes informations de la fiche dans un formulaire
d'édition.

27
4. Le système récupère les nouvelles informations et les modifie dans la BD.
5. Le système vérifie les informations saisies. S’il y a erreur il faut exécuter
l'Exception2, sinon le système effectue la modification.
 Supprimer maintenance :
1. Le système affiche dans l’écran la liste de maintenance.
2. Il sélectionne la maintenance concernée dans le formulaire de gestion des
maintenances.
3. Le responsable choisit de supprimer la maintenance.
4. Le système affiche un message de confirmation de suppression.
Exceptions :
Exception2 : Le système affiche «ERREUR!!»
Conclusion :
Le but de ce chapitre est le recueil de la spécification des besoins fonctionnels du système.
À la capture des besoins, nous avons décrit, d’une manière globale, le comportement
du système, exprimé sous la forme de cas d’utilisation et d’acteurs. Le modèle global des cas
d’utilisation va servir d’entrée pour l’activité suivante à savoir la conception ; ceci sera
l’objectif du chapitre suivant.

28
Chapitre 3 : Etude conceptuelle
Introduction :
Après avoir fait une minutieuse capture des besoins, une phase d'analyse et
conception est adaptée pour mieux éclaircir cette dernière. Il s’agit d’une des étapes les plus
fondamentales dans le cycle de développement de toute application. Elle permet de construire
un modèle considéré comme étant une simplification de la réalité afin de comprendre au
mieux le projet à développer.
L’objectif de ce chapitre est de développer un modèle de ce que le système doit faire:
ce modèle est exprimé en termes d’objets et de relations, de flux dynamiques et de
transformation fonctionnelle. Ce chapitre s’articule autour de deux volets: développement du
modèle statique et développement du modèle dynamique.
1. Etude statique :
Le terme vue statique s’applique aux aspects d'un modèle donné ayant un rapport avec
les types de choses qui existent dans le modèle, leur structure interne et les relations qui
existent parmi ces choses. La vue statique est capturée principalement dans les diagrammes de
classes.
1.1. Diagramme de classe :
En général, le diagramme de classes représente la structure statique d’un modèle, à
savoir les éléments (classes et types), la structure interne des éléments et leurs relations les
uns par rapport aux autres. Ce diagramme (figure 8) représente les classes, les paquetages ou
les interfaces connectés par des relations statiques. Il constitue donc un élément très
important de la modélisation car il permet essentiellement de :
 Définir quelles sera les composantes du système final.
 Représenter l'organisation des données dans les systèmes d'information
 Structurer le travail de développement de manière très efficace.

29
Dans cette partie nous procédons au recensement des classes indispensables pour remplir les
fonctionnalités de notre application. Le tableau de la figure 7 présente ces classes et leurs
descriptions:
Classe Attribut Description
Client cinClient
nomClient
prenomClient
telClient
adrClient
Numéro de carte d’identité
Nom de client
Prénom de client
Numéro de téléphone
Adresse de client
Reservation IdRsv
prixRsv
dateRsv
descriptionRsv
Code de réservation
Prix de réservation
Date de réservation
Description de réservation
Facture idVente
typeReglement
dateVente
montant
quantite
designation
Code de vente
Type de règlement
Date de vente
Montant total de vente
Quantité vendu d’huile
Désignation de tous les achats
Caisse idCaisse
solde
Code de la caisse
Budget du moulin
Stock IdStock
codeStock
capacité
Numéro du stock
Référence du stock
Capacité du stock
Citerne prixUT
qualitehuile
quantitehuile
Prix d’un litre d’huile
Qualité d’huile
Quantité d'huile actuelle dans la
citerne
CuveOlive quantiteactOL Quantité actuelle d'olive
BonAchat IdBA
dateBa
montantAchat
designation
quantiteOL
region Olive
Code d'achat
Date d'achat
Montant d'achat
Désignation de tous les achats
Quantité achetée
Région d'olive acheté

30
Fournisseur cinFourn
nomFourn
prenomFourn
telFourn
adrFourn
Nom du fournisseur
Prénom du fournisseur.
Téléphone du fournisseur
Adresse du fournisseur
FournisseurOlive Classe hérite de la classe
fournisseur
FournisseurMaintenance Classe hérite de la classe
fournisseur
Maintenance Idmain
Descpanne
datemain
prixmain
Code de maintenance
Description de panne
Date de maintenance
Prix de maintenance
Employe cinEmp
nomEmp
prenomEmp
telEmp
adrEmp
grade
periode
Nom d'employer
Prénom d'employer
Numéro de téléphone
Adresse d'employer
Grade d'employer
Période de travail
Role Idrole
Role
Identificateur
Le rôle du responsable dans
l'application
Responsable user_name
passowrd
Login
Mot de passe
Figure 7 : Les Classes indispensables pour l'application
Le diagramme de classes est composé essentiellement de classes et de relations entre les
classes qui constituent la future application de notre projet et servent à en décrire les
principales méthodes ainsi que leurs attributs et leurs comportements comme le montre la
figure 8:

31
Figure 8 : Digramme de classe

32
1.2. Transformation en modèle relationnel :
Les règles de passage :
Transformation des classes : chaque classe du diagramme UML devient une relation, il
faut choisir un attribut de la classe pouvant jouer le rôle de clé.
 Association 1..* : il faut ajouter un attribut de type clé étrangère dans la relation fils de
l’association. L’attribut porte le nom de la clé primaire de la relation père de
l’association.
 Association *..* : la classe-association devient une relation. La clé primaire de cette
relation est la concaténation des identifiants des classes connectées à l’association.
 Association 1..1 : il faut ajouter un attribut de type clé étrangère dans la relation
dérivée de la classe ayant la multiplicité minimale égale à un. L’attribut porte le nom
de la clé primaire de la relation dérivée de la classe connectée à l’association. Si les
deux multiplicités minimales sont à un, il est préférable de fusionner les deux classes
en un seule.
Role (idRole, roleName, #cinEmp).
Employe (cinEmp, nomEmp, prenomEmp, telEmp, adrEmp, grade, periode).
Responsable (cinEmp, nomEmp, prenomEmp, telEmp, adrEmp, grade, periode, username,
password).
Fournisseur (cinFourn, nomFourn, prenomFourn, telFourn, adrFourn, TYPE_FRN).
Maintenance (IdMain, descpanne, datemain, prixmain, #idcaisse, #cinFourn).
Caisse (idCaisse, solde).
BonAchat (idBA,dateBA, designation, maturite, MontantAchat, quantiteOL, regionOlive,
#idcaisse, #cinFourn, #codeStock).
Stock (codeStock, capacite, prixUT, qualiteHuile, quantiteHuile, quantiteactOL,
TYPE_STK).
Facture (idVente, typeReglement, desigantion, dateVente, Montantf, quantite, #cinClient,
#idCaisse).
fact_c (#codeStock, #idVente).

33
Client (cinClient, nomClient, prenomClient, telClient, adrClient).
Réservation (idRsv, prixRsv, descriptionRsv, dateRsv,#cinClient).
2. Etude dynamique:
Les aspects d'un modèle donné ayant un rapport avec la spécification et
l’implémentation du comportement au cours du temps.
2.1. Diagramme de séquence :
Le diagramme de séquence permet de représenter les vues dynamiques du système. Il
s'agit de la représentation des interactions entre les objets selon un point de vue temporel.
L’accent sur la chronologie des envois de messages. Le diagramme est structuré de la manière
suivante :
Les objets étudiés sont placés sur la première ligne et pour chaque objet, nous
associons une barre verticale en pointillée appelée " ligne de vie " de l'objet. Le diagramme
possède un axe du temps dirigé du haut vers le bas. Les messages sont représentés par des
flèches horizontales orientées de l'émetteur vers le destinataire.
La représentation des périodes d'activité des objets est possible à l'aide d'une bande
rectangulaire le long des lignes de vie des objets et dont les extrémités représentent le début et
la fin de l'activité. Dans ce travail le diagramme de séquence permet de représenter la
succession chronologique des opérations réalisées par un acteur. Dans ce qui suit une étude de
quelques cas de diagrammes de séquence tel que :
 Authentification.
 Gérer les ventes.
 Gérer les achats.
 Gérer les maintenances.
 Gérer les clients.
 Gérer le stock d’huile.

34
2.1.1. Représentation du diagramme de séquence « S'authentifier »
Figure 9 : Diagramme de séquence « S'authentifier »
2.1.2. Représentation du diagramme de séquence « Gérer les clients »

35
Figure 10 : Diagramme de séquence « Gérer les clients »

36
2.1.3. Représentation du diagramme de séquence « Gérer les ventes »
Figure 11 : Diagramme de séquence « Gérer les ventes »

37
2.1.4. Représentation du diagramme de séquence « Gérer les achats »
Figure 12 : Diagramme de séquence « Gérer les achats »

38
2.1.5. Représentation du diagramme de séquence « Gérer stock d’huile »
Figure 13 : Diagramme de séquence « Gérer stock d’huile »

39
2.1.6. Représentation du diagramme de séquence « Gérer le maintenance »
Figure 14 : Diagramme de séquence « Gérer le maintenance »

40
3. Diagramme d'activité :
Parmi les avantages d’UML est la possibilité de représenter graphiquement le
comportement d’une méthode ou d’un cas d’utilisation à l’aide du diagramme d’activité (une
variante des diagrammes d’état-transitions).
L’activité dans ce diagramme représente une exécution d’un mécanisme de déroulement
d’étapes séquentielles. Le passage d’une activité vers une autre est matérialisé par une
transition.
Ces transitions sont déclenchées par la fin d’une activité et provoquent le début immédiat
d’une autre. En théorie, tous les mécanismes dynamiques pourraient être décrits par des
diagrammes d’activité mais seuls les mécanismes complexes ou intéressants méritent d’être
représentés; c’est dans cette perspective que nous avons utilisé le diagramme d’activité en
exploitant au mieux ses capacités ou caractéristiques afin de mettre en évidence les différentes
activités et transitions par les quelles passe le système durant son cycle d’utilisation.
Ainsi, nous présentons quelques diagrammes d’activités :
 S'authentifier.
 Gestion de vente.
 Gestion du client.
S'authentifier :
Pour accéder à notre application, l’utilisateur doit s’authentifier en entrant son login et
son mot de passe. Le processus d’authentification peut être résumé dans le diagramme
d’activités de la figure 15:

41
Figure 15 : Diagramme d'activité « S'authentifier »
Ce diagramme d’activité « s’authentifier » présente la manière d'entrer a l'application.
L’utilisateur demande tout d’abord la page d’accueil de l'application, il saisit son login et son
mot de passe, le système vérifie les informations saisies avec les données de la base de
données. Si les informations saisies sont correctes, il est autorisé à se connecter à
l’application, sinon un message s’affiche pour lui demander de vérifier ces informations
saisies.
Gestion de la vente :
Pour passer une commande du client de Moulin d'olive, il faut passer par ces étapes
présentées dans le diagramme d’activité présenté dans la figure 16 :

42
Figure 16 : Diagramme d'activité « Gestion de la vente »
Le diagramme (figure16) représente les activités qui peuvent être faite pour chaque client.
Pour passer une commande, le responsable remplit d’abord le formulaire puis envoie
les informations de ce formulaire (date de commande, CIN du client, type de règlement,
quantité d'huile achetée de chaque citerne, unité d’huile (KG/L), prix total).Le responsable
peut aussi consulter les factures de chaque client.
Gestion du client :
Pour gérer les clients, le responsable du Moulin d'olive passe par un panel de gestion des
clients dont ces fonctionnalités se présentent comme suit :

43
Figure 17 : Diagramme d'activité « Gestion du client »
Ce diagramme explique la manière dont le responsable effectue des mises à jour de ces
clients ainsi une erreur système ou de saisi peut être dû à chaque opération (ajouter, modifier,
supprimer) ce qui demande à l’utilisateur de vérifier les champs de saisie; si l’opération passe
avec succès, le système informe l’utilisateur à travers une réponse de validation.
Conclusion :
Dans ce chapitre nous avons décrit la phase de l’étude conceptuelle de la future
application. Durant cette phase nous avons identifié les classes indispensables pour remplir
les besoins fonctionnels du système. Ensuite nous avons établis quelques scénarios de
l’utilisation de notre application et le diagramme de classes.
Le chapitre suivant traitera la phase de mise en œuvre de l’application.

44
Chapitre 4: Réalisation et mise en
œuvre
Introduction :
Cette partie constitue le dernier volet de ce rapport et dont l’objet est d'exposer le
travail achevé. Elle nous permet ainsi de valider le travail ou bien de réitérer en vue
d’éventuelles améliorations.
Dans le cadre de ce chapitre, nous présentons l’environnement de développement
utilisé et le choix technique et technologique ainsi que les différentes étapes de
l’implémentation. Ensuite, nous faisons une description des interfaces et des états de
l'application avec quelques captures d'écrans. Enfin, nous abordons la phase de test.
1. Présentation de l’environnement :
Afin d’accomplir notre projet, nous avons eu recours à un environnement matériel et logiciel.
1.1. Environnement matériel :
Pour réaliser ce projet, nous avons utilisé les ordinateurs suivant:
 Deux PC ASUS, SAMSUNG possédants une RAM de capacité 8 GB/GO.
 Deux processeurs Intel® Core™ i5- 2.20 GHz et Intel® Core™ i5- 2.59 GHz
 Système d'exploitation 64 bits.
 Deux disque dur de capacité 1000 GB/GO et 500GB/Go.
1.2. Environnement logiciel :
L’environnement logiciel sur lequel nous avons travaillé est constitué de :
StartUML : c’est un outil de conception et de modélisation des Systèmes d'Entreprises pour
la réalisation les diagrammes de modélisation UML.
Notepad++ : c'est un éditeur de texte; nous l’avons utilisé afin de réaliser les pages web
intégrant les style CSS et des java scripts.

45
MySQL manager 2010 : pour la création et manipulation de la base données.
Serveur d'application Apache Tomcat : c'est un conteneur web libre de servlets et JSP Java
EE. Issu du projet Jakarta, c'est l’un des nombreux projets de l’Apache Software Foundation.
Il implémente les spécifications des servlets et des JSP du Java Community Process, est
paramétrable par des fichiers XML et des propriétés, et inclut des outils pour la configuration
et la gestion. Il comporte également un serveur HTTP.
Eclipse IDE : c’est l’environnement de travail qui permet la création des composants de notre
application.
2. Choix techniques :
2.1. Choix du langage :
JAVA : Les applications Java sont compilées en byte code (les fichiers *.class) destinés à
être interprétées plus tard par la machine virtuelle de Java (Java Virtual Machine (JVM)).Il ne
s’agit donc pas de code machine, mais d’un code intermédiaire. Une application Java est, en
règle générale, un ensemble de fichiers .classes regroupés dans un paquetage (package).
Une application Java peut ainsi être déployée sur n’importe quelle plateforme compatible Java
installée sans être recompilée(JRE).
On dit alors que les applications Java sont portables au niveau binaire.
Parmi les caractéristiques de JAVA : Fiabilité, Sécurité, Portable.
3. Choix technologiques :
L’utilisation de la technologie J2EE nous permet de bénéficier de ses principales
caractéristiques qui sont :
• Un seul langage : Java.
• Une grande variété de plateformes et de systèmes d’exploitation qui sont capables de faire
fonctionner une application J2EE.
• Il existe un grand nombre déférents d’IDE pour le développement.
Il existe plusieurs framework pour le développement d’une application avec la technologie
J2EE parmi lesquelles, pour le développement de notre application, nous avons utilisé :

46
3.1. Spring :
Spring est un framework complet d’applications Java/Java EE, il est effectivement un
conteneur dit « léger », c'est-à-dire une infrastructure similaire à un serveur d'application
J2EE. Il prend donc en charge la création des objets et la mise en relation d'objets par
l'intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les relations de
dépendances entre ces objets [3].
Il permet de séparer le code métier du code technique.
 Spring s’appuie principalement sur l’intégration de trois concepts clés :
 l’inversion de contrôle ou injection de dépendance (IoC).
 la programmation orientée aspect (AOP).
 une couche d’abstraction.
Ce framework, grâce à sa couche d’abstraction, ne concurrence pas d’autres framework dans
une couche spécifique d’un modèle architectural MVC mais s’avère un framework
multicouches pouvant s’insérer au niveau de toutes les couches.
3.2. Hibernate :
Hibernate est un framework open source gérant la persistance des objets en base de données
relationnelle. Il est adaptable en termes d'architecture. Il peut donc être utilisé aussi bien dans
un développement client lourd, que dans un environnement web léger de type Apache
Tomcat ou dans un environnement Java EE complet : WebSphere, JBoss Application
Server et Oracle WebLogic Server[4].
Hibernate est l'implémentation concrète du moteur de persistance. En outre, le moteur lui-
même offre un certain nombre d'APIs de requêtage.
La Java Persistence API (abrégée en JPA) :
C’est une interface de programmation Java permettant aux développeurs d'organiser
des données relationnelles dans des applications utilisant la plateforme Java.
La Java Persistence API est à l'origine issue du travail du groupe d'experts JSR 220.
La persistance dans ce contexte recouvre 3 zones :
 l'API elle-même, définie dans le paquetage javax.persistence
 le langage Java Persistence Query (JPQL)

47
 les objets/les métadonnées relationnelles.
La Java Persistence API repose essentiellement sur l'utilisation des annotations, introduites
dans Java 5. Elles permettent de définir facilement des objets métier, qui pourront servir
d'interface entre la base de données et l'application, dans le cadre d'un mapping objet-
relationnel
3.3. JSP :
Le Java Server Pages ou JSP : une technique basée sur Java qui permet aux développeurs de
créer dynamiquement du code HTML. Cette technique permet au code Java et à certaines
actions prédéfinies d'être ajoutés dans un contenu statique.
Cette technique permet la création de bibliothèques de balises JSP (taglib) qui agit comme
des extensions au HTML. Les bibliothèques de balises offrent une méthode indépendante de
la plate-forme pour étendre les fonctionnalités d'un serveur HTTP. Il existe aussi un langage
de script particulier, appelé Expression Language (EL) destiné à réduire l'injection de code
java au sein des pages JSP ainsi qu'à étendre les possibilités des taglibs, tel que la JSTL.
JSTL :
La Java Server Pages Standard Tag Library (JSTL) est un composant de la plate-
forme JEE de développement. Elle étend la spécification JSP en ajoutant une bibliothèque de
balises pour les tâches courantes. JSTL a été développée par la Java Community
Process (JCP). Le 8 mai 2006, la JSTL 1.2 est sortie [5].
3.4. JUnit :
JUnit est un framework de test unitaire pour le langage de programmation Java. Créé
par Kent Beck et Erich Gamma, JUnit est certainement le projet de la série
des xUnitconnaissant le plus de succès [6].
3.5. Spring security :
Spring Security permet de sécuriser les applications Spring, en particulier dans un
environnement Java EE.
 Il fonctionne dans tous les serveurs d’applications.
 Il vient de remplacer la sécurité standard Java EE.
 Il est très répandu en production, car il propose des fonctionnalités particulièrement
avancées.

48
 Il se configure via un fichier de configuration Spring.
 Il peut sécuriser des URLs mais aussi des méthodes Java.
 Spring Security est une alternative à la sécurité fournie par les serveurs d’applications
Java EE.
4. Architecture de l’application adoptée :
Figure 18 : les couches de notre application
4.1. Couche de Présentation :
Cette couche correspond à la présentation de l'interface graphique, l'enchainement des
pages et la logique applicative. En d'autres termes, c'est la partie visuelle de l'application que
pourra observer l'utilisateur. Elle est basée sur le modèle MVC et utilise la technologie JSP.
Nous avons utilisé les langages suivants: HTML, CSS, JQuery et Ajax.
4.2. Couche de Persistance (Couche d'accès aux données) :
Le rôle de cette couche est d'insérer, de mettre à jour, de supprimer, ou de rechercher les
objets métiers dans la base de données. Elle contient donc le gestionnaire de persistance des
objets métiers (DAO). Cette couche de persistance utilise le framework Hibernate. La
connexion de Hibernate avec la base se fait via un driver JDBC.
4.3. Couche métier :
C'est véritablement au sein de cette couche que sont réalisées toutes les actions de
traitement de notre application. Les transactions sont déclarées dans cette couche (service).

49
4.4. Architecture modèle-vue-contrôleur (MVC) :
Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais Model-View-Controller)
est une architecture et une méthode de conception qui organise l'interface homme-machine
(IHM) d'une application logicielle. Ce paradigme divise l'IHM en un modèle (modèle de
données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle,
gestion des événements, synchronisation), chacun ayant un rôle précis dans l'interface. Cette
méthode a été mise au point en 1979 par ‘’Trygve Reenskaug’’, qui travaillait alors sur
‘’Smalltalk’’ dans les laboratoires de recherche’’ Xerox PARC’’» :
Ce modèle d'architecture impose la séparation entre les données, la présentation et les
traitements; ce qui donne trois parties fondamentales dans l'application finale :
 le modèle.
 la vue.
 le contrôleur.
L'organisation globale d'une interface graphique est souvent délicate. L'architecture MVC
ne résout pas tous les problèmes. Elle fournit souvent une première approche qui peut ensuite
être adaptée. Elle offre aussi un cadre pour structurer une application.
Ce modèle d'architecture impose la séparation entre les données, la présentation et les
traitements, ce qui donne trois parties fondamentales dans l'application finale (figure19) :
Le modèle : Le modèle représente le comportement de l'application : traitements des données,
interactions avec la base de données, etc. Il décrit ou contient les données manipulées par
l'application. Il assure la gestion de ces données et garantit leur intégrité. Dans le cas typique
d'une base de données, c'est le modèle qui la contient.
La vue : La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche
est de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes
les actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons…). Ces différents
événements sont envoyés au contrôleur. La vue n'effectue aucun traitement, elle se contente
d'afficher les résultats des traitements effectués par le modèle.
Le contrôleur : Le contrôleur prend en charge la gestion des événements de synchronisation
pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de
l'utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des

50
données, le contrôleur demande la modification des données au modèle et ensuite avertit la
vue que les données ont changé pour qu'elle se mette à jour.
Figure 19 : Exemple d'architecture MVC
5. Présentation des interfaces :
Cette étape consiste à décrire les différents scénarios possibles de l’utilisation de notre
application correspondant à chaque interface. Ainsi, nous avons choisi de représenter
quelques interfaces relatives à chaque scénario :
 S’authentifier.
 Gestion les clients.
 Gestion de vente.
 Gestion d'achat.
 Gestion de stock.
 Gestion de maintenance.
 Gestion de caisse.
 Gestion des réservations.
 Gestion des fournisseurs.

51
Interface « s’authentifier »
L'interface authentification est présentée dans la figure 20. Durant cette dernière
l’utilisateur doit saisir son login et mot de passe pour pouvoir passer à la page d’accueil et au
reste des fonctionnalités de notre application Web.
Cette étape met en valeur l’aspect sécurité : nous vérifions la disponibilité du compte
utilisateur et nous lui attribuons les droits et privilèges nécessaires.
Figure 20 : Interface « S’authentifier »
Interface « Accueil(gérer la caisse)»
Une fois passé par l’interface d’authentification à partir de laquelle l’utilisateur a été
authentifié avec succès. Ce dernier sera redirigé vers une interface d’accueil (figure21).
Grâce à cette interface l’utilisateur peut ajouter et retirer d’argent de la caisse et peut
consulter le budget aussi.
On trouve en haut le menu principal et à gauche le sous menu :
Menu principale:
Réservation : Ajouter une réservation, Consulter les réservations.
Commande : Ajouter une commande, Factures du client.

52
Achat d'olive : Ajouter un achat, Bon d'achat du fournisseur, Consulter les fournisseurs.
Maintenance : Ajouter une maintenance, Consulter les maintenances, Consulter les
fournisseurs.
Fournisseurs : Fournisseurs d'olive, Fournisseur de maintenance.
Stock : Stock d'olive, Stock d’huile, Gérer le stock.
Sous menu:(varie selon la page)
Gérer la caisse, Ajouter un client, Consulter la liste des clients, Ajouter un employé,
Consulter la liste des employés.
Figure 21 : Interface « Accueil »
Interface « Ajouter un client »
Pour l’ajout d’un nouveau client le responsable saisie toutes les informations qui lui
sont relatives (CIN, nom, prénom, adresse, téléphone) comme présenté dans la figure 22 puis
clique sur Ajouter.

53
Figure 22 : Interface « Ajouter un client »
Interface « Consulter la liste des clients »
Dans le sous menu, le responsable choisi « Consulter la liste des clients » pour pouvoir
consulter tous les clients : dans cette interface, on trouve la liste des clients avec toutes ses
informations (nom, prénom, numéro de carte d’identité, téléphone) qui sont enregistrés dans
la base de données.
Pour consulter un client, il faut saisir le numéro de carte d’identite de client demandé ( ou
le nom du client ) avec la possibilité de modifier ou supprimer les informations saisies
précédemment lors de l’ajout de chaque client.
Figure 23 : Interface « Consulter la liste des clients »

54
Interface « Ajouter une Commande »
Pour enregistrer une nouvelle commande du client le responsable saisie toutes les
informations demandées par le client (la date, l'unité de huile (KG/L), sélectionner le
client).
En bas, nous trouvons " la liste de citerne ". Lors de l'ajout d'une quantité d'huile
achetée, cette demande va directement, apparaitre dans le formulaire.
Quand nous sélectionnons les produits achetés, le champ de désignation va être rempli
automatiquement.
Il y a un lien « Gérer les clients » pour passer à l’interface d’ajout du client.
Après avoir rempli le formulaire de la figure 24, il suffit de cliquer sur le bouton ''ajouter''.
Figure 24 : Interface « Commande »
En cliquant sur le bouton ''ajouter'' une nouvelle interface graphique s'affiche cette
interface représente "la facture" (figure 25).

55
Figure 25 : Interface « Facture »
Interface « Imprimer facture »
L'impression se fait en cliquant sur l'icone "imprimer" qui se trouve en haut comme
représente la figure 25 et 26.

56
Figure 26 : Interface « Imprimer facture »
Interface « Facture du client »
Dans cette interface, lors de l'insertion du numéro de carte d’identité du client, toutes leurs
données et les anciennes factures s'affichent et nous avons la possibilité de supprimer l'une
de ces factures (figure 27).

57
Figure 27 : Interface « Facture du client »
Interface « Ajouter un achat d'olive »
Cette interface permet d'ajouter un bon d'achat en déterminant les attributs suivants: date,
maturité, quantité d'olive, désignation, région d'olive, montant d'achat. En plus, il faut préciser
le fournisseur et le lieu du stockage. Pour cela, il y a un lien « Gérer les fournisseurs » qui
permet de passer à l’interface d’ajout du fournisseur d’olive (figure 28).

58
Figure 28 : Interface « Ajouter un achat d'olive »
Interface « Consulter bons du fournisseur »
Dans cette interface, et quand nous tapons le numéro de carte d’identité de fournisseur,
tous leurs données et leurs anciens bon d'achat s'affichent et nous avons la possibilité de
supprimer ou de modifier l'un de ces bon d'achat (figure 29).
Figure 29 : Interface « Bons du fournisseur »

59
Interface « Ajouter une citerne »
Grâce à cette interface l’utilisateur peut ajouter des citernes à la base de données.
Figure 30 : Interface « Ajouter une citerne »
Interface « Consulté la liste des citernes»
Dans cette interface, nous trouvons la liste des citernes du moulin d'olive avec toutes les
informations (référence de la citerne, capacité, quantité d'huile, qualité d'huile) qui sont
enregistrés dans la base de données.
Pour consulter une citerne, il faut saisir sa référence, avec la possibilité de modifier ou
supprimer les informations saisies précédemment lors de l’ajout de chaque citerne.
Figure 31 : Interface « Consulter la liste des citernes »

60
Interface « gérer le stock »
Grâce à cette interface le responsable peut retirer d’olive, vider la cuve et ajouter l'huile
d'olive dans les citernes. Nous utilisons cette interface pour la production d’huile d’olive.
Le retrait de la quantité d’olive utilisée dans la production se fait automatiquement (la figure
32).
Figure 32 : Interface « Gérer le stock »
Interface « Ajouter une maintenance »
Grâce à cette interface l’utilisateur peut ajouter une maintenance en introduisant les
informations qui lui sont relatives (date de la maintenance, prix, description de la panne).
Avant tout cela, il faut préciser le fournisseur de la maintenance.
Il y a aussi un lien « Gérer les fournisseurs » qui permet de passer à l’interface d’ajout du
fournisseur de la maintenance, comme montre la figure 33.

61
Figure 33 : Interface « Ajouter une maintenance »
Interface « Consulter la liste des maintenances »
Dans cette interface, on trouve la liste des maintenances avec toutes les informations
(description, date de maintenance, prix, nom du fournisseur, prénom du fournisseur, numéro
de carte identité, mobile du fournisseur) qui sont enregistrés dans la base de données, avec la
possibilité de modifier ou supprimer l'une des maintenances.
En plus nous pouvons rechercher une ou plusieurs maintenances par le nom du fournisseur
de la maintenance écrit dans le champ texte de recherche, comme montre la figure 34:
Figure 34 : Interface « Consulter la liste des maintenances »

62
Interface « Ajouter une réservation »
Grâce à cette interface, l’utilisateur peut ajouter une réservation en introduisant les
informations qui lui sont relatives (date de réservation sous forme d’un calendrier, prix,
description de la réservation). Pour la précision du client, il ya aussi un lien « Gérer les
clients » qui fait passer à l’interface d’ajout du Client, comme montre la figure 35.
Figure 35 : Interface « Ajouter une réservation »
Interface « Consulter la liste des réservations »
Dans cette interface, nous trouvons la liste des réservations avec toutes les informations
(prix, date de réservation, description, nom du client, prénom du client, numéro de carte
d’identité, mobile du client) qui sont enregistrés dans la base de données, avec la possibilité
de modifier ou supprimer l'une des réservations.
En outre, nous pouvons rechercher une ou plusieurs réservations par "la date" écrite dans
le champ texte de recherche, comme montre la figure 36.

63
Figure 36 : Interface « Consulter la liste des réservations »
Interface « Ajouter un fournisseur d'olive»
Dans le cas d'ajout d'un fournisseur d'olive ou de maintenance nous adaptons la même
interface.
Grâce à cette interface, l’utilisateur peut ajouter un fournisseur en introduisant les
informations qui lui sont relatives (CIN, nom, prénom, mobile, adresse).
Figure 37 : Interface « Ajouter un fournisseur d'olive »

64
Interface « Consulter la liste des fournisseurs d'olive »
Dans le cas de consultation des listes des fournisseurs d'olive et des maintenances nous
introduisons la même interface.
Aussi, même que l’interface de la liste des clients.
Figure 38 : Interface « Consulter fournisseur d'olive »
Gestion des dialogues :
La figure 39 montre quelques boites de dialogues générés par l’application
développée: ces exceptions traitent les cas limites, le dialogues homme système, …etc. Pour
s’assurer de la saisie entrée par l’utilisateur ou bien une décision prise, par exemple le
système demande à l’utilisateur de bien réfléchir avant de supprimer un client car ce dernier
peut se tromper par une faute de frappe par exemple.
Si la décision est bonne, le système informe l’utilisateur que le client a bien été supprimé.

65
Figure 39 : Gestion des exceptions
Test Et validation :
Le test de l'application est une étape inévitable dans la conception des applications. Il
peut être un processus manuel ou automatique, qui a pour objet de vérifier si les résultats
donnés par le système correspondent aux objectifs préétablis avant sa conception.
Le test peut aussi avoir comme objectif de vérifier le respect des contraintes comme la
performance temporaire, critère de sécurité, portabilité du logiciel, etc.
On ne peut pas connaître en avance le nombre de tests nécessaires mais le test doit se
baser sur le fonctionnement du logiciel, les interfaces de ce logiciel et les contraintes établis
par les développeurs.

66
Dans la conception d'une nouvelle application, on doit recourir à plusieurs étapes afin
d'aboutir à un produit fini afin que ce produit soit utilisé par les entreprises sans erreurs.
Dans ces étapes nous pouvons citer : l'analyse préétablie d'un cahier des charges, la
conception, le codage, les tests, la validation, l'intégration, la mise en place d'un nouveau
système, la réception du système et sa validation ainsi que sa maintenance.
Conclusion :
Dans ce chapitre, nous avons commencé par définir l’environnement du projet. Puis
nous avons présenté les différentes fonctionnalités implémentées dans notre application, en
mettant l’accent sur les technologies utilisées et les méthodes de développements suivies.
En effet nous avons présenté la majorité des interfaces implémentées dans notre
application.

67
Conclusion générale
L'objectif de ce travail était d’informatiser l’activité de gestion du moulin d’olive.
Pour cela, nous avons réalisé une application interactive permettant de gérer les différentes
activités et de satisfaire les besoins d’utilisateur impliqués dans ce processus de gestion.
Notre stage est débuté par la compréhension du contexte de notre projet, à savoir le moulin
d’olive, ses concepts et ses activités. Ensuite, nous avons réalisé la modélisation du métier
concernant le domaine ou le métier de moulin d’olive, ce qui nous a permis de fixer les
anomalies à éviter et les objectifs à réaliser pour avoir un système satisfaisant. Puis, nous
avons passé à la capture des besoins pour présenter un recueil des besoins fonctionnels et
techniques. Par la suite, nous avons effectué l'analyse et la conception selon une approche
orientée objet tout en se basant sur le langage UML. Après, nous avons terminé avec le
codage et l’implémentation de l’application. Enfin, nous avons effectué les tests nécessaires
pour valider notre application.
Ce stage nous a permis de renforcer plusieurs notions telles que la gestion optimale du temps
et la communication. La réalisation du projet nous a permis, aussi, de raffiner notre capacité
de conception et de renforcer nos compétences en matière de technologies telles que J2EE et
les framework de développement (Spring, Hibernate) ainsi l’utilisation de la base de données.
En plus, ce projet était une bonne occasion pour réaliser un travail très concret, avec des
objectifs clairs et bien définis et de se familiariser avec l'environnement du travail et la vie
professionnelle. Nous avons donc créé une application extrêmement facile à utiliser. En effet,
nous avons créé une interface utilisateur ergonomique où la plupart des commandes sont
faciles pour l’accès ou bien pouvant être exécutées graphiquement avec de simples
manipulations de la souris.
En outre, ce stage était pour nous une occasion de traduire nos connaissances théoriques et
pratiques, dans le domaine professionnel, particulièrement au sein d’un établissement ayant
un poids particulier dans l’économie nationale.
En perspective, notre application peut être améliorée en ajoutant d'autres fonctionnalités
(comme la gestion du pointage, gestion des congés, gestion des opérations import/export,
etc.).

68
Bibliographie
[1] http://www.tunisia-oliveoil.com/Fr/notre-histoire_8_14 (17/03/2016).
[2] P. Roques, 7ème édition, UML2 par la pratique, Eyrolles.
[3] http://fr.wikipedia.org/wiki/Spring_framework (visité le 20/04/2016).
[4] https://fr.wikipedia.org/wiki/Hibernate.
[5] https://fr.wikipedia.org/wiki/JavaServer_Pages_Standard_Tag_Library
[6] https://fr.wikipedia.org/wiki/JUnit

69
Les exceptions
Exception1 : Login et mot de passe incorrects, connexion refusée.
Exception3 : Le système affiche « Client introuvable »
Exception4 : Le système affiche « s’il vous plait choisir l’unité d’huile ».
Exception5 : Le système affiche le message suivant « La quantité demandée est supérieure à
la quantité trouvable dans la citerne » .
Exception6 : Le système affiche « Vérifier les informations de cette commande !» .
Exception7 : Le système affiche « Fournisseur introuvable »
Exception8 : Le système affiche « Citerne introuvable »
Exception9 : Le système affiche « la quantité ajoutée est supérieure à la quantité trouvable
dans la citerne ».

Rapport final

Contenu connexe

Tendances

Similaire à Rapport final

Plus de Hassen BEN SLIMA

Rapport final

Contenu connexe

Tendances

Similaire à Rapport final

Plus de Hassen BEN SLIMA

Rapport final