CPSC 241-002 Computer Science IV
(Data Structures and Algorithms)

Fall 1998
TTh 12:30--1:45 Daniel 408
Assignment 8
<http://andrewd.ces.clemson.edu/courses/cpsc241/fall98/hw/asg8.html>

Objectives:
To design and implement an electronic address book.

Due dates:
Project design and team organization: 11/12/98 (see below)

Project writeup: 11/24/98

Teams:
You may organize yourselves into small teams (of size no larger than 4) to complete this assignment.

If you form a team, you must specify the ``division of labor'' (e.g., who did what) in your assignment writeup (scores will be divided equally, however).

Teams organization deadline:
You must indicate your team/solo status on your project design write-up. If you have not formed a team, you can elect to remain solo, or request to be included in a team, and I will arbitrarily form teams from remaining (willing) solo students.

Description:
Write a program to implement an address book as follows:
  1. Each entry in the address book includes address and phone number records composed of fields in US format as follows:
    • A name, consisting of a last and first name, e.g., "Smith", "James".
    • A street address, e.g., "1234 Any Street".
    • A city, e.g., "Anytown".
    • A state, e.g., "ST".
    • A zip-code, e.g., "12345".
    • A phone number, including the area code, e.g., "(123) 456-7890".
    Carefully design appropriate data structures for these fields and records. Use classes to define objects where appropriate. You are free to choose any representation that you feel is suitable (e.g., each field can be a character string).

  2. At the beginning of the program, the address book is to be initialized from a file (possibly empty). You are free to choose an appropriate format for the file. In the design and final assignment write-up, specify the format you have settled on, indicating any special delimiters you use to signify separation between fields, records, etc.

  3. The address book program is to be driven by a user dialog that first asks for the name of the address book file. The address book is then initialized from this file and the address book interface dialog begins. The user is repeatedly asked to indicate an action by typing in a number 1-8. The corresponding actions are:
    1. Add a new entry to the address book.
      • The response to this action is to request (prompt for) each line needed for an address book entry in the same order as the record format in the address book file, after which the new entry is added to the address book.
    2. Update an existing entry in the address book.
    3. Remove an existing entry in the address book.
    4. Display (to screen, i.e., stdout) an address from the address book.
    5. Display (to screen, i.e., stdout) a phone number from the address book.
      • The response to actions 2-5 is to request (prompt for) the last name and the first name (each to be entered on one line) for the address book entry.
      • An error message is displayed if the name is not in the address book.
      • If the name is in the book, then the action is performed for actions 3-5.
      • For action 2, a further prompt for a sub-action is given:
        1. Change the name.
        2. Change the address.
        3. Change the city (includes city, state, and zip).
        4. Change the phone number (includes area code and number).
        After a change action is specified, a prompt is given for each line of the new data (just as was done for a new entry), and after the changed information is read, the address book is updated. Only one address entry item can be changed by a Change action.
    6. Print (to screen, i.e., stdout) the address book.
      • For printing the address book, the entries are to be separated by a blank line, and each entry is to be printed in the following format:
        <first_name> <last_name>
        <street_address>
        <city> <state> <zip>
        <(area_code)> <phone_number>
        
      • The entries should be printed in alphabetical order, alphabetized on <last_name> <first_name>
    7. Save the current address book into the file.
    8. Quit (without saving).

  4. In your design and assignment write-ups, specify your design choice for internal storage, providing reasons for your choice. For example, what will you use to store the address book in memory (a tree, a linked list, a hash table, etc.) and why.

Notes, suggestions, and additional requirements:

  1. Design specifications are due from each team (see due date above). Provide at least the following:
    • The file format you plan to use.
    • The data structure you plan to use to internally represent the address book.
    • The search algorithm you plan to implement to find an address book entry.
    • The sorting algorithm you plan to implement to sort the address book entries.
    • The incremental design steps you plan to take to complete the assignment and the anticipated time-line for completion of each step.
    • The responsibility of each team member relative to the implementation.
    • A significant portion of this assignment deals with good design of the object-oriented internal data structure to facilitate the operations on the address book. Think this through clearly first, as the assignment grade will reflect the overall efficiency of your algorithms.
      (I will review your design specs and return comments and suggestions.)

  2. Some considerations for incremental development:
    • The file initialization is not necessary initially.
    • The prompt for file initialization can be included but ignored, just as if the file were empty.
    • Update and Remove are not needed initially.
    • Either the Get Address/Get Phone actions or the Print Address Book action can be omitted initially.
    • Printing the entries in alphabetical order is not necessary initially.

What to hand in (for both the design and final documents):
``Professional-quality'' writeup (one writeup per team), including:
  1. Cover page containing names of all participants:
    Course Id--Section No.
    Name:
    SS No:
    Assignment No.
  2. Assignment description
  3. Solution description (e.g., program design, description of algorithm, etc., however appropriate).
  4. Lessons learned, identified interesting features of your program
  5. Appendix A: Source code listing
  6. Appendix B: Sample input (if any)
  7. Appendix C: Sample output
The entire document should be a clearly written account of what you were to accomplish, what you in fact did accomplish, and what you learned (how you accomplished it). The code and sample runs, listed in the appendices, should be clearly documented (e.g., document the source code, generate informative output).

The general presentation of your document counts! (This includes qualities such as neatness, formatting, and legibility.)