cs1ch3sec9.htm
 

CHAPTER THREE

Analysis and Design : First Steps

 
Section IX: Taking Advantage of Patterns Section I : Problem Analysis Section II: Problem Analysis Section III: Patterns Section IV:The While Loop With Priming Read Pattern
Section V: The Counter Pattern Section VI: The Sum Pattern Section VII: The Average Pattern Section VIII: The Salary Problem Revisited

  


Table of Contents

Learning C++:
An Index of Entry Points

2. The

of C++

A reference document on the basic elements of C++.


3. The Patterns


Index!

A. Patterns and Purpose Statements
Back at the beginning of this chapter we talked about the need to design an algorithm before proceeding to code and about the challenge of writing an algorithm that can easily be translated into computer code. We then introduced patterns as one aid in writing such translatable algorithms. We close this chapter with a discussion of just how to take advantage of these patterns.

As part of the analysis phase for a problem, you discover the purpose of a program. Notice that the various patterns also have a purpose. The average pattern, for example, has as its purpose:

to calculate the average of some set of numbers.

Big deal, hu? But, if you compare the purpose of your problem with the purpose of the various patterns you might find a match! If you decide, for example, that the problem you have in front of you needs an average calculated, it is clearly time to pull out the old average pattern.

Please take advantage of these patterns. If you don't, you will be 're-inventing the wheel' every time you start a new program. To summarize then - the steps you know for successfully completing a programming problem are:

  1. Analyze the problem to develop a set of specifications.
  2. Use those specifications to determine what variables, constants, and patterns might be needed.
  3. Use the patterns to help create an algorithm for the problem.
  4. Trace your algorithm if you have any doubts it will work.
  5. Translate your algorithms into C++ code.
  6. Compile your code and fix any syntactic errors.
  7. Test the compiled code with a number of different values to make sure it works.

Each of these steps depends on the ones above it and, if you discover a problem, you may need to go back to an earlier step to fix that problem. When you think you are finished, make sure that the output you have matches your specifications. It is not uncommon for programmers to write a set of specifications and then drift away from them as they go through the rest of the steps. It is a bit like that game where one person whispers something into someone's ear and the 'secret' gets passed from person to person, and finally passed back to the original person. Usually, the final version of the secret is quite different from the original.

And, be careful with your testing. For example, in the average problem we just looked at, a good set of tests would have included two or three sets of numbers whose averages were easily calculated. Three test possibilities might be:

10, 20, 30 where the average is 20;
5, 6, 7 where the average is 6;
at least one run where no numbers were entered - to test the 'if' statement.

In general if your program has multiple 'paths' (different sets of code that are chosen by 'if' and 'while' test conditions) each of those paths should be tested with a data set.

B. Wrap Up
In this chapter you have been introduced to algorithm patterns - an important tool in program development. We have assumed that our programming problems are simple enough to be solved with one pattern or some combination of patterns. Real world problems are usually much more complex and require some kind of 'divide and conquer' strategy. In the next chapter we will take a look at one variation of this strategy. However, remember, as you read the next chapter, that, once a problem is broken up into parts, solving each of those parts may benefit from the use of the patterns you learned here.


Top of Section Main Menu Next Chapter