117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medecine.pdf

Ministère l’Enseignement Supérieur de la Recherche scientifique
Université de Monastir
Institut Supérieur d’Informatique et de Mathématique
Monastir
PFE
Pour l’obtention d’une licence en génie logiciel informatique
appliqué
Présenté et soutenu par
Slimene Ranim & Selmi Sabrine
Le 03/07/2012
Application Web de Gestion de stock du magasin de Faculté
de Médecine
Composant du jury:
President du jury: Mr. Elkamel Akil
Rapporteur : Mr. Khedher AbdelKarim
Encadrant : Mr. Ramzi Mahmoudi

2 | P a g e
Dédicace
A mes très chers parents
Pour tout l’amour dont vous m’avez entouré,
Pour tout ce que vous avez fait pour moi. Je vous dois ce que je suis
aujourd’hui grâce à votre amour, à votre patience et vos
innombrables sacrifices…
Je ferai mon mieux pour rester un sujet de fierté à vos yeux avec
l’esprit de ne jamais vous décevoir…
A mes deux sœurs (Héla & Hanin) et mon petit frère (Ahmed)
Vous occupez une place particulière dans mon cœur, je vous dédie ce
travail en vous souhaitant un avenir radieux, plein de bonheur et de
succès. Je vous dirai tout simplement merci, je vous aime tant.
Que le bon Dieu veille sur vous…
A mes très chers ami(e)s
En témoignage de l’amitié sincère qui nous a liées et des beaux
moments passés ensemble je vous dédie ce travail en vous souhaitant
tout le bonheur du monde…
A ma chère binôme Sabrine
En souvenir de nos éclats de rire, des bons moments et des nuits
blanches.
J’espère de tout mon cœur que notre amitié durera éternellement et
que le succès, le bonheur et la bonne étoile vous accompagnent durant
toute la vie…
Ranim

3 | P a g e
Dédicace
A mes très chers parents
Qui m’ont fourni au quotidien un soutien et une confiance sans faille
Et de ce fait,
Je ne saurais exprimer ma gratitude seulement par des mots.
Que dieu vous protège et vous garde pour nous.
A ma précieuse sœur et binôme Ranim, les mots ne peuvent résumer
Ma reconnaissance et mon amour à ton égard
A ma belle sœur Nour
A mon beau-frère Oussama
A mes adorables amies, Ilhem et Dhouha pour leur fidélité
A tous mes amis avec lesquels j’ai partagé mes moments de
joie et de bonheur
Que toute personne m’a aidé de près ou de loin, trouve ici l’expression
de ma reconnaissance.
Sabrine

4 | P a g e
Remerciement
Au terme de ce travail,
Nous saisissons cette occasion pour exprimer
Nos vifs remerciements à toutes personnes ayant contribué, de prés ou
de loin, à la réalisation de ce travail.
On adresse nos sincères remerciement a
Monsieur Ramzi Mahmoudi, notre encadrant, qui a veillé pas a pas
l’élaboration de ce travail, pour son aide,
Ses efforts précieux pour pouvoir nous mettre dans le bon chemin.
Nous exprimons également notre gratitude aux membres de jury, qui
nous ont honorés de juger notre travail.
Ainsi que nos professeurs, pour leurs conseils avisés. Nous avons
apprécié leur disponibilité et leur patience.

5 | P a g e
Sommaire
RESUME -------------------------------------------------------------------------------------------------------------- 7
LISTE DES FIGURES --------------------------------------------------------------------------------------------- 8
CHAPITRE I : INTRODUCTION ----------------------------------------------------------------------------- 10
I.1. CONTEXTE ET MOTIVATIONS : -----------------------------------------------------------------------11
I.2. CONTRIBUTIONS :------------------------------------------------------------------------------------12
I.3. ORGANISATION DU RAPPORT : -----------------------------------------------------------------------13
CHAPITRE II : SPECIFICATION ET ANALYSE DES BESOINS------------------------------------ 15
II.1. INTRODUCTION : ------------------------------------------------------------------------------------16
II.2. DESCRIPTION DU PROJET : -------------------------------------------------------------------------16
II.2.1. Domaine d’application :.......................................................................................... 17
II.2.2. Spécification des besoins : ..................................................................................... 17
II.3. ETUDE DE L’EXISTANT : ----------------------------------------------------------------------------19
II.3.1. Importance de la gestion automatisée des stocks :................................................ 19
II.3.2. Exemples de logiciels existants sur le marché : ..................................................... 19
II.3.3. Critique de l’existant : ............................................................................................ 22
II.3.4. Conclusion : ............................................................................................................ 22
CHAPITRE III: ETUDE CONCEPTUELLE ---------------------------------------------------------------- 24
III.1. INTRODUCTION : -----------------------------------------------------------------------------------25
III.2. L’APPROCHE UML ADOPTEE : ---------------------------------------------------------------------25
III.3. ÉTUDE ET MODALISATION DE LA SOLUTION :------------------------------------------------------27
III.3.1. Les diagrammes des cas d’utilisations : ............................................................... 27
III.3.1.1. Diagramme de cas d’utilisation « Magasinier » : -------------------------------------------- 28
III.3.1.2. Diagramme de cas d’utilisation «client» :----------------------------------------------------- 31
III.3.1.3. Diagramme de cas d’utilisation « Fournisseur » :------------------------------------------- 33
III.3.2. Les diagrammes de séquences : ........................................................................... 35
III.3.2.1. Diagramme de séquence « Saisir et m-a-j de la base de donnée » : ---------------------- 35
III.3.2.2. Diagramme de séquence « Inscription Client » :------------------------------------------- 36
III.3.2.3. Diagramme de séquence « authentification Client » :------------------------------------- 37
III.3.2.3. Diagramme de séquence scénario « Commander » :---------------------------------------- 38
III.3.2.4. Diagramme de séquence du scénario « Répondre aux appels d’offres » : --------------- 39
III.3.2.5. Diagramme de séquence de scénario « Communication » : ------------------------------- 39
III.3.4. Diagramme de classes : ........................................................................................ 40
III.3.3. Diagramme d’état transition :................................................................................ 41
III.4. PRESENTATION DES MAQUETTES PRELIMINAIRES : -----------------------------------------------44
III.5. CONCLUSION : -------------------------------------------------------------------------------------46
CHAPITRE IV : TECHNIQUE DE DEVELOPPEMENT ------------------------------------------------ 47
IV.1. INTRODUCTION : -----------------------------------------------------------------------------------48
IV.2. DESCRIPTION DE L’ENVIRONNEMENT DE DEVELOPPEMENT INTEGRE :---------------------------48
IV.2.2. Environnement Logiciel : ....................................................................................... 49
IV.2.2.1. WampServer : ------------------------------------------------------------------------------------ 49
IV.2.2.2. PHP :----------------------------------------------------------------------------------------------- 49
IV.2.2.3. CSS :----------------------------------------------------------------------------------------------- 50
IV.2.2.4. Java Script : ------------------------------------------------------------------------------------- 50
IV.2.2.5. Photoshop : --------------------------------------------------------------------------------------- 51

6 | P a g e
IV.3. LES PHASES DE DEVELOPPEMENT : ---------------------------------------------------------------52
IV.4. LES SCENARIOS DE DEVELOPPEMENT : -----------------------------------------------------------53
IV.4.1. Évaluation des scénarios : ................................................................................... 54
IV.5. LES PHASES DE DEVELOPPEMENT : ---------------------------------------------------------------55
IV.5.1.Réalisation de la rubrique de Commande : ............................................................ 55
IV.5.2.Réalisation de la rubrique d’appel d’offre :............................................................ 58
IV.5.3.Réalisation de la rubrique d’édition : ..................................................................... 60
IV.6. INTERFACES DE L’APPLICATION: -------------------------------------------------------------------62
 Espace administrateur :............................................................................................ 63
 Espace Fournisseur :................................................................................................ 65
 Espace client : ........................................................................................................... 67
IV.7. CONCLUSION : -------------------------------------------------------------------------------------69
CHAPITRE V : CONCLUSION -------------------------------------------------------------------------------- 70
ANNEXE------------------------------------------------------------------------------------------------------------- 72
EXTENSION ANDROID----------------------------------------------------------------------------------------- 74
I. INTRODUCTION : ------------------------------------------------------------------------------------75
II. DEFINITION DE L’ANDROID : ------------------------------------------------------------------------75
III. HISTORIQUE D’ANDROID : -----------------------------------------------------------------------75
IV. ARCHITECTURE D’ANDROID : --------------------------------------------------------------------76
V. COMPOSANTS PRINCIPAUX DE L’ANDROID :-----------------------------------------------------------77
IVI. OUTILS DE REALISATION D’UN PROJET ANDROID : -------------------------------------------------77
VI.1. Outils et installation : ............................................................................................... 77
VI.2. Création et utilisation de l’émulateur : ...................................................................... 78
VI.3. Création d’un projet Android :.................................................................................. 79
VI.4. Modification de l’interface graphique: ....................................................................... 79
VII. Les interfaces : ........................................................................................................... 80
VIII. Conclusion :............................................................................................................... 82

7 | P a g e
Résumé
ne application de gestion des stocks est un système informatique qui
permet d'assurer le suivi des niveaux des produits, commandes, ventes et
livraisons. Il peut également être utilisé dans l'industrie manufacturière de
créer un ordre de travail, le projet de loi de matériaux et d'autres documents liés à
la production
Les entreprises utilisent les applications de gestion des stocks pour éviter les
stocks excédentaires de produits et de pannes. Il s'agit d'un outil pour organiser les
données d'inventaire qui a été avant généralement stockés sous forme de copie
papier, Spécialement le magasin qui est un espace de stockage où les marchandises
sont rangées suivant un ordre bien précis. Il permet de garder un état juste des
stocks ; il assure pour chaque article un point de gestion entre l’approvisionnement
et la consommation ; c’est le lieu où l’on pointe les entrées et les sorties ; le magasin
offre des emplacements de stockage bien matérialisés ; ce qui permet de réaliser des
inventaires afin de garantir l’exactitude permanente des quantités de marchandises
disponibles.
Notre stage s’est déroulé au sein de l’association sportive de la faculté de
médecine de Monastir, Son but était de développer un ensemble d’applications afin
de mettre à la disposition des utilisateurs, des outils informatiques leur permettant
de faciliter leur travail. Ce stage était principalement destinés à la mise en place
d’une application web de gestion des stocks qui nécessite un développement
spécifique car les logiciels existants sur le marché sont prévus pour une utilisation
plus poussée et manquent de simplicité d’utilisation.
Notre mission consiste à construire une application qui a pour rôle de
simplifier les taches et du magasin de la faculté, aider le magasinier à organiser
son travail et mémoriser ses données sans avoir passé par les archives et lui
informé en cas d’une rupture de stock, aussi pour aider les utilisateurs et les
professeurs de la faculté, qui réclame tout le temps des produits.
Par la réalisation de cette application on va organiser les demandes, mettre
en premier lieu les dates des besoins pour les commandes et remplacer les feuilles
et les archives par une mémoire stocké dans un disque dur bien sécurisé.
U

