Table des matières

Introduction générale.............................................................................................7
Chapitre 1..............................................................................................................8
Analyse et spécification des besoins.....................................................................8
1.1. Introduction..................................................................................................8
1.2. Présentation générale...................................................................................9
1.2.1. Cadre de projet......................................................................................9
1.3. Etude de l’existent :..................................................................................9
1.4. Critique de l’existent:................................................................................9
1.5. Solution Proposée...................................................................................10
1.6. Spécification des besoins :......................................................................11
1.4.1 Les besoins fonctionnels :.....................................................................11
1.4.2 Les besoins non fonctionnels :..............................................................12
1.5 Environnement de développement..........................................................12
1.5.1 Environnement matériel :.....................................................................12
1.5.2 Environnement logiciel.........................................................................12
1.5.3 Langage de développement :.................................................................14
1.6 Conclusion :................................................................................................15
2.1 Introduction...............................................................................................15
2.1.1 Définition d’UML..................................................................................16
2.1.2 Pourquoi UML.........................................................................................16
2.2 Diagrammes du système............................................................................16
[Link] - Identification des acteurs :.................................................................17
2.2.2– Diagramme de cas d’utilisation globale : .............................................18
2.1.2 Diagrammes de séquence :....................................................................33
2.1.3 Diagramme de classe :...........................................................................38
3.1 Introduction..............................................................................................39
3.2 Le diagramme de Gantt...........................................................................39
3.3 Les interfaces de l’application..................................................................40
3.3.1 Interface de connexion client................................................................40
3.3.2 L’interface inscription:............................................................................40
3.3.3 L’interface demande SOS:......................................................................41
3.3.1 Interface login Admin............................................................................42
3.3.2 L’interface de Gestion des utilisateurs :.................................................42
3.3.4 L’interface de Gestion des matériels :....................................................44
3.3.6 L’interface de Gestion des demandes:...................................................45
Conclusion :......................................................................................................45
Conclusion et perspective................................................................................46
Référence Bibliographie...................................................................................47
 PROJET DE FIN D’ÉTUDES

Introduction générale

L’informatique est une discipline à la mode, très variée et très riche. Elle est
devenue indispensable dans tous les domaines, vue les avantages majeures
qu’elle offre. Elle rend le travail plus facile, plus précis et surtout bien géré et
provoque une nouvelle révolution de l’organisation du travail.

L’informatique de gestion occupe évidemment une grande place dans le

domaine de réparation des automobiles et en particulier, la gestion SOS
automobiles. En effet, la gestion des automobiles est une tâche capitale qui
présente un nombre important de sous tâches réalisées manuellement. Elle
consiste généralement à classifier les véhicules selon leurs pannes, ensuite le
parcours de réparation des véhicules commence par le processus normal qui
commence par le remorquage et enfin la maintenance.

