Sujet du mini-projet :

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

Objectif du projet

Gestion des candidatures à des formations organisées par l'université.

L'université organise des formations. Chaque formation dure environ 15 jours et est ouverte à toute personne intéressée. Les candidats ont une date limite pour s'inscrire (la date dépend de la formation). Après cette date, le responsable de la formation sélectionne les personnes qui suivront la formation. Chaque formation est payante mais le responsable peut accorder des bourses aux meilleurs candidats.

Les informations que les candidats doivent fournir :

Vous supposerez que les candidatures sont adressées par email. L'envoi, la réception des emails et la sauvegarde des photos dans des fichiers locaux ne font pas partie du projet. Pour chaque email l'opérateur de l'université saisit la candidature dans un formulaire affiché sur un ordinateur local ; dans ce formulaire il désigne l'emplacement de la photo du candidat. Les informations sont enregistrées dans une base de données. La photo doit être sauvegardée sous la forme d'un BLOB dans la base de données (pas sous la forme d'un chemin de fichier).

Les informations sur les formations :

Les informations sur le responsable de la formation :

Le responsable de la formation peut consulter les candidatures sur la formation dont il est responsable et les exporter (pas la photo qui ne sera pas exportée) dans un fichier de format Excel pour les manipuler, indiquer les candidats sélectionnés et saisir les montants des bourses attribuées.

Ensuite, l'opérateur lit le fichier Excel et saisit les informations ajoutées par le responsable dans ce fichier Excel. NOUVEAU * Précision : cette lecture du fichier Excel n'est pas automatique (donc pas à coder). L'opérateur lit le fichier et saisit manuellement les nouvelles informations ajoutées par le responsable. *

Votre projet consistera à :

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, mais ne négligez 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).

La persistance devra pouvoir se faire aussi bien avec un SGBD relationnel qu'avec un SGBD objet. Vous utiliserez pour cela les SGBD du cours : Oracle et db4o. Le langage sera le langage Java. Au démarrage de l'application, l'opérateur de l'université indiquera s'il utlise un SGBD relationnel ou un SGBD objet et les informations utiles pour la connexion au SGBD. 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.

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)

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.

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. Pour db4o il suffira de préfixer le nom du fichier qui contiendra les données. 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. Si vous voulez fournir des données dès le début de l'exécution, le projet devra donc créer les données nécessaires (choisissez le moyen que vous voulez du moment où c'est automatiquement fait en lançant les fichiers execute.bat ou execute.sh) juste après que l'utilisateur ait choisi le type de la base de données (Oracle ou db4o). Le test doit pouvoir être lancé plusieurs fois consécutives sans provoquer d'arrêt à cause d'erreurs (vous pouvez donc être amenés à supprimer les tables Oracle au début, ou à vider la base de données). 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 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 lundi 11 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 lundi 15 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

    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

    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.

    Tout projet qui ne respectera pas le format indiqué ci-dessus ne sera pas corrigé. Toute application qui ne respectera pas 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. 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.

    Les remarques, questions, signalements de fautes de frappes ou d'erreurs concernant ce sujet de projet peuvent être adressées à grin@unice.fr.

    Bon travail...

    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.