RAPPORT DE PROJET DE FIN D E TUDE

Transcription

1 Charles-Édouard BERNAILLE Benoît REYNAERT RAPPORT DE PROJET DE FIN D E TUDE La Formation Ouverte À Distance 01 / 02 / 2013 ESEO I3 SI Ce document est le rapport de projet de fin d étude réalisé par un binôme en option SI à l ESEO Angers. Il s inscrit dans un projet réalisé par trois équipes : deux de l ESEO et une de l université du Maine, au Mans. Le thème est la formation à distance. L objectif est de proposer une solution pour pallier à l absence de lien physique entre formateur et apprenants, tout au long de cet enseignement.

2 Sommaire Table des figures... 3 Extraction des traces générées sur Moodle et SharePoint... 4 Introduction... 5 Flexibilité de la FOAD... 6 Cahier des charges... 7 Problématique... 7 Environnement... 7 Fonctionnalités mises en place... 8 Réponse à la problématique : service web Choix du service web Structure coté serveur Structure du Service Schéma Rôle et implémentation des différentes parties Diagrammes de classe Diagramme de séquence d un cas nominal Moodle Introduction à la plateforme Moodle Traduction des objets Moodle/model Structure des logs Structure de la base de donnée et problèmes de jointures Conclusion SharePoint Introduction à la plateforme SharePoint Connexion à la base de données Structure des logs Problèmes rencontrés Conclusion JSP de test Exemple de trace Présentation Conclusion Glossaire Bibliographie Page 1 sur 63

3 Annexes Recherche Documentaire Introduction Présentation de la formation ouverte à distance Pour résumer Notre Projet Application à créer : éditeur de scénarios LOA Framework Plugin : extraction de traces et interprétation Conclusion Exemple de requête et de réponse SOAP/XML EndPoint Exemple de requête lancée sur le serveur Exemple de réponse du serveur Extraits de requêtes SQL Installation d un server Debian avec Moodle Table des matières Installation de la plateforme Installation web d'apache // Installation de Moodle, copier le dossier moodle dans /srv/web 62 Warnings \\ dans les logs de PostgreSQL Automatisation des taches Migration / Sauvegarde du campus Page 2 sur 63

4 Table des figures Figure 1 : Schéma d'une formation... 5 Figure 2 : Schéma général du projet... 7 Figure 3 : Fonctionnalités du service... 9 Figure 4 : Schéma fonctionnel du serveur Figure 5 : Schéma du service en blocs fonctionnels Figure 6: fichier de configuration Conf/conf.xml Figure 7 : Appel du fichier de configuration des logs Figure 8 : Exemple de log lié à l'appel du service Figure 9 : Blocs composant le service Figure 10 : Modèle commun à l éditeur de scénario et au projet d extraction des traces (partie1) 19 Figure 11 : Modèle commun à l éditeur de scénario et au projet d extraction des traces (partie2) 20 Figure 12 : Modèle des traces Figure 13 : Modélisation du package Controller Figure 14 : Cas nominal de la recherche des logins d'un apprenant Figure 15 : Extrait d'une page depuis le campus ESEO (cours plateforme.net) Figure 16 : Extrait de la liste "Tous les cours" du campus ESEO Figure 17 : Modèle et object Moodle Figure 18 : Table des logs Moodle : mdl_log Figure 19 : Exemple de logs Moodle Figure 20 : Tableau des jointures entre le log et le modèle (Moodle) Figure 21 : Informations récupérables dans les traces de Moodle Figure 22 : index.jsp - Page d'accueil pour utiliser le service web Figure 23 : Affichage des traces correspondantes Figure 24: Traces de consultation d'un module sur SharePoint Figure 25 : Système de gestion des traces Figure 26 : Schéma récapitulatif des trois dimensions clés de la FOAD Figure 27 : Fonctionnalités du projet Figure 28 : Granularités des dimensions Scénario et Participants Figure 29 : Structure en quatre couches du système OASIF Figure 30 : Capture d'écran du logiciel OASIF Figure 31 : The development process Page 3 sur 63

5 EXTRACTION DES TRACES GENEREES SUR MOODLE ET SHAREPOINT

6 Introduction La formation continue est en plein accroissement dans le monde professionnel et, face aux impératifs de chaque participant, cet apprentissage tend à se faire à distance. Cette méthode d enseignement limite fortement les contraintes temporelles et spatiales, mêlant flexibilité et adaptabilité. Chacun peut ainsi suivre les cours depuis le lieu de son choix, depuis son domicile par exemple, à tout moment de la journée : c est la formation ouverte à distance, également appelée FOAD. Chaque participant dispose d une grande autonomie pour gérer son apprentissage. Le suivi de la formation est propre à chacun, selon ses disponibilités personnelles. L apprentissage concerne donc plusieurs individus qui ne dépendent pas les uns des autres pour travailler. Ils peuvent travailler depuis des lieux distincts, à des heures différentes, sans impact sur leur formation. La FOAD offre également la possibilité de concerner un grand nombre d acteurs. En effet, les limites spatiales ne sont plus d actualité, car chacun est libre de suivre les cours d où il veut. Le concept de l enseignement dans une salle, avec l ensemble des apprenants qui écoutent le formateur est dépassé. La majorité de la formation est dispensée via internet et est donc accessible depuis tout ordinateur connecté. La dimension temporelle est également importante, car les cours n ont plus lieu sur une plage horaire définie. Il est désormais possible d étudier à toute heure du jour et de la nuit. Les acteurs concernés ont donc la liberté d organiser leur temps de travail, notamment pour répondre à leurs contraintes personnelles. Pour qu une telle formation puisse se dérouler dans de bonnes conditions, un contexte précis couplé avec une organisation rigoureuse sont nécessaires. Un scénario clair, illustrant l ensemble de la formation, doit être mis en place dès le commencement. Cette formation doit être structurée, découpée en différentes parties que nous appellerons modules. Chaque module sera lui-même décomposé en séquences qui comprendront plusieurs activités. Figure 1 : Schéma d'une formation De plus, un calendrier doit être mis en place par le formateur. En projetant le scénario sur ce dit calendrier, chaque tâche sera accompagnée d un délai pour la réaliser. Les participants auront donc des dates limites pour suivre chaque cours et réaliser les exercices demandés. Page 5 sur 63

7 Flexibilité de la FOAD Avant le commencement de l apprentissage à distance, le formateur met en place un scénario précis, comportant différentes tâches et activités à réaliser, dans des délais impartis. Cependant, le contexte de la formation à distance ne doit pas être fixe. Le formateur doit utiliser la flexibilité proposée par ce mode d apprentissage pour adapter son scénario initial en fonction de l avancement réel des participants. Si la difficulté de certains cours a été mal évaluée au départ, il est nécessaire d effectuer les modifications adéquates afin d adapter au mieux la formation aux individus qui la suivent. Il faut également souligner l hétérogénéité des participants aux formations. Chacun ne dispose pas des mêmes compétences, notamment dans le domaine de l informatique. Les outils mis à leur disposition doivent donc être simples d utilisation. Les thèmes des apprentissages proposés varient aussi, d où une nécessité de posséder des outils pluridisciplinaires, qui s adaptent à chaque domaine traité. L objectif de ce projet est donc de proposer une solution qui réponde aux exigences de la FOAD et à celles de ses acteurs. Pour rendre possible l adaptabilité du scénario, le formateur doit pouvoir avoir des retours de la part des apprenants. En effet, l absence de lien physique ne permet pas un suivi régulier, comme ce serait le cas dans une formation dans un établissement dédié. Cette absence de proximité doit être comblée par des retours et des échanges réguliers entre formateur et étudiants. Ce suivi donnera ainsi des indications au formateur quant à la réussite des exercices, à l avancement de chaque participant et au temps consacré à la formation. Il sera donc en mesure de modifier le scénario qu il avait prévu, s il le juge nécessaire. L objectif est donc de palier à l absence de lien physique entre le formateur et les apprenants, en favorisant les échanges et les retours pour le formateur. Page 6 sur 63

8 Cahier des charges Problématique Le principal inconvénient de la formation à distance est le manque de proximité entre le formateur et les apprenants. En effet, chacun apprend à des lieux différents, à des horaires variables. Comment le professeur peut-il suivre ses élèves? Actuellement, le seul retour proposé concerne l évaluation finale de chaque étudiant. Cette étape se situant à la fin de chaque module de la formation (cf. schéma ci-dessus), il est donc impossible pour le formateur de modifier son scénario prévu pour l adapter à la réalité des apprenants. Comment fournir des retours quotidiens au professeur, malgré la distance qui le sépare des individus qui suivent sa formation? Contrairement à un cours commun dans une salle, il n est pas possible pour un professeur de contrôler l assiduité de ses apprenants et de connaître le temps que ces derniers consacrent à la formation. De plus, il ne peut ni savoir si les travaux demandés ont été rendus à temps, ni être au courant de la consultation de chaque ressource mise à disposition des étudiants. Il est également nécessaire de savoir si chaque outil ou fichier utile à la formation a été téléchargé par l étudiant. Enfin, les échanges possibles entre étudiants ou avec le formateur doivent être tracés. Le professeur doit être en mesure de visualiser les messages rédigés, ainsi que leur modification ou suppression. Plusieurs professeurs peuvent enseigner dans la même formation. Le responsable doit être alerté lorsque des modifications sont réalisées sur le scénario, qu elles concernent un module, une séquence ou encore une activité. Environnement La solution proposée pour répondre à cette problématique se décompose en quatre parties. Un scénario d apprentissage est donc décomposé comme suit : Création du scénario par le formateur Export du scénario vers le campus numérique (Moodle ou SharePoint) Chaque apprenant génère des traces loguées, lors de son suivi de la formation Sélection, tri et organisation des traces pour être exploitées Visualisation de l activité des apprenants par le formateur comparaison entre le réel et le scénario prévu Figure 2 : Schéma général du projet Page 7 sur 63

