SCORM-Laufzeitumgebung

Überblick über die SCORM-Laufzeitumgebung

Die SCORM-Laufzeitspezifikation steuert, wie das LMS Inhalte startet und wie der Inhalt dann mit dem LMS kommuniziert. All diese Kommunikation geschieht im Rahmen eines einzigen Versuchs an einem einzigen SCO. Die Navigation zwischen SCOs wird durch die im Manifest angegebene Sequenzierung geregelt und hier weiter erläutert.

Starten von Inhalten

Alle SCORM-Inhalte müssen webbereit sein und die gesamte SCORM-Kommunikation erfolgt im Kontext einer Webbrowser-Sitzung. Das LMS startet jeweils einen SCO, wie vom Benutzer ausgewählt oder gemäß den SCORM 2004-Sequenzierungsregeln festgelegt. In Versionen vor SCORM 2004 3rd Edition gab es keine formalen Anforderungen an die von einem LMS bereitgestellte Benutzeroberfläche. Jedes LMS ist etwas anders, aber zum größten Teil, Es ist fair zu erwarten, dass ein LMS eine ähnliche Schnittstelle wie die unten abgebildete bereitstellt. Es sollte mindestens eine Form eines navigierbaren Inhaltsverzeichnisses sowie Steuerelemente für die Flussnavigation (vorherige und nächste Schaltflächen) enthalten. Diese Navigationselemente steuern die Navigation zwischen SCOs. Wenn eine Navigation innerhalb einer SCO erforderlich ist, muss die SCO eigene Navigationselemente bereitstellen.

Das LMS hat zwei Möglichkeiten, einen SCO zu starten. Es kann entweder die SCO in einem Frameset starten (wie oben abgebildet), oder es kann die SCO in einem neuen Fenster starten. Einige LMS starten Inhalte immer auf die eine oder andere Weise. Wenn ein Kurs jedoch nur einen SCO enthält (und daher keine Navigationselemente aus dem LMS benötigt), wird der SCO in einem Popup-Fenster gestartet. Wenn der Kurs umgekehrt viele SCOs enthält, startet das LMS die SCOs normalerweise in einem Frameset, das von Navigationselementen umgeben ist. Einige LMS ermöglichen es den Inhaltsautoren, genau zu steuern, wie SCOs gestartet werden, welche Navigationselemente verfügbar sind und sogar die Größe der SCO-Fenster.

Die API

Die gesamte Kommunikation zwischen einem SCO und dem LMS erfolgt über eine ECMAScript-API (JavaScript). Nur so kann Kommunikation stattfinden. Andere Kommunikationskanäle stehen nicht zur Verfügung. Inhalte können nicht über Webdienste, Formularbeiträge, Datenbankschreibvorgänge oder andere Mechanismen kommunizieren, sondern nur über die vom LMS bereitgestellte JavaScript-API.

API finden

Das LMS ist dafür verantwortlich, ein speziell benanntes JavaScript-Objekt an einer bestimmten Stelle im DOM des Browsers bereitzustellen. Somit kann der Inhalt diese API immer mithilfe eines gemeinsamen Algorithmus finden.

In SCORM 1.1 und SCORM 1.2 heißt das API-Objekt immer „API“. In SCORM 2004 heißt das Objekt „API_1484_11“.

Das API-Objekt sollte sich in einem Fenster befinden, das ein übergeordnetes Element des SCO oder ein übergeordnetes Element des Opener-Fensters des SCO ist. Ein „übergeordnetes“ Fenster ist definiert als die gesamte Kette der übergeordneten Fenster bis zum Stammbrowserfenster. Die API könnte sich also im übergeordneten Element des SCO, im übergeordneten Element des SCO, im übergeordneten Element des übergeordneten Elements des SCO usw. befinden. In ähnlicher Weise kann sich die API im Öffnerfenster, im übergeordneten Element des Öffners, im übergeordneten Element des Öffners usw. befinden. Die folgenden Diagramme aus der Spezifikation SCORM 2004 3rd Edition veranschaulichen die möglichen API-Speicherorte.

SCORM enthält spezielle Algorithmen, mit denen Inhalte die SCORM-API finden können.

Verwenden der API

