Rapport projet de base de données

De Wiki de Romain RUDIGER
Aller à : navigation, rechercher

Mini projet de base de données : Développement d'une plateforme de formation continue


Participants : Romain RÜDIGER, Yoann COLAS, Flavian BUTEAU, Neo CHU, Sebastien MASSART, Erwan BÈZIER, Ameziane HAMLAT.

Période : 15/01/08 - 17/03/08.

REPARTITION DES TACHES

La modélisation de la base de données a été faite en commun dès le début du projet pour pouvoir ensuite travailler indépendamment sur chaque parties. Voici la répartition des modules pour le projet :

  • Module 1 : Yoann COLAS, Romain RUDIGER,
  • Module 2 : Ameziane HAMLAT, Sebastien MASSART, Nam CHU,
  • Module 3 : Flavian BUTEAU, Erwan BÈZIER.

Modélisation

Projet base de données modélisation.jpg

Ce diagramme est le fruit d’une modélisation faite en commun dès le début du projet. Étant une partie importante pour le bon déroulement de la suite du projet, deux réunions ont été nécessaire pour parvenir à cette version.

PLATE FORME DE TRAVAIL EN COLLABORATION

Deux choses ont été mise en place pour nous permettre de travailler en collaboration sans pour être dans la même pièce :

  • Logiciel de gestion de versions
  • Wiki

Logiciel de gestion de versions

L’école n’offrant pas de serveur permettant de travailler en équipe sur un projet qui doit être capable de :

  • Stockage de toute l’évolution du code source
  • Garder une trace de toutes les mise à jour
  • Capable de restituer des versions antérieures
  • Accès possible depuis Internet et l’école
  • Compatible avec Netbeans, Eclipse.

Un serveur Subversion (svn) a donc été installé sur un serveur à l’adresse suivante : [1] L’accès est bien entendu restreint : utilisateur : projetBD, mot de passe : polyform. Il y a eu plus de 180 versions différentes de ce projet sachant que certaine personne n’avait pas la accès à internet. L’utilisation d’un tel système pour un projet a été une première pour tout le groupe. Ce genre de logiciel est très utilisé dans le monde de l’entreprise, c’est donc une très bonne expérience.

Wiki : Polytech S4 MiniProjet BD

Le Wiki a permit de pouvoir s’échanger différentes informations sur l’avancement de chaque parties pais aussi de réaliser ce rapport au fur et à mesure. Il y a eu plus d’une centaine de contributions sur ce support de communication dont l’idée été vraiment de tout rassembler en un même point.

MODULE DE SUIVI DES INSCRIPTIONS (YOANN COLAS, ROMAIN RUDIGER)

Rappel sur le travail demandé

Ce module a pour but de permettre d’accèder au catalogue de formation, de pouvoir le télécharger, de réaliser une inscription stagiaire, de réaliser une inscription entreprise (plusieurs stagiaires concernés) et enfin, de pouvoir se déinscrire d’une session. Quelques pré-requis sont ainsi demandés :

  • De disposer d’une base de données contenant différentes formations et sessions

de formations ;

  • De disposer d’utilisateurs pré-inscrits sur le site et présents dans la BD ;
  • Dans la table « utilisateur », un champ « profil » pouvant prendre comme valeur

soit « stagiaire » soit « responsable » (ce dernier permettra de réaliser des inscriptions entreprises) ;

La conception

Plan de navigation du module

Le plan de navigation nous permet d’avoir une vue d’ensemble de l’architecture des pages de ce module. À partir de l’accueil l’utilisateur peut accèder au catalogue de formation, et de là il peut télécharger ce catalogue au format PDF d’AcrobatReader. Pour pouvoir accèder à d’autre fonctionnalités l’utilisateur doit se connecter, il peut le faire à tout moment sur chacune des pages sitées.

Une fois connecté, l’utilisateur a à disposition un panier de formation. Dans le catalogue, chaque session de formation peut être ajouté à ce panier. Si l’utilisateur est reconnu comme ayant un profil « responsable », il pourra choisir en plus les collaborateurs qu’il veut inscrire à la session choisie. Le panier est dès lors accessible à n’importequel moment via le menu. À partir du panier, l’utilisateur peut demander à s’inscrire aux formations présente. Une page de facturation apparait, plus ou moins détaillée selon le profil de l’utilisateur.

