isbn9789526046266

Given content means that the learner engages with a visualization of software that they have not
produced themselves and whose behavior they do not significantly affect. Examples: a teacher-given
example program, a program chosen from a selection of predefined examples in an SV tool’s library.
Own cases is defined as above, except that the learner can choose inputs or other parameters that
significantly affect what the target software does. Example: choosing a data set for an algorithm, entering
inputs that affect loop termination during a program visualization that illustrates control flow. Merely
typing in some relatively arbitrary input does not count as own cases.
Modified content means that the learner engages with a visualization of given software which they have
already modified themselves or may modify while using the visualization.
Own content means that the learner engages with a visualization of software that they wrote themselves.
A note on the 2DET
I have introduced the 2DET primarily to help me produce a nuanced and yet succinct and systematic
description of the learning activities supported by different program visualization systems. In this chapter,
I have used the taxonomy only as a classification tool for structuring my review of program visualization
systems. I feel that it allows a clearer expression of modes of visualization use than the OET or the EET.
I will further use the 2DET to describe the functionality of our own PV system in Part IV.
The 2DET could be used in the future in research that tests hypotheses about the role of engagement
in software visualization, and could serve as a basis for a wider and more detailed review of software
visualization in programming education. Such initiatives may establish how useful the taxonomy is in
general, but are beyond the scope of my present work. That said, I do expect that both kinds of
engagement highlighted by the two dimensions of the 2DET can help bring about the “purposeful perusal”
of program visualizations that Petre called for (p. 144 above).
In the end, perhaps it matters less which classification system you use than how you engage with the
one you do use.
11.3 Many existing systems teach about program dynamics
This section describes a number of program visualization tools for introductory programming education, as
delimited in Section 11.1 above. A summary of the tools appears in Tables 11.5, which gives an overview
of each system, and 11.6, which goes into more detail on the systems’ visualization and modes of user
interaction. The preceding Table 11.4 provides a legend to the other two tables.
11.3.1 Regular visual debuggers are not quite enough
Tools that reflect code-level aspects of program behavior, showing execution proceeding
statement by statement and visualizing the stack frame and the contents of variables [. . . ] are
sometimes called visual debuggers, since they are directed more toward program development
rather than understanding program behavior. (Pears et al., 2007, p. 209)
Programming experts – and novices, though not as often as many programming teachers would like –
use debugging software such as that shown in Figure 11.4 to find defects in programs and to become
familiar with the behavior of complex software. These tools are not particularly education-oriented or
beginner-friendly, but can still be useful in teaching (see, e.g., Cross et al., 2002) and may be integrated
into otherwise beginner-friendly environments such as the BlueJ IDE (Kölling, 2008).
Typical visual debuggers have significant limitations from the point of view of learning programming
fundamentals. They generally step through code only at the statement level, leaving most of the
educationally interesting dynamics of expression evaluation implicit. The visualization and user interface
controls of a ‘regular visual debugger’ are geared towards programming-in-the-large, not towards
explicating programming concepts and principles such as assignment, function calls, parameter passing,
and references, all of which the user is assumed to understand already. Only information essential for
an expert programmer is shown, with the goal of helping the programmer to find interesting (defective)
stages of execution in as few steps as possible while ignoring as many details as possible. The target
151