Design of a Learning Environment in Combinatorics based on

Design of a Learning Environment in Combinatorics based on Problem Solving: Modeling Activities, Problems and Errors Françoise Le Calvez, Hélène Giroire, Gérard Tisseau, University Pierre et Marie Curie (Paris 6), LIP6-MOCAH, 104 avenue du président Kennedy, 75016 Paris - FRANCE {francoise.le-calvez, helene.giroire, gerard.tisseau}@lip6.fr Abstract. In this paper we present the design of a learning environment in a mathematical domain (elementary combinatorics) where problem solving is based more on modeling than on deduction or calculation. In this approach, we want to provide students with a presentation which is close to the natural language formulations that they tend to give spontaneously, while ensuring a rigorous mathematical reasoning. To do so, we have introduced three modeling levels: first, a mathematical formalization of the students’ intuitive process, that we called the constructive method, then a conceptual and computational model that allows mathematical reasoning as well as communication with the student, and finally a presentation consisting of several “machines”. We show that, in such a system, error detection is specific. We present an incremental mechanism of error detection. Specific knowledge necessary to detect and explain the errors is organized into a database of error schemas. The system Combien?, founded on this research, has been used by university students since 2002. Keywords. Problem solving, combinatorics, modeling of activities, the constructive method, incremental error detection, error schemas

INTRODUCTION One of the well-known learners' difficulties in solving problems is to be able to abstract concrete problems. Nowadays, Technology Enhanced Learning (TEL) can be used to help students in their solving processes. This technology offers students activities that help them to develop skills such as abstraction, modeling formalization and reasoning. The aim of the present research is to explore ways to move from standard learning in a formal domain to the design of computational tools that enhance learning. We work in a framework similar to the “didactical engineering of production” (Artigue, 1994). Some questions such as: how to structure the domain?, or how to model learners' activities? are at the bottom of this research. Our team is composed of high school mathematics teachers and of teachers and researchers in Artificial Intelligence who have been working on the Combien? project1. Our practical goal is to help students to learn combinatorics, and more particularly to allow students to train themselves in solving combinatorics exercises (i.e. counting the number of ways in which to arrange given objects while satisfying some constraints). The mathematical domain of combinatorics is very specific: on the one hand, because of its place in the school curriculum, on the other hand because of the specific reasoning necessary to solve the exercises. 1

Combien? means How Many? in French. Web site: http://www.lip6.fr/combien/

- In France, combinatorics used to be taught in the last year of high school, for scientific students. Now, it is taught in the first two years of university. Combinatorics is usually taught to prepare courses on the calculus of probabilities. But often, not much time is devoted to this course. Consequently underlying concepts cannot be explained in detail and many students have difficulties in solving these problems. - The domain of combinatorics is specific as far as the procedures of proof and modeling are concerned. In many other domains of mathematics, problem solving consists in using inference rules to get new facts or in rewriting rules to transform an expression. In combinatorics we start with a constrained system and we work with a set of objects (called configurations) satisfying those constraints, in order to calculate the number of configurations. The main difficulty is to find a suitable representation of the problem and an appropriate modeling of the solution. Thus, solving combinatorics problems needs skills to abstract the problem, to formalize it and then to reason about its formalization. From our teaching experience of combinatorics, we designed the mathematical basis of a solving method which we called the constructive method. This is what we describe in the first section of the present paper. This method has been chosen because the user can justify the numerical solution. Since the learning system that we built aims to make users learn this method, the next section presents the activities proposed to the students by the system. To realize the system, to ensure a rigorous mathematical reasoning, we chose to model knowledge of the domain, the problem and the solution as shown in the “Internal Representation” section. These models, underlying the interfaces, are close to natural language formulations that students spontaneously give. Fischbein and Grossman (1997; 2004) show that in solving combinatorial problems “intuitions are always based on certain structural schemas”. By using students' usual formulations we hoped to remain close to their own schemas. Error detection is very important in a pedagogical system. In the “Incremental Error Detection” section we discuss the notion of error and the time of feedback; we show the characteristics of error detection in a system whose solution looks like programming. Then we present the incremental error detection we implemented and discuss its benefits. The training system named Combien? that we built has been used since 2002. The first two years, experiments were conducted with various types of users and various kinds of protocols. In 2004 and 2005 it was used by 2nd year university students in mathematics as part of their curriculum. We present the way in which it has been used in the “How Combien? has been Tested and Used” section. Finally we discuss how this research can contribute to the design of problem solving learning environments.

