|
Please wait ......
ADL SCORM Run-Time Environment - Summary
Terms of use
X
Terms of use
These contents have been obtained from the ADL web site and edited for presentation. Please refer to the ADL web site for additional information on terms of use.
Print
There are several key concepts that are introduced in the SCORM Run-Time Environment (RTE) book. The book covers the essential LMS responsibilities for sequencing content objects (SCOs or Assets) during run-time and allowing SCOs to indicate navigation requests. In addition, guidance is offered for providing navigation controls to learners. General subjects discussed include:- Run-Time Environment Management: Launching of content objects – SCOs and Assets, Management of communications with a SCO, Run-time environment data model management.
- Application Programming Interface (API): LMS API requirements, SCOM communication requirements, communication error conditions) Run-Time.
- Environment Data Model: Data model management and behavior requirements, Data type requirements.
SCORM Conceptual Run-Time Environment.
|
|
Managing The Run-Time Environment
As described in the Content Aggregation Model, the SCORM Content Model is made up of three components:
- Assets
- SCOs
- Content Organizations
The SCORM CAM describes the characteristics of launchable content objects; SCOs and Assets are the defined content model components that can be launched. Different launching requirements exist depending on the content object’s type. The launching process defines the common way for LMSs to launch content objects to the learner’s Web browser. The procedures and responsibilities for establishing communication between the launched content object and the LMS vary depending on the type of the launched content object.
It is the responsibility of the LMS to manage the sequencing between learning activities based on well-defined behaviors and the evaluation of defined sequencing information applied to activities. The progression through learning activities that comprise a particular learning experience may be sequential, nonsequential, user-directed or adaptive, depending on the sequencing information defined and the interactions between a learner and content objects.
The two SCORM Content Model components that can be launched by an LMS are Assets and SCOs. There are different launching requirements depending on the type of learning resource being launched. The launching mechanism defines the common way for LMSs to start learning resources. The procedures and responsibilities for the establishment of communication between the delivered learning resource and the LMS vary depending on the type of SCORM learning resource being launched:- Asset. For content objects that represent Assets, the SCORM launch model only requires that an LMS launch the Asset using the HTTP protocol. An Asset does not communicate to the LMS via the API and Data Model.
- Sharable Content Object (SCO). For content objects that represent SCOs, the SCORM launch model requires that an LMS launch and track one SCO at a time (per learner). In other words, the LMS launches and tracks one SCO at a time (per learner).The launched SCO can itself implement an API Instance for subordinate SCOs that it may launch and track. The LMS is not responsible for “knowing” of these subordinate SCOs. If this is the case, the SCO that was launched by the LMS is responsible for all cleanup (e.g., closing of any windows that were opened to host the subordinate SCO) upon termination of itself. All communication with the LMS must take place with the SCO that was launched by the LMS.
|
Application Program Interface (API)
The use of a common API fulfills many of the SCORM’s high-level requirements for interoperability and reuse. It provides a standardized way for SCOs to communicate with LMSs, yet it shields the particular communication implementation from the SCO developer. How the LMS-provided API Instance communicates with the server-side component of the LMS is outside the scope of SCORM. This back-channel communication can be implemented anyway the LMS vendor likes.
There are several terms that are used throughout SCORM: API, API Implementation and API Instance. The figure shown below describes the terms and their relationships to each other.
API, API Instance, API Implementation
|
|
In its simplest terms, the API is merely a set of defined functions that the SCO can rely on being available.
An API Implementation is a piece of functional software that implements and exposes the functions of the API. How an API Implementation functions should not matter to a SCO developer, as long as the API Implementation uses the same public interface and adheres to the semantics of the interface. The LMS need only provide an API Implementation that implements the functionality of the API and exposes its public interface to the client SCO.
An API Instance is an individual execution context and state of an API Implementation. The API Instance represents the piece of executing software that the SCO interacts with during the SCOs operation.
A key aspect of the API is to provide a communication mechanism that allows the SCO to communicate with the LMS. It is assumed that once the SCO is launched it can then store and retrieve information with an LMS. All communication between the LMS and the SCO is initiated by the SCO. There is currently no supported mechanism for LMSs to initiate calls to functions implemented by a SCO. |
Data Model
The purpose of establishing a common data model is to ensure that a defined set of information about SCOs can be tracked by different LMS environments. If, for example, it is determined that tracking a learner’s score is a general requirement, then it is necessary to establish a common way for content to report scores to LMS environments.
If SCOs use a unique scoring representation, LMSs may not know how to receive, store or process the information.
The SCORM Run-Time Environment Data Model is based on the P1484.11.1 Draft Standard for Learning Technology - Data Model for Content Object Communication standard produced by the IEEE LTSC Computer Managed Instruction (CMI).
P1484.11.1 is a standard that defines a set of data model elements that can be used to communicate information from a content object (i.e., SCO in SCORM) to an LMS. This set of data includes, but is not limited to, information about the learner, interactions that the learner had with the SCO, objective information, success status and completion status. This information may be vital for many purposes. This data can be used to track the learner’s progress and status, aid in sequencing decisions and report on the overall learner interaction with the SCO.
Using the data model with the API
|
|
|