8 | P a g e
Liste des figures
Fig. 1 : Modélisation graphique du projet -------------------------------------------------------------------------- 17
Fig. 2 : Consultation d’un article (DJA Soft) --------------------------------------------------------------------- 20
Fig. 3 : Une facture pour Dja soft-------------------------------------------------------------------------------------- 20
Fig. 4 : Cinq façons de voir un système (4+1 vues de Kruchten) ---------------------------------------- 25
Fig. 5 : Les trois composantes d’une modélisation------------------------------------------------------------- 26
Fig. 6 : diagramme de cas d’utilisation « Magasinier »------------------------------------------------------ 28
Fig. 7 : Description détaillé du cas d’utilisation « consulter le stock »-------------------------------- 29
Fig. 8 : Description plus détaillé du cas d’utilisation « consulter le stock »------------------------- 29
Fig. 9 : Diagramme de cas d’utilisation « client » ------------------------------------------------------------- 31
Fig. 10 : Description détaillé du cas d’utilisation « consulter le stock » ------------------------------ 31
Fig. 11 : Description plus détaillé du cas d’utilisation « consulter le stock »----------------------- 32
Fig. 12 : Diagramme de cas d’utilisation « Fournisseur» --------------------------------------------------- 33
Fig. 13 : Description détaillé du « Répondre aux appels d’offre » --------------------------------------- 33
Fig. 14 : Description plus détaillé du cas d’utilisation «Répondre aux appels d’offre» ---------- 34
Fig. 15 : Diagramme de séquence « Saisir et mise à jour de la base de donnée »------------------ 35
Fig. 16 : Diagramme de séquence de scénario « authentification Client » -------------------------- 36
Fig. 17 : Diagramme de séquence « Authentification »------------------------------------------------------- 37
Fig. 18 : Digramme de séquence du scénario « commander » ------------------------------------------ 38
Fig. 19 : Diagramme de séquence du scénario « Répondre aux appels d’offres » ----------------- 39
Fig. 20 : Diagramme de séquence de scénario « Communication » ------------------------------------ 39
Fig. 21 : Diagramme de classe ----------------------------------------------------------------------------------------- 40
Fig. 22 : diagrammes d’état transitions ---------------------------------------------------------------------------- 43
Fig. 23 : Interface Inscription ------------------------------------------------------------------------------------------- 44
Fig. 24 : Interface authentification------------------------------------------------------------------------------------ 45
Fig. 25 : Interface du formulaire d’une commande------------------------------------------------------------- 45
Fig. 26 : Le modèle de cycle de vie en cascade------------------------------------------------------------------ 52
Fig. 27 : Schéma d’évaluation des scenarios--------------------------------------------------------------------- 54
Fig. 28 : Page d’accueil de l’application ---------------------------------------------------------------------------- 62
Fig. 29 : Interface authentification administrateur------------------------------------------------------------- 63
Fig. 30 : Interface ajouter un fournisseur -------------------------------------------------------------------------- 63
Fig. 31 : Interface pour modifier un fournisseur----------------------------------------------------------------- 64
Fig. 32 : Interface pour ajouter un produit------------------------------------------------------------------------- 64
Fig. 33 : Interface pour publier un appel d’offre----------------------------------------------------------------- 65
Fig. 34 : Interface pour l’authentification des fournisseurs------------------------------------------------- 65
Fig. 35 : Interface pour les offres des produits des fournisseurs----------------------------------------- 66
Fig. 36 : Interface pour répondre aux appels d’offre de magasinier ------------------------------------ 66
Fig. 37 : Interface pour l’inscription ---------------------------------------------------------------------------------- 67
Fig. 38 : Interface authentification Client -------------------------------------------------------------------------- 67
Fig. 39 : Interface de consultation du stock----------------------------------------------------------------------- 68
Fig. 40 : Interface à remplir par l’utilisation pour commander--------------------------------------------- 68
Fig. 41 : Fiche de mouvement des entrées ------------------------------------------------------------------------ 72
Fig. 42 : Fiche des articles consommables ------------------------------------------------------------------------ 72
Fig. 43 : Fiche de stock---------------------------------------------------------------------------------------------------- 73
Fig. 44 : Evolution des versions d’Android. ----------------------------------------------------------------------- 75
Fig. 45 : Architecture du système d’exploitation Android --------------------------------------------------- 76
Fig. 46 : Liste des AVD crées ------------------------------------------------------------------------------------------- 78
Fig. 47 : Interface graphique -------------------------------------------------------------------------------------------- 79
Fig. 48 : Interface Smartphone ----------------------------------------------------------------------------------------- 80

9 | P a g e
Fig. 49 : Interface d'accès à l’application -------------------------------------------------------------------------- 80
Fig. 50 : Page d’accueil via Smartphone --------------------------------------------------------------------------- 81
Fig. 51 : Formulaire d’inscription via Smartphone ------------------------------------------------------------- 81
Fig. 52 : Interface d’authentification--------------------------------------------------------------------------------- 82

Chapitre I : Introduction
11 | P a g e
I.1. Contexte et motivations :
urant ces dernières années l'informatique s'est imposé d'une manière très
impressionnante dans les entreprises, cela est du à son apport
extraordinaire dans le domaine de gestion des bases de données.
En effet, l'informatique désigne l'automatisation du traitement de
l'information par un système concret « machine » ou abstraie. On entend également
par « l'informatique» l'ensemble des sciences et techniques en rapport avec le
traitement de l'information.
En réalité, ce traitement est de plus en plus utilisé dans tous les domaines
d'activités y compris celui de la gestion des stocks auquel nous rattacherons
d'ailleurs notre étude, et cela pour une meilleure gestion des différents traitements
imposés par cette activité de gestion des stocks.
Nous avons pu constater, en effet, pendant notre stage que l'ensemble des
traitements au sein du magasin de la FMM1 se fait manuellement, ce qui engendre
un certain nombre de problèmes tels que la lenteur dans l'accès aux données et le
risque de perte d’informations.
La meilleure solution pour palier ces problèmes est l'informatisation afin
d'assurer l'accès instantané aux données et la sécurisation de ces dernières, ce qui
simplifie le travail administratif.
De ce fait, on a été sollicité par les responsables de la faculté de médecine
afin de leur concevoir un système d'information automatisé pour leur gestion de
stocks, dans le but de diminuer le temps de travail, les coûts de conservation2 des
documents et ainsi réduire le coût de production3.
Nous proposons le developpement d’une application hébergée, permettant au
magasinier de la faculté de gérer le stock et les commandes en suivant la
disponibilité des marchandises, et en affichant les produits dont le stock est bas.
1 Faculté de Médecine de Monastir
2 Les frais de conservation ou de destruction de chéquier sont des frais variables prélevés par la grande majorité des banques
lorsque le client possesseur d’un compte bancaire n’a pas retiré son chéquier au guichet de sa banque
3 Les coûts auxquels une entreprise doit faire face afin d’assurer sa production de biens ou d’équipement
D

12 | P a g e
I.2. Contributions :
Lors de notre projet de fin d’étude nous avons réalisé un logiciel de gestion de
stocks et contribuer à l’amélioration du traitement de l’information.
Nous avons recensé les demandes spécifiques du directeur de la faculté ainsi que le
magasinier.
Notre logiciel doit répondre aux critères suivants :
 Automatiser la gestion de stocks.
 Organiser le travail du magasinier et améliorer la maintenance de la FMM.
 Faciliter le processus de commande.
 Avoir la possibilité d’imprimer n’importe quel document
 Améliorer le suivi de commande avec consultation de la hiérarchie.
 Sécuriser les accès.
 Diminuer les coûts de production.
 Avoir un historique.
 Avoir une alarme lorsque la quantité livrée est en dessous de 20% du stock.
 Diminuer la quantité des archives papiers.
 Mettre en place un system de communication entre les différents acteurs.
 Organiser les produits en différentes catégories.
 Permettre la communication entre les clients et le magasinier
Après avoir étudié et validé la faisabilité du projet, nous avons développé le
logiciel tout en respectant la totalité des critères énoncés ci-dessus.
De plus nous avons fait en sorte que l’utilisation du logiciel soit la plus
ergonomique possible.
En sus de ce qui nous a été demandé dans le cahier des charges, nous
avons décidé d’aller encore plus loin dans l’utilisation du logiciel hébergé en
proposant aux décideurs, l’introduction de l’application sur system android. Nous
avons réussi a lui « vendre » l’idée.
Bien sur l’établissement universitaire peut nous solliciter à tous moment
pour la modification ou l’ajout d’une nouvelle rubrique.

13 | P a g e
Suite à une série de test en compagnie du directeur ainsi que le magasinier nous
avons mis en production l’application.
Cette dernière est à ce jour 100% opérationnelle.
I.3. Organisation du rapport :
Nous allons présenter le plan du rapport qui se subdivisera en cinq
principaux chapitres qui vont nous aider à réaliser l’application et suivre les étapes
nécessaire pour le déroulement du projet.
Dans le premier chapitre intitulé « introduction » nous présentons
l’importance de l’application de gestion de stock dans notre vie quotidienne, les
motivations et les contributions.
Puis, au sein de « Spécification et analyse des besoins », deuxième
chapitre de ce travail, nous commençons à présenter l'organisme d'accueil,
approfondir la compréhension du contexte du système par un processus continu de
collecte d'information auprès des différente applications dans les entreprises
commerciales en premier lieu qui gère les magasins et automatise les taches ,
ensuite déterminer les inconvénients majeurs de la gestion actuelle du stock et les
point faibles des logiciels existantes qu’ on a déjà citer , énumérer des suggestions
informatiques qui peuvent remédier aux difficultés rencontrées, tenant compte des
moyens de la faculté, nous proposons la solution qui paraît la plus adéquate.
Au niveau de troisième chapitre intitulé « Etude conceptuelle », un premier
pas consisterait a Sitter les étapes qu’on doit passer par, pour créer et bien
organiser notre travaille. Nous analysons ensuite les principaux objectifs attendus
du futur système à concevoir et qui seront décrits par le diagramme des cas
d'utilisation. Nous étendons la représentation des diagrammes effectués au niveau
de l'analyse du besoin, les scènes et les scenarios par le diagramme de séquence,
les classes qu’on a besoin dans notre application par le diagramme de classe et le
diagramme état transition pour décrire les changements d'états d'un objet ou d'un
composant, en réponse aux interactions avec d'autres objets/composants ou avec
des acteurs .ce chapitre sera terminer par les maquettes préliminaires .

14 | P a g e
Concernant le quatrième chapitre « Technique de développement» nous
présentons les outils de développement qui nous ont servi pour le développement de
l'application.
Finalement dans le dernier chapitre « Conclusion » nous présentons un
récapitulatif du contexte de ce projet de fin d’étude et ainsi nos contribution suivie
par les perspectives.

Chapitre II :
Spécification et analyse
des besoins

