Universidade Federal do Rio Grande do Norte
Instituto Metrópole Digital
Programa de Pós-graduação em Engenharia de
Software
Mestrado Profisional em Engenharia de Software
Arquitetura de comunicação entre AVAs e
objetos de aprendizagem dinâmicos
utilizando a especificação IMS LTI
Saulo Rufino de Sá
Natal-RN
Agosto 2017
Saulo Rufino de Sá
Arquitetura de comunicação entre AVAs e objetos de
aprendizagem dinâmicos utilizando a especificação IMS
LTI
Dissertação de Mestrado apresentada ao Pro-
grama de Pós-graduação em Engenharia de
Software da Universidade Federal do Rio
Grande do Norte como requisito para a ob-
tenção do grau de Mestre em Engenharia de
Software.
Universidade Federal do Rio Grande do Norte – UFRN
Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Engenharia de Software
Orientador: Rummenigge Rudson Dantas
Natal-RN
Agosto 2017
Sá, Saulo Rufino de.
   Arquitetura de comunicação entre AVAs e objetos de
aprendizagem dinâmicos utilizando a especificação IMS LTI /
Saulo Rufino de sa. - 2017.
   101 f.: il.
   Dissertação (mestrado) - Universidade Federal do Rio Grande
do Norte, Instituto Metrópole Digital, Programa de Pós-graduação
em Engenharia de Software. Natal, RN, 2017.
   Orientador: Prof. Dr. Rummenigge Rudson Dantas.
   1. Ambientes Virtuais de Aprendizagem - Dissertação. 2.
