MODELE GENERIQUE DE PROGRAMMATION SUR EXEMPLE

Transcription

1 Université de Poitiers ENSMA DEA T3IA Traitement de l Information : Informatique, Images, Automatique MODELE GENERIQUE DE PROGRAMMATION SUR EXEMPLE Loé SANOU Mémoire de Stage effectué sous la direction de Patrick GIRARD au Laboratoire d Informatique Scientifique et Industrielle Université de Poitiers ENSMA Septembre 2004

2 REMERCIEMENTS Mes remerciements les plus sincères vont à Patrick GIRARD et toute sa famille pour leur soutien. Je leur en suis très reconnaissant. Que Patrick GIRARD trouve ici l expression de ma profonde reconnaissance pour sa disponibilité, ses conseils, et de façon générale son aide. Je l exprime toute ma gratitude pour m avoir accordé sa confiance. Je remercie le professeur Guy Pierra (directeur du LISI), le professeur Yamine Aït Ameur et monsieur Pascal Richard. Je remercie également Mickaël BARON, pour avoir prêté attention à mon travail, me prodiguer ses conseils, ses critiques, et en général son assistance

3 À tous le personnel du LISI, surtout les membres de l équipe IHM et en particulier Laurent et Nicolas, je dis un grand merci. Je n oublie pas mes compagnons de route du LISI et du SIC, plus particulièrement Stéphane, Romain, Alexandre, Mounir et Philipe. Qu ils soient ici remerciés. À tous ceux, qui de près ou de loin ont contribué d une manière ou d une autre à l aboutissement de ce travail, je leur dis merci

4 SOMMAIRE REMERCIEMENTS...2 SOMMAIRE...4 TABLE DES FIGURES...6 INTRODUCTION GENERALE...7 PREMIERE PARTIE : ETAT DE L ART CHAPITRE I : LES SYSTEMES DE PERSONNALISATION I-1 LES PREFERENCES, LES ENREGISTREURS DE MACROS ET LES SCRIPTS I-1-1 les préférences I-1-2 les enregistreurs de macros I-1-3 les scripts I-2 LA PROGRAMMATION SUR EXEMPLE I-2-1 définition I-2-2 Objectifs et caractéristiques I-2-3 Quelques exemples de systèmes I-2-4 Limites des systèmes de PbD I-3 CONCLUSION CHAPITRE II : CLASSIFICATION DES SYSTEMES II-1 TAXONOMIES EXISTANTES II-1-1 La taxonomie de Myers II-1-2 une grille de classification II-1-3 Classification de Girard II-2 NOUVELLE CLASSIFICATION DES SYSTEMES DE PBD II-2-1 domaines d application II-2-2 modes de programmation II-2-3 catégorisation des systèmes II-3 CONCLUSION CONCLUSION PREMIERE PARTIE DEUXIEME PARTIE : DES REPONSES AUX BESOINS DE LA PBD : SERVICES ET TOOLKIT CHAPITRE I : DES BESOINS POUR REALISER UNE APPLICATION DE PbD I-1 SERVICES A FOURNIR I-1-1 Enregistrement I-1-2 Généralisation I-1-3 Rejeu I-2 LES TENTATIVES DE REALISATION I-2-1 AIDE Project I-2-2 pbdscript I-2-3 limites de ces deux systemes par rapport aux besoins I-3 CONCLUSION CHAPITRE II : PRINCIPE DE RESOLUTION : PbDToolkit II-1 EXEMPLE : EAGER II-1-1 Enregistrement II-1-2 Rejeu II-2 PRINCIPES DE REALISATION II-2-1 Mécanismes de réutilisation

5 II-2-2 Spécification de développement d objets II-2-3 Procédé de réalisation II-3 EXEMPLE D IMPLEMENTATION II-3-1 Techniques utilisées II-3-2 Structure logicielle du système II-4 CONCLUSION CONCLUSION DEUXIEME PARTIE CONCLUSION GENERALE BIBLIOGRAPHIE

6 TABLE DES FIGURES Figure I-1-1 : Préférence du Mail sous Mac OS X 11 Figure I-1-2 : Enregistreur de macros sous Word97 (Windows) 13 Figure I-1-3 : Exemples de script sous Mac OS X (Récupération de mail sous Eudora) 14 Figure I-1-4 : Fenêtres utilisées pour créer un procédé en utilisant Peridot 18 Figure I-1-5 : Mondrian : définition de la macro "Créer Ombre". 19 Figure I-1-6 : SmallStar : une macro qui place la dernière version du fichier "Treaty" sur le bureau. 21 Figure I-1-7 : La «main de dieu» dans ToonTalk 21 Figure I-1-8 : La métaphore utilisée par ToonTalk 22 Figure I-1-9 : Environnement Metamouse 25 Figure I-1-10 : Composants de Tinker (avec la représentation de deux exemples) 26 Figure I-1-11 : Bâtir une pile de blocks à l aide de Tinker 27 Figure I-1-12 : Environnement Pygmalion 28 Figure I-1-13 : Réalisation de la fonction «factorielle» à l aide de Pygmalion 29 Figure I-1-14 : Environnement Gamut 30 Figure I-1-15 : Représentation graphique d un jeu 30 Figure I-1-16 : Programmation du jeu précédent (Figure I-1-15) 31 Figure I-1-17 : Environnement EBP 32 Figure I-1-18 : Exemples de construction complexe (boucle/répétition) 33 Figure I-1-19 : Rendu spécifique à Eager 34 Figure I-1-20 : Confirmation de fin de tâche dans le menu Eager 34 Figure II-1-21 : Architectures d AIDE 52 Figure II-1-22 : Arbre de commande pour une tâche de «Remplacer Numéros par Astérisques» dans une liste _ 52 Figure II-1-23 : Dialogue entre l Application et AIDE lors de l exécution d une commande 54 Figure II-1-24 : Dialogue entre l application et AIDE en mode enregistrement de macro 54 Figure II-1-25 : Dialogue entre l application et AIDE en mode exécution de macro 54 Figure II-1-26 : Apprentissage des applications cibles. 56 Figure II-1-27 : Gestion des scripts sous PbDScript 56 Figure II-1-28 : Affichage de la hiérarchie des widgets dans PbDScript 57 Figure II-1-29 : Gestion d événement émis par l application cible (AC) 59 Figure II-2-30 : Phase d espionnage d Eager représentant l enregistrement 63 Figure II-2-31 : Anticipation des actions utilisateur par Eager 64 Figure II-2-32 : Menu du système Eager 64 Figure II-2-33 : Structure du modèle Prototype 67 Figure II-2-34 : Structure du modèle Design Pattern Commande 69 Figure II-2-35 : Modélisation des relations entre source d événements et écouteur 70 Figure II-2-36 : Triplet de base du modèle MVC 70 Figure II-2-37 : Schéma de composition fonctionnelle de l exemple 73 Figure II-2-38 : Schéma des fonctionnalités principales 75 Figure II-2-39 : Partie du modèle avec ListCell 76 Figure II-2-40 : Partie du modèle avec EventCell 76 Figure II-2-41 : Partie du modèle pour les abstractions MVC

7 INTRODUCTION GENERALE L ordinateur est un automate déterministe à états finis. il répond aux instructions données par l utilisateur à travers les fonctionnalités des applications. Ces derniers proposent souvent des fonctions génériques qu il conviendrait d adapter à chaque utilisateur. Ceci fut reconnu lors d une étude dont le résultat figure dans le rapport du groupe de travail constitué sur le thème «End-User Computing» en 1991 au cours de la conférence SIGCHI 91, à la Nouvelle-Orléans [Myers 1992]. La réponse naturelle à ce besoin consiste à permettre à l utilisateur de modifier la programmation de son application. La programmation est-elle accessible à un utilisateur final quelconque? La programmation textuelle classique, en dépit de l évolution très grande des langages utilisés, n est pas à la portée de tous les utilisateurs sans un effort d apprentissage souvent disproportionné. L introduction des systèmes de programmation sur exemple a été une très grande évolution dans le cadre de la programmation utilisateur. Halbert a recensé et comparé les approches permettant à l utilisateur final (non-programmeur) de créer des programmes [Halbert 1984]. L idée générale est qu il est plus facile de comprendre le programme que l on cherche à écrire si celui-ci s exécute parallèlement à sa construction. Afin de mieux cerner certains concepts du domaine, faisons un bref parcours historique du phénomène. L émergence des environnements de développement utilisables par un utilisateur final non-informaticien a consisté en l utilisation d exemples d exécution pour la conception des programmes : «Example-Based Programming». Au lieu de sélectionner des fonctions et définir des variables sur lesquelles les fonctions s appliqueront, l utilisateur utilise des fonctions sur des valeurs, qui se comportent comme des variables d un programme. Une des idées principales est d éviter le niveau d abstraction des variables en autorisant l utilisateur à manipuler des exemples. Dans ce même cadre, Halbert [Halbert 1984] définit une notion importante : l inférence («Inferencing»). Un système est dit avec inférence s il est capable de déduire des actions de l utilisateur un programme, sans que ce dernier ait effectivement dit comment le faire. En 1988, Myers cherche à préciser ce principe [Myers 1988]. Il parle alors d inférence plausible («Plausible Inferencing» ou abstraction) pour caractériser les systèmes qui génèrent des explications ou des généralisations basées sur des informations limitées. Ces explications peuvent se révéler incorrectes, et ces systèmes prennent souvent l initiative d un dialogue avec l utilisateur pour lever l ambiguïté. Ceci le conduit à distinguer ce qu il appelle «Programming-With- Example», sans inférence plausible, et «Programming-By-Example», avec inférence plausible. Halbert [Halbert 1984] les caractérise respectivement par les formules «Do What I Did» («Fais ce que j ai fait») et «Do What I Mean» («Fais ce que je pense»). Chez Apple Computing s est tenu en 1992, un Workshop où les pionniers du domaine de l «Example-Based-Programming» ont effectué nombre de démonstrations de leurs systèmes. En dehors du recueil (et souvent de la réécriture) de leurs travaux dans un ouvrage qui fait aujourd hui référence [Cypher 1993], les

8 participants ont affiné les définitions et proposé une nouvelle expression, «Programming by Demonstration» (PbD), qui aujourd hui est largement acceptée. Nous détaillerons ce concept plus en profondeur dans ce rapport. L ensemble des termes utilisés dans le domaine est d origine anglaise. On se trouve confronté à des problèmes de vocabulaire du fait que le poids de la langue anglaise est considérable en informatique. En 1990, Lieberman [Lieberman 1990] définit l expression «programmation par l exemple» en français. Lieberman prend comme point de départ l idée d utiliser des exemples pour enseigner un processus à l ordinateur dans un environnement de programmation. Il se base sur l idée qu une interface graphique est un langage permettant à l utilisateur de demander à l ordinateur de réaliser ses intentions. D après Allen Cypher, si l'utilisateur est capable d'accomplir une tâche sur un ordinateur, alors il est suffisant pour le système de créer un programme pour généraliser sa tâche [Cypher, Kosbie et al. 1993]. C est dans ces termes qu il définit ainsi le principe de «Programming by Demonstration». En 2000, Girard dans [Girard 2000] apporte des définitions claires aux termes et expressions employés. Par exemple la traduction mot à mot du terme «Programming by Demonstration» en «Programmation par démonstration» dans la langue française n est pas exacte car le mot «démonstration» ne le permet pas dans cet contexte. La définition de Girard nous semble bien appropriée : l expression «Programmation Sur Exemple» convient mieux pour le terme «Programming By Demonstration» (ou PbD). Tout au long de ce rapport, nous essaierons de présenter des définitions (d autres auteurs ou propres à nous) pour chacun des termes ou expressions ambigus utilisés. Si l on se limite à l étude des systèmes dit de Programmation Sur Exemple (nous utiliserons désormais l acronyme anglais PbD), on peut constater un certain développement du concept à travers de multiples systèmes. Plus d une trentaine d entre eux ont ainsi été réalisés, explorant différentes voies de réalisation, et permettant de valider la paradigme. Cependant, malgré un évident intérêt, cette technique a rarement dépassé le cadre des laboratoires de recherche. L une des raisons de cette absence de discrimination peut être recherchée dans la difficulté d implémentation de la PbD. Nous verrons que cette dernière nécessite de nombreux efforts, en l absence d outils utilisables. Le but de notre travail consiste à combler cette lacune. Dans un premier temps une analyse précise des concepts et systèmes de PbD s avère nécessaire, afin de vérifier la portée d une démarche globale de conception d outils de PbD. Dans un deuxième temps, la recherche d une solution de type boîte à outils générique sera effectuée, en s appuyant sur un exemple concret. Le contenu de ce rapport se divise en deux parties. Une première partie sur l état de l art et la seconde sur les besoins en terme de boîte à outil de PbD. La première partie fait l état de l art des systèmes de programmation sur exemple. Elle comporte deux chapitres. Le chapitre un retrace la succession des différents systèmes et présente leur fonction. Le chapitre deux fait une classification des

