SCORM Run-Time Environment

Overview of the SCORM Run-Time environment

SCORM Run-Time specification säätelee, miten LMS käynnistää sisällön ja miten sisältö sitten kommunikoi LMS: n kanssa. Kaikki tämä viestintä tapahtuu yhden SCO: n vastaisen yrityksen yhteydessä. Navigointia SCOs: n välillä säätelee manifestissa määritelty sekvensointi, joka selitetään tarkemmin tässä.

sisällön käynnistäminen

kaiken SCORM-sisällön on oltava web-toimitettavissa ja kaikki SCORM-viestintä tapahtuu web-selainistunnon yhteydessä. LMS käynnistää yhden SCO kerrallaan käyttäjän valitsemana tai SCORM 2004-sekvensointisääntöjen mukaisesti. SCORM 2004 3rd Edition-versiota edeltäneissä versioissa ei ollut muodollisia vaatimuksia LMS: n tarjoamalle käyttöliittymälle. Jokainen LMS on hieman erilainen, mutta suurimmaksi osaksi, se on reilua odottaa LMS tarjota käyttöliittymä samanlainen kuin kuvassa alla. Sen tulisi sisältää vähintään jonkinlainen navigoitavissa oleva sisällysluettelo sekä virtaussuunnistuksen hallintalaitteet (edellinen ja seuraava painike). Nämä navigointielementit ohjaavat navigointia SCOs: n välillä. Jos SCO: ssa tarvitaan navigointia, SCO: n on tarjottava omat navigointielementtinsä.

LMS: llä on kaksi vaihtoehtoa SCO: n käynnistämiseksi. Se voi joko käynnistää SCO ina kehyssetti (kuten kuvassa edellä), tai se voi käynnistää SCO uudessa ikkunassa. Jotkut LMS: t käynnistävät sisällön aina tavalla tai toisella. Yleisesti kuitenkin, jos kurssi sisältää vain yhden SCO (ja siten ei vaadi ja navigointielementtejä LMS), SCO käynnistetään ponnahdusikkunassa. Vastaavasti, jos kurssi sisältää useita SCOs, niin LMS yleensä käynnistää SCOs kehyssetti ympäröi navigointielementtejä. Jotkut LMS: t antavat sisällön tekijöille mahdollisuuden valvoa tarkasti, miten SCOs käynnistetään, mitkä navigointielementit ovat käytettävissä ja jopa Sco-ikkunoiden koko.

API

kaikki viestintä SCO: n ja LMS: n välillä tapahtuu ECMAScript (JavaScript) API: n kautta. Tämä on ainoa tapa kommunikoida. Muita viestintäkanavia ei ole. Sisältö ei voi kommunikoida verkkopalvelujen, lomakkeiden, tietokantakirjoitusten tai minkään muun mekanismin kautta, ainoastaan LMS: n tarjoaman JavaScript-API: n kautta.

API: n löytäminen

LMS on vastuussa erityisesti nimetyn JavaScript-objektin tarjoamisesta tiettyyn paikkaan selaimen Domissa. Siten, sisältö, voi aina paikantaa tämän API käyttäen yhteistä algoritmia.

SCORM 1.1: ssä ja SCORM 1.2: ssa API-olion nimi on aina ”API”. SCORM 2004: ssä kohteen nimi on ”API_1484_11”.

API-objektin tulee sijaita ikkunassa, joka on SCO: n vanhempi tai SCO: n avaavan ikkunan vanhempi. ”Vanhempi” ikkuna on määritelty koko ketjun vanhemman ikkunat aina juuriselainikkunan. Niin, API voisi olla SCO vanhemman, SCO vanhemman vanhemman, SCO vanhemman vanhemman, jne. Vastaavasti API voisi olla avaajan ikkunassa, avaajan vanhemmassa, avaajan vanhemman vanhemmassa jne. SCORM 2004 3rd Edition-spesifikaation alla olevat kaaviot kuvaavat mahdollisia API-sijainteja.

SCORM sisältää erityisiä algoritmeja, joiden avulla sisältö voi löytää SCORM-API: n.

käyttäen API: a

kun SCORM-API on löytynyt, se voi käyttää API: a kommunikoidakseen LMS: n kanssa. Huomaa, että vain SCO voi aloittaa viestinnän. LMS on passiivinen kokonaisuus, joka yksinkertaisesti vastaa sisällön tekemiin API-kutsuihin. LMS ei voi aloittaa mitään viestintää, se vain käynnistää sisällön ja vastaa pyyntöihin.

SCORM API sisältää kahdeksan menetelmää, joilla on seuraavat allekirjoitukset:

SCORM 2004

Initialize( "" ) : bool Terminal( "" ) : bool GetValue( element : CMIElement ) : string SetValue( element : CMIElement, arvo : string) : string Commit ( "" ): bool Getrasterror (): 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

menetelmien nimet vaihtelevat hieman SCORM-versioiden välillä, mutta käsitteellisesti menetelmät ovat identtisiä.

huomautukset:

• boolin tyyppi on SCORM Boolen, joka on todellisuudessa merkkijono, jonka arvo on ”tosi”tai ” epätosi”.
• ” – parametria vaaditaan kaikissa SCORM-menetelmissä, jotka eivät hyväksy muita argumentteja. Sco: ita vaaditaan yksinkertaisesti siirtämään tyhjä merkkijonoparametri näihin menetelmiin.
• CMIElement – tietotyyppi on merkkijono, joka vastaa alla kuvattuja SCORM-tietomallin elementtejä.
• CMIErrorCode-tietotyyppi on kolminumeroinen luku, joka esittää merkkijonoa, joka vastaa yhtä SCORM-suoritusajan virhekoodia.

Initialize / LMSInitialize

Initialize-menetelmä osoittaa LMS: lle, että sisältö haluaisi aloittaa viestintäistunnon. Kaikki SCOs on kutsuttava alustaa ennen kuin suorittaa mitään muuta viestintää. LMS palauttaa Boolen, joka osoittaa alustuksen onnistumisen tai epäonnistumisen. Tyypillisesti LMS: n ei tarvitse tehdä paljon alustusta ja palaa aina ”true”.

Terminate / LMSFinish

Terminointimenetelmä osoittaa LMS: lle, että sisältö on tehty viestinnäksi. SCOs: n pitää lopettaa. Kutsuminen lopettaa ei välttämättä tarkoita, että käyttäjä on tehnyt SCO, teknisesti se vain osoittaa SCO on tehty kommunikoida. Käytännössä sisältö on kuitenkin yhteensopivampaa ja käyttökelpoisempaa, jos lopetetaan vasta, kun Sisältö voidaan ottaa käyttäjältä pois. Koska päättyminen on aina kutsuttava, riippumatta siitä, miten oppija poistuu SCO: sta, on viisasta kutsua Päättyminen SCO: n onunload-tapauksessa. LMS: n palauttama Boolen-arvo ilmaisee usein, onko SCO-tietoja onnistuttu jatkamaan palvelimelle.

GetValue / LMSGetValue

GETVALUE-menetelmän avulla SCO voi hakea tietoja LMS: stä. Aina haettava data on yksi määritellyistä SCORM – tietomallin elementeistä. Jokainen näistä tietomallin elementeistä sisältää eri tietopalan. Joissakin tietomallin elementeissä on LMS: n alustamia arvoja, jotka kertovat olosuhteista, joissa SCO käynnistetään. SCO alustaa muut arvot soittamalla Setvaluelle. Jos getvalue-puhelu palauttaa tyhjän merkkijonon, on mahdollista, että tapahtui virhe ja getrasterror-menetelmää tulisi käyttää ongelmien tarkistamiseksi.

SetValue / Lmssetvalue

