Editeur de constantes

Comme l’éditeur de structure, l’éditeur de constante pourrait aussi être utilisé dans le nouvel état du système DIVA, c’est à dire avec l’intégration du flot de données. Il permet à l’utilisateur de créer une constante qui sera ensuite utilisée par l’Editeur de script en tant que

paramètre d’entrée d’un nœud par exemple. La fenêtre principale (Figure 3.31) de l’éditeur de constante ressemble à celle de l’éditeur de structure (Figure 3.28). Elle permet donc à l’utilisateur de créer un nouveau fichier de constantes ou d’ouvrir un fichier existant. La fenêtre d’édition de constante (Figure 3.32) permet de créer une nouvelle constante ou de modifier les caractéristiques d’une constante donnée.

Figure 3.31 Fenêtre principale de l’éditeur de constante

3.7 Les outils supplémentaires 87

Le type d’une constante pourrait être simple (booléen, entier, réel, caractère, chaîne de caractère) ou structuré (tableau, liste, arbre). Il peut aussi être un type défini par l’utilisateur à l’aide de l’éditeur de structure. Le choix du type se fait à partir de la fenêtre d'édition de constante (Figure 3.32). L’utilisateur doit aussi donner un nom et choisir, s’il le veut, une icône pour représenter la constante. L’entrée de (des) valeur(s) de la constante dépend de son type. La Figure 3.33 présente l’entrée de valeur d’une constante nommée age de type entier.

Figure 3.33 Entrée de valeur d’une constante de type entier

L’ensemble de constantes créées par l’éditeur de constantes est enregistré dans un fichier (texte) avec l’extension .dc (data constant). Comme pour les structures, les constantes sont aussi séparées les unes des autres par une ligne composée par des séquences de "=". Le fichier donne le nombre de constantes qu’il contient. Pour chaque constante les informations suivantes sont enregistrées:

• commentaire global sur la constante (optionnel) • le nom de la constante

• l’icône (une valeur par défaut existe) qui la représente visuellement • son type

• et sa valeur. Si le type de la constante est structuré, le type de base est donné avant les différentes valeurs.

Figure 3.34 Fichier de constantes (myconst.dc) avec deux éléments

Figure 3.35 Valeur du quatrième élément d’une constante tableau de sept éléments La Figure 3.34 présente graphiquement un fichier de constante contenant deux éléments: age qui est une constante de type entier dont la valeur est 25, joursem qui est une constante de type tableau de chaîne de caractères ayant sept éléments qui sont les jours de la semaine. La Figure 3.35 montre que la valeur du quatrième élément de ce tableau est "mercredi".

3.7 Les outils supplémentaires 89

CONSTANTS DECLARATION FILE

Number of constants : 2

===================================================== *************************************************************************** * C’est l’age de reference

* *************************************************************************** age @/user/ub2/eao/ideal/StructEd/source/icons/simple.xbm 2Integer 25 ===================================================== *************************************************************************** * tableau pour les jours de la semaine. 1 correspond a dimanche

* *************************************************************************** joursem @/user/ub2/eao/ideal/StructEd/source/icons/array.xbm 7Array 1 7(6String 80) (dimanche,lundi,mardi,mercredi,jeudi,vendredi,samedi) ===================================================== Exemple 3.19 Le contenu du fichier de constante myconst.dc

L’éditeur de structures et l’éditeur de constantes peuvent communiquer entre eux. Durant l'édition (création ou modification) d'une constante, l'utilisateur peut choisir une structure qu'il avait préalablement créée avec l'éditeur de structure en appuyant sur le bouton " structure prédéfinie" (représenté par un livre ouvert, Figure 3.32). A ce moment-là, si l’éditeur de structures n’est pas actif, il est lancé par l’éditeur constant. Dans l’éditeur de structures, l'utilisateur doit choisir une structure (en cliquant dessus), puis l'envoyer en utilisant la fonction "Envoie" (Figure 3.28). Dans l’éditeur constant, si l’utilisateur change d’avis et ne veut pas recevoir le type, il devra appuyer sur un bouton représentant un autre type.

D’autres communications similaires devraient aussi être mises en place d’une part entre l’édi- teur de structures et l’éditeur de script pour que ce dernier puisse choisir un type défini par l’utilisateur, et d’autre part entre l’éditeur de constantes et l’éditeur de script pour que ce dernier puisse aussi prendre une constante définie par l’utilisateur. L’éditeur de structures

aurait alors deux fonctions d’envoi, l’une vers l’éditeur de script et l’autre vers l’éditeur de constante.

Note 3.7

• La version actuelle de DIVA-cd ne tient pas encore compte de l'existence de ces deux éditeurs.

