SCORM Run-Time Environment

oversigt over SCORM Run-Time environment

SCORM Run-Time specifikationen styrer, hvordan LMS lancerer indhold, og hvordan indholdet derefter kommunikerer med LMS. Al denne kommunikation sker inden for rammerne af et enkelt forsøg på en enkelt SCO. Navigationen mellem SCOs styres af den sekventering, der er angivet i manifestet, og forklares yderligere her.

lancering af indhold

alt SCORM-indhold skal kunne leveres på nettet, og al SCORM-kommunikation sker inden for rammerne af en session. LMS vil lancere en SCO ad gangen, som valgt af brugeren, eller som bestemt af SCORM 2004 sekventering regler. I versioner før SCORM 2004 3. udgave var der ingen formelle krav til brugergrænsefladen leveret af en LMS. Hver LMS er lidt anderledes, men for det meste er det rimeligt at forvente, at en LMS giver en grænseflade, der ligner den, der er afbildet nedenfor. Som minimum skal den indeholde en eller anden form for navigerbar indholdsfortegnelse samt kontroller til strømnavigation (forrige og næste knapper). Disse navigationselementer styrer navigationen mellem SCOs. Hvis navigation er nødvendig inden for en SCO, skal SCO levere sine egne navigationselementer.

LMS har to muligheder for at starte en SCO. Det kan enten starte SCO ina-rammesættet (som vist ovenfor), eller det kan starte SCO i et nyt vindue. Nogle LMS ‘ er vil altid lancere indhold på den ene eller den anden måde. Almindeligvis, hvis et kursus kun indeholder en SCO (og dermed ikke kræver og navigationselementer fra LMS), vil SCO blive lanceret i et popup-vindue. Omvendt, hvis kurset indeholder mange SCOs, vil LMS almindeligvis lancere SCOs i et rammesæt omgivet af navigationselementer. Nogle LMS ‘ er giver indholdsforfatterne mulighed for at kontrollere nøjagtigt, hvordan SCOs lanceres, hvilke navigationselementer der er tilgængelige og endda størrelsen på SCO-vinduerne.

API

al kommunikation mellem en SCO og LMS sker gennem en ECMAScript (JavaScript) API. Dette er den eneste måde, hvorpå kommunikation kan forekomme. Der er ingen andre kommunikationskanaler til rådighed. Indhold kan ikke kommunikere via internettjenester, formularindlæg, databaseskrivninger eller nogen anden mekanisme, kun via JavaScript API leveret af LMS.

find API

LMS er ansvarlig for at levere et specifikt navngivet JavaScript-objekt på et bestemt sted i Bro.sererens DOM. Således kan indholdet altid finde denne API ved hjælp af en fælles algoritme.

i SCORM 1.1 og SCORM 1.2 hedder API-objektet altid “API”. I SCORM 2004 hedder objektet “API_1484_11”.

API-objektet skal placeres i et vindue, der er en forælder til SCO eller en forælder til åbnings-vinduet i SCO. Et” overordnet ” vindue er defineret til at være hele kæden af overordnede vinduer helt op til rodvinduet. Så API ‘en kunne være i SCO’ s forælder, SCO ‘s forældres forælder, SCO’ s forældres forældres forælder osv. Tilsvarende kan API ‘ en være i åbnervinduet, åbnerens forælder, åbnerens forældres forælder osv. Diagrammerne nedenfor fra SCORM 2004 3rd Edition-specifikationen illustrerer de mulige API-placeringer.

SCORM indeholder specifikke algoritmer, som Indhold kan bruge til at finde SCORM API.

brug af API

når en SCO har fundet SCORM API, kan den bruge API ‘ en til at kommunikere med LMS. Bemærk, at kun SCO kan indlede kommunikation. LMS er en passiv enhed, der blot reagerer på API-opkald foretaget af indholdet. LMS kan ikke starte nogen kommunikation, det lancerer simpelthen indholdet og reagerer på anmodninger.

SCORM API indeholder otte metoder med følgende signaturer:

SCORM 2004

Initialiser( "" ) : bool Afslut( "" ) : bool GetValue( element : CMIElement ) : string SetValue( element: cmielement) : CMIElement, værdi: 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

