adaptação de conteúdo para múltiplos contextos - · pdf file3.3.2...

UNIVERSIDADE FEDERAL DE GOIÁSINSTITUTO DE INFORMÁTICA

MARCELO RICARDO QUINTA

Adaptação de conteúdo para múltiploscontextosSistema Odin

Goiânia2011

UNIVERSIDADE FEDERAL DE GOIÁS

INSTITUTO DE INFORMÁTICA

AUTORIZAÇÃO PARA PUBLICAÇÃO DE DISSERTAÇÃO

EM FORMATO ELETRÔNICO

Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto de Infor-mática da Universidade Federal de Goiás – UFG a reproduzir, inclusive em outro formatoou mídia e através de armazenamento permanente ou temporário, bem como a publicar narede mundial de computadores (Internet) e na biblioteca virtual da UFG, entendendo-seos termos “reproduzir” e “publicar” conforme definições dos incisos VI e I, respectiva-mente, do artigo 5o da Lei no 9610/98 de 10/02/1998, a obra abaixo especificada, sem queme seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou publi-cação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgaçãoda produção acadêmica gerada pela Universidade, a partir desta data.

Título: Adaptação de conteúdo para múltiplos contextos – Sistema Odin

Autor(a): Marcelo Ricardo Quinta

Goiânia, 15 de Março de 2011.

Marcelo Ricardo Quinta – Autor

Fábio Nogueira de Lucena – Orientador

MARCELO RICARDO QUINTA

Adaptação de conteúdo para múltiploscontextosSistema Odin

Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emComputação.

Área de concentração: Engenharia de Software.

Orientador: Prof. Fábio Nogueira de Lucena

Goiânia2011

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).

Marcelo Ricardo Quinta

Graduou–se em Ciências da Computação na UFG - Universidade Federal deGoiás. Durante sua graduação, foi estagiário da Exis Serviços e pesquisadordo CNPq em um trabalho de iniciação científica no Instituto de Informática.Durante o Mestrado, também no Instituto de Informática da UFG, foi bolsistaREUNI e acompanhou as disciplinas de Estrutura de Dados I e Estrutura deDados II. Atualmente desenvolve soluções para celulares nas plataformas JavaME, Android e iOS, além de ser professor na UFG e SENAI, instrutor daGlobalcode e gerente de projetos da Triangulum Soluções.

Aos meus pais

Agradecimentos

É difícil agradecer tanta gente em tão pouco espaço, principalmente em umaépoca que tanta gente me ajudou.

Primeiramente, devo agradecer a meu pai e minha mãe, que me deram todo osuporte e educação para que eu chegasse onde estou agora. Mesmo ausente em corpo, oSr. José Divino Quinta está muito presente em minha vida, seja pelos seus ensinamentosou pelo exemplo de batalha de vida e honestidade que ele foi. Para compensar, a DonaMaísa está firme e forte, sempre ao meu lado, dando apoio (e as broncas) que preciso pararealizar bem minhas atividades.

Além dos dois, o pessoal aqui de casa também tem muita contruibuição nessesúltimos dois anos. Palô, Juju, Poli, Clara, Duda, Paty, Sandy, Gaby e Júnior foram muitopacientes, mantendo meu estado emocional melhor, bem como os amigos de curta oulonga data, como o Ramiro, Victor, Artur, Egio e André.

Por falar em estado emocional, a Ana Flávia também merece um parágrafo sópara ela, onde devo agradecer todos os conselhos, ajudas, companheirismo, paciência,complacência e alto astral, me aguentando nos poucos finais de semana que o Mestradome liberava.

Também tive uma família na universidade, onde tive até “filhos”, meus orientan-dos de PFC: Fernando, Lauro, Luiz e Bombeiro. Foi ótima a contribuição deles para meuprojeto, bem como as divertidas conversas com todo pessoal do PEP, principalmente oDanillo. E eu posso bater no peito e dizer que tive um paizão, não só profissionalmente,mas para a vida: Dr. Fábio Nogueira de Lucena. Este professor me entregou (em mãos)meu diploma de graduação, sempre procurou me doutrinar e me arranjar ocupação, dis-posto e dando instruções para o projeto, tecnologias e para a vida em geral. As reuniõesde orientação com o Fábio foram praticamente palestras motivacionais. A cada vez quesaia de sua sala, ficava louco para sentar e produzir algo especial com tantas idéias que elecolocava na minha cabeça. No dia que eu for do nível deste professor, estarei realizadoprofissionalmente.

Ao Edir, devo agradecer todos os atalhos que ele abriu ou me ensinou a pegar,sempre disposto a quebrar um galho, mesmo com um milhão de coisas que tem para fazer.E não posso esquecer da Berê pelas conversas descontraídas à noite e conselhos. Aos

professores Juliano, Plínio e Humberto, agradeço por me mostrarem com seus própriosexemplos o que devo fazer para me tornar também um profissional de renome, como teralto compromisso acadêmico e tecnológico, ética profissional impecável, etc. Um dia euchego lá.

E fico muito feliz, não só por passar vários dias com amigos como a Sofia,Carine, Leandro, Thiago, Adriana, Enio, Luis Loja, Dedé, Alex e o Fera, mas por dividirnoites mal dormidas programando com o Daniel Pateta, a encarnação do Alan Turing.Sem contar a dupla dinâmica, Pat e Bia, que vão ser minhas irmãzinhas do laboratóriopara o resto da vida, não importa se elas se escondem no meio do Mato ou não.

Não fiz todo o trabalho sozinho. Certas pessoas contribuiram de diferentesformas, como a Anna Trifonova, que me liberou alguns artigos pagos (e caros), o MarcosRoriz, que me ajudou com os ClassLoader do Java e a profa. Rose da UFSM, que deuidéias interessantíssimas que fizeram o Odin se tornar algo melhor.

Ao final, agradeço meus avaliadores, professor Dr. Hans e professor Dr. Ed-mundo pela paciência de ler meu trabalho e fazer tantas contribuições, além do pessoaldos grupos de usuário os quais pertenço, principalmente os do GoJava (Raphael, Flávia eFilipe) e DFJug (Daniel de Oliveira), que sempre tinham críticas construtivas e elogios aomeu produto.

“Não há problema no fato do seu alvo estar no alto se você tem bastantemunição.”

Hawley R. Everhart,.

Resumo

Ricardo Quinta, Marcelo. Adaptação de conteúdo para múltiplos contextos.Goiânia, 2011. 127p. Dissertação de Mestrado. Instituto de Informática, Univer-sidade Federal de Goiás.

O aumento da popularidade do emprego de tecnologias móveis para acesso a internetviabiliza o acesso a conteúdo educacional por qualquer pessoa, em qualquer lugar, emqualquer instante. Contudo, usufruir desta flexibilidade exige esforço considerável, pois oresponsável pelo conteúdo deve produzir não apenas uma versão do material, mas tantasquanto o número de dispositivos diferentes empregados.O presente trabalho discute o suporte à adaptação de conteúdo nas ferramentas de ensinoa distância atuais, os problemas associados ao emprego de diferentes dispositivos paraacesso a conteúdo educacional e apresenta a solução Odin. O Odin oferece transparênciana adaptação automática de áudio, vídeo, imagens e texto para emprego adequado doconteúdo adaptado para diferentes dispositivos, suporte ao SCORM e pode ser visto comoextensão em servidores de aplicações para ensino a distância.

Palavras–chave

adaptação de conteúdo, e-learning, m-learning, u-learning

Abstract

Ricardo Quinta, Marcelo. <Content adaptation to multiple contexts>. Goiânia,2011. 127p. MSc. Dissertation. Instituto de Informática, Universidade Federalde Goiás.

The mobile technology The increasing of mobile technology usage popularity for internetaccess enables educational content access in anyplace, anytime. However, the use of thisflexibility requires considerable effort, because the content sponsor must produce not justone material version, but as many ones as the number of different devices used.This work discusses the content adaptation support in actual learning management sys-tems, the problems associated with the use of different devices to access educational con-tent and presents Odin. The Odin solution offers transparency on automatic adaptationof audio, video image ant text for suitable adhibition of adapted content in different ma-chines, SCORM support and can be described as an extension in learning managementsystems application servers.

Keywords

content adaptation, e-learning, m-learning, u-learning

Sumário

Lista de Figuras 14

1 Introdução 161.1 Problema 171.2 Proposta: Odin 171.3 Método de trabalho 181.4 Organização do trabalho 18

2 O ensino a distância apoiado pela tecnologia 202.1 Introdução 202.2 E-learning 202.3 M-learning 22

2.3.1 Trabalhos relacionados 242.4 T-learning 26

2.4.1 Trabalhos relacionados 272.5 U-learning 28

2.5.1 Trabalhos relacionados 312.6 Contextualização do Odin 32

3 Conteúdo instrucional em e-learning 333.1 Introdução 333.2 Objetos de Aprendizagem 333.3 Padronização para objetos de aprendizagem 34

3.3.1 LOM 363.3.2 IMS 363.3.3 SCORM 39

3.4 Ferramentas para construção de objetos de aprendizagem 413.5 Diretivas para criação de objetos de aprendizagem 423.6 Desafios para criação de objetos de aprendizagem em u-learning 44

3.6.1 Desafios pedagógicos 44Resistência à adoção de novas tecnologias 45Resistência à adoção de novas práticas de aprendizagem 45Tempo de resposta do aluno reduzido 45Entendimento do contexto 45Prender a atenção dos estudantes e concorrência com outras fontes 46

3.6.2 Desafios tecnológicos 46Limitações de tamanho de tela 46Limitações de cores 47

Limitações de dispositivos de interação 47Limitações de processamento 48Limitações de memória 48Capacidade de armazenamento limitada 49Limitações de bateria 49Tempo de resposta 49Limitações de software 49Largura de banda e disponibilidade de internet 50Preço de planos de dados 50Rápida obsolescência dos dispositivos 50

3.7 Contextualização do Odin 51

4 Adaptação de conteúdo 524.1 Introdução 524.2 Motivação 524.3 Descoberta de contexto (Para) 53

4.3.1 Cabeçalhos HTTP 544.3.2 Parâmetros de requisição 554.3.3 Composite capabilities / Preferences Profile(CC/PP) 554.3.4 User Agent Profile (UAProf) 554.3.5 Media queries 574.3.6 Synchronized Multimedia Integration Language (SMIL) 574.3.7 MPEG-21 57

4.4 Locais de adaptação (Onde) 584.4.1 Servidor 584.4.2 Cliente 584.4.3 Proxy 59

4.5 Tipos de adaptação (Quando) 594.5.1 Estática 594.5.2 Dinâmica 594.5.3 Híbrida 60

4.6 Seleção de conteúdo (O que) 604.7 Forma de adaptação (Como) 61

4.7.1 Escala 614.7.2 Mudança de formato 614.7.3 Mudança de modo 61

4.8 Trabalhos relacionados 624.9 Contextualização do Odin 63

5 Odin : Viabilização de e-learning em múltiplos dispositivos 645.1 Introdução 645.2 Requisitos 645.3 Arquitetura do sistema 74

5.3.1 Atendimento web 75Interface gráfica 75Requisições web 76

5.3.2 Serviços Administrativos 76Controle de acesso 76

Preferências do sistema 765.3.3 Gerência de conteúdo 76

Download 76Upload 77

5.3.4 Adaptação 78Descoberta de contexto 78Contextos e perfis 79Configurações de mídia 79Adaptação 79Conversores 80

5.3.5 Gerência de recursos de objetos de aprendizagem 805.3.6 Tecnologias 80

Java 80WURFL 81WebServices 81

5.4 Implementação 825.4.1 O ambiente de desenvolvimento 83

6 Considerações finais 846.1 Conclusão 846.2 Resultados e contribuições 846.3 Trabalhos Futuros 86

Referências Bibliográficas 87

A Requisitos do Sistema Odin 98A.1 Introdução 98

A.1.1 Propósito 98A.1.2 Necessidades 98A.1.3 Escopo 98A.1.4 Definições, acrônimos e abreviações 99A.1.5 Organização do documento 100

A.2 Descrição geral 100A.2.1 Perspectiva do produto 100A.2.2 Interfaces do sistema 101A.2.3 Interfaces de usuário 102A.2.4 Interfaces de hardware 102A.2.5 Interfaces de software 102A.2.6 Interfaces do comunicação 102A.2.7 Requisitos de adaptação ao local de implantação 102A.2.8 Operações 102A.2.9 Funções do Odin 102A.2.10 Características e papéis dos usuários 103

Administrador 103Desenvolvedor de LMS 103Professor 103Aluno 103Conteudista 104

A.2.11 Restrições 104A.2.12 Suposições e dependências 104

A.3 Requisitos específicos 104A.3.1 Requisitos de interfaces externas 104

Interfaces de hardware 104Interfaces de software 104

A.3.2 Características do sistema 104Objetos de aprendizagem 105Contextos e perfis 105Configurações de mídia 106Conversor 107Adaptação 107Controle de acesso 109Download transparente 109

A.3.3 Atributos de software (Requisitos não funcionais) 110Funcionalidade::Adequação 110Funcionalidade::Acurácia 110Funcionalidade::Segurança 110Funcionalidade::Interoperabilidade 111Funcionalidade::Conformidade 111Funcionalidade::Recuperabilidade 111Usabilidade::apreensibilidade 111Eficiência 111Manutenibilidade 111Portabilidade :: Adaptabilidade 111Portabilidade :: Instalação 112Portabilidade :: Conformidade 112

A.3.4 Outros requisitos 112

B Arquitetura do Sistema Odin 113B.1 Visão geral 113

B.1.1 Propósito 113B.1.2 Escopo 113B.1.3 Representação utilizada 114B.1.4 Referências 114B.1.5 Glossário 114B.1.6 Interessados e interesses 114

B.2 Visões identificadas 115B.2.1 Visão de prateleira 115

Interface gráfica 116Serviços Web 116

B.2.2 Visão do usuário 116B.2.3 Visão do comprador 117B.2.4 Visão do administrador 118B.2.5 Visão lógica 119

Objetos de aprendizagem 121Configurações de mídia 121

Controle de usuários 122Conversor 122Contextos e perfis 123Adaptações de objeto de aprendizagem 124

B.2.6 Visão de implantação 124B.2.7 Visão de processos 125B.2.8 Visão de camadas 126

B.3 Tecnologias 127

Lista de Figuras

2.1 A relação entre os modelos de ensino. Todos usam e-learning. 212.2 A evolução do paradigma do uso de dispositivos pelos usuários. 282.3 O u-learning propõe integrar todas as modalidades do e-learning. 292.4 Componentes do Acesso Universal. Figura adaptada de [125] 30

3.1 A configuração básica de um objeto de aprendizagem: Uma breve descri-ção, seus metadados e seu conteúdo. 35

3.2 Grafo de referência entre os padrões citados nesse trabalho e projetosanteriores, adaptada de [92]. 35

3.3 Representação gráfica de metadados de um objeto de aprendizagem [9]. 373.4 Esquema que representa a estrutura de um pacote padronizado segundo

o IMS-LD [68]. 383.5 Representação do SCORM, seu conjunto de especificações e suas refe-

rências. 403.6 Exemplo de tela do Respondus na criação de um teste do tipo “Algoritmo". 423.7 Diferentes dispositivos possuem diferentes resoluções de tela, com dife-

rentes necessidades. 473.8 Teclado virtual para celulares Android e teclado Bluetooth, respectivamente. 48

4.1 Exemplo de fluxo entrega de conteúdo para um celular, um dos contextosexistentes. 53

4.2 Trecho de exemplo de definição de características compatíveis com o CC/PP. 564.3 Exemplo de customização via descoberta do contexto no CSS. 57

5.1 Classificações dos atores quanto a seu uso da solução Odin. 665.2 Pacotes de componentes da solução Odin. 755.3 Em destaque roxo, as funções do componente de requisição que são

utilizados no download. 775.4 Hachuradas, destacam-se as funções do componente de gravação que

são utilizados no upload. 785.5 Processo de adaptação de objeto de aprendizagem 795.6 Grafo de dependência dos projetos. 82

A.1 Cenário possível, onde duas interfaces distintas, de usuário e de outrossistemas, podem explorar o sistema. 100

A.2 Principais componentes lógicos do Odin. 101

B.1 Visão de prateleira do sistema Odin. 116B.2 Visão do usuário do sistema Odin. 117B.3 Visão do comprador do sistema Odin. 117

B.4 Modelo de domínio do sistema Odin. 120B.5 Classes de domínio de objetos de aprendizagem e algumas classes de

serviço. 121B.6 Classes de domínio de configurações de mídia. 121B.7 Classes de domínio de usuários e alguns detalhes de sua classe de

serviços. 122B.8 Classes de domínio de conversores de arquivos, juntamente com um

exemplo de classe de serviços. 122B.9 Classes de domínio de contextos e perfis, juntamente com um exemplo

de classe de serviços de descoberta de contexto. 123B.10 Classes de domínio de adaptações de objetos de aprendizagem. 124B.11 Nós da visão de implantação, com seus componentes. 125B.12 Visão de processos, mostrando cada uma das quatro threads. 126B.13 Visão de camadas do Odin. 126

CAPÍTULO 1Introdução

Segundo pesquisas de mercado no Brasil [64], só na área de TI há um déficitde pelo menos setenta mil profissionais. Em Goiás, mais da metade dos profissionais ematuação na produção de software não possui curso superior completo. A expectativa é deque uma melhor e mais abundante qualificação acessível aos interessados na área possarepercutir positivamente nas empresas locais.

Tanto para aqueles que já estão empregados e desejam se qualificar quanto paraaqueles distantes, o ensino a distância torna-se uma alternativa promissora. Para viabilizá-lo é necessário a disponibilidade de recursos educacionais, o que inclui o conteúdopropriamente dito e a correspondente formatação para ser explorado remotamente.

Como a internet vem sendo acessada cada vez mais por dispositivos diferentesde laptops ou computadores de mesa convencionais, como aparelhos celulares, PDA’s(Personal Digital Assistant - Assistente Pessoal Digital), dispositivos móveis (portáteis ouembarcados) e settop-boxes de TV digital, acredita-se que esse conjunto maior de opçõesofereça uma flexibilidade que ajude a tratar cada usuário potencial de forma adequada,inclusive promovendo a acessibilidade.

Contexto é qualquer informação que pode ser utilizada para identificar ou des-crever um dispositivo ou situação que um cliente do sistema. Várias soluções não dãosuporte à heterogeneidade de contextos de alunos, mas pretendem aproveitar essa novarealidade para suplementar as tecnologias de ensino existentes, com o intuito de atingirmais estudantes por meio da oferta de oportunidades adicionais de interação fora da salade aula, em “qualquer hora e lugar”, através de dispositivos inteligentes. Tal característicaé denominada u-learning, que engloba, inclusive, a integração entre o e-learning conven-cional e o apoiado por dispositivos móveis (m-learning) e TV (t-learning).

Com muitas especificidades nos contextos somadas ao fato dos dispositivospoderem estar em diferentes ambientes e a realidade da maioria dos conteúdos na redeestar projetada somente para computadores de mesa [125], o uso desses aparelhos setorna mais difícil nas instituições de ensino. Certos serviços são atualmente inviáveis nosdispositivos móveis, como o whiteboard. Porém, adaptações podem ser feitas em muitoscasos e até novas funcionalidades podem ser inseridas [116].

1.1 Problema 17

1.1 Problema

Conforme ressaltado em [43], ao mesmo tempo em que o uso de dispositivosmóveis na educação é inovador, ele traz inúmeros obstáculos a serem vencidos pelosambientes de ensino. Cabe às plataformas prover soluções em cada uma dos problemaspara que os alunos tenham a oportunidade de utilizar os aparelhos, usufruam mais dosrecursos existentes e tenham experiências que tornem suas formações mais completas.Atualmente, tal suporte é restrito. Como visto em [96], existem muitas funcionalidadesainda não cobertas pelos atuais sistemas de gestão de aprendizagem (LMS).

Analisando os vários desafios (Seção 3.6) que ainda devem ser enfrentados naárea de u-learning, percebemos que um dos mais importantes é o da facilitação da en-trega de conteúdo adaptado para diferentes usuários com diferentes aptidões, definidocomo Acesso universal [125]. Isso inclui a criação do objeto de aprendizagem (LO) pro-priamente dita e a correspondente personalização para cada meio empregado. A criaçãode conteúdo já é parte do processo comum do trabalho de professores. Contudo, a perso-nalização para vários contextos exige habilidades, conhecimento e esforço significativos.Cada aparelho possui peculiaridades que devem ser conhecidas e empregadas correta-mente no processo de criação do LO adaptado. O professor pode consumir tempo valiosono processo de personalização e ainda corre o risco de produzir LOs de baixa qualidade.

1.2 Proposta: Odin

O objetivo final deste trabalho é a definição e a construção de um protótipoque permita que sistemas existentes para e-learning atinjam mais alunos, de forma maisapropriada e com eficiência, tanto para o aluno quanto para o professor. Logo, o usode novos dispositivos tidos como promissores para o ensino, como o Televisor Digital esmartphones, seria facilitado.

O Odin é a denominação do protótipo para adaptação de conteúdo educacionalpara diferentes dispositivos, que funciona através da conversão de arquivos via agente hu-mano ou computacional. É oferecido como serviço a ser utilizado pelas plataformas deensino existentes (proxy para a base de dados de objetos educacionais). Seu objetivo é ofe-recer transparência tanto na conversão de arquivos para vários dispositivos, desonerandoo professor/conteudista de conhecer o processo da criação de cada uma das personaliza-ções, quanto no download de objetos educacionais adaptados, tornando a experiência dou-learning para o aluno mais agradável.

Em tempo, Odin é nome do deus nórdico da sabedoria e organizador da Terra(retirando-a do caos), que observava todos os mundos e nunca errava um golpe com sualança [69].

1.3 Método de trabalho 18

1.3 Método de trabalho

Para o desenvolvimento do presente trabalho, as seguintes atividades foramexecutadas, não exatamente na ordem abaixo:

• Levantamento da bibliografia - Foram empregados cerca de oitenta artigos sobree-learning, caracterização de sistemas para e-learning, análise de funcionalidadesde sistemas para e-learning, m-learning, sistemas para m-learning, u-learning,sistemas para u-learning, tecnologias para adaptação de conteúdo, arquiteturas parasistemas móveis e ubíquos, conversão de arquivos e protocolos para descobertade contexto. Tais referências bibliográficas foram obtidas através de consultas emportais de periódicos e conferências e são utilizadas por todo o trabalho paraembasar a argumentação.

• Análise de requisitos - A definição do escopo, requisitos funcionais e não-funcionais, casos de uso e algumas restrições de projeto foram identificados e re-gistrados. Ao final dessa atividade, obteve-se um produto principal: a Especificaçãode Requisitos do Sistema Odin, presente no Apêndice A.

• Definição de arquitetura - A elaboração da arquitetura de software do sistemapartiu do momento posterior ao fechamento de escopo da aplicação. Foram elabo-rados diagramas segundo as visões arquiteturais consideradas necessárias para oentendimento da aplicação, havendo muitos refinamentos durante todo o períodode desenvolvimento do Odin. Nessa fase foram escolhidas as tecnologias a seremutilizadas na implementação do protótipo. Ao final dessa atividade, obteve-se umproduto principal: a Arquitetura de Software do Sistema Odin, presente no Apên-dice B.

• Implementação do protótipo - A Especificação de requisitos e a Arquitetura dosistema serviram de insumos para a construção do serviço que oferece todas asfuncionalidades necessárias na solução, com persistência de dados e acesso viainternet.

• Testes do protótipo - As funcionalidades foram testadas tanto nos dispositivos alvocomo em emuladores de dispositivos e contextos, em computadores de mesa.

1.4 Organização do trabalho

Este trabalho foi organizado na mesma sequência que o estudo foi realizado.No Capítulo 2, há uma introdução ao assunto do e-learning, com as definições de

suas vertentes (m-learning, t-learning e u-learning), relacionando o assunto com trabalhosimportantes da área e a relação de alguns deles com o Odin.

1.4 Organização do trabalho 19

No Capítulo 3, a temática da produção de objetos de aprendizagem e os desafiosrelacionados à produção de conteúdo são atacados, abordando também possíveis soluçõese o uso de padrões para reutilização de material.

O Capítulo 4 aborda a adaptação de conteúdo nos materiais didáticos e comopode ser montada a arquitetura de aplicações voltadas a resolver tal problema, relacio-nando os conceitos e trabalhos existentes com o Odin.

O Capítulo 5 apresenta os requisitos, a arquitetura e a implementação do Odin.É importante destacar que os anexos A (Especificação de Requisitos do Odin) e B(Arquitetura de Software do Odin) complementam as informações deste capítulo.

Finalmente, o Capítulo 6 apresenta as considerações finais, com a conclusão,resultados, contribuições e trabalhos futuros.

CAPÍTULO 2O ensino a distância apoiado pela tecnologia

2.1 Introdução

O Odin é um sistema de adaptação de conteúdo voltada ao ensino a distânciacom diferentes contextos. Logo, esse capítulo contém uma introdução aos conceitosfundamentais relacionados ao e-learning e algumas de suas sub-modalidades, com suasdefinições, potencialidades e os principais trabalhos relacionados. O entendimento destestermos é de importância para os capítulos seguintes.

Ao final deste capítulo, o Odin é contextualizado dentro da área aqui descrita,ilustrando os problemas que ele deseja ajudar a resolver.

2.2 E-learning

Segundo [52, 28, 53], “e-learning é o processo de ensino norteado pela interaçãocom conteúdo, serviço ou suporte tecnológico”. Ele envolve intensivo uso de tecnologiade informação e comunicação para servir, facilitar e favorecer o processo de ensino [77],visto que pode ser aplicado aos três modelos de ensino existentes: educação tradicional,educação à distância e ensino misto (blended-learning).

O ensino tradicional é o mais antigo, mais aplicado e tido como a primeira emelhor opção. Ele é definido como aquele realizado com espaço físico e tempo definidos,onde um professor realiza atividades a um grupo de estudantes [55]. Nele, o e-learning

pode ser percebido quando, por exemplo, o professor utiliza computador e projetor paramostrar conteúdo aos alunos.

O ensino à distância é reconhecido como segunda melhor opção porque nele émais difícil trabalhar com as diferenças. Nele, alunos e professor(es) estão separados pordistância física, temporal ou de recursos [52]. A principal diferença deste com o ensinotradicional é que ele pode ser realizado tanto por processo síncrono como por processoassíncrono. Os alunos podem até estar juntos, em uma sala de aula, assistindo material,

2.2 E-learning 21

enquanto o professor pode estar em outra posição geográfica. Nesse caso, é importantedestacar que o docente também pode ser chamado pela alcunha de facilitador.

Até os anos 60, a única forma conhecida para tal modalidade de ensino era acorrespondência, podendo cobrir até 50% dos treinamentos [70]. Mas tal realidade foimudando de acordo com a popularização dos computadores. Hoje é difícil pensarmos emensino à distância sem o uso do e-learning na internet, o que pode ser percebido, porexemplo, em discussões dentro de um fórum virtual.

Finalmente, o ensino misto é aquele que mescla ensino tradicional com e-

