Está en la página 1de 34

-1-

Universit de Caen
Dpartement informatique
U.F.R. Sciences
Univers Informatique
14700 Falaise


















RAPPORT DE STAGE DE LICENCE


Sous la direction de Monsieur Lionel Cosson
Juin aot 2003


















Enseignant tuteur : Auteur :
Monsieur Etienne Grandjean Nicolas Lefvre


-2-







COOLGESTION



RAPPORT DE STAGE DE LICENCE


Sous la direction de Monsieur Lionel Cosson
Juin aot 2003






















Enseignant tuteur : Auteur :
Monsieur Etienne Grandjean Nicolas Lefvre


-3-



-4-
Remerciements




Je remercie tout particulirement :


Mon tuteur, Monsieur Lionel COSSON, pour mavoir accueilli
dans son entreprise et pour avoir t mon coute pendant
toute la dure de ce stage.

Les techniciens, Messieurs Franois DJABALI et Geoffrey
DUVENT pour avoir t prsents lors des phases cls de mon
stage aussi bien lors de la conception que de la ralisation du
logiciel.

Mademoiselle Stphanie LEFEBVRE pour mavoir aiguill en ce
qui concerne lintgration de la comptabilit dans le logiciel.

Monsieur Etienne Grandjean pour son appui lors de la ralisation
de ce rapport.


-5-

Sommaire



Introduction ................................................................................................................. 6
1. Prsentation du cadre du stage........................................................................... 7
1.1. Prsentation du magasin.............................................................................. 7
1.2. Positionnement du stage .............................................................................. 7
1.3. Cahier des charges....................................................................................... 8
1.4. Analyse de lexistant ..................................................................................... 9
1.5. Structuration du problme ............................................................................ 9
1.6. Outils informatiques utiliss ........................................................................ 10
1.6.1. Le choix de Java.................................................................................. 10
1.6.2. Le choix de MySQL ............................................................................. 11
1.6.3. Connexion JAVA-MYSQL.................................................................... 12
1.6.4. Outils de documentation...................................................................... 12
2. Conception et ralisation du logiciel .................................................................. 13
2.1. La base de donnes ................................................................................... 13
2.1.1. Critique du modle .............................................................................. 17
2.2. Linterface homme-machine ....................................................................... 18
2.3. Implmentation du programme................................................................... 21
2.3.1. Implmentation de la base de donnes............................................... 21
2.3.2. Programmation des classes intermdiaires......................................... 21
2.4. Linterface graphique .................................................................................. 22
2.4.1. Explication de la mise en forme........................................................... 24
2.4.2. Limitations de linterface graphique ..................................................... 25
3. Avancement du projet ........................................................................................ 26
3.1. Problmes rencontrs................................................................................. 26
3.2. Avancement du projet ................................................................................. 27
3.3. Fonctionnalits ajoutes............................................................................. 28
3.4. Limitations .................................................................................................. 29
3.5. Extensions .................................................................................................. 30
Conclusion ................................................................................................................ 32
Bibliographie ............................................................................................................. 33
Annexes




-6-
Introduction


Dans le cadre de ma matrise informatique, jai effectu un stage, dune dure
de 9 semaines, au sein du magasin LUnivers Informatique Falaise. Ce magasin
est tout aussi spcialis dans la vente de composants que dans la maintenance
informatique.

Mon premier travail, en commun avec celui des quipes technique et
comptable, a t de mettre en place le cahier des charges ncessaire
laboutissement dun logiciel conforme aux besoins de lentreprise. Dans un second
temps, mon travail sest focalis sur une recherche de documentation dans le but de
parfaire mes connaissances sur les sources de donnes permettant la connexion de
programmes des bases de donnes indpendantes.

Ayant toutes les cls en main, la troisime phase devait aboutir, au terme de
ce stage, la ralisation du logiciel en lui-mme.

Ce rapport voque, en dtail, les diffrentes phases danalyse et de
dveloppement ncessaires la ralisation du logiciel. Celui-ci est complt par des
informations concernant les problmes rencontrs et les moyens informatiques dy
remdier.

Avant mme le dbut de la phase de conception, il convient de dcouvrir les
diffrents acteurs de ce stage travers une prsentation succincte de LUnivers
Informatique. Nous voquerons, par la suite, la structuration du sujet de ce stage et
son positionnement dans lentreprise, pour finir sur lexplication de nos choix en ce
qui concerne le langage de programmation et le systme dexploitation.

Cette phase termine, nous parlerons, ensuite, de notre rflexion conceptuelle
autour du sujet dans une partie ddie la modlisation, dans un premier temps, de
la base de donnes et, dans un second temps, du programme et de son interface
graphique.

Cette partie nous conduira la troisime et dernire phase, voquant la
ralisation proprement dite, de limplmentation du noyau. Nous finirons, dans une
troisime partie, par faire le point sur les rsultats obtenus la fin de ce stage puis
nous conclurons sur son apport dans un cursus universitaire.


-7-
1. Prsentation du cadre du stage

1.1. Prsentation du magasin

Domicili au cur de Falaise lUnivers Informatique est un magasin offrant un
service des plus comptents tout aussi bien dans le domaine de la cration de sites
Internet que dans ladministration de systmes et des rseaux. Cependant, leur
principale activit soriente autour de la vente et de la maintenance de matriel
informatique.

Sous la direction de Monsieur Cosson, deux techniciens offrent leurs
comptences chacun dans des domaines spcialiss mais se recoupant concernant
la maintenance de matriel informatique.

Les besoins de Monsieur Cosson et de ses techniciens auxquels on ma
demand de rpondre sorientent autour de la cration dun logiciel orient base de
donnes. Aprs avoir prsent lUnivers Informatique et ses employs, il convient de
dfinir le positionnement du stage dans lentreprise.


1.2. Positionnement du stage

Le stage a pour but de rendre le travail des employs plus efficace encore, par
la cration complte dun logiciel de gestion du magasin. Lautomatisation et, le cas
chant, la rduction du temps de mise en uvre de nombreuses tches, permettent
la proposition dun meilleur service.

Pour cela, la gestion du magasin se devra dtre prcise, intuitive et surtout
trs efficace. Le logiciel est le fruit dun rel besoin de toute lquipe qui souhaite une
centralisation des donnes en ce qui concerne la vente et la maintenance du
matriel informatique. En effet, nous le verrons dans lanalyse de lexistant, tout
processus est rendu laborieux car aucune trace informatique des transactions
effectues nest cre. Cela implique, par consquent, un long temps de recherche
dans le cas, par exemple, du calcul du stock en fin danne, processus qui pourrait
tre automatis.

Pour bien reprsenter lensemble du travail demand, il convient de dfinir les
besoins et les contraintes dans le cahier des charges.



-8-
1.3. Cahier des charges

Le stagiaire devra dvelopper une application de gestion complte du
magasin fonctionnant sous les systmes Microsoft Windows. Pour cela, il devra lui-
mme choisir ses propres outils de dveloppement, tant au point de vue du stockage
des donnes que de la programmation de linteraction entre linterface graphique et
ces mmes donnes.

Le logiciel terminal devra tre pourvu des fonctionnalits suivantes :

