Previous Section
| Previous Section |
Main Menu | Next Section |
| Section V: Adding String Properties to the Contract Class | Section I: An Expandable List of Contracts | Section II: Declaring the New ListofContracts | Section III: Defining the New ListOfContracts |
| Section IV : Re-Evaluating the Contract Program Design | Section VI: Declaring the New Contract Class | Section VII: Defining the New Contract Class | Section VIII: Modifying the Main Program |
Section V: Adding String Properties to the Contracts Class
In all the previous descriptions of the contract program, the
authors were careful to avoid any mention of names, addresses,
or any other data type that would require a string. Imagine that
we as programmers have shown the first version of our program
to Olympia and she has complained about inability to
the handle the name of the person handling the contract and the
address of the office to be cleaned. We might go back to the office
and rewrite the problem narrative as follows:
Users should also be able to add new contracts and delete existing
ones. When adding contracts, the contract ID, the contractee's
name, the square footage of the office, the number of desks in
the office, and the number of days per week the office is to be
cleaned all must be provided. The office address can be provided
initially or added later. To delete a contract, the user enters
the contract ID.
We have been skipping the program interface analysis in the last few modifications of this program but enough new material has been added that it is time to revisit this issue. Take your time and play with this for a bit. Then, continue with the paragraph below
Now that you are finished with your interface analysis, compare
your conclusions with those below. Remember, that there are many
possible 'correct answers' but some may be more elegant, efficient,
or easier to use than others.
One of the things that you may have noticed is that as more properties
are added, the output of those properties may need to be consolidated
and organized more cleanly. One way to handle this might be to
imagine a screen layout for the information on each contract.
For example:
Contract ID
Contractee Name: ..............................................
Office Address: ..............................................
..............................................
The square footage: .................... The number of desks: ..................
The number of days: .................... The per week charge: ..................
Another thing you may have noticed is that it is getting awkward
to input information for contract changes. If the user wants
to make a large number of changes, it can take a while - not so
much to enter the actual changes, as that can't be avoided, but
to make the requests. One way to speed things up is to have a
menu as before but allow the user to enter at once the codes for
all the fields to be changed. The menu might look as follows:
"Please enter the codes corresponding to the properties you want to change";
"Enter as many as you desire. When finished, hit Enter.";
You could not have written code to handle this before because
you did not know how to handle strings. Now you are ready for
the big time. One thing you might stop to consider at this point
is just how important a good program interface is to the success
of a piece of software. That is probably one of the criteria you, yourself, use in evaluating software. Of course, your criteria probably include issues involving
windows and the use of input devices such as mice or joy sticks.
We are avoiding those issues here but they are just variations
on the theme.
All we have discussed here is part of an improved program interface that needs to be incorporated into the program specifications. In Chapter 6 we developed a simple interface. Below is a modified interface, reflecting the modifications we have discussed:
Interface:
An Introductory Screen:
"W E L CO M E TO O L Y M P I A
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. User Option Menu:
"Please choose one of the following operations
'D' to display the information for a contract
'L' to display the information on ALL contracts
'C' to change the information for a contract
'A' to add a contract to the list
'E' to eliminate a contract from the list
'Q' to quit the program"
Input: <choice>, a character
2. Prompt: "Please enter the ID for the contract you wish to work with.
Choose 0 (zero) when you are finished with this operation."
Input: <contract number>, an integer
3. Change Contract Menu:
"Please enter the codes corresponding to the properties you want to change";
"Enter as many as you desire. When finished, hit Enter.";
'1': Contractee Name;
'2': Office Street Address;
'3': Office City;
'4': Office State;
'5': Office Zip;
'6': square Footage;
'7': number of desks;
'8': number of days per week;
Input: <choices>, a string of characters
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. "Please enter the new …." (Fill in with appropriate contract property name,
for example, 'Office Street Address'.)
Input: <property>, a string of up to 80 characters
7. Prompt: "Do you want to really want top quit (Y) or (N)?"
Input: <choice>, a character
Outputs:
All outputs are to the screen:
Contract ID
Contractee Name: ..............................................
Office Address: ..............................................
..............................................
The square footage: .................... The number of desks: ..................
The number of days: .................... The per week charge: ..................
Now that we have come up with a better program interface,
we move onto the class analysis. The question is: Have the changes
we have made required any new classes be added to the program,
or do they simply require new or modified data and function members
in existing classes? To answer this, the first step again is to
underline and circle.
Users should also be able to add new contracts and delete
existing ones. . When adding contracts the contract ID,
the contractee's name, the square footage of the office, the number
of desks in the office, and the number of days per week the office
is to be cleaned all must be provided. The office address
can be provided initially or added later. To delete a contract,
the user enters the contract ID.
This time we come up with one new verb, 'includes', and five new
nouns - 'information', 'person', 'name' (of the person), 'contractee',
and 'address' (of the office).
The verb 'includes' and the noun 'information' can be ignored
for the same reason we ignored the verb 'provided'
in chapter
8. Again, we are dealing with English phrasing
here. All programs deal with "information" and the act
of 'including' information is a description of an action performed
by almost all objects automatically - by having properties. In
saying that contracts have or include certain information, the
narrative is simply stating that instances of the class have certain
properties (data members), but it is stating nothing about the actions
of contracts. As has already been said, object-oriented analysis
and design is, in part, an art form requiring good common sense.
You will become better at the process, the more you practice it,
BUT whatever you do, make sure you use your own common sense.
The next noun is 'person'. Remember the issues here: Is 'person'
a new element in the design? If so, is it a class or a property
of some class? The answers to these questions require a careful
analysis, an analysis that can be tricky. Using our common sense
we say that persons exist as separate 'things'. They are not
a property of some other thing. We are led to believe then that
'person' might be a new class in this program. However, look carefully
at the problem. Does the problem concern itself in any way with
persons other than as contractee's of contracts? In other words,
do 'persons' exist separate from contracts? In this program
it does not seem that they do. There are no actions or responsibilities
uniquely related to persons and no properties of persons other
than those related to contracts.
We could imagine a different problem where people 'existed' separate
from contracts and performed actions or had their own responsibilities.
For example, if the problem involved professional baseball players
and each player-person had not only a contract but various properties
related to baseball statistics we would need a separate class.
The upshot then is that 'person' in this problem narrative
is another one of those words that we can ignore. In coming to
this conclusion we can also say the same thing about 'contractee'
since 'contractee's in this problem really are persons under a
different name.
The final two words in the list (name and address) are important.
They clearly refer to properties of a contract - each contract
includes a name and an office address. Thus, we have two more properties
to add to our class declaration. We also have more member functions
since these are properties that users of this class will want
to access and modify. Note that an address really refers to a
number of data items. While we could have one data member for
the address that included the street address, the city, the state,
and the zip code, it would be difficult then to only access one
part of the address, for example, the state. Therefore, when we
implement the address property, we will actually create separate
data members for each element of the address.
That completes our analysis as it relates to the 'Contract' class. Since we have added two new properties that are accessible and modifiable by users, we need to add two new knowledge responsibilities and four new behaviors to the CRC card for this class. The card, therefore, looks as follows:
Figure 10.10
While there are no new verbs in the problem narrative related to the "ListOfContracts" class, we know from earlier discussion that it has new responsibilities. Figure 11.11 shows the modified CRC card for this class.
It is now time to move to the implementation phase. As we do so,
be aware that the analysis and design phases focus on what properties
and responsibilities or behaviors are required in each class and
say nothing about HOW those properties and responsibilities are
implemented. We will discover that more changes need to be made
than have been mentioned - primarily because of the way C++ handles
strings.
 Top of Section |
Main Menu | Next Section |