9 Cette schématisation distingue plusieurs fonctions à développer, pour remplir les objectifs des quatre parties du projet : Application graphique pour créer un scénario Plugin pour exporter le scénario vers le campus numérique Extraction des traces depuis les bases de données Visualisation des traces générées par les apprenants Chaque étape du projet est donc réalisée par un groupe de développement : deux sont présents à l ESEO, à Angers, et un autre est situé au Mans, à l université du Maine. L étape n 2, à savoir l export du scénario vers Moodle ou SharePoint, n est pas réalisée cette année. Le groupe Florent BOURDON & Antoine ZÉTULE avait pour mission de concevoir et développer un éditeur de scénarios basé sur le principe d OASIF, un logiciel existant. Cet éditeur permet l exportation des scénarios créés, au format XML. Le binôme Charles-Édouard BERNAILLE & Benoît REYNAERT a mis en place un service web pour extraire les logs sur les campus Moodle et SharePoint, les trier et les organiser en suivant le même modèle que celui utilisé pour l édition du scénario. Enfin, une équipe de cinq étudiants, basée au Mans, a exploité les traces extraites pour permettre leur visualisation sur une plateforme mobile, telle une tablette graphique. Durant le projet, plusieurs réunions ont eu lieu pour faire un lien entre Angers et Le Mans. Une première rencontre a eu lieu mi-octobre 2012 entre les deux binômes de l ESEO et Monsieur Philippe TEUCH, responsable de l équipe mancelle. Elle a permis de faire un point sur la recherche bibliographique autours de la FOAD, ainsi que de proposer une première ébauche de la solution à développer. Le 25 octobre 2012, une deuxième réunion s est déroulée avec les mêmes acteurs, autours de la modélisation UML du projet. Elle a permis à chacun d exprimer son point de vue afin d aboutir à un modèle commun, répondant au mieux aux exigences du projet. Courant décembre 2012, une visio-conférence a permis aux étudiants angevins de rencontrer ceux du Mans, pour faire un point sur l avancée de chacun. Nous avons expliqué le fonctionnement de notre service web, la procédure pour l interroger ainsi que les fonctionnalités qu il propose. Enfin, le 25 janvier 2012, une dernière réunion s est déroulée à l ESEO, entre les deux binômes locaux et Monsieur Teutsch, pour présenter le travail réalisé. Le projet était largement avancé, presque terminé, et une démonstration a permis de montrer l ensemble des fonctionnalités implémentées. Fonctionnalités mises en place Nous avons commencé par exploiter les traces du campus Moodle, que nous avons installé sur un serveur, associé à une base de données PostgreSQL. Cet espace de travail numérique correspond à une configuration que l on pourrait trouver lors d une formation à distance. Tous les outils nécessaires à cette installation sont Open Source. Nous avons créé une formation ainsi que ses sous-catégories (modules, activités ), pour en exploiter les traces. Ensuite, nous nous sommes concentrés sur SharePoint, solution proposée par Microsoft. Notre projet étant en collaboration avec l ESSCA Angers, nous avions à disposition une base de données de logs, très restreinte. Nous n avons pas pu mettre en place les mêmes fonctionnalités sur celles sur Moodle, à cause des manques liés à la base de données. Page 8 sur 63

10 Le tableau suivant illustre l ensemble des fonctionnalités développées sur chacun des deux campus numériques, qui répondent à la problématique. FONCTIONNALITÉ MOODLE SHAREPOINT Gestion des connexions et déconnexions Consultation d une formation, d un module, d une séquence, d une activité X X X Téléchargement d une ressource pédagogique X X Dépôt d un travail et modification Utilisation des outils de communication (forum) Edition/modification d un élément du scénario Suppression d un élément du scénario X X X X Afficher toutes les traces générées X X Figure 3 : Fonctionnalités du service Pour chaque fonctionnalité, le formateur peut appliquer des filtres pour généraliser ou au contraire préciser les vues qu il souhaite. Il peut ainsi restreindre son champ de recherche à une formation en particulier, ou encore à une certaine activité, par exemple. Chaque paramètre des fonctions décrites ci-dessous est facultatif, c est-à-dire qu il peut être nul et ne sera pas pris en compte dans la requête. Gestion des connexions et déconnexions Nous exploitons les traces générées par la connexion et la déconnexion d une personne sur le campus numérique. Le nombre de logins est supérieur à celui des logouts, car il est possible que l utilisateur soit déconnecté à l issu du timeout du serveur. Méthodes implémentées : renvoient un tableau de traces de type Login ou Logout getlogins ( Acteur, Date [] ) getlogouts ( Acteur, Date [] ) Paramètres un apprenant un tableau de dates pouvant contenir la date de début et de fin de l intervalle de temps concerné Consultation d une formation, d un module, d une séquence, d une activité Lorsqu un apprenant visite la page de la formation qu il suit, ou lorsqu il consulte un module, une séquence ou une activité, il génère des traces. Il est donc possible pour le formateur de s assurer que l ensemble des cours a été visité et donc lu par ses élèves. Méthodes implémentées : renvoient un tableau de traces de type Consultation getconsultationsformation ( Acteur, IDFormation, TitreFormation, Date[] ) getconsultationsmodule ( Acteur, IDFormation, TitreFormation, Module, Date [] ) getconsultationssequence ( Acteur, IDFormation, TitreFormation, Sequence, Date[] ) getconsultationsactivite ( Acteur, IDFormation, TitreFormation, Activité, Date[] ) Page 9 sur 63

11 Paramètres un apprenant la formation concernée, avec son ID et son titre un module, une séquence ou une activité (l objet est passé en paramètre) dates Téléchargement d une ressource pédagogique Des fichiers au format PDF, DOCX sont mis à la disposition des apprenants dans le cadre de leur formation. Il est nécessaire de les télécharger avant de pouvoir les consulter. Le professeur peut désormais s assurer que l ensemble des ressources a été exploité. Méthode implémentée : renvoie un tableau de traces de type Téléchargement gettelechargements ( Acteur, IDFormation, TitreFormation, RessourcePedagogique ressource, Date[]) Paramètres un apprenant la formation concernée, avec son ID et son titre une ressource pédagogique (l objet est passé en paramètre) dates Dépôt d un travail Tout au long de leur formation, les élèves doivent faire des exercices, rédiger des rapports, réaliser un certain nombre de productions. Cette fonctionnalité permet au professeur de déterminer l auteur de chaque production, mais également le jour et l heure du dépôt. Méthodes implémentées : renvoient un tableau de traces de type Dépôt(production) ou Dépôt(outilCom) getdepotsproduction ( Acteur, IDFormation, TitreFormation, Production, Date[]) geteditsdepotproduction ( Acteur, IDFormation, TitreFormation, Production, Date[] ) getdeletedepotproductions ( Acteur, IDFormation, TitreFormation, Production, Date[]) getdepotsfichiers ( Acteur, IDFormation, TitreFormation, OutilCommunication, Date[] ) geteditsdepotfichier ( Acteur, IDFormation, TitreFormation, OutilCommunication, Date[] ) getdeletedepotfichiers ( Acteur, IDFormation, TitreFormation, OutilCommunication, Date[] ) Paramètres un apprenant la formation concernée, avec son ID et son titre une production ou un fichier (l objet est passé en paramètre) dates Page 10 sur 63

12 Utilisation des outils de communication Des outils pour échanger avec d autres apprenants ou professeurs existent sur les campus numériques. Le formateur doit être en mesure de répondre aux messages qui lui sont destinés et visualiser les échanges entre les individus. À chaque message déposé, modifié ou consulté sur un forum, un chat ou un wiki, une trace est générée et exploitée. Méthodes implémentées : renvoient un tableau de traces de type Consultation, Edition, Suppression d un OutilCommunication ou Message getconsultationsoutilcommunication (, IDFormation, TitreFormation, OutilCommunication, Date[] ) geteditsoutilcom ( Acteur, IDFormation, TitreFormation, OutilCommunication, Date[] ) getdeleteoutilcom ( Acteur, IDFormation, TitreFormation, OutilCommunication, Date[] ) getmessages ( Acteur, IDFormation, TitreFormation, OutilCommunication, Date[] ) geteditsmessages ( Acteur, IDFormation, TitreFormation, OutilCommunication, Date[] ) getdeletemessages ( Acteur, IDFormation, TitreFormation, OutilCommunication, Date[] ) Paramètres un apprenant la formation concernée, avec son ID et son titre un outil de communication (l objet est passé en paramètre) dates Edition d un élément du scénario Le formateur n est pas la seule personne qui a les droits de modification sur le scénario d apprentissage. Si une formation, un module, une séquence ou encore une activité est modifié, il doit en être informé. Méthodes implémentées : renvoient un tableau de traces de type Edition Formation, Module, Séquence ou Activité geteditsformation ( Acteur, IDFormation, TitreFormation, Date[] ) geteditsmodule ( Acteur, IDFormation, TitreFormation, Module, Date[] ) geteditssequence ( Acteur, IDFormation, TitreFormation, Séquence, Date[] ) geteditsactivite ( Acteur, IDFormation, TitreFormation, Activité, Date[] ) Paramètres un apprenant la formation concernée, avec son ID et son titre un module, une séquence ou une activité (l objet est passé en paramètre) dates Suppression d un élément du scénario De même que pour la modification d une formation, la suppression d une formation, d un module, d une séquence ou d une activité doit être remontée jusqu au formateur. Méthodes implémentées : renvoient un tableau de traces de type Suppression Formation, Module, Séquence ou Activité getdeleteformations ( Acteur, IDFormation, TitreFormation, Date[] ) getdeletemodules ( Acteur, IDFormation, TitreFormation, Module, Date[] ) getdeletesequences ( Acteur, IDFormation, TitreFormation, Séquence, Date[] ) getdeleteactivites ( Acteur, IDFormation, TitreFormation, Activité, Date[] ) Page 11 sur 63

13 Paramètres un apprenant la formation concernée, avec son ID et son titre un module, une séquence ou une activité (l objet est passé en paramètre) dates Affichage de toutes les traces générées Le formateur peut ainsi avoir une vision générale de l activité d un étudiant ou du suivi d une formation. Méthode implémentée : renvoie un tableau de traces de type Trace getalltraces ( Acteur, IDFormation, TitreFormation, Date[] ) Paramètres un apprenant la formation concernée, avec son ID et son titre dates Page 12 sur 63