metodenavne varierer lidt mellem SCORM-versioner, men konceptuelt er metoderne identiske.

noter:

• bool-typen er en SCORM boolsk, som faktisk er en streng med værdien “sand” eller “falsk”.
• parameteren “” kræves af alle SCORM-metoder, der ikke accepterer andre argumenter. SCOs er simpelthen forpligtet til at videregive en tom strengparameter til disse metoder.
• cmielement-datatypen er en streng svarende til SCORM-datamodelelementerne beskrevet nedenfor.
• datatypen CMIErrorCode er et trecifret tal, repræsenteret en streng, der svarer til en af SCORM Run-time fejlkoder.

Initialiser / Lmsinitialiser

Initialiseringsmetoden indikerer til LMS, at indholdet gerne vil starte en kommunikationssession. Alle SCO ‘ er skal ringe initialisere, før de udfører anden kommunikation. LMS returnerer en boolsk, der angiver initialiseringens succes eller fiasko. Typisk behøver LMS ‘ er ikke at foretage en masse initialisering og vil altid vende tilbage “sandt”.

Afslut / LMSFinish

Afslutningsmetoden angiver til LMS, at indholdet er færdig med at kommunikere. Alle SCOs skal kalde opsige. Opkald opsige betyder ikke nødvendigvis, at brugeren er færdig med SCO, teknisk det kun angiver SCO er færdig kommunikere. I praksis vil indholdet dog være mere kompatibelt og brugbart, hvis Terminate kun kaldes, når indholdet kan tages væk fra brugeren. Da opsige er forpligtet til altid at blive kaldt, uanset hvordan eleven forlader SCO, er det klogt at placere et opkald til at afslutte i onunload tilfælde af en SCO. Den boolske værdi, der returneres af LMS, indikerer ofte, om SCO-data med succes blev vedvarende til serveren.

GetValue / LMSGetValue

GetValue-metoden tillader en SCO at hente data fra LMS. De data, der altid hentes, er et af de definerede SCORM-datamodelelementer. Hvert af disse datamodelelementer indeholder et andet stykke data. Nogle af datamodelelementerne har værdier initialiseret af LMS, der taler til de omstændigheder, hvorunder SCO lanceres. Andre værdier initialiseres af SCO gennem opkald til SetValue. Hvis opkaldet til GetValue returnerer en tom streng, er det muligt, at der opstod en fejl, og GetLastError-metoden skal påberåbes for at kontrollere problemer.

SetValue / LMSSetValue

SetValue-metoden gør det muligt for SCO at fortsætte data til LMS. Dataene gemmes altid i et af de definerede SCORM-datamodelelementer. Nogle datamodelelementer er begrænset til at have værdier i et begrænset ordforråd (for eksempel kan status være “afsluttet” eller “bestået”), andre er begrænset til at være en bestemt datatype (for eksempel skal score altid være et tal), mens andre tillader SCO at fortsætte fritekstdata uden semantisk betydning. SetValue-opkaldet returnerer en boolsk, der angiver succes eller fiasko for opkaldet.

Commit / LMSCommit

Commit-metoden signalerer til LMS, at der er gemt en betydelig chuck af data, og at den skal sikre, at dataene er korrekt vedvarende. Der er ingen krav til, hvordan LMS skal implementere Commit-metoden, det er simpelthen et informativt signal. Nogle LMS ‘ er foretager en rundtur til serveren for hvert opkald for at forpligte sig til at sikre, at alle data vedvarer. Selvom den er intuitiv, kan denne implementeringsstrategi føre til skalerbarhedsproblemer. Pas på ikke at kalde begå overdrevent for ikke at overbelaste disse LMS ‘ er.

GetLastError / LMSGetLastError

GetLastError-metoden kontrollerer, om det sidste SCORM API-opkald forårsagede en fejl. I så fald returnerer denne metode et fejlnummer, der svarer til et defineret sæt mulige fejl. Nogle fejlnumre repræsenterer helt legitime situationer (såsom 403 – Datamodelelement ikke initialiseret). SCO-forfattere skal passe på kun at markere legitimt uventede fejl for brugeren. Den komplette liste over fejlkoder kan findes i SCORM run-time reference chart.

GetErrorString / LMSGetErrorString

