Conception et réalisation d'une application web pour la gestion des stocks cas d'étude magasin de la faculté des sciences exactes de l'université de Bejaia

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE L'ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE

Université Abderrahmane Mira de Bejaïa
Faculté des Sciences Exactes
Département d'Informatique

Mémoire de fin de cycle

En Vue De L'obtention Du Diplôme
Licence Académique en Informatique

THEME

Conception et réalisation d'une application

web pour la gestion des stocks

Cas d'étude : Faculté des Sciences Exactes

Réalisé par: Encadré par:

BENCHARIF Souad BOUDAA Slimane Mme TAHAKOURT. Z

LAHLOU Laaziz MEDDAH Boussad

MANSOUR Abdelaziz MELLOUK Cherif Examinateurs:

MOAD Toufik MOKRANI Nadjim Mr OMAR .M

OUAZINE Kahina YAHIAOUI Hakim Mr DEMMOUCHE .O

Promotion Juin 2010

«Puisqu'on ne peut être universel en sachant tout ce qui se peut savoir
sur tout, il faut savoir peu de tout, car il est bien plus beau de savoir

quelque chose de tout que de savoir tout d'une chose. Cette universalitéest la plus belle. Si on pouvait avoir les deux encore mieux, mais s'il faut
choisir il faut choisir celle-là. Pensées, Et le monde le sait et le fait, car
le monde est un bon juge ^souvent»[Blaise Pascal (1623-1662)]

«En essayant continuellement, on finit par réussir, donc : plus on rate,
plus on a de chances que ça marche»

Nous dédions ce modeste travail à :

+ Nos très chers parents;

+ Nos très chers frères et scours;

+ Toutes nos familles ;

+ Tous nos ami(e)s.

A mes très chers parents

(yemma saliha et vava madjid)

Pour tout l'amour don't vous m'avez entouré, pour tout ce que vous avez
fait pour moi.

Je ferai de mon mieux pour rester un sujet de fierté à vos yeux avec
l'espoir de ne jamais vous décevoir.

Que ce modeste travail, soit l'exaucement de vos veux tant formulés et de
Vos priers quotidiennes.

A mes très chers frères, soeur et mon oncle

( Rabah, Sofiane, Kamel, Thaninna, khali

abdennour)

Vous occupez une place particulière dans mon coeur. Je vous dédie ce
travail en vous souhaitant un avenir radieux, plein de
bonheur et de succès.

A Lahlou Laaziz(& thifloukines laali) , Mokrani

Nadjim, Kamel Hemchaoui & touts mes ami(e)s et

surtout hanane de tunisie

En souvenir de nos éclats de rire, des bons moments et nuits blanches.
En souvenir de tout ce qu'on a vécu ensemble.
J'espère de tout mon coeur
Que notre amitié durera
éternellement.

Moad Toufik.

A mes très chers parents

Je vous dois ce que je suis aujourd'hui grâce à votre amour, à votre
patience et vos innombrables sacrifices.

Que ce modeste travail, soit pour vous une petite compensation et
reconnaissance envers ce que vous avez fait
d'incroyable pour moi.

Que dieu, le tout puissant, vous préserve et vous procure santé
et longue vie afin que je puisse à mon tour vous combler.

A mes très chers soeurs, frère, ma tante ounissa et mon oncle bouhou

Aucune dédicace ne serait exprimer assez profondément ce que
je ressens envers vous.

Je vous dirais tout simplement, un grand merci, je vous aime.

A mes très chers ami(e)s

En témoignage de l'amitié sincère qui nous a liée et des bons moments

passés ensemble. Je vous dédie ce travail en vous souhaitant un avenir radieux et plein
de bonnes promesses.

