BallWorlds
CSSE 221 – Fundamentals of Software Development Honors
Fall 2009–2010

Instructions

• Use pair programming for this exercise.

• Be quick to ask questions of your instructor, student assistants and classmates as desired.

• This project has a Project Report.
  • Both you AND your partner should do the report, each in your own Angel account but collaborating on your answers.

  Consider: When you see “Consider” in red, where do you go to report your answer to that question?

  • Hint: You go to the report for the exercise, located in Angel ~ Lessons ~ Project Reports.
  • Go to Angel now and report your answer to this (and ONLY this) question.

  Consider: When you see “Consider” in red, do you:

  • Go to the Angel report to answer that question right at that time, or do you
  • Wait until you have done the rest of the exercise?

  Consider: When you see “Consider” in red, at that point do you answer:

  • Only the single question in that “Consider”, or
  • All the questions in the Angel report?

  Consider: After you answer a “Consider”-in-red question, the answer to the question is displayed. Do you:

  • Read that answer and make sure that you understand it (asking your instructor for help if you don't), or
  • Ignore the answer that appears?

Overview: Demo and Basic Specification

Here is a summary specification of BallWorlds:

The project constructs and displays Worlds that contain various kinds of Balls that behave in various ways. For example: One kind of Ball (Bouncer) might move in the world and bounce off the World's boundaries, another (Shrinker) might grow and shrink in size, and yet another (Dud) might do very little at all. The user can construct instances of the various kinds of Balls, drag them around and kill them.

Your instructor will demo an implementation of BallWorlds. Here is a screen shot of BallWorlds that shows what the finished project should look like.

We have provided a framework in which to work. Your job is to implement the various kinds of Balls, with their different behaviours, per the instructions below.

Design

1. UML (Unified Modeling Language) class diagrams are used primarily for two purposes:

   • First, project designers use them during the design phase of larger projects to brainstorm the roles/responsibilities of each class and the relationships between classes.
   • Second, they can then be used during the implementation phase to communicate the design to the implementors of the project.

   We are using UML for the second purpose in this BallWorlds project.

   Examine the UML class diagram for BallWorlds. Focus on the Ball class on the right-hand-side of the diagram, since the subclasses of Ball are the portion of the BallWorlds project that you will implement. (We will supply an implementation of the rest of the project.)

   Refer to BallWorld's UML class diagram to answer the following questions:

   1. There are six classes that are Balls: Dud, DudThatMoves, Mover, Bouncer, Shrinker and Exploder. These are the classes that you will eventually implement.

      These six Ball classes extend the Ball interface, which in turn extends five interfaces: Drawable, Animate, Selectable, BallDescriber and Morphable.

      Consider: True or false: Each of your Ball classes must implement all five of the interfaces that Ball extends (possibly by inheriting the implementation from a superclass).

   2. Read the Drawable documentation.

      Consider: According to the Drawable documentation, what should a Ball be able to do?

   3. Read the Animate documentation.

      Consider: According to the Animate documentation, what should a Ball be able to do?

   4. Read the Selectable documentation.

      Consider: According to the Selectable documentation, what should a Ball be able to do?

   5. According to BallWorld's UML class diagram, each Ball has a World, where World is an interface that extends the BallManager and WorldDescriber interfaces. Read the World documentation and the documentation of the BallManager and WorldDescriber interfaces.

      Consider: According to the World documentation, what method would be useful to a Ball for the Ball to appear at a random location in its World?

   6. According to the note attached to Ball in BallWorld's UML class diagram:

      Consider: How does a Ball acquire its World?

   7. Ball classes have attributes (characteristics). For example, according to the UML:

      Consider: A Dud has what attributes in addition to its World?

   8. There is a blue note in the lower-right-corner of BallWorld's UML class diagram.

      Consider: According to that note in the lower-right-corner, all your subclasses of Ball should be in what package?

   Important: You must take full advantage of inheritance in this project to get full credit!

   Stage 0 - Checkout the Project

2. Open Eclipse.
3. Checkout your BallWorlds project.
   • As usual, use the SVN Repository Exploring Perspective; if needed, see the JavaEyes instructions to remind yourself how to checkout a project from your individual repository for this course.

Stage 1: Implement a Dud

4. You will implement BallWorlds in stages, one Ball class per stage. This is called iterative enhancement.

   Read the instructions in this box before continuing. For each stage: First, READ the description of the Ball class to be implemented in that stage. Second, ANSWER the questions in the instructions for that stage. Third, ADD a class for that stage with DOCUMENTED STUBS. Important: Use Quick Fix to add the stubs for you! Do NOT type the method headers yourself! Important: After using Quick Fix to add the stubs, generate the Javadoc html documentatation, noting that the stubs are already documented (from the documentation of the interfaces that your class implements). Add Javadoc comments only where that generated documentation is inaccurate or incomplete. Fourth, IMPLEMENT and TEST the Ball class to be implemented in that stage. For example, first read the description below of a Dud, then answer the questions about the Dud class, then generate the stubs and document as necessary, and finally implement and test your Dud class.

   A Dud is a Ball that merely appears on the screen. It should appear in a random location (otherwise, they will all appear on top of each other), with any reasonable size and color.

   Consider: According to the UML class diagram for BallWorlds, how many methods must any Ball (including a Dud) have?

   Consider: Given that a Dud basically does nothing, what method(s) must you convert from stubs to working code? (The rest of the methods can remain as stubs.)

   Consider: According to BallWorld's UML class diagram, what fields should a Dud have?

5. AFTER you answer the above questions in your report:
   1. Add a Dud class with generated stubs and document Dud as necessary.
   2. Implement and test your Dud class.

   Commit your work to the repository after completing this stage.

Stage 2: Implement a DudThatMoves

6. A DudThatMoves should behave exactly like a Dud (including random location), except that it moves, on its own, in a straight line (i.e., a constant velocity). It can move at any reasonable speed you choose -- try numbers like 0.1 for starters. Each new Ball type's color should be different from colors of the Ball types that you already implemented.

   You need to use inheritance here. A DudThatMoves is very similar to a Dud, and you should exploit that similarity by inheriting functionality from the Dud.

   The framework calls act() on each Ball every 20th of a second or so. So, a DudThatMove's act() method is the place to change the DudThatMove's position.

   Consider: According to BallWorld's UML class diagram, what field(s) should a DudThatMoves have (in addition to its inherited fields).

   Consider: What method(s) must DudThatMoves override?

7. AFTER you answer the above questions in your report:
   1. Add a DudThatMoves class with generated stubs and document DudThatMoves as necessary.
   2. Implement and test your DudThatMoves class.

   Commit your work to the repository after completing this stage.

Last reminder that for each stage you read the specification, answer the questions, add a class with documented stubs, and only then implement and test your class. Don't forget to commit your work to the repository every time you complete a stage.

Stage 3: Implement a Mover

8. A Mover should start in the exact middle of its world (even if its world is resized). Each Mover should have its own fixed velocity that is set at random when the Mover is constructed. The random velocity should be in any reasonable range that includes all directions (not just the "positive" direction).

   Additionally, the Mover should be "selectable", "draggable", and "killable" by the mouse.

   Remember, each new Ball type needs to be a different new color.

   Referring to BallWorld's UML class diagram as necessary:

   Consider: What class implements both MouseListener and MouseMotionListener (and hence responds to mouse events)?

   Consider: The World responds to a mouse-press by selecting the Ball nearest the mouse (and showing this by turning that Ball red while the mouse is pressed). Which Ball method(s) must be implemented in order for this Ball-selecting to work correctly?

   • Note: you will probably want to implement that method back in the Dud class, so that Dud's and DudThatMove's won't always be selected.
   • Hint: you don't have to remember the distance formula; a Point2D already knows it!

   Consider: The World responds to a mouse-drag by (repeatedly, throughout the drag) telling the selected Ball to move to the current mouse-point. Which Ball method(s) must be implemented in order for this Ball-dragging to work correctly?

   Consider: The World responds to a mouse-left-click (i.e. press and release) by telling the selected Ball to toggle between the paused and not-paused state. (So, if the Ball is acting, it should stop acting; while if it is not acting, it should resume acting.) Which Ball method(s) must be implemented in order for this Ball-pause-resume to work correctly?

   Consider: The World responds to a mouse-right-press by telling the selected Ball to kill itself, that is, to have itself removed from its World. Which Ball method(s) must be implemented in order for this Ball-suicide to work correctly?

   In summary, you don't need to deal with the mouse directly. The framework does that for you. For example, pauseOrResume() is called on the nearest Ball whenever the user clicks the mouse. By implementing pauseOrResume(), you are saying what should change when a Ball is paused.

Stage 4: Implement a Bouncer

9. A Bouncer should behave just like a Mover, except that it bounces off the edges of its World.

Stage 5: Implement a Shrinker

10. A Shrinker should behave just like a Bouncer, except that as it moves/bounces, it also shrinks and expands, as follows:
    • Stage 1: It picks a random size between 0 and its initial size, and shrinks to that in small increments (through the act method).
    • Stage 2: When it reaches that random size, it picks a random size between its initial size and 4 times its initial size, and grows to that in small increments (through the act method).
    • Stage 3: The process then repeats, picking a new random number for the size to shrink/grow to, at each iteration of shrinking/growth.

    A Shrinker should neither move nor shrink/grow when in the paused state.

Stage 6: Implement an Exploder

11. An Exploder should behave just like a Bouncer, except that as it moves/bounces, it also:
    • Stage 1: It picks a random size between 1 and 10 times its initial size, and grows to that in small increments (through the act method).
    • Stage 2: When it reaches that random size, it dies (and hence is no longer in the World, hence is no longer drawn, etc).
    • Stage 3: When it reaches that random size, it also constructs two new Exploders, each starting where the original Exploder died.

    It shouldn't grow or explode when in the paused state.

    Consider: According to BallWorld's UML class diagram, Exploder should extend Bouncer. Why is that preferable to extending Shrinker?

Stage 7: BONUS - “Implement's Choice”

12. Design a Ball with its own special properties, extending an appropriate existing Ball class.

    Bonus points will vary from just a couple points for something that basically just copies something else that a Ball can do (like just using random colors), to up to 50% bonus for something really original, cool-looking, and non-trivial! Possibilities (of varying difficulty) include:

    • Teleporters teleport themselves to another World when they explode!
    • Poppers pop balls that they intersect!
    • Rebounders rebound off other balls!
    • Wormholes -- when a ball enters a wormhole, it emerges in another World!

    You can do the Bonus Ball(s) independently (not pair programming), if you wish. The partner whose name is alphabetically first should do a Bonus1 class while the other partner does a Bonus2 class.

    • You will need to add "Bonus1" and "Bonus2" to the STANDARD_BALLS field of the BallButtons class.
    • Eclipse should be happy with you working on these separate files, separately. But stay away from concurrent modification of the other classes, else you may need to resolve conflicts.
    • Use inheritance whereever appropriate!

Stage last: Turn in your work (i.e., commit your project)

13. Make sure that your project has correct style. Make sure that there is appropriate HTML documentation for all your public methods (inheriting appropriate documentation from interfaces is fine).
14. Commit your BallWorlds project to the repository from which you checked it out.
    • You can look at the JavaEyes instructions to remind yourself how to commit a project to the repository from which it was checked out.