Sujet du mini-projet :

Problèmes éventuels (une parenthèse pour répondre à une question posée récemment)

Question posé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.

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

Objectif du projet

Écrire une application pour faire des dessins constitués de formes géométriques. Votre projet consistera essentiellement à écrire la partie qui gère la persistance des dessins.

Les grands points du code

Vous pouvez récupérer le source de la partie dessin sur le Web (API de dessin ou petit programme). Il vous faudra sans doute adapter ce source pour qu'il convienne au projet. Si vous trouvez une API qui convienne exactement, vous pouvez l'utiliser sans avoir le source.

La partie "persistance" devra être personnelle (ne récupérez pas du code déjà écrit). Elle devra comporter obligatoirement des DAOs et une fabrique abstraite pour pouvoir changer facilement de support de persistance. Les supports de persistance seront :

Quelques précisions

Cette section décrit ce qui vous est demandé. Certains points ne sont pas obligatoires (mention "optionnel"). Concentrez-vous sur les parties obligatoires. Un projet ne comportant que les parties obligatoires peut avoir une très bonne note s'il est très bien écrit. Une partie optionnelle ne compensera pas une partie obligatoire absente ou mal écrite.

Au début de la session de travail, l'utilisateur indique avec quel type de support il souhaite travailler.

L'utilisateur peut alors choisir de dessiner un nouveau dessin ou de récupérer un ancien dessin déjà sauvegardé sur le support de persistance choisi au début de la session. Optionnel : un plus serait de pouvoir changer de support de persistance en cours de session pour retrouver un dessin qui n'est pas sur un certain support.

Un dessin a un nom qui peut servir à l'utilisateur pour le désigner, par exemple "la tête à Toto".

Types de dessins

Oblligatoirement un dessin pourra comporter les formes géométriques simples segment, cercle, rectangle et polygone.

Le code devra distinguer au moins 2 types de dessin : les dessins qui ne contiennent qu'une seule forme géométrique simple, et les dessins qui contiennent plusieurs formes géométriques, et même plusieurs dessins (pensez aux lots du TP sur le mapping).

Il doit être possible de réutiliser un dessin dans un autre dessin, en changeant sa taille (en faisant une homothétie ; les proportions sont gardées) et en le positionnant dans l'autre dessin.

Un dessin appartient à une catégorie pour que l'utilisateur puisse le retrouver plus facilement pour l'incorporer dans un autre dessin (catégorie "sport", ou "informatique" par exemple).

Optionnel : Vous pouvez ajouter d'autres types de dessins si vous le voulez. Vous pouvez aussi ajouter d'autres types d'attributs aux dessins si vous le voulez.

Pour toute cette partie vous pouvez libérer votre imagination, mais attention à ne pas vouloir en faire trop. L'essentiel est de fournir à la fin un logiciel qui fonctionne et qui effectue correctement la persistance des dessins.

Fonctionnalités de l'application

Pour résumer, 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 faciliter les tests par le correcteur et pour vérifier votre savoir-faire) :

Ces contraintes techniques sont vraiment obligatoire. 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.

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 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 dessins la table s'appelera DESSIN_DDDR. N'oubliez pas que les noms de contraintes et d'index sont globaux dans Oracle 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 DESSIN_DDDR2. En revanche, les classes Java ne devront pas être suffixées ; par exemple, la classe s'appellera Dessin, et pas DessinDddr. 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 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 dessins 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).

Constitution 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 lundi 26 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).

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 dimanche 22 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.

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