Funcionamento e Reutilização do UbiCon

A Figura 4.8 ilustra o funcionamento da adaptação híbrida com o uso do

UbiCon, considerando apenas o perfil do dispositivo do usuário. Quando um cliente

acessa a aplicação, a requisição HTTP é interceptada pelo componente ContentAdapterFilter do UbiCon ( ), o qual inicia o processamento da adaptação. Em seguida, o componente ContextManager é invocado para obter o perfil do dispositivo de acesso ( ), o qual é recuperado do WURFL ( ). A seguir, a parte estática da adaptação é realizada através da seleção da página Web requisitada a partir da versão mais apropriada ao perfil do dispositivo obtido ( ). A adaptação dinâmica é então iniciada, com a invocação das funcionalidades de adaptação fornecidas pelo componente ContentAdapter ( ). Uma cópia da página escolhida é criada na memória, e os trechos da interface que necessitam ser refinados para atender ao perfil do dispositivo recuperado são identificados aplicando-se as regras implementadas nos serviços de adaptação ( ). Os ajustes necessários (e.g. redimensionamento, transcodificação) são aplicados ( ), a cópia da página com o conteúdo adaptado é escrita no fluxo de saída da resposta HTTP ( ), e finalmente enviada ao dispositivo do usuário ( ).

Para determinar a versão mais apropriada da interface durante a parte estática da adaptação, o UbiCon realiza a leitura de um arquivo de configuração XML, chamado context-rules.xml, o qual contém definições de regras contextuais estáticas

que determinam a escolha da versão adequada que atenda aos requisitos do contexto. Este arquivo é preparado pelo Engenheiro de Aplicação, que decide, em tempo de desenvolvimento, a melhor combinação de ECs para definir a escolha de cada versão desenvolvida para a interface. Conforme mostrado no arquivo context-rules.xml ilustrado na Figura 4.9, as regras para a seleção de uma determinada versão da interface são expressas nos nós contextRule, os quais especificam os ECs e seus respectivos valores que determinam a escolha da versão da interface relacionada com o nó de rótulo context no qual estão contidos. Por exemplo, conforme se observa no trecho destacado do arquivo da Figura 4.9, a versão da interface desenvolvida para

desktops está associada com o nó context cujo atributo interfaceID contém o

valor “Desktop”. Esse valor corresponde exatamente ao nome da pasta na qual essa versão está armazenada no diretório da aplicação. Os nós filhos de rótulo contextRule indicam que tal versão será selecionada somente no caso dos ECs DEVICE_PRODUCT_INFO_IS_MOBILE_DEVICE e DEVICE_MARKUP_XHTML_SUPPORT recuperados do contexto estejam com valores iguais (eq) a “falso” (false) e “verdadeiro” (true), respectivamente. Conforme pode-se observar na Figura 4.9, também é possível estabelecer o grau de relevância (relevanceLevel) de cada EC

! " # $ % $ % & $ & ' (" ' ) $ &

'

(

'

) *

em relação à decisão de escolha da versão da interface, o qual varia entre alto (3), médio (2) ou baixo (1). No arquivo de exemplo, o nível de relevância do EC rotulado DEVICE_PRODUCT_INFO_IS_MOBILE_DEVICE na decisão de escolha da versão para

desktops foi configurado como “alto” (3), uma vez que tal informação contextual possui

grande importância na determinação dessa escolha.

Durante a leitura do arquivo context-rules.xml, o UbiCon calcula, para cada versão da interface, as quantidades de regras contextuais que coincidem com os valores dos ECs recuperados do contexto. Essas quantidades são agrupadas por grau de relevância conforme especificado em cada EC nos nós contextRule. O UbiCon então executa o algoritmo apresentado na Figura 4.10, escrito em pseudocódigo. Nesse algoritmo, a variável R representa o grau de relevância, variando entre 1 e 3; a variável I é um índice que representa a versão da interface cujo valor varia de 1 a n, onde tal valor associa-se com uma determinada versão de acordo com a sequência em que seu nó context correspondente aparece no arquivo context-rules.xml; e a variável score[I][R] é um vetor bidimensional que armazena as quantidades calculadas de regras contextuais para cada versão da interface por grau de relevância dos ECs. O objetivo do algoritmo é retornar o índice da versão que possui o maior número de regras contextuais satisfeitas com maiores níveis de relevância. Se todas

