Desenvolvimento de ambientes de u-learning

Com relação ao desenvolvimento de sistemas ubíquos, este processo se apresenta como um paradigma radicalmente diferente daquele utilizado em aplicações tradicionais para

Web ou Desktop. Isto se deve ao fato dos dispositivos estarem espalhados no ambiente e

serem projetados para requerer atenção periférica (e não central) dos usuários e, idealmente, utilizar-se de interações “naturais” (AZEVEDO, 2009). Outra particularidade, que deve ser considerada durante projetos de sistemas ubíquos, é o conceito de affordance, que se refere à qualidade perceptiva de um objeto, ou ambiente, que permite (ou atrai) o indivíduo a realizar uma ação. Indo um pouco mais além, a percepção não vem apenas do que se vê, mas do contato do indivíduo com o ambiente, ou seja, do conjunto total de elementos perceptivos (DOURISH, 2001).

18 _{Entidades elementares do Youubi: Pessoa}

A partir de uma análise sistemática, Ogata (2004) apresenta um conjunto de características fundamentais para sistemas de informação concebidos para apoiar a aprendizagem ubíqua:

a) Permanência das informações – as informações criadas e coletadas pelos indivíduos não devem ser perdidas, a menos que sejam propositalmente excluídas. Além disso, as interações e demais dados úteis para o processo de aprendizagem devem ser registrados de forma contínua;

b) Acessibilidade das informações – os indivíduos têm acesso às suas informações a partir de qualquer lugar;

c) Imediatismo – onde quer que estejam, os indivíduos podem requisitar e obter informações imediatamente;

d) Interatividade – os indivíduos podem interagir com seus pares por mecanismos de comunicação síncrona ou assíncrona; e

e) Atividades situadas – as situações de aprendizagem podem ser incorporadas à vida cotidiana dos envolvidos.

Além dessas características gerais, o conceito de Computação Ubíqua, e seu desenvolvimento na área educacional, é muito amplo e apresenta requisitos desafiadores de serem contemplados, mesmo diante dos avanços tecnológicos atuais. Portanto, entende-se que o desenvolvimento de padrões e ferramentas simplificam o desenvolvimento de aplicações de aprendizagem móveis e ubíquas 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. Durante as atividades de concepção dos requisitos e da arquitetura do ambiente Youubi foram consideradas também as características descritas por Martin (2011b), que define um conjunto de critérios que devem ser observados no desenvolvimento de ambientes de u-learning, e que, consequentemente, devem estar previstos durante a concepção de suas arquiteturas:

a) Privacidade – preocupações relativas à privacidade são amplificadas em aplicações sensíveis ao contexto, devido ao acesso a uma grande quantidade de dados que se referem às interações com os conteúdos e seus pares, e ao perfil completo do indivíduo, inclusive seus dados de localização;

b) Sincronização – operações síncronas, em que uma operação tem de esperar por uma resposta antes da execução continuar, são inadequadas para aplicações sensíveis ao contexto, que precisam ser notificadas de forma assíncrona quando novos dados estão disponíveis;

c) API disponível – a disponibilização de uma API (Application Programming

Interface) permite que serviços possam ser consumidos por outros subsistemas,

desenvolvidos com tecnologias diferentes, o que reduz a complexidade dos projetos e a sobrecarga de processamento sobre as aplicações clientes;

d) Software livre – quando um software é distribuído com uma licença open

source, significa que mais pessoas podem ter acesso a ele, o que contribui para

a evolução e popularização dos projetos;

e) Extensibilidade e reusabildade – extensibilidade está relacionada à capacidade de adicionar uma nova funcionalidade, enquanto reusabildade se refere à capacidade de uma funcionalidade ser novamente usada em outros sistemas. Proporcionar essas propriedades nos componentes de software permite a evolução incremental e reduz o esforço de desenvolvimento;

f) Aquisição do contexto – a coleta de dados que descrevem o contexto pode ser direta, quando faz uso de uma fonte interna (ex. um provedor de localização), ou externa, quando faz uso de uma fonte externa (ex. um servidor meteorológico);

g) Tolerância à incerteza – medições feitas do mundo real por sensores podem apresentar algum grau de incerteza e incompletude. Assim, usar várias fontes de sensores é recomendado para minimizar essa incerteza;

h) Representação das entidades – para permitir que o sistema possa coletar e processar os dados de forma sistêmica por todos os componentes, a representação das entidades e do contexto precisam estar bem definidos e sem ambiguidades;

i) Escalabilidade – propriedade que se refere à capacidade de aumentar progressivamente a capacidade de um sistema, a fim de manter seu desempenho em um nível aceitável para os usuários;

j) Comunicação – suporte à comunicação entre os indivíduos de forma síncrona e assíncrona; e

k) Conteúdos instrutivos – além de dar suporte aos conteúdos criados pelos próprios aprendizes, os ambientes devem disponibilizar conteúdos relacionados aos objetivos de aprendizagem desses indivíduos.

Por ser um campo de pesquisa ainda muito recente, durante a revisão bibliográfica sobre temas relacionados à u-learning, constatou-se a carência de padrões que auxiliassem o desenvolvimento padronizado de sistemas nessa natureza. Mesmo entre os trabalhos que descrevem o desenvolvimento de aplicações, há poucos detalhes sobre o processo de concepção, arquitetura ou tecnologias adotadas. Esse fato também foi constatado por outras pesquisas e revisões sistemáticas acerca de modelos e padrões adotados em projetos de

u-learning (MARTIN, 2011b; SPÍNOLA; TRAVASSOS, 2012). Percebe-se que esse cenário

é bem diferente daqueles relacionados, por exemplo, aos ambientes de aprendizagem Web para a e-learning, com padrões e projetos já bem maduros, consolidados e muitos deles open

source. Essa carência de padrões e projetos open source pode acarretar retrabalho no esforço

do desenvolvimento de novos projetos, como também, atrasar a efetiva popularização de sistemas sensíveis ao contexto pelos aprendizes e professores.

Quando se usa o termo genérico “arquitetura”, no contexto da Engenharia de Software, pode-se estar se referindo à arquitetura de referência ou à arquitetura de software, que estão atreladas a um modelo de referência. Apenas para ilustrar e facilitar a compreensão sobre a relação entre esses conceitos, o Quadro 5 apresenta alguns exemplos já bastante consolidados.

Quadro 5 – Exemplo de Modelo de Referência, Arquitetura de Referência e Arquitetura de Software

Modelo de Referência Arquitetura de Referência Arquitetura de Software

Sistemas Distribuídos CORBA19 Visibroker20

Fonte: o autor

Portanto, uma arquitetura candidata precisa dar suporte ao desenvolvimento de ambientes baseados na abordagem da u-learning, e, consequentemente, busca satisfazer os princípios da computação ubíqua. Neste processo, primeiramente, é preciso definir o Modelo de Referência que se refere à decomposição de um problema conhecido em partes que o resolvem de forma cooperativa. A partir da experiência, os Modelos de Referência são

19

CORBA: http://www.corba.org

características de um domínio maduro e descrevem em termos gerais como as partes se inter- relacionam para realizarem seus objetivos (CLEMENTS, 2002; DOMINGOS, 2004). Em seguida, é preciso conceber 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. Por fim, a arquitetura de referência deve ser instanciada para criar a arquitetura de software de um sistema específico, que está mais diretamente relacionada às questões estruturais e tecnológicas do desenvolvimento do software final. Desenvolver um sistema sobre uma arquitetura tem como vantagem auxiliar a gestão dos problemas decorrentes da complexidade do projeto (DOMINGOS, 2004).