Abstraction, Decomposition and Automation

Representational abstraction removes irrelevant detail. A route planner may retain junctions, connections and travel costs while omitting building colours. The choice depends on the task: a wheelchair route may require accessibility information that another planner omits. Generalisation groups objects by common characteristics, forming an is-a hierarchy.

Information hiding prevents clients depending on non-essential implementation details. A stack user needs the operation contract without knowing whether the representation is linked or array-based. Hiding relevant constraints, such as a bounded capacity, would instead make the interface misleading.

Procedural abstraction captures a reusable computational method from individual calculations. A routine that computes a rectangle’s area can accept different dimensions. In the theory-of-computation sense, functional abstraction goes further by describing the input–output relationship independently of the particular method used to obtain it.

Data abstraction separates the use of a compound data object from its construction. Problem reduction reformulates a task as an already understood problem, for example mapping a practical connection problem to graph reachability. These forms can work together; they are not merely alternative names for shortening code.

Decomposition divides a problem into identifiable subtasks, which may be subdivided further. A reporting system can separate data acquisition, validation, calculation and presentation. Clear interfaces specify the data each subtask needs and provides.

Composition combines procedures into larger operations or data objects into compound structures. A graph model may combine vertex records and edge records; a reporting operation may compose loading, summarising and formatting. A hierarchy chart expresses this organisation, while an algorithm describes the control flow inside each task.

Automation implements models as data structures and algorithms as executable instructions. An algorithm is a finite, unambiguous procedure that terminates for its stated inputs; a continuously running service may use algorithms repeatedly while the service itself remains active.

Hand-trace pseudocode using the stated assignment, selection and loop rules, then translate those rules into the chosen language. Argue for correctness using the model, invariants, suitable tests and user requirements. Passing one example does not establish that omitted real-world constraints are irrelevant.

Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.