Plan du rapport

I. Introduction
II. Objectifs
III. Fonctionnement gnral et spcification des besoins
VI. Architecture logicielle
V. Conception
VII. Environnement et techniques de ralisation
IVII. Conclusion & perspectives

I. Introduction
Toute entreprise, quelle que soit son activit, doit veiller assurer une bonne gestion des stocks, ainsi
qu'une efficacit dans la rotation des stocks et la gestion des approvisionnements pour tre
performante et viter la rupture de stock ou le sur-stockage. Cest une activit qui se dcompose en
gestion des mouvements d'entre et de sortie des marchandises.
L'objectif est d'assurer un placement intelligent des stocks afin de pouvoir retrouver facilement un ou
des produits prcis. Le stockage, aussi appel entreposage, rpond des rgles afin de garantir le
maintien de la marchandise en bon tat, optimiser l'espace et assurer la scurit entre donnes
sauvegardes et donnes relles. Un bon stockage permet de connatre tout moment la quantit de
marchandise disponible et mise la vente.
La gestion des stocks s'avre alors toujours indispensable pour rpondre au mieux aux demandes des
clients: Un stock doit contenir les articles demands en quantit adapte.

II. Objectifs
Cette application intgre les bases dune gestion commerciale qui assure le suivi des clients et des
fournisseurs ainsi que la cohrence de leurs interactions avec l'entreprise. Lobjectif cest de :

Produire un cahier des charges fonctionnel valid, une spcification complte, et un modle
de base de donnes.

Mettre en relation un suivi commercial des clients et des fournisseurs .

Avoir le suivi des commandes et des factures.

Crer, modifier ou supprimer des fournisseurs, des clients et des produits.

III. Fonctionnement gnral et spcification des besoins

Le but principal du futur logiciel est dassurer une gestion commerciale aise. Il doit tre le plus
ergonomique possible, mais pouvant rpondre toutes les demandes.
Lapplication doit permettre de grer des activits multiples comme :

Gestion des fournisseurs, des produits et des clients

Gestion des stocks

Gestion et dition des bons d'achats et de commandes

Gestion et dition des factures

2

VI. Architecture logicielle

L'aspect logique du systme correspond une architecture trois tiers. En fait, il est divis en trois
niveaux ou couches : couche prsentation, couche mtier et couche accs aux donnes.

la prsentation des donnes : correspondant l'affichage, la restitution sur le poste de

travail, le dialogue avec l'utilisateur ;
le traitement mtier des donnes : correspondant la mise en uvre de l'ensemble des
rgles de gestion et de la logique applicative ;
l'accs aux donnes persistantes : correspondant aux donnes qui sont destines tre
conserves sur la dure, voire de manire dfinitive.

L'architecture adopte prsente un avantage par rapport aux architectures client-serveur classiques.
En fait, au niveaux des architectures client-serveur classiques les couches prsentation et traitement
taient trop souvent imbriques. Ce qui posait des problmes chaque fois que l'on voulait modifier
l'interface homme-machine du systme.
Nous avons alors adopt l'architecture trois tiers qui permet l'activation distance (entre la station
et le serveur d'application) des objets et de leurs mthodes: on parle d'invocation. Cette architecture
utilise galement certains moyens de programmation dfinissant des correspondances entre monde
objet et monde relationnel (ORM).

V. Conception
Pour rpondre aux exigences dj dfinies, nous avons suivi une mthodologie de conception
centre utilisateur afin de se focaliser surtout sur les critres d'utilisabilit et d'utilit du systme.
Pour ce faire, nous avons reprsent nos choix conceptuels travers le langage de modlisation
unifi UML. Pour dcrire l'aspect comportemental du systme, nous avons eu recourt au diagramme
des cas d'utilisation suivant :

gerer des clients

Supprimer client
Ajouter client

modifier client

Commercial
Gerer des produits

ajouter_produit

supprimer produit

modifier produit

s'authentifier
Gerer des fournisseurs

Adminstrateur

ajouter_fournisseur

supprimer_fournisseur

Passer commande

verifier_stock

consulter_commande

payer_facture

Figure 1: Diagramme des cas d'utilisation

modifier_fournisseur

Aprs llection des besoins exprims sous la forme de fonctionnalits modlises comme des cas
dutilisation nous pouvons modliser les aspects statiques du systme travers le diagramme de
classes suivant:

commande
client
-

Num client
Nom client
prenom client
Num_compte
adresse
telephone

:
:
:
:
:
:

int
String
String
int
String
int

1..*
1..1 -

num_commande
date_commande
designation
id_client
id_produit

:
:
:
:
:

int
int
int
int
int

1..*1..*
produit
- referance_p : int
- libelle_p
: int
- prix
: int

0..1

1..*

ligne_produit
- qte_achete : int

ligne_commande
- ref_p
: int
- num_commande : int

facture
- num_fac : int
- libelle
: int

bande d'entree

0..*

1..1
*

fournisseur
-

Figure 2 : Diagramme de classes

Nom_fournisseur
Prenom_fournisseur
Date naissance
e-mail
telephone
pays
ville
code_postale

:
:
:
:
:
:
:
:

String
String
Date
String
int
String
String
int

VII. Environnement et techniques de ralisation

La prsente application a t implmente sur une machine ayant les caractristiques suivantes:

Systme dexploitation : Windows7

Systme de gestion de base des donnes: MYSQL

Environnement de dveloppement intgr : Eclipse

L'implmentation est ralise au moyen des framework J2EE car il offre un ensemble de techniques
simples et efficaces tel que :

Swing : pour crer des interfaces graphiques identiques quel que soit le systme
d'exploitation sous-jacent, au prix de performances moindres qu'en utilisant Abstract Window
Toolkit (AWT).
Spring : pour la cration dobjets et la mise en relation dobjets par lintermdiaire dun
fichier de configuration qui dcrit les objets fabriquer et les relations de dpendances entre
ces objets.
Hibernate : grant la persistance des objets en base de donnes relationnelle. Hibernate
apporte une solution aux problmes d'adaptation entre le paradigme objet et les SGBD en
remplaant les accs la base de donnes par des appels des techniques avances tel que :
o DAO (Data Access Object): permet de s'abstraire de la faon dont les donnes sont
stockes au niveau des objets mtier. Cette souplesse implique cependant une plus
complexit de mise en uvre supplmentaire.
o La mthode d'annotations : Cette approche permet d'viter la description de la
correspondance entre les champs d'une table et les champ en XML.

IVII. Conclusion & perspectives

Au niveau du prsent projet, nous avons ralis une petite application de gestion commerciale dont
les principaux objectifs sont d'assurer un ensemble de fonctionnalits qu'on a dtaill dans la phase
de conception qui visent la simplicit et la cohrence.
Cependant, une phase amlioratrice est ncessaire pour augmenter l'efficience de l'application. Une
phase volutive est galement ncessaire afin d'accroitre son efficacit. Cette dernire peut
s'envisager par la prise en charge de fonctionnalits plus spcifiques telles que gestion des diffrents
articles de dpense la gestion des diffrentes structures de lentreprise, la gestion des banques et
des types de paiement.