learning [52]. O e-learning pode ser percebido tanto em sala de aula como em atividadesrealizadas em outra hora e local, como na execução de uma avaliação via internet.

Figura 2.1: A relação entre os modelos de ensino. Todos usam e-learning.

Este trabalho faz uso de e-learning através de todos os modelos de ensino, masfoca principalmente no ensino à distância com o uso da internet, o qual é mais evidentee popular. Existem mais de um milhão de cursos online [108], que ocorrem porque oe-learning traz benefícios, como:

• Rápida atualização dos conteúdos - Em certas áreas, o conteúdo pode mudar como tempo, devendo haver atualização constante. Além disso, em certos momentoso professor pode ter a intenção de mudar ou adicionar um conteúdo que queiraque os alunos vejam o mais cedo possível. Nesses casos, sistemas de e-learning

possibilitam que o profissional coloque seu material online e este pode ser acessadoquase instantaneamente por seus alunos, através da internet.

• Acompanhamento facilitado do aluno - O acompanhamento online do alunofacilita o entendimento das dificuldades do aluno por parte do facilitador, poisgeralmente são oferecidas diversos serviços úteis, como disponibilização tempode uso do sistema pelo estudante, relatórios de atividade dos discentes, correção

2.3 M-learning 22

automática de atividades e avisos automáticos para eventos durante o curso. Alémdisso, o conteúdo pode ficar disponível 24 horas por dia, inclusive aos fins desemana.

• Personalização - Nem todos aprendem da mesma forma, no mesmo lugar etêm a mesma cultura. Como os sistemas de e-learning permitem que os alunospersonalizem suas preferências, há mais centralização de tudo para que o professorpossa transmitir um só conteúdo e esse possa ser visto de acordo com o gosto decada estudante. Porém, é importante destacar que pode ser mais difícil trabalharcom as diferenças.

Porém, o e-learning não é a “bala-de-prata” da educação. Ainda existem algumasdesvantagens de sua aplicação na educação à distância, das quais podemos destacar:

• Dificuldades na adaptação ao modelo de ensino - Muitas pessoas ainda têmdificuldade na operação de computadores. Outras pessoas já têm dificuldade deadequar-se ao modelo de ensino à distância, diferente das salas de aula tradicionais.Nesse sentido, o e-learning pode se tornar uma alternativa que não resulte em bonsresultados pedagógicos caso não seja aplicado em um ambiente que ofereça ascondições favoráveis ou seja uma tentativa de uma simples transposição.

• Falta de desenvolvimento da socialização do aluno - Com o ensino à distância,os alunos geralmente estão sozinhos e só interagem via computador. Críticas feitassobre esse modelo é que ele não exercita as interações humanas de forma eficiente(como falar em público) e que a solidão pode provocar a evasão.

A adoção de um sistema que não atenda aos requisitos de alunos, professo-res/facilitadores e gestores da instituição pode arruinar um curso [78]. De acordo com[123], as organizações funcionam mais efetivamente quando suas redes sociais e tecno-lógicas são compatíveis. Assim, a escolha do software a ser utilizado é importante parao sucesso de uma instituição de ensino que queira aplicar e-learning. Isso depende doconhecimento da equipe de TI em identificar os reais requisitos dos interessados e dasopções existentes, que devem se adequar dentro das atividades a serem realizadas.

2.3 M-learning

Existem de 5 a 10 vezes mais celulares do que computadores de mesa no mundo[95], perfazendo mais de 5 bilhões de dispositivos móveis [66]. Desses aparelhos, estácrescendo a porcentagem do suporte a softwares mais poderosos, como as de suite

de escritório e visualização de imagens e vídeo. Pensando nisso, podemos utilizar atecnologia móvel para suplementar as tecnologias de ensino existentes, de forma a ter

2.3 M-learning 23

mais chance de atingir um domínio maior de usuários, mais rapidamente e gastandomenos, por vários aparelhos e terrenos.

O mobile learning (m-learning) é caracterizado pela maioria dos autores comoo uso de dispositivos móveis e ligados à rede sem fio sejam eles notebooks, tablets,pdas, celulares comuns, smartphones ou qualquer outra máquina que seja não obstrutivao suficiente para ser carregada com facilidade no dia-a-dia. Outros autores, como Orr [90]e Georgiev [55], caracterizam o m-learning não como o uso de dispositivos móveis noe-learning, mas a constante mudança entre esses aparelhos e do estudante.

A aplicação do m-learning já está presente em vários campos do ensino, sendoconsiderada de muita utilidade principalmente para pessoas que trabalham em constantemovimento ou em locais onde o uso de um desktop não é sempre viável (zona rural) [129].Para isso, eles podem usar as funcionalidades de conexão dos aparelhos (GSM, CDMA,WAP, 3G, etc) para acessar diferentes módulos de ensino, via SMS (Short Message

Service), recursos visuais (vídeo, imagens, texto) e sonoros (áudio, chat), dentre outros.Em relação às vantagens tecnológicas do m-learning em relação ao e-learning

convencional, podemos citar:

• Facilitação da mobilidade no ensino, pelo peso e tamanho reduzidos;• A maioria dos dispositivos móveis tem menor preço do que os computadores de

mesa;• Baseado em tecnologias modernas, as quais já estão inseridas nas vidas dos estu-

dantes;• Possibilidade de realização de novas experiências através de funcionalidades dos

dipositivos móveis, como telas multi-toque;• Dispositivos móveis gastam menos energia que computadores comuns, colaborando

com o meio ambiente e gastando menos com contas de luz;

Em relação às vantagens pedagógicas do m-learning em relação ao e-learning


• O ensino passa a ser mais personalizado, centrado no usuário e pode envolversituações reais, de campo;

• Aumento da possibilidade de comunicação professor-aluno, visto que dispositivosmóveis possuem maior disponibilidade.

Porém, o m-learning ainda é um campo novo e possui alguns desafios, dos quaisalguns requerem soluções ainda não existentes:

• Dispositivos móveis não têm a capacidade de ser o único ponto de acesso ao ensino[95]. Alguns serviços são atualmente inviáveis [116], como o whiteboard;

2.3 M-learning 24

• Ausência de métodos pedagógicos voltados especificamente à aprendizagem mó-vel;

• Novas normas e padrões éticos terão que ser estabelecidos para o uso de tecnologiasdentro da sala de aula;

• Falta de compatibilidade da informação com o dispositivo que a acessa;• A maioria das aplicações são standalone [56], ou seja, são executadas no dispositivo

móvel e não ligadas a um sistema de gerenciamento (servidor).• Diversidade em termos de plataforma.

Trata-se de um campo promissor, mas que ainda possui problemas, que deman-dam soluções tanto pedagógicas quanto tecnológicas.

2.3.1 Trabalhos relacionados

Existem trabalhos nacionais e internacionais que exploraram o mobile learning,seja na criação de novas soluções ou na definição de conceitos sobre o tema. Destes,podemos destacar alguns casos:

1. Sharples et. al [109] apresentaram várias questões teóricas, tecnológicas e princi-palmente pedagógicas sobre m-learning, seus potenciais e limitações, sua relaçãocom convergência digital e um framework que conecta os elementos de ensino ne-cessários para a provisão do serviço móvel.

2. Georgiev et. al [55] discutiram o impacto da adoção de dispositivo móveis noe-learning, principalmente por causa das novas tecnologias que tais aparelhospodem oferecer. Para as muitas restrições tecnológicas existentes, foram citadassoluções. Porém, quanto ao paradigma educacional, recomendou-se que estudantese professores devem se adequar a essa nova realidade.

3. Orr [90] fez uma revisão das teorias de ensino existentes, provando que o m-

learning pode ser compatível com todas elas. Além disso, revelou alguns problemasainda existentes na área, no ano de 2010, devido a diversos desafios aos desenvol-vedores de objetos de aprendizagem para dispositivos móveis.

4. Grasso e Roselli [58] relatam algumas experiências da Universidade de Bari (Itália)no campo de projeto de conteúdo para mobile learning que culminaram na definiçãode diretrizes para desenvolvimento de recursos para dispositivos móveis. Taisdiretrizes foram usadas na aplicação, com sucesso, em um curso dentro do sistemade ensino à distância da instituição.

5. Georgieva [56] fez uma análise comparativa entre as funcionalidades oferecidas pe-los sistemas de ensino móvel desenvolvidos pela academia e mercado, verificandoa diferença entre eles e tendências futuras.

2.3 M-learning 25

6. Wains e Mahmood [120] investigaram a viabilidade do uso de tecnologia móvelno treinamento à distância, propondo uma arquitetura de integração entre aplica-ções de e-learning já existentes com novas soluções de m-learning. A validaçãoocorreu através de um curso dado em uma universidade do Paquistão. Porém, foiconcluído que um dos maiores desafios ao ensino móvel é a adaptação dos recursoseducacionais, do computador de mesa para os celulares.

7. Sharma e Kitchens [108] apresentam um método de exploração de m-learning

através do uso de Web Services 1, que podem ser acessados por qualquer aplicaçãoque consiga trocar mensagens via protocolo Hypertext Transfer Protocol (HTTP),ou seja, a maioria absoluta das aplicações da internet.

8. Zagar et. al [128] apresentou um caso de ensino e prática de Engenharia deSoftware através de dispositivos móveis, aplicado também em cenário real dedesenvolvimento de instituições na Croácia e Suécia.

9. Cruz et. al [35] apresentou um estudo sobre inclusão digital e implementação dem-learning no ensino de matemática, com construção de objetos de aprendizagempadronizados de acordo com normas internacionais. O projeto foi avaliado comsucesso pelos alunos, mas cita que “os dispositivos móveis podem evoluir parapoder propiciar a mobilidade por completo na educação”.

10. Oliveira e Medina [43] apresentaram um levantamento sobre o estado atual do de-senvolvimento do m-learning no Brasil, além de uma plataforma de desenvolvi-mento de objetos de aprendizagem para esse ambiente, baseada na tecnologia FlashLite. Foi também relatado que ainda há falta de referências relativas à desafios aodesenvolvimento dos materiais.

11. Ribeiro et. al [36] analisou a aplicação de m-learning através da solução MLE-Moodle, componente do Moodle, sistema de gerenciamento mais utilizado em e-

learning. Ao final, tal software foi bem avaliado pelos alunos, que o consideraramum incentivador no ensino e com muita utilidade na aprendizagem.

12. Lobato et. al [81] construíram e apresentaram o Amadeus-MM, um componentemóvel do software Amadeus, software brasileiro que se propõe a oferecer serviçostanto para web quanto para celulares, com diferentes funcionalidades em cada. Oprojeto Amadeus está hospedado no Portal do Software Público Brasileiro [13].

13. Zanella et. al [129] apresentaram um estudo exploratório do m-learning sobre 31casos práticos no Brasil, realizando pesquisa sobre percepções nas instituiçõesnacionais, principalmente em nível organizacional. Os resultados mostraram quetal modalidade de ensino vem sendo aplicada de forma experimental no ambiente

1WebServices é uma maneira padronizada para comunicação entre sistemas que trabalha através detrocas de mensagens pela internet via protocolo definido, geralmente por XML

2.4 T-learning 26

acadêmico, com raras aplicações no mercado. Segundo os próprios profissionais,isso se deve a vários desafios ainda não resolvidos, que fomentam a pesquisa naárea.

2.4 T-learning

A distribuição irregular de acesso à tecnologia no Brasil é visível quandocomparamos o uso da TV e o uso de computadores de mesa comuns. Enquanto cercade 20% da população tem acesso a internet, mais de 98% dos brasileiros tem acesso à TVconvencional.

Com o advento da TV Digital, o televisor passou a se tornar não só um aparelhode radiodifusão convencional, mas um sistema com mais características. Essas caracterís-ticas estão relacionadas à capacidade de execução de aplicativos e a interatividade propor-cionada ao usuário, que pode ser local ou utilizando de um canal de retorno (parcialmenteou totalmente), que pode ser inclusive através de ligação a um servidor na internet. Assim,a TV, hoje, pode realizar algumas tarefas que o computador realiza.

O televisor já foi alvo da EAD, citados posteriomente, mas com a impossibili-dade de comunicação entre o aluno e o professor, os cursos desses projetos são executadosem uma via de mão única, no sentido do professor para o aluno, sem haver uma formade retorno eficaz. Com a TV Digital, podemos oferecer novas experiências de ensino adistância, fazendo que esse aparelhos possa se tornar alvo de possíveis soluções em e-

learning [112]. Tal modelo de ensino é denominado t-learning.Obviamente, ajustes devem ser realizados quanto se pretende mover recursos

pedagógicos da web comum para a televisão. A TV Digital, apesar de ter a capacidade deexecutar aplicativos, não oferece todos os recursos de um computador. Por isso os LOsdevem ser implementados de acordo com os recursos específicos dos receptores da TVDigital.

Apesar de todo o conjunto de avanços tecnológicos realizados, principalmentena telecomunicação, é importante voltarmos nossos olhos para realidade brasileira. Porisso, o governo federal buscou as melhores tecnologias aplicáveis à TV aberta e lançou oprojeto Sistema Brasileiro de Televisão Digital (SBTVD), observando não só a definiçãode um padrão, mas também os custos para o usuário e produção do conteúdo, inclusãodigital. Depois de anos de discussão, foi lançada a norma, implementada pelo middleware

Ginga, ainda não adotado completamente pelo mercado.O Ginga é um produto concebido com tecnologia nacional, sendo composto por

dois ambientes: Ginga-J (programação procedural) e Ginga-NCL (programação declara-tiva). O middleware adotou a técnica do H.264, mais conhecida como MPEG-4, que apre-senta maior eficácia do que aqueles em vigência em outros países. Além dessa qualidade

2.4 T-learning 27

de imagem, outro grande diferencial da tecnologia do Sistema Brasileiro de TV Digital éa possibilidade de poder ser transmitida tanto para set-top boxes quanto para alguns apa-relhos móveis, o que torna a TV presente em vários locais. Logo, o ambiente brasileiro ébem favorável para o desenvolvimento de soluções em ensino. Basta adaptá-las ao públicoalvo.

Das vantagens e desafios tecnológicos do t-learning em relação ao e-learning


• A tecnologia de televisão digital dá suporte a execução de recursos gráficos de altaqualidade;

• Devido às três formas de interação promovidas pelo Ginga (local, intermitente eplena), existem muitas possibilidades de se aproveitar as aplicações;

• O desenvolvedor de objetos de aprendizagem para TV Digital deve conhecer bem omiddleware e entender os problemas da concorrência do seu material com o passadopelas emissoras;

• O ano de 2010 fechou com as pesquisas na área tendo muita dificuldade emtrabalhar com canal de retorno das emissoras. Tal módulo ainda não foi terminadopela equipe do Ginga.

Em relação às vantagens e desafios pedagógicos do t-learning, podemos citar:

• Como a TV é controlada por um controle remoto, o mecanismo de interação éelementar e não aplica-se objetos de aprendizagem complexos.

• A TV Digital é uma tecnologia com tamanho diferente do convencional. Geral-mente as pessoas assistem TV longe do aparelho (cerca de 3 metros) e em grupo.Construir material com boa resolução e que possa prender atenção de todos não ésimples.


Ultimamente, trabalhos vem alardeando que o t-learning via TV digital comosolução milagrosa para os problemas enfrentados [23], mas nem todos os trabalhos daárea vêem dessa forma. Pode-se melhorar. Para isso, pesquisas estão sendo feitas. Dosestudos mais relevantes, podemos destacar:

1. Santos et. al [48] apresentaram potencialidades e limitações do uso do sistema daTV digital brasileira no ensino, além de algumas aplicações-piloto desenvolvidaspela Universidade de Campinas (Unicamp) para a área,

2. Colace et. al [32] propuseram o projeto e implementação de um framework paraintegração de e-learning, com t-learning, levando em consideração padrões inter-nacionais e diretivas de usabilidade e acessibilidade.

2.5 U-learning 28

3. Monteiro et. al [44] apresentaram os resultados de uma exploração da TV digital pormeio de objetos de aprendizagem no contexto educacional, mesmo em situações emque o canal de retorno não esteja disponível. Ao final, foram levantadas questõesconsideradas importantes, como custo de implementação, qualidade nas questõesde usabilidade e adoção de padrões de compatiblidade.

4. Chen et. al [31] demonstraram um protótipo de ferramenta para reuso de recursosem ambiente de t-learning, integrado com o sistema de e-learning já existente naUniversidade de Taiwan, com resultados significativamente positivos.

5. Tavares et. al [112] abordou a utilização de Tv Digital interativa como ferramentapara educação infantil, culminando em muitas lições quanto à real experiência dedesenvolvimento de um objeto de aprendizagem em t-learning.

2.5 U-learning

A internet é acessada cada vez mais por dispositivos diferentes de laptops oucomputadores de mesa convencionais, como celulares, PDA’s e settop-boxes de TVdigital. Com isso, o cenário da computação mudou, passando de “vários usuários pormáquina” para “várias máquinas por usuário” (Figura 2.2).

Figura 2.2: A evolução do paradigma do uso de dispositivos pelosusuários.

Mesmo com todo o potencial do m-learning e o t-learning, nem sempre conhecero dispositivo já é o suficiente para o processo de ensino e aprendizagem. O aluno podeser alguém com necessidades especiais ou estar em um local movimentado, por exemplo.Assim, outras informações podem ser utilizadas para que a experiência do usuário sejamais completa. Além disso, a integração de todos os pontos do sistema de ensino àdistância é importante para retirar o melhor de cada ambiente. Assim, o ubiquitous

2.5 U-learning 29

learning (u-learning) se propõe a integrar pontos de acesso às mídias e a realidade dousuário para que se tenha o ensino “em qualquer hora, lugar e situação”. Veja a Figura2.3.

Figura 2.3: O u-learning propõe integrar todas as modalidades doe-learning.

Em um ambiente de u-learning, o dispositivo pode ser usado como ferramenta deacesso ao conteúdo, ferramenta de comunicação ou ambos [90]. Porém, este sistema nãodepende só do aparelho e da provisão de recursos acessados remotamente, mas de outrostrês pilares: aprendiz, conteúdo e conhecimento de contexto [25]. Quanto ao aprendiz,deve-se conhecer seu conhecimento atual e seus interesses de aprendizado (como no e-

learning tradicional). Quanto ao conteúdo, estes devem estar acessíveis de qualquer lugare em vários formato, dada a heterogeneidade de máquinas e redes de comunicação. Já ocontexto é qualquer informação que pode ser usada para caracterizar a situação de umapessoa, lugar ou objeto considerado relevante para a interação humano-computador [47].Quanto a esse item, o sistema deve gerenciar os elementos que identificam os possíveisambientes para melhor garantir a interoperabilidade, incluindo o possível uso de sensores.Tal tipo de provisão de serviço é chamado de “Acesso Universal”, cujo esboço é feito naFigura 2.4.

2.5 U-learning 30

Figura 2.4: Componentes do Acesso Universal. Figura adaptadade [125]

Para estabelecer a interoperabilidade dos contextos, outros requisitos são impor-tantes [104], como:

• Adaptabilidade: adaptação de um recurso com a interface de acordo com cadaplataforma (dispositivo);

• Atualizações automáticas: Possibilidade de download e auto-instalação de novasversões de software;

• Acessibilidade: Permitir acesso a todos, inclusive aqueles com necessidades espe-ciais;

• Compatibilidade: Ser compatível com ferramentas, sistemas e padrões voltados aadaptação de conteúdo.

• Portabilidade de dados: Permitir que todos os pontos do sistema possam ter acessoaos dados dos outros existentes.

Em relação às vantagens tecnológicas do u-learning em relação ao e-learning

convencional, podemos lembrar todas de m-learning e t-learning somadas a:

• Maior integração entre as modalidades de e-learning, melhorando a disponibilidadedo serviço;

• Com a vasta oferta de dispositivos no mercado, cada um pode significar uma novaoportunidade para o ensino;

• Do ponto de vista pedagógico, novos paradigmas de ensino podem ser úteis.

Em relação às vantagens pedagógicas do m-learning em relação ao e-learning

convencional, também podemos citar todas do m-learning e t-learning aliadas a:

2.5 U-learning 31

• Melhor conhecimento de contexto, ou seja, o professor agora pode saber porinformações oferecidas pelos sitemas, quem é o aluno, onde ele prefere aprender,como ele prefere interagir com a máquina, etc;

• Conformidade com o conectivismo [110], teoria baseada na integração das diferen-tes mídias e norteada pelo incentivo à interação dos envolvidos. O aluno não só vêconteúdo disponível por mais tempo, como também deve ter vários pontos de co-municação para que possa interagir. O know-how e o know-what é complementadopelo know-where.

Quanto às desvantagens, seguem àquelas do e-learning convencional, como apouca interoperabilidade entre sistemas de ensino e o conteúdo de outras fontes, poiscomo a maioria das soluções em u-learning é ligada a somente um sistema, a reutilizaçãode objetos de aprendizagem ubíquos através dos padrões e adaptações é um desafio a sevencer.


Vários trabalhos internacionais exploraram o u-learning, seja na criação de novassoluções ou na definição de conceitos sobre o tema. Alguns são identificados abaixo:

1. Siemens [110] introduziu o já citado conceito de conectivismo, modelo de ensinobaseado nas relações humanas em diferentes ambientes e momentos, onde o u-

learning se encaixa de maneira eficiente.2. Yang e Chen [125] relacionaram o conceito de “Acesso Universal” ao ensino, de

forma que a solução computacional aja de acordo com as características do usuário(inclusive pessoas com necessidades especiais) e do ambiente. Além disso, propõeregras de projeto de objetos de aprendizagem relacionados à ubiquidade.

3. Pu et. al [59] apresentam uma proposta de construção de um sistema para e-learning

que detecta o ambiente que o dispositivo se encontra e adapta os serviços para este,seja qual for o aparelho (independência de máquina).

4. Roesler et. al [104] apresentaram uma proposta de arquitetura que permite inte-roperabilidade entre TV Digital, Web e dispositivos móveis, validada através daconstrução de dois objetos de aprendizado aplicados na Universidade Federal doRio Grande do Sul (UFRGS).

5. Colazzo et. al [33] apresentaram uma proposta de arquitetura que facilita o acessoao ensino em celulares de diferentes fabricantes, baseada na descoberta do contexto,adaptação e entrega de conteúdo.

6. Barbosa et. al [25] dedicaram-se à construção de objetos de aprendizagem ubí-quos, aplicados ao curso de Engenharia da Computação, que estimularam apro-fundamento dos estudos sobre a integração do modelo pedagógico do sistema da


Universidade Vale do Rio Sinos (UNISINOS) e fomentaram tecnologias de apren-dizagem móvel e ubíqua dentre os alunos.

7. Rao [99] apresentou como entregar conteúdo de acodo com diversos requisitos,como a metodologia de ensino, base de conhecimento, contexto, emoções e ativi-dades do usuário.

8. Ferlin et. al [71] construíram uma ferramenta para avaliação de ambientes e-

learning quanto aos aspectos de acessibilidade visual, podendo ser utilizado paramensurar a eficácia de sistemas u-learning voltados para ensino de deficientesvisuais.

2.6 Contextualização do Odin

O objetivo final deste trabalho é a construção de uma ferramenta que permita quesistemas existentes para e-learning atendam de forma mais apropriada os interessados noprocesso de ensino-aprendizagem. Logo, conhecer melhor os conceitos da área, os tiposde sistema usados e os trabalhos realizados é o primeiro passo para conhecer o contextode pesquisa.

Focando nos sistemas de gerência de ensino, pecebemos que as ferramentasatuais têm muitas funcionalidades para o e-learning tradicional, mas restrições no suporteàs áreas do u-learning. Como a maioria das aplicações para tal modalidade são específicasa um ambiente ou outro, decidimos propor uma solução que pudesse ser usada pelos LMSexistentes, como um serviço, e também diretamente, servindo como um software.

Nesse capítulo foi mostrada a àrea de atuação do Odin. Nas páginas seguintes,vamos entender os requisitos que nortearam o seu desenvolvimento e sua validação.

CAPÍTULO 3Conteúdo instrucional em e-learning

3.1 Introdução

O Odin pretende dar suporte a criação de objetos de aprendizagem para dife-rentes modalidades de e-learning, como m-learning, t-learning e u-learning. No capítuloanterior foram abordadas as questões pedagógicas e teóricas, porém é necessário enten-der quais são os problemas relacionados a sua construção e reutilização de conteúdo emdiferentes contextos, abordados nesse capítulo.

O constante avanço da tecnologia, a substituição do sistema computacional deensino é mais frequente do que a obsolecência do conteúdo dos cursos [45]. Logo,a maioria dos desafios e soluções presentes nesse capítulo não são presos somente atecnologia.

Ao final deste capítulo, é descrito sucintamente como o Odin pretende resolveralguns dos desafios de construção de objetos de aprendizagem para múltiplos contextos.

3.2 Objetos de Aprendizagem

Segundo [122], "um objeto de aprendizagem é uma parte digital do materialda aprendizagem que se dirige a um tópico claramente identificável ou resultado daaprendizagem e tem o potencial de reutilização em contextos diferentes". Seguindoesse pensamento, objetos de aprendizagem podem e devem ser utilizados em diferentessistemas de e-learning para atingir diferentes metas.

Segundo [91], objetos de aprendizagem (learning objects - LOs)devem resolvermuitos problemas existentes no e-learning atualmente, dos quais podemos destacar:

• Aumento do valor de um conhecimento: Com o reuso contínuo e evolução doconteúdo de um objeto de aprendizagem, a sua consolidação cresce de maneiraespontânea, indicando melhoria significativa da qualidade do ensino.

• Facilidade na atualização: Uma pessoa que utiliza um conteúdo pode ter contri-buições para melhorá-lo. Como na internet a atualização de conteúdo pode aconte-

3.3 Padronização para objetos de aprendizagem 34

cer em tempo real desde que os dados estejam em conformidade com o padrão jáexistente, os objetos de aprendizagem facilitam a evolução dos trabalhos.

• Flexibilidade: Como objetos de aprendizagem têm definidos em seus metadadoso início, meio e fim, eles podem ser reutilizados em diferentes ambientes semmanutenção.

• Facilidade de busca: Com a padronização dos metadados, a localização de deter-minado conteúdo se torna mais fácil.

• Personalização: Objetos de aprendizagem são independentes. Dessa forma, oprofissional pode rearranjá-lo da forma que achar necessário adaptá-lo para seuambiente.

• Interoperabilidade: A idéia de que um LO possa ser reutilizado em qualquerplataforma de ensino aumenta ainda mais as vantagens desse objeto, podendoinclusive ser integrado em sistemas de vários locais do mundo.

Para a criação de um objeto de aprendizagem, o fluxo de trabalho ideal ocorre emtrês passos: concepção, produção e publicação. Na produção, o autor/professor/pedagogoprojeta o conteúdo a ser tratado e como será tratado, definindo sequenciamento deconteúdo, resultado esperado, fontes sobre o tema, dentre outros itens. Logo após, odesigner/editor/conteudista cria o conteúdo de acordo com o especificado no passoanterior e disponibiliza para a publicação, que é feita no LMS da instituição de ensino.Então, o LO estará disponível para o consumidor/estudante.

É importante destacar que nem sempre o professor tem um desig-ner/conteudista/editor de LO disponível para auxílio no trabalho. Logo, ele tem querealizar os dois primeiros passos sozinho, demandando disciplina, criatividade e conheci-mento tecnológico[105].

3.3 Padronização para objetos de aprendizagem

Um dos componentes de um objeto de aprendizagem é o conjunto de metadados,que são informação acerca da informação contida dentro do LO, como sequenciamentode conteúdo, pré-requisitos para execução, dentre outros. Veja a Figura 3.1. Segundo aW3C [119], metadados são dados que descrevem dados mais complexos.

A adoção de padrões no desenvolvimento de objetos de aprendizagem advém dapreocupação que há grande diversidade e formas de conteúdo, abordagens pedagógicase contextos de ensino. Diante dessa realidade, a padronização é necessária para que ossistemas de gerenciamento de ensino possam executar diferentes materiais em diferentesambientes e para que professores não precisem realizar re-trabalho na criação de conteúdopara seus alunos.


Figura 3.1: A configuração básica de um objeto de aprendizagem:Uma breve descrição, seus metadados e seu conteúdo.

Várias organizações procuram criar padrões para metadados educacionais. Den-tre estes, destacam-se o Learning Object Metadata (LOM), o Sharable Content Object

Reference (SCORM) e os da Global Learning Consortium, mais especificamente o Lear-

ning Design (LD) e o Question and Text Interoperability (QTI). Na figura 3.2, é mostradoum grafo de referência que ilustra os padrões e quais os projetos anteriores que os influ-enciaram.

O SCORM é considerado um dos melhores padrões para agregação de conteúdo[35] e por isso será dada ênfase a este, mas é importante destacar que a maioria dospadrões atualmente existentes tem ligação entre si e com padrões não mais utilizados,mas cuja contribuição influi fortemente em suas definições.

Figura 3.2: Grafo de referência entre os padrões citados nessetrabalho e projetos anteriores, adaptada de [92].


3.3.1 LOM

O Learning Object Metadata)(LOM) foi um padrão proposto pelo IEEE (Ins-

titute of Electrical and Electronics Engineers) e IMS (Instrucional Management Sys-

tems Global Learning Consortium), à partir dos projetos Ariadne[89], IMS[8] e DublinCore[67] (Figura 3.2).

O LOM define um esquema conceitual de dados para especificar a sintaxe e asemântica dos metadados, ou seja, informações associadas aos objetos de aprendizadoque definem suas características, de forma a torná-los gerenciáveis e pesquisáveis. Taisinformações são: tipo do objeto, autor, propriedade(s), termos de distribuição e formato.

Tais elementos de dados que seguem esse padrão são dispostos em uma hierar-quia (nós intermediários e folhas), onde os dados existentes se enquadram nas sequintescategorias:

• Características gerais - informações gerais que descrevem o objeto de aprendiza-gem como um todo. Ex: Título, idioma, estrutura e descrição.

• Ciclo de vida - informações relacionadas à história e estado corrente do desenvol-vimento do objeto. Ex: status, versão e papel.

• Meta-metadados - informações sobre a instância de metadados propriamente dita.• Técnicas - informações e requisitos técnicos do LO. Ex: formato, tamanho, requi-

sitos de browser. Não há claramente um campo que especifique dispositivo alvo doobjeto de aprendizagem[75].

• Aspectos educacionais - informações pedagógicas e educacionais do objeto. Ex:interatividade, dificuldade, características esperadas do usuário.

• Direitos - informações sobre propriedade intelectual e direitos de uso do LO.• Relações - informações sobre relacionamento com outros objetos de aprendizagem.• Anotação - informações adicionais do LO.• Classificação - informações que descrevem o objeto com relação a um sistema de

classificação específico, à partir de seu propósito.

3.3.2 IMS

O IMS (Instructional Management Systems) Consortium surgiu em 1997 atravésde associação de organizações ligadas à educação, comércio e governos. Como um projetoinicialmente focado na educação superior, seu objetivo é promover especificações nãoproprietárias, tais como definições de metadados e questionários de avaliação para provero estudo online distribuído (e-learning) e dar suporte a incorporação e integração deespecificações IMS em produtos e serviços.

Além da preocupação com a padronização para metadados, há também a pre-ocupação com a preservação de uma das propriedades dos objetos de aprendizagem, a


interoperabilidade. Para estar em conformidade com esse requisito, o IMS propõe que umLO deve ser estruturado em três partes:

• Objetivos - informações sobre o que é aprendido com tal objeto de aprendizagem.• Conteúdo Instrucional - material didático a ser utilizado como referência, como

livros, vídeo, áudio, entre outros.• Prática e feedback - forma de avaliação do aluno, para medir seu aprendizado e

permitir que ele acesse outros conteúdos.

A abordagem do IMS em relação à forma que o conteúdo deve ser normalizadoé modular, pois foram criados vários grupos de trabalho para definição das especificaçõesnas áreas do e-learning: metadados, empacotamento de conteúdo, enterprise, questões etestes, informações sobre discentes e definição de competências. Para este trabalho, osgrupos mais enfocados foram os de metadados (metadata), empacotamento de conteúdo(content packaging) e questões e testes (Question & Test).

O grupo de trabalho em metadados preocupa-se com a definição de padrões dedados para composição de detalhes acerca da informação dos conteúdos pedagógicos.Tais informações podem ser vistas como etiquetas que se agregam aos diversos conteúdoseducativos. Portanto, o produto do trabalho deste grupo é utilizado por todos os outros.

Figura 3.3: Representação gráfica de metadados de um objeto deaprendizagem [9].

O grupo de trabalho em empacotamento de conteúdo é responsável pela manu-tenção da norma para empacotamento de conteúdo e estruturação de atividades educacio-


nais e, portanto, é de extrema importância para nosso trabalho. O produto dessa equipe é opadrão IMS Learning Design (IMS-LD), que tem a idéia de criar uma modelagem que nãosó modele o conteúdo, mas uma unidade de aprendizagem em sua totalidade, englobandotodos os processos envolvidos. Com seus principais componentes de estrutura representa-dos na Figura 3.4, ele dá suporte ao uso de diferentes abordagens de ensino-aprendizagem,como behavorismo, cognitivismo e construtivismo através de uma linguagem genérica eflexível [45].

Figura 3.4: Esquema que representa a estrutura de um pacotepadronizado segundo o IMS-LD [68].

Um curso é visto como conjunto de “unidades de aprendizagem”, agregados emuma estrutura em forma de árvore que pode ser navegada até o nível dos recursos dosobjetos de aprendizagem. Os níveis dessa árvore são de responsabilidade do criador,através de linguagem XML, podendo gerar overhead a esse profissional. O chamado“manifesto de curso” define a estrutura do curso, a relação de seus componentes e osarquivos e a definição dos metadados sobre todos estes aspectos.

Após a construção do XML, este pode ser processado por uma aplicação“player”. Sua grande vantagem é ser baseado na idéia de que existem mais relações noprocesso de ensino do que a interação de aluno com conteúdo. Porém, historicamente,a grande desvantagem desse padrão em relação aos outros é a pequena quantidade deaplicações que dão suporte a essa especificação.

Finalmente, o grupo de trabalho em questões e testes abrange um tipo específicode conteúdos pedagógicos: os questionários. O IMS desenvolveu o IMS Question &

Test Interoperability (IMS-QTI), um formato padrão para representação de avaliaçõese troca de questionários entre sistemas. Seu objetivo é que diferentes softwares possamcomunicar entre si apesar das distinções.

A versão 1.2 do IMS-QTI também utiliza os arquivos XML (Extensible Markup

Language) para a representação dos dados, que podem ser de testes múltipla escolha,


verdadeiro e falso, esboço, correspondência, complementação de espaços, múltiplasrespostas ou algoritmo.

Este padrão é de importância para o nosso trabalho porque define uma represen-tação de questionários cuja interação é simples e não depende de dispositivos complexos.Por isso, seu uso é interessante em m-learning e t-learning, sendo coberto em diversostrabalhos, como [103] e [37], que desenvolveram aplicações para execução de avaliaçõesIMS-QTI no ambiente móvel e de TV Digital, respectivamente.

3.3.3 SCORM

O Sharable Content Object Reference (SCORM) é um projeto de iniciativado Departamento de Defesa dos Estados Unidos [16]. Ele é baseado em trabalhos járealizados pela AICC [21] e IMS (Veja a Figura 3.2) e tem como objetivo manterum conjunto de especificações técnicas e de referência que permitam a construçãode conteúdos pedagógicos que possam ser compatíveis com os mais diversos LMSexistentes. Conforme [62], este padrão é um dos melhores exemplos de integração deobjetos de aprendizagem com padrões LMS. Isso acontece porque esse conjunto denormas é pautado em cinco requisitos principais [20]:

• Acessibilidade - Deve ser possível encontrar o conteúdo dentro do repositório, oque requer catalogação dos dados.

• Durabilidade - O conteúdo deve ter durabilidade compatível com seu custo, sendorelevante o tempo que existir.

• Interoperabilidade - O mesmo conteúdo deve funcionar da mesma maneira emdiferentes ambientes, não importando o LMS ou forma de entrega.

• Portabilidade - Deve ser possível portar um objeto de aprendizagem de umambiente de entrega à outro. Tal conteúdo deve funcionar sem a necessidade demodificações.

• Reusabilidade - Deve-se sempre primar pela criação de objetos de aprendizagemde tamanho menor possível, de forma que seu conteúdo possa ser reusado váriasvezes.

A versão atual do SCORM, publicada em 2004, é dividida em quatro livros: Vi-são Geral, Modelo de Agregação de Conteúdo, Ambiente de Execução e Sequenciamentoe Navegação. Veja a Figura 3.5.

O Modelo de “Agregação de Conteúdo” (Content Agregation Model) defineo dicionário de metadados, o empacotamento e estrutura de conteúdos e XML dosmetadados do pacote, necessários para agrupamento, organização e identificação de todosos objetos de aprendizagem necessários para disponibilizar unidades de aprendizagem em


Figura 3.5: Representação do SCORM, seu conjunto de especifi-cações e suas referências.

diferentes LMS. Como este trabalho refere-se à adaptação de dados, esse é o conjunto deespecificação mais importante.

No livro “Ambiente de Execução” (Runtime Environment), são definidas aspolíticas para comunicação entre o curso e o LMS, incluindo acompanhamento do aluno.Tal padronização é importante por diminuir o problema da falta de normalização dos LMSquanto ao acompanhamento do desempenho do aluno. Atualmente, cada aplicação usa aseu própria ferramenta para realizar tal atividade.

Finalmente, o livro de “Sequenciamento e navegação” (Sequencing and naviga-

tion) descreve como os conteúdos SCORM podem ser arranjados e como um LMS deveinterpretar as regras de sequenciamento, ou seja, qual conteúdo deve ser entregue, quandodeve ser entregue e quando rastrear os estudantes durante o ensino.

Assim, como pôde ser observado, o SCORM preocupa-se basicamente com aorganização, sequenciamento e como o conteúdo será mostrado, aproximando-se da teoriabehavorista [45].

“A grande vantagem do SCORM é sua crescente adoção como especificação deobjetos de aprendizagem.” [45], talvez pelo fato da especificação ter uma abrangênciamenor, tendo um escopo mais focado no conteúdo e trabalho do professor somente antesdas atividades. Outra vantagem importante para adotar tal padrão é o grande suporteao professor/conteudista, tanto por editores de objetos de aprendizagem (Authorware,Reload Editor, FlashMX, dentre outros) quanto de LMS (Moodle, Blackboard, Claroline,.LRN, dentre outros).

3.4 Ferramentas para construção de objetos de aprendizagem 41

Exemplos nacionais de utilização do padrão SCORM são [38], [24], [35] e [117].

3.4 Ferramentas para construção de objetos de aprendi-zagem

Para criarmos conteúdo a ser consumido pelos alunos, precisamos de umaferramenta de criação das mídias e outra para autoria e normalização de objetos deaprendizagem. Adicionalmente, caso o contexto alvo seja específico e necessite de testes,pode-se usar um software de emulação do dispositivo ou ambiente desejado.

No processo de criação de mídias (áudio, vídeo, imagens e texto), temos à esco-lha milhares de softwares para a edição de conteúdo. Cabe ao professor ou conteudistaescolher as que melhor se encaixem no propósito do trabalho e conhecimento do profis-sional. Existem diferentes suites de aplicativos de propósito geral que podem voltadas àcriação desses arquivos, como o OpenOffice[18] e o iWork [17]. Além disso, muitas fer-ramentas de design, como as do pacote Adobe Creative Suite [1], também são utilizadas.Na maioria dos casos, caso a adaptação seja necessária, ela é de responsabilidade do pro-fessor, que deve conhecer as especificidades do dipositivo ou contexto alvo. Já a autoriae normalização de objetos de aprendizagem de acordo com os padrões exige softwareadicional, pois é necessário escrever arquivo(s) de configuração.

Teoricamente, para construirmos um arquivo utilizando um dos padrões preci-samos somente de um editor de texto simples, visto que são descritores geralmente emXML. Porém, por questões de produtividade, utilizamos ferramentas mais específicas,que empacotam o conteúdo de acordo com o padrão desejado sem a necessidade da edi-ção diretamente no arquivo texto.

Para criar objetos SCORM, podemos utilizar uma ferramenta de empacotamentodo objeto que acrescente os recursos desejados. Para essas tarefas pode-se utilizar oReload (Reusable eLearning Object Authoring and Delivery) [14], AuthorWare [4],dentre outras.

Para a criação de objetos IMS-LD, temos somente uma aplicação, que tambémdá suporte ao SCORM: a Reload.

A criação do objeto IMS QTI envolve, além do arquivo descritor do LO, a ediçãode um arquivo XML com o teste a ser feito. Para esse tipo de objeto, a ferramentaRespondus [100] também pode ser utilizada. Uma das telas desse software está na Figura3.6.

3.5 Diretivas para criação de objetos de aprendizagem 42

Figura 3.6: Exemplo de tela do Respondus na criação de um testedo tipo “Algoritmo".

3.5 Diretivas para criação de objetos de aprendizagem

A disseminação de tecnologias multimídia vem facilitando e melhorando cadadia mais a criação de recursos para a aprendizagem. Porém, o mau planejamento domaterial pode causar desorientação e desmotivação do aluno, não permitindo que oaluno possa acompanhar melhor o curso, acessando mais facilmente a informação e seengajando mais no processo de aprendizagem. E tais resultados são polarizados dentro deambiente móvel.

A primeira tarefa no design de atividades e conteúdos de objetos de aprendiza-gem é identificar as características dos alunos e professores que irão usar esse material, deforma que a equipe de produção possa entender melhor quem serão os usuários e comoutilizarão o sistema. O projeto RIVED (Rede Interativa Virtual de Educação)[39] citaalgumas questões que devem ser levantadas, como:

• “Quais as características pessoais (idade, status socioeconômico, região onde mora,sexo, etc)?”

• “Qual é o nível educacional dos usuários (primeiro, segundo, terceiro ano)?”• “Qual a experiência anterior dos usuários com computadores e internet?”

3.5 Diretivas para criação de objetos de aprendizagem 43

• “Que recursos de tecnologia têm disponíveis?”

A primeira pergunta diz respeito a conhecer o usuário no ponto de vista social, ouseja, quem ele é, de forma que o objeto de aprendizagem seja compatível com a realidadeda pessoa. Já a segunda pergunta ajuda a equipe de produção no sentido de mostrarque nível de linguagem acadêmica poderá ser usada e até qual nível de profundidadede conteúdo pode-se chegar. A terceira pergunta diz respeito ao conhecimento dosusuários com computação, que pode influir nos modelos de interação, principalmentenavegacionais do objeto de aprendizagem virtual. E a última pergunta é cabível a essetrabalho, pois preocupa-se com a tecnologia disponível, a qual pode variar desde umcomputador de mesa até um dispositivo bem mais simples, talvez modificado para atendera certos requisitos do(s) ambiente(s).

Após a identificação das características do usuário e do(s) ambiente(s),recomenda-se trabalhar na interface instrucional, a fim de orientar e ganhar a atenção doaluno. Quanto mais o sistema instigar a curiosidade e motivação do estudante, mais ele seengajará ao módulo. Seja via web (site) ou via aplicação instalada na máquina, deve-seorganizar adequadamente a informação que deverá aparecer na tela do computador nãosobrecarregando o discente com informações irrelevantes.

Nesse ponto, é importante destacar que as ferramentas de adaptação de conteúdopara dispositivos móveis e ubíquos têm papel importante, pois a correta formatação dasinformações em ambientes hostis é de extrema importância para o sucesso do curso.

A correta formatação dos recursos multimídia é o último passo, mas não menosimportante, pois é neles que o estudante vai extrair boa parte do conteúdo em um ambientede e-learning. Para isso, em u-learning deve-se aproveitar da melhor maneira possível ocontexto do discente e a mídia que o aluno tem interesse, adaptando o material.

Ao criar recursos de imagem, deve-se estar atento em até que ponto umailustração pode ajudar no ensino, principalmente quando se trata de representações quebusquem realismo. Nem sempre tal tipo de abordagem é interessante. Além disso, aequipe de produção pode levar em conta outras dicas da W3C [98], como:

• Criar imagens que podem ser redimensionadas em até 200% do seu tamanho semperdas visíveis;

• Informações de ajuda e rótulos deixam o conteúdo do objeto de aprendizagem maisclaros.

Para vídeos e animações, Nascimento [39] indica que o material feito sejaconstruído de forma que possa ser convertido em imagens, estando, obviamente, emformato compatível com o aparelho alvo, pois uma experiência ruim pode desmotivaros alunos.

3.6 Desafios para criação de objetos de aprendizagem em u-learning 44

Ao criarmos material de áudio, este deve ser complementar e não ser a únicaforma de conteúdo, pois muitos dispositivos não possuem tal recurso ou têm sua execuçãodificultada por agentes externos.

Para materiais textuais, o mais comum, nem sempre os princípios de designde texto se aplicam ao e-learning. Exemplo disso é a constatação que nem sempre otexto justificado aumenta a legibilidade da tela [15]. Além dessa asserção, outros pontosobservados:

• O “rolamento” de tela deve ser evitado, pois causa distração nos usuários [98];• Linhas de texto curtas são mais efetivas do que linhas longas [46], pois cansam

menos os olhos dos usuários, aumentando a compreensão;• Usar hierarquia tipográfica consistente e que facilite a visão e a leitura dos usuários

identificados [39];• Primar pela voz ativa e palavras claras, sem muitos termos técnicos e abreviações

[39];• Diminuir a densidade do texto através de espaço em branco;• Listas e marcadores aumentam a velocidade de leitura [98].

Enfim, a melhor forma de construir um objeto de aprendizagem com boa usa-bilidade é conhecendo seus usuários e utilizando o melhor de cada mídia e dispositivo.Mesmo com todas as soluções existentes, muitos problemas ainda devem ser considera-dos na criação de cada material específico, havendo muitos desafios a serem vencidos,descritos na seção seguinte.

3.6 Desafios para criação de objetos de aprendizagem emu-learning

A abordagem do u-learning demandará mudanças em termos de estratégias peda-gógicas, matrizes curriculares e práticas de sala de aula. Quanto ao conteúdo educacional,muitas restrições devem ser tratadas nos diferentes contextos. Há muitos desafios parase enfrentar. Muitos deles são similares aos existentes no e-learning tradicional. Outrosestão mais relacionados ao modelo de ensino em si e à mobilidade, estando presentes emmuitos trabalhos da área ([98], [43], [55], [90], [48], [129]).

3.6.1 Desafios pedagógicos

Existem muitos desafios para criação de atividades e conteúdos para u-learning

que não estão ligados à tecnologia, mas ao modelo de ensino. Agrupamos esses desafios(muitos deles possuem interrelação) nos subtópicos seguintes.


Resistência à adoção de novas tecnologias

Segundo [129], os brasileiros ainda têm a idéia de que “falta cultura, familiari-dade ou hábito em utilização dos dispositivos móveis” para outros motivos senão o defalar ao celular. Além disso, muitos ainda não se acostumaram com o uso de computado-res. Por isso, os professores devem tomar cuidado com a complexidade do material criadoe na escolha do aparelho em que ele deverá ser executado.

Quanto ao propósito de uso de celular, este vem se tornado cada vez mais amplocom a popularização da internet móvel e aumento do número de aparelhos. Segundoa Agência Nacional de Telecomunicações (ANATEL), a base de telefones celulares noBrasil está chegando a 200 milhões de aparelhos, mais de um por habitante. Já o acessoà banda larga móvel está crescendo e já chega ao número de praticamente 20 milhões depessoas conectadas, ou seja, cerca de 10% da população.

Resistência à adoção de novas práticas de aprendizagem

Muitos profissionais de ensino ainda têm resistência ao e-learning, o que podeser estendido ao u-learning [129]. Da mesma forma, muitos alunos ainda não se acostu-maram com esse modalidade de ensino. Pensando nisso, durante o processo de ensino-aprendizagem, o profissional deve acompanhar o progresso dos alunos, de forma a nãodeixá-los se desmotivarem.

Tempo de resposta do aluno reduzido

Para um ensino em u-learning, estudantes e alunos devem entender a naturezae a qualidade e das relações que o envolvem. Como uma das propostas deste modelo deensino é o aprendizado “em qualquer hora e em qualquer lugar”, é mais provável que hajamais interação dos discentes. Dessa forma, o professor deve manter um meio eficiente detirar as dúvidas das lições. Uma abordagem alternativa pode ser o foco no grupo.

Entendimento do contexto

O material de aprendizagem em ambiente ubíquo deve ser baseado em múltiplasperspectivas e formas de ensino, pois o contexto pode mudar muito. Podemos ter desdeum deficiente visual acessando o conteúdo via tablet adaptado com teclado e leitor de telaaté um doutor acessando referências para sua pesquisa.

Dessa forma, é importante conhecer o contexto dos alunos e os dispositivos pelosquais será dado suporte. Nesse ponto, pensar na acessibilidade também é importante.


Prender a atenção dos estudantes e concorrência com outras fontes

Acessar um conteúdo enquanto se faz outra atividade nem sempre é produtivo,pois o usuário nem sempre consegue se concentrar no que realmente é necessário. Emt-learning, por exemplo, geralmente as atividades são feitas em grupo [48]. Nesses casos,o professor deve explorar bem a relação entre o conteúdo passado e as atividades queacontecem simultaneamente, caso existam.

Em outros casos, o material que está sendo dado no curso compete com ainformação/interrupção de outras fontes ao redor do estudante, como uma televisão ligada,família e ambiente em geral. Para este problema, recomenda-se que o professor pensesempre na motivação do aluno, de preferência criando conteúdo que possa ser ajustado àscondições do aluno [90], tornando seu acesso facilitado.

3.6.2 Desafios tecnológicos

Os desafios tecnológicos do u-learning estão ligados principalmente à grandeheterogeneidade dos dispositivos móveis. Muitos deles também possuem inter-relação esão descritos, juntamente com possíveis soluções, nos subtópicos seguintes.

Limitações de tamanho de tela

O uso de recursos visuais pode ser comprometido, pois o tamanho da telageralmente varia de um dispositivo para outro. Pode-se ter como cliente da aplicaçãodesde um celular de tela pequena (cerca de duas polegadas) até um televisor full HD de50 polegadas, passando por um leitor de livros digitais (cerca de 9 polegadas). Pior do queisso, muitos aparelhos não têm a capacidade de renderizar o conteúdo para o tamanho datela, que pode ser retangular ou mais quadrada. Veja um exemplo na Figura 3.7.

O surgimento de barras de rolagem prejudicam a ergonomia da aplicação. Já aprojeção do material via aparelho e a transmissão dos gráficos para outros dispositivostambém não são recomendados, visto que poucos têm tais propriedades. A soluçãogeralmente utilizada para esses casos é converter os recursos de acordo com a mídia alvo,diminuindo a escala (tamanho em pixels) nos casos em que a tela for menor que o arquivooriginal ou aumentando-a, nos casos em que a tela é maior. Neste último cenário, só háresultado satisfatório se a mídia estiver vetorizada, tendo a capacidade de aumentar detamanho sem muita perda de qualidade.

Para a TV Digital, como a distância de visualização da tela é maior do que emcomputadores de mesa e dispositivos móveis, [48] recomenda evitar fontes menores doque 22 pt para todos os textos. E isso ainda depende do modelo de set top-box.


Figura 3.7: Diferentes dispositivos possuem diferentes resoluçõesde tela, com diferentes necessidades.

Limitações de cores

O uso de recursos predominantemente ligados a cor pode arruinar a experiênciaem usar um aparelho porque nem todas as máquinas têm a capacidade de mostrar todasas cores do espectro visual e muitas pessoas têm dificuldade em assimilar certos padrõescromáticos. Cada aparelho dá suporte a exibição de uma quantidade limitada de cores,dentro de uma escala. Existem hoje desde aparelhos que exibem duas cores (Preto eBranco) até outros com capacidade de mostrar bilhões de tonalidades.

Não há atualmente uso de soluções que aumentem a quantidade de cores, poispode-se comprometer o objetivo do material. Já para os casos em que o espectro de coresdo aparelho é menor do que o do material original, sugere-se criar uma versão cujas corespodem ser visualizadas na máquina. Essa conversão geralmente falha nos casos em que acor do original tem peso importante no entendimento do recurso. A solução mais utilizadaé o nivelamento pelo “mínimo denominador comum”, evitando cores saturadas e gráficoscom menos brilho.

Finalmente, é importante destacar que conversões podem incluir distorções úteis,por exemplo, melhor contraste para o daltônico, sem comprometer a imagem para quempossui visão normal.

Limitações de dispositivos de interação

Dispositivos móveis geralmente não têm a mesma facilidade de uso de um com-putador comum, assim como um controle de TV. Interagir com eles é mais complicado,


pois cada um tem especificidades quanto a acessibilidade. A simples entrada de dados tex-tuais em um objeto de aprendizagem pode se tornar uma tarefa árdua para um estudante,principalmente se o aluno tiver limitações motoras ou outras.

Algumas das soluções existentes são os teclados virtual ou Bluetooth (Figura3.8). Quando não for possível o uso de tais soluções, recomenda-se a criação de mídiainstrucional que não necessite de muita interação. Caso o objetivo do objeto de aprendi-zagem seja ensinar através da interação com o usuário, como nas animações Shockwave

Flash, sugere-se converter o recurso exatamente para o(s) dispositivo(s) homologado(s)em questão, pois a experiência do usuário é fator determinante na sua motivação. Assim,há a necessidade de uma nova versão para cada aparelho, o que pode ser feito tanto porum conversor do computador como por um agente humano [41].

Figura 3.8: Teclado virtual para celulares Android e teclado Blue-tooth, respectivamente.

Limitações de processamento

O uso de diferentes tipos de dispositivos de tamanhos e finalidades diferentesimplica em se preocupar com as capacidades computacionais de cada um, no que dizrespeito ao processador. Podemos ter algum aparelho com processador similar a umcomputador de mesa, com potência de 1.1 GHz, bem como podemos ter uma máquinacujo processamento se equipare a um celular antigo 100MHz.

Geralmente esse problema gera alguns outros, como a falta de suporte a formatosde mídia e tempo de vida de bateria. Por isso, na maioria dos casos não é tratadodiretamente: ataca-se as restrições geradas por esse problema.

Limitações de memória

Atualmente, uma grande quantidade de memória ram exige um tamanho físicorelativamente grande, o que limita dispositivos móveis e embarcadas, geralmente peque-nos, de possuir tal componente mais potente.


A solução desse problema é a mesma de limitações de processamento, masrecomenda-se evitar tecnologias que não necessitem de tanta memória de leitura e escrita.Cabe ao professor estudar o(s) dispositivo(s) alvo e encontrar os requisitos máximos quepodem ser utilizados.

Capacidade de armazenamento limitada

Muitos dispositivos modernos têm boa capacidade de armazenamento e até acapacidade de ter sua memória estendida. Porém, outros têm a memória física pequena enão extensível. Nesses casos, a solução mais utilizada é prover os recursos por demandaem streaming de dados ao invés de envio completo do arquivo, caso o aparelho tenhaacesso a internet, de forma que o usuário consuma a mídia sob demanda, não necessitandogravar arquivos maiores em sua pequena memória.

Outras abordagens são mudar o formato do arquivo para outra extensão supor-tada cujo tamanho do arquivo seja menor ou recomendar o uso de cartões de memóriaflash.

Limitações de bateria

Em u-learning, deve-se preocupar com o uso de aparelhos que nem sempre estãoligados à alimentação de energia. Dessa forma, quanto menos tempo em atividades queconsumam muita bateria, melhor.

Recomenda-se não produzir recursos que durem mais de cinco minutos [114]e que não estabeleçam muitas conexões, pois o tráfego de dados com outras redes é afuncionalidade que geralmente mais consome energia.

Tempo de resposta

Segundo [43], devido ao fato dos recursos estarem sempre disponíveis emdispositivos móveis, 24 horas por dia, usuários são menos tolerantes a grandes tempos deresposta como seriam com computadores de mesa, o que costuma ser maior em ambientesWeb, de onde vem a paródia World Wide Wait, ao invés de World Wide Web (WWW).

Para buscar uma melhor expectativa do usuário, espera-se que a arquitetura (maisespecificamente dependências de componentes e complexidade de execução) seja o maissimples possível.

Limitações de software

Por haver diferentes limitações de hardware (processador, arquitetura da má-quina, etc.) e conflitos de interesses comerciais dos fabricantes de aparelhos, a falta de


padronização no suporte a mídias é um dos maiores obstáculos a serem transpostos no ofe-recimento de recursos de qualidade para diferentes dispositivos simultaneamente. Dessaforma, o responsável pela produção do conteúdo deve ter conhecimento específico dosseus aparelhos homologados para não entregar ao usuário arquivos que não possam serexecutados.

Existem muitas soluções para o problema. A mais simples é não entregar oarquivo ao usuário caso o dispositivo não seja compatível com o aparelho. Porém, pode-se também converter o arquivo para outro formato suportado pelo dispositivo, desde queexista conversor que transforme a mídia original para a extensão da mídia destino. Talconversão pode ser automática (via serviço computacional) ou via agente humano. Deve-se lembrar que neste último caso, o agente humano deve conhecer exatamente qual éo dispositivo em questão e seus atributos, o que demanda conhecimento adicional, porexemplo sobre o sistema operacional do aparelho.

Largura de banda e disponibilidade de internet

A largura de banda e disponibilidade de internet é alta em computadores de mesa,mas em u-learning, nem sempre o usuário está utilizando o dispositivo e o ambiente quelhe garantem melhor conexão com a internet.

Quando for este o caso, recomenda-se converter o objeto para um formatocompatível com o aparelho, mas de tamanho (em bits) menor e primar pelo uso de objetosde aprendizagem off-line.

Preço de planos de dados

No Brasil, os custos dos planos de dados para internet móvel estão ficando cadavez mais baratos, mas ainda não estão acessíveis à grande massa e têm disparidadeem relação à internet comum, oferecida para computadores robustos. Assim, o custopara download de certo objeto de aprendizagem geralmente voltado para computadorescomuns pode ser um obstáculo.

Uma abordagem para resolver esse problema é a mesma de largura de bandapequena ou pouco disponível.

Rápida obsolescência dos dispositivos

A rápida obsolescência de dispositivos móveis faz com que a criação de certosobjetos aprendizado se tornem inúteis em tempo rápido, pois os aparelhos aos quais elessão direcionados saem do mercado.


Para resolver tal problema, recomenda-se criar mídias que sejam independentesde tecnologia específica ou que estejam relacionadas à plataformas reconhecidamenteestáveis. Isso ocorre menos nos casos de recursos de áudio, vídeo, imagens e texto.


Um dos objetivo do projeto Odin é facilitar o trabalho do professor que constróiconteúdo para ser utilizado em ambiente u-learning. Para isso, precisamos saber o que éum objeto de aprendizagem e o que deve ser considerado antes, durante e depois de suaprodução.

Com o intuito de permitir o gerenciamento do perfil dos alunos, dispositivos eambientes, o Odin oferece ao administrador do sistema uma interface que possibilita agravação de todos os detalhes inerentes aos contextos alvo, estando em conformidadecom a idéia de que é necessário conhecer os alunos durante a fase de projeto dos objetosde aprendizagem.

Como foi visto neste capítulo, diversos desafios devem ser vencidos para que aexperiência de ensino-aprendizagem seja satisfatória. O Odin ataca tais problemas ofere-cendo formas de adaptação à essas mídias, seja pela conversão via agente computacional(API), que ataca os desafios tecnológicos, ou via agente humano (criação de ticket de con-versão para conteudista), que visa atacar ambos os desafios, com ênfase nos pedagógicos.

Finalmente, o Odin também propõe o suporte a padrões de objeto de aprendiza-gem para aumentar o reuso do conteúdo criado. Assim, o padrão SCORM foi escolhidopor ser o mais largamente utilizado pelas aplicações LMS e de criação de conteúdo.

CAPÍTULO 4Adaptação de conteúdo

4.1 Introdução

O Odin é uma aplicação de adaptação de conteúdo multimídia. E quando se estáprovendo um serviço de tal tipo, a mais difícil tarefa é como manipular os diferentesarquivos e oferecer conteúdo que seja útil para seu usuário em diferentes ocasiões.

Este capítulo trata do problema da adaptação de conteúdo para diferentes con-textos, explicando como quando e onde ela pode ocorrer, o que as aplicações converteme os trabalhos relacionados, de forma que fique mais simples o entendimento de toda aarquitetura do Odin.

Na última seção deste capítulo o Odin é contextualizado de acordo com asdefinições aqui apresentadas.

4.2 Motivação

Segundo a W3C, em um futuro próximo, 75% dos conteúdo na internet seráacessado por dispositivos diferentes de computadores de mesa, fazendo que o acesso naweb aconteça “em qualquer hora, lugar e ocasião”. Esse cenário demanda novos serviçostecnológicos para dar suporte de acordo com preferências do usuário e característicasdos dispositivos. Porém, uma das limitações observadas em alguns ambientes virtuaisem uso corrente está relacionada à utilização inadequada de recursos de mídia [94]. Nãobasta somente disponibilizar a informação para qualques pessoa , em qualquer lugar e porvários formatos. Deve-se oferecer os dados corretos, no momento certo e da maneira maisinteligente.

Em um ambiente de u-learning, a experiência do usuário no sistema é fatorimportante na avaliação da qualidade do ensino da instituição. Logo, deve-se preocuparcom uma forma de tornar disponíveis os conteúdos também para contextos onde o usuárioprecise de atenção especial, seja por causa de seu aparelho ou condições excepcionais queele se encontra. Como a maioria dos conteúdos é projetada para computadores de mesa,

4.3 Descoberta de contexto (Para) 53

a alternativa para resolver a frustração de muitos usuários é a adaptação de conteúdo.Mobilidade exige adaptabilidade [106].

Adaptação é o processo de seleção, geração e modificação de conteúdo paraadequação a diferentes ambientes computacionais e contextos de uso, o que pode serfeito também para serviços (chat, fórum, etc). Ele visa reconhecer e responder diferentescontextos de forma uniforme, não obstrutiva e se possível invisível, entregando ao usuárioo que ele precisa, de forma personalizada. Para atingir esse objetivo, dois problemasdevem ser resolvidos: consciência de contexto e adaptação de conteúdo. Após conhecer ocontexto e estabelecer um processo para adaptação do conteúdo, basta entregar ao usuárioo recurso desejado (Figura 4.1).

Figura 4.1: Exemplo de fluxo entrega de conteúdo para um celular,um dos contextos existentes.

Como principais vantagens da adaptação de conteúdo, temos a diminuição dotempo gasto para interagir com o sistema, pois este se personaliza de acordo com ascondições do ambiente, e o aumento da eficiência no acesso aos dados, pois o usuário nãoprecisa realizar ações adicionais para interagir melhor com o conteúdo.

Nas seções seguintes, introduzimos como pode ocorrer essa descoberta e onde,quando e como o conteúdo pode ser adaptado para os diferentes contextos.

4.3 Descoberta de contexto (Para)

A Computação Consciente de Contexto se beneficia do uso de informações dousuário para aprimorar as experiências no sistema. Tais informações podem conter dadossobre dispositivo utilizado, localização, temperatura, nível de ruído, níveis de deficiênciada pessoa, preferências de interação, condições de rede, etc. Assim, a aplicação passa a


saber quem é seu usuário, aplicando algoritmos para decidir como, quando e onde entregaro conteúdo.

Existem várias abordagens para descoberta do contexto ou, pelo menos, partedele. Seguem, à seguir, algumas das técnicas conhecidas.

4.3.1 Cabeçalhos HTTP

O Hypertext Transfer Protocol (HTTP) é o protocolo usado na troca de informa-ções na internet e define diversas informações no cabeçalho que podem ser usadas peloservidor no tratamento de requisições.

Uma das informações provisionadas pelo HTTP são os cabeçalhos de requisiçãodo tipo “Accept”, que indicam os tipos de mídia que o cliente pode aceitar, ou seja,suas capacidades. Tais tipos de formatos aceitos são oferecidos para mídia em geral(Accept, devendo estar presente o MIME do tipo do arquivo), codificação dos caracteres(Accept-Charset), codificação do arquivo (Accept-Encoding) e idioma utilizado (Accept-

Language).Juntamente com as características das mídias suportadas, também podem ser

adicionadas em cabeçalhos Accept as preferências quanto aos formatos aceitos, comnúmeros fracionários variando de 0 (total rejeição) até 1 (Prioridade total), dando maisflexibilidade a esse sistema.Veja a Tabela 4.1.

