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 10 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 and Database Model


Figure 1 Lesson related domain object diagram


Figure 2 Lesson related database design

The above diagrams are fragments of the entire domain object diagram and database to illustrate the objects that handle lesson related learner progression. The major inheritance mapping we adopted is "Table per class hierarchy" so the database diagram doesn't distinguish between tool activities and the abstract activity class, as all activities are stored in the one table in the database.

There are four major components for a lesson:

  • The LearningDesign defines the major learning sequence that students in a lesson should complete.
  • The LessonClass 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.

The relationships between the group tables looks a little confusing, as the grouping classes are used for both normal groups and the lesson class. A Lesson has a LessonClass, which is a subclass of Grouping (and hence is stored in the lams_grouping table). The staff_group_id column is only used for the LessonClass object. The LessonClass has a single group in its groups collection, and this group is all the learners in the LessonClass. Then there is a second group which is the staff group, and that group's id is stored in the staff_group_id column.

In the course of the lesson, there maybe "normal" groups set up, such using the Random Grouping. These will have a Grouping class and one or more Group classes, so one lams_grouping row and multiple lams_group rows.

  • 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. Moreover, the ToolSession is the means by which we assign a batch of learners to a particular instance of an activity. If the activity is being used for the whole class, then the ToolSession is associated with the LessonClass' group of learners. If the activity is grouped, then there is a separate ToolSession for each group, creating a separate instance of the ToolActivity.
  • The LearnerProgress records the progress data for each learner. One lesson should have 0 or many learner progressions. Every learner should only have one learner progress record for a lesson.

The learner's progress object is represented as one class in Java, but the attempted and completed sets are implemented as separate tables in the database. So there are 5 direct and indirect links from the learner's progress to activity - current activity, previous activity, next activity, attempted set and completed set.

The completed and attempted sets are exclusive sets. When a learner starts an activity then the activity is recorded in the attempted set. When the activity is completed, it is removed from the attempted set and added to the completed set.

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. Currently not used, as there is no definition of "Finished" as new learners could be added at any time.

ARCHIVED_STATE

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

REMOVED_STATE

The state for lessons that are removed and never can be accessed again. In reality, the records are still in the database and could be retrieved by setting the state back to STARTED_STATE directly in the database.

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