o La cration, modification et consultation des donnes concernant un
fournisseur ou un client.
o Le stockage de factures fournisseur permettant dtablir une trace des
produits du magasin.
o La cration et la consultation de factures client.
o La cration, modification et consultation de devis client.
o La gestion du stock par un tableau des produits achets, facturs, livrs.
o La cration automatique dun journal de caisse.
o Lenvoi de la comptabilit du magasin par e-mail.
o Lenvoi des factures client du jour au cabinet comptable.
o La cration de bons de livraison et leurs consultations.
o La recherche rapide des prix des produits ainsi que leur quantit en stock.
o La cration davoirs sur une facture client
*
.
o Un tableau rcapitulatif des avoirs crs
*
.
o La cration de bulletin dintervention
*
.
o Un tableau rcapitulatif des achats et des devis dun client.
o La gnration de fichiers html imprimables pour les devis, les factures client,
les bons de livraison et les avoirs.


Le logiciel se devra, en outre, dutiliser le code barre des produits pour une
plus grande rapidit quant la cration de factures client, dune part, et la tracabilit
des produits, dautre part.

Aprs avoir schmatis lensemble de la base de donnes, celle-ci sera
valide par lquipe technique qui donnera son accord pour la phase de
dveloppement.

Aprs une courte tude graphique, le logiciel devra tre pourvu dune interface
efficace permettant une meilleure intuitivit ainsi quun gain de temps dans
lexcution de processus.

Une phase de tests rels viendra conclure ce stage permettant de dceler les
possibles problmes.


*
Ces fonctionnalits ont t rajoutes au fur et mesure du dveloppement du logiciel.




-9-
1.4. Analyse de lexistant

A lorigine, une simple utilisation du logiciel Microsoft Excel permettait la
cration de factures, de devis et des journaux de caisse. Plusieurs problmes se sont
poss quant cette mthode. En effet, il nexistait aucune automatisation des
tches, tout se faisait manuellement, ainsi, lors de la cration dune facture client, il
fallait, en plus, crire le montant de cette facture dans le journal de caisse. La gestion
du stock tait rendue quasi-impossible car il fallait reprendre lensemble des factures,
quelles soient des fournisseurs ou pour les clients, et soustraire les quantits
achetes celles vendues.

Lors de la rception dun colis provenant dun fournisseur, les techniciens
taient obligs de coller une tiquette sur chaque produit pour permettre dtablir
sa traabilit dans le cas dun retour en service aprs vente, do une grande perte
de temps et donc de productivit.

Du point de vue comptabilit, le cabinet comptable tait oblig denvoyer un
de ses reprsentants pour consulter le journal de caisse et les factures tablies, l de
mme, il en rsulte une grande perte de temps.

Nous le voyons travers cette courte explication, aucun processus do la
ncessit de crer un logiciel qui permettrait dautomatiser lensemble de ces taches.

Le cot de revient dun logiciel commercial, permettant une parfaite intgration
avec le logiciel de comptabilit utilis au cabinet comptable, tant trop lev pour un
magasin de la taille de lUnivers Informatique, les techniciens se sont vu pousss
tablir un dbut de base de donnes sous Microsoft Access. Cependant, ayant
dautres occupations, ceux-ci nont pu mener terme cette bauche. De plus,
dsirant un cot minimal quant la cration du logiciel, lutilisation dAccess ntait
pas des plus sage.

Jai dabord tudi cette base de donnes ce qui ma permis une premire
approche dans la conception du logiciel.

Aprs avoir analys les diffrentes possibilits envisages jai structur le
problme pour permettre le dveloppement de la solution adquate.

1.5. Structuration du problme

La structuration du problme est soumise, dune part, au sujet, qui est la
cration dun logiciel et, dautre part, au cahier des charges lui-mme qui dicte les
phases de la ralisation.

Trois phases ont t dfinies lors de ce stage. La premire consiste raliser
une tude sur la conception de la base de donnes, plus connue sous le nom de
mthode Merise. Cette mthode permet de crer une base de donnes
conformment aux besoins de lentreprise.



-10-
La seconde phase consiste, dans un premier temps, implmenter la base de
donnes en elle-mme et, dans un second temps, de crer le noyau
*
du programme
permettant les interactions entre linterface graphique et cette base. Le noyau se
composera dun ensemble de petits programmes simplifiant la ralisation de la
troisime et dernire phase.

Cette dernire phase consiste crer linterface graphique. Dans un premier
temps, une tude sera ralise pour prsenter une interface des plus efficace en
tablissant une charte graphique. Cette phase se terminera par la programmation de
linterface graphique en elle-mme.

Pour mener bien lensemble de ces phases et plus particulirement les deux
dernires, il convient de dfinir et dexpliquer nos choix quant la slection des outils
informatiques.


1.6. Outils informatiques utiliss

1.6.1. Le choix de Java

Le langage de programmation Java met notre disposition un ensemble de
package graphique rendant simple la cration dinterfaces utilisateurs en vue dune
interactivit avec le logiciel et une intuitivit des plus accrues. Un gestionnaire intgr
Java permet la cration dAPI permettant une reprise optimale du logiciel pour des
modifications plus aises.

De plus la syntaxe de Java est analogue celle de C++, ce qui le rend
conomique et professionnel. Le fait de crer une autre version du C++ n'est
cependant pas l'objet de ce langage. En effet le point cl de Java est le suivant: Il est
beaucoup plus facile d'obtenir un code sans erreur avec Java qu'avec C++ car un
certain nombre de points susceptibles d'apporter des erreurs tel que :

L'allocation et la libration de mmoire manuelles ont t retires. En effet la
mmoire, dans Java, est alloue et libre automatiquement.

Java permet, entre autres, une vraie gestion des tableaux car les
concepteurs ont retir l'arithmtique des pointeurs. La notion de rfrence
sur une zone mmoire remplace avantageusement celle de " pointeur ", car
elle supprime la possibilit d'craser toute zone mmoire cause d'un
compteur erron.

Les concepteurs ont supprim l'hritage multiple en le remplaant par une
nouvelle notion d'interface drive d'Objective C. Une interface nous offre les
mme possibilits que l'hritage multiple, sans la complexit de la gestion de
hirarchie d'hritage multiple.

*
Noyau : Programme minimal, dpourvu dune quelconque interface graphique et de fonctionnalits. Les
fonctionnalits viennent sintgrer au noyau, conu spcialement pour les recevoir. Dans le cas de notre logiciel
linterface graphique se sert du noyau pour communiquer avec la base de donnes.


-11-

Les objectifs de Java s'articulent autour de termes cls dont la simplicit, la
portabilit, la fiabilit, et les performances leves, le tout, qui plus est, gratuit.

1.6.2. Le choix de MySQL

De nombreux arguments nous ont conduits choisir MySQL comme serveur
*

de base de donnes plutt que Microsoft Access. En effet, MySQL gnre des
fichiers de stockage beaucoup plus petits, ce qui rends lensemble de la base de
donnes moins importante
*
que sous Access.

Concernant la gestion Multi-Utilisateurs, l encore, MySQL propose un
systme beaucoup plus souple quAccess. En effet, sous Access, chaque client
dsirant interagir avec la base de donnes conduit le systme la dupliquer, par
consquent, chaque client connect dispose de sa propre base de donnes sur le
serveur. Si le nombre de client dpasse 5, les changes entre ceux-ci et le systme
surchargent le rseau ralentissant lensemble des changes entre tous les
ordinateurs. MySQL, quant lui, prend en compte lensemble des interactions des
clients avec la base de manire souple grce son dmon
*
. En effet, celui-ci prend
en compte lensemble des requtes des clients et les traite les unes aprs les autres
sur une seule et unique base de donnes. Les changes sur le rseau sont rduits
leur minimum.

