Rapport de Stage - Finali

Gestion de parc roulant 2012-2013
Remerciement
Nous venons remercier en premier lieu, notre encadreur Madame BESBES Salsabil pour
l’intérêt qu’elle a bien voulu porter à notre travail et pour son aide précieuse.
Nous tenons à présenter nos remerciements également à Madame NAIIRI Ibtissem notre
encadreur au STT pour m'avoir accueilli, veillé au bon déroulement de notre stage, et les
efforts qu'elle a fournis pour la réussite de ce projet.
Nous voudrons adresser nos grands remerciements à tous ceux et celles qui ont contribués de
près ou de loin, à la réalisation de ce travail.
Et finalement, nos chères familles pour leurs soutient et encouragement.

Introduction générale
Actuellement reconnu que toutes les entreprises, cherchent à développer leurs

environnements technologiques quelque soit leurs domaines d’activité en terme de logiciels
de gestion, que ce soit pour gérer le personnel de la société ou leurs activités. Afin de
faciliter l’intégration au sein de leurs environnements en donnant un espace à la créativité,
l’innovation, l’échange et l’enrichissement des compétences. La gestion de parc roulant vise
à améliorer la qualité de service et surtout l’information voyageur en utilisant les nouvelles
technologies de communication.
Dans ce contexte, notre projet de fin d’étude réalisé au sein de la Société de Transport de
Tunis consiste à développer une application web pour la gestion de son parc roulant.
Nous commençons notre rapport par une introduction et problématique de notre projet qui suit
par étude de l'existant, il s'agit de décrire le processus actuel de gestion de parc roulant. Puis,
nous enchainons par une analyse des différents besoins du système suivie par une
spécification détaillée de ses fonctionnalités.
Ensuite, nous présentons dans un troisième chapitre la conception en se basant sur la
méthodologie UML pour décrire les aspects statiques et dynamiques de notre système.
Le dernier chapitre est consacré à la phase de l'implémentation. Nous allons définir
l'environnement du travail et les outils utilisés suivi d'une présentation de quelques interfaces
de l'application. Nous terminons enfin ce rapport par une conclusion générale.
Table des matières

Remerciement
Introduction générale
Chapitre 1 Introduction et problématique.............................................................................................1
I.1 Cadre de projet..................................................................................................................................1
I.1.1 Historique..................................................................................................................................1
I.1.2 Répartition géographique...........................................................................................................1
I.1.3 Activité de la STT........................................................................................................................2
I.1.3.1 La direction « maintenance bus ».....................................................................................2
I.1.3.2 La direction « informatique ».............................................................................................3
I.2 Problématique...................................................................................................................................4
I.3 Contributions.....................................................................................................................................4
Chapitre 2 Etude de l’existent et spécification des besoins....................................................................6
II .1 Processus de gestion de parc roulant existant..................................................................................6
II.1.1 Modalités de l’application existante.........................................................................................6
II.2 Spécification des besoins.................................................................................................................8
II.2.1 Besoins fonctionnels.................................................................................................................9
II.2.1.1 Gestion des procès verbaux..............................................................................................9
II.2.1.2 Gestion des véhicules........................................................................................................10
II.2.1.3 Gestion de l’état d’un véhicule......................................................................................10
II.2.1.3 Gestion d’une visite technique......................................................................................11
II. 2.2 Besoins non fonctionnels........................................................................................................11
II. 2.2.1 Contraintes techniques...................................................................................................12
II. 2.2.2 Contraintes ergonomiques.............................................................................................12
II.2.3 Les cas d’utilisation.................................................................................................................12
II.2.3.1 Diagrammes de cas d’utilisation général........................................................................13
II.2.3.2 Raffinement du diagramme de cas d’utilisation général.................................................14
Chapitre III Conception.........................................................................................................................21
III.1 Outil de conception : Rational Rose 7.0.0.....................................................................................21
III.2 Vue statique.................................................................................................................................21
III.2.1 Diagrammes de classes..........................................................................................................21
III.2.2 Description.............................................................................................................................23
III.3 Vue dynamique.............................................................................................................................24
Chapitre IV Implémentation.................................................................................................................37
IV.1 Environnements et outils de travail..............................................................................................37
IV.1.1 Plateforme matérielle............................................................................................................37
IV.1.2 Plateforme logicielle...............................................................................................................37
IV.2.3 Langages et technologies de développement........................................................................38
IV.2.3.1 WampServer....................................................................................................................38
IV.2.3.2 PHP5................................................................................................................................38
IV.2.3.3 Adobe Dreamweaver 9.0...............................................................................................38
IV.2 Présentation des interfaces utilisateurs........................................................................................39
IV.2.1 Interface Authentification......................................................................................................39
IV.2.2 Interface Changer mot de passe............................................................................................39
IV.2.3 Interface ajout bus................................................................................................................40
IV.2.4 Interface modification bus.....................................................................................................42
IV.2.5 Interface ajout procès verbal.................................................................................................43
IV.2.6 Interface ajout bon................................................................................................................44
IV.2.7 Interface ajouter visite technique..........................................................................................45
Conclusion générale
Référence
Table des figures

Figure 1.1: Répartition géographique du parc roulant.......................................................................2
Figure 2.1: Page d’accueil de l’application existante..........................................................................7
Figure 2.3 : Interface d’ajout d’un véhicule........................................................................................8
Figure 2.4: Diagramme de cas d’utilisation général.........................................................................13
Figure 2.5: Raffinement de cas d’utilisation « s’authentifier ».........................................................14
Figure 2.6: Raffinement de cas d’utilisation « gérer les véhicules ».................................................15
Figure 2.7 : Raffinement de cas d’utilisation « gérer un bon ».........................................................16
Figure 2.8 : Raffinemeent de cas d’utilisation « Gérer un procès verbal »......................................18
Figure 2.9 : Raffinemeent de cas d’utilisation « Gérer une visite technique ».................................19
Figure 3.1: Diagramme de classe......................................................................................................22
Figure 3.2: Diagramme de séquence « s’authentifier »....................................................................24
Figure 3.3: Diagramme de séquence « ajout d’un procès verbal »..................................................25
Figure 3.4: Diagramme de séquence « modifier un procès verbal »................................................26
Figure 3.5: Diagramme de séquence « recherche d’un procès verbal ».........................................27
Figure 3.6: Diagramme de séquence « ajout d’un véhicule »..........................................................28
Figure 3.7: Diagramme de séquence « modifier un véhicule »........................................................29
Figure 3.7: Diagramme de séquence « rechercher un véhicule »....................................................30
Figure 3.7: Diagramme de séquence « ajouter un bon ».................................................................31
Figure 3.10: Diagramme de séquence « modifier un bon »..............................................................32
Figure 3.7: Diagramme de séquence « rechercher un bon »...........................................................33
Figure 3.12: Diagramme de séquence « ajouter une visite technique »...........................................34
Figure 3.13: Diagramme de séquence « modifier une visite technique ».........................................35
Figure 3.14: Diagramme de séquence « rechercher une visite technique ».....................................36
Figure 4.1 : Interface « authentification »........................................................................................39
Figure 4.2: Interface « Changer mot de passe »...............................................................................40
Figure 4.3 : Interface « ajouter bus »................................................................................................41
Figure 4. 4: Erreur d’ajout d’un bus..................................................................................................42
Figure 4.5: Interface « modifier bus »..............................................................................................43
Figure 4.6: Interface « ajouter procès verbal »................................................................................44
Figure 4.7 : Interface « ajouter bon »...............................................................................................45
Figure 4.8 : Interface « ajouter visite technique »............................................................................46
Chapitre 1
Introduction et problématique
Introduction
Dans ce chapitre, nous commençons par présenter l’organisme d’accueil dans lequel
ce projet a été mené et dont dépende, en grande partie, son activité principale.
Ensuite, nous définissons la problématique de notre sujet intitulé « Gestion de parc roulant».
Finalement, nous proposons les solutions appropriées pour résoudre cette problématique.
I.1 Cadre de projet
Ce sujet se situe dans le cadre du développement d’un système d’information capable de

