Descrição da Arquitetura de Referência

Conforme apresentado nos capítulos anteriores, o conceito de Aprendizagem Ubíqua é bastante interdisciplinar e apresenta requisitos desafiadores de serem contemplados. Portanto, entende-se que a adoção de padrões simplificam o desenvolvimento de novos projetos, e aceleram o ciclo de vida dos projetos. Isto faz com que os esforços das equipes se concentrem nos aspectos didáticos e de design educacional, e não nos detalhes tecnológicos e de programação. Neste sentido, a arquitetura proposta para o Youubi foi concebida para dar suporte ao desenvolvimento de ambientes baseados na abordagem da u-learning.

Durante esse processo, primeiramente, foi preciso definir o modelo de referência, que se refere à decomposição de um problema conhecido em partes que o resolvem de forma cooperativa. Para este trabalho foi adotado o modelo Cliente-Servidor, onde há um provedor de serviços sempre em funcionamento que atende as requisições de subsistemas denominados clientes. Algumas vantagens na adoção desse modelo são: não exige dos clientes altos requisitos de processamento, é fácil de ser escalado em casos de sobrecarga, normalmente requer hardware mais barato, e atualizações do servidor são feitas de forma transparente para os clientes (KUROSE; ROSS, 2006).

Em seguida, foi concebida a arquitetura de referência, que consiste em um modelo de referência mapeado sobre elementos de software, que cooperativamente implementam as

funcionalidades definidas no modelo de referência. Ela também define a infraestrutura comum e as interfaces dos componentes dos sistemas que a implementam (Apêndice K). Por fim, a arquitetura de referência foi implementada para dar origem à arquitetura de software do sistema, que neste trabalho é chamada de Youubi Server. A seguir, a Figura 10 ilustra uma representação de alto nível da arquitetura de referência proposta e dos componentes internos implementados para esta tese, destacados de vermelho.

Figura 10 – Arquitetura do Youubi

Fonte: o autor

Conforme será detalhado a seguir, a arquitetura do Youubi é composta por oito componentes internos do lado do servidor, e seus serviços podem ser consumidos por aplicações clientes, por exemplo, para smartphones, tablets, aplicações web, smart TV e

smartwatches49, ou por outros sistemas, por meio de uma API de serviços. Essa API provê

métodos que devem suportar os casos de uso elementares de uma rede social on-line (BENEVENUTO; ALMEIDA; SILVA, 2011), como também, serviços específicos para ambientes de u-learning sensíveis ao contexto. Vale salientar também que cada um dos componentes internos da arquitetura possui uma atribuição específica e uma interface de serviços bem definida. Isso garante, desde sua concepção, o respeito às propriedades de baixo acoplamento e alta coesão. Por fim, para sua validação, todos os seus componentes internos foram implementados, o que deu origem ao Youubi Server; e para consumir seus serviços, foi implementado também um cliente para smartphones e tablets, chamado aqui de Youubi Android,

para que pudesse ser utilizado por professores e estudantes em ambiente real.

4.3.1.1 Componentes da arquitetura

Para garantir alta coesão, os componentes principais são divididos e posicionados de acordo com sua função na arquitetura. A seguir, serão descritos cada um deles e as tecnologias adotadas para sua implementação.

Communication – este componente faz o papel da camada de comunicação, o que

permite que as aplicações clientes utilizem a API de serviços do Youubi (Apêndice J) para requisitar serviços do Youubi Server. Esses serviços também devem estar em consonância com os requisitos funcionais elencados. No nível de implementação, foi adotada a linguagem Java50, e para disponibilizar essa API, a camada de comunicação foi implementada sobre Web

Service51, o que permite responder as requisições realizadas pelas aplicações clientes, e

sistemas independentes, por meio de requisições HTTP52 (Hypertext Transfer Protocol). Dessa forma, não há restrições quanto à linguagem ou às tecnologias utilizadas nos aplicativos que consumam esses serviços, pois, por se tratar do protocolo de aplicação da Internet, qualquer linguagem de programação moderna é capaz de enviar requisições HTTP. Mais especificamente, para sua implementação, foi adotado o framework RESTEasy53, que utiliza a técnica REST (Representational State Transfer), que se apresenta como alternativa mais eficiente frente ao padrão SOAP (Simple Object Access Protocol) (FIELDING, 2000).

