Group Project Assignment

Outline of requirements

For our group project you will be writing a software system to manage a small lending library. This library lends a variety of materials, such as books, periodicals, and DVDs. Each item in the library has a unique identifying number. Each person using the library has a library card with a unique identifying number. Library patrons can check out materials within certain limits: any patron can check out up to a total of 10 items at any time. Items have to be returned within a certain time frame (two weeks for books, one week for periodicals and DVDs). When items are returned late, fines are assessed ($0.50 per day for books and periodicals, $1.00 per day for DVDs). As soon as fines on an account reach $10.00 or more, that account is frozen and no new items may be checked out until the fine is paid. Items can be lost - if a patron reports that an item is lost, they are assessed a fine equal to the original purchase price of the item. Also, if fines on any item checked out reach the purchase price, the item is considered lost, and no further fines are assessed.

To keep things simple, we will assume that the library is run by a single librarian who uses a single computer application to manage all aspects of the library.

The software that we will write to manage this system will have three major categories of functionality: administrative functionality, checking out materials, and returning materials.

Administrative functions

The application's user interface will need to support the following activities.

  1. Create a new library item. User enters code number, item type, title, and replacement cost.
  2. Create a new patron. Enter patron id number, name, and mailing address.
  3. Generate overdue notices. Produce a list of all items that have become overdue since the last report was run. Dump this report to a text file containing patron names and addresses followed by a list of those items that are newly overdue. The user can then print this text file and mail the overdue notices to patrons.
  4. Update status of all users - recompute fines as needed, check for items that should be marked as lost.
  5. Run start up and shut down tasks. When the application starts up, all the data it needs will need to be restored from one or more files. When the application exits, it should save all of its data to one or more files.

We will assume that the user runs items 3 and 4 daily.

Checking out items

Our user interface will need to support the iteractions that typically take place when a patron checks out an item. The check out session starts by entering the patron's code number. This should bring up a window in which the user can conduct the following activities.

  1. Display patron status, including list of all items already checked out, list of overdue items, total fines due, and whether or not the patron has lost check out priviledges.
  2. Check out an item. Given the code number for an item, mark that item as being checked out by that user. (If the user has already reached the limit of ten items checked out or owes too much in fines, the application should refuse to check the item out.)
  3. Change the status of a checked out item to lost. Update system records and patron fines accordingly.
  4. Pay fines. Allow the user to enter the amount the patron has paid, and deduct that from the amount due. If the payment brings the fines due to less than $10.00, unfreeze the account.

Checking in items

We also need to provide a simple interface for checking in items. Given the item number, mark the item as checked in. At the instant an item is checked in, assess any fines that have not already been assessed for this item being overdue.

Thinking about how to organize your data

Before you can start to design a software solution to meet a set of requirements, you should think about the best way to organize the application's data. You will need to think through the class design of the data classes first, because these will form the foundation for the application.

The two most obvious classes we will need to have are a patron class and an item class. Patrons will represent the library's patrons, and will contain basic information such as patron id number, address information, and how much the patron owes in fines. Items will represent the items available to check out. Each item object will have an item number, a title, a type, and a replacement cost. Also, we will want a class to hold information about the status of checked out items (the item number, patron number, and the date when the item was checked out.) We will create items of the third type the instant something gets checked out, and those objects will persist in the system until the item is turned in or declared lost.

How to proceed

Once you have decided on a preliminary structure for the data classes, you should go over all the requirements listed above and try to imagine how these data classes will help us to perform each of the required tasks. Going through that exercise will help you to discover necessary data attributes that we may have missed. Once you have made enough passes through the requirements to convince yourself that your data classes are capable of handing everything we want from them, you can start to map out the structure of the application's GUI.

Since this is a group project that you will be working on with a partner you should try to develop a strategy for splitting up the work. This can anything from a decision to split up the classes and have each person work on a separate group of classes to deciding to write everything together, with one person typing and the other observing and providing input to the code writing process.