środowisko czasu pracy SCORM

przegląd środowiska pracy SCORM

Specyfikacja czasu pracy SCORM kontroluje, w jaki sposób LMS uruchamia zawartość i jak zawartość komunikuje się z LMS. Cała ta komunikacja odbywa się w kontekście jednej próby na jednym SCO. Nawigacja między SCOs jest regulowana przez sekwencjonowanie określone w manifeście i wyjaśnione dalej tutaj.

uruchamianie zawartości

Cała zawartość SCORM musi być dostarczana przez internet, a cała komunikacja SCORM odbywa się w kontekście sesji przeglądarki internetowej. LMS będzie uruchamiał po jednym SCO na raz, zgodnie z wyborem użytkownika lub zgodnie z zasadami sekwencjonowania SCORM 2004. W wersjach sprzed 3 edycji SCORM 2004 nie było żadnych formalnych wymagań dla interfejsu użytkownika dostarczanego przez LMS. Każdy LMS jest nieco inny, ale w większości przypadków można oczekiwać, że LMS zapewni interfejs podobny do tego pokazanego poniżej. Powinien zawierać przynajmniej pewną formę nawigacyjnego spisu treści, a także elementy sterujące nawigacją przepływową (przyciski Poprzedni i następny). Te elementy nawigacyjne kontrolują nawigację między SCOs. Jeśli nawigacja jest potrzebna w ramach SCO, SCO musi zapewnić własne elementy nawigacyjne.

LMS ma dwie opcje uruchamiania SCO. Może uruchomić zestaw ramek SCO ina (jak na zdjęciu powyżej) lub może uruchomić SCO w nowym oknie. Niektóre LMS-y zawsze uruchamiają zawartość w taki czy inny sposób. Zwykle jednak, jeśli kurs zawiera tylko jeden SCO (a zatem nie wymaga i elementy nawigacyjne z LMS), SCO zostanie uruchomiony w wyskakującym oknie. Z drugiej strony, jeśli kurs zawiera wiele SCOs, LMS będzie zwykle uruchamiał SCOs w ramce otoczonej elementami nawigacyjnymi. Niektóre LMS-y pozwolą autorom treści precyzyjnie kontrolować sposób uruchamiania SCOs, które elementy nawigacyjne są dostępne, a nawet rozmiar okien SCO.

API

cała komunikacja między SCO a LMS odbywa się za pośrednictwem interfejsu API ECMAScript (JavaScript). To jedyny sposób komunikacji. Nie ma innych dostępnych kanałów komunikacji. Treści nie mogą komunikować się za pośrednictwem usług internetowych, postów formularzy, zapisów w bazie danych ani żadnego innego mechanizmu, tylko za pośrednictwem JavaScript API dostarczanego przez LMS.

znajdowanie API

LMS jest odpowiedzialny za dostarczenie specjalnie nazwanego obiektu JavaScript w określonej lokalizacji w drzewie DOM przeglądarki. Tak więc, zawartość, zawsze może zlokalizować to API za pomocą wspólnego algorytmu.

w SCORM 1.1 i SCORM 1.2 obiekt API zawsze nosi nazwę „API”. W SCORM 2004 obiekt nosi nazwę „API_1484_11”.

obiekt API powinien znajdować się w oknie, które jest rodzicem SCO lub rodzicem okna otwierającego SCO. Okno „rodzic”jest zdefiniowane jako cały łańcuch okien nadrzędnych aż do głównego okna przeglądarki. Tak więc API może znajdować się w rodzicu SCO, rodzicu SCO, rodzicu SCO, itd. Podobnie API może znajdować się w oknie otwierającego, rodzicu otwierającego, rodzicu otwierającego itp. Poniższe diagramy ze specyfikacji SCORM 2004 3rd Edition ilustrują możliwe lokalizacje API.

SCORM zawiera określone algorytmy, których content może użyć do znalezienia interfejsu API SCORM.

Korzystanie z API

gdy SCO znajdzie API SCORM, może używać API do komunikacji z LMS. Zauważ, że tylko SCO może zainicjować komunikację. LMS jest pasywnym podmiotem, który po prostu reaguje na wywołania API wykonane przez zawartość. LMS nie może zainicjować żadnej komunikacji, po prostu uruchamia treść i odpowiada na żądania.

SCORM API zawiera osiem metod z następującymi podpisami:

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

nazwy metod różnią się nieznacznie między wersjami SCORM, ale koncepcyjnie metody są identyczne.

uwagi:

• Typ bool jest SCORM boolean, który jest w rzeczywistości łańcuchem o wartości „true” lub „false”.
• parametr „” jest wymagany przez wszystkie metody SCORM, które nie akceptują żadnych innych argumentów. SCOs są po prostu wymagane do przekazania pustego parametru string do tych metod.
• typ danych CMIElement jest łańcuchem znaków odpowiadającym elementom modelu danych SCORM opisanym poniżej.
• typ danych CMIErrorCode to trzycyfrowa liczba, reprezentowana ciągiem znaków, odpowiadająca jednemu z kodów błędów w czasie wykonywania SCORM.

Initialize / LMSInitialize

metoda Initialize wskazuje LMS, że zawartość chciałaby rozpocząć sesję komunikacji. Wszystkie SCOs muszą wywołać Initialize przed wykonaniem jakiejkolwiek innej komunikacji. LMS Zwraca wartość logiczną wskazującą na powodzenie lub niepowodzenie inicjalizacji. Zazwyczaj LMS ’ y nie muszą wykonywać wielu inicjalizacji i zawsze zwracają „true”.

Terminate / LMSFinish

metoda Terminate wskazuje LMS, że treść jest zakończona. Wszyscy SCOs muszą zakończyć. Wywołanie zakończenia nie musi oznaczać, że użytkownik jest skończony z SCO, technicznie oznacza to tylko, że SCO jest skończony. W praktyce jednak zawartość będzie bardziej kompatybilna i użyteczna, jeśli Terminate zostanie wywołany tylko wtedy, gdy zawartość może zostać odebrana użytkownikowi. Ponieważ Terminate musi być zawsze wywoływany, bez względu na to, w jaki sposób uczeń opuszcza SCO, rozsądnie jest wywołać Terminate w zdarzeniu onunload SCO. Wartość logiczna zwracana przez LMS często wskazuje, czy dane SCO zostały pomyślnie zapisane na serwerze.

GetValue / Lmsgetvalue

metoda GetValue umożliwia SCO pobieranie danych z LMS. Dane, które są zawsze pobierane, są jednym ze zdefiniowanych elementów modelu danych SCORM. Każdy z tych elementów modelu danych zawiera inny fragment danych. Niektóre elementy modelu danych mają wartości inicjowane przez LMS, które mówią o okolicznościach, w których SCO jest uruchamiany. Inne wartości są inicjowane przez SCO poprzez wywołania SetValue. Jeśli wywołanie GetValue zwraca pusty łańcuch, możliwe jest, że wystąpił błąd i należy wywołać metodę GetLastError w celu sprawdzenia problemów.

SetValue / LMSSetValue

metoda SetValue umożliwia SCO przechowywanie danych w LMS. Dane są zawsze przechowywane w jednym ze zdefiniowanych elementów modelu danych SCORM. Niektóre elementy modelu danych są ograniczone do posiadania wartości w ograniczonym słownictwie (na przykład status może być „ukończony” lub „przekazany”), inne są ograniczone do bycia określonym typem danych (na przykład wynik musi być zawsze liczbą), podczas gdy inne pozwalają SCO na przechowywanie wolnych danych tekstowych bez znaczenia semantycznego. Wywołanie SetValue Zwraca wartość logiczną wskazującą na powodzenie lub niepowodzenie wywołania.

Commit / LMSCommit

metoda Commit sygnalizuje LMS, że znaczna część danych została zapisana i że powinna zapewnić prawidłowe zachowanie danych. Nie ma wymagań co do tego, jak LMS powinien zaimplementować metodę Commit, jest to po prostu sygnał informacyjny. Niektóre LMS ’ y wykonają podróż w obie strony do serwera dla każdego połączenia, aby upewnić się, że wszystkie dane są utrzymywane. Ta intuicyjna strategia implementacji może prowadzić do problemów ze skalowalnością. Uważaj, aby nie wywoływać nadmiernie Commit, aby nie przeciążyć tych LMS-ów.

GetLastError / LMSGetLastError

metoda GetLastError sprawdza, czy ostatnie wywołanie API SCORM spowodowało błąd. Jeśli tak, to ta metoda zwraca numer błędu, który odpowiada zdefiniowanemu zestawowi możliwych błędów. Niektóre liczby błędów reprezentują całkowicie uzasadnione sytuacje (takie jak 403 – Element modelu danych nie zainicjowany). Autorzy SCO powinni dbać o to, aby zgłaszać użytkownikowi jedynie legalnie nieoczekiwane błędy. Pełną listę kodów błędów można znaleźć na wykresie referencyjnym SCORM run-time.

GetErrorString / LMSGetErrorString

biorąc pod uwagę konkretny numer błędu (zwykle numer błędu zwracany z GetLastError), metoda GetErrorString zwróci tekstowy opis tego, co oznacza kod błędu. Na przykład, w SCORM 2004, podanie numeru błędu ” 406 „zwróci ciąg znaków z napisem” Data Model element Type Mismatch”, aby wskazać, że wynik poprzedniego wywołania (prawdopodobnie wartość SetValue) nie powiódł się, ponieważ przechowywane dane nie były w odpowiednim formacie.

GetDiagnostic / LMSGetDiagnostic

metoda GetDiagnostic pozwala LMS zwrócić szczegółowe informacje o wcześniejszym błędzie, które mogą być przydatne w diagnozowaniu problemu. Na przykład informacja diagnostyczna dla wspomnianego powyżej błędu ” 406 „może brzmieć:” wartość 'zero’ nie jest dozwolona dla cmi.punkt.surowe. Cmi.punkt.surowy element musi zawierać poprawną liczbę reprezentowaną tylko jako cyfry”.

model danych Czasu Pracy SCORM

model danych czasu pracy zawiera wiele elementów, z których każdy ma swoje znaczenie. Elementy mogą być odczytywane i zapisywane za pomocą API. Wykres odniesienia SCORM run-time zawiera listę każdego elementu modelu danych wraz z jego typem danych i krótkim opisem jego znaczenia i użycia.

każdy SCO ma swój własny zestaw danych czasu pracy. Każdy z tych elementów modelu danych ma osobną wartość dla każdego SCO w ramach kursu, elementy modelu danych nie są współdzielone między SCOs. Co więcej, każda „próba”na SCO ma swój własny zestaw danych w czasie pracy. Gdy uczeń rozpocznie nową próbę na SCO, wartości modelu danych zostaną zresetowane na początku nowej próby.

elementy modelu danych są nieco inne w różnych wersjach SCORM, ale w większości przypadków istnieje odpowiedni element w każdej wersji standardów. SCORM 1.1 i SCORM 1.2 mają identyczne modele danych. SCORM 2004 ma inny zestaw modeli danych. Istnieją niewielkie subtelne różnice między edycjami SCORM 2004, jak również. Wykres zawiera wyczerpujące odniesienie dla każdej wersji / edycji. Do najważniejszych zmian w SCORM 2004 należą:

• drobne zmiany nazw, głównie usunięcie „rdzenia” z nazw elementów modelu danych.
• W SCORM 1.2 pojedynczy element, cmi.rdzeń.lesson_status reprezentuje status SCO. W SCORM 2004 status został podzielony na dwa oddzielne elementy, cmi.completion_status (zakończone vs niekompletne) i cmi.success_status (passed vs failed).
• interakcje (wyniki pytań) są odczytywane/zapisywane zamiast tylko do zapisu. Interakcje zawierają również Pole opisu, którego brakowało w SCORM 1.2.
• dodanie adl.nav.* elementy modelu danych, które umożliwiają SCO inicjowanie żądań sekwencjonowania

przy użyciu czasu pracy

Korzystanie z czasu pracy SCORM jest w dużej mierze opcjonalne z punktu widzenia ścisłej zgodności, jednak normą branżową jest użycie co najmniej podzbioru dostępnych elementów modelu danych w czasie pracy.

w najprostszym przypadku, jeśli kurs zawiera tylko zasoby uruchamialne, nie są potrzebne żadne połączenia w czasie wykonywania. LMS uruchamia po prostu każdy zasób zgodnie z życzeniem użytkownika, a zasób jest uważany za ukończony natychmiast po uruchomieniu.

aby uzyskać bogatszą interakcję, pierwszą rzeczą, którą musimy zrobić, to włączyć komunikację w czasie pracy. Będzie to wiązało się ze znalezieniem API, a następnie upewnieniem się, że wywołane są Initialize i Terminate. W większości przypadków Inicjalizacja powinna być wywołana natychmiast po uruchomieniu SCO. Po wywołaniu initialize, ważne jest, aby zakończyć być wywołane w każdym scenariuszu wyjścia.

po zainicjowaniu komunikacji nadszedł czas, aby zacząć faktycznie przekazywać dane. Najważniejsze i najczęściej stosowane są następujące elementy modelu danych „1st tier” (SCORM 1.2 odpowiedniki w nawiasach):

