ASR: Projet de fin d études. Learner Profiler. Des traces d apprenant à un profil prédictif

Transcription

1 ASR: Projet de fin d études Learner Profiler Des traces d apprenant à un profil prédictif Etudiants: Thomas LECOURT et Moroine BENTEFRIT Encadrants : Claire LECOCQ, Alda GANCARSKI et Olivier BERGER Source: profiler

2 Sommaire Présentation A. Objectifs B. Problématique C. Démarche Conception A. Modèle de données B. Architecture fonctionnelle Réalisation A. Choix technologiques B. Architecture applicative Conclusion

3 Introduction Depuis quelques années le nombre de plates formes d apprentissage en ligne ne fait qu augmenter. Parmi ces plates formes on retrouve Moodle qui est la plate forme utilisée à Telecom SudParis. Ces plates formes permettent à des communautés d avoir des ressources à dispositions pour s instruire sur différents sujets. Grâce à ces plates formes, différents types d apprentissage se sont développés. Ainsi sont apparus les MOOC, acronyme de Massive Open Online Courses, ce qui signifie en français Cours en ligne ouvert et massif. Ce sont des cours administrés par des formateurs. Ces cours sont considérés massifs en raisons du nombre important d inscrits par cours (plus de 1000 en général). De plus aucune restriction n est posée pour pouvoir participer à ces MOOC. Ainsi donc, la population inscrite à ces MOOC est très diverse et très importante. De plus, la formation étant en ligne, il n y a pas de contact entre les apprenants et les formateurs. Il est donc difficile de se faire une idée de l efficacité d un MOOC et encore plus d avoir une idée des profils des apprenants inscrits à ces cours. Pourtant les formateurs et administrateurs de ces MOOC aimeraient connaître ces profils afin de pouvoir continuellement améliorer le contenu du MOOC et s adapter aux apprenants. Notre projet s est inscrit dans la volonté de définir des profils d apprenants à partir des traces laissées par les ceux ci lors de leurs sessions de travail car chacune des manipulations est stockée en base de données. Pour cela nous avions à notre disposition les données issues de la base de donnée du MOOC de Telecom SudParis sur les bases de données.

4 Présentation Dans cette première partie nous allons présenter dans un premier temps les objectifs fixés pour mener à bien notre étude, puis nous expliciterons la problématique associée à notre sujet d étude. A. Objectifs Le but à atteindre dans ce projet étant l analyse de données issues d une base de données d un MOOC, nous avons pour objectifs les trois points suivants : Dans un premier temps, il faut être en mesure rassembler les données depuis la base de données du MOOC vers une base de données qui nous est propre. Ensuite il va falloir traiter les données afin d en faire ressortir uniquement les données qui nous semblent pertinentes et s assurer que ces données soient utilisables. Dernièrement il faudra analyser les données traitées. Cet objectif se subdivise en deux parties. L analyse se fera d une part en reliant les informations entre elles, et d autre part avec une analyse visuelle de la part de l utilisateur. Ce sera à lui de tirer des conclusions après visualisation des données traitées et analysées. B. Problématique Comme il est indiqué dans l appellation MOOC, le nombre important d apprenants engendre des complications. La première d entre elles est le nombre important de données à traiter. Un autre problème auquel nous avons du faire face est celui de la cohérence des données. En effet, une partie des données recueillies provient de données saisies par les apprenants. Ces données sont donc sujettes à des incohérences car elles ne sont pas contrôlées par les formateurs du MOOC. Le dernier problème important qui se pose est celui de savoir quelles données sont pertinentes. Et une fois les données pertinentes définies, il reste encore à trouver le type de représentation visuelle qui saura mettre en valeur ces données.

5 Nous allons donc maintenant expliciter la démarche qui nous a permis d atteindre nos objectifs malgré les difficultés énoncées ci dessus. C. Démarche L élaboration du Learner Profiler a débuté par l analyse des besoins. Nous avons tout d abord listé les questions pertinentes sur le profil des apprenants dont voici quelques exemple: Nous nous sommes ensuite attaché à l étude de la plateforme Moodle pour identifier les données disponible et l organisation de celles ci. Une fois l étude terminée la phase de spécification a débuté par l'établissement du modèle de données, de l architecture de l application, des différentes visualisations à réaliser et l interface utilisateur. Enfin nous avons pu développer la solution, d abord par le biais d une preuve de concept puis par la réalisation d un premier prototype minimaliste avant de l enrichir fonctionnellement conformément au cahier des charges établie lors de la phase précedente.

