Program Design and Decomposition

Imagine being handed a programming task that is far too large to solve in one go. There is no single obvious step that completes it. Where do you begin? Program design is the discipline of deciding how the work should be organized before the individual details are written. This article follows one of the most widely used answers to that question, called top-down programming, and then looks at where that method stops being enough.

Top-down programming makes a large problem manageable through repeated decomposition. Decomposition means dividing something into smaller parts. The method begins with the complete problem, divides it into smaller jobs, and then continues dividing each job until the remaining tasks can be solved directly. The approach focuses attention on the structure of the work before the individual details.

The important movement is from broad to specific. The programmer first decides what major work the system must perform, then refines each part. Each refinement produces smaller jobs, and the refining continues level by level. A useful way to picture this is as a tree: the complete problem sits at the top, its major jobs sit beneath it, and each of those jobs may have its own smaller jobs beneath it. Decomposition stops at a branch once that branch is simple enough to solve directly.

Top-down programming is not presented as a bad method. It is a valuable and often-used way to solve problems. Its value is that it gives the programmer a practical way to organize a large problem. Even a partial top-down design gives direction to the work. Sub-problems that are not yet understood can be left in the plan as unfinished pieces, while the rest of the structure guides what to do next. Those unfinished pieces are filled in later, once the designer knows more about them.

The limitation of top-down programming is not that decomposition is useless. The limitation is that the method concentrates mainly on the instructions needed to solve the problem. That focus can leave another design question underdeveloped: what data the program must manipulate and how that data should be organized. A complete program design therefore needs more than a list of operations.

Three areas matter in program design. Subroutines describe organized pieces of work. Control structures describe how that work proceeds. Data structures describe the data that the program manipulates. The design of data structures is at least as important as the design of subroutines and control structures. If the instructions are carefully planned but the program's data receives no comparable attention, the overall design is incomplete.

The diagram shows that data structures are a full member of the design, not an afterthought. In the registration example, the plan for adding, removing, and reporting describes what the program does. Those activities do not, by themselves, settle how the registration information is designed as data. A designer who has only planned the operations has not yet answered that question.

A second limitation appears when work from one project must support another. Strict top-down programming begins with a particular problem and divides that problem into pieces that are convenient for that situation. As a result, the final design tends to be specific to the original problem. A large portion of it may not fit a different project without extensive modification.

Reuse matters because producing high-quality programs is difficult and expensive. Programmers and the people who employ them therefore have a strong reason to reuse work that has already been produced. A design that is tightly fitted to one problem makes that goal harder to achieve. The diagram contrasts the two outcomes: the same decomposition method that makes one project manageable can leave its result hard to carry into another.