najib

Universit de Sfax Ecole Nationale dIngnieurs de Sfax Dpartement dinformatique et de mathmatiques-appliques

En vue de lobtention du

MEMOIRE

Mastre ProfessionnelEn Technologie dInformation et Commerce ElectroniqueOption WEB

GESTION DU PARC VEHICULE DE LA STEGCANDIDAT Nejib HABIB ENSEIGNANT ENCADREUR Monsieur Nizar ELLEUCH

Soutenu le ../../2011, Devant la commission dexamen :Pr. Mr. Nizar ELLEUCH Dr. Prsident Encadreur Examinateur

Anne Universitaire 2010- 2011

DdicacesA 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

REMERCIEMENTSNous 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 NizarNous 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 proposCette 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.

SOMMAIREINTRODUCTION 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 L APPLICATION -------------------------------------------------------------------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 D APPROVISIONNEMENT DES PIECES DE RECHANGES ----------------------- 11 2.5 GESTION DES VEHICULES --------------------------------------------------------------------------- 12 3. DIAGRAMME DE CAS D UTILISATION 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 D UTILISATION ------------------------------------------------- 23 4.1. DIAGRAMME DES CAS D UTILISATION ------------------------------------------------------------ 23 4.2. DESCRIPTION TEXTUELLE DES CAS D UTILISATION ------------------------------------------ 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 D INTERACTION ----------------------------------------- 63 2.2. CONSTRUCTION DES DIAGRAMMES DETATS --------------------------------------------------- 70 CONCLUSION ------------------------------------------------------------------------------------------------- 71 CHAPITRE 4 : CONCEPTION ------------------------------------------------------------------ 72 INTRODUCTION ---------------------------------------------------------------------------------------------- 72 1. DEFINITION DE L ARCHITECTURE 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 : D IAGRAMME DE G ANTT 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 figuresFIGURE 1 : ORGANIGRAMME DE LA SOCIETE TUNISIENNE DE LECTRICITE 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



D

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



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 ralisation de notre systme informatis. limplmentation et la

2

CHAPITRE 1 : MODELISATION DU METIER


MODELISATION DU METIER

CHAPITRE1 : MODELISATION DU METIER

IntroductionDans 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 missionDans 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 socitIl 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%,3



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

Direction gnrale Prsident directeur gnral Directeur gnrale adjoint Direction des tudes et de planification Direction de lquipement Direction des affaires gnrales Direction informatique Direction conseill en management Conseil Centre essais et mesures S.P.C.M DP de la coopration et de la communication Direction audit Direction des affaires administratives et juridiques Directions des affaires financires Direction de contrle

Direction organisation et systme dinformation

Direction de la production et du transport dlectricit

Direction Gaz

Units rgionales production et transport dlectricit

Units rgionales des distributions

Units rgionales de la production et du transport de gaz

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

4



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 lapplicationIl 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,5



Gestion des accidents, Gestion des visites techniques, Gestion des fournisseurs.

1.3 Objectifs atteindreLautomatisation 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,

6



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 prvisionnelAfin 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 Phase dEtude thorique Phase de conception Phase de Ralisation Novembre Dcembre Fvrier Mars Avril Mai Juin

Tableau 1 : Diagramme de Gantt de ralisation de notre application

7



2. Reprage et diagnostic du domaineDans 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 :8



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.

9



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.

10



Critique de lexistant 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.

11



Critique de lexistant 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 . Critique de lexistant 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 mtierLe 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,12



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

: garage externe

6,7 8,9 10,11 : s ervice financier et com ptable

ges tion parc vhicule

12 1,2 3,4,5 13,14

: fournis s eur

