SCORM Run-Time prostředí

přehled SCORM Run-Time prostředí

SCORM Run-Time SPECIFIKACE řídí, jak LMS spouští obsah a jak obsah pak komunikuje s LMS. Veškerá tato komunikace probíhá v kontextu jediného pokusu o jediné SCO. Navigace mezi SCOs se řídí sekvenováním uvedeným v manifestu, a dále vysvětleno zde.

spouštění obsahu

Veškerý obsah SCORM musí být doručitelný z webu a veškerá komunikace SCORM probíhá v rámci relace webového prohlížeče. LMS spustí jeden SCO najednou, podle výběru uživatelem nebo podle pravidel sekvenování SCORM 2004. Ve verzích před SCORM 2004 3rd Edition neexistovaly žádné formální požadavky na uživatelské rozhraní poskytované LMS. Každý LMS je mírně odlišný,ale z větší části, je spravedlivé očekávat, že LMS poskytne rozhraní podobné níže uvedenému. Minimálně by měl obsahovat nějakou formu splavného obsahu a ovládací prvky pro navigaci toku (tlačítka Předchozí a další). Tyto navigační prvky řídí navigaci mezi SCOs. Pokud je navigace v rámci SCO potřebná, musí SCO poskytnout své vlastní navigační prvky.

LMS má dvě možnosti pro spuštění SCO. Může buď spustit SCO Ina frameset (jak je znázorněno výše), nebo může spustit SCO v novém okně. Některé LMS vždy spustí obsah Tak či onak. Běžně však, pokud kurz obsahuje pouze jeden SCO (a proto nevyžaduje navigační prvky z LMS), SCO bude spuštěn ve vyskakovacím okně. Naopak, pokud kurz obsahuje mnoho SCO, pak LMS obvykle spustí SCO v rámečku obklopeném navigačními prvky. Některé LMS umožní autorům obsahu přesně řídit, jak jsou spuštěny SCOs, které navigační prvky jsou k dispozici a dokonce i velikost oken SCO.

API

veškerá komunikace mezi SCO a LMS probíhá prostřednictvím ECMAScript (JavaScript) API. To je jediný způsob komunikace. Nejsou k dispozici žádné další komunikační kanály. Obsah nemůže komunikovat prostřednictvím webových služeb, formuláře příspěvky, databáze zápisy nebo jakýkoli jiný mechanismus, pouze prostřednictvím JavaScript API poskytované LMS.

nalezení API

LMS je zodpovědný za poskytnutí specificky pojmenovaného objektu JavaScript na určitém místě v DOM prohlížeče. To znamená, že obsah, můžete vždy najít toto API pomocí společného algoritmu.

v SCORM 1.1 a SCORM 1.2 je objekt API vždy pojmenován „API“. V SCORM 2004 je objekt pojmenován „API_1484_11“.

objekt API by měl být umístěn v okně, které je rodičem SCO nebo rodičem otevíracího okna SCO. „Nadřazené“ okno je definováno jako celý řetězec nadřazených oken až do kořenového okna prohlížeče. API by tedy mohlo být v rodičích SCO, rodičích SCO, rodičích rodičů SCO atd. Podobně, API může být v okně otvíráku, rodič otvíráku, rodič otvíráku, atd. Níže uvedené diagramy ze SPECIFIKACE SCORM 2004 3rd Edition ilustrují možná umístění API.

SCORM obsahuje specifické algoritmy, které obsah může použít k nalezení SCORM API.

pomocí API

jakmile SCO najde SCORM API, může použít API pro komunikaci s LMS. Všimněte si, že pouze SCO může zahájit komunikaci. LMS je pasivní entita, která jednoduše reaguje na volání API uskutečněná obsahem. LMS nemůže zahájit žádnou komunikaci, jednoduše spustí obsah a reaguje na požadavky.

SCORM API obsahuje osm metod s následujícími podpisy:

SCORM 2004