SetValue-menetelmän avulla SCO voi säilyttää tiedot LMS: lle. Tiedot tallennetaan aina johonkin SCORM-tietomallin määritellyistä elementeistä. Jotkut tietomallin elementit rajoittuvat siihen, että niillä on arvoja suppeassa sanastossa (esimerkiksi tila voi olla ”valmis” tai ”hyväksytty”), toiset rajoittuvat tiettyyn tietotyyppiin (esimerkiksi pistemäärän on aina oltava numero), kun taas toiset sallivat SCO: n säilyttää vapaan tekstitiedon ilman semanttista merkitystä. SetValue-puhelu palauttaa Boolen, joka kertoo puhelun onnistumisesta tai epäonnistumisesta.

Commit / Lmscommit

Commit-menetelmä viestii LMS: lle, että merkittävä määrä tietoja on tallennettu ja että sen pitäisi varmistaa, että tietoja säilytetään asianmukaisesti. Ei ole vaatimuksia siitä, miten LMS: n pitäisi toteuttaa toimitusmenetelmä, se on vain informatiivinen signaali. Jotkut LMS: t tekevät edestakaisen matkan palvelimelle jokaisen puhelun sitoutua varmistamaan, että kaikki tiedot pysyvät. Vaikka tämä käyttöönottostrategia on intuitiivinen, se voi johtaa skaalautuvuusongelmiin. Ole varovainen, ettet soita sitoutua liikaa, jotta ei ylikuormittaa näitä LMS: n.

GetLastError / LMSGetLastError

GetLastError-menetelmä tarkistaa, aiheuttiko viimeinen SCORM API-puhelu virheen. Jos näin on, tämä menetelmä palauttaa virhenumeron, joka vastaa määriteltyä mahdollisten virheiden joukkoa. Jotkut virhenumerot edustavat täysin oikeutettuja tilanteita (kuten 403 – Tietomallielementtiä Ei Alusteta). SCO laatijat olisi huolehdittava vain merkitä laillisesti odottamattomia virheitä käyttäjälle. Täydellinen virhekoodiluettelo löytyy SCORM run-time-viitekartasta.

GetErrorString / LMSGetErrorString

tietyn virheluvun (yleensä getlasterrorista palautettu virheluku) vuoksi GetErrorString-menetelmä palauttaa tekstimuotoisen kuvauksen siitä, mitä virhekoodi tarkoittaa. Esimerkiksi SCORM 2004: ssä virhenumero ”406” palauttaa merkkijonon, joka sanoo ”Tietomallielementtityypin epäsuhta” osoittaakseen, että edellisen puhelun tulos (todennäköisesti SetValue) epäonnistui, koska Tallennettavat tiedot eivät olleet oikeassa muodossa.

Getdiagnostinen / Lmsgetdiagnostinen

Getdiagnostinen menetelmä antaa LMS: lle mahdollisuuden palauttaa yksityiskohtaista tietoa aiemmasta virheestä, josta voi olla hyötyä ongelman diagnosoinnissa. Esimerkiksi edellä mainitun ”406” – virheen diagnostiset tiedot voivat olla ”arvo” nolla ” ei ole sallittu cmi: lle.pisteet.raaka. Cmi.pisteet.raw-elementin tulee sisältää kelvollinen numero, joka esitetään vain numeroina”.

SCORM Run-Time-tietomalli

run-time-tietomalli sisältää monia elementtejä, joilla kullakin on oma merkityksensä. Elementit voidaan lukea ja kirjoittaa API: n avulla. SCORM run-time reference chart sisältää luettelon kustakin tietomallielementistä ja sen tietotyypistä sekä lyhyen kuvauksen sen merkityksestä ja käytöstä.

jokaisella SCO: lla on omat ajoaikatietonsa. Jokaisella näistä tietomallin elementeistä on erillinen arvo kullekin SCO: lle kurssin sisällä, tietomallin elementtejä ei jaeta SCOs: ille. Lisäksi jokaisella SCO: n” yrityksellä ” on oma joukko ajonaikaisia tietoja. Kun oppija aloittaa uuden yrityksen SCO: lla, tietomallin arvot nollataan uuden yrityksen alussa.

