CSC 171
Homework 4

Assigned Feb. 27, due March 9

Design Recipe

For each programming problem below, you should follow a 6-step recipe:

1. Contracts: Choose names and data types as necessary for the problem at hand. Write these down on paper or in a text file, or (if you prefer) directly as javadoc comments in your program file. (You can write javadoc comments for methods you haven't written yet; they won't show up in the generated Web page until you write at least a method header, but that's OK.)

2. Write test cases: a sequence of things you plan to do, and what effect each one should have, in order to confirm that it works correctly. For this assignment, the "results" are essentially all pictures on the screen, so the JUnit TestCase feature won't help much. If you wish, you can use it for the Buggle problem, or if you prefer, you can write the test cases in a file, with precise descriptions of what should be drawn on the screen for each one. For the Applet problems, the way you test the program is presumably to just run the applet, but for each successive version of the program you should describe in advance what you expect it to draw.

3. Write the Java code. This step can be broken down into

   1. write a skeleton. For a class, this is the word "class", the name of the class, perhaps an "extends" clause, and a pair of curly-braces. For a method, this is an access specifier (like "public"), the return type, the method name, a pair of parentheses enclosing a parameter list, and a pair of curly-braces.
   2. if you're writing a method, write down a list of available ingredients: any parameters to the method, as well as the implicit parameter "this", along with their data types. Then, if some of them are class objects, start listing their parts, e.g. "this.x", "this.y", etc.
   3. fill in the details until the method does what it's supposed to.

4. Proofread the code, looking for misspellings, mismatched braces, missing semicolons, etc.

5. Compile the code. If there are syntax error messages, log them for future reference, fix them, and return to the "Proofread" step above, until there are no error messages.

6. Test the code: in DrJava, you can do this by typing into the Interactions window the things you said you were going to try, or by hitting the "test" button to run your JUnit tests. In BlueJ, you can create objects by right-clicking on the class and choosing "new ...", and you can invoke methods on them either by right-clicking on their red boxes at the bottom of the window or by typing expressions into the Expression Evaluator tool. In BlueJ, you can run an applet by right-clicking on the class, choosing "run applet", and clicking the OK button in the dialogue box. (You can also use this dialogue box to change the initial size and shape of the applet window.)

   However you run your tests, if any of them produce answers different from what you expected, log what happened for future reference, fix the error, and return to the "Proofread" step above, until everything works the way you expect.

Error logging

I want a log of everything that went wrong in the development of your programs. You may do this on paper or in a text file, as in homework 2, or using the on-line PSP forms.

Programming assignments

Modifying and extending a class

In DrJava, open the BuggleWorld.java program. For this problem, you may want to change the grid size to 25 or 30 so you have plenty of room to experiment.

Next, make a copy of your WritingBuggle class from homework 3, and modify it as follows:

1. Recall that in homework 3, each letter was drawn in whatever the current paint color was. Now the color will become a parameter to the method.

   For each of the methods drawS, drawC, etc, add another version of the method that takes in a Color parameter. For example,
   becky.drawS(java.awt.Color.orange);
   should draw an orange letter S, regardless of what color becky is before, while
   becky.drawS();
   will still draw an S in whatever the current paint color is, as before. Test the new versions of each method, as well as making sure that the old versions still work.

   Hint: You should be able to write each of the new versions of the methods in two or three lines, not counting javadoc comments. If it takes more than that, you're probably duplicating the work you already did to write the original versions of the methods.

2. Change the drawCourseName method to use the new versions of drawS, drawC, etc; drawCourseName should end up several lines shorter than it was before, but still producing exactly the same result.




3. Recall that in homework 3, each letter was 3 squares wide by 5 squares high, except the number 1 which was 1 square wide by 5 squares high.

   For each of the methods drawS, drawC, etc, add yet another version of the method that takes in two int parameters width and height specifying the size of the letters. (The draw1 method should take in only a height; it'll always be one square wide.) Thus
   becky.draw7(4,10);
   should draw a digit 7 in the current color, four squares wide by ten squares high.

   Note: if the height is an even number, the letter S can't have its horizontal part exactly halfway up; make it appear just below the halfway point. Be sure to test drawS with both even and odd heights!

4. By this time you probably have a lot of similar code between the two-parameter and no-parameter versions of the methods. Since the new two-parameter version is more general than the original version, change the no-parameter version of each method drawS, drawC, etc. so that it calls the two-parameter version that you just wrote, thus reducing each of the no-parameter methods to about two or three lines long. They should produce the exact same results they did before.




5. For each of the single-letter methods, add yet another version which takes in three parameters: a color, a width, and a height. You should be able to write each of these in about two or three lines.




6. Change the drawCourseName method to use the three-parameter versions; see the example at right.

Writing an applet

Choose one of the exercises P4.1 through P4.7, and write an applet to do it.
Then do exercise P4.8 (which requires writing both an Applet class and an ordinary class named House).
For extra credit, do one one of the exercises P4.9, P4.11, P4.12, P4.13, P4.15.

For each applet, follow these steps:

1. Open BlueJ
2. Create a "new project" and give it a name that indicates which problem you're doing, e.g. "HW4.6" for exercise P4.6
3. Click the "New Class" button, choose "Applet", and specify a suitable class name of your choice, e.g. "MyApplet".
4. Compile the program. There should be no compiler errors, because it's pre-written. (If there are, please let me know!)
5. Run it by right-clicking on the class and choosing "Run applet", then clicking the "OK" button in the dialogue that comes up. Make sure it works as it is.
6. Plan out a sequence of small steps that will get you from what the pre-written applet draws to what the problem in the book asks you to draw.
7. For each of these steps in turn, modify the pre-written paint() method (and any other parts of the class you need to modify) to do what you want it to.

What to turn in

• You've written a new-and-improved version of "WritingBuggle.java", perhaps with an associated JUnit TestCase class, and you've written two Applets, each of which may involve writing one or more other classes. Turn in each of the ".java" files (not the ".class" files or the ".java~" files!).

• I also want to see your development logs. If you prefer, the names and types and the test cases may now be in the program file itself, in comments, and the errors may be in PSP, in which case there's no separate log file to turn in.

Grading standards