Vous êtes sur la page 1sur 78

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

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

6|Page
Résumé

U
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é.

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

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

9|Page
Chapitre I :
Introduction
Chapitre I : Introduction

I.1. Contexte et motivations :

D
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

11 | P a g e
Chapitre I : Introduction

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.

12 | P a g e
Chapitre I : Introduction

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 .

13 | P a g e
Chapitre I : Introduction

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.

14 | P a g e
Chapitre II :
Spécification et analyse
des besoins
Chapitre II : Spécification et analyse des besoins

II.1. Introduction :

L
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

16 | P a g e
Chapitre II : Spécification et analyse des besoins

Archives une application web


pour l'oraganisation

service mal Perte de


gérer Temps service bien gérer Gagner le temps

Perte des Désordre du


documents magasin
automatisation des
Ordonnancement du
taches
magasin

Avant
Après

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,

17 | P a g e
Chapitre II : Spécification et analyse des besoins

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.

18 | P a g e
Chapitre II : Spécification et analyse des besoins

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

19 | P a g e
Chapitre II : Spécification et analyse des besoins

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

20 | P a g e
Chapitre II : Spécification et analyse des besoins

 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. 4 : Formulaire à remplir par le fournisseur (ICIM Stock)

Fig. 5 : Formulaire à remplir par le fournisseur (ICIM Stock)

21 | P a g e
Chapitre II : Spécification et analyse des besoins

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  Interfaces compliqués et non
compréhensibles compréhensibles.
 Pas besoin des factures  Tous le travail est basé sur les
 La banque n’intervient pas factures et les manières de
 Gratuite payement.
 Répond aux besoins de la faculté de  Payante donc cher et pour chaque
Médecine de Monastir mise à jour de l’application
 Notre interface et notre module sont  On les utilise juste pour les grandes
complets. 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.

22 | 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é.

23 | P a g e
Chapitre III: Etude
conceptuelle
Chapitre III: Etude conceptuelle

c
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 UML 7 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.

Vue logique Vue implantation

Vue des cas d'utilisation


Vue des processus Vue de déploiement

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

25 | P a g e
Chapitre III: Etude conceptuelle

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.

Modèle fonctionnel
Que fait le système
Aspect dynamique :
Aspect fonctionnel :
diagrammes d'interaction séquences,
collaboration), diagrammes des cas d'utilisation
Séquencement des actions
d'états-transitions
Dans et
le d'activité
système Modèle structurel (objet)

Sur quoi le système agit


Modèle temporel
Aspect statique :

diagramme de classes et d'objets

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

26 | P a g e
Chapitre III: Etude conceptuelle

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

27 | P a g e
Chapitre III: Etude conceptuelle

III.3.1.1. Diagramme de cas d’utilisation « Magasinier » :

Fig. 6 : 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.

28 | P a g e
Chapitre III: Etude conceptuelle

scénario d’un cas d’utilisation


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.

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

Consulter le stock Cas normal Description détaillé

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.

Variante En (4) le magasinier n'est pas reconnu, dans ce cas, tant


qu'il n'est pas reconnu, on lui redemande de
1 s'authentifier

Variante En (7) le système affiche le stock, si la quantité d’un


produit a atteint 20% de stock une alarme sera
2 déclencher pour informer le magasinier.

Fig. 8 : Description plus détaillé du cas d’utilisation « consulter le stock »

29 | P a g e
Chapitre III: Etude conceptuelle

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.

30 | P a g e
Chapitre III: Etude conceptuelle

III.3.1.2. Diagramme de cas d’utilisation «client» :

Fig. 9 : 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.

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.

Fig. 10 : Description détaillé du cas d’utilisation « consulter le stock »

31 | P a g e
Chapitre III: Etude conceptuelle

La figure ci-dessus peut etre expliqué d’avantage dans la figure 11.

Scénario d’un cas d’utilisation

Commander Cas normal Description détaillé

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.
3. Le système lui demande de s’authentifier.
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.

Variante1 En (8) le client doit connaitre les produits présents

Variante En (4) le client n'est pas reconnu, dans ce cas, tant


qu'il n'est pas
2
reconnu, on lui redemande de s'authentifier
Variante En (8), le client peut envoyer plusieurs commandes
3 successives

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é

32 | P a g e
Chapitre III: Etude conceptuelle

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

Scénario d’un cas d’utilisation

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

Fig. 13 : Description détaillé du « Répondre aux appels d’offre »

33 | P a g e
Chapitre III: Etude conceptuelle

La figure précédente peut etre expliqué d’avantage dans la figure suivante.

Scénario d’un cas d’utilisation

Répondre aux appels d’offres Cas normal Description détaillé

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 ».
3. Le système lui demande de s’authentifier.
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.

