A Personal Database

In this project, you are to design and implement a book database. Your database will store book records, and each book records has, at least, these fields:

  • Title
  • Author
  • Date of publication
  • Book type: hardcover, softcover, or digital
  • ISBN # (yes, there is more than one kind of ISBN — it’s your decision about how to handle this)
  • number of pages

When your program runs, it should display a nicely formatted menu that lets the user choose from the following options:

  • Add a new book record.
  • Delete an existing record.
  • Update any field of a book record, e.g. the user might want to change the date of publication of a book.
  • Search for book records by any field; the resulting books should be sorted in whatever order the user wants.
    • Allow for both simple searches, e.g. all books with date=2005. Your program should let the user search for any book record whose field is equal to a value given by the user.
    • Some searches can be more complex, e.g. all books from the 1990s with at least 200 pages not written by JK Rowling. Include as many complex searches as possible.
    • Allow the user to sort the results by name, or by date, or by number of pages, etc.
    • Searching and sorting features of this program could be quite sophisticated, and you should make them as useful an efficient as possible.
  • Save the database to a text file, and load a database from a text file.
    • You must design the format of this text file! You could, for instance, store every book record on one line of the file as a string of fields.

This is an individual project: we expect everyone to create their own original program.

Constraints

Only code you write yourself, or that comes from the C++ standard library. Don’t use any other libraries.

Marking

When marking your project, markers will look for the following.

Correctness

  • Your program compiles without error. If your program does not compile, you will get 0 for the entire project.
  • You use separate compilation. A good idea is to split all classes into their own .h and .cpp files, compile those on their own, and then link them together.
  • Valgrind reports no errors when run with your program.
  • Your program has no run-time errors.
  • Your program correctly implements all requested features (listed above), and has no noticeable bugs or problems. Projects that implement more and better features will get higher marks.
  • Your program’s output is neatly formatted and user-friendly. All menus should be printed on cout, and they let the user choose what to do. No spelling or formatting errors please! Your program should not crash if the user enters invalid input.

Program Design

  • You have a class (or struct) called, say, Book that represents a book record.
  • You have a class called, say, Database that stores all the book records (e.g. in a vector<Book>), and provides methods for processing them
  • A class called, say, Menu that handles printing the menu of options on the screen, and getting the users input. One way to design this Menu class is to have it store a vector<string> of menu choices, and give it a method that prints the menu on the screen and gets the user input.
  • Use of STL functions, like sort and reverse. There are many more potentially useful functions in <algorithm>, and other standard C++ libraries may have functions and classes that are useful for this project. Do some research! We want to see that you know how to use these functions.
  • Your file format is sensible and works with both loading and saving.

Source Code Style and Readability

  • Good use of C++ features as discussed in the class, notes, and textbook. Don’t use features of C++ not discussed in 130/135.
  • Your source code is, overall, beautiful, understandable, and a pleasure to read. Really! Readable source code is an important part of a good program, so this will be checked carefully.
  • Indentation and spacing is sensible and consistent everywhere; whitespace is used to help group related pieces of code.
  • All names for variables, functions, classes, etc. are sensible and self-descriptive.
  • Appropriate C++ features are used in an appropriate way. We don’t want to see you use C code/libraries when better C++ alternatives exist.
  • No unnecessary code, e.g. no unneeded variables, no unused functions, etc.
  • No code that needlessly wastes time or memory.
  • No code that is overly complicated or long. For example, as a general rule of thumb, all functions and methods should fit on a single screen. If a function is longer than that, consider breaking it into smaller functions.
  • Comments are used to explain any part of the code that is not obvious.

Readme File

In addition to all the code need to compile and run your program, include a file named readme.txt formatted as follows (replace all the comments with your own text):

    Full name:
SFU student #:


Compilation Instructions
------------------------

// A precise, step-by-step, description of how to compile your program
// that the marker can cut-and-paste from to compile your program.


Running Instructions
--------------------

// Precisely how to run your program. Explain anything else about running
// your program that a user needs to know.


Key Features
------------

// List the best features of your program.


Bugs and Limitations
--------------------

// List all known bugs and limitations of your program.


All People, Websites, and Sources of Help
-----------------------------------------

// List all people, websites, books, chats, apps, etc. that you used for
// help.

What to Submit

Put all code needed to compile and run your program (and also readme.txt) into a folder called bookDatabase, and zip it into an archive named bookDatabase.zip. Submit bookDatabase.zip on Canvas when it’s ready.

Note

You can submit bookDatabase.zip more than once. Canvas will automatically rename the file — that’s normal and to be expected. The markers will only mark your most recently submitted file.

Hints

  • Start early! This is a relatively big and open-ended project, and may be more involved than you might guess. Since it replaces the final exam, markers will mark it more carefully than previous assignments.

  • Do a little planning at the start. It doesn’t have to be much. Just writing down the major classes you think you will use, and a couple of important methods you think they will have, is better than not doing any planning.

    You may want to sketch a class diagram, especially if you think you are using inheritance.

  • Use a field separator for the file. One way to format the database file is to but all the fields on one line separated by some special symbol, e.g. “:::” or “—”, or whatever you think is good. Be careful: don’t choose a symbol that might appear in one of the fields (e.g. a comma would be a separator because some titles will likely contain a comma).

  • Make your source code readable as go. Don’t wait until “later” to fix up what you know is unreadable or bad source, since “later” might never come if you run it problems (or just forget to do it).

  • Multiple menus can work well. In addition to the main menu that is printed when the program starts, you may want to have sub-menus that are printed when the user selects an option. For instance, if the user chooses to search for a book record, then you could print a menu showing the various options for how to do that search.

  • Re-ask the user when they enter bad input. As it says in the description above, your program should not crash if the user enters unexpected. Instead, it should politely ask the user to re-enter the input. One nice way to do this is to write a special input functions called. For instance, if you need to read in integers in some places, write a function called get_integer that keeps asking the user for an integer until they enter a valid one.

    Some inputs the user might give, like type ctrl-D or ctrl-C or Ctrl-Alt-Del, are beyond what we can handle in this course, so don’t worry about them.

  • Here are some notes on how to use a makefile to simplify separate compilation.

  • Here is some code for creating random data: rand_book.cpp. A recording of the live session where it was created will appear on Canvas on the Bb Collaborate Ultra page … there I explain what everything does.