Next PDF List

Apprendre la programmation par l'exemple : méthode et système.Nicolas Guibert, Laurent Guittet, Patrick GirardLISI / ENSMATéléport 2 - 1 avenue Clément Ader BP 4010986961 Futuroscope Chasseneuil cedex{guibert, guittet, girard}@ensma.frRésuméAlors que micro-ordinateurs et programmesinformatiques se sont implantés dans denombreuses disciplines scientifiques en tantqu'outils d'analyse ou qu'instruments de mesure(physique, chimie, sciences de la vie on parlemême dans ce dernier cas de bio-informatique),l'acquisition des compétences requises pour laconception de programmes ne se fait pas aisément.Käasboll rapporte que, de par le monde, entre 25 et80 % des étudiants dans un cursus d'initiation à laprogrammation sont en situation d'échec oud'abandon.

Nous présentons de manièresynthétique une typologie des erreurs et desdifficultés des programmeurs débutants.

Nousexplorons les utilisations pédagogiques d'unparadigme de programmation alternatif, la" Programmation sur Exemple ».

Enfin, nousprésentons un environnement d'apprentissage de laprogrammation et de l'algorithmique, MELBA(Metaphor-based Environment to Learn the Basicsof Algorithmic), ainsi que la démarche didactiquequ'il supporte.AbstractAlthough programs take now a greater importanceof programs as analysis or measurement tools inscience (physics, chemistry, biology in this casebio-informatics has even become a topic in itself),introductory programming courses are still knownto be difficult for students.

Kaasboll recentlyreports that their rate of drop out and failure varyfrom 25% to 80% worldwide.

We present atypology of the difficulties in learningprogramming, and explore the pedagogical issuesof an alternative programming paradigm,Programming by Example.

Finally we present aninnovating Learning Environment forprogrammers, MELBA (Metaphor-basedEnvironment to Learn the Basics of Algorithmic),and the didactic approach it supports.Mots clés :Interactions Homme-Machine, Didactique de laprogrammation, Programmation sur Exemple,Métaphores, Programmation graphique.KeyWords:Human Computer Interaction, Didactics and Psychologyof Programming, Programming by Example, Metaphors,Visual Programming.IntroductionLa généralisation de l'ordinateur comme outilindispensable dans les sciences fondamentales(astrophysique, génétique, chimie moléculaire, ) aentraîné l'expansion de l'apprentissage de laprogrammation à une nouvelle audience universitaire.Cependant, la difficulté avérée des cours d'initiation(Kaasboll (Kaäsboll 2002) relate que 25 à 80% desétudiants dans le monde sont en situation d'échec dansde tels modules - ce qui se traduit par une absence ouun échec à l'examen) nous amène à reconsidérer lapédagogie employée et les facteurs d'échec quiconduisent à ce constat alarmant.

Pourquoi laprogrammation est-elle donc si difficile d'accès ? Lasynthèse de différents travaux de didactique nouspermet d'apporter des éléments de réponse à cettequestion.Figure 1 : Le cycle de conception d'un programme.Classification des difficultés des étudiants.Nous allons nous attacher à définir et à décomposerl'activité de programmation (figure 1), et de répertorierles difficultés essentielles à chaque étape.

Programmer,qu'est ce ? C'est " faire faire une tâche à unordinateur » (Duchateau 2000).D'un point de vue chronologique, l'activité deconception d'un programme débute donc par l'analyseet la modélisation précise de la tâche, où l'on se pose laquestion " quoi faire ? ».

Cette étape n'est cependantgénéralement pas abordée en initiation à laprogrammation, mais reportée au cours de génielogiciel, ceci parce que les tâches que l'on se proposede faire automatiser par l'étudiant sont soit triviales,soit familières.Les premières difficultés ne surgissent donc qu'unpeu plus tard, lorsque le programmeur se pose laquestion " comment le faire ? ».

