SCORM Runtime Environment

overzicht van de SCORM Runtime environment

de SCORM Runtime specification bepaalt hoe het LMS inhoud lanceert en hoe de inhoud vervolgens communiceert met het LMS. Al deze communicatie gebeurt in de context van een enkele poging op een enkele SCO. De navigatie tussen SCO ‘ s wordt bepaald door de volgorde die in het manifest is gespecificeerd, en wordt hier verder uitgelegd.

Startinhoud

alle SCORMINHOUD moet web-deliverable zijn en alle SCORMCOMMUNICATIE vindt plaats in de context van een webbrowsessie. De LMS zal starten een SCO per keer, zoals geselecteerd door de gebruiker, of zoals bepaald door SCORM 2004 sequencing regels. In versies vóór SCORM 2004 3e editie, waren er geen formele vereisten voor de gebruikersinterface die door een LMS. Elke LMS is iets anders, maar voor het grootste deel, het is eerlijk om te verwachten dat een LMS om een interface vergelijkbaar met de hieronder afgebeelde bieden. Ten minste, het moet een bepaalde vorm van bevaarbare inhoudsopgave bevatten, evenals besturingselementen voor flow navigatie (vorige en volgende knoppen). Deze navigatieelementen regelen de navigatie tussen SCOs. Als navigatie nodig is binnen een SCO, moet de SCO zijn eigen navigatie-elementen leveren.

het LMS heeft twee opties voor het starten van een SCO. Het kan ofwel de SCO Ina frameset lanceren (zoals hierboven afgebeeld), of het kan de SCO in een nieuw venster lanceren. Sommige LMS ‘ s zal altijd de inhoud op de een of andere manier te lanceren. Gewoonlijk echter, als een cursus slechts één SCO bevat (en dus geen navigatieelementen van het LMS vereist), zal de SCO worden gestart in een popup venster. Omgekeerd, als de cursus bevat veel SCOs, dan zal de LMS gewoonlijk lanceren de SCOs in een frameset omgeven door navigatie-elementen. Sommige LMS ‘ s zullen de content auteurs in staat stellen om precies te controleren hoe SCOs worden gelanceerd, welke navigatie-elementen beschikbaar zijn en zelfs de grootte van de SCO-vensters.

de API

alle communicatie tussen een SCO en het LMS gebeurt via een ECMAScript (JavaScript) API. Dit is de enige manier om te communiceren. Er zijn geen andere communicatiekanalen beschikbaar. Inhoud kan niet communiceren via web services, vorm berichten, database schrijft of een ander mechanisme, alleen via de JavaScript API die door de LMS.

API vinden

het LMS is verantwoordelijk voor het leveren van een specifiek JavaScript-object op een specifieke locatie binnen het DOM van de browser. Dus, de inhoud, kan altijd lokaliseren deze API met behulp van een gemeenschappelijk algoritme.

in SCORM 1.1 en SCORM 1.2 wordt het API-object altijd “API”genoemd. In SCORM 2004 wordt het object “API_1484_11″genoemd.

het API-object moet zich bevinden in een venster dat een ouder is van de SCO of een ouder van het opener-venster van de SCO. Een “ouder” venster wordt gedefinieerd als de hele keten van oudervensters helemaal tot aan het root browser venster. Dus, de API kan in de SCO ’s ouder, de SCO’ s ouder ouder, de SCO ‘ s ouder ouder, enz. Op dezelfde manier kan de API in het opener venster, de opener ouder, de opener ouder ouder, enz. De onderstaande diagrammen uit de SCORM 2004 3rd Edition specificatie illustreren de mogelijke API-locaties.

SCORM bevat specifieke algoritmen die content kan gebruiken om de SCORM API te vinden.

met behulp van de API

zodra een SCO de SCORM API heeft gevonden, kan het de API gebruiken om met het LMS te communiceren. Merk op dat alleen de SCO de communicatie kan initiëren. De LMS is een passieve entiteit die gewoon reageert op de API-oproepen van de inhoud. Het LMS kan geen communicatie initiëren, het lanceert gewoon de inhoud en reageert op verzoeken.

de SCORM API bevat acht methoden met de volgende handtekeningen:

SCORM 2004