Sobald ein SCO die SCORM-API gefunden hat, kann er über die API mit dem LMS kommunizieren. Beachten Sie, dass nur der SCO die Kommunikation initiieren kann. Das LMS ist eine passive Entität, die einfach auf die API-Aufrufe des Inhalts reagiert. Das LMS kann keine Kommunikation initiieren, es startet einfach den Inhalt und reagiert auf Anfragen.

Die SCORM-API enthält acht Methoden mit den folgenden Signaturen:

SCORM 2004

Initialize( "" ) : bool Terminate( "" ) : bool getValue( element : CMIElement ) : string setValue( element : CMIElement, Wert: string) : string Commit( "" ) : bool GetLastError() : CMIErrorCode GetErrorString( Fehlercode: CMIErrorCode ) : string GetDiagnostic( Fehlercode: CMIErrorCode ) : string

SCORM 1.1 / SCORM 1.2

LMSInitialize( "" ) : bool LMSFinish( "" ) : bool LMSGetValue( element : CMIElement ) : string LMSSetValue( element : CMIElement, value : string) : string LMSCommit( "" ) : bool LMSGetLastError() : CMIErrorCode LMSGetErrorString( errorCode : CMIErrorCode ) : string LMSGetDiagnostic( errocCode : CMIErrorCode ) : string

Die Methodennamen variieren geringfügig zwischen den SCORM-Versionen, aber konzeptionell sind die Methoden identisch.

Anmerkungen:

• Der bool-Typ ist ein SCORM-Boolescher Wert, bei dem es sich tatsächlich um eine Zeichenfolge mit dem Wert „true“ oder „false“ handelt.
• Der Parameter „“ wird von allen SCORM-Methoden benötigt, die keine anderen Argumente akzeptieren. SCOs müssen lediglich einen leeren String-Parameter an diese Methoden übergeben.
• Der CMIElement-Datentyp ist eine Zeichenfolge, die den unten beschriebenen SCORM-Datenmodellelementen entspricht.
• Der Datentyp CMIErrorCode ist eine dreistellige Zahl, die als Zeichenfolge dargestellt wird und einem der SCORM-Laufzeitfehlercodes entspricht.

Initialize / LMSInitialize

Die Initialize-Methode gibt dem LMS an, dass der Inhalt eine Kommunikationssitzung beginnen möchte. Alle SCOs müssen Initialize aufrufen, bevor sie eine andere Kommunikation durchführen. Das LMS gibt einen booleschen Wert zurück, der den Erfolg oder Misserfolg der Initialisierung angibt. Normalerweise müssen LMS nicht viel initialisieren und geben immer „true“ zurück.

Terminate / LMSFinish

Die Terminate-Methode zeigt dem LMS an, dass der Inhalt fertig kommuniziert ist. Alle SCOs müssen Terminate aufrufen. Das Aufrufen von Terminate zeigt nicht unbedingt an, dass der Benutzer mit dem SCO fertig ist, technisch gesehen zeigt es nur an, dass der SCO mit der Kommunikation fertig ist. In der Praxis sind Inhalte jedoch kompatibler und verwendbarer, wenn Terminate nur aufgerufen wird, wenn der Inhalt dem Benutzer entzogen werden kann. Da Terminate immer aufgerufen werden muss, unabhängig davon, wie der Lernende den SCO verlässt, ist es ratsam, im onunload-Ereignis eines SCO einen Aufruf zum Beenden zu tätigen. Der vom LMS zurückgegebene boolesche Wert gibt häufig an, ob SCO-Daten erfolgreich auf dem Server gespeichert wurden oder nicht.

getValue / LMSGetValue

Mit der Methode getValue kann ein SCO Daten vom LMS abrufen. Die Daten, die immer abgerufen werden, sind eines der definierten SCORM-Datenmodellelemente. Jedes dieser Datenmodellelemente enthält ein anderes Datenelement. Einige der Datenmodellelemente haben vom LMS initialisierte Werte, die mit den Umständen sprechen, unter denen der SCO gestartet wird. Andere Werte werden vom SCO durch Aufrufe von setValue initialisiert. Wenn der Aufruf von getValue eine leere Zeichenfolge zurückgibt, ist möglicherweise ein Fehler aufgetreten, und die GetLastError-Methode sollte aufgerufen werden, um nach Problemen zu suchen.

setValue / LMSSetValue

Mit der setValue-Methode kann der SCO Daten im LMS beibehalten. Die Daten werden immer in einem der definierten SCORM-Datenmodellelemente gespeichert. Einige Datenmodellelemente sind darauf beschränkt, Werte in einem begrenzten Vokabular zu haben (z. B. kann der Status „abgeschlossen“ oder „bestanden“ sein), andere sind darauf beschränkt, ein bestimmter Datentyp zu sein (z. B. muss die Punktzahl immer eine Zahl sein), während andere es dem SCO ermöglichen, Freitextdaten ohne semantische Bedeutung beizubehalten. Der setValue-Aufruf gibt einen booleschen Wert zurück, der den Erfolg oder Misserfolg des Aufrufs angibt.

Commit / LMSCommit

Die Commit-Methode signalisiert dem LMS, dass eine erhebliche Menge an Daten gespeichert wurde und dass sichergestellt werden soll, dass die Daten ordnungsgemäß beibehalten werden. Es gibt keine Anforderungen daran, wie das LMS die Commit-Methode implementieren soll, es ist lediglich ein informatives Signal. Einige LMS führen für jeden Aufruf einen Roundtrip zum Server durch, um sicherzustellen, dass alle Daten beibehalten werden. Diese Implementierungsstrategie ist zwar intuitiv, kann jedoch zu Skalierbarkeitsproblemen führen. Achten Sie darauf, Commit nicht übermäßig aufzurufen, um diese LMS nicht zu überlasten.

GetLastError / LMSGetLastError

Die Methode GetLastError prüft, ob der letzte SCORM-API-Aufruf einen Fehler verursacht hat. Wenn ja, gibt diese Methode eine Fehlernummer zurück, die einem definierten Satz möglicher Fehler entspricht. Einige Fehlernummern stellen vollkommen legitime Situationen dar (z. B. 403 – Datenmodellelement nicht initialisiert). SCO-Autoren sollten darauf achten, dem Benutzer nur legitim unerwartete Fehler anzuzeigen. Die vollständige Liste der Fehlercodes finden Sie im SCORM-Laufzeitreferenzdiagramm.

GetErrorString / LMSGetErrorString

Bei einer bestimmten Fehlernummer (normalerweise die von GetLastError zurückgegebene Fehlernummer) gibt die GetErrorString-Methode eine Textbeschreibung des Fehlercodes zurück. In SCORM 2004 gibt die Übergabe der Fehlernummer „406“ beispielsweise die Zeichenfolge „Data Model Element Type Mismatch“ zurück, um anzuzeigen, dass das Ergebnis des vorherigen Aufrufs (wahrscheinlich ein setValue) fehlgeschlagen ist, da die gespeicherten Daten nicht im richtigen Format waren.

GetDiagnostic / LMSGetDiagnostic

Mit der Methode GetDiagnostic kann das LMS detaillierte Informationen über den vorherigen Fehler zurückgeben, die bei der Diagnose des Problems hilfreich sein können. Zum Beispiel könnten die Diagnoseinformationen für den oben erwähnten „406“ -Fehler „Der Wert ‚Null‘ ist für cmi nicht zulässig.Ergebnis.Rohstoff. Das cmi.Ergebnis.das Element muss eine gültige Zahl enthalten, die nur als Ziffern dargestellt wird“.

Das SCORM-Laufzeitdatenmodell

Das Laufzeitdatenmodell enthält viele Elemente, von denen jedes seine eigene Bedeutung hat. Die Elemente können über die API gelesen und geschrieben werden. Das SCORM-Laufzeitreferenzdiagramm enthält eine Liste jedes Datenmodellelements zusammen mit seinem Datentyp und eine kurze Beschreibung seiner Bedeutung und Verwendung.

Jeder SCO hat seinen eigenen Satz von Laufzeitdaten. Jedes dieser Datenmodellelemente hat einen separaten Wert für jedes SCO innerhalb eines Kurses. Darüber hinaus verfügt jeder „Versuch“ eines SCO über einen eigenen Satz Laufzeitdaten. Wenn der Lernende einen neuen Versuch an einem SCO startet, werden die Datenmodellwerte für den Start des neuen Versuchs zurückgesetzt.

Die Datenmodellelemente unterscheiden sich geringfügig zwischen den SCORM-Versionen, aber zum größten Teil gibt es in jeder Version der Standards ein entsprechendes Element. SCORM 1.1 und SCORM 1.2 haben identische Datenmodelle. SCORM 2004 hat einen anderen Datenmodellsatz. Es gibt auch kleinere subtile Unterschiede zwischen den Editionen von SCORM 2004. Das Diagramm bietet eine umfassende Referenz für jede Version / Edition. Zu den wichtigsten Änderungen in SCORM 2004 gehören:

• Geringfügige Umbenennung, meistens Entfernen des „Kerns“ aus den Namen der Datenmodellelemente.
• Trennung des Status. In SCORM 1.2 ein einzelnes Element, cmi.Kern.lesson_status repräsentiert den Status des SCO. In SCORM 2004 wird der Status in zwei separate Elemente, cmi, unterteilt.completion_status (abgeschlossen vs unvollständig) und cmi.success_status (bestanden vs fehlgeschlagen).
• Interaktionen (Fragenergebnisse) sind Lese- /Schreibzugriff anstelle von Schreibzugriff. Interaktionen enthalten auch ein Beschreibungsfeld, das in SCORM 1.2 fehlte.
• Hinzufügung von adl.nav.* datenmodellelemente, die es dem SCO ermöglichen, Sequenzierungsanforderungen zu initiieren

Verwenden der Laufzeit

Die Verwendung der SCORM-Laufzeit ist aus strikter Konformitätsperspektive weitgehend optional.

Wenn Ihr Kurs nur startbare Assets enthält, sind im einfachsten Fall keine Laufzeitaufrufe erforderlich. Das LMS startet einfach jedes Asset wie vom Benutzer angefordert, und das Asset gilt sofort nach dem Start als abgeschlossen.

Für eine umfassendere Interaktion müssen wir zunächst die Laufzeitkommunikation aktivieren. Dazu müssen Sie die API finden und dann sicherstellen, dass Initialize und Terminate aufgerufen werden. In den meisten Fällen sollte Initialize unmittelbar nach dem Start des SCO aufgerufen werden. Sobald initialize aufgerufen wurde, ist es wichtig, dass Terminate in jedem Exit-Szenario aufgerufen wird.

Sobald die Kommunikation initialisiert wurde, ist es an der Zeit, mit der tatsächlichen Datenkommunikation zu beginnen. Die folgenden „1st Tier“-Datenmodellelemente sind die wichtigsten und am häufigsten verwendeten (SCORM 1.2 äquivalent in Klammern):

• cmi.completion_status & cmi.success_status (cmi.Kern.lesson_status) – Diese Datenmodellelemente sind die grundlegendsten und wichtigsten. Sie zeigen an, wann ein Benutzer einen Kurs beendet hat und ob er bestanden oder nicht bestanden hat. Diese grundlegenden Informationen sind für die meisten LMS unerlässlich.
• cmi.Ergebnis.skaliert (cmi.Kern.Ergebnis.raw) – Gibt die Punktzahl an, die der Lernende bei einer Bewertung innerhalb eines SCO erzielt hat. Das Melden einer Min- und Max-Punktzahl in Verbindung mit einer Rohpunktzahl ist ebenfalls eine gute Form.
• cmi.session_time (cmi.Kern.session_time) – Gibt die Zeit an, die der Lernende im SCO verbracht hat.
• cmi.standort (cmi.Kern.lesson_location) – Bietet dem SCO ein freies Textfeld zum Aufzeichnen eines Lesezeichens. Wenn der SCO größer als nur ein paar HTML-Seiten ist, sollte er in Betracht ziehen, eine Lesezeichen-Funktion zu implementieren, damit der Lernende einen angehaltenen Versuch fortsetzen kann.
• cmi.beenden (cmi.Kern.exit) – Dieser Wert gibt an, wie der Lernende den SCO verlässt. Einstellung cmi.exit to „suspend“ stellt sicher, dass der aktuelle Versuch beibehalten wird und die Laufzeitdaten beim nächsten Start des SCO nicht zurückgesetzt werden. Einstellung cmi.exit to „“ zeigt an, dass das LMS beim nächsten Start des SCO einen neuen Versuch mit einem neuen Satz Laufzeitdaten starten soll.