A SOLVING METHOD FOR COMBINATORICS EXERCISES: THE CONSTRUCTIVE METHOD In the domain of mathematics, proposed problems are often solvable by a deductive method: starting from given facts, considered as a set of axioms, the learner can apply inference rules to get new facts and thus find a way to the property to be proved or to the result of the requested calculation. In order to evaluate a learner’s activity, the system can observe which rules are tried, whether they are correctly applied, whether the learner reaches the goal effectively, and if the way to the goal is a good one. During resolution the system can guide the learner at each step, for example by giving hints about the

relevance of the newly obtained facts, by detecting dead ends, by trying to guess the followed plan, and by proposing sub-goals (Abraham, Crawford, Lesta, Merceron, & Yacef, 2001). While this process is promoted in such domains as transformation of algebraic expressions (Nicaud, 1994) and proof of geometric properties (Matsuda & VanLehn, 2005; Spagnol, 2003), it does not apply to all domains, in particular to combinatorics. As Papert (1980) said “I observe that the combinatorics problem is really a problem in programming (rather than in algebra or in formal logic)”.

A difficult domain: combinatorics Mashiah-Eizenberg and Zaslavsky (2004) recall that “Combinatorics is considered one of the more difficult mathematical topics to teach and to learn”. Godino, Batanero and Roa (2005) emphasize that: “This author (Roa) gave a questionnaire with 13 simple combinatorial problems to a sample of 118 students majoring in mathematics (4th or 5th year of university study), who generally found it difficult to solve the problems (each student only solved an average number of 6 problems correctly)”. In combinatorics (counting the number of ways in which to arrange given objects in a prescribed way), this unsuitability is apparent in the students’ reactions to the problems: “I can’t represent the problem”, “I don’t know where to begin ”, “I understand the solution given by the teacher, but I don’t understand why mine is wrong”, “I’m proposing a solution but I have no way of finding out if it is right or wrong”. We interpret these reactions as representational difficulties: the solving process does not result mostly from a clever chaining of inferences or calculations, but from the elaboration of a suitable representation and from the transformation of one representation into another, equivalent one. The importance of representations in problem solving is studied for example in (Abidin & Hartley, 1998; Cox & Brna, 1995; White & Frederiksen, 1990; Parkes, 1994; Kohl & Finkelstein, 2006; Koedinger & Nathan, 2004). Let us take an example of a combinatorics exercise which we will call listExercise12: “How many 5-letter words are there with exactly one occurrence of the letter a?” This exercise is typical of an exercise given to twelfth-grade students in a scientific class. Some students are able to solve this problem (see Fischbein & Gazit, 1988, for a study of the combinatorial capacity in children and adolescents) but they usually give only the numerical solution, and if you ask them to justify their answers, their answers are often something like this: “I have 5 possibilities for a, and when I choose a, I can put any letter other than a in the remaining positions. Thus I have 5*254 possible words.” (see Biryukov, 2004, for different strategies of students' solving). The numerical result is right, but the justification is not a demonstration of the result and it is not precise enough: what is a “word”? what does “5 possibilities for a” correspond to? what does it mean when the student says “I choose the letter a”? what are the remaining positions? how can it be proven that the carried out operations answer the question? Using mathematical language is a way to be more precise and to be able to make a proof. The use of an expression such as “remaining positions” suggests that a word can be modeled as a set of pairs (position number, letter). For example, the word “taste” is seen as the set of five pairs {(1,t), (3,s), (5,e), (4,t), (2,a)}. Such a set is a mapping from the position set to the letter set. The previous problem

2

To facilitate the reading of this article, all the wordings of the exercises are listed in Appendix 1.

can be modeled as: Let A and P be two sets: A is the alphabet and P is {1, 2, 3, 4, 5}. How many mappings from P to A are there such that the letter a occurs only once in the second place of a pair? The expression “How many … are there” can be translated by “What is the cardinal of the set of…” This highlights a fundamental concept of combinatorics: the set of elements to be counted SeC defined as the set of elements of a Universe U (here the set of the mappings from P to A), satisfying some constraints. The exercises that we consider can all be expressed in the following way: given a set or sets (here, the set of positions, and the alphabet), count within some universe of configurations (here each configuration is a mapping from P to A and the universe is the set of all these mappings) the elements that satisfy some constraints (here the injective mappings whose range contains the letter a exactly once). Solving a combinatorics exercise consists in counting the cardinal of SeC.

The constructive method It is possible to count the cardinal of SeC without enumerating its elements; it can be done by reasoning about the way of enumerating. It is possible to create an algorithm which is a constructive definition of a configuration and thus enables to enumerate the elements of SeC. This algorithm is named a construction. Therefore an efficient method of counting consists in analyzing it in order to foresee how many elements it will build, without running it. We called this method “the constructive method”.

The enumerating algorithms Each instruction of the algorithms that we consider defines an object. Some of these instructions are non-deterministic and allow the expression of the equivalence of loops or recursiveness. Figure 1 presents an example of construction for listExercise1 about the 5-letter words containing exactly one letter a.

Fig.1. A construction example.

Running this construction will, in the end, give an element of SeC (configuration), which is obtained randomly because of the two non-deterministic instructions (numbers 4 and 8). Interpreted in this manner, it is not an enumerating algorithm but an algorithm for building one element. For that

reason, it is easy to understand and to define. However, it could be seen as an enumerating algorithm that gives all the elements of SeC, if it was run as a logic program (Kowalski, 1974), exploring systematically all the possible answers to the non-deterministic instructions. Our method consists in using the algorithm at a meta level (Pitrat, 1990): the algorithm is not to be run, it is an object to study. In our example, let us reason about this construction for counting the number of elements of SeC which can be built: steps 1, 2, 3, 5, 6, 7, 9 are deterministic. The number of different ways to run steps 4 and 8 are 5 and 1*254 respectively. The cardinal of SeC is the product of the number of possibilities for each step i.e. 5*1*254. Such a calculus is valid only if the construction is injective, i.e. the construction cannot build a given element in several ways. Let us give an example of construction which is not injective. In the exercise setExercise1: “How many 3-digit sets is it possible to form with exactly two odd digits?” a possible construction, which is not in accordance with the constructive method, is given in Figure 2.

Fig.2. A possible construction for setExercise1.

If this construction is run, it produces 12 configurations, while the cardinal of SeC is 6. Here, instructions 4 and 5 take their elements in the same set; thus the number of configurations is doubled. With the constructive method a valid construction is obtained by merging instructions 4 and 5: choose two elements from O. Thus, running the new construction will produce only six configurations. The number of possibilities for the new instruction is 3, and the number of possibilities for instruction 6 is 2. In such a construction we applied the multiplicative principle, which is the fundamental principle taught in combinatorics. To apply this principle is a meta-constraint i.e. a constraint about the algorithm itself, considered as the structured object, and not about the configurations. The metaconstraint is that two constraints must apply to two disjoint sets. Let us now consider a more complex example: setExercise2: “With a 32-card pack, how many thirteen-card hands is it possible to form with at least 1 heart, exactly 4 black cards and exactly 4 aces?” If the two steps: “Choose 4 aces” and “Choose 1 heart” are present, the multiplicative principle cannot be applied. The meta-constraint is not respected because the ace of hearts belongs to the set of hearts and to the set of aces.

Problem classes and solving schemas In fact, the above-described program has a structure: it includes declarations of fixed sets (A, P, Aa, CAa) necessary to the construction, non-deterministic instructions used to build pieces of the result, and finally the building of the result R as a union of the pieces. Moreover this structure naturally

results from a plan according to which it is possible to build a word (R) as a union of mappings (Ma, CMa). But asking a beginner to invent such a structure and such a plan from scratch is too demanding. Experts have their own representations (Kook & Novak, 1991). For an expert, this structure and this plan correspond to a classical resolution schema associated with a certain problem class: building a word of a given size with x1 occurrences of letters taken from a category c1, x2 occurrences of letters taken from a category c2, and so on, with disjoint categories. Experts know different classes and their related resolution schemas, and this helps them to solve classical problems: they first analyze the problem to identify its class and then they apply an associated resolution schema (Chi, Feltovich, & Glaser, 1981; Simon & associates, 1986). In fact, using a classification to solve problems is a general method. Dubois (1984) proposes a general classification for combinatorial problems, but this does not exactly cover the problems that we consider and it was not conceived to be used in a learning environment. Batanero, Godino & Navarro-Pelayo (1997) also recall that the combinatorial problems posed for the students can be reduced to a small number of standard problems; the difficulty is to recognize the type of the problem whatever the wording and the objects concerned – cards, tokens, dice... We have defined our own classification of the problems of the domain. It allows solving most of the problems posed at the considered school level and takes into account more constraints than Dubois's classification. Our classification, which comprises twelve basic classes as well as composed classes obtained by applications of operations on basic classes, is based on the solution schema of the problem (Guin, Giroire & Tisseau, 1995). For example, exercise listExercise1 belongs to the listConstruction class because the result (a word) can also be seen as a list of letters; setExercise1 and setExercise2 belong to the setconstruction class because the results are respectively a 3-digit set or a card hand, i.e. a set.

WHAT KIND OF LEARNERS’ ACTIVITIES? We propose some activities for the learner based on this method and classification. These activities do not consist of counting but in describing, because we want to insist on representation problems. Before asking “how many?”, it is necessary to first ask “what?”, in order to give a precise representation of the configurations that must be counted. We built interfaces (which we called “machines”3) which help the students to build an enumerating algorithm and to reason about it. These interfaces are designed in such a way that students can fulfill the instructions of the algorithm. In order to make them easier to use algorithms are written using natural language formulations close to the ones that students spontaneously give (Biryukov, 2004). For example, the enumerating algorithm of listExercise1 becomes: 1. I want to build a 5-letter word (list of 5 letters, set of 5 pairs {position, letter}) 2. Satisfying some constraints 3

We use the word “machine” as a metaphor to name an interface bound to a class of problem. With their answers, the students configure a machine able to randomly draw configurations (for example, 3-letter lists with 1 occurrence of the letter a). Thus, the constructive aspect of the solution is stressed and students can test themselves if the machine reacts as they expect it to, using the “Drawings” button described further.

2.1. one position is filled with the letter a 2.2. the other positions are filled with letters different from a The first sentence corresponds to the definition of the set of elements including the elements of SeC. We have named this set Universe, in reference to probabilities. The block of steps from sentence 2 defines the constraints on the elements of the Universe, such that the elements belong to SeC. Therefore the student must reason about each step to express the number of elements which can be produced. This example belongs to the listConstruction Machine. For each class of problems, we have built a specialized machine. Each machine is based on the specific solving schema of its class. Universe and constraints are the underlying concepts that are present in all the machines. Each machine leads the students to define their enumerating algorithm and their reasoning. At each step of the algorithm, the machine tests the validity of the solution which is being built, using an incremental error detection which will be described in the “Incremental Error Detection” section. This student’s activity is similar to the one proposed by SQL-Tutor (Mitrovic, 1998). SQL-Tutor is an Intelligent Tutoring System (ITS) where the learner’s activity consists in writing SQL requests translating an informally asked question. The learner knows the conceptual schema of the associated database. When the SQL-tutor asks: “Write a SQL request which, if it were executed, would provide all the data satisfying some properties”, our system Combien? asks “Write a construction which, if it were executed, would provide all the configurations satisfying some properties”. But in Combien?, we add “Now, reason about this construction (without executing it), and infer the number of configuration-solutions”. The student expresses interactively the construction and s/he is guided by the machine. But the construction will be expressed in a formal language which will have the same role as SQL in SQL-tutor. We tried this possibility in a first prototype but we rejected it because it was too far from the usual formulation of the student and consequently too difficult to use. On the contrary, in SQL-Tutor, SQL is the very subject of the learning.

Machine description The formulation of the algorithm via the machine has been chosen to avoid a level of abstraction that is not familiar to students. Students are not necessarily aware they are describing an enumerating algorithm but only that they are creating a generic element of the set SeC. A machine appears on the screen in a window as a form including standard interaction elements (widgets): buttons, menus, fields. Each machine concerns a particular problem class, but all machines have the same use pattern: students select a problem to be solved, they give a model of this problem and then they give a construction of a solution, i.e. a program. Problems are stored inside each machine, not only as texts, but also in an internal representation. The interface appears in a window which is composed of several frames. Each frame is added on the fly of the steps. Figures 3 to 9 present different pieces of snapshots of the listConstruction machine when listExercise1 is being solved. Students select the text of a problem in natural language by a selection device (a menu and a text field). They must then specify some elements in order to model the problem. For example, for the problems of the listConstruction class, to define the universe, two sets (referentials) are necessary, the set of positions and the set of associated elements (second element of the pair). To define the set of positions, students just have to indicate the size of the list. They choose the second set from a

predefined menu. The system associates to each answer an internal modeled object. In this type of exercise, they must also specify whether the list may have several occurrences of a letter or not (the repetition of an element is either “allowed” or “not allowed”).

Fig.3. Selection of an exercise.

Fig.4. Definition of the universe.

Thus the first modeling stage is very short. Yet, it makes students aware of representation choices. Moreover, it allows the machine to take the above selection into account in order to present only pertinent choices in the subsequent steps (it knows for example that a letter can be a vowel or not, or that a digit can be even or odd). This example also shows how the specialization of the machines saves the student from deciding all aspects of the model: here the machine itself indicates that lists are being built. In other problem classes, it would be sets or mappings. The student then describes his/her construction in the form of an instruction sequence. Each of them is built as follows (see Figure 5). The presentation is like a text written in natural language, with blanks to be filled. The syntax and the type of words suggest the role of each element, therefore it is not necessary to label them with abstract concepts like attribute, comparator, value. In the internal representation, however, these labels exist and the elements, that look like strings, are in fact composed objects (letter is an instance of the Attribute class, and is related to its possible values and to the sets to which it can be applied). The item lists of the menus are dynamic: for example the last menu to the right (possible values) will be updated when the student selects the attribute letter. The machine controls the dialogue in several ways. First, it reacts to the learners’ selections by enabling or disabling some widgets in the window and by dynamically changing the contents of the menus. The aim is to restrict the learners’ possibilities in order to guide them through their progression

and to prevent mistakes caused by inconsistencies or confusions without pedagogic interest. However, the machine leaves them the possibility to make mistakes concerning combinatorics concepts. Sometimes it is only an impossibility linked to the concrete objects of the exercise (card-packs, tokens, letters): “I cannot select three different vowels, because the cardinality of the subset satisfying this constraint – the letter is a vowel and the letter is not in {a, e, i, o} – is less than three”. But the most interesting errors are the violations of the basic principle of counting: “I refuse to execute the instruction ‘select two vowels’ because you already asked ‘select three vowels’ in a preceding instruction. If I accepted, certain configurations would be generated more than once, for example …”. The machine is specialized in a particular program schema, so it possesses the necessary knowledge to make this diagnosis. See section “Incremental Error Detection”.

Fig.5. One stage of definition of the construction.

At each stage, when the stage belongs to a correct solution, students must give the number of elements which can be built by this instruction using arithmetic expressions with possible combinatorics notations (see Figure 6). Then the instruction is added to the list of stages in the stage field so that students can always visualize the state of the building process (see Figure 6). Moreover, at any time, students can look at an example of the element of the solution they are building, using the “drawings” button. To build this element, the machine executes all the instructions already given. Figure 7 shows the result of a drawing after the first stage of the solution visible in Figure 6. When the second stage of the solution is validated, asking for a drawing would display a union of a drawing bound with the first stage, and a drawing bound with the second stage. The resulting configuration could be for example:{(4,a), (1,b), (2,z), (3,b), (5,v)}, which corresponds to the word “bzbav”. When all the stages are expressed, students indicate that the construction is ended. They have built a generic element of SeC. The machine shows a recapitulative form of their solution which is a justification in the form expected by their teachers (see Figure 8).

Fig.6. An expression of the number of possibilities.

Fig.7. Result of a drawing after the first stage of Figure 5.

To show the mathematical concepts that underlie this solution, a second form of the solution is presented to the student (see Figure 9). For them, to express their solution in a mathematical language instead of their usual language is a long time process. But this learning process is initiated here and has to be strengthened. We have designed another system centred on mathematical concepts (not only combinatorics concepts), in which students can refine their notions of these concepts (definition, examples, counter-examples).

Fig.8. Recapitulative form of a solution.

Fig.9. A more mathematical justification.

INTERNAL REPRESENTATION4 The above interfaces are based on an internal representation implementing a model of the domain and of the problems. A machine must not only build configurations according to the learner’s instructions but also reason about these instructions, for example to satisfy that they respect the fundamental counting principle mentioned above. It must include a computational model of the domain that allows mathematical reasoning. On this point, we agree with Nicaud (1994) when he stresses the importance of models explicitly described at knowledge level (defined by Newell (1982)), and the necessity to elaborate a “resolution theory” of the domain. Despite the anticipated variety of the machines, this model must be the same for all machines, firstly to make the implementation easier and above all to reflect the internal consistency of the domain. It must enable the representation of not only mathematical concepts, but also the problems and the learner’s activity. We have defined such a model as an object-oriented conceptual model, a collection of classes describing objects with attributes and with relations between the classes. The higher level classes are Problem and Construction, thus reflecting learners’ activity: learners are given a problem and they must represent it and solve it by providing a construction. Each machine represents a certain construction type associated with a problem type. The definition of the conceptual model is based not only on the logical structure of the main concepts (problem, construction), but also on a concern that students can use a representation close to their usual language. This has been made possible by the fact that the underlying theoretical method itself (the constructive counting method) has been elaborated from the students’ usual answers. To compensate for the excessive generality of the mathematical language, where every structure can be assimilated to a set, we have assigned different roles to the structures involved in counting, and particularly to those involved in the constructive method. For example, the sets of objects used to form configurations have been called referentials (a pack of cards, the letters of the alphabet, tokens) and the set of configurations in which the solutions are selected has been called universe (it is similar to the possibility space in the probability theory). This vocabulary and these concepts do not usually appear in combinatorics courses, but they have proved helpful. A referential is the union of subreferentials, each of them being defined as a set of couples attribute-domain. In what follows, the modeling of the concepts is instantiated using two examples of exercises: listExercise1 (see Appendix 1) and setExercise3: With a 32-card pack, how many 5-card hands is it possible to form with 2 spades and 2 hearts? The model of referential is instantiated for a 32-card pack in Figure 10. The “suit” attribute (for a card-pack) derives its values from the domain composed of the values hearts, spades, diamonds, and clubs. A domain is defined as an enumeration of values or as an interval of numerical or alphabetical values. To each attribute, we can associate predicates applying to values (for instance the “even” predicate applies to integers).

4

In all the figures of this section arrows have the same meaning as the one they have in graphical representation of object language. The wide arrows express the inheritance between two concepts and the fine ones a relation from a concept to another as shown in the caption of Figure 10.

Fig.10. The Referential class and the 32-card pack instance.

There are 2 types of universe: the PartUniverse (used to model a set of parts of a referential, for instance the set of the 5-card hands from a 32-card pack) and the AssociationUniverse (used to model a set of mappings from one set into another, for example the set of 5-letter words, each word seen as a mapping from the set of 5 positions into the set of letters), see Figure 11.

Fig.11. Universe modeling.

Some concepts do not directly concern mathematical objects (sets, elements, universe) but the means of expression offered to the learner. This introduces a metalevel, which we discuss below.

Metamodeling To communicate with the machine, learners must speak of objects included in referentials, such as playing cards and tokens that can be colored and numbered. It is often heard that combinatorics does not require knowing the nature or the properties of the involved objects, because the only goal is to count them. This is not exactly true. In order to count configurations, including playing cards, it is necessary to know that each card has a suit and a value, and what the possible values of these attributes are. Likewise, it is necessary to know what an even number is or what it means for a letter to be a vowel. The interface must therefore offer the learner some means of expression to refer to these objects, these attributes and these properties, and the conceptual model must include the related concepts. In fact, the only important aspects are that the objects have attributes, that these attributes take their values in predefined lists and that it is not necessary to interpret or decompose these values: they are merely atomic. However, these values can have unary properties (a number can be even, a letter can be a vowel), and they can be compared one to the other. We have restricted the representation of objects to the modeling primitives that are close to those of the relational model for databases. To define a subset of a set of objects, learners can use a declarative selection formula. The set of spades in the pack can be designated by: “the cards whose suit attribute has the value spades”. This concept of selection simplifies the constructions that learners must write. Instead of defining in advance the auxiliary sets that they will need for their construction (and to do it for example with Cartesian products, which is not very natural), they can introduce them only when they need them, as a selection, and without naming them. This comes close to a formulation in natural language such as: “I want two cards whose suit is spades”. Students can introduce such a selection formula, called filter in the model. It is a conjunction of properties, each of them being a comparison, (the suit = spades), a membership (the suit is in {spades, clubs}), or an assertion using a predicate (the suit being red), see Figure 12.

Fig.12. Filter modeling.

Finally, our choice consists in introducing a metalevel: instead of including predefined classes (e.g. the Card class, the Token class), we explicitly represent a representation formalism. The model

includes, for example, the classes Attribute, Predicate, Domain, Comparison and Comparator. One benefit of this approach is to allow teachers (or even students) to introduce new types of objects without having to modify the conceptual model or to program the computer. Through the interface, students use this formalism to express their solutions, but the presentation hides the details of the formalism, as was shown in the previous section “What Kind of Learners’ Activities?”

Problem modeling This formalism is used to model the problem. For each exercise, a wording in natural language is stored as well as an internal representation (class Problem). A problem is defined by a universe describing the type of configurations (for instance: the set of all possible five-card hands) and a set of constraints defining the relevant configurations (for example: the hands including two spades and two hearts). Three classes of constraints are defined: NumberConstraint, RestrictionConstraint, DistributionConstraint see Figure 13. An example of NumberConstraint is “with at least 2 elements whose suit is spades”. An example of RestrictionConstraint is “the letters in positions 1 and 3 are vowels”. An example of DistributionConstraint is “with exactly 2 cards of the same suit and 3 cards of another suit and 2 cards of yet another suit”.

Fig.13. Constraint modeling.

Construction Modeling In the constructive method, the solution of a problem is composed of a universe (class Universe) and a construction (class Construction). There are 2 types of constructions corresponding to the two types of universe: PartConstruction and AssociationConstruction. An example of partConstruction is: “choose 2 cards whose suit is hearts and 2 cards whose suit is spades, the last one is neither hearts nor spades”. An example of associationConstruction is: “choose 1 place, fill it with the letter a, and then fill the other places with letters other than a”.

A construction is composed of subConstructions, so that the final construction (in the setExercise3 example: a 5-card hand, in the listExercise1 example: a 5-letter word) is the union of the sets given by the subConstructions (2 hearts, 2 spades, 1 neither hearts nor spades; 1 letter a, 4 letters other than a).

Fig.14. Construction modeling.

For each exercise the system has a complete model of the exercise (class Problem) and an associated solution (class Solution). For each exercise, there exist different right constructions. The set of constraints can be defined in different manners. For example, the setExercise4: “With a 32-card pack, how many twelve-card hands is it possible to form with at least seven hearts, exactly 4 aces, 2 spades and nothing else?” has distinct right constructions. Fig. 15 shows two of these possible constructions.

Fig.15. Two possible constructions for setExercise4.

The nature of the solutions induced by the constructive method and our modeling led an error management which displays some particular features that we present below.

INCREMENTAL ERROR DETECTION Our system lays the emphasis on the detection of students' errors, on their analysis, and on the generation of explanations facilitating a motivated learning. The pedagogical assumption is that motivation for understanding and learning is strong when an error is detected (Borasi, 1996; Hirashima, Horiguchi, Kashihara, & Toyoda, 1998). In this context, the meaning of the words solution and error has to be accurately defined.

Error and feedback Usually speaking, in mathematics an error is the statement of an assertion whose “truth value” is false (2+2=5) or of an erroneous application of a theorem (using “ab