Computational Thinking and Problem Solving

What you'll learn

This revision guide covers the fundamental computational thinking skills you need for WJEC GCSE Computer Science. You'll master how to break down complex problems, identify patterns, create algorithms, and represent solutions effectively. These skills underpin programming, systems analysis, and every aspect of computer science at GCSE level.

Key terms and definitions

Decomposition — breaking down a complex problem into smaller, more manageable sub-problems that are easier to solve.

Abstraction — removing unnecessary detail from a problem to focus on the essential information needed to solve it.

Pattern recognition — identifying similarities or patterns among problems or within a problem to help predict outcomes or reuse solutions.

Algorithmic thinking — developing a step-by-step solution to a problem that can be implemented as a program or followed as a procedure.

Algorithm — a precise sequence of instructions or steps to solve a problem or complete a task.

Pseudocode — a structured, plain-English representation of an algorithm that uses programming constructs without strict syntax rules.

Flowchart — a diagrammatic representation of an algorithm using standardised symbols connected by arrows showing the flow of control.

Generalisation — adapting a solution to one problem so it can solve a wider category of similar problems.

Core concepts

Decomposition

Decomposition involves systematically breaking down complex problems into smaller parts. Each sub-problem can be solved independently, making the overall task more manageable.

When to use decomposition:

• Large software projects requiring multiple programmers
• Complex systems where different components interact
• Problems that seem overwhelming when viewed as a whole

Example application: Creating a school library system requires decomposition into:

• User login and authentication
• Book catalogue database
• Borrowing and returns management
• Overdue book tracking
• Report generation

Each sub-problem can be tackled separately by different team members, then integrated into the complete system.

Benefits of decomposition:

• Easier to identify and fix errors in smaller sections
• Multiple programmers can work simultaneously on different parts
• Sub-solutions can be tested independently
• Components can be reused in other projects

Abstraction

Abstraction simplifies problems by filtering out unnecessary information and focusing only on relevant details. Different levels of abstraction are appropriate for different audiences and purposes.

Types of abstraction:

Representational abstraction — using symbols or models to represent real-world entities (e.g., using a variable studentAge to represent a student's age in years).

Data abstraction — hiding the specific details of how data is stored and only showing what's needed (e.g., using a function getStudentName(studentID) without needing to know how student records are structured).

Procedural abstraction — identifying common sequences of operations and representing them as a single procedure or function.

Example: When designing a sat-nav system, abstraction means:

• Representing roads as lines (not including surface material, width variations, or kerb details)
• Showing only relevant landmarks (not every building)
• Displaying simplified route instructions (not every micro-adjustment to the steering wheel)

Effective abstraction requires:

• Clear understanding of the problem's purpose
• Identifying which information is essential
• Removing details that don't affect the solution
• Maintaining enough detail to solve the problem correctly

Pattern recognition

Pattern recognition involves identifying similarities and trends within problems or between different problems. Recognising patterns allows you to reuse solutions and predict outcomes.

Common patterns in computational problems:

Repeated actions — tasks that need doing multiple times (solved using loops).

Similar structures — problems that share the same underlying logic (e.g., sorting names alphabetically uses the same pattern as sorting numbers numerically).

Predictable sequences — data following recognisable patterns (e.g., doubling, arithmetic sequences, factorial growth).

Benefits:

• Reduces duplication by reusing proven solutions
• Speeds up problem-solving
• Helps predict how problems will behave with different inputs
• Enables creation of general-purpose solutions

Example: Calculating total costs for multiple shopping baskets all follow the same pattern:

1. Start with total = 0
2. For each item, add (quantity × price) to total
3. Apply any discount
4. Add delivery charges
5. Output final total

This pattern can be reused for any retail scenario.

Algorithmic thinking

Algorithmic thinking means developing clear, step-by-step solutions that achieve specific goals. Algorithms must be:

• Precise — no ambiguity in instructions
• Unambiguous — each step has only one interpretation
• Finite — the algorithm must eventually complete
• Effective — it must solve the problem correctly for all valid inputs

Developing algorithms:

1. Clearly define inputs, processing requirements, and expected outputs
2. Break the problem into logical steps
3. Consider all possible scenarios (normal cases, edge cases, error conditions)
4. Verify the algorithm works through dry-running with test data
5. Refine and optimise where necessary

Key considerations:

• What data is needed as input?
• What validation is required?
• What decisions need to be made?
• What repeated actions are needed?
• What output should be produced?
• How will errors be handled?

Algorithm representation

Algorithms can be represented in multiple ways. WJEC GCSE requires familiarity with pseudocode and flowcharts.

Pseudocode

Pseudocode uses structured English with programming-like constructs. WJEC uses specific conventions:

Common pseudocode constructs:

// Input and output
INPUT variable
OUTPUT message, variable
PRINT message

// Assignment
SET variable TO value
variable ← value

// Selection
IF condition THEN
   statements
ELSE
   statements
ENDIF

// Iteration (count-controlled)
FOR counter ← start TO end
   statements
ENDFOR

// Iteration (condition-controlled)
WHILE condition
   statements
ENDWHILE

REPEAT
   statements
UNTIL condition

Pseudocode example — password validation:

INPUT password
SET validPassword TO FALSE

WHILE validPassword = FALSE
   IF LENGTH(password) >= 8 THEN
      SET validPassword TO TRUE
      OUTPUT "Password accepted"
   ELSE
      OUTPUT "Password too short - minimum 8 characters"
      INPUT password
   ENDIF
ENDWHILE

Flowcharts

Flowcharts use standardised symbols connected by arrows. You must know these symbols for WJEC exams:

Symbol	Name	Purpose
Oval/Rounded rectangle	Start/Stop	Marks the beginning or end of an algorithm
Parallelogram	Input/Output	Shows data being input or output
Rectangle	Process	Represents a calculation or action
Diamond	Decision	Shows a yes/no question or condition being tested
Arrow	Flow line	Shows the direction of flow through the algorithm

Flowchart rules:

• Flow generally runs top-to-bottom or left-to-right
• Decision boxes must have two exit paths (Yes/No or True/False)
• Every path must eventually reach a stop symbol
• Avoid crossing flow lines where possible
• Keep the layout clear and logical

Problem-solving strategies

Effective computational problem-solving follows a systematic approach:

1. Analysis

• Understand the problem fully
• Identify inputs, required outputs, and processing needed
• Consider constraints and limitations

2. Decomposition

• Break into manageable sub-problems
• Identify dependencies between sub-problems

3. Pattern recognition

• Look for similarities with previously solved problems
• Identify repeating elements within the current problem

4. Abstraction

• Remove irrelevant details
• Focus on essential information
• Create appropriate models or representations

5. Algorithm design

• Plan step-by-step solutions for each sub-problem
• Choose appropriate representation (pseudocode/flowchart)
• Consider efficiency and elegance

6. Testing and refinement

• Dry-run algorithms with test data
• Check edge cases and error scenarios
• Optimise and improve the solution

Worked examples

Example 1: Cinema ticket pricing (4 marks)

Question: A cinema charges different prices based on customer age and showing time. Tickets cost £12 for adults (16+) and £8 for children. Evening showings (after 18:00) cost £3 extra regardless of age. Design an algorithm using pseudocode that inputs customer age and showing time, then calculates and outputs the correct ticket price.

Model answer:

INPUT age
INPUT showingTime
SET price TO 0

IF age >= 16 THEN
   SET price TO 12
ELSE
   SET price TO 8
ENDIF

IF showingTime >= 1800 THEN
   SET price TO price + 3
ENDIF

OUTPUT price

Mark scheme guidance:

• 1 mark: Appropriate input of age and time
• 1 mark: Correct selection for age category with appropriate threshold (16)
• 1 mark: Correct selection for evening showing with appropriate threshold (1800/18:00)
• 1 mark: Correct output of calculated price

Example 2: Flowchart interpretation (3 marks)

Question: A student creates a flowchart to validate a test score. Describe what happens when the input value is: a) 75 b) 105 c) -10

[Flowchart shows: Start → Input score → Decision "score >= 0 AND score <= 100?" → If Yes: Output "Valid" → Stop; If No: Output "Invalid" → Stop]

Model answer:

a) The condition evaluates to TRUE (75 is between 0 and 100), so "Valid" is output and the algorithm stops. (1 mark)

b) The condition evaluates to FALSE (105 is greater than 100), so "Invalid" is output and the algorithm stops. (1 mark)

c) The condition evaluates to FALSE (-10 is less than 0), so "Invalid" is output and the algorithm stops. (1 mark)

Mark scheme guidance: Award marks for correctly identifying the condition result AND the corresponding output for each value.

Example 3: Decomposition application (5 marks)

Question: A school wants a system to manage student attendance. Explain how decomposition would help in developing this system and identify four sub-problems that the system could be broken down into.

Model answer:

Decomposition would help by breaking the complex attendance system into smaller, independent parts that are easier to design, program, and test (1 mark). Different programmers could work on different components simultaneously, speeding up development (1 mark).

Four sub-problems:

1. Recording daily attendance for each class/registration group (1 mark)
2. Generating reports for individual students showing attendance patterns (1 mark)
3. Identifying and alerting staff about students with poor attendance (1 mark)
4. Calculating attendance percentages and statistics (acceptable alternative sub-problem for 1 mark)

Mark scheme guidance:

• Up to 2 marks for explaining benefits of decomposition
• Up to 3 marks for identifying appropriate sub-problems (1 mark each, maximum 3)
• Accept any reasonable sub-problems relevant to attendance management

Common mistakes and how to avoid them

Confusing abstraction with decomposition

• Decomposition = breaking into parts; abstraction = removing unnecessary detail
• Remember: decomposition is about structure, abstraction is about simplification
• Use both together: decompose first, then apply abstraction to each part

Incomplete algorithms

• Always include clear START/INPUT, processing steps, and OUTPUT/STOP
• Check your algorithm handles all possible inputs, including edge cases
• Verify every path through a flowchart reaches a stop symbol

Ambiguous pseudocode

• Be precise with conditions (use >=, <=, =, NOT, AND, OR correctly)
• Make assignments clear: use SET or ← consistently
• Don't mix programming language syntax (like Python or JavaScript) with pseudocode conventions

Poor flowchart technique

• Decision diamonds must have exactly two exits (usually Yes/No or True/False)
• Label all arrows leaving decision boxes
• Don't use process boxes for decisions or decision boxes for processes
• Ensure flow lines don't cross unnecessarily

Overlooking validation and error handling

• Real algorithms must handle invalid inputs
• Include checks for boundary values (e.g., age must be > 0)
• Consider what happens with unexpected data types

Not testing algorithms thoroughly

• Dry-run with normal, boundary, and invalid test data
• Check the algorithm works for minimum and maximum values
• Verify calculations are correct at each step

Exam technique for "Computational Thinking and Problem Solving"

Responding to command words:

• Describe — give characteristics or features (2-3 marks usually expect multiple points)
• Explain — give reasons why/how something works (must include justification for marks)
• Design/Write — create a complete algorithm (needs correct syntax and structure)
• Complete — fill gaps in given algorithms (match the style/convention already used)

Answer structure for algorithm questions:

• Use the format specified (pseudocode or flowchart)
• Follow WJEC pseudocode conventions shown on the specification
• For flowcharts, draw symbols large enough to write inside clearly
• Show all steps including inputs and outputs

Maximising marks:

• In explanation questions, link computational thinking concepts to specific benefits (e.g., "decomposition allows parallel development")
• For algorithm design, spend 30 seconds planning before writing
• Check your algorithm covers all scenarios mentioned in the question
• Use variable names that reflect their purpose (e.g., totalPrice not x)

Quick revision summary

Computational thinking combines four key approaches: decomposition breaks problems into smaller parts; abstraction removes unnecessary detail; pattern recognition identifies similarities; algorithmic thinking creates step-by-step solutions. Represent algorithms using pseudocode (structured English with programming constructs) or flowcharts (standardised symbols showing flow). Always test solutions with normal, boundary, and invalid data. Apply all four thinking skills together to solve complex problems systematically. Master the standard conventions for both representation methods to score full marks in design questions.