Um Interpretador de Contexto para Plataformas de Serviços Context-Aware

Camilo Zardo Calvi, Rodrigo Mantovaneli Pessoa, José Gonçalves Pereira Filho

Programa de Pós-Graduação em Informática Departamento de Informática – Universidade Federal do Espírito Santo

Caixa Postal 01-9011 – CEP 29060-970 – Vitória – ES – Brasil {camilozc, rpessoa, zegonc}@inf.ufes.br

Abstract. The new mobile computing technologies and the increasing use of portable devices place computers even more present on human life activities. This particular scenario favored rising a new computing paradigm: the Ubiquitous Computing. Among the existing sorts of applications, context-aware mobile applications take benefits from using contextual information to improve users’ interactions. This paper presents the design of a new Context Interpreter. The proposed interpreter is based on directed acyclic graphs to handle, reasoning and interpret context information – core activities on ubiquitous, context-aware services platforms.

Resumo. O desenvolvimento de novas tecnologias de computação móvel e o crescente emprego de dispositivos portáteis têm tornado a computação cada vez mais presente na realização de diversas atividades humanas. Este ambiente favorece o surgimento de um novo paradigma computacional: o da Computação Ubíqua. Dentre as classes de aplicações existentes nesse novo cenário, as aplicações móveis sensíveis ao contexto se beneficiam do uso de informações contextuais para aprimorar a interação com seus usuários. Este artigo descreve o projeto de um interpretador de contexto, baseado em grafos acíclicos dirigidos, destinado à manipulação, inferência e interpretação de informações contextuais – atividades de importância fundamental em plataformas de serviços sensíveis ao contexto.

XXXII SEMISH 1990

1. Introdução Os últimos anos têm presenciado um movimento de mudança do paradigma de computação desktop, tradicionalmente estático, para um novo paradigma, altamente dinâmico, caracterizado pelo emprego de novos dispositivos portáteis multifuncionais – que substituem as agendas, telefones, pagers ou um computador pessoal – e pela constante mudança no ambiente, como conseqüência da mobilidade do usuário. Esse novo paradigma, o da Computação Ubíqua (Ubiquitous Computing), traz consigo a possibilidade de se explorar uma nova geração de aplicações, sensíveis ao contexto (Context-Aware Applications), em que a interação usuário-aplicação é enriquecida pela percepção e uso de informações contextuais. Essas aplicações levam em consideração na sua tomada de decisão e em seus processamentos não apenas as entradas explícitas, mas também entradas implícitas, provenientes do contexto físico e computacional do ambiente e de seus usuários. O termo Computação Ubíqua foi introduzido por Mark Weiser [Weiser 1991], quando vislumbrou ambientes acrescidos de recursos computacionais capazes de prover serviços e informações quando e onde sejam desejadas. De acordo com Weiser, deve haver integração contínua entre tecnologia e ambiente de modo a auxiliar os usuários em atividades cotidianas; portanto, computadores devem ser embutidos de forma implícita ao ambiente do usuário.

A manipulação de contexto em um ambiente ubíquo requer a superação de uma série de desafios tecnológicos e de design. Em particular, o desenvolvimento de aplicações móveis sensíveis ao contexto requer a existência de uma infra-estrutura de suporte de software adequada à manipulação de contextos diversos, provenientes de ambientes altamente dinâmicos, distribuídos, heterogêneos e em constantes mudanças. Em função disso, temos presenciado o surgimento de várias pesquisas relacionadas à construção de plataformas de serviços com suporte à execução dessas aplicações [Dey 2000], [Chen, Kotz 2002], [Dockhorn 2003], [Hess et al 2002], [Hong, Landay 2001], [Gu et al 2004] e [Chen 2004]. Essas plataformas visam fornecer suporte arquitetural e de programação extra para que os projetistas possam desenvolver as suas aplicações usando serviços, mecanismos e interfaces que escondam dessas a complexidade da manipulação de contexto.

Um dos requisitos fundamentais nessas plataformas é a existência de um componente responsável pela atividade de interpretação do contexto. Esse componente, o Interpretador de Contexto, realiza a manipulação e o refinamento das informações contextuais provenientes das diferentes fontes de contexto, com a finalidade de torná-las disponíveis para uso, de forma transparente, para as aplicações. Além disso, o interpretador fornece padronização e generalização no processo de aquisição e manipulação de contexto, possibilitando o reuso de componentes e métodos no desenvolvimento de novas aplicações. Desse modo, a complexidade de tratamento de informações contextuais em ambientes ubíquos é abstraída para as aplicações.

O processo de interpretação de contexto pode ser simples, como derivar a velocidade de um maratonista a partir de informações de localização e de tempo, ou o nome de uma rua a partir de suas coordenadas geográficas; ou mais complexo, como reconhecer o humor de um usuário baseado no seu perfil e na atividade que ele está realizando, ou mesmo inferir a atividade de um médico a partir de um conjunto de

XXXII SEMISH 1991

