Vamos conhecer o segundo dos três livros do padrão SCORM, o Livro RTE – Run-Time Enviromment. Tido como um dos preferidos pelos desenvolvedores.

Define a forma como o LMS disponibiliza os SCOs e como se comunicam com o LMS, ou seja, determina um Modelo de Dados para comunicação entre SCOs e o navegador/browser, define também o protocolo utilizado, permitindo que os SCOs sejam visualizados em diferentes LMSs, uma das principais vantagens do padrão.

Temos três elementos no Livro RTE: o Mecanismo Launch, responsável por lançar o SCO para o browser e efetuar todas as diligências para que o SCO possa comunicar com o LMS; a API (Application Program Interface), dispositivo que criará um canal de comunicação entre os SCOs e o LMS e o Data Model, que define a “metodologia/linguagem” utilizada pelo SCO e pelo LMS para comunicação, conforme imagem abaixo:

RTE – Launch, mecanismo comum a todo LMS, responsável pelo envio dos recursos de ensino para o navegador. Obtêm um comportamento consistente em diferentes LMSs no ato da entrega dos recursos independentemente da forma como os LMSs estejam implementados.

O LMS é responsável por fornecer a estrutura que irá suportar a comunicação entre o SCO e o LMS: a API Adapter, e também por gerir a sequenciação e a navegação entre diferentes recursos de ensino a partir da estrutura definida no Livro CAM, já citado no artigo anterior.

O LMS localiza o SCO através do URL descrito no Content Package e envia para o navegador, obrigatoriamente pelo protocolo HTTP. Podemos lançar um SCO por vez e apenas um pode estar ativo.

Antes de enviar o SCO para o navegador, o LMS deve enviar uma janela com a API, que deve estar em uma janela superior à janela para onde o SCO vai ser lançado e assim que encontrar a API, estabelecerá a comunicação com LMS.

API – Application Program Interface – pretende facilitar a interoperabilidade e reutilização dos conteúdos de ensino, ou seja, um conjunto pré-definido de funções que o SCO tem à sua disposição, necessários para comunicação.

API Adapter consiste no software que implementa as funções da API, permite que cada LMS crie seu próprio API Adapter. Toda comunicação parte do SCO para o LMS e nunca o contrário. Assim que o LMS recebe o SCO invocando o mecanismo “Launch“, cabe ao SCO localizar o API Adapter e iniciar a comunicação. A API Adapter possui oito funções em três categorias:

Estado de Execução: LMSInitialize (): indica ao LMS que o SCO pretende se comunicar e LMSFinish(): encerra comunicação.

Controle de Erros: LMSGetLastError: retorna um código com status das funções da API; LMSGetErrorString(errornumber): descrição textual do erro e LMSGetDiagnostic(parameter): permite acessar as descrições específicas de cada LMS para os erros e, alguns exemplos:

Transferência de Dados: LMSGetValue(element): solicitar dados ao LMS, descritos no Data Model; LMSSetValue(element, value): enviar informação para o LMS, em element indicamos o elemento do Data Model que deve guardar o conteúdo do value e LMSCommit(): garante ao SCO que a informação enviada ao LMS, via LMSSetValue() persista, o que pode garantir a conformidade do padrão.

Todas as interações entre SCOs e o API Adapter são realizados através de JavaScript, independente do curso ser desenvolvido em Flash ou HMTL, programadores JavaScript, já pensaram em trabalhar com e-learning?

Enfim, o Data Model permite diferentes LMSs guardarem e processarem informações dos SCOs. Existem três palavras que permitem obter informações sobre o modelo de dados: _version, para versão; _children, para elementos contidos e _count, para número de elementos. Temos o cmi.core, com as informações mais importantes do aluno; o cmi.objetives, guarda as informações sobre o desempenho dos alunos; o cmi.interactions, onde são guardados os registros das interações; o cmi.student_data, informação para suportar a customização baseado no desempenho do aluno e o cmi.student_preference, com as opções do aluno que serão apropriadas em subseqüentes SCOs.

Falta um livro, um abraço e até o próximo.