Représentation et correction de programme dans les systemes de programmation sur exemple
	Problèmes particuliers de la Programmation de Métamorphoses
Fabrice Depaulis
Laboratoire d’Informatique Scientifique et Industrielle (LISI) & Laboratoire Signal Image Communication (SIC)
Ecole Nationale de Mécanique et d’Aéronautique (ENSMA)
Téléport 2 – 1, rue Clément ADER – BP 40109
86961 FUTUROSCOPE Cedex
Résumé — La Programmation sur Exemple permet à un utilisateur non programmeur de créer de véritables programmes informatiques par la simple exécution d’une de leurs instances. Si les systèmes existants permettent de remplir une partie de ce travail, peu s’intéressent au problème de la représentation et de la correction de programmes générés par ce biais, la solution la plus utilisée restant un simple listing textuel. Nos travaux ont pour objet l’utilisation de la Programmation sur Exemple dans le cadre de la programmation de métamorphose, comme par exemple la croissance de plante. Dans ce domaine, les processus de construction sont des processus de mise au point et nécessitent de nombreux retours en arrière. Il s’agit donc, pour nous, de dégager des solutions interactives permettant à un utilisateur de visualiser et de corriger le programme correspondant à la métamorphose qu’il désire simuler.

1.	Introduction
De nos jours, le monde de l’informatique est confronté à une contradiction. D’un côté, les utilisateurs de systèmes informatiques se trouvent être de plus en plus des “ utilisateurs finaux ” ne sachant utiliser un ordinateur que dans le cadre restreint d’un environnement donné et d’un nombre d’applications limité. De l’autre, l’apparition de tâches répétitives dans les environnements à manipulation directe, ainsi que le besoin naissant de spécialiser des applications de plus en plus généralistes (Excel permet aussi bien de faire la liste de ses courses que de gérer la paye des employés d’une société) suscitent le désir, chez ces mêmes utilisateurs, de réaliser de véritables programmes.
Pour résoudre ce problème, beaucoup de systèmes ont tenté, depuis 20 ans, comme décrit dans [Girard 00], d’utiliser la Programmation sur Exemple (PbD pour Programming by Demonstration). La PbD repose sur la constatation qu’il est plus facile de raisonner sur des valeurs concrètes que sur des concepts abstraits et sur le principe que si un utilisateur est capable d’exécuter une tâche particulière alors le système doit être capable d’enregistrer et de généraliser cette tâche pour en créer un programme informatique.
L’objectif de nos travaux est d’appliquer les principes de la PbD à la programmation de métamorphoses. Il s’agit de permettre à un utilisateur de créer de manière interactive le programme décrivant les transformations subies par un objet au cours du temps, comme par exemple celles affectant une plante au cours de sa croissance. Dans ce domaine particulier, le concepteur est un expert du domaine. Il connaît le résultat auquel il veut parvenir, par exemple l’aspect global d’un arbre à sa maturité, mais il n’en maîtrise pas les étapes constructives. Il se distingue d’un “ utilisateur final ” par le fait qu’il tient à comprendre les mécanismes mis en œuvre et qu’il ne veut pas de système “ magique ” agissant comme une boîte noire. De ce fait, la conception du programme correspondant se fait par essai–erreur–correction. Un tel processus de construction n’est envisageable que dans la mesure où le système autorise à chaque instant une visualisation compréhensible et une correction simple du programme en cours de réalisation. D’autre part, il nous confronte naturellement au double problème de la représentation et de la correction de programme.
Ce problème est commun à tous les systèmes de PbD existants. Sachant que l’utilisateur n’a qu’une connaissance dynamique du programme (celle de l’exemple qu’il a exécuté), comment en donner une vision statique et compréhensible ? Comment, d’autre part, en permettre une modification intuitive ?
Cet article présente les approches utilisées par différents systèmes de PbD pour résoudre le problème de la représentation et de la correction d’un programme. Il met également en évidence les particularités de l’utilisation d’une telle méthode dans le cadre de la programmation de métamorphoses.
2.	Motivations - Difficultés
La plupart des systèmes de PbD s’intéressent à la création de programmes sans se préoccuper de leur visualisation. Pourtant, un utilisateur peut avoir de nombreuses raisons d’en consulter une représentation statique. D’après [Modugno 93] l’utilisateur doit avoir accès à une représentation de son programme pour pouvoir en vérifier l’intégrité, le corriger, modifier les généralisations effectuées par le système ou encore le réutiliser dans le cadre d’un nouveau programme.
La représentation d’un programme créé par PbD pose deux problèmes liés à la nature même de la PbD. Le premier concerne la structure du programme. La PbD évitant à l’utilisateur une partie de l’effort de conception, comment rendre un programme compréhensible à un non programmeur sachant qu’il n’en possède aucune représentation mentale ? Le second problème relevé par [Kurlander 93] est celui de la difficulté à représenter des objets qui ne sont pas convertibles de manière intuitive en termes textuels, comme par exemple des attributs graphiques ou des propriétés géométriques.
D’autre part, comme il est dit dans [Myers 98], trop peu de systèmes de PbD s’intéressent à la correction, considérant que tous les programmes créés par PbD fonctionnent du premier coup et n’ont jamais à être modifiés. Ce problème est intimement lié à celui de la représentation : un utilisateur ne peut modifier un programme que s’il peut agir sur une représentation compréhensible de celui-ci.
Il est donc primordial de parvenir à offrir à l’utilisateur une représentation statique du programme exploitable, rendant compte à la fois de la structure et des objets manipulés.
3.	Représentation et correction de programme dans les systèmes de PbD
Les problèmes de représentation et de correction de programme dans les systèmes de PbD ont souvent été négligés. Nous recensons ici plusieurs systèmes de PbD en essayant de mettre en évidence les choix utilisés pour résoudre des difficultés.
3.1.	Textuelle
La plupart des systèmes se contentent d’une représentation textuelle des programmes qu’ils ont générés. Dans ces circonstances, les corrections se font presque toujours en éditant le code et en le modifiant “ à la main ”.
Tinker [Lieberman 93a] est un environnement de programmation s’adressant à des programmeurs débutants et permettant de créer des programmes LISP. Pour construire un programme, l’utilisateur définit des instructions textuellement en désignant leurs arguments parmi la liste des instructions déjà connues. Chacune d’entre elles est composée d’une partie “ Result ” et d’une partie “ Code ”, représentant respectivement l’instance de l’instruction et sa généralisation. Dans ce système la représentation du programme est textuelle et la correction se fait également textuellement, par ajout et suppression d’instructions.
Smallstar [Halbert 93] permet d’automatiser des tâches répétitives dans un système d’exploitation graphique autorisant la manipulation directe. Pour enregistrer une action, comme par exemple déplacer le contenu d’un répertoire, l’utilisateur exécute simplement son opération interactivement. Il a ensuite accès à une représentation semi-textuelle semi-icônique du programme créé (les objets sont représentés sous la forme qu’ils ont dans le système d’exploitation mais les actions sont décrites de manière textuelle). Il peut utiliser cette représentation pour corriger le programme en modifiant “ à la main ” la généralisation (comme par exemple le critère de sélection du répertoire : nom, position, etc.) ou en ajoutant et supprimant des structures de contrôle.
Topaz [Myers 98] est un système permettant de créer des programmes agissant sur les objets de différentes applications graphiques. Il permet aussi bien de subdiviser un rectangle en trois “ sous-rectangles ” dans un éditeur de dessin que de simplifier des associations de portes logiques dans un éditeur de circuits électroniques. La représentation d’un programme se réduit à la liste textuelle des actions qui le composent. Pour modifier un programme, l’utilisateur peut sélectionner certaines actions pour les supprimer ou les dupliquer.
On voit bien à travers ces quelques exemples que de telles solutions sont difficilement acceptables : alors qu’on essaye d’alléger le travail du concepteur par des méthodes de construction toujours plus graphiques et interactives, on impose en même temps un formalisme de représentation rébarbatif et parfois simplement inaccessible. Dans le contexte qui nous intéresse, une telle représentation nuirait à l’interactivité que l’on désire mettre en place : le concepteur désire connaître l’aspect du programme qu’il crée mais au prix d’un effort de lecture limité.
3.2.	Anticipation
Certains systèmes présentent la particularité de permettre aux utilisateurs de créer des programmes à leur insu. Ils partent du principe que, souvent, l’utilisateur ne sait pas que l’action qu’il va entreprendre est “ automatisable ” : la PbD est donc cachée et c’est le système qui repère lui-même les actions répétitives et tente de les automatiser.
Metamouse [Maulsby, 89] permet d’automatiser des tâches répétitives dans un éditeur graphique. L’utilisateur exécute des suites d’actions qui sont enregistrées et analysées par le système. Dès que ce dernier pense reconnaître un motif répétitif, il propose, par l’intermédiaire d’un agent “ instructible ” (la tortue Basil), d’exécuter le pas suivant du programme tout seul en montrant au concepteur ce qu’il pense être la prochaine action.
Eager [Cypher 91] est également un système latent qui permet lui de repérer des tâches répétitives dans des applications de Bureautique. De la même manière que Metamouse, dès qu’il reconnaît un motif répétitif, il montre le prochain pas d’exécution en utilisant la surbrillance et propose à l’utilisateur de terminer l’action à sa place.
Dans ces deux cas, la représentation du programme est sous-jacente : le système n’en donne jamais une vue statique directement exploitable par l’utilisateur. Il se contente de lui donner un aperçu dynamique qui permet simplement de savoir s’il a bien saisi ses intentions. Cette solution, si elle convient dans un contexte où la programmation est totalement cachée à l’utilisateur, est impensable dans le contexte qui nous intéresse : on souhaite réaliser un système d’aide à la programmation de métamorphose dans lequel le concepteur sait qu’il est en train de créer un programme et veut pouvoir en consulter une représentation. D’autre part, de telles méthodes ne permettent pas d’envisager d’éventuelles corrections, alors que c’est justement un des aspects qui nous font envisager l’utilisation de la PbD.
3.3.	Corriger sans représenter
Quelques systèmes tentent de résoudre le problème de la correction de programme sans le représenter de manière statique.
EBP [Potier 95] est un système de CAO permettant de créer des familles de composants industriels à partir de la description interactive d’une seule de leurs instances. Il s’adresse à des experts en CAO. Pour créer le programme correspondant à la construction d’une pièce, l’utilisateur décrit les paramètres (hauteur, largeur, etc.) puis fabrique sa pièce interactivement. Il peut ensuite rejouer le scénario en donnant de nouvelles valeurs et obtenir ainsi une exécution différente (et donc une pièce différente). Dans EBP, il existe une représentation textuelle du programme créé, le système générant aussi bien des programmes Fortran que des fichiers d’échange Autocad ou EXPRESS. Mais cette forme n’existe que pour permettre des échanges entre systèmes et en aucun cas à des fins de visualisation. Il n’est d’ailleurs pas possible d’apporter des modifications au programme en éditant le code. Pour ça, EBP fournit un mécanisme interactif évolué consistant à exécuter le programme depuis le début jusqu’au point de modification et à enregistrer de nouvelles actions à partir de ce point.
Pavlov [Wolber 96] est un système de création d’interfaces animées sans programmation. Il s’appuie sur un modèle Stimulus/Réponse : l’utilisateur spécifie le comportement de l’interface en associant interactivement à des actions de l’utilisateur les transformations graphiques que ceux-ci déclenchent. Aucune représentation statique du programme généré n’est disponible mais on peut accéder aux propriétés d’un objet de l’application et voir à quels stimuli ils répondent. Inversement, on peut dresser la liste des objets modifiés par un stimulus particulier. Cette représentation sous forme de feuille de propriétés ne permet de modifier le programme que textuellement.
Gamut [McDaniel 99] est un système permettant de construire des animations et des jeux 2D. Le processus de construction d’un programme suit celui d’une perpétuelle correction : à tout moment, on peut modifier le comportement courant d’un objet de manière interactive. Deux boutons (Do Something et Stop That) permettent d’ajouter de nouvelles informations relatives au comportement d’un objet et d’annuler des comportements non désirés. Ainsi, si le système ne possède pas de représentation statique du programme, il est tout de même possible, sur une exécution, de le corriger de manière interactive.
Ces systèmes considèrent que l’utilisateur n’a pas besoin d’accéder à une représentation du programme autre que celle constituée par son exécution, et cherchent des moyens interactifs pour en permettre sa correction. Si ces solutions sont séduisantes pour des non programmeurs, elles ne conviennent pas aux concepteurs de métamorphoses : ceux-ci veulent pouvoir comprendre leur programme dans le détail et ceci n’est possible que par une représentation statique.
3.4.	Comic-Strip Metaphor
La “ Comic-Strip-Metaphor ” est la seule solution graphique au problème de représentation. Elle consiste, d’aprés [Kurlander 88], à représenter l’historique d’une application sous la forme d’une série de deux images, montrant l’état de l’application avant (prologue) et après (épilogue) l’exécution d’une action. Cette mise en forme permet de ne pas avoir à établir de nouvelles conventions, l’utilisateur faisant lui-même les opérations mentales menant d’un état à l’autre.
“ History Based Macros by Example ” [Kurlander 92] est une amélioration du système de macros de Chimera, un éditeur d’interfaces et de dessins en 2D. Il permet d’automatiser certaines tâches en utilisant un historique graphique des actions de l’utilisateur. Au contraire de nombreux systèmes, on peut, dans Chimera, décider de créer un programme après en avoir exécuté un exemple : Pour en concevoir un, l’utilisateur commence par effectuer une série d’actions, puis consulte l’historique graphique. Cet historique consiste en une séquence d’images portant le nom de chaque action et représentant l’objet affecté ainsi qu’une partie du contexte. Le concepteur peut ensuite sélectionner la série d’actions à partir de laquelle il veut créer un programme et déterminer les paramètres en attribuant des noms aux objets désignés comme tels. La représentation d’un programme est donc une partie d’historique graphique généralisée. Les modifications se font par édition de la séquence d’actions : on peut changer les paramètres ou ajouter de nouvelles transformations. Pour réaliser ce dernier point, toutes les actions postérieures à l’action insérée sont annulées puis réintroduites après la propagation de celle-ci.
Mondrian [Lieberman 93b] est un éditeur graphique permettant de créer de nouvelles commandes par PbD. Dans ce système, toutes les commandes sont représentées par un doublon Prologue/Epilogue, montrant le type d’objet affecté et les effets produits. Pour décrire une nouvelle commande, l’utilisateur modifie un objet de départ en lui appliquant différentes opérations pour arriver à un objet final. Le programme consultable par l’utilisateur est composé des états successifs de l’objet, enregistrés sous une forme graphique. La commande associée est illustrée par un doublon utilisant la première et la dernière étape de la transformation. Contrairement aux macros de Chimera, on ne peut pas modifier le programme en utilisant sa représentation graphique.
KidSim [Cypher 95] est un logiciel permettant à des enfants de créer des animations et des jeux 2D dans un espace discret. Les programmes sont gérés par des règles, décrites interactivement par l’utilisateur : il sélectionne un objet et son contexte et leur applique à un certain nombre de transformations. La règle ainsi créée est consultable de manière graphique : elle comprend deux images représentant respectivement l’état de l’objet et de son contexte avant et après l’application des opérations de transformation. La suite des règles constitue le programme. Il n’est pas possible de modifier une règle autrement qu’en la décrivant à nouveau complètement.
Il semble que la solution des “ Comic-Strips ” soit la plus proche de celle que nous voulons mettre en place en programmation de métamorphose : elle permet de représenter le programme d’une manière graphique qui s’adapte à la répétition implicite qu’on trouve dans les phénomènes de croissance (découpage en étapes). Le concepteur peut également l’appréhender facilement et, couplée à une méthode interactive de correction, elle doit permettre de contrôler aisément la simulation d’une métamorphose.
4.	Programmation de métamorphoses et PbD
Dans le cadre de la programmation de métamorphoses, l’application de la PbD, ainsi que les problèmes de représentation et de correction de programmes, présentent un certain nombre de particularités.
4.1.	Pourquoi la PbD
Les systèmes de programmation de métamorphose (ensemble d’opérations décrivant les transformations géométriques et topologiques d’un objet au cours du temps) existants souffrent d’un manque d’interactivité. Les concepteurs doivent écrire leur métamorphose textuellement dans un langage de programmation donné, le compiler, le tester puis éventuellement le corriger. Il s’agit pourtant d’un domaine dans lequel les processus constructifs suivent un schéma essai/erreur/correction : si le concepteur sait à quel résultat il désire parvenir, il n’en connaît pas forcément les étapes de construction intermédiaires et doit donc passer par de nombreuses étapes de mise au point.
Ce besoin d’un environnement de conception plus graphique et plus interactif, et le fait que la création de métamorphoses corresponde exactement à l’écriture d’un programme informatique, nous ont amené à étudier la possibilité d’appliquer la PbD à la programmation de métamorphoses.
4.2.	Programme et métamorphose
La principale particularité du domaine de la programmation de métamorphose est son caractère temporel. La métamorphose d’un objet est en effet une suite de modifications topologiques et géométriques au cours du temps. Elle s’appuie, en outre, sur des phénomènes périodiques (comme par exemple l’alternance des saisons). Cette particularité du programme se retrouve lorsque l’on cherche à construire, représenter et modifier ce programme de manière graphique.
On peut tirer plusieurs enseignements de cette constatation. Tout d’abord, il apparaît indispensable que la construction et la représentation du programme restent indissociables. En effet, que cette construction se fasse étape par étape, ou de manière plus globale, le concepteur doit pouvoir à chaque instant constater l’influence des actions qu’il met en œuvre, sur l’ensemble de la métamorphose. Ceci implique qu’il puisse visualiser, à tout moment, une partie pertinente (par rapport à ses actions) du programme en cours, c’est-à-dire les étapes pertinentes de la transformation.
D’autre part, étant donné le nombre important de mises au point impliquées par le processus constructif, le mode de correction du programme doit être le plus proche possible du mode de création. Cela semble possible en replaçant le concepteur dans le contexte de création de la séquence à modifier.
5.	Conclusion
Les systèmes de PbD n’offrent que très rarement la possibilité de visualiser et de modifier facilement un programme créé par démonstration. Toute la difficulté du problème vient de la représentation statique des interactions (essentiellement graphiques) utilisées par le concepteur.
Dans le cadre de la programmation de métamorphose, les problèmes de représentation et de correction doivent leur importance à la nature expérimentale des processus de construction et à la nécessité de disposer d’une représentation statique du programme.
Dans ce contexte, les solutions qui se dessinent prennent en compte le caractère “ temporel ” des programmes, en permettant d’embrasser la totalité de la métamorphose et de contrôler les conséquences de chaque action mise en œuvre.
Bibliographie
[Cypher 91] Cypher, A. Eager: Programming Repetitive Tasks by Example. in Human Factors in Computing Systems (CHI'91). 1991. New Orleans, Louisiana: ACM/SIGCHI.
[Cypher 95] Cypher, A. and D.C. Smith. KidSim: End User Programming of Simulations. in Human Factors in Computing Systems (CHI'95). 1995. Denver, Colorado: ACM/SIGCHI.
[Girard 00] Girard, P, Habilitation à diriger les recherches. Ingénierie des systèmes interactifs : vers des méthodes formelles intégrant l'utilisateur, 2000, Université de Poitiers. P 3-33.
[Halbert 93] Halbert, D., SmallStar : Programming by Demonstration in the Desktop Metaphor, in Watch What I Do, A. Cypher, Editor. 1993, The MIT Press: Cambridge, Massachusuetts. p. 102-123.
[Kurlander 88] Kurlander, D. and S. Feiner. Editable Graphical Histories. in IEEE Symposium on Visual Languages. 1988. Pittsburg: IEEE.
[Kurlander 92] Kurlander, D. and S. Feiner. A History-Based Macro by Example System. in ACM Symposium on User Interface Software and Technology (UIST'92). 1992. Monterey, California: ACM/SIGCHI.
[Kurlander 93] Kurlander, D. and S. Feiner, A History of Editable Graphical Histories, in Watch What I Do, A. Cypher, Editor. 1993, The MIT Press: Cambridge, Massachusetts. p. 405-413.
[Lieberman 93a] Lieberman, H., Tinker: A Programming by Demonstration System for Beginning Programmers, in Watch What I Do, A. Cypher, Editor. 1993, The MIT Press: Cambridge, Massachusetts. p. 49-66.
[Lieberman 93b] Lieberman, H., Mondrian: a Teachable Editor, in Watch What I Do, A. Cypher, Editor. 1993, The MIT Press: Cambridge, Massachusetts. p. 341-360.
[Maulsby 89] Maulsby, D.L., I.H. Witten, and K.A. Kittlitz. Metamouse : Specifying Graphical Procedures by Example. in SIGGRAPH'89. 1989. Boston.
[McDaniel 99] McDaniel, R.G., Building Whole Applications Using Only Programming-by-Demonstration, in School Of Computer Science. 1999, Carnegie Mellon University: Pittsburg. p. 371
[Modugno 93] Modugno, F. and B.A. Myers, Graphical Representation and Feedback in a PbD System, in Watch What I Do, A. Cypher, Editor. 1993, The MIT Press: Cambridge, Massachusetts. p. 415-422.
[Myers  98] Myers, A.B. Scripting Graphical Applications by Demonstration. in Human Factors in Computing Systems (CHI'98). 1998. Los Angeles, Californie: ACM/SIGCHI.
[Potier 95] Potier, J.-C., Thèse de doctorat. Conception sur exemple, mise au point et génération de programmes portables de géométrie paramétrée dans le système EBP, 1995, Université de Poitiers. p. 140.
[Wolber 96] Wolber, D. Pavlov : Programming by Stimulus-Response Demonstration. in Human Factors in Computing Systems (CHI'96). 1996. Vancouver, Canada: ACM/SIGCHI.