Enforcing Learning Activities Policies in Runtime Monitoring System for E-learning Environments

8/4/2019 Enforcing Learning Activities Policies in Runtime Monitoring System for E-learning Environments

http://slidepdf.com/reader/full/enforcing-learning-activities-policies-in-runtime-monitoring-system-for-e-learning 1/9

Enforcing Learning Activities policies in Runtime

Monitoring System for E-learning Environments

Turki Alghamdi, Hussein Zedan, Ali Alzahrani

Software Technology Research Laboratory, De Montfort University Leicester, UK LE1 9BH

talgamdi,zedan,[email protected]

Abstract—Most educational institutes are involved with boththe e-learning and classroom-based learning methods. Nowadays,quality and flexibility properties become essential in learning.The classroom-based learning lack in flexibility but offers agood quality in learning process. On the other hand, developingthe e-learning system to meet the efficiency in both qualityand flexibility is the attention for researchers. To overcome

the deficiency in the quality property in e-learning system,we provide in this paper a runtime monitoring system whichbased on learning activities policy to attains both quality andmanageability properties with respect of flexibility property.Obviously, keeping track of learning activities performed bystudent can prevent problems that affect the student progress.In addition, learning activity policy can control the learningbehaviour of the student.

Keywords—Learning Activity, Policy, Runtime Monitoring,Student Tracking, VLE

I. INTRODUCTION

The recent growth of e-learning environments has made

them widespread in higher educational institutes and universi-ties all over the world. Currently, virtual learning environments

(VLE) have become widely adopted as a form of e-learning

system. VLE offers a large number of benefits, the most

important of which is flexibility of access: any time and from

any location with internet access [1]. Tracking or observing a

student is a fundamental component to any e-learning system.

The tracking component is not simply a fixed method that can

be adhered to any e-learning system; the tracking component

must reflect the specific requirements of the respective learning

activities in the e-learning system. In traditional learning envi-

ronments, teachers have a comprehensive view of the progress

of their students, and they provide immediate feedback and

personalized help. However, e-learning environments are more

anonymous and utilize tracking tools that only show the

number of activities performed by learners. Thus, teachers

of e-learning courses have difficulty translating the enormous

statistical reports into student behaviour, so they may not be

able to provide individualized assistance to the same degree

that traditional classroom teachers can [2].

Within the scope of this paper, we present the way that

teachers observe and support their students in the traditional

learning (classroom-based) environment, and we compare their

methods with the tracking tools in the e-learning environ-

ment and then we draw our motivation. Then, we present

the architecture of our runtime monitoring system with the

description of its components and the technology we want

to use. Moreover, we describe the key word ” policy ” in our

system and show the types of policies that can be adapted

to our approach. In section (V), we discuss a case study

about requirements in e-learning course and then we show the

formalisation of these requirements into numbers of policies.

In addition, we write an algorithm to show the monitoring

process specifically for our case study of quiz activity and the

enforcement of its policies. Finally, we conclude this paper

with future work to our approach.

II. E-LEARNING VS. CLASSROOM-BASED LEARNING

Educational research suggests [3]–[5] that in the e-learning

context, the students should be assisted and evaluated by an

instructor who, amongst other things, must monitor the stu-

dents’ learning progress continuously, understand their needs,

and provide feedback. To clearly explain the instructor’srequirements in terms of teaching, we provide thorough detail

of how the students are observed in the traditional learning

(classroom-based) environment, and then compare those ob-

servations to the current VLEs to determine which metaphors

can be adapted to the e-learning form.

1) Monitoring classroom-based learning (Reactivity): In

traditional classes, the teacher has more presence [6],

therefore the teacher has more control over the behaviour

of the students. All of the student activities are always

within the teacher’s view, including attendance, how

students adapt to the lessons, what difficulties the student

face, student progress, etc. A teacher in a conventional

classroom setting is able to notice the body language

of the students. Therefore, the teacher can immediately

respond to nonverbal cues, such as a reduction in student