: ATTT(l'Agence Technique des Trans ports Terres tres )

Figure 2 : Diagramme de contexte du systme mtier

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,

13



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

fourniseur gestion pieces de rechanges service comptable et financier

gestion accident

garage externe gestion intervention

ATTT(Agence Technique des transports terrestres)

visite technique

reparation

entretien

Figure 3 : Diagramme de cas dutilisation mtier

14



4. Description des processus mtierProcessus Gestion des interventions Type mtier Evnement dclencheurs - Vhicule en panne - Kilomtrage atteint - Visite technique Activits -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.

15



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 - Vente des vhicules (reforme) ltat des vhicules.16

Ordre de prise Pilotage de dcision

- Ltablissement dun rapport technique.

- Rapport technique sur - Envoie de ce rapport au chef rgional de



distribution. - Rception dun ordre de dcision. Gestion des accidents mtier Vhicule accidents - Etablir un rapport technique. - Envoie du vhicule pour la rparation.Tableau 2 : Tableau de description des processus mtier

5. Dfinition des orientationsLa 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 gestionLes 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.17



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 dorganisationLes 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 techniquesLes 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.18



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.

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

19

CHAPITRE 2 : CAPTURE DES BESOINS

GESTION DU PARC VEHICULECHAPITRE 2 : Capture des besoins

CAPTURE DES BESOINS

IntroductionDans 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 conceptionUML (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 informatisUn 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.

20


CAPTURE DES BESOINS

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 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. des tats mensielle et les rapports techniques et

21


CAPTURE DES BESOINS

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

: chef de parc

1,2,3 4,5,6

7,8 9,10

: utilisateurs vhicules

gestion parc vhicule

14,15 16,17

11,12 13

: directeur regional

: responsable d'achat

Figure 4 : Diagramme de contexte du systme informatis

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

22


CAPTURE DES BESOINS

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 dutilisation4.1. Diagramme des cas dutilisationLe 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.

23


CAPTURE DES BESOINS

gerer entretien chef de parc gerer reparation

gerer reforme

reparation interne reparation externe

authentification

directeur regional

gerer accident

gerer visite technique

Figure 5: Diagramme cas dutilisation relatif la gestion des interventions

24


CAPTURE DES BESOINS

gerer devis responsable d'achat

gerer commande

authentification

gerer retour pieces

gerer facture d'avoire

gerer bon de retour

chef de parc

gerer fournissuer

Figure 6: Diagramme cas dutilisation relatif la gestion des pices de rechanges

utilis ateur vhicule

gerer vhicule

authentification

directeur regional

Figure 7: Diagramme cas dutilisation relatif la gestion des vhicules

25


CAPTURE DES BESOINS

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.

26


CAPTURE DES BESOINS

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.

27


CAPTURE DES BESOINS

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. Pr condition : Le chef du parc doit sauthentifier. 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 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 dune nouvelle rparation. Le chef du parc saisie les informations concernant la nouvelle rparation. 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 marque le vhicule respectivement en rparation .

28


CAPTURE DES BESOINS

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 Acteur : chef du parc. Objectif : ce cas dutilisation est utilis pour grer et suivre les entretiens. Pr condition : Le chef du parc doit sauthentifier. 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 processus se poursuit selon les tapes suivantes : a. Saisir dinformation Le systme propose lutilisateur laction quil va raliser. Le chef du parc demande lajout dun nouvel entretien. Le chef du parc saisie les informations concernant le nouveau entretien.

29


CAPTURE DES BESOINS

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 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. Scnarios alternatifs : 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.

30


CAPTURE DES BESOINS

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. Scnarios alternatifs : 1. Modifier une commande - Le responsable achat peut modifier les donnes dune commande.

31


CAPTURE DES BESOINS

-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, ). - Le responsable dachat saisit les critres de recherche. - Le systme affiche la commande relative aux critres saisis, sinon le systme excute exception1. 3. Supprimer une commande. - Le responsable dachat peut supprimer une commande. -Le systme propose au responsable dachat 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 systme dsactive la commande aprs validation. Exception : 1 : Le systme affiche le message : Commande inexistante.32


CAPTURE DES BESOINS

Cas dutilisation grer fournisseur Acteur : Chef du parc. Objectif : Ce cas dutilisation est utilis pour grer les fournisseurs. Pr condition : Le chef du parc doit sauthentifier. 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 : a. Saisie des informations Le systme propose lutilisateur laction quil va raliser. Le chef du parc demande lajout dun nouveau fournisseur. Le chef du parc saisie les informations concernant ce nouveau fournisseur. b. Validation de lajout Le chef du parc 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 code de ce fournisseur. Sil le trouve, alors il doit excuter Exception 2. Le scnario se termine lorsque le systme enregistre lajout dun nouveau fournisseur.33


CAPTURE DES BESOINS

A tout moment le chef du parc peut annuler la saisie dun fournisseur. Scnarios alternatifs : 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. Pr condition : Le chef du parc doit sauthentifier. 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 : a. Saisie des informations Le systme propose lutilisateur laction quil va raliser. Le chef du parc demande lajout dun nouveau vhicule. Le chef du parc saisie les informations concernant ce nouveau vhicule.34


CAPTURE DES BESOINS

b. Validation de lajout Le chef du parc 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 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. Scnarios alternatifs : 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 Acteur : chef du parc. 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.

35


CAPTURE DES BESOINS

Le systme vrifie que le chef est autoris manipuler les visites 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 dune visite. 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 scnario se termine lorsque le systme enregistre lajout. A tout moment le chef peut annuler la saisie de la visite. Scnarios alternatifs : 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 participantesIl sagit de diagrammes de classes UML qui dcrit pour chaque cas dutilisation, les principales classes mtier ncessaires et les relations entre elles.36


CAPTURE DES BESOINS

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.

Figure 8 : Diagramme des classes participantes au cas dutilisation grer authentification

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 :

37


CAPTURE DES BESOINS

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

Figure 9: Diagramme des classes participantes au cas dutilisation grer devis

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 :

38


CAPTURE DES BESOINS

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

Figure 10 : Diagramme des classes participantes au cas dutilisation grer commandes

Cas dutilisation retour pices rechanges

Les classes participantes dans ce cas dutilisation : - Fournisseur - Commande - Ligne commande39


CAPTURE DES BESOINS

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

Figure 11 : Diagramme des classes participantes au cas dutilisation retour pices rechanges

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 participantes dans ce cas dutilisation sont :

40


CAPTURE DES BESOINS

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

41


CAPTURE DES BESOINS

Figure 12 : Diagramme des classes participantes au cas dutilisation rparation

42


CAPTURE DES BESOINS

Cas dutilisation grer entretien

Ce cas dutilisation concerne lentretien des vhicules. Les classes participantes dans ce cas dutilisation sont : - Entretien - Type entretien - Vhicule - Pice de rechange - Marque - Famille pices

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

43


CAPTURE DES BESOINS

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

44


CAPTURE DES BESOINS

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

Figure 15 : Diagramme des classes participantes au cas dutilisation grer 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 16 : Diagramme des classes participantes au cas dutilisation grer reforme

45


CAPTURE DES BESOINS

Cas dutilisation grer vhicule

Ce cas dutilisation concerne la gestion des vhicules. Les classes participantes dans ce cas dutilisation sont : - Vhicule - Catgorie - Unit - District

Figure 17 : Diagramme des classes participantes au cas dutilisation grer vhicule

Cas dutilisation grer fournisseur

Ce cas dutilisation concerne la gestion des fournisseurs. Les classes participantes dans ce cas dutilisation sont : - Fournisseur - Famille pices - Marque

46


CAPTURE DES BESOINS

Figure 18 : Diagramme des classes participantes au cas dutilisation grer fournisseurs

5. Dfinition des prioritsNous avons opt pour une classification selon le degr dimportance des cas dutilisation : Priorit 1 2 3 4 5 6 7 8 Cas dutilisation Grer authentification Grer vhicule Grer entretien Grer rparation Grer visite technique Grer accident Grer fournisseur Grer commande Acteurs Tous les acteurs du systme informatis Chef du parc Chef du parc Chef du parc Chef du parc Chef du parc et directeur rgional Responsable dachat Responsable dachat

Tableau 3 : Tableaux des priorits

47


CAPTURE DES BESOINS

6. dcoupage en package Package approvisionnement

Figure 19: Package approvisionnement

48


CAPTURE DES BESOINS

Package interventions

Figure 20 : Package intervention

49


CAPTURE DES BESOINS

Package vhicules

Figure 21 : Package vhicules

50


CAPTURE DES BESOINS

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

51

CHAPITRE 3 : ANALYSE

GESTION DU PARC VEHICULECHAPITRE 3 : ANALYSE

ANALYSE

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

1. Dveloppement du modle statique1.1. Construction du diagramme de classes1.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.

52


ANALYSE

1.1.2. Dictionnaire de donnes Le tableau qui suit prsente le dictionnaire de donnes : Nom de la classe Attributs RefAcc Accident DateAcc LieuAcc CodeUnite Unit LibellUnite AdrUnite CodeType Type entretien Libell CodeType Type rparation Libell CodeEquip Type quipement Libell NumLigneRet QtRetour NumBL Bon de livraison DatBL QtPices Description Rfrence dun accident. Date dun accident. Lieu dun accident. Code dune unit. Libell dune unit. Adresse dune unit. Code dun entretien. Libell dun entretien. Code type dune rparation. Libell dune rparation. Code type dun quipement. Dsignation dun quipement. Numro dune ligne de retour. Quantit dune ligne de retour. Numro dun bon de livraison. Date dun bon de livraison. Quantit des pices de rechanges dune livraison. NumBon Numro dun bon de retour.

53


ANALYSE

Bon de retour

datBon QteRetourn

Date dun bon de retour. Quantit retourn des pices de rechanges.

NumligneCom

Numro dune ligne commande.

QtPices

Quantit dune ligne commande.

Mht

Montant hors taxe dune ligne commande.

ReffVisit Visite Technique

Rfrence dune visite technique.

DatVisit LieuVisit NumCom DatCom MontantCom

Date dune visite technique. Lieu dune visite technique. Numro dune commande. Date dune commande. Montant dune commande. Quantit des pices dune commande.

Commande

QtCom

CodDist libellDist District NbUnit AdrDist ReffPices Pice de rechange libell54

Code dun district. Libell dun district. Nombre dunit dun district. Adresse dun district. Rfrence dune pice. Libell dune pice.


ANALYSE

PrixUnit QtStock SeuilMin ImmatVh

Prix unitaire dune pice. Quantit en stock dune pice. Seuil minimal dune pice. Numro de matricule dun vhicule.

Marque Vhicule Index UniteFrais UniteTechnique DatMEM

Marque dun vhicule. Index dun vhicule. Unit frais dun vhicule. Unit technique dun vhicule. date de mise en marche dun vhicule.

NumReforme Intutile description

Numro dun reforme. Inutile de reforme. Description dun vhicule reform.

Reforme

ValeurAcqui

Valeur dacquisition dun vhicule.

DureeAmortiss

Dure damortissement dun vhicule.

Etat DatAquisition

Etat dun vhicule reform. Date dacquisition dun vhicule.

RaiSocial Garage Externe AdrGar55

Raison social du garage. Adresse dun garage.


ANALYSE

Spcialit TellGar

Spcialit dun garage. Numro de tlphone dun garage.

NumEtre DatEtre

Numro dun entretien. Date dun entretien dun vhicule.

Entretien

Index Prochain index

Index actuel de vhicule. Prochain index dun entretien dun vhicule.

DelaiFiltre

Dlai de changement des filtres dun vhicule.

NumRep DelaiPrevi

Numro dune rparation. Dlai prvision dune rparation.

Rparation

DateEntree DateSorti Delaireel EtatRep NumBPI MatAgentCedant

Date dbut dune intervention. Date fin dune intervention. Dlai rel dune intervention. Etat dune rparation. Numro dun bon de Prestation interne Matricule de lagent cdant Code dune catgorie.

Catgorie

CodCatgorie

56


ANALYSE

Libell Cat

Libell dune catgorie.

NumFact Facture DatFact MontantRep DateEssaie Essaie IndexDeb IndexFin Famille pices CodFall Libell

Numro dune facture. Date dune facture. Montant de rparation. Date dun essai Index dbut dun vhicule. Index fin dun vhicule. Code dune famille des pices. Libell dune famille des pices.

Fournisseur

CodFrss NomFrss PrenomFrss AdrFrss FaxFrss Ville NumTel

Code dun fournisseur. Nom dun fournisseur. Prnom dun fournisseur. Adresse dun fournisseur. Fax dun fournisseur. Ville dun fournisseur. Numro de tlphone dun fournisseur.

CodMrq

Code dune marque des pices de rechanges.

57


ANALYSE

Marque

libell

Libell dune marque des pices de rechanges.

NumDevis Dlai Devis TVA Remise DatDevis Ligne Devis NumligneDevis QtePices Mht Rparation Interne

Numro dun devis fournisseur Dlai dun devis. Taxes sur la valeur ajoute Remise. Date dun devis. Numro dun devis. Quantit des pices dun devis. Montant dun devis.

MatAgentReception Matricule Agent naire MatInterveneur MatAgentEsseyeur rceptionnaire. Matricule dun intervenant. Matricule dun agent Essayeur.

Rparation Externe

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

58


ANALYSE

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

Tableau 4: Dictionnaire de donnes

59


ANALYSE

1.1.3. Reprsentation des diagrammes de classe

Figure 22: Diagramme de classes

60


ANALYSE

1.2. Construction des diagrammes dobjetsUn 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.

61


ANALYSE

Figure 23 : Diagramme dobjets

62


ANALYSE

2. Dveloppement du modle dynamique2.1. Construction des diagrammes dinteractionUn 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.

: Chef de Parc

: Ecran:Authentification

: Controleur:Authentification

Tous:Utilisateur s

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

Figure 24: Diagramme de squence Authentification

63


ANALYSE

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

tous:vhicules : chef de parc : Ecranvhicule : ControleurVhicule

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)

