Model Weaving and Pedagogy

Mapping Abstraction Levels in Instructional Design Languages

Esteban Loiseau, Pierre Laforcade and S

ebastien Iksal

Laboratoire d’Informatique de l’Universit

e du Maine,

Avenue Olivier Messiaen, Le Mans, France

Keywords:

Model Weaving, MetaModeling, Model Transformation, Instructional Design.

Abstract:

The GraphiT project aims at providing teachers with an operationalizable instructional design language. To

provide compatibility with existing e-learning platforms, the produced learning scenarios have to comply with

a platform speciﬁc metamodel. The issue addressed in this paper is about mapping high level pedagogical

elements captured from teachers’ practices to low-level platform features. We propose to use model weaving

to specify the mappings between different abstraction levels. Weaving models can then be used to generate

model transformations that will effectively perform modiﬁcations on the model at runtime.

1 INTRODUCTION

GraphiT is a research project funded by the French

research agency. Its main goal is to study the pos-

sibilities and limits of the pedagogical expressive-

ness of operationalizable visual instructional design

languages. The operationalizable property relates to

the possibility to exploit learning scenarios in Learn-

ing Management Systems(Chou and Liu, 2005). The

original approach of the project is to propose a plat-

form dependant architecture to guarantee compatibil-

ity. The challenge is about providing a pedagogically

relevant modeling language without adding features

to the targeted platform. We propose to address it

by building a multi-layered language where the ﬁrst

layer includes platform speciﬁc features and each sub-

sequent layer is a higher abstraction level. The project

methodology consists in exploring how Model Driven

Engineering and more particularly Domain Speciﬁc

Modeling(Kelly and Tolvanen, 2008) techniques and

tools can be relevant and useful to achieve our goal.

From a DSM point of view, the abstract syntax of the

language will be speciﬁed using a metamodel in the

Ecore format, the concrete syntax will make use of

the Graphical Modeling Framework from the Eclipse

Modeling Project.

2 RESEARCH CONTEXT

2.1 Visual Instructional Design

Languages

Educational Modeling Languages (EML), were the

ﬁrst generation of languages to allow formalization

of learning scenarios. IMS-LD (Botturi and Stubbs,

2008) is the de facto standard of this domain, but

has two main issues: it is mainly a machine under-

standable language (XML format) thus cannot be di-

rectly used by teachers, and it is currently not com-

patible with the main e-learning platforms (Moodle,

Ganesha. . . ). Visual Instructional Design Languages

(VIDL) address the ﬁrst issue by providing teachers

with a graphical notation (for example Flexo (Dodero

et al., 2010)) but the platform full compatibility issue

has yet to be tackled.

Previous works tried to achieve LMS compati-

bility through model transformations (Burgos et al.,

2007)(Abdallah et al., 2008) but suffered semantic

loss in the process. This issue appeared because the

instructional design language was designed indepen-

dently of the operationalizing system. By designing

our instructional design language with platform com-

patibility in mind in the ﬁrst place, we want to avoid

these semantic losses.

In this context, we aim at specifying a new VIDL

based on teachers needs and practices while providing

Learning Management System compatibility. With

regards to the ﬁrst point, we gathered information

Loiseau E., Laforcade P. and Iksal S..

Model Weaving and Pedagogy - Mapping Abstraction Levels in Instructional Design Languages.

DOI: 10.5220/0005003600810086

In Proceedings of the 9th International Conference on Software Paradigm Trends (ICSOFT-PT-2014), pages 81-86

ISBN: 978-989-758-037-6

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

from interviews and surveys from local teachers com-

munity. They expressed the need for a graphical tool

and language to design their learning scenarios, and

being able to import it on the Moodle platform.

2.2 Moodle

Moodle is one of the most wide spread Learning

Management System (LMS) in academic institutions.

Teachers use this platform to set up fully distant

courses or as an additional medium to teach in class-

rooms. Moodle is also the main e-learning platform