interest or an unenthusiastic performance (e.g. a student

spends more time than normal performing a task, a stu-

dent does nothing, or a student does not collaborate with

his or her peers when working in a group. Additionally,

teachers in a traditional classroom setting are conscious

of class unity, such as how well the students understand

the lessons, how many students did the coursework, how

many resources the students utilized, who succeeded

(IJCSIS) International Journal of Computer Science and Information Security,

Vol. 9, No. 8, August 2011

45 http://sites.google.com/site/ijcsis/

ISSN 1947-5500



at completing a certain task, and so on. Teachers in a

traditional setting are normally required to ensure that

their students meet all requirements of the course they

are taking by being proactive in student development

in a timely manner. Because traditional teachers instruct

their students as a group, their learning sessions are more

interactive: students can help each other, the teacher can

conduct organized discussion groups, and the teacherand the students can come to a mutual understanding or

a group consensus over certain activities.

2) Monitoring the e-learning environment (anytime, any-

where): The major aim of e-learning environments is

to allow students access to the course at the times and

locations which are convenient for them, which, in turn,

encourages them to pass the course. Students participat-

ing in e-learning have the freedom to study and par-

ticipate in all activities. The drawback of this flexibility

and freedom is that instructors cannot personally interact

with the students as a group, so the performance and

behaviour of the learners is not as easily controlled, and

the absence of class unity may discourage an individual

student’s sense of accountability to the course policies.

However, most VLEs have a built-in functionality to

track, analyze and report e-learners’ activities [7]. Most

commercial VLEs (e.g. Blackboard and WebCT) and

free open source VLEs (e.g. MOODLE) have similar

tracking tools, which provide reports that include the

number of activities performed by learners and the types

of actions they have taken. The following list presents

some features of the student tracking tool in MOODLE

as reported in [8]:

• It provides reports that show the number of students

who access the course, the number of times the

course is accessed, the date of each access, and

the IP address of each student who accessed course

contents, discussion forums, course assessments,

and assignments.

• It provides a report that shows the number of

attempts by each student on an assignment and the

time spent on each attempt. Instructors can keep

private notes about each student in a secure area.

• Student tracking also provides a summary report of

each student’s performance on all assignments.

• The instructor can set a flag on particular course

components to track the frequency that learnersaccess those components.

• It allows the instructor to monitor learners who are

currently logged in to the course.

The features above show statistical data from large

logs of students’ activities, but the problem that this

comprehensive data that is presented to the instructors is

the burden of interpretation. Instructors must spend an

enormous amount of time studying the statistics in order

to translate them into behaviour patterns before they can

provide appropriate feedback to the learners.

III. MOTIVATION

In comparing the two methods of learning above, we can

find that in classroom-based learning methods the quality

and manageability properties of the course requirements are

met. The teacher in traditional classroom can ensure that

students accomplish all learning activities during the session

and also the teacher can manage to achieve applying all course

requirements to students and prevent any barriers that affectlearning process and achievement of student. In contrast, we

can figure out that in e-learning method the quality property is

less [9] .The instructor has less sense in understanding student

behaviour on doing learning activity. Thus, he or she can

not ensure student progress due to more flexibility and less

restrictions on doing these activities [10]. However, we can be

motivated according to all above that an effective tracking and

monitoring technique is needed immediately. The motivation

that is raised here leads us to have such technique that

attains more quality and manageability properties with respect

to flexibility property (as depicted in Fig 1) which already

exist in e-learning systems. Our motivation is summarized asfollowing:

• To have a runtime tracking and monitoring system that

keeps track of all learning activities performed by student

can prevent problems that affects the student progress at

proper time.

• Enforcing dynamic policy will let our system evaluate

all events that are associated with the learning activities

which are performed by the student, accordingly and

thus, a suitable assistance will be provided to the student

continuously.

• Monitoring student based on a policy at runtime will lead

the teacher to have more sense in understanding students’

behaviour since the learning activity policies( see Section

VI.E)can control the learning behaviour of the student and