Chapitre II : Spécification et analyse des besoins
16 | P a g e
II.1. Introduction :
a gestion de stocks au sein du magasin de la faculté est une opération
rigoureuse qui mérite d'être perfectionnée et analysée soigneusement. Mais
avant de porter une solution informatique pour ce processus, la
présentation de l'organisme d'accueil en général et le service qui gère les
mouvements de stock au niveau du magasin en particulier est nécessaire, et c'est
ce qui est conseillé d'ailleurs dans toute démarche informatique de Génie Logiciel.
Donc, afin de mieux réaliser les prochaines étapes du plan de travail, la
spécification et la précision de notre sujet doivent être bien comprises, cernées et
clarifiées.
L'étape de l'analyse des besoins est l'une des étapes les plus importantes à
considérer, en effet si les besoins sont mal spécifiés et exprimés, ou mal analysés,
toute la suite sera mal traité, d'où l'importance accordée à cette activité.
Notre objectif dans cette étape est donc d'exprimer les besoins attendus du
futur système à développer.
II.2. Description du projet :
Notre travail consiste à concevoir et à développer une application
informatique qui permettra la gestion automatique des utilisateurs 4 , des
fournisseurs5, du stock, etc.
Autrement dit notre but est de développer une application web de gestion
commercial adaptable aux conditions citées précédemment .En tenant compte des
critiques et des besoins d'informatiser les services la solution est de concevoir et
développer une application permettant de satisfaire le client .
4 Création, Modification et suppression d’un utilisateur et information sur l’utilisateur
5 Est un élément clé dans la chaine d’approvisionnement du chantier
L

17 | P a g e
Fig. 1 : Modélisation graphique du projet
II.2.1. Domaine d’application :
Ce logiciel est conçu pour la gestion de commande et de stock dans un
environnement universitaire.
Il permettra à plusieurs acteurs d’une même structure de gérer leur besoins en
fourniture divers afin d’optimiser le travail de chacun.
II.2.2. Spécification des besoins :
C'est une étape primordiale au début de chaque démarche de développement.
Son but est de veiller à développer une application adéquate, sa finalité est la
description générale des fonctionnalités du système, en répondant à la question :
Quelles sont les fonctions du système?
Notre système doit répondre aux exigences suivantes :
 Le système doit pouvoir récupérer des informations de chaque utilisateur
suivant son login et son mot de passe, pour mettre à jour la base de données de
l'application.
 L'insertion des nouveaux produits et leur classement.
 Modification des informations à propos du client ou du produit.
 La suppression des données (produit ou client)
 Impression : état du stock à la date choisie, détail des mouvements effectués
dans telle période et selon différents critères de sélection, bons de commande,
Avant
Après
Archives
Désordre du
magasin
Perte des
documents
service mal
gérer
17 | P a g e
l'application.
Avant
Après
Perte de
Temps
Désordre du
magasin
une application web
pour l'oraganisation
Ordonnancement du
magasin
automatisation des
taches
service bien gérer
17 | P a g e
l'application.
Avant
Après
une application web
pour l'oraganisation
Gagner le temps
Ordonnancement du
magasin

18 | P a g e
bons de réception, bons de livraison(sur papier vierge ou pré-imprimé),
courriers avec ou sans modèles pour clients et fournisseurs(avec archivage
automatique).
 Permettre au magasinier et au fournisseur de publier des appels d’offres.
 Alarmes facultatives : si la quantité restant en stock est inférieure à la quantité
minimale prévue, si vous tentez de sortir du stock une quantité indisponible.
 Permettre à l’utilisateur de remplir une commande avec plus de sécurité et plus
d’organisation.
Le système, dont le magasin de la faculté veut se doter, doit être
opérationnel, évolutif, convivial et offrant les informations nécessaires à temps réel.
Pour ceci, le système à réaliser doit satisfaire les exigences de la totalité des
utilisateurs.
A part les besoins fondamentaux, notre futur système doit répondre aux
critères suivants:
 La rapidité de traitement: En effet, vu le nombre important des transactions
quotidiennes, il est impérativement nécessaire que la durée d'exécution des
traitements s'approche le plus possible du temps réel.
 La performance: Un logiciel doit être avant tout performant c'est à-dire à travers
ses fonctionnalités, répond à toutes les exigences des utilisateurs d'une manière
optimale.
 La convivialité: le futur logiciel doit être facile à utiliser. En effet, les interfaces
utilisateurs doivent être conviviales c'est-à-dire simples, ergonomiques et
adaptées à l'utilisateur.
 La sécurité : le futur logiciel doit permettre un accès sécurisé aux données
(nous distinguons alors l’administrateur qui a le droit de tout faire et qui limite
les droits d’accès des autre utilisateurs, et les utilisateurs qui utilisent le
system d’une façon limitée)
 L’application doit signaler les erreurs par des messages d’erreur.

19 | P a g e
II.3. Etude de l’existant :
II.3.1. Importance de la gestion automatisée des stocks :
Nous remarquons la présence des logiciels de gestion dans toutes les
entreprises qui vendent ou achètent des produits. En effet, ces logiciels sont
devenus indispensable pour plusieurs raison dont on cite en particulier :
 Faciliter la gestion des stocks.
 Mettre en place des alarmes afin d’éviter la rupture de stock.
 Optimiser le suivi de commande.
 Mutualiser6 une base de données lorsqu’il y a plusieurs utilisateurs
 Organiser les procédures de travail.
 Comparer les mouvements de stock avec le service comptabilité.
 Recenser les pertes et les vols
II.3.2. Exemples de logiciels existants sur le marché :
On trouve plusieurs solutions pour gérer les magasins automatiquement et
d'une manière efficace. Beaucoup des softwares nous aident à atteindre notre but et
d’organiser notre magasin. On cite à titre d’exemple :
 Dja Soft :
Qui est un logiciel de gestion de stocks et commercial à l'intention des auto-
entrepreneurs, petites entreprises ainsi qu'aux petits commerces permettant
d'améliorer leurs gestions commerciales ainsi que de gérer rationnellement et
efficacement les stocks des articles. Par sa simplicité d'utilisation, Dja Soft permet
d'automatiser la gestion de stocks des articles ainsi que l’ensemble d’activités de
l’entreprise. La convivialité de ces écrans de saisies facilite l’utilisation du logiciel et
procure un confort et une sécurité dans sa manipulation, l’organisation et la
manière de présenter les données. En effet, grâce à cela, la situation des stocks des
articles est présentée d’une manière instantanée par des signalisations graphiques
rien qu’en paramétrant les indicateurs de stocks sur la fiche de l’article. Celle-ci,
riche en informations, permet de donner des caractéristiques détaillées des articles.
De plus, avec Dja Soft, la gestion de vos bons de livraison commande, devis,
factures n’en est que simplifiée et ce, grâce à son puissant générateur de
6 La mise en commun des bases de données

20 | P a g e
documents commerciaux. Les deux figures suivantes illustres l’interface de
consultation du produit et une interface d’une facture pour Dja stock.
Fig. 2 : Consultation d’un article (DJA Soft)
Fig. 3 : Une facture pour Dja soft

21 | P a g e
 ICIM STOCK
Qui est un logiciel de gestion des articles, familles, assemblages, pièces
assemblées, codes à barres, images et photos d'articles, emplacements, numéros de
série, références, unités d'achat et de consommation, travaux, clients, appelants,
fournisseurs, modèles de lettres et modèles de courriels pour clients et
fournisseurs. Jusqu'à quatre prix fournisseurs par fiche article, enregistrés
manuellement ou automatiquement lors de la saisie du bon de commande. Quatre
prix de vente par article, chaque prix étant soit fixe, soit un coefficient qui, multiplié
par le prix moyen pondéré du dernier achat, donnera le prix de vente. Récupération
de bons de livraison, bons de commande, assemblages, articles et sorties dans bons
de livraison ou bons de commande. Envoi de courriels avec ou sans pièces jointes, à
l'unité ou en série. Dans les figures suivantes on montre un formulaire à remplir
par le fournisseur et un autre à remplir pour donnée les données d’un article
Fig. 5 : Formulaire à remplir par le fournisseur (ICIM Stock)
Fig. 4 : Formulaire à remplir par le fournisseur (ICIM Stock)

22 | P a g e
II.3.3. Critique de l’existant :
Nous allons citer les problèmes organisationnels, humains et techniques liés
aux logiciels de gestion de stocks généralement ainsi que les problèmes liés au
système d'information.
Dans notre étude de l’existant, prennent comme cas particulier DJA soft et ICIM
stock, nous allons dégager certaine insuffisance à savoir dans le tableau suivant
qui compare notre application avec les autres existants sur le marché.
Notre application de gestion de Stock Les autres applications de gestion de
stock qui figurent au marché
 Interfaces simples et
compréhensibles
 Pas besoin des factures
 La banque n’intervient pas
 Gratuite
 Répond aux besoins de la faculté de
Médecine de Monastir
 Notre interface et notre module sont
complets.
 Interfaces compliqués et non
compréhensibles.
 Tous le travail est basé sur les
factures et les manières de
payement.
 Payante donc cher et pour chaque
mise à jour de l’application
 On les utilise juste pour les grandes
interfaces commerciales comme les
magasins publiques.
 On trouve toujours des modules qui
manquent.
Comparaison entre notre application et les autres sur le marché
II.3.4. Conclusion :
A l'issue de cette étape nous avons pu exprimer clairement les objectifs
attendus du futur système à concevoir car cette étude préalable appelée analyse et
spécification des besoins, constitue une phase capitale dont dépend toute la suite
du projet, elle doit être faite avec beaucoup de rigueur et plus d'attention pour la
réussite de l’application.

23 | P a g e
Dans ce chapitre, on a exposé la description du projet et ces fonctionnalités,
les problèmes du magasin, puis nous avons critiqué l’existant et enfin on a comparé
les logiciels existants et l’application.
Aucun logiciel ne répond à nos besoins qui figurent dans le cahier de charge,
et ne respecte nos critères. C’est pourquoi on a choisi la mise en place d’une
application web de gestion de stock Différente des autres logiciels existant.
Après avoir fixé nos objectifs, pour atteindre notre but on doit suivre
plusieurs étapes ces dernières constituent une partie du cycle de vie de tout projet
informatique. Ainsi dans l'étape suivante on va donner une étude conceptuelle
détaillé.

Chapitre III: Etude
conceptuelle

