Cognitive Tutor Authoring Tools 2.5 > Using the Tools > Example-tracing Tutors > GeneralizeYou can generalize a complete graph to account for various problem-solving strategies, as well as a varieties of student input and step order. By generalizing, you're adding flexibility to a single graph structure to allow for a greater variety of student behavior.
Generalizing a behavior graph enables you to:
Specify a range or set of student input values to match on a given step;
Enable the tutor to perform some steps;
Constrain the order in which steps should be performed by the student.
In an Example-tracing Tutor, each action that a student performs is compared by the tutor against the set of potential actions described in the graph. Specifically, the tutor compares the student's 'selection' (widget), 'action' (interaction type), and 'input' (entered value) with those on the links of the graph. Whether this comparison is against all links in the graph or a specific subset of links depends on the graph's ordering constraints (see Section 3.2.3, “Ordering Constraints”).
You commonly edit student-input matching to match a wider range of student input (i.e, beyond the input you demonstrated), but you can also generalize matching on widget selection and action.
To edit student-input matching:
Click a link's label in the graph.
Select .
When CTAT compares a student action with that defined on a link, it can do so precisely (an exact match), or by another method (eg, a regular expression, range, wildcard, or any value). The type of comparison is specified on each link in the graph. By default, the type of comparison is an 'exact' match. Other types of input matching can be specified for a link:
The default matching type. Requires that the student's selection, action, and input match exactly with that specified on the link.
Any input value for the specified selection and action is considered a match.
A value within the specified numeric range is considered a match. Includes the minimum and maximum values (eg, 0-100 would match inputs of 0, 2, 10.12, or 100).
A value that matches the wildcard pattern is considered a match. A wildcard * denotes any number of characters. Special characters such as {, \, or & should be avoided—for these, use a regular expression match. A wildcard expression can be used for selection, action, and/or input.
Example 1: "*_text" would match "_text", "this_text", or "123abc_text".
Example 2: "abc*xyz" would match "abcxyz", or "abc123xyz".
A value that matches the regular expression is considered a match. Uses the Java regular expression engine. A regular expression can be used for selection, action, and/or input. Regular expression matching is the most powerful type of matching in CTAT.
Below are six examples that illustrate some of the regular expression conventions. For a complete reference and tutorial, see Sun's Java Regular Expression Lesson.
Example 1: The regular expression ^cat$
would match 'cat', but not 'a cat', 'cat one', or 'Cat'; the
'^' character specifies beginning of a line, and '$' specifies
end of a line.
Example 2: The regular expression animal.
would match 'animals' or animale', but not 'animal' or
'animales'; the '.' character represents any single
character.
Example 3: The regular expression [THK]im
would match 'Tim', 'Him', or 'Kim', but not 'Jim'; any single
character from the set of characters between the square
brackets can be used in the match.
Example 4: The regular expression a{3}
would match 'aaa' or 'aaaaaa' (it would match this twice), but
not 'aa'; the number between the braces specifies the number
of times the preceding character must occur to match.
Example 5: The regular expression .*hello
would match 'hi hello', 'xhello', or 'hello'; the '*'
character represents zero or more occurrences of the preceding
character, and '.' represents any character.
Example 6: The regular expression \d\w\W
would match '0z!' or '09@', but not 'b1+' or '4!!'; \d
represents a digit (0-9), \w represents a word character
(a-zA-Z_0-9), and \W represents a non-word character.
Steps in a behavior graph can be either student-performed (steps the student should perform) or tool-performed (steps that the tutor itself should perform). While a student-performed step specifies behavior the student should perform while using the tutor, a tool-performed step specifies an action that the tutor software will perform on the interface. Tool-performed steps are therefore powerful links that can be used to complete problem-solving steps, make changes to the student interface such as hiding or showing a widget, or perform other actions that you specify.
By default, demonstrated steps are stored in the behavior graph as correct steps that a student should perform when using the tutor. Steps such as these have an actor of student; that is, they are performed by the student. For steps where the tutor performs the step, the actor is the tool itself—a tool-performed action.
To specify a tool-performed action:
Create a new link (optional) - while in Demonstrate mode, demonstrate a step in the student interface. For steps that cannot be demonstrated (e.g., hiding an interface widget), create a blank step in the graph by right-clicking a node in the graph and choosing .
(Windows) or Control+ (Mac) on the action label of the link in the graph for which you'd like to specify a tool-performed action.
Select .
To the right of Actor, select Tutor (see Figure 2.2, “Specifying a tool-performed action”).
![[Note]](images/note.gif) | Note |
|---|---|
Tool-performed actions can only be specified for links where the matching type is Exact Match. |
A tool-performed action link in a graph is activated by the tutor whenever the state before the tool-performed link becomes the current state. In an ordered group of links, this process is intuitive: when the state preceding the tool-performed action link becomes the current state, the tool-performed action link is then activated. Slightly less intuitive is that this criterion—that a state with a single outgoing tutor-performed action link becomes the current state—applies for unordered groups of links as well (see Section 3.2.3, “Ordering Constraints” below).
In a tutorable activity, you may want to specify which problem-solving steps come before other steps. In what order (if any) should the correct steps be completed by the student?
You can specify ordering constraints in CTAT by grouping steps, and specifying whether each group of steps can be completed in any order or sequential order. In addition, you can nest groups of steps. Using these basic tools, you can construct complex step-ordering constraints in your tutor.
The most basic example of an ordering constraint is when all steps in a problem or activity make up a single group of steps and that group is either ordered or unordered. When you create a new behavior graph, all steps are considered part of this group by default.
To view and edit ordering constraints
Display both the and windows by selecting them each from the menu .
To create a group of steps (links):
Select links from the behavior graph by holding CTRL or SHIFT and clicking each of the links (the arrows). (Alternatively, you can click and drag to draw a bounding box around the desired links.)
In the , click . Enter a name for your group.
Traversal Count (optional)
To add or remove links from a group:
In the , select the group to modify.
Select links in the behavior graph to add or remove.
In the , click .
In the , you can also a group, a group, or choose whether its should be visualized in the behavior graph ().
| Note |
|---|---|
Deleting a group places its links in the group above it; it does not delete steps from the behavior graph. |
A group of steps is either ordered or unordered.
The student has to perform the entire series of steps in the order they appear in the graph, from the start state node toward the final "done" step, for the problem-solving behavior to be considered correct.
The student can perform the steps in any order for the behavior to be considered correct.
Ordered and unordered groups are visualized in the current behavior graph as rectangles and ovals, respectively.
A group of steps is either "reenterable" or "not reenterable". "Reenterable" means that once the student starts working on a step in the group, the student may "leave" that group of steps to work on others, returning to it (reentering it) later. If a group is "not reenterable", the student must complete that group of steps once she starts it.
Another way of thinking about "not reenterable" is the phrase "you start, you finish": if you start working on this group of steps, you have to finish working on all if them before you can move on.
Experiment with ordering constraints in your tutor, modifying the ordered/unordered and "reenterable" settings for each group.
Try combining ordering constraints with optional steps, formulas, and/or other types of student-input matching.
You can set a mimum and/or maximum number of a times a step should be performed by a student. CTAT refers to these events as "traversals"―that is, a successful match, by the tutor, on a student's action.
By default, the minimum and maximum traversals for a step are both set to "1": the student should perform the step once, but not more than once. You can use this feature to designate a step as optional by setting its minimum required traversals to "0".
Minimum and maximum traversals can be set on any correct or suboptimal-action step in an example-tracing tutor.
To set minimum and maximum traversals:
Click a link's action label in a behavior graph and select .
Modify the values and press .
Test your tutor to see if the change has the desired effect on your tutor's behavior.