gérer le parc roulant de la société de transport de Tunis (STT) dans laquelle notre stage s’est
déroulé.
I.1.1 Historique
La Société des Transports de Tunis dont la dénomination commerciale est Transtu, est une
entreprise publique chargée de la gestion du transport des passagers sur les réseaux d'autobus
et de métro léger de l’agglomération de Tunis ainsi que l'exploitation de la ligne ferroviaire
TGM.
Née en 2003 de la fusion entre la Société Nationale des Transports(SNT) et la Société du

Métro Léger de Tunis (SMLT), elle transporte chaque année 460 million de passagers.
I.1.2 Répartition géographique
Afin d’améliorer les outils d’exploitation et minimiser les coûts, le parc des autobus et
ses moyens humains conséquents ont été affectés à quatre districts, repartis en cinq
zones géographiques : district Banlieu Ouest, district Ben Arous, district Tunis 1, district
Tunis 2.La figure 1.1 présente ces diférentes zones.
District District Ben

District Tunis1 District Tinis2
Banlieue Ouest Arous
Dépôt Bâb Dépôt Dépôt Bir Dépôt Dépôt Dépôt

Sâadoun Zahrouni Charguia B Tebourba
El kasaa Charguia A
Figure 1.1: Répartition géographique du parc roulant
I.1.3 Activité de la STT
La société de Transport de Tunis est une entreprise publique chargée de la gestion du

transport des passagers sur les réseaux d'autobus et de métro léger. Elle se compose de deux
directions : direction « maintenance bus» et la direction « informatique ».
I.1.3.1 La direction « maintenance bus »
La direction « maintenance bus » se compose de deux principaux services : service « étude

et méthode » et service « gestion de parc véhicules et entretien des voitures légères ».
 Service étude et méthode

Les fonctionnalités de ce service sont :
 Elaborer et suivre les études techniques en matière de maintenance,
 Réformer, rénover, et choisir le matériel roulant et les équipements.
 Elaborer des gammes de réparation en fonction de l’évolution technologique et
l’apparition de nouvelles méthodes.
 Assurer la réception, le lancement des travaux, et le contrôle final de la
production.
 Recevoir et contrôler les organes (composants) livrés par les différents clients internes et
externes.
 Tenir un compte analytique pour les véhicules reçus.
 Assurer la réception technique du parc roulant.
 Assurer la gestion des magasins relais des organes.
 Service gestion de parc et entretien voitures légères
Les fonctionnalités de ce service sont :
 Assurer la gestion des documents administratifs des véhicules de la société.

 Tenir les fiches techniques des véhicules.
 Suivre le taux de disponibilité des véhicules.
 Assurer le suivi des visites du contrôle technique périodique.
 Assurer l’entretien du parc des voitures légères.
 Assumer la coordination avec les ateliers centraux ou les sous traitants pour la
maintenance des voitures.
 Veiller à l’établissement de fiches de suivi technique des voitures.
 Assurer la coordination avec le service gestion de parc véhicules et entretien voitures
légères en matière d’utilisation du parc.
 Elaborer le rapport d’activité du service.
I.1.3.2 La direction « informatique »
Le département informatique de la société des transports de Tunis veille à développer un

système d’information en utilisant des outils de traitement de l’information et tout en
optimisant son temps de réponse. En plus, il veille au développement, la mise en place et la
mise à jour du manuel des procédures de l’entreprise.
Le département est composé de deux directions. La première s’appelle Direction

informatique. Elle supervise le développement des logiciels et les outils de traitement de
l’information avec la qualité et la sécurité requises en matière de logiciels et de données. La
seconde direction est la direction organisation. Cette dernière assure le développement du
système d’information. Elle se compose de deux services :
 Service Etudes Informatiques : Le service étude est chargé de la conception et de

l’automatisation des nouvelles procédures de gestion.
 Service Centre de calcul : Ce service est chargé de l’exploitation et du suivi des

logiciels développés par le service étude.
I.2 Problématique
La gestion de parc roulant au sein de STT présente une activité délicate. Il s’agit de gérer
les véhicules, les procès verbaux, les bons et les visites techniques.
La gestion des véhicules est effectuée par le chef service gestion de parc véhicules et entretien
voitures légères. Ce dernier peut ajouter, modifier ou rechercher un véhicule existant dans la
base de données. Selon l’état de véhicule (vendu, loué, cédé, en reforme, immobilisé en
instance de reforme ou détaché), il lui affecte le bon adéquat. Cette tâche est réalisée
manuellement.
Le chef service étude et méthode s’occupe de la gestion des procès verbaux. A chaque fois, il
doit établir une demande de fixation de la date de visite au fournisseur avant production par
fax ou par téléphone. Après cette visite, il élabore un procès verbal de visite avant production,
un procès verbal de réception provisoire, un procès verbal de levée des réserves s’ils existent
et finalement un procès verbal de livraison.
Chaque véhicule possède un rapport de visite technique qui contient un numéro de rapport, le
numéro de véhicule concerné et la date de la visite technique. Ce processus est réalisé par le
chef service entretien.
Toutefois, la gestion de parc roulant représente une source d'erreurs pour plusieurs raisons. En
effet, étant donné que le processus n'est pas automatisé, les chefs service sont chargés
d'effectuer la plupart des traitements de façon manuelle. Cela engendre une mauvaise
manœuvre de la part du collaborateur (oubli, redondance, confusion de noms, erreur de
saisie...) aboutissant à des flux correctifs avec le fournisseur et même avec les employés de la
STT, et donc une perte de temps ainsi que une mal organisation des données.
Pour remédier à ces problèmes, nous proposons les solutions informatiques, qui permettront
de résoudre ces différentes difficultés rencontrées, lors du processus de gestion de parc
roulant.
I.3 Contributions
Le processus de gestion de parc roulant non informatisé présente plusieurs lacunes et

nécessite par conséquent une mise en œuvre d’un système qui prend en charge la réalisation
de cette tâche tout en garantissant son automatisation, sa consistance et son efficacité.
Concevoir un tel système est l’objet de notre mission.
Dans un premier lieu, nous avons créé une base de données, afin de centraliser, structurer et
contrôler toutes les données relevant à la gestion de parc roulant.
Dans un deuxième lieu, nous avons développée une application web qui a pour but de
répondre aux besoins nécessaires en automatisation et en contrôle : notre système devra
assurer le contrôle automatique et la vérification continue de la saisie des données lors de
l'ajout, de la modification, de la recherche et de la consultation d’un véhicule.
Etant donné que la génération des procès verbaux et des visites techniques est manuelle et
pour satisfaire à la contrainte de temps, nous avons créé un module permettant d’automatiser
cette tâche et par conséquent d’améliorer la productivité du personnel en l’aidant à faire une
synthèse concernant les gains et les pertes d’argent et d’orchestrer les processus dont il est
chargé.
Conclusion
Durant ce chapitre nous avons présenté le cadre général de notre projet. Nous avons
introduit l’entreprise d’accueil et ses fonctionnalités. Par la suite, nous avons présenté la
problématique de notre sujet et les solutions que nous avons proposées. Dans le chapitre
suivant, nous allons présenter le processus existant et illustrer les fonctionnalités de notre
futur application.
Chapitre 2
Etude de l’existent et spécification
des besoins
Introduction
Dans ce chapitre, nous allons commencer par une description du processus actuel de
gestion de parc roulant au sein du STT, afin de faciliter la phase de conception et
d'implémentation de notre système. Ensuite nous nous intéresserons à illustrer les
fonctionnalités de notre futur application, en nous basant sur le diagramme des cas
d'utilisation d'UML [1] accompagné par sa description textuelle.
II .1 Processus de gestion de parc roulant existant
II.1.1 Modalités de l’application existante
Développer son application devient un atout pour la Société de Transport de Tunis.

C’est pour cela, elle nous a demandé d’améliorer son application intranet de gestion de parc
roulant des bus qui permet de gérer les bus dès l’acquisition jusqu’à sa mise en non
utilisation. Cette application, était réalisée en COBOL [1] sur le réseau AS400.
COBOL est un langage de programmation de troisième génération crée en 1959. Le réseau
AS400 (Application System) est une architecture composée d’éléments matériels et
logiciels comportant notamment une base de données et des éléments de sécurité avancés.
Cette architecture est une structure sous forme des couches séparant ces éléments.
L’application de Gestion de Parc n’est pas bien structurée et présente plusieurs
inconvénients. D’une part, chaque révision ou suivi d’un bus doit être sauvegardée. D’autre
part, le parc possède un seul acteur qui accède à l’application. Les autres utilisateurs
travaillent manuellement pour échanger les documents entre eux par Fax, téléphone ou
papiers ce qui engendre un gaspillage en temps et en matériel. En plus, l’application n’est pas
totalement sécurisée. On ajoute à ceci qu’il y’a un excès et redondance des données dans le
menu de l’application actuelle avec une difficulté de consulter les documents.
La figure 2.2 décrit les principaux menus de l’application existante.
Figure 2.1: Page d’accueil de l’application existante
Le responsable accède a l’application pour gère les véhicule par un ajout ou une
modification, ainsi il gère la liste des visites programmées par mois et saisit la date de la
prochaine visite. La figure 2.3 illustre l’ajout d’un véhicule.
Figure 2.3 : Interface d’ajout d’un véhicule
L’ajout d’un véhicule s’effectue en remplissant les différents champs présents dans la
figure 2.3. Chaque bus est identifié par son numéro d’immatriculation.
Pour modifier les informations relatives à un véhicule, le responsable doit saisir l’identifiant
du bus puis il réalise les modifications nécessaires.
L’employé responsable édite la liste des véhicules programmés ayant une visite technique
pour chaque jour du mois suivant et envoie à chaque district la liste des véhicules concernés.
II.2 Spécification des besoins
Dans la section précédente, nous avons décrit le processus de gestion de parc roulant
existant. Ceci nous a permis d’identifier l’existant et de cerner ce qui peut être automatisable.
Dans ce qui suit, nous allons présenter les besoins fonctionnels de notre système, illustrés à
l’aide du paradigme des cas d’utilisation donnant une vue externe sur les fonctionnalités
offertes par le système développé, ainsi que les besoins non fonctionnels.
II.2.1 Besoins fonctionnels
Ce sont les processus utiles pour le service de gestion de parc ainsi que les fonctionnalités
que nous voulons réaliser à partir des informations que nous avons collectées auprès de
personnel de la STT.
II.2.1.1 Gestion des procès verbaux
 Gérer le procès verbal de réunion avant production

Une première réunion avec le fournisseur doit être effectuée par le chef service « étude et
méthode » afin de désigner les caractéristiques des véhicules à acheter.
Après cette réunion, un procès verbal de réunion avant production est réalisé. Le
chef « service étude et méthode » d o i t pouvoir créer (ajouter un nouveau procès verbal après
chaque réunion avant production ou modifier les informations de chaque procès) et de
chercher un procès verbal selon son numéro.
 Gérer le procès verbal de réception provisoire

Après la visite de réception provisoire, le chef service « étude et méthode » établit un
procès verbal de réception provisoire en précisant les différents réserves et le délai de
réception. Il a le droit de d’ajouter un nouveau procès verbal après la visite de réception
provisoire ou modifier les informations de chaque procès verbal de réception provisoire et de
chercher un procès verbal selon son numéro.
 Gérer le procès verbal d’enlèvement :

Une deuxième réunion avec le fournisseur sera réalisée pour la vérification d’enlèvement
de réserves. Si les réserves existent encore, un procès verbal de réunion d’avant enlèvement
aura lieu. Si non un procès verbal de levées de réserves sera écrit. Le chef service « étude et
méthode » peut gérer peut gérer les procès verbaux (ajouter un nouveau procès verbal
d’enlèvement si les réserve aura lieu encore ou modifier les informations de chaque procès
verbal de réception provisoire) et de chercher un procès verbal d’enlèvement selon son
numéro.
 Gérer le procès verbal de livraison