A moad toufik, hammou (l'athlete du someil) & Nadjim Mokrani

En souvenir de nos éclats de rire, des bons moments et des nuits blanches.
En souvenir de tout ce qu'on a vécu ensemble.
J'espère de tout mon
coeur que notre amitié durera éternellement.

A tous les assoifés du savoir

Où l'encre des savants est bien meilleur auprès de dieu que le sang des martyrs

Laaziz LAHLOU.

Remerciement

Wous exprimons nos remerciements à notre encadreur Madame TAHAKOURT .Z pour l'assistance qu'elle nous a témoignée, pour sa disponibilité, pour ces orientations et conseils sans lesquels ce travail ne verra pas le jour, qu'elle trouve ici l'expression de notre gratitude.

Wous adressons nos vifs remerciements à Monsieur AUHROFAWE .A pour son aide et ses précieux conseils.

Wous souhaitons également remercier Monsieur « le magasinier de la faculté des sciences exactes » pour ces orientations.

Wous remercions tout particulièrement les membres de jury qui ont accepté de juger notre travail ainsi que tous les enseignants qui ont contribué à notre formation.

Enfin, Wous remercions aussi tous nos amis et collègues qui nous ont soutenu et tous ceux qui ont contribué de près ou de loin à la réalisation de ce travail.

Table Des Matières

Introduction générale 1

Chapitre I: Généralités

INTRODUCTION 3

I._LE PROCESSUS UNIFIE ET UML 4

I.1 PRESENTATION D'UML 4

I.1.1 La notation UML 4

I.1.2 Les Diagrammes UML 5

I.1.3 Diagramme de cas d'utilisation 6

I.1.4 Diagramme de séquence 6

I.1.5 Diagramme d'activités 7

I.1.6 Diagramme de classe 7

I.I.7 Diagramme de déploiement 8

I.2 LE PROCESSUS UNIFIE 8

I.2.1 Définition d'UP 8

I.2.2 Les principes d'UP 8

I.2.3 Les phases du processus unifié : 9

I.3 RESEAU INFORMATIQUE 11

I.3.1 Concepts réseau 11

I.3.2 Présentation de l'architecture client/serveur 12

I.3.2.1 Fonctionnement d'un système client/serveur 12

I.3.3 Types d'architectures réseaux 13

I.3.3.1 Architecture à 1-tiers 13

I.3.3.2 Architecture à 2-tiers 13

I.3.3.3 Architecture à 3-Tiers 13

I.3.3.4 Comparaison entre l'architecture 2-tiers et 3-tiers 15

I.4 SERVICES WEB 16

I.4.1 Définition des services web 16

I.4.2 Les standards et l'architecture des services web 16

I.4.3 L'infrastructure des services web 17

I.4.4 Caractéristiques techniques des services web 17

CONCLUSION 18

Chapitre II: Spécification des besoins

INTRODUCTION 19

II.1PRESENTATION DE L'ORGANISME D'ACCUEIL 20

II.1.1HISTORIQUE DE L'UNIVERSITE DE BEJAIA 20

II.1.2 L'HISTORIQUE DE LA FACULTE DES SCIENCES EXACTES 21

II.1.3 L'ORGANIGRAMME DE LA FACULTE DES SCIENCES EXACTES 21

II.1.4 LES MISSIONS DE LA FACULTE DES SCIENCES EXACTES 22

II.1.5 PRESENTATION DU SERVICE D'ACCUEIL 23

II.1.5.1 L'effectif du magasin 23

II.1.5.2 Missions du magasinier 23

II.1.5.3 Situation informatique : 23

II.2 CONTEXTE DU SYSTEME 24

II.2.1CIRCUIT DU DEROULEMENT DES ACTIVITES RELATIVES A LA FACTURE 24

II.2.2 CIRCUIT DU DEROULEMENT DES ACTIVITES RELATIVES AU BON DE COMMANDE INTERNE : 27

II.2.3 DIAGNOSTIC DE LA SITUATION ACTUELLE 29

II.3 PROBLEMATIQUE 29

II.4 PROPOSITIONS 30

II.5 OBJECTIFS 30

II.6 DIAGRAMME DU CONTEXTE 31

II.6.1 IDENTIFICATION DES ACTEURS 32

II.6.2 IDENTIFICATION DES MESSAGES 32

CONCLUSION 33

Chapitre III: Analyse des besoins

INTRODUCTION 34

III.1MODELE DU SYSTEME 35

III.2 BESOINS FONCTIONNELS ET NON FONCTIONNELS 36

III.2.1BESOINS FONCTIONNELS 37

III.2.2 BESOINS NON-FONCTIONNELS 41

III.3 LA DEMARCHE DU PROTOTYPAGE 41

III.4 REALISATION DES DIAGRAMMES DE SEQUENCES 43

III.4.1 DIAGRAMME DE SEQUENCE DU CAS D'UTILISATION AUTHENTIFIE 43

III.4.3 DIAGRAMME DE SEQUENCE DU CAS D'UTILISATION MODIFIER UN PRODUIT 44

III.4.4 DIAGRAMME DE SEQUENCE DU CAS D'UTILISATION SUPPRIMER UN PRODUIT 45

III.4.5 DIAGRAMME DE SEQUENCE DU CAS D'UTILISATION AJOUTER UN BON DE SORTIE 46

III.4.6 DIAGRAMME DE SEQUENCE DE CAS D'UTILISATION MODIFIER UN BON DE SORTIE 48

III.4.7 DIAGRAMME DE SEQUENCE DU CAS D'UTILISATION SUPPRIMER UN BON DE SORTIE 50

III.4.8 DIAGRAMME DE SEQUENCE DU CAS D'UTILISATION CONSULTER L'ETAT DE STOCK 51

III.4.9 DIAGRAMME DE SEQUENCE DE CAS D'UTILISATION EDITER UN BON DE SORTIE 52

III.5 RISQUES CRITIQUES : 53

Chapitre IV: Conception

INTRODUCTION 55

IV. REALISATION DU DIAGRAMME DE CLASSE 56

IV.1 REGLES DE GESTION 56

IV.2 DICTIONNAIRE DES DONNEES 57

IV.3 DIAGRAMME DE CLASSE 58

IV.4 LE MODELE LOGIQUE DE DONNEES : 60

IV.5 REGLES DE PASSAGES 60

IV.6 REGLES DE NORMALISATION 60

CONCLUSION 61

Chapitre V: Réalisation

INTRODUCTION 62

V.1 ENVIRONNEMENT DE DEVELOPPEMENT DE L'APPLICATION 63

V.2 OUTILS DE DEVELOPPEMENT 63

V.2.1 WAMPSERVER 63

V.2.2 PHP 64

V.2.3 ADOBE DREAMWEAVER 64

V.2.4 MYSQL 65

V.2.4.1 Concurrents de MySQL 66

V.2.5 JAVASCRIPT 66

V.2.6 PHOTOSHOP 67

V.3 IMPLEMENTATION DE LA BASE DE DONNEES 68

V.4 LA SECURITE DE L'APPLICATION 68

V.5ARBORESCENCE DE L'APPLICATION WEB 69

V.6 INTERFACES DE L'APPLICATION 70

V.6.1 INTERFACE D'ACCUEIL 70

V.6.2 INTERFACE D'ADMINISTRATION 70

V.6.3 INTERFACE GESTION DES SESSIONS 71

V.6.4 INTERFACE EDITION FICHE DE STOCK 72

V.7 ARCHITECTURE MATERIELLE MISE EN PLACE 73

V.8 DIAGRAMME DE DEPLOIEMENT 74

V.9 TEST 75

V.9.1 TEST DU CAS D'UTILISATION « AUTHENTIFICATION» 75

V.9.2 TEST DU CAS D'UTILISATION « ETABLIR UN BON DE SORTIE » 75

V.9.3 TEST DU CAS D'UTILISATION « IMPRIMER UN BON DE SORTIE » 76

V.9.4 TEST DU CAS D'UTILISATION « SUPPRIMER UN BON DE SORTIE » 77

V.9.5 TEST DU CAS D'UTILISATION « MODIFIER UN BON DE SORTIE » 77

V.9.6 TEST DU CAS D'UTILISATION «AJOUT D'UN NOUVEL ARTICLE» 77

V.9.6 TEST DU CAS D'UTILISATION « ETABLIR UNE FICHE DE STOCK» 78

Liste des figures

Figure 1 : Schéma d'ensemble des diagrammes d'UML 2 5

Figure 2 : Cycle de vie du processus unifié 9

Figure 3 : Schéma de fonctionnement d'un système client/serveur 12

Figure 4 : Architecture à 2-Tiers 13

Figure 5 : Architecture 3-Tiers .. 14

Figure 6 : Architecture de référence des services web . 17

Figure 7 : Organigramme de la Faculté des Sciences Exactes . 21

Figure 8 : Diagramme d'activité relatif à la facture . 26

Figure 9 : Diagramme d'activité relatif au bon de commande interne 28

Figure 10:Diagramme de contexte . 33

Figure 11:Diagramme du cas d'utilisation gestion des stocks . 35

Figure 12: Package du cas d'utilisation gérer les bons de sorties 37

Figure 13: Package du cas d'utilisation gérer les bons d'entrées . 38

Figure 14 : Package du cas d'utilisation édition 38

Figure 15 : Package du ca d'utilisation mettre a jour la base de donnée 40

Figure 16: Interface gestion des entrées . 42

Figure 17: Interface gestion des sorties 42

Figure 18: Interface gestion des produits 42

Figure 19 : Le diagramme de séquence du cas d'utilisation authentifier 43

Figure 20 : Diagramme de séquence de cas d'utilisation ajouter un produit 44

Figure 21 : Diagramme de séquence du cas d'utilisation modifier un produit 45

Figure 22 : Diagramme de séquence du cas d'utilisation supprimer un produit 46

Figure 23 : Diagramme de séquence du cas d'utilisation ajouter un bon de 47

Figure 24 : Diagramme de séquence ajouter une ligne de bon de sortie 48

Figure 25 : Diagramme de séquence du cas d'utilisation modifier un bon de sortie.. 49

Figure 26 : Diagramme de séquence modifier une ligne de bon de sortie . 50

Figure 27 : Diagramme de séquence supprimer un bon de sortie 51

Figure 28 : Diagramme de séquence du cas d'utilisation consulter le stock . 52

Figure 29 : Diagramme de séquence du cas d'utilisation éditer un bon de sortie...... 53

Figure 30: Diagramme de classe . 59

Figure 31: Page d'accueil WampServer 64

Figure 32: Base de données Gestock .. 68

Figure 33: Arborescence de l'application web . 69

Figure 34: Interface d'accueil 70

Figure 35: Interface d'administration 71

Figure 36 : Interface gestion des sessions . 72

Figure 37 : Interface fiche de stock 73

Figure 38 : Architecture matérielle adoptée . 73

Figure 39: Diagramme de déploiement 74

Figure 40 : Test sur les sorties du stock 76

Figure 41 : Test sur l'impression d'un bon de sortie 77

Figure 42 : Test établir une fiche de stock 78

Figure 43 : Bon de sortie et bon de commande interne 86

Figure 44 : Bon d'entrée 87

Figure 45 : Fiche de stock 87

Liste des tableaux

Liste des tableaux:

Tableau 1 : Anomalies et suggestions 29

Tableau 2 : Propositions et solutions informatiques 30

Tableau 3 : Comparaison des deux SI manuel est automatisé . 31

Tableau 4 : Tableau des messages en interaction . 32

Tableau 5 : Dictionnaire des données 57

Introduction générale

Durant ces dernières années l'informatique s'est imposée 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 abstrait. On entend également par << l'informatique » l'ensemble des sciences et techniques en rapport avec le traitement de l'information.

L'informatique est de plus en plus utilisée 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 exigés par cette activité de gestion des stocks.

Nous avons pu constater, en effet, pendant nos recherches que l'ensemble des traitements au sein du magasin de la Faculté des Sciences Exactes de l'Université de Bejaia 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 ; donc la meilleure solution pour palier aux problèmes et l'informatisation afin d'assurer l'accès instantané aux données et une 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é des Sciences Exactes afin de leur concevoir un système d'information automatisé pour leur gestion des stocks.

Pour la réalisation de cette tâche, notre choix s'est porté sur le Processus Unifié. En effet, le processus unifié est une solution de développement logiciel adaptée à tout type de projet. Ses traits distinctifs tiennent en trois notions : piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental.

Le langage de modélisation qu'on a utilisé est UML (Unifier Modeling Language), qui est une partie intégrante de la démarche UP. Ses diagrammes sont largement utilisés dans chaque étape et phases de ce processus de développement.

Pour l'implémentation, le choix du langage de programmation à été dicté par le type de l'application qui devrait être réalisée d'une part, et être accessible via le réseau Intranet de l'Université d'autre part. Ainsi, le choix s'est porté sur le langage de programmation PHP. La base de données est implémentée avec MySQL qui est largement compatible avec PHP.

Ayant présenté les outils et la méthode adoptée, nous allons maintenant exposer le plan du mémoire qui se subdivisera en quatre principaux chapitres.

Dans le premier chapitre intitulé << Généralités » nous présentons quelques concepts de base de la méthode et outils qui nous ont servi pour l'accomplissement de notre projet.

Puis, au sein de <<Spécification 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 experts du domaine, ensuite déterminer les inconvénients majeurs de la gestion actuelle du service d'accueil, énumérer des suggestions informatiques qui peuvent remédier aux difficultés rencontrées, et enfin, 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é <<Analyse des besoins », nous analysons les principaux objectifs attendus du futur système à concevoir, et qui seront décrits par le diagramme des cas d'utilisation.

Concernant le quatrième chapitre : <<Conception », nous étendons la représentation des diagrammes effectués au niveau de l'analyse en y intégrant les aspects techniques les plus proches des préoccupations physique.

Finalement dans le dernier chapitre qu'on a nommé << Réalisation » nous présentons les outils de développement qui nous ont servi pour le développement de l'application, et enfin l'activité test qui consiste, justement, à la tester dans le but de s'assurer de son bon fonctionnement.

«La science restera toujours la satisfaction
du plus haut désir de notre nature, la curiosité ;
elle fournira à l'homme le seul moyen qu'il ait
d'améliorer son sort''
[ Ernest Renan]

Introduction

Dans le cadre de ce chapitre, nous allons définir quelques généralités portant sur la méthode et outils mettant en évidence la réalisation de notre projet. Nous allons commencer par présenter le langage de modélisation unifié UML (Unified Modeling Language), définir la démarche générique du processus de développements logiciel qui l'accompagne, énumérer les architectures réseaux et enfin nous allons présenter les principaux concepts de base des services web.

I._Le Processus Unifié et UML

Pendant plusieurs décennies, le monde informatique a toujours rêvé d'un processus qui puisse garantir le développement efficace de logiciels de qualité, valable quelque soit la grandeur et la complexité du projet, et présentant de bonnes pratiques adaptées à la méthode en question, surtout que, de nos jours, les logiciels demandés sont de plus en plus imposants et exigeants qu'auparavant.

Le processus unifié semble être la solution idéale pour remédier à l'éternel problème des développeurs. En effet, il regroupe les activités à mener pour transformer les besoins d'un utilisateur en un système logiciel quelque soit la classe, la taille et le domaine d'application de ce système.

Le processus unifié utilise le langage UML (Unified Modeling Language). Ce langage de modélisation est une partie intégrante du processus unifié, ils ont été d'ailleurs développés de concret.

Essayons tout d'abord de présenter UML, car ses diagrammes sont utilisés dans chaque phase et activité du processus unifié, ensuite nous reviendrons sur la présentation du processus unifié.

I.1 Présentation d'UML I.1.1 La notation UML

UML (Unified Modeling Language), 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. [JU01]

I.1.2 Les Diagrammes UML

UML dans sa version 2 s'articule autour de treize diagrammes, chacun d'entre eux est dédié à la représentation d'un système logiciel suivant un point de vue particulier. Ces diagrammes sont regroupés dans deux grands ensembles: les diagrammes structurels et les diagrammes de comportement.

L'ensemble des treize types de diagrammes UML peut ainsi être résumé sur la figure ci-dessous :

Diagramme de
Comportement

Diagramme d'activité

Diagramme de cas

Diagramme d'état

Diagramme d'interaction

Diagramme
UML 2

Diagramme de composant

Diagramme d'objet

Diagramme de classe

Diagramme de déploiement

Diagramme de structure composite

Diagramme de package

Diagramme de séquence

Diagramme de communication

Diagramme de vue d'ensemble d'interaction

Diagramme de Timing

Diagramme de
Structure

Figure 1 : Schéma d'ensemble des diagrammes d'UML 2

Nous présentons ci-dessous les diagrammes UML 2, que nous avons utilisés dans le cadre de ce projet et quelques notions de base qui leurs étant associées.

I.1.3 Diagramme de cas d'utilisation

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

· 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é.[Roques06]

· 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. [Roques06]

· Les relations entre acteurs : La seule relation entre acteur est la relation de généralisation. Quand un acteur fils hérite d'un acteur père, il hérite en réalité de toutes les associations du père. [Roques06]

· Les relations entre cas d'utilisation :

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

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

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

I.1.4 Diagramme de séquence

Ce diagramme 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. [JD08]

· Scénario: Représente une succession particulière d'enchaînements, s'exécutant du début à la fin du cas d'utilisation, un enchaînement étant l'unité de description de séquences d'actions. [Roques06]

· Ligne de vie : Représente l'ensemble des opérations exécutées par un objet. [JD08]

· Message: Un message est une transmission d'information unidirectionnelle entre deux objets, l'objet émetteur et l'objet récepteur. Dans un diagramme de séquence, deux types de messages peuvent être distingués :

> Message synchrone : Dans ce cas l'émetteur reste en attente de la réponse à son message avant de poursuivre ses actions. [JD08]

> Message asynchrone : Dans ce cas, l'émetteur n'attend pas la réponse à son message, il poursuit l'exécution de ses opérations. [JD08]

I.1.5 Diagramme d'activités

Ce diagramme donne une vision des enchaînements des activités propres à une opération ou à un cas d'utilisation. Il permet aussi de représenter les flots de contrôle et les flots de données. [JD08]

· Action : correspond a un traitement qui modifié l'état de système. L'enchaînement des actions constitue le flot de contrôle. [JD08].

· Le passage d'une action à une autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d'une action et provoquent le début d'une autre (elles sont automatiques). [AM07]

· Activité : représente le comportement d'une partie du système en termes d'actions et de transitions. [JD08]

I.1.6 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é. [Roques06]

· Une classe : Représente la description abstraite d'un ensemble d'objets possédant les mêmes caractéristiques. On peut parler également de type. [Roques06]

· 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. [Roques06]

· Un attribut : Représente un type d'information contenu dans une classe. [Roques06]

· Une opération: Représente un élément de comportement (un service) contenu dans une classe. [Roques06]

· Une association: Représente une relation sémantique durable entre deux classes.[Roques06]

· 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. [Roques06]

I.I.7 Diagramme de déploiement

Ce diagramme décrit l'architecture technique d'un système avec une vue centrée sur la répartition des composants dans la configuration d'exploitation. [JD08]

I.2 Le Processus Unifié I.2.1 Définition d'UP

Pour définir le processus unifié, nous allons simplement définir les deux termes qui le composent :

· Processus : Suite continue d'opérations constituant la manière de fabriquer. En d'autres termes, c'est une succession de tâches dans le but d'accomplir un travail, un projet.

· Unifié : Participe passé du verbe unifié, être amené à l'unité, se fondre en un tout. En fait, les méthodes d'analyse et de conception orientées objet, étaient variées jusqu'à ce que Rambaugh, Jacobson et Booch eut l'idée de les unifier.

I.2.2 Les principes d'UP

Le processus unifié s'appuie sur les principes suivants :

> Piloté par les cas d'utilisation : Comme nous avons déjà vu, un cas d'utilisation représente une fonctionnalité qui satisfait un besoin d'un utilisateur.

Le processus suit une voie spécifique, en procédant par une série d'enchaînement d'activités, dérivées d'un cas d'utilisation. Un cas d'utilisation est analysé, conçu, implémenté et enfin testé.

> Centré sur l'architecture : L'architecture logicielle représente les aspects statiques et dynamiques du système. L'architecture émerge des besoins de l'entreprise, tels qu'ils sont exprimés par les utilisateurs et reflétés par les cas d'utilisation. L'architecture propose une vue d'ensemble de la conception faisant ressortir les caractéristiques essentielles en laissant de côté les détails secondaires. Il faut noter que tout produit est à la fois forme et fonction. L'une ou l'autre isolément ne saurait suffire. Les cas d'utilisation et l'architecture doivent s'équilibrer pour créer un produit réussi.

> Itératif et incrémental : Vu que les projets à réaliser sont de plus en plus complexes et grands, l'idée est de découper le travail en mini projets. Chacun d'entre eux représente une itération qui donne lieu à un incrément. Les itérations désignent des étapes de l'enchaînement d'activités, tandis que les incréments correspondent à des stades de développement du produit. [JBR99]

I.2.3 Les phases du processus unifié :

Le processus unifié se déroule en quatre phases, incubation, élaboration, construction et transition. Chaque phase répète un nombre de fois une série d'itérations. Et chaque itération est composée de cinq activités : capture des besoins, analyse, conception, implémentation et test. [JBR99]

Figure 2 : cycle de vie du processus unifié

1. Inception (Incubation):

C'est la première phase du processus unifié. Il s'agit de délimiter la portée du système, c'est-à-dire tracer ce qui doit figurer à l'intérieur du système et ce qui doit rester à l'extérieur, identifier les acteurs, lever les ambiguïtés sur les besoins et les exigences nécessaires dans cette phase. Il s'agit aussi d'établir une architecture candidate, c'est-àdire que pour une première phase, on doit essayer de construire une architecture capable de fonctionner. Dans cette phase, il faut identifier les risques critiques susceptibles de faire obstacles au bon déroulement du projet. [JBR99]

2. Elaboration :

C'est la deuxième phase du processus. Après avoir compris le système, dégagé les fonctionnalités initiales, précisé les risques critiques, le travail à accomplir maintenant consiste à stabiliser l'architecture du système. Il s'agit alors de raffiner le modèle initial de cas d'utilisation, voire capturer de nouveaux besoins, analyser et concevoir la majorité des cas d'utilisation formulés, et si possible implémenter et tester les cas d'utilisation initiaux.[JBR99]

3. Construction :

Dans cette phase, il faut essayer de capturer tous les besoins restants car il n'est pratiquement plus possible de le faire dans la prochaine phase. Ensuite, continuer l'analyse, la conception et surtout l'implémentation de tous les cas d'utilisation. A la fin de cette phase, les développeurs doivent fournir une version exécutable du système.[JBR99]

4. Transition :

C'est la phase qui finalise le produit. Il s'agit au cours de cette phase de vérifier si le système offre véritablement les services exigés par les utilisateurs, détecter les défaillances, combler les manques dans la documentation du logiciel et adapter le produit à l'environnement (mise en place et installation). [JBR99]

I.3 Réseau informatique I.3.1 Concepts réseau

Un réseau : Est un ensemble d'objets interconnectés les uns avec les autres. Il permet de faire circuler des éléments entre chacun de ces objets selon des règles bien définies.[CCM05]

Définition d'extranet

Un réseau extranet est un réseau du type internet, dont la liste de sécurité est externalisée c'est-à-dire gérée par un organisme ou une entité externe aux utilisateurs. Par opposition, pour un réseau intranet, la liste de sécurité est gérée en interne.

La liste de sécurité est l'ensemble des données regroupant les identifiants (nom d'utilisateur (login), adresse IP, adresses MAC, clefs logiques ou physiques) autorisés à se connecter.

