• Aucun résultat trouvé

1.2 Étude des objectifs

1.2.2 Objectif : utiliser conjointement

Communication des données

Actuellement, si les utilisateurs réalisaient un exercice de géométrie du début à la fin (de la lecture de l’énoncé à la rédaction d’une réponse) avec les différents prototypes existants, ils se trouveraient dans la nécessité de saisir des données plusieurs fois, sous des formats parfois différents.

1.2. Étude des obje tifs 19

Théorie du domaine Base de connaissances

Aide dans l ’interaction Base d ’exercices

Rappels de cours

Aide au raisonnement (par visualisation de l’état de résolution) Aide à la rédaction de la solution

Aide au raisonnement (par application guidée du cours)

Extraction de sous-figure Exploration de figure Analyse de l ’énoncé Edition de figure Diagnostic de l ’interprétation de l ’énoncé

Diagnostic de besoin d ’aide

Diagnostic de correction de figure

Trace des objets créés Analyse des interactions Domaine d ’apprentissage (a)

Pédagogie, aide (b) Outils, micromonde (c) Dynamique de l ’activité (d) CABRI PACT CHYPRE MENTONIEZH TALC

Figure 1.8 – Fonctionnalités des EIAO de l’exemple introductif

Exemple 1.5 Dans l'exemple introdu tif(page 5), les prototypes sontutilisés onjoin- tementpourrésoudreunproblème.Nousdisposonsinitialementd'unénon éduproblème en langage naturel (par exemple, le français).

Dans l’exemple 1.5, chaque utilisateur interprète cet énoncé afin de pouvoir fournir les informa- tions adéquates aux prototypes dans une forme appropriée ( f. figure 1.9). L’apprenant (voir

les flèches fines sur la figure 1.9), extrait de l’énoncé les faits à partir desquels il peut raisonner et la conjecture qu’il doit prouver. Il utilise ensuite les faits identifiés pour construire la figure avecCABRI-Géomètre.

Pour cela, il applique lesoutils d’édition de figure proposé par CABRI-Géomètre. Il exploite

la conjecture et une nouvelle fois les faits, lorsque Mentoniezh demande d’identifier les faits et

la conjecture présents dans l’énoncé. Il utilise pour cela lesmenus que lui proposeMentoniezh.

Il effectue la même tâche (entrée des faits et de la conjecture) avec CHyPre grâce à des me-

20 Chapitre 1. Un atelier d'expérimentation delogi iels édu atifs

et la conclusion de l’énoncé. Il traduit ces informations dans le langage de représentation des connaissances de géométrie que requiert Mentoniezh. Il traduit une nouvelle fois ces informa-

tions dans le langage de représentation des connaissances de géométrie que nécessite TALC. Il

entre une fois encore ces informations dans PACT(par le biais de menus). De plus, différents

