Page 346 - Introduction to Programming with Java: A Problem Solving Approach

312 Chapter 8 Software Engineering
of what the test result should be before you perform a test. Before you push the “run” button, say out loud what you think the result should be! This improves your chance of recognizing an error.
Testing keeps you on track. In any development program, you should interleave testing and coding so that you get quick feedback. If an experienced programmer makes a mistake in every 8 or 10 lines of code, a new programmer is well advised to perform some kind of test after every 4 or 5 lines of new code! This makes it easy to identify errors, and it reduces your level of stress. The more frequently you test, the more positive feedback you get, and this helps your attitude—it gives you a “warm-fuzzy feeling.” Frequent test- ing makes programming a more pleasant experience.
There is no practical way to verify all the aspects of a complicated system by looking at it only from the outside. Testing should be performed on each component and on combinations of components, at all levels. As you’ll see in subsequent discussion, testing typically requires creation of some kind of extra testing code. Sometimes it’s a special driver. Sometimes it’s a special driven module. Creating such test code may seem like extra work for something that’s to be used only in a test environment and not in an actual runtime envi- ronment. Yes, it is extra work, but it is well worth the effort. Writing and using test code will save you time in the long run, and it will lead to a better final product.
8.6 Top-Down Design
The dominant design methodology for large high-performance systems is the top-down design strategy. Top-down design requires the designer to think about the big picture first—that’s the “top.” After complet- ing the design at the top, the designer works on the design at the next lower level. The design process contin-
ues in this iterative manner until the bottom level (the level with the most detail) is reached.
Apago PDF Enhancer
For an object-oriented programming project, top-down design means starting with a problem descrip- tion and working toward a solution using these guidelines:
1. Decide on the classes that are needed. You should normally include a driver class as one of the classes. To determine the other classes, think of the problem in terms of its component objects. Specify one class for each unique type of object. With large systems that have many classes, pure top-down design defers identification of detailed classes until later, because identifying detail classes is itself a detail.
2. For each class, decide on its instance variables, which should be state variables identifying object at- tributes. The driver class should not have any instance variables.
3. For each class, decide on its public methods. The driver class should contain only one public method—main.
4. For each public method, implement in a top-down fashion. Consider each public method to be a “top” method. If it is fairly involved and can be broken into subtasks, have it call private helper methods to do the subtask work. Finish writing the top methods before starting to write the lower level helper methods. Initially, implement the helper methods as stubs. A stub is a dummy method that acts as a placeholder for an actual method. A stub’s body typically consists of a print statement that displays something like “In method x, parameters 􏰀 a, b, c” where x is the name of the method and a, b, and c are values of passed-in arguments. We’ll show an example later in this section.
5. Test and debug the program. The suggested stub print messages will help you trace the program’s actions.
6. Replace stub methods one at a time with fully implemented helper methods. After each replacement, test and debug the program again.
Top-down design is sometimes referred to as stepwise refinement. The term stepwise refinement is used because the methodology encourages programmers to implement solutions in an iterative manner where
Start testing right away.