Dautre part, MySQL ncessite une licence dutilisation payante uniquement
lorsque le programme est destin tre vendu. La revente du logiciel ntant pas
envisage, MySQL nous est donc gratuit, la diffrence dAccess qui ncessite une
licence payante et ce, pour une quelconque utilisation.

Loptique dune utilisation sur Internet nous a conforts dans notre choix. En
effet, le langage PHP, destin utiliser une base MySQL, est beaucoup plus
conventionnel que le langage ASP, destin, lui, lutilisation dune base Access. La
reprise dune base de donnes MySQL pour une utilisation sur Internet est donc la
porte dun plus grand nombre de dveloppeurs.

MySQL a, cependant, aussi ses dfauts, parmi eux, nous retiendrons l non-
gestion des cls trangres
*
. Il en rsulte une surcharge quant la cration des
requtes SQL. Cependant, toutes les requtes ncessaires lutilisateur sont
traduites dans le logiciel. Par consquent, un utilisateur na pas besoin dcrire ses
propres requtes. Ce dfaut de MySQL est contourn, lutilisateur nen ayant aucune
connaissance.


*
Serveur de base de donnes : Programme permettant la gestion dun ensemble de donnes de manire
optimale et professionnelle. MySQL est un serveur de base de donnes robuste, rapide et gratuit.
*
Base de donnes moins importante : Pour exemple la table contenant lensemble des codes postaux Franais
associs aux villes faisait quelque 6.5Mo sous Access contre 1Mo sous MySQL.
*
Dmon : Un dmon est un programme excut au lancement de la machine et fonctionnant en tche de fond.
Lutilisateur na pas forcement connaissance de lexistence dun tel processus.
*
Cl trangre : Pour toute valeur de la cl trangre, elle rfre une valeur identique de la cl primaire
obligatoirement prsente dans la table associe.


-12-
1.6.3. Connexion JAVA-MYSQL

Lutilisation de MySQL sous Java nest oprationnelle que si un pilote
*
est
install. Aprs une recherche de documentation sur Internet, notre choix sest porte
sur le pilote de Mark Mathews, le pilote MM. Il permet la connexion de Java
MySQL, utile pour grer une base de donnes avec les outils offerts par Java tel
quune interface graphique.

1.6.4. Outils de documentation

Notre application tant voue une utilisation sous Windows, nous avons
dcid dutiliser les outils que ce systme dexploitation met notre disposition pour
permettre une intgrit maximale avec celui-ci. En vue de cette intgrit, nous avons
dvelopp une aide, non pas sous le format PDF dAdobe AcrobatReader mais sous
le format CHM propre au systme de Microsoft. Ainsi, lutilisateur se voit en mesure
dutiliser cette aide ds son premier lancement, il na aucun besoin de se familiariser
avec celle-ci, la normalisation tant faite pour tre intuitive.

Aucun outil na t utilis pour crer cette aide mise part le compilateur CHM
de Microsoft. En effet, il suffit de crer ses pages sous forme HTML sous un
quelconque diteur puis de les intgrer au fichier CHM pour pouvoir les utiliser.

Le choix de cet outil plutt que de laide conventionnelle (fichier HLP) de
Microsoft sexplique par sa simplicit et par son intuitivit quant linteraction avec
lutilisateur.

Aprs avoir dfini le cahier des charges et conclu sur nos choix quant aux
outils informatiques utiliss, il convient dappliquer une bonne mthodologie de
cration ; entendons par-l, la conception de la base de donnes dans un premier
temps et de linterface homme-machine dans un second temps pour finir dans une
partie concernant limplmentation du programme qui nest autre que lcriture du
logiciel.


*
Pilote : Programme permettant lutilisation dun premier programme dans un second si ces deux derniers sont
indpendants lun de lautre et fonctionnels lun sans lautre. Il permet simplement la jonction entre deux
programmes indpendants.


-13-
2. Conception et ralisation du logiciel

2.1. La base de donnes

A la base de la conception, le cahier des charges a ncessit une grande
rflexion, permettant dentrevoir toutes les possibilits que le logiciel devrait offrir.
Les lments soumis une reprise ou une consultation sont les points cl de la
base de donnes. En effet, celle-ci stockera toutes les informations tout point de
vue, de la facture fournisseur jusqu' la facture client.

Pour tablir une base de donnes, non seulement conforme aux besoins de
lUnivers Informatique mais aussi respectant les principales rgles de gestion de la
conception des bases de donnes, il convient de la concevoir mthodiquement
travers la mthode Merise.

En tablissant les donnes dun produit ainsi que sa vie dans le magasin,
nous obtenons un grand nombre dinformations devant tre implmentes dans la
base de donnes ainsi :

Un produit est vendu, un certain prix et une certaine date, au magasin
par un fournisseur, ce produit a une dsignation, un temps de garantie fournisseur.
Pour tre vendu, le magasin lenregistre et fixe un prix de vente. Lors de sa vente, le
magasin enregistre lacheteur et la date de vente.

Cette phrase semble cependant oublier de nombreux concepts, cependant,
nous avons dj une ide des informations minimales et obligatoires devant figurer
dans la base de donnes. Pour tre plus complets, nous nommons fournisseur
un objet ayant de nombreux attributs que nous verrons dans le prochain schma.

Pour tre plus prcis il ne faut pas rflchir au niveau produit mais plutt
en essayant de sadapter en fonction de la vie du produit ainsi, en ce qui concerne
lachat de produits chez des fournisseurs :

Un fournisseur tablit une facture, ayant une date et un montant total,
concernant des lots de produits et leur quantit, ces lots de produits ont, tous, une
dsignation, un prix dachat et de vente et un temps de garantie.

Maintenant, que nos produits sont enregistrs, chacun dentre eux peut tre
vendu un client, ainsi :

Un client, dsirant acheter un certain produit, se voit remettre une facture
la date du jour, quil peut payer de diffrentes manires. Cette facture est tablie
par un intervenant. Le client doit donc payer un montant total regroupant les prix de
tous les lots de produits quil dsire acheter.



-14-
Ds lors, nous avons les informations minimales permettant de vendre des
produits ayant pralablement t achets. Nous en concluons donc la liste des
tables suivante :

o Fournisseur
o Facture fournisseur
o Lots de produits
o Produit
o Client
o Facture client

Concernant ces tables nous avons aussi lensemble des attributs devant y
figurer (En italique dans les phrases).

Voici donc le schma minimum aussi appel modle conceptuel de donnes.


Modle conceptuel de donnes minimal.


Nous avons maintenant lossature de notre base de donnes, de nombreux
lments vont sy greffer en regardant de nouveau le cahier des charges. En effet,
nous ne parlons pas encore de devis, de bons de livraison, davoirs, de comptabilit
mais aussi est surtout dutilisation de code barre.




-15-
Reprenons notre systme pour y intgrer ces lments :

Lorsquun client est mcontent ou lorsquun des produits quil a achets ne
lui convient pas, le magasin peut tablir un avoir sur la facture se rfrant cet
article. Un avoir se compose dune date, dun montant et est associ une facture
client. Il dispose en outre dune dsignation.

En vue dun achat, un client peut demander au magasin dtablir un devis,
pour cela, lintervenant, conseille le client sur les diffrents choix dachat disponibles
dans lensemble des produits, en stock ou non, et ce, quelle que soit la quantit
demande. Le client se voit ensuite proposer un devis un certain montant. Un devis
se compose en outre dune date et dun ensemble de lots de produits et de leur
quantit.

