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

BO Front

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

http://fr.wikipedia.org/wiki/Application_informatique

http://fr.wikipedia.org/wiki/Processus_%28gestion_de_la_qualit%C3%A9%29

http://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27information


[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


Redirection a l’étape 2.

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)


Redirection a l’étape 6. 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


Redirection à l’étape 2.1 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 CRUD

7,

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

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

Education

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