Najib

Universit de Sfax
Ecole Nationale dIngnieurs de Sfax

Dpartement dinformatique et de mathmatiques-appliques

M
M
E
E
M
M
O
O
I
I
R
R
E
E

En vue de lobtention du
M
M
a
a
s
s
t
t
r
r
e
e
P
P
r
r
o
o
f
f
e
e
s
s
s
s
i
i
o
o
n
n
n
n
e
e
l
l

En Technologie dInformation et Commerce Electronique
Option WEB
G
G
E
E
S
S
T
T
I
I
O
O
N
N
D
D
U
U
P
P
A
A
R
R
C
C
V
V
E
E
H
H
I
I
C
C
U
U
L
L
E
E

D
D
E
E
L
L
A
A
S
S
T
T
E
E
G
G

C CA AN ND DI ID DA AT T
Nejib HABIB

E EN NS SE EI IG GN NA AN NT T E EN NC CA AD DR RE EU UR R
Monsieur Nizar ELLEUCH

Soutenu le ../../2011, Devant la commission dexamen :

Pr. Prsident
Mr. Nizar ELLEUCH Encadreur
Dr. Examinateur
Anne Universitaire
2010- 2011

Ddicaces

A celui qui ma fait apprendre que le
travail est l unique moyen, pour lhomme,
daffirmer son existence et de raliser ses
buts: mon trs cher pre Salah.
A celle qui a veill pour mon avenir
et mon bonheur: mon adorable mre Khadija.
A ceux qui jaime: mes frres Neji, Mahmoud, Nejah et mes
Soeurs Rawdha, Houda.
A toute la famille LHBIB.
A mes oncles et mes tentes.
A mes ami(e)s.
A tous ceux qui me sont chers.
Je ddie ce travail avec mes profonds
sentiments de reconnaissance et de gratitude.
NEJIB

REMERCIEMENTS
Nous remercions Dieu de nous avoir accord des connaissances de la
science et de nous avoir aid raliser ce travail.

Nous tenons exprimer nos sentiments de reconnaissance et de gratitude
Nous nous adressons spcialement notre encadreur de mmoire :

Monsieur ElEuch Nizar

Nous le remercions vivement davoir accept dencadrer ce prsent projet de fin
dtudes et aussi pour la qualit de son encadrement et son soutien tout au
long du droulement de ce projet. Nous esprons tre la hauteur de sa
confiance et quil trouve dans ce travail lexpression de notre profonde
gratitude.

Nous remercions aussi Monsieur MASMOUDI ABDENACEUR,
responsable service informatique de la STEG et Monsieur CHWAYAKH
RIADH, nous lui tmoignons toute notre gratitude pour sa collaboration, sa
disponibilit et son aide la ralisation de ce projet.

Nous prsentons nos remerciements les plus sincres tous les enseignants de
lEcole Nationale dIngnieurs de Sfax "ENIS" auxquels nous devons notre
formation.

Puisse ce travail les apporte le tmoignage de notre respect et notre gratitude
Merci tous

Avant propos

Cette tude entre dans le cadre de la prparation d'un Mastre Professionnel

En Technologie dInformation et Commerce Electronique Option WEB
au sein de lEcole Nationale dIngnieurs de Sfax pour l'obtention de la
mastre.
Elle nous assiste concrtiser nos connaissances thoriques par la
ralisation dun cas pratique. Nous tions alors chargs de dvelopper une
application web pour la STEG.

SOMMAIRE
INTRODUCTION GENERALE ------------------------------------------------------------------ 1
CHAPITRE1 : MODELISATION DU METIER ---------------------------------------------- 3
INTRODUCTION ----------------------------------------------------------------------------------------------- 3
1. DEFINITION DE LA MISSION --------------------------------------------------------------------------------------- 3
1.1 PRESENTATION DE LA SOCIETE ------------------------------------------------------------------------ 3
1.1.1 ORGANIGRAMME -------------------------------------------------------------------------------------- 4
1.1.2 PRESENTATION DU SYSTEME INFORMATIQUE----------------------------------------------- 5
1.2 PRESENTATION DE LAPPLICATION ------------------------------------------------------------------- 5
1.3 OBJECTIFS A ATTEINDRE --------------------------------------------------------------------------------- 6
1.4 PLANNING PREVISIONNEL -------------------------------------------------------------------------------- 7
2. REPERAGE ET DIAGNOSTIC DU DOMAINE ------------------------------------------------------------------- 8
2.1 GESTION DES REPARATIONS ------------------------------------------------------------------------- 8
2.2 GESTION DES ENTRETIENS -------------------------------------------------------------------------- 10
2.3 GESTION DES VISITES TECHNIQUES-------------------------------------------------------------- 10
2.4 GESTION DAPPROVISIONNEMENT DES PIECES DE RECHANGES ----------------------- 11
2.5 GESTION DES VEHICULES --------------------------------------------------------------------------- 12
3. DIAGRAMME DE CAS DUTILISATION METIER ------------------------------------------------------------ 12
4. DESCRIPTION DES PROCESSUS METIER --------------------------------------------------------------------- 15
5. DEFINITION DES ORIENTATIONS ------------------------------------------------------------------------------- 17
5.1 ORIENTATIONS DE GESTION --------------------------------------------------------------------------- 17
5.2 ORIENTATIONS DORGANISATION ------------------------------------------------------------------- 18
5.3 ORIENTATIONS TECHNIQUES -------------------------------------------------------------------------- 18
CONCLUSION ------------------------------------------------------------------------------------------------- 19
CHAPITRE 2 : CAPTURE DES BESOINS --------------------------------------------------- 20
INTRODUCTION ---------------------------------------------------------------------------------------------- 20
1. CHOIX DUML DANS LA CONCEPTION ---------------------------------------------------------------------- 20
2. ACTEURS DU SYSTEME INFORMATISE ----------------------------------------------------------------------- 20
3. MODELE DE CONTEXTE DU SYSTEME INFORMATISE -------------------------------------------------- 22
4. ELABORATION DU MODELE DES CAS DUTILISATION ------------------------------------------------- 23
4.1. DIAGRAMME DES CAS DUTILISATION ------------------------------------------------------------ 23
4.2. DESCRIPTION TEXTUELLE DES CAS DUTILISATION ------------------------------------------ 26
4.3. DIAGRAMME DE CLASSES PARTICIPANTES ------------------------------------------------------- 36
5. DEFINITION DES PRIORITES ------------------------------------------------------------------------------------- 47
6. DECOUPAGE EN PACKAGE --------------------------------------------------------------------------------------- 48
CONCLUSION ------------------------------------------------------------------------------------------------- 51
CHAPITRE 3 : ANALYSE ------------------------------------------------------------------------ 52
INTRODUCTION ---------------------------------------------------------------------------------------------- 52

1. DEVELOPPEMENT DU MODELE STATIQUE ------------------------------------------------------------------ 52
1.1. CONSTRUCTION DU DIAGRAMME DE CLASSES ------------------------------------------------- 52
1.1.1. DEFINITION ------------------------------------------------------------------------------------------- 52
1.1.2. DICTIONNAIRE DE DONNEES ------------------------------------------------------------------- 53
1.1.3. REPRESENTATION DES DIAGRAMMES DE CLASSE--------------------------------------- 60
1.2. CONSTRUCTION DES DIAGRAMMES DOBJETS -------------------------------------------------- 61
2. DEVELOPPEMENT DU MODELE DYNAMIQUE ------------------------------------------------------------- 63
2.1. CONSTRUCTION DES DIAGRAMMES DINTERACTION ----------------------------------------- 63
2.2. CONSTRUCTION DES DIAGRAMMES DETATS --------------------------------------------------- 70
CONCLUSION ------------------------------------------------------------------------------------------------- 71
CHAPITRE 4 : CONCEPTION ------------------------------------------------------------------ 72
INTRODUCTION ---------------------------------------------------------------------------------------------- 72
1. DEFINITION DE LARCHITECTURE DU SYSTEME --------------------------------------------------------- 72
1.1 COUCHE METIER / BUSINESS ------------------------------------------------------------------------- 74
1.2 COUCHE PRESENTATION ------------------------------------------------------------------------------- 74
1.3 COUCHE APPLICATION ---------------------------------------------------------------------------------- 75
2.CONCEPTION DES SCHEMAS LOGIQUES DES DONNEES ------------------------------------------------- 75
CONCLUSION ------------------------------------------------------------------------------------------------------------ 81
CHAPITRE 5 : IMPLEMENTATION --------------------------------------------------------- 82
INTRODUCTION ---------------------------------------------------------------------------------------------- 82
1. ENVIRONNEMENT DE REALISATION -------------------------------------------------------------------------- 82
1.1. MATERIELS ET LOGICIELS DE BASE ---------------------------------------------------------------- 82
1.2. OUTILS DE DEVELOPPEMENT ------------------------------------------------------------------------- 83
2. DEPLOIEMENT DU SYSTEME INFORMATISE ---------------------------------------------------------------- 85
3. REALISATION DU SYSTEME INFORMATISE ---------------------------------------------------------------- 86
3.1. PRODUCTION DES SQUELETTES DE CODE --------------------------------------------------------- 86
3.2. PRESENTATION DES GRILLES DECRAN ----------------------------------------------------------- 90
CONCLUSION ------------------------------------------------------------------------------------------------- 94
CONCLUSION GENERALE --------------------------------------------------------------------- 95
BIBLIOGRAPHIE ---------------------------------------------------------------------------------- 96

Liste des tableaux

TABLEAU 1 : DIAGRAMME DE GANTT DE REALISATION DE NOTRE APPLICATION ..................... 7
TABLEAU 2 : TABLEAU DE DESCRIPTION DES PROCESSUS METIER .......................................... 17
TABLEAU 3 : TABLEAUX DES PRIORITES .................................................................................. 47
TABLEAU 4: DICTIONNAIRE DE DONNEES................................................................................. 59

Liste des figures

FIGURE 1 : ORGANIGRAMME DE LA SOCIETE TUNISIENNE DELECTRICITE ET DU GAZ ......................................... 4
FIGURE 2 : DIAGRAMME DE CONTEXTE DU SYSTEME METIER ........................................................................... 13
FIGURE 3 : DIAGRAMME DE CAS DUTILISATION METIER .................................................................................. 14
FIGURE 4 : DIAGRAMME DE CONTEXTE DU SYSTEME INFORMATISE ................................................................. 22
FIGURE 5: DIAGRAMME CAS DUTILISATION RELATIF A LA GESTION DES INTERVENTIONS ............................... 24
FIGURE 6: DIAGRAMME CAS DUTILISATION RELATIF A LA GESTION DES PIECES DE RECHANGES ..................... 25
FIGURE 7: DIAGRAMME CAS DUTILISATION RELATIF A LA GESTION DES VEHICULES ....................................... 25
FIGURE 8 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER AUTHENTIFICATION ..... 37
FIGURE 9: DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER DEVIS ........................... 38
FIGURE 10 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER COMMANDES ............. 39
FIGURE 11 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION RETOUR PIECES RECHANGES . 40
FIGURE 12 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION REPARATION ........................... 42
FIGURE 13 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER ENTRETIEN .................. 43
FIGURE 14 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER ACCIDENT .................... 44
FIGURE 15 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER VISITE TECHNIQUE ..... 45
FIGURE 16 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER REFORME ................... 45
FIGURE 17 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER VEHICULE .................. 46
FIGURE 18 : DIAGRAMME DES CLASSES PARTICIPANTES AU CAS DUTILISATION GERER FOURNISSEURS .......... 47
FIGURE 19: PACKAGE APPROVISIONNEMENT .................................................................................................... 48
FIGURE 20 : PACKAGE INTERVENTION.............................................................................................................. 49
FIGURE 21 : PACKAGE VEHICULE ..................................................................................................................... 50
FIGURE 22: DIAGRAMME DE CLASSES .............................................................................................................. 60
FIGURE 23 : DIAGRAMME DOBJETS ................................................................................................................. 62
FIGURE 24: DIAGRAMME DE SEQUENCE AUTHENTIFICATION ............................................................................ 63
FIGURE 25: DIAGRAMME DE SEQUENCE AJOUTER VEHICULE ............................................................................ 64
FIGURE 26: DIAGRAMME DE SEQUENCE SUPPRIMER VEHICULE ........................................................................ 65
FIGURE 27: DIAGRAMME DE SEQUENCE AJOUTER COMMANDE ......................................................................... 66
FIGURE 28: DIAGRAMME DE SEQUENCE SUPPRIMER COMMANDE ..................................................................... 67
FIGURE 29: DIAGRAMME DE SEQUENCE AJOUT ACCIDENT ................................................................................ 68
FIGURE 30: DIAGRAMME DE SEQUENCE REPARATION...................................................................................... 69
FIGURE 31: DIAGRAMME DETAT-TRANSITION DUN VEHICULE ...................................................................... 70
FIGURE 32: ARCHITECTURE A TROIS NIVEAUX ................................................................................................. 73
FIGURE 33: TRANSFORMATION DUNE CLASSE ................................................................................................. 76
FIGURE 34: TRANSFORMATION DUNE ASSOCIATION 1, 1..* OU 1, 0..* ............................................................. 76
FIGURE 35: TRANSFORMATION DUNE ASSOCIATION 1, 0..1 ............................................................................... 77
FIGURE 36: TRANSFORMATION DUNE CLASSE ASSOCIATION ........................................................................... 78
FIGURE 37: TRANSFORMATION DUN HERITAGE ............................................................................................... 79
FIGURE 38: DIAGRAMME DE DEPLOIEMENT ...................................................................................................... 85
FIGURE 39: GRILLE DECRAN POUR LECRAN FICHE VEHICULE......................................................................... 90
FIGURE 40: GRILLE DECRAN POUR LECRAN FICHE REPARATION .................................................................... 91
FIGURE 41: GRILLE DECRAN POUR LECRAN CONSULTATIONREPARATION ...................................................... 92
FIGURE 42: GRILLE DECRAN POUR LECRAN CONSULTATION COMMANDE ...................................................... 92
FIGURE 43: GRILLE DECRAN POUR LECRAN FICHE FOURNISSEUR ................................................................... 93
FIGURE 44: GRILLE DECRAN POUR LECRAN FICHE FOURNISSEUR ................................................................... 94

INTRODUCTION GENERALE
GESTION DU PARC VEHICULE INTRODUCTION GENERALE

1
INTRODUCTION GENERALE

ans le cadre de ce mmoire de fin dtude, nous allons dvelopper
une application web destin la Socit tunisienne dlectricit et
du gaz STEG pour sa gestion du parc vhicule qui viennent
dinvestir avec beaucoup dampleur dans le domaine de linformatique
cause des avantages rendus tout type dentreprises (commerciale,
industrielle, financire,), tout en garantissant des gains multiples en temps
et en argent.
Linformatisation de la gestion du parc vhicule est devenue une ncessit de
premier ordre pour la STEG, vu le nombre important des vhicules dont elle
dispose qui rend lopration de leurs gestion et de leurs maintenance, une
tche pnible, difficile et routinire.
Les technologies web permettent un dploiement rapide et lger
dapplications de gestion au cur de lentreprise. En effet, les principaux
avantages des technologies web tiennent en quelques mots : Interoprabilit,
modularit et souplesse.
Pour cette raison, le changement de la manire de gestion de cette socit
est devenu une ncessit vu son impact positif sur loptimisation du temps.
Il aura donc pour rle damliorer la gestion des vhicules ainsi que de
permettre une meilleure organisation avec un accs plus rapide
linformation.
Dans ce cadre, nous tudierons, analyserons et informatiserons des modules
suivants :
Grer les vhicules,
Grer les rparations,
Grer les entretiens,
D
GESTION DU PARC VEHICULE INTRODUCTION GENERALE

2
Grer lapprovisionnement des pices de rechanges,
Grer les accidents,
Grer les visites techniques,
Grer les fournisseurs.
Enfin, le prsent mmoire intitul "gestion du parc vhicule" s'articule autour
des trois chapitres suivants :
- Le premier chapitre va prsenter la modlisation du mtier o nous
allons dfinir notre mission tout en prsentant lorganisme dans lequel le
projet sera dvelopp.
- Le deuxime chapitre va prsenter la capture des besoins dans le quel
nous allons identifier les acteurs qui interagissent avec le systme
informatis,
- Le troisime chapitre va prsenter lanalyse de deux modles, savoir un
modle statique et une autre dynamique.
- Le quatrime chapitre va soccuper de la conception du logiciel.
- Le cinquime chapitre va tre rserv pour limplmentation et la
ralisation de notre systme informatis.

CHAPITRE 1 :
MODELISATION DU METIER
GESTION DU PARC VEHICULE MODELISATION DU METIER

3
CHAPITRE1 : MODELISATION DU METIER
Introduction
Dans ce chapitre, nous allons tout dabord faire une tude pralable qui
consiste dfinir notre mission tout en prsentant lorganisme dans lequel le
projet sera dvelopp ainsi que son systme dinformation actuel et les
objectifs atteindre. Ensuite, nous passerons au reprage et au diagnostic de
chaque module du domaine. Puis, nous aboutissons llaboration du
diagramme cas dutilisation mtier. Enfin, nous prsenterons nos orientations.
1. Dfinition de la mission
Dans le cadre de notre projet de mmoire de fin dtude, intitul Gestion du
Parc Vhicule , notre mission sarticule principalement autour de la
conception et la ralisation dune application web apte faire une Gestion du
parc vhicule de la socit tunisienne dlectricit et du gaz STEG .
Linformatisation de cette application passe par trois tapes essentielles,
savoir : ltude pralable, la conception et enfin la ralisation de lapplication.
1.1 Prsentation de la socit
Il sagit dans cette partie de prsenter lorganisme pour lequel le projet sest
dvelopp. Cet organisme est la socit tunisienne de llectricit et du gaz
qui est une socit nationale cre par le dcret loi n 62_8 du 3 avril 1962.
La STEG et une entreprise publique caractre industriel et
commercial(EPIC) responsable de la production de llectricit et de gaz
naturel travers toute la Tunisie.
La STEG assure au niveau national la fourniture dlectricit, le
dveloppement du rseau de gaz et la ralisation dune infrastructure
lectrique et gazire permettant un dveloppement quilibr sur tout le
territoire national.
Lactivit dlectricit de la STEG, quarante huit ans aprs sa cration, a vu
passer :
Le taux dlectrification global de 21% 99,2%,

4
Le taux dlectrification rural de 6% 98%,
La puissance installe de 100MW 1.2127 GWH,
La consommation spcifique du parc de 395 239 Tep/GWH,
Le nombre de client de 183.000 a 2.689.000 pour llectricit.
1.1.1 Organigramme

Conseil dadministration
Direction gnrale
Prsident directeur gnral
Directeur gnrale adjoint
Direction Gaz
Direction de la production et
du transport dlectricit
Units rgionales de la production et
du transport de gaz
Units rgionales des
distributions
Units rgionales
production et
transport dlectricit
Direction organisation et systme
dinformation
Direction audit
Direction de contrle
Directions des affaires financires
Direction des affaires administratives et
juridiques
Direction informatique
Direction des affaires gnrales
Direction de lquipement
Direction des tudes et de
planification
Direction conseill en management
Conseil
Centre essais et mesures
S.P.C.M
DP de la coopration et de la
communication

Figure 1 : Organigramme de la Socit Tunisienne dElectricit et du Gaz


5
1.1.2 Prsentation du systme informatique
Dans le but de dcentraliser lactivit informatique, la socit tunisienne
dlectricit et du gaz STEG a cre six centres rgionaux de traitement
informatiques (CTIs) se trouvant Tunis, Sfax, Tunis Marin, Bja, Sousse et
Gafsa. Ces CTIs sont interconnects par un rseau de communication base
des liaisons spcialises haut dbits (frame-relay, LS, RNIS, etc.).
Chaque CTI assure le traitement journalier dun fichier abonn dun ensemble
de districts dune mme rgion qui aboutit une restriction de factures et
dtats. Chaque district est reli au CTI par ligne spcialise permettant :
- La consultation en temps rel du fichier abonns.
- La communication lectronique.
- Laccs linternet et au rseau intranet de lentreprise.
Linfrastructure matrielle dun CTI ou dun district repose sur une
architecture Client /Serveur btie au tour dun rseau local utilisant le
protocole standard TCP/IP.
1.2 Prsentation de lapplication
Il sagit de concevoir et de raliser une application web : Gestion du parc
vhicule qui sera parmi les applications importantes de la socit tunisienne
dlectricit et du gaz STEG , cette gestion qui va consister suivre
lensemble des tches de lactivit du garage rgional de Sfax.
Notre futur systme intitul Gestion du parc vhicule effectuera les
procdures suivantes prsentes ci-aprs :
Gestion des vhicules,
Gestion des rparations,
Gestion des entretiens,
Gestion dapprovisionnements des pices de rechanges,

6
Gestion des accidents,
Gestion des visites techniques,
Gestion des fournisseurs.
1.3 Objectifs atteindre
Lautomatisation complte de la gestion du parc vhicule permettra de
disposer dune information fiable, pertinente et prcise. Elle facilitera aussi
laccs aux diffrents dossiers et assure le contrle ainsi que lacheminement
complet de linformation en temps rel.
Les principaux objectifs sont :
Dvelopper une application assez dynamique pour satisfaire les besoins
futurs du parc tout en assurant la cohrence, la scurit et la
confidentialit des donnes et en facilitant les processus de Gestion du
parc vhicule,
Faciliter la prise de dcision grce au suivi rgulier du parc,
Informatiser le processus de gestion et le suivi des vhicules,
Faciliter la coordination entres les utilisateurs des vhicules et le parc
pour permettre de bien savoir des dates des visites techniques et de fin
de rparation o entretien,
Simplifier les circuits dinformations et diminuer le nombre de
documents utiliss,
Gagner du temps et avoir un accs rapide aux informations,
Amliorer la fiabilit des informations par la mise en place dune base
de donnes jour,
Appliquer les logiciels de base et les outils de dveloppements afin
damliorer la qualit du logiciel,

7
Dterminer les orientations gnrales qui devraient permettre
lobtention de cette qualit,
Eviter les erreurs par linstauration des contrles efficaces lors de la
prise en charge des informations et lutilisation des procdures
informatises pour raliser les diffrents calculs,
Mettre en place un systme rigoureux permettant la cohabitation avec
toutes les autres applications du STEG,
Avoir des outils danalyse et de suivi de la gestion des diffrentes
fonctions de lapplication aidant la prise de dcision (statistiques
relles sur les diffrentes oprations effectues),
Mettre en place une application web rigoureuse qui assure un certain
niveau de scurit.
1.4 Planning prvisionnel
Afin dassurer la russite de notre projet, il faut le dcomposer en tches
divines et raliser un planning descriptif de chaque tche. Le diagramme de
Gantt donn ci-aprs reprsente la progression prvisionnelle de notre travail
ainsi que les dlais approximatifs ncessaires pour la ralisation relle de
chaque tche.

Octobre Novembre Dcembre Fvrier Mars Avril Mai Juin
Phase dEtude
thorique

Phase de conception
Phase de Ralisation
Tableau 1 : Diagramme de Gantt de ralisation de notre application

8
2. Reprage et diagnostic du domaine
Dans le but de satisfaire les diffrents utilisateurs et de dvelopper un logiciel
de qualit, nous tions amener analyser lexistant de la gestion du parc de
vhicule afin de dgager les dfaillances du systme actuel.
Cette partie sarticule autour de deux volets :
Etude de lexistant.
Critiques de lexistant.
La gestion du parc vhicule est une gestion trs importante pour la STEG
quil doit tre bien matriser pour bien suivre et contrler les interventions
(gestion de rparation, gestion dentretien, gestion des visites techniques),
grer les commandes des pices de rechanges et les fournisseurs et tablir
des statistiques qui aident la prise de dcision.
Pour cela, il est intressant davoir une application qui permet de grer les
diffrentes missions du garage rgional de Sfax.
Lapplication Gestion du parc vhicule a t dveloppe avec dbase3+
(language de programmation) pour le garage. Elle a t instaler localement
sur un poste client et ne permet pas aux diffrents units ou districts de
suivre les oprations ralises dans le garage ainsi que les changes des
documents et dinformations ncessaires .
Ce logiciel couvre les modules suivants :
- Gestion des interventions ( rparation,entretien),
- Gestion vhicule.
Dans ce qui suit, on va prsenter lexistant et les critiques pour chaque
gestion, ainsi que les problmes qui ont rsult par lancienne application.
2.1 Gestion des rparations
On peut rsumer le processus de rparation existant comme suit :

9
Etude de lexistant
Tout vhicule de la socit tunisienne dlectricit et de gaz STEG
peut se prsenter au garage rgional Sfax pour tre rpar,
Le chauffeur du vhicule en panne doit se prsente dans le parc
accompagn par un bon de prestation interne (demande de rparation),
Le chef du parc vrifie ce bon et tablie une fiche dadmission
contenant les observations ncessaires et les diagnostics concerns,
Le chef du parc dcide si ce vhicule va tre rpar par les mcaniciens
du garage (rparation interne) ou il va tre envoy vers dautres garages
externes (rparation externe),
Un mme vhicule peut tre rpar lintrieur du garage et
lextrieur au mme temps,
Le chef du parc enregistre le cot des pices changes sil sagit dune
rparation interne.
Le chef du parc reois un bon dessaie de la part du mcanicien qui a
contrl le vhicule et sil sagit dune rparation externe, le bon
dessai doit tre accompagn par une facture de rparation.
Le chef du parc envoie la facture de rparation au service financier et
comptable aprs avoir gard une copie.
Critique de lexistant
Le logiciel existant dans le parc ne permet pas de grer le suivi des
rparations correctement, ce qui rend cette phase trs difficile.
Lutilisation frquente des documents (bon de prestation, fiche
dadmission, fiche dessaie) engendre la perte du temps et une
documentation volumineuse difficile grer.

10
2.2 Gestion des entretiens
Etude de lexistant
Le chauffeur du vhicule se prsente dans le parc pour raliser la phase
dentretien accompagn dun bon de prestation interne.
Le chef vrifie la nature de ce bon sagit-il dune demande dentretien.
Le chef du parc notifie le nouvel index de kilomtrages parcourus ainsi
que la date du prochain entretien.
Critiques de lexistant
Labsence de communications entre le parc et les diffrentes units et
districts du STEG engendre une absence dinformations concernant les
tats des vhicules.
Toute la phase dentretien est gre manuellement, ce qui a pour
consquences lutilisation dun volume de papiers norme.
Lexistence dun logiciel install localement dans le parc ne rpond pas
aux besoins nouveaux des utilisateurs.
2.3 Gestion des visites techniques
Etude de lexistant
La majorit des vhicules de la STEG se prsente dans le parc avant
la date de leurs visites techniques pour tre rparer ou entretenu avant
dtre envoyer.
Le chauffeur dun vhicule se prsente muni dun bon de prestation
interne (demande dune visite technique).
Le chauffeur reoit le vhicule aprs sa rparation ou son entretien pour
quil soit prt pour la visite technique la date prvue.


11
Absence dune application dynamique dans le parc qui permet aux
units et aux districts de la STEG de savoir la date de la prochaine
visite technique de chaque vhicule.
Une mauvaise planification de la gestion des visites techniques ce qui
engendre un dpassement de la date de leur visite technique cause de
labsence dun systme dalerte.
2.4 Gestion dapprovisionnement des pices de rechanges
Etude de lexistant
Le gestionnaire du parc reoit des bons de commandes locales
contenant les pices ncessaires la rparation.
Le gestionnaire du parc vrifie ces bons, les regroupes et tablie un bon
de commande global pour chaque fournisseur.
Le gestionnaire envoi ces bons globaux vers le service financier et
comptable.
Le service financier et comptable vrifie ces bons et les envoi vers le
directeur rgional de distribution pour les signer.
Le dmarcheur reoit les bons signes et contacte les fournisseurs pour
effectuer lopration dachat.
Le chef du parc reoit les pices accompagnes dun bon de livraison et
de la facture concern.
Le chef du parc envoi la facture au service financier et comptable aprs
avoir gard une copie.


12
Tout le processus dachat est gr manuellement.
Lutilisation frquente des documents (bon de commande local, bon de
commande global, facture,) qui engendre la perte du temps, le cot
des papiers et une documentation volumineuses non facilement
exploites.
2.5 Gestion des vhicules
Etude de lexistant
Accder aux fichiers des vhicules pour savoir les informations
concernant chaque vhicule (date du prochain entretien, date de la
prochaine visite technique, les cots annuelles des interventions).
Effectuer des oprations de mise jour sur les diffrents vhicules de
la STEG .
Accs non rapide aux donnes des vhicules pour connatre leurs tats
actuels.
Consultation des vhicules trs limite qui ne conduit pas tirer les
informations ncessaires.
3. Diagramme de cas dutilisation mtier
Diagramme de contexte mtier
Le systme mtier constitue la modlisation de lactivit de lorganisation
selon une vision externe et une vision interne. Il dcrit les aspects statiques et
dynamiques de lactivit de lentreprise. Ainsi, le systme de gestion parc
vhicule de cette entreprise est en interaction avec les acteurs suivants :
Les fournisseurs,

13
Le service financier et comptable,
Les garages externes,
LATTT (Agence Techniques des Transports Terrestres).
Ces interactions sont modlises par le diagramme ci-aprs :

Les flux des donnes changes entre le systme et les diffrents acteurs
sont :
1-Demande de devis,
2-Demande de commande,
3-Pices demandes,
4-Bon de livraison,
5-Facture dachat,
6-Demande de devis rparation,
7-Demande de rparation,
8-Devis,
gestion parc vhicule
: service financier et comptable
: garage externe
: fournisseur
: ATTT(l'Agence Technique des
Transports Terrestres)
1,2
3,4,5
6,7
8,9
10,11
12
13,14
Figure 2 : Diagramme de contexte du systme mtier

14
9-Facture de rparation,
10- Factures dachats et de rparation,
11-Bon de commande globale,
12-Demande de visite technique,
13-Reu de montant,
14-Rapport de la visite.
Diagramme de cas dutilisation mtier

visite technique reparation entretien
ATTT(Agence Technique des transports terrestres)
fourniseur
gestion pieces de rechanges
service comptable et financier
gestion intervention
gestion accident
garage externe
Figure 3 : Diagramme de cas dutilisation mtier

15
4. Description des processus mtier
Processus Type Evnement dclencheurs Activits
Gestion des
interventions
mtier - Vhicule en panne
- Kilomtrage atteint
- Visite technique
-Envoi du vhicule pour la
rparation ou la visite
technique
-Prise en charge dun bon
de prestation interne.
-Etablir une fiche
dadmission du vhicule.
-Dterminer les pices de
rechanges.
-Rparer ou entretenir le
vhicule.
-Etablir un bon dessai sil
sagit dune rparation
externe.
-Recevoir une facture
dintervention externe.
-Remplir le bon de
prestation pour ltat de
sortie.
-Remise du vhicule au
chauffeur la date de fin
de rparation.
-Envoi de la facture au
service financier et
comptable aprs avoir
garder une copie.

16
Gestion
dachat des
pices de
rechanges
mtier - Demande dachat des
pices
- Manque des pices
dans le magasin.
-Envoi dun bon de
commande local au
gestionnaire.
-Regroupement des bons
de commande local et
tablissement dun bon de
commandes global.
-Envoi de ce bon de
commande au directeur
gnral pour le vrifi et
le sign
-Rception de ce bon par
le dmarcheur.
-Envoi du bon de
commande au fournisseur.
-Rception des pices de
rechanges accompagnes
dun bon de livraison et
dune facture.
-Envoi des factures au
service financier et
comptable aprs avoir
garder une copie.
Gestion des
vhicules
support
Ordre de prise
de dcision
Pilotage - Vente des vhicules
(reforme)
- Rapport technique sur
ltat des vhicules.
- Ltablissement dun
rapport technique.
- Envoie de ce rapport au
chef rgional de

17
distribution.
- Rception dun ordre de
dcision.
Gestion des
accidents
mtier Vhicule accidents - Etablir un rapport
technique.
- Envoie du vhicule pour
la rparation.

5. Dfinition des orientations
La solution propose, pour remdier ces dfaillances, est le dveloppement
dune application de gestion du parc vhicule qui est capable damliorer le
quotidien du gestionnaire et aussi dimplmenter une base de donnes
complte pour la gestion des diffrents types dactivits.
On distingue trois types dorientations :
Orientation de gestion.
Orientation dorganisation.
Orientation technique.
5.1 Orientations de gestion
Les principales orientations de gestion sont :
Allger au maximum lintervention manuelle surtout au niveau de la
gestion et du suivi des interventions effectues sur les vhicules.
Optimiser le temps daccs aux diffrentes donnes concernant les
vhicules de la STEG.
Implanter une application dynamique complte permettant la gestion et
le suivi des vhicules.
Tableau 2 : Tableau de description des processus mtier

18
Assurer la cohrence et la confidentialit des donnes et lobtention
dune information en temps rel pour garantir aux utilisateurs laccs
une information exacte et prcise.
Faciliter le travail du responsable dans le parc puisquil soccupe
presque de la totalit du travail dans le parc.
Fournir une information en temps rel sur ltat des vhicules aide les
dcideurs la prise de dcision concernant les vhicules de la STEG.
Assurer une meilleure communication entre le parc et les diffrents
services de la STEG et surtout une cohrence de linformation.
5.2 Orientations dorganisation
Les principales orientations dorganisation sont :
Dcentraliser linformation : les donnes seront accessibles tout
moment.
Aboutir une circulation formelle des informations surtout entre le parc
et les diffrents services du STEG.
Utiliser le temps rel pour toute mise jour (consultation ou
modification de linformation).
Dfinir les responsabilits de cration et de mise jour des donnes au
personnel.
Dfinir les responsabilits de cration et de mise jour des donnes
certain personnel de la socit (limit laccs aux donns).
5.3 Orientations techniques
Les orientations techniques sont :
Veiller la confidentialit et la scurit de linformation en
dfinissant un jeu de permission (mot de passe) et des rgles de
contrles et de sauvegarde de linformation.

19
Concevoir et dvelopper un logiciel extensible et volutif qui rpond
aux besoins de ces utilisateurs.
Donner beaucoup dimportance linterface homme-machine et
simplifier au maximum lutilisation de lapplication par lutilisateur.
Sensibiliser les utilisateurs envers les outils informatiques,
Favoriser une formation pour les utilisateurs du nouveau systme,
Dvelopper le maximum de procdures en appliquant la technique
temps rel pour la saisie des donnes.

Conclusion
A la lumire de cette tude, une base de donnes doit tre mise en relief mais
avant de cr cette base o nous allons enregistrer toutes les informations et
les donnes ncessaires, nous devrons raliser une modlisation conceptuelle
de notre application, qui sera lobjectif du chapitre suivant.

CHAPITRE 2 :
CAPTURE DES BESOINS
GESTION DU PARC VEHICULE CAPTURE DES BESOINS

20
CHAPITRE 2 : Capture des besoins
Introduction
Dans ce chapitre, nous allons identifier les acteurs qui interagissent avec le
systme informatis et dvelopper le diagramme de contexte informatis pour
pouvoir tablir prcisment les frontires du systme. De plus, nous allons
laborer les diagrammes des cas dutilisation avec une description textuelle
dtaille de chaque cas dutilisation et par suite nous dterminerons ses
classes participantes. Enfin, nous nous intresserons au dcoupage en
package.
1. Choix dUML dans la conception
UML (Unified Modeling Language) est un langage de modlisation dobjet. Il
peut tre associ toutes les dmarches de conception ainsi quon peut
lappliquer tous les processus de conception ; lUML couvre le cycle de
dveloppement des logiciels en commenant de la spcification des besoins
jusqu limplmentation sous forme dun ensemble de diagrammes.
2. Acteurs du systme informatis
Un acteur reprsente un rle jou par une entit externe (utilisateur humain,
dispositif matriel ou autre systme) qui interagit directement avec le
systme tudi. Un acteur peut consulter et/ou modifier directement ltat du
systme, en mettant et/ou en recevant des messages susceptibles dtre
porteurs de donnes.
Les acteurs candidats sont systmatiquement :
- Les utilisateurs humains directs : on doit identifier tous les profils
possibles.
- Les autres systmes connexes qui intragissent aussi directement avec le
systme tudi, souvent par le biais de protocoles bidirectionnels.

21
Pour lapplication de la gestion du parc vehicules, les acteurs humains sont
les suivants :
Le chef de parc
Il sera responsable du bon fonctionnement de lapplication et de sa
maintenance.
Il est responsable aussi de grer et de mettre jour les vhicules, grer et
suivre les interventions, les accidents et les fournisseur ainsi que
ltablissement des tats mensielle et les rapports techniques et
dinformations.
Les utilisateurs des vhicules
Ils sont autoriss :
Consulter la fiche vhicule concern pour savoir son tat actuel.
Prvoir la date du prochain entretien pour chaque vhicule.
Consulter la liste des interventions effectues sur leurs vhicules.
Prvoir la date de la prochaine visite technique.
Directeur rgional
Il a lautorisation de :
Consulter toutes informations pour le suivi rgulier du garage.
Grer les vhicules accidents.
Prondre des rensiegnements concernant les cots des interventions
effectues sur chaque vhicule.
Prendre les dcisions concernant lachats de quelques pices de
rechanges.
Prendre des dcision concernant les demandes emis par le garage.


22
Responsable dachat
Il sera responsable de :
Grer les commandes dachats des pices de rechanges.
Grer les devis fournisseurs.
Grer le retour de pices de rechanges.
3. Modle de contexte du systme informatis
Le systme informatique couvre la partie du systme mtier qui donne lieu
une automatisation. Sa modlisation fournit une image de lactivit des
utilisateurs au niveau oprationnel et au niveau physique, comme le montre la
figure suivante :

Les flux changs entre le systme et les diffrents acteurs sont :
1: Mise jour des vhicules,
2 : Mise jour des interventions (rparation, entretien, visite technique),
Figure 4 : Diagramme de contexte du systme informatis
gestion parc
vhicule
: responsable
d'achat
: utilisateurs
vhicules
: directeur regional
: chef de parc
1,2,3
4,5,6
7,8
9,10
11,12
13
14,15
16,17

23
3 : Mise jour des accidents,
4 : Liste des vhicules,
5 : Liste des interventions (rparation, entretien, visite technique),
6 : Liste des accidents,
7 : Demande dinformation sur les vhicules,
8 : Demande dinformation des interventions (rparation, entretien, visite
technique),
9 : Liste des vhicules (toutes les informations),
10 : Liste des interventions (rparation , entretien, visite technique),
11 : Mise jour des commandes,
12 : Bons des commandes fournisseurs,
13 : Listes des commandes fournisseurs,
14 : Demandes dinformations,
15 : Demandes de consultation (vhicule, intervention, commandes, ect ),
16 : Listes dinformations,
17 : Fiches des consultation.
4. Elaboration du modle des cas dutilisation
4.1. Diagramme des cas dutilisation
Le diagramme des cas dutilisation permet de reprsenter les diffrents
scnarios prsents que peuvent avoir les diffrents utilisateurs du systme.
Les diagrammes ci-aprs reprsentent les diagrammes des cas dutilisation de
modlisation de gestion parc vhicule.


24

Figure 5: Diagramme cas dutilisation relatif la gestion des interventions
reparation interne reparation externe
gerer reparation
gerer entretien
chef de parc
gerer visite technique
gerer reforme
<<extend>>
authentification
<<include>>
<<include>>
<<include>>
<<include>>
directeur regional
gerer accident
<<extend>>
<<include>>

25

Figure 6: Diagramme cas dutilisation relatif la gestion des pices de rechanges
Figure 7: Diagramme cas dutilisation relatif la gestion des vhicules
chef de parc
gerer facture d'avoire gerer bon de retour
authentification
gerer devis
<<include>>
gerer retour pieces
<<include>>
gerer commande
responsable d'achat
<<include>>
gerer fournissuer
<<include>>
utilisateur vhicule
directeur regional
gerer vhicule authentification
<<include>>

26
4.2. Description textuelle des cas dutilisation
Cas dutilisation authentification
Acteur : tous les acteurs.
Objectifs : ce cas dutilisation est utilis pour contrler laccs lapplication.
Pr condition : un utilisateur existe dans le systme.
Post condition : une nouvelle session est ouverte.
Scnario nominal :
Ce cas dutilisation dbute quand un acteur demande de sauthentifier.
Le systme propose au demandeur de saisir son login name et son mot de
passe.
Le systme vrifie le login name et son mot de passe. Sil ne le trouve pas
alors il excute Exeption1.
Exception :
1 : le systme affiche le message login Name ou mot de passe incorrect et
demande lutilisateur de saisir de nouveau les informations exiges.
Le scnario se termine lorsque le systme accepte la connexion de
lutilisateur.
Cas dutilisation grer vhicule
Acteur : chef de parc , utilisateurs des vhicules.
Objectif : Ce cas dutilisation est utilis pour grer et faire le suivi des
vhicules.
Pr condition : Le chef du parc doit sauthentifier.
Post condition : un nouveau vhicule est enregistr dans le systme.
Un vhicule supprim nexiste plus dans le systme.

27
Scnario nominal :
Ce cas dutilisation dbute quand le chef du parc demande lajout dun nouvel
vhicule.
Le systme vrifie que le chef est autoris manipuler les vhicules et le
processus se poursuit selon les tapes suivantes :
a. Saisie des informations
Le systme propose lutilisateur laction quil va raliser.
Le chef du parc demande lajout dun nouvel vhicule.
Le chef du parc saisie les informations concernant le nouvel vhicule.
b. Validation de lajout
Le chef demande la validation de lajout.
Le systme vrifie lexactitude des informations (que tous les champs
obligatoires sont saisis). Sil y a une information manquante, alors il doit
excuter Exception 1.
Le systme cherche le numro dimmatriculation saisie. Sil le trouve, alors il
doit excuter Exception 2.
Le scnario se termine lorsque le systme enregistre lajout dun nouvel
vhicule.
A tout moment le chef peut annuler la saisie du vhicule.
Scnarios alternatif :
1. Modifier un vhicule existant.
2. Consulter les vhicules existants.
3. supprimer un vhicule existant.


28
Exceptions :
1 : Le systme affiche le message : il existe des informations manquante .
2 : Le systme affiche le message : vhicule existe dj .
Cas dutilisation grer rparation
Acteur : chef du parc.
Objectif : ce cas dutilisation est utilis pour grer et suivre les rparations.
Post condition : lintervention est enregistre dans le systme. Le vhicule est
marqu rpar .
Scnario nominal : cration dintervention :
Ce cas dutilisation dbute quand le chef du parc demande de crer une
nouvelle rparation.
Le systme vrifie que le chef est autoris manipuler les interventions et le
a. Saisie des informations :
Le chef du parc demande lajout dune nouvelle rparation.
Le chef du parc saisie les informations concernant la nouvelle rparation.
b. Validation de lajout :
Le systme marque le vhicule respectivement en rparation .

29
Le systme enregistre les informations saisies.
Le scnario se termine lorsque le systme enregistre les informations et
affecte un numro la rparation.
Scnarios alternatifs :
1- Modifier une rparation.
2- Consulter les rparations.
3- Supprimer une rparation.
Exception :
1 : Le systme affiche le message : il existe une information manquante .
Cas dutilisation grer entretien
Objectif : ce cas dutilisation est utilis pour grer et suivre les entretiens.
Post condition : lintervention est enregistre dans le systme. Le vhicule est
marqu entretenir.
Scnario nominal : cration dintervention :
Ce cas dutilisation dbute quand le chef du parc demande de crer un nouvel
entretien.
Le systme vrifie que le chef est autoris manipuler les interventions et le
a. Saisir dinformation
Le chef du parc demande lajout dun nouvel entretien.
Le chef du parc saisie les informations concernant le nouveau entretien.

30
Le systme marque le vhicule respectivement en entretien
Le systme enregistre les informations saisies.
Le scnario se termine lorsque le systme enregistre les informations et
affecte un numro lentretien.
1- Modifier un entretien.
2- Consulter les entretiens.
3- Supprimer un entretien.
Exception :
1 : Le systme affiche le message : il existe une information manquante
Cas dutilisation grer commandes
Acteur :Responsable dachat.
Objectif : Ce cas dutilisation est utilis pour passer et suivre les commandes
du parc.
Pr condition : le responsable dachat sest authentifi.
Scnario nominal :
Ce cas dutilisation dbute quand le responsable dachat demande de crer
une nouvelle commande.

31
Le systme vrifie que le responsable dachat est autoris crer une nouvelle
commande et le processus se poursuit selon les tapes suivantes :
a. Identification du fournisseur
Le systme propose au responsable dachat de chercher le fournisseur selon
plusieurs critres (code, nom).
Le systme fournit la liste des fournisseurs satisfaisants ce critre.
Si le fournisseur nexiste pas, le responsable dachat lance le scnario de
gestion des fournisseurs pour ajouter un nouveau fournisseur.
Sinon le responsable dachat slectionne le fournisseur souhait.
b. Saisie des articles commands
Le systme propose au responsable dachat de chercher les articles selon
plusieurs critres (code, dsignation, famille, catgorie)
Le systme fournit la liste des articles satisfaisants ce critre.
Pour tout article command, le responsable dachat slectionne les articles
ncessaires et saisie la quantit commande.
Le systme affiche le prix de chaque article slectionn.
Aprs la saisie de tous les articles commands, le systme affiche le total de la
commande.
c. Validation de la commande
Le responsable dachat demande la validation de la commande.
A tout moment le vendeur peut annuler la saisie de la commande.
1. Modifier une commande
- Le responsable achat peut modifier les donnes dune commande.

32
-Le systme propose au responsable achat plusieurs critres de recherche
(numro, date, ).
- Le responsable dachat saisit les critres de recherche.
- Le systme affiche la commande relative aux critres saisis, sinon le
systme excute exception1.
- Le responsable dachat saisit les modifications apporter.
- Le systme enregistre alors la commande modifie aprs validation.
2. Consulter une commande :
- Le responsable dachat peut consulter les caractristiques dune
commande.
-Le systme propose au responsable dachat plusieurs critres de
recherche (numro, date, ).
3. Supprimer une commande.
- Le responsable dachat peut supprimer une commande.
-Le systme propose au responsable dachat plusieurs critres de
recherche (numro, date, ).
- Le systme dsactive la commande aprs validation.
Exception :
1 : Le systme affiche le message : Commande inexistante.

33
Cas dutilisation grer fournisseur
Acteur : Chef du parc.
Objectif : Ce cas dutilisation est utilis pour grer les fournisseurs.
Post condition : Un nouveau fournisseur est enregistr dans le systme.
Un fournisseur supprim nexiste plus dans le systme.
Scnario nominal : Lajout dun nouveau fournisseur.
Ce cas dutilisation dbute quand le chef du parc demande lajout dun
nouveau fournisseur.
Le systme vrifie que le chef du parc est autoris manipuler les
informations concernant les fournisseurs et le processus se poursuit selon les
tapes suivantes :
Le chef du parc demande lajout dun nouveau fournisseur.
Le chef du parc saisie les informations concernant ce nouveau fournisseur.
Le chef du parc demande la validation de lajout.
Le systme cherche le code de ce fournisseur. Sil le trouve, alors il doit
Le scnario se termine lorsque le systme enregistre lajout dun nouveau
fournisseur.

34
A tout moment le chef du parc peut annuler la saisie dun fournisseur.
1. Modifier les informations dun fournisseur existant.
2. Consulter les informations dun fournisseur existant.
3. Supprimer les informations dun fournisseur existant.
Exceptions :
1 : Le systme affiche le message : Il existe des informations manquante .
2 : Le systme affiche le message : Fournisseur existe dj .
Cas dutilisation grer accidents
Acteur : chef du parc , directeur rgional.
Objectif : Ce cas dutilisation est utilis pour grer et suivre les vhicules
accidents.
Post condition : Un nouveau vhicule accident est enregistr dans le systme.
Un vhicule accident supprim nexiste plus dans le systme.
Scnario nominal :
Ce cas dutilisation dbute quand le chef du parc demande lajout dun
nouveau vhicule accident.
Le systme vrifie que le chef du parc est autoris manipuler les vhicules et
le processus se poursuit selon les tapes suivantes :
Le chef du parc demande lajout dun nouveau vhicule.
Le chef du parc saisie les informations concernant ce nouveau vhicule.

35
Le chef du parc demande la validation de lajout.
Le scnario se termine lorsque le systme enregistre lajout.
A tout moment, le chef peut annuler la saisie du vhicule.
Le chef du parc envoie au directeur rgional un rapport technique en cas dun
accident grave pour quil puisse prendre des dcisions concernant cet
accident.
1. Modifier les informations dun vhicule existant.
2. Consulter les statistiques des accidents existants.
3. Supprimer un vhicule accident existant.
Exception :
1 : Le systme affiche le message : il existe des informations manquante .
Cas dutilisation grer visites techniques
Objectif : Ce cas dutilisation est utilis pour grer les visites techniques.
Pr condition : chef deu parc doit sauthentifier.
Post condition : Un vhicule supprim nexiste plus dans le systme.
Scnario nominal :
Ce cas dutilisation dbute quand le chef du parc demande de crer une
nouvelle visite.

36
Le systme vrifie que le chef est autoris manipuler les visites et le
Le chef du parc demande lajout dune visite.
Le scnario se termine lorsque le systme enregistre lajout.
A tout moment le chef peut annuler la saisie de la visite.
1. Consulter les visites existantes.
2. Supprimer une visite existante.
Exception :
1 : Le systme affiche le message : il existe des informations manquantes
Nb : les cas dutilisation grer les devis et grer les retours pices
entre dans notre procdure et dans la conception du parc mais ne sont
pas des cas dutilisations qui vont tre implments dans lapplication
cest pour cela que nous navons pas fait leurs descriptions textuelles.
4.3. Diagramme de classes participantes
Il sagit de diagrammes de classes UML qui dcrit pour chaque cas
dutilisation, les principales classes mtier ncessaires et les relations entre
elles.

37
Les diagrammes de classe participantes sont particulirement importants car
dune part, ils font la jonction entre les cas dutilisation, le modle de
domaine et les interfaces et dautre part, ils permettent de retrouver les classes
du modle statique et les relations entre elles.
En effet, la fusion de ces diagrammes menant un diagramme de classe qui
contient presque toute les classes du modle statique.
Dans ce qui suit, nous allons traiter les classes participantes pour chaque cas
dutilisation.
Cas dutilisation authentification
Pour accder cette application, chaque utilisateur doit sauthentifier auprs
de son district ou dune unit sous un district concerne. Les classes
participantes dans ce cas dutilisation sont :
- Utilisateurs.
- Permission.
- Menu.

Cas dutilisation grer devis
A la prsence de plusieurs fournisseurs de pices de rechanges, il demande
ltablissement dun devis. Les classes participantes dans ce cas dutilisation :
Figure 8 : Diagramme des classes participantes au cas dutilisation grer authentification

38
- Pice rechange
- Fournisseur
- Devis
- Ligne devis
- Famille pices
- Marque

Cas dutilisation grer commandes
A la prsence des fournisseurs et une demande dapprovisionnement on va
passer une commande.
Do les classes participantes dans ce cas dutilisation sont :
Figure 9: Diagramme des classes participantes au cas dutilisation grer devis

39
- Fournisseur
- Pice de rechange
- Commande
- Ligne commande
- Marque
- Famille pices

Cas dutilisation retour pices rechanges
Les classes participantes dans ce cas dutilisation :
- Fournisseur
- Commande
- Ligne commande
Figure 10 : Diagramme des classes participantes au cas dutilisation grer commandes

40
- Pices rechanges
- Famille pices
- Marque
- Bon de livraison
- Ligne bon livraison
- Bon de retour
- Ligne bon de retour

Cas dutilisation grer rparation
Ce cas dutilisation concerne la rparation des vhicules, le suivi des
rparations ainsi que les pices ncessaire ces traitements. Les classes
Figure 11 : Diagramme des classes participantes au cas dutilisation retour pices rechanges

41
- Vhicule
- Rparation
- Type rparation
- Rparation externe
- Rparation interne
- Pice de rechange
- Famille pice
- Marque
- Entretien
- Garage externe
- Devis rparation
- Facture rparation
- Essaie


42

Figure 12 : Diagramme des classes participantes au cas dutilisation rparation

43
Cas dutilisation grer entretien
Ce cas dutilisation concerne lentretien des vhicules. Les classes
- Entretien
- Type entretien
- Vhicule
- Pice de rechange
- Marque
- Famille pices

Figure 13 : Diagramme des classes participantes au cas dutilisation grer entretien

44
Cas dutilisation grer accident
Ce cas dutilisation concerne la gestion des accidents des vhicules. Les
classes participantes dans ce cas dutilisation sont :
- Vhicule
- Rparation
- rparation externe
- rparation interne
- accident

Figure 14 : Diagramme des classes participantes au cas dutilisation grer accident

45
Cas dutilisation grer visite technique
Ce cas dutilisation concerne les visites techniques des vhicules, les dates des
visites et les rsultats appropris. Les classes participantes dans ce cas
dutilisation sont :
- Vhicule
- visite technique

Cas dutilisation grer reforme
Ce cas dutilisation concerne la gestion des vhicules reforms et ces causes.
Les classes participantes dans ce cas dutilisation sont :
- Vhicule
- reforme

Figure 15 : Diagramme des classes participantes au cas dutilisation grer visite technique
Figure 16 : Diagramme des classes participantes au cas dutilisation grer reforme

46
Cas dutilisation grer vhicule
Ce cas dutilisation concerne la gestion des vhicules. Les classes
- Vhicule
- Catgorie
- Unit
- District

Cas dutilisation grer fournisseur
Ce cas dutilisation concerne la gestion des fournisseurs. Les classes
- Fournisseur
- Famille pices
- Marque
Figure 17 : Diagramme des classes participantes au cas dutilisation grer vhicule

47

5. Dfinition des priorits
Nous avons opt pour une classification selon le degr dimportance des cas
dutilisation :

Priorit Cas dutilisation Acteurs
1 Grer authentification Tous les acteurs du systme informatis
2 Grer vhicule Chef du parc
3 Grer entretien Chef du parc
4 Grer rparation Chef du parc
5 Grer visite technique Chef du parc
6 Grer accident Chef du parc et directeur rgional
7 Grer fournisseur Responsable dachat
8 Grer commande Responsable dachat
Figure 18 : Diagramme des classes participantes au cas dutilisation grer fournisseurs
Tableau 3 : Tableaux des priorits

48
6. dcoupage en package
Package approvisionnement

Figure 19: Package approvisionnement

49
Package interventions

Figure 20 : Package intervention

50

Package vhicules

Figure 21 : Package vhicules

51
Conclusion
Dans ce chapitre, nous avons tudi de manire dtaille notre solution future
en prsentant les diagrammes des cas dutilisation et les classes participantes
correspondantes chaque cas dutilisation. Enfin, on a procd au dcoupage
en packages.

CHAPITRE 3 :
ANALYSE
GESTION DU PARC VEHICULE ANALYSE

52
CHAPITRE 3 : ANALYSE
Introduction
Lors de la modlisation dun systme informatique, le concepteur est devant
deux vues : lune est statique et lautre est dynamique. Pour cela, nous allons
analyser dans ce chapitre deux modles : un modle statique reprsent par un
diagramme de classe et un diagramme dobjet et un modle dynamique
reprsent par des diagrammes de squences et des diagrammes dtat-
transitions.
1. Dveloppement du modle statique
1.1. Construction du diagramme de classes
1.1.1. Dfinition
Le diagramme de classe exprime de manire gnrale la structure dun
systme, en termes de classes et de relations entre elles. De mme une classe
dcrit un ensemble dobjets ; une association dcrit un ensemble de liens ; les
objets sont instances des classes et les liens sont des instances relations. Dans
le but de construire le diagramme de classes, nous nous basons, dune part,
sur une tude du domaine et, dautre part, sur lanalyse des cas dutilisation et
les diagrammes de classes participantes obtenus dans le chapitre prcdent.
Une premire consquence de cette tude est le dictionnaire de donnes
suivant qui regroupent toutes les informations manipules dans notre
domaine dtude. Ce dictionnaire nous aidera complter lensemble de
classes mtier du domaine recenses prcdemment et identifier leurs
attributs.


53
1.1.2. Dictionnaire de donnes
Le tableau qui suit prsente le dictionnaire de donnes :
Nom de la classe Attributs Description

Accident
RefAcc Rfrence dun accident.
DateAcc Date dun accident.
LieuAcc Lieu dun accident.

Unit
CodeUnite Code dune unit.
LibellUnite Libell dune unit.
AdrUnite Adresse dune unit.

Type entretien
CodeType Code dun entretien.
Libell Libell dun entretien.

Type rparation
CodeType Code type dune rparation.
Libell Libell dune rparation.

Type quipement
CodeEquip Code type dun quipement.
Libell Dsignation dun quipement.
NumLigneRet Numro dune ligne de retour.
QtRetour Quantit dune ligne de retour.

Bon de livraison
NumBL Numro dun bon de livraison.
DatBL Date dun bon de livraison.
QtPices Quantit des pices de
rechanges dune livraison.
NumBon Numro dun bon de retour.

54
Bon de retour datBon Date dun bon de retour.
QteRetourn Quantit retourn des pices de
rechanges.
NumligneCom Numro dune ligne
commande.
QtPices Quantit dune ligne
commande.
Mht Montant hors taxe dune ligne
commande.
Visite Technique
ReffVisit Rfrence dune visite
technique.
DatVisit Date dune visite technique.
LieuVisit Lieu dune visite technique.

Commande
NumCom Numro dune commande.
DatCom Date dune commande.
MontantCom Montant dune commande.
QtCom Quantit des pices dune
commande.
District
CodDist Code dun district.
libellDist Libell dun district.
NbUnit Nombre dunit dun district.
AdrDist Adresse dun district.
Pice de rechange
ReffPices Rfrence dune pice.
libell Libell dune pice.

55
PrixUnit Prix unitaire dune pice.
QtStock Quantit en stock dune pice.
SeuilMin Seuil minimal dune pice.

Vhicule
ImmatVh Numro de matricule dun
vhicule.
Marque Marque dun vhicule.
Index Index dun vhicule.
UniteFrais Unit frais dun vhicule.
UniteTechnique Unit technique dun vhicule.
DatMEM date de mise en marche dun
vhicule.

Reforme

NumReforme Numro dun reforme.
Intutile Inutile de reforme.
description Description dun vhicule
reform.
ValeurAcqui Valeur dacquisition dun
vhicule.
DureeAmortiss Dure damortissement dun
vhicule.
Etat Etat dun vhicule reform.
DatAquisition Date dacquisition dun
vhicule.
Garage Externe
RaiSocial Raison social du garage.
AdrGar Adresse dun garage.

56
Spcialit Spcialit dun garage.
TellGar Numro de tlphone dun
garage.
Entretien
NumEtre Numro dun entretien.
DatEtre Date dun entretien dun
vhicule.
Index Index actuel de vhicule.
Prochain index Prochain index dun entretien
dun vhicule.
DelaiFiltre Dlai de changement des filtres
dun vhicule.

Rparation

NumRep Numro dune rparation.
DelaiPrevi Dlai prvision dune
rparation.
DateEntree Date dbut dune intervention.
DateSorti Date fin dune intervention.
Delaireel Dlai rel dune intervention.
EtatRep Etat dune rparation.
NumBPI Numro dun bon de Prestation
interne
MatAgentCedant Matricule de lagent cdant

Catgorie CodCatgorie Code dune catgorie.

57
Libell Cat Libell dune catgorie.
Facture
NumFact Numro dune facture.
DatFact Date dune facture.
MontantRep Montant de rparation.
Essaie
DateEssaie Date dun essai
IndexDeb Index dbut dun vhicule.
IndexFin Index fin dun vhicule.
Famille pices

CodFall Code dune famille des pices.
Libell Libell dune famille des
pices.
Fournisseur

CodFrss Code dun fournisseur.
NomFrss Nom dun fournisseur.
PrenomFrss Prnom dun fournisseur.
AdrFrss Adresse dun fournisseur.
FaxFrss Fax dun fournisseur.
Ville Ville dun fournisseur.
NumTel Numro de tlphone dun
fournisseur.
CodMrq Code dune marque des pices
de rechanges.

58
Marque
libell Libell dune marque des
pices de rechanges.

Devis
NumDevis Numro dun devis fournisseur
Dlai Dlai dun devis.
TVA Taxes sur la valeur ajoute
Remise Remise.
DatDevis Date dun devis.
Ligne Devis

NumligneDevis Numro dun devis.
QtePices Quantit des pices dun devis.
Mht Montant dun devis.
Rparation Interne

MatAgentReception
naire
Matricule Agent
rceptionnaire.
MatInterveneur Matricule dun intervenant.
Rparation Externe

MatAgentEsseyeur Matricule dun agent Essayeur.
NomAgentEsseyeur Nom dun agent Essayeur.
Facture Rep
NumFact Numro de la facture de
rparation.
DatFact Date de la facture dune
rparation.
MontantRep Montant de la facture.
Type Equipement
CodTyp Code dun type dquipement.
Designation Dsignation dun type

59
dquipement.
Equipement
CodEquip Code dun quipement.
Libell Libell dun quipement.
Ligne Bon Livraison
Numligneliv Numro ligne livraison.
QtPices Quantit des pices livr.
Ligne Retour
NumligneRet Numro ligne retour.
Qte Retour Quantit retourn.
Ligne Commande
NumligneCom Numro ligne commande.
QtePieces Quantit des pices.
Mht Montant hors taxe.

Tableau 4: Dictionnaire de donnes

60
1.1.3. Reprsentation des diagrammes de classe
Figure 22: Diagramme de classes

61
1.2. Construction des diagrammes dobjets
Un diagramme dobjet est un diagramme qui reprsente un ensemble dobjets
et leurs relations un moment donn.
Par dfinition, le diagramme dobjet est une instance dun diagramme de
classes.Il montre ltat modelis un instant donn.
Le diagramme dobjet constitue la modlisation dun tat du systme un
moment donn et la reprsentation dun emsemble dobjets, de leurs tat et de
leurs relations.
Le diagramme dobjet facilite la comprhension des strectures de donnes
complexes.
La figure ci-aprs montre un ensemble dobjets relatifs aux processus de
rparation, dentretien, des devis et des commandes.

62
Figure 23 : Diagramme dobjets

63
2. Dveloppement du modle dynamique
2.1. Construction des diagrammes dinteraction
Un diagramme dintraction montre une interaction c'est--dire un ensemble
dobjets et leurs relations, ainsi que les messages qui peuvent circuler entre
eux.
Parmi les diagramme dinteraction on va utiliser les diagramme de squenses
qui sadoptent mieux a bien reprsenter notre travail.
Un diagramme de squence est un diagramme dinteraction qui met laccent
sur le classement des messages suivant un ordre chronologique. Un
diagramme de squence est un tableau dans lequel les objets sont rangs le
long de laxe des abscisses et les messages,par ordre croissant dapparition, le
long de laxe des ordones.
Diagramme de squence Authentification :
Dans ce diagramme, on va dcrire le squentiellement des tapes
dauthentification des utilisateurs avant daccder notre application.

Figure 24: Diagramme de squence Authentification
: Chef de Parc : Chef de Parc : Ecran:Authentification : Ecran:Authentification
:
Controleur:Authentification
:
Controleur:Authentification
Tous:Utilisateur
s
Tous:Utilisateur
s
Ecran Menu : Menu Ecran Menu : Menu
saisie(login,mot de passe)
vrifier syntaxe(login,mot de passe)
saisie(login,mot de passe)
Rep=chercher(login,mat de passe)
[rep=null] Afficher("login et mot de passe n'est pas valide" )
[rep<>null]Accs a l'application permis

64
Diagramme de squence Ajouter vhicule :
Le chef de parc introduit les informations ncessaires pour ajouter un
vhicule.
Le diagramme de squence suivant illustre le suivi dvnement pour le
scnario Ajouter vhicule .

Diagramme de squence supprimer vhicule :
Le chef de parc selectionne le vhicule quil dsire supprimer .
scnario Supprimer vhicule .

Figure 25: Diagramme de squence ajouter vhicule
: chef de parc : chef de parc
: Ecranvhicule : Ecranvhicule : ControleurVhicule : ControleurVhicule
tous:vhicules tous:vhicules
nouveau:vhicule nouveau:vhicule
1:AjouterVhicule(IMMAT,marque,cathegorie)
2:AjouterVhicule(IMMAT,marque,cathegorie)
3:E:=chercherVhicule(IMMAT)
4:[E<>null]affiche("cette vhicule existe deja")
5:[E=null]creerVhicule(IMMAT,marque,cathegorie)

65

Diagramme de squence ajout commande :
Le responsable dachat introduit les informations ncessaires pour crer une
nouvelle commande.
scnario ajout commande .
Figure 26: Diagramme de squence supprimer vhicule
: chef de parc : chef de parc : Ecranvhicule : Ecranvhicule
: ControleurVhicule : ControleurVhicule
tous:vhicule tous:vhicule
: controlReparation : controlReparation
tous:reparation tous:reparation vhicule vhicule
1supprimerVhicule(IMMAT)
2:supprimer voiture(IMMat)
3:Exist:=chercchrVhicule(IMMAT)
4:[Exist==null]affiche("vhicule n'existe pas")
5:res:=chercherReparation
[res<>null] "la vhicule est en reparation en ne peut pas supprimer"
6:res:=chercher reparation
[res==null]"destory"

66

Diagramme de squence supprimer commande :
Le responsable dachat selectionne la commande qui va supprimer.
scnario supprimer commande .

Figure 27: Diagramme de squence ajouter commande
: Responsable
d'achat
: Responsable
d'achat
: Ecran:Commande : Ecran:Commande
: Controleur:Commande : Controleur:Commande
: Tous:Commandes : Tous:Commandes
: Tous:fournisseurs : Tous:fournisseurs
: tous:pices : tous:pices
: Nouveau:Commande : Nouveau:Commande
Ajouter Commande(Numro,DAte)
Ajouter Commande(Numro,Date)
Chercher Fournisseur(Nom)
C=chercherCommande(Numro)
[C<>null] Afficher("Commande existante impossible d'ajouter ")
F=chercher fournisseur(Nom)
F=chercher Fournisseur (Nom)
F=renvoyer( tlephone,Fax, Adresse )
i:1..n : chercher Pices(dsignation)
A=chercher Pices(dsignation)
A=chercher Pices(dsignation)
A=renvoyer( prix unitaire )
saisir (quantit)
saisir (quantit)
saisir (quantit)
afficher(motant)

67

Diagramme de squence ajout accident :
Le chef de parc introduit les informations ncessaires pour crer un nouvel
accident.
scnario ajout accident .
Figure 28: Diagramme de squence supprimer commande
: Responsable
d'achat
: Responsable
d'achat
: Ecran:Commande : Ecran:Commande : Controleur:Commande : Controleur:Commande
Tous:Command
e
Tous:Command
e
:commande :commande
:lignes
Commande
:lignes
Commande
1:lister Commande(Numro)
2:lister Commande(Numro)
A=chercher Commande(Numro)
Selectionner Commande
Supprimer Commande(Numro)
Supprimer Commande(Numro)
Supprimer Commande()
Supprimer Lignes()
Afficher "commande supprimer avec succs"
supprimer()

68