logiciels communiquent les informations (faits, conjectures) directement à d’autres logiciels (voir les flèches dont le trait est constitué de tirets sur la figure 1.9.

conclusion Problème à résoudre

Énoncé en langage naturel

sujet prescripteur

faits conjecture hypothèses

TALC Mentoniezh Cabri CHyPre Informations extraites de l'énoncé Logiciels qui utilisent ces informations Légende PACT

Figure 1.9 – Traitement d’un énoncé par différents prototypes

L’utilisation conjointe des cinq prototypes de notre exemple requiert de chaque utilisateur de multiples saisies sous plusieurs formes des même informations, ainsi qu’une communication inter logiciels de certaines des informations.

Le premier intérêt de l’atelier est de mettre au point un système de communication de données et de gestion des formats afin de supprimer ces saisies multiples.

⋄ Dès lors, la onséquen e pour l'atelier est que celui-ci doit permettre le transfert de

données à des logiciels divers sans multiplier les saisies. Pour cela, l’atelier doit assurer la communication entre les prototypes, d’où la prise en compte d’un média de communication (un équipement) et d’un protocole de transfert des données.

⋄ Ainsi, la onséquen e pour haque prototype, est qu’il fautassurer la communication des

données au format adéquat c’est-à-dire que les données soient représentées dans un format compris par tous les logiciels. Deux possibilités sont envisageables :

1. soit il existe un format standard de représentation des données ;

2. soit il existe un moyen de traduire les connaissances à échanger dans le langage de repré- sentation de chaque prototype cible de ces données.

Ces deux possibilités ne sont pas bien évidemment exclusives.

⋄ La re her he né essaire sur et obje tif concerne la gestion des formats de données entre

différents prototypes. Elle est présenté à la section 3.6. Monitoring

Le transfert de données est le premier maillon de la solution. La notion même de communi- cation implique sur les prototypes des actions, des inter-actions. En effet, il est parfois nécessaire

1.2. Étude des obje tifs 21

de prendre le contrôle de certains prototypes afin de mettre en évidence un objet ou bien de lancer une action.

Exemple 1.6 Dansl'exempleintrodu tif(page5),PACTagitsur CABRI-Géomètreet

CHyPre(lesmi romondesd'éditiondegures).Pourillustrernotre proposnousprenons le as de CABRI-Géomètre.

PACT a pour but d'aider l'apprenant à partir de l'analyse de ses intera tions ave

CABRI-Géomètre. Dans CABRI-Géomètre, l'apprenant est libre d'agir. Il peut ainsi ne jamaisatteindre lebut qu'il s'est xé. Lorsque PACT déte te que l'apprenant est en di ulté,ilpeuta herunmessageà elui- i. Toutefoisa herunsimplemessage est parfois insusant : par exemple, il est parfois souhaitable de rendre saillants ertains objets. Pour ela, PACT, met, par exemple, en éviden e une propriété de la gure en épaississant les segments d'une sous gure. Ainsi PACT doit pouvoir prendre la main sur CABRI-Géomètre pour provoquer l'épaississementde ertains objets géométriques.

⋄ La onséquen e pourl'atelier est que l’atelier doit commander les prototypes pour agir

sur eux : les activer, les désactiver, par exemple.

⋄ La onséquen e pour haque prototype est qu’il devrait permettre une certaine forme

de prise de contrôle par un autre prototype. Ritter et Koedinger parlent dans ce cas, de prototype «scriptable » ([Ritter 96]).

⋄ Lare her he né essaire sur etobje tif concerne la définition d’un ensemble de commandes

pour agir sur tous les prototypes. Elle est présentée à la section 3.5. Le but est de pouvoir scripter tous les prototypes avec le même langage de scripts.

Protocole de coopération des prototypes

Finalement, lorsque l’on rend possible pour les prototypes des inter-actions, il apparaît in- dispensable d’ajouter encore une notion de gestion des inter-actions : ordre d’apparition des prototypes, condition de leur clôture, . . .

Exemple 1.7 Dans l'exemple introdu tif (page 5), CHyPre et Mentoniezh sonta tifs en même temps. De même, CABRI-Géomètre et TALC sont a tifs en même temps, pourque TALC puisseré upérer lesobjets réésave CABRI-Géomètre etainsivérier la onformitédelagure relativement àl'énon é.Cependantlediagnosti de TALC ne doit être lan é que lorsque l'utilisateur a onstruit une gure ave CABRI-Géomètre, ave l'aide de PACT, etqu'il demande une validation.

⋄ La onséquen e pourl'atelierest qu’il doitposséder un moyen de définir un protocole

de coopération entre les prototypes. Ce protocole de coopération consiste à définir au cours du temps le statut (actifs, inactifs) des participants (les prototypes) et les règles de participation (l’un après l’autre, en parallèle,et .). L’atelier doit aussi être capable descruter certains états

ou certaines variables d’un prototype afin de les utiliser dans le protocole de coopération. ⋄ La onséquen e pour haque prototype est qu’il devrait pouvoir être rendu actif ou

inactif, totalement ou partiellement. Nous retrouvons ici la propriété de scriptabilité. Le prototype doit aussipermettre l’observation de certains de ses états ou de ses variables. Ritter et Koedinger parlent, dans ce cas, d’états ou de variables «scrutables» ([Ritter 96]).

⋄ Lare her he né essaire sur etobje tif concerne deux points :

– la définition de scrutables commun à tous les prototypes. Cet aspect n’est pas approfondi ici.

– la définition d’une protocole de coopération entre les prototypes. Le dernier point est présenté à la section 3.3.

22 Chapitre 1. Un atelier d'expérimentation delogi iels édu atifs