Introduce students to the question ‘How does a supermarket checkout work?’. Ask them to discuss what actually happens when groceries are taken to the checkout.
After their initial discussion, ask ‘What are the key parts of the system?’ Guide discussion to help them identify parts that they may have noticed. Write down key terms and parts of the system that students identify; for example, scanner, items, money, barcodes, cash register, cashier, conveyer belt, credit card reader, scales, database and central computer (data storage). Using these terms, talk about the possible interactions between parts of the system. On a whiteboard connect key parts of the system with arrows. Build up from a starting point of an item and the interactions that follow.
You may find it useful to relate discussion of barcodes to the school library and how this works. Scan a few items in the library and look for similarities between systems.
Explain to students that they are going to investigate the way a checkout works and design their own computer program to simulate the process. They will look at how barcodes are used to identify an item using a unique code of digits and how the information related to this item is stored, modified and retrieved.
Provide students in groups with a range of supermarket items containing barcodes or images of barcodes. (See handout one.)
What do you notice about a barcode? The bars or stripes are made up of lines of different thickness and associated digits (0–9). Look for patterns between different items. Why might we have the digits as well as bars? (The digits enable humans to read the 12-digit code if the reader cannot scan the barcode or there is an error.)
Time each group to determine how long it takes them to sort the items in order using the bar code numbers. Jot down in seconds how long it takes each group. Discuss that computers can sort information extremely fast. Make the comparison to how fast a computer is able to locate an item from a list of 10,000 store items in a few milliseconds. It uses an algorithm called a binary search which halves the amount of data being searched each time until it locates the exact match. It also does a check on that barcode to ensure the code is correct – all within a few milliseconds. Compare that to how long it took to sort 5–6 items in order
Additional scaffolding: For students who find this task/concept challenging or need more examples, you could extend this activity by creating a price list. The student would have to match the bar code to the price list and check that the item with the barcode is as described. As suggested below, you could roleplay this with a "customer" choosing items and a "cashier" who has to look up items on the price list.
Ask students to imagine they are at the checkout with their items. What sequence of steps might a computer use to work out the cost of the items at the checkout?
Students could role-play the scanning of items and work through the process and record what they would expect to see on screen and how to progress to the next item. These questions may help students during the process:
Students have a go at creating an algorithm to show how a self-checkout works. Invite students to draw a flowchart by hand or using software.This example of a flowchart was created using Gliffy software. (Sign in for free for limited features.) Other software includes Microsoft Visio.
Alternatively, students can write their sequence of steps in what is called ‘pseudo code’.
The following is an example of pseudo code:
Program for What is the cost of the items at the checkout?
OUTPUT - Set counter to 0. (Total item cost)
OUTPUT - Ask: What is your item?
OUTPUT - Say: Enter bar code.
INPUT - User types in barcode.
IF answer = barcode THEN
Output: Display item name and item cost.
Add item cost to ‘Total item cost’.
OUTPUT - Are there any more items?
IF answer =Yes THEN continue to loop.
IF answer =No THEN.
OUTPUT - Ask: Please pay.
OUTPUT - Display total item cost.
CLEAR stored data
Refer to their algorithm when creating the computer program. For a programming language that uses blocks of code use Scratch, Snap, Tynker or another similar program.
Establish the mindset in which you see the importance of continually adding to and retesting the code, to look at the output onscreen and check if it works as intended. You could also set up the protocol that each person in the group programs for 5 minutes at a time.
It is expected the computer programs for this task will include the following components:
The ‘Ask’ block of code requires user input; in this case a 12-digit barcode. If that data is entered correctly, then a series of other actions occur with the output displaying onscreen.
Examples of repeat blocks in Scratch.
If answer is ‘yes’ then the program finalises with several actions.
Spend time with students talking about the functional requirements (outputs and calculations) of what they want their program to do. For example do users enter data or do they select from buttons on screen? Consider how the program will keep a tally of the item costs and how this is to be stored in the program.
A computer program for this task, made in Scratch, may have similar functions to Checkout, an example of a Scratch program. For students who want to add a barcode scanner, refer to this Scratch example as a guide.
Students could search for a Scratch program that features a barcode scanner and remix the project or borrow some of the code and sprites to use in their own project.
Note the examples are based around Scratch. Similar programming blocks are available in Tynker and Snap.
A useful approach to iron out bugs and review how well the interface works is to provide the completed program to be ‘road tested’ by someone else.
The person or group doing the ‘testing’ is observed working their way through the program, noting:
The observer can take notes and then modify the program (if time permits) or list the changes they would make if they were to do things differently next time.
Give each group an opportunity to share their program with the class. Students explain their choice of coding blocks and the intended onscreen output.
They compare their algorithm with the final product and talk about how some parts of the sequence may differ and why.
You may decide to talk about limitations for example: