Rechercher sur le site:

Recherche

Home | Publier un mémoire | Une page au hasard

Memoire Online > Commerce et Marketing

Conception et réalisation d'une application de gestion de stock dans une
entreprise privée cas de Sesomo. ( Télécharger le fichier original ) Disponible en
par Harris KATETE mode multipage
Intitut supérieur de commerce de Lubumbashi RDC - Licence 2011

EPIGRAPHE
« Il suffit que tu commences, tout est possible »

Harris KATETE

« Nosce te ipsum » : Connais toi, toi-même.

Socrate

DEDICACE
À mon père Evariste KATETE LUMANISHA, ma mère Françoise MBETE, mon Grand Frère Gaspard KALONDA et sa
femme Rosette MULANGA, pour vos soutiens tant moral et spirituel que vous m'avez apportés dans les moments difficiles.
Que ce travail soit pour vous, fruit de nombreux sacrifices ;

À celle qui viendra s'ajouter à mes côtés ;

À mes futurs enfants ;

À cette entreprise qui m'a offerte l'opportunité de m'étaler à leurs besoins.

Je dédie cet oeuvre.

Harris KATETE

REMERCIEMENTS
Au degré de cet oeuvre, nous révélons notre gratitude à notre Directeur, le Professeur NGUBA qui a assuré la direction du
présent travail. S'aperçois, critiques et avis ont profusément contribué à bien élaborer le fond et la forme de cet oeuvre.

Nos sentiments de gratitude s'adressent autant à au Chef de TravauxEmery KALONJI, qui a pu consacrer de son temps à
la coordination de ce travail.

Certifions encore notre reconnaissance au corps professoral de l'Institut Supérieur de Commerce ainsi qu'à tous ceux qui
ont contribué moralement et financement à notre formation durant les deux années d'études de deuxième cycle à l'Institut
Supérieur de Commerce. .

Et restons infiniment reconnaissant à vous frères et soeurs: Petronie MBAMBI, NKUSU Bibiche, Kany KANYEBA, Mwabana
Françoise, Gaspe KALANDA, Laurianne KALOMBO, Alice MWISANGE, Platini NGONGO, Papy KAKOKO, Huguette

KALONDA.
KALONDA.

