rapport pfe

Application de gestion

Tables des matières

TABLES DES MATIÈRES....................................................................................................................................1

LISTE DES FIGURES...........................................................................................................................................3

LISTE DES TABLEAUX.......................................................................................................................................4

PRÉSENTATION DE LA SOCIÉTÉ D’ACCUEIL............................................................................................5

INTRODUCTION GÉNÉRALE...........................................................................................................................6

CHAPITRE 1 : CADRE DE PROJET..................................................................................................................7

I. INTRODUCTION :...........................................................................................................................................7II. MOTIVATION :..............................................................................................................................................7III. OBJECTIFS :..................................................................................................................................................7IV. TRAVAIL DEMANDÉ :....................................................................................................................................7V. PUGET DU TEMPS :........................................................................................................................................8VI. ORGANISATION DU RAPPORT :......................................................................................................................8VII. CONCLUSION :..........................................................................................................................................9

CHAPITRE 2 : ETUDE PRÉALABLE..............................................................................................................10

I. INTRODUCTION :.........................................................................................................................................10II. ETUDE DE L’EXISTANT :.............................................................................................................................10III. CRITIQUE DE L’EXISTANT :.........................................................................................................................11IV. PROBLÉMATIQUES :....................................................................................................................................11V. SOLUTION PROPOSÉS :................................................................................................................................11VI. SPÉCIFICATION DES BESOINS :....................................................................................................................12

VI.1. Les besoins fonctionnels :.................................................................................................................12VI.2. Les besoins non fonctionnels :..........................................................................................................13

VII. CONCLUSION:.........................................................................................................................................13

CHAPITRE 3 : ETUDE CONCEPTUELLE.....................................................................................................14

I. INTRODUCTION :.........................................................................................................................................14II. ETUDE CONCEPTUELLE :.............................................................................................................................14

II.1. Présentation du Langage (UML) utilisé :.........................................................................................14II.2. Modélisation:....................................................................................................................................15

II.2.1. Diagramme des cas d’utilisation:...................................................................................................................15II.2.2. Le diagrammes de cas d’utilisation détaillé :.................................................................................................17II.2.3. Les diagrammes des Séquences :...................................................................................................................21II.2.4. Diagrammes de Classes :...............................................................................................................................29

II.3. Conception des données : Modèle logique de données(MLD).........................................................33III. CONCLUSION:.............................................................................................................................................34

CHAPITRE 4: RÉALISATION..........................................................................................................................35

I. INTRODUCTION :.........................................................................................................................................35II. ENVIRONNEMENT DE DÉVELOPPEMENT :....................................................................................................35

II.1. Environnement matériel:...................................................................................................................35II.2. Environnement logiciel:....................................................................................................................35

III. RÉALISATION :............................................................................................................................................36III.1. Organigramme :................................................................................................................................36III.2. Interface d’accueil :.........................................................................................................................37III.3. Interfaces utilisateur:........................................................................................................................38

III.3.1. Gestion candidats:.....................................................................................................................................38

1


III.3.2. Gestion des séances :.................................................................................................................................39III.3.3. Gestion des voitures :................................................................................................................................40III.3.4. Gestion Moniteur:.....................................................................................................................................41III.3.5. Etat candidat :............................................................................................................................................42III.3.6. Connexion:................................................................................................................................................43

III.4. Interfaces administrateur:.................................................................................................................43III.4.1. Statistiques :..............................................................................................................................................44III.4.2. Historiques :..............................................................................................................................................45III.4.3. Paramètres:................................................................................................................................................46

IV. CONCLUSION :............................................................................................................................................46

CONCLUSION ET PERSPECTIVES................................................................................................................47

2


Liste des figures

FIGURE II. 1: EXEMPLE D'APPLICATION...................................................................................................................10

FIGURE III. 1: DIAGRAMME DE CAS D'UTILISATION GÉNÉRALE..............................................................................17FIGURE III. 2: DIAGRAMME DE CAS D’UTILISATION POUR LA GESTION DES CANDIDATS........................................17FIGURE III. 3: DIAGRAMME DE CAS D’UTILISATION POUR LA GESTION DES SÉANCES............................................18FIGURE III. 4: DIAGRAMME DE CAS D’UTILISATION POUR LA GESTION DES VOITURES..........................................19FIGURE III. 5: DIAGRAMME DE CAS D’UTILISATION POUR LA GESTION D’HISTORIQUES.........................................19FIGURE III. 6:DIAGRAMME DE CAS D’UTILISATION POUR LA GESTION DES STATISTIQUES.....................................20FIGURE III. 7:DIAGRAMME DE SÉQUENCE D’AUTHENTIFICATION...........................................................................22FIGURE III. 8:DIAGRAMME DE SÉQUENCE D’AJOUTER UN CANDIDAT PAR L’ADMINISTRATEUR.............................23FIGURE III. 9:DIAGRAMME DE SÉQUENCE DE SUPPRIMER UN CANDIDAT PAR L’ADMINISTRATEUR......................24FIGURE III. 10:DIAGRAMME DE RECHERCHER UN CANDIDAT PAR UN ADMINISTRATEUR.......................................25FIGURE III. 11:DIAGRAMME DE SÉQUENCE DE MODIFIER UN MONITEUR PAR L’ADMINISTRATEUR........................26FIGURE III. 12:DIAGRAMME DE SÉQUENCE D’AJOUTER UN MONITEUR PAR L’ADMINISTRATEUR...........................27FIGURE III. 13:DIAGRAMME DE SÉQUENCE DE SUPPRIMER UN MONITEUR PAR L’ADMINISTRATEUR......................28FIGURE III. 14:DIAGRAMME DES CLASSES..............................................................................................................30