nouveau:vhicule

Figure 25: Diagramme de squence ajouter vhicule

Diagramme de squence supprimer vhicule : Le chef de parc selectionne le vhicule quil dsire supprimer . Le diagramme de squence suivant illustre le suivi dvnement pour le scnario Supprimer vhicule .

64


ANALYSE

tous:vhicule : chef de parc : Ecranvhicule 1supprim erVhicule(IMMAT) 2:supprimer voiture(IMMat) 3:Exis t:=chercchrVhicule(IMMAT) 4:[Exist==null]affiche("vhicule n'exis te pas") : ControleurVhicule : controlReparation

tous:reparation

vhicule

5:res:=chercherReparation 6:res:=chercher reparation [resnull] "la vhicule est en reparation en ne peut pas supprim er" [res==null]"destory"

Figure 26: Diagramme de squence supprimer vhicule

Diagramme de squence ajout commande : Le responsable dachat introduit les informations ncessaires pour crer une nouvelle commande. Le diagramme de squence suivant illustre le suivi dvnement pour le scnario ajout commande .

65


ANALYSE

: Responsable d'achat Ajouter Commande(Numro,DAte)

: Ecran:Commande

: Controleur:Commande : Tous:Commandes

Ajouter Commande(Numro,Date) C=chercherCommande(Numro)