9 systèmes en fonction des besoins de l utilisateur. Ce chapitre présente les domaines d application de la PbD et les modes de programmation utilisés. La deuxième partie porte sur l étude des besoins en terme de boîte à outil de la programmation sur exemple. Elle contient deux chapitres. Le premier chapitre définit les besoins pour la réalisation d une application de PbD. Dans ce chapitre, nous parlons aussi de deux systèmes AIDE[Piernot and Yvon 1993] et PbDScript[Depaulis, Guittet et al. 2003] qui sont des tentatives de résolution des besoins que nous avons définit. Le deuxième chapitre présente les éléments à mettre en œuvre pour la réalisation d une boîte à outils en nous appuyant sur l exemple du système Eager [Cypher 1991]. Ce présent rapport, comme tout rapport de stage, se termine par une conclusion dans laquelle nous établissons une synthèse de nos travaux et les perspectives pour de futures recherches

10 Première partie : Etat de l art Avant la vulgarisation de l informatique, les logiciels existants étaient destinés à des applications précises et pour un nombre restreint d utilisateurs. Ceci était dû au fait que la plupart des utilisateurs étaient des programmeurs. Ils fabriquaient ou commandaient eux-mêmes les outils correspondant à leurs besoins et à leur personnalité. Or il n est pas à démontrer que les préférences varient d un utilisateur à l autre. L avènement de l ordinateur personnel et la croissance du nombre d utilisateurs ont rendu caduque l ère des logiciels sur mesure. Actuellement, un logiciel est construit pour être utilisé dans plusieurs types d applications, par un public nombreux et, composé en majorité de non-programmeurs. De ce fait, les produits sont de plus en plus impersonnels. Dans la plupart des logiciels existants (et notamment dans les interfaces à manipulation directe), il n est pas rare que l utilisateur ait à exécuter des tâches très répétitives. Malheureusement, une personne ne sachant programmer n est pas capable de faire comprendre à un système ce qu elle aimerait lui voir accomplir, si cette tâche ou action n a pas été prévue par le concepteur. Comment faire en sorte qu un utilisateur final, ignorant tous des principes de la programmation, puisse personnaliser les logiciels qu il utilise? S il est capable d exécuter des actions dans un environnement donné, pourquoi ne pas mettre à sa disposition les moyens nécessaires pour qu il puisse créer ses propres actions, tout en restant dans un environnement familier? Pour répondre à ces questions, plusieurs approches ont été envisagées. Nous verrons ces différentes approches permettant de résoudre le problème de la personnalisation des systèmes par des non-programmeurs dans cette partie. Nous détaillerons les principes de la programmation sur exemple et effectuerons une classification de ces systèmes en fonction des besoins même de la PbD

11 CHAPITRE I : LES SYSTEMES DE PERSONNALISATION L instrument idéal pour la résolution des tâches répétitives est l ordinateur. Pourtant, c est à l utilisateur d accomplir la plupart des actions de ces tâches. Pour adapter lui-même une application à ses propres besoins, l utilisateur doit modifier la logique mise en place par le programmeur de l application. Pour faire cela, différentes approches ont été développées. Depuis les années 75, plusieurs techniques ont vu le jour, des préférences à la programmation sur exemple en passant par les enregistreurs de macros et les langages de scripts. I-1 LES PREFERENCES, LES ENREGISTREURS DE MACROS ET LES SCRIPTS I-1-1 LES PREFERENCES Les préférences (exemple donné par la figure I-1-1) sont prévues par le programmeur lors de la réalisation d application. Ils sont très simples à mettre en œuvre et à utiliser. Il s agit d un ensemble d alternatives fixes, offertes par le concepteur, présenté (en général) sous forme de cases à cocher. Leur possibilité d utilisation est restreinte aux choix prévus par le concepteur. Elles constituent la façon la plus élémentaire de modifier le comportement d une application, même si elles ne mettent pas en œuvre une réelle programmation. Figure I-1-1 : Préférence du Mail sous Mac OS X

