licenciatura em engenharia electrotécnica e de computadoresee95135/relatorio_final.pdf · aluno...

Licenciatura em Engenharia Electrotécnica e de Computadores

Projecto/Seminário/Trabalho Final de Curso 2002/2003

Análise de requisitos do sistema de e-Learning de um centro de formação

profissional e desenvolvimento de protótipo de demonstração.

Estágio realizado no Centro de Formação Profissional da Indústria de Calçado de S. João

da Madeira entre 5 de Março e 23 de Julho de 2003

Carlos Alberto de Oliveira Costa

2

“If you tell me, I will listen

If you show me, I will see

If you let me experience, I will learn”

Lao Tze

15 de Julho de 2003

3

Índice

1. Motivação………………………………………………………………………………………… 5

2. Objectivos………………………………………………………………………………………... 6

3. Enquadramento………………………………………………………………………………… 7

4. Norma SCORM………………………………………………………………………………….. 8

4.1. Introdução………………………………………………………………………………….. 8

4.2. Content Aggregation Model……………………………………………………….......... 9

4.2.1. Content Model………………………………………………………………………... 9 4.2.2. Meta-data……………………………………………………………………………... 11 4.2.3. Content Packaging…………………………………………………………………... 11

4.3. Run-Time Environment…………………………………………………………………... 14

4.3.1. Launch………………………………………………………………………………… 15 4.3.2. API…………………………………………………………………………………….. 17

4.3.2.1. Descrição………………………………………………………………… …… 17 4.3.2.2. Interacções dos SCOs e do LMS com o API Adapter…………………….. 20

4.3.3. Data Model…………………………………………………………………………… 21 4.3.3.1. Introdução……………………………………………………………………… 21 4.3.3.2. Regras gerais do Modelo de Dados………………………………………… 21 4.3.3.3. Elementos do Modelo de Dados…………………………………………….. 22

5. Protótipo de LMS………………………………………………………………………………. 27

5.1. Introdução………………………………………………………………………………….. 27

5.2. Especificações…………………………………………………………………………….. 27

5.3. Concepção…………………………………………………………………………………. 28

5.3.1. Introdução……………………………………………………………………………. 28 5.3.2. Servidor de páginas Web…………………………………………………………… 28 5.3.3. Módulo para atender os pedidos do SCO………………………………………… 29 5.3.4. API Adapter…………………………………………………………………………... 31 5.3.5. Base de Dados………………………………………………………………………. 31 5.3.6. Interacção entre os elementos…………………………………………………….. 32

5.4. Implementação…………………………………………………………………………….. 35

5.4.1. Introdução……………………………………………………………………………. 35 5.4.2. Implementação da Base de Dados………………………………………………... 36

4

5.4.3. Implementação do API Adapter……………………………………………………. 39 5.4.4. Implementação do Web Service…………………………………………………… 49 5.4.5. Implementação da Web Application………………………………………………. 53

6. Conclusões……………………………………………………………………………………… 63

7. Referências……………………………………………………………………………………… 64

7.1. Referências Bibliográficas………………………………………………………………. 64

7.2. Referências URL…………………………………………………………………………... 64

5

1. Motivação “Actualmente, em plena era da Sociedade da Informação e do Conhecimento, não é razoável para qualquer Instituição de Ensino ignorar o potencial das novas tecnologias de informação na Educação. Salienta-se contudo que, embora se acredite na importância estratégica da utilização de tecnologias de informação e comunicação avançadas para apoio à educação, não se pretende, nem se acredita ser possível, ter um processo educativo inteiramente baseado na Internet. A educação é sobretudo um processo humanizado, em que a ênfase se coloca na preparação do aluno para a inserção social e profissional, o qual passa pela socialização do aluno e pela aprendizagem construtiva baseada tanto em conhecimento explícito como em conhecimento tácito, exigindo por isso algum contacto pessoal directo do aluno com o professor e com os colegas. Para qualquer Instituição de Ensino, e-Learning significa expandir o âmbito da sua oferta de ensino para lá de barreiras físicas e temporais. A nível internacional são já vários milhares as Instituições de Ensino que souberam entender as muitas possibilidades do ensino à distância distribuído pela Internet. Em Portugal, o sector começa agora a aproximar-se das possibilidades do e-Learning na nova realidade educativa sem fronteiras. As Instituições que mais cedo souberem entender a potencial vantagem competitiva que significa este novo canal de ensino, serão as primeiras a retirar proveitos daquilo que é já considerado por muitos como a Segunda Vaga da Internet: a utilização da rede global para a disseminação do conhecimento através do e-Learning.”

Compilação de artigos sobre

e-Learning em jornais on-line

Atento a esta necessidade, o Centro de Formação Profissional da Indústria de Calçado (CFPIC) de S. João da Madeira pretende complementar a sua oferta de ensino colocando em funcionamento o seu próprio sistema de e-Learning. Coloca-se, no entanto, a questão: implementar ou comprar um sistema de e-Learning? A realização deste estágio pretende ajudar a responder a esta questão através do estudo da norma SCORM TM (Sharable Content Object Reference Model) descrita mais adiante e de sistemas compatíveis com esta norma.

6

2. Objectivos Na realização deste estágio pretende-se estudar a norma SCORM TM e desenvolver um protótipo de um servidor de e-Learning que respeite a norma, construído sobre a tecnologia Microsoft .NET. A implementação do protótipo tem como objectivos estudar (e experimentar) o modo de funcionamento de um servidor de e-Learning compatível com a norma SCORM TM assim como adquirir conhecimentos no desenvolvimento de aplicações no ambiente .NET.

7

3. Enquadramento

e-Learning, o que é? Por e-Learning entende-se a utilização das Tecnologias de Informação e Comunicação (TIC) como meio de transmitir conteúdos e promover a aprendizagem. Os cursos e programas de formação servidos por uma plataforma de e-Learning podem fazer uso de qualquer formato electrónico para expor os seus conteúdos e usar diversos meios para os divulgar: CD-ROM, DVD, Internet, Intranet, etc… Distinguem-se habitualmente duas modalidades de formação:

• A modalidade síncrona – ou seja, uma componente de formação em tempo real, que promove a interacção através de voz, imagem e dados, entre formandos e formador numa "sala de aula virtual", independente do local onde se encontrem.

• A modalidade assíncrona – ou seja, sem a possibilidade de interacção em tempo real e

que proporciona o acesso aos conteúdos - nos seus múltiplos suportes - de forma individualizada. Nestes casos, se existe interacção com os formandos ou formadores, ela é realizada em diferido através de e-mails ou fóruns de discussão.

Os sistemas de e-Learning oferecem numerosas vantagens: Eliminam as barreiras da distância e do acesso aos professores/formadores Conferem a cada indivíduo ou organização o privilégio de gerir de forma personalizada os seus tempos de formação Optimizam o investimento na formação através da redução de custos associados à deslocação e à ausência do local de trabalho dos seus colaboradores. Permitem a participação nas sessões de formação através de horários mais alargados e ajustados às necessidades de cada utilizador (24 horas por dia).

8

4. Norma SCORM1

4.1. Introdução

A norma SCORM TM (Sharable Content Object Reference Model) pode-se definir de uma forma simples como sendo um modelo que descreve um conjunto de especificações técnicas e de referências para apresentação de conteúdos de ensino via Web. A norma foi criada pela ADL (Advanced Distributed Learning – www.adlnet.org) com o intuito de uniformizar as diversas implementações de sistemas de e-Learning que começaram a surgir baseadas em diferentes tecnologias. A norma SCORM aplica os desenvolvimentos actuais da tecnologia na construção de um modelo com o objectivo de produzir recomendações para a implementação consistente de sistemas de e-Learning. Num sistema de e-Learning existem tipicamente os seguintes módulos e funcionalidades:

Ferramentas de criação de recursos de ensino Uma base de dados (repositório) para guardar os recursos de ensino Um sistema para entregar os recursos de ensino aos formandos Uma forma de acompanhar a progressão do aluno e de avaliar o seu desempenho e conhecimentos sobre o curso.

A norma SCORM distingue de forma muito clara as funções dos recursos de ensino das funções dos sistemas de gestão. Os recursos de ensino têm a designação de Sharable Content Objects (SCO) e o sistema de gestão é designado por Learning Management System (LMS). Quando os formadores criam um curso trabalham apenas com os conteúdos de ensino (SCO). Posteriormente o LMS irá determinar a forma e a ordem pela qual o formando irá ver os SCOs criados. Isto significa que os formadores têm que incluir nos SCOs instruções para indicar ao LMSs quais os conteúdos a usar, a forma como os conteúdos estão organizados, a ordem pela qual devem ser apresentados e qual a informação que desejam guardar relativamente a cada sessão. 1 A descrição da norma SCORM aqui apresentada refere-se à versão 1.2 em vigor no início da realização deste estágio. Encontra-se, no entanto, já em vigor a versão 1.3, lançada no final de Maio deste ano.

9

A norma SCORM divide-se em duas partes que serão descritas nas secções 4.2 e 4.3: Content Aggregation Model – Define a forma como os conteúdos de ensino devem ser criados e agrupados.

Run-Time Environment – Define a forma como o LMS disponibiliza os SCOs e como é que estes comunicam com o LMS, isto é, especifica um Modelo de Dados.

4.2. Content Aggregation Model

O Content Aggregation Model permite aos formadores agrupar os conteúdos que criarem seguindo um modelo que os LMS são capazes de interpretar. O Content Aggregation Model é constituído pelos seguintes componentes: Content Model – Define os elementos onde podem ser guardados os conteúdos de ensino. Meta-data – Descreve o conteúdo dos recursos de ensino. Permite ao LMS organizar de forma conveniente os SCO disponíveis e torna mais rápida e eficiente a pesquisa dos SCO guardados. Content Packaging – Define como devem ser agrupados os conteúdos de ensino para permitir que sejam instalados em ambientes diferentes.

4.2.1. Content Model

O Content Model define três componentes: Assets, Sharable Content Objects (SCO) e Content Aggregation. Assets

Os Assets constituem a forma mais básica de conteúdo de ensino. Podem fazer parte de um Asset: texto, imagens, som, páginas HTML e qualquer formato que possa ser entregue pela Web.

10

PáginaHTML

ObjectoFLASH

FicheiroWAV

ImagemJPEG

DocumentoXML

ApresentaçãoPowerPoint

Figura 1 – Exemplo de Assets

Sharable Content Objects

O Sharable Content Object (SCO) representa um conjunto de um ou mais Assets e inclui (obrigatoriamente) um mecanismo para comunicar com o LMS. Embora o LMS possa apresentar Assets, estes devem ser sempre inseridos em SCOs para que o LMS possa acompanhar a evolução dos alunos através dos dados passados pelo SCO. As comunicações entre os SCOs e o LMS serão analisadas na secção 4.3 Run-Time Environment. Os SCOs devem ser pequenas unidades de ensino para potenciar a sua reutilização em diferentes contextos de ensino, ou seja, para permitir que o mesmo SCO possa ser utilizado em vários cursos. Quanto mais pequeno for o SCO mais facilmente poderá ser reintegrado noutro contexto. A reutilização de conteúdos de ensino é um dos pontos-chave da filosofia da norma SCORM. Com a SCORM pretende-se não só a possibilidade de transferir cursos entre LMS mas também facilitar a construção desses mesmos cursos através da utilização de unidades já existentes.

PáginaHTML

ObjectoFLASH

ImagemJPEG

DocumentoXML



Figura 2 – Exemplo de SCO

11

Content Aggregation Model