inicializovat( "" ) : Bool Terminate( "" ) : bool GetValue( element : CMIElement): string SetValue( element : CMIElement, hodnota : 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

názvy metod se mezi verzemi SCORM mírně liší, ale koncepčně jsou metody identické.

poznámky:

• typ bool je SCORM boolean, což je vlastně řetězec s hodnotou „true“ nebo „false“.
• parametr „“ je vyžadován všemi metodami SCORM, které nepřijímají žádné další argumenty. SCO jsou jednoduše povinni předat těmto metodám parametr prázdný řetězec.
• datový typ Cmielementu je řetězec odpovídající prvkům SCORM datového modelu popsaným níže.
• datový typ CMIErrorCode je třímístné číslo představované řetězcem, které odpovídá jednomu z chybových kódů SCORM Run-Time.

Initialize / LMSInitialize

Initialize metoda označuje LMS, že obsah by chtěl zahájit komunikační relaci. Všechny SCO musí volat inicializovat před provedením jakékoli jiné komunikace. LMS vrací boolean označující úspěch nebo Selhání inicializace. Typicky, LMS nemusí dělat hodně inicializace a vždy se vrátí „true“.

Terminate / LMSFinish

metoda Terminate označuje LMS, že obsah je hotový. Všechny SCO musí volat ukončit. Volání Terminate nemusí nutně znamenat, že uživatel je hotový s SCO, technicky to znamená pouze komunikaci SCO. V praxi však bude obsah kompatibilnější a použitelnější, pokud je Terminate volán pouze tehdy, když může být obsah odebrán uživateli. Vzhledem k tomu, že Terminate musí být vždy volán, bez ohledu na to, jak student opustí SCO, je moudré zavolat ukončení v případě onunload SCO. Booleovská hodnota vrácená LMS často označuje, zda byla data SCO úspěšně přetrvávána na serveru.

GetValue / LMSGetValue

metoda GetValue umožňuje SCO načíst data z LMS. Data, která jsou vždy načtena, jsou jedním z definovaných prvků datového modelu SCORM. Každý z těchto prvků datového modelu obsahuje jinou část dat. Některé prvky datového modelu mají hodnoty inicializované LMS, které hovoří o okolnostech, za kterých je SCO spuštěn. Ostatní hodnoty jsou inicializovány SCO prostřednictvím volání do SetValue. Pokud volání GetValue vrátí prázdný řetězec, je možné, že došlo k chybě a ke kontrole problémů by měla být vyvolána metoda GetLastError.

SetValue / LMSSetValue

metoda SetValue umožňuje SCO přetrvávat data do LMS. Data jsou vždy uložena v jednom z definovaných prvků datového modelu SCORM. Některé prvky datového modelu jsou omezeny na hodnoty v omezené slovní zásobě (například stav může být „dokončen“ nebo „předán“), jiné jsou omezeny na specifický datový typ (například skóre musí být vždy číslo), zatímco jiné umožňují SCO přetrvávat volná textová data bez sémantického významu. Volání SetValue vrací boolean označující úspěch nebo neúspěch hovoru.

Commit / LMSCommit

metoda Commit signalizuje LMS, že bylo uloženo významné množství dat a že by měla zajistit, aby data byla řádně zachována. Neexistují žádné požadavky na to, jak by LMS měl implementovat metodu odevzdání, je to prostě informativní signál. Některé LMS udělají zpáteční cestu na server pro každé volání, aby se zavázaly, aby zajistily, že všechna data přetrvávají. I když je tato implementační strategie intuitivní, může vést k problémům se škálovatelností. Dávejte pozor, abyste nezavolali příliš, aby nedošlo k přetížení těchto LMS.

GetLastError / LMSGetLastError

metoda GetLastError kontroluje, zda poslední volání SCORM API způsobilo chybu. Pokud ano, tato metoda vrátí číslo chyby, které odpovídá definované sadě možných chyb. Některá čísla chyb představují zcela legitimní situace (například 403-Element datového modelu není inicializován). Autoři SCO by měli dbát na to, aby uživatel označil oprávněně neočekávané chyby. Kompletní seznam chybových kódů naleznete v referenční tabulce SCORM run-time.

GetErrorString / LMSGetErrorString

vzhledem k určitému číslu chyby (obvykle číslo chyby vrácené z GetLastError) vrátí metoda GetErrorString textový popis toho, co Kód chyby znamená. Například, v SCORM 2004, předávání číslo chyby “ 406 „vrátí řetězec říká“ datový model Element Type nesoulad“, což znamená, že výsledek předchozího volání (pravděpodobně SetValue) selhal, protože data jsou uloženy nebyl ve správném formátu.

GetDiagnostic / LMSGetDiagnostic

metoda GetDiagnostic umožňuje LMS vrátit podrobné informace o předchozí chybě, která může být užitečná při diagnostice problému. Například diagnostická informace pro chybu“ 406 „uvedená výše může být „hodnota“ nula “ není povolena pro cmi.skóre.surovina. CMI.skóre.prvek raw musí obsahovat platné číslo reprezentované pouze jako číslice“.

datový model SCORM Run-Time

datový model run-time obsahuje mnoho prvků, z nichž každý má svůj vlastní význam. Prvky lze číst a zapisovat pomocí API. Referenční tabulka SCORM run-time obsahuje seznam každého prvku datového modelu spolu s jeho datovým typem a krátký popis jeho významu a použití.

každý SCO má svou vlastní sadu run-time dat. Každý z těchto prvků datového modelu má samostatnou hodnotu pro každý SCO v rámci kurzu, prvky datového modelu nejsou sdíleny napříč SCOs. Kromě toho má každý „pokus“ na SCO vlastní sadu dat za běhu. Když student zahájí nový pokus o SCO, hodnoty datového modelu budou resetovány pro začátek nového pokusu.

prvky datového modelu se ve verzích SCORM mírně liší, ale z větší části je v každé verzi standardů odpovídající prvek. SCORM 1.1 a SCORM 1.2 mají identické datové modely. SCORM 2004 má jinou sadu datových modelů. Mezi edicemi SCORM 2004 jsou také drobné jemné rozdíly. Graf poskytuje komplexní odkaz pro každou verzi / vydání. Mezi nejvýznamnější změny v SCORM 2004 patří:

• menší přejmenování, většinou odstranění „jádra“ z názvů prvků datového modelu.
• oddělení stavu. V SCORM 1.2 jeden prvek, cmi.jádro.lesson_status představuje stav SCO. Ve SCORM 2004 je stav rozdělen na dva samostatné prvky, cmi.completion_status (dokončeno vs neúplné) a cmi.success_status (prošel vs selhal).
• interakce (výsledky otázek) jsou čtení / zápis místo zápisu. Interakce také obsahují pole popisu, které ve SCORM 1.2 chybělo.
• přidání adl.nava.* prvky datového modelu, které umožňují SCO iniciovat požadavky na sekvenování

pomocí Run-time

použití SCORM run-time je z hlediska přísné shody do značné míry volitelné, nicméně průmyslovou normou je použít alespoň podmnožinu prvků run-time datového modelu, které máte k dispozici.

v nejjednodušším případě, pokud váš kurz neobsahuje nic jiného než spouštěcí aktiva, nejsou potřeba žádná volání za běhu. LMS jednoduše spustí každé aktivum podle požadavku uživatele a aktivum se považuje za dokončené ihned po spuštění.

pro bohatší interakci musíme nejprve povolit komunikaci za běhu. To bude zahrnovat nalezení API a poté zajištění vyvolání inicializace a ukončení. Ve většině případů by inicializace měla být vyvolána ihned po spuštění SCO. Jakmile inicializace byla volána, je nezbytné, aby ukončit být volán v každém scénáři ukončení.

jakmile je komunikace inicializována, je čas začít skutečně komunikovat data. Následující prvky datového modelu“ 1. úrovně “ jsou nejdůležitější a nejčastěji používané (SCORM 1.2 ekvivalent v závorkách):

• cmi.completion_status & cmi.success_status (cmi.jádro.lesson_status – – tyto prvky datového modelu jsou nejzákladnější a nejdůležitější. Označují, kdy uživatel dokončil kurz a zda prošel nebo selhal. Tato základní informace je nezbytná pro většinu LMS.
• cmi.skóre.scaled (cmi.jádro.skóre.raw) – označuje skóre, které student získal při jakémkoli hodnocení v rámci SCO. Hlášení min a max skóre ve spojení s raw skóre je také dobrá forma.
• cmi.session_time (cmi.jádro.session_time) – hlásí množství času, který student strávil v SCO.
• cmi.místo (cmi.jádro.lesson_location – – poskytuje volné textové pole pro SCO pro záznam záložky. Pokud je SCO větší než jen pár stránek HTML, mělo by zvážit implementaci funkce záložek, aby student mohl pokračovat v pozastaveném pokusu.
• cmi.exit (cmi.jádro.exit) – tato hodnota označuje, jak student opouští SCO. Nastavení cmi.výstup na „Pozastavit“ zajistí, že aktuální pokus bude zachován a data run-time nebudou resetována při příštím spuštění SCO. Nastavení cmi.výstup na „“ bude znamenat, že LMS by měl zahájit nový pokus s novou sadou dat run-time při příštím spuštění SCO.

průmyslová norma očekává, že všechny prvky datových modelů 1. úrovně budou v SCO použity správně. Jakmile je tato funkce povolena, další nejběžnější prvky datového modelu, nebo 2. úroveň, zahrnují:

• interakce-pomocí prvků datového modelu interakcí nahlaste výsledky každé odpovědi na otázku. Interakce nemusí být tradiční testovací odpovědí. Například, SCO mohl dokumentovat volby žáka, jak postupuje simulací. Pokud je to možné, použijte všechny prvky interakcí k poskytnutí nejkomplexnějšího obrazu odpovědí žáka. Minimálně použijte „id“, „Typ“, „výsledek“ a „popis“, abyste umožnili LMS poskytovat základní hlášení.
• cíle-ve velkých SCO zvažte podávání zpráv o zvládnutí konkrétních cílů učení žákem pomocí prvků datového modelu cílů. Cíle umožňují podrobnější podávání zpráv o pokroku žáka a zvládnutí školicího materiálu.
• cmi.progress_measure-použijte prvek progress_measure v SCORM 2004 pro hlášení pokroku uživatele směrem k dokončení SCO. Progress_measure je jako“ procento úplné “ opatření, které by umožnilo LMS poskytnout ukazatel průběhu celkového dokončení kurzu.

vstup, Režim a kredit

CMI.vstup (cmi.jádro.entry), cmi.režim (cmi.jádro.lesson_mode) a cmi.kredit (cmi.jádro.kreditní) prvky datového modelu poskytují SCO nějaký kontext, který může použít k tomu, aby studentovi poskytl optimální zážitek.

• cmi.položka označuje, zda uživatel spouští SCO poprvé nebo zda obnovuje předchozí pokus. Pokud používáte záložky, SCO může použít tuto hodnotu k vyzve uživatele, aby začít od začátku nebo od okamžiku, kdy předchozí pokus skončil.
• cmi.režim označuje, zda student zahajuje tento SCO: normálně – v“ živém „tréninku; v režimu procházení-uživatel prochází katalog školení a chce si tento kurz“ prohlédnout“; nebo v režimu kontroly-uživatel již dokončil SCO a vrací se k přezkoumání materiálu. V režimu procházení, autor SCO by měl zvážit změnu chování SCOs, aby poskytl volnější navigaci ve formuláři, poskytnout přehled nebo mapu kurzu a případně skrýt hodnocení. V režimu kontroly by autor SCO měl podobně zvážit umožnění štíhlejší úplné svobody navigace. V režimu kontroly může být student také schopen volně procházet všechny testy a procházet seznam správných odpovědí. Při spuštění v režimu kontroly, SCO by měl být opatrný, aby nezměnil stav studenta nebo resetoval skóre.
• cmi.úvěr označuje, zda se tento SCO pokouší o úvěr, nebo zda se „počítá“. Podobně jako v režimu procházení, pokud je SCO spuštěn bez kreditu, chování by mělo být pravděpodobně změněno.