Projet pour cours Java EE

Sujet

Détaillé dans cette page.

Groupes de projet

Un groupe de projet est constitué de 3 étudiants. 1 ou 2 groupes peuvent être constitués de 2 étudiants seulement si le nombre d'étudiants n'est pas divisible par 3. Pas de "groupe" formé avec un seul étudiant ou avec 4 étudiants.

Un des membres du groupe sera le chef de projet. Il sera l'unique correspondant du groupe avec le correcteur.

La liste des groupes devra m'être envoyée (grin@unice.fr) par le délégué de la classe au plus tard le *** ; le sujet de l'email : "[Projet Java EE Rabat] Liste des groupes". La liste sera de la forme suivante :

RabatA : Nom, prénom et email des étudiants du groupe A, nom du chef de projet
RabatB : Nom, prénom et email des étudiants du groupe B, nom du chef de projet
etc.

Remarque : pour cet email et pour tous les autres envoyés par le chef de projet, sauf exception, merci de mettre en copie les autres membres du groupe. Ils pourront ainsi profiter des réponses éventuelles du correcteur.

Source de données

Il est IMPORTANT de suivre ce qui est dit dans cette section.

Le projet doit utiliser une seule source de données. Lorsque le projet est démarré par la personne qui va tester le projet, la base de données doit être vide. Le projet doit donc lancer la création des tables et des données nécessaires à son fonctionnement. Vous pouvez supposer que l'unité de persistance est configurée avec la stratégie de génération des tables "Create".

L'application doit se lancer sans obliger le correcteur/testeur à définir une nouvelle source de données dans le serveur d'application. La source de données doit donc être définie dans l'application (@DataSourceDefinition) et pas directement dans le serveur d'application.

Si votre projet nécessite l'existence de données dans les tables (par exemple pour créer des utilisateurs) ou si on vous demande de créer un minimum de données pour faciliter les tests, il vous faudra créer les données dans le code du projet.

Vous pouvez automatiser cette création ou demander à la personne qui va tester l'application de cliquer sur un bouton pour lancer l'initialisation. Dans tous les cas, votre code doit bien vérifier que la source de données ne contient pas déjà des données avant de lancer l'initialisation (sinon les données de l'initialisation risquent de se trouver en double dans les tables) et doit afficher un message indiquant le problème à l'utilisateur si c'est nécessaire.

Pour vous assurer que tout fonctionne correctement testez le projet sur une machine qui n'a pas servi au développement du projet.

Comment rendre le projet

Avant d'envoyer le projet, pour vous assurer que tout fonctionne correctement, testez le projet sur une machine qui n'a pas servi au développement du projet. Le mieux est de faire tester par une personne qui n'a pas participé au projet et qui suit les instructions des fichiers readme et du guide utilisateur.

Attention, le non respect d'un point du format décrit dans cette section sera comptabilisé dans la note du projet. En particulier respectez bien les noms des fichiers et répertoires pour faciliter la tâche du correcteur. Une partie loin d'être négligeable de la note sera attribuée à la bonne documentation de votre projet (voir répertoire « documentation » ci-dessous).

Mettez le projet dans un fichier projetRabatA.zip (pour le groupe A ; projetRabatB.zip et projetRabatC.zip pour les groupes B et C, etc.) qui contient un répertoire du nom du fichier zip, par exemple projetRabatA pour le groupe A. Dans ce répertoire mettre les entrées suivantes :