12 Plus les préférences offrent des possibilités, plus elles sont difficiles à manipuler moins elles respectent les critères ergonomiques. Bien qu utiles, elles présentent deux limites importantes. Du fait des besoins potentiellement variés des utilisateurs, elles ne peuvent répondre à leur totalité. Les préférences ne permettent d accommoder qu un nombre fini de situations prévues par le concepteur de l application. La seconde limitation est ressentie lorsqu il faut répondre au plus de besoins possibles. Dans ce cas, un nombre important d options doit être proposé, rendant ainsi la configuration de l application très difficile par l utilisateur. I-1-2 LES ENREGISTREURS DE MACROS Ils sont très fréquents dans les éditeurs de textes. Les enregistreurs de macros permettent aux utilisateurs de créer un programme (appelé macro) dans le langage de l application en enregistrant la séquence de commandes qu ils effectuent. Tout comme les préférences, les enregistreurs de macros sont aussi prévus par le concepteur de l application. Leur utilisation très simple se résume au lancement du système par un simple click sur bouton (en général «Enregistrer Macro»), à jouer ou exécuter les actions désirées et à stopper l enregistrement par un simple click. Sur une demande de l utilisateur, la macro rejoue toutes les actions (enregistrées sous forme de séquences) effectuées par l utilisateur durant la période d enregistrement. Beaucoup de logiciels proposent un enregistreur de macro : des traitements de texte aux logiciels de communications en passant par les tableurs. Certains systèmes comme QuicKeys ou AppleScript proposent l enregistrement de macro étendu à tout le système. Cela a l avantage de présenter un mécanisme unique à l utilisateur et de pouvoir créer des macros mettant en œuvre plusieurs applications. Les enregistreurs de macro permettent à l utilisateur de créer des macros pour automatiser des tâches simples sans avoir à apprendre un langage de programmation. Par exemple, dans un traitement de texte la tâche peut être d'insérer la date courante à chaque fois qu'un nouveau document est créé, dans un logiciel de télécommunications elle peut être de charger périodiquement le cours d'une action donnée et dans un tableur, de tracer le graphe mensuel d'une valeur boursière

13 Figure I-1-2 : Enregistreur de macros sous Word97 (Windows) Les enregistreurs de macros possèdent un très faible paramétrage, mais certains problèmes demeurent néanmoins. Les enregistreurs de macros sont très littéraux. La séquence de commandes enregistrée est rejouée sans discernement de leur part. Par exemple, lorsqu il s agit de copier un fichier dans un répertoire du bureau, si celui ci se trouve renommé ou pire déplacé, la macro aura un comportement incorrect. Enfin, pour comprendre ou modifier le comportement d une macro existante, il faut connaître le langage de programmation de l application ou du système. On retrouve alors de la vrai programmation. I-1-3 LES SCRIPTS Ce sont de petits et simples programmes très populaires. Un langage de script est un langage de programmation dont la syntaxe est restreinte aux objets et actions d application particulière. Les scripts sont facile à apprendre. L utilisateur doit développer complètement un script pour l élaboration de l automatisation d une tâche

14 Figure I-1-3 : Exemples de script sous Mac OS X (Récupération de mail sous Eudora) L utilisateur doit donc tout apprendre du langage, ce qui l oblige à devenir un programmeur. Le domaine d application des scripts est très restreint. En général, les scripts écrits sur une plate forme ne n exécutent que sur la même plate forme. Ils ont les même inconvénients que les enregistreurs de macros dans la plupart des actions. I-2 LA PROGRAMMATION SUR EXEMPLE La programmation a beaucoup évolué de nos jours. Dans les années 80, de nombreux projets ont jeté les bases de la programmation visuelle. L idée principale de cette approche est de remplacer les mots par des images. La programmation visuelle utilise des images qui donnent un sens beaucoup plus intuitif à la programmation. Cette méthode a permis d introduire des images pour remplacer, par exemple, les variables et les fonctions des programmes. Cependant, son application se cantonne à la représentation de programmes statiques. Elle ne permet pas de visualiser le programme au fur et à mesure de son exécution. L utilisation d exemple pour concevoir des programmes constitue le second pas vers les environnements de programmation pour utilisateur final. La programmation a

15 évolué du remplacement des mots par les images (programmation visuelle) à la programmation basée sur exemple (Example-based programming) en passant par la programmation par l utilisateur final (End-User programming). C est la notion de conception de programmes à partir d exemples. L utilisateur conçoit lui-même ses fonctions sur des valeurs réelles, utilisées comme variantes par le programme. Le concept de la programmation sur exemple trouve son origine dans le système Pygmalion [Cypher 1993] réalisé par David SMITH en Il a été approfondi par Daniel C. Halbert en 1984 lors de sa thèse. En 1980, Brad MYERS dans ses travaux formalise le concept et lui donne le nom de Example-based programming. Plusieurs travaux de recherche se sont succédés sur le sujet. En 1993, Allen CYPHER fait un récapitulatif des systèmes de PbD existants [Cypher 1993] et introduit la notion de Programming by Demonstration. L idée principale est d éviter le niveau d abstraction des variables manipulées par l utilisateur et de ne lui permettre d interagir qu avec les valeurs des objets. I-2-1 DEFINITION La PbD est une extension du concept des enregistreurs de macros [Cypher, Kosbie et al. 1993]. Ces derniers sont à même d enregistrer les actions de l utilisateur et de les rejouer à la demande. Cependant l exécution des macros ainsi réalisées ne prend pas en compte le contexte de création ou d exécution. L enregistrement est au niveau des commandes et des clics souris. Dans le cas de la PbD, le système produit une généralisation des actions enregistrées. Durant la conception d un programme, le système analyse les entrées de l utilisateur, et construit le programme à même de générer l exemple. La PbD est donc une approche permettant de créer des programmes en s'appuyant sur le comportement ou les effets d'exemples. C est une approche permettant de créer des programmes en s appuyant sur les actions réalisées par l utilisateur lors de la construction d exemples. Le système enregistre et généralise le comportement ou les effets de l exemple. L utilisateur final est le programmeur qui ne programme que par l intermédiaire d une interface. Dans [Girard 2000], il ressort que la PbD n est pas seulement de la programmation visuelle, (c est-à-dire un système de programmation dans lequel la définition du programme peut être effectuée par interaction graphique dans un espace à deux dimensions), mais ce qui fait sa spécificité est qu elle est «basée sur exemple». Un système de programmation est dit basé sur exemple si l utilisateur peut utiliser les valeurs d un exemple d exécution pour définir les objets sur lesquels portent le programme à construire [Girard 1992]. La programmation sur exemple est à l opposé de la programmation avec exemple. Un système de programmation est dit avec exemple si la visualisation des programmes associés à des exemples permet seulement une représentation plus

