Approach – Tracing to Understand the Notional Machine

Summary of Approach

The process a computer goes through when executing a section of code is manually stepped through by the learner in order to understand how it will work and what the expected output should be.

Keypoints

• Just showing a visualisation of a piece of code or an algorithm doesn’t appear to improve learners depth of understanding.
• Using a traditional trace table approach still means many aspects of the program execution have to be kept in working memory. This is difficult for most beginners and particularly for learners with a more limited working memory.
• Annotation on, and next to, the code provides a visual guide of what actually happens when it executes. This makes these abstract concepts and hidden mechanisms visible and therefore easier to think and reason about.
• There is evidence to suggest that those learners who cannot trace code accurately find explaining and writing code extremely difficult. Explicitly developing this skill may contribute to better code writing skills.
• It has the most impact when a new concept is introduced and when it’s used as a diagnostic tool with learners who are struggling.

Limitations

The limitations of this approach are:

• Example code will need to be carefully designed as tracing through loops should be limited to 2 or 3 repetitions.
• It will take a bit of time for the pupils to get the hang of particular way of annotating code.
• TRACS will be useful in the initial stages but pupils who already understand these code mechanisms won’t gain much from the experience. It may be better to provide them with just the code and a table or blank scratch pad area.
• More complex programs involving subroutines etc can produce complicated annotation and the complications can take away from the understanding of the processes.
• It can be carried out either on computer or on paper depending on your preference but will require some preparation time.

PLAN C Techniques

There are several techniques for annotating code to visually show the execution of the notional machine underneath. They are each designed to focus learners at a particular level of detail assuming that lower level understanding is automatic and unconscious.

At the lowest level of detail TRACS for understanding expressions is useful for annotating complex calculations and logic as well as nested function calls. Structured TRACS is focused on understanding sequence, selection and repetition constructs as well as a simple model of variables and arrays. Finally Modular TRACS focuses on how the different modules interact and the flow of data between them

Teacher Experiences of Benefits

I introduced the Mechanism Visualiser (Structured TRACS) and Code Comprehension tasks for N5 pupils this year and have been very impressed with the results. Through using TRACS my classes were exposed to multiple working programs or code blocks and this was completed in a fraction of the time it would have taken to have them write, create and test 15-20 programs. Pupils’ were able to work through them step by step and describe confidently what the machine would do.

I noticed a big increase of pupils working together to work through each activity and support each other to get all of the tasks completed. From a tracking point of view, I used the resource online and was able to look at any pupil work and keep note of the progress they were making. The task also allowed for natural extension work as more advanced pupils’ had time to create the programs from the TRACS to see that it did indeed work as they’d traced.

A. McSwan- Computing Teacher, Knox Academy

I use TRACS with S4 classes and variants of TRACS with S3 and S5 pupils. I originally found that some of my examples were too complicated to be useful in the early stages of programming. TRACS is best introduced with really simple programs such as a single IF statement. I think that as pupils learn how programs interact with memory and input/output, their are more likely to “trust” that the output of the program is entirely predictable. The use of the T/F arrows was a real breakthrough for some pupils as they realised that evaluating an expression during execution meant that a program was predictable.

I would encourage all aspects of tracing code from highlighting expressions to drawing the program path with all pupils as they learn. As pupils experience the execution of code more often, and run more programs, it is useful to start working through an example by execution and recording of the values.

The annotation in TRACS is really useful for keeping a record of understanding. It is very easy to see which pupils “get” a program simply by looking at their work. This is not something that was as obvious when they were answering questions about code.

P Liddle- Computing Principal Teacher, Bearsden Academy

Research References

• Juha Sorva (2013), Notional machines and introductory programming education, ACM Transactions on Computing Education (TOCE), v.13 n.2, p.1-31, June 2013
• Matthew Hertz, Maria Jump (2013), Trace-Based Teaching in Early Programming Courses, SIGCSE’13, March 6–9, 2013, Denver, Colorado, USA.
• Anne Venables , Grace Tan , Raymond Lister (2009), A closer look at tracing, explaining and code writing skills in the novice programmer, Proceedings of the fifth international workshop on Computing education research workshop, August 10-11, 2009, Berkeley, CA, USA
• Mike Lopez, Jacqueline Whalley, Phil Robbins and Raymond Lister (2008), Relationships Between Reading, Tracing and Writing Skills in Introductory Programming, ICER’08, September 6–7, 2008, Sydney, Australia.
• Soloway, E. (1986). Learning to program= learning to construct mechanisms and explanations. Communications of the ACM, 29(9), 850-858.
• du Boulay, B. (1986). Some Difficulties of Learning to Program. Journal of Educational Computing Research, 2(1):57–73.