Nos gratitudes aux amis et tous ceux qui, de près ou de loin ont contribué à l`accomplissement de cette oeuvre : Thierry
KYOMBE TWITE, Christian LUYENGU, Mr Arnolde KUKELE, Gains MWIMBA, Guelord MUTEB, Mr Christian MWIKA, Mr
Sylvain MULOWAYI, Mr Eric MUMBA, Trésors MANIX, Bavon, Lisette MUSHILANGA, Hossie LUMBALA, Guellord Momat,
Jacques, Mr MUMBA Eric, Mr Delphin.

En définitive, nous ne passerons pas sous silence, les remarques et conseils de nos collègues avec qui nous avons
supporté et étions confrontés aux mêmes difficultés : Alain ILUNGA LUFULWABO, Baron TSHIMUANGA MUAMBA, Josués
MUKAWA, Nancy ILUNGA, Sandra BONONGO, PHUATI Christelle, Clarisse MUKENDI, MPIANA Thierry, TSHOMBE Jires,
Olivier MUSHID, Antoine MWELWA, KABEJ MUKAD, PANDE MOYA MPIANI El'adje.

Harris KATETE

AVANT PROPOS
Pour cet oeuvre scientifique, nous avons voulu faire voir qu'hormis l'existence, nous sommes à mesure d'innover, créer par
nos propres efforts. Pour le reste nous soumettons cet ouvrage entre les mains des Ingénieurs Concepteurs et
Développeurs, qu'ils tiennent compte de tout le déroulement de Gestion de Stock en générale et particulièrement celle de
SESOMO enfin de rapporter toutes corrections relatives à celle-ci.

Nous nous sentons fiers de forger ces pages et encore une fois remercions notre Directeur et Co-directeur de nous avoir
accordé encouragement et soutien tout au long de notre investigation.

Cette documentation n'est pas parfaite et elle est incomplète car le domaine est vaste. C'est ainsi je sollicite votre
indulgence pour toute erreur qui se serait glissée dans la rédaction de ce travail. Toutefois vos suggestions et remarques
seraient les bienvenues pour l'amélioration de celle-ci. Et nous vous laissons découvrir le contenu.

Harris KATETE

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. Ce c'est qui nous a poussés à créer une
application dynamique, qui sera aussi 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 Hyper File Classic, MySQL, ORACLE, PostgreSQL, etc. est indispensable.

Notre travail a abouti à la conception d'une application en utilisant une base de données Hyper File Classic, pour la gestion
de stocks de la Secrétariat Sociale de la Main d'OEuvre (SESOMO). L'application a été développée en général avec le
Windev (renfermant plusieurs autres outils), le Word. Le langage de programmation utilisé est le WLangage.

INTRODUCTION GENERALE
L'informatique, science de traitement automatique de l'information, constitue un domaine pratiquement incontournable dans
la résolution de multiples problèmes, principalement ceux liés à la gestion optimale des organisations.

Dans cette vision, nous inscrivons notre présent travail pour n'aborder que le problème lié à la Conception et Réalisation
d'une Application de gestion de Stock afin résoudre certaines difficultés y afférentes que rencontre l'entreprise SESOMO
dans sa Gestion quotidienne.

O.1. CHOIX ET INTERET DU SUJET

Avant de fixer les idées sur l'intérêt du sujet, nous portons à la connaissance de nos lecteurs que le présent travail est né du

besoin réel des responsables de SESOMO, qui pour des raisons de rationalisation de la gestion de leurs stocks, nous ont
sollicité pour informatiser ladite gestion. Ce qui veut dire que l'application qui sortira de notre dissertation sera
sollicité pour informatiser ladite gestion. Ce qui veut dire que l'application qui sortira de notre dissertation sera
immédiatement utilisée par l'entreprise.

Ainsi donc l'intérêt ayant motivé le choix du présent sujet, se situe à trois niveaux :

0.1.1. Sur le plan Personnel

Améliorer le processus de gestion et le souci d'informatiser un système manuel en apportant mon savoir faire pour alléger
les tâches liées à la gestion de stock de SESOMO, une réalité que nous avons développé dans les lignes qui suivent.

0.1.2. Sur le plan Scientifique

Actuellement l'évolution de la technologie nous oblige à intégrer l'informatique dans le métier en manipulant plus l'ordinateur,
raison pour laquelle nous devons savoir les principes et techniques de travail, des théories scientifiques élaborées par des
différents auteurs spécialisés dans cette matière.

0.1.3. Sur le Plan social

Les conclusions auxquelles vont aboutir notre travail, apporterons plus au moins des solutions aux problèmes qui se posent
dans la gestionstock. D'où la formulation de notre sujet comme suit : « Conception et réalisation d'une application de gestion
de stock de SESOMO ».

0.2. ETAT DE LA QUESTION

Aucune étude si originale soit elle ne peut pas prétendre s'affranchir des liens qui l'unissent à d'autres études de la même
contrainte. La logique scientifique exige de nos jours et dans la plupart de cas, que lorsqu'on traite un sujet scientifique, il est
préférable à tout rédacteur de commencer par fréquenter des bibliothèques pour consulter les travaux de fin d'études traités
par nos prédécesseurs, d'en tirer une démarcation enfin d'éviter de revenir sur les mêmes idées.

En effet, au sujet de notre présent travail, l'honnêteté se focalise sur les recherches des travaux de nos prédécesseurs tout
en confrontant les deux variables dépendantes et indépendantes dans notre sujet dont nous sommes appelés à démontrer
sur quel point le Système Informatique peut résoudre les problèmes que connaisse la gestion de stock.

O.2.1. PROBLEMATIQUE ET HYPOTHESE

Le mystère de notre travail se fait sentir dans l'introduction, car cela où la recherche devient conditionnée. Nous ne pouvons
pas parler de la problématique sans hypothèse, ils sont deux concepts qui marchent ensemble l'une à paginer de l'autre.

O.2.2. Problématique

Nous ne serons pas entreprendre notre travail sans pour autant définir la problématique ; cette dernière est définie comme
l'ensemble des problèmes posés dans un domaine de recherche, elle est aussi définie comme des questions principales
autour desquelles notre travail tournera.

Elle peut être posée d'une manière affirmative ou interrogative cependant, elle est toujours établie avant de procéder à la
recherche.

La problématique de ce travail réside dans la manipulation des activités réalisées par le magasinier ; elles sont liées aux
problèmes tels que : la perte de données, difficultés d'établir des rapports, le contrôle d'utilisation des biens ne pas assuré,
manque de système informatique.

D'où il s'avère indispensable de formuler notre problématique en différentes questions suivantes permettant de résoudre ce
problème:

- Est-ce que l'outil Informatique est il indispensable à SESOMO pour résoudre le problème de la gestion de stock ?

O.2.3. Hypothèse

Les hypothèses seront confirmées ou infirmées à la fin de notre étude, étant donné que c'est une idée directrice et une
tentative de réponse ou d'explications des faits, formulés au début de notre recherche.

Selon PINTO. R, l'hypothèse est une proposition des réponses aux questions que l'on se pose à propos de l'objet de la
recherche formulée en des termes tels que l'observateur et analyste puissent fournir une réponse justifiée de manière
provisoire.1(*)

On dénonce des réponses à la problématique en vertu de connaissance théorique ou empirique dont on dispose des
questions. La recherche consistera à confirmer ou infirmer et à accepter ou rejeter ces réponses anticipées. Elle est toujours
une relation entre les variables de la problématique.
une relation entre les variables de la problématique.

Raison pour laquelle, nous allons dans le cadre de notre présent travail, mettre en oeuvre une application qui pourra
permettre de gérer efficacement les données relatives à la gestion de stock.

- En effet, la nécessité d'automatiser la gestion s'impose dans la mesure où le nombre donnée deviennent très
considérables et consistant ;

- Au vu que l'outil informatique ou des avantages non négligeable et que la gestion automatisée est nécessaire là où il y a le
nombre élevé des données, nous pensons qu'il serait indispensable.

O.2.4. Méthodes et Techniques

L'ensemble de méthodes et techniques constitue, ce que nous appelons « la méthodologie », qui est une procédure à une
recherche scientifique que le chercheur utilise dans son investigation. Le rédacteur d'un travail scientifique est obligé de
montrer les méthodes et techniques utilisées.

0.2.4.1. Méthodes

Selon PINTO. R et GRAWITZ M ; la méthode est l'ensemble des opérations intellectuelles par lesquelles une discipline
cherche à atteindre les vérités qu'elle poursuit, les démontre et vérifie2(*)

Dans le présent travail, nous aurons à utiliser la démarche UP, un processus de développement construit sur UML, qui est
un Langage de Modélisation Unifiée, destiné à comprendre et à définir des besoins, spécifier et documenter des systèmes,
esquisser des architectures logicielles, concevoir des solutions et communiquer de point de vue en passant par trois niveaux
d'abstraction qui sont3(*) :

- Niveau Conceptuel ;

- Niveau Logique ;

- Et le niveau Physique.

0.2.4.2. Technique

La technique est un moyen mis à la disposition des méthodes pour amener à la découverte de la vérité 4(*). Quant à ce qui
est de notre travail, nous avons empruntés la technique documentaire et technique d'interview ; ces techniques nous ont
permis d'enrichir notre préoccupation.

0.2.5. Délimitation du Sujet

Pour que le travail scientifique ne soit pas vague, la déontologie scientifique, nous oblige à délimiter notre travail dans le
temps et dans l'espace. Pour cela nous allons restreindre notre sujet d'étude pour éviter de l'immerger dans un champ très
vaste.

C'est pourquoi en informatique, l'analyse tient à réaliser un système d'information tout en tenant compte de NT (Nouvelles
Technologies) à appliquer par rapport à un langage que le Concepteur juge bon. Nous signalons que notre étude est menée
en général sur la Gestion de Stock du Magasin de SESOMO Sprl/ Agence du Katanga, de l'année 2012.

CHAPITRE. I. GENERALITES
1.1. 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 commencerons 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 et énumérer les
architectures réseaux

1.2. 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, 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
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.

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

1.2.1. Présentation d'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 manque la démarche) mais plutôt
comme une boite d'outils qui sert à améliorer les méthodes de travail.

A) 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-dessous5(*):

Figure 1: les diagrammes UML

Diag. De classe

Diag. D'objet

Diag. De composants

Diag. De déploiement

Diag. De paquetages

Diag. Structures composites

Diagrammes structurels

Diag. De séquences

Diag. De communication

Diag. Global d'interaction

Diag. De temps

Diagrammes d'interactions

Diagrammes comportementaux

Diag. Des cas d'utilisation

Diag. D'états-transitions

Diag. D'activités

1.2.2. Le Processus Unifié

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.

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

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

Figure 2 : cycle de vie du processus unifié

1. Création

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.

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.

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.

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

1.3. Réseau Informatique

1.3.1. Concepts De Réseau

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

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

c) 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 les protocoles HTTP) et des serveurs web (protocole HTTP),
pour réaliser un système d'information interne à une organisation ou une entreprise.

1.3.2. Type des réseaux

On distingue différents types de réseaux (privés) selon leur taille (en termes 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.

1.3.3. 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 termes 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 etc. 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).

1.3.3.1. Fonctionnement d'un système client/serveur

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

Client

Client

SERVEUR

Réponses

Requête

Requête

Figure : 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.

1.3.3.2. Types d'architectures réseaux

Il existe trois types d'architectures des réseaux qui sont :

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

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

Niveau 1

Niveau 2

Interroger BD

Requêtes

Réponses

Figure: Architecture à 2-Tiers

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

Figure 5: Architecture 3-Tiers

Niveau 1

Niveau 2

Interroger BD

Client

Serveur d'application

Niveau 3

Serveur de BD

BD BDn

Résultats

BD BDn

Requêtes

Requêtes

Requêtes

- 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 d'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.

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

Conclusion Partielle
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.

CHAPITRE II. SPECIFICATION DES BESOINS

 CHAPITRE II. SPECIFICATION DES BESOINS
2.1. Introduction
La gestion de stock au sein du Secrétariat Social de Main d'OEuvre, est une opération nécessaire, 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 cette société
en particulier est indispensable, 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'investigation doivent être bien comprises, cernées et clarifiées.

2.2. Présentation de l'Entreprise

SESOMO (SECRETARIAT SOCIAL DE LA MAIN D'OEUVRE) Sprl, est une société qui existe au Katanga depuis 1960 dans
son sein, il a actuellement 30 agents dont 1 à l'agence de Likasi et 2 à Kolwezi, tous ceux-ci sont soumis sous direction de
Lubumbashi.

SESOMO Sprl, en tant que institution financière a pour objectif social de rendre un bon service à ses clients pour avoir une
main d'oeuvre qualifiée lui permettant de maximiser ses recettes, elle est spécialisée dans les domaines :

- La gestion du personnel, un service qui met sous le marché c'est qu'on appelle le classement : les affectations des agents
SESOMO qui travaillent sous-traitance à d'autres entreprises ;

- Et Le calcul des salaires (l'Application des lois sociales).

2.2.1. Situation Historique

- 1936 - 1939 : une vision stratégique prémonitoire

Les années 30 sont caractérisées par une extension des institutions sociales avec comme corollaire une instabilité des
textes qui les organisent. Dès cette époque, le monde des entreprises est confronté aux prestations administratives toujours
plus nombreuses et complexes.

Par ailleurs, les employeurs, absorbés par leur volonté de développer leurs activités et d'assurer ainsi la pérennité de leurs
entreprises, sont quelque peu « déstabilisés » par les implications administratives que génère la législation sociale.

Conscients de ces difficultés, quelques administrateurs de l'Association du Brabant des Entrepreneurs généraux de Travaux
publics et privés unissent leurs efforts dès 1936, pour trouver une solution à ce problème aussi complexe que délicat.

Le 20 avril 1938, il est décidé de procéder à la création d'un organisme spécialisé qui se substituerait aux employeurs du
secteur de la Construction qui en exprimeraient le désir pour accomplir en leur nom toutes les formalités administratives
exigées par les textes légaux relatifs à l'occupation de personnel.

Le 1er janvier 1939 sont rédigés la Charte constitutive et le Règlement de fonctionnement de cet organisme dénommé
« Service Social », lequel entamera son activité pour le compte de 19 employeurs occupant au total 100 ouvriers le 1er
mars 1939.

- 1940 - 1944 : consécration légale de la vision stratégique des fondateurs. Les

années du second conflit mondial n'ont pas fondamentalement ralenti le
développement du « Service Social ».
Ainsi en juillet 1940, il se voit attribuer la tenue des écritures sociales des entreprises travaillant en régie pour le compte de
l'Administration des ponts et chaussées.

A la fin 1944, environ 250 entreprises groupant quelques 3.300 ouvriers s'étaient inscrites au « Service Social ».

La promulgation de l'arrêté-loi du 28 décembre 1944 donnant un statut légal à la sécurité sociale dans notre pays ainsi que
l'arrêté organique du 16 avril 1945 organisant l'ONSS et qui prévoit le droit pour le Ministre de la Prévoyance Sociale

d'agréer des organismes compétents et qualifiés en vue de se substituer aux chefs d'entreprise dans l'exécution des
formalités sociales imposées, constitue la consécration légale d'une stratégie visionnaire et révolutionnaire initiée par
les fondateurs du « Service Social ».

- 1945 - 1946 : agrément

Constitué entre-temps en Association sans but lucratif dont les statuts sont publiés au Moniteur Belge le9 juin 1945, le
« Service Social » est le premier secrétariat social du pays à être agréé par l'arrêté ministériel du 7 mars 1946 sous le n°
« Service Social » est le premier secrétariat social du pays à être agréé par l'arrêté ministériel du 7 mars 1946 sous le n°
100. Son premier siège social est installé rue des Poissonniers 13 à 1000 Bruxelles.

Les années 50 : développement des services et expansion outre-mer

Le « Service Social » est très rapidement convaincu qu'un service personnalisé, presté quasiment à « domicile » a le plus de
chance de séduire les entreprises du pays. Outre le siège social de Bruxelles, 17 bureaux régionaux sont ouverts dans
l'ensemble du pays.

Cette stratégie d'extension et de développement est également « transportée » dans notre ancienne colonie dès1951.

En effet, au Congo, les employeurs ont également à faire face aux multiples tâches administratives qu'une législation
sociale et fiscale également en pleine expansion leur imposait. Est ainsi constitué le Secrétariat Social du Congo sous la
dénomination de Secrétariat Social de la main d'ouvre (SESOMO).

C'est ainsi en1955 par invitation des Militaires de KAMINA dans la province du Katanga, elle avait le statut d'une ONG en
collaboration avec tous les services étatiques liés à la gestion du personnel, entre autre INSS, DGI, INPP, MTPS etc.

Elle avait pour but d'aider les opérateurs économiques dans le traitement des dossiers administratifs et le calcul des
salaires. En 1960, SESOMO s'est installée à Elisabeth Ville actuellement appelé Lubumbashi, où elle traitait les mêmes
affaires, par ailleurs, le 29 Décembre 1969 par un décret loi, elle sera reconnue comme une Sprl (Société Privée à
Responsabilité Limité).

Cette société, regorge, plus de 1500 travailleurs avec lesquels, elle traite la paie de différentes Entreprises et récoltes de
différentes taxes (impôts) et cotisations de certains services de l'Etat tels que I.N.P.P, I.N.S.S etc.

Sa direction générale est à Kinshasa, après le traitement de tous les documents, les rapports journaliers, menstruels et
annuels sont envoyés à KINSHASA.

2.2.2. Situation Géographique

SESOMO Sprl/Kat, est situé au N°15 64 de l'Avenue DU 30 JUIN dans le Commune de Lubumbashi, B.P : 2624 en face de
l'Université Protestante de Lubumbashi dans la ville de Lubumbashi.

2.2.3.

DIRECTION d'AGENCE

INFORMATIQUE

BUREAU D'EXECUTION

COMPTABILITE

ARCHIVE

SECRETARIAT

SAISIE DES DONNES

DECOUPAGE

TRIAGE

CALCUL SALAIRE

ENGAGEMENT

LICENCIEMENT

GARDE ET SECURITE

RESSOURCES HUMAINES

CAISSE

FACTURATION

Organigramme

Source : SESOMO agence du katanga.

 2.2.4. Présentation du Service

Le service de gestion de stocks de SESOMO est lié à la structure du secrétariat, et reste presque sous entendu.

A) L'effectif du Magasin

La secrétaire, est la seule personne qui gère le magasin, disposant d'un nombre important de fournitures qui augmentent en
fonction des besoins de l'entreprise.

B) Mission du Magasinier

Le magasinier est chargé d'effectuer les tâches suivantes :

- Parapher des bons de sortie ;

- 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 de sa réception jusqu'au service fait (établir un bon
d'entrée, mentionner de la marchandise dans le registre d'entrée et d'inventaire) ;

- Etablir le bilan mensuel des produits en stock.

C) Situation Informatique

Le service de secrétariat, qui joue aussi le rôle de gestion de stocks, dispose d'un matériel informatique assez important. Ce
matériel est constitué d'un ordinateur HP ayant les caractéristiques suivants:

- Marque : PACKARD BELL ;

- Taille RAM : 768 Mo ;

- Type de processeur : Intel (R) Pentium (R) dual CPU 2.80 GHz ;

- Taille disque dur : 144 GO.

- Un système d'exploitation SP Professionnel.

- Écrans de « 15 et 19».

- Deux (02) imprimantes :

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

- Imprimante simple HP à jeux d'ancré d'une marque Canon IR 2018.

Un réseau intranet (transfert des mails par Outlook). La suite bureautique de Microsoft Office est utilisée pour les traitements
de textes, les bons de commande et les fiches de stocks etc.

2.2.5. Contexte du système

Pour concevoir et réaliser le système logiciel de gestion de stocks du magasin de SESOMO/l'shi, il nous était indispensable
de collecter les informations nécessaires auprès des responsables du service. 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 :

- Stocker des produits fournis ;

- L'établissement des bons de commande interne établi par les services demandeurs.

Nous allons décrire ses opérations de l'arrivée des produits, le stock et la passation de bon de commande interne auprès du
magasinier.

2.2.5.1. Circuit du Déroulement des Activités Relatives

2.2.5.1. Circuit du Déroulement des Activités Relatives

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

1. Il réceptionne les produits demandés ;

2. 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 ;

3. Etablir un bon d'entrée (bon de réception) sur lequel il saisit le numéro et la 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 ;

4. 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 ;

5. Le service de ressources humaine constate ;

6. Enfin le magasinier stocke les produits;

7. Le Service demandeur passe le bon de commande ;

8. Le magasinier vérifie la disponibilité, si oui acquise la réception, si non informe, le demandeur

9. Si oui la direction vise le bon ;

10. Et le magasinier remet les produits au service demandeur.

NB : Lorsque le stock diminue, le magasinier informe le Service de Ressources Humaines.

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

SERVICE DE RESSOURCES SERVICE

FOUNISSEUR MAGASIN DIRECTION
HUMAINES DEMANDEUR

FOURNIR PRODUIT

RECEPTION PRODUIT

SI OUI

SI NON

ENREGISTRER PRODUIT

CONSTATE

PRODUIT

STOCKER PRODUIT

PASSER BON

VOIR DISPONIBILITE

SI OUI

SI NON

INFORME LE DEMANDEUR

ACQUISE RECEPTION

VISER LE BON

REMETTRE PRODUIT
2.2.5.2. Diagnostic de la Situation Actuelle

Après avoir fini l'étude de contexte du domaine d'étude lié au magasin de SESOMO, 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.

Tableau 1: Anomalies et Suggestions

Plan Anomalies Suggestions

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

Le système d'information actuelle de SESOMO, est non encore automatisé, toute fois les tâches et procédures
administratives de l'organisation qui contrôle et traite les mouvements de stocks sont manuelles, ce qui rend la tâche du
magasinier fastidieuse et complexe, 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.

2.2.5.4. Propositions

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

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.

Notre choix s'est porté sur d'abord la 1ère et après la 2ième proposition, vu que le futur système à concevoir sera d'une part,
accessible au temps avenir par :

- Les différentes structures Départementales liées au stock ;

- Le Magasinier de SESOMO, 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 SESOMO possédant des services Informatiques
Moyennes. La deuxième proposition aurait pu être exploitée. Néanmoins, nous avons commencé avec la première à cause
d'expérimentation nous exigées et performances, puis suivra le déploiement avec la deuxième dans les jours avenirs.

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

TACHES MANUELLES SYSTEME INFORMATIQUE

Sur des fiches dans un Sur un disque :

carton :
- Possibilité de faire plusieurs copies ;
- Encombrant ;
- Sécurité de l'information ;
- Risque de détoriation.
- Accès à l'information (rechercher la facture d'une ancienne date).
Recherche Manuelle ; bon - la machine effectue une recherche rapide et instantanée pour l'utilisateur ;
par bon (lente)
- Traitement ( établir une fiche de l'état de stock,par produit ou par service ou par période)
- Difficile et risque Calcul automatique sans risque d'erreur.
d'érreur ;
 d'érreur ;

- Traitement lent.
Stockage des produits - Enregistrer produits ;

- Etablissement des bons, Stocker une grande masse d'information (facture, bons de
commandes internes, bons de sorties, bon d'entrées, etc.).

Tableau 2: Comparaison de deux SI, Manuel et Informatique

Source : SESOMO Agence du Katanga

2.2.5.6. 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, en prenant de bonne décision sur les
quantités des produits à commander en fonction du taux de consommation des services pour chaque produit.

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

Application GestionStock

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.

a) 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 et enfin mettre à jour l'état du stock, des produits ;

- Le Service Demandeur : peut établir et éditer les bons de commandes.

Conclusion Partielle
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, mais aussi de nous familiariser avec les différentes activités et traitements qui se font au sein du 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.

CHAPITRE III. ANALYSE DES BESOINS

3.1. 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 Informatique à développer.

3.2. Modèle Du Système

Le système à concevoir est régi par une application qui fonctionnera sur un poste (Monoposte) dans un premier temps et
sera accessible par seul le magasinier, qui en sera l'administrateur principal.

- Le Magasinier: l'administrateur de l'application.

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

Figure 1 : Diagramme du cas d'utilisation gestion de stock

Description des différents cas d'utilisation

- Authentifier : Permet à un acteur de s'authentifier avant d'accéder à l'application ;

- 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 et enregistrement ;

- 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 et l'enregistrement ;

- Edition : Permet à l'acteur d'éditer différents documents (bon de commande interne, bon de sortie, bon d'entrée).

3.3. Besoins Fonctionnels et Non Fonctionnels

Le système dont le magasin de SESOMO 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 acteur 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.

3.3.1. Besoins Fonctionnels

Pour ces besoins fonctionnels, nous avons utilisé pour notre cas les use case.

Un Use case : Est ensemble d'actions réalisées par le système, en réponse à une action d'un acteur.

· Les uses cases peuvent être structurés ;

· Les uses cases peuvent être organisés en paquetages (packages);

· L'ensemble des use cases décrit les objectifs (le but) du système.6(*)

L'objectif poursuivi par les cas d'utilisation est de permettre, de décrire, dans des documents lisibles par tous, la finalité des
interactions du système et de ses utilisateurs. Les services attendus de l'application sont décris par les USE CASE suivants
:

1. Ajouter

Modifier

Supprimer

Imprimer

Authentifier

« extend »

« extend »

« extend »

« include »»

Magasinier
Magasinier

Gérer les bons de sorties

Figure 2: Cas d'utilisation Gérer les Bons de Sorties

Description textuelle de cas d'utilisations

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

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

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

- Imprimer un bon de sortie : le système permet au magasinier de lancer des impressions des bons établis.

2. Gérer les bons d'entrées

Ajouter

Modifier

Supprimer

Imprimer

Authentifier

« extend »

« extend »

« extend »

« include »»

Magasinier

Figure 3: 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.

- Imprimer un bon d'entrée : revient à lancer des impressions des bons établis.

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

2. Magasinier

Ajouter
Imprimer

Modifier

Authentifier

« extend »

« extend »

« include »»

Supprimer

Edition des Bons

Figure 4 : Cas d'utilisation Edition

Description textuelle des cas d'utilisation

- Edition de bon d'entrée : Permet d'ajouter, modifier et d'imprimer un bon d'entrée.

- Edition de bon de sortie : Permet d'ajouter, modifier et d'imprimer un bon de sortie.

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

3.4. Diagramme d'Etat-Transition du Système Informatique

Les diagrammes d'états-transitions d'UML décrivent le comportement interne d'un objet à l'aide d'un automate à états finis.
Ils présentent les séquences possibles d'états et d'actions qu'une instance de classe peut traiter au cours de son cycle de
vie en réaction à des événements discrets (de type signaux, invocations de méthode).

Concrètement, un diagramme d'états-transitions est un graphe qui représente un automate à états finis, c'est-à-dire une
machine dont le comportement des sorties ne dépend pas seulement de l'état de ses entrées, mais aussi d'un historique des
sollicitations passées.7(*)

0. Diagramme d'Etat-Transition pour l'Opération : Nouveau Produit

- Initialisation : Après l'achat des marchandises achetées ;

- Exécution : Au moment de stockages des produits ;

- Clôture : Se clôture à la fermeture du système.

Description textuelle

Ce diagramme montre comment le déroulement de la transition de l'objet Produits s'effectue. Débute par être ajouté et son
arrestation. Cette opération peut être annulée pendant son déroulement.

1. Diagramme d'Etat-Transition pour l'opération : Modifier un Produit

- Initialisation : Est le constat d'un produit à modifier ;

- Exécution : Dès l'effectuation de cette modification sur les données ciblées ;

- Clôture : La clôture intervient juste après la modification des données.

Description Textuelle

Ce schéma est le déroulement de l'opération modifier un produit. En fait à ce niveau, la modification peut intervenir juste
après l'enregistrement des produits dans le stock et lorsqu'on constate qu'il y a un produit à modifier. Nous pouvons arrêter
cette modification après avoir modifié un élément dans le système. Et pendant cette opération, il peut nous arriver qu'on
puisse annuler pendant que le déroulement est entrain de s'opérer.

2. Diagramme d'Etat-Transition pour l'opération : Supprimer un Produit

- Initialisation : Dès qu'on croit qu'il ya nécessité de supprimer un produit suite une erreur quelconque ;

- Exécution : A la suppression d'élément ciblé ;

- Clôture : Dès que la suppression est effectuée.

3. Diagramme d'Etat-Transition pour l'opération : Imprimer un Bon

- Initialisation : Dés qu'on sent qu'il faut imprimer ;

- Exécution : A l'impression des données ciblées ;

- Clôture : lorsque la suppression est réalisée.

Description Textuelle

Ce diagramme nous fait voir comment se réalise le déroulement de lancement de l'impression, pendant cette exécution il
peut arriver qu'on puisse annuler l'impression. Sinon arrêter pour quitter le système.

3.5. 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 restent dans le même ordre d'idée avec les interfaces du futur système.
1. Prototype de l'interface-homme machine gestion des entrées

Figure 6: Interface gestion des entrées

2. Prototype de l'interface-homme machine gestion des sorties

Figure 7: Interface gestion des sorties

3. Prototype de l'interface homme-machine gestion des produits

Figure 8 : Interface gestion des produits

3.6. Réalisation des Diagrammes de Séquences

3.6.1. Diagramme de Séquence du cas d'utilisation Authentifié

Description textuelle du scénario

Lorsque l'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 à 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.

3.6. Réalisation des Diagrammes de Séquences du Système Informatique

3.6.1. Diagramme de séquence du cas d'utilisation authentifiée

Description textuelle du scénario

Lorsque un utilisateur souhaite se connecter au système, 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, accède au système, sinon un message d'erreur est
informations introduites, si le login et le mot de passe sont valides, accède au système, sinon un message d'erreur est
affiché le sollicitant de ressaisir ses coordonnées. Ce processus de vérification ce répétera autant de fois que l'utilisateur
communique des informations erronées.

3.6.2. Diagramme de séquence du cas d'utilisation éditer un bon de sortie

Description textuelle du scénario

Le magasinier demande l'édition d'un bon de sortie au système. Le système lui affiche une fenêtre d'édition, il édite le bon
puis valide.

3.6.3. Diagramme de séquence du cas d'utilisation modifié un bon de sortie

Description textuelle du scénario

Le magasinier clic sur bouton modifier, le système affiche la fenêtre des modifications. Le magasinier saisie les
modifications et applique, le système lui demande s'il veut garder ces modifications et clic sur ok pour valider sinon, il clic
sur annuler.

3.6.4. Diagramme de séquence du cas d'utilisation supprimé un bon d'entrée

Description textuelle du scénario

Le magasinier demande au système la suppression d'un produit sélectionné. Le système lui laisse le choix, soit de
supprimer, soit de refuser.

3.6.5. Diagramme de séquence de cas d'utilisation imprimer un bon de sortie

Description textuelle du Scenario

Le magasinier clic sur bouton imprimer, le système affiche la fenêtre de saisie, le magasinier saie les données, applique et
clic sur imprimer, le système affiche l'état à imprimer, le magasinier clic sur imprimante, le système affiche le menu
imprimante puis le magasinier choisi la marque d'imprimante et valide l'impression.

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

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 Partielle
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 et REALISATION DU PROJET», que nous allons détailler
dans le chapitre suivant.

CHAPITRE IV. CONCEPTION ET REALISATION DU

PROJET
4.1. 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.

4.2. Réalisation des diagrammes de classe du Système Informatique

Cette réalisation de diagrammes de classe montre la passation des différentes opérations; nous avons voulu le présenter
dans nos pages suivantes en se basant 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. Par ce que les liens qui les relient tiennent compte
des règles de gestion.

1. Diagramme de classe : Cas d'utilisation Gérer bon Sortie

2. Diagramme de Classe : Cas d'utilisation Gérer bon Sortie

3. Diagramme de classe : Cas d'utilisation Edition

4.3. Diagramme de classe conceptuelle

Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire
lors d'une telle modélisation. Alors que le diagramme de cas d'utilisation montre un système du point de vue des acteurs, le
diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du
diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du
système qui vont interagir ensemble pour réaliser les cas d'utilisation.8(*)

4.4. 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 sortie est associé à un et un seul bon de commande interne ;

2. Un bon de sortie contient un ou plusieurs produits ;

3. Un produit peut figurer dans un bon de sortie une ou une seule fois;

4. Un bon d'entrée peut avoir un ou plusieurs produits ;

5. Un produit peut avoir un ou plusieurs bons d'entrée.

4.4.1. 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 Taille Observation

Gestion_de_Sorties IDSortie Le Numéro de bon numérique 4 9999999
RefP C'est la Référence du Produit Texte 50
NomAgent C'est le nom de l'agent qui passe le bon interne Texte 50
DesigneP C'est la désignation du Produit Texte 50

QuantitéD C'est la quantité du produit demandé Numérique 4 9999999

Date C'est la date à laquelle a été passé la Date 8 JJ/MM/AAA
commande A
Gestion_des_Entrées IDEntrée Numéro entrée numérique 4 9999999
RefP C'est la Référence du Produit Texte 50
QteEntrée C'est la quantité du produit enregistré Numérique 4 9999999
Date C'est la date à laquelle a été enregistré le Date 8 JJ/MM/AAA
produit A
Observation C'est le constat Texte 50
Stock IDStock Numéro stock numérique 4 9999999
DesineP C'est le nom du produit Texte 50
QteEntrée C'est la quantité de produit Entrées Numérique 4 9999999
QteS C'est la quantité des produits sortis Numérique 4 9999999
Date Date Date 8 JJ/MM/AAA
A
 A
Solde C'est la quantité qui reste Numérique 4 99999999

4.4.2. Représentation des Rubriques des fichiers

- Gestion des Sorties

- Gestion des Entrées

- Stock

NB : Avec WINDEV au lieu de A = alphabétique, AN = alphanumérique. On a Texte et Numérique.

4.4.3. Le Modèle Logique de Données

Après l'application des règles de transformations et de passage aux diagrammes 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 :

Gestion_des_Entrées(#IDEntree, RefP, QteEntrée, Date, Observation) ;

Gestion_de_Sorties (#IDSortie, RefP, NomAgent,DesigneP, QteS, Date) ;

Stock (#IDStock ; DesineP , Date, QteEntrée, QteS, Solde).

4.4.4. 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;

- Une association « un à plusieurs» engendre la migration de la clé primaire de la table mère à la table fille ;

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

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

4.5. Réalisation
 4.5. Réalisation
A ce stade du processus, les cas d'utilisations 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.

4.5.1. Environnement de Développement de l'application

Pour réaliser notre application, nous avons utilisé le langage de programmation Wlangage adapté à la création des
applications de Gestion, de web dynamique etc. Celui-ci nous l'avons manipulé et étudié lors de notre stage effectué à
SESOMO, dans un environnement de développement intitulé WINDEV, qui est largement compatible avec DotNet, PHP,
Java et autres.

Par ailleurs, il faut noter que les pages écrites en WLangage sont à chaque fois testées grâce à une plate forme de
développement spécifique. La plate forme que nous avons adoptée est L'HyperFil Classic version 10.0 qui inclut tous les
outils nécessaires pour le test voir même d'un site web dynamique.

Cet outil est menu voir même des interfaces ergonomiques, dans son catalogue d'images pour les applications.

4.5.2. Outils de Développement

1. Windev

Un langage de 5ème génération, facile, puissant :

WLangage
Apparu en 1992 (dernière révision en 2012)
Auteur PC SOFT
Paradigme procédural, structuré, orienté objet
Typage statique, dynamique, faible
Influencé par BASIC, Pascal, C++
Implémentations WinDev, WebDev, WinDev Mobile
Multiplate-forme ( Windows, Windows CE, iOS,
Système d'exploitation
Linux)

Le WLangage est un langage de programmation de 4e génération . Inclus dans les outils de développementWinDev,
WebDev et WinDev Mobile. Il est propriétaire et ne peut être manipulé qu'avec les outils PC SOFT. Le WLangage est né en
1992 avec la première version de WinDev.
Même s'il y a explicitement une première phase précoce de compilation, le bytecode WLangage est exécuté par une
machine virtuelle ou converti en code natif lors de l'exécution par un compilateur à la volée (just in time, JIT). Le framework
est disponible sous Windows (32 bits, 64 bits et CE), sous iOS (iPhone et iPad) et sous Linux.

Le WLangage peut également s'appuyer sur le framework Java pour une partie de ses fonctionnalités, ce qui permet une
indépendance relative et limitée du fichier exécutable par rapport au système d'exploitation cible. Il en va de même dans
WebDev, où le WLangage peut s'appuyer sur le frameworkPHP, sans toutefois permettre d'utiliser toutes les possibilités de
ce dernier. Initialement prévu pour Windows, une partie des fonctions du WLangage est basée sur l' API.9(*)

4.5.3. Programmation

Le WLangage est un langage de programmation procédurale qui permet la programmation impérative et la programmation
orientée objet. C'est en fait un langage de programmation multi-paradigme.

Le WLangage contient des fonctions de haut niveau, telle que la fonction EcranVersFichier, qui effectue les affectations du
contenu des champs d'une fenêtre vers des tables stockées dans un fichier ou des variables, auxquelles les champs ont été
préalablement reliés (databinding).

A) Typage

Le WLangage autorise une utilisation souple du typage. Les variables doivent être typées mais les paramètres formels des
procédures ou les itérateurs de boucles peuvent ne pas l'être. Il est ainsi possible dans un même projet de combiner des
procédures ou les itérateurs de boucles peuvent ne pas l'être. Il est ainsi possible dans un même projet de combiner des
procédures avec typage strict pour profiter de la rigueur du typage statique et des procédures sans typage pour profiter de la
souplesse du typage dynamique et du duck typing.

B) Orientation Objet

Le WLangage permet l'utilisation de classes et inclut entre autres :

· l' encapsulation (public, protégé, privé) ;

· la composition de classes ;

· l'association de classes ;

· l' héritage multiple ;

· l' abstraction et le polymorphisme.

Limitation importante : il est impossible de créer des classes qui hériteraient des éléments graphiques de base (appelés
champs dans la terminologie WinDev). En fait, ces champs ne peuvent pas être instanciés ni manipulés comme des objets:
il n'y a pas la possibilité d'ajouter par programmation un champ à un écran vierge autrement que par copie d'un champ déjà
existant (clonage) ou via des API.

C) Gestion des Instances

L'allocation des instances est toujours dynamique, que la variable objet soit une variable locale, une variable globale, un
membre de classe ou que l'instance soit créée par l'ordre allouer (new si on code en anglais). Une variable ou un membre
objet manipule en fait une référence sur l'instance. Lorsqu'une instance est créée, son constructeur est exécuté.

La gestion des instances se fait par comptage de références, c'est-à-dire que chaque instance possède un compteur du
nombre de variables ou de membres qui la manipulent. Lorsque plus aucune variable ou membre ne manipule une instance,
son compteur de références arrive à 0, son destructeur est exécuté et l'instance est libérée. Dans la grande majorité des
cas, il n'est donc pas nécessaire de se préoccuper de la libération des instances allouées, quelle que soit la méthode
d'allocation. Cette technique permet l'exécution du destructeur lorsqu'une instance n'est plus utilisée, ce qui permet de
libérer rapidement les ressources utilisées par l'instance (socket, fichier, ...). Dans le cas de références circulaires entre
instances, il est nécessaire de forcer la libération d'une instance du cycle par l'ordre libérer (delete si on code en anglais)
pour libérer les autres instances du cycle.

D) Gestion des Erreurs et des Exceptions

Le WLangage se différencie d'autres langages en distinguant deux catégories d'erreurs qui peuvent survenir lors de
l'exécution et en proposant des mécanismes automatiques de traitement des erreurs.

Une erreur, ou erreur non fatale, est une erreur qui se produit en conditions normales lors de l'exécution. Par exemple
l'échec de l'ouverture d'un fichier est une erreur non fatale, l'exécution continue pour permettre le traitement de l'erreur.
L'erreur peut être traitée par programmation, comme dans la majorité des autres langages, en testant la valeur de retour de
la fonction appelée ou en vérifiant une variable d'état (nommée ErreurDétectée). Cependant l'intérêt du WLangage repose
sur toute une panoplie de traitements automatiques sans programmation qui permettent de gérer les erreurs qui se
produisent dans une procédure :
· poursuite de l'exécution de la procédure au label spécifique CAS ERREUR ;

· sortie de la procédure en renvoyant une valeur d'échec prédéfinie et/ou en relayant l'erreur à l'appelant ;

· affichage du message d'erreur avec différentes propositions pour l'utilisateur : réessaie l'opération (utile pour les erreurs de
fichiers par exemple), fin de l'application, ...

· exécution d'une procédure.

Une exception, ou erreur fatale, est une erreur qui se produit en conditions anormales lors de l'exécution. Par exemple
l'accès au troisième élément d'un tableau n'en contenant que deux génère une exception, l'exécution en cours s'interrompt
de la même manière qu'en C++ ou C#. L'exception peut être traitée par programmation grâce aux instructions QUAND
EXCEPTION et QUAND EXCEPTION DANS. Dans ce cas également, WinDev propose des traitements automatiques sans
programmation :

· poursuite de l'exécution de la procédure au label spécifique CAS EXCEPTION

· exécution d'une procédure

e) Bilingue

Le WLangage permet de programmer en français et en anglais. Exemple :

sChaine est une chaîne

sChaine est une chaîne

sChaine = DateVersChaine(DateDuJour())

Info("Nous sommes le " + sChaine)

ou en anglais :

sChaine is string

sChaine = DateToString(Today())

Info("Nous sommes le " + sChaine)

Il est possible de traduire automatiquement le code d'une langue à l'autre. Par ailleurs, l'environnement permet la traduction
des zones de saisie et des textes utilisés dans la programmation et destinés à l'utilisateur final de l'application (jusqu'à 20
langues dans un même programme).10(*)

1.1. Hello world

Info("Hello world!")

4.5.4. Base des Données

4.5.4.1. Implémentation de la base de Données

Pour implémenter notre base des données «GestionStock», nous avons utilisé l'environnement de création de base des
données Hyper File Classic. Est un système de gestion de base de données relationnel exploité par les logiciels WinDev,
WebDev et Mobile. Il est propriétaire et est lié à l'utilisation des produitsPC SOFT. Sa diffusion est autorisée avec les
applications développées avec les logiciels PC SOFT.11(*)

HyperFileSQL Classic est un SGBD fichier. L'accès aux données est géré par l'application cliente. La première version est
apparue vers 1988. Il permet de joindre les fichiers dans le répertoire de l'application, dans un dossier de la machine ou sur
un serveur (voire sur un support amovible pour une utilisation nomade). Il est utilisé pour des applications monopostes ou
des applications multipostes; les blocages en lecture/écriture sont gérés par des commandes WLangage.
Le tableau ci-dessous présente la création de notre base de données :

4.5.4.2. La sécurité de l'application

On applique également la fonction GPWlogin () 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 GPWlogin du bon mot de passe qui se trouve dans notre base de données.

Ce déroulement est représenté par le graphique suivant :

4.5.4.3. Architecture Matérielle Mise en Place

Dans le premier temps, tenant compte des exigences imposées nous allons utiliser l'architecture MONOPOSTE. 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.

Pour ce nous recommandons à SESOMO de disposer au moins :

- Une machine de préférence marque Desck Top DELL ;

- Disque dur 350Gb et Processeur Geniune Intel ® 575 2.00GHz

- Mémoire (2 Gb) ;

- Type du système : 32Bits.

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

4.6.1. Test du cas d'utilisation « Authentification »

L'utilisateur possède son propre « login » et mot de passe « password ». Pour tester ce cas d'utilisation, nous avons lancé
l'application et il nous affiché le menu du login à remplir les champs spécifiques pour le login et le mot de passe avec un
l'application et il nous affiché le menu du login à remplir 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.

Montré dans cette capture d'écran de l'application :

4.6.2. Test du cas d'utilisation « Editer 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 :

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 «1» dans la base de données, la vérification est
réussie.

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

4.6.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 1, 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.

4.6.5. 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.
 Conclusion Partielle
Dans ce chapitre, nous avons décrit brièvement le processus de réalisation de notre application Gestion Stock 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 d'utilisateur.

Conclusion Générale
La phase de conception du projet a duré plus que nous l'avions prévue. En effet, il nous 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, pendant cette période, il nous était demandé d'assimiler le contexte du travail à accomplir. Accompagnés
par le chef du magasin, la SESOMO, 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.

La phase d'analyse, 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 SESOMO 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 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 SESOMO. Nous souhaitons que cette application soit admissible
voir même pour d'autres organismes que SESOMO dans les jours avenirs.

Bibliographie

I. Ouvrages et Dictionnaire
1. Dictionnaire PETIT LAROUSSE ; 2006.

2. MULUMBATI NGASHA ; Introduction à la Science Politique, Ed africa 2006.

3. PASCAL ROQUES ; UML2.x. Les Cahiers de Programmeur, Modéliser une Application Web ; 4ième Ed Eyrolles ,
2008,p4.

4. PINTO R. et GRAWITZ M ; Méthodes de sciences sociales, Paris. Dallas ;1985.

5. PINTO. R ; Sociologie Générale, Ed Africa. 1982.

II. Site Internet

0. http://fr.wikipedia.org/wiki/Unified_Modeling_Language

1. Uml.free.fr/cours/ip13.html

2. UML 2 - Laurent Audibert - http://laurent-audibert.developpez.com/Cours-UML/

3. UML 2 - Laurent Audibert - http://laurent-audibert.developpez.com/Cours-UML/

4. http :fr.wikipedia.org/wiki/WLangage.

5. www.pcsoft.fr

Annexe
5.1. CODES DE L'APPLICATION
a) MENU PRINCIPAL

- Selection du Menun de Menu.Fichier.Config

// configuration de l'imprimante par défaut

iConfigure(Faux)

- Selection du Menun de Menu.Fichier.Quitter

// termine l'application en fermant la fenêtre

Ferme()

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_de_Sorties

// ouverture de la fenêtre fille "Fiche_Gestion_de_Sorties"

Ouvre(Fiche_Gestion_de_Sorties)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_de_Sorties

// ouverture de la fenêtre fille "Table_Gestion_de_Sorties"

Ouvre(Table_Gestion_de_Sorties)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_de_Sorties.Imprimer

// prévisualisation de l'état "Etat_Table_Gestion_de_Sorties"

iAperçu(100)

iImprimeEtat(Etat_Table_Gestion_de_Sorties)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_des_Entrées

// ouverture de la fenêtre fille "Fiche_Gestion_des_Entrées"

Ouvre(Fiche_Gestion_des_Entrées)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_des_Entrées
// ouverture de la fenêtre fille "Table_Gestion_des_Entrées"

Ouvre(Table_Gestion_des_Entrées)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_des_Entrées.Imprimer1

// prévisualisation de l'état "Etat_Table_Gestion_des_Entrées"

iAperçu(100)

iImprimeEtat(Etat_Table_Gestion_des_Entrées)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_de_Stock

// ouverture de la fenêtre fille "Fiche_Stock"

Ouvre(Fiche_Stock)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_de_Stock

// ouverture de la fenêtre fille "Table_Stock"

Ouvre(Table_Stock)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_des_Entrées.Imprimer2

// prévisualisation de l'état "Etat_Table_Stock"

iAperçu(100)

iImprimeEtat(Etat_Table_Stock)

- Selection du Menu.M_Gestion_de_Sorties.OPT_Fiche_Gestion_des_Entrées.Imprimer3

// prévisualisation de l'état "Etat_Table_Gestion_des_Entrées"

iAperçu(100)

iImprimeEtat(Etat_Table_Gestion_des_Entrées)

- Selection du Menu de Menu_WindevHelp.Menu_Interrogation_1

// ouvre le fichier d'aide correspondant à la langue en cours

SELON Nation()

CAS nationFrançais : LanceAppliAssociée("Aide GestionStockharris005.chm")

FIN

- Selection du Menu de Menu_WindevHelp.Menu_Interrogation_9

// Adresse mail où doivent être envoyés les incidents

// ProjetInfo(piEMailApplication) renvoie l'adresse mail saisie dans l'assistant de création du menu ?,

// ou dans l'assistant de création d'exécutable

// Vous pouvez remplacer cette valeur pour modifier l'adresse mail si vous le souhaitez.

sMail est une chaîne = ProjetInfo(piEmailApplication)

CCFeedback.Configure(fbEmail,sMail)

// Création et envoi du nouvel incident

CCFeedback.NouvelleDemande()

- Selection du Menu de Menu_WindevHelp.Menu_Interrogation_9

Ouvre(FEN_APropos)

b) Codes Fenêtre Gestion des Sorties

- Clic sur nouveau

- Clic sur nouveau

// vérification des modifications de la fiche

VerifModification()

// passe en mode création

ModifModeFenetre("Création")

// demande de confirmation

SI OuiNon(Non,"Voulez-vous vraiment supprimer l'enregistrement ?") ALORS

// suppression

HSupprime(Gestion_de_Sorties)

SI ErreurDétectée ALORS

Erreur("Impossible de supprimer l'enregistrement."+RC+HErreurInfo())

RETOUR

FIN

- Clic sur Supprimer

// On indique qu'un enregistrement a été modifié (le rafraichissement des données sera nécessaire)

gbFenetreModifiee = Vrai

// lecture de l'enregistrement suivant

HLitSuivant(Gestion_de_Sorties,IDGestionSortie)

// si l'enregistrement supprimé était le dermier enregistrement

SI HEnDehors() ALORS

// lecture du dernier enregistrement

HLitDernier(Gestion_de_Sorties,IDGestionSortie)

// il n'y a plus d'enregistrement dans le fichier

SI HEnDehors() ALORS

// vide les champs

RADEfface()

// informe l'utilisateur que le fichier est vide

Info("Le fichier est vide")

// terminé

RETOUR

FIN

FIN

// transfert du buffer du fichier dans les champs

RADAffiche()

FIN

- Clic sur imprimer

// prévisualisation de l'état fiche

iAperçu(100)
iInitRequêteEtat("Etat_Fiche_Gestion_de_Sorties",Gestion_de_Sorties.IDGestionSortie)

iImprimeEtat("Etat_Fiche_Gestion_de_Sorties")

- Clic sur appliquer

// Application de la modification

VerifModification()

- Clic sur fermer

// fermeture de la fenêtre sans rien faire

Ferme("",gbFenetreModifiee)

- Déclaration globales de fiche_de_stock

// Ouverture de la fenêtre de type Fiche

// Entrée: ModeOuverture=mode d'ouverture de la fenêtre :

// - "Parcours" Visualisation de tous les enregistrements

// grâce aux boutons de parcours

// - "Modif" Modification de l'enregistrement en cours

// - "Création" Création d'un nouvel enregistrement

// - "ParcoursLié" Parcours du fichier en liaison avec la fenêtre mère

// (avec suppression et création)

PROCEDURE FicheRAD(ModeOuverture="Parcours")

GLOBAL

gNumEnr est un entier = 0 // enregistrement en cours dans le fichier

gModeFenetre est une chaîne // mode de la fenêtre

gbFenetreModifiee est un booléen = Faux // Est-ce qu'un enregistrement a été modifié ?

gsModeAppel est une chaîne = ModeOuverture // Mode d'appel de la fenêtre

// Gestion des erreurs d'accès à la base de données

// Les messages d'erreurs renvoyés par la base sont affichés

// Vous pouvez traiter ici les compte-rendu d'erreurs de votre base

QUAND EXCEPTION

Erreur("Une erreur est survenue dans la fenêtre",ExceptionInfo(errMessage))

// On réactive les exceptions

ExceptionActive()

// On reprend le traitement

RepriseSaisie()

FIN

Initialisation de fiche Gestion_de_Sortie

// si la fiche est ouverte en mode parcours

// mais que le fichier n'a aucun enregistrement

// passe automatiquement en mode création

SI (ModeOuverture="Parcours" OU ModeOuverture~="ParcoursLié") ET HNbEnr(Gestion_de_Sorties)=0 ALORS

// ouvre une boite de dialogue pour informer l'utilisateur

Info("Le fichier ne contient aucun enregistrement.","La fiche va passer en mode 'Création'.")

// changement de mode d'ouverture

ModeOuverture="Création"

FIN

// activation des champs selon le mode de la fenêtre

ModifModeFenetre(ModeOuverture)

c) Fenêtre de login ( déclaration globale GPWLogin)

// Fenêtre de Login

//-----------------------------------------------

EXTERNE GPWUtilisateur

EXTERNE GPWUtilisateurConfiguration

EXTERNE GPWConfiguration

EXTERNE GPWConfigurationElement

EXTERNE GPWElement

//-----------------------------------------------

GLOBAL

gnNbEssai est un entier = 0 // nombre d'essai

gbAvecConfirmation est un booléen = Vrai // Vrai si la fenêtre affiche le champ de confirmation de mot de passe

CONSTANTE nNBESSAISMAX = 3 // nombre d'essais maximum

CONSTANTE nMODIFHAUTEUR =30 // différence de hauteur lorsque la fenêtre est agrandie

// pas de confirmation de mot de passe à l'ouverture de la fenêtre

AvecConfirmation(Faux.

d) Initialisation de la fenêtre GPWLogin

// Fenêtre de Login

//-----------------------------------------------

EXTERNE GPWUtilisateur

EXTERNE GPWUtilisateurConfiguration

EXTERNE GPWConfiguration

EXTERNE GPWConfigurationElement

EXTERNE GPWElement

//-----------------------------------------------

GLOBAL

gnNbEssai est un entier = 0 // nombre d'essai

gbAvecConfirmation est un booléen = Vrai // Vrai si la fenêtre affiche le champ de confirmation de mot de passe

CONSTANTE nNBESSAISMAX = 3 // nombre d'essais maximum

CONSTANTE nMODIFHAUTEUR =30 // différence de hauteur lorsque la fenêtre est agrandie

CONSTANTE nMODIFHAUTEUR =30 // différence de hauteur lorsque la fenêtre est agrandie

// pas de confirmation de mot de passe à l'ouverture de la fenêtre

AvecConfirmation(Faux)

Table des Matières

EPIGRAPHE Erreur ! Signet non défini.

DEDICACE II

REMERCIEMENTS III

AVANT PROPOS IV

Résumé V

0. INTRODUCTION GENERALE 6

0.1. CHOIX ET INTERET DU SUJET 6

0.1.1. Sur le plan Personnel 6

0.1.2. Sur le plan Scientifique 6

0.1.3. Sur le Plan social 6

0.2. ETAT DE LA QUESTION 6

0.2.3. PROBLEMATIQUE ET HYPOTHESE 7

0.2.4. Méthodes et Techniques 8

0.2.5. Délimitation du Sujet 8

CHAPITRE. I. GENERALITES 10

1.1. Introduction 10
1.2. Le Processus Unifié et UML 10

1.2.1. Présentation d'UML 10

1.2.2. Le Processus Unifié 11

1.2.3. Les Principes d'UP 12

1.2.4. Les Phases Du Processus Unifié 12

1.3. Réseau Informatique 13

1.3.1. Concepts De Réseau 13

1.3.2. Type des réseaux 14

1.3.3. Présentation de l'architecture client/serveur 14

Conclusion Partielle 17

CHAPITRE II. SPECIFICATION DES BESOINS 18

2.1. Introduction 18

2.2. Présentation de l'Entreprise 18

2.2.1. Situation Historique 18

2.2.2. Situation Géographique 20

2.2.3. Organigramme 21

2.2.4. Présentation du Service 22

2.2.5. Contexte du système 23

Conclusion Partielle 28

CHAPITRE III. ANALYSE DES BESOINS 29

3.1. Introduction 29

3.2. Modèle Du Système 29

3.3. Besoins Fonctionnels et Non Fonctionnels 30

3.3.1. Besoins Fonctionnels 30

3.3.2. Besoins Non-fonctionnels 33

3.4. Diagramme d'Etat-Transition du Système Informatique 33

3.5. La Démarche du Prototypage 36

3.6. Réalisation des Diagrammes de Séquences 38

3.6.1. Diagramme de Séquence du cas d'utilisation Authentifié 38

3.7. Réalisation des Diagrammes de Séquences du Système Informatique 38

3.7.1. Diagramme de séquence du cas d'utilisation authentifiée 38

3.7.2. Diagramme de séquence du cas d'utilisation éditer un bon de sortie 39

3.7.3. Diagramme de séquence du cas d'utilisation modifié un bon de sortie 39

3.7.4. Diagramme de séquence du cas d'utilisation supprimé un bon d'entrée 40

3.7.5. Diagramme de séquence de cas d'utilisation imprimer un bon de sortie 40

3.8. Risques Critiques 41

Conclusion Partielle 41

CHAPITRE IV. CONCEPTION ET REALISATION DU PROJET 42

4.1. Introduction 42

4.2. Réalisation des diagrammes de classe du Système Informatique 42

4.3. Diagramme de classe conceptuelle 43

4.4. Règles de Gestion 44

4.4.1. Dictionnaire des données 44

4.4.2. Représentation des Rubriques des fichiers 45

4.4.3. Le Modèle Logique de Données 47

4.4.4. Règles de Passages 47

4.4.5. Règles de Normalisation 47

4.5. Réalisation 47

4.5.1. Environnement de Développement de l'application 47

4.5.2. Outils de Développement 48

4.5.3. Programmation 48

4.5.4. Base des Données 51

4.6. Test... ......................................................................................................................................................... 52

4.6.1. Test du cas d'utilisation « Authentification » 52

4.6.2. Test du cas d'utilisation « Editer un bon de sortie » 53

4.6.2. Test du cas d'utilisation « Editer un bon de sortie » 53

4.6.3. Test du cas d'utilisation « Modifier un bon de sortie » 54

4.6.4. Test du cas d'utilisation « supprimer un bon de sortie » 54

4.6.5. Test du cas d'utilisation « imprimer un bon de sortie» 54

Conclusion Partielle 55

Conclusion Générale 56

A. Bibliographie 57

B. Site Internet 57

5. Annexe 58

5.1. CODES DE L'APPLICATION 58

Table des Matières 61

* 1 PINTO. R ; Sociologie Générale, Ed Africa. 1982.p12.

* 2 PINTO R. et GRAWITZ M ; Méthodes de sciences sociales, Paris. Dallas ;

* 3 PASCAL ROQUES ; UML2 Les cahiers de programmeur, modéliser une application Web ; 4ième Ed Eyrolles , 2008,p4.

* 4 MULUMBATI NGASHA ; Introduction à la Science Politique, Ed africa 2006,p18.

* 5 http://fr.wikipedia.org/wiki/Unified_Modeling_Language

* 6 Uml.free.fr/cours/ip13.html

* 7 UML 2 - Laurent Audibert - http://laurent-audibert.developpez.com/Cours-UML/

* 8. UML 2 - Laurent Audibert - http://laurent-audibert.developpez.com/Cours-UML/

* 9 http :fr.wikipedia.org/wiki/WLangage.

* 10 www.pcsoft.fr

* 11 Idem

Rechercher sur le site:

Recherche
9Impact, le film from Onalukusu Luambo on Vimeo.
BOSKELYWOOD from Ona Luambo on Vimeo.

© Memoire Online 2000-2019

Pour toute question contactez le webmaster