16 concrète de ce que l on a écrit et non une description concrète de ce que l on veut [Girard 1992]. I-2-2 OBJECTIFS ET CARACTERISTIQUES Le but principal de la PbD est de générer interactivement des programmes. Les systèmes de PbD doivent fournir le pouvoir d expression d un environnement de programmations classiques aux non-programmeurs (éditeur de programmes, structuration de programmes, etc.). La PbD permet de généraliser les suites d actions effectuées par un utilisateur lors de la description d une instance du programme qu il désire écrire. Elle s appuie sur le fait que l utilisateur fait moins d erreurs lorsqu il raisonne sur des exemples que sur des concepts abstraits. Le programmeur n a pas besoin de garder à l esprit l état courant du système (ce qui s avère souvent complexe) si celui-ci est affiché à l écran (sous forme d exemple). La PbD se place à un niveau d abstraction beaucoup plus élevé que les enregistreurs de macros. Elle manipule des objets et la sémantique associée permet de sortir de la simple ré-exécution d actions. La PbD résout des problèmes d interprétation par l intermédiaire de procédures de dialogues sophistiquées ou par l utilisation de règles (notion d inférence [Cypher, Kosbie et al. 1993]). Afin de mieux étayer la PbD, nous présentons des exemples de systèmes de PbD ou utilisant des systèmes de PbD dans la section suivante. I-2-3 QUELQUES EXEMPLES DE SYSTEMES Afin de tester son apport au niveau de la convivialité, la PbD a été utilisée dans un grand nombre de systèmes expérimentaux. Il convient de noter néanmoins que la PbD n est pas utilisée à grande échelle (comme énoncé plus haut). Selon les auteurs des systèmes de PbD existants, l objectif principal est de générer interactivement des programmes. Cela est explicite dans les systèmes Peridot [Myers 1993], Mondrian, SmallStar, ou encore ToonTalk [Cypher 1993]. Aussi les systèmes de PbD cherchent-ils à fournir aux non-programmeurs le pouvoir d expression d un environnement de programmation classique (éditeur, structuration de programmes, etc.). Le plus souvent, ils s attachent également à enrichir et à personnaliser l interface de dialogue du système interactif, en permettant à l utilisateur d associer l exécution d un programme construit interactivement à une commande du système

17 Par exemple, Eager [Cypher 1993] automatise des tâches répétitives entre applications différentes. Metamouse [Cypher 1993] automatise des tâches de programmation répétitives dans un logiciel de dessin. À l inverse Tinker [Cypher 1993] a pour but de favoriser l apprentissage de la programmation elle-même. Les programmes produits n ont pas d intérêt particulier. Pygmalion [Cypher 1993] se focalise sur la création interactive de programmes et Gamut [Cypher 1993] et StageCast Creator [Cypher and Smith 1995] génèrent des applications. Grammex [Lieberman, Nardi et al. 1998] permet la reconnaissance de textes. Enfin, le système EBP [Girard, Potier et al. 1996] crée des outils de conception technique. I Peridot Peridot [Myers 1993] est un système permettant la création de l interface graphique et du contrôleur de dialogue d une application par démonstration. L utilisateur doit donner le nom de la procédure qui sera appelée par l application. Cette procédure provoquera une modification de l interface. Il donne aussi les paramètres éventuels et les valeurs actives (celles qui vont intervenir dans l exemple qu il va construire par la suite) ainsi qu un exemple de valeur pour chacune de ces entrées. Ensuite, le concepteur montre l interface qu il souhaite en construisant un exemple. Il montre alors comment créer la représentation graphique de l interface et comment celle-ci doit répondre aux actions de la souris. Quand l utilisateur fabrique des objets (par exemple deux rectangles), le système Peridot va scruter une base de 60 règles et vérifier s il pense reconnaître la condition d une de ces règles. Dans le cas de l exemple, si Peridot remarque que ces deux rectangles ont sensiblement la même taille, le système demande à l utilisateur s il doit considérer que les deux rectangles ont les mêmes dimensions. Si l utilisateur répond par l affirmative, les deux rectangles sont liés, donc si l un grandit, l autre rectangle fera de même. Pour déterminer une contrainte géométrique de ce type, Peridot n a besoin que d un seul exemple. Il emploie un mécanisme d inférence pour déterminer les contraintes géométriques mais également pour trouver les branchements conditionnels. Ces derniers permettent de tester si une valeur de paramètre ou une valeur active est une constante ou une variable, et aussi pour savoir comment l interface doit réagir aux actions d une souris. Par exemple pour déterminer les branchements conditionnels, le système Peridot s appuie sur des contre-exemples qui doivent, bien sûr, être fournis explicitement par l utilisateur. Aussi pour gérer le comportement de l interface par rapport aux actions effectuées avec la souris (déplacement, clic sur un des boutons), l utilisateur décrit explicitement quelles sont les modifications qu elles entraînent sur le contexte. Enfin, Peridot permet à l utilisateur de personnaliser le système pour une application particulière, en lui laissant la possibilité de définir ses propres règles

18 Figure I-1-4 : Fenêtres utilisées pour créer un procédé en utilisant Peridot I Mondrian Mondrian [Lieberman 1993] est un éditeur graphique orienté objet avec lequel l'utilisateur peut définir de nouvelles commandes par démonstration. Il est destiné aux personnes accomplissant des tâches graphiques et désireuses de créer de nouvelles commandes sans pour autant posséder des notions de programmation. Cet éditeur est très simple et offre une représentation graphique originale des commandes sous forme de dominos : le côté gauche d'un domino est une miniature de l'écran avant exécution de la commande, tandis que le côté droit montre l'écran après exécution (partie gauche de la figure I-1-5 ). Parmi les commandes proposées on trouve la sélection, le déplacement et le groupement d'objets, la création de rectangles, le choix de couleurs etc. La phase de création débute par la sélection des objets graphiques qui constitueront les arguments du programme. Ensuite, l'utilisateur choisit le domino intitulé "Nouvelle Commande" puis fournit le nom de la commande qu'il souhaite définir. Un nouveau domino apparaît alors dans la fenêtre, avec une miniature de l'écran courant en partie gauche et un point d'interrogation en partie droite. L'utilisateur démontre ensuite les étapes nécessaires en faisant appel soit aux commandes de l'éditeur soit à des commandes qu'il a précédemment définies (y compris celle qu'il est en train de créer, autorisant ainsi non seulement l'appel de procédure mais aussi la récursivité). Enfin, il sauvegarde la commande ainsi définie en cliquant à nouveau sur le domino "Nouvelle Commande". Le côté droit du nouveau domino est mis à jour en conséquence : le point d'interrogation est remplacé par une miniature de l'écran représentant l'état final

