2.1.3 - Decomposition and procedural plans

Separate problem components from solution components

Decomposition divides a problem into smaller subproblems. Begin with what must be achieved before deciding the precise code that achieves it.

A small shop needs to turn an order into an invoice. Problem components include obtaining valid item quantities and prices, determining charges, and presenting an accurate receipt. “Use a loop” is an implementation choice, not a customer's problem component. Keeping the distinction clear prevents an early coding choice from hiding a requirement.

Solution components can then meet those responsibilities: a reader/validator obtains acceptable order data; a subtotal routine sums quantity times unit price for each item; a delivery routine applies the delivery policy; a formatter constructs a receipt. Their interfaces specify what passes between them. The formatter needs accepted item details and calculated charges, not raw invalid entries.

This makes development easier to divide and test. The subtotal routine can be checked with a fixed small order even before the final screen exists. Components still have to fit together: separately correct routines with inconsistent units can produce an incorrect invoice. Decomposition identifies connections as well as separate tasks.

Use a hierarchy to assign responsibilities

A structure chart shows how a solution is divided into modules or subprocedures. A parent coordinates work performed by its children; a component can be decomposed again if it has distinct internal responsibilities.

For the invoice solution, Produce invoice is the coordinating component. Its children are Read and validate order, Calculate charges and Format receipt. Within Calculate charges, Subtotal and Delivery charge handle different rules. The chart shows who is responsible for which work. It is not a flowchart and does not by itself specify the temporal order of siblings.

[DIAGRAM: Invoice procedure hierarchy with charge calculation decomposed into two subprocedures; asset_slug: invoice-structure; caption: A structure chart assigns responsibility and does not specify execution order.]

The complete hierarchy is also stated in the paragraph above. To extend it for a tax requirement, add a suitable tax-calculation child under Calculate charges, then update the coordinating component and its interface so the result reaches the receipt. Adding a box alone does not define its inputs or guarantee that it will be called.

A single huge Do everything child gives little useful decomposition. Equally, a child for each trivial arithmetic symbol hides the meaningful responsibilities among fragments. Choose boundaries that can have a clear purpose and independently described inputs and outputs.

Order the steps by their data dependencies

A procedural plan gives the sequence, decisions and repetition needed to reach the result. A step that uses another step's result must wait until that result exists.