C++ 13 Review Questions

ANALYSIS AND DESIGN

Please note that the material on this website is not intended to be exhaustive. This is intended as a summary and supplementary material to required textbook.

INTRODUCTION

Having a systematic approach two programming means that you will approach each problem in the same methodological way. So you will take the same steps to writing programs for each problem. However, there are some variations. For example, we will present to general systematic approaches to programming here. The first approach is constructed for the beginning programmer. It is relatively simple and basic and helps the student programmer get a handle on the necessary tools.

The second approach models the kind of approach used by professional programmers. This approach is sometimes called the Software Development Life Cycle (SDLC). With this second approach, you will see a summary of a different and more complicated organization of basically the same material.

Our suggestion is that you start with the first approach and then change over to the second one when you are ready. In the end, you should choose the approach that best helps you get a handle on the problem you are programming for.

The simple approach to a systematic approach states that there are two parts to a systematic approach to programming. These two parts consist of solving the problem and implementing the solution. What needs to be emphasized here is that the first part is done without writing any code. The solution to the problem is logically constructed and is expressed using specific tools and templates. After the solution is constructed, we implement it. This implementation includes using programming languages that eventually have to be translated into the computer's machine language – the actual language that the computer understands.

THE ANALYSIS

The first part of solving the problem has 3 sub-steps. Those 3 sub-steps consist of writing the analysis, writing the design, and testing the solution. First, it is important to distinguish analysis from the design. The analysis expresses the basic informational requirements of the problem. This information conveyed in the analysis includes the data inputs of the program, the data outputs, data that is calculated but not part of the output, and formulas. The beginning template we will use for the analysis is below. Note that this is only a beginning template and that you should find your own way to modify this template as more complex problem solving and programming issues are introduced.

Analysis: Input: Output: Temporary Variables: Formulas:

The input part of the analysis will consist of the information that the person running the program, the user, will enter. This usually consists of data values only; the user rarely, if ever, enters a formula. The output part of the analysis will consist of the information that the user either wants to see, store, or send to another location. Like the input, we are usually referring to data values. The Temporary Variables will consist of all values calculated in the formulas but are not output. Finally, we will list the formulas used. In terms of the sequence of filling out this analysis template, we need to fill out the Formulas before we fill out the Temporary Variables, because the Formulas often determine what is a Temporary Variable. But in terms of the order of appearance, Temporary Variables will be listed before the Formulas because, like input and output, Temporary Variables are data and it is preferable to list like items together.

Below is a sample analysis. The problem that this sample analysis will address is listed before the analysis.

Problem: You are to find and display the average of 3 test scores.

Analysis: Input: Test #1, Test #2, Test #3 Output: Average Temporary Variables: Total Formulas: Total = Test #1 + Test #2 + Test #3

Average = Total/3

We should note few things about the above analysis. For the Input, Output, and Temporary Variables, we do not fill in numeric values. It is the job of the user to select the numeric values for the Input and the job of the computer to calculate the numeric values for the Temporary Variables and Output. The next thing we should observe is that once a term is used, Average in the Output for example, that term is spelled the same way throughout the rest of the analysis. As a result, Average in Formulas is spelled the exact same way as Average in Output. Finally, Total is a Temporary Variable because its value is calculated in Formulas, but is not part of the Output.

THE DESIGN

The next part of solving the problem consists of writing the Design. While the Analysis is concerned with understanding the problem by listing its requirements, the Design contains the actual solution to the problem. How that solution is expressed depends on the kind of problem solving approach we are using. In an Object-Oriented (OO) programming approach, we would be identifying the parts or players needed to solve the problem and then we would determine how and when these parts would communicate with each other to actually solve the problem. We will be using a Structured programming approach, which is much easier to use.

