Thinking ahead — OCR A-Level Computer Science
Thinking ahead explained
Thinking ahead covers 4 specification points, including (a) Identify the inputs and outputs for a… and (b) Determine the preconditions for devising a….
Read the full explanation
Open a point below for its explanation and revision guidance.
(a) Identify the inputs and outputs for a given situation.
This statement asks you to identify the inputs and outputs for a given situation. An input is data or a signal that a system receives, such as a learner typing exam marks into a program. An output is data or a signal the system produces, such as the printed average. To identify them, read the scenario, list every item entering the system, then list every item leaving it. For example, in a program that calculates a class average, the inputs are the entered marks; the output is the average shown on screen. Do not treat intermediate values or processing steps, such as adding or dividing, as outputs.
(b) Determine the preconditions for devising a solution to a problem.
This statement asks you to determine the preconditions for devising a solution to a problem. A precondition is a condition that must be true before a solution can be designed or started. Examples include having a clearly defined problem, knowing what data is available and its format, and understanding constraints such as hardware or time. For instance, before designing a program that finds the mean of a list of exam scores, you need to know that the scores are numbers, that the list is not empty, and that a user can enter values. Work through the problem statement, ask what must already be in place for a solution to be possible, and state each condition specifically. Do not confuse preconditions with the solution steps themselves or with outputs, which come later.
(c) The nature, benefits and drawbacks of caching.
Caching keeps a small, fast copy of frequently or recently used data, avoiding repeated trips to a slower store. A CPU cache sits between processor and main memory; a browser cache keeps downloaded pages locally. A hit finds the item in the cache; a miss forces a fetch from the slower store, usually followed by copying it in. Benefits: faster access, less waiting, and less load on memory, networks or servers. Drawbacks: limited capacity, so older items are replaced; the cost of cache hardware or storage; and stale data, where a cached copy no longer matches the original. Use a named example for each point.
(d) The need for reusable program components.
Reusable program components are procedures, functions, modules, classes or libraries written once and called wherever the same task arises. The need comes from avoiding repeated code, which wastes effort and can leave copies inconsistent when only one is corrected. For example, a single validateEmail() function can serve a registration form, a password reset form and a mailing list form, so one fix updates all three. Reuse also supports abstraction, because callers need only know what a component does. Explain the need in terms of maintenance, consistency and development speed, using a concrete case.
Your focus
- Identify the inputs to a described system, naming each data item.
- Identify the outputs of a described system, distinguishing them from processing steps.
- Justify each entry in an inputs and outputs list by reference to the scenario.
Show all 12 objectives
- Determine the conditions that must be met before a solution to a given problem can be devised.
- Explain why each condition is necessary for the solution to proceed.
- Distinguish a precondition from a solution step or an output.
- Describe the nature of caching, including what is stored and why.
- Explain at least two benefits of caching, each with a reason.
- Explain at least two drawbacks of caching, each with a reason, using a named example.
- Describe what a reusable program component is.
- Explain at least two needs for reusable components, each with a reason.
- Explain the need for reuse using a concrete example of a component called from more than one place.
Thinking ahead exam tips
Marking Points
- Identifies each item of data that enters the system as an input, including values supplied by a user, a file or a sensor.
- Identifies each result or data item produced by the system as an output.
- Links each input and output to the given situation rather than listing generic terms.
- States the inputs and outputs as data items rather than as processes such as sorting or calculating.
- Names each item precisely, for example exam marks rather than data.
- States conditions that must be true before design begins, such as a defined problem and known data.
- Identifies data availability and format as a precondition where the solution depends on them.
- Identifies constraints such as available hardware, time or user access that limit what can be devised.
- Links each precondition to the specific problem rather than giving generic statements.
- Keeps preconditions separate from solution steps and from outputs.
- Describes caching as storing a temporary copy of data that is accessed often or recently.
- Identifies a cache hit as the requested item being found in the cache, and a cache miss as the item having to be fetched from the slower store.
- Gives a benefit such as faster access or reduced load on main memory, a network or a server, with a reason.
- Gives a drawback such as limited capacity, the cost of extra storage, or stale data, with a reason.
- Uses a named example, such as a CPU cache or a web browser cache, to support the description.
- Describes a reusable component as code written once and called from several places.
- Explains that reuse reduces duplicated code, so a fault needs correcting in only one place.
- Explains that reuse helps keep behaviour consistent across different parts of a program.
- Explains that reuse saves development time and supports abstraction, because callers need only know what a component does.
- Uses a concrete example, such as a shared validation function, to support the explanation.
Examiner Tips
- 💡Draw a simple boundary around the system and label arrows in and out before writing your answer.
- 💡Use the scenario's own nouns, such as marks, sensor reading or receipt, so your answer is specific.
- 💡Check each entry: if it is a data item entering or leaving the system, it belongs in your list.
- 💡Read the problem and ask what must already be true for a solution to be possible.
- 💡Write each precondition as a separate, checkable condition.
- 💡Give one example from the scenario for each condition you state.
- 💡Learn the terms hit and miss precisely, and use them in your answers.
- 💡For each benefit or drawback, state the reason it arises before you move on.
- 💡Use one clear example, such as a browser cache, to show that you understand how caching works in practice.
- 💡Define a reusable component in one sentence before explaining why it is needed.
- 💡Link each need to a specific effect, such as fixing a fault once or keeping behaviour consistent.
- 💡Use one concrete example and refer back to it, rather than inventing several unrelated ones.
Common Mistakes
- Lists processes such as calculating or sorting as outputs; restate the result that the process produces.
- Omits an input the scenario implies, such as a stored value; reread the situation for everything the system uses.
- Gives vague entries such as data or information; name the specific item from the scenario.
- Describes algorithm steps instead of the conditions needed before one can be designed; state what must be true first.
- Gives generic statements such as the program must work; name a specific condition from the problem.
- Confuses outputs with preconditions; outputs describe results, while preconditions describe what must already be in place.
- Treats a cache as permanent storage; the correction is that a cache holds temporary copies that can be replaced.
- Confuses a cache miss with an error; the correction is that a miss means the data must be retrieved from the slower store.
- Lists benefits and drawbacks without linking them to the nature of caching; the correction is to explain why each one follows from keeping a small, fast copy.
- Treats reuse as copying and pasting code; the correction is that reuse means calling one tested component from several places.
- Describes reuse only as saving typing; the correction is to link it to maintenance, consistency and abstraction.
- Gives a general statement without an example; the correction is to name a specific component and show how it is used in more than one place.