Caron RSTI version finale, finale

De l'intérêt de la contextualisation de modèles
1
La contextualisation de modèles, une étape indispensable à
un développement dirigé par les modèles ?
Pierre-André Caron(1), Mireille Blay-Fornarino(2), Xavier Le Pallec(1)
(1) LIFL (équipe NOCE), Université de Lille 1
Extension Bâtiment M3, Cité Scientifique
59655 Villeneuve d’Ascq
[email protected], [email protected]
(2) Université de Nice – Sophia Antipolis
Laboratoire I3S CNRS, 930 Route des colles, 06903 Sophia Antipolis Cedex
[email protected]
: Le principe de la démarche MDA est l'élaboration de modèles adaptés aux métiers, indépendants des plateformes, et
leur transformation en modèles dépendants de plateformes pour l'implémentation concrète du système. Une partie des travaux de
l’équipe NOCE vise à appliquer cette démarche sur les Environnements Informatiques pour l'Apprentissage Humain (EIAH).
Cette application révèle une double particularité : la polyvalence de l’utilisateur final qui modélise, raffine et concrétise ; la
construction automatique finale qui se doit de contextualiser le dispositif modélisé au sein d’une plateforme déjà active et
peuplée. L’expérience menée a souligné de nombreuses difficultés relatives à cette démarche. Nous mettons ici en évidence les
problèmes résultants des transformations entre métamodèles différents et proposons des pistes pour réduire la distance entre les
modèles du métier et des plateformes.
RÉSUMÉ
ABSTRACT : The MDA approach may be broadly reduced to the following lifecycle: defining platform independent business models
and transforming them into platform dependent models for software implementation concerns. The NOCE team works in the
Technology Enhanced Learning (TEL) area. One of its works aims to apply the MDA approach in TEL domain. This application
presents two particularities: the versatility of the user who defines models, refines them and drives the corresponding software
construction; the final automatic construction which has to contextualise the modelled dispositif within a platform already active
and populated. The conducted experience has underlined several difficulties which are related to such approach. We bring out
here problems which result from transformations between distinct metamodels and we propose some perspectives to reduce
distance between business models and platforms.
MOTS-CLÉS : MDA, fusion de métamodèles, transformation de modèles, contextualisation de modèles, expérimentation, EIAH,
plateforme d’enseignement.
KEYWORDS :
MDA, metamodel merge, model transformation, model contextualisation, experimentation, TEL, learning platform.
2
Revue. Volume X – n° x/année
1. Introduction
Nous nous intéressons à l'élaboration de modèles adaptés aux pratiques des enseignants construisant des
dispositifs pédagogiques sur des plateformes de formation. Un dispositif pédagogique "consiste en une organisation
de moyens au service d'une stratégie, d'une action finalisée, planifiée visant à l'obtention d'un résultat" (Peraya,
1998). Dans la pratique et pour des plateformes de formation, 'les moyens' sont, pour les plus connus, les forums, les
gestionnaires de documents, les outils permettant le dépôt de devoirs, les exerciciels, la conférence synchrone, les
Wikis, les séquences pédagogiques, 'le résultat' attendu est l’acquisition d’une connaissance ou d’une compétence.
Dans le cadre de cet article, nous abordons la construction d’environnements informatiques supports à la construction
de ces dispositifs.
Cet article court vise à ouvrir des pistes d’investigations en IDM relativement à un domaine applicatif, les
environnements informatiques pour l'apprentissage humain. Au sein d'un tel domaine le modèle dirige non seulement
le développement mais il est également nécessaire au cycle de vie globale de l’application non seulement comme un
artefact de compréhension mais également comme un moyen de diriger les évolutions de ces environnements.
Dans la deuxième partie, nous montrons les problèmes associés à la construction de dispositifs sur des
plateformes de formation, nous présentons l’approche orientée modèle que nous avons adoptée pour apporter à ces
problèmes des solutions. Dans la troisième partie, nous relatons une expérimentation de cette démarche et nous
indiquons les limites d’une démarche de type OMG-MDA dans ce domaine. La dernière partie présente une évolution
de notre approche afin d’éliminer les précédentes limitations.
2. De la nécessité de l’IDM en EIAH
2.1. Dispositifs et plateformes de formation
Les plateformes de formation procurent de nombreuses fonctionnalités qui facilitent, en dehors des phases de
face-à-face pédagogique, le suivi pédagogique pour l’enseignant et le travail collaboratif pour les étudiants. Dans le
cadre de l’enseignement à distance, de telles plateformes sont devenues incontournables. On compte aujourd'hui près
de 240 de plateformes dédiées à l'enseignement (Thot). Ce nombre est à relativiser :
- en le minimisant : toutes les plateformes n'ont pas la même audience, par exemple parmi les nombreuses
plateformes open sources utilisables, quatre plateformes occupent une place prépondérante (Adkins, 2005).
- en l'augmentant : de nombreux outils sont utilisés en tant que plateforme de formation sans être référencés en
tant que tel, par exemple près de 600 "Content Management System" sont référencés (CMS).
L'expérimentation que nous relatons dans cet article considère le terme plateforme de formation au sens large en y
incluant par exemple des artefacts tels que Wiki, Blog ou Forum, pour peu que ces artefacts permettent
d'accompagner une œuvre de formation. L'artefact utilisé par notre expérimentation est l'application WikiniMST.
Quelque soit le type de plateforme envisagée la lourdeur de certaines tâches d’ingénierie associée à ces
plateformes reste un obstacle au partage, à l’alternance technologique et plus généralement à la réutilisation de
dispositifs pédagogiques.
La réutilisation. Construire un dispositif sur une plateforme implique une série de tâches vite rébarbatives si elles
doivent être répétées chaque année. Ces tâches consistent par exemple à définir des espaces de documentation, de
partages et de dépôts de travaux, des conférences asynchrones dédiées à des sujets particuliers, indiquer la
chronologie, fournir un descriptif détaillé du cours associé en explicitant par exemple les objectifs, les modalités
d’évaluation, les modes d’apprentissages… L’espacement entre deux promotions ne permet pas à l’enseignant de
s’habituer à la plateforme et d’augmenter son efficacité. Une fonction de sauvegarde du dispositif serait ici bénéfique
afin d’éviter la reconstruction du dispositif pour chaque nouvelle promotion. Toutefois une telle fonctionnalité devrait
alors prendre en charge plusieurs caractéristiques sophistiquées parmi lesquelles on dénombre par exemple :
De l'intérêt de la contextualisation de modèles
3
- la sélectivité des éléments du dispositif à sauvegarder, certains messages sur un forum pouvant par exemple faire
partie des informations à reconstruire,
- l’abstraction de certains éléments construits comme par exemple la vue d’ensemble d’un dispositif, celle-ci étant
construite sur la base des éléments existants …
Le partage. Actuellement partager un dispositif pédagogique entre deux enseignants nécessite pour ceux-ci
l'utilisation d'une même plateforme de formation. En effet faute d'un langage, indépendant des plateformes de
formation, il est difficile pour un enseignant d'exprimer un dispositif indépendamment des choix technologiques qui
le mettent en œuvre. Ceci implique pour l’enseignant, auteur du dispositif, de devoir extraire les intentions
pédagogiques de son dispositif "technologique". Cette extraction est rendue difficile par divers facteurs, l'oubli des
intentions qui ont permis la création du dispositif, le caractère semi-improvisé des activités menées par un enseignant
(Perrenoud, 1983) (Merrieu, 1999), l'évolution naturelle que subit un dispositif pédagogique dès lors qu'il implique
chez les apprenants des activités de co-constructions. De fait, le modèle sous-jacent à un dispositif pédagogique est
en constante évolution.
L’alternance technologique. Une formation ou un enseignant peut être amenée à changer de plateforme afin de
s’adapter à des changements de son contexte (changement de politique universitaire, de direction) ou plus
généralement de profiter d’une plateforme plus efficace ou plus adaptée au type d’enseignement appliqué. La
difficulté pour un enseignant à exprimer les concepts sous-jacents à un dispositif pédagogique entraîne alors pour lui
une difficulté à les transférer conceptuellement d’une plateforme à une autre.
Une solution à ces trois problèmes consisterait à disposer de standards supportés par les plateformes de formation
et permettant d'exprimer des dispositifs pédagogiques. De tels standards existent mais ils ne permettent pas de
correctement spécifier des dispositifs pédagogiques :
-Les standards SCORM ou IMS-SS permettent de décrire de simples séquences pédagogiques sans impliquer des
aspects collaboratifs tels que régulation d’outils et synchronisation d’activités. L’expression de dispositifs
pédagogiques à l'aide de ces standards est donc volontairement très limitée. Pour préserver l’indépendance vis-à-vis
des plateformes, ces deux standards passent en effet sous silence les références au contexte précis permettant la
réalisation de l'activité (Allert, 2004). La réutilisation réelle recherchée n’est alors pas facilement atteignable.
- Le Standard IMS-LD est plus complexe, il permet d'exprimer, sous forme de séquencements multiples, les
différentes activités que des élèves et des enseignants peuvent mener dans le cadre d'un dispositif pédagogique.
Cependant malgré de nombreux travaux réalisés pour simplifier l'appréhension du standard, sa complexité le rend
difficile à maîtriser (Paquette, 2006). En conséquence, il ne permet pas de répondre aux points énoncés
précédemment, d'une part il ne peut pas être manipulé directement car il ne forme pas un langage métier adapté à des
enseignants, d'autre part les plateformes courantes ne proposent pas de correspondance avec le métamodèle sousjacent à ce standard.
2.2. Séparation des intentions pédagogiques et des aspects technologiques
La diversité des dispositifs imaginés par les enseignants en fonction des différents contextes d’apprentissage et la
multiplicité des plateformes potentielles pour déployer un dispositif pédagogique, nous ont conduits à nous intéresser
aux outils à mettre en œuvre pour supporter ce déploiement. Notre objectif est donc d’accompagner les activités de
conception de dispositifs pédagogiques afin de favoriser l’expression des dispositifs dans les termes de l’enseignant,
de permettre leur mise en œuvre sur différentes plateformes à moindre coût et de supporter à la fois les évolutions du
modèle pédagogique et les changements de plateformes. Une approche guidée par les modèles semble toute indiquée
pour répondre à cette problématique. Nous avons choisi d’adopter une démarche de type OMG-MDA (MDA, 2003)
et nous avons spécifié et outillé un processus illustré sur la figure 1 : la séparation entre les préoccupations
indépendantes et dépendantes de la plateforme (Kent, 2002) permet à l'enseignant de se focaliser sur ses intentions
pédagogiques, de ne pas être perturbé et/ou influencé par des considérations techniques. Le dispositif abstrait ainsi
spécifié peut alors être transformé en un dispositif spécifique à la plateforme de formation.
4
Revue. Volume X – n° x/année
ModX
Description
informelle du
dispositif
pédagogique (CIM)
Modèle abstrait
du dispositif
(PIM)
GenDep
Modèles
technologiques
du dispositif
(PSM)
Dispositif au sein
de plateformes
Ganesha
WikiMST
…
[transformation]
[construction]
Figure 1. Une démarche MDA pour modéliser et construire des dispositifs
Le modèle CIM (Computer Independant Model) correspond à la description en langage naturel (i.e. textuel) du
dispositif pédagogique imaginé par l’enseignant. Le modèle PIM (Platform Independant Model) correspond à une
description du dispositif conforme à un métamodèle spécifique à une pratique pédagogique. Ce modèle est
indépendant de la plateforme de formation visée par l’enseignant. Le modèle PSM (Platform Specific Model)
correspond au modèle du dispositif conforme au métamodèle déduit de l’analyse de la plateforme ciblée.
Nous relatons, ci-après, la construction d’un ensemble de dispositifs qui s’appuie sur le précédent processus et sur
un environnement logiciel mis à disposition de l’enseignant basé sur deux outils : ModX un éditeur de métamodèles
et GenDep un générateur de constructeurs spécifiques.
3. Construction des dispositifs dirigée par les modèles
3.1. Contexte : Explorateurs d’Actions Personnelles et Collectives
Une des applications qui a guidé notre travail apparaît dans le projet PCDAI (Pratique Collective Distribuée
d’Apprentissage sur Internet) (PCDAI, 2006) (PCDAI, 2007). Ce projet vise à permettre des formes d’apprentissage
plus actives sur Internet et plus particulièrement l’accompagnement collaboratif à distance de stages et de rédactions
de mémoire professionnel. Pour réaliser cet accompagnement, une équipe d’enseignants et de chercheurs en Science
de l’Education a souhaité concevoir un type de dispositif pédagogique adapté à ce genre d’activités, type qu’ils ont
nommé Explorateur d’Actions Personnelles et Collectives (EAPC).
L’EAPC est basé sur les concepts de membres, de groupes et de balises (cf. le métamodèle présenté dans la figure
2) : le travail collaboratif se fait via un espace de travail "balisé" où les informations associées à chacune des balises
mettent en jeux différents usages dont le plus important est la création par leur propriétaire d'un premier écrit "balisé"
permettant à terme de servir de supports à l'écriture de mémoires professionnels. D'autres usages sont envisagés
parmi lesquels l'enrichissement par les autres apprenants des différents espaces dans le but de constituer une mémoire
collective ainsi que la création au sein de cette mémoire de parcours pédagogiques. La réalisation technologique d’un
EAPC peut se faire au travers de forums, de référentiels de documents, de pages Wiki, etc…
Le dispositif a pour but d'encadrer la rédaction de mémoire professionnel, il est destiné à des apprentis formateurs
en activité (contrat de professionnalisation) ayant un "double" statut de salariés et d’étudiants, la formation dure 18
mois et permet l'obtention d'une licence professionnelle intitulée : "Gestion et Accompagnement des Parcours
Professionnels et Personnels dans les organisations" (LP GA3P). L'équipe pédagogique a décidé que l'activité
d'écriture de chaque étudiant devait être balisé et que chaque balise pouvait correspondre à un espace spécifique
d'écriture, l'ensemble de ces écrits balisés pouvant permettre à terme l'écriture du mémoire professionnel. L'équipe a
donc envisagé d'affecter à chaque étudiant 6 espaces permettant de baliser ses écrits : un pour la création de son
espace personnel, un pour la formalisation de sa mission, un pour la capitalisation des références bibliographiques, …
(cf. le modèle de cette application dans la Figure 2).
De l'intérêt de la contextualisation de modèles
Figure 2 . Métamodèle métier
5
Figure 3 . Détails du Modèle métier
3.2. Transformations vers l’application Web WikiniMST
La précédente équipe s’est orientée vers l’application Web WikiniMST pour construire des EAPC. Ce Wiki,
adapté aux besoins du milieu éducatif, a été choisi à cause de sa proximité avec les caractéristiques des EAPC.
Pour automatiser la construction des EAPC à partir de modèles, nous avons conçu un environnement logiciel
respectant les préceptes du précédent processus (cf. partie 2.2) et basé sur les quatre éléments suivants :
1.
Définition du métamodèle métier : le métamodèle EAPC (cf. figure 2) est défini avec l’éditeur ModX.
ModX est un éditeur de métamodèles et de modèles basé sur MOF 1.4. Bien moins puissant que des outils
comme EMF/GMF, son environnement est par contre très simple et adapté à des enseignants. Il supporte la
persistance des modèles au format MOF-XMI 1.1.
2.
Définition du métamodèle spécifique de la plateforme cible : un métamodèle de la plateforme WikiniMST
est défini dans ModX (cf. figure 4). Ce métamodèle contient les concepts du WikiniMST qui nous
permettront de peupler la plateforme. On retrouve au niveau de cette plateforme les concepts de membre et
de groupe.
3.
Définition des règles de transformations des modèles métiers vers des modèles plateformes : des règles de
transformation du métamodèle EAPC vers le métamodèle WikiniMST ont été définies dans ModX.
Les espaces balisés trouvent une correspondance acceptable avec les pages, tout comme les enrichissements avec
les commentaires. Au niveau de la plateforme, des règles régissent les droits d’accès. Les précédentes
correspondances et l’explicitation des droits d’accès constituent l’essentiel des règles de projection EAPC vers
WikiniMST. La figure 5 montre la projection du triplet Etudiant [Membre] - Prendre Place [Balise] – Etudiants
[Groupe] de la figure 3.
4.
Définition d’un web service permettant de peupler la plateforme : la construction d’un dispositif à partir
d’un modèle sur une plateforme en ligne et sa contextualisation implique une communication dynamique
avec la plateforme et non un simple chargement de fichier. L’outil GenDep s’occupe de cette opération. En
amont de ces opérations, il permet de générer la partie SOAP cliente pour une plateforme donnée à partir du
métamodèle correspondant (Caron, 2007).
GenDep lit les métamodèles et les modèles au format MOF-XMI 1.1. Pour un modèle et une URL donnés,
GenDep interagit avec la plateforme désignée par la précédente URL pour construire sur celle-ci un dispositif dont la
structure est formalisée par le précédent métamodèle et décrite par le modèle de dispositif. Cette construction
comporte une phase de contextualisation du modèle qui est fondamentale : GenDep consulte les éléments existants
sur la plateforme et les présente à l’utilisateur pour que celui-ci les utilise ou non dans la construction de son
dispositif. Par exemple, les espaces personnels préexistants sont présentés à l’utilisateur qui peut exprimer des
correspondances avec les éléments pages de son modèle, ou simplement faire le choix de les inclure dans son
dispositif comme de nouveaux éléments du modèle. L’interaction avec la plateforme dans cette expérimentation se
fait via le protocole SOAP.
Cet environnement a permis aux enseignants de la licence GAP3 de créer leur EAPC au sein de la plateforme
WikiniMST en leur offrant la possibilité de spécifier leurs intentions pédagogiques sans se préoccuper des contraintes
6
Revue. Volume X – n° x/année
liées à la plateforme WikiniMST. Le processus de conception et de construction que les enseignants ont alors suivi
est constitué de trois étapes :
1.
Définition du modèle de l’application : le métamodèle EAPC est utilisé dans l’éditeur ModX pour
contraindre la définition du modèle d’EAPC adapté à la licence GAP3 (cf. figure 3)
2.
Transformation (automatique) du modèle EAPC du dispositif en modèle WikiniMST : les enseignants
pouvaient consulter et raffiner le modèle WikiniMST généré automatiquement.
3.
Contextualisation et construction du système sur la plateforme : à partir du modèle spécifique à la
plateforme, cette étape, prise en charge par l’outil GenDep, permet d’automatiser la construction des
entités au niveau de la plateforme. Cette approche a été appliquée dans un contexte composé de 40
étudiants et 5 formateurs, et GenDep a engendré la création de 1315 éléments au niveau de la
plateforme. Cette étape a nécessité la récupération et le traitement des informations préexistantes sur la
plateforme cible. Nous la discutons ci-après.
Ces trois étapes sont répétées à chaque nouvelle construction d’EAPC, les quatre éléments de l’environnement ne
sont quant à eux créés qu’une seule fois : le méta-modèle EAPC peux ainsi être par exemple utilisé pour des
transformations vers les plateformes Claroline (Claroline) ou Moodle (Moodle). Si ces deux plateformes disposent
déjà de leur métamodèle et de leur plug-in SOAP, seules les règles de transformation PIMPSM devront alors être
définies par l'informaticien responsable de la mise en œuvre de l'infrastructure logicielle, (Peter et al., 2007) illustre
notre processus de type MDA sur un dérivé d’IMS-LD et la plateforme Claroline.
Figure 4 . Vue simplifiée du Métamodèle spécifique plateforme
Figure 5 . Un détail du modèle PSM
3.3 Une étape critique, la contextualisation
Une des caractéristiques de cette expérimentation est d’adresser une plateforme de formation de type "Wiki"
privilégiant des activités de co-écriture et des structurations émergentes (création de groupe, établissement de
privilèges etc). Construire un dispositif pédagogique sur une telle plateforme repose sur l’utilisation de ces
mécanismes. La contextualisation, évoquée plus haut, est particulièrement pertinente dans ce contexte car elle aide
l’émergence d’une nouvelle structure – l’EAPC – au sein d’éléments déjà existants : par exemple pour un étudiant
donné, GenDep permet d’utiliser une de ses pages Wiki pour la balise "espace personnel" plutôt que de lui créer et
associer une nouvelle page. Cette phase de construction/contextualisation primordiale a été jugée difficile, voire
incompréhensible, par les enseignants. Cette difficulté étant due d'une part à la distance entre le modèle de dispositif
et sa réalisation dans la plateforme et d’autre part, à la nécessité de récupérer au niveau du dispositif des informations
pré-existantes sur la plateforme.
Lors de l'expérimentation, les enseignants ont facilement compris que les pages du Wiki concrétisaient les balises
de l'EAPC et qu'elles offraient cet espace potentiel d'écriture balisée qu'ils souhaitaient mettre en œuvre. Par contre,
la définition d'une politique régissant les droits d’accès à ces écrits s'est révélée être plus problématique. Dans le
contexte des EAPC, les droits d’accès sont implicites : pour une balise donnée, l'étudiant, à qui la balise est destiné, a
un accès complet aux écrits balisés, les membres de son groupe ont un droit de lecture et d’enrichissement sur ces
écrits et les autres ont un simple droit de lecture. Nous l’avons dit plus haut, les règles de transformation EAPCWikiniMST spécifient automatiquement pour chaque modèle EAPC, les droits d’accès correspondants au sein du
modèle WikiniMST. A la construction d’un dispositif, les enseignants peuvent ainsi occulter les droits d’accès des
De l'intérêt de la contextualisation de modèles
7
pages Wiki et laisser faire la construction automatique. Cette possibilité ne peut cependant pas être envisagée
lorsqu'ils souhaitent ou doivent intégrer des pages déjà existantes dans l’espace balisé. Pour ces pages préexistantes,
les modifications que doivent manuellement effectuer les enseignants à l'aide de notre logiciel GenDep visent
principalement à établir les droits d’accès pour les membres du groupe auquel appartient le propriétaire et pour les
personnes extérieures au groupe. Les enseignants, usagers de notre infrastructure logicielle, nous ont indiqué que
cette étape était loin de leur sembler anodine et qu’ils souhaitaient vivement vérifier, ou tout au moins analyser, les
modifications relatives aux droits d’accès des espaces personnels préexistants. Malheureusement les concepts
intervenants dans cette étape ‘administrative’ sont très éloignés de ceux utilisés par les enseignants lors de la
définition de leur modèle abstrait, ce qui les a désorientés. Cet éloignement PIM-PSM s’est révélé être, finalement,
réellement problématique, l'exploitation pédagogique du dispositif généré ayant mis en évidence l’importance des
espaces personnels préexistant, ceux permettant d’amorcer l’usage du dispositif EAPC rapidement et efficacement
lors des phases initiales de regroupement.
De manière générale, proposer comme nous l’avons fait une séparation abstrait-concret dans la modélisation avec
les règles de transformation associées, c’est-à-dire adopter une démarche typiquement OMG-MDA, n’est pas une
bonne approche dans notre contexte. Dans celui-ci, l’enseignant travaille sur la modélisation abstraite et occulte la
modélisation concrète alors que celle-ci est le fil conducteur de la construction/contextualisation, des éléments
essentiels pouvant lui être inconnus ou peu connus. Nos travaux nous amènent à penser que ce type de démarche
rencontrera les mêmes problèmes dans bon nombre de domaines où la personne qui définit le modèle abstrait est la
même que celle qui effectue, au final, la construction logicielle. Nous avons donc défini, l’année suivante lors d’une
nouvelle construction de dispositifs, un nouveau métamodèle intégrant des éléments nécessaires à la
construction/contextualisation dans les termes du métier. La construction de ce métamodèle s’est basée sur le
métamodèle EAPC et le métamodèle Wikini-MST précédemment définis. Elle n’aurait pas été possible sans cette
connaissance. Nous présentons à présent ce nouveau métamodèle.
4. Contextualisation des métamodèles
Sur la base de la même application que précédemment, l’année suivante, nous avons conduit une nouvelle
expérimentation dans laquelle les problèmes rencontrés ont été traités en définissant un nouveau métamodèle de
dispositifs mieux adapté. Nous le décrivons ci-après puis discutons (cf. 4.2) les perspectives à ce travail.
4.1 Définition d’un métamodele métier contextutalisé
Pour pallier les difficultés de contextualisation, l’équipe pédagogique a reformulé le dispositif initial en le
complétant d’informations mises en exergue lors de la première expérimentation, en particulier les aspects
d’administration. Elle a choisi d'exprimer au niveau d’un modèle métier les droits, ceux-ci étant plus faciles à
appréhender sous cette forme que sous la forme de règles de transformation. La notion de balise a de ce fait été
abandonnée au profit de la notion d'espace, notion jugée par les enseignants plus proche du dispositif final. De même
les notions de nommage ont été distinguées de l’identifiant du membre, cette distinction a facilité la présentation et la
réutilisation des entités existantes au niveau de la plateforme. Enfin, l’expression des cardinalités a permis, lors de la
phase de construction, d’expliciter la génération de liste d’entités sans les énumérer au niveau du modèle. Ainsi la
figure 7 visualise le nouveau métamodèle qui a été définit et la figure 8 présente un détail du nouveau modèle
construit.
8
Revue. Volume X – n° x/année
Figure 6 . Vue simplifiée du Métamodèle contextualisé
Figure 7 . Une partie du modèle
Sur la base de ce métamodèle, le modeleur et le constructeur spécifique ont été générés par ModX.
L’implémentation de ce constructeur a été modifiée afin que le dialogue avec la plateforme soit traduit dans ce
nouveau métamodèle. La partie cliente, SOAP pour la plateforme WikiniMST, tout comme son greffon de services
Web encapsulant l’API de la plateforme, restent inchangés. Le nouvel environnement destiné aux enseignants ne
propose plus deux étapes possibles de modélisation mais une seule, celle-ci étant basée sur un métamodèle inspiré
des deux précédents. L'enseignant peut modéliser son dispositif et profiter des vues multiples de ModX pour le
décrire sous différents angles (les espaces, les groupes, les propriétés … cf. figures 8 et 9).
Figure 8 . Partie décrivant les sous-groupes
Figure 9 . Partie décrivant les fonctions d'administration
Le nouveau métamodèle représente un compromis entre les concepts métiers et leurs réalisations dans le contexte
de la plateforme tels qu’ils sont perçus par les enseignants. Ce métamodèle correspond d’une certaine manière au
métamodèle des affordances perçues de la plateforme au sens qu’en donne (Norman, 2002), la notion d'affordance
perçue caractérisant la capacité pour un humain d'appréhender spontanément les fonctionnalités d'un objet.
Cette deuxième expérimentation a validé cette démarche:
- les enseignants ne sont plus "perdus" lors de la phase de contextualisation/construction ;
- ils peuvent spécifier leur dispositif avec comme repère l’idée intuitive qu’ils ont de l’usage de la plateforme de
formation.
Si, sur le plan pragmatique, cette solution s’est révélée efficace, elle présente conceptuellement des inconvénients.
L’écriture de règles de transformation au niveau du constructeur spécifique a pour conséquence de mêler une partie
de la logique métier avec des considérations technologiques. La solution proposée ne permet plus la réutilisation d'un
De l'intérêt de la contextualisation de modèles
9
modèle abstrait sur une autre plateforme, ce qui ne favorise plus le partage avec d'autres enseignants et la réutilisation
sur d'autres plateformes.
4.2. Entre transformations et composition de métamodeles
Dans notre cas d’étude, le passage du PIM au dispositif sur la plateforme met en jeu une étape importante de
contextualisation. Nous trouvons dans le processus classique MDA, une étape de raffinement qui conduit à préciser
les paramètres nécessaires à la réalisation sur la plateforme cible (Blanc et al., 2004). Cette étape peut introduire des
informations non prévues dans le modèle source, telle que la gestion des fichiers de configuration.
Dans notre expérimentation, cette étape est d’autant plus critique qu’elle est réalisée par le concepteur du modèle
qui n’est pas programmeur. Dans la première expérimentation, l’enseignant est confronté à la précision d’artefacts
logiciels qui n’appartiennent pas au métamodèle source et sont donc difficilement compris. De même, la nécessité
d’exprimer l’ensemble du modèle par extension ne permet pas d’automatiser certaines constructions par
transformation. Enfin la nécessité de prendre en charge des éléments préexistants sur la plateforme ne permet pas
d’échapper aux précédents problèmes. L’approche par "contextualisation" des métamodèles apporte de notre point de
vue des éléments de réponse, nous les discutons ici.
La contextualisation de métamodèles n’a été possible qu’après une première étape PIM, PSM et transformation
PIM-PSM. Cette première expérience nous a permis de clairement identifier les propriétés propres à chaque partie du
processus. La contextualisation a alors été réalisée "à la main", et le résultat obtenu a été d’un point de vue
fonctionnel immédiat satisfaisant. Pour pallier les problèmes éventuels d’évolution de ce métamodèle au regard de
changements de plateformes et d’évolution du métamodèle métier, nous pensons qu’il existe une voie intermédiaire
qui supporterait la construction semi-automatique du métamodèle "contextuel" .Les règles d’appariements entre
métamodèles doivent donner pour l'enseignant accès à des artefacts qui lui permettent d’interagir avec la plateforme,
dans les termes du métamodèle pédagogique, tout en ayant accès aux éléments et à la structuration portée par le
métamodèle de plateforme.
Nous envisageons aujourd’hui plusieurs pistes pour outiller la construction de ce métamodèle. La première repose
sur la relation "Package Merge" définie par la spécification UML (OMG, 2007). Elle repose sur des transformations
qui étendent le contenu du package résultant de la fusion. Ce mécanisme repose sur l’identité des noms des éléments.
Il nous faut donc lever cette contrainte qui est inadéquate dans notre contexte. Dans (Ammour et al., 2006), les
auteurs étendent les règles de fusion par des clauses qui permettent de fusionner des éléments de nom différent. Les
travaux sur la composition de modèles (Bézivin et al., 2006) offrent également différentes solutions pour l’expression
des correspondances entre modèles. Ainsi S. Clarke (Clarke, 2002) propose d’étendre UML afin d’intégrer une
relation de composition dans laquelle des fusions et remplacements peuvent être exprimés. D’autres travaux abordent
la composition des modèles par la définition de paquetage générique (Template package) (Muller et al., 2005), ou de
modèles génériques (UML Model Template) (Straw et al., 2004). Ces travaux renforcent alors la notion de points de
vue, qui permet de réduire la complexité du métamodèle résultat. Enfin, nous citerons les travaux de Bernstein and
co. qui visent à généraliser la composition des modèles (Bernstein, 2003). La construction du générateur de code peut
alors être dirigée par les compositions définies (Muller et al., 2007).
L’ensemble de ces travaux, relatifs à la composition de modèles, nous semble prometteurs. De notre expérience, il
apparaît en effet que, sans ce type d’opérateur, l’ingénierie des modèles est inadaptée à des domaines d’applications
où la contextualisation joue un rôle important et où la multiplicité et l’hétérogénéité des plateformes cibles ne permet
pas d’envisager le développement de fabriques logicielles de type "plugin".
5. Bibliographie
Adkins, "Wake-Up Call: Open Source LMS ", http://www.learningcircuits.org/2005/oct2005/adkins.htm, pages consultées en
octobre 2007
S. Ammour, P. Desfray, "A Concern based Technique for Architecture Modelling Using the UML Package Merge." Electr. Notes
Theor. Comput. Sci. 163 (2006), 718.
P. Bernstein, "Applying model management to classical meta data problems" Innovative Database Research (CIDR), (Asilomar,
CA, USA, 2003.
10
Revue. Volume X – n° x/année
J. Bézivin, S. Bouzitouna, M. D. D. Fabro, M. P. Gervais, F. Jouault, D. S. Kolovos, I. Kurtev, R. F. Paige, "A Canonical Scheme
for Model Composition." A. Rensink, , J. Warmer (eds), ECMDAFA, Lecture Notes in Computer Science, Springer 4066
(2006), 346-60.
X. Blanc, O. Caron, A. Georgin, A. Muller, "Transformations de modèles : d'un modèle abstrait aux modèles CCM et EJB" Conf.
francophone LMO'2004 (Langages et Modèles à Objets), (2004.
P.-A. Caron, "Ingénierie dirigée par les modèles pour la construction de dispositifs pédagogiques sur des plateformes de
formation" (phD thesis, Université des Sciences et Technologie de Lille, 2007), p. 262.
S. Clarke, "Extending standard UML with model composition semantics", Sci. Comput. Program 44 (2002), 71-100.
Claroline, "Claroline.net - Open Source eLearning ", http://www.claroline.net/, pages consultées en octobre 2007
CMS, "CMS ", http://www.cmsmatrix.org/, pages consultées en octobre 2007
S. Kent, "ModelDrivenEngineering" 3rd Intl. Conf. on Integrated Formal Method-IFM 2002, ed. P. L. BUTLER M., SERE K.
(Turku,Finland, 2002Springer-Verlag), pp. 286-98.
MDA, MDA GUIDE Version 1.0.1 OMG, 2003, omg/2003-06-01, http://www.omg.org/docs/omg/03-06-01.pdf
P. Merrieu, "Un nouvel art d’apprendre" Intervention aux Entretiens de la Villette, (La Villette, Paris, France, 1999.
Moodle, "Moodle - A Free, Open Source Course Management System for Online Learning ", http://moodle.org/, pages consultées
en octobre 2007
A. Muller, O. Caron, B. Carré, G. Vanwormhoudt, "On some properties of Parameterized Model Applications" European
Conference on Model Driven Architecture (ECMDA), (2005.
A. Muller, O. Caron, B. Carré, G. Vanwormhoudt, S. Bouzitouna, "Ingénierie multimodèles : Projection flexible d’assemblages
de modèles" LMO, eds. I. Borne, X. Crégut, S. EbersoldF. Migeon (Toulouse, France, 2007Hermès Lavoisier), pp. 167-82.
D. A. Norman, The design of everyday things (New York, 2002), pp. xxi, 257 p.
G.
Paquette, "Introduction à la spécification IMS-LD. D’une perspective d’ingénierie pédagogique
http://helios.licef.teluq.uquebec.ca/residld/2/Introduction_à_IMSLD.doc, pages consultées en octobre 2007
",
PCDAI, "Monographie du projet PCDAI ", http://edutice.archives-ouvertes.fr/PCDAI/, pages consultées en octobre 2007
S. PCDAI, "Symposium Environnements numériques en formation professionnelle, 8 articles n° 314 à 318 et 372 à 376" congrés
AREF 2007, http://www.congresintaref.org/, (Strasbourg, 2007.
D. Peraya, Le cyberespace : un dispositif de communication et de formation médiatisées Cyberespace et autoformation, ed. A. S.
(1998).
P. Perrenoud, "La pratique pédagogique entre l'improvisation réglée et le bricolage, Essai sur les effets indirects de la recherche
en éducation", La formation des enseignants entre théorie et pratique, Éducation & Recherche 1983 (1983), 198-212.
Y. Peter, X. Le Pallec, T. Vantroys, Pedagogical Scenario Modelling, Deployment, Execution and Evolution Architecture
Solutions for E-Learning Systems, ed. H. Claus Pahl (PA, 2007).
G. Straw, G. Georg, E. Song, S. Ghosh, R. France, J. M. Bieman, "Model Composition Directives" UML’2004 :7th International
Conference on UML Modeling Languages and Applications, (Lisbon, Portugal, 2004Lecture Notes in Computer Science),
pp. 84-97.
Thot, "Thot ", http://thot.cursus.edu/, pages consultées en octobre 2007