informações contextuais primitivas. Como um exemplo adicional no campo da Saúde, a interpretação de contexto poderia ser usada como suporte a serviços de gerência de emergências médicas, auxiliando, por exemplo, na escolha da melhor rota de ambulâncias para hospitais de acordo com as condições do trânsito, com a gravidade em que se encontram os pacientes e com as especialidades e informações de lotação das unidades hospitalares da vizinhança. Nesse exemplo, observa-se que são várias as informações contextuais manipuladas e que a habilidade de se poder antecipar a transmissão de informações críticas sobre os pacientes em trânsito, para o hospital mais apropriado, pode fazer a diferença em casos mais graves. Vários outros exemplos de serviços na área da Saúde imediatamente surgem quando passamos a dispor dessas tecnologias: a Telemedicina Móvel, o Monitoramento Remoto de Pacientes, os Serviços de Localização, o Acesso Ubíquo aos Prontuários Clínicos dos Pacientes e outros.

Os exemplos acima ilustram os benefícios que as tecnologias de computação móvel e a manipulação de contexto podem trazer para uma área de grande apelo social, como a Saúde. Na verdade, superadas algumas limitações das tecnologias sem fio hoje existentes (por exemplo, largura de banda, roteamento, privacidade, etc), e existindo um suporte arquitetural apropriado para a manipulação de contexto, o universo das potenciais aplicações e dos possíveis domínios de uso é praticamente ilimitado. Em outras palavras, pode-se afirmar que a computação móvel e ubíqua exibe um alto grau de verticalidade, atingindo praticamente todas as áreas do conhecimento (Negócios, Educação, Segurança, Turismo, Engenharias, etc). Esse cenário justifica o crescente interesse da comunidade acadêmica e do setor produtivo em geral no desenvolvimento de novas plataformas, serviços e soluções baseadas no uso dessas tecnologias.

Este artigo apresenta o projeto de um interpretador de contexto para a Plataforma Infraware, uma plataforma orientada a serviços, com suporte a aplicações móveis sensíveis ao contexto, em desenvolvimento no Laboratório de Pesquisas em Redes e Multimídia da UFES. Tipicamente, duas questões merecem especial atenção na construção de um interpretador de contexto: (i) o tipo de estrutura de software em que é baseada a arquitetura e a lógica interna do interpretador; e (ii) a modelagem de contexto e de informações contextuais que é usada na manipulação dos dados. O interpretador proposto neste trabalho utiliza grafos acíclicos dirigidos [Szwarcfiter 1986] como estrutura de software para manipulação, interpretação e inferência de contextos. O modelo de contexto adotado é o descrito em [Henricksen et al 2002], que possui expressividade adequada à representação de informações contextuais e é compatível com a estratégica de desenvolvimento do projeto (isto é, uso inicial de um modelo informal de contexto). Dentre as principais características do interpretador de contexto desenvolvido, destacam-se a utilização de componentes genéricos que podem ser usados (e reusados) em um grande número de aplicações sensíveis ao contexto, além de uma flexibilização quanto ao uso diversificado de linguagens de programação para descrever mecanismos de cálculos de valores contextuais e disparos de ações.

O restante deste artigo está assim organizado: a Seção 2 introduz algumas discussões sobre contexto; a Seção 3 apresenta a plataforma Infraware; a Seção 4 detalha os componentes funcionais do interpretador desenvolvido; a Seção 5 descreve a implementação realizada; a Seção 6 mostra um estudo de caso em um cenário hospitalar; a Seção 7 descreve brevemente alguns trabalhos relacionados e a Seção 8 conclui o artigo, apresentando considerações finais e perspectivas de trabalhos futuros.

XXXII SEMISH 1992

2. Definindo Contexto Contexto tendo sido objeto de investigação científica há vários anos em algumas comunidades científicas, como Lingüística e Psicologia Cognitiva. Na comunidade de Ciência da Computação, os estudos sobre o tema são mais recentes; porém, pode-se observar importantes contribuições para o seu entendimento e formalização, particularmente em trabalhos da área de inteligência artificial [McCarthy 1997].

No dicionário Houaiss a palavra “contexto” significa a “inter-relação de circunstâncias que acompanham um fato ou uma situação”. A abrangência desse conceito leva a entender que, intuitivamente, para os sistemas computacionais, contexto pode ser entendido como tudo que está ao redor de um sistema em questão, tudo que ocorre em um determinado ambiente. O termo possui uma grande variedade de significados na literatura, dependendo do propósito da aplicação particular e/ou do ponto de vista da comunidade científica em questão. [Schilit 1995], em um dos trabalhos pioneiros da área, enumera exemplos de contextos em três categorias: (i) contexto computacional (conectividade de rede, custos de comunicação, largura de banda e recursos disponíveis), (ii) contexto do usuário (perfil, localização e humor) e (iii) contexto físico (luminosidade, níveis de barulhos, condições do trânsito e temperatura). Várias outras definições podem ser encontradas na literatura de Computação Ubíqua, mas a mais referenciada é aquela apresentada por [Dey 2000]:

Contexto é qualquer informação que pode ser usada para caracterizar uma situação de uma entidade. Uma entidade é uma pessoa, um lugar, ou um objeto que é considerado relevante para a interação entre um usuário e uma aplicação, incluindo o próprio usuário e a própria aplicação.

Freqüentemente usadas como sinônimo de contexto, as informações contextuais são as informações que caracterizam um determinado contexto. São elas as informações relevantes para se determinar o estado atual de um contexto. Por exemplo, para o contexto localização, as informações contextuais que o caracterizam podem ser a latitude e a longitude de uma entidade.

Segundo [Henricksen et al 2002], existe uma série de características acerca da natureza da informação contextual que provocam um grande impacto no projeto de uma plataforma sensível ao contexto, e que determinam alguns dos seus requisitos: (i) a informação contextual é intrinsecamente imperfeita; (ii) a informação contextual é altamente inter-relacionada; (iii) o contexto possui várias representações alternativas (por exemplo, existe um gap significativo entre a saída de um sensor e o nível de informação que é útil para as aplicações); (iv) a informação contextual disponibilizada pela plataforma é temporal, isto é, depende de quando os dados foram obtidos. [Dockhorn 2003] discute alguns dos requisitos essenciais das plataformas de serviços sensíveis ao contexto. Considerar esses requisitos e as características intrínsecas da informação contextual são questões primordiais na definição da arquitetura da plataforma. Pesquisas mais recentes [Ranganathan et al 2004], [Gu et al 2004] defendem que técnicas tradicionais de modelagem da engenharia de software não são expressivas o suficiente para modelagem de contexto e, por isso, o uso de ontologias [Guarino 1998] é indicado para a construção de modelos de contexto em ambientes ubíquos. Essa é uma das questões que vêm sendo investigadas no projeto da plataforma Infraware.

XXXII SEMISH 1993

3. A Plataforma Infraware A arquitetura da plataforma Infraware é baseada no trabalho desenvolvido no projeto holandês WASP (Web Architectures for Services Platforms) [WASP]. WASP é um projeto desenvolvido na University of Twente em parceria com o Telematica Instituut e a Ericsson, com o objetivo de oferecer uma infra-estrutura de apoio ao desenvolvimento e execução de aplicações sensíveis ao contexto, usando a tecnologia de Web Services. Em sua proposta inicial [Dockhorn 2003], a arquitetura WASP era composta por três componentes principais: o Interpretador de Contexto, os Repositórios e o Monitor, cujas funcionalidades foram redefinidas e estendidas na Infraware (Figura 1).

Figura 1. Arquitetura atual da plataforma Infraware.

Nessa arquitetura destacam-se os componentes com capacidade de manipulação semântica: Service Manager, Registry Manager, User Registries, Task Ontologies Registry, Semantic Service Description Registry e Domain Ontologies Registry. A arquitetura proposta usa tecnologias da Web Semântica, como as linguagens de marcação OWL e RDF, e introduz uma nova abordagem baseada em ontologias de tarefas para a seleção e composição de serviços. Uma descrição detalhada da Infraware está fora do escopo desse artigo (vide [Santos 2004] para tal). Deve ser observado que tanto na plataforma WASP quanto na Infraware a função de interpretação de contexto está sendo simulada. Existe, portanto, a necessidade imediata de se implementar o Interpretador de Contexto como forma de se materializar um dos componentes mais importantes da arquitetura. Isso permite o desenvolvimento de protótipos de aplicações sensíveis ao contexto em cenários mais realísticos, como o apresentado na Seção 6.

XXXII SEMISH 1994

4. O Projeto do Interpretador de Contexto A interpretação de contexto é o conjunto de métodos e processos que realizam a abstração, o mapeamento, a manipulação, a agregação, a derivação, a inferência, o refinamento e demais ações sobre as informações contextuais, com o propósito de facilitar o entendimento de um determinado contexto pelas aplicações e auxiliá-las na tomada de decisões. Em [Dey 2000], a interpretação de contexto é vista como o processo de se elevar o nível de abstração das informações contextuais de um ambiente, de gerar uma informação contextual mais elaborada a partir de uma mais primitiva, como, por exemplo, gerar o nome do local em que se encontra um indivíduo a partir de suas coordenadas de localização.

O Interpretador de Contexto proposto utiliza uma infra-estrutura de componentes de software reutilizáveis, que corretamente dispostos e organizados, agem como ferramentas funcionais que realizam o processo de interpretação de contexto e de informações contextuais. Os três componentes funcionais do Interpretador de Contexto da plataforma Infraware são: os Gatherers, os Reasoners e os Aggregators (Figuras 2 e 3). Além dos componentes funcionais, um outro componente, o Manager, gerencia e organiza as atividades do Interpretador de Contexto.

Figura 2. Arquitetura do interpretador de contexto.

Os Gatherers são as unidades funcionais que compõem a interface entre o Interpretador de Contexto e o mundo externo (sensores ou quaisquer outras fontes de informações contextuais), criando uma abstração do mundo externo para a plataforma Infraware. Os Gatherers são responsáveis pela coleta de informações contextuais de maneira organizada e transparente. Eles utilizam um mecanismo de transformação dos dados obtidos das fontes de contexto em um padrão uniforme de leitura, a fim de que as informações contextuais sejam entendidas pelo Interpretador. A Figura 3(a) mostra a divisão interna dos Gatherers em duas camadas de funcionalidades bem definidas, que se inter-relacionam e trocam mensagens e informações através do Gatherer Communication Protocol (GCP). A camada inferior do Gatherer é chamada de Wrapper. Ela é a camada mais próxima dos elementos que fornecem a informação

XXXII SEMISH 1995

contextual para a plataforma e age como um envoltório de informações contextuais. Funcionalmente, um Wrapper é um tradutor de informações, que realiza a tradução do modelo de dados e da linguagem de comunicação das fontes de contexto para um modelo de comunicação e de contexto padrão que a plataforma é capaz de entender. Cada tipo de sensor e de fonte de contexto possui um Wrapper característico e específico, capaz de transformar as informações da fonte de contexto em dados legíveis para a plataforma.

Figura 3. Gatherers, Reasoners e Aggregators do interpretador de contexto.

A camada superior do Gatherer é chamada de Collector. Essa camada busca e colhe as informações contextuais do ambiente, além de garantir o envio dessas informações aos demais componentes do Interpretador de Contexto. Através do protocolo de comunicação do Gatherer, o Collector decide qual Wrapper utilizar como meio de acesso aos provedores de contexto. Para o Collector, o Wrapper é visto como o próprio provedor de contexto, abstraindo a complexidade dos formatos dos dados e enviando informações em um formato uniforme. Assim, a tarefa do Collector abrange a coleta de informações, não importando se elas estão distribuídas, centralizadas ou se são de difícil acesso.

Os Reasoners (Figura 3(b)) realizam a conversão de uma informação contextual mais primitiva em uma mais elaborada, além disso, são capazes de inferir e derivar informação contextual de relevância para aplicações sensíveis ao contexto. De acordo com a necessidade da aplicação, os Reasoners podem variar de muito simples a extremamente complexos, podendo ser implementados por meio de diferentes estruturas computacionais. A estrutura lógica dos Reasoners aqui proposta é baseada em Grafos Acíclicos Dirigidos [Szwarcfiter 1986]. Cada nó dos grafos montados nos Reasoners representa um tipo de informação contextual que pode ser acessada pelas aplicações através da plataforma e do Interpretador de Contexto. Os nós são divididos em Primitivos (P) e Resultantes (R), representando, respectivamente, as informações contextuais primitivas provenientes dos Gatherers e as informações contextuais resultantes de processos de derivação e interpretação de contexto, geradas a partir das informações primitivas e de outras informações resultantes. Cada nó dos grafos guarda uma lista dos nós que dependem dele para a geração de novas informações contextuais. Além disso, os nós resultantes também guardam uma segunda lista contendo os nós dos quais eles dependem para gerar suas próprias informações.

Os nós primitivos dos Reasoners recebem as informações contextuais primitivas dos sensores e demais provedores de contexto coletadas e enviadas pelos Gatherers. A cada nova informação contextual primitiva atualizada nos nós primitivos dos grafos, um algoritmo de propagação de valor é executado nesse nó e a nova informação contextual

XXXII SEMISH 1996

é enviada para os demais nós dos grafos que necessitam dessa informação. O valor é propagado de nó em nó dos grafos, atualizando as informações contextuais e gerando a interpretação, inferência e derivação de contextos. Os valores das informações contextuais resultantes são calculados de acordo com a propagação de valores dos demais nós dos grafos dos Reasoners. Os nós dos Reasoners podem ainda realizar duas funcionalidades de apoio à manipulação de contexto e informação contextual na plataforma. A primeira delas é um pequeno histórico contendo os últimos valores de informação contextual que ocorreram em um nó, funcionando como um cache de informações. A segunda funcionalidade de apoio presente nos nós dos Reasoners é o disparo de ações e mensagens às aplicações e demais componentes da plataforma. As ações e as mensagens são disparadas de acordo com mudanças de valores das informações contextuais dos nós e podem gerar, de maneira controlada, mudanças de comportamento em módulos da plataforma e até em aplicações cliente. As ações podem ser chamadas de métodos, de serviços, de dados contidos em uma estrutura externa ao Interpretador de Contexto ou qualquer outra ação relevante para a plataforma e para uma aplicação cliente. Já as mensagens podem ser de avisos, de notificações, de mudanças de contexto, de término de um determinado processo ou outra mensagem necessária à interpretação e à manipulação de contexto.