Il faut pour répondre àcette question construire un modèle viable de lastructuration temporelle de la tâche à effectuer.L'étudiant n'ayant pas réussi à construire un telmodèle ne parvient pas à abstraire correctement lesdifférents comportements de la tâche, ou ne parvientpas à prévoir le comportement dynamique du"programme» qu'il a écrit.Ensuite se pose le problème du " faire faire », c'est-à-dire la prise en compte de l'exécutant-ordinateur.

Ilfaut pour répondre à cette question intégrer à sastratégie un modèle viable de l'exécutant-ordinateur .Une difficulté spécifique à la programmation est que,contrairement à d'autres sciences comme la physique,l'étudiant débutant en programmation n'a pas demodèle " naïf » viable de l'ordinateur, qui pourrait luiservir comme base pour construire des modèles plussophistiqué (Ben-Ari 1998).

Il en résulte deux typesd'erreurs : Des erreurs anthropomorphiques (Pea 1986;Spohrer 1986; Du Boulay 1989), qui proviennentdu fait que, en l'absence de modèle defonctionnement de l'ordinateur, l'étudiant utilisepar défaut le modèle d'un exécutant humain (ex.compréhension contextuelle des instructions -donner exemple : nom de variable).

Des erreurs liées à la numérisation (Smith 1993)de la tâche, causées par la distance cognitive quisépare les objets de l'univers de la tâche de leurformalisation dans le programme (Arsac 1991).Généralement les objets du domaine de la tâchesont analogiques dans le sens où leur forme traduitleur "contenu» ; par opposition les représentationsnumériques utilisées dans les ordinateurs sontfregeïennes car elles ne supportent pas cetteanalogie entre la forme et le contenant (figure 2).La dernière étape consiste à interpréter les résultats del'exécution du programme.

Cette interprétationprésente la même difficulté .Figure 2 : Représentations analogique et fregeïenne d'untriangle.Cette classification démontre clairement qu'apprendrela programmation ne peut être réduit à apprendre lasyntaxe d'un langage spécifique, tout comme il fautplus que la connaissance du solfège pour devenircompositeur de musique.

Mais, surtout, elle met enexergue la pertinence de mettre en place des activitéspédagogiques correspondant à chaque étape de ceprocessus, et de disposer pour cela d'un environnementsupport adapté.En effet, l'utilisation des langages / environnements deprogrammation traditionnels, semble être la causedirecte d'un ensemble de difficultés d'apprentissagesque l'on pourrait qualifier d' " articulatoires », enréférence à la théorie de l'action de Norman (Norman1990).

Celle ci associe la réalisation d'une tâche auparcours d'une distance - figure 3.

Les distancesarticulatoires traduisent les difficultés à adapterl'intention de l'utilisateur aux commandes disponibles,et à interpréter l'état du système à partir de l'état del'interface.Figure 3 : Distances sémantiques et articulatoires.La première difficulté tient à ce que cesenvironnements, étant destinés à un public d'experts,favorisent l'évaluation mais pas la conception deprogrammes.Ainsi, coloration lexicale et analyse syntaxique,"debuggers», "assertions» fournissent ils un support àl'évaluation du "comment écrire», du "comment fairefaire», du "quoi faire».

Mais aucun outil n'estexplicitement destiné à supporter le processus de laconception du programme.On comprend dès lors mieux les difficultésexprimées par les étudiants dans (Carbone, Hagan, etSheard 1998) :" lorsque le problème est présenté on ledécompose comme ça, comme ça, comme ça.

