Exemple d'une simulation argumentée pour l'apprentissage de Prolog

Dessalles, J-L. & Meyers, P. (1993). "Exemple d'une simulation argumentée
pour l'apprentissage de Prolog". In M. Baron, R. Gras & J-F. Nicaud (Eds),
Environnements interactifs d'apprentissage avec ordinateur. Paris :
Eyrolles, 147-157. Exemple d'une simulation argumentée pour l'apprentissage de Prolog
Jean-Louis Dessalles
Telecom-Paris - 46 rue Barrault - 75634 Paris Cedex 13
Tel.: (1) 45 81 75 29 - Fax: (1) 45 81 31 19 - E-): dessalles@enst.fr Pascal Meyers
Université Catholique de Leuven (KUL)
Département d'Informatique RESUME : L'étudiant qui cherche à acquérir un savoir-faire, ici la maîtrise
de Prolog, a aussi besoin de connaissances conceptuelles. Pour répondre à
ce type de besoin, nous avons développé un système qui permet à l'étudiant
de simuler l'exécution de son programme Prolog, mais qui lui offre aussi la
possibilité de soumettre ce programme au regard critique de savant 3. Ce
dernier système a été conçu pour soutenir une argumentation avec
l'étudiant. Il est utilisé ici pour critiquer la justesse et l'efficacité
du programme écrit par l'étudiant, ce qui permet à celui-ci de corriger
d'éventuelles fautes conceptuelles. L'étudiant peut ainsi faire tourner son
programme et observer son exécution, pour ensuite "discuter" de ce qu'il a
écrit avec savant 3. Nous abordons la question de savoir s'il est possible
et souhaitable d'étendre ce qui n'est pour l'instant qu'une maquette à des
situations réelles (par ex. programme Prolog complexe) et à des sujets
quelconques (économie, architecture de réseau, etc.).
1. Le rôle de la critique dans l'apprentissage de savoir-faire Contrairement à la plupart des produits d'assistance à l'enseignement, qui
visent à faciliter l'acquisition de savoir-faire, le développement de
savant 3 a été motivé au départ par le souci d'enseigner des concepts,
(cf. [dessalles 1990]). Dans certaines situations, en effet, l'étudiant est
supposé acquérir des connaissances de nature conceptuelle (par exemple en
biologie moléculaire ou en histoire). En observant les connaissances
échangées dans les conversations naturelles [dessalles 1992b], nous avons
pensé que l'argumentation était un bon moyen d'enseigner des notions
nouvelles. savant 3 est ainsi conçu pour argumenter avec l'étudiant en
utilisant une stratégie simple : le système essaie de déceler une
contradiction logique dans le discours de l'étudiant, et ce-dernier doit
donc faire des déclarations qui soient cohérentes du point de vue du
système, au besoin en révisant certaines d'entre elles [dessalles 1992a]. savant 3 a été appliqué à des contenus comme la théorie des systèmes, les
communications analogiques et numériques. Dans chaque cas, il s'agissait
d'enseigner des connaissances de nature conceptuelle : notion de filtre,
transformées de Fourier et de Laplace, interférence entre symboles, etc.
Bien que la majeure partie de l'enseignement à telecom-Paris soit consacrée
à l'apprentissage de notions, nous nous sommes posé la question de savoir
si savant 3 pouvait être utile lors de l'acquisition d'un savoir-faire
comme la programmation. Certes, nous faisons une distinction qualitative
très nette entre concepts et savoir-faire [Dessalles 1990], [Inhelder &
Piaget 1979], [Ohlsson 1991], [Sleeman 1989]. Mais il apparaît clairement
qu'ils sont liés lors de l'accomplissement de tâches inhabituelles. Nous sommes donc partis de l'idée maintenant bien établie que de nombreuses
erreurs lors de l'accomplissement d'une tâche non maîtrisée sont la
conséquence de fautes conceptuelles (misconceptions) [Stevens et al. 1979],
[Sleeman 1982], [Self 1992]. Prenons l'exemple qui a servi de base au
développement de notre maquette de simulation argumentée : placer des
"cuts'" aux bons endroits d'un programme Prolog constitue indéniablement un
savoir-faire. La connaissance conceptuelle associée (un cut inhibe toutes
les alternatives rencontrées depuis l'appel de la clause dans l'arbre de
résolution) est insuffisante dans la pratique pour que le débutant place
des "cuts" là où ils sont utiles. Mais elle est nécessaire, car il est
difficile d'imaginer que le programmeur débutant trouve des indices, par
exemples syntaxiques, pour placer correctement des cuts dont il ne
comprendrait pas l'effet. De plus, des versions erronées de cette
connaissance conduisent à des erreurs de placement : par ex. celui qui
croit que le cut rend déterministes les buts (goals) qui le suivent placera
des cuts trop tôt au sein d'une clause. Il existe plusieurs systèmes dont l'objectif est d'apporter un diagnostic
ou une critique de type conceptuel sur un programme informatique qu'un
étudiant vient d'écrire. Par exemple PROUST [Johnson & Soloway 1987], pour
l'apprentissage du Pascal, peut introduire le concept de "test sentinelle"
dans son analyse du programme de l'élève. Nowé et Jonkers [1991] disent
utiliser des "concepts abstraits de programmation" pour formuler des
diagnostics de haut niveau (en Lisp ou Pascal). Dans Lisp-Tutor [Anderson
et al. 1989] les diagnostics utilisent des concepts comme "variable de
comptage", "communication d'une valeur d'initialisation à une fonction".
Intelligent-Prolog-Tutor [Lee 1991] signale à l'apprenant des erreurs comme
des définitions circulaires. Lisp-Critic [Fischer et al. 1991] est capable
de suggérer des transformations d'un programme Lisp en donnant des
explications relatives à l'efficacité ou à la lisibilité.
Dans tous ces systèmes qui ont pour objectif d'aider l'étudiant à acquérir
un savoir-faire en programmation, on constate que les diagnostics sont
généralement conceptuels puisqu'ils font intervenir des notions de
programmation (par ex. PATAT [Nowé & Jonkers 1991] peut écrire : "variable
result must be initialised to 0 because result is the running total
variable and the unity element for the sum operator is 0", par opposition à
un diagnostic non conceptuel qui pourrait être : "cette clause est erronée,
voici la forme correcte"). Autrement dit l'effet pédagogique de tels
diagnostics nécessite un examen par l'étudiant de ses propres
connaissances. Notre approche consiste elle aussi à apporter une critique de type
conceptuel à l'étudiant, mais elle diffère sur un point qui nous semble
important. Dans son principe, la simulation argumentée que nous présentons
ici ne consiste pas à fournir un simple diagnostic. Il s'agit, à partir de
ce que savant 3 considère comme une anomalie de structure dans le programme
de l'étudiant, de susciter un échange argumentatif avec ce-dernier. On
rejoint ainsi l'idée de base de savant 3 qui utilise une "conversation"
pour tester la cohérence des connaissances de l'étudiant, et non une simple
succession d'échanges question-feedback. Cette approche semble
particulièrement indiquée dans le cas de l'apprentissage d'un langage de
programmation, et ce pour plusieurs raisons : La possibilité de simuler le programme de l'étudiant permet à celui-
ci de constater des exécutions anormales, ce qui est censé le motiver pour
solliciter la critique de savant 3. On peut imaginer que savant 3
intervienne automatiquement en cas d'anomalie (critique active), mais nous
n'avons pas implanté cette possibilité.
Les critiques que l'on peut formuler sur un programme donné sont
rarement définitives. L'étudiant peut avoir une motivation, non connue du
programme, pour écrire par exemple une clause correcte mais très
inefficace. L'échange d'arguments lui permet d'imposer son point de vue.
Le diagnostic immédiat permet rarement de mettre la faute
conceptuelle en évidence. C'est souvent lorsque l'élève se défend en
donnant ses raisons que le dialogue remonte jusqu'aux présupposés erronés. 2. L'apprentissage d'un savoir-faire en Prolog avec un exercice simple Dans la maquette que nous avons mise au point, on demande à l'étudiant
d'écrire un petit programme Prolog qui calcule la relation voiture(X,Y)
suivante : Pour X inférieur à 4000, Y doit être nul.
Pour X entre 4000 et 10000, Y doit être égal à 10.
Pour X supérieur à 10000, Y doit valoir 30. Ce programme est supposé calculer la taxe (Y) qu'un individu doit payer
pour sa voiture d'après le montant de ses revenus (X). Mais nous ne
laissons pas à l'étudiant la possibilité d'écrire un programme quelconque.
Nous lui fournissons un éditeur très limité qui impose les contraintes
suivantes : le programme comprend trois clauses
la tête de chaque clause est imposée : voiture(Revenus, 0) :-
voiture(Revenus, 10) :-
voiture(Revenus, 30) :-
l'étudiant peut placer des buts pour construire ces clauses en les
choisissant dans une liste :
< 4000
>= 4000
< 10000
>= 10000
! (cut) Le nombre de programmes qu'il pourra écrire avec un tel éditeur est tout de
même égal à 215 (32768) (chaque but est présent ou absent dans chacune des
trois clauses). A chaque instant l'étudiant peut exécuter son programme :
il fournit la valeur de Revenus dans voiture(Revenus, Taxes), puis
l'interpréteur Prolog cherche toutes les solutions possibles pour Taxes
pendant qu'une fenêtre de trace montre les clauses appelées et leur échec
éventuel (voir figure). [pic] Cet exercice est utilisé pour enseigner à l'étudiant certains savoir-faire
nécessaires pour l'écriture et la compréhension de programmes Prolog.
L'objectif est d'attirer son attention sur la justesse et l'efficacité de
son programme. Par exemple, un programme peut être correct, mais très peu
efficace : voiture(Revenus, 0) :- Revenus < 4000, Revenus < 10000 .
voiture(Revenus, 10) :- Revenus >= 4000, Revenus < 10000 .
voiture(Revenus, 30) :- Revenus >= 4000, Revenus >= 10000 . Ce programme est inefficace pour plusieurs raisons : il comporte des buts
redondants dans les clauses 1 et 3, et l'aspect déterministe du programme
n'est pas pris en considération (par ex. un cut peut être introduit en
clause 1 pour éviter un appel inutile des clauses suivantes). L'interp