:: Enseignements :: ESIPE :: E4INFO :: 2008-2009 :: Interface graphique ::

CheatIRs

But du projet

Sujet mis à jour le 12 janvier 2009

Vous devrez réaliser un programme permettant de faire des simulations de lancers de dés, afin de détecter des dés truqués.

Les dés

Les dés sont définis par l'interface Dice. Votre application devra proposer une liste contenant deux types de dés prédéfinis: le dé normal et le dé truqué de base. Votre application devra proposer dans un menu la possibilité de charger un fichier jar contenant de nouveaux dés, en utilisant le ClassLoader. Pour être un dé valide, un objet contenu dans le jar devra respecter les conditions suivantes (les méthodes de Class vous seront utiles):

implémenter l'interface Dice (attention à ne pas changer son package!)
posséder un et un seul constructeur déclaré
ce constructeur ne doit posséder que des paramètres de type int, float ou String
ce constructeur doit être annoté avec une annotation de type DiceDescription, retournant un tableau de String
la taille de ce tableau doit correspondre au nombre de paramètres du constructeur plus un

Si toutes ces conditions sont remplies, vous ajouterez ce dé à la liste des dés proposés par votre application.

La phase de configuration

Votre application devra proposer un item de menu permettant de démarrer une session de travail, en remplacement de la précédente s'il y en avait déjà une en cours. Une session débute par la configuration des dés. Vous devrez demander à l'utilisateur combien de dés il veut pour chacune des sortes proposées (exemple: 4 dés normaux et 2 dés truqués). Ensuite, vous demanderez à l'utilisateur de paramétrer les dés pour lesquels il y a un constructeur avec des paramètres. Pour cela, vous générerez une boîte de dialogue en fonction des paramètres attendus et en utilisant la description fournie par l'objet. Pour FakeDice, ça devrait ressembler à quelque chose comme ça:

Au clic sur "OK", vous devrez récupérer les valeurs fournies et tenter de créer l'objet dé (un constructeur de dé peut lever une exception). Une fois que tous les dés auront été convenablement configurés, l'application devra permettre de passer à la phase de test des dés.

La phase de test

L'application devra proposer un champ de saisie dans lequel l'utilisateur indiquera le nombre de lancers qu'il souhaite. Une fois une valeur N saisie et validée, l'application devra générer N tirages des dés et les présenter dans une liste. Une case à cocher devra permettre de choisir entre un affichage des valeurs respectant toujours le même ordre pour les dés et un affichage où les valeurs des dés sont mélangées à chaque ligne. Attention dans ce dernier cas à ce que l'affichage d'une case reste constant dans le temps (on ne veut pas que les cases changent au hasard à chaque rafraîchissement). Par exemple, si on a choisi 6 dés truqués donnant toujours le même chiffre, l'affichage standard ressemblerait à ceci:

4 2 2 3 5 1
4 2 2 3 5 1
4 2 2 3 5 1
4 2 2 3 5 1

alors que l'affichage mélangé donnerait quelque chose comme ça:

2 4 2 5 1 3 
3 5 2 1 4 2
2 4 1 3 5 2
5 3 2 1 2 4

Dans la partie droite de la fenêtre, on veut pouvoir visualiser les nombres de 1, 2, 3, 4, 5 et 6 qui sont sortis sous la forme de diagrammes. Une telle analyse doit être paramétrée par 2 éléments:

une sélection des dés que l'on veut prendre en compte (tous les dés, juste le troisième, les deux derniers, etc)
une valeur D d'échantillonnage. Cette valeur sert à déterminer en combien de sous-parties on va découper nos lancers. Par exemple, si on a 1000 lancers et une valeur d'échantillonnage de 100, on veut décomposer les lancers en 10 groupes de 100 lancers, avec un histogramme pour chaque groupe, ce qui pourrait donner quelque chose comme ceci (ceci est un graphique Open Office; inutile de faire exactement pareil, c'est juste une source d'inspiration):

On veut pouvoir avoir plusieurs analyses en même temps, comme par exemple: un échantillonnage de 50 sur le dé numéro 3 et un échantillonnage de 400 sur tous les dés. Votre application devra donc permettre de placer plusieurs panels d'analyses dans la partie droite de la fenêtre, en gérant le scrolling si nécessaire. L'utilisateur devra bien évidemment povoir ajouter des analyses, mais également pouvoir en retirer. Voici par exemple ce qu'on pourrait voir pour 2 analyses, la première comportant 10 groupes de lancers et la seconde un seul:

Les points critiques du projet

Le rafraîchissement

En cours de session, l'utilisateur devra pouvoir refaire les lancers, éventuellement en changeant leur nombre. L'application devra entièrement se rafraîchir, aussi bien la liste des lancers que toutes les analyses sous forme d'histogrammes. Cet aspect du projet est fondamental, aussi apportez-y grand soin si vous voulez obtenir une note raisonnable.

Les diagrammes

Vous devrez créer un composant Swing pour afficher des diagrammes, en veillant à détacher l'UI du composant logique. Vous proposerez 2 UI différents: l'un qui affiche sous forme d'histogramme, l'autre sous forme de camembert. Un clic sur un diagramme devra permettre de basculer d'un UI à l'autre pour le diagramme sur lequel on aura cliqué.

Les dés

Le chargement des dés ainsi que leur paramétrage ne doivent pas rebuter l'utilisateur. Vous ferez donc attention à produire une application la plus ergonomique possible (par exemple, réinitialiser tous les champs de saisie pour un dé sous prétexte qu'un champ int contenait "abc", ce n'est pas agréable).

Conditions de rendu

Vous travaillerez en binômes. En premier lieu, vous lirez avec profit la charte des projets pour éviter des bavures malheureuses. Vous rendrez ensuite une archive nommée login1-login2.zip contenant les choses suivantes:

un répertoire src contenant les sources du projet ainsi qu'un build.xml. Lorsqu'on lance ant, on doit obtenir un exécutable nommé CheatIRs.jar. La cible clean doit fonctionner correctement. Les sources doivent être propres, en anglais et commentées.
un fichier doc.pdf contenant votre rapport qui devra décrire votre travail. En particulier, vous décrirez avec soin et en les justifiant tous vos choix d'architecture, en particulier sur le MVC. Si votre projet ne fonctionne pas complètement, vous devrez en décrire les bugs.

Il est interdit d'utiliser du code externe: vous devrez tout coder vous-mêmes.
Tout code commun à plusieurs projets vaudra zéro pour tous les projets concernés.

Le projet est à rendre par mail à tous les enseignants (i.e. Sébastien Paumier, Matthieu Constant et Sylvain Cherrier), au plus tard le lundi 18 mai 2009 à 23h.