SCORM Run – Time Environment

Oversikt OVER SCORM Run – time environment

scorm Run-Time specification styrer hvordan LMS lanserer innhold og hvordan innholdet deretter kommuniserer MED LMS. All denne kommunikasjonen skjer innenfor rammen av et enkelt forsøk på en ENKELT SCO. Navigasjonen mellom SCOs styres av sekvenseringen spesifisert i manifestet, og forklares nærmere her.

Lansering av innhold

ALT SCORM-innhold må være webleverbart, og ALL SCORM-kommunikasjon skjer i sammenheng med en nettleserøkt. LMS vil lansere EN SCO om gangen, som valgt av brukeren, eller som bestemt AV scorm 2004 sekvenseringsregler. I versjoner før SCORM 2004 3rd Edition var det ingen formelle krav til brukergrensesnittet som ble levert av EN LMS. Hver LMS er litt annerledes,men for det meste er det rimelig å forvente AT EN LMS gir et grensesnitt som ligner på bildet nedenfor. Som et minimum bør den inneholde noen form for navigerbar innholdsfortegnelse samt kontroller for flytnavigasjon (forrige og neste knapper). Disse navigasjonselementene styrer navigasjonen mellom SCOs. Hvis navigasjon er nødvendig innenfor EN SCO, MÅ SCO gi sine egne navigasjonselementer.

LMS har to alternativer for å starte EN SCO. DET kan enten starte SCO ina frameset (som vist ovenfor), eller det kan starte SCO i et nytt vindu. NOEN LMS vil alltid lansere innhold på en eller annen måte. Vanligvis skjønt, hvis et kurs bare inneholder EN SCO (og dermed ikke krever og navigasjonselementer fra LMS), VIL SCO bli lansert i et popup-vindu. Omvendt, hvis kurset inneholder mange SCOs, vil LMS vanligvis starte SCOs i et rammesett omgitt av navigasjonselementer. NOEN LMS-er vil tillate innholdsforfatterne å kontrollere nøyaktig hvordan SCOs lanseres, hvilke navigasjonselementer som er tilgjengelige og til OG med STØRRELSEN PÅ SCO-vinduene.

API

all kommunikasjon mellom EN SCO og LMS skjer gjennom En Ecmascript (JavaScript) API. Dette er den eneste måten for kommunikasjon å skje. Det er ingen andre kommunikasjonskanaler tilgjengelig. Innhold kan ikke kommunisere via webtjenester, skjema innlegg, database skriver eller noen annen mekanisme, bare Gjennom JavaScript API levert AV LMS.

Finne API

LMS er ansvarlig for å gi et Spesifikt Navngitt JavaScript-objekt på et bestemt sted i nettleserens DOM. Dermed kan innholdet alltid finne DENNE API-EN ved hjelp av en felles algoritme.

I SCORM 1.1 OG SCORM 1.2 HETER API-objektet alltid «API». I SCORM 2004 heter objektet «API_1484_11».

API-objektet skal være plassert i et vindu som er en forelder FOR SCO eller en forelder for åpningsvinduet TIL SCO. Et» overordnet » vindu er definert som hele kjeden av overordnede vinduer helt opp til rotleservinduet. SÅ, API-EN kan være I SCOS foreldre, SCOS foreldres foreldre, SCOS foreldres foreldres foreldre, etc. PÅ samme måte KAN API være i åpningsvinduet, åpnerens foreldre, åpnerens foreldres foreldre, etc. Diagrammene nedenfor FRA scorm 2004 3rd Edition spesifikasjonen illustrerer mulige API steder.

SCORM inneholder spesifikke algoritmer som innholdet kan bruke til å finne SCORM API.

VED HJELP AV API

Når EN SCO har funnet SCORM API, kan DEN bruke API til å kommunisere med LMS. Merk at BARE SCO kan starte kommunikasjon. LMS ER en passiv enhet som bare reagerer PÅ API-kallene fra innholdet. LMS kan ikke starte noen kommunikasjon, det lanserer bare innholdet og svarer på forespørsler.

SCORM API inneholder åtte metoder med følgende signaturer:

SCORM 2004

 Initialiser( "" ) : bool Avslutte( "" ) : bool GetValue( element : CMIElement ) : streng SetValue (element : CMIElement, verdi: streng ) : String Commit ( "" ): bool GetLastError (): CMIErrorCode GetErrorString( errorCode : CMIErrorCode): streng GetDiagnostic( errocCode : CMIErrorCode): streng

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