our system can provide the teacher with feedback about

students state at particular learning activity.

Fig. 1. Motivation and Challenge.

IV. THE ARCHITECTURE

Our approach is to track and observe students’ learning

activities during runtime of e-learning environments. Our mon-

itoring mechanism keeps track of students’ learning activities

as well as the requirements that are represented by the learning

activity policies (see section IV.D) that are predefined by the

educational institution. We focus on how to detect the events




ISSN 1947-5500



that are associated with the learning activities in order to

ensure these events match the set of predefined policies. These

policies are expressed with respect to a set of learning activities

which must take place within the scope of a complex set

of rules (e.g. start time, duration, deadline, etc). Specifically,

the learning activity policies consist of a number of learning

activities with certain rules, (e.g. the predetermined duration

of certain quizzes and assignments). We consider some keypoints upon which some activity rules are dependent. For

example, some activities (e.g. assignment submission) may be

restricted to all students until they have achieved all necessary

prerequisites. Therefore, the key aspects of our approach are:

(a) how to detect e-learning activities, (b) how to formalise

and enforce the predefined activities policies on detected e-

learning activities and, (c) how to take supportive action

against students while they are logged into the e-learning

environment.

As shown in (Fig. 2), we divided our architecture into three

layers : Tracking layer, Runtime Validation layer and Action

layer.

Fig. 2. System Architecture.

A. Tracking layer

This layer aims to monitor and observe learning activities

that are performed by students. It has one component called

Observer that detects continuously and concurrently the data

about the learning activities (such as quiz, assignment, at-

tempts to access the course and so on) that are performed

by the student in the e-learning environment. The tracking

data collected by the observer component is stored in the

event repository. The event repository consists of tables that

contain the information about learning activities. Moreover,

they hold information about the students and the course which

the observed learning activities are associated with.Thus, tracking layer in our architecture is designed to ensure

that each event which is associated with a learning activity

is detected by the observer component once it occurred and

is stored in the event repository. The main functionality of

the observer component in this layer is to detect and collect

any possible data about learning activities. The task of this

component is to keep track of the changes in the detected

states of the learning activities frequently over the time, and

send a sequence of states to the event repository.

B. Runtime Validation layer

In this layer, our system will determine whether or not

the learning behaviour satisfies given policies by validating

these policies at the runtime. This process is a fundamental

part in our approach which is the ability to capture the

leaning behaviour of the student. As a policy reflects a set of

requirements about learning activities, satisfaction is achieved

by checking whether or not the learning behaviours (i.e.

sequence of events) satisfy these requirements. In addition,

we use a runtime validation technique based on AnaTempura

validation toolkit [11](see Fig 3) to accomplish the above

process. It is a tool for runtime validation of safety and timing

properties (more details about this tool are in section IV.E).

We have two components in this layer as depicted in Figure

2.These components are described below.

Fig. 3. AnaTempura Architecture [11].

1) Event Recogniser : Is used to collect an event from the

state information stored in the event repository by the Observer

in the previous layer. An event (i.e. a snapshot of states

that reflect the learning behaviour of a particular student)

is recognised according to the e-learning activity policy’s

attributes. The recognised events are then sent to the Checker

components.




ISSN 1947-5500



2) Checker : The Learning Activities Policies and the events

in the current learning activity state of the student are required

inputs for the Checker. Checker determines whether or not the

current learning behaviour of student satisfies the e-learning

activities policy. The behaviour is captured from a sequence

of events sent by the Event Recogniser. The Checker should

deal with history-based events that, in some cases, are based

on other previous events. Finally, the Checker sends feedback (e.g. Violation of the policy on particular events) to the Action

component in the instance that a student is in state which

violates learning activity policy.

C. Action layer

In this layer, there is one component which is interfaced

with the e-learning system. This component is called Action

component. Action component acts on student behaviour that

violates the policy determined by the Checker. Also, the

Action component will evaluate the obtained feedback from