14 Réponse à la problématique : service web Le choix de la technologie à utiliser pour extraire les traces a été fait assez tôt dans le processus de développement, lors de la seconde réunion avec le client et en accord avec lui. Choix du service web Nous avons décidé de développer une solution sous la forme d un service web en Java/JEE, hébergé sur un serveur d application : Tomcat. Pourtant, une deuxième solution s offrait à nous : il était possible de développer un plugin directement adapté à la plateforme de destination. En effet, pour Moodle par exemple, la plateforme fournit un certain nombre de librairies PHP pour l accès aux données de la base. Cependant, cette deuxième solution avait un certain nombre de défauts, notamment : Coder deux plugins : un pour Moodle, un pour SharePoint, en deux technologies différentes Couche d abstraction pour l accès au service à distance difficile à mettre en place Risque de non-rétrocompatibilité fort si la plateforme est mise à jour Evolutivité vers d autres plateformes de FOAD réduite La solution retenue, sous forme d un service web développé en Java, corrige ces points négatifs, bien qu il y ait toujours des défauts, mais moindres : Risque moyen de non-rétrocompatibilité (risque seulement lié à un changement de base de données) Besoin d installer un serveur d application Tomcat sur la machine hôte et de fournir à l application un accès en lecture à la base Cette solution a, de plus, les avantages suivants : Réutilisabilité des composants Façade unique d appel au service Protocole de communication standard et répondant au cahier des charges (SOAP/XML) Haut niveau d abstraction possible Evolutivité du service, ajout du support d autres plateformes facilité Page 13 sur 63

15 Structure coté serveur La structure d une telle solution coté serveur est la suivante : Serveur Moodle/Sharepoint Serveur Web SGBD Service Tomcat+Axis SOAP/http Client Figure 4 : Schéma fonctionnel du serveur Le «service» désigne la partie que nous développons. On le voit ici, il est complètement séparé de la partie dédiée à la plateforme de FOAD et l accès aux données se fait de manière indépendante. Le protocole de communication avec le client est basé sur SOAP (échange de données au format XML), via HTTP. Le serveur d application que nous avons choisi pour développer le service est Tomcat v7.0, couplé avec axis 1.4. Page 14 sur 63

16 Structure du Service Schéma Notre service, dans son implémentation, essaye de répondre au mieux aux exigences de maintenabilité : cohérence, concision, modularité, simplicité, documentation. Nous avons conçu notre service de façon à ce qu il suive un schéma de conception simple. Il est ensuite dérivé pour remplir les fonctions relatives à l extraction des données de Moodle ou de SharePoint. Service Constructeur de requête SQL SGBD J D B C Connecteur Manager Interpréteur de Résultat SQL Façade SOAP/HTTP Client Figure 5 : Schéma du service en blocs fonctionnels Rôle et implémentation des différentes parties Plus en détails, notre service est composé de 5 blocs dont les rôles sont les suivants : La Façade L accès à notre service depuis l extérieur («le client») se fait à partir de ce point-là. Cette façade est une classe java (controller.service) déclarant la liste des fonctions exposées au client. Cette classe est traduite, grâce à Axis, en un fichier WSDL au format pivot de description d un service. Le fichier décrit au client la façon dont il doit interroger le service, en toute indépendance de la technologie utilisée. Notre façade fournit 30 fonctions au client de la forme gettracesconsultation, gettraceseditions, Le Manager Toutes les requêtes envoyées à la façade sont retournées au Manager. Le rôle du Manager est d orchestrer les actions nécessaires à la résolution du problème. Le manager (controler.manager) fera appel successivement au constructeur de requête SQL, au connecteur et à l Interpréteur de résultat SQL. Page 15 sur 63

17 Le constructeur de requête SQL La première étape de traitement après l aiguillage du manager est la construction de la requête SQL. Ce rôle est implémenté par la classe controler.sqlpreparedrequest qui contient une seule méthode statique : requestasstring( ), qui délègue le travail à la classe controler.sqlpreparedrequestmoodle ou à la classe controler.sqlpreparedrequestsharepoint, suivant la configuration du service. Ce bloc a deux particularités : c est l un des blocs les plus importants du projet et il prend en compte les contraintes de sécurité en retournant une requête préparée suivie de ses paramètres, de manière séparée. L utilisation de requêtes préparés est une bonne pratique contre le piratage de base de donnée via l utilisation d injections SQL. En effet, la requête est compilée indépendamment de ses paramètres. Ceux-ci sont ajoutés par la suite et leur prise en compte est assurée par le JDBC. La construction de la requête joue un rôle très important dans la qualité du service. Elle est construite sur le principe des filtres. La fonction requestasstring( ) prend un certain nombre de paramètres qui joueront le rôle de filtres dans la recherche de traces. Par exemple, si un objet Forum est donné en paramètre à la fonction, la requête sera construite de telle sorte qu elle permette de retrouver les logs relatifs à ce forum. En plus des objets qui jouent le rôle de filtres, la fonction prend aussi une valeur énumérée en paramètre, indiquant le type de log recherché (consultation, création, édition, dépôt, etc.) Le connecteur Le connecteur que nous avons implémenté (jdbc.dbconnector) obéit à un pattern de fabrique abstraite et fournit une fonction fabriqueconnector() pour récupérer une instance d un objet jdbc.dbconnectorpg (Moodle, base PostgreSQL) ou jdbc.dbconnectorsp (SharePoint, base SQL Server) avec le JDBC adéquat. Ces deux connecteurs implémentent la classe abstraite DBConnector et fournissent notamment les fonctions suivantes : getconnection(), Connect(), Disconnect() et executequerry(). L interpréteur de résultat SQL La fonction executequerry() du connecteur retourne un objet de type ResultSet, c est à dire le résultat de la requête sous forme d un tableau aux lignes et colonnes variables. La classe jdbc.resultat, notre interpréteur, possède une liste de fonction du type resultsettotrace dont l objectif est de transformer le ResultSet en un ensemble d objets cohérents. L interpréteur effectue notamment les fonctions suivantes : récupération de la date de la trace récupération de l acteur (prénom, nom, mail, adresse) construction d une courte description du log reconstruction de l adresse internet de l objet consulté si le client le demande, l interpréteur récupère les données relatives à l objet consulté (titre, description, formation) Actuellement une seule version de cette classe est implémentée et elle suffit pour interpréter les résultats extraits d une base PostgreSQL (Moodle) ou Microsoft SQL Server (SharePoint), car nous récupérons les données sous un même format. Ajoutées à ces 5 blocs, deux classes servent de support à l ensemble du service : Jdbc.Settings Cette classe, associée à un fichier de configuration au format XML, fournit toutes les données de configuration utiles à notre service. A la manière d ADO (.Net) le fichier de configuration contient notamment les informations d accès à la base de donnée (JDBC, hôte, login). La classe Settings charge les données de configuration lors du premier appel du service. Ainsi, tout changement du fichier de configuration doit être accompagné d un redémarrage du service pour être effectif. Page 16 sur 63

18 Voici un exemple du fichier de configuration Conf/conf.xml <database_jdbc>org.postgresql.driver</database_jdbc> <database_type>jdbc:postgresql</database_type> <database_host>localhost</database_host> <database_name>moodle</database_name> <prefixe_table>mdl_</prefixe_table> <login_base>moodle</login_base> <password_base>exemple</password_base> <foad_address> Apache.log4J.Logger Figure 6: fichier de configuration Conf/conf.xml Nous avons configuré deux loggers qui tournent en continu pour notre service : un logger d erreur et un logger d information. Le flux stderr (le flux de sortie des exceptions) est redirigé automatiquement vers le logger d erreur. Le logger d information est configuré pour enregistrer les appels au service. Les fichiers de configuration des loggers sont dans le dossier WebContent/WEB-INF/classes et les logs apparaissent à la racine de Tomcat, avec l extension.log. Le logger est configurable grâce au fichier Log4J.properties. Le fichier de configuration doit être appelé à chaque utilisation du service par un client, à l aide des lignes suivantes dans le constructeur de Service.java : public Service(){ } PropertyConfigurator.configure( Service.class.getClassLoader().getResource("log4j.properties")); logger = Logger.getLogger("debug"); logger.info("appel du service"); Figure 7 : Appel du fichier de configuration des logs Exemple de log avec le nom des fonctions appelées et le temps pris pour retourner un résultat : :22:51,675 : controller.service.<init>: Appel du service :22:51,847 : controller.service.getlogins: temps d'execution : 171 ms :22:52,027 : controller.service.getlogouts: temps d'execution : 178 ms. Figure 8 : Exemple de log lié à l'appel du service Page 17 sur 63

19 L ensemble des blocs précédents, traduit en objets Java, peut être représenté comme suit : Service servicefilelog.log errors.log SGBD J D B C Manager.java Verte.java Settings.java Conf.xml Service.java apache.log4j.logger Log4j.properties Figure 9 : Blocs composant le service Page 18 sur 63

20 Diagrammes de classe Figure 10 : Modèle commun à l éditeur de scénario et au projet d extraction des traces (partie1) Page 19 sur 63

21 Figure 11 : Modèle commun à l éditeur de scénario et au projet d extraction des traces (partie2) Page 20 sur 63

22 Figure 12 : Modèle des traces Page 21 sur 63

23 Figure 13 : Modélisation du package Controller Page 22 sur 63

24 Diagramme de séquence d un cas nominal Ce schéma représente le cas nominal d utilisation du service web, pour la recherche des traces concernant les logins d un apprenant. Figure 14 : Cas nominal de la recherche des logins d'un apprenant Page 23 sur 63

