Year 7 Computing: Autumn Assessment

Hardware means the physical parts of a computer system, the pieces you can actually touch, such as the keyboard, the screen and the hard drive.

A keyboard is an input device, because it lets data go into the computer. A printer is an output device, because it takes the results out of the computer and puts them onto paper.

System software runs the computer itself. The operating system, such as Windows or Android, is the main example, and without it the computer would not work at all. Application software is installed so that the user can carry out a particular task, such as a browser for looking at web pages or a word processor for writing.

The first problem is that names like new1 tell you nothing about what is inside the file, so finding a particular piece of work later means opening one file after another until the right one appears. The second problem is that it becomes very easy to hand in the wrong file, or to save over work that was already there, because nothing on the screen distinguishes one file from another. Instead they should give every file a name that says what it is, such as year7-networks-homework, and store files in folders arranged by subject and then by topic.

The first reason is that your account is yours, so anything done while you are still logged in looks exactly as though you did it, and you would have to explain it. The second reason is that anyone who sits down at the machine can open, change or delete your work, and a whole term of work can disappear in seconds. The third reason is that they could send messages or post things using your account, which could get you into serious trouble and would be very hard to prove was not you.

A computer is extremely literal. It carries out the blocks in exactly the order they are joined together, from the top of the script downwards, and it never works out what you meant. That means putting the right blocks in the wrong order is just as wrong as using the wrong blocks. For example, if a sprite is told to move 100 steps and then turn 90 degrees it walks along one side of a square and then faces a new direction, but if the turn block is put first the sprite turns on the spot and then walks off in a completely different direction, so the finished drawing is wrong.

A variable is a named box that holds a value while the program is running, and the value inside it can be changed. The score has to change constantly during a game, going up by one every time the player collects something, so it cannot simply be written into the blocks as a fixed number. Because the value is stored under a name, the program can also read it back, for example showing it on the stage and testing whether the score has reached ten so that the game can say the player has won.

I would use a repeat block set to five, and inside it put a move 100 steps block followed by a turn 72 degrees block. Each time round the loop the sprite draws one side and then turns ready for the next one, and after five repeats the shape closes because the five turns add up to 360 degrees. The advantage of the loop is that the script is far shorter and much easier to change. If I decide to draw a hexagon instead I only have to change two numbers in one place, whereas with the blocks written out five times I would have to add another pair of blocks and edit every turn.

When the green flag is clicked, use an ask 'What colour is the sky?' and wait block, which stores what the player types in the answer box. Then use an if answer = blue then, else block. Inside the if part put say 'Correct' for two seconds, and inside the else part put say 'Try again' for two seconds. Only one of the two paths runs, so the sprite gives exactly one reply each time.

One possible cause is that the condition is wrong. If the block says repeat until lives greater than 0 rather than lives = 0, the loop will never end, because the test is the wrong way round. The other likely cause is that nothing in the game ever reduces lives, so it stays at three forever and the stopping condition is never true. To check the first, I would read the condition carefully and try it with lives set to zero by hand. To check the second, I would tick the box next to the lives variable so that it shows on the stage, then play the game and watch whether the number actually goes down when the sprite is hit. Clicking individual blocks to see what each one does is the quickest way to find the block that is missing.

An event block is a block that starts a script when something particular happens. On the button sprite I would use a when this sprite clicked block, and underneath it a broadcast start block, which sends a message that every sprite in the project can hear. On the second sprite I would use a when I receive start block, and join the movement blocks underneath it. Clicking the button therefore triggers the message, the message triggers the second script, and the two sprites work together without either one needing to know anything about the other's blocks.

First they should read the order of the blocks, because a script with the right blocks in the wrong order is one of the most common faults. Second they should check that every variable is set at the start, since a score or a timer left over from the last game causes strange behaviour the moment the green flag is clicked. Third they should look closely at every condition, because a greater than sign where a less than sign was meant makes the program do exactly the opposite of what was intended. Fourth they should check the script is attached to the sprite they think it is, and then click each block on its own and watch what happens, which shows very quickly which block is not doing its job.