Après avoir enlevé les réserves, les véhicules seront livrés et réceptionnés et un procès
verbal de livraison sera mis à disponibilité des responsables concernés. Cette tâche se
termine par un bon de livraison et une acquisition des matériaux roulants. Le chef service
étude et méthode peut créer (ajouter un nouveau procès verbal d’enlèvement après avoir
enlevé les réserves ou modifier les informations de chaque procès verbal de réception
provisoire).
Pour ajouter un procès verbal, le chef service étude et méthode doit compléter les champs
suivantes: numéro de procès verbal d’un véhicule, marque du véhicule, type du véhicule,
numéro châssis du véhicule, date, immatriculation du véhicule et remarque.
II.2.1.2 Gestion des véhicules
Au cours de cette phase, le chef service « gestion de parc véhicules et entretien voitures
légères » détermine tous les attributs concernant le véhicule. A chaque réception d’un
nouveau véhicule, ce chef service l’affecte au dépôt selon les besoins ainsi il a le droit
d’ajouter un bus afin de compléter les champs nécessaires (numéro d’un véhicule,
immatriculation, date de Carte Grise, l’énergie, gabarit, type Châssis, nombre de place
Assises, poids à vide, date mise en circulation, date laissez passer, numéro de châssis, nombre
de place debout, poids à charge, montant d’achat, date visite technique, nombre de
rénovation, matricule utilisateur, code dépôt, code marque, Code fournisseur, code organe,
date), de modifier ses caractères et de chercher un véhicule selon son numéro.
II.2.1.3 Gestion de l’état d’un véhicule
Cette gestion est réalisée par le chef service « gestion de parc véhicules et entretien
voitures légères ».
 Gérer le bon de location
Un véhicule peut être loué à une société dès son achat ou après sa circulation. A la sortie
du véhicule, un bon de location est rempli précisant le type de location, numéro de véhicule et
la durée de location.
 Gérer le bon de vente
Un véhicule peut être vendu suite à une décision de vente. Après chaque décision de vente,
le chef service « gestion de parc véhicules et entretiens voitures légères » remplit un bon de
vente en indiquant l’acheteur et le prix de vente.
 Gérer le bon de cédé
On peut faire un échange des bus entre les différents Districts, en cas où il y a un manque
de véhicules dans l’un des districts de la société. Un véhicule dont l’état est activé peut être
cédé par un autre district ou par le ministère de transport lui-même. A chaque décision d’une
empreinte, le chef service « gestion de parc véhicules et entretiens voitures légères » remplit
un bon de cédé en précisant le numéro et le nom du dépôt de destination du véhicule.
 Gérer le bon d’immobilisation
Pendant sa période de validité, un véhicule peut être exposé à la corruption au niveau
de ses organes. Ce cas ne l’autorise pas à circuler, il est donc nécessaire de faire un
entretien.
Le chef service « entretien » remplit alors un bon d’immobilisation en précisant la cause
d’immobilisation, le numéro d’organe manqué et le numéro d’article de ce véhicule.
 Gérer le bon de détachement
C’est le cas où le véhicule est en mauvais état c'est à dire il ne peut pas déplacer les
passagers ou en cas de circulation il ne peut pas dépasser un nombre de kilométrage précis.
Après chaque décision de détachement, le chef service « gestion de parc véhicules et
entretiens voitures légères » fait la mise à jour de l’état du véhicule. Notons que l’état du
véhicule actuel est en reforme.
 Gérer le bon de reforme
C’est l’étape qui permet de faire passer un véhicule en état de reforme après une longue
période de circulation (qui dépasse 10 ans). Dans cet état, le véhicule ne peut pas être
exploité.
II.2.1.3 Gestion d’une visite technique
La procédure de gestion d’une visite technique comporte les phases suivantes:
 Phase de planification
Il est possible d’obtenir la situation des véhicules immobilisés, suivant les types de
motif d’immobilisation et les véhicules qui sont signalés.
Le chef service « entretien » dispose de la liste des véhicules qui sont programmés pour
subir une visite technique. Il ne sélectionne que les véhicules en bon état pour réaliser la
visite technique.
 Phase de programmation
Le système fournit, à un jour donné, les visites techniques à effectuer par les véhicules.
Le chef service « entretien » précise les véhicules et leurs visites ou autres opérations
différées non effectuées les jours précédents.
II. 2.2 Besoins non fonctionnels

Les besoins non fonctionnels se résument par l’ensemble des contraintes techniques et
ergonomiques ainsi que les contraintes de sécurité.
II. 2.2.1 Contraintes techniques
Portabilité : L’application à réaliser doit pouvoir s’adapter à un nouvel environnement.
Flexibilité : L’application doit être facile à modifier.
Universalité : La transparence de l’application est recommandée. En d’autres termes, les
traitements compliqués doivent être invisibles pour l’utilisateur :
- Assister les utilisateurs par des messages d’erreur durant l’utilisation de l’application.
- Sensibiliser les utilisateurs envers l’outil informatique.
- Former le personnel pour l’utilisation des nouvelles applications.
II. 2.2.2 Contraintes ergonomiques
Les contraintes de qualité: L’application doit être facile à utiliser, elle doit assurer une
interaction facile avec l’utilisateur en présentant, des informations claires et précises, la
rapidité de traitement et la performance et la fiabilité.
Les contraintes esthétiques: Les interfaces doivent être similaires dans toutes les pages de
l’application.
Les contraintes de sécurité: Chaque utilisateur doit s’identifier avant d’accéder à sa propre
interface.
II.2.3 Les cas d’utilisation
Dans cette section, nous avons rédigé une description de la méthodologie UML [2].
En effet UML est un langage de modélisation, il vise par ses différents diagrammes, à
concevoir les besoins et le comportement d’un système. Les cas d’utilisations qui
forment le diagramme fonctionnel d’UML présentent une modélisation des
fonctionnalités du système en tant que tâches effectuées par des utilisateurs externes
appelés acteurs.
Pour notre application, nous distinguons 3 acteurs :
 Le chef service « étude et méthode » : il est chargé de gérer les procès verbaux.
 Le chef service « gestion de parc véhicules et entretiens voiture légères » : il s’occupe
de la gestion des bons (bon de livraison, bon de vente, bon de location, bon de cédé,
bon de détachement, bon de reforme).
 Le chef service « entretien » : il est responsable de la gestion de la fiche de visite

technique.
II.2.3.1 Diagrammes de cas d’utilisation général
Nous allons présenter les différents cas d’utilisation de notre application ainsi que leur
description textuelle. La figure 2.4 présente notre diagramme de cas d’utilisation général.
Figure 2.4: Diagramme de cas d’utilisation général

Dans ce qui suit, nous allons détailler les cas d’utilisation cités dans la figure 2.4.
II.2.3.2 Raffinement du diagramme de cas d’utilisation général
 Raffinement du cas d’utilisation « s’authentifier »
Figure 2.5: Raffinement du cas d’utilisation « s’authentifier »
Description du cas d’utilisation « s’authentifier »

- Acteur: Le chef service étude et méthode.
Le chef service gestion de parc véhicules et entretiens voiture légères.
Le chef service entretien.
- Objectif : s’authentifier pour accéder à l’application.
- Pré-condition: Système ouvert et connexion à la base effectuée.
- Post-condition: utilisateur authentifié.
- Scénario nominal :
1- L’utilisateur se connecte à la page d’accueil et saisit son pseudo et son mot de
passe.
2- Le système vérifie le pseudo et le mot de passe saisis.
3- Le système valide l’authentification.
- Scénario alternatif :
Le système ne reconnait pas le mot de passe ou le pseudo :