O Content Aggregation é um mapa usado para reunir os recursos de ensino numa unidade de instrução coesa (por exemplo, um curso, um capítulo, um módulo, etc…) e lhes dar uma estrutura bem definida. É esta estrutura que define a sequência pela qual os conteúdos de ensino serão apresentados aos alunos. A sequência e a navegação entre os conteúdos de ensino são definidas na estrutura através da atribuição de pré-requisitos a cada conteúdo. Cabe ao LMS interpretar a sequência descrita e controlar a navegação da forma pretendida. Para preservar a reutilização de conteúdos, a navegação entre SCO é sempre feita através do LMS. Em particular, um SCO não pode conter links para outros SCOs, porque nesse caso, se o SCO for reutilizado noutro curso, os SCOs para os quais contém links poderão não existir no novo curso. Os únicos links que o SCO pode ter são a nível interno, isto é, para páginas ou recursos existentes dentro do próprio SCO.

4.2.2. Meta-data A meta-data consiste em informação acerca da informação. Concretamente no modelo SCORM, consiste em informação que descreve o conteúdo dos diversos componentes: Assets, SCO e Content Aggregation. A função da meta-data é disponibilizar um meio coerente de descrever o conteúdo de cada componente de modo a que este possa ser arquivado e pesquisado de uma forma rápida e eficiente. A aplicação de meta-data no modelo SCORM respeita o standard IEEE LTSC Learning Object Meta-Data (LOM)1 e utiliza a IMS Learning Resource Meta-data XML Binding Specification2 para guardar a informação em formato XML. 4.2.3. Content Packaging O Content Packaging consiste num conjunto de regras e normas para agregar conteúdos de ensino em blocos (packages), com o objectivo de permitir a transferência desses mesmos blocos entre sistemas diferentes: entre LMSs, entre as ferramentas de criação de conteúdos e o LMS, etc… 1 IEEE Information Technology – Learning Technology – Learning Objects Meta-data LOM: Working Draft v6.1 (2001-05-03) Resource Meta-data Specification Version 1.2. Disponível em: http://ltsc.ieee.org/ 2 IMS Learning Resource Meta-data Specification Version 1.2. Disponível em: http://www.imsglobal.org/

12

Os packages dividem-se em duas partes: Um documento especial XML que descreve os conteúdos e a organização do package. Os ficheiros físicos respeitantes aos recursos de ensino.

Os packages criados são geralmente guardados num ficheiro PIF (Package Interchange File) com o intuito de facilitar a sua distribuição pela Web. O PIF pode ter diversos formatos sendo os mais utilizados: zip, jar, tar e cab. O documento XML constitui um manifesto dos diversos componentes do package, por isso mesmo, tem o nome imsmanifest.xml. Do manifesto fazem parte os seguintes elementos: Meta-data sobre o bloco. Uma secção (opcional) com o nome Organizations que define a estrutura e o comportamento dos conteúdos de ensino. Uma lista de apontadores para os recursos guardados no bloco (Resources).

A figura seguinte ilustra a estrutura de um PIF:

Meta-dataOrganizations

Resources

Manifesto

Ficheiros

Manifesto(imsmanifest.xml)

PIF - PackageInterchange File

Ficheiros dos recursos de ensino: vídeos, imagem, texto, etc…

Figura 3 – Exemplo de ficheiro PIF

A secção Organizations permite organizar e estruturar os conteúdos de ensino como a figura seguinte ilustra:

13

Resource

Organization

Item

Item

Item

Item

Item

Item

Item

Resource

Resource

Resource

SCO

Asset

SCO

Asset

Figura 4 – Diagrama da secção Organizations

Para concluir a secção apresenta-se na figura seguinte um excerto de um Manifesto:

<manifest>

<organizations><organization>

<title><item>…

</item></organization>

</organizations><resources>

<resource href=“index.html”adlcp:scormtype=“sco”identifier=“R_01”>

<metadata><schema>ADL SCORM</schema><schemaversion>1.2</schemaversion><adlcp:location>R_01.xml</adlcp:location>

</metadata><file href=“index.html” /><file href=“image1.jpg”>

<metadata><schema>ADL SCORM</schema><schemaversion>1.2</schemaversion><adlcp:location>image1.xml</adlcp:location>

</metadata></file>

</resource>…

</resources></manifest>

Estrutura dosconteúdos de ensino

SCO

Asset

Figura 5 – Exemplo do ficheiro imsmanifest.xml

14

4.3. Run-Time Environment A especificação do Run-Time Environment tem como objectivo permitir que os conteúdos de ensino possam ser visualizados em diferentes LMS e tenham em todos o mesmo comportamento. Para que isto seja possível, esta especificação determina a forma como os SCOs são enviados para o browser e define o protocolo que os SCOs e o LMS irão usar para comunicar entre si. O Run-Time Environment é constituído por três elementos que serão analisados nas secções seguintes: Mecanismo Launch – responsável por lançar o SCO para o browser e efectuar todas as diligências para que o SCO possa comunicar com o LMS. API (Application Program Interface) – dispositivo que irá criar um canal de comunicação entre os SCOs e o LMS. Data Model – define a “linguagem” usada pelos SCOs e pelo LMS para comunicarem.

A figura 6 mostra o papel destes três elementos e o modo como actuam numa plataforma de e-Learning:

Launch(Inicia SCO)

Learning Management System (LMS)

ServidorLMS

Browser

Sharable Component Object

JavaScript

Servidor

Cliente

APIAdapter

DataModel

Figura 6 – Run-Time Environment de uma plataforma de e-Learning

15

4.3.1. Launch

O Launch consiste num mecanismo, comum a todos os LMSs, responsável pelo envio dos recursos de ensino para o browser do utilizador. A ideia de criar de um mecanismo comum para lançar os recursos de ensino tem como objectivo obter um comportamento consistente em diferentes LMSs no acto de entrega dos recursos independentemente da forma como os LMSs estejam implementados. Os componentes do Content Model que podem ser lançados pelo LMS são os Assets e os SCOs. Consoante se trate de um Asset ou de um SCO, o LMS desencadeia acções diferentes. Por exemplo, no caso de ser lançado um SCO, o LMS tem a responsabilidade de fornecer a estrutura que irá suportar a comunicação entre o SCO e o LMS, o API Adapter, descrito na secção seguinte. Como foi já abordado, cabe ao LMS gerir a sequenciação e navegação entre diferentes recursos de ensino a partir da estrutura definida no Content Aggregation Model. O LMS baseia-se na interpretação de pré-requisitos presentes nos conteúdos de ensino para criar a sequência pela qual os conteúdos serão enviados para o utilizador. É de referir, no entanto, que a presença destes pré-requisitos não é obrigatória, assim como, nem todos os LMS poderão ter a capacidade para os interpretar. Na presente versão, a norma SCORM (1.2) não possui ainda um padrão para a criação de sequências e regras de navegação entre SCOs bem como da forma de apresentação das ferramentas de navegação. Assim, a progressão através dos conteúdos de ensino, num determinado curso ou contexto de ensino, pode ser feita de diferentes maneiras consoante as capacidades do LMS e do modo como os recursos de ensino estejam construídos: Navegação sequencial – o formando navega progressivamente pelos recursos de ensino. Navegação escolhida pelo formando – o formando escolhe a ordem pela qual quer aceder aos recursos de ensino, seleccionando-os através de um menu com uma tabela de conteúdos. Navegação adaptada – o LMS determina quais os conteúdos de ensino e a ordem pela qual são entregues consoante o desempenho do formando.

Depois de seleccionado o recurso a ser lançado, o LMS localiza-o através do URL descrito no Content Package e envia-o para o browser. O envio do recurso para o browser é feito obrigatoriamente pelo protocolo HTTP.

16

Para concluir esta secção descreve-se resumidamente o comportamento do LMS no “Launch” de Assets e SCOs: Assets

No lançamento de Assets o único requisito a cumprir é que o Asset seja enviado para o browser através de HTTP. Como o Asset não irá comunicar com o LMS não é necessário executar mais nenhuma operação SCOs Os SCOs são o meio privilegiado para divulgar os conteúdos de ensino pelo facto de serem dotados de capacidade de comunicação com o LMS. A capacidade de comunicação obriga contudo a alguns cuidados especiais para garantir um funcionamento correcto do LMS e um acompanhamento eficiente da progressão do formando. Assim, o LMS só pode lançar um SCO de cada vez e em cada momento apenas um SCO pode estar activo. Por outro lado, um SCO só pode ser lançado pelo LMS. Um SCO não pode lançar outro SCO nem pode conter links que apontem para recursos externos ao próprio SCO. Antes de enviar o SCO para o browser, o LMS deve enviar uma janela principal com o API Adapter (Application Program Interface Adapter). O API Adapter é o responsável pelo estabelecimento da comunicação entre os SCOs e o LMS, como se pode observar na figura 6. Depois de ser criada esta janela principal contendo o API Adapter, o SCO pode ser lançado para uma janela aberta pela janela principal ou para uma frame da janela principal, ou seja, o API Adapter deve estar colocado numa janela hierarquicamente superior à janela para onde o SCO vai ser lançado de modo a que este o possa encontrar. O API Adapter é sempre fornecido pelo LMS e pode ter implementações diferentes de LMS para LMS, embora respeite o mesmo Modelo de Dados. Depois de lançado para o browser, o SCO irá percorrer as janelas hierarquicamente superiores para encontrar o API fornecido pelo LMS. Assim que encontrar o API o SCO poderá iniciar a comunicação com o LMS.

17

4.3.2. API

4.3.2.1. Descrição

A Application Program Interface (API) é, como foi já descrito, o meio através do qual os SCOs e o LMS comunicam. A utilização da API pretende facilitar a interoperabilidade e reutilização dos conteúdos de ensino. A API permite que os SCOs comuniquem com o LMS de uma forma standard, encapsulando os detalhes da comunicação do professor/formador que cria os conteúdos de ensino. De uma forma simples pode-se descrever uma API como sendo um conjunto predefinido de funções que o SCO tem à sua disposição. O API Adapter consiste no software que implementa as funções da API. O API Adapter usa a capacidade de encapsulamento, inerente às linguagens orientadas a objectos, para ocultar os detalhes da implementação, permitindo assim que cada sistema de LMS crie o seu próprio API Adapter da forma mais conveniente tendo apenas que disponibilizar uma interface pública pré-definida. Todas as comunicações entre SCOs e o LMS são iniciadas pelo SCO. O LMS não dispõe de nenhum meio para chamar funções dentro de um SCO. Assim, depois do LMS lançar o SCO para o browser invocando o mecanismo “Launch”, cabe ao SCO localizar o API Adapter e iniciar a comunicação com o LMS para pedir e guardar os dados que pretender. As funções disponibilizadas pelo API Adapter são oito, divididas em três categorias: Estado de Execução

o LMSInitialize(“”) o LMSFinish(“”)

Controle de erros

o LMSGetLastError() o LMSGetErrorString(errornumber) o LMSGetDiagnostic(parameter)

Transferência de Dados

o LMSGetValue(element) o LMSSetValue(element, value) o LMSCommit(“”)

Segue-se uma descrição resumida de cada uma das funções.

18

LMSInitialize(“”)

Esta função indica ao LMS que o SCO pretende comunicar. Permite ao LMS “preparar-se” realizando as operações necessárias para processar os pedidos do SCO. O SCO deve executar obrigatoriamente o LMSInitialize antes de invocar qualquer outra função da API. Na versão 1.2 o único argumento aceite é a string vazia “”. Na versão 1.3 podem ser passados outros argumentos de forma a fazer uma inicialização parametrizada do LMS. Retorna uma string com o valor “true” ou “false” consoante a invocação tenha sido ou não bem sucedida. LMSFinish(“”)

O SCO deve invocar esta função quando já não precisar de comunicar com o LMS para que o LMS possa libertar os recursos gastos para atender aos pedidos do SCO. À semelhança do LMSInitialize, na presente versão o único argumento aceite é a string vazia “” e retorna uma das strings “true” ou “false” de acordo com o sucesso da invocação. LMSGetValue(parameter)

Através desta função o SCO pode pedir dados ao LMS. O SCO especifica os dados que pretende através do parâmetro passado como argumento. Os dados pedidos e a sintaxe dos parâmetros que são passados estão descritos no Data Model analisado na secção 3.2.3.3. Todos os dados devolvidos pela função vêm no formato de strings. Exemplo de um pedido feito pelo SCO: var value = LMSGetValue("cmi.core.student_name");

O valor devolvido seria por exemplo: “João Santos” LMSSetValue(parameter, value)

Com esta função o SCO pode enviar informação para o LMS. Consoante a implementação do API Adapter a informação pode ser enviada directamente para o LMS ou guardada temporariamente numa memória cache e enviada mais tarde. No segundo argumento da função é colocada a informação que se pretende guardar e no primeiro, indica-se em que elemento do modelo de dados ela deve ser guardada. A função retorna “true” se não ocorrer nenhum erro ou “false” no caso contrário.

19

LMSCommit(“”)

Esta função existe para garantir ao SCO que a informação enviada ao LMS através de uma chamada a LMSSetValue() será persistida. Nas implementações do API Adapter que usam memória cache, quando recebem a chamada a esta função devem enviar para o LMS todos os dados que tenham em memória e que ainda não tenham sido persistidos na base de dados do LMS. Se o API Adapter estiver implementado de forma a persistir os dados no fim de cada chamada a LMSSetValue, a função LMSCommit() torna-se redundante, devendo, no entanto, existir sempre para garantir conformidade total com a norma SCORM. Nestes casos pode ser implementada como uma função oca, ou seja, não executa nenhuma operação e retorna sempre o valor “true”. O parâmetro passado na chamada à função é sempre a string nula “” e o valor de retorno será “true” ou “false” de acordo com o sucesso da chamada à função. LMSGetLastError()

Através da função LMSGetLastError o SCO pode saber se a chamada a alguma das funções da API descritas acima foi bem sucedida ou não e, neste caso, saber o que é que falhou. Sempre que é invocada a função retorna um código que representa o estado do erro gerado na última chamada à API. Todas as funções da API (com excepção das funções do grupo de Controle de Erros: LMSGetLastError, LMSGetErrorString e LMSGetDiagnostic) geram um código de erro quando são chamadas. Este código assume o valor 0 se não ocorrer nenhum erro, ou o valor correspondente ao erro ocorrido. A seguinte tabela mostra os códigos de erro mais comuns e o seu significado:

Tabela 1 – Códigos dos erros mais frequentes Tipo de erro Código Descrição

0 No error 100’s General errors 101 General exception 200’s Syntax errors 201 Invalid argument 202 Element cannot have children 203 Element not an array – cannot have count 300’s LMS errors 301 Not initialized 400’s Data model errors 401 Not implemented error 402 Invalid set value, element is a keyword 403 Element is read only 404 Element is write only 405 Incorrect Data Type

20

LMSGetErrorString(errornumber)

Esta função permite ao SCO obter uma descrição textual do erro ocorrido. Quando o SCO chama a função passa-lhe como argumento o código do erro para o qual pretende a descrição e a função devolve-lhe a string correspondente tal como está descrita na tabela 1. Exemplo: var error = LMSGetErrorString("403");

O valor devolvido à variável error seria: “Element is read only” LMSGetDiagnostic(parameter)

A função LMSGetDiagnostic permite aceder a descrições específicas de cada LMS para os erros ocorridos. Estas descrições serão à partida mais detalhadas que as fornecidas pela função GetErrorString porque são criadas dentro de cada LMS e permitem descrever o erro de forma mais pormenorizada e melhor integrada no contexto do LMS onde ocorreu o erro. 4.3.2.2. Interacções dos SCOs e do LMS com o API Adapter A figura 7 representa um diagrama de estados de um SCO visto pelo API Adapter:

Nãoinicializado

SCO lançadopelo LMS

Inicializado

Terminado

O SCO deve procurar o API Adapter e chamar LMSInitialize

LMSInitialize(“”) LMSFinish(“”)

Neste estado o SCO pode chamar as funções:•LMSGetValue•LMSSetValue•LMSGetLastError•LMSGetErrorString•LMSGetDiagnostic•LMSCommit•LMSFinish

Figura 7 – Diagrama de estados de um SCO visto pelo API Adapter

Como se observa na figura, depois de ser lançado, o SCO deve localizar o API Adapter previamente enviado para o browser pelo LMS. Para isso deve percorrer recursivamente as janelas-pai até o encontrar. Todas as interacções entre os SCOs e o API Adapter são realizadas através de ECMAScript (o standard de JavaScript). Apesar de o API Adapter poder ser implementado de diversas maneiras

21

(Applets em Java, Flash, Remote Scripting, etc…) ele deve estar acessível através de JavaScript como sendo um objecto do tipo DOM1 (Document Object Model) com o nome API. Um SCO deve chamar sempre pelo menos as funções LMSInitialize(“”) e LMSFinish(“”). 4.3.3. Data Model

4.3.3.1. Introdução O Data Model foi criado para permitir que diferentes LMSs possam guardar e processar um conjunto definido de informações provenientes de qualquer SCO assim como, por outro lado, proporcionar aos SCOs uma forma standard de aceder aos dados do LMS de que necessita. O Data Model consiste portanto, no estabelecimento de um protocolo que irá permitir a comunicação entre SCOs e LMS numa “linguagem” que ambos entendem. O Modelo de Dados utilizado pela SCORM 1.2 deriva do modelo de dados criado pela AICC (Aviation Industry CBT Committee) denominado AICC CMI Data Model2 em que CMI é o acrónimo para Computer Managed Instructions. Em versões futuras da norma poderão vir a ser incluídos outros modelos de dados, cuja estrutura será sempre semelhante à da AICC, prevendo-se portanto, uma transição fácil para os novos modelos quando estes forem adoptados. 4.3.3.2. Regras gerais do Modelo de Dados Antes de iniciar a descrição dos elementos que compõem o modelo de dados e da sua organização é oportuno fazer uma apresentação sumária das regras gerais a observar na utilização do modelo de dados: O primeiro símbolo em cada elemento identifica o modelo de dados que está a ser utilizado. Na presente versão, existe apenas o modelo CMI da AICC por isso, todos os elementos começam por “cmi”. Esta regra permite que a mesma API funcione correctamente com modelos de dados diferentes. Existem três palavras-chave reservadas que permitem obter informações acerca sobre o modelo de dados. Todas começam com o carácter “underscore” e são escritas em minúsculas:

1 Especificação do Document Object Model (DOM) World Wide Web Consortium (W3C) - www.w3c.org 2 AICC / CMI CMI001 Guidelines for Interoperability Version 3.4 Disponível em www.aicc.org

22

o _version – utilizada para determinar a versão do modelo de dados suportado pelo LMS

o _children – utilizada para determinar os elementos contidos por um nó o _count – utilizada para determinar o número de elementos contidos numa lista

Todas as listas começam em 0 e os elementos devem ser colocados nas listas de forma sequencial (sem saltos). O modelo de dados é implementado individualmente para cada SCO, isto é, cada SCO dispõe de campos específicos para guardar os seus dados e não pode aceder a dados guardados por outro SCO.

4.3.3.3. Elementos do Modelo de Dados Uma vez que a lista de elementos que compõem o modelo de dados é bastante extensa e a sua compreensão é relativamente fácil, far-se-á apenas a apresentação dos elementos mais relevantes do modelo de dados acompanhada de uma breve descrição. A descrição completa encontra-se disponível no manual da SCORM disponível em www.adlnet.org cmi.core Contém as informações mais importantes para os SCOs. O cmi.core é constituído pelos elementos: student_id, student_name, lesson_location, credit, lesson_status, entry, score, total_time, lesson_mode, exit e session_time. Se um SCO quiser saber os elementos do cmi.core suportados pelo LMS pode invocar a função LMSGetValue do seguinte modo: var coreChildren = LMSGetValue("cmi.core._children");

Se o LMS suportar todas as funções previstas, irá responder com a string: “student_id, student_name, lesson_location, credit, lesson_status, entry, score, total_time, lesson_mode, exit, session_time” contendo todos os elementos separados por vírgulas. A tabela 2 contém uma breve descrição de alguns destes campos:

23

Tabela 2 – Descrição de alguns elementos de cmi.core cmi.core.student_id Campo para guardar um código alfanumérico que identifica

univocamente um determinado aluno. Corresponde ao número de aluno em qualquer instituição de ensino.

cmi.core.student_name Campo onde é guardado o nome completo do aluno. cmi.core.lesson_location Corresponde ao ponto do SCO que estava a ser visualizado quando

o formando abandonou a sessão. Este valor é passado ao LMS pelo SCO quando o aluno sai do SCO e é depois recuperado quando o aluno visita novamente o SCO para permitir ao aluno recomeçar a lição no ponto em que a abandonou. A forma como o SCO guarda o ponto visitado diz respeito apenas ao SCO, o LMS limita-se a guardar essa informação.

cmi.core.lesson_status Aqui é guardado o estado de cada SCO. Existem 6 valores possíveis: “passed”, “completed”, “failed”, “incomplete”, “browsed” e “not attempted”.

cmi.core.entry Indica se o formando já visitou o SCO. Existem três valores possíveis para este campo: “ab-initio” se o SCO nunca foi visitado, “resume” se o formando já esteve no SCO ou “”, a string vazia, para outros casos como por exemplo se já tiver completado o SCO e decidiu vê-lo novamente.

cmi.core.score Indicação do desempenho do aluno. Este campo possui três filhos: “raw”, “min” e “max”. (Só é utilizado nos SCOs em que se pretende avaliar o aluno como testes e exames.)

cmi.core.score.raw Indica o resultado da avaliação do aluno no SCO. A forma de calcular e determinar o resultado da avaliação é decidida pelo formador que cria o SCO.

cmi.core.score.max Resultado máximo que o aluno pode obter no SCO. Por exemplo, no caso de o SCO ser um exame, indica se está cotado para 20 valores, 100% ou outra escala definida pelo formador. Este valor tem, no entanto que ser um número inteiro entre 0 e 100.

cmi.core.score.min Nota mínima que pode ser atribuída ao aluno. Tem de ser um valor normalizado entre 0 e 100.

24

cmi.core.total_time Tempo acumulado de todas as sessões do aluno no SCO. O formato deste campo deverá ser “HHHH:MM:SS.SS”

cmi.core.exit É uma indicação do motivo ou da forma como o formando abandonou a sessão. Os valores possíveis para este campo são: “time-out”, “suspend”, “logout” ou “” (string nula) quando a saída é feita normalmente (completando o SCO).

cmi.core.session_time Tempo gasto pelo formando numa sessão, ou seja, o tempo decorrido entre o início e o fim de uma única sessão.

cmi.objectives O cmi.objectives guarda informações sobre o desempenho dos formandos relativamente aos objectivos propostos pelo SCO. Este campo possui 3 elementos filhos: id, score e status. O cmi.objectives é um campo composto, isto é, permite guardar vários registos sob a forma de uma lista vectorial. Por exemplo, se um determinado SCO tiver definidos 3 objectivos, pode guardar o desempenho do aluno em cada um desses objectivos da seguinte forma: LMSSetValue("cmi.objectives.0.status","failed");

LMSSetValue("cmi.objectives.1.status","passed");

LMSSetValue("cmi.objectives.2.status","incomplete");

Observe-se que as listas numeradas começam sempre em 0. Se o SCO quiser num dado momento saber quantos registos dos objectivos existem no LMS pode usar a palavra chave “_count”: var totalObj = LMSGetValue("cmi.objectives._count");

Segue-se na tabela 3 a descrição sumária dos elementos pertencentes a cmi.objectives. Os elementos descritos referem-se ao registo genérico ‘n’.

25

Tabela 3 – Descrição de alguns elementos de cmi.objectives

cmi.objectives.n.id Identificador do objectivo definido pelo formador que criou o SCO. Por exemplo: “objectivo 1”, “P1”, etc…

cmi.objectives.n.score À semelhança do campo cmi.core.score, este campo também possui os filhos: raw, min e max.

cmi.objectives.n.status Este campo guarda o desempenho do aluno para o objectivo n. Existem 6 valores definidos para este campo: “passed”, “completed”, “failed”, “incomplete”, “browsed” e “not attempted”

cmi.interactions O campo cmi.interactions é também um campo composto onde são guardados os registos das interacções dos alunos com o SCO. A cada registo deste campo corresponde uma interacção do formando com o SCO e para cada registo são guardados diversos pormenores dessa interacção descritos na tabela 4. O cmi.interactions possui os filhos: id, objectives, time, type, correct_responses, weighting, student_response, result e latency.

Tabela 4 – Descrição de alguns elementos de cmi.interactions cmi.interactions.n.id Identificador da interacção. cmi.interactions.n.time Indicador do tempo utilizado pelo formando para completar a

interacção. cmi.interactions.n.type Identifica o tipo de interacção que é guardada neste registo. O tipo

de interacção determina a forma como a resposta do formando deve ser interpretada. Existem 8 valores pré-definidos para indicar o tipo de interacção, embora possam ser usados outros valores: “true-false” – questão apenas com duas respostas possíveis. “choice” – questão com um número limitado de respostas que o formando pode escolher. Podem estar correctas mais do que uma resposta. “fill-in” – questão com uma resposta curta de apenas algumas palavras. O formando tem de preencher um campo sem que

26

exista uma resposta pré-definida. “matching” – questão com dois conjuntos de itens em que cada item de um conjunto se relaciona com um ou mais itens do outro. A resposta à questão consiste em encontrar os pares de itens correctos. “performance” – É uma questão semelhante à questão de resposta múltipla mas em que a resposta do formando é dada através da realização de uma acção ou tarefa. “likert” – oferece ao formando um grupo de alternativas dentro de uma série contínua. A resposta é geralmente baseada na opinião do aluno. “numeric” – a resposta à pergunta é um valor numérico, não necessariamente inteiro.

cmi.interactions.n.correct_responses.n.pattern Descreve as respostas possíveis à interacção n. Pode existir mais do que uma resposta correcta, assim como podem existir respostas mais correctas do que outras.

cmi.interactions.n.weighting Consiste num campo numérico que atribui um peso diferente a cada interacção. A finalidade deste campo é permitir avaliar a importância relativa entre interacções. Deste modo, se uma interacção possuir um peso de 25 e outra tiver peso 15, o resultado da primeira terá mais influência no resultado final da avaliação.

Concluída a apresentação da norma SCORM TM inicia-se no capítulo seguinte a descrição do trabalho realizado no desenvolvimento do protótipo de um Learning Management System (LMS).

27

5. Protótipo de LMS

5.1. Introdução O protótipo que se pretende desenvolver será muito simples, uma vez que os objectivos da sua implementação são apenas aprofundar o conhecimento da norma SCORM (experimentando a sua aplicação) e testar o desenvolvimento da plataforma de e-Learning no ambiente da Microsoft .NET. A escolha do ambiente Microsoft .NET deve-se ao facto de ser esta a tecnologia utilizada actualmente pelo Centro de Formação procurando desta forma facilitar uma futura integração da plataforma no sistema informático do centro, nomeadamente: instalação em Windows Server, utilização das bases de dados alojadas em SQL Server e tirar partido das funcionalidades oferecidas pelo software Microsoft Sharepoint relativas à partilha de documentos. A secção seguinte descreve as funcionalidades que se pretendem desenvolver no protótipo.

5.2. Especificações O LMS deverá oferecer o seguinte conjunto de funcionalidades: Registo de utilizadores do sistema – O sistema deve permitir a inscrição de novos utilizadores através do preenchimento de um formulário, para que estes possam aceder aos recursos de ensino.

Serviço de Login – Apenas os utilizadores registados podem ter acesso aos conteúdos de ensino. Todos os utilizadores registados possuem um username e uma password com a qual podem entrar no sistema.

Permitir a um utilizador registado inscrever-se num ou mais cursos – Depois de ter feito login, o utilizador pode inscrever-se num curso e começar de imediato a frequentá-lo. O mesmo utilizador pode estar inscrito simultaneamente em mais do que um curso.

O LMS deve disponibilizar um modelo de dados coerente com a norma SCORM, isto é, deve permitir aos SCOs guardar e acederem a toda a informação pretendida tal como é previsto no

28

modelo de dados. Para isso, a base de dados deve possuir uma estrutura adequada ao tipo de informação que se pretende guardar.

Depois de efectuar o login, deve ser apresentada ao aluno uma página onde poderá escolher um curso em que se deseja inscrever e onde o aluno poderá consultar informação sobre o seu desempenho no(s) curso(s) que está a frequentar. A informação sobre o seu desempenho poderá conter o tempo total de frequência no curso, lições concluídas, resultados de testes, etc…

5.3. Concepção 5.3.1. Introdução Depois de definidas as especificações, o passo seguinte é estruturar o modo de funcionamento e definir a arquitectura do sistema. Uma plataforma de e-Learning irá estar assente num servidor web que, tal como foi analisado nas secções anteriores, irá fornecer ao utilizador todas as páginas necessárias. De entre as páginas entregues ao browser do formando, existe uma página especial que irá conter o API Adapter e para a qual os SCOs serão lançados. Depois de lançados para o browser, os SCOs irão utilizar o API Adapter para comunicar com o servidor, o que significa que o servidor deverá estar preparado para atender aos pedidos feitos pelo SCO. Para além disso, deverá existir também no servidor uma base de dados para guardar as informações relativas aos alunos e aos recursos de ensino. Em linhas gerais ficam então definidos os componentes do protótipo de LMS: Servidor de páginas web Módulo que irá atender os pedidos do SCO API Adapter Base de Dados

5.3.2. Servidor de páginas web

O servidor irá fornecer um conjunto de páginas com comportamento dinâmico para que possam conter a informação mais adequada a cada formando. No ambiente .NET estas páginas são

29

criadas desenvolvendo uma Web Application que irá servir páginas ASP (Active Server Pages) com a extensão (.aspx) 5.3.3. Módulo para atender os pedidos do SCO

Apesar dos pedidos do SCO poderem ser atendidos por páginas ASP, existe um modo muito mais eficiente de processar esses pedidos que consiste na criação de um Web Service. Um Web Service é, como o nome indica, um serviço que pode ser acedido via Web. Os serviços disponibilizados por um Web Service podem ser desde simples cálculos matemáticos ou consulta de informações de uma base de dados até operações arbitrariamente complexas. Uma das grandes vantagens dos Web Services reside no facto de serem baseados em protocolos standard, o que permite que possam ser consumidos por qualquer aplicação que utilize esses protocolos. Os protocolos utilizados pelos Web Service são os seguintes: Extensible Markup Language (XML) XML data structure (XML Schemas) Simple Object Access Protocol (SOAP) Web Service Description Language (WSDL)

Segue-se uma breve referência a cada um destes protocolos. A descrição detalhada destes protocolos excede o âmbito deste relatório uma vez que o ambiente de programação utilizado esconde do programador os detalhes da implementação e aplicação destes protocolos. A criação de um Web Service em .NET faz-se utilizando o Visual Studio com a linguagem que se quiser, Visual Basic, C++ ou C Sharp e durante a compilação o Visual Studio cria automaticamente os ficheiros e interfaces necessárias para construir o Web Service com o comportamento programado. XML1 O XML consiste numa forma standard de guardar dados em ficheiros de texto não formatado, o que lhe confere uma vantagem imediata: os ficheiros podem ser transferidos facilmente entre plataformas, pelo facto de todas saberem abrir este tipo de ficheiros. Os dados em XML são guardados com uma estrutura constituída por diversas secções cujos limites e significados são atribuídos por tags de forma semelhante ao que acontece em HTML.

1 http://www.w3.org/XML/

30

XML Schemas1

Os XML Schemas constituem um conjunto de regras que se aplicam tanto à estrutura dos documentos XML como aos seus conteúdos. Através dos XML Schemas podem-se definir simultaneamente a posição de cada elemento na estrutura do documento e o que cada elemento deve conter. Desta forma, qualquer documento XML pode ser validado quando estiver a ser criado ou consultado, confrontando-o com o seu esquema. Os próprios ficheiros que contêm os XML Schemas são escritos em XML, herdando todas as vantagens inerentes aos ficheiros XML. SOAP2

Originalmente o protocolo SOAP (Simple Object Access Protocol) era utilizado para manipular objectos remotamente. Actualmente, a sua utilização é mais especializada, sendo usado quase exclusivamente com Web Services. Os protocolos XML e XML Schemas analisados em cima são suficientes para a troca de dados com Web Services utilizando apenas HTTP, contudo, os ficheiros XML podem ser alternativamente colocados dentro de uma mensagem SOAP, beneficiando desta forma de diversas vantagens oferecidas por este protocolo. O protocolo SOAP é uma tecnologia que trabalha também com XML, assim, colocar um documento XML numa mensagem SOAP significa envolver o documento com XML adicional. As mensagens SOAP contêm duas secções: o cabeçalho e o corpo. O documento XML é colocado no corpo da mensagem e o cabeçalho é utilizado para enviar informações adicionais, específicas de cada aplicação, que podem incluir a forma como o Web Service deve responder e o esquema utilizado pelo corpo da mensagem. Um aspecto importante deste protocolo é o facto de incluir especificações relativas à indicação da ocorrência de erros. Isto permite a transmissão da informação relativa ao erro de uma forma standard e muito mais detalhada que as mensagens de erro do protocolo HTTP. WSDL3

Associado a cada Web Service existe um ficheiro WSDL (Web Service Description Language), escrito em XML, cuja função é descrever as operações que realiza. Nesta descrição incluem-se: as estruturas de dados utilizadas, as combinações destas estruturas de dados presentes nos pedidos e respostas dos serviços e qual o método a que se dirige. 1 http://www.w3.org/XML/Schema 2 http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ 3 http://www.w3.org/TR/2001/NOTE-wsdl-20010315

31

5.3.4. API Adapter

O API Adapter irá ser enviado para o browser para estabelecer a comunicação entre os SCOs e o LMS. Tal como foi analisado na secção anterior, o LMS irá disponibilizar um Web Service para atender aos pedidos do SCO. Isto significa que o API Adapter terá que comunicar com o Web Service através do protocolo SOAP. Assim, o API Adapter deverá disponibilizar de um lado uma interface acessível por JavaScript com as funções previstas no Run-Time Environment e do outro, uma interface de comunicação com o Web Service através do protocolo SOAP. O envio de dados a partir do browser é relativamente fácil de conseguir utilizando os formulários definidos em HTML, no entanto, a recepção de dados é mais complexa, porque normalmente exige que a página seja refrescada. Este comportamento é evidentemente indesejável, até porque para cada SCO podem ser necessárias várias dezenas de comunicações o que implicaria estar constantemente a refrescar a página. Para resolver esta questão recorre-se habitualmente a tecnologias com capacidade de comunicarem via HTTP tais como applets em Java ou objectos em Flash. No Internet Explorer este problema pode também ser contornado utilizando ficheiros HTC (HTML Component) que permitem imprimir um comportamento dinâmico às páginas HTML. Em particular, a Microsoft preparou já um ficheiro HTC (webservice.htc) para permitir a comunicação com Web Services (enviar e receber dados) sem necessidade de refrescamento da página. Utilizando este ficheiro, o API Adapter pode ser construído utilizando apenas JavaScript. 5.3.5. Base de Dados

