SCORM Run-Time Environment

Prezentare generală a SCORM Run-Time environment

specificația SCORM Run-Time controlează modul în care LMS lansează conținut și modul în care conținutul comunică apoi cu LMS. Toate aceste comunicări se întâmplă în contextul unei singure încercări asupra unui singur SCO. Navigarea între SCO este guvernată de secvențierea specificată în manifest și explicată mai departe aici.

lansarea conținutului

tot conținutul SCORM trebuie să fie livrabil pe web și toată comunicarea SCORM are loc în contextul unei sesiuni de browser web. LMS va lansa un SCO la un moment dat, așa cum este selectat de utilizator sau așa cum este determinat de regulile de secvențiere SCORM 2004. În versiunile anterioare SCORM 2004 ediția a 3-a, nu existau cerințe formale pentru interfața cu utilizatorul furnizată de un LMS. Fiecare LMS este ușor diferit, dar în cea mai mare parte, este corect să ne așteptăm ca un LMS să ofere o interfață similară cu cea din imaginea de mai jos. Cel puțin, ar trebui să conțină o formă de cuprins navigabil, precum și controale pentru navigarea în flux (butoanele anterioare și următoare). Aceste elemente de navigație controlează navigarea între SCO. Dacă este necesară navigarea în cadrul unui SCO, SCO trebuie să furnizeze propriile sale elemente de navigație.

LMS are două opțiuni pentru lansarea unui SCO. Se poate lansa fie SCO Ina frameset (ca imaginea de mai sus), sau se poate lansa SCO într-o fereastră nouă. Unele LMS va lansa întotdeauna conținut într-un fel sau altul. În mod obișnuit, dacă un curs conține doar un SCO (și, prin urmare, nu necesită și elemente de navigație din LMS), SCO va fi lansat într-o fereastră pop-up. În schimb, dacă cursul conține multe SCO-uri, atunci LMS va lansa în mod obișnuit SCO-urile într-un cadru înconjurat de elemente de navigație. Unele LMS-uri vor permite autorilor de conținut să controleze exact modul în care sunt lansate SCO-urile, ce elemente de navigație sunt disponibile și chiar dimensiunea ferestrelor SCO.

API

toate comunicare între un SCO și LMS se întâmplă printr-un ECMAScript (JavaScript) API. Aceasta este singura modalitate de comunicare. Nu există alte canale de comunicare disponibile. Conținutul nu poate comunica prin servicii web, postări de formulare, scrieri de baze de date sau orice alt mecanism, numai prin API-ul JavaScript furnizat de LMS.

găsirea API-ului

LMS este responsabil pentru furnizarea unui obiect JavaScript denumit în mod specific într-o anumită locație din DOM-ul browserului. Astfel, conținutul, poate localiza întotdeauna acest API folosind un algoritm comun.

în SCORM 1.1 și SCORM 1.2, obiectul API este întotdeauna numit „API”. În SCORM 2004, obiectul este numit”API_1484_11″.

obiectul API ar trebui să fie situat într-o fereastră care este un părinte al SCO sau un părinte al ferestrei de deschidere a SCO. O fereastră „părinte” este definită ca fiind întregul lanț de ferestre părinte până la fereastra browserului rădăcină. Deci, API – ul ar putea fi în părintele SCO, părintele părintelui SCO, părintele părintelui SCO etc. În mod similar, API-ul ar putea fi în fereastra de deschidere, părintele deschizătorului, părintele părintelui deschizătorului etc. Diagramele de mai jos din CAIETUL DE SARCINI SCORM 2004 3rd Edition ilustrează posibile Locații API.

SCORM include algoritmi specifici pe care conținutul le poate utiliza pentru a găsi API-ul SCORM.

utilizarea API-ului

odată ce un SCO a găsit API-ul SCORM, acesta poate utiliza API-ul pentru a comunica cu LMS. Rețineți că numai SCO poate iniția comunicarea. LMS este o entitate pasivă care răspunde pur și simplu la apelurile API efectuate de conținut. LMS nu poate iniția nicio comunicare, pur și simplu lansează conținutul și răspunde la solicitări.

API-ul SCORM conține opt metode cu următoarele semnături:

SCORM 2004

 inițializare ( ""): Bool Terminate ( "" ): Bool GetValue ( element: CMIElement ): string SetValue( element : CMIElement, valoare : 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

numele metodelor variază ușor între versiunile SCORM, dar conceptual metodele sunt identice.

Note:

• tipul bool este un boolean SCORM, care este de fapt un șir având valoarea „adevărat” sau „fals”.
• parametrul „” este cerut de toate metodele SCORM care nu acceptă alte argumente. Sco sunt pur și simplu necesare pentru a trece un parametru șir gol la aceste metode.
• Tipul de date CMIElement este un șir corespunzător elementelor modelului de date SCORM descrise mai jos.
• Tipul de date CMIErrorCode este un număr din trei cifre, reprezentat un șir, care corespunde unuia dintre codurile de eroare SCORM Run-Time.

Initialize / Lmsinitialize

metoda Initialize indică LMS că conținutul ar dori să înceapă o sesiune de comunicare. Toate SCO-urile trebuie să apeleze inițializarea înainte de a efectua orice altă comunicare. LMS returnează un boolean care indică succesul sau eșecul inițializării. De obicei, LMS nu trebuie să facă o mulțime de inițializare și va reveni întotdeauna „adevărat”.

Terminate / LMSFinish

metoda Terminate indică LMS că conținutul se face comunicarea. Toate SCO-urile trebuie să sune Terminate. Apelarea terminare nu indică neapărat că utilizatorul se face cu SCO, punct de vedere tehnic indică doar SCO se face comunicarea. Cu toate acestea, în practică, conținutul va fi mai compatibil și mai utilizabil dacă Terminate este apelat numai atunci când conținutul poate fi luat de la utilizator. Deoarece terminarea este necesară pentru a fi întotdeauna apelată, indiferent de modul în care elevul iese din SCO, este înțelept să plasați un apel pentru a termina în cazul onunload al unui SCO. Valoarea booleană returnată de LMS indică adesea dacă datele SCO au fost sau nu persistate cu succes pe server.

GetValue / Lmsgetvalue

metoda GetValue permite unui SCO să recupereze date din LMS. Datele care sunt întotdeauna preluate sunt unul dintre elementele modelului de date SCORM definite. Fiecare dintre aceste elemente de model de date deține o bucată diferită de date. Unele dintre elementele modelului de date au valori inițializate de LMS care vorbesc despre circumstanțele în care SCO este lansat. Alte valori sunt inițializate de SCO prin apeluri la SetValue. Dacă apelul către GetValue returnează un șir gol, este posibil să apară o eroare și să fie invocată metoda GetLastError pentru a verifica problemele.

SetValue / Lmssetvalue

metoda SetValue permite SCO să persiste date la LMS. Datele sunt întotdeauna stocate într-unul dintre elementele modelului de date SCORM definite. Unele elemente ale modelului de date sunt constrânse să aibă valori într-un vocabular limitat (de exemplu, statutul ar putea fi „completat” sau „trecut”), altele sunt constrânse să fie un tip de date specific (de exemplu, scorul trebuie să fie întotdeauna un număr), în timp ce altele permit SCO să persiste date text liber fără sens semantic. Apelul SetValue returnează un boolean care indică succesul sau eșecul apelului.

Commit / Lmscommit

metoda Commit semnalează către LMS că o cantitate semnificativă de date a fost salvată și că ar trebui să asigure persistența corectă a datelor. Nu există cerințe pentru modul în care LMS ar trebui să implementeze metoda Commit, este pur și simplu un semnal informativ. Unele LMS va face o călătorie dus-întors la server pentru fiecare apel să se angajeze pentru a se asigura că toate datele sunt persistate. Deși intuitivă, această strategie de implementare poate duce la probleme de scalabilitate. Aveți grijă să nu apelați excesiv pentru a nu supraîncărca aceste LMS-uri.

GetLastError / Lmsgetlasterror

metoda GetLastError verifică dacă ultimul apel API SCORM a cauzat o eroare. Dacă da, această metodă returnează un număr de eroare care corespunde unui set definit de erori posibile. Unele numere de eroare reprezintă situații perfect legitime (cum ar fi 403-Element Model de date nu inițializat). Autorii SCO ar trebui să aibă grijă să semnaleze utilizatorului numai erori neașteptate în mod legitim. Lista completă a codurilor de eroare poate fi găsită în graficul de referință SCORM run-time.

GetErrorString / Lmsgeterrorstring

având în vedere un anumit număr de eroare (de obicei, numărul de eroare returnat de la GetLastError), metoda GetErrorString va returna o descriere textuală a ceea ce înseamnă codul de eroare. De exemplu, în SCORM 2004, trecerea numărului de eroare „406” va returna un șir care spune „nepotrivire de tip Element Model de date” pentru a indica faptul că rezultatul apelului anterior (probabil o valoare set) a eșuat deoarece datele stocate nu erau în formatul corect.

GetDiagnostic / Lmsgetdiagnostic

metoda GetDiagnostic permite LMS să returneze informații detaliate despre eroarea anterioară care poate fi utilă în diagnosticarea problemei. De exemplu, informațiile de diagnosticare pentru eroarea „406” menționate mai sus ar putea fi „valoarea” zero ” nu este permisă pentru cmi.scor.crud. Cmi.scor.elementul brut trebuie să conțină un număr valid reprezentat doar ca cifre”.

modelul de date SCORM Run-Time

modelul de date run-time conține multe elemente, fiecare având propriul său sens. Elementele pot fi citite și scrise folosind API-ul. Diagrama de referință SCORM run-time conține o listă a fiecărui element model de date împreună cu tipul său de date și o scurtă descriere a semnificației și utilizării sale.

fiecare SCO are propriul set de date run-time. Fiecare dintre aceste elemente ale modelului de date are o valoare separată pentru fiecare SCO în cadrul unui curs, elementele modelului de date nu sunt partajate între SCO. În plus, fiecare „încercare” pe un SCO are propriul set de date run-time. Când cursantul începe o nouă încercare pe un SCO, valorile modelului de date vor fi resetate pentru începerea noii încercări.

elementele modelului de date sunt ușor diferite între versiunile SCORM, dar în cea mai mare parte există un element corespunzător în fiecare versiune a standardelor. SCORM 1.1 și SCORM 1.2 au modele de date identice. SCORM 2004 are un set diferit de modele de date. Există diferențe minore subtile și între edițiile SCORM 2004. Graficul oferă o referință cuprinzătoare pentru fiecare versiune/ediție. Cele mai semnificative schimbări în SCORM 2004 includ:

• redenumirea minore, cea mai mare parte eliminarea „core” din numele elementelor modelului de date.
• separarea statutului. În SCORM 1.2 un singur element, cmi.miezul.lesson_status reprezintă starea SCO. În SCORM 2004, statutul este împărțit în două elemente separate, cmi.completion_status (completat vs incomplet) și cmi.success_status (trecut vs nu a reușit).
• interacțiunile (rezultatele întrebării) sunt Citire/Scriere în loc de scriere numai. Interacțiunile conțin, de asemenea, un câmp de descriere care lipsea în SCORM 1.2.
• adăugarea adl.nav.* elemente de model de date care permit SCO să inițieze cereri de secvențiere

utilizarea Run-time

utilizarea SCORM run-time este în mare parte opțională dintr-o perspectivă strictă de conformitate, cu toate acestea, norma industriei este de a utiliza cel puțin un subset al elementelor modelului de date run-time disponibile pentru dvs.

la cel mai simplu, dacă cursul dvs. nu conține decât active lansabile, nu sunt necesare apeluri în timp de rulare. LMS lansează pur și simplu fiecare activ solicitat de utilizator, iar activul este considerat finalizat imediat după lansare.

pentru o interacțiune mai bogată, primul lucru pe care trebuie să-l facem este să activăm comunicarea în timpul rulării. Aceasta va implica găsirea API-ului și apoi asigurarea faptului că inițializarea și terminarea sunt apelate. În majoritatea cazurilor, inițializarea trebuie apelată imediat după lansarea SCO. Odată ce inițializarea a fost apelată, este esențial ca terminare să fie apelată în fiecare scenariu de ieșire.

odată ce comunicarea a fost inițializată, este timpul să începeți comunicarea efectivă a datelor. Următoarele elemente ale modelului de date „1st tier” sunt cele mai importante și cele mai frecvent utilizate (SCORM 1.2 echivalent între paranteze):

• cmi.finalizare_status & cmi.success_status (cmi.miezul.lesson_status) – aceste elemente de model de date sunt cele mai fundamentale și importante. Acestea indică când un utilizator a terminat un curs și dacă a trecut sau a eșuat. Aceste informații fundamentale sunt esențiale pentru majoritatea LMS.
• cmi.scor.scalate (cmi.miezul.scor.raw) – indică scorul pe care elevul l-a obținut la orice evaluare din cadrul unui SCO. Raportarea unui scor min și max împreună cu un scor brut este, de asemenea, o formă bună.
• cmi.session_time (cmi.miezul.session_time) – raportează cantitatea de timp pe care elevul a petrecut-o în SCO.
• cmi.locație (cmi.miezul.lesson_location) – oferă un câmp de text liber pentru SCO pentru a înregistra un marcaj. Dacă SCO este mai mare decât doar câteva pagini HTML, ar trebui să ia în considerare implementarea unei funcții de marcare pentru a permite cursantului să reia o încercare întreruptă.
• cmi.ieșire (cmi.miezul.exit) – această valoare indică modul în care cursantul iese din SCO. Setarea cmi.ieșirea la” suspendare ” se va asigura că încercarea curentă este păstrată și că datele de rulare nu sunt resetate la următoarea lansare a SCO. Setarea cmi.ieșirea la „” va indica faptul că LMS ar trebui să înceapă o nouă încercare cu un nou set de date de rulare la următoarea lansare a SCO.

norma industriei se așteaptă ca toate elementele modelelor de date de nivel 1 să fie utilizate corect într-un SCO. Odată ce această funcționalitate a fost activată, următoarele elemente cele mai comune ale modelului de date sau nivelul 2 includ:

• interacțiuni-utilizați elementele modelului de date privind interacțiunile pentru a raporta rezultatele fiecărui răspuns la întrebare. O interacțiune nu trebuie să fie un răspuns tradițional de testare. De exemplu, un SCO ar putea documenta alegerile cursantului pe măsură ce progresează printr-o simulare. Dacă este posibil, utilizați toate elementele de interacțiune pentru a oferi cea mai cuprinzătoare imagine a răspunsurilor cursantului. Cel puțin, utilizați „id”, „tip”, „rezultat” și „descriere” pentru a permite LMS să furnizeze rapoarte de bază.
• obiective – în sco-uri mari, luați în considerare raportarea cu privire la stăpânirea de către cursant a obiectivelor specifice de învățare folosind elementele modelului de date obiective. Obiectivele permit raportarea mai detaliată a progresului cursantului și stăpânirea materialului de instruire.
• cmi.progress_measure-utilizați elementul progress_measure în SCORM 2004 pentru a raporta progresul utilizatorului spre finalizarea unui SCO. Progress_measure este ca o măsură „procent complet”, care ar permite LMS pentru a oferi o bară de progres de finalizare generală a unui curs.

intrare, mod și Credit

cmi.intrare (cmi.miezul.intrare), cmi.mod (cmi.miezul.lesson_mode) și cmi.credit (cmi.miezul.credit) elementele modelului de date oferă SCO un anumit context pe care îl poate folosi pentru a oferi cursantului experiența optimă.

• cmi.intrarea indică dacă utilizatorul pornește SCO pentru prima dată sau dacă reia o încercare anterioară. Dacă utilizați marcare, SCO ar putea utiliza această valoare pentru a solicita utilizatorului să înceapă de la început sau de la punctul în care încercarea anterioară sa încheiat.
• cmi.modul indică dacă cursantul lansează acest SCO: în mod normal – într – o sesiune de instruire „live”; în modul de navigare – utilizatorul navighează într-un catalog de instruire și dorește să „previzualizeze” acest curs; sau, în modul de revizuire-utilizatorul a finalizat deja SCO și se întoarce pentru a revizui materialul. În modul de navigare, autorul SCO ar trebui să ia în considerare modificarea comportamentului SCOs pentru a oferi o navigare mai liberă în formă, pentru a oferi o imagine de ansamblu sau o hartă a cursului și, eventual, pentru a ascunde evaluările. În modul de revizuire, autorul SCO ar trebui să ia în considerare în mod similar să permită o libertate completă de navigație mai slabă. În modul de revizuire, elevul ar putea, de asemenea, să poată naviga liber la orice teste și să răsfoiască o listă de răspunsuri corecte. Când este lansat în modul de revizuire, un SCO ar trebui să fie atent să nu schimbe starea cursantului sau să reseteze scorul.
• cmi.credit indică dacă este sau nu acest SCO este încercarea de credit, sau dacă este sau nu „contează”. Similar modului de navigare, dacă un SCO este lansat fără credit, comportamentul ar trebui probabil modificat.