Project 4 — Document Storage System

Assigned Thursday, November 13thth
Program Due Sunday, November 23st by 11:59pm
Weight 10%
Updates
  • The Requirements section has been augmented to list the exact types and order of the fields you should prompt for for each document type.
  • The due date has been extended by a day.
  • The bad link to DocumentStore.cpp has been fixed, and a couple of the files have had cosmetic changes (e.g., fixing the printed command menu), so you should download fresh copies. The files are also now available on a directory on the GL machines for copying using a simple "cp".
  • The very original posting referred to there being active and archived sets of documents. We have simplified the project by removing the archive features. The system now only maintains a single collection of documents (no archives).

Objectives

To gain experience:

  1. Designing a hierarchy of classes related classes
  2. Redefining methods in child classes
  3. Using pointers
  4. Using dynamic memory and pointers
  5. Writing constructors and destructors

Project Policy

This project is considered an CLOSED project. Please review the open vs. closed project policy before beginning your project.

Overview: The CMSC202 Document Storage System

In pursuit of the "paperless office" (hah), the online storage and retrieval of documents has become a fundamental requirement of any company. In this project, you will build a small document storage system (DSS) that contains documents of various types. You will design the system to take advantage of the reuse mechanisms that C++ inheritance provides. For this first of two final projects, you will only be using simple inheritance and overriding, and will not be allowed to use any form of polymorphism. So, no virtual functions are allowed! Any use of the keyword virtual in your classes will result in substantial deductions, possibly a 0 (zero). The goal of the project is to force you to use regular static binding to understand it's use and limitations.

Starting with our provided drivers and skeletal class definitions, you will build a system that allows users to create and store documents, retrieve documents, and make inquiries about the documents.

Description

In this project, you will design and implement a document storage system (DSS) that will be used by a software consulting firm. This system stores internal company reports and company correspondence, such as memos and emails. All relevant document information will be input by the user. Documents are stored by the DSS in an internal document list.

When a document is initially stored, a unique document identification number is assigned, and the ID and the author who created the document are recorded. The unique ID is assigned to the document starting with 10001. The document number (its ID) is incremented for each subsequent document stored. Your document storage system must be able to store an unlimited number of documents.

In addition to the document ID and author name, which are common to all documents, each individual document type has additional fields which are specific to that type. Your document storage system will initially support three different document types. Company reports include a title. Memos, which are a kind of correspondence, include the name of the person to whom the memo is being sent, a list of people who will receive a copy of the memo (the distribution list), and the subject of the memo. The third type of document, emails, are electronic correspondence that include the email's subject, the name of the person to whom it is being sent, along with his/her email address.

Your document system must provide the following services for the user. We are providing a driver program that lets a user access these services through a command line interface.

  1. Create and store an email message

    This service should accept all necessary email information followed by the contents of the email. This service will display the document ID assigned to the email.

  2. Create and store a memo

    This service should accept all necessary memo information followed by the body (contents) of the memo. Since there is no limit on the number of names on the distribution list, your program should continue to accept names (one per line) until the user types “END” (without the quotes, in upper-case) at the begining of a separate line. This service will display the document ID assigned to the memo.

  3. Create and store a report

    This service accepts all necessary report information followed by the contents of the report. This service will display the document ID assigned to the report.

  4. Display a single document

    The user inputs a document ID and all relevant document information is displayed followed by the document body.

  5. List all documents stored in the system

    For each document, this service displays the document's ID and author, and any other document-specific information. The body of the documents are NOT displayed. Print out "No documents found." if there are no documents.

  6. Search all documents for a specified word or phrase

    The user inputs a word or phrase on a single line. A listing of the IDs of the documents that contain the word/phrase in their text body is displayed. It is NOT necessary to find phrases that are split across lines. Print out "No documents found." if there are no documents.

  7. Empty the document collection

    All stored documents are permanently removed from the document system.

  8. Quit the program

    Your program exits gracefully.

The Components of your Document Class

There are three important components to your Document class hierarchy implementation:

1. The Base Class Representation:

You should have a base class for your hierarchy, named Document. Your Document class should contain all of the data members and functions that are used in common by the actual specific document type subclasses. Having duplicated members in child classes that could have been easily put into a common parent class will be considered poor design, and penalized.

2. More Classes

Each of your document types should be in it's own class. The skeletal DocumentStore class that we are providing requires you to have 3 classes named Email, Memo, and Report, which are all descendents of Document. However, this does not restrict you to making them all direct children-- you are encouraged to actually try out more interesting hierarchy structures.

3. Method Implementation

However you structure your classes, it must provide the methods expected by the calls already made from the DocumentStore methods, as well as any other calls you add there.

