Design and Implementation of an Extensible Learner-Adaptive Environment

: This paper describes the design and implementation of a flexible architecture that is capable of extending the functions of a learner-adaptive self-learning environment. A “courseware object”, which is a program module that is used to implement various educational functionalities, has been newly introduced to ensure both function extensibility as well as content reusability. A prototype system was designed and implemented to investigate the feasibility of the proposed architecture and to identify the core behavior and interaction schema of courseware objects. The results from this trial indicated that several learner-adaptive functionalities including the SCORM 2004 standard specifications will be able to be successfully implemented into the proposed architecture.

Yosuke Morimoto is an associate professor at the Open University of Japan. He graduated and received his Ph.D. in Engineering from Tokyo Institute of Technology in 2005. He has specialized in educational technologies. He is currently mainly engaged in designing and developing retrieval/sharing systems for learning content.

Introduction
It is widely known that the interoperability and reusability of learning content is a critical issue that needs to be addressed to provide high-quality e-learning services with rich learning experiences. Enormous amounts of effort have been expended to confront this issue by establishing and disseminating e-learning content specifications (Fallon & Brown, 2003;Nakabayashi, 2004) including the Aviation Industry CBT Committee (AICC) Computer Managed Instruction (CMI) specifications (Aviation Industry CBT Committee, 2004), the Advanced Distributed Learning (ADL) Sharable Content Object Reference Model (SCORM) (Advanced Distributed Learning, 2006), and the IMS Global Learning Consortium Common Cartridge (CC) (IMS Global Learning Consortium, 2008). Some of these attempts have successfully achieved interoperability between e-learning content and learning-management systems (Kazi, 2004;Nakabayashi et al., 2006;Nakabayashi et al., 2007;Shih et al., 2005;Yang et al., 2004). On the other hand, learneradaptive techniques have been regarded as an effective means of enhancing learning experience by providing suitable learning content and resources that match the learner's current status. There have been numerous proposals and studies on learner-adaptive techniques (Fletcher 1975;Murray, Blessing & Ainsworth, 2003;Wenger, 1987) that have been based on the traditional overlay model (Carr & Goldstein;1977) and the bug model (Brown & Burton, 1978) as well as a Web-based training system (Nakabayashi et al., 1995), sophisticated adaptive hypermedia (Brusilovsky, 2003;De Bra & Ruiter, 2001), and a system using domain ontology (Sosnovsky et al., 2007).
However, little consideration has been given to interoperability and reusability of content in the field of learner-adaptive systems. Most existing learner-adaptive systems have usually been designed to implement a certain single learner-adaptive strategy without any consideration being given to support multiple learner-adaptive strategies or even to extend a single implemented strategy. Without such a framework for extending functions, it would be difficult to add new functions that could improve the effectiveness of learning. This is because newly added functions may conflict with those towards executing existing learning content by leading to a damage of the reliable behavior of this content. In addition, it would take too long for standardization organizations to authorize extensions of functions to existing standard specifications. It is thus very difficult to achieve both content-system interoperability and system-function extensibility in conventional learner-adaptive systems.
To overcome this problem, the authors have proposed a new learning-system architecture that aims at achieving the goals of both extending learner-adaptive functions and making learning content interoperable (Nakabayashi, Morimoto & Hada, 2008;Nakabayashi, Morimoto & Hada, 2009). To achieve this goal, the proposed architecture introduces the concept of a "courseware object", which is a program module that is used to implement various educational functionalities. This architecture allows for the incremental extensions of functions by adding new courseware objects. Since the existing functions are not affected, this ensures that existing content will always work properly. Following these earlier investigations, the authors designed and implemented a prototype system to investigate the feasibility of the proposed architecture and to identify the core behavior and interaction schema of courseware objects. The results from a trial showed that several learner-adaptive functionalities including the SCORM 2004 standard specifications and their extensions could be successfully implemented on the proposed architecture.

Issues with Conventional Learner-Adaptive Systems
It was common to employ a system architecture, as shown in Figure 1, that separated the content from the platform in the past evolution of learner-adaptive systems (Nakabayashi et al., 1996;Wenger, 1987). The content in this configuration consisted of learning material that was specific to a particular learning subject with a particular learning goal, and the platform implemented common learner-adaptive functionalities, which were independent of the specific learning subject or learning goal. By separating content from the platform, this configuration was intended to make it much easier to design learneradaptive content. This was because the designer could concentrate on creating content to fulfill the learning objectives or goals without having to worry about how to implement learner-adaptive functionalities in detail.

Figure 1. Configuration for conventional learner-adaptive system
The drawback to this configuration was the lack of a framework for extending functions. Once the platform was designed and implemented, it was difficult to extend it by adding new functionalities because the existing learning content that had been designed before the platform was extended may not work properly on the extended system. Moreover, these extensions needed to be authorized as new standard specifications to achieve system interoperability, but this authorization process took a long time. It was also necessary to update existing platforms to meet the new specifications, which was also a time-consuming process. Thus, it was almost impossible to make both the system interoperable with content and extend its functions in conventional learner-adaptive systems. A representative standard with specifications for learner-adaptive systems, SCORM 2004, employed the same configuration and resulted in a lack of function extensibility.

The Proposed Architecture
To overcome the problems described in the previous section, the authors propose a new learner-adaptive system architecture that is capable of both function extensibility and system interoperability (Nakabayashi, Morimoto & Hada, 2008; Nakabayashi, Morimoto & Hada, 2009). To accomplish this, the proposed architecture introduces the concept of a "courseware object", which is a program module used to implement various educational functionalities such as learner adaptation to choose the most suitable learning material for the learner, material presentation to tailor the way the learning material is presented, and learner tracking to record the status of the learner's progress, i.e., functions usually embedded in the platform in a conventional configuration. For example, the courseware object can implement simple linear, branch, and remedial sequencing taking into account the test results, or much more sophisticated strategies such as scenario-based sequencing using a state-transition machine.
As shown in Figure 2, in the proposed architecture, the courseware object is clearly separated from the platform. It is possible to incrementally extend functions with this configuration by adding new courseware objects. Since this addition does not affect functions previously implemented with existing courseware objects, existing content always works properly. Moreover, courseware objects can be distributed with content, thus enabling existing platforms to be immediately updated for newly developed functionalities. This eliminates the long time lags that result from conducting standard authorization processes and installing platform updates.

Figure 2. Configuration of the proposed learner-adaptive system
Similar to the conventional configuration, the content consists of learning materials specific to a particular learning subject in this architecture. In addition, the content has a link to the courseware objects used to implement the learner-adaptive behavior that the content designer requires. The content designer may reuse existing courseware objects to implement his/her new content, or may ask an IT engineer to develop new ones if there is none suitable to meet his/her purpose for content design. The courseware objects may be delivered and reused with the content to allow for both system interoperability with content and functions extensibility.
The role of the platform is completely different from that in the conventional configuration. Instead of implementing a particular learner-adaptive behavior, the platform coordinates the communication between courseware objects. When the learner launches the content, the platform reads it and instantiates the required courseware objects. When the learner interacts with the system, the platform forwards the information from the learner to the proper courseware objects to carry out certain learneradaptive behaviors.

