1. Introduction

Cet environnement [Ibr89a, Ibr89b, Ibr90a, Ibr90b] est conçu pour faciliter la tâche des créateurs de didacticiels lors de la phase de conception pédagogique ainsi que celle des programmeurs lors des phases d'implantation, de test et de maintenance, de même que celle des traducteurs lors de la phase de traduction des dialogues. Il est utilisé pour produire et maintenir sur des stations de travail graphiques des programmes d'EAO qui seront ensuite compilés et exécutés sur des machines cibles (généralement des micro-ordinateurs).

Pour être facilement utilisable par des enseignants, un formalisme de spécification doit être relativement simple. Celui que nous utilisons est totalement indépendant de tout langage de programmation. C'est un mélange de symboles graphiques et de texte qui permet au(x) concepteur(s) de décrire le dialogue entre l'apprenant et l'ordinateur ainsi que le déroulement logique de la leçon, c'est-à-dire comment le programme doit réagir aux réponses et actions de l'apprenant. Cela peut se comparer à un script de film, mais en bien moins linéaire. Ce formalisme comprend quatre composants de base que le concepteur peut utiliser pour élaborer sa leçon: des messages, des instructions au codeur, des boîtes de test et des arcs reliant des composants des trois premiers types.

• Les messages sont juste du texte qui doit apparaître à l'écran. Ils peuvent éventuellement inclure des directives de mise en page. Ces messages sont stockés séparément du programme, facilitant ainsi une traduction ultérieure des dialogues. Dans un script, les textes des messages sont entourés d'une ellipse.

• Les instructions au codeur sont du texte libre décrivant une action à faire par le programme. Cette action peut être très simple (par exemple lire une chaîne de caractères au clavier, faire clignoter une zone de l'écran, ...) ou bien plus complexe (par exemple simuler un tableur électronique, montrer une image complexe, ...). Dans un script, les instructions au codeur sont indiquées entre accolades.

• Les boîtes de test sont généralement empilées les unes sur les autres. Chaque boîte contient un prédicat en texte libre, généralement en relation avec les actions de l'apprenant (par exemple des réponses possibles, des mots clés qui doivent être présents, ...). Si, pour une réponse donnée, le prédicat s'avère faux, le prédicat qui suit (s'il y en a), dans la boîte juste en dessous, est évalué à son tour.

• Les arcs sont des flèches reliant les trois autres types de composants. Ils indiquent la séquence des opérations. Alors qu'il n'y a qu'un arc partant d'un message ou d'une instruction au codeur, plusieurs arcs peuvent partir latéralement d'une boîte de test. Ces arcs sont alors numérotés pour indiquer lequel doit être utilisé à chaque fois que le test s'avère positif.

Notre environnement de développement comporte un ensemble d'outils tels que ceux qui sont utilisés pour la plupart des développements de logiciels à grande échelle: des outils de spécification, d'implantation, de prototypage, de mise au point et de maintenance. Etant donné la nature graphique de notre formalisme de spécification, l'outil de spécification est un éditeur de script. C'est un éditeur graphique interactif spécifique dont les primitives de base sont étroitement liées au formalisme de spécification. Il comporte, entre autres, des primitives d'édition de graphe, d'édition du contenu des noeuds, de déplacement le long des arcs, l'insertion ou la suppression de noeuds ainsi qu'un contrôle de la validité structurelle du graphe.

Un tel graphe peut être considéré comme une spécification semi- formelle d'une leçon. Le graphe orienté correspondant à une leçon peut ainsi être vu comme représentant un automate à états finis; chaque noeud du graphe correspondant à un état de l'automate et les arcs représentant les transitions d'un état à l'autre. Nous avons donc développé un générateur automatique de programmes qui traduit un graphe en code source dans un langage évolué tel que Pascal, Modula 2 ou Ada. Cette traduction ne peut bien entendu pas être totale, puisque les scripts comportent des éléments en texte libre.

L'automate à états finis est généré sous la forme d'une instruction de sélection imbriquée dans une boucle. Le sélecteur est une variable d'état dont la valeur sera l'identificateur du prochain noeud à exécuter. Cela donne quelque chose du genre:

  REPEAT
    CASE Etat OF
      Etati : begin InstructionCorrespondantAuNoeud;
                    Etat := Etatj;
              end; {Etati}
      ...
    END;  (*CASE Etat OF*)
  UNTIL Sortir;

Les instructions au codeur sont traduites en un appel de procédure. Pour certaines instructions simples et indépendantes de la matière enseignée (mise en page, délai d'attente, etc.) une procédure de bibliothèque sera invoquée. Pour les instructions plus compliquées, le générateur automatique produira un appel à une procédure d'un module externe dont le corps sera défini par le programmeur. D'une manière similaire, les prédicats qui se trouvent dans une boîte de test seront générés sous la forme d'un appel à une fonction booléenne. Ces fonctions booléennes sont, elles aussi, placées dans un module externe et leur corps devra être défini par le programmeur. La partie déclarative est, quant-à elle, aussi générée automatiquement.

Cet environnement de développement ayant déjà fait l'objet de plusieurs publications, nous ne décrirons pas ici le reste des outils le composant. Nous nous attacherons, pour la suite de cet article, à la description d'une extension du générateur automatique de programmes, par le biais de techniques d'intelligence artificielle, dans le but d'en augmenter la capacité de génération automatique.

2. Qu'est-ce que la programmation automatique ?

Site Hosting: Bronco