Abstraction and Decomposition Exam Questions

• A It allows the programmer to ignore details that do not affect the simulation (1)
• The only correct answer is A. The correct answer is it allows the programmer to ignore details that do not affect the simulation.
• B is not correct because splitting a problem into smaller parts is decomposition
• C is not correct because reusing code in other programs is a benefit of subprograms
• D is not correct because abstraction removes detail and does not make an exact copy of the real world

• A They allow a block of code to be reused without being rewritten (1)
• The only correct answer is A. The correct answer is that subprograms allow code to be reused.
• B is not correct because subprograms do not make variables global
• C is not correct because subprograms do not stop a program from having logic errors
• D is not correct because a program still needs to be tested when subprograms are used

• B Split the problem into smaller tasks (1)
• The only correct answer is B. The correct answer is splitting the problem into smaller tasks.
• A is not correct because one long section of code does not split the problem into smaller tasks
• C is not correct because removing details from a problem is abstraction
• D is not correct because including every detail is not abstraction and adds unnecessary complexity

Award one mark for any of the following:

• Unnecessary/irrelevant details can be removed/hidden (1)
• The model is simpler/easier to develop/understand (1)

Allow an example, e.g. the programmer does not need to model the engine temperature if it is not needed in the game.

Do not accept 'removes all detail' / 'makes the model more realistic'.

Award one mark for any of the following up to a maximum of one mark:

• The code only has to be written once (1)
• The subprogram can be reused/called many times/in several programs (1)
• The subprogram only has to be tested/debugged once (1)
• Other programmers can use the subprogram without knowing how it works/hides how the subprogram works (abstraction) (1)

Do not accept unqualified 'easier'/'faster'/'quicker'.

Do not accept makes the program(s) run faster/quicker (a subprogram does not make a program run faster).

Award one mark for any of the following up to a maximum of two marks:

• Breaking down/splitting a problem/task/solution into smaller parts/sub-problems (1)
• Each smaller part/sub-problem can be solved/analysed/understood separately (1)
• Each smaller part/sub-problem can be broken down further (until each task is manageable) (1)
• The solutions to the smaller parts are combined (to solve the whole problem) (1)
• Allows a large/complex problem to be solved by different people/teams (1)

Do not accept removing/hiding unnecessary detail (this is abstraction).

Do not accept a named example on its own, e.g. 'making the score and the movement separate parts of the game', with no definition.

Award up to two marks for a linked description such as:

• Unnecessary detail is removed/ignored (1) so the programmer can focus on the features that matter to the problem (1)
• The model only includes the parts of the real-world thing that the program needs (1) so less code/data is needed to represent it (1)
• A complicated real-world object/system is replaced by a simpler model (1) which is easier to analyse/understand (1)

Do not accept responses that describe decomposition.

Do not accept responses that say abstraction makes a model more realistic or more detailed.

Do not award credit for generic statements about abstraction, such as that it makes a program faster, with no linked benefit for the model.

Award up to two marks for a linked description such as:

• Solving each sub-problem/smaller part on its own (1) is easier than solving the whole (large) problem at once (1)
• Each sub-problem/smaller part can be tested separately (1) so errors are easier to find and fix (1)
• Different programmers can work on different sub-problems/smaller parts (1) at the same time/so the work can be shared and finished more quickly (1)
• The solution to one sub-problem/smaller part can be reused (1) in other parts of the program/other programs, so it does not have to be written again (1)

Do not accept a definition of decomposition on its own with no benefit, e.g. 'breaking a large problem into smaller parts', or responses that describe abstraction, e.g. removing/hiding unnecessary detail (0).

Award up to two marks for a linked description such as:

• A subprogram only has to be written once (1) so the same code does not have to be rewritten/typed again (1)
• A subprogram can be reused/called in other programs (1) which saves development time (1)
• A subprogram can be tested/debugged on its own (1) so errors are easier to find and fix (1)
• A subprogram only has to be changed/updated in one place (1) so the program is easier to maintain/update (1)
• A subprogram can be given a name that describes what it does (1) so the main program is shorter/easier to read and understand (1)

Do not accept responses that describe abstraction (such as hiding the detail of how the code works) or decomposition (such as splitting the work between programmers), or that state that subprograms make the program run faster.

Award up to two marks for a linked explanation such as:

• The model is simpler/quicker to create (1) because unnecessary details of the real aircraft are removed/ignored (1)
• The program uses less memory/processing (1) because only the essential parts of the aircraft are stored/calculated (1)
• The model is easier to test/update (1) because there are fewer features to check/change (1)

For both marks, the expansion must follow/associate with the statement.

A benefit stated on its own, without a linked reason, can earn one mark.

Allow equivalent benefits such as the simulator runs faster or needs less storage (1) with a linked reason such as only the essential parts of the aircraft are modelled (1)

Allow the model is easier to understand (1) because the details that do not matter are hidden (1)

Do not accept 'it removes detail'/'it hides detail' on its own without stating a benefit of doing so.

Do not accept benefits of decomposition, such as 'different programmers can write different parts'.

Do not accept 'the user cannot see the code' or 'it is more secure'.

Award up to two marks for a linked explanation such as:

• Each part of the program can be written by a different programmer (1) so the program is completed more quickly (1)
• Each smaller problem can be solved on its own (1) so a programmer can focus on one task at a time (1)
• Each part can be tested separately (1) so errors are easier to find/fix (1)
• Parts of the program can be reused (1) so less code needs to be written (1)
• The finished program is easier to understand/manage (1) because it is split into smaller parts that each do one job (1)

For both marks, the expansion must follow/associate with the statement.

Only award the second mark where the benefit is expanded with a linked reason.