Chapitre III: Etude conceptuelle
25 | P a g e
III.1. Introduction :
ette partie est consacrée aux étapes fondamentales pour le développement
de notre système de gestion de stock du magasin de la faculté de Médecine
de Monastir. Pour la conception et la réalisation de notre application, nous
avons choisis de modéliser en s’appuyant sur le formalisme UML7 qui offre une
flexibilité marquante et s'exprime par l'utilisation des diagrammes.
III.2. L’approche UML adoptée :
UML se définit comme un langage de modélisation graphique et textuel
destiné à comprendre et à définir des besoins, spécifier et documenter des
systèmes, esquisser des architectures logicielles, concevoir des solutions et
communiquer des points de vue. UML modélise l'ensemble des données et des
traitements en élaborant des différents diagrammes.
En clair, il ne faut pas designer UML en tant que méthode (Il y manque la
démarche) mais plutôt comme une boite d'outils qui sert à améliorer les méthodes
de travail.
Une architecture adapté est la clé de voûte8 de succès d’un developpement,
elle décrit des choix stratégiques qui déterminent en grande partis les qualités du
logiciel (adaptabilité, performance, fiabilité…). Ph.kruchten propose différentes
perspectives, indépendantes et complémentaires, qui permettent de définir un
modèle. Cette vue (‘4+1’) ci-dessous a fortement inspiré UML.
Fig. 4 : Cinq façons de voir un système (4+1 vues de Kruchten)
7 Langage de modélisation modifié, il est apparu dans le cadre de la « Conception Orienté objet »
8 Ouvrage cintré, formé d'éléments appareillés, maçonnés (pierre), voire assemblés (bois), couvrant un espace construit
c
Vue logique Vue implantation
Vue des processus Vue de déploiement
Vue des cas d'utilisation

26 | P a g e
Ce modèle est composé de cinq vues. La vue « logique » décrit les aspects
statiques et dynamiques d’un système en termes de classes, d’objets, de connexions
et de communications. Elle se concentre sur l’abstraction et l’encapsulation. La vue
« des processus » capte les aspects de concurrence et de synchronisation, et les
décompose en flux d’exécution (processus, fil d’exécution, etc.). Elle se rapporte aux
objets actifs et aux interactions. La vue « développement » représente l’organisation
statique des modules (exécutable, codes source, paquetages, etc.) dans
l’environnement de développement. La vue « implémentation » décrit les différentes
ressources matérielles et l’implantation logicielle tenant compte de ces ressources.
Fig. 5 : Les trois composantes d’une modélisation
Pour garantir que l’application ou le système logiciel satisfait les besoins des
utilisateurs on peut décrire des modèles utilisés tout au long de la conception. Ces
modèles aident à comprendre l'architecture existante, discuter les modifications et
communiquer clairement les intentions. Dans notre cas, le modèle le plus adopter
avec notre étude, c’est le model fonctionnel qui se base sur les cas d’utilisation pour
cela parmi les cinq vue d’UML nous allons suivre la vue des cas d’utilisation car elle
se concentre sur la cohérence en présentant des scénarios d’utilisation qui mettent
en œuvre les éléments des quatre premières vues. Les scénarios sont une
abstraction des exigences fonctionnelles de l’application. Cette dernière vue valide
en quelque sorte les autres vues et assure la cohérence globale. C’est aussi cette
dernière vue qui est construite en premier, juste après l’établissement du cahier des
Modèle fonctionnel
Que fait le système
Séquencement des actions
Dans le système Modèle structurel (objet)
Sur quoi le système agit
Modèle temporel
Aspect dynamique :
diagrammes d'interaction séquences,
collaboration),
d'états-transitions et d'activité
Aspect statique :
diagramme de classes et d'objets
Aspect fonctionnel :
diagrammes des cas d'utilisation

27 | P a g e
charges, pour fixer les contours du système à réaliser avec ses fonctionnalités
appelées dans la terminologie UML des cas d’utilisation.
III.3. Étude et modalisation de la solution :
III.3.1. Les diagrammes des cas d’utilisations :
Ce diagramme est destiné à représenter les besoins des utilisateurs par
rapport au système. Il constitue un des diagrammes les plus structurants dans
l'analyse d'un système.
Nous rappelons que :
 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é.
 Cas d'utilisation (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. On trouve plusieurs relations pour
lier entre les cas d’utilisation, citons :
 Relation d'inclusion : 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.
 Relation d'extension : Une relation d'extension d'un cas
d'utilisation A par un cas d'utilisation A signifie qu'une instance
de A peut être étendue par le comportement décrit dans B.
 Relation de généralisation : Les cas d'utilisation descendants
héritent de la description de leurs parents communs. Chacun
d'entre eux peut néanmoins comprendre des interactions
spécifiques supplémentaires.
Les 3 principaux acteurs de notre application sont :
Le magasinier c’est un administrateur. Il a le droit de tout faire et il limite les droits
d’accès des autres utilisateurs, les clients et les fournisseurs sont des utilisateurs
qui utilisent le system d’une façon limitée).

28 | P a g e
III.3.1.1. Diagramme de cas d’utilisation « Magasinier » :
La figure n°6 présente le diagramme de cas d’utilisation du magasinier qui
est l’administrateur dans notre application. Dans le figure ci-dessous on explique
en détaille le cas d’utilisation de consultation de stock.
Fig. 6 : diagramme de cas d’utilisation « Magasinier »

29 | P a g e
Fig. 7 : Description détaillé du cas d’utilisation « consulter le stock »
Cette figure peut etre expliqué d’avantage dans la figure 8, ou on détaille plus
les étapes qu’un magasinier passe par pour consulter son stock.
scénario d’un cas d’utilisation
1. Le système lui affiche un menu avec un choix d’opération.
2. Le magasinier choisi l’opération espace administrateur.
3. Le système lui demande de s’authentifier.
4. Le magasinier donne son prédéfini login et mot de passe.
5. Le système lui affiche un menu.
6. Le magasinier choisie consulter le stock
7. Le system lui affiche la liste des produits présents dans le stock ordonné
alphabétiquement.
Fig. 8 : Description plus détaillé du cas d’utilisation « consulter le stock »
scénario d’un cas d’utilisation
Consulter le stock Cas normal Description détaillé
Variante
1
En (4) le magasinier n'est pas reconnu, dans ce cas, tant
qu'il n'est pas reconnu, on lui redemande de
s'authentifier
Variante
2
En (7) le système affiche le stock, si la quantité d’un
produit a atteint 20% de stock une alarme sera
déclencher pour informer le magasinier.
Consulter le stock Description détaillé
Pré-condition : Le magasinier doit etre authentifié
La base de données doit etre saisie par le magasinier
Post-condition : si un client à commander des produits.
Le nombre de produit du stock est décrémenté de nombre de
produit pris par l’utilisateur.

30 | P a g e
Dans le reste on explique brièvement les autres cas d’utilisation :
 Authentifier : Permet à un acteur de s'authentifier avant d'accéder à
l'application.
 Etablir un bon de commande interne: Donne la possibilité aux services
demandeurs d'exprimer leurs besoins envers le magasinier.
 Gérer les bons de sorties: Permet au magasinier d'effectuer des opérations sur
les bons de sorties. Ces opérations concernent : la modification et la
suppression.
 Gérer les bons d'entrées : Permet au magasinier d'effectuer des opérations sur
les bons d'entrées. Ces opérations concernent : l'ajout.
 Mise à jour de la base de données : Permet au magasinier de mettre à jour sa
base de données. Cette mise à jour concerne : les fournisseurs, les services, les
produits, les clients et les familles.
 Lancer des appels d’offre : Permet au magasinier de mettre plusieurs
fournisseurs en concurrence pour fournir un produit ou un service, et le choix
du meilleur produit se fait selon trois critères : la qualité, le prix et la date de
livraison.
 Gérer les commandes : Permet au magasinier de traiter les commandes des
clients pour satisfaire leurs besoins.
 Contrôler le travaille de magasinier : Seul le directeur générale est responsable
du contrôle, c’est un super administrateur qui gère le magasin à distance.
 Imprimer les commandes : Permet au magasinier d’imprimer les commandes
des clients en cas d’un conflit.

31 | P a g e
III.3.1.2. Diagramme de cas d’utilisation «client» :
Dans la figure 9 on présente le diagramme de cas d’utilisation du client.
Précisons le cas d’utilisation « commander » pour une description détaillé dans la
figure 10.
Fig. 10 : Description détaillé du cas d’utilisation « consulter le stock »
Fig. 9 : Diagramme de cas d’utilisation « client »
Scénario d’un cas d’utilisation
Commander Description détaillé
Pré-condition : le client doit etre inscrit au magasin de la faculté
Post-condition : si l’opération s’est bien déroulée
Une mise à jour automatique ce fait dans la base de données.

32 | P a g e
La figure ci-dessus peut etre expliqué d’avantage dans la figure 11.
Fig. 11 : Description plus détaillé du cas d’utilisation « consulter le stock »
Comme étant un utilisateur de l’application le client intervient par plusieurs cas
d’utilisation qu’on explique brièvement :
 S’inscrire: chaque utilisateur doit faire l’inscription pour qu’il puisse bénéficier
des services de l’application.
 Consulter son profil : chaque utilisateur a un profil qu’il consulter pour
surveiller ses archives de commandes.
9 Numéro de la carte nationale d'identité
1. Le système affiche un message d’accueil sur le terminal avec un choix
d'opérations.
2. Le client choisit l’espace client parmi les différentes opérations.
4. Le client donne son identification (login, mot de passe).
5. Le system affiche un menu de choix.
6. Le client choisi « commander ».
7. Le system demande le NCIN 9 du client, le nom d’article souhaité, la
quantité et la date de besoin.
8. Le client rempli ce formulaire et envoi la commande.
Commander Cas normal Description détaillé
Variante1 En (8) le client doit connaitre les produits présents
Variante
2
En (4) le client n'est pas reconnu, dans ce cas, tant
qu'il n'est pas
reconnu, on lui redemande de s'authentifier
Variante
3
En (8), le client peut envoyer plusieurs commandes
successives

33 | P a g e
 Consulter le stock : chaque utilisateur peut consulter le stock et voir le
nombre de produit présents pour sa commande.
 Contacter le magasinier : Permet aux clients d’envoyer un email au magasinier
en cas de disfonctionnement des matériels ou un défaut dans les produits.
III.3.1.3. Diagramme de cas d’utilisation « Fournisseur » :
Fig. 12 : Diagramme de cas d’utilisation « Fournisseur»
Dans la figure 12 on présente le diagramme de cas d’utilisation du
fournisseur. Précisons le cas d’utilisation « Répondre aux appels d’offre » pour une
description détaillé dans la figure 13.
Fig. 13 : Description détaillé du « Répondre aux appels d’offre »
Répondre aux appels d’offres Description détaillé
Pré-condition : le fournisseur doit etre inscrit dans l’application
Le fournisseur doit connaitre tous les produits du magasin

34 | P a g e
La figure précédente peut etre expliqué d’avantage dans la figure suivante.
1. Le système affiche un message d’accueil sur le terminal avec un choix
d'opérations.
2. Le fournisseur doit choisir « espace fournisseur ».
4. Le fournisseur saisie ces données (login, mot de passe).
5. Le système affiche un menu.
6. Le fournisseur choisi « appels d’offres ».
7. Le system lui précise l’interface qu’il doit l’utiliser.
Fig. 14 : Description plus détaillé du cas d’utilisation «Répondre aux appels d’offre»
Dans le reste on explique brièvement les autre cas d’utilisation du fournisseur :
 S’inscrire : l’inscription est la tache la plus importante pour profiter de
l’application.
 Postuler des appels d’offres : permet au fournisseur de postuler des produits
pour informer le magasinier en cas des nouveautés.
 Contacter le magasinier : le fournisseur contact le magasinier en lui envoyant
en email.
 Consulter le stock : Permet au fournisseur de voir les produits disponibles pour
publier si il ya des nouveautés. Ce dernier n’a pas le droit de voir que les noms
des produits pas leurs type, quantité, prix ou la désignation.
Répondre aux appels d’offres Description détaillé
Cas normal
Variante
1
En (3), le fournisseur n'est pas reconnu, dans ce
cas, tant qu'il n'est pas reconnu, on lui
redemande de s'authentifier
Variante
2
En (6), le fournisseur peut envoyer un e-mail au
magasinier pour la communication et le choix des
appels d’offres.

35 | P a g e
III.3.2. Les diagrammes de séquences :
Un diagramme de séquence permet de décrire les scénarios de chaque cas
d'utilisation en mettant l'accent sur la chronologie des opérations en interaction
avec les objets. Il montre une interaction présentée en séquence dans le temps. En
particulier, il montre aussi les objets qui participent à l'interaction par leur "Ligne
de vie" et les messages qu'ils échangent présentés en séquence dans le temps.
Rappelons quelques notions de base du diagramme :
 Scénario: une liste d'actions qui décrivent une interaction entre un acteur et
le système.
 Interaction: un comportement qui comprend un ensemble de messages
échangés par un ensemble d'objets dans un certain contexte pour accomplir
une certaine tâche.
 Message: Un message représente une communication unidirectionnelle entre
objets qui transporte de l'information avec l'intention de déclencher une
réaction chez le récepteur.
III.3.2.1. Diagramme de séquence « Saisir et m-a-j de la base de donnée » :
Fig. 15 : Diagramme de séquence « Saisir et mise à jour de la base de donnée »

36 | P a g e
Le diagramme représenté dans la figure 15 décrit les scénarios possibles lors
de la saisie de la base de données aussi lors d’une mise à jour.
En effet, l’administrateur doit entrer les produits présents dans le magasin et
préciser les coordonnées des articles dans la base de données pour le
fonctionnement de l’application.
Et en cas de changement des données, le magasinier met à jour la base de
données il peut ajouter, supprimer ou modifier des produits aussi supprimer ou
modifier les coordonnées d’un client.
III.3.2.2. Diagramme de séquence « Inscription Client » :
d'une inscription d'utilisateur.
En effet, lorsque L'utilisateur demande l'accès à l’application Le système lui affiche
une interface qui contient des champs vides. Il remplit ces champs et envoie les
données pour que Le système puisse vérifier la validité des champs, Une série de
Fig. 16 : Diagramme de séquence de scénario « authentification Client »

37 | P a g e
tests doit être réalisée (login existe, tester email, tester mot de passe, tester
matricule pour les enseignants). Si tous les champs sont corrects, alors le système
prend en charge les informations introduites et les enregistrent dans la base de
données et permet à l'internaute d'accéder à l’application.
Et Si l'inscription n'est pas valide, l'utilisateur doit soit réinscrit soit quitter
l’application.
III.3.2.3. Diagramme de séquence « authentification Client » :
Fig. 17 : Diagramme de séquence « Authentification »
Le diagramme de la figure 17 décrit les scénarios possibles lors de
l'identification d'utilisateur (enseignant ou administrateur), en effet, L’utilisateur
demande l'accès au site et donne le login et le mot de passe. Un test doit être
réalisé (existence et compatibilité du login/mot de passe), si les données sont
correctes alors permette à l'internaute d'accéder à la totalité du site sinon
l'utilisateur doit soit réessayer soit quitter l’application.

38 | P a g e
III.3.2.3. Diagramme de séquence scénario « Commander » :
de l’envoi d’une commande d'utilisateur au magasinier.
Le client remplit les champs du formulaire et envoie les données pour que Le
système avec la base de données puissent vérifier la validité des champs, Une série
de tests doit être réalisée (login existe, tester mot de passe, produit existe, quantités
suffisante). Si tous les champs sont corrects, alors le système prend en charge les
informations introduites et valide la commande du client.
Et Si les données introduites ne sont pas valides, le client doit soit remplir de
nouveau le formulaire.
Fig. 18 : Digramme de séquence du scénario « commander »

39 | P a g e
III.3.2.4. Diagramme de séquence du scénario « Répondre aux appels d’offres » :
de la publication d’un appel d’offre du magasinier vers le fournisseur et vise vers
ca. Le magasinier lance un appel d’offre dans un forum spécifique pour que Le
fournisseur puisse répondre s’il est intéressé.
III.3.2.5. Diagramme de séquence de scénario « Communication » :
Fig. 19 : Diagramme de séquence du scénario « Répondre aux appels d’offres »
Fig. 20 : Diagramme de séquence de scénario « Communication »

40 | P a g e
Le diagramme ci-dessus présente les différentes étapes pour la
communication entre les membres de l’application et le magasinier. En effet, les
clients ou les fournisseurs peuvent écrire des commentaires dans un espace de
conversations et le magasinier répond si nécessaire.
III.3.4. Diagramme de classes :
Fig. 21 : Diagramme de classe
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 orienté.

41 | P a g e
 Une classe : Représente la description abstraite d'un ensemble d'objets
possédants mêmes caractéristiques. On peut parler également de type.
 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.
 Un attribut : Représente un type d'information contenu dans une classe.
 Une association: Représente une relation sémantique durable entre deux
classes.
 Une superclasse : 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 superclasse et peuvent
comporter des propriétés spécifiques supplémentaires.
Le diagramme de la figure 21 présente les classes de notre application :
 Commande est la classe principale de l'application. Elle facilite les interactions
entre les autres classes. Elle permet de réaliser des commandes par coopération
avec les classes client et article.
 Appel offre C'est la classe qui effectue les opérations d'appels d'offres relatives
aux besoins du magasin, Elle intègre la classe Produit appel offre pour décrire
le produit en question et la classe fournisseur pour préciser le fournisseur qui a
servi le magasin.
 class article représente l'enregistrement dans laquelle on stock les données
relatives aux articles du magasin.
 class forum c'est la classe qui déclenche une sorte de communication entre les
utilisateurs et le magasinier pour échanger des informations ou exprimer des
avis.
III.3.3. Diagramme d’état transition :
Etat : Commander :

42 | P a g e
Sous état : Vérification :
Etat : Répondre aux commandes

43 | P a g e
Etat : authentification
Fig. 22 : diagrammes d’état transitions
Ce diagramme sert à représenter des automates d'états finis, sous forme de
graphe d'états, reliés par des arcs orientés qui décrivent les transitions. Les
diagrammes d'états-transitions permettent de décrire les changements d'états d'un
objet ou d'un composant, en réponse aux interactions avec d'autres
objets/composants ou avec des acteurs.
Un état se caractérise par sa durée et sa stabilité, il représente une
conjonction instantanée des valeurs des attributs d'un objet. Une transition
représente le passage instantané d'un état vers un autre. Une transition est
déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement
qui conditionne la transition. Les transitions peuvent aussi être automatiques,
lorsqu'on ne spécifie pas l'événement qui la déclenche.
En plus de spécifier un événement précis, il est aussi possible de
conditionner une transition, à l'aide de "gardes" : il s'agit d'expressions booléennes,
exprimées en langage naturel (et encadrées de crochets).

44 | P a g e
III.4. Présentation des maquettes préliminaires :
Fig. 23 : Interface Inscription
L’identifiant unique de la personne qui
souhaite s’inscrire a notre application, il
ne doit pas contenir une lettre ou un
symbole et doit avoir une longueur de 8
caractères. Sinon un message d’erreur
s’affiche.
On a 3 types de personnes qui peuvent
accéder a notre application qui sont :
les enseignant, les chercheurs, les
personnels de l’administration.
Un numéro de téléphone doit être
composé que des chiffre pas des
lettres ni des symboles
Un email doit être sous la forme :
Chaine@chaine.chaine
Pour
contacter
les clients
en cas des
besoins.
Le
numéro
de
téléphone
et l’email
sont
obligatoire
s.
Chaque utilisateur possède
un login et mot de passe
pour accéder a l’application
Envoyer la
commande. Effacer et remplir
le formulaire de
nouveau en cas
d’erreur.
Un message
d’erreur
apparait lorsque
les contraintes
de saisie ne
seront pas
respecter

45 | P a g e
Fig. 24 : Interface authentification
Fig. 25 : Interface du formulaire d’une commande
Chaque
utilisateur
possède un
login qui lui
permet
d’accéder à
l’application.
Se diriger
vers le forum
de
l’inscription
en cas d’un
utilisateur
non inscrit.
Pour la
connexion
automatique
Envoyer un
email pour
rappeler le
client
Envoyer la
commande
Effacer et remplir
le formulaire de
nouveau en cas
d’erreur.
L’identifiant de l’utilisateur, il
est obligatoire.
3 type de produit :
titre1, titre2 et Pack
Chaque produit a un
code (ID) spécifique et
unique.
Chaque utilisateur doit
donner la date de besoin du
produit pour se précipiter
en cas de rupture de stock.
Un message
d’erreur
apparait en
cas d’erreur

46 | P a g e
III.5. Conclusion :
La phase conceptuelle est une étape fondamentale pour la réalisation de
n’importe quel projet .Elle permet de faciliter le système d’information et réaliser
l’implémentation de la base de donnée et le traitement .Par la suite, on doit
chercher les moyens et les outils possibles pour développer cet application, ce qu’on
va présenter dans le chapitre suivant.

Chapitre IV : Technique
de développement

Chapitre IV : Techniques de développement
48 | P a g e
IV.1. Introduction :
près avoir achevé l'étape de conception de l'application, on va entamer
dans ce chapitre la partie réalisation qui constitue le dernier volet de ce
rapport et qui a pour objectif d'exposer le travail réalisé. Pour ce faire, on
va commencer tout d'abord par préciser l'environnement matériel et logiciel de ce
travail.
IV.2. Description de l’environnement de développement intégré :
Dans ce paragraphe, nous présentons notre environnement matériel et nos
choix de logiciels.
IV.2.1. Environnement matériel :
Pour la réalisation de ce projet on a disposé de :
 Un ordinateur de type DELL équipé d’un microprocessus Intel(R)
Core(TM) 2 Duo CPU T6600 @2.20 GHz, possédant 3,49 Go de RAM, système
d’exploitation Windows XP service pack 3.
 Un ordinateur de type ACER équipe d’un microprocessus Intel(R)
Core(TM) 2 Duo CPU T6570 @2.10 GHz, possédant 3,00 Go de RAM, Système
d’exploitation Windows 7.
 Un scanner.
A