Design Issues with the Proposed Architecture
To achieve the goal of the proposed architecture, courseware objects developed by various designers with various timing should be combined to work together. To meet these requirements, it is necessary to define some standards or make agreements on a communication scheme between courseware objects, the information courseware objects manage and update, and the responsibility of courseware objects.
To investigate these issues, the authors designed the system based on the following principles and assumptions. Firstly, it was assumed that the content was structured hierarchically or like a tree. This is because content with a hierarchical structure is widely adopted in learning materials by various standards including AICC CMI ( Figure 3. Configuration of the proposed system treating hierarchical content Secondly, it was assumed that courseware objects were assigned to each hierarchical node of content as outlined in Figure 3. A courseware object assigned to a content node is responsible for managing the learner-adaptation behavior of the sub-tree under the assigned node. In particular, according to the pedagogical strategy implemented in it, the courseware object sequences its child nodes by taking into account of their learner progress information. This makes it possible to implement different pedagogical strategies in different sub-trees. It was also assumed that the communication between courseware objects was limited only between parents and children. Based on this assumption, the authors attempted to define the required communication patterns between courseware objects and what interface courseware objects should provide for other courseware objects.

Implementation of the Prototype System
Based on the design principles discussed in the previous section, the authors implemented several learner-adaptive functions to further investigate the feasibility of the proposed architecture and to identify the core behavior and interaction scheme of courseware objects. One of the functions implemented was a subset of SCORM 2004 behaviors including:  Continue, previous, choice, start, suspend and resume navigation requests,  Default rollup behavior,  Skip precondition rule, and  Retry, continue and previous post condition rules.
Another function implemented was a sequencing function based on the statetransition machine. The following sections give details on the implementation of the prototype system.

Command execution
In SCORM 2004, the learner interacts with the system using navigation commands such as "continue" (meaning move to the next page) or "choice" (meaning jump to the specified page). In the command-processing schema that has been designed, the command from the learner is sent to the current object, or the courseware object associated with the content page currently presented to the learner, to deal with the command. If the object cannot process the command, then it forwards, or escalates, the command to its parent object in the content tree. The parent also tries to deal with the command, then it escalates the command to its parent object if it cannot process it. This is repeated until it encounters a parent node capable of dealing with the command.   Figure 4 illustrates the process to execute the command. First of all, the current object receives the command. It then escalates the command to its parent to select the candidate next page from its children. If the parent cannot find a suitable child, then it escalates the command to the grandparent. The grandparent makes its children select a suitable node from their children. This recursive behavior is repeated until a suitable candidate for the next page is found. This results in a behavior that gradually expands the search space for the candidate in the content tree from the local (the smallest sub-tree containing the current object) to the global (the entire content tree). The identified node for the next page will be presented to the learner, and its associated courseware object will be the new current object.
To implement the SCORM 2004 specifications, the control modes, limit conditions, and precondition rules that affect the selection of the candidate child node are evaluated when the parent node selects the candidate child. It needs to be noted that the criteria or the strategy for selecting the child node may differ from object-to-object allowing different learner-adaptation functionalities to be implemented in different nodes of the single content tree.

Rollup
To update the learner-progress status associated with each tree node, rollup from the current object to the root node is conducted before a command is executed. During the rollup process, the courseware object assigned to each tree node updates its learnerprogress status from the learner-progress status of its child nodes. Although this is similar to the rollup behavior in SCORM 2004, all courseware objects may implement their own rollup criteria.

Evaluation of the post-condition rules
To implement the SCORM 2004 specifications, the post-condition rules associated with each tree node, which may result in the command changing to another, are evaluated after rollup and before a command is executed. This process is similar to the evaluation behavior of post-condition rules in SCORM 2004; however, again all courseware objects may implement their own rule-evaluation criteria.

Generation of the command list
Since a courseware object may have its own unique commands, and since a command from a learner will be escalated from the current object toward the root node of the content tree until a certain node that can handle the command is encountered, commands defined in each courseware object from the current object to the root node are collected as a list of commands that is presented to the learner. This command list is generated after the previous command has been executed.

Courseware object for learning objectives
In addition to the tree nodes, the SCORM 2004 content structure may have learning objectives, which can be created independently from the tree structure. A learning objective is an entity to hold the learner's success status as global information. In the prototype system, a learning objective is implemented as a kind of a courseware object. The learner's success status information is stored from a tree node courseware object to learning objective courseware object. The stored success status information may be read later by the other tree node courseware objects. Table 1 outlines the current status of the SCORM 2004 functions implemented with the SCORM 2004 courseware objects of the prototype system. Almost all the main functions of the SCORM 2004 specifications have been implemented. Functions not implemented in the prototype system include references to additional objectives other than primary objectives in the sequencing rules, rollup conditions and rollup controls, and delivery controls. These functions not available in the prototype system can rather easily be implemented later not by modifying the communication schema described above but by modifying the SCORM 2004 courseware objects themselves. For example, complicated rollup conditions and rollup controls can be implemented within the SCORM 2004 courseware objects by adding a mechanism to interpret the condition part of the rollup rules and rollup controls in addition to the default rollup behavior that has already been implemented. This does not require any modifications to the communication schema for the rollup behavior described above. The same discussion can be applied to references to the additional objectives in the sequencing rules and delivery controls. The former can be implemented by enhancing the rule-condition interpretation logic of the SCORM 2004 courseware objects, which is currently only capable of handling primary objectives. The latter can be achieved by adding a function to check delivery control flags in the SCORM 2004 courseware objects for leaf nodes.

Evaluation of the implementation of SCORM 2004
The prototype system was evaluated with several types of sample content to check if the communication schema for the prototype system could correctly implement the basic SCORM 2004 sequencing functions. The most complicated sample content is given in Figure 5 with the test procedure in Table 2. Behavior of handling the post-condition rule was evaluated in Step 5, where the retry rule of node 12 was activated so that traversal from node 123 to node 121 took place despite the continue navigation command. The behavior of the command execution schema described in Subsection 5.1.1 is highlighted in Steps 6,8,10 and Step 11. The leaf nodes receiving navigation commands such as continue or previous escalate the navigation command to their parents in these steps. Each parent tries to find the candidate node in its descendants. If there are no proper candidates, the parent again escalates the navigation command to its parent. This behavior works correctly in the operation steps above, resulting successful traversal beyond the sub-trees. This indicates that the communication schema for the prototype system can be used to mimic the behavior of the original SCORM 2004 specifications described with the complicated procedural pseudo code.

The state-transition machine
Within the framework of communication patterns described in Subsection 5.1, a pedagogical strategy based on the state-transition machine has been implemented. In particular, a courseware object holds the following state-transition

Further Issues
There are several open issues related to the design and implementation of the proposed architecture. Short-term issues are to confirm the feasibility of implementing full SCORM 2004 functions and other commonly required easy-to-understand functions such as "hint" or "remedial". Assuring interoperability with existing SCORM 2004 content as well as installing functionalities that are familiar to content designers are important steps towards the dissemination of the proposed architecture. Other issues include extending the manifest-file format defining the courseware structure. It is necessary to extend the current SCORM 2004 manifest-file format so that it is capable of assigning a courseware object to each content node.
It is also important to consider the programming and execution environment. The environment to implement the proposed architecture must have capabilities to deal with courseware objects, especially dynamic combinations of courseware objects at run time. A naive implementation is placing an execution environment in a learning management system (LMS) constructed by using a certain object-oriented language. In this case, the communication schema described in the previous section will be implemented as the method call of an object. However, since the abstract communication schema between courseware objects is standardized, it is not necessary to place these objects in one LMS. For example, a courseware object can be implemented as a Web service on a separate server. If there are courseware objects implementing large-scale simulations or adaptive testing (Wainer, 2000) with huge item pools placed on an external Web server, these courseware objects can be reused as parts of various learning content. In this case, the communication schema between the courseware objects will be implemented using a Web-service protocol. Another interesting possibility would be to implement courseware objects as widgets. A widget is a small application module running on a client terminal communicating with the Web server. It can easily be implemented with a widely used script language such as JavaScript. Developer's Toolkits are also helpful for implementing widgets equipped with certain learner-adaptive functionalities associated with a specific user interface.
In addition to the above, the framework should be discussed to deal with a common vocabulary for commands, learner progress status, and events to generalize communication between courseware objects. It will also be necessary to consider contentauthoring environments in the future using courseware objects and a repository of courseware objects.

Conclusion
The authors discussed the design and implementation of a flexible learner-adaptive architecture that is capable of extending functions. By introducing the concept of a "courseware object", which is a program module that implements various educational functionalities, the proposed architecture is capable of incrementally extending functions while maintaining the existing functionalities. A trial implementation was carried out to investigate the basic behavior and communication schema of courseware objects that implemented the basic functions of SCORM 2004 and other learner-adaptive functions. Future work includes further investigations into communication schemata between courseware objects, manifest file extensions, and execution environments.