Variante En (3), le fournisseur n'est pas reconnu, dans ce


1 cas, tant qu'il n'est pas reconnu, on lui
redemande de s'authentifier

Variante En (6), le fournisseur peut envoyer un e-mail au


2 magasinier pour la communication et le choix des
appels d’offres.

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.

34 | P a g e
Chapitre III: Etude conceptuelle

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 »

35 | P a g e
Chapitre III: Etude conceptuelle

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

Fig. 16 : Diagramme de séquence de scénario « authentification Client »

Le diagramme représenté dans la figure 16 décrit les scénarios possibles lors


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

36 | P a g e
Chapitre III: Etude conceptuelle

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.

37 | P a g e
Chapitre III: Etude conceptuelle

III.3.2.3. Diagramme de séquence scénario « Commander » :

Fig. 18 : Digramme de séquence du scénario « commander »

Le diagramme représenté dans la figure 18 décrit les scénarios possibles lors


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.

38 | P a g e
Chapitre III: Etude conceptuelle

III.3.2.4. Diagramme de séquence du scénario « Répondre aux appels d’offres » :

Fig. 19 : Diagramme de séquence du scénario « Répondre aux appels d’offres »

Le diagramme représenté dans la figure 19 décrit les scénarios possibles lors


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. 20 : Diagramme de séquence de scénario « Communication »

39 | P a g e
Chapitre III: Etude conceptuelle

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

40 | P a g e
Chapitre III: Etude conceptuelle

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

41 | P a g e
Chapitre III: Etude conceptuelle

Sous état : Vérification :

Etat : Répondre aux commandes

42 | P a g e
Chapitre III: Etude conceptuelle

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

43 | P a g e
Chapitre III: Etude conceptuelle

III.4. Présentation des maquettes préliminaires :

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.
Pour
contacter
Un numéro de téléphone doit être
les clients
composé que des chiffre pas des
en cas des
lettres ni des symboles
besoins.

Le
numéro Un email doit être sous la forme :
de
téléphone Chaine@chaine.chaine
et l’email
sont
obligatoire
Chaque utilisateur possède
s.
un login et mot de passe
pour accéder a l’application

Un message
d’erreur
apparait lorsque
les contraintes Envoyer la
commande. Effacer et remplir
de saisie ne
le formulaire de
seront pas nouveau en cas
respecter d’erreur.

Fig. 23 : Interface Inscription

44 | P a g e
Chapitre III: Etude conceptuelle

Pour la
connexion
automatique

Chaque
utilisateur
possède un Se diriger
vers le forum
login qui lui
de Envoyer un
permet
l’inscription email pour
d’accéder à en cas d’un rappeler le
l’application. utilisateur client
non inscrit.

Envoyer la Effacer et remplir


commande le formulaire de
nouveau en cas
Fig. 24 : Interface authentification
d’erreur.

L’identifiant de l’utilisateur, il
est obligatoire.

Chaque produit a un
code (ID) spécifique et
unique. 3 type de produit :
titre1, titre2 et Pack

Un message
d’erreur
apparait en
Chaque utilisateur doit cas d’erreur
donner la date de besoin du
produit pour se précipiter
en cas de rupture de stock.

Fig. 25 : Interface du formulaire d’une commande

45 | P a g e
Chapitre III: Etude conceptuelle

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.

46 | P a g e
Chapitre IV : Technique
de développement
Chapitre IV : Techniques de développement

IV.1. Introduction :

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

48 | P a g e
Chapitre IV : Techniques de développement

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.

49 | P a g e
Chapitre IV : Techniques de développement

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
Chapitre IV : Techniques de développement

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
Chapitre IV : Techniques de développement

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
Chapitre IV : Techniques de développement

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.

53 | P a g e
Chapitre IV : Techniques de développement

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

Sénario1
5
Sérnario2
4 Sénario3
Sénario4
3
Sénario5
2 Sénario6
Sénario7
1

0
Faisabilité spécificité Efficacité Rendement Evolutivité

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

54 | P a g e
Chapitre IV : Techniques de développement

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.

IV.5. Les phases de développement :

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.

55 | P a g e
Chapitre IV : Techniques de développement

 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);
Contrôle des données
$qte_dispo=$ligne['Qte_A']; saisies
$qte1=$_GET['qte1'];

if($qte1 > $qte_dispo)

{echo '<script type="text/javascript">alert("qte indisponible")</script>';} Mise a jour


else{ de la base

$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); Insertion dans la base

$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>';}}

?>

56 | P a g e
Chapitre IV : Techniques de développement

<?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) {
Requête de sélection de la
echo "<script>alert('Ncin incorrecte!');</script>"; commande à consulter
$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() );

$total = mysql_num_rows($result);

