Upon successful completion of this project, the student will be able to:
A. Identify the components of a menu module,
B. Use a hierarchy chart to organize a programming system,
C. Design, create and access user defined functions,
D. Use comment sequences as prescribed in the Style Manual (Brunjes and Shultz, rev. 2010).
A. Basic decision and Looping Operations,
B. Arithmetic Operations,
C. Basic input/output operations cin, getline(),cin.get() and cout.
D. User-defined function creation.
In this project a "main menu" will be created to access various components of the program. Menu modules have four common characteristics: they display the user options, prompt the user for input and accept the user response, check the user response for reasonableness, and finally execute the requested program sequence.
To show relationships between various modules in a program often a "Hierarchy chart" is used. Each module is represented by a rectangle with connecting lines showing general sequence of operation. Typically execution trends are from top to bottom and from left to right. The figure below (Figure 4) presents a simplified hierarchy chart showing the relationship between a main menu and accessed routines (Data Input and Data Display).
Within the mdoule the operations can be represented by a structured outline of the sequence of events. This is termed "pseudo code" (false code). Following the hierarchy chart you will find a sample of pseudocode that generally describes the operations that occur in a two-option menu.
A "level 1" pseudocode sequence for a two-option menu is presented in Figure 5. Note that all menus should include a "Quit" option (not shown). This option may be worded somewhat differently, however once established the message should be consistent through out the program.
Display "Quit" option
Allow user input
Error check for appropriateness and Call requested
while the user input is not Quit
Pseudocode for a two-option menu.
Note the display lines may be as many as necessary to display the required options. This is the only significant change required for various menus, and will make the routine available for use as a template with a minimum of modifications. Calling the requested routine can be accomplished typically by using a switch() control structure which can make any number of comparisons. Error trapping is typically incorporated into the menu module by way of the default label within the switch() structure. The default option will be executed if there are no other matches made in the structure. The default option is typically used to display an error message and a prompt to continue the program. The menu continues to execute (loop) until the user enters the key for Quit, at which time the execution of the remainder of the program continues.
It is now necessary to consider the concept of a module. Modules are programming units which essentially have "one way in and one way out" in addition they typically have one or a very limited number objectives. In C++ the programming construct for a module is the function or as it is sometimes known as a "user-defined function". Referring back to Figure 4, it can be surmised that there could be at least four modules in the program as it is currently conceived: A main menu, data input, and data display in addition to the screen title. To this we might add "sub-modules" or "level two" modules which would include utilities such as the Error Check screens, calculation modules, etc. that might be called from level 1 modules.
The design of programming systems often begins with the development of an over all hierarchy chart that displays basic relationships between various sections of the project. Then typically pseudocode is used to identify the specific actions of each module, often identifying level 2 modules which may be needed, as well as processes which may be redundant between modules (processes which may be combined). The actual pseudocode is often left to the developer or programmer. However, once again consistency and understandability are the keys. Each module should have a separate pseudocode sequence.
In that in the C++ programming language modules are developed using the "user-defined" function.
The essence of this project is to develop functions (modules) from the programming sequences in project 2 and a new
main menu function that will selectively call or access various other functions passing to them all required data.
The first task is to break the splash (title or opening) screen, input screen and output screen into separate executable functions. All data variables should be declared in the main() as strings. The input screen function should be able to receive data values by way of the parameter list and pass all entered data to the output screen function via parameters and arguments. So initially the input screen will directly call the output screen (within the scope of the input screen). At this point the program should look like project 2 when it is executed.
The second part is to create a main menu function. This function should be called from main() after the splash screen has been executed. Data should be able to be passed from main() into the main menu function and subsequently to the input and output functions via parameters. The parameter list for each of these functions should be the same (the splash screen function should be a void function).
At this point the main menu will be programmed directly in main(). It will be extracted as a separate function in the next project. Figure 6 presents a hierarchy chart with the menu module as a separate module.
The modules created in this project should be able to be used (with minor modification) in project 4. Separate the code from Project 2 into three modules: Title Screen, Data Input, and Data Output modules. Each module should be coded as a separate function. All data input should be entered into character strings (for ease of access and error checking). The user input in the menu should be a a string of which only the first character will be utilized.
Note that each module should have one way in, one way out, and limited objectives or tasks to perform.
A. General Operation
The program should display the "Title Screen" until the user presses a key to continue. The "Main Menu" should then be displayed with a prompt for user input. The menu should also display a "Quit" option. The menu screen display should follow the specifications developed in Project 2. Subsequent to the option selection, the program should branch to the appropriate module. Each module display should also be consistent with Project 2 specifications. Upon user request, each module should return control to the Main Menu.
A. All data should be entered as character strings - and converted within the appropriate modules into suitable data types.
B. Error Trapping - requirements are limited to the character entered as a response to the menu selection prompts.
C. Program Validation - Operation of each program must be substantially demonstrated as to computational reliability. Each numeric computation should be tested with a variety of data. The selection of the data set should demonstrate the program's accuracy on the broadest range practical as well as with "critical" values such as 0, or range limits. This should be represented in the data sets chosen for the demonstration of the project. It is the programmer's responsibility to be prepared to adequately demonstrate all facets of the program.
As in project 2 the project will bve submitted in two parts - development/design documents and the listing/demonstration.
Screen design for the main menu,(10 possible points)
Program Heierarchy chart, (10 possible points)
Pseudocode/flowcharting for each module (20 possible points)
Program Listing (code), (5 possible points)
Data Sets, (5 possible points)
Real-time demonstration of the program (50 possible points)
The following is a check list for the evaluation package for Project 3 -
___ A. Project 3 Performance Evaluation Sheet.
___ B. Previous evaluation of Development/Design docs
___ C. Five Data Sets- that were used to test the program
___ D. Program List - with appropriate commenting and spacing