Exemplo de cabeçalho SignificadoAccept: image/*; q=0.2,image/png

Preferência à imagem PNG (20%), mas me mandequalquer um se o formato PNG não estiver disponível.

Accept-Charset: ISO-8859-1;q=0.9; UTF-8; q=0.6

Preferência à codificação de caracteres em ISO-8859-1, masvocê também pode me mandar UTF-8.

Accept-Encoding: indentity,gzip, *, q=0

Suporte somente a conteúdo sem codificação definida econteúdo com GNU gzip.

Accept-Language: pt-br, en;q=0.7

Preferência à conteúdo em Português, mas também dousuporte à Inglês.

Tabela 4.1: Exemplos de cabeçalhos Accept do protocolo HTTP.

Adicionalmente ao Accept, o protocolo HTTP também oferece o cabeçalho User-

Agent para identificar aparelhos e clientes (navegadores web) à partir de uma cadeia decaracteres. Esses dados geralmente incluem o nome do fabricante, o número de versãoe um nome. Para os dispositivos móveis, ele também pode possuir informações sobre ohardware.

Não há padrões que regulamentem como informação de User-Agent é construída.Apesar disso, sofisticados algoritmos podem ser usados para tentar identificar o disposi-tivo e o programa navegador sendo usado, o que acontece com muitos sistemas atuais, queusam essa identificação para acessar um repositório de informações sobre as capacidades


do dispositivo e de seu navegador. Um dos exemplos mais famosos é o WURFL ??, queidentifica o aparelho via cadeia de caracteres do agente de usuário e acessa as capacidadesdo mesmo através de sua base de dados, um arquivo XML.

Já existiram também outras formas de inserir informações adicionais sobrecapacidades dos dispositivos no protocolo HTTP de forma não padronizada. Por isso,nenhuma delas é usada com frequência, pois são difíceis de serem interpretados.

4.3.2 Parâmetros de requisição

A forma mais trivial de identificação de contexto é através do envio, pelo usuário,de parâmetros de requisição que informem seu estado, suas características. Tal abordagemé utilizada nos casos em que não há tecnologia disponível para verificação de contexto,além de poder complementar informações já existentes. Por exemplo, um usuário pode terseu aparelho identificado através do cabeçalho HTTP, mas em sua aplicação, ele adicionouum parâmetro a mais: tem problemas de visão. Logo, esse método tem a vantagem depoder enviar informações

A desvantagem de tal método é o fato do envio de tais dados serem de responsa-bilidade da aplicação cliente, o que inclusive pode onerar o usuário, tornando a ubiquidademais complicada.

4.3.3 Composite capabilities / Preferences Profile(CC/PP)

Devido ao aumento no número de dispositivos ligados à internet, o World

Wide Web Consortium (W3C) especificou o Composite capabilities / Preferences Pro-

file(CC/PP), um padrão para troca de informações de configuração do cliente para o ser-vidor.

O CC/PP é baseado no Resource Definition Framework (RDF - Framework deDescrição de Recursos), sendo extensível e independente de aplicação, permitindo quemais vocabulários possam ser escritos opcionalmente, utilizando um RDF schema. Dessaforma, pode-se adicionar novos atributos além do padrão, seguindo uma regra, o que éo grande pró desse padrão. Porém, é necessário trabalho adicional para especificar umprotocolo para troca de perfis CC/PP e especificar como um perfil deve ser processado eusado em conjunto a qualquer mecanismo de adaptação de conteúdo.

4.3.4 User Agent Profile (UAProf)

O User Agent Profile (UAProf - Perfil de agente de usuário) é uma implementa-ção da especificação CC/PP desenvolvida pela Open Mobile Alliance (OMA), destinada


a terminais móveis compatíveis com WAP. Seu funcionamento depende da definição, du-rante a requisição, onde o XML que caracteriza o contexto (geralmente um dispositivo)pode ser encontrado, através do parâmetro “X-WAP-Profile”. Por exemplo, o endereço“X-WAP-Profile: http://nds1.nds.nokia.com/uaprof/N95r3.xml” caracterizaria onde estãoas informações do dispositivo N95. Basta que o servidor faça contato com esse link parater conhecimento das capacidades do usuário. Um exemplo de XML com as configuraçõesdo celular Nokia 2160 podem ser vistas na Figura 4.2.

Figura 4.2: Trecho de exemplo de definição de característicascompatíveis com o CC/PP.

O transporte das informações UAProf deve ocorrer por um protocolo que estendeo HTTP, chamado W-HTTP (Wireless HTTP), proposto pela W3C ??, contendo no XMLdados categorizados da seguinte forma:

• Plataforma de hardware: capacidades físicas áudio, tela, interação, dentre outras.• Plataforma de software: sistema operacional, MIME types suportados, codificação

de arquivos, formatos de áudio e vídeo suportados, dentre outros.• Características da rede: Suporte a protocolos de rede, segurança e conectividade.• Características do navegador: informações do navegador, capacidades de tabelas

e janelas, dentre outros.• Características WAP: suporte a WAP/XML e relacionados.• Características do serviço de push: Tipos de conteúdo push suportados, tamanho

máximo de mensagem, dentre outros.


4.3.5 Media queries

Principalmente para os casos onde deseja-se entregar conteúdo construído porlinguagens de marcação, como HTML estilizado com CSS, a W3C recomenda também ouso de media queries, que permite que o estilo seja condicionado a um número de catego-rias de dispositivos denominadas: all (geral), aural (sintetizadores de som e voz), braille

(dispositivos com suporte tátil), embossed (impressoras braille), handheld (dispositivospequenos), print (impressoras), projection (projetores), screen (computadores comuns),tty (teletipos e terminais) e tv (aparelhos televisores).

Nas media queries, as características do contexto (“media features”) são consul-tadas e combinadas através de uma expressão restrita, de forma que o CSS possa adaptaro conteúdo de acordo com o encontrado (Figura 4.3). Porém, tal adaptação também podeocorrer, totalmente ou em parte, no servidor, que envia o conteúdo já pronto.

Figura 4.3: Exemplo de customização via descoberta do contextono CSS.

A crítica feita à media queries está relacionada ao fato que nem todos navegado-res dão suporte a tal tecnologia.

4.3.6 Synchronized Multimedia Integration Language (SMIL)

O Synchronized Multimedia Integration Language (SMIL - Linguagem de Inte-gração multimídia sincronizada) é mais um padrão W3C e introduz um novo vocabuláriopara o acesso a um número limitado de características dos dispositivos, como largura datela, largura de banda, sistema operacional e processador.

A versão 2.0 desse padrão define um conjunto de módulos de marcação quepodem ser integrados em perfis de dispositivos, guardados em um servidor que a aplicaçãoprovedora pode consultar a qualquer hora.

Para que o SMIL possa funcionar, o cliente, geralmente um navegador, devepossuir um plugin.

4.3.7 MPEG-21

O MPEG-21 é um framework ainda não finalizado, proposto pela ISO/IEC e quepretende dar suporte ao uso transparente de recursos multimídia através de uma grande

4.4 Locais de adaptação (Onde) 58

extensão de contextos. Ele não só deseja entregar conteúdo depois da identificação dodispositivo, mas também trata de direitos das mídias.

Enxergando o arquivo como um ‘item digital”, a especificação propõe queos clientes devem descrever, pelo menos, as capacidades do terminal, rede, usuário eambiente, trabalhando inclusive em conformidade com a especificação CC/PP.

Por estar ainda em desenvolvimento, este padrão ainda não tem muitos exemplos,mas pode se tornar referência no futuro para a entrega de áudio e vídeo digital.

4.4 Locais de adaptação (Onde)

“O lugar onde a adaptação ocorrerá é a base para a classificação das soluções deadaptação do conteúdo” [102]. Atualmente, classificamos em três os locais onde ela podeocorrer: Servidor, cliente ou agente intermediário (proxy).

4.4.1 Servidor

A adaptação no servidor dá ao fornecedor da aplicação de personalização o maiorpoder possível sobre a entrega do conteúdo. O servidor pode codificar seus recursos comos parâmetros que deseja, porém ele precisa de mecanismos para conhecimento do con-texto e poder computacional suficiente para atender várias requisições de personalizaçãoao mesmo tempo. Por outro lado, a sobrecarga do cliente não existirá, pois este só consu-mirá o produto final já adaptado.

4.4.2 Cliente

A adaptação pelo cliente não é recomendada porque, dada a grande heteroge-neidade de aparelhos e contextos, a conversão tem boas chances de falhar, tornando aexperiência do usuário pior, principalmente por causa de falta de suporte e tempo de res-posta.

O “beneficiado” neste caso é o servidor, que não precisará ter nenhum meca-nismo de adaptação. Basta enviar o conteúdo, como a maioria faz isso (e seus conteúdosnão funcionam na maioria dos dispositivos móveis).

Um dos únicos casos de sucesso dessa abordagem é a adaptação de páginas web(HTML) via folha de estilos (CSS), onde o navegador web do celular é o responsável porrenderizar o conteúdo da página para o contexto especificado.

4.5 Tipos de adaptação (Quando) 59

4.4.3 Proxy

A adaptação via agente intermediário é uma forma de atender as requisições deforma transparente, tanto para o cliente quanto para o servidor, evitando que o servidor sesobrecarregue e que o cliente não consiga adaptar o conteúdo por falta de capacidade.

Geralmente realizada por um proxy, a adaptação via agente intermediário ocorreem um nó separado do sistema (servidor), que só repassa as requisições do cliente. Comacesso aos arquivos a serem adaptados, o proxy atende as requisições de cliente a ele re-direcionadas, realiza o processamento necessário e retorna o(s) arquivo(s) personalizadospara o usuário.

Logo, essa é a forma menos onerosa, tanto para o cliente quanto para o servidor,mas requer cuidado na comunicação entre os componentes do sistema, pois todo otrabalho ocorre através da troca de mensagens.

Os proxys geralmente também dão suporte a caching, fazendo com que algunspedidos possam ser entregues com maior rapidez.

4.5 Tipos de adaptação (Quando)

Segundo [102], existem três tipos de adaptação: estática, dinâmica e híbrida, quedefinem em que etapa do processo de entrega do conteúdo a personalização ocorre.

4.5.1 Estática

A adaptação estática é caracterizada pela conversão dos arquivos antes dasrequisições, o que demanda um pré-processamento do recurso pelo servidor e maioralocação de espaço físico. Porém, ao receber a requisição, o arquivo já estará pronto paraa resposta, que é retornada instantaneamente para o cliente. Além disso, em tempos decloud computing, o maior uso de espaço físico se torna um contra menos custoso.

Esse tipo de adaptação é indicado para os casos em que a conversão demoratempo razoavelmente grande o suficiente para prejudicar a experiência do usuário naaplicação.

4.5.2 Dinâmica

A adaptação dinâmica é caracterizada pela conversão durante o processo derequisição do usuário, o que geralmente demanda maior tempo de resposta, pois o tempode resposta é compatível com o tempo de execução da adaptação. Por isso, existe maiornecessidade de poder de processamento para diminuir a espera do usuário. Porém, não hásobrecarga de espaço de gravação, pois os arquivos adaptados não ficam guardados.

4.6 Seleção de conteúdo (O que) 60

Uma das técnicas que se usa para melhorar a adaptação dinâmica é o uso dechaching, ou seja, guardar temporariamente objetos que são requisitados para minimizaro tempo de futuras requisições.

Esse tipo de adaptação é indicado para os casos onde a conversão dos arquivosdemora pouco tempo ou quando a geração de novas versões persistidas tem um custo altopara o sistema.

4.5.3 Híbrida

A adaptação híbrida consiste na realização de dois tipos de adaptação, estáticae dinâmica, cooperativamente ou não. Dessa forma, pode-se aproveitar o melhor de cadaadaptação, dado o tipo de mídia.

O único contra da adaptação híbrida é o problema do gerenciamento do sistemaquanto à escolha do que pré-adaptar e o que deixar para adaptação “em tempo deexecução”.

4.6 Seleção de conteúdo (O que)

Antes de adaptar um conteúdo para um certo perfil (conjunto de contextos) oucontexto específico, é necessário responder à seguinte pergunta: “É realmente necessáriogerar uma nova versão do recurso?”.

Em muitos casos, as restrições do aparelho exigem que conversões sejam rea-lizadas. Em outros, versões já existentes podem ser utilizadas, evitando processamentosdesnecessários e também espaço de gravação.

Para definir se é necessária uma conversão, temos duas abordagens: a trivial e abaseada em algoritmo de decisão. A abordagem trivial é bem simples e não sabe muitosdetalhes: Se existe versão diretamente ligada ao contexto, entregá-la. Senão, realizar novaconversão. Já a abordagem baseada em algoritmos de decisão é mais complexa e envolveproblemas de decisão.

Muitas são as abordagens não-triviais para decidir, dado recurso, suas proprieda-des e o contexto alvo, qual é a sua versão mais compatível. Dentre elas podemos destacaro uso de scoring e árvores de decisão.

Nas técnicas de scoring, para cada contexto são atribuídos valores de preferênciapara cada item, por exemplo, quantidade de cores e tamanho de tela. Dado uma versãodo arquivo, esta é avaliado e é dada uma nota de compatibilidade com o contexto. Casoatinja o valor esperado, ela é escolhida para a entrega ao usuário. Caso não seja, pode-se procurar em todas as outras se há harmonização. Se não encontrar nenhuma versãocompatível, retorna-se erro ou chama-se a criação de uma nova adaptação.

4.7 Forma de adaptação (Como) 61

Os problemas de decisão também podem ser resolvidos com árvore de decisão:Para cada propriedade do contexto alvo, a versão do arquivo é analisada até que se cheguea uma folha, que responde positivamente ou negativamente à compatibilidade.

4.7 Forma de adaptação (Como)

Para manipular a mídia e torná-la um recurso de qualidade a ser usado em ensino,existem três tipos de adaptações possíveis: escala, mudança de formato e mudança demodo [101].

É importante destacar que qualquer conversão de arquivo envolve perda dequalidade, mesmo que ínfima.

4.7.1 Escala

A escala consiste na eliminação, redução ou qualquer geração de versão mo-dificada de um arquivo sem que se mude o formato. Geralmente usada para diminuir otamanho ou a complexidade do arquivo, tem como exemplo a mudança de resolução emarquivo visual, mudança em taxa de qualidade em algum item de mídia audiovisual ecompressão de dados no caso de um texto.

4.7.2 Mudança de formato

A mudança de formato supõe a transformação de um recurso de uma codificaçãopara outra. A transcodificação para o arquivo alvo deve envolver vários parâmetrosespecíficos para o tipo de mídia. Um exemplo de conversão por mudança de formato éa transformação de uma página WEB, de HTML para WML, para que seja possível suavisualização em um celular.

Essa metodologia de conversão geralmente é utilizada para resolver casos deproblema de suporte a formatos nos dispositivos.

4.7.3 Mudança de modo

A adaptação por mudança de modo é o processo que consiste na mudança detipo do arquivo para outro ou na integração de vários arquivos de diferentes tipos emum só. Este processo é mais utilizado para resolver problemas pedagógicos, não ligadosà tecnologia, e podemos citar como exemplos a transformação de um vídeo em váriasimagens, a transformação da imagem em um texto e a síntese de texto, áudio e imagensem um vídeo.

4.8 Trabalhos relacionados 62

A mudança de modo é uma atividade que envolve mais variáveis que as anteri-ores e por isso necessita, muitas vezes, de um agente humano. É mais difícil tornar talprocesso computadorizado.

4.8 Trabalhos relacionados

A área de adaptação de conteúdo possui muitos artigos sobre teoria e desenvol-vimento de aplicações. Dentre os trabalhos mais importantes, podemos destacar:

1. Mohan, Smith e Li [88] foram um dos pioneiros da adaptação moderna, em 1999, aocriar uma aplicação que aninhava contextos de usuário hierarquicamente, de formaque a customização seguisse padronizada para cada nível de contexto utilizado,principalmente para dispositivos móveis.

2. Metso et. al [34] fizeram um importante trabalho que introduz embasamento teóricosobre adaptação de serviços multimídia para dispositivos móveis, principalmente anivel arquitetural.

3. Lemlouma e Layaida [76] apresentaram uma arquitetura para adaptação de contextopara dispositivos móveis através do reconhecimento do usuário via cabeçalhos doprocolo HTTP.

4. Zhao e Okamoto [130] propuseram um framework de adaptação dinâmica deconteúdo para u-learning levando em conta diferentes contextos, como capacidadesdo dispositivo, preferências dos professores, localização do estudante.

5. Serrano et. al propuseram um sistema de adaptação de conteúdo centrado notrabalho de multi-agentes móveis. O uso de sistemas multi-agentes em adaptaçãode conteúdo se tornou comum, principalmente para converter o conteúdo existente.

6. Lum e Lau [127] fizeram um estudo sobre ferramentas de decisão de escolha deconteúdo para adaptação, apresentando uma nova engine para escolha ótima deconteúdo.

7. Lum e Lau [84] também fizeram um trabalho que compara as decisões tomadas emsistemas de adaptação de conteúdo quanto à relação de uso do CPU e consumo deespaço de gravação. Ao final, apresentaram um modelo para criação de sistemasque pudessem balancear essas duas restrições da área.

8. Reveiu et. al [102] fizeram uma revisão da área de adaptação de conteúdo, propondoum futuro sistema baseado na entrega de arquivos via MPEG-21.

9. Lau et. al [74] apresentaram um modelo de adaptação de Web Services paradiferentes contextos, avaliando a eficiência e eficácia da adaptação de serviços nainternet.


10. Bartholo et. al [41] apresentaram um modelo de adaptabilidade para ambientesmóveis de aprendizagem (M-AVA), com diretrizes para o uso da idéia proposta.Atualmente, este modelo é utilizado no Brasil.

11. O Amadeus [80] é um software brasileiro que oferece adaptação de conteúdo eserviços de e-learning para dispositivos móveis.

12. Yang et. al [126] apresentaram uma aplicação de sucesso para adaptação de con-teúdo aplicada, em Taiwan, ao software Blackboard, um dos maiores LMS domundo. Ao final, foi verificado que a provisão de recursos adaptados melhoroua colaboração entre os estudantes.

13. O laboratório de mídias da TeleSonera [87] fez um estudo sobre o estado da arteem adaptação de conteúdo na web, apresentando também algumas comerciais exis-tentes na área, como Oracle Application Service Wireless, WebSphere Publisher,MobiXtar e Cocoon.


Dados os desafios tecnológicos existentes, o Odin pretende resolve-los atravésda adaptações para diferentes contextos.

No estabelecimento da arquitetura (Seção 5.3), foram realizadas algumas deci-sões de projeto importantes relacionadas ao tema, das quais podemos destacar:

• O Odin combina duas técnicas de reconhecimento de contexto: Parâmetros de requi-sição e cabeçalho HTTP (User-Agent). O segundo serve para identificar aparelhos,ou seja, o contexto tecnológico. Já o primeiro serve para identificar contextos maisespecíficos, ligados principalmente à pedagogia envolvida no u-learning.

• O Odin aplica a adaptação estática, pois apesar dela alocar mais espaço físicono servidor, tem menor custo computacional do que a dinâmica e oferece menosatrasos aos usuários, tornando-o mais focado no estudo. Por exemplo, converterum vídeo Full HD para FLV em tempo de requisição demoraria tanto tempo quefrustraria o estudante.

• O Odin pode atuar tanto como servidor principal de objetos de aprendizagem oucomo um proxy de adaptação, evitando que o servidor de uma aplicação LMScliente se sobrecarregue e que seus usuários não consigam adaptar o conteúdo porfalta de capacidade.

• O Odin deve trabalhar com todas as formas de adaptação possíveis, dando flexibili-dade para o administrador escolher como converterá os arquivos para os perfis.

• O Odin verifica a compatibilidade de arquivos através de uma função de decisão,que calcula a compatibilidade de contexto. Dessa forma, uma só adaptação pode serfeita para mais de um contexto.

CAPÍTULO 5Odin : Viabilização de e-learning em múltiplosdispositivos

5.1 Introdução

O processo de desenvolvimento de software envolve várias etapas durante seuciclo de vida.

O Odin é uma nova solução proposta para adaptação de conteúdo para várioscontextos e aplicável em u-learning. Logo, o projeto passou por várias etapas até odesenvolvimento do código final da aplicação, quando foi aplicado todo o conhecimentoobtido todo o embasamento teórico descrito nas seções anteriores.

Este capítulo descreve, de modo geral, o que é o Odin, onde ele se aplica e comofoi projetado. Assim, nas seções seguintes seguem a descrição da arquitetura, requisitos eimplementação da solução Odin.

5.2 Requisitos

O processo de Engenharia de Requisitos é aquele responsável pelo entendimentodo problema e do ambiente em questão para a definição de funcionalidades que atendamàs necessidades e expectativas. Algumas das atividades envolvidas nessa fase incluem acompreensão do domínio, identificação das partes interessadas, identificação dos proble-mas e captura de requisitos.

Para a especificação do Odin, foi utilizada a pesquisa de levantamento do cenáriona área através de artigos científicos, além de entrevistas e conversas informais comprofissionais da área de ensino, computação móvel e ubíqua. Primeiramente, foramlevantados os problemas, juntamente com os envolvidos no processo de criação, consumoe manutenção de objetos de aprendizagem em u-learning.

Dos principais problemas encontrados na área de u-learning durante o desenvol-vimento da pesquisa, os mais relevantes escolhidos para o projeto foram:

5.2 Requisitos 65

• Dificuldade do professor em saber todos os requisitos tecnológicos e pedagógicosnecessários para construção de objetos de aprendizagem para contextos diferentes.

• Dificuldade ou impossibilidade dos alunos na visualização de objetos de aprendi-zagem não personalizados para seus contextos.

• Pouca reutilização de objetos de aprendizagem na criação de novas versões domesmo para diferentes contextos.

• Falta de suporte das aplicações LMS ao u-learning.

Dados os problemas, definimos as necessidades que o Odin deve atender:

• Eficácia na execução de objetos de aprendizagem em múltiplos contextos.• Eficiência na execução de objetos de aprendizagem em múltiplos contextos.• Melhorar a produtividade do professor na criação de objetos de aprendizagem

personalizados.• Melhorar o suporte ao u-learning nas aplicações de gerência de ensino existentes.

Após entender problemas e necessidades, foram eliciados os requisitos funci-onais do Odin. Tal especificação é detalhada no Apêndice A, em conformidade com anorma IEEE 830. Podemos resumir o escopo no trecho abaixo:

“O Odin é uma ferramenta para adaptação de conteúdo educacional para diferen-tes dispositivos, que funciona através da conversão prévia de arquivos via agente humanoou software no servidor e é oferecida como um serviço a ser utilizado pelas plataformasde ensino existentes, como um serviço de base de dados de objetos educacionais. Seuobjetivo é oferecer transparência tanto na conversão de arquivos para vários dispositi-vos, desonerando o professor/conteudista, quanto no download de objetos educacionaispersonalizados, tornando a experiência do u-learning para o aluno mais agradável.

Há três maneiras principais de uso dos dispositivos como ferramenta para oe-learning: acesso a mídia, comunicação ou ambas. O foco do Odin é somente tratardos casos de acesso à mídia, ou seja, não trata da adaptação de dados ou interface parasoluções baseadas na interação entre os usuários”.

Um ator na Engenharia de Software representa um papel executado por umusuário ou por um outro sistema que interage com a solução modelada. A seguir sãodescritos os atores que vão interagir com o Odin:

• Administrador: Profissional com experiência em administrar sistemas de compu-tação e com conhecimento de dispositivos móveis e contextos de ensino. Seu papelé customizar e administrar todos os componentes do sistema sem trabalhar neces-sariamente com código-fonte. Seu objetivo é, principalmente, garantir a maior dis-ponibilidade possível dos dados corretos aos outros usuários.

5.2 Requisitos 66

• Desenvolvedor de LMS: Mantenedor e desenvolvedor de aplicações de gerencia-mento de ensino, com conhecimento em programação e arquitetura Web. Tambémé desejado conhecimento em APIs de conversão multimídia. Seu principal obje-tivo no nosso contexto é fazer a comunicação da sua aplicação com o Odin, viaWeb Services. Além disso, também pode ser o responsável por desenvolver novosconversores de arquivos para o sistema.

• Professor: Profissional com experiência em docência e conhecimento de médiopara baixo em computação. Pode ter dificuldades com manipulação de softwaresna internet e conhecimento restrito na confecção de objetos de aprendizagem. Seupapel dentro do Odin é a inserção de recursos no repositório de LOs. Ele não possuiresponsabilidades relativas à administração do sistema.

• Aluno: Estudante com conhecimento variável em computação e médio no uso dedispositivos móveis. Pode ter dificuldades motoras e estar em diferentes locais.Seu único papel no sistema é consumir os recursos personalizados, oferecidos pelosistema de ensino.

• Conteudista: Profissional com conhecimento em computação e dispositivos mó-veis, além de grande domínio de ferramentas de conversão e design gráfico e deinteração. Seu objetivo no Odin é criar versões dos objetos de aprendizagem, en-viados pelo professor, para os diferentes contextos, à medida do aparecimento derequisições de conversão pelo Odin.

• Sistema LMS: Sistema LMS, que oferece funções de gerência de ensino em e-

learning. Seu interesse com o Odin é a “terceirização” da adaptação de conteúdo.

Figura 5.1: Classificações dos atores quanto a seu uso da soluçãoOdin.

5.2 Requisitos 67

O modelo de caso de uso também é instrumento para descrição dos requisitosfuncionais de um sistema computacional. Podemos citar alguns casos de uso importantes:

• Cadastrar usuário: Ação de cadastrar um usuário no sistema, seja ele professor,novo administrador, conteudista e até aluno. Este último pode ser opcional. Reali-zado pelo administrador, também está relacionado a casos de uso de manutenção detais dados.

• Cadastrar conversor: Ato de cadastrar uma entidade conversora, seja essa umhumano ou uma implementação da API de conversão do Odin. Realizada peloadministrador, é relacionado aos outros casos de uso de configuração do sistema.

• Cadastrar configuração de mídia: Procedimento de cadastro de configurações deáudio, imagens, vídeo e documentos, que posteriormente devem ser relacionadosa perfis de mídia. Cada classe de arquivo possui seus dados específicos. Tambémrelacionado ao administrador, esse caso de uso também pode compreender futurasatualizações dos dados cadastrados.

• Cadastrar perfil de mídia: Ação de cadastrar um novo perfil de mídia, que atuacomo uma família de dispositivos. Para isso, depende de configurações de mídiae conversores cadastrados. Realizada pelo administrador, é pré-requisito para ocadastro de um contexto.

• Cadastrar contexto: Ato de cadastrar um contexto, que pode estar relacionado aum dispositivo ou a uma situação que o usuário se encontra. Neste último caso, oadministrador deve definir uma String específica que identifica o contexto especial.

• Pesquisar objetos de aprendizagem: Procedimento de buscar objetos de apren-dizagem através de meta-informações do recurso. Pode ser realizada por qualquerator.

• Upload de objeto de aprendizagem diretamente no Odin: Recebimento de objetode aprendizagem para gravação do original e posterior conversão.

• Upload de objeto de aprendizagem por aplicação LMS: Recebimento de objetode aprendizagem para gravação do original e posterior conversão.

• Adaptação de objeto de aprendizagem: Criação de versões adaptadas no sistema.Inclui as conversões necessárias após a gravação do original e pode envolver oconteudista.

• Download de objeto de aprendizagem diretamente no Odin: Envio de objeto deaprendizagem ao usuário, que inclui a descoberta de contexto, escolha de melhorversão de adaptação e envio dos recursos.

• Download de objeto de aprendizagem via solução LMS: Envio de objeto deaprendizagem ao usuário que está acessando um sistema LMS. Inclui a descobertade contexto, escolha de melhor versão de adaptação e envio dos recursos.

5.2 Requisitos 68

• Manter configurações de repositório: Manutenção de configurações da localiza-ção e características do repositório. Realizado pelo administrador, está diretamenteligado com o download e upload de objetos de aprendizagem.

• Upload de adaptação de objeto de aprendizagem: Atribuído ao conteudista,constitui-se do upload de versões adaptadas para objetos de aprendizagem exis-tentes. Ocorre somente se já existir requisição de criação da adaptação para certocontexto.

• Visualizar relatórios de conversão: Realizado pelo administrador, consiste navisualização de relatórios de adaptações pendentes e concluídas.

• Visualizar relatórios de download: Realizado pelo administrador, consiste navisualização de relatórios de download de objetos de aprendizagem, podendo sercustomizado para atender desde o acompanhamento de alunos até a verificação dedispositivos mais utilizados.

Dos casos de uso acima, cinco são mais importantes e precisam ser vistos commais cuidado, pois são os mais percebidos por seus usuários finais: upload de LO direta-mente no Odin, upload de LO via solução LMS, adaptação de objetos de aprendizagem,download de LO diretamente no Odin e download de objeto de aprendizagem via soluçãoLMS, que são detalhados nas Tabelas 5.1, Tabela 5.2, Tabela 5.3, Tabela 5.4 e Tabela 5.5,respectivamente.

5.2 Requisitos 69

Nome: Upload de objeto de aprendizagem diretamente no Odin.Descrição: Upload de recursos de objeto de aprendizagem para o sistema Odin.Ator principal: Professor.Pré-condições:

• O professor conhece a URL de acesso à página de upload do sistema.

Pós-condições:

• O sistema grava, com sucesso, os arquivos recebidos pelo usuário.• O remetente recebe confirmação de resposta do sistema.

Fluxo principal:1. O professor preenche os campos de arquivo, título do objeto de aprendizagem (texto),palavras-chave (texto), descrição (texto), a estratégia de entrega (item de lista) do LO e submeteo formulário.2. O Odin recebe o formulário e percebe que nenhum campo está faltando ou está vazio.3. O sistema verifica que não há descritor SCORM no pacote enviado.4. O sistema salva o(s) arquivo(s) enviados no pacote.5. O sistema gera um código único para o objeto de aprendizagem.6. O sistema salva o objeto de aprendizagem e seus atributos.7. O sistema retorna sucesso ao usuário, juntamente com o código do objeto de aprendizagemenviado.Fluxos secundários:2.1. Caso o campo “arquivo” seja um arquivo vazio ou inexistente, o sistema retorna tal erro aousuário. Fim do caso de uso.2.2. Caso o campo “título” esteja vazio, o sistema retorna tal erro ao usuário. Fim do caso deuso.2.3. Caso o campo “descrição” esteja vazio, o sistema retorna tal erro ao usuário. Fim do casode uso.2.4. Caso o campo “palavras-chave” esteja vazio, o sistema retorna tal erro ao usuário. Fim docaso de uso.2.5. Caso nenhuma estratégia de entrega seja marcada, o sistema atribui a estratégia padrão aoobjeto de aprendizagem. O caso de uso segue seu fluxo normal.3.1. O sistema verifica que há descritor SCORM no pacote enviado e adiciona os metadadadosdescritos no objeto de aprendizagem. O caso de uso segue seu fluxo normal.4.1. O sistema gera erro ao salvar o arquivo e, por isso, retornar descrição do problema aousuário. Fim do caso de uso.

Tabela 5.1: Caso de uso do upload de objetos de aprendizagemdiretamente pela ferramenta Odin.

5.2 Requisitos 70

Nome: Upload de objeto de aprendizagem através de solução LMS.Descrição: Upload de recursos de objeto de aprendizagem para o sistema Odin, via soluçãoLMS.Atores principais: Professor e Sistema LMS.Pré-condições:

• O professor conhece a URL de acesso à página de upload do LMS.• O sistema Odin tem seu ponto de acesso corretamente configurado no sistema LMS.

Pós-condições:

• O sistema Odin grava, com sucesso, os arquivos recebidos pelo usuário.• O remetente recebe confirmação de resposta do sistema.

Fluxo principal:1. O professor envia um objeto de aprendizagem ao sistema LMS, contendo nessa requisiçãodados dos campos de arquivo, título do objeto de aprendizagem (texto), palavras-chave (texto),descrição (texto), a estratégia de entrega (item de lista) do LO e submete o formulário.2. O sistema LMS cria uma instância local do objeto de aprendizagem (com os dados que julgarconveniente) e redireciona a requisição de gravação diretamente para o Odin.3. O Odin recebe o formulário e percebe que nenhum campo está faltando ou está vazio.4. O sistema verifica que não há descritor SCORM no pacote enviado.5. O sistema salva o(s) arquivo(s) enviados no pacote.6. O sistema gera um código único para o objeto de aprendizagem.7. O sistema salva o objeto de aprendizagem e seus atributos.8. O sistema retorna sucesso ao sistema LMS, juntamente com o código do objeto de aprendi-zagem enviado.9. O Sistema LMS anexa o código do LO no Odin à instância de objeto de aprendizagem local.10. O Sistema LMS grava a instância local do objeto de aprendizagem. 11. O sistema LMSconfirma ao usuário o recebimento e gravação dos recursos.Fluxos secundários:2.1. Caso o campo “arquivo” seja um arquivo vazio ou inexistente, o sistema retorna tal erroao sistema LMS, que exclui a instância de objeto de aprendizagem recém-criada e repassa adescrição do erro ao usuário. Fim do caso de uso.3.2. Caso o campo “título” esteja vazio, o sistema retorna tal erro ao sistema LMS, que excluia instância de objeto de aprendizagem recém-criada e repassa a descrição do erro ao usuário.Fim do caso de uso.3.3. Caso o campo “descrição” esteja vazio, o sistema retorna tal erro ao sistema LMS, queexclui a instância de objeto de aprendizagem recém-criada e repassa a descrição do erro aousuário. Fim do caso de uso.3.4. Caso o campo “palavras-chave” esteja vazio, o sistema retorna tal erro ao sistema LMS,que exclui a instância de objeto de aprendizagem recém-criada e repassa a descrição do erro aousuário. Fim do caso de uso.3.5. Caso nenhuma estratégia de entrega seja marcada, o sistema atribui a estratégia padrão aoobjeto de aprendizagem. O caso de uso continua seu fluxo normal.4.1. O Odin verifica que há descritor SCORM no pacote enviado e adiciona os metadadadosdescritos no objeto de aprendizagem. O caso de uso segue seu fluxo normal.7.1. O Odin gera erro ao salvar o arquivo e, por isso, retornar descrição do problema ao sistemaLMS, que exclui a instância de objeto de aprendizagem recém-criada e repassa a descrição doerro ao usuário. Fim do caso de uso.

Tabela 5.2: Caso de uso do upload de objetos de aprendizagem noOdin através de solução LMS.

5.2 Requisitos 71

Nome: Adaptação de objeto de aprendizagem

Descrição: Criação de versões de objetos de aprendizagem para diferentes contextos, à partir

dos conversores.

Atores principais: Administrador e conteudista.

Pré-condições:

• O administrador já inseriu todas as informações necessárias para a homologação de

contextos de usuário.

• O Odin chamou o caso de uso de adaptação de objeto de aprendizagem após um upload

de objeto de aprendizagem.

• Um perfil de contexto foi escolhido para adaptação

• Todos os usuários envolvidos têm acesso as funcionalidades do sistema.

Pós-condições: Todos os perfis existentes possuem uma versão adaptada do objeto de aprendi-

zagem.

Fluxo principal:1. O sistema escolhe o primeiro arquivo do objeto de aprendizagem.

2. O Odin verifica o tipo do arquivo (áudio, vídeo, imagens, texto e documento).

3. O sistema recupera o conversor para tal tipo de arquivo.

4. O sistema percebe que o conversor é um usuário cadastrado (conteudista).

5. O sistema cria um ticket de conversão para tal arquivo e perfil, alocando-o a tal usuário.

6. O conteudista marca que começou a fazer a conversão do arquivo.

7. O conteudista envia a versão convertida do arquivo para o sistema.

8. O sistema relaciona esse arquivo ao original e a uma adaptação ligada ao objeto de

aprendizagem original e ao perfil atual.

9. O Odin salva as informações.

10. Não há mais arquivos para adaptar.

Fluxos secundários:4.1. O sistema percebe que o conversor é software e vai para o passo 5.1.

O sistema coloca o arquivo na fila de conversão para os recursos de tal tipo.

Chega a vez do arquivo e ele é convertido para o perfil especificado, sendo salvo no sistema de

arquivos. Continua no passo 8.

10.1. Há mais arquivos para adaptar e o sistema volta para o passo 1, escolhendo o próximo

arquivo do pacote do objeto de aprendizagem.

Tabela 5.3: Caso de uso de adaptação de objetos de aprendizagem.

5.2 Requisitos 72

Nome: Download de objeto de aprendizagem diretamente pelo Odin.

Descrição: Ação de encontrar e fazer o download dos recursos de um objeto de aprendizagem

para um determinado contexto.

Ator principal: Aluno

Pré-condições:

• O usuário conhece a URL de acesso ao sistema.

Pós-condições:O usuário recebe o objeto de aprendizagem desejado ou alguma notificação de erro, caso sua

requisição não seja válida.

Fluxo principal:1. O usuário faz uma pesquisa de recursos de acordo com atributos desejados e submete ao

Odin. 2. O sistema pesquisa objetos de aprendizagem que possuem os atributos necessários e

retorna ao discente uma lista com os LOs que concidem com a requisição. 3. O aluno escolhe

todo o conteúdo objeto de aprendizagem e faz a requisição deste ao Odin.

4. O Odin verifica que a estratégia de entrega para o objeto de aprendizagem requisitado está

marcada como “Somente adaptado”.

5. O Odin verifica o contexto do usuário, que é homologado.

6. O sistema recupera todos os recursos escolhidos do objeto de aprendizagem para seu

contexto, de acordo com o contexto e estratégia de entrega.

7. O sistema envia o pacote ao usuário.

Fluxos secundários:2.1. O sistema não encontra nenhum objeto de aprendizagem que coincida com os campos da

requisição, retornando erro de LOs inexistentes para o usuário. Fim do caso de uso.

3.1. O aluno escolhe somente parte do objeto de aprendizagem para o download.

4.1. O sistema verifica que a estratégia de entrega no Odin é “Somente original”.

4.2. O Odin verifica que a estratégia de entrega no Odin é “Adaptado, senão original”.

5.1. O sistema não consegue verificar o contexto do usuário. Logo, atribui-se como o contexto

o “original”, relacionado ao objeto de aprendizagem original. O caso de uso continua normal-

mente.

6.1. O conjunto de recursos voltado ao contexto do usuário e estratégia de entrega do LO é

vazio. O sistema Odin retorna ao usuário um erro de arquivos indisponíveis.Fim do caso de

uso.

Tabela 5.4: Caso de uso do download de objetos de aprendizagemdiretamente pelo Odin.

5.2 Requisitos 73

Nome: Download de objeto de aprendizagem via aplicação LMS.

Descrição: Ação de encontrar e fazer o download dos recursos de um objeto de aprendizagem

para um determinado contexto, onde o usuário interage via solução LMS.

Ator principal: Aluno

Pré-condições:

• O usuário conhece a URL de acesso ao sistema LMS;

• O sistema LMS está corretamente ligado ao Odin.

Pós-condições:O usuário recebe o objeto de aprendizagem desejado ou alguma notificação de erro, caso sua

requisição não seja válida.

Fluxo principal:1. O usuário faz uma pesquisa de recursos de acordo com atributos desejados e submete ao

sistema LMS. 2. O sistema LMS pesquisa no Odin os objetos de aprendizagem que possuem

os atributos necessários e retorna ao discente uma lista com os LOs que coincidem com a

requisição. 3. O aluno escolhe todo o conteúdo objeto de aprendizagem e faz a requisição deste

ao sistema LMS.

4. O sistema LMS repassa a requisição ao Odin.

5. O Odin verifica que a estratégia de entrega para o objeto de aprendizagem requisitado está

marcada como “Somente adaptado”.

6. O Odin verifica o contexto do usuário, que é homologado.

7. O Odin recupera todos os recursos escolhidos do objeto de aprendizagem para seu contexto,

de acordo com o contexto e estratégia de entrega.

8. O Odin envia o pacote ao usuário.

Fluxos secundários:2.1. O Odin não encontra nenhum objeto de aprendizagem que coincida com os campos da

requisição, retornando erro de LOs inexistentes para o sistema LMS, que repassa ao usuário.

Fim do caso de uso.

3.1. O aluno escolhe somente parte do objeto de aprendizagem para o download.

4.1. O Odin verifica que a estratégia de entrega no Odin é “Somente original”.

4.2. O Odin verifica que a estratégia de entrega no Odin é “Adaptado, senão original”.

5.1. O Odin não consegue verificar o contexto do usuário. Logo, atribui-se como o contexto

o “original”, relacionado ao objeto de aprendizagem original. O caso de uso continua normal-

mente.

6.1. O conjunto de recursos voltado ao contexto do usuário e estratégia de entrega do LO é

vazio. O sistema Odin retorna ao usuário um erro de arquivos indisponíveis.Fim do caso de

uso.

Tabela 5.5: Caso de uso do download de objetos de aprendizagemvia aplicação LMS.

5.3 Arquitetura do sistema 74

Finalmente, existem alguns princípios importantes do projeto de software doOdin. São eles: transparência, experiência do aluno, flexibilidade e reusabilidade.

A transparência está na qualidade do serviço oferecido a professores e estudan-tes. Discentes não devem precisar saber sobre como deve trabalhar com o conteúdo paracobrir as necessidades especiais dos seus alunos. Ele deve somente construir o material,pensando nos pontos importantes a serem ensinados. Já os alunos não devem precisarescolher a melhor versão do material para seus aparelhos. Eles devem somente pedir omaterial e recebê-lo de forma personalizada.

A experiência de discentes com a ferramenta computacional é importante emuma ferramenta de e-learning. A experiência do aluno no Odin é potencialmentemelhorada pelo fato da restrição de que este só recebe o material otimizado para seucontexto, fazendo que ele aproveite o melhor possível e tenha acesso a recursos de boaqualidade.

A flexibilidade permite que um ambiente possa se adequar melhor a umainstituição de ensino. O Odin é flexível ao permitir que novos conversores, inclusivehumanos, existam para fazer o melhor trabalho possível com os recursos enviados peloprofessor. Além disso, a estratégia de entrega do material (“Somente original”, “Somenteadaptado” ou “Adaptado, senão original”) também pode ser gerenciada, pois nem sempreum arquivo adaptado é a melhor opção.

A reusabilidade faz com que a produtividade dos discentes aumente, sem queeles precisem refazer trabalho já feito por ele e por outros. Para isso, ele precisa conhecero que pode usar. O Odin oferece suporte ao padrão de objetos de aprendizagem SCORM,que é uma padronização de metadados que permite, dentre outros prós, uma melhorcatalogação dos dados. Logo, o Odin aumenta o potencial de reusabilidade dos objetosde aprendizagem, não somente por adaptar objetos de aprendizagem a outros locais, masfacilitando a procura e o entendimento do propósito de cada um.

5.3 Arquitetura do sistema

O projeto de software é um processo em que, a partir dos requisitos do software,decompõe-se o sistema em componentes e determina-se seus relacionamentos, especifi-cando interfaces, funcionalidades e identificando oportunidades para o reuso. Assim, umavez que o domínio do problema foi esclarecido, o sistema é projetado com o apoio de umaou mais metodologias de forma a resolver o problema em questão.

A arquitetura do sistema é responsável por mostrar como é a configuração dosobjetos computação e como eles estão interligados. Na arquitetura do sistema Odinsão mostrados os objetos considerados importantes para provisão de todos os serviços


registrados na Especificação de Requisitos. A arquitetura detalhada do Odin encontra-seno Apêndice B.

Nessa seção, serão detalhados alguns componentes, distribuídos em pacotes.Uma visualização geral pode ser feita na Figura 5.2.

Figura 5.2: Pacotes de componentes da solução Odin.

5.3.1 Atendimento web

São os componentes responsáveis pelo atendimento das requisições aos usuáriosna internet, que podem ser clientes ou sistemas LMS. Estes componentes só oferecem umainterface às funcionalidades do Odin e, portanto, precisam que o serviços de gerência deconteúdo e de administração estejam funcionando.

Interface gráfica

A interface gráfica é oferecida através de um endereço específico e único na web(URL), onde o administrador tem acesso à manutenção do sistema, o conteudista possuiacesso às funções de relacionadas a suas tarefas de adaptação, o professor tem acessoao serviço de upload de objetos de aprendizagem e os alunos têm acesso ao serviço dedownload de recursos personalizados.


Requisições web

Componente voltado para o uso em soluções LMS que desejam usufruir doserviços do Odin por meio de Web Services. Não há interface gráfica, existindo somenteuma descrição de mensagens HTTP que o cliente pode usar, implementada com REST.

5.3.2 Serviços Administrativos

É o pacote que oferece serviços não relacionados diretamente à adaptação eentrega de conteúdo, mas que provê infraestrutura para que estes sejam realizados. Todosestes serviços são mantidos pelo administrador do sistema Odin.

Controle de acesso

Faz a manutenção dos dados de usuários, que podem ser administradores, con-teudistas, professores e alunos.

Preferências do sistema

Manutenção de preferências de download, upload, localização de repositório eoutras definições importantes para provisão do serviço do Odin, como porta padrão.

5.3.3 Gerência de conteúdo

Pacote principal do Odin, onde estão inseridas todas as funcionalidades deupload, download, gerência e adaptação de objetos de aprendizagem.

Download

Esse conjunto de funcionalidades compreende tudo o que deve ser feito para pro-ver download de conteúdo personalizado para contextos. Ele depende do funcionamentoda gerência de recursos de aprendizagem, além da funcionalidade de descoberta de con-texto. Afinal, sem informações do ambiente do aluno não há como entregar um recursomais oportuno. É dividido em dois grupos:

• Pesquisa - Funcionalidades responsáveis pela pesquisa de conteúdo no Odin. Talpesquisa é feita através do envio de parâmetros do usuário na requisição, seja elavia interface gráfica ou Web Services. Pode retornar qualquer atributo do usuário,via XML ou fluxo simples de dados.

• Requisição - A requisição no Odin só ocorre via código do objeto de aprendizageme a especificação dos recursos de tal LO. Para isso, verifica-se se o objeto deaprendizagem existe e se o contexto do usuário pode ser identificado. O retorno de


pedidos de material segue a especificação do HTTP. Veja na Figura 5.3 o processode download.

Figura 5.3: Em destaque roxo, as funções do componente de requi-sição que são utilizados no download.

Upload

Os componentes de upload são aqueles usufruídos pelo professor para o envio deobjetos de aprendizagem. Ele compreende a persistência do LO, além da leitura de seusmetadados. Por essas duas questões, depende do pacote de gerenciamento de objetos deaprendizagem.

O Odin faz a adaptação antes da requisição e no servidor. Logo, estecomponente também depende do pacote “Adaptação”.

• Parser SCORM - Funcionalidades necessárias para leitura do padrão SCORM,versão 2004, que serão adicionadas como metadados. Ele é nomeado “Parser” porser um leitor de XML de descrição do objeto de aprendizagem.

• Gravação - Funcionalidades necessárias para a gravação de objetos de aprendiza-dos enviados pelo professor, seja em repositório local ou em outro host. Veja na


Figura 5.4 o processo de upload de LOs, onde as funções de tal grupo estão desta-cadas.

Figura 5.4: Hachuradas, destacam-se as funções do componentede gravação que são utilizados no upload.

5.3.4 Adaptação

Esse pacote contém todos os conjuntos de funcionalidades relacionadas à adap-tação de conteúdo para múltiplos contextos. Ele depende do cadastro para conversõesjá feito de possíveis usuários (conteudistas) e da gerência de objetos e aprendizagem jáestabelecida.

Descoberta de contexto

A descoberta de contexto no Odin acontece por leitura de cabeçalho “User-

Agent” do procotolo HTTP, via framework WURFL. Além disso, o usuário pode adicionarinformações extras do contexto via parâmetro da requisição. Caso o sistema não consigaler o contexto do usuário, ele estabelece que este é o “contexto padrão”, comumenterelacionado a aluno sem deficiência, alocado em computadores de mesa.


Contextos e perfis

Não basta que o contexto do Odin seja identificado. Ele deve ser homologadopelo sistema para que adaptações sejam feitas para ele. Este conjunto de funcionalidadestem o objetivo de gerir tais informações.

É importante destacar que contextos devem ser agrupados em perfis, que contêmos conversores e as configurações de mídia comuns a todos.

Configurações de mídia

Conjunto de funcionalidades para a gerência das configurações de áudio, vídeo,imagens e texto. Uma conversão só pode ser feita para uma configuração de mídiaregistrada no sistema.

Adaptação

A Adaptação é o conjunto de funcionalidades que, a partir de informações dosdados necessários para conversão (perfil, conversor e objeto de aprendizagem original),faz o necessário para adaptar os LOs para os contextos existentes. A Figura 5.5 ilustra talprocesso dentro do Odin.

Figura 5.5: Processo de adaptação de objeto de aprendizagem


Conversores

Conjunto de funcionalidades para gerência de conversores humanos e computa-cionais (via API) existentes. Conversores computacionais são arquivos “.jar” que imple-mentam a API de conversão do Odin e devem ser enviados pelo administrador. Converso-res humanos são usuários registrados como “conteudistas”. Tal componente não verificase conversores computacionais realmente implementam a API. Portanto, tal conformidadedeve ser verificada antes pelo administrador.

5.3.5 Gerência de recursos de objetos de aprendizagem

Componente responsável pela criação, atualização, remoção e recuperação dedados originais dos objetos de aprendizagem e suas adaptações. Sem ele, o sistema Odinnão oferece funcionalidade alguma, pois não gravará nem adaptará nenhum LO.

5.3.6 Tecnologias

Java

O protótipo do Odin é oferecido como componente a ser utilizado por diferentesplataformas. Logo, escolhemos a tecnologia Java para implementação, que também já eraconhecida.

A plataforma Java, criada pela Sun Microsystems (Oracle), é mantida peloJava Community Process (JCP), empresas e universidades que através de processosdemocráticos definem a evolução da linguagem. A tecnologia se divide em especificações.As utilizadas no Odin são Java Standard Edition (Java SE) e Java Enterprise Edition

(Java EE). A primeira contém as APIs de funções básicas do sistema, como entradae saída, funções multi-tarefa, redes, conectividade com bancos de dados entre outras.Já o Java EE é a especificação que contém APIs com funcionalidades específicas parao desenvolvimento de aplicações para servidores, tais como Servlets, JSP (Java Server

Pages), EJB (Enterprise Java Beans) e JMS (Java Message Service), todas utilizadas noOdin.

O Java EE é uma extensão do Java SE e acompanha um servidor Web, umservidor de componentes transacionais de negócio, um servidor de banco de dados e umservidor de filas de mensagens. Todos esses serviços são implementados por aplicações dotipo “container web”. No caso do Odin, utilizamos o Glassfish, por prover mais robusteze recursos do que os demais.


WURFL

O Wireless Universal Resource File (WURFL - Arquivo Universal de RecursosSem-fio) é um projeto open-source de identificação de contexto de dispositivos vialeitura de cabeçalho HTTP, mais especificamente o “User-Agent”, presente em todarequisição. Reconhecido pela W3C e recomendado pela OMA, é o mais popular dentreas ferramentas da área e tem como objetivo, permitir que os desenvolvedores abstraiamprogramaticamente as características de diferentes dispositivos, evitar a necessidadede modificar aplicações a cada lançamento de um novo dispositivo móvel e evitar anecessidade de rastrear o lançamento de novos dispositivos.

O funcionamento do WURFL é baseado em um arquivo (XML) de configuraçãoque contém mais de 400 informações de mais de 9000 dispositivos, atualizado periodi-camente. Tais aparelhos estão arranjados em uma árvore, composta por sub-árvores dasfamílias dos dispositivos. Como consequência, assim que um novo dispositivo é lançado,pode-se adicioná-lo seguramente ao WURFL à partir da determinação de sua família ge-nérica, permitindo que o dispositivo herde as características de sua árvore. Este meca-nismo, conhecido como “fall-back”, permite aos desenvolvedores a flexibilidade e reusonecessários em tempos de rápida obsolescência dos aparelhos.

Atualmente existem APIs (Application Programming Interfaces / Interfaces paraProgramação de Aplicações) do WURFL disponíveis para diversas linguagens de progra-mação, como JAVA, PHP, PERL, RUBY, PYTHON e DOT NET que permitem identificarum aparelho e acessar todos os dados necessários. No caso do Java, foi desenvolvida umaque implementa duas funções básicas:

• Identificação de dispositivo através da cadeia de caracteres do cabeçalho “’User-

Agent”;• Retorno de capacidade do aparelho através de seu nome e identificador do disposi-

tivo.

WebServices

Um Web Service é um sistema de software projetado para dar suporte a inte-roperabilidade entre máquinas sobre rede. Ele envia e recebe dados em formato XML,utilizando o protocolo HTTP, fazendo com que os recursos da aplicação estejam disponí-veis sobre a rede de forma normalizada. As instituições responsáveis pela padronizaçãodos Web Services são o W3C e a OASIS (Organization for the Advancement of StructuredInformation Standards - Organização para o Avanço de Padrões em Informação Estrutu-rada).

Em Java existem diversas implementações de Web Services, como o Jersey eMetro. Tais frameworks têm uma relação descritiva em um formato conhecido como

5.4 Implementação 82

WSDL. O WSDL é um documento escrito em XML que, além de descrever o serviço,especifica como acessá-lo e quais as operações ou métodos disponíveis. Dessa forma, acomunicação intersistemas é facilitada e por isso, utilizamos tal tecnologia no Odin.

5.4 Implementação

A implementação do Odin foi feita em Java. seguindo os documentos de re-quisitos e arquitetura e dividindo o código fonte em cinco projetos: “odin-base”, “odin-data”,“odin-servicos”, “odin-web” e “odin-conversores”, seguindo o modelo de camadasarquiteturais definidas na Seção B.13. A relação de dependência entre estes é mostrada naFigura 5.6.

Figura 5.6: Grafo de dependência dos projetos.

O projeto “odin-base” todas as classes de domínio (POJOs - Plain Old Java

Objects) e interfaces do sistema. É a base para todos os outros projetos.O projeto “odin-data” possui a implementação das interfaces de acesso ao banco

de dados, através do padrão Repository. Somente essas classes têm acesso a esses dados.Pensando em tecnologias, foi usado Hibernate JPA e HSQLDB.

O projeto “odin-servicos” possui a implementação das interfaces que contém asregras de negócio das funcionalidades do sistema, através do padrão Service. Depende dosdois projetos anteriores. Pensando em tecnologias, foi usado Hibernate JPA e HSQLDBpara a persistência de dados.

O projeto “odin-web” implementa a interface gráfica e os serviços web paraacesso aos serviços. Depende do projeto “odin-servicos” e é o único acessível aosusuários.

Finalmente, o projeto “odin-conversores” possui a API de conversão do Odin ea implementação de referência das interfaces de adaptação de áudio, vídeo, imagens e

5.4 Implementação 83

texto. Código do “odin-conversores” só trabalha com arquivos e não depende de nenhumoutro projeto.

5.4.1 O ambiente de desenvolvimento

O protótipo do Odin foi implementado na IDE Netbeans (2009), um ambiente dedesenvolvimento integrado e livre para desenvolvimento de software. Ele dá suporte aodesenvolvimento de aplicações em Java e está disponível para os sistemas operacionaisWindows, Linux, Mac OS, todos utilizados durante o desenvolvimento. A IDE possuitambém integração com o servidor Web Glassfish e o banco de dados Java Derby, tambémutilizados no protótipo.

CAPÍTULO 6Considerações finais

6.1 Conclusão

Esse trabalho discutiu alguns dos problemas relacionados à adaptação automá-tica de conteúdo para vários contextos. Os problemas vão desde os pedagógicos até tec-nológicos. Tais dificuldades ainda não foram cobertas pelas atuais soluções LMS, que têmum suporte limitado ao u-learning. Existem propostas para atacar cada problema isolada-mente. Contudo, a combinação delas é inviável de ser trabalhada pelo professor.

Com o objetivo de viabilizar o e-learning, o Odin auxilia usuários na recriaçãode conteúdo adaptado para cada dispositivo no qual se deseja acessá-lo. O Odin torna aoperação de visualização de arquivos menos frustrante (mais qualidade), já que o materialé automaticamente personalizado para o aparelho com o qual o conteúdo é acessado.

Como diferenciais tecnológicos da solução, podemos destacar:

• A flexibilidade quanto aos conversores (agente humano ou computacional) e iden-tificadores de contexto, que facilita a resolução tanto dos problemas pedagógicosquanto os tecnológicos.

• A possibilidade de ser acessado por qualquer sistema de gerenciamento de ensino,atributo o qual não foi encontrado em outras soluções pesquisadas.

• O Odin contempla o conteúdo existente. Dessa forma, ele abre a perspectiva dereutilização da enorme base de objetos educacionais disponíveis para uso em outrosdispositivos, diferentes daqueles para os quais foram criados. Assim, bases atuaispodem empregar o Odin para atingir públicos que fazem uso de outros dispositivosnão contemplados inicialmente.

6.2 Resultados e contribuições

Além da solução oferecida, o projeto Odin também produziu outros resultados,publicados em conferências, todos no ano de 2010:

6.2 Resultados e contribuições 85

• An evaluation of e-learning plataforms funcionalities and the problem of m-learning and t-learning support [96] - Aborda a necessidade de suporte ao m-

learning e t-learning por parte das aplicações LMS. Além disso, o artigo tambémfez uma revisão da cobertura de funcionalidades das soluções existentes, de acordocom vários quesitos.

• Odin: Viabilizando e-learning em múltiplos dispositivos [97]- Breve descriçãodos requisitos do Odin, apresentado como poster no evento.

• Problemas e soluções em m-learning e a adaptação de conteúdo de objetos deaprendizagem para diferentes dispositivos [98] - Descrição da arquitetura do sis-tema Odin. Neste trabalho, a solução é classificada de acordo com a categorizaçãode arquiteturas em adaptação de conteúdo: “Quando, Onde, O que, Como”.

O projeto Odin também gerou contribuições indiretas, relacionadas a ProjetosFinais de cursos de alunos de Ciência da Computação da Universidade Federal de Goiás:

• OCA: Otimizador de Conversão de Áudio [40] - O trabalho teve por finalidadecriar uma API de conversão de áudio que facilitasse o trabalho de desenvolvedoresna criação de programas de geração de arquivos mais adaptáveis para diferentesaparelhos, como dispositivos móveis, e a TV Digital Brasileira.

• OCV: Otimizador de Conversão de Vídeos [82] - O trabalho também teve porfinalidade a criação de uma API de conversão, voltada a videos, que facilitasse otrabalho de desenvolvedores na criação de programas de geração de arquivos maisadaptáveis para diferentes contextos.

• OCI: Otimizador de Conversão de Imagens [26] - Apesar de não ter sido de-fendida formalmente pelo aluno, culminou na criação de uma API de conversão devídeos para diferentes formato, usando parâmetros como cor, tamanho e extensão.

• Interface móvel do Player Odin utilizando JavaFX [22] - Projeto e protótipode interação de um software a ser executado em dispositivos móveis para acesso àfuncionalidades de um sistema de ensino à distancia. Tal projeto foi implementadousando a tecnologia JavaFX, que pode ser usada tanto em computadores de mesaquanto em celulares e TV Digital.

• PAMIMS [103] - Ferramenta de interpretação de objetos de aprendizagem nopadrão IMS-QTI que executa avaliações em aparelhos com mecanismo de interaçãoreduzidos, como celulares e settop-boxes (cuja interação é por controle remoto).Ao final, foi produzido software que não só executava tais testes, mas também osenviava para servidor da instituição, dando o feedback para o professor.

6.3 Trabalhos Futuros 86

6.3 Trabalhos Futuros

Melhorias em relação aos serviços oferecidos ao professor, às soluções LMS eà realização de novos testes são atividades imediatas com o propósito de tornar a versãocorrente do Odin mais próxima de um emprego real, por vários professores e, dessa forma,receber retroalimentação que oriente trabalhos posteriores.

Para o professor, a criação de uma interface de gerência de seus objetos deaprendizagem, onde ele aprova ou reprova as adaptações feitas pelo sistema, além depoder escolher exatamente qual arquivo ele deseja adaptar. Atualmente, o Odin adaptatodo o material enviado, com exceção dos tipos de arquivo não suportados diretamente,como animações em Flash.

Para as soluções LMS, o apoio para todos os serviços de configuração doOdin via Web Services. Dessa forma, mantenedores dessas soluções poderão embutir oOdin diretamente dentro de suas aplicações, tornando seu uso mais fácil. Atualmente, énecessário que o administrador só mantenha as configurações pela interface gráfica doOdin.

Finalmente, em relação aos testes, o Odin pode ser integrado ao Moodle (re-conhecidamente o mais completo e mais utilizado sistema de gerenciamento de ensinono mundo), o que permitiria uma forma de introduzir os serviços por meio de ambientecomumente empregados.

Referências Bibliográficas

[1] Adobe creative suite. http://www.adobe.com/education/products/

creativesuite/, Ultimo acesso em Fevereiro de 2011.

[2] Amadeus lms. http://amadeus.cin.ufpe.br/, Ultimo acesso em Fevereiro de

2011.

[3] Atutor. http://www.atutor.ca/, Ultimo acesso em Fevereiro de 2011.

[4] Authorware. http://www.adobe.com/products/authorware/, Ultimo acesso

em Fevereiro de 2011.

[5] Claroline. http://www.claroline.net, Ultimo acesso em Fevereiro de 2011.

[6] Dokeos. http://www.dokeos.com, Ultimo acesso em Fevereiro de 2011.

[7] Ieee learning technology standardization committee - ltsc.

[8] Ims consortium. www.imsproject.org/specifications.html, Ultimo acesso

em Fevereiro de 2011.

[9] Ims meta-data best practice guide for ieee 1484.12.1-2002 standard for le-

arning object metadata. http://www.imsglobal.org/metadata/mdv1p3pd/

imsmd_bestv1p3pd.html, Ultimo acesso em Fevereiro de 2011.

[10] Joomla lms. http://www.joomlalms.com, Ultimo acesso em Fevereiro de 2011.

[11] .lrn. http://www.dotlrn.org, Ultimo acesso em Fevereiro de 2011.

[12] Moodle lms. http://moodle.org/, Ultimo acesso em Fevereiro de 2011.

[13] Portal do software público brasileiro. http://www.softwarepublico.gov.

br/, Ultimo acesso em Fevereiro de 2011.

[14] Reload. http://www.reload.ac.uk/, Ultimo acesso em Fevereiro de 2011.

[15] The Human Factor: Designing Computer Systems for People. New York Digital

Press, 1984.

http://www.adobe.com/education/products/creativesuite/

http://www.adobe.com/education/products/creativesuite/

http://amadeus.cin.ufpe.br/

http://www.atutor.ca/

http://www.adobe.com/products/authorware/

http://www.claroline.net

http://www.dokeos.com

www.imsproject.org/specifications.html

http://www.imsglobal.org/metadata/mdv1p3pd/imsmd_bestv1p3pd.html

http://www.imsglobal.org/metadata/mdv1p3pd/imsmd_bestv1p3pd.html

http://www.joomlalms.com

http://www.dotlrn.org

http://moodle.org/

http://www.softwarepublico.gov.br/

http://www.softwarepublico.gov.br/

http://www.reload.ac.uk/


[16] Adl - advanced distributed learning. www.adlnet.gov, Ultimo acesso em Feve-

reiro de 2011, 2010.

[17] Apple iwork. http://www.apple.com/iwork/, Ultimo acesso em Fevereiro de

2011, 2010.

[18] Oracle open office. http://www.openoffice.org/, Ultimo acesso em Fevereiro

de 2011, 2010.

[19] Blackboard academic suite. www.blackboard.com, Ultimo acesso em Fevereiro

de 2011, 2011.

[20] ADL. Scorm overview. http://www.ostyn.com/standards/docs/

scorm2004overview.htm, Ultimo acesso em Fevereiro de 2011, 2010.

[21] AICC. Aviation industry cbt committee. http://www.adlnet.org, Ultimo

acesso em Fevereiro de 2011.

[22] ALVES, L. C. Interface móvel do player odin utilizando javafx. Technical report,

Universidade Federal de Goiás, 2009.

[23] ANDREATA, J. A. Interatv: Um portal para aplicações colaborativas em tv digital

interativa usando a plataforma mhp. Master’s thesis, Universidade Federal de

Santa Catarina, 2006.

[24] BARBEIRA, J.; SANTOS, A. Desenvolvimento de conteúdos normalizados para

ambientes de e-learning: um estudo de caso na pt inovação. In: Revista

Brasileira de Informática na Escola, 2008.

[25] BARBOSA, J.; HAHN, R.; RABELLO, S.; PINTO, S. C. C. S.; BARBOSA, D. N. F.

Computação móvel e ubíqua no contexto de uma graduação de referência.

Revista Brasileira de Informática na Educação, 15(3):53–65, Setembro a Dezembro

2007.

[26] BARBOSA, J. O.; QUINTA, M. R. Oci: Otimização de conversão de imagens.

Technical report, Universidade Federal de Goiás, 2009.

[27] BOLL, S.; KLAS, W.; WANDEL, J. A cross-media adaptation strategy for multi-

media presentations. In: Proceedings of the ACM Multimedia 99, 1999.

[28] CHAIRMAN, V. W. A glossary of e-learning terms and acronyms. eLearning

Network, 2009.

www.adlnet.gov

http://www.apple.com/iwork/

http://www.openoffice.org/

www.blackboard.com

http://www.ostyn.com/standards/docs/scorm2004overview.htm

http://www.ostyn.com/standards/docs/scorm2004overview.htm

http://www.adlnet.org


[29] CHAVAN, A. Seven criteria for evaluating open-source content management

systems. http://www.linuxjournal.com/article/8301, Ultimo acesso em

Fevereiro de 2011, May 2005.

[30] CHEN, I.; YANG, S. J. H.; SHAO, N. W. Y. Applying multi-sensory learning model

with mobile handheld devices to pervasive learning. In: Proceedings of the

2nd IEEE international workshop on wireless and mobile technologies in education,

2004.

[31] CHEN, K.-H.; HUNG, H.-P.; CHEN, M.-S. Designing a resource-reusable t-

learning system. In: Proceedings of the Consumer Communications and Networ-

king Conference, 2007.

[32] COLACE, F.; DE SANTO, M.; RITROVATO, P.; MASCAMBRUNO, P. From e-learning

to t-learning. In: Information and Communication Technologies: From Theory to

Applications, 2008. ICTTA 2008. 3rd International Conference on, p. 1 –6, 7-11 2008.

[33] COLAZZO, L.; MOLINARI, A.; RONCHETTI, M.; TRIFONOVA, A. Towards a multi-

vendor mobile learning management system. In: Proceedings of the E-Learn

2003 Conference, 2003.

[34] CONTENT ADAPTATION, M. M. S. Maija metso and mikko loytynoja and jari

korva and petri maatta and jaakki sauvola. In: Proceedings of 3rd International

Conference on Information, 2001.

[35] DA COSTA CRUZ, L. J.; NICOLEIT, E. R.; GIACOMAZZO, G. F.; ZANETTE, E. N.;

GONÇALVES, L. L. Desenvolvimento de objeto de aprendizagem de suporte ao

conteúdo matemático de limites para dispositivos móveis baseado no padrão

scorm. In: Anais do Congresso da SBC, 2008.

[36] DA S RIBEIRO, P.; FRANCISCATO, F. T.; MOZZAQUATRO, P. M.; MEDINA, R. D.

Validação de um ambiente de aprendizagem móvel em curso à distância. In:

Anais do XX Simpósio Brasileiro de Informática na Educação, 2009.

[37] DE AGUIAR MEDEIROS, P. H. Desenvolvimento de objetos de aprendizagem

para a tv digital. Technical report, Universidade Federal de Goiás, 2007.

[38] DE ANDRADE KRATZ, R.; PINTO, S. C. C. S.; SCOPEL, M.; BARBOSA, J. Fábrica

de objetos de aprendizagem. Revista Brasileira de Informática na Educação,

3(15):25–38, Setembro a Dezembro 2007.

[39] DE AZEVEDO NASCIMENTO, A. C. Princípios de design na elaboração de

material multimídia para a web.

http://www.linuxjournal.com/article/8301


[40] DE CAMARGO FILHO, O. F. Oca: Otimizador de conversão de áudio. Technical

report, Universidade Federal de Goiás, 2009.

[41] DE F. BARTHOLO, V.; AMARAL, M. A.; CAGNIN, M. I. M-ava: Modelo de adap-

tabilidade para ambientes virtuais móveis de aprendizagem. In: Anais do XX

Simpósio Brasileiro de Informática na Educação, 2009.

[42] DE LARA, E.; WALLACH, D. S.; ZWAENEPOEL, W. Puppeteer: Component-based

adaptation for mobile computing. In: Proceedings of the Third Usenix Symposium

on Internet Technologies and Systems, 2001.

[43] DE OLIVEIRA, L. R.; MEDINA, R. D. Desenvolvimento de objetos de aprendi-

zagem para dispositivos móveis: uma nova abordagem que contribui para a

educação. In: ?????, ?????

[44] DE SOUSA MONTEIRO, B.; PROTA, T. M.; DE SOUZA, F. F.; GOMES, A. S. Desen-

volvimento de objetos de aprendizagem para tvdi. In: nao sei, 2099.

[45] DE SOUZA DUTRA, R. L.; TAROUCO, L. M. R. Objetos de aprendizagem:

Uma comparação entre scorm e ims learning design. Novas Tecnologias na

Educação, 4(1):1–8, Julho 2006.

[46] DEBRA, P. M. Hypermedia structures and systems. Technical report, Eidenhoven

University of technology, 1996.

[47] DEY, A. K.; ABOWD, G. D.; BROWN, P. J.; DAVIES, N.; SMITH, M.; STEGGLES, O.

Towards a better understanding of context and context-awareness. In: Proce-

edings of the 1st International Symposium on Handheld and Ubiquitous Computing,

1999.

[48] DOS SANTOS, D. T.; DO VALE, D. T.; MELONI, L. G. P. Digital tv and distance

learning: Potentials and limitations. In: Proceedings of 36th ASEE/IEEE Frontiers

in Education Conference, p. S1J1(1–6). IEEE, October 2006.

[49] DUFFY, T. M.; KIRKLEY, R. J. Learner-Centered Theory and Practice in Distance

Education. Lawrence Erlbaum Associates, 2004.

[50] DYSON, M. C.; CAMPELLO, S. B. Evaluating virtual learning environments:

what are we measuring? Electronic Journal of e-Learning, 1(1):11–20, 2003.

[51] EISINGER, R.; ROMERO, R. A. F.; GOULARTE, R. Machine learning techniques

applied to dynamic video adapting. In: Proceedings of the seventh conference on

Machine learning and applications, 2008.


[52] EL-GHAREEB, H. A. E-learning and management information systems. ELearn

Magazine, 1:1–5, 2009.

[53] EL-HADIDI, H.; RIAD, A. M.; MATSUMOTO, M. A multi-agent system to enhance

information retrieval results. In: IEIC, 2007.

[54] GARCIA, F. B.; HERVAS, J. A. Evaluating e-learning platforms through scorm

specifications. In: IADIS Virtual Multi Conference on Computer Science and

Information Systems, 2006.

[55] GEORGIEV, S.; GEORGIEVA, E.; SMRIKAROV, A. M-learning: a new stage of e-

learning. In: Proceedings of the 5th international conference on Computer systems

and technologies, número IV, p. 1–5, 2004.

[56] GEORGIEVA, E. A comparison analysis os mobile learning systems. In:

CompSysTech - International Conference on Computer Systems and Tecnologies,

2006.

[57] GRAF, S.; LIST, B. An evaluation of open source e-learning plataforms stres-

sing adaptation issues. In: Proceedings of the Fifth IEEE International Conference

on Advanced Learning Technologies, p. 163–165. IEEE, 2005.

[58] GRASSO, A.; ROSELLI, T. Guidelines for designing and developing contents for

mobile learning. In: Proceedings of the IEEE International Workshop on wireless

and Mobile Technologies in education, 2005.

[59] HAITAO, P.; LIN, J.; SONG, Y.; FASHENG, L. The approach of device indepen-

dence for mobile learning system. In: Proceedings of the IEEE International

Symposium on IT in Medicine Education, 2009.

[60] HILTZ, S. R.; ZHANG, Y.; TUROFF, M. Studies of effectiveness of learning

networks. In: Proceedings of the Sloan ALN Workshop, 2001.

[61] HILTZ, S. R.; TUROFF, M. What makes learning effective? Communications of

the ACM, 45(4):56–59, April 2002.

[62] HODGINS, W.; CONNER, M. Everything you ever wanted to know about lear-

ning standards but were afraid to ask. www.linezine.com/2.1/features/

wheyewtkls.htm, Ultimo acesso em Fevereiro de 2011, 2006.

[63] HORTON, C. H. W. E-Learning Tools and Technologies. Wiley Publishing Inc.,

2003.

www.linezine.com/2.1/features/wheyewtkls.htm

www.linezine.com/2.1/features/wheyewtkls.htm


[64] IANNINI, T. O. Pesquisa do perfil dos profissionais de tecnologia da infor-

mação. http://www.assespro.org.br/images/Pesquisa_Perfil_sintese_

revisao8c.pdf, Ultimo acesso em Fevereiro de 2011.

[65] IBGE. Ibge investiga a cultura nos municípios brasileiros. http:

//www.ibge.gov.br/home/presidencia/noticias/noticia_visualiza.

php?id_noticia=980, Ultimo acesso em Fevereiro de 2011, 2007.

[66] IDGNOW. Telefonia móvel deve chegar a 5 bilhões de assinatu-

ras em 2010. http://idgnow.uol.com.br/internet/2010/05/25/

internet-deve-chegar-a-5-bilhoes-de-usuarios-em-2010-diz-pesquisa/,

Ultimo acesso em Fevereiro de 2011.

[67] IEEE. Lom. http://ltsc.ieee.org, Ultimo acesso em Fevereiro de 2011.

[68] IMS. Ims learning design information model. http://www.imsglobal.org/

learningdesign/ldv1p0/imsld_infov1p0.html, Ultimo acesso em Fevereiro

de 2011.

[69] INFO-ESCOLA. Odin - infoescola. http://www.infoescola.com/mitologia/

odin/, Ultimo acesso em Fevereiro de 2011, 12 2010.

[70] JURUBESCU, T. Learning content management systems. Revista Informatica

Economica, 48(4):91–94, 2008.

[71] KEMCZINSKI, A.; FERLIN, W.; GASPARINI, I. Uma ferramenta para avaliação

de ambientes e-learning quanto aos aspectos da acessibilidade visual. In:

Simpósio Brasileiro de Informática na Escola, 2008.

[72] KLJUN, M.; VICIC, J.; KAVSEK, B.; KAVCIC, A. Evaluating comparisons and

evaluations of learning management systems. In: 29th International Conference

of Information Technology Interfaces, p. 363–368, 2007.

[73] LAAKO, T.; HILTUNEN, T. Adapting web content to mobile user agents. IEEE

Internet Computing, 2005.

[74] LAU, B. Y. S.; PHAM-NGUYEN, C.; LEE, C. S.; GARLATTI, S. Semantic web

service adaptation model for a pervasive learning scenario. In: Proceedings

of the 2008 IEEE Conference on Innovatie Technologies, 2008.

[75] LEE, Y.; CHANG, B.; DOH, H.; PARK, K.; CHA, J. Analogous content selection

mechanism using device profile and content profile for u-learning environ-

ments. In: Proceedings of the Ninth IEEE International Conference on Advanced

Learning Technologies, 2009.

http://www.assespro.org.br/images/Pesquisa_Perfil_sintese_revisao8c.pdf

http://www.assespro.org.br/images/Pesquisa_Perfil_sintese_revisao8c.pdf

http://www.ibge.gov.br/home/presidencia/noticias/noticia_visualiza.php?id_noticia=980



http://idgnow.uol.com.br/internet/2010/05/25/internet-deve-chegar-a-5-bilhoes-de-usuarios-em-2010-diz-pesquisa/

http://idgnow.uol.com.br/internet/2010/05/25/internet-deve-chegar-a-5-bilhoes-de-usuarios-em-2010-diz-pesquisa/

http://ltsc.ieee.org

http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html

http://www.imsglobal.org/learningdesign/ldv1p0/imsld_infov1p0.html

http://www.infoescola.com/mitologia/odin/

http://www.infoescola.com/mitologia/odin/


[76] LEMLOUMA, T.; LAYAIDA, N. Adapted content delivery for different contexts. In:

Proceedings of the 2003 Symposium on applications and the Internet. IEEE, 2003.

[77] LEUNG, C.-H. Mobile learning: A new paradigm in eletronic learning. In:

Proceedings os the 3rd IEEE International Conference on Advanced Learning

Technologies (ICALT 03), 2003.

[78] LEWIS, B.; MACENTEE, V. M. Learning management systems comparison. In:

Proceedings of the 2005 Informing Science and IT Education Joint Conference, p.

17–26, 2005.

[79] LIPPINCOTT, J. K. A mobile future for academic libraries. Esmerald Insight,

38(2):205–213, 2010.

[80] LOBATO, L. L.; DE SOUSA MONTEIRO, B.; DA SILVA, H. T. C. R.; DE LUNA,

F. C.; GOMES, A. S. Novos estilos de interação em sistemas de gestão de

aprendizagem. In: Anais do XXVIII Congresso da SBC, p. 186–195, 2008.

[81] LOBATO, L. L.; DE SOUSA MONTEIRO, B.; GOMES, A. S. Amadeus-mm: Lms com

integração de serviços multimídia. In: ?????, ?????

[82] LOBO, F. M. Ocv: Otimizador de conversão de vídeos. Technical report,

Universidade Federal de Goiás, 2009.

[83] LONG, L. E.; LONG, N. Introduction to computers and information systems:

the Internet edition. Prentice Hall, 1996.

[84] LUM, W. Y.; LAU, F. C. M. On balancing between transcoding overhead and

spatial consumption in content adaptation. In: Proceedings of the 8th annual

international conference on Mobile computing and networking, 2002.

[85] MA, Z. Web-based intelligent e-learning systems: Technologies and applicati-

ons. In: Information Science Publishing, 2006.

[86] MCGREAL, R.; KINSHUK. Mobile technology and content delivery in education.

In: Proceedings of the sixth international conference on advanced learning techno-

logies, 2006.

[87] MEDIALAB. Web content adaptation. Technical report, TeliaSonera Finlândia,

2004.

[88] MOHAN, R.; SMITH, J. R.; LI, C.-S. Adapting multimedia internet content for

universal acess. IEEE Transactions on multimedia, 1, 1999.


[89] OF REMOTE INSTITUTE OF ELETRICAL DISTRIBUTION NETWORKS FOR EUROPE, A.

Ariadne project.

[90] ORR, G. A review of literature in mobile learning: Affordances and constraints.

In: Proceedings of the 6th international conference on Wireless, Mobile and Ubiqui-

tous technologies in education, p. 107–111, 2010.

[91] PASSARINI, R. F. Objetos de aprendizagem: protótipo para módulo de am-

biente de treinamento online. Master’s thesis, Universidade Federal de Santa

Catarina, 2003.

[92] PEREIRA, L.; PORTO, F.; MACHADO, M.; NASCIMENTO, R. Objetos de aprendi-

zagem reutilizáveis (rlos): Conceitos, padronização, uso e armazenamento.

Technical report, PUC-Rio, 2003.

[93] PINTER, R.; RADOSLAV, D. Comparison of e-learning platforms. In: Serbian-

Hungarian Joint Symposium on Intelligent Systems, 2005.

[94] PREECE, J.; ROGERS, Y.; SHARP, H. Interaction Design: Beyond Human Com-

puter Interaction. John Wiley Sons, 2002.

[95] PRENSKY, M. What can you learn from a cell phone? almost anything! http:

//www.innovateonline.info/index.php?view=article&id=832007, Ultimo

acesso em Fevereiro de 2011.

[96] QUINTA, M. R.; DE LUCENA, F. N. An evaluation of e-learning plataforms funcio-

nalities and the problem of m-learning and t-learning support. In: Proceedings

of the 7th International Conference on Information Systems and Technology Mana-

gement, 2010.

[97] QUINTA, M. R.; DE LUCENA, F. N. Odin: Viabilizando e-learning em múltiplos

dispositivos. In: Proceedings of the XVI Workshop de Informática na Escola, 2010.

[98] QUINTA, M. R.; DE LUCENA, F. N. Problemas e soluções em m-learning

e a adaptação de conteúdo de objetos de aprendizagem para diferentes

dispositivos. In: Proceedings of the XXX Simpósio Brasileiro de Informática na

Escola. Sociedade Brasileira de Computação, Novembro 2010.

[99] RAO, D. D. Multimedia based intelligent content networking for future internet.

In: Proceedings of Third UKSim European Symposium on Computer Modeling and

Simulation, 2009.

[100] RESPONDUS-LOCKDOWN. Respondus. www.respondus.com, Ultimo acesso em

Fevereiro de 2011.

http://www.innovateonline.info/index.php?view=article&id=83 2007

http://www.innovateonline.info/index.php?view=article&id=83 2007

www.respondus.com


[101] REVEIU, A.; DARDALA, M.; FURTUNA, F. Using content-based multimedia data

retrieval for multimedia content adaptation. In: Proceedings of the 12th Interna-

tion Conference on Human Computer Interaction, 2007.

[102] REVEIU, A.; SMEUREANU, I.; DARDALA, M. Content adaptation in mobile multi-

media system for m-learning. In: Proceedings of the 7th international conference

on mobile business, 2008.

[103] RIBEIRO, L. H. M. Geração automática de interfaces para avaliação pela web:

Plugin para avaliações usando o padrão ims-qti. Technical report, Universidade

Federal de Goiás, 2009.

[104] ROESLER, V.; BARBOSA, M. L. K.; VARELLA, F.; BORDIGNON, A. Uma proposta

de arquitetura interoperável integrando web, tv digital e dispositivos móveis.

In: Anais do XX Simpósio Brasileiro de Informática na Educação, 2009.

[105] ROSENBERG, M. e-learning. McGrow Hill, 2001.

[106] SATYNARAYANAN, M. Fundamental challenges in mobile computing. In: Proce-

edings of the 15th ACM Synposium on principles of distributed computing, 1996.

[107] SERRANO, M.; SERRANO, M.; DE LUCENA, C. J. P. Framework for content

adaptation in ubiquitous computing centered on agents intentionality and

collaborative mas. In: Proceedings of IV Workshop on Software Engineering for

Agent-oriented Systems, 2008.

[108] SHARMA, S. K.; KITCHENS, F. L. Web-services architecture for m-learning.

International Journal of Mobile Communications, 4(1):178–192, 2006.

[109] SHARPLES, M.; TAYLOR, J. Towards a theory of mobile learning. In: Proceedings

of mLearn 2005, 2005.

[110] SIEMENS, G. Connectivism: a learning theory for the digital age. http://

www.itdl.org/Journal/Jan_05/article01.html, Ultimo acesso em Fevereiro

de 2011.

[111] SVETLANA, K.; YONGLK-YOON. Adaptation e-learning contents in mobile envi-

ronment. In: Proceedings of ICIS 2009, 2009.

[112] TAVARES, T. A.; SANTOS, C. A. S.; DE ASSIS, T. R.; DE PINHO, C. B. B.;

DE CARVALHO, G. M.; DA COSTA, C. S. A tv digital interativa como ferramenta

de apoio à educação infantil. Revista Brasileira de Informática na Educação,

15(2):31–44, 2007.

http://www.itdl.org/Journal/Jan_05/article01.html

http://www.itdl.org/Journal/Jan_05/article01.html


[113] TIMMINS, P. J.; MCCORMICK, S.; AGU, E.; WILLS, C. E. Characteristics of mobile

web content. In: Proceedings of the 1st IEEE Workshop on Hot Topics in Web

Systems and Technologies, 2006.

[114] TRAXLER, J. Defining, discussing and evaluating mobile learning: the moving

finger writes and having writ... The International Review of Research in Open and

Distance Learning, 8, 2007.

[115] TRIFONOVA, A. Mobile learning: Review of literature. Technical report, University

of Trento, 2003.

[116] TRIFONOVA, A.; RONCHETTI, M. A general architecture for m-learning. Journal

of Digital Contents, 2:31–36, 2003.

[117] VAHLDICK, A.; RAABE, A. L. A. Adaptação de conteúdo scorm em ambientes

inteligentes de aprendizagem. In: Anais do SBIE 2008, 2008.

[118] W3C. Web content accessibility guidelines (wcag) 2.0. http://www.w3.org/

TR/2008/REC-WCAG20-20081211/, Ultimo acesso em Fevereiro de 2011.

[119] W3C. World wide web consortium. http://www.w3c.org/, Ultimo acesso em

Fevereiro de 2011.

[120] WAINS, S. I.; MAHMOOD, W. Integrating m-learning with e-learning. In: SIGITE

’08: Proceedings of the 9th ACM SIGITE conference on Information technology

education, p. 31–38, New York, NY, USA, 2008. ACM.

[121] WAISMAN, T. Usabilidade em serviços educacionais em ambiente de tv digital.

Master’s thesis, Universidade de São Paulo, 2006.

[122] WELLER, M.; PEGLER, C.; MASON, R. Putting the pieces together: What

working with learning objects means for the educator. In: Proceedings of the

Second eLearnInternational World Summit, 2003.

[123] WHITELOCK, D.; WHEELER, S. Alt-c 2006: The next generation. In: Heriot-Watt

University, The next generation: 13th International Conference, 2006.

[124] WURFL. Wireless universal resource file. http://www.wurfl.sourceforge.

net, Ultimo acesso em Fevereiro de 2011.

[125] YANG, S. J. H.; CHEN, I. Y. L. Universal access and content adaptation in

mobile learning. In: Proceedings of the sixth international conference on advanced

learning technologies, 2006.

http://www.w3.org/TR/2008/REC-WCAG20-20081211/

http://www.w3.org/TR/2008/REC-WCAG20-20081211/

http://www.w3c.org/

http://www.wurfl.sourceforge.net

http://www.wurfl.sourceforge.net


[126] YANG, S. J. H.; CHEN, I. Y. L.; CHEN, R. Applying content adaptation technique

to enchance mobile learning on blackboard learning system. In: Proceedings

of the seventh international conference on advanced learning technologies, 2007.

[127] YIP LUM, W.; LAU, F. C. M. A context-aware decision engine for content

adaptation. Pervasive Computing, 2002.

[128] ZAGAR, M.; BOSNIC, I.; ORLIC, M. Enchancing software engineering education

- a creative approach. In: Proceedings of SEESE 08, 2008.

[129] ZANELLA, A. S.; SCHLEMMER, E.; BARBOSA, J. L. V.; REINHARD, N. M-learning

ou aprendizagem com mobilidade: um estudo exploratório sobre sua utiliza-

ção no brasil. Technical report, Anais do XXIII Congresso Internacional de Educa-

ção à Distância, 2007.

[130] ZHAO, X.; WAN, X.; OKAMOTO, T. Adaptative content delivery in ubiquitous

learning environment. In: Proceedings of the sixth international conference on

wireless, mobile and ubiquitous technologies in education, 2010.

APÊNDICE ARequisitos do Sistema Odin

A.1 Introdução

Este documento especifica os requisitos de software Odin.Os requisitos aqui identificados são o resultado de pesquisa do projeto de Mes-

trado de Marcelo Ricardo Quinta, orientado pelo professor Fábio Nogueira de Lucena,além de contribuições pontuais de outros profissionais da área, em eventos e reuniões.

A.1.1 Propósito

Este documento contém o registro de requisitos do Odin, cuja a clientela incluiinteressados no Projeto Odin, em particular, engenheiros de software responsáveis pelasua implementação e integração com outros sistemas, professores e administradores desistema de gerenciamento de ensino.

A.1.2 Necessidades

As necessidades levantadas que norteiam a criação do Odin são:

• Eficácia na execução de objetos de aprendizagem em múltiplos contextos;• Eficiência na execução de objetos de aprendizagem em múltiplos contextos;• Melhorar a produtividade do professor na criação de objetos de aprendizagem

personalizados;• Melhorar o suporte ao u-learning nas aplicações de gerência de ensino existentes.

A.1.3 Escopo

O sistema Odin é uma solução para apoiar o e-learning em múltiplos contex-tos, denominado u-learning, executando adaptação de conteúdo. Ele é particularmenteperceptível aos usuários por meio de um de seus principais componentes, o software (fer-ramenta), que apóia a adequação dos objetos de aprendizagem a vários dispositivos e

Apêndice A 99

condições do usuário. Além do software, o Odin também inclui processos, procedimentose outros componentes.

A coleção de padrões SCORM é comumente usada por softwares de EAD(Moodle, Blackboard, Claroline, dentre outros). Dessa forma, o Odin visa contemplartal padronização no armazenamento e execução de objetos de aprendizagem. Porém, osoftware não contempla a criação e edição de LOs SCORM diretamente pelo usuário.Será oferecido somente o serviço de leitura de metadados para uma melhor catalogaçãodos recursos.

Além de atividades de trabalho de professores e conteudistas, o Odin deve per-mitir que as funcionalidades de acesso ao serviço de adaptação também esteja disponívelpara outras soluções de gerenciamento como um proxy de repositório e adaptação de da-dos, fazendo que estes também possam oferecer tal serviço a seus interessados.

Alguns cursos podem ser oferecidos à dezenas ou milhares de alunos. Logo, acomunicação desses cliente com o software deverá ser otimizada para melhor tempo deresposta e menos retrabalho. Dessa forma, o Odin deverá oferecer repositório de objetosde aprendizagem, controle de transações e controle de acesso.

Embora sejam vários os interessados, os principais são professor e aluno. Odocente deverá poder usufruir de serviços de adaptação sem precisar entender quais sãoas característica tecnológicas dos clientes de seus alunos, poupando tempo. Já o discentepoderá fazer download de material personalizado sem a necessidade de escolher a versãoapropriada, tarefa a qual o Odin já realiza para ele, transparentemente.

A.1.4 Definições, acrônimos e abreviações

• LO (Learning Object - Objeto de aprendizagem) - São arquivos que têm comofunção auxiliar o processo de ensino-aprendizagem à distância, podendo ser cons-tituído de recursos multimídia ou descrição de atividades.

• EAD - Ensino à distância.• LMS (Learning Management Systems) - Sistemas de gerenciamento de ensino.• SCORM (Sharable Content Reference Model) - Coleção de padrões e especifica-

ções para e-learning. A norma define comunicações entre o conteúdo e o ambientede execução, além de metadados para catalogação das informações contidas nosseus recursos.

• SBTVD (Sistema Brasileiro de TV Digital) - Sistema de TV digital brasileiro,feito à partir do padrão japonês ISDB, adicionando algumas modificações feitaspor pesquisadores brasileiros, culminando no ISDB-T.

Apêndice A 100

A.1.5 Organização do documento

A Seção A.2 fornece uma visão geral do Odin, cujos requisitos detalhadosseguem na Seção A.3. Esta organização é aquela sugerida pela norma IEEE 830.

A.2 Descrição geral

A.2.1 Perspectiva do produto

O Odin é essencialmente uma ferramenta para produtividade para o professor,adaptando seus objetos de aprendizagem para diferentes contextos. Porém, ele não éo único que se beneficia com o uso do sistema. Alunos e sistemas LMS também têmproveito do sistema para suas atividades. A Figura A.1 ilustra tal cenário.

Figura A.1: Cenário possível, onde duas interfaces distintas, deusuário e de outros sistemas, podem explorar o sis-tema.

Outros usuários incluem administradores de sistemas, designers de con-teúdo/conteudistas e desenvolvedores de aplicações LMS.

O ator Sistema LMS representa a interação do Odin com outra ferramentade ensino, onde essa tira proveito dos serviços providos, via web, da solução aquiproposta. Esta interação é bidirecional, pois também pode-se inserir serviços no Odin(os conversores) que façam acesso a diferentes sistemas.

O sistema Odin é composto por quatro componentes, conforme a Figura A.2:

Apêndice A 101

Figura A.2: Principais componentes lógicos do Odin.

O componente do núcleo do Odin implementa as funcionalidades de software.O componente de serviços web é a interface computacional de acesso aos serviços debusca, envio e recebimento de objetos de aprendizagem adaptados. O componente deinterface gráfica do usuário implementa a interface humano-computador para que osinteressados interajam para upload e download de recursos. Finalmente, o Odin aindainclui o componente Processos, que inclui diretivas necessárias para construir objetos deaprendizagem mais reutilizáveis e acessar as funcionalidades da solução.

O principal objetivo desse documento é caracterizar os componentes do SistemaOdin e estabelecer as respectivas atribuições, ou seja, os componentes ilustrados na figuraacima não têm propósito de definir e/ou estabelecer restrições à arquitetura de softwaredo Odin.

Por fim, a visão da solução Odin, da perspectiva dos seus usuários humanos, estárestrita ao cliente gráfico, acessado pela web. Para este usuário, o Odin é o software queestá em execução no dispositivo. Partindo da figura acima, percebe-se que este cliente fazuso da interface gráfica que acessa os serviços do componente que implementa o núcleodo Odin.

A.2.2 Interfaces do sistema

As funcionalidades implementadas pelo Odin são oferecidas por interface web epor interface gráfica. A primeira refere-se à comunicação com outros sistemas. A segundarefere-se ao uso direto da aplicações por professores, administradores e alunos.

Apêndice A 102

A.2.3 Interfaces de usuário

O Odin possui interface de usuário para a administração e consumo direto daaplicação por professores, administradores e alunos. Tal interface não é descrita emdetalhes nesse documento.

A.2.4 Interfaces de hardware

Não se aplica.

A.2.5 Interfaces de software

Uma interface de acesso na internet deve ser oferecida para que soluções externasao Odin possam usufruir de suas funcionalidades.

A.2.6 Interfaces do comunicação

A integração entre qualquer cliente e o Odin deverá empregar o protocolo HTTPpara qualquer troca de informação. Isso visa assegurar a facilidade de acesso, visto que asolução deve conseguir comunicar-se com diferentes dispostivos. A variante HTTP(S)deverá ser usada nos casos em que for necessária implementação de protocolos desegurança.

A.2.7 Requisitos de adaptação ao local de implantação

Não são conhecidos.

A.2.8 Operações

Não são conhecidos.

A.2.9 Funções do Odin

Uma perspectiva geral das funções oferecidas pelo Odin podem ser resumidasem:

• Registro e manutenção de objetos de aprendizagem, inclusive suporte aos padroni-zados pela norma SCORM.

• Gerência de contextos e perfis relacionados ao u-learning, bem como as caracterís-ticas de mídia e conversão de cada um.

• Adaptação de conteúdo de objetos de aprendizagem para dispositivos homologados.

Apêndice A 103

• Upload e download transparente aos usuários quanto à verificação de contexto econversão de conteúdo.

• Administração de usuários.• Facilitação de entrega de objetos de aprendizagem personalizados em soluções

LMS existentes.

A.2.10 Características e papéis dos usuários

Em tempo, existem quatro tipos básicos de usuário que se relacionarão com aferramenta Odin. Ferramentas LMS foram desconsideradas por se tratarem de software.

Administrador

Profissional com experiência em administrar sistemas de computação e comconhecimento de dispositivos móveis e contextos de ensino. Seu papel é personalizar eadministrar todos os componentes do sistema sem trabalhar necessariamente com código-fonte.

Seu objetivo é, principalmente, garantir a maior disponibilidade possível dosdados corretos aos outros usuários.

Desenvolvedor de LMS

Profissional mantenedor e desenvolvedor de aplicações de gerenciamento deensino, com conhecimento em programação e arquitetura Web.

Seu principal objetivo no nosso contexto é fazer a comunicação da sua aplicaçãocom o Odin.

Professor

Profissional com experiência em docência e conhecimento de médio para baixoem computação. Pode ter dificuldades com manipulação de softwares na internet.

Seu papel dentro do Odin é a inserção de recursos no repositório de objetos deaprendizagem. Ele não tem responsabilidades relativas à administração do sistema.

Aluno

Estudante com conhecimento variável em computação e médio no uso de dispo-sitivos móveis. Pode ter dificuldades motoras.

Seu papel no sistema é consumir os recursos oferecidos pelo sistema de ensino.

Apêndice A 104

Conteudista

Profissional com grande conhecimento em computação e dispositivos móveis,além de grande domínio de ferramentas de conversão e design gráfico e de interação.

Seu objetivo no Odin é criar versões dos objetos de aprendizagem, enviadospelo professor, para os diferentes contextos, à medida do aparecimento de requisiçõesde conversão pelo Odin.

A.2.11 Restrições

R 1 O SBTVD deve ser contemplado como possível contexto de entrega de recursos deobjetos de aprendizagem.

R 2 Caso o conversor seja computacional, este deve ser uma biblioteca em Java, do tipo“.JAR”.

A.2.12 Suposições e dependências

S 1 A percepção de qualidade do Odin é estabelecida pelos fatores (na seguinte ordem):(a) utilidade para os usuários; (b) facilidade de uso e operação;(c)precisão dasadaptações oferecidas.

A.3 Requisitos específicos

A.3.1 Requisitos de interfaces externas

Interfaces de hardware

Não se aplica.

Interfaces de software

A interface para acesso externo, via internet, deverá ser definida a partir dasfunções deste documento. Nenhuma restrição conhecida é imposta à definição destainterface, empregada por elementos externos para acesso a requisitos contidos nestedocumento.

A.3.2 Características do sistema

As funções do Odin foram agrupadas em “tópicos de interesse”, onde cada umdeles resume o escopo e os requisitos detalhados na sua subseção.

Apêndice A 105

Objetos de aprendizagem

Objeto de aprendizagem é um dos componentes mais importantes em e-learning.Ele é produzido por professores e conteudistas e consumido pelos estudantes.

RF1 Todo objeto de aprendizagem deve possuir um código que o identifica unicamenteno sistema.

RF2 O código do objeto de aprendizagem deve ser NUMÉRICO.RF3 Cada LO deve conter, obrigatoriamente: código, título (valor do tipo TEXTO, que

não precisa ser único), descrição (valor do tipo TEXTO), data de adição (DIA,MÊS, ANO e HORÁRIO) e pelo menos uma palavra-chave (valor do tipo TEXTO).

RF4 Todo objeto de aprendizagem deve possuir, pelo menos, um recurso (arquivo)educacional.

RF5 Objetos de aprendizagem podem ter atributos variáveis, compostos por nome (valordo tipo TEXTO) e descrição (valor do tipo TEXTO).

RF6 Recursos de objetos de aprendizagem também podem ter atributos variáveis, com-postos por nome (valor do tipo TEXTO) e descrição (valor do tipo TEXTO).

RF7 Todo recurso de objeto de aprendizagem deve estar relacionado a um arquivo.RF8 Arquivos relacionados a recursos de objetos de aprendizagem devem conter infor-

mações sobre o tipo(MIME-type) e URL(caminho completo do arquivo),que deveser único, além de código de verificação de integridade (CHECKSUM), que tam-bém deve ser único.

RF9 Deve ser oferecida forma de adição de metadados SCORM aos atributos de umobjeto de aprendizagem.

RF10 Objetos de aprendizagem podem ser bloqueados para adaptação, ou seja, pode havera proibição de geração de versões adaptadas para seus recursos.

RF11 O repositório de objetos de aprendizagem pode estar tanto no computador que oOdin está instalado, como em outro local.

Contextos e perfis

Contexto é qualquer informação que pode ser usada para caracterizar a situaçãode uma entidade. Para nossa realidade, contexto define o ambiente que o usuário seencontra durante o processo de aprendizagem. Tais características podem ser comuns aoutros contextos. Logo, temos um perfil.

RF12 Um contexto é identificado por um nome (valor do tipo TEXTO), código (valor dotipo TEXTO) e descrição (valor do tipo TEXTO).

RF13 Dois contextos não podem ter o mesmo código.RF14 Dois contextos podem ter o mesmo nome.

Apêndice A 106

RF15 O contexto pode ser relativo a um dispositivo ou a uma condição do ambiente.RF16 Um perfil de mídia pode ter vários contextos relacionados.RF17 Todo contexto deve estar relacionado a um perfil de mídia.RF18 Um perfil de mídia contém um nome (valor do tipo TEXTO), que o identifica.RF19 Um perfil de mídia contém uma configuração de áudio, uma configuração de vídeo,

uma configuração de imagem e uma configuração de documento.RF20 Perfis de mídia devem possuir um conversor padrão para cada tipo de mídia: áudio,

imagem, vídeo e documento.RF21 Dado um tipo de mídia, dois perfis serão iguais se apontarem para a mesma

configuração de mídia de tal MIME-type.


Configurações de mídia guardam as informações sobre os recursos de cada pefil,ou seja, as propriedades dos arquivos para os tipos MIME suportados pelo Odin.

RF22 São quatro as configurações de mídia: imagem, áudio, vídeo e documento.RF23 Configurações de mídia podem estar relacionados a nenhum ou vários perfis.RF24 Uma configuração de imagem deve possuir o nome do formato (valor do tipo

texto), largura em pixels (valor do tipo NUMÉRICO), altura em pixels (valor dotipo NUMÉRICO) e flag (valor do tipo BOOLEANO) que indique se há suporte aimagens maiores do que a resolução especificada.

RF25 Não podem existir duas configurações de imagem com todos os valores idênticos.RF26 Uma configuração de documento deve possuir somente o nome do formato (valor

único no sistema, do tipo TEXTO).RF27 Configurações de áudio devem possuir nome do formato suportado (valor do tipo

TEXTO), nome do codec de áudio relacionado (valor do tipo TEXTO), taxa debits (bit rate - valor do tipo NUMÉRICO), taxa de amostragem (sampling rate -valor do tipo NUMÉRICO) e indicação de stereo (mono ou estéreo, valor do tipoBOOLEANO).

RF28 Não podem existir duas configurações de áudio com o mesmo nome de formato,codec, bit rate e sampling rate, simultaneamente.

RF29 Uma configuração de vídeo deve possuir nome do formato suportado (valor do tipoTEXTO), nome do codec de vídeo relacionado (valor do tipo TEXTO), taxa debits (bit rate - valor do tipo NUMÉRICO), taxa de amostragem (sampling rate -valor do tipo NUMÉRICO), taxa de frames por segundo (frame rate - valor do tiponumérico), largura de imagem em pixels (valor do tipo NUMÉRICO) e altura deimagem em pixels (valor do tipo NUMÉRICO).

RF30 Toda configuração de vídeo deve ter uma configuração de áudio relacionada.

Apêndice A 107

RF31 Nem toda configuração de áudio está relacionada a uma configuração de vídeo.RF32 Não podem existir duas configurações de vídeo com todos os atributos iguais.RF33 A igualdade de uma configuração de mídia deve ser feita em nível de software, ou

seja, tal comparação deve ser implementada em código-fonte.

Conversor

Conversores são diretamente responsáveis pela adaptação do material, partici-pando da criação de novas versões de objetos de aprendizagem. Um dos diferenciais doOdin é a possibilidade desse conversor ser tanto uma pessoa quanto uma aplicação.

RF34 Todo conversor deve ter nome (valor do tipo TEXTO), descrição (valor do tipoTEXTO) e indicação do tipo de mídia que ele trata: áudio, vídeo, imagem oudocumento.

RF35 Um conversor pode estar relacionado a um usuário. Sendo assim, o nome doconversor deve ser igual ao nome do usuário.

RF36 Um conversor pode estar relacionado a mais de um tipo de mídia.RF37 Não pode existir mais de um conversor para um tipo de arquivo relacionado ao perfil

de mídia.RF38 A descrição no conversor é obrigatória.RF39 O repositório de conversores pode estar tanto na máquina onde o Odin está instalado

quanto em uma localidade remota.RF40 Todo conversor computacional deve seguir a API estabelecida pelo Odin para o(s)

tipo(s) de mídia alvo.RF41 Usuários do sistema podem adicionar seus próprios conversores de mídia,

relacionando-os a perfis.

Adaptação

A adaptação consiste na verificação do contexto do usuário e entrega de conteúdopersonalizado para suas necessidades. No Odin, a adaptação ocorre antes da requisição,de forma que o arquivo esteja pronto quando o usuário requisitá-lo, diminuindo o tempode espera. Para isso, precisamos guardar metadados que estabeleçam a conexão entrearquivos e perfis.

RF42 Todo objeto de aprendizagem adaptado está relacionado a um objeto de aprendiza-gem original e a um perfil de mídia (conjunto de contextos).

RF43 Um objeto de aprendizagem adaptado possui ao menos um recurso do originaladaptado.

RF44 Nem todos os recursos do objetos de aprendizagem original precisam estar relacio-nados a um adaptado.

Apêndice A 108

RF45 Devem existir “N” objetos de aprendizagem adaptados, onde “N” é o número deperfis de mídia.

RF46 Todo objeto de aprendizagem adaptado deve possuir um status: PENDENTE,PUBLICADO ou COM ERROS.

RF47 Um objeto de aprendizagem adaptado deve possuir status PENDENTE quando asconversões necessárias para sua criação ainda não foram terminadas.

RF48 Um objeto de aprendizagem adaptado deve possuir status PUBLICADO quando asconversões necessárias para sua criação estiverem terminadas.

RF49 Caso alguma conversão do objeto de aprendizagem não tenha sucesso, este deveráter o status COM ERROS.

RF50 Deve ser emitido relatório de todas as adaptações de objetos de aprendizagem,agrupadas por status.

RF51 A adaptação deve ocorrer após o professor/conteudista enviar um novo objeto deaprendizagem no sistema.

RF52 Para que ocorra a adaptação, todos os dados de contextos e perfis devem estarpreenchidos.

RF53 O arquivo do recurso do objeto de aprendizagem adaptado deve conter os mesmosmetadados do recurso original.

RF54 Toda conversão de recurso de LO deverá ser feita unicamente com o conversor doperfil relacionado ao contexto que esteja relacionado ao tipo de mídia tratado.

RF55 Todo processo de conversão acaba no exato momento que todos os arquivos doobjeto de aprendizagem são recebidos.

RF56 Todo processo de conversão de arquivos deve estar relacionado a uma tarefa deconversão.

RF57 A tarefa de conversão deve possuir uma data de atribuição (DIA e HORÁRIO),valor não nulo.

RF58 Uma tarefa de conversão está relacionada a somente um recurso do objeto deaprendizagem e perfil de mídia.

RF59 Após a conversão for marcada como iniciada pelo conversor, ela deve guardarinformação sobre quando foi aceita.

RF60 Após a conversão for marcada como finalizada pelo conversor , ela deve guardarinformação sobre quando foi terminada.

RF61 Devem ser fornecidos relatórios de demora de tempo para conversão, agrupados portipo de conversor: humano e computacional.

RF62 Os arquivos adaptados devem ficar no mesmo diretório que seus originais.RF63 O nome do arquivo adaptado deve ser igual aos do original, adicionado com o nome

do perfil existente.RF64 Uma nova adaptação para um perfil só será feita se não existir nenhuma outra para

Apêndice A 109

um perfil compatível, dado o tipo do arquivo.RF65 Dado o tipo do arquivo e um novo perfil, caso já exista versão do arquivo relacio-

nado a outro perfil compatível, a versão para esse novo perfil deverá fazer referênciaao já existente.

RF66 A adaptação deve ocorrer paralelamente ao funcionamento do Odin, não bloque-ando nenhum outro processo, como a resposta de upload com sucesso.

RF67 A adaptação de um tipo de arquivo não suportado pelo Odin só pode ser requisitadamediante pedido de um administrador, que deve escolher o arquivo e o perfil alvo.

RF68 Um administrador do Odin pode excluir adaptações de objetos de aprendizagempara perfis, de forma que uma nova versão (mais cabível) seja futuramente produ-zida.

Controle de acesso

A segurança oferecida pelo Odin é baseada no conceito de nível de alçada. Cadanível define um conjunto de privilégios a serem usufruídos em relação a cada função dosistema.

RF69 Todo usuário deve conter nome completo (valor do tipo TEXTO), nome de usuário(valor do tipo TEXTO), senha (valor do tipo TEXTO), email (valor do tipo TEXTO)e nível de alçada(3 para administrador, 2 para conversor de conteúdo, 1 paraprofessor e 0 para estudante).

RF70 Nomes de usuário devem ser únicos no sistema.RF71 A senha não deve ser guardada, mas o valor MD5 correspondente, de forma que ela

não possa ser recuperada, mas apenas substituída.RF72 O nível 0 só permite a consulta e download de objetos de aprendizagem.RF73 O nível 1 permite as operações do nível 0, somadas ao envio de arquivos e relatórios

de download dos próprios recursos enviados.RF74 O nível 2 permite as operações do nível 1, somadas à possibilidade de se tornar um

conversor, podendo criar novas versões de objetos de aprendizagem.RF75 Usuário do nível 2 só possui acesso às conversões que forem relacionadas a ele.RF76 O nível 3 permite acesso total aos objetos de aprendizagem e suas adaptações, além

de oferecer acesso a todas configurações do sistema.RF77 Um usuário também poderá ser software.

Download transparente

RF78 O usuário pode buscar objetos de aprendizagem por título, código, atributo oupalavra-chave.

Apêndice A 110

RF79 Quando não for encontrado recurso compatível, deve-se retornar o resultado deacordo com os códigos de resposta do HTTP.

RF80 A verificação de contexto do dispositivo deve ser transparente para o usuário.RF81 O contexto do usuário deve ser verificado após que este requisite algum material e

somente durante essa operação.RF82 O código do contexto também pode ser enviado diretamente pelo cliente da aplica-

ção, dentro da requisição. Nesse caso, a identificação do dispositivo não deve serfeita.

RF83 Quando não for possível identificar o contexto, deve-se assumir que o usuárioencontra-se em um computador de mesa comum.

RF84 Existem três estratégias de entrega possíveis: “Entregar somente o arquivo origi-nal”, “Entregar somente arquivo adaptado” e “Entregar arquivo adaptado. Caso nãoencontre, entregue o original.”

RF85 O Odin deve ser capaz de retornar relatório de downloads realizados, com quanti-dade de contextos registrados e porcentagem de consumo de recursos de objetos deaprendizagem em cada um.

RF86 Um aluno não pode escolher a estratégia de entrega de um objeto de aprendizagempara seu contexto.

A.3.3 Atributos de software (Requisitos não funcionais)

O conteúdo desta seção está organizado conforme a norma NBR ISO/IEC 91261.

Funcionalidade::Adequação

RNF 1 O Odin deverá, onde aplicável, estar em conformidade e/ou seguir orientaçõesfornecidas pelo padrão SCORM.

RNF 2 Os relatórios do Odin podem ser exportados nos formatos HTML ou PDF.RNF 3 Objetos de aprendizagem sob controle do Odin poderão ser acrescentados até o

limite de memória secundária disponível.

Funcionalidade::Acurácia

Não identificados.

Funcionalidade::Segurança

RNF 4 Todos os valores de verificação de integridade de arquivos do Odin deverá ser feitocom a tecnologia MD5.

Apêndice A 111

RNF 5 Só terá acesso aos serviços oferecidos pelo Odin pessoa ou software devidamentecadastrado, também chamado de usuário.

RNF 6 Apenas usuário autorizado deverá ter acesso aos objetos de aprendizado e adapta-ções geridas pelo Odin.

Funcionalidade::Interoperabilidade

RNF 8 Deve estar disponível uma implementação da API de conversores do Odin em lin-guagem Java (versão 5.0 ou superior). A implementação correspondente será for-necida pelo arquivo “.jar”(ConversorOdin-<versao>.jar), onde “<versao>” fornecea versão da implementação.

RNF 9 Implementações de terceiros da API de Conversores do Odin devem fazer uso doarquivo ConversorOdin-<versao>.jar em tempo de compilação e execução.

Funcionalidade::Conformidade

RNF 10 A língua padrão do Odin é o Português do Brasil ou PT-BR (descritor desta língua).RNF 11 A hora padrão do Odin é a hora oficial de Brasília/DF (Brasil).

Funcionalidade::Recuperabilidade

RNF 12 O Odin deve ser configurado de forma que a troca de local do repositório de LOs econversores não inviabilize a utilização do sistema.

Usabilidade::apreensibilidade

RNF 13 As implementações da API de Conversão do Odin e dos serviços Web deverão serdocumentadas e ilustradas por meio de exemplos. A documentação deverá detalharas funções oferecidas, situações de exceção e retornos produzidos.

Eficiência

RNF 14 O Odin deve ser capaz de tratar mais de 10 requisições de download e upload aomesmo tempo, não superando tempo de resposta de mais de 5 segundos para cadauma.

Manutenibilidade

Não identificados.

Portabilidade :: Adaptabilidade

Não identificados.

Apêndice A 112

Portabilidade :: Instalação

RNF 15 A instalação do Odin, se possível, deverá ocorrer em tempo não superior a 2minutos, desconsiderando o tempo necessário para criação dos dados iniciais decontextos, perfis e conversores.

Portabilidade :: Conformidade

RNF 16 O Odin poderá estar em execução sobre os ambientes Linux, Windows Vista e MacOS X 10.6.

A.3.4 Outros requisitos

Não identificados.

APÊNDICE BArquitetura do Sistema Odin

B.1 Visão geral

Nesta seção, intitulada Visão Geral, e nas suas subseções, será apresentada umavisão geral do artefato "Documento de Arquitetura de Software", definindo-se o seupropósito no contexto do processo, o seu escopo de representação, vinculado a soluçãoOdin, bem como as definições, os acrônimos, as abreviações e referências utilizadas.

São alvos deste documento todos os stakeholders (interessados) definidos naSeção B.1.6.

A partir da Seção B.2 temos a representação detalhada da arquitetura do sistema,mostrada a partir de suas visões arquiteturais mais expressivas.

B.1.1 Propósito

O propósito do documento de arquitetura é fornecer um molde de desenvolvi-mento que deve guiar as atividades de projeto e implementação da solução Odin. Porrepresentar as decisões significativas do projeto, tal artefato estabelece a estrutura cola-borativa dos elementos do sistema, os quais definem um modelo de construção que devedirecionar as demais atividades relacionadas à construção da aplicação.

B.1.2 Escopo

Este documento define a forma tratada pelo sistema Odin para adaptação deconteúdo para múltiplos contextos transparente aos usuários.

O detalhamento está restrito ao nível de tecnologia utilizada para a construçãodos componentes do Odin. Não é disponibilizado nenhum código de arquitetura de baixonível (código-fonte).

Apêndice B 114

B.1.3 Representação utilizada

Todas as perspectivas representam categorias complementares de análise, asquais, vistas enquanto uma unidade, definem a estrutura completa da aplicação. Comoessas visões arquiteturais constituem-se em categorias do RUP, as suas representaçõesseguem as definições semânticas da UML e estão voltadas a papéis específicos doprocesso.

Ao total são tratadas aqui as seguintes visões arquiteturais:

• Visão de prateleira.• Visão do usuário.• Visão do comprador.• Visão do administrador.• Visão lógica.• Visão de implantação.• Visão de processos.• Visão de camadas.

Uma visão de casos de uso pode ser acessada no documento de Especificação derequisitos (Apêndice A).

B.1.4 Referências

B.1.5 Glossário

• LMS - (Learning Management System): Sistema de gerenciamento de ensino,usado para provisão de e-learning a estudantes.

• LO - (Learning objects) - Objetos de aprendizagem.

B.1.6 Interessados e interesses

Os interessados no Odin são todos aqueles que usufruem o sistema ou trabalhampara mantê-lo em funcionamento. Segue a definição dos papéis existentes, com brevedescrição de suas atividades e principais interesses.

• Aluno: Qualquer pessoa, interessada em consumir objetos de aprendizagem emdiferentes contextos. Faz somente pesquisa e download de arquivos.

• Professor: Profissional com experiência em docência e conhecimento de médiopara baixo em computação, que tem como objetivo enviar recursos no repositóriode objetos de aprendizagem. Ele não possui responsabilidades relativas à adminis-tração do sistema, somente envia arquivos.

Apêndice B 115

• Conteudista: Profissional com grande conhecimento em computação e dispositivosmóveis e tem o objetivo de criar versões dos objetos de aprendizagem, enviados peloprofessor, para os diferentes contextos, à medida do aparecimento de requisições deconversão pelo Odin.

• Administrador: Usuário(s) responsável(is) pela administração de recursos deaprendizagem, perfis de contextos, métodos de conversão no sistema e gerência deusuários. Suas principais necessidades são a facilidade de personalização das con-versões para os perfis existentes, facilidade de detecção de problemas e facilidadede recuperação de dados após falhas.

• Comprador: Instituição que adota o Sistema, interessada em facilidade de implan-tação, diminuição do custo de operação e diminuição do custo de infraestrutura.

• Aplicação LMS: Aplicação de gerência de ensino que pode ter o interesse de passarfunções de gravação e adaptação de objetos de aprendizagem para outros sistemas.

• Desenvolvedor: Responsável pelo desenvolvimento do Sistema Odin. Suas princi-pais necessidades são a facilidade de construção do software e facilidade de testes.

• Mantenedor: Profissional responsável pela personalização do Sistema para asinstituições. Suas principais necessidades são a facilidade de compreensão docódigo e a facilidade de acrescentar/alterar serviços.

B.2 Visões identificadas

B.2.1 Visão de prateleira

Os interessados em interagir com a solução Odin observarão somente doispacotes principais de componentes de prateleira: (a) interface gráfica e (b) Web Services,ilustrados na Figura B.1. O primeiro é executado em qualquer dispositivo com acesso aInternet. O segundo em um servidor, computador no qual outros serviços também deverãoestar em execução.

Apêndice B 116

Figura B.1: Visão de prateleira do sistema Odin.

Interface gráfica

O usuário deve ter acesso a um componente de software para acessar as funcio-nalidades do sistema, disponível para computadores de mesa (no caso das funções admi-nistrativas) e para qualquer outro dipositivo ou contexto, no caso da função de downloadde objetos de aprendizagem.

Serviços Web

Componente responsável por prover toda a infra-estrutura necessária para aten-dimento das requisições dos clientes do Odin, além da provisão do serviço de upload edownload para sistemas LMS.

B.2.2 Visão do usuário

As funcionalidades oferecidas pelo Sistema Odin serão usufruídas por alunos,professores, administradores e conteudistas através da interface gráfica de um cliente (vianavegador). Tal interface gráfica irá interagir com um servidor possivelmente remoto. Taisfunções também podem ser oferecidas via Web Services, consumidas por soluções LMSque pretendem usar o Odin como proxy de objetos de aprendizagem. Veja a Figura B.2.

Apêndice B 117

Figura B.2: Visão do usuário do sistema Odin.

O servidor (Componente do Sistema Odin) é o elemento que guarda as informa-ções que podem ser obtidas por meio da internet (requisições HTTP ou HTTPS), por umainterface gráfica via interface Web, ou via serviços na internet. Este último é consumidosomente por aplicações LMS.

B.2.3 Visão do comprador

A adoção do Sistema Odin exige a presença de alguns elementos de infraestru-tura (hardware e software), presentes na Figura B.3.

Figura B.3: Visão do comprador do sistema Odin.

Como a idéia do sistema é prover conteúdo específico para diferentes contextos,há certa flexibilidade de sistemas para execução dos clientes, podendo ser desde um

Apêndice B 118

computador de mesa até um settop-box. A restrição sobre sistemas operacionais estána obrigatoriedade de acesso à internet para execução da interface gráfica no clientee obrigatoriedade de existência de máquina virtual Java (JVM) para a aplicação webno servidor. Já restrições pela qualidade do hardware utilizado dependerão (em termosde memória, armazenamento e capacidade de processamento) das exigências de umaimplantação específica.

Podemos observar a flexibilidade de software para servidores de aplicação e sis-tema gerenciador de banco de dados(SGBD). O primeiro servirá para hospedar a apli-cação em um servidor, garantindo funcionalidades extras como segurança e controle detransações. Por ser gratuito e utilizado largamente pela comunidade de desenvolvimento,o Glassfish será o contêiner Web padrão. Já no caso do SGBD, a escolha do padrão é peloHSQLDB, considerado sólido e que demanda pouca manutenção e recursos. Porém, pos-síveis mudanças em servidores de aplicação e sistemas gerenciadores de banco de dadospodem acontecer, dependendo do definido pelo persistence provider. Para isso, possíveismudanças devem acontecer em nível de código fonte.

Softwares fabricados para terceiros para conversão de arquivo não têm restri-ções definidas nesse documento. Isso acontece pela flexibilidade do uso de aplicações,dependendo do já utilizado pelo adaptador de conteúdo, um conteudista.

B.2.4 Visão do administrador

O administrador do Odin tem papel importante no sistema, mantendo o sistemaem funcionamento. Para isso, ele gerencia pontos importantes do sistema, como:

• Configurações básicas de rede do Odin , como indicação de URL de servidores eportas de oferecimento de serviços.

• Ligamento e desligamento do sistema.• Gerência de usuários.• Gerência de conteudistas.• Gerência de conversores computacionais.• Manutenção das configurações de áudio, vídeo, imagem e texto existentes.• Manutenção dos dados de perfis, que relacionam configurações de mídia, converso-

res e contextos.• Gerência de contextos.• Verificação de atividade do sistema (inclui relatórios).• Serviços pertinentes a acesso e segurança como, por exemplo, portas, firewalls e

outras.• Gerência de configurações de repositório de conversores e objetos de aprendizagem.• Definição de estratégias de entrega de versões adaptadas de LOs.

Apêndice B 119

• Manutenção de objetos de aprendizagem e suas adaptações.

Serviços realizados pelo administrador são requisitados indiretamente pelomesmo por meio da interface gráfica. O administrador também se interessa pela Visãode Implantação.

B.2.5 Visão lógica

Na página seguinte, a Figura B.4 mostra o modelo de domínio, seguido dodetalhamento de subdomínios nas figuras subsequentes.

Apêndice B 120

Figura B.4: Modelo de domínio do sistema Odin.

Apêndice B 121

Objetos de aprendizagem

Figura B.5: Classes de domínio de objetos de aprendizagem ealgumas classes de serviço.


Figura B.6: Classes de domínio de configurações de mídia.

Apêndice B 122

Controle de usuários

Figura B.7: Classes de domínio de usuários e alguns detalhes desua classe de serviços.

Conversor

Figura B.8: Classes de domínio de conversores de arquivos, junta-mente com um exemplo de classe de serviços.

Apêndice B 123

Contextos e perfis

Figura B.9: Classes de domínio de contextos e perfis, juntamentecom um exemplo de classe de serviços de descobertade contexto.

Apêndice B 124

Adaptações de objeto de aprendizagem

Figura B.10: Classes de domínio de adaptações de objetos deaprendizagem.

B.2.6 Visão de implantação

Ilustrada na Figura B.11, a visão de implantação também é particularmenteútil ao administrador. Na figura abaixo são empregadas três estratos: cliente, servidore persistência. Contudo, nada impede que servidores e bancos de dados sejam executadosem um mesmo nó.

Apêndice B 125

Figura B.11: Nós da visão de implantação, com seus componentes.

B.2.7 Visão de processos

Vários clientes podem requisitar simultaneamente serviços à instância do Glass-fish. De forma similar, teremos um único SGBD e vários conversores funcionando simul-taneamente, conforme ilustra a Figura B.12.

Apêndice B 126

Figura B.12: Visão de processos, mostrando cada uma das quatrothreads.

B.2.8 Visão de camadas

O Sistema Odin pode ser visto da perspectiva de camadas onde a Apresentação(interface gráfica ou serviços web) interage com a Aplicação por meio de serviçosoferecidos pela camada Serviços. A camada de Aplicação, por sua vez, exclusivamentecom as camadas de Domínio e Serviços. A Persistência faz uso da camada de Domínio,mas não o inverso. Por fim, a camada de Domínio é ortogonal oferece funcionalidadespara todas as outras. Veja a Figura B.13.

Figura B.13: Visão de camadas do Odin.

Apêndice B 127

Como pudemos ver, a dependência das camadas é descendente e possibilitamenos acoplamento do sistema, principalmente por causa da restrição de acesso aosdados em cada uma delas. Com isso, novas funcionalidades e manutenções no sistemaOdin podem ser feitas (criando novas implementações de interface) de forma a não gerar“efeito cascata” sobre requisitos já implementados.

B.3 Tecnologias

Para a implementação do cliente: Java Server Pages (JSP). Para a implementaçãodos componentes disponibilizados no servidor: Java Enterprise Edition (Java EE), oservidor de aplicações Glassfish V3 , o Hibernate como framework de persistência dedados, WURFL para verificação de contexto e o HSQLDB como Sistema Gerenciador deBanco de Dados.

adaptação de conteúdo para múltiplos contextos - · pdf file3.3.2...

Documents