Deciding which details to keep and which to ignore

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. A library system records who borrowed a book. Which detail should it keep?

A The borrower's name

B The colour of the book's cover

2. Which statement about abstraction is correct?

A Keep every detail so nothing is missed

B Keep the details the solution needs and ignore the rest

3. A library system stores the book title but not the borrower. What is the problem?

A Too little detail, so it cannot show who has the book

B Too much detail, so the system is slow to understand

4. A library system also stores each book's weight, cover colour and the author's favourite food. What is the effect?

A Too much detail makes the problem harder to solve

B More detail always makes the solution better

5. A school timetable program is being designed. Which detail is irrelevant to it?

A The time of each lesson

B A teacher's favourite colour

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1abstraction		ARemove a detail that does not help the solution work, such as the colour of a library book
2IF detail NOT needed THEN IGNORE it		BToo much detail: colour, weight and cover art are not needed, so the problem is harder than it should be
3A library system needs the book title and the borrower to record a loan, so these details are kept		Cloan <- [bookTitle, borrowerName]
4The book's colour is irrelevant to lending, so it is left out of the record		DToo little detail: the borrower is missing, so the system cannot tell who has the book and the solution fails
5loan <- [bookTitle]		Ebook <- [title, author] // no colour
6loan <- [title, borrower, colour, weight, coverArt]		FKeeping only the details the solution needs to work and ignoring the rest

Definitions

abstraction

Fill in the Blanks

Complete each line of code by filling in the missing parts.

_____ BookTitle

Borrower _ "Mia"

INPUT BookTitle OUTPUT _________

IF DaysLate _ 0 THEN OUTPUT "Fine due" ENDIF

PROCEDURE CheckOut(Borrower, BookTitle) OUTPUT Borrower, BookTitle ____________

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A DECLARE Title : STRING

B DECLARE Borrower : STRING

C INPUT Title

D INPUT BookColour

Question 2

A INPUT Title

B INPUT Borrower

C OUTPUT Title, Colour

Question 3

A INPUT Available

B IF Available = TRUE

C OUTPUT "Can borrow"

D ENDIF

Question 4

A Fine = 0

B INPUT DaysLate

C Fine ← DaysLate * 0.5

D OUTPUT Fine

Question 5

A INPUT Distance

B INPUT Age

C Price ← Distance * 0.2

D IF Age < 16 DO

E Price ← Price / 2

F ENDIF

Answer Key

Deciding which details to keep and which to ignore

Section A: Quick Questions

A — The borrower's name

B — Keep the details the solution needs and ignore the rest

A — Too little detail, so it cannot show who has the book

A — Too much detail makes the problem harder to solve

B — A teacher's favourite colour

Section B: Match the Pairs

abstraction → Keeping only the details the solution needs to work and ignoring the rest

IF detail NOT needed THEN IGNORE it → Remove a detail that does not help the solution work, such as the colour of a library book

A library system needs the book title and the borrower to record a loan, so these details are kept → loan <- [bookTitle, borrowerName]

The book's colour is irrelevant to lending, so it is left out of the record → book <- [title, author] // no colour

loan <- [bookTitle] → Too little detail: the borrower is missing, so the system cannot tell who has the book and the solution fails

loan <- [title, borrower, colour, weight, coverArt] → Too much detail: colour, weight and cover art are not needed, so the problem is harder than it should be

Section C: Definitions

abstraction — Keep only the details the solution needs to work and ignore the rest. A library system needs the book title and borrower, not the book's colour. Too few details fails; too many makes it harder.

Section D: Fill in the Blanks

INPUT BookTitle

Borrower ← "Mia"

INPUT BookTitle
OUTPUT BookTitle

IF DaysLate > 0 THEN
  OUTPUT "Fine due"
ENDIF

PROCEDURE CheckOut(Borrower, BookTitle)
  OUTPUT Borrower, BookTitle
ENDPROCEDURE

Section E: Spot the Error

D — The library system needs the borrower, so Borrower must be input. The book's colour is an irrelevant detail, and Borrower is never given a value. It should be INPUT Borrower.

C — Colour is an irrelevant detail that was never input. The loan record needs the title and the borrower, so it should be OUTPUT Title, Borrower.

B — Whether the book is available is a relevant detail, and the program uses it in a decision. Every IF needs the keyword THEN, so it should be IF Available = TRUE THEN.

A — The fine only needs the number of days late, and the book's colour is ignored. Cambridge pseudocode uses the assignment arrow ←, so the line should be Fine ← 0.

D — The ticket price only needs the distance and the age, not the bus colour. An IF statement must use THEN, not DO. It should be IF Age < 16 THEN.