ambiente de tempo de execução do SCORM

Visão Geral do ambiente de tempo de execução do SCORM

a especificação de tempo de execução do SCORM controla como o LMS inicia o conteúdo e como o conteúdo se comunica com o LMS. Toda essa comunicação acontece dentro do contexto de uma única tentativa em uma única SCO. A navegação entre SCOs é regida pelo sequenciamento especificado no Manifesto e explicado mais adiante aqui.

lançamento de conteúdo

todo o conteúdo do SCORM deve ser entregue na web e toda a comunicação do SCORM ocorre no contexto de uma sessão do navegador da web. O LMS lançará um SCO de cada vez, conforme selecionado pelo usuário, ou conforme determinado pelas regras de sequenciamento do SCORM 2004. Nas versões anteriores à 3ª edição do SCORM 2004, não havia requisitos formais para a interface do usuário fornecida por um LMS. Cada LMS é um pouco diferente, mas na maior parte, é justo esperar que um LMS forneça uma interface semelhante à mostrada abaixo. No mínimo, deve conter alguma forma de índice navegável, bem como controles para navegação de fluxo (botões Anterior e seguinte). Esses elementos de navegação controlam a navegação entre SCOs. Se a navegação for necessária dentro de uma SCO, a SCO deve fornecer seus próprios elementos de navegação.

o LMS tem duas opções para lançar um SCO. Ele pode iniciar o conjunto de quadros SCO ina (como na foto acima) ou pode iniciar o SCO em uma nova janela. Alguns LMS sempre lançarão conteúdo de uma forma ou de outra. Normalmente, porém, se um curso contiver apenas um SCO (e, portanto, não exigir e elementos de navegação do LMS), o SCO será iniciado em uma janela pop-up. Por outro lado, se o curso contiver muitos SCOs, o LMS geralmente iniciará os SCOs em um conjunto de quadros cercado por elementos de navegação. Alguns LMS permitirão que os autores do conteúdo controlem com precisão como os SCOs são lançados, quais elementos de navegação estão disponíveis e até mesmo o tamanho das janelas SCO.

a API

toda a comunicação entre um SCO e o LMS acontece por meio de uma API ECMAScript (JavaScript). Esta é a única maneira de A comunicação ocorrer. Não existem outros canais de comunicação disponíveis. O conteúdo não pode se comunicar por meio de serviços da web, postagens de formulários, gravações de banco de dados ou qualquer outro mecanismo, apenas por meio da API JavaScript fornecida pelo LMS.

encontrar a API

o LMS é responsável por fornecer um objeto JavaScript nomeado especificamente em um local específico dentro do dom do navegador. Assim, o conteúdo, sempre pode localizar esta API usando um algoritmo comum.

em SCORM 1.1 e SCORM 1.2, O Objeto API é sempre chamado de “API”. No SCORM 2004, o objeto é denominado “API_1484_11”.

o objeto API deve estar localizado em uma janela que é pai do SCO ou pai da janela do abridor do SCO. Uma janela” pai ” é definida como toda a cadeia de janelas pai até a janela do navegador raiz. Portanto, a API pode estar no Pai do SCO, no Pai do pai do SCO, no Pai do pai do SCO, etc. Da mesma forma, a API pode estar na janela do abridor, no Pai do abridor, no Pai do pai do abridor, etc. Os diagramas abaixo da especificação SCORM 2004 3rd Edition ilustram os possíveis locais da API.

SCORM inclui algoritmos específicos que o conteúdo pode usar para encontrar a API SCORM.

usando a API

uma vez que um SCO encontrou a API SCORM, ele pode usar a API para se comunicar com o LMS. Observe que apenas a SCO pode iniciar a comunicação. O LMS é uma entidade passiva que simplesmente responde às chamadas de API feitas pelo conteúdo. O LMS não pode iniciar nenhuma comunicação, ele simplesmente inicia o conteúdo e responde às solicitações.

A API SCORM contém oito métodos com as seguintes assinaturas:

SCORM 2004

Initialize( "" ) : bool Rescindir( "" ) : bool GetValue( elemento : CMIElement ) : string SetValue( elemento : Se você estiver procurando por um código de erro, use o código de erro para criar um código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de código de erro de erro de código de erro. 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
 os nomes dos métodos variam ligeiramente entre as versões SCORM, mas conceitualmente os métodos são idênticos.
 notas:

o tipo bool é um booleano SCORM, que na verdade é uma string com o valor “true” ou “false”.
o parâmetro “” é exigido por todos os métodos SCORM que não aceitam nenhum outro argumento. SCOs são simplesmente necessários para passar um parâmetro de string vazio para esses métodos.
o tipo de dados CMIElement é uma string correspondente aos elementos do modelo de dados SCORM descritos abaixo.
o tipo de dados CMIErrorCode é um número de três dígitos, representado uma string, que corresponde a um dos códigos de erro de tempo de execução SCORM.


inicializar / LMSInitialize 
 o método Initialize indica ao LMS que o conteúdo gostaria de iniciar uma sessão de comunicação. Todos os SCOs devem chamar Initialize antes de realizar qualquer outra comunicação. O LMS retorna um booleano indicando o sucesso ou falha da inicialização. Normalmente, os LMS não precisam fazer muita inicialização e sempre retornarão “true”.
 encerrar / LMSFinish 
 o método encerrar indica ao LMS que o conteúdo é feito comunicando. Todos os SCOs devem ligar para encerrar. Chamar encerrar não indica necessariamente que o Usuário é feito com o SCO, tecnicamente indica apenas que o SCO é feito comunicando. Na prática, no entanto, o conteúdo será mais compatível e utilizável se terminar for chamado apenas quando o conteúdo puder ser retirado do Usuário. Como terminar é necessário sempre ser chamado, não importa como o aluno saia da SCO, é aconselhável fazer uma chamada para terminar no evento onunload de uma SCO. O valor booleano retornado pelo LMS geralmente indica se os dados SCO foram ou não persistidos com sucesso no servidor.
 GetValue / LMSGetValue 
 o método GetValue permite que um SCO Recupere dados do LMS. Os dados que são sempre recuperados são um dos elementos definidos do modelo de dados SCORM. Cada um desses elementos do modelo de dados contém um dado diferente. Alguns dos elementos do modelo de dados têm valores inicializados pelo LMS que falam das circunstâncias em que o SCO está sendo lançado. Outros valores são inicializados pelo SCO por meio de chamadas para SetValue. Se a chamada para GetValue retornar uma string vazia, é possível que um erro tenha ocorrido e o método GetLastError deva ser invocado para verificar se há problemas.
 SetValue / LMSSetValue 
 o método SetValue permite que o SCO persista dados no LMS. Os dados são sempre armazenados em um dos elementos do modelo de dados SCORM definidos. Alguns elementos do modelo de dados são limitados a ter valores de um vocabulário limitado (por exemplo, o estado pode ser “concluída” ou “passado”), outras são restritas a ser um tipo de dados específico (por exemplo, a pontuação deve ser sempre um número), enquanto outras permitem que a SCO para persistência de dados de texto livre sem significado semântico. A chamada SetValue retorna um booleano indicando o sucesso ou falha da chamada.
 Commit / LMSCommit 
 o método Commit sinaliza para o LMS que um mandril significativo de dados foi salvo e que deve garantir que os dados sejam persistidos corretamente. Não há requisitos para como o LMS deve implementar o método de Commit, é simplesmente um sinal informativo. Alguns LMS farão uma ida e volta ao servidor para cada chamada se comprometer para garantir que todos os dados sejam persistidos. Embora intuitiva, essa estratégia de implementação pode levar a problemas de escalabilidade. Tome cuidado para não chamar Commit excessivamente para não sobrecarregar esses LMS.

 GetLastError / LMSGetLastError 
 o método GetLastError verifica se a última chamada da API SCORM causou um erro. Nesse caso, esse método retorna um número de erro que corresponde a um conjunto definido de possíveis erros. Alguns números de erro representam situações perfeitamente legítimas (como o elemento 403-Data Model não inicializado). Os autores da SCO devem ter o cuidado de sinalizar apenas erros legitimamente inesperados para o usuário. A lista completa de códigos de erro pode ser encontrada no gráfico de referência de tempo de execução do SCORM.
 GetErrorString / LMSGetErrorString 
 dado um número de erro específico (geralmente o número de erro retornado de GetLastError), o método GetErrorString retornará uma descrição textual do que o código de erro significa. Por exemplo, no SCORM 2004, passar o número de erro ” 406 “retornará uma string dizendo” incompatibilidade do tipo de elemento do modelo de dados ” para indicar que o resultado da chamada anterior (provavelmente um SetValue) falhou porque os dados armazenados não estavam no formato correto.
 GetDiagnostic / LMSGetDiagnostic 
 o método GetDiagnostic permite que o LMS retorne informações detalhadas sobre o erro anterior que pode ser útil no diagnóstico do problema. Por exemplo, as informações de diagnóstico para o erro” 406 “mencionado acima podem ser” o valor ‘zero’ não é permitido para o cmi.pontuacao.materia. O cmi.pontuacao.o elemento bruto deve conter um número válido representado apenas como dígitos”.
 o modelo de dados de tempo de execução SCORM 
 o modelo de dados de tempo de execução contém muitos elementos, cada um com seu próprio significado. Os elementos podem ser lidos e escritos usando a API. O gráfico de referência de tempo de execução do SCORM contém uma lista de cada elemento do modelo de dados, juntamente com seu tipo de dados e uma breve descrição de seu significado e uso.
cada SCO tem seu próprio conjunto de dados de tempo de execução. Cada um desses elementos do modelo de dados tem um valor separado para cada SCO em um curso, os elementos do modelo de dados não são compartilhados entre scos. Além disso, cada “tentativa” em uma SCO tem seu próprio conjunto de dados em tempo de execução. Quando o aluno inicia uma nova tentativa em um SCO, os valores do modelo de dados serão redefinidos para o início da nova tentativa.
os elementos do modelo de dados são ligeiramente diferentes nas versões SCORM, mas na maior parte existe um elemento correspondente em cada versão dos padrões. SCORM 1.1 e SCORM 1.2 têm modelos de dados idênticos. SCORM 2004 tem um conjunto de modelos de dados diferente. Existem pequenas diferenças sutis entre as edições do SCORM 2004 também. O gráfico fornece uma referência abrangente para cada versão/edição. As mudanças mais significativas no SCORM 2004 incluem:


renomeação menor, principalmente removendo o “núcleo” dos nomes dos elementos do modelo de dados.
 separação de status. Em SCORM 1.2 um único elemento, cmi.Nucleo.lesson_status representa o status da SCO. No SCORM 2004, o status é dividido em dois elementos separados, cmi.completion_status (concluído vs incompleto) e cmi.success_status (passado vs falhou).
interações (resultados da pergunta) São leitura/gravação em vez de apenas gravação. As interações também contêm um campo de descrição que faltava no SCORM 1.2.
adição de adl.navegacao.* os elementos do modelo de dados que permitem ao SCO iniciar solicitações de sequenciamento 

usando o tempo de execução
usando o tempo de execução do SCORM são amplamente opcionais de uma perspectiva de conformidade estrita, no entanto, a norma do setor é usar pelo menos um subconjunto dos elementos do modelo de dados em tempo de execução disponíveis para você.
 no mais simples, se o seu curso não contém nada além de ativos lançáveis, nenhuma chamada em tempo de execução é necessária. O LMS simplesmente lança cada ativo conforme solicitado pelo Usuário e o ativo é considerado concluído imediatamente após o lançamento.
 para uma interação mais rica, a primeira coisa que precisamos fazer é habilitar a comunicação em tempo de execução. Isso envolverá encontrar a API e, em seguida, garantir que inicialize e termine sejam chamados. Na maioria dos casos, inicializar deve ser chamado imediatamente após o lançamento do SCO. Uma vez inicializar foi chamado, é essencial que terminar ser chamado em todos os cenários de saída.
 uma vez que a comunicação foi inicializada, é hora de começar a realmente comunicar dados. Os seguintes elementos do modelo de dados de” 1ª camada ” são os mais importantes e mais comumente usados (SCORM 1.2 equivalente entre parênteses):

 cmi.completion_status & cmi.success_status (cmi.Nucleo.lesson_status) – esses elementos do modelo de dados são os mais fundamentais e importantes. Eles indicam quando um usuário terminou um curso e se ele passou ou falhou. Esta informação fundamental é essencial para a maioria dos LMS.
 cmi.pontuacao.escalado (cmi.Nucleo.pontuacao.raw) – indica a pontuação que o aluno ganhou em qualquer avaliação dentro de uma SCO. Relatar uma pontuação mínima e máxima em conjunto com uma pontuação bruta também é uma boa forma.
 cmi.session_time (cmi.Nucleo.session_time) – relata a quantidade de tempo que o aluno passou na SCO.
 cmi.localização (cmi.Nucleo.lesson_location) – fornece um campo de texto livre para o SCO para gravar um marcador. Se o SCO for maior do que apenas algumas páginas HTML, ele deve considerar a implementação de um recurso de bookmarking para permitir que o aluno retome uma tentativa pausada.
 cmi.saída (cmi.Nucleo.exit) – este valor indica como o aluno está saindo do SCO. Definindo cmi.sair para” suspender ” garantirá que a tentativa atual seja preservada e que os dados em tempo de execução não sejam redefinidos na próxima vez que o SCO for iniciado. Definindo cmi.sair para “” indicará que o LMS deve iniciar uma nova tentativa com um novo conjunto de dados em tempo de execução no próximo lançamento do SCO.


 a norma da indústria espera que todos os elementos dos modelos de dados da 1ª camada sejam usados corretamente em uma SCO. Uma vez que essa funcionalidade tenha sido ativada, os próximos elementos de modelo de dados mais comuns, ou 2ª camada, incluem:

 interações-Use os elementos do modelo de dados de interações para relatar os resultados de cada resposta de pergunta. Uma interação não precisa ser uma resposta de teste tradicional. Por exemplo, uma SCO pode documentar as escolhas do aluno à medida que ele progride através de uma simulação. Se possível, use todos os elementos de interações para fornecer a imagem mais abrangente das respostas do aluno. No mínimo, use “id”, “tipo”, “resultado” e “descrição” para permitir que os LMS forneçam relatórios básicos.
 objetivos-em SCOs grandes, considere relatar o domínio do aluno de objetivos de aprendizagem específicos usando os elementos do modelo de dados de objetivos. Os objetivos permitem um relato mais granular do progresso do aluno e o domínio do material de treinamento.
 cmi.progress_measure-Use o elemento progress_measure no SCORM 2004 para relatar o progresso do Usuário para a conclusão de um SCO. O progress_measure é como uma medida “por cento completa” que permitiria ao LMS fornecer uma barra de progresso da conclusão geral de um curso.

entrada, modo e crédito 
o cmi.entrada (cmi.Nucleo.entrada), cmi.modo (cmi.Nucleo.lesson_mode) e cmi.crédito (cmi.Nucleo.crédito) Os elementos do modelo de dados fornecem à SCO algum contexto que ela pode usar para fornecer ao aluno a experiência ideal.

 cmi.a entrada indica se o usuário está iniciando o SCO pela primeira vez ou se está retomando uma tentativa anterior. Se estiver usando bookmarking, o SCO pode usar esse valor para solicitar que o usuário Comece do início ou do ponto em que a tentativa anterior terminou.
 cmi.o modo indica se o aluno está iniciando este SCO: normalmente-em uma sessão de treinamento” ao vivo”; no modo de navegação – o usuário está navegando em um catálogo de treinamento e deseja” visualizar ” este curso; ou, no modo de revisão – o usuário já completou o SCO e está voltando para revisar o material. No modo de navegação, o autor da SCO deve considerar alterar o comportamento da SCO para fornecer navegação de forma mais livre, fornecer uma visão geral ou mapa do curso e possivelmente ocultar avaliações. No modo de revisão, o autor da SCO deve considerar de forma semelhante permitir uma liberdade de navegação completa e mais enxuta. No modo de revisão, o aluno também pode navegar livremente em qualquer teste e navegar em uma lista de respostas corretas. Quando iniciado no modo de revisão, um SCO deve ter cuidado para não alterar o status do aluno ou redefinir a pontuação.
 cmi.o crédito indica se esta SCO está ou não sendo uma tentativa de crédito, ou se “conta”ou não. Semelhante ao modo de navegação, se um SCO for iniciado sem crédito, o comportamento provavelmente deve ser alterado.