Flame Maker – Rendu final

Afin de faciliter l'évaluation de votre programme, vous devez vous assurer qu'il affiche au démarrage la fractale Shark fin colorée avec la palette interpolant entre les couleurs rouge, vert et bleu et une qualité de 50. Vous devez également prendre soin d'initialiser les champs représentant les paramètres des transformation avec les valeurs indiquées dans l'étape 9, à savoir :

En résumé, votre application au démarrage doit donc ressembler le plus possible à la copie d'écran ci-dessous, qui est la même que celle de l'étape 9.

Pour ce rendu, vous devez soumettre toutes les classes du projet. Les classes du paquetage ch.epfl.flamemaker.IFS sont optionnelles de même que toutes les classes principales produisant des images dans des fichiers.

Pour cette deuxième soumission, nous vous demandons d'utiliser le même script que lors de la première et de soumettre l'archive .jar ainsi créée sur Moodle.

Afin d'éviter tout problème lié aux groupes, chaque membre du groupe doit soumettre une même archive sur Moodle. Merci également de renseigner dans chaque fichier, les noms, prénoms et numéros SCIPER des membres du groupe. A cet effet, vous pouvez par exemple utiliser l'étiquette @Author de Javadoc.

Si pour une quelconque raison vous deviez rater le délai et qu'il ne vous soit donc plus possible d'effectuer votre rendu via Moodle, veuillez envoyer votre archive par courrier électronique à Michele Catasta (michele.catasta@epfl.ch).

Attention : vos points seront réduits de 10% par heure entamée après 19:00, l'heure de réception de l'e-mail faisant foi. Par exemple un e-mail reçu entre 20:00:01 et 21:00:00 impliquera une réduction de 20% des points. Si vous envoyez l'e-mail après 5:00 du matin suivant, vous n'obtiendrez aucun point. Pour éviter tout problème, nous vous recommandons fortement de soumettre une première version fonctionnelle de votre code dès que possible et de la mettre éventuellement à jour par la suite, mais au plus tard à la date limite mentionnée plus haut.

Nous baserons l'évaluation du code pour 40% sur l'évaluation du comportement de l'interface graphique. Pour ce faire nous vérifierons la bonne exécution du programme lors du lancement de la méthode main de la classe ch.epfl.flamemaker.gui.FlameMaker, ainsi que la ressemblance visuelle avec le programme de référence. Le comportement de chaque bouton sera testé systématiquement avec différentes valeurs.

Les 60% restants des points seront attribués après une lecture attentive du code, 50% en fonction des éventuelles erreurs dans les fonctionnalités qui n'auraient pas été déjà sanctionnées lors du test de l'interface et 10% en fonction de la qualité du code. A cet effet, nous avons compilé une liste de ce que nous estimons être les bonnes pratiques à respecter pour coder en Java. Cette liste n'est pas exhaustive et est principalement basée sur le guide de bonnes pratiques proposé par Oracle :

• Le code est proprement indenté. Eclipse peut indenter un fichier automatiquement en sélectionnant la totalité de son contenu (menu Edit > Select All) puis en le ré-indentant en sélectionnant l'entrée Correct Indentation du menu Source.
• Toutes les méthodes et classes sont commentées en utilisant la syntaxe de Javadoc. Vous pouvez choisir de le faire en français ou en anglais, mais n'utilisez qu'une langue dans tout votre projet. Eclipse peut vous aider à générer ces commentaires Javadoc en plaçant le curseur sur l'élément à commenter (classe, attribut ou méthode) puis en sélectionnant l'entrée Generate Element Comment du menu Source. Certains attributs sont automatiquement générés, à vous de compléter les commentaires judicieusement.
• Les parties de code complexes sont commentées afin de fournir des informations supplémentaires.
• Les composants des classes et interfaces apparaissent toujours dans l'ordre suivant :
  1. Les variables statiques triées par visibilité (les variables publiques en premier, puis les protégées, ensuite les variables sans modificateur de visibilité et enfin les variables privées).
  2. Les variable d'instance, également triées par visibilité.
  3. Les méthodes, triées par fonctionnalité et non par visibilité (p.ex. une méthode privée peut-être entre deux méthodes publiques si elle est utilisée uniquement par la première).
• Toutes les classes, variables et méthodes sont correctement nommées en anglais et en camel case, c-à-d que les mots qui forment un nom sont collés les uns aux autres et, à l'exception éventuelle du premier, commencent tous par une majuscule.
• Les noms de classes et d'interfaces commencent par une majuscule, les noms de variables et de méthodes par une minuscule. Les constantes sont nommées en majuscules avec des tirets bas "_" entre les mots. Les noms doivent avoir un sens, mais pas forcément être longs. Par exemple il est communément accepté de nommer i un index ou x et y des coordonnées.
• Le code est concis, clair et évite la duplication inutile. L'utilisation de variables pour les expressions se répétant plusieurs fois comme par exemple Math.pow(p.r(), 2) dans la variation Swirl est recommandée.
• Les exécution inutiles sont évitées. Par exemple, lors de la transformation d'un point, en vérifiant si le poids d'une variation est non nul avant de la calculer. Attention ce genre d'optimisation ne doit pas se faire au détriment des points ci-dessus.
• Les expressions booléenne sont utilisées de façon intelligente, par exemple :
  • if (e) return true; else return false;
    (remplacer par return e;),
  • if (e) return false; else return true;
    (remplacer par return !e;),
  • if (e == false) …
    (remplacer par if (!e) …).

Cette soumission doit être faite séparément de la version de base. Vous devez fournir une archive zip structurée ainsi :

• src/ : dossier contenant le code source de votre application,
• dist/flameMaker.jar : archive jar contenant une version compilée de votre code,
• doc/rapport.pdf : fichier contenant le rapport, voir ci-dessous,
• lib/ : dossier contenant les éventuelles bibliothèques externes utilisées, ou à installer.

En plus du code mettant en œuvre l'amélioration, un petit rapport la décrivant doit également être rendu. Ce rapport, d'une longueur comprise entre 400 et 800 mots (par amélioration ajoutée), décrit d'une part l'amélioration elle-même du point de vue de l'utilisateur et d'autre part sa mise en œuvre en Java. Le rapport, au format PDF et nommé rapport.pdf, doit être placé dans le dossier doc de l'archive.

L'archive ainsi créée doit être envoyée par mail à michele.catasta@epfl.ch dans les mêmes délais que ceux du rendu normal. Par contre, tout envoi en retard ne sera pas pris en compte et aucun bonus ne sera compté.

Le bonus sera évalué selon l'échelle annoncée lors de la dernière étape. Si l'exécution de votre programme nécessite des étapes préliminaires telle que l'installation d'une bibliothèque externe, veuillez le mentionner clairement dans votre rapport et fournir toutes les indications nécessaires pour une exécution correcte, faute de quoi le bonus ne sera pas pris en compte.