25 Moodle Introduction à la plateforme Moodle La plateforme Moodle, que nous connaissons sous le nom de «campus-eseo» au sein de l école, est une solution open-source de portail web, dédiée à la FOAD. Moodle est en grande partie développé en PHP et ne nécessite qu un serveur apache et une base de donnée PostgreSQL ou MySQL pour fonctionner. Il est fourni, en annexe, grâce à M. Chavin, un tutoriel d installation. Pour notre part, nous avons installé notre plateforme de test sur un serveur semblable à celui utilisé par l ESEO : Debian6 + apache2 + base de données PostgreSQL. La plateforme Moodle permet la gestion de tous les objets nécessaires à un scénario de formation à distance et son modèle de données est semblable à celui développé pour l ensemble du projet Visualis. En effet, il est possible de créer des cours appartenant à des catégories différentes et de les associer à des outils pédagogiques : forums, dépôts, ressources, De plus, la gestion des utilisateurs permet la catégorisation professeurs/étudiant et la plupart des actions est loguée dans la base de données. Traduction des objets Moodle/model Faire coordonner, ou «tisser des liens», entre notre modèle de donnée et le modèle de donnée de Moodle a été une étape cruciale pour le développement de l application. Pour reprendre nos objets (cf. diagrammes de classe plus haut), nous avons fait l analogie avec les objets de plus bas niveau, pour remonter jusqu à la formation. L analyse a été tout d abord graphique Figure 15 : Extrait d'une page depuis le campus ESEO (cours plateforme.net) Nous reconnaissons facilement les objets suivant : 1. Une Ressource 2. Un outil de dépôt de Production Les cadres Bureau d étude et Cours (3) représentent donc des Activités et le cours Plate-forme.NET (4), en tant qu ensemble d Activités, est une Séquence. Page 24 sur 63

26 Revenons maintenant aux catégories de cours, la séquence.net appartient à la catégorie Option SI de la sur-catégorie S9 1 2 Nous avons donc ici : Figure 16 : Extrait de la liste "Tous les cours" du campus ESEO 1. Une Formation 2. Un Module, qui contient 13 séquences (dont.net) Voici donc le tableau de translation entre les modèles pour les objets les plus importants : MODELE FOAD Formation Module Séquence Activité OutilCommunication RessourcePedagogique Production Acteur APPELLATION MOODLE Catégorie de cours Sous-Catégorie de cours Cours Section de cours Forum ou Chat ou Wiki Ressource (lien vers un fichier ou un site web) Dépôt (ou assignment) Utilisateur (ou user) Figure 17 : Modèle et object Moodle En étudiant la structure de Moodle et en comparaison avec notre modèle, nous avons aussi déduit les faits suivants : Il y a équivalence entre consulter une Activité et consulter une Séquence. En effet, selon l Extrait du cours Plateforme.Net (figure15), la consultation d une séquence et de ses activités est indissociable Consulter une Séquence implique la consultation d un Module (non réciproque) Consulter un Module implique la consultation d une Formation (non réciproque) Consulter un Forum ou une ressource ou déposer un fichier n implique pas consulter une activité Éditer un Objet (Activité, Séquence, Module) implique éditer son parent (respectivement Séquence, Module, Formation) Module et Formation sont de même type pour Moodle (catégorie) l identification d un module ou d une formation est donc relative (catégorie / sous-catégorie) Page 25 sur 63

27 Structure des logs La base de données de Moodle contient 198 tables. La première à nous intéresser s appelle mdl_log. Elle contient tous les logs. En voici la structure : Voici quelques exemples de logs : Figure 18 : Table des logs Moodle : mdl_log Un log, sous Moodle, est composé des parties suivantes : id : l identifiant du log, son numéro Figure 19 : Exemple de logs Moodle time : l heure du log. Le format utilisé est proche du Timestamp, mais sans l indication des millisecondes. Pour transcrire le temps au format Timestamp il faut donc multiplier le chiffre indiqué par 1000 userid : l id de l utilisateur qui a effectué l action ip : son IP course : indique le cours (=la séquence) concerné par le log module : représente un objet de la formation : ce champ indique le type d objet visité, ce peut être : cours, forum, assignemnt, resource,. Ce champ va de paire avec le cmid cmid : le Course-Module ID. Cet Id ne pointe pas directement vers l objet visité, mais vers une table de jointure action : indique l action effectuée. Laction peut être de type add, view, update, edit, delete, upload, login ou logout url : l url spécifiée doit être complétée par l adresse de Moodle, plus le fichier PHP d affichage qui varie selon le type d objet visité (le «module») info : peut contenir une information complémentaire. Par exemple, lors d une suppression de module, son nom est supprimé. Dans le cas d une discussion, il contient l id du message posté Page 26 sur 63

28 Structure de la base de donnée et problèmes de jointures De par le nombre important de tables, Moodle propose une base de données très complète. Cependant, nous nous sommes rendu compte que les jointures à effectuer pour retrouver les informations nécessaires pour rechercher et compléter nos logs étaient très compliquées. Voici le tableau de translation. Dans la colonne «table de jointure» est indiqué s il faut utiliser une table secondaire pour faire la jointure entre le log et l objet du modèle. Modèle FOAD Appellation Moodle Table associée Table de jointure Formation Catégorie mdl_course_categories mdl_course, mdl_course_categories Module Sous-Catégorie mdl_course_categories mdl_course Séquence Cours mdl_course Activité Section mdl_course_sections OutilCommunication Forum mdl_forum mdl_course_modules RessourcePedagogique Ressource mdl_resource mdl_course_modules Production assignment mdl_assignment mdl_course_modules Acteur user mdl_user Figure 20 : Tableau des jointures entre le log et le modèle (Moodle) Page 27 sur 63

29 Le cas de la jointure est particulièrement compliqué lorsque l on veut récupérer les messages déposés par un utilisateur sur un forum donné. Voici un exemple de requête générée : Messages: [select l.id as ID, l.time as HEURE, l.url as URL, l.module as OBJET_TYPE, l.info as INFO, u.id as USERID, u.firstname as PRENOM, u.lastname as NOM, u. as , u.phone1 as TELEPHONE, u.address as ADRESSE, u.city as VILLE, u.country as PAYS, formation.id as ID_FORMATION, formation.name as TITRE_FORMATION, module.id as ID_MODULE, module.name as TITRE_MODULE, sequence.id as ID_SEQUENCE, formation.name as TITRE_SEQUENCE, forum.id as ID_FORUM, forum.name as OUTILCOM_NOM, forum.intro as OUTILCOM_DESCRIPTION, messages.message as MESSAGE, messages.subject as MESSAGE_SUJET, messages.attachment as MESSAGE_PIECE_JOINTE from mdl_log l, mdl_user u, mdl_course_categories module, mdl_course_categories formation, mdl_course sequence, mdl_forum forum, mdl_course_modules course_module, mdl_forum_posts messages, mdl_forum_discussions discussions where l.userid = u.id and l.course = sequence.id and module.id = sequence.category and module.parent=formation.id and u.id=? and u.firstname like? and u.lastname like? and u.confirmed = 1 and l.module like 'forum' and course_module.id=l.cmid and course_module.instance=forum.id and forum.course = sequence.id and ( ( l.action like '%discussion' and discussions.id = CAST(l.info as BIGINT) and messages.id=discussions.firstpost ) OR ( l.action like '%post' and messages.id = CAST(l.info as BIGINT) and messages.discussion=discussions.id ) ) and (forum.name like?) and (l.action like 'add post' or l.action like 'add discussion' or l.action like 'talk');, 2, Admin, User, ForumPourDiscuter] Nous distinguons 4 parties : les 3 clauses : SELECT, FROM, WHERE, et les arguments (paramètres). Select La partie SELECT liste toutes les informations dont nous aurons besoin pour reconstruire les informations relatives au log : La personne, la formation, le module, la séquence : ce sont des informations nécessaires pour pouvoir décrire la trace Nous récupérons les informations relatives au forum de discussion et au message déposé via la dernière partie du select : l id du forum, son nom, sa description, le message déposé, le sujet du message, et si présent : la pièce jointe From Dans la clause FROM, apparaissent les tables utilisées : mdl_log, mdl_user, mdl_course_categories, mdl_course : les tables décrites plus haut mdl_forum, mdl_course_modules, mdl_forum_posts, mdl_forum_discussions : les tables pour récupérer les informations relatives au forum et au message déposé. Page 28 sur 63