19 Figure I-1-5 : Mondrian : définition de la macro "Créer Ombre". Pour invoquer un programme, l'utilisateur commence par sélectionner les objets qui doivent être les arguments, puis clique sur le domino représentant le programme à exécuter. Il n'y a aucune différence entre invoquer une commande prédéfinie et une commande créée par l'utilisateur. Ainsi, pour invoquer la commande "Créer Ombre" de la figure, l'utilisateur sélectionne le rectangle qui l'intéresse et clique ensuite sur le domino "Créer Ombre". Mondrian exécute alors les commandes associées au domino "Créer Ombre" : 1. Sélectionner la couleur noire (couleur de l'ombre) ; 2. Créer un rectangle (noir) ayant les mêmes coordonnées que le rectangle sélectionné (l'ombre) ; 3. Décaler le nouveau rectangle (pour créer un effet d'ombrage) ; 4. Amener le rectangle original au premier plan ; 5. Grouper les deux rectangles pour former un objet unique

20 Mondrian n'offre pas de contrôle de l'exécution de la macro. Mondrian implante un certain nombre d'heuristiques afin d'améliorer la lisibilité des miniatures d'écran. Il possède également un algorithme d'apprentissage qui garde trace des relations géométriques entre les objets ainsi que des relations de dépendance entre différentes commandes. Mondrian ne détecte ni les boucles ni les conditions : une commande n'est qu'une séquence linéaire d'instructions ce qui limite sa force d'expression. De façon interne, une commande est représentée comme un objet dont les variables donnent le nom de la commande, décrivent l'image du domino, pointent sur une fonction à appeler lorsque la commande doit être exécutée et pointent sur une liste décrivant la classe des arguments de la commande et l'interaction associée (c està-dire. drag and drop, sélection). I SmallStar SmallStar [Halbert 1993] est une simulation de l'interface graphique du système d exploitation Star de Xerox, à laquelle des capacités de Programmation par Démonstration ont été rajoutées. Star [Smith, Kimball et al. 1982] utilise la métaphore du bureau avec des icônes représentant les différents objets du système (programmes, imprimantes, documents, formulaires, boîtes aux lettres, tableaux etc.). Dans cet environnement, l'utilisateur peut éditer du texte et des graphiques, envoyer et recevoir des messages, remplir des formulaires, accéder à des bases de données et imprimer des documents. Star possède également un langage d'application appelé CUSP (CUStomer Programming) avec lequel l'utilisateur peut développer des applications sur mesure. SmallStar est le premier système de Programmation par Démonstration destiné au grand public, c'est-à-dire à des utilisateurs n'ayant pratiquement aucune connaissance de la programmation, dans le but d'automatiser les tâches répétitives souvent rencontrées lorsqu'ils utilisent le Star et ceci sans avoir recours au langage CUSP. Pour créer un programme l'utilisateur commence par ouvrir un bouton ou une icône programme puis presse le bouton "Start Recording" pour démarrer l'enregistrement (Figure I-1-6 ). Il effectue ensuite les étapes nécessaires puis presse le bouton "Stop Recording" pour arrêter l'enregistrement. Une fois la phase d'enregistrement du programme terminée, l'utilisateur doit effectuer les généralisations nécessaires. Pour chaque type d'objet présent dans le système, SmallStar propose un ensemble de descripteurs de données présentées à l'utilisateur dans une boîte de dialogue. SmallStar permet d exécuter le programme pas à pas afin de suivre son fonctionnement. Dans le cas où une erreur se produirait, SmallStar affiche un message d'erreur et indique l'instruction fautive dans la fenêtre représentant le programme

21 Figure I-1-6 : SmallStar : une macro qui place la dernière version du fichier "Treaty" sur le bureau. Au fur et à mesure que les commandes sont enregistrées, une description textuelle agrémentée d'icônes apparaît dans la fenêtre programme (partie supérieure de la figure I-1-6 ). Les icônes indiquent le type d'objet manipulé (dossier, document, sélection, tableau etc.). SmallStar n'effectue aucune inférence. Au lieu de cela, c'est l'utilisateur qui spécifie les structures de contrôle et les descripteurs de données. Une fois le programme enregistré, c est l utilisateur qui effectue les généralisations nécessaires. Une heuristique présente dans le système consiste à proposer par défaut les descripteurs de données les plus plausibles (ainsi pour un fichier, le nom est le facteur de choix par défaut). Lorsque SmallStar exécute un programme, il utilise les descripteurs de données pour trouver les objets que le programme a besoin. La première fois qu'un descripteur de données est rencontré, SmallStar cherche les objets correspondant à cette description. Si plus d'un objet correspondent à la description, l'un d'eux est choisi arbitrairement. Lorsque SmallStar rencontre à nouveau le même descripteur de données il saute l'étape de recherche et utilise l'objet déjà trouvé. Ainsi, quand un même objet apparaît plus d'une fois dans un programme, toutes les références à cet objet utilisent le même descripteur de données ce qui constitue une heuristique importante. Il est cependant possible de changer manuellement les descripteurs de données pour chaque référence faite à un objet de façon à contrer cette heuristique. SmallStar enregistre les commandes sous forme de commandes haut niveau et non pas comme des opérations souris. Une commande possède un nom et un ensemble d'arguments. Une commande enregistrée peut impliquer plusieurs actions de la part de l'utilisateur. I ToonTalk ToonTalk [Kahn 2001] est un environnement de programmation sur exemple à l aide d exemples dans la métaphore de jeu de construction pour enfant. C est une illustration de l importance de la métaphore et de son adaptation au public visé. ToonTalk est un système de programmation iconique qui s adresse aux enfants (à partir de six ans). Figure I-1-7 : La «main de dieu» dans ToonTalk ToonTalk se base sur une approche particulière : le programmeur est un acteur