$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 L’affichage de
while($row = mysql_fetch_array($result)) {
la commande

echo" <tr><td>".$row["article"]."</td><td>".$row["qte"]."</td><td>".$row["date"]."</td></tr>";

}} }

57 | P a g e
Chapitre IV : Techniques de développement

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'].'")'; Création
$sql = mysql_query($sql);
echo'<script>alert("votre appel a été postuler")</script>';}
d’un
if(isset($_GET['valider1'])) nouvel
{?> appel
<div id="templatemo_right_content">
<div id="templatemo_content_area"> d’offre
<div class="templatemo_title">les répenses appels d'offres :</div>
<?php
$select = 'SELECT nom,qte,prix,date FROM repappel';
$result = mysql_query($select,$base) or die ('Erreur : '.mysql_error() );
$total = mysql_num_rows($result);
if($total) {
while($row = mysql_fetch_array($result)) { Affichage
echo '<div style="background-color:white;"><fieldset>'; des
echo ' le fourniseur :<u><font
color="#0097C5"><strong>'.$row["nom"].'</strong></font></u>'; réponses

58 | P a g e
Chapitre IV : Techniques de développement

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
} Affichage des
if(isset($_GET['valider2']))
{ réponses
?>
<div id="templatemo_right_content"> Affichages des
<div id="templatemo_content_area"> nouveaux
<div class="templatemo_title">les nouveaux appels d'offres :</div>
appels d’offres
<?php
$select="select * from new";
$result = mysql_query($select,$base) or die ('Erreur : '.mysql_error() );
$total = mysql_num_rows($result);
if($total) {
echo'<fieldset>';
while($row = mysql_fetch_array($result)) {
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>';}}}
?>

59 | P a g e
Chapitre IV : Techniques de développement

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'].'")';
$sql = mysql_query($sql);
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 ");}

Des if(!is_numeric($_GET['Ref_A']))
contraintes { echo (" la reference est numérique");}

lorsqu’on if(is_numeric($_GET['type_A']))
ne les { echo (" le type n est pas de type numérique");}
respecte pas if (is_numeric($_GET['ss_type_A']))
un message { echo (" le sous type n est pas de type numérique");}
d’errer if (!is_numeric($_GET['PU_A']))
s’affiche. { 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();
?>

60 | P a g e
Chapitre IV : Techniques de développement

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."'";

61 | P a g e
Chapitre IV : Techniques de développement

IV.6. Interfaces de l’application:


 Page d’accueil :

Fig. 28 : Page d’accueil de l’application

62 | P a g e
Chapitre IV : Techniques de développement

 Espace administrateur :

Fig. 29 : Interface authentification administrateur

Fig. 30 : Interface ajouter un fournisseur

63 | P a g e
Chapitre IV : Techniques de développement

Fig. 31 : Interface pour modifier un fournisseur

Fig. 32 : Interface pour ajouter un produit

64 | P a g e
Chapitre IV : Techniques de développement

Fig. 33 : Interface pour publier un appel d’offre

 Espace Fournisseur :

Fig. 34 : Interface pour l’authentification des fournisseurs

65 | P a g e
Chapitre IV : Techniques de développement

Fig. 35 : Interface pour les offres des produits des fournisseurs

Fig. 36 : Interface pour répondre aux appels d’offre de magasinier

66 | P a g e
Chapitre IV : Techniques de développement

 Espace client :

Fig. 37 : Interface pour l’inscription

Fig. 38 : Interface authentification Client

67 | P a g e
Chapitre IV : Techniques de développement

Fig. 39 : Interface de consultation du stock

Fig. 40 : Interface à remplir par l’utilisation pour commander

68 | P a g e
Chapitre IV : Techniques de développement

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

69 | P a g e
Chapitre V :
Conclusion

70 | P a g e
Chapitre V : Conclusion

C
e projet nous a permis d’appliquer les connaissances qui nous ont été
inculquées 10 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.

71 | P a g e
Annexe

Fig. 41 : Fiche de mouvement des entrées

Fig. 42 : Fiche des articles consommables

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

73 | P a g e
Extension
Android
Extension Android

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, PDA 11 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

75 | P a g e
Extension Android

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

76 | P a g e
Extension Android

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

77 | P a g e
Extension Android

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"

Créer un
nouveau divice
virtuel

Fig. 46 : Liste des AVD crées

14C’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

78 | P a g e
Extension Android

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

79 | P a g e
Extension Android

VII. Les interfaces :

Fig. 48 : Interface Smartphone

Fig. 49 : Interface d'accès à l’application

80 | P a g e
Extension Android

Fig. 50 : Page d’accueil via Smartphone

Fig. 51 : Formulaire d’inscription via Smartphone

81 | P a g e
Extension Android

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.

82 | P a g e