Définition d'intranet

Un intranet est un ensemble de services internet (par exemple un serveur web) interne à un réseau local, c'est-à-dire accessible uniquement à partir des postes d'un réseau local, ou bien d'un ensemble de réseaux bien définis, et invisible de l'extérieur. Il consiste à utiliser les standards client-serveur de l'internet (en utilisant les protocoles TCP/IP), comme par exemple l'utilisation de navigateurs internet (client basé sur le protocoles HTTP) et des serveurs web (protocole HTTP), pour réaliser un système d'information interne à une organisation ou une entreprise.[CCM05].

Type des réseaux

On distingue différents types de réseaux (privés) selon leur taille (en terme de nombre de machines), leur vitesse de transfert des données ainsi que leur étendue. Les réseaux privés sont des réseaux appartenant à une même organisation. On fait généralement trois catégories de réseaux:

· LAN (Local Area Network)

· MAN (Métropolitain Area Network)

· WAN (Wide Area Network)

I.3.2 Présentation de l'architecture client/serveur

De nombreuses applications fonctionnent selon un environnement client/serveur, cela signifie que des machines clientes (des machines faisant partie du réseau) contactent un serveur, une machine généralement très puissante en terme de capacités d'entrée-sortie, qui leur fournit des services. Ces services sont des programmes fournissant des données telles que l'heure, des fichiers, une connexion, etc.

Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines clientes. On parle ainsi de client FTP, client de messagerie, ..., lorsque l'on désigne un programme, tournant sur une machine cliente, capable de traiter des informations qu'il récupère auprès du serveur (dans le cas du client FTP il s'agit de fichiers, tandis que pour le client messagerie il s'agit de courrier électronique). [CCM05]

I.3.2.1 Fonctionnement d'un système client/serveur

Un système client/serveur fonctionne selon le schéma suivant:

Figure 3 : Schéma de fonctionnement d'un système client/serveur

· Le client émet une requête vers le serveur grâce à son adresse et le port, qui désigne un service particulier du serveur

· Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client et son port.

I.3.3 Types d'architectures réseaux I.3.3.1 Architecture à 1-tiers

Dans une approche d'application de type 1-tiers, les trois couches sont fortement et intimement liées, et s'exécutent sur la même machine. Dans ce cas, on ne peut pas parler d'architecture client-serveur mais d'informatique centralisée.

Dans un contexte simple utilisateur, la question ne se pose pas, mais dans un contexte multiutilisateurs, on peut voir apparaître deux types d'architectures mettant en oeuvre des applications 1-tiers : des applications sur site central ; des applications réparties sur des machines indépendantes communiquant par partage de fichiers.

I.3.3.2 Architecture à 2-tiers

L'architecture à deux niveaux (aussi appelée architecture 2-tiers, tiers signifiant tierce partie) caractérise les systèmes clients/serveurs dans lesquels le client demande une ressource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir le service. [CCM05]

Interroger BD

BD

Requêtes

Niveau 2

Réponses

Niveau 1

Résultats

Client Serveur Base de données

Figure 4: Architecture à 2-Tiers

I.3.3.3 Architecture à 3-Tiers

Dans l'architecture à trois niveaux (appelée architecture 3-tiers), il existe un niveau intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée entre :

> Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une

interface utilisateur (généralement un navigateur web) chargée de la présentation; > Le serveur d'application (appelé également middleware), chargé de fournir la

ressource mais faisant appel à un autre serveur

> Le serveur de données, fournissant au serveur d'application les données dont il a besoin.

Requêtes Requêtes

Niveau1

Client

Niveau2

Serveur d'application

Niveau3

Serveur de BD

Résultats

Résultats

BD

Figure 5: Architecture 3-Tiers

. Les niveaux de l'architecture 3-tiers

1) Client

Dans un réseau informatique un client est l'ordinateur et le logiciel qui envoient des demandes à un serveur. L'ordinateur client est généralement un ordinateur personnel ordinaire, équipés de logiciels relatifs aux différents types de demandes qui vont être envoyées, comme par exemple un navigateur web, un logiciel client pour le World Wide Web.

2) Serveur

Dans un réseau informatique, un serveur est à la fois un ensemble de logiciels et l'ordinateur les hébergeant dont le rôle est de répondre de manière automatique à des demandes envoyées par des clients ordinateur et logiciel via le réseau.

Les serveurs sont d'usage courant dans les centres de traitement de données, les entreprises, les institutions, et le réseau Internet, où ils sont souvent un point central et sont utilisés simultanément par de nombreux utilisateurs pour stocker, partager et échanger des informations. Les différents usagers opèrent à partir d'un client: ordinateur personnel, poste de travail, ou terminal.

Le World Wide Web, la messagerie électronique et le partage de fichiers sont quelques applications informatiques qui font usage de serveurs.

3) Serveur de base de données

Lorsque le nombre d'enregistrements par table n'excède pas le million, et que le nombre d'utilisateurs varie de une à quelques personnes, un micro-ordinateur actuel de bonnes performances, un logiciel système pour poste de travail, et un SGBD "bureautique" suffisent.

Si ces chiffres sont dépassés, ou si le temps de traitement des données devient prohibitif, il faut viser plus haut. Le micro-ordinateur doit être remplacé par un serveur de BDD, dont les accès aux disques durs sont nettement plus rapides. Le logiciel système client doit être remplacé par un logiciel système serveur (donc multiutilisateurs), et le SGBD bureautique par un SGBD prévu pour les grosses BDD multi-clients.

Ceci dit, la structure d'une grosse base n'est pas différente de celle d'une petite, et il n'est pas nécessaire de disposer d'un "mainframe" (une grosse machine) gérant des milliers de milliards d'octets pour apprendre à se servir des BDD. Ce n'est pas parce qu'il gère un plus grand volume de données qu'un SGBD possède plus de fonctionnalités.

. Limites de l'architecture 3-tiers

L'architecture trois-tiers a corrigé les excès du client lourd en centralisant une grande partie de la logique applicative sur un serveur HTTP. Le poste client, qui ne prend à sa charge que la présentation et les contrôles de saisie, s'est trouvé soulagé et plus simple à gérer.

En revanche, le serveur HTTP constitue la pierre angulaire de l'architecture et se trouve souvent fortement sollicité : il est difficile de répartir la charge entre client et serveur. On se retrouve confronté aux épineux problèmes de dimensionnement serveur et de gestion de la montée en charge rappelant l'époque des mainframes. De plus, les solutions mises en oeuvre sont relativement complexes à maintenir et la gestion des sessions est compliquée, mais reste possible.

Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures deux-tiers : le client est soulagé, mais le serveur est fortement sollicité.

Le juste équilibre de la charge entre client et serveur semble atteint avec la génération suivante : les architectures n-tiers.

I.3.3.4 Comparaison entre l'architecture 2-tiers et 3-tiers

L'architecture à deux niveaux est donc une architecture client/serveur dans laquelle le serveur est polyvalent, c'est-à-dire qu'il est capable de fournir directement l'ensemble des ressources demandées par le client.

Dans l'architecture à trois niveaux par contre, les applications au niveau serveur sont délocalisées, c'est-à-dire que chaque serveur est spécialisé dans une tâche (serveur web/serveur de base de données par exemple). L'architecture à trois niveaux permet :

· Une plus grande flexibilité/souplesse ;

· Une sécurité accrue car la sécurité peut être définie indépendamment pour chaque service, et à chaque niveau.

· De meilleures performances, étant donné le partage des tâches entre les différents serveurs.

I.4 Services web

I.4.1 Définition des services web

Les services web sont des applications auto descriptives, modulaires et faiblement couplées qui fournissent un modèle de programmation et de déploiement d'applications, basé sur des normes, et s'exécutant au travers de l'infrastructure web.

Un service web est un composant implémenté dans n'importe quel langage, déployer sur n'importe quelle plate forme, afin qu'el soit recherché et invoqué par d'autres services grâce à des standards (SOAP, WSDL et UDDI).

Un service web est une unité de logique d'application qui fournit des données, et des services aux autres applications, les applications accèdent aux web services via des protocoles, et des formats de données omniprésentes telles que HTTP, XML et SOAP.

En terme général, les services web sont des composants d'applications distribuées qui se forment à des standards permettant de les rendre publique, et de résoudre les problèmes d'interopérabilité entre les applications hétérogènes.

I.4.2 Les standards et l'architecture des services web

En terme général l'architecture des services web est une architecture interopérable, c'est-à-dire qu'elle identifie les éléments globaux d'un service web global qui sont nécessaires pour assurer une interopérabilité entre services. La figure suivante représente l'architecture de référence de services web, et les standards utilisés :

	DECOUVERTE DU SERVICE
							UDDI Statique
	PUBLICATIO N DU SERVICE
		DESCRIPTION DU SERVICE
		MESSAGE BASE SUR XML
		TRANSPORT/RESEAU					UDDI
							Direct

Figure 6 : Architecture de référence des services web

I.4.3 L'infrastructure des services web

Les services web assurent à travers le réseau internet, l'interaction entre les applications, les ordinateurs et les processus métiers selon l'infrastructure suivante :

> Le protocole HTTP (HyperText transfert Protocol) > Protocole SOAP (Simple Object Access Protocol)

> UDDI (Universal Description Discovery and Integration) > Langage WSDL (Web Services Description Langage)

I.4.4 Caractéristiques techniques des services web

En plus de l'infrastructure standard, les services web sont caractérisés par d'autre technologies telle que la possibilité d'être découverts et invoquer par d'autre services et applications distantes une fois déployés ; la répartition en plusieurs serveurs ; accessibilité depuis n'importe quel type de client (WAP, Web, Applicatif) et la possibilité de servir au développement d'autre applications distribuées. On parle aussi d'une implémentation sous forme d'application autonome ou répartie en plusieurs applications dont la communication et l'interaction entre elles se fait par l'échange de messages XML à l'aide des protocoles web (HTTP, SMTP, FTP).

Conclusion

A l'issu de ce chapitre, nous nous sommes familiarisé avec l'outil de modélisation UML d'une part et d'autre part, avec la démarche du processus de développement logiciel (Processus Unifié) qui va nous guider dans la réalisation des prochaines étapes de notre projet.

Toutes les applications finies fondées sur les bases de données sont entièrement logées dans au moins une architecture réseau. Si de plus, ces applications sont dédiées au web, l'exploitation de ses services est alors indispensable.

«La science La science consiste à passer
d'un étonnement à un autre''
[Aristote]

Introduction

La gestion des stocks au sein de l'Université de Bejaïa est une opération rigoureuse, qui mérite d'être perfectionnée et analysée soigneusement ; mais avant d'essayer 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 de la Faculté des Sciences Exactes en particulier est nécessaire, et c'est ce qui est conseillé d'ailleurs dans toute démarche informatique de Génie Logiciel. Toute fois, il est important de signaler à l'attention qu'afin de mieux réaliser les prochaines étapes de notre plan de travail, la spécification et la précision de notre sujet et champ d'étude doivent être bien comprises, cernées et clarifiées.

II.1Présentation de l'organisme d'accueil II.1.1Historique de l'université de Bejaia

L'université de Bejaia a été crée à la faveur de la décentralisation initiée au début des années 80 pour désengorger les pôles universitaires d'Alger, Constantine, Tizi-Ouzou et de Sétif. Bien que née tardivement (1983) par rapport à son passé scientifique et culturel de renom, l'Université de Bejaia, établissement public de formation supérieure sous tutelle du Ministère de l'Enseignement Supérieur et de la Recherche Scientifique, a pu s'agrandir et passer d'un effectif de 205 étudiants encadrés par 40 enseignants à son ouverture à un effectif de 22 792 étudiants et 698 enseignants en 2006.

Cet essor n'a pu se réaliser qu'avec une diversification judicieuse de ses filières et options. L'Université de Bejaia regroupe quatre Facultés (Faculté des Sciences exactes, Faculté de technologie, Faculté de science de la nature et de la vie, faculté de droit, faculté des lettres et des sciences humaines, faculté des sciences économiques, sciences de gestion et sciences commerciales et faculté de médecine). Elle se déploie sur deux sites principaux (Targa Ouzemmour et Aboudaou). L'Université de Bejaia dispose d'une bibliothèque centrale pluridisciplinaire, d'une annexe opérationnelle depuis 2002 et d'une bibliothèque au campus d'Aboudaou ouverte en 2003. Elle couvre plus de 35 spécialités avec un fond documentaire riche et dépassant en ouvrage 146 000 volumes, 2500 titres de thèses et mémoires, 300 titres de revue dont 79 en cour d'abonnement et environ 400 CD ROM. La diversification de filière de formation, la valorisation de la recherche et le transfert de compétences lui ont permis d'être parmi les universités les plus performantes du pays.

Devant l'importance grandissante de l'informatique dans les domaines de la vie courante et sa large utilisation dans toutes les filières (technologie, économie, médecine, etc.), l'ouverture de cette spécialité est devenue indispensable. La volonté et le dynamisme des différents responsables ont conduit à l'ouverture d'une Ecole Doctorale en Informatique option Réseaux et Systèmes Distribués : c'est la première du genre dans le pays. L'université de Bejaia, à l'instar des autres établissements de l'enseignement supérieur, a mis en place le nouveau dispositif d'enseignement LMD des la rentrés 2004/2005, avec comme première étape une proposition de 33 licences dont 19 professionnelles et 14 académiques.

