Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

The progress engine controls the progress of a lesson. When a learner starts a lesson or moves from activity to activity, it is the progress engine guiding their way. Without the progress engine, LAMS isn't LAMS.

This page covers some background to the progress engine, the overall system design as well as the implementation algorithm.

Background

To understand the progress engine, it is necessary to review some background concepts that related to LAMS progress engine. The main purpose of this section is to let new developers to understand the e-learning concept behind the design of progress engine and what progress engine is doing from user's point of view. If you knows LAMS concept already, please feel free to skip this section.

Learning Design
The concept of learning design has been defined in the IMS specification. The LAMS learning designs are not described in the same way as learning designs in the IMS standard, but the concept is the same. From progress engine's perspective, learning design defines a sequence of collaborative learning activities and tools required to support these activities. It defines the basic navigation rules that progress engine should cope with. Learning designs are also known as "sequences" as main structure of a learning design is a sequence of Activities, rather than a set of unordered Activities.

Activity
An Activity is the major element of a learning design. In another words, it is main learning object that sits inside the learning design. From progress engine's point of view, activities are the nodes of the sequence that the engine needs to navigate through. Generally they are a "box" of some kind on the learning design picture.

Lesson
While a learning design is a reusable template, the lesson is one instance that using the learning design template. A lesson should have a number of participating learners (see Lesson Class), who are going to do the activities that are defined in a learning design. Therefore, data that is involved in the learning design instance of a particular lesson should not be shared across lessons. In terms of progress engine, the start of a lesson is the trigger of the progress engine. At this point, progress engine should initialise any resources of the learners.

Learner Progress
The learner progress is the data holder that records the progress status of runtime learning design instance. In other words, learner progress record where the learner is in a lesson. Therefore, learner progress has to be specific to a particular learner and a particular lesson.

Learner Progress Bar
The learner progress bar is a graphical representation of a user's progress. It appears in three forms - a vertical Flash component that sits on side of the LAMS learner GUI interface or a non-Flash tree structure that overlays the LAMS learner GUI interface, and the horizontal Flash layout used in the the LAMS monitoring GUI interface. These give a user friendly graphical representation of where a learner is in the learning design.

Lesson Class
The lesson class is the group of users who will participate in the lesson. Some users are assigned learner (or participant) status, which gives access to the Learner interface. Some users are given Staff status, which gives them access to the Monitoring interface.

Progress Engine History

The LAMS 2.0 progress engine is the third version of the algorithm of progressing the learning design since the born of LAMS software. LAMS has gained lot of lessons from previous implementation in terms of scalability and maintainability. Before documenting the current design, it is handy to review the experience and pitfalls from previous versions.

The first version of LAMS progress engine is based on JMS asynchronous messaging. This approach has been referred to a Polling. Under the polling architecture, instead of LAMS itself to figure out what is the next activity for the learner, the client side (essentially the Flash component) drive the progress engine to keep moving by keep sending message to the server. This approach works fine if the number of concurrent learners is very small. However, once we moved onto the loading testing stage of LAMS application, the overhead generated by client messaging quickly becomes the major bottleneck that halted the whole system. The high concurrency nature of progress engine decides asynchronous messaging is not a suitable technology choice for LAMS.

This was then replaced with an approach that completely removed the overhead result from polling architecture, which make it possible for LAMS to scale under hundreds of concurrent users. However due to the lack of proper data structure to hold the learner's progress status, the Flash learner progress bar has to request the server to go through the entire learning design to calculate the exact position for display. Profiled showed this calculation consumed 65% of the system resources. The bigger the learning design is, the more resources need to be consumed by this profiling. Even worse, this calculation needs to be done every time when each learner wants to progress to next activity. Consequently, designing a flexible data structure that holds necessary progress data becomes the major rationale we followed in LAMS 2.0 Progress engine.

Domain Object Model


Figure 1 Lesson related domain object diagram

The above diagram is a fragment of the entire domain object diagram to illustrate the object model design to handle lesson related learner progression. As you can see, there are four major aggregated components for a lesson:

  1. LearningDesign - It defines the major learning sequence that students in a lesson should complete.
  2. LessonClass - It holds all the students information who are participating a lesson. It is also a special grouping type in LAMS to perform class based learning tasks.
  3. LearnerProgress - It records the progress data for each learner. One lesson should have 0 or many learner progression. Every student should only have one learner progress record. This makes it possible for a teacher to monitor all students progression status.
  4. ToolSession - As you already know, learning design is a static aggregation of learning activities. Each activity refers to a tool session record that holds the runtime data for the activity.

Database Design


Figure 2 Lesson related database design