0 1- L’utilisateur sera invité à s’identifier de nouveau.
2- Le système retourne à l’étape 1.
 Raffinement du cas d’utilisation « gérer les véhicules »
Figure 2.6: Raffinement du cas d’utilisation « gérer les véhicules »
Description du cas d’utilisation «ajouter véhicule»

- Acteur : chef service « gestion de parc véhicules et entretiens voitures légères ».
- Objectif : Ce cas d’utilisation est utilisé pour permettre l’ajout d’un bus.
- Pré-Condition: le chef service « gestion de parc et entretien voitures légères »
s’authentifie.
- Post-condition : un nouveau bus est ajouté. La table « véhicule » est mise à jour.
- Scénario nominal :
1- Le chef service « gestion de parc véhicules et entretiens voitures légères »
choisit l’option « Ajouter bus ».
2- Il saisit les données nécessaires (Numéro d’un véhicule, Immatriculation d’un
véhicule, Date carte grise d’un véhicule, Energie d’un véhicule, Gabarit d’un
véhicule, Type Châssis d’un véhicule, Nombre de places assises, Poids à vide
d’un véhicule, Date mise en circulation SNT, Date laissez passer d’un
véhicule, Numéro châssis d’un véhicule, Place Debout d’un véhicule, Poids à
charge d’un véhicule, Montant Achat d’un véhicule, Date visite technique d’un
véhicule, Nombre rénovation d’un véhicule, Matricule Utilisateur d’un
véhicule, Code dépôt, Code marque d’un véhicule, Code fournisseur, Code
organe d’un véhicule, Date).
3- Le système vérifie les données saisies.

4- Le système valide l’ajout.
Si le véhicule existe, un message d’erreur s’affiche.
Description du cas d’utilisation « Rechercher véhicule »
- Acteur: chef service gestion du par cet entretien voitures légères.
- Objectif : Ce cas d’utilisation est utilisé pour permettre la recherche de la fiche bus.
-Pré-Condition: le chef service gestion du par cet entretien voitures légères s’authentifie.
-Post-condition: affichage de la page recherche bus.
-Scénario nominal:
1- Le chef service gestion du par cet entretien voitures légères choisit l’option
« Rechercher véhicule ».
2- Le système affiche la liste des bus recherchés et le chef service « gestion de
parc véhicules et entretiens voitures légères » choisit l’opération souhaitée
(modification ou visualisation).
Si le véhicule n’existe pas un message d’erreur s’affiche.
 Raffinement du cas d’utilisation « Gérer un bon »
Figure 2.7 : Raffinement du cas d’utilisation « gérer un bon »
Description du cas d’utilisation « ajouter bon »

- Acteur: chef service « gestion de parc véhicules et entretiens voitures légères ».
- Objectif : Ce cas d’utilisation est utilisé pour permettre l’ajout d’un bon.
- Pré-Condition: le chef service gestion de parc véhicules et entretiens voitures légères

s’authentifie.
- Post-condition: un nouveau bon est ajouté. La table « bon » est mise à jour.
- Scénario nominal:
1- Le chef service gestion de parc véhicules et entretiens voitures légères choisit
l’option « Ajouter bon».
2- Saisit les données nécessaires (Numéro Bon d’un véhicule, Code dépôt, Date,
Numéro d’un véhicule, Matricule utilisateur, Code état d’un véhicule), puis
valider l’ajout.
Si le bon existe déjà un message d’erreur s’affiche.
Description du cas d’utilisation « Rechercher fiche bon »
- Acteur: chef service « gestion de parc véhicules et entretiens voitures légères ».
- Objectif: Ce cas d’utilisation est utilisé pour permettre la recherche d’un bon.
-Pré-Condition: le chef service gestion du par cet entretien voitures légères s’authentifie.
-Post-condition: affichage de la page recherche bon.
-Scénario nominal:
1- Le chef service gestion de parc véhicules et entretiens voitures légères choisit
l’option « Rechercher fiche bon ».
2- Le système affiche la liste des bons recherchés et le chef service gestion de parc
véhicules et entretiens voitures légères choisit l’opération souhaitée
(modification ou consultation)
- Scénario alternatif:
Si le bon n’existe pas un message d’erreur s’affiche.
 Raffinement du cas d’utilisation « Gérer un procès verbal »
Figure 2.8 : Raffinemeent de cas d’utilisation « Gérer un procès verbal »
Description du cas d’utilisation « ajouter procès verbal »

- Acteur: chef service « étude et méthode ».
- Objectif: Ce cas d’utilisation est utilisé pour permettre l’ajout du procès verbal.
- Pré-condition: le chef service « étude et méthode » s’authentifie.
- Post-condition: un nouveau procès verbal est ajouté. La table « procès verbal »est mise à
jour.
1- le chef service étude et méthode choisit l’option « Ajouter procès verbal » de
visite avant production.
2- Il saisit les données nécessaires (Numéro procès verbal, d’un véhicule,
Marque d’un véhicule, Type d’un véhicule, Numéro châssis d’un véhicule,
Date, Immatriculation d’un véhicule, Remarque), valide l’ajout. Si le procès
verbal n’existe pas, il sera ajouté sinon un message d’erreur s’affiche.
Description du cas d’utilisation « Rechercher procès verbal»
- Acteur: chef service « étude et méthode ».
- Objectif : Ce cas d’utilisation est utilisé pour permettre la recherche du procès verbal.
- Pré-Condition: le chef service « étude et méthode » s’authentifie.
- Post-condition: afficher le procès verbal recherché.
- Scénario principal:
1- Le responsable d’étude et méthode choisit l’option « Rechercher procès
verbal ».
2- Le système affiche la liste des procès verbaux recherchés et le responsable

d’étude et méthode choisit l’opération souhaitée « visualiser » ou « Modifier
».
Si le procès verbal n’existe pas, un message d’erreur s’affiche.
 Raffinement du cas d’utilisation « Gérer une visite technique »
Figure 2.9 : Raffinement de cas d’utilisation « Gérer une visite technique »
Description du cas d’utilisation « ajouter visite technique »