Do not accept 'it breaks the problem into smaller parts' on its own, as this repeats the question without a benefit.

Do not accept 'it is easier' without saying what is easier, such as easier to understand, test or write.

Do not accept benefits of abstraction, such as 'it removes/hides unnecessary details'.

Do not award the second mark for 'it is quicker' unless the answer says why, such as the work being shared between programmers or code being reused.

Award up to two marks for a linked explanation such as:

• The same subprogram can be called/used more than once (1) so the code does not need to be written/typed again (1)
• The subprogram can be tested on its own/separately (1) so any errors in the calculation are easier to find/fix (1)
• A change/update to the calculation only needs to be made in one place (1) so the program is easier to maintain/update (1)
• Work can be shared between programmers (1) so the program is completed/written more quickly (1)
• The subprogram can be reused/copied into another program (1) so less time is spent writing/developing new code (1)

For both marks, the expansion must follow/associate with the statement.

Do not accept 'it is easier' on its own without an expansion of what is easier.

Do not accept 'it is a small piece of code'/'it breaks the program up' on its own without a benefit of using the subprogram.

Do not award 'it removes unnecessary detail' as this describes abstraction, not a benefit of using a subprogram.

Indicative content

Details that could be abstracted from the real department

• Details that do not affect how patients move through the department, such as the colour of the walls or the names of the staff, could be left out of the model.
• Each patient could be represented using only the data the simulation needs, such as arrival time, triage category and treatment time, instead of a full medical record.
• Staff could be modelled as a resource with a role and an availability, rather than as named individuals.
• Rooms and corridors could be represented as connected spaces with a capacity, ignoring their exact size and the furniture in them.
• The passing of time could be modelled in fixed steps, ignoring the real clock time of each event.

How the problem could be decomposed

• The simulation could be split into stages, such as patients arriving, triage, treatment and discharge.
• Each stage could be written as a separate subprogram, for example one subprogram to generate patient arrivals and another to assign a room.
• The rules for allocating staff could be built as a separate part from the department layout.
• A separate part could produce the results, such as the waiting times and queue lengths.
• The separate parts could be combined to produce the whole simulation, in the same way that subprograms are called from a main program.
• Different programmers in the team could work on different parts at the same time.

The benefits of these techniques for this simulation

• Only the factors that affect patient flow are included, so the results the hospital gets back are the waiting times and queue lengths it wants to test.
• A change to staffing or to the room layout only has to be made in one part, so the hospital can test two layouts without the whole program being rewritten.
• An error in one stage, such as triage, can be found and fixed without affecting the other stages, so the simulation is more reliable.
• The parts can be reused, for example the subprogram that generates arrivals could be used again when the hospital tests a different layout.
• Smaller parts are easier to understand and test on their own before they are combined, so the simulation is quicker to develop.

Guidance

Level 3 responses must cover both abstraction and decomposition, with benefits clearly applied to the hospital simulation.

Do not accept abstraction described as adding detail to the model, or decomposition described as testing the finished program; a response that only says detail is removed, without naming any detail of the emergency department, cannot go beyond Level 1.

Levels

• Level 0 (0 marks): No rewardable content.
• Level 1 (1–2 marks): Basic, independent points are made, showing elements of understanding of key concepts/principles of computer science. (AO1) The discussion will contain basic information with little linkage between points made or application to the context. (AO2)
• Level 2 (3–4 marks): Demonstrates adequate understanding of key concepts/principles of computer science. (AO1) The discussion shows some linkages and lines of reasoning with some structure and application to the context. (AO2)
• Level 3 (5–6 marks): Demonstrates comprehensive understanding of key concepts/principles of computer science to support the discussion being presented. (AO1) The discussion is well developed, with sustained lines of reasoning that are coherent and logically structured, and which clearly apply to the context. (AO2)

Indicative content

How the app could be broken down

• Into separate parts such as recording a run, calculating calories, storing history and producing the weekly summary.
• Each part could be a subprogram, for example calculateCalories(distance, time).
• The user interface could be separate from the data storage.
• The app could be split into modules that the two programmers can work on independently.
• The weekly summary could reuse subprograms that read the stored runs.

Benefits of using subprograms

• Code can be written once and called many times, for example the calorie calculation used for every run.
• A subprogram hides its internal logic, so a programmer can call it without knowing how it works.
• Subprograms make code easier to read and understand because each has a clear name and purpose.
• A subprogram can be tested on its own before it is added to the app.
• Errors are easier to find and fix in a smaller subprogram.
• A subprogram can be reused in another app or a later version.

How this helps the two programmers

• They can work on different subprograms at the same time, saving development time.
• Each programmer needs to know only the inputs and outputs of the other programmer's subprogram, not its internal code.
• One programmer can change a subprogram without affecting the other's code, as long as the interface stays the same.
• Work can be combined more easily because the parts are separate.
• Testing can be divided between them.

Levels

• Level 0 (0 marks): No rewardable content.
• Level 1 (1–2 marks): Basic, independent points are made, showing elements of understanding of key concepts/principles of computer science. (AO1) The discussion will contain basic information with little linkage between points made or application to the context. (AO2)
• Level 2 (3–4 marks): Demonstrates adequate understanding of key concepts/principles of computer science. (AO1) The discussion shows some linkages and lines of reasoning with some structure and application to the context. (AO2)
• Level 3 (5–6 marks): Demonstrates comprehensive understanding of key concepts/principles of computer science to support the discussion being presented. (AO1) The discussion is well developed, with sustained lines of reasoning that are coherent and logically structured, and which clearly apply to the context. (AO2)

Level 3 responses must cover both decomposition and subprograms.

Do not accept vague statements such as 'subprograms are easier' without a reason.