Touta l'air simple et très logique, et puis c'est à toi etOuch !! Par quoi je commence ? Peut-être quec'est facile, mais le problème c'est que tu ne saisTriangle2241310 6Analogique Fregeïenpas par quel bout commencer quand il fautrésoudre le problème »Deuxièmement, lorsque les étudiants connaissent leurpremière expérience concrète de la programmation, ilsont en premier lieu un retour sur les erreurs syntaxiques(comment écrire ?), qui leur sont signalées par lecompilateur.Plus insidieuses sont les erreurs sémantiques, où leprogrammeur débutant exprime avec des mots dulangage des instructions qui n'ont pas de sens pourl'exécutant, car il se fait une idée fausse dufonctionnement de celui-ci (comment faire faire ?).Il doit alors détecter à partir de l'exécution duprogramme l'origine et la cause de l'erreur (Arsac1991), c'est-à-dire reconstruire le lien correct entre lesobjets analogiques de la tâche et les donnéesnumériques de l'exécutant-ordinateur d'une part, etentre le comportement des objets analogiques etl'algorithme d'autre part.Enfin les erreurs pragmatiques, résultant d'un défautdans les spécifications du programme, ou d'unemodélisation non exhaustive des comportements de latâche sont classiquement les dernières (car les plusdifficiles) à être détectées.

Le retour d'erreur sur lesdifférents processus qu'englobe la programmations'effectue donc en sens inverse de leur exécution.Le cycle de conception " classique » de laprogrammation, qui s'appuie sur l'écriture complèted'un programme, ne permet donc pas de séparer lesdifférents problèmes : pour pouvoir évaluer le" comment faire » il faut avoir déjà répondu auproblème " comment faire faire » et avoir évalué lasolution ; et pour ce faire, il faut avoir écrit et corrigésyntaxiquement le programme.

Cet état de fait permetde comprendre l'échec relatif des tentatives de séparerces différentes étapes, comme le rapporte Rogalsky(Rogalsky et Hoc 1988) :" L'observation d'élèves débutant en informatiquedans un cadre scolaire semble indiquer que lesméthodes d'analyse enseignées ne sont pas vuespar les élèves comme un outil pour résoudre leursproblèmes de programmation, mais comme uncontrat (avec l'enseignant) qu'il faut respecter.L'expression de la phase de travail qui correspondà l'analyse apparaît assez souvent comme uneparaphrase du texte du programme écrit, qui peutprécéder, accompagner, voire succéder à l'écrituredirecte dans un langage de programmation ».Tout ceci démontre la piètre adéquation des langages etenvironnements de programmation actuels à un butd'apprentissage.

Mais quel est l'impact de cettedifficulté articulatoire sur les résultats d'un étudiant,comparativement à la difficulté intrinsèque d'uneactivité de conception ?Un élément de réponse peut être extrait des résultatsde deux études menées par (Goold et Rimmer 2000 ) et(Wilson et Schrok 2001) sur des étudiants en coursd'initiation à l'informatique.

Leurs résultats corrèlentparfaitement le fait que le facteur prioritaire dans laréussite est ce qu'ils nomment respectivement " dégoûtde la programmation » et " degré de confort pendantl'apprentissage » (table 1).Ce terme englobe le niveau d'anxiété lors du travailsur la machine, la difficulté perçue de lacompréhension des concepts - en soi etcomparativement aux autres étudiants, et la difficultéperçue à réussir les exercices sur machine.Conceptsde base.Structure de donnéeset Algorithmes.Total Examen TotalVariable Coefficients de régressionScore moyendans les autresmodules0,32(2,07)*0,89(5,19)**0,71(3,35)**A fait de laprogrammationavant l'université--12,32(2,00)Dégoût de laprogrammation-12,50(-2,52)*-28,38(-4,51)**-22,40(-2,94)**Résolution deproblèmes1,36(1,84)--Sexe (h|f) 7,52(2,11)*--Table 1 : Effets de différentes variables sur les résultats desmodules d'initiation à la programmation.Un autre résultat qui nous semble démontrer l'impactprimordial de cette difficulté " articulatoire » a étéexhibé par (Mancy et Reid 2004) dans une étuderécente portant sur 150 étudiants de l'université deGlasgow, étude qui cherchait les corrélations entre lescaractéristiques cognitives des étudiants et leurrésultats en programmation.Les résultats y montrent que la dépendance auxchamp