givet et bestemt fejlnummer (normalt fejlnummeret returneret fra GetLastError), returnerer GetErrorString-metoden en tekstbeskrivelse af, hvad fejlkoden betyder. For eksempel i SCORM 2004, passerer fejlnummer “406” returnerer en streng, der siger “Data Model Element Type Mismatch” for at indikere, at resultatet af det forrige opkald (sandsynligvis en SetValue) mislykkedes, fordi de data, der blev gemt, ikke var i det korrekte format.

GetDiagnostic / LMSGetDiagnostic

GetDiagnostic-metoden gør det muligt for LMS at returnere detaljerede oplysninger om den tidligere fejl, der kan være nyttige til diagnosticering af problemet. For eksempel kan de diagnostiske oplysninger for “406” – fejlen nævnt ovenfor være “værdien” nul ” er ikke tilladt for cmi.Resultat.råvare. Cmi.Resultat.rå element skal indeholde et gyldigt tal kun repræsenteret som cifre”.

SCORM Run-Time data model

run-time data model indeholder mange elementer, som hver har sin egen betydning. Elementerne kan læses og skrives ved hjælp af API. SCORM run-time reference-diagrammet indeholder en liste over hvert datamodelelement sammen med dets datatype og en kort beskrivelse af dets betydning og brug.

hver SCO har sit eget sæt af run-time data. Hvert af disse datamodelelementer har en separat værdi for hver SCO inden for et kursus, datamodelelementer deles ikke på tværs af SCO ‘ er. Desuden har hvert” forsøg ” på en SCO sit eget sæt kørselsdata. Når eleven starter et nyt forsøg på en SCO, nulstilles datamodelværdierne til starten af det nye forsøg.

datamodelelementerne er lidt forskellige på tværs af SCORM-versioner, men for det meste er der et tilsvarende element i hver version af standarderne. SCORM 1.1 og SCORM 1.2 har identiske datamodeller. SCORM 2004 har et andet datamodelsæt. Der er også mindre subtile forskelle mellem udgaverne af SCORM 2004. Diagrammet giver en omfattende reference for hver version/udgave. De mest markante ændringer i SCORM 2004 inkluderer:

• mindre omdøbning, for det meste at fjerne “kernen” fra datamodelelementnavne.
• adskillelse af status. I SCORM 1.2 et enkelt element, cmi.kerne.lesson_status repræsenterer SCO ‘ s status. I SCORM 2004 er status opdelt i to separate elementer, cmi.completion_status (afsluttet vs ufuldstændig) og cmi.success_status (bestået vs mislykkedes).
• interaktioner (spørgsmålsresultater) læses/skrives i stedet for kun at skrive. Interaktioner indeholder også et beskrivelsesfelt, der manglede i SCORM 1.2.
• tilføjelse af adl.navigation.* datamodelelementer, der gør det muligt for SCO at starte sekventeringsanmodninger

brug af Run-time

brug af SCORM run-time er stort set valgfri ud fra et strengt konformitetsperspektiv, men branchenormen er at bruge mindst en delmængde af de run-time datamodelelementer, der er tilgængelige for dig.

hvis dit kursus kun indeholder aktiver, der kan lanceres, er der ikke behov for opkald i runtime. LMS lancerer simpelthen hvert aktiv som anmodet af brugeren, og aktivet anses for at være afsluttet umiddelbart efter lanceringen.

for en rigere interaktion er det første, vi skal gøre, at aktivere run-time kommunikation. Det vil indebære at finde API ‘ en og derefter sikre, at initialisere og afslutte kaldes. I de fleste tilfælde skal initialisere kaldes umiddelbart efter SCO er lanceret. Når initialisere er blevet kaldt, er det vigtigt, at opsige kaldes i hvert udgangsscenarie.

når kommunikationen er initialiseret, er det tid til at begynde at kommunikere data. Følgende” 1.tier ” datamodelelementer er de vigtigste og mest almindeligt anvendte (SCORM 1.2 tilsvarende i parentes):