Dans notre système ce processus est initialisé par la phase administrative (la
gestion des utilisateurs, la gestion des factures et la gestion des demandes.

1
 PROJET DE FIN D’ÉTUDES

Chapitre 1
Analyse et spécification des besoins

1.1. Introduction

Dans ce chapitre nous allons mettre le travail dans son contexte général. Dans la
première section nous ferons une présentation générale qui détermine le cadre
du projet, En suite nous décrivons brièvement le processus actuel de gestion
SOS automobile en montrant ses limites afin de proposer notre solution. Puis
nous décrivons les besoins fonctionnels et non fonctionnels. Nous terminons ce
premier chapitre par l’environnement de développement matériel et logiciel et le
langage de développement.

1.2. Présentation générale 

Dans ce chapitre nous allons présenter le cadre du projet.

1.2.1. Cadre de projet

Dans le cadre de mon projet de fin d’études j’envisage de concevoir et

développer une application informatique de gestion sos automobiles.

Le sujet de mon projet s’intitule : la conception et la réalisation d’une

application de gestion sos automobiles.

Ce projet concerne la gestion et la structuration d’un service sos des véhicules.

1.3. Etude de l’existent :

L’amélioration de la qualité des services fournis est un but prioritaire pour

n’importe quel domaine. Afin d’atteindre cet objectif il est tout d’abord
indispensable d’adapter des nouvelles technologies, d’information et de
communication, permettant d’une part l’amélioration du fonctionnement de
l’entreprise et d’autre part de garantir la fidélité des clients. Notre but à travers

2
 PROJET DE FIN D’ÉTUDES

ce travail est de chercher une solution qui répond aux exigences des utilisateurs
par la création d’une application web rendant disponible la communication chez
le client d’une manière efficace.
Les clients demandes un camion de remorquage pour l’assistance et d’autre
part, l’administrateur répondre a ces demandes ,gérer matérielle, gérer
agents.

1.4. Critique de l’existent :

Le processus actuel pour la gestion de demande remorquage manque un système

informatique qui permet de faciliter les processus de gestion de demande
remorquage (évaluations des anomalies, désassemblage, suivi avec le client…
etc.)

L’étude de l’existant permet de révéler les anomalies et les insuffisances

suivantes :

• Absence de service support client.

• Des difficultés de la disponibilité des camions de remorquage.

• Perde de temps de procédure de réclamation.

• L’agent ne peuvent plus consulter les réclamations sans savoir besoin de

se déplacer.

• Le système existant est insuffisant pour répondre aux réclamations et les

problèmes.

• Perdre du temps pour chercher une réclamation,

• Pas d’espace dédié pour le suivi des informations nécessaire pour les
agents.

De ce fait, il sera plus logique de mettre en ligne un espace où on réclame toutes

les problèmes rencontrés et ou on exige une fois les données sont informatisées.
3
 PROJET DE FIN D’ÉTUDES

1.5. Solution Proposée

Comment avoir une bonne application ? Il suffit de répondre aux

critères essentiels de performance pour attirer tous les objectifs.

Notre solution proposée est la création une application dédiée au

services SOS automobile.

« L'application gestion SOS automobile » est une application

informatique permette aux clients de réclamer aux agents pour le
remorquage. De ce fait, la mise en place d’une application mobile
capable d’accomplir les transactions et les suivis en un temps réel, et
de simplifier les procédures de l’organisation de travail.

L’application SOS automobile qui fournit plusieurs services parmi

lesquelles on peut citer :

• Gestion des agents : ajout, modification, suppression

• Gestion des demandes, rependre toutes les réclamations des pannes

de matériels

• Gestion des matériels, planification, mise à jour

1. Définition des branchements

Nous distinguons trois types du branchement à savoir les

branchements de gestion, d’organisation et technique.

Branchement Gestion : concerne la partie gestion de notre application à savoir

• Implanter une base de données complète pour la gestion des

réclamations

• Assurer une meilleure communication et une cohérence de

l’information.

4
 PROJET DE FIN D’ÉTUDES

• Gagner le maximum de temps pour la gestion des tâches principales.

Branchement d’Organisation : concerne la partie

organisationnelle comme:

• Définir une bonne organisation des données collectées entre les

utilisateurs.

• Centraliser les informations c'est-à-dire que les données seront

disponibles à tout moment.

• Réaliser un transfert formel des informations entre l’enseignant et

les techniciens.

BranchementTechnique :Une application web :

• les machines « clientes » contactent une machine « serveur » afin

que ce serveur leur fournisse un service (via l’exécution d’un
programme)

• Les clients envoient des requêtes

• Le serveur envoie des réponses

1.6. Spécification des besoins :

Dans cette section nous allons détermine les besoins fonctionnels et non
fonctionnels de notre future système.

1.4.1 Les besoins fonctionnels :

5
 PROJET DE FIN D’ÉTUDES

Tableau 1 : les besoins fonctionnels

Description détaillé
Fonctionnalités
Gestion administrative Dans cette partie nous intéressons à la gestion des
utilisateurs (ajouter, modifier, supprimer … etc.),la
gestion des demandes pour chaque clients et la gestion
des matériels de chaque existe sur le système.
Gestion de demande Dans cette partie nous intéressons à la gestion de
demandes la consultation des demandes accepter ou
refuser demandes.

1.4.2 Les besoins non fonctionnels :

 Sécurité : l’application sera sécurisée. 

 L’extensibilité : la possibilité d’ajouter ou modifier des nouvelles fonctions.
 La performance : l’application devra être avant tout performante c'est-à-dire à
travers ses fonctionnalités, il répond à toutes les exigences des usages d’une
manière optimale.
 La simplicité : l’application devra être simple à utiliser.
 L’ergonomie : le thème et jeu de couleur de l’application devra être satisfaire
aux yeux.

1.5 Environnement de développement

Dans cette section nous allons déterminer l’environnement matériel et logiciel et

le langage du développement.

1.5.1 Environnement matériel :

6
 PROJET DE FIN D’ÉTUDES

Cette application sera développée sur un ordinateur portable qui possède les
caractéristiques suivantes :
 Marque : Asus.
 Processeur : Intel® core ™ i7-6500U [email protected] 2.59GHz
 Disque Dur : 1 To .
 RAM : 8.00Go .
 Système d’exploitation : Windows 10 Professionnel 64 bits.

1.5.2 Environnement logiciel

Lors du développement de cette application, nous allons utiliser les logiciels

suivants :
 Star UML 3.0.1.
 DreamWeaver CS6.
 PHP Myadmin 5.4.
 EasyPHP 14 VC9

Star UML 3.0.1:

Est un logiciel de modélisation UML (Unified Modeling Language)

open source qui peuvent remplacer dans bien des situations des logiciels
commerciaux et coûteux comme Rational Rose1 ou Together2. Étant
simple d’utilisation, nécessitant peu de ressources système, supportant
UML 2, ce logiciel constitue une excellente option pour une
familiarisation à la modélisation

7
 PROJET DE FIN D’ÉTUDES

Figure 1- Logo de StarUML

DreamWeaver :

est un éditeur de site web WYSIWYG pour Microsoft Windows, et Mac OS X

créé en 1997, commercialisé par Macromedia puis Adobe Systems sous licence
utilisateur final.[4]

Figure 2- DreamWeaver

PHP Myadmin :

(PMA) est une application Web de gestion pour les systèmes de gestion de base

de données MySQL réalisée principalement en PHP et distribuée sous
licence GNU GPL.[1]

8
 PROJET DE FIN D’ÉTUDES

Figure 3- phpMyadmin

EasyPHP :

C’est une plate-forme de développement Web permettant de faire fonctionner

localement (sans se connecter à un serveur externe) des scripts PHP. Ce n'est pas
en soi un logiciel mais un environnement comprenant deux serveurs (un serveur
web Apache et un serveur de bases de données MySQL), un interpréteur de
script (PHP), ainsi qu'une administration SQL phpMyAdmin.

Figure 4– EasyPHP
1.5.3 Langage de développement :

Dans cette partie nous allons parler à proposer les langages du développement

PHP

Le langage PHP fut créé en 1994 par Rasmus Lerdorf pour son site web. C'était

à l'origine une bibliothèque logicielle en C dont il se servait pour conserver une
trace des visiteurs qui venaient consulter son CV. Au fur et à mesure qu'il
ajoutait de nouvelles fonctionnalités, Rasmus a transformé la bibliothèque en

9
 PROJET DE FIN D’ÉTUDES

une implémentation capable de communiquer avec des bases de données et de

créer des applications dynamiques et simples pour le Web [1].

SQL

MySQL est un serveur de bases de données relationnelles SQL développé dans

un souci de performances élevées en lecture, ce qui signifie qu'il est davantage
orienté vers le service de données déjà en place que vers celui de mises à jour
fréquentes et fortement sécurisées. Il est multi-thread et multi-utilisateur.

C'est un logiciel libre, open source, développé sous double licence selon qu'il est
distribué avec un produit libre ou avec un produit propriétaire [1].

CSS

Les feuilles de style en cascade, généralement appelées CSS de

l'anglais Cascading Style Sheets, forment un langage informatique qui décrit la
présentation des documents HTML et XML.

HTML

L'HyperText Mark up Language, généralement abrégé HTML, est le langage de

balisage conçu pour représenter les pages web. C'est un langage permettant
d'écrire de l'hypertexte, d'où son nom [1].

1.6 Conclusion :

Dans ce chapitre, nous avons présenté le cadre de notre projet. Aussi nous avons
fait l’étude de l’existant et la capture des besoins fonctionnels et non
fonctionnels qui nous permettra de préparer une bonne conception pour la
réalisation de notre application SOS automobiles. Dans le chapitre nous

10
 PROJET DE FIN D’ÉTUDES

présenterons les démarches de développement, et de conception suivant de notre

application.

Chapitre 2

Etude Conceptuelle

2.1 Introduction

Dans ce chapitre, nous allons détailler l’étude conceptuelle de notre application.

La phase de conception nécessite des méthodes permettant de mettre en place un
modèle sur lequel on va s’appuyer. La modélisation consiste à créer une
représentation virtuelle d’une réalité de telle façon à faire sortir les points on
quelles on va s’intéresser.

Pour la conception et la réalisation de notre système, nous avons choisis de

modéliser avec le langage UML (Unified Modeling Language) qui offre une
flexibilité marquante qui s’exprime par l’utilisation des diagrammes.

2.1.1 Définition d’UML 

Le Langage de Modélisation Unifié, de l'anglais Unified Modeling Language

(UML), est un langage de modélisation graphique à base de pictogrammes
conçu pour fournir une méthode normalisée pour visualiser la conception d'un
système. Il est couramment utilisé en développement logiciel et en conception
orientée objet [2].

Figure 5- Uml

11
 PROJET DE FIN D’ÉTUDES

2.1.2 Pourquoi UML

Dans ce chapitre, nous allons utiliser UML grâce à ses principaux

critères :

 UML est plus expressif, plus propre et pus uniforme.

 UML pourrait être appliqué à toute science fondée sur la description d’un
système.
 UML permet aux projets de modéliser des choses qui n’auraient pas pu l’être
avant.
 UML supprime toutes les différences non nécessaires de notation et de
terminologie qui obscurcissent les similarités de base de ces différentes
approches.

2.2 Diagrammes du système

Dans cette partie nous présenterons l’ensemble des diagrammes du

système à savoir :
 Le diagramme de cas d’utilisation
 Le diagramme de séquence
 Le diagramme de classe

2.2.1 Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation permet de formaliser (recueillir,

analyser, organiser) les besoins c’est à dire les représenter sous une fore
graphique suffisamment simple.
La construction d’un diagramme de cas d’utilisation débute par la recherche des
frontières du système et des acteurs, pour se poursuivre par la découverte des cas
d’utilisation[2].

12
 PROJET DE FIN D’ÉTUDES

Les éléments de base d’un diagramme de cas d’utilisation sont les suivants :
 Acteur : représente le rôle d’une entité externe (utilisateur humain ou non)

Interagissant avec le système .Il est représenté par un petit bonhomme.

 Cas d’utilisation : Ensemble de séquences, des actions réalisées par le système

et qui produisent un résultat intéressant pour un acteur particulier.
 Relation entre cas d’utilisation : Uml a proposé 3 types de relations standards
Entre cas d’utilisation.
- Include  : le cas d’utilisation incorpore explicitement et de manière
obligatoire un autre cas d’utilisation à l’endroit spécifié.
- Extend  : le cas d’utilisation incorpore implicitement de manière facultative
un autre cas d’utilisation à l’endroit spécifié.
- Généralisation  : le cas d’utilisation descendante héritent des propriétés de
leur parent.

[Link] - Identification des acteurs :

Figure 6– Utilisateur

Acteur Rôles

13
 PROJET DE FIN D’ÉTUDES

Utilisateur -L’utilisateur utilise son login et mot

de passe pour se connecter au
système.

Figure 7– Administrateur

Acteur Rôles
Administrateur -L’administrateur utilise ses
privilèges pour gérer les comptes, les
demandes, et les agents.

Figure 8– Client

Acteur Rôles
Client -Consulter les demande de
remorquage de son véhicule et ses

14
 PROJET DE FIN D’ÉTUDES

factures.

2.2.2– Diagramme de cas d’utilisation globale :

L’objectif de ce diagramme est de donner une vision globale sur les

fonctionnalités du système. Ce diagramme est constitué les acteurs qui agissent
sur les cas d’utilisation

Raffinement du cas d’utilisation : Un cas d’utilisation est une séquence

d’actions réalisées par le système et qui fournit un résultat observable ayant une
valeur ajouté pour un acteur particulier [2]. Pour notre système, nous allons
distinguer les cas d’utilisation suivants :

15
 PROJET DE FIN D’ÉTUDES

Figure 10– Raffinement du cas d’utilisation ‘’S’authentifier ‘’

 Tableau 2 : Description textuelle «Authentification»

Cas -Authentification
d’utilisation :
Acteur : -Utilisateur
Pré-condition : -Etre un Utilisateur
Post-condition : -Utilisateur authentifié
Scénario 1-L’utilisateur lance le système.
nominal : 2-L’utilisateur demande l’interface d’authentification.
3-Le système affiche l’écran d’authentification.
4-L’utilisateur saisit son login et son mot de passe et clique sur
connexion.
5-Le système vérifie le login et le mot de passe de l’utilisateur.
6-Le système ouvre la session de l’utilisateur et affiche l’écran
d’accueil qui correspondant aux privilèges de l’utilisateur.
Scénario A1 : Annulation de connexion
alternatif : ce scénario démarre après le point 2 du scénario nominal.
3-L’utilisateur annule l’authentification,
4- Le système ferme l’écran d’authentification.
Scénario E1 : Erreur de saisie
d’exception : Ce scénario démarre après le point 4 du scénario nominal.
1- Le système affiche un message d’erreur.
2-La séquence nominale repend au point 3.

16
 PROJET DE FIN D’ÉTUDES

Figure 11– Raffinement du cas d’utilisation ‘’Gestion des utilisateurs‘’

 Tableau 3 : Description textuelle «Ajouter utilisateur »

Cas d’utilisation : -Ajouter utilisateur

Acteur : -Administrateur (Admin)
Pré-condition : -L’administrateur authentifié
Post-condition : -Le système sauvegarde les données d’utilisateur.
Scénario nominal : 1- 1-L’administrateur choisit d’ajouter un nouvel
utilisateur.
2- 2-Le système affiche un formulaire d’ajout.
3- 3-L’administrateur saisit les données d’un utilisateur
et clique sur ajouter.
4- 4-Le système vérifie les données saisies.
5-Le système enregistre les données d’un nouvel
utilisateur et affiche un message de sucées.

Scénario alternatif : A1 : Modification un utilisateur

Ce scénario démarre au point 1 du scénario nominal.
2-L’administrateur choisit de modifier un utilisateur.
3-L’administrateur choisit de modifier un utilisateur

17
 PROJET DE FIN D’ÉTUDES

existent.
4-Le système affiche l’écran de modification.
5-Appel du cas ‘’modifier un utilisateur ‘’.

Scénario d’exception E1:  Erreur de saisie

1-Le système affiche un message d’erreur « vérifier
les données ».

18
 PROJET DE FIN D’ÉTUDES

 Tableau 4 : Description textuelle «Modifier utilisateur »

Cas Cas d’utilisation : -Modifier utilisateur

Acteur : -Administrateur (Admin)
Pré-condition : -l’administrateur authentifié
Post-condition : - L’utilisateur a été modifié
Scénario nominal : 1- 1-L’administrateur demande l’interface
de modification des utilisateurs.
2- 2-Le système affiche l’interface de
modification des utilisateurs.
3- 3-L’administrateur choisit l’utilisateur à
modifier.
4- 4-Le système affiche les informations du
l’utilisateur choisit.
5- 5-L’administrateur modifie et valide les
informations des utilisateurs.
6- 6-Le système vérifie les données saisies.
7-Le système affiche le message du
succès.
Scénario alternatif : A1 : Suppression un utilisateur
Ce scénario démarre au point 1 du
scénario nominal.
2-L’administrateur choisit de supprimer
un utilisateur..
3-Le système affiche l’interface de
suppression.
4-Appel du cas ‘’supprimer un
utilisateur ‘’.

19
 PROJET DE FIN D’ÉTUDES

Scénario d’exception E1:  Erreur de saisie

Ce scénario démarre au point 6 du
scénario nominal.
1- Le système affiche un message
d’erreur.

Cas d’utilisation : -Supprimer utilisateur

Acteur : -Administrateur (Admin)
Pré-condition : -L’administrateur authentifié
Post-condition : -Le compte a été supprimé
Scénario nominal : 1- 1-L’administrateur demande l’interface de
suppression des utilisateurs.
2-Le système affiche l’interface de suppression
des utilisateurs.
3-L’administrateur choisit l’utilisateur à
supprimer.
4- Le système affiche message de confirmation
5-L’administrateur valide le choix et clique sur
supprimer.
6- Le système supprime l’utilisateur.
7-Le système affiche un message indiquant que la
suppression s’est déroulée avec succès.

Scénario alternatif : A1 : Annulation de suppression

1-L’administrateur annule l’opération de

20
 PROJET DE FIN D’ÉTUDES

suppression d’utilisateur.
2-Le système réaffiche l’interface de gestion des
utilisateurs sans suppression.
 Tableau 5 : Description textuelle «Supprimer utilisateur »

Figure 12– Raffinement du cas d’utilisation ‘’Gestion des factures‘’

 Tableau 6 : Description textuelle «Ajouter facture »

Cas Cas d’utilisation : -Ajouter facture

Acteur : -Administrateur (Admin)
Pré-condition : -L’administrateur authentifié
Post-condition : -Le système sauvegarde les données d’une
facture.
Scénario nominal : 1-L’administrateur choisit d’ajouter une
nouvelle facture.
2-Le système affiche un formulaire d’ajout.
3-L’administrateur saisit les données d’une
facture et clique sur ajouter.
4-Le système vérifie les données saisies.
5-Le système enregistre les données du
nouvelle facture et affiche un message de

21
 PROJET DE FIN D’ÉTUDES

sucées.

Scénario alternatif : A1 : Modification un utilisateur

Ce scénario démarre au point 1 du scénario
nominal.
2-L’administrateur choisit de modifier une
facture.
3-L’administrateur choisit de modifier une
facture existante.
4-Le système affiche l’écran de modification.
5-Appel du cas ‘’Imprimer une facture ‘’

Scénario d’exception E1:  Erreur de saisie

1-Le système affiche un message d’erreur
« vérifier les données ».

22
 PROJET DE FIN D’ÉTUDES

 Tableau 7 : Description textuelle «Imprimer facture »

Cas d’utilisation - Imprimer facture

Acteur : -Administrateur (Admin)
Pré-condition : -L’administrateur authentifié
Post-condition : -La facture a été imprimée
Scénario nominal : 1-L’administrateur demande l’interface de l’impression
des factures.
2-Le système affiche l’interface de l’impression des

23
 PROJET DE FIN D’ÉTUDES

factures.
3-L’administrateur choisit la facture à imprimer.
4-Le système affiche les informations du la facture
choisie.
5-L’administrateur cliquer sur imprimer.
6-Le système commence l’impression.

Scénario alternatif : A1 : Consultation facture

Ce scénario démarre au point 1 du scénario nominal.
1-L’administrateur choisit de consulter une facture
existante.
2-le système affiche l’interface de listes des factures.

24
 PROJET DE FIN D’ÉTUDES

Figure 13– Raffinement du cas d’utilisation ‘’Gestion des demandes‘’

 Tableau 8 : Description textuelle «Ajouter demande »

25
 PROJET DE FIN D’ÉTUDES

Cas d’utilisation : -Ajouter demande

Acteur : -Client
Pré-condition : -Client s’authentifier
Post-condition : -Le système sauvegarde les données d’une demande.
Scénario 1-Le Client choisit d’ajouter une nouvelle demande.
nominal : 2-Le système affiche un formulaire d’ajout.
3- Le Client saisit les données d’une demande et clique sur
ajouter.
4-Le système vérifie les données saisies.
5-Le système enregistre les données de la nouvelle demande et
affiche un message de sucées.

Scénario A1 : Modification une demande

alternatif : Ce scénario démarre au point 1 du scénario nominal.
2- le Client choisit de modifier une demande.
3-le système affiche l’écran de modification.
4-appel du cas ‘’modifier une demande ‘’.

Scénario E1:  Erreur de saisie

d’exception : 1-Le système affiche un message d’erreur « vérifier les
données ».

 Tableau 9 : Description textuelle «Modifier demande »

Cas Cas d’utilisation : -Modifier demande

Acteur : - Client
Pré-condition : - Client authentifié
26
 PROJET DE FIN D’ÉTUDES

Post-condition : - La demande a été modifiée

Scénario nominal : 1- Le Client demande l’interface de modification des
demandes.
2-le système affiche l’interface de modification des
demandes
3- Le Client choisit la demande à modifier.
4-Le système affiche les informations du la demande
choisit.
5- Le Client modifie et valide les informations des
demandes.
6-Le système vérifie les données saisies.
7-Le système affiche le message du succès.
Scénario alternatif : A1 :Suppression une demande.
Ce scénario démarre au point 1 du scénario nominal.
2- Le Client choisit de supprimer une demande existante.
3-Le système affiche l’interface de suppression.
4-Appel du cas ‘’supprimer une demande ‘’.

Scénario d’exception : E1:  Erreur de saisie

1-Le système affiche un message d’erreur.

 Tableau 10 : Description textuelle «Supprimer demande »

Cas d’utilisation : -Supprimer demande

Acteur : - Client
Pré-condition : - Client authentifié
Post-condition : -La demande a été supprimée
Scénario nominal : 1- Le Client demande l’interface de suppression
des demandes.
2-le système affiche l’interface de suppression des
demandes.
3- Le Client choisit la demande à supprimer.

27
 PROJET DE FIN D’ÉTUDES

4- le système affiche message de confirmation

5- Le Client valide le choix et clique sur
supprimer.
6- Le système supprime la demande.
7- Le système affiche un message indiquant que la
suppression s’est déroulée avec succès.

Scénario alternatif : A1 : Annulation de suppression

1- Le Client annule l’opération de suppression
d’une demande.
2-Le système réaffiche l’interface de gestion des
demandes sans suppression.

Figure 14– Raffinement du cas d’utilisation ‘Gestion des matériels‘’

 Tableau 11 : Description textuelle «Ajouter matériel »

28
 PROJET DE FIN D’ÉTUDES

C Cas d’utilisation : -Ajouter matériel

Acteur : - Administrateur
Pré-condition : - Administrateur authentifié
Post-condition : -Le système sauvegarde les données d’un matériel.
Scénario nominal : 1-l’administrateur choisit d’ajouter un nouvel matériel.
2-Le système affiche un formulaire d’ajout.
3- l’administrateur saisit les données d’un matériel et
clique sur ajouter.
4-Le système vérifie les données saisies.
5-Le système enregistre les données du nouvel matériel
et affiche un message de sucées.

Scénario alternatif : A1 :Modification un matériel

Ce scénario démarre au point 1 du scénario nominal.
2- l’administrateur choisit de modifier un matériel
existant.
3-Le système affiche l’écran de modification.
4-appel du cas ‘’modifier une matériel ‘’.

Scénario d’exception : E1:  Erreur de saisie

1-Le système affiche un message d’erreur « vérifier les
données ».

29
 PROJET DE FIN D’ÉTUDES

 Tableau 12 : Description textuelle «Modifier matériel »

Cas d Cas d’utilisation : -Modifier matériel

Acteur : - Administrateur
Pré-condition : - Administrateur authentifié
Post-condition : - Le matériel a été modifié
Scénario nominal : 1- l’administrateur demande l’interface de
modification des matériels.
2-le système affiche l’interface de modification des
matériels.
3- l’administrateur choisit le matériel à modifier.
4-Le système affiche les informations du la
matériel choisit.
5- l’administrateur modifie et valide les
informations des matériels.
6-Le système vérifie les données saisies.
7-Le système affiche le message du succès.
Scénario alternatif : A1 : Annulation la modification d’ un matériel
Ce scénario démarre au point 1 du scénario
nominal.
2- l’administrateur choisit d’annuler la
modification d’un matériel.
3-le système affiche l’interface de suppression.

Scénario d’exception : E1:  Erreur de saisie

1-le système affiche un message d’erreur.

30
 PROJET DE FIN D’ÉTUDES

Figure 15– Raffinement du cas d’utilisation ‘Consultation des demandes‘’

 Tableau 13 : Description textuelle «Accepter demande »

CCas d’utilisation -Accepter demande

Acteur : - Administrateur
Pré-condition : -Administrateur authentifié
Post-condition : -Le système sauvegarde l’état de l’acceptation d’une
demande.
Scénario nominal : 1- l’administrateur choisit de changer l’état une nouvelle
demande.
2-Le système affiche la liste des demandes.
3- l’administrateur Choisit de changer d’une demande
et clique sur accepter.
4-Le système affiche un message de confirmation
l’acceptation.
5- l’administrateur clique sur ok.
5-Le système enregistre l’état nouvelle d’une demande et
affiche un message de sucées.

Scénario alternatif : A1 : Refus une demande

Ce scénario démarre au point 1 du scénario nominal.

31
 PROJET DE FIN D’ÉTUDES

2- l’administrateur choisit de refuser une demande.

3-le système affiche l’écran de refuser.
4-appel du cas ‘’refuser une demande ‘’.

 Tableau 14 : Description textuelle « Refuser demande »

Cas Cas d’utilisation : -Refuser demande

Acteur : - Administrateur
Pré-condition : - Administrateur authentifié
Post-condition : - la demande a été refusée
Scénario nominal : 1-L’administrateur demande l’interface de refuser
des demandes.
2-Le système affiche la liste des demandes
existante.
3-L’administrateur choisit la demande à refuser.
4-Le système affiche les informations du la
demande choisit.
5- L’administrateur refuser et cliquer sur refuser.
6-Le système affiche l’interface de justification.
7-L’administrateur saisit sa justification et clique
sur ok.
8-Le système affiche un message de confirmation.
9-L’administrateur clique sur ok.
10-Le système affiche le message du succès.
Scénario alternatif : A1 : Consultation demande
Ce scénario démarre au point 1 du scénario

32
 PROJET DE FIN D’ÉTUDES

nominal.
2- Le administrateur choisit de consulter une
demande.
3- Le système affiche les informations du la
demande choisie. .

2.1.2 Diagrammes de séquence :

Dans cette section, nous allons réaliser les diagrammes de séquence du

système, le diagramme de classe de conception des cas raffinés les plus
importants [2].
 Diagramme de séquence du cas « S’authentifier»

La Figure 35 illustre le diagramme de séquence du cas « S’authentifier».

Chaque utilisateur doit s’authentifier, en fournissant son login et son mot de
passe afin d’accéder à son espace sur le système. Si les données saisies sont
erronées, le système affiche un message d’erreur.

33
 PROJET DE FIN D’ÉTUDES

Figure 16– Diagramme de séquence du cas « S’authentifier »

 Diagramme de séquence du cas « Ajouter Utilisateur »

34
 PROJET DE FIN D’ÉTUDES

La figure suivante illustre le diagramme de séquence du cas « Ajouter

Utilisateur ». L’administrateur doit tout d’abord être s’authentifier, pour
pouvoir remplir le formulaire d’ajout. Lorsque les données saisies sont valides,
le système procède à l’enregistrement, puis fait une redirection vers la page où
sera affichée la liste des utilisateurs.

sd [Link]

Systéme

Administrateur

ref
authentification

1:Click_bt_ajouter()

2:Charger_formulaire()
3:Afficher_formulaire()

4:Saisir_formulaire()

5:Clicker_bt_Ajouter()

6:Vérifier(données)

alt
[Formulaire incorrecte ]
7:Corriger les erreurs et saisir à nouveaux()

[Formulaire correcte]

alt
[Données non ajoutées]
8:Affichage("Données deja existe")

[Données ajoutées]
9:Ajouter_Utilisateur()
10:Affichage("message de succées")

Figure 17– Diagramme de séquence du cas « Ajouter utilisateur »

35
 PROJET DE FIN D’ÉTUDES

 Diagramme de séquence du cas « Modifier Utilisateur »

 Diagramme de séquence du cas « Modifier Utilisateur»

La figure suivante illustre le diagramme de séquence du cas « Modifier
Utilisateur ». Chaque administrateur peut modifier un ou plusieurs utilisateurs
en cliquant sur le bouton modifier. Un formulaire est alors affiché, là où
l’administrateur peut modifier les données. S’il insère des données qui ne sont
pas valides ou déjà existes, le système affiche un message d’erreur.

sd Modif util

Systéme

Administrateur

ref
authentification

1:Click_bt_modifier()

2:Charger_formulaire()
3:Afficher Formulaire()

4:Saisir_formulaire(nouveaux Données)
5:Vérification()

alt
[Saisie incorrecte]
6:Affichage("corriger et saisir à nouveaux")

[Saisie correcte]
7:Retourner au liste des utilisateurs()

Figure 18– Diagramme de séquence du cas « Modifier utilisateur » 36

 PROJET DE FIN D’ÉTUDES

 Diagramme de séquence du cas « Supprimer Utilisateur»

La figure suivante illustre le diagramme de séquence du cas « Supprimer
Utilisateur » Lorsque l’administrateur clique sur le bouton Supprimer , le
système affiche une fenêtre de dialogue. Si l’administrateur valide la
suppression, l’utilisateur sera supprimé à partir de la base de données, sinon la
liste des utilisateurs s’affichera une deuxième fois.

sd [Link]

Systéme

Administrateur

ref
authentification

1:Affichage liste des utilisateurs()

2:Click_bt_supprimer()

3:Affichage("Voulez-vous supprimer ce utilisateurs")

4:Click_bt_Ok()

alt

[Suppresion confirmée]

5:Suppression_Utilisateur()
6:Affichage_liste_utilisateurs()

[Suppression annulée]
7:affichage_list_utilisateurs()

Figure 19– Diagramme de séquence du cas « Supprimer utilisateur »

37
 PROJET DE FIN D’ÉTUDES

2.1.3 Diagramme de classe :

Le diagramme de classes est considéré comme le plus important de la

modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation
.Chaque langage de programmation orienté objet, donne un moyen spécifique
pour implémenter le paradigme objet (pointeurs ou non, héritage multiple ou
non, etc.), mais le diagramme de classe permet de modéliser les classes du
système et leurs relations indépendamment d’un langage de programmation
particulier. Les principaux éléments de cette vue statique sont les classes et leurs
relations : association, généralisation et plusieurs types de dépendances, telles
que la réalisation et l’utilisation [2].

38
 PROJET DE FIN D’ÉTUDES

Chapitre 3

Implémentation et réalisation

3.1 Introduction

Après avoir affecter l’étude et la conception de notre application nous passerons

à la phase de l’implémentation. Ce chapitre présentera le résultat du travail
effectué durant ce projet de fin d’étude.

3.2 Le diagramme de Gantt

Le diagramme de Gantt est un outil utilisé (souvent en complément d'un

réseau PERT) en ordonnancement et en gestion de projet et permettant de
visualiser dans le temps les diverses tâches composant un projet. Il s'agit d'une
représentation d'un graphe connexe, valué et orienté, qui permet de représenter
graphiquement l'avancement du projet.

Figure 45– Diagramme de classe 39

 PROJET DE FIN D’ÉTUDES

Le premier diagramme de ce type (appelé Harmonogram Adamieckiego) fut

réalisé par l'ingénieur polonais Karol Adamiecki en 1896. Il l'a décrit en
1931, mais la langue de publication n'a pas permis la reconnaissance
internationale de son idée. Pour cette raison, le concept a été nommé
d'après Henry L. Gantt, ingénieur américain collaborateur de Frederick
Winslow Taylor, qui a publié la description du diagramme en 1910.

Figure 20– Diagramme de Gantt

3.3 Les interfaces de l’application

Dans cette partie , nous présenterons quelques interfaces utilisateurs de notre

application.

3.3.1 Interface de connexion client

L’utilisateur peut de se connecter à partir de son login et son mot de passe.

40
 PROJET DE FIN D’ÉTUDES

Figure 21– Interface de connexion

3.3.2 L’interface inscription:

L’interface permet aux utilisateurs d’ajouter un demande d’inscription

Figure 22– Interface inscription

41
 PROJET DE FIN D’ÉTUDES

3.3.3 L’interface demande SOS:

L’interface permet aux utilisateurs d’ajouter un demande de dapannage

Figure 23–Interface demande dépannage

3.3.1 Interface login Admin

L’administrateur peut de accéder a leur session à partir de son login et son mot
de passe correct.

42
 PROJET DE FIN D’ÉTUDES

Figure 24– Interface login Admin

3.3.2 L’interface de Gestion des utilisateurs :

L’interface de gestion des utilisateurs permet d’ajouter un nouvel

utilisateur et de modifier ses données ou de supprimer ses informations.

Figure 25– Interface de Gestion des utilisateurs 43

 PROJET DE FIN D’ÉTUDES

Figure 26– Interface d’ajout utilisateur

Figure 27– message de sucée ajouter utilisateur

44
 PROJET DE FIN D’ÉTUDES

3.3.4 L’interface de Gestion des matériels :

L’interface de gestion des matériels permet d’ajouter un nouveau matériel

et de modifier ses données.

Figure 28– Interface de Gestion des matériels

3.3.6 L’interface de Gestion des demandes:

L’interface de gestion des demandes permet d’accepter une nouvelle

demande ou de refuser ses demandes.

45
 PROJET DE FIN D’ÉTUDES

Figure 29– Interface de Gestion des demandes

Conclusion :

Au cour de ce dernier chapitre nous avons présenté le diagramme de Gantt

et le diagramme de déploiement, aussi nous avons montrer comment gère notre
système et ses fonctionnalités. Ainsi nous avons présenté les interfaces de notre
application SOS automobile et nous terminé avec les besoins.

Conclusion et perspective

46
 PROJET DE FIN D’ÉTUDES

Dans le cadre de ce projet de fin d’étude, nous espérons avoir bien réussi à
créer une application SOS auomobile. Ce travail a nécessité d’effectuer au
préalable une étude de quelques applications évoluant dans le même secteur
d’activité de celui-ci. Cette étude nous a été donc de forte utilité pour dégager
les fonctionnalités à mettre en œuvre et cerner les spécifications de notre site.

La conception du projet avec la méthode UML nous a permis de bien

modéliser le cahier de charge de manière à ce que la compréhension du système
devienne plus facile et le développement plus rapide.

Ce projet a était une occasion bénéfique pour nous mettre ultérieurement

dans les conditions du travail professionnel en terme de contraintes, de
communication et des exigences des clients.

Au terme de ce travail, nous espérons avoir bien réussi à atteindre les

objectifs fixés dés le début. Nous notons également que plusieurs améliorations
demeurent possibles dans le futur.

Cette expérience nous a permis de mettre en pratique nos connaissances

acquises dans la programmation qui a été développée en utilisant le langage
PHP, etc. Cette expérience se résume donc en une somme d’enrichissements
techniques, personnels, culturels et humains qui constitue un atout significatif
pour le début de nos carrières professionnelles ultérieures.

47
 PROJET DE FIN D’ÉTUDES

Référence Bibliographie

[1] :[Link]/wiki/technologie (développements)e-de-d

[2] :[Link]/wiki/Uml-(informatique).

[3] : [Link]

[4] : [Link]

[5] : [Link]

48