49 | P a g e
IV.2.2. Environnement Logiciel :
IV.2.2.1. WampServer :
WampServer (anciennement WAMP5) est une plateforme de développement
Web de type WAMP, permettant de faire fonctionner localement (sans se connecter à
un serveur externe) des scripts PHP.
WampServer n'est pas en soi un logiciel, mais un environnement comprenant
deux serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi qu'une
administration pour les deux bases SQL PhpMyAdmin et SQLiteManager.
Il dispose d'une interface d'administration permettant de gérer et
d'administrer ses serveurs au travers d'un tray-icon (icône près de l'horloge de
Windows).
La grande nouveauté de WampServer 2 réside dans la possibilité d'y installer
et d'utiliser n'importe quelle version de PHP, Apache ou MySQL en un clic. Ainsi,
chaque développeur peut reproduire fidèlement son serveur de production sur sa
machine locale.
IV.2.2.2. PHP :
PHP est un langage de scripts libre principalement utilisé pour produire des
pages Web dynamiques via un serveur HTTP, mais pouvant également fonctionner
comme n'importe quel langage interprété de façon locale, en exécutant les
programmes en ligne de commande. PHP est un langage impératif disposant depuis
la version 5 de fonctionnalités de modèle objet complètes. En raison de la richesse
de sa bibliothèque, on désigne parfois PHP comme une plate-forme plus qu'un
simple langage.

50 | P a g e
IV.2.2.3. CSS :
Cascading Style Sheet : Le principe de base est le suivant: il faut séparer le
contenu de la page, de son apparence. La page html contient l'information, et non la
façon dont l'information est affichée. Pour un unique contenu : plusieurs affichages
sont possibles. On peut penser à des affichages monochromes, sur de petits écrans,
oral (le contenu de la page web est lu), une impression papier, impression sur des
transparents, impression en braille…
IV.2.2.4. Java Script :
JavaScript est un langage de programmation de scripts principalement
utilisé dans les pages web interactives. C'est un langage orienté objets à prototype,
c'est-à-dire que les bases du langage et ses principales interfaces sont fournies par
des objets qui ne sont pas des instances de classes, mais qui sont chacun équipés
de constructeurs permettant de générer leurs propriétés, et notamment une
propriété de prototypage qui permet d'en générer des objets héritiers personnalisés.
Ce Langage de programmation est développé par Sun, inspiré de C++.
Fonctionnant sur le principe machine virtuelle, il peut s'adapter à n'importe quel
ordinateur. Les programmes Java peuvent être appelés depuis des documents
HTML ou de manière autonome. Lorsqu'ils s'exécutent à partir d'une page Web, on
les appelle des applets Java. Lorsqu'ils s'exécutent sur un serveur Web, on les
dénomme Servet.
50 | P a g e
IV.2.2.3. CSS :
dénomme Servet.
50 | P a g e
IV.2.2.3. CSS :
dénomme Servet.

51 | P a g e
IV.2.2.5. Photoshop :
Photoshop est un logiciel de retouche, de traitement et de dessin assisté par
ordinateur édité par Adobe. Il est principalement utilisé pour les traitements de
photographies numériques.
Photoshop travaille sur les images matricielles (également appelées "bitmap",
à ne pas confondre avec le format d'enregistrement Windows bitmap) car les images
sont constituées d'une grille de points appelés pixels. L'intérêt de ces images est de
reproduire des graduations.
Photoshop possède son propre format de projet (PSD), qui est plus qu'un
simple format de fichier. Le programme accepte également d'importer et d'exporter
des fichiers d'image dans les formats les plus courants (GIF, JPEG, TIFF, PNG,
ILBM, etc.).
Il offre :
 Un système de tri et d'organisation des fichiers permettant l'application d'une
opération sur plusieurs fichiers simultanément ;
 Des outils de dessin en mode bitmap : pinceau, crayon, formes géométriques ;
 Des outils de sélection de zones de travail (ou zones d'intérêt) : lasso, rectangle
de sélection, sélection par plage de couleur;
 Des outils de copie, collage et duplication de zones de travail;
 Des outils de manipulation de calques : par l'empilement de zones graphiques
et l'utilisation de transparence et autres effets, on peut construire l'équivalent
de photomontages complexes;
 Des outils de manipulation de la palette de couleurs : changement de palette,
réglages colorimétriques, de luminosité, de contraste, de saturation;
 Des filtres pour appliquer divers effets à des zones d'intérêt : texturent, ombres,
renforcement des contours, estampage, flou, etc.
51 | P a g e
ILBM, etc.).
Il offre :
51 | P a g e
ILBM, etc.).
Il offre :

52 | P a g e
IV.3. Les phases de développement :
Afin d'être en mesure d'avoir une méthodologie commune entre le client et la
société de service réalisant le développement, des modèles de cycle de vie ont été
mis au point définissant les étapes du développement ainsi que les documents à
produire permettant de valider chacune des étapes avant de passer à la suivante.
Pour notre projet on a adopté le modèle de cycle de vie en cascade, présenté
dans la figure 26 ci-dessous, qui a été mis au point dès 1966, puis formalisé aux
alentours de 1970. Il définit des phases séquentielles à l'issue de chacune
desquelles des documents sont produits pour en vérifier la conformité avant de
passer à la suivante.
Fig. 26 : Le modèle de cycle de vie en cascade
52 | P a g e
52 | P a g e

53 | P a g e
IV.4. Les scénarios de développement :
La formulation des scénarios de développement par l’exploration des visions
futures est une approche qui est très bien adaptée au contexte et à la
problématique de l’étude. C’est un processus créatif qui permet d’identifier d’une
façon participative et intégrée les tendances des systèmes de production.
 Le scénario1 : « Mise à jour de la base : saisie, modification et suppression»
Cette étape est préliminaire et obligatoire pour le démarrage de l’application.
Le magasinier remplit les différents tableaux de la base pour un lancement
primaire de la gestion de stock, utilisateurs, et droits d’accès
On peut modifier notre stock lors d’une entrée d’un nouveau produit en l’ajoutant à
la base. Lorsqu’un produit est inutile on le supprime.
Aussi lors de l’inscription d’un nouveau client on vérifie ces coordonnées et on peut
le supprimer de notre base de données s’il n’appartient pas à l’association.
 Le scénario2 : « Inscription »
L’inscription est indépendante et très importante pour « la gestion des droits
d’accès ». Il faut attribuer à chaque utilisateur un mot de passe et un pseudo qui
sera stocké dans la base de données pour bien gérer les accès.
 Le scénario3 : « Authentification »
L’authentification est la clé pour accéder aux différentes fonctionnalités de
l’application.
 Le scénario4: « Consultation »
Plusieurs utilisateurs peuvent consulter notre application, mais non pas avec
le même degré d’intervention (super utilisateur, utilisateur normale) .en réalité, un
Utilisateur normale celui qui peut consulter son profil personnel, et les produits
disponibles, il peut aussi communiquer avec les membres inscrit et avec le
magasinier. Ce dernier peut demander la maintenance en cas de problème dans les
matériels. Ainsi que le Super utilisateur (magasinier, directeur générale) : peut
consulter tous les profils de tous les utilisateurs, possède l’accès à la base, et
contrôles tous les autres utilisateurs (supprimer, bloquer, servir..), répondre aux
questions des membres, gérer les commandes, enfin, il peut les imprimer.

54 | P a g e
 Le scénario 5 : «Commander»
C’est La plus importante action dans notre application, le client rempli la
commande et l’envoi au magasinier qui la gère.
 Le scénario 6 : « Répondre aux appels d’offre»
Ce scénario présente la manière de communication entre les fournisseurs et
le magasinier pour réaliser la tache d’appel d’offre qui est une fonctionnalité
primordiale pour servir le client positivement après une commande et aussi pour
prévenir la rupture de stock.
Cette communication se manifeste grâce aux mails électroniques.
 Le scénario 7 : « Forum »
Ce forum permet aux utilisateurs de l’application de communiquer avec le
magasinier, à partir des commentaires et des questions que peut poster les clients.
IV.4.1. Évaluation des scénarios :
Fig. 27 : Schéma d’évaluation des scenarios
Citons les critères d’évaluation de ces scénarios :
 Faisabilité : L'analyse de faisabilité est un outil permettant au propriétaire
d'une entreprise d'évaluer un changement proposé. Il peut s'agir d'élaborer
0
1
2
3
4
5
6
7
Faisabilité spécificité Efficacité Rendement Evolutivité
Sénario1
Sérnario2
Sénario3
Sénario4
Sénario5
Sénario6
Sénario7

55 | P a g e
un nouveau produit, d'améliorer un produit existant, de modifier une
stratégie de commercialisation.
 Spécificité : Le scénario doit répondre aux besoins spécifiques de tous les
propriétaires qui cherchent la sécurité.
 Efficacité : c’est la capacité d'arriver aux buts, produire les résultats
escomptés et réaliser les objectifs fixés. Dans l’enjeu de s’assurer que la
solution retenue correspond aux objectifs de l’application.
 Rendement : Le scénario doit réaliser l’objectif de l’application avec le
minimum de moyens engagés possibles.
 Evolutivité : Choisir une solution ouverte qui peut être modifié.
Le graphique de la figure 27 permet de visualiser le scénario qui possèdes le
profil le plus cohérant. Le premier scénario est celui le plus important parce qu’il
vérifie toutes les critères d’évaluation.
En se basant sur la conception élaborée dans le chapitre précédent, on a
développé une application permettant de gérer les stocks du magasin de FMM d’une
façon simple, efficace, rapide et sécurisée.
La gestion de stocks ce subdivise en différents rubriques tel que les
commandes, les appels d’offres, l’alerte, la mise à jour, les mouvements d’entrée
sortie et d’autre fonctionnalités qui définissent notre application.
La base de données nous a aidée à réaliser les divers fonctionnalités qui ont
répondus a notre cahier de charge et encore plus.
Ainsi, dans ce chapitre, nous allons motionner des bout de code les plus
important qui sont considérer préliminaire pour le fonctionnement de l’application.
Enfin, nous allons montrer à l’aide des imprimes écran les résultats obtenus.
IV.5.1.Réalisation de la rubrique de Commande :
Pour passer une commande on procède comme suit :
 On récupère les données saisies par l’utilisateur
 les données seront stockées dans la base de données.
 On répète ces deux étapes chaque fois qu’on a besoin d’articles.

56 | P a g e
 On peut consulter notre commande, en saisissant la date dans la quelle on a
commandé.
<?php
if(isset($_GET['envoyer']))
{if($_GET['article'] == NULL OR $_GET['qte1'] == NULL OR $_GET['SelectedDate'] == NULL OR
$_GET['ncin'] == NULL)
{echo '<script type="text/javascript">alert("champs doivent être remplis!")</script>';}
$sql="SELECT Qte_A FROM articles WHERE Des_A= '".$_GET["article"]."'";
$res = mysql_query($sql);
$ligne=mysql_fetch_array($res);
$qte_dispo=$ligne['Qte_A'];
$qte1=$_GET['qte1'];
if($qte1 > $qte_dispo)
{echo '<script type="text/javascript">alert("qte indisponible")</script>';}
else{
$qte=$qte_dispo-$qte1;
$sql1 = "UPDATE articles SET Qte_A='".$qte."' WHERE Des_A= '".$_GET["article"]."'";
$req = mysql_query($sql1)or die ('Erreur : '.mysql_error() );
$sql="SELECT nom,prenom FROM client WHERE ncin = '".$_GET['ncin']."' ";
$result = mysql_query($sql,$base) or die ('Erreur : '.mysql_error() );
$total = mysql_num_rows($result);
$row = mysql_fetch_array($result);
$sql='INSERT INTO commande VALUES("","'.$_GET['ncin'].'","'.$row["nom"].'","'.$row["prenom"].'",
"'.$_GET['article'].'","'.$_GET['qte1'].'","'.$_GET['SelectedDate'].'",now())';
$sql = mysql_query($sql);
echo' <script type="text/javascript">alert ("votre commande a été traité avec succès")</script>';}}
?>
Contrôle des données
saisies
Insertion dans la base
Mise a jour
de la base

