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

12,790 views

Published on

Published in: Education
2 Comments
11 Likes
Statistics
Notes
  • Thank you :)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • felicitation pour le beau travail
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
12,790
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
1,955
Comments
2
Likes
11
Embeds 0
No embeds

No notes for slide

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

  1. 1. 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
  2. 2. 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.).
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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.
  8. 8. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [2] Chapitre I : Analyse et spécification des besoins
  9. 9. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  10. 10. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  11. 11. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  12. 12. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 qui composent le dossier en ligne * Nécessité de se déplacer pour avoir le détail * Tirage et remplissage manuelle Réorientation Disponibilité des documents qui composent le dossier en 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.
  13. 13. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  14. 14. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  15. 15. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  16. 16. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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)
  17. 17. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  18. 18. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  19. 19. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [13]
  20. 20. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  21. 21. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  22. 22. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  23. 23. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 :
  24. 24. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [18] Figure 8 : Diagramme de Gantt
  25. 25. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  26. 26. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [20] b. Page Presentation.xhtml Figure 10: Page Présentation
  27. 27. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [21] c. Page Formation.xhtml Figure 11: Page Formation
  28. 28. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [22] d. Page Concours.xhtml Figure 12: Page Concours En cliquant sur l’un des doc à télécharger un lightBox s’ouvre
  29. 29. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [23] e. Page Administration.xhtml Figure 13: Page Administration
  30. 30. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [24] f. Page Contact.xhtml Figure 14: Page Contact
  31. 31. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  32. 32. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [26] Chapitre II : La conception
  33. 33. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  34. 34. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  35. 35. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  36. 36. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  37. 37. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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)
  38. 38. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  39. 39. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  40. 40. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  41. 41. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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)
  42. 42. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  43. 43. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  44. 44. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  45. 45. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 "
  46. 46. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 Le système affiche un message d’erreur pour alerter l’utilisateur 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 »
  47. 47. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [41] B.2. Cas d’utilisation : « Maintenance système » B.2.1. Description textuelle : cas d’utilisation « Maintenance système » Sommaire d’identification 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 Description des enchainements Pré-conditions Post-conditions  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 »
  48. 48. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [42] Tableau 4: Description textuelle : cas d’utilisation « Maintenance système » B.2.2. Diagramme d’activité : « Maintenance système » Enchainement alternatif 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 »
  49. 49. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 » Sommaire d’identification 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 Description des enchainements Pré-conditions Post-conditions  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
  50. 50. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 Enchainement alternatif 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 Le système affiche un message d’erreur pour alerter l’utilisateur. 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
  51. 51. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [45] B.4.1. Description textuelle : cas d’utilisation « Dépôt candidature » Sommaire d’identification 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 Description des enchainements Pré-conditions Post-conditions  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 Enchainement alternatif E1 : champs obligatoires non valides et/ou vide Le système affiche un message d’erreur pour alerter l’utilisateur. Redirection a l’étape 2. E2 : login et / ou mot de passe incorrecte Le système affiche un message d’erreur pour alerter l’utilisateur. Redirection a l’étape 4. E3 : Modification candidature refusée (date expirée, candidature en cours de traitement) Le système affiche un message d’erreur. Redirection a l’étape 6. E4 : suivi candidature refusée (accès refusée) Le système affiche un message d’erreur. Redirection a l’étape 6. Figure 27: Description textuelle : cas d’utilisation « Dépôt candidature »
  52. 52. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [46] B.4.2. Diagramme d’activité : « Dépôt candidature » Figure 28: Diagramme d’activité : « Dépôt candidature »
  53. 53. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 »
  54. 54. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [48] B.5.1. Description textuelle : cas d’utilisation « Gestion des utilisateurs » Sommaire d’identification 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 Description des enchainements Pré-conditions Post-conditions 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.  Le système informe de la réussite de l’opération effectuée. 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).  Le système informe de la réussite de l’opération effectuée. 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. Enchainement alternatif 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 »
  55. 55. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [49] B.6. Cas d’utilisation : « Gestion des Tests » B.6.1. Description textuelle : cas d’utilisation « Gestion des Tests» Sommaire d’identification 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 Description des enchainements Pré-conditions Post-conditions 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 »
  56. 56. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [50] 2.3.Le système affiche le résultat. Enchainement alternatif E1 : champ obligateur non valide et/ou vide Le système affiche un message d’erreur pour alerter l’utilisateur Pas de redirection, le système pointe sur le donné invalide E2 : lien ne s’ouvre pas Le système affiche un message d’erreur pour alerter l’utilisateur Redirection à l’étape 1.2 E2 : le résultat ne s’affiche pas Le système affiche un message d’erreur pour alerter l’utilisateur 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 »
  57. 57. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [51] B.7. Cas d’utilisation : « Gestion ville » B.7.1. Description textuelle : cas d’utilisation « Gestion des villes» Sommaire d’identification 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 Description des enchainements Pré-conditions Post-conditions 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 Enchainement alternatif Figure 35 : Cas d’utilisation : « Gestion ville »
  58. 58. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [52] E1 : champ obligateur non valide et/ou vide Le système affiche un message d’erreur pour alerter l’utilisateur Redirection à l’étape 1.2 E2 : ville existe déjà dans la base donnée Le système affiche un message d’erreur pour alerter l’utilisateur Redirection à l’étape 1.2 E2 : la ville ne peut pas être supprimée Le système affiche un message d’erreur pour alerter l’utilisateur Redirection à l’étape 1.2 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 »
  59. 59. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 »
  60. 60. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 »
  61. 61. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [55] 3. Diagramme de classe Figure 41 : Diagramme de classe
  62. 62. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  63. 63. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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)
  64. 64. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [58] Etape 2 : génération du script 1 2 3 Figure 45: génération du script (etape2.1) Figure 46: génération du script (etape2.2) Figure 47: génération du script (etape2.3)
  65. 65. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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 Figure 48: génération du script (etape2.5)
  66. 66. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [60] Chapitre III : Développement
  67. 67. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  68. 68. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  69. 69. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  70. 70. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  71. 71. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  72. 72. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  73. 73. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  74. 74. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  75. 75. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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.
  76. 76. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  77. 77. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  78. 78. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [72] 3.1. Architecture couche présentation : 3- Génération de la requête 4- Génération du rapport / format PDF
  79. 79. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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
  80. 80. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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"
  81. 81. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [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"
  82. 82. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [76] Ajout utilisateur : Mise à jour utilisateur :
  83. 83. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [77] Liste Utilisateurs : Gestion des événements :
  84. 84. [Gestion de candidature et test d’évaluation] [UVT - FST] [Auteur : Rahma Ghali] [78] Liste utilisateurs selon leurs Privilèges et Etat :
  85. 85. 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.
  86. 86. 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
  87. 87. 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
  88. 88. Figure 44: Le modèle EER (Enhanced Entity Relationship)............................................................................. 57 Figure 45: génération du script (etape2.1)......................................................................................................... 58 Figure 46: génération du script (etape2.2)......................................................................................................... 58 Figure 47: génération du script (etape2.3)......................................................................................................... 58 Figure 48: génération du script (etape2.5)......................................................................................................... 59 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
  89. 89. 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

×