Por que utilizar adaptadores e programação orientada a aspectos

Dey e colaboradores, em [Dey01], indicam que a separação de interesses, uma das bases da programação orientada a aspectos, é um dos requisitos que um framework

para lidar com contexto deve contemplar para auxiliar os desenvolvedores no gerenciamento de contexto. A separação de interesses mencionada pelos autores refere- se à aquisição e ao uso do contexto. De acordo com eles, através da separação da aquisição do contexto de seu uso, as aplicações podem usar informações contextuais sem se preocupar, por exemplo, com detalhes de implementação de um sensor, ou com as interfaces utilizadas para obter informações a partir dele. Carton et al. [Car07] citam que um dos requisitos para uma aplicação pervasiva é ser capaz de se adaptar dinamicamente com base em diversos fatores, incluindo o estado do ambiente, limitações do dispositivo, mobilidade do usuário e conectividade. Esses fatores podem impactar ao longo de toda a aplicação, por isto que se pode falar que eles são transversais [Car07].

Na visão de autores cujas pesquisas são mais voltadas para consciência de contexto em aplicações (sem se preocupar com o padrão arquitetural) parece ser claro quais são os interesses transversais. Já na literatura de agentes, ainda não há uma definição geral de quais são os interesses transversais que devem ser modelados como aspectos. Segundo Amor e Fuentes [Amo09], “(…) identifying crosscutting concerns specific to agents is still an open issue (…)”. Para eles, as propriedades de comunicação tipicamente “cortam” diferentes módulos da arquitetura dos agentes e, portanto, englobam os interesses transversais utilizados pelos autores. Já Garcia e Lucena [Gar08] consideram como interesses transversais características de agência, como interação, adaptação, autonomia, colaboração, aprendizagem e mobilidade.

Amor e Fuentes [Amo09] indicam que o primeiro passo para a aplicação efetiva da tecnologia de desenvolvimento de software orientada a aspectos é a identificação dos interesses transversais na arquitetura interna de um agente individual. Neste trabalho, como se adapta os agentes em decorrência de mudanças em seus contextos e eventos ocorridos em suas arquiteturas internas, os interesses transversais são relacionados a ambos contexto e eventos ocorridos no agente. Na verdade, o processo de adaptação, por si só, é um interesse que corta muitos (senão todos) componentes do agente. Sendo assim, para evitar espalhamento e embaralhamento do código (scattering e tangling), é interessante separar o código relacionado à adaptação dos demais módulos ou componentes do agente, como é feito com o uso de adaptadores na arquitetura K2. A natureza “transversal” de um adaptador está na possibilidade de utilizar elementos genéricos na composição dos pontos de adaptação. Com os elementos genéricos, um adaptador pode cortar a aplicação em diferentes pontos.

Na literatura foram encontrados dois16 trabalhos que utilizam programação orientada a aspectos para o desenvolvimento de aplicações conscientes de contexto. Em [Sin08], Sindico e co-autores apresentam a linguagem JCOOL (COntext Oriented Language), desenvolvida para lidar com consciência de contexto em aplicações Java. De acordo com os autores, a detecção das mudanças no contexto e as adaptações relacionadas a essas mudanças podem ser considerados dois interesses transversais distintos com respeito à lógica de negócio da aplicação.

A Figura 4.1 apresenta um trecho de código-fonte em linguagem JCOOL (extraído de [Sin08]), onde são interceptadas mensagens entre peers de acordo com o contexto. Como ilustrado na figura, a linguagem proposta define construtores para o monitoramento de contexto (construtor Context) e para a adaptação ao contexto (construtor Adaptor). No exemplo, o estado do contexto refere-se à segurança do protocolo de transporte disponível, sendo os valores possíveis “alto” ou “baixo” (conforme indicação a na figura). A adaptação compreende o cancelamento do envio de mensagens que requerem alto nível de privacidade quando a segurança do protocolo é baixa (indicação b na figura).

Em [Gra07] há aspectos executando o papel de “Monitores de contexto” e as modificações nas informações contextuais são verificadas por um contêiner chamado Monitor. Uma vez recuperadas, as informações contextuais são armazenadas pela própria aplicação. Há outro contêiner chamado Adapter, cujo papel é aplicar os mecanismos de adaptação de acordo com as indicações recebidas dos monitores de contexto. As políticas de adaptação são descritas em diagramas de atividade UML e no próprio código- fonte da linguagem AspectJ.

Figura 4.1 – Exemplo do código-fonte da linguagem JCOOL [Sin08].

