Master Professionnel I2A Spcialit Intgration de Systmes Logiciels

Un Annuaire des Anciens tudiants du Master

Premire partie : les tapes 1 et 2

Janvier 2010

Yannick LORENZATI Stphanie MALAKIAN

Prsentation
Lobjectif de ce mini-projet est de grer laide de la technologie JEE un annuaire des tudiants du Master deuxime anne, limage de lannuaire actuel du Master. Le cahier des charges de lannuaire est assez simple : Trois entits seront manipuler : Des tudiants, Un administrateur, Des promotions.

Au niveau des fonctionnalits : Gestion de lauthentification des tudiants et dun administrateur. Possibilit de consulter la liste des promotions. Possibilit de consulter la liste des tudiants de chaque promotion. Opration de destruction / modification / ajout dtudiants et de promotions dans lannuaire par ladministrateur aprs authentification. Possibilit pour un tudiant de modifier ses propres informations aprs authentification. Envoi de mail aux tudiants en cas doubli de leur mot de passe pour le leur rappeler.

Ce mini-projet se dcoupe en trois tapes : 1. la couche de stockage, 2. la couche mtier, 3. la couche de prsentation. Lobjectif de ce document est de prsenter et dexpliquer notre travail concernant les tapes 1 et 2.

Etape 1 : La couche de stockage

1. Conception et cration de la base de donnes
1.1. Conception

Comme indiqu dans le chier des charges, nous allons manipuler les trois entits suivantes : Un tudiant (entit Student ) possdant obligatoirement : un ID, un login, un mot de passe, un nom, un prnom. Il possde ventuellement : une adresse postale, une adresse mail, un nom de socit (dans laquelle il a effectu son stage), un commentaire (quelques phrases), une date de mise jour de ses informations dans lannuaire, et un site web. Un administrateur (entit Admin ) possdant : un ID, un login et un mot de passe. Une promotion (entit Promotion ) possdant : un ID, une anne, un titre et une description (quelques phrases).

Au niveau des relations : Nous avons mis en vidence une relation Un-Plusieurs entre les entits Student et Promotion : en effet, un tudiant appartient exactement une promotion, et une promotion regroupe plusieurs tudiants. Quant lentit Admin , elle nest en relation avec aucune des autres entits.

Voici un diagramme de classes rsumant ce qui vient dtre nonc :

1.2.

Cration de la base de donnes

Pou reprsenter ces entits, nous avons choisi dutiliser une base de donnes relationnelles, en utilisant le SGBD MySQL (version 5).

2. Persistance des JavaBeans : technologie JPA

Le package annuaire.beans contient les trois JavaBeans permettant de reprsenter les trois entits de lannuaire. Pour grer la persistance de ces JavaBeans, nous utilisons la technologie JPA ( Java Persistence API ). Nous mettons en JPA pratique via le framework Hibernate, qui nous sert de fournisseur de persistance (utilisation de Hibernate-Annotations et Hibernate-EntityManager). Lutilisation de JPA va nous permettre de grer le passage du modle relationnel au modle objet ( mapping objet/relationnel ).

2.1.

DAO : Data Access Object

Voici les diffrentes oprations quoffre notre couche de service daccs aux donnes (DAO) : Ajouter / Modifier / Supprimer une promotion Ajouter / Modifier / Supprimer un administrateur Ajouter / Modifier / Supprimer un tudiant Rechercher une promotion (avec ou sans les tudiants qui la composent) avec limite du nombre de rsultats Rechercher un tudiant avec limite du nombre de rsultats Rechercher un administrateur avec limite du nombre de rsultats

Lister les ID des tudiants dune promotion partir Lister les ID de toutes les promotions de lID de celle-ci

2.2.

Architecture

Pour mettre en place la DAO, nous avons organis notre package annuaire.dao comme suit : Linterface IAnnuaireDao : elle est indpendante du choix de JPA. La classe JpaAnnuaireDao : elle implmente linterface IAnnuaireDao.