deployed in our university making it the priority target

of our system.

To achieve platform compatibility we rely on

a platform speciﬁc instructional design metamodel

(Abedmouleh et al., 2012). This metamodel includes

every pedagogically relevant concept found through

an identiﬁcation process including database and user

interfaces analysis. An API to import scenarios was

developed, based on the XSD schema extracted from

the previous metamodel. The API concretely parses

the XML based scenario and populates the database

according to it.

2.3 A Need for Mapping

The teachers we interviewed expressed some difﬁcul-

ties trying to set-up their previously designed learning

scenarios on the LMS. Each teachers community will

often have its own ”pedagogical language”, as well as

the platform. This ”translation” issue can be tackled

by mapping each concept from one language to one or

many concepts from the other. In this study we focus

on one community (local teachers) and one platform

(Moodle).

In fact, platform features can be seen as tools and

each tool can be used to implement many pedagog-

ical activities that teachers are used to work with.

This ﬁrst level of abstraction (pedagogical activity

from platform tool) was identiﬁed in a previous study

(Loiseau and Laforcade, 2013). This study identiﬁed

the relevance of one speciﬁc approach to model this

abstraction: extending the platform metamodel to in-

clude pedagogical activities from teachers practices.

In our current work we aim at generalizing this ab-

straction technique to several levels. The multiplicity

of these abstraction layers makes the mapping task

even more complex. The more obvious way to map

from one level to another is using model transforma-

tion, but considering the number of transformations to

write and the complexity of each mapping, we had to

ﬁnd a solution to reduce development costs.

2.4 Mapping examples

To illustrate our approach, we will use two examples

of mapping, simpliﬁed versions of real case pedagog-

ical elements.

The ﬁrst one is a pedagogical activity (a speciﬁc

use of one or many platform features): to complete the

Write A Report activity, students have to write a text

relating a real world activity they experienced, de-

pending on the course context. Several Moodle tools

could support this activity, but each one has speciﬁc

constraints, for example:

• Does the text have to be written online?

• Is it a group work (collaborative)?

• Does the text have to be written in one time or is

it more like a log (iterative)?

These properties depend on the pedagogical activity

the teacher wants to set up, and the appropriate tool

to use depends on these properties (conditional map-

ping). The decision table 1, explain how to choose

the right tool. Note that two options rely on the same

feature: assignment. The difference is ate the settings

of these tools, on the platform when creating an as-

signment you have to set many parameters including

whether students have to upload a ﬁle or write a text

online to complete the assignment. These parameter

settings have to be taken into account when designing

the mapping (parameter settings).

The second example is the Debate, it is a peda-

gogical pattern that will be mapped as following:

• Debate

– Label (platform tool)

– Exchange (pedagogical activity)

∗ Chat (if synchronous)

∗ Forum (if not)

The Debate will be mapped to an Exchange activity,

which in turn will be mapped to a Chat or a Forum

depending on the synchronous property. This exam-

ple illustrates once again the conditional mapping, but

also highlights the need to mix abstraction levels:

Debate is also mapped to a Label, an element from

an even lower level.

3 MODEL WEAVING

Model weaving can be deﬁned as ”the operation

for setting ﬁne-grained relationships between mod-

els or metamodels and executing operations on them

based on the semantics of the weaving associations

speciﬁcally deﬁned for the considered application do-

main.”(Di Ruscio, 2007)

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

Table 1: Write A Report mapping decision table (/ means either yes or no).

Journal Wiki Assignment (ﬁle upload) Assignment (online text)

Online Y Y N Y

Collaborative N Y / N

Iterative Y / / N

Model weaving produce a model, called weaving

model, linking several other models, called woven

models. The semantic of the weaving associations,

also referred as links or mappings, depends on the ap-

plication domain, but every type of weaving associa-

tion as to be deﬁned in a weaving metamodel.

The model weaving task can either be achieved

manually, by a domain expert through a weaving