Moodle - Dissertação. 3. Metadados - Dissertação. 4. LTI -
Dissertação. 5. Objetos de Aprendizagem - Dissertação. 6.
Repositório de Objetos de Aprendizagem - Dissertação. I. Dantas,
Rummenigge Rudson. II. Título.
RN/UF/BCZM                                  CDU 37.091.64:004
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Saulo Rufino de Sá
Arquitetura de comunicação entre AVAs e objetos de
aprendizagem dinâmicos utilizando a especificação IMS
LTI
Dissertação de Mestrado apresentada ao Pro-
grama de Pós-graduação em Engenharia de
Software da Universidade Federal do Rio
Grande do Norte como requisito para a ob-
tenção do grau de Mestre em Engenharia de
Software.
Trabalho aprovado. Natal-RN, 17 de agosto de 2017:
Rummenigge Rudson Dantas
Orientador
Charles Andrye Galvão Madeira
Convidado Interno
Cláudia Maria Fernandes Araújo
Ribeiro
Convidado Externo
Natal-RN
Agosto 2017
Resumo
Os Objetos de Aprendizagem (OAs) são recursos modulares reutilizáveis importantes para
a Educação a Distância (EaD) e integram os Ambientes Virtuais de Aprendizagem (AVAs),
compondo o leque de opções que podem ser utilizadas pelos professores em seu projeto de
ensino. Os OAs podem ficar diretamente hospedados em um AVA ou armazenados em um
Repositório de Objetos de Aprendizagem (ROA), que são próprios para hospedá-los de
forma centralizada, descrevendo suas características e utilizando metadados padronizados
com mecanismo de busca eficiente para encontrar o objeto solicitado. Para que os objetos
sejam acessados e utilizados em mais de um AVA, é necessário a existência de mecanismos
que os tornem interoperáveis. Este artigo trata da proposta de uma arquitetura e interface
para integração dos objetos de um repositório com o AVA Moodle utilizando a especificação
LTI.
Palavras-chave: Moodle. Metadados. IMS. LTI. Objetos de Aprendizagem. Repositório
de Objetos de Aprendizagem. Integração.
Abstract
The Learning Objects (LO) are importants modular and reusable resources to Distance
Education thatt composes the Learning Management Systems (LMS), building a tool kit
that can be used for teachers in their learning project and a course’s activity fluxs.The
LOs can ber hosted directly into LMS or stored into Learning Objects Repositories (LOR),
that are suitable to host them in centered form, describing their details using metadata
and with eficient search engine for find the requested object. The stored objects in the
LOR can be accessed and used in severals LMSs that include them, increasing the resource
available variety to mount a course whith their evaluative activities. This dissertation
aproachs the proposal of architecture for integration of the Distance Education Secretary’s
(DES) LOR of Federal University of Rio Grande do Norte with LMS Moodle using tha
LTI especification developed by IMS Global Leaning Consortion.
Keywords: Moodle. Metadata. IMS. LTI. Learning Object. Learning Objects Repository.
Integration.
Lista de ilustrações
Figura 1 – Polos EaD atendidos pela SEDIS. . . . . . . . . . . . . . . . . . . . . . 15
Figura 2 – Exemplo do GradeBook com as notas dos alunos no Moodle. . . . . . . 22
Figura 3 – Tela inicial do repositório de objetos educacionais. . . . . . . . . . . . . 25
Figura 4 – Exemplo da utilização do DC no BIOE. . . . . . . . . . . . . . . . . . 27
Figura 5 – Esquema das especificações base do CC. . . . . . . . . . . . . . . . . . 29
Figura 6 – Esquema básico do funcionamento da especificação LTI. . . . . . . . . 30
Figura 7 – Esquema chave de comunicação LTI 2.0 LTI. . . . . . . . . . . . . . . . 31
Figura 8 – Representação do objeto JSON na especificação JSON-LD . . . . . . . 33
Figura 9 – Esquema em alto nível do funcionamento do Caliper. . . . . . . . . . . 34
Figura 10 – Comunicação bidimensional e troca de informação entre o COALA e o
LMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 11 – Cenários representados como diagrama de caso de uso . . . . . . . . . 43
Figura 12 – Modelo conceitual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 13 – Parte da tela de cadastro de consumidores na BDI. . . . . . . . . . . . 48
Figura 14 – Parte da tela de cadastro de uma ferramenta externa no Moodle. . . . 49
Figura 15 – Diagrama de sequência com a ordem cronológica do processo de iniciali-
zação de uma aplicação. . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 16 – Diagrama de classes com estereótipos. . . . . . . . . . . . . . . . . . . 51
Figura 17 – Aplicação adaptada para trocar de dados. . . . . . . . . . . . . . . . . 53
Figura 18 – Comparativo da necessidade de utilização de OAs diferentes X conheci-
mento da existência do ROA, N=28. . . . . . . . . . . . . . . . . . . . 55
Figura 19 – Participantes que consideram importante que a SEDIS tenha um repo-
sitório que seja integrado ao AVA. . . . . . . . . . . . . . . . . . . . . . 56
Figura 20 – Figura 20a. Distribuição de testadores por sexo, N=5; Figura 20b.
Distribuição de testadores por idade, N=5. . . . . . . . . . . . . . . . . 61
Figura 21 – Tela de seleção de aplicações. Descrição e botão para copiar identificador. 63
Figura 22 – Gráfico com a pontuação de cada testador obtida via SUS . . . . . . . 64
Figura 23 – Mostra a distribuição da pontuação por afirmação do SUS . . . . . . . 65
Lista de tabelas
Tabela 1 – Tabela dos quinze elementos básicos do DC . . . . . . . . . . . . . . . 26
Tabela 2 – Atributos educacionais utilizados na descrição dos objetos. . . . . . . . 28
Tabela 3 – Tabela comparativa dos trabalhos relacionados . . . . . . . . . . . . . 40
Tabela 4 – Primeiro cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Tabela 5 – Segundo cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Tabela 6 – Terceiro cenário: O professor solicita a equipe de materiais interativos
uma nova aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Tabela 7 – Tabela comparativa da BDI com os trabalhos relacionados . . . . . . . 66
Lista de abreviaturas e siglas
API Application Programming Interface
AVA Ambiente Virtual de Aprendizagem
BIOE Banco Internacional de Objetos Educacionais
CINTED Centro Interdisciplinar de Novas Tecnologias na Educação
EaD Educação a Distância
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
IEEE Instituto de Engenheiros Eletricistas e Eletrônicos
IMSCP IMS Content Package
JSON JavaScript Object Notation
JSON-LD JavaScript Object Notation - Linking Data
LMS Learning Management System
LOM Learning Object Metadata
LTI Learning Tools Iteroperability
LTSC Technology Standards Committee
MCT Ministério da Ciência e Tecnologia
OEI Organização dos Estados Ibero-americanos
OA Objeto de Aprendizagem
PHP Hypertext Preprocessor
RDF Resource Description Framework
RECIPP Repositório Científico do Instituto Politécnico do Porto
RELPE Rede Latino-americana de Portais Educacionais
ROA Repositório de Objetos de Aprendizagem
SCORM Sharable Content Object Reference Model
SEDIS Secretaria de Educação a Distância
SSL Secure Socket Layer
TIC Tecnologias da Informação e Comunicação
TSL Transport Layer Security
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
WRAP Web Resource Authorization Profiles
XML eXtensible Markup Language
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 Motivação do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Abordagem Metodológica . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 20
2.1 Ambientes Virtuais de Aprendizagens e EaD . . . . . . . . . . . . . . 20
2.1.1 Moodle, seus objetos de aprendizagem e livro de notas . . . . . . . . . . . 21
2.2 Repositórios de Objetos de Aprendizagem (ROA) . . . . . . . . . . . 22
2.2.1 Características principais dos ROAs . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 Banco de Internacional de Objetos Educacionais (BIOE) . . . . . . . . . . 24
2.2.3 Padrões de Metadados para Objetos de Aprendizagem . . . . . . . . . . . 25
2.2.4 Coletânea de entidades de suporte ao uso de tecnologias na aprendizagem . 27
2.3 Padrões de tecnologias educacionais interoperáveis . . . . . . . . . . 27
2.3.1 IMS Global Learning Consortium . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2 Learning Tools Interoperability (LTI) . . . . . . . . . . . . . . . . . . . . . 29
2.3.2.1 Processo de comunicação entre TC e TP . . . . . . . . . . . . . . . . . . . . 31
2.3.3 Caliper Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.4 ADL e xAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.5 Caliper e xAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.1 Cocriação e avaliação de recursos educacionais abertos e acessíveis . . . . . 37
2.4.2 Uso do LTI para aumentar o aprendizado distribuído . . . . . . . . . . . . 38
2.4.3 Uso do padrão LTI para integração com o AVA . . . . . . . . . . . . . . . 39
2.4.4 Integração de Ambiente Virtual de Aprendizagem com Repositório Digital . 39
3 BIBLIOTECA DIGITAL INTEGRADA (BDI) . . . . . . . . . . . . . 41
3.1 Análise de domínio do problema . . . . . . . . . . . . . . . . . . . . . 41
3.2 Materiais e Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1 Sistematização da Biblioteca Virtual . . . . . . . . . . . . . . . . . . . . . 44
3.2.1.1 Utilização do framework Laravel . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.2 OAs que enviam resultados para o GradeBook . . . . . . . . . . . . . . . . 45
3.2.3 Modelo conceitual estendido . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.4 Teste de usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Solução proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 Moodle e BDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.1 Autenticação e inicialização de aplicações da BDI . . . . . . . . . . . . . . 49
3.5 Comunicação entre as aplicações e a BDI . . . . . . . . . . . . . . . 51
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1 Estudo exploratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.1 Questionário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.1.1 Análise de dados do questionário . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.2 Análise da entrevista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Teste de usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.1 Abordagem da avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2 Teste de usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.3 Interpretação dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3 Análise comparativa dos resultados . . . . . . . . . . . . . . . . . . . 65
5 CONCLUSÃO E TRABALHOS FUTUROS . . . . . . . . . . . . . . 67
5.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 Limitações do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
APÊNDICES 74
APÊNDICE A – FORMULÁRIO DE PESQUISA SOBRE REPO-
SITÓRIO INTEGRADO AO MOODLE ACADÊ-
MICO DA SEDIS . . . . . . . . . . . . . . . . . . 75
APÊNDICE B – TERMO DE AUTORIZAÇÃO DE PESQUISA AS-
SINADO . . . . . . . . . . . . . . . . . . . . . . . 79
APÊNDICE C – ENTREVISTA SEMI-ESTRUTURADA COM A CO-
ORDENAÇÃO DE PRODUÇÃO DE MATERIAIS
INTERATIVOS . . . . . . . . . . . . . . . . . . . . 81
APÊNDICE D – LISTA DE TAREFAS PARA REALIZAÇÃO DO
TESTE DE USABILIDADE . . . . . . . . . . . . . 85
APÊNDICE E – TELA DE CADASTRO DE APLICAÇÕES DA BI-
BLIOTECA DIGITAL INTEGRADA (BDI) . . . . 87
ANEXOS 89
ANEXO A – RESPOSTAS DA PESQUISA SOBRE REPOSITÓ-
RIO INTEGRADO AO MOODLE ACADÊMICO DA
SEDIS . . . . . . . . . . . . . . . . . . . . . . . . . . 90
ANEXO B – QUESTIONÁRIO SYSTEM USABILITY SCALE (SUS)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
13
1 Introdução
A Educação a Distância (EaD) se tornou uma realidade no cenário nacional por
meio do avanço das tecnologias de telecomunicações, propiciando uma oferta de diversos
formatos e modalidades de cursos utilizando Ambientes Virtuais de Aprendizagem (AVAs),
que ganharam popularidade entre usuários e desenvolvedores interessados em melhorar
essa tecnologia. Pereira, Schmitt e Dias (2007, p.4) conceitualiza AVAs como "mídias que
utilizam o ciberespaço para veicular conteúdos e permitir interação entre os atores do
processo educativo".
Um dos projetos AVA mais difundidos atualmente, muito utilizado no Brasil e
que possui código fonte aberto é o Moodle. Ele possui uma comunidade ativa de 530
desenvolvedores registrados em 57 países (MOODLE, 2016), focados na evolução de seus
módulos principais.
A Secretaria de Educação a Distância (SEDIS) da Universidade Federal do Rio
Grande do Norte (UFRN) utiliza o Moodle como seu AVA para EaD, inserindo professores,
alunos e tutores em disciplinas tratadas no ambiente como cursos. Em cada um desses
cursos, o professor ou projetista de conteúdo utiliza os Objetos de Aprendizagem (OAs)
disponíveis no AVA para implementar o seu projeto, definindo objetivos e incluindo recursos
e orientações para que os alunos consigam completar as atividades (ADELSBERGER;
PAWLOWSKI et al., 2008) . Wiley (2003, p.7) discute o significado de OAs e os define como
"qualquer recurso digital que possa ser reutilizado para dar suporte ao aprendizado", ou seja,
recursos que podem ser reutilizados um número de vezes em contextos de aprendizagem
diferentes, incluindo qualquer material grande ou pequeno entregue através da internet.
Neste mesmo trabalho Wiley restringe sua definição para englobar apenas materiais digitais,
diferente da definição dada pelo Learning Technology Standards Committee (LTSC), que
define OAs como "qualquer entidade, digital ou não que pode ser reutilizada ou referenciada
na aprendizagem baseada em tecnologias"(WILEY, 2003, p.4).
Como em qualquer cenário que envolve tecnologia da informação, a área de EaD
precisa ser sincronizada com as inovações tecnológicas, focando no melhoramento contínuo
de suas funcionalidades. Os cursos que são postos para os alunos e a comunidade em geral
devem apresentar recursos que permitam a permanência deles no ambiente de forma efetiva,
além de um bom projeto de aprendizagem. O AVA deve oferecer aos professores formas
de aplicar suas atividades, medir o desempenho dos alunos, registrar suas dificuldades e
facilidades encontradas durante o percurso. Para isso, ele precisa de um leque de ferramentas
vasto, que possibilite a ampliação de acordo com suas necessidades. Além disso, o aluno
deseja encontrar cada dia mais interatividade no seu ambiente, onde ele possa se sentir
Capítulo 1. Introdução 14
confortável e entusiasmado para realizar de suas atividades.
Ao acessar o ambiente virtual para aplicar seu plano de ensino, o docente escolhe
quais ferramentas irá utilizar dentre as existentes no AVA. No caso do Moodle, ele pode
fazer o upload de imagens ou utilizar outros recursos multimídias que posteriormente
podem ser baixados pelos alunos. Contudo, a elaboração das atividades e interações em
geral estão restritas aos recursos existentes no ambiente.
Apesar de o Moodle ser um ambiente extensível, os formatos das atividades
propostas pela equipe pedagógica podem ser muito específicos, de tal forma que os
recursos disponibilizados no AVA não sejam suficientes para preencher as lacunas de
aprendizagem. Essas constatações levam a observar a necessidade de fabricação de OAs
personalizados para aplicação em uma tarefa interativa, com objetivos específicos ou até
mesmo um OA que represente um curso inteiro, com seus próprios caminhos avaliativos e
interface totalmente personalizada.
Atualmente a SEDIS conta com um repositório de OAs personalizados, desenvolvido
internamente e chamado de Biblioteca Digital, o qual não possui a capacidade de registrar
os resultados das interações dos alunos, como também não se comunica com seus AVAs.
Este trabalho apresenta uma proposta de arquitetura conceitual visando proporcio-
nar a comunicação da Biblioteca Virtual com as instâncias dos AVAs da SEDIS. Atualmente
a biblioteca não é capaz de trocar nenhuma informação com ambiente, nem de fornecer
acesso facilitado e centralizado aos objetos.
1.1 Motivação do trabalho
A SEDIS foi criada na UFRN com o objetivo de fomentar a modalidade de educação
a distância utilizando tecnologias da informação como meio para proporcionar o ensino-
aprendizagem. Além de fornecer cursos de extensão, graduação e pós-graduação, também
são produzidos materiais impressos, digitais e estruturas de apoio localizadas nos municípios
que são polos equipados com laboratórios de informática, bibliotecas e ambientes específicos
para cada área. Os polos atendidos atualmente estão disponíveis na Figura 1.
Hoje existem 15 AVAs em funcionamento, que são instâncias do Moodle para atender
objetivos da instituição. Entre essas instâncias se destaca o Moodle Acadêmico, que foi
utilizado para seleção dos sujeitos da pesquisa. Nele existem as ofertas das graduações
semipresenciais, pois, apesar da maioria das atividades serem desenvolvidas a distância,
provas presenciais também são aplicadas nos polos. Os cursos fornecidos nesta plataforma
são os seguintes:
• Administração Pública (Bacharelado);
Capítulo 1. Introdução 15
• Tecnólogo em Gestão Pública (Tecnólogo);
• Licenciaturas:
– Ciências Biológicas;
– Educação Física;
– Física;
– Geografia;
– História;
– Letras;
– Matemática.
Na EaD, o professor tem um papel fundamental que não se resume a utilização das
tecnologias disponíveis. Ele também é responsável pelo projeto pedagógico das disciplinas,
agindo como um conceptor e realizador de cursos e materiais didáticos, ao preparar os
planos de estudo, currículos e responder as dúvidas relacionadas aos conteúdos ou à
organização dos estudos e das disciplinas. O docente exerce uma função central em todo
processo formativo, conversando com coordenadores, artistas gráficos, tutores técnicos e
editores (MOTA, 2015).
Figura 1 – Polos EaD atendidos pela SEDIS.
Fonte: http://sedis.ufrn.br/index.php/module-positions/localizacoes
Capítulo 1. Introdução 16
Analisando a função central do professor, é possível perceber que ele conecta as
partes envolvidas no processo de ensino-aprendizagem a distância, ao observar as reais
necessidades de produção de materiais que ajudarão no seu plano de ensino impresso
ou digital. Por meio de entrevista realizada com a coordenadora do setor de produção
de materiais interativos da SEDIS, foi possível obter uma visão histórica e evolutiva da
produção de materiais e da criação de um setor para produção de conteúdos interativos
digitais.
Segundo a coordenadora, a Secretaria sempre teve tradição no que diz respeito
aos materiais impressos produzidos para os cursos do Moodle acadêmico distribuídos nos
polos. Contudo, há dez anos, o acesso à internet ainda era limitado, então a produção de
materiais interativos digitais não era tão solicitada. Com o passar do tempo, se tornou
possível o início tímido da produção desses materiais, porém com algumas limitações
que até hoje impedem a utilização mais frequente e de forma mais adequada. Durante
a entrevista foi possível observar os seguintes problemas relacionados à produção desses
materiais e à forma como eles são acessados:
• Houve a necessidade de trocar o formato Flash1 por HyperText MarKup Language
(HTML) versão 5 na produção de novos OAs. O desenvolvimento do HTML5 tem
como foco os princípios de (1) compatibilidade; (2) utilidade; (3) interoperabilidade;
(4) acesso universal (SILVA, 2014);
• A biblioteca digital onde os OAs são armazenados não faz nenhum controle de acesso
de usuários;
• As atividades são disponibilizadas para os alunos por meio de links que levam
diretamente ao recurso específico;
• Nenhum dos OAs se comunica com o Moodle enviando nota total de interação ou
controle de acesso dos usuários, ou seja, "são objetos isolados", segundo a coordena-
dora.
A biblioteca digital disponível atualmente contém OAs dinâmicos personalizados
que são solicitados pelos docentes da secretaria com o objetivo de suprir necessidades
de aprendizagem específicas. Ela possui três categorias de OAs cadastradas: impressos,
interativos e videoaula. Tanto o material impresso quanto as videoaulas são facilmente
adicionados como recurso ao Moodle, podendo ser encontrado facilmente no escopo de um
curso, o que possibilita registros de visualização dos usuários no AVA.
1 "Formato que codifica áudio e vídeo sincronizados. Os dados de áudio e vídeo dentro dentro do arquivo
FLV são codificados da mesma forma com áudio e vídeo em arquivos SWF" (ADOBE SYSTEMS
INCORPORATED, 2010, p.1).
Capítulo 1. Introdução 17
Os materiais interativos são ferramentas que possibilitam interação com o aluno e po-
dem ser representados por jogos, apresentações, livros interativos, etc. Segundo Koshiyama
(2014, p.15) "materiais interativos fazem parte da família dos Objetos de Aprendizagem".
Esses objetos foram desenvolvidos utilizando a tecnologia flash que atualmente está em
desuso pois não facilita o acesso de pessoas com deficiência visual, além de não funcionar
em alguns browsers e dispositivos móveis. Atualmente são utilizados recursos do HTML5
e javascript para entregar as vantagens que o flash não era capaz de fornecer no cenário
tecnológico atual.
Este último tipo de recurso é o que será focado neste trabalho, pois ele é mais
adequado para registro de interações, geração de notas e comunicação com o Moodle.
Existem 17 recursos interativos disponíveis na biblioteca que podem ser acessados
por qualquer pessoa que possua o link de acesso a eles, contudo, nenhum registro de
interação, nota ou controle de acesso é realizado.
Avaliando estas situações de dificuldade de comunicação dos OAs produzidos sob
demanda específica com o Moolde, juntamente a ausência de formas de avaliar os alunos na
utilização destes objetos, foi possível enxergar uma oportunidade de melhorar o processo
de produção desses OAs. Foi ainda possível constatar a necessidade de transformar a
biblioteca digital em um sistema capaz de comunicar os OAs com o Moodle, e de propor um
modelo conceitual completo que prospectasse até onde seria possível a troca de informações
entre as partes.
1.2 Objetivo Geral
Diante do cenário apresentado na seção anterior, este trabalho tem o objetivo de
propor uma arquitetura conceitual e um protótipo funcional que seja capaz de integrar
seguramente os AVAs da SEDIS com os OAs interativos da Biblioteca Digital. Dessa forma,
será possível efetuar o registro de desempenho dos alunos obtido por meio das interações
com os OAs no livro de notas do AVA. A arquitetura conceitual proposta mostra até onde
esta integração pode chegar e quais tecnologias e dados são possíveis produzir para futuras
análises.
1.2.1 Objetivos Específicos
• Transformar a biblioteca virtual em um sistema capaz de integrar seus objetos as
instâncias Moodle da SEDIS, utilizando padrões de comunicação abertos;
• Propor mecanismo que facilite a fabricação dos OAs compatíveis com o envio de
informações para os AVAs;
Capítulo 1. Introdução 18
• Proporcionar o envio dos resultados obtidos nos OAs para o GradeBook do Moodle;
• Propor uma arquitetura conceitual completa, apontando o rumo dos próximos
trabalhos.
1.3 Abordagem Metodológica
Levando em consideração os objetivos apresentados, esta pesquisa é considerada ex-
ploratória, pois se baseia em levantamento bibliográfico; análise de exemplos que estimulem
a compreensão; levantamento utilizando o método de pesquisa (Survey), ideal para coleta
de dados quantitativos utilizando o instrumento questionário que, neste caso, combinou
questões quantitativas e qualitativas, caracterizando uma investigação denominada de
"multimétodo"(FREITAS et al., 2000). Este questionário teve caráter exploratório com
nove perguntas objetivas e subjetivas para conhecer o comportamento dos professores
quanto à utilização dos OAS da Biblioteca Digital atual (questionário disponível no Apên-
dice A) (PRODANOV; FREITAS, 2013); entrevista investigativa com cinco perguntas
interpretativas realizada com a coordenação de produção de materiais interativos da SEDIS
(entrevista transcrita no Apêndice C). Essa entrevista teve o objetivo de conhecer melhor
o processo interno de criação e disponibilização dos materiais para os professores e alunos,
assim como identificar os problemas existentes, levantar os requisitos e propor a possível
forma de resolução desses problemas. Os dois instrumentos utilizados foram autorizados
pela coordenação da SEDIS (Apêndice B).
Do ponto de vista dos procedimentos técnicos a pesquisa é bibliográfica, pois se
fundamenta em publicações da área. É documental, pois também se baseia em materiais
que não passaram por tratamento analítico como: análise dos repositórios de outras
instituições, pesquisa de bibliotecas de código aberto disponíveis no github 2 e em outros
sites disponíveis.
Se focarmos na perspectiva da abordagem do problema, a pesquisa é qualitativa,
pois é possível observar a necessidade da existência de um repositório de OAs que seja
capaz de se integrar aos AVAs e de dar um retorno mais detalhado da participação dos
alunos. Além de ser quantitativa, pois foram observados os percentuais de professores que
já utilizaram de alguma forma OAs da Biblioteca Digital, quantos sabiam da existência
desse repositório e quantos conseguiram colher algum resultado das atividades realizadas
pelos alunos.
2 Gerenciador de repositório de códigos-fonte aberto git. https://github.com/explore
Capítulo 1. Introdução 19
1.4 Organização do trabalho
Este trabalho está organizado em cinco capítulos incluindo este capítulo introdutório.
O capítulo 2 apresenta uma visão geral dos temas importante para o entendimento do
trabalho. São definidas as tecnologias utilizadas para o desenvolvimento do projeto, assim
como para os trabalhos futuros. Neste capítulo também são apresentados os trabalhos
relacionados.
No capítulo 3 são apresentados os detalhes para a resolução do problema como
definição da arquitetura conceitual, análise dos requisitos e o desenvolvimento do protótipo
funcional.
O capítulo 4 apresenta os resultados entregues pelo projeto, que compreende os
resultados do estudo exploratório e o teste de usabilidade para validação do protótipo
funcional.
Por fim, capítulo 5 finaliza este documento apesentando as conclusões que puderam
ser observadas durante a execução do trabalho, além de estabelecer os trabalhos futuros
para complementação e evolução da ferramenta desenvolvida.
20
2 Fundamentação Teórica
Neste capítulo serão abordados os conceitos dos temas relevantes para compreensão
do estudo realizado.
2.1 Ambientes Virtuais de Aprendizagens e EaD
A evolução das Tecnologias da Informação e Comunicação (TICs) permitiu o
aumento do acesso a modalidades de ensino completamente a distância ou semipresencial,
impulsionando as instituições de ensino, em diferentes níveis de capacitação, a oferecerem
essas modalidades de curso utilizando AVAs. Sem eles, tanto os professores quanto os alunos,
possivelmente não teriam toda interatividade e dinamicidade na troca de informações
disponíveis atualmente.
A EaD desde os seus primórdios foi definida como um processo de ensino-aprendizagem
mediado por tecnologias, onde docentes e discentes encontram-se separados tanto no es-
paço físico como no momento onde existe interação entre as duas partes (MORAN, 2008).
Obviamente a velocidade com que acontecia essa interação era bem mais lenta do que
atualmente, pois os meios de comunicação utilizados eram correio, rádio, televisão, telefone,
etc.
O AVA, também conhecido como sistema gerenciador de aprendizagem (Learning
Management System - LMS), é uma aplicação web que objetiva principalmente o geren-
ciamento de atividades educacionais de forma colaborativa, oferecendo espaços virtuais
para que os alunos possam se reunir, compartilhar, colaborar e aprender juntos (PAIVA,
2010). Para que as atividades ocorram, os ambientes disponibilizam ferramentas síncronas
e assíncronas para troca de informações como: chats, questionários, livro de anotações, etc.
Atualmente existem vários AVAs disponíveis no mercado. De acordo com o site
Capterra (2015), os três mais populares são: Edmodo1, Moodle2 e o Blackboad3. O Moodle
atualmente é o que mais possui usuários.
Neste trabalho, será utilizado LMS Moodle como parte dos estudos, para atender
a requisitos metodológicos, execução de testes e validações.
1 https://www.edmodo.com/
2 https://moodle.org/
3 http://blackboard.grupoa.com.br/
Capítulo 2. Fundamentação Teórica 21
2.1.1 Moodle, seus objetos de aprendizagem e livro de notas
O Moodle é um AVA ou Course Management System (CMS) de código fonte aberto
que pode ser implantado em qualquer servidor que execute códigos escritos na linguagem
PHP e tenha algum dos seguintes serviços de banco de dados instalado: PostgreSQL,
MariaDB, MySQL, MSSQL, Oracle.
Como é um sistema modular, ele é formado por vários componentes que seguem
regras específicas de implementação para fornecer funcionalidades específicas no sistema.
Para que um módulo seja incorporado ao ecossistema e funcione corretamente, ele deve
seguir os padrões de implementação especificados para cada tipo/finalidade.
Esses módulos são também chamados de plugins. Os tipos de componentes mais
comuns no repositório de plugins do Moodle MoodlePlugins (2016) são:
• Blocos: ferramentas que podem ser anexadas aos cursos do Moodle para fornecer
acesso rápido a alguma informação específica;
• Módulos: tipo de plugin que permite inclusão de conteúdo nos cursos. Ele também
representa uma variedade de atividades que podem ser criadas. Como exemplo temos:
questionários, fóruns, tarefas de envio de arquivos, etc;
• Temas: toda a parte organizacional e de estilo do Moodle fica aqui. Define toda a
parte estrutural e disposição de cada componente no sistema;
• Local: em geral, são plugins que não se encaixam em nenhuma outra categoria de
plugin. Se enquadram aqui serviços web personalizados, entre outras funcionalidades.
Este tipo de componente também deve seguir regras e estruturas específicas.
Com essas estruturas predefinidas, o Moodle pode incorporar plugins desenvolvidos
pela comunidade para atender a inúmeras necessidades educacionais.
Um professor utiliza o plugin do tipo módulo para aplicar as atividades e disponi-
bilizar os materiais como o conteúdo que os alunos acessarão durante o período que eles
estiverem matriculados nos cursos.
Uma atividade pode ou não ser avaliativa. Caso uma atividade esteja valendo
alguma nota, os resultados ficam gravados no livro de nota do curso em questão. Este livro
registra os resultados de participação de cada aluno. A Figura 2 demonstra a visualização
do livro de notas ou GradeBook de um curso do Moodle.
É possível observar na imagem que as notas de um usuário pode ser dadas de formas
diferentes. Além de valores numéricos, as notas também podem ser atribuídas utilizando
escalas personalizadas, como é possível visualizar na atividade da coluna U1:Task 1, notas
como: A, C, B- e D
Capítulo 2. Fundamentação Teórica 22
Figura 2 – Exemplo do GradeBook com as notas dos alunos no Moodle.
Fonte: Barrington (2014, p. 8)
Também é possível perceber que o sistema calcula a nota geral do curso ou a média
geral de uma determinada atividade avaliativa.
Podemos considerar os plugins do tipo módulo como OAs, pois eles podem ser
definidos como “qualquer recurso digital que possa ser reutilizado para o suporte ao
ensino” Wiley (2001, p.7) e atendem a características típicas de um OA como: flexibilidade,
facilidade para atualização, customização e interoperabilidade (PRATA; NASCIMENTO,
2007). O último item pode ser questionado, pois o AVA possui sua própria estrutura
de desenvolvimento de módulos de atividades. Contudo “você pode importar e exportar
recursos e atividades entre cursos facilmente” (MOODLE, 2008).
2.2 Repositórios de Objetos de Aprendizagem (ROA)
O desempenho do aluno depende diretamente de como um professor prepara sua
estratégia para atingir os objetivos (KAY; KNAACK; PETRARCA, 2009). Em vista disso,
a melhora da aprendizagem não está restrita aos objetos, mas a união desses recursos com
a estratégia aplicada na sua utilização. É necessário saber se um curso que abriga vários
conteúdos pode ser ministrado utilizando apenas um objeto ou se deve ser complementado
com outros.
Os repositórios oferecem uma base para que o autor de um curso consiga acessar de
forma centralizada o catálogo desses objetos e tenha como utilizá-los em um AVA. Durante
investigação do uso de OAs no processo de aprendizagem na disciplina de matemática na
escola secundária, Kay, Knaack e Petrarca (2009) chegou a conclusão que a maioria dos
professores utilizavam essas ferramentas para aumentar as opções para fornecer formas
diferentes de apresentar um conteúdo.
Capítulo 2. Fundamentação Teórica 23
Portanto, os recursos educacionais são mais eficientes quando são organizados,
catalogados e armazenados em um repositório (TAROUCO; FABRE, 2003), pois professores,
alunos e editores de cursos podem obter respostas através dos metadados dos objetos
pesquisados de forma mais precisa e fácil. Isso é importante, principalmente em um
cenário onde existem várias instâncias de AVAs com vários cursos em contextos e áreas
diferentes, onde, por exemplo, os editores de curso precisam acessar uma lista centralizada
com alternativas que possam ser reutilizadas em qualquer uma dessas instâncias. Caso
essa lista não seja centralizada, a busca pode ficar fragmentada deixando alguns objetos
subutilizados.
Afonso et al. (2011, p.148-158), define repositórios de recursos educacionais digitais
ou repositórios de OAs como “sistemas de informação que permitem o aproveitamento
e reutilização de objetos educacionais como, animações, softwares educacionais, vídeos,
mapas, entre outros, construindo um acervo dinâmico que subsidia as diversas práticas
pedagógicas”. Para complementar a definição anterior, um repositório também pode
proporcionar interoperabilidade entre os OAs (ADELSBERGER; PAWLOWSKI et al.,
2008).
Muitos dos repositórios atuais abrigam objetos como imagens, vídeos, animações
e raramente objetos proporcione interação dos usuários. A próxima seção diferencia e
exemplifica repositórios utilizados atualmente descrevendo suas principais características.
2.2.1 Características principais dos ROAs
A evolução das tecnologias web permitiu a implantação de diversos repositórios
globalmente acessíveis via internet e que atendem a uma gama de propósitos, grupos de
temas e áreas específicas, cobrando ou não pelo acesso a seu conteúdo. Um ROA pode
abrigar recursos relacionados a diversas áreas.
A organização interna de acesso e armazenamento dos objetos existentes nos ROAs
podem variar, podendo ser centralizada ou distribuída. Adelsberger, Pawlowski et al. (2008)
especificou três tipos de repositórios baseado-se na localidade dos OAs:
1. Recurso hospedado no site: são repositórios que possuem sua própria estrutura
de armazenamento físico dos recursos;
2. Links com metadados hospedados em outros sites: possui os metadados
descrevendo cada objeto que está indexado em seu sistema de buscas, contudo não
armazena os objetos propriamente ditos;
3. Sites Híbridos: fornecem recursos e links para conteúdos externos. Eles possuem
recursos armazenados, como metadados fornecendo links apontando para ferramentas
específicas encontradas através do mecanismo de busca;
Capítulo 2. Fundamentação Teórica 24
Um ROA pode abriga os mais variados tipos de objetos, que podem ser categorizados
por suas características chaves, como uma imagem, vídeo, lições, módulos implementados
como applets ou até mesmo cursos completos. Estes repositórios oferecem características
básicas comuns, como a capacidade de fazer buscas, permitir o upload e o download dos
objetos quando eles estão hospedados no próprio site ou fornecer os metadados referentes
a outros sites. Contudo, o download e a utilização deles deve respeitar regras de direitos
autorais que cada um desses objetos possui.
A catalogação dos objetos é um ponto importante dentro de um repositório, pois ela
se destina à descrição das características deles. “O objetivo da catalogação é fornecer uma
representação do objeto, permitindo identificá-lo, localizá-lo e representá-lo” (AFONSO,
2010).
2.2.2 Banco de Internacional de Objetos Educacionais (BIOE)
O BIOE4 é um repositório de objetos educacionais de acesso público, criado em
2008 pelo Ministério da Educação (MEC) em parceria com o Ministério da Ciência e
Tecnologia (MCT), Rede Latino-americana de Portais Educacionais (RELPE), Organização
dos Estados Ibero-americanos (OEI) e universidades brasileiras. Ele apresenta objetos
em vários formatos, somando 19.842 objetos (BIOEMEC, 2015). O BIOE está disponível
nacionalmente e para utilização de outros países, o que promove a troca de experiências
e o nivelamento com outros países que estão mais avançados na área de tecnologias
educacionais.
Ele foi desenvolvido utilizando como base o DSpace5, que é um software livre de
código fonte aberto. Ele implementa as principais funcionalidades de um repositório, facili-
tando o acesso a todos os tipos de conteúdos digitais, ou seja, o coração das funcionalidades
existentes no BIOE são oriundas do DSpace.
A página inicial conta com links de acesso rápido categorizados por modalidades
de ensino e por buscas detalhadas, onde é possível aplicar filtros variados para pesquisar
objetos e suas coleções, podendo especificar idiomas, países, tipos de recursos e coleções,
etc. A Figura 3 mostra o formulário de seleção desses filtros.
Ao realizar pesquisas no repositório BIOE é fácil perceber que ele armazena os links
para realização dos downloads do objetos que podem estar hospedados tanto no próprio
site quando em outros. O procedimento de utilização dos objetos parte do download e
execução de seu conteúdo. O objeto pode ser incorporado a um AVA como o Moodle,
contudo, os objetos não são executados dentro do próprio repositório.
4 http://objetoseducacionais2.mec.gov.br/
5 http://www.dspace.org/
Capítulo 2. Fundamentação Teórica 25
Figura 3 – Tela inicial do repositório de objetos educacionais.
Fonte: http://objetoseducacionais2.mec.gov.br/
2.2.3 Padrões de Metadados para Objetos de Aprendizagem
Segundo Silva (2011), metadados são dados que descrevem um conjunto de outros
dados, identificando e descrevendo a forma como eles podem ser organizados para que seja
possível a compreensão sobre a sua natureza, no intuito de facilitar a busca em repositórios,
e são importantes na definição da estrutura dos OAs. Pela sua importância, e por existir
muita dificuldade na representação das descrições, esforços foram feitos para que padrões
fossem definidos, como por exemplo os padrões: Sharable Content Object Reference Model
(SCORM), CanCore, IMS LD, Dublin Core e LOM que é do Instituto de Engenheiros
Eletricistas e Eletrônicos(IEEE). O LOM é o mais utilizado e compõe a base, ou parte dos
demais padrões citados anteriormente.
Para realizar a catalogação o BIOE utiliza um padrão aberto internacional, o
Dublin Core (DC). DC é uma recomendação do Dublin Core Metadata Initiative (DCMI)
que tem como objetivos o apoio à inovação compartilhada nas especificações de metadados
e às melhores práticas para atender o maior grau de abrangência em propósitos e modelos
de negócios.
DC utiliza para descrição dos metadados dos objetos o modelo genérico para
metadados Resource Description Framework (RDF) desenvolvido pela World Wide Web
Consortium (W3C) (DCMI, 2008). De acordo com a comunidade desenvolvedora, ele está
dividido em quatro níveis de interoperabilidade:
1. Nível 1 (Definição de termos compartilhados): neste primeiro caso a aplicação
Capítulo 2. Fundamentação Teórica 26
utiliza a linguagem natural para descrever seus dados. Neste nível não é necessário
especificar uma URI que defina um identificador único para um termo, contudo este
nível segue os quinze elementos do padrão DC. O nível de integração neste nível não
é alto;
2. Nível 2 (Semântica formal de interoperabilidade): O segundo nível é formal e
segue o modelo RDF. Utiliza URI seguindo as melhores práticas para dar suporte aos
dados ligados ou Linked Data para compartilhamento e conectividade de informações.
As propriedades e classes estão definidas no DMI Metadata Terms;
3. Nível 3 (Descrição sintática de interoperabilidade) e Nível 4 (Descrição
dos perfis de interoperabilidade): São níveis pouco comuns na prática. O nível
três está preocupado com a padronização da sintaxe dos registros dos metadados
e o quatro com a troca de dados entre aplicações utilizando os metadados, defi-
nindo restrições estruturais em XML com o uso do mesmo vocabulário para obter
compatibilidade com aplicações do mundo todo.
Na Tabela 1 são apresentados os 15 termos do padrão DC.
Tabela 1 – Tabela dos quinze elementos básicos do DC
Elemento Descrição
contributor Pessoa ou organização identificadaque contribui com o OA.
coverage Descreve o escopo de um OA.
creator Responsável pelo OA.
date Data de criação ou alteração do OA.
descrition Descrição do OA.
format Especifica o tipo do OA e seu tamanho físico.
identifier Uma referência não ambígua de um OA dentro de um dadocontexto.
language O idioma de referência do OA.
publisher Entidade responsável por disponibilizar o OA.
relation OA relacionado.
right Informações sobre os direitos assegurados sob o OA
source Link que aponta para a origem do OA
subject Os assuntos ou categorias de assuntos existentes no OA.Exemplo disponível na Figura 4.
title Nome dado ao OA.
type A natureza, ou o gênero do OA.
A Figura 4 é um exemplo que mostra a descrição dos metadados de um objeto
indexado pelo BIOE utilizando a especificação DC.
É possível perceber que a descrição qualificada utilizando URIs não está presente
na Figura 4, como também é perceptível que nem todos os elementos são de preenchimento
obrigatório.
Capítulo 2. Fundamentação Teórica 27
Figura 4 – Exemplo da utilização do DC no BIOE.
Fonte: http://objetoseducacionais2.mec.gov.br/handle/mec/20706?show=full
2.2.4 Coletânea de entidades de suporte ao uso de tecnologias na aprendizagem
Outro repositório conhecido nacionalmente é o Coletânea de Entidades de Suporte ao
uso de tecnologias na Aprendizagem (CESTA2), desenvolvido pelo Centro Interdisciplinar
de Novas Tecnologias na Educação (CINTED) da Universidade Federal do Rio Grande
do Sul (UFRGS). O CESTA pode ser considerado um repositório híbrido, que apresenta
tanto links para objetos de outros sites, como também os hospedados, característica que o
diferencia da sua primeira versão que apenas indexava links para outros sites.
Como o BIOE, ele também foi implementado utilizando o DSpace e as descrições
dos metadados dos seus objetos utilizando o padrão DC, contemplando os atributos
mais aceitos para interações com outras aplicações, como também incorpora atributos de
categoria educacional, descritos na Tabela 2.
Ao tentar realizar o acesso ao CESTA2, em 22 de julho de 2016, foi constatado que
o mesmo não encontrava-se disponível.
2.3 Padrões de tecnologias educacionais interoperáveis
Devido ao aumento da variedade de AVAs e de repositórios produzidos para a
EaD, as definições de padrões tornaram-se necessárias para que os recursos educacionais
pudessem ser mais compatíveis com diversos ambientes, facilitando a sua distribuição.
Todo esse esforço tem sido feito para atender à demanda crescente de recursos específicos
Capítulo 2. Fundamentação Teórica 28
Tabela 2 – Atributos educacionais utilizados na descrição dos objetos.
Atributo Descrição
Tipo de
interatividade
modo predominante de aprendizagem (ativa, expositiva,
mista)
Recurso
de aprendizagem
tipo específico do objeto (exercício, simulação, questionário,
diagrama, figura, gráfico, índice, slide, tabela, teste,
experiência, texto, problema, auto-avaliação, palestra)
Nível de
interatividade
grau de interatividade (muito baixo, baixo, médio, alto,
muito alto);
Usuário
final esperado
tipo de usuário para o qual foi desenvolvido o objeto
(professor, autor, aluno, gerenciador)
Ambiente
de utilização escola, faculdade, treinamento, outro
Faixa
etária idade do usuário final esperado
Descrição comentários sobre como esse objeto deve ser usado
para avaliação de aprendizagem.
Atualmente duas organizações sem fins lucrativos se destacam no desenvolvimento
de padrões e tecnologias com o objetivo de conseguir um nível mais alto e global de
interação entre tecnologias educacionais. Essas organizações são ADL e IMS Global.
2.3.1 IMS Global Learning Consortium
É um membro da organização global sem fins lucrativos que contribui para a
evolução das tecnologias educacionais, disponibilizando modelos de arquiteturas abertas e
extensíveis que favorecem a existência de ecossistemas compostos por produtos que podem
ser implantados rapidamente, em cenários que tenham capacidade de funcionar juntos
(KRAEFT, 2015b).
IMS incentiva que as instituições realizem o seu processo de certificação, como
forma de tornarem empresas confiáveis na prestação de serviços certificados.
O Common Catridge(CC) é um conjunto de padrões definidos pelos membros da
comunidade IMS com dois objetivos definidos: o primeiro é o fornecimento de normas
para representar materiais digitais de uma forma que eles sejam compatíveis com os mais
diversos AVAs. O segundo é a publicação de novos modelos para cursos online que sejam
interativos e customizáveis (KRAEFT, 2015a).
Tudo isso leva a um aumento da quantidade e abrangência dos cursos disponibili-
zados, a partir do ponto que as aplicações se comunicam e trocam dados.
Dentro do CC, existe uma subdivisão de padrões. O Thin Common Catridge
que fornece a interoperabilidade usando Learning Tools Iteroperability (LTI) seguindo o
Capítulo 2. Fundamentação Teórica 29
esquema da Figura 5:
Figura 5 – Esquema das especificações base do CC.
Fonte: https://www.imsglobal.org/cc/CCv1p0thin/ims_thinCC_impl-v1p0.html
A imagem mostra que o AVA ou LMS possui sua base de dados e aceita pacotes
IMS Content Package (IMSCP) utilizando a especificação. O AVA é capaz de registrar os
resultados que os alunos obtiveram na utilização do pacote IMSCP em seu livro de notas.
No lado direito da Figura 5, o aluno tem acesso a todo esse ecossistema acessando apenas
o seu ambiente de aprendizagem.
Além dos padrões apresentados, a IMS também possui outras especificações mais
novas, como o Caliper Analytics que define como OAs devem disparar eventos e registrá-los
durante uma interação de um usuário, para que seja possível realizar análises no que foi
registrado.
2.3.2 Learning Tools Interoperability (LTI)
Os AVAs atuais carregam dentro de suas fronteiras seus próprios objetos e recursos
administrativos para gerenciar seus usuários e seus desempenhos. Contudo, estes ambientes
são controlados, dificultando a integração de ferramentas externas desenvolvidas por outros
fornecedores na composição do plano de aprendizagem de um curso online. Quando isso
ocorre, outras ferramentas desenvolvidas com tecnologias, metodologias e designs diferentes,
podem ser deixadas de lado e os educadores elaboradores dos cursos ficam limitados aos
OAs preexistentes no AVA.
Segundo Alario-Hoyos et al. (2013), apesar dos AVAs fornecerem OAs predefinidos
e incluírem plugins para atender a alguma necessidade específica de ensino, muitos profis-
sionais da educação criticam estes ambientes pela reduzida quantidade dessas ferramentas
existentes na plataforma.
Capítulo 2. Fundamentação Teórica 30
O principal conceito por trás da especificação LTI é estabelecer um caminho padrão
para integrar aplicações educacionais ricas, geralmente fornecidas por outros fornecedores
utilizando AVAs, ROAs ou outros ambientes educacionais (KRAEFT, 2015c).
Na especificação LTI um AVA comumente assume o papel de Tools Consumers (TC)
, ator responsável por consumir informações de ferramentas externas ou Tools Providers
(TP) que são responsáveis por fornecer as funcionalidades e ferramentas acessadas.
Em suma, é possível acessar de forma direta uma aplicação externa baseada na
web e compatível com a especificação seguramente, disponibilizando uma nova ferramenta
educacional integrada ao ambiente consumidor.
A Figura 6 abaixo exemplifica o fluxo de um ecossistema construído utilizando a
especificação LTI.
Figura 6 – Esquema básico do funcionamento da especificação LTI.
Fonte: (KRAEFT, 2015c)
A Figura 6 mostra o desenvolvedor considerando ótima a ideia de construir as
ferramentas solicitadas utilizando a linguagem que ele está habilitado a usar. Nesse cenário
o desenvolvedor precisará implementar o código necessário para que ocorra a integração
da aplicação com o AVA. O processo ocorre de tal forma que toda a comunidade composta
por docentes, discentes e administradores do sistema pode utilizar as novas ferramentas
através do AVA que normalmente já é utilizado.
A primeira versão da LTI foi lançada em 2006 e em maio de 2010 a versão foi
chamada LTI básica. Ela fornecia apenas um mecanismo de lançar uma URL dentro de um
Capítulo 2. Fundamentação Teórica 31
AVA (IMS, 2014). Apesar de simples, a primeira versão serviu como base para a evolução
e disponibilização de novas versões.
A versão 1.1 da LTI veio composta de alterações na especificação para o forneci-
mento de resultados no processo conhecido como loop-back communication, que ocorre
ocasionalmente quando um serviço externo envia de volta para o TC informações como
status de término de atividades, nota de alguma avaliação realizada, etc (JURADO;
REDONDO, 2014).
Após o lançamento da versão 1.1, veio a 2.0, que tem regras um pouco diferentes
para aumentar a sua extensibilidade e a troca de outras mensagens com o(s) consumidor(es)
de serviços, carregando consigo a importante capacidade de ser compatível com as versões
anteriores.
2.3.2.1 Processo de comunicação entre TC e TP
O processo de comunicação entre o TC e TP ocorre de acordo com a Figura 7.
Figura 7 – Esquema chave de comunicação LTI 2.0 LTI.
Fonte: (IMS, 2014)
Todo o processo de autenticação e autorização é gerenciado pelo TC, que comumente
é representado pelo AVA. Boyd (2012) define autenticação e autorização, respectivamente,
como processo que verifica se um usuário é realmente quem ele diz ser e processo que
verifica se um usuário tem o direito de executar alguma ação.
Capítulo 2. Fundamentação Teórica 32
O processo de autenticação de um usuário inicia com a identificação dele. O usuário
precisa comprovar que ele é realmente quem ele afirma ser e este processo geralmente
utiliza o nome dele e a sua senha. Após este processo de autenticação, o sistema verifica
se o usuário tem a autorização para executar determinadas ações como: executar um
documento ou acessar determinado relatório.
Quando o AVA lança um link para execução de uma aplicação externa, ele deve
enviar junto dados como:
• Qual usuário está solicitando o acesso à ferramenta externa;
• O contexto onde este usuário realizou o acesso;
• Qual o papel do usuário no contexto onde partiu a solicitação no TC.
Estes dados devem ser passados de forma segura e confiável.
A especificação também define dois tipos de conexões entre o TC e o TP na
especificação 2.0:
1. Baseado em mensagens: utiliza HTTP(Hypertext Transfer Protocol) POST para
transferir os dados via navegador. Ela é disparada quando o AVA lança uma ferra-
menta externa;
2. Baseado em serviços: exige uma conexão direta entre as partes, um processo de
requisição e respostas baseados no protocolo HTTP seguindo os padrões de serviço
web e formatando os dados das mensagens utilizando a especificação de formatação
de objetos JavaScript Object Notation - Linking Data (JSON-LD) 6
A Figura 8 mostra um objeto JSON-LD.
Apesar de referenciar URLs de padronização de dados, o JSON-LD tem a formatação
típica de um JavaScript Object Notation (JSON).
Tanto a especificação 1.0 quanto a 2.0 do LTI aconselham a utilização do OAuth
para realizar o processo de autenticação e login único, também conhecido como Single
Sign On (SSO).
O processo de autenticação e autorização é delegado ao TC, contudo, para realizar
este processo ele utiliza OAuth versão 1.0. A versão 2.0 é incompatível com a primeira.
OAuth é um protocolo que permite segura autorização, utilizando um método
padrão simples na web, em dispositivos móveis e aplicações web desktop (MESSINA, 2015).
6 <http://json-ld.org/>
Capítulo 2. Fundamentação Teórica 33
Figura 8 – Representação do objeto JSON na especificação JSON-LD
Fonte: http://json-ld.org/
A principal característica que diferencia o Oauth1.0 da sua versão mais nova é
que no processo de autenticação da versão 1.0 é necessária uma assinatura criptografada
para enviar requisições de verificação de identidade e autorizações de um cliente. A
grande complexidade de se lidar com assinatura criptografada e o aumento do suporte
das Application Programming Interface (APIs) 7, Secure Socket Layer (SSL), levaram ao
desenvolvimento da especificação Oauth Web Resource Authorization Profiles (WRAP),
eliminando a complexidade inerente a assinatura.
Contudo, o padrão LTI ainda funciona com a exigência de assinatura. Uma men-
sagem assinada no padrão LTI deve conter as seguintes informações: quem realiza a
solicitação, de onde vem a solicitação, o que se deseja fazer e a chave do TC.
2.3.3 Caliper Analytics
Caliper é um padrão que permite a coleta, armazenamento e transporte de dados
de aprendizado. Ele é um framework que possibilita a captura detalhada de dados através
das aplicações educacionais (WHYTE VINCE KELLEN, 2016).
Esse padrão permite a captura de interações executadas pelos estudantes utilizando
um vocabulário universal para descrever os eventos disparados durante o uso de uma
aplicação compatível. Os dados são armazenados para possibilitar pesquisas e análises,
utilizando ferramentas habilitadas para isso.
Atualmente esse padrão está na sua primeira versão estável, podendo receber
ajustes e adições de funcionalidades. Na versão atual é permitido que os dados oriundos
dos eventos disparados por seus sensores possam vir de várias aplicações diferentes para
serem consumidos em um Learning Record Store(LRS)/EventStore e outros serviços.
O LRS é um servidor capaz de processar e receber uma requisição, além de arma-
7 Conjunto de definições de rotinas e protocolos para utilização no desenvolvimento de sistemas
Capítulo 2. Fundamentação Teórica 34
zenar e posteriormente fornecer acesso aos dados de aprendizagem gravados. (ADLNET,
2016)
IMS Caliper funciona utilizando perfis de métrica padronizados e extensíveis, que
estabelecem um conjunto de etiquetas para os dados de uma atividade de aprendizagem,
possibilitando a troca das informações entre as plataformas. Os perfis de métricas são
organizados por tipos de atividades de aprendizados, por exemplo: Assessment, Reading,
Média, etc.
Os eventos e as entidades que participam de um evento são relacionados a um perfil
específico que segue o padrão JSON em conformidade com o formato JSON-LD. Quando
um evento é disparado na aplicação, ele captura as entidades e as ações realizadas como
um evento de aprendizagem através de um sensores.
Um Sensor é uma API criada sob os moldes do IMS para definir os eventos básicos
que padronizam e simplificam a coleta de dados das métricas de aprendizagem. Uma API
Sensora implementa os perfis de métrica nas seguintes linguagens de programação: Java,
Javascript, PHP, Python, .NET, Ruby. A Figura 9 mostra em alto nível o esquema de
funcionamento do Caliper.
Figura 9 – Esquema em alto nível do funcionamento do Caliper.
Fonte: (MATTSON, 20115)
O Sensor facilita a padronização da construção do objeto JSON que representa um
Capítulo 2. Fundamentação Teórica 35
evento de um perfil de métrica. Um evento possui informações dos atores, ações, objetos e
contexto onde o evento aconteceu.
2.3.4 ADL e xAPI
Assim como a IMS possui o padrão para mapeamento de ações executadas durante
o uso de uma aplicação, a Advanced Distributed Learning (ADL) também possui o seu
padrão.
ADL é uma organização estabelecida pelo governo americano para conduzir pesquisa,
desenvolvimento, teste e avaliação para melhorar o processo de aprendizagem distribuída
nos Estados Unidos (ADLNET.GOV, 2015).
O padrão para a captura das ações é conhecido como Exprerience API (xAPI). Esse
padrão também é representado no formato JSON puro para representação das experiências
que serão gravadas em um LRS. A especificação da ADL fornece instruções para construção
de LRSs. A IMS não possui especificação para isso.
Normalmente as experiências registradas são experiências de aprendizado, mas a
API pode declarar outros tipos de experiências para registro de ações em jogos, mapeamento
de ações em pacotes de aplicações educacionais como o SCORM, simuladores etc.
O processo de registro de experiências está baseado em três peças chave: ator,
verbo e atividade. A interação ocorre quando um ator realiza uma ação em uma atividade
específica, logo depois, a ação é compilada no formato JSON.
O exemplo de uma experiência no formato JSON é exibido no trecho de código da
lista 2.1.
2.3.5 Caliper e xAPI
Os dois padrões apresentados anteriormente têm o papel fundamental de tornar
mais fácil o entendimento das experiências dos usuários em aplicações. Isso ocorre por meio
de registros de resultados gravados em uma ampla variedade de contextos, plataformas e
tecnologias.
É notória as semelhanças entre as duas especificações reconhecidas pela ADL e IMS.
Devido a elas, as duas organizações iniciaram investigações para saber se o alinhamento
entre as duas seria possível. Segundo a postagem publicada por Haag (2016) no site da
ADL, os principais resultados esperados são:
• Acordo entre as comunidades de quando usar a Caliper ou xAPI;
• Determinar se é tecnicamente possível harmonizar ambas as especificações em um
formato de dados, preservando a segurança, privacidade e mecanismos de transporte;
Capítulo 2. Fundamentação Teórica 36
Listing 2.1 – Objeto JSON xAPI
{
" verb " : {
" id " : " http :// ad lnet . gov/ expapi / verbs / i n t e r a c t ed " ,
" d i sp l ay " : {
" en−US" : " c l i c k e d "
}
} ,
" v e r s i on " : " 1 . 0 . 1 " ,
" timestamp " : " 2016−12−30T22 :52 :45 .160502+00 :00 " ,
" ob j e c t " : {
" id " : " http :// ad lnet . g ithub . i o /xapi−statement−viewer " ,
" objectType " : " Ac t i v i ty "
} ,
" ac to r " : {
"mbox" : " mai l to : eu0zj@adlnet . g ithub . i o " ,
"name" : " eu0z j " ,
" objectType " : " Agent "
} ,
" s t o r ed " : " 2016−12−30T22 :52 :45 .160502+00 :00 " ,
" author i ty " : {
"mbox" : " mai l to : tom . c r e i gh ton . ctr@adlnet . gov " ,
"name" : " tom" ,
" objectType " : " Agent "
} ,
" context " : {
" c o n t e x tAc t i v i t i e s " : {
" parent " : [
{
" id " : " http :// ad lnet . g ithub . i o/#xapi " ,
" objectType " : " Ac t i v i ty "
}
]
}
} ,
" id " : " 8c4b0732−a046−44b7−ad4d−b824948a2ba4 "
}
Capítulo 2. Fundamentação Teórica 37
• Identificar as diferenças e semelhanças entre as duas e determinar se o alinhamento
é possível;
• Escrever terminologias semelhantes em uma especificação.
É importante saber que as duas organizações estão trabalhando em conjunto para
tornar as tecnologias compatíveis, isso gera a expectativa de união das funcionalidades
existentes nas duas. O Caliper possui uma estrutura de funcionalidades mais restrita em
relação a xAPI. Apesar disso, as principais características que levaram a adoção do Caliper
na arquitetura deste trabalho foram:
• A existência de sensores em diversas linguagens;
• Ela possui suas ações bem definidas e separadas por perfis de métricas;
• Estende o padrão LTI, fornecendo detalhamento das ações executadas pelos estudan-
tes;
• Está restrito à criação de métricas quantitativas de aprendizagem.
2.4 Trabalhos relacionados
O desenvolvimento de aplicações que possuem compatibilidade com outras fer-
ramentas vem se tornando cada vez mais utilizado e avançado na área de Educação a
Distância (EaD), pois o uso de especificações em aplicações educacionais permite o reapro-
veitamento de instrumentos pedagógicos, além de fornecer condições de comunicação com
outros softwares compatíveis e habilitar o compartilhamento detalhado de informações
entre eles. Outro fator relevante nesse panorama é que as instituições de ensino tendem a se
comunicar entre si para agregar novas funcionalidades a seus ambientes e para melhorar a
experiência de seus usuários. Nesta seção, serão apresentados alguns trabalhos relacionados
a este.
2.4.1 Cocriação e avaliação de recursos educacionais abertos e acessíveis
O "Cocreation and Evaluation of Inclusive and Accessible Open Educational Re-
sources: A Mapping Toward the IMS Caliper", publicado por Avila et al. (2016), utilizou as
especificações LTI e Caliper para conseguir a comunicação entre os recursos educacionais
desenvolvidos por professores e o LMS ATutor 8 Os recursos foram materiais digitais usados
para o ensino, aprendizado e pesquisa disponibilizados em um domínio público. Ele teve
como seu objetivo geral colher dados de participação de alunos nos recursos utilizando o
8 LMS de código conte aberto disponível no link: http://www.atutor.ca/
Capítulo 2. Fundamentação Teórica 38
framework Caliper guardando os dados para futura análise educacional, além da produção
de um módulo para análise inicial e exibição de gráficos no ATutor.
Apesar de o autor ter afirmado que houve a utilização da arquitetura proposta pela
IMS, ele não deixa muito claro qual recurso externo realmente teve os eventos registrados
ou a forma como os dados gerados por eles foram armazenados. Durante a busca realizada,
não foi possível encontrar o módulo "Accessibility dashboard" do ATutor produzido, o que
impossibilitou a análise detalhada da sua implementação.
Levando em consideração que o AVA utilizado foi diferente do usado na SEDIS,
existe uma grande dificuldade de implantação da solução. Contudo, é possível observar
pontos de semelhança no modelo conceitual, como o processador de dados analíticos que se
situa no próprio AVA e a existência de um ponto central de acesso às ferramentas externas,
que no caso deste trabalho será o Moodle e não o ATutor.
2.4.2 Uso do LTI para aumentar o aprendizado distribuído
Outro trabalho que tem o LMS como ponto central de acesso em seu modelo
conceitual (Figura 10) é o "Learning tools interoperability for enhancing a distributed
personal learning environment with support for programming assignments" publicado por
Jurado e Redondo (2014), no qual é apresentada a ideia de aumentar a quantidade de
recursos educacionais para suprir as necessidades de aprendizado e, para isso, foi utilizada a
especificação LTI, com o objetivo de integrar as aplicações de aprendizagem ricas fornecidas
por ferramentas externas.
Figura 10 – Comunicação bidimensional e troca de informação entre o COALA e o LMS
Fonte: (JURADO; REDONDO, 2014)
O modelo mostra o processo de acesso à ferramenta externa COALA 9, utilizando
9 Ferramenta baseada no eclipse para correção de códigos disponível no link:
Capítulo 2. Fundamentação Teórica 39
LTI e o TupleSpace10 para registrar e fornecer os resultados que posteriormente são
disponibilizados em uma API REST. Nesse modelo, o Moodle necessitou de um plugin
para receber as notas totais das avaliações e para registrá-las no gradebook utilizando a
API fornecida pelo TupleSpace Connector cliente do servidor TupleSpace. TupleSpace não
é uma implementação muito utilizada atualmente, portanto a sua implementação se torna
complicada, já que é difícil encontrar materiais e bibliotecas atualizadas que auxiliem no
processo de desenvolvimento.
2.4.3 Uso do padrão LTI para integração com o AVA
O trabalho “Using the Leaning Tools Interoperability Framework for LMS In-
tegration for LMS Integration in Service Oriented Architetures”11, de Leal e Queirós
(2011), tem o objetivo de propor uma arquitetura de troca de informações entre um LMS
e as ferramentas externas de avaliação ou os repositórios de objetos de aprendizagem,
considerando o ambiente como um local natural para aplicar exercícios para os alunos.
Os autores propõem uma arquitetura de integração utilizando o IMS LTI v1.0,
descrito como LTI básico responsável por fornecer uma comunicação unidirecional, ou
seja, ela apenas fornece um link seguro para o lançamento de uma atividade externa.
A arquitetura proposta está focada em um único recurso que implementa um ambiente
de resolução de exercícios de programação. Para isso, eles dividem tudo em quatro
componentes: repositório de objetos; motor de avaliação que avalia as tentativas dos alunos;
ambiente de resolução de exercícios de programação; e o LMS que recebe os dados através
do ambiente de resolução dos exercícios.
Os LMSs utilizados para validar a proposta no trabalho de Leal e Queirós (2011)
foram o Moodle e o Sakai. Contudo a sua implementação no Moodle não utilizou a
ferramenta de atividades externas nativas do ambiente, então eles chegaram a conclusão
que seria impossível implementar os resultados das avaliações dos estudantes de volta no
livro de notas do Moodle, pois a versão utilizada do LTI não suportava o processo de
comunicação completo.
2.4.4 Integração de Ambiente Virtual de Aprendizagem com Repositório
Digital
A tese de doutorado “Integração de Ambiente Virtual de Aprendizagem com
Repositório Digital” de Rodrigues (2012) descreve a importância de se utilizar um ROA e
https://marketplace.eclipse.org/content/coala-eclipse-plug
10 Funciona como memória centralizada onde as informações relevantes são escritas e lidas.
Link:http://wiki.c2.com/?TupleSpace
11 Os detalhes deste trabalho estão disponível no Repositório Científico do Instituto Politécnico do Porto
(RECIPP). Link: http://recipp.ipp.pt/
Capítulo 2. Fundamentação Teórica 40
suas interações com um AVA. A autora investigou estratégias para integrar um ROA a um
LMS, evitando a restrição do acesso dos alunos aos recursos disponibilizados pelo docente
no Moodle, proporcionando um fluxo de busca por objetos de aprendizagem que segue os
conceitos da avaliação formativa, no qual o próprio aluno busca seu próprio conhecimento.
Para isso, ela propôs um modelo baseado em serviços web de integração entre o
Moodle e o ROA DSpace, inserindo a ferramenta nativa de buscas e edição do LMS à
funcionalidade de pesquisa e incorporação dos objetos pesquisados no ROA ao LMS. Não
foi utilizado um padrão como o LTI para lançamento de uma aplicação externa, pois
as aplicações presentes no ROA necessitavam de uma importação no Moodle para que
pudessem funcionar.
A ferramenta de pesquisa inserida no Moodle para fazer buscas no ROA é um recurso
interessante para ser utilizado com o TP habilitando buscas das aplicações educacionais
disponíveis na SEDIS, portanto, ela faz parte do modelo conceitual deste trabalho.
A Tabela 3 apresenta a visão comparativa dos trabalhos relacionados. Nessa tabela
é possível observar que em alguns trabalhos não foi possível implementar o registro de
notas utilizando o método nativo da especificação LTI.
Tabela 3 – Tabela comparativa dos trabalhos relacionados
AVA Utilizado Padrões Suportados Necessidadede download Registra nota
Implementação
LTI para cada APP
(AVILA et al., 2016) Atutor LTI, Caliper NÃO Nativo SIM
(JURADO; REDONDO, 2014) Moodle LTI, TupleSpaces NÃO Não nativo LTI SIM
(LEAL; QUEIRÓS, 2011) Moodle/Sakai LTI NÃO Não nativo LTI SIM
(RODRIGUES, 2012) Moodle SCORM SIM Sim —–
41
3 Biblioteca Digital Integrada (BDI)
3.1 Análise de domínio do problema
Esta seção tem o objetivo de elucidar os requisitos identificados através do ques-
tionário realizado com os professores e da entrevista realizada com a Coordenação dos
Materiais Interativos da SEDIS.
Por meio das necessidades observadas foi possível capturar os requisitos para
o desenvolvimento do software e do modelo conceitual estendido. Para documentar os
requisitos funcionais utilizaremos o diagrama de caso de uso dividido em três cenários.
Segundo Tonsig (2008) "Os cenários são situações de uso informal para a validação dos
requisitos do sistema com relação ao caso de uso em particular". A criação de cenários
também ajuda no entendimento do domínio do problema e são descritos nas Tabelas 4, 5
e 6.
Tabela 4 – Primeiro cenário
Cena 1 Professor consulta os aplicativos disponíveis
Professor Professor realiza o login na Biblioteca Digital Integrada (BDI)
Professor Acessa os aplicativos interativos disponíveis
Professor Pega o link de lançamento da aplicação para cadastrar em seucurso do Moodle
Professor Acessa seus cursos no Moodle
Professor Cria uma nova atividade externa no seu curso e insere o linkda aplicação que está na Biblioteca Digital.
Tabela 5 – Segundo cenário
Cena 2 Aluno acessa o seu ambiente virtual de aprendizagem
Aluno Acessa o Moodle e realiza o login
Aluno Acessa seus cursos e então acessa a atividade externa cadastradapelo professor no Moodle.
Aluno Realiza a atividade externa cadastrada previamente peloprofessor. Esta atividade será aberta pela BDI.
BDI A atividade, através da biblioteca, envia a nota da interaçãodo aluno para o Moodle.
Moodle Moodle registra a nota do aluno no livro de nota do curso,para a atividade externa acessada pelo aluno.
Capítulo 3. Biblioteca Digital Integrada (BDI) 42
Tabela 6 – Terceiro cenário: O professor solicita a equipe de materiais interativos uma
nova aplicação
Cena 3 Desenvolvedor adapta as suas aplicações interativas
Desenvolvedor Cadastra os consumidores de aplicações na BDI. O Moodleé um consumidor de aplicação.
Desenvolvedor Desenvolve a aplicação
Desenvolvedor Adapta suas aplicações para que elas consigam se comunicarcom a BDI.
Desenvolvedor Cadastra a aplicação na BDI
BDI
Ajusta a aplicação para que ela consiga se comunicar com
ela e com o Moodle. Fornece um portal para acesso as apli-
cações.
Moodle Moodle registra a nota do aluno no livro de nota do curso,para a atividade externa acessada pelo aluno.
Os cenários são representados pelo diagrama de caso de uso da Figura 11.
Capítulo 3. Biblioteca Digital Integrada (BDI) 43
Figura 11 – Cenários representados como diagrama de caso de uso
Os casos de uso são detalhados nas seções seguintes, assim como é apresentada a
proposta de solução para atender aos requisitos analisados.
3.2 Materiais e Métodos
O desenvolvimento da Biblioteca Digital foi realizado em conjunto com o AVA
Moodle, onde o primeiro funcionou como um servidor de aplicações e o segundo como
um consumidor. Foi necessário a utilização das seguintes tecnologias livres como base:
Capítulo 3. Biblioteca Digital Integrada (BDI) 44
PHP1(Juntamente com o framework Laravel 2), banco de dados livre, biblioteca javascript
jQuery3.
As próximas seções mostram quais as metodologias utilizadas para atingir os
objetivos do trabalho.
3.2.1 Sistematização da Biblioteca Virtual
A Biblioteca Virtual atual funciona como um sumário de links estáticos. O processo
de programação dela foi feito utilizando a linguagem de programação PHP, que é uma
linguagem livre utilizada na SEDIS.
Como a biblioteca engloba os objetos e eles precisam se comunicar com os ambientes
virtuais de aprendizagem, foi preciso implementar na sua base um padrão para que ocorresse
essa comunicação. O padrão escolhido foi o LTI - padrão mundialmente difundido que
facilita a interoperabilidade com mais ferramentas existentes no mercado.
Para que a implementação do padrão fosse possível, realizamos pesquisas no GitHub
com o objetivo de encontrar implementações do padrão LTI utilizando PHP para então
fazer as adaptações necessárias.
3.2.1.1 Utilização do framework Laravel
A adoção do framework teve o objetivo de usufruir de recursos modernos e seguros
pré-instalados, além de ter a garantia da implementação de padrões de projeto importantes
para acelerar a programação e melhorar a organização do código.
O uso do Laravel permite rápida instalação do sistema, permitindo que outros
desenvolvedores consigam replicar a solução facilmente, uma vez que as tabelas são criadas
automaticamente em vários Sistemas Gerenciadores de Bancos de Dados (SGBDs) por
meio das "Migrations". Portanto, o funcionamento da Biblioteca Digital não depende de um
SGBD específico. Outro ponto que também foi muito útil para garantir a independências
de um SGBD específico foi o "Eloquent4", que é a implementação do padrão de projeto
"ActiveRecord5" para tratar cada tabela da base de dados como uma classe que faz parte
do modelo do sistema.
1 Hypertext Processor(PHP)linguagem de programação interpretada que passou que se tornou orientada
a objetos na versão cinco, lançada oficialmente em julho de 2004 (DALL’OGLIO, 2015)
2 Framework PHP gratuito que implementa o padrão de arquitetura Modelo Visão e Controlador (MVC),
disponível no link: https://laravel.com/
3 "Biblioteca JavaScript criada por John Resig e disponibilizada como software livre e aberto"(SILVA,
2008, p.25)
4 Documentação disponível no link: https://laravel.com/docs/5.3/eloquent
5 Padrão de projeto que pode ser aplicado onde o modelo de negócios se parece bastante com o modelo
de dados. Os dados de uma coluna de uma tabela são convertidos para propriedades de objetos
(DALL’OGLIO, 2015)
Capítulo 3. Biblioteca Digital Integrada (BDI) 45
O Laravel também proporcionou um controle maior na segurança e facilitou a
organização e a manutenção das requisições Hypertext Transfer Protocol(HTTP), através
das suas rotas. Isso é muito importante visto que as requisições das aplicações na Biblioteca
Digital são feitas via HTTP, que são representadas pelas rotas.
3.2.2 OAs que enviam resultados para o GradeBook
Como nos OAs presentes atualmente não conseguem se comunicar com Moodle, foi
necessário desenvolver uma pequena biblioteca de funções e variáveis em javascript/jQuery
para facilitar a troca de informações entre a Biblioteca, o Moodle e as Aplicações HTML5.
Portanto, para que cada aplicação da biblioteca digital consiga enviar um resultado
obtido pelo aluno, ela deve chamar uma função da biblioteca de funções javascript. Este
funcionamento é explicado no padrão de projeto Adapter.
3.2.3 Modelo conceitual estendido
Além implementar o sistema que irá englobar as aplicações e desenvolver mecanismos
utilizados para troca de informações entre os componentes envolvidos, propomos um modelo
conceitual abrangendo o ecossistema completo que abriga novas funcionalidades que podem
ser implementadas no futuro.
3.2.4 Teste de usabilidade
Para validar o protótipo foi realizado um teste de usabilidade. O teste de usabilidade
compreende as atividades referentes ao cenário 1 da Tabela 4, capítulo 3. Este cenário
envolve dois sistemas, o Moodle e a Biblioteca Digital Integrada (BDI), que são as partes
fundamentais da arquitetura conceitual proposta. Nesta etapa os usuários foram convidados
a executar uma lista de tarefas direcionadas aos dois sistemas para avaliar a forma como
eles são integrados.
A avaliação da usabilidade foi realizada de forma colaborativa e para a avaliação
da satisfação foi utilizado um questionário padronizado chamado System Usability Scale
(SUS) que tem seus critérios de confiabilidade validados.
3.3 Solução proposta
A solução proposta é o sistema chamado de Biblioteca Digital Integrada que possui
os seguintes propósitos:
• Servir como um repositório inteligente de aplicações;
Capítulo 3. Biblioteca Digital Integrada (BDI) 46
• Proporcionar a comunicação das aplicações hospedadas na BDI com várias instâncias
de AVAs;
• Ser uma peça-chave na coleta, armazenamento e distribuição de dados colhidos
durante a utilização das aplicações da BDI.
Estes objetivos são ilustrados por meio do seguinte modelo conceitual na Figura
12. Ele apresenta um modelo conceitual completo do que foi desenvolvido neste trabalho e
o que ainda pode ser implementado no futuro.
Figura 12 – Modelo conceitual.
Cada componente do modelo conceitual estendido está numerado para facilitar a
sua identificação no texto. Eles estão relacionados às seguintes descrições:
1. Moodle - Consumidor das aplicações fornecidas pela biblioteca ou TC;
Capítulo 3. Biblioteca Digital Integrada (BDI) 47
2. Biblioteca Digital Integrada que funciona como um fornecedor ou TP;
3. Aplicações inseridas na biblioteca e API para acesso às funções externas da biblioteca;
4. Conjunto de funções acessadas externamente;
5. Banco de dados para armazenar dados e notas dos usuários;
6. Banco de dados não relacional para armazenar os documentos em JSON;
7. Plugins Moodle(7,8) - são plugins extras que podem ser desenvolvidos para adicionar
funcionalidades ao Moodle e para tratar os dados armazenados pela biblioteca
gerando informações.
As seções seguintes dirão respeito a cada componente do modelo conceitual estendido
e ao detalhamento dos casos de uso. O modelo é considerado estendido pois apenas os itens
presentes na área demarcada foram implementados, os outros componentes são extensões
que adicionam novas funcionalidades.
3.4 Moodle e BDI
O primeiro evento de comunicação entre os dois sistemas tem início no Moodle. O
aluno entra no Moodle e acessa uma disciplina para realizar suas atividades e, ao clicar
em atividade externa ele é direcionado para uma aplicação que está hospedada na BDI.
Este processo de comunicação inicial segue padrão aberto LTI.
Contudo, para que a inicialização de uma aplicação da BDI dê certo, é necessário
que um sistema saiba da existência do outro, portanto, os casos de usos da Figura 11:
cadastrar consumidor, cadastrar aplicação, disponibilizar aplicação, e criar uma atividade
externa são fundamentais.
O Moodle, representado pelo item 1 do modelo conceitual, Figura 12, é o con-
sumidor/TC de aplicações e deve ser cadastrado no fornecedor das aplicações, que é
representado pelo item 2. A tela de cadastro de consumidores é exibida na Figura 13. Cada
consumidor possui um identificador que deve ser único e uma chave compartilhada que é
gerada automaticamente pela BDI. Esta chave compartilhada deve ser colocada no campo
"segredo do consumidor"da Figura 14.
Na BDI também são cadastradas as aplicações pelo formulário que permite o upload
como um arquivo compactado. O arquivo é descompactado e guardado e a aplicação é
disponibilizada por uma view da BDI. A tela de cadastro de novas aplicações está no
apêndice E.
Quando o consumidor é cadastrado no fornecedor/TP, o Moodle pode acessá-lo
através da ferramenta externa que também é compatível com o padrão LTI. Parte da
Capítulo 3. Biblioteca Digital Integrada (BDI) 48
Figura 13 – Parte da tela de cadastro de consumidores na BDI.
tela de cadastro de uma atividade externa no Moodle é exibida na Figura 14. Após esse
processo de reconhecimento e cadastro de atividade que o aluno pode acessar a aplicação
da BDI. É possível perceber na Figura 14 o campo "Parâmetros customizados", ele deve ser
preenchido com o nome da aplicação do BDI que será iniciada. Isto permite que um único
fornecedor(BDI) compatível com LTI consiga abrir várias aplicações também compatíveis,
logo todas as aplicações serão iniciadas utilizando uma mesma URL de lançamento
disponibilizada na biblioteca. Também é possível informar um ícone personalizado na
atividade criada no consumido através do campo "URL do ícone".
Uma atividade criada com a ferramenta externa do consumidor permite a confi-
guração de notas, as quais são registrada no "GradeBook" do Moodle. A BDI é capaz de
enviar as notas das interações dos alunos com as aplicações como retorno.
Capítulo 3. Biblioteca Digital Integrada (BDI) 49
Figura 14 – Parte da tela de cadastro de uma ferramenta externa no Moodle.
O processo de inicialização das aplicações é descrito na subseção abaixo.
3.4.1 Autenticação e inicialização de aplicações da BDI
Quando um aluno ou professor acessa uma atividade externa, é realizada uma
requisição a BDI passando variáveis através do método POST. As principais informações
que a requisição carrega são as seguintes:
• Identificador do usuário no Moodle - user_id;
• Papel que ele possui no Moodle - roles;
• Identificador da atividade no Moodle - resource_link_id;
• Dados no formato JSON para registro de notas no GradeBook - lis_result_sourcedid;
• Nome da aplicação que deve ser inicializada - custom_app;
• Nome completo do usuário - lis_person_name_full;
• Chave única para autorização - oauth_consumer_key;
• Identificado do curso no Moodle - context_id.
Capítulo 3. Biblioteca Digital Integrada (BDI) 50
Ao receber os dados da requisição, a BDI realiza a autorização do usuário e
disponibiliza a view contendo a aplicação que será exibida de acordo com a configuração
que o professor fez no campo "Lançamento do Container" da Figura 14. Este processo de
troca de informação compreende os passos cronológicos de execução dos seguintes casos de
uso: disponibilizar aplicação, acessar aplicação, enviar nota para o Moodle e inserir nota
no GradeBook. Estes passos são expressos no diagrama de sequência da Figura 15.
Figura 15 – Diagrama de sequência com a ordem cronológica do processo de inicialização
de uma aplicação.
Para realizar a implementação do padrão LTI na BDI, utilizamos como base a
implementação do padrão em PHP desenvolvida pela IMS Global que está disponível
no GitHub. Contudo, esta implementação não estava seguindo os moldes do Framework
Laravel, e foi necessário reescrever seu código seguindo padrão arquitetural MVC. A
reescrita deixou a utilização e manutenção do código mais fáceis, além de tornar as
consultas aos dados mais independentes de fabricantes de banco de dados.
Para facilitar o entendimento da utilização do padrão MVC utilizamos o diagrama
de classe de análise, na Figura 16, utilizando estereótipos para mostrar o que acontece
quando o caso de uso "acessar aplicação"é executado.
Capítulo 3. Biblioteca Digital Integrada (BDI) 51
Figura 16 – Diagrama de classes com estereótipos.
A Figura 16 mostra que ao receber uma requisição a BDI aciona o controlador
"Launcher" chamando a função "index". O elemento "Launcher@index" representa um
Controller, Launcher é a classe controladora e "index"é a função chamada. A função,
por sua vez, acessa a entidade "LtiApp"responsável pela regra de negócio das aplicações
cadastradas recebendo uma resposta logo em seguida. Quando uma resposta é dada pela
entidade, o controlador direciona para a tela que representa a aplicação solicitada ou para
um tela de erro. Todas as classes que representam entidades herdam características da
classe "Model"fornecida pelo Framework Laravel.
3.5 Comunicação entre as aplicações e a BDI
O padrão LTI para o fornecedor foi idealizado para funcionar com uma implemen-
tação por sistema, ou seja, cada um tem na sua base o padrão implementado. Porém,
a necessidade principal analisada foi a de disponibilizar várias aplicações em HTML5
por meio da BDI. Contudo, para fazer isso, seria necessário implementar o padrão LTI
para cada uma delas, o que seria bastante trabalhoso. Dessa forma, a solução para isso
foi adaptar, de forma facilitada, as aplicações produzidas pela equipe de Materiais, para
Capítulo 3. Biblioteca Digital Integrada (BDI) 52
que elas pudessem se comunicar com a BDI que já possui o padrão implementado. As
informações trocadas entre a BDI e suas aplicações são posteriormente enviadas para o
Moodle, neste caso, as notas dos alunos.
No caso de uso "desenvolver e adaptar aplicativos",a atividade de desenvolvimento
já existe atualmente, mas a adaptação é a parte nova. As alterações que o desenvolvedor
precisa fazer em sua aplicação consiste em duas atividades:
1. Recebimento de dados da BDI;
2. Enviar dados para a BDI;
O processo de recebimento dos dados da biblioteca ocorre com a adição do arquivo
"player_vars.js". Este arquivo carrega dados como: nome do usuário, identificador do
recurso do Moodle, identificador da aplicação e se o usuário tem permissão de edição no
Moodle ou se ele é um aluno. Essas informações são importantes para que o desenvolvedor
consiga personalizar sua aplicação.
O processo de envio de dados para a BDI funciona com a adição do arquivo
javascript "player_request" que deve ser carregado após o carregamento do jQuery, pois
são feitas chamadas aos recursos dele. O "player_request" possui a função "sendGradeBook"
que envia os dados para a API da BDI que é responsável pelo envio da nota do aluno
para o GradeBook do Moodle. A função da API javascript "sendGradeBook" faz uma
chamada ao serviço da BDI, representada na Figura 12 pelo item 4. Atualmente existem
2 serviços: (1)"/gradebook/update" que realiza o envio dos resultados para o Moodle
utilizando utilizando LTI; (2)"/playerapp/getapps" que lista as aplicações disponíveis na
BDI.
Adicionalmente, a função também registra o desempenho na sua base de dados
própria.
O arquivo que possui a função de envio de dados para a BDI pode ser estendido
para adicionar novas funcionalidades.
Para que o desenvolvedor consiga enviar a nota do aluno utilizando a função
"sendGradeBook", é necessário passar os parâmetros da função, porém todos eles já são
pré-carregados quando o arquivo "player_vars" é carregado, restando apenas o parâmetro
"outcomeValue", que é a nota final do aluno, ou seja, o desenvolvedor terá que atribuir
valor a eventos da aplicação e passar para função apenas o resultado final obtido pelo
aluno.
Realizamos a adaptação com a aplicação "Atividade de Fonética". Nessa atividade,
baseada em drag and drop, programamos a nota final para 100% se o aluno conseguir
relacionar todos os nomes com as partes do corpo humano corretamente e não atribuímos
Capítulo 3. Biblioteca Digital Integrada (BDI) 53
nota alguma se ele não concluir esta atividade. Fica claro que o desenvolvedor está livre
para implementar a valoração dos eventos na sua aplicação. A aplicação sobre fonética é
exibida na Figura 17
Figura 17 – Aplicação adaptada para trocar de dados.
54
4 Resultados
O desenvolvimento da proposta de uma arquitetura conceitual, com o objetivo de
resolver a falta de comunicação entre OAs da biblioteca digital com o AVA da SEDIS,
partiu inicialmente da percepção do problema. Logo após isso, foi realizado um estudo
exploratório com o objetivo de analisar as reais necessidades existentes e entender como os
professores faziam para utilizar os recursos fornecidos pela biblioteca (apêndice A). Neste
estudo, além do uso do questionário, também foi realizada uma entrevista qualitativa com
a coordenação de produção dos OAs interativos (apêndice C).
Após a utilização desses dois instrumentos, questionário qualitativo/quantitativo e
entrevista, a fim de fazer a analise dos requisitos, o protótipo funcional foi desenvolvido e
testado utilizando ferramentas para medição de sua usabilidade.
Este capítulo tem a finalidade de descrever os resultados obtidos no decorrer do
desenvolvimento deste trabalho. As entregas do projeto são: (1) relatos obtidos do estudo
exploratório; (2) arquitetura conceitual completa para resolução do problema; (3) protótipo
funcional implementando as partes principais da arquitetura; (4) primeiro ciclo de teste
de usabilidade do protótipo. O item 3 das entregas foi detalhado no capítulo 3 e inclui a
biblioteca LTI da IMS reformulada para funcionar no framework MVC Laravel.
4.1 Estudo exploratório
4.1.1 Questionário
Para realizar a coleta de dados inicial, foi utilizado o questionário eletrônico do
Google. O critério de seleção da população participante seguiu os seguintes critérios:
• Professores editores de conteúdo vinculados à SEDIS;
• Ter ministrado alguma disciplina no Moodle Acadêmico da SEDIS durante o semestre
de 2016.1.
Apesar de existirem mais papéis que possuem capacidade de edição de conteúdo no
AVA, o perfil de professor foi escolhido, pois a proposta de fabricação dos OAs interativos
é realizado por ele.
As perguntas do questionário disponíveis no apêndice A foram elaboradas para:
avaliar o conhecimento dos professores a respeito da biblioteca digital, se já haviam
utilizado, como foi a experiência da utilização, se houve coleta de dados para uma posterior
Capítulo 4. Resultados 55
utilização na composição das notas dos alunos no Moodle e se eles consideravam importante
a existência de uma ferramenta que desse um retorno mais detalhado da participação dos
alunos.
4.1.1.1 Análise de dados do questionário
A população selecionada foi de 117 professores e obtivemos o total de 28 respostas.
A Figura 18 faz uma análise comparativa entre a necessidade de utilização de OAs
diferentes dos disponíveis no AVA e o número de professores que possuíam o conhecimento
da existência do ROA. É possível perceber nesta imagem que, apesar do número de
professores que não tiveram a necessidade de adicionar um recurso diferente a seu curso
ser igual a 18 ou 64% deles, contudo, o número dos que não tinham o conhecimento
da existência da biblioteca também foi muito alto, o equivalente a 42,8%, o que pode
sugerir que eles podem não ter sentido a necessidade de usar os OAS por não terem sido
apresentados às opções de recursos extras disponíveis na biblioteca.
Figura 18 – Comparativo da necessidade de utilização de OAs diferentes X conhecimento
da existência do ROA, N=28.
Na questão cinco da pesquisa, "Você sabia que a SEDIS possui uma Biblioteca
Digital com repositório de Objetos de Aprendizagem?", das 28 respostas, 12 não sabiam
da existência de uma Biblioteca. Dos 10 que tiveram necessidade de inserir algum objeto
externo ao AVA, seis não sabiam da existência da Biblioteca. Os gráficos gerados por cada
pergunta está disponível no anexo A.
Capítulo 4. Resultados 56
Ao consultar as respostas presentes no anexo A , é perceptível que a maioria
respondeu ter a necessidade de adicionar um objeto da biblioteca não conseguiu extrair
nenhum dado de interação, como por exemplo, o registro de acesso ou desempenho do
aluno. Além disso, 17 professores responderam que ao tentar utilizar os recursos no interior
do AVA, não conseguiram coletar dados de interação dos alunos. Isso fica ainda mais
claro quando observamos as respostas das perguntas qualitativas três e quatro. Na três,
quando perguntamos qual foi o procedimento utilizado para inserir o OA nas atividades
dos alunos no AVA, recebemos respostas como esta: "Enviei o endereço do link e como
senti dificuldades de operacionalizar, enviei mais arquivos pelo e-mail dos estudantes". A
questão quatro, consequentemente teve suas respostas negativas, a maioria respondeu que
não houve coleta de dados de interação dos alunos.
Na pergunta seis "Você chegou a utilizar os Objetos de Aprendizagem da Biblioteca
Digital da SEDIS como ferramentas de ensino?", foi verificada uma discrepância. Dos seis
participantes que utilizaram objetos da biblioteca, quatro afirmaram anteriormente que
não tiveram necessidade de adicionar um OA ao ambiente. Portanto, essas quatro pessoas
que afirmaram que não houve necessidade sabiam da existência da biblioteca.
Na pergunta final da pesquisa, é possível observar no gráfico da Figura 19 que 92,9%
dos participantes consideraram importante que exista um repositório de OAs integrado ao
AVA.
Figura 19 – Participantes que consideram importante que a SEDIS tenha um repositório
que seja integrado ao AVA.
É muito importante observar que todos os objetos interativos que estão hospedados
atualmente na biblioteca tiveram sua construção baseada em alguma demanda educacional,
de um professor ou de um grupo deles, e que a utilização desses objetos deve ser facilitada
e os retornos devem ser registrados, possibilitando a geração de nota de participação dos
alunos.
Capítulo 4. Resultados 57
4.1.2 Análise da entrevista
A entrevista é uma ferramenta para investigação qualitativa, utilizada para in-
vestigar aspectos não mensuráveis em termos de quantidade e com ênfase na qualidade
(DENZIN, 2008) . A entrevista foi realizada com a Coordenação de Produção de Materiais
Interativos da SEDIS em 04/04/2017, com o objetivo de conhecer o histórico de produção
do setor, dificuldades, processo de solicitação, fabricação e disponibilização de OAs intera-
tivos. Ela também foi realizada para confirmar a hipótese prévia da necessidade de OAs
interativos integrados ao AVA.
É comum que em uma investigação qualitativa surjam elementos subjetivos como:
ideias, emoções, valores e opiniões que são conduzidas de forma natural. Todos relatos
descritos pelo entrevistado dizem respeito ao processo de produção e publicação de um
recurso produzido.
A entrevista foi classificada como semi-estruturada, onde as questões derivam de
um plano prévio, um guia onde se define e registra uma ordem lógica para o entrevistador
do que se pretende obter, embora, durante a interação seja dada uma grande liberdade de
resposta ao entrevistado (AMADO, 2014). A entrevista foi gravada em áudio e transcrita
no apêndice C. A gravação foi autorizada pelo entrevistado.
A entrevista foi guiada por cinco perguntas abertas e ordenadas, apoiadas nos
objetivos e nas hipóteses da pesquisa:
1. Atualmente como são feitas solicitações de produção dos materiais interativos? Qual
o procedimento?
2. Como é feita a solicitação e entrega dos materiais produzidos para o solicitante?
3. Antigamente vocês produziam materiais utilizando o flash. Qual tecnologia vocês
estão utilizando atualmente?
4. Existe algum procedimento padrão para que os professores e tutores possam utilizar
o OAs nos AVAs?
5. Existe alguma forma de registro de utilização desses OAs e registro de notas de
participação dos alunos? Você considera isso um problema para que os OAs sejam
mais utilizados?
Na primeira pergunta, o entrevistado fez um histórico do surgimento do setor até
os dias atuais. Tudo começou com a produção de materiais impressos, os quais a SEDIS
mantinha uma tradição. Há 10 anos a realidade erá bem diferente, a qualidade da internet
não permitia ao aluno o acesso ao meio digital da forma que é hoje. Começou-se a pensar
Capítulo 4. Resultados 58
em produção de materiais interativos para a web, após editais de projetos de TIC, a partir
de então o setor se constituiu.
Quando um professor tem uma ideia de material interativo, ele entra em contato
com o setor específico para fazer uma reunião. Nesse encontro são acertados detalhes de
como esse material será desenvolvido, se será um jogo, HTML interativo ou até mesmo uma
disciplina inteira personalizada. O entrevistado citou o caso de uma disciplina optativa
ministrada completamente com um único OA interativo no curso de geografia:
"Esse material virou uma disciplina optativa do curso de geografia a distân-
cia. Ela está toda contida ali, desde apresentação, passando pelos objetivos,
atividade, resumo, então tem toda estrutura didática para que aquilo seja uma
disciplina inteira."
Os materiais produzidos atualmente não estão mais utilizando o Flash. Independente
da ferramenta utilizada, as aplicações são compiladas para HTML5. O entrevistado afirmou
que não existe nenhum procedimento específico para que os professores consigam incorporar
estes materiais nos AVAs "Não, a gente nunca inseriu dentro do Moodle não". Isto abre
brechas para que estes conteúdos sejam transmitidos para os alunos de forma errada e sem
controle algum, como também traz à luz a necessidade de padronização da forma como
eles podem utilizar os OAs inseridos aos AVAs.
Quando o entrevistado foi perguntado se existia algum registro de notas das intera-
ções dos alunos nos OAs, ele respondeu que não existe qualquer registro de interatividade,
nem registro de notas:"Ele é um objeto desvinculado, ou um objeto isolado".
Os relatos descritos pelo entrevistado são indícios fortes de que a hipótese é verda-
deira e que existe um problema de integração dos OAs com os AVAs, o que impossibilita a
utilização correta desses recursos educacionais. O cenário para resolução deste problema é
retratado no cenário três da Tabela 6 do capítulo 3. Ele mostra o fluxo de atividades que
o setor de produção dos materiais interativos deve seguir.
4.2 Teste de usabilidade
Usabilidade tem uma definição complexa, de acordo com Salvendy (2012), não
existe um instrumento que possa fornecer uma medida absoluta da usabilidade de um
produto. Ela é algo que depende de interações entre produtos, tarefas e ambientes. Contudo,
NCITS (2001) define usabilidade como "a medida em que o produto pode ser usado por
usuários específicos para alcançar metas especificadas em um contexto específico de uso
com eficácia, eficiência e satisfação".
Capítulo 4. Resultados 59
Neste trabalho teste de usabilidade foi aplicado com usuários que possuem perfil
de edição de conteúdo no AVA da SEDIS. Os participantes selecionados representam os
usuários finais do produto. Esse grupo compreende professores, administradores do AVA e
tutores editores.
4.2.1 Abordagem da avaliação
A abordagem experimental adotada para avaliar a usabilidade da parte da arquite-
tura conceitual implementada neste trabalho seguiu os seguintes passos: (1) Teste piloto;
(2) Teste baseado em tarefas com coleta de dados; (3) Análise dos dados coletados.
Para a coleta de dados qualitativos e quantitativos foram utilizados os seguintes
instrumentos:
• Anotações de avaliação: um bloco de notas onde são descritos os problemas iden-
tificados durante a execução das tarefas, tempo de execução e performance do
usuário;
• Lista de tarefas: lista com 10 tarefas que devem ser executadas pelos participantes
testadores;
• Questionário subjetivo: questionário para avaliar a satisfação do usuário, utilizando
o questionário padronizado SUS.
Os instrumentos citados foram utilizados com o objetivo geral de medir a usabilidade.
Em NCITS (2001), a medida da usabilidade está relacionada à taxa de conclusão de
tarefas (efetividade), tempo de execução das atividades (eficiência) e à taxa de satisfação
(questionários padronizados).
A efetividade e a eficiência são medidas baseadas na performance que um usuário
teve em um determinado contexto de uso. Em Macleod et al. (1997), efetividade é definida
como a medida do quão correto e completo os objetivos são alcançados em um contexto
específico. De acordo com Lewis (2005), esta medida deve ser acima de 95%.
4.2.2 Teste de usabilidade
Para ter certeza que as tarefas propostas aos testadores poderiam ser realizadas no
protótipo, foi necessário realizar o teste piloto, checando se cada item da lista de tarefas
estava exequível, tanto em temos de hardware, quanto de software. Através do teste piloto
também foi possível descobri o intervalo de tempo médio necessário para que o testador
conclua as atividades da lista proposta. O teste piloto foi aplicado para dois usuários com
nível de experiência moderado na utilização do Moodle, onde eles obtiveram um tempo
médio de nove minutos para conclusão das tarefas. Monk et al. (1993) propõe que o tempo
Capítulo 4. Resultados 60
para execução das tarefas deve ser 50% maior que o tempo para completá-las, logo, o
tempo máximo definido para conclusão foi de treze minutos e meio.
Após o teste piloto, as sessões de testes foram conduzidas de forma individual entre
os meses de junho e julho de 2017 no protótipo adequado para execução das tarefas. As
tarefas foram divididas entre os dois sistemas: Moodle e BDI.
O ambiente foi preparado para que cada testador pudesse testar o protótipo. Foi
criado um usuário e uma disciplina para cada um deles no Moodle. Quando o testador
chegou para fazer a avaliação do protótipo, a sessão foi conduzida de uma maneira informal
e cooperativa, havendo interrupções e discussões abertas sobre o sistema, deixando sempre
claro que a avaliação visava avaliar onde o sistema pode induzi-los ao erro ou o que eles são
incapazes de fazer. Monk et al. (1993) define avaliação cooperativa como "o procedimento
para obter dados sobre problemas obtidos através da experiência de trabalho com um
produto de software, e que mudanças podem ser feitas para melhorar o produto". Para
este trabalho, a avaliação cooperativa foi aplicada na simulação de um protótipo parcial.
Para que fosse possível o acompanhamento do avaliador, foi solicitado que o testador
falasse em voz alta qual tarefa ele estava realizando. Todas as sessões de teste foram
gravadas utilizando a ferramenta Screencastify1. Também foi explicado ao testador os
propósitos gerais da sessão de teste, informando que tudo seria gravado e mantido de
forma confidencial, segundo as regras da avaliação cooperativa. Devido às configurações
corretas hardware, os testes foram realizados em uma única máquina. Isso foi importante
para garantir o desempenho igual para cada um dos voluntários.
Ao final da sessão de testes, os participantes foram convidados a responder o
questionário de satisfação. Em NCITS (2001) satisfação é considerada como a liberdade
que o usuário tem de demonstrar desconforto ou satisfação com o uso do produto. Para
realizar esta avaliação, o questionário padronizado SUS foi utilizado. O SUS é um tipo
de questionário pequeno, que não toma muito tempo dos participantes, evitando que
eles deixem de respondê-lo por completo. O SUS é uma Ferramenta confiável para medir
a usabilidade, mesmo quando aplicado a pequenas amostragens. Consiste em dez itens
de questionário (disponível no anexo B), onde o participante responde em uma escala
de 0 à 5, se concorda ou discorda totalmente de uma afirmação sobre a utilização de
uma variedade de produtos e serviços, incluindo hardware, software, dispositivos móveis,
websites e aplicações.
O SUS é uma escala Likert, considerada em Brooke et al. (1996), como uma escala
baseada em questões de escolha "forçada", onde a declaração é feita ao entrevistado e ele
indica um grau de concordância em uma escala de 5 ou 7. Para prevenir que os participantes
1 Utilizado como extensão do google chrome disponível no link:
https://chrome.google.com/webstore/detail/screencastifyscreen-vide/mmeijimgabbpbgpdklnllpncmdofk
cpn?utm_source=chromeapplauncherinfodialog
Capítulo 4. Resultados 61
deem respostas sem pensar sobre cada afirmação, elas foram elaboradas alternando entre
itens positivos e negativos. Dessa forma os participantes são obrigados a pensar se realmente
concordam ou não com cada afirmação. Além dessas características, Tullis e Stetson (2004),
em uma análise comparativa de questionários padronizados, concluiu que o SUS é o único
questionário dos estudados em seu trabalho, que todas as questões são direcionadas a
reação do usuário ao acessar o produto como um todo.
A pontuação do SUS tem uma variação que vai de 0 à 100, contudo, este cálculo
não é baseado em uma porcentagem simples, mas sim em um fórmula específica que
define que para cada item existe um intervalo pontuado de 0-4. Por exemplo: para as
afirmações 1,3,5,7 e 9, a pontuação é a posição na escala menos 1, já para os itens 2,4,6,8
e 10, é calculando diminuindo o número cinco, pelo valor escolhido na escala. No final,
esta pontuação é somada e multiplicada por 2,5 (BROOKE et al., 1996). Esse cálculo é
realizado para cada participação. Por fim, com todos os resultados de cada participante,
aplicamos a média aritmética para obter o resultado geral de satisfação. O resultado da
média aritmética é considerado satisfatório se ficar acima de 68.
4.2.3 Interpretação dos resultados
Os testes de usabilidade, preferencialmente, devem ser realizados iterativamente de
acordo com a evolução do produto. Para este trabalho, analisamos o primeiro ciclo do teste
de usabilidade. Ele foi realizado com 5 testadores voluntários, 40% do sexo masculino e 60%
feminino. Monk et al. (1993) sugere que para cada iteração exista de 1 a 5 participantes.
A variação de idade ficou no intervalo de 27 a 45 anos. As duas distribuições são exibidas
nos gráficos da Figura 20.
Figura 20 – Figura 20a. Distribuição de testadores por sexo, N=5; Figura 20b. Distribuição
de testadores por idade, N=5.
Em relação a precisão de conclusão das dez tarefas propostas, 70% delas foram
resolvidas corretamente, 20% a resolução foi parcial e 10% ocorreu falha e o testador
precisou da ajuda do avaliador para concluir, não atingindo a efetividade desejada de 95%.
Capítulo 4. Resultados 62
O tempo de conclusão das tarefas (eficiência) foi medido através dos logs gerados pelo
Moodle, gravações e anotações realizadas durante os testes. O tempo médio para realizar
as tarefas foi de 7 minutos e 40 segundos, ficando abaixo do tempo médio estimado. A
lista abaixo descreve as atividades onde ocorreu algum tipo de dificuldade, levando em
consideração os dois sistemas.
• BDI
1. Tarefa 1: Acesse a BDI através do link – playerapps.dev para selecionar o OA
que você deseja inserir como atividade avaliativa em sua disciplina no Moodle.
Realize seu cadastro para poder acessar a BDI. (Parcial);
2. Tarefa 2: Clique no OA para visualizar os seus detalhes. Copie o código de
identificação do OA clicando no botão .Este código será fundamental para que
a configuração do OA no Moodle funcione corretamente.(Parcial);
3. Tarefa 3: Abra uma nova aba do navegador para acessar o Moodle. Não é
necessário sair da BDI.
• Moodle
1. Tarefa 1:Acesse o Moodle de testes utilizando o Link - localhost/mdl_ligacoes
. Clique em acessar no canto superior direito da tela. Realize login utilizando o
usuário: [seu primeiro nome] e senha:123;
2. Tarefa 2:Entre no curso que você está matriculado(a) como professora e Ative
a edição utilizando o botão do canto superior direito da tela;
3. Tarefa 3:Crie uma atividade do tipo Ferramenta Externa;
4. Tarefa 4:Selecione a BDI no item “Tipo de ferramenta externa”;
5. Tarefa 5: Cole o código de identificação do OA (copiado do item 4 da BDI)
no campo “Parâmetros customizados”. (Falha);
6. Tarefa 6:Clique em “Salvar e voltar para o curso”;
7. Tarefa 7:Clique na atividade que você acabou de criar para visualizar o resul-
tado e aguarde que seus alunos realizem a atividade. https://sigrh.ufrn.br/sigrh/servidor/portal/servidor.jsf
A lista detalhada das atividades está disponível no apêndice D.
Na tarefa 1 realizada na BDI, ao se cadastrar, o testador não teve certeza se
preenchia o campo "Nome" com seu nome completo ou com seu nome de usuário. Esse
é um problema de fácil resolução. Na tarefa 2, o usuário não sabia se o identificador da
aplicação realmente havia sido copiado "Como eu sei se copiou?", pois o sistema não deu
nenhuma resposta após o clique no botão exibido na figura 21. Ainda nesta tarefa, um dos
Capítulo 4. Resultados 63
testadores comentou a falta de informação sobre cada aplicação: "Gostaria de visualizar
mais detalhes sobre a aplicação. Imagens de como ela realmente é.", o que demonstra que
a descrição da aplicação exibida na Figura 21 não foi suficiente para que o testador fizesse
uma escolha totalmente consciente das funcionalidades disponíveis na aplicação e de seu
design.
Figura 21 – Tela de seleção de aplicações. Descrição e botão para copiar identificador.
Na tarefa 5 executada no Moodle, todos os usuários tiveram dificuldade em encontrar
o campo para preenchê-lo com o identificador da aplicação selecionada na BDI. Isto se
caracteriza como uma falha da disposição nos itens do formulário do Moodle considerada
impeditiva. O testador não conseguia encontrar este campo de forma alguma, pois os
campos menos comuns do formulário de cadastro da ferramenta externa, ficam escondidos,
sem nenhum destaque, sendo necessário clicar em "Mostrar mais..." para que eles apareçam.
Mesmo após receber orientação do avaliador para poder concluir a tarefa, o testador não
sabia se bastava apenas colar o identificador da forma como ele se apresentava. Isto leva a
necessidade de alterar o plugin ferramenta externa para que ela liste as aplicações da BDI
disponíveis para o editor de conteúdo do Moodle.
Após a realização das tarefas os usuário responderam o questionário de satisfação
SUS. A pontuação total obtida no questionário foi de 77,5, ficando a cima de 68. O que
significa que os testadores consideraram a integração dos dois sistemas com usabilidade
satisfatória. A melhor avaliação foi de 82,5 e foi dada por três testadores como mostra o
gráfico na Figura 22.
As médias da pontuação das respostas dadas em cada uma das dez afirmações do
SUS é mostrada na Figura 23. Levando em consideração que as afirmações são intercaladas
entre negativas e positivas, a maior pontuação foi dada a primeira afirmação: "Eu acho que
Capítulo 4. Resultados 64
Figura 22 – Gráfico com a pontuação de cada testador obtida via SUS
gostaria de utilizar este sistema frequentemente". Ou seja, todos concordaram plenamente
que gostariam de utilizar a ferramenta. A afirmação negativa que teve o maior índice foi
a quarta: "Eu acho que precisaria do apoio de um suporte técnico para ser possível usar
este sistema". A pontuação alta para esta afirmação foi caracterizada pela fala de um dos
testadores que falou: "tive dificuldade, pois foi a primeira vez que estou utilizando esta
funcionalidade, a partir da segunda, tudo será bem mais rápido".
A afirmação positiva que obteve a maior pontuação pode pode ser explicada pela
reação dos testadores ao executarem a tarefa 7 no Moodle: "Clique na atividade que
você acabou de criar para visualizar o resultado e aguarde que seus alunos realizem a
atividade". Eles esboçaram uma reação muito positiva, "nossa que legal", gostando bastante
do resultado ao visualizar a sua aplicação completamente personalizada executando através
do AVA.
Capítulo 4. Resultados 65
Figura 23 – Mostra a distribuição da pontuação por afirmação do SUS
4.3 Análise comparativa dos resultados
Para concluir o texto referente aos resultados, esta seção vai traçar um comparativo
com os trabalhos relacionados da seção 2.4.
Através da análise do trabalho de Avila et al. (2016) foi possível utilizar a ideia
de colocar um módulo de análise de dados colhidos pelo Caliper no AVA. Esta ideia foi
representada na arquitetura conceitual e deve ser implementada em trabalhos futuros.
Contudo, o autor não indica como fez a comunicação do ambiente virtual com as aplicações.
Além disso, ele deu a entender que o padrão Caliper precisava ser implementado para
cada uma das aplicações desenvolvidas no trabalho. Neste trabalho, para cada aplicação
desenvolvida o desenvolvedor precisa chamar serviços que permitem a comunicação com
o AVA, e a BDI gerencia os dois pontos de partida dessa comunicação. O desenvolvedor
não precisa se preocupar com a implementação de padrões, ele simplesmente chama as
funcionalidades que precisa e utiliza os dados dos usuários fornecidos pela BDI.
No trabalho Jurado e Redondo (2014) a comunicação da aplicação com o AVA
Moodle não era possível de forma nativa, o mesmo aconteceu em Leal e Queirós (2011),
que não obteve sucesso ao registrar resultados no Moodle. Em Jurado e Redondo (2014) foi
necessário criar um serviço específico para registrar os resultados e a arquitetura produzida
no trabalho foi baseada em uma tecnologia pouco difundida atualmente, atendendo as
necessidades de uma única aplicação e regra de negócio.
Na dissertação de Rodrigues (2012) foi possível aproveitar a ideia de facilitar a
escolha de uma aplicação externa disponível em um ROA. Esta ideia está implementada no
modelo conceitual deste trabalho. Durante os testes de usabilidade foi possível concluir que
é necessário uma ferramenta de escolha das aplicações existentes na BDI. Esta ferramenta
Capítulo 4. Resultados 66
acaba com a dificuldade que os testadores voluntários encontraram ao tentar escrever o
identificador da aplicação no Moodle.
O trabalho de Rodrigues (2012) foca em aplicações que utilizam padrões de desen-
volvimento de aplicações como SCORM e IMSCP. Esses padrões seguem regras rígidas
de implementação e para utilizar as ferramentas produzidas por eles é preciso baixá-las
do ROA para poderem ser incorporadas ao AVA. Uma aplicação desenvolvida utilizando
LTI não precisa ser baixada para ser incorporada no AVA, pois ela funciona como uma
aplicação web, oferecendo a possibilidade de integração com redes sociais, recurso que
não funciona no SCORM. A arquitetura deste trabalho e a BDI fornecem recursos para
que a aplicação seja produzida deixando a equipe de desenvolvimento livre para produzir
recursos com identidade própria, assim como abre portas para o acoplamento de novas
tecnologias.
A síntese dos pontos principais dos trabalhos relacionados é exibida na Tabela 7. A
arquitetura proposta junto com a BDI, permitem que as aplicações de uma implementação
LTI para cada uma delas. O desenvolvedor irá utilizar as ferramentas fornecidas por este
modelo de acordo com suas necessidade. Não existe a necessidade de realização de download
da aplicação e qualquer AVA que implementar a especificação LTI poderá utilizar a BDI.
Dentre os trabalhos observados, a BDI é a única ferramenta que utiliza webservices
implementados para funcionar com qualquer aplicação baseada em HTML5 e javascript.
Basta que a aplicação utilize a sua API sem a necessidade de implantação da especificação
LTI para cada situação. A vantagem da utilização de serviços para implementar a integração
com os AVAs está no poder de comunicação dos dados entre duas ferramentas desenvolvidas
com tecnologias diferentes. Além de que, uma vez que um novo serviço foi criado na BDI
e registrado na API javascript, ele funcionará em todas as aplicações desenvolvidas.
Tabela 7 – Tabela comparativa da BDI com os trabalhos relacionados
AVA Utilizado Padrões Suportados Necessidadede download Registra nota
Implementação
LTI para cada APP
(AVILA et al., 2016) Atutor LTI, Caliper NÃO Nativo SIM
(JURADO; REDONDO, 2014) Moodle LTI, TupleSpaces NÃO Não nativo LTI SIM
(LEAL; QUEIRÓS, 2011) Moodle/Sakai LTI NÃO Não nativo LTI SIM
(RODRIGUES, 2012) Moodle SCORM SIM Sim —–
BDI Moodle LTI, WebServices NÃO Sim NÃO
67
5 Conclusão e Trabalhos Futuros
Este capítulo descreve as conclusões obtidas nesta dissertação. São apresentadas
conclusões finais referentes a limitações (seção 5.2) , assim como sugestões de trabalhos
futuros (seção 5.3).
5.1 Conclusões
A elaboração da arquitetura conceitual foi muito importante para demonstrar até
onde o projeto pode chegar. Contudo, outras funcionalidades novas podem surgir dessa
arquitetura. O desenvolvimento do protótipo funcional se mostrou bastante relevante
tanto para atender aos requisitos colhidos durante o estudo exploratório e a satisfação
dos resultados produzidos por eles durante o teste de usabilidade, quanto a inovação
implementada por ele, se compararmos aos trabalhos relacionados.
O foco do trabalho proposto de desenvolver um modelo que resolvesse o problema
de integração dos OAs interativos da antiga biblioteca digital foi atingido com êxito. O
desenvolvimento do protótipo referente à parte principal da arquitetura para abrigar as
aplicações utilizou apenas uma implementação do padrão LTI, de forma que todas essas
aplicações produzidas pudessem se comunicar com os AVAs. A criação da API javascript
utilizada nas aplicações, juntamente com a BDI, eliminaram a necessidade de inserir a
especificação LTI em cada uma dessas aplicações. Algo semelhante acontece no trabalho
de Jurado e Redondo (2014), contudo, a sua arquitetura foi organizada de forma que é
necessário serviços específicos para cada aplicação para que ela consiga enviar os dados
utilizando LTI. Pelo fato da especificação LTI ser uma especificação muito difundida,
outros ambiente virtuais além do Moodle, que implemente esta especificação, poderão
utilizar a BDI.
Com a utilização da BDI, o professor poderá utilizar as aplicações produzidas pelo
setor de materiais interativos no Moodle, através do módulo de atividade externa. O aluno
entrará no AVA e terá acesso a atividade. Agora o professor pode configurar se a aplicação
utilizada valerá nota ou não.
Outro ponto que foi possível identificar durante a entrevista foi em relação à falta de
critérios para produzir os OAs. Não existia nenhum padrão definido para desenvolvimento
deles, também não existia um procedimento padrão para que eles pudessem ser utilizados da
forma correta. O desenvolvimento deste trabalho não definiu apenas uma arquitetura e um
protótipo funcional, também definiu uma especificação que os desenvolvedores responsáveis
pela criação desses materiais interativos devem seguir para que eles possam ser utilizados no
Capítulo 5. Conclusão e Trabalhos Futuros 68
AVA e de forma integrada. A integração da nota recebida pelo aluno, durante a utilização
do OA, é registrada no livro de nota da disciplina do Moodle, eliminando a necessidade de
registro manual de notas para uma atividade extra.
5.2 Limitações do Trabalho
O trabalho apresentou limitação quanto ao número de ciclos de teste de usabilidade.
Foram apresentados resultados do primeiro ciclo, apontando para os problemas identificados
e que devem ser corrigidos. Contudo, o processo de teste de usabilidade deve ser iterativo.
Apesar de ter as características de melhoramento contínuo, não foi possível implementar
uma segunda fase apresentando as correções.
Além disso, os testes de usabilidade foram realizados com a população que está inse-
rida no contexto do protótipo apresentado, todavia, nem todos os testadores participaram
do questionário inicial.
Outro fator que apresenta limitação neste estudo é que não foram realizados testes
com os desenvolvedores de materiais interativos, com o intuito de avaliar a utilização da
API fornecida. Não foi possível analisar as dificuldade que os desenvolvedores poderiam
encontrar ao adaptarem suas aplicações e hospedá-las na BDI.
5.3 Trabalhos Futuros
A partir dos resultados obtidos por este trabalho, é possível pensar em trabalhos
derivados que implementem as outras partes da arquitetura conceitual proposta ou a amplie.
A seguir são apresentadas as sugestões de trabalhos futuros que podem ser realizados a
partir deste:
1. Implementação do plugin LTI no Moodle que seja capaz de listar as aplicações dispo-
níveis na BDI e que podem ser utilizadas no contexto do curso. Esta funcionalidade
pode resolver o problema que os testadores voluntários tiveram para configurar o
módulo de ferramenta externa do Moodle;
2. Incorporar as características definidas na seção 2.2 do capítulo 2, para que a BDI
tenha as funcionalidade específicas de um ROA;
3. Expandir a API utilizada na adaptação dos OAs, implementando novas funcionali-
dades;
4. Implementar funções que torne possível o registro detalhado de todas as ações que
os usuários executam no OA.Para que isso seja possível, as funções podem seguir as
especificações do Caliper ou xAPI;
Capítulo 5. Conclusão e Trabalhos Futuros 69
5. Definir um LRS para armazenar os dados analíticos capturados;
6. Serviços web que possibilite a análise dos dados educacionais colhidos pelo Caliper ou
xAPI. A partir disto o trabalho pode enveredar para o campo da Learning analytics;
7. Desenvolvimento de módulos para interpretar os dados analíticos educacionais.
Além dos pontos citados, é necessário realizar melhorias no protótipo desenvolvido,
tais como na segurança, controle de acesso e escalabilidade. Para isso é necessário realização
de testes de carga e segurança.
70
Referências
ADELSBERGER, H. H.; PAWLOWSKI, J. M. et al. Handbook on information technologies
for education and training. [S.l.]: Springer Science & Business Media, 2008. Citado 2
vezes nas páginas 13 e 23.
ADLNET. Experience API Advanced Distributed Learning (ADL) Co-Laboratories. 2016.
Disponível em: <<https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-About.
md#def-learning-record-store>>. Acesso em Nov 12, 2016. Citado na página 34.
ADLNET.GOV. About Us: Our Mission - ADL Net. 2015. Disponível em:
<<https://www.adlnet.gov/about-adl/>>. Acesso em maio 29, 2016. Citado na página
35.
ADOBE SYSTEMS INCORPORATED. Adobe Flash Video File Format Specification
Version 10.1. EUA, 2010. Citado na página 16.
AFONSO, M. d. C. L. Banco internacional de objetos educacionais (bioe): normas para a
definição dos metadados. Brasília: CESPE/UnB, MEC, 2010. Citado na página 24.
AFONSO, M. d. C. L. et al. Banco internacional de objetos educacionais (bioe):
tratamento da informação em um repositório educacional digital. Perspectivas em Ciência
da Informação, v. 16, n. 3, p. 148–158, 2011. Citado na página 23.
ALARIO-HOYOS, C. et al. Glue!: An architecture for the integration of external tools in
virtual learning environments. Computers & Education, Elsevier, v. 60, n. 1, p. 122–137,
2013. Citado na página 29.
AMADO, J. Manual de investigação qualitativa em educação, 2a Edição. [S.l.]: Imprensa
da Universidade de Coimbra/Coimbra University Press, 2014. Citado na página 57.
AVILA, C. et al. Cocreation and evaluation of inclusive and accessible open educational
resources: A mapping toward the ims caliper. IEEE Revista Iberoamericana de Tecnologias
del Aprendizaje, IEEE, v. 11, n. 3, p. 167–176, 2016. Citado 4 vezes nas páginas 37, 40,
65 e 66.
BARRINGTON, R. Moodle Gradebook. [S.l.]: Packt Publishing Ltd, 2014. Citado na
página 22.
BIOEMEC. Banco internacional de Objetos Educacionais. 2015. S2016. Disponível em:
<http://objetoseducacionais2.mec.gov.br/>. Acesso em Julho 21, 2016. Citado na página
24.
BOYD, R. Getting started with OAuth 2.0. [S.l.]: "O’Reilly Media, Inc.", 2012. Citado na
página 31.
BROOKE, J. et al. Sus-a quick and dirty usability scale. Usability evaluation in industry,
London, United kingdom, v. 189, n. 194, p. 4–7, 1996. Citado 2 vezes nas páginas 60 e 61.
Referências 71
CAPTERRA. Best LMS (Learning Management System) Software 2016 Reviews of the
Most Popular Systems documents. 2015. Disponível em: <http://www.capterra.com/
learning-management-system-software/#infographic>. Acesso em Junho 4, 2016. Citado
na página 20.
DALL’OGLIO, P. PHP Programando com Orientação a Objetos 3a Edição. [S.l.]: Novatec
Editora, 2015. Citado na página 44.
DCMI. DCMI Metadata Basics. 2008. S2008. Disponível em: <http://dublincore.org/
metadata-basics/>. Acesso em Julho 23, 2016. Citado na página 25.
DENZIN, N. K. Collecting and interpreting qualitative materials. [S.l.]: Sage, 2008. v. 3.
Citado na página 57.
FREITAS, H. et al. O método de pesquisa survey. Revista de Administra&ccdeil; ão da
Universidade de São Paulo, v. 35, n. 3, 2000. Citado na página 18.
HAAG, J. ADL Experience (API) and IMS Caliper Discovery Review. 2016. Disponível
em: <<https://www.adlnet.gov/adl-experience-api-and-ims-caliper-discovery-review/>>.
Acesso em julho 27, 2016. Citado na página 35.
IMS. LTI v2.0 Implementation Guide | IMS Global Learning Consortium. 2014. Disponível
em: <https://www.imsglobal.org/specs/ltiv2p0/implementation-guide#toc-19>. Acesso
em maio 4, 2016. Citado na página 31.
JURADO, F.; REDONDO, M. A. Learning tools interoperability for enhancing a
distributed personal learning environment with support for programming assignments. In:
IEEE. Computers in Education (SIIE), 2014 International Symposium on. [S.l.], 2014. p.
87–92. Citado 6 vezes nas páginas 31, 38, 40, 65, 66 e 67.
KAY, R.; KNAACK, L.; PETRARCA, D. Exploring teachers perceptions of web-based
learning tools. Interdisciplinary Journal of E-Learning and Learning Objects, Informing
Science Institute, v. 5, n. 1, p. 27–50, 2009. Citado na página 22.
KOSHIYAMA, D. J. D. G. Avaliação de usabilidade em materiais interativos de ensino a
distância da UFRN-SEDIS. 15 p. Dissertação (Mestrado) — Universidade Federal do Rio
Grande do Norte, 2014. Citado na página 17.
KRAEFT, C. Common Cartridge | IMS Global Learning Consortium. 2015. Disponível
em: <https://www.imsglobal.org/activity/common-cartridge>. Acesso em julho 26, 2016.
Citado na página 28.
KRAEFT, C. IMS Global Learning Consortium. 2015. Disponível em: <https:
//www.imsglobal.org//>. Acesso em julho 27, 2016. Citado na página 28.
KRAEFT, C. Learning Tools Interoperability | IMS Global Learning Consortium. 2015.
Disponível em: <https://www.imsglobal.org/activity/learning-tools-interoperability>.
Acesso em junho 26, 2016. Citado na página 30.
LEAL, J. P.; QUEIRÓS, R. Using the learning tools interoperability framework
for lms integration in service oriented architectures. Technology Enhanced Learning
TECH-EDUCATION’11, Springer Verlag, 2011. Citado 4 vezes nas páginas 39, 40, 65
e 66.
Referências 72
LEWIS, J. Introduction to usability testing. Tutorial given at HCI International, p. 22–27,
2005. Citado na página 59.
MACLEOD, M. et al. The music performance measurement method. Behaviour &
Information Technology, Taylor & Francis, v. 16, n. 4-5, p. 279–293, 1997. Citado na
página 59.
MATTSON, L. IMS Caliper Analytics Implementation Guide | IMS Global Learning
Consortium. 20115. Disponível em: <https://www.imsglobal.org/caliper/caliperv1p0/
ims-caliper-analytics-implementation-guide>. Acesso em dezembro 29, 2016. Citado na
página 34.
MESSINA, C. OAuth 2.0 - OAuth. 2015. Disponível em:<http://oauth.net/2/>. Acesso
em julho 29, 2016. Citado na página 32.
MONK, A. et al. Improving your human-computer interface: A practical technique. [S.l.]:
Prentice Hall New York, 1993. v. 1. Citado 3 vezes nas páginas 59, 60 e 61.
MOODLE. learning objects. 2008. Disponível em: <https://docs.moodle.org/30/en/
learning_objects>. Acesso em Junho 07, 2016. Citado na página 22.
MOODLE. Developer credits. 2016. Disponível em: <<https://moodle.org/dev/
contributions.php>>. Acesso em Maio 31, 2016. Citado na página 13.
MOODLEPLUGINS. Moodle plugins directory. 2016. Dec., s2016. Disponível em:
<https://moodle.org/plugins/>. Acesso em Junho 5, 2016. Citado na página 21.
MORAN, J. M. O que é educação a distância. 2008. Citado na página 20.
MOTA, E. d. S. L. J. B. Planejamento de produção de materiais didáticos para ead. Série
conhecimento - Universidade Federal de Viçosa, 2015. Citado na página 15.
NCITS, A. 354: Common Industry Format for Usability Test Reports. American National
Standards Institute. [S.l.]: Inc, 2001. Citado 3 vezes nas páginas 58, 59 e 60.
PAIVA, V. M. d. O. Ambientes virtuais de aprendizagem: implicações epistemológicas.
Educação em Revista, SciELO Brasil, v. 26, n. 3, p. 353–370, 2010. Citado na página 20.
PEREIRA, A. T. C.; SCHMITT, V.; DIAS, M. Ambientes virtuais de aprendizagem.
AVA-Ambientes Virtuais de Aprendizagem em Diferentes Contextos. Rio de Janeiro:
Editora Ciência Moderna Ltda, p. 4–22, 2007. Citado na página 13.
PRATA, C. L.; NASCIMENTO, A. Objetos de aprendizagem: uma proposta de recurso
pedagógico. Brasília: MEC, SEED, p. 20, 2007. Citado na página 22.
PRODANOV, C. C.; FREITAS, E. C. de. Metodologia do Trabalho Científico: Métodos e
Técnicas da Pesquisa e do Trabalho Acadêmico-2a Edição. [S.l.]: Editora Feevale, 2013.
Citado na página 18.
RODRIGUES, A. P. Integração de ambiente virtual de aprendizagem com repositório
digital Optimization Problems: Methods and Analysis. Tese (Doutorado) — Universidade
Federa do Rio Grande do Sul, 2012. Citado 4 vezes nas páginas 39, 40, 65 e 66.
SALVENDY, G. Handbook of human factors and ergonomics. [S.l.]: John Wiley & Sons,
2012. Citado na página 58.
Referências 73
SILVA, M. S. jQuery - A Biblioteca do Programador JavaScript 1a Edição. [S.l.]: Novatec
Editora, 2008. Citado na página 44.
SILVA, M. S. HTML5–2a Edição: A linguagem de marcação que revolucionou a web. [S.l.]:
Novatec Editora, 2014. Citado na página 16.
SILVA, R. S. da. Objetos de aprendizagem para educação a distância. 2011. Citado na
página 25.
TAROUCO, L.; FABRE, M. Jm; tamusiunas, fr reusabilidade de objetos educacionais.
Novas Tecnologias na Educação. Cinted-Ufrgs, v. 1, n. 1, 2003. Citado na página 23.
TONSIG, S. L. Engenharia de software: análise e projeto de sistemas. [S.l.]: Ciência
Moderna, 2008. Citado na página 41.
TULLIS, T. S.; STETSON, J. N. A comparison of questionnaires for assessing website
usability. In: Usability professional association conference. [S.l.: s.n.], 2004. p. 1–12.
Citado na página 61.
WHYTE VINCE KELLEN, S. D. J. S. O. H. N. M. P. L. R. A. A. 7 things you should
know about caliper. EDUCAUSE Learning Initiative, p. 2, mar 2016. Citado na página
33.
WILEY, D. A. Instructional use of learning objects. [S.l.]: Agency for Instructional
Technology, 2001. 7 p. Citado na página 22.
WILEY, D. A. Connecting learning objects to instructional design theory: A definition, a
metaphor, and a taxonomy. [S.l.: s.n.], 2003. Citado na página 13.
Apêndices
75
APÊNDICE A – Formulário de Pesquisa
sobre repositório integrado ao Moodle
acadêmico da SEDIS