• cmi.completion_status & cmi.success_status (cmi.kerne.lesson_status) – disse datamodelelementer er de mest grundlæggende og vigtige. De angiver, hvornår en bruger har afsluttet et kursus, og om han bestod eller mislykkedes. Denne grundlæggende information er afgørende for de fleste LMS ‘ er.
• cmi.Resultat.skaleret (cmi.kerne.Resultat.rå) – angiver den score, som eleven tjente på enhver vurdering inden for en SCO. Rapportering af en min og maks score i forbindelse med en rå score er også god form.
• cmi.session_time (cmi.kerne.session_time) – rapporterer den tid, som eleven brugte i SCO.
• cmi.placering (cmi.kerne.lesson_location) – giver et fritekstfelt for SCO at optage et bogmærke. Hvis SCO er større end blot et par HTML-sider, bør den overveje at implementere en bogmærkefunktion for at lade eleven genoptage et pauset forsøg.
• cmi.Afslut (cmi.kerne.afslut) – denne værdi angiver, hvordan eleven forlader SCO. Indstilling cmi.Afslut til” suspend ” vil sikre, at det aktuelle forsøg bevares, og kørselsdataene nulstilles ikke næste gang SCO lanceres. Indstilling cmi.Afslut til “” vil indikere, at LMS skal begynde et nyt forsøg med et nyt sæt kørselsdata ved den næste lancering af SCO.

Industry norm forventer, at alle 1.tier data models elementer skal bruges korrekt i en SCO. Når denne funktionalitet er aktiveret, inkluderer de næste mest almindelige datamodelelementer eller 2. niveau:

• interaktioner-brug interaktionsdatamodelelementerne til at rapportere resultaterne af hvert spørgsmålssvar. En interaktion behøver ikke at være et traditionelt Testsvar. For eksempel kunne en SCO dokumentere elevens valg, når han skrider frem gennem en simulering. Hvis det er muligt, skal du bruge alle interaktionselementerne til at give det mest omfattende billede af elevens svar. Brug som minimum “id”, “type”, “resultat” og “beskrivelse” for at give LMS ‘ er mulighed for at levere grundlæggende rapportering.
• mål – i store SCO ‘ er skal du overveje at rapportere om elevens mestring af specifikke læringsmål ved hjælp af måldatamodelelementerne. Mål giver mulighed for mere detaljeret rapportering af elevens fremskridt gennem og beherskelse af træningsmaterialet.
• cmi.progress_measure-brug progress_measure-elementet i SCORM 2004 til at rapportere brugerens fremskridt mod færdiggørelse af en SCO. Progress_measure er som en” procent komplet ” foranstaltning, der gør det muligt for LMS at give en statuslinje for den samlede gennemførelse af et kursus.

indgang, tilstand og kredit

cmi.indgang (cmi.kerne.indgang), cmi.tilstand (cmi.kerne.lesson_mode) og cmi.kredit (cmi.kerne.kredit) datamodelelementer giver SCO en vis kontekst, den kan bruge til at give eleven den optimale oplevelse.

• cmi.indtastning angiver, om brugeren starter SCO for første gang, eller om den genoptager et tidligere forsøg. Hvis du bruger bogmærkning, bruger SCO muligvis denne værdi til at bede brugeren om at starte fra begyndelsen eller fra det punkt, hvor det forrige forsøg sluttede.
• cmi.tilstand angiver, om eleven lancerer denne SCO: normalt – i en “live” træningssession; i Gennemse – tilstand – brugeren gennemser et katalog over træning og ønsker at “forhåndsvise” dette kursus; eller i gennemgangstilstand-brugeren har allerede afsluttet SCO og kommer tilbage for at gennemgå materialet. I gennemse-tilstand, SCO-forfatteren bør overveje at ændre SCOs-adfærd for at give mere fri formnavigation, give et overblik eller kort over kurset og muligvis skjule vurderinger. I gennemgangstilstand bør SCO-forfatteren ligeledes overveje at tillade den slankere komplette navigationsfrihed. I gennemgangstilstand kan eleven muligvis også frit navigere i alle test og gennemse en liste med korrekte svar. Når den startes i gennemgangstilstand, skal en SCO være forsigtig med ikke at ændre elevens status eller nulstille scoren.
• cmi.kredit angiver, om denne SCO forsøges for kredit, eller om det “tæller”eller ej. I lighed med gennemse-tilstand, hvis en SCO lanceres uden kredit, bør adfærden sandsynligvis ændres.