model editor (or model weaver), or automatically us-

ing model matching algorithms.

In an example model weaving use case, the user

will weave two metamodels (source and target), then

execute a High Order Transformation on the weav-

ing model to produce a model transformation. This

transformation can then be applied to a source model

to obtain a model conforming to the targeted meta-

model. In this case, the weaving model captures the

transformation semantics.

3.1 Weave to Map

In our use case, users will design their learning sce-

nario at a speciﬁc level of abstraction then run a

model transformation to add the corresponding ele-

ments from a lower level to the global model. Run-

ning these transformations at each level will reﬁne the

model to the point where every element is linked to

elements from the lowest level (platform tools).

The weaving model will capture the mappings

between elements from different abstraction layers,

keeping track of what become what. This model will

be deﬁned together with pedagogical engineers and

teachers from the targeted community to ensure its

relevance regarding the pedagogical aspects.

Applied to our instructional design issues, the

model weaving process described in 3 can be used

to automate the generation of model transformations,

thus reducing the cost induced by their development.

4 MODEL WEAVERS

In the following subsections, we present two frame-

works to achieve model weaving. The ﬁrst one was

developed in an academic research context and the

second one is an adhoc use of several existing lan-

guages and tools from an Eclipse foundation project.

4.1 Atlas Model Weaver

Atlas Model Weaver (AMW) (Didonet Del Fabro

and Valduriez, 2009) is a model weaving framework

developed by the AtlanMod research team. It is

part of the ATLAS Model Management Architecture

(AMMA) platform.

The framework provides a reﬂexive weaving

model editor, a base weaving metamodel and numer-

ous use cases and examples: matching transforma-

tions, semi-automatic generation of weaving mod-

els. . .

In a typical model weaving application, users will

extend the basic weaving metamodel with its own

weaving associations semantic in KM3 (Kernel Meta

Meta Model) ﬁles; write a High Order Transformation

(HOT) in ATL(ATL Transformation Language); de-

ﬁne the weaving model with a domain expert and ex-

ecute the HOT to generate the ﬁnal ATL model trans-

formation.

AMW seems to be an appropriate model weav-

ing framework for our use case, as it fulﬁlls every re-

quirements we had. Unfortunately the project is not

supported anymore and several of its plugins depend

on outdated components of the Eclipse platform and

old versions of the Eclipse Modeling Framework.

4.2 Using Eclipse Epsilon to Achieve

Model Weaving

Epsilon (Paige et al., 2009) is a project supported

by the Eclipse foundation. It features multiple lan-

guages and tools to perform speciﬁc tasks on models:

model migration, model merging, Model-to-Model

and Model-to-Text transformations, model validation,

model comparison. . . Epsilon has a wide and active

community of users and developers and has a deep

compatibility with other frameworks from the Eclipse

Modeling Project.

Combining several languages and tools from the

Epsilon project, we were able to recreate a model

weaving toolchain similar to the AMW one while

beneﬁting from up to date compatibility with Eclipse

platform and modeling plugins.

One of the tools provided by Epsilon is Mod-

eLink, it is a 3-pane EMF-compatible model edi-

tor. The main feature of ModeLink is its ability to

ModelWeavingandPedagogy-MappingAbstractionLevelsinInstructionalDesignLanguages

capture links between different models using EMF

cross-source references. In combination with Exeed,

a reﬂective customizable model editor from Epsilon,

ModeLink can be used to weave heterogeneous mod-

els. Setting up the woven models on the left and right

panes and the weaving model in the center, one can

simply obtain a weaving model editor with no con-

straints on the weaving metamodel.

As writing High Order Transformation is a criti-

cal and complex task, we chose to take a different ap-

proach on generating the ﬁnal model transformations.

Using Epsilon model-to-text transformation language

EGL (Rose et al., 2008) (Epsilon Generation Lan-

guage) one can generate any text ﬁle, including model