FIGURE IV. 1: ORGANIGRAMME DE L’APPLICATION...............................................................................................36FIGURE IV. 2: INTERFACE D'ACCUEIL......................................................................................................................37FIGURE IV. 3: GESTION DES CANDIDATS PAR L'UTILISATEUR.................................................................................38FIGURE IV. 4: GESTION DES SÉANCES PAR L'UTILISATEUR.....................................................................................39FIGURE IV. 5: GESTION DES VOITURES PAR L'UTILISATEUR....................................................................................40FIGURE IV. 6: GESTION MONITEUR PAR L'UTILISATEUR.........................................................................................41FIGURE IV. 7: ETAT CANDIDAT CONTRÔLER PAR L'UTILISATEUR...........................................................................42FIGURE IV. 8: CONNEXION EFFECTEUR PAR L'UTILISATEUR....................................................................................43FIGURE IV. 9: STATISTIQUES EFFECTUER PAR L'ADMINISTRATEUR.......................................................................44FIGURE IV. 10: HISTORIQUES CONSULTER PAR L'ADMINISTRATEUR.......................................................................45FIGURE IV. 11: PARAMÈTRE RÉGLER PAR L'ADMINISTRATEUR...............................................................................46

Liste des tableaux

3


TABLEAU III. 1: IDENTIFICATION DES CLASSES.......................................................................................................31TABLEAU III. 2: IDENTIFICATION DES ATTRIBUTS ET DES MÉTHODES....................................................................33

4


Présentation de la société d’accueil

Institut : Institut Supérieur d’Informatique et des Techniques de Communication

(ISITCOM).

Adresse : Rue G.P.1 Hammam Sousse, 4011 Hammam Sousse, Tunisie.

Tél/Fax: +216 73 37 15 71 / +216 73 36 44 11.

Le ministère de l’Enseignement Supérieur et de la Recherche Scientifique et de la

Technologie de Tunisie a fondé l’Institut Supérieur d'Informatique et des Technologies de

Communication de Hammam Sousse (ISITCom ou Infcom) en Août 2001 au sein de

l’Université de Sousse pour pouvoir former des compétences très demandées dans le domaine

des Technologies de l’Information et de la Communication.

L’ISITCOM suit le système LMD et elle donne trois types de formations: Technologies du

multimédia et du Web, Technologies des réseaux informatiques et Technologies des

communications. Elle offre l’occasion aux étudiants brillants de continuer leurs études au

cycle d'ingénieurs dans le but d'obtenir le diplôme national d'ingénieur en téléinformatique.

5


Introduction générale

Grâce au progrès de la recherche scientifique et technologique, l’informatique n’a cessé

d’évoluer et de s’adapter aux besoins de l’homme.

En effet, avec l’apparition des outils de développement, de programmation et avec

l’évolution des méthodes de conception et de modélisation des systèmes d’information,

l’informatique est devenue aussi fiable qu’elle se voit intégrée dans tous les autres domaines.

Dans le cadre de réalisation de ce projet de fin d’étude intitulé « Application de gestion

d’auto école» nous avons l’objectif d’informatiser les tâches de gestion des candidats d’une

auto école.

Le présent rapport expose les différentes étapes de la démarche suivie pour garantir une

conception adéquate et une réalisation répondant aux besoins spécifié. Il comprend, après la

présentation générale du projet et des objectifs globaux du travail deux parties :

Conception

Réalisation de l’application.

6


Chapitre 1 : Cadre de projet

I. Introduction :

Dans ce chapitre nous allons nous intéresser à la problématique de notre projet. Nous

allons énumérer les objectifs et présenter le travail demandé.

II. Motivation :

A la fin de nos études on des acquits concernant la programmation orienté objet , donc

on va utilisé ces acquits pour trouvé la solution idéale pour n’importe quel projet.

Dans notre cas on va utilisé Java comme langage de programmation orienté objet pour

la réalisation de notre projet.

III. Objectifs :

Faciliter le traitement des données.

Faciliter la gestion des ressources.

Contrôler et valider les paiements des candidats.

Assurer une communication directe avec l’ATTT.

Gérer les comptes candidats.

IV. Travail demandé :

Notre projet consiste à réaliser une application de gestion pour une auto école, dans

laquelle on essayera de répondre de manière efficace au besoin utilisateur et d’atteindre les

objectifs fixés en proposant la solution optimale.

7


V. Puget du temps :

Découpage de l’application

2012

Février Mars Avril Mai Juin

Bibliographie

Etude préalable

Etude détaillée

Réalisation

Elaboration du rapport

Tableau 1. Puget de temps

VI. Organisation du rapport :

Le rapport est organisé en 4 chapitres :

Le premier chapitre concerne ‘le cadre de projet’ qui contient une introduction,

motivation, objectifs, travail demandé, puget de temps et organisation du rapport.