Une fois inscrit à des formations, l’utilisateur peut consulter la liste de ses formations via le menu. C’est ici qu’il peut se désinscrire d’une session de formation. Le responsable d’une formation pourra désinscrire les collaborateurs qu’il veut pour chaque session de formation.

Projet base de données plan navigation.jpg

Le paradigme MVC

Le module respecte le paradigme MVC en séparant l’affichage, du contrôle ainsi que de l’accès à la base de données. Voici notre architecture :

Projet base de données MVC.jpg

Il n’y a que les éléments de « EntityClasses » qui accèdent à la BD. Les contrôleurs sont en fait des servlet qui servent d’intermédiaires entre les pages web (JSP) et les « EntityClasses » (JAVA).

Ainsi, à travers les « EntityClasses » nous pouvons appeler les méthodes de mise à jour des données et de sélection. Elles renferment toutes les requêtes SQL. Les contrôleurs se chargent du traitement des résultats des requêtes et de la communication avec l’affichage.

Le catalogue

À partir de l’accueil, n’importe qui peut accéder au catalogue de formation. Celui-ci est généré dynamiquement dans une page JSP et contient alors de grand morceau de scriptlet. Mais avant d’y accéder, nous appelons le contrôleur CC_Catalogue qui se charge de récupérer les informations de formations et de sessions de formation. Nous commençons par créer un nouvel objet Formation et de récupérer ainsi toutes les formations présentent dans la BD, de même pour les sessions de formation. Ces données sont insérées dans l’objet session qui sert de support de communication entre les Servlets et les JSP. Pour rediriger vers la page de catalogue, nous nous servons de l’objet « RequestDispatcher » La page JSP récupère ces informations et boucle sur les formations ainsi que les sessions de formation pour les afficher. Nous en profitons pour afficher les dates de début et de fin de session. Nous permettons de récupérer ce catalogue en le téléchargeant au format pdf. Cette version est généré automatiquement à partir de la BD dès que l’on clique sur le lien. Nous passons alors par le contrôleur CC_Catalogue.pdf. Pour chaque session, nous mettons à disposition un lien permettant de l’ajouter au panier de formation (lien visible que si l’utilisateur est connecté).

Le développement

Le sujet précise que l’on doit pouvoir s’inscrire à plusieurs sessions de formations. Nous avons choisi de gérer cela avec un panier de formation comme ceux que l’on peut retrouver sur des sites e-commerces. À partir du catalogue, nous pouvons ajouter une session à notre panier. Pour s’inscrire, il suffira de valider le panier.

Une autre fonctionnalité est l’inscription entreprise où l’on peut inscrire des stagiaire pour le compte d’une entreprise. Il faudra alors les sélectionner.

La sélection des collaborateurs

Ceci ne rentre en compte que lorsque l’utilisateur a un profil « responsable », ce qui veut dire qu’il s’est enregistré comme étant un responsable d’entreprise pouvant inscrire des stagiaires à une session de formation.

Quand on veut ajouter une session au panier, notre contrôleur CC_PanierAjouterFormation détecte le profil et le fait que l’on ai pas encor choisi nos collaborateurs. Il les récupère en sélectionnant tous ceux qui ont le même numéro d’entreprise que le responsable. Il enregistre aussi la session de formation que l’on a choisi.

La page sélection-collaborateurs.jsp nous présente 2 champs :

  • Le premier avec tous les collaborateurs ;
  • Un deuxième avec les collaborateurs que nous choisissons d’inscrire.

Du code javascript permet la gestion de ces deux champs avec des boutons de passage d’un champs à un autre. Nous pouvons aussi double-cliquer sur les noms des collaborateurs directement pour effectuer le passage. Une fois cette liste convenue, le responsable peut la valider. Nous appelons alors une nouvelle fois le contrôleur CC_PanierAjouterFormation qui détecte cette fois-ci que nous avons choisi nos collaborateurs.

