SCORM Run-Time Environment

översikt över SCORM Run-Time environment

SCORM Run-Time specification styr hur LMS startar innehåll och hur innehållet sedan kommunicerar med LMS. All denna kommunikation sker inom ramen för ett enda försök på en enda SCO. Navigeringen mellan SCOs styrs av den sekvensering som anges i manifestet och förklaras vidare här.

starta innehåll

allt SCORM-innehåll måste vara webblevererbart och all SCORM-kommunikation sker inom ramen för en webbläsarsession. LMS kommer att starta en SCO i taget, som valts av användaren, eller som bestäms av SCORM 2004 sekvenseringsregler. I versioner före SCORM 2004 3rd Edition fanns det inga formella krav för användargränssnittet från en LMS. Varje LMS är något annorlunda, men för det mesta är det rättvist att förvänta sig att en LMS tillhandahåller ett gränssnitt som liknar det som visas nedan. Det bör åtminstone innehålla någon form av navigerbar innehållsförteckning samt kontroller för flödesnavigering (föregående och nästa knappar). Dessa navigeringselement styr navigeringen mellan SCOs. Om navigering behövs inom en SCO måste SCO tillhandahålla sina egna navigeringselement.

LMS har två alternativ för att starta en SCO. Det kan antingen starta SCO ina ramuppsättning (som bilden ovan), eller det kan starta SCO i ett nytt fönster. Vissa LMS kommer alltid att starta innehåll på ett eller annat sätt. Vanligtvis om en kurs bara innehåller en SCO (och därmed inte kräver och navigeringselement från LMS), kommer SCO att startas i ett popup-fönster. Omvänt, om kursen innehåller många SCOs, kommer LMS vanligtvis att starta SCOs i en ramuppsättning omgiven av navigeringselement. Vissa LMS gör det möjligt för innehållsförfattarna att kontrollera exakt hur SCOs lanseras, vilka navigeringselement som är tillgängliga och till och med storleken på SCO-fönstren.

API: et

all kommunikation mellan en SCO och LMS sker via ett ECMAScript (JavaScript) API. Detta är det enda sättet att kommunicera. Det finns inga andra kommunikationskanaler tillgängliga. Innehåll kan inte kommunicera via webbtjänster, formulärinlägg, databasskrivningar eller någon annan mekanism, bara via JavaScript API som tillhandahålls av LMS.

hitta API

LMS ansvarar för att tillhandahålla ett specifikt namngivet JavaScript-objekt på en viss plats i webbläsarens DOM. Således kan innehållet alltid lokalisera detta API med hjälp av en gemensam algoritm.

i SCORM 1.1 och SCORM 1.2 heter API-objektet alltid ”API”. I SCORM 2004 heter objektet ”API_1484_11”.

API-objektet ska placeras i ett fönster som är en förälder till SCO eller en förälder till SCO: s öppnarfönster. Ett” förälder ” – fönster definieras som hela kedjan av föräldrafönster hela vägen upp till root-webbläsarfönstret. Så API kan vara i SCO: s förälder, SCO: s förälders förälder, SCO: s förälders förälders förälder etc. På samma sätt kan API vara i öppnarfönstret, öppnarens förälder, öppnarens förälders förälder etc. Diagrammen nedan från SCORM 2004 3rd Edition-specifikationen illustrerar de möjliga API-platserna.

SCORM innehåller specifika algoritmer som innehåll kan använda för att hitta SCORM API.

använda API

när en SCO har hittat SCORM API kan den använda API för att kommunicera med LMS. Observera att endast SCO kan initiera kommunikation. LMS är en passiv enhet som helt enkelt svarar på API-anrop som görs av innehållet. LMS kan inte initiera någon kommunikation, Det startar helt enkelt innehållet och svarar på förfrågningar.

SCORM API innehåller åtta metoder med följande signaturer:

SCORM 2004

initialisera( "" ) : Bool avsluta( "" ) : bool GetValue( element : CMIElement ) : string SetValue (element : CMIElement, värde : sträng): sträng Commit ( "" ): bool GetLastError (): CMIErrorCode GetErrorString( errorCode: CMIErrorCode ): sträng GetDiagnostic ( errocCode: CMIErrorCode): sträng

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

metodnamnen varierar något mellan SCORM-versioner, men konceptuellt är metoderna identiska.

anmärkningar:

• bool-typen är en SCORM boolean, som faktiskt är en sträng med värdet ”sant” eller ”falskt”.
• parametern ”” krävs av alla SCORM-metoder som inte accepterar några andra argument. SCOs krävs helt enkelt för att skicka en tom strängparameter till dessa metoder.
• datatypen CMIElement är en sträng som motsvarar SCORM-datamodellen som beskrivs nedan.
• cmierrorcode-datatypen är ett tresiffrigt tal, representerat en sträng, som motsvarar en av SCORM Run-Time-felkoderna.

Initialize / LMSInitialize

Initialize-metoden indikerar för LMS att innehållet vill starta en kommunikationssession. Alla SCOs måste anropa Initialize innan någon annan kommunikation utförs. LMS returnerar en boolesk som anger initialiseringens framgång eller misslyckande. Vanligtvis behöver LMS inte göra mycket initialisering och kommer alltid att returnera ”sant”.

avsluta / LMSFinish

avsluta-metoden indikerar för LMS att innehållet är klart kommunicerat. Alla SCOs måste ringa avsluta. Att ringa avsluta indikerar inte nödvändigtvis att användaren är klar med SCO, Tekniskt indikerar det bara att SCO är klar att kommunicera. I praktiken blir innehållet dock mer kompatibelt och användbart om Avsluta endast anropas när innehållet kan tas bort från användaren. Eftersom avsluta krävs för att alltid kallas, oavsett hur eleven lämnar SCO, är det klokt att ringa ett samtal för att avsluta i onunload händelse av en SCO. Det booleska värdet som returneras av LMS indikerar ofta huruvida SCO-data framgångsrikt kvarstod på servern.

GetValue / LMSGetValue

GetValue-metoden tillåter en SCO att hämta data från LMS. Data som alltid hämtas är ett av de definierade SCORM – datamodellelementen. Var och en av dessa datamodellelement innehåller olika data. Några av datamodellen element har värden initieras av LMS som talar till de omständigheter under vilka SCO lanseras. Andra värden initieras av SCO genom samtal till SetValue. Om samtalet till GetValue returnerar en tom sträng är det möjligt att ett fel inträffade och GetLastError-metoden ska åberopas för att kontrollera om det finns problem.

SetValue / LMSSetValue

SetValue-metoden tillåter SCO att fortsätta data till LMS. Data lagras alltid i ett av de definierade SCORM-datamodellelementen. Vissa datamodellelement är begränsade till att ha värden i ett begränsat ordförråd (till exempel kan status vara ”färdig” eller ”godkänd”), andra är begränsade till att vara en specifik datatyp (till exempel måste poäng alltid vara ett tal) medan andra tillåter SCO att fortsätta fritextdata utan semantisk mening. SetValue-samtalet returnerar en boolesk som indikerar framgång eller misslyckande av samtalet.

Commit / LMSCommit

Commit-metoden signalerar till LMS att en betydande chuck av data har sparats och att den ska säkerställa att data är korrekt kvar. Det finns inga krav på hur LMS ska implementera Commit-metoden, det är helt enkelt en informativ signal. Vissa LMS kommer att göra en rundresa till servern för varje samtal för att förbinda sig för att säkerställa att all data kvarstår. Även om det är intuitivt kan denna implementeringsstrategi leda till skalbarhetsproblem. Var noga med att inte ringa begå alltför för att inte överbelasta dessa LMS.

GetLastError / LMSGetLastError

GetLastError-metoden kontrollerar om det senaste SCORM API-anropet orsakade ett fel. Om så är fallet returnerar den här metoden ett felnummer som motsvarar en definierad uppsättning möjliga fel. Vissa felnummer representerar helt legitima situationer (till exempel 403 – Datamodellelement som inte initierats). SCO-författare bör se till att endast flagga legitimt oväntade fel för användaren. Den fullständiga listan över felkoder finns i SCORM run-time reference chart.

