EDUCON 2010: Adaptation in a PoEML-based E-learning Platform


Published on

Presentation from the 2010 IEEE Engineering Education Conference

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

EDUCON 2010: Adaptation in a PoEML-based E-learning Platform

  1. 1. Adaptation in a PoEML-based E- learning Platform Roberto Perez-Rodriguez Manuel Caeiro-Rodriguez Luis Anido-Rifon
  2. 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. 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. 4. Elements in an Educational Scenario in PoEML
  5. 5. Hierarchical Educational Scenario
  6. 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. 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. 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. 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. 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. 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. 12. A Late Modeling Example
  13. 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. 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. 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. 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. 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. 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. 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. 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. 21. The Moodle Extension for PoEML (ii) • B. The run-time environment
  22. 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. 23. Implementation • Overall architecture
  24. 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. 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. 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