: Tous:fournisseurs : tous:pices

[Cnull] Afficher("Commande existante impossible d'ajouter ") : Nouveau:Commande Chercher Fournisseur(Nom) 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)

Figure 27: Diagramme de squence ajouter commande

Diagramme de squence supprimer commande : Le responsable dachat selectionne la commande qui va supprimer. Le diagramme de squence suivant illustre le suivi dvnement pour le scnario supprimer commande .

66


ANALYSE

: Responsable : Ecran:Commande d'achat 1:lister Commande(Numro)

: Controleur:Commande

Tous:Command e

2:lister Commande(Numro) A=chercher Commande(Numro) :commande

Selectionner Commande

Supprimer Commande(Numro) Supprimer Commande(Numro) :lignes Commande

Supprimer Commande() Supprimer Lignes() supprimer() Afficher "commande supprimer avec succs"

Figure 28: Diagramme de squence supprimer commande

Diagramme de squence ajout accident : Le chef de parc introduit les informations ncessaires pour crer un nouvel accident. Le diagramme de squence suivant illustre le suivi dvnement pour le scnario ajout accident .

67


ANALYSE

: Chef de Parc

: ecran Accident : controleur Accident

tous:vhicule

1:Ajout Accident(IMMAT,lieu,date) 2:Ajout Accident(IMMAT,lieu,date) 3:A=ChercherVhicule(IMMAT)

