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 PIM
PSM 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