GEF320 Lab 6

BugBattle version 0.7

Objectif

Ce laboratoire a pour objectif

  • de vous permettre de pratiquer la reconnaissance et la résolution des bris du principe de responsabilité unique;
  • de pratiquer le réusinage;
  • de vous permettre d’implémenter le pattern de la fabrique (Factory Pattern); et
  • vous permettre de réfléchir plus en profondeur à la façon de créer des créature intéressante.

Afin d’atteindre ces objectifs, vous modifierez BugBattle tel qu’indiqué dans la demande de changement de BugBattle v0.7

Remise et date d’échéance

Vous devez remettre votre rapport de laboratoire et le code source par courriel avant le début du prochain laboratoire, vous devez remettre:

  • un rapport de laboratoire concis et bien mis en page (en format pdf) qui contient:
    • une introduction;
    • les réponses aux questions ci-dessous;
    • la documentation de design en UML tel que décrite ci-dessous; et
    • une brève discussion sur ce que vous avez appris, les découvertes que vous avez faites, ce qui a été difficile dans le laboratoire. Soyez concis!
  • Un fichier .zip contenant votre code source complètement documenté avec javadoc (référez-vous au guide de survie d’Eclipse pour les instructions d’exportation); et
  • Vous n’avez pas besoin de remettre les fichiers de vos modèles VP-UML que vous avez utilisé pour créer la documentation. Remettez un fichier pdf.
  • Assurez-vous de combiner le rapport et le fichier .zip dans un autre fichier .zip avant de l’envoyer à l’instructeur.

Tâches

Préparation

Installation

Créez un nouveau projet Eclipse, télécharger et importer BugBattle v0.6, qui est le point de départ pour ce laboratoire.

Comme dans le dernier laboratoire, il y aura plusieurs erreurs signalées par Eclipse parce que le cadre d’applications jUnit 4 ne se trouve pas dans le « build path » du projet. Afin de régler ce problème, ouvrez la classe AllTest, mettez le curseur sur la directive @RunWith, et choisissez l’option d’ajouter jUnit 4.

Exécutez la classe BugBattle afin de vous assurer qu’elle fonctionne. Exécutez la suite des tests jUnit dans la classe AllTests (Run As > jUnit test) et vérifiez que les 59 tests sont exécutés et que la barre jUnit est verte.

Familiarisation avec le code

Générez la documentation javadoc pour le projet dans Eclipse (Project > Generate Javadoc…). Lisez la documentation javadoc et le code source du projet jusqu’à ce que vous le compreniez.

Familiarisation avec la demande de modification

Lisez attentivement et au complet le document de demande de changement de BugBattle v0.7 avant de commencer les modifications.

Implémentation et documentation

Implémentez la demande de modifications. On vous demande d’utiliser une approche de développement piloté par les tests. Il n’est pas possible de vous forcer à travailler de cette façon, mais il est vraiment préférable d’écrire les tests en premier, de diviser le travail en petits incréments, d’écrire le nouveau code d’application avec une barre rouge (test qui échoue), et d’implémenter jusqu’à ce que vous ayez une barre verte.

À mesure que vous créez de nouveaux cas de test, ajoutez-les au groupe de tests (« test suite ») AllTest. Vous pouvez exécuter une classe de test à la fois ou tous les tests ensemble avec AllTest selon votre préférence. En pratique, il est normalement mieux d’exécuter tous les tests après chaque modification. Cette approche vous donne une indication immédiate si vous avez brisé quelque chose.

Écrivez du javadoc au fur et à mesure. Mettez le javadoc à jour au fur et à mesure que vous ajoutez ou modifiez les classes, méthodes et attributs. Vous n’avez pas besoin de fournir du javadoc pour les classes de test, mais elles devraient s’expliquer d’elles-mêmes. Référez-vous aux classes de test fournies pour voir des exemples.

Documentation du design en UML

Fournissez des diagrammes de classe et de séquence qui documentent uniquement les modifications faites dans cette version de BugBattle. Il n’est pas nécessaire de donner un diagramme de classe montrant tout le système, mais seulement les diagrammes de classe des parties modifiées. Utilisez aussi votre jugement pour déterminer quels diagrammes de séquence seraient utiles à la compréhension du fonctionnement de votre code.

Si nécessaire, incluez du texte explicatif avec vos diagrammes. Vous pouvez supposer que le lecteur a accès à votre code et au javadoc. Ne répétez donc pas l’information qui est évidente.

Questions

  1. Quel était le bris du principe de responsabilité unique dans la méthode World.attack que vous avez corrigé avec le changement 0.7.1? Comment l’avez-vous corrigé, c’est-à-dire quelles responsabilités ont été déplacées vers d’autres classes?
  2. Quelles fonctionnalités ont été retirées de World et mises dans la nouvelle classe Simulation dans le changement 0.7.2? Avez-vous aussi déplacé des fonctionnalité de BugBattle vers Simulation? Si oui, lesquelles?
  3. Décrivez votre design pour le senseur d’espèce de créature du changement 0.7.6. Quelle est l’information retournée par votre senseur? Quelles autres options avez-vous contemplées? Quelles sont les raisons de votre choix d’option, c’est-à-dire quels sont les avantages par rapport aux autres options?
  4. Décrivez le design de votre créature plus intelligente pour le changement 0.7.7, incluant son développement (comment et quand elle crée ses organes), sa structure finale et ses stratégies.
Scroll to Top