I.   Class diagram

     The design requires, at least, the following classes:  Author, Book,
     ScriptInput, Manager, Database, ArrayT<Author> and ArrayT<Book> 
     (template instantiations).  These are all listed in the project spec, 
     so there's no excuse for leaving any out.  It's OK to have additional 
     classes as long as they make sense.  The class diagram should NOT show
     the array template (since that's not a class).

     The following relationships, with the indicated cardinalities, should 
     be represented in the class diagram:

       Manager O-------- ScriptInput              "O"  indicates association
               1       1                          "<>" indicates aggregation
                                                  "[]" indicates either association
                                                         or aggregation is OK
       Manager O-------- Database
               1       1

       Database []------- ArrayT<Author>
                1       1

       Database []------- ArrayT<Book>
                1       1

       ArrayT<Author> <>------- Author            "n" instead of "*" is OK
                      1       *

       ArrayT<Book> <>------- Book                "n" instead of "*" is OK
                    1       *

     It's also OK if they show an association between Database and Author/Book as
     long as they do show the correct relationships between the two arrays and
     Author/Book.  They shouldn't show any relationship between either the Manager
     or the input class and either Book or Author.

     They should use proper class diagram notation for association and aggregation,
     including cardinality indicators.


II.  Book and Author interfaces:

     Book data members:
        ISBN, category, title, author id, units sold, year

     Author data members:
        name, author id

     There should be:  
        + overloads for at least two relational operators, 
          say operator< and operator==
        + no direct mutators for any Author data members
        + no direct mutators for any Book data members except UnitsSold


III. Database interface:

     Data members:
        Two array objects (template instantiations) -- these can be data
            members themselves, or Database can store pointers to them.
        It's OK to have other data members as well.

     There should be:  
        + member functions to handle each of the relevant script commands
          (addBook, addAuthor, delBook, listBooks, listAuthors, updateSales,
           findAuthor, saveBooks, and saveAuthors)



IV.  Array template interface:

     Data members:
        Pointer for dynamic array, dimension, and usage.

     There should be:  
        + only generic operations such as Insert(), Remove(), etc.; any mention of 
          an attribute or function from the Author or Book class (except the 
          relational operators) is incorrect.
        + deep copy support (copy constructor, assignment operator)
        + memory management support (constructor taking array dimension, destructor)


Only check the class forms for the types detailed above.


V.   Proper respresentation of design.

     The class forms should look like class forms.  Each should include:
 
        + the class name, 
        + a brief description of purpose that makes sense, 
        + a listing of all the member functions, 
        + an indication of private for any private functions 
             (data members are assumed private unless indicated otherwise, and
              function members are assumed public)
        + a listing of the data members.