Die Industrienorm erwartet, dass alle Datenmodellelemente der 1. Ebene in einem SCO korrekt verwendet werden. Sobald diese Funktionalität aktiviert wurde, umfassen die nächsthäufigsten Datenmodellelemente oder die 2. Ebene:

• interaktionen – Verwenden Sie die Interaktionsdatenmodellelemente, um die Ergebnisse jeder Fragenantwort zu melden. Eine Interaktion muss keine traditionelle Testantwort sein. Zum Beispiel könnte ein SCO die Entscheidungen des Lernenden dokumentieren, während er eine Simulation durchläuft. Verwenden Sie nach Möglichkeit alle Interaktionselemente, um ein möglichst umfassendes Bild der Antworten des Lernenden zu erhalten. Verwenden Sie mindestens „ID“, „Typ“, „Ergebnis“ und „Beschreibung“, damit LMS grundlegende Berichte erstellen können.
• objectives – Erwägen Sie in großen SCOs die Berichterstattung über die Beherrschung bestimmter Lernziele durch den Lernenden mithilfe der Objectives-Datenmodellelemente. Ziele ermöglichen eine detailliertere Berichterstattung über den Fortschritt des Lernenden durch und die Beherrschung des Schulungsmaterials.
• cmi.progress_measure – Verwenden Sie das Element progress_measure in SCORM 2004, um den Fortschritt des Benutzers bis zum Abschluss eines SCO zu melden. Die progress_measure ist wie eine „percent complete“ -Maßnahme, die es dem LMS ermöglichen würde, einen Fortschrittsbalken für den Gesamtabschluss eines Kurses bereitzustellen.

Eintrag, Modus und Kredit

Das cmi.eintrag (cmi.Kern.eintrag), cmi.modus (cmi.Kern.lesson_mode) und cmi.kredit (cmi.Kern.kredit) Datenmodellelemente bieten dem SCO einen Kontext, den er verwenden kann, um dem Lernenden die optimale Erfahrung zu bieten.

• cmi.eintrag gibt an, ob der Benutzer den SCO zum ersten Mal startet oder ob er einen vorherigen Versuch fortsetzt. Bei Verwendung von Lesezeichen kann der SCO diesen Wert verwenden, um den Benutzer aufzufordern, am Anfang oder an dem Punkt zu beginnen, an dem der vorherige Versuch beendet wurde.
• cmi.modus gibt an, ob der Lernende diesen SCO startet: normalerweise – in einer „Live“ –Trainingseinheit; im Browse–Modus – Der Benutzer durchsucht einen Schulungskatalog und möchte diesen Kurs „in der Vorschau anzeigen“; oder im Review-Modus – Der Benutzer hat den SCO bereits abgeschlossen und kommt zurück, um das Material zu überprüfen. Im Browse-Modus sollte der SCO-Autor erwägen, das SCOS-Verhalten zu ändern, um eine Freiformnavigation bereitzustellen, eine Übersicht oder Karte des Kurses bereitzustellen und möglicherweise Bewertungen auszublenden. Im Überprüfungsmodus sollte der SCO-Autor in ähnlicher Weise in Betracht ziehen, dem Schlankeren die vollständige Freiheit der Navigation zu gewähren. Im Überprüfungsmodus kann der Lernende möglicherweise auch frei durch Tests navigieren und eine Liste der richtigen Antworten durchsuchen. Wenn ein SCO im Überprüfungsmodus gestartet wird, sollte er darauf achten, den Status des Lernenden nicht zu ändern oder die Punktzahl zurückzusetzen.
• cmi.kredit gibt an, ob dieser SCO für Kredit verwendet wird oder nicht oder ob er „zählt“. Ähnlich wie im Browse-Modus sollte das Verhalten wahrscheinlich geändert werden, wenn ein SCO ohne Guthaben gestartet wird.