metodenavnene varierer litt MELLOM SCORM-versjoner, men konseptuelt er metodene identiske.

Notater:

• bool-typen er EN SCORM boolsk, som faktisk er en streng som har verdien «true» eller «false».
• parameteren «» kreves av ALLE SCORM-metoder som ikke godtar andre argumenter. SCOs er bare nødvendig for å sende en tom strengparameter til disse metodene.
• Datatypen CMIElement er en streng som svarer TIL scorm-datamodellelementene som er beskrevet nedenfor.
• Datatypen CMIErrorCode er et tresifret tall, representert en streng, som tilsvarer EN AV Scorms Kjøretidsfeilkoder.

Initialiser / Lmsinitialiser

Initialiser-metoden angir FOR LMS at innholdet ønsker å starte en kommunikasjonsøkt. Alle SCOs må ringe Initialisere før du utfører annen kommunikasjon. LMS returnerer en boolsk som indikerer suksess eller fiasko for initialiseringen. VANLIGVIS TRENGER LMS ikke å gjøre mye initialisering og vil alltid returnere «sant».

Avslutt / LMSFinish

Avslutt-metoden angir FOR LMS at innholdet er ferdig med å kommunisere. Alle SCOs ma ringe Avslutte. Å Ringe Avslutte betyr ikke nødvendigvis at brukeren er ferdig MED SCO, teknisk sett indikerer DET bare AT SCO er ferdig med å kommunisere. I praksis vil imidlertid innholdet være mer kompatibelt og brukbart hvis Terminering bare kalles når innholdet kan tas bort fra brukeren. Siden Terminering er nødvendig for å alltid bli kalt, uansett hvordan eleven avslutter SCO, er det lurt å ringe For Å Avslutte i onunload-hendelsen TIL EN SCO. Den boolske verdien som returneres av LMS, indikerer ofte OM SCO-data ble opprettholdt til serveren.

GetValue / LMSGetValue

GetValue-metoden lar EN SCO hente data fra LMS. Dataene som alltid hentes, er en av de definerte scorm-datamodellelementene. Hver av disse datamodellelementene inneholder et annet stykke data. Noen av datamodellelementene har verdier initialisert AV LMS som snakker til omstendighetene UNDER HVILKE SCO blir lansert. ANDRE verdier initialiseres AV SCO gjennom kall Til SetValue. Hvis kallet Til GetValue returnerer en tom streng, er det mulig at det oppstod en feil, Og GetLastError-metoden skal startes for å se etter problemer.

SetValue / LMSSetValue

SetValue-metoden tillater SCO å beholde data TIL LMS. Dataene lagres alltid i et av de definerte scorm-datamodellelementene. Noen datamodellelementer er begrenset til å ha verdier i et begrenset ordforråd (for eksempel status kan være «fullført» eller «bestått»), andre er begrenset til å være en bestemt datatype (for eksempel må poengsum alltid være et tall) mens andre tillater SCO å fortsette fritekstdata uten semantisk betydning. SetValue-anropet returnerer en boolsk som indikerer at anropet er vellykket eller mislykket.

Commit / LMSCommit

Commit-metoden signaliserer TIL Lms at en betydelig chuck av data er lagret, og at den skal sikre at dataene er riktig vedvarende. Det er ingen krav til HVORDAN LMS skal implementere Commit-metoden, det er bare et informativt signal. Noen LMS ‘ er vil gjøre en rundtur til serveren for hver samtale Å Forplikte seg til å sikre at alle data vedvarer. Mens intuitiv, kan denne implementeringsstrategien føre til skalerbarhetsproblemer. Pass på å ikke ringe Begå overdrevet for ikke å overbelaste DISSE LMS.

GetLastError / LMSGetLastError

GetLastError-metoden kontrollerer om det siste SCORM API-anropet forårsaket en feil. I så fall returnerer denne metoden et feilnummer som tilsvarer et definert sett med mulige feil. Noen feilnumre representerer helt legitime situasjoner (for eksempel 403 – Datamodellelement Ikke Initialisert). SCO forfattere bør passe på å bare flagge legitimt uventede feil til brukeren. Den komplette listen over feilkoder finner DU i SCORM run-time reference chart.

