Abstraction and automation study guide

Build the explanation from the problem

Start by identifying the problem that must be solved. Explain which real-world objects or phenomena are being modelled and which details are necessary. A model is an abstraction, so not every real-world detail should be retained. State that details are discarded when they do not contribute to solving the problem to the required degree of accuracy. If the original problem is too complex, use problem abstraction or reduction: remove details until the problem has a representation that is possible to solve or reduces to one already solved.

Move from model to executable solution

A strong explanation follows the automation chain:

1. Create an algorithm for actions on, or with, the modelled data.
2. Implement the algorithm as program-code instructions.
3. Implement the model in data structures.
4. Execute the code.

When discussing the algorithm, identify sequence, assignment, selection and iteration where relevant. Remember that an algorithm must always terminate. A hand-trace follows the algorithm step by step, updating values after assignments, following the selected branch, and repeating iteration only as specified. Use suitable test data to check the resulting behaviour and use logical reasoning to argue that the solution is correct. User feedback can also contribute to checking how well the program works. Efficiency should be argued logically rather than asserted without explanation.

Explain the abstraction level precisely

If the question concerns an object, discuss information hiding and data abstraction. Explain what the object does while separating that use from how it is constructed. A stack illustrates this distinction: its implementation may use an array and a pointer for the top of the stack, but those representation details are hidden from the way the compound data object is used.

If the question concerns a method, distinguish procedural and functional abstraction. Procedural abstraction removes the actual values from a computation and produces a procedure representing a computational pattern or method. Functional abstraction hides the particular computation method as well; it requires another abstraction beyond the procedure. Do not describe these as interchangeable terms.

If the question concerns structure, use procedural decomposition to split the problem into identifiable sub-problems. Explain how each sub-problem could be further divided. Then consider composition: procedures can be combined into compound procedures, and data objects can be combined into compound data such as a tree data structure.

Self-check questions

• Can you define an algorithm and explain why termination matters?
• Can you identify sequence, assignment, selection and iteration in a pseudo-code solution?
• Can you describe how a hand-trace checks the changing state of an algorithm?
• Can you distinguish representational abstraction, generalisation or categorisation, information hiding and problem abstraction?
• Can you explain why a stack implemented with an array and a top pointer demonstrates data abstraction?
• Can you distinguish a procedure produced by procedural abstraction from a function produced after functional abstraction?
• Can you trace the complete route from model, to algorithm, to code and data structures, to execution?
• Can you justify correctness and efficiency with logical reasoning, test data and user feedback rather than merely claiming that a solution works?