Figure 2 is a fragment of database model that illustrate the database structure mapping to the object model we discussed in the last section. As the major inheritance mapping we adopted is "Table per class hierarchy", the above diagram appears to simpler than the object model we shown in the last section.

Lesson States

The lesson passes through a number of states. The states are defined in the Lesson class.


Figure 3 Lesson States

Lesson State

Description

CREATED

A newly created lesson. The learning design has been copied. The lesson class may or may not have been configured. The lesson is shown on the staff interface but not on the learning interface.

NOT_STARTED_STATE

A CREATED lesson may be scheduled to start at a particular date. When it is schedule, state is set to NOT_STARTED_STATE for lessons that have been scheduled. The lesson is shown on the staff interface but not on the learning interface.

STARTED_STATE

The lesson has been started. The lesson is shown both the staff interface and learner interface. Whilst in this state, the learners can participate in the lesson.

SUSPENDED_STATE

A lesson that is in STARTED_STATE may be suspended. While suspended, the lesson can be seen on the staff interface but not on the learning interface. When the lesson is no longer suspended, it returns to STARTED_STATE.

FINISHED_STATE

The state for lessons that have been finished. A finished lesson is shown as inactive on the staff interface, and is shown on the learner interface but the learner is to only see the overall progress and be able to export data - they should not be able to interact with the tools.

ARCHIVED_STATE

The state for lessons which are shown as inactive on the staff interface but no longer visible to the learners.

DISABLED_STATE

The state for lessons that are removed and never can be accessed again

Progress Engine from the Teacher's Perspective

Use Cases

Primary Actor

Use Cases

Teacher

Create and Start Lesson

Teacher

Create Lesson

Teacher

Start Lesson

Teacher

Force Complete Learner

Teacher

Live Edit

Use Case Name:

Create and Start Lesson

Actors:

Teacher

Description:

The teacher creates a lesson for a learning session.

Preconditions:

The teacher loads up the "Add Lesson" interface.

Postconditions:

  1. A lesson gets created.
  2. A copy of learning design for lesson gets created.
  3. A copy of tool content gets created.
  4. A new lesson class is created.
  5. Progress engine data such as the tool sessions is initialised.

