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

• If your greatest current concern is whether some particular functionality can be implemented, use the bottom-up design strategy to implement that functionality as soon as possible.
• Ifyourgreatestneedsarereliabilityandlowcost,usepre-writtensoftwarewithbottom-updesign.
• If your greatest concern is overall performance and managerial control, use the top-down design
strategy.
A famous iterated-design example is NASA’s man-on-the-moon space program. President Kennedy was thinking top-down when he announced the program. However, the first implementation was a prototype. Using a modified version of the existing Atlas ICBM rocket, “Project Mercury” shot one man a few hundred miles out into the Atlantic Ocean.
Subsequent iterations of Project Mercury used a bottom-up approach to put astronauts into earth orbit. Then, NASA replaced the Atlas booster rocket with the newer and larger Titan ICBM rocket, which carried several people into earth orbit in several iterations of “Project Gemini.”
NASA’s next iteration was a top-down design plan known as “Project Apollo.” Project Apollo originally envisioned the use of a gigantic booster rocket called Nova. After working on that for awhile, NASA real- ized that a much smaller booster rocket (called Saturn) would suffice if a smaller moon lander was separated from the mother ship orbiting the moon, and the moon lander’s return module was separated from its de- scent mechanism.
Project Apollo was a top-down design, optimized for NASA’s requirements, rather than a bottom-up adaptation of existing military equipment. In the end, the top-down plan involving Nova was scrapped and replaced by a radically different top-down plan. This apparently erratic development sequence is a great example of successful real-world design. The history of successful software is the same. Different design cycles often emphasize different design strategies, and sometimes there are major changes.
Maintenance
After a program has been developed and put into operation, you might think there’s no more need to work on it. Not so. In the real world, if a program is useful, programmers are often asked to maintain it long after that program is first put into operation. On average, 80% of the work on a successful program is done after the program is first put into operation. Maintenance consists of fixing bugs and making improvements. Maintenance is much easier if good software practices are employed at the beginning and throughout the life of the program. This includes writing the code elegantly in the first place, preserving elegance when you make changes, and providing and keeping complete and well organized documentation.
Remember that documentation is more than just comments for programmers reading source code. Doc- umentation is also interface information for programmers who want to use already-compiled classes. Ap- pendix 6 shows how to embed interface information in your source code so that it can be read by javadoc and presented like Sun’s documentation of the Java API. Documentation also includes information for peo- ple who are not programmers at all but need to use a finished program. This type of documentation needs to be even more user-oriented than javadoc’s output.
If you are responsible for maintaining an existing program, here are some useful thumb rules:
1. Respect your predecessor. Don’t change any piece of code you think is wrong until you have spent as much time thinking about it as some other programmer (or you) spent creating it in the first place. There may have been an important reason for doing something in a certain way, even if there is a problem in how it was done, and you want to understand that reason before you make changes.
2. Respect your successor. Whenever you have trouble figuring out what a particular section of code is do- ing, after you thoroughly understand the problem, fix the code and documentation so that it is easier to figure out next time.
Apago PDF Enhancer
8.9 Iterative Enhancement 325