the Checker and then specifies what type of action should be

taken against the student (e.g. warning messages or email tothe teacher describing the current state of a student) to prevent

potential problems that can affect student’s progress.

D. Learning Activities Policies

As mentioned earlier in this paper, a policy is a set of rules

which reflect particular requirements. In learning activities

context, it is a set of rules that ensure learning behaviours

and monitors students’ progress. The policies are specified in

term of learning activity type (e.g. Quiz, Assignment, etc...)

and specific requirements which student must meet during a

period of time. In most policy languages, rules are expressed

using authorisation, obligation rules.1) Rule Structure: Let S , O and A be the set of all subjects,

objects and actions in the system. Subjects denote students

or teachers and objects denote learning activity and actions

denote actions those subjects are performed on objects. For

the concrete syntax and semantics we refer the reader to

[12]. Some examples of these specifications are shown in

the case study section below. However, policy rules cannot

directly refer to the state of the system, but instead refer to

the occurrences of events in the system history. For the policy

language used, these events are done(s; o; a) representing the

successful execution of action a on object o by subject s,

autho(s,o,a) representing an access control decision. For the

purposes of this paper we are mainly interested to control the

learning activities that are performed by student rather than

in the actual semantics of the rule which are used in security

access control in policy-based management systems.

Authorisation The authorisation rule can express either

positive or negative access control. Positive rule means al-

lowances authorisation and negative rules means denials au-

thorisation. Both positive and negative rule may indicate

under which condition an access request should be granted or

denied. Thus, the authorisation rules are defined to express the

environmental policies if and only if the condition is system-

based and behavioural where a condition based on historical

behavioural of student.

Example There are three cases as following :

• Suppose that subject is a student ID SI D1234 and the

activity (object) is the quiz q2 and the action that should

be preformed is start :

true → autho(SI D1234; q2; start)

• Suppose that subject s is the student ID SI D1234 ,

the object o is the activity of quiz q1 and the action

a that should be preformed is start where the date is

30thofMay:

date(30/05)0 → autho(SI D1234; q2; start)

• Suppose that subject s is the student ID SI D1234 , the

object o is the activity of quiz q2 and the action a that

should be preformed is start where he/she has to have

quiz q1 already has done and submitted :

3done(SI D1234; q1; submit) → autho(SI D1234; q2; start)

Obligation Rules Obligation rules state an action that

performs where a specific action has been taken by a subject.

Generally, a student in the e-learning system or other subject

can perform the obligated action. In our contribution, the

obligation rules are defined to express the behavioural policies.

Example: Suppose that subject s is student SI D1234 and

the object o is the activity of quiz number 2 q2 and the action

a that should be preformed is start thus, the teacher T ID10must be notified for this action that taken by the sutdent.

2autho(SI D1234; q2; start) → Oblig(sys,TID10;notify)

E. Technology: Runtime Validation Toolkit ( AnaTempura)

Interval Temporal Logic (ITL) is a flexible notation for both

propositional and first-order reasoning about periods of time

found in descriptions of hardware and software systems. Un-

like most temporal logics, ITL can handle both sequential and

parallel composition, and offers powerful and extensible spec-

ification and proof techniques for reasoning about properties

involving safety (i.e. nothing bad will happen), liveliness and

timeliness [11]. Timing constraints are not only expressible,

but most imperative programming constructs can be viewed

as formulas in a slightly modified version of ITL. Alternative

formalisms that can be used are TLA (Lamport, 1994) or

Event Calculus [13]. In addition, ITL has an executable subset,

Tempura, which means that an interpreter for our learning

activities policies is readily available, if expressible in this

subset. Previous work [14] has successfully used Tempura

for the runtime verification of functional (safety) and real-

time properties. Since learning policies are, in essence, safety

properties, we can express them in Tempura.




ISSN 1947-5500



AnaTempura is a tool for runtime validation of timing and

safety properties (Fig 3). The runtime validation technique

uses assertion to check whether a system satisfies the safety

properties expressed in ITL [14]. The assertion in our

approach can be represented by Event Recognizer component

in our system architecture which sends a sequence of events

(learning activity states), such as values of variables, while

the software is running. Since an ITL property correspondsto a set of state sequences (intervals), runtime validation is

checking whether the sequence of events sent by our Event

Recogniser are a member of the set of rules corresponding to

the safety and timeliness properties represented by learning

activity policy that we want to check. The Tempura interpreter

is used to do this membership check [14]. So, we can use

AnaTempura as our runtime checker of e-learning activities

policy against events.

V. CAS E STUDY

We present a small simplified scenario that illustrates the

use of our dynamic tracking policy for learning activities.

Scenario: The faculty of technology, department of

computer science in De Montfort University provides a

distance learning course of MSc in software engineering

for distant students through e-learning environment. This

course has four modules in semester one with duration of 12

weeks .One of these modules is formal methods which has

number of learning activities (such as quizzes , assignments,

learning materials, discussion forums ,etc ...). The distant

students must participate in all learning activities and perform

them to meet the course requirements and achieve the

modules successfully. In addition, these activities examine theperformance and understanding of students and assist them

to acquire all expected outcomes from the module. We focus

in this scenario on quizzes and assignments activities as there

are six quizzes and three assignments that are required over

the semester one. However, due to the flexibility of access to

the modules, participation in and accomplishment of these

activities are monitored and controlled by a policy with a

number of requirements as following:

1) Quizzes have to be done all in sequence during the

session of the module.

2) Student cannot start quiz or assignment until the previ-

ous one has finished.

3) The assignment is due after two quizzes have been done

and cannot be submitted before and so on.

4) Student can not submit assignments after the deadline.

5) Each quiz has a limited period of 10 days for comple-

tion.

6) Each quiz has total marks of 25 and the performance of

student in doing the quiz can be indicated as following:

• Mark form 0 to 10 denotes bad performance.

• Mark from 11 to 20 denotes normal performance.

• Mark from 21 to 25 denotes very good performance.

7) Each quiz has duration of 30 minutes for student to do

and the progress of student on doing the quiz can be

indicated as following:

• Time in minuts form 0 to 10 denotes fast progress.

• Time in minuts from 11 to 20 denotes normal

progress.• Time in minuts from 21 to 30 denotes slow progress.

In the following we will formalise the requirements above

as rules and then we will show how these rules as policies

reflect these requirements. However, our learning activity

policies we will construct in the following will be a mixed

policies based on the types of rules we mentioned in (section

IV.E).We will also use the structure we stated above in

constructing these policies.

The requirements 1 and 2 above can be formalised as

follows firstly for the quiz activity:

Policy1 =

fin (T imeUnit < 12)∧Student (S,M odule)∧Quiz(Qn, Module)∧

n −1

i =03done (S, Qi, Submit)

−→

Autho+(S, Qn, Submit)

Where student S and Quiz Qi are members of the module

.However, if TimeUnit in the last state of the interval is less

than 12 which denotes the number of weeks in the session,

and sometime over the states the previous quiz is already done,

then in the next state , the student is allowed to submit the

quiz Qi.

Policy2 =

fin (T imeUnit < 12)∧Student (S, Module)∧

Assignment(An, Module)∧n −1

i =03done (S, Ai, Submit)

−→

Autho+(S, An, Submit)

The policy above is similar to the previous one but now for

the assignment activity.

Policy3 =(currentDate ≤ deadline)∧

done (S, Qi∗2, Submit)∧done (S, Qi∗2+1, Submit)∧

−→ Autho+(S, Ai, start)The above policy represents the requirements 3 in our

scenario where the student S is authorized to start the

assignment Ai when the previous two quizzes Qi∗2 and

Qi∗2+1 have been done firstly. For example, if student wants

to start the second assignment A1 , then the third quiz Q2

and fourth quiz Q3 (as quizzes in our scenario are six quizzes

Q0, Q1, Q2, Q3, Q4andQ5 ) must be done before.

