Top-down design does not require which of the following?
2010
Top-down design does not require which of the following?
Answer: B. loop invariants — Top-down design is a decomposition strategy. It begins with a single high-level statement of what a system must do, and repeatedly splits that statement into…
- A.
stepwise refinement
- B.
loop invariants
- C.
flowcharting
- D.
modularity
Attempted by 9 students.
Show answer & explanation
Correct answer: B
Top-down design is a decomposition strategy. It begins with a single high-level statement of what a system must do, and repeatedly splits that statement into smaller, well-separated sub-problems until each piece is simple enough to implement directly. Everything the method needs is therefore a means of producing or recording that structure: a way of taking one refinement step, a way of drawing the boundaries between the resulting units, and a notation for describing the procedure each unit is meant to carry out. Establishing that finished code actually behaves as specified is a separate activity, program verification, which reasons about executable statements rather than about how the problem was partitioned.
The question asks which of the listed items plays no part in that activity. The test to apply is therefore not whether an item is strictly mandatory on every project, but whether it belongs to the vocabulary of top-down design at all, or comes from a different discipline.
Stepwise refinement is the mechanism of top-down design itself: each level of the hierarchy is rewritten as a slightly more detailed level, so without it the method has no way to proceed.
Modularity is the property the decomposition aims at: the sub-problems become units with defined interfaces, which is what makes splitting the problem worthwhile.
Flowcharting is the notation the structured-design tradition uses to record the control flow of the procedure that a refinement step proposes. The particular notation can be swapped for pseudocode or a structure chart, but writing the design down in some such form is part of carrying out the decomposition.
Loop invariants are assertions attached to an existing loop, used to prove partial correctness by induction over its iterations; they presuppose written code and say nothing about how the problem was partitioned.
Three of the listed items are notions of the design activity itself: refinement is how it proceeds, modularity is what it produces, and flowcharting is how it is recorded. Only loop invariants come from program verification, a discipline concerned with the behaviour of code that has already been written. So the one that top-down design does not require is loop invariants.