79
APÊNDICE B – Termo de autorização de
pesquisa assinado

81
APÊNDICE C – Entrevista semi-estruturada
com a Coordenação de Produção de Materiais
Interativos
Transcrição da Entrevista com a
Coordenação de Produção de
Materiais Interativos  04/04/17
Entrevistador: Atualmente como são feitas solicitações de produção dos materiais 
interativos? Qual o procedimento?
Entrevistado: Você está falando hoje ou as que estão na biblioteca? pois são momentos 
diferentes.
As que estão lá foram… a SEDIS sempre teve uma tradição muito grande em materiais 
impressos pelo público que era das graduações, das   licenciaturas e do bacharelado 
que era a distância no interior do estado e nos estados adjacentes, e a realidade daquela 
época de 10 anos atrás, era de pessoas que não tinham internet, e não tinha acesso ao digital,
até o próprio digital se tornou mais presente na nossas vidas recentemente. 
Então a produção de materiais interativos começou aqui muito tímida e provocada por
um edital que veio do projeto TICS,  quase simultaneamente com outro projeto do curso 
geografia, então começou-se a pensar em fazer coisas digitais, coisas para web por que antes
a nossa tradição era completamente impresso, eventualmente em gravação de vídeo aulas, 
mas eram aulas bem voltadas para apresentação do curso, ou o professor que quer dar uma 
revisão de prova. 
Na época, a coordenação de materiais, de produção de materiais, juntou algumas pessoas 
que ele achava que tinha perfil para isso e a gente começou a montar o que seria a equipe de
produção de materiais interativos. Aí, a gente tinha eu atuando como design instrucional, 
tinha Sujeito1 que era ilustrador, tinha Sujeito2 que mexia com ilustração, diagramação e 
animação, tinha Sujeito3 que trabalhava com programação e Sujeito4 também que também é
multiúso.
Entrevistador: E hoje como eles fazem para solicitar, algum material interativo desses. Eu 
estava vendo que inclusive entrou no meu trabalho, aquele que é sobre fonoaudiologia, 
utilizando arrasta e solta, o livro digital. Como é que vem esta solicitação, é o professor que 
faz?
Entrevistado: Hoje a gente prensa junto. Temos uma reunião inicial com o professor e aí 
ele tem a ideia do que ele quer fazer, mas ele, até por não conhecer os produtos, ele não tem 
ideia do como aquilo pode ser trabalhado. Então a gente mostra o que a gente faz, e ai 
fazemos proposições já nessa reunião, mas mesmo quando eles mandam o conteúdo a gente 
ainda tem um equipe de desenvolvimento instrucional que ainda faz sugestões. Então você 
tem, de repente, um conteúdo que dá para se transformar em um jogo. Então a gente vai e 
pergunta: professor, isso aqui se a gente fizesse um jogo? A gente precisa do seu apoio. A 
gente trabalha junto com ele, pois não temos o conhecimento técnico sobre o assunto, Então 
a gente precisa desse contato muito próximo, para produzir este produto, seja um livro 
digital, seja um jogo, seja HTML interativo, que a gente tem esse caso também de conteúdo 
completamente digitais. Tem o caso da Professora Sujeito5 que fez a disciplina de geografia,
que está na biblioteca digital também, geografia cultural, que é a árvore, não sei se você 
chegou a acessar. Esse material virou uma disciplina optativa do curso de geografia a 
distância. Ela está toda contida ali, desde apresentação,  passando pelos objetivos, 
atividade, resumo, então tem toda estrutura didática para que aquilo seja uma 
disciplina inteira.
Saulo:Antigamente vocês produziam materiais utilizando o flash. Qual tecnologia vocês 
estão utilizando atualmente?
Entrevistado: Flash, tanto pela incompatibilidade com todos os dispositivos, quanto até
o desuso mesmo, hoje a gente não usa. A gente faz em HTML e o que é flash a gente 
transforma em vídeo em MP4. 
Entrevistador: Como é feita a entrega dos materiais produzidos. Vocês terminam de fazer 
os objetos de aprendizagem e vocês enviam eles diretamente para pessoa que solicitou ou 
vocês colocam direto na biblioteca digital?
Entrevistado: Primeiro a gente envia para o solicitante aprovar. Não colocamos nada no ar 
sem aprovação de quem solicitou. Então a gente coloca numa página temporária aqui do 
servidor e ele acessa e aponta tudo que ele tiver de consideração, não no conteúdo, mas se 
tiver ficado alguma coisa errada, ou que não ficou do jeito que ele queria. Então a gente 
refaz e libera o acesso.
Entrevistador: Existe algum procedimento padrão para que os professores e tutores possam
utilizar o Oas da biblioteca dentro da disciplina no Moodle? 
Entrevistado: Não a gente nunca inseriu dentro do Moodle não. A única experiência que
a gente teve foi aquela do curso do quando fizemos no Moodle mandacaru, a gente fez do 
cérebro. Fora aquilo, a gente nunca colocou no Moodle, sempre foi acesso externo.
Entrevistador: Existe alguma forma de registro de utilização desses OAs e registro de 
notas de participação dos alunos?Vocês já registram algum tipo de acesso a esses objetos? 
Entrevistado: A gente registra assim: os meninos pensavam por exemplo, os conteúdos 
interativos a questão de, quando ele loga ficar registrado onde ele clicou, para ele não repetir
o que ele já viu, mas de registro de todo mapeamento, ou registro de nota não. Ele é um 
objeto desvinculado, ou um objeto isolado.
A gente começou a fazer um trabalho desses naquele projeto que eu falei do TICs de um 
jogo que a gente iria fazer esse registro de nota para a professora, mas o projeto foi 
abandonado no meio do caminho e não foi concluído. A gente teria.
Entrevistador:  Você considera que isso é um problema para que os OAs sejam mais 
utilizados? 
Entrevistado: Eu considera um problema a falta de integração. Na verdade eu acho que o 
aluno deveria estar dentro do Moodle, mas sem estar no Moodle. Eu gosto muito desse tipo 
de conteúdo, em que você faz o aluno imergir nele. Era para ter la dentro a nota, a avaliação,
a atividade, a interação toda com o professor, mas sem que ele necessariamente associe que 
ele está dentro do Moodle.
85
APÊNDICE D – Lista de tarefas para
realização do teste de usabilidade
Tarefas para validação do protótipo
O protótipo desenvolvido neste trabalho faz parte de uma arquitetura conceitual que engloba a
Biblioteca Digital Integrada (BDI) e o Ambiente Virtual de Aprendizagem (AVA) Moodle como
partes principais. A proposta tem como objetivo propor uma solução para a falta de comunicação
dos Objetos de Aprendizagem (OA)  armazenados  na Biblioteca Digital da  Secretaria de Educação
a Distância (SEDIS).  As tarefas descritas abaixo fazem parte do processo de validação da BDI e da
efetividade do processo de integração de seus OAs com o Moodle.  Ao final dos passos descritos, o
OA cadastrado pelo professor deve registrar o resultado da participação do aluno no livro de notas
do Moodle. Com isso, o professor terá acesso aos resultados de participação de cada um dos
participantes, em OAs  completamente customizados.
BDI:
1)  Acesse a BDI  através do link – playerapps.dev  para selecionar o OA que você deseja 
inserir como atividade avaliativa em sua disciplina no Moodle. Realize seu cadastro para 
poder acessar a BDI.
2) Clique no OA para visualizar os seus detalhes. Copie o  código de identificação do OA 
clicando no botão .Este código será fundamental para que a configuração do OA no Moodle 
funcione corretamente.
3) Abra uma nova aba do navegador para acessar o Moodle. Não é necessário  sair da BDI.
MOODLE:
1) Acesse o   Moodle de testes utilizando o  Link -  localhost/mdl_ligacoes . Clique em acessar
no canto superior direito da tela. Realize login utilizando o usuário: [seu primeiro nome] e 
senha:123.
2) Entre no curso que você está matriculado(a) como professora e Ative a edição  utilizando o 
botão do canto superior   direito da tela.
3) Crie uma atividade do tipo  Ferramenta Externa.
4) Selecione a BDI no item “Tipo de ferramenta externa”. 
5) Cole o código de identificação do OA (copiado do item 4 da BDI) no campo “Parâmetros 
customizados”. 
6) Clique em “Salvar e voltar para o curso”.
7) Clique na atividade que você acabou de criar para visualizar o resultado e aguarde que seus 
alunos realizem a atividade.
Clique aqui para acessar o formuário de avaliação do sistema.
87
APÊNDICE E – Tela de cadastro de
aplicações da Biblioteca Digital Integrada
(BDI)

