AQA A-Level Computer Science (7517)

## Learning Outcomes

- Define **composition** accurately in the context of AQA A-Level Computer Science
- Explain how composition relates to **decomposition**, **modularity**, and **abstraction**
- Identify how procedures, functions, modules, and data structures are combined into a full solution
- Apply composition to programming scenarios using clear module inputs and outputs
- Distinguish common exam confusions, especially composition versus decomposition and abstraction
- Structure stronger exam answers using precise Computer Science terminology

## AQA A-Level Computer Science (7517) Syllabus

For the AQA A-Level Computer Science (7517), you are expected to understand composition as part of a systematic approach to problem solving, with a focus on the following syllabus points:

- Know that **decomposition** breaks a complex problem into smaller sub-problems, while **composition** combines smaller parts into a complete solution
- Identify how programs are structured into **modular parts** with clear, documented interfaces
- Explain how **procedures**, **functions**, and **modules** interact through parameters and return values
- Understand the difference between **composition** and **abstraction**
- Apply decomposition and composition to realistic program-design scenarios
- Recognise the benefits of modular design, including easier testing, debugging, maintenance, reuse, and team development
- Understand that composition may refer to combining both program procedures and data structures, depending on context

## Test Your Knowledge

_Attempt these questions before reading this article. If you find some difficult or cannot remember the answers, look more closely at that area during your revision._

1. What is meant by composition in program design?
2. How is composition different from decomposition?
3. Why are clear interfaces between modules necessary when composing a full program?
4. Give one example of composition using subroutines and one using data structures.
5. Why is composition useful in testing and maintenance?

## Introduction

Composition is a design idea that students often understand informally but define badly in exams. Many know that large programs are built from smaller parts, but they do not explain clearly what those parts are, how they connect, or why this approach matters. In AQA terms, the safest way to think about composition is as the process of combining smaller components or sub-solutions to form a complete system.

This matters because exam questions do not just reward a vague statement like “split the program into parts”. Strong answers show the full process: first a problem is broken into manageable sub-problems, then each part is designed or coded, then those parts are recombined into a working solution. That recombination stage is composition.

> **Key Term: composition**
> The process of combining smaller components, modules, procedures, functions, or data structures to build a complete solution.

### Composition and decomposition: opposite directions in problem solving

Composition is easiest to understand when placed next to decomposition. These two ideas are linked, but they are not the same.

> **Key Term: decomposition**
> Breaking a complex problem into smaller, more manageable sub-problems that can be solved separately.

Decomposition works from large to small. You start with the whole problem and divide it into parts. Composition works from small to large. You take completed parts and combine them into the whole system.

A common weak answer says something like, “composition means splitting a problem into parts.” That is wrong. Splitting into parts is decomposition. Composition is what happens when those parts are put back together.

A good way to picture this is a top-down design followed by bottom-up assembly:

- Start with the full problem
- Decompose it into major tasks
- Break those tasks into smaller tasks if needed
- Design or code each task as a procedure, function, or module
- Compose those parts into a working complete program

That sequence matters because composition depends on earlier decomposition being sensible. If the original sub-problems are badly chosen, recombining them will also be awkward. For example, if a programmer creates one giant procedure called `ProcessEverything`, that is poor decomposition. Because the parts are not well separated, composition later gives few benefits.

Consider a school login system. A poor answer might say the program is “made of code for login”. A better design decomposes it into:

- input username
- input password
- validate format
- check credentials
- display result
- log failed attempt

Composition then means linking these parts together so that the full login process works in order. The main program may call `GetUsername()`, then `GetPassword()`, then `CheckCredentials(username, password)`, then `DisplayLoginResult(result)`.

This shows an examiner that you understand not just the definitions, but the flow of control through the system.

> **Key Term: top-down design**
> A method of planning a solution that starts with the whole problem and breaks it into smaller sub-problems.
>
> **Test Tip:** If a question asks you to compare composition and decomposition, do not define only one and assume the contrast is obvious. State clearly that decomposition breaks a problem down, while composition combines the resulting parts into the final solution.

There is also a practical reason these ideas are taught together. Decomposition helps human thinking. Composition helps implementation. A person can focus on one manageable sub-problem at a time, but the computer still needs one final executable system. Composition is the step that turns separate pieces into that final system.