The requirement 4 can be represented in the following

policy:




ISSN 1947-5500



P olicy4 =(currentDate > deadline)

−→

Autho−(S, Ai, Submit)

Where the student is not authorized to submit the assign-

ment after the deadline.

Requirements 6 and 7 indicate the progress and performance

of the student on doing the quizzes, teacher should be notified

if the performance is bad and the progress is fast or slow. This

can be represented by formalising the following policy:

P olicy5 =

done (S, Qn, Submit)∧( performance = Bad)∧( progress = Slow)∨( progress = Fast)

−→ (Oblig(Sys,Tid,Notify))

This policy above will ensure the behaviour of the student

on doing the quiz from the time he or she spent and the

total mark obtained. Our monitoring system will recognizethe performance based on the total mark obtained, and the

progress according to the time spent on doing the quiz, then an

obligation policy will be enforced to notify the teacher when

student’s progress (for instance) is fast but the performance is

bad, so the teacher can know the student state in proper time

to provide appropriate assistance.

After formalising our policies for the quizzes and assign-

ments based on requirements in our case study, in the follow-

ing we draw an algorithm to show the monitoring process and

how these polices above will be enforced.

A. Monitoring process and policy enforcement algorithm

The algorithm shows the monitoring process and the

enforcement of the learning activity policies in the runtime

validation layer for above scenario of quiz activity. It is based

on the state transition diagram as depicted in (Figure 4).The

main task of the algorithm is to monitor the events occurred

in the quiz activity from opening it and selecting a specific

quiz until closing the activity, and to enforce an applicable

policy accordingly based on the current state of the quiz

activity.

The algorithm (1) below shows how the monitoring process

for the quiz activity moves from state to state. We first define

global variables that are used in the whole process. Then, wedefine the mine state of this process which is Active. The

Variable QSatate denotes the current state of the quiz activity

in our monitoring process. The Active state has sub-states

(Active = {SelectingQ, DoingQ, DoneQ, N otDoneQ, }{Aborted, Cheated}) and its initial state is Inactive.

Moreover, the monitoring process and enforcement of the

policies are done through functions that are represented below

in algorithm (1) where they all take the current selected quiz

(Quiz[n]) as input parameter.

Fig. 4. STD for Quiz policy enforcement.

Algorithm 1 Check Quiz Activity

Require: Quiz[n],QuizTM,StartT,SubmitT,NoOfQuizzes, QuizDur,QState, T Left, SpentT,SelectedQ, Mark, QProgress, QPerform

Ensure: n ∈ NoOfQuizzes1: Active is main State!, Inactive is Initial state!2: for QState = Active do

3: (SelectingQ, DoingQ, DoneQ, N otDoneQ,AbortedQ, CheatedQ) are substates!4: NotDoneQ is Initial Substate!5: for QState = SelectingQ do

6: (GettingP ermit, Allowed, Denied)areSubstates!

7: GettingPermit is Initial Substate!8: end for

9: end for

10: repeat

11: SelectedQ = CurrentQuiz()12: if n = SelectedQ then

13: QState = Active14: CheckPermission(Quiz[n]) // Moving to Select-

ingQ state!

15: CheckDoingQ(Quiz[n]) // Moving to DoingQ state

or CheatedQ state!

16: CheckSubmission(Quiz[n]) // Moving to DoneQ !

