A Reified Interface for a Tutor on Program Debugging Amruth N Kumar Ramapo College of New Jersey, Mahwah, NJ 07430, USA amruth@ramapo.edu Abstract In this paper, we will present two user interfaces we developed for a tutor on debugging programs. The second interface is reified with respect to the first, and is hence, better at capturing student misconceptions and promoting the development of an accurate mental model in the learner. We will discuss the rationale behind the interface, its significance, and its impact on the maintenance of the student model. We will also describe the design and implementation of the reified interface. 1. Introduction We have been developing an intelligent tutoring system to help students learn C++ programming by solving problems on specific constructs in the language. For each problem, the tutor presents a program involving the construct, and provides answering options corresponding to possible errors in the program. The learner may select one or more errors in the program before soliciting feedback. The tutor provides demand feedback, and explains the errors that may be present in the code. The tutor maintains a cognitive model of the student that includes scores for each type of error - how many problems the student solved correctly, incorrectly, and partially for problems involving that type of error. This overlay model is used to sequence problems in the tutor. To date, our tutoring system covers variables, scope, pointers [6], dynamic allocation [5], for loops, nested selection statements, function calls, and classes in C++ [3]. Empirical evaluation of the tutor indicates that it helps improve student learning [4]. Figure 1 shows a snapshot of the first interface provided by the tutor. Learners study the code presented in the left panel, and identify the errors in the code by checking the boxes in the top-right panel. Learners may select more than one error for a given program. Students have found it easy to use this interface. We have tested this interface over several semesters, multiple tutors and multiple sections of courses. We recently revised the user interface. In the next section, we will discuss the new interface, and how it is reified [1] with respect to the old one. We will discuss the rationale behind the interface, and its significance. In Section 3, we will describe how the new interface affects the maintenance of the student model. We will describe our implementation of the interface, along with an example in Section 4. We will discuss future work in Section 5. 2. The Reified Interface In the reified interface, the learner identifies the errors in the code as follows: • The learner clicks on the line of code where (s)he believes a bug exists; • From a menu of program objects (e.g., variables, functions), the learner selects the object to which the bug applies; • From a submenu of possible reasons, the learner selects the reason why (s)he thinks the bug applies to the selected object. • After identifying all the errors in the code, the learner clicks on the “Submit” button to commit his/her answers. E.g., the learner may click on line 15 of the code, and specify that a dangling pointer error applies to the variable valuePointer, because it is being referenced before it is initialized. The interface permits the user to unselect an error, and select more than one error in a program. For each line, the interface lists only the program objects involved in that line of code. Therefore, the interface is context- sensitive, and may be said to scaffold learning by presenting only the relevant errors. Please see Figure 2 for a snapshot of the tutor with the new interface. This interface is reified with respect to the earlier interface because it not only expects the user to identify the error, but also the line of code and the program object to which that error applies: • A program object may enter an error state only after a certain operation, e.g., a pointer pointing to another variable may become a dangling pointer only after the variable to which it points goes out of scope.