We have introduced each role in lectures when it is encountered for the first time by presenting a short, informal definition of the role, e.g., "a variable is said to be a fixed value if its value never changes", and mentioned special cases covered by the exact definition of the role, e.g., that there may be several alternative assignment statements and that there may be an immediate correction of the original value. It is essential that the distinctive features of the new role (as compared to the already known roles) are made clear. Later, whenever a role reappears in some example program the teacher has repeated the informal definition and explained the life cycle of the variable.
In example programs, we have used the convention that the declaration of each variable is followed by a comment stating the role of the variable and its use in the program. For example (in Java):
public class Dog {
String name; // Fixed value: dog's name
int age; // Stepper: current age in years
public Dog (String n) {
name = n;
age = 0;
}
public void birthday () {
age++;
}
}
Moreover, we have given students a short printed list describing all roles in an informal way:
(Versions with old role sets can be found here.)
We have also described to students how roles can be used in program design. For example, consider the task of writing a program to convert temperatures between various scales (Celsius, Kelvin, Fahrenheit). [This example is based on real life: one fourth-year student told how he had had problems in getting a novice even to begin writing the program: the novice just couldn't know where to start. The problem was something like "Do I need a variable or a loop?" Neither of these students had learned to utilize roles.]
The starting point for design may be the selection of variables based on the task description. In this case, the user input consists of a temperature value and its unit. Input is normally (i.e., as taught in lectures) stored in a fixed value (if only a single value is read) or a most-recent holder; so we'll need one of those for both inputs; let's call them temperature and unit. [The variable declaration is equal for both a fixed value and a most-recent holder; the difference is that a most-recent holder induces the use of a loop because in every program seen in lectures a most-recent holder has occurred within a loop.]
The program has to produce the same temperature in several units so that they can be printed as output. The role temporary fits that purpose, so we will need one for each of them. Let's call them temperatureInCelsius, temperatureInKelvin, and temperatureInFahrenheit.
So a first sketch of the program (in C) looks now something like:
#include <stdio.h>
?type? temperature; /* fixed value: input temperature */
?type? unit; /* fixed value: input unit */
?type? temperatureInCelsius; /* temporary: input in C */
?type? temperatureInKelvin; /* temporary: input in K */
?type? temperatureInFahrenheit; /* temporary: input in F */
int main ()
{
?input temperature?
?input unit?
temperatureInCelsius = ?calculation based on temperature?
temperatureInKelvin = ?calculation based on temperature?
temperatureInFahrenheit = ?calculation based on temperature?
?output all temperatures?
exit(0);
}
This program uses two roles (fixed value or most-recent holder; and temporary) and their prototypical uses in programs. It does not say what should be written between question marks but it gives some hints on the kind of things there might be. The next step is to fill these missing parts before the program can be compiled and run.
It should be noted that this method necessarily produce an optimal program. The most important issue is the fact that now we can give students a concrete way to proceed from a problem statement to start writing the program.
Roles are cognitive concepts and different persons may have different interpretations of roles. It is therefore important that students' role assignments are not criticized -- unless they are clearly wrong, e.g., stating that a stepper is a temporary. Students rarely expose their solutions voluntarily; so we have asked students about their role assignments, and explained appropriate alternatives even if no suggestions are presented that, e.g., "somebody might have considered this temporary to be a most-recent holder". The most important issue is not to be able to assign roles unambiguously but to let the roles help in writing and understanding programs.
PlanAni utilizes role-based animation of various operations like assignment and comparison. For example, consider the comparison "some_variable > 0". In case (a) below, the variable is a most-recent holder and the comparison just checks whether the value is in the allowed range. In the visualization, the set of possible values emerges, allowed values with a green background and disallowed values with red. The arrow that points to that part of the values where the variable lays, appears as green or red depending on the values it points to. In case (b), the variable is a stepper and, again, the allowed and disallowed values are colored. However, these values are now part of the variable visualization and no new values do appear.
PlanAni is freely available. It is implemented using Tcl/Tk and it has been tested both on Linux/Unix and Windows NT (and should run without problems on Mac, too, but this has not been tested.)
In the current implementation, animation commands must be authored by hand for each program to be animated. Typically five animation lines are required for each line in the animated program. There are ready-made animations for several Java, C, Python, and Pascal programs -- four that are suitable for teaching elementary programming, and one that demonstrates the animation of various roles. These programs can be easily turned into, e.g., C++, and new programs can be added with a modest effort.
We have used PlanAni in the following way: In each session, the teacher first presents the animation step by step using her computer and a video projector. As each role appear for the first time, she explains what the role image is and how it tries to visualize the most important properties of the role. Students are then instructed to run the animation using given data, carefully selected by the teacher. Thereafter, students animate the program with their own input data. Finally, the teacher discusses with students about complicated issues or other problems students have had in understanding the program. All the time, students are encouraged to proceed slowly with the animation and predict the effect of the next statement on the values of variables and other aspects of the program.
Novices have little grounds to interpret visualizations in the anticipated way. It is therefore possible that seeing past and future values in role images may give students the impression that all these values are available and could be accessed using some special syntax. Therefore, the teacher has stressed constantly during animation sessions that only one of the values does exist in reality and that the others exist for visualization purposes only.
Here is a role-based game that is based on the idea of the Black Jack card play, but here the values drawn from a card deck are further manipulated with variables of various roles. We have guided students to play the game during lab sessions just to get a break; thus they have elaborated their role knowledge practically with no extra time.
Independent researchers have produced other tools for the inclusion of roles in introductory programming education:
Acknowledgments: Marja Kuittinen and Elina Räisänen have provided valuable information about their experiences in using roles in introductory teaching.
Last updated: September 17, 2014