GetErrorString / LMSGetErrorString

givet ett visst felnummer (vanligtvis felnumret som returneras från GetLastError) kommer geterrorstring-metoden att returnera en textbeskrivning av vad felkoden betyder. Till exempel, i SCORM 2004, passerar felnummer ”406” kommer att returnera en sträng som säger ”Data Model Element Type Mismatch” för att indikera att resultatet av det tidigare samtalet (sannolikt en SetValue) misslyckades eftersom data som lagras inte var i rätt format.

GetDiagnostic / LMSGetDiagnostic

GetDiagnostic-metoden gör det möjligt för LMS att returnera detaljerad information om det tidigare felet som kan vara användbart vid diagnos av problemet. Till exempel kan den diagnostiska informationen för felet ”406” som nämns ovan vara ”värdet” noll ” är inte tillåtet för cmi.Betyg.råvara. Cmi.Betyg.raw-elementet måste innehålla ett giltigt nummer som endast representeras som siffror”.

SCORM Run-Time data model

run-time data model innehåller många element, var och en har sin egen betydelse. Elementen kan läsas och skrivas med hjälp av API. SCORM run-time reference-diagrammet innehåller en lista över varje datamodellelement tillsammans med dess datatyp och en kort beskrivning av dess betydelse och användning.

varje SCO har sin egen uppsättning körtidsdata. Var och en av dessa datamodellelement har ett separat värde för varje SCO inom en kurs, datamodellelement delas inte över SCO. Dessutom har varje ”försök” på en SCO sin egen uppsättning körtidsdata. När eleven startar ett nytt försök på en SCO återställs datamodellvärdena för början av det nya försöket.

datamodellelementen skiljer sig något mellan SCORM-versionerna, men för det mesta finns det ett motsvarande element i varje version av standarderna. SCORM 1.1 och SCORM 1.2 har identiska datamodeller. SCORM 2004 har en annan datamodelluppsättning. Det finns mindre subtila skillnader mellan utgåvorna av SCORM 2004 också. Diagrammet ger en omfattande referens för varje version/utgåva. De viktigaste förändringarna i SCORM 2004 inkluderar:

• mindre namnbyte, mestadels avlägsnande av” kärnan ” från datamodellens elementnamn.
• Separation av status. I SCORM 1.2 ett enda element, cmi.kärna.lesson_status representerar SCO: s status. I SCORM 2004 är status uppdelad i två separata element, cmi.completion_status (färdig vs ofullständig) och cmi.success_status (godkänd vs misslyckades).
• interaktioner (frågeresultat) läses/skrivs istället för att bara skriva. Interaktioner innehåller också ett beskrivningsfält som saknades i SCORM 1.2.
• tillägg av adl.satellitnavigering.* datamodellelement som gör det möjligt för SCO att initiera sekvenseringsbegäranden

använda Run-time

använda SCORM run-time är i stort sett valfritt ur ett strikt överensstämmelseperspektiv, men branschnormen är att använda åtminstone en delmängd av run-time-datamodellelement som är tillgängliga för dig.

om din kurs inte innehåller något annat än startbara tillgångar behövs inga run-time-samtal. LMS lanserar helt enkelt varje tillgång som begärts av användaren och tillgången anses vara klar omedelbart efter lanseringen.

för en rikare interaktion är det första vi behöver göra att aktivera körtidskommunikation. Det kommer att innebära att hitta API och sedan se till att initialisera och avsluta kallas. I de flesta fall bör Initialize ringas omedelbart efter att SCO har lanserats. När initialisera har kallats, är det viktigt att avsluta kallas i varje exit scenario.

när kommunikationen har initierats är det dags att börja kommunicera data. Följande” 1st tier ” datamodellelement är de viktigaste och mest använda (SCORM 1.2 motsvarande inom parentes):

• cmi.completion_status & cmi.success_status (cmi.kärna.lesson_status) – dessa datamodellelement är de mest grundläggande och viktiga. De anger när en användare har avslutat en kurs och om han passerade eller misslyckades. Denna grundläggande information är väsentlig för de flesta LMS.
• cmi.Betyg.skalad (cmi.kärna.Betyg.raw) – anger poängen som eleven tjänat på någon bedömning inom en SCO. Att rapportera en min-och max-poäng i samband med en raw-poäng är också bra form.
• cmi.session_time (cmi.kärna.session_time) – rapporterar den tid som eleven tillbringade i SCO.
• cmi.plats (cmi.kärna.lesson_location) – ger en fri textfält för SCO att spela in ett bokmärke. Om SCO är större än bara ett par HTML-sidor bör den överväga att implementera en bokmärkningsfunktion för att låta eleven återuppta ett pausat försök.
• cmi.utgång (cmi.kärna.exit) – detta värde anger hur eleven lämnar SCO. Inställning cmi.avsluta till” suspend ” kommer att säkerställa att det aktuella försöket bevaras och körtidsdata återställs inte nästa gång SCO startas. Inställning cmi.avsluta till ”” kommer att indikera att LMS bör börja ett nytt försök med en ny uppsättning körtidsdata vid nästa lansering av SCO.

Industry norm förväntar alla 1st tier datamodeller element som ska användas korrekt i en SCO. När den funktionen har aktiverats inkluderar de näst vanligaste datamodellelementen, eller 2: a nivån:

• interaktioner-använd interaktionsdatamodellelementen för att rapportera resultaten av varje frågesvar. En interaktion behöver inte vara ett traditionellt testsvar. Till exempel kan en SCO dokumentera elevens val när han fortskrider genom en simulering. Om möjligt, använd alla interaktionselement för att ge den mest omfattande bilden av elevens svar. Använd åtminstone ”id”, ”type”, ”result” och ”description” för att tillåta LMS att tillhandahålla grundläggande rapportering.
• mål – i stora SCO: er, överväga att rapportera om elevens behärskning av specifika inlärningsmål med hjälp av målen datamodellelement. Mål möjliggör mer detaljerad rapportering av elevens framsteg genom och behärskning av utbildningsmaterialet.
• cmi.progress_measure-använd progress_measure elementet i SCORM 2004 för att rapportera användarens framsteg mot slutförandet av en SCO. Progress_measure är som en” procent komplett ” åtgärd som skulle göra det möjligt för LMS att tillhandahålla en förloppsindikator för övergripande slutförande av en kurs.

inträde, läge och kredit

cmi.inträde (cmi.kärna.inträde), cmi.läge (cmi.kärna.lesson_mode) och cmi.kredit (cmi.kärna.credit) datamodellelement ger SCO med något sammanhang som den kan använda för att ge eleven den optimala upplevelsen.

• cmi.posten anger om användaren startar SCO för första gången eller om den återupptar ett tidigare försök. Om du använder bokmärkning kan SCO använda detta värde för att uppmana användaren att börja från början eller från den punkt där föregående försök slutade.
• cmi.läge anger om eleven startar denna SCO: normalt – i en ” live ”träningspass; i bläddringsläge – användaren bläddrar i en katalog över utbildning och vill” förhandsgranska ” den här kursen; eller, i granskningsläge – användaren har redan slutfört SCO och kommer tillbaka för att granska materialet. I bläddringsläge bör SCO-författaren överväga att ändra SCOs-beteendet för att ge mer fri formnavigering, ge en översikt eller karta över kursen och eventuellt dölja bedömningar. I granskningsläge bör SCO-författaren på samma sätt överväga att tillåta den smalare fullständiga navigeringsfriheten. I granskningsläge kan eleven också fritt navigera i alla tester och bläddra i en lista med korrekta svar. När den startas i granskningsläge bör en SCO vara försiktig så att den inte ändrar elevens status eller återställer poängen.
• cmi.kredit indikerar huruvida denna SCO försöker kredit, eller huruvida det ”räknas”eller inte. I likhet med bläddringsläge, om en SCO lanseras utan kredit, bör beteendet förmodligen ändras.