16 _{O trabalho apresentado em [Amo09], como discutido na Seção 2.2.2, também utiliza aspectos para}

realizar a adaptação do sistema, no entanto, como os pontos de atuação são muito limitados (são interceptados apenas o envio e o recebimento de mensagens), ele não será considerado como exemplo nessa seção.

a

A Figura 4.2 mostra um exemplo de código em AspectJ (retirado de [Gra07]) de uma aplicação no domínio de serviços para usuários móveis em um aeroporto. As informações contextuais utilizadas no exemplo são a realização do check-in e o tempo faltante para o embarque (que deve ser menor que 20 minutos). O efeito obtido com a adaptação é a apresentação de alerta de tempo insuficiente para almoço quando ativada a função “Selecionar Restaurante” (o usuário pode optar por continuar ou abortar).

Figura 4.2 – Exemplo do código-fonte em AspectJ da solução proposta em [Gra07]. De maneira geral, a programação orientada a aspectos parece ser apropriada para o desenvolvimento de aplicações adaptativas ao contexto. Alguns dos benefícios obtidos com o uso da tecnologia são a modularização da solução e a separação dos interesses de adaptação ao contexto do restante do comportamento funcional da aplicação, simplificando seu desenvolvimento e manutenção. Embora a utilização de tal tecnologia traga benefícios para o desenvolvimento de aplicações adaptativas ao contexto, há algumas questões que ainda limitam o seu uso. No entanto, como será descrito a seguir, várias dessas limitações são superadas quando se trabalha com um nível de abstração maior do que o próprio aspecto, como é proposto neste trabalho.

De acordo com Grassi e Sindico [Gra07], abordagens orientadas a aspectos propõem soluções para lidar com consciência de contexto no nível de código-fonte, sem considerar o nível de projeto mais abstrato. Já em [Sin08] é criticado o restrito conjunto de

eventos no fluxo de execução de uma aplicação que são considerados como pontos de junção (locais onde há interceptação e possivelmente inserção de um comportamento adaptativo). De acordo com os autores, os pontos de junção normalmente utilizados na programação orientada a aspectos não são expressivos o suficiente para lidar com a complexidade de uma definição de contexto.

As duas limitações citadas pelos autores são superadas quando se usa adaptadores cujos pontos de adaptação e variantes são compostos, respectivamente, de um conjunto abrangente de eventos internos e primitivas. Primeiro, ao definir um adaptador utilizando eventos no ponto de adaptação e primitivas nas variantes, o desenvolvedor trabalha em um nível de abstração maior que o código-fonte, o que permite considerar o nível de projeto mais abstrato. A falta de expressividade dos pontos de junção também é superada com um conjunto abrangente e completo de eventos internos.

Amor e Fuentes [Amo09], com base no estudo de trabalhos disponíveis na literatura, indicam três limitações relacionadas à aplicação de soluções orientadas a aspectos em agentes. A primeira diz respeito à falta de interoperabilidade com plataformas compatíveis com o padrão FIPA, pois o padrão geralmente não é seguido nas soluções propostas na literatura. A segunda limitação refere-se ao tipo de weaving de aspectos utilizado. Segundo os autores, a composição dos objetos e aspectos é normalmente executada em tempo de compilação, o que reduz as possibilidades de adaptação dos agentes. A terceira limitação está relacionada ao reuso de aspectos, que é afetado devido à inclusão de nomes de classes, assinaturas de métodos, e outros, dos objetos que serão modificados. Por último, e não menos importante, a programação orientada a aspectos não é tão simples de aprender e, com a falta de ferramentas de suporte, o seu uso pode se tornar realmente complexo [Amo09].

Algumas das limitações indicadas por Amor e Fuentes são superadas devido à forma como os adaptadores são criados e combinados nos componentes do agente. Neste trabalho, os adaptadores são combinados nos componentes do agente em tempo de carga (load time weaving), porém, como os pontos de atuação de um aspecto criado para a implantação de um adaptador possui, basicamente, cláusulas com o designador if, todas as verificações para a execução de uma adaptação são feitas em tempo de execução. A dificuldade de utilizar programação orientada a aspectos é minimizada pelo fato do desenvolvedor definir os pontos de adaptação e variantes utilizando um conjunto de eventos e primitivas pré-definidos. A falta de interoperabilidade com o padrão FIPA não

é uma preocupação do trabalho proposto, visto que tal compatibilidade é de responsabilidade da plataforma na qual a arquitetura K2 estiver integrada. Já a questão relacionada ao reuso de aspectos continua sendo uma limitação.