Ambiente di runtime SCORM

Panoramica dell’ambiente di runtime SCORM

La specifica di runtime SCORM controlla il modo in cui LMS avvia il contenuto e il modo in cui il contenuto comunica con LMS. Tutta questa comunicazione avviene nel contesto di un singolo tentativo su un singolo SCO. La navigazione tra SCO è regolata dal sequenziamento specificato nel manifesto, e spiegato ulteriormente qui.

Avvio del contenuto

Tutti i contenuti SCORM devono essere web-deliverable e tutte le comunicazioni SCORM avvengono nel contesto di una sessione del browser Web. L’LMS lancerà uno SCO alla volta, come selezionato dall’utente, o come determinato dalle regole di sequenziamento SCORM 2004. Nelle versioni precedenti a SCORM 2004 3rd Edition, non c’erano requisiti formali per l’interfaccia utente fornita da un LMS. Ogni LMS è leggermente diverso, ma per la maggior parte, è giusto aspettarsi un LMS per fornire un’interfaccia simile a quella nella foto qui sotto. Come minimo, dovrebbe contenere una qualche forma di sommario navigabile e controlli per la navigazione del flusso (pulsanti precedente e successivo). Questi elementi di navigazione controllano la navigazione tra SCO. Se la navigazione è necessaria all’interno di una SCO, la SCO deve fornire i propri elementi di navigazione.

LMS ha due opzioni per il lancio di uno SCO. Può lanciare il frameset SCO ina (come nella foto sopra), oppure può lanciare SCO in una nuova finestra. Alcuni LMS lanceranno sempre contenuti in un modo o nell’altro. Comunemente però, se un corso contiene solo uno SCO (e quindi non richiede e elementi di navigazione dal LMS), lo SCO verrà avviato in una finestra popup. Al contrario, se il corso contiene molti SCO, l’LMS lancerà comunemente gli SCO in un frameset circondato da elementi di navigazione. Alcuni LMS consentiranno agli autori del contenuto di controllare con precisione come vengono lanciati gli SCO, quali elementi di navigazione sono disponibili e persino le dimensioni delle finestre SCO.

L’API

Tutte le comunicazioni tra SCO e LMS avvengono tramite un’API ECMAScript (JavaScript). Questo è l’unico modo per la comunicazione a verificarsi. Non ci sono altri canali di comunicazione disponibili. Il contenuto non può comunicare attraverso servizi Web, post di moduli, scritture di database o qualsiasi altro meccanismo, solo attraverso l’API JavaScript fornita dall’LMS.

Trovare l’API

L’LMS è responsabile della fornitura di un oggetto JavaScript con nome specifico in una posizione specifica all’interno del DOM del browser. Pertanto, il contenuto, può sempre individuare questa API utilizzando un algoritmo comune.

In SCORM 1.1 e SCORM 1.2, l’oggetto API è sempre chiamato “API”. In SCORM 2004, l’oggetto è denominato “API_1484_11”.

L’oggetto API deve trovarsi in una finestra che è un genitore della SCO o un genitore della finestra di apertura della SCO. Una finestra” genitore ” è definita come l’intera catena di finestre padre fino alla finestra del browser principale. Quindi, l’API potrebbe essere nel genitore dello SCO, nel genitore del genitore dello SCO, nel genitore del genitore del genitore dello SCO,ecc. Allo stesso modo, l’API potrebbe essere nella finestra di apertura, il genitore dell’opener, il genitore del genitore dell’opener, ecc. I diagrammi riportati di seguito dalla specifica SCORM 2004 3rd Edition illustrano le possibili posizioni API.

SCORM include algoritmi specifici che il contenuto può utilizzare per trovare l’API SCORM.

Utilizzando l’API

Una volta che uno SCO ha trovato l’API SCORM, può utilizzare l’API per comunicare con l’LMS. Si noti che solo la SCO può avviare la comunicazione. LMS è un’entità passiva che risponde semplicemente alle chiamate API effettuate dal contenuto. L’LMS non può avviare alcuna comunicazione, semplicemente lancia il contenuto e risponde alle richieste.

L’API SCORM contiene otto metodi con le seguenti firme:

SCORM 2004

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

Il metodo nomi possono variare leggermente tra versioni SCORM, ma concettualmente i metodi sono identici.

Note:

• Il tipo bool è uno SCORM booleano, che in realtà è una stringa con il valore “true”o ” false”.
• Il parametro “” è richiesto da tutti i metodi SCORM che non accettano altri argomenti. Gli SCO sono semplicemente tenuti a passare un parametro stringa vuoto a questi metodi.
• Il tipo di dati CMIElement è una stringa corrispondente agli elementi del modello di dati SCORM descritti di seguito.
• Il tipo di dati CMIErrorCode è un numero a tre cifre, rappresentato da una stringa, che corrisponde a uno dei codici di errore di runtime SCORM.

Initialize / LMSInitialize

Il metodo Initialize indica all’LMS che il contenuto desidera avviare una sessione di comunicazione. Tutti gli SCO devono chiamare Initialize prima di eseguire qualsiasi altra comunicazione. LMS restituisce un booleano che indica il successo o il fallimento dell’inizializzazione. In genere, gli LMS non hanno bisogno di fare molta inizializzazione e restituiranno sempre “true”.

Terminate / LMSFinish

Il metodo Terminate indica al LMS che il contenuto è fatto comunicare. Tutti gli SCO devono chiamare Terminate. Chiamare Terminate non indica necessariamente che l’utente ha terminato con SCO, tecnicamente indica solo che la SCO è stata comunicata. In pratica, tuttavia, il contenuto sarà più compatibile e utilizzabile se Terminate viene chiamato solo quando il contenuto può essere tolto all’utente. Poiché Terminate è richiesto di essere sempre chiamato, indipendentemente da come lo studente esce dallo SCO, è consigliabile effettuare una chiamata per Terminare nell’evento onunload di uno SCO. Il valore booleano restituito dall’LMS indica spesso se i dati SCO sono stati mantenuti correttamente sul server.

GetValue / LMSGetValue

Il metodo GetValue consente a SCO di recuperare i dati dal LMS. I dati che vengono sempre recuperati sono uno degli elementi definiti del modello di dati SCORM. Ciascuno di questi elementi del modello di dati contiene un pezzo diverso di dati. Alcuni degli elementi del modello di dati hanno valori inizializzati dall’LMS che parlano delle circostanze in cui viene lanciato lo SCO. Altri valori vengono inizializzati dallo SCO tramite chiamate a SetValue. Se la chiamata a GetValue restituisce una stringa vuota, è possibile che si sia verificato un errore e che il metodo GetLastError debba essere richiamato per verificare la presenza di problemi.

SetValue / LMSSetValue

Il metodo SetValue consente allo SCO di mantenere i dati nell’LMS. I dati vengono sempre memorizzati in uno degli elementi del modello di dati SCORM definiti. Alcuni elementi del modello di dati sono vincolati ad avere valori in un vocabolario limitato (ad esempio, lo stato potrebbe essere “completato” o “passato”), altri sono vincolati ad essere un tipo di dati specifico (ad esempio, il punteggio deve sempre essere un numero) mentre altri consentono allo SCO di mantenere dati di testo libero senza significato semantico. La chiamata SetValue restituisce un valore booleano che indica il successo o il fallimento della chiamata.

Commit / LMSCommit

Il metodo Commit segnala all’LMS che un mandrino significativo di dati è stato salvato e che dovrebbe garantire la corretta persistenza dei dati. Non ci sono requisiti per come LMS dovrebbe implementare il metodo di Commit, è semplicemente un segnale informativo. Alcuni LMS effettueranno un round trip al server per ogni chiamata da eseguire per garantire che tutti i dati siano persistenti. Sebbene intuitiva, questa strategia di implementazione può portare a problemi di scalabilità. Fare attenzione a non chiamare Commit eccessivamente in modo da non sovraccaricare questi LMS.

GetLastError / LMSGetLastError

Il metodo GetLastError controlla se l’ultima chiamata API SCORM ha causato un errore. In tal caso, questo metodo restituisce un numero di errore che corrisponde a un insieme definito di possibili errori. Alcuni numeri di errore rappresentano situazioni perfettamente legittime (come 403-Elemento del modello di dati non inizializzato). Gli autori SCO dovrebbero fare attenzione a segnalare solo errori legittimamente imprevisti all’utente. L’elenco completo dei codici di errore può essere trovato nel grafico di riferimento SCORM runtime.

GetErrorString / LMSGetErrorString

Dato un particolare numero di errore (di solito il numero di errore restituito da GetLastError), il metodo GetErrorString restituirà una descrizione testuale di ciò che significa il codice di errore. Ad esempio, in SCORM 2004, il passaggio del numero di errore “406” restituirà una stringa che dice “Mancata corrispondenza del tipo di elemento del modello di dati” per indicare che il risultato della chiamata precedente (probabilmente un SetValue) non è riuscito perché i dati memorizzati non erano nel formato corretto.

GetDiagnostic / LMSGetDiagnostic

Il metodo GetDiagnostic consente all’LMS di restituire informazioni dettagliate sull’errore precedente che possono essere utili per diagnosticare il problema. Ad esempio, le informazioni diagnostiche per l’errore “406” menzionato sopra potrebbero essere “Il valore” zero ” non è consentito per cmi.Punteggio.materia. Il cmi.Punteggio.l’elemento raw deve contenere un numero valido rappresentato solo come cifre”.

Il modello di dati runtime SCORM

Il modello di dati runtime contiene molti elementi, ognuno dei quali ha il suo significato. Gli elementi possono essere letti e scritti utilizzando l’API. Il grafico di riferimento SCORM runtime contiene un elenco di ogni elemento del modello di dati con il suo tipo di dati e una breve descrizione del suo significato e l’utilizzo.

Ogni SCO ha il proprio set di dati di runtime. Ciascuno di questi elementi del modello di dati ha un valore separato per ogni SCO all’interno di un corso, gli elementi del modello di dati non sono condivisi tra SCO. Inoltre, ogni “tentativo” su uno SCO ha il proprio set di dati di runtime. Quando lo studente avvia un nuovo tentativo su un SCO, i valori del modello di dati verranno reimpostati per l’inizio del nuovo tentativo.

Gli elementi del modello di dati sono leggermente diversi tra le versioni SCORM, ma per la maggior parte c’è un elemento corrispondente in ogni versione degli standard. SCORM 1.1 e SCORM 1.2 hanno modelli di dati identici. SCORM 2004 ha un set di modelli di dati diverso. Ci sono piccole differenze sottili tra le edizioni di SCORM 2004 pure. Il grafico fornisce un riferimento completo per ogni versione / edizione. I cambiamenti più significativi nello SCORM 2004 includono:

• Ridenominazione minore, principalmente rimuovendo il “core” dai nomi degli elementi del modello di dati.
• Separazione di stato. In SCORM 1.2 un singolo elemento, cmi.core.lesson_status rappresenta lo stato dello SCO. In SCORM 2004, lo stato è suddiviso in due elementi separati, cmi.completion_status (completato vs incompleto) e cmi.success_status (passato vs fallito).
• Le interazioni (risultati delle domande) sono in lettura/scrittura anziché in sola scrittura. Le interazioni contengono anche un campo di descrizione che mancava in SCORM 1.2.
• Aggiunta di adl.nav.* elementi del modello di dati che consentono allo SCO di avviare richieste di sequenziamento

L’utilizzo del runtime

L’utilizzo del runtime SCORM è in gran parte facoltativo dal punto di vista della conformità rigorosa, tuttavia la norma del settore consiste nell’utilizzare almeno un sottoinsieme degli elementi del modello di dati runtime disponibili.

Nel modo più semplice, se il tuo corso non contiene altro che risorse lanciabili, non sono necessarie chiamate in fase di esecuzione. L’LMS avvia semplicemente ogni risorsa come richiesto dall’utente e la risorsa viene considerata completata immediatamente al momento del lancio.

Per un’interazione più ricca, la prima cosa che dobbiamo fare è abilitare la comunicazione in fase di esecuzione. Ciò comporterà la ricerca dell’API e quindi l’assicurazione che Initialize e Terminate vengano chiamati. Nella maggior parte dei casi, Initialize deve essere chiamato immediatamente dopo l’avvio di SCO. Una volta che initialize è stato chiamato, è essenziale che Terminate sia chiamato in ogni scenario di uscita.

Una volta inizializzata la comunicazione, è ora di iniziare a comunicare effettivamente i dati. I seguenti elementi del modello di dati” 1st tier ” sono i più importanti e più comunemente utilizzati (SCORM 1.2 equivalente tra parentesi):

• imc.completo_stato & cmi.success_stato (cmi.core.lesson_status – – Questi elementi del modello di dati sono i più fondamentali e importanti. Indicano quando un utente ha terminato un corso e se ha superato o fallito. Questa informazione fondamentale è essenziale per la maggior parte dei LMS.
• cmi.Punteggio.scaled (cmi.core.Punteggio.raw) – Indica il punteggio che lo studente ha guadagnato su qualsiasi valutazione all’interno di una SCO. Segnalazione di un punteggio min e max in combinazione con un punteggio grezzo è anche buona forma.
• cmi.session_time (cmi.core.session_time) – Riporta la quantità di tempo che lo studente ha trascorso nella SCO.
• cmi.posizione (cmi.core.lesson_location) – Fornisce un campo di testo libero per la SCO per registrare un segnalibro. Se SCO è più grande di un paio di pagine HTML, dovrebbe considerare l’implementazione di una funzione di bookmarking per consentire allo studente di riprendere un tentativo in pausa.
• cmi.uscita (cmi.core.exit) – Questo valore indica come lo studente sta uscendo dalla SCO. Impostazione cmi.esci su “sospendi” assicurerà che il tentativo corrente sia conservato e che i dati di runtime non vengano reimpostati al successivo avvio dello SCO. Impostazione cmi.uscire a “” indicherà che l’LMS dovrebbe iniziare un nuovo tentativo con una nuova serie di dati di runtime sul prossimo lancio della SCO.

Industry norm prevede che tutti gli elementi dei modelli di dati di 1 ° livello vengano utilizzati correttamente in uno SCO. Una volta abilitata tale funzionalità, i successivi elementi del modello di dati più comuni, o 2 ° livello, includono:

• interazioni-Utilizzare gli elementi del modello di dati delle interazioni per segnalare i risultati di ogni risposta alla domanda. Un’interazione non deve essere una risposta di prova tradizionale. Ad esempio, uno SCO potrebbe documentare le scelte dello studente mentre progredisce attraverso una simulazione. Se possibile, utilizzare tutti gli elementi delle interazioni per fornire il quadro più completo delle risposte dello studente. Come minimo, utilizzare “id”, “tipo”, “risultato” e “descrizione” per consentire agli LMS di fornire report di base.
• obiettivi – Nelle grandi SCO, considerare la possibilità di riferire sulla padronanza dello studente di specifici obiettivi di apprendimento utilizzando gli elementi del modello di dati degli obiettivi. Gli obiettivi consentono una segnalazione più granulare dei progressi dello studente attraverso e la padronanza del materiale di formazione.
• cmi.progress_measure-Utilizzare l’elemento progress_measure in SCORM 2004 per segnalare i progressi dell’utente verso il completamento di un SCO. Il progress_measure è come una misura “percentuale completa” che consentirebbe al LMS di fornire una barra di avanzamento del completamento complessivo di un corso.

Ingresso, modalità e credito

Il cmi.ingresso (cmi.core.voce), cmi.modalità (cmi.core.modalità di lezione) e cmi.credito (cmi.core.credito) gli elementi del modello di dati forniscono allo SCO un contesto che può utilizzare per fornire allo studente l’esperienza ottimale.

• cmi.la voce indica se l’utente sta avviando SCO per la prima volta o se sta riprendendo un tentativo precedente. Se si utilizza il bookmarking, SCO potrebbe utilizzare questo valore per richiedere all’utente di iniziare dall’inizio o dal punto in cui è terminato il tentativo precedente.
• cmi.modalità indica se lo studente sta lanciando questo SCO: normalmente – in una sessione di allenamento “live”; in modalità browse – l’utente sta sfogliando un catalogo di formazione e vuole” visualizzare in anteprima ” questo corso; o, in modalità review – l’utente ha già completato lo SCO e sta tornando a rivedere il materiale. In modalità sfoglia, l’autore SCO dovrebbe prendere in considerazione la possibilità di modificare il comportamento SCOs per fornire una navigazione in forma più libera, fornire una panoramica o una mappa del corso ed eventualmente nascondere le valutazioni. In modalità di revisione, l’autore SCO dovrebbe allo stesso modo considerare consentendo la più snella completa libertà di navigazione. In modalità di revisione, lo studente potrebbe anche essere in grado di navigare liberamente eventuali test e sfogliare un elenco di risposte corrette. Quando viene lanciato in modalità di revisione, uno SCO dovrebbe fare attenzione a non modificare lo stato dello studente o ripristinare il punteggio.
• cmi.credito indica se questo SCO è in fase di tentativo di credito, o se non “conta”. Simile alla modalità browse, se uno SCO viene lanciato per nessun credito, il comportamento dovrebbe probabilmente essere alterato.