Os processos de interpretação, manipulação, inferência e derivação de contexto e ocorrem em função dos arranjos e das distribuições corretas dos nós primitivos e resultantes nos grafos dos Reasoners, além do mecanismo de propagação de valores através dos grafos. A diversidade de informação contextual que pode ser gerada e processada depende da distribuição e organização desses nós, além do cálculo dos valores das informações em cada nó. Quanto maior for a complexidade de abstração, de geração e de interpretação de um determinado contexto ou informação contextual, mais complexo e inter-relacionado será o grafo que dará origem a esses dados. As informações contextuais que são manipuladas nos nós de um Reasoner podem ser reutilizadas na interpretação e geração de outras informações por outros Reasoners. Os nós primitivos e derivados de um Reasoner podem apontar e depender de informações contidas em outros Reasoners. Por exemplo, os mesmos nós primitivos que fornecem informação de localização de usuários para uma aplicação de mapa em um campus universitário pode também enviar suas informações para aplicações que calculam as velocidades médias desses indivíduos.

Devido à natureza distribuída da informação contextual, há a necessidade de existir um elemento no Interpretador de Contexto que realize a tarefa de agregação e agrupamento das informações que chegam e são processadas por ele. A agregação de informação contextual se refere à coleta e ao agrupamento de diversos dados distribuídos pela plataforma ou no ambiente externo que estão logicamente inter-relacionados em um único pacote de dados para as aplicações sensíveis ao contexto [Dey 2000]. O componente Aggregator (Figura 3(c)) é o módulo responsável pelo agrupamento das informações contextuais referentes a uma dada entidade, tal como pessoas, restaurantes, dispositivos móveis e pontos turísticos. Além disso, os Aggregators também realizam o agrupamento das informações contextuais de um determinado contexto reconhecido pela plataforma, entre eles a localização e a temperatura. Os Aggregators vêm suprir a necessidade de uma unidade funcional que obtém e agrupa as informações contextuais relevantes, e que estão logicamente

XXXII SEMISH 1997

relacionadas, para as aplicações. Além disso, organiza as informações contextuais para as aplicações em uma estrutura de software única e compacta.

5. Implementação O Interpretador de Contexto foi implementado na linguagem Java. A Figura 5 ilustra suas principais classes, agrupadas nos componentes funcionais do Interpretador. Essa figura constitui o diagrama de classes UML básico para a construção dos Reasoners, dos Aggregators e dos Gatherers propostos. A abstração Gatherer, para esse trabalho, teve somente a camada dos Collectors implementada. Os Wrappers não foram explorados nesta versão do Interpretador, tendo seu comportamento simulado por software. Cada objeto Collector possui um nome e um tipo que o caracterizam, além de uma lista de nós primitivos (consumerNodes) que representam os nós alimentados por cada objeto dessa classe. O método privado sendValue() envia o valor lido dos Wrappers monitorados aos respectivos nós primitivos dos Reasoners que solicitaram a informação. Para isso, esse método envia a informação contextual obtida para cada elemento presente na lista consumerNodes. Além de enviar as informações contextuais e alterar os dados de cada nó primitivo, o método sendValue() é quem inicia o processo de propagação e disseminação das informações contextuais nos Reasoners.

Figura 5. As classes do interpretador.

A classe Aggregator define os atributos name, type e um atributo denominado table, que, por sua vez, é um mapeamento hash que agrega as informações contextuais agrupadas. Para tanto, os principais métodos implementados na classe Aggregator são: addNewEntry(), que adiciona uma nova entrada na tabela de índices; removeOldEntry(), que remove uma entrada da tabela; e getEntryData(), que retorna a informação referenciada por uma entrada da tabela. Portanto, o Aggregator funciona como uma tabela de índices em que cada uma de suas entradas referencia uma informação contextual contida em um nó dos Reasoners. O agrupamento de informações contextuais auxilia a manipulação e a entrega dos dados às aplicações. A busca pela

XXXII SEMISH 1998

informação através da tabela de índices é mais rápida e eficiente do que uma busca por profundidade através dos nós dos Reasoners. Além disso, o Aggregator possibilita o reuso de informações já processadas por diferentes aplicações.

O pacote Reasoner implementa as estruturas necessárias para o processamento das informações contextuais. Ele é composto pelas classes ContextNode, PrimitiveContextNode, ResultantContextNode, History, NodeActions, Language e LanguageJava. A classe abstrata ContextNode generaliza a representação das informações contextuais em nós de um grafo. Cada ContextNode possui um nome e um tipo específicos, que caracterizam a informação contextual armazenada e o tipo de contexto que ela representa. Além disso, o valor referente à informação contextual é encapsulado em um objeto da classe ContextValue. Essa classe descreve a informação contextual em termos de valor absoluto, de sua unidade de medida e de um tipo. As classes PrimitiveContextNode e ResultantContextNode especializam a classe abstrata ContextNode respectivamente em nós primitivos e em nós resultantes. Como nos nós resultantes pode ocorrer derivação e inferência de valores, um importante atributo da classe ResultantContextNode é a string valueExpression. Esta string representa uma sentença a ser interpretada e essa interpretação, por sua vez, resultará no valor da informação contextual armazenada em cada nó resultante.

