INFM 718B
Building the Human - Computer Interface
Fall 2006


Course Description
Syllabus
Reading List
Team Project

Exercise 3

Last updated: Sept 22, 2006 7:45 pm

For this exercise, I strongly encourage you to work in pairs or in a group, especially on the first 3 parts. Having 2 or 3 pairs of eyes can often help spot the little details (like syntax errors) that are so easy to get wrong.

If you get stuck on one part, try the next.

1. Analyzing the Book and Library classes

Start by downloading the java files containing the Book and Library classes. Examine these classes to understand what they do. For each class, identify:

  • The instance variables
  • The constructors
  • The other public methods

Answer the following questions about the Book class:

  • In the constructor method, what variables are set to a default, hardcoded value?
  • As we discussed in class, the equals() method compares each field of the object against each field of the book passed to it to determine. What does the && notation mean?
  • Why does the equals() method use the == notation to compare the copyright year?
  • Why does the equals() method use the notation "book.getTitle().equals(getTitle())" to compare the titles?

Notice that the Library class constructor creates a "library" of 3 books.

  • What does the search() method do?
  • What will the main() method output when you run it? Answer this before you run it and then see if you were right.

You should be able to answer these questions based on what we've covered in class.

2. Accomodating multiple copies of each book

As written, the Book class only accomodates a single copy of each book. You will now extend the Book class to accommodate multiple copies of each book. You will NOT modify the Library class! Your goal is to implement the new capability without making any changes at all to the Library class, thus demonstrating the value of encapsulation.

Start by changing the boolean variable called "available" to an int that represents the number of available copies. Next, modify the Book constructor to represent the presence of two copies of each book that is created. Next, modify the checkIn, heckOut, and getAvailable classes to check and/or update the available variable appropriately. Note that the getAvailable method must still return a boolean, since we want NO CHANGES AT ALL to the Library class. You may change the main method in the in the Book class to see if everything is working okay if you like.

Then run the main method in the Library class (NOT the Book Class). If it prints "Darn, it's still available!", then your program is operating correctly. If not, go back and look again at the Book class to figure out what you did wrong. If you find problems that you can't fix, ask a friend (better yet, work this out as a group), attend the lab session, or send me an email. If you send email, include enough details so that I can help.

3. Adding a size to the Book

In this part, you will extend the program to include a third object class, Size, that represents the size of a book. This will give you an opportunity to create a new class, its constructor methods, set and get methods, and one helper method (equals).

Because you probably treasure your creation in part 2, you'll want to make another copy of it to modify for this assignment. Create a new project, and copy the Library and the Book methods in there. That way you can modify those copies, and still look back to part 2.

Now create a new class called Size. This will represent the size of the book. We'll code the class first, and then modify the Book class to include a Size for every Book. To keep things simple, lets just represent the height and width of the book as instance variables, leaving out other thigs that you might also think of (e.g., the number of pages). Make both height and width "double" variables (i.e., long versions of floating point numbers, so that the either can hold a number like 8.5).

Remember: Each class goes in its own file. The file name must match the name of the class that is in that file. For example, Book.java contains the Book class -- nothing else. If you use the Eclipse class wizard, it will do this for you automatically.

Next we need at least one constructor. To try out the idea of overloaded method names, let's create two constructors for Size. The first should always set the size to 8.5 (width) by 11 (height), so it needs no parameters. The second should have two parameters (both of which are doubles), the width and the hight, and it should set the instance variables to those values.

Now for the get and set methods. You'll need one of each for height, and one of each for width. Don't forget defensive programming, both here and in the constructor methods!

Finally, we'll define a helper method to determine whether two different books have the same size. As usual, lets call it "equals". Look at how this was done for Book, and it should be pretty clear how to do it for size. Once you are done with this, create a main method in the Size class to try out both constructors and the equals method.

Okay, now we are ready to add a Size to each Book. We'll do this by first declaring a size instance variable in the Book class, and then modifying the Book class's constructor to create a Size for each book. There are several ways to do this, some of which would require modifying the Library class and others of which would not; which way you choose is up to you. Finally, in the Book class, you need to change the equals method to include a check to see if the Sizes of two books are the same before saying that they are equal. When you do this, you should rely on the equals method in the Size class; that's what the principle of encapsulation suggests is the best way to do it (i.e., better than actually checking the height and width yourself).

4. Modelling the program with UML class and object diagrams

Usually, you create the UML diagrams before you write the program. (If you don't know why this is the case, review the slides from session 1 and meditate on the rapid prototyping cycle.) For this part, though, I want you to do it backwards: You will reverse engineer the program to document it with these two diagrams.

Start by drawing boxes for each class. Remember that each box has 3 compartments: the name (top), attributes (middle), and operations (bottom). List the attributes and operations in the appropriate compartments. Don't forget to use the +/- signs to indicate public/private.

Next identify the associations between the classes. For each association, identify the multiplicity at each end of the connector line. Identify any aggregations. (We will discuss aggregation again in class, but you should read the UML book and try it now.)

Finally, create an object diagram that shows the state of the program just before the Library main() method exits (finishes). You will have one Library object, 3 Book objects, and 3 Size objects.

If you run into problems

There are two kinds of problems you might run into as you do this exercise. First, you might not know how to do something. Or second, you might actually be able to figure out how to do it, but you might not understand WHY doing it that way is a good idea. Both kinds of things would be good to ask about in lab, in class, or by email.


Bill Kules