Prototyping permits developers to elicit, model and then capture user requirements for a system. Like the buildings on a movie set, a prototype must look real even though it is only a facade. On a movie set, certain buildings have rooms, some of which are furnished. Similarly some features in a prototype are fully implemented, while others remain as images only. There are four levels of functionality used when describing a prototype:

Level  Functionality

one    Screens only
two    Screens with field entry and
       edit, some controllable flow.
three  Level two plus Create, Retrieve,
       Update and Delete of data
       and Menu linking screens
       together.
four   Level three plus Integrity
       checking, a correctly
       structured database and some
       application specific algorithms
       working.

The prototype developer must be able to respecify the data model and quickly regenerate the database structure because a prototype is not a static model; it goes through a number of iterations.

A typical prototype development iteration consists of analyzing the requirements (read documentation, conduct interviews); specifying (data model, functional specifications); designing (display layout, reports); developing (program, fill in tables of data); demonstrating and using; and finally, reviewing the design with users using Joint Application Design (JAD) techniques.

The JAD is a meeting in which a consensus can be reached amongst the user population as to the system requirements. The results of the JAD provide the requirements for the start of the next iteration.

Theoretically, this cycle should be repeated three times during a prototyping project. Ideally, each iteration of the prototype progresses closer to the specification for the final system. A rule of thumb is that sixty percent of the remaining requirements are captured in each cycle. After the second cycle, the system should be 84 percent correct and after the third cycle, 93+ percent correct (rather like golf where each shot gets you closer to the hole). At some point, however, diminishing returns make further iterations pointless.

ZIM is a natural choice for prototyping projects. It directly implements an Entity-Relationship data model which it keeps in an Active and Integrated Data Dictionary. An entity-relationship database structure allows transferring the conceptual data model produced in the specification stage directly into the database data dictionary. An Active data dictionary is important because the programs can access all the metadata. An Integrated data dictionary stores display specification information as well as the database structure. An advantage of choosing E-R Designer is that the data model can be exported and used to create the ZIM database description without rekeyboarding.

ZIM also runs code either in interpreted or compiled mode. Since prototype performance is not a consideration, the interpreted mode is used. This mode has a macro substitution capability which allows names of entities, relationships, displays, and ZIM routines to be substituted in the programs and resolved at run time. The data dictionary stores all these names, as well as segments of ZIM code for macro substitution. Thus, the data dictionary becomes the repository of the prototype specifications, data, displays and programs.

Other tools such as WordPerfect and internally developed ZIM utilities increased productivity further. We used WordPerfect's line draw facility to draw boxes and rapidly design the displays. Then below each display, the position of all the fields and their prompts were specified. A short ZIM program analyzed this information and created the display form specifications in the ZIM data dictionary.

One of ZIM's most useful prototyping features is the way in which display forms relate to entities in the database. If a field on a display form is given the same name as a field in an entity, then the ZIM command CHANGE Form FROM EntitySet fills in the fields of the current form from the fields of the same name in the current record of the entity set. Similarly, ADD EntitySet FROM Form creates a new record in the entity set from the data entered on the form.

This functional relationship between display form fields and entity set fields is re-inforced by maintaining the metadata in the data dictionary for each entity set field. (See Table 1.)

The other ZIM database information normally needed — length, decimals, indexed and required — are also stored in the data dictionary. Other useful attributes, such as default value, data mask and validation rules, exist for the fields in the display form.

We developed a number of generic, table-driven modules for the prototype's functional side. The concept of table-driven software is extremely powerful: by simply modifying the data in the tables, the developer can rapidly change the way in which a module functions, what it operates on and how it appears to the user. For example, we developed a menu program which was totally table driven. By changing the tables, the routines executed when the menu items were chosen, the menu structure and menu functions were modifiable.

With the table-driven approach, code can be reused. For example, only one modify routine can be applied to any entity set, and an enhancement made to a routine is universally available in the prototype system. Thus, the only nonreusable code is the application-specific algorithms, which are all linked in via the program name attribute attached to each field.

For the Canada Post Corporation prototype, generic table-driven routines were developed for

Menu
Level 1 and 2 screens (slide show)
Entityset Lister, which provided
access to the functions of:
    Sort list
    Pick record
    Print list
    Find record
    Add record
    Modify record
    Delete record
Help

There exist both a spreadsheet and business graphics package which take data from a ZIM database and allow for its manipulation, analysis and presentation. Given that the Canada Post Corporation application involved large quantities of statistical information, both these packages were linked into the prototype to assist the user in performing ad hoc inquiries and analysis of the data. These two packages were especially useful for the design and creation of new and existing reports to elicit user feedback. They added substantial functionality to the prototype with very little effort.