A classe History implementa o cache de informações contextuais associados a cada nó dos grafos dos Reasoners. A classe abstrata Language representa um interpretador de expressões genérico e define métodos abstratos para interpretação e processamento de sentenças que contenham funções e procedimentos para o cálculo dos valores de nós resultantes. Essa classe abstrata deverá, portanto, ser efetivamente estendida por classes como a LanguageJava que implementem interpretadores de sentença específicos para determinada linguagem de programação. Na implementação da classe LanguageJava foi utilizada a ferramenta BeanShell [BeanShell] para a interpretação e processamento das sentenças escritas em Java. Assim, os nós resultantes dos Reasoners independem de linguagem de programação e do mecanismo de interpretação dos valores. Interpretadores de sentença específicos para outras linguagens de programação podem ser incorporados ao Interpretador de Contexto pela inclusão de novas classes que estendam a classe Language.

O método que realiza a propagação de valores através dos Reasoners é o contextPropagator(). Esse método percorre a lista de nós dependentes (subscribers) de um determinado nó, recalculando seus valores. A recursão acontece através do método calculateValue() de um nó resultante. Caso o novo valor calculado para o nó seja diferente do valor previamente armazenado, é disparada a propagação desse novo valor e as informações contextuais dos demais nós resultantes são recursivamente recalculados. Cada ContextNode possui ainda uma lista de ações, representadas pela classe NodeActions, que são executadas sob determinadas condições. Para isso, os ContextNodes monitoram condições, também expressas na forma de sentenças, e se responsabiliza pelo disparo das ações correspondentes a cada condição. Nos nós primitivos, as ações podem ser disparadas a partir do método setContextValue(), chamado quando um novo valor é atribuído ao nó. Já nos nós resultantes, as ações podem ser disparadas sempre que o valor do nó é recalculado, através do método calculateValue(). Em ambos os casos, o disparo das ações se dá pelo método triggerActions(), que faz uso do mesmo interpretador de sentenças utilizado no cálculo

XXXII SEMISH 1999

dos valores dos nós resultantes. Este método verifica se o novo valor atribuído a um nó satisfaz a alguma condição que possa vir a disparar uma ação expressa pelos NodeActions. Por fim, o Manager é o componente do Interpretador de Contexto incumbido de gerenciar e controlar as suas ações. Para que o Manager possa atender a requisições de aplicações sensíveis ao contexto, estruturas de dados contendo os elementos funcionais do Interpretador de Contexto são montadas e organizadas de acordo com o que for requisitado pelas aplicações. O Manager, através de uma classe denominada ComponentMap, instancia três tipos de mapeamento, um para cada conjunto de elementos funcionais (Gatherers, Reasoners e Aggregators). Esses mapeamentos são de fundamental importância para o funcionamento das estruturas interpretadoras de contexto e para a troca de informações entre os elementos do Interpretador.

6. Estudo de Caso Com o intuito de demonstrar o uso da infra-estrutura de componentes proposta para o Interpretador de Contexto e o potencial dessa solução em sistemas de computação ubíqua, foram implementadas três aplicações simples relacionadas a um cenário hospitalar. O cenário para o qual as aplicações foram desenvolvidas consiste de um hospital, dividido em oito ambientes distintos (salas com diferentes finalidades) onde se realizam os atendimentos. Nas salas Trauma 1 e Trauma 2 são atendidos os pacientes em casos de emergência. Já nas salas Room 1, Room 2 e Room 3 são realizadas consultas de atendimentos gerais aos pacientes. Além disso, compõem o hospital a sala de cirurgia, a sala de raios-X e o saguão principal. No plantão desse hospital, quatro médicos realizam o atendimento: Gonçalves, Cury, Caruso e Barbosa.

Figura 6. Infra-estrutura montada para o desenvolvimento das aplicações hospitalares.

A Figura 6 mostra os relacionamentos e as ligações entre os nós de um grafo construído para atender os requisitos de fornecimento de informações contextuais para as aplicações desenvolvidas. Essa mesma figura, também ilustra a entrega das informações pelos Gatherers aos nós primitivos do grafo. Como pode ser observado, os

XXXII SEMISH 2000

Gatherers locationCury, locationGoncalves, locationCaruso e locationBarbosa alimentam seus respectivos nós primitivos com informações acerca da localização de cada médico. Os nós primitivos, por sua vez, fornecem as coordenadas de localização às aplicações e repassam suas informações atualizadas aos nós resultantes roomDoctorCury, roomDoctorGoncalves, roomDoctorCaruso e roomDoctorBarbosa, respectivamente. Esses nós resultantes são os responsáveis por derivar o nome das salas em que cada médico se encontra, a partir das coordenadas de localização. Por fim, os dados contendo os nomes das salas dos médicos são propagados ao nó resultante doctorResp, encarregado de interpretar e decidir o médico responsável por um novo atendimento de emergência, baseado em critérios como a sala em que os médicos de encontram durante a ocorrência da possível emergência.