Le deuxième chapitre nommé ‘étude préalable’ contient l’étude de l’existant, la critique

de l’existant , la problématique, les solutions proposées, la spécification des besoins et la

conclusion.

Le troisième chapitre nommé ‘étude Conceptuelle’ présente notre étude conceptuelle

détaillée du projet.

Le dernier chapitre est consacré à la partie réalisation du projet. Nous commençons

par les outils de réalisation matériels et logiciels puis nous présentons quelques images écran

des interfaces réalisées et nous clôturons par une conclusion.

8


VII. Conclusion :

Dans ce chapitre nous avons présenté le cadre générale du projet et nous avons donné

une légère description concernant le travail à réaliser.

9


Chapitre 2 : Etude préalable

I. Introduction :

Dans ce chapitre nous allons mener une étude préalable de notre projet. Nous allons

exposer les solutions existantes et la critique de ces solutions pour arriver à spécifier les

problématiques détectées. Nous spécifions ensuite les besoins fonctionnels et non fonctionnels

pour aboutir enfin à proposer notre solution.

II. Etude de l’existant :

Cette section porte sur l’étude des systèmes existants sur le marché et de

dégager les déficits détectés.

Dans ce but on a remarqué que le domaine des auto école n’est pas encore informatiser,

ils utilisent les outils traditionnels pour la gestion des données et des ressources.

Toutefois, il existe quelques applications de gestion d’auto école qui facilitent la

gestion des clients. La figure II.1 illustre l’interface de l’application Yonix Gestion Auto

Ecole.

Figure II. 1: Exemple d'application

10


Yonix Gestion Auto Ecole

Version Beta 0.1

Auteur :Moreau Yoann

Est un logiciel libre de gestion des clients des auto école

III. Critique de l’existant :

Cette application présente des lacunes. En effet, elle ne permet pas la gestion des

moniteurs ni celle des voitures. En outre, elle se limite à l’ajout ou la modification des

candidats sans avoir la possibilité de programmer leurs séances de code ou de conduite. Elle

n’est pas efficace pour répondre aux besoins utilisateurs.

IV. Problématiques :

D’après l’étude effectuée au sein des auto écoles, il nous a été possible de dégager les

insuffisances suivantes :

Des problèmes de perte de temps et d’argents.

Difficultés de la gestion des donnés

Problème de contrôle des candidats.

Lenteur des services.

Perte des données.

V. Solution proposés :

L’étude de l’existant et sa critique nous ont menés à proposer une solution qui

répond aux objectifs et permettant de résoudre les problèmes cités. Notre solution offre les

fonctionnalités suivantes :

Gestion des candidats

Gestion des séances

Gestion des voitures

Gestion des moniteurs

Etat des candidats

11


Connexion

Historique

Statistiques

Paramètres

VI. Spécification des besoins :

VI.1. Les besoins fonctionnels :

Afin de définir les besoins que doit satisfaire l’application, nous avons effectué des

entretiens avec les différents utilisateurs pour identifier leurs besoins.

Ainsi l’application à réaliser doit permettre à :

L’administrateur la :

Gestion les candidats

Gestion les moniteurs.

Gestion les voitures.

Gestion les séances.

Contrôler l’état des candidats

Consulter l’historique.

Calculer les statistiques.

Modifier les paramètres

Se connecter à l’ATTT

L’utilisateur la :

Gestion les candidats.

Gestion les moniteurs.

Gestion les séances.

Gestion les voitures

Contrôler l’états des candidats

Se connecte à l’ATTT.

12


VI.2. Les besoins non fonctionnels :

Notre application doit être à la fois facile à utiliser, et efficace. Donc il faut

respecter des contraintes sur plusieurs niveaux. Nous allons spécifier ces contraintes :

Développer des interfaces simples et compréhensibles par l’utilisateur.

Ne pas surcharger l’écran ; il faut laisser des espaces vides pour que la concentration

soit équilibrée.

L’application doit répondre exactement aux besoins utilisateurs.

VII. Conclusion:

A la fin de ce chapitre on a achevé l’étape d’étude de marché et la spécification des

besoins et on passera dans le chapitre suivant à l’étude conceptuelle de projet .

13


Chapitre 3 : Etude Conceptuelle

I. Introduction :

La conception est une étape fondamentale dans la réalisation d’un projet. Elle consiste à

modéliser les composantes du système à réaliser.

Nous allons présenter tout au long de ce chapitre notre conception. Nous allons utilisé

UML comme langage de modélisation .

II. Etude conceptuelle :

II.1. Présentation du Langage (UML) utilisé :

UML (Unified Modeling Langage) :

UML en français Langage de Modélisation Unifié : C’est un langage graphique de

modélisation des données et des traitements, il est l’accomplissement de la fusion des

précédents langages de modélisation objet : Booch, OOSE, OMT, il est un standard défini par

l’OMG (Object Management Group).

Le secteur informatique a adopté UML comme langage pivot, très complet, orienté objet

et indépendant des langages de programmations, il est riche et ouvert.

Nous avons adopté le langage UML comme langage de modélisation pour notre

application, ce n’est pas un choix arbitraire, mais ceci est dû en fait à plusieurs raisons :

- UML est basée sur les mécanismes d’abstraction, d’hiérarchie et de décomposition.