Anexos
90
ANEXO A – Respostas da pesquisa sobre
repositório integrado ao Moodle acadêmico da
SEDIS
Pesquisa sobre repositório integrado ao
Moodle acadêmico da SEDIS -
PPGSW/UFRN
28 respostas
Data de Nascimento:
28 respostas
dez de 1947 24
jan de 1956 23
dez de 1956 18
jul de 1960 31
fev de 1962 10
fev de 1965 23
fev de 1966 8
jun de 1966 20
dez de 1971 29
mai de 1973 10
ago de 1975 26
jan de 1978 4 6
jun de 1978 12
fev de 1981 9
fev de 1982 16
dez de 1982 25
jun de 1983 25
out de 1983 25
mai de 1986 2
jun de 1986 17
jun de 1986 17
jan de 1991 15
fev de 2016 24
jun de 2016 8
jul de 2016 28
ago de 2016 14 31
jan de 2017 16
Gênero:
27 respostas
Pesquisa
Você é professor(a) em qual(is) curso(s) no Moodle Acadêmico no
semestre 2016.1 ?
26 respostas
Masculino
Feminino
66,7%
33,3%
1
2
1 (3,8%)
2 (7,7%)
1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)
2 (7,7%)
1 (3,8%)1 (3,8%)
2 (7,7%)
1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)1 (3,8%)
Você já teve a necessidade de adicionar algum Objeto de
Aprendizagem ao Ambiente Virtual da SEDIS que fosse diferente dos já
existem no ambiente? Ex: livro interativo, jogo, questionário
personalizado, etc.
28 respostas
Caso a resposta anterior seja sim, como foi o procedimento de
inserção deste(s) objeto(s)?
10 respostas
Utilizei as orientações da equipe de suporte
ALGUMAS VEZES EU MESMA FIZ A INSERÇÃO OUTRAS VEZES SOLICITEI A AJUDA DO SUPORTE DE TI
DA SEDIS/UFRN.
Não houve
Tinha a necessidade de colocar um vídeo, consegui,mas os estudantes não conseguiram visualizar.
Fui na SEDIS e z o treinamento para inserção de diários.
Tive a necessidade, mas não consegui inserir.
Enviei o endereço do link e como senti diculdades e operacionalizar, enviei mais arquivos pelo e-mail dos
estudantes.
questionario com nota
Prático
Inseri hiperlinks de páginas que tinham questionários ou instrumentos, também vídeos diferenciados,
como é o caso de aula em 360 graus. Algumas ferramentas do próprio MOODLE Mandacaru, que se dizem
disponíveis, não estão por completo, como é o caso de Banco de Dados, por exemplo.
 
