VP-SE Research Group (C)
Tout un environnement de développement a alors été conçu sur station de travail graphique pour faciliter la transcription des spécifications de leçons en programmes pouvant être exécutés sur diverses machines cibles. Cet environnement comporte entre autres, un éditeur graphique de scripts, un générateur automatique de programmes et un éditeur multi-fenêtres synchrones pour faciliter le travail des programmeurs qui doivent compléter le code généré automatiquement.
L'avantage généralement perçu des systèmes auteurs est l'absence de la nécessité de connaître un langage de programmation pour pouvoir les utiliser. Cela en fait un outil de choix pour des enseignants désireux de développer leurs propres leçons à moindre frais. A nos yeux, cet avantage constitue en fait un inconvénient puisque la simplicité d'utilisation se fait généralement au détriment de la richesse d'expression. Quelques rares systèmes offrent des possibilités de programmation plus étendues, mais leur complexité d'utilisation augmente d'autant. De plus, ces possibilités de programmation ne répondent que de loin aux critères modernes de sécurité et de lisibilité des programmes.
Soucieux de n'imposer aucune limitation aux enseignants désirant développer des leçons d'EAO, nous avons choisi l'alternative consistant à utiliser un langage de programmation se prêtant bien au travail en équipe, c'est-à-dire incorporant la notion de module. Indépendamment du choix d'un langage de programmation, nous utilisons un formalisme de spécification des leçons, développé par l'équipe du professeur A. Bork (Bork86) et qui, tel un scénario de film, permet de décrire le dialogue entre l'ordinateur et l'apprenant ainsi que la logique de déroulement de la leçon, prenant en compte les réponses fournies à l'ordinateur.
C'est dans le but de faciliter cette transcription et pour éviter que les mêmes efforts soient répétés à chaque fois qu'une série de modules réutilisables ont été développés. Ces modules permettent de gérer des fenêtres de texte et de graphique à l'écran, des entrées au clavier ou à la souris, des fichiers de messages en accès direct pour séparer la logique de déroulement des textes des dialogues, des fichiers d'images matricielles pour assurer une certaine indépendance vis-à-vis de la résolution de l'écran (Ibra88), l'accès à un réseau local pour contrôler le déroulement des leçons et récolter des statistiques (Ibra85), ainsi que des algorithmes de classification permettant l'analyse des réponses de l'apprenant.
Bien que d'une utilité certaine, ces divers modules n'offrent d'aide que dans une petite partie du cycle de vie d'un logiciel d'EAO. De plus, une bonne partie du travail de programmation qui reste à faire et qui a trait à la logique de déroulement est assez fastidieuse et sujette à des erreurs d'implantation.
Les différentes phases de l'élaboration d'un didacticiel peuvent être représentées par la figure 2.
Cet environnement de développement utilise une station de travail avec grand écran. Pour des raisons de portabilité et d'indépendance vis-à-vis des constructeurs le langage de programmation utilisé est le langage Ada et l'environnement de gestion de fenêtre est X-Windows, développé au M.I.T. dans le cadre du projet Athena (Sche86). Les leçons développées à l'aide de cet environnement sont conçues pour être exécutées sur un ordinateur personnel et nécessitent des ressources nettement plus modestes. Parmi les langages cibles envisagés, on peut citer Ada, Modula 2, Pascal UCSD, Turbo Pascal...
L'environnement de développement comporte, pour la phase de conception pédagogique, un éditeur de script permettant d'introduire graphiquement la spécification d'une leçon ou de modifier la spécification d'une leçon pré-existante.
La phase de révision de la conception pédagogique utilise un traducteur automatique (générateur automatique de programmes) qui, même s'il ne peut traduire la totalité du script, est capable de générer pour faire du prototypage rapide un programme dont l'exécution donnera une idée assez précise de ce que sera le produit final. A ce stade, l'éditeur de script peut être utilisé pour apporter des modifications au scénario avant même que la phase de codage n'ait commencé.
La phase de codage ainsi que celle de révision du code font, elles, appel à un éditeur multi-fenêtres synchrones qui permet à un programmeur de compléter dans une fenêtre le code généré par le traducteur automatique tout en visualisant dans une autre fenêtre la partie du script correspondante. C'est ici que l'utilisation d'un langage cible modulaire apporte un avantage certain. Cela permet en effet de séparer dans des modules le code ajouté par le(s) programmeur(s), ne nécessitant pas ainsi la modification du code généré par le traducteur automatique.
La phase de révision du code fait usage d'un outil de supervision à distance (sur une machine de développement) pour suivre le déroulement d'une leçon (sur une machine cible reliée au même réseau local), permettant de visualiser directement sur le script le cheminement du programme cible. Il est ainsi plus facile de déterminer à quel endroit de la leçon a lieu telle ou telle erreur. L'éditeur multi-fenêtres synchrones permet alors au programmeur de se placer directement sur le code concerné pour le corriger.
Un mécanisme similaire permet de récolter automatiquement des statistiques sur le déroulement des leçons, une fois que le didacticiel est opérationnel. L'étude de ces statistiques peut alors amener les concepteurs à revoir la conception pédagogique en utilisant l'éditeur de script.
A côté de la conception et de la mise au point de leçons, il est une phase qui est assez importante à nos yeux: la traduction des dialogues. En effet, tous les didacticiels que nous développons sont étudiés pour pouvoir être facilement traduits dans diverses langues utilisant le même alphabet (à quelques variantes de lettres accentuées près). Cette phase de traduction pouvant intervenir avant aussi bien qu'après des révisions du script, elle nécessite l'emploi d'un outil d'édition qui possède aussi les fonctionalité d'un gestionnaire de versions et gère une base de données de mises à jour.
Tous ces outils sont interdépendants et forment un ensemble cohérent qui peut être illustré par la figure 3.
La structure de donnée construite par cet éditeur et chargée de représenter le contenu de la leçon est un graphe orienté où chaque noeud représente une action élémentaire: l'affichage d'un texte (message) à l'écran, l'exécution d'une opération quelconque (commentaire au codeur) ou l'évaluation d'un test sur une action de l'apprenant. Les arcs orientés représentent quant à eux l'enchaînement des opérations. Cette structure est non-linéaire puisqu'un noeud représentant un test (généralement un critère d'analyse de réponse) peut avoir plusieurs successeurs:
En plus des primitives d'édition, l'éditeur de script permet de contrôler la cohérence du graphe, mettant ainsi rapidement en évidence des arcs oubliés ou des chemins incomplets.
En sortie, cet éditeur crée un fichier contenant le graphe correspondant à la leçon et un fichier de messages contenant le texte des dialogues (contenu des noeuds de type message). Ces deux fichiers pourront ensuite être utilisés par les autres outils de l'environnement (fig. 3) pour obtenir une sortie papier ou pour produire les programmes correspondants.
Un noeud de type message sera traduit en un appel à la primitive d'affichage de texte sur l'écran avec, en paramètre, le nom du message correspondant. Un noeud de type test sera traduit en un appel à une fonction booléenne dont le corps sera défini dans un module externe. Un noeud de type commentaire au codeur sera traduit en un appel à une procédure dont le corps sera lui aussi défini dans un module externe.
Le code qui devra être ajouté par les programmeurs se trouve donc dans des modules séparés du code produit par le générateur automatique. Ces modules externes ont leur définition (interface) fixée par le générateur automatique et leur implantation pourra être définie à l'aide de l'éditeur multi-fenêtres synchrones.
Pour permettre un prototypage rapide des leçons, le générateur automatique peut produire une implantation "bidon" des modules externes dans laquelle les procédures correspondant aux commentaires au codeur ne contiennent qu'une instruction d'affichage du commentaire et les fonctions correspondant aux tests sollicitent interactivement le résultat qu'elles sont sensé retourner.
Cette fenêtre auxiliaire affiche la partie du script que le code de la fenêtre principale est sensé implanter. Toutes ces fenêtres (principale et auxiliaire) permettent d'introduire des commandes de positionnement qui provoqueront un déplacement synchronisé de l'autre fenêtre. En plus du code sur lequel il travaille, le programmeur a ainsi en permanence sous les yeux la spécification correspondante, qui constitue une documentation nettement plus lisible.
Pour faciliter le maintien de la cohérence entre les différentes traductions, un utilitaire multi-fenêtres de gestion des modifications apportées aux messages permet de se placer automatiquement à l'endroit où une modification a eu lieu pour une langue et pas pour une autre, d'afficher dans différentes fenêtres le message modifié avant et après modification ainsi que la traduction qui doit être mise à jour. Il y a donc une fenêtre active permettant de mettre à jour une langue et des fenêtres passives permettant de voir les modifications apportées à d'autres langues. Ces différentes fenêtres sont synchronisées et tout déplacement dans l'une d'elles provoque le même mouvement dans les autres.
En plus des primitives d'édition de texte, cet outil possède donc des primitives de gestion de versions tenant à jour une base de données de modifications.
Lorsque la leçon se déroule sur la machine cible, il suffit alors de mettre une station de travail à l'écoute du réseau pour pouvoir visualiser à l'écran de la station de travail l'avancement de la leçon directement sur le dessin du script. Parallèlement à la visualisation de l'avancement de la leçon, il est possible de récolter par le même mécanisme des statistiques sur le déroulement de l'ensemble des leçons. Ces statistiques permettent ensuite de mieux se rendre compte de l'impact des leçons sur les apprenants, en dévoilant les parties où un grand nombre ont eu des difficultés, nécessitant éventuellement une modification du script en vue d'améliorer la situation. Nous avons d'ailleurs par le passé déjà tiré profit de machines connectées en réseau pour récolter des informations sur le déroulement de leçons (Ibra85).
Moyennant l'adjonction du nom de l'apprenant dans les informations envoyées par la machine cible, il serait aussi possible de faire du curriculum automatique. Nous sommes toutefois peu partisans d'une telle solution car il n'est pas toujours facile de contrôler l'identité réelle de la personne qui suit la leçon. Cela nuirait aussi au climat de confiance qui règne quand l'apprenant sait qu'il n'y a personne pour le surveiller et qu'il peut par conséquent faire des erreurs sans se sentir culpabilisé.
Il va de soi que le module d'accès au réseau est conçu de telle façon qu'en cas de défaillance de ce réseau, la machine ne soit pas bloquée pour autant. En plus de son utilité évidente dans la phase d'exploitation des didacticiels, cette possibilité de suivre le déroulement d'une leçon est très utile durant la phase de mise au point. En effet, s'il est possible de savoir à quel point du script on se trouve lorsqu'une leçon se "plante", l'éditeur multi-fenêtres synchrones permet de se placer très rapidement sur le code correspondant, facilitant ainsi la recherche des erreurs de programmation.
Nous envisageons donc, dans une deuxième phase, d'augmenter la puissance de traduction à l'aide de techniques d'intelligence artificielle, en l'occurrence des mécanismes d'apprentissage et de généralisation. Cela consistera à essayer de reconnaître des similitudes entre différents commentaires au codeur et de solliciter du programmeur un prédicat permettant d'associer des paramètres spécifiques à chaque commentaire.
Site Hosting: Bronco
