CSE 143, Homework 3

Library Lists

• assigned, Friday, 7 July 2000
• Part I
  • web turn-in due, 10:00 pm, Wednesday, 12 July 2000
  • paper submission due in section, Thursday, 13 July 2000
• Part II
  • web turn-in due, 10:00 pm, Wednesday, 19 July 2000
  • paper submission due in section, Thursday 20 July 2000

In this homework, you will complete a partial implementation of an extended version of the program you wrote for Homework 2 using list ADTs. Even moreso than for past homeworks, a major part of this assignment is understanding provided code and specifications well, so take the time to read both closely and thoroughly. If you understand the provided code and instructions properly, you should find that the code you need to write is neither very long nor complicated.

The following concepts and technical knowledge are the focus of this homework:

• list* ADT (unsorted and sorted)
  • implementation
  • client code
• class implementation
• better software engineering: stubs and drivers for testing and debugging

*also known as "vector"

You will complete a partially implemented project which is a new, extended version of the library project you worked on in Homework 2. When complete, this new, extended version will use two list ADT implementations: one to store records of books, and another for records of library patrons.

There are three substantial pieces of code missing in the provided project:

• sorted list ADT implementation for storing patron records by patron name (class LibraryPatronList)
• main function
• top-level function (i.e. not a member function) to process records from a transaction log data file

You are provided with a full implementation of the book list class (LibraryBookList), which is an implementation of the (unsorted) list ADT. You should use this as a model for implementing the patron list, which will be similar but sorted by patron name, i.e. sorted order (by patron name) is maintained when items are inserted/deleted. You are also provided with the following complete classes: Date (same as in Homework 2), LibraryBook (not the same as in Homework 2, extended slightly), LibraryPatron.

As in the previous homework, understanding the provided code and what it implies about the sections of code you must fill in will be crucial to the correct, timely completion of the project. A week prior to the final due date for the programming part of this project, you will be asked to submit a static call graph of the whole program (see written work below). Completing the call graph should help you to gain a precise, comprehensive understanding of the code and to plan the missing code you will write.

Under files below, you are given all of the files needed to build a program that works just like the sample executable, but some of them are incomplete, e.g. function definitions, a class missing. Start by spending some time familiarizing yourself with the sample executable, then make sure to study all of the provided code, because knowing what classes and methods are available to you will be crucial. The provided versions of files you will complete contain comments marked with *** (three asterisks), placed where you are expected to add code. These are intended to guide your programming, often very precisely, and should be taken seriously as supplements to these specifications.

class LibraryPatronList (in lpatrlst.h, lpatrlst.cpp)

Implement this class in the provided files lpatrlst.h and lpatrlst.cpp. The class declaration provided in lpatrlst.h only declares the constructors and a private file I/O method (readFile) for you. The rest of the declaration mainly consists of comments describing each of the methods you should implement. Source file lpatrlst.cpp defines method readFile but is otherwise basically empty.

This homework is larger than past homeworks and provides a good opportunity to learn about software engineering---in this case, how to develop a complex program composed of many pieces of code (e.g. classes, functions, files) in a timely, correct fashion. More specifically, you will complete the homework in two stages. In Part I, you will be focusing on class LibraryPatronList in taking these main steps:

• begin implementing the class LibraryPatronList by completing the class declaration in lpatrlst.h (mostly entails declaring methods and member variables)
• write stub implementations of LibraryPatronList's methods in lpatrlst.cpp
• demonstrate that this stub implementation builds and can be tested using a small driver program (a main function defined in a source file you create called driver.cpp)

For the Part I due date, you will submit your LibraryPatronList stub implementation (header and source file pair) and a driver program. (In this case, by "driver program", we simply mean a source file which defines a main function whose purpose is to comprehensively test the class. See under resources and hints and tips for more review on stubs and drivers.) Your driver should instantiate LibraryPatronList instances using each constructor at least once and call each public method at least once for testing coverage.

Your stub implementation of LibraryPatronList must build successfully, but the methods do not have to work the way they are supposed to. (The whole point of a stub implementation is to enable you to build a project with an incomplete part, writing code and testing gradually, progressing in small, controlled steps.) This means that your test driver might not do anything very interesting at this stage, perhaps just produce some output signalling that certain methods have been called. However, as you replace your stubs with complete implementations, the hope is that this driver will be useful for testing and debugging.

For the Part II due date, you will complete the LibraryPatronList implementation, as well as the processTransaction and main functions, as described next. The result should be a multi-file project that builds into an executable that works just like the sample program. Part II requires that you submit lpatrlst.h, lpatrlst.cpp, library.cpp, and main.cpp.

function processTransaction (in library.cpp)

Study library.cpp and its corresponding header, and make sure you understand the purposes of the functions defined and declared in these files. The only part of library.cpp you should need to modify is the definition of function processTransaction. A detailed outline of the definition is provided in the comments. From this outline and the other provided code, you should be able to deduce how you should be using the various Library classes in this function.

function main (in main.cpp)

As with processTransaction, you are provided with an empty definition for main. Define main using the comments as a guideline, calling functions declared in library.h and using the list classes appropriately. The resulting function should not be very long---the whole file, main.cpp, should end up being a page and a half long or less.

additional requirements

• The guideline comments (those marked with ***) should be replaced by your code, i.e. they should not appear in your final submission. Make sure to comment the code that you write, however, particularly in the definitions of the LibraryPatronList class' methods.
• By this point, we expect you to always be considering invariants, and you should use assertions throughout your code.

Finally, make sure you do not modify the following files:

• library.h
• lbook.h
• lbook.cpp
• lpatron.h
• lpatron.cpp
• lbooklst.h
• lbooklst.cpp
• date.h
• date.cpp

static call graph (for Part I)

For Part I's paper submission, in addition to a project report and your web turn-in receipt print-out, you should submit a static call graph that includes all of the functions and member functions that can be called, starting from main (not your driver.cpp's main definition, but main.cpp's main definition). (Do not include implicit constructor invocations---your graph will be cluttered enough without them.)

At the time you submit Part I, you might not have completed main.cpp yet, but you should be able to deduce (from the commments and provided code) what functions and methods will be called.

Your call graph will end up being rather large and complicated, so we strongly suggest you write on a large sheet of paper and start with main in the middle. To save space, remember to write only function/method names on the graph, omitting parameter lists. For a method name, remember to include the class name using :: notation. For example, if main happened to call LibraryBookList's isEmpty method, you'd write "LibraryBookList::isEmpty" on your call graph and draw an arrow from "main" pointing at it.

Please write small but neatly, fold your call graph into a reasonable size (e.g. 8.5 x 11 inches) for submission, and make sure your name, student number, and section are written in a visible location.

project report (for both Part I and Part II)

In addition to your turn-in receipt print-out, you are required to submit the following on paper with each of the two parts' submissions. This may be handwritten if it is 100% legible. If your TA can't read it easily, he may require you to resubmit it word-processed. It must be on a separate sheet of paper, and not embedded in comments in the program. Please write your name and section on the sheet.