Une structure de données particulière est mise en place pour enregistrer les collaborateurs. Le panier n’est pas une classe créée de nous même mais nous nous servons des objets ArrayList pour les enregistrements que nous transportons dans l’objet session. Une première ArrayList est utilisée pour enregistrer les sessions de formations auxquelles nous aimerions nous inscrire. Une deuxième est utilisée pour les collaborateurs, mais comme nous pouvons avoir plusieurs collaborateurs pour une même session, nous utilisons une ArrayList d’ArrayList. Au final, 2 ArrayList sont nécessaires pour l’enregistrement des collaborateurs.

Ce sont des objets qui sont passés dans l’objet session, ainsi l’ArrayList du panier contient des objets Sessionsformations et les sous-ArrayList collaborateurs contiennent des objets Utilisateurs.

Une fois tout ceci enregistrée, nous pouvons afficher notre panier de formation.

Le panier de formation

Le contrôleur CC_PanierAjouterFormation réalise le même traitement d’ajout d’éléments à un panier pour les stagiaires et pour les responsables. Cette page JSP récupère la structure de données définit pour le panier et bouclera dedans pour afficher chaque élément. Ainsi nous pouvons retrouver les sessions de formations sélectionnées et les collaborateurs que nous y avons attribué. Pour chaque session, un lien pour retirer cet élément du panier. Nous appelons alors le contrôleur qui reçoit le numéro de position et réalise le traitement correspondant avant d’afficher de nouveau le panier. Un dernier lien permet de valider notre panier, c’est à dire de réaliser la facturation.

La facturation

La page du panier de formation fait appel au contrôleur CC_Inscription qui nous redirige selon le cas, vers la page de facturation pour stagiaire ou pour entreprise.

Facturation du stagiaire

Seules les informations concernant qui facturer sont à remplir. La table facturation contient les champs d’adresses et d’information sur qui facturer. Une fois ces champs remplis, nous appelons le contrôleur CC_Inscription qui détecte la validation de la facturation et réalise les traitements qui s’imposent.

Un nouvel objet Inscription et facturation apparaissent. L’objet facturation dispose d’une méthode « setAdresse » qui détectera si l’adresse indiqué n’existe pas déjà. Si oui, ont récupère son numéro pour l’insérer dans la table facturation. Sinon on en créer une nouvelle et on récupère son numéro aussi.

Une fois la facturation établit, on met à jour notre inscription en lui donnant notament le numéro de facturation, le numéro du responsable de formation (lui-même).

Facturation entreprise

Plusieurs champs sont à renseignés. Tout d’abord les champs concernant la société, ensuite le responsable de formation, par qui est prise l’inscription et enfin les informations sur qui facturer. Nous réalisons un pré-remplissage des données.

Une fois tout-ci remplis nous accédons à notre contrôleur CC_Inscription. Il récupère toutes les informations et réalise le même traitement que pour la facturation stagiaire. Sauf que si le responsable de formation indiqué n’existe pas dans la BD, il sera créé.

De plus, il faut noter nous avons une inscription par stagiaire inscrit pour une même facturation. Alors, nous récupérons la structure de données du panier et nous parcourons les ArrayList des collaborateurs, nous réalisons une correspondance entre collaborateurs et sessions de formation et nous créons les inscriptions dans la BD grâce à notre objet Inscription.

Une fois terminée, nous retournons sur la page d’accueil avec un message d’alerte nous prévenant que la facturation s’est bien passée.

Le suivi des inscriptions

Le lien dans le menu « consulter les formations » nous permet de voir les sessions auxquelles nous sommes inscrites.

Si l’utilisateur est un responsable, il pourra consulter toutes les sessions auxquelles des collaborateurs sont inscrits, et pour chacune d’entre elles, tous les collaborateurs y participants.

Cette page JSP récupère elle-même les données en créant des objets Formation, Sessionformation et Utilisateurs. Des méthodes de Sessionformation permettent de récupérer les inscrits. Nous faisons attention à ne récupérer que les stagiaires ayant comme responsable de formation celui indiqué dans la table d’inscription. Ainsi, un stagiaire faisant partit d’une inscription entreprise et à la fois d’une inscription faite de son propre chef sera totalement indépendant de l’affichage des données.