57 | P a g e
<?php
if(isset($_GET['afficher']))
{ $error=false
if($_GET['ncin'] == NULL OR $_GET["date"] == NULL){
echo "<script>alert('Tout les champs doivent être remplis!');</script>";
$ncin=$_GET['ncin'];
$stmt = "Select * from client where ncin='".$ncin."'";
$result = mysql_query($stmt,$base);
if (mysql_num_rows($result) == 0) {
echo "<script>alert('Ncin incorrecte!');</script>";
$error=true; }}
else{
$date=$_GET['date'];
$select="select * from commande where datecomm='".$date."' && ncin='".$_GET['ncin']."' ";
$result = mysql_query($select,$base) or die ('Erreur : '.mysql_error() );
$row = mysql_fetch_array($result) ;
echo<table><tr><td><font color="#0097C5">
Le Client :
</td><td> <strong><u><font color="#0097C5">".$row['nom']." ".$row["prenom"]."</td>
<tr><td><font color="#0097C5">
A Commander le :
</td><td><font color="#0097C5"><strong><u>".$row['datecomm']."</u></strong></td><td>
<font color="#0097C5"> la commande suivante :</td></tr>";
if($total) {
?><table border="3"style="background-color:white";>
<tr>
<td><strong>Article</td><td><strong>Qte</td><td><strong>Date besoins</td></tr>
<?php
while($row = mysql_fetch_array($result)) {
echo" <tr><td>".$row["article"]."</td><td>".$row["qte"]."</td><td>".$row["date"]."</td></tr>";
}} }
Requête de sélection de la
commande à consulter
L’affichage de
la commande

58 | P a g e
IV.5.2.Réalisation de la rubrique d’appel d’offre :
On a deux parties dans le scénario d’appels d’offre :
 L’administrateur qui lance un appel d’offre, consulte les réponses sur
des appels anciens et les nouveautés des fournisseurs.
 Les fournisseurs qui peuvent soit rependre a un appel d’offre ou lancer
des nouveautés.
La partie du code ci-dessus présente la création du formulaire de la
réalisation d’un appel d’offre.
<div id="templatemo_right_content">
<div id="templatemo_content_area">
<div class="templatemo_title">Réaliser un appel d'offre</div>
<form action="apelphp.php" method="Get" >
<table>
<tr><td><label ><strong><font
color="#0097C5">Produit:</font></strong></label></td></tr>
<tr><td><input type="text" name="nom"></td></tr>
<tr><td><label ><strong><font color="#0097C5">Qte:</font></strong></label></td></tr>
<tr><td><input type="text" name="qte"></td></tr>
<tr><td><label ><strong><font
color="#0097C5">description:</font></strong></label></td></tr>
<tr><td><textarea name="desc"cols="37" rows="3"></textarea></td></tr>
</table>
<div id="templatemo_login">
<input type="submit" name="valider" value="Postuler" class="button"/>
<input type="submit" name="valider1" value="voir les reps" class="button"/>
<input type="submit" name="valider2" value="voir les new" class="button"/>
</div></div></div></div>
<?php
if(isset($_GET['valider']))
{$sql='INSERT INTO appel
VALUES("'.$_GET['nom'].'","'.$_GET['qte'].'","'.$_GET['desc'].'")';
echo'<script>alert("votre appel a été postuler")</script>';}
if(isset($_GET['valider1']))
{?>
<div class="templatemo_title">les répenses appels d'offres :</div>
<?php
$select = 'SELECT nom,qte,prix,date FROM repappel';
if($total) {
echo '<div style="background-color:white;"><fieldset>';
echo ' le fourniseur :<u><font
color="#0097C5"><strong>'.$row["nom"].'</strong></font></u>';
Création
d’un
nouvel
appel
d’offre
Affichage
des
réponses

59 | P a g e
echo ' peut nous servir avec <font color="#0097C5"><u> '.$row["qte"].'
</u></font>';
echo '<br> piéces dont le prix sera egal a
<font color="#0097C5"><u>'.$row["prix"].'</font></u>';
echo ' a un delais qui ne deppassera pas
<font color="#0097C5"><u>'.$row["date"].'</u></font></fieldset>';
}}else echo "<script>alert('Pas d'enregistrements dans cette table...');</script>";
mysql_free_result($result);
?>
<?php
}
if(isset($_GET['valider2']))
{
?>
<div class="templatemo_title">les nouveaux appels d'offres :</div>
<?php
$select="select * from new";
if($total) {
echo'<fieldset>';
echo '<div style="background-color:white;">';
echo ' Fournisseur :<u><font
color="#0097C5"><strong>'.$row["name"].'</strong></font></u>';
echo ' Produit :<u><font
color="#0097C5"><strong>'.$row["produit"].'</strong></font></u>';
echo ' Prix :<font color="#0097C5"><u> '.$row["prix"].' </u></font>';
echo ' qualité: <font
color="#0097C5"><u>'.$row["qualite"].'</font></u>';}}}
?>
Affichage des
réponses
Affichages des
nouveaux
appels d’offres

60 | P a g e
IV.5.3.Réalisation de la rubrique d’édition :
L’édition est un travail administratif dont l’administrateur de l’application
édite (les fournisseurs, les produits et les clients), il les gérer (modifier, ajouter ou
supprimer). Une mise à jour automatique de la base après chaque modification.
Le code ci-dessous réalise l’édition d’un produit :
<?php
$registerOK = FALSE;
$error=FALSE;
if( isset($_GET['valider']))
{
if($_GET['Des_A'] == NULL OR $_GET["Famille_A"] == NULL OR $_GET["ss_famille_A"] == NULL OR
$_GET["N°ordre_A"] == NULL OR $_GET["Ref_A"] == NULL OR $_GET["titre_A"] == NULL OR
$_GET["Durabilité_A"] == NULL OR $_GET["type_A"] == NULL OR $_GET["ss_type_A"] == NULL OR
$_GET["PU_A"] == NULL OR $_GET["Qte_A"] == NULL OR $_GET["Montant_A"] == NULL OR
$_GET["TVA%"] == NULL OR $_GET["Code_f"] == NULL)
{
$error = TRUE;
$errorMSG = "Tout les champs doivent être remplis!";
}
$sql='INSERTINTOarticle
VALUES("'.$_GET['Des_A'].'","'.$_GET['Famille_A'].'","'.$_GET['ss_famille_A'].'","'.$_GET['N°ordre_A'].'","'.$_
GET['Ref_A'].'","'.$_GET['titre_A'].'","'.$_GET['Durabilité_A'].'","'.$_GET['type_A'].'","'.$_GET['ss_type_A'].'","'.$
_GET['PU_A'].'","'.$_GET['Qte_A'].'","'.$_GET['Montant_A'].'","'.$_GET['TVA%'].'","'.$_GET['Code_f'].'")';
if($sql)
{
$registerOK = TRUE;
$registerMSG = "Produit Ajouter avec Succés !!";
}
if(is_numeric($_GET['Des_A']))
{ echo ("Désignation n est pas de type numérique");}
if(!is_numeric($_GET['N°ordre_A']))
{ echo (" Num d ordre est un numérique ");}
if(!is_numeric($_GET['Ref_A']))
{ echo (" la reference est numérique");}
if(is_numeric($_GET['type_A']))
{ echo (" le type n est pas de type numérique");}
if (is_numeric($_GET['ss_type_A']))
{ echo (" le sous type n est pas de type numérique");}
if (!is_numeric($_GET['PU_A']))
{ echo ("le prix unitaire doit etre numérique ");}
if(!is_numeric($_GET['Qte_A']))
{ echo("la quantité est numérique ");}
if(!is_numeric($_GET['Montant_A']))
{echo("le Montant est numérique");}
if(!is_numeric($_GET['TVA%']))
{echo (" TVA numérique ");}
if(!is_numeric($_GET['Code_f']))
{echo (" le code fournisseur est numérique ");}
} mysql_close();
?>
Des
contraintes
lorsqu’on
ne les
respecte pas
un message
d’errer
s’affiche.

61 | P a g e
La suppression d’un client se fait par son numéro de carte d’identité comme
l’indique le code suivant :
<?php
if(isset($_GET['valider']))
{
$num=$_GET['num'];
$sql="select* from articles where code='".$num."'";
$result = mysql_query($sql,$base);
if (mysql_num_rows($result) == 0) {
echo "<script>alert('article introuvable!');</script>";
$error=true;
}
else
{
$sql="DELETE FROM articles WHERE code =
'".$num."'" ;
$result = mysql_query($sql,$base);
echo "<script>alert('article supprimer!');</script>";
}
}
?>
Pour la modification du produit on ressaisie toutes les données liées a un article.
if(isset($_GET['maj']))
{
$code=$_GET['code'];
$des=$_GET['des'];
$fam=$_GET['fam'];
$sfam=$_GET['sfam'];
$ordre=$_GET['ordre'];
$ref=$_GET['ref'];
$titre=$_GET['titre'];
$durab=$_GET['durab'];
$type=$_GET['type'];
$stype=$_GET['stype'];
$pu=$_GET['pu'];
$qte=$_GET['qte'];
$montant=$_GET['montant'];
$tva=$_GET['tva'];
$codef=$_GET['cfour'];
$sql1 = "update articles SET code='".$code."', Des_A='".$des."', Famille_A='".$fam."', ss_famille_A='".$sfam."',
ordre_A='".$ordre."', Ref_A='".$ref."', titre_A='".$titre."', Durabilité_A='".$durab."', type_A='".$type."',
ss_type_A='".$stype."', PU_A='".$pu."', Qte_A='".$qte."', Montant_A='".$montant."', TVA='".$tva."',
Code_f='".$codef."' WHERE code= '".$code."'";

62 | P a g e
IV.6. Interfaces de l’application:
 Page d’accueil :
Fig. 28 : Page d’accueil de l’application
62 | P a g e
62 | P a g e

63 | P a g e
 Espace administrateur :
Fig. 29 : Interface authentification administrateur
Fig. 30 : Interface ajouter un fournisseur

64 | P a g e
Fig. 31 : Interface pour modifier un fournisseur
Fig. 32 : Interface pour ajouter un produit

65 | P a g e
Fig. 33 : Interface pour publier un appel d’offre
 Espace Fournisseur :
Fig. 34 : Interface pour l’authentification des fournisseurs

66 | P a g e
Fig. 35 : Interface pour les offres des produits des fournisseurs
Fig. 36 : Interface pour répondre aux appels d’offre de magasinier

67 | P a g e
 Espace client :
Fig. 37 : Interface pour l’inscription
Fig. 38 : Interface authentification Client

68 | P a g e
Fig. 39 : Interface de consultation du stock
Fig. 40 : Interface à remplir par l’utilisation pour commander

69 | P a g e
IV.7. Conclusion :
Dans ce chapitre, nous avons décrit brièvement le processus de réalisation
de notre application Gestion de stock en spécifiant l'environnement de
développement, l'implémentation et la démarche suivie pour la réalisation. On a
justifié les choix considérés pour aboutir à la réalisation de ce projet ainsi que
quelques captures d'écran. En effet, nous avons achevé l'implémentation et les tests
de tous les cas d'utilisation, tout en respectant la conception élaborée. En d'autres
termes, nous détenons la version finale du logiciel, installée dans notre
environnement de développement. Ainsi que nous avons prévenu la plate forme
sous laquelle le système sera installé dans l'environnement dans l'environnement
des utilisateurs

70 | P a g e
Chapitre V :
Conclusion

Chapitre V : Conclusion
71 | P a g e
e projet nous a permis d’appliquer les connaissances qui nous ont été
inculquées10 au cours de ces trois années de Licence Informatique à
l’institue supérieure d’informatique et Mathématiques Monastir.
Nous avons réalisé une application Web qui permet de résoudre des
problèmes (perte de temps, rupture de stock, en proposant la solution qui va
changer la situation et offrir un bon fonctionnement.
Au cours de ce projet de fin d’étude ayant pour objet «la réalisation d’une
application web pour la gestion de stock», nous nous sommes attelés d’abord à la
détermination des points faibles des fonctionnements du magasin. Ainsi nous
avons proposé une solution adéquate pour changer la situation et aider
l’administrateur à gérer le magasin avec plus de confort et d’automatisation. Son
rôle n’est plus consacrer à la recherche des feuilles ou des commandes dans les
archives ni de contrôler après chaque ordre de livraison de marchandise le stock de
crainte qu’il se trouve dans une rupture, mais juste avec un accès simple et à
distance aux données qu’il a besoin.
Pour aidé le magasinier à gérer le magasin, on a détaillé dans le deuxième et
le troisième chapitre les différents diagrammes et scenarios qu’on passe par pour
atteindre notre but.
Notre approche dans ce travail consistait à mettre l'accent sur le magasin et
les services, et à implémenter des interfaces graphiques offrant la simplicité et la
clarté aux clients pour pouvoir bénéficier des biens de notre application.
La réalisation de ce projet a nécessité l’apprentissage d’une multitude de
langages d’outils de développement comme PHP, HTML, CSS, UML, Visual
Paradigm for UML et Notepad++.
L'application que nous avons développée est dédiée spécialement au magasin de la
Faculté de Médecine de Monastir. Nous souhaitons que celle-là soit étendue afin de
toucher les différents magasins des universités de la Tunisie.
10 Imprimer une chose dans l'esprit de quelqu'un.
C

72 | P a g e
Annexe
Fig. 41 : Fiche de mouvement des entrées
Fig. 42 : Fiche des articles consommables

73 | P a g e
Fig. 43 : Fiche de stock

Extension Android
75 | P a g e
I. Introduction :
Dans le but d’améliorer l’utilisation de notre projet, on a développé notre
application sur android pour permettre aux utilisateurs d’y accéder directement par
leurs Smartphones.
II. Définition de l’android :
Android est un système d’exploitation Open Source pour Smartphones, PDA11 et
terminaux mobiles conçu par Android, une startup rachetée par Google, et annoncé
officiellement le 15 novembre 2007.
Afin de promouvoir ce système d’exploitation ouvert, Google a su fédérer12 autour
de lui une trentaine de partenaires réunis au sein de l’Open Handset Alliance13.Ils
ont comme principaux concurrents Apple avec iPhone OS qui équipe
l’iPhone,ResearchInMotionavec BlackBerryOS, Palm avec Nova ou webOS, Microsof
et son Windows Mobile, Nokia avec Symbian OS, libéré en 2008, et bien
sûr OpenMoko, le projet dont les spécifications logicielles et matérielles sont
ouvertes.
Android doit son nom à la startup éponyme spécialisée dans
le développement d’applications mobiles que Google a rachetée en août 2005. Le
logiciel, qui avait été surnommé gPhone par les rumeurs de marchés, sera proposé
gratuitement aux fabricants de téléphones mobiles, ce qui devrait faciliter son
adoption.
III. Historique d’android :
Les différentes versions d’Android ont toutes des noms de desserts (en anglais)
depuis la sortie de la version 1.5 et suivent une logique alphabétique :
Fig. 44 : Evolution des versions d’Android.
11 Est un ordinateur de poche dont l'usage est prévu originalement dans un but d'organisation.
12 Grouper
13 Est un consortium de plusieurs entreprises dont le but est de développer des normes ouvertes pour les
appareils de téléphonie mobile

Extension Android
76 | P a g e
IV. Architecture d’android :
Le schéma suivant illustre les composants principaux du système
d’exploitation Android.
Le noyau basé sur Linux 2.6 qui intègre notamment les drivers nécessaires.
Au-dessus de cette couche, on retrouve les librairies C/C++ fournissant des
fonctionnalités de plus haut niveau (moteur HTML Web Kit, base de données
SQLite), au-dessus des librairies, on retrouve l’Android Runtime, cette couche
contient les librairies cœurs du Framework ainsi que la machine virtuelle exécutant
les applications, au-dessus de la couche "Android Runtime" et des librairies cœurs,
on retrouve le Framework permettant au développeur de créer des applications.
Enfin, au-dessus du Framework, il y a les applications.
Fig. 45 : Architecture du système d’exploitation Android

Extension Android
77 | P a g e
V. Composants principaux de l’android :
 Intent : Les Intents sont des objets permettant de faire passer des messages
contenant de l’information entre composants principaux, une application A ne peut
accéder aux services d’une autre application B qu’à travers l’envoi des Intents.
 View : Les Views sont les composants de base de l’interface graphique qui
permettent de construire l’interface utilisateur ainsi que de gérer les actions
utilisateurs tels que l’appui sur l’écran tactile
Activity : Le concept d’Activity repose sur la notion d’interaction utilisateur.
Une Activity représente la fenêtre ou tout simplement l’écran qui sera affiché à
l’utilisateur. Une application peut avoir une ou plusieurs activities. Chaque Activity
est implémentée sous la forme d’une classe qui hérite de la classe Activity.
 Service : Les services n’ont pas d’interface graphique et tournent en tâche de
fond. Il est possible de s’inscrire à un service et de communiquer avec celui-ci en
utilisant l’API Android.
 ContentProvider : Les ContentProvider sont, comme l’exprime leurs noms,
des gestionnaires de données. Ils permettent de partager l’information entre
applications.
 BroadcastReceiver : Pour finir, un BroadcastReceiver est une application qui
est à ’l’écoute’ des autres applications. Ce type d’application tente de répondre au
Intent qui lui sont adressés.Il ne fait donc rien d’autres que d’être à l’écoute des
Intent envoyés par d’autres composants applicatifs.
VI. Outils de réalisation d’un projet Android :
VI.1. Outils et installation :
Pour la création d’une application android, il est nécessaire d’installer les
éléments suivants :
 JDK : Java Development Kit : Environnement de développement de Java, qui
permet de compiler et exécuter des applications écrites en Java.
 Eclipse : IDE (Integrated Developement Environment) pour une écriture
simplifiée du code. On utilise avec Eclipse le plugin ADT (Android Developement
Tools) adapté aux applications Android.
 Android SDK : Android Software Developement Kit : Le SDK fournit une API
et un ensemble d’outils pour le développement d’applications sur Android. Il
contient principalement un émulateur (AVD pour Android Virtual Device) qui

Extension Android
78 | P a g e
permet de modéliser un appareil mobile réel en définissant les options logicielles et
matérielles désirées.
VI.2. Création et utilisation de l’émulateur :
Afin de tester notre application, nous allons utiliser l’émulateur14 Android. Il
faudra donc créer un Android Virtual Device (AVD). Un AVD décrit les paramètres
systèmes et les composants de notre émulateur.
Pour créer un AVD :
 Nous lançons Eclipse
 Nous allons sous "Window > Android SDK and AVD Manager"
 Nous sélectionnons "Virtual Device" dans le panneau à gauche
 Nous cliquons sur "New". La boite de dialogue "Create New AVD" apparaîtra
 Nous tapons le nom de notre AVD, "emul_GsMag" par exemple
 Nous choisissons la cible (the target). La cible est la version de la plateforme
Android SDK que nous avons téléchargé (2.3.3).
 Nous ignorons les autres champs pour le moment et nous cliquons sur
"Create AVD"
Fig. 46 : Liste des AVD crées
14 C’est un appareil mobile virtuel qui fonctionne sur l’ordinateur. L’émulateur permet aux
développeurs de développer, tester et évaluer des applications Android sans l'aide d'un appareil
physique
Créer un
nouveau divice
virtuel

Extension Android
79 | P a g e
VI.3. Création d’un projet Android :
Après avoir créé un émulateur Android, nous passons à la création du projet
sous Eclipse.
• Cliquer sur , ou aller à File, New puis Android Project
• Spécifier le nom du projet : Gsmag, et cliquer sur Next
• Choisir la plateforme Android à utiliser (dans notre cas 2.3.3), cliquer sur Next
• Dans la fenêtre suivante, nous devons spécifier un package à utiliser, qui
doit être unique. Ce package doit contenir au moins deux niveaux. Dans notre cas,
on peut taper com.android.Gs-Mag et cliquer sur Finish. Un nouveau projet
apparaît.
VI.4. Modification de l’interface graphique:
L’interface graphique est gérée grâce aux fichiers XML qui se trouvent dans le
répertoire layout. ADT offre une interface conviviale pour gérer ces fichiers, et pour
manipuler graphiquement les éléments de l’interface.
Fig. 47 : Interface graphique

Extension Android
80 | P a g e
VII. Les interfaces :
Fig. 48 : Interface Smartphone
Fig. 49 : Interface d'accès à l’application

Extension Android
81 | P a g e
Fig. 50 : Page d’accueil via Smartphone
Fig. 51 : Formulaire d’inscription via Smartphone

Extension Android
82 | P a g e
Fig. 52 : Interface d’authentification
VIII. Conclusion :
Ce projet nous a amenés à découvrir le monde de gestion de stock du
magasin et à développer pour la première fois sur la plateforme Android. Nous
avons mis en œuvre nos connaissances en langage Java avec des outils nouveaux
tels qu’Eclipse, et utilisé ce que Google met à disposition de ses développeurs : un
Google code. Nous avons pu réaliser notre projet pour valoriser notre application.

117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medecine.pdf

Contenu connexe

Tendances

Similaire à 117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medecine.pdf

117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medecine.pdf