Houve alguma coleta de dados da interação dos alunos com este
Sim
Não64,3%
35,7%
Houve alguma coleta de dados da interação dos alunos com este
objeto? Como foi feita?
10 respostas
Não (2)
Que tipo de interação? Acesso? Se sim, zemos esse levantamento
SIM. EM SEMESTRES ANTERIORES APLIQUEI UM QUESTIONÁRIO DE AVALIAÇÃO E ESTE SEMESTRE
(2016.1) FIZ ESSE ACOMPANHAMENTO ATRAVÉS DA LEITURA DOS RELATÓRIOS GERAIS DISPONÍVEIS
NO AMBIENTE.
Não foi feita por desconhecimento da possibilidade
Não houve, devido ao relato que z no questionamento anterior
Não houve.
Houve consulta do link, vídeo para tirar dúvidas de normas da ABNT
respostas
Sim. Os estudantes foram a um laboratório de informática e preencheram de forma orientada aos
questionários e participaram das medições dos testes de tempo de reação, sob minha orientação, passo
a passo.
Você sabia que a SEDIS possui uma Biblioteca Digital com repositório
de Objetos de Aprendizagem?
27 respostas
 
 
 
 
 
 
 
 
Sim
Não44,4%
55,6%
 
 
Você chegou a utilizar os Objetos de Aprendizagem da Biblioteca
Digital da SEDIS como ferramentas de ensino?
28 respostas
Os objetos da Biblioteca Digital foram utilizados dentro do contexto do
curso do Ambiente Virtual de Aprendizagem?
25 respostas
 
 
 
 
 
 
 
 
 
 
 