Pour chaque collaborateur affiché, nous permettons de pouvoir désinscrire d’une session de formation. Le contrôleur CC_Inscription est appelé et détecte que l’on veut désinscrire une personne, le numéro de la session passé. La table Inscription est alors mise à jour ainsi que la table facturation si besoin est. Après traitement, nous affichons de nouveau cette page de suivi des inscriptions.

Conclusion

Un gros travail de modélisation a été effectué pour cette partie. Nous avons voulu nous attacher particulièrement à cette modélisation car c’est ce qui fait notre valeur ajoutée en tant qu’ingénieur. C’est cette phase qui nous permet d’acquérir les compétences pour s’abstraire de toutes solutions techniques et ainsi de pouvoir s’adapter à n’importe quel environnement.

Nous avons pu aboutir à une solution fonctionnelle assez complète incluant notamment la facturation qui fait un plus pour notre projet. Découvrir J2EE n’a pas été chose facile, c’est une technologie très complète et compliquée. Mais nous avons appris les rudiments qui nous serviront de bases pour nos projets professionnels.

Le travail en groupe a été facilité par la mise en place du serveur SVN. La mise en commun systématique de notre production a facilité grandement notre productivité.

MODULE SUIVI DE FORMATIONS (AMEZIANE HAMLAT, SEBASTIEN MASSART, NAM CHU)

Plan de navigation

Ce diagramme montre l’activité de l’utilisateur dans le module du suivi de formations. En effet, on peut voir les différentes possibilités de navigation à partir de chaque page. Un lien vers la page d’accueil de l‘administrateur (contient un lient vers toute les pages du module) apparaît dans toutes les pages. Projet base de données plan navigation2.jpg

Modèle MVC

Comme indiqué dans les sections ci-dessus, notre application se base sur une architecture MVC (Modèle, Vue, Contrôleur). Ainsi, notre module suit aussi cette architecture. En effet, on a séparé les interfaces web (la vue, représentée par des fichiers JSP) des données manipulées (le modèle, représenté par des classes JAVA qui sont une abstraction de la base de données). Ainsi, pour effectuer les différents traitements, des classes java qui héritent de la classe HTTPServlet - les Servlets - sont développées. Ces classes représentent le contrôleur dans notre architecture MVC.

Projet base de données MVC2.jpg

Le développement

Gestion des formations

Cette partie de l’administration permet de gérer les formations créées. En effet, on peut soit ajouter une nouvelle formation, modifier ou supprimer une formation existante en affichant la liste des formations dans la base de données. Ainsi, on dispose de deux pages pour cette partie :

  • Ajouter une formation : La page est présentée sous forme d’un formulaire.

Chaque champ du formulaire correspond à un attribut de la table Formation de la base de données. Une procédure de gestion des erreurs est mise en place. En effet, chaque donnée du formulaire est vérifiée par le contrôleur appelé (CC_InsertionFormation.java) avant d’être insérée dans la base de données. En cas d’erreurs, un élément contenant le message est ajouté dans le tableau Erreurs qui va s’afficher dans la page ajoutFormation.jsp.

Exemples d’erreurs :
  • Quelques champs sont obligatoires, ainsi l’envoi du formulaire sans les

remplir provoque une erreur ;

  • La durée doit être un nombre, tout autre type de données provoque

une erreur.

Pour la modification des formations, on utilise la même page JSP. En effet, cela dépend de la source du lien. Si la source est la page d’administration alors il s’agit d’un ajout d’une formation car l’objet « tuple » est nul. Si la source est la page contenant la liste des formations alors il s’agit d’une modification car un objet «tuple » contenant les données du tuple sélectionné est encapsulé dans Request. Dans ce cas, le champ date est modifiable et doit respecter un format particulier (dd/mm/aaaa). Si le champ date ne respecte pas le format indiqué, une erreur est soulevée.

A L’envoi des données du formulaire de modification, le contrôleur CC_majFormation.java est appelé. Il permet de faire les différents tests et éventuellement mettre à jour la table formation.

  • Liste des formations : Permet d’afficher la liste des formations. Cela est fait