as versões possuírem a mesma quantidade de regras satisfeitas em cada grau de relevância, então o índice da primeira versão é retornado.

Também é possível observar no arquivo context-rules.xml da Figura 4.9 a definição do atributo dynamicAdaptation em cada nó context. Esse atributo indica quando certa versão da interface deverá passar pela etapa de adaptação dinâmica após sua escolha. A presença desse atributo é justificada pela possibilidade de se construir versões da interface altamente especializadas para dispositivos específicos, as quais, portanto, não requerem refinamentos adicionais. Pode-se, por exemplo, considerando o tipo de dispositivo do público-alvo que utilizará a aplicação com mais frequência, desenvolver uma versão específica para o dispositivo mais usual e definir que tal versão não deverá ser adaptada em tempo de execução.

Após sua implementação, o framework Ubicon é reutilizado no desenvolvimento das aplicações ubíquas com interfaces ricas adaptativas. No processo Model Driven RichUbi, o UbiCon é um importante mecanismo de suporte à adaptação das interfaces na etapa de EA, conforme destacado na Figura 4.11. O

UbiCon contribui para facilitar o desenvolvimento, no sentido de que o desenvolvedor

precisa apenas conhecer sua interface (hot spot do framework) para a reutilização dos

adaptadores de conteúdo. Além disso, o framework pode ser futuramente estendido com a incorporação de novas entidades contextuais, de modo a fornecer serviços de adaptação que atendam os diferentes dispositivos, preferências do usuário, características da rede e outros contextos.

4.4 Considerações Finais

Para que a adaptação de uma aplicação que executa em um ambiente ubíquo ocorra de forma satisfatória, diferentes fatores devem ser considerados pela aplicação. Esses fatores incluem não apenas as características do dispositivo de acesso, mas também características relacionadas com outros perfis, como o do usuário, da rede de acesso e outros.

Visando a prover auxílio aos desenvolvedores de software no desenvolvimento de interfaces ricas adaptativas de aplicações ubíquas, foi construído o framework

UbiCon, apresentado neste capítulo, reaproveitando-se os adaptadores de conteúdo

elaborados na etapa de ED do processo Model Driven RichUbi. O UbiCon encapsula as tarefas de manipulação do contexto na execução da aplicação e fornece funcionalidades para adaptação do conteúdo de interfaces ricas.

Como um refinamento do processo, o framework UbiCon fornece um apoio computacional mais adequado para o emprego dos adaptadores de conteúdo, através de uma interface que omite detalhes de implementação e torna disponível, para o Engenheiro da Aplicação, apenas o que interessa para a sua reutilização. Embora a versão atual trate apenas do contexto associado ao perfil do dispositivo de acesso, o UbiCon foi projetado de forma que novos componentes que manipulam o contexto de outras entidades contextuais possam ser futuramente adicionados. Assim, é possível estender o UbiCon para atender a diferentes requisitos de adaptação demandados por diferentes entidades contextuais. Dessa forma, o

UbiCon pode ser reutilizado na etapa de EA do processo Model Driven RichUbi para

apoiar a construção de interfaces ricas que se adaptam conforme as variações contextuais de diferentes entidades.

No próximo capítulo é abordada a avaliação do processo Model Driven

RichUbi. Nessa avaliação o reúso do framework UbiCon foi fundamental para facilitar

o processo no atendimento aos requisitos de adaptação dos conteúdos das interfaces.