30 Where Dans la clause WHERE, apparaissent les conditions de jointure : Le forum concerné par le log est donné grâce à la table de jointure course_modules : course_module.id=l.cmid and course_module.instance=forum.id L ajout d un message peut être une réponse à une discussion (un post) ou la création d une discussion (un add discussion) l.action like 'add post' or l.action like 'add discussion' Dans le cas de la création d une discussion, l id de la discussion est donné par le champ info du log, et le message est le premier message de la discussion (firstpost) : (( l.action like '%discussion' and discussions.id = CAST(l.info as BIGINT) and messages.id=discussions.firstpost ) Ou: OR Dans le cas d une réponse à une discussion, l id du message est donné par le champ info du log et il faut tout de même faire la jointure avec la discussion (obligatoire pour éviter les problèmes occasionnant des résultats combinatoires.) ( l.action like '%post' and messages.id = CAST(l.info as BIGINT) and messages.discussion=discussions.id ) ) Il convient de vérifier que le log est relatif à la personne que nous cherchons : and u.id=? and u.firstname like? and u.lastname like? and u.confirmed = 1 Et nous ne cherchons que les logs relatifs à un certain forum: forum.name like? Les arguments Chaque point d interrogation est à remplacer par les paramètres voulus (dans l ordre) : 2, Admin, User, ForumPourDiscuter Il est bien sûr possible d ajouter des filtres supplémentaires, pour la formation par exemple (si cas de deux forum homonymes dans deux formations différentes). Après passage par l interpréteur de résultat SQL, nous obtenons la trace suivante : Trace 1 : Message [ outilcom=model.execution.forum@ec115b (idoutilcommunication:, nom: ForumPourDiscuter, description: null), getdescription()=log n : 610; ForumPourDiscuter; (Forum pour discuter) ; Message: Je parle, Sujet: Test de sujet de discussion;, getacteur()=model.execution.acteur@6798eb (idacteur: 2, nom: User, pays: null, region: null, ville: null, adresse: null, sexe: null, nationalite: null, prenom: Admin, datenaissance: null, null, ntelephone: null), getformation()=model.scenario.formation@168989e (idformation: 7, titre: FormationS2, objectif: null, description: null, niveau: null, prerequis: null, porteur: null, partenaires: null, commenditaire: null, client: null, contact: null, commentaire: null, generique: false), getdate()=fri Dec 07 19:02:55 CET 2012, getlien()= Il a fallu 370 ms pour exécuter la recherche et la mise en forme du résultat, ce qui est assez raisonnable. Le message déposé par l utilisateur est consultable via l attribut description de la trace. Page 29 sur 63

31 Nous avons mis en place, pour Moodle, un système de recherche avancé permettant de retrouver les informations de l objet consulté. Ces informations peuvent être retrouvées dans la description du log ou dans les objets associés. Par exemple, si le client veut savoir quels modules a consulté l Acteur acteur, il peut faire l appel suivant : getconsultationsmodule(acteur, null, null, null, null) Cet appel rendra des traces de type Consultation relatives à l acteur donné avec, en attribut, le Module consulté et la Formation associée. Les informations que nous pouvons récupérer sont les suivantes : Objet FOAD Tables Moodle associées Champs récupérés Formation mdl_course_categories Id, Titre Module mdl_course_categories Id, Titre Séquence mdl_course Id Titre Activité mdl_course_sections Id, Titre OutilCommunication mdl_forum Id, Nom, Description mdl_forum_discussions mdl_forum_posts Sujet Message, Pièce Jointe RessourcePedagogique mdl_resource Type, Lien, Nom, Description Production mdl_assignment Titre Depot, Description Depot Acteur mdl_user Id, Nom, Prenom, , (+Telephone, Adresse, Ville, Pays si indiqué par l utilisateur) Figure 21 : Informations récupérables dans les traces de Moodle Page 30 sur 63

32 Conclusion L extraction des traces sous Moodle a été compliquée à cause des jointures. Cependant c est aussi ce qui donne sa richesse à la plateforme, car nous pouvons récupérer toutes les informations dont nous avons besoin. Nous nous sommes, de plus, rendus compte que le modèle proposé par Moodle est assez proche de celui que nous avons défini pour la FOAD, ce qui a facilité notre travail. Après cette analyse, quelques points sont à mettre en avant : Une Activité est indissociable de sa Séquence. De plus, dans une Séquence, il y a souvent plusieurs activités vides, du fait des paramètres par défaut de Moodle (Moodle crée des sections vides à la création d un cours). En conséquence, la granularité «Activité» n est pas forcement la plus adaptée à l étude des traces sous Moodle. Moodle enregistre les traces par rapport à la Séquence (cours) ou par rapport à la Ressource visitée (grâce au champ cmid). Par conséquant, ce sont les deux niveaux de granularité à préférer pour l obtention des traces. De plus, concrètement, Moodle ne fournit aucune trace relative à la gestion des catégories (granularité Module ou Formation). Les traces retournées par les fonctions getconsultationsformation, geteditsformation, getconsultationsmodule, geteditsmodule suivent donc les règles indiquées dans la partie Traduction des objets Moodle/model dans la liste des faits déduits. Les fonctions getdeleteformations et getdeletemodules ne retournent aucun résultat. Pour un résultat cohérant dans la recherche de traces, la plateforme devra respecter les règles d organisation des cours : Les catégories représentent les Formations, les sous-catégories représentent les Modules, les cours représentent les Séquences, les sections de cours représentent les Activités auxquelles il est possible d associer des ressources. Les recherches de logs se font essentiellement à l aide du titre ou de l id de l objet de la recherche. Ainsi, une fonction dont la déclaration est public Depot[] getdepotsproduction(acteur acteur, String idformation, String titreformation, Production production, Calendar[] date) pourrait être déclarée de la façon suivante : public Depot[] getdepotsproduction(string nomacteur, String prenomacteur, String , String idacteur, String idformation, String titreformation, String titreproduction, String idproduction, Calendar[] date) La déclaration semble plus longue, mais elle pourrait faciliter l échange des données entre le client et le serveur et améliorer la performance du service. Cependant, nous avons choisi de conserver la représentation objet haut niveau. Enfin, la contrainte d unicité des noms dans une formation (il n existe pas deux forums de même nom dans une même Formation) n est pas respectée dans Moodle. Il existe autant de forums portant le nom «Forum des nouvelles» dans une formation qu elle contient de Séquences. Les traces relatives à ces forums sont donc erronées, à moins de connaitre les id respectifs de chacun des forums. L ensemble des fonctionnalités fournies par le service a été testé et est fonctionnel avec Moodle ce qui est un succès. Page 31 sur 63

33 SharePoint Introduction à la plateforme SharePoint Nous avons développé des méthodes pour exploiter certaines traces générées sur la base de données SQL Server de SharePoint. Cette solution permet la mise en place de sites collaboratifs afin de partager des informations entre plusieurs utilisateurs et la gestion de documents. Cet outil est donc particulièrement adapté à la formation à distance. Comme pour Moodle, nous avons mis en place un service web proposant au client de visualiser les traces liées à l utilisation du campus. Des filtres sont disponibles pour affiner la recherche à souhait. Connexion à la base de données SharePoint est connecté à une base de données Microsoft SQL Server. Pour s y connecter depuis notre application java, nous avons utilisé les paramètres suivants : JDBC : com.microsoft.sqlserver.jdbc.sqlserverdriver Type de base de données : jdbc:sqlserver Serveur SQL de développement du projet : EDISON69-PC\SQLEXPRESS2 Nom de la base à interroger : Audit_Enovaxe Login : etudiant Password : network Structure des logs Champs de la table Pour travailler sur ce campus numérique, nous avions un fragment de base de données, fourni par l ESSCA, limité à une seule table nommée dbo.auditdata. Elle comprend la plupart des logs relatifs à la consultation de pages web et de documents. La table que nous avions à notre disposition comporte les colonnes suivantes : SiteID : id relatif au serveur SharePoint utilisé (ici, toujours le même) ItemID : id pour chaque log qui est recensé dans la base de données UserID : id de l utilisateur qui génère les logs DocLocation : emplacement du document ou de la page visitée Occurred : date et heure du log ItemType : type d élément consulté (1 page ou fichier ; 3 élément d une liste ; 4 liste ; 5 dossier ; 6 site ; 7 web) Event : type de log (1 CheckOut ; 2 CheckIn ; 3 View ; 4 Delete ; 5 Update ; 10 Undelete ; 12 Copy ; 13 Move) Page 32 sur 63

34 Exemple d URL recensée dans les logs SiteCollectionDocuments/MSK_refonte/Module- 420/MSK_421_Gerer_chaine_valeur_interne/Documents/MSK421-travail_preparatoire_2.pdf SiteCollectionDocuments : relatif au serveur SharePoint MSK_refonte : l ID de la formation est MSK, son titre est «Master ESSCA» Module-420 : ID du module qui est concerné par le log, son titre est «Le business Model et l'architecture de valeur» MSK_421 : ID de la séquence concernée par le log Gérer la chaine de valeur interne : titre de la séquence Documents : l utilisateur a consulté une ressource et non une page web Travail_preparatoire_2.pdf : nom de la ressource vue Problèmes rencontrés La principale difficulté rencontrée était due au manque d informations fournies par la table de la base de données. En effet, contrairement à Moodle où la base de données est fixe, SharePoint permet de choisir les logs que l on souhaite enregistrer. Compte tenu la taille très importante que prend la base de données SQL Server, nous n avions que des informations peu détaillées concernant les logs. Par exemple, nous n avions que les ID des utilisateurs : nous ne pouvions pas faire une jointure sur une autre table pour connaître leurs nom et prénom. De plus, seule l URL fournie par la table de log était exploitable quant aux pages et documents visités. Nous ne pouvions donc pas filtrer les recherches par nom de formation, module, mais seulement par leurs ID qui ne sont pas explicites pour l utilisateur. De même, nous n avons pas pu visualiser les logs de connexion et déconnexion, qui n étaient pas enregistrés dans la base de données. Les outils de communication tels les forums ou chats n étaient pas non plus exploitables. La gestion du scénario, à savoir sa création, sa modification et la suppression de certains éléments n est pas non plus loguée dans la base de données. Conclusion Nous avons exploité au mieux la table qui nous était fournie, afin d extraire les logs relatives à SharePoint. L ensemble des fonctionnalités proposées pour Moodle n a pas pu être adapté, à cause du manque d informations disponibles. Afin de visualiser l ensemble des traces, il serait nécessaire de configurer le serveur SharePoint pour enregistrer davantage de logs, concernant toutes les activités réalisées par les apprenants. Page 33 sur 63

35 JSP de test L extracteur de trace sera utilisé par l équipe qui réalise une application graphique pour plateforme mobile. Le formateur pourra sélectionner les filtres qu il souhaite appliquer pour visualiser les logs. Cependant, afin de s assurer du bon fonctionnement de notre projet, nous avons développé des JSP de test, afin de spécifier nous-mêmes les formations, activités ou encore étudiants à prendre en compte. Cela représente une alternative à l application graphique, qui permet de contrôler les résultats obtenus, d une part pour notre binôme, mais également pour le groupe basé au Mans, pour garantir la cohérence des résultats. Exemple de trace Test de la fonction getlogin ( acteur, dates[] ) Login [getacteur()=model.execution.acteur@5d727a (idacteur: 2, nom: reynaert, pays: null, region: null, ville: null, adresse: null, sexe: null, nationalite: null, prenom: benoit, datenaissance: null, null, ntelephone: null), getformation()=model.scenario.formation@7a152c (idformation: 1, titre: Formation S1, objectif: null, description: null, niveau: null, prerequis: null, porteur: null, partenaires: null, commanditaire: null, client: null, contact: null, commentaire: null, generique: false), getdate()=tue Dec 11 11:45:21 CET 2012, getlien()= Acteur : idacteur : 2 nom : reynaert prenom : benoit Les autres champs (pays, ville, adresse, ) n ont pas été renseignés dans notre base Moodle, donc ne sont pas retournés dans les logs) Formation : idformation : 1 Titre : Formation S1 Les autres champs (objectif, description, niveau, ) n ont pas été remplis lors de la création de la formation Date : Mardi 11 décembre h45 Lien : correspond à la page web de la formation «Formation S1» Présentation Ces JSP permettent de tester l ensemble des fonctionnalités que nous avons développées. Elles sont directement liées au service web qui sera proposé à l utilisateur final. Un index permet de spécifier les filtres ; l utilisateur remplit les champs qu il souhaite les champs laissés vides ne sont donc pas pris en compte. Page 34 sur 63

36 La configuration ci-dessous permet de visualiser les traces de l étudiant «benoit reynaert», concernant la formation «Formation S1», dans l intervalle de temps qui court du «10 décembre 2012» au «13 décembre 2012». La plateforme concernée est Moodle. Figure 22 : index.jsp - Page d'accueil pour utiliser le service web Page 35 sur 63

37 Les traces correspondant à la recherche effectuée sont représentées sur le JSP suivante, ordonnées de la plus ancienne à la plus récente. L utilisateur benoit reynaert s est connecté et déconnecté deux fois entre le 10 et le 13 décembre Figure 23 : Affichage des traces correspondantes Page 36 sur 63

38 La figure suivante représente les traces de consultation du module «Module 220», pour la formation «MSK», concernant l individu d ID 15, pour la période du 15 au 20 octobre Toutes les traces ne sont pas visibles sur la capture d écran. Figure 24: Traces de consultation d'un module sur SharePoint Page 37 sur 63

39 Conclusion À la fin de notre projet, nous avons rencontré l ensemble des professeurs de l ESEO concernés, Monsieur Teutsch, et Madame Licchelli, afin de présenter notre travail. Concernant la plateforme Moodle, l ensemble des fonctionnalités demandées a été implémenté et les résultats obtenus sont corrects. Le projet est donc une réussite concernant cette plateforme. Les traces pourront donc être utilisées par l équipe du Mans qui va permettre leur affichage dans une application mobile. En revanche, concernant SharePoint, la pauvreté de la base de données à notre disposition ne nous a pas permis de produire un service web aussi complet que pour Moodle. Nous avons exploité au mieux les traces à notre disposition et implémenté les méthodes adéquates. Il est donc possible de poursuivre l avancement de ce projet, en intégrant une base de logs plus complète, pour avoir les informations nécessaires à la mise en place des mêmes fonctionnalités que pour le campus Moodle. Ce projet a été une opportunité de mettre en pratique nos connaissances en Java et J2EE, à travers un cas concret réel. En effet, notre travail sera utilisé dans le cadre de la formation à distance, à l université du Maine, au Mans. De plus, concernant la partie SharePoint, une équipe de développement poursuivra l implémentation pour compléter le panel de fonctionnalités disponible. Nous avons également mobilisé nos compétences en termes de recensement des besoins, pour comprendre les attentes des professeurs et ainsi proposer une solution adéquate. Nous avons donc fait la traduction des besoins métiers en solution technique. Avant de procéder au développement et à l écriture du code, nous avons modélisé l ensemble d un scénario d apprentissage avec le langage UML, en collaboration avec le binôme chargé de produire un éditeur de scénario. Nous avons travaillé ensemble afin d aboutir à un modèle commun, afin de garantir l interopérabilité de chaque partie pour le projet global. De plus, nous avons échangé avec l équipe du Mans afin de déterminer leurs besoins fonctionnels et les informer des méthodes que nous avions implémentées, ainsi que les paramètres à prendre en compte. Ce projet a donc été une opportunité de faire travailler plusieurs équipes entre elles, malgré la distance. Enfin, avant de faire la démonstration de notre production aux professeurs, nous avons procédé à de nombreux tests, tout au long du développement et une fois le projet terminé. Nous avons comparé les traces obtenues avec notre application avec celles recueillies directement sur la base de données. Nous avons ainsi validé l extraction et la mise en forme des traces obtenues. Page 38 sur 63

40 Glossaire API DSL FOAD GUI GWT JDBC OASIF RIA SVG UML WPF XML Application Programming Interface Domain Specific Language Formation ouverte à distance Graphical User Interface Google Web Toolkit Java DataBase Connector Outil d'aide à la Scénarisation pour l'ingénierie de la Formation Rich Internet Application Scalable Vector Graphics Unified Modeling Language Windows Presentation Foundation extensible Markup Language Page 39 sur 63

41 Bibliographie BOURDET Jean-François, TEUTSCH Philippe, i l i g f m i à i, Lium, Laboratoire d Informatique de l Université du Maine GALISSON Arnaud, NOUVEAU Jean-Sébastien, OASIF : un outil collaboratif i à l é i i modules de formation ouverte et à distance, Télécom Paris, département Innovation Pédagogique BARAIS Olivier, BEAUDOUX Olivier, BLOUIN Arnaud, JEZEQUEL Jean-Marc, Specifying and Implementing UI Data Bindings with Active Operations BARAIS Olivier, BEAUDOUX Olivier, BLOUIN Arnaud, CLAVREUL Mickael, JEZEQUEL Jean-Marc, YANG Mengqiang, Specifying and Running Rich Graphical Components with Loa BOURDET Jean-François, TEUTSCH Philippe, M li é i i f m i l ig m ligne, Université du Maine CREN, Rentre de Recherche en Éducation de Nantes, France Page 40 sur 63

42 ANNEXES Page 41 sur 63

43 Recherche Documentaire Introduction Face au développement des campus numériques dans les écoles et universités, formateurs et apprenants sont désormais à travailler ensemble, depuis différents endroits. L éloignement de ces deux parties ne doit pas être un obstacle au bon déroulement de la formation. Il est donc possible d étudier depuis n importe quel endroit, sans nécessité de présence de tous les participants : c est la formation ouverte à distance. Cette méthode de travail, souvent raccourcie à ses initiales, FOAD, se caractérise tout d abord par sa flexibilité. En effet, l apprenant dispose d une grande autonomie dans la gestion de son apprentissage. Il adapte son enseignement à ses disponibilités et ses contraintes personnelles. L individu est donc pris en considération, et plus seulement le groupe avec lequel il suit la formation. De plus, la FOAD permet de concerner un nombre important de personnes, puisque les contraintes spatiales et temporelles ne sont plus d actualité. Dans la majorité des cas, les formations sont dispensées via internet, et chacun y a accès depuis n importe quel ordinateur. Afin d assurer le bon déroulement de la formation pour tous les participants, une organisation particulière est nécessaire. L apprentissage doit être structuré ; différents modules composent la formation, des délais sont imposés. Un scénario clair et précis doit donc être mis en place avant le début de l enseignement, pour délimiter tous ces facteurs qui délimitent le cadre de travail. Cependant, le contexte de la formation à distance ne doit pas être figé. La flexibilité proposée par cette méthode de travail doit permettre au formateur de modifier son scénario lorsqu il le juge nécessaire, par exemple s il s aperçoit qu il a mal évalué la difficulté de certains cours, ou si un nombre non négligeable d apprenants ne peut respecter les délais fixés. La modification en cours de formation est donc indispensable pour s adapter au mieux aux utilisateurs. Il est également important de noter que les utilisateurs sont très différents les uns des autres. Du point de vue des compétences, tous les formateurs qui utilisent la FOAD ne disposent pas d un bagage informatique important ; la simplicité d utilisation des applications est donc nécessaire. De plus, les formations dispensées sont diverses et variées, et les acteurs n ont donc pas les mêmes domaines d activité. Une pluridisciplinarité de la FOAD est donc à prendre en compte. L objectif de notre projet est donc de proposer une solution répondant aux exigences de la formation ouverte à distance, et aux exigences de ses acteurs. D une part, une application permettra aux formateurs de créer les scénarios des formations. Cette organisation sera ensuite rendue publique aux futurs apprenants, et intégrée sur un campus numérique. Dans le but d obtenir les meilleurs résultats possibles et de procéder aux éventuels ajustements du scénario, le formateur doit pouvoir suivre le travail de chaque individu, à distance. L absence de proximité telle un professeur et ses étudiants ne doit pas représenter un obstacle au suivi de chacun. Le système doit donc fournir au formateur les retours nécessaires concernant l avancée de l apprentissage en cours. Ce retour permet ainsi de mettre en évidence les différences de ressenti concernant la situation d apprentissage, du point de vue de l apprenant et celui du formateur. La visualisation du degré d avancement de l individu par rapport au contexte fixé initialement ainsi que de la réussite ou non des activités rendront possible ce retour. Enfin, une interaction entre formateur et apprenant est indispensable. La possibilité de communication, d échange de messages, de commentaires concernant les différents exercices ou de questions engendrera un bon déroulement de la formation. L objectif est donc de mettre au second plan l absence de proximité entre chaque partie, et de valoriser les échanges entre les acteurs. Page 42 sur 63

44 Présentation de la formation ouverte à distance Généralités Pourquoi la formation à distance? L enseignement comporte des cours exclusivement théoriques, sans pratique L apprenant a un handicap qui l empêche de suivre une formation «classique» L étudiant est loin du lieu de formation La personne n a pas le temps nécessaire pour suivre une formation en présentiel La FOAD, pour qui? Des étudiants dans le cycle supérieur Des cadres ou formateurs d entreprises Des travailleurs qui doivent sans cesse être au courant des nouveaux changements concernant leur domaine d activité Quels sont ses avantages? La flexibilité de la formation Un rythme adapté à chacun Une formation ciblée Un suivi régulier par le formateur Une possibilité d échanges pour être plus efficace Ses inconvénients? Pas de contacts physique et humain entre formateur et participants Motivation personnelle nécessaire pour suivre la formation La FOAD est caractérisée par trois grandes dimensions : le scénario, le calendrier et les participants. Chacune des dimensions est étroitement liée avec les autres. Le calendrier impose le planning et le rythme de la formation aux participants. Les participants suivent le scénario qui correspond à la trajectoire de leur formation. Enfin, le scénario est projeté sur le calendrier qui fixe les contraintes temporelles et l emploi du temps à suivre. De plus, il existe un lien fort qui rapproche le formateur de ses apprenants. Le tuteur doit être capable de connaître le profil de ses «élèves», leurs compétences, leur niveau initial, leur progression. C est une véritable situation d accompagnement qui est mise en place, permettant un suivi régulier de chacun. Pour être au courant de chaque situation, des interfaces graphiques sont indispensables pour venir en aide au formateur. Leur enjeu principal est de réduire le nombre d informations recensées par la plateforme, pour ne fournir au tuteur que celles dont il a besoin. Des données très hétérogènes sont donc triées et organisées, afin de permettre à l utilisateur de choisir les indications qu il souhaite voir apparaître à l écran. Visualiser l'avancement de la formation Le principal inconvénient de la formation à distance est le manque d interfaces permettant au formateur de suivre l avancée de ses apprenants. Cela permet ainsi d adapter le scénario suivant les difficultés rencontrées par chacun, et de s assurer que les différents cours sont étudiés et les exercices faits. Des interfaces doivent présenter au formateur des graphiques montrant les activités réussies et celles où l apprenant a échoué, des statistiques concernant le temps passé sur chaque cours. Il doit également connaître la périodicité à laquelle la personne qui suit la formation se connecte. Le formateur ne peut se satisfaire du seul retour proposé par l évaluation des apprenants, il doit les suivre pas à pas, tout au long de la formation, pour s assurer de son bon déroulement. Des échanges réguliers sont donc nécessaires. Page 43 sur 63

45 Plusieurs vues sont donc nécessaires pour permettre l affichage au plus précis des données nécessaires au formateur. Compte tenu de la différence entre les formateurs, les applications doivent être intuitives et faciles d utilisation, notamment pour choisir les informations affichées, et basculer entre els vues. Comparer le travail des étudiants Tout au long de la formation, le formateur doit avoir la possibilité de comparer le travail de ses apprenants, et ce à différentes échelles. Plusieurs dimensions sont à prendre en compte, comme l avancée dans la formation, le pourcentage de réussite aux exercices, le temps consacré à chaque chapitre, les notes obtenues aux examens L échelle individuelle : comparaison entre deux individus L échelle collective : comparaison d un individu avec un groupe d individus L échelle globale : comparaison avec l ensemble des apprenants qui suivent la formation Le formateur peut donc déceler les différences de niveau ou d avancement entre les apprenants, et modifier son scénario initial si nécessaire. Il doit gérer deux situations qui sont, au premier abord, opposées. Il doit animer la formation pour un collectif, tout en étant attentif à chaque situation individuelle des apprenants. Projection du participant sur le calendrier Le formateur doit pouvoir contrôler l assiduité de ses apprenants, pour expliquer leur avancement et leur réussite dans la formation. Il a également la possibilité de vérifier si l étudiant respecte le calendrier fixé, en ce qui concerne le suivi des cours, le rendu des documents Cette visualisation permet aussi une ébauche du parcours prévisionnel de l apprenant ou du groupe d individus, pour la suite de la formation. Cela permet de prédire d éventuels retards ou de déterminer si certaines activités vont être échues en avance par rapport au calendrier. Modifier le scénario en fonction de l'avancement Une des caractéristiques importantes de la FOAD est sa flexibilité. Le tuteur doit savoir comment se déroule le programme d apprentissage, pour être capable de le modifier si nécessaire. Il a la possibilité d agir sur de nombreux paramètres et par conséquent, d affiner les contraintes en fonction des participants. La dimension temporelle, représentée par le calendrier, temporise la formation en imposant les délais. En modifiant le planning initial, le tuteur peur ajuster son scénario au travail général de son groupe. Le paramètre scénario structure de la formation ; c est le fil conducteur à suivre pour chaque participant. Il décrit les tâches, objectifs, contenus, modalités que chacun doit suivre. Le formateur peut donc également influer sur son scénario, pour adapter la formation aux participants. La mise à jour d un scénario en cours de formation n est possible que si le tuteur dispose de suffisamment d informations pertinentes, pour déceler le réel intérêt d une modification. Échanges entre formateur et apprenant La possibilité d échange entre le formateur et ses élèves est indispensable. La FOAD doit proposer l envoi de message de la part des deux parties. L apprenant doit pouvoir poser ses questions, demander des renseignements, et son professeur doit pouvoir l aider, le conseiller, lui expliquer la formation. Ces échanges par voie numériques doivent remplacer les échanges physiques rendus impossibles par la distance de la formation. Les participants correspondent au paramètre qui regroupe les caractéristiques du groupe d apprenants, chacun ayant ses propres «particularités». Le formateur doit les prendre en compte pour personnaliser les échanges à distance avec ses élèves. Page 44 sur 63

46 Des utilisateurs divers et variés Une des principales difficultés de la conception d un système pour gérer la FOAD relève de la grande diversité des utilisateurs. Tous les secteurs de formation peuvent être concernés par le tutorat à distance, et les compétences notamment informatiques de chacun seront donc très hétérogènes. Il en découle qu une facilité d utilisation du système est nécessaires. De plus, différentes tâches seront mises en œuvre selon le type de formation considéré, et donc le panel de fonctionnalités proposé par l éditeur de scénario devra être complet. En amont de la formation, les enseignants, ingénieurs pédagogiques et technologues coopèrent autour d une même situation et effectuent ensemble les choix concernant la formation. Exploiter les traces liées à l'apprentissage Pour permettre un retour sur l activité des apprenants, seules les traces générées par leurs activités sont exploitables. L objectif est d interpréter les traces générées par le campus numérique et de permettre leur visualisation par le formateur. Le schéma suivant représente la gestion des traces, depuis leur création par la plateforme numérique, jusqu à leur exploitation rendue possible. Système de visualisation Système d interrogation SYSTEME DE GESTION DES TRACES Système de transformation Modèles de transformation Système de collecte Source de traçage Figure 25 : Système de gestion des traces Pour résumer Les fonctionnalités En résumé, pour garantir le déroulement optimal de la formation à distance, le système informatisé qui gère le scénario et le processus d apprentissage doit répondre aux objectifs suivants : Proposer des interfaces qui permettent au tuteur de visualiser des informations d ensemble et de détail, concernant le groupe ou un individu en particulier. Possibilité de basculer rapidement d une vue synthétique à une vue plus détaillée, pour faciliter le suivi du tuteur. Permettre de contextualiser les informations remontées, c est-à-dire connaître avec précisions les conditions dans lesquelles les apprenants étudient, pour donner un sens à leurs activités recensées. Croiser les données, pour comparer les avancements de chacun par rapport aux autres ou à l ensemble, établir des statistiques, déceler la moindre anomalie. Page 45 sur 63

47 Trois dimensions : Participants, Calendrier et Scénario SCÉNARIO Objectifs formation de Trajectoire à construire Activités en cours Passé Présent Délai de formation CALENDRIER Trajet effectué Début de formation Modules acquis Notre Projet Schéma général Figure 26 : Schéma récapitulatif des trois dimensions clés de la FOAD La ligne de vie d'un scénario d'apprentissage est réduite aux 4 points suivants : L'éducateur crée un scénario Le scénario est exporté vers la base Moodle ou MS SharePoint et est déroulé par des apprenants. Chaque apprenant laisse des traces de son apprentissage, qui sont loguées. Les traces sont triées et organisées pour être exportées L'éducateur visualise l'activité de ses apprenants et compare leur avancement avec le scénario prévu Par conséquent, cette réduction permet de distinguer 4 sous-fonctions à développer, chacune correspondant aux points évoqués ci-dessus : Edition de scénario Exportation vers Moodle ou SharePoint de scénario Extraction des Traces Visualisation des Traces Le travail à réaliser a été délégué à 4 groupes de développement dont deux présents à l ESEO, en option Systèmes d Information. Le groupe BOURDON Florent ZÉTULE Antoine a pour mission de concevoir et développer un éditeur de scénario basé sur le principe d OASIF, un logiciel existant. Cet éditeur devra permettre l exportation des scénarios créés, au format XML. Le binôme BERNAILLE Charles-Édouard REYNAERT Benoît a pour mission d étudier et créer un plugin pour Moodle et SharePoint, permettant l extraction et la mise en forme des traces sous un format XML. Le fonctionnement des différentes parties du projet entre-elles peut être représenté comme suit. Les fonctionnalités développées pas l ESEO sont donc représentées par les numéros 1 et 3. Page 46 sur 63

48 Application à créer : éditeur de scénarios L objectif Figure 27 : Fonctionnalités du projet Notre objectif est de mettre en place un outil pour la FOAD qui permettra à un formateur de construire un scénario d apprentissage destiné aux apprenants. Cet éditeur doit prendre en compte les trois dimensions essentielles qui se dégagent de la formation à savoir : le scénario lui-même, le calendrier et les participants. Le scénario est le fondement de l application, il doit fournir la structure de la formation et son fil conducteur. Il va notamment définir un axe à suivre pour l ensemble des acteurs en décrivant le contenu de la formation. Le système doit mettre en relief la structure suivante : Formation > modules -> séquences d activité -> activités pédagogiques. De plus, les ressources (accompagnements, matériels ) allouées à chaque activité pourront-être renseignées. Le calendrier doit offrir une vue temporelle sur le déroulement de la formation. Il doit permettre de spécifier la durée attendue pour une certaine activité tout en prenant en compte le rythme individuel d apprentissage. Il faut pouvoir accommoder le calendrier par rapport à l avancement réel de manière à s adapter au rythme des apprenants. Cette dernière remarque souligne notamment l intérêt de suivre l activité des apprenants à travers les traces. Les participants et l environnement dans lequel ils évoluent sont une dimension essentielle à prendre en compte. Par exemple, il peut être intéressant d étudier l avancement d un individu par rapport au groupe, les différences de niveaux, l éloignement entre les différents participants, la dynamique de groupe ou encore les interactions possibles. Tous ces éléments peuvent aider quant à la compréhension des performances de la FOAD. Il apparaît encore une fois l importance de l extraction des traces laissées par l apprenant et de leur exploitation de manière à ajuster au mieux le scénario. L application doit également prendre en compte le fait que les dimensions scénario et participants comportent des niveaux de granularités différents dominés par un niveau globale à l image de la formation complète pour le scénario. Le calendrier lui aussi dispose d une certaine granularité à l image du découpage qui peut être fait au niveau du temps : heure, jour, semaine, mois, année. Page 47 sur 63

49 Dimension Niveau micro Niveau méso Niveau macro Scénario Activité Module Formation Participants Individu Groupe de travail : binôme, équipe Contexte : classe, ensemble des apprenants Figure 28 : Granularités des dimensions Scénario et Participants Ainsi, le système doit proposer différents niveaux de visualisation permettant d avoir une vue d ensemble ou, au contraire, de se focaliser plus en détail sur une partie de la formation (activité, individu, heure de cours ). Méthode de développement L idée serait de développer le système en collaboration avec de futurs potentiels utilisateurs de manière à cibler leurs besoins et ainsi fournir une application qui réponde le mieux possible à leurs attentes. Cela permettrait notamment de mieux comprendre et cerner les enjeux du domaine métier de l utilisateur. «Ce i i i é l ili IHM probablement le plus important (Norman, 1988)». On entre alors dans une démarche dite participative où l on souhaite intégrer les utilisateurs au processus de développement du système. Pour commencer, nous nous sommes intéressés aux systèmes déjà existants à l image du logiciel OASIF qui offre une solution assez complète et dont nous allons parler à présent. L existant : OASIF Il existe actuellement le logiciel OASIF (Outil d'aide à la Scénarisation pour l'ingénierie de la Formation) dont le but est de concevoir et d éditer des scénarios de formation. Celui-ci est gratuit et fait partie des outils de l'ingénierie de la FOAD. Il s'adresse aux différents acteurs de la FOAD comme les enseignants, les formateurs et les ingénieurs de formation. Il fut conçu et développé par le département «Innovation Pédagogique» de Télécom Paris suite au constat sur l évolution grandissante des campus numérique et des universités virtuelles. OASIF s'utilise en amont des plates-formes logicielles de la FOAD dont le but est de mettre à la disposition des acteurs (formateurs et apprenants) les ressources qui leurs sont utiles. OASIF s'articule ainsi avec la plateforme Amarante. Les objectifs principaux du logiciel OASIF sont donc de : Permettre la création de scénarios pédagogiques destinés à la FOAD Représenter et décrire visuellement l ensemble des éléments d un scénario de FOAD Faciliter la coopération entre les principaux acteurs de la conception et de la mise en œuvre des formations S articuler avec les plates-formes logicielles de FOAD existantes OASIF offre une représentation globale des scénarios de formation de manière graphique. Il permet ainsi de visualiser sous forme de planning les différents composants d une formation (module, séquence, activités pédagogiques, ) ainsi que leurs descriptions. Il est également possible d y associer des ressources spécifiques. OASIF permet de conceptualiser et de modéliser des formations pour différents groupes d'apprenants (binômes, classes entières, équipes de projet, ). Page 48 sur 63

50 Comme le montre la figure suivante, OASIF se base sur une décomposition en plusieurs couches : Figure 29 : Structure en quatre couches du système OASIF Chaque niveau peut ensuite posséder une description et des propriétés propres. Les formations conçues à l aide du logiciel OASIF peuvent ensuite être exportées sous plusieurs formats de fichiers, notamment XML, HTML et SVG. OASIF est utilisable sous Windows, Linux et Mac OS. Son interface graphique se découpe en 3 blocs principaux : Une arborescence des formations et des principaux éléments qui les composent. Un planning sous forme de calendrier qui permet de visualiser de manière graphique le scénario dans le temps. Un bloc propriétés qui permet de renseigner les propriétés de l'élément en cours de sélection Figure 30 : Capture d'écran du logiciel OASIF Arborescence Planning Propriétés Page 49 sur 63

51 Points d amélioration On peut dégager quelques points faibles du logiciel OASIF : Le produit n est compatible que sur la plateforme Amarante. La prise en main de l outil nécessite au préalable d avoir bien compris le principe de découpage du scénario en quatre couches : formation -> modules -> séquences -> activités. Dans la zone de planning la manipulation des éléments n est pas des plus simples. En effet, on pourrait imaginer par exemple un système de drag and drop pour la création d activités ce qui serait plus simple à utiliser pour l utilisateur. On pourrait éventuellement imaginer un travail plus collaboratif entre les formateurs et indiquer les dernières modifications effectuées sur le scénario. Il n y a pas d informations concernant les activités réalisées par les apprenants (la vision des traces n étant pour le moment pas effectuée). La visualisation des différentes échelles (micro, méso, macro activité, module, formation) n est pas nécessairement très intuitive. Après avoir étudié le système OASIF qui offre une solution plutôt satisfaisante, nous allons à présent voir, de façon synthétique, comment développer notre propre solution grâce au Framework Loa. LOA Framework Généralités Pour implémenter notre éditeur de scénarios nous avons besoin d un outil permettant de mettre au point notre interface graphique et de gérer l interaction de l utilisateur avec celle-ci (GUI Graphical User Interface). Pour cela nous utiliserons le Framework Loa qui va nous permettre à la fois de définir nos éléments graphiques et de gérer les changements opérés au niveau du modèle des données lorsque l utilisateur réalise des actions. Il existe d ores et déjà de nombreux outils comme GWT, WPF et Flex qui permettent d implémenter des composants graphiques pour des applications internet riches. Dans ce type d applications on prête tout particulièrement attention à l aspect de l interface et la vitesse d exécution (RIA Rich Internet Application). Cependant, pour ces outils, la création de nouveaux éléments demande beaucoup d efforts et est donc très couteuse en temps. En effet, il faut définir en soi les composants, implémenter les interactions associées ainsi que les actions effectuées au niveau des données et pour terminer intégrer l ensemble au sein de l application finale. Loa a donc été conçu en vue de faciliter le travail du développeur. Il permet à la fois de spécifier des éléments graphiques riches et variés mais également de gérer leur lien avec le modèle et leur intégration dans l application finale. L objectif reste d offrir à l utilisateur une interface la plus intuitive et ergonomique possible. Un Framework basé sur le langage Scala Le Framework Loa est basé sur le langage Scala. Ce dernier présente l avantage d être orienté objet et parfaitement compatible avec JAVA ce qui permet l utilisation de certaines bibliothèques et interfaces de programmations (API). Il est également extensible et offre la possibilité de construire de nouveaux langages dit dédiés (DSL Domain Specific Language). Les langages dédiés ciblent un domaine d'application précis et sont donc destinés à résoudre un problème spécifique. Dans notre cas, Loa aura donc pour but d aider les développeurs en réglant le problème des interfaces graphiques à travers un langage concis, précis et totalement dédié à cette question. Page 50 sur 63

52 Processus LOA Figure 31 : The development process Le processus de développement utilisé par Loa se décompose en six étapes distinctes : Définition du modèle (langage UML). Réalisation des croquis graphiques/artefacts (possibilité d utiliser des outils comme Illustrator ou Inksape pour réaliser des graphes basés sur le format SVG ou encore le plug-in Google WindowBuilder). Formalisation des modèles graphiques (ajout des paramètres aux artefacts, modèle emprunté à exact). Définition du lien entre les modèles graphiques et le domaine des données (utilisation du principe des opérations dites actives). Spécification des interactions (modèle d interactions inspiré de Malai). Intégration au niveau de l application finale. * à noter que les étapes 1, 2 et 3 peuvent s exécuter parallèlement Les opérations actives représentent une nouvelle manière de lier le modèle de données à la vue en réalisant une connexion que l on pourrait qualifier de permanente et réciproque. On parle alors de lien bidirectionnel. Ainsi, lorsque le modèle change la vue est mise à jour immédiatement et vice versa. En résumé Pour conclure, Loa a été mis au point pour intégrer l ensemble des questions relatives aux systèmes interactifs. L idée est de relier le modèle à la vue (tous deux représentés par des diagrammes de classes) grâce aux opérations actives. Il permet au designer et au développeur de travailler conjointement. Pendant que le premier est d avantage porté sur le rendu visuel de l interface, le second peut réaliser l implémentation et l intégration des différents composants graphiques en vue de l application finale. Pour terminer, on constate que le processus se focalise essentiellement sur l idée de la spécification et non plus de l implémentation à proprement parler: ʺ Specifying GUIs rather than implementing them ʺ Page 51 sur 63

53 Plugin : extraction de traces et interprétation Technologies à utiliser D après le chapitre 3.1, nous devons considérer plusieurs contraintes : Les plateformes que le plugin doit supporter : Microsoft SharePoint et Moodle Le formatage des données pour les vues futures Les objets standards de l éditeur de formation : scenarios, activités, apprenants Pour répondre à ces contraintes, plusieurs technologies vont être utilisées : Microsoft SQL Server et PostgreSQL pour l accès aux données des plateformes SharePoint et Moodle Java / PHP pour l édition d un plugin XML et XML Schema pour l importation et l exportation des données Résultats attendus Les plateformes existantes (Moodle et SharePoint) n offrent pas un rendu satisfaisant, de par l expérience des apprenants. Notamment, l exportation des traces doit permettre au formateur de répondre aux questions suivantes : L apprenant est-il présent et actif? L apprenant est-il en progression ou en difficulté? L apprenant exploite-t-il toutes les ressources mises à sa disposition? Il est à noter que ce projet se limite seulement à l extraction des données et non à leur affichage. Néanmoins, les contraintes liées à ce domaine s appliquent entièrement à nous. Le résultat attendu de notre projet sera un schéma XML compatible avec le schéma XML des objets scénarios (apprenants, activités ) et conforme aux exigences de l affichage, notamment au niveau des relations entre objets et des références. Page 52 sur 63