Il se peut quun client dsire une quantit de matriel trop important et,
nayant pas les moyens de tout ramener chez lui, demande au magasin de le livrer.
Lintervenant tablit donc un bon de livraison chaque dplacement, rendant
compte de la quantit livre et de la quantit due. Un tel bon de livraison dispose
dune date, et dun ensemble de lots de produits ayant chacun une quantit livre.

Pour permettre une utilisation des codes barre, pour rechercher les donnes
dun produit, il nous faut crer une nouvelle table qui, chaque lot de produits achet
chez un fournisseur, associe un code barre. Il existe plusieurs comportements
adopter selon les catgories de produits. En effet, certaines catgories de produits
nont quun code barre, identique pour tous les produits, cest le cas des botes de
disquettes ou de CD-R ou de tout autre sorte de consommable de manire gnrale.

Dautres catgories attribuent un code barre unique pour chaque produit. Cest
le cas des disques durs ou tout autre produit disposant dune garantie. Le troisime
cas concerne les produits nayant tout simplement pas de code barre. Cest le cas
des microprocesseurs et barrettes mmoires. Dans ce cas, il nous faut attribuer un
numro de lot, pour permettre de lassocier une facture fournisseur.

En ce qui concerne la comptabilit et son intgration dans le logiciel, il nous
suffit de crer un systme qui, pour chaque produit stock ou non, associe le numro
du plan comptable.

Le modle conceptuel suivant prend en compte tous ces besoins en essayant
au mieux doptimiser lensemble des donnes pour viter la redondance
dinformations, sans pour autant en perdre.

Ce modle subira, par la suite, quelques ajouts. En effet, la mise en place
rapide dun jeu de tests et lavancement du projet en milieu de stage nous a permis
de dvelopper quelques fonctionnalits utiles ncessitant toutefois la cration de
nouvelles tables. Ces fonctionnalits concernent, dune part, le journal de caisse qui
ncessite une trace des fonds de caisse dune journe sur lautre et dautre part, un
systme de cration de bulletins dintervention permettant de garder une trace des
travaux effectus sur les ordinateurs des clients du magasin.



-16-
Il est noter que ces ajouts ne modifient en aucun cas le modle suivant, ils
sont mme indpendants de celui-ci.


Modle conceptuel de donnes final et ses cardinalits
*
.


Nous voyons dans ce modle quelques entits (futures tables dans la base de
donnes) ajoutes, Cest le cas par exemple de la table ville, qui contient lensemble
des codes postaux franais (En rouge dans le schma). Comme nous lavons vu
dans les paragraphes prcdents, ce modle est optimis, toutes les informations
que nous avons vues dans nos phrases logiques y figurent, cela ncessite donc des
explications.

*
Les cardinalits : Entre chaque entit, nous voyons des doublons de chiffres ((0..*,1),(1,1..*) etc.). Ces chiffes
nous renseignent sur le nombre dune premire entit prsente dans une seconde. Par exemple la cardinalit
(1,0..*) entre client et ville signifie que chaque client habite dans une seule et unique ville, tandis quune ville
peut accueillir de zro un nombre indfini de clients. De mme un client peut tablir autant de devis quil veut,
chaque devis prsent dans la base de donnes se rfre un seul et unique client, ce qui explique la cardinalit
(1,0..*).


-17-

La mise en place dune table DeductionAvoir (En bleu dans le modle)
nous permet de prendre tout ou partie dun avoir prcdemment cr. En effet, cette
table stocke lensemble des dductions mises pour chaque avoir, ainsi, lintervenant
ne peut pas soustraire un montant suprieur au montant restant de lavoir.

Lors de lutilisation du code barre, la base de donnes nous permet de
retrouver la dsignation, le prix dachat et le prix de vente du produit douch
*
en
consultant lensemble des codes barres(nomms rfrenceDouchette ) de la table
ProduitEnStock (En violet dans le modle).

Ce code barre nous permet aussi, lors de lutilisation de la traabilit, de
connatre le fournisseur ainsi que de nombreuses informations sur la facture lis ce
produit. Le logiciel aiguille directement sur la procdure de retour en Service aprs
vente selon le fournisseur (En orange dans le modle).

En ce qui concerne les bons de livraison, et plus particulirement les lots de
produits livrs, ils sont intimement lis aux lots de produits facturs. En effet, chaque
lot de produits livr a son quivalent dans la table des lots de produits facturs (En
vert dans le modle).

Le modle propose une base de donnes prvue pour lutilisation sur Internet.
En effet, la mise en place de droits
*
sur la table produits permettrait tout visiteur
du site hbergeant la base de donnes, dtablir son propre devis en slectionnant
ces produits dans cette table.

Ce modle nest cependant pas exempt de dfauts, certains volontaires,
dautres rvls lors de la phase de test.

2.1.1. Critique du modle

Ce modle propos, bien quadquat pour une utilisation dans le magasin,
nest pas pour autant le meilleur modle. En effet, celui-ci a ses limites.

Le cahier des charges stipule expressment quune gestion du stock doit tre
implmente dans le logiciel. Cependant, nous ne voyons aucune table qui
permettrait une gestion adquate. Le modle ne prend tout simplement pas en
compte cette partie du cahier des charges. Pour pallier ce problme, nous
programmerons une mthode, en Java, permettant cette gestion. Lunique problme
dun tel programme est sa relative lenteur par rapport un ensemble de requtes
MySQL, cependant, pour lutilisateur, la diffrence est de lordre de la seconde.


*
Produit douch : Lecture du code barre du produit laide dun lecteur optique.
*
Systme de droit dans une base de donnes : Les droits permettent de donner des privilges une certaine
catgorie dutilisateurs. Par exemple ladministrateur dune base de donnes a tous les droits sur celle-ci
(cration, suppression, consultation des tables mais aussi administration des droits) et donne des droits aux autres
utilisateurs. Pour une utilisation scurise sur Internet, ladministrateur doit donner le droit, aux clients, de
consultation uniquement sur la table Produit , les autres tables restant inaccessibles et invisibles aux yeux de
ceux-ci.


-18-
En ce qui concerne le mode de paiement dun client rglant une facture, le
modle est, l aussi, limit. En effet, il est impossible dajouter un mode de paiement.
Ainsi, si un nouveau mode de paiement venait voir le jour, il nous faudrait appliquer
une petite modification dans le programme. Cependant, seul un dveloppeur pourrait
leffectuer, la diffrence dune criture des modes de paiement dans la base de
donnes, qui pourrait se voir modifi par un utilisateur lambda.

La premire phase de conception tant maintenant conclue, il convient
prsent dtudier la partie graphique du projet pour proposer une interface dont les
mots cls sont convivialit, efficacit et intuitivit.

2.2. Linterface homme-machine

La mise en place dune charte graphique permet une cohrence au niveau
interface, ainsi chaque lment trouve sa dfinition et son utilisation dans sa manire
dtre reprsent.

Notre langage de programmation met notre disposition bon nombre doutils
permettant une plus grande simplicit dutilisation, et il convient bien videmment de
les utiliser bon escient. Ltude mise en place nous a conduits apprhender les
lments graphiques suivants :

o La barre de menu, pour contrler entirement le logiciel.
o Les boutons standards, pour laiguillage vers une partie quelconque de
linterface graphique.
o Les boutons radios, pour une slection unique dans une liste de choix.
o Les zones de textes, pour la saisie dinformations au clavier.
o Les onglets permettant un aiguillage rapide vers les fonctionnalits les plus
courantes.
o Les boutons cocher pour la slection dun ensemble de choix dans une liste.