tietomallin elementit ovat hieman erilaisia SCORM-versioiden välillä, mutta useimmiten jokaisessa standardiversiossa on vastaava elementti. SCORM 1.1: llä ja SCORM 1.2: lla on identtiset tietomallit. SCORM 2004: ssä on erilainen tietomallisarja. Myös SCORM 2004: n painosten välillä on pieniä hienoisia eroja. Kaaviossa on kattava viite kustakin versiosta / painoksesta. SCORM 2004: n merkittävimpiä muutoksia ovat:

• pieni uudelleennimeäminen, lähinnä poistamalla ”ydin” tietomallielementtien nimistä.
• statuksen erottaminen. SCORM 1.2: ssa yksi elementti, cmi.ydin.lesson_status edustaa SCO: n statusta. SCORM 2004: ssä status on jaettu kahteen erilliseen osaan, cmi: hen.completion_status (completed vs imperfective) ja cmi.success_status (hyväksytty vs hylätty).
• vuorovaikutukset (kysymystulokset) luetaan/kirjoitetaan pelkän kirjoituksen sijaan. Vuorovaikutukset sisältävät myös kuvauskentän, joka puuttui SCORM 1.2: sta.
• ADL: n lisääminen.selaus.* tietomallin elementit, joiden avulla SCO voi aloittaa sekvensointipyynnöt

käyttämällä ajonaikaista

SCORM-ajonaikaista on pitkälti valinnaista tiukasta vaatimustenmukaisuuden näkökulmasta, mutta alan normi on käyttää ainakin osaa käytettävissäsi olevista ajonaikaisista tietomallin elementeistä.

yksinkertaisimmillaan, jos kurssilla ei ole muuta kuin käynnistettävää omaisuutta, ei suoritusaikaisia soittoja tarvita. LMS yksinkertaisesti käynnistää jokaisen hyödykkeen käyttäjän pyynnöstä ja hyödykkeen katsotaan olevan valmis heti käynnistämisen jälkeen.

rikkaampaan vuorovaikutukseen tarvitaan ensisijaisesti ajonaikaisen viestinnän mahdollistaminen. Tämä edellyttää löytää API ja sitten varmistaa, että alustaa ja lopettaa kutsutaan. Useimmissa tapauksissa, alustaa tulisi soittaa heti SCO käynnistetään. Kun alustaa on kutsuttu, on tärkeää, että lopettaa kutsutaan jokaisessa exit skenaariossa.

kun viestintä on alustettu, on aika aloittaa varsinainen tiedonvälitys. Seuraavat ”1st tier” – tietomallin elementit ovat tärkeimmät ja yleisimmin käytetyt (SCORM 1.2 vastaava suluissa):

• cmi.täydennetty tilasto_9589> cmi.success_status (cmi.ydin.lesson_status) – nämä tietomallin elementit ovat olennaisimpia ja tärkeimpiä. Ne osoittavat, milloin käyttäjä on suorittanut kurssin ja onko hän läpäissyt tai epäonnistunut. Tämä perustieto on olennainen useimmille LMS: lle.
• cmi.pisteet.scaled (cmi.ydin.pisteet.raw) – ilmaisee pistemäärän, jonka oppija on ansainnut SCO: n sisällä suoritetusta arvioinnista. Min – ja max-pisteiden ilmoittaminen yhdessä raa ’ an pistemäärän kanssa on myös hyvä muoto.
• cmi.session_time (cmi.ydin.session_time) – ilmoittaa oppijan SCO: ssa viettämän ajan.
• cmi.location (cmi.ydin.lesson_location) – tarjoaa vapaan tekstikentän SCO: lle kirjanmerkin tallentamiseksi. Jos SCO on suurempi kuin vain pari HTML-sivua, sen pitäisi harkita bookmarking-ominaisuuden toteuttamista, jotta oppija voi jatkaa keskeytettyä yritystä.
• cmi.exit (cmi.ydin.exit) – tämä arvo ilmaisee, miten oppija poistuu SCO: sta. Asetan cmi: n.poistuminen ”keskeytä” varmistaa, että nykyinen yritys säilyy ja suoritusaikatietoja ei nollata seuraavan SCO: n käynnistämisen yhteydessä. Asetan cmi: n.poistuminen””: een osoittaa, että LMS: n pitäisi aloittaa uusi yritys uudella ajoaikatietojen joukolla SCO: n seuraavassa laukaisussa.

alan standardi odottaa, että kaikkia 1.tason tietomallien elementtejä käytetään oikein SCO: ssa. Kun kyseinen toiminto on otettu käyttöön, seuraavaksi yleisimmät tietomallielementit eli 2. taso sisältävät:

• interactions – käytä interactions data model elements raportoida tulokset kunkin kysymyksen vastaus. Vuorovaikutuksen ei tarvitse olla perinteinen testivastaus. Esimerkiksi SCO voisi dokumentoida oppijan valintoja hänen edetessään simulaation läpi. Jos mahdollista, käytä kaikkia vuorovaikutuselementtejä antaaksesi mahdollisimman kattavan kuvan oppijan vastauksista. Käytä vähintään ”id”, ”type”, ”result” ja ”description”, jotta LMS: t voivat tarjota perusraportoinnin.
• tavoitteet-suurissa Oppisopimuskoulutuskeskuksissa tarkastellaan raportointia siitä, miten oppija hallitsee tietyt oppimistavoitteet käyttämällä tavoitetietomallin elementtejä. Tavoitteet mahdollistavat tarkemman raportoinnin oppijan etenemisestä koulutusmateriaalin läpi ja hallitsemisesta.
• cmi.progress_measure-käytä SCORM 2004: n progress_measure-elementtiä raportoidaksesi käyttäjän edistymisestä SCO: n valmistumisessa. Progress_measure on kuin ”prosentti täydellinen” mitta, jonka avulla LMS voi tarjota etenemispalkin kurssin suorittamisesta kokonaisuudessaan.

sisäänpääsy, moodi ja luotto

cmi.entry (cmi.ydin.entry), cmi.moodi (cmi.ydin.lesson_mode) ja cmi.Luoto (cmi.ydin.credit) tietomallielementit tarjoavat SCO: lle jonkinlaisen kontekstin, jota se voi käyttää tarjotakseen oppijalle optimaalisen kokemuksen.

• cmi.merkintä osoittaa, käynnistääkö käyttäjä SCO: n ensimmäistä kertaa vai jatkaako se aiempaa yritystä. Jos käytetään kirjanmerkkausta, SCO saattaa käyttää tätä arvoa kehottaakseen käyttäjää aloittamaan alusta tai siitä kohdasta, johon edellinen yritys päättyi.
• cmi.tila ilmaisee, onko harjoittelija käynnistämässä tätä SCO: ta: normaalisti – ”live” – koulutustilassa; selaustilassa – käyttäjä selailee koulutusluetteloa ja haluaa ”esikatsella” tätä kurssia; tai, arvostelutilassa-käyttäjä on jo suorittanut SCO: n ja tulee takaisin tarkastelemaan materiaalia. Selaustilassa SCO: n kirjoittajan tulisi harkita SCOs: n käyttäytymisen muuttamista siten, että se tarjoaa vapaamman muodon navigointiin, antaa yleiskuvan tai kartan kurssista ja mahdollisesti piilottaa arviointeja. Tarkastelutilassa SCO: n laatijan tulisi samoin harkita, että se sallisi laihemman täydellisen liikkumisvapauden. Arvostelutilassa oppija voi myös vapaasti navigoida mitä tahansa testejä ja selata oikeiden vastausten listaa. Tarkastelutilassa käynnistettäessä SCO: n on varottava muuttamasta oppijan tilaa tai nollaamasta pisteitä.
• cmi.luotto osoittaa, onko tätä SCO: ta yritetty saada luottoa vai onko sillä ”merkitystä”. Samanlainen selaustila, jos SCO käynnistetään ilman luottoa, käyttäytymistä pitäisi luultavasti muuttaa.