GEF320 Lab 4

Labo 4: BugBattle version 0.3

GEF320 Hiver 2016

Objectif

Les objectifs de ce laboratoire sont l’introduction du pattern de design « Null Object », de vous permettre de pratiquer la résolution de problèmes de conception simples, et de vous permettre de pratiquer la création des documents de conception en format UML en utilisant l’outil VP-UML.

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. Veuillez remettre:

  • un fichier .zip contenant votre code source avec commentaires (référez-vous au guide de survie d’Eclipse); et
  • un rapport de laboratoire concis et bien mis en page (en format pdf) qui contient:
    • une introduction;
    • vos réponses aux questions ci-dessous;
    • la documentation UML telle 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!

Tâches

Installation

Créez un nouveau projet Eclipse et télécharger et importer BugBattle v0.2, qui est le point de départ pour ce laboratoire. Exécutez la classe BugBattle pour s’assurer qu’elle fonctionne.

Familiarisation avec le code initial

Générez la documentation javadoc pour le projet dans Eclipse. Lisez la documentation javadoc et le code source du projet jusqu’à ce que vous le compreniez.

Familiarisation avec la demande de modification

Ce laboratoire est structuré comme une activité d’entretien et d’amélioration tel que vous trouveriez dans un projet réel. Lisez attentivement le document de demande de modification de BugBattle v0.3. Vous trouverez ci-dessous une vidéo montrant le produit attendu.

Implémentation et documentation

Implémentez les modifications demandées et modifiez le javadoc en même temps. Nous vous encourageons fortement à implémenter les modifications dans l’ordre donné et à vérifier que chaque modification fonctionne bien avant de continuer à la prochaine étape. C’est aussi une bonne idée de générer et de regarder le javadoc au fur et à mesure que vous l’écrivez afin de vous assurer qu’il est clair.

Documentation du design en UML

Rappel: Pour copier un diagramme de VP-UML à un document, sélectionnez les éléments du diagramme voulu, et choisissez Edit > Copy > To Clipboard as Vector Image (WMF)** ou … as Vector Image (PDF)*.

  1. Fournissez un diagramme de classe de votre système final semblable à celui fourni dans la spécification de BugBattle v0.1. Il n’est pas nécessaire de montrer les classes et les interfaces qui viennent de la bibliothèque standard Java dans votre diagramme. Vous pouvez utiliser la fonction « instant reverse » de VP-UML. Vous devrez réorganiser le diagramme de classe pour plus de clarté et ajouter toutes les dépendances importantes.

  2. Fournissez un diagramme de séquence montrant le fonctionnement du mouvement en utilisant l’organe Cilia. Votre diagramme devrait être semblable à celui pour le « Déplacement des créatures » dans la spécification de BugBattle v0.1 du laboratoire 3. Il n’est pas nécessaire de montrer les boucles ni les cas alternatifs. Documentez simplement le cas normal dans lequel le mouvement réussit.

  3. Fournissez un diagramme de séquence montrant le fonctionnement de la méthode sense de la classe EnergySensor. Les mêmes instructions que celles de la partie 2. s’appliquent (boucles, cas alternatifs, etc.).

Questions

Répondez aux questions suivantes dans votre rapport de laboratoire (incluez les questions):

  1. Lors de la génération de documentation javadoc, vous avez le choix du niveau de visibilité à produire. Lorsque vous avez généré la documentation javadoc initiale, vous avez utilisé une visibilité de private. Essayez maintenant de générer la documentation javadoc avec une visibilité public. Qu’est-ce qui a changé? Parcourez la spécification de l’API Java SE 8 fournie par Oracle. À quel niveau de visibilité est-elle générée? Expliquez pourquoi vous voudriez peut-être générer des versions différentes de la documentation javadoc et pour qui?

  2. Il y a deux types différents de boucle « for » utilisés dans la classe World. Par exemple, dans la méthode initialize:

    for (int ix = 0; ix < WORLD_SIZE; ix++) {
    locations.add(null);
}

    Et dans la méthode doTurn:

    for (Creature c : creatures) {
      c.doTurn();
 }

    Expliquez la différence entre ces deux types de boucles « for ». Dans quelles circonstances peut-on utiliser chaque type, et dans quelles circonstances serait-il interdit?

  3. Recherchez le terme « génie aller-retour » (round-trip engineering). Croyez-vous que le technique génie aller-retour serait utile dans la production d’un produit évolutif comme BugBattle? Expliquez votre opinion.

Scroll to Top