Caso os Objetos tenham sido utilizados dentro do contexto do
Ambiente virtual, alguma coleta de dados da interação dos alunos com
estes objetos foi feita?
20 respostas
Sim
Não
21,4%
78,6%
Sim
Não
20%
80%
Você considera importante ter um repositório de Objetos de
Aprendizagem capaz de se comunicar com o Ambiente Virtual e de dar
um retorno mais detalhado da interação com os alunos?
28 respostas
Número de respostas diárias
Este conteúdo não foi criado nem aprovado pelo Google. Denunciar abuso - Termos de Serviço - Termos Adicionais
Sim
Não
100%
Sim
Não
Não sei os benefícios que isto
poderia trazer par a educação
a distância.7,1%
92,9%
jul de
2016
ago de
2016
set de
2016
out de
2016
nov de
2016
dez de
2016
jan de
2017
0
2
4
6
 Formulários
97
ANEXO B – Questionário System Usability
Scale (SUS)
System Usability Scale
© Digital Equipment Corporation, 1986.
*Obrigatório
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
 
 
 
 
Eu acho que gostaria de utilizar este sistema frequentemente. *
Eu achei o sistema desnecessariamente complexo *
Eu achei o sistema fácil de utilizar *
Eu acho que precisaria do apoio de um suporte técnico para ser
possível usar este sistema *
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Eu achei que as diversas funções neste sistema foram bem
integradas *
Eu achei que houve muita inconsistência neste sistema *
Eu imaginaria que a maioria das pessoas aprenderia a usar esse
sistema rapidamente *
Eu achei o sistema muito pesado para uso *
Eu me senti muito conante usando esse sistema *
Discordo
totalmente
1 2 3 4 5
Concordo
totalmente
Nunca envie senhas pelo Formulários Google.
Este conteúdo não foi criado nem aprovado pelo Google. Denunciar abuso - Termos de Serviço - Termos Adicionais
Eu precisei aprender uma série de coisas antes que eu pudesse
continuar a utilizar esse sistema *
ENVIAR
 Formulários