Presentation from ICALT 2010 on the support of exceptions in CSCL

1. Roberto Perez-Rodriguez
Manuel Caeiro-Rodriguez
Luis Anido-Rifon
University of Vigo, Spain

2. Introduction
 The most common approach to provide online
education is based in courses as fundamental units to
deliver contents and provide communication facilities.
 Some Educational Modelling Languages (EMLs) such
as IMS-LD and PoEML provide a means to design and
run scripted courses
 Learning sequences or rich structures in which
participants are engaged

3. Introduction (ii)
 The life-cycle of an EML-based course is:
 Authoring-time
 Instantiation-time
 Run-time
 The problem with the above subdivision is that these
stages are overlapped in real-world practice
 During run-time a course may suffer deviations from the
designed behaviour during design-time, in order to
adapt itself to a new situation

4. Introduction (iii)
 In this paper:
 We make a review of the state-of-the-art of exception
management in scripted collaborative courses in terms
of process metamodel and execution metamodel.
 We propose an execution semantics to support run-time
changes in course instances, enabling thus the
resolution of unexpected exceptions.

5. Related Work
 IMS Learning Design
 This issue has not been seriously addressed.
 Coppercore provides neither mechanism for dynamic
modification of learning design nor support for the resolution
of abnormal situation.
 Workflow-based collaborative learning
 Approaches based on using a generic-purpose workflow
engine to enact collaborative courses rely on the capabilities
of the workflow engine of choice.
 Previous work from the authors use jBPM to enact learning
processes. Regrettably, jBPM does not provide mechanisms to
change process definitions at run-time.

6. Background: Analysis of Exceptions
in Scripted Collaborative Courses
 Exceptions are deviations from normal execution arising during a process.
 Classification of exceptions:
 Basic failures
 They are triggered by the underlying system
 Failure of the DBMS, failure of the operating system, network failure
 Application failures
 They are triggered by the groupware tools that are used at a task level
 An internal error in the groupware tool
 Expected exceptions
 They are triggered by the execution engine. This kind of exceptions may occur
frequently, therefore they need to be modelled and automated.
 A task has reached its deadline, a participant leaves a course in which he/she was
enrolled into, etc.
 Unexpected exceptions
 They are triggered by a human user when he/she detects that that the semantics of the
process definition does not fulfil the requirements.
 The course is over-dimensioned and the teacher wants to skip some tasks, the teacher
wants to correct the process schema, etc.

7. Background (ii)
 The exception life-cycle:
 Signalling: a software component or a human actor
detect the exception and signal it.
 Propagating: the exception signal propagates through a
typical layered architecture.
 Handling/resoluting: finally, the exception is handled by
a software component or an authorized user. Three types
of resolution are identified:
 Manual resolution
 Automatic resolution
 Mixed resolution

8. Our approach: Process Language
 We present a process language that is a subset of PoEML
(Perspective-oriented EML), and an execution semantics that
allows for run-time changes on the control flow.
 Process language:
 The process language provides the definition and format of data
involved in learning processes.
 The process language takes into account the expected exceptions.
 The most relevant elements in our process language are:
 Data element: it is a generic container for process variables. A data
element may store information such as a student’s grade, the age of a
student, etc.
 Data expression: it is a logic expression with a boolean output that takes
data elements (process variables) as inputs.
 Goal: it represents a functional objective. Its state can be directly
inferred from the value of certain data expressions.
 Scenario: it provides a context for the rest of elements.

9. Our approach: Execution Semantics
 A dynamic model is composed of the following parts
 Definition part: the process language
 Situation part: it captures information specific to a
particular situation
 Execution part: it defines the transition from one
situation to another one
 Change part: it defines how a process instance goes from
one state to another one due to a run-time change on the
process definition

11. Managing Process Instances in
Exception Resolution
 We describe two methods for dealing with unexpected
exceptions: ad-hoc changes, and dynamic changes.
 Ad-hoc changes:
 In certain cases, a unexpected exception can only be resolved by
modifying the process instance that triggered that exception
 Dynamic changes:
 They are changes in the process schema
 There are two usage scenarios:
 Create a new version of process schema: all process instances further
created will constraint to the new version of the model
 Update all process instances: for example, and exception caused by a
groupware tool no longer available will cause the failure of all process
instances that make use of that tool. In consequence, the exception
resolution entails to update all process instances

12. Conclusions
 Exceptions are not being adequately handled on
current approaches to scripted collaborative courses
 The main contribution of our approach to execution
semantics is to get rid of the dynamic change bug.
 In our approach, a process instance is characterized just
by its process variables, and it has no explicit state,
being possible to recalculate it after a run-time change.

13. Thank you for your attention!