- Acteur : chef service « entretien ».
- Objectif : Ce cas d’utilisation est utilisé pour permettre l’ajout de la visite technique.
- Pré-Condition: le chef service entretien s’authentifie.
- Post-condition: une nouvelle visite technique est ajoutée. La table « visite technique» est
mise à jour.
1- Le chef service entretien choisit l’option « Ajouter visite technique ».
2- Saisit les données nécessaires (Numéro fiche visite technique d’un véhicule,
Date prochaine visite technique d’un véhicule, Date Actuel, Numéro véhicule,
Cause, Matricule Utilisateur, valide l’ajout.
3- Le système vérifie les données saisies.
4- Le système valide l’ajout.
Si la visite technique existe, un message d’erreur s’affiche.
Description du cas d’utilisation « Rechercher visite technique »

- Acteur: chef service entretien.
- Objectif: Ce cas d’utilisation est utilisé pour permettre la recherche du visite technique.
- Pré-Condition: le chef service étude et méthode s’authentifie.
- Post-condition: afficher page recherche visite technique.
- Scénario principal:
1- Le chef service entretien choisit l’option « Rechercher visite technique».
3- Le système affiche la liste des visites techniques recherchées et le chef service
entretien choisit l’opération souhaitée « visualiser » ou « Modifier »).
- Scénario alternatif:
Si la visite technique n’existe pas, un message d’erreur s’affiche.
Conclusion
Dans ce chapitre, nous avons décrit le processus de gestion de parc roulant Nous avons
détaillé les besoins fonctionnels en utilisant le diagramme des cas d'utilisation et nous avons
spécifié les besoins non fonctionnels du notre système. Dans la suite, nous allons entamer la
phase de conception en utilisant la méthodologie UML.
Chapitre III
Conception
Introduction
Afin de mieux comprendre le système à développer, une démarche de modélisation
structurée s'impose. Nous avons choisi d'utiliser la méthodologie UML pour décrire les
différents aspects de notre système en définissant le diagramme de classe et les diagrammes
de séquence, ce qui permettra de faciliter et structurer le développement. Cette modélisation
est effectuée à l'aide de l'outil de conception Rational Rose 7.0.0.[3]
III.1 Outil de conception : Rational Rose 7.0.0

Rational Rose est un logiciel édité par la société Rational (racheté par IBM) pour créer et
éditer des diagrammes différents d'UML (Unifed Modeling Language). Il permet à ses
utilisateurs de sauvegarder et imprimer ces diagrammes et de générer de code source vers
différents langages cibles tels que Java ou C++.
III.2 Vue statique

Un élément central de conception d'un logiciel est le diagramme de classes. C'est un
modèle représentant la structure du système à concevoir. Le diagramme de classe est une
représentation statique des éléments qui composent un système et de leurs relations. Il fait
abstraction des aspects dynamiques et temporels.
III.2.1 Diagrammes de classes
Notre système, conçu dans une approche orientée objet, donne naissance au diagramme de
classes illustré par la figure 3.1.
Figure 3.1: Diagramme de classe

III.2.2 Description
Ce diagramme, qui contient les différentes classes décrivant le système à réaliser, permet
de donner une vue orientée objet du système de gestion de parc roulant.
Il se compose principalement des classes suivantes :
 Utilisateur : Représente tout tiers ayant accès à l’application. Elle contient le
chef service « étude et méthode », le chef service « gestion de parc véhicules
et entretiens voitures légères » et le chef service « entretien ».
 chefServiceEtudeMethode,chefServiceGestionParcEtEntretienLegere,
chefServiceEntretien : ces trois classes partagent les mêmes méthodes et
attributs de la classe mère Utilisateur.
 procèsVerbal : cette classe contient les détails d’un procès verbal qui peut
étre ajoutéou modifié.
 pvReunion, pvReunion, pvEnlevement, pvLivraison : ces classes partagent
les mêmes méthodes et attributs de la classe mère procèsVerbal.
 vehicule : c'est une classe qui contient les données du véhicule ainsi que
toutes les méthodes nécessaires à la gestion des véhicules (ajout,
modification)
 organne : cette classe contient les informations de base d’un organe.
 etatVehicule : cette classe contient les détails de l’état d’un véhicule.
 marque : cette classe contient les informations concernant la marque d’un
véhicule.
 fournisseur : cette classe contient les informations du fournisseur.
 depot : cette classe contient le code et le nom du dépôt.
 bon : cette classe contient tous les attributs qui peuvent définir un bon. Les
méthodes de cette classe sont ajouter et modifier. .
 bonLocation, bonVente, bonDetachement, bonImmobilisation, bonReforme
et bonCede : ces six classes partagent les mêmes méthodes et attributs de la
classe mère bon, elles ont aussi des attributs spécifiques pour chacune d'entre
eux.
 ficheVisiteTech : cetteclasse contient tous les attributs qui peuvent définir
une fiche de visite technique
III.3 Vue dynamique

La vue dynamique permet de donner une vision microscopique du fonctionnement du
système. UML offre différents diagrammes permettant de représenter cet aspect
comportemental et temporel des systèmes. Dans notre conception, nous avons eu recours aux
diagrammes de séquence, qui forment une représentation temporelle des objets et de leurs
interactions.
 S’authentifier
Figure 3.2: Diagramme de séquence « s’authentifier »
- Description
Pour accéder à l’application, l’utilisateur « chef service gestion du par cet entretien
voitures légères », « chef service étude et méthode » et « chef service entretien » doivent
s’authentifier.
Afin d’accéder à la page d’accueil, l’utilisateur saisit son login et mot de passe. Le
gestionnaire vérifie au niveau de la base de données la validité des coordonnés saisies, il
autorise l’accès à la page d’accueil si les informations sont correctes, sinon il affiche un
message d’erreur
 Ajouter un procès verbal
Figure 3.3: Diagramme de séquence « ajout d’un procès verbal »
- Description
Le chef service « étude et méthode » est le seul responsable de la gestion d’un procès
verbal. Après qu’il se connecte au système, il peut ajouter un nouveau procès verbal en
remplissant un formulaire contenant les informations nécessaire du procès verbal, le
gestionnaire effectue un contrôle de saisie avant d'ajouter ces informations à la base de
données.
 Modifier un procès verbal
Figure 3.4: Diagramme de séquence « modifier un procès verbal »
- Description
Après la consultation des procès verbaux le chef service « étude et méthode » peut les
modifier.
Afin que le chef service « étude et méthode » accède au formulaire, il doit choisir un procès
verbal à modifier. Le système envoie le formulaire de mise à jour. Si les données sont
correctes, elles seront enregistrées dans la base de données.
 Recherche d’un procès verbal
Figure 3.5: Diagramme de séquence « recherche d’un procès verbal »
- Description
Le chef service « étude et méthode » saisit le numéro de procès verbal à rechercher, le

système vérifie l’existence de celui-ci dans la base de données et affiche les détails du procès
verbal correspondant. Si le procès verbal n’existe pas le système affiche un message d’erreur.
 Ajouter un véhicule
Figure 3.6: Diagramme de séquence « ajout d’un véhicule »
- Description
Lorsque le chef service « véhicules et entretiens voitures légères » veut ajouter un nouveau
véhicule, le gestionnaire lui renvoie le formulaire correspondant, après le remplissage et avant
l'ajout dans la base de données une vérification des champs est nécessaire.
 Modifier un véhicule
Figure 3.7: Diagramme de séquence « modifier un véhicule »
- Description
Pour mettre à jour les informations d'un véhicule, le chef service « gestion de parc
véhicules et entretiens voitures légères » saisit l'identifiant de ce dernier, le gestionnaire donne
la possibilité de modifier les données qui seront ensuite enregistrées dans la base.
 Recherche d’un véhicule
