Informatics 42 • Winter 2008 • David G. Kay • UC Irvine

Lab Assignment A

This assignment is due at the end of lab on Friday, January 18. This is enough time for a novice Java programmer to complete the task, bearing in mind that Informatics 42 is a six-unit course that typically will require work outside of the normally scheduled lab hours.

You will also notice that the specifications for most assignments in this course are longer than we've seen before. This is a good thing: the more explanation we give, the more guidance you have. But technical specifications are not like novels. You cannot speed-read through them just one time and expect to gain the information you need. Plan to read the specifications carefully, and plan to go back and read them again to pick up additional details.

We expect you to complete this assignment in pairs, following the usual pair programming guidelines. You may not choose this project as your one "pair programming holiday" this quarter. There are lots of little details to get through, and it's really hard to do it alone. We suggest that you try to pick a partner whose experience level is relatively close to your own; that seems to optimize both the effectiveness and the efficiency of both partners' learning (i.e., you'll learn more with less effort).

The problem: Complete Alex Thornton's ICS 22 lab assignment, "Perfect Candidate," available at http://www.ics.uci.edu/~thornton/ics22/LabManual/PerfectCandidate/.

How to get started: Read the assignment specification. Reading it through twice wouldn't hurt. Then download the code and scan through the files to get an idea of what's where. Note that some of the files, you aren't allowed to change at all; you just need to know what "services" they provide for you.

The code supplied to you (the "starting point") compiles correctly. That is, when you run javac on those files or import them into an Eclipse workspace, you get no error messages. (Of course, it doesn't execute correctly; it hardly does anything, because it's your job to add the necessary code to make it satisfy the specifications in the problem.) As your first step, pick one small part of the task that you think you know how to do. Add the code to do that part (writing examples and tests in advance and including those tests in your code—you can take them out at the very end). Your code should still compile correctly, and your tests should produce the results you expect.

It is absolutely essential that you work in very small increments. After each tiny change, compile and run your code, and make sure it is correct. Novice programmers (and even some experienced ones) sometimes fall into this terrible trap: They add a whole lot of code to their program all at once, then they try to run it, and their code doesn't even compile correctly. The debugging job is enormous at that point, because there's no easy way to tell which part of the code has the error in it. When you add one tiny portion of code at a time, recompiling and running after each addition and not adding more until what you have is correct, your overall development time is shorter because you can locate any error in the small part of code you most recently added. (For a non-computing-related illustration of how it's better to take small, easy steps rather than trying to bite off a lot at once, everyone should read Atul Gawande's article about ICU checklists.)

In assignments for this class, code that doesn't compile correctly will receive very little credit, no matter how long or how hard you worked on it. If it doesn't compile, there's no real way to tell what it does or doesn't do. Your starting point compiles; each change you make must also compile. You'll receive much more credit for a running solution that doesn't implement some of the features than you will for a solution that has bugs (or worse yet, that doesn't even compile).

Keep adding new functionality, small piece by small piece, running and testing as you go, until you've satisfied all the requirements in the assignment specification. When you have a way to approach a task, it's less daunting.

Opening files for reading and writing in Java: This lab asks you to write Java code that reads its input from a file and writes its output to a (different) file. Here's a quick primer on files in Java:

• There are two kinds of objects in the Java library that know how to read and write using files, respectively: FileReader and FileWriter. As their names suggest, FileReaders know how to read information from files, and FileWriters know how to write information into files. Unfortunately, they do not provide a clean interface for doing common tasks like writing output the same way you write to System.out, or for reading one line, one word, one number, etc., at a time.



• There is a helpful class in the Java library that knows how to read input one line, one word, one number, one character, etc., at a time; it's called Scanner. Scanners know how to read input from a variety of input sources, not just files. When you create a Scanner, you tell it what input source you'd like to read from. To create a Scanner that reads its input from a file, you'd write:
  Scanner s = new Scanner(new FileReader(filename));
  with filename being replaced by the name of the file (or the variable containing the name of the file) that you want to read from. From here, reading from the Scanner you just created works just as it would if you were reading from the console (System.in). One important wrinkle is that it's important to "close" files when you're done with them; this is a way of telling your operating system not to maintain resources associated with the open file, not to lock it so that other programs can't use it, and so on. To close the file, simply call the close( ) method on the Scanner.



• The best class for you to use to write your output file is called PrintWriter. PrintWriter objects behave just like System.out — including methods like print( ), println( ), and format( ) that are analogous to the ones supported by System.out — but are able to send their output to a variety of sources. When you create a PrintWriter, just like when you create a Scanner, you "wrap" it around another object which will handle writing the output somewhere (a file, a network, etc.). To create a PrintWriter for writing output to a file, you'd write:
  PrintWriter pw = new PrintWriter(new FileWriter(filename));
  with filename being replaced by the name of the file (or the variable containing the name of the file) that you want to read from. At this point, you can call methods like print( ) and println( ) on the PrintWriter to write output into the file. You'll also need to remember to close the file when you're done, by calling the close( ) method on the PrintWriter. (This turns out to be very important when writing output to a file, since the output may not end up in the file until after it is closed!)

What to turn in: Turn in via Checkmate all of the Java source (.java) files for this project, including the ones you didn't have to modify. Also submit your test plan, as described in Alex's project write-up. If you haven't registered yourself for Checkmate this quarter, do it now; instructions are on the syllabus. (Checkmate may seem to limit the number of files you can submit, but really it only limits how many you can submit at one time. Submit the maximum, and if you still have more, just go back and submit the rest.)

As usual, each pair should submit just one solution, with both partners' names clearly listed at the top of each file.

Also as usual, every student must fill out a partner evaluation form at eee.uci.edu. You can get to the partner evaluation for this lab by logging in at eee.uci.edu, choosing MyEEE, and selecting Survey. Your class participation score will suffer if you neglect to do this. We have not turned on the Email nagging option for this evaluation; it's up to you to remember to do it within a day or so of the due date.

Grading criteria: The usual grading criteria for lab assignments will apply to this one.

Written by David G. Kay, Winter 2005; methodological expanation enhanced, Winter 2006. Modified by Alex Thornton, Winter 2007, and by David G. Kay, Winter 2008.