A Figura 7 ilustra a primeira aplicação desenvolvida. Trata-se de um mapa, representando a planta do hospital, que também apresenta a localização dos médicos monitorados. Para isso, cada médico deve possuir um dispositivo capaz de enviar regularmente suas coordenadas de localização ao Interpretador de Contexto. A aplicação sensível ao contexto solicita então à plataforma informações referentes à localização de cada médico a fim de construir um mapa representando a distribuição real dos médicos no hospital.

Figura 7. Localização dos médicos no hospital.

Para o estudo de caso em questão, o recebimento das informações de localização dos médicos foi simulado, uma vez que o escopo do trabalho desenvolvido é a interpretação do contexto. Entretanto, vale observar que vem sendo desenvolvido na plataforma Infraware um trabalho paralelo de investigação e construção de uma interface de comunicação com sensores e provedores de contexto para o recebimento e tratamento das informações contextuais.

A segunda aplicação desenvolvida trata-se de um quadro informativo contendo os nomes dos médicos plantonistas e as respectivas salas em que os mesmos se encontram. Se a alteração nos valores das coordenadas de localização indicar que um

XXXII SEMISH 2001

determinado médico se movimentou de uma sala do hospital para outra, o quadro de localização é atualizado, retratando a nova situação. A interface do quadro de localização é ilustrada através da Figura 8.

Figura 8. Quadro de localização dos médicos em um hospital.

A terceira aplicação é capaz de interpretar as localizações de cada médico, inferir suas atividades e a partir daí escolher o médico com maior disponibilidade para atender a nova emergência que foi disparada. Após o processo de decisão sobre o médico responsável por uma nova emergência, uma ação é disparada pelo Interpretador de Contexto avisando à aplicação cliente o resultado final do processamento. Em uma situação real, a ação tomada poderia ser o envio de um sinal a um dispositivo (PDA ou pager) do médico escolhido, a fim de que o mesmo fosse notificado sobre o ocorrido. Essa aplicação é tipicamente dependente e sensível ao contexto do ambiente em que está situada. O nome do médico responsável pela emergência depende do momento, da situação em questão e da localização de cada médico, que se alteram a cada instante. Claramente, outros tipos de informações contextuais poderiam ser adicionados ao processo de decisão do médico mais adequado ao atendimento de emergência. Exemplos incluem: a especialidade médica, a experiência anterior em certos tipos de atendimento, os perfis profissionais das equipes de plantão, as afinidades entre médico e paciente, etc.

Observa-se que o cenário hospitalar é um ambiente potencialmente receptivo às aplicações móveis sensíveis ao contexto. O trabalho clínico nos hospitais modernos é caracterizado por um alto grau de mobilidade, com freqüentes interrupções e muita colaboração ad hoc entre colegas de diferentes especialidades. Essa natureza do trabalho clínico é pobremente suportada pelas arquiteturas cliente-servidor e sistemas de informação hospitalares atuais, tipicamente desktop e voltados, na sua maioria, para o controle operacional e administrativo. Além disso, o contexto onde se dá a prática médica é simplesmente ignorado por essas arquiteturas e sistemas de informação.

7. Projetos Relacionados Como mencionado, o desenvolvimento de plataformas e infra-estruturas de apoio à construção e à execução de aplicações e sistemas sensíveis ao contexto é um dos desafios da Computação Ubíqua. Essa seção apresenta algumas iniciativas de pesquisa em trabalhos que facilitam o desenvolvimento dessas aplicações.

O projeto GaiaOS [Hess et al 2002], oferece uma infra-estrutura de middleware distribuída que coordena os recursos computacionais de um espaço físico, transformando-o em um sistema computacional programável, similar a um sistema

XXXII SEMISH 2002

operacional tradicional, à medida que gerencia as tarefas comuns a todas as aplicações. Para permitir que seus usuários interajam com diversos dispositivos e serviços simultaneamente, o GaiaOS disponibiliza espaços virtuais para seus usuários, uma abstração que compreende as informações contextuais, as tarefas e os dispositivos associados a cada usuário. O Context Broker Architecture (CoBrA) [Chen 2004] fornece uma arquitetura baseada em agentes para o desenvolvimento de aplicações sensíveis ao contexto em espaços inteligentes. Trata-se de uma arquitetura centralizada em componente denominado context broker, que compartilha um modelo de contexto através da comunicação entre agentes distribuídos, serviços e dispositivos.

A arquitetura do Solar System [Chen, Kotz 2002] busca suprir os requisitos de flexibilidade, mobilidade e escalabilidade em ambientes ubíquos. Essa arquitetura também utiliza uma estrutura baseada em grafos acíclicos dirigidos para manipular informações contextuais distribuídas nesses ambientes, com o propósito de refiná-las e fornecê-las às aplicações. A interpretação de contexto ocorre através de combinações de operadores em seus grafos. O Context Toolkit [Dey 2000] oferece um framework conceitual de abstrações de componentes para apoiar o desenvolvimento e a execução de aplicações sensíveis ao contexto. Esse framework define como principais componentes os Widgets, os Interpreters e os Aggregators, para prover às aplicações transparência na aquisição e manipulação das informações contextuais. A interpretação de contexto ocorre através dos componentes Interpreters, apesar de ser ainda limitada e dependente do tipo de aplicação e implementação utilizada em cada componente.