Project Requirements, Hints, and Tips

  1. (Reqirement) Your design should consist of four basic elements outlined here. Parts of it have been implemented in the code we provide. You are responsible for writing the rest.
    1. main() in Proj4.pp, which provides the main control loop.
    2. A single class called DocumentStore, instantiated by main(), that stores the documents, assigns ID's, and implements the other services requested by the user. It needs to maintain the collection of documents.
    3. A base document class, called Document which implements the base Document class that supports the storage, manipulation, and output of generic documents. This class will never actually be instantiated by our driver, but will still provide the implementations for all of the reusable data members and methods that are common across the various document subclasses you will be designing.
    4. A hierarchy of document classes derived from class Document, which implement the document type-specific functionality and define the type-specific additional document elements.
  2. (Reqirement) The collection of documents managed in the DocumentStore class should be implemented using the vector class, and should hold pointers to dynamically allocated document objects.
  3. (Reqirement) Since your collection of documents will be dynamically allocated, you should make sure you manage memory carefully, correctly using delete to dispose of objects that are no longer needed.
  4. (Reqirement) You should make good use of inherited methods, and method overriding, to show that you understand and can apply these techniques.
  5. (Reqirement) All static and non-static data members must be private. No protected variables are permitted.
  6. (Reqirement) Note that the body of text for any document may contain blank lines. These blank lines must be preserved, and present whenever the text body is displayed.
  7. (Reqirement) Because the text of a document is of indeterminant length, your program should continue to accept text for a document's content until the user types “END” (without the quotes and in upper-case) at the beginning of a separate line.
  8. (Requirement) For some menu items, the user is asked to input a document ID. If an invalid ID is entered, the system should respond by redisplaying the menu. DO NOT reprompt the user for a new document ID.
  9. (Requirement) Your menu MUST ask for the information for an email in the following order: author, subject, recipient's name, recipient's email address, text body
  10. (Requirement) Your menu MUST ask for the information for a memo in the following order: author, subject, recipient's name, distribution list, text body.
  11. (Requirement) Your menu MUST ask for the information for a report in the following order: author, title, text body.
  12. (Tip) When entering author's name, subject, etc., we promise that the user will not enter a blank line. Blank lines may (will) only occur within the document text.
  13. (Hint) Good OO design dictates that main( ) will rely on the DSS to perform the user's request. Other than constructors, the code in main( ) will not call any methods of any class other than the DSS.
  14. (Hint) Because we are using simple inheritance withoug polymorphism, and because the DSS must use a vector of pointers to generic Document objects, that means that the DSS cannot “know” the type of the Document it is handling, and so must infer it from some common data member that must be defined in the base Document class. We have already added the data member m_type and the accessor method Document::GetType() to the Document base class to do support this. Each of the actual document classes, Email, Memo, and Report, should define their respective constant DOC_TYPE_EMAIL, DOC_TYPE_MEMO, and DOC_TYPE_REPORT as unique integers to allow this to work. Even after a method figures out the type of the document being referenced, it must then do pointer casting to allow it to treat the object pointed to as the proper subclass type in order to work on it as that type. See the sample code in the implementation of ListActive() to see how this might be done.
  15. (Hint) Don't forget to use good top-down design when implementing your classes and your code.

Example Session

The program takes no command line arguments. It goes into a contiuous loop, prompting for a command, reading it, performing the required operations, then outputting the results. It exits when the user enters "99". The output from a sample run is provided HERE. NOTE: The order of the input prompts when a document is created must match the order found in the sample session so that the grading scripts will work properly.

Provided Code

We are providing several complete and incomplete source files for this project. They are: These files are also available for copying on the GL machines, using: 
cp /afs/umbc.edu/users/p/a/park/pub/cmsc202/fall14/proj4/* .

How to Test Your Project

You should create documents of each and every type supported be the system. You should also throughly test your program by trying out each and every command option to make sure all of your classes support all of the commands.

Additional Requirements

As always, you will have to create a Makefile.

Grading

See the course website for a description of how your project will be graded.

We will be automating much of the grading for this project. It is absolutely essential that you do not modify any of the files that we provided to you; You should not even submit these files. If you do inadvertantly submit your copies of these files, we will be replacing them with our own versions before trying to compile and run your program.

Another requirement is that your executable, as produced by your Makefile, is called Proj4.out; adjust your Makefile accordingly.

Project Submission

Before submitting your project, be sure to compile and test your code on the GL system. See the Project Compilation section of the course Projects page for details on how to compile and execute your project on GL.

Assuming you’ve used the specified file names, submit your project by typing the command 

submit cs202 proj4 [all of your various .h and .cpp files] Makefile

See the Project Submission page for detailed instructions. Note that we require you to submit the Makefile, also. We will in fact be using your own Makefile to build your program, so it must work properly.

You may resubmit your files as often as you like, but only the last submittal will be graded and will be used to determine if your project is late. Also note that if you rename or remove certain files, the old versions that you submitted earlier will stay in the submit directory unless you use "submitrm" to clean them out, which you should. At the end, a "submitls" should show exactly those files that are part of your project: no more, no less. For more information, see the Projects page on the course web site.

Remember — if you make any change to your program, no matter how insignificant it may seem, you should recompile and retest your program before submitting it. Even the smallest typo can cause errors and a reduction in your grade.