II.1.2 L'historique de la faculté des Sciences Exactes

La faculté des Sciences Exactes est créée par le décret exécutif n°07 - 271du 11 Septembre 2007 modifiant et complétant le décret exécutif n°98 - 218 du 7 Juillet 1998 portant création de l'université Abderrahmane MIRA de Bejaïa.

II.1.3 L'organigramme de la Faculté des Sciences Exactes

D.I

S.B.C

Ch.S.1

Ch.S.2

Ch.S.3

D.C

S.A.S

V.D.1

F.S.Exactes

D.P

Le SG

Service des moyens et
de la maintenance

Section de la
maintenance

Section des
moyens

V.D.2

D.RO

Ch.S.4

Ch.S.6

Ch.S.5

S.P.A

S.P.E

S.P

D.M

Figure 7 : Organigramme de la Faculté des Sciences Exactes

Liste d'abréviations :

F.S.E : Faculté des Sciences Exactes.

V.D.1 : Vice doyen chargé des études et questions liées aux étudiants.

V.D.2 : Vice doyen chargé de la post graduation, de la recherche scientifique et des relations extérieures

Ch.S.1 : Chef de service de la scolarité.

Ch.S.2 : Chef de service Chef de service des enseignants et de l'évaluation. Ch.S.3 :Chef de service des statistiques de l'information et de l'orientation. Ch.S.4 :Chef du suivi de la formation de pst graduation.

Ch.S.5 : Chef de service du suivi des activités de recherche.

Ch.S.6 : Chef de service de la coopération et des relations extérieures. Le SG : Le secrétariat général.

S.B.C : Vice du budget et de la comptabilité.

S.A.S : Service de l'animation, scientifique, culturelle et sportive. S.P : Service des personnels.

S.P.E : Section des personnels enseignants.

S.P.A : Section des personnels administratifs, techniques.

D.I : Département informatique.

D.C : Département Chimie

D.P : Département physique.

D.RO : Département de recherche opérationnelle.

D.M : Département math.

II.1.4 Les missions de la Faculté des Sciences Exactes

La faculté des Sciences Exactes de l'Université Abderrahmane Mira de Bejaïa se caractérise par un fort potentiel d'encadrement aussi bien en graduation qu'en post graduation. La volonté politique de la faculté des Sciences Exactes est de développer l'accueil d'étudiants et enseignants nationaux et étrangers, d'aider à la mobilité des étudiants et enseignants chercheurs de la Faculté dans le cadre de conventions interuniversitaires et de les faire participer aux différents projets. Ces missions sont :

v' La formation de cadres (Graduation et post graduation).

v' Enrichissement et transmission des connaissances au sein de ses départements d'enseignement.

v' Participation aux activités de recherche grâce au dynamisme de ses laboratoires.

II.1.5 Présentation du service d'accueil

Le service des moyens et maintenance de la faculté des sciences exactes se subdivise en deux structure: service de maintenance et service des moyens généraux auquel est lié le magasin de la faculté, dans lequel on a effectué notre stage.

II.1.5.1 L'effectif du magasin

Le magasinier de la Faculté des Sciences Exactes est la seule personne qui gère le magasin, disposant d'un nombre important de fournitures qui augmentent en fonction des besoins de la faculté.

II.1.5.2 Missions du magasinier

Le magasinier est chargé d'effectuer les taches suivantes :

> Signature des documents.

> Suivre les mouvements du magasin (entrées et sorties).

> Recevoir les commandes des demandeurs (services, départements)

> Etablir des situations et états du stock.

> Suivi des fiches de stocks relatifs à chaque fourniture du magasin.

> Etablissement d'inventaire et tenue d'inventaire physique.

> Accorder au service demandeur des quantités de produit.

> Faire des traitements de suivie effectif de la marchandise livrés se sa réception jusqu'au service fait (établir un bon d'entrée, mentionne de la marchandise dans le registre d'entrée et d'inventaire).

> Etablir le bilan mensuel des produits en stock.

II.1.5.3 Situation informatique :

Le service des moyens généraux de la faculté des Sciences Exacte dispose d'un matériel informatique assez important.

Ce matériel est constitué de 3 ordinateurs HP ayant les caractéristiques suivants:

· Processeur Intel(R) pentium(R) Dual, vitesse d'horloge : 2.0 GHz.

· Capacité mémoire 128 à 512 Mo de RAM.

· Capacité de disque dur est de 160 Go.

· Un système d'exploitation Vista à 32 bits.

· Écrans de 15» et 19».

Deux (02) imprimantes :

· Imprimante simple de marque HP LaserJet 1018 : 18 pages/minutes.

· Imprimante photocopieuse d'une marque Canon IR 2018.

Un réseau intranet.

La suite bureautique de Microsoft est utilisée pour les traitements de textes, les bons de commande et les fiches de stocks.

II.2 Contexte du système

Pour concevoir et réaliser le système logiciel de gestion de stock de magasin de la Faculté des Sciences Exactes, il nous était indispensable de collecter les informations nécessaires auprès des spécialistes du domaine. Après avoir structuré les informations collectées, nous avons remarqués que presque tout, se déroule autour de deux opérations principales qui sont :

> L'arrivée des produits facturés par le fournisseur.

> L'arrivée du bon de commande interne établi par un service demandeur.

Nous allons présenter le parcours du traitement de ces opérations de l'arrivée du bon de commande interne ou de la facture auprès du magasinier jusqu'à leurs accomplissements.

II.2.1Circuit du déroulement des activités relatives à la facture

A l'arrivée de la facture du fournisseur, ainsi que la marchandise commandée, le magasinier procède comme suit:

Il vérifie tout d'abord la conformité de la marchandise conformément au bon de commande ; ensuite le magasinier enchaine avec ces deux opérations:

1. Etablir un bon d'entrée (bon de réception) sur lequel il saisit son numéro et sa date d'établissement. Par la suite, il note dans chaque ligne de bon: la désignation du produit réceptionné, le numéro de facture (ou bon de livraison), date de réception, le nom du fournisseur et enfin la quantité livrée.

2. Enregistrer les produits réceptionnés dans deux registres différents ; il s'agit du registre d'entrée et celui d'inventaire. Le premier sert à enregistrer tous les produits réceptionnés étant consommables ou non consommables, en mentionnant la désignation des produits, le numéro de la facture, etc. Le deuxième sert à enregistrer uniquement les produits non consommables en mentionnant les mêmes informations du registre d'entrée en rajoutant pour chaque produit un numéro d'inventaire.

NB : Lorsque le stock de sécurité d'un (des) produit(s) est atteint, le magasinier informe le Service des Moyens Généraux.

Ces enchainements d'activités et traitements sont formalisées par le diagramme d'activité d'UML suivant :

Magasinier

Service des moyens généraux

Fournisseur

[Produit en rupture] [Sinon]

Attendre la rupture de produit en stock

Bon de cmd EXt reçu

Livrer produit

Envoyer le bon de cmd EXt

Etablir une facture

Faire une commande

Envoyer la facture

Recevoir le produit

Recevoir le bon de commande externe

Recevoir la facture

Sinon

Demande de renvoyer des produits conformes à ce qui a été mentionné

Etablir un bon d'entrée

Enregistrer les produits consommables et non consommables dans le registre d'entée

Enregistrer les produits dans le registre d'inventaire

II.2.2 Circuit du déroulement des activités relatives au bon de commande interne:

Les services appartenant à la faculté peuvent commander des produits au Magasin en établissant un bon de commande (interne) qui sera adressé au magasinier.

En effet, à l'établissement du bon de commande (interne) le demandeur motionne le numéro de bon de commande, la date de l'établissement, son nom, son prénom, sa fonction ; en suite il mentionne les produits à demander en précisant pour chacun : la désignation du produit et la quantité demandée. Et, il l'envoi au magasinier, signé par le responsable de sa structure. A la réception, le magasinier traite la commande selon l'état de stock, et il affecte pour chaque produit demandé une quantité à accorder (<= quantité demandée), et qui sera servie une fois eu l'avis favorable du doyen. A la livraison des produits, le magasinier établit un bon de sortie qu'est caractérisé par la quantité servie (qui peut être différente de la quantité demandée si le demandeur fait un retard pour ramener l'accord au doyen car durant cette période la quantité en stock peut varier), le numéro d'inventaire si le produit servi n'est pas consommable et une observation.

Et pour les suivis de l'état de stock, le magasinier assigne pour chaque produit une fiche de stock.

Ces successions d'activités sont formalisées par le diagramme d'activité suivant :

Magasinier

Demandeur

Doyen

Faire une commande

favorable]

Sinon

Recevoir le bon de commande interne

Renvoyer le bon de commande interne

Envoyer une copie

Etablir un bon de sortie

Envoyer le bon de sortie

Recevoir produit

Copie de bon de commande reçue

Copie de bon de sortie reçue

Figure 9 : Diagramme d'activité relatif au bon de commande interne

II.2.3 Diagnostic de la situation actuelle

Apres avoir fini l'étude de contexte du domaine d'étude lié au magasin de la Faculté des Sciences Exactes, nous avons approfondi la compréhension du fonctionnement du système actuel. A présent, il nous est possible d'établir un diagnostic sur les trois plans : technique, organisationnel et informationnel.

Plan	Anomalies		Suggestions	Technique
Capacité de stockage limité a cause de la surface réduite à 200 m2	Agrandissement de l'espace alloué au magasin en ajoutant des salles de stockage.		Organisationnel
Mauvaise répartition des taches, ce qui rend la procédure de travail très lente pour le magasinier.	Faire une meilleure attribution des taches à travers un partage plus équitable du travail		Informationnel
Lorsque le stock du magasin est en rupture, le magasinier transmet ses besoins au service des moyens généraux par le biais d'un document non structuré.	Utilisation d'un bon de commande structuré pour l'expression de ses besoins auprès du service des moyens généraux.

Tableau 1: anomalies et suggestions

II.3 Problématique

Le système d'information actuel de l'Université de Bejaia et plus particulièrement le magasin de la est non encore automatisé, toute fois les taches et procédures administratives de l'organisation qui contrôle et traite les mouvements du stocks sont manuelles, ce qui rend la tache du magasinier fastidieuse et complexe et ne peut entièrement les assumer. La fatigue, l'oubli et l'erreur ont de grandes répercutions sur la qualité du travail et par conséquent, un effet négatif sur les résultats attendus de l'organisation.

II.4 Propositions

Propositions

Après avoir analysé le contexte du système actuel, nous avons suggérés au responsable du magasin un ensemble de propositions et solutions informatiques pouvant remédier aux différentes lacunes soulevées durant notre stage.

Le tableau suivant récapitule ces propositions:

Propositions		Description textuelle de la proposition	1
Conception et réalisation d'une application monoposte.		2
Conception et réalisation d'une application client/serveur .		3
Conception et réalisation d'une application à trois niveaux .

Tableau 2 : Propositions et solutions informatiques

Notre choix s'est porté sur la 3^ème proposition, vu que le futur système à concevoir doit être d'une part, accessible par:

- Les différentes structures Départementales liées à la Faculté.

- Le magasinier de la faculté qui est l'acteur principal du système, aura tous les privilèges sur la base de données.

Et d'autre part, par la disponibilité d'un réseau intranet au sein de l'Université de Bejaia possédant des services informatiques de qualité.

La deuxième proposition aurait pu être exploitée. Néanmoins, nous avons préférés la troisième à cause de ses avantages et performances (voir généralités).

II.5 Objectifs

Les objectifs de la solution que nous avons adoptés sont cités ci-dessous :

> Amélioration et simplification du travail administratif :

On confie à l'ordinateur les procédures lourdes, complexes et répétitives de l'organisation.

Tache	S.I. Manuel		S.I. Automatisé	Stocker une grande masse d'information (facture, bons de commandes internes, bons de sorties, bon d'entrées, etc.).
Sur des fiches dans un carton · Encombrant · Risque de détérioration. · Difficile de faire plusieurs copies.	Sur un disque · Espace réduit. · Possibilité de faire plusieurs copies. · Sécurité de l'information.		Accès à l'information (rechercher la facture d'une ancienne date).
Recherche manuelle. Facture par facture (lente).	La machine effectue une recherche rapide et instantanée pour l'utilisateur.		Traitement (établir une fiche de l'état de stock, par produit ou par service ou par période).
· Difficile et risque d'erreur. · Traitement lent.	Calcul automatique sans risque d'erreur.
Stockage des produits	Stockage désordonné des produits		Classification des produits appartenant a une même famille dans un même emplacement
Codification	Absence de codification		Adopter une codification pour les produits.

Tableau 3 : Comparaison des deux SI manuel et automatisé

> Aide à la décision:

L'évaluation des chiffres de l'état de stock par produit ou les quantités consommé par service

dans une période spécifique, donnera aux responsables un meilleur pilotage du système et de minimiser les pertes, on prenant de bonne décision sur les quantités des produits à commander en fonction du taux de consommation des services pour chaque produit.

II.6 Diagramme du contexte

Au cours de cette étape nous allons réaliser le diagramme de contexte. L'application est considérée comme étant une boite noire qui interagit avec les déférents acteurs. Des liens relient l'application à chacun des acteurs sur lesquels sont montrés les messages en entrée et en sortie de l'application.