par le contrôleur CC_ListFormation, qui instancie un objet du type Formation (abstraction de la table formation) et fait appel à l’une des méthodes de la classe Formation getAll() qui renvoie la liste des tuples de la tables . On peut effectuer sur chaque ligne deux opérations :

  • Supprimer la formation représentée par la ligne en cliquant sur le bouton

annuler, cela provoque un message de demande de confirmation pour éviter d’effacer par erreur des formations. Si l’utilisateur confirme la suppression CC_SupprimerFormation qui instancie un objet Formation et supprime le tuple dont le numéro de formation est passé en paramètre. LE contrôleur renvoie sur la page contenant la liste des formations.

  • Modifier la formation. Cela nous renvoie sur la page d’ajout avec les

données de la formation à modifier. A l’envoi du formulaire, la ligne concernée de la table Formation est mise à jour.

Si l’ajout ou la modification d’une formation est réussie, une page JSP insertionReussi.jsp contenant des liens dépendant de l’opération effectuée s’affiche.

Gestion des sessions de formations

Dans cette section, on peut gérer les sessions des différentes formations. On peut en ajouter des nouvelles sessions de formations, les modifier ou modifier leur état (valider ou annuler). Comme dans la gestion de formation, cette partie est composée de deux pages :

  • Ajouter une session de formation : La page est représentée sous forme dans

formulaire. Deux champs sont représentés sous forme de menus déroulants (formation et lieu), les données sont récupérées de la base de données. En effet, on ne peut pas proposer une session d’une formation qui n’existe pas, de même pour le lieu de formation. La même gestion d’erreur que l’ajout de formation est mise en place. Le servlet qui permet de faire ces différents traitements est CC_InsertionSession.java. Cette même page est utilisée pour modifier une session de formation. En cliquant sur le bouton « modifier » de la page liste de sessions de formations, cette page s’affiche avec les données de la session de formation correspondante. L’opération effectuée dans ce cas sur la table session de formation est une mise à jour et non pas une insertion. Le servlet qui s’occupe des différents traitements est CC_UpdateSession.java.

  • Gestion des sessions de formations : Permet d’afficher la liste des sessions

de formations. Sur chaque ligne, on peut soit valider, annuler ou modifier une session. L’annulation d’une session de formation provoque une demande de confirmation pour éviter d’annuler des sessions par erreurs.

Gestions des demandes de création de formation

Des utilisateurs du site peuvent créer des demandes de création de formations la partie publique du site. En effet, on peut proposer une demande de création d’une formation (thème, mots clés, notions abordées et la durée). Une gestion d’erreurs est mise en place lors de l’ajout d’une demande de création. Le contrôleur appelé est CC_InsertionDCFormation.

On peut aussi afficher la liste des demandes de créations dans l’espace d’administration. Deux opérations sont possibles sur une demande de création de formation : valider la demande (créer la formation) ou supprimer la demande. Une validation d’une demande de création nous renvoie à la page d’ajout d’une formation en initialisant les champs : intitulé de formation et mots clés. Ceci permet de créer des formations à partir des demandes de formations. L’annulation d’une demande fait appel au contrôleurCC_SupprimerDCFormation.java qui supprime le tuple sélectionné dans la base de données en passant par la classe Java DCFormation.java.

Conclusion

La modélisation de notre partie suivant un modèle MVC a beaucoup facilité la mise en place des différentes fonctionnalités. On a veillé aussi à réutiliser des pages qui sont déjà créées pour éviter la redondance (ajout et mise à jour d’une formation ou d’une session de formation). Ainsi, plusieurs traitements ont été effectués dans les différents contrôleurs pour passer d’une page à une autre (passage de paramètres).

De plus, on a essayé d’adopter un plan de navigation intuitif pour l’utilisateur (quand on ajoute une nouvelle formation, on peut directement afficher la liste des formations pour voir le résultat). Un retour à la page d’accueil d’administration est possible dans n’importe quel page.

Enfin, on a pu apprécier le travail en groupe en découvrant le gestionnaire de versions SVN. En effet, on a pu voir les différents aspects du travail collaboratifs, inconvénients et avantages et essayer de gérer au mieux les différentes situations.