A base de dados irá estar alojada no servidor e irá ter uma estrutura que lhe permita guardar os elementos seleccionados do Modelo de Dados da norma SCORM e informação relativa à gestão dos formandos (dados pessoais, contas de utilizador, etc…). Atendendo ao facto do volume de informação ser relativamente pequeno, a base de dados será criada em Microsoft Access.

32

5.3.6. Interacção entre os elementos Depois de introduzidos os elementos que compõem o sistema, nesta secção irá ser analisada a forma como eles actuam entre si para responder às interacções do utilizador. As interacções do utilizador serão acompanhadas de imagens das interfaces utilizadas para permitir uma melhor compreensão. Antes de iniciar a descrição das interacções do utilizador, e também para colmatar a análise dos diversos componentes nas secções anteriores, apresenta-se na figura 8 um diagrama com a arquitectura do sistema que irá ser implementado. Nele estão representados os diversos elementos que compõem o sistema e a forma como estão interligados.

API Adapter

JavaScript

Basede

Dados

Active ServerPages(aspx)

Web Application

LMS Service

Web ServiceLMS

• Login• Registo• Selecção de curso• Informação do utilizador

TOC SCO

HTTP

HTTP

SOAP

Web Browser

Figura 8 – Arquitectura do protótipo a desenvolver

Para iniciar a sua sessão no sistema, o formando deve colocar no browser o endereço do servidor de LMS. É-lhe enviada nesse momento pela Web Application a página de entrada, que consiste numa página de boas-vindas, na qual estão disponíveis informações de carácter geral (disponíveis para qualquer visitante, registado ou não) e a partir da qual o formando pode efectuar o login.

33

Figura 9 – Página de entrada

No caso do formando não estar ainda registado no sistema, deve fazê-lo através da página de registo, acessível a partir da página inicial. Nesta página, são-lhe pedidos alguns dados pessoais como, o nome, contactos, data de nascimento, etc… Seguidamente é-lhe atribuído um número de aluno e é-lhe pedido que escolha uma password para aceder à plataforma de e-Learning. A partir do momento em que o formando entra no sistema como utilizador registado, é-lhe apresentada uma página, a partir da qual se pode inscrever nos cursos disponíveis, e onde pode visualizar informações sobre o seu desempenho nos cursos a que já está inscrito, como ilustra a figura 10:

34

Figura 10 – Página do aluno

Seleccionando o curso na list box da coluna da esquerda, o formando pode inscrever-se e frequentar o curso que pretender. Na figura 10, o aluno com o número alu001 encontra-se já inscrito no curso Maritime Navigation. Para o frequentar deve simplesmente seleccioná-lo na list

box e carregar no botão “Frequentar”. Todas estas janelas apresentadas correspondem ao primeiro rectângulo a verde da figura 8. As janelas são enviadas pela Web Application (como páginas aspx) que também atende a todos os pedidos do utilizador (registo, login, inscrição num curso, etc…) A partir do momento em que o formando inicia a frequência de um curso, é-lhe enviada para o browser a janela especial que contém o API Adapter ilustrada na figura 11. Esta janela corresponde ao segundo rectângulo a verde da figura 8. Como se pode observar, esta janela irá abrir uma segunda janela, ou conter uma frame, na qual irão ser disponibizados os SCOs, representada na figura pelo rectângulo branco. Na realidade esta será uma janela com três frames: uma frame colocada do lado esquerdo para a Tabela de Conteúdos com um índice dos SCOs disponíveis, uma frame auxiliar colocada no topo para auxiliar a navegação e a frame principal para a visualização dos SCOs. Esta janela, à semelhança do que acontece com todas as outras, é enviada pela Web Application como uma página aspx. Quando o SCO quiser comunicar com o LMS, irá invocar as

35

funções disponibilizadas pelo API Adapter que por sua vez irá invocar, através do protocolo SOAP, as funções do Web Service adequadas. O resultado destas funções será devolvido ao API Adapter, através de uma mensagem SOAP, que o entregará à função do SCO que desencadeou o processo de comunicação.

Figura 11 – Página de visualização dos SCOs

5.4. Implementação 5.4.1. Introdução Ao longo desta secção irá ser analisada a forma como cada um dos componentes identificados na secção anterior foi implementado: Base de Dados (Secção 5.4.2) API Adapter (Secção 5.4.3) Web Service (Secção 5.4.4) Web Application (Secção 5.4.5)

A análise segue uma sequência lógica, começando pela base de dados, que guardará toda a informação necessária ao funcionamento da plataforma. Os três componentes seguintes estão

36

todos estreitamente ligados entre si: a Web Application serve a página com o API Adapter que por sua vez comunica com o Web Service. Destes três elementos, o primeiro a ser analisado será o API Adapter porque tanto a Web Application como o Web Service serão influenciados pela forma como ele estiver implementado. De facto, a página em que o API Adapter é enviado terá que ser construída na Web Application com uma estrutura que permita ao API Adapter funcionar correctamente e o Web Service deverá, por outro lado, receber e devolver os dados pedidos da forma mais conveniente. 5.4.2. Implementação da Base de Dados A base de dados será criada, como foi referido, em Microsoft Access. Atendendo ao reduzido universo de utilizadores para o qual o protótipo foi desenhado, o Microsoft Access permite criar e gerir facilmente uma base de dados eficiente para o sistema.

Figura 12 – Diagrama das relações da base de dados.

Para os formandos acederem ao sistema, deverão primeiro efectuar o seu registo, fornecendo os seus dados pessoais. Depois de registados, o sistema atribui-lhes um número de aluno que, em conjunto com a password que escolherem, lhes permitirá entrar no sistema. A informação pessoal dos alunos será guardada numa tabela com o nome AlunosInfo representada na figura 12. A chave primária desta tabela é o número de aluno atribuído pelo sistema. É também com este número que o aluno tem acesso ao sistema introduzindo-o como login juntamente com a password cujo valor será guardado na tabela Contas.

37

Figura 13 – Diagrama das relações da base de dados.

Na base de dados irão também estar guardadas informações relativas aos cursos instalados no LMS. Essa informação estará guardada na tabela CursosInfo que contém um identificador numérico unívoco para cada curso, o nome, uma pequena descrição do curso, o endereço do Manifesto e a localização do curso. O Manifesto indica não só a organização do curso, mas também a localização relativa de cada componente (SCOs e Assets) a partir do directório em que o curso esteja instalado. Embora essa informação possa ser consultada directamente do Manifesto, isso obrigaria a fazer o parsing do ficheiro para cada utilização do curso que se iria traduzir numa perda de eficiência no tempo de resposta do LMS, sobretudo se o Manifesto tiver muita informação. Em alternativa, é preferível fazer o parsing do Manifesto uma única vez, quando o curso é instalado no LMS, e guardar a informação extraída na base de dados. O acesso à informação é muito mais rápida depois de instalada na base de dados, não só pelos métodos de pesquisa optimizados que as bases de dados possuem, mas também porque a informação pode ser guardada com a estrutura mais conveniente a cada sistema. Assim, foi criada a tabela ItemInfo para guardar as informações relevantes do Manifesto, que terá uma entrada para cada item (SCO ou Asset) de cada curso. Os campos guardados na tabela são os seguintes:

38

Href – localização do SCO ou do Asset. Nome – nome do SCO ou Asset. Título – indica se na organização, se trata de um componente com sub componentes, ou de um componente isolado, isto é, indica se é um elemento-pai. Profundidade – é um valor numérico que indica o grau de profundidade do item na estrutura. Prerequisites – guarda a indicação de qual ou quais os SCOs do curso que devem ser completados antes de iniciar este item. MasteryScore – este campo guarda um valor numérico (habitualmente entre 0 e 100) que estabelece a nota mínima que o formando deve atingir para ser aprovado no SCO. Só se aplica aos SCOs que contenham elementos de avaliação. MaxTimeAllowed – tempo máximo que o formando dispõe para visualizar o SCO. TimeLimitAction – guarda a informação sobre a forma como o LMS deve agir quando o tempo máximo é excedido (ex: sair do SCO, avisar o utilizador, continuar…). Sequence – indica qual a posição do SCO na sequência de SCOs do curso.

Obs: Ao contrário do que acontece com as restantes colunas da tabela, a informação contida nos

campos Título, Profundidade e Sequence, é obtida através da análise do Manifesto mas não está

declarada explicitamente. A função destes campos é permitir a construção automática da Table

of Contents (TOC) que acompanhará o lançamento dos SCOs.

A tabela Aluno_Curso regista quais os cursos em que cada aluno se encontra inscrito, juntamente com a indicação do número de vezes que entrou no curso e o tempo total gasto a frequentar o curso. Para cada aluno e para cada curso, são guardadas na tabela Alunos_SCO_Info as informações relativas a cada SCO. Esta tabela existe para que os SCOs possam aceder e guardar os dados que precisarem, tendo uma coluna para cada elemento do Modelo de Dados suportado pelo protótipo. Os elementos suportados no sistema são os que se podem observar na figura 13, na tabela Alunos_SCO_Info. A tabela LMS_Objectives é um elemento composto da tabela Alunos_SCO_Info, isto é, para a mesma chave (formada pelo ID do aluno, ID do curso e ID do SCO) pode ter várias entradas identificadas pelo parâmetro N. Desta forma quando o SCO efectua um SetValue do elemento cmi.objectives.1.status com um determinado valor, está a guardar esse valor na linha identificada pela chave: ID do aluno, ID do curso, ID do SCO e N igual a 1 da tabela LMS_Objectives.

39

A tabela LMS_Interactions é em tudo análoga à LMS_Objectives, com a particularidade de ela própria ter também elementos compostos guardados nas tabelas LMS_Interactions_Objectives e LMS_Interactions_Correct_Responses. 5.4.3. Implementação do API Adapter O API Adapter irá, como foi já analisado na secção 4.3.2, disponibilizar aos SCOs as funções previstas na norma SCORM: LMSInitialize(“”) LMSFinish(“”) LMSGetLastError() LMSGetErrorString(errornumber) LMSGetDiagnostic(parameter) LMSGetValue(element) LMSSetValue(element, value) LMSCommit(“”)

Estas funções terão que estar todas disponíveis num objecto com o nome API criado em ECMAScript (JavaScript). Assim, quando o SCO quiser, por exemplo, invocar o LMSInitialize, só tem que localizar o objecto API (que deverá estar numa janela-pai daquela em que o SCO se encontre) e utilizar o método LMSInitialize desse objecto. O exemplo seguinte, retirado e adaptado do manual da ADL, mostra de que forma o SCO pode procurar o API quando é lançado, e como pode utilizar os seus métodos: <script language=”javascript”> //***************************// //Funções para procurar a API// //***************************// var findAPITries = 0; function findAPI (win) { while ( (win.API == null) && //enquanto não encontrar o API na (win.parent != null) && //janela (win) e esta tiver uma (win.parent != win) ) //janela pai diferente da janela em //que se encontra { //incrementa o número de tentativas findAPITries++; //7 é um número arbitrário de tentativas, mas é em geral

40

//mais do que suficiente if (findAPITries > 7) { alert("Error findind API – too deeply nested."); return null; } //procura na janela pai; win = win.parent; } return win.API; } function getAPI() { //começa por procurar o objecto API nesta janela var theAPI = findAPI (window); //se não tiver encontrado o API e esta janela tiver sido aberta //por outra janela, procura nessa janela if ( (theAPI == null) && (window.opener != null) && (typeof(window.opener) != "undefined") ) { theAPI = findAPI(window.opener); } //Se não tiver encontrado o API if (theAPI == null) { alert("Unable to find the API Adapter"); } return theAPI; } //*****************// //Utilização da API// //*****************// var API; //procura a API e cria uma instância com o nome myAPI myAPI = getAPI(); //Exemplos de utilização da API myAPI.LMSInitialize(""); myAPI.LMSGetValue("cmi.core.student_name"); myAPI.LMSFinish("");

No LMS implementado, o API Adapter irá estar inserido na janela representada na figura 11. Esta janela tem a seguinte estrutura:

41

API Adapter

JavaScript

Frame paravisualização de

SCOsFrame

daTable ofContents

(TOC)

Frame auxiliar de navegação

Figura 14 – Estrutura da janela de apresentação de SCOs

Como se pode verificar, o API Adapter está na janela-pai que contém as três frames observadas na figura 11. Em HTML, esta é a janela principal onde são definidas as frames. O API Adapter representado é um objecto criado em JavaScript com o nome API e que contém os 8 métodos correspondentes às funções da API descritos acima. Sempre que é chamado cada um destes métodos, o API Adapter irá comunicar com o Web Service para que este execute as operações pedidas pelo SCO. A comunicação do API Adapter com o SCO será feita utilizando um script criado pela Microsoft para comunicação com Web Services. O script está programado em JScript, que consiste numa versão de ECMAScript da Microsoft, e é distribuído num ficheiro HTC (HTML Component) com o nome webservice.htc. Para poder utilizar as funções disponibilizadas neste ficheiro, ele tem de ser anexado ao documento HTML em que irá ser utilizado. A anexação é feita utilizando o atributo style num elemento HTML e definindo o parâmetro behavior com o url do ficheiro webservice.htc. No fim desta secção encontram-se listados os excertos de código que implementam toda a comunicação com o LMS e que exemplificam a utilização deste ficheiro. O webservice.htc disponibiliza dois métodos através dos quais se podem aceder a Web Services e manipular os dados que eles retornem: useService(string URL, string friendlyName) – permite aceder a um Web Service no endereço que for passado em “URL”, e atribui à invocação desta função um nome ‘amigável’ em “friendlyName”. callService([function callback,] string method, mixed parameters) – utilizada para chamar um método específico do Web Service, passado através do parâmetro “method”, com os argumentos passados em “parameters”. A função opcional “callback” permite atribuir uma

42

função que será chamada quando o Web Service devolver uma resposta. Esta função é opcional porque normalmente é utilizado um handler, colocado no elemento HTML que anexa o ficheiro HTC, que é invocado sempre que o Web Service retorna algum resultado.

A codificação e descodificação das mensagens SOAP com que os Web Services operam, é feita de forma automática pelo script do ficheiro HTC, o que permite utilizar os Web Services confortavelmente como se se tratassem de funções declaradas localmente. No protótipo desenvolvido, o API Adapter funcionará do seguinte modo: quando o SCO fizer a invocação de algum dos métodos disponibilizados, por exemplo do LMSInitialize, o API Adapter irá por sua vez fazer a invocação desse método no Web Service, ou seja, irá transmitir o pedido do SCO ao Web Service. Utilizando as funções do ficheiro webservice.htc, isso pode ser forma de uma forma tão simples como esta: callService("LMSInitialize","");

A string “LMSInitialize” é o parâmetro que indica o método do Web Service invocado, e a string nula “” é o argumento do método que, neste caso é sempre a string nula. A invocação dos métodos do Web Service do LMS obriga, no entanto, à utilização de mais argumentos. De facto, o Web Service precisa de saber qual o SCO que está a fazer o pedido, a que curso é que ele pertence e qual o aluno que está a utilizar o SCO para poder identificar univocamente os dados que são pedidos. Assim, cada invocação de um método é sempre feita com estes três argumentos adicionais como mostram estes exemplos: callService("LMSInitialize","",ID_Aluno,ID_Curso,ID_SCO);

callService("LMSGetValue","cmi.core.lesson_status",ID_Aluno,ID_Curso,I

D_SCO);

Voltando à análise da figura 14, observa-se que o API Adapter está na janela-pai (representada a verde) que contém o código HTML para a criação das 3 frames. Pelo facto de ser uma página de criação de frames, não permite a inclusão de mais nenhum código HTML, em particular, não permite inserir nenhum elemento que possa suportar a anexação do ficheiro webservice.htc. Isto significa que, para utilizar as funções deste ficheiro, ele terá de ser anexado a um elemento de uma das frames. A frame escolhida foi a frame auxiliar de navegação, colocado no topo da janela, pelo facto de ser a única que se mantém inalterada durante a visualização dos SCOs. As outras duas são dinâmicas, sendo os seus conteúdos dependentes do SCO que o utilizador estiver a ver.

43

Deste modo, o API Adapter irá estar dividido em duas partes, uma colocada na janela-pai e outra colocada na frame auxiliar. A parte colocada na janela-pai é a que está responsável por criar o objecto “API” que os SCOs irão procurar, e que lhes disponibiliza uma interface para as 8 funções da API. A parte colocada na frame auxiliar estará incluída num elemento <DIV> do código HTML, que irá conter no atributo style os argumentos necessários para anexar o ficheiro webservice.htc. A colocação da primeira parte do código na janela-pai é possível porque está toda inserida no cabeçalho do ficheiro HTML, no entanto, a segunda parte obriga à existência de um elemento <DIV> que não pode ser criado nesta janela pelo facto de ser uma janela de definição de frames e consequentemente não tem secção <BODY> onde estes elementos são criados. Por outro lado, também não é possível colocar todo o código na frame auxiliar porque ela está ao mesmo nível da janela do SCO e a norma SCORM obriga a que o API Adapter esteja colocado numa janela hierarquicamente superior à do SCO. Concluída a análise da implementação do API, conclui-se a secção com os excertos de código relevantes na implementação da API. Código da frame auxiliar de navegação (Toolbar.aspx): <HTML>

<HEAD>

<script language=”javascript”>

function init() {

//Elemento da página que contém o Web Service. A variável

//svcElm a partir deste momento passa a apontar para um objecto

//que contém os métodos do ficheiro webservice.htc

svcElm = document.getElementById("apiDiv");

//Indica o endereço do serviço que vai ser utilizado e o nome

//pelo qual vai ser chamado (Api)

svcElm.useService("http://localhost/LMSService/LMS.asmx?WSDL",

"Api");

}

/////////////////////////

//Funções do WebService//

/////////////////////////

44

//Esta função tem apenas um atributo para indicar o

//último serviço fornecido pelo LMSService a ser chamado

//O código da API colocado na janela-pai coloca em s o nome

//de cada serviço invocado.

function service() {

this.s;

}

//Esta função é chamada quando o LMSService responde

//Faz o parsing da resposta SOAP enviada pelo LMSService

//e coloca a resposta em hresult

//Utiliza o atributo 's' definido em cima para procurar a resposta

//adequada consoante o serviço que foi chamado.

function handleResult() {

var html = "";

var r = event.result;

if (r.error) {

html += "A service error occured:\n\n";

html += r.errorDetail.string;

} else {

var xml = r.raw;

var hresult = 0;

var elm = xml.getElementsByTagName(service.s +

"Result").item(0);

hresult = elm.firstChild.nodeValue;

}

html = hresult;

event.srcElement.innerHTML = html;

//O objecto resultado e a variável res estão definidos na

//janela-pai. Esta instrução passa para a variável res colocada

//nessa janela o resultado devolvido pelo Web Service

top.resultado.res = html;

}

</script>

</HEAD>

<BODY onload="init()">

(...)

//Aqui está definido o elemento <DIV> onde é feita a anexação do

//ficheiro webservice.htc. Os métodos disponíveis no ficheiro podem

45

//podem ser agora acedidos usando uma referência ao elemento apiDiv.

//O handler onresult chama a função handleResult() sempre que algum

//dos métodos chamados através deste elemento devolva um resultado,

//ou seja, sempre que o Web Service retorna um valor.

<DIV id="apiDiv"

style="BEHAVIOR:url(http://localhost/LMS/scripts/webservice.htc)"

onresult="handleResult()">

</DIV>

</BODY>

</HTML>

Código da janela-pai: <HTML>

<HEAD>

<TITLE>E-learning</TITLE>

<SCRIPT language="javascript" src="API.js"></SCRIPT>

</HEAD>

<FRAMESET rows="40,*">

<FRAME name="Toolbar" src="Toolbar.aspx">

<FRAMESET cols="216,73%">

<FRAME name="toc" src="Toc.aspx">

<FRAME name="stage" src="blank.html">

</FRAMESET>

</FRAMESET>

</HTML>

No cabeçalho está colocado o código do API Adapter

var contador;

var sco;

//Esta função guarda os resultados devolvidos pelo Web Service

// passados pela parte do código colocado na frame Toolbar.aspx

// (frame auxiliar). Guarda também os valores ID_SCO, ID_Curso e

// ID_Aluno que permitem ao Web Service identificar univocamente o

// SCO. Estes valores são passados pela frame que contém a Table of

// Contents. Sempre que um novo SCO é inicializado, estes valores

// são actualizados.

function resultado() {

this.res;

this.ID_SCO; //guarda o código do SCO que está a chamar a API

this.ID_Curso;

46

this.ID_Aluno;

}

//Implementação da função Pause em JavaScript

//O JavaScript não tem implementada nenhuma função de pause. Esta

//função cria um ModalDialog invisível durante o número de

//milisegundos indicado que bloqueia o fluxo do script

function pause(numberMillis) {

var dialogScript = 'window.setTimeout(' +

' function () { window.close(); }, ' + numberMillis + ');';

var result = window.showModalDialog('javascript:document.writeln(' +

'"<script>' + dialogScript + '<' + '/script>")');

}

/*********************************************************************

** Funções da API **

** **

** Estas funções são métodos do objecto API que apenas invocam **

** o WebService: 'LMSService' para lhe passar e pedir os parâmetros **

** que o SCO determinar **

*********************************************************************/

function LMSInitialize(str) {

//reinicializa a variável res

resultado.res = null;

//Este contador serve para limitar o nr de tentativas feitas para

//tentar contactar o Web Service. Desta forma, se o Web Service não

//estiver disponível por algum motivo, o browser não irá ficar

//bloquado à espera da resposta do Web Service

contador = 0;

//coloca no atributo 's' de service, na frame auxiliar

//a indicação do serviço que está a ser utilizado.

//Esta informação é necessária apenas na segunda parte do código.

Toolbar.service.s = "LMSInitialize";

//Invoca o serviço e passa-lhe os parâmetros necessários,

//neste caso ""

Toolbar.svcElm.Api.callService("LMSInitialize", "",

resultado.ID_Aluno,resultado.ID_Curso, resultado.ID_SCO);

47

//Executa um ciclo de espera até que o LMSService responda

//isto é, coloque um resultado em 'resultado.res'

//Esta verificação é feita em intervalos de 500 milisegundos,

//até a um número máximo de 10 vezes, ou seja, irá esperar no

//máximo 5 segundos pela resposta.

while (resultado.res == null && contador < 10) {

pause(500);

contador++;

}

return resultado.res;

}

function LMSFinish(str) {


Toolbar.service.s = "LMSFinish";

Toolbar.svcElm.Api.callService("LMSFinish", "",

resultado.ID_Aluno, resultado.ID_Curso, resultado.ID_SCO);

contador = 0;


pause(500);

contador++;

}


}