Como mencionado, o Interpretador de Contexto aqui proposto foi inspirado nesses dois últimos projetos. Diferentemente deles, o interpretador concebido consegue atender a uma gama maior de situações e aplicações possíveis, em virtude da generalidade dos seus componentes. Tanto o Solar System quanto o Context Toolkit são dependentes dos tipos de aplicação e implementação utilizados. Além disso, a arquitetura Infraware explora conceitos de SOA (Service Oriented Architectures) e da Web Semântica na sua realização (por exemplo, na descrição e descoberta de serviços), visando a garantia de representação e interoperabilidade semântica.

8. Conclusões e Trabalhos Futuros Este trabalho descreveu o projeto de um Interpretador de Contexto, baseado em grafos acíclicos dirigidos, destinado à manipulação, inferência e interpretação de contextos. Esse componente desempenha um papel fundamental nas arquiteturas das novas plataformas de suporte a aplicações móveis sensíveis ao contexto.

O interpretador proposto apresenta as seguintes características particulares, que o diferencia de sistemas similares: (i) componentes genéricos o suficiente para serem usados e reutilizados em um grande número de aplicações sensíveis ao contexto; (ii) infra-estrutura de processamento de informações contextuais independente das tecnologias de cálculo de valores utilizados internamente nos nós dos Reasoners; (iii) flexibilização quanto ao uso diversificado de linguagens de programação para descrever mecanismos de cálculos de valores contextuais e disparos de ações; (iv) uso de um pequeno histórico de dados para armazenagem de informações contextuais.

Algumas questões não foram deliberadamente exploradas no escopo deste trabalho, constituindo, assim, temas de estudos futuros. São exemplos: a manipulação

XXXII SEMISH 2003

de informações contextuais imprecisas e ambíguas, a propagação de incertezas acumuladas, a persistência e a confiabilidade das informações contextuais, dentre outros. Além disso, outros mecanismos de interpretação de contextos e de implementação dos Reasoners devem ser investigados como forma de se estabelecer uma base comparativa para estudos de desempenho, escalabilidade e decidabilidade.

Referências BeanShell (2005) “Leightweight Scripting for Java”. http://www.beanshell.org, Março.

Calvi, C. Z. (2005) “Um Interpretador de Contexto para Plataformas de Serviços Context-Aware”, Projeto de Graduação, Curso de Engenharia de Computação, UFES.

Chen, G., Kotz, D. (2002) “SOLAR: A Pervasive-Computing Infrastructure for Context-Aware Mobile Applications”, Technical Report TR2002-421, Dartmouth College.

Chen, H. (2004) “An Intelligent Broker Architecture for Pervasive Context-Aware Systems”, Ph.D. Thesis, University of Maryland.

Dey, A. K. (2000) “Providing Architectural Support for Building Context-Aware Applications”, Ph.D. Thesis, Georgia Institute of Technology.

Dockhorn Costa, P. (2003) “Towards a Services Platform for Context-Aware Applications”, Master Thesis, University of Twente, Enschede, The Netherlands.

Gu Tao et al (2004) "A Middleware for Building Context-Aware Mobile Services". In: Proceedings of IEEE Vehicular Technology Conference, Milan, Italy.

Guarini N. (1998) “Formal ontology in information systems”, In: Proceedings of FOIS’98, Trento, Italy.

Henricksen, K., Indulska, J., Rakotonirainy, A. (2002) “Modeling Context Information in Pervasive Computing Systems”, In: Proceeding of Pervasive 2002, Zurich.

Hess, C. K., Romon, M., Campbel, R. H. (2002) “Building applications for ubiquitous computing environments”, In: Proc. Intl. Conference on Pervasive Computing.

McCarthy, J. (1993) “Notes on formalizing context (expanded notes)”, In: Proceedings of the Thirteenth International Joint Conference on Artificial Intelligence.

Ranganathan A. et al (2004) “Use of Ontologies in a Pervasive Computing Environment” In: The Knowledge Engineering Review, vol. 18:3, 209-220, Cambridge University Press.

Santos, L. O. B. S. (2004) “Semantic Services Support for Context-Aware Platforms”, Dissertação de Mestrado, Departamento de Informática, UFES.

Schilit, B. N. (1995) “A Context-Aware Systems Architecture for Mobile Distributed Computing”, Ph.D. Thesis, Columbia University.

Szwarcfiter, J. L. (1986) “Grafos e algoritmos computacionais”. 2ª edição, Editora Campus, Rio de Janeiro.

WASP Project: http://www.freeband.nl/projecten/wasp/ENindex.html.

Weiser M. (1991) "The Computer for the Twenty-First Century" Scientific American, pp. 94-10, September.

XXXII SEMISH 2004