Diagramme de squence ajout reparation :
Le chef de parc introduit les informations ncessaires pour crer une nouvelle
reparation.
scnario ajout reparation.
Figure 29: Diagramme de squence ajout accident
5:[A=nul]CreAccident(IMMAT,lieu,Date)
: Chef de Parc : Chef de Parc
: ecran Accident : ecran Accident
: controleur Accident : controleur Accident
tous:vhicule tous:vhicule
nouveau:vhicule
Accident
nouveau:vhicule
Accident
1:Ajout Accident(IMMAT,lieu,date)
2:Ajout Accident(IMMAT,lieu,date)
3:A=ChercherVhicule(IMMAT)
4:[A<>null]Afficher("vhiculedja accident...

69
Figure 30: Diagramme de squence rparation
: chef de parc : chef de parc : Ecran:reparation : Ecran:reparation
: rparation : rparation
: :Intervention : :Intervention
: Nouvelle:intervention : Nouvelle:intervention
tous:reparation tous:reparation
nouveau:vhicul
e rpar
nouveau:vhicul
e rpar
: Tous:Intervention : Tous:Intervention
1:ajout Reparation(IMMAT,date Entre,date Sortie...)
2:ajout Reparation(IMMAT,date Entre,date Sortie...)
3:R=Chercher Reparation(IMMAT)
4:[R<>null]Afficher(vhicule existe dja)
[R=null]Cre Reparation(IMMAT,Date Ente,Date Sortie)
Lister Intervention()
Lister Intervention()
Slectionner Pices()
Slectionner Intervention()
Ajouter (Pices,dsignation,Quantit)
[A=null] Affichier(" intervention inxistante")
Cre Intervention()
affichier(" Commande ajouter avec succs")

70
2.2. Construction des diagrammes dtats
Un diagramme dtats-transitions montre un automate tats finis et met en
vidence le flot de contrle dun tat un autre. Un automate tats est un
comportement qui dfinit les squences des tats par lesquels un objets passe
aucours de son existance en rponse des vnements, ainsi que les rponses
de cet objets ces vnements. Un tat est une condition ou une situation
dans la vie dun objet au cours de laquelle cet objet satisfait certaines
conditions, excute une activit ou attend un vnement.
On se limite alors dans cette partie la reprsentation du diagramme dtat
transition dun vhicule car cest lobjet le plus impotant dans notre tude
ainsi quil suit plusieurs changement dtats aucours de son existance.
Diagramme dtat-transition dun vhicule:

Figure 31: Diagramme dtat-transition dun vhicule
disponible
cre
non disponible
en panne
en cas de reparation
ou d'entretien
en panne
en cas de reparation
ou d'entretien
accident
en entretein
envoyer
reparation terminer
rendre [non rpar]
panne
vendre
accident
quand(kilom atteint) entretien terminer
vendre
reparer

71
Conclusion
Dans ce chapitre, on a dvelopp le modle statique en laborant le
diagramme de classes et le diagramme dobjets ainsi que le modle
dynamique en construisant les diagrammes dinteraction et dtats.

CHAPITRE 4 :
CONCEPTION
GESTION DU PARC VEHICULE CONCEPTION

72
CHAPITRE 4 : CONCEPTION
Introduction
Dans ce chapitre, on dfinit larchitecture du systme en prsentant la
conception des diffrentes couches de cette architecture. A la fin, on aboutit
la conception du schma logique des donnes.
1. Dfinition de larchitecture du systme
Les systmes modernes sont organiss en couches horizontales, elles mme
dcoupe en partitions verticales. Ce dcoupage est logique, puis
ventuellement physique.
Architecture en trois niveaux
L'architecture 3-tiers est un modle logique d'architecture applicative qui vise
sparer trs nettement trois couches logicielles au sein d'une mme
application ou systme, modliser et prsenter cette application comme un
empilement de trois couches, tages, niveaux ou strates dont le rle est
clairement dfini :
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 : correspondant aux donnes qui sont destines
tre conserves sur la dure, voire de manire dfinitive.


73

Dans cette approche, les couches communiquent entre elles travers un
modle d'change, et chacune d'entre elles propose un ensemble de services
rendus. Les services d'une couche sont mis disposition de la couche
suprieure. On s'interdit par consquent qu'une couche invoque les services
d'une couche plus basse que la couche immdiatement infrieure ou plus
haute que la couche immdiatement suprieure (chaque niveau ne
communique qu'avec ses voisins immdiats).
Le rle de chacune des couches et leur interface de communication tant bien
dfinis, les fonctionnalits de chacune d'entre elles peuvent voluer sans
induire de changement dans les autres couches. Cependant, une nouvelle
fonctionnalit de l'application peut avoir des rpercussions dans plusieurs
d'entre elles. Il est donc essentiel de dfinir un modle d'change assez souple,
pour permettre une maintenance aise de l'application.
Ce modle d'architecture 3-tiers a pour objectif de rpondre aux
proccupations suivantes :
Allgement du poste de travail client (notamment vis--vis des
architectures classiques client-serveur de donnes typiques des
applications dans un contexte Oracle/Unix) ;
Figure 32: Architecture trois niveaux

74
Prise en compte de l'htrognit des plates-formes (serveurs, clients,
langages, etc.) ;
Amlioration de la scurit des donnes, en supprimant le lien entre le
client et les donnes. Le serveur a pour tche, en plus des traitements
purement mtiers, de vrifier l'intgrit et la validit des donnes avant
de les envoyer dans la couche de donnes ;
Meilleure rpartition de la charge entre diffrents serveurs
d'application.
1.1 Couche Mtier / Business
Elle correspond la partie fonctionnelle de l'application, celle qui implmente
la logique, et qui dcrit les oprations que l'application opre sur les donnes
en fonction des requtes des utilisateurs, effectues au travers de la couche
prsentation.
Les diffrentes rgles de gestion et de contrle du systme sont mises en
uvre dans cette couche.
La couche mtier offre des services applicatifs et mtier la couche
prsentation. Pour fournir ces services, elle s'appuie, le cas chant, sur les
donnes du systme, accessibles au travers des services de la couche
infrieure. En retour, elle renvoie la couche prsentation les rsultats qu'elle
a calculs.
1.2 Couche Prsentation
Elle correspond la partie de l'application visible et interactive avec les
utilisateurs. On parle d'Interface Homme Machine. En informatique, elle peut
tre ralise par une application graphique ou textuelle. Elle peut aussi tre
reprsente en HTML pour tre exploite par un navigateur web ou en WML
pour tre utilise par un tlphone portable.

75
On conoit facilement que cette interface peut prendre de multiples facettes
sans changer la finalit de l'application. Dans le cas d'un systme de
distributeurs de billets, l'automate peut tre diffrent d'une banque l'autre,
mais les fonctionnalits offertes sont similaires et les services sont identiques
(fournir des billets, donner un extrait de compte, etc.).
Toujours dans le secteur bancaire, une mme fonctionnalit mtier (par
exemple, la commande d'un nouveau chquier) pourra prendre diffrentes
formes de prsentation selon qu'elle se droule sur Internet, sur un distributeur
automatique de billets ou sur l'cran d'un charg de clientle en agence.
La couche prsentation relie les requtes de l'utilisateur destination de la
couche mtier, et en retour lui prsente les informations renvoyes par les
traitements de cette couche. Il s'agit donc ici d'un assemblage de services
mtiers et applicatifs offerts par la couche infrieure.
1.3 Couche Application
Elle consiste en la partie grant l'accs aux gisements de donnes du systme.
Ces donnes peuvent tre propres au systme, ou gres par un autre systme.
La couche mtier n'a pas s'adapter ces deux cas, ils sont transparents pour
elle, et elle accde aux donnes de manire uniforme (couplage faible).
2.Conception des schmas logiques des donnes
Passage du modle de classes au modle relationnel
Transformation des classes
Chaque classe devient une relation en choisissant un attribut de la classe
pouvant jouer le rle de cl primaire.
Dans la figure ci-dessous ,la classe GarageExterne se transforme en une
relation ayant comme cl primaire RaiSocial.
Garage Externe (RaiSocial,AdrGar,TellGar, Specialit)

76

Transformation des associations
- Association 1, 1..* ou 1, 0..*
Il faut ajouter un attribut de type cl trangre dans la relation fils de
lassociation. Lattribut porte le nom de la cl primaire de la relation pre de
lassociation comme lindique lexemple ci-dessous .
Les classes Vhicule et VisiteTechnique se transforment en relations ayant
comme cls primaires successives ImmatVh et ReffVisit .
La cl primaire de la relation VisiteTechnique devient une cl trangre
dans la relation Vhicule

Vhicule (ImmatVh,Marque,Idex,UnitFrais ,UnitTechnique,DatMeM)
Visite Technique (ReffVisit,DatVisit,LieuVisit,#ImmatVh)

Figure 33: Transformation dune classe
Figure 34: Transformation dune association 1, 1..* ou 1, 0..*

77
- Association 1, 0..1
Il faut ajouter un attribut de type cl trangre dans la relation drive de la
classe attache la patte dont la multiplicit minimale est gale 0. lattribut
porte le nom de la cl primaire de la relation drive de la classe connecte
lassociation.
Dans cet exemple, les classes Vhicule et Reforme se transforment en deux
relations ayant comme cls primaires respectivement ImmatVh et
NumReforme . Comme la multiplicit minimale est celle de la classe
Reforme, la relation reforme aura comme cl trangre ImmatVh

Vhicule (ImmatVh,Marque,Idex,UnitFrais ,UnitTechnique,DatMeM)
Reforme(NumReforme,Intitul,
Description, Etat,DatAcquisition,ValeurAcqui,
DureeAmotiss, #Immatvh)
Transformation des classes dassociation
La classe dassociation devient une relation.
Figure 35: Transformation dune association 1, 0..1

78
La cl primaire de cette relation est la concatnation des cls des relations
issues des classes connectes lassociation. Chaque attribut devient une cl
trangre si la classe dont il provient devient une relation.
Les attributs de la classe dassociation doivent tre ajouts la nouvelle
relation. Ces attributs ne sont ni cls primaires ni cls trangres.

Dans cette exemple , la classe dassociation se transforme en relation ayant
comme cls primaires la concatnation des deux cls primaires des relations
Article et Point De Vente.
Pice de rechange (#ReffPices, Libell, PrixUnit, QtStock, SeuilMin)
Devis (#NumDevis, Datdevis, Delai, TVA, Remise)
Ligne Devis (#ReffPices,#Numdevis, NumligneDevis,QtPieces,Mht)
Transformation dune gnralisation
Dans Notre cas, on va appliquer la 3
me
rgle de la gnralisation \
spcialisation:
La rgle dit quil faut supprimer la ou les relations issues de la ou des sous-
classes et faire migrer les attributs dans la relation issue de la classe gnral.
On adopter a cette mthode car on a une contrainte de chevauchement dans
la relation.
Figure 36: Transformation dune classe association

79

Rparation (NumRep, NumBPI, DelaiPrevi, DatEntree, DatSortie, DelaiReel,
EtatRep, MatAgentCedant, MatAgentReceptionnaire, MatInterveneur,
MatAgentEsseyeur, NomAgentEsseyeur)
Modle logique
En appliquant toutes les rgles de transformations prcdentes nous aurons le
modle logique suivant :
1. Marque (codMrq, libell).
2. Devis (NumDevis, Datdevis, Delai, TVA, Remise, #CodFrss).
3. Fournir - Marque (#CodMrq, #CodFrss).
4. Famille Pices (CodFall, Libell).
5. Fournir - Famille (#CodFall, #CodFrss).
6. Lignedevis (#ReffPices, #Numdevis, NumligneDevis, QtPieces, Mht).
7.Commande (NumCom, DatCom, MontantCom, QtCom).
8. LigneCommande (#ReffPices, #NumCom, NumligneCom, QtPieces,
Mht).
9. Fournisseur (CodFrss, NomFrss, PrnomFrss, AdrFrss, NumTell, FaxFrss,
ville).
Figure 37: Transformation dun hritage

80
10. Bon de Livraison (NumBL, DatBL, QtPices).
11. LigneBon de Livraison (#ReffPices, #NumBL, NumligneLiv,
QtPices).
12. Bon de Retour (NumBon, DatBon, QtRetourn).
13. Ligne Retour (#ReffPices, #NumBon, NumligneRet, QteRetour).
14. Pice de rechange (ReffPices, Libell, PrixUnit, QtStock, SeuilMin,
#CodMrq, #CodFall).
15. Avoir Entretien (ReffPices, #NumEtre).
16. Avoir Rparation (ReffPices, #NumRep).
17.Type Entretien (CodType, Libell).
18. Type Rparation (CodType, Libell).
19. Avoir Type Rparation (#CodType, #NumRep).
20. Avoir Type Entretien (#CodType, #NumEtre).
21. Entretien (NumEtre, DatEtre, Index, ProchainIndex, DelaiFiltre,
#NumRep).
22. Rparation (NumRep, NumBPI, DelaiPrevi, DatEntree, DatSortie,
DelaiReel, EtatRep, MatAgentCedant, MatAgentReceptionnaire,
MatInterveneur, MatAgentEsseyeur, NomAgentEsseyeur).
23.Vhicule (ImmatVh, Marque, Idex,UnitFrais , UnitTechnique,
DatMeM, #CodCatgorie).
24. Catgorie (#CodCatgorie, Libell).
25. Essaie (#NumRep, #ImmatVh , DateEssaie, IndexDeb, IndexFin).
26.Unit (CodUnite, LibellUnite,AdrUnite ,#CodDist).
27. Accident (RefAcc,DatAcc,lieuAcc,#immatVh).
28. Avoir Accident (RefAcc, #NumRep).
29.Reforme (NumReforme, Intitul, Description, Etat, Lieu,
DatAcquisition,ValeurAcqui, DureeAmotiss, #Immatvh).
30.Visite Technique (ReffVisit, DatVisit,LieuVisit, #ImmatVh).

81
31. Equipement (CodEquip, libell, #Immatvh, #CodType).
32.TypeEquipement (CodType, dsignation).
31. Devis Rparation (NumDevis, DatDevis, Montant, #NumRep,
#Raisocial).
33.GarageExterne ( RaiSocial, AdrGar, TellGar, Specialit).
34. Facture Rparation (NumFact, DatFact, MontantRep, #NumRep,
RaiSocial).

CONCLUSION

Dans ce chapitre, on a dfinit dune part larchitecture du systme en
presentant les trois couches : metier, presentation et application ainsi que leurs
conceptions.
Dautre part, on sest intress la conception du shma logique des donnes.

CHAPITRE 5 :
IMPLEMENTATION
GESTION DU PARC VEHICULE IMPLEMENTATION

82
CHAPITRE 5 : IMPLEMENTATION
Introduction
Ce chapitre correspond la phase dimplmentation qui consiste la
ralisation de lapplication en prsentant les squelettes des codes, quelques
interfaces, les grilles dcran ainsi que les grilles dimprimantes.
1. Environnement de ralisation
Lapplication gestion du parc vhicule a t dvelopp sous le systme de
ralisation de base de donnes MySQL . Cette section contient les deux
points suivants :
- Matriels et logiciels de base
- Outils de dveloppement
1.1. Matriels et logiciels de base
La programmation du logiciel est ralise sur un micro ordinateur ayant les
caractristiques suivantes :
Marque : HP ;
Processeur : Intel Core 2 duo CPU ;
Frquence de lhorloge : 980 MHZ ;
RAM : 2 GO ;
Disque dur : 160 GO ;
Mmoire cache : 1 GO ;
Imprimante : Canon IP800 ;
Systme dexploitation : Windows XP ;
Navigateur web : internet explorer7

83
1.2. Outils de dveloppement
Les principaux outils qui ont contribus la qualit du dveloppement du
logiciel sont :
UML (UNIFIED MODELING LANGUAGE) : est un standard pour
lanalyse et conception orientes objet. UML se dfinit comme un
langage de modlisation graphique et textuel destin comprendre et
dcrire des besoins, spcifier et documenter des systmes, esquisser des
architectures logicielles concevoir des solutions et communiquer des
points de vue.
Html : Le Langage HTML est un ensemble de balises et d'attributs cest
un langage universel utilis pour communiquer sur le Web.
JavaScript : est un langage de programmation de scripts principalement
utilis pour les pages web interactives. C'est une extension du langage
HTML qui est incluse dans le code. Ce langage est un langage de
programmation qui permet d'apporter des amliorations au langage
HTML en permettant d'excuter des commandes. Ce code est
directement crit dans la page HTML, c'est un langage peu volu qui ne
permet aucune confidentialit au niveau des codes (ceux-ci sont
effectivement visibles). Un langage Orient Objet de type script
permettant d'enrichir les possibilits de HTML par des fonctions de
contrle dynamique du navigateur ou de programmation vnementielle.
Le code JavaScript s'intgre directement dans le fichier HTML et apporte
ainsi l'interactivit qu'il manque ce langage de formatage.
PHP (Outil dAGL): est un langage de scripts libre principalement utilis
pour produire des pages Web dynamiques via un serveur HTTP et il est
excut du ct serveur, mais pouvant galement fonctionner comme
n'importe quel langage interprt de faon locale, en excutant les

84
programmes en ligne de commande. PHP est un langage impratif
disposant depuis la version 5 de fonctionnalits de modle objet
compltes. En raison de la richesse de sa bibliothque, on dsigne parfois
PHP comme une plate-forme plus qu'un simple langage.
MySQL : Cest un SGBD relationnel utilisant le langage de requte SQL.
Avec MySQL, on peut crer plusieurs bases de donnes sur un serveur.
Rational Rose : Atelier de Gnie Logiciels (AGL) qui facilite la
modlisation des diagrammes des applications selon la mthodologie
UML ;
Ajax : Asynchronous Javascript And Xml (AJAX) : il dsigne un
nouveau type de conception de pages Web permettant l'actualisation de
certaines donnes d'une page sans procder au rechargement total de
cette page. Cette mthode de conception repose sur la combinaison de
technologies dj existantes : HTML/CSS, JavaScript/DOM, XML et les
requtes HTTP, avec une demande ralise au serveur, en version
dynamique.
Macromedia Dreamweaver CS3 : Dreamweaver est un diteur de site
Web de type WYSIWYG ("What You See Is What You Get", ce que
vous voyez est ce que vous obtenez).
Dreamweaver offre deux modes de conception par son menu daffichage.
L'utilisateur peut choisir entre un mode de cration permettant d'effectuer
la mise en page directement l'aide d'outils simples, comparables un
logiciel de traitement de texte (insertion de tableau, d'image, etc.). Il
est galement possible d'afficher et d'diter directement le code HTML,
JavaScript ou autre qui compose la page. Il peut passer trs facilement
d'un mode d'affichage l'autre ou opter pour un affichage mixte. Cette
dernire option est particulirement intressante car elle nous permet de
se familiariser facilement avec le langage HTML. En outre, cette

85
flexibilit de linterface nous encourage dopter pour Dreamweaver afin
dinstaurer les interfaces graphiques de notre systme.
WORD 2007 : Outils de traitement de texte ;
POWERPOINT 2007 : Outils daide la ralisation des exposs.
2. Dploiement du systme informatis
Il sagit dun diagramme qui montre la disposition physique des differents
matriels qui entrent dans la composition dun systme et la rpartition des
programmes excutables sur ces matriels.
La figure suivante reprsente le diagramme de dploiement de cette
application :

Figure 38: Diagramme de dploiement

PC CLIENT

SERVEUR
WEB STEG

SERVEUR
SGBD
Connexion

86
3. Ralisation du systme informatis
3.1. Production des squelettes de code
On va se limit a prsent une seule squelettes complte dune seule interface
qui contient les fonctions ajout, modification et suppression. Cette squelettes
contient aussi dautre fonctionalits
Squelette de la fiche fournisseur
<script>
function check(){
if(courant>=0&&courant<vec.length){
document.getElementById('verif').value="1";
}
else
document.getElementById('verif').value="0";
}
function affiche(x){
if(x=="0"){
document.getElementById('mat').style.visibility='hidden';
document.getElementById('code').style.visibility='hidden';
}
if(x=="1"){
document.getElementById('mat').style.visibility='visible';
document.getElementById('mat').readOnly=true;
document.getElementById('code').style.visibility='visible';
}
}
</script>
<?php
require("connexion.php");
if(isset($_GET['add']))
{
$r="insert into fournisseur(codfss,desfss,adrfss,numtel,faxfss,ville)
values(NULL,'".$_GET['nom']."','".$_GET['adr']."',".$_GET['tel'].",".$_GET['fax'].",'".$_G
ET['ville']."')";
if($_GET['verif']==1)
$r="update fournisseur set
desfss='".$_GET['nom']."',adrfss='".$_GET['adr']."',numtel=".$_GET['tel'].",faxfss=".$_G
ET['fax'].",ville='".$_GET['ville']."' where codfss=".$_GET['mat'];
$res=mysql_query($r) or die("ajout impossible");
}

87
if(isset($_GET['delete'])){
$r="delete from fournisseur where codfss =".$_GET['mat'];
$res=mysql_query($r) or die("Suppression impossible");
}
?>
<fieldset><legend><span class="title">Fiche fournisseur</span></legend>
<div class="left">
<form name="four" >
<input type=hidden id=verif name=verif>
<table width="100%">
<tr>
<td><span class="box1" id=code>Code Fournisseur</span><input type=hidden
value="four" name=action id=action> </td>
<td><input type="text" id=mat readOnly name=mat class="input" /></td>
<td><span class="box">Désigantion</span> </td>
<td><input id=nom name=nom class="input"></td>
</tr>
<tr>
<td><span class="box">N° Telephone</span> </td>
<td><input id=tel name=tel class="input"></td>
<td><span class="box">Fax</span></td>
<td><input type="text" name="fax" id=fax class="input" /></td>
</tr>
<tr>
<td><span class="box">Adresse</span> </td>
<td><textarea name="adr" id=adr class="textarea"></textarea>
</td>
<td><span class="box">Ville</span></td>
<td><input type="text" name="ville" id=ville class="input" /></td>
</tr>
<tr valign="bottom">
<td height="50" colspan="2"><table>
<tr>
<td class="menu" style="border: 0;">
<input type=button value=Nouveau id=new onClick="affiche('0');courant=-
1;vider(four);nom.focus();" class=Bouton name=new>&nbsp&nbsp&nbsp&nbsp
</td>
<input type=submit value=Enregistrer class=Bouton name=add onClick="return
verifier('four');" >&nbsp&nbsp&nbsp&nbsp
</td>
<input type=submit value=Supprimer class=Bouton name=delete
>&nbsp&nbsp&nbsp&nbsp

88
</td>
<input type=button value=Annuler class=Bouton name=raise
onClick="document.getElementById('mat').readOnly=false;vider(four)">
</td>
</tr>
</table></td>
<td colspan="2">
<a href=#><img title='premire page' src='images/premier.ico'
onClick="affiche('1');courant=0;move('four');";></a>&nbsp&nbsp<a href=#><img
title='page pr&ecaute;cedente' src='images/precedent.ico'
onClick="affiche('1');(courant>0)?courant--:courant=0;move('four')"></a>&nbsp&nbsp<a
href=#><img src='images/suivant.ico' title='page suivante'
onClick="affiche('1');(courant!=vec.length-
1&&courant>=0)?courant++:courant=vec.length-1;move('four');"></a>&nbsp&nbsp<a
href=#><img title='dernire page' onClick="affiche('1');courant=vec.length-
1;move('four');" src='images/dernier.ico'></a>
</td>
</tr>
</table>
</form>
</div>
</fieldset>
<br />
<br />
<fieldset><legend><span class="title">listes des fournisseurs</span></legend>
<div id=data>
<table width="100%">
<tr bgcolor="#b0e0e6">
<td id="colmat"><font size=4 color=blue>Code</font></td>
<td ><font size=4 color=blue id=marque1>Désignation</font></td>
<td ><font size=4 color=blue>Téléphone</font></td>
<td ><font size=4 color=blue>Fax</font></td>
<td ><font size=4 color=blue>Ville</font></td>
<td ><font size=4 color=blue>Actions</font></td>
</tr>
<?php
$req="select * from fournisseur order by codfss desc";
if($res=mysql_query($req)){
if(mysql_num_rows($res)!=0){
$i=0;
$bool=0;
$nb=mysql_num_rows($res);
echo "<script>vec=new Array($nb);</script>";

89
while($l=mysql_fetch_assoc($res)){
if($i==0)
$_SESSION['first']=$l["codfss"];
echo "<script>
vec[$i]=new
fournisseur(".$l["codfss"].",'".$l["desfss"]."','".$l["adrfss"]."',".$l["numtel"].",".$l["faxfss"].
",'".$l["ville"]."');</script>";
if($i==0)
echo
"<script>affecterfournisseur(".$l["codfss"].",'".$l["desfss"]."','".$l["adrfss"]."',".$l["numtel"
].",".$l["faxfss"].",'".$l["ville"]."');</script>";
if($i<5){
if($bool==0)
echo "<tr style=\"background-color: 'white';\"
onMouseOver=\"colorcourant=this.style.backgroundColor;this.style.background=
'#98fb98'\" onMouseOut=\"this.style.background= colorcourant;\"><td class=menu
style='text-align:center'><a href=#
onClick=\"localiser(".$l["codfss"].");affecterfournisseur(".$l["codfss"].",'".$l["desfss"]."','"
.$l["adrfss"]."',".$l["numtel"].",".$l["faxfss"].",'".$l["ville"]."');affiche('1');\">".$l["codfss"]
."</a></td><td class=menu >".$l["desfss"]."</td><td
class=menu>".$l["numtel"]."</td><td class=menu>".$l["faxfss"]."</td><td
class=menu>".$l["ville"]."</td><td><a style=\"color:#dc143c\" onClick=\"return
confirm('Voulez vous vraiment supprimer cet enregistrement?')\"
href=\"INDEX.php?action=four&delete=go&mat=".$l["codfss"]."\"><img
src=\"images\delete.png\" border=0 ></a></td></tr>";
if($bool==1)
echo "<tr style=\"background-color: silver;\"
onMouseOver=\"colorcourant=this.style.backgroundColor;this.style.background=
'#98fb98'\" onMouseOut=\"this.style.background= colorcourant;\"><td class=menu
style='text-align:center'><a href=#
onClick=\"localiser(".$l["codfss"].");affecterfournisseur(".$l["codfss"].",'".$l["desfss"]."','"
.$l["adrfss"]."',".$l["numtel"].",".$l["faxfss"].",'".$l["ville"]."');affiche('1')\">".$l["codfss"].
"</a></td><td class=menu >".$l["desfss"]."</td><td class=menu>".$l["numtel"]."</td><td
class=menu>".$l["faxfss"]."</td><td class=menu>".$l["ville"]."</td><td><a
style=\"color:#dc143c\" onClick=\"return confirm('Voulez vous vraiment supprimer cet
enregistrement?')\" href=\"INDEX.php?delete=go&mat=".$l["codfss"]."\"><img
src=\"images\delete.png\" border=0 ></a></td></tr>";
}
if($i+1==5)
$_SESSION['last']=$l["codfss"];
$i++;
if($bool==0)
$bool=1;
else

90
$bool=0;
}
}
}
?>
</table>
<br>
<a href=#><img title='premire page' src='images/premier.ico'
onClick=go('premier','four')></a>&nbsp&nbsp<a href=#><img title='page
pr&ecaute;cedente' src='images/precedent.ico'
onClick=go('precedent','four')></a>&nbsp&nbsp<a href=#><img src='images/suivant.ico'
title='page suivante' onClick=go('suivant','four')></a>&nbsp&nbsp<a href=#><img
title='dernire page' onClick="go('dernier','four')" src='images/dernier.ico'></a>
</div>
</fieldset>

3.2. Prsentation des grilles dcran
Grille dcran pour lcran fiche vhicule
Ce formulaire est utilis pour lajout, la modification et la suppression dun
vhicule tout en vrifiant les champs obligatoires.

Figure 39: Grille dcran pour lcran fiche vhicule


91
Grille dcran pour lcran fiche rparation
Ce formulaire est utilis pour lajout, la modification et la suppression dune
rparation dun vhicule toute en choisisant les pices ncessaires a cette
reparation.

Grille dcran pour lcran consultationrparation
Ce formulaire est utilis pour faciliter la recherche et la manipulation des
rparations dans une priode bien dterminer ainsi laffichage des dtail de
chacune delles lorsque on a besoin.

Figure 40: Grille dcran pour lcran fiche rparation


92

Grille dcran pour lcran consultation commande
Ce formulaire est utilis pour afficher les commandes dj enregistres et les
lignes de commande de chacun delles.

Figure 41: Grille dcran pour lcran consultationrparation

Figure 42: Grille dcran pour lcran consultation commande


93
Grille dcran pour lcran fiche fournisseur
fournisseur tout en vrifiant les champs obligatoires.

Grille dcran pour lcran fiche fournisseur
visite technique tout en vrifiant les champs obligatoires.
Figure 43: Grille dcran pour lcran fiche fournisseur


94

Conclusion
Limplmentation est une phase qui couronne le travail ralis dans les phases
prcdentes. Dans ce chapitre on a labor le diagramme de dploiement ainsi
que la ralisation du systme informatis par la prsentation des grilles
dcran et des grilles dimprimantes.
Figure 44: Grille dcran pour lcran fiche fournisseur

CONCLUSION
GESTION DU PARC VEHICULE CONCLUSION

95
CONCLUSION GENERALE

ans ce mmoire, nous avons essay de prsenter une tude
approfondie base sur un nouvel axe de rflexion qui cest impos
rcemment, lorient objet.
En effet, les travaux de conception et danalyse raliss lors de cette tude ont
bnfici de nombreux concepts nouveaux grce ladoption du langage
UML qui reprsente un standard des notations graphiques et des vocabulaires
utiliss pour lanalyse et la conception oriente objet des systmes
dinformation. Ce langage offre une modlisation et une conception oriente
objet qui permet daboutir une meilleure comprhension des besoins, une
conception plus propre et des systmes plus faciles maintenir.
Notre dmarche nous a permis, dans un premier temps, de faire la
connaissance de plusieurs concepts de base concernant la fonction entretien et
rparation du parc vhicule. Dans un second temps, de faire connaissance des
concepts de base des outils utiliss pour le dveloppement dun logiciel,
notamment ceux du langage UML pour la modlisation, MYSQL comme un
systme de gestion de base de donnes avec le langage de programmation
PHP5, pour la ralisation ; la partie restante du mmoire, est consacre
lexploitation des outils dvelopps et la proposition dune application web
qui permet de rsoudre les problmes rencontrs avec lancien programme
pour la gestion du parc vhicule .
Notre tude t base sur divers articles et ouvrages, et sur un effort rel de
notre part, qui sest manifest par la comprhension et lapplication dune
dmarche propre un langage de modlisation (UML).
Ce mmoire nous a donn loccasion de connatre les diffrents niveaux de
difficults rencontrer au niveau de la gestion dun dpartement spcifique
D
GESTION DU PARC VEHICULE CONCLUSION

96
dune entreprise savoir la gestion du parc vhicule, et de proposer des
solutions qui nous a paru plus souples la rsolution des tches du
dpartement prcit en se basant sur linformatisation.
Nous esprons, en fin, que nous avons t au niveau de la tche qui nous a t
affect et que nous avons fait bnficier la socit STEG de nos ides et nos
propositions.

BIBLIOGRAPHIE

BIBLIOGRAPHIE

Ouvrage
- [UML2 MAW/2007] : UML 2 Modliser une application web. Pascal
ROQUES, Eyrolls (3
me
dition) 05/04/2007.
- [UML2 pour les bases de donnes / 2007] : UML 2 Pour les bases de
donnes. Christian SOUTOU, Eyrolls (1
re
dition) 15/03/2007.
- [PHP4 Le guide complet / 2008] : PHP 4 Le guide complet. Franois-
Xavier BOIS, Micro Application (2
me
dition) 05/01/08.
Supports de cours

Site web
www.developpez.com
www.codes-sources.com
www.commmenta marche.com

Najib

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Najib

Transféré par

Droits d'auteur :

Formats disponibles

Universit de Sfax

Ecole Nationale dIngnieurs de Sfax

Vous aimerez peut-être aussi