A Generic Domain Model for an Imperative Programming Languages Tutor Shell Bedir Tekinerdogan Department of Computer Science University of Twente P.O. Box 217, 7500 AE Enschede, The Netherlands E-Mail:
[email protected] Jeroen J. G. van Merriënboer Hein P.M. Krammer Marcel J. Schonewille Department of Education University of Twente P.O. Box 217, 7500 AE Enschede, The Netherlands
Abstract: ITSSEL (Intelligent Tutoring Shell System for Executable Languages) is a tutoring shell system for imperative programming languages. Each generated intelligent tutoring system (ITS) in the ITSSEL system is composed of an instruction model, a domain model and a student model. In order to use the shell as a test bed for instructional experimentations the instruction model and the domain model are highly orthogonal to each other. This paper describes the design of the domain model which represents the programming knowledge to be taught. The programming knowledge is represented by abstract programming plans provided in a reusable and extensible framework. The generic problem specification language PSL is used to define problems with multiple student solutions. Problems and feedback specifications can be easily added after the ITS has been built at the application level. This provides the knowledge engineer a high level of flexibility in composing a specific course.
keywords: knowledge representation, imperative programming languages, intelligent tutoring system shell, knowledge representation, planmatching, feedback generation, object-oriented software development
1. Introduction ITSSEL (Intelligent Tutoring Shell System for Executable Languages) is a tutoring shell system for imperative programming languages. Intelligent Tutoring Systems are computer-controlled education systems in which Artificial Intelligence is applied. These systems do not only teach factual and procedural knowledge, but they also teach the student problem solving skills. This makes these systems extremely suitable for the purpose of teaching programming languages. In the ITSSEL system (Tekinerdogan & Krammer, 1995) an ITS is composed of an instantiation of the domain model class, instruction model class and a student model class. The domain model includes the knowledge to be taught. The instruction model represents the knowledge on the teaching of knowledge to the student. Finally, the student model contains the knowledge on the perception and assessment of the student’s behavior with the knowledge taught. This paper presents a generic domain model which can be used in any ITS that will be used for
1
teaching the student an imperative programming language. This generic domain model is part of the ITSSEL system that contains also a generic instruction model (Van Marcke, 1992) and a generic student model (Vassileva, 1990) for an imperative programming languages tutor. In the ITSSEL system the domain model knowledge is the knowledge of programming. The programming knowledge is represented by programming plans (Soloway, 1986; Krammer & Dijkstra, 1994). The evaluation of student solutions is based on the results of a plan matching process. The plan matching process will give a diagnosis of the student program after which the instruction model can use the diagnosis to give adequate feedback. A considerable number of ITSs that teach programming languages have been developed or are under development (McKendree, Radlinski & Atwood, 1992; Ramadhan & du Boulay, 1992; Brusilovsky, 1992). Although some of these systems have proven to be very effective in specific cases, we identified a number of important obstacles that hinder the reusability, extensibility and the flexibility of these systems. Most of the traditional systems have only a limited number of problems that they can present to the student. The system can give very effective feedback to these pre-determined problems, however, modifying these problems or adding new problems requires a lots of expertise. Sometimes the feedback for the corresponding problem is hard-coded in the system. This approach assumes that each problem is well understood and that the feedback for the problem will not change. However, even after the system has been built we may identify some student-problems for which we would wish to give adequate feedback. Our goal is to ease the addition or update of new problems and the feedback belonging to these problems. To do this we believe that the problems and the feedback should not be hard-coded with the matching algorithms at the system level, but it should also be possible to manipulate these at the application level. This means that the system engineer should build an ITS shell in which only the matching functionality with some default feedback on problems is implemented at the system level. The knowledge engineer must then be able to add or update the problems and the feedback for a specific ITS at the application level. In this way the knowledge engineer can easily develop an ITS tailored to the need of the curriculum. Another problem which we would like to address is the lack of modular composability (Meyer, 1988) of most of these systems. That is, we are not able to freely reuse or extend the components of the available ITSs to compose a different ITS. By a different ITS we mean an ITS that for example teaches another programming language, uses a different student model, instruction model, domain model or other different parts of an ITS. The need for reusability comes from the observation that many elements of intelligent tutoring systems follow common patterns. Therefore, it should be possible to exploit this commonality and avoid reinventing solutions to problems that have been encountered before. An example of bad or even no reuse of the components of an ITS are the matching algorithms which are written always from scratch if a new ITS is required. These matching algorithms try to match a pre-defined formal problem specification with the student’s program. We think that it should be possible to write abstract matching algorithms for all kind of imperative languages. The ITSSEL system is based on an object-oriented architecture (Bonar, Cunningham & Schultz, 1986) with which various ITSs for imperative programming languages can be built very easily by extending or reusing existing ITSs in the system. Also exercises and feedback can be developed very easy. Furthermore, ITSSEL provides a generic Planmatcher which can be used for diagnosing a student program in any imperative programming language. This paper is organized as follows: The next section gives the generic framework for the domain model which can be used for any imperative programming languages tutor. Section 3 gives a description of the generic matching algorithm which can be applied to match a given problem specification with any imperative programming language program. Section 4 handles about the problem specification in the ITSSEL system. It gives an indication of the problem specification language and the knowledge representation in the system. Section 5 explains the feedback generation. Finally, section 6 gives conclusions.
2
2. Generic Domain Model framework Figure 1 gives the generic framework for the domain model in the ITSSEL system. In the ITSSEL system the domain model includes the programming knowledge that must be taught to the student. Generally, a domain model contains zero or many domain elements. A domain element is defined as an entity in the domain model that is used to represent the knowledge to be taught. As illustrated in figure 1, a domain element is either a programming plan (Soloway, 1986; Krammer & Dijkstra, 1994), a task or a relation.
Figure 1. The generic domain model framework The programming plan hierarchy is typical for an imperative programming languages tutor and contains all the necessary abstract plans for representing the imperative programming language constructs. The design of such a generic programming plan framework was possible after we did a thorough domain analysis of imperative programming languages. In this way we exploited the common components of various imperative programming languages. The relation type element represents the relations between instantiations of the domain elements. These relations are generally applicable to all kind of domains. These relation classes are (Van Merriënboer & Luursema, 1995): 1. uses - indicates that another domain element uses this domain element. 2. together_with - indicates that another domain element must preferably be presented together with this domain element. 3. conflicts with - indicates that another domain element must preferably not be presented together with this domain element. 4. before - indicates that another domain element should preferably be presented before this domain element. 5. after - indicates that another domain element should preferably be presented after this domain element. The knowledge engineer must instantiate from these relation types if the establishment of the corresponding relation between the given domain elements is required. The actions of the instruction model are constrained by these relation instantiations which provide in this way robust learning elements. In the ITSSEL system, the student is given several tasks to acquire the required programming skills. A Task domain element is either a question, a problem or an explanation. Problems are generic program specifications which include instantiations of programming plans. As such, the program code of each problem that will be presented to the student can either be complete (example program), incomplete (a partial program that must be completed by the student), or absent (in which case the student has to implement the whole program).
3
The question and explanation domain elements are used for defining feedback or interaction with the student in which the student parameters will be measured. Several question element types are available in the ITSSEL system. Examples of these element types are multiple choice questions, Likert-questions, check questions, categorization questions, fill-in questions, true/false questions and complete tests which are the composition of all these question elements. Explanations consists of a hint, a strategy, an example program or a reminder.
3. Generic match algorithm In the ITSSEL system problems are defined by a problem specification language PSL which contains the necessary language constructs for imperative programming languages in a generic and intuitive way. The component which is responsible for matching a problem specification with the student’s program is called the Planmatcher. Figure 2 illustrates the matching process. A student may be taught different imperative languages (e.g. C, Pascal, Modula etc.). For each programming language X that must be taught an XPSL-parser will be needed. All these parsers (e.g. Pascal-PSL, C-PSL, Modula-PSL etc.) will translate the student program to a PSL program. The translated PSL student program will then be matched with the chosen problem from the problem database of the system. The result of the matching can be used to identify which feedback is needed for the student. This matching mechanism provides us the ability to re(use) each specified problem in the problem database to teach any imperative programming language. Additionally, the Planmatcher can be re(used) for diagnosing any imperative language X provided that an X-PSL parser is available. Note that since our emphasis is on teaching the style of programming and not the specific programming constructs, the student program must be syntactically correct before it can be submitted to the Planmatcher. This means that each student program must first be compiled by the compiler of the language it was written in. If the student program contains no errors the student program will be translated to PSL after which the matching can begin.
Figure 2: The matching process
4. Problem specification The problem specification language PSL is used by the knowledge engineer to specify the problems the student must learn. Because PSL is also meant to be used by the general Planmatcher which must be
4
orthogonal to each imperative language, PSL includes the necessary language constructs that are available in current imperative languages. These language constructs are expressions denoting programming plans. Programming plans can be generic or concrete. A concrete plan denotes one specific language construct. A generic plan is an abstraction of a set of correct plans. The concrete and generic plans together are called the ordinary plans. To enlarge the expressiveness PSL also supports the following additional shorthand operators, given the plans p and q: p* p? p+
p zero or more times p zero or one time p at least one time
OR [planlist] SET(planlist) p IN [planlist]
one of the plans in the planlist list of plans with arbitrary order. plan p is somewhere in planlist
These operators are called extended plans in the ITSSEL system. By using generic plans and the extended plans we can specify problems in PSL with multiple solutions. However, if we wish to enforce the student to use a specific language construct then we must indicate this with concrete language constructs of PSL. Consider for example the problem specification ComputeSum in figure 3, which is a formal representation of a generic imperative program that computes the sum of the numbers from one to ten.
PROBLEM ComputeSum;
Compute the sum of the list 1 to 10
DECLARE (i, sum : INTEGER);
Declare two integers called I and sum
BEGIN TEXTOUTPUTLN*;
Zero or more comments
SET [ ASSIGN(i, 0);
Initialize Loop variable I with 0
ASSIGN(sum, 0)] ; LOOP( i > 10 , [
Initialize sum with 0 Start a loop which exits if i greater than 10
ASSIGN(sum, sum+ I),
Increment sum with i
ASSIGN(i, i+1) ]);
Update condition variable
TEXTOUTPUTLN*;
Zero or more comments
OUTPUTLN(sum)
Output the sum variable
END.
Figure 3: A problem specification written in PSL If we take a close look at this problem specification we see that the knowledge engineer has just to indicate which programming plans the student must use. The program in figure 3 contains a declaration plan, loop plan, output plan etc. Note that the knowledge engineer has used both generic and concrete plans. An example of a generic plan is the plan LOOP which indicates that the user may solve the problem with any kind of loop, like a repeat loop, for loop or while loop in Pascal. An example of a concrete plan is the plan ASSIGN which can only be represented by one language construct (Pascal ‘:=‘, C ‘=‘ etc.). This problem specification also contains the extended plans SET and closure (*). The SET plan is used because the order of the initialization of the sum and i variable are not important for the final computation. The plan TEXTOUTPUTLN* means that the student may use zero or more output statements (e.g. think of the statement WriteLn of Pascal ). It is clear that this formal PSL representation has many student solutions. However, the number of student solutions can be restricted by avoiding the generic plans and/or the extended plans.
5. Feedback generation As noted before, each plan in the plan hierarchy has a corresponding language construct in PSL. Problems are instantiations of these programming plans. During the matching each problem plan will be compared with a plan in a student program solution. Initially, a problem plan will have the state NotEvaluated. After the matching process all plans in the problem specification will have one of the following states:
5
1. 2. 3. 4. 5. 6. 7. 8. 9.
Matched - which indicates that the student has used the correct plan in a correct way Mismatched - indicates that the student used a correct plan in an incorrect way Bugmatched - indicates that the incorrect student plan matched with a pre-defined buggy-plan Spurious - indicates that the student used a plan which is superfluous Missing - indicates that the student has not included this plan in the program MisplacedMatched - indicates that the student plan is at the wrong place but it matched correctly with the required problem plan. MisplacedMismatched - indicates that the student plan is at the wrong place and mismatched with the required problem plan. MisplacedBugmatched - indicates that the student plan is at the wrong place and bugmatched with the required problem plan. NotMatched - which indicates that the student used a plan which the Planmatcher could not detect as one of the previous states.
Thus, these states represent the kind of error the student made in the program for the corresponding problem plan. Figure 4 illustrates the state diagram (Rumbaugh et al., 1991) for an instantiation of a programming plan and shows the effect and order of the matching process.
Figure 4. The state diagram for an instantiation of a programming plan For each of these states, feedback is specified by default for the corresponding plan. However, the ITS shell allows the knowledge engineer to override or extend the default feedback in an easy way at the application level. Another important aspect is that each plan may have multiple buggy plans (Sack, 1988). Buggy plans are erroneous plans which are often used by the student as a consequence of a misunderstanding. By storing these buggy plans in the system, the Planmatcher will be able to check if the current student plan matches with one of the associated buggy plans. In that case, the student plan will get the state Bugmatched. Because for each buggy plan the knowledge engineer can also specify feedback, this mechanism provides us a precise diagnosis of the students misconceptions, to which the right feedback can be given. Figure 5 shows a snapshot of the ITSSEL system in which the knowledge engineer defines feedback for the problem specification ComputeSum in figure 3. As we can see in figure 5, feedback is specified by selecting a problem plan from the plan list of the problem specification. The feedback and the related buggy plans can then be saved by pressing the save button. These feedback specifications will then be used for giving adequate feedback after the diagnosis of the student’s program.
6
Figure 5. A snapshot of the feedback specification in the ITSSEL system
6. Conclusion In this paper we described a framework for a generic Domain model of the ITS in the ITSSEL system. Each domain model is composed of several domain elements which are entities to represent the domain knowledge. A domain element is either a programming plan, a relation or a task. Programming plans are classified in a reusable and extensible hierarchy of generic imperative programming plans. Problem specifications are compositions of the instantiations of these programming plans. The Planmatcher matches a given problem specification with the student’s program. The result of this matching process is a diagnosis that can be used by the instruction model to give the student adequate feedback. The Planmatcher and the defined problem specifications are generally applicable for diagnosing programs of imperative programming languages. The only requirement for the use of the Planmatcher is that we have to provide an X-PSL parser for each imperative language X we wish to teach. The problem specification language PSL we used is highly expressive, precise and close to the mental model. With the ITSSEL system it is indeed possible to generate different ITSs which teach different imperative programming languages. The exercises and feedback can be easily specified and they can even be reused for other ITSs. This promotes the modular composability of the system. Additionally, the most important component of the domain model, the Planmatcher, is language-independent and can be used for all the generated ITSs.
7
Acknowledgments This research is financed by the Ministry of Education within the framework of the so-called “Technology Renewal Project” of the Dutch technical universities.
References 1.
2.
3. 4. 5.
6.
7. 8.
9. 10. 11. 12.
13.
14. 15.
16.
Bonar, J., Cunningham, R., & Schultz, J. (1986). An object-oriented architecture for intelligent tutoring systems, Proceedings of the First Object-Oriented Programming Systems, Languages and Applications. pp. 296-276. Brusilovsky, P. L. (1993). Towards an intelligent environment for learning introductory programming. In: E. Lemut, B. du Boulay & G. Dettori (Eds.), Cognitive Models and Intelligent Environments for Learning Programming (pp. 114-125). Berlin: Springer Verlag. Bosch, J., & Krammer., H. P. M. (1994). CAVI user guide. Memorandum University of Twente, Dept. of Computer Science & Dept. of Edcuation. Johnson, W. L. (1990). Understanding and debugging novice programs. Journal of Artificial Intelligence, 42, 51-99. Krammer, H. P. M., & Dijkstra, S. (1994). Plan-based sequencing of problems for introductory programming. In: R.D. Tennyson (Ed.), Automating instructional design, development and delivery (chapter 12). Berlin: Springer Verlag. McKendree, J., Radlinski, B., & M. E. Atwood. (1992). The Grace Tutor: A Qualified Success. Proceedings of the Second International Intelligent Tutoring System Conference (pp. 677-684), Montreal, Canada. Meyer, B. (1988). Object-oriented software construction, Prentice Hall Ramadhan, H., & B. du Boulay. (1993). Programming environments for novices. In: E. Lemut, B. du Boulay & G. Dettori (Eds.), Cognitive Models and Intelligent Tutoring Environments for Learning Programming (pp. 125-135). Berlin: Springer Verlag. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorenson . W. (1991). Object-oriented modeling and design, Prentice-Hall. Sack, W. (1988). Finding errors by overlooking them. Proceedings of the Conference on Intelligent Tutoring Systems, Montreal, Canada. Soloway, E. (1986). Learning to program is learning to construct mechanisms and explanations. Communications of the ACM, 29(9), pp. 850-858. Tekinerdogan, B., & Krammer, H. P. M. (1995). Design of a modular composable tutoring shell for imperative programming languages. Submitted to International Conference on Computers in Education ‘95, Singapore. Tekinerdogan, B., Krammer, H. P. M., & van Merriënboer, J. J. G. (1995). Design of a general planmatcher for diagnosing student programs [Summary]. Proceedings of the Seventh World Conference on Artificial Intelligence in Education, Washington D.C., USA. Van Marcke, K. (1992). Instructional expertise. Proceedings of the Second International Intelligent Tutoring System Conference (pp. 234-244), Montreal, Canada. Van Merriënboer, J.J.G., & Luursema, J.J. (1995). Implementing instructional models in computerbased learning environments: A case study in problem selection. In T.T. Liao (Ed.), Advanced educational technology: Research issues and future potential (NATO ASI Series F). Berlin: Springer Verlag. Vassileva, J. (1990), A classification and synthesis of student modelling techniques in intelligent computer-assisted instruction. Proceedings ICCAL ‘90, Hagen (Germany), pp. 202-213.
8
