charles-Édouard bernaille benoît reynaert
TRANSCRIPT
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.
Charles-Édouard BERNAILLE – Benoît REYNAERT
RAPPORT DE PROJET DE FIN D’E TUDE
La Formation Ouverte À Distance
01 / 02 / 2013
ESEO I3 – SI
Page 1 sur 63
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 ....................................................................................... 13
Choix du service web ........................................................................................................... 13
Structure coté serveur.......................................................................................................... 14
Structure du Service ......................................................................................................................... 15
Schéma ............................................................................................................................... 15
Rôle et implémentation des différentes parties .................................................................... 15
Diagrammes de classe ........................................................................................................ 19
Diagramme de séquence d’un cas nominal ......................................................................... 23
Moodle ............................................................................................................................................... 24
Introduction à la plateforme Moodle ..................................................................................... 24
Traduction des objets Moodle/model ................................................................................... 24
Structure des logs ................................................................................................................ 26
Structure de la base de donnée et problèmes de jointures .................................................. 27
Conclusion ........................................................................................................................... 31
SharePoint......................................................................................................................................... 32
Introduction à la plateforme SharePoint ............................................................................... 32
Connexion à la base de données ......................................................................................... 32
Structure des logs ................................................................................................................ 32
Problèmes rencontrés .......................................................................................................... 33
Conclusion ........................................................................................................................... 33
JSP de test ......................................................................................................................................... 34
Exemple de trace ................................................................................................................. 34
Présentation ........................................................................................................................ 34
Conclusion ........................................................................................................................................ 38
Glossaire ............................................................................................................................................ 39
Bibliographie..................................................................................................................................... 40
Page 2 sur 63
Annexes ................................................................................................................................................... 41
Recherche Documentaire ................................................................................................................. 42
Introduction .......................................................................................................................... 42
Présentation de la formation ouverte à distance .................................................................. 43
Pour résumer ....................................................................................................................... 45
Notre Projet ......................................................................................................................... 46
Application à créer : éditeur de scénarios ............................................................................ 47
LOA Framework ................................................................................................................... 50
Plugin : extraction de traces et interprétation ....................................................................... 52
Conclusion ........................................................................................................................... 53
Exemple de requête et de réponse SOAP/XML ............................................................................... 55
EndPoint .............................................................................................................................. 55
Exemple de requête lancée sur le serveur ........................................................................... 55
Exemple de réponse du serveur .......................................................................................... 56
Extraits de requêtes SQL .................................................................................................................. 57
Installation d’un server Debian avec Moodle .................................................................................. 58
Table des matières .............................................................................................................. 58
Installation de la plateforme ................................................................................................. 58
Installation web d'apache // Installation de Moodle, copier le dossier moodle dans /srv/web 62
Warnings \\ dans les logs de PostgreSQL ............................................................................ 62
Automatisation des taches ................................................................................................... 62
Migration / Sauvegarde du campus ...................................................................................... 62
Page 3 sur 63
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 ....................................................................................... 14
Figure 5 : Schéma du service en blocs fonctionnels ....................................................................... 15
Figure 6: fichier de configuration Conf/conf.xml ........................................................................... 17
Figure 7 : Appel du fichier de configuration des logs ..................................................................... 17
Figure 8 : Exemple de log lié à l'appel du service ........................................................................... 17
Figure 9 : Blocs composant le service ............................................................................................. 18
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 ......................................................................................................... 21
Figure 13 : Modélisation du package Controller ............................................................................. 22
Figure 14 : Cas nominal de la recherche des logins d'un apprenant ............................................... 23
Figure 15 : Extrait d'une page depuis le campus ESEO (cours plateforme .Net) ........................... 24
Figure 16 : Extrait de la liste "Tous les cours" du campus ESEO .................................................. 25
Figure 17 : Modèle et object Moodle .............................................................................................. 25
Figure 18 : Table des logs Moodle : mdl_log ................................................................................. 26
Figure 19 : Exemple de logs Moodle .............................................................................................. 26
Figure 20 : Tableau des jointures entre le log et le modèle (Moodle) ............................................ 27
Figure 21 : Informations récupérables dans les traces de Moodle .................................................. 30
Figure 22 : index.jsp - Page d'accueil pour utiliser le service web ................................................. 35
Figure 23 : Affichage des traces correspondantes ........................................................................... 36
Figure 24: Traces de consultation d'un module sur SharePoint ...................................................... 37
Figure 25 : Système de gestion des traces ....................................................................................... 45
Figure 26 : Schéma récapitulatif des trois dimensions clés de la FOAD ........................................ 46
Figure 27 : Fonctionnalités du projet .............................................................................................. 47
Figure 28 : Granularités des dimensions Scénario et Participants .................................................. 48
Figure 29 : Structure en quatre couches du système OASIF........................................................... 49
Figure 30 : Capture d'écran du logiciel OASIF ............................................................................... 49
Figure 31 : The development process ............................................................................................. 51
EXTRACTION DES TRACES GENEREES SUR MOODLE ET SHAREPOINT
Page 5 sur 63
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 6 sur 63
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 7 sur 63
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 8 sur 63
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 9 sur 63
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 X
Consultation d’une formation, d’un module, d’une séquence, d’une activité
X X
Téléchargement d’une ressource pédagogique X X
Dépôt d’un travail et modification X
Utilisation des outils de communication (forum) X
Edition/modification d’un élément du scénario X
Suppression d’un élément du scénario 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 10 sur 63
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 11 sur 63
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 12 sur 63
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 13 sur 63
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 14 sur 63
Structure coté serveur
La structure d’une telle solution coté serveur est la suivante :
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.
Serveur Web
SGBD
Moodle/Sharepoint
Tomcat+Axis Service
Client
Serveur
SOAP/http
Page 15 sur 63
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.
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.
Service
SGBD
Façade
Manager Connecteur
JDBC
Constructeur de requête SQL
Interpréteur de Résultat SQL
Client
SOAP/HTTP
Page 16 sur 63
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 17 sur 63
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>http://localhost/moodle/</foad_address>
Figure 6: fichier de configuration Conf/conf.xml
Apache.log4J.Logger
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 :
2013-01-30 19:22:51,675 : controller.Service.<init>: Appel du service
2013-01-30 19:22:51,847 : controller.Service.getLogins: temps d'execution : 171 ms.
2013-01-30 19:22:52,027 : controller.Service.getLogouts: temps d'execution : 178 ms.
Figure 8 : Exemple de log lié à l'appel du service
Page 18 sur 63
L’ensemble des blocs précédents, traduit en objets Java, peut être représenté comme suit :
Figure 9 : Blocs composant le service
Service
SGBD
Service.java
Manager.java
JDBC
Verte.java
Settings.java
Conf.xml
apache.log4j.Logger
Log4j.properties
errors.log
serviceFileLog.log
Page 19 sur 63
Diagrammes de classe
Figure 10 : Modèle commun à l’éditeur de scénario et au projet d’extraction des traces (partie1)
Page 20 sur 63
Figure 11 : Modèle commun à l’éditeur de scénario et au projet d’extraction des traces (partie2)
Page 21 sur 63
Figure 12 : Modèle des traces
Page 22 sur 63
Figure 13 : Modélisation du package Controller
Page 23 sur 63
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 24 sur 63
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.
2
4
3
3
1
Page 25 sur 63
Revenons maintenant aux catégories de cours, la séquence .NET appartient à la catégorie Option SI de la
sur-catégorie S9
Figure 16 : Extrait de la liste "Tous les cours" du campus ESEO
Nous avons donc ici :
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 APPELLATION MOODLE
Formation Catégorie de cours
Module Sous-Catégorie de cours
Séquence Cours
Activité Section de cours
OutilCommunication Forum ou Chat ou Wiki
RessourcePedagogique Ressource (lien vers un fichier ou un site web)
Production Dépôt (ou assignment)
Acteur 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)
2 1
Page 26 sur 63
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 :
Figure 18 : Table des logs Moodle : mdl_log
Voici quelques exemples de logs :
Figure 19 : Exemple de logs Moodle
Un log, sous Moodle, est composé des parties suivantes :
id : l’identifiant du log, son numéro
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 27 sur 63
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 28 sur 63
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.email as EMAIL, 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 29 sur 63
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, Email: 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()=http://localhost/moodle/mod/forum/discuss.php?d=4]
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 30 sur 63
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 Sujet
mdl_forum_posts Message, Pièce Jointe
RessourcePedagogique mdl_resource Type, Lien, Nom, Description
Production mdl_assignment Titre Depot, Description Depot
Acteur mdl_user Id, Nom, Prenom, Email, (+Telephone, Adresse, Ville, Pays si indiqué par l’utilisateur)
Figure 21 : Informations récupérables dans les traces de Moodle
Page 31 sur 63
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 email, 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 32 sur 63
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 33 sur 63
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 34 sur 63
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, Email: 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()=http://localhost/moodle/view.php?id=0&course=1]
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 2012 – 11h45
Lien :
http://localhost/moodle/view.php?id=0&course=1 – 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 35 sur 63
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 36 sur 63
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 2012.
Figure 23 : Affichage des traces correspondantes
Page 37 sur 63
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 2012. Toutes les traces ne sont pas visibles sur la capture d’écran.
Figure 24: Traces de consultation d'un module sur SharePoint
Page 38 sur 63
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 39 sur 63
Glossaire
API Application Programming Interface
DSL Domain Specific Language
FOAD Formation ouverte à distance
GUI Graphical User Interface
GWT Google Web Toolkit
JDBC Java DataBase Connector
OASIF Outil d'Aide à la Scénarisation pour l'Ingénierie de la Formation
RIA Rich Internet Application
SVG Scalable Vector Graphics
UML Unified Modeling Language
WPF Windows Presentation Foundation
XML eXtensible Markup Language
Page 40 sur 63
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 41 sur 63
ANNEXES
Page 42 sur 63
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 43 sur 63
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 44 sur 63
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 45 sur 63
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.
SYSTEME DE
GESTION DES TRACES
Système de visualisation
Système
d’interrogation
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 46 sur 63
Trois dimensions : Participants, Calendrier et Scénario
Figure 26 : Schéma récapitulatif des trois dimensions clés de la FOAD
Notre Projet
Schéma général
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.
Trajectoire à construire
Objectifs de formation
Modules acquis
Passé Délai de formation Présent
Activités en cours
Début de formation
Trajet effectué
SCÉNARIO
CALENDRIER
Page 47 sur 63
Figure 27 : Fonctionnalités du projet
Application à créer : éditeur de scénarios
L’objectif
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 48 sur 63
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 49 sur 63
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 50 sur 63
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 51 sur 63
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 52 sur 63
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 53 sur 63
Les principaux modules et fonctionnalités du plugin livré devront permettre d’extraire les données des
serveurs, les trier et les organiser suivant des règles de granularité, les formater et les exporter suivant un schéma
de donnée (Figure #). Suivant les dispositions, il est fortement possible qu’il faille développer plusieurs fonctions
de connexion (connecteur et extracteur) relatives au format d’accès et au format de données des serveurs.
Figure 8 : Extraction des traces – fonctionnalités
Utilité du projet
L’analyse de l’existant montre qu’une solution entière et compatible Moodle / MS SharePoint n’existe
pas. Le projet OASIF propose cependant des concepts très développés en termes d’édition de scénarios, bien que
le logiciel ne soit plus maintenu.
Pour le client, L’Université du Maine, l’objectif est double : s’approprier un outil complet assistant à la
FOAD et développer une solution et des concepts d’école pouvant être améliorés par la suite. En conséquence,
cet outil donnera accès à une meilleure maîtrise du domaine de l’apprentissage à distance.
Le but, concilier l’édition et l’exportation des scénarios premièrement, puis, apporter un sens aux traces
par une mise en contexte, permettra de manière finale l’étude et l’amélioration des stratégies d’apprentissage
par les différents acteurs : enseignants, ingénieurs pédagogiques, technologues.
Conclusion
En fort développement, les exigences pour la FOAD sont de plus en plus fortes. Différents acteurs entrent
en jeux. Un outil pour la gestion de l’information conciliant les dimensions Apprenants – Scenario – Calendrier
pourrait permettre, à terme, de mettre à l’étude une véritable stratégie pour la FOAD.
Le projet, séparé en 4 ensembles fonctionnels, devra permettre l’Edition de scénarios (1), l’exportation
des scénarios vers des objets de formation Moodle ou MS SharePoint (2), l’extraction des traces laissées par
l’étudiant (3) et permettra la visualisation des traces dans leur contexte (4). Les tâches de développement
déléguées à notre groupe ESEO (1) et (3) sont l’occasion de nous former à un nouveau domaine métier : la FOAD
et d’en rencontrer ses acteurs. Ce sujet permettra aussi une appropriation des technologies XML, SVG, Java, SGBD
PostgreSQL et Microsoft qui seront utilisées pour mener à bien le développement.
L’étude et l’utilisation des concepts de LOA, langage de programmation orienté opérations actives, de
concert avec l’utilisation des technologies XML, notamment SVG, permettra l’approche d’une nouvelle vision de
l’interface utilisateur, plus intuitive, plus réactive.
Les fonctionnalités développées par nos deux groupes ESEO, (1) et (3), ne suffirons pas à fournir une
solution complète pour les besoins exprimés. L’ensemble du développement doit se faire de pair avec les groupes
responsables des fonctions (2) et (4) ou, du moins, en prévision de leur développement. Ce travail à distance
demandera une qualité de conception et de développement forte ainsi que des compétences en communication.
Requêtes
Extracteur Tri
Formatage XML
Co
nn
ect
eu
r
traces.xml
traces.xsd S
Schema
.xsd
Page 54 sur 63
Ce projet nous ouvre enfin sur la manipulation des traces utilisateur de manière générale. Qu’extraire ?
Comment formater et présenter l’activité des utilisateurs d’un système ?
Le domaine métier de la FOAD est un domaine porteur. Il permet une flexibilité de la formation, un
rythme adapté à l’étudiant. Il touche autant les étudiants sur des domaines scolaires que des professionnels dans
le cadre d’une formation continue. En conséquence, la distance entre l’apprenant et le formateur augmente.
Cependant, un rapprochement est possible grâce aux technologies de l’information (IT). Malgré un niveau
technologique croissant des outils développés, des interfaces utilisateur avancées permettent aux personnes
extérieures au domaine IT de manipuler les objets et les fonctionnalités que nous concevons.
Page 55 sur 63
Exemple de requête et de réponse SOAP/XML
EndPoint
Adresse du serveur où la requête est envoyée : « http://193.49.148.12:8080/traces1/services/Service »
Hôte du service : localhost
(peut également être une adresse IP de type 192.168.xxx.xxx, ou une URL de type
http://campus.eseo.fr/)
Port : 8080
Emplacement du service sur l’hôte : traces1/services/
Nom du service web : Service
Exemple de requête lancée sur le serveur
<soapenv:Envelope
xmlns:q0="http://controller"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<soapenv:Body>
<q0:getTraces/>
</soapenv:Body>
</soapenv:Envelope>
Protocole de communication : SOAP
Envelope : spécifique à SOAP pour communiquer entre le serveur et le client
Format du fichier : XML
Package dans lequel se situe le service web appelé : controller
Dans le corps de l’enveloppe, méthode appelée : getTraces (), sans paramètre
o C’est une méthode de test qui renvoie des traces fictives (2)
o Les attributs date et lien sont renseignés manuellement
Page 56 sur 63
Exemple de réponse du serveur
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getTracesResponse xmlns="http://controller">
<getTracesReturn>
<acteur xsi:nil="true" />
<date>1990-09-10T06:08:08.385Z</date>
<formation xsi:nil="true" />
<lien>http://www.eseo.fr </lien>
</getTracesReturn>
<getTracesReturn>
<acteur xsi:nil="true" />
<date>1992-09-17T15:00:00.386Z</date>
<formation xsi:nil="true" />
<lien> http://www.google.fr </lien>
</getTracesReturn>
</getTracesResponse>
</soapenv:Body>
</soapenv:Envelope>
Méthode appelée : getTraces (), sans paramètre
Réponse : getTracesReturn, qui renvoie un tableau de Traces (Traces []) – composé de 2 traces
o Acteur : null
o Date : retourne la date de la trace
o Formation : null
o Lien : renvoie le lien correspondant à la trace (ici, eseo.fr et google.fr)
Page 57 sur 63
Extraits de requêtes SQL
Voici quelques exemples de requêtes générées par le service web et envoyées au serveur.
Login
[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.email as EMAIL, u.phone1 as TELEPHONE, u.address as
ADRESSE, u.city as VILLE, u.country as PAYS from mdl_log l, mdl_user u where l.userid = u.id and l.action like
'login' ;]
Logout
[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.email as EMAIL, u.phone1 as TELEPHONE, u.address as
ADRESSE, u.city as VILLE, u.country as PAYS from mdl_log l, mdl_user u where l.userid = u.id and l.action like
'logout' ;]
ConsultationModule
[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.email as EMAIL, 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 from mdl_log l, mdl_user u, mdl_course_categories
module, mdl_course_categories formation, mdl_course sequence where l.userid = u.id and l.course =
sequence.id and module.id = sequence.category and module.parent=formation.id and (l.action like 'view
forum' or l.action like 'view discussion' or l.action like 'view');]
ConsultationSequence
[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.email as EMAIL, 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 from mdl_log l, mdl_user u, mdl_course_categories
module, mdl_course_categories formation, mdl_course sequence where l.userid = u.id and l.course =
sequence.id and module.id = sequence.category and module.parent=formation.id and (l.action like 'view
forum' or l.action like 'view discussion' or l.action like 'view');]
ConsultationActivite
[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.email as EMAIL, 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, activite.id as ID_ACTIVITE, activite.summary as
TITRE_ACTIVITE from mdl_log l, mdl_user u, mdl_course_categories module, mdl_course_categories
formation, mdl_course sequence, mdl_course_sections activite where l.userid = u.id and l.course =
sequence.id and module.id = sequence.category and module.parent=formation.id and activite.course =
sequence.id and l.cmid=0 and (l.action like 'view forum' or l.action like 'view discussion' or l.action like 'view');]
Page 58 sur 63
Installation d’un server Debian avec Moodle
Procédure écrite par Monsieur Jérôme CHAVIN, enseignant – chercheur à l’ESEO Angers.
Table des matières
Installation de la plateforme
o Installation de la partie LAMP
o Création des répertoires
o Base de données PostgeSQL
o Paramètres pour PHP
Installation web d'apache
Warnings \\ dans les logs de PostgreSQL
Automatisation des taches
o Gestion de cron
Migration / Sauvegarde du campus
o Sauvegardes des données
Les données correspondent à la configuration présente sur Moodle-II.
Installation de la plateforme
Installation de la partie LAMP
Les paquets
libgd est optionnel pour Moodle
apt-get install \
apache2 apache2-mpm-prefork \
php5 php5-cli libapache2-mod-php5 \
postgresql php5-pgsql \
php5-gd php5-curl \
tetex-extra imagemagick \
mimetex ucf \
php-pear dbishell libgd-tools tinyca \
php5-xmlrpc php5-intl php5-ldap \
libatk1.0-data libglib2.0-data hicolor-icon-theme libgtk2.0-bin x-ttcidfont-conf xml-core zip unzip \
libdbd-mysql-perl libdbd-odbc-perl libdbd-pg-perl libgd2-xpm-dev libgtk2-perl-doc librsvg2-common \
libjasper-runtime liblcms-utils html2ps libwmf-bin libcompress-zlib-perl librsvg2-bin ca-certificates php5-
dev oidentd \
debhelper gs-gpl gs-esp gs-afpl gv cm-super \
ghostscript dvipdfmx lmodern perl-tk texpower tipa \
texlive-humanities texlive-generic-extra prosper latex-beamer latex-xcolor \
pgf shared-mime-info xsltproc curl wget psfontmgr libhtml-format-perl libmailtools-perl libmail-sendmail-
perl libmail-box-perl
Page 59 sur 63
Note Squeeze - Test
Attention dbishell n'existe plus.
Note : sélection de « ghostscript-x » au lieu de « gs-afpl »
Note : sélection de « texlive-base » au lieu de « dvipdfmx »
Aucune version du paquet tetex-extra n'est disponible, mais il existe dans la base
de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète
ou qu'il n'est disponible que sur une autre source
Retrait de dbishell et de tetex-extra
Creation du site virtuel moodle
Modifiez le fichier /etc/apache2/sites-available/default contenant :
NameVirtualHost *:80
ServerTokens Major
<VirtualHost *>
ServerAdmin [email protected]
DocumentRoot /srv/web/
AcceptPathInfo On
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /srv/web/>
DirectoryIndex index.php index.html index.htm
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from 192.168.10.0/24
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature Off
</VirtualHost>
Page 60 sur 63
Pour la partie HTTPS pour l'authentification créez le fichier /etc/apache2/sites-available/default-ssl contenant :
NameVirtualHost *:443
ServerTokens Major
<VirtualHost *:443>
AcceptPathInfo On
SSLEngine On
SSLCertificateFile /etc/apache2/server.pem
SSLCertificateKeyFile /etc/apache2/server.pem
ServerAdmin [email protected]
DocumentRoot /srv/web/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /srv/web/>
DirectoryIndex index.php index.html index.htm
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from 192.168.
</Directory>
# Partage pour la recup des sauvegardes sur srv-fourier
Alias /Sauvegarde/ /srv/Sav/
<Directory /srv/Sav/>
Options None
AllowOverride None
Order allow,deny
Allow from 192.168.4.3
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature Off
</VirtualHost>
Page 61 sur 63
Création du certificat auto-signé
# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/server.pem
activation du virtualhost ssl
# a2ensite default-ssl
relancez le serveur apache avec la commande
/etc/init.d/apache2 reload
Création des répertoires
pour le site web
mkdir -p /srv/web
chown www-data:www-data /srv/web
chmod -R g+w /srv/web
pour les fichiers
mkdir -p /srv/data
chown www-data:www-data /srv/data
chmod -R g+w /srv/data
Base de données PostgeSQL
Installation de la base de données PostgreSQL en version 8.4 (squeeze)
aptitude install postgresql php5-pgsql
Editez le fichier '/etc/postgresql/8.4/main/pg_hba.conf' et changez à la ligne 82 le terme ident en md5. Et
relancez la base de données. /etc/init.d/postgresql restart
Déplacement des datadirs dans /srv/postgresql
arrêt de la base : /etc/init.d/postgresql stop
déplacement des fichiers mv /var/lib/postgresql /srv
modifier (ligne 42) data_directory = '/srv/postgresql/8.4/main' dans le fichier
/etc/postgresql/8.4/main/postgresql.conf
relancer la base : /etc/init.d/postgresql start
Création de la base et de l'utilisateur moodle
su postgres
createuser -D -A -P moodle
createdb -E utf8 -O moodle moodle
psql template1
=# ALTER USER moodle WITH PASSWORD 'moodle';
=# \q
exit
Paramètres pour php
Editez le fichier /etc/php5/apache2/php.ini et vérifiez les valeurs suivantes
post_max_size = 16M
upload_max_filesize = 8M
register_globals = Off
A la fin pour être sur que tous les services ont bien pris en compte les modifications exécutez la commande
/etc/init.d/apache2 restart
Page 62 sur 63
Installation web d'apache // Installation de Moodle, copier le dossier moodle dans
/srv/web
Choisissez une langue ⇒ Français (fr)
Confirmer les chemins d'accès : Dossier de données ⇒ /srv/data
La langue fr n'a pas pu être téléchargée ⇒ on téléchargera ultérieurement le pack et on l’installera plsu tard.
Sélectionner un pilote de base de données ⇒ postgresql (natif, pgsql)
Réglages de la base de données ⇒ localhost, db moodle, user moodle, password network, prefix mdl_,
socket unix oui.
Copyright ⇒ continuer
Contrôles serveur ⇒ si tout est ok alors continuer sinon rajouter les modules manquants.
Création des tables dans la base de données ⇒ attendre succès partout puis continuer.
Création du compte administrateur
Réglages page d'accueil
Moodle est opérationnel
Warnings \\ dans les logs de PostgreSQL
http://tracker.moodle.org/browse/MDL-22189
If you take a look to the configure_dbconnection() function (lib/dmllib.php), you' ll see that, for mssql and oracle,
both using the single quote as escape char, we are doing this:
/// Enable sybase quotes, so addslashes and stripslashes will use "'"
ini_set('magic_quotes_sybase', '1');
/// NOTE: Not 100% useful because GPC has been addslashed with the setting off
/// so IT'S MANDATORY TO CHANGE THIS UNDER php.ini or .htaccess for this DB
/// or to turn off magic_quotes to allow Moodle to do it properly
So, perhaps, if you want to try it... you could add that code in the 'postgres7' section, and also set magic_quotes =
off and play with it. If we get positive reports from some POSTGRES servers running it ok and without problems...
we could add it upstream.
Automatisation des taches
Gestion de cron
Ajouter dans cron (crontab -e) la ligne suivante issue de la doc.
• /10 * * * * wget -q -O /dev/null http://localhost/admin/cron.php
Migration / Sauvegarde du campus
Sauvegardes des données
Les fichiers
Les fichiers à sauvegarder sont présents dans le répertoire /srv/data. Un simple tar.gz suffit à sauvegarder
l'ensemble. Attention l'archive générée fait plusieurs Giga. Attention il faut que le processus Apache puisse
accéder en lecture / écriture, donc le propriétaire des fichiers doit être www-data.
La base de données
L'utilisateur postgres est l'administrateur de la base de données, il doit donc exécuter les commandes. ( non pas
root) La commande pour extraire complètement la base de données moodle est :
su postgres -c "/usr/bin/pg_dump -o -f /srv/Sav/Base_moodle.sql moodle"
Page 63 sur 63
Le moteur moodle
Dans cette partie il faut juste conserver le fichier /srv/web/config.php qui contient l'ensemble des
informations de connexions de moodle.
Pour la restauration il suffit d'importer la nouvelle base après avoir supprimer l'ancienne.
su postgres -c "psql < /srv/Sav/Base_moodle.sql"