Though there are other parts to it, the Structured programming approach is primarily concerned with taking the right sequence of actions to solve the problem. The solution will be expressed using verb-phrases. One can use a number of tools when expressing the solution in a Structured programming approach. At this programming level, we will write the solution to our problems using an algorithm. There are three important parts to the definition of an algorithm. The first part says what we have already said, that there is a correct sequence of actions to take. The next part says that this sequence of actions will solve the problem – that is, give us the correct answer every time. Finally, the solving of the problem occurs in a timely fashion.

If writing a design means listing the actions, we need to know what actions are available to us. The actions available to beginning programmers include get input, process information, and print output. When we say get input, we are telling the computer to ask the user to enter in specific information and then tell the computer to use the appropriate input device to read that information. When we say process information, we are telling the computer to apply operations (arithmetic, logic, or shifting) to data it has. And when we say print output, we are telling the computer to send the requested information to a specified output device, usually the monitor. We should note that during the design time, we are not actually telling the computer to do anything; telling the computer to act is in our planned solution, and programming the computer comes later.

Now we know what actions we can take, we need to determine the order of the actions to write the algorithm. The steps in an algorithm can be determined in a number of different ways. Some of these approaches include working backwards, using the algorithm from a similar problem, means-ends, and trial and error. But the one we will use here is called the Input-Process- Output (IPO) algorithm. What this means is that we will list all of the get input steps first, then we will list all of the process information steps second, and we will finally list all of the print output steps last. To determine what get input, process information, and print output steps we need we will consult the analysis for that problem. Below is an example of an algorithm that is written by applying the IPO approach and using the analysis of that problem.

Problem: Find and display the average of 3 test scores.

Analysis: Input: Test #1, Test #2, Test #3 Output: Average Temporary Variables: Total Formulas: Total = Test #1 + Test #2 + Test #3 Average = Total /3

Design (using an IPO algorithm): Get test #1 Get test #2 Get test #3 Calculate Total Calculate Average Print Average

Using the IPO approach, we started by listing the get input steps. How do we know what get input steps are involved? For

each input item, whcih we will call a variable, in the input part of the analysis, we write a get input step. That is why we have the steps Get test #1 and so on.

Then for each formula in the analysis, we will write a process information step. Each step will state what it is calculated. We do not need to rewrite the formula used. That is why we wrote Calculate Total and Calculate Average.

Finally, the print output step was determined writing the step for each variable in the output part of the analysis.

We have arrived at the final part of Solving the Problem. That part is testing the solution. Note that we are testing the solution before we write any code. Though we will be testing the solution by testing the code later on.

THE TEST OF THE SOLUTION

The last part of solving the problem consists of testing our analysis and design. We can do this by creating a table of information using a spreadsheet. Using the analysis and design from the test average problem, our test of the solution of the analysis and design looks like the following:

Test1 Test2 Test3 Total Average Get Test1 90 ? ? ? ? Get Test2 90 80 ? ? ? Get Test3 90 80 70 ? ? Calc Total 90 80 70 240 ? Calc Average 90 80 70 240 80 Print Average 90 80 70 240 80

To construct this test, we simply put each variable from the analysis into a column and put each design step into a row. The values entered for Test1, Test2, and Test3 produce a result that is known without using the formulas from the analysis. The value for Total is calculated by implementing the formula in the analysis by adding the cells containing the test scores for that row. And we implement the formula used to calculate Average by dividing the contents of the cell holding the Total for that row by 3.

Returning back to the values we entered for Test1, Test2, and Test3, we need to repeat that we, those who constructed this test, must pick values that produce a known result. That is because if the answer calculated for Average is different from 80, the answer we expected, we know that there was an error in either the Analysis and/or the Design.

IMPLEMENTING THE SOLUTION

Implementing the solution means exactly what it says. We have to tell the computer how to carry out our solution to the problem. To do that, we must translate the solution into code, we must eliminate errors, and we must document the code. But whereas the order in which the steps of solving the problem are performed are sequential, the steps in which implementing the solution takes place, for the most part, are concurrent. That is we will be translating the solution, eliminating error, and documenting the code seemingly at the same time.

TRANSLATING THE SOLUTION