Normal Flow:

  1. Teacher clicks on the Add Lesson button. Each Add Lesson button is association with an organisation and this will become the organisation used to display the list of potential users, and be associated with the lesson.
  2. Teacher selects the learning design he wants to run for the new lesson and clicks Next.
  3. Teacher select the users who will be in the lesson and clicks Next.
  4. Teacher types in the title and description for the lesson.
  5. Teacher clicks on the Start Now to tell LAMS to create lesson.
  6. LAMS initialises the lesson:
  • Creates a read only copy of the learning design, of type COPY_TYPE_LESSON
  • LAMS notifies all tools that involved in the learning design to create a copy of their content for lesson.
  • Creates a new lesson for the copied learning design (without a lesson class), associated with the selected organisation. Lesson status is set to Lesson.CREATED.
  1. LAMS creates the LessonClass, based on the list of users supplied by the GUI, and associates it with the lesson.
  2. LAMS starts the lesson
  • Goes through all the non-grouped tool activities and initialises the tool sessions.
  • Goes through all the scheduled based activities and start scheduler of each task if necessary.
  • Goes through all the branching activities and assigns it a grouping (if one doesn't exist) so that the users in the branch can be tracked.
  • Marks each activity as initialised. This is needed later for Live Edit.
  • Sets lesson status to Lesson.STARTED_STATE


Use Case Name:

Create Lesson

Actors:

Teacher

Description:

The teacher creates a lesson for a learning session and starts it ready for use.

Preconditions:

The teacher loads up the "Add Lesson" interface.

Postconditions:

  1. A lesson gets created.
  2. A copy of learning design for lesson gets created.
  3. A copy of tool content gets created.
  4. A new lesson class is created.

Normal Flow:

  1. Teacher clicks on the Add Lesson button. Each Add Lesson button is association with an organisation and this will become the organisation used to display the list of potential users, and be associated with the lesson.
  2. Teacher selects the learning design he wants to run for the new lesson and clicks Next.
  3. Teacher select the users who will be in the lesson and clicks Next.
  4. Teacher types in the title and description for the lesson.
  5. Teacher selects on the Schedule or Start In Monitor to tell LAMS to create lesson but not start the lesson.
  6. LAMS initialises the lesson:
  • Creates a read only copy of the learning design, of type COPY_TYPE_LESSON
  • LAMS notifies all tools that involved in the learning design to create a copy of their content for lesson.
  • Creates a new lesson for the copied learning design (without a lesson class), associated with the selected organisation. Lesson status is set to Lesson.CREATED.
  1. LAMS creates the LessonClass, based on the list of users supplied by the GUI, and associates it with the lesson.
  2. If the teacher selected Start In Monitor, the lesson is left as Lesson.CREATED. If the teacher scheduled the lesson, then a scheduler task is set up to start the lesson automatically and the lesson status is Lesson.NOT_STARTED.


Use Case Name:

Start Lesson in Monitoring

Actors:

Teacher

Description:

The teacher starts a lesson that was created previously.

Preconditions:

The teacher loads up the "Monitor" interface.

Postconditions:

  1. Progress engine data such as the tool sessions is initialised.

Normal Flow:

  1. Teacher clicks on the Start Now button.
  2. LAMS starts the lesson
  • Goes through all the non-grouped tool activities and initialises the tool sessions.
  • Goes through all the scheduled based activities and start scheduler of each task if necessary.
  • Goes through all the branching activities and assigns it a grouping (if one doesn't exist) so that the users in the branch can be tracked.
  • Marks each activity as initialised. This is needed later for Live Edit.
  • Sets lesson status to Lesson.STARTED_STATE

Similarly to the previous test case, if the lesson is scheduled, LAMS will do the same "start the lesson" process automatically at the correct time. The teacher may also go into the Monitoring interface and do "Start Now" on a scheduled lesson, or set up scheduling on a non-started lesson.

Use Case Name:

Force Complete

Actors:

Teacher

Description:

The teacher moves a learner from one part of the lesson to another part of the lesson.

Preconditions:

The teacher loads up the "Monitor" interface and brings up the sequence tab. The learner is partway through the lesson.

Postconditions:

  1. Learner's progress is updated

Normal Flow:

  1. Teacher finds the learner's icon on the learning design diagram, then clicks and drags the learner's icon to a later activity, or to the "finished" bar at the end of the screen.
  2. If the teacher dragged to the icon to a later activity, the call to the server passes the activity id of the activity just proceeding the selected activity (ie the "last" activity to be marked as completed"). LAMS then processes the learner's path through the design to the nominated activity using the progress engine to determine the next task. Along the way, LAMS will create tool sessions and do branching calculations as required. Once the "last" activity is reached, the learner is started on the next activity. This gives the affect of moving the user to the nominated activity.
  3. If the teacher dragged the icon to the finished bar, the call to the server does not pass any activity id. LAMS will process the learner's path to the end of the learning design.
  4. In either case, LAMS obeys the normal "stop" mechanisms. For example if the user reaches a permission gate that is shut, or a chosen grouping but has not been grouped, then the processing will stop and LAMS will return the current activity id of the activity where the user is stopped. Also, LAMS only marks the user's progress as completed - it does not call the tool and tell the tool that this user has completed the activity. Therefore if the learner returns to the activity later they will complete the activity the same as normal (e.g. in MCQ they will get to answer the questions).


Use Case Name:

Live Edit

Actors:

Teacher

Description:

The teacher makes a small change to the learning design of an existing lesson. Note: this is only designed for quick changes to the learning design structure, not large scale changes. If only the content of an activity is to be changed, it should be changed via the activity's screen in monitoring.

Preconditions:

The teacher loads up the "Monitor" interface and brings up the sequence tab.

Postconditions:

  1. The learning design attached to the lesson is updated.

Normal Flow:

  1. Teacher clicks Live Edit, and confirms that they wish to edit the learning design.
  2. LAMS sets up the design ready for editing. As authoring will not allow a user to edit a read only design, edit override flags are set. To stop users moving through parts of the sequence that are being edited, a temporary stop gate is added after the last activity attempted by a learner.
  3. The monitoring client is "replaced" by a cut down version of authoring. The teacher is able to change any part of the design that the learner's have not yet reached (ie after the temporary stop gate). The teacher makes their changes then clicks Apply Changes.
  4. LAMS updates the runtime copy of the learning design (not the original version created in authoring). The stop gate is removed. Any new activities are initialised (hence the initialisation flag set when the lesson was created). If any of the learners had completed the lesson, then their completion flags are cleared so that next time they go into the lesson, they new activities will be displayed.
  5. The teacher is taken back to the normal monitoring screen.

Note: If the teacher closes the monitoring/editing screen before completing the editing, then the lesson is left in editing mode. If that teacher returns to monitoring they will be taken back into Live Edit. If another teacher attempts to access monitoring, then they will be blocked from using monitoring and will be told who is editing the lesson.

A more detailed explanation of how Live Edit works is given elsewhere.

  • No labels