4:[Anull]Afficher("vhiculedja accident...

nouveau:vhicule Accident 5:[A=nul]CreAccident(IMMAT,lieu,Date)

Figure 29: Diagramme de squence ajout accident

Diagramme de squence ajout reparation : Le chef de parc introduit les informations ncessaires pour crer une nouvelle reparation. Le diagramme de squence suivant illustre le suivi dvnement pour le scnario ajout reparation.

68


ANALYSE

: chef de parc

: Ecran:reparation

: rparation : :Intervention

1:ajout Reparation(IMMAT,date Entre,date Sortie...) 2:ajout Reparation(IMMAT,date Entre,date Sortie...) tous:reparation

3:R=Chercher Reparation(IMMAT) 4:[Rnull]Afficher(vhicule existe dja)

nouveau:vhicul e rpar

[R=null]Cre Reparation(IMMAT,Date Ente,Date Sortie) : Nouvelle:intervention Lister Intervention() Lister Intervention() Slectionner Intervention() [A=null] Affichier(" intervention inxistante") : Tous:Intervention

Cre Intervention() Slectionner Pices()

Ajouter (Pices,dsignation,Quantit) affichier(" Commande ajouter avec succs")

Figure 30: Diagramme de squence rparation

69


ANALYSE

2.2. Construction des diagrammes dtatsUn 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:

vendre

non disponible

en panne cre disponible panne rendre [non rpar] reparation terminer en cas de reparation ou d'entretien entretien terminer accident en entretein reparer accident quand(kilom atteint) envoyer

vendre

Figure 31: Diagramme dtat-transition dun vhicule

70


ANALYSE

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

71

CHAPITRE 4 : CONCEPTION

GESTION DU PARC VEHICULECHAPITRE 4 : CONCEPTION

CONCEPTION

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

72


CONCEPTION

Figure 32: Architecture trois niveaux

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


CONCEPTION

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 / BusinessElle 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 PrsentationElle 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.74


CONCEPTION

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 ApplicationElle 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)75