Pour valider les mthodes mises en uvre dans notre implantation, nous avons cr une classe de test dans le package annuaire.dao.test :
JpaAnnuaireDaoTest : classe de test unitaire JUnit 4, qui teste toutes les mthodes de la classe JpaAnnuaireDao.

2.3.

Mapping Objet / Relationnel

Annotations Pour assurer le mapping entre classes Java et tables relationnelles, nous utilisons les annotations Java 5 dans chacun de nos JavaBeans. Notons que nous nos tables proprement parl nexistent pas dj, elles sont cres daprs les annotations indiques dans les classes. Pour mettre en uvre la relation Un-Plusieurs entre Student et Promotion , nous avons utilis lannotation @ManyToOne (relation principale) place sur le champ promo de lentit Student . Nous avons choisi de mettre en uvre la relation inverse (qui nest pas indispensable) grce lannotation @OneToMany place sur le champ listStudents de lentit Promotion . Cela, dans un but de commodit pour obtenir les tudiants dune promotion, sans passer par une requte JPQL. EntityManager Pour analyser les paramtres de connections (fichier /META-INF/persistence.xml) et pour pouvoir ouvrir des connections vers la base de donnes, nous utilisons un objet EntityManagerFactory. Pour grer un contexte de persistance, nous utilisons des objets EntityManager : toute opration sur le contexte de persistance se fait lintrieur dune transaction (utilisation dobjets EntityTransaction). Gestion optimiste Nous utilisons lannotation @Version dans nos trois JavaBeans, pour pouvoir grer plus tard les accs concurrents une mme ligne dune table. JPQL Les requtes prsentes dans notre DAO utilisent le langage JPQL ( Java Persistence Query Language ) : contrairement au langage SQL, les requtes font intervenir des objets (plutt que des tables).

Etape 2 : La couche mtier

La technologie RMI : Remote Method Invocation
Linterface mtier vers notre annuaire des anciens tudiants se fait sous la forme dun serveur RMI.

Architecture
Voici comment est organise notre architecture, dans le package annuaire : Le package rmi.remotedObject regroupe quatre interfaces : IRemotedAnnuaire, IRemotedUser, IAdminService, IStudentService. Dans rmi.remotedObject.impl se trouvent les quatre classes implantant respectivement ces interfaces : RemotedAnnuaire, RemotedUser, AdminImpl et StudentImpl.

Quelques explications :

- Les classes AdminImpl et StudentImpl hritent toutes les deux de la classe RemotedUser. - La classe RemotedUser implante IRemotedUser, elle permet de reprsenter un utilisateur identifi (donc implmente une mthode de logout). Deux mthodes permettant de grer les droits : selon si lutilisateur est un tudiant, il aura accs aux services de IStudentService, ou si cest un administrateur, il aura accs aux services de IAdminService. - De plus, la classe AdminImpl implante les interfaces IAdminService et IStudentService. En effet, en plus davoir accs aux services propres ladministrateur seulement (comme par exemple lajout dune promotion), un administrateur peut galement effectuer des oprations quun tudiant peut faire (comme par exemple la mise jour dun tudiant). Le package rmi.server contient linterface IRmiServer, qui va reprsenter notre serveur RMI. Dans rmi.server.impl : la classe RmiServer implante linterface IRmiServer. Cest le serveur qui va crer le registre et publier une unique instance de RemotedAnnuaire (singleton). De plus, le serveur se charge de lauthentification des utilisateurs (publication de plusieurs instances dAdminImpl et de StudentImpl. ( ?????) Dans rmi.server.test (CORRIGER ?) se trouve la classe de test unitaire JUnit 4 RmiServerTest qui teste toutes les mthodes de la classe RmiServer.

A terminer : Parler des transactions RMI ? Dtailler un peu plus les mthodes Un peu mal dit, reformuler.