Sujets de mini-projets

Un des buts de ce mini-projet est de vous faire pratiquer Swing, l'API pour les interfaces graphiques. Vous devrez donc soigner particulièrement l'interface graphique de votre application Arrangez-vous, par exemple, pour utiliser le plus grand nombre de widgets 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 trop artificiel.

Vous voulez quelques images ? Vous en trouverez quelques unes ici. Il y en a certainement de bien meilleures sur le Web ; charchez un peu.

Le code devra être bien documenté, fourni sous forme d'un fichier zip contenant les pages Web de présentation, le code exécutable (si possible sous forme de fichier jar), la javadoc (à mettre donc dans le fichier zip), un éventuel fichier d'installation et 2 exécutables intitulés execute.sh et execute.bat. Et que tout ceci ne vous empêche pas d'expliquer dans votre page Web et dans un fichier readme (ou lisez-moi) tout ce qu'il faut pour installer et exécuter votre application. Si votre (vos) page Web contient un diagramme de classe et/ou des explications sur l'architecture de votre application, ça n'est pas plus mal.

  1. Interface graphique conviviale pour programmer des récupérations de fichiers par ftp (par exemple la nuit à 2 h du matin). Si vous arrivez à aller voir régulièrement sur un site si la version fournie a changé, c'est encore mieux (même si votre algorithme ne marche pas à tous les coups).
  2. Poser des QCM, afficher ou non la réponse et donner la note finale (chaque question pourra être à une réponse ou à réponses multiples). Prévoir une possibilité de limiter le temps pour chaque réponse ou pour tout le questionnaire. Pour ceux qui connaissent (ou veulent connaître), les QCM seront écrits en XML. Les autres feront comme ils veulent.
  3. Interface graphique conviviale pour établir des factures et les afficher (prendre une base d'articles comme dans les TP, sous forme d'une collection ou d'une map sérialisée sur disque). Imaginez une caisse enregistreuse avec écran d'ordinateur. Ça serait bien de pouvoir imprimer les factures.
  4. Dans le cadre d'une société de vente de forfaits pour les remontées mécaniques des stations de sports d'hiver de la région, écrivez pour le responsable une interface graphique conviviale lui permettant de gérer les ventes de plusieurs billeteries de forfaits (une pour chaque station). Cette application devra permettre - entre autres - de :
Vous pouvez proposer votre propre sujet. Il devra comporter une interface graphique non triviale.

Vous pouvez choisir votre sujet jusqu'à la semaine après les vacances. Une interface graphique devant être le plus indépendante possible des classes qui font vraiment le travail, vous pouvez commencer à réfléchir sur les classes de votre application, même si vous ne savez pas encore programmer une interface graphique (les interfaces graphiques seront étudiés dans le cours du 25 avril et un peu dans celui du 9 mai, le cours du 2 mai étant vraisemblablement remplacé par une conférence).

Le projet devrait être rendu le 10 mai, on repoussera la limite au 17 mai pour tenir compte de la conférence du 2 mai (aucun dépassement possible de cette dernière date pour ne pas gêner les autres projets).

N'oubliez pas les grands principes de programmation que vous avez appris : documenter l'application (javadoc en particulier pour une application Java), encapsulation, modularité, extensibilité (du polymorphisme en particulier plutôt que des "switch"), réutilisabilité. Pour cela, vous séparerez le plus possible l'interface graphique des classes "métier", vous utiliserez des paquetages, pas de variables public (sauf exceptions très rares), etc...

IMPORTANT : comment rendre le projet

Quand vous avez choisi votre projet, envoyez un message électronique à l'adresse grin@unice.fr .
Ce message devra comporter dans le sujet
  • le projet choisi
  • les noms des étudiants du binôme
  • Le corps du message devra
  • rappeler le projet choisi et les noms des étudiants du binôme
  • comporter en plus l'adresse (cliquable s'il vous plait !) de la page du projet sur le Web.
  • Un fichier zip attaché au message devra comporter tout votre travail sur ce projet : code source, exécutable, documentation (javadoc et autre), page Web, fichier readme ou autre, etc.

    Tout manquement à ces règles (qui sont destinées à faire gagner du temps au correcteur qui va recevoir un grand nombre de projets de plusieurs promos d'étudiants) sera pris en compte dans la notation. :-((

    Evitez d'envoyer plusieurs messages pour un même projet. Testez si tout va bien en vous envoyant d'abord le message. Seule la première version envoyée sera prise en compte pour la correction.

    Dans le fichier readme vous rendrez à César ce qui lui appartient en indiquant les sources, paquetages, articles ou autres que vous avez utilisés (adresses Web où les obtenir si possible).

    Ca serait bien d'avoir un document qui explique l'articulation de vos classes et paquetages au correcteur et aux futures développeurs intéressés par votre projet.