Avant de présenter le diagramme du contexte, l'identification des acteurs communiquant avec le système ainsi que les messages qui transitent de part et d'autre est indispensable.

II.6.1 Identification des acteurs

Dans cette étape, nous allons identifier les différents acteurs qui interagiront avec l'application.

Le magasinier : peut consulter l'état du stock, gérer les bons de sorties et les bons d'entrées, établir les bons de commandes internes et les bons d'entrées ainsi que les bons de sortie, et enfin mettre à jour l'état du stock, des produits et leurs familles correspondantes, des fournisseurs avec lesquels traitent et les services qui s'attachent au Magasin de la faculté.

Le service demandeur : peut consulter l'état du stock, établir et éditer les bons de commandes internes.

II.6.2 Identification des messages

Un message est une information envoyée par un émetteur dont le but de déclencher une activité chez le récepteur. Voici la liste des messages échangés entre l'application et ses acteurs :

Messages envoyés acteur système	Messages réponses système acteur
M1 : Authentification.	M2 : Interface d'authentification.
M3 : Consultation de l'état du stock.	M4 : Interface de consultation adéquate.
M5 : Gérer les bons de sortie.	M6 : Interface gérer les bons de sorties.
M7 : Gérer les bons d'entrées.	M8 : Interface gérer les bons d'entrées.
M9 : Editer un bon de commande interne.	M10 : Interface éditer un bon de commande interne.
M11 : Editer un bon de sortie	M12 : Interface éditer un bon de sortie.
M13 : Mettre à jour emplacements des produits.	M14 : Interface de mise à jour adéquate.
M15 : Mettre à jour les fournisseurs.	M16 : Interface de mise à jour adéquate.
M17 : Mettre à jour les services.	M18 : Interface de mise à jour adéquate.
M19 : Mettre à jour les produits.	M20 : Interface de mise à jour adéquate.
M21 : Mettre à jour les familles des produits.	M22 : Interface de mise à jour adéquate.

Tableau 4: tableau des messages en interaction

M22,M20,M19,M16,M14,M12,M10,M8,M6,M4,M2

M21,M19,M17,M15,M13,M11,M9,M7,M5,M3,M1

M3, M1

M5, M2

Service demandeur Magasinier

Figure 10 : diagramme de contexte

Conclusion

Cette première phase du Processus Unifié nous a permis non seulement d'avoir une vue détaillée de l'état actuel de l'organisme d'accueil, mais aussi de nous familiariser avec les différentes activités et traitements qui se font au sein de magasin. Il faut noter que le diagramme de contexte réalisé au niveau de cette étape nous a donné déjà un premier aperçu sur l'application à concevoir, ouvrant ainsi la porte à la deuxième étape du Processus Unifié intitulé «Analyse des besoins », que nous allons détailler dans le prochain chapitre de notre mémoire.

«On fait la science avec de faits, comme
onfait une maison avec des pierres :
mais une accumulation de
fait n'est pas plus une science qu'un

tas de pierres n'est une ^maison»[Henri Poincaré]

Introduction

L'étape de l'analyse des besoins est la deuxième phase de cycle de vie du Processus Unifié et 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 devra être refaite, 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.

III.1Modèle du système

Le système à concevoir est régi par une application web dynamique qui sera accessible via le réseau intranet de l'Université, permettant ainsi un accès aux différents services souhaitant solliciter le magasin.

De ce fait, les acteurs interagissant avec l'application sont :

> Le magasinier: l'administrateur de l'application.

> Les services demandeurs: utilisateurs ayant un accès limité à l'application.

Les principales fonctionnalités de l'application à concevoir sont érigées autour des besoins et exigences des différents acteurs. Elles sont illustrées dans le diagramme du cas d'utilisation de la gestion du stock suivant :

Service demandeur

Use case gestion des stocks

Editer un bon de commande interne

Etablir un bon de commande interne

Edition

Gérer les bons de sorties

Gérer les bons d'entrées

Include

Include

Mettre a jour la base de donnée

Include

Include

Consulter le stock

Authentification

Include

Include

Magasinier

Figure 11 : Diagramme du cas d'utilisation gestion des stocks Description des différents cas d'utilisation

> Authentifier : Permet à un acteur de s'authentifier avant d'accéder à l'application. > Consulter le stock: Permet aux différents acteurs d'avoir une consultation sur les différentes fournitures du magasin.

> 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 : l'ajout, 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, la modification et la suppression.

