Fonte de Dados

O framework foi implementado a partir de padrões de design que descrevem uma solução reusável para captura de contextos a partir de três tipos de fontes de dados distintas: ambiente físico; ambiente digital pessoal do usuário; e, bases de dados de informações contextuais (por exemplo, SGA, bases públicas ou privadas).

A coleta realizada a partir do ambiente digital pessoal do usuário utiliza nós sensores lógicos, onde cada nó coleta, paralela e independentemente uns dos outros, um evento específico. A coleta realizada por sensores lógicos possibilita amplo rastreamento dos comportamentos do usuário a partir de interações executadas em páginas web e eventos de aplicações locais. Dados coletados a partir do rastreamento das interações via browser incluem: a duração da interação e sequência de eventos naquela interação; duração de intervalos de tempo de inatividade (ou seja, sem interações) durante as visitas às páginas do SGA ou demais páginas na web; cliques em objetos ativos da página; uso de barra de rolagem, entre outros. O rastreamento do ambiente local, externo ao browser, inclui: interações com objetos baixados a partir de uma disciplina no SGA e duração da interação; execução de aplicações paralelamente enquanto estuda no SGA, relacionadas ou não com a unidade de estudo atual, tais como mensageiros instantâneos, tocadores multimídia, etc.; e, o uso de dispositivos de entrada e saída, tais como pen drive, câmera e memória secundária. Características do dispositivo físico (por exemplo, tamanho de tela) e da rede de comunicação (por exemplo, largura da banda, latência) também são obtidos por sensores lógicos.

Sensores lógicos são implementados como um sistema multiagentes, onde cada sensor lógico é considerado um micro agente artificial com existência própria e independente dos demais. Tais sistemas oferecem uma organização estruturada e provê características de trabalho concorrente e distribuído com padrões de interação sofisticados (BRADSHAW, 1997). Assim, micro agentes (sensores lógicos) são projetados para agirem em paralelo e tem características de sentir e coletar um tipo de dado específico. A especificação e divisão de funcionalidades entre micro agentes provê requisitos importantes em arquitetura distribuída, por exemplo, modularidade, flexibilidade, capacidade de modificação e extensibilidade.

O framework também suporta mecanismos de atuação no lado cliente. Atuadores são agentes responsáveis por realizar uma ação apropriada no ambiente,

conforme interesse das aplicações. Por exemplo, o atuador lockUserActuator bloqueia o computador do usuário. Outro exemplo de atuador implementado é o

showOnBrowserActuator, responsável por criar um elemento <div> para exibir

parâmetros CSS e HTML na janela do browser.

Com isso, a coleta realizada pelo framework proposto produz um conjunto de dados detalhado e de granularidade final que pode refletir fielmente as atividades distribuídas do usuário e, então, conduzir a análises de dados educacionais mais sólidas e precisas.

5.2.1.1.1 Pré-processamento dos Dados

Dada a diversidade de fontes e o grande volume de dados produzidos por diferentes interfaces consideradas na fase de aquisição realizada pelo framework, torna-se evidente a complexidade do tratamento dos dados obtidos a fim de eliminar, ou reduzir, imperfeições. Considera-se que não há como resolver todos os problemas que podem estar relacionados à imperfeição dos dados em único algoritmo de fusão sem acarretar outros problemas decorrentes da complexidade da infraestrutura de software necessária.

A centralização de todos esses dados obtidos (navegação, interação, comunicação do usuário, dados do ambiente físico e dados de repositórios) em um único repositório de dados a fim de facilitar o processo de fusão é algo impraticável e, portanto, uma solução desconsiderada. Isso não se deve a questões de armazenamento físico, que não é um problema dadas as excelentes características de arquiteturas de hardware de armazenamento atuais, mas sim às questões de gerenciamentos que se fazem necessárias e novas soluções que sejam eficientes em resolver o problema da fusão de todos esses dados de maneira integrada.

Conforme apresentado na Seção 2.6.2 deste documento, algumas pesquisas sobre abordagens para fusão de dados obtidos por fontes heterogêneas estão sendo propostas atualmente. No entanto, não há soluções automatizadas, por enquanto, que resolvam todos os problemas de imperfeição em dados de fontes híbridas, especialmente pela dificuldade de lidar com incertezas de dados subjetivos, tais como redes sociais, conteúdos de mensagens de fóruns e e-mails. Soluções atuais necessitam de intervenção humana para validação ou complementação de dados e não são totalmente automáticas.

Abordagens diferentes podem ser usadas para fusão de dados no ambiente físico, no ambiente digital e em repositórios. O tratamento de dados para eliminar imperfeições, apesar de extremamente importante, não é o foco deste trabalho. Partindo deste ponto de vista e considerando, ainda, que eventuais falhas no funcionamento do sistema proposto nesta tese, ocasionadas por imperfeições nos dados coletados, não comprometem a segurança de pessoas, também não promovem danos materiais, financeiros ou naturais, a questão da qualidade do dado não é implementada em todos os níveis de abstração do framework proposto, mas apenas no nível da rede física. Essa decisão foi tomada tendo em vista que o tempo necessário para proposição de uma solução que resolva os problemas com dados imperfeitos considerando a heterogeneidade de tipos de dados, fontes, e interfaces de coleta, inviabilizaria o desenvolvimento do framework proposto, e portanto, desta pesquisa.