MODULE GESTION DES STAGIAIRES (FLAVIAN BUTEAU, ERWAN BEZIER)

Un stagiaire, une fois connecté peut avoir accès à deux nouveaux liens : modifier ses coordonnées et consulter les formations auxquelles il a été (ou auxquelles il s’est) inscrit. Tout d’abord, commençons avec l’opération de modification de coordonnées d’un stagiaire.

Modifier son profil

Une fois sur la page d’accueil, l’utilisateur clique sur le lien « Modifier Informations ». Il arrive ensuite sur une page/formulaire avec ses données actuelles déjà renseignées (certaines étant dans des champs de saisie).

Projet base de données ss 1.jpg

L’exécution pour le pré affichage de cette page est effectuée à l’aide d’une servlet CC_GestionInformationStagiaire.java. Cette servlet récupère des données en base de données en exécutant des requêtes à travers la classe bean Utilisateur.java. Les valeurs sont passées en paramètres de session. La page jsp contenant le code html du formulaire que l’on peut visualisé page précédente récupère ces paramètres de session et les affiche (la valeur des entités tel que les textfield ont alors pour « value » le résultat récupéré). Il est alors possible pour le stagiaire de modifier un certain nombre d’information. Il ne peut pas modifier son login, car il ne doit pas y avoir deux login identique (pour des problèmes d’identification évidents). De même, le numéro d’utilisateur ne peut pas être modifié (c’est la clé primaire en base de données). En revanche, il lui est proposé de changer son nom, prénom, mot de passe, numéro d’entreprise (représentant l’entreprise dans lequel il est rattaché) ainsi que son adresse mail. Comme il l’a été formulé dans l’énoncé, le stagiaire doit de nouveau entrer son mot de passe si il veut pouvoir enregistrer ces modifications en base de données.

Les champs sont éditables directement. Ils sont configurés de sorte qu’un utilisateur ne puisse pas entrer une valeur qui dépasserait en taille (par rapport à la taille fixée en bdd). Pour le mot de passe, si il souhaite en changer, il doit le rentrer deux fois (pratique couramment utilisée, pour ne pas engendrer d’erreurs de saisie). Si évidement, le nouveau mot de passe n’est pas le même dans les deux champs, un message pop up généré par du code javascript (code qui s’affiche en head des page jsp que lorsque l’utilisateur est un stagiaire) le prévient de sa maladresse. De même, lors d’une mauvaise saisie du mot de passe courant en bas de la page, si il y a une erreur, alors un message d’erreur l’invite à le ressaisir.

Une fois les valeurs modifiées, elles sont envoyées à la base de données. Des requêtes de type update sont exécutées. Le tuple correspondant au stagiaire dans la table Utilisateur est ainsi modifié. Pour que ces valeurs soient de nouveaux prises en compte par le système (affichage du nouveau nom et du nouveau prénom par exemple…), l’utilisateur doit se reconnecter (avec son nouveau mot de passe si il a décidé de changer). La page lui indiquant que l’opération de modification s’affiche, avec les deux champs pour le loguer.

Projet base de données ss 2.jpg

Une fois cette opération terminée, il est redirigé vers la page d’accueil stagiaire. Il peut de nouveau avoir accès aux options de modification de profil et de consultation de formations.

Projet base de données ss 3.jpg

Le prénom que l’on a modifié (Flavian -> Florian) est pris en compte.

Consultation des formations

Le stagiaire en cliquant sur ce lien accède à une page jsp qui lui retourne les informations sur les formations auxquelles il est inscrit. Cette fois, et contrairement à la procédure utilisée pour la modification des informations, c’est bel et bien une page jsp qui est appelée. Cette page contient un appel à une méthode présente dans le bean Utilisateur.java. Cette méthode renvoi une String (contenant des éléments html comme des « <br> » et contient les résultats). Cette chaîne de caractères est générée en récupérant le résultat de commandes SQL de type select (exemple : SELECT intituleformation, description FROM `formation` where numformation IN (SELECT numformation FROM `sessionformation` WHERE numsession IN (SELECT numsession FROM `inscription` WHERE numcandidat ="+numstgiaire+" ));). Les résultats, renvoyés dans des ResultSet sont ensuite traités et changés en type String pour être renvoyés à la page.

Projet base de données ss 4.jpg

Comme on peut le constater, un lien est présent en bas de cette page. Il s’agit d’un lien permettant à un utilisateur de se désincrire d’une session. Cette page jsp appelée est développé et expliquée dans la partie gestion des sessions.

Envoi de mot de passe par mail

Fonctionnement

Les stagiaires ne sont pas les seuls à posséder un mot de passe. Tous les utilisateurs doivent donc pouvoir récupérer leur mot de passe lorsqu’ils l’ont oublié. Ainsi, sur la page d’authentification, on rajoute un lien qui va charger une page demandant à l’utilisateur de rentrer son adresse e-mail. Le fonctionnement est identique à celui des sites e-commerce.

Projet base de données ss 5.jpg

L’adresse saisie par l’utilisateur est envoyée à la servlet « CC_envoiMdp » qui vérifie que l’adresse existe dans la base de données, récupère les nom, prénom et mot de passe de l’utilisateur associé et envoi le mail contenant ces informations. Une fois le message envoyé, l’utilisateur est informé du bon déroulement de la demande Pour la création et l’envoi de mail on utilise l’API « Commons Email » d’Apache, qui est une surcouche simplifiant l’utilisation de JavaMail. Cette API est particulièrement adaptée à notre cas puisque le message à envoyer est un simple message texte qui n’exploiterait pas toute la puissance de JavaMail.

Gestion des erreurs

Plusieurs mécanismes sont mis en place (en plus de la gestion d’erreur globale au niveau de l’application) pour limiter les erreurs liées à des entrées utilisateur erronées :

  • Un contrôle de champ utilisant la technologie Javascript permet de vérifier que

l’entrée est non nulle et est bien une adresse email grâce à l’utilisation d’une expression régulière caractérisant ce type de texte.

  • Un champ «état », renvoyé par la servlet d’envoi de mail à la page JSP (où

l’utilisateur rentre son adresse), permet d’informer l’utilisateur si l’adresse fournie n’existe pas dans la base de données.

Projet base de données ss 6.jpg

Gestion des stagiaires par l’administrateur

Avantpropos

Un stagiaire est un utilisateur qui est inscrit à au moins une formation. A ce titre, on peut considérer que les administrateurs voudront pouvoir gérer l’ajout, la suppression et la modification d’utilisateurs en général. A noter qu’un administrateur pourra aussi modifier le profil d’un utilisateur. Avant de continuer, il est important d’expliquer que nous avons fait la distinction entre les administrateurs et le super administrateur. En effet, nous considérons que plusieurs personnes peuvent avoir le statut d’administrateur pour pouvoir, par exemple, enrichir le catalogue ou effectuer une demande de création de formation. Le super utilisateur est le seul à pouvoir s’occuper de gestion des utilisateurs. Dans le cas contraire, n’importe quel administrateur pourrait modifier les profils de tous les autres de manière à garder les droits d’administration pour lui seul.

Fonctionnement

La gestion est accessible depuis l’index des administrateurs mais n’est visible que par le super administrateur. Le fonctionnement est similaire à la gestion des autres entités du système, c’est à dire que l’on a le choix entre « ajouter un utilisateur » et « afficher la liste des utilisateurs ». L’ajout d’un utilisateur amène sur une page contenant les champs à renseigner à l’intérieur d’un formulaire. Une fois le formulaire soumis, la contrôleur (servlet) associé récupère les valeurs de ces champs dans la requête et effectue l’ajout dans la base de données. Sous réserve qu’aucune erreur n’advienne lors de l’ajout dans la base, on affiche la page d’index administrateur avec un message de confirmation. La liste des utilisateurs fait apparaître tous les champs exceptés les formations associées à un stagiaire. La servlet appelée depuis l’index administrateur récupère toutes les données nécessaires dans la base et les fournis à la page JSP affichant la liste. A partir de là, on peut supprimer ou modifier un utilisateur. La modification d’un utilisateur amène à une page contenant toutes ses informations dans des champs texte éditables et des sélections modifiables. Si l’utilisateur est un stagiaire, on affiche la liste des formations auxquelles il est inscrit mais sans pour autant pouvoir y apporter une quelconque modification. La conséquence de cela est l’impossibilité de transformer le profil d’un stagiaire en simple utilisateur tant qu’il reste inscrit à au moins une formation. La soumission du formulaire entraîne l’envoi des champs au contrôleur qui se chargera de mettre à jour la base de données via les classes entités. Lorsque la modification s’est correctement déroulée, on affiche la liste des utilisateurs (mise à jour) avec un message de confirmation. Dans le cas contraire, on affiche un message sur la page de modification (au cas où l’erreur à été prévue). La suppression d’un utilisateur consiste à envoyer le numéro de l’utilisateur à supprimer à la servlet en charge de l’opération, qui effectue les modifications sur la base. Le résultat (échec ou réussite) est affiché sur la liste des utilisateurs qui est rechargée pour correspondre avec le modèle de données.