6 Conception A. Modèle de données L objectif du Learner Profiler étant l analyse des traces d apprenants et plus globalement l établissement d un profil apprenant la conception du modèle de données est une phase primordiale. Notre modèle de donnée doit être capable de recueillir toutes les informations pertinentes de notre source de données, la plateforme Moodle, sans pour autant être spécifique. 1. Moodle Comme on peut le constater sur la figure suivante le schéma relationnel de Moodle est très dense, il nous a fallut tout d abord comprendre ce schéma puis identifier les données utiles. Schéma du Modèle de Données Moodle

7 Le schéma n est pas totalement utilisé par la plateforme Moodle, de nombreux champs ne sont pas complétés et plusieurs dizaines de tables sont vides ce qui a grandement compliqué l interprétation des données. De plus Moodle utilise nombre de constantes numérique et en trouver leur signification n a pas été aisée. Finalement nous avons pu isoler trois groupes essentiels: La gestion des ressources La gestion des utilisateurs Les enregistrements des interactions utilisateurs 2. Learner - Profiler Compte tenu de la problématique il s avère essentiel d être capable de transposer dans notre modèle de données les ressources, les utilisateurs et leurs interactions. Les utilisateurs disposent des attributs `pays` et `ville` qui représentent le lieu d habitation de l apprenant. Cependant ces données sont difficilement exploitable en l état, la question qui se pose alors est : Comment représenter la répartition géographique des apprenants? Nous avons décidé de regrouper ces informations au sein d une table dans l optique de les consolider ultérieurement afin d en faciliter leur exploitation. Enfin les enregistrements des actions utilisateurs sont associés à une adresse IP, il nous sera donc possible de situer géographiquement la répartition géographique des actions.

8 Modèle de données du Learner-Profiler L entité `Participant` est au coeur de ce modèle de données, et est relié comme évoqué précédemment à une `Localisation`. On distingue également les différents participants, à savoir les apprenants s étant inscrits délibérément, avec donc la volonté de suivre activement le MOOC, les étudiants de Telecom SudParis inscris automatiquement et le personnel encadrant du MOOC. L entité `Module` correspond aux ressources de cours du MOOC au sens large qui regroupe aussi bien les fichiers pdf, les vidéos, les liens que les quizz ou bien les forums. Ainsi l attribut `category` permet de classifier ces ressources en plusieurs en fonction de leur utilités: théorie, pratique et communauté. L entité `Action` a tout autant d importance que `Participant`, c est effet la représentation de l interaction utilisateur. L action relie donc un Participant à un Module et détient l information géographique associée à cette action. Nous sommes ainsi en mesure de corréler la déclaration de l apprenant sur son lieu d habitation. B. Architecture fonctionnelle Une fois le modèle de donnée établie il convient de spécifier le fonctionnement de l application permettant à partir des données Moodle l établissement du profil utilisateur. 1. Vue globale La démarche se décompose en trois étapes: La collecte des données La consolidation des données L analyse des données Nous avons donc séparé la logique applicative en modules suivant ces trois étapes, respectivement le CollectorBundle, le BuilderBundle et l AnalyserBundle. Nous avons également introduit le CoreBundle qui détient la gestion des entités d abstraire permettant la persistance des données et la recherche. Enfin le soucis d une plus grande évolutivité, nous voulions fournir une API permettant l exposition des données dont la gestion est confié au ProviderBundle.

9 Schéma de l architecture fonctionnel 2. CollectorBundle Le CollectorBundle est le premier module intervenant dans le processus de l application qui a pour mission de récupérer les données issues de la plateforme Moodle et de les extraire pour être compatible avec le modèle de donnée du Learner Profiler. Une fois les données formatées, le CollectorBundle en confie la gestion au CoreBundle pour leur persistence en base. 3. CoreBundle Le CoreBundle a pour unique objectif la gestion des données, il transforme les données stockées en objets. Il permet donc la manipulation des données en objets. 4. BuilderBundle Le BuilderBundle récupère les données via le CoreBundle pour les consolider. Il génère les relations entre différentes entités, c est donc lui qui interprète les données bruts pour enrichir

10 les données. Il s appuie également sur des webservice pour la consolidation, notamment pour la création des entités `Localisation`. A titre d exemple la déclaration utilisateur de son lieu d habitation peut comporter des erreurs. Pour le pays d origine, l utilisateur choisi parmi une liste mais la ville est quant à elle entrée via un simple champs texte qui peut donc comporter des fautes de frappes. Le BuilderBundle utilise donc la recherche par mots clés de l API Gplace de Google qui est très performante sur la gestion des fautes de frappes et permet d obtenir des informations précises comme la position GPS du lieu en question. 5. ProviderBundle Le fournisseur de données interprète la requête reçu de l AnalyserBundle la transforme en une requête auprès du CoreBundle pour ensuite renvoyer le résultat à l AnalyserBundle. 6. AnalyserBundle L AnalyserBundle est le seul module de la partie client de l application. La partie client possède moins de modules car la majorité des traitements se font du côté serveur de l application. L analyseur est donc le chaînon de l application avec lequel va intéragir l utilisateur. Une interface utilisateur doit donc être implémentée au travers de laquelle l utilisateur choisira les données dont il souhaite obtenir une représentation et selon quelle forme. Le choix de l utilisateur quant à la visualisation s effectue autour de trois données. La première est le type de représentation souhaité. A l heure actuelle il est proposé soit une carte du monde, soit un histogramme. Le deuxième critère est la donnée que l utilisateur veut étudier. Une fois encore il existe deux choix possibles. Soit on affiche des données concernant les apprenants, soit des données concernant les actions effectuées. Une fois ces deux critères définis, l utilisateur a la possibilité d ajouter des filtres pour cibler les données qu il souhaite analyser. Par exemple il est possible de recueillir la localisation de tous les apprenants sauf ceux habitant en France. Le travail de l AnalyserBundle est donc de récupérer les données saisies par l utilisateur et à partir de ces données doit être produite une représentation visuelle correspondante aux attentes de l utilisateur. Ce module va intéragir avec le ProviderBundle pour récupérer les données à afficher.

11 Réalisation Une fois les spécifications fixées nous pouvons réaliser les différents modules de façon relativement indépendantes sous la seule condition de respecter les flux d entrées/sorties et bien évidemment la mission qui lui est confié. A. Choix technologiques Le choix des technologies est une étape essentielle pour la bonne réalisation du projet. Ainsi les points à prendre en compte sont à la fois l apport même de cette technologie mais également notre maîtrise de ces technologies. 1. Intégration continue Afin d appuyer le développement en équipe nous avons naturellement décidé d utiliser un gestionnaire de version, GIT. En complément de ce gestionnaire de version nous avons appliqué le GitWorkflow nous permettant de fixer des realeases incrémentales suivant l intégration continue. Dans le but de faciliter le déploiement de l application, nous avons utilisé Vagrant. Vagrant est un outil de création d environnements complet de développement permettant de s abstraindre des spécificités de chaque machine en exécutant une virtual machine. Enfin pour une meilleure gestion du projet nous utilisons le gestionnaire de dépendance composer qui permet notamment de regrouper les dépendances de librairies externes et de pouvoir les mettre à jour simplement.

12 Git Workflow 2. Technologies serveur Le serveur se base sur le framework php Symfony2 offrant une panoplie d avantage. Symfony2 est un framework MVC orienté Service ce qui nous permet une de garder la maîtrise de notre application. Symfony2 dispose également d une multitude de bundles opensource, et notamment Doctrine.

13 Doctrine est un ORM (Object Relational Mapping) permettant une abstraction niveau objet du schéma relationnel. 3. Technologies client Le client se présente sous la forme d une application web. Ce choix apparaît comme étant naturel à la fois par la facilité de création et de déploiement. De plus de multiple outils sont disponible et notamment la bibliothèque Javascript D3js permettant la création de graphiques utilisés pour la représentation des données. B. Architecture applicative Nous allons maintenant aborder l implémentation des des modules principaux à savoir le CollectorBundle, le BuilderBundle et l AnalyserBundle. 1. CollectorBundle Le CollectorBundle a pour mission d importer les données Moodle. Ces données se présentent sous la forme d un dump SQL. La principale difficulté du CollectorBundle consiste en la quantité de données à importer. En effet avec plus de actions, l importation naïve peut s avérer impossible. Ainsi pour des raisons de performance le CollectorBundle se lance en ligne de commande pour pouvoir utiliser pleinement les ressources systèmes.

14 Architecture applicative du CollectorBundle Le premier composant intervenant est le Fetcher qui se charge simplement d importer le dump sql dans une base de données spécifique au collecteur. Interviennent ensuite les composants d extraction des données spécifique à chaque entité cible. Ce choix nous permet de paralléliser l extraction des données et donc d optimiser le temps de traitement. Chaque composant récupère les données brut dans la base spécifique du Collecteur pour créer des entités dont la gestion sera délégué au CoreBundle. Il nous a fallu également se préoccuper de la consommation mémoire. Les premiers essais s avéraient très gourmand requirant jusqu à 4 Giga de mémoire vive. La solution mis en place pour contourner le problème était de fonctionner par lot, chaque composant récupère des lots d une cinquantaine d entités avant d en confier la gestion au CoreBundle puis de supprimer les références vers ces entités pour libérer la consommation mémoire. Avec cette méthodologie on parvient à diviser par 100 la consommation mémoire et réduire le temps de traitement à une demi heure. 2. BuilderBundle Le BuilderBundle se charge de la consolidation des données et donc de lier les différentes entités entre elles.

15 Architecture applicative du BuilderBundle Le BuilderBundle est confronté à la même problématique que le CollectorBundle dû à la quantité de données à traiter. Ainsi le BuilderBundle est également décomposé en plusieurs composants spécifique. Le BuilderBundle crée les Localisation à partir des données issues des Participants et des Actions en s appuyant sur différents Web Services. Le LocalisationBuilder utilise une panoplie de services regroupées dans le composant LocalisationServices afin de consolider les données. Les Web Services appelés ayant tous des quotas et les requêtes aux Web Service introduisant du temps de latence dans le traitement nous mettons en cache les résultats dans le CoreBundle afin de limiter les appels externes. 3. AnalyserBundle Comme il a été établi précédemment, l AnalyserBundle est le module de la partie client chargé de récupérer les critères de visualisation de l utilisateur puis de restituer une visualisation adaptée. Dans cette partie nous allons détailler le fonctionnement interne de ce module. Voici donc le schéma de son fonctionnement :

16 Le flux de données suivant un ordre précis, nous allons détailler le fonctionnement du module en procédant dans le même ordre. L interface utilisateur est donc le point d entrée de l application pour l utilisateur. Cette interface utilisateur est ancrée dans une page web. C est à partir de cette page que l utilisateur entre les données liées à la visualisation qu il souhaite obtenir. Une fois ces données saisies, le contrôleur les récupère pour les analyser. Une fois les paramètres analysés, le contrôleur transmet au collecteur la requête que ce dernier doit transmettre vers le ProviderBundle pour récupérer les informations nécessaires pour établir la visualisation. Une fois la requête transmise, le collecteur attend la réponse du ProviderBundle..La réponse reçue est au format JSON et contient les données attendues par le bloc visualisation du module. Le bloc visualisation utilise la bibliothèque Javacsript D3.js. Cette bibliothèque est spécialisée dans la transformation de données en des représentations visuelles. Cependant le format des données nécessaire à l utilisation de cette bibliothèque nécessite un format précis. Le bloc de visualisation se charge d ajouter aux données venues du contrôleur les attributs nécessaires pour la création de la visualisation. Cette tâche n est pas effectuée du

17 côté serveur car certaines données sont mises à jour du côté client sans faire appel au serveur. Les difficultés qui ont été rencontrées lors du développement de ce module ont essentiellement été dues à la découverte de D3.js. En effet, à la différence de JQuery, D3.js offre des fonctions d un niveau très élevé et utilise des objets spécifiques à cette bibliothèque, ce qui rend difficile la compréhension des exemples ainsi que la transcription de ces exemples vers nos problèmes.

18 Conclusion Le LearnerProfiler se présente comme étant un outil d analyse des MOOC. Plutôt que de proposer différentes représentations que nous jugions pertinente, nous avons fait le choix de la fléxibilité laissant libre choix à l utilisateur la représentation des données qu il souhaite. N ayant pas le recul nécessaire sur les MOOC, nous n étions pas capable d identifier les facteurs déterminant du profil apprenant. Cette fléxibilité permet donc de répondre à une multitude de questions sur l utilisation du MOOC. Le LearnerProfiler s'inscrit également dans une volonté de facilité d utilisation. Un intérêt tout particulier à été accordé à l ergonomie de l interface utilisateur et plus globalement à la facilité d utilisation et d installation. Ce projet nous a permis de mettre en oeuvre différents processus d industrialisation dans un soucis de maintenabilité et d évolutivité.