GetErrorString / LMSGetErrorString

Gitt et bestemt feilnummer (vanligvis feilnummeret returnert Fra GetLastError), Vil GetErrorString-metoden returnere en tekstlig beskrivelse av hva feilkoden betyr. FOR EKSEMPEL, I SCORM 2004, passerer feilnummeret » 406 «vil returnere en streng som sier» Data Model Element Type Mismatch » for å indikere at resultatet av forrige samtale (sannsynligvis En SetValue) mislyktes fordi dataene som lagres ikke var i riktig format.

GetDiagnostic / LMSGetDiagnostic

GetDiagnostic metoden lar lms å returnere detaljert informasjon om tidligere feil som kan være nyttig i diagnostisering av problemet. For eksempel kan den diagnostiske informasjonen for» 406 «- feilen nevnt ovenfor være «verdien» null » er ikke tillatt for cmi.score.råvare. Cmi.score.rå element må inneholde et gyldig tall representert bare som sifre».

SCORM Run-Time datamodell

run-time datamodellen inneholder mange elementer, hver med sin egen betydning. Elementene kan leses og skrives ved HJELP AV API. SCORMS kjøretidsreferansediagram inneholder en liste over hvert datamodellelement sammen med datatypen OG en kort beskrivelse av dens betydning og bruk.

HVER SCO har sitt eget sett med kjøretidsdata. Hver av disse datamodellelementene har en egen verdi for HVER SCO i et emne, datamodellelementer deles ikke på Tvers Av Sco-Er. Videre har hvert «forsøk» på EN SCO sitt eget sett med kjøretidsdata. Når eleven starter et nytt FORSØK PÅ EN SCO, tilbakestilles datamodellverdiene for starten av det nye forsøket.

datamodellelementene er litt forskjellige PÅ TVERS AV SCORM-versjoner, men for det meste er det et tilsvarende element i hver versjon av standardene. SCORM 1.1 og SCORM 1.2 har identiske datamodeller. SCORM 2004 har et annet datamodellsett. DET er også små små forskjeller mellom utgavene AV SCORM 2004. Diagrammet gir en omfattende referanse for hver versjon/utgave. DE viktigste endringene I SCORM 2004 inkluderer:

• Mindre omdøping, for det meste å fjerne «kjernen» fra datamodellelementnavnene.
• Separasjon av status. I SCORM 1.2 et enkelt element, cmi.kjerne.lesson_status representerer SCOS status. I SCORM 2004 er status delt inn i to separate elementer, cmi.completion_status (fullført vs ufullstendig) og cmi.success_status (bestått vs mislyktes).
• Interaksjoner (spørsmålsresultater) leses / skrives i stedet for bare skriving. Interaksjoner inneholder også et beskrivelsesfelt som manglet I SCORM 1.2.
• Tillegg av adl.nav.* datamodellelementer som tillater SCO å starte sekvenseringsforespørsler

Ved Hjelp av Kjøretiden

VED HJELP AV SCORM-kjøretiden, er i stor grad valgfritt fra et strengt samsvarsperspektiv, men bransjestandarden er å bruke minst et delsett av kjøretidsdatamodellelementene som er tilgjengelige for deg.

på det enkleste, hvis emnet ditt ikke inneholder annet enn startbare ressurser, er det ikke nødvendig med kjøretidssamtaler. LMS lanserer bare hver eiendel som forespurt av brukeren, og eiendelen anses å være fullført umiddelbart etter lansering.

for en rikere interaksjon er det første vi må gjøre, å aktivere kjøretidskommunikasjon. Det vil innebære å finne API og deretter sikre At Initialisere og Avslutte kalles. I De fleste tilfeller Bør Initialize kalles umiddelbart etter AT SCO er lansert. Når initialize har blitt kalt, er Det viktig At Avslutte kalles i hver exit scenario.

når kommunikasjonen er initialisert, er det på tide å begynne å kommunisere data. Følgende» 1st tier » datamodellelementer er de viktigste og mest brukte (SCORM 1.2 ekvivalent i parentes):

