Sujets de mini-projets

Un seul sujet :

Voici le sujet.

Autres sujets :

Si vous avez de très bonnes raisons (et uniquement dans ce cas), vous pouvez proposer votre propre sujet. Il devra comporter une interface graphique et des entrées-sorties non triviales. Le sujet devra recevoir l'accord des 3 enseignants.

Vous pouvez choisir votre sujet jusqu'au 4 avril. Chaque binôme devra alors envoyer un e-mail à l'adresse grin@unice.fr pour rappeler le sujet choisi (un seul message par binôme).

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 trop artificiel. Faites de même avec l'API sur les entrées-sorties.

Compte tenu de ce but, il est interdit d'utiliser un outil de dessin d'interface graphique pour ce projet.

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

Il est nécessaire d'être en binôme ; il faut apprendre à travailler en groupe. Les étudiants seuls devront en expliquer la raison avant de commencer à travailler sur le projet.

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é (du polymorphisme en particulier plutôt que des "switch"), réutilisabilité, documentation de l'application (javadoc en particulier pour une application Java), etc.

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

Vous séparerez le plus possible l'interface graphique des classes "métier" (par exemple l'architecture des classes qui représenteront les figures dessinées). 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 4 avril (dans le message où vous donnez le sujet que vous avez choisi). 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 contenant tout sur le projet :

Vous pouvez aussi ajouter un diagramme de classe et des explications sur l'architecture de votre application qui expliquent l'articulation de vos classes et paquetages au correcteur et aux futures développeurs intéressés par votre projet. Mettez-le dans le fichier zip et indiquez où ils se trouvent par un lien dans la page Web du projet.

IMPORTANT :

IMPORTANT : comment rendre le projet

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

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

Le sujet du message sera du type "Projet licence info de toto et titi"

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.
  • Le fichier zip 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 er récupérable depuis la page Web du projet, mais seul le fichier zip envoyé par mail sera utilisé par le correcteur.

    Evitez 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 et vos répertoires de développement) pour le tester. 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. Il est temps de prendre des bonnes habitudes pour ceux qui ne les ont pas déjà (une toute petite minorité évidemment...).

    On préfère de très loin une application qui fait le minimum (indiqué dans le sujet) 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 et pas extensible. Les fonctionnalités ajoutées au minimum demandé n'auront pas une grande influence sur la note (pas plus de 5 points sur 20

    Bon travail...