The purpose of this project and Project 4 is to give you some practice in dealing with generic packages, and illustrate the advantages of a clearly-specified generic interface in supporting multiple implementations and multiple clients. This project uses material from Chaps. 2, 3, 4, and 5.

In Project 2 you completed a simple package to handle a table of student records. This package is limited in a number of important ways.

• There is no way for the client to query the number of records in the table
• There is no way to load the table from a disk file, or write it back out to a disk file
• A Replace operation is very indirect: the client must do a Retrieve, change the values in the record, Delete the old record, and Insert the new one
• The table is implemented as an unordered array
• The package provides no exception to report a full-table condition

Program 5.19 presents a generic version of a table package, Tables_Generic; Program 5.21 presents a child package containing backup and restore operations. The body of Tables_Generic uses an ordered array implementation of the table objects, and so instantiates Binary_Search_Generic (Programs 5.12 and 5.14) to provide a table-searching operation. The package operations are "stubbed out", containing only some calls to Debugging_Support to display an "under construction" message. Your tasks in this project are:

• If you have not already done so, add file-oriented operations to your Student IO, also, implement robust input in the interactive Get procedure.
• Complete and the operations in the body of Tables_Generic.
• Integrate the new table handler into your user interface program:
• Instantiate the table handler for the employee type
• Instantiate the backup/restore package for the appropriate Student IO operations.
• Add menu selections for backing up and restoring the database, and implement all operations fully.

Regarding test plans and user guides: write test plans for everything you change; write user guides for any package(s) that don't have them yet.