Method and system for interactive computer science testing, anaylsis and feedback

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office public patent files or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
This invention relates to a method and system for computer-based testing and computer-based analysis and feedback, and in particular to methods and systems which analyze, grade and diagnostically comment upon students' free responses to computer science problems.
The background for this invention is in two fields; standardized testing and analysis and feedback systems.
In the standardized testing field, large-scale standardized testing has long depended upon the administration by paper-and-pencil of multiple-choice test items, which can be stored efficiently and objectively by modern scanning technology. Such tests have several disadvantages, including that they cannot be dynamically adjusted to the skill levels of the examinees, that they must be scored in a central location where the scoring apparatus resides, and that they depend on problems that may not adequately represent the tasks which examinees may encounter in academica and work settings.
Advances in computer technology have recently been applied to the testing field. For example, adaptive administration techniques provide a test which is dynamically tailored to the skills of the examinee and instantaneously scored in order to allow the examinee to know how he or she performed as soon as the test is concluded. Additionally, systems have been developed for automatically grading examinees' responses to "free-response" items. A free-response examination is one in which the examinee must provide an uncued response to an open-ended question, for which there are no answers from which to select (as there are in the multiple-choice format).
None of the prior art systems have been successfully applied to testing in computer science. Thus, in order to assess an individual's ability to write computer programs, school systems, colleges and businesses continue to rely on paper-and-pencil tests which are graded individually by humans. These paper-and-pencil tests are necessarily of limited value because they require the examinee to demonstrate programming skills without a computer and are expensive to score because each examineers program must be graded by a human computer science expert.
Accordingly, computer-based systems are needed that will require the examinee to develop a computer program in response to a variety of programming problems. The system should be able to present various types of free-response test items, in response to which the examinee must provide entire programs or portions thereof. The system must be able to automatically evaluate and score the student's responses.
In the field of analysis and feedback, it is desired to be able to provide automated assistance to computer science students in the form of an intelligent computer-based analysis and feedback system. Such systems should be capable of reading programs which have been entirely or partially input by the student, identifying various errors therein and providing critiques back to the student.
The errors which a desired analysis and feedback system should be able to detect include syntax, semantic, and problem-specific errors. An example of a syntax error is a missing semi-colon at the end of a program line; syntax errors such as these are detected by standard compilers available in the prior art. Semantic errors are those such as the declaration of a variable to be an integer and using it as a character in the program.
Problem-specific errors, which are most difficult to diagnose, involve errors in programming logic. For example, a student may shift data through an array in the wrong direction. This problem-specific error is not detected by computer-based analysis and feedback systems currently available.
A computer-based analysis and feedback system which can diagnose problem-specific errors in programming logic as well as semantic and syntax errors would be ideally carried out by an expert system. An expert system, which is an application of the science of artificial intelligence, is used to diagnose problems in a specialized area which here is computer science. In particular, an expert system comprises two main components: an inference engine and a knowledge base. The inference engine contains general logical rules related to the computer science language under analysis. The knowledge base is a repository of data representing expertise in the computer science language, and is used by the inference engine to solve problems presented. Knowledge bases are constructed by knowledge engineers, who utilize information obtained from an expert in computer science in order to translate the expertise into a language a computer can comprehend.
The critiques to be provided by the desired expert system serve two purposes: (1) to assist students while they are debugging their programs, and (2) to be used by teachers as evaluations of the students' work. Thus, the desired expert system should be both a debugging aid and a grader of student programs.
Further, an automated analysis and feedback system should meet certain criteria. First, teachers need to be provided with a predetermined selection of programming exercises from which they can choose for inclusion in their curricula.
Second, the system needs to contain a large amount of information about the programming exercises that teachers might assign and the many and various problems that students may have in solving the exercises.
Third, a user-friendly interface, which would simulate the personal interaction of an instructor or teaching assistant, is desired. The interface should include techniques for highlighting pertinent text in a student program on the screen and for managing windows which display the text of the feedback to the student.
Fourth and finally, an intelligent analysis and feedback system must be founded upon a machine executable language that allows articulation of knowledge of programming that will be used by the program to diagnose and explain errors. Advice for students is articulated in this knowledge base language by knowledge engineers with expertise in instructing novice programmers.
The LISP-TUTOR software, developed by Anderson et al., and the PROUST software, developed by Johnson are examples of intelligent systems found in the prior art which attempt to address some, but not all, of the four criteria mentioned above.
The PROUST software provides only feedback on residual errors in the students' program and does not interactively guide the student in actual coding. However, the PROUST program's functionality has been convincingly demonstrated on only one set of student programs written to fulfill one programming problem. (Although Johnson was able to use the PROUST program to grade student solutions for a second programming problem, it was done only off-line, and only after many special purpose mechanisms were added to the PROUST software.) PROUST software provided only minimal coverage; teachers were provided with only one programming problem that could be used in their curricula; that same programming problem was the only one that PROUST could analyze and give advice on. Further, there existed no functional interface; messages from the PROUST program were simply stored in a text file.
The LISP-TUTOR software performs an analysis of each token, or word, immediately after it is input by the student. The LISP-TUTOR has specific predetermined word patterns stored in its memory, and compares each word input by the student in order to determine if the sequence follows one of the predetermined stored patterns. That is, in the LISP-TUTOR system, the knowledge base expects to encounter a program tree structure which is top-down, depth first, and left to right. The LISP-TUTOR is capable of detecting only the first error in this order. As such, LISP-TUTOR does not analyze the entire solution, as a whole, which would be presented by the student. Because the LISP-TUTOR system never allows a student's program to contain more than one bug, students using it are never faced with the normal "multiple-bug" demands of debugging, one of which demands is the perpetual uncertainty of not knowing how many different pieces of a program contain errors. In addition, students can only attempt to solve problems on the LISP-TUTOR system which were presented by the LISP-TUTOR system.
Accordingly, an object of this invention is to provide an analysis and feedback method and system for students in computer science which will allow them to interactively develop and debug their programs through immediate, on-line diagnostic feedback.
A further object of this invention is to provide a method and system for students in computer science to be given an examination in developing and debugging programs, by means of a computer, where the computer automatically evaluates the students' responses to test questions and assigns a numerical grade thereto.
A further object of this invention is to provide such a computer science analysis and feedback and testing system which will analyze students' programs after they have been completely entered and provide an accurate analysis for a wide range of potential correct and incorrect solutions.
A still further object of this invention is to provide a computer science analysis and feedback and testing system which will detect and provide an analysis of multiple errors in a program.
SUMMARY OF THE INVENTION
In accordance with these and other objects, the present invention provides a method of administering to a student via a computer a computer science problem which provides to the student an item pool comprising a plurality of predetermined test problems to be selected by the student. The student enters a program solution in response to the selected test problem, and the program solution text is recorded and then converted, via lexing and parsing, into an abstract syntax tree. Predetermined knowledge base patterns, indicative of expected correct and incorrect methods of implementing the program solution, are compared against portions of the abstract syntax tree until the predetermined pattern matches a portion of the abstract syntax tree. A text message correlated to the predetermined pattern matched to a portion of the abstract syntax tree is then provided to the student. In this manner, the abstract syntax tree is compared, piece by piece, against the predetermined patterns stored in the knowledge base. Messages associated with the knowledge base patterns which have been matched are then all provided to the student. As a result, the student is automatically provided with information embodied in the text messages which indicates how the solution text differs from a correct response.
The comparison stage of the present invention is greatly facilitated by the ability of the predetermined knowledge base patterns to be matched against portions of the abstract syntax tree which represent certain nodes of the abstract syntax tree which are prespecified to be as close or remote as desired. That is, the pattern matching function can account for "don't cares" within the abstract syntax tree, and the matching criteria can be as expansive or specific as desired. Thus, the pattern matching capabilities of the analytic component of the present invention allow the abstract syntax tree representation of the student's solution to be compared against prespecified knowledge bases in a much more flexible fashion than has been heretofore available. The analytic component is a pattern matcher for trees; it can match parts of trees and their spatial relationships. Rather than specifying nodes to be matched exactly, the present invention can provide for "don't care" situations and expand or contract its matching criteria in accordance with the specification of the knowledge engineer so that an abstract syntax tree representation need only fall within a certain specified range to be a match.
In a further embodiment of the present invention, portions of the abstract syntax tree are compared to the predetermined knowledge base patterns in the same fashion as above. Rather than flagging a text message, a score is stored which correlates to the predetermined patterns which are matched. As a result, the student's response to the predetermined test problem is automatically evaluated and scored, the score being indicative of the correctness or incorrectness of the solution text entered by the student in response to the test problem provided. The student can optionally be given as many predetermined test questions from the item pool as desired, and the score for each response thereto can be accumulated into a total test score. The number of test questions provided to a student can be predetermined, or the number can be determined dynamically as in the computer adaptive testing environment.
The computer system of the present invention which carries out the practice analysis and feedback embodiment as well as the computer science examination embodiment includes a computer/user interface which comprises an item pool of predetermined test problems to be selected by the student, output means for presenting to the student the particular test problem selected and for providing all other communications from the rest of the system, input means for allowing the student to enter and edit the solution and for providing all other communications to the rest of the system, and editor means for capturing the student's solution text to the particular test problem selected and allowing the student to edit the same. In addition to the computer/user interface, the system has at least one knowledge base comprising a set of predetermined patterns to be compared against the abstract syntax tree representation of the student's program solution. The system includes an analytic component, which comprises means for converting, by lexing and parsing, the student's program into an abstract syntax tree and means for comparing portions of the abstract syntax tree against the predetermined patterns from the knowledge base until portions of the abstract syntax tree match the patterns. In addition, a text message correlated to the predetermined pattern matched is provided to the student via the interface output means.
The present invention includes an item pool of test problems that present the examinee or student with a programming specification and ask him or her to construct, complete, or debug (depending upon the specification) a computer program or procedure. These programs and procedures are processed by the system's lexer and parser, which places them in an abstract syntax tree form amenable to diagnostic analysis and grading. The system also includes several knowledge bases that contain correct and incorrect "patterns" for solving each problem. These patterns are matched against lexed and parsed examinee responses. The analytic component directs the analysis of the lexed and parsed student response and produces both a partial credit score to indicate the degree to which the response is correct, and a message to give the student information about exactly which portions of the response were right and which were wrong.
Finally, the system includes an example compiler, which is an off-line software tool for developing new knowledge bases. The example compiler allows interactive compiling of knowledge base patterns by converting, via lexing and parsing, a model program into an abstract syntax tree representation, querying the user to select parts of the program against which the knowledge base pattern will be used to compare, and allowing the user to specify the node relations of the knowledge base patterns in accordance with desired match criteria.
This invention provides a means for testing and providing instructional practice with problems that resemble the tasks required of novice programmers in academic and work settings--problems that require the construction, completion, or debugging of a computer program. Such tasks are very different from multiple choice computer science problems, in that multiple-choice problems do not require the generation of a working computer pregtam. This is a significant improvement because it increases the validity of assessment by presenting tasks that more closely represent those encountered by examinees on the job.

BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of the system architecture of the preferred embodiment;
FIG. 2 is a flowchart showing how a student will execute the options presented by the computer/user interface of the preferred embodiment;
FIG. 3 is a block diagram of the example compiler of the preferred embodiment;
FIG. 4 is a tree representation of a program node generated by the parser of the preferred embodiment; and
FIG. 5 is a flowchart showing how a knowledge engineer will use the example compiler.

DESCRIPTION OF THE PREFERRED EMBODIMENT
The preferred embodiment of the method and system of the present invention will be illustrated with reference to work at Educational Testing Service (ETS) which seeks to emulate the Advanced Placement Computer Science (APCS) examination in the Pascal programming language. While the preferred embodiment is designed to provide analysis of a program written in the Pascal language, it is understood that the present invention is not limited to Pascal; rather, programs written in other languages such as FORTRAN, BASIC, and C could be analyzed within the spirit and scope of this invention.
Referred to at ETS as the APCS Practice and Feedback System, the preferred embodiment employs a Disk-Operating-System (DOS) based personal computer, a color or monochrome display monitor, 640K of random access memory, and at least 2.5 megabytes of free hard disk space. Referring to the block diagram in FIG. 1, the preferred embodiment is comprised of a computer/user interface 102, an analytical component 112 for diagnostically analyzing and scoring students' solutions and for providing interactive feedback in the form of messages, and repositories of predetermined patterns called knowledge bases 120 for use by the analytical component 112.
Student Execution
Referring generally to FIGS. 1 and 2, the computer science student will carry out the preferred embodiment in the following manner. Initially, the student will select, via input means 103, a predetermined test problem from an item pool 106 accessible from the computer/user interface 102. The item pool 106 is based upon, inter alia, problems taken from prior APCS examinations which have been made publicly available. Several prototype problems were selected to emphasize important data structures taught in the APCS curriculum. These data structures are arrays, linked lists, binary trees, and records. A series of isomorphic items were written for the preferred embodiment in three formats by using these prototype problems.
Isomorphic items present the same underlying solution structure although they may be embedded in different environments. Generally, students have considerable difficulty recognizing the underlying structure of a problem. Thus, by using isomorphic items, students are able to practice identifying problems with similar underlying structures and get repeated practice with important programming constructs and concepts.
The first prompt displayed by output means 110, which in the preferred embodiment is a monitor screen, enables the student to select either a Practice Mode or a Test Mode, as shown at block 200.
In the Practice Mode, the student will enter into the input means 103 a program solution in response to the selected problem; the student can then compile and run a program based on that solution at his or her option. The student will get the same choice of problems regardless of which mode has been selected. An indication of the choice made will be displayed at the top of the next two screens.
The next screen displayed by the output means 110, as shown at block 202, prompts the student to select one of the aforementioned problem types: an array problem, a linked list problem, a record of integer problem or a binary tree problem.
After the student has selected a problem type, the next screen displayed by the output means 110 prompts the student to select the problem format, as shown at block 204. The open-ended format presents a problem in response to which the student is to write the entire solution. The completion format presents a problem, variables and part of a solution; the student is to finish the solution using the code given. The faulty solution format presents a program that includes some errors which the student must detect and correct. Any of the three problem formats can be chosen for any of the four problem types available.
After the student has selected via the input means 103 the desired problem format at block 204, a screen will appear at the output means 110 which lists the specific predetermined test problems from the item pool 106 available for the problem type and format chosen by the student. Block 206 shows by way of example a list of available predetermined test problems for the array type faulty solution format problems as provided in the preferred embodiment.
Once the student has chosen a specific test problem, an editor 108 is invoked, and a problem description appears on the screen. Illustrative of the specific test problems which the student may encounter are Examples 1 through 3 below, which depict an array type open-ended problem called "Baseball Team," a linked list completion problem called "Flavors," and an array type faulty solution problem called "Draw Card."
In Example 1, the student must completely write the program solution; the editor contains no code to start with other than the program header including the variable declarations.
EXAMPLE 1______________________________________Array Type Open-Ended Problem: Baseball Team______________________________________At the end of spring training, a baseball coach mustcut from the team all players whose batting averagesare below .200.Write a procedure called PickATeam that will dothe following:I. Accept as a parameter a list, Players, of type ListType.II. Eliminate from the list all players with batting averages below .200. Batting averages are stored as integers 0 to 1000.III. Return the team list, Players, with the remaining players in their original order.*Note: no additional array storage can be used.Use the following declarations and procedure call:PROGRAM Baseball(input,output); CONST MaxLength = 1000; TYPE NumberList = ARRAY[1..MaxLength] OF integer; ListType = RECORD Average : NumberList; Length : integer END; VAR Players : ListType;BEGIN - PickATeam(Players)END______________________________________
In Example 2, the student must determine that certain code is missing, and then must enter that missing code accordingly.
EXAMPLE 2______________________________________Linked List Completion Type Problem: Flavors______________________________________An ice cream parlor is in the process of updatingtheir inventory program. The recursive functionFlavorCount is needed to count the number of flavorsthat the parlor has in stock. Complete the functionso that it works as intended.PROGRAM Parlor(input, output); TYPE Pointer = Node; Node = RECORD NumberOrdered : integer; NextFlavor : Pointer END;VAR Flavors : Pointer; NumFlavors : integer;FUNCTION HowMany(First : Pointer) : integer;BEGIN FlavorCount := FlavorCount(First .NextFlavor) + 1END;BEGIN Num Flavors := HowMany(Flavors); Writeln(NumFlavors)END.______________________________________
In Example 3, the student must determine that certain code is incorrect, and must replace that incorrect code with correct code.
EXAMPLE 3______________________________________Array Type Faulty Solution Problem: Draw Card______________________________________A procedure has been written that will simulatedrawing a card from a deck. Once a card is drawnfrom the top of the deck, it will be placed at thebottom of the deck and the other cards will be oneposition closer to the top (Note: n is the top, 1is the bottom).Correct the procedure so that is will work asintended.PROGRAM CardGames(input, output); CONST Max = 100; TYPE CardCode = integer; DeckType = ARRAY[1..Max] OF CardCode; VAR Deck : DeckType; NumCards : integer: PROCEDURE MoveCard(VAR C : DeckType; n : integer); VAR i : integer; BEGIN FOR i := n DOWNTO 2 DO C[i] := C[i-1] END;BEGIN MoveCard(Deck, NumCards)END.______________________________________
After the code is written and/or the changes required by the problem are made in the editor 108, the student's solution is saved on a computer disk, and a diagnostic analysis of the program can then be invoked. In the diagnostic analysis, the code that has been entered is first examined for certain types of syntax errors. If there are syntax errors, the student will be provided with a message to help correct the error. If the program has no syntax errors it is then processed and analyzed to see if it properly solves the selected problem.
After the system performs the diagnostic analysis on the student's solution, the top half of the screen will display the original problem, the student's solution code (with any erroneous code highlighted), and any applicable diagnostic messages. The bottom half of the screen will display an editable copy of the student's solution code. The top half will not change and will be available as reference.
The student is then able to utilize the diagnostic messages provided by the system and edit the original solution. A second diagnostic analysis can then be invoked, with the most recent code moved to the top half of the screen with any applicable error messages. The student will get a copy of the most recently edited code on the bottom of the screen in order to make changes. This process can be repeated until a satisfactory solution is arrived at.
Examples of diagnostic messages a student may encounter are shown in Table A.
TABLE A______________________________________Sample Diagnostic Messages______________________________________Unable to find loop that checks each element of the array.The variable i used as an array subscript must be initialized above the loop and must be incremented inside the loop.The array and its size have to be passed into the procedure.Unknown method used to eliminate zero element of the array.An assignment statement to reset the length is missing/incorrect.The solution is correct.______________________________________
The student has the option of compiling a completed solution. In addition, the student can return to the menu screen that selects a problem format, block 204, by pressing the Escape key.
The system also employs several management utilities which allow the student to load a solution file from the disk (e.g., to continue work on a previously saved solution), save a file, zoom in on the highlighted text, and the like.
If the student is running in the Test Mode, the same procedure as the Practice Mode is generally followed. In Test mode, however, the student may not compile or run the solution program entered as in the Practice Mode.
In the both modes, diagnostic messages will be displayed on the screen in addition to a score, correlated to the correctness of the student's solution. After a fixed number of problems has been worked through by the student, all the scores from each problem can be totalled into one final test score in the Test Mode. Another approach to getting the final test score would be to use, instead of a fixed number of problems, a dynamic determination based upon a student's performance on items given, as in the computer adaptive testing environment.
System Architecture
The system architecture of the preferred embodiment of the present invention is shown in FIG. 1. The system comprises, at the top level, the computer/user interface 102, the analytic component 112, and the knowledge base 120.
The following is a general description of the operation of the preferred embodiment of the present invention. The computer/user interface 102, which comprises input means 103, an item pool menu 104, the item pool 106, the editor 108, and output means 110, provides all communication between the student and the analytic component 112 and knowledge base 120. The item pool 106 is a repository of predetermined test problems such as the ones illustrated in Examples 1 through 3 above. The student selects a particular test problem from the item pool 106 with reference to the item pool menu 104, which displays the selection options through the output means 110 as illustrated in blocks 100-106 of FIG. 1.
Once a particular predetermined test problem has been selected, it will be displayed to the student via the output means 110. The student will then, via the input means 103, enter and/or correct solution code in the editor 108 as appropriate. The preferred embodiment utilizes a text editor marketed by Sage Professional Software, although other configurable commercially available text editors will suffice. The student may then be able to compile the solution program in order to determine if there exist errors in syntax. After proper editing in accordance with the results of the compilation, the student's solution in text form is then passed from the editor 108 to the analytic component 112.
All processing performed by the analytic component 112, in conjunction with the knowledge base 120, is achieved in the preferred embodiment with logic programming. Logic programming is a means by which relationships between objects and data structures can be stored in a database and subsequently accessed in order to answer questions about, verify statements concerning, or make inferences from these object relationships. This is a descriptive procedure, rather than a conventional algorithmic type programming technique.
The present invention analyzes computer programs by lexing and parsing (decomposing), the program, storing results into a database, and matching portions of the patterns of the parsed student program against patterns previously loaded from the knowledge base 120 into the database. Thus, logic programming, rather than an imperative command-based sequentially executed language, is particularly suited to achieve the pattern matching of the present invention. In particular, the Prolog programming language (Arity Corp. Version 5.1) is used in the preferred embodiment, although it is contemplated that other logic programming languages could be used within the spirit and scope of the invention. For a general background, reference is made to the text Programming in Prolog, by W. F. Clocksin and C. S. Mellish, 3d Revised and Extended Edition (1987).
The analytic component 112 is comprised of a lexer 114, a parser 116, and pattern comparison means 118. The lexer 114 accepts the student program in text form from the editor 108 and outputs a list of tokens to the parser 116. The parser 116 then processes the tokens from the lexer 114 and outputs a set of associated nodes representative of the student program, which nodes are referred to collectively as an abstract syntax tree. The comparison means 118, which is an inference engine comprising a set of Prolog predicates, analyzes the abstract syntax trees and carries out a variety of pattern matching operations.
To carry out this pattern matching, the analytic component 112 calls upon the information stored in the knowledge base 120. The knowledge base 120 comprises a set of knowledge base pattern predicates 122, a set of diagnostic messages 124, and a set of scores 126. The knowledge base pattern predicates 122 correlate to portions of correct as well as various incorrect methods of solving the programming problem presented to the student. Each knowledge base pattern predicate 122 has associated with it a diagnostic message 124 and a score 126, such that when a knowledge base pattern predicate 122 is successfully matched against a part of the student's abstract syntax tree, the associated diagnostic message 124 is flagged for future display to the student via the output means 110, and the score 126 is accumulated in a register.
Analytic Component
The analytic component 112 will now be described in detail. The analytic component 112 is comprised of five files of Prolog predicates--ANALYZER.ARI, PARSER.ARI, LEXER.ARI, ENGINE.ARI, and UTILS.ARI--all of which are listed in the Source Code Appendix hereto. ANALYZER.ARI is the top-level file that consults the other four files into the Prolog database. The parser 116 is carried out by the file PARSER.ARI, which processes a list of tokens produced by the lexer 114 and outputs an abstract syntax tree into the Prolog database. The lexer 114 is carried out by the Prolog file LEXER.ARI, which is called by PARSER.ARI in order to produce the list of tokens. The comparison means 118 is carried out by the file ENGINE.ARI, which contains Prolog predicates used for analyzing, in conjunction with the knowledge base 120, the abstract syntax tree produced by the PARSER.ARI. Finally, the file UTILS.ARI contains some list and number manipulation and message formatting predicates used in the other four files of the analytic component 112.
The Prolog files of the analytic component 112 utilize a number of custom top-level Prolog predicates which are defined in the preferred embodiment in terms of other standard Prolog predicates. Explanations and technical definitions of these Prolog predicates are contained in the Predicate Definition section of this specification. In Prolog, the integer after the slash symbol of each predicate indicates the number of arguments for that predicate. For example, the predicate "above/2" uses two arguments which are described in the Predicate Definition section.
The Prolog predicates utilize data in nine various forms, called data types. Explanations and technical definitions of the data types are contained in the Data Type Definition section of this specification.
ANALYZER.ARI
ANALYZE.ARI is a file of Prolog predicates that reconsults, or loads, the remaining four files (ENGINE.ARI, UTILS.ARI, LEXER.ARI, and PARSER.ARI) into the Prolog database. In addition, the appropriate knowledge base is consulted into the Prolog database for subsequent pattern matching operations.
The top level predicate analyze/1 is defined in the file ANALYZE.ARI and accepts as its argument a file name containing a student solution program in Pascal. Analyze/1 lexes and then parses the file using the predicate parse/1, applies the current knowledge base 120 to the resulting abstract syntax tree by using the predicate top.sub.-- level/1, and then writes out the resulting list of messages to a file by using the predicate output.sub.-- messages/2 where the messages can be input to the computer/user interface 102 for display.
PARSER.ARI
The file PARSER.ARI defines the predicate parse/1 and is called by the analyze/1 predicate of ANALYZE.ARI. The function of parse/1 is to create an abstract syntax tree for the student program and store the abstract syntax tree in the Prolog database. An abstract syntax tree is a node which contains within it a set of associated nodes which represent the student program. A node is a data type which can be represented either as a nested list, or as a set of parent.sub.-- child/2, next.sub.-- left.sub.-- sibling/2 and node.sub.-- type/2 Prolog assertions. The node pointer that points to the root node of the abstract syntax tree can be determined by invoking the query root.sub.-- node(PtrToRootOfAST).
LEXER.ARI
In order to generate an abstract syntax tree, the parse/1 predicate first calls the lexer 114 by invoking the predicate open.sub.-- file.sub.-- and.sub.-- lex.sub.-- tokens/2 found in LEXER.ARI. The predicate open.sub.-- file.sub.-- and.sub.-- lex.sub.-- tokens/2 opens the student Pascal program, executes the lex/2 predicate on the text contained therein to create a list of tokens, and closes the file. The tokens are asserted into the second argument of the predicate open.sub.-- file.sub.-- and.sub.-- lex.sub.-- tokens/2.
A token is a data type which is a two-element list. The first element is the symbol found by the lexer, and the second element is the line number in the file on which the symbol was found. For example, if the following file called TEST.PAS is input:
______________________________________1 { Definition of the program called foo}2 PROGRAM foo (INPUT,OUTPUT);4 VAR5 i: INTEGER;67 BEGIN8 i:= 19 END10 { End of the text of the program}______________________________________
Execution of the open.sub.-- file.sub.-- and.sub.-- lex.sub.-- tokens/2 predicate will result in the following:
______________________________________?- open.sub.-- file.sub.-- and.sub.-- lex.sub.-- tokens (`test.pas`,Tokens).Tokens = [[ program,2],[foo,2],['(',2],[input,2],[',',2], [output,2],[')',2],[';',2], [var,4], [i,5],[:,5],[integer,5],[';',5], [begin,7], [i,8],[:,8],[=,8],[1,8], [end,9],['.',9],[eof,9]] .fwdarw.;no______________________________________
As can be seen, the variable "token" has been instantiated to indicate that the symbol "program" is found at line 2, the symbol "foo" is found at line 2, . . . the symbol "begin" is found at line 7, and so on. Thus, the list of tokens contained in the variable "tokens" describes the student program by listing each symbol of the program and its line location.
The program file which was input in the predicate open.sub.-- file.sub.-- and.sub.-- lex.sub.-- tokens/2 is processed by the Arity Prolog special predicates open/3 and close/1. The lexer invoked is defined in the predicate lex/2, which is modelled after the lexer defined in Clocksin & Mellish, pp. 101-103. This has been modified to include predicates to strip out Pascal comments and to define which characters constitute special symbols in Pascal (e.g., `;`, `.`, etc.). One extra token is added to the end of all lists of tokens: [eof,N], where N is an integer denoting the last line of the file lexed.
Abstract Syntax Tree
Once the student's program has been lexed into a list of tokens, the parse/1 predicate processes the list of tokens into an abstract syntax tree. The abstract syntax tree is a description of a node in terms of its associated nodes. A node is a data type in Prolog which is defined in terms of its type, its location pointer, and its children nodes. The children nodes are also defined in terms of their type, their location pointers, and their children nodes, which are the grandchildren nodes of the original node. A node is set forth below in BNF form: ##STR1##
When the list of tokens for TEST.PAS is processed by parse/1, the following abstract syntax tree results:
______________________________________[program,[node22,2,9], [[foo,[node1,2,2], []], [prog.sub.-- header,[node4,2,2], [[input,[node2,2,2], []], [output,[node3,2,2], []]]], [block,[node21,4,9], [[label.sub.-- decl.sub.-- list,[node5,9999999,9999999], []], [const.sub.-- decl.sub.-- list,[node6,9999999,9999999], []], [type.sub.-- decl.sub.-- list,[node7,9999999,9999999], []], [var.sub.-- decl.sub.-- list,[node12,4,5], [[var.sub.-- decl,[node11,5,5], [[defined.sub.-- type,[node10,5,5], [[integer,[node9,5,5], []]]], [ i,[node8,5,5], []]]]]], [procedure.sub.-- and.sub.-- function.sub.-- list,[node13,9999999,9999999], []], [begin,[node20,7,9], [[:=,[node19,8,8], [[variable,[node17,8,8], [[i,[node15,8,8], []], [empty,[node16,8,8], []]]], [1,[node18,8,8], []]]]]]]]]]
This abstract syntax tree can also be viewed pictorially as a tree of nodes, as shown in FIG. 4. By analyzing the abstract syntax tree, it can be seen that the top level node has a node type "program," a unique ID "node22", starts on line 2 and extends to line 9 of the program, and has three children whose types are "foo", "prog.sub.-- header", and "block". Each of the children can be similarly described; for example, the child node "prog.sub.-- header" has a unique ID "node4", starts and ends on line 2, and has two children "input" and "output".
Line numbers of 9999999 indicate that the node does not appear in the text of the Pascal program; rather, the node was created by parse/1 for internal accounting procedures, or as a "filler" to canonicalize the parent node. In the abstract syntax tree above, a node has been created for a "procedure.sub.-- and.sub.-- function.sub.-- list" even though no procedures or functions exist in the Pascal program parsed; this was done simply so that all nodes of type "block" contain a child of type "procedure.sub.-- and.sub.-- function.sub.-- list".
Abstract syntax trees are most conveniently viewed as nested lists, but are not actually stored in the Prolog database in that form. Instead, parse/1 creates and stores abstract syntax trees as sets of Prolog assertions. The four types of assertions which are used to completely describe and store abstract syntax trees are root.sub.-- node/1, parent.sub.-- child/2, next.sub.-- left.sub.-- sibling/2, and node.sub.-- type/2. All io previously existing parent.sub.-- child/2, next.sub.-- left.sub.-- sibling/2, node.sub.-- type/2 and root.sub.-- node/1 assertions are deleted from the Prolog database to insure that all such assertions in the current database refer to the most recently parsed Pascal program. In addition, the predicate parse/1 will only return the assertions into the database if the Pascal program is syntactically correct. Should the program called in the argument of parse/1 be syntactically deficient, parse/1 will return either the word "no" or display an error message.
Root.sub.-- node/1 defines the top level node in the abstract syntax tree. Thus, for TEST.PAS, a root.sub.-- node/1 query would result as follows:
?--root.sub.-- node(PtrToTopLevelNode).
PtrToTopLevelNode=[node22,2,9]
This is the pointer to the node "program" in TEST.PAS. This can be confirmed by invoking the predicate node.sub.-- type/2:
?--node.sub.-- type(TypeOfTopLevelNode,[node22,2,9]).
TypeOfTopLevelNode=program.fwdarw.
A parent.sub.-- child/2 query for the children of the top level node will provide a list of the node pointers to the nodes that are the children of the top level node "program":
?--parent child([node22,2,9],Child).
Child=[node1,2,2].fwdarw.;
Child=[node4,2,2].fwdarw.;
Child=[node21,4,9].fwdarw.;
Again, by viewing the abstract syntax tree, it is seen that these node pointers refer to the top level node's three children: "foo", "prog.sub.-- header", and "block".
The predicate next.sub.-- left.sub.-- sibling/2 can be invoked in order to determine how the children nodes are juxtaposed:
?--next.sub.-- left.sub.-- sibling([node1,2,2],Sibling).
Sibling=[node4,2,2].fwdarw.
and
?--next.sub.-- left.sub.-- sibling([node4,2,2],Sibling).
Sibling=[node21,4,9].fwdarw.
The results of these queries indicate that the node "foo" is immediately to the left of the node "prog.sub.-- header", which is itself immediately to the left of the node "block".
Thus, by querying the Prolog database with the required number and combinations of the root.sub.-- node/1, parent.sub.-- child/2, next.sub.-- left.sub.-- sibling/2, and node.sub.-- type/2 predicates, one can access all information regarding the abstract syntax tree which would be embodied in its nested list format.
The predicate recreate.sub.-- node/2 is useful since it allows the recreation of any node as a nested list. Thus, to view the "prog.sub.-- header" node as a nested list:
______________________________________recreate.sub.-- node([node4,2,2],NodeAsList).NodeAsList = [prog.sub.-- header,[node4,2,2], [[input,[node2,2,2], []], [output,[node3,2,2], []]]] .fwdarw.______________________________________
ENGINE.ARI
The file ENGINE.ARI, which is consulted into the Prolog database by the top-level file ANALYZER.ARI, functions as an inference engine to search the abstract syntax tree generated by PARSER.ARI and perform pattern matching operations in conjunction with the assertions stored in the knowledge base 120. ENGINE.ARI defines certain "node relation" predicates, as described in the Predicate Definitions section, and provides for the match/1 predicate for pattern matching between portions of the abstract syntax tree and the knowledge base.
Knowledge Base
The knowledge base is a repository of correct and incorrect methods of solving a particular programming problem, and is written as a set of Prolog predicates called knowledge base pattern predicates. A knowledge base pattern predicate 122 is a Prolog predicate of data type "knowledge base pattern," which is consulted into the Prolog database and matched by the analytic component 112 against portions of the abstract syntax tree of the student's Pascal program. Each programming problem made available to the student requires its own corresponding knowledge base 120 to be consulted into the Prolog database. Some sets of knowledge base pattern predicates 122 can be shared among different knowledge bases 120 depending upon common features of the various problems.
Attached to some of the knowledge base pattern predicates 122 are messages 124 in English textual form. The messages 124 provide feedback to the student regarding the solution he or she has entered in response to the selected problem.
Knowledge Engineering
A knowledge base for a particular programming problem is created by a knowledge engineer, who should have experience in critiquing students' Pascal programs. Knowledge bases are succinct descriptions of the many and various ways in which students are apt to correctly and incorrectly solve a given programming problem. Thus, a knowledge engineer needs to have a working knowledge of what sorts of solution variants students are likely to arrive at.
It is useful for the knowledge engineer to develop knowledge bases with a computer having a large screen, along with a windows-type software environment and a mouse input device. Thus, in the preferred embodiment, a MAC II personal computer is used for knowledge base development. The knowledge bases are then ported to the DOS-based computer used to execute the entire system.
In creating a knowledge base, the knowledge engineer, typically follows the following steps (not necessarily in the order given below):
By examining a large corpus (e.g., one hundred or more) of student solutions to a given programming problem, the knowledge engineer is able to get a good idea of the sorts of programs that the knowledge base will need to be able to account for. Existing knowledge bases may be perused to find parts that may be effectively reused in the construction of the new knowledge base.
Exemplars from the corpus of student solutions are selected according to typicality. Normally, there are a handful of programs which exhibit a large part of the variance exhibited in the types of solutions arrived at by the majority of students represented in the corpus. Starting from these exemplars, the knowledge engineer can start to describe, as patterns for the knowledge base, the characteristic components of the program solutions. In the preferred embodiment, an off-line utility called the example compiler assists the knowledge engineer with this phase of the development process.
Patterns created are abstracted and generalized into sets of Prolog predicates that can then be tested against other student programs in the corpus of student solutions. At this point, standard software engineering techniques of top-down design can be applied to the problem of structuring the knowledge base.
The patterns in a knowledge base have attached to them a message which is reported to the student if the pattern successfully matches against some part of the student's program. In order to author pedagogically effective messages, it is recommended that knowledge engineers work closely with Pascal instructors to edit and rephrase messages included in the knowledge bases.
After preliminary testing and consultations with Pascal instructors, the knowledge engineer ports the knowledge base to the DOS-based computer, where the knowledge base is compiled and then tested against another corpus of student programs. If testing goes well, the knowledge base is ready for use.
To illustrate the process of outlining a knowledge base, reference is made to the Rotate problem, which is available in the preferred embodiment, as shown in Table B.
TABLE B______________________________________The Rotate Problem______________________________________ Write a procedure that rotates the elements ofan array "s" with "n" elements so that when therotation is completed, the old value of s[1] will bein s[2], the old value of s[2] will be in s[3],. . . , the old value of s[n-1] will be in s[n], andthe old value of s[n] will be in s[1]. The procedureshould have "s" and "n" as parameters. You mayassume that the type "Item" has been declared and"s" is of the type "List" which has been declared asList = array [1. .Max] of Item.______________________________________
The Rotate problem essentially asks students to write a program to rotate each element of an array one position to the right. In Table C below is an incorrect sample solution to the Rotate problem, which uses one loop and one temporary variable. Note that the loop counts upwards, where, to be correct, it should count downwards. Thus, the program will incorrectly copy the contents of S[2] into all of S[3], S[4], . . . S[N].
TABLE C______________________________________Incorrect Sample Solution to the Rotate Problem______________________________________PROGRAM Foo (INPUT, OUTPUT);CONST Max = 100;TYPE Item = INTEGER; List = ARRAY[1..Max] OF Item;VAR PassedAsS : List; PassedAsN : INTEGER;PROCEDURE Rotate (VAR S : List; N : INTEGER); VAR Temp : Item; I : 1..Max; BEGIN Temp := S[N]; FOR I := 2 TO N DO BEGIN S[I] := S[I - 1] END; S[1] :=Temp END;BEGINRotate(PassedAsS, PassedAsN)END.______________________________________
The major design decisions faced by students attempting to solve the Rotate Problem include: whether to use one array or two; whether to use one loop or two; whether to have the loop(s) count up or down; and what kind of and how many temporary variables to use.
As a first step towards developing a knowledge base for a new programming problem, the knowledge engineer should first record all the different sorts of potential solutions as he or she can determine. By sorting the solutions generated into categories, one often ends up with a list of major design decisions for the problem, like the ones listed above for the Rotate problem. If the knowledge engineer then looks through a large selection of student solutions to the problem, he or she will likely find solutions that he or she wasn't able to predict a priori. If unexpected correct solutions aren't found, then, at the very least, unexpected buggy solutions will be found in the students' solutions.
By highlighting some of the more important pieces of the code and by articulating some of the relationships between statements in the sample program, we can start to describe the sorts of pattern predicates that the knowledge base will need to contain. First, we describe what each statement in the body of the procedure does:
______________________________________BEGIN store.sub.-- to.sub.-- temp: The value of S[N] is put into atemporary variable. Temp := S[N]; loop: The loop operates on each element of the array. FOR I := 2 TO N DO BEGIN shift: The values in the array are shifted oneposition to the right. S[I] := S[I - 1] END; retrieve: The former value of S[N] is retrieved fromthe temporary variable and installed in S[1]. S[1] := TempEND;______________________________________
By annotating the body of the procedure in this manner, we have identified four of the major pieces necessary for a solution which uses one temporary variable and one loop:
store to temporary variable,
loop,
shift array elements right, and
retrieve from temporary variable.
In addition, the loop of the program in Table C contains an error; it counts up instead of down. The error is observable upon examination of the relationship between the expression used in the shift statement and the direction of the loop. Moreover, the array needs to be passed into the procedure before the procedure can rotate the elements of the array. Thus, we can refine the outline of the Rotate Knowledge Base further:
Rotating an array involves:
passing parameters into a procedure, and
shifting the array.
Passing parameters into a procedure entails checking to make sure that:
the array and
the size of the array are passed into the
Shift: one of the following can be used as the mechanism that shifts the array elements one place to the
Correct Method:
A[LHSExpr]:=A[RHSExpr] is used to shift the array elements where LHSExpr=RHSExpr+1,
A[n] is stored into a temporary variable above the loop, and
A[n] is retrieved from the temp below the loop and put into A[1]
The loop counts downward from n to 1.
Buggy Method:
A[LHSExpr]:=A[RHSExpr]where LHSExpr=RHSExpr+1,
A[n] is stored into a temporary variable above the loop, and
A[n] is retrieved from the temp below the loop and put into A[1]
The loop counts upwards, consequently, the first element of the array is incorrectly copied into the rest of the elements.
Note that not only has more detail been added to the outline with respect to what kinds of statements are expected, but also, information has been added which specifies relations between the constituent parts. For example, A[N] should be stored above the loop.
The outline above is still incomplete. It is also possible to solve the Rotate problem with a loop counting upwards, with two loops, with two temporary variables, or with an extra array used as intermediate storage during the process of rotation.
The following outline describes the Rotate knowledge base of the preferred embodiment. It was constructed after many student programs had been examined and analyzed for errors and alternative solution methods.
Rotating an array involves
passing parameters into a procedure, and
shifting the array
Shifting the array can be done using either
one array, or
two arrays.
If one array is used to shift the array, then
within a loop one should be able to find
a shift expression
If two arrays are used to shift the array, then either
two loops are used, or
one loop is used
Passing parameters into a procedure entails checking to make sure that
the array and
the size of the array are passed into the procedure
Shift expression: one of the following can be used as the mechanism that shifts the array elements one place to the right:
Correct Method:
A[LHSExpr]A[RHSExpr]is used to shift the array elements where LHSExpr=RHSExpr+1,
A[n] is stored into a temporary variable above the loop, and
A[n] is retrieved from the temp below the loop and put into A[1]
The loop counts downward from n to 1.
Correct Method:
Temp2:=A[RHSExpr], and
A[LHSExpr]:=Temp1, and
Temp1:=Temp2
A[1] is stored into Temp1 above the loop,
and
A[2] is stored into Temp2 above the loop
A[1] gets Temp2 below the loop
The loop counts upward.
Buggy Method:
A[LHSExpr]:=A[RHSExpr]
where LHSExpr=RHSExpr+1,
A[n] is stored into a temporary variable above the loop, and
A[n] is retrieved from the temp below the loop and put into A[1]
The loop counts upwards, consequently, the first element of the array is copied into the rest of the elements.
Buggy Method:
A[LHSExpr]:=A[RHSExpr]
where RHSExpr=LHSExpr+1,
which forces the elements of the array to be shifted left rather than right.
If two arrays and two loops are used to rotate the array, then either:
Correct Method:
in the first loop elements from the first array are copied into
the second array, offset by one position, then
in the second loop elements of the second array are copied
back into the first array in their offset positions, or
Correct Method:
in the first loop elements from the first array are copied into
the second array, then
in the second loop elements of the second array are copied
back into the first array offset by one position, or
Buggy Method:
in the first loop elements from the first array are copied into
the second array, offset by one position, but then
in the second loop elements are not copied back into
the first array in their offset positions, or
Buggy Method:
in the first loop elements from the first array are copied into
the second array, but then
in the second loop elements of the second array are not copied
back into the first array offset by one position.
If two arrays and one loop are used to rotate the array, then statements of the form
A2[LHSExpr1]A1[RHSExpr1], and
A1[LHSExpr2]A2[RHSExpr2] are inside the loop,
and
Correct Method:
The loop counts upward,
LHSExpr1=RHSExpr1,
LHSExpr2=RHSExpr2+1, and
LHSExpr1=LHSExpr2, or
Correct Method:
The loops counts downward,
LHSExpr1=RHSExpr1,
LHSExpr2=RHSExpr2+1, and
RHSExpr1=RHSExpr2, or
Correct Method:
The loop counts upward, and
UiSExpr1=RHSExpr1+1,
LHSExpr2=RHSExpr2, and
LHSExpr2=RHSExpr1, or
Correct Method:
The loop counts downward,
LHSExpr1=PHSExpr1+1,
LHSExpr2=RHSExpr2, and
LHSExpr1=LHSExpr2, or
Buggy Method:
The loop counts upward,
LHSExpr1=RHSExpr1, but
in the second assignment statement the elements are not restored
into the original array, A1, by offsetting their position one to the right.
Buggy Method:
The loop counts downward,
LHSExpr1=RHSExpr1, but
in the second assignment statement the elements are not restored
into the original array, A1, by offsetting their position one to the right.
Buggy Method:
The loop counts upward,
LHSExpr1=RHSExpr1+1, but
in the second assignment statement the elements are not restored
into the original array, A1, from the storage array, A2.
Buggy Method:
The loop counts downward,
IJiSExpr1=RHSExpr1+1, but
in the second assignment statement the elements are not restored
into the original array, A1, from the storage array, A2.
Two criteria need to be balanced during the construction of a knowledge base: (1) the need to render the knowledge base so that it can be efficiently matched against student programs, and (2) the requirement that the knowledge base represent a set of plausible decompositions of the programming problem. As to the representation of the possible decompositions, it is desirable that a knowledge base describe, in as problem independent form as possible, the various tasks and subtasks that must be solved by a student program. A problem independent vocabulary for problem decomposition is desired because it forces pieces of the knowledge base into a form general enough to be of use in the construction of other knowledge bases. That is, knowledge base predicates should be written in a form as general as possible so that they can be reused later. The Rotate knowledge base outlined above does not contain many problem independent pattern predicates. However, for example, in the outline of the Rotate knowledge base it has been assumed that a pattern predicate will be available to match a loop. The example Rotate student solution examined earlier contained a FOR loop. However, the loop could be implemented in Pascal as a REPEAT-UNTIL, a WHILE, a FOR, or with tail recursion. The loop pattern predicate used in the Rotate knowledge base can match against several different forms of iteration and, thus, can be of use in the construction of other knowledge bases where a loop is called for in the problem statement.
The construction of generalized pattern predicates conflicts with the criterion that knowledge bases be as small and as fast as possible. As is usually the case with all software, the criteria of efficiency and generality are in tension with one another. When two or more knowledge bases need to be constructed, it is recommended that the knowledge engineer identify subtasks common to all of the programming problems and then outline the knowledge bases with the intention that some of the code for the knowledge bases will be shared between them.
Note also how the structure of the outline of the Rotate knowledge base does not necessarily reflect the hierarchy of decisions that have to made by the students in creating a solution to the Rotate problem. Rather, the outline reflects the order in which pieces of the student programs should be matched. Ideally, the student program would be analyzed in a manner isomorphic to the order in which it was constructed by the student. Such an isomorphism would be ideal because it would allow one to examine the relationship between a knowledge base and a cognitive model of the problem solving processes applied by a given student solving a given programming problem.
Efficiency, however, does not permit this isomorphism between cognitive model and knowledge base. Thus, for example, checking the parameters passed into the procedure is one of the first things done by the Rotate knowledge base because it allows the binding of some pivotal variables in the pattern predicates that are used, subsequently in the analysis of a student program, to direct searches through the student's code. That is, passing parameters is at the top level of the Rotate knowledge base, not because it is descriptive of a top level decision that has to be made by student programmers, but, rather, because matching parameters right away makes it easier for the knowledge base to analyze the rest of the student's program.
During development of a knowledge base, the knowledge engineer repeatedly amends the knowledge base so that it can analyze a wider range of student solutions; and the knowledge engineer revises the knowledge base so that it does its pattern matching on the student program quicker and more efficiently. Maintaining an outline to reflect the changes imposed on the knowledge base can give the knowledge engineer a way-of planning and explaining the structure of the knowledge base. Construction of Knowledge Base Pattern Predicates
The knowledge base pattern predicate 122 is primarily constructed out of three types of Prolog instructions: match/1 instructions, node relation predicates (such as above/2, nth.sub.-- child/3, etc.), and messages/2.
Match/1
By using the predicate match/1, knowledge base pattern predicates 122 can be matched against the abstract syntax tree produced by parse/1. The purpose of match/1 is to search an abstract syntax tree to find specific node types and node pointers within the tree. Match/1 does not return nodes from the Prolog database; rather, it binds variables contained in its argument to specific node types and node pointers. The argument of match/1 is written in nested list syntax.
The argument for match/1 is written in the following general format:
[<type>,<ptr>,<children>]
If a variable is desired in the <children> position, the generic underscore variable should be used:
[<type>,<ptr>,.sub.-- ]
Essentially, match/1 destructures its node pattern argument into a three element list: Type, Ptr, and Children. It first fetches any node pointer in the data base of the type Type (i.e., node.sub.-- type(Type,Ptr)). It then invokes the predicate match/3, which is match(1,Children, Ptr). Match/3 takes 3 arguments: match(N,Children,ParentPtr), where N is an integer, Children is a list of node patterns, and ParentPtr is a node pointer.
Match/3 terminates successfully when the argument Children is an empty list. Otherwise, it destructures the first child listed in Children into the three element list [Type,Ptr,GrandChildren]; it checks to make sure that the first child is the Nth child of the node pointed to by ParentPtr. Match/3 recursively invokes itself to check the form of the GrandChildren: match(1,GrandChildren,Ptr); and then it recursively invokes itself to check the rest of the Children: match(Next,RestChildren,ParentPtr), where Next is N+1 and Children=[[Type,Ptr,GrandChildren].vertline.RestChildren].
If match/3 fails at any point, match/1 is backtracked to and selects another node in the database to try using the node.sub.-- type(Type,Ptr) query. In this way, all of the nodes in the database (which were produced by the predicate parse/1) are searched until either the pattern described in the argument of match/1 is found, or it is determined that the pattern does not exist in the current abstract syntax tree.
The code for the predicate match/i which implements the above described recursive routine is found in the Prolog predicate file ENGINE.ARI, which is listed in the Source Code Appendix hereto.
Node Relation Predicates
In addition to the match/1 predicate, the knowledge base 120 implements the following set of fourteen predicates which define various relations between nodes (these predicates are a subset of the predicates listed in the Predicates Definition section):
TABLE D______________________________________Node Relation Predicates______________________________________above/2 proper above/2ancestor/2 proper.sub.-- ancestor/2below/2 proper.sub.-- below/2descendant/2 proper.sub.-- descendant/2left.sub.-- sibling/2 proper.sub.-- left.sub.-- sibling/2right.sub.-- sibling/2 proper.sub.-- right.sub.-- sibling/2next.sub.-- left.sub.-- sibling/2 parent.sub.-- child/2______________________________________
Both arguments to each of the relation predicates refer to node pointers. All of the relations can be used with both arguments instantiated, or with the first argument as a variable and the second argument instantiated to an existing node pointer. It is not possible, however, to use the relation predicates with the first argument instantiated and the second argument as a variable; the results will not necessarily be correct if used in this fashion.
For example, referring to the abstract syntax tree generated for the program TEST.PAS, it can be determined that "block" (node21) is a proper.sub.-- descendant of "program" (node22):
?--proper.sub.-- descendant(PD,[node22,2,9])
PD=[node21,4,9]
All of the relation predicates are fully explained in the Predicate Definitions section.
The predicates proper.sub.-- above/2, above/2, proper.sub.-- below/2, and below/2 are all less specific than the predicates such as parent.sub.-- child/2, ancestor/2, left.sub.-- sibling/2, and the like. This is true, because, for example, if parent.sub.-- child (A,B) is true, it necessarily follows that proper.sub.-- above(A,B) is true; that is, parent.sub.-- child(A,B) implies proper.sub.-- above(A,B). Note that below/2 and above/2 are the least specific of all the relation predicates.
Generation of an efficient knowledge base mandates that the most specific predicates be used, so that the knowledge base pattern will match only to the portions of the abstract syntax tree intended to be matched. Table E below defines a partial order for all fourteen relation predicates. The partial order is Q.fwdarw.R, which is read as "Q implies R." The preferred embodiment utilizes an example compiler 300, which is an off-line software tool which will check the code in a knowledge base against the partial order defined in Table E.
In particular, it has been observed that the predicates above/2 and below/2 may function in a redundant fashion. A combination of the predicates left-sibling/2 and/or ancestor/2 is more efficient than the use of above/2, and likewise, a combination of the predicates right.sub.-- sibling/2 and/or descendent/2 is more efficient than the use of below/2. Thus, in the preferred embodiment, the use of above/2 and below/2 has been avoided. The descriptions of above/2 and below/2 are included in this specification however, in order to present a complete description of predicates available in the present invention.
TABLE E______________________________________Partial Order Over the Relation Predicates______________________________________ancestor(X,Y) .fwdarw. descendent(Y,X)descendent(X,Y) .fwdarw. ancestor(Y,X)ancestor(X,Y) .fwdarw. above(X,Y)descendent(X,Y) .fwdarw. below(X,Y)proper.sub.-- ancestor(X,Y) .fwdarw. ancestor(X,Y)proper.sub.-- descendent(X,Y) .fwdarw. descendent(X,Y)proper.sub.-- ancestor(X,Y) .fwdarw. proper.sub.-- descendent(Y,X)proper.sub.-- descendent(X,Y) .fwdarw. proper.sub.-- ancestor(Y,X)parent.sub.-- child(X,Y) .fwdarw. proper.sub.-- ancestor(X,Y)parent.sub.-- child(X,Y) .fwdarw. proper.sub.-- descendent(Y,X)left.sub.-- sibling(X,Y) .fwdarw. right.sub.-- sibling(Y,X)right.sub.-- sibling(X,Y) .fwdarw. left.sub.-- sibling(Y,X)left.sub.-- sibling(X,Y) .fwdarw. above(X,Y)right.sub.-- sibling(X,Y) .fwdarw. below(X,Y)proper.sub.-- left.sub.-- sibling(X,Y) .fwdarw. left.sub.-- sibling(X,Y)proper.sub.-- right.sub.-- sibling(X,Y) .fwdarw. right.sub.-- sibling(X,Y)proper.sub.-- left.sub.-- sibling(X,Y) .fwdarw. proper.sub.-- right.sub.-- sibling(Y,X)proper.sub.-- right.sub.-- sibling(X,Y) .fwdarw. proper.sub.-- left.sub.-- sibling(Y,X)next.sub.-- left.sub.-- sibling(X,Y) .fwdarw. proper.sub.-- left.sub.-- sibling(X,Y)next.sub.-- left.sub.-- sibling(X,Y) .fwdarw. proper.sub. -- right.sub.-- sibling(Y,X)above(X,Y) .fwdarw. below(Y,X)below(X,Y) .fwdarw. above(Y,X)proper.sub.-- above(X,Y) .fwdarw. above(X,Y)proper.sub.-- below(X,Y) .fwdarw. below(X,Y)proper.sub.-- above(X,Y) .fwdarw. proper.sub.-- below(Y,X)proper.sub.-- below(X,Y) .fwdarw. proper.sub.-- above(Y,X)proper.sub.-- descendent(X,Y) .fwdarw. proper.sub.-- below(X,Y)proper.sub.-- right.sub.-- sibling(X,Y) .fwdarw. proper.sub.-- below(X,Y)proper.sub.-- ancestor(X,Y) .fwdarw. proper.sub.-- above(X,Y)proper.sub.-- left.sub.-- sibling(X,Y) .fwdarw. proper.sub.-- above(X,Y)______________________________________
To describe how a knowledge base pattern predicate 122 is derived from match instructions and ordering relation predicates, reference is made to the Rotate programming problem, as shown in Table B above.
As indicated in the sample knowledge base outline above, one important program step which should be included in a student's solution code is the step of retrieving the former value of S[N] from the temporary variable and installing it in S[1], which appears in the solution above as S[1]:=Temp.
The knowledge base pattern predicate retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6 shown below is constructed to find in the student's solution program a statement in the form A[N] :=Temp, as required above. In the preferred embodiment, retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6 is part of a knowledge base called ROTATE.ARI used to analyze a student's program solution to the Rotate problem.
The predicate retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6 defines the correct form sought as well as two incorrect forms which may be found instead. Each of the two incorrect forms is annotated with a message. If an incorrect form is matched to the student's program, the message attached is reported to the student.
______________________________________retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6:% The first clause defines what the knowledge base expects to% find if the Pascal program is correct.retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop( RetrievePtr, ArrayName, Integrer, TempName, LoopPtr, Msgs) :-match( [:=, RetrievePtr, [[variable,.sub.--, [[ArrayName,.sub.--, []], var.sub.-- modifier.sub.-- list,.sub.--, [[array.sub.-- index,.sub.--, [[Integer,.sub.--,[]]]]]]]], [variable,.sub.--, [[TempName,.sub.--,[]], [empty,.sub.--, []]]]]]),below( RetrievePtr, LoopPtr).% The second clause defines what the knowledge base might find% if the Pascal program contains the expected assignment% statement in an unexpected place in the program.retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop( RetrievePtr, ArrayName, Integer, TempName, LoopPtr, Msgs) :-match( [:=,RetrievePtr, [[variable,.sub.--, [[ArrayName,.sub.--,[]], [var.sub.-- modifier.sub.-- list,.sub.--, [[array.sub.-- index,.sub.--, [[Integer,.sub.--,[]]]]]]]], [variable,.sub.--, [[TempName,.sub.--,[]], [empty,.sub.--,[]]]]]]),not below( %%% This call to below/2 RetrievePtr, %%% is not necessary, but LoopPtr), %%% allows a declarativemessages( %%% reading of the predicate. [[bug,RetrievePtr,[-1.0] , ["The assignment statement", nl, "must be below the loop"]]], Msgs).% The third clause covers the case where the Pascal program% does not contain an assignment statement of the expectedform.retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop( RetrievePtr, ArrayName, Integer, TempName, LoopPtr, Msgs) :-messages( [[bug,LoopPtr,[-1.0], ["Your program appears to be missing", nl, "a necessary assignment statement below", "the loop.",nl, "Specifically, it is missing an assignment", nl, "statement of the form", nl, ArrayName,"[",Integer,"]," := ",TempName]]], Msgs).______________________________________
The match instructions in retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop.sub.-- 6 specify the form of the assignment statement expected. The relations used are below(RetrievePtr,LoopPtr) and not(below(RetrievePtr,LoopPtr)) definitive, respectively, of the correct and possible incorrect positionings of the assignment statement.
If the match/1 predicate and the relation predicate below/2 of the first clause of retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop.sub.-- 6 are both satisfied, the student's use of the assignment statement is correct, and no messages are flagged for display. This will occur when the RetrievePtr node is correctly "below" the LoopPtr node.
If, however, the match/1 predicate is satisfied but the RetrievePtr node is incorrectly "not below" the LoopPtr node, the messages variable will be instantiated to indicate that the assignment statement must be below the loop, as illustrated in the second clause of retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop.sub.-- 6.
Finally, if the assignment statement is omitted such that the predicate match/1 is not satisfied, the messages variable will be automatically instantiated to so indicate, as shown in the third clause of retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop.sub.-- 6.
As illustrated above, a knowledge base pattern predicate may take the form of any arbitrary Prolog predicate, and often includes calls to other predicates. It is preferable to list match instructions before any relation predicates. As shown in the example, retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop.sub.-- 6 is written with the assumption that LoopPtr will be instantiated elsewhere and then passed in, in order to be compared against RetrievePtr after RetrievePtr has been found with the match instruction shown
Messages
The messages/2 instructions contain the text of error messages that can be output to the student. Normally, a message contains a pointer to a portion of the student's program and some text describing what is wrong with the student's program. In addition to the text, messages/2 also contain a negative integer, or weight. The analytic component 112 uses the sum of the weights of the matched patterns to calculate an overall score for a student's program, which is comparable to the score that the student would get if the program were graded manually, in accordance with APCS guidelines.
There are two types of messages in the preferred embodiment: "bug" and "method". Bug-type messages correspond to faulty student programs, while method-type messages correspond to correct student implementations. Only those messages labelled as bug-type messages are provided to the student in the preferred embodiment. It is useful, however, when generating knowledge base pattern predicates, to include method-type messages, in the event that users desire an embodiment which will provide messages that the solution entered by the student is correct in various respects. The preferred embodiment could easily be modified to output such method-type messages to the student if the messages are already contained within the knowledge bases in existence.
The messages that are associated with knowledge base pattern predicates have a very specific syntax, as defined in the Data Type Definition section. Each message has four fields: a type (bug or method), a node pointer (or a "*" as a place holder), a list containing a negative integer (or a "*"), and a list of message strings. Occurrences of "n1"in the list of strings causes a new line to be inserted in the message when it is displayed to the student. The third field of a list containing a number is used to weight the knowledge base pattern predicate for scoring purposes.
An example of a message was given in the third clause of the definition of the knowledge base pattern predicate retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6. The predicate messages/2 takes as a first argument a list of messages. Messages/2 appends all of the messages that appear in its first argument and puts the result in its second argument. By convention, the second argument to messages/2 is usually the last parameter of the knowledge base pattern predicate. Messages are instantiated in the knowledge base pattern predicates and then passed "upwards" to the calling predicate and are then, ultimately, output to the student by the predicate top.sub.-- level/1.
Scoring
In addition to producing English language messages on a student Pascal program, the preferred embodiment also generates an overall score representative of the score that the student would likely receive from an APCS grader if the solution program was submitted as an exam problem solution.
The weight attached to the second and third clauses of the knowledge base pattern predicate retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6 is -1.0. The weights are passed, along with the messages, "upwards" to the predicate top.sub.-- level/1 of the knowledge base. There, they are added together and the sum is reported to the student as the score for the solution program. If the sum is less than zero a score of zero, is reported. (Zero is the minimum score because zero is the minimum score for open response questions on the APCS examination.)
The magnitudes of the weights attached to the messages are derived from scoring rubrics for the APCS examination which have been made publicly available.
In sum, the structure of a knowledge base is as follows:
______________________________________knowledge base = set of correct and incorrect knowledge base pattern predicatesknowledge base = pattern to find + messagepattern predicatepattern to find = matches to abstract syntax tree + relations between parts of treemessage = text + weight______________________________________
A new knowledge base must be constructed for each new programming problem class added to the system's repertoire. For example, in the preferred embodiment, COMPACT.ARI and ROTATE.ARI are the two knowledge bases built to analyze student solutions to the problems of compacting and rotating an array, respectively.
By using appropriate match instructions, along with the generic Prolog variable and ".sub.-- " appropriate node relation predicates, knowledge base pattern predicates can be created to be as flexible or specific as desired.
For example, if a knowledge base engineer wishes to specify that a certain node X can be anywhere above a certain node y, the knowledge base pattern predicate utilized to check for this will be quite flexible. That is, a successful match would occur against the abstract syntax tree as long as the general condition that X is above Y is met, no matter how many lines of code separate the two nodes.
If, however, the knowledge base engineer feels it is necessary to successfully match only if node X is directly above node Y, the knowledge base pattern predicate will be created to only match if this more specific condition occurs.
Thus, the knowledge base is created with an eye towards matching portions of the abstract syntax tree as flexibly or specifically as desired with nodes of the abstract syntax tree being considered matched if they are within a certain predetermined range, thus nodes can be matched as close or remote as desired by the knowledge base engineer.
Example Compiler
The knowledge base pattern predicates which comprise the knowledge base can be generated manually as described above. This process is partially automated in the preferred embodiment by an off-line utility, called an example compiler 300, which is shown at FIG. 3.
The example compiler 300 will take as input a model solution program in text form, and, through interaction with the knowledge engineer, will generate the knowledge base pattern predicates which comprise the knowledge base 120 for the programming problem in question. The example compiler 300 is described with reference to the Rotate problem, as shown in Table B, and a correct sample solution program, as shown in Table F. In particular, the function of the example compiler 300 will be illustrated by generating a knowledge base pattern predicate which will be used to check that the "retrieve from temporary variable" step is properly implemented in the solution program in Table F.
TABLE F______________________________________Correct Sample Solution to the Rotate Problem______________________________________PROGRAM Foo (INPUT, OUTPUT);CONST Max = 100;TYPE Item = INTEGER; List = ARRAY[1..Max] OF Item;VAR PassedAsS : List;PassedAsN : INTEGER;PROCEDURE Rotate (VAR S : List; N : INTEGER); VAR Temp : Item; I : 1..Max; BEGIN Temp := S[N]; FOR I := N DOWNTO 2 DO BEGIN S[I] := S[I - 1] END; S[1] := Temp END;BEGINRotate(PassedAsS, PassedAsN)END.______________________________________
Knowledge Engineer Use of the Example Compiler
Referring to FIGS. 5(a) and 5(b), the knowledge engineer will use the example compiler 300 in the following manner. The knowledge engineer first consults the example compiler 300 into the Prolog database, as shown at block 502. The Pascal solution program, as shown in Table F, is then converted into an abstract syntax tree as shown at block 504 by the same lexer and parser used in the analytic component; that is, the lexer 114 and the parser 116, which are carried out by LEXER.ARI and PARSER.ARI, respectively.
The example compiler 300 will request a name for the knowledge base pattern predicate to be generated, which the knowledge engineer inputs as shown at block 506. In this example, the name retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop is entered in response.
The knowledge engineer can indicate that he or she is done identifying lines in the solution program, as shown at block 508. If the knowledge engineer is not done, the example compiler will branch to display the solution in menu form as shown at block 510.
The knowledge engineer will be requested to select a desired line of code from the solution program at block 512 and a desired part of the selected line at block 514. In the present example, the ":=" symbol which is contained in the assignment statement below the FOR loop of ROTATE.PAS is selected.
The example compiler 300 will request a name for the selected part, which the knowledge engineer inputs as shown at block 516. In this example, the name RetrievePtr is entered for the ":=" symbol.
The line and part selection and part naming processes (blocks 508, 510, 512, 514 and 516) are repeatedly invoked until all the desired parts are selected and named. In this example, the part "FOR" is selected and named LoopPtr, and the loop is exited by responding affirmatively to the query at block 508.
The example compiler 300 will then process the information input by the knowledge engineer and automatically generate the appropriate match instructions. The next set of steps involve the definition of node relation predicates which will be included in the desired knowledge base pattern predicate.
At block 520, the example compiler 300 will query whether the knowledge engineer is done specifying relations involving the parts previously chosen, which in this example are RetrievePtr and LoopPtr. In response to a negative answer, the example compiler 300 will display a menu which lists all the possible node relation predicates available (see Table D). The knowledge base engineer then selects the desired node relation predicates at block 522 which describe the relation between the parts previously chosen.
In the present example, the predicate below(RetrievePtr,LoopPtr) is chosen at block 522. When done specifying relations between RetrievePtr and LoopPtr, the knowledge engineer is then given the option of specifying relations between LoopPtr and RetrievePtr. In our example, no further node relation predicates are chosen, and the example compiler 300 exits from block 520.
The example compiler will display a warning message, as shown at block 524, if it detects that the knowledge engineer has input redundant node relation predicates one of the node relation predicates will be deleted in order to eliminate the redundancy. For example, had the knowledge engineer entered the node relation predicate above(LoopPtr,RetrievePtr), it would be deleted since the predicate below(RetrievePtr,LoopPtr) implies above(LoopPtr,RetrievePtr), which had been previously entered.
Finally, the example compiler 300 outputs a first version of the knowledge base pattern predicate, as shown at block 526. The retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop pattern predicate generated by the example compiler 300 in the present example is shown below:
______________________________________retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop( Retrieve.sub.-- Ptr, Loop.sub.-- Ptr) :- match( [:=,Retrieve.sub.-- Ptr, [[variable,.sub.--, [[s,.sub.--, []], [var.sub.-- modifier.sub.-- list,.sub.--, [[array.sub.-- index,.sub.--, [[1,.sub.--, []]]]]]]], [variable,.sub.--, [[temp,.sub.--, []], [empty,.sub.--, []]]]]]), match( [for,Loop.sub.-- Ptr, [[for.sub.-- assign,.sub.--, [[i,.sub.--, []], [2,.sub.--, []], [to,.sub.--, []], [variable,.sub.-- , [[n,.sub.--, []], [empty,.sub.--, []]]]]], [begin,.sub.--, [[:=,.sub.--, [[variable,.sub.--, [[i,.sub.--, []], [empty,.sub.--, []]]], [1,.sub.--, []]]], [:=,.sub.--, [[variable,.sub.--, [[s,.sub.--, []], [var.sub.-- modifier.sub.-- list,.sub.--, [[array.sub.-- index,.sub.--, [[variable,.sub.--, [[i,.sub.--, []], [empty,.sub.--, []]]]]]]]]], [variable,.sub.--, [[s,.sub.--, []], [var.sub.-- modifier.sub.-- list,.sub.--, [[array.sub.-- index,.sub.--,,.sub.--, [[variable,.sub.--, [[i,.sub.--, []], [empty,.sub.--, []]]], [1,.sub.--, []]]]]]]]]]]]]]]]), below( Retrieve.sub.-- Ptr, Loop.sub.-- Ptr).% End of retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop______________________________________
The knowledge base pattern predicate produced in this example by the example compiler 300 contains only two arguments, RetrievePtr and LoopPtr. In addition, the predicate is quite lengthy, due to the fact that it is very specific. The knowledge engineer has the option of manually reducing the size of the predicate by generalizing certain of its parts and adding variables to the argument. The final version of the knowledge base pattern predicate should thus be the same as or similar to the one generated entirely manually, which is retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6.
The FOR loop in the generated predicate specifies a FOR loop containing two specific assignment statements rather than just a FOR loop. The first step in reducing the predicate retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/2 is to generalize the node pattern for the loop. The following node pattern accomplishes this objective:
______________________________________ [for,Loop.sub.-- Ptr, [[for.sub.-- assign,.sub.--, [[LoopVarName,.sub.--, []], StartExpr, [Direction,.sub.--, []], EndExpr]], .sub.-- ]]______________________________________
The above node pattern is reduced-in size and has additional variables. If the node pattern above is unified with the one generated by the example compiler 300, the following bindings would result:
______________________________________ LoopVarName = i StartExpr = [2,.sub.--, []] Direction = to EndExpr = [variable,.sub.--, [[n,.sub.--, []], [empty,.sub.--, []]]]______________________________________
Variablizing parts of the node pattern makes the match instruction much more flexible. Furthermore, the newly variablized match instructions can be isolated in a separate predicate as follows:
______________________________________for.sub.-- loop(Loop.sub.-- Ptr,LoopVarName,StartExpr,Direction,EndExpr):- match([for,Loop.sub.-- Ptr, [[for.sub.-- assign,.sub.--, [[LoopVarName,.sub.--, []], StartExpr, [Direction,.sub.--, []], EndExpr]], .sub.-- ]]),______________________________________
By isolating out the FOR loop, a knowledge base pattern predicate that can be used in other knowledge bases where a FOR loop needs to be matched has been created. Having separated out the for.sub.-- loop/5 predicate from the retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/2 predicate, the pattern can be rewritten as it appears below. Note that parts of the node pattern specifying the form of the assignment statement have been variablized and the variables added to the list of the predicate's arguments.
______________________________________ retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop( Retrieve.sub.-- Ptr, Loop.sub.-- Ptr, ArrayName, ArrayIndex, TempVarName) :- match([:=,Retrieve.sub.-- Ptr, [[variable,.sub.--, [[ArrayName,.sub.--, []], [var.sub.-- modifier.sub.-- list,.sub.--, [[array.sub.-- index,.sub.--, [[ArrayIndex,.sub.--, []]]]]]]], [variable,.sub.--, [[TempVarName,.sub.--, []], [empty,.sub.--, []]]]]]), for.sub.-- loop(Loop.sub.-- Ptr, LoopVarName, [2,.sub.--,[]], to, [variable,.sub.--, [[n,.sub.--, []] , [empty,.sub.--, []]]]), below(Retrieve.sub.-- Ptr,Loop.sub.-- Ptr).______________________________________
The resulting knowledge base pattern predicate retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/5 is closer in form to the first clause of the predicate retrieve.sub.-- from.sub.-- temp.sub.-- below loop/6 which was generated completely manually. The only difference between the two is that retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6 was generated with the assumption that the Loop.sub.-- Ptr would be matched elsewhere and then passed into the predicate to be checked against the position of the Retrieve.sub.-- Ptr.
A further comparison of the predicate retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/5 generated with the aid of the example compiler 300 with retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6 reveals two deficiencies in retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/5. First, no accommodation has been made for Pascal programs which will not match the node patterns specified. Second, the loop is assumed to be a FOR, when, in practice, the program might use a different form of iteration (REPEAT loop, WHILE loop, tail recursion, etc.).
To remedy the first deficiency, we can add clauses to the definition of retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/5. By referring to retrieve.sub.-- from.sub.-- temp.sub.-- below.sub.-- loop/6, two more clauses are appropriate to add. One clause should handle the case where the assignment statement can still be matched, but where it is not necessarily below the LoopPtr as desired; a second clause can be added to cover the case where no assignment statement of the expected form could be found in the Pascal program analyzed. Bug-type messages, to be reported to the student, should be attached to both of these two extra clauses.
The match/1 instructions of any knowledge base pattern predicate can be replaced by a set of node.sub.-- type/2, parent.sub.-- child/2 and next.sub.-- left.sub.-- sibling/2 goals. This may be desirable if the argument, which must always be a nested list, is nested too deeply to be easily readable by the knowledge engineer, or for some other aesthetic reasons.
To illustrate, the match/1 instruction for the Pascal statement I:=1 is as follows:
______________________________________ match([:=,AssignPtr, [[variable,VarPtr, [[i,SymbPtr, []], [empty,EmptyPtr, []]]], [1,IntPtr, []]]]).______________________________________ This is equivalent to the following set of goals:
node.sub.-- type(:=, AssignPtr),
parent.sub.-- child(AssignPtr,VarPtr),
parent.sub.-- child(AssignPtr,IntPtr),
next.sub.-- left.sub.-- sibling(VarPtr,IntPtr),
node.sub.-- type(variable,VarPtr),
node.sub.-- type(1,IntPtr),
parent.sub.-- child(VarPtr,SymbPtr),
parent.sub.-- child(VarPtr,EmptyPtr),
next.sub.-- left.sub.-- sibling(SymbPtr,EmptyPtr),
node.sub.-- type(i,SymbPtr),
node.sub.-- type(empty,EmptyPtr).
To satisfy the previously discussed objective of using the most specific relations in order to facilitate the most efficient matching of patterns, the example compiler 300 utilizes the implicative relations defined in Table E above. In the present example, the predicate right.sub.-- sibling/2 is more specific than the predicate below/2, and thus is a more efficient predicate to use.
System Architecture of the Example Compiler
The architecture of the example compiler 300 is described with reference to FIG. 3. The example compiler 300 is comprised of a pattern lexer 304, a pattern parser 306, a pattern generator 308, a relations analyzer 310, and a formatter 312.
The functions of the example compiler 300 are carried out by five files of Prolog predicates,--EC.P, LEX.sub.-- PATTERN.P, PARSE.sub.-- PATTERN.P, PP.sub.-- PATTERN.P, and NODE2PATTERN.P--all of which are listed in the Source Code Appendix hereto. EC.P is a top-level Prolog file that consults the remaining four files into the Prolog database.
The lexer 114 accepts the program in text form from the computer/user interface 102 and outputs a list of tokens to the parser 116. The parser 116 processes the tokens from the lexer 114 and generates an abstract syntax tree, which is a node representative of the program entered by the knowledge engineer.
The pattern generator 308, which function is carried out by the Prolog file NODE2PATTERN.P, converts the abstract syntax tree produced by the parser 116 to a pattern which is displayed, in menu form, to the user for further modification as explained above.
The relations analyzer 310 provides the interactive function of allowing the knowledge base engineer to specify the particular node relations predicates which are to be included in the final version of the knowledge base pattern predicate being created. Finally, the pattern lexer 304, the pattern parser 306, and the formatter 312, the functions of which are carried out by the Prolog files LEX.sub.-- PATTERN.P, PARSE.sub.-- PATTERN.P, and PP.sub.-- PATTERN.P, respectively, act as a pretty printer for the Prolog predicate which formats the predicate so that the knowledge engineer can be optionally presented with an intelligible representation thereof. ##SPC1##

Number	Name	Date
4887212	Zamora et al.	Dec 1989
5059127	Lewis et al.	Oct 1991
5095432	Reed	Mar 1992
5111398	Nunberg et al.	May 1992

Method and system for interactive computer science testing, anaylsis and feedback

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

US Classifications

Field of Search

US

International Classifications

Abstract

Description

Claims

US Referenced Citations (4)

Non-Patent Literature Citations (4)

Entry
Clocksin, W. F. and C. S. Mellish, "Programming in Prolog", Third, Revised and Extended Edition, 1987.
Henry I. Braun et al., Scoring Constructed Responses Using Expert System, Journal of Education Measurement, Summer 1990, vol. 27, No. 2, pp. 93-108.
Albert T. Corbett et al., Computer-Assisted Instruction and Intelligent Tutoring Systems: Shared Goals and Complementary Approaches, 1992, Chapter 3, pp. 73-109.
W. L. Johnson, Intention-Based Diagnosis of Novice Programming Errors (Morgan Kaufmann Publisher, Inc., Los Altos, Calif. 1986).