This document discusses approaches to adaptation in educational modeling languages and describes a framework for late modeling of learning flows defined using PoEML. It introduces the concept of placeholders that allow parts of a learning flow to be left unspecified during design and modeled at runtime. The framework was implemented as a Moodle extension, including authoring, monitoring, and delivery modules. The implementation supports late modeling of PoEML learning flows while tracking individual learner instances. Future work includes adapting learning flows based on execution using instance and type adaptation.

1. Adaptation in a PoEML-based E-
learning Platform
Roberto Perez-Rodriguez
Manuel Caeiro-Rodriguez
Luis Anido-Rifon

2. Introduction
• Educational Modeling Languages (EMLs) enable
the definition of UoLs in a pedagogy-independent
way.
• An EML describes not only contents, but also
– Activities to perform
– Composition of groups of participants
– Order between activities
• These specifications conform a process.
• The PoEML language follows into this conceptual
model, and it was developed following a
separation-of-concerns approach.

3. Life-cycle of a Unit-of-Learning
• Authoring: in this phase,
the UoL is designed by
making use of an
authoring tool.
• Publication: the UoL is
imported into an
execution engine.
• Delivering: the
participants perform the
UoL. This phase is also
known as run-time.

4. Elements in an Educational Scenario in
PoEML

5. Hierarchical Educational Scenario

6. Late Modeling
• A main issue in the design of e-learning systems is that
of the adaptation.
• Late modeling allows for designers to leave some parts
of the UoL unmodeled until run-time.
– Often, designers may prefer to model the most relevant
parts of the UoL, remaining the rest to be modeled at run-
time.
• Therefore, it is required to support incomplete (or
abstract) models, which will be specified in run-time.
• This paper introduces a conceptual framework and a
software architecture for supporting late modeling of
PoEML learning-flows.

7. Common Approaches to Adaptation
• Approach centered in process definition meta-
model
– Advanced modeling
– Late modeling
• Approach centered in the execution system
– Type adaptation (evolutionary change)
– Instance adaptation (ad-hoc change)

8. Approach Centered in Process-
Definition Meta-Model
• In this approach, it is the process meta-model the one that
determines the structure and the allowed types of changes.
The following lines are considered:
– Advanced modeling
– Late modeling
• Advanced modeling allows authors to consider alternatives
during run-time.
– The different alternatives (learning paths) that are allowed
during execution are modeled in the process definition at
design-time.
– During run-time, it should be possible to select one of those
alternatives. There are two main ways to do the selection:
• In accordance with the state of execution.
• In accordance with the decision of an authorized participant.

9. Approach Centered in the Process-
Definition Meta-Model (ii)
• Late modeling allows for leaving some parts of
the design without being modeled, in order to
be modeled during run-time.
• Some parts of the process definition are
leaved as black-boxes, in order to be modeled
during execution.

10. Approach Centered in the Execution
System
• In this approach, it is the execution system the
one that supports the types of change that are
allowed.
• The following lines are considered:
– Instance adaptation
– Type adaptation

11. Approach Centered in the Execution
System (ii)
• Instance adaptation is usually named exception
management. An exception can be seen as an
occasional deviation from the normal behavior of
a process. Exception management is in charge of
correcting the wrong situation, without need for
stopping all process instances, fix the model, and
enact all the instances again.
• Type adaptation deals with process instance
migration during a process execution from an old
schema to a new one.

12. A Late Modeling Example

13. A Late Modeling Example (ii)
• The initial scenario.
• Once the initial
scenario is finished,
three scenarios are
launched in parallel.
• Finally, participants are
requested to perform a
collaborative activity,
which is evaluated by
the teacher.

14. A Late Modeling Example (iii)
• Order and Temporal
views of scenarios
• The teacher may want
to tune the model in
some ways:
– Adding more activities.
– Changing the temporal
constraints for activity
finishing.
– Adding/skipping a
goal, etc.

15. Late Modeling of PoEML Learning-
Flows
• Following an aspect-oriented approach, the
allowed changes in the model can be
systematically categorized in aspects, each
one dealing with an specific concern.
• A. Situating placeholders in the UoL model
– The approach here is to use a special type of
construct, named placeholder.
– The placeholder occupies the place of the
unmodeled element or specification.

16. Late Modeling of PoEML Learning-
Flows
– A. Situating placeholders in the UoL model.
– In PoEML, we identify the following placeholder types:
• Scenario placeholder. It is a black box that reserves space for a
scenario model. The language constructs will be added at run-time
in the space kept by the placeholder.
• Goal placeholder. It reserves the space for the definition of a
learning objective.
• Environment placeholder
• Tool placeholder
• Data placeholder. It is used for reserving the space to add
resources and/or activities to a UoL at run-time.
• Order placeholder. It keeps the space for adding ordering
constraints at run-time.
• Temporal placeholder. It enables the deferred definition of
temporal constraints in the Unit of Learning.

17. Late Modeling of PoEML Learning-
Flows
• B. Modeling black-
boxes at run-time
• When the execution
flow reaches a black-
box, the educational
scenario is
instantiated, but it
cannot progress
towards the accessible
state.

18. Late Modeling of PoEML Learning-
Flows
• A learning-flow with a
temporal placeholder
in the final scenario.
• At run-time the
teacher may fill the
placeholder by making
use of the authoring
environment.

19. Late Modeling of PoEML Learning-
Flows
• C. Updating of instances.
• Every learner who starts a learning-flow
enacts a new instance.
• Every learning-flow instance has its own state.
• When a teacher commits a change in the
learning-flow model, every instance has to be
re-evaluated from root to leaves in order to
update its state.

20. The Moodle Extension for PoEML
• A. The authoring environment
– The authoring process consists on a series of
atomic operations.
• Add/edit/delete a scenario
• Add/edit/delete a goal
• Add/edit/delete a resource/activity
– This authoring strategy presents some advantages
• Atomic changes are automatically seen by other co-
authors
• There is no need for a complex consistency check like
the one needed when importing a manifest file

21. The Moodle Extension for PoEML (ii)
• B. The run-time environment

22. The Moodle Extension for PoEML
• C. Monitoring
– Monitoring of a goal
• Possible states of a goal and number of students per state.
Histogram
• Detail of the status of a goal for every enrolled student

23. Implementation
• Overall architecture

24. Implementation
• A. The learning-flow engine
– It is the core component of the e-learning system
– Stores information on scenarios, participants,
goals, etc. and it makes the state of the system to
evolute depending on events
– This component is integrated through a well-
defined interface
– Two subcomponents:
• Models manager
• Instances manager

25. Implementation
• B. The middleware layer
– The functionality of the learning-flow engine is
published into a WSDL file.
• C. Presentation modules
– Three views:
• Authoring
• Monitoring
• Delivering

26. Conclusions
• This paper details the implementation of a late
modeling approach for PoEML
• Late modeling allows for leaving some parts of a UoL
model unspecified until run-time
• The aspect-orientation of PoEML presents great
advantages in supporting late modeling
• The combination of late modeling and advanced
modeling provides a high degree of adaptation
• Future work: to support adaptation based on the
execution engine
– Instance adaptation
– Type adaptation