Aprs avoir dfini lensemble de besoins en ce qui concerne les outils graphiques,
il convient de mettre en forme la fentre principale. Aux vues des besoins dfinis
dans le cahier des charges, nous proposerons une interface graphique principale
dfinie par trois zones dinformations ou dinteractions.




-19-

Proposition dinterface graphique.

La barre de menu, situe en haut de la fentre principale, constitue llment
majeur permettant de contrler lensemble des fonctionnalits du logiciel. Ainsi, cette
barre permet dinteragir avec la base de donnes en ce qui concerne les crations,
suppressions, modifications de donnes.

La zone principale de linterface graphique se compose dune bote donglets
proposant lensemble des fonctionnalits les plus couramment utilises, telle que la
consultation du journal de caisse ou la cration de factures. Cette bote donglets
permet une rapidit accrue quant lexcution des tches quelle propose par
rapport un systme de barre de menu.

Les onglets disposent tous de deux sous-parties. En bas gauche se trouve
une zone dinformations concernant les modifications apportes au contenu de
longlet en lui-mme. Par exemple, lors de la slection dun client, le nom de celui-ci
se voit crit dans cette zone. En bas droite, se situe une zone contenant un
ensemble de boutons, permettant de contrler longlet et de le finaliser, cest dire
dcrire ses donnes dans la base.

La troisime et dernire zone contient les informations sur les interactions
entre lutilisateur et la base de donnes par lintermdiaire de linterface graphique.
Ainsi, tous les messages de confirmations, mais aussi derreurs dcriture se trouvent
crit ici. Cette zone est trs importante dans la comprhension de ltat de la base de
donnes chaque instant.

Un menu reste cependant inaccessible lutilisateur tout pendant quil ne
clique pas sur le bouton droit de la souris. En effet, un tel clic rvle un menu
droulant permettant la recherche dinformations au sujet des prix des produits ou
sur un produit dont nous disposons du code barre ou du numro de lot en vue de son


-20-
retour en service aprs vente. Ce menu, disponible dans chaque fentre du logiciel,
permet lutilisateur de sinformer sur le stock et le prix dun certain produit ou dune
catgorie de produits de manire trs rapide. La mise en place dun tel menu est le
fruit dune motivation en ce qui concerne le renseignement rapide dun client quil soit
au guichet ou au tlphone.

Le nombre dinterfaces tant assez restreint
*
, un schma denchanement des
interfaces nous semble le bienvenu pour conclure cette tude concernant la partie
graphique de ce projet.


Schma navigationnel dinterfaces
*
.

Aprs avoir termin la phase de conception, il convient maintenant
dapprhender ltape de ralisation, qui consiste utiliser notre tude conceptuelle
ainsi que les outils informatiques pour crer un logiciel conforme aux besoins et
contraintes de ses utilisateurs.


*
Boite de dialogue bloquante : fentre obligeant lutilisateur une interaction avec elle-mme. Les autres
fentres du logiciel sont bloques tout le temps que cette fentre na pas t ferm. Typiquement, ce genre de
fentre est utilis pour le questionnement, lerreur, ou encore linformation.
*
En effet, mis part linterface principale, nous disposons dun ensemble dinterfaces secondaires pour la
cration denregistrement dans la base de donnes.
*
Ce schma manque toutefois de prcisions, en effet, les interfaces de cration nont pas t schmatises parce
que celles-ci sont assez nombreuses, et bien souvent quasi-identiques. Pour ce qui est des interfaces de
consultation et suppression, elles sont identiques, se composant dune bote de dialogue bloquantes et excutant
leur processus respectif sur lobjet slectionn.


-21-
2.3. Implmentation du programme

2.3.1. Implmentation de la base de donnes

Comme nous lavons vu dans la premire partie, nous avons choisi MySQL
comme gestionnaire de base de donnes. Cet outil met notre disposition de
nombreux lments simplifiant la cration des tables (Annexe I) ainsi que
lenregistrement de donnes. En effet, en voulant respecter les rgles de gestion
dfinies par la mthode Merise, il est ncessaire, pour chaque table cre dy
implmenter une cl primaire
*
. MySQL permet une gestion automatique des cls
primaires, ainsi, celui-ci attribue automatiquement un nombre (identifiant) pour les
occurrences de toutes les tables de la base de donnes sauf la table
FactureFournisseur car lidentifiant est donn par le fournisseur qui attribue lui-
mme un numro sa facture.

Nous pouvons donc retrouver chaque donne de la base par son numro
associ. Toutefois, lutilit de lidentifiant ne rside pas dans la recherche des
donnes le concernant, il permet, plutt, de ne pas avoir de doublon dans la base de
donnes. Il est beaucoup plus simple, et valorisant pour le client, de chercher ses
donnes partir de son nom plutt que par son numro.

Nous le verrons dans la prochaine partie, cette attribution automatique
didentifiant nest pas sans poser de problme en ce qui concerne ltablissement
des factures.

Linterface graphique ne peut utiliser la base de donnes directement, et ce,
pour des raisons de souplesse de programmation, nous avons donc mis en place un
systme de classes intermdiaires.

2.3.2. Programmation des classes intermdiaires

Le but du logiciel tant, dun point de vue purement informatique, la gestion
dune base de donnes par une interface graphique, il convient de mettre en place
une interface
*
entre cette interface graphique et la base de donnes. Nous avons vu
dans la premire partie que le pilote MM se charge de la communication avec la
base de donnes. Cette connexion tablie, il nous faut enregistrer les donnes que
saisit lutilisateur. Pour cela, nous avons mis en place un systme de classes
*

intermdiaires permettant la jonction entre linterface graphique et MySQL :



*
Cl primaire : Attribut ou champ particulire de la table telle que, pour chacune des valeurs de attribut, il en
existe au maximum une occurrence dans cette table. La cl primaire de la table Client pourrait tre, par exemple,
le numro de scurit sociale, diffrent pour chaque individu.
*
Nous parlons ici dune interface, dun programme qui fait le lien entre la base de donnes et le logiciel. En
aucun cas il ne sagit dune interface graphique.
*
Classe : Terme informatique, ddi la programmation oriente objet, dsignant un modle dobjet. La classe
Client , par exemple, se charge de grer la table Client de la base de donnes. Ainsi lorsque lutilisateur
cre un nouveau client, les donnes saisies dans linterface graphique sont envoyes la classe client qui les
traite et les envoie sous forme de requtes interprtables par MySQL.


-22-

Jonction entre linterface graphique et MySQL.

Le but des classes intermdiaires, programmes en Java, tout comme
linterface graphique, cependant invisibles aux yeux de lutilisateur, est de simplifier la
programmation en lallgeant. Les classes sont programmes en fonction de la
structure de la base de donnes. Ainsi, pour chaque table de la base de donnes,
une classe intermdiaire a t cre. Cette classe centralise les actions possibles
pour une table. Lorsque lutilisateur clique sur un des boutons de cration, Client par
exemple, il ninteragit pas avec la base de donnes directement. En effet le
programme cre un objet
*
ayant la structure dun client, cest dire disposant dun
nom, dune adresse etc. Cet objet est ensuite crit dans la base de donnes.

Dune manire gnrale, le principe du logiciel est le suivant : En fonction du
bouton de la barre de menu sur lequel lutilisateur a cliqu, le programme cible les
besoins de celui-ci en saiguillant automatiquement sur la partie concerne par le
bouton. Par exemple, si lutilisateur clique sur le bouton Cration de client , le
logiciel se tourne automatiquement vers la classe Client et utilisera la fonction
dcriture intgre cette classe.

2.4. Linterface graphique

Comme nous lavons vu dans la prcdente partie, notre interface graphique
devait ce composer de 3 zones, dont un menu, une zone dinteractions entre
lutilisateur et le logiciel, et une dernire concernant linteraction entre lutilisateur, et
plus particulirement le logiciel, et la base de donnes.


*
Cration dun objet : Dun point de vue purement informatique, les objets facilitent le passage par paramtres.
En effet, plutt que de passer le nom, ladresse, le numro de tlphone le code postal et la ville en paramtres,
nous passons un objet de type Client. Ce type dobjet a une structure contenant lensemble de ces informations.
Par consquent, nous passons 1 seul paramtre au lieu de 5.


-23-

Schma simplifi de linterface.


Ainsi, nous proposons aux utilisateurs linterface graphique suivante :



Interface Graphique de lapplication.



-24-

2.4.1. Explication de la mise en forme

En ce qui concerne la barre de menu, nous avons dcid non pas de classer
les boutons par actions, mais plutt de classer les boutons par rapport aux objets de
la base de donnes auxquels ils se rapportent. Ainsi, nous navons pas de menu
cration ou suppression , mais un menu concernant les fournisseurs etc.

Par rapport au systme de bote onglets, nous avons dcid dy implanter
les systmes de facturation et de cration de bulletin dintervention ainsi que le
gestionnaire de journal de caisse. Ny figurent pas les devis, qui selon nous, sont
moins utiliss, les clients demandant rarement ltablissement de devis, prfrant,
une numration des prix des produits dsirs. En effet, les devis sont gnralement
tablis pour un ensemble de produits en vue dun trs probable achat.

En ce qui concerne les autres possibilits telle que la cration de bons de
livraison ou encore davoirs, l aussi, les probabilits nous ont conduits ne pas
crer donglets part entire.

Cependant, malgr linexistence de certains onglets, le lancement dun
possible processus associ nest pas forcement plus long. En effet, la mise en place
de raccourcis clavier vient palier ce problme. Ainsi, les actions plus rares que
celles prsentes dans les onglets se voient dotes de raccourcis permettant, dune
simple saisie au clavier, leurs lancements. Nous avons donc 3 degrs dutilit :

o Les onglets pour les oprations courantes.
o Les raccourcis clavier et la barre de menu pour les oprations de moindre
utilit.
o La barre de menu pour les oprations plus rares.

Nous lavons vu dans la partie prcdente, la mise en place dun menu
droulant permet une interrogation trs rapide de la base de donnes. En effet, dun
simple clic, lutilisateur peut rechercher les donnes dun produit par la saisie
complte ou partielle de sa dsignation. Lors dune saisie partielle, le logiciel affiche
lensemble des produits concerns. Ce petit moteur de recherche accepte mme la
saisie de caractre despacement en vue dune recherche sur plusieurs mots. Lide
de ce menu est rapidit et efficacit ainsi quutilit et intuitivit.



-25-

Processus de recherche des donnes dun produit.

Linterface graphique autorise un bon nombre dactions, mais en interdit ou
nen permet pas certaines autres.

2.4.2. Limitations de linterface graphique

Linterface graphique nautorise pas certaines actions, interdites par la
lgislation. Ainsi, lutilisateur na pas la possibilit de modifier une facture tablie. En
effet, la loi franaise linterdit formellement. Toutefois, celui-ci a la possibilit de
leffacer. Si une telle action se produit, la facture sera belle et bien efface mais au
niveau comptable, un trou dans les numros de facture sera visible, la facture
supprime ntant pas remplace dans la base de donnes
*
.

Linterface propose un nombre considrable doprations possibles sur la
base de donnes, Nous lavons cependant vu prcdemment, toutes les oprations
ne peuvent tre implmentes car pour la plupart quasi-inutiles, seules les
oprations courantes ont t implmentes. Nous pouvons donc regretter
linexistence dun module intgr au logiciel permettant la saisie de requte SQL.

Malgr les limitations de linterface graphique, le logiciel fourni au terme du
stage est fonctionnel. Cependant, au cours du stage, quelques problmes nous sont
apparus, ncessitant une plus grande rflexion. Nous les verrons dans la prochaine
partie concernant les problmes rencontrs ainsi que les limitations et extensions
possibles du logiciel.

*
Numro de facture : Prenons lexemple dune facture, que lutilisateur supprime, ayant le numro X. La
prochaine facture aura le numro X+1 malgr tout. Le cabinet comptable et aussi, pourquoi pas, le contrleur
fiscal aura une trace des factures numro X-2,X-1 et X+1, et remarquera par consquent quil manque la facture
numro X.


-26-
3. Avancement du projet

3.1. Problmes rencontrs

Comme nous lavons vu dans la premire partie, limplmentation a t
relativement courte. Nous avons donc pu mettre en place une phase de test assez
rapidement ce qui a permis de corriger en heure et en temps les problmes
dimplmentation. Cependant, le principal problme lors de la ralisation dun tel
projet, et qui ne peut tre rsolu par une phase de test, est de se projeter dans le
futur et dimaginer le comportement du logiciel dans plusieurs mois. Malgr cette
rflexion, nous ne pouvons imaginer que les problmes les plus simples, laissant, du
mme coup, de ct des problmes bien plus importants dont nous ignorons la
nature et mme lexistence.

Le plus gros problme rencontr concerne la centralisation des donnes. En
effet, lorigine, les potentialits du driver MM nous taient mconnues. Cependant
aprs avoir apprhend ce pilote, il nous est apparu possible de connecter une
machine la base de donnes dun serveur . La simplicit de mise en uvre
dune application client-serveur dcuplait les potentialits du logiciel en lui-mme. En
effet, les perspectives quoffre une application client-serveur sont multiples. Plus
besoin dattendre la finalisation dune facture pour en crer une nouvelle, si le logiciel
est install sur n postes, n oprations peuvent tre effectues en mme temps sur la
mme base de donnes, pourvu que ces oprations soient atomiques
*
.

Un problme a t soulev par la mise en place de lutilisation en rseau. En
effet, si la rutilisation des informations crites dans la base de donnes est simple, il
nen est rien pour les donnes gnres sous forme de fichier, comme, tous les
documents imprimables. En effet, un programme client gnre son propre fichier
sans pour autant que les autres clients ne puissent le consulter.

Prenons lexemple dune facture : Un poste client enregistre une facture.
Lors de cet enregistrement, les donnes sont crites dans la base de donnes et un
fichier HTML reprsentant la facture est gnr sur ce mme poste. Imaginons quun
autre poste client dsire visionner cette facture. En consultant la base de
donnes, il apprend quelle existe bel et bien, mais aucun fichier HTML ne se
rapporte la dite facture car les fichiers des postes clients sont inaccessibles.

Dans un premier temps, pour pallier ce problme, linterface tait pourvue
dun bouton permettant de re-gnrer une facture partir de son enregistrement
dans la base de donnes. Nous avons, par la suite, prfr centraliser toutes les
donnes que le logiciel pouvait gnrer. Finalement, chaque poste client ,
gnrant une facture, cre un fichier HTML imprimable sur le serveur , ce qui le
rend consultable par les autres postes du rseau.

Tous les enregistrements tant maintenant regroups sur un mme poste, la
sauvegarde de toutes les donnes est du mme coup rendue plus aise.

*
Une opration est dite atomique si elle ne peut tre interrompue durant son excution par une autre opration.


-27-
Dans un second temps, il a fallu apprhender le problme de la comptabilit.
En effet, il tait convenu dans le cahier des charges que le cabinet comptable devait
recevoir sous forme de mails lensemble des transactions du magasin. Plusieurs
solutions soffraient nous. La premire consistait utiliser un programme denvoi de
mails par ligne de commande qui serait lanc par le logiciel. Le problme de cette
solution concerne la licence dutilisation du client mail, qui, dans la plupart des cas,
est payante. La seconde tait dutiliser un programme Java connu sous le nom de
JavaMail. Nous avons retenu cette solution car, dune part, ce programme est libre
de droit et, dautre part, son intgration au logiciel est parfaite par le fait que tous
deux soient programms en Java.

Aprs avoir mis en place un systme denvoi de mails, le problme suivant
consistait ajouter des pices jointes aux mails. En effet, le cabinet comptable
doit avoir une trace de chaque facture tablie. Cependant, JavaMail permet
denvoyer un fichier joint par mail uniquement et la question denvoyer un mail par
facture tablie ne se posait mme pas. La solution a t de crer un fichier
darchives (connu sous le nom de fichier ZIP) quotidiennement et de le joindre
lenvoi du mail. Il nous a donc fallu apprhender la cration de fichier ZIP en
Java.

Lors de la phase de conception nous avions omis la gestion des avoirs pour
une meilleure comptabilit. Cependant, aucune modification na t apporte sur le
programme existant, seules deux tables ont t ajoutes dans la base de donnes et
une interface graphique permettant lenregistrement de donnes dans ces tables a
t cre.

Si la rsolution de tels problmes nous a demand un peu de temps, cela ne
nous a pas empch de fournir un logiciel fonctionnel avant mme la fin du stage.

3.2. Avancement du projet

Comme nous lavons vu dans les paragraphes prcdents, la phase
dimplmentation ne nous a pas pris trop de temps malgr les problmes cits. Nous
avons pu fournir un logiciel conforme aux besoins signals dans le cahier des
charges. Cependant certains lments agrmentant lintuitivit nont pas t finaliss,
cest le cas par exemple du fichier daide.

Lcriture dun fichier daide ncessite dans un premier temps la mise en place
dune petite charte graphique permettant la comprhension et la clart des
informations prodigues. Dans un second temps, il sagit dcrire une documentation
claire et complte concernant lutilisation et la configuration du logiciel. Vis vis du
temps restant lors du stage, nous navons pu fournir une documentation utilisateur et
un fichier daide exhaustif.

Linstallation du logiciel est rendue trs difficile car aucun programme
dinstallation na t implment. Tout est donc manuel et, par la mme occasion,
trs dlicat car la moindre erreur de configuration rend le logiciel inexploitable. La
phase de test ayant rvl des problmes plus importants, la cration dun
programme dinstallation a t sans cesse recule jusqu' lchance du stage.


-28-

Au fil du test, il est apparu que le cahier des charges ne proposait pas
forcement une liste exhaustive des fonctionnalits dont devrait disposer le logiciel.
Celui-ci sest donc vu rajouter bon nombre de fonctions permettant lautomatisation
de certaines tches dune part, et dautre part de rendre le logiciel plus adapt aux
utilisateurs.

3.3. Fonctionnalits ajoutes

Les fonctionnalits sont le fruit dune demande des utilisateurs au cours de la
phase de test. Bien que moins utiles que les fonctionnalits dcrites dans le cahier
des charges, celles-ci ajoutent lutilit du logiciel en lui-mme. Lensemble de ces
fonctionnalits agit en tout point du logiciel.

Parmi elles, lajout de longlet Bulletin dintervention permet de grer les
interventions des techniciens sur les ordinateurs des clients du magasin. Plus quune
optimisation en ce qui concerne le temps de cration dun bulletin, un tel onglet
permet de garder une trace de toute intervention en vue dune consultation future.




Interface de cration dun bulletin dintervention



-29-
Une routine, quant elle, permet dalerter lutilisateur lorsque celui-ci vend un
produits dont la quantit en stock est pass sous un seuil dfini lors du paramtrage.
La recherche ne se fait pas sur un seul produit mais sur toute une catgorie de
produit. Lutilisation typique de cette alerte concerne lensemble des consommables.
Ainsi, lutilisateur se voit prvenu du manque de stock.

En plus de ces fonctionnalits, nous avons cr un programme autonome
permettant la cration et lenvoi de fichiers zip la comptabilit prcdemment cite.
Ce programme se connecte la mme base de donnes, et crer un fichier archive
en consquence des factures cres la mme journe.

Malgr ces ajouts, et mme si le logiciel est bien adapt au besoin du
magasin, certains points limitent lefficacit du logiciel pour quelques tches. Nous
allons maintenant parler des limitations du logiciel.

3.4. Limitations

A ce niveau de dveloppement et mme si le logiciel est fonctionnel, il noffre
pas une parfaite satisfaction. En effet, malgr une rdaction de cahier des charges
en adquation avec les besoins de ses futurs utilisateurs, le logiciel est tout de mme
limit, et ce, sur plusieurs points. Plusieurs raisons expliquent de telles limitations, la
premire concerne la dure du stage, un peu courte pour le dveloppement dun
logiciel et la correction des problmes dcels lors de sa phase de test. La seconde
concerne les outils informatiques utiliss qui, bien quadquats, automatisent
certaines tches, les rendant, du mme coup, inaccessibles.

La premire limitation concerne la base de donnes en elle-mme.
Ladministration de celle-ci fait dfaut car elle reste accessible tous les utilisateurs.
En effet, ce jour, aucun mot de passe nest demand lors de la connexion la base
de donnes, par consquent, tout utilisateur peut se connecter cette base et la
modifier son propre gr. Un travail sur ladministration de MySQL permettrait
simplement den scuriser laccs. En ce qui concerne le logiciel, aucun travail nest
apporter, le problme ayant dj t prvu. En effet, les noms et mots de passe
sont modifiables dans le fichier de configuration. La connexion se fait donc
indpendamment du programme compil.

La mise en place dun systme de droits sur la base de donnes pourrait,
lavenir, tre trs utile pour des extensions possibles du logiciel.

Nous lavons vu dans lintroduction de cette partie, certains outils
informatiques couramment utiliss lors du stage automatisent des tches, cest le
cas de MySQL. Lors de la cration des tables, la spcification de certains attributs
permettent leur gestion automatique, cest le cas, par exemple, de la cl primaire
dune table. Si celle-ci est spcifie AUTO_INCREMENT , MySQL attribue une
valeur automatiquement chaque cration de ligne. Un problme de gestion nous


-30-
est apparu lorsquun des utilisateurs a voulu supprimer
*
, de la base de donnes, la
dernire facture cre. Lors de la cration dune nouvelle facture, celle-ci ne se
voyait pas attribuer le numro de cl de la facture supprime mais le numro suivant.
Au fil du temps et des suppressions, les numros de factures ne se suivront plus, des
trous apparatront.

Lors du bilan comptable de fin danne ou lors dun contrle fiscal, le magasin
aura le plus grand mal se justifier vis vis de ces numros de factures inexistants.
A ce jour, le problme reste entier, aucune solution permettant la suppression de
facture errone, na t trouve, mis part, bien sur, la cration davoirs ce qui
allonge considrablement le temps de saisie dune facture.

