95271774-najib

Universit de Sfax Ecole Nationale dIngnieurs de Sfax

Dpartement dinformatique et de mathmatiques-appliques

MMEEMMOOIIRREE En vue de lobtention du

MMaassttrree PPrrooffeessssiioonnnneell

En Technologie dInformation et Commerce Electronique

Option WEB

GGEESSTTIIOONN DDUU PPAARRCC VVEEHHIICCUULLEE

DDEE LLAA SSTTEEGG

CCAANNDDIIDDAATT Nejib HABIB

EENNSSEEIIGGNNAANNTT EENNCCAADDRREEUURR 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,910,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

authentification

directeur regionalgerer accident


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

gerer retour pieces

gerer commande

responsable d'achat

gerer fournissuer

utilisateur vhicule

directeur regional

gerer vhicule authentification


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 : MenuEcran 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" )

[repnull]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:vhiculestous:vhicules

nouveau:vhiculenouveau:vhicule

1:AjouterVhicule(IMMAT,marque,cathegorie)

2:AjouterVhicule(IMMAT,marque,cathegorie)

3:E:=chercherVhicule(IMMAT)

4:[Enull]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:vhiculetous:vhicule : controlReparation : controlReparation

tous:reparationtous:reparation vhiculevhicule

1supprimerVhicule(IMMAT)

2:supprimer voiture(IMMat)

3:Exist:=chercchrVhicule(IMMAT)

4:[Exist==null]affiche("vhicule n'existe pas")

5:res:=chercherReparation

[resnull] "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 selection

Documents

95271774-najib