• cmi.fullføring_status & cmi .success_status (cmi.kjerne.lesson_status) – disse datamodellelementene er de mest grunnleggende og viktige. De indikerer når en bruker har fullført et emne, og om han har bestått eller mislyktes. Denne grunnleggende informasjonen er viktig for DE FLESTE LMS.
• cmi.score.skalert (cmi.kjerne.score.raw) – Indikerer poengsummen som eleven tjente på en vurdering i EN SCO. Rapportering en min og max score i forbindelse med en rå score er også god form.
• cmi.session_time (cmi.kjerne.session_time) – Rapporterer hvor mye tid som eleven brukt I SCO.
• cmi.plassering (cmi.kjerne.lesson_location – – Gir et fritekstfelt FOR SCO å spille inn et bokmerke. HVIS SCO er større enn BARE ET PAR HTML-sider, bør det vurdere å implementere en bokmerkingsfunksjon for å la eleven gjenoppta et pauset forsøk.
• cmi.utgang (cmi.kjerne.exit) – denne verdien indikerer hvordan eleven forlater SCO. Innstilling cmi.utgang til «suspendere» vil sikre at gjeldende forsøk bevares og kjøretidsdataene ikke tilbakestilles neste GANG SCO startes. Innstilling cmi.utgang til «» vil indikere AT LMS skal starte et nytt forsøk med et nytt sett med kjøretidsdata ved NESTE lansering AV SCO.

Bransjestandard forventer at alle datamodellelementene i 1.nivå skal brukes riktig i EN SCO. Når denne funksjonaliteten er aktivert, inkluderer de neste vanligste datamodellelementene, eller 2. nivå,:

• interaksjoner-Bruk interaksjonsdatamodellelementene til å rapportere resultatene av hvert spørsmålsrespons. En interaksjon trenger ikke å være et tradisjonelt testsvar. FOR eksempel kan EN SCO dokumentere elevens valg når han utvikler seg gjennom en simulering. Hvis mulig, bruk alle interaksjonselementene for å gi det mest omfattende bildet av elevens svar. Som et minimum, bruk «id», «type», «resultat» og «beskrivelse» for å tillate LMS å gi grunnleggende rapportering.
• mål-i store SCOs, vurdere rapportering på elevens mestring av spesifikke læringsmål ved hjelp av mål datamodell elementer. Mål tillate mer detaljert rapportering av elevens fremgang gjennom og mestring av opplæringsmateriell.
• cmi.progress_measure-Bruk progress_measure-elementet I SCORM 2004 for å rapportere brukerens fremgang mot fullføring av EN SCO. Progress_measure er som et» prosent fullført » mål som vil gjøre DET MULIG FOR LMS å gi en fremdriftslinje for total gjennomføring av et kurs.

Oppføring, Modus Og Kreditt

cmi.oppføring (cmi.kjerne.oppføring), cmi.modus (cmi.kjerne.lesson_mode) og cmi.kreditt (cmi.kjerne.kreditt) datamodellelementer gir SCO en viss kontekst den kan bruke til å gi eleven den optimale opplevelsen.

• cmi.oppføring angir om brukeren starter SCO for første gang, eller om den gjenopptar et tidligere forsøk. HVIS du bruker bokmerke, KAN SCO bruke denne verdien til å be brukeren om å starte fra begynnelsen eller fra punktet der forrige forsøk avsluttet.
• cmi.modus indikerer om eleven starter DENNE SCO: normalt – i en «live» treningsøkt; i bla – modus-leser brukeren en katalog av trening og ønsker å «forhåndsvise» dette kurset; eller, i gjennomgangsmodus – brukeren har allerede fullført SCO og kommer tilbake for å gjennomgå materialet. I bla-modus bør SCO-forfatteren vurdere å endre SCOs-oppførselen for å gi mer fri formnavigasjon, gi oversikt eller kart over kurset og muligens skjule vurderinger. I gjennomgangsmodus bør SCO-forfatteren på samme måte vurdere å tillate slankere fullstendig navigasjonsfrihet. I gjennomgangsmodus kan eleven også fritt navigere i tester og bla gjennom en liste over riktige svar. Når den startes i gjennomgangsmodus, bør EN SCO være forsiktig med å endre elevens status eller tilbakestille poengsummen.
• cmi.kreditt indikerer hvorvidt DENNE SCO blir forsøk på kreditt, eller hvorvidt det «teller». I likhet med browse-modus, hvis EN SCO lanseres uten kreditt, bør oppførselen sannsynligvis endres.