22 dans le monde virtuel, où chaque objet abstrait des programmes est représenté grâce à une métaphore. Cette approche le place en marge des systèmes de PbD classiques. S adressant à des enfants, ToonTalk tend à faire l analogie entre la programmation et un jeu de construction. Dans la métaphore utilisée par ToonTalk, chaque objet du monde de la programmation est associé à son équivalent dans le monde de ToonTalk. Un programme complet se représente sous la forme d une ville, les sous programmes et les processus sont représentés par des maisons, que l on peut faire communiquer à l aide de pigeons voyageurs. Ceux-ci peuvent transporter des objets depuis leur maison jusqu à des nids. Chaque maison peut contenir des robots ; ce sont eux qui accomplissent les tâches à l intérieur des sous-programmes. On peut affecter à ces tâches des pré-conditions qui apparaissent sous forme de bulles. Figure I-1-8 : La métaphore utilisée par ToonTalk On peut apprendre à un robot à effectuer sa tâche par l exemple. Cette tâche peut être par exemple : - L envoi d un message : en donnant une boîte à un pigeon ; - La création d un nouveau processus (une nouvelle maison) : en chargeant une boîte et un ou plusieurs robots dans un camion ; - Copier un élément dans une boîte grâce à la «main de dieu» (figure I-1-7) ;

23 - Modifier une structure de données par copier-coller de boîte à boîtes ; - Tuer un processus en envoyant une bombe sur la maison ; - Etc. I Metamouse Metamouse [Maulsby, Witten et al. 1989] est un logiciel de dessin du type MacDraw, programmable par démonstration de façon à automatiser certaines tâches répétitives. Il est destiné aux utilisateurs sans connaissance préalable de la programmation. Ce assistant de dessin possède un nombre restreint de commandes permettant de créer, déplacer et effacer des rectangles et des droites. Metamouse utilise la métaphore de l'apprenti et permet à l'utilisateur de créer de nouvelles commandes en utilisant des outils de construction comme de façon traditionnelle en dessin. Un objet graphique, ayant la forme d'une tortue, appelée Basil, (figure I-1-9 ), correspond à un curseur multifonctions servant à concentrer l'attention du dessinateur sur les capacités d'inférences limitées du logiciel. Basil simule un élève auquel on apprend à dessiner : il prédit les actions suivantes lorsqu'il détecte des répétitions, il demande à l'utilisateur d'effectuer des constructions géométriques et de fournir des paramètres lorsque cela est nécessaire et il génère un programme. Pour spécifier une procédure, l'utilisateur passe en mode enregistrement puis accomplit la tâche sur un exemple. Metamouse observe alors les actions de l'utilisateur et lorsqu'il détecte une répétition c'est-à-dire que l'utilisateur a accompli une même séquence d'actions une seconde fois Metamouse prédit les commandes à venir et offre d'effectuer les itérations suivantes. Dans ce système, non seulement l'utilisateur montre la tâche exemple mais, en plus, il peut mettre en valeur des relations entre objets à l'aide d'outils de constructions, corriger certaines inférences faites par le système ou répondre aux questions posées par Basil. L'utilisateur peut interrompre l'enregistrement pour le reprendre par la suite. Dans la figure I-1-9 ci-dessous, l'utilisateur souhaite enseigner à Basil comment trier des rectangles par hauteur croissante. Pour réaliser ce projet, il commence par créer deux objets de construction l'espaceur et la règle qui seront utilisés par la suite pour exprimer des relations entre objets (a,b). L'espaceur est un segment qui sera utilisé pour déterminer l'espace entre les rectangles dans la configuration finale et la règle est un second segment qui sera utilisé pour désigner chacune des boîtes par hauteur croissante. Dès que Metamouse détecte une répétition il offre à l'utilisateur la possibilité de finir la tâche à sa place (figure I-1-9 g). Une fois le programme créé, l'utilisateur peut l'appeler à nouveau en utilisant le menu "Tasks". Metamouse n'offre pas de visualisation du programme créé à proprement parler. Au lieu de cela il présente l'étape prédite en déplaçant la tortue. L'inférence est utilisée pour identifier les contraintes géométriques dans les commandes d'édition, pour déterminer les boucles et les branchements et pour différencier les variables des constantes

24 Pour chaque commande accomplie par l'utilisateur, Metamouse enregistre les paramètres de la commande ainsi qu'un ensemble d'arguments représentant le contexte dans lequel la commande est exécutée. Metamouse est l'un des rares systèmes capables d'inférer des conditions

25 Figure I-1-9 : Environnement Metamouse

26 I Tinker Tinker [Lieberman 1993] est un environnement de programmation LISP destiné aux débutants pour apprendre la programmation. Il applique à la programmation la métaphore de l apprentissage. Cette approche identifie le programmeur avec un professeur qui va apprendre à Tinker à réaliser une tâche, en spécifiant la procédure de réalisation de cette tâche avec un ou plusieurs exemples. Cette approche présente un intérêt pour le programmeur débutant, car la correspondance entre l exemple et la procédure générale permet de s assurer que l intention du programmeur a été fidèlement capturée. Tinker se compose de plusieurs éléments (figure I-1-10 ) : un menu principal, un menu de sélection des exemples, une fenêtre de définition de l exemple (où l utilisateur peut taper des expressions LISP), une fenêtre de visualisation par exemple et une fenêtre de visualisation en LISP des fonctions définies par l exemple. Figure I-1-10 : Composants de Tinker (avec la représentation de deux exemples) L utilisateur programme par démonstration à l aide de plusieurs exemples en partant du plus simple pour arriver au plus complexe. Chaque fois que le programmeur assigne un nouvel exemple à la même procédure, le système lui demandera de fournir un test permettant de distinguer l exemple le plus récent de ceux qu il connaît déjà. Le programmeur construit des expressions LISP avec Tinker en assemblant des fonctions LISP et leurs arguments dans la fenêtre de définition d exemple. Celle-ci est composée d une liste d éléments comportant deux parties : une expression LISP et sa valeur. Tinker doit disposer toujours d au moins deux définitions pour chaque exemple : une définition pour le cas de base, et une autre pour le cas complexe (où il y a un obstacle). Il fait appel à l utilisateur pour définir un prédicat permettant de choisir