• En se basant sur les représentations visuelles des types données décrites ci-dessus. Notre groupe a aussi conçu des représentations visuelles de certaines manipulations de données [Ibrahim98a]. Les représentations visuelles des types et des manipulations de données ne devront pas apparaître directement sur la représentation statique du graphe pour ne pas trop encombrer l’affichage. Elles apparaîtraient sur demande, dans une fenêtre transitoire, toutes les fois que l’utilisateur clique sur les endroits appropriés. Ces représentations visuelles ne sont pas encore implantées dans la version actuelle de DIVA-cd.

En résumé

La représentation interne de la spécification (fichier du graphe de script) est utilisée d’une ma- nière ou d’une autre par la plupart des outils: le générateur de code automatique l’utilise directement pour produire le code sous forme d’automate à états finis, l’éditeur synchrone l’utilise pour afficher des vues synchronisées de la spécification et du code complémentaire que les programmeurs doivent produire, l’outil de surveillance à distance l’utilise pour afficher l’état actuel de l’exécution du programme final fonctionnant sur une machine cible. Il faut donc noter que la spécification visuelle est ainsi utilisée

• en tant qu’entrée formelle au générateur de code,

• comme une spécification pour les programmeurs qui doivent implémenter les parties qui ne pourraient pas être produites automatiquement,

• comme documentation humainement lisible pour aider les programmeurs qui font l’entretien, à mieux comprendre le code,

• comme une carte visuelle du logiciel pour les enseignants qui veulent suivre ce que les étudiants font.

3.7 Les outils supplémentaires 91

Tous les outils supplémentaires sont aussi prévus pour des utilisations multi-langues. Ils com- mencent donc par l’affichage de la fenêtre de choix de langue (Figure 3.5).

Seuls les deux composants principaux du système DIVA sont directement concernés par l’intégration du flot de données: l’éditeur synchrone, notamment l'éditeur de script, qui devra être enrichi avec des fonctionnalités permettant de dessiner des éléments relatifs au flot de données, et le générateur de code, qui devrait tenir compte de ces données soit dans le module du code correspondant à l’automate à états finis, soit dans le module du code manuel.

Du point de vue implémentation, le tableau suivant donne un aperçu des langages de program- mation utilisés pour les différents composants du système DIVA et ses outils supplémentaires.

Ada Tcl/Tk Java C Autres

Editeur synchrone x x x

Générateur de code x

Gestionnaire de traduction x

Outil de vue d’ensemble de projet x x x

Outil d’impression de script x latex

Superviseur x x x

Editeur de structures x

Editeur de constantes x

93

nouveau formalisme visuel

Le fait de pouvoir représenter visuellement la "circulation" des données dans un langage de programmation visuelle permet d’augmenter l’utilité du langage. Comme nous l'avons discuté dans le chapitre 2, la co-existence des flots de données et des flots de contrôle permet de tirer les avantages de chacun d’eux. Nous avons déjà décrit dans le chapitre 3 la représentation du flot de contrôle dans le système DIVA. Ce flot de contrôle reste le même dans le nouveau système intégrant le flot de données. Dans ce chapitre, nous allons étudier comment le système DIVA tient compte des données traitées dans une application [Randriamparany01a] [Randriamparany01b]. Le nouveau langage ainsi défini est baptisé DIVA-cd, c’est-à- dire "DIVA combinant flots de contrôle et de données".

Le système DIVA, avec le flot de contrôle, est utilisable seulement pour spécifier des applica- tions qui n’ont pas des traitements et d’échanges de données. C’est généralement le cas de la plupart des applications d’EAO (leçons). Ce qui domine surtout c’est l’interaction entre le système et l’apprenant. Le système affiche des messages à l’écran, l’apprenant agit en entrant ses réponses (données) directement au clavier. Très souvent, ces données entrées sont traitées tout de suite (localement) et ne seront pas réutilisées dans des étapes ultérieures de la leçon. Ces données sont donc considérées comme des variables locales à chaque étape d’exécution (correspondant à un nœud de la spécification visuelle). Lorsque le traitement de l’étape est fini, la leçon continue selon le flot de contrôle prévu. On ne garde pas des traces des données utilisées. Si la leçon nécessite de spécifier la circulation des données le formalisme utilisant seulement le flot de données ne pourrait donc pas être utilisé.

Le but principal de l’intégration du flot de données dans le système DIVA est donc de pouvoir considérer dans la spécification visuelle les échanges et les circulations des données dans une application. Ceci enrichit davantage les spécifications d’application d’EAO, et offre aussi une ouverture vers des applications des autres domaines qui pourront être purement de flot de données. Nous avons donc besoin d'un formalisme visuel permettant, d'une part, de localiser