Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)

Mémoire de Stage de Fin
d’Etudes
Présenté en vue de l’obtention de
La Licence Appliquée en Sciences et Techniques de
l’Information et de Communications
Par
Rahma Ghali
« Conception et développement d’une application de gestion des candidatures et épreuves
d’évaluations (eCandidat) »
Effectué à :
Enterprise: Faculté des Sciences de Tunis
Encadreur: Mr. Riadh Bouhouch
Soutenu le……. devant la commission d'examen composée de :
MR. RIADH BOUHOUCH PRESIDENT
……………….. MEMBRE
MR. RIADH BOUHOUCH ENCADRANT
Année Universitaire : 2012 / 2013
République Tunisienne
*****
Ministère de l’Enseignement Supérieur et de la Recherche
Scientifique
*****
Université Virtuelle de Tunis

Université Virtuelle de Tunis
14 rue Yahia Ibn Omar 1082 Mutuelleville Tunis
Tél : +216 71 28 99 81 / +216 71 89 17 31 Fax : +216 71
89 26 25- www.uvt.rnu.tn
Mots clefs : JEE, Netbeans, MySql Workbench, Gestion de candidature, JSF2, JPA,
Primefaces
Mon stage a était réalisée pour le compte de la faculté des Sciences de Tunis. Le
but était de concevoir et de développer une application de gestion de candidature
et épreuves d’évaluations visant a gérer informatiquement les candidatures des
étudiants (inscrits ou pas a l’FST) pour les procédures nécessitant une commission
d’accès de l’Université, permettant d’éviter la nécessité d’intervention humaine sur
tout le processus de sélection.
Ce stage était principalement destiné à la mise en place d’une application basée sur
deux volets : FrontOffice (inscription, suivi candidature, etc..) et BackOffice
(gérer la gestion des candidatures, gestion personnels, gestion d’accès, etc.)
Keywords: JEE, Netbeans, MySql Workbench, application management, JSF2, JPA,
Primefaces
My internship was conducted on behalf of the Faculty of Sciences of Tunisia.
My goal was to design and develop a management application of candidacy and
evaluation tests aimed to manage computer applications students (enrolled or not
has FST) for procedures requiring access committee of the University, to avoid the
need for human intervention throughout the selection process.
This internship was mainly for the development of an application based on two
components: FrontOffice (registration, tracking application, etc.) and BackOffice
(manage applications management, personnel management, access management,
etc.).

Dédicaces
Je dédie ce modeste travail :
A mes parents, Naoufel & Aicha, avec toute ma reconnaissance et ma
gratitude pour leurs sacrifices.
A mes deux sœurs Nour el Houda et Chahrazed, avec tous mes vœux de les
voir réussir dans leurs vies.
A mon fiancé Chaker, à qui je dois une grande part de la réussite de mon
projet grâce à son soutien et à sa compréhension et à qui je souhaite tout le
bonheur du monde, je remercie également toute sa famille.
A mes grands-parents, a mes oncles et tantes : Lamia, ilhem, Adel,
chokriAmel, Anis, Hamda, Ridha et Kamel.
A toute ma famille
A mes ami(e)s, à qui je souhaite le sucés, en les remerciant pour l’amitié qui
nous a toujours unis.
A tous ceux qui me sont chers.
Et pour finir, à ma chère amie Mouna, avec qui j’ai partagé des moments
Spécieux et à qui je souhaite la réussite et el bonheur
Ainsi qu’à toute sa famille.
Paroles qui me tiennent à cœur : « De l’union » « si » avec « mais » naquit
enfant nommé « jamais » il n’y a pas de « si » ni « mais »
Il faut réussir » NAPOLEON I
Rahma Ghali

Remerciements
C’est d’abord grâce à DIEU, que je voie ce projet de fin d’étude s’achever.
Comme l’a dit Sir Issac Newton :
« Si j’ai pu voir plus loin,
C’est en montant sur les épaules des géants ».
Je tiens à adresser mes sincères remerciements :
A Mr Riadh Bouhouch, mon encadreur et mon professeur à l’UVT
Dont je suis particulièrement redevable.
Je le remercie pour sa patience, pour le suivi ininterrompue de ce projet,
Pour ses conseils judicieux qui m’ont aidé à mener à bout ce travail,
Et son appuie toute au long de ce projet.
A tous les membres du jury,
A tous ceux qui, directement ou indirectement, ont aidé à la
Finalisation de ce travail.
Qu’ils trouvent ici l’expression de ma profonde gratitude.
Rahma Ghali

Tables des Matières
INTRODUCTION GENERALE....................................................................................................................................... 1
CHAPITRE I : ANALYSE ET SPECIFICATION DES BESOINS.................................................................................................... 2
I. Introduction de l’entreprise................................................................................................................................. 3
II. Etude de l’existant............................................................................................................................................... 3
1. Modalités et processus d’admission .................................................................................................................................5
2. Critiques de l’existant........................................................................................................................................................6
3. Risque potentiel.................................................................................................................................................................6
III. Identification des besoins (fonctionnelles/non fonctionnels)............................................................................... 8
1. Analyse des besoins...........................................................................................................................................................8
2. Besoins fonctionnelles.......................................................................................................................................................8
3. Besoins non fonctionnelles................................................................................................................................................9
4. Technologie déployée......................................................................................................................................................10
IV. Best Practice ..................................................................................................................................................... 10
1. Les « Best Practice » Open source...................................................................................................................................11
2. Les « Best Practice » propriétaires ..................................................................................................................................14
3. Le choix de « Best Practice » pour eCandidat...............................................................................................................15
V. Critiques............................................................................................................................................................ 16
VI. Présentation de projet (Ma mission)................................................................................................................. 17
VII. Gestion de la qualité projet........................................................................................................................... 17
1. Diagramme de Gantt........................................................................................................................................................17
2. Templates ........................................................................................................................................................................19
2.1. Les Interfaces.........................................................................................................................................................19
a. Page Index.xhtml ...................................................................................................................................................19
b. Page Presentation.xhtml.........................................................................................................................................20
c. Page Formation.xhtml............................................................................................................................................21
d. Page Concours.xhtml.............................................................................................................................................22
e. Page Administration.xhtml ....................................................................................................................................23
f. Page Contact.xhtml................................................................................................................................................24
2.2. Les PV des réunions...............................................................................................................................................25
CHAPITRE II : LA CONCEPTION........................................................................................................................................ 26
I. La conception générale ..................................................................................................................................... 27
1. Cycle de vie.....................................................................................................................................................................27
1.1. Les différents modèles de cycle de vie...................................................................................................................28
1.2. Choix de cycle de vie en « Y » .............................................................................................................................32
1.3. Récapitulation : Les tâches du projet par activités et par phases...........................................................................33
2. Méthodologie et langage de modélisation .......................................................................................................................34
2.1. Présentation UML et MERISE..............................................................................................................................34
2.2. Techniques d’implémentation UML, Pourquoi ?...................................................................................................35
2.3. Les Différents diagrammes d’UML.......................................................................................................................36
3. Description des scénarios du système..............................................................................................................................37
3.1. Recherche des acteurs et des cas d’utilisations ......................................................................................................38
a. Acteurs ..................................................................................................................................................................38
b. La description des cas d’utilisation........................................................................................................................39
B.1. Cas d’utilisation : « Authentification »…………………………………………………………………….39
B.1.1. Description textuelle : cas d’utilisation « Authentification »…………………………………………..40
B.1.2. Diagramme d’activité : « Authentification »……………………………………………………………40
B.2. Cas d’utilisation : « Maintenance système »………………………………………………………………..41
B.2.1. Description textuelle : cas d’utilisation « Maintenance système »……………………………………..41
B.2.2. Diagramme d’activité : « Maintenance système »……………………………………………………..42
B.3. Cas d’utilisation : Gestion des candidatures………………………………………………………………..43
B.3.1. Description textuelle : cas d’utilisation « Gestion des candidatures »………………………………...43
B.4. Cas d’utilisation : dépôt des candidatures…………………………………………………………………44

B.4.1. Description textuelle : cas d’utilisation « Dépôt candidature »…………………………….45
B.4.2. Diagramme d’activité : « Dépôt candidature »…………………………………………….46
B.4.3. Diagramme d’activité : « Formulaire d’inscription –création compte candidat »…………………….47
B.5. Cas d’utilisation : « Gestion des utilisateurs »……………………………………………………………...47
B.5.1. Description textuelle : cas d’utilisation « Gestion des utilisateurs »…………………………………..48
B.6. Cas d’utilisation : « Gestion des Tests »…………………………………………………………………....49
B.6.1. Description textuelle : cas d’utilisation « Gestion des Tests»………………………………………….49
B.6.2. Diagramme d’activité : « Gestion des Tests »………………………………………………………….50
B.7. Cas d’utilisation : « Gestion ville »………………………………………………………………………….51
B.7.1. Description textuelle : cas d’utilisation « Gestion des villes»………………………………………….51
B.7.2. Diagramme d’activité : « Gestion des villes »………………………………………………………....52
I. La conception détaillée…………………………………………………………………………………………………53
1. Les Diagrammes de séquences………………………………………………………………………………………………53
1.1. Diagramme de séquence : « Authentification »……………………………………………………………………53
1.2. Diagramme de séquence : « Gestion des candidatures »........................................................................................54
1.3. Diagramme de séquence : « Gestion des Tests »……………………………………………………………………54
2. Diagramme de classe.......................................................................................................................................................55
3. La base de données..........................................................................................................................................................56
3.1. Implémentation de la base de données...................................................................................................................56
3.2. Génération script SQL ...........................................................................................................................................57
CHAPITRE III : DEVELOPPEMENT ..........................................................................................................................................................60
I. Identification des besoins Hardware....................................................................................................................................61
II. Identification des besoins Software ......................................................................................................................................61
III. Configuration de l’environnement de travail .......................................................................................................................61
1. Fichiers de configuration.................................................................................................................................................61
2. Packages..........................................................................................................................................................................63
3. Base de données et serveur d’application ........................................................................................................................64
IV. Plateforme JEE ....................................................................................................................................................................65
1. Langage ...........................................................................................................................................................................65
2. Framework.......................................................................................................................................................................66
2.1. Framework de présentation ..........................................................................................................................................66
a. JSF2 .......................................................................................................................................................................66
b. Primefaces..............................................................................................................................................................67
2.2. API de persistance ......................................................................................................................................................68
2.3. Framework de sécurité ……………………………………………………………………………………………….69
2.4. Framework JavaMail………………………………………………………………………………………………...70
3. Plugin Jasper Report........................................................................................................................................................71
V. Architecture de l’application................................................................................................................................................73
VI. Gestion d’erreur...................................................................................................................................................................74
VII. Présentation de quelques interfaces Administrateur .......................................................................................................75
CONCLUSION ET PERSPECTIVES.................................................................................................................................................75
NETOGRAPHIE
LISTE DES FIGURES
LISTE DES TABLEAUX
LISTE DES ABREVIATIONS
ANNEXES

Introduction Générale
Pour mon stage de PFE, mon encadreur pédagogique Mr. Riadh Bouhouch m’a proposé de faire la
conception, et le développement d’ « une application de Gestion de Candidature et Test
d’évaluation » pour le compte de la Faculté des Sciences de Tunis que j’ai nommée eCandidat.
Ce présent rapport sera structuré en trois grandes parties :
Dans la premier partie «Analyse et spécification des besoins», je présente le cadre de mon
Stage de PFE à savoir l’organisme de la Faculté des Sciences de Tunis (FST), je propose d’analyser
l’existant, d’élaborer un cahier des charges en illustrant les différents besoins fonctionnelles et non
fonctionnelles et les technologies déployées au niveau de cette application.
Aussi j’ai réservé une partie pour identifier les meilleures pratique « Les Best Practice » de manière à
choisir l’implémentation qui s’adapte le mieux a cette outil de gestion des candidatures et test
d’évaluation. Ensuite j’ai traité la section « MQP » dite Gestion de qualité projet, qui expose la
bonne gestion du projet an terme de respect de délais de livraison de l’application et les différents
Template de ce dernier.
Dans la seconde partie intitulée la «Conception », j’ai bien parlé sur la conception à la fois générale
et détaillée en proposant et en appliquant le cycle de vie que j’ai jugé, pour certaine raison, que c’est
le plus adéquats a mon application, ainsi que la méthodologie de conception dite MVC en partant
sur le principe de séparation des données, la présentation et les traitements, et enfin pour la
conception détaillée j’ai déployer les cas d’utilisation, les diagrammes d’activités, les diagrammes
de Séquence, ainsi que le diagramme de classe complet.
Dans le dernier chapitre intitulé «Développement», j’ai présenté l’environnement matériel et
logiciel, le passage vers le schéma relationnel et quelques composantes de l’application réalisées.
Enfin, j’ai clôturé ledit rapport de fin d’étude par une conclusion dans laquelle j’ai résumé ma
solution et exposant quelques perspectives futures.

[Gestion de candidature et test d’évaluation]
[UVT - FST]
[Auteur : Rahma Ghali]
[2]
Chapitre I : Analyse et spécification des besoins

[UVT - FST]
[3]
Introduction
Je commence ce chapitre par la présentation générale de la Faculté des Sciences de Tunis.
Je présenterai ensuite, la spécification de l’application par la description de la situation
actuelle, chose qui me sert pour la définition de la problématique et la détermination des
solutions possibles aussi je vais élaborer une étude sur les risques potentiels de l’existant.
J’aboutirais en dernier lieu, à la spécification des besoins fonctionnels et non fonctionnels.
II. Introduction de l’entreprise
La Faculté des Sciences de Tunis a été fondée en 1960 dans les locaux de l'Institut des Hautes
Etudes de Tunis, qui dépendait de l'Université de Paris, depuis 1945.
Dès sa création, la FST s'est vue attribuer la mission de former ses étudiants en vue de
l'obtention des licences dans les différentes disciplines scientifique (Mathématiques,
Physique, Chimie et Sciences Naturelles).
Une filière d'enseignement d'ingéniorat a vu le jour à la FST, d'abord en Informatique puis en
Chimie et en Géologie. Enfin, dès les débuts des années 2000, il a été crée à la FST, un cycle
préparatoire aux Etudes d'Ingénieurs de deux années. Depuis sa création, la FST n'a cessé
d'évoluer sur tous les niveaux. En absence de changement majeur, sa mission n'a cessé d'être
élargie et diversifiée
En moins d'un demi-siècle d'existence, la FST a pu contribuer au développement de la
Tunisie et elle le fait encore. Il faut souligner également que plusieurs générations
d'ingénieurs et d'enseignants du secondaire et du supérieur de tout le pays lui doivent une
formation en totalité ou en partie.
III. Etude de l’existant
Dans un premier temps, pour des raisons de compréhension du système, je vais m’intéressé
au processus d’admission de l’université actuel pour savoir ce qu’il est nécessaire pour mettre
en place mon outil de « Gestion des candidatures et test d’évaluation »1
.
1
GCTE : Gestion de candidature et test d »évaluation

[UVT - FST]
[4]
Dans un deuxième temps, je vais me penché sur le travail que j’ai effectué pour le compte de
l’FST2
, de son avancement et de son impact. J’apporterai dans ce rapport les solutions que
j’ai proposées et mit en place.
2
FST ; Faculté des sciences de Tunis

[UVT - FST]
[5]
1. Modalités et processus d’admission
Il existe un seule mode de candidature :
Dépôt de dossier « papier » auprès des différents départements de l’FST, composée de documents a
remplirent manuellement qui sont disponible en ligne sur le site de l’université et à déposer
impérativement dans les délais impartis avec les pièces justificative demandées.
Figure 1 Diagramme générale d’admission
Telechargement fiche de
renseignements &
demande d'inscription
Dépots des dossiers
complets aux
départements
aucun envoi par la
poste n'est accepté
(attribution d'un reçu
lors du dépôt )
Attente affichage
resultat apérs réunion
commission
Réception aprés dépôt
traitement candidature
(vérification dossier
complets ou pas)
examen des
candidatures par une
commission
Délibértaion aprés
réunion commission
Ouverture inscription aux
Licences, Cycle préparatoire
et Cycle ingénieur
FO
BD
BOFront
Office
Base de
Donnée
s
Back
Office
Archives /
Bibliothèque
 Papier

[UVT - FST]
[6]
2. Critiques de l’existant
Processus d’admission Points Fort Points Faible
Modalités d’inscription Disponibilité des documents
qui composent le dossier en
ligne
Tirage et remplissage manuelle
Dépôt dossier - Nécessité de se déplacer, aucun
envoie postal n’est permis
Réinscription (étudiant
redoublant)
Disponibilité des documents
ligne
* Nécessité de se déplacer pour
avoir le détail
* Tirage et remplissage
manuelle
Réorientation Disponibilité des documents
ligne
* Nécessité de se déplacer pour
avoir le détail
* Tirage et remplissage
manuelle
Résultat Affichage en ligne pour
quelques sections
Nécessité de se déplacer pour
avoir le détail
Etat dossier (refus, en attente
de traitement, incomplet,
etc.…)
- Nécessité de se déplacer pour
avoir le suivi de sa candidature
Réclamation résultat
candidature
- Nécessité de se déplacer pour
déposer une fiche réclamation
au bureau d’ordre
Tableau 1 : Tableau récapitulative pour la critique de l'existant
Nécessité l’intervention humaine sur tout le processus de sélection.
Gaspillage de temps.
3. Risque potentiel
Perte de dossier suite au nombre volumineux des candidatures reçu.
Perte de dossier en cas d’archivage.
Erreur de saisie de la part du candidat.
Le système ne permet que très peu d'automatisation et oblige de nombreuses opérations
Fastidieuses comme le déplacement pour déposer le dossier de candidature (problème crée en
période d’été).
Organisation : pas de gestion de visibilité, protections et contrôles des documents.
Pas de transparence et traçage.

[UVT - FST]
[7]
En Bref,
En générale les méthodes
classiques de dépôt d‘une
candidature consiste à consulter
le site de la faculté Tunisienne
ou le site officiel du ministère
de l’enseignement supérieur
pour le l’ouverture des
inscriptions aux différents
filières afin de postuler son
dossier à caractère « tout
papier ».
Cette méthode et loin d’être
satisfaisante et pratiques pour
les différents acteurs qui
touchent de loin ou de prés au
processus. Coté candidat le
processus et très long et génère
des conflits, coté administration
c’est un vrai gaspillage de
temps avec ces taches énormes
et prise de décision retardée.
D’où vient la nécessité de
trouver une méthode ou un outil
rapide et efficace : une
application de gestion de
candidature et test d’évaluation
La dénomination donnée est
eCandidat.

[UVT - FST]
[8]
IV. Identification des besoins (fonctionnelles/non fonctionnels)
Dans le cadre de mon projet de fin d’études, mon encadreur pédagogique Mr. Riadh
Bouhouch m’a proposée de concevoir et réaliser un logiciel en utilisant la technologie JEE
dont l’idée m’a parue très intéressante.
1. Analyse des besoins
L’objective de mon application et de gérer informatiquement les candidatures des étudiants
(inscrits ou pas a l’FST) pour les procédures nécessitant une commission d’accès de la faculté
et d’ajuter un volet « Test d’évaluation » qui permettras une meilleur analyse des capacités et
de savoir faire afin de mieux positionner et orienter le candidat.
2. Besoins fonctionnelles
Cet outil permettra a l’FST à la fois d'analyser, de suivre et d'agir ponctuellement ou en temps
réel sur les évolutions ayant lieu sur son ouverture de candidature et d’effectuer un test
d’évaluation. eCandidat doit respecter les conditions fonctionnelles suivantes :
Mode de candidature : "Partiellement électronique".
Passage de test d’évaluation (test de niveau) pour les candidats retenue afin de mieux
les orienter.
Centraliser l'information et les données concernant la gestion des candidatures.
Automatisation des taches, et faciliter le processus d’inscription afin de l’accélérer et de
diminuer le risque d’erreur (dossier incomplet, perte, non réception).
Diminuer le temps de traitement des dossiers des candidatures.
Créer un suivi des candidatures.
Partager plus facilement l’information des candidatures avec les responsables de
services d’inscription et la commission chargée de la sélection.
Introduire un aperçu sur les statistiques et reporting.
Introduire un système d’authentification pour accéder aux services (suivi candidature,
passage test) basé sur le profil de l’utilisateur (administrateur, candidat).
Implémentation d’une interface simple, ergonomique et facile à utiliser.

[UVT - FST]
[9]
Front Office
Gestion d’inscription
Gestion modification profil de candidat
Gestion Suivi candidature
Gestion d’authentification (suivi candidature, passage épreuves, modification profil)
Back Office
Gestion de traitement des dossiers déposé
Gestion des épreuves
Gestion d’administration
Gestion de configuration
Gérer les droits d’accès
Ajout / Modification / Suppression (Utilisateurs, Filières)
MAJ date / documents d’inscription / Téléchargement des Documents d’inscription
Gestion de la commission (création, ajout, état etc..).
Gestion état candidature (refusé, approuvée, en attente, rétracté)
Gestion de reporting et statistique
Gestion des réclamations
3. Besoins non fonctionnelles
Avoir un IHM3, ergonomique et pratique à utiliser=> gestion d’utilisabilitè
Application écrite dans un langage portable, avec des librairies tierces portables et/ou
remplaçables aisément=> gestion de performance
Etre compatible avec n’importe quel système d’exploitation et navigateur web=> gestion
compatibilité
Sécurité des informations qui ne devront pas être accessibles à tout le monde => gestion de
sécurité
3
IHM : Interface homme machine

[UVT - FST]
[10]
4. Technologie déployée
Figure 2:Les technologies déployées pour la conception de eCandidat
V. Best Practice
La notion de logiciel libre a été inventée par la FSF4
fondée par Richard Stallmann en 1982.
Elle signifie que les utilisateurs d’un logiciel sont libres :
* D’utiliser le programme.
* D'en étudier le fonctionnement, de l'améliorer, le modifier et de publier ces
améliorations.
* De redistribuer des copies, gratuitement ou non : toute entreprise ou particulier est
donc autorisé à les commercialiser.
La section qui suit illustre quelques exemples des Best Pactises, utilisé dans ce domaine.
4
FSF : Free Software Fundation
Langage de
programmat
ion : JEE
Base de
données :
MySQL
Workbench
Frameworks
: JSF2,
PrimeFace,
JPA,
IDE :
Netbeans
7.2.1
JASS
(Droits
d'accées)

[UVT - FST]
[11]
1. Les « Best Practice » Open source
Moodle : acronym de “Modular Object-Oriented Dynamic Learning Environment”
Figure 3: "Best practice" MOODLE
La gestion des utilisateurs :
La plateforme dispose de plusieurs profils d'utilisateurs:
* Ces profils peuvent être renommée (apprenant en étudiant, agent administrative...)
* L'inscription des utilisateurs et l'attribution des rôles à chacun est très simple.
* Chaque utilisateur devra se connecter au moyen d'un identifiant et d'un mot de passe pour
ensuite avoir accès aux rubriques définies par l'administrateur.
La sécurité des contenus
La sécurité des accès nous amène à la sécurité des contenus. Seules les personnes autorisées
auront donc accès aux ressources et aux activités.
Les rapports statistiques
La plateforme offre la possibilité de suivre l'évolution des apprenants dans leur ensemble ou
individuellement.
Possibilité de sélectionner les critères voulues pour pouvoir afficher simplement les
statistiques de la plateforme.
Moodle
La gestion
des
utilisateurs
La sécurité
des
contenus
Les
rapports
statistiques

[UVT - FST]
[12]
Exemple d’inscription au sein de l’ENIT « Ecole Nationale d’Ingénieurs de Tunis »
Le processus d’inscription et très simple, j’ai de ma part effectué un test d’admission qui sera
bien détaillée dans les figures ci-dessous (pas possibilité de visualiser ne le reste de
processus car les inscriptions sont clôturées pour cette année).
Figure 4: Processus d'inscription ENIT
ouverture compte
(saisie formulaire)
Confirmation des
données saisies
confirmation de
création compte avec
redirection pour la
connexion

[UVT - FST]
[13]

[UVT - FST]
[14]
2. Les « Best Practice » propriétaires
ERP : Enterprise Resource Planning
Le principe fondateur d'un PGI/ERP 5
est de construire des applications informatiques :
de manière modulaire et intégrée au niveau des traitements offerts.
de manière rigoureuse et cohérente au niveau des données gérées.
Avantage :
Optimisation des processus de gestion
Intégrité et unicité du Système d'information
Maîtrise des coûts et des délais de mise en œuvre et de déploiement
Inconvénients :
Mise en œuvre pouvant être complexe
Coût élevé de 300 000 € minimum pour un progiciel fiable et de qualité
5
PGI/ERP : Progiciel de Gestion Intégré / Enterprise Resource Planning

[UVT - FST]
[15]
3. Le choix de « Best Practice » pour eCandidat
IDE : Netbeans
Figure 5: IDE Netbeans
SGBD : MySql Workbench
Figure 6: SGBD MySql Worbench
utilise des
frameworks
JSF2 et
primeface
développerment des
applications Web, à
base de HTML 5 et
de Javascript
faire de la
manipulation
de données
C’est
GRATUIT
développement
avec des
langages et des
technologies
multiples
architecture logicielle qui
le rend extrêmement rapide
et facile à personnaliser
sa rapidité, sa robustesse et
sa facilité d'utilisation et
d'administration
sa documentation très
complète et bien construite
C’est GRATUIT

[UVT - FST]
[16]
Méthodologie de conception : MVC « Model View Control »
VI. Critiques
L’application eCandidat et un outil permettant à la fois d'analyser, de suivre et d'agir
ponctuellement ou en temps réel sur les évolutions ayant lieu sur le processus de candidature
et les tests d’évaluations : gérant a la fois les inscriptions, les invitations à passer les tests, la
visualisation des résultats, gestion des dossiers, gestion d’administration et de configuration
de l’outil.
Le développement de l’application est centré sur l’automatisation des tâches et pour l’étudiant
que pour l’administration de l’université, faciliter l’accès, le temps de réponse et le
trainement des candidatures postées.
Ce projet intitulé eCandidat est conçu grâce à des environnements Open Source assez facile
a manipuler et permettant une meilleur optimisation du résultat attendue de cette application.
le contrôleur, reçoit
les actions de
l’utilisateur et gère
la répartition des
traitements entre la
vue et le modèle
C’est atout pour
les frameworks
utiliser (JSF..)
Le modèle représente la
partie métier de
l’application : on y
retrouve les états et la
logique de l’application
la vue, est la partie
graphique, dans
laquelle seul
l’affichage est
géré
Figure 7: Modèle MVC

[UVT - FST]
[17]
VII. Présentation de projet (Ma mission)
Comme déjà évoquée, dans ce qui précède, ce projet a était proposée par mon encadreur
pédagogique Mr. Riadh Bouhouch. Suite à des réunions régulières avec Mr. Riadh Bouhouch
on a pu identifier ma mission pour la mise en place de cette application.
Le but étant de développer et de concevoir 3 volets du projet en respectant les contraintes
fonctionnelles, ergonomiques et respects des normes de chaque volet à savoir :
Partie Front Office (on aura le détail dans la partie conception)
Partie Back Office (on aura le détail dans la partie conception)
Partie SGBD (on aura le détail dans la partie conception)
VIII. Gestion de la qualité projet
La gestion de la qualité du projet comprend les processus et les activités réalisatrices qui
déterminent la politique qualité, les objectifs et les responsabilités, afin que le projet réponde
aux besoins pour lesquels il a été entrepris. Il met en œuvre aussi le système de gestion, des
procédures, en fonction des besoins.
La mise en œuvre d’activités d’amélioration continue des processus tout au long du projet.
1. Diagramme de Gantt
Le diagramme de Gantt repose sur une idée simple. Il s'agit simplement de faire figurer sur un
document les différentes phases qui se succèdent dans la réalisation d'un projet. Le
diagramme va permettre de voir quand commence une tâche, quand elle se termine, et quelle
est sa durée.
Ci-dessous une illustration de diagramme de Gantt relative a eCandidat :

[UVT - FST]
[18]
Figure 8 : Diagramme de Gantt

[UVT - FST]
[19]
2. Templates
J’ai préparé les interfaces appropriées, à l’aide du logiciel PHOTOSHOP ainsi que la librairie
PRIMEFACES. Ensuite, j’ai préparé quelques animations avec FLASH CS3. La gamme des
couleurs que j’ai choisies et en parfaite harmonie (le bleu, le marron, et l’orange).
2.1. Les Interfaces
a. Page Index.xhtml
Figure 9: Page Index

[UVT - FST]
[20]
b. Page Presentation.xhtml
Figure 10: Page Présentation

[UVT - FST]
[21]
c. Page Formation.xhtml
Figure 11: Page Formation

[UVT - FST]
[22]
d. Page Concours.xhtml
Figure 12: Page Concours
En cliquant sur
l’un des doc à
télécharger un
lightBox s’ouvre

[UVT - FST]
[23]
e. Page Administration.xhtml
Figure 13: Page Administration

[UVT - FST]
[24]
f. Page Contact.xhtml
Figure 14: Page Contact

[UVT - FST]
[25]
2.2. Les PV des réunions
2.1.1. Les présentations
Conclusion
A la fin de ce chapitre j’ai pu dégager les différents besoins fonctionnels, ainsi que les
diverses contraintes ergonomiques et des procédures, afin de mieux comprendre les
fonctionnalités et procéder à une réalisation et conception détaillée et ce, grâce à une analyse
interne et externe.

[UVT - FST]
[26]
Chapitre II : La conception

[UVT - FST]
[27]
Introduction
La partie conception permet de mettre en place l’architecture du logiciel et définie les
interfaces entre les différents modules. Le but étant d’exposer une documentation complète
sur les différentes architectures de chaque module qui sera implémentée et testé au niveau de
la partie développement, de ce faite la conception me permettra de relevée les différentes
contraintes auxquels chaque architecture doit respecter et de spécifier les normes de
communication entre eux.
I. La conception générale
La conception générale comporte deux sections primordiales à savoir, le cycle de vie de mon
projet qui permet de décrire les différentes phases de ce dernier (la création, la distribution et
la disparition). Ensuite je vais exposer la partie méthodologie et langage de modélisation.
1. Cycle de vie
Le « cycle de vie d'un logiciel » (en anglais software lifecycle) ou méthode de
développement, sélectionne et identifie toutes les étapes du développement d'un logiciel, dé
sa conception en allant jusqu'à sa disparition. L'objectif étant de définir des balises
intermédiaires permettant la validation du la partie développement logiciel, c'est-à-dire si le
logiciel réponds aux besoins exprimés, et la vérification du processus de développement, et
si les méthodes mises en œuvre respectent bien les contraintes prédéfinies auparavant.
Dans ce qui suit je vais illustrer les différents cycles de vie qui existent en dégageant leurs
avantages et inconvénients d’une part, d’autre part je vais exposer le cycle de vie adéquat à
l’application eCandidat.

[UVT - FST]
[28]
1.1. Les différents modèles de cycle de vie
Modèle en cascade
Modèle en V
Modèle en W
Le modèle en spirale
Le cycle RAD (RapidApplication Development)
XP (eXtreme Programming)
Les cycles ERP (EntrepriseResource Planning
ou Progiciel de Gestion Intégré)
Le modèle de la transformation automatique
(transform model)
Analyse des différents modèles de cycle de vie
Les Méthodes traditionnelles
Modèle en « cascade »
Principes :
Chaque phase doit se terminer avant d’entamer
la suivante.
Avantage :
Facilité de planification des étapes et
des Délais
Contrôle facile
Simple et logique
Inconvénients :
Incapacité de revenir en arrière
Nécessite une phase de conception
parfaite
De moins en moins de droit à l’erreur
avec l’avancement du projet,
notamment lors des tests
Méthodes traditionnelle
Méthodes agiles
Méthodes spécifiques

[UVT - FST]
[29]
Modèle en « V »
Principes :
Amélioration du Cascade, l’objectif étant de
réduire la perte de visibilité au niveau de
l’avancement du projet.
Avantage :
La qualité de la mise en œuvre des
tests
Oriente le découpage du système en
composants qui pousse à une
réflexion sur l’architecture
Deux types de tâches sont réalisées en
parallèle (on prépare la vérification de
la tâche en cours)
Inconvénients :
La validation finale par le client très
tardive augmente les risques de
dépassement de délai (et de coût)
Ne propose pas de plan type de
document
Modèle en « W »
Principes :
Enrichissement du modèle en V avec
anticipation du livrable final
Avantage :
La qualité de la mise en œuvre des
tests
Dérisquage de la partie IHM avec une
maquette
Inconvénients :
La validation finale par le client très
tardive augmente les risques de
dépassement de délai
Ne propose pas de plan type de
documents

[UVT - FST]
[30]
Modèle en « Spirale »
Principes :
Les besoins ne peuvent s’exprimer qu’après
une expérimentation
Avantage :
Identification rapide des risques
Chaque boucle serait un sous projet
A l'issue de la boucle, une revue des
produits et des résultats fournit une
évaluation qui sert d'entrée pour la
boucle suivante
Inconvénients :
Évaluer les risques impliqués dans le
projet peut prendre jusqu'à le coût et il
peut être plus élevé que le coût de la
construction du système
Modèle très complexe
Les objectifs ne sont pas souvent
faciles à formuler
Les Méthodes Agiles
Le cycle RAD (RapidApplication
Development)
Principes :
Développement rapide dans des délais réduits
Avantage :
Méthode légère applicable aux
petits projets (80 à 120 jours)
Met l’utilisateur du logiciel au
cœur de la démarche
Le développement met
rapidement en œuvre les
fonctionnalités majeures dans
des prototypes fonctionnels
Inconvénients :
L’utilisateur doit avoir le
pouvoir de décision
Demande une implication des
utilisateurs
La discipline est très importante
: seules les fonctionnalités
cibles doivent être développée

[UVT - FST]
[31]
XP (eXtreme Programming)
Principes :
Destinée à des équipes de moyens taille avec
des spécifications incomplets et / ou vagues
Avantage :
Implication active du client
Appliquer aux meilleures pratiques de
développement
Souplesse extrême
Inconvénients :
Difficulté de planifier et budgétiser un
projet
La faible documentation peut nuire en
cas de départ des développeurs
Les Méthodes Spécifiques
Les cycles ERP (EntrepriseResource
Planning ou Progiciel de Gestion
Intégré)
Principe :
Construire un système améliorant la
performance de l’entreprise en tirant le
meilleur parti d’un progiciel
Avantage :
Structurant (données, terminologie,
règles)
Orienté processus (comprendre le
processus, création de fonctions de
contrôle)
Information accessible et directement
exploitable
Suivi des coûts, qualité
Planification
Inconvénients :
Rigueur (Propagation des erreurs)
Données fiables (Base de données
unique)

[UVT - FST]
[32]
Le modèle de la transformation
automatique (transform model)
Principes :
Possibilité de transformer automatiquement
des spécifications en programmes, à l’aide
de règles
Avantage :
L’essentiel et de porter sur une
description exhaustive des
spécifications, qui devront être
complètement validées
Une succession de cycles de
spécification/validation s’achève par
la génération de code
Figure 15: Analyse des différents modèles de cycle de vie
1.2. Choix de cycle de vie en « Y »
Analyse modèles « Y »
Pourquoi le « Y » :
permet de gérer la complexité technologique, en lui réservant toute une
branche de son cycle.
permet donc en plus, de réduire le risque technologique.
offre un cadre de gestion des risques à travers la déclaration et le suivi d’une
liste des risques identifiés.
Figure 16: Cycle de vie en « Y »
Avantage :
Captures des spécifications et des
contraintes fonctionnels.
Propose une phase d’analyse
séparée en deux branches parallèles
à savoir l’étude fonctionnelle et
l’étude technique du projet
propose une gestion des risques. Ce
qui constitue une avancée
significative
Inconvénients :
Un effort de synthèse : reconnaître,
abstraire…
Un apprentissage à effectuer, une
expérience

[UVT - FST]
[33]
1.3. Récapitulation : Les tâches du projet par activités et par phases
Activités
Phases Plan et besoins Conception Programmation Intégration et test
Analyse des besoins Analyse de
l’existant
- - -
Spécifications et
conception
Prototype,
modèles risques
Spécification,
conception,
modèles,
prototypes
MAJ conception MAJ conception
Réalisation Planification
personnel et outils
Planification des
taches et
acquisition des
outils
Conception
détaillée, codage,
et tests unitaires
Intégration des
modules
Planification et tests Test de
qualifications
Test d’intégration Test unitaires -
Vérification et
validation (V.V)
Validation des
besoins,
conception des
outils et V.V
(V.V) des
spécifications et
conception
(V.V) du code Test d’intégration et
qualification
Figure 17: Les tâches du projet par activités et par phases

[UVT - FST]
[34]
2. Méthodologie et langage de modélisation
Tout projet informatique doit suivre un certain procédé, afin de décrire le plus fidèlement
possible, à quoi rassemblerais l’amélioration apportée au projet existant.
2.1. Présentation UML et MERISE
En réalité il n’existe pas une comparaison ente un langage de modélisation et une méthode
d’analyse et de réalisation, d’autant que le mot langage fait référence a la capacité d'exprimer
une pensée et de la communiquer au moyen d'un système, alors que le mot méthode permet
de formaliser les étapes préliminaire d’un système donnée.
Dans ce qui suit je vais définir le langage UML et la méthode MERISE vu leur remarquable
utilisation dans le domaine de développement.
UML (Unified Modeling Langage) MERISE (Méthode d’Etude et de Réalisation
Informatique pour les Systèmes d’Entreprise)
Est un langage de modélisation des systèmes
standard, qui s’appuie sur les diagrammes
afin de représenter chaque aspect d'un
système en déployant son coté orienté objet
qui est un véritable atout
C’est une méthode d'analyse et de réalisation
des systèmes d'information qui est élaborée en
plusieurs étapes: schéma directeur, étude
préalable, étude détaillée et la réalisation
Se base sur un ensemble de formalismes,
dont a besoin d’y associer une démarche et
une organisation pour constituer une
méthode
Auparavant il proposait un ensemble "cohérent"
sur ces trois composantes. Certaines ont vieilli et
ont du être réactualisées (la démarche), d'autre
"tiennent encore la route" (les modélisations).
La modélisation des données en vue de la
construction d'une base de données
relationnelle, la modélisation des processus
métiers d'un system d’information
automatisé en partie par du
logiciel
C’est une méthode de conception de system
d’information organisationnel, plus tournée vers
la compréhension et la formalisation des besoins
du métier que vers la réalisation de
logiciels
Identification des besoins utilisateur dans le
cadre de cahier des charges, en vue de la
conception d'un logiciel adapté.
Dédié pour l'ingénierie du system d’information
métier que du génie logiciel
Tableau 2: UML vs MERISE

[UVT - FST]
[35]
Afin de mieux comprendre :
Figure 18: Apparition de l'UML
2.2. Techniques d’implémentation UML, Pourquoi ?
Comme déjà préciser dans la section qui précède, on a pu comprendre que la méthode UML
et la plus appropriée pour ce projet eCandidat grâce a son caractère orientée objet et
l’utilisation du langage java.
Les points qui suivent expliquent mon choix d’implémenter le langage UML :
l’UML permet de concevoir et détaler une architecture logiciel développée dans un
langage orientée objet
Son caractéristique « unificateur » offre des formalités pour :
 modéliser les données de manière structurelle (le modèle de classe en
identifiant la structure des classes d'un système, y compris les propriétés et les
méthodes de chaque classe).
 modéliser le fonctionnement métier grâce aux Diagrammes Comportementaux
(le diagramme d’activité, de cas d'utilisation, etc.) qui sont des formalismes très
anciens qui viennent pour améliorer Merise.
L'unification et la normalisation des méthodes (1995-1997)
UML (Unified Modeling Langage), la fusion et synthèse des méthodes
Les premiers consensus (1995) OMT, OOD, OOSE
L'émergence des méthodes objet (1990-1995)
L'approche systémique (années 80)
Modélisation des données + modélisation des traitements (Merise, Axial, IE...).
Les premières méthodes d'analyse (années 70)

[UVT - FST]
[36]
2.3. Les Différents diagrammes d’UML
La modélisation consiste à créer une représentation virtuelle d'une réalité de telle façon à faire
ressortir les points auxquels on s'intéresse. Ceci et une citation des différents diagrammes
UML, trois d’entre eux seront employée dans ce qui suit :
UMl
Diagrammes
structurel
D. des classe
D. des objets
D. des composants
D. de déploiement
diagrammes
comportementaux
D. cas d'utilisation
D. des séquences
D. des
collaborations
D. d'état
D. d'activité
Figure 19: Les Différents diagrammes d’UML

[UVT - FST]
[37]
3. Description des scénarios du système
Pour cette application de gestion de candidatures et test d’évaluation, je me suis fixé les
objectifs suivants : mette en place un outil d’échanges interactif et partiellement en temps réel
afin de faciliter le processus d’inscription et d’adhésion, permettre à l’administration
d’automatiser ses tâches et de gagner du temps pour une meilleur optimisation et pour donner
au candidat un espace convivial afin de gérer sa candidature et tout ce qui se rapporte a cette
dernière.
Les principales fonctionnalités de chaque acteur sont résumées dans le tableau suivant :
Acteurs Fonctionnalités
FrontOffice : candidat Dépôt candidature
Création compte candidat (paramétrage
compte)
Suivi candidature
Effectuer une réclamation
Passage de test d’évaluation
BackOffice : Administration Traitement candidatures
Gestion des Personnels
Gestion des fichiers d’inscriptions
Maintenance à la fois des comptes
administrateurs et candidats
Gestion des réclamations
Gestions des candidatures (ouverture,
résultat, modification, etc.…)
Gestion de reporting
Figure 20: Description des acteurs par fonctionnalités

[UVT - FST]
[38]
3.1. Recherche des acteurs et des cas d’utilisations
Les fonctionnalités du système sont décrites à partir de diagrammes de cas d ‘utilisation ou
use case diagrams du langage de modélisation objet UML (Unified Modeling Language).
Ces diagrammes illustrent les fonctions du système (cas d’utilisation), leurs limites (acteurs)
et les relations entre les cas d’utilisation et les acteurs.
La modélisation du système commence par l’identification des acteurs et des cas d’utilisation
et se poursuit par la description des cas d’utilisation.
Pour une bonne compréhension du modèle, il paraît nécessaire de définir certains termes
propres au langage UML.
Un cas d’utilisation est une séquence d’activités ou d’actions organisées en étapes
distinctes, qu’un système effectue en réponse à une sollicitation extérieure.
Un acteur définit un rôle qu’une entité extérieure assume lors de son interaction avec le
système.
Le diagramme de cas d’utilisation est une représentation contextuelle de haut niveau du
système modélisé.
a. Acteurs
Dans le cadre de mon application j’ai distingué quatre types d’acteurs :
 Le candidat : C’est un exploitant externe de l’application dés qu’il décide de postuler pour
une candidature, il sera considérer comme un utilisateur actif, il aura a sa disposition
certaines fonctionnalité de system, à savoir consultation candidature, dépôt dossier, effectuer
une réclamation ou bien passer l’épreuve de l’évaluation en cas d’acception de dossier de
candidature par la commission. Il a aussi la possibilité de gérer son compte (création,
modification, désactivation) et de suivre sa candidature après avoir s’authentifier.
 Le Personnel FST : Après avoir s’authentifier selon les privilégies prédéfinie pour son accès,
il assure le suivi administratif des demandes de candidatures, la vérification de la complétude
des documents reçus, la gestion de l’ouverture et clôtures des inscriptions et prolongation s’il
y a lieu, l’affichage des résultats après traitement des avis de la commission, effectuer des
reporting, et traiter tous types de réclamations relatives aux candidats.

[UVT - FST]
[39]
 La commission : Après avoir s’authentifier selon les privilégies prédéfinie pour son accès, il
pourra consulter la date de rassemblement de la commission, donner son avis sur le résultat
des candidatures, écrire des notes, ou aussi consulter les résultats définitifs. Une commission
est composée d’au moins 3 à plusieurs membres.
Il a aussi la possibilité de gérer son compte (création, modification, suppression). Un agent de
la commission peut appartenir à l’FST ou d’autres facultés Tunisiennes.
 Le super-utilisateur : Après avoir s’authentifier, il s’occupe de la « Maintenance des
données », des privilèges et aussi la maintenances des comptes utilisateurs (mot de passe
oublié, identifiant oubliée, problèmes accès, etc.).
b. La description des cas d’utilisation
B.1. Cas d’utilisation : « Authentification »
Figure 21: Cas d’utilisation "Authentification "

[UVT - FST]
[40]
B.1.1. Description textuelle : cas d’utilisation « Authentification »
Sommaire d’identification
Titre Authentification
But Saisir un mot de passe et un login pour pouvoir se connecter sur l’application
Résumé Après avoir saisir les identifiants, chaque utilisateur pourras accéder a certaines
volets de l’application selon la nature du privilège qu’il possède
Acteurs Utilisateur interne : super-utilisateur, personnel FST, membre commission
Utilisateur externe : candidat
Description des enchainements
Pré-conditions Post-conditions
 L’utilisateur eCandidat doit avoir
un compte déjà créé.
 L’application doit être ouverte et
la connexion à la base de donnés
doit être effectuée pour vérifier les
identifiants.
Contacter l’administrateur en cas de problème
d’accès.
Scénario nominal
 L’utilisateur demande l’accès au système.
 L’utilisateur saisit son login et son mot de passe.
 Le système vérifie l’existence de l’utilisateur.
 Si l’utilisateur et identifiée, le système affiche son interface (selon ses droit d’accès).
Enchainement alternatif
E1 : champ obligateur non valide et/ou vide
Le système affiche un message d’erreur pour alerter l’utilisateur
Redirection a la page d’authentification
E2 : champ des identifiants invalide
clic sur « mot de passe oubliée » ou contacter administrateur
Tableau 3: Description textuelle cas d’utilisation « Authentification »
B.1.2. Diagramme d’activité : « Authentification »
Figure 22: Diagramme d’activité : «
Authentification »

[UVT - FST]
[41]
B.2. Cas d’utilisation : « Maintenance système »
B.2.1. Description textuelle : cas d’utilisation « Maintenance système »
Titre Maintenance système
But Maintenance de système et bon fonctionnement de ce dernier
Résumé Le super-utilisateur gère les comptes utilisateurs, affectation des privilèges et la
gestion des problèmes d’accès.
Acteurs Utilisateur interne : super-utilisateur
 Le super-utilisateur eCandidat doit avoir
un compte et les hauts privilèges pour
maintenir et gérer le système.
Accès à l’interface de supervision système.
Mis à jour en cas de modification, suppression,
ou d’ajout.
Scénario nominal
 Le super-utilisateur demande l’accès au système.
 Le super-utilisateur saisit son login et son mot de passe.
 Le super-utilisateur choisit de gérer les comptes utilisateurs et mise à jour.
 Le super-utilisateur affecte les privilèges d’accès aux différents utilisateurs.
Figure 23: Cas d’utilisation : « Maintenance système »

[UVT - FST]
[42]
Tableau 4: Description textuelle : cas d’utilisation « Maintenance système »
B.2.2. Diagramme d’activité : « Maintenance système »
E1 : champ ou choix non valide et/ou vide
Le système affiche un message d’erreur pour alerter le super -utilisateur
Redirection a l’étape 2
E2 : champ ou choix invalide
Le système affiche un message d’erreur pour alerter le super-utilisateur
Redirection a l’étape 2
Figure 24: Diagramme d’activité : « Maintenance système »

[UVT - FST]
[43]
B.3. Cas d’utilisation : Gestion des candidatures
Figure 25: Cas d’utilisation : Gestion des candidatures
B.3.1. Description textuelle : cas d’utilisation « Gestion des candidatures »
Titre Gestion des candidatures
But Gérer les candidatures déposées par les étudiants
Résumé  Le personnel FST à la possibilité de gérer les candidatures, de les lister, et
de vérifier s’ils sont complets ou pas
 La commission effectue une présélection des dossiers validées et donne son
avis.
Acteurs Utilisateur interne : personnel FST, commission
 Le personnel FST eCandidat doit avoir
un compte et les privilèges nécessaires
luire permettant de gérer les candidatures
déposées.
 Un membre de la commission doit avoir
un compte.
Accès à l’interface de gestion des candidatures.
Une candidature peut être : acceptée, refusée, en
attente, ou rétracter
Scénario nominal

[UVT - FST]
[44]
1. Le personnel FST ou membre de la commission demande l’accès au système.
2. Le personnel FST ouvre les inscriptions.
3. Le personnel FST peut demander de consulter la liste des candidatures
4. Le personnel FST vérifie la complétude des dossiers déposé.
5. Les membres de la commission effectuent une présélection et donne leurs avis
E1 : ouverture d’inscription refusée (date invalide, accès refusée)
Le système affiche un message d’erreur pour alerter l’utilisateur.
Redirection a l’étape 2 ou contact super-utilisateur.
E2 : accès liste des candidatures refusées
Redirection a l’étape 3 ou contact super-utilisateur.
E2 : recherche : candidature n’existe pas ou invalide
Le système affiche un message d’erreur.
Redirection a l’étape 4.
Tableau 5: Description textuelle : cas d’utilisation « Gestion des candidatures »
B.4. Cas d’utilisation : dépôt des candidatures
Figure 26: Cas d’utilisation : dépôt des candidatures

[UVT - FST]
[45]
B.4.1. Description textuelle : cas d’utilisation « Dépôt candidature »
Titre Dépôt candidature
But Faciliter le dépôt de candidature pour les étudiants.
Résumé Tout candidat dont le profil correspond aux critères d’adhésion pourra déposer sa
candidature
Acteurs Utilisateur externe : candidat
 Le candidat doit remplir le formulaire
d’inscription pour créer son compte et
suivre les étapes de dépôt de candidature
 Authentification avec le login et mot de
passe.
 Le candidat doit remplir correctement
tout les informations demandées.
 Accès interface profil candidat lui
permettant de suivre, modifier, ou
d’annuler sa candidature.
Scénario nominal
1. Le candidat demande de déposer sa candidature
2. Le candidat remplit le formulaire puis valide.
3. Le système crée un nouveau compte avec les informations saisies par le candidat.
4. Le candidat récupère son login et mot de passe pour pouvoir se connecté et gérer sa
candidature (suivi, modification, annulation).
5. Le candidat a la possibilité de modifier sa candidature en respectant la date imposée.
6. Le candidat a la possibilité de consulter sa candidature
7. Le candidat a la possibilité de suivre sa candidature
E1 : champs obligatoires non valides et/ou vide
E2 : login et / ou mot de passe incorrecte
E3 : Modification candidature refusée (date expirée, candidature en cours de traitement)
E4 : suivi candidature refusée (accès refusée)
Figure 27: Description textuelle : cas d’utilisation « Dépôt candidature »

[UVT - FST]
[46]
B.4.2. Diagramme d’activité : « Dépôt candidature »
Figure 28: Diagramme d’activité : « Dépôt candidature »

[UVT - FST]
[47]
B.4.3. Diagramme d’activité : « Formulaire d’inscription –création compte candidat »
B.5. Cas d’utilisation : « Gestion des utilisateurs »
Figure 29: Diagramme d’activité : « Formulaire d’inscription –création compte
candidat »
Figure 30: Cas d’utilisation : « Gestion des utilisateurs »

[UVT - FST]
[48]
B.5.1. Description textuelle : cas d’utilisation « Gestion des utilisateurs »
Titre Gestion des utilisateurs
But Gérer les actions relatives aux différents utilisateurs de l’application.
Résumé Le super-utilisateur gère l’état des utilisateurs, leurs privilèges, leurs profils, de les
lister, ainsi que le traitement de problèmes d’accès de ces derniers. Le système
effectue la mise à jour dans la base de données.
Acteurs Utilisateur interne : super-utilisateur
Le super-utilisateur doit s’authentifier. Accès interface gestion utilisateur, effectue les
différentes actions et mise à jour au niveau de la
base de donné.
Scénario nominal
1. Gérer état utilisateur :
 Un utilisateur peut être actif, inactif ou en attente de validation.
 Le système informe de la réussite de l’opération effectuée.
2. Gérer privilèges utilisateur
 Le super- utilisateur affecte a chaque utilisateur un privilège (personnel FST,
membre commission, candidat, président commission).
 Selon son privilège chaque utilisateur aura un droit d’accès à certaines
fonctionnalités de système.
 Un privilège peut avoir un état actif, inactif ou en attente.
3. Gérer problèmes d’accès
 Un utilisateur peut demander à recevoir soit le login ou le mot de passe d’un en cas
d’oublie via e-mail (en saisissant son mail).
4. Lister utilisateur
 Le super-utilisateur peut lister les utilisateurs et imprimer cette liste.
 Le système affiche la liste des utilisateurs.
 Le super-utilisateur peut choisir d’effectuer des statistiques ou d’imprimer la liste.
E1 : le super-utilisateur saisit une information incorrecte
Le système affiche un message d’erreur pour alerter le super-utilisateur
Le système se positionne sur l’information erronée
Figure 31: Description textuelle : cas d’utilisation « Gestion des utilisateurs »

[UVT - FST]
[49]
B.6. Cas d’utilisation : « Gestion des Tests »
B.6.1. Description textuelle : cas d’utilisation « Gestion des Tests»
Titre Gestion des Tests
But Passer le Test d’évaluation afin de positionner le candidat
Résumé Le candidat pourra passer son test d’évaluation dans le cas ou sa candidature sera
validée et de consulter son résultat
Acteurs Utilisateur externe : candidat
Le candidat doit s’authentifier.  Le candidat accède a son compte il aura
un lien pour cliquer dessus afin de passer
son test.
 Affichage de résultat du test dans la
même interface à savoir son compte.
Scénario nominal
1. Passage de test :
1.1.Le candidat accède à son compte en saisissant ses identifiants
1.2.Clic sur le lien permettant de passer son test
1.3.Le système informe le candidat qu’il a une seule tentative et en cas de validation il n’aura
pas la possibilité ni de modifier ni de revenir en arrière.
1.4.Le candidat passe son test et valide l’envoie des données.
1.5.Le système confirme l’opération effectuée.
1.6.La mise à jour sera prise en compte au niveau de la base de données.
2. Consultation résultat :
2.1.Le candidat accède à son compte en saisissant ses identifiants
2.2.Demande de consulter son résultat pour le test
Figure 32: Cas d’utilisation : « Gestion des Tests »

[UVT - FST]
[50]
2.3.Le système affiche le résultat.
Pas de redirection, le système pointe sur le donné invalide
E2 : lien ne s’ouvre pas
Redirection à l’étape 1.2
E2 : le résultat ne s’affiche pas
Figure 33: Description textuelle : cas d’utilisation « Gestion des Tests»
B.6.2. Diagramme d’activité : « Gestion des Tests »
Figure 34: Diagramme d’activité : « Gestion des Tests »

[UVT - FST]
[51]
B.7. Cas d’utilisation : « Gestion ville »
B.7.1. Description textuelle : cas d’utilisation « Gestion des villes»
Titre Gestion des villes
But L’ajout, la modification, la suppression et le listage des villes
Résumé Possibilité des gérer les villes
Acteurs Utilisateur interne ; super-utilisateur
L’utilisateur doit s’authentifier. Login et mot de passe doivent être uniques.
Scénario nominal
1. Création /modification/suppression d’une ville :
1.1.L’ajout se fait à partir d’un remplissage correct d’un formulaire.
1.2.Le super-utilisateur remplie le formulaire puis valide.
1.3.Le système informe de la réussite de l’opération effectuée.
1.4.La mise à jour sera prise en compte au niveau de la base de données
2. Lister les villes :
2.1.Le super-utilisateur choisit un critère pour lister les villes
2.2.Le système affiche la liste des villes selon le critère choisie
2.3.Le super-utilisateur peut choisir d’effectuer des statistiques ou d’imprimer la liste
Figure 35 : Cas d’utilisation : « Gestion ville »

[UVT - FST]
[52]
E2 : ville existe déjà dans la base donnée
E2 : la ville ne peut pas être supprimée
Figure 36 : Description textuelle : cas d’utilisation « Gestion des villes»
B.7.2. Diagramme d’activité : « Gestion des villes »
Figure 37 : Diagramme d’activité : « Gestion des villes »

[UVT - FST]
[53]
II. La conception détaillée
2. Les Diagrammes de séquences
C’est une représentation des objets et leurs interactions selon une ligne temporelle.
C’est la vue fonctionnelle d’une demande, actions, ou d’une activité donnée.
2.1. Diagramme de séquence : « Authentification »
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
Figure 38 : Diagramme de séquence : « Authentification »

[UVT - FST]
[54]
2.2. Diagramme de séquence : « Gestion des candidatures »
2.3. Diagramme de séquence : « Gestion des Tests »
Figure 39 : Diagramme de séquence : « Gestion des candidatures »
Figure 40: Diagramme de séquence : « Gestion des Tests »

[UVT - FST]
[55]
3. Diagramme de classe
Figure 41 : Diagramme de classe

[UVT - FST]
[56]
4. La base de données
4.1. Implémentation de la base de données
Afin de créer graphiquement la base donnée j’ai utilisé l’outil « MySql Worbench », qui m’a
permis de modéliser ma baes de donnée(les tables, les attributs, etc.…).
Pour faciliter l’utilisation et la manipulation de « Workbench » j’ai instillé PhpMyAdmin
(version 3.5.6) et le serveur Wamp (version 2.2).
Une bref Définition :
MySql Worbench : c’est un outil visuel unifié destinées aux architectures des BDD, il
participe à la modélisation des données et au développement et génération du code
SQL.
Pourquoi MySql Worbench ?
Sélection rapide des tables et des champs.
Une simple exportation / importation de script SQL.
Conception, développement et administration sur un même outil.
Existence d’un utilitaire de validation de modèle afin de vérifier si un modèle de
données contient d'éventuelles erreurs et signale à l'utilisateur tous les problèmes
détectés.
Figure 42: Interface MySql Workbench

[UVT - FST]
[57]
 PhpMyAdmin : c’est une interface de gestion et d’administration d’une base de donnée
permettant d’exécuté et de manipuler très facilement cette dernière, installer avec le
serveur Wamp.
 Wamp : c’est un environnement de développement web contenant les deux serveurs
« Apache » et « MySql ».
4.2. Génération script SQL
Etape 1 : Le modèle EER (Enhanced Entity Relationship)
Figure 43: Interface phpMyAdmin
Figure 44: Le modèle EER (Enhanced Entity Relationship)

[UVT - FST]
[58]
Etape 2 : génération du script
1
2
3
Figure 45: génération du script (etape2.1)

[UVT - FST]
[59]
Conclusion
Dans ce chapitre, qui commence par la conception générale , l’étude de cycle de vie adoptée
pour eCandidat, la langage de modélisation choisie qui est l’UML, et en dernier lieu la
conception détaillée, dont j’ai exposer les différents cas d’utilisation, les diagrammes de
séquences, le diagramme de classe et enfin la conception de la base de données.
Le troisième et dernier chapitre de ce rapport, traiteras l’aspect pratique de la réalisation.
4

[UVT - FST]
[60]
Chapitre III : Développement

[UVT - FST]
[61]
I. Identification des besoins Hardware
Intitulé Description
Fabricant Packard bell Esay note TJ65
Processeur Intel Core 2 Duo processor T6600 2.20GHZ
Mémoire installée (RAM) 4,00 M
Type de système Système d’exploitation 64bitss
II. Identification des besoins Software
Outil de développement Métier
IDE Netbeans 7.2.1
SGBD Conception BDD : MySQl Workbench
Serveur BDD : WampServer , PhpMyAdmin
Serveur d’application Glassfish 3.1
Plugins iReport> jasperreports-components-plugin-4.7.1
Outil de développement Design
Conception de la charte graphique Photoshop CS3
Conception des animations Flash CS3
Composants charte graphique Primefaces 3.5-2
Primefaces-extensions-0.6.3
III. Configuration de l’environnement de travail
1. Fichiers de configuration
Figure 49 : Fichiers de configuration

[UVT - FST]
[62]
Descripteur de
déploiement
Description
Faces-config.xml Permet de configurer l'application JSF6
(déclaration des managedbeans/
controllers , déclaration des règles de navigation, etc.)
Glassfish-web.xml Description des accès et des autorisations selon les rôles et les groupes
d’appartenance.
Persistence.xml Pour se connecter à la base de données et réaliser les opérations CRUD7
,
l'EntityManager utilise les informations de configuration contenues dans un
fichier appelé unité de persistance qui contient une référence sur le connecteur
JDBC à utiliser en tant que source de données.
Web.xml Définit les mappages entre les chemins d'URL et les servlets qui traitent les
requêtes avec ces chemins. Le serveur Web utilise cette configuration pour
identifier le servlet devant traiter une requête donnée et pour appeler la méthode
de classe qui correspond à la méthode de requête, il traite aussi la configuration
de l’authentification, les principaux avec des rôles, et les autorisations.
Glassfish-
resources.xml
C’est un fichier propriétaire et spécifique au serveur glassfish, il indique à
glassfish que l'on déploie une source de données avec l'application et que l'on
désire qu'il s'y connecte.
Tableau 6: Description fichiers de configuration
6
JSF : Java Server faces
7
CRUD : Create, Read, Update, Delete

[UVT - FST]
[63]
Figure 50: Fichier glassfish-resource.xml
2. Packages
Principaux
1 Contient les ManagedBean des opérations CRUD
2 Contient les ManagedBean relatifs à l’accès et
l’authentification des utilisateurs
3 Contient les différents entités
4 C'est l'EJB façade que vous utiliserez pour accéder
à la base de données. Il contient une référence à la
PersistenceUnit qui a été créée précédemment, et il
contient également une référence à l'EntityManager
qui réalise les opérations d'accès à la base.
5 Contient les fichiers relatifs a la gestion des
Statistiques
1
2
3
4
5
Figure 51 : Liste des Packages de eCandidat

[UVT - FST]
[64]
3. Base de données et serveur d’application
Glassfish 3.1 :
C’est le serveur d’application
installé sous Netbeans 7.2.1 pour
le développement d’eCandidat.
Glassfish a permis une
configuration facile en utilisant
le REALM afin d’assurer la
sécurité et l’autorisation d’accès
des différents acteurs de cette
application.

[UVT - FST]
[65]
IV. Plateforme JEE
1. Langage
Langage Description
JPQL8
C’est un langage de requête dédiée PI de persistance J.P.A. Il est très proche
du langage SQL dont il s'inspire fortement mais offre une approche objet.
SQL 9
C’est le langage de programmation destinée à stocker, à manipuler et à
retrouver les données enregistrées dans la base de données relationnelles.
Xhtml C’est la nouvelle génération du Html, ça consiste à reformuler les balises de
Html selon les nouvelles règles de présentations et de syntaxe de XML.
CSS310
Le langage CSS est utilisé pour définir l'aspect
de site eCandidat. Le CSS (ou feuille de style), c'est un fichier dans lequel
j’ai définit l'ensemble des choix de couleurs, type de police, les positions.
Tableau 7 : Langage de Programmation
8 JPQL: Java Persistence Query Language
9
SQL : Structured Query Language
10
CSS : Cascading Style Sheets

[UVT - FST]
[66]
2. Framework
2.1. Framework de présentation
a. JSF2
Java Server Faces est un Framework de développement d’applications Web en Java permettant
de respecter le modèle d’architecture MVC et basé sur des composants côté présentation.
*Architecture MVC pour séparer l’interface utilisateur, la couche de persistance et les processus
métier, utilisant la notion d’événement, Conversion des donnée, Validation des données (par
exemple, des champs de formulaires requis)
*Automatisation de l’affichage des messages d’erreur en cas de problèmes de conversion ou de
validation.

[UVT - FST]
[67]
b. Primefaces
Quelques composantes de Primefaces utilisée dans eCandidat :
C’est l’un des composants de JSF2.
C’est une bibliothèque open source de composantes JSF, il est basé côté serveur sur l’API
standard de ce dernier.
Elle permet de mettre à disposition des interfaces clients riches dans les applications Web JEE.

[UVT - FST]
[68]
2.2. API de persistance
JPA
Exemple de l’entité « user » implémentant les annotations JPA :
*JPA permet de rendre les données d'une application persistantes dans une base de données
relationnelle. *l'API de persistance JPA repose essentiellement sur l'utilisation des annotations,
introduites dans Java 5. Elles permettent de définir très facilement, et précisément des objets
métier, qui pourront servir d'interface entre la base de données et l'application.
Figure 52: exemple d'une classe implémentant JPA

[UVT - FST]
[69]
Le bon accès
au bon contenu
par les bonnes
personnes
2.3. Framework de sécurité
JAAS :
Configuration web.xml
*JAAS est une série de paquetages qui implémente un service d'authentification et d'autorisation
des utilisateurs. *Afin d’assurer un certain niveau de confidentialité et de sécurité j’ai intégrée le
JAAS au niveau de eCandidat. * Le JAAS m’a permis d’identifier les rôles des personnes aux
zones qu’ils peuvent accéder. Grace ace dernier j’ai pu garantir l’aspect confidentialité, l’intégrité,
l’authentification et l’autorisation.

[UVT - FST]
[70]
Configuration de Realm au niveau de la console de Glassfish :
2.4. Framework JavaMail
JavaMail
*L’API JavaMail a était utiliser pour permettre aux différents utilisateurs de recevoir leurs Mot de
passe en cas d’oublie de ce dernier.
Figure 53: Configuration de Realm au niveau de la console de Glassfish

[UVT - FST]
[71]
3. Plugin Jasper Report
Exemple de génération d’un rapport sous Netbeans :
*La nécessité d’avoir des éditions écrans et papiers provenant de la base de donnée de eCandidat,
m’a permis de choisir Jasper report comme solution afin de construire des rapports simples. *Le
Framework Jasper Report à était configuré au niveau de Netbeans.
1- Choix de type de rapport
2- Choix des tables
rapport

[UVT - FST]
[72]
3.1. Architecture couche présentation :
3- Génération de la requête
4- Génération du rapport / format PDF

[UVT - FST]
[73]
V. Architecture de l’application
5- Résultat final
> Format PDF
Figure 54: Fichier Report générer avec iReport
Figure 55: Architecture de l'application

[UVT - FST]
[74]
VI. Gestion d’erreur
Pour un candidat souhaitant effectuer une inscription afin de déposer sa candidature, il passera
par ce formulaire composé de plusieurs onglets dont il doit remplir les différents champs. La
figure ci-dessus montre les cas ou le candidat laissera le champ « Prénom » vide, d’où un
message d’erreur s’affichera pour l’avertir, aussi s’il met des lettres dans un champ numérique
comme le montre cette figure pour l’attribut « CIN », un message d’erreur apparaitra pour lui
dire que ce champ et de type numérique.
Figure 56: Exemple de gestion des erreurs
Figure 57 : Exemple de gestion des erreurs "email"

[UVT - FST]
[75]
VII. Présentation de quelques interfaces Administrateur
Etape 1 : Saisie des Identifiants Etape 2 : Message de Bienvenue
Etape 3 : Interface « Gestion des utilisateurs »
Figure 58: Interface "Gestion des utilisateurs"

[UVT - FST]
[76]
Ajout utilisateur :
Mise à jour utilisateur :

[UVT - FST]
[77]
Liste Utilisateurs :
Gestion des événements :

[UVT - FST]
[78]
Liste utilisateurs selon leurs Privilèges et Etat :

Conclusion et perspectives
Mon projet a consisté en la conception, le développement et l’intégration d’une application de
gestion de candidature et test d’évaluation pour le compte de la Faculté des Sciences de Tunis, afin
d’apporter une valeur ajoutée et un meilleur service aux étudiants de cette dernière.
Je suis arrivé à développer la majorité des fonctionnalités du système qui m’ont était affecter dans
les temps.
Ce stage a été pour moi, était l’occasion d’une part d’approfondir mes connaissances théoriques,
acquises durant les 3 semestres de mon master, par la pratique des nouvelles technologies. Cette
expérience m’a permis de maîtriser des différents langages de programmation et les Framework de
présentations ainsi que les différent API de persistance, de génération des rapports, d’assurer un
environnement sécurisé en prédéfinant auparavant les divers privilèges et les droits d’accès.
L‘environnement de développement JEE à savoir l’IDE Netbeans, sous lequel, le développement n’a
pas été une tâche facile, mais je n’ai pas hésité à y participer, et de m’intégrer dans la recherche et
l’apprentissage des différents outils logiciels nécessaires à la réalisation de eCandidat.
Ce stage de PFE m’a également permis de découvrir toute un monde de nouvelles technologies
relatifs aux environnements de persistance, le mariage de HTML et de l’XML, le langage JPQL qui
rassemble beaucoup à l’SQL mais orientée objet, le serveur d’application Glassfish avec
l’implémentation de JAAS afin d’assurer la coté sécurité de mon application, les interfaces crée par
deux technologies totalement hétérogènes le CS3 et Primefaces.
Cette opportunité a aussi été pour moi une occasion unique pour épanouir mes capacités de
communication dans un environnement professionnel. C’est une expérience très enrichissante sur
tous les domaines.
Enfin, l’application que j’ai développée pourrait être enrichie par le Module Test d’évaluation que
suite à des contraintes de temps j’ai pas eu l’occasion de le développée, mais c’est un objectif qui
reste prioritaire dans l’avenir.

Netographie
http://www.luglearning.com/plateformes-de-formations-en-ligne/moodle/avantages-de-moodle
http://www.edsti.enit.rnu.tn/fr/index.php?id=15
http://www.tenstep.fr/TSPB/01_Publique/Chapitre_8_Management_de_la_qualite_du_projet.htm
http://fr.wikipedia.org/wiki/Progiciel_de_gestion_int%C3%A9gr%C3%A9#Les_avantages
http://www.tunisie.campusfrance.org/page/inscriptions-en-licence-3-licence-professionnelle
http://www.osbi.fr/enquete-actuate-sur-lopen-source-annee-2009/
http://laurent-piechocki.developpez.com/uml/tutoriel/lp/cours/#LI-B-2
http://www.mysql.fr/products/workbench/
http://tahe.developpez.com/java/primefaces/?page=page_1#LIII-A
http://wwwdi.supelec.fr/hardebolle/tutos/TutorielJavaEE/JEE_43-jpa.php
http://primefaces-rocks.appspot.com/ui/fieldset.jsf
http://www-igm.univ-mlv.fr/~dr/XPOSE2007/acollign_ORM-JPA/jpa-tech2.html
http://docs.oracle.com/cd/E19798-01/821-1794/gepgd/index.html

Liste des Figures
Figure 1 Diagramme générale d’admission........................................................................................................ 5
Figure 2:Les technologies déployées pour la conception de eCandidat ............................................................ 10
Figure 3: "Best practice" MOODLE ................................................................................................................. 11
Figure 4: Processus d'inscription ENIT............................................................................................................. 12
Figure 5: IDE Netbeans..................................................................................................................................... 15
Figure 6: SGBD MySql Worbench ................................................................................................................... 15
Figure 7: Modèle MVC ..................................................................................................................................... 16
Figure 8 : Diagramme de Gantt......................................................................................................................... 18
Figure 9: Page Index.......................................................................................................................................... 19
Figure 10: Page Présentation............................................................................................................................. 20
Figure 11: Page Formation ................................................................................................................................ 21
Figure 12: Page Concours ................................................................................................................................. 22
Figure 13: Page Administration......................................................................................................................... 23
Figure 14: Page Contact .................................................................................................................................... 24
Figure 15: Analyse des différents modèles de cycle de vie.............................................................................. 32
Figure 16: Cycle de vie en « Y »...................................................................................................................... 32
Figure 17: Les tâches du projet par activités et par phases............................................................................... 33
Figure 18: Apparition de l'UML........................................................................................................................ 35
Figure 19: Les Différents diagrammes d’UML................................................................................................. 36
Figure 20: Description des acteurs par fonctionnalités ..................................................................................... 37
Figure 21: Cas d’utilisation "Authentification "................................................................................................ 39
Figure 22: Diagramme d’activité : « Authentification » ................................................................................... 40
Figure 23: Cas d’utilisation : « Maintenance système ».................................................................................... 41
Figure 24: Diagramme d’activité : « Maintenance système »........................................................................... 42
Figure 25: Cas d’utilisation : Gestion des candidatures .................................................................................... 43
Figure 26: Cas d’utilisation : dépôt des candidatures........................................................................................ 44
Figure 27: Description textuelle : cas d’utilisation « Dépôt candidature » ....................................................... 45
Figure 28: Diagramme d’activité : « Dépôt candidature » ................................................................................ 46
Figure 29: Diagramme d’activité : « Formulaire d’inscription –création compte candidat » ........................... 47
Figure 30: Cas d’utilisation : « Gestion des utilisateurs »................................................................................. 47
Figure 31: Description textuelle : cas d’utilisation « Gestion des utilisateurs »................................................ 48
Figure 32: Cas d’utilisation : « Gestion des Tests ».......................................................................................... 49
Figure 33: Description textuelle : cas d’utilisation « Gestion des Tests».......................................................... 50
Figure 34: Diagramme d’activité : « Gestion des Tests » ................................................................................. 50
Figure 35 : Cas d’utilisation : « Gestion ville »................................................................................................. 51
Figure 36 : Description textuelle : cas d’utilisation « Gestion des villes» ........................................................ 52
Figure 37 : Diagramme d’activité : « Gestion des villes » ................................................................................ 52
Figure 38 : Diagramme de séquence : « Authentification » .............................................................................. 53
Figure 39 : Diagramme de séquence : « Gestion des candidatures » ................................................................ 54
Figure 40: Diagramme de séquence : « Gestion des Tests » ............................................................................. 54
Figure 41 : Diagramme de classe ...................................................................................................................... 55
Figure 42: Interface MySql Workbench............................................................................................................ 56
Figure 43: Interface phpMyAdmin.................................................................................................................... 57

Figure 44: Le modèle EER (Enhanced Entity Relationship)............................................................................. 57
Figure 45: génération du script (etape2.1)......................................................................................................... 58
Figure 49 : Fichiers de configuration ................................................................................................................ 61
Figure 50: Fichier glassfish-resource.xml ......................................................................................................... 63
Figure 51 : Liste des Packages de eCandidat .................................................................................................... 63
Figure 52: exemple d'une classe implémentant JPA ......................................................................................... 68
Figure 53: Configuration de Realm au niveau de la console de Glassfish ........................................................ 70
Figure 54: Fichier Report générer avec iReport ................................................................................................ 73
Figure 55: Architecture de l'application ............................................................................................................ 73
Figure 56: Exemple de gestion des erreurs........................................................................................................ 74
Figure 57 : Exemple de gestion des erreurs "email".......................................................................................... 74
Figure 58: Interface "Gestion des utilisateurs".................................................................................................. 75

Liste des Tableaux
Tableau 1 : Tableau récapitulative pour la critique de l'existant ......................................................................... 6
Tableau 2: UML vs MERISE............................................................................................................................ 34
Tableau 3: Description textuelle cas d’utilisation « Authentification » ........................................................... 40
Tableau 4: Description textuelle : cas d’utilisation « Maintenance système ».................................................. 42
Tableau 5: Description textuelle : cas d’utilisation « Gestion des candidatures » ............................................ 44
Tableau 6: Description fichiers de configuration .............................................................................................. 62
Tableau 7 : Langage de Programmation............................................................................................................ 65
Liste des Abréviations
JSF Java Server Faces
JPA Java Persistence Architecture
Xhtml eXtensible HyperText Markup Language
Html Hypertext Markup Language
CSS Cascading Style Sheets
SQL Structured Query Language
JDBC Java Database Connectivity
Jrxml JasperReports Xml
XML Extensible Markup Language
JPQL Java Persistence Query Language

Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)

Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)

Similaire à Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA) (20)

Dernier

Dernier (20)

Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)