- Elle considère un système comme une totalité organisée dont les éléments solidaires

ne peuvent être définis que les uns par rapport aux autres.

- La modélisation orientée objet avec UML facilite la réutilisation d’application.

- Nous visons réaliser l’application avec le langage java qui est un langage orientée

objet.

14


II.2. Modélisation:

II.2.1. Diagramme des cas d’utilisation:

Le diagramme des cas d’utilisation est une représentation du comportement du système

de point de vue de l’utilisateur, c’est une définition des besoins qu’attend un utilisateur du

système, il contient tous les cas d’utilisation en liaison directe ou indirecte avec les acteurs.

Les acteurs : les acteurs se représentent sous la forme de petits personnages nommés, un

acteur représente le rôle joué par une personne ou une classe qui interagit avec un système.

Les cas d’utilisation : un cas d’utilisation est un classificateur qui modélise une

fonctionnalité d’un système ou d’une classe. L’instanciation d’un cas d’utilisation se traduit

par l’échange de message entre le système et ses acteurs. Il définit les activités attendues des

différents utilisateurs par rapport `a l’application. Le cas d’utilisation décrit ce que fait un

système sans préciser comment il le fait : il donne un point de vue externe sur le système.

a. Les acteurs du système:

Un acteur système représente l’ensembles des rôles joués par un utilisateur en

interaction avec notre application. Un acteur interagit avec notre système pour avoir un

résultat.

Les acteurs de notre système sont :

L’administrateur de l’école: il bénéficie de la totalité des fonctionnalités car il a les

possibilités d’effectuer l’ajout, la suppression, la modification, le contrôle et la

gestion de toutes les ressources.

L’utilisateur de l’application : ses fonctionnalités sont limités à certaines fonctions tel

que la gestion des candidats, des voitures, des séances, des moniteurs, contrôles les

états des candidats et la connexion à l’ ATT.

b. Les cas d’utilisation :

L’administrateur de l’école peut gérer les candidats et les ressources :

Gérer les candidats

15


Gérer les moniteurs

Gérer les voitures

Consulter l’historique

Valider les candidats

Calculer les statistiques

Modifier des paramètres

Vérifier l’état des candidats

L’utilisateur de l’application peut :

Gérer les candidats

Gérer les séances

Gérer les moniteurs

Gérer les voitures

Se connecter à l’ATT

Consulter l’états des candidats

Notre système est composé de deux parties : une partie accessible par tous les acteurs

du systèmes et d’autres ne sont accessibles que par l’administrateur de l’application. Toutes

les fonctionnalités nécessitent une authentification préalable.

Un acteur du type « administrateur » hérite toutes les fonctionnalités de l’acteur

« utilisateur ». Il a aussi les droits d’effectuer d’autres fonctionnalités de calcul des

statistiques, d’affichage de l’historiques et de paramétrage de l’application.

16


Figure III. 1: Diagramme de cas d'utilisation générale

II.2.2. Le diagrammes de cas d’utilisation détaillé :

1. Cas d’utilisation de la gestion des candidats :

Figure III. 2: Diagramme de cas d’utilisation pour la gestion des candidats

17


Description

Le module de « gestion des candidats » offre des fonctionnalités pour les deux types

d’acteurs « Administrateurs » et « Utilisateur » . Il y a une flèche de l'acteur

« Administrateur » vers l'acteur « utilisateur »: qui représente une relation entre ces deux

acteurs qui est la généralisation: tous les cas d'utilisation accessibles à « Utilisateur » sont

aussi accessibles pour « l’administrateur », mais l'inverse est faux.

Ce module est composé de 5 sous modules : ajouter candidats, modifier candidats,

supprimer candidats, Rechercher candidats et afficher candidats.

2. Cas d’utilisation de la gestion des Séances :

Figure III. 3: Diagramme de cas d’utilisation pour la gestion des Séances

Description

La fonction de gestion des séances est une fonction accessible par les deux acteurs

« Administrateurs » et « Utilisateur ».. Ce module est composé par les 4 sous modules

ajouter séances code, ajouter séances conduite, ajouter examen code, ajouter examen

conduite.

Avec la relation « Extend » un acteur peut effectuer une tâche ou plusieurs parmi les

tâches offertes selon les besoins utilisateurs.

18


3. Cas d’utilisation de la gestion des voitures

Figure III. 4: Diagramme de cas d’utilisation pour la gestion des voitures

Description

La fonction de gestion des voitures est une fonction accessible par les deux acteurs

« Administrateurs » et « Utilisateur » .Ce module est composé par les 3 sous modules

« ajouter voiture, suivi voiture, supprimer voiture»

Avec la relation « Extend » un acteur peut effectuer une tâche ou plusieurs parmi les


4. Cas d’utilisation de l’affichage des historiques :

Figure III. 5: Diagramme de cas d’utilisation pour la gestion d’historiques

19


Description

La fonction d’Historiques est une fonction accessible que l’acteur

« Administrateurs ». Ce module est composé par les deux sous modules : Afficher

historique code et afficher historique conduite.

Avec la relation « Extend » un acteur peut effectuer une tâche ou plusieurs parmi tles


5. Cas d’utilisation pour les statistiques :

Figure III. 6:Diagramme de cas d’utilisation pour la gestion des Statistiques

Description

La fonction de statistiques est une fonction accessible que par l’ acteurs

« Administrateurs ».

Ce module est composé par les 4 sous modules « Afficher Statistiques moniteur,

Afficher Statistiques voiture, Afficher Statistiques code, Afficher Statistiques conduite».

Un acteur peut effectuer une tâche ou plusieurs parmi les tâches offertes selon les

besoins utilisateurs.

20


II.2.3. Les diagrammes des Séquences :

Un diagramme de séquence permet de spécifier les interactions qui existent entre un

groupe d’objets selon un point de vue temporel, on y met l’accent sur la chronologie des

envois de message. Comme les diagrammes des séquences sont toujours lus du haut vers le

bas, ils illustrent l’ordre dans lequel les messages sont envoyés entre les objets. Il peut

illustrer un cas d’utilisation.

Les composants d’un diagramme de séquence sont les suivants :

Les objets : sur un diagramme de séquence, les objets apparaissent toujours

dans la partie supérieure, ce qui facilite l’identification des classes qui participent à

l’interaction.

Les messages : les messages sont représentés par des flèches directionnelles.

Au-dessus de ces flèches figure un texte nous informant du message envoyé entre les

objets.

21

Administrateur

1 : entrer login et pwd ()

3 : demande de connexion()

5 : si valide()

Interface BD

6 : se connecter()

8:message d’erreur ()

7: si n’est pas valide()

2: verification()

4 : Verification()


1. Diagramme de séquence d’authentification :

Figure III. 7:Diagramme de séquence d’authentification

2. Diagramme de séquence d’ajout d’un candidat

Ce diagramme décrit le scénario suivant :

L’administrateur demande le formulaire d’ajout en cliquant sur l’onglet « Ajouter

candidat ». Une fois le système lui renvoie ce formulaire, il doit remplir les champs avec des

valeurs valides.

Si le candidat n’existe pas, un message de confirmation sera affiché. Si non, un message

d’erreur apparait sur l’interface du travail.

22

Administrateur

1 : insert les valeurs d’un candidat ()

2 :verification())

5 : s'il existe ()

Interface BD

8: ajout réussi()

6:message d’erreur()

7: s’il n’existe pas()

3 :demande d’ajout


Figure III. 8:Diagramme de séquence d’ajouter un candidat par l’administrateur

3. Diagramme de séquence de supprimer un candidat


L’administrateur demande le formulaire de suppression en cliquant sur l’onglet

« Supprimer candidat». Une fois le système lui renvoie une formulaire, il doit remplir le

champs avec le numéro de la carte d’identité de candidat qu’on souhaite le supprimer .

Si le candidat est supprimé, un message de confirmation sera affiché. Si non, un

message d’erreur apparait sur l’interface de travail.

23

4: verification()

Administrateur

1 : entrer N° CIN Candidat()

3: recherche()

5 : s'il existe

Interface BD

8:suppression réussie()

7: si suppression réussie()

2:verification()

6:demande de suppression()

9: si suppression échouée() 10 :suppression échouée()

11 : s'il n’ existe pas()12:message d’erreur()


Figure III. 9:Diagramme de séquence de supprimer un candidat par l’administrateur

4. Diagramme de séquence de rechercher un candidat


L’administrateur demande le formulaire de recherche d’un candidat en cliquant sur

l’onglet « Rechercher candidat». Une fois le système lui renvoie une formulaire, il doit taper

le numéro de la carte d’identité de candidat a chercher .

Si le candidat existe, un affiche de ses informations personnels. Si non, un message

d’erreur apparait sur l’interface de travail.

24

4:verification()

Administrateur

1 :Entrer N° CIN candidat ()

2 : lancer la recherche()

4 : s'il existe()

Interface BD

5 :afficher les informations()

7 :Candidat n’existe pas()


3: verification()


Figure III. 10:Diagramme de rechercher un candidat par un administrateur

5. Diagramme de séquence de modifier d’un moniteur


L’administrateur demande le formulaire d’ajout en cliquant sur l’onglet « Ajouter». Une

fois le système lui renvoie ce formulaire avec récupération de données existantes, il effectue

les modifications nécessaires, puis il valide. Un message de confirmation sera affiché.

25

Adminadministist Administrateur rateur

3 : vérification()

10: Enregistrement()

1 : entrer N° CIN moniteur()

2 : lancer la recherche()

6 : s'il existe ()

BD

7 :recuperation des données()


8 :insertion nouveau valeur()

9 :Demande enregistrement()

5:Message d’erreur()

11: si oui

12: Enregistrement avec succé()

13: si Non14: erreur d’enregistrement()

Administrateur Interface


Figure III. 11:Diagramme de séquence de modifier un moniteur par l’administrateur

26

Administrateur

1 : remplir les champs ()

2 : demande d’ajout()

4 : s'il existe()

Interface BD

7 : Ajout réussie() ()

5 :message d’erreur()



6. Diagramme de séquence d’ajout un moniteur


L’administrateur demande le formulaire d’ajout un moniteur en cliquant sur l’onglet

« Ajouter moniteur ». Une fois le système lui renvoie une formulaire, il doit remplir les

champs avec des valeurs valides.

Si le candidat n’existe pas, un message de confirmation sera affiché. Si non, un message

d’erreur apparait sur l’interface du travail.

Figure III. 12:Diagramme de séquence d’ajouter un moniteur par l’administrateur

27

3 : vérification()

1 : entrer N° CIN moniteur()

3: recherche()

5 : s'il existe

Interface BD

8:suppression réussie()

7: si suppression réussie()

2:verification()

6:demande de suppression()

9: si suppression échouée() 10 :suppression échouée()

11 : s'il n’ existe pas()12:message d’erreur()


7. Diagramme de séquence de suppression d’un moniteur


L’administrateur demande le formulaire de suppression en cliquant sur l’onglet

« Supprimer moniteur». Une fois le système lui renvoie une formulaire, il doit remplir le

champ avec le numéro de la carte d’identité nationale.

Si le moniteur est supprimé, un message de confirmation sera affiché. Si non, un

message d’erreur apparait sur l’interface de travail.

Figure III. 13:Diagramme de séquence de supprimer un moniteur par l’administrateur

28

4:verification()


II.2.4. Diagrammes de Classes :a. Définition :

Le diagramme de classe est une étape nécessaire pour la conception de la base, il va nous

aider à l’implémenter des différentes tables de notre base de données.

Une classe est composée par :

Des attributs : ces sont les données dont les valeurs représentent l’état de

l’objet.

Des méthodes : ces sont les opérations applicables aux objets.

b. Le diagramme de classe de l’application :

La figure suivante représente le diagramme de classe de notre application, dévoilant la

manière avec laquelle la base de données est construite.

29


Figure III. 14:Diagramme des classes

c. Identification des classes :

N° Nom Désignation1 Administrateur Cet objet englobe les informations concernant un

administrateur2 Utilisateur Cet objet englobe les informations concernant un utilisateur

3 Candidat Cet objet englobe les informations concernant un candidat4 Moniteur Cet objet englobe les informations concernant un moniteur

30


5 Voiture Cet objet englobe les informations concernant une voiture

6 Séance Cet objet englobe les informations concernant les séances passé par les candidats

7 Séance code Cet objet englobe les informations concernant les séances du code

8 Séance conduite Cet objet englobe les informations concernant les séances du conduite

9 Payement Cet objet contient les acomptes déposé par les candidats10 Historique Cet objet englobe les informations concernant l’historique de

l’école11 Statistique Cet objet englobe les informations concernant les statistiques

de l’école{voiture, moniteurs, examen code et conduite}12 Examen Cet objet englobe les informations concernant les examen

des conduite et de code passé par les candidats13 Examen code Cet objet englobe les informations concernant les examen de

code passé par les candidats14 Examen conduite Cet objet englobe les informations concernant les examen de

conduite passé par les candidats

Tableau III. 1: Identification des classes

Dans notre cas on a les association suivantes:

Un administrateur va hériter les fonctionnalité de l’utilisateur

Un utilisateur peut gérer un ou plusieurs candidats.

Un utilisateur peut gérer un ou plusieurs moniteur.

Un utilisateur peut gérer une ou plusieurs séances

Les candidats peut être gérer par un seul utilisateur.

les moniteur peut être gérer par un seul utilisateur.

Un candidat peut passer une ou plusieurs séances de code ou de conduite

Les séance peut être séance de code ou de conduite

Un candidat peut passer un ou plusieurs examen.

Un candidat peut déposer un ou plusieurs payements.

Un moniteur peut faire une ou plusieurs séances de conduite .

Une séance de conduite est piloter par un seul moniteur et une seule voiture et

avec un seul candidat.

Une voiture peut être Gérer par un seul utilisateur.

Une voiture peut être conduite par un ou plusieurs moniteur.

L’historique est consulté que par un seul administrateur.

Les statistiques sont accessibles que par un seul administrateur.

31


L’administrateur peut afficher une ou plusieurs statistiques voitures.

L’administrateur peut afficher une ou plusieurs statistiques moniteur.

L’administrateur peut afficher une ou plusieurs statistiques des examens code.

L’administrateur peut afficher une ou plusieurs statistiques des examens

conduite.

d. Identification des attributs et des méthodes :

N° Classe Attributs Méthodes

1 Utilisateur Login S’authentifier()

PasswordAdministrateur Parametrer()

3 Candidat Cin Ajouter ( )Supprimer ( )Modifier ( ) Rechercher( )

NomPrenomDateTelAdress

5 Moniteur Cin Ajouter ( )Supprimer ( )Modifier ( ) Rechercher( )

NomPrénomDateTelAdresse

7 Voiture Matricule Ajouter ( )Supprimer ( )

Marque

8 Séance DateN°séanceNbre heureAcompteHeure début

9 Séance conduite Prix heure A

Prix heure B

Ajouter séance conduite()

32


10 Séance code Prix_heurecode Ajouter séance code()

11 Historique Critère Afficher historique code()Afficher historique conduite()

16 Statistiques Début Afficher statistiques examen codeAfficher statistiques examen conduiteAfficher statistiques voituresAfficher statistiques moniteurs

FinId

19 Examens Prix Ajouter examen code()Ajouter examen conduite()

DateRésultatIdExam

21 Payement Acompte_codepayer Valider Code()Valider Conduite()Acompte_codeapayer

Acompte_conduite payerAcompte_conduiteapayerDateN°payemen

Tableau III. 2: Identification des attributs et des méthodes

II.3. Conception des données : Modèle logique de données(MLD)

Candidat ( Cin, nom, prénom, date_naissance, adresse, tel).

Moniteur ( Cinm, nom, prénom, date naissance, adresse, tel ).

Séance Code (N°scode,#Cin, date, heure_debut, nbre_heure, acompte,prix_heure code).

SéanceConduite(N°sconduite,date, #Cin,heure_debu

t,nbreheure,#Cinm,#matricule,prixheureA,prixheureB).

33


Examen code(IdExamcode,#Cin, date,prix, résultat, salle).

Examen conduite(IdExamconduite ,#Cin, date, prix, résultat, date, N° liste, N°

convocation ).

Voiture ( Matricule, marque).

Utilisateur ( login, password).

Payement(N°payement,#Cin , datepayement, heure payement, Acompte_codeapyer,

Acompte_conduiteapayer, Acompte_codepayer, Acompte_conduitepayer).

III. Conclusion:

Nous avons utilisé le langage de modélisation UML (Unified Modeling Language) pour

établir les différents diagrammes, ce qui nous a permis d’extraire d’une part les différentes

fonctionnalités que doit offrir notre application aux différents acteurs, et d’autre part de

concevoir les classes .

Chapitre 4: Réalisation

I. Introduction :

Dans ce chapitre nous donnons tout d’abord un aperçu sur les outils de réalisation

utilisés. Nous allons présenter des images écran de notre application. Ces images sont

organisées selon les fonctionnalités offertes à l’utilisateur.

34


II. Environnement de développement :

II.1. Environnement matériel:

Pour réaliser notre application nous avons disposé d’un ordinateur pentium 4,

3,06GHZ, avec 1 GB de RAM et 300GO.

II.2. Environnement logiciel:

Les logiciels utilisés sont : Windows 7, Eclipse et StarUML.

Eclipse:

Eclipse IDE for Java Developers

Version: Helios Service Release 2

Java JDK 1.5

StarUml: est un logiciel libre de conception

Oracle 10 G : Oracle est un système de gestion de bases de données (SGBD),il fonctionne

sur beaucoup de plates-formes différentes, incluant linux, Solaris ,sunos , Windows

95,98,NT,2000 et xp. Les bases de données sont accessibles en utilisant des langages de

programmation tels que c, c++,c#,java, perl, PHP , python, une API spécifique est disponible

pour chacun d’entre eux.

III. Réalisation :

III.1. Organigramme :

35


Figure IV. 1: Organigramme de l’application

Notre application possède deux types de profils : un pour un simple utilisateur qui

permet de gérer les fonctionnalité suivantes( la gestion des candidats, la gestion des

moniteurs, la gestion des voitures, la gestion des séances , la vérification des états des

candidats et la connexion a l’ATTT), et un profil administrateur qui va hériter les tâches de

l’utilisateur et effectuer d’autres (effectuer des statistiques, consulter l’historiques et

paramétrer l’application) .

La figure « Figure IV. 1 » représente les modules fonctionnels de l’application qui

contient 10 modules . Chaque module contient des sous modules qui représentent les

différentes tâches a réaliser.

III.2. Interface d’accueil :

36

Accueil Authentification

Gestion candidats

Gestion SéancesGestion VoituresGestion moniteursEtat candidats

Connexion

Statistiques

Historiques

Paramètres

Aides

Ajouter

Modifier

Supprimer

Recherche

Afficher

Ajout code

Ajout conduite

Examen conduite

Examen code

Ajouter

Supprimer

Suivi voiture

Ajouter

Modifier

Supprimer

Recherche

Validé code

Validé conduite

Moniteur

Voiture

Code

Conduite

Code

Conduite


Figure IV. 2: Interface d'accueil

Cette interface « Figure IV. 2 » représente la page d’accueil de notre application. A partir

de cette interface l’administrateur ou l’utilisateur peut passer à son espace privé, après

authentification.

III.3. Interfaces utilisateur:

III.3.1. Gestion candidats:

37


Figure IV. 3: Gestion des candidats par l'utilisateur

L’utilisateur peut choisir selon ses besoins parmi les sous onglets :

« Ajouter candidat» : elle affiche les formulaire d’ajout . L’utilisateur doit remplir les

informations qui correspondant à un candidat et valider l’ajout à travers sur le bouton

« Ajouter ».

«Modifier candidat» : une zone de texte permet la saisie du CIN d’un candidat et en

cliquant sur rechercher, les informations correspond s’affiche dans une formulaire et

l’utilisateur peut effectuer les modification nécessaire et valider.

«Supprimer candidat» : une zone de texte permet la saisie du CIN d’un candidat et en

cliquant sur rechercher, les informations corresponds au CIN vont être afficher . L’utlisateur

peut valider la suppression en cliquant sur le bouton « Supprimer ».

«Recherche candidat» : une zone de texte s’affiche, l’ utilisateur saisie le N° CIN de

candidat et en clique sur rechercher. Une vérification s’effectue au niveau de la base de

38


donnée : si le candidat est déjà inscrit les informations correspondante sera afficher si non une

message d’erreur s’affiche.

«Afficher candidat» en cliquant sur cet onglet tout les candidats qui sont déjà inscrit

seront affichés.

III.3.2. Gestion des séances :

Figure IV. 4: Gestion des séances par l'utilisateur

L’onglet « Gestion séances » : est un élément qui contient des sous onglets représentant les

différentes opérations à effectuer.

« Ajouter séances code » : un formulaire sera afficher. Après remplissage du formulaire,

l’enregistrement s’effectue en cliquant sur le bouton « Ajouter ».

De même pour « Ajouter séances conduite », « examen code » et « examen conduite » l’

utilisateur peut sauvegarder les résultats de ses candidats en remplissant les champs du

formulaire.

39


III.3.3. Gestion des voitures :

Figure IV. 5: Gestion des voitures par l'utilisateur

Il est très utile d’utiliser cette onglet pour la meilleur gestion des ressources.

L’utilisateur peut choisir parmi les fonctions suivantes :

« Ajouter voiture »:pour ajouter une voiture on doit renseigner les caractéristiques

d’une voiture à travers le formulaire illustrée par la figure « Figure IV. 5 ».

« Supprimer voiture »la suppression est possible à travers le N° de matricule.

« Suivi voiture » pour enregistrer le suivi d’une voiture on doit remplir les champs, ses

informations sont utile pour déterminer le rendement d’une voiture.

III.3.4. Gestion Moniteur:

40


Figure IV. 6: Gestion Moniteur par l'utilisateur

Cette interface permet à l’ utilisateur de gérer la liste des moniteurs. Elle comprend les

fonctionnalités d’ajout, de modification de suppression et de recherche d’un moniteur.

III.3.5. Etat candidat :

41


Figure IV. 7: Etat Candidat contrôler par l'utilisateur

Pour voir si un candidat est autorisé pour passer un examen de code, il doit choisir

l’onglet« candidat validé code ». La liste des candidats qui ont effectué leur payement dues

et qui fait sont donc autorisés à passer l’examen de code sera affichée.

De même l’onglet « Candidat validé conduite» pour lister tous les candidats qui sont

autorisés pour passer la conduite.

42


III.3.6. Connexion:

Figure IV. 8: connexion effecteur par l'utilisateur

« Connexion ATTT» : cet onglet permet de se connecter au site de l’ATTT (Agence

Technique des Transports Terrestre) pour inscrire les candidats au niveau de l’agence et

permet au professionnel de consulter leur compte.

III.4. Interfaces administrateur:

Certaines opérations dans l’application, font la préoccupation, seulement et strictement,

de l’administrateur. Ce dernier a la possibilité de paramétrer l’application ,calculer le

statistique et afficher l’historique.

43


III.4.1. Statistiques :

Figure IV. 9: Statistiques effectuer par l'administrateur

« Statistiques Moniteur» :Cette rubrique facilite à l’administrateur la tâche de calcul du

rendement de ses moniteurs, elle permet de calculer les heurs effectués pour chaque moniteur

sur une période donnée. Les informations seront affichés selon une date et qui affichera le

nombre d’heure effectuer a cette date et le montant payer puis il affichera la totalité des

heures et des montants payés.

« Statistiques Voiture» le suivi des voitures est disponible à travers cette onglet qui va

afficher le rondement d’une voiture à une date donnée.

« Statistiques examen» : une liste des candidat qui ont passé les examens sera afficher

selon une date précis. Elle permet de calculer et d’afficher le taux de réussite au niveau code

et conduite (1 :les taux des réussite des candidats pour la première fois, 2:les taux des

réussite des candidats pour la deuxième fois,3 :les taux des réussite des candidats pour la

troisième fois,4 :les taux des réussite des candidats pour la quatrième fois,5 :les taux des

réussite des candidats pour la cinquième fois).

44


III.4.2. Historiques :

Figure IV. 10: Historiques consulter par l'administrateur

« Historique code» pour déterminer l’historique détaillée d’un candidat qui a passer un

examen code qui sera organisée selon la date, nombre d’heure, le montant payer.

« Historique conduite» pour déterminer l’historique détaillée d’un candidat qui a passer un

examen conduite qui sera organisée selon la date, nombre d’heure, le montant payer.

45


III.4.3. Paramètres:

Figure IV. 11: Paramètre régler par l'administrateur

Cette interface donne la main à l’administrateur de paramétrer son application.

L’onglet « modifier prix heure » offre la possibilité de modifier le prix de l’heure de code

ou de conduite.

L’onglet « modifier password » offre la possibilité de modifier les mots de passe de

l’utilisateur et de l’administrateur.

IV. Conclusion :

Dans ce dernier chapitre nous avons présenté l’environnement de développement, les

technologies utilisées, quelques interfaces commentées de l’application.

46


Conclusion et Perspectives

Ce projet de fin d’étude a été pour nous une précieuse occasion pour développer notre

savoir, notre savoir faire et notre savoir être. En effet, on a pu approfondir nos connaissances,

acquérir de nouvelles qui ont enrichi nos capacités d’observations, d’analyse, de créativité, de

rédaction et de programmation.

La réalisation de cette application nous a permis de pratiquer la vie professionnelle,

maitriser de nouveaux outils de développement.

Afin de promouvoir notre projet, nous visons l’améliorer en offrant la possibilité

d’imprimer les fiches des candidats.

47

rapport pfe

Documents