17: CheckProgress(Quiz[n])18: CheckPefromance(Quiz[n]19: QState = Inactive // Final State in this process!

20: end if

21: until QState = Inactive




ISSN 1947-5500



The algorithm (2) is sub-algorithm of the main one

(algorithm 1) which shows the process of the function

CheckPermission(). The task of this function is to check

whether or not the student is allowed to access the current

quiz. Its inputs are the applicable policy from the policies

repository and the events that corresponds to policy attributes

.Therefore, The enforcement of the policy in this function will

result whether the student is allowed to access the current quizand do the quiz, or denied to access and thus the monitoring

process here will end by assigning the quiz’s state to Aborted.

In addition, the sequence diagram in (Figure 5) can represent

the process in this function in details according to system

components in the system architecture as depicted above in

(Figure 2 ).

Algorithm 2 CheckPermission(Quiz[n])

Require: Quiz Policy for permissionEnsure: Events corresponds to the Policy attributes

1: if QState[Quiz[n]] = CheatedQ∧ DoneQ ∧AbortedQ

then2: QState[Quiz[n]] ← SelectingQ3: Qpermission[Quiz[n]] ← GettingPermit // Moving

to GrttingPermit state!

4: GetQuizPolicy(Quiz[n]) // Find applicable Policy

from the repository!

5: return PolicyX 6: GetQEvents(Quiz[n])7: return SequanceofEvents!8: TLeft = CurrentTime() − QuizDur9: CheckPolicyV.S.Events

10: if Policy is Satisfied then

11: Qpermission[Quiz[n]] ← Allowed12: QState[Quiz[n]] ← DoingQ // Moving to DoingQ

state!

13: StartT = CurrentTime();14: else

15: QPermission[Quiz[n]] ← Denied16: QState[Quiz[n]] ← Aborted17: end if

18: end if

The sub-algorithm (Algorithm 3) represents the process of

the function CheckSubmission(). Its task is to check the

submission state of the current quiz. The enforcement of an

applicable policy for this case will result whether or not the

current quiz is done otherwise it becomes cheated quiz. For

instance, the policy restricts the student to do the quiz once

and if he or she has started to do the quiz and quit from the

quiz, then student will be dealt as cheater and thus he or she

cannot do this quiz again.

However, as mentioned before this algorithm is suggested

to show the monitoring process and the enforcement of quiz

activity policies only for this case study. This algorithm can

Algorithm 3 CheckSubmission(Quiz[n])

Require: Quiz Policy for SubmisstionStateEnsure: Events corresponds to the Policy attributes

1: if QState[Quiz[n]] = DoingQ then

2: GetQuizPolicy(Quiz[n]) // Find applicable Policy

from the repository!

3: return PolicyY

4: GetQEvents(Quiz[n])5: return SequanceofEvents!6: SubmitT = GetSubmitT ime7: CheckPolicyV.S.Events8: if Policy is Satisfied then

9: QState[Quiz[n]] ← Done // Moving to Done state!

10: else

11: QState[Quiz[n]] ← Cheated12: end if

13: else

14: QState[Quiz[n] ← Idle15: end if

work in the runtime validation layer in our system architecture.

V I. CONCLUSION AND FUTURE WOR K

In this paper we have presented the runtime monitoring

system based on learning activities policies for e-learning

environments. A comparison between two learning methods

(e-Learning and Traditional learning) has been discussed. We

have shown the system architecture and we described its

components in details including the purpose of learning activ-

ities policies. Moreover, a case study was described to showthe formalisation of a number of requirements for learning

activities. Moreover, the tracking process and the enforcements

of policies in the case study have been shown in algorithm of

quiz activity.

However, we are currently developing a generic algorithm

of tracking process and policies enforcement for all possible

learning activities in the e-learning environments. In addtion,

we will develop a prototypical system to evaluate our algo-

rithm on one of e-learning environments such as MOODLE.

REFERENCES

[1] A. Al-Ajlan and H. Zedan, “Why moodle,” Future Trends of Distributed Computing Systems, IEEE International Workshop, vol. 0, pp. 58–64,2008.

[2] F. Buendı́a, J. C. Cano, and J. V. Benlloch, “An instructional approach todrive computer science courses through virtual learning environments,”in ITiCSE ’09: Proceedings of the 14th annual ACM SIGCSE conference

on Innovation and technology in computer science education. NewYork, NY, USA: ACM, 2009, pp. 6–10.

[3] S. W. Jude Lubega, Lily Sun, “An effective tracking model for person-alised e-learnin.” Paris, France: 3rd European Conference on e-Learning(ECEL), 2004.

[4] A. Juan, T. Daradoumis, J. Faulin, and F. Xhafa, “Developing an infor-mation system for monitoring student’s activity in online collaborativelearning,” in Complex, Intelligent and Software Intensive Systems, 2008.CISIS 2008. International Conference on, march 2008, pp. 270 –275.




ISSN 1947-5500



Fig. 5. Quiz Tracking process.

[5] B. Zeng, J. Nie, and J. Wei, “Design for active monitor system indistance learning environments,” in Education Technology and Computer

Science, 2009. ETCS ’09. First International Workshop on, vol. 2, march

2009, pp. 809 –813.[6] L. France, J.-M. Heraud, J.-C. Marty, T. Carron, and J. Heili, “Mon-

itoring virtual classroom: Visualization techniques to observe studentactivities in an e-learning system,” in Advanced Learning Technologies,2006. Sixth International Conference on, july 2006, pp. 716 –720.

[7] R. Mazza and V. Dimitrova, “Coursevis: A graphical student monitoringtool for supporting instructors in web-based distance courses,” vol. 65,no. 2, 2007, pp. 125 – 139.

[8] S.-C. Pan, “Teachers’ perceptions in the development of onlinek-12 courses,” in Proceedings of Society for Information Technology &Teacher Education International Conference 2009, I. Gibson, R. Weber,K. McFerrin, R. Carlsen, and D. A. Willis, Eds. Charleston, SC,USA: AACE, March 2009, pp. 3096–3099. [Online]. Available:http://www.editlib.org/p/31120

[9] J. T. Lubega and S. Williams, “A study of factors contributing to thelate submission of course work,” European Journal of Open Distance

and E-leaming (EURODEL), 2006.[10] A. M. B. S. Hardy, J., “E-learner tracking: tools for discovering learner

behavior,” vol. Vol. 9, no. No.4, 2004, pp. pp.437–69.

[11] A. Cau and B. Moszkowski. (2011) Interval temporal logic.ITL Homepage. Retrieved in May 09, 2011. [Online]. Available:://www.cse.dmu.ac.uk/STRL/ITL/index.html

[12] H. Janicke, “The development of secure multi-agent systems,” Ph.D.dissertation, De Montfort University, 2007.

[13] R. Kowalski and M. Sergot, “A logic-based calculus of events,” NewGen. Comput., vol. 4, pp. 67–95, January 1986. [Online]. Available:http://portal.acm.org/citation.cfm?id=10030.10034

[14] S. Zhou, H. Zedan, and A. Cau, “Run-time analysis of time-criticalsystems,” vol. 51, no. 5. New York, NY, USA: Elsevier North-Holland,Inc., 2005, pp. 331–345.

AUTHORS ’ PROFILES

Turki Alghamdi is a PhD student in the Soft-ware Technology Research Laboratory (STRL) atDe Montfort University, Leicester UK. He receivedthe bachelor’s degree (BSc in Computer Science) in2005 from University of Taif, Taif, Saudi Arabia.He received the master’s degree (MSc in SoftwareEngineering) in 2008 from University of Bradford ,Bradford UK.

Professor Hussein Zedan is the Technical Directorof the Software Technology Research Laboratory(STRL) at De Montfort University, UK. His researchinterests include formal methods, verification, se-mantics, critical systems, re-engineering, computersecurity, CBD, and IS development.




ISSN 1947-5500



Ali Alzahrani is a PhD student in the SoftwareTechnology Research Laboratory (STRL) at DeMontfort University, Leicester UK. He received thebachelor’s degree (BSc in Computer Science) in2002 from King Abdulaziz University, Jeddah, SaudiArabia. He received the master’s degree (MSc inInformation Technology) in 2008 from QueenslandUniversity of Technology (QUT), Brisbane , Aus-tralia.




ISSN 1947-5500

Documents

Enforcing Learning Activities Policies in Runtime Monitoring System for E-learning Environments