Previous Chapter
| Previous Chapter |
Main Menu | Next Section |
| Section I: User Interface Analysis - Giving Olympia Choices | Section II: Functional Decomposition of 'main' | Section III: C++ Code | Section IV : Putting It All Together |
As you may have noticed, the focus of this 'text' is not so much
on the details of C++, but on the principals of software engineering
and program design. Discussion of specific C++ features and syntax
comes up as part of the more general discussion of how to implement
the design of some programming problem. It is likely, however,
that the struggles of getting your programs to work have caused you
to focus on the details and syntax of C++. You are urged to keep
in mind the real focus of this material - a core set of strategies
and techniques for managing the complexity of the programming
task.
It is especially appropriate that this reminder take place at
the beginning of this chapter because it focuses not so much on software design, but on a number of C++ details relevant
to implementing a good design. As you read this material and explore
C++ in more depth, be sure to keep in mind the use of the engineering
principals we have already learned.
Section I. User Interface Design - Giving Olympia Choices
The 'main' we wrote in chapter five was simply a test of the Contract class and was not at all useful to Olympia, the person with whom we have contracted to write a program. As written, the test (or driver) program did not allow Olympia to view the contracts as she might wish or make any changes she might like. To allow Olympia (hereafter referred to as 'the user') to choose how she wants to access or modify the information available in the contracts, requires the creation of a user interface. Work on such an interface earlier would have detracted us from our focus which was to understand how to design, code, and test C++ classes
Having learned how to declare, use, and test a class, it is now time to return to the original problem and explore a more useful user interface and its implications for the rest of the program. Be forewarned that the program we are about to create is still much too simple. In the next chapter we will add more functionality which will increase the usefulness of the program and open new possibilities for the user interface.
In our previous discussions of user interface designs we have
ignored issues involving the manner and order of the dialogue
between the program and the user. Whole books exist on the subject
of how best to interact with users. The issues
include how to decide what kind of input to use (keyboard, mouse,
light pen etc.), what colors and screens designs to use, the organization
and complexity of menus, etc. Unfortunately, we have to limit
our discussion of this topic here, but you might want to explore
these issues on your own and you certainly should at least be
aware that they exist.
At this point we will assume that our program is to continually
ask the user to input a choice of action via the keyboard until
the user signals that he or she is finished. We will further assume
that the input requests will be based on relatively simple menus.
This simplifies some design issues, but we still need to decide
which questions to ask first of the user. This may not sound like
much, but good vs. poor sequencing of questions can make the difference
between a program that has a comfortable "look and feel"
and a program that just doesn't feel right.
In this program (perhaps simply because it is the easiest way to handle other issues) we will first ask users which operation they want to perform (view or change contracts), then which contract they want to work with, and finally which piece of information they want to change (or view). In summary then the user will have three choices to make:
But, perhaps, part of this is wrong! Each contract only involves four items - the square footage, the number of desks, the number of days, and the charge per week. Why not simply display all the properties of an instance whenever the user wants to view information, rather than force the user to choose which property to display. Here we see a hint of the types of decisions that go into more complex programs. There is a trade off here between the selective power a user has and the simplicity of the program as well as the work required of a user.
Let's go with the option of displaying all information about a contract each time. Therefore, we will not need a menu of choices for the display, but we will still need a menu of choices to change the values of properties. It would be poor design to force the user to re-enter the values for all properties when he or she only wants to change the value of one property.
We have now made a number of decisions and it is time to turn this into a formal interface analysis:
Interface:
An Introductory Screen:
"W E L CO M E TO O L Y M P I A ' S
O F F I C E C O N T R A C T P R O G R A M"
An Exit Screen:
"Some Appropriate Message"
Inputs:
All inputs come from a user at a keyboard
1. Menu:
"Please choose one of the following operations
'D' to display the information for a contract
'C' to change the information for a contract
'Q' to quit the program"
Input: <choice>, a character
2. Prompt: "Please choose which contract (1 through 5) that you wish to work with."
Input: <contract number>, an integer
3. Menu:
"Please enter the letter corresponding to the property you want to change
'S': square Footage
'K': number of desks
'Y': number of days per week
'N': none"
Input: <choice>, a character
4. Prompt: "What is the new square footage for the contract?"
Input: <square footage>, a integer;
5. Similar prompts and integer inputs for the number of desks and number of days
6. Prompt: "Do you really want to quit (Y) or (N)?"
Input: <choice>, a character
Outputs:
All outputs are to the screen:
1. "The square footage for the contract is: < square footage>"
"The number of desks for the contract is: < number of desks>"
"The number of days for the contract is: < number of days>"
"The per week charge for the contract is: < charge>"
This represents our understanding, so far, of how the interface will look. As we move on to the design stage and later to coding, we may discover refinements that will need to be made. For example, it is likely that some error messages will be required. Still, what we have here provides a good starting point.
 Top of Section |
Main Menu | Next Section |