> Editions: Permet aux différents acteurs, selon leurs droits d'accès, d'éditer
différents documents (bon de commande interne, bon de sortie, bon d'entrée).

> Mise a jour de la base de donnée : Permet au magasinier de mettre a jour sa base de donnée. Cette mise a jour concerne : les fournisseurs, les services, les produits, les emplacements et les familles des produits.

III.2 Besoins fonctionnels et non fonctionnels

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.

Nous présentons dans ce qui suit tous les besoins fonctionnels classés par acteurs ainsi que les besoins non fonctionnels du système.

Afin d'éviter d'alourdir le diagramme de cas d'utilisation nous avons préférer de l'organiser en paquetages.

III.2.1Besoins fonctionnels

Les services attendus de l'application sont décris par les packages suivants:

Extend

Ajouter

Gérer les bons de sorties

Extend

Extend

Modifier

Include

Supprimer

Authentification

Magasinier

Figure 12: package du cas d'utilisation gérer les bons de sorties Description textuelle des cas d'utilisations

- Ajouter un bon de sortie: Lorsqu'un demandeur se présente au magasinier muni
d'un bon de commande interne signé par le doyen, un bon de sortie lui est établi.

- Modifier un bon de sortie: Un bon de sortie doit être modifiable, le magasinier peut se tromper en remplissant les informations communiquées, la modification de l'erreur est envisagée.

- Rechercher un bon de sortie : Toute opération de mise à jour (modification ou suppression) d'un bon de sortie doit être précédée par une opération de recherche. Le critère de recherche demandé est le numéro du bon de sortie.

- Supprimer un bon de sortie: Le système doit offrir au magasinier la possibilité de supprimer un bon de sortie lorsque le demandeur remet les produits qui lui étaient déjà livrés.

<<Extend>>

Ajouter

Gérer les bons d'entrées

<<Extend>>

<<Extend>>

Modifier

<<Include>>

Supprimer

Authentification

Magasinier

Figure 13: package du cas d'utilisation gérer les bons d'entrées Description textuelle des cas d'utilisation

- Ajouter un bon d'entrée : Ce cas d'utilisation donne au magasinier la possibilité d'ajouter un bon d'entrée.

- Modifier un bon d'entrée : Un bon d'entrée doit être modifiable, le magasinier peut se tromper en remplissant les informations communiquées, la récupération de l'erreur est envisagée.

- Rechercher un bon d'entrée : Toute opération de mise à jour (modification ou suppression) d'un bon d'entrée doit être précédée par une opération de recherche. Le critère de recherche demandé est le numéro du bon d'entrée.

- Supprimer un bon d'entée : Le magasinier peut être amené à supprimer un bon d'entrée déjà établi.

Magasinier

<<Include>>

Authentification

<<Extend>>

Editions Edition bon d'entrée

<<Extend>>

Edition bon de sortie

Figure 14 : package du cas d'utilisation édition

Description textuelle des cas d'utilisation

- Edition de bon d'entrée : Permet d'imprimer un bon d'entrée. - Edition de bon de sortie : Permet d'imprimer un bon de sortie.

Figure 15: Package du cas d'utilisation mettre a jour la base de donne

Description textuelle du cas d'utilisation

Les opérations d'ajout, de modification et de suppression sont communes à tous les cas d'utilisation de la mise a jour de la base de données.

- Ajouter : Le système permet au magasinier d'ajouter des produits, des

fournisseurs, des services, des emplacements et des familles de produits.

- Modifier: Le système offre la possibilité de modifier les informations des

différentes entités manipulées par le système.

- Supprimer: Le système offre la possibilité au magasinier de supprimer les différentes entités crées.

III.2.2 Besoins non-fonctionnels

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.

III.3 La démarche du prototypage

Dans le but d'inciter l'utilisateur à nous fournir une information efficace, nous avons adopté la démarche de prototypage. Le prototypage motive les spécialistes du domaine à nous livrer des informations. Dans ce qui suit, nous présentons quelques prototypes des interfaces réalisées au cours de cette phase.

Il faut noter que les interfaces prototypes peuvent ne rien avoir avec les interfaces du futur système.

> Prototype de l'interface-homme machine gestion des entrées

Figure 16: Interface gestion des entrées

> Prototype de l'interface-homme machine gestion des sorties

Figure 17: Interface gestion des sorties

> Prototype de l'interface homme-machine gestion des produits

Figure 18 : Interface gestion des produits

III.4 Réalisation des diagrammes de séquences

III.4.1 Diagramme de séquence du cas d'utilisation authentifié

Description textuelle du scénario

Lorsque un utilisateur souhaite accéder à sa session, une page d'accueil lui sera affichée, dans laquelle saisit ses propres coordonnées d'authentification (login et mot de passe).par la suite le système procède a la vérification des informations introduites, si le login et le mot de passe sont valides sa session lui sera alors ouverte, sinon un message d'erreur est affiché le sollicitant de réintroduire ses coordonnées. Ce processus de vérification ce répétera autant de fois que l'utilisateur communique des informations erronées.

: Utilisateur

: Système

Demande_page_d'accueil ()

Affichage de la page d'accueil

loop

Authentifier (login, mot de passe)

[Login ou mot de passe incorrect]

Vérification

Alt

[Mot de passe et login sont valide]

Ouverture de la session

[Mot de passe et login non valides]

Message d'erreur

Figure 19 : Le diagramme de séquence du cas d'utilisation authentifier

III.4.2 Diagramme de séquence du cas d'utilisation ajouter un produit Description de textuelle du scénario

Le magasinier demande au système l'ajout d'un nouveau produit à travers l'interface appropriée. Le système lui demande alors de fournir les informations suivantes : « la référence du produit, désignation, le type, le stock minimum, la famille et l'emplacement.

	:Formulaire BS		:Demandeur				: Bon de sortie	: FLBS
					:BCI
: Magasinier

Alt

Alt

[Pas d'erreur]

[Erreur saisie]

[Sinon]

[Sinon]

Afficher le formulaire BS

Sélectionner le numéro de BCI

Préciser la date de BS et valider

Demande d'ajout un bon de sortie

Sélectionner le demandeur

Signaler l'erreur

BS enregistré

Signaler l'erreur

Vérifier saisie

Numéroter le BS

Enregistrement LBS Ok

Ajouter LBS

Enregistrer BS

Numéroter le BS

Ajouter LBS

Le système procède alors à la vérification des différentes informations fournies au clavier puis déclenche le contrôle d'intégrité de la référence du produit. En cas d'absence d'erreur, l'enregistrement sera effectué, sinon toute erreur sera signalée.

Alt

Alt

: Magasinier

[Sinon]

[Référence produit existe]

[Erreur de saisie]

Sélectionner la famille du produit

Sélectionner l'emplacement du produit

Demande d'ajout d'un produit

Saisir la référence, désignation, type, stock min et valider

Afficher le formulaire

[Sinon]

Signaler l'erreur

Signaler l'erreur

Le produit est enregistré

: Formulaire

Vérifier l'existence

Vérifier la saisie

: Famille

: Emplacement

: Produit

Contrôler l'existence

Figure 20 : Diagramme de séquence du cas d'utilisation ajouter un produit

III.4.3 Diagramme de séquence du cas d'utilisation modifier un produit

Description textuelle du scénario

Le magasinier sollicite du système la modification des propriétés d'un produit. Le système demande d'abord de préciser la référence du produit à modifier puis procède à la recherche de son existence. S'i n'est pas trouvé, le système signalera au magasinier que « ce produit n'existe pas ».Sinon, il fournira la fiche descriptive au magasinier qui commencera à opérer ses modifications puis validera ses saisies en appuyant sur le bouton approprié. Le système contrôle alors les nouvelles informations et s'il n'y a pas d'erreurs, il enregistra la modification. Sinon toute erreur sera signalée.

Alt

Alt

: Magasinier

[Erreurs de données]

Signaler l'erreur

[Sinon]

[Le produit existe]

[Le produit n'existe pas]

Afficher le formulaire

Demande de modification d'un produit

Saisir la référence du produit et valider

Afficher le formulaire de modification

Saisir les modifications et valider

Les modifications sont enregistrées

Signaler l'erreur

: Formulaire

Vérifier les modifications

Retourner les données du produit

Rechercher le produit

Produit non trouvé

: Produit

Rechercher le produit

Vérifier les modifications

Figure 21 : Diagramme de séquence du cas d'utilisation modifier un produit

III.4.4 Diagramme de séquence du cas d'utilisation supprimer un produit Description textuelle du scénario

Le magasinier demande au système la suppression d'un produit. Le système lui demande d'abord de préciser la référence du produit à supprimer puis il procède à la recherche de son existence. Il signalera au magasinier si le produit en question n'a pas été trouvé, sinon il fournira la fiche descriptive affichée à l'écran : le magasinier doit alors confirmer l'opération de suppression. Ensuite, le système doit contrôler si le produit en question n'est pas référencié dans d'autre classe du système. En effet il ne supprimera le produit que si sa trace n'est retrouvée nulle part ailleurs, sinon la suppression sera annulée.

Alt

Alt

[Sinon]

[Le produit existe]

[Le produit n'existe pas]

[Suppression impossible]

Afficher le formulaire de la suppression

Valider la suppression

La suppression est impossible

Signaler l'erreur

produit supprimé

Retourner les données du produit

Demande de suppression

Produit non trouvé

Vérifier si la suppression est possible

Demande de suppression d'un produit

Afficher le formulaire

Saisir la référence du produit et valider

Demande la recherche du produit

Rechercher produit

: Magasinier

: Formulaire

: Produit

Figure 22: Diagramme de séquence du cas d'utilisation supprimer un produit

III.4.5 Diagramme de séquence du cas d'utilisation ajouter un bon de sortie Description textuelle du scénario

Le magasinier demande l'ajout d'un nouveau BS (bon de sortie). Le système lui demande de préciser les informations suivantes : « la date du BS, le nom de demandeur et le numéro du BCI (bon de commande interne) associé au BS ». Le système déclenche alors le processus d'ajout d'une ligne de BS. Ce procédé se répétera autant de fois que le magasinier voudra ajouter de ligne.

Figure 23 : Diagramme de séquence de cas d'utilisation ajouter un bon de sortie

NB : FLBS signifie formulaire de ligne du bon de sortie.

Le diagramme de séquence suivant décrit la séquence d'interaction ajouter lignes du

BS :

: Magasinier	: Formulaire LBS		: LBS		: Produit

Alt

Alt	[Quantité servie > Quantité en stock] Signaler l'erreur
	[Sinon] Enregistrement ligne	Enregistrer LBS

[Sinon]

[Erreur de saisie]

Signaler l'erreur

Contrôler quantité servie

Retourner quantité en stock

Demande quantité en stock

Contrôler
contrainte

Récupérer donnée

[Ajouter ligne de BS= OUI]

Demande d'ajout d'une ligne de BS

Afficher le formulaire de d'ajout des LBS

Sélectionner le produit

Saisir la quantité servie et valider

Vérifier
la saisie

Loop

Figure 24 : diagramme de séquence ajouter une ligne de bon de sortie

III.4.6 Diagramme de séquence de cas d'utilisation modifier un bon de sortie

Description textuelle du scénario

La modification d'un bon de sortie peut concerner aussi la modification de ses lignes. Le système affiche un formulaire permettant l'une de ses options. Le processus de modification de LBS (Ligne de Bon de Sortie) pourra se répéter autant de fois qu'il aura de lignes à modifier.

Alt

[BS non trouvé]

Effectuer les modifications sur l'entête

[Sinon]

Afficher le formulaire de modification

Effectuer les modifications sur LBS

Valider les modifications

Modifications Enregistrées

Lignes de BS modifiées

Signaler l'erreur

Retourner les données

Modifier LBS

: Magasinier

: Formulaire BS

: Bon de sortie

: FLBS

Demande Rechercher
		Rechercher le BS

Modifier un bon de sortie

Afficher le formulaire de recherche

Saisir le numéro de BS et valider

Figure 25 : Diagramme de séquence du cas d'utilisation modifier un bon de sortie

Le diagramme de séquence suivant décrit la séquence d'interaction modifié lignes BS:

	: Formulaire LBS		: LBS
: Magasinier

Loop

Alt

Alt

[Erreur de données]

[Sinon]

[Modifier ligne de BS= OUI]

[Erreur de saisie]

Afficher le formulaire de modification

Effectuer les modifications et valider

Sélectionner la ligne de BS à modifier

Signaler l'erreur

Enregistrement de la ligne de BS

Signaler l'erreur

Demander Vérifications

Vérifier saisie

Enregistrer
La ligne de
BS modifié

Vérifier les modifications

Figure 26 : Diagramme de séquence modifier une ligne de bon de sortie

III.4.7 Diagramme de séquence du cas d'utilisation supprimer un bon de

sortie

Description textuelle du scénario

Le magasinier demande au système de supprimer un BS (bon de sortie). Celui-ci lui demande de saisir le numéro du BS, puis procède à la recherche de son existence. En effet, s'il a trouvé une fiche descriptive de BS lui sera affichée. Sinon un message d'erreur sera signalé. Le magasinier doit alors confirmer la suppression du bon en cliquant sur le bouton approprié. Ensuite, le système procède à la suppression de l'entête ainsi que l'ensemble de ses les lignes. En cas d'absence d'erreur, le BS sera supprimé sinon toute erreur sera signalée.

	: Formulaire BS
: Magasinier			: Bon de sortie		:LBS

Alt

Alt

[Sinon]

[BS non trouvé]

Affichage de formulaire de recherche

Saisir le numéro du BS et valider

[Suppression impossible]

Supprimer un bon de sortie

Afficher les données de BS

Valider la suppression de BS

[Sinon]

Suppression impossible

BS Supprimé

Signaler l'erreur

Retourner les données

Rechercher le BS

LBS Supprimées

Demande de supprimer LBS

Supprimer le BS

Vérifier si suppression possible

Rechercher le BS

Supprimer les lignes de BS

Figure 27 : Diagramme de séquence supprimer un bon de sortie

III.4.8 Diagramme de séquence du cas d'utilisation consulter l'état de stock Description textuelle du scénario

L'utilisateur demande au système la consultation de l'état du stock. Le système lui demande de choisir un type consultation, puis procède à l'exécution de la requête de type choisi et affiche les informations des produits demandés.

:Produit

:Formulaire

: Magasinier

Demande de consulter le stock

Affichage de la page de consultation

Choisir un type de consultation

Envoie de la requête

Retourner les données des produits

Afficher les informations des produits

Recherche de produits

Figure 28 : Diagramme de séquence du cas d'utilisation consulter le stock

III.4.9 Diagramme de séquence de cas d'utilisation éditer un bon de sortie Description textuelle de scénario

Le magasinier demande l'édition d'un bon de sortie au système. Le système lui affiche un formulaire de recherche lui demandant de saisir son numéro. Le magasinier saisi son numéro et valide la saisie. Puis le système procède à la recherche de son existence. Si le numéro ne correspond à aucun bon de sortie, une erreur sera signalée, sinon il affiche la fiche descriptive de bon. Après la validation de l'opération par le magasinier le système procède à l'impression de bon de sortie.

: Magasinier

: Formulaire

: Imprimante

: Bon de sortie

Rechercher le BS

Demande d'édition d'un BS

Affiche un formulaire de recherche

Saisir le numéro du BS

Demande de recherche BS

Alt

[le BS n'existe pas]

Signaler l'erreur

[Sinon]

Retourner les données

Afficher le BS

Valider l'impression de BS

Demande d'édition de BS

Edition BS

Imprimer BS

Figure 29: Diagramme de séquence du cas d'utilisation éditer un bon de sortie

III.5 Risques critiques:

Avant de se lancer dans la conception, il faut déterminer les principaux risques, mettant en danger la réalisation du projet, afin de les atténuer le maximum possible. La détermination de ces risques est très importante, par exemple elle peut influencer la définition de l'ordre de priorité des cas d'utilisation. En effet, si le langage de programmation présente un risque, nous aurons intérêt à commencer par le cas d'utilisation le plus simple.

> Délai de livraison :

En effet, nous sommes contrariés par le délai de dépôt du mémoire, fixé à trois mois du début de stage, et par l'ampleur de notre projet.

> Risques techniques :

1. L'ambiguïté du Processus unifié :

En effet, le point fort du Processus unifié réside dans son ambiguïté car s'il est adaptable à divers types de projets, c'est parce que sa démarche est générique. Pour cela, nous sommes amenés à bien adapter le processus à notre projet.

Conclusion

A l'issue de cette étape nous avons pu exprimer clairement les objectifs attendus du futur système à concevoir, ainsi que l'analyse associée à chaque cas d'utilisation et la possibilité de les réaliser dans un paradigme orienté objet, sans s'attacher à aucun outil de développement.

Il faut noter que l'étape d'analyse est une activité utile qui va nous permettre d'introduire la prochaine étape du Processus Unifié intitulé «Conception », que nous allons détailler dans le chapitre suivant.

«Le commencement de toutes les sciences, c'est l'étonnement de ce que les choses

sont ce qu'elles sont»[Aristote]

Introduction

Dans la démarche de Processus Unifié, la phase de conception suit immédiatement la phase d'Analyse, par ailleurs la conception de logiciel est un art qui nécessite de l'expérience, et elle consiste à traduire les besoins en spécifiant comment l'application pourra les satisfaire avant de procéder à sa réalisation. En effet, dans ce chapitre nous essayons d'étendre la représentation des diagrammes effectués au niveau de l'analyse en y intégrant les aspects techniques plus proches des préoccupations physiques.

IV. Réalisation du diagramme de classe

La réalisation du diagramme de classe se base sur le dictionnaire de données et les règles de gestion. L'analyse sémantique des données du dictionnaire permet de les regrouper dans des entités à part. Les liens qui les relient tiennent compte des règles de gestion.

IV.1 Règles de gestion

Le diagramme de classe du système étudié est basé sur les règles de gestion suivantes :

1. Un bon de commande interne donne lieu à un et ou plusieurs bon de sortie.

2. Un bon de sortie est associé à un et un seul bon de commande interne.

3. Un bon de commande interne contient un ou plusieurs produits.

4. Un produit peut figurer dans un bon de commande interne, comme il peut ne pas l'être.

5. Un fournisseur établit une ou plusieurs factures.

6. Une facture provient d'un et un seul fournisseur.

7. Un bon d'entrée concerne un ou plusieurs produits.

8. Un produit peut figurer dans un ou plusieurs bons d'entrée.

9. Un bon d'entrée est associé à une et une seule facture.

10. Une facture est associée à un et un seul bon d'entrée.

11. Une facture est associée à un et un seul bon de commande externe.

12. Un bon de commande externe est associé à une et une seule facture.

13. Un bon de sortie peut contenir un ou plusieurs produits.

14. Un produit peut figurer sur plusieurs bons de sortie, comme il peut ne pas l'être.

15. Un bon de sortie concerne un et un seul service demandeur.

16. Un service demandeur peut figurer sur plusieurs bons de sortie.

17. Un produit appartient à une et une seule famille.

18. Une famille concerne un ou plusieurs produits.

19. Un produit peut être stocké dans plusieurs emplacements, comme il peut ne pas posséder d'emplacement.

20. Un emplacement peut contenir un ou plusieurs produits.

IV.2 Dictionnaire des données

La collection et l'analyse des informations en provenance de différentes sources (Entretien avec le magasinier et analyse des documents), nous a permis d'établir le dictionnaire de données ci-dessous :

Nom de la classe	Codification	Désignation	Type	Longueur	observation
Service_Demandeur	Nom_Ser	Le nom de service	A	50
	Nom_Dem	Le nom de demandeur	A	25
	Pre_Dem	Le prénom de demandeur	A	25
	Fct_Dem	La fonction de demandeur	A	40
Fournisseur	Code_F	Le code de fournisseur	N	4
	Rais_Soc	La raison sociale de fournisseur	A	60
	Adresse	L'adresse de fournisseur	AN	50
	Tel	Le numéro de téléphone de Fournisseur	N	10
	Fax	Le fax du fournisseur	N	10
	E-mail	L'e-mail de fournisseur	AN	30
Produit	Ref_Prod	La référence du produit	N	4
	Design_Prod	La désignation du produit	A	50
	Type	Le type du produit : Consommable ou non Consommable	boolé en	1
	Qtt_Stock	La quantité du produit en stock	N	10
	Stock_Min	La valeur du stock minimum	N	10
Famille	Ref_Fam	La référence de la famille	N	4
	Design_Fam	La désignation de la famille	A	50
Emplacement	Ref_Emp	La référence de l'emplacement	N	4
	Design_Emp	La désignation de l'emplacement	AN	50
Produit_NonC	Num_Inv	Le numéro d'inventaire de produit non consommable	AN	10
Bon_Entree	Num_Entree	Le numéro de bon d'entrée	N	10
	Date_Entree	La date de bon d'entrée	Date	8	JJ/MM/AAA A
	Num_Fact	Le numéro de la facture	AN	10
	Date_Fact	La date de la facture	Date	8	JJ/MM/AAA A
	Num_BCEX	Le numéro du bon de	AN	8

		commande externe
	Date_BCEX	La date du bon de commande externe	Date	10	JJ/MM/AAA A
Bon_Sortie	Num_BS	Le numéro du bon de sortie	N	4
	Date_BS	La date du bon de sortie	Date	10	JJ/MM/AAA A
Bon_CmdI	Num_BCI	Le numéro du bon de commande interne	AN	5
	Date_BCI	La date du bon de commande interne	Date	10	JJ/MM/AAA A
Nom de la classe associative	Codification	Désignation	Type	Longueur	Observation
Ligne_Entree	Qtt_ProdE	La quantité du produit entrée	N	6
	Prix_ProdE	Le prix total du produit entré	N	8
Ligne_Sortie	Qtt_Ser	La quantité du produit servie	N	10
	Obs_BS	Observation	A	100
Ligne_BCI	Qtt_Dem	La quantité demandée	N	6
	Qtt_Acc	La quantité accordée	N	6
	Obs_BCI	Observation	AN	100

Tableau 5 : Dictionnaire des données

NB : A = alphabétique, AN = alphanumérique.

IV.3 Diagramme de classe

Le schéma suivant représente le diagramme de classe correspondant au système étudié :

Service_Demandeur

Nom_ Ser: String Nom_Dem : String Pre_Dem : String Fct_Dem :String

Ajouter ()

Modifier () Supprimer ()

1

Fournisseur
			Bon_Entrée
Code_F : Integer Rais _Soc : String Adresse : String Tel: Integer Fax : integer Email :String
	1 Concerne1 1..*			Num_Entree:integer Date_Entree: Date1 Num_BCEX : String Date_BCEX: Date Num_Fact : String Date_Fact : Date
Ajouter () Modifier () Supprimer ()
				Ajouter () Modifier () Supprimer ()

Famille

Ref_Fam : Integer Désign_Fam : String

Ajouter ()

Modifier ()

Supprimer () Ligne_Entrée

Qtt_ProdE: Float Prix_ProdE : Integer

Concerne

1

Possède 1..*

Ranger

1..*

0..*

Ligne_Sortie

Qtt_Ser : Float Obs_BS : String

Contient2 0..*

1..*

0..*

Ligne_BCI

Qtt_Acc:Float Qtt_Dem :Float Obs BCI:String

1..* Contient1

Emplacement

Ref_Emp : Integer Désign_Emp : String

Ajouter ()

Modifier () Supprimer ()

1..*

Contient

1..*

Produit

Ref_Prod: Integer Désign_Prod :String Type :booléen Qtt_Stock :Float Stock_Min :Float

Ajouter ()

Modifier () Supprimer ()

Produit Non .C

Num_Inv : String

0..*

Bon_ CmdI

Num_BCI: String Date_BCI : Date

1

Donne
lieu

1..*

Bon_Sortie

Num_BS : integer Date_BS : Date

Ajouter ()

Modifier () Supprimer ()

Figure 30: diagramme de classe

IV.4 Le modèle logique de données :

Apres l'application des règles de transformations et de passage du diagramme de classe vers le modèle logique de données, nous avons dégagé les différentes tables relatives au diagramme de classe, elles sont comme suit:

Fournisseur (Code F, Rais_Soc, Adresse, Tel, Fax, E-mail)

Bon_Entrée(Num Entree, Date_Entree, Num_Fact, Date_Fact, Num_BCEX, Date_BCEX, #Code_F)

Produit (Ref_Prod, Design_Prod, Type, Qtt_Stock, Stock_Min, #Ref_Fam) Ligne_BCI (Ref Prod,Num BCI, Qtt_Dem, Qtt_Acc, Obs_BCI)

Ligne_Entrée (Num Entree, Ref Prod, Qtt_ProdE, Prix_ProdE)

Ligne_Sortie (Num_BS, Ref_Prod, Qtt_Ser, Obs_BS)

Bon_Sortie (Num_BS, Date_BS, # Num_BCI)

Bon_CmdI (Num BCI, Date_BCI, #Nom_Ser)

Produit_NonC (Num Inv, #Ref_Prod)

Emplacement (Ref_Emp, Design_Emp)

Ranger (Ref_Prod, Ref_Emp)

Famille (Ref_Fam, Design_Fam)

Service_ Demandeur (Nom Ser, Nom_Dem, Pre_Dem, Fct_Dem).

IV.5 Règles de passages

Dans ce qui suit, nous allons présenter les différentes règles de passages, qui nous ont servis lors de l'élaboration du modèle logique des données.

· Affecter une table à chaque classe. [JCJO]

· Une association « un à plusieurs » engendre la migration de la clé primaire de la table mère à la table fille. [JCJO]

· Une association « plusieurs à plusieurs » est représentée par une table ayant pour clé primaire la concaténation des clés primaires des deux tables associées. [JCJO]

IV.6 Règles de normalisation

Une table est sous la troisième forme normale si, à tout moment, chaque ligne est constituée d'un identificateur d'objet unique associé à un certain nombre d'attributs indépendants. [JCJO]

Conclusion

Apres avoir identifié les règles de gestion du système et les classes associées, nous avons procédé à l'extraction du dictionnaire des données afin d'élaborer un diagramme de classe détaillé. A base de ce dernier, on a abouti au modèle logique des données en faisant appel aux règles de passages.

«L'ambition est le dernier refuge de l'échec»

[Oscar Wilde, in Le portrait de Dorian Gray]

Introduction

A ce stade du processus, les cas d'utilisation sont terminés, le problème a été d'analysé en profondeur ; nous avons défini une conception mieux appropriée aux besoins de l'application. Nous pouvons alors entreprendre la dernière activité du Processus Unifié qu'est de même composé de deux parties (implémentation et test), ayant comme objectif d'aboutir à un produit final, exploitable par les utilisateurs. Dans cette phase nous allons présenter l'environnement de développement que nous avons utilisé, l'architecture matérielle mise en place, implémenter tout les cas d'utilisation, et enfin les tester

V.1 Environnement de développement de l'application

Pour réaliser notre application, nous avons utilisé le langage de programmation PHP dédié à la création des applications web dynamique, celui-ci nous l'avons manipulé dans un environnement de développement intitulé Dreamweaver, qui est largement compatible avec PHP.

Par ailleurs, il faut noter que les pages écrites en PHP sont à chaque fois testées grâce à une plate forme de développement spécifique. La plate forme que nous avons adoptée est WampServeur version 2.0 qui inclut tous les outils nécessaires pour le test d'un site web dynamique à savoir le serveur Apache version 2.2.8, MySQL version 5.0.51b et la version PhpMyadmin 2.9.1.1. Nous avons utilisé quelques portions de codes JavaScript qui est un langage exécuté coté client.

Afin d'avoir des interfaces ergonomiques, nous avons utilisé Adobe Photoshop pour les traitements des images de notre application.

V.2 Outils de développement

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

Figure 31 : Page d'accueil WampServer

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

V.2.3 Adobe Dreamweaver

Anciennement Macromedia Dreamweaver est un éditeur de site web de type WYSIWYG. Dreamweaver fut l'un des premiers éditeurs HTML de type tel affichage, tel résultat, mais également l'un des premiers à intégrer un gestionnaire de site (CyberStudio

GoLive étant le premier). Ces innovations le propulsèrent rapidement comme l'un des principaux éditeurs de site web, aussi bien utilisable par le néophyte que par le professionnel.

Dreamweaver offre deux modes de conception par son menu affichage. L'utilisateur peut choisir entre un mode création permettant d'effectuer la mise en page directement à l'aide d'outils simples, comparables à un logiciel de traitement de texte (insertion de tableau, d'image, etc.). Il est également possible d'afficher et de modifier directement le code (HTML ou autre) qui compose la page. On peut passer très facilement d'un mode d'affichage à l'autre, ou opter pour un affichage mixte. Cette dernière option est particulièrement intéressante pour les débutants qui, à terme, souhaitent se familiariser avec le langage HTML.

Dreamweaver a évolué avec les technologies de l'internet. Il offre aujourd'hui la possibilité de concevoir des feuilles de style. Les liaisons avec des bases de données ont également été améliorées ainsi que le chargement des fichiers sur les serveurs d'hébergement. Il propose en outre l'utilisation de modèles imbriqués de pages web, selon un format propriétaire.

Depuis la version MX, il peut être utilisé avec des langages web dynamiques (ASP, PHP) à l'aide d'outils relativement simples d'utilisation. Il permet ainsi de développer des applications dynamiques sans connaissance préalable des langages de programmation.

V.2.4 MySQL

MySQL est un système de gestion de base de données (SGBD). Selon le type d'application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avec Oracle et Microsoft SQL Server.

MySQL est un serveur de bases de données relationnelles SQL développé dans un souci de performances élevées en lecture, ce qui signifie qu'il est davantage orienté vers le service de données déjà en place que vers celui de mises à jour fréquentes et fortement sécurisées. Il est multi-thread et multi-utilisateur.

MySQL fait partie du quatuor LAMP: Linux, Apache, MySQL, PHP. Il appartient également à ses variantes WAMP (Windows) et MAMP (Mac).

Le couple PHP/MySQL est très utilisé par les sites Web et proposé par la majorité des hébergeurs Web. Plus de la moitié des sites Web fonctionnent sous Apache, qui est le plus souvent utilisé conjointement avec PHP et MySQL.

V.2.4.1 Concurrents de MySQL

· Oracle : c'est le SGBD le plus célèbre, le plus complet et le plus puissant. Il est malheureusement payant (et cher), ce qui le réserve plutôt aux entreprises qui l'utilisent déjà massivement. Il existe cependant des versions gratuites d'Oracle notamment pour ceux qui veulent apprendre à s'en servir.

· Microsoft SQL Server: édité par Microsoft, on l'utilise souvent en combinaison avec ASP .NET, bien qu'on puisse l'utiliser avec n'importe quel autre langage. Il est payant, mais il existe des versions gratuites limitées.

· PostgreSQL : il s'agit d'un SGBD libre et gratuit comme MySQL, qui propose des fonctionnalités plus avancées. Parfois comparé à Oracle, il lui reste cependant du chemin à parcourir. Il dispose d'une communauté un peu moins importante que MySQL et Oracle. Le Site du Zéro utilise PostgreSQL.

· SQLite : le SGBD le plus simple et le plus petit. Il est libre et gratuit mais dispose de très peu de fonctionnalités (ce qui suffit parfois). Son gros avantage est d'être très léger.

V.2.5 JavaScript

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.

V.2.6 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 : textures, ombres, renforcement des contours, estampage, flou, etc.

V.3 Implémentation de la base de données

Pour implémenter notre base des données « Gestock », nous avons utilisé l'environnement de création de base des données PHPMyAdmin et le système de gestion de base des donnés MySQL. Le tableau ci-dessous présente notre base de données :

Figure 32 : base de données Gestock

V.4 La sécurité de l'application

Pour assurer la sécurité des comptes de chaque utilisateur de l'application, on applique la fonction addslashes(), qui va permettre d'échapper les caractères spéciaux comme qui pourraient être utilisés par des utilisateurs malveillants pour pénétrer notre système en traficotant la requête. Cette technique s'appelle l'injection SQL.

On applique également la fonction md5 ()pour le mot de passe, car notre requête devra faire la comparaison entre le mot de passe tapé par l'utilisateur et l'empreinte md5 du bon mot de passe qui lui se trouve dans notre base de données. (On aurait pu aussi utiliser sha1 () ou crypt () (fonctionnement différent)).

Fiche de Stock

compte

Bon d'entree

Modification d'un

Bon de so

rtie

interne

mpte

Creer un co

Bon de commande

iestion de sessions

Editions

Figure 33 : Arborescence de l'application web

V.6 Interfaces de l'application

Dans ce qui suit, nous allons présenter quelques interfaces de notre application web GeStock.

V.6.1 Interface d'accueil

Cette page offre un aperçu de l'application web. On retrouve l'interface d'authentification permettant aux différents utilisateurs d'accéder à leurs sessions.

Figure 34: Interface d'accueil

V.6.2 Interface d'administration

Cette interface permet au superviseur d'avoir un contrôle total sur l'application, lui permettant ainsi d'accéder a toutes ses fonctionnalités.

Figure 35: Interface d'administration

V.6.3 Interface gestion des sessions

Cette interface permet au superviseur de gérer les différentes sessions des utilisateurs de l'application.

Figure 36: Interface gestion des sessions

V.6.4 Interface édition fiche de stock

Cette interface permet au superviseur d'éditer une fiche de stock pour un produit bien spécifique.

Figure 37 : Interface fiche de stock

V.7 Architecture matérielle mise en place

L'architecture que nous allons utiliser est l'architecture à trois niveaux. L'application web sera hébergée dans un serveur situé dans le centre de calcul de l'Université Abderrahmane Mira. La base de données quant à elle sera hébergée dans un autre serveur.

L'architecture adoptée est comme suite:

Figure 38: Architecture matérielle adoptée

V.8 Diagramme de déploiement

Le diagramme de déploiement ci-dessous représente la répartition physique des micro ordinateurs clients connectés a un serveur web situé au niveau du centre de calcul de l'Université, et qu'est de même relié au serveur de base de données dont lequel nous souhaitons implémenter notre base de données GeStock.

Exécutable

PC Service demandeur

: Navigateur Web

Exécutable

PC Magasinier

vigateur Web

: Serveur WEB

<<Le serveur web Apache>>

: Serveur de base de données

<< MySQL>>

<<Base de donnée Gestock >>

Figure 39: Diagramme de déploiement

Perspective

Nous souhaitons mettre en place une application serveur faisant office d'un pare-feu entre le serveur web et le serveur de base de données afin de filtrer les différentes requêtes acheminées à travers la liaison, émanant des différents clients connectés au serveur web dans le souci de mieux sécuriser le serveur de base de données.

Pour cela, nous proposons une application serveur bien connu dans le domaine des bases de données qu'est GreenSQL.

V.9 Test

Cette activité consiste à tester les résultats de l'implémentation pour s'assurer du bon déroulement des fonctionnalités du système. Lors de l'évaluation des tests effectués, si nous détectons une anomalie quelconque, nous devrions la corriger.

V.9.1 Test du cas d'utilisation « Authentification>>

Chaque utilisateur possède son propre "login" et mot de passe "password".

Pour tester ce cas d'utilisation, nous avons rempli les champs spécifiques pour le login et le mot de passe avec un nom d'utilisateur existant déjà dans la base de données et après la validation, la session est ouverte.

Par la suite, nous avons tenté d'accéder à la même session mais avec un mot de passe différent, l'accès à la session est rejeté (idem pour un login inexistant dans la base de données). Donc le test est réussi.

V.9.2 Test du cas d'utilisation « Etablir un bon de sortie>>

Cette tâche consiste à établir un Bon de sortie et de l'enregistrer dans la base de données.

Nous avons créé un Bon de sortie fictif et voici ses attributs montrés dans cette capture d'écran de l'application :

Figure 40 : Test sur les sorties du stock

Le formulaire vierge étant affiché, nous avons saisi les informations montrées dans la capture ci-dessus. En validant, le Bon de sortie doit figurer dans notre base de données.

En effet, Nous avons vérifié l'existence du Bon de sortie dont le numéro est« 5 » dans la base de données, la vérification est réussie.

V.9.3 Test du cas d'utilisation « imprimer un bon de sortie»

Sur le même bon de sortie nous avons essayé de l'imprimer. En validant l'impression, l'opération est lancée.

Figure 41 : Test sur l'impression d'un bon de sortie

V.9.4 Test du cas d'utilisation << supprimer un bon de sortie >>

Nous avons testé ce cas d'utilisation pour le bon de sortie ayant le numéro 5, qui a été établi et enregistré dans la base de données.

Apres avoir vérifié la base de données, nous avons remarqué l'inexistence du bon, donc le teste est réussi.

V.9.5 Test du cas d'utilisation << Modifier un bon de sortie >>

Toujours sur le même bon de sortie, nous avons effectué des modifications sur ses informations. Et Apres avoir consulté le bon de sortie.

Nous avons constaté que les informations modifiées, on été pris on considération. Le test de modification est réussi.

V.9.6 Test du cas d'utilisation <<Ajout d'un nouvel article>>

Nous avons saisi les informations d'un nouvel article dans l'interface approprié, ensuite nous avons vérifié son existence dans la base de données. La vérification est réussie.

V.9.6 Test du cas d'utilisation « Etablir une fiche de stock»

Figure 42 : Test sur Etablir une fiche de stock

Conclusion

Dans ce chapitre, nous avons décrit brièvement le processus de réalisation de notre application Gestock en spécifiant l'environnement de développement, l'implémentation de la base des données et la démarche suivie pour la réalisation. 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

Conclusion générale

La phase de conception du projet a duré plus que nous l'avions prévue. En effet, il lui a fallu un mois et demi pour analyser le contexte auquel s'attache notre travail, et concevoir le futur système. La tâche qui nous a embarrassés le plus, consiste notamment dans l'application conforme du cycle de vie du Processus Unifié. En fait, la liberté que nous a accordée ce processus, (un processus générique), s'est convertie en une lourde responsabilité : la responsabilité d'accomplir les bons choix.

La spécification des besoins a duré un mois. Pendant cette période, il nous était demandé d'assimiler le contexte du travail à accomplir. Accompagnés par le chef du magasin, la Faculté des Sciences Exactes nous a permis d'explorer et d'approfondir la compréhension du domaine d'étude. Nous avons réussi à dégager les lacunes du système actuel et suggérer des solutions afin d'y remédier. Nous avons opté pour l'architecture réseau à trois niveaux qui est adéquate aux exigences de l'organisme.

La phase d'analyse a duré un moi, au cours de cette période, nous avons essayé de structurer et définir les besoins attendus du futur système. Il s'agissait de formuler, d'affiner et d'analyser la plupart des cas d'utilisation via les diagrammes d'UML.

Il faut noter que le dégagement des grandes fonctionnalités du système n'a pas suffi pour aborder la phase de conception, il fallait dégager plus de besoins. Il nous a fallu interroger les différents acteurs du système d'information de la Faculté pour enrichir notre diagramme de cas d'utilisation. Et là nous étions confrontés à un problème délicat : la dissimulation de l'information. La solution réside dans le Processus Unifié, et consiste au prototypage. Il fallait donc construire des interfaces prototypes et les présenter aux différents acteurs.

Les éléments à livrer au terme de la phase d'analyse (acteurs, besoins fonctionnels, besoins non fonctionnels) étant déterminés, nous pouvions passer à la phase suivante.

Ensuite nous avons entamé la phase de conception. Dans cette phase, nous avions déjà un modèle final des cas d'utilisation. Il s'agissait alors d'étendre la représentation effectuée au niveau de l'analyse en y intégrant les aspects techniques les plus proches des préoccupations physiques. L'élément principal à livrer au terme de cette phase est le diagramme de classe ainsi que le schéma relationnel.

Enfin, nous étions arrivés à la dernière phase du Processus Unifié, où il s'agissait d'implémenter et tester les cas d'utilisation conçus. La version exécutable du système est l'élément principal à livrer à l'issu de cette étape.

L'application que nous avons développée est dédiée spécialement au magasin de la Faculté des Sciences Exactes. Nous souhaitons que celle-là soit étendue afin de toucher les différents magasins de l'Université de Bejaïa y compris ceux d'ABOUDAOU.

Nous souhaitons ainsi que l'application développée sera utile, aussi utile au magasinier de la Faculté des Sciences Exactes qu'elle fut intéressante pour nous. En fait, à la fin de la réalisation de ce mémoire, nous avons accumulé une masse importante de connaissances aussi bien sur le plan théorique que sur le plan pratique, et nous estimons qu'elle nous sera très utile à l'avenir, dans nos études ultérieures.

glossaire

-A-

Adresse (@) IP :Une adresse IP (avec IP pour Internet Protocol) est le numéro qui identifie chaque ordinateur connecté à Internet, ou plus généralement et précisément, l'interface avec le réseau de tout matériel informatique (routeur, imprimante) connecté à un réseau informatique utilisant l'Internet Protocol.

Adresse (@) MAC :En réseau informatique une adresse MAC (Media Access Control address) est un identifiant physique stocké dans une carte réseau ou une interface réseau similaire et utilisé pour attribuer mondialement une adresse unique au niveau de la couche de liaison (couche 2 du modèle OSI). C'est la partie inférieure de celle-ci (sous-couche d'accès au média - Media Access Control) qui s'occupe d'insérer et de traiter ces adresses au sein des trames transmises. Elle est parfois appelée adresse Ethernet, UAA (Universally Administered Address), BIA (Burned-In Address), MAC-48 ou EUI-48.

Application : Les applications sont les outils qui nous permettent de tout faire sur un ordinateur. Les traitements de texte, les tableurs, les navigateurs Web sont des applications (synonymes : Logiciel et Programme).

-B-

Bon de commande :Le bon de commande est le document écrit adressé par la personne publique contractante au titulaire du marché ; il précise celles des prestations décrites dans le marché dont l'exécution est demandée et en détermine la quantité.

-E-

Encapsulation :En programmation orientée objet, l'encapsulation est l'idée de protéger l'information contenue dans un objet et de ne proposer que des méthodes de manipulation de cet objet.

-F-

Fiche de stock :Une fiche de stock est feuille qui permet de tenir à jour un état des stocks. Elle permet de suivre les mouvements de stock, c'est à dire de suivre les entrées (livraisons (achats)) et les sorties (ventes) de marchandises. La fiche de stock retrace l'historique des achats et ventes pour une même référence.

Flot : Motif d'ornementation formé d'enroulements se reliant de façon continue. Appelé également flots-grecs, cet ornement est obtenu par la répétition d'une courbe en S couchée, terminée à l'une de ses extrémités par une volute d'où part la courbe suivante. On reconnaît une dizaine de flots définis par l'exécution du dessin, ils sont couramment dénommés :

FTP :le File Transfer Protocol (protocole de transfert de fichiers), un protocole de communication dédié à l'échange de fichiers informatique sur un réseau TCP/IP.

-H-

HTTP :[protocole] HyperText Transfer Protocol .Protocole de transmission dédié aux clients et aux serveurs du web. Facile à implanter car à un transfert de données est associé une connexion, il devient lourdingue, car il multiplie ainsi les connexions.

-I-

Instanciation: En programmation orientée objet, on appelle instance d'une classe, un objet avec un comportement et un état, tous deux définis par la classe. Dans ce contexte, instance est un anglicisme, qui signifie « cas >>, « exemple >>.

Inventaire : L'inventaire (latin inventus) est une liste exhaustive d'entités considérées comme un patrimoine matériel ou une somme de biens afin d'en faciliter l'évaluation ou la gestion. ...

-P-

POO: La programmation orientée objet (POO), ou programmation par objet. C'est un paradigme de programmation informatique qui consiste en la définition et l'interaction de briques logicielles appelées objets , un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d'un livre. Il possède une structure interne et un comportement, et il sait communiquer avec ses pairs. Il s'agit donc de représenter ces objets et leurs relations ; la communication entre les objets via leur relation permet de réaliser les fonctionnalités attendues, de résoudre le ou les problèmes.

-S-

Standardisation :L'entreprise qui applique une politique de standardisation de son produit offre une version unique d'un produit (le produit vendu sur le marché domestique) sur l'ensemble de ses marchés étrangers.

SMTP :Serveur SMTP signifie « Serveur Simple Mail Transfert Protocol >> et se traduit par « protocole simple de transfert de courrier >> en français.

Un serveur SMTP est un serveur de courrier. Il gère le transfert du courrier électronique vers les différents serveurs de messagerie électronique. De plus, il permet l'envoi de mail à partir des ordinateurs clients. C'est pourquoi, il est utile de spécifier un serveur pop et un serveur SMTP lors de la configuration du logiciel du mail.

SMTP n'a pas pour but de récupérer à distance des mails arrivés dans une boite mail.

-T-

TCP/IP :Définition du mot TCP IP, Ensemble de deux protocoles qui permettent la gestion des flux d'informations sur Internet.

-W-

Webmaster: C'est la personne responsable du développement d'un site web en général. Il s'occupe de la programmation et de la présentation des différentes applications et informations qui sont destinées aux internautes. Il a également le rôle d'administrateur du site et a pour but de s'assurer de la fiabilité des services proposés et de la sécurité de l'ensemble (contre les pirates) ainsi que de l'audimat et de la rentabilité de celui-ci.

Résumé

Résumé

Résumé

Aujourd'hui, l'informatique a atteint une prodigieuse évolution technologique dans différents domaines (réseaux informatiques, bases de données, le Web, etc.). Cette évolution est nécessaire pour remédier aux problèmes rencontrés dans la vie actuelle.

Le dynamisme est l'une des caractéristiques les plus essentielles de l'informatique. C'est ceci qui nous a poussés à créer une application web dynamique, accessible par des utilisateurs dans un réseau informatique que ce soit intranet ou local.

Chaque création nécessite une modélisation avec un langage universel bien spécifié tel qu'UML, la réalisation quant à elle nécessite des outils de développements bien adaptés au contexte de l'application. Pour les bases de données, l'utilisation d'un SGBD tel que MySQL, ORACLE, PostgreSQL, etc. est indispensable.

Notre travail consiste à concevoir une application web à trois niveaux en utilisant une base de données centralisée, pour la gestion des stocks de la faculté des sciences exactes de l'Université Abderrahmane Mira. L'application a été développée en utilisant différents logiciels informatiques tel que Dreamweaver, WampServer, JavaScript, Adobe Photoshop, etc. Le langage de programmation utilisé est le PHP.

Mots clés: Web, MySQL, PHP, Dreamweaver, JavaScript, WampServer, Adobe Photoshop.

Abstract

Today, data processing reached an extraordinary technological development in various fields (data-processing networks, databases, the Web, etc). This evolution is necessary to cure the problems encountered in the current life.

The dynamism is one of the most essential characteristics of data processing. It is that which pushed us to create dynamic Web application, accessible by users in a data-processing network that it is Intranet or local Network.

Each creation requires a modeling with a universal language good specified such as UML, the realization as for it requires development tools adapted well to the context of the application. For the databases, the use of a DBMS such as MySQL, ORACLE, PostgreSQL, etc is essential.

Our work consists in conceiving a Web application to three levels by using a database centralized, for the inventory control of the Exact Faculty of Science of the University Abderrahmane Mira. The application was developed by using various data-processing software such as Dreamweaver, WampServer, JavaScript, Adobe Photoshop, etc. The programming language used is the PHP.

Key words: Web, MySQL, PHP, Dreamweaver, Javascript, WampServer and Adobe Photoshop.

Bibliographie

Bibliographie

[AM07] N.ABDAT et L.MAHDAOUI, UML Outil du génie logiciel.

[AUD08] Laurent AUDIBERT, `UML 2', Institut Universitaire de Technologie de

Villetaneuse - Département Informatique, Édition 2007-2008.

[JBR99] Ivar Jackobson, Grady Boosh, James Rambaugh, Le processus unifié de développement logiciel, Editions Eyrolles, 1999.

[JCJO00] Ivar Jackobson, Manus Cristerson, Patrick Jonsson, Gunar Overgaard, Le génie logiciel orienté objet, Editions Addison Wesley, 2000.

[JU01] F. Juliard UML Unified Method Language, Journal Université de Bretagne Sud UFR SSI-IUP Vannes, 2001-2002.

[JD08]Joseph Gabay et David Gabay, Mise en oeuvre guidée avec études de cas, édition Dunod, Paris 2008.

[LMP00] Nathalie Lopez, Jorge Migueis et Emmanuel Pichon, Intégrer UML dans vos projets, Editions Eyrolles, 2000.

[Roques06] Pascal ROQUES, UML 2 par la pratique étude de cas et exercices corrigés, ÉDITIONS EYROLLES, Septembre 2006.

Webliographie

[CCM] www.commentcamarche.com/initiation/concept.html

Les annexes

Dans cette annexe, nous présenterons les différents documents qui nous ont servis tout au long de notre travail. Ces documents sont : bon de commande interne, bon de sortie, bon d'entrée, bon de commande, fiche de stock et fiche état d'inventaire physique.

Annexe :

Figure 43 : bon de sortie et bon de commande interne

Figure 44 : bon d'entrée

Figure 45 : Fiche de stock

87