Skip to main content

Top-down approach

Short answer

Top-down approach is stepwise refinement: start with the whole system, decompose it into sub-systems and modules until each part is simple enough to implement. It gives a clear overall view and early skeleton, but low-level details are considered late. Top-down integration testing uses stubs.

Define top-down approach in terms of software engineering.

The top-down approach is a design (and development) strategy in which the system is first viewed as a whole and then broken down, step by step, into smaller sub-systems and modules until each part is simple enough to be implemented directly. It is also called stepwise refinement (Wirth).

How it works

  1. Start with the main function of the system (the top-level module or context diagram).
  2. Decompose it into a few major sub-functions.
  3. Refine each sub-function into smaller sub-functions.
  4. Repeat until every lowest-level module performs one clear task.
  5. Define the interfaces between modules at each level, then code the modules.

Example: payroll system

                  +----------------+
                  | Payroll system |
                  +----------------+
         +-------------+-------------+
         |             |             |
   +-----------+ +-----------+ +-----------+
   | Read      | | Compute   | | Produce   |
   | employee  | | salary    | | payslips  |
   | data      | |           | | & reports |
   +-----------+ +-----------+ +-----------+
                   |       |
            +----------+ +----------+
            | Compute  | | Compute  |
            | gross    | | tax and  |
            | pay      | | deduct.  |
            +----------+ +----------+

In top-down integration testing, the same idea is applied to testing: the top module is tested first with stubs standing in for lower modules, and the stubs are then replaced by real modules one at a time.

Advantages

  • Gives a clear overall view of the system from the start, and it matches how requirements are written.
  • Errors in the main structure and interfaces are found early.
  • Work can be divided among teams by sub-system.
  • A working skeleton (with stubs) can be demonstrated early.

Disadvantages

  • Low-level details (hardware, performance, reusable library code) are considered late and may force redesign.
  • Stubs must be written for testing, which takes effort.
  • Less reuse of existing components than the bottom-up approach, which builds from low-level modules upward.

In practice most projects use a mix: top-down for the architecture and bottom-up for reusable low-level components.

✓ Answer checked by Claude Sonnet 5.5

All Software Engineering chapter 3 questions →