BugBattle version 0.7

Objectives

The objectives of this lab are to

  • give you practice recognizing and resolving violations of the Single Responsibility principle;
  • to practice Refactoring;
  • to allow you to implement the Factory Method Pattern; and
  • to let you think more about building interesting creatures.

To achieve these aims, you will extend BugBattle as documented in the BugBattle v0.7 Change Request

Submission

Your lab must be submitted by e-mail to This email address is being protected from spambots. You need JavaScript enabled to view it. not later than the date and time specified on the course schedule. Submit:

  • Your lab report in PDF format. The report should consist of
    • an introduction,
    • answers to the questions below,
    • the UML design documention described below (enclosed in the PDF lab report and not in separate files),
    • a discussion of what you learned, discovered or found difficult while completing the lab. Be concise!
  • A .zip containing your fully javadoc commented source files (see the Eclipse survival guide for export instructions).
  • You are not required to submit the VP-UML model file(s) you used to create your documentation.

Tasks

Preliminaries

Installation. Create a new Eclipse project and then download and import BugBattle version 0.6, which is the starting point for this week’s lab.

As last lab, there will be several errors reported by Eclipse because the jUnit 4 framework is not on the build path for the project. To fix this, open the class AllTest, hover the cursor over the @RunWith directive, and choose the offered option to add jUnit 4.

Run BugBattle to ensure it works. Run the jUnit test suite in AllTests (Run As > jUnit test) and ensure that 59 tests run and the bar comes up green.

Code familiarization. Generate javadoc documentation for the project in Eclipse (Project > Generate Javadoc…). Review the javadoc and the project source code until you are sure you understand it.

Change request familiarization. Carefully read the complete change request document for BugBattle v0.7 before beginning the modifications.

Implementation and documentation

Implement the change request using TDD. You are asked to use a Test-Driven Development approach. We can't force you to do this (especially once you leave the lab) but it really is a much better idea to write the tests first, then the code, working in very small increments, always writing new code against a “red bar” (failing test) and implementing only until you have a “green bar”.

As you create new test classes, add them to the AllTest test suite. Note that you can run either a single test class or the AllTest suite, as you prefer. In practice, it's generally better to run all tests after every change — this gives you immediate warning if you break something.

javadoc as you go. Update the javadoc for your new or modified classes, methods, and attributes as you proceed. You do not need to provide javadoc for your test classes; however, they should be completely self-explanatory. See the provided test classes for examples.

UML design documentation. Provide class and sequence diagrams documenting only what has changed in this version of BugBattle. This means that you do not need to provide a class diagram of the complete system; just class diagrams of the parts of the system that have changed. Similarly, use your judgement in determining what sequence diagrams would be useful to someone trying to learn how your code works.

If necessary, provide explanatory text with your diagrams. You can assume that the reader will also have access to your code and javadoc comments, so don't reproduce anything that should be obvious.

Questions

1. What was the Single Responsibility violation in the World.attack method that you addressed in change 0.7.1? How did you address it, i.e., what responsibilities were moved to other classes?

2. What functionality moved out of World into the new Simulation class in change 0.7.2? Did you also move any functionality from BugBattle to Simulation, and if so, what?

3. Describe your design for the "kind of creature" sensor in change 0.7.6. What information does your sensor return? What other options did you consider? Why did you choose the option you did, i.e., what advantages does it offer over the other option?

4. Describe the design of your smarter creature for change 0.7.7, including its development (how and when it grows organs), its ultimate structure, and its strategies.