50 _{Java: http://www.java.com} 51

Web Service: solução que utiliza como base o protocolo HTTP, e que tem como objetivo permitir a comunicação entre sistemas diferentes, inclusive, implementados em plataformas e linguagens de programação diferentes.

52 _{HTTP: protocolo de comunicação utilizado para sistemas de informação, distribuídos e colaborativos. É}

também o protocolo padrão para a transferência de conteúdos Web na Internet.

Atualmente, a API Youubi disponibiliza 90 métodos, que refletem os requisitos funcionais definidos no Quadro 8, além de outros serviços de consulta auxiliares. Isso permite que qualquer aplicação cliente capaz de consumir os serviços do Youubi Server tem também a capacidade de implementar os requisitos funcionais do Youubi.

Manager – este componente deve processar as requisições vindas dos clientes,

repassadas pelo componente Communication, logo, é responsável por gerenciar as regras de negócio, distribuindo para os outros componentes da arquitetura (Analyzer, Collector,

Recommender, Persistence) tarefas especializadas, conforme suas competências. Devido sua

importância, ele pode ser considerado o núcleo da arquitetura, pois é responsável por gerenciar todos os demais componentes. Para lidar com essa complexidade ele é subdividido em vários gerenciadores (managers), conforme Figura 11, que em nível de implementação foram escritos na linguagem Java.

Figura 11 – Gerenciadores especializados do componente Manager

Fonte: o autor

Além de encaminhar tarefas para outros componentes, algumas regras de negócio são realizadas pelo próprio componente Manager. Por exemplo, ele é responsável por atualizar indicadores (classes do componente Common Model) que permitem identificar padrões de comportamento dos usuários com base em suas interações com o sistema. Esses indicadores (Scores, Context e Times) são atualizados constantemente pelo componente Manager sempre que um serviço da API Youubi é utilizado pelos clientes. Essa estratégia reduz a necessidade de processamentos custosos em lote e garante que os dados representados por esses indicadores possam ser consultados em tempo real. A seguir, são apresentadas as classes que representam esses indicadores:

A classe Scores é composta por atributos responsáveis por contar todas as ações realizadas pelo usuário no sistema, organizados por tipos específicos. A cada interação do usuário no sistema, o atributo correspondente a esta ação é incrementado. A manutenção desses atributos, em tempo real, garante que estejam sempre atualizados e evita processamento extra para calcular esses indicadores. Os dados representados por essa classe podem ser utilizados para: refinar o processo de recomendação do componente Recommender; possibilitar a adoção de estratégias de gamification tais como mural de medalhas e rankings; e permitir aos professores acompanharem as atividades mais realizadas pelos estudantes no ambiente e utilizar essas informações em suas práticas.

A classe Context representa o estado de um objeto Person em um determinado instante de tempo, sua localização, altitude, velocidade de deslocamento, estado do dispositivo que ele está utilizando para acessar o sistema, e a ação que o usuário realizou. Um objeto Context é criado periodicamente e sempre que a aplicação cliente consome algum serviço da API do

Youubi Server, para que o processamento da requisição possa utilizar um contexto recente do

usuário. Com o passar do tempo, o conjunto desses objetos ajuda a compor o histórico de ações do usuário.

A classe Times representa um histograma (distribuição de frequências) de todas as ações realizadas pelo usuário distribuídas por unidades de tempo (hora do dia e dia da semana). É possível registrar as seguintes ações: criação de elementos, edição de elementos, adição de objetos como favorito, convites de amizade enviados, convites de amizade recebidos, comentário sobre algum elemento, avaliação sobre algum elemento, visualização de algum elemento, aceitação de sugestões, buscas por elementos, remoção de algum elemento, logins realizados, logouts realizados, mensagens enviadas, mensagens recebidas, e a soma de todas as ações anteriores. Para cada um desses indicadores, há dois tipos de histogramas, que se diferenciam por sua periodicidade: o primeiro representa um histograma das 24 horas do dia, enquanto o segundo representa o histograma dos 7 dias da semana.

Collector – este componente é responsável por coletar dados sobre outros sistemas que

disponibilizam uma API de acesso, tais como Google54, YouTube55, Wikipedia56, Facebook57, Twitter58, Redu59, Moodle60, entre outros. Dessa forma, o perfil do usuário pode ser

54

Google API: http://code.google.com/apis/console

55 _{Youtube: https://www.youtube.com/yt/dev/pt-BR/api-resources.html}

56 _{MediaWiki: http://www.mediawiki.org/wiki/API}

57 _{Facebook API: http://developers.facebook.com} 58

Twitter API: http://dev.twitter.com

enriquecido com informações vindas de outros sistemas, tornando as recomendações mais exatas. Além disso, esse recurso também permite incrementar o acervo de informações, conteúdos e serviços que podem estar sendo disponibilizados e recomendados aos aprendizes e professores. Para a versão atualmente implementada, foi necessário utilizar a API do Google54 para, com base nas coordenadas de latitude e longitude, conseguir obter detalhes de um determinado local, tais como, estabelecimento (se houver), logradouro, bairro, cidade, estado e país.

Analyzer – este componente é responsável por analisar os dados armazenados no

banco de dados a fim de identificar novas informações que possam enriquecer o perfil dos usuários. Um exemplo de aplicação desse componente no Youubi se refere à adoção de recursos de Gamification (DETERDING, 2011; SEIXAS, 2014). Neste sentido, procura-se analisar todas as ações realizadas pelos usuários a fim de incentivá-los a continuar interagindo no sistema, através de indicadores de participação, medalhas e rankings. Outro exemplo de aplicação desse componente seria a identificação do estilo de aprendizagem do estudante. Por meio das dimensões e indicadores desenvolvidos por Felder e Silvermann (1988), busca-se identificar o estilo de aprendizagem do aprendiz utilizando a análise de todo seu histórico de interações e tipos de conteúdos consumidos. À medida que as dimensões de estilos de aprendizagem vão sendo identificadas, essas informações podem ser utilizadas pelo componente Recommender, a fim de melhorar a precisão dos elementos recomendados. Além disso, informações desse tipo podem auxiliar o professor na condução das suas práticas. No nível de implementação, este componente foi utilizado para identificar o local mais visitado pelo usuário e calcular os amigos em comum de sua rede social. Para tornar seu processo mais eficiente, este componente utiliza threads para permitir o paralelismo do processamento. Ao fim de cada ciclo, os dados obtidos são persistidos no banco de dados, ou seja, o perfil do usuário é constantemente realimentado.

Recommender – este componente é responsável por analisar os dados armazenados no

banco de dados e gerar uma lista de objetos recomendados para cada entidade elementar do Youubi (Person, Post, Event, Challenge, Location e Group). No nível de implementação, para garantir paralelismo do processamento, o processo de recomendação acontece apenas em uma fase: a cada login realizado por um usuário, uma thread periódica é disparada com o objetivo de confrontar o perfil desse usuário com todos os objetos da base de dados. E por se tratar de

um ambiente de u-learning, em cada um desses ciclos, são utilizadas informações provenientes das aplicações clientes, que se referem aos atributos de contexto dinâmico do usuário, por exemplo, sua localização atual, velocidade de deslocamento e detalhes sobre o equipamento utilizado. Essas informações são encapsuladas e repassadas da aplicação cliente para o Youubi Server através da classe Context.

Persistence – este componente é responsável pela persistência dos dados no banco de

dados, o que garante o isolamento entre persistência e regras de negócio. No nível de implementação, este componente utiliza o padrão JPA (Java Persistence API) sobre o framework EclipseLink61. O Sistema de Gerenciamento de Banco de Dados (SGBD) adotado foi o PostgreSQL62, pois além de se tratar de um projeto estável e já bastante consolidado é distribuído sob a licença open source BSD (Berkeley Software Distribution).

Common Tools – este componente deve ser composto por uma série de métodos

utilitários, por exemplo, algoritmos de conversão. Dessa forma, por concentrar tais métodos, evita que regras de negócio sejam implementadas no componente Common Model, além disso, evita também a sobrecarga de atribuições sobre o componente Manager. Ele também pode ser utilizado tanto pelas aplicações clientes, quanto pelos componentes executados no servidor, sem riscos de dependência cíclica.

Common Model – este componente é responsável por representar os modelos de dados

das entidades da arquitetura, inclusive as entidades elementares (Person, Post, Event,

Challenge, Location e Group). No nível de implementação, as entidades Post, Event e Challenge, por possuírem muitos atributos em comum, são implementadas pela classe Content, conforme é exibido na Figura 12. Além disso, este componente concentra classes

JavaBeans63 que representam as entidades da arquitetura, por isso, não deve realizar nenhuma

regra de negócio e pode ser utilizado por todos os outros componentes da arquitetura, inclusive pelas aplicações clientes, sem riscos de dependência cíclica. Este componente também representa o modelo de dados, graças à utilização das annotations do padrão JPA, ou seja, as classes do modelo servem para representar tanto as entidades do sistema quanto as tabelas do modelo de dados, conforme é apresentado na Figura 13.

61 _{EclipseLink: http://www.eclipse.org/eclipselink} 62 _{PostgreSQL: http://www.postgresql.org} 63

JavaBeans: classe Java serializável, reutilizável, e que permite acesso às suas propriedades através de métodos getter e setter. Normalmente é utilizada para representar as entidades do modelo de dados de um sistema.

Figura 12 – Classes que representam as entidades elementares

Figura 13 – Diagrama Entidade-Relacionamento do componente Model

Fonte: o autor

Por disponibilizar uma API de serviços, outros sistemas e outras aplicações clientes, independente do dispositivo ou linguagem de programação, podem consumir os serviços oferecidos pela interface IYouubi, bastando apenas que sua plataforma suporte ao protocolo HTTP, o que não é difícil, pois se trata de um protocolo padrão da camada de aplicação da Internet. Além disso, por ter seu desenvolvimento baseado no conceito de Computação Ubíqua, no qual os serviços oferecidos podem estar distribuídos em diferentes dispositivos, o componente Communicationpermitequeaarquiteturasejacapazdereceberetratar requisições de aplicações clientes Mobile, TV, Web e Wearable, conforme são descritos a seguir:

Cliente Mobile – diante da popularização dos dispositivos móveis, tais como

smartphones e tablets, conforme já discutido, eles podem contribuir com a popularização de

cenários de aprendizagem ubíqua, pois são dispositivos que acompanham o usuário em suas atividades cotidianas e são capazes de coletar informações do ambiente e se conectarem a outros dispositivos (DEY, 2011). Para este trabalho, foi implementada uma aplicação cliente para dispositivos desse tipo, e é chamada aqui de Youubi Android, cujos detalhes de concepção e desenvolvimento serão apresentados na Seção 4.4.

Cliente Web – conforme Pesquisa Brasileira de Mídia 2014 (BRASIL, 2014), encomendada pelo IBOPE para a Secretaria de Comunicação do Governo Federal, em 2013, 46% da população possuía acesso à Internet. Esses dados mostram a importância da oferta de serviços sobre clientes Web. Além disso, a oferta de serviços personalizados, independente do

dispositivo de acesso que o aprendiz tenha à sua disposição, é uma das características da aprendizagem ubíqua. Vale destacar também que clientes Web podem ser desenvolvidos não só para computadores desktop e notebooks, mas também para qualquer plataforma que disponibilize um navegador Web, como, por exemplo, smartphones, tablets, e alguns modelos de televisores, celulares convencionais, centrais multimídia, entre outros.

Cliente TV – conforme pesquisa IBOPE (2013), em 2013, 97% da população brasileira possuía acesso à televisão. Embora nem todos tenham acesso à TV por assinatura, TV Digital por sinal aberto (TVD) ou televisores inteligentes (smart TV), é notável a penetração desse tipo de dispositivo entre a população brasileira. Além disso, sabe-se que o desligamento do sinal analógico está previsto para acontecer até 2018 (BRASIL, 2013), o que pode motivar a população trocar seus televisores por aparelhos mais modernos. Diante desses fatos, o Youubi também prevê o acesso a seus serviços por meio de plataformas executadas sobre sistemas de

smart TV, por exemplo, Android TV64.

Cliente Wearable – no sentido de tornar o Youubi cada vez mais próximo do conceito de ubiquidade, adotou-se também o suporte a dispositivos do tipo Smartwatches (relógios inteligentes). Embora esses aparelhos ainda não sejam populares, talvez devido aos preços ainda elevados, mais empresas vêm comercializando estes produtos. De modo geral, estes aparelhos permitem a instalação de aplicativos, possuem display touchscreen e podem se conectar à Internet e/ou a smartphones por meio de conexão bluetooth, e recentemente, também por conexão Wi-Fi. Por exemplo, LG65, Sony66, Samsung67, Pebble68 e I’m69 disponibilizam SDK (Software Development Kit) para o desenvolvimento de aplicações para seus produtos.

Aplicações externas – além das aplicações clientes previstas acima, o Youubi também prevê que outros sistemas independentes (ex: OpenRedu70 e Amadeus-LMS71) possam consumir seus serviços. Para isso, o acesso pode ser feito por meio de protocolos de autorização. 64 _{Android TV: http://www.android.com/tv} 65 _{LG: http://www.lge.com/br/wearables} 66 Sony: http://www.sonymobile.com/br/products/smartwear/ 67 _{Samsung: http://www.samsung.com/uk/consumer/mobile-devices/wearables/} 68 _{Pebble: http://getpebble.com} 69 _{I´m: http://www.imsmart.com/en/i-m-watch/} 70 OpenRedu: http://openredu.cin.ufpe.br/ 71 _{Amadeus-LMS: www.softwarepublico.gov.br/dotlrn/clubs/amadeus/}

4.3.1.2 Entidades elementares

Embora o componente Model, que representa o modelo de dados do sistema, seja composto por dezenas de classes, seis delas representam as entidades elementares do Youubi, são elas: Person (pessoa), Post (postagem), Location (localização), Event (evento), Challenge (desafio) e Group (grupo). Dessas classes derivam os objetos que representam os usuários do ambiente e os objetos que esses usuários podem criar e manipular. É importante destacar que cada uma dessas entidades possuem também atributos de geolocalização, o que permite associar a cada um deles uma posição geográfica real.

Person – esta entidade representa os indivíduos do ambiente e pode ser considerada a

principal do modelo, pois, localiza-se logicamente no centro de todas as demais. Deste modo, ela deve ter relacionamento com Post, Event, Challenge, Group, Location e também com a própria Person, para que possa dar suporte a requisitos de rede social. Esta entidade também deve possuir atributos que consigam representar o contexto de cada indivíduo.

Location – esta entidade representa uma localização, que pode ser criada, comentada,

avaliada e compartilhada pelos indivíduos. Ela é composta naturalmente por sua coordenada (latitude e longitude), como também por outros atributos que agregam significado, como nome, descrição, endereço, imagem, entre outros. Esta entidade também está associada às outras entidades elementares (Post, Event, Challenge e Group) o que possibilita aproximar os objetos do ambiente virtual ao cotidiano do indivíduo, inclusive, recomendá-los conforme seu contexto é alterado.

Post – esta entidade representa uma postagem, que pode ser criada, comentada,

avaliada e compartilhada pelos indivíduos. Uma postagem pode ser composta por textos, links e arquivos, inclusive imagens.

Event – esta entidade representa um evento do tempo, que pode ser criado, comentado,

avaliado e compartilhado pelos indivíduos do ambiente. A adoção desse elemento é baseada nas possibilidades de estratégias de autorregulação da aprendizagem que podem ser desenvolvidas (SOUZA, 2012).

Challenge – esta entidade representa um desafio, por exemplo, uma questão de

múltipla escolha, que pode ser criada, comentada, avaliada e compartilhada pelos indivíduos do ambiente. Esse elemento possibilita aos professores e aos próprios aprendizes o desenvolvimento de práticas lúdicas embasadas nos princípios da aprendizagem ativa (PRINCE, 2009) e em estratégias de gamification (SEIXAS, 2014). Para cada desafio criado,

há também um placar que informa a pontuação de cada indivíduo que tentou responder, por exemplo, informando quantas vezes cada um errou e se conseguiu acertar.

Group – esta entidade representa um grupo, ou seja, um conjunto de pessoas que podem compartilhar entre si mensagens, postagens, eventos, desafios e lugares. Um grupo pode ser criado e avaliado pelos indivíduos do ambiente. Esse elemento possibilita práticas com suporte nas teorias da aprendizagem sócio interacionista (VIGOTSKI, 2007) e cognição situada (LAVE; WENGER, 1991).