Initialize( "" ) : bool Terminate( "" ) : bool GetValue( element : CMIElement ) : string SetValue( element : CMIElement, value: string): string Commit ( "" ): bool GetLastError (): CMIErrorCode GetErrorString ( errorCode: CMIErrorCode ): string GetDiagnostic (errocCode: 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

de methodenamen variëren enigszins tussen SCORM versies, maar conceptueel zijn de methoden identiek.

opmerkingen:

• het bool type is een SCORM boolean, wat eigenlijk een string is met de waarde ” true “of”false”.
• de “” parameter is vereist voor alle SCORM methoden die geen andere argumenten accepteren. SCO ‘ s zijn gewoon nodig om een lege string parameter door te geven aan deze methoden.
• het CMIElement-gegevenstype is een string die overeenkomt met de hieronder beschreven elementen van het SCORM-gegevensmodel.
• het CMIErrorCode-gegevenstype is een driecijferig getal, vertegenwoordigd door een string, dat overeenkomt met een van de SCORM Runtime-foutcodes.

Initialize / LMSInitialize

de Initialize methode geeft aan dat de inhoud een communicatiesessie wil beginnen. Alle SCO ‘ s moeten initialiseren aanroepen voordat ze een andere communicatie uitvoeren. De LMS geeft een boolean terug die het succes of falen van de initialisatie aangeeft. Typisch, LMS ‘ s niet nodig om veel initialisatie te doen en zal altijd terugkeren “true”.

Terminate / LMSFinish

de Terminate-methode geeft aan dat de inhoud klaar is met communiceren. Alle SCO ‘ s moeten stoppen. Het aanroepen van Terminate geeft niet per se aan dat de gebruiker klaar is met de SCO, technisch gezien geeft het alleen aan dat de SCO klaar is met communiceren. In de praktijk zal de inhoud echter meer compatibel en bruikbaar zijn als Terminate alleen wordt aangeroepen wanneer de inhoud van de gebruiker kan worden weggenomen. Omdat Terminate altijd moet worden aangeroepen, ongeacht hoe de leerling de SCO verlaat, is het verstandig om een call te plaatsen om te beëindigen in het onunload event van een SCO. De Booleaanse waarde die door de LMS wordt geretourneerd, geeft vaak aan of SCO-gegevens met succes aan de server zijn doorgezet.

GetValue / LMSGetValue

met de GetValue-methode kan een SCO gegevens ophalen uit het LMS. De gegevens die altijd wordt opgehaald is een van de gedefinieerde SCORM data model elementen. Elk van deze gegevensmodel elementen bevat een ander stuk gegevens. Sommige elementen van het datamodel hebben waarden geïnitialiseerd door het LMS die spreken over de omstandigheden waaronder de SCO wordt gelanceerd. Andere waarden worden geïnitialiseerd door de SCO via calls naar SetValue. Als de aanroep naar GetValue een lege tekenreeks retourneert, is het mogelijk dat er een fout is opgetreden en de GetLastError methode moet worden aangeroepen om te controleren op problemen.

SetValue / LMSSetValue

met de SetValue-methode kan de SCO gegevens naar het LMS doorzetten. De gegevens worden altijd opgeslagen in een van de gedefinieerde SCORM data model elementen. Sommige data model elementen zijn beperkt tot het hebben van waarden in een beperkte vocabulaire (bijvoorbeeld, status kan worden “voltooid” of “doorgegeven”), anderen zijn beperkt tot een specifiek gegevenstype (bijvoorbeeld, score moet altijd een nummer), terwijl anderen toestaan dat de SCO vrije tekst gegevens te behouden zonder semantische betekenis. De SetValue aanroep geeft een boolean terug die het succes of falen van de aanroep aangeeft.

Commit / LMSCommit

de Commit methode geeft het LMS aan dat een significante chuck met gegevens is opgeslagen en dat het ervoor moet zorgen dat de gegevens correct blijven staan. Er zijn geen vereisten voor hoe de LMS de Commit methode moet implementeren, het is gewoon een informatief signaal. Sommige LMS ‘ s zullen een retourtje maken naar de server voor elke call om te committen om er zeker van te zijn dat alle data blijft bestaan. Hoewel intuïtief, kan deze implementatiestrategie leiden tot schaalbaarheidsproblemen. Zorg ervoor dat u niet te veel Commit belt om deze LMS ‘ s niet te overbelasten.

GetLastError / LMSGetLastError

de GetLastError methode controleert of de laatste SCORM API aanroep een fout heeft veroorzaakt. Als dat zo is, geeft deze methode een foutnummer terug dat overeenkomt met een gedefinieerde set van mogelijke fouten. Sommige foutnummers vertegenwoordigen volkomen legitieme situaties (zoals 403 – Data Model Element niet geïnitialiseerd). SCO auteurs moeten ervoor zorgen dat alleen legitieme onverwachte fouten aan de gebruiker worden gemarkeerd. De volledige lijst met foutcodes is te vinden in de SCORM run-time referentiegrafiek.

GetErrorString / LMSGetErrorString

gegeven een bepaald foutnummer (meestal het foutnummer geretourneerd van GetLastError), zal de GetErrorString methode een tekstuele beschrijving geven van wat de foutcode betekent. Bijvoorbeeld, in SCORM 2004, het passeren van fout nummer “406” zal een tekenreeks te zeggen “Data Model Element type Mismatch” om aan te geven dat het resultaat van de vorige oproep (waarschijnlijk een SetValue) is mislukt omdat de gegevens die worden opgeslagen was niet in de juiste indeling.

Getdiagnostisch / Lmsgetdiagnostisch

met de Getdiagnostische methode kan het LMS gedetailleerde informatie over de eerdere fout retourneren die nuttig kan zijn bij het diagnosticeren van het probleem. Bijvoorbeeld de diagnostische informatie voor de ” 406 ” fout hierboven vermeld zou kunnen zijn “de waarde ‘nul’ is niet toegestaan voor cmi.scoren.grondstof. De cmi.scoren.raw element moet een geldig getal bevatten dat alleen als cijfers wordt weergegeven”.

het SCORM runtime data model

het runtime data model bevat vele elementen, elk met zijn eigen betekenis. De elementen kunnen worden gelezen en geschreven met behulp van de API. De SCORM run-time referentiegrafiek bevat een lijst van elk data model element samen met het gegevenstype en een korte beschrijving van de betekenis en het gebruik ervan.

elke SCO heeft zijn eigen reeks runtime-gegevens. Elk van deze data model elementen heeft een aparte waarde voor elke SCO binnen een cursus, data model elementen worden niet gedeeld tussen SCOs. Verder heeft elke “poging” op een SCO zijn eigen set runtime data. Wanneer de leerling een nieuwe poging op een SCO start, worden de waarden van het datamodel gereset voor het begin van de nieuwe poging.

de elementen van het gegevensmodel verschillen enigszins tussen SCORM-versies, maar voor het grootste deel is er een overeenkomstig element in elke versie van de standaarden. SCORM 1.1 en SCORM 1.2 hebben identieke datamodellen. SCORM 2004 heeft een andere datamodel set. Er zijn kleine subtiele verschillen tussen de edities van SCORM 2004 ook. De grafiek geeft een uitgebreide referentie voor elke versie/editie. De belangrijkste veranderingen in SCORM 2004 omvatten:

• kleine hernoemen, meestal het verwijderen van de” core ” uit de data model element namen.
• scheiding van status. In SCORM 1.2 een enkel element, cmi.Core.lesson_status vertegenwoordigt de status van de SCO. In SCORM 2004, status is opgesplitst in twee afzonderlijke elementen, cmi.completion_status (voltooid vs onvolledig) en cmi.success_status (doorgegeven vs mislukt).
• interacties (vraagresultaten) zijn lezen/schrijven in plaats van alleen schrijven. Interacties bevatten ook een beschrijvingsveld dat ontbrak in SCORM 1.2.
• toevoeging van adl.navigatiebalk.* gegevensmodel-elementen waarmee de SCO sequentieverzoeken

kan initiëren met behulp van de Run-time

met behulp van de SCORM-run-time is grotendeels optioneel vanuit een strikt conformiteitsperspectief, maar de industrienorm is het gebruik van ten minste een subset van de run-time data model-elementen die voor u beschikbaar zijn.

op de eenvoudigste manier, als uw cursus alleen opstartbare activa bevat, zijn er geen run-time calls nodig. De LMS lanceert gewoon elke asset zoals gevraagd door de gebruiker en het asset wordt geacht onmiddellijk te zijn voltooid bij de lancering.

voor een rijkere interactie is het eerste wat we moeten doen runtime communicatie inschakelen. Dat zal inhouden het vinden van de API en dan ervoor te zorgen dat initialiseren en beëindigen worden genoemd. In de meeste gevallen, Initialize moet worden opgeroepen onmiddellijk nadat de SCO is gestart. Zodra initialize is aangeroepen, is het essentieel dat Terminate wordt aangeroepen in elk exit scenario.

zodra de communicatie is geïnitialiseerd, is het tijd om te beginnen met het daadwerkelijk communiceren van gegevens. De volgende” 1st tier ” data model elementen zijn de belangrijkste en meest gebruikte (SCORM 1.2 equivalent tussen haakjes):

• cmi.completion_status & cmi.success_status (cmi.Core.lesson_status) – deze gegevens model elementen zijn de meest fundamentele en belangrijke. Ze geven aan wanneer een gebruiker een cursus heeft afgemaakt en of hij geslaagd of mislukt is. Deze fundamentele informatie is essentieel voor de meeste LMS ‘ s.
• cmi.scoren.geschaald (cmi.Core.scoren.raw) – geeft de score aan die de leerling heeft verdiend op een beoordeling binnen een SCO. Het rapporteren van een min en max score in combinatie met een raw score is ook een goede vorm.
• cmi.session_time (cmi.Core.session_time) – rapporteert de hoeveelheid tijd die de leerling doorbracht in de SCO.
• cmi.locatie (cmi.Core.lesson_location) – biedt een vrij tekstveld voor de SCO om een bladwijzer op te nemen. Als de SCO groter is dan slechts een paar HTML-pagina ‘ s, zou het moeten overwegen het implementeren van een bookmarking functie om de leerling te laten hervatten een gepauzeerde poging.
• cmi.exit (cmi.Core.exit) – deze waarde geeft aan hoe de leerling de SCO verlaat. CMI instellen.afsluiten naar “suspend” zal ervoor zorgen dat de huidige poging wordt bewaard en de runtime data niet wordt gereset de volgende keer dat de SCO wordt gestart. CMI instellen.exit naar “” geeft aan dat de LMS een nieuwe poging moet beginnen met een nieuwe set van run-time data bij de volgende lancering van de SCO.

Industry norm verwacht dat alle elementen van 1st tier data models correct worden gebruikt in een SCO. Zodra die functionaliteit is ingeschakeld, omvatten de volgende meest voorkomende gegevensmodel-elementen, of 2nd tier,:

• interacties-gebruik de elementen van het interaction data model om de resultaten van elke vraagrespons te rapporteren. Een interactie hoeft geen traditioneel test antwoord te zijn. Bijvoorbeeld, een SCO kan de keuzes van de leerling documenteren als hij vordert door middel van een simulatie. Gebruik indien mogelijk alle elementen van interacties om een zo volledig mogelijk beeld te krijgen van de reacties van de leerling. Gebruik minimaal “id”, “type”, “result” en “description” om LMS ‘ s in staat te stellen basisrapportage te leveren.
• doelstellingen-overweeg in grote SCO ‘ s verslag uit te brengen over de beheersing van specifieke leerdoelstellingen door de leerling aan de hand van de elementen van het objectives data model. De doelstellingen maken een meer gedetailleerde rapportage van de vooruitgang van de leerling door middel van en beheersing van het trainingsmateriaal mogelijk.
• cmi.progress_measure – gebruik het progress_measure element in SCORM 2004 om de voortgang van de gebruiker naar de voltooiing van een SCO te rapporteren. De progress_measure is als een “percentage complete” maatregel die het LMS in staat zou stellen om een voortgangsbalk van de totale voltooiing van een cursus te bieden.

Entry, Mode en Credit

de cmi.entry (cmi.Core.entry), cmi.modus (cmi.Core.lesson_mode) en cmi.krediet (cmi.Core.credit) datamodelelementen bieden de SCO enige context die het kan gebruiken om de leerling de optimale ervaring te bieden.

• cmi.entry geeft aan of de gebruiker de SCO voor de eerste keer start of dat het een eerdere poging hervat. Als bookmarking wordt gebruikt, kan de SCO deze waarde gebruiken om de gebruiker te vragen om te beginnen vanaf het begin of vanaf het punt waarop de vorige poging eindigde.
• cmi.modus geeft aan of de cursist deze SCO start: normaal – in een “live” training sessie; in browse mode – de gebruiker bladert door een catalogus van training en wil “preview” deze cursus; of, in review mode – de gebruiker heeft de SCO al voltooid en komt terug om het materiaal te beoordelen. In de bladermodus zou de SCO-auteur moeten overwegen om het SCOs-gedrag te wijzigen om meer vrije vormnavigatie te bieden, een overzicht of kaart van de cursus te bieden en mogelijk assessments te verbergen. In de review-modus moet de SCO-auteur ook overwegen om de slanker volledige vrijheid van navigatie toe te staan. In de review-modus kan de leerling ook vrij door tests navigeren en door een lijst met correcte antwoorden bladeren. Wanneer een SCO wordt gestart in de review-modus, moet hij voorzichtig zijn om de status van de leerling niet te veranderen of de score niet te resetten.
• cmi.krediet geeft aan of deze SCO wordt geprobeerd om krediet te krijgen, of dat het al dan niet “telt”. Vergelijkbaar met browse mode, als een SCO wordt gestart zonder krediet, het gedrag moet waarschijnlijk worden gewijzigd.