1. It may be that your project does not meet the specifications given above. Write a short statement that either says you are in full compliance with the requirements, or lists the ways in which you are not (things that don't work, etc.).

2. You may decide that the program you turn in is not ideal in some respects. If your boss or fellow programmers were looking at it, what do you think they would find to like or dislike? Write a short paragraph evaluating the project. You could focus on the way it's designed and programmed, or focus on what usefulness the program has.

3. Write a statement of acknowledgements. If you took code from anywhere (except what the assignment gives you directly), say where you got it from and who the original author is. You must do this even if you modified the code considerably. If you received help on the assignment from anyone other than course staff (TA, instructors, consultants), please list the name of the person and the extent of their help.

• testing and debugging using stubs and drivers
  • CSE 143 lecture slides, "Principles of Software Engineering" - includes an overview of stubs and drivers
  • Carrano et al. (your textbook), around p. 12 - brief discussion of stubs
  • definition of "stub" - a dummy function with a very simple body, often just an output statement that this function was reached, and a return value (if any is required) of the correct type. Its name and parameter list is the same as a function that will actually be called by the program being tested. (from lecture notes for a class at Towson University [Zimand, 2000])
• Carrano et al., Chapter 3 - covers ADTs, including the list ADT
• CSE 142 lecture slides, "Arrays of Structures" - includes a discussion of insertion sort, which you might find relevant when implementing insertion into a sorted list
• CSE 143 lecture slides, "Recursion" - includes a review of binary search, a strategy you might consider employing to implement insertion into a sorted list

• Read these instructions and the comments in the skeleton code very carefully.
• Start early, study provided code, and don't wait to ask questions.
• When writing the declaration for class LibraryPatronClass, whenever possible, use method and member variable names used in the similar class LibraryBookList. This kind of consistency will make your job easier and your code more readable.
• Not sure how to compare items in LibraryPatronList? You probably didn't study class LibraryPatron enough.
• Stumped on how to write a stub? A stub is a small, temporary piece of code that takes the place of a real implementation for the sake of allowing a multi-part project to build. More specifically, in the case of methods, a stub definition for a method is a short definition that doesn't really accomplish what the method is supposed to but facilitates testing and debugging by satisfying the most basic requirements of the method. For instance, a stub for a method which is declared to return an int must, at the very least, return some int value, even if the value is arbitrarily chosen rather than properly computed. You should also consider making each stub produce some minimal output (using cout) to signal when the method has been called.
• In addition to the driver that you are required to write, consider writing separate, smaller drivers (main functions) to test other parts of your code (e.g. function processTransaction) or experiment with provided code (e.g. classes LibraryPatron and LibraryBookList) to gain a better understanding of the whole assignment. (Note that this might require making separate projects in MSVC, since you cannot have more than one main function definition per project.)
• Part II will probably require more work to complete that Part I, so try to finish Part I as early as possible. We recommend against waiting until the Part I deadline to begin work on Part II.
• Remember, always make sure your code compiles, and when it doessn't, don't attempt too much progress (write too much code) until it does.

As always, be sure to read the official homework submission policy, linked on the course web on the Homework page. For each of the two parts, you will have to submit your work (1) via the web using the page linked below and (2) on paper.

• web turn-in page for Part I (closed)
• web turn-in page for Part II

Your web turn-in for Part I should consist of the files listed below. The form will not accept any other files.

• lpatrlst.h - should contain a complete declaration of class LibraryPatronList
• lpatrlst.cpp - should contain a stub implementation of class LibraryPatronList
• driver.cpp - should contain a main function that tests class LibraryPatronList

Your web turn-in for Part II should consist of the files listed below. The form will not accept any other files.

• main.cpp
• library.cpp
• lpatrlst.h
• lpatrlst.cpp

Your paper submission for each part should consist of the following:

• printed receipt from the web turn-in for Part I/II - No other form of submission will be graded. No other kinds of printout, disks, etc. are acceptable, so make sure to print out the receipt page as soon as you do your web turn-in.
• project report for Part I/II (as specified above)

As stated on the official homework submission policy page, all parts and pages of your paper submission must be stapled together and sealed in a large envelope. (Don't expect the TA to have a stapler in section, either!) You can lose points for not following these instructions (crazy, but true!) For this homework, you will submit your paper submission in quiz section on the due date at the top of this page.

• code
  • main.cpp (incomplete)
  • library.h
  • library.cpp (incomplete)
  • lbook.h
  • lbook.cpp
  • lpatron.h
  • lpatron.cpp
  • lbooklst.h
  • lbooklst.cpp
  • lpatrlst.h
  • lpatrlst.cpp (incomplete)
  • date.h
  • date.cpp
• sample test data - We might release more test data later, but you should also create your own for testing purposes.
  • books.txt - book catalogue data file
  • patrons.txt - patron data file
  • trans.txt - transaction log data file
• sample executable

  • hw3.exe (PC, Windows)

• sample solution
  • Part I
    • lpatrlst.h - stub implementation
    • lpatrlst.cpp - stub implementation
    • driver.cpp - tests class LibraryPatronList
  • Part II
    • main.cpp
    • library.cpp
    • lpatrlst.h
    • lpatrlst.cpp

If any clarifications or changes need to be made for this homework, they will be posted to the cse143-announce e-mail list and linked here.

• Date class files linked; typo in LibraryPatronList::readFile
  Ken Yasuhara (Sun Jul 09 2000 - 20:09:09 PDT)
• #include in library.cpp; Debug vs. Release
  Ken Yasuhara (Mon Jul 10 2000 - 10:03:43 PDT)
• HW 3; replace method for sorted list ADT
  Ken Yasuhara (Mon Jul 10 2000 - 11:47:24 PDT)
• HW 3 questions: stub, driver, related files
  Ken Yasuhara (Tue Jul 11 2000 - 12:27:09 PDT)
• HW 3; call graph
  Ken Yasuhara (Tue Jul 11 2000 - 15:10:25 PDT)
• HW 3; call all methods directly in driver
  Ken Yasuhara (Tue Jul 11 2000 - 19:41:29 PDT)
• HW 3; LibraryPatronList tips
  Ken Yasuhara (Wed Jul 12 2000 - 11:25:49 PDT)
• no direct update of itemCount in readFile
  Ken Yasuhara (Sun Jul 16 2000 - 12:58:16 PDT)
• HW 3; findPositionByID's success flag and return value
  Ken Yasuhara (Sun Jul 16 2000 - 22:32:23 PDT)

Save paper. Read documents on the web and, if you must print, print two-sided. Recycle this when you're done.