Sujet du mini-projet :

Écrire une application pour gérer les services d'enseignement et administratifs dans un département universitaire. Pour simplifier vous supposerez que la gestion se limite à un seul niveau, par exemple à M1 informatique. Les niveaux d'étude ne devront donc pas intervenir.

2 types d'utilisateur pourront utiliser cette application :

Pour simplifier, il n'est pas demandé de gérer des mots de passe, ni de gérer les autorisations pour les différents utilisateurs.

Faites une interface graphique simple (mais ergonomique) ; la richesse de l'interface graphique ne sera pas un critère important pour juger le projet (mais l'ergonomie le sera).

Les données à gérer sont définies ci-dessous.

Les enseignants ont

Par exemple, l'enseignant Pierre Martin est professeur.

Les cours ont

Un cours peut ne pas avoir de CM, de TD ou de TP.

Par exemple, le cours de Compilation consiste en 20 h de CM, 10 h de TD et 20 h de TP. Il a 2 groupes d'étudiants en TD et 4 groupes en TP. Autre exemple : le cours "LaTeX" a 2 groupes de TP (pas de CM ni de TP).

Les services d'enseignement des enseignants sont constitués de groupes d'étudiants pour un type d'enseignement. Par exemple, Pierre Martin a la charge du CM, d'un groupe de TD et de 2 groupes de TP pour le cours de compilation.

Les services d'enseignement sont calculés en "heures équivalent TD" (hTD). Une heure de TD vaut une 1 hTD ; une heure de CM vaut 1,5 hTD et une heure de TP vaut 1/1,5 hTD.

Un enseignant doit un certain nombre d'hTD suivant sont statut. Un PR ou un MC doit 192 hTD. Et donc l'enseignant Pierre Martin doit effectuer 192 hTD. Un PRAG doit 384 hTD.

Un enseignant peut aussi faire des tâches administratives qui sont prises en compte dans les services qu'il doit. Une tâche administrative peut être, par exemple, la coordination du département ou la gestion des stages organisés par le département. Chaque tâche administrative correspond à un certain nombre d'hTD. Par exemple la gestion des stages correspond à 20 hTD.

Un minimum de données seront insérées par l'application dans la base la première fois que l'application est exécuté, ou les fois suivantes si la base ne contient pas de données (ne rien faire si la base contient déjà des données) pour pouvoir tester tout de suite certaines fonctionnalités. En particulier, les informations sur les cours ; vous pouvez prendre par exemple les cours que vous suivez en M1.

Les fonctionnalités de l'application devront au moins comporter (si ces fonctionnalités sont parfaitement implémentées et documentées vous aurez déjà une très bonne note) :

Quelques contraintes techniques (pour permettre les tests par le correcteur et pour vérifier que vous avez bien assimiler le cours) :

Ce format est vraiment obligatoire. 2 objectifs principaux à ces contraintes :

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.

L'application a 2 types d'utilisateur :

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.

Consitution des groupes de projet

Chaque groupe de projet doit comporter 4 membres (à la rigueur 3 ou 5 si le nombre total d'étudiants n'est pas divisible par 4). 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 le correspondant de l'enseignant en cas d'échanges de messages. La constitution des groupes devra être envoyée à grin@unice.fr avant le mercredi 22 octobre minuit (0,5 point en moins par jour de retard), avec l'adresse du site Web du projet et le suffixe choisi par le groupe de projet pour les noms de la base de données (voir ci-dessous dans les sections "Site du projet" et "La base de données").

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 "Services des enseignants").

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).

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 suffixe unique parmi tous les projets reçus par le correcteur. Pour cela vous suffixerez 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 et Dupuis et si une table contient des cours la table s'appelera COURS_DDDR. N'oubliez pas que les noms de contraintes et d'index sont globaux et il faudra donc aussi les suffixer. 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 COURS_DDDR2. En revanche, les classes Java ne devront pas être suffixées ; par exemple, la classe s'appellera Cours, et pas CoursDddr. Pour db4o il suffira de suffixer le nom du fichier qui contiendra les données. Les projets qui ne respecteront pas cette clause ne seront pas corrigés.

Le test du projet devra partir d'une base de données vide. Le projet devra donc créer les données nécessaires à son exécution (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 (supprimez donc les tables Oracle au début).

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 :

Comment rendre le projet

Le projet devra être rendu avant le mercredi 12 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 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 suffixe choisi par le groupe (par exemple dddr) ;
  • comporter en plus l'adresse (cliquable s'il vous plait !) 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.

    Toute application qui ne respectera pas le format indiqué ci-dessus et les contraintes données plus haut ne sera pas corrigée. Idem pour les applications qui ne seront pas documentées ou qui auront, par exemple, une javadoc sans information véritable. 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...