function LMSGetLastError() {


Toolbar.service.s = "LMSGetLastError";

//para esta função não é necessário identificar o SCO, por isso

//a função é invocada sem nenhum argumento

Toolbar.svcElm.Api.callService("LMSGetLastError");

contador = 0;


pause(500);

contador++;

}


}

function LMSGetErrorString(errorcode) {


Toolbar.service.s = "LMSGetErrorString";

Toolbar.svcElm.Api.callService("LMSGetErrorString",errorcode);

48

contador = 0;


pause(500);

contador++;

}


}

function LMSGetDiagnostic(errorcode) {


Toolbar.service.s = "LMSGetDiagnostic";

Toolbar.svcElm.Api.callService("LMSGetDiagnostic",errorcode);

contador = 0;


pause(500);

contador++;

}


}

function LMSGetValue(element) {


Toolbar.service.s = "LMSGetValue";

Toolbar.svcElm.Api.callService("LMSGetValue", element,


contador = 0;


pause(500);

contador++;

}


}

function LMSSetValue(element, value) {


Toolbar.service.s = "LMSSetValue";

Toolbar.svcElm.Api.callService("LMSSetValue", element, value,


contador = 0;


pause(500);

contador++;

}


}

49

//Função fictícia. Uma vez que os dados são passados em

//tempo real para o servidor, esta instrução torna-se redundante,

//apenas está implementada para não ser gerado um erro

//no caso do SCO a chamar

function LMSCommit(str) {

return 0

}

//Cria uma 'classe' com os métodos da API. Quando for instanciado

//um objecto desta classe, pode invocar qualquer um dos métodos

//implementados pelas funções acima.

function APIfunc() {

this.LMSInitialize = LMSInitialize;

this.LMSFinish = LMSFinish;

this.LMSGetLastError = LMSGetLastError;

this.LMSGetErrorString = LMSGetErrorString;

this.LMSGetDiagnostic = LMSGetDiagnostic;

this.LMSGetValue = LMSGetValue;

this.LMSSetValue = LMSSetValue;

this.LMSCommit = LMSCommit;

}

//Cria o objecto API

var API = new APIfunc();

5.4.4. Implementação do Web Service O Web Service foi criado para atender aos pedidos dos SCOs pelo facto de permitir, juntamente com a utilização do ficheiro webservice.htc, a criação de um API Adapter com uma estrutura relativamente simples, como foi analisado na secção anterior. A criação de um Web Service em .NET pode ser feita facilmente utilizando a ferramenta Visual Studio com uma das linguagens: Visual Basic, C++ ou C#. No protótipo criado, o Web Service foi programado em Visual Basic. A programação é muito semelhante à utilizada para o desenvolvimento de uma aplicação executável, com mais algumas instruções específicas. Por exemplo, para criar um método no Web Service que some dois valores usa-se a seguinte sintaxe: <WebMethod()> Public Function Add(ByVal A As System.Single, ByVal B As

System.Single) As System.Single

50

Return A + B

End Function

Durante a compilação, o Visual Studio cria automaticamente um ficheiro com a extensão .asmx que implementa as funcionalidades do Web Service. No exemplo sugerido, se ao Web Service fosse dado o nome MathService, seria criado o ficheiro MathService.asmx acessível no servidor em que fosse criado. Para realizar a adição de dois números, por exemplo, 2 e 3, a operação pode ser pedida enviando a seguinte mensagem SOAP: POST /MathService/MathService.asmx HTTP/1.1

Host: localhost

Content-Type: text/xml; charset=utf-8

Content-Length: length

SOAPAction: "http://tempuri.org/Add"

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<Add xmlns="http://tempuri.org/">

<A>2</A>

<B>3</B>

</Add>

</soap:Body>

</soap:Envelope>

à qual o Web Service responderia com a mensagem: HTTP/1.1 200 OK

Content-Type: text/xml; charset=utf-8

Content-Length: length

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

51

<soap:Body>

<AddResponse xmlns="http://tempuri.org/">

<AddResult>5</AddResult>

</AddResponse>

</soap:Body>

</soap:Envelope>

Alternativamente poderia aceder-se directamente ao ficheiro pelo endereço url, com os

parâmetros inseridos no próprio url:

http://localhost/MathService/MathService.asmx/Add?A=2&B=3

Neste caso seria mostrada uma página com a resposta em formato xml: <?xml version="1.0" enconding="utf-8" ?>

<float xmlns="http://tempuri.org/">5</float> No protótipo de LMS foi criado um Web Service com o nome LMSService com um método para cada uma das funções disponibilizadas pelo API Adapter com excepção do LMSCommit que é simulada localmente no API Adapter como foi já explicado na secção 5.4.3. A listagem do código não irá ser aqui apresentada porque ser bastante extensa (mais de 1300 linhas de código) e de fácil implementação. Será feito apenas um resumo das operações realizadas em cada um dos métodos: LMSInitialize

Do ponto de vista do LMS implementado, a função LMSInitialize serve apenas para identificar o SCO que está activo e que deseja iniciar uma comunicação. Assim, a função LMSInitialize recebe como argumentos os IDs do SCO, do curso e do aluno e guarda numa variável de sessão com o nome Initialized que o SCO está inicializado. Uma variável de sessão, é uma funcionalidade das Web Applications e dos Web Services que permite guardar variáveis para um utilizador durante o tempo que o utilizador permanecer ligado à página (tempo de sessão). No caso particular da variável de sessão Initialized, sempre que o API Adapter invocar algum dos métodos do Web Service estes podem verificar se o SCO está ou não inicializado consultando esta variável.

52

Foi também criada uma outra variável de sessão com o nome Error, que irá guardar o código do último erro ocorrido. Pela norma SCORM, sempre que é invocada a função LMSGetLastError(), o LMS deve devolver o código do último erro. Para implementar esta funcionalidade, cada função vai actualizando esta variável de acordo com o sucesso ou não das suas operações. Voltando ao LMSInitialize, se não ocorrer nenhum erro, a variável de sessão Error irá ficar com o valor 0, a variável Initialized ficará com o valor true e a função irá retornar ao API Adapter a string “true”. Se ocorrer algum erro, não haverá inicialização, é atribuído a Error o código 101 e a função devolve o valor “false”. LMSFinish

Quando esta função é invocada actualiza a variável de sessão com o valor false para indicar que o SCO foi terminado, actualiza a variável error com o valor adequado (0 se não ocorrer nenhum erro) e actualiza na base de dados o tempo total de sessão, isto é, soma ao tempo total o tempo utilizado nesta sessão. Se ocorrer algum erro o modo de proceder será idêntico ao descrito para o LMSInitialize. LMSGetLastError

Esta é a função utilizada pelo SCO para avaliar o sucesso da última operação realizada. Quando é invocada ela simplesmente devolve o valor da variável de sessão Error, que vai sendo actualizado por cada uma das funções quando é chamada. LMSGetErrorString

A função ErrorString simplesmente devolve ao SCO uma string com a descrição do código do erro que ele pedir. A implementação desta função é extremamente simples, consiste apenas em associar a cada código de erro uma string pré-definida, por exemplo para o código 0 a string devolvida será “No error”. LMSGetDiagnostic

Esta função não foi implementada no protótipo pelo facto de o seu objectivo ser meramente o de fornecer uma informação mais detalhada acerca do código de erro passado como argumento. Nesta fase de protótipo a descrição fornecida pelo LMSGetErrorString será suficiente.

53

LMSGetValue e LMSSetValue

Estas duas funções são as que têm uma implementação mais extensa porque têm uma estrutura de Select – Case que abrange todos os elementos do Modelo de Dados implementado: cmi.core.student_name, cmi.core.session_time, cmi.objectives.0.id, etc… Para cada elemento o Web Service guarda ou retorna os dados pedidos no argumento e gera os códigos de erro adequados, por exemplo, se o API Adapter pedir para fazer um LMSSetValue do elemento cmi.core.student_name, a operação não será realizada e será colocado em Error o valor 403 que significa que o API tentou alterar um elemento que é apenas de leitura. 5.4.5. Implementação da Web Application Tal como foi analisado na secção 5.3.6 a Web Application constitui o módulo principal do LMS. Todas as páginas enviadas para o browser do formando, com excepção das páginas de SCOs, são geradas pela Web Application. Para além desta funcionalidade, tem ainda a seu cargo o registo de novos alunos e a autenticação dos utilizadores do sistema. À semelhança do que acontece com os Web Services, no ambiente .NET as Web Applications são também desenvolvidas utilizando o Visual Studio. Durante a criação das páginas, o código HTML é introduzido juntamente com o código em Visual Basic para lhes conferir o comportamento dinâmico. O código Visual Basic é inserido dentro de tags especiais que começam com a palavra asp tais como: <asp:textbox> ou <asp:label>, ou alternativamente é introduzido dentro de uma tag de script com a indicação de que o script corre no servidor: <SCRIPT runat="server">

As funções geradas podem ainda ser criadas num ficheiro em Visual Basic que existe associado a cada página. Depois de criadas, as páginas são compiladas numa DLL que irá ser executada cada vez que alguma das páginas da Web Application seja acedida. A primeira página a ser enviada para o browser, é uma página de boas-vindas onde o formando pode consultar informações sobre os cursos disponíveis na plataforma e a partir da qual pode entrar no sistema. (Ver fig. 9) Se o formando não estiver ainda registado no sistema, pode efectuar o seu registo sendo-lhe nesse caso apresentada uma página para pedir os seus dados pessoais com o seguinte aspecto:

54

Figura 15 – Janela de registo

Depois de introduzidos os dados é enviada para o formando uma página de confirmação, representada na figura 16, na qual são apresentados todos os dados introduzidos na página anterior, um número de aluno gerado automaticamente e um campo para que o formando possa escolher a sua password. Se o formando desejar corrigir algum dos dados, deve seleccionar a opção correspondente, regressando neste caso à janela da figura 15, se por outro lado, todos os dados estiverem correctos, o formando deve introduzir uma password e carregar em “Confirmar” para concluir o processo de registo.

55

Figura 16 – Janela de confirmação de registo

Na janela da figura 15, os dados inseridos são guardados em variáveis temporárias para poderem ser depois expostos na janela de confirmação. A janela de registo tem ainda implementado um pequeno algoritmo para garantir que os dados sejam introduzidos com o formato correcto. Se algum dos dados para o qual é feita a verificação, não for colocado correctamente, é apresentada uma mensagem na coluna a verde para pedir ao formando que corrija esse campo. Os campos para os quais é feita a verificação são os seguintes: Código Postal – Deve ser da forma “xxxx-xxx localidade”, isto é, deve ter 4 dígitos, um hífen, 3 dígitos e o nome da localidade. Telefone – Os números de telefone devem pertencer ao plano de numeração nacional com 9 dígitos. E-mail – A string introduzida deve conter obrigatoriamente os caracteres ‘@’ e ‘.’ Data de Nascimento – Deve ter o formato ‘dd-mm-aaaa’

Com esta verificação pretende-se dificultar a introdução de dados falsos, por distracção ou intencionalmente, e conferir aos dados o formato com que a base de dados trabalha.

56

Se todos os dados estiverem introduzidos com o formato correcto, o formando deve de seguida validar o seu conteúdo, na página de confirmação da figura 16, na qual lhe são apresentados novamente os dados que acabou de introduzir. Nesta página é também fornecido ao formando o número de aluno, gerado automaticamente pela Web Application. O número de aluno tem o formato ‘aluxxx’, onde xxx é um número com 3 dígitos atribuído de forma sequencial. Para criar o número de aluno, a Web Application consulta a base de dados, verifica qual é o número do último aluno inscrito (aluno com o número xxx mais alto) e cria um novo número de aluno incrementando o número do último aluno inscrito. Depois de confirmados os dados e de introduzida a password, os dados são guardados na base de dados como uma nova entrada nas tabelas AlunosInfo e Contas. Concluído o processo de registo, o formando pode agora aceder ao sistema introduzindo o seu número de aluno e a sua password na página inicial (figura 9). Ao aceder ao sistema é-lhe apresentada uma página que contém as informações sobre o seu desempenho em cada um dos SCOs para cada curso em que esteja inscrito. Como o formando ainda não se encontra inscrito em nenhum curso a página será apresentada como ilustra a figura 17:

Figura 17 – Janela com informações sobre o desempenho do aluno

57

Para iniciar a frequência de um curso, o formando deve seleccioná-lo na list box e carregar no botão “Inscrever”. Quando o formando se inscreve a Web Application cria uma entrada nova na tabela Aluno_Curso para registar a inscrição do aluno no curso escolhido, e, para cada SCO pertencente ao curso, cria uma entrada na tabela Alunos_SCO_Info. Para saber quais os SCOs que pertencem ao curso é consultada a tabela ItemInfo. Todos os campos das linhas inseridas em Alunos_SCO_Info estão em branco, excepto o lesson_status, entry e lesson_mode que guardam valores pré-definidos. No campo lesson_status ficará guardado o valor “not attempted”, em entry “ab-initio” e em lesson_mode o valor “normal”. Depois de criadas as entradas na tabela, a janela da figura 17 é actualizada com as novas informações disponíveis:

Figura 18 – Janela com informações sobre o desempenho do aluno após inscrição no curso

A figura 18 representa o aspecto da janela após a inscrição no curso “Maritime Navigation” que consiste num curso de demonstração fornecido pela ADL para a realização de testes com a norma SCORM.

58

Obs: Encontra-se disponível no endereço http://www.fe.up.pt/~ee95135/ uma simulação do

protótipo de LMS criado, na qual é possível inscrever-se e frequentar este curso.

Depois de inscrito, o formando pode iniciar a frequência desse curso sendo enviada para o browser a janela com o API Adapter e as três frames ilustrada na figura 11 e representada esquematicamente na figura 14. Tanto a janela auxiliar de navegação “Toolbar” como a janela-pai, onde está o API Adapter, são do ponto de vista da Web Application páginas estáticas, isto é, o seu conteúdo é sempre o mesmo independentemente do SCO visualizado e das interacções do formando. O mesmo não se passa com a frame que contém a Table of Contents. Esta frame irá apresentar uma lista ordenada a partir da qual o formando pode seleccionar o SCO que pretende ver. Para construir esta lista, a Web Application consulta a tabela ItemInfo de onde extrai a informação necessária para criar a estrutura da lista. A construção é feita do seguinte modo: É feita uma query à base de dados na qual são pedidos os elementos “href”, “nome”, “título” e “profundidade”, ordenados por ordem crescente do elemento “sequence”. Os nomes dos SCOs são então dispostos pela ordem indicada, e é-lhes atribuído um link apontado para o valor “href” respectivo retirado da base de dados. A informação do campo “profundidade” permite colocar cada elemento da lista com o avanço adequado para que a apresentação da lista seja consistente com a sua estrutura. A Web Application introduz automaticamente um script na criação da Table of Contents que permite expandir e agrupar as diversas secções do curso. Para isso, utiliza a informação do campo “título” para saber se se trata de um item expansível ou não. Quando o formando clica nalgum elemento da lista, é aberto na frame de visualização o SCO escolhido. Em qualquer altura, o formando pode regressar à janela com as informações sobre o seu desempenho carregando no link “Menu Principal” na frame auxiliar de navegação. A figura 19 apresenta um diagrama de interacções que resume o funcionamento da Web Application:

59

Base de Dados

Página de boas vindas

Welcome.aspx

Registo1.aspx Registo2.aspx

Main.aspx E-Learning.aspx

Toolbar.aspx

Toc.aspx

SCOs

Login:

Password: INFO

Nome:

Morada:

(…)

Nome: João SilvaRegisto Confirmação de registo

Morada: Rua das…

Número: alu009

****Password:

Seleccionecurso: João Silva

Nr: alu009

INFO

• Item 1• Item 2

* Subitem 1(…)

Menu principal do aluno

Página de visualização de SCOs

Figura 19 – Diagrama de interacções da Web Application

Uma funcionalidade muito importante a cargo da Web Application é a autenticação dos utilizadores e a restrição do acesso ao sistema apenas aos utilizadores registados. A tecnologia .NET fornece três funções para garantir a segurança dos sistemas desenvolvidos: Authentication – A autenticação é um processo através do qual se tenta garantir que o utilizador é quem realmente indica ser. O funcionamento do processo de autenticação consiste na obtenção de credenciais do utilizador (vulgarmente um nome e uma password) e validá-las perante uma sistema com autoridade para as validar. Authorization – A Autorização limita o acesso aos recursos do sistema concedendo ou negando permissões a uma entidade autenticada. Impersonation – Esta função permite que a aplicação desenvolvida se comporte de acordo com o perfil do utilizador, apresentando funcionalidades diferentes e concedendo ou negando permissões a diferentes partes da aplicação consoante o perfil do utilizador.

60

Para garantir a segurança do sistema irão ser utilizados apenas as duas primeiras funções descritas. Autenticação

Em .NET existem três formas de fazer a autenticação de um utilizador: Forms Authentication, Passport Authentication e Windows Authentication. O sistema escolhido para o protótipo foi o de forms authentication por ser de aplicação relativamente simples e eficiente. O modo de funcionamento do sistema de Forms Authentication é o seguinte: Quando chega um pedido para aceder a uma página, o sistema detecta se se trata de um utilizador autenticado ou não. Se o utilizador não estiver autenticado ele é redireccionado para uma página com um form HTML utilizando redireccionamento do lado cliente, isto é, é enviada ao browser a ordem de abrir uma nova página. Na página aberta, o utilizador fornece as suas credenciais (username e password) e envia-as para o sistema carregando no botão de Submeter. Se a aplicação autenticar o pedido, o sistema cria um form que contém as credenciais do utilizador e a partir daí, todos os pedidos seguintes são enviados com a informação deste form no cabeçalho e são autenticados e autorizados automaticamente. Depois de autorizado, o utilizador é novamente redireccionado pelo lado cliente para a página que pretendia ver, introduzida inicialmente. Para colocar em funcionamento o método de Forms Authentication é necessário editar o ficheiro de configuração Web.config, escrito em XML. Este ficheiro permite configurar vários aspectos do funcionamento da aplicação tais como o modo de debug, ou editar as mensagens de erro, e permite configurar o funcionamento da Autenticação. A explicação da configuração e o código deste ficheiro encontram-se no fim desta secção. Autorização

A Autorização tem como objectivo determinar quais os utilizadores a quem deve ser dado ou negado o acesso a um dado recurso. Quando se utiliza o método de Forms Authentication para a autenticação, o ambiente .NET utiliza o método URL Authorization para implementar a Autorização. Este método mapeia os utilizadores a secções de endereços URL, ou seja a directórios e páginas de um determinado domínio, conferindo-lhes autorização ou não para visualizarem as páginas mapeadas. Quando é concedido a um utilizador ou grupo de utilizadores o acesso a um determinado directório, a

61

autorização estende-se a todos os sub-directórios a menos que seja explicitamente indicado qual ou quais os sub-directórios ou ficheiros a que não se aplica a autorização. A listagem que se segue apresenta o código do ficheiro Web.config da Web Application desenvolvida no protótipo para ilustrar a utilização dos métodos de Autenticação e de Autorização referidos. <?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.web>

<compilation defaultLanguage="vb" debug="true" />

<customErrors mode="RemoteOnly" />

 <authentication mode="Forms">

<forms loginUrl = "WebForm1.aspx" />

</authentication>

 <authorization>

<deny users="?" />

</authorization>

<sessionState

mode="InProc"

stateConnectionString="tcpip=127.0.0.1:42424"

sqlConnectionString="data source=127.0.0.1;user id=sa;password="

cookieless="false"

timeout="20"

/>

<globalization requestEncoding="utf-8" responseEncoding="utf-8" />

62

</system.web>

 <location path="Registo.aspx">

<system.web>

<authorization>

<allow users="?" />

</authorization>

</system.web>

</location>

<location path="Registo2.aspx">

<system.web>

<authorization>

<allow users="?" />

</authorization>

</system.web>

</location>

</configuration>

63

6. Conclusões Penso que ao longo do estágio consegui atingir os objectivos propostos: aprender a desenvolver aplicações no ambiente Microsoft .NET, estudo da norma SCORM TM e implementação de um protótipo de LMS. O protótipo desenvolvido, funciona correctamente, conseguindo de guardar de forma consistente todas as informações enviadas pelos SCOs e responder aos pedidos solicitados. As limitações do LMS prendem-se sobretudo com o facto de o protótipo implementar apenas uma parte da norma SCORM, quer no modelo de dados, quer no ambiente de Run-Time. Apesar da simplicidade, o LMS construído pode ser facilmente aperfeiçoado e expandido, através da inclusão de novas funções no Web Service e na Web Application e acrescentando os elementos necessários à base de dados. O API Adapter é o único módulo que está completo, disponibilizando aos SCOs todas as funções previstas pela norma SCORM. Relativamente à norma SCORM, as conclusões a retirar são as seguintes: constitui um modelo bastante completo para a construção de um LMS com indicações bastante detalhadas relativamente à construção do Modelo de Dados, à concepção de conteúdos de ensino e ao comportamento do LMS no acompanhamento do desempenho dos alunos. Na realidade o termo Learning Management System têm uma abrangência muito vasta, e numa abordagem mais purista refere-se a um sistema que é capaz de gerir inteiramente o processo de ensino de um formando, não só através da disponibilização de conteúdos de ensino, mas também com a capacidade de acompanhar o progresso do formando e tendo a capacidade de decidir qual ou quais os métodos e recursos que deve apresentar ao formando em cada momento. A norma SCORM está mais vocacionada para a normalização da distribuição de conteúdos de ensino de forma a garantir que os recursos possam ser instalados em qualquer plataforma que respeite a norma. A SCORM tem evoluído rapidamente e está amplamente divulgada a nível mundial prevendo-se que se venha a tornar a norma standard para a partilha de recursos de ensino. Em Portugal são já várias as plataformas de e-Learning disponíveis (na ordem das dezenas) e uma grande parte assegura a compatibilidade com a norma SCORM.

64

7. Referências 7.1. Referências Bibliográficas Microsoft Visual Basic .NET Professional Projects Kuljit Kaur, Pooja Bembey Premier Press Beginning .NET Web Services using Visual Basic .NET Joe Bustos, Karli Watson Wrox Press Ltd. Sharable Content Object Reference Model (SCORM) Version 1.2 Manual Disponível em www.adlnet.org Apontamentos sobre XML do prof. Gabriel David para a cadeira de Sistemas de Informação Disponíveis em www.fe.up.pt/~gtd/sinf/

7.2. Referências URL Advanced JavaScript Tutorial http://hotwired.lycos.com/webmonkey/programming/javascript/index.html Web Service Behavior http://msdn.microsoft.com/library/default.asp?url=/workshop/components/htc/reference/elements/component.asp Working with Web Services http://developer.apple.com/internet/webservices/ie5webservices.html Microsoft QuickStart Tutorials http://samples.gotdotnet.com/quickstart/aspplus/

65

PerfectXML.com http://www.perfectxml.com/XML.asp .NET Framework Developer's Guide http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/netdevanchor.asp

licenciatura em engenharia electrotécnica e de computadoresee95135/relatorio_final.pdf · aluno...

Documents