### How composition works in real programs

In exam answers, composition should be explained through actual programming structures. The most common are **procedures**, **functions**, **modules**, and sometimes **classes** or compound data structures.

> **Key Term: module**
> A self-contained part of a program with a clear purpose and a defined interface to the rest of the system.

Suppose you are designing a card game. The full problem is too large to code in one block without errors. You might decompose it into:

- create deck
- shuffle deck
- deal cards
- calculate score
- display hand
- determine winner

Composition means combining these subroutines into the full game flow. The main program might do this:

```txt
deck ← CreateDeck()
ShuffleDeck(deck)
playerHand ← DealCards(deck, 5)
computerHand ← DealCards(deck, 5)
playerScore ← CalculateScore(playerHand)
computerScore ← CalculateScore(computerHand)
DisplayHand(playerHand)
DisplayWinner(playerScore, computerScore)
```

This is composition because the complete game behaviour comes from several smaller procedures and functions working together.

Notice something else: these parts only compose well if they have well-designed interfaces.

> **Key Term: interface**
> The defined way one module or subroutine interacts with another, such as its name, parameters, and return value.

If `DealCards` expects a queue but `CreateDeck` returns a string, the modules will not fit together. Composition therefore depends on compatible interfaces. This is why AQA stresses modular parts with clear documented interfaces. The parts must not just exist separately; they must connect properly.

A clear interface includes:

- what input data is needed
- what output data is returned
- what the subroutine does
- any side effects, such as changing a passed data structure

For example:

```txt
FUNCTION CalculateAverage(scores : ARRAY OF INTEGER) RETURNS REAL
```

This tells another programmer what must be supplied and what will be produced. That makes composition easier because each module can be treated as a known component.

Composition also supports team programming. One programmer can write the input module, another the validation module, and another the reporting module. As long as they agree the interfaces in advance, the final program can be assembled from these separate pieces. Without agreed interfaces, the modules may not work together.

Another exam-worthy point is that composition is not only about procedures. It can also mean combining data structures into larger structures. For instance, a binary tree might be represented using separate arrays for node values, left links, and right links. These arrays together form one logical structure. The programmer uses the abstract data structure as a whole, even though internally it is built from smaller components.

A queue can also be composed from:

- an array to store items
- a front pointer
- a rear pointer
- perhaps a count variable

These separate pieces together create the behaviour of the queue.

> **Key Term: modularity**
> Organising a program into separate, manageable parts that each have a clear role.

Modularity is not identical to composition, but it makes composition possible. If code is modular, the parts are easier to combine, test, replace, and reuse.

### Composition, abstraction, and clear interfaces

A very common mistake is to confuse composition with abstraction. They often appear in the same topic area, but they describe different problem-solving actions.

> **Key Term: abstraction**
> Removing unnecessary detail so that attention is focused only on the features needed to solve the problem.

Decomposition asks: “What smaller problems make up this large problem?”

Abstraction asks: “What details can I ignore?”

Composition asks: “How do I combine the finished parts into one solution?”

That distinction is worth learning exactly, because exam questions often target it.

Take a satnav system. A programmer does not need to model every detail of real roads, weather, buildings, and driver emotion. Ignoring irrelevant detail is abstraction. Splitting the satnav into map loading, route calculation, location tracking, and voice instructions is decomposition. Joining those modules into one working navigation app is composition.

These ideas often work together in a chain:

1. Use abstraction to remove irrelevant details
2. Use decomposition to split the reduced problem into sub-problems
3. Solve each sub-problem
4. Use composition to combine the sub-solutions

That is why composition fits naturally into a systematic approach to problem solving.

Here is a worked design example.

Scenario: Write a program for a cinema booking system.

A sensible decomposition might be:

- display films
- choose showing
- choose seats
- calculate total price
- process payment
- print confirmation

Now think about composition. The main control structure may be:

```txt
chosenFilm ← SelectFilm()
chosenShowing ← SelectShowing(chosenFilm)
selectedSeats ← ChooseSeats(chosenShowing)
totalCost ← CalculatePrice(selectedSeats, chosenShowing)
paymentOK ← ProcessPayment(totalCost)

IF paymentOK = TRUE THEN
    PrintConfirmation(chosenFilm, chosenShowing, selectedSeats, totalCost)
ELSE
    DisplayPaymentFailed()
ENDIF
```