27 quelle définition utiliser, et génère ainsi une procédure conditionnelle. Cette définition se fait de façon interactive et simultanément sur les différents cas. Figure I-1-11 : Bâtir une pile de blocks à l aide de Tinker I Pygmalion Pygmalion [Cypher 1993] de David Smith est un environnement graphique de programmation. C est la première tentative de programmation visuelle, basée sur la métaphore du «tableau noir» : la zone de travail est vue comme un tableau où le programmeur peut «dessiner» ses idées. Pygmalion est à l origine du concept d icône disposant à la fois d une image, d un contenu (du texte pour une icône de document), et d un comportement (déplacement d un fichier par drag and drop). Pygmalion fournit un menu permettant d accéder aux icônes et aux opérations portant sur ces icônes. Il dispose d un champ de texte appelé «mouse value» dans laquelle toute valeur tapée est rattachée à la souris et peut être déposée dans n importe qu elle icône. Lorsque Pygmalion est en mode enregistrement, une zone d historique («remembered») affiche les deux dernières actions exécutées. Le système dispose aussi d une zone «SmallTalk» où le programmeur peut taper et évaluer des expressions écrites dans ce langage. Enfin, il existe une zone «mouse» où l on peut définir le sens d un click avec l un des boutons

28 Figure I-1-12 : Environnement Pygmalion

29 Pygmalion fournit les représentations graphiques standard d arithmétique, de relationnelle et des opérateurs booléens. Pour réaliser la fonction «factorielle» à l aide de Pygmalion, on commence par lui allouer une icône. Ensuite on lui associe deux sous icônes pour représenter l argument et la valeur de la fonction, et on dessine un symbole (voir figure I-1-13) pour la représenter. On rend la bordure invisible et on associe un nom avec l icône par la commande «define». Le système effectue alors une capture d écran : la zone de travail sera restaurée à cet état chaque fois que la fonction sera appelée. L appel de la fonction «define» fait basculer le système en mode enregistrement. On peut alors spécifier le comportement de la fonction, à l aide d un exemple. Figure I-1-13 : Réalisation de la fonction «factorielle» à l aide de Pygmalion I Gamut Gamut [McDaniel and Myers 1999] est un outil de programmation par démonstration destinée à la construction complète d'applications interactives. Il est essentiellement destiné à la conception de petites applications interactives comme les jeux vidéo, les simulations et les logiciels éducatifs. Cet outil permet de fabriquer des jeux simplement en montrant à l ordinateur comment le jeu doit fonctionner. Concrètement, le concepteur commence par représenter visuellement à quoi doit ressembler le jeu. Il définit les éléments visibles et invisibles pendant la phase d exécution. Il place les objets graphiques et widgets sur une zone d édition

30 Figure I-1-14 : Environnement Gamut Par exemple sur la Figure, nous avons représenté un chemin fermé défini par des flèches. Nous y avons placé un objet rectangle dont le rôle est de se déplacer sur l'extrémité des flèches quand l utilisateur appuie sur le bouton move. Figure I-1-15 : Représentation graphique d un jeu Pour le mécanisme de programmation, l outil Gamut dispose de 2 boutons Do Something! et Stop that!. Le développeur utilise Do Something! pour ajouter un nouveau comportement. Le concepteur provoque un événement, par exemple l appui sur le bouton move. Quand un objet ne répond pas, le développeur sélectionne ce bouton et presse le bouton Do Something!. Cela indique au système Gamut que le développeur est prêt à lui montrer une nouvelle manipulation sur les objets du jeu. Sur la Figure I-1-16, le concepteur déplace l objet rectangle vers l extrémité de la flèche suivante. En mettant en sur brillance la flèche de liaison, il précise aussi le chemin à suivre. Et finalement il valide la programmation par démonstration par l appui sur un bouton

31 Figure I-1-16 : Programmation du jeu précédent (Figure I-1-15) À ce moment, Gamut a traduit le fait que si l utilisateur clic sur le bouton move, le rectangle suit le chemin démontré pendant la programmation. Chose importante aussi, le déplacement du rectangle ne se limite pas seulement à la portion d une flèche. Gamut va déduire le déplacement total que pourra prendre le rectangle. Sur notre exemple, le rectangle se positionnera sur toutes les extrémités des flèches. Le système Gamut essaie de déduire des actions du «programmeur» une généralisation permettant de construire l application. Par contre le bouton Stop that! stipulera les déplacements à ne pas réaliser sur le jeu. En résumé, l'utilisateur représente visuellement la ressemblance du jeu et définit les éléments visibles de la phase d'exécution. Gamut permet à l'utilisateur de modifier le comportement d'un objet à l'aide d un menu interactif. Cette modification peut être l'ajout ou l'annulation de comportements. Le système déduit une généralisation des actions de l'utilisateur, permettant de construire l'application. Le comportement d'un programme peut être corrigé de manière interactive sur une exécution. Le mécanisme de généralisation consiste en la création automatique de structures de contrôle d'un programme modifié après la première exécution. I EBP EBP (Example Based Programming) [Girard, Potier et al. 1996] est un environnement de développement de programmes paramétrés, susceptibles de générer des comportements standard. Il permet en particulier de mettre au point par manipulation directe et visuelle les programmes générés. EBP utilise des techniques de PbD permettant la création de familles de composants standard portables par des utilisateurs de systèmes de conception assistée par ordinateur. Basé sur une interprétation orientée vers la sémantique des interactions utilisateurs, EBP utilise comme représentation interne un arbre de syntaxe abstraite. Il utilise une double capture : au niveau lexicographique (pour filtrer les commandes et les désignations autorisées) et au niveau sémantique