Memoire Online - Conception et réalisation d'une application de gestion de stock dans une entreprise privée cas de Sesomo.

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

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

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

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.

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.

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

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érifie^2(*)

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 sont^3(*) :

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 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-dessous^5(*):

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

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

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

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

- 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

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.

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.

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.

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.

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.

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.

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.

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

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 ;

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 1^er 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 le 9 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° 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ès 1951.

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.

Organigramme

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

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

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:

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 :

- 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

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

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 ;

8. Le magasinier vérifie la disponibilité, si oui acquise la réception, si non informe, le 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 :

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.

Plan	Anomalies	Suggestions
Capacité de stockage limité à cause de la surface réduite à 200 m2	Agrandissement de l'espace alloué au magasin en ajoutant des salles de stockage.	Organisationnel
Mauvaise répartition des tâches, ce qui rend la procédure de travail très lente pour le magasinier.	Faire une meilleure attribution des tâches à travers un partage plus équitable du travail	Informationnel
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é.	Utilisation d'un bon de commande structuré pour l'expression de ses besoins auprès du service de Ressources Humaines	Technique

2.2.5.3. Problématique

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 :

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

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

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.

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.

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 ;

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.

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 :

- 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

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

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 :

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

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

- 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(*)

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.

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

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.

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

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.

3.6. Réalisation des Diagrammes de Séquences

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

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

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

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

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

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

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.

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.

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

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 commande	Date	8	JJ/MM/AAA 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 produit	Date	8	JJ/MM/AAA 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
	Solde	C'est la quantité qui reste	Numérique	4	99999999

4.4.2. Représentation des Rubriques des fichiers

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 :

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.

- 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

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

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 framework PHP, 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 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 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

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 :

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

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

e) Bilingue

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

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

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.

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.

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

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

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

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

II. Site Internet

Annexe

5.1. CODES DE L'APPLICATION

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

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

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

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

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

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

iInitRequêteEtat("Etat_Fiche_Gestion_de_Sorties",Gestion_de_Sorties.IDGestionSortie)

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

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

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

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

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

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

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

Table des Matières

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

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

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

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

Conception et réalisation d'une application de gestion de stock dans une entreprise privée cas de Sesomo.

EPIGRAPHE

DEDICACE

REMERCIEMENTS

AVANT PROPOS

Résumé

INTRODUCTION GENERALE

O.1. CHOIX ET INTERET DU SUJET

0.1.1. Sur le plan Personnel

0.1.2. Sur le plan Scientifique

0.1.3. Sur le Plan social

0.2. ETAT DE LA QUESTION

O.2.1. PROBLEMATIQUE ET HYPOTHESE

O.2.2. Problématique

O.2.3. Hypothèse

O.2.4. Méthodes et Techniques

0.2.4.1. Méthodes

0.2.4.2. Technique

0.2.5. Délimitation du Sujet

CHAPITRE. I. GENERALITES

1.1. Introduction

1.2. Le Processus Unifié et UML

1.2.1. Présentation d'UML

A) Les Diagrammes UML

1.2.2. Le Processus Unifié

1.2.3. Les Principes d'UP

1.2.4. Les Phases Du Processus Unifié

1. Création

2. Elaboration

3. Construction

4. Transition

1.3. Réseau Informatique

1.3.1. Concepts De Réseau

a) Un réseau

b) Extranet

c) Intranet

1.3.2. Type des réseaux

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

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

1.3.3.2. Types d'architectures réseaux

Conclusion Partielle

CHAPITRE II. SPECIFICATION DES BESOINS

2.1. Introduction

2.2. Présentation de l'Entreprise

2.2.1. Situation Historique

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

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

- 1945 - 1946 : agrément

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

2.2.2. Situation Géographique

2.2.3.

Organigramme

2.2.4. Présentation du Service

A) L'effectif du Magasin

B) Mission du Magasinier

C) Situation Informatique

2.2.5. Contexte du système

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

2.2.5.2. Diagnostic de la Situation Actuelle

2.2.5.3. Problématique

2.2.5.4. Propositions

2.2.5.5. Objectifs

2.2.5.6. Aide à la décision

2.2.5.7. Diagramme du contexte

Conclusion Partielle

CHAPITRE III. ANALYSE DES BESOINS

3.1. Introduction

3.2. Modèle Du Système

3.3. Besoins Fonctionnels et Non Fonctionnels

3.3.1. Besoins Fonctionnels

3.3.2. Besoins Non-fonctionnels

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

3.5. La Démarche du Prototypage

3.6. Réalisation des Diagrammes de Séquences

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

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

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

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

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