Figure 3.8: Diagramme de séquence « recherche d’un véhicule »
- Description
Le chef service « gestion de parc véhicules et entretiens voitures légères » peut chercher
un véhicule à partir de son numéro. S’il existe le système affiche les données du véhicule, si
ce n’est pas le cas il affiche un message d’erreur.
 Ajouter un bon
Figure 3.9: Diagramme de séquence « ajouter un bon »
- Description
Après qu’il se connecte au système, le chef service « gestion de parc véhicules et entretiens
voitures légères » peut ajouter un nouveau bon, il doit remplir le formulaire, ce dernier sera
vérifié par le gestionnaire avant qu’il l’ajoute à la base de données.
 Modifier un bon
Figure 3.10: Diagramme de séquence « modifier un bon »
- Description
Le chef service « gestion de parc véhicules et entretiens voitures légères » choisit le bon
qu’il veut modifier, le gestionnaire donne la possibilité de modifier les données qui seront
ensuite enregistrées dans la base.
 Rechercher un bon
Figure 3.11: Diagramme de séquence « rechercher un bon »

- Description
Pour rechercher un bon, le chef service « gestion de parc véhicules et entretiens voitures
légères » saisit d'abord son l'identifiant. Le gestionnaire vérifie son existence et affiche les
données correspondantes au bon choisit.
 Ajouter une visite technique
Figure 3.12: Diagramme de séquence « ajouter une visite technique »
- Description
Le chef service « entretien » saisit l'identifiant de la visite technique. Le gestionnaire
vérifie son existence. Puis il envoie le formulaire correspondant et l'enregistre dans la base de
données après son remplissage par le chef service « entretien ».
 Modifier une visite technique
Figure 3.13: Diagramme de séquence « modifier une visite technique »
- Description
Pour modifier une visite technique, le chef service entretien commence par choisir
l’option modifier de cette visite technique. Le système affiche ensuite le formulaire de mise
à jour au chef service entretien. Enfin, il sauvegarde les informations dans la base de
données.
 Rechercher une visite technique
Figure 3.14: Diagramme de séquence « rechercher une visite technique »
- Description
Pour chercher les informations d'une visite technique, le chef service « entretien » saisit
l'identifiant du ce dernier, le gestionnaire vérifie s'il existe afin d’afficher les informations de
la visite technique choisie. Si ce n'est pas le cas c'est à dire que l'identifiant saisi est incorrect,
un message d'erreur est affiché.
Conclusion
Dans ce chapitre nous avons essayé de modéliser notre système, en nous intéressant d’une
part à la vue statique et d’autre part à la vue dynamique à l’aide des diagrammes de classe et
les diagrammes de séquence de la méthodologie UML. Nous finissons ainsi l’étape de
conception élaborée dans ce chapitre et dans laquelle nous avons préparé tout ce qu’il fallait
pour commencer la réalisation qui sera le sujet du chapitre suivant.
Chapitre IV
Implémentation
Introduction
Dans ce chapitre, nous allons décrire la phase d'implémentation de notre système. Nous
allons commencer par un aperçu sur les outils et les langages utilisées afin de réaliser notre
application web de gestion de parc roulant. Par la suite, nous présenterons quelques interfaces
des modules réalisées, afin d'illustrer leurs fonctionnalités principales.
IV.1 Environnements et outils de travail

Dans cette première partie, nous décrivons brièvement l’environnement mis à notre
disposition pour accomplir le projet.
IV.1.1 Plateforme matérielle
Le long de notre projet, nous avons utilisé une machine ayant la configuration suivante :
– Un processeur i3.
– Une mémoire vivre 4 GO.
– Un disque dur de capacité 80 GO.
IV.1.2 Plateforme logicielle
Au cours de la phase de développement, nous nous sommes servies des environnements
logiciels suivants :
– Système d’exploitation : Microsoft Windows 7
– Serveur d’application : WampServer.
–PHP5
– SGBD: MySql 5.0.
IV.2.3 Langages et technologies de développement

IV.2.3.1 WampServer
Le wampServer (anciennement WAMP5) est une plateforme de développement Web de
type WAMP, permettant de faire fonctionner localement (sans se connecter à un serveur
externe) des scripts PHP[4]. WampServer n'est pas en soi un logiciel, mais un environnement
comprenant deux serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi que
phpMyAdmin pour l'administration Web des bases MySQL.
Les fonctions principales de WampServer :
 Détection automatique du répertoire d’installation en fonction des droits de l'utilisateur.

 Détection automatique des ports disponibles.
 Gestion des composants : plusieurs versions de PHP (ou plusieurs fois la même) peuvent
être installées.
 Possibilité de basculer d'une version de PHP à une autre en un clic.
 PHP configuration Manager (max execution time, error reporting, upload max file size...).
 MySQL configuration Manager (storage engine : InnoDB/MyISAM...).
 Apache configuration Manager (timezone, available ports...).
 Alias Manager (ajout/suppression).
IV.2.3.2 PHP5
Le PHP est un langage de scripts (donc interprété) s'exécutant sur un serveur. Cela signifie
qu'il est exécuté par le serveur avant d'apparaitre en tant que document HTML. Il est donc
fondamentalement différent d'un autre langage de script comme le JavaScript, car pour ce
dernier, c'est la machine client (l'ordinateur de l'internaute) qui exécute les instructions
JavaScript. Il s'agit d'une plateforme de développement Web, permettant de faire fonctionner
localement (sans se connecter à un serveur externe) des scripts PHP.
IV.2.3.3 Adobe Dreamweaver 9.0
C’est un outil de développement pour la création des applications Client/Serveur
permettant aux utilisateurs finaux d’accéder aux informations stockées au niveau de la base de
données. En effet grâce aux images écran développées par Dreamweaver[5],
l’administrateur de l’application peut supprimer, insérer, modifier ou consulter des
enregistrements.
C’est un logiciel créé par Macromedia (et géré maintenant par Adobe) permettant la
conception de sites web. Dreamweaver fonctionne en mode WYSIWYG ou en mode code et
dispose d'un client FTP permettant le transfert des pages créées sur le serveur hébergeant le
site web.
IV.2 Présentation des interfaces utilisateurs

Nous présentons dans ce qui suit quelques interfaces fonctionnelles du système.
IV.2.1 Interface Authentification
Lors du lancement du système, l'interface d'authentification s'affiche, l'utilisateur saisit son
identifiant et son mot de passe pour se connecter et pouvoir ensuite utiliser les fonctionnalités
offertes, selon les droits qui lui ont été accordés.
Figure 4.1 : Interface « authentification »
IV.2.2 Interface Changer mot de passe

Après l’authentification, si l’utilisateur souhaite changer son mot de passe il suffit de
choisir l’option désirée à partir de la page d’accueil. Il saisit le nouveau mot de passe et valide
son opération.
Figure 4.2: Interface « Changer mot de passe »
IV.2.3 Interface ajout bus

