Le projet en M1 Maths pour 2004-2005

Sujet

L'énoncé du travail à faire est donné ici.

Quelques modifications par rapport à cet énoncé :

But du projet

Un des buts de ce mini-projet est de vous faire pratiquer Swing, l'API pour les interfaces graphiques et l'API sur les entrées-sorties. Vous devrez soigner particulièrement l'interface graphique de votre application. Arrangez-vous, par exemple, pour utiliser le plus grand nombre de composants et de possibilités de Swing (fenêtres de dialogue, boutons, listes, menus, barres d'outils, onglets, bulles d'aide, raccourcis clavier, etc.; voir par exemple, ici) sans que ce soit artificiel. Soignez l'ergonomie, point important d'une bonne interface graphique. Compte tenu de ce but, il est interdit d'utiliser un outil pour créer/dessiner l'interface graphique. Vous devez le faire "à la main".

Il est nécessaire d'être en binôme ; il faut apprendre à travailler en groupe.

Un autre but important (sans doute le plus important) est de vous faire pratiquer les grands principes de programmation que vous avez appris : encapsulation (par exemple, pas de variables publiques sauf exceptions très rares, et le moins possible de variables protected), modularité, extensibilité (utilisation du polymorphisme en particulier), réutilisabilité, documentation de l'application (javadoc en particulier pour une application Java, mais il faudra aussi certainement ajouter des informations pour bien documenter votre application : comment l'installer, l'exécuter, des schémas UML,...), etc.

Vos classes devront appartenir à des paquetages (obligatoire !).

Vous séparerez le plus possible l'interface graphique des classes "métier" (par exemple les classes qui représenteront l'arbre). Vous pouvez commencer à réfléchir sur les classes "métier" de votre application, même si vous ne savez pas encore bien programmer une interface graphique.

Site du projet

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

Son adresse (cliquable) devra être envoyée par mail à grin@unice.fr du cours au plus tard le 3 mai, en même temps que la constitution des binômes. A cette date le site pourra ne comporter que le titre du projet et les noms des participants. Vous y indiquerez ensuite (au moins) l'état d'avancement du projet (avec les dates des étapes) et les liens vers des sites que vous aurez utilisés pendant le développement. A la fin du projet, un lien pointera vers la page finale du projet (présentation du projet, exécutable,...).

Le contenu de ce site comptera dans la note finale (la forme est secondaire ; inutile de passer trop de temps dessus).

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 :

IMPORTANT : comment rendre le projet

Le projet devra être rendu le 28 mai au plus tard (tout dépassement aura un impact négatif sur la note).

Pour rendre le projet, envoyez un message électronique à l'adresse grin@unice.fr . Un seul message par binôme.

Le sujet du message sera du type "Projet M1 maths de toto et titi".

Le corps du message devra être concis et

  • rappeler le projet choisi et les noms des étudiants du binôme
  • comporter l'adresse (cliquable s'il vous plait !) de la page du projet sur le Web.
  • Le fichier zip sera attaché au message (indispensable car vous serez noté sur ce fichier zip et pas sur celui que l'on pourra trouver sur votre page web ; vous pourrez donc améliorer votre projet après l'avoir rendu). Ce fichier zip devra aussi être accessible et récupérable depuis la page Web du projet.

    Évitez d'envoyer plusieurs messages pour un même projet. 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). 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é
    2. l'extensibilité
    3. l'ergonomie (faites tester par une personne étrangère au développement...)

    de l'application.

    Toute application qui ne respectera pas le format indiquée dans cette page 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.

    On préfère de très loin une application qui fait le minimum (indiqué ci-dessus) mais qui le fait bien, d'une façon robuste et conviviale et bien documentée, à une application avec beaucoup de fonctionnalités mais qui se plante ou qui est difficile à utiliser.

    Bon travail...