La comptabilit intgre au logiciel est, de nouveau, concerne par un autre
problme. Quotidiennement, celui-ci envoie un e-mail au cabinet comptable. Ce mail
contient un fichier HTML, reprsentant le journal de caisse, et un fichier zip,
contenant lensemble des factures du jour. Cet envoi de mail nest pas scuris ce
qui offre, des personnes malveillantes, la possibilit de connatre lensemble des
transactions du magasin. Une solution consisterait envoyer les e-mails de manire
scurise en utilisant un protocole adquat.

Concernant les interventions sur la base de donnes, celles-ci ncessitent la
connaissance des commandes MySQL. En effet, le logiciel ne propose quun
ensemble de boutons traduisant certaines de ces commandes, nanmoins, cet
ensemble est trs restreint et se cantonne des insertions ou des suppressions dans
les tables. Certaines modifications sont possibles, cest le cas dun devis par
exemple, dautres impossibles et ncessitent lintervention, en ligne de commandes,
partir dune console MySQL.

Aux vues du nombre de possibilits de modifications, suppressions ou
insertions, il nous tait impossible de rendre lensemble de commandes pr
interprtes exhaustif auquel cas il serait inappropri.

3.5. Extensions

Lutilisation de MySQL pour la gestion de la base de donnes ouvre les portes
de lutilisation sur Internet, par le biais de PHP. La mise en place de devis en ligne
permettrait aux personnes connectes de connatre le prix des composants en temps
rel et dtablir leur propre devis de chez eux.

Cependant, la mise en place dun tel service soulve plusieurs problmes. Le
premier concerne la base de donnes en elle-mme qui devrait dtre stocke sur un
serveur, dans le magasin
*
, ayant une adresse IP
*
fixe pour pouvoir tre consulte

*
Suppression dune facture : Normalement interdit, le logiciel en offre tout de mme la possibilit pour effacer
une facture errone. La solution adquate est de crer un avoir du montant de la facture errone et de le reporter
sur la nouvelle facture.
*
Le serveur doit obligatoirement tre dans le magasin pour permettre une connexion illimite a la base de
donnes. En effet, lhbergement de la base pourrait conduire une inactivit lors dune panne dADSL par
exemple, rendant la facturation ou toute autre opration impossible.


-31-
depuis Internet. De plus, celle-ci devrait se voir dote dun systme de droit adquat
ne permettant que la consultation des donnes et non leurs modifications.

Une telle extension permettrait aussi de lancer le logiciel travers Internet
permettant aux administrateurs de grer la base de donnes depuis nimporte quel
poste connect pourvu que le logiciel y soit install.

Nous lavons vu dans la partie prcdente, lenvoi de donnes par e-mail au
cabinet comptable nest pas scuris. Une solution plus approprie consisterait
tudier le logiciel de comptabilit utilis et dadapter notre logiciel pour que celui-ci
envoie directement des donnes interprtables par le logiciel comptable. Cela
automatiserait la tche de saisie comptable et rendrait incomprhensible les donnes
envoyes pour quiconque ne disposant pas de ce logiciel.

Une telle tude ncessiterait beaucoup de temps, mais rendrait les deux
logiciels solidaires.

En ce qui concerne lutilisation
*
du logiciel dans un autre tablissement, elle
est tout fait envisageable pourvu que ce magasin ait les mmes besoins
*
que
lUnivers Informatique. En effet, ayant les mmes besoins, la base de donnes et
lensemble des tables seraient identiques. Linterface graphique ntant quune
couche permettant lutilisation simplifie de cette base de donnes, aucun lment
ne serait sujet modification.

Nous venons de voir les rsultats obtenus la suite de ce stage, travers les
parties concernant lavancement, les fonctionnalits ajoutes, les limitations et les
extensions du logiciel. Il nous reste conclure sur lapport dun tel stage, tant au
point de vue des connaissances quau point de vue humain, dans un cursus
universitaire, travers la conclusion.

*
Adresse IP : ensemble de 4 numros 3 chiffres permettant de dsigner un ordinateur sur Internet.(Exemple :
192.168.0.55)
*
A propos de cette utilisation, Le logiciel ne peut se voir vendu, mais donn car sa vente ncessiterait lachat
dune licence MySQL.
*
Lorsque nous parlons de besoins, nous ne parlons pas forcment dun autre magasin dinformatique. En effet,
les lments contenus dans les tables peuvent ne pas tre dorigine informatique. Ainsi, en reprenant la table
Produit, on se rend compte que tout article disposant dune catgorie, dune dsignation, dun prix dachat et
dun prix de vente peut se voir intgr dans la base de donnes. Or, gnralement, tous les articles vendus dans
un quelconque magasin dispose de ces renseignements. Par consquent, la table Produit est adapte, et donc
utilisable dans toutes sortes de magasin. Le logiciel est donc utilisable dans un magasin si toutes ses tables sont
adaptes.


-32-
Conclusion

Aprs avoir prsent les auteurs du sujet de ce stage, Monsieur Cosson et
ses techniciens, nous venons de voir comment, conceptuellement parlant ainsi que
du point de vue du dveloppement nous avions rpondu leurs attentes.

Les objectifs de tels stages sont multiples : Il faut tirer une double exprience
(communication omniprsente avec les responsables du sujet et acquisition de
nouvelles connaissances dans le domaine cibl par le stage) et que nous puissions
apporter lentreprise pour laquelle nous travaillons un bnfice sous la forme de
nouveaux logiciels.

La dure de ce stage, 9 semaines temps plein, se rvle tre une
exprience dans le monde du travail trs bnfique. En ce qui me concerne, cela
reprsente, ce jour, ma plus longue insertion dans le monde du travail, et plus
particulirement du gnie logiciel. Jai rellement pu dpasser le stade de
formation qui est une tape obligatoire lorsque lon arrive dans une nouvelle
entreprise. Ensuite, le stage devient une vraie exprience professionnelle puisque jai
t amen travailler de manire autonome.

Ce stage a rpondu mes attentes aussi bien au niveau professionnel quen
terme de comptences relatives au savoir-faire ncessaire pour toute autre activit
relationnelle. Il est mon premier pas vers un apprentissage de la ralisation complte
dune application pour une entreprise en ayant besoin et ce, grce la
communication entre elle et nous.




-33-
Bibliographie

Dans le cadre du stage de cursus licence matrise, il ma t demand de
dvelopper une application permettant la gestion complte dun magasin de vente de
matriel informatique. Afin de mieux aborder ce sujet, jai d faire appel certains
documents.

Livres
Java 2 dition SDK 1.3
Livre traitant des principes du langage Java
ISBN 2-7464-0105-3 OSMAN Eyrolles multimdia

Site Internet

Tutorial Java (consult le 1
er
juillet 2003) [En ligne]
Adresse URL: http://java.sun.com/docs/books/tutorials

Documentation lectronique

Documentation MySQL 3.23. Manuel de rfrence.

Bruce Eckel. Thinking In Java
Live lectronique traitant du langage Java
ISBN 0-13-659723-8


-34-




Rsum

Un stage annuel entre dans le cadre du cursus licence - matrise informatique.
Sur une demande du magasin lUnivers Informatique, celui-ci portait sur la cration
dun logiciel permettant la gestion complte du magasin, de lenregistrement de
factures fournisseur la cration de factures client, en passant par une gestion du
stock. Les outils utiliss sont Java, pour la programmation, et MySQL pour le
stockage des donnes.



Mots cls

Gestion complte de magasin
Stage de Licence - matrise
Univers Informatique
Java
MySQL