• Un répertoire « projet NetBeans » qui contient tous les fichiers du projet NetBeans. Vous pouvez y mettre un fichier zip obtenu par l'exportation du projet (menu File > Export Project de NetBeans).
• Un répertoire « documentation » qui contient
  • La javadoc (dans un sous-répertoire javadoc),
  • Un guide utilisateur nommé « guide-utilisateur.pdf ». Pour aider la personne qui va utiliser l'application (et donc aussi le correcteur qui va tester l'application). Des copies d'écran seront sans doute utiles pour expliquer ce qu'il est possible de faire, et comment le faire, sur chaque page de l'application. Il devra aussi comporter au début le nom de la base de données ainsi que le nom de l'utilisateur et le mot de passe pour cette base de données. Il doit expliquer comment lancer l'application à partir du fichier zip global du projet.
  • Un guide du développeur nommé « guide-programmation.pdf ». Ce guide explique comment vous avez programmé votre application (par exemple l'architecture de votre application, la structure des classes et des données, etc.) et qui contient ce qui pourrait permettre à un autre développeur de comprendre votre application et éventuellement de la modifier ou d'étendre ses fonctionnalités. Je ne demande pas un document très détaillé mais plutôt un document de 4 ou 5 pages maximum qui décrit les grandes lignes de votre application, en détaillant éventuellement les points délicats (par exemple pourquoi vous avez choisi telle portée pour un backing bean particulier). Un document qui facilitera aussi la correction de votre projet.
  • Un fichier bugs.pdf qui contient 2 sections :
    • les bugs que vous avez repérés dans votre application (sans les avoir corrigés). C'est mieux si vous les détaillez un peu en donnant, si possible, les messages d'erreur ;
    • les fonctionnalités demandées que vous n'avez pas implémentées ou qui n'ont été que partiellement implémentées.
  Les bugs ou les fonctionnalités non implémentées qui ne sont pas signalés dans ce fichier seront plus sévèrement pris en compte dans la note. Ce fichier bugs.pdf doit être présent, même si votre projet est parfait (vous avez tout implémenté et vous n'avez aucune erreur) ; en ce cas vous écrivez dans le fichier "Tout est implémenté sans erreur repérée".
  • Un fichier quiafaitquoi.pdf qui indique
    • ce que chacun des membres du groupe a fait,
    • les sites Web ou autres sources d’information que vous avez principalement utilisés pour votre développement,
    • les portions de code que vous avez récupérées sur le Web ou ailleurs (livres par exemple) pour les mettre dans votre développement. C’est tout à fait autorisé à partir du moment où vous le dites. En revanche, il est interdit de se passer des portions de code entre les groupes de projet.
    • plus généralement, tout ce que vous avez utilisé et qui ne vient pas directement de vous.
  Remarque : n'indiquez pas que tout le monde a participé à toutes les parties du projet ; vous devez vous partager les tâches et chacun doit être responsable d'une partie (même si vous travaillez à 2 sur certaines parties). Un des buts du projet est de vous apprendre à gérer le partage des tâches ainsi que l'intégration des parties développées par chaque membre du groupe. L'idéal serait de vous partager le travail de telle sorte que chacun puisse travailler sur tous les aspects du projet (JSF, EJB, JPA,...).
• Dans la racine du fichier zip, 2 fichiers readme.txt et lisezmoi.txt qui donnent une description très courte du projet, qui décrivent le contenu du fichier zip et qui donnent des informations pour lancer l’application à partir du fichier zip global. Il est conseillé de donner le fichier zip à une personne qui ne fait pas partie du groupe, pour voir si elle arrive à lancer le projet avec les seules informations des fichiers readme ou lisezmoi.

Respectez bien les noms des fichiers et répertoires pour faciliter la tâche du correcteur.

Et n'oubliez pas : le nom du projet NetBeans, TOUTES les ressources du serveur qui peuvent provoquer un conflit de nom, telles qu'un nom de base de données, un pool de connexion, une ressource JDBC,... doivent être suffixés avec le nom du projet (par exemple xyzITUA pour le groupe ITUA).

Récupération du fichier zip

Le fichier zip ne peut être mis en pièce jointe d'un email que si sa taille ne dépasse pas environ 7 Mo (contrainte technique du serveur d'emails du correcteur).

Si la taille est dépassée (vous recevrez un message d'erreur en ce cas), dans un email que vous envoyez à grin@unice.fr, donnez une adresse Web pour aller le récupérer, ou indiquez un moyen quelconque simple pour aller le récupérer (fichier dropbox par exemple). Cet email devra rappeler les noms des étudiants du groupe de projet et avoir un objet qui contient « Projet Java EE Rabat du groupe … » ; indiquez le nom du groupe de projet dans les pointillés (RabatA, RabatB ou RabatC,...).

L’email doit être envoyé par le chef de projet du groupe.

Questions

Le descriptif du sujet est nécessairement incomplet. Beaucoup de détails ne sont pas donnés à dessein pour que chaque groupe puisse écrire sa propre version, différente de la version des autres groupes.

Il se peut aussi qu’il manque des informations ou que des informations ne soient pas assez claires. En ce cas, vous pouvez envoyer un email aux mêmes adresses que pour rendre le projet (grin@unice.fr) en commençant l’objet par « [Projet Java EE Rabat] ».  Tout email qui concerne le projet et qui est particulier à votre groupe doit commencer par ce même texte.

Remarque : pour ces emails, sauf exception, mettez en copie les autres membres du groupe. Ils pourront ainsi profiter des réponses éventuelles du correcteur.

Si vous avez un gros problème technique que vous n’arrivez pas à résoudre, vous pouvez demander aux autres groupes s’ils savent le résoudre (attention, n’aidez pas vos camarades en donnant du code, les projets ne doivent pas comporter du code commun). Si vous n’avez toujours pas la réponse, vous pouvez vous inscrire à des forums pour poser des questions (il y en a plusieurs ; http://stackoverflow.com/ est un bon forum en anglais pour JSF, et pour bien d'autres choses ; http://www.developpez.net/forums/f300/java/developpement-web-java/frameworks/jsf/ en est un autre en français ; il y en a sans doute plein d’autres). En dernier recours, envoyez-moi un email et j’essaierai de vous mettre sur la voie. L’email doit être envoyé par le chef de projet du groupe.

En cas de conflit grave dans un groupe, que vous ne pouvez résoudre (c'est déjà arrivé), contactez-moi. Il est interdit de scinder un groupe sans mon autorisation (qui sera très difficile à obtenir...).

Un conseil : consultez les problèmes relevés après la correction des projets des années passées (une différence avec cette année : pas de mots de passe à conserver).

Date pour rendre le projet

***, à minuit. Aucun dépassement de date autorisé.

[n jours de retard retirent n points (sur 20) à la note du projet. Un projet qui a plus de 4 jours de retard a la note 0.]