If we have put the appropriate work into solving the problem, then writing the code will be like translating a U.N. speech into the language of a listener. Most of the mental work, for the beginning programmer, takes place while we try to solve the problem. Translating the solution should be simple once we have sufficiently learned the language.

Writing code has 3 prerequisites. You must know what each part of the code does. We can learn that by reading definitions and seeing examples. You must also know the syntax of each C++ construct you have to use. Knowing this syntax is equivalent to knowing the syntax of the language you speak in. When writing code, the syntax of the programming language tells us the order in which each symbol should occur. Finally, and this is where using the solution to the problem comes into

play, the solution to the problem tells us when to use each C++ construct. That is what we need to know to write code. We need to understand each construct we use, we need to know the syntax so that we can write the code properly, and we need to know when to use each construct. We will not go into the details here, but as you learn the different C++ constructs, remember the constructs used by the solution so you can recognize what C++ construct to write as you translate each part of your solution into code.

ELIMINATING ERRORS

The errors that we must correct when writing programs are of 3 kinds: compiler errors, runtime errors, and logical errors. We should note that we will be oversimplifying things when describing compiler errors. Before defining what a compiler error is, we must first define a compiler. A compiler is one of the tools that a computer uses to translate code, written in a programming language, into a language a computer understands. To help translate what is written in a programming language, a compiler must perform two tasks. The first task of the compiler is to check the code for syntax errors. A syntax error is when the symbols of a piece of code are in the wrong order. If the compiler spots a syntax error, it notes it and goes on to look for the next error so that these errors can be reported to the user. If the code being compiled does not have any syntax errors, then the compiler translates the code into machine code, code in a language the computer understands, and writes it to a file with a .obj or .o extension. Now even though the contents of the .obj and .o files are in machine code, it is not quite ready for the computer to execute the file. In order to execute the code, the machine language must be loaded into main memory.

The next kind of error that we must know how to correct is a runtime error. Whereas compiler errors occur when different parts of the code are not written in the correct order, a runtime error occurs when there are no syntax errors. A runtime error occurs when use the correct syntax to tell the computer to do something it cannot do. A common example of a runtime error is when we tell the computer to divide by 0. Because we cannot divide by 0, we cannot tell the computer how to divide by 0; thus when the computer is told to divide by 0, it is told to do something that it is not able to do.

How a computer reacts to a runtime error is unpredictable. That is because how a computer reacts to such an error depends on the machine and the software it runs.

Runtime errors are more difficult to solve than compiler errors. That is because runtime errors are more difficult to locate than compiler errors.

The final kind of error that we must know how to eliminate is a logical error. Logical errors contain no syntax errors or runtime errors. A logical error occurs when the programmer writes code that tells the computer to do something that does not help solve the problem. For example, suppose we are writing a program that will find and display the average of 3 test scores. And suppose that we have added the 3 tests together but when we calculate the average, we divide by 4 rather than 3. We can tell the computer to divide by 4 legally and the computer is able to do that. The problem is that dividing the total by 4 does not tell the computer how to calculate the average of 3 tests.

All of the 3 errors types are corrected by re-editing the code and retesting, until no errors remain.

DOCUMENTING THE CODE

Documentation is a plain language description of either of what the whole program does or what a part of the program does. The first step in documenting the code is to provide documentation at the top of the file. An example is provided below:

/* Program: TestAverage.cpp Name: Your Name Date: 07/28/10 Purpose: The purpose of this program is to find and display the average of 3 test scores */

It is recommended that you document your program as you are writing the code rather than to document after you finish writing the code.

Again, when implementing the code, we will be translating the solution into code, eliminating errors, and documenting the code concurrently. When discovering a logical error in the code, if the error is because of a mistake in the analysis or design, then the analysis and design must be corrected immediately. Then we correct the code, recompile, and retest.

REVIEW EXERCISES

Using the methods of this module provide a design, analysis, and test of the algorithms you previously developed in the Review Exercises at the end of the Introduction to Programming Environments module.

© 2011 cad18; rcm27; cpsm