CONCEPTION

Figure 33: Transformation dune classe

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

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

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

76


CONCEPTION

- 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

Figure 35: Transformation dune association 1, 0..1

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.

77


CONCEPTION

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.

Figure 36: Transformation dune classe association

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

78


CONCEPTION

Figure 37: Transformation dun hritage

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

79


CONCEPTION

10. Bon de Livraison (NumBL, DatBL, QtPices). 11. LigneBon QtPices). de Livraison (#ReffPices, #NumBL, NumligneLiv,

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, DatAcquisition,ValeurAcqui, DureeAmotiss, #Immatvh). 30.Visite Technique (ReffVisit, DatVisit,LieuVisit, #ImmatVh). Lieu,

80


CONCEPTION

31. Equipement (CodEquip, libell, #Immatvh, #CodType). 32.TypeEquipement (CodType, dsignation). 31. Devis Rparation #Raisocial). (NumDevis, DatDevis, Montant, #NumRep,

33.GarageExterne ( RaiSocial, AdrGar, TellGar, Specialit). 34. Facture Rparation (NumFact, DatFact, MontantRep, #NumRep, RaiSocial).

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

81

CHAPITRE 5 : IMPLEMENTATION

GESTION DU PARC VEHICULECHAPITRE 5 : IMPLEMENTATION

IMPLEMENTATION

IntroductionCe chapitre correspond la phase dimplmentat

najib

Documents

Transcript of najib