Computational methods — OCR A-Level Computer Science
Computational methods explained
Computational methods covers 6 specification points, including (a) Features that make a problem solvable by… and (b) Problem recognition..
Read the full explanation
Open a point below for its explanation and revision guidance.
(a) Features that make a problem solvable by computational methods.
Computational methods suit problems with features a computer can process. Abstraction removes irrelevant detail so only essential features are modelled, for example keeping bus routes and times but ignoring passengers' names. Decomposition splits a large problem into smaller sub-problems, such as checking seats and calculating fares, that can each be solved. The problem also needs defined inputs and outputs and a finite set of ordered steps that can be written as an algorithm. Recognising patterns allows one solution to be reused. Together these features show whether a computer can solve the problem.
(b) Problem recognition.
Problem recognition means deciding whether a situation is a problem a computer can help solve, and stating it clearly enough for a method to be designed. Before any code is written, identify the inputs (the data given), the outputs (the result required) and any constraints such as time, memory or accuracy. For example, a timetable with no room clashes is a scheduling problem: the inputs are classes, rooms and times, and the output is a conflict-free timetable that can be checked. Recognition also means spotting when a task is unsuitable, such as one needing subjective judgement with no clear test of success.
(c) Problem decomposition.
Problem decomposition means breaking a large problem into smaller sub-problems that are simpler to solve, test and combine. Each sub-problem should have clear inputs and outputs so that it can be designed independently. For example, a monthly sales report could be split into: read records, validate each record, total sales by region, and format output. Each part can then be coded and tested alone, and the results joined together. Decomposition relies on the inputs and outputs defined during problem recognition, so the parts fit together. Stop dividing when each piece is small enough to solve directly.
(d) Use of divide and conquer.
Divide and conquer splits a problem into smaller sub-problems of the same type, solves each, and combines the partial results into the answer. It depends on recursion, where a procedure calls itself on each smaller part until a base case is reached and that part can be solved directly. Merge sort is a standard example. A list is split into two halves, each half is sorted by calling merge sort again, and the two sorted halves are merged by repeatedly taking the smaller front item. Learners should name the divide, conquer and combine stages, identify the base case, and explain why each sub-problem must be smaller than the original. In an exam, apply the method to a scenario rather than only reciting its definition.
(e) Use of abstraction.
Abstraction is the use of a simplified model that keeps the details relevant to a problem and hides the rest. It manages complexity by hiding detail not needed for the task. A London Underground map shows stations and connecting lines but ignores true distances, because a traveller planning a route does not need them. In a program, a Student class might store a name and form group while omitting details the system never uses. To apply abstraction, identify the essential features for the task, decide what can be hidden, and check the model still answers the question. Learners should justify what was removed and explain how this makes the problem easier to solve.
(f) Learners should apply their knowledge of: • backtracking • data mining • heuristics • performance modelling • pipelining • visualisation to solve problems.
You must apply six methods to solve problems: backtracking, data mining, heuristics, performance modelling, pipelining and visualisation. Backtracking tries options step by step, abandons paths that cannot succeed and returns to the last choice, as in maze solving. Data mining finds patterns in large datasets. A heuristic is a rule of thumb giving a good, not guaranteed optimal, answer quickly, such as nearest-neighbour routing. Performance modelling predicts system behaviour under given loads. Pipelining overlaps stages so several items are processed at once. Visualisation presents data graphically to reveal patterns. Application means choosing a method, justifying it and tracing how it solves the problem.
Your focus
- Identify abstraction and decomposition in a description of a problem.
- Distinguish a computable problem from one lacking defined inputs, outputs or steps.
- Select the feature that explains why a given problem can be solved by a computational method.
Show all 18 objectives
- Identify the inputs, outputs and constraints of a given problem statement.
- Decide whether a given problem is suitable for a computational approach, justifying the decision.
- Describe a testable success condition for the output of a given problem.
- Break a given problem into sub-problems, each with defined inputs and outputs.
- Explain how the sub-problems combine to give the solution to the original problem.
- Explain why decomposition makes a problem easier to design, test and debug.
- Identify divide and conquer in a described algorithm or scenario.
- Explain the divide, conquer and combine stages using merge sort as an example.
- Describe why each sub-problem must be smaller and why a base case is needed.
- Identify the essential features and hidden details in a described model.
- Explain how removing irrelevant detail reduces complexity in a problem.
- Justify whether a simplified model is fit for a given task.
- Select an appropriate computational method for a described problem and justify the choice.
- Explain how backtracking, pipelining or a heuristic produces its result in a stated scenario.
- Distinguish between the purpose of data mining, performance modelling and visualisation in a given context.
Computational methods exam tips
Marking Points
- Identifies abstraction as removing irrelevant detail so only essential features are modelled.
- Describes decomposition as splitting a large problem into smaller sub-problems that can each be solved.
- Explains that defined inputs, outputs and a finite set of ordered steps allow the problem to be written as an algorithm.
- Recognises patterns or repeated sub-problems that allow one solution to be reused.
- Justifies whether a given problem has these features by referring to its specific inputs, outputs and steps.
- Identifies the inputs, outputs and constraints of the problem before proposing any solution.
- States whether the problem is suitable for a computational approach and gives a reason.
- Describes a clear, testable success condition for the required output.
- Distinguishes problems that can be solved algorithmically from those that rely on subjective judgement.
- Identifies sub-problems that each have clearly defined inputs and outputs.
- Shows how the sub-problems combine to produce the solution to the original problem.
- Gives a sensible example, such as splitting a sales report into validation, totalling and formatting.
- Explains why smaller parts are easier to design, test and debug independently.
- Identifies divide and conquer when a problem is split into smaller sub-problems of the same type.
- Recognises that each sub-problem is solved and the partial solutions are combined into one answer.
- Names recursion or a base case as features that signal the method is in use.
- Distinguishes divide and conquer from a simple loop that processes items one at a time without splitting the problem.
- Identifies the features of a problem that are essential to the task being solved.
- Explains which detail has been hidden and why that detail is irrelevant to the purpose of the model.
- Checks that the simplified model still produces a correct answer for the required task.
- Links the removed detail to a reduction in complexity for the person or program solving the problem.
- Selects a method from the list that matches the features of the problem rather than describing methods in isolation.
- Explains backtracking as abandoning a partial solution once it cannot lead to a valid answer, then returning to an earlier choice.
- Identifies patterns, trends or anomalies in a stated dataset when applying data mining.
- Distinguishes the approximate result of a heuristic from an optimal result and justifies accepting it.
- Uses performance modelling to predict outcomes from stated loads, rates or resource figures.
- Traces pipelined processing by showing which stage each item occupies at each time step.
- Chooses a visualisation whose form makes the relevant pattern clear for the data type and audience.
Examiner Tips
- 💡For each option, ask whether it removes detail (abstraction) or divides the problem (decomposition) before choosing.
- 💡Check that a correct option names inputs, outputs or ordered steps, since these make a problem computable.
- 💡Reject options that describe a problem with no defined method or with vague, unbounded steps.
- 💡Read the scenario and list the inputs, outputs and constraints in separate headings before answering.
- 💡Test whether the output could be checked objectively; if it cannot, say so and explain why the problem is unsuitable.
- 💡Support any suitability judgement with a specific feature of the scenario rather than a general statement.
- 💡Draw or list the top-level problem first, then break it down one level at a time.
- 💡Check that each sub-problem has its own input and output before deciding it is a valid part.
- 💡Explain how the parts are recombined to reach the final solution, not only how they are separated.
- 💡Check each option against the three stages: divide the problem, solve the parts, then combine the results.
- 💡Look for recursion or a base case in the scenario as evidence that the method is being used.
- 💡Eliminate options that describe only repeated processing of a single list unless they also split the problem into smaller parts.
- 💡Name the specific detail removed and state why it is not needed for the task in the scenario.
- 💡In a scenario, list what the model keeps before deciding what to hide.
- 💡Avoid answers that call abstraction a simpler version of the problem; give the reason the model is fit for its purpose.
- 💡Read the scenario first and identify what the problem needs, then check each option against that need.
- 💡When an option names a method, test whether its description matches the method's defining feature, not just its name.
- 💡Eliminate options that claim a heuristic is exact or that pipelining runs separate unrelated jobs, then compare the remaining choices.
Common Mistakes
- Treats any goal as computable; a problem needs a defined method with clear inputs, outputs and finite steps.
- Confuses abstraction with decomposition; abstraction removes unnecessary detail, while decomposition divides the problem into parts.
- Lists the features without explaining why a computer can process the problem; state how each feature makes the problem suitable for computation.
- Jumps straight to writing code without first defining what the problem requires; define inputs, outputs and constraints first.
- Treats a vague goal, such as making a website better, as a well-defined problem without stating measurable criteria.
- Confuses problem recognition with algorithm design by describing how to solve the problem; keep recognition to defining what the problem is.
- Splits the problem into parts that depend on each other's internal workings, so the parts cannot be tested alone; define clear interfaces between them.
- Lists individual programming statements as sub-problems rather than meaningful task-level parts; group steps into tasks with a single purpose.
- Stops dividing at a level where the pieces are still too large to solve directly; keep dividing until each part is manageable.
- Confuses divide and conquer with any method that uses a loop; the defining feature is splitting into sub-problems and combining their results.
- Treats the sub-problems as no smaller than the original; each must be simpler so that recursion reaches a base case.
- Omits the combine stage, so the answer never merges the partial results into a solution to the original problem.
- Keeps every detail of the real situation, which removes no complexity and so is not abstraction.
- Hides detail that the task actually needs, which makes the model give wrong answers; keep the features the problem depends on.
- Describes abstraction only as making things simpler, without naming what was removed or why it is irrelevant.
- Defines all six methods without applying any of them to the problem; link each method to a stated step or outcome.
- Treats a heuristic as guaranteeing the optimal solution; state that it gives a good approximation within reasonable time.
- Describes backtracking as trying options at random; correct this to ordered, systematic trial with failed branches abandoned.
- Labels any table or printed output as visualisation; correct this to a graphical representation that reveals structure in the data.