Après l’authentification, si le gestionnaire du parc souhaite ajouter, modifier, rechercher ou
consulter un bus, une propriété d’Etat, un formulaire d’immatriculation, et un rapport de visite
technique. Il suffit de choisir l’option désirée à partir de sa page d’accueil. Il saisit les
informations nécessaires (numéro bus, marque, genre, énergie, état, etc.) et valide l’opération.
Figure 4.3 : Interface « ajouter bus »
Notre système effectue un contrôle sur les champs avant chaque opération d'ajout, la figure
4.3 montre le message d'erreur lorsque l'utilisateur laisse des champs vides et valide l’ajout.
Figure 4. 4: Erreur d’ajout d’un bus
IV.2.4 Interface modification bus

Le chef service gestion de parc véhicules et entretiens voitures légères peut modifier les
informations d’un bus existant.
Figure 4.5: Interface « modifier bus »
IV.2.5 Interface ajout procès verbal

Cette interface nous offre l'opportunité de saisir les informations concernant un nouveau
procès verbal. Une fois la saisie terminée, l'utilisateur clique sur le bouton « ajouter » pour
enregistrer le nouveau procès verbal dans la base de données.
Figure 4.6: Interface « ajouter procès verbal »
IV.2.6 Interface ajout bon

Lorsque chef service gestion de parc véhicules et entretien voitures légères choisit le sous
menu « ajouter bon » l'interface correspondante s'affiche, il remplit le formulaire d’ajout,
enfin il valide l’opération.
Figure 4.7 : Interface « ajouter bon »
IV.2.7 Interface ajouter visite technique

Cette tache est réalisée par le chef service entretien, il saisit les informations nécessaires
pour une visite technique. Après avoir confirmé ces informations par le système, une nouvelle
visite technique sera ajoutée.
Figure 4.8 : Interface « ajouter visite technique »
Conclusion
Dans ce chapitre, nous avons présenté l'environnement et les outils utilisés pour
l'implémentation.
Nous avons exposé ainsi le résultat de développement à l'aide des aperçus écran avec une
description de chacun.
Conclusion générale
Ce stage de fin d’étude, réalisé à la Société de Transport de Tunis dans le but d’obtenir
le diplôme de licence appliqué en Système Informatique et Logiciels. Lors de ce stage, nous
avons pu mettre en pratique nos connaissances théoriques acquises durant nos formations, de
plus nous nous sommes confrontés aux difficultés réelles du mode du travail et du
management d’équipes.
Nous pensons que cette expérience en entreprise nous a offert une bonne préparation à notre
insertion professionnelle. En effet nous avons implémenté une application web de gestion de
parc roulant de la STT.
Nous espérons bien qu'il soit à la hauteur de la confiance qu’ils nous ont accordé et que nous
avons laissé une bonne impression de l’Institut Supérieur d’Informatique.
Nétrographie
[1] Common Business Oriented Language http://en.wikipedia.org/wiki/COBOL visité le

18/02/2013.
[2] Unified Modeling language http://fr.wikipedia.org/wiki/Unified_Modeling_Language visité le

18/02/2013.
[3] Rational Rose http://fr.wikipedia.org/wiki/Rational_Rose visité le 18/02/2013.
[4] HyperText Preprocessor https://fr.wikipedia.org/wiki/PHP visité le 18/02/2013.
[5] Dreamweaver http://www.adobe.com/products/dreamweaver.html visité le 18/02/2013.


Rapport de Stage - Finali

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage - Finali

Transféré par

Droits d'auteur :

Formats disponibles

Gestion de parc roulant 2012-2013

Et finalement, nos chères familles pour leurs soutient et encouragement.

Actuellement reconnu que toutes les entreprises, cherchent à développer leurs

Table des matières

Table des figures

I.1 Cadre de projet

Ce sujet se situe dans le cadre du développement d’un système d’information capable de

Née en 2003 de la fusion entre la Société Nationale des Transports(SNT) et la Société du

I.1.2 Répartition géographique

District District Ben

Dépôt Bâb Dépôt Dépôt Bir Dépôt Dépôt Dépôt

Figure 1.1: Répartition géographique du parc roulant

I.1.3 Activité de la STT

La société de Transport de Tunis est une entreprise publique chargée de la gestion du

I.1.3.1 La direction « maintenance bus »

La direction « maintenance bus » se compose de deux principaux services : service « étude

 Service étude et méthode

 Assurer la gestion des documents administratifs des véhicules de la société.

Le département informatique de la société des transports de Tunis veille à développer un

Le département est composé de deux directions. La première s’appelle Direction

 Service Etudes Informatiques : Le service étude est chargé de la conception et de

 Service Centre de calcul : Ce service est chargé de l’exploitation et du suivi des

Le processus de gestion de parc roulant non informatisé présente plusieurs lacunes et

II .1 Processus de gestion de parc roulant existant

II.1.1 Modalités de l’application existante

Développer son application devient un atout pour la Société de Transport de Tunis.

Figure 2.1: Page d’accueil de l’application existante

Figure 2.3 : Interface d’ajout d’un véhicule

II.2 Spécification des besoins

 Gérer le procès verbal de réunion avant production

 Gérer le procès verbal de réception provisoire

 Gérer le procès verbal d’enlèvement :

II. 2.2 Besoins non fonctionnels

 Le chef service « entretien » : il est responsable de la gestion de la fiche de visite

Figure 2.4: Diagramme de cas d’utilisation général

Figure 2.5: Raffinement du cas d’utilisation « s’authentifier »

Description du cas d’utilisation « s’authentifier »

Le système ne reconnait pas le mot de passe ou le pseudo :

0 1- L’utilisateur sera invité à s’identifier de nouveau.

2- Le système retourne à l’étape 1.

 Raffinement du cas d’utilisation « gérer les véhicules »

Figure 2.6: Raffinement du cas d’utilisation « gérer les véhicules »

Description du cas d’utilisation «ajouter véhicule»

3- Le système vérifie les données saisies.

Si le véhicule n’existe pas un message d’erreur s’affiche.

 Raffinement du cas d’utilisation « Gérer un bon »

Figure 2.7 : Raffinement du cas d’utilisation « gérer un bon »

Description du cas d’utilisation « ajouter bon »

- Pré-Condition: le chef service gestion de parc véhicules et entretiens voitures légères

 Raffinement du cas d’utilisation « Gérer un procès verbal »

Figure 2.8 : Raffinemeent de cas d’utilisation « Gérer un procès verbal »

Description du cas d’utilisation « ajouter procès verbal »

2- Le système affiche la liste des procès verbaux recherchés et le responsable

Figure 2.9 : Raffinement de cas d’utilisation « Gérer une visite technique »

Description du cas d’utilisation « ajouter visite technique »

Description du cas d’utilisation « Rechercher visite technique »

III.1 Outil de conception : Rational Rose 7.0.0

III.2 Vue statique

Figure 3.1: Diagramme de classe

III.3 Vue dynamique

Figure 3.2: Diagramme de séquence « s’authentifier »

 Ajouter un procès verbal

Figure 3.3: Diagramme de séquence « ajout d’un procès verbal »