Spécifications et architecture d’un environnement Websupportant des activités coopératives d’apprentissage

Thierry Nodenot (1), Christophe Marquesuzaa (1), Pierre Laforcade (2), Marie-Noëlle Bessagnet (2),Christian Sallaberry (2)

Laboratoire d’Informatique de l’UPPA (LIUPPA)(1)IUT de Bayonne Pays Basque (2)FDEG et IAEChâteau-Neuf, Place Paul-Bert Avenue du Doyen Poplawski64100 Bayonne – France 64000 Pau – France

contact : Thierry.Nodenot@iutbayonne.univ-pau.fr - http://liuppa.univ-pau.fr

RésuméNous présentons dans cet article nos travaux sur laspécification d’environnements permettant à un pédagoguede mettre en œuvre des situations coopérativesd’apprentissage. Après avoir décrit les enjeux, les acteurs etles principes de mise en œuvre d’activités coopérativesd’apprentissage, nous focalisons notre attention sur ladéfinition d’un système (appelé Learning ManagementSystem) capable de gérer ce type d’activités pour unecommunauté d’utilisateurs (apprenants et moniteurs). Nousmontrons ainsi qu’une pédagogie à base d’activitéscoopératives est envisageable sur la base des travaux denormalisation menés par les consortiums internationauxcentrés sur l’E-Learning.

AbstractIn this paper, we present our works dedicated to thespecification of environments enabling a community ofusers to do some cooperative learning activities. We firstdescribe the goals, key players and principles of suchcooperative and learning activities. Then, we focus theproblem of defining the characteristics of a system (called aLearning Management System) that could manage suchcooperative learning activities. By the way, we argue that aconstructivist way of learning is reachable on the basis ofnormalisation works that are led by the internationalconsortiums centred on e-learning.

IntroductionL’ingénierie éducative a évolué ces dernières années danssa dimension technologique. Nous en voulons pour preuveles travaux de recherche actuels pour la formation ouverteà distance. Ceux-ci sont centrés sur l’établissement destandards pour les méta données et les objetsd’apprentissage. Des organismes comme [LTSC, 2001],[LOM, 2000], [PROMETEUS, 2001] ou [IMS, 2001], dessociétés commerciales comme Asymetrix, Oracle ouencore Microsoft, visent une meilleure interopérabilitéentre applications éducatives et une meilleure réutilisationd’applications et services « électroniques ».

D’autres recherches s’intéressent davantage à laspécification pédagogique (aspect modélisation) commepoint central d’un environnement d’apprentissage.L’objectif est de proposer des langages de haut niveaupermettant de guider les pédagogues concepteurs dans laspécification d’un tel environnement. De nombreuxtravaux s’accordent pour considérer qu’un environnementd’apprentissage est avant tout un Système d’Informations[Rodriguez-Artacho & all, 1999], [Koper, 2001],[Nodenot, 2001]. Il s’agit donc d’étudier un telenvironnement dans sa complexité en prenant en compteses spécifications (pédagogiques et fonctionnelles) maisaussi sa dynamique, sa mise en œuvre et son exploitation.

Dans cet article, nous allons étudier ces deux dimensions,technologique et pédagogique, sur un cas particulier : ledéveloppement d’applications éducatives à base d’activitéscoopératives entre apprenants. Nous décrirons dans unpremier temps ce que nous entendons par activitécoopérative d’apprentissage en centrant notre propos surles fonctions que doit proposer un environnement supportpour ce type d’activités (dimension pédagogique). Dansune seconde partie, nous décrirons comment un telenvironnement peut être implémenté en respectantnotamment les principes proposés par les principauxorganismes de normalisation en matière d’E-Learning(dimension technologique).

1. Spécifications fonctionnelles d’unenvironnement support pour des activités

coopératives d’apprentissagePréparer, enseigner, évaluer sont les trois étapesprimordiales dans la mise en œuvre d’une situationpédagogique. Ce processus doit prendre en compte diversparamètres comme les conditions d’enseignement, lesobjectifs pédagogiques, la rétroaction nécessaire,

l’adaptation à une modification de la situationpédagogique, etc. Quand la situation pédagogique est« médiatisée » via un réseau d’ordinateurs, l’enseignantdoit garder un rôle prépondérant d’animation, de guidage,et ce, même si les conditions d’exploitation changent :- Les apprenants ne sont pas forcément physiquement

dans le même lieu,- L’activité des apprenants est perçue au travers d’une

médiatisation par l’outil informatique,- L’activité de l’enseignant dans ses rôles de suivi, de

maîtrise, de contrôle et d’orientation des activités desapprenants est également médiatisée par l’outilinformatique.

Par contraste avec l’apprentissage traditionnel, basé sur lanotion de cours, de lectures et d’exercices, l’apprentissagecollectif (qu’il soit coopératif ou collaboratif) [George,2001] impose que les apprenants participent activement àla production, à l’accès et l’organisation de l’information.L’instructeur structure soigneusement les activités desapprenants, met l’accent sur un contenu particulier etcontrôle le travail de l’étudiant. La construction deconnaissances est donc perçue comme un processus derésolution progressive de problèmes, qui encourage desétudiants à être novateurs, à créer des aptitudesintellectuelles et à développer et acquérir de l’expertise.Ceci est démontré par [Harasim, 1999] qui dresse un biland’exploitation d’un tel système : Virtual-U [Sawyer, 2000].

Dans nos travaux, le point de départ d’une activitécoopérative est la situation-problème (PBLS) [Develay,1993], [Meirieu, 1994]. [Suthers, August 2001] note :”Collaborative learning based on the notion of PBLS is aninteresting approach and quite different from more classicsequences: courses, exercises, evaluation”. Cet objetpédagogique inclut tous les éléments nécessaires pour que

le groupe classe (et ses sous-groupes constitutifs) se metteen situation de projet avec :- Un objectif global, des critères de réussite fonctionnel et

formel,- Des matériels et autres outils facilitant la résolution de la

situation problème,- Un guide décrivant certaines modalités et autre

répartition des tâches entre acteurs (et groupesd’acteurs).

[Marquesuzaà, 1998] a décrit cet objet d’apprentissageparticulier qu’est la situation-problème et proposé unenvironnement d’outils permettant à un enseignant de créeret manipuler un tel objet. [Wiley, 2000] résume de façonconsensuelle ce qu’est un objet d’apprentissage (dans lalittérature, certains auteurs emploient le terme d’objetpédagogique [De La Passardière & Giroire, 2001] ouencore « learning object ») : « [il] représente touteressource numérique (quelle que soit sa taille et son type)pouvant être réutilisée comme support d’apprentissage (àtravers le réseau ou non) ».

Partant de ces travaux, nous proposons un environnementau sein duquel l’enseignant a la possibilité de définir unprojet global éducatif à base de situations-problèmes :- Plusieurs groupes d’apprenants disposant de rôles

distincts doivent coopérer pour résoudre une situationproblème et atteindre les objectifs pédagogiques attachésà cette situation.

- Le système intègre un autre type d’acteur : un moniteurqui est chargé de suivre et d’assister les apprenants dansleur résolution de problème. Ce moniteur peut êtrehumain (personne physique) ou automatique. Il disposedonc de ressources et de services idoines et peutinteragir avec le système :

Figure 1 : La coopération des acteurs du système

Chacun des groupes d’acteurs présenté mène, au servicede la collectivité, un certain nombre d’activités au sens de[Bourguin, 2000]. Ces activités dont les caractéristiquessont définies en phase de conception pédagogique sont

enchaînées par les acteurs de manière synchrone ouasynchrone [Laforcade, 2002]:

Groupe G1

Groupe G2

Groupe Gn

MoniteurAutomatique (MA)

MoniteurHumain (MH)

...

1

2

3

1 Conception

2 Réalisation

3 Exécution

Figure 2 : La synchronisation des activités menées parles acteurs du système

Ces activités se caractérisent par un certain nombred’invariants :- Toute activité met à disposition des acteurs qui la

mènent un ensemble de ressources en lecture et définitun ensemble de ressources à produire,

- Toute activité met à disposition des acteurs qui lamènent un certain nombre de fonctionnalités d’outils.Ces fonctionnalités ne sont disponibles qu’en fonctiondu contexte de la tâche menée par l’acteur considéré.Pour des activités coopératives d’apprentissage, ondistingue trois types d’outils :

1. Des outils de production qui sont utiles auxactivités individuelles (pour la production desressources requises par l’activité).

2. Des outils de coordination qui offrent un point devue dynamique sur les activités menées par les unset les autres et sur la façon dont elles sontsynchronisées.

3. Des outils de communication qui permettentl’échange d’information entre apprenants ou entreapprenants et moniteurs.

Figure 3 : Les trois espaces des outils d’unenvironnement collectif [George, 2001]

Dans la seconde partie de cet article, nous allons focalisernotre étude sur le problème de la mise en œuvre d’unenvironnement-support capable de gérer des activitéscoopératives d’apprentissage compatibles avec lesobjectifs énoncés ci-dessus. Un exemple d’utilisationillustrera nos propos.

2. Spécifications techniques d’unearchitecture support pour les activités

coopératives d’apprentissage.

2.1. Existant en matière de normes etarchitectures-support

L’industrie du logiciel a investi depuis maintenantplusieurs années le domaine de l’E-Learning. Lesprincipaux acteurs militent pour la définition de standardsqui facilitent la compatibilité des développementsd’applications éducatives. Disons clairement qu’iln’existe pas de standards définissant comment lesdéveloppeurs doivent bâtir des cours en ligne de tellemanière que des cours mis en œuvre par différentescompagnies puissent interagir. Il y a en revanche desgroupes de travail définissant des spécifications, desprotocoles qui sont proposés à l’industrie du logicieléducatif : citons parmi les groupes non européens lestravaux complémentaires ou concurrents menés par theIEEE’s Learning Technology Standards Committee(IEEE LSTC) [LTSC, 2001], the IMS Global LearningConsortium [IMS, 2001], the Aviation Industry CBTCommittee (AICC) [AICC, 2000], the AdvancedDistributed Learning with its Sharable Content ObjectReference Model (ADL-SCORM) [SCORM, 2000]. EnEurope, les consortiums ARIADNE [ARIADNE, 2001] etPROMETEUS [PROMETEUS, 2001] sont les principauxacteurs.Un certain nombre d’invariants ressortent de tous cestravaux :- La prédominance des architectures client-serveur dans

la mesure où le déploiement des contenus éducatifs sefait via le Web. Afin de dépasser les limites du langageHTML (trop tourné vers la présentation de contenus),les travaux se sont tournés vers le langage XMLcomme support de transfert des contenus entre leserveur Web et les clients (postes de travail desapprenants),

- La recherche d’une meilleure réutilisabilité descontenus éducatifs. L’idée générale est d’extraire descontenus éducatifs (Learning Contents) deux typesd’éléments :

1. Les éléments de présentation de ces contenus auxapprenants (aspects liés à l’interface usager),

2. Les éléments de navigation qui définissentl’orientation proposée aux apprenants d’uncontenu éducatif à un autre. Cette orientationdépend en général du comportement constaté del’apprenant au niveau de l’un ou d’une liste decontenus éducatifs dans lesquels il a navigué.

Pour répondre à ces préoccupations, différents types desystèmes sont proposés [Chapman & Hall, 2001]:- Les Learning Management Systems (ou LMS) assurent

ABC

MActivités de tutorat, suivi, temps

le déploiement des contenus éducatifs aux apprenants.Ils gèrent l’accès des usagers aux différents modules deformation, permettent aux pédagogues de suivrel’avancement des apprenants dans les modules (tempsécoulé, historique des réponses, …) et de gérerl’orientation de ces apprenants d’un module à un autre.De exemples de LMS sont WebCT, Ingenium, WBTManager, …

- Les Learning Content Management Systems (ouLCMS) permettent à des experts d’un domaine, à desdéveloppeurs, de coopérer (via le Web) pour créer descontenus éducatifs (ou Learning Contents) aussiréutilisables que possible. ASPEN est un exempled’environnement entrant dans cette catégorie[Rengarajan, 2001].

Figure 4 : Le rôle du LMS et du LCMS dans la diffusionde contenus éducatifs pour le Web

[Chapman & Hall, 2001] note qu’à ce jour, des travauximportants sont engagés et doivent être poursuivis afind’améliorer les capacités de navigation entre contenuséducatifs offerts par ces systèmes : ces capacités sebornent à des orientations basiques d’un contenu à unautre, ce qui limite l’adaptabilité des modules deformation offerts aux comportements réels desapprenants.

Nous rajouterons que ces LMS nous semblent plus penséspour transmettre des savoirs sous forme de pages etexercices proposés aux apprenants que pour mettre enœuvre des activités d’apprentissage (plus basées sur dessavoir-faire) qu’elles soient individuelles ou coopératives.Ces constatations nous conduisent à proposer, sur la basedes travaux menés par les grands consortiums dudomaine, un certain nombre d’adaptations que nousdécrivons dans le prochain paragraphe.

2.2. Eléments d’une solution technique pour lesactivités coopératives d’apprentissage

Notre objectif est ici de décrire le fonctionnement générald’un Learning Management System (LMS) capable deprendre en compte des activités coopératives telles quecelles décrites dans la partie 1. Le rôle de ce LMS estdonc de permettre le suivi des apprenants, tant dans leurprogression et leurs performances dans les activitéscoopératives proposées que dans le niveau de tutorat quileur est apporté.

Le point de départ de notre analyse est le suivant.L’architecture client-serveur qui est la base du Web et surlaquelle s’appuient tous les développements en FormationOuverte et A Distance (FOAD) actuels (notamment tousceux des consortiums cités dans le paragraphe précédent :- ne peut être remise en cause sous peine que nos travaux

se coupent de toutes les retombées positives en matièrede normalisation qui découlent de l’activité de cesconsortiums,

- pose cependant de nombreuses difficultés dans lamesure où elle place toute l’intelligence du système auniveau du serveur (machine sur laquelle se situe leLMS). La notion d’activité perd selon nous une partiede son sens dans ce type d’architecture puisquel’apprenant interagit avec des pages qui lui sontenvoyées les unes après les autres par le LMS. Lanotion d’activité n’a donc pas d’existence sur le postede l’apprenant, chaque action de l’apprenant devantêtre envoyée au LMS pour interprétation et rétroactionsous forme d’une nouvelle page Web (cf figure 5.1).

Figure 5.1 : Une activité d’Apprentissage conforme avecles modèles classiques de diffusion par le Web

Learning ContentManagement System

(LCMS)

Internet Internet

Déploiement

Design stage Regulation stage

DéveloppeursExperts du domaine Apprenants

Administrateurs etpédagogues

Learning Objects database

LO

Learning ContentManagement System

(LCMS)

extraction etintégrationLO

LO

Learning Management System (LMS)

Web page W

eb p

age

Action

Act

ion

Internet

Apprenants

Activitéd'apprentissage

LO

LO

LO

Administrateurset pédagogues

Notre proposition (cf figure 5.2 ci dessous) ne se contentepas de changer la granularité des ressources transmisesaux apprenants (Page Web / Activité d’Apprentissage).

Figure 5.2 : Notre proposition pour l’exploitation via leWeb d’Activités d’Apprentissage

Une page Web est une entité de présentationd’informations qui fournit des capacités d’intéractionlimitées ; une activité d’apprentissage intègre des

éléments de présentation et d’intéraction mais aussi desoutils permettant à l’apprenant d’agir pour résoudre leproblème posé par l’activité (notion de micro-mondequ’on retrouve dans la figure 3 : outils de production, decommunication, de coordination).

Notre proposition propose aussi une distribution de laconnaissance sur l’activité menée par les apprenants entrele serveur et le client. Cette distribution est basée sur leséléments suivants : - Le poste serveur héberge un modèle de données lui

permettant de disposer, en temps réel de toute laconnaissance sur l’activité concrète menée par chaqueapprenant (que nous appellerons « Domaine del’activité ») ainsi que sur l’activité coopérative globale(que nous appellerons « Organisation de l’activité »).Les détails des informations relevant du domaine del’activité et de l’organisation de l’activité seront donnésdans le paragraphe 2.3),

- Chaque poste client récupère du serveur toutel’information décrivant :

1. L’activité à mener par l’apprenant présent sur ceposte client : cette information correspond à unsous-ensemble des informations du domaine et del’organisation de l’activité.

2. Mais aussi les interfaces-usagers (écrans, outils etfonctionnalités) mises à sa disposition.

Figure 6 : Le détail des ressources côté serveur (LMS) et côté client

Learning Management System (LMS)

Activité Pa

ge W

eb

Trace de l'activité

Actio

nInternet

Apprenants

Modèle del'activité

LO

LO

LO

Administrateurset pédagogues

Activitéd'apprentissage

Activité d'Apprentissage

Interfaceusager1

Learning Management System (LMS)

Représentation de l'activité

LODomaine del'activité

Organisationde l'activité

LO

LO

Apprenant Apprenant Tuteur

Représentation1de l'activité

Activité d'Apprentissage

Interfaceusager2

Représentation2de l'activité

Activité de monitorat

Interfaceusager3

Représentation3de l'activité

Internet

Côt

é-Clie

ntCôt

é-Se

rveu

r

Activitéd'apprentissage

Trace del'activité

Trace del'activité

Activitéd'apprentissage

Traces de l'activité,demandes d'aide, ...

Monitoringl'activité

Chaque apprenant, au travers de ses interactions, met àjour certaines valeurs du domaine de l’activité ainsi quecelles relatives à l’organisation de l’activité (ce quipermettra, non seulement de synchroniser les actions d’unapprenant avec les activités d’autres apprenants maisaussi de synchroniser les actions de tutorat avec lesactivités d’apprentissage menées).

L’enjeu est donc de mettre en œuvre un LMS capable desupporter des modalités de fonctionnement compatiblesavec le schéma précédent. L’analyse du fonctionnementd’un tel système nous oriente vers un pattern de type

Modèle-Vue-Présenteur (MVP) comme support de miseen œuvre. Ce modèle permet en effet d’établir un pontd’informations (bi-directionnel) entre un serveur et desclients Web. Le principe du pattern MVP vient du projetIBM-Taligent [Potel, 1996]. Il s’agit d’une extension dupattern Model-View-Controler (MVC) qui a fait lapopularité de Smalltalk et qui est largement utilisé pourtous les développements d’Interfaces-Usagers(notamment Java-Swing mais aussi des projets duconsortium Apache tels que STRUTS cfhttp://jakarta.apache.org/struts/) :

Figure 7 : Le pattern Model-View-Presenter dans un contexte réparti

Côté serveur, ce pattern permet de définir des vuespartielles sur un modèle (structure de données etméthodes) ; ces vues étant obtenues grâce à desrestrictions sur certaines valeurs stockées dans le modèleou des projections sur certaines propriétés du modèle.

Côté client, ce pattern permet de lier l’interface-usagerofferte à un acteur (représentée dans le schéma par laclasse View) au modèle sur lequel agit cette interface(représenté par la classe Model) via le présenteur dumodèle. Le pattern fonctionne comme si le modèle et lavue étaient en liaison directe et assure ainsi leursynchronisation.

Dans notre contexte, ce pattern va permettre de gérer ladistribution des responsabilités entre les apprenants ou lesmoniteurs (côté client) et le LMS (côté serveur). L’idéeest de placer :- Au niveau de la classe Model les objets représentant le

domaine de l’activité et l’organisation de l’activité,- Au niveau de la classe View les objets permettant

d’offrir une interface-usager susceptible de permettre àl’apprenant de suivre l’activité coopérative proposéepar le LMS,

- La classe Presenter a pour rôle de synchroniser ce quitouche à la représentation de l’activité et ce qu’enperçoit un utilisateur (apprenant ou moniteur).

Remarquons ici, que plusieurs clients ayant leurs propres

présenteurs (issus de la classe Presenter) et leurs propresvues (issues de la classe View) peuvent synchroniser leursactivités grâce à ce modèle ; le pattern MVP se charged’assurer cette synchronisation pour la communauté desutilisateurs manipulant la classe Model (nousexpliquerons comment dans le paragraphe suivant).

Dans le prochain paragraphe, nous allons présenter unexemple simplifié d’application éducative coopérative quinous permettra de décrire comment un tel pattern MVPpourrait être mis en œuvre par un LMS.

2.3. Un exemple de mise en œuvre

Un pédagogue a conçu une situation dont l’objectif estque deux groupes d’apprenants coopèrent pourcomprendre les effets de la radioactivité sur l’organisme.Il s’agit d’une situation simplifiée qui permettra à desenfants d’école primaire de percevoir les effets surl’organisme en fonction de la quantité de matièreradioactive, de la durée de contact avec la sourceradioactive, de la distance entre une personne et cettesource radioactive, du calfeutrage de la source radioactive(capacité à isoler la source de son environnementimmédiat). L’objectif est que les apprenants se meuventdans un espace à proximité de la bombe, fassent deshypothèses et découvrent peu à peu les caractéristiquesdéfinissant le degré de contamination engendré par cettecharge. Les enfants doivent échanger des informations sur

Server-Side Client-Side

Presenter Presenter

Model View

interactor

commands

selections

distributed notification

remote data access

Client/Server communications :HTTP, RPC, ...

(n apprenants et moniteurs répartis sur le Web)

leurs découvertes et être en mesure à la fin de remplir unformulaire permettant de valider leurs acquis.

Pour décrire cette activité d’apprentissage, il nous fautdécrire les éléments du système d’informations qui vontse répartir au niveau serveur et au niveau client (cf figure

7). Les informations doivent être stockées au niveau de laclasse Model (côté serveur) afin d’être partagées et mise àdisposition des différents acteurs. Par rapport au patternMVP, la partie Model de notre exemple se décrit de lamanière suivante :

Figure 8 : Description générale des deux classes permettant de modéliser une activité

La description en UML du détail des classes utiles pourmettre en œuvre ces deux éléments du modèle dépassentle cadre de cet article. Nous donnons ci-dessous le modèlecomplet en UML pour la partie du modèle intitulée :Organisation de l’activité. Cet ensemble de classes UML

permet de décrire à la fois les activités prévues pourchaque acteur et de suivre les actions réellement menéesdurant l’activité par chaque acteur. Le lecteur trouvera lesexplications détaillées relatives à ce modèle dans[Sallaberry, et al., 2002] :

Figure 9 : Le détail des classes décrivant l’organisation d’une activité coopérative d’apprentissage

Domaine de l'activité

Propriétés décrivant la charge nucléaire et la position de la personne en contactavec cette charge à savoir :- quantité d'uranium- position de la charge d'uranium- contenant de la charge définissant un niveau de calfeutrage- position du sujet dans l'espace- heure de début d'exposition du sujet à la charge radioactive en un lieu donné- heure de fin d'exposition du sujet à la charge radioactive en un lieu donné- ...

Méthodes permettant de valoriser les propriétés décrivant la charge nucléaire et laposition de la personne en contact avec cette charge à savoir :- method getquantité()- method setquantité(qte : quantité)- ...

Organisation de l'activité

Propriétés décrivant les reponsabilités de chaque acteur (apprenant, moniteur) àchaque étape de l'activité ainsi que les outils à sa disposition (et lessynchronisations possibles entre acteurs) :

Méthodes permettant au pédagogue concepteur de définir les comportementsattendus des acteurs (apprenants, moniteurs). Méthodes permettant de suivre pas àpas les activités menées par les différents acteurs et de vérifier la faisabilité desactions initiées par les acteurs.

PBL

ProblemDescription

AssessmentCriterion Pre-requisite Success

Criterion

ObjectiveResource

MonitorLearner

Activity

User

performs

1..n1..n

1..n0..n0..n

1..n

1..n

1..n

uses

1..n

1..n 1..n

0..n

creates

0..n

1..n

Act

Scene PedagogicalStatement

*{ordered}

*{ordered} * *

{ordered}

State-TransitionDiagram

(from Core)

Element withHistory

State(fromCore)

Action(from Core)

Event(from Core)

predecessor

**

*

*

*

prer

equi

site

post

requ

isite

*m

anip

ulab

le*

RoleComponent

*

1..n

Functionality

Tool

Type ofResource

generated by* via

*

*

*

can manipulate

*

1

1

1

1

Côté View du pattern MVP, les apprenants (côté client)vont percevoir le modèle de la figure 8 au travers del’activité qu’ils mènent :

Figure 10 : La perception de l’activité par les apprenants(côté client)

L’activité de l’usager est contrainte par l’organisation del’activité qui lui est proposée et par les éléments dudomaine qu’on lui permet de manipuler (il s’agit bien deprésenteurs car deux apprenants différents vont avoir surla même activité coopérative des droits et des vuesdifférentes). Cette activité de l’usager va se manifester pardes interactions de celui-ci avec un environnementinformatique (au travers d’une certaine interface-usagerqui lui offrira certaines fonctionnalités en liaison avec sonrôle dans l’activité). Ainsi, une activité va par exempleoffrir à un apprenant un environnement d’outils luipermettant d’agir dans un micro-monde dédié. Le schémaci-dessous présente des exemples d’interactions enrelation avec le thème « Danger radioactif » :

Figure 11 : Exemple d’interactions présentées à unapprenant

L’écran présenté ci-dessus est un exemple d’interactiondans lequel l’apprenant se retrouve dans une partie de laville (ici la zone industrielle) et perçoit le phénomèneradioactif au travers d’un certain nombre de capteurs : leniveau de radioactivité actuelle, l’état physique de

l’enquêteur se trouvant dans la zone industrielle, … Ontrouve aussi dans cette interaction :- Des objets que peut analyser l’enquêteur pour

déterminer si la charge radioactive se situe ou pas danscette zone (taux de radioactivité instantanée, étatphysique de l’enquêteur).

- Des boutons permettant à l’enquêteur d’interagir avecd’autres enquêteurs (pour demander desrenseignements sur les autres zones de la ville, pourrenseigner d’autres enquêteurs, pour visualiser les lieuxde la ville où se trouvent les différents enquêteurs).

D’autres interactions pour cet apprenant sont renduesdisponibles par l’activité : une interaction lui permettantd’évaluer sa compréhension du phénomène radioactifobservé est ainsi accessible à travers le bouton «Tu astrouvé ?».

Les autres enquêteurs disposent d’interfaces et defonctionnalités d’outils spécifiques pour coopérer avec cetenquêteur selon un modèle de coopération défini auniveau de l’organisation de l’activité et sur la based’informations partagées qui sont issues du domaine del’activité (cf figure 8).

Les présenteurs (côté client et côté serveur) ne sont pasperçus par les acteurs ; ils permettent de gérer lessynchronisations entre les actions des usagers et lesvaleurs prises par les propriétés du modèle. Cettesynchronisation est basée sur le pattern Sujet-Observateur[Gamma, et al., 1995]. Le pattern Sujet-Observateurassure le fonctionnement général du LMS puisque c’estlui qui assure la synchronisation entre les valeurs despropriétés gérées par les différentes classes d’objets (cffigure 12). Ce pattern fonctionne selon le principesuivant :- Un objet qui souhaite observer des éléments d’un sujet

donné va s’attacher à ce sujet (méthode publiqueattache() de la classe Sujet)

- A un instant donné (lorsqu’une valeur des propriétésd’un sujet est modifiée par un acteur externe ou par lesujet lui-même), le sujet invoque sa méthode privéenotifie() qui va se charger de parcourir tous sesobservateurs attachés pour les mettre au courant que lesujet a été changé. Chaque activité de l’apprenant,instance d’un observateur, se charge alors de demanderla mise à jour des interactions fournies à l’apprenant ;chaque interaction connaît les propriétés du sujet surlesquelles elle est bâtie. Un rafraîchissement desvaleurs de ces propriétés de l’interaction suffit pourassurer la cohérence de cette interaction au regard dusujet observé.

Ainsi, côté client le schéma complet devient :

ActivitéPrésenteur du

domaine del'activité

Présenteur del'organisation de

l'activité

Interaction

*

11

11

Figure 12 : Application du pattern Sujet-Observateur à la gestion d’une activité distribuée

Côté client (voir schéma ci-dessus), on peut voir commentle système est capable, dès qu’il y a modification d’uneinformation au niveau d’un des présenteurs, de notifierl’activité en cours d’un apprenant pour que celle-ci prenneen compte le contexte nouveau (on rappelle que lesactivités étant coopératives, une valeur peut être mise àjour par un acteur autre que celui qui agit au niveau d’uneinterface-usager).

Nous ne présenterons pas les détails du fonctionnementcôté serveur dans cet article. Cependant le fonctionnementest similaire côté serveur avec des présenteurs qui jouent lerôle d’Observateurs de sujets que sont le Domaine del’activité et l’Organisation de l’activité.

3. Conclusions et perspectives

Dans cet article, nous avons montré qu’une pédagogie àbase d’activités coopératives est compatible avec lestravaux de normalisation menés par les consortiumsinternationaux centrés sur l’E-Learning. Après avoir décritles enjeux, les acteurs et les principes de mise en œuvred’activités d’apprentissage coopératives, nous avonsfocalisé notre attention sur la définition d’un système(appelé Learning Management System) capable d’assurerla distribution d’activités au service d’une communautéd’utilisateurs (apprenants et moniteurs).En nous appuyant sur la notion de pattern et sur le langage

UML, nous avons proposé une architecture techniquepermettant de supporter ces activités coopérativesd’apprentissage. Au delà de l’exemple présenté dans cetarticle :- Cette architecture doit être testée sur des situations

d’apprentissage en vraie grandeur. C’est à ce travail quenotre groupe de recherche vient de s’engager puisquenous avons acquis les ressources relatives à une situationd’apprentissage réelle [ACTIS, 2001] que nous tentonsen ce moment de formaliser et de mettre en œuvre.

- Du point de vue technique, nous avons entamé un travailde développement afin de coder les fonctionnalités d’unLMS simplifié capable de se comporter selon lesprincipes décrits dans cet article. Ce développements’effectue dans un environnement EJB (Entreprise JavaBeans), qui est particulièrement indiqué pour tous lesdéveloppements Web côté serveur [Brethes, et al.,2000].

Ces deux directions de travail nous permettront de validerles premiers résultats décrits dans cet article.

4. BibliographieACTIS (2001). Smash Scenario. ACTIS Ltd,http://www.projectboxes.co.uk/catalogue/scenarios.html#smash

AICC (2000). Aviation Industry CBT Committee (AICC).

Présenteur dudomaine de l'activité

Présenteur del'organisation de

l'activité

*

observateurs

*

1

1

1

1

Sujet

+ Attache()+ Detache()- Notifie()

Observateur

+ Mise_a_jour()

*

Interaction

+ Mise_a_jour()

for o inobservateurs :

o.Mise_a_jour()

Il s'agit d'uneméthode

abstraite qui doitêtre redéfinie

Activité

+ Mise_a_jour() for i ininteractions :

i.Mise_a_jour()

interactions

Une Interaction se met àjour en raffraichissant son

interface-usager enfonction des propriétés

gérées par les présenteursdu domaine et de

l'organisation de l'activité

document #CMI001: CMI Guidelines for Interoperability,v3.4; released, www.aicc.org

ARIADNE (2001). Alliance of remote instructionalauthoring and distribution networks for Europe website[On-line. 2001: ARIADNE, http://ariadne.unil.ch/

Bourguin, Grégory (2000) Un support informatique àl’activité coopérative fondée sur la théorie de l’activité : leprojet DARE, Thèse de Doctorat de l’Université de Lille

Brethes, T., Hisquin, F., & Pezziardi, P. (2000). Serveurd'Applications.

Chapman, B., & Hall, B. (2001). Learning ContentManagement Systems.

De La Passardière, B., & Giroire, H. (2001). XML auservice des applications pédagogiques. Revue Sciences etTechniques Educatives, 99-112,

Develay, M. (1993). De l'apprentissage à l'enseignement.Collection Pédagogies

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995).Design Patterns: elements of reusable object-orientedsoftware.

George, S. (2001). Apprentissage collectif à distance.SPLASH : un environnement informatique support d'unepédagogie de projet. Thèse de doctorat de l'Université duMaine

Harasim, L. (1999). A framework for Online Learning:The Virtual-U. IEEE Computer, 0018-9162/99,http://www.telelearn.ca/g_access/news/r9044.pdf.

IMS (2001). Instructional management systems projectwebsite. http://imsproject.org/

Koper, R. (2001). Modeling Units of Study from aPedagogical Perspective : the pedagogical meta-modelbehind EML. Educational Expertise Technology Centre,Open University of the Netherlands

Laforcade, P. (2002). Modélisation des composantséducatifs mis en jeu dans une plate-forme de FOAD.soumis à la conférence Inforsid 2002. Grenoble (France)

LOM (2000). LOM working draft v4.1.http://ltsc.ieee.org/doc/wg12/LOMv4.1.htm

LTSC (2001). Learning technology standards committeewebsite. http://ltsc.ieee.org/

Marquesuzaà, C. (1998). OMAGE : Outils et Méthodepour la spécification des connaissances au sein d'un Atelier

de Génie Educatif. Doctorat de l'Universite de Pau et desPays de l'Adour

Meirieu, P. (1994). Apprendre... Oui mais comment?Collection Pédagogies

Nodenot, T. (2001). A case for an Adult EducationalTechnology. IFIP 7th World Conference on Computers inEducation. Copenhagen (Denmark)

Potel, M. (1996). MVP : Model-View-Presenter : theTaligent Programming Model for C++ and Java. TaligentIncorporated,www.carfield.com.hk/document/software_design/MVC.pdf

PROMETEUS (2001). European Partnership for aCommon Approach to the Production of e-learningTechnologies and Content website.http://www.prometeus.org

Rengarajan, R. (2001). ASPEN LCMS : Click2Learn'sComprehensive LCMS Solution. Click2learn Inc.,http://home.click2learn.com/en/downloads/Aspen_LCMS_white_paper.pdf

Rodriguez-Artacho, M., & all, a. (1999). Using a high-level language to describe and create Web-based learningscenarios. 29th ASEE/IEEE Frontiers in educationConference. San Juan, Porto Rico

Sallaberry, C., Nodenot, T., Marquesuzaà, C., Bessagnet,M.-N., & Laforcade, P. (July 14th-18th 2002). An attemptto design an Information System supporting CollaborativeProblem-Based Learning Situations. The 6th WorldMultiConference on Systemics, Sybernetics andInformatics. Orlando (USA), http://www.iiis.org/sci2002/

Sawyer, B. (2000). Using Virtual U in Consultant andTraining Situations:

Tips and advice on creating 1-2 day workshops or seminarsusing Virtual U., http://www.virtual-u.org/edutools.html

SCORM (2000). The Department of Defense AdvancedDistributed Learning -- ADL -- Initiative Releases Version1.2 of the Sharable Courseware Object Reference Model --SCORM 1.2.

Suthers, D. (August 2001). Architectures for ComputerSupported Collaborative Learning. IEEE InternationalConference on Advanced Learning Technologies(ICALT'2001). Madison, Wisconcin (USA)

Wiley, D. (2000). Connecting learning objects toinstructional design theory: A definition, a metaphor, and ataxonomy. http://reusability.org/read/chapters/wiley.doc