Gestion des erreurs

Les formulaires contiennent des champs qui doivent être obligatoirement renseignées. On utilise des fonctions en JavaScript pour effectuer les contrôles côté client et éviter de charger inutilement le serveur. Les servlets effectuent diverses opérations, et sont susceptibles de lever des exceptions. Que ce soit pour les opérations effectuées sur la base de données ou des fonctions plus spécifiques comme l’envoi de mail, toutes les erreurs survenant à l’exécution doivent être gérés. On a fait en sorte que chaque servlet renvoi une exception jusqu’au navigateur, tout en restant dans la charte graphique de l’application. Pour cela, une page d’erreur par défaut implémente le traitement et l’affichage des exceptions qu’elle reçoit et permet de revenir en arrière proprement. Cette page est appelée automatiquement à chaque fois qu’une exception est lancée depuis une servlet.

Conclusion

Notre partie consistait donc a gérer les stagiaires (les personnes inscrites aux formations) et les utilisateurs par le super administrateur, à la mise en place d'un système de renvoi de mot de passe par courriel (avec la gestion des erreurs possibles), et à la création de l'environnement du stagiaire (création des liens auxquels il a accès, modification de son profil, et consultation des formations auquel il est inscrit).

Cette partie nous a permis de maîtriser une toute nouvelle API de Java que nous n'avions pas encore exploité. Elle nous a aussi permis de comprendre et d'utiliser la technologie JSP et J2EE avec une architecture MVC. Ainsi, nous avons géré nos pages JSP à l'aide de contrôles implémentés par des servlets.

Nous avons aussi utilisé une méthode de travail nouvelle pour nous, étudiants peu habitués à travailler à plus de deux sur un projet, à savoir : le système de gestion de versions SVN. Cette approche a aussi été très intéressante car c'est une technologie utilisée très couramment dans le monde professionnel.

CONCLUSION SUR LE PROJET

Au niveau du travail en groupe, l’utilisation d’un système de gestion de versions nous a permis de travailler en collaboration comme dans une entreprise en évitant la redondance de code qu’il y aurait sans mise en commun. Le gain de temps n’est pas négligeable en particulier pour rendre la version finale. Il nous a fallu aussi répartir les tâches pour contenter toute l’équipe mais également d’équilibrer la charge de travail au mieux. Après avoir modéliser la base tous ensemble, le travail par binôme a pu se dérouler de manière indépendantes. Au cour du développement, nous avons été amenés à découvrir, apprendre et maitriser une toute nouvelle technologie : le JEE l’utilisation de Servlets mais également l’application du design pattern MVC à ce langage. Chacun d’entre nous a donc acquis de l’expérience dans ce domaine de plus en plus utilisé dans le monde des entreprises développeuses d’applications Web. Au vu de la charge de travail qui nous a été demandé, nous avons tenter de réaliser une plateforme la plus complète possible, et répondant au maximum des attentes et contraintes du cahier des charges. « PolyForm » fonctionne donc et peut être mis en production. Cependant, nous pouvons améliorer cette application avec des options complémentaires. L’architecture et la qualité permet de reprendre facilement notre travail pour une éventuelle évolution.