Why is this a good example of composition?

- Each task is handled by a separate routine
- Data flows from one stage to the next
- The complete booking process emerges from combining the smaller routines
- Each routine can be tested on its own before the whole system is integrated

That last point is one of the strongest exam benefits.

> **Test Tip:** When asked why decomposition and composition are useful, go beyond “easier to code”. Better points include independent testing, easier debugging, maintenance, reuse, team development, and clearer program structure.

Students also need to understand why composition can fail. Problems appear when:

- interfaces are unclear
- modules depend on global variables
- one module does too many unrelated jobs
- data formats are inconsistent
- modules are tested separately but not integrated properly

For example, a `CalculatePrice` function may return an integer number of pounds, but `ProcessPayment` expects a real value in pence. Individually both modules may work, but when composed, the program gives incorrect results. This shows that composition is not automatic. Good design is needed so the parts fit together.

Another issue is excessive dependence between modules. If every procedure directly changes shared global data, it becomes harder to understand how one part affects another. Clear parameters and return values usually make composition cleaner because interactions are explicit.

This is why structured programming encourages independent subroutines. A subroutine should perform one clear job and interact with the rest of the program in a controlled way. That improves composition because each unit behaves predictably.

### How to answer exam questions on composition

Composition is usually tested through command words such as define, describe, explain, compare, distinguish, or apply. The wording matters.

If asked to **define composition**, give a short precise definition:
“Composition is combining smaller program components or sub-solutions to form a complete solution.”

If asked to **compare composition with decomposition**, make the contrast explicit:
“Decomposition breaks the original problem into smaller sub-problems. Composition combines the resulting procedures or modules back into the finished system.”

If asked to **apply** the idea, you must name sensible sub-problems and show how they link. A generic answer such as “split into modules” is too vague. You should refer to likely modules in the scenario and explain their interaction.

For example, in a timetable system, strong applied sub-problems might include:

- input teacher availability
- input room availability
- assign class groups
- detect clashes
- produce timetable output

Composition would then be described as combining these modules so the finished program produces a valid timetable from the inputs.

Here is a compact exam-style response:

Question: Explain how composition could be used in the design of a library management system.

Strong answer:
The system can first be broken into smaller tasks such as searching for a book, issuing a loan, returning a book, calculating overdue fines, and updating stock records. Composition is then used to combine these separate procedures into the complete library system. For example, issuing a loan may call routines to check borrower status, confirm book availability, update the database, and print a receipt. This makes the program modular and easier to test and maintain.

Notice the structure:

- identifies modules
- explains combination
- gives a concrete example
- links to benefits

Common student errors include:

- defining decomposition instead of composition
- talking only about splitting code, not combining it
- failing to mention interfaces, parameters, or outputs
- confusing composition with composition of functions in functional programming when the question is about design structure
- describing “breaking the solution into modules” instead of “breaking the problem into sub-problems”

That last distinction is subtle but useful. In AQA wording, decomposition is best described as acting on the **problem**. The design and code then follow from that analysis.

A final high-level point: composition does not remove the need for algorithmic thinking. A badly designed set of modules will still produce a poor program. Composition helps manage complexity, but the programmer must still choose correct algorithms, suitable data structures, and sensible interfaces.

## Key Point Checklist

_This article has covered the following key knowledge points:_

- Composition means combining smaller components or sub-solutions into a complete program
- Decomposition and composition are linked but opposite processes
- Decomposition breaks a complex problem into smaller sub-problems
- Composition recombines completed procedures, functions, modules, or data structures
- Composition is part of a systematic approach to problem solving
- Good composition depends on modular design and clear documented interfaces
- Interfaces include details such as subroutine names, parameters, return values, and expected behaviour
- Composition can involve both program logic and compound data structures
- Abstraction removes irrelevant detail, while composition combines finished parts
- Benefits include easier testing, debugging, maintenance, reuse, and team development
- Poor interfaces or overuse of global variables can make composition difficult
- Strong exam answers use precise terminology and applied programming examples

## Key Terms and Concepts

- composition
- decomposition
- top-down design
- module
- interface
- modularity
- abstraction


Theory of Computation - Composition