5.2.1.1.2 Aspectos tecnológicos

O framework foi escrito em Java. Por razões de implementação, a coleta de dados no ambiente digital do usuário é dividida em duas subredes de sensores lógicos: sensores para rastreamento de eventos dentro do browser; e sensores para rastreamento fora do browser. No primeiro caso, sensores lógicos são implementados usando tecnologias JavaScript e AJAX e são embarcados em

browsers via plugin. Dados coletados no browser são publicados no sink, conforme

ilustra a Figura 5.2. Um container servlet, Jetty14_{, é usado para manipular} solicitações assíncronas. Neste trabalho, sink é um nó receptor responsável por gerenciar os mecanismos de publish/subscribe (p/s) localmente e também pela comunicação entre a rede e serviços.

No segundo caso, sensores para rastreamento fora do browser são implementados usando Java Agent Development Framework (JADE)

(BELLIFEMINE, POGGI, e RIMASSA, 1999) em conformidade com a Foundation for

Intelligent Physical Agents (FIPA15) que suporta o desenvolvimento de sistemas

multiagentes. Um sensor lógico é implementado como um micro agente coletor de

14 _{Jetty Web Server,http://www.eclipse.org/jetty/about.php.} 15 _{Foundation for intelligent physical agents, http://www.fipa.org/.}

dados. Um agente tem um modelo de computador multitarefa, onde tarefas (ou comportamentos) do agente são executados simultaneamente.

Figura 5.2 _{– Coleta distribuída de dados realizada por redes de sensores híbrida e} tecnologias utilizadas. Fonte: elaborado pela autora.

O Quadro 5.1 apresenta alguns exemplos de sensores lógicos desenvolvidos no escopo deste trabalho a partir da identificação de requisitos. Sensores físicos também são usados para coleta de dados convencionais, tais como a localização do usuário. Sensor Observation Service (SOS16_{) é usado para consultas aos dados dos} sensores na rede física em tempo real. O padrão PostgreSQL é usado como base de dados para armazenamento persistente.

Outro aspecto tecnológico relacionado ao framework desenvolvido é que ele facilita a adição de novas funcionalidades, caracterizando-o como uma solução reusável. Os seguintes padrões de design foram utilizados com o propósito de reduzir a reescrita de código: (i) abstract factory para manter um conjunto consistente de sensores de acordo com a plataforma subjacente, por exemplo em sistemas Windows deve-se garantir que nenhum sensor implementado para Linux

será criado; (ii) singleton, para assegurar a criação de uma factory somente durante o ciclo de vida dos sensores em uma plataforma, ou máquina, em particular; e (iii)

strategy para isolar as diferentes implementações de sensores de acordo com a

plataforma em uso. A implementação do framework possibilita a fácil integração de novos nós sensores. Para isso, algumas funcionalidades são disponibilizadas para facilitar seu uso, tais como as seguintes opções de manipulação de sensores:

create_sensor – cria um sensor com parâmetros básicos para serem estendidos a

fim de incorporar novas fontes de dados; update_sensor – possibilita alterar parâmetros de sensores já existentes, incluir ou excluir parâmetros; e delete_sensor – possibilita a exclusão de sensores criados que não serão utilizados pelo sistema.

As decisões de projeto foram influenciadas pelo desenvolvimento extensível de novos nós sensores e atuadores, rápido desempenho, independência de plataforma e solução reusável.

Quadro 5.3 _{– Sensores Lógicos e Atuadores. Fonte: elaborado pela autora.}

Nome do Sensor Dado Coletado

Dent ro do B rows er ( DB )

quiz_sensor Cliques realizados em formulários. whereAtLMS_sensor Localização do usuário no SGA. login_sensor Login no SGA.

focusChange_sensor Recebimento e perda de foco (seleção de objetos). scrolling_sensor Uso de barras de rolagem.

resizing_sensor Redimensionamento da janela. keystrokes_sensor Pressionamento de teclas.

accessedMaterials_sensor Materiais teóricos acessados no SGA. accessedActivities_sensor Atividades acessadas no SGA.

F ora do B rows er ( F B

) USBSensor Uso de portas USB.

AppMonitorSensor Aplicações em execução no dispositivo do usuário. ResponseTimeSensor Tempo de resposta em comunicação entre dois pontos. BandwidthSensor Velocidade de download e upload.

InstantCommunicationSensor Ferramentas de comunicação instantânea sendo usadas. CameraSensor Uso da câmera.

MicrophoneSensor Uso do microfone.

Atuador Atuação

FB LockUserActuator Bloqueia o computador do usuário _{de hibernate.} – função semelhante à opção DB showOnBrowserActuator Cria um elemento <div> para exibir parâmetros recebidos.