Sujet du mini-projet :

Cette page est très détaillée mais peut comporter des lacunes, des contradictions ou des erreurs. N'hésitez pas à m'envoyer un email en cas de doute (mais lisez bien le texte ci-dessous avant de poser une question).

Objectif du projet

Aide pour l'envoi des notes aux étudiants.

Un enseignant de l'université souhaite envoyer individuellement les notes de ses étudiants par email.

Les notes sont enregistrées dans une base de données. Les noms des étudiants sont fournies à l'enseignant dans des fichiers Excel (ou format compatible Excel 2007). L'enseignant utilise lui-même un tableur pour faire quelques calculs complexes.

L'enseignant ne doit pas réinitialiser sa base chaque année et, de toute façon, il souhaite garder dans la base un historique des notes pour pouvoir suivre l'évolution de ses étudiants. Par exemple, dans la base il y aura les notes du cours POO pour les années 2011-12 et 2010-11.

Vous devrez modéliser les informations suivantes :

Fonctionnalités demandées :

Remarque : ce projet concerne la persistance des données. Cette partie sera donc importante pour la note attribuée au projet. Ne fignolez pas trop le reste de l'application (pas besoin d'avoir des belles interfaces utilisateur). Ne négligez cependant pas l'ergonomie ; testez votre logiciel sur une personne qui n'a pas participé à son développement et voyez s'il peut s'en servir sans trop faire appel au manuel utilisateur (pensez à l'enseignant qui va corriger votre projet).

La persistance devra pouvoir se faire aussi bien avec le SGBD relationnel Oracle, avec JPA. Le langage sera le langage Java. Au démarrage de l'application, l'opérateur de l'université indiquera s'il utilise un SGBD relationnel ou un autre type de persistance. Toute la partie de l'application qui ne concerne pas l'implémentation de la persistance devra être indépendante du type de persistance utilisé, comme vous l'avez appris en cours. Il devra être possible d'implémenter facilement un autre type de persistance et vous utiliserez donc une fabrique abstraite mais on ne vous demande pas d'implémenter un autre type de persistance que JPA.

Quelques précisions

Quelques contraintes techniques

Ces contraintes techniques permettront de faciliter les tests par le correcteur et de vérifier votre savoir-faire :

Ces contraintes techniques sont vraiment obligatoires. Tout manquement sera pénalisé par des points en moins.

Vous pouvez utiliser tout IDE que vous voulez à partir du moment où vous comprenez tout le travail effectué plus ou moins automatiquement par cet IDE. Evidemment l'exécution de l'application doit être indépendante de cet IDE (le correcteur pourra lancer l'application même s'il n'a pas cet IDE). C'est important que vous le vérifiiez !

Vous devez respecter les grands principes de programmation que vous avez appris : encapsulation (par exemple, pas de variables publiques, et le moins possible de variables protected), modularité, extensibilité (du polymorphisme en particulier plutôt que des "switch" s'il y a de l'héritage), réutilisabilité, documentation de l'application (javadoc en particulier pour une application Java), etc.

Vous séparerez le plus possible l'interface graphique, les classes "métier" et la couche de persistance.

La documentation est particulièrement importante. Le correcteur ne devra pas passer trop de temps à comprendre le code et l'architecture globale de l'application devra être expliquée, si nécessaire. Il est inadmissible de rendre une application mal documentée et donc les projets non ou mal documentés seront fortement pénalisés. Un conseil en passant : écrivez la documentation au fur et à mesure de l'écriture de l'application et pas au dernier moment. La javadoc est absolument indispensable.

Le correcteur doit pouvoir tester rapidement l'application dans son propre environnement, depuis sa propre machine, avec sa propre base de données.

La base de données

Très important : pour éviter les problèmes d'homonymie sur les noms d'entités (tables, index, séquences,...) manipulés par la base de données Oracle utilisée par le correcteur, les noms de toutes les entités devront avoir un préfixe unique parmi tous les projets reçus par le correcteur. Pour cela vous préfixerez les noms de ces entités par les initiales des noms de chacun des participants au projet. Par exemple, si les auteurs du projet sont Dupond, Durand, Robert, Pierre et Dupuis et si une table contient des formations la table pourra s'appeler DDDPR_FORMATION. N'oubliez pas que les noms de contraintes et d'index sont globaux dans Oracle et il faudra donc aussi les préfixer. De même, si vous utilisez la génération automatique des identificateurs par une table, n'oubliez pas de préfixer le nom de la table (ou de la séquence) qui sert à la génération automatique des clés. Vérifiez qu'il n'y a pas d'homonymie avec un autre groupe ; si c'est le cas, ajoutez un numéro, par exemple DDDPR2_FORMATION, ou, plus simplement, changez de préfixe. En revanche, les classes Java ne devront pas être préfixées ; par exemple, la classe s'appellera Formation, et pas DddprFormation. Les projets qui ne respecteront pas cette clause ne seront pas testés et recevront la note "d'exécution" en conséquence.

Le test du projet devra partir d'une base de données vide. Le test doit pouvoir être lancé plusieurs fois consécutives sans provoquer d'arrêt à cause d'erreurs. Au moment du choix de la base de données, l'opérateur pourra réinitialiser la base s'il le souhaite, en cochant une simple option.

Site du projet

Chaque binôme devra écrire un site Web pour le projet.

Son adresse (cliquable dans l'email) devra être envoyée par mail en même temps que la composition du groupe. A cette date le site pourra ne comporter que le titre du projet et les noms des participants. Vous y indiquerez ensuite (au moins)

Le contenu de ce site, et sa mise à jour régulière au fur et à mesure de l'avancement du développement comptera dans la note finale (la forme est secondaire ; inutile de passer trop de temps dessus).

Si vous le souhaitez, vous pourrez donner au correcteur un mot de passe pour accéder à ce site (dans le même email que celui qui donnera la composition du groupe et l'adresse du site Web du projet).

Format obligatoire pour rendre le mini-projet :

Le projet devra être fourni sous forme d'un fichier zip (pas de tar.gz ou autres formats) contenant tout sur le projet (vous devez respecter les noms des fichiers donnés ci-dessous) :

IMPORTANT :

Constitution des groupes de projet

Chaque groupe de projet doit comporter 6 membres (à la rigueur 5 si le nombre total d'étudiants n'est pas divisible par 6). Un des buts essentiel du projet est de vous apprendre à travailler en groupe. Chaque groupe doit comporter un chef de projet qui coordonnera le travail du groupe, veillera à la bonne marche du développement et sera l'unique correspondant de l'enseignant en cas d'échanges de messages ou au moment de rendre le projet. La constitution des groupes devra être envoyée à grin@unice.fr avant le dimanche 16 octobre minuit (0,5 point en moins par jour de retard), avec :

Toute question sur le projet devra être envoyée à grin@unice.fr par le chef de projet. Soyez précis et indiquez bien qui vous êtes (nom, prénom) et dans quelle filière vous travaillez (M1 info, projet "Candidatures pour formations"). Utilisez toujours la même adresse de retour pour les emails.

Comment rendre le projet

Le projet devra être rendu avant le jeudi 17 novembre minuit (1 point en moins par jour de retard). Aucun projet ne sera accepté avec plus de 3 jours de retard.

Pour rendre le projet, envoyez un message électronique à grin@unice.fr. Un seul message par groupe. Le sujet du message sera du type "Projet M1 info Modèles de persistance de Brouhami, Gonzalvès, Dupond, Durand, Robert et Dupuis". En cas d'homonymie, précisez le prénom.

Le corps du message devra

  • rappeler le projet choisi et les noms des étudiants du groupe ;
  • le préfixe choisi par le groupe (par exemple dddpr) ;
  • comporter en plus l'adresse (cliquable s'il vous plait pour un message lu en HTML !) de la page du projet sur le Web.
  • Le fichier zip (pas un autre format de compression, svp) attaché au message devra comporter tout votre travail sur ce projet (relisez le début de cette page). Ce fichier zip devra aussi être accessible et récupérable depuis la page Web du projet (4 jours après la date limite pour rendre le projet), mais seul le fichier zip envoyé par mail sera utilisé par le correcteur.

    Évitez d'envoyer plusieurs messages pour un même projet. Pour éviter des envois erronés, testez si tout va bien en vous envoyant d'abord le message et en vous plaçant dans un environnement neutre (par exemple pas sur la machine qui contient votre page Web et vos répertoires de développement) pour le tester, comme si vous étiez le correcteur. Pour le cas où la taille de votre fichier zip serait supérieure à 10 Mo (souvent une taille limite pour envoyer des emails), décomposez-le en 2 ou 3 fichiers zip (le moins possible) envoyés dans 2 ou 3 emails. Si vous envoyez plusieurs emails, tout votre code devra être dans un seul des fichiers zip et les jar que vous aurez utilisés dans les autres fichiers zip. Seule la première version envoyée sera prise en compte pour la correction.

    Notation

    Normalement, tous les membre du groupe auront la même note, sauf problème signalé dans le fichier quiafaitquoi.

    Il sera tenu le plus grand compte de

    1. la lisibilité (repectez en particulier les conventions du langage Java)
    2. l'extensibilité
    3. l'ergonomie (faites tester par une personne étrangère au développement pour voir s'il arrive à utiliser l'application sans trop lire la documentation...)
    4. la documentation
    5. la bonne implémentation de la persistance

    de l'application.

    Une application qui fait le minimum mais qui le fait bien, d'une façon robuste et conviviale et bien documentée, sera préférée à une application avec beaucoup de fonctionnalités mais qui se plante ou qui est difficile à utiliser et pas extensible. Les fonctionnalités optionnelles réunies ne compteront pour pas plus de 3 points au total ; elles sont surtout là pour motiver les meilleurs groupes ou étudiants.

    Tout projet qui ne respectera pas le format indiqué ci-dessus ne sera pas corrigé. Toute application qui ne respectera pas les contraintes données plus haut ne sera pas testé. Le code des applications qui ne seront pas documentées ou qui auront, par exemple, une javadoc sans information véritable ne sera pas étudié. Il est temps de prendre des bonnes habitudes pour ceux qui ne les ont pas déjà (une toute petite minorité évidemment...).

    Le correcteur n'essaiera pas de faire fonctionner une application qui ne démarre pas en lançant le fichier execute (ne comptez pas sur lui pour chercher les bugs à votre place). Le projet n'aura donc aucun point sur tout ce qui concerne l'exécution. A ce niveau vous devez être capables de faire fonctionner un fichier jar.

    Pour finir, une question qui se pose chaque année :

    Que doit-on faire si un des participants au projet met en péril le projet en ne faisant pas son travail ?

    Réponse :

    Le chef de projet doit intervenir rapidement car une intervention trop tardive peut occasionner l'échec pour tout le groupe (et une note en conséquence pour tout le groupe).

    Si le participant ne fait pas son travail par mauvaise volonté, le chef de projet doit le rappeler à l'ordre (soyez diplomate, svp). S'il ne participe toujours pas, le chef de projet répartit ses tâches entre les autres participants et signale le problème dans le fichier "quiafaitquoi".

    Si le participant ne fait pas correctement son travail parce que son niveau est insuffisant, le chef de projet peut le faire aider ponctuellement par un autre membre du projet. Si cette aide ne suffit pas car son niveau est vraiment insuffisant, le chef de projet lui donne un tâche plus facile et répartit son ancienne tâche entre les autres membres. En ce cas, il faut signaler le problème dans le fichier "quiafaitquoi".

    En cas de profondes divergences entre membres du groupe, que le chef de projet ne peut résoudre, signalez-le à l'enseignant qui peut essayer d'intervenir.

    Cela signifie qu'une partie non négligeable de ce que l'on attend du chef de projet devrait être de se tenir au courant de l'avancement des différentes tâches. Il faut en tenir compte dans la répartition des autres types de tâches (codage en particulier). Ceci n'est qu'un conseil, chaque groupe est libre de s'organiser comme il l'entend.

    Bon travail...