• cmi.completion_status & cmi.success_status (cmi.rdzeń.lesson_status) – te elementy modelu danych są najbardziej fundamentalne i ważne. Wskazują one, kiedy użytkownik ukończył kurs i czy zdał lub nie zdał. Te podstawowe informacje są niezbędne dla większości LMS.
• cmi.punkt.skalnica (cmi.rdzeń.punkt.raw) – oznacza wynik, który uczeń uzyskał na dowolnej ocenie w ramach SCO. Raportowanie wyniku min i max w połączeniu z wynikiem surowym jest również dobrą formą.
• session_time (cmi.rdzeń.session_time) – raportuje ilość czasu, jaki uczeń spędził w SCO.
• miejsce (cmi.rdzeń.lesson_location) – zapewnia wolne pole tekstowe Dla SCO do zapisania zakładki. Jeśli SCO jest większe niż tylko kilka stron HTML, należy rozważyć wdrożenie funkcji zakładek, aby umożliwić uczniowi wznowienie wstrzymanej próby.
• exit (cmi.rdzeń.exit) – wartość ta wskazuje, w jaki sposób uczeń opuszcza SCO. Ustawienie cmi.wyjście do „suspend” zapewni, że bieżąca próba zostanie zachowana, a DANE czasu pracy nie zostaną zresetowane przy następnym uruchomieniu SCO. Ustawienie cmi.Wyjście Do „” oznacza, że LMS powinien rozpocząć nową próbę z nowym zestawem danych w czasie pracy przy następnym uruchomieniu SCO.

Norma branżowa oczekuje, że wszystkie elementy modeli danych pierwszej warstwy będą poprawnie używane w SCO. Po włączeniu tej funkcjonalności do kolejnych najczęściej używanych elementów modelu danych, czyli warstwy drugiej, należą:

• interakcje-użyj elementów modelu danych interakcji, aby zgłosić wyniki każdej odpowiedzi na pytanie. Interakcja nie musi być tradycyjną odpowiedzią testową. Na przykład SCO może dokumentować wybory ucznia w trakcie symulacji. Jeśli to możliwe, wykorzystaj wszystkie elementy interakcji, aby zapewnić najbardziej wszechstronny obraz odpowiedzi ucznia. Co najmniej użyj „id”, „type”, „result” I „description”, aby umożliwić LMS dostarczenie podstawowego raportowania.
• cele-w dużych SCOs rozważ raportowanie na temat opanowania przez ucznia konkretnych celów uczenia się za pomocą elementów modelu danych celów. Cele pozwalają na bardziej szczegółowe raportowanie postępów ucznia i opanowanie materiału szkoleniowego.
• progress_measure-użyj elementu progress_measure w SCORM 2004, aby zgłosić postępy użytkownika w kierunku ukończenia SCO. Progress_measure jest jak miara „procent kompletności”, która umożliwiłaby LMS dostarczenie paska postępu ogólnego ukończenia kursu.

wejście, tryb i Kredyt

CMI.wejście (cmi.rdzeń.wejście), cmi.tryb (cmi.rdzeń.lesson_mode) oraz cmi.kredyt (cmi.rdzeń.credit) elementy modelu danych zapewniają SCO pewien kontekst, który może wykorzystać do zapewnienia uczniowi optymalnego doświadczenia.

• wpis wskazuje, czy użytkownik uruchamia SCO po raz pierwszy, czy wznawia wcześniejszą próbę. W przypadku korzystania z zakładek SCO może użyć tej wartości, aby zachęcić użytkownika do rozpoczęcia Od początku lub od punktu, w którym zakończyła się poprzednia próba.
• tryb wskazuje, czy uczący się uruchamia ten SCO: normalnie – w sesji treningowej „na żywo”; w trybie przeglądania – użytkownik przegląda katalog szkoleń i chce „przejrzeć” ten kurs; lub w trybie recenzji – użytkownik ukończył już Sco i wraca, aby przejrzeć materiał. W trybie przeglądania autor SCO powinien rozważyć zmianę zachowania SCOs, aby zapewnić bardziej swobodną nawigację formularzy, zapewnić przegląd lub mapę kursu i ewentualnie ukryć oceny. W trybie recenzji autor SCO powinien również rozważyć umożliwienie szczuplejszej pełnej swobody nawigacji. W trybie recenzji uczeń może również swobodnie poruszać się po testach i przeglądać listę poprawnych odpowiedzi. Po uruchomieniu w trybie recenzji SCO powinien uważać, aby nie zmieniać statusu ucznia ani nie resetować wyniku.
• kredyt wskazuje, czy SCO próbuje uzyskać kredyt, czy też”liczy się”. Podobnie jak w trybie przeglądania, jeśli SCO jest uruchamiany bez przypisania, zachowanie powinno być prawdopodobnie zmienione.