transformations. EGL is a template based language,

similar to PHP or ASP, relying on the multi-purpose

language EOL (Epsilon Object Language). Consid-

ering that each transformation has a similar structure,

in our case, writing a template is an easier task: write

an example model-to-model transformation manually,

keep the ﬁxed section in the template and get variable

ones from the input weaving model.

Our application differs from traditional use cases

of model transformation: the transformation has to be

run while the model is being edited, the source and

target models are the same and the source elements

should be preserved by the transformation. To avoid

unnecessary copying of source elements in transfor-

mation rules, the simplest way to go was to imple-

ment rule body as an operation and run it as an EOL

program modifying the currently edited model.

5 MODEL WEAVING APPLIED

We propose to use the technical framework presented

in 4.2, to provide users with a ”mapping editor” (or

weaving editor) and a ”mapping execution” solution.

Figure 2 summarize the architecture of our proposi-

tion. Unlike the learning scenario editor, our weaving

editor does not directly target teachers as main users,

as it requires computer skills to understand how the

system operates.

To clarify the use of this mapping solution, here is

a typical use scenario: prior to distributing the learn-

ing scenario editor to teachers, a pedagogical engi-

neer along with a teacher from the targeted commu-

nity deﬁne their own mapping semantics using the

weaving editor. Once done, a computer engineer

will run the High Order Transformation to gener-

ate Model Transformations based on the weaving

model. The engineer will then integrate the transfor-

mations in the learning scenario editor. As explained

before, the generated model transformations will be

launched inside the learning scenario editor, at run-

time, to operate the mappings previously deﬁned in

the weaving model.

5.1 Weaving Metamodel

In order to deﬁne mappings for our instructional de-

sign language, we must ﬁrst specify a weaving meta-

model. The weaving metamodel has to be generic

enough to capture every mapping we already know

(fulﬁlling the requirements presented in 2.4) and po-

tential evolutions and additions. The ﬁgure 1 illustrate

our weaving metamodel proposition.

The Weaving Model is the root of the model and

contains many Bindings. Each Binding represents the

mapping of one element from the language to one or

many Targets. Each Target may have a Condition con-

trolling whether it must be added to the model or not.

These Conditions relate to the value of the source ele-

ment attributes and can be composed with logical op-

erators. Attributes of the Target element can be set to

constant values (SetAttr) or retrieved from source at-

tributes (BindAttr). Again, setting of these attributes

can be subject to conditions. Note that, since we are

weaving metamodels, the weaving metamodel only

references EClasses.

5.2 Weaving Model Example

Figure 3 is a screenshot of a ModeLink editor show-

ing the mappings of the examples from section 2.4.

These mappings were modeled using the metamodel

presented in 5.1. The central pane shows the weaving

model, with custom labels deﬁned with annotations

in the weaving metamodel. The left and right pan-

els (not shown here) display the metamodel of the in-

structional design language. By right-clicking on the

Weaving Model element, users can easily add more

bindings and set the source or target elements and at-

tributes by dragging and droping them from the left

and right panes.

Figure 3: Weaving model example.

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

Figure 1: Weaving metamodel.

Figure 2: Global architecture.

5.3 Generative Template

The generative template, expressed in EGL, replaces

the High Order Transformation as used in the AMW

framework. Code between [% tags is executable and

will be replace by the result of its evaluation in the

generated transformation. An excerpt of the template

is presented in ﬁgure 4.

6 CONCLUSION

We proposed a generic weaving metamodel, a high

order model-to-text transformation, and a speciﬁc

weaving model to capture mappings of pedagogical

elements from an LMS centered instructional design

language. We used an innovative model weaving en-

vironment making use of existing open-source lan-

guages and tools. We validated the expressiveness of

our weaving metamodel by testing it on real mapping

ModelWeavingandPedagogy-MappingAbstractionLevelsinInstructionalDesignLanguages

Figure 4: Generative template.

provided by teachers or from literature: from a textual

description of how to implement a particular activity

or pedagogical pattern on Moodle, we tried to design

an equivalent weaving model using our solution. The

few missing mapping features were then added to the

weaving metamodel.

6.1 Further Work

The learning scenario editor has to be tweaked in or-

der to automatically run the generated transforma-

tions, also high level elements still remain in the

model, breaking compatibility with the Moodle im-

port API. To circumvent this last issue, we will have

to write a global ”cleaning” transformation that will

delete these elements. Another issue is about struc-

ture blocks: teachers can structure their learning sce-

nario using sequences of activities but since mapping

transformations are run just-in-time and the high level

elements are kept, the global transformation will also

have to restore the general structure of the scenario,

replacing the sequences with their Moodle counter-

parts (sections, indented content etc.). Unfortunatly

we could not yet try the model weaver in real con-

ditions with real users, as they lack interest until a

suitable version of the learning scenario editor is re-

leased.

REFERENCES

Abdallah, F., Toffolon, C., and Warin, B. (2008). Mod-

els transformation to implement a project-based col-

laborative learning (pbcl) scenario : Moodle case

study. In 8th IEEE International Conference on Ad-

vanced Learning Technologies (ICALT 08), Santander

(Spain).

Abedmouleh, A., Oubahssi, L., Laforcade, P., and Choquet,

C. . (2012). Expressing the implicit instructional de-

sign language embedded in an lms: motivations and

process. In Computers and Advanced Technology in

Education, Naples (Italie).

Botturi, L. and Stubbs, S. (2008). Handbook of Visual Lan-

guages for Instructional Design: Theories and Prac-

tices. Gale virtual reference library. Information Sci-

ence Reference.

Burgos, D., Tattersall, C., Dougiamas, M., Vogten, H., and

Koper, R. (2007). A ﬁrst step mapping ims learning

design and moodle. Journal of Universal Computer

Science, 13(7):924–931.

Chou, S.-W. and Liu, C.-H. (2005). Learning effective-

ness in a web-based virtual learning environment: a

learner control perspective. Journal of Computer As-

sisted Learning, 21(1):65–76.

Di Ruscio, D. (2007). Speciﬁcation of Model Transforma-

tion and Weaving in Model Driven Engineering. PhD

thesis, University of L’Aquila.

Didonet Del Fabro, M. and Valduriez, P. (2009). Towards

the efﬁcient development of model transformations

using model weaving and matching transformations.

Software & Systems Modeling, 8(3):305–324.

Dodero, J. M.,

Alvaro Mart

ınez del Val, and Torres, J.

(2010). An extensible approach to visually editing

adaptive learning activities and designs based on ser-

vices. Journal of Visual Languages & Computing,

21(6):332–346. Special Issue on Visual Instructional

Design Languages.

Kelly, S. and Tolvanen, J. (2008). Domain-Speciﬁc Model-

ing: Enabling Full Code Generation. Wiley.

Loiseau, E. and Laforcade, P. (2013). Speciﬁcation of learn-

ing management system-centered graphical instruc-

tional design languages - a dsm experimentation about

the moodle platform. In ICSOFT’13, Reykjavik (Ice-

land).

Paige, R. F., Kolovos, D. S., Rose, L. M., Drivalos, N.,

and Polack, F. A. C. (2009). The design of a concep-

tual framework and technical infrastructure for model

management language engineering. In Proceedings

of the 2009 14th IEEE International Conference on

Engineering of Complex Computer Systems, ICECCS

’09, pages 162–171, Washington, DC, USA. IEEE

Computer Society.

Rose, L., Paige, R., Kolovos, D., and Polack, F. (2008).

The epsilon generation language. In Schieferdecker, I.

and Hartman, A., editors, Model Driven Architecture